01:02:20 -!- Qworkescence [~quad@unaffiliated/quadrescence] has quit [Quit: Leaving] 04:48:54 May I build a binary for Darwin/PPC for the website to use? 04:53:27 Quadrescence: it's worth trying, at least. SBCL 1.0.47 (which is available from ) is not too old, which is a good sign.. 04:53:54 akovalenko: I've compiled it with 1.0.53 just fine, and actively use it. 04:54:04 I've compiled 1.0.53* 04:54:54 I misunderstood the question fatally :-) 04:55:20 Then I have a similar question on freebsd-8.2-stable () 05:18:37 -!- Fare [Adium@nat/google/x-rlcoxrnzzeyvggts] has quit [Ping timeout: 240 seconds] 05:22:25 -!- antgreen [~user@bas3-toronto06-1176449892.dsl.bell.ca] has quit [Ping timeout: 258 seconds] 05:28:40 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 05:31:22 tsuru`` [~charlie@adsl-74-179-25-191.bna.bellsouth.net] has joined #sbcl 05:33:09 -!- tsuru` [~charlie@adsl-74-179-250-113.bna.bellsouth.net] has quit [Ping timeout: 258 seconds] 05:37:24 pkhuong: be proud, https://bugs.launchpad.net/sbcl/+bug/888410 05:38:30 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 240 seconds] 05:52:12 attila_lendvai [~attila_le@81.211.133.50] has joined #sbcl 05:52:12 -!- attila_lendvai [~attila_le@81.211.133.50] has quit [Changing host] 05:52:12 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 05:54:36 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Read error: Connection reset by peer] 05:58:51 -!- flip214 [~marek@unaffiliated/flip214] has quit [Read error: Operation timed out] 06:14:01 flip214 [~marek@86.59.100.100] has joined #sbcl 06:14:01 -!- flip214 [~marek@86.59.100.100] has quit [Changing host] 06:14:01 flip214 [~marek@unaffiliated/flip214] has joined #sbcl 06:16:35 attila_lendvai [~attila_le@62-84-55-107.customers.almanet.kz] has joined #sbcl 06:16:35 -!- attila_lendvai [~attila_le@62-84-55-107.customers.almanet.kz] has quit [Changing host] 06:16:35 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 07:05:24 sdemarre [~serge@91.176.210.70] has joined #sbcl 07:43:31 angavrilov [~angavrilo@217.71.227.181] has joined #sbcl 08:05:48 antgreen [~user@bas3-toronto06-1177890584.dsl.bell.ca] has joined #sbcl 08:22:51 Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has joined #sbcl 09:02:01 nikodemus [~nikodemus@cs181056239.pp.htv.fi] has joined #sbcl 09:02:01 -!- ChanServ has set mode +o nikodemus 09:18:26 drdo` [~drdo@85.207.54.77.rev.vodafone.pt] has joined #sbcl 09:19:42 -!- drdo [~drdo@85.207.54.77.rev.vodafone.pt] has quit [Ping timeout: 240 seconds] 10:25:14 hlavaty [~user@91-65-217-112-dynip.superkabel.de] has joined #sbcl 10:52:31 -!- drdo` [~drdo@85.207.54.77.rev.vodafone.pt] has quit [Remote host closed the connection] 11:08:11 (a late) good morning everyone 11:22:28 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Read error: Connection reset by peer] 11:24:22 attila_lendvai [~attila_le@62-84-55-107.customers.almanet.kz] has joined #sbcl 11:24:22 -!- attila_lendvai [~attila_le@62-84-55-107.customers.almanet.kz] has quit [Changing host] 11:24:22 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 13:28:24 -!- cow-orker [~foobar@pogostick.net] has quit [Remote host closed the connection] 13:57:44 nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has joined #sbcl 13:57:55 G'morning all. 13:59:58 o/ 14:00:43 Congratulations on landing the first round of threading changes. 14:02:45 Guess it's time for me to rebase a couple of branches. 14:02:59 thanks. hopefully not too much work for everyone else 14:06:21 Looks like only one of my current branches is at risk of a merge conflict. Yesterday's branch, dealing with MAKE-LISP-OBJ. 14:12:46 And one of us would have run into this conflict, we both touch looks_like_valid_lisp_pointer_p(). 14:14:57 At least it's an easy fix. 14:17:56 Fare [~Adium@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has joined #sbcl 14:18:16 Heh. "On hypothetic platforms with threads and exact gc it is actually a must." -- Comment in interrupt.c, line 1261. 14:25:13 -!- Fare [~Adium@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has quit [Quit: Leaving.] 14:38:22 tyson1 [~Ian@bas1-toronto06-2925211537.dsl.bell.ca] has joined #sbcl 15:09:47 Fare [~Adium@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has joined #sbcl 15:09:55 -!- Fare [~Adium@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has left #sbcl 15:16:28 -!- tyson1 [~Ian@bas1-toronto06-2925211537.dsl.bell.ca] has left #sbcl 15:22:42 homie [~levgue@xdsl-78-35-191-26.netcologne.de] has joined #sbcl 15:26:38 Vivitron [~user@pool-173-48-170-228.bstnma.fios.verizon.net] has joined #sbcl 15:39:43 I need to write a test case that asserts that using MAKE-LISP-OBJ under certain circumstances should *NOT* return an object. And then I need the GC to not pitch a fit if it does. 15:43:48 ... looks like I can just throw a vector into static space and it should Just Work. 16:02:32 -!- christoph_debian [~user@oteiza.siccegge.de] has quit [Remote host closed the connection] 16:16:03 <_8david> nikodemus: do you have any estimate how much effort it would be to reduce or eliminate use of the world lock? 16:17:44 1-3 weeks is my current estimate 16:18:23 On which thread does SBCL run SIGCHLD handlers? 16:18:42 in whatever thread receives the signal, i think 16:25:35 -!- hlavaty [~user@91-65-217-112-dynip.superkabel.de] has quit [Ping timeout: 258 seconds] 16:29:11 rpg [~rpg@216.243.156.16.real-time.com] has joined #sbcl 16:36:40 christoph_debian [~user@oteiza.siccegge.de] has joined #sbcl 16:45:40 -!- antgreen [~user@bas3-toronto06-1177890584.dsl.bell.ca] has quit [Remote host closed the connection] 16:58:39 prxq [~mommer@mnhm-4d01164f.pool.mediaWays.net] has joined #sbcl 17:00:33 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 17:03:22 nikodemus: Please do a non-threaded build of HEAD. 17:05:35 CONDITION-WAIT in target-thread reads TIMEOUT, which is ignored. 17:06:18 i get lots of warnings about parallel hash access with mcclim and sbcl.... 17:06:25 concurrent! 17:06:28 why is that ? 17:06:41 There are also three undefined function style-warnings, for %%WAIT-FOR-MUTEX, MAKE-LISP-OBJ, and WAIT-FOR, but they may not be critical. 17:06:59 And there's something about not stack-allocating some result, but I'm fairly certain that that's PPC damage. 17:07:30 thanks, i'll see to it 17:07:54 homie: Why is which? Why are you getting the warnings, why does McCLIM do such access, or why does SBCL warn on such access? 17:08:34 nyef: i mean is that something to be bothered about to get a warning ? 17:09:05 nyef: cause when i click away the warning and tell to ignore, all is back to ok..... 17:09:12 nyef: but sometimes it freezes.... 17:09:26 nyef: and sometimes it freezes, without me doing anything! 17:09:35 Mmm. SBCL complains because it's a dangerous operation that can cause a lot of problems. 17:09:43 nyef: but it's not often..... 17:09:55 Such as random freezes, as a simple example. 17:10:07 hmmmm 17:10:24 Random data corruption is another fun one. 17:11:04 oh, i think it's mentioned in the testsuite, the hash acess has always problems as with 1.0.52.dirty 17:11:18 especially concurrent ones.... 17:12:12 Okay, building some version of SBCL from before the new threading stuff landed. Hopefully that will build and will cause my test case to fail... 17:15:10 i'm running the testsuite with my custom .sbclrc loaded, will see if it is that...... 17:16:04 homie: you have a non-default build of sbcl, with concurrent hash-table access detection built into it -- which is a good thing, but not on by default 17:16:19 but mcclim should probably always use synchronized hash tables on sbcl 17:16:20 ah yes, i enabled that 17:16:30 hmmmm 17:17:49 homie: do you follow the mcclim mailing list? (if i send a patch there, will you get it, or should i put you into cc?) 17:18:31 i subscribed there, but what i see is old, and i don't get new batch email nor see any new threads there actually...... 17:18:46 seems like stuck on 2008 or so..... 17:19:10 so if it will be recent i'll get it i think..... 17:20:37 patch sent to mcclim-devel, maybe it fixes things for you 17:20:59 thank you, hope i'll get it via e-mail.... 17:22:52 http://news.gmane.org/gmane.lisp.mcclim.devel 17:25:24 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 256 seconds] 17:29:30 -!- Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 17:32:27 right, i got it with knode now, thank you :) 17:32:56 attila_lendvai [~attila_le@62-84-55-107.customers.almanet.kz] has joined #sbcl 17:32:56 -!- attila_lendvai [~attila_le@62-84-55-107.customers.almanet.kz] has quit [Changing host] 17:32:56 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 17:39:08 patched, and reloading now 17:39:23 nikodemus: my take on join-thread timeout is to use conditions for this, and then we can have a with-captured-timeouts or whatever for the lazy or the repl 17:39:29 nyef: fix pushed 17:39:42 nikodemus: Thanks. 17:40:16 I'll give it the 'ol cheneygc try this afternoon if I can get my test case to fail properly. 17:40:38 attila_lendvai: i'm mostly convinced that non-conditions are TRT for local :timeout arguments -- but i'm going home right now so... 17:42:56 ahh, I see: with-deadline vs local :timeout args 17:53:22 -!- nikodemus [~nikodemus@cs181056239.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 18:01:16 akovalen` [~anton@77.51.42.201] has joined #sbcl 18:02:56 -!- akovalenko [~anton@77.51.40.53] has quit [Ping timeout: 248 seconds] 18:03:22 -!- akovalen` is now known as akovalenko 18:04:06 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 240 seconds] 18:06:10 *akovalenko* is going to extend save-lisp-and-die on windows with :subsystem :gui, :subsystem :console. Any opinions on this interface? 18:06:58 ... it's better than the hack I proposed a few years ago to use with-open-file on a dumped executable-with-core and blast the subsystem byte directly. 18:07:49 Maybe :windows-subsystem, to make it more obvious when it's expected to matter? 18:07:52 hahahaa oh nyef 18:08:09 redline6561: Sample code probably still available via the lispgames wiki if it's still up. 18:08:17 I have such a hack too (with actual image header structures defined)... 18:09:13 the implementation is trivial, but I want it to be in SBCL (1) because it's good to have, (2) because grovelling image header structure fields is easy to add into SBCL build process. 18:10:34 :windows-subsystem noted. As of specific subsystem naming, MS disagrees with itself -- sometimes it's CUI / GUI, sometimes CONSOLE / WIN32, etc. 18:11:15 Interfaces are hard. Let's go shopping! ;; nikodemus is right. 18:22:21 nikodemus [~Nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 18:22:21 -!- ChanServ has set mode +o nikodemus 18:25:01 cow-orker [~foobar@pogostick.net] has joined #sbcl 18:27:00 ;; nikodemus is right here 18:27:14 ? 18:27:41 did i break something exciting? 18:28:05 no, I just referred to a "go shopping" comment. 18:28:27 discussing save-lisp-and-die :windows-subsystem :gui 18:28:37 nikodemus: I'm doing a build now, I'll let you know if it's still broken. 18:28:49 ahh 18:29:14 i'm on my ipad now, so fixing will have to wait ti 18:29:19 ll tomorrow 18:29:52 this is my cunning new method to be able to leave work at the office - no laptops at home on weekdays 18:30:17 Nice. 18:30:32 My cunning method is no work on the laptop I take home on weekdays. 18:31:01 should we think of an ipad SBCL port?.. 18:31:12 It'd never get past Apple. 18:31:32 We could do one for the droid tablets, though. 18:32:57 tablet + running sbcl on the cloud seems like a reasonable option as well 18:33:29 Modulo being able to do a native-looking interface, sure. 18:33:41 Then again, no work for us to make it happen is a win. 18:34:15 sb- 18:34:26 bah. this keyboard sucks 18:34:57 ... A cross-compiler package named SB!CL ? 18:35:36 isn't that sb!xc? 18:40:25 Details, details. Also, not as amusing as sb!cl. 18:41:21 ;) 18:42:51 *nyef* just noticed that he's done (logand x (lognot y)) in a test case. 18:46:31 Ahem. It's called "Android". Droid is a trademark of LucasFilm licensed by Verizon for their phones only. 18:46:42 So how's the ARM port coming? :) 18:47:43 I don't know. Is anyone working on one? 18:48:10 Haven't heard of any. 18:49:29 didn't you make a dent at it? 18:49:51 I made a dent, but haven't picked up that hammer for quite a while now. 18:50:01 of course, if we had an llvm port, it would make an arm verison trivial ;p 18:50:31 I thought pkhuong was playing with some llvm-ish sbcl work recently... 18:50:36 hence the SSA article, etc 18:51:31 foom made a start of an llvm backend at some point as well... 18:51:47 like 2-3 years ago 18:52:34 what's the point of llvm ? 18:52:38 like jvm ? 18:52:57 does that mean it will be sold in the future ? 18:54:05 dinner, bye! 18:54:07 -!- nikodemus [~Nikodemus@cs181063174.pp.htv.fi] has quit [Quit: Leaving] 18:55:00 But... but... I'm only at second genesis in my build! 18:55:05 Oh well. 18:55:41 the genesis package names are full of ! 18:55:45 lol 18:55:53 sb!impl 18:56:58 Yes. Yes, they are. 18:57:44 I have a couple of angles for using "warm" package names in XC FASLs, but... 18:58:30 (Or, at the very least, dumping cores with warm package names.) 19:01:53 hmmm, that would look like xml tho..... 19:14:46 -!- angavrilov [~angavrilo@217.71.227.181] has quit [Ping timeout: 256 seconds] 19:41:23 -!- pchrist [~spirit@gentoo/developer/pchrist] has quit [Quit: leaving] 19:41:56 pchrist [~spirit@gentoo/developer/pchrist] has joined #sbcl 19:43:20 ... Is pickier MAKE-LISP-OBJ on CHENEYGC a bug fix or a feature? 19:44:06 (Well, enhancement, not feature.) 19:50:20 Qworkescence [~quad@unaffiliated/quadrescence] has joined #sbcl 20:31:18 -!- nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has quit [Ping timeout: 240 seconds] 20:35:04 nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has joined #sbcl 20:41:04 -!- sdemarre [~serge@91.176.210.70] has left #sbcl 20:42:03 Hunh. Looks like I need to ask nikodemus something about the test suite... 20:45:25 -!- pchrist [~spirit@gentoo/developer/pchrist] has quit [Ping timeout: 240 seconds] 20:49:07 homie` [~levgue@xdsl-78-35-162-55.netcologne.de] has joined #sbcl 20:51:00 -!- homie [~levgue@xdsl-78-35-191-26.netcologne.de] has quit [Ping timeout: 260 seconds] 21:00:03 zyg [d572af0d@gateway/web/freenode/ip.213.114.175.13] has joined #sbcl 21:02:05 Hi! I'm in sbcl in gdb. Sofar passing sigsegv and sigusr1 has been enough (on linux 3.6.38 x86-86). Now I'm getting a sigtrap. What does that mean? 21:02:37 It means you hit an error trap, and should pass that, as well. 21:03:03 If you can't pass that, rebuild SBCL with the extra feature :ud2-breakpoints and pass SIGILL instead. 21:05:48 nyef: thanks, what is an error trap? .. that reminds me also of my second question. I did try sbcl without any user-code. If I now type (error "hi") in the repl, I will not hit gdb, why not? 21:07:05 SBCL uses breakpoint instructions internally to provide a compact mechanism to encode infrequently-made calls, such as for particular error conditions. 21:08:16 oh, you dont spend time context switching so (error ...) can be really fast? 21:08:24 Not exactly. 21:08:54 pchrist [~spirit@gentoo/developer/pchrist] has joined #sbcl 21:08:58 Error conditions are supposed to be rare, so it's better to have a slow-but-compact representation for error paths. 21:09:51 The trap handler reads the encoded error information and constructs a suitable condition object based on that and the information in the trap context, and then calls ERROR. 21:10:33 But what if the user has modelled after a fast (SIGNAL ...)? 21:11:43 Calling SIGNAL or ERROR directly doesn't have any particular performance issues, this is more for when the compiler needs to indicate a TYPE-ERROR or similar. 21:13:40 So we can end up in the trap handler without a sigtrap situation, like a brk instruction? 21:15:12 No, we need a break instruction (typically the INT3 instruction on x86oids) to hit the trap handler. 21:15:50 The trap handler turns around and calls ERROR when necessary. 21:16:26 There are one or two traps that don't wind up calling ERROR, they're used for other purposes that don't require a fast-path as well. 21:18:41 yes I can see the int 3 and have backtracked it to make-block-key, but that doesnt tell me anything. 21:19:44 Just pass the damned signal, let SBCL deal with it. 21:20:06 It'll either do something clever, or it'll wind up in the SBCL debugger. 21:20:51 I get it when I do (require :sb-posix) ... having done (require :asdf) prior to this. 21:23:06 ok to sum up, I shouldn't worry about sigtrap? that is, it isn't a bug hiding somewhere. 21:23:50 Right, not a bug, not something to worry about. 21:24:40 Thanks alot! I'll go update my gdb config. 21:37:00 -!- homie` [~levgue@xdsl-78-35-162-55.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 21:39:07 -!- Vivitron [~user@pool-173-48-170-228.bstnma.fios.verizon.net] has quit [Remote host closed the connection] 21:40:53 nyef: IMO, our signal conses a bit too much (seems like most of it is comes from a temporal restart) 21:41:07 CL:SIGNAL, i mean 21:42:17 Let's not go there, I'm knee-deep in GC damage relating to dynamic-extent on PPC. 21:42:55 *akovalenko* experimented yesterday with altered *handler-clusters* that keep dx-fletted type predicates instead of type specifiers, but it still conses on each SIGNAL, only some 10% less.. 21:43:53 Wait, SIGNAL itself is consing for this stuff? 21:44:03 Rather than HANDLER-BIND and friends? 21:44:21 SIGNAL itself. 21:44:33 Hunh. 21:44:34 of course, I signal a preallocated condition object 21:47:02 I'll consider taking a look at that soonish. 21:47:02 that predicates-instead-of-specifiers hack may suddenly become useful for my next attempt of handling stack overflow on Windows sensibly. Unoptimized typep is not something that I'd like to call with 4k stack space left.. 21:48:07 Of course, the ideal would be to find the handler clusters by walking the control stack and the function debug info. 21:49:16 the problem is, different performance patterns require different designs. I'm interested in SIGNAL as a generic "non-error" communication device, so I want unhandled signals to be very performant.. 21:50:23 Mmm... I suppose that makes sense. 21:50:27 ..so I like even the current *handler-clusters* layout better than a SIGNAL which walks stacks, examines debug info and is slow as hell whether it conses or not. 21:51:27 Right, fair enough. 21:51:36 What are potential downsides to your alternate implementation akovalenko? 21:51:49 We'll save the stack walk for things which really do have to be performant, like unwind-protect blocks. 21:55:40 -!- zyg [d572af0d@gateway/web/freenode/ip.213.114.175.13] has quit [Quit: Page closed] 21:57:20 redline6561: it would cons more in handler-bind on targets without dx-closures, probably. 21:57:42 Gotcha. 21:58:06 or maybe not. (lambda (thing) (typep thing 'some-constant-typespec)) doesn't really close over anything. 21:59:19 ... what platforms don't have dx-closures? 21:59:34 heh, joining a predicate and a handler together may be better (so instead of testing than calling a handler, SIGNAL can just funcall everything..) 22:00:16 on platforms with no dx-closures, I have no idea. But there are reader conditionals in %%handler-bind, iirc. 22:00:25 Ah. HPPA doesn't have stack-allocatable-closures. 22:01:29 And all platforms should support implicit-value-cells... 22:03:33 I must say that our handler-bind and signal are pretty good even as they are, so it's just a perfectionism on my side, and possibly misapplied one. 22:07:15 now, another question on save-lisp-and-die: what if we want to take an executable prefix from another sbcl.exe, not that one we're running? I've looked at ClozureCL, and they pun on non-generalized booleans (:prepend-kernel #P"another-ccl.exe"). I could easily do the same to :executable, but altering a public interface this way looks wrong. 22:08:28 The use case is like that: we're on Windows, and we used UpdateResource to prepare a shiny new sbcl.exe with icons, file version strings, manifest, et al. Now we want to dump an application. 22:10:04 Doing this from a running SBCL instance? 22:11:25 I have no objection to a difference between :prepend-kernel t and :prepend-kernel #p"pathname" 22:11:36 -!- tsuru`` [~charlie@adsl-74-179-25-191.bna.bellsouth.net] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 22:13:29 nyef: I understand that I can run a new shiny sbcl.exe and make it dump itself, and sometimes it's just great (that's why I proposed --core sbcl-with-embedded-core.exe, btw) 22:15:30 Kryztof: if we're taking this route, :save-runtime-options '(:dynamic-space-size 42) becomes another interesting possibility. 22:26:50 -!- prxq [~mommer@mnhm-4d01164f.pool.mediaWays.net] has quit [Quit: Leaving] 23:44:54 -!- nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has quit [Ping timeout: 240 seconds] 23:55:18 borkman` [~user@S0106001111de1fc8.cg.shawcable.net] has joined #sbcl 23:57:32 -!- borkman [~user@S0106001111de1fc8.cg.shawcable.net] has quit [Ping timeout: 258 seconds]