01:08:52 -!- edgar-rft [~GOD@HSI-KBW-109-193-013-113.hsi7.kabel-badenwuerttemberg.de] has quit [Quit: continuation abandoned into perpetual nothing] 01:36:42 -!- ltt_ [~ltt_@186.223.55.174] has quit [Quit: Textual IRC Client: www.textualapp.com] 02:01:02 michael_lee [~michael_l@117.22.207.23] has joined #sbcl 02:01:26 milosn_ [~milosn@user-5af50ef2.broadband.tesco.net] has joined #sbcl 02:03:54 -!- milosn [~milosn@user-5af50afe.broadband.tesco.net] has quit [Ping timeout: 246 seconds] 02:54:38 prxq_ [~mommer@x2f6c871.dyn.telefonica.de] has joined #sbcl 02:56:19 -!- scymtym_ [~user@ip-5-147-115-29.unitymediagroup.de] has quit [Ping timeout: 260 seconds] 02:58:05 -!- prxq [~mommer@x2f6aa4b.dyn.telefonica.de] has quit [Ping timeout: 272 seconds] 03:39:37 -!- christoph_debian [~christoph@ppp-46-244-230-30.dynamic.mnet-online.de] has quit [Ping timeout: 272 seconds] 03:52:19 -!- Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has quit [Ping timeout: 260 seconds] 03:52:38 Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has joined #sbcl 03:52:59 christoph_debian [~christoph@ppp-88-217-54-57.dynamic.mnet-online.de] has joined #sbcl 04:05:11 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 04:22:54 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl 04:49:57 zulu_inuoe_ [~quassel@71.47.78.155] has joined #sbcl 04:54:06 How is a Windows SBCL release built? I've found fragmented documentation online etc. but I'm wondering how much of it is actually current.. any help would be greatly appreciated 04:56:46 I have a note where I seem to think starting threads with interrupts and gc disabled (in the C runtime) is a good idea. thoughts? 04:57:19 sure looks like it'd make the trampoline more reliable 05:27:20 hillgreen [~hillgreen@106.120.127.15] has joined #sbcl 05:40:27 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 05:58:19 -!- hillgreen [~hillgreen@106.120.127.15] has quit [Quit: Leaving] 06:12:02 teggi [~teggi@123.21.198.146] has joined #sbcl 06:38:21 sdemarre [~serge@91.176.207.143] has joined #sbcl 07:08:06 -!- sdemarre [~serge@91.176.207.143] has quit [Ping timeout: 245 seconds] 07:21:17 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 07:21:40 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 07:27:15 -!- ASau [~user@p5083D4AE.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 07:31:35 ASau [~user@p5083D4AE.dip0.t-ipconnect.de] has joined #sbcl 08:06:58 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 08:23:25 sdemarre [~serge@91.176.207.143] has joined #sbcl 08:41:19 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 08:52:26 -!- oleo [~oleo@xdsl-78-35-135-188.netcologne.de] has quit [Ping timeout: 264 seconds] 08:53:08 oleo [~oleo@xdsl-87-79-252-137.netcologne.de] has joined #sbcl 09:15:07 -!- yacks [~py@103.6.159.103] has quit [Read error: Operation timed out] 09:20:51 -!- sdemarre [~serge@91.176.207.143] has quit [Ping timeout: 260 seconds] 09:52:16 yacks [~py@103.6.159.103] has joined #sbcl 10:13:10 -!- samskulls [~user@S0106001111de1fc8.cg.shawcable.net] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 10:26:20 -!- stassats` [~stassats@wikipedia/stassats] has quit [Remote host closed the connection] 10:27:41 stassats [~stassats@wikipedia/stassats] has joined #sbcl 10:29:57 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl 10:34:35 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Ping timeout: 260 seconds] 10:39:47 root_empire [~michael_l@219.145.47.251] has joined #sbcl 10:42:50 -!- michael_lee [~michael_l@117.22.207.23] has quit [Ping timeout: 264 seconds] 10:52:55 -!- yacks [~py@103.6.159.103] has quit [Ping timeout: 246 seconds] 10:59:19 -!- Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has quit [Ping timeout: 260 seconds] 11:06:13 sdemarre [~serge@91.176.207.143] has joined #sbcl 11:52:26 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 264 seconds] 12:19:05 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl 12:19:53 stassats [~stassats@wikipedia/stassats] has joined #sbcl 12:23:24 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Ping timeout: 246 seconds] 12:44:18 -!- sdemarre [~serge@91.176.207.143] has quit [Ping timeout: 272 seconds] 12:56:01 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 245 seconds] 13:03:42 davazp [~user@178.167.254.154.threembb.ie] has joined #sbcl 13:20:54 yacks [~py@103.6.159.103] has joined #sbcl 13:42:36 stassats [~stassats@wikipedia/stassats] has joined #sbcl 14:01:45 LiamH [~none@96.231.221.245] has joined #sbcl 14:25:57 scymtym_ [~user@ip-5-147-115-29.unitymediagroup.de] has joined #sbcl 14:29:26 leuler [~user@p548F9E51.dip0.t-ipconnect.de] has joined #sbcl 14:38:37 ltt_ [~ltt_@186.223.55.174] has joined #sbcl 15:02:03 (foo (the index x) (ceiling x 2)) is not enough to trigger the correct transform for X, since the type is not known it goes through a bad %ceiling inlining 15:02:34 looks like (deftransform ceiling ((x y)) `(%ceiling x y)) could use a transform delay 15:04:14 that solves it 15:06:20 how much more such delays has to be added? 15:14:58 perhaps there should be some automatic way to tell that if a transform can't advance constraint propagation it should be skipped until all the constraints are propagated 15:15:28 -!- davazp [~user@178.167.254.154.threembb.ie] has quit [Ping timeout: 260 seconds] 15:23:34 -!- ltt_ [~ltt_@186.223.55.174] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz] 16:01:21 ok, now we need pkhuong to commit absolutely everything in the next 13 days 16:06:00 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl 16:20:45 SIGILL on an ordinary error, interesting 16:21:29 ah, no return sequence 16:22:43 Ignore runtime option --eval "(require :sbcl-page)". 16:22:44 GAH 16:24:35 turns out, marking concatenate as flushable, and deriving (concatenate nil) type as NIL, it flushes everything 16:24:45 including the return sequence 16:25:09 that can't be right 16:28:33 on the plus side, the interactive-debugger-and-restart combo did actually rescue the release script 16:28:37 the return sequence flush is not a problem, but the error signalling is a problem 16:28:47 the lack of 16:29:55 probably disabling flush if the type is NIL would solve it 16:38:53 -!- Bike [~Glossina@75-175-70-102.ptld.qwest.net] has quit [Ping timeout: 272 seconds] 17:11:12 edgar-rft [~GOD@HSI-KBW-109-193-013-113.hsi7.kabel-badenwuerttemberg.de] has joined #sbcl 17:11:13 Munksgaard [uid17912@gateway/web/irccloud.com/x-upjouofzwwhpwakj] has joined #sbcl 17:15:32 -!- yacks [~py@103.6.159.103] has quit [Quit: Leaving] 17:43:06 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 265 seconds] 17:45:12 stassats: see finish-ir2-block 17:48:06 or perhaps type derivation should mark nodes as error-ful when they are of type NIL 17:50:15 Hm. I wonder what existing practice is over reader macros 17:51:02 Krystof: i pretend that named readtable is the standard 17:51:03 do interesting userspace libraries define sharpsign-dispatch macros 17:51:28 also, how is it that I have still not setup quicklisp-grep 17:52:27 (also, major style corrections incoming. doubt i'll so much sbcl past this sunday) 17:55:37 nooooo 17:56:12 and you're going into the real world so we can't even dangle the "well it's nearly research" argument in front of you 18:09:51 sdemarre [~serge@91.176.207.143] has joined #sbcl 18:17:10 ltt_ [~ltt_@186.223.55.174] has joined #sbcl 18:17:55 -!- LiamH [~none@96.231.221.245] has quit [Quit: Leaving.] 18:20:35 -!- ltt_ [~ltt_@186.223.55.174] has quit [Client Quit] 18:24:40 -!- root_empire [~michael_l@219.145.47.251] has quit [Ping timeout: 265 seconds] 18:56:10 Bike [~Glossina@24.221.35.141] has joined #sbcl 19:18:59 Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has joined #sbcl 19:24:08 stassats [~stassats@wikipedia/stassats] has joined #sbcl 19:26:35 -!- angavrilov [~angavrilo@217.71.227.190] has quit [Remote host closed the connection] 19:55:10 theAlgorist [~theAlgori@host57-237-dynamic.6-87-r.retail.telecomitalia.it] has joined #sbcl 19:55:25 -!- sdemarre [~serge@91.176.207.143] has quit [Ping timeout: 245 seconds] 19:55:44 I've got problem with heap space on a freebsd sbcl installation 19:55:59 what problem? 19:57:44 stassats: http://paste.lisp.org/display/140314 19:58:14 well, heap exhausted 19:58:26 in .emacs I've put: (setq inferior-lisp-program "/usr/local/bin/sbcl --dynamic-stack-size 2048") 19:58:36 stack? 19:58:52 stack is at default value 19:59:08 no, i'm questioning the "stack" part of your snipped 19:59:13 t 20:00:02 to be more exact, i would expect it to be --dynamic-space-size 20:01:28 mmmh ok 20:01:53 mmap: Invalid argument 20:01:53 ensure_space: failed to validate -2147483648 bytes at 0x58000000 20:01:53 (hint: Try "ulimit -a"; maybe you should increase memory limits.) 20:02:07 is your sbcl really that old? 20:02:17 whatever value I use for it 20:04:53 This is SBCL 1.1.8, an implementation of ANSI Common Lisp. 20:05:03 is that so old? 20:05:25 no 20:07:33 :( 20:08:07 well, that -2147483648 is at least clear, it's printed using %ld 20:08:35 so, try ulimit, like it says, while i'll try to put some sense into that printf 20:08:58 ulimit doesn't work 20:09:14 also, you can't make it 4GB on 32-bit anyway 20:11:13 using 128, it seems to work 20:11:26 and 2048? 20:11:31 not working 20:11:49 try the binary search 20:11:51 and i like "--dynamic-space-size argument 4000 is too large, max 4143972351" 20:12:11 lol 20:12:18 who wrote this? 20:12:29 wrote what? 20:13:02 sbcl 20:13:11 anyway 20:13:14 some people 20:13:21 and you too 20:13:25 anyway 20:13:32 well, i didn't write the bad parts! 20:13:54 is there a way to not recompile packages everytime I restart sbcl? 20:14:14 asdf usually loads from .fasls 20:14:19 no recompiling involved 20:14:45 :(, still heap exhausted 20:14:58 well, then stop using a 32-bit sbcl 20:15:06 ok 20:15:36 LiamH [~none@96.231.221.245] has joined #sbcl 20:16:36 is the first time I found a program on linux or freebsd that it is worse on 32 bit arch 20:16:52 well, you're using too much memory 20:17:05 ... 20:17:31 <|3b|> lisp implementations like to preallocate contiguous address space for their GC, and 32 bit can get pretty restrictive 20:17:33 sbcl can't magically exceed the 4GB limit, or whatever freebsd has 20:17:51 ltt_ [~ltt_@186.223.55.174] has joined #sbcl 20:18:46 <|3b|> then on top of the 32 bit limit, there might be kernel or shared libs taking up specific chunks of address space, so finding a large chunk gets difficult 20:23:56 -!- Bike [~Glossina@24.221.35.141] has quit [Quit: Reconnecting] 20:28:13 Bike [~Glossina@24.221.35.141] has joined #sbcl 20:30:34 fisxoj [~fisxoj@24-212-142-77.cable.teksavvy.com] has joined #sbcl 20:30:34 -!- stassats [~stassats@wikipedia/stassats] has quit [Read error: Connection reset by peer] 20:31:08 -!- fisxoj [~fisxoj@24-212-142-77.cable.teksavvy.com] has quit [Client Quit] 20:31:54 stassats [~stassats@wikipedia/stassats] has joined #sbcl 20:34:38 almost as if hardware vendors had a point with the move to x86-64. 20:35:07 pkhuong: higher numbers just sell better 20:43:37 "4000 MB is too large, max 4046847 KB" 20:43:40 now, that's better 20:44:29 and no more negative sizes 20:49:10 stassats: ok, I'm back to amd64 20:49:48 LiamH1 [~none@96.231.216.85] has joined #sbcl 20:49:50 oh, that was you? 20:49:56 yes 20:50:03 on a freebsd incarnation 20:50:38 -!- LiamH [~none@96.231.221.245] has quit [Ping timeout: 240 seconds] 20:51:51 -!- LiamH1 is now known as LiamH 20:52:14 -!- Bike [~Glossina@24.221.35.141] has quit [Ping timeout: 240 seconds] 20:53:40 stassats: actually works on amd64 20:54:15 at least sbcl now got better --dynamic-space-size out of range messages 20:57:44 -!- ltt_ [~ltt_@186.223.55.174] has quit [Quit: Textual IRC Client: www.textualapp.com] 21:01:10 did you fixed it? 21:01:17 Bike [~Glossina@24-221-35-141.pools.static.spcsdns.net] has joined #sbcl 21:01:34 yacks [~py@103.6.159.103] has joined #sbcl 21:18:35 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 260 seconds] 21:27:23 -!- Bike [~Glossina@24-221-35-141.pools.static.spcsdns.net] has quit [Remote host closed the connection] 21:28:58 Bike [~Glossina@24.221.35.141] has joined #sbcl 21:38:12 -!- oleo [~oleo@xdsl-87-79-252-137.netcologne.de] has quit [Ping timeout: 272 seconds] 21:41:59 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 21:43:56 -!- Bike [~Glossina@24.221.35.141] has quit [Ping timeout: 245 seconds] 21:48:17 Bike [~Glossina@24.221.35.141] has joined #sbcl 21:53:10 -!- Bike [~Glossina@24.221.35.141] has quit [Read error: Connection reset by peer] 21:55:19 Bike [~Glossina@24-221-35-141.pools.static.spcsdns.net] has joined #sbcl 22:05:42 ASau` [~user@p54AFFA8A.dip0.t-ipconnect.de] has joined #sbcl 22:08:55 -!- ASau [~user@p5083D4AE.dip0.t-ipconnect.de] has quit [Ping timeout: 260 seconds] 22:15:41 -!- ASau` is now known as ASau 22:17:01 -!- leuler [~user@p548F9E51.dip0.t-ipconnect.de] has quit [Quit: ERC Version 5.1.2 $Revision: 1.796.2.6 $ (IRC client for Emacs)] 22:18:23 -!- prxq_ [~mommer@x2f6c871.dyn.telefonica.de] has quit [Quit: Leaving] 22:18:44 prxq [~mommer@x2f6c871.dyn.telefonica.de] has joined #sbcl 22:38:45 -!- Bike [~Glossina@24-221-35-141.pools.static.spcsdns.net] has quit [Ping timeout: 245 seconds] 22:39:53 Bike [~Glossina@24.221.35.141] has joined #sbcl 23:01:35 pkhuong: Got a minute? 23:01:55 zulu_inuoe_: sure 23:03:08 pkhuong: This is in relation to https://bugs.launchpad.net/sbcl/+bug/1256034 I was able to find the cause of the problem, and I've got a solution that 'works' but I don't know if it's the right thing to do. Was hoping you could give me some advice 23:03:45 pkhuong: Or direct me to someone who could >;] Guessing Anton in this case 23:04:02 ok 23:07:52 The problem is in code/fd-stream.lisp in STREAM-REINIT when setting the *stdin* *stdout* and *stderr* values. On windows, when an application set to be a "GUI Application" it does not get its own std handles allocated as would be returned by GetStdHandle. This ultimately causes GET-STD-HANDLE-OR-NULL (in code/win32.lisp) to, appropriately, return nil. 23:08:14 -!- Bike [~Glossina@24.221.35.141] has quit [Quit: Reconnecting] 23:08:19 Bike_ [~Glossina@24.221.35.141] has joined #sbcl 23:08:44 stream-reinit then passes nil as the handle value over to MAKE-FD-STREAM where it's expecting its first arg to be an fd (or in this case, a handle) 23:08:49 bad stuff follows 23:09:40 what's your solution? 23:10:06 so my 'solution' is for when the handles cannot be aquired, use the cl:make-concatenated-stream and cl:make-broadcast-stream to create black-hole input/output streams and set stdin and stdout to those 23:10:38 is there something like /dev/null on windows? 23:11:12 think there is, I'd have to look. That's essentially what I'm replicating here 23:11:17 I wouldn't be surprised if some code assumes that *std{in,out,err}* are fd streams 23:11:22 zulu_inuoe_: not quite the same. 23:11:39 right yea that's why I was afraid of having it as a solution 23:11:53 out of fear of people expecting fd's behind them 23:12:23 Thanks for verifying, I'll see if something else is available 23:12:27 over all, looks sound to me. _8hzp or nyef might have input to give here. 23:12:28 <_8hzp> well, there's NUL 23:15:18 Okay. I'll look at using NUL. I'll need to see how to properly open it up and clean it up 23:15:50 -!- Bike_ [~Glossina@24.221.35.141] has quit [Ping timeout: 264 seconds] 23:16:36 ISTM it'd make sense for the header frobbing code to be in s-l-a-d, eventually. 23:18:34 <_8hzp> pkhuong: oh yeah, that would be cool 23:19:18 ... once it works, that is ;) 23:24:10 <_8hzp> even though those are the easy solutions, it would of course (long-term) also be cool to use a kind of handle that allows us to actually get at the data written. Maybe a named pipe, and then optionally open a window to show that output. 23:27:15 _8hzp: that would be nifty; perhaps as an option in slad. 23:29:46 zulu_inuoe_: whenever it's convenient, updating the bug report with your findings so far will be useful, even if you don't have a patch yet. 23:30:14 pkhuong: 10 4. I'll do that in a minute. Thanks! 23:30:34 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl 23:33:36 Thank you! 23:35:38 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Ping timeout: 264 seconds]