00:31:30 antgreen [~user@CPE0021910f07ac-CM0019477f82fc.cpe.net.cable.rogers.com] has joined #sbcl 00:36:33 LiamH [~healy@pool-74-96-16-203.washdc.east.verizon.net] has joined #sbcl 00:47:51 KDr2 [~kdr2@123.112.73.31] has joined #sbcl 01:28:08 psilord [~psilord@c-24-118-208-140.hsd1.mn.comcast.net] has joined #sbcl 01:33:43 echo-area [~user@182.92.247.2] has joined #sbcl 02:06:04 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 02:08:08 -!- ASau` [~user@128-72-117-212.broadband.corbina.ru] has quit [Read error: Connection reset by peer] 02:08:50 ASau [~user@128-72-117-212.broadband.corbina.ru] has joined #sbcl 04:08:10 -!- psilord [~psilord@c-24-118-208-140.hsd1.mn.comcast.net] has quit [Quit: Leaving.] 04:31:56 -!- LiamH [~healy@pool-74-96-16-203.washdc.east.verizon.net] has quit [Quit: Leaving.] 04:50:39 -!- DGASAU [~user@91.218.144.129] has quit [Remote host closed the connection] 04:51:14 DGASAU [~user@91.218.144.129] has joined #sbcl 04:59:31 homie` [~levgue@xdsl-78-35-175-251.netcologne.de] has joined #sbcl 05:03:28 -!- homie [~levgue@xdsl-78-35-174-200.netcologne.de] has quit [Ping timeout: 276 seconds] 05:30:46 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 276 seconds] 05:53:08 attila_lendvai [~attila_le@176.222.158.66] has joined #sbcl 05:53:08 -!- attila_lendvai [~attila_le@176.222.158.66] has quit [Changing host] 05:53:08 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 06:08:56 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 06:16:43 -!- antgreen [~user@CPE0021910f07ac-CM0019477f82fc.cpe.net.cable.rogers.com] has quit [Ping timeout: 245 seconds] 06:23:29 sdemarre [~serge@91.176.202.245] has joined #sbcl 06:36:25 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 06:44:43 gko [~gko@220.228.255.202] has joined #sbcl 06:52:25 -!- sdemarre [~serge@91.176.202.245] has quit [Ping timeout: 260 seconds] 07:21:15 mgodshall [~quassel@pool-108-36-207-226.phlapa.fios.verizon.net] has joined #sbcl 07:22:19 attila_lendvai [~attila_le@87.247.56.213] has joined #sbcl 07:22:19 -!- attila_lendvai [~attila_le@87.247.56.213] has quit [Changing host] 07:22:19 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 07:55:18 nikodemus [~nikodemus@cs181241043.pp.htv.fi] has joined #sbcl 07:55:19 -!- ChanServ has set mode +o nikodemus 07:55:33 nikodemus_phone [~androirc@87-95-244-7.bb.dnainternet.fi] has joined #sbcl 07:55:37 -!- nikodemus_phone [~androirc@87-95-244-7.bb.dnainternet.fi] has quit [Client Quit] 07:57:40 good morning 07:59:56 good morning 08:00:05 I am excited about the upcoming patchbombing 08:06:36 hopefully it lives up to expectations :) 08:06:54 apropos, do you know what seems to be taking the most time in our fasl-loading these days? 08:07:23 *allocation* of code-objects 08:16:53 wow, we must have fantastically optimized everything else 08:17:02 why haven't we taken over the world? 08:20:39 not sanctification for execution? 08:21:19 hm, given the empty function definition I guess not :) 08:23:45 (and (< num-consts #x100) (< total-length #x10000)) ... (dump-integer-as-n-bytes total-length (/ sb!vm:n-word-bytes 2) fasl-output) 08:23:51 one of these things is not like the other 08:26:12 wouldn't it be funny if the problem was something like all of our fixups being stored in a hash table and every single one of them having the same hash value 08:26:21 anyway, must work. Patch away! :) 08:32:49 -!- Kryztof [~user@81.174.155.115] has quit [Ping timeout: 252 seconds] 08:58:22 -!- homie` [~levgue@xdsl-78-35-175-251.netcologne.de] has quit [Read error: Connection reset by peer] 08:59:03 homie` [~levgue@xdsl-78-35-175-251.netcologne.de] has joined #sbcl 09:01:35 -!- homie` [~levgue@xdsl-78-35-175-251.netcologne.de] has quit [Remote host closed the connection] 09:03:04 homie [~levgue@xdsl-78-35-175-251.netcologne.de] has joined #sbcl 09:06:35 nikodemus: hi 09:09:05 hi 09:10:01 why generate-version.sh doesn't work for me 09:10:17 are your the expert to discuss this? 09:10:22 with 09:11:43 it generates wrong version.lisp-expr 09:12:11 at least it doesn't work if i check out some older commit and work from there 09:12:56 why don't we use simple git describe --tags --match 'sbcl*' ? 09:15:24 hlavaty: i don't have time to dig in right now 09:15:44 please post details to sbcl-devel or launchpad 09:15:50 ok 09:15:58 your git version, what it generates, etc. more is better 09:16:28 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 260 seconds] 09:17:43 but re. why: the amount of time and confusion that the branch marker in the version name saves for me at least is substantial 09:22:04 -!- KDr2 [~kdr2@123.112.73.31] has quit [Remote host closed the connection] 09:25:29 attila_lendvai [~attila_le@87.247.13.15] has joined #sbcl 09:25:29 -!- attila_lendvai [~attila_le@87.247.13.15] has quit [Changing host] 09:25:29 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 09:47:49 christop` [~user@oteiza.siccegge.de] has joined #sbcl 09:49:08 -!- christoph_debian [~user@oteiza.siccegge.de] has quit [Ping timeout: 260 seconds] 09:59:17 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 248 seconds] 10:16:20 nikodemus: i think you fixed the issue i am seeing in 1ae15ca163c85f5bce5fdfca5fa73af39ee7ffaa so no need for report. unfortunatelly, i can't rely on generate-version.sh while reviving autobench :-( or i just skip the broken versions ;-) 10:18:06 hlavaty: have autobench copy the new version over? 10:18:58 what do you mean? 10:19:41 hlavaty: have autobench replace broken versions of generate-version.sh with the fixed one 10:20:06 ah, ok another option 10:20:08 or just generate version.lisp-expr using data it has at it's disposal otherwise 10:20:20 its, even 10:21:23 yes thats what i did, but there is another place in autobench where this comes to play, so i need to fix that too or just skip the versions, i'll see 10:22:01 ok 10:22:11 much kudos for looking after autobench! 10:23:13 nikodemus: please signal when you're done committing stuff, so that i can commit mine without interference 10:24:24 stassats`: i have one batch of runtime cleanups coming up, then i'm done for the afternoon 10:25:10 but they're all in src/runtime/, so if you're not working there, it's a non-issue 10:25:49 i'd wait, there's no hurry 10:25:55 ok. running tests now 10:30:08 -!- echo-area [~user@182.92.247.2] has quit [Read error: Connection reset by peer] 10:59:56 Kryztof [~user@81.174.155.115] has joined #sbcl 10:59:56 -!- ChanServ has set mode +o Kryztof 11:04:33 stassats`: done 11:04:50 good 11:07:12 for all you WAIT-FOR haters: turns out it's pretty damn convenient for enforcing order of events in threaded tests. the code is both easier to read and write than explicit synchronization would be 11:07:31 and "more correct" to boot 11:09:04 (wait-for (eq mutex (sb-thread::thread-waiting-for thread)) is correct. (wait-on-semaphore thread-waiting-on-mutex) + (signal-semaphore thread-waiting-on-mutex) (with-mutex (mutex) ...) is racy 11:15:38 -!- nikodemus [~nikodemus@cs181241043.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 11:20:28 *stassats`* complains that tests take too much time to complete 11:20:47 didn't somebody do something about concurrizing tests? 11:31:04 -!- christop` is now known as christoph` 11:31:17 -!- christoph` is now known as christoph_debian 11:33:26 pprint.lisp could use proper-list-of-length 11:39:27 nikodemus [~nikodemus@cs181241043.pp.htv.fi] has joined #sbcl 11:39:27 -!- ChanServ has set mode +o nikodemus 11:40:01 saschakb [~saschakb@p4FEA07AC.dip0.t-ipconnect.de] has joined #sbcl 11:54:20 should i specify lp# in the commit message if i filed a bug report just so that i don't lose a patch? 11:54:41 doesn't hurt 11:55:04 forgot to do that for the last two commits 11:55:25 no biggie, imo 11:55:43 i just try to do it always so i don't forget it when it matters :) 11:56:23 yeah, i think it's useful when someone tries to find where was this "fix committed" 11:56:30 will do for the third one 11:57:12 i also like to add the commit message to the bug when i change the status to fix committed 11:57:35 automating that would be pretty neat, actually 11:57:47 i wish it was possible to somehow au.. what you said 11:58:19 with cross-references and all 11:58:47 still, git rebase -i is such a time-saver that i don't mind sprinkling some of those saved minutes to manual copy-pasting 11:59:11 also, a hot tip: 11:59:13 > cat .gitattributes 11:59:13 NEWS merge=union 11:59:25 what does that do? 11:59:55 when there's a conflict in NEWS, it tells git to use both changesets without considering it a conflict 12:00:44 still requires manual supervision, and can produce amusing nonsense, but makes rebase -i and patch-reordering while having stuff in NEWS less painful 12:01:17 i still tend to do NEWS pretty late before the final push, but that helps a bit 12:06:49 *stassats`* just added sha1 to bugs 12:10:55 alright, pushed all of my 3 pending commits 12:11:43 *stassats`* waits for more simple bugs to accrue 12:13:22 do you want some of mine? :) 12:13:47 depends on how simple they are 12:14:12 https://bugs.launchpad.net/sbcl/+bug/958931 # trivial :) 12:14:23 edgar-rft [~user@HSI-KBW-078-043-123-191.hsi4.kabel-badenwuerttemberg.de] has joined #sbcl 12:14:42 that's too boring 12:14:47 https://bugs.launchpad.net/sbcl/+bug/936513 # haven't looked in detail, but should be simple 12:15:06 that's more interesting 12:15:37 hm. i think you did this one already? https://bugs.launchpad.net/sbcl/+bug/904818 12:17:12 Xof_ committed it 12:18:52 there should be locks on bugs or something! 12:20:11 nikodemus: you beat my by whole 7 seconds with pasting the commit message 12:20:20 hah 12:24:02 bloody launchpad broken in Opera 12:28:14 *stassats`* marked remaining things as released, 496 bugs to go 12:29:40 heroic KLUDGE to get debugging output without breaking cold init: (when (boundp '*handler-clusters*) (ignore-errors ...print stuff...)) 12:40:09 -!- Kryztof [~user@81.174.155.115] has quit [Read error: Operation timed out] 12:44:17 Kryztof [~user@81.174.155.115] has joined #sbcl 12:44:17 -!- ChanServ has set mode +o Kryztof 12:44:53 Part of my release script outputted a mail body which could be sent to launchpad to mark all the bugs fixed (from parsing news) in that release as Fix Released 12:47:51 it's still output, but I don't do anything with it 12:51:48 maybe in my glorious future of leisure I can take over duties again 12:59:17 whee! i found the sbcl tree with all those old branches i've been missing o/ 13:05:59 -!- slyrus [~chatzilla@12.132.197.125] has quit [Ping timeout: 252 seconds] 13:09:09 -!- gko [~gko@220.228.255.202] has quit [Ping timeout: 248 seconds] 13:18:14 bad: that wasn't actually the tree i was looking for. good: i found another tree with tons of branches, which might be the one... 13:20:02 so... 13:20:06 froydnj [nfroyd@people.mozilla.com] has joined #sbcl 13:20:27 I had forgotten that sbcl actually had its own channel :) 13:20:39 one thing i think we should do, is have a list of commitments. "i'm looking after platform x, and build option y" 13:20:48 or "adoptions" 13:21:21 whatever. point being, if there's something no-one is willing to spend time on, we should be upfront about it 13:21:58 hppa ? 13:22:27 i don't think anyone expects it to be actively maintained, but yes, we should be upfront about its status 13:23:22 also: split responsibility between "will actively test", "willing to fix regressions when they're reported" for minority platforms 13:25:09 eg, i'm not going to spend time regularly testing PPC, but if someone reports a regression during freeze i'm happy to dive in 13:26:43 -!- scymtym [~user@2001:638:504:2093:21a:a0ff:fe34:2d7d] has quit [Read error: Connection reset by peer] 13:36:51 no. still not the tree i'm looking for :/ 13:51:35 psilord [~psilord@23-25-144-217-static.hfc.comcastbusiness.net] has joined #sbcl 14:08:50 *stassats`* will actively test platform ARM 14:09:01 android-ARM, that is 14:17:17 need arm port first =/ 14:17:20 scymtym [~user@2001:638:504:2093:21a:a0ff:fe34:2d7d] has joined #sbcl 14:21:38 "no regressions this month on ARM: still doesn't build!" 14:22:38 attila_lendvai [~attila_le@176.222.148.102] has joined #sbcl 14:22:38 -!- attila_lendvai [~attila_le@176.222.148.102] has quit [Changing host] 14:22:38 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 14:33:59 -!- specbot [~specbot@pppoe.178-66-71-77.dynamic.avangarddsl.ru] has quit [Ping timeout: 244 seconds] 14:34:35 -!- stassats` [~stassats@wikipedia/stassats] has quit [Ping timeout: 246 seconds] 14:40:35 gko [~gko@114-34-168-13.HINET-IP.hinet.net] has joined #sbcl 14:49:35 stassats [~stassats@wikipedia/stassats] has joined #sbcl 14:50:15 specbot [~specbot@pppoe.178-66-29-116.dynamic.avangarddsl.ru] has joined #sbcl 14:51:59 kanru` [~user@61-228-149-181.dynamic.hinet.net] has joined #sbcl 15:04:06 slyrus [~chatzilla@66-140-241-100.ded.swbell.net] has joined #sbcl 15:09:34 -!- slyrus [~chatzilla@66-140-241-100.ded.swbell.net] has quit [Ping timeout: 272 seconds] 15:10:15 leuler [~user@p54903F9D.dip.t-dialin.net] has joined #sbcl 15:11:42 rpg [~rpg@216.243.156.16.real-time.com] has joined #sbcl 15:13:10 Hi everybody. Nice that we are out of the long freeze! 15:13:39 Hi. 15:14:13 Quick question: is there some way to control source file recording in SBCL? Have DSL that is being processed in Lisp, so that I know the source files, but SBCL doesn't. 15:17:23 I'm not sure what you mean 15:22:17 rpg: we don't have a nice exported API, but if you take a gander at how eg. DEFUN expands, you should be able to utilize the internal mechanism 15:25:18 -!- stassats [~stassats@wikipedia/stassats] has quit [Remote host closed the connection] 15:25:18 -!- specbot [~specbot@pppoe.178-66-29-116.dynamic.avangarddsl.ru] has quit [Remote host closed the connection] 15:26:19 stassats [~stassats@wikipedia/stassats] has joined #sbcl 15:26:35 nikodemus: thanks. 15:26:57 Kryztof: Some things are made by consing forms and then EVALing them. 15:27:08 *rpg* hastens to add that this wasn't his idea, and it's not his code 15:30:04 Regarding https://bugs.launchpad.net/sbcl/+bug/958931: What's the general policy in SBCL regarding whitespace/comment corrections? I know some other software projects object to whitespace/comment-cleaning-only-commits as it forces more rebasing work onto folks wanting to do "real" changes in the same places. I ask because I have collected lots of typo fixes myself that I'd like to apply some time. 15:31:28 leuler: I'm fine with cleanups occasionally. A good time is probably about one week into a development cycle, after all the held-over patches have landed 15:31:30 nikodemus: ah. Looks like binding sb-c::*source-namestring* is the right solution, yes? 15:35:11 nikodemus: should I try to make sure I don't pass *SOURCE-PLIST* in? Seems like that might be in an odd state if I make-definition-source-location inside EVAL... 15:37:37 slyrus [~chatzilla@97.72.227.80] has joined #sbcl 15:41:37 wait, actually we have hald an api 15:42:29 rpg: (with-compilation-unit (:source-namestring "foo.not-common-lisp") ...) 15:42:54 nikodemus: Oh, great. I can make that happen. 15:43:21 So calling EVAL in there will see the right context from WITH-COMPILATION-UNIT? 15:43:42 :source-plist allows you to add extra information which sbcl doesn't deal with at all, but which you can access via sb-introspect 15:44:14 EVAL is tricky: it depends on if it actually has to go through the compiler 15:44:33 but (with-compilation-unit (...) (compile nil `(lambda ...))) should do the right thing for sure 15:45:28 nikodemus: thanks. I don't know exactly why my colleague decided to use EVAL instead of COMPILE... 15:45:49 adding more accurate location information requires unsupported magic 15:46:10 but you can stick that in the :source-plist and utilize it yourself 15:46:18 sbcl just won't know about it 15:48:34 OK, thanks. I see --- most of the code that he's translating is DEFCLASS. I suppose ENSURE-CLASS might have been an alternative. But it doesn't seem like we can call COMPILE on a class definition. 15:49:31 no, eval is right thing to use there 15:49:38 for classes... let me see 15:50:34 looks like w-c-u and :source-namestring should do the right thing there 15:50:52 -!- les [~les@unaffiliated/les] has quit [Ping timeout: 252 seconds] 15:50:54 nikodemus: that is great. thank you so much... 15:52:31 will the support of hppa be ever revived? 15:52:49 if not, maybe it'd be good to remove its code from the tree? 15:53:39 there are arguments for keeping it, but i'm not the right person to speak them, as i'm not particularly convinced myself... 15:54:29 HP stops supporting HPPA in 2013 16:08:57 -!- slyrus [~chatzilla@97.72.227.80] has quit [Ping timeout: 265 seconds] 16:10:01 Phoodus [~foo@wsip-68-107-217-139.ph.ph.cox.net] has joined #sbcl 16:12:07 nikodemus: If you indeed want to get rid of lp 958931, I take it and will commit that and my collected typo fixes in a week or so. 16:12:45 specbot [~specbot@pppoe.178-66-29-116.dynamic.avangarddsl.ru] has joined #sbcl 16:12:50 take it away :) 16:12:55 lp 958931 16:12:55 https://bugs.launchpad.net/bugs/958931 16:13:52 stassats: The one you found too boring earlier. 16:14:01 yeah 16:14:20 so boring i didn't remember its number 16:14:32 (not that i ever do) 16:19:39 slyrus [~chatzilla@97.72.227.80] has joined #sbcl 16:25:24 les [~les@lesharris.com] has joined #sbcl 16:25:25 -!- les [~les@lesharris.com] has quit [Changing host] 16:25:25 les [~les@unaffiliated/les] has joined #sbcl 16:36:30 -!- gko [~gko@114-34-168-13.HINET-IP.hinet.net] has quit [Ping timeout: 265 seconds] 16:42:29 dtw [~dtw@pdpc/supporter/active/dtw] has joined #sbcl 16:44:37 *nikodemus* is amused that we have more commits coming out of the freeze than during the past 3 months 16:45:05 well, a lot of them accumulated during the prolonged freeze 16:48:24 so, what's the status on sb-int:proper-list-of-length-p? 16:49:06 i don't think a deftransform is needed, since it's insignificantly faster 16:51:18 i've done nothing since i emailed you mine 16:51:33 I'm done 16:51:41 wake me next spring 16:51:56 back into the vortex? 16:54:57 -!- saschakb [~saschakb@p4FEA07AC.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer] 16:56:54 Kryztof: re: (eval `(trace ,(intern (format nil "ASH-LEFT-MOD~D" sb-vm::n-word-bits) "SB-VM"))) 16:57:51 didn't the stuff in compiler-test-utils.lisp, eg ctu:find-named-callees, work for you? 16:59:38 -!- slyrus [~chatzilla@97.72.227.80] has quit [Read error: Connection reset by peer] 17:05:46 -!- nikodemus [~nikodemus@cs181241043.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 17:06:03 you've gone. But I didn't get that far 17:07:37 no-one suggested that, among all the insane things that they in fact did suggest. ("grep the disassembly") 17:07:53 but that's the simplest way! 17:08:50 however, sb-introspect:find-function-callees is easier 17:10:16 find-named-callees appears to be basically the same 17:14:06 slyrus [~chatzilla@97.72.227.80] has joined #sbcl 17:15:13 nikodemus [~nikodemus@cs181241043.pp.htv.fi] has joined #sbcl 17:15:13 -!- ChanServ has set mode +o nikodemus 17:18:09 homie` [~levgue@xdsl-78-35-151-245.netcologne.de] has joined #sbcl 17:21:28 -!- homie [~levgue@xdsl-78-35-175-251.netcologne.de] has quit [Ping timeout: 265 seconds] 17:21:53 i guess i have to set up windows compilation environment to test the other run-program patch, although i could just patch the image 17:26:13 "surely this cannot break the build! inconceivable!" 17:27:01 actually, "assuming something cannot break the build" ranks right there with "land war in asia" on the list of classic mistakes :) 17:28:49 i wish sbcl didn't need a c compiler to compile itself 17:29:24 "i know, i'll write a c compiler in lisp" 17:30:13 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 17:30:54 vacietis? 17:31:09 -!- nikodemus [~nikodemus@cs181241043.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 17:34:31 sdemarre [~serge@91.176.202.245] has joined #sbcl 17:46:55 -!- rpg [~rpg@216.243.156.16.real-time.com] has quit [Quit: rpg] 17:59:00 -!- slyrus [~chatzilla@97.72.227.80] has quit [Read error: Connection reset by peer] 18:02:27 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 18:10:09 froydnj: how micro are those microoptimizations? 18:11:38 stassats: the allocation one saves ~100K of core; I didn't measure the other two 18:14:24 http://paste.lisp.org/display/128545 is still not committed 18:14:53 froydnj: you like microoptimizations, maybe you will look at it if pkhuong can't? 18:16:25 what's the goodness there? it's not immediately obvious to me 18:17:34 oh, fixnum indices where appropriate 18:17:35 ? 18:18:04 it uses effective address to unbox fixnum indices, instead of a shift 18:18:26 yeah, that would be an improvement 18:18:49 though making it continue to work for the n-fixnum-tag-bits != case...could be done, I think 18:18:59 it saves some core and is slightly faster 18:19:04 n-fixnum-tag-bits != 1, that is 18:19:43 -!- angavrilov [~angavrilo@217.71.227.190] has quit [Ping timeout: 276 seconds] 18:20:14 I had a fantasy the other shower of messing with the array representation so that the specialized information was cleverly encoded in the header, rather than in the widetag 18:20:49 what would that imply? 18:20:59 in particular I wondered whether with a clever encoding the bits per element could be encoded as a field in the header, so that all array accesses actually emit the same code 18:21:08 or nearly the same code 18:21:20 it was probably a pessimization in all respects except for widetag space 18:22:23 I was really thinking about it for base-string/string issues -- whether you could usefully encode "this base-string or string has never had a non-ascii character in it" so that it could be printed much faster in most external formats 18:22:36 but then my shower finished :) 18:23:18 *froydnj* writes a grant proposal for a tankless water heater for Kryztof 18:23:44 crowd-funding? 18:23:55 I'm surprised we touch 2/4-byte element-type arrays enough in core for it to matter that much 18:24:25 froydnj: strings? 18:24:45 oh, duh, yes 18:25:01 i don't know the actual core savings, it was 65536 bytes 18:25:23 because it allocates core by 65536 blocks, i assume 18:25:42 *froydnj* wishes that integer type checking didn't suck so much 18:25:43 maybe it was just small enough to align it to the other block 18:26:34 According to my experience core size varies by multiples of 4 KiB (page size). 18:26:35 and integer type checking + array bounds checking 18:27:13 oh it finished because one or other of the children needed attention 18:28:38 in 17 years' time or so I can have long showers again. (I believe there's a period in between where the shower is persistently unavailable -- maybe we need a "bigger house" grant proposal :-) 18:28:58 Isn't water rationed in britain currently anyway? 18:39:49 saschakb [~saschakb@p4FEA07AC.dip0.t-ipconnect.de] has joined #sbcl 18:46:20 it would be pretty awesome to store strings in a small representation and transparently reallocate them upon mutation if necessary. 18:46:57 it's pretty wasteful to use 4 bytes / char for ascii strings. 18:48:11 I think some scheme implementation does that already, doesn't it? 18:48:46 yea 18:48:55 python just implemented it too, I believe. 18:49:45 http://www.python.org/dev/peps/pep-0393/ 18:50:25 their implementation was rather constrained by the need to keep compatibility with existing C extensions. 18:50:35 (source compat, not binary compat) 18:51:07 but, python has immutable strings. :) 18:51:27 and doesn't scheme, too? 18:51:38 -!- dtw [~dtw@pdpc/supporter/active/dtw] has quit [Quit: Zzzzz] 19:04:04 -!- psilord [~psilord@23-25-144-217-static.hfc.comcastbusiness.net] has quit [Quit: Leaving.] 19:09:56 -!- saschakb [~saschakb@p4FEA07AC.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 19:14:43 foom: but ascii strings use 1 byte on sbcl 19:24:16 -!- specbot [~specbot@pppoe.178-66-29-116.dynamic.avangarddsl.ru] has quit [Ping timeout: 252 seconds] 19:24:51 specbot [~specbot@pppoe.178-66-29-116.dynamic.avangarddsl.ru] has joined #sbcl 19:27:00 stassats: but in sb-unicode builds, "foom" uses ~20 bytes, not ~8 19:27:16 (and for symbol names too) 19:27:38 simple-base-strings use 8 bytes regardless of sb-unicode 19:28:11 no argument there 19:28:58 but the reader produces simple-strings, even when it could produce simple-base-strings 19:29:44 yes, it can't know ahead of time whether it will encounter only ascii characters 19:30:13 although it can't know the length too 19:30:22 *stassats* goes to see what it actually does 19:31:08 slyrus [~chatzilla@184.169.40.209] has joined #sbcl 19:31:59 it does know the length in advance. 19:44:50 http://paste.lisp.org/display/128944 here's a patch which reads strings into simple-base-strings when possible 19:45:24 Didn't someone try a patch like that before, and it broke stuff? 19:45:42 didn't try rebuilding with it yet 19:47:52 I believe it broke something that used copy-seq on a symbol or constant string, and assumes it'll end up with not a simple-base-string? 19:50:02 stassats: I tried pkhuong's paste and didn't see any core file size reduction, but I agree it is an improvement 19:55:00 -!- specbot [~specbot@pppoe.178-66-29-116.dynamic.avangarddsl.ru] has quit [Remote host closed the connection] 20:02:11 clisp has a multiple-header-word string implementation; downside: extra indirection on access 20:03:09 foom: built everything fine, and ran some of my code fine, but have some test failures, perhaps they're just bad tests 20:03:11 I've tended to veto patches which make "foo" change its specialized type based on the contents 20:03:36 the thing that typically goes wrong is a failure to make print/read consistency and print-not-readable right, but I think it's just generally not nice 20:04:12 "veto". Obviously I can't actually do that 20:07:39 stassats: I will probably push the patch this weekend-ish 20:07:51 good 20:11:39 bloody oom killer 20:11:44 killed several sbcls 20:12:12 -!- slyrus [~chatzilla@184.169.40.209] has quit [Read error: Connection reset by peer] 20:26:33 just mark their oom score as -1000 so it doesn't kill 'em until it kills everything else on the box first 20:27:46 -!- sdemarre [~serge@91.176.202.245] has quit [Ping timeout: 276 seconds] 20:42:22 i see the problem with strings, but what about symbols? 20:44:30 we already `compress' symbols during (most of) the sbcl build, I think 20:44:56 yes, but what about other symbols? 20:45:21 I'd be interested to know the effect of base-stringifying symbol names on things like fasl file size or even core size (since PCL symbols probably don't get compressed) 20:54:19 Actually, I had looked at how many symbol names in the sbcl core are base strings a while ago. Most are not base strings. It seems only the ones compiled in the first phase of the build are base strings and all the rest are not. I may have not kept the results of my investigation, but will search. 20:55:57 that sounds right 20:56:27 except for the "most" part -- I would have expected that most symbols would be base strings, at least in the vanilla sbcl.core 20:56:43 xemacs in hexl mode shows strings of 4-byte-characters in a very easy spottable pattern, and paging through a core file this way shows lots of such strings. 20:56:44 there are probably a fair number of internal SB-PCL symbols which aren't 20:57:01 I am fairly sure it aren't only the pcl symbols. 20:57:05 hm 20:57:52 Take a look at the cold core. 20:58:29 alright, building sbcl with basifying symbols 21:00:35 I see things like method-fun and copy-structure-object, but most other things are base-strings 21:00:52 in hexl-mode, searching for [A-Z]\.\.\.[A-Z]\.\.\.[A-Z]\.\.\. 21:02:06 looking again myself ... 21:02:09 basically, I expect anything that's an internal symbol built in make-target-2 (i.e. freshly created) to be a 32-bit string 21:02:16 no dice, internal error #34 (invalid array index) 21:02:18 but everything else to be 8-bit 21:02:45 stassats: congratulations, now you get to learn how to debug cold-init! 21:03:37 can i do something more than just look at the backtrace? 21:03:49 think very hard? 21:03:59 antgreen [user@nat/redhat/x-iwjaxlxcadsgfwcr] has joined #sbcl 21:03:59 building with sb-show often helps 21:04:00 well, backtrace is very clear 21:04:13 i just though there may be something more to learn 21:04:15 what!? cold-init debugging has become easier since my day 21:04:40 oh, it's warm-init 21:04:57 well, I'll go to bed then 21:05:57 just s/to/below/ in loop 21:06:44 It seems I misremembered. Sorry, Kryztof. You are right, it's only pcl. 21:07:12 3 and a half painful minutes of waiting for SBCL to build 21:12:29 stassats: What I do to get faster builds (half a minute here) is using a specially compiled sbcl as the host compiler: In make-host2.lisp set safety to 0. 21:12:53 half a minute less, that is, obviously. 21:13:02 i was all excited 21:13:07 and you ruined it! 21:13:15 Apologies. 21:13:41 we'd have for intel to bring under a minute builds into reality 21:13:47 have to wait 21:14:21 or put unreasonable amounts of work into parallelizing the build 21:14:43 low hanging fruit is paralyzing contribs 21:15:19 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 21:16:22 -!- antgreen [user@nat/redhat/x-iwjaxlxcadsgfwcr] has quit [Remote host closed the connection] 21:17:21 *stassats* did something wrong when testing and cores are exactly the same 21:17:28 don't want to recompile everything again, later 22:26:46 -!- leuler [~user@p54903F9D.dip.t-dialin.net] has quit [Quit: ERC Version 5.1.2 $Revision: 1.796.2.6 $ (IRC client for Emacs)] 22:40:36 specbot [~specbot@pppoe.178-66-29-116.dynamic.avangarddsl.ru] has joined #sbcl 23:01:14 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 23:29:49 -!- stassats` [~stassats@wikipedia/stassats] has quit [Remote host closed the connection] 23:30:31 stassats` [~stassats@wikipedia/stassats] has joined #sbcl