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