00:01:44 Okay, time for me to go find food. 00:01:50 -!- nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has quit [Quit: G'night all.] 00:42:27 pers [~user@96-25-162-104.gar.clearwire-wmx.net] has joined #sbcl 02:01:29 scombinator [~user@122-59-8-113.jetstream.xtra.co.nz] has joined #sbcl 02:01:53 I'm getting a wierd error from SBCL under SLIME 02:02:16 It's all native code - but the backtrace includes a foreign function 02:02:30 s/native/lisp/ 02:04:16 The actual error itself is a type error, it complains that I give it '(1 1) instead of a (MOD 536870909) 02:10:35 When I give it '(1), it's still not (MOD 536...) and when I give it 1 it's not a LIST 02:19:00 -!- scombinator [~user@122-59-8-113.jetstream.xtra.co.nz] has quit [Remote host closed the connection] 02:38:50 rpg [~rpg@216.243.156.16.real-time.com] has joined #sbcl 07:41:15 sdemarre [~serge@91.176.62.153] has joined #sbcl 07:59:15 -!- homie [~levgue@xdsl-78-35-164-84.netcologne.de] has quit [Read error: Connection reset by peer] 08:00:25 homie [~levgue@xdsl-78-35-153-178.netcologne.de] has joined #sbcl 09:14:23 -!- pchrist_ [~spirit@gentoo/developer/pchrist] has quit [Ping timeout: 276 seconds] 09:21:14 -!- pers [~user@96-25-162-104.gar.clearwire-wmx.net] has quit [Ping timeout: 256 seconds] 09:37:57 nikodemus [~nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 09:37:57 -!- ChanServ has set mode +o nikodemus 09:42:08 pkhuong: re. jump elimination: would not the elimination still be safe (if performance neutral aside from code-size) if ir2-block-drop-thru-to is true? 09:47:27 -!- drdo [~drdo@85.207.54.77.rev.vodafone.pt] has quit [Remote host closed the connection] 10:11:18 pchrist [~spirit@gentoo/developer/pchrist] has joined #sbcl 10:22:54 akovalen` [~anton@95.73.221.214] has joined #sbcl 10:24:24 -!- akovalenko [~anton@95.72.170.186] has quit [Ping timeout: 240 seconds] 10:26:09 prxq [~mommer@mnhm-590c25f9.pool.mediaWays.net] has joined #sbcl 10:58:37 -!- pchrist [~spirit@gentoo/developer/pchrist] has quit [Ping timeout: 240 seconds] 11:54:03 -!- nikodemus [~nikodemus@cs181063174.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 12:03:40 nikodemus [~nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 12:03:40 -!- _8david [~user@port-92-195-81-17.dynamic.qsc.de] has quit [Ping timeout: 258 seconds] 12:03:40 -!- ChanServ has set mode +o nikodemus 12:06:14 pchrist [~spirit@gentoo/developer/pchrist] has joined #sbcl 12:09:53 -!- akovalen` is now known as akovalenko 12:24:10 -!- homie [~levgue@xdsl-78-35-153-178.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 12:29:01 lars_t_h [~lars_t_h@0132300253.0.fullrate.dk] has joined #sbcl 12:29:17 homie [~levgue@xdsl-78-35-153-178.netcologne.de] has joined #sbcl 12:29:26 -!- lars_t_h [~lars_t_h@0132300253.0.fullrate.dk] has left #sbcl 12:38:01 -!- nikodemus [~nikodemus@cs181063174.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 12:39:01 nikodemus [~nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 12:39:01 -!- ChanServ has set mode +o nikodemus 12:40:49 -!- nikodemus [~nikodemus@cs181063174.pp.htv.fi] has quit [Client Quit] 12:48:01 _8david [~user@port-92-195-81-17.dynamic.qsc.de] has joined #sbcl 12:53:54 nikodemus [~nikodemus@cs181056239.pp.htv.fi] has joined #sbcl 12:53:54 -!- ChanServ has set mode +o nikodemus 12:54:39 does anyone have tcr's current cell number? 12:54:46 Xof? 12:54:52 jsnell? 13:13:18 -!- pchrist [~spirit@gentoo/developer/pchrist] has quit [Quit: leaving] 13:13:52 pchrist [~spirit@gentoo/developer/pchrist] has joined #sbcl 13:18:40 LiamH [~healy@pool-108-45-22-54.washdc.east.verizon.net] has joined #sbcl 13:50:06 -!- antifuchs [~foobar@care.boinkor.net] has quit [Quit: ZNC - http://znc.sourceforge.net] 13:50:36 antifuchs [~foobar@care.boinkor.net] has joined #sbcl 14:03:22 -!- antifuchs [~foobar@care.boinkor.net] has quit [Ping timeout: 244 seconds] 14:03:36 antifuchs [~foobar@care.boinkor.net] has joined #sbcl 14:54:05 -!- akovalenko [~anton@95.73.221.214] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 15:06:52 akovalenko [~anton@95.73.221.214] has joined #sbcl 15:08:23 nikodemus: it would be stupid. 15:24:47 -!- danlarkin [~dan@danlarkin.org] has quit [Quit: Quit] 15:25:27 danlarkin [~dan@danlarkin.org] has joined #sbcl 15:26:56 nyef [~nyef@64.134.65.221] has joined #sbcl 15:27:01 Hello all. 15:27:17 hi nyef 15:30:41 -!- christoph_debian [~user@oteiza.siccegge.de] has quit [Ping timeout: 244 seconds] 15:31:59 Okay, I have two things ready for review, if not commit upstream. 15:32:02 First is http://repo.or.cz/w/sbcl/nyef.git/commitdiff/e67ef6e16b4193808e3862b324ee1f0ba04f1017 15:32:51 Hacks genesis and the compiler to arrange for cold-cores to have warm package names. 15:33:09 Second is http://repo.or.cz/w/sbcl/nyef.git/shortlog/refs/heads/keep-src-clean 15:34:06 Moves all build products out of src/ and into output/. 15:34:18 (Well, in theory. There might be a few I didn't find.) 15:37:46 I can't comment on the former, but I am in favor of build system cleanups 15:38:24 The build system cleanups mainly need testing on more platforms than x86-64/linux. 15:39:00 testing? that's what users are for :) 15:39:11 nyef: to encourage reviews, try putting more things looking scary and dangerous next time :) I'd dig deeper in your diffs if they didn't look so harmless. 15:39:12 Exactly! 15:39:19 I'll give it a spin on a few platforms 15:39:53 if I can remember how to add git remotes, that it 15:39:59 akovalenko: Altering the top-level form processing in the compiler, and doing semi-arbitrary string rewrites in genesis aren't scary and dangerous? 15:40:26 joshe: It's really easy. What you do is open up .git/config with a text editor... 15:40:48 nyef: not if we compare to lowtag rearrangement and fixnum width change :) 15:40:48 that's usually what I end up doing too, heh 15:41:24 akovalenko: Ah, but I had pkhuong helping with that. And it still took a while to sort out. 15:42:29 awesome. I can fix the bug, but I don't understand why I have to. 15:44:23 Wait, what bug 15:44:25 ? 15:44:49 ok, got it. Stupid xcompiler. 15:44:57 I broke the build on sparc 15:45:00 Ah. 15:45:20 Oh, the char-literals thing? 15:45:26 yup. 15:45:29 ISTR running into some variant on that on PPC. 15:45:52 I forget exactly what I did there. 15:47:42 I might have simply disabled the VOP on unicode builds. 15:53:37 nyef: base-char, iirc. 15:54:07 That'd work too. base-char is only seven or eight bits. 15:54:54 I have in mind a possible hack to allow genesis to dump literal package objects. 15:56:24 mm. so that type won't print on #!-sb-unicode builds. 15:56:35 otoh, it'll never be printed in normal operation either. 16:00:32 Hmm! I wonder if I can get the globaldb initialized in genesis? 16:02:12 Ah, damn. hash-table. 16:05:57 Does anyone know why we delay first GC until the end of cold-init? 16:06:11 layouts? 16:06:19 Hrm. 16:06:30 There's some circularity in layout-layout 16:06:41 Thought that was sorted in genesis? 16:07:58 I can maybe see that some instances might be created before their layouts are initialized, but it seems a touch dubious... 16:08:27 I know that one of the forces was that we had SAPs acting as unboxed pointers into heap space to handle load-time-value fixups, but I fixed that ages ago. 16:09:03 right, layout-layout is fixed up in genesis 16:09:21 And that force only lasted until the toplevel forms are processed... 16:10:19 ah... but it also helps debugging a lot. 16:10:28 Okay, fair point. 16:10:40 Forgot about the cold-sbcl.map for a bit there. 16:20:23 Lovely. *QUEUED-PROCLAIMS* is a rather explicit indicator that our stuff isn't loaded in dependency order. 16:28:01 Tentative proposition: Most of the !whatever-cold-init functions are indicators that our load-time dependency ordering is messed up. 16:31:36 *akovalenko* would like to have some sb-ext:*runtime-epoch*, which would be set to a new (cons nil nil) on startup, before init-hooks. Many things may be cached for a single "session" but not across dumps, and *runtime-epoch* allows some convenient idioms for invalidating such caches.. 16:33:45 akovalenko: That should actually be fairly easy to set up. 16:34:58 akovalenko: Find a place to put the DEFVAR, then set your cons in cold-init.lisp towards the top of !COLD-INIT and REINIT. 16:36:40 nyef: of course. I'm proposing API extension here, that should be eventually documented in the manual and all that :) there's no problem with implementation. The point of having it done by SBCL is to be sure that *all* init-hooks will see a new value, which would be hard if it's assigned by init-hook.. 16:37:40 nyef: for something that works, I already have *runtime-pathname* with a similar behavior, though it is not promised anywhere. 16:37:41 Right. So the only extra step is to add it to the manual. 16:39:31 the main extra step is to get you'all Western hege^H^Hmisphere hackers to _think_ of it enough to get _some_ opinion and share it where I can see it :-E 16:40:15 Honestly? If we weren't in code-freeze, and could agree on what the documentation should say, it'd be in today. 16:40:46 well, let's talk about stdcall callback syntax, which is way more important 16:40:52 It falls under the category of "stupidly obviously useful, why didn't we think of it already?" 16:42:14 That's a kind of chicken-and-egg problem for features. "If there really were $50 on the floor, somebody would pick it up by now." 16:43:03 Mmm. Fruit hanging so low, it's not worth leaving to the newbies. 16:44:23 Is *RUNTIME-EPOCH* the best name for this, or can we come up with better? 16:45:44 Of course, SB-KERNEL::*GC-EPOCH* isn't exactly a documented and supported interface either. 16:45:57 attila_lendvai [~attila_le@95.56.87.163] has joined #sbcl 16:45:57 -!- attila_lendvai [~attila_le@95.56.87.163] has quit [Changing host] 16:45:57 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 16:48:28 well, I've though about it more than several minutes, and I was unable to come up with a better name. 16:49:31 I guess it's not yet done everywhere because epoch-based caching is not what newbies do. Coming to this idea can take a year or two _after_ one learns about l-t-v. 16:49:42 Heh. 16:51:43 As of documentation, the only thing to _promise_ about the epoch is probably that it's updated to non-eq object each time, not that it's (cons nil nil) or something. 16:53:09 Yes, of course. 16:53:29 Are there any other epochs that we should be tracking? 16:53:56 maybe there are, but I need a year or two to become aware of them :) 16:54:02 Fair enough. 16:54:27 Let's have this discussion again in about a week, after the release is done. 16:55:57 yep. 16:59:39 drdo [~drdo@85.207.54.77.rev.vodafone.pt] has joined #sbcl 17:01:36 -!- sdemarre [~serge@91.176.62.153] has quit [Ping timeout: 240 seconds] 17:03:13 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has left #sbcl 17:09:10 -!- LiamH [~healy@pool-108-45-22-54.washdc.east.verizon.net] has quit [Quit: Leaving.] 17:10:50 ... I can get rid of COLD-FSET and FOP-COLD-FSET, at the price of introducing a specific hack to PROCESS-TOPLEVEL-FORM and a new VOP. 17:14:55 I'm not sure which is more interesting, being able to load warm fasls in genesis, or being about to load cold fasls normally. 17:24:19 Actually, thinking about it, I -do- know which is more interesting: being able to load warm fasls in genesis. 17:26:42 ... or not. There are some nice possibilities either way. 17:28:26 yep, both are interesting 17:30:31 There are still a few other format differences between XC fasls and target fasls, but they can be cleaned up. 17:34:56 nyef: that would be an interesting delivery option. 17:35:19 nyef: I had a proposal for generation epoch. 17:35:48 pkhuong: Uh-huh. Combine "universal" fasls with getting our load deps sorted out, and we could almost have a minimal core with little more than a fasloader in it. 17:40:42 pers [~user@96-25-162-104.gar.clearwire-wmx.net] has joined #sbcl 17:45:52 cmm [~cmm@109.67.212.191] has joined #sbcl 17:46:46 ugh, I hate building in the wrong tree by mistake 17:46:56 or in this case, on the wrong machine 18:13:37 nikodemus` [~nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 18:14:54 Oh, the other upshot of removing FOP-FSET is that the differences between cross-compiled and target-compiled functions (mostly noticable in disassembly) should disappear. 18:15:19 \o/, i think :) 18:16:31 nikodemus`: Have you had a chance to review today's logs yet? 18:21:18 which logs? 18:21:27 oh, #sbcl? 18:21:29 Yeah. 18:21:37 *nikodemus`* goes look 18:24:57 I've also got a combination of stuff that, when put together, mean the death of *in-package-init*. 18:27:16 ok, i'm caught up 18:27:32 (not that i looked at the trees you linked to, yet) 18:27:46 nikodemus`: re fall-through/trampoline, I'll probably commit something a teensy bit more aggressive soon. 18:28:11 I'm not sure I can construct a snippet on which it'll make a difference, but it can't hurt 18:28:25 ok. i was mainly asking to check my own understanding 18:29:42 nikodemus`: The tree I'm more worried about is emitting warm package names from genesis. 18:30:10 (and I'm sort of considering how could be ported to something like CL) 18:30:24 re. runtime epoch: i'm not opposed to it, but it's not obvious to me where it is superior to using *save-hooks* to blow away caches, or *init-hooks* to set them up 18:31:17 nikodemus`: Essentially, it takes effect before *init-hooks*, so all of your init hooks can do the right thing, and it saves tracking down all of the caches to invalidate them on save. 18:32:58 your caches need to either be aware of the epoch and check it, or they can use *save-hooks* to clean up on save -- in both cases the cache code needs to be written to be aware of the issue 18:33:43 nikodemus`: now, what if your caches are in a multitude of objects with indefinite lifetime? 18:34:00 which an epoch, they can be blown on-demand. 18:34:05 *with an epoch 18:34:09 fair point 18:34:35 that's the point. sometimes I cache stuff in (l-t-v ...). 18:34:48 for extra bonus, make it something like (cons (get-universal-time) (something-else-potentially-useful))? 18:35:02 akovalenko: that's not too bad. But when the caches are in closures, ... 18:35:03 no, it would better be minimal 18:35:30 nikodemus`: (cons nil (make-hash-table)). 18:35:39 blumbri [~blumbri@c-67-181-176-186.hsd1.ca.comcast.net] has joined #sbcl 18:35:39 true, otherwise people will try to use it for something 18:35:45 when we don't use weak pointers for cache keys, stale epoch values would be non-gcable indefinitely 18:36:20 actually, people can use *runtime-pathname* (and friends) as runtime epoch, as I mentioned before :) 18:36:21 akovalenko: but the epoch value itself is just a cons; both the car and cdr can be nulled out. 18:36:39 pkhuong: we're discussing my proposed *runtime-epoch*, not gc-epoch 18:36:47 akovalenko: same. 18:37:01 ah, I see 18:37:41 seems like I have things to learn even after using this stuff for a while.. 18:37:41 18:37:53 nyef: i would be happier if xof could review the genesis magic, but if he can't find the time i can dive in. there are bits there that i've never properly sorted out in my head 18:38:40 our (user-homedir-pathname) on Windows could be runtime-cacheable, btw.. 18:39:31 nikodemus`: I'm reasonably confident on the genesis changes proper, it's the hack in the compiler and the effects on all of the load-time-value find-package noise that worries me going forward. 18:40:09 does it still complain if you try to dump an SB-FOO:BAR symbol from host? 18:40:30 I believe so, but I don't think I tested that. 18:41:07 Yes, it should still complain about that. 18:41:19 The genesis changes only affect strings interned to the core. 18:42:29 btw, are sb!package names used only to prevent host SBCL packages from colliding with target ones? 18:42:46 akovalenko: Pretty much, yeah. 18:42:58 akovalenko: which is also helpful to detect host leakage. 18:44:41 You know, we could move the target-package validation to the fasdumper. 18:44:48 hmm. The first part could be done with a sbcl-specific hack... and I can see how it's helpful, but sometimes it seems that it costs too much (of developers' convenience) 18:50:50 ... oh my. I have an angle for making cold-fasls a LOT closer to warm-fasls. 18:51:30 Now, can I teach genesis about DEFPACKAGE...? 18:53:24 ... no, not quite a bright idea. 19:01:29 LiamH [~healy@pool-108-45-22-54.washdc.east.verizon.net] has joined #sbcl 19:25:17 Okay, does anything need doing before I disappear for the rest of the afternoon, and probably evening? 19:31:10 -!- nyef [~nyef@64.134.65.221] has quit [Quit: Bye all.] 20:13:39 homie` [~levgue@xdsl-78-35-137-29.netcologne.de] has joined #sbcl 20:15:48 -!- homie [~levgue@xdsl-78-35-153-178.netcologne.de] has quit [Ping timeout: 252 seconds] 20:26:51 nikodemus: (unsigned #.sb!vm:n-word-bits) is [slightly] better than unsigned-long, for L32P64 perspective. 20:47:22 akovalenko: ? 20:47:35 I mean last thing about dynamic-usage 20:47:48 the runtime uses unsigned long as the C type 20:47:51 we have 32-bit unsigned-long here on win64 20:48:08 does that match the runtime's length? 20:48:31 in my port, 64 is the runtime's length 20:49:02 remind me why the mismatch 20:49:18 this sounds familiar, but... 20:50:03 don't C people on win64 expect unsigned long to be 64 bits? 20:50:06 well, actually, in any 64-bit runtime it's 64-bit on the C side. I had to fix it for win/amd64 'cause microsoft's _long_ are 32-bit 20:50:32 nikodemus: all of them expect it when they're newbies, sure :) 20:50:37 heh 20:51:47 rewriting longs is still *the* most boring and conflict-prone thing in my entire sbcl/win experience 20:51:50 what is unsigned long under win64 in a C program that doesn't include any windows specific headers? 20:51:58 _32-bit_ 20:52:18 and LONG and ULONG are 32-bit too. 20:52:31 and what's 64? long long? 20:52:34 yep 20:52:50 int64_t is normally used for it outside GCC world. 20:53:38 it was somewhat tempting to make sb-alien:unsigned-long be 64-bit nevertheless, but I decided against it. 20:53:38 int64_t is the C99 type, iirc 20:54:01 of course, I also recall that MS doesn't want to implement C99 because they consider C obsolete 20:54:37 hm. maybe i'll let it be like it is over the release, and then add alien types unsigned-word and signed-word? 20:54:48 yep 20:56:31 "the problem with types is that there are so many to choose from" 20:58:05 btw, dynamic_space_size is simply size_t in runtime, and size_t on windows _is_ 64-bit 20:59:53 i suspect many things that are unsigned long should be size_t really 21:00:35 Finally! Someone has an opinion on a thing I asked half a year ago :-) 21:01:02 i thought i replied to that thread 21:01:09 I had an opinion on that several years ago :) 21:01:12 *akovalenko* is unsure about size_t on Alpha.. 21:01:46 ..or about _everything_ on Alpha, for that matter.. 21:01:47 wasn't there some work somewhere towards making Alpha properly 64-bit? 21:02:11 alpha... yeah. no idea 21:34:12 nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has joined #sbcl 21:36:07 Oh, lovely. 32/64 bit mismatches? 21:36:31 You might consider what happens when n-machine-word-bits is larger than n-word-bits. 21:36:38 those never get old 21:36:56 Indeed. 21:37:12 Somewhere on my list of possible problems is a 32-bit heap on 64-bit x86oid. 21:37:17 s/problems/projects/ 21:37:53 i think i've done my civic duty with launchpad now, and shall go to bed. good night o/ 21:38:10 Sleep well. 21:38:21 -!- nikodemus` [~nikodemus@cs181063174.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 22:33:10 nyef: I have some commits on top of your keep-src-clean branch which you may want 22:33:33 Oh? 22:33:44 a couple minor fixes plus a rather invasive header reshuffle which I've been meaning to do for a while 22:33:46 http://git.elsasser.org/cgit/jre/sbcl.git 22:33:53 Still with the campaign messages, I hope? 22:34:26 hah, sorry, I forgot those 22:36:02 Okay, first patch. "Fix build on non-Darwin BSD-derived systems." Why not just include $(BASE_DIR)/src/runtime/Config.whatever? 22:36:39 ldso-stubs. Oops. Good catch. 22:36:39 in the actual Config.arch-os file? 22:36:48 Yeah. 22:36:54 hm, I suppose that would be a good bit simpler 22:40:28 Include path changes I'm badly unconvinced about. 22:41:08 And one reason I'm badly unconvinced is that you added a symlink. 22:41:39 A longstanding theme of my build-system hacking efforts has been to REMOVE symlinks where possible. 22:41:52 ah, I didn't realize you were against symlinks in general 22:42:24 it seemed less disruptive to me than to move every single header 22:43:24 Actually, I can see moving the headers from src/runtime/ to src/runtime/include/runtime/ or src/include/runtime/ or similar as being beneficial. 22:43:38 We'd then have runtime/whatever.h and genesis/whatever.h. 22:43:59 More depth than that, though, and it's a bit much. 22:44:22 And, as I said, I'm still unconvinced. 22:45:10 Would lead to target/arch.h and target/lispregs.h, which wouldn't be horrible, either... 22:45:12 well, the motivation was to insure that sbcl headers can't shadow system headers with the same name 22:45:45 doing it with compiler flags didn't look easy 22:47:39 -!- prxq [~mommer@mnhm-590c25f9.pool.mediaWays.net] has quit [Quit: Leaving] 22:48:48 Mmm. I can see that. 22:58:34 Okay, I'll update with some of this stuff. 22:58:40 ... But not tonight. 23:02:20 no rush, obviously :) 23:03:14 -!- tsuru``` [~charlie@adsl-98-87-43-94.bna.bellsouth.net] has quit [Read error: Connection reset by peer] 23:03:42 tsuru``` [~charlie@adsl-74-179-250-214.bna.bellsouth.net] has joined #sbcl 23:03:45 True. We're in code freeze, after all. (-: 23:05:01 -!- Phoodus [~foo@68.107.217.139] has quit [Ping timeout: 240 seconds] 23:22:38 -!- LiamH [~healy@pool-108-45-22-54.washdc.east.verizon.net] has quit [Quit: Leaving.] 23:36:44 -!- nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has quit [Quit: G'night all.]