00:00:00 That happens sometimes, yes. 00:00:05 Anything interesting in there? 00:01:11 the if/if versus constant folding ordering change 00:01:26 recognize (if foo [leaf] [same leaf]) 00:01:56 constant-lvar-p on more singleton types 00:02:02 and convert singleton type tests to EQL checks. 00:03:36 Given the way these things tend to have follow-on effects, perhaps a greater focus on fixing compiler problems is in order? 00:03:50 sounds likely. 00:04:16 Even the low-hanging fruit opens up possibilities. 00:04:38 of course, I've been expecting to merge the SSE stuff in too for a while... 00:04:42 /nick sid 00:04:43 I'm probably going to be tidying up the TLS-index fixup stuff for commit soon. 00:56:35 Fare [~Fare@64.119.159.126] has joined #sbcl 01:02:13 hum. 01:02:20 I'm trying to fix this char-size issue. 01:02:30 What the meaning of :default as an external-format? 01:02:48 dynamically the default as this default change, or statically the default at the type the stream is created? 01:02:59 doesn't buffering prevent the former, anyway? 01:04:26 so assuming the latter, shouldn't it be stored in a slot what it was? 01:04:58 is there any reason the external-format slot should be kept :default rather than this thing that replaces it? 01:13:33 *Fare* compiles a local sbcl with this fix... 01:22:08 Also, is there any reason not to :length 1 :level 1 in the initial write from pprint-backq-comma 01:22:20 or (min 1 *print-length*), etc. 01:24:32 I can't imagine a reason why it would print a different first character (except, admittedly, where user-defined print-object methods do something really funky, but then, so can they based on other factors). Oh, yeah, one reason: a circle could cause a #= in the complete write that is absent in the local write, but it's conservative so not a problem. 01:24:41 anyway. 01:24:48 just a suggestion 02:13:13 ... What the /hell/? I just had fourteen contribs fail, and when I checked the most recent one the message was about #p"~/.clc/systems/" not being an absolute pathname. 02:13:59 Now, this is the contrib build, so it's being run --no-sysinit --no-userinit. 02:14:38 I am running on Debian, but I try not to use any lisp stuff from there. 02:20:42 cmpitg [~cmpitg@113.22.123.211] has joined #sbcl 02:27:54 nyef: oops. Might have been a problem with the new ASDF. 02:28:01 Does SBCL do ~/ expansion ? 02:28:09 No, it doesn't. 02:28:33 oh. common-lisp-controller might be having a messed up configuration file 02:28:56 and ASDF is both clever enough to find it's messed up, and stupid enough to bork rather than warn and ignore. 02:29:15 I'm doing an SBCL build, it shouldn't even be /checking/ for the configuration file. 02:29:47 nyef: export CL_SOURCE_REGISTRY='(:source-registry :ignore-inherited-configuration)' 02:30:05 maybe this ought to be in the build scripts. 02:30:40 Mmm. I'll open a bug in the morning. 02:31:05 (Meanwhile, I'm trying to find out where the bogus config file came from, so I can shoot it.) 02:33:02 Lovely. It came from common-lisp-controller, which was brought in by clisp, which didn't even install correctly and had to be taken out, which was brought in by xindy, which was brought in by some TeX package. 02:33:02 see in /etc/common-lisp/source-registry.d/ 02:33:23 sorry .conf.d 02:34:13 And an "apt-get purge common-lisp-controller" got rid of the entire /etc/common-lisp/ directory. Score! 02:36:16 congrats :) 02:38:41 Thanks. 02:43:58 nyef: how do I read a sbcl run-tests output to determine what the errors are? 02:45:49 ok, found the issue -- now to recompile the whole thing :-( 02:51:54 You might find a quick "sh ./make-target-contrib.sh" to be a shortcut. 02:52:51 The other part of this, though, is that debian puts a pathname in a config file that SBCL can't handle. 02:53:20 Which then becomes a nasty surprise for users. 02:55:31 ok, so I have two diffs. Should I submit them to the list? 02:56:31 May as well. 02:56:58 oh - and what's the policy for temporary files during tests? 02:58:14 I have no idea, actually. 02:58:22 I think sb-posix creates some, though. 03:09:16 kclifton [~kclifton@S010600123ff34d7d.cg.shawcable.net] has joined #sbcl 03:12:51 -!- kclifton [~kclifton@S010600123ff34d7d.cg.shawcable.net] has quit [Remote host closed the connection] 03:15:14 kclifton [~kclifton@S010600123ff34d7d.cg.shawcable.net] has joined #sbcl 03:15:49 -!- kclifton [~kclifton@S010600123ff34d7d.cg.shawcable.net] has quit [Remote host closed the connection] 03:16:23 kclifton [~kclifton@s198-166-45-245.ab.hsia.telus.net] has joined #sbcl 03:18:36 kclifton_ [~kclifton@S010600123ff34d7d.cg.shawcable.net] has joined #sbcl 03:20:58 -!- kclifton [~kclifton@s198-166-45-245.ab.hsia.telus.net] has quit [Ping timeout: 250 seconds] 03:20:58 -!- kclifton_ is now known as kclifton 03:31:16 well, that was an interesting failure: too many process to fork and run the test suite. 03:32:09 -!- kclifton [~kclifton@S010600123ff34d7d.cg.shawcable.net] has quit [Quit: kclifton] 03:35:53 Heh. 03:38:09 *Fare* run tests after his latest fix. 03:39:21 Ugh. My main system doesn't know where my public git repository is. 03:40:20 nyef pasted "Move pack.lisp to its own package" at http://paste.lisp.org/display/115430 03:53:34 -!- nyef [~nyef@pool-70-109-147-129.cncdnh.east.myfairpoint.net] has quit [Quit: G'night all.] 03:56:53 ok, only expected failures now. 03:58:16 should I send patch to launchpad, the list, or both? 03:59:55 Fare: most people on the list follow launchpad, I think. 04:00:31 ok 04:08:23 ok, now for my backquote pretty printing optimization - should I create a "bug" for it, or post it on the list? 04:08:36 (put my patch on launchpad for the file-position bug) 04:09:01 no idea. 04:09:39 I'll send to the list 04:15:59 -!- Fare [~Fare@64.119.159.126] has quit [Ping timeout: 265 seconds] 04:29:43 woah... 04:30:02 I'm playing with hash-based double dispatch, and... 04:30:59 64 classes, with a flat hierarchy, 65 methods: one catch-all, and 64 for arguments of the same class. 04:31:21 Fare [~Fare@64.119.159.126] has joined #sbcl 04:32:05 I've got it all represented in a vector of length 131. 05:13:14 minion: memo for nyef: 1.0.43.47 should fix both bugs in lp#309063 (the bad shift and the ugly type test) 05:13:14 Remembered. I'll tell nyef when he/she/it next speaks. 05:15:24 Krystof [~csr21@81.174.155.115] has joined #sbcl 05:15:24 -!- ChanServ has set mode +o Krystof 05:15:40 Xof: any thought on the pp-backq patch? 05:15:53 also, anyone to commit the file-position patch? 05:42:02 rbarraud [~rbarraud@118-92-1-3.dsl.dyn.ihug.co.nz] has joined #sbcl 05:47:53 -!- Fare [~Fare@64.119.159.126] has quit [Quit: Leaving] 06:06:01 Blkt [~user@93-33-133-222.ip44.fastwebnet.it] has joined #sbcl 06:06:45 good day everyone 06:22:39 mega1 [~quassel@pool-05177.externet.hu] has joined #sbcl 07:32:04 -!- mega1 [~quassel@pool-05177.externet.hu] has quit [Ping timeout: 264 seconds] 07:47:50 stassats [~stassats@wikipedia/stassats] has joined #sbcl 07:53:46 mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has joined #sbcl 08:02:48 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl 08:02:48 -!- ChanServ has set mode +o nikodemus 08:07:18 -!- mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has quit [Ping timeout: 240 seconds] 08:15:02 mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has joined #sbcl 08:23:34 good morning 08:26:38 -!- lnostdal [~quassel@167.80-203-136.nextgentel.com] has quit [Quit: ssd fw + os upgrade .. bye bye world(?) .. :)] 08:30:20 -!- cmpitg [~cmpitg@113.22.123.211] has quit [Quit: leaving] 10:02:48 -!- rbarraud [~rbarraud@118-92-1-3.dsl.dyn.ihug.co.nz] has quit [Remote host closed the connection] 10:14:29 mbohun [~mbohun@ppp115-156.static.internode.on.net] has joined #sbcl 10:16:48 -!- mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has quit [Ping timeout: 240 seconds] 10:17:56 mega1 [~quassel@catv4E5CABA2.pool.t-online.hu] has joined #sbcl 10:22:11 attila_lendvai [~attila_le@adsl-89-135-203-148.monradsl.monornet.hu] has joined #sbcl 10:33:42 -!- attila_lendvai [~attila_le@adsl-89-135-203-148.monradsl.monornet.hu] has quit [Quit: Leaving.] 10:36:50 hargettp [~anonymous@96.237.125.187] has joined #sbcl 10:43:43 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 10:47:22 -!- svr1 [~svr@79.165.187.105] has quit [Quit: WeeChat 0.3.2] 10:55:13 nikodemus [~nikodemus@cs181058025.pp.htv.fi] has joined #sbcl 10:55:13 -!- ChanServ has set mode +o nikodemus 10:57:22 nyef [~nyef@pool-70-109-147-129.cncdnh.east.myfairpoint.net] has joined #sbcl 10:57:30 G'morning all. 10:57:30 nyef, memo from pkhuong: 1.0.43.47 should fix both bugs in lp#309063 (the bad shift and the ugly type test) 11:00:42 Nice. 11:03:26 -!- Blkt [~user@93-33-133-222.ip44.fastwebnet.it] has quit [Quit: Error: do not makunbound t please!] 11:11:32 -!- hargettp [~anonymous@96.237.125.187] has quit [Quit: hargettp] 11:15:48 hi nyef 11:21:33 There we go, bug filed. 11:21:36 Hello nikodemus. 11:24:26 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 276 seconds] 11:26:52 hey, who broke the build? 11:27:09 unhandled UNDEFINED-FUNCTION: The function SB-C::%INSTANCE-TYPEP is undefined. 11:27:10 # while loading the cold core 11:28:08 ... Within the past few hours? Had to be pkhuong, surely? 11:28:59 And the last build breakage I saw was Fare's fault, clearly. 11:30:29 Fare's? 11:31:10 Well, how /else/ would I be seeing a path like #p"~/.clc/systems/" in my build? 11:31:54 ouch 11:33:06 What's worse is that I didn't have common-lisp-controller installed anymore (it was brought in by a failed clisp install). 11:33:46 But the config files were still there. 11:37:18 is there a supported way to turn off the source registry stuff? or remove things from there? 11:37:45 Fare suggested some environment variable, as I mentioned in the bug report. 11:38:09 hm. i think (setf (source-registry) nil) should actually work 11:38:55 Shouldn't be /loading/ the files in the first place. 11:39:59 oh, this is interesting. 11:40:24 i think i broke my own build by installing a strangely broken sbcl 11:40:47 Heh. I build from known releases only at this point. 11:41:12 (Specifying which run-sbcl.sh to use as host.) 11:41:43 i don't understand the source-registry stuff at all. well, the basic idea, sure, but the implementation is wierdly complex 11:42:05 too complex for me to want to untangle it in my head 11:42:21 Yeah. I don't want to deal with ASDF at all. 11:51:30 *nyef* realizes that this source-registry thing has to be new in 2.009. 12:01:04 nyef: there's no "clc" in asdf.lisp 12:01:11 fe[nl]ix: Yes, I know. 12:01:35 fe[nl]ix: It was from a stale config file on my machine, but it should never have been loaded during an SBCL build. 12:02:14 (Should also never have been loaded, period, but that's another matter.) 13:10:59 stassats [~stassats@wikipedia/stassats] has joined #sbcl 13:31:38 more type system holes: https://bugs.launchpad.net/sbcl/+bug/659173 # rtoym brought this to my attention 13:33:59 haven't we already established that function types are mads unsafe? 13:35:09 I have a question. If a symbol's FTYPE is declared, shouldn't we be type-checking anything stashed as its SYMBOL-FUNCTION? 13:35:14 no reason not to make them better 13:35:31 nyef: that's what i'm about to add 13:36:04 style-warning for "maybe incompatible", error + continue restart for "definitely incompatible" 13:36:25 Something like that, yeah. 13:37:14 Any thoughts on paste 115430? 13:37:19 minion: Paste 115430? 13:37:20 Paste number 115430: "Move pack.lisp to its own package" by nyef in #sbcl. http://paste.lisp.org/display/115430 13:37:44 i'm just not sure what to do about return types as csubtypep considers (FUNCTION () (VALUES STRING &REST T)) disjoint from (FUNCTION () (VALUES STRING &OPTIONAL)) 13:37:47 Probably not something to go in mainline soon, but... 13:38:34 That is... odd. But then, the &OPTIONAL version is clearly a subtype of the &REST T version. 13:40:07 the question is: can the stack be messed up if they are considered compatible? 13:42:21 ... Not obviously so? 13:45:47 don't forget that function types are associated with _use_ not objects 13:46:08 they're the opposite of whichever of contravariant and covariant is the normal case 13:47:29 Krystof: except they're associated with objects too -- or rather should be, if (setf symbol-function) is to be anything but a massive hole in the type-system 13:48:06 no, because the declaration is only active at the point of (named) use 13:49:20 i'm not sure what you're saying 13:49:23 that is, it's at the point of use (call-site) that type checks should happen, not the setting of the function object 13:49:29 nikodemus: build worked for me on x86 and x86-64... 13:49:44 pkhuong: it was a local problem. false alarm 13:50:03 assume (declaim (ftype (function (t) (values string &optional)) foo) 13:50:23 then (defun foo (x) 3) is legal, (foo 17) is not 13:50:35 nyef: does the type test work better on PPC? (although I now realize that type tests and checks aren't always the same) 13:51:19 pkhuong: I'm actually in the middle of something, about to build. After that, I'll rebase and check the type-tests. 13:51:24 (defun foo (x) (declare (integer x)) (make-array x :element-type 'character)) is legal, even though it doesn't accept all types of arguments 13:51:28 but only integers 13:51:30 k. 13:52:40 lnostdal [~Lars@167.80-203-136.nextgentel.com] has joined #sbcl 13:52:44 I can't remember why we don't systematically check call sites of named functions with active ftype declarations (for both arguments and values) and funcall of variables with type function declarations 13:52:51 but that's the direction I would work in 13:53:13 Krystof: because it would be insanely expensive and opposite of the way the system is built? 13:53:43 the way Python currently works is that an FTYPE declaration affects the definition, and call-sites trust it 13:54:01 So, perhaps the ftype declaration is saying that the symbol-function is /either/ holding such-and-such a type of function or unbound? 13:55:04 nikodemus: right, but my contention is that that's because the CMUCL Gods didn't understand FTYPE 13:55:24 I don't see why it would be more insanely expensive than other declarations-are-assertions 13:55:45 Krystof: possible. because function types are complex. complex type-checks are expensive 13:55:51 don't check the function type 13:55:56 there is no function type to check, anyway 13:56:16 we really want to treat function types like dynamically-checked contracts. 13:56:27 you check that the argument types are compatible with the arguments in the ftype declaration, and the results are compatible with the values in the ftype declaration 13:56:59 but then we run into issues with EQness. 13:57:38 think (locally (declare (ftype (function (integer) string) foo)) (foo 3)) => (multiple-value-bind (x &rest rest) (foo (the integer 3)) (the string x) (values-list (cons x rest))) 13:57:41 Krystof: which means duplicating the argument type-checks on both sides of the call? 13:58:19 kclifton [~kclifton@s198-166-45-245.ab.hsia.telus.net] has joined #sbcl 13:58:32 only if the ftype declaration and the function declaration have exactly the same types 13:58:36 it is legal for them not to 13:58:45 nikodemus: you can check the %simple-fun-type too. 13:59:01 pkhuong: that's what would be expensive 13:59:04 again, the ftype declaration refers to a _call site_ 13:59:15 Krystof: sure. but the common case is that they are the same 13:59:25 the common case is no ftype declaration at all 13:59:48 Wait, wait. Why a call site and not a function binding? 13:59:50 granted. but in the presence of one, the common case is a global proclamation 14:00:02 nyef: (locally (declare) ...) 14:00:19 anywyas, given my available amount of time, i'd right now rather plug the gaping holes than leave them open pending refactoring of the way we typecheck calls 14:00:25 pkhuong: Which is a declaration that, within the body of the LOCALLY, the binding has these properties. 14:00:30 no 14:01:33 "Thus, an ftype declaration for a function describes calls to the function, not the actual definition of the function." 14:01:38 nyef: function type declarations constrain the way the function is called. 14:02:15 That's what makes it possible to check them without solving HALT. 14:02:16 Krystof: Where? 14:02:35 clhs function 14:02:35 http://www.lispworks.com/reference/HyperSpec/Body/a_fn.htm 14:02:39 (the system class page) 14:03:01 Would have helped if that were mentioned on the FTYPE page. 14:13:04 aside from the work involved in refactoring call checking to be clhsly correct i'm concerned about doubling of the type-checks -- both in code-size and work done 14:13:56 well, for sbcl-internal :declared ftypes we can cheat 14:14:01 defknowned 14:14:02 Maybe we should just defer the whole issue for a bit? 14:14:36 I recognize that it's not obvious how to get it right 14:15:36 if such a work is undertaken, i would wish that it also included (declaim (static-type ...)) or similar, which would allow call-sites to trust the implementation 14:16:22 though good news is that i have a patch cooking that is actually a small step in direction of the kind of checking scheme you're talking about 14:31:32 Okay, the fundamental issue is that FUNCTION types are specified to be unusable for discrimination. Period, end of story. 14:41:23 -!- mbohun [~mbohun@ppp115-156.static.internode.on.net] has quit [Ping timeout: 276 seconds] 14:53:08 mbohun [~mbohun@ppp115-156.static.internode.on.net] has joined #sbcl 15:11:34 mm.. Krystof do you have a vague idea as to whether funding for equipment can be used to buy computer time "in the cloud"? 15:19:49 in academia? You can include bids for computer time on supercomputers, so in general, yes. In an already-running grant? Phone up the grant body and say "we didn't think of this, but it seems like a good idea" 15:21:31 k. The IT dept seems to think it's a great idea, but I don't think we're used to preparing grant reqs to rent resources instead of buying them. Another case of ambidextrous administration. 15:28:50 pkhuong: Maybe you could give some hints as to what definitely would have to be improved? 15:29:00 So that things could progress. 15:29:34 angavrilov: I haven't even looked at it. 15:30:17 Maybe something about your own patches at the base of the queue? 15:34:48 pkhuong: Incidentally, while discussing the name for cl-simd (the contrib), nikodemus seemed to like the :sse2 feature name currently used by ECL core. For sbcl it is currently pushed by the contrib itself. 15:36:53 we need a *features* policy document... but i think :sse2 is a good candidate for *features* -- and we should probably put all :os-provides-foo crap elsewhere but allow #!+/- to see them 15:37:08 hear, hear! 15:38:16 and every second library thinks it's a great idea to put itself into *features* 15:38:34 And then there's trivial-features, which /really/ screws things up. 15:42:08 Then I wonder how hackish is pushing features from rc files to configure libraries... :) 15:42:43 The "correct" thing is to push them to a local binding of *features* around the call to LOAD. 15:44:00 For example, after my refactorings of cl-mpi, on ECL pushing :mpicc before the asdf definition is loaded makes it directly link to the MPI libs instead of using the usual cffi stuff. 15:44:33 Maybe there is a better way 15:45:27 There's a case to be made for *features* being a mechanism for a simpler world. 15:48:21 I think there is an unfilled niche for providing configuration to packages at build-time in a standard way (i.e. without any kind of source editing and so on) 15:48:59 ./configure! 15:49:08 *features* can be used as a surrogate for boolean-only flags 16:18:47 attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has joined #sbcl 16:22:32 -!- mbohun [~mbohun@ppp115-156.static.internode.on.net] has quit [Quit: Leaving] 17:32:38 Blkt [~user@dynamic-adsl-94-37-236-50.clienti.tiscali.it] has joined #sbcl 18:05:12 -!- nikodemus [~nikodemus@cs181058025.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 18:46:05 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl 18:46:05 -!- ChanServ has set mode +o nikodemus 19:33:48 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 19:43:54 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl 19:43:54 -!- ChanServ has set mode +o nikodemus 19:56:16 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 20:07:05 ... Wow, the definition of the list form of the FUNCTION type-specifier is stupid. 20:08:33 in what way ? 20:09:01 The logic in the prose description is wrong. 20:09:37 I had thought that the intersection logic was also broken, but I now think that that might be right. 20:17:40 nikodemus [~nikodemus@cs181199216.pp.htv.fi] has joined #sbcl 20:17:40 -!- ChanServ has set mode +o nikodemus 20:37:10 -!- attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has quit [Quit: Leaving.] 21:17:36 DanLentz [~danlentz@c-68-32-54-29.hsd1.nj.comcast.net] has joined #sbcl 21:27:43 -!- DanLentz [~danlentz@c-68-32-54-29.hsd1.nj.comcast.net] has quit [Quit: Colloquy for iPhone - http://colloquy.mobi] 21:52:34 -!- nikodemus [~nikodemus@cs181199216.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 21:54:59 rbarraud [~rbarraud@118-92-1-3.dsl.dyn.ihug.co.nz] has joined #sbcl 21:57:18 -!- FareWell is now known as Fare 22:01:21 -!- cmm- [~cmm@bzq-79-182-202-208.red.bezeqint.net] has quit [Remote host closed the connection] 22:01:40 cmm [~cmm@bzq-79-182-202-208.red.bezeqint.net] has joined #sbcl 23:12:05 -!- kclifton [~kclifton@s198-166-45-245.ab.hsia.telus.net] has quit [Quit: kclifton] 23:12:18 attila_lendvai [~attila_le@catv-89-133-169-124.catv.broadband.hu] has joined #sbcl 23:43:42 -!- Blkt [~user@dynamic-adsl-94-37-236-50.clienti.tiscali.it] has quit [Remote host closed the connection] 23:56:18 skalawag [~user@c75-111-102-202.amrlcmta01.tx.dh.suddenlink.net] has joined #sbcl