00:52:51 -!- christoph_debian [christoph@sf-ogame.de] has quit [Remote host closed the connection] 01:29:50 -!- nyef [~nyef@pool-70-20-44-124.man.east.myfairpoint.net] has quit [Quit: G'night all.] 02:42:13 grumps [~user@c-71-194-138-249.hsd1.il.comcast.net] has joined #sbcl 02:45:57 homie` [~user@xdsl-78-34-200-160.netcologne.de] has joined #sbcl 02:48:38 -!- homie [~user@xdsl-78-34-205-84.netcologne.de] has quit [Ping timeout: 264 seconds] 03:09:22 -!- grumps [~user@c-71-194-138-249.hsd1.il.comcast.net] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 04:02:25 tux7 [~tux@bzq-109-64-3-14.red.bezeqint.net] has joined #sbcl 04:04:29 new online community www.blitzpost.com (email, blog, chat, photos..) 04:07:42 -!- tux7 [~tux@bzq-109-64-3-14.red.bezeqint.net] has left #sbcl 05:10:38 -!- homie` [~user@xdsl-78-34-200-160.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 05:27:53 homie [~user@xdsl-78-34-200-160.netcologne.de] has joined #sbcl 06:21:53 stassats [~stassats@wikipedia/stassats] has joined #sbcl 06:39:17 pocket_ [~pocket_@p4252-ipbf3210hodogaya.kanagawa.ocn.ne.jp] has joined #sbcl 06:40:06 -!- pocket_ [~pocket_@p4252-ipbf3210hodogaya.kanagawa.ocn.ne.jp] has left #sbcl 07:12:30 -!- cmm [~cmm@bzq-79-182-202-208.red.bezeqint.net] has quit [Ping timeout: 260 seconds] 07:13:09 cmm [~cmm@bzq-79-182-202-208.red.bezeqint.net] has joined #sbcl 07:25:22 i don't get it, why does my cvs version of sbcl not build the contribs ? 07:25:30 is it too recent ? 07:25:37 version is 1.0.44 07:25:49 yet the git version is 43.82 07:26:07 and it builds all the contribs, at least they are generated 07:27:36 "you are doing it wrong" 07:28:11 ? in what way ? 07:28:49 how do i know, you don't provide any details 07:31:21 i checkout the source, go in there, do a sh make.sh --prefix=/usr --xc-host='sbcl --no-sysinit --no-userinit 07:31:21 --sysinit /dev/null --userinit /dev/null' then a sh run-test.sh in the test dir then a doc/manual make, then sh 07:31:21 install.sh --prefix=/usr in all cases, the cvs version fails the contribs telling me contribs didn't met the test 07:31:24 requirements, the git version builds them, and yet the 43.tar.gz version is even building them too and copying over 07:37:58 <`3b`> git should be 1.0.44 too, but nothing changed since .43.82 that should break anything 07:38:20 ok 07:38:49 <`3b`> if you cvs a new checkout into a new dir? 07:39:03 <`3b`> *is your cvs... 07:39:26 yes yes, it's not cvs in git or git in cvs dir 07:39:42 <`3b`> i meant more cvs into old cvs dir 07:39:55 <`3b`> but if it is a fresh checkout, it should be OK 07:40:08 no i just clean.sh, then do a cvs update in my cvs folder always 07:40:28 that way nothing remains from the old builds 07:40:37 <`3b`> might ask cvs if there are any files it doesn't know about, or that it thinks are changed 07:41:12 i think, just that some script in the cvs version don't work the way they should, maybe it's intentional 07:41:29 cause they just work on the core maybe 07:41:39 why is your --xc-host has all these options? 07:41:41 <`3b`> well, they should be the same scripts in th egit checkout 07:42:15 don't know then really, one builds the contrib the other fails everytime 07:42:43 well, the only build succeeding in the cvs version is sb-executable asdf and sb-sprof 07:42:55 i mean from the contribs 07:43:02 <`3b`> same machine, same paths, same environment, etc? 07:43:18 same machine, same paths, same environments 07:45:57 i pulled new perl libs into /usr/local with cpan, but then i build as root always so i removed all links to 07:45:57 /usr/local stuff from root's path 07:46:14 so that it is not affected in any way 07:46:19 from new libs or so 07:46:28 or some other weird interference... 07:46:31 <`3b`> well, if it isn't related to the strange --xc-host options, next step is read the build logs in output/building-contrib* and see how they are failing 07:46:39 ok 07:47:06 <`3b`> building as root seems like an odd thing to do 07:47:34 it is the same behaviour when building as normal user too, i tested 07:47:54 i will look into the logs yes 07:48:01 <`3b`> tested in a separate dir i assume, not one owned by root? 07:49:19 well initially the checkout was as normal user so the checkout dirs contents are all user owned, but building as 07:49:19 user changes some files ownership in the dirs, but before the final install steps i revert them all to the normal user 07:49:19 so there should be no problems with it 07:49:26 <`3b`> checking logs is probably better than my random guessing though :) 07:49:34 yep 07:49:36 i'll do 07:58:31 cmpitg [~cmpitg@210.245.54.125] has joined #sbcl 08:00:55 ok found 08:04:49 http://pastie.org/1276672 08:06:17 and the others are alike that one 08:08:03 -!- cmpitg [~cmpitg@210.245.54.125] has left #sbcl 08:08:08 <`3b`> contrib/sb-aclrepl/sb-aclrepl.asd (and parent directories) exists and has reasonable permissions? 08:09:58 yes they are there in both cvs and the git versions with same ownership etc... 08:12:34 http://pastie.org/1276677 08:12:55 huuups 08:13:07 two times the GIT version pasted sorry, i'm correcting 08:15:04 yep the cvs version seems not checkout cleanly or so 08:15:09 http://pastie.org/1276677 08:15:31 or wait no 08:15:50 they are there, just not compiled... 08:18:24 <`3b`> maybe verify that contrib/asdf/asdf.lisp is the same between both? 08:23:02 diff shows no output, means they are the same 08:23:18 and even diff -y suggests they are really the same 08:24:08 couldn't paste the two sided diff, bigger than 100kb 08:24:39 <`3b`> hmm, maybe sh ./run-sbcl.sh in each dir, and compare output of (logical-pathname-translations "SYS") 08:25:06 <`3b`> in particular the part about SYS:CONTRIB 08:28:18 ok the git version is giving something back with that function, the cvs version does just fails with undefined function 08:28:47 wait wait no 08:28:49 it does not fail 08:29:21 (logical-pathname-translations "SYS") 08:29:21 08:29:21 (("SYS:SRC;**;*.*.*" #P"/mnt/sources/sources/CVS/sbcl/src/**/*.*") 08:29:21 ("SYS:CONTRIB;**;*.*.*" #P"/mnt/sources/sources/CVS/sbcl/contrib/**/*.*") 08:29:24 ("SYS:OUTPUT;**;*.*.*" #P"/mnt/sources/sources/CVS/sbcl/output/**/*.*")) 08:29:27 * 08:29:35 it is there too 08:30:23 <`3b`> maybe also try running sbcl with the command from that failed contrib log (except the --eval and --load options) 08:30:36 <`3b`> and evaluate the same form there 08:31:02 <`3b`> and check for an SBCL_HOME environment variable 08:38:42 done, the forms give the same pathnames as above wrt to CVS and GIT folder of course 08:38:57 and how do you check the SBCL_HOME env variable, from within lisp ? 08:42:40 http://pastie.org/1276697 08:42:53 removed all eval and load things 08:47:46 <`3b`> checking env var from shell should be enough 08:48:24 err, i don't have it set! 08:48:33 why should that matter ? 08:49:02 <`3b`> not being set is ok 08:49:09 ah ok 08:49:30 <`3b`> ah, that last paste looks wrong 08:49:50 <`3b`> and actually the stuff pasted in channel as well 08:50:10 <`3b`> what does the pathname-translation stuff look like from the git checkout? 08:50:33 the same with just CVS substitued for GIT in all cases 08:51:09 <`3b`> #P"/mnt/sources/sources/ note /mnt/sourceS/ while the shell says /mnt/source/ 08:51:21 <`3b`> is that true for the git as well? 08:53:01 look again, i pasted the output from the git version aswell http://pastie.org/1276697 08:53:34 <`3b`> hmm, i guess so... 08:53:51 <`3b`> does /mnt/sources/sources/CVS/sbcl/contrib/ exist? 08:53:59 yes, in one case i was just in the contrib/sb-aclrepl folder that's all 08:54:02 there is no diff 08:54:07 <`3b`> or with GIT in place of CVS 08:54:19 yes yes they all exist 08:54:43 i already showed http://pastie.org/1276677 08:54:43 <`3b`> so you have /mnt/source/ and /mnt/sources/ ? 08:54:56 no i have /mnt/source/sources 08:54:57 <`3b`> that is /mnt/source/ 08:55:09 GIT and CVS being subfolders there 08:55:18 <`3b`> right, those pathname translations have /mnt/sources/sources/ 08:55:38 <`3b`> no idea why it would work in the GIT version though 08:55:47 oh man you are right, now i see 08:55:54 but it's the case for both actually! 08:55:59 git and cvs 08:55:59 <`3b`> right 08:56:58 oh wait, i found out 08:57:10 i have a /mnt/source link to /mnt/source/sources 08:57:23 the first is a symbolink link to the latter 08:57:34 err 08:57:42 i have a /mnt/source linke to /mnt/sources 08:57:43 sorry 08:58:16 so in /mnt i have one symlink 08:58:34 and the pathname just takes the hardpath 08:58:51 so it is actually true to be /mnt/sources/sources 08:58:58 <`3b`> ok 09:01:16 *`3b`* wonders if something is thinking the CVS in the path means it is in version control metadata dir and should be ignored 09:01:17 so the pathnames are correct, i don't know what else remains 09:01:54 *`3b`* would try renaming that CVS to something else, or building the cvs checkout in another dir 09:02:14 ok 09:02:17 i'll try now 09:02:19 in my /home 09:02:54 <`3b`> yeah, it looks like asdf does check for that sort of thing at least sometimes 09:06:52 you right, the above suggestion is maybe right, i'm now testing it in my /home/sepult/sbcl dir which i checkout out now 09:07:01 via cvs 09:07:41 i'm not gonna name my repository dirs CVS anymore 09:07:45 lol 09:08:19 <`3b`> heh, stuff breaking on specifically named paths is always fun 09:08:43 <`3b`> for a while sbcl wouldn't build correctly if any of the parent dirs were named src 09:08:56 oh 09:09:01 <`3b`> which took a similarly long time to figure out 09:09:03 so it is a recurrent theme 09:09:05 eheh 09:09:26 <`3b`> similar theme, but completely unrelated mechanism 09:09:47 ok 09:10:49 i thought the CVS wouldn't matter cause sbcl is the root path for the checkout 09:10:53 CVS/sbcl 09:12:23 <`3b`> yeah, would make more sense to only check directories it is considering recursing into 09:16:56 yep now the .fasl files are in the contrib/sb-aclrepl files too 09:17:22 the question is then why would some contribs build at all ? 09:17:53 <`3b`> presumably not all of them use asdf to load 09:17:57 ah 09:18:48 ok i'm gonna rename all my dirs in /mnt/source/sources to all lowercase 09:19:06 i hope that is sufficient, if not i'll name them totally different 09:19:10 <`3b`> yeah, looks like asdf, sb-executable and sb-sprof don't use asdf 09:19:17 ok 09:19:48 <`3b`> yeah, renaming it to cvs should fix it... might also file a bug on asdf about it 09:20:17 err is that a bug actually ? 09:20:24 or was that just my failure ? 09:20:47 <`3b`> i'd say it is a bug, though it is a bad name (since it risk triggering that sort of bug) 09:21:25 ok, but are ordinary users allowed to file bugs ? 09:21:31 <`3b`> cvs uses a dir named CVS. so things will tend to assume it is the one created by CVS and possibly treat it specially 09:21:57 <`3b`> yeah, https://bugs.launchpad.net/asdf/ might need to create an account or something 09:22:11 ok 09:22:13 will do then 09:22:41 tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has joined #sbcl 09:40:45 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl 09:40:45 -!- ChanServ has set mode +o nikodemus 09:45:45 hmm, shall i put any attachments of the above pastes ? 09:46:56 nope i don't 09:53:55 cmpitg [~cmpitg@210.245.54.125] has joined #sbcl 09:55:01 oh my, now i tried to build the cvs version with the git version and my heap got exhausted in the test runs of the threads 09:55:15 -!- cmpitg [~cmpitg@210.245.54.125] has left #sbcl 09:55:20 <`3b`> how much ram do you have? 09:55:29 4GB 09:55:53 *`3b`* would expect that to be enough 09:56:30 http://pastie.org/1276768 09:57:21 hangs there now 10:00:52 i already set my /proc/sys/vm/max_map_count to 262144 10:03:21 ok there was another lisp running, killed it 10:03:30 running the setup again after sh clean.sh 10:28:51 <`3b`> have you already renamed your CVS dir? 10:29:50 <`3b`> noticed the problem may have already been fixed in asdf, just not made it to sbcl yet... 10:45:30 yes now i did 10:46:57 <`3b`> might be interesting to rename it back and test with new asdf, if it isn't too much effort 10:48:38 <`3b`> or i suppose i could just try to test it myself :p 10:49:39 *`3b`* supposes that would be easy enough to do, so starts a build 10:49:49 no i'm doing the test now, but you said the patch did not go into sbcl so i thought i wait 10:50:41 <`3b`> right, but if it is fixed in asdf, would be nice to verify it so they don't need to worry about the bug report :) 10:52:05 i try to, am compiling already 10:52:44 played around with the default target features of my /home/sbcl 10:52:51 enabled all i could 10:52:52 lol 10:52:58 now i have two builds running 10:56:05 ok no lutexes for me 10:56:09 cc -g -Wall -Wsign-compare -O3 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I. -DSBCL_PREFIX=\"'/usr'\" -c -o pthread-lutex.o pthread-lutex.c 10:56:09 pthread-lutex.c: In function 'lutex_init': 10:56:09 pthread-lutex.c:70: warning: implicit declaration of function 'pthread_mutexattr_settype' 10:56:09 pthread-lutex.c:71: error: 'PTHREAD_MUTEX_ERRORCHECK' undeclared (first use in this function) 10:56:12 pthread-lutex.c:71: error: (Each undeclared identifier is reported only once 10:56:15 pthread-lutex.c:71: error: for each function it appears in.) 10:56:19 make: *** [pthread-lutex.o] Error 1 10:56:24 make: Leaving directory `/home/sepult/sbcl/src/runtime' 10:56:27 10:59:42 hmm, the cvs version fails again, with the contrib modules not building 11:00:02 didn't alter anything there 11:00:23 apart from renaming my cvs folder to CVS back 11:01:09 <`3b`> did you try with newer asdf? 11:01:22 wait newer ? 11:01:37 oh i have to checkout the new version of asdf, ups sorry lol 11:01:41 forgot it totally 11:03:45 ok did the git pull now 11:03:48 rebuilding 11:19:25 hmm, no it did not build seemingly 11:19:33 i mean the contribs failed 11:19:45 though i did the git pull of asdf 11:20:11 and asdf is in my /usr/share˘ommon-lisp/source and linked to /usr/share/common-lisp/systems 11:20:35 does sbcl not use it's own asdf ? 11:20:43 so i should just put it in there ? 11:20:58 i mean the newer one into my sbcl dir not ? 11:21:06 wait, i'll do that 11:21:21 <`3b`> yeah, put new asdf.lisp in contrib/asdf/ 11:21:28 ok 11:22:15 ok now did, rebuilding 11:36:38 yep, now it built the contribs 11:37:00 there are fasls in the contrib/sb-aclrepl/and others 11:37:13 patch works 11:39:05 -!- hefner [~hefner@ppp-58-9-182-82.revip2.asianet.co.th] has quit [Ping timeout: 255 seconds] 11:43:50 <`3b`> ok, probably should add a comment to the bug saying that new asdf fixes it 11:44:20 *`3b`* should have though of 'try newest version before filing bug' sooner :( 11:45:29 hefner [~hefner@ppp-58-9-117-34.revip2.asianet.co.th] has joined #sbcl 11:45:39 ah 11:48:24 -!- tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has quit [Quit: Leaving.] 11:48:46 where do you get the version info ? 11:52:00 2.010.3 ok found it 11:56:02 tag 2.147 12:01:09 was there really already a fix ? 12:01:44 how often does sbcl itself update it's own asdf files ? 12:05:54 <`3b`> sbcl will probably get the new asdf this month, just didn't quite make it in time for the 1.0.44 release 12:09:18 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 245 seconds] 12:10:43 ah ok 12:50:10 blabla [~lisps@BSN-61-32-239.dial-up.dsl.siol.net] has joined #sbcl 13:00:17 yay 13:02:02 http://pastie.org/1277000 this did pass 13:16:07 hrmpf, the test didn't pass though 13:16:39 it hanged somewhere around impure.lisp or so suspended and neve came back 13:23:42 stassats [~stassats@wikipedia/stassats] has joined #sbcl 13:42:17 test results this time http://pastie.org/1277068 13:47:32 ok and the with lutex version just fails 13:47:51 but why did the first test hang ? and the second complete ? 13:50:51 homie: i haven't been following this properly. what are you trying to do? 13:52:36 trying to set it up with the setup from base-target-features-lisp-expr i put above (without lutexes), it compiles 13:52:36 fine, but then did fail on my first attempt to test it (run-tests.sh hanged), the second time i rebuild and tested the 13:52:36 test completed with the above failure report, and the with lutexes version just fails 13:53:14 there was maybe some hint left from the first run of tests for the compiler ? 13:53:44 or it was just magic 13:55:07 homie: don't edit base-target-features.lisp-expr 13:55:24 use customize-target-features.lisp 13:55:36 ah 13:55:37 ok 13:55:43 what platform are you on, what features are you trying to enable or disable? 13:56:25 i'm on x86, debian, and the features i enabled are here http://pastie.org/1277000 13:57:33 homie: some concision, please. what did you enable that isn't on by default? 13:59:53 :sb-after-xc-core, :sb-show-assem, :sb-unicode, :sb-eval, :sb-source-locations, :sb-xref-for-internals, 13:59:53 :32x16-divide these here 14:00:51 and Q_SHOW_SIGNALS to 1 in runtime.h 14:03:03 ah and :restore-segment-registers-from-tls too 14:03:11 uh 14:03:53 32x16-divide is probably bogus. i doubt anyone has built with it in years 14:03:59 ok 14:04:20 restore-segment-registers-from-tls isn't ment to be enabled by hand -- it will be enabled if it's needed 14:05:07 sb-unicode, sb-eval, and sb-source-locations are already on by default 14:05:55 i'm not sure how functional sb-show-assem is -- but it sounds unlikely to break things 14:06:22 :sb-dyncount breaks :sb-show too but :sb-show-assem does not 14:06:59 sb-after-xc-core only allows you to use slam.sh, so unless you're working on slammable changes (and know what those are), turning it on is pointless but harmless 14:07:15 :sb-xref-for-internals should work :) 14:07:16 ok 14:08:20 i think the moral here is "don't enable a bunch of semi-random features and expect things to work" :) 14:08:31 eheh 14:08:58 :) i'm not gonna do that on regular builds, i just test 14:09:27 sure. reports of such failures don't really contribute anything useful, though 14:09:54 ok will keep in mind 14:12:10 now if you instead eg. enable _one_ feature, and it breaks the build or does something unexpected, then a report to the effect: "i enabled X - everything else was normal. it caused Y to happen. is this expected?" is quite appreciated 14:13:08 ok 14:13:31 as is "i enabled both X1 and X2, and it broke the build. either X1 or X2 by itself works fine" -- that's useful too 14:13:47 jup i see 14:29:21 morning 14:29:39 nikodemus: any word about access to upload openbsd builds? 14:39:47 joshe: oh, right 14:40:24 the answer is yes -- i'll go navigate the admin interface now :) 14:40:45 heh, ok 14:40:51 Good luck 14:41:18 (webpage is trickier, since it needs the commit-bit, but active shin-kicking here asking someone to link the binaries should do the trick) 14:51:58 attila_lendvai [~attila_le@adsl-89-134-29-99.monradsl.monornet.hu] has joined #sbcl 14:52:43 homie` [~user@xdsl-84-44-252-148.netcologne.de] has joined #sbcl 14:54:15 -!- homie` [~user@xdsl-84-44-252-148.netcologne.de] has quit [Read error: Connection reset by peer] 14:55:17 -!- homie [~user@xdsl-78-34-200-160.netcologne.de] has quit [Ping timeout: 276 seconds] 14:57:38 homie [~user@xdsl-84-44-252-148.netcologne.de] has joined #sbcl 15:02:46 hargettp [~anonymous@pool-71-184-181-150.bstnma.east.verizon.net] has joined #sbcl 15:03:22 *stassats* learns about sb-int:format-universal-time 15:03:30 why is it in sb-int and not sb-ext? 15:04:13 sb-ext is an interface to the OS 15:04:23 that is wrong 15:04:40 i mean false 15:05:12 oki 15:05:39 homie: see (documentation (find-package :sb-ext) t) 15:07:34 jup 15:07:44 extensions to the ansi spec 15:09:01 does that exclude it providing interface to the os ? 15:12:24 no 15:14:13 representation, external-os-side, internal 15:14:52 i don't know what the advantage of overwriting the os semantics on time representation would be.. other than not 15:14:52 allowed or ub maybe 15:15:13 you're not making sense 15:22:49 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 15:34:07 nyef [~nyef@pool-70-20-44-124.man.east.myfairpoint.net] has joined #sbcl 15:34:22 G'morning all. 15:37:14 morning 15:55:03 -!- hargettp [~anonymous@pool-71-184-181-150.bstnma.east.verizon.net] has quit [Quit: hargettp] 16:59:08 hargettp [~anonymous@pool-71-184-181-150.bstnma.east.verizon.net] has joined #sbcl 17:00:39 tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has joined #sbcl 17:02:58 -!- hargettp [~anonymous@pool-71-184-181-150.bstnma.east.verizon.net] has quit [Client Quit] 17:06:57 hargettp [~anonymous@pool-71-184-181-150.bstnma.east.verizon.net] has joined #sbcl 17:47:20 If someone with a commit bit is awake, I've uploaded openbsd binaries for ppc and x86* 17:48:11 Also, the openbsd/mipsbe box in the download table should be "no such system", not "not available" 18:42:27 kclifton [~kclifton@s198-166-45-245.ab.hsia.telus.net] has joined #sbcl 18:59:58 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 19:03:59 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 255 seconds] 19:18:13 -!- blabla [~lisps@BSN-61-32-239.dial-up.dsl.siol.net] has quit [Quit: blabla] 20:01:44 -!- hefner [~hefner@ppp-58-9-117-34.revip2.asianet.co.th] has quit [Ping timeout: 255 seconds] 20:09:23 hefner [~hefner@ppp-58-9-117-34.revip2.asianet.co.th] has joined #sbcl 20:53:18 -!- hargettp [~anonymous@pool-71-184-181-150.bstnma.east.verizon.net] has quit [Quit: hargettp] 21:02:40 -!- kclifton [~kclifton@s198-166-45-245.ab.hsia.telus.net] has quit [Quit: kclifton] 21:29:27 -!- stassats` [~stassats@wikipedia/stassats] has quit [Ping timeout: 250 seconds] 21:34:36 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl 21:34:36 -!- ChanServ has set mode +o nikodemus 21:34:56 Hello nikodemus. 23:04:11 -!- attila_lendvai [~attila_le@adsl-89-134-29-99.monradsl.monornet.hu] has quit [Ping timeout: 265 seconds] 23:15:36 -!- tcr [~tcr@cpc5-bour5-2-0-cust340.15-1.cable.virginmedia.com] has quit [Quit: Leaving.] 23:16:25 attila_lendvai [~attila_le@adsl-89-134-26-225.monradsl.monornet.hu] has joined #sbcl 23:17:21 -!- nyef [~nyef@pool-70-20-44-124.man.east.myfairpoint.net] has quit [Quit: G'night all.] 23:28:26 -!- attila_lendvai [~attila_le@adsl-89-134-26-225.monradsl.monornet.hu] has quit [Quit: Leaving.]