00:06:48 -!- milanj [~milanj_@178-223-158-248.dynamic.isp.telekom.rs] has quit [Quit: Leaving] 00:28:07 drdo [~user@85.207.54.77.rev.vodafone.pt] has joined #sbcl 00:30:19 Fare [~Adium@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has joined #sbcl 00:44:57 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 00:56:04 stassats [~stassats@wikipedia/stassats] has joined #sbcl 00:56:40 -!- leuler [~user@p54903537.dip.t-dialin.net] has quit [Quit: ERC Version 5.1.2 $Revision: 1.796.2.6 $ (IRC client for Emacs)] 00:58:36 what's the policy on clean-up commits? like making (sort seq #'string> :key #'symbol-name) into (sort seq #'string>)? 01:00:09 akovalenko [~akovalenk@95.72.175.162] has joined #sbcl 01:00:44 -!- brown` [user@nat/google/x-spiyzwsgrvbgxnxu] has quit [Remote host closed the connection] 01:00:54 stassats: I like them on their own. 01:01:51 right. is grouping several unrelated clean-ups into a single commit ok though? 01:02:11 -!- christoph_debian [~user@oteiza.siccegge.de] has quit [Ping timeout: 244 seconds] 01:04:51 and while reading load.lisp i've noticed that it's full of (declare (optimize (speed 0))), what might be the reason behind them? 01:05:18 seems like that's been that way since cmucl 01:05:28 stassats: seems fine to me. 01:07:12 and most of these declartions are inside of macro bodies, perhaps they're there to save space? 01:07:22 pretty sure that was the goal. 01:08:40 i guess putting them into eval-when would achieve more saving 01:08:59 Re grouping clean up, it might be good to group them by sections of code 01:09:08 just in case something goes wrong, it's easier to bisect that way 01:09:56 it'd be nice to have defmacro-like macros which would optionally be present only at compile-time 01:10:19 something like :sb-remove-macros feature 01:17:18 -!- tcr1 [~tcr@95-88-46-7-dynip.superkabel.de] has quit [Quit: Leaving.] 01:27:39 Qworkescence [~quad@unaffiliated/quadrescence] has joined #sbcl 01:44:05 -!- Fare [~Adium@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has quit [Read error: No route to host] 03:32:15 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [Ping timeout: 260 seconds] 03:34:33 antoszka [~antoszka@unaffiliated/antoszka] has joined #sbcl 03:41:06 attila_lendvai [~attila_le@87.247.6.23] has joined #sbcl 03:41:06 -!- attila_lendvai [~attila_le@87.247.6.23] has quit [Changing host] 03:41:06 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 03:41:07 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [Ping timeout: 260 seconds] 03:42:02 antoszka [~antoszka@unaffiliated/antoszka] has joined #sbcl 03:51:26 homie` [~levgue@xdsl-78-35-176-243.netcologne.de] has joined #sbcl 03:52:47 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [Ping timeout: 260 seconds] 03:53:53 -!- homie [~levgue@xdsl-78-35-176-111.netcologne.de] has quit [Ping timeout: 252 seconds] 03:54:24 antoszka [~antoszka@unaffiliated/antoszka] has joined #sbcl 04:03:03 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [Ping timeout: 259 seconds] 04:05:05 antoszka [~antoszka@unaffiliated/antoszka] has joined #sbcl 04:23:13 -!- saschakb [~saschakb@p4FEA1072.dip0.t-ipconnect.de] has quit [Ping timeout: 252 seconds] 04:30:07 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [Ping timeout: 260 seconds] 04:33:53 antoszka [~antoszka@unaffiliated/antoszka] has joined #sbcl 04:38:30 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [Ping timeout: 260 seconds] 04:44:30 chp [~user@c-68-45-180-238.hsd1.nj.comcast.net] has joined #sbcl 04:50:29 antoszka [~antoszka@unaffiliated/antoszka] has joined #sbcl 04:59:02 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [Ping timeout: 260 seconds] 05:00:08 antoszka [~antoszka@unaffiliated/antoszka] has joined #sbcl 05:04:30 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 05:08:08 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 255 seconds] 05:13:13 -!- DGASAU [~user@91.218.144.129] has quit [Read error: Connection reset by peer] 05:17:45 tsuru`` [~charlie@adsl-74-179-198-46.bna.bellsouth.net] has joined #sbcl 05:19:01 -!- tsuru` [~charlie@adsl-74-179-198-89.bna.bellsouth.net] has quit [Read error: Connection reset by peer] 06:07:19 angavrilov [~angavrilo@217.71.227.181] has joined #sbcl 06:40:44 -!- stassats` [~stassats@wikipedia/stassats] has quit [Ping timeout: 252 seconds] 07:03:31 sdemarre [~serge@91.176.87.217] has joined #sbcl 07:25:03 -!- pers [~user@96-25-162-104.gar.clearwire-wmx.net] has quit [Ping timeout: 248 seconds] 07:39:59 -!- sdemarre [~serge@91.176.87.217] has quit [Ping timeout: 248 seconds] 07:45:01 nikodemus [~nikodemus@87-95-54-33.bb.dnainternet.fi] has joined #sbcl 07:45:01 -!- ChanServ has set mode +o nikodemus 07:51:00 pon1980 [~pon@195-67-88-105.customer.telia.com] has joined #sbcl 08:33:04 tcr [~tcr@95-88-46-7-dynip.superkabel.de] has joined #sbcl 08:41:36 Cryotank2011 [~Cryotank2@c-24-17-62-152.hsd1.wa.comcast.net] has joined #sbcl 08:50:59 christoph_debian [~user@oteiza.siccegge.de] has joined #sbcl 09:25:23 -!- Cryotank2011 [~Cryotank2@c-24-17-62-152.hsd1.wa.comcast.net] has quit [Quit: Cryotank2011] 10:22:15 -!- scymtym [~user@2001:638:504:2093:21a:a0ff:fe34:2d7d] has quit [Ping timeout: 244 seconds] 10:25:55 -!- flip214 [~marek@unaffiliated/flip214] has quit [Remote host closed the connection] 10:27:03 flip214 [~marek@unaffiliated/flip214] has joined #sbcl 10:27:21 -!- Kryztof [~user@81.174.155.115] has quit [Read error: No route to host] 10:51:40 scymtym [~user@2001:638:504:2093:21a:a0ff:fe34:2d7d] has joined #sbcl 10:57:31 Kryztof [~user@81.174.155.115] has joined #sbcl 10:57:32 -!- ChanServ has set mode +o Kryztof 11:05:01 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [Read error: Operation timed out] 11:09:44 antoszka [~antoszka@unaffiliated/antoszka] has joined #sbcl 11:09:46 -!- tcr [~tcr@95-88-46-7-dynip.superkabel.de] has quit [Quit: Leaving.] 11:14:57 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [Read error: Operation timed out] 11:21:13 -!- Kryztof [~user@81.174.155.115] has quit [Ping timeout: 260 seconds] 11:25:29 scymtym_ [~user@ip-78-94-201-237.unitymediagroup.de] has joined #sbcl 11:26:33 antoszka [~antoszka@unaffiliated/antoszka] has joined #sbcl 11:35:41 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [Read error: Operation timed out] 11:52:06 antoszka [~antoszka@unaffiliated/antoszka] has joined #sbcl 11:53:03 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [Read error: Connection reset by peer] 11:53:16 antoszka [~antoszka@unaffiliated/antoszka] has joined #sbcl 12:18:27 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [Read error: Operation timed out] 12:22:28 DGASAU [~user@91.218.144.129] has joined #sbcl 12:29:12 https://github.com/nikodemus/SBCL/commit/924faaa47b9c0024b98bc3ff8f90c80a07cbca3e # sh make.sh --fancy 12:39:19 -!- tsuru`` [~charlie@adsl-74-179-198-46.bna.bellsouth.net] has quit [Read error: Connection reset by peer] 12:40:29 tsuru`` [~charlie@adsl-74-179-198-34.bna.bellsouth.net] has joined #sbcl 13:39:46 -!- blackwolf [~blackwolf@ool-45763eb0.dyn.optonline.net] has quit [Read error: Connection reset by peer] 14:06:21 -!- nikodemus [~nikodemus@87-95-54-33.bb.dnainternet.fi] has quit [Quit: This computer has gone to sleep] 14:06:29 nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has joined #sbcl 14:06:39 G'morning all. 14:21:10 leuler [~user@p54904FEB.dip.t-dialin.net] has joined #sbcl 14:30:21 Kryztof [~user@81.174.155.115] has joined #sbcl 14:30:21 -!- ChanServ has set mode +o Kryztof 14:30:25 nikodemus [~nikodemus@87-95-54-33.bb.dnainternet.fi] has joined #sbcl 14:30:25 -!- ChanServ has set mode +o nikodemus 14:41:30 -!- drdo [~user@85.207.54.77.rev.vodafone.pt] has quit [Remote host closed the connection] 14:43:07 Hrm. I'm not as far along with my stack-allocatable-fixed-objects stuff as I thought I was. Stack scavenge is still broken. 14:44:37 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 14:54:39 -!- nikodemus [~nikodemus@87-95-54-33.bb.dnainternet.fi] has quit [Ping timeout: 248 seconds] 15:00:57 nikodemus [~nikodemus@178-55-191-18.bb.dnainternet.fi] has joined #sbcl 15:00:57 -!- ChanServ has set mode +o nikodemus 15:01:26 silly hack of the day: https://github.com/nikodemus/SBCL/commit/11e88126f5f313d3d4237199f27df6f7b5757e2b 15:02:51 what is it useful for? 15:03:32 Hum. 15:03:38 i would understand it if not for the "/in addition/" part 15:03:47 Why is this more useful than just concatenating the files "manually" as it were? 15:05:10 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 15:05:31 no idea 15:05:46 that's why it's a branch of it's own and not on my pending tree 15:06:12 nyef: presumably it would be easier to get the order right 15:06:44 this, on the other hand is the user-friendly hack of the day: https://github.com/nikodemus/SBCL/commit/9a55533af58cb2e2fa9c2d0c5aca94227ab23424 15:06:46 -!- DGASAU [~user@91.218.144.129] has quit [Read error: Connection reset by peer] 15:07:21 nikodemus: Lovely. You going to make that work on, say, MIPS? 15:08:10 brown` [user@nat/google/x-ahgbybofqaqoiehn] has joined #sbcl 15:08:29 Thank heaven for nyef, looking out for the poor, lesser seen architectures 15:08:30 nyef: "don't use it on mips" 15:08:51 could even make it break hard if you try to use it outside x86ids 15:09:28 Mmm. Never tried core-compression on PPC... And I don't think I've tried xref-for-internals, either... 15:09:52 On the other hand, I'm half-considering enabling threading by default on PPC/Linux. 15:10:01 and the "potentially controversial" one: https://github.com/nikodemus/SBCL/commit/26833e304336b5b9b4f21d83873c0a86522cf9fc 15:10:32 (it's not quite the same as attila's original -- simplified it and removed the places where he hooked into DESCRIBE) 15:10:57 antoszka [~antoszka@unaffiliated/antoszka] has joined #sbcl 15:11:13 -!- tsuru`` is now known as tsuru` 15:11:25 DGASAU [~user@91.218.144.129] has joined #sbcl 15:11:37 what's the opinion on making non-exported macros conditionally disappear from the core? (by means of defmacro-like macro which expands into eval-when :compile-toplevel in the presence of sb-remove-macros feature)? 15:12:13 Beats the ones that unconditionally disappear. 15:12:33 some macros are wrapped in such eval-when, but they don't really save much space and only hinder interactive changes 15:12:56 (By means of calling EVAL on the DEFMACRO form at macroexpansion time, of all the stupid things...) 15:14:03 i would sure like :sb-dev-mode that kept all that stuff 15:14:24 actually, we could repurpose sb-fluid for that, i guess 15:15:12 stassats`: you need to be careful about removing macros that aren't exported, though: if an inline function refers to them, things can break at runtime 15:15:31 (our inline functions store the original definition, not a minimally compiled one) 15:15:54 hmm, is that conforming? 15:16:15 nikodemus: right, making sure that it works is one of the goals 15:16:20 i /think/ it is, but i'm not 100% sure 15:16:47 it /is/ mostly convenient, though 15:16:47 if it wasn't compiler macros would arguably be much less useful 15:17:55 i'm still wondering it is actually legal to expand compiler macros with constants propagated into them 15:18:45 so that (has-a-cmacro "foo") and (let ((x "foo")) (has-a-cmacro x)) would both look like the same for the compiler macro 15:18:46 *nikodemus* has a patch for that *somewhere* 15:22:59 I doubt it, but surely any compiler macro which cares will do constantp/constant-form-value? 15:24:41 Kryztof: what do you mean? 15:25:02 (the idea is to allow compiler-macros to optimize in more cases) 15:25:31 Kryztof: not as portable. 15:25:55 it wouldn't be portable to depend on constants being propagated either 15:26:12 nikodemus: I peeked at your suppress print errors change, but it seems add substantially less features (e.g. restarts). I've added the with-possibly-suppressed-print-errors infrastructure in the hopes that it'll be used all around where it makes sense (I've found only two when I looked, though) 15:27:28 attila_lendvai: i didn't benchmark it yet, but i suspect that adding a handler and restart for every output-object is going to hurt a bit 15:28:03 oh, I haven't even considered print performance 15:28:37 my way of thinking is that if someone wants speed, then they won't go through all the bells and whistles of the printing infrastructure 15:28:50 doing it just in output-object allows us to elide the handler when it isn't needed 15:29:16 Kryztof: but it's performance we're talking about ;) 15:29:43 my experience of real-life-software suddenly going a lot faster when *print-pretty* is turned off suggests otherwise 15:29:44 the non-portability would be more general expansion than needed. 15:30:52 exactly. can portable code depend on (let ((x "foo")) (has-a-cmacro x)) seeing X in the expansion, instead of "foo"? 15:31:37 "To expand a compiler macro, the expansion function is invoked by calling the macroexpand hook with the expansion function as its first argument, the entire compiler macro form as its second argument, and the current compilation environment (or with the current lexical environment, if the form is being processed by something other than compile-file) as its third argument." 15:31:44 (clhs 3.2.2.1) 15:31:52 nikodemus: I believe the *print-pretty* infrastructure is a lot heavier than binding two specials and a bit of consing 15:32:33 but anyways, I don't really have a need for those changes, so I don't lobby for them... 15:33:33 ...although I think the whole hacking session on it was initiated by something annoying that could be trivially debugged by invoking one of the new restarts. 15:36:47 ? 15:41:00 nikodemus: I think it was that sometimes bogus user print-object methods turn the slime backtrace into an empty skeleton, and I couldn't inspect the error either 15:41:28 which restarts, i meant? 15:42:05 ok. given very light benchmarking, in my current scheme *suppress-print-errors* makes a difference of around 2-5% 15:43:23 don't know, just do it as you see fit and I'll hibernate my changes and get back lobbying if I'll miss a feature 15:46:27 fair enough 15:47:21 Kryztof: but does the "entire compiler macro form" have to be the /original/ source form? 15:52:43 (I think it was the abort-printing restart, it lets me abort bogus print-object methods in a fine grained way without losing the rest of the output. but judging from how little I remember, I think haven't used this feature ever since then... :) 15:52:57 *attila_lendvai* leaves, see you 15:59:55 homie`` [~levgue@xdsl-78-35-145-132.netcologne.de] has joined #sbcl 16:01:48 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 244 seconds] 16:02:09 -!- homie` [~levgue@xdsl-78-35-176-243.netcologne.de] has quit [Ping timeout: 245 seconds] 16:11:28 nikodemus: I would say so, yes: clhs 3.2.2.1.3 and the glossary entry for "compiler macro form". Of course by being Humpty Dumpty anything is possible 16:14:28 ok 16:15:01 i think having a supported halfway-house between define-compiler-macro and deftransform is more interesting anyways :) 16:22:17 Hunh. Okay, looks like I've been building with xref-for-internals for quite a while now. 16:23:37 defsubst ? 16:26:17 -!- pon1980 [~pon@195-67-88-105.customer.telia.com] has left #sbcl 16:28:15 nikodemus: What do you do about NEWS entries for your pending queue? Add them to the commits just prior to pushing upstream, be careful during rebase, have some custom rebase logic for NEWS, or something else? 16:38:49 milanj [~milanj_@91-150-120-190.dynamic.isp.telekom.rs] has joined #sbcl 16:44:40 -!- brown` [user@nat/google/x-ahgbybofqaqoiehn] has quit [Remote host closed the connection] 16:44:53 brown` [user@nat/google/x-mutywfkjdrnxyxsl] has joined #sbcl 16:51:10 nyef: either add them just prior, or make one masside NEWS-only commit 16:51:28 nyef: but it /is/ possible to define custom merge rules for files 16:51:38 Okay, that's about what I figured. 16:51:50 Guess I'll go with that for now myself. 16:51:56 possibly just saying that merging NEWS with 0-lines of context would be enough 16:52:27 Wouldn't be reliable, unfortunately. 16:52:41 no, but if you review them manually, it gets close 16:53:05 True. 16:53:12 a fully custom merge driver would be even neater, but i ran out of steam when i tried to write one 16:53:22 it's not difficult per se 16:53:34 Just getting it to work "right" is tricky, yeah. 16:53:39 just ... trucky 16:54:05 a very apropos typo, that 16:54:58 actually... 16:55:14 I think I want a feature to distinguish those platforms where the register set is conservatively scavenged from those platforms with a partitioned register set... And I'm thinking that it should be enabled for the conservatively scavenged platforms, not for the partitioned register set platforms. 16:55:49 :conservative-registers and :conservative-stack? 16:56:13 We already have :c-stack-is-control-stack for the latter. 16:58:02 c-stack being value stack doesn't prevent accurate gc on stack, pre se 16:58:02 per se, even 16:58:57 True, but it does preclude just calling scavenge_control_stack(thread), which is the decision point that I currently require. 16:59:21 fair enough 16:59:41 And having a non-partitioned register set doesn't prevent precise GC on the registers, but does preclude using scavenge_interrupt_context(). 17:06:06 akovalenko: so, how are filenames encoded on windows? 17:08:50 drdo [~user@85.207.54.77.rev.vodafone.pt] has joined #sbcl 17:11:02 nikodemus: ANSI code page in mainline, UCS-2 here 17:13:59 ok, so it actually is semi-sensible 17:14:14 gotto go now 17:15:54 -!- nikodemus [~nikodemus@178-55-191-18.bb.dnainternet.fi] has quit [Quit: This computer has gone to sleep] 17:19:50 rpg [~rpg@216.243.156.16.real-time.com] has joined #sbcl 17:20:29 Vivitron [~user@pool-173-48-170-228.bstnma.fios.verizon.net] has joined #sbcl 17:27:24 -!- brown` [user@nat/google/x-mutywfkjdrnxyxsl] has quit [Remote host closed the connection] 17:27:35 brown` [user@nat/google/x-toayjkmtmsizohya] has joined #sbcl 17:31:14 Oh, for the love of killall -9 sbcl... Neglected to rebase my working tree, and it's branched from that time period where SVIT.3 locks up fairly reliably on PPC... 17:44:49 Hello. I have a question about macroexpand-all, perhaps best explained with a paste: http://paste.lisp.org/display/126239 -- which is the expected behavior? (or are both expected?) 17:47:06 I'm unfamiliar with the semantics of macroexpand-all, but the SBCL behavior you describe seems a touch unlikely to be correct. 17:47:34 That said, I don't have my copy of CLtL2 anywhere near to hand, so I can't actually check. 17:49:33 well, there is no define-symbol-macro in cltl2.. 17:50:28 ..and I think SBCL's behavior is not good here, even if it doesn't contradict any document. 17:52:27 I think I might agree. 17:54:55 Thanks for the insight. 18:03:07 Heh. symbol-macros are mostly for CLOS, aren't they? 18:03:35 symbol-macros have many uses 18:04:53 I don't disagree, but they'd have been /introduced/ primarily by the forces behind CLOS, wouldn't they? 18:05:45 symbol-macrolet is in cltl2 18:06:25 ... guess not. Okay, why doesn't macroexpand work on them, then? 18:06:42 Or am I completely misunderstanding the context? 18:06:43 nyef: MACROEXPAND-1 and MACROEXPAND works on them 18:06:50 Eesh. 18:07:05 nyef: it's only SB-CLTL2:MACROEXPAND-ALL that fails 18:07:24 Right, I'll bow out, then. 18:39:20 brown`` [user@nat/google/x-emynifasjzwuljtr] has joined #sbcl 18:39:39 -!- brown` [user@nat/google/x-toayjkmtmsizohya] has quit [Read error: Connection reset by peer] 18:43:02 tcr [~tcr@95-88-46-7-dynip.superkabel.de] has joined #sbcl 18:58:00 -!- homie`` [~levgue@xdsl-78-35-145-132.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 19:00:22 homie [~levgue@xdsl-78-35-145-132.netcologne.de] has joined #sbcl 19:01:47 sdemarre [~serge@91.176.87.217] has joined #sbcl 19:08:33 brown``` [user@nat/google/x-ymlkvopxnertqbme] has joined #sbcl 19:08:36 Hrm. My latest build managed to fail three dynamic-extent.impure.lisp tests, three times each, over the course of a single invocation of the full test suite. 19:08:52 -!- brown`` [user@nat/google/x-emynifasjzwuljtr] has quit [Read error: Connection reset by peer] 19:33:07 prxq [~mommer@mnhm-5f75e941.pool.mediaWays.net] has joined #sbcl 19:38:23 -!- chp [~user@c-68-45-180-238.hsd1.nj.comcast.net] has quit [Ping timeout: 248 seconds] 19:44:43 -!- rpg [~rpg@216.243.156.16.real-time.com] has quit [Quit: rpg] 19:52:01 -!- leuler [~user@p54904FEB.dip.t-dialin.net] has quit [Quit: ERC Version 5.1.2 $Revision: 1.796.2.6 $ (IRC client for Emacs)] 19:52:27 ... Does ROOM have that same nasty exponential blowup behavior on x86 that it does on ppc? 19:52:44 It has to have at least some of it... 19:52:58 there was a recent commit about room consing like hell 19:53:15 s/commit/lp entry/ perhaps 19:55:18 it was consing after nikodemus's fp and pc saving thing a month or two ago, I committed a workaround the other day 19:55:26 I thought that was x86-oid only though 19:56:43 the room test passes now on x86, but I don't have a reliable box to run nightly ppc tests on 20:00:46 Yeah, I'm looking at room on PPC right now. 20:01:18 It runs okay for a couple of iterations, and then it starts generating CONSes like fury, and then starts generating BIGNUMs as well, and then it just goes nonlinear. 20:05:55 -!- angavrilov [~angavrilo@217.71.227.181] has quit [Ping timeout: 244 seconds] 20:06:15 that sounds familiar all right 20:11:52 First off, it really shouldn't be using MAKE-LISP-OBJ... 20:12:11 If you're walking through a heap space, you can be reasonably confident that the objects you find are valid. 20:15:35 Then again, if ROOM is the low-hanging fruit for test failures on PPC... 20:18:04 -!- scymtym_ [~user@ip-78-94-201-237.unitymediagroup.de] has quit [Ping timeout: 244 seconds] 20:18:44 ... All three failing D-X tests appear to require :stack-allocatable-vectors, which I have yet to completely figure out... 20:20:00 float.pure.lisp / RANGE-REDUCTION fails on x86-64/linux, so isn't a PPC bug. 20:20:28 The two debug.impure.lisp failures are fixed in one of my pending trees. 20:20:58 So, it's either stack-allocatable-vectors, or the xep-allocate-frame / copy-more-arg thing. 20:26:14 saschakb [~saschakb@p4FEA010C.dip0.t-ipconnect.de] has joined #sbcl 20:43:33 Cryotank2011 [~Cryotank2@c-24-17-62-152.hsd1.wa.comcast.net] has joined #sbcl 20:47:30 -!- Cryotank2011 [~Cryotank2@c-24-17-62-152.hsd1.wa.comcast.net] has quit [Client Quit] 20:59:03 -!- brown``` [user@nat/google/x-ymlkvopxnertqbme] has quit [Remote host closed the connection] 20:59:14 brown``` [user@nat/google/x-uobiuqizcxeoqrle] has joined #sbcl 21:14:58 So, run-tests.sh reports "7 tests skipped for this combination of platform and fetures". How do I find out which seven tests were skipped? 21:15:57 _8david [~user@port-92-195-21-77.dynamic.qsc.de] has joined #sbcl 21:17:42 Hrm. Five in hash.impure... 21:19:50 Why the hell are some of the hash-table tests only enabled for threaded PPC? 21:20:16 -!- lichtblau [~user@port-92-195-21-77.dynamic.qsc.de] has quit [Ping timeout: 248 seconds] 21:25:12 -!- Qworkescence [~quad@unaffiliated/quadrescence] has quit [Quit: Leaving] 21:36:44 -!- prxq [~mommer@mnhm-5f75e941.pool.mediaWays.net] has quit [Quit: Leaving] 21:38:16 chp [~user@c-68-45-180-238.hsd1.nj.comcast.net] has joined #sbcl 21:40:07 nikodemus [~nikodemus@178-55-191-18.bb.dnainternet.fi] has joined #sbcl 21:40:07 -!- ChanServ has set mode +o nikodemus 21:46:34 nikodemus: Would you happen to know why some of the hash-table tests are only run on threaded, non-x86oid targets? 21:52:37 ...no 21:52:52 that sounds not-right 21:54:15 nyef: that's probably gc conservatism (we can't really test weakness) 21:54:15 Looks like it came in with the addition of the :skipped-on feature. 21:54:36 akovalenko: So why the non-thread limitation? 21:54:50 (Or, rather, why limit it to only threaded platforms?) 21:55:12 have you checked the commit logs? 21:55:14 hmm. 21:55:46 Okay, I've thus far been unable to repeat the failure of deadline-detection interrupts, so I'm going to chalk it up to a fragile test case, because it's far too timing-dependent for my liking. 21:55:48 Err. 21:55:49 Damnit, 21:55:53 4c81c652cdc32faefee1bccb84c3c9a7854e3edd 21:55:59 Bloody clipboard. 21:56:33 thanks for your hash! 21:56:34 lol 21:56:39 They basically get disabled with no explicit justification. 21:57:51 "almost always too general (one EXCEPTION being :skipped-on '(not :sb-thread))" 21:58:04 curiouser and curiouser 21:58:18 Sure, that just means that it's a test that requiers threads. 21:58:21 Err. 21:58:26 Requires threads. 21:58:34 yes 21:58:44 Now, :skipped-on '(or x86 x86-64 (not :sb-thread)) is a bit much. 21:58:55 heh 21:59:20 Since the only platform which can have that combination is PPC/Linux. 21:59:33 nyef: maybe it means "gencgc", really 22:00:32 No, because the gencgc platforms are ppc, x86, and x86-64, and the thread platforms are the same set. 22:00:56 PPC is actually the only platform that can do both gencgc and cheneygc. 22:01:53 I mean that (not :sb-thread) is "sometimes accidentally equivalent" to :cheneygc 22:02:13 (if we exclude x86oids that *are* excluded here) 22:02:42 But, it just doesn't make sense. 22:03:01 I have no idea whether cheney gc has some effect on hash table weakness, but if it does, the reason for :skip-on is clear. 22:03:52 No, because the :cheneygc feature is still valid in :skipped-on. 22:03:54 hey nikodemus 22:03:58 hi 22:04:04 so, generate-version doesn't work out very well. :( 22:04:04 no. a) it should use "git merge-base HEAD origin/master" not the crap it has to determine version_root. what's there is totally broken if you're on a branch that branched from earlier than the tip of origin/master. 22:04:12 b) selecting a name to use for your branch doesn't work when you're using an autobuilder like hudson, which checks out a specific commit hash. 22:04:18 (a) is trivial to fix. But I don't know what to do about (b). 22:04:48 now I remember what I dislike about hudson's git usage (-: 22:04:54 you mean a detached head? 22:05:27 Okay, at some point over the weekend, I'll do a cheneygc ppc build and see how those tests behave. 22:05:29 yes, it will always be building from a detached head, because it checks out a particular hash. 22:06:06 right. it that commit exists on master, we can pretend it's on... 22:06:18 well, all my builds are going to be on the "ita" branch. 22:07:08 I mean, i guess we could run git branch --contains and randomly select one of the branches that contains the hash, but this is starting to seem a little hacky. :) 22:07:14 i think i've had ~3 beers to many to think sensibly about this right now 22:07:54 I find beers are necessary whenever thinking too much about version control. :p 22:08:00 possibly export SBCL_BUILD_NAME to use as the branch name for detached branches, defaulting to "detached" 22:08:25 it defaults to "HEAD" right now for detached heads 22:08:37 foom: (a) is the one martin put on lp, right? 22:08:44 nikodemus: yea 22:09:40 HEAD works as a default, i guess -- but you probably want to a prettier one... 22:10:13 or if there's a branch head that exactly corresponds to the detached head, that would be a natural pick too 22:10:26 -!- Posterdati [~tapioca@host133-226-dynamic.10-87-r.retail.telecomitalia.it] has quit [Ping timeout: 244 seconds] 22:11:02 Oh, I see what happened. 22:11:21 The original was protected by #+(or (not (or x86 x86-64)) sb-thread). 22:11:35 Posterdati [~tapioca@host133-226-dynamic.10-87-r.retail.telecomitalia.it] has joined #sbcl 22:13:10 So it should be :skipped-on '(and (or :x86 :x86-64) (not :sb-thread)), or, more accurately, :skipped-on '(and :c-stack-is-control-stack (not :sb-thread)). 22:15:38 I guess if there was something like 'git describe' except which gives you a pretty name based on the closest ref *after* the rev you specify that might be good for this. 22:16:02 yeah 22:16:34 i think we (i?) erred on the side to "too much cleverness, or not quite enough" initially 22:17:11 really, as long as the version number contains the last tag, and a sha1, and the dirty marker... everything else is imo negotiable 22:17:47 it's not like i'd try to count "65 commits forward" from a specific tag when there's the sha1 to use... 22:18:34 indeed. it's useful for sorting and identification, but not much else. 22:19:18 well, there's also the "wow, over 100 this month" factor, but that's value is a debatable :) 22:21:11 foom: apropos nothing: once you have QPX happy with 1.0.54.vintage, you might want to try it /without/ :sb-futex. in the non-contested case userspace locks currently outperform futex-based ones a bit 22:24:48 -!- akovalenko [~akovalenk@95.72.175.162] has quit [Ping timeout: 248 seconds] 22:46:53 -!- nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has quit [Quit: G'night all.] 22:48:12 but in the contested case it busy waits? 22:50:17 Hm, http://paste.lisp.org/+2PEX 22:50:36 This is with fresh SBCL as of yesterday. 22:51:25 increase the heap size? 22:51:28 -!- Vivitron [~user@pool-173-48-170-228.bstnma.fios.verizon.net] has quit [Ping timeout: 248 seconds] 22:54:46 foom: with backoff to nanosleep, yes 22:56:15 ASau`: default heap sizes shrunk. run with eg. --dynamic-space-size 4Gb, or pass --dynamic-space-size=4000 to make.sh 22:56:39 (unfortunately make.sh and sbcl commandline syntax isn't identical) 22:57:10 4Gb won't work, there's 3Gb limit. 22:57:18 would be nice to have put dynamic-space-size into a file something like customize-target-features 22:57:22 ASau`: well, try 3G 22:57:34 whatever works for you 22:57:36 Why cannot it obey rlimit??? 22:57:50 it should? 22:58:07 Yes. 22:58:36 why? 22:58:40 ASau`: it would be nice, yes. no-one's gotten around to doing that yet 22:58:40 that's a curious thought 22:59:00 stassats`: if rlimit specifies a memory limit, that's an upper bound 22:59:14 yea, but, you probably don't really want to pin yourself against the limit 22:59:28 then C allocations will fail 23:00:10 yeah, but if default dynamic-space-size is > rlimit, sbcl should probably complain to stderr and try to run with smaller heap 23:00:12 $ sbcl --dynamic-space-size 3Gb 23:00:12 fatal error encountered in SBCL pid 10714: 23:00:12 --dynamic-space-size argument is out of range: 3Gb 23:00:29 $ ulimit -m 23:00:29 3073508 23:01:27 Is there a reason for why it's not automatically set to available_memory - delta other than none done it? 23:01:52 [00:58] ASau`: it would be nice, yes. no-one's gotten around to doing that yet 23:02:13 ASau`: try less 23:02:20 also, rlimits are somewhat platform specific -- what is actually counted against what 23:02:33 $ sbcl --dynamic-space-size 1500 23:02:33 [1] Segmentation fault (core dumped) sbcl --dynamic-space-size 1500 23:02:43 ??? 23:02:51 debian ? 23:02:54 bsd? 23:03:12 $ sbcl --dynamic-space-size 1600 23:03:13 mmap: File too large 23:03:13 ensure_space: failed to validate 1677721600 bytes at 0x60000000 23:03:21 ??? 23:03:28 NetBSD/i386 23:03:48 try less still 23:03:58 i'm on slack, and still don't know how rlimits is set 23:03:59 that argument out of range looks odd 23:04:23 what's LONG_MAX there? 23:05:00 #define ULONG_MAX 0xffffffffUL /* max value for an unsigned long */ 23:05:00 #define LONG_MAX 0x7fffffffL /* max value for a long */ 23:06:11 try doing binary search on non-failing space size 23:06:28 Alright, doing that. 23:06:28 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 23:08:34 hm. i wonder i used long there in the first place? braindamage 23:08:38 New failure mode: 23:08:38 $ sbcl --dynamic-space-size 1466 23:08:38 ... 23:08:38 debugger invoked on a TYPE-ERROR: The value NIL is not of type CONS. 23:08:41 ... 23:08:45 (no restarts: If you didn't do this on purpose, please report it as a bug.) 23:08:48 (SB-IMPL::TOPLEVEL-INIT) 23:08:51 0] 23:09:18 ASau`: sbcl --dynamic-space-size 1466 --no-userinit ? 23:09:21 1465 works, 1465 segfaults. 23:09:28 wow 23:09:39 Same for no-userinit. 23:09:47 (SB-IMPL::TOPLEVEL-INIT) 23:09:47 0] 23:10:08 i see /* NetBSD counts mmap()ed space against the process's data size limit, * so yank it up. This might be a nasty thing to do? */ 23:10:23 and then it sets rlimit to 1073741824 23:11:11 anyways, i'm off to bed. unless someone else can help with this, details on the lp or mailing list please. (along with information about the last sbcl that works fine in the same environment) 23:11:50 Ufff! 23:12:51 -!- nikodemus [~nikodemus@178-55-191-18.bb.dnainternet.fi] has quit [Quit: This computer has gone to sleep] 23:13:10 Oh, damn. 23:13:15 1465 works, 1465 segfaults. 23:13:23 This should be 23:13:23 1465 works, 1467 segfaults. 23:13:54 I never understood what that rlimit thing in netbsd_init was supposed to do 23:14:15 in openbsd_init, we try to raise the soft limit to the hard limit, if it's lower 23:14:40 What is it in freebsd_init? 23:14:57 nothing to do with limits 23:15:25 What is the source file name (to save time)? 23:15:25 I don't think anyone other than netbsd and openbsd check resource limits at mmap() time 23:15:48 src/runtime/bsd-os.c 23:16:38 I'll patch it to try openbsd way. 23:17:05 or just remove that block and try it with no rlimit fiddling 23:17:17 That too. 23:17:35 unless you run it with a soft limit lower than the hard limit, there's no point 23:17:52 Anyway, I think that my softlimit is equal to hardlimit now. 23:19:02 Right, memory, data, and vmemory are "unlimited". 23:19:11 Highest available value. 23:29:54 tcr1 [~tcr@95-88-46-7-dynip.superkabel.de] has joined #sbcl 23:29:54 -!- tcr [~tcr@95-88-46-7-dynip.superkabel.de] has quit [Read error: Connection reset by peer] 23:31:12 tcr [~tcr@95-88-46-7-dynip.superkabel.de] has joined #sbcl 23:31:12 -!- tcr1 [~tcr@95-88-46-7-dynip.superkabel.de] has quit [Read error: Connection reset by peer] 23:31:20 -!- tcr [~tcr@95-88-46-7-dynip.superkabel.de] has quit [Client Quit] 23:36:40 I don't understand why rlimit is hardcoded there and why that value is chosen. 23:36:53 you're not alone 23:37:20 -!- sdemarre [~serge@91.176.87.217] has quit [Ping timeout: 248 seconds] 23:37:37 And I think that playing with rlimit behind curtain is very bad idea. 23:39:12 OTOH, my original problem is solved, I'm able to procede. 23:39:17 Thank you! 23:39:36 so, what did you change? 23:39:56 did you make it the same as for openbsd? 23:39:57 "sbcl --dynamic-space-size 1465" helps. 23:40:11 No, that is being tested. 23:40:14 ok 23:41:16 I'm building patched SBCL. I'll report when it's ready. 23:41:40 In case I go to sleep and forget it, remind me tomorrow or at any later time. 23:47:22 rpg [~rpg@216.243.156.16.real-time.com] has joined #sbcl