02:33:36 slyrus_ [~chatzilla@adsl-76-254-45-26.dsl.pltn13.sbcglobal.net] has joined #sbcl 02:34:09 -!- slyrus [~chatzilla@adsl-99-39-234-229.dsl.pltn13.sbcglobal.net] has quit [Read error: Connection reset by peer] 02:34:17 -!- slyrus_ is now known as slyrus 03:03:36 tsuru` [~charlie@adsl-74-179-197-62.bna.bellsouth.net] has joined #sbcl 03:04:48 -!- tsuru [~charlie@adsl-74-179-250-19.bna.bellsouth.net] has quit [Ping timeout: 240 seconds] 03:52:10 -!- antgreen [~user@bas3-toronto06-2925099342.dsl.bell.ca] has quit [Ping timeout: 260 seconds] 05:27:42 -!- loke [~elias@bb115-66-85-121.singnet.com.sg] has quit [Ping timeout: 255 seconds] 05:30:25 loke [~elias@bb115-66-85-121.singnet.com.sg] has joined #sbcl 06:17:03 sdemarre [~serge@91.176.28.90] has joined #sbcl 07:39:28 attila_lendvai [~attila_le@95.56.172.20] has joined #sbcl 07:39:28 -!- attila_lendvai [~attila_le@95.56.172.20] has quit [Changing host] 07:39:28 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 07:47:18 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 10:22:22 akovalen` [~anton@95.72.102.59] has joined #sbcl 10:23:11 -!- loke [~elias@bb115-66-85-121.singnet.com.sg] has quit [Ping timeout: 248 seconds] 10:24:03 -!- akovalenko [~anton@95.72.96.201] has quit [Ping timeout: 252 seconds] 10:29:36 loke [~elias@bb115-66-85-121.singnet.com.sg] has joined #sbcl 10:43:37 nikodemus [~nikodemus@cs181056239.pp.htv.fi] has joined #sbcl 10:43:37 -!- ChanServ has set mode +o nikodemus 11:00:47 hlavaty [~user@91-65-217-112-dynip.superkabel.de] has joined #sbcl 11:03:59 -!- hlavaty [~user@91-65-217-112-dynip.superkabel.de] has quit [Read error: Connection reset by peer] 11:26:21 -!- akovalen` is now known as akovalenko 11:50:54 homie [~levgue@xdsl-84-44-155-200.netcologne.de] has joined #sbcl 11:55:48 tsuru`` [~charlie@adsl-74-179-17-157.bna.bellsouth.net] has joined #sbcl 11:57:55 -!- tsuru` [~charlie@adsl-74-179-197-62.bna.bellsouth.net] has quit [Ping timeout: 252 seconds] 12:01:04 _8david [~user@port-92-195-81-17.dynamic.qsc.de] has joined #sbcl 12:02:41 -!- lichtblau [~user@port-92-195-43-239.dynamic.qsc.de] has quit [Ping timeout: 252 seconds] 12:11:18 attila_lendvai [~attila_le@178.88.210.192] has joined #sbcl 12:11:18 -!- attila_lendvai [~attila_le@178.88.210.192] has quit [Changing host] 12:11:18 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 12:21:32 hlavaty [~user@91-65-217-112-dynip.superkabel.de] has joined #sbcl 12:26:51 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 244 seconds] 12:29:36 feh. slime's receive-if is messing my benchmarks -- and i was scratching my head and wondering where all the consing was coming from 12:34:32 hahaha 12:58:01 nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has joined #sbcl 13:14:18 antgreen [~user@70.50.67.213] has joined #sbcl 13:48:01 Is there a way to disassemble a function with its lambdas and flets? 13:49:57 Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has joined #sbcl 13:49:59 angavrilov_: sb-disassem:disassemble-code-component, maybe? 13:50:23 i tend to use slime-inspector on the function object, and follow the references 13:57:21 So, I've been wondering about this a bit: Why is the barrier-to-entry for SBCL hacking as high as it is? 13:59:27 too few shallow bugs that are easy to run across? 14:00:13 the compiler doesn't quite resemble anything in any textbook 14:00:47 our signal handling -- while more robust -- is also growing quite baroque and hard to read 14:01:59 Hmm. 14:02:33 I agree that interrupt handling could do with some TLC. 14:02:48 TLC? 14:02:53 Tender Loving Care. 14:02:57 ah 14:03:17 The compiler shouldn't be scaring people off of hacking the rest of the system, though, should it? 14:03:26 probably not 14:03:53 <_8david> overall though, I think SBCL is the one with the lowest "barrier to entry". Trivial bootstrap, quite a lot of people involved and ready to point out stuff, written in CL, etc. 14:03:53 and lots of things -- like transforms -- are easy to hack on without understanding anything about most of the compiler 14:04:28 but what gets people into cl impl hacking in the first place? 14:04:37 Mmm. With handholding, someone could pretty much do an entire new backend without understanding much of the front-end. 14:06:11 <_8david> But if this was regarding the earlier question in the spirit of `why doesn't dissemble do something useful', I'd certainly agree that some parts of the code base are a tad overwhelming there, especially for the newbie. ("How do I know I'm not breaking it entirely while improving some detail?") 14:06:56 hi hi. just wondering, since i hadn't heard anything about it in a while. is this a low level issue that'd require a lot of work? LANG=C sbcl ï 14:07:07 cutting my teeth on lisp still and picking my battles ;) 14:07:49 maybe we should organize "a summer of SBCL". projects defined by sbcl committers where they are willing to mentor, ranging from "an afternoon's hack" to "a week or two on the outside" in complexity 14:08:01 that'd be fun 14:08:28 dsp_: what's the question? 14:08:40 it blows up SBCL 14:08:49 what did you expect it to do? 14:09:06 nikodemus: it's not good to crash into LDB when command-line arguments can't be decoded.. 14:09:09 i don't know. is it expected behaviour to drop to the LDB? 14:09:20 oh, LDB 14:09:25 that's not nice, no 14:09:27 <_8david> expected I'd say, but IMNSHO very unfortunate 14:10:01 <_8david> As nice as a fully unicode world would be, on Unix, neither file names nor command line arguments can be expected to strictly conform to any encoding. 14:10:09 indeed 14:10:12 Ah, finally! My cold-package-system hack is finally producing the fasl changes I've been wanting. 14:10:40 nikodemus: Summer of lisp that would be really fun. That said, I agree with _8david and think that SBCL is pretty accessible, especially considering launchpad and your blog entry on the matter. :) 14:15:43 oh, we already had a launchpad bug about that 14:16:19 i'm pretty sure there's another one -- which is probably the exact same underlying bug -- where contrib build breaks if the directory name contains non-ascii characters 14:16:41 oiiii [~oiiii@82.71.241.25] has joined #sbcl 14:20:35 nikodemus: yes, my apologies, i filed that bug originally 14:20:47 i just had not heard anything about it, which is why i asked, as i was considering diving in myself 14:21:22 it really is not an issue for me, and i happened across it accidentally while doing something i shouldn't have, but i usually am alarmed when I hit the LDB 14:23:08 for a good reason :( 14:23:29 dsp_: the real problem here is to decide what you want -- "anything but dropping to LDB" would be easy to implement, if you don't expect *posix-argv* to be useful in any way. 14:24:00 well, from the manual page it seems that the possible argument list that is allowed is a limited set 14:24:55 for example, runtime options and toplevel options seem to be well defined, though i'm not sure about user options 14:24:59 dsp_: Anything that the normal startup doesn't recognize ends up in *posix-argv* for user programs to pick over. 14:25:10 aha 14:26:45 and user functions in *init-hooks*, while there are too late for runtime options, can do anything to all other arguments. 14:29:59 i am not sure what would be the best option, really. silently ignoring the command line might not be expected behaviour, but if it is stuff that cannot be parsed then i suppose it can't be put on *posix-argv*. 14:30:54 when i was experimenting with UTF-8 previously there were certain conditions related to incorrect coding that were triggered that put us in the regular debugger, i think. not sure if such a thing is feasable. (for example, i think it gave the option to replace the invalid stuff) 14:34:29 oh well, it's friday and 4.30pm here so that means beer at the office time. *toddles off* 14:48:54 ... two things that I think I'd like to see in SBCL are the package relationships becoming a DAG and much of the stuff in SYS:SRC;CODE;*.*.* being moved to subdirectories and possibly broken up a bit.. 14:50:14 Being able to look in SYS:SRC;CODE;DEBUGGER; and find the various parts of the debugger, for example. 14:51:11 Maybe break that into debugger and debugger-interface. 15:31:40 i'm not sure about that -- but maybe it's because i have a C-c g bound to grep, not git grep 15:32:19 sorting out package relationships sounds good to me 15:32:39 but i may have a different vision of what it should entail :) 15:33:16 One of the reasons that I want to break up code/ into subdirectories is that it groups related files into an easily-perceived, conceptually cohesive unit. 15:34:25 in cases where that is so, i don't have a problem with that -- as long as there is a catchall place for things which don't obviously belong to a subdirectory 15:34:41 Sure. They can stay where they are. 15:34:44 maybe src/debugger/ in parallel with src/code/ and src/compiler/ ? 15:35:22 Should we move src/code/external-formats/ then? 15:35:30 possibly 15:36:15 Another thing I'd like to do is commit some version of my genesis refactoring. 15:36:24 but src/code/debugger works for me just as well 15:37:22 http://repo.or.cz/w/sbcl/nyef.git/shortlog/refs/heads/radical-refactoring/genesis 15:40:00 Oh, and what do you think about moving the genesis headers and all the symlink games away from src/runtime/ to somewhere under src/output/ ? 15:40:22 We really shouldn't have any build products under src/. 15:40:47 could it be just output/ (and the same for objects and exe, btw) ? 15:40:58 that is, for runtime C stuff 15:41:05 akovalenko: I was thinking subdirectories, TBH. 15:41:17 output/headers/genesis/ and such. 15:42:28 Since we're using gnumake, we could plausibly do something in terms of a VPATH. 15:42:31 yep. while we're at it, bulding outside the tree would make life easier.. 15:43:44 definitely 15:43:51 src/runtime/ symlinks (or copies) are bad too (and they're build products, after all) 15:44:24 akovalenko: Be glad you don't have src/whatever/target/ symlinks anymore. 15:44:48 but I would be really glad if we could do with prepopulated linkage-table and get rid of ldso-stubs & scratch() before the Build revolution :) 15:48:20 What could we do if the cross-compiler could spit out fasls that could be loaded not only by genesis, but also by the target lisp? 15:48:37 they almost can already 15:48:52 I definitely had that more-or-less working on a train station outside paris about 9 years ago 15:48:59 8 years ago, maybe 15:49:00 Hunh. Neat. 15:49:06 What doesn't work? 15:49:11 cold-fset 15:49:16 ... Right. 15:49:33 other than that, it's less that stellarly useful because the cross-compiler can't compile anything clos-related 15:49:34 You had to chill the warm lisp, though, didn't you? 15:49:38 oh, yes 15:50:18 Might be able to make it happen without chill. 15:50:28 I suppose it would be fun to reintroduce the bootstrapping problem by making the cross-compiler (under those circumstances) use host macro definitions if target ones aren't available 15:50:42 "fun" as in "hideously ugly and will make me scream" 15:50:47 good for hallowe'en 15:50:53 Heh. 15:59:34 --> home 15:59:39 -!- nikodemus [~nikodemus@cs181056239.pp.htv.fi] has quit [Quit: Ex-Chat] 16:21:29 -!- Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has quit [Remote host closed the connection] 16:33:55 -!- oiiii [~oiiii@82.71.241.25] has quit [Remote host closed the connection] 16:36:39 prxq [~mommer@mnhm-590c0af9.pool.mediaWays.net] has joined #sbcl 16:42:34 -!- antgreen [~user@70.50.67.213] has quit [Read error: Connection reset by peer] 16:47:26 -!- prxq [~mommer@mnhm-590c0af9.pool.mediaWays.net] has quit [Quit: Leaving] 17:23:06 -!- hlavaty [~user@91-65-217-112-dynip.superkabel.de] has quit [Remote host closed the connection] 17:28:23 Hrm. I can change the fasdumper to dump a warm package name instead of cold package names. 17:29:25 But I think that would entail substantial damage to the handling of symbols and packages in genesis. 17:37:27 antgreen [user@nat/redhat/x-stobsgsywugdqili] has joined #sbcl 17:39:20 -!- dsp_ [~tt@lebesgue.cowpig.ca] has quit [Ping timeout: 260 seconds] 17:48:58 dsp_ [~tt@lebesgue.cowpig.ca] has joined #sbcl 18:23:47 homie` [~levgue@xdsl-78-35-129-49.netcologne.de] has joined #sbcl 18:26:45 -!- homie [~levgue@xdsl-84-44-155-200.netcologne.de] has quit [Ping timeout: 276 seconds] 18:33:20 Does anyone know why we have separate output/ and obj/ directories instead of, say, output/obj/ ? Is it just because that's the way it's always been? 19:04:32 pchrist_ [~spirit@gentoo/developer/pchrist] has joined #sbcl 19:05:55 rpg [~rpg@mpls.sift.info] has joined #sbcl 19:07:27 -!- pchrist [~spirit@gentoo/developer/pchrist] has quit [Ping timeout: 258 seconds] 19:33:35 How nuts would it be for me to try and fix lp 560977 (function-lambda-expression support) in the near future? ccl has a ccl:*save-definitions* global. Would that sort of solution be suitable or a declare setting or...? 19:45:25 *nyef* sighs. 19:45:40 Okay, where on earth is the d-x consing in with-spinlock? 19:46:09 I am completely failing to see it, but it has to be in there somewhere. 19:47:30 nyef: can you try get-spinlock separately? 19:48:02 Possibly at some point, but that's an even smaller code-area to not see it. 19:48:19 prxq [~mommer@mnhm-590c0af9.pool.mediaWays.net] has joined #sbcl 19:49:34 I'm re-running the thread tests again now, because some of them failed the first time, and I want to know if it's an intermittent failure or something that I actually need to worry about. 19:50:38 Hrm. Then again, I haven't actually put together the stack scavenging fixes, that might be causing trouble... 19:58:56 -!- angavrilov_ [~angavrilo@217.71.227.181] has quit [Ping timeout: 244 seconds] 20:00:13 *nyef* wonders if it's worth spending about $350 for a g4 notebook. 20:02:44 btw, qemu is now able to run sbcl-1.0.28 mipsel without _immediate_ crashing (it happens after you load ASDF or something). It's worse with ppc, but maybe hacking qemu is a good long-term strategy for testing on uncommon hardware... 20:04:48 I'm thinking that having build-time options for x86-64 in various configurations could actually alleviate much of the worst damage for the less-maintained ports. 20:05:55 Being able to run a cheneygc x86-64, for example, would flush out a few things. Or a 32-bit-wide heap on x86-64 would exercise a lot of the alpha-specific stuff. 20:07:13 "SBCL x86-64 reaches alpha quality" 20:07:18 Heh! 20:07:57 Hey, is there some option to with-test that says "we really, really expect to fail on this platform, but run the test anyway, and only tell us if it passes"? 20:08:35 Or should I just use skipped-on to suppress the "expected failure" output, since making it pass is really, really unlikely? 20:14:02 nyef: is it something that can start to work accidentally, without hours of relevant hacking? For windows stuff, iirc, I had no problems with unmarking expected failures when things started to work.. 20:14:47 Umm. No, it's something that would require hours of relevant hacking. 20:14:55 Possibly weeks or more of relevant hacking. 20:14:58 Good point. 20:15:45 Then I'd let it be expected-failure. Relevant hacker will read those tests through several times at that point, probably :) 20:16:18 Fair enough, I guess. 20:26:13 -!- akovalenko [~anton@95.72.102.59] has quit [Quit: software upgrade...] 20:35:03 akovalenko [~anton@95.72.102.59] has joined #sbcl 20:39:53 *nyef* sighs. 20:40:39 These long builds suck. 20:41:05 Especially when you're making a single-line change, but need a full build to see if it works properly or not. 20:48:22 nyef: hooray, you're almost ready for pre-populated linkage tables :) 20:49:03 Heh. I fail to see how that would speed up compiles on an 800MHz dual-core system. 20:49:15 dramatically :) 20:49:22 Riiight. 20:49:58 the point is, you change runtime, GCC recompiles it, and it's compatible with every other core you already have built :) 20:50:26 ... I change runtime, GCC recompiles it, and then I pick up at make-genesis-2. 20:50:48 I change compiler backend, and then I really -do- have to run a full build. 20:51:52 ooh, than I'd wait till you hack runtime C stuff on some very old PowerPC machine.. 20:52:11 I don't have anything older than my G4, sorry. 20:52:53 nyef: I'll think of donating one of my MIPS routers :) 20:53:11 Heh. Ever heard of cross-compilation? 20:53:43 ..of cold->warm stage? Tried to make it work with qemu once... good luck. 20:54:23 I've actually got a mips box capable of running some linux-2.4 system. 21:26:55 -!- antgreen [user@nat/redhat/x-stobsgsywugdqili] has quit [Remote host closed the connection] 21:27:00 -!- rpg [~rpg@mpls.sift.info] has quit [Quit: rpg] 21:38:56 Almost finished with the compiler side of getting DX working better on PPC. 21:40:41 If this build still works, should just be a matter of sorting out appropriate commits from what's in my working tree, index, and branch history, and then fixing up the GC stuff. 22:23:36 -!- sdemarre [~serge@91.176.28.90] has quit [Ping timeout: 240 seconds] 23:17:34 MrMc [~user@91-65-142-36-dynip.superkabel.de] has joined #sbcl 23:18:40 greetings to you all 23:23:06 -!- MrMc [~user@91-65-142-36-dynip.superkabel.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 23:25:29 MrMc [~user@91-65-142-36-dynip.superkabel.de] has joined #sbcl 23:33:29 -!- nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has quit [Quit: G'night all.] 23:38:44 I am trying to compile sbcl from git on OpenBSD and sb-posix fails 23:48:52 yes, it's indicative of a more serious problem that I haven't had time to track down 23:49:19 and sb-posix isn't actually failing to build, it's only one of the tests which fails 23:53:18 as there any way I can assist? 23:54:18 MrMc: of course you can. Just ask here for more info, so anyone else don't have to :) 23:54:29 joshe: which test? 23:55:15 one of the flock tests, the one which forks and has the child attempt some flock operation 23:56:18 what seems to be happening is that the child gets a SIGSEGV which isn't handled by the GC 23:58:10 is strace available on that OS? 23:58:28 ktrace is, yes 23:59:06 on the second thought, it's unlikely to be too useful