00:24:10 -!- leuler [~user@p54905011.dip.t-dialin.net] has quit [Quit: ERC Version 5.1.2 $Revision: 1.796.2.6 $ (IRC client for Emacs)] 00:53:11 -!- edgar-rft [~me@HSI-KBW-078-043-123-191.hsi4.kabel-badenwuerttemberg.de] has quit [Quit: Eternal darkness] 01:03:18 tcr [~tcr@84-72-21-32.dclient.hispeed.ch] has joined #sbcl 01:06:41 -!- prxq [~mommer@mnhm-5f75d075.pool.mediaWays.net] has quit [Ping timeout: 244 seconds] 01:18:57 prxq [~mommer@mnhm-5f75fa93.pool.mediaWays.net] has joined #sbcl 01:25:50 -!- tcr [~tcr@84-72-21-32.dclient.hispeed.ch] has quit [Quit: Leaving.] 03:14:40 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 04:17:34 sdemarre [~serge@91.176.29.6] has joined #sbcl 06:49:11 homie`` [~levgue@xdsl-87-79-192-207.netcologne.de] has joined #sbcl 06:51:49 -!- homie` [~levgue@xdsl-78-35-145-238.netcologne.de] has quit [Ping timeout: 244 seconds] 07:31:06 nikodemus [~nikodemus@37-219-42-250.nat.bb.dnainternet.fi] has joined #sbcl 07:31:06 -!- ChanServ has set mode +o nikodemus 07:55:09 -!- loke [~elias@bb115-66-85-121.singnet.com.sg] has quit [Remote host closed the connection] 08:00:50 -!- homie`` [~levgue@xdsl-87-79-192-207.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 08:05:53 homie [~levgue@xdsl-87-79-192-207.netcologne.de] has joined #sbcl 08:05:58 wbooze [~wbooze@xdsl-87-79-192-207.netcologne.de] has joined #sbcl 08:46:39 tcr [~tcr@84-72-21-32.dclient.hispeed.ch] has joined #sbcl 08:47:29 wtf? it looks like as if on darwin select interprets the tv_usec as 1/100th of seconds, not nanoseconds? 08:48:19 oh, no 08:48:53 it's just on darwin the granularity select() sleeping is 0.01 seconds 08:48:58 useless 09:03:04 -!- DGASAU [~user@91.218.144.129] has quit [Remote host closed the connection] 09:06:39 DGASAU [~user@91.218.144.129] has joined #sbcl 09:09:27 kwmiebach [~kwmiebach@xdsl-87-79-213-151.netcologne.de] has joined #sbcl 09:16:50 -!- nikodemus [~nikodemus@37-219-42-250.nat.bb.dnainternet.fi] has quit [Quit: Leaving] 09:58:47 fvides [~quassel@56.165.216.87.static.jazztel.es] has joined #sbcl 10:32:01 nikodemus [~nikodemus@37-219-42-250.nat.bb.dnainternet.fi] has joined #sbcl 10:32:01 -!- ChanServ has set mode +o nikodemus 10:34:12 -!- DGASAU [~user@91.218.144.129] has quit [Remote host closed the connection] 10:34:34 DGASAU [~user@91.218.144.129] has joined #sbcl 11:50:20 -!- tcr [~tcr@84-72-21-32.dclient.hispeed.ch] has quit [Quit: Leaving.] 12:00:54 nikodemus: nice, thanks for the forward. 12:03:31 the downside is COMPILE on (setf fdefinition) 12:04:37 upside, we can apply the same trick to compile arg parsing away as well. 12:17:32 ...and the same framework can do some of the lifting for "generate an out-of-line specialized version based on constant arguments" stuff 12:19:32 very little code sharing, I'd expect. 12:20:09 on the (setf fdefinition) end, surely? 12:20:25 or maybe i misremember what the outline looked like 12:23:12 if COMPILE on setf is too expensive, the needed glue could almost be assembled directly from a few VOPs, no? 12:23:31 lichtblau: yes, I think that'd be more robust as well. 12:24:51 Anyway, this sounds like a big win for floats (in theory at least). 12:25:35 What I find intriguing/worth thinking about are the ramifications for integers. Because while the same trick should allow for untagged integers, there are major implications on representation selection. 12:25:37 yup. I tried to go that direction once, but it seemed so complicated and scary. 12:26:02 Yeah, maybe we only want fixnums for storage now (: 12:26:50 After all, we strongly prefer tagged arithmetic in functions because of the tagging overhead for args/rets -- if we suddently can have untagged args, the whole setup break down, and we need to think about which representation is right (for a certain var), seen from a global optimisation perspective. 12:26:53 well, they're also useful to index into arrays (: 12:26:59 Or at least we would have to, to actually benefit from the new scheme. 12:27:07 lichtblau: we already mixx miss a lot of opportunities 12:27:20 and arrays are another reason we might want tagged integers 12:30:45 but, as a default, I think we can actually be simpler minded and expect equivalent/better performance: keep everything unboxed, except if it's only a copy operation, or if it's a fixnum used to index in complex double vectors. 12:32:04 otoh, I don't know that we necessarily want this to be enabled by default. 12:33:35 for small functions, the overhead of back to back call/ret may well dominate a couple of (un)fixnumising operations. 12:36:03 the "by default" question depends a little on how many named calls to non-inline functions _with declared ftype_ and specificially suitable argument types we have anyway. 12:37:05 Sounds to me like there is huge room for experimentation. 12:37:12 ...as long as there are no big garbage collection issues. We certainly don't want to sprinkle in weak pointers to thousands of call sites into too many functions. 12:40:57 tcr [~tcr@84-72-21-32.dclient.hispeed.ch] has joined #sbcl 12:42:28 kwmiebach_ [~kwmiebach@xdsl-213-196-218-41.netcologne.de] has joined #sbcl 12:43:31 weak pointers aren't that bad, really. 12:43:59 also, we don't need declared ftypes once we embrace the dynamic generation of wrappers. 12:45:03 -!- kwmiebach [~kwmiebach@xdsl-87-79-213-151.netcologne.de] has quit [Ping timeout: 256 seconds] 12:48:09 if we move type checks that don't correspond to ptypes in wrappers, we don't need to walk through all call sites; call sites with the same ptypes can all point to the same wrapper. 12:51:08 well, first step is to figure a solid way to expose the unboxed entry point. After that, the rest is mostly engineering choices with a bit of programming. 12:59:46 stassats [~stassats@wikipedia/stassats] has joined #sbcl 13:21:19 -!- nikodemus [~nikodemus@37-219-42-250.nat.bb.dnainternet.fi] has quit [Quit: This computer has gone to sleep] 13:52:11 -!- mrpat [~mrpat@c-71-60-133-203.hsd1.pa.comcast.net] has quit [Quit: Leaving] 13:54:03 leuler [~user@p54903801.dip.t-dialin.net] has joined #sbcl 14:08:47 -!- kwmiebach_ [~kwmiebach@xdsl-213-196-218-41.netcologne.de] has quit [Ping timeout: 246 seconds] 14:35:18 LiamH [~healy@pool-74-96-13-228.washdc.east.verizon.net] has joined #sbcl 15:02:44 -!- homie [~levgue@xdsl-87-79-192-207.netcologne.de] has quit [Read error: Connection reset by peer] 15:03:24 homie [~levgue@xdsl-87-79-192-207.netcologne.de] has joined #sbcl 15:19:28 edgar-rft [~me@HSI-KBW-078-043-123-191.hsi4.kabel-badenwuerttemberg.de] has joined #sbcl 15:26:40 slyrus_ [~chatzilla@adsl-108-80-231-20.dsl.pltn13.sbcglobal.net] has joined #sbcl 15:51:03 -!- LiamH [~healy@pool-74-96-13-228.washdc.east.verizon.net] has quit [Quit: Leaving.] 16:02:02 nikodemus [~nikodemus@37-219-42-250.nat.bb.dnainternet.fi] has joined #sbcl 16:02:02 -!- ChanServ has set mode +o nikodemus 16:09:07 faheem [~faheem@bigipfloater1.duhs.duke.edu] has joined #sbcl 16:09:47 Hi. Does anyone know an easy way to log the output in the sbcl interpreter to a file? preferably non-sbcl specific. 16:11:16 clhs dribble 16:11:16 http://www.lispworks.com/reference/HyperSpec/Body/f_dribbl.htm 16:11:28 stassats: thanks. will take a look 16:20:39 -!- homie [~levgue@xdsl-87-79-192-207.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 16:22:37 faheem: #lisp is perfect for non-sbcl questions. 16:25:30 homie [~levgue@xdsl-87-79-192-207.netcologne.de] has joined #sbcl 16:38:52 and even for some sbcl ones 16:41:55 does anyone have an opinion on my lp entry 1010646: assuming the change is fine in principle, should I leave the "cat" commented out or not? 16:42:23 I've always found the contrib build output rather annoyingly long, but perhaps others like seeing it? 16:42:44 ASau` [~user@176.14.240.113] has joined #sbcl 16:42:58 that sounds better for me. 16:43:24 I think we should have a simple way to benchmark self-build times in a robust and repeatable fashion, though. 16:43:42 One way would be to just not build contribs, admittedly. 16:44:45 SBCL_JOBS=1 sh make.sh should be repeatable 16:44:59 good. 16:45:43 well, actually, not quite, because contribs are tested during build. 16:46:31 -!- ASau [~user@95-26-235-15.broadband.corbina.ru] has quit [Ping timeout: 252 seconds] 16:50:32 LiamH [~healy@pool-74-96-13-228.washdc.east.verizon.net] has joined #sbcl 16:51:14 I think that is because of the "don't ship the contrib if it's broken" policy, which I would argue is in place only because we consider contribs to be possibly unmaintained stuff that might be unfinished or broken in the first place. 16:51:43 If we kick out the obviously broken contribs, we could consider the rest to be part of SBCL proper and test them in run-tests. 16:51:52 right, but that's an orthogonal issue. 16:52:00 I like your output, fwiw. 16:52:04 +1 16:55:59 nikodemus: I can reproduce the problem with your code, on the interpreter. this is with Debian 386. I'm going to try amd64? What is your platform? 16:56:22 Meaning https://bugs.launchpad.net/sbcl/+bug/1009267 to be clear 16:56:29 *pkhuong* is ready to blame stack conservativeness. 16:56:34 faheem: just post the whole interaction on lauchpad so i can look at it 16:56:43 nikodemus: will do 16:57:08 pkhuong: possible, but these days we have tools to find out if that's the case. at least somewhat 16:57:56 nikodemus: hmm, IIANM, the new debugger tests are failing on #-sb-thread because after "debugger invoked" there's no extra line "in thread " 16:58:18 duh 16:58:34 i'll see to them. thanks for the heads-up 16:58:41 thanks! 16:59:03 ok. This has been on my queue for too long: if I don't commit the list merge sort stuff this week, I'm paying a round next time we have an SBCL meet (: 16:59:26 july? :) 16:59:53 lichtblau: *poke* re. windows stuff? 17:00:46 hell, I'll install wine and take a look at the safepoint stuff at least. 17:00:53 nikodemus: if I don't commit any windows stuff this year, I'm paying a round next time we have an SBCL meet (: 17:01:12 :-) :-( 17:01:13 nikodemus: that'd be nice (: Although, I have to get out of the euro zone some time around july 20th. 17:01:51 seriously, hlavaty is just getting ready with the autobench/autobuild stuff, which will allow me to push things without manually testing everywhere 17:02:19 \o/ 17:03:13 pkhuong: my vacation starts on 13th, and i need to be back in finland by 20th, so it sounds like we have a window :) 17:05:24 awesome! 17:05:56 the teclo people seem to be quite occupied, unfortunately. 17:07:29 nikodemus: are you located in helsinki? 17:07:39 yes 17:08:24 passing through at some point? 17:09:02 well, i'm somewhat near, in saint-petersburg across the border, will be passing through in a two weeks 17:09:22 but, no time for anything 17:11:21 nikodemus: surprisingly, on an amd64 machine your code doesn't crash. Do you want the output of that too? 17:13:21 how does this feel for a 2.0 release: win32, win64, safepoints, and the calling convention adapters thing? 17:13:38 3.0 can be new GC and software barriers ;) 17:14:37 win32 doesn't feel so novel anymore 17:15:20 and wasn't it in 1.0 already? 17:16:49 looks like it was 17:16:55 stassats: with threads. 17:17:42 pkhuong: 2.0 release of what? 17:17:47 and what is calling convention adapters thing? 17:18:53 stassats: in a nutshell, no consing for passing floats around. 17:19:32 the one proposed by helmut? 17:21:18 yeah, same basic idea. 17:21:35 if we could move boxing/unboxing and keyword/optional parsing to call sites, I'd be happy. 17:21:36 -!- LiamH [~healy@pool-74-96-13-228.washdc.east.verizon.net] has quit [Quit: Leaving.] 17:24:40 we should have an SBCL meet 17:25:03 I can do London again in December if we need a venue, though I'm up for travelling too 17:25:28 +1 on a meet 17:25:36 same. 17:25:57 can't make promises about december yet, though 17:26:33 well, December was just so that we could call it SBCL13 17:26:40 ye gods, SBCL will be a TEENAGER 17:27:31 oh dear. rebellion time 17:27:54 oh god. I fear the day I'll be teaching people younger than SBCL. 17:29:08 time for a new fork? 18:01:27 lichtblau: tests should be happy on unithreaded builds now 18:04:35 other options to be checked, -sb-eval and -sb-unicode 18:05:00 not today, though 18:05:09 (i did check x86 for a change) 18:05:28 but also: hooray for hlavaty and autobuilder 18:05:41 and running tests on windows is basically pointless 18:07:38 ...unless you're the one working on fixing those tests (?) 18:07:44 right 18:08:43 some tests are using missing features, like :environment parameter to run-program, that could be fixed by adding support for :environment on win32 18:49:06 LiamH [~healy@pool-74-96-13-228.washdc.east.verizon.net] has joined #sbcl 18:55:38 homie` [~levgue@xdsl-78-35-153-68.netcologne.de] has joined #sbcl 18:57:20 -!- wbooze [~wbooze@xdsl-87-79-192-207.netcologne.de] has quit [Ping timeout: 244 seconds] 18:57:28 -!- homie` [~levgue@xdsl-78-35-153-68.netcologne.de] has quit [Read error: Connection reset by peer] 18:58:15 wbooze [~wbooze@xdsl-78-35-153-68.netcologne.de] has joined #sbcl 18:58:38 -!- homie [~levgue@xdsl-87-79-192-207.netcologne.de] has quit [Ping timeout: 245 seconds] 19:00:01 homie [~levgue@xdsl-78-35-153-68.netcologne.de] has joined #sbcl 19:46:27 leuler: regarding the format bug, it already had a test-case, albeit without endless loop detection 19:49:10 well, the particular test didn't cause an endless loop, but what if it will? 19:49:20 that could be said about any test 19:50:53 stassats: I don't understand what you are getting at? 19:51:49 the old test, (format nil "~,0a" 1), could possibly hang in the future too 19:52:09 Yes. 19:52:41 so, how do one decides where to check for infinite loops or not? 19:53:10 because any other test, not related to format or printing, could conceivably hang in the future 19:53:17 I understand. 19:54:24 I just built the test to check for the exact failure that occurred and that was an endless loop. I consider that common practice and sound. 19:54:29 and those tests test the same thing, so they could be merged 19:57:48 I thought it being useful to have the bug number in the test name, so I made it a single test. 19:58:26 well, it could be (:format :negative-colinc-and-mincol :bug-905817) 19:59:07 and 0 is not really negative, but oh well 19:59:16 stassats: unit tests are nice when they test one small thing at a time. 19:59:53 pkhuong: well, it's actually the same thing, albeit with slightly different manifestations 20:02:58 and by the way, is (format nil ...) considered impure? 20:05:51 and it also doesn't signal an error for (format nil "~8,,-1a" 1) 20:07:42 it does it contradict the standard, but i don't think it's ever intended 20:08:04 s/it/does it/it doesn't/ 20:09:22 the whole format chapter can be scavenged for numerical arguments and tested for negative and other nonsensical values 20:09:53 (format nil "~'1f" 1) for example signals an error, but a bad one 20:10:35 True (that format error checking can be improved). Today, I just wanted to clean up two old launchpad entries and be done with it. 20:11:58 maybe format can just catch any errors signaled by directive processors and re signal them as its own 20:14:16 because checking all of them by hand can become boring pretty quick 20:16:25 also signalling warnings for (format nil "~,0a" 1) at compile time 20:17:04 maybe there should be some declarative description for format directives 20:17:21 https://github.com/nikodemus/SBCL/commit/7499be83c81f175f229f75e51a2da39c4f5855b7 # thinking about this 20:18:02 like (:a :args (float unsigned-byte) :modifiers '(@ : @:)) 20:18:57 doesn't sparc have some tagged arithmetic instructions? does sbcl use them? 20:21:01 well, looks like the vops with taddcctv and tsubcctv are commented out 20:49:06 -!- edgar-rft [~me@HSI-KBW-078-043-123-191.hsi4.kabel-badenwuerttemberg.de] has quit [Quit: All hope lost] 20:51:30 -!- LiamH [~healy@pool-74-96-13-228.washdc.east.verizon.net] has quit [Ping timeout: 260 seconds] 21:07:42 LiamH [~healy@vpn219118.nrl.navy.mil] has joined #sbcl 21:13:54 -!- LiamH [~healy@vpn219118.nrl.navy.mil] has quit [Quit: Leaving.] 21:16:26 -!- nikodemus [~nikodemus@37-219-42-250.nat.bb.dnainternet.fi] has quit [Quit: This computer has gone to sleep] 21:17:07 LiamH [~healy@pool-74-96-13-228.washdc.east.verizon.net] has joined #sbcl 21:18:00 kwmiebach [~kwmiebach@xdsl-213-196-218-41.netcologne.de] has joined #sbcl 21:22:20 -!- kwmiebach [~kwmiebach@xdsl-213-196-218-41.netcologne.de] has quit [Client Quit] 21:23:33 -!- fvides [~quassel@56.165.216.87.static.jazztel.es] has quit [Ping timeout: 256 seconds] 21:28:43 -!- stassats [~stassats@wikipedia/stassats] has quit [Read error: Operation timed out] 21:34:22 -!- leuler [~user@p54903801.dip.t-dialin.net] has quit [Quit: ERC Version 5.1.2 $Revision: 1.796.2.6 $ (IRC client for Emacs)] 21:48:50 -!- LiamH [~healy@pool-74-96-13-228.washdc.east.verizon.net] has quit [Quit: Leaving.] 22:21:20 -!- sdemarre [~serge@91.176.29.6] has quit [Ping timeout: 260 seconds] 22:35:23 Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has joined #sbcl 22:40:00 -!- Phoodus [~foo@wsip-68-107-217-139.ph.ph.cox.net] has quit [Ping timeout: 260 seconds] 22:54:27 -!- wbooze [~wbooze@xdsl-78-35-153-68.netcologne.de] has quit [Quit: Bye]