00:07:55 -!- ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has quit [Ping timeout: 245 seconds] 00:12:47 i wonder whether anybody depends on (defstruct (x (:include hash-table))) 00:13:05 -!- Bike [~Glossina@wl-nat101.it.wsu.edu] has quit [Ping timeout: 246 seconds] 00:13:12 nice 00:19:59 *stassats* tries to make it sealed 00:20:08 Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has joined #sbcl 00:26:10 -!- echo-area [~user@114.254.104.35] has quit [Remote host closed the connection] 00:27:07 that doesn't seem so easy 00:32:17 Xach [~xach@pdpc/supporter/professional/xach] has joined #sbcl 00:44:38 *stassats* removes some other 32K from the core, that ought to clear some space for structure accessors 00:52:04 -!- slyrus [~chatzilla@173-228-44-92.dsl.static.sonic.net] has quit [Ping timeout: 264 seconds] 01:06:25 -!- segv- [~mb@95-91-243-202-dynip.superkabel.de] has quit [Remote host closed the connection] 01:07:05 Is that problem Eric reported something where it should be fixed in in-the-wild code? 01:07:31 As far as I can tell it *is* finding bugs in defstruct forms, so I guess I should start sending out bug reports 01:07:36 *Xach* is so, so tired though 01:07:54 probably some random tester of his 01:08:46 Well, it affects real libraries that don't compile any more 01:09:27 i can't find whether keywords are allowed in defstruct 01:10:01 it already says "The symbols which name the slots must not be used by the implementation as the names for the lambda variables in the constructor function, since one or more of those symbols might have been proclaimed special or might be defined as the name of a constant variable." 01:11:32 whereas for defclass it's "The slot-name argument is a symbol that is syntactically valid for use as a variable name." 01:12:07 and it says syntactically, aren't keywords syntactically valid? but by being constants semantically not valid? 01:15:31 though, : is a part of the syntax and implies that it's a constant 01:16:18 how would a symbol not be "syntactically valid" as a variable name? 01:16:47 you can't bind constants 01:17:02 that's "semantic", though 01:17:09 :x is always a constant 01:17:47 barring the time it is unintended 01:18:31 though, you can't deconstify it still 01:19:14 or you can, makunbound doesn't say anything about constants 01:20:01 (unintern :x :keyword) (makunbound :x) can make it to be a valid slot name 01:20:56 but sbcl complains about just constants too, In DEFCLASS FOO, the slot name X is a constant. 01:45:00 -!- kwmiebach [~kwmiebach@xdsl-213-196-195-199.netcologne.de] has quit [Ping timeout: 245 seconds] 02:12:19 ASau` [~user@p54AFFE1B.dip0.t-ipconnect.de] has joined #sbcl 02:15:08 -!- ASau [~user@p5083D277.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds] 02:34:28 Xach: i send bug reports to cl-oauth, cl-snmp and cgn-devel 02:35:03 if i remember correctly, all of these had actual syntax errors (as opposed to using keywords as slot names) 02:35:50 s/send/sent/ 02:55:57 prxq_ [~mommer@x2f65451.dyn.telefonica.de] has joined #sbcl 02:57:27 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 02:59:18 -!- prxq [~mommer@x2f6655d.dyn.telefonica.de] has quit [Ping timeout: 245 seconds] 03:01:55 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 260 seconds] 03:12:50 echo-area [~user@182.92.247.2] has joined #sbcl 03:18:21 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 03:20:27 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 246 seconds] 03:26:39 -!- ASau` is now known as ASau 03:38:39 -!- christoph_debian [~christoph@ppp-88-217-41-153.dynamic.mnet-online.de] has quit [Ping timeout: 246 seconds] 03:51:59 christoph_debian [~christoph@ppp-46-244-231-19.dynamic.mnet-online.de] has joined #sbcl 04:16:21 ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has joined #sbcl 04:23:29 -!- kludge` [~comet@unaffiliated/espiral] has quit [*.net *.split] 04:23:29 -!- jsnell [~jsnell@ash.snellman.net] has quit [*.net *.split] 04:24:46 jsnell [~jsnell@ash.snellman.net] has joined #sbcl 04:26:17 kludge` [~comet@unaffiliated/espiral] has joined #sbcl 05:08:13 Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has joined #sbcl 05:20:21 -!- jaimef [jaimef@dns.mauthesis.com] has quit [Excess Flood] 05:28:31 jaimef [jaimef@dns.mauthesis.com] has joined #sbcl 05:29:43 -!- echo-area [~user@182.92.247.2] has quit [Remote host closed the connection] 05:51:31 -!- oleo [~oleo@xdsl-78-35-149-161.netcologne.de] has quit [Remote host closed the connection] 06:08:44 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 06:31:41 -!- yacks [~py@103.6.159.103] has quit [Ping timeout: 268 seconds] 06:41:13 sdemarre [~serge@91.180.77.67] has joined #sbcl 06:59:40 -!- jaimef [jaimef@dns.mauthesis.com] has quit [Excess Flood] 07:01:19 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 260 seconds] 07:06:05 -!- angavrilov [~angavrilo@217.71.227.190] has quit [Ping timeout: 272 seconds] 07:06:33 jaimef [jaimef@dns.mauthesis.com] has joined #sbcl 07:12:42 echo-area [~user@182.92.247.2] has joined #sbcl 07:13:14 -!- sdemarre [~serge@91.180.77.67] has quit [Ping timeout: 240 seconds] 07:39:36 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 07:59:45 -!- ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has quit [Ping timeout: 246 seconds] 08:12:58 I think that defstruct per se doesn't disallow keywords as slot names, and it's sort-of a reasonable idea 08:13:14 I wonder if the MOP slot names for defstructs should be the conc-name+slot-name 08:13:34 on the other hand, given the hilarious number of :copier and :constructor slots that this appears to uncover... 08:14:27 defstruct read in combination with the MOP would disallow keywords/constants as slot names 09:06:43 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 09:10:59 Krystof: do people use keywords at slot names? 09:11:07 I'd never have thought that to be allowed. 09:13:36 -!- prxq_ is now known as prxq 09:17:52 -!- echo-area [~user@182.92.247.2] has quit [Remote host closed the connection] 09:21:22 they do. One reason why it's reasonable with structures is that it avoids pointless symbol pollution in the given package 09:21:44 (defstruct foo :bar) avoids the useless symbol with name "BAR" being created 09:22:17 and since defstruct works basically with strings not symbols, the structure ends up being the same (foo-bar accessor, for example) 09:23:02 kwmiebach [~kwmiebach@xdsl-213-196-195-199.netcologne.de] has joined #sbcl 10:08:32 OK, I see 10:34:10 -!- kludge` [~comet@unaffiliated/espiral] has quit [Ping timeout: 245 seconds] 10:35:04 kludge` [~comet@unaffiliated/espiral] has joined #sbcl 10:50:50 -!- jaimef [jaimef@dns.mauthesis.com] has quit [Remote host closed the connection] 11:13:18 stassats [~stassats@wikipedia/stassats] has joined #sbcl 11:36:59 -!- scymtym [~user@ip-5-147-115-29.unitymediagroup.de] has quit [Ping timeout: 246 seconds] 11:49:04 -!- kwmiebach [~kwmiebach@xdsl-213-196-195-199.netcologne.de] has quit [Ping timeout: 264 seconds] 11:49:18 kwmiebach [~kwmiebach@xdsl-87-78-6-88.netcologne.de] has joined #sbcl 11:51:07 jaimef [jaimef@dns.mauthesis.com] has joined #sbcl 12:02:30 milanj [~milanj@cable-178-148-2-202.dynamic.sbb.rs] has joined #sbcl 12:39:13 Bike_ [~Glossina@gannon-wless-gw.resnet.wsu.edu] has joined #sbcl 12:40:25 -!- Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has quit [Ping timeout: 265 seconds] 12:44:29 yacks [~py@103.6.159.103] has joined #sbcl 12:45:44 -!- yacks [~py@103.6.159.103] has quit [Max SendQ exceeded] 12:46:02 yacks [~py@103.6.159.103] has joined #sbcl 12:55:45 -!- yacks [~py@103.6.159.103] has quit [Quit: Leaving] 13:11:44 segv- [~mb@95-91-243-185-dynip.superkabel.de] has joined #sbcl 13:12:21 Ok, this is a surprise to me: (probe-file "/etc/bogus-path/../profile") => nil but (probe-file "/etc/cron.d/../profile") => #p"/etc/profile" 13:14:08 clhs 19.2.2.1.3 13:14:09 Sorry, I couldn't find anything for 19.2.2.1.3. 13:15:03 clhs 19.2.2.4.3 13:15:03 Restrictions on Examining a Pathname Directory Component: http://www.lispworks.com/reference/HyperSpec/Body/19_bbdc.htm 13:15:23 aha 13:15:34 Xach: on Unix .. is :up, so all previous components must resolve 13:16:01 what about symbolic links? 13:16:09 the same 13:16:29 Thanks, I didn't realize the difference between :up and :back. I was using make-pathname already and it is an easy change. 13:17:17 *Xach* smells a lisptip 13:17:20 stassats: the path resolution starts with the first component, applying a substitution in case of symlink 13:17:33 fe[nl]ix: i had a multiple misreadings of things 13:18:05 read "semantic" as "syntactic", and "must resolve" as in (probe-file "/etc/bogus-path/../profile") should work 13:18:33 Xach: what you expected, «..» being :back, is how URIs behave 13:18:55 clisp, acl, and abcl give /etc/profile 13:19:34 that's severely against POSIX 13:19:56 for a different reason: (pathname-directory "/etc/bogus-path/../profile/") => (:ABSOLUTE "etc" "profile") 13:20:31 I'll submit a bug report to Franz 13:20:34 abcl might warrant a bug report 13:20:49 clisp don't care about bug reports, so i won't even bother 13:21:29 Hmm, bknr-web breaks in PCL now too, but with a different kind of error than the struct thing. 13:21:36 tell! 13:21:52 It's fundamentally in bknr-datastore 13:22:37 and a thing like (pathname-directory "/etc/bogus-path/../profile/") changing its behaviour can cause problem to somebody 13:22:40 Sorry not to test earlier. http://report.quicklisp.org/bknr-datastore/2013-11-06/failtail.txt 13:22:41 (I think I will resolve the struct thing by just treating structure-slot-definitions differently. It will be ugly but hey) 13:23:19 Xach: not a problem. I think people are relearning conservatism before doing sbcl upgrades :) 13:25:12 (probe-file (make-pathname :directory '(:ABSOLUTE "etc" "xxx" :back "profile"))) => ungood directory segment in NATIVE-NAMESTRING: :BACK 13:25:17 go figure 13:26:23 The BKNR thing involves a metaclass 13:26:52 Xach: in compute-slots (indexed-class) in indices/indexed-class.lisp 13:27:04 remove the sbcl from #+(or cmu sbcl) 13:27:27 but (merge-pathnames "x" (make-pathname :directory '(:ABSOLUTE "etc" "xxx" :back "profile"))) => #P"/etc/profile/x" 13:28:52 looks like :back is borked everywhere 13:29:37 Xach: that change should be backwards-compatible 13:29:49 :back can be resolved at make-pathname time 13:30:54 Krystof: thanks. 13:31:09 I have another one for you! 13:31:19 yay! 13:31:26 http://report.quicklisp.org/montezuma/2013-11-06/failtail.txt 13:31:59 i've seen that before 13:32:13 Is it an old bug caught by better analysis in SBCL? 13:32:14 it got mixed arguments in (AREF MONTEZUMA::I MONTEZUMA::RESULT) 13:32:30 yeah, that's not one of mine 13:32:35 not better analysis, just a different way of expanding (setf (aref ..)) 13:32:38 It compiled fine last month and I don't think it was changed, but I could be wrong. 13:32:42 it's mine, but it's not bad! (for once) 13:32:55 argh the backtrace has chicken-pox 13:33:04 you mean asdf? 13:33:17 I mean #10# #11# #12# 13:33:39 from asdf calls, it annoys me to no end 13:33:41 WELCOME TO THE WORLD OF ASDF 13:34:01 I apologize for the inconvenience 13:34:06 So, re montezuma, old bug in code newly caught? 13:34:11 yes 13:34:22 Thanks. I opened an issue on github for it. 13:34:27 yeah, should be (setf (aref result i) ...) 13:34:30 Now to open one for bknr-datastore 13:35:11 somebody told me about the montezuma thing, and they didn't open a bug for it! 13:35:50 I hope Xach gets a fortune in donations 13:36:07 Krystof: I'm writing a commit message for the :readers fix. Can you suggest how to word why the change is needed? 13:36:43 I haven't rattled the tip jar in a while. They're slow & steady. 13:37:06 maybe for one of these 13:37:14 It feels weird now that I am paid to write CL all day, and occasionally paid directly by Clozure for days spent hacking on Quicklisp. 13:38:14 Xach: sure. something like "effective slot definitions don't (in the MOP) have readers or writers; those are attached to direct slots. SBCL is now enforcing this, and this change is backwards-compatible because the default for the slots was NIL in any case." 13:38:18 ok, i see nothing stopping from resolving :back at make-pathname time, i'll conjure a fix sometime later today 13:38:48 oh yeah, you have an actual Lisp Job. Sometimes I forget those even exist 13:39:28 though, merge-pathnames may disagree 13:42:11 ok, resolve all :back except the first one after :relative 13:42:31 make sure you don't collapse :back :back into nothing 13:42:43 sure 13:44:01 Woo, hans merged the fix 13:45:16 it also says "Using :absolute or :wild-inferiors immediately followed by :up or :back signals" 13:46:10 sbcl doesn't 13:46:25 and when, at the time of creation or at the time of resolution? or merging? 13:47:52 echo-area [~user@123.112.232.137] has joined #sbcl 13:49:25 I think there's somewhere in the pathnames chapter that basically says "no errors are guaranteed to happen until the pathname touches the filesystem" or something 13:50:19 it makes sense to signal early 13:50:53 *stassats* awaits another barrage of broken code after prohibiting "/.." 13:50:56 not before runtime, please 13:51:50 fe[nl]ix: #p is resolved at read-time 13:52:56 no, it does not make sense to signal early 13:53:18 the pathnames can be used as objects, taken apart, inspected, and recombined 13:54:03 (make-pathname :directory 1) is an error, even if you can take it apart 13:54:16 :directory 1 violates the type constraints 13:54:28 and the latter you signal an error, the less chance it has to be noticed 13:55:21 if there's a pathname constructed that would cause an error if used, and it is never used, is there an error that must be brought to someone's attention? 13:55:27 maybe, of course 13:55:39 it may be used in two weeks 13:57:49 yacks [~py@103.6.159.103] has joined #sbcl 13:57:49 (truename (make-pathname :directory '(:absolute :up))) gives no error at all 13:58:01 absolutely fair enough to fix that 13:59:10 fair is not good enough, i want to what's right 14:01:17 i like the "if that is appropriate to the cultural conventions of the implementation." part 14:03:01 (error 'cultural-convention-error ...) 14:04:38 ha 14:05:17 cmucl does error on (make-pathname :directory '(:absolute :up)), but #P"/../" is alright 14:07:12 many implementations do, so, if (make-pathname :directory '(:absolute :up)) will signal an error people won't blame SBCL for breaking their portable code 14:07:44 lispworks repl signals an error on #p"/.." just after you type the last " 14:07:49 now, that may a bit too early 14:08:08 heh 14:12:35 /../ is perfectly fine according to POSIX 14:13:09 not according to clhs 14:13:47 i won't touch /.. right now, since i can't make up a consensus with myself 14:13:53 just deal with :back not working 14:15:25 the definition of truename as (if (streamp pathspec) (query-file-system pathspec :truename) (query-file-system pathspec :truename)) is puzzling, even taking the comment into account 14:40:56 oleo [~oleo@xdsl-78-35-147-183.netcologne.de] has joined #sbcl 15:08:44 why are there win32 pathname stuff on -win32? 15:09:56 and (equal (make-pathname :version 2) (make-pathname :version 3)) will be T on #-win32 and NIL #+win32 15:10:14 (see sb-impl::pathname=) 15:20:21 slyrus [~chatzilla@107.200.11.207] has joined #sbcl 15:28:05 -!- Bike_ is now known as Bike 15:32:07 stassats: i did report the aref thing in montezuma 15:33:43 Where? 15:34:46 i commented on the specific source line. in my experience, github will notify the committer via email, then 15:35:04 it may not show up as an issue, though; sorry 15:35:29 i reported the bknr-datastore thing (in form of an issue), as well :) 15:48:37 fisxoj [~fisxoj@2620:101:f000:9c00:224:7eff:feda:1209] has joined #sbcl 15:59:22 not having win32 stuff saves whole 64K! 16:01:01 down to 80,000,000 from 80,065,536? 16:01:06 bytes, that is. 16:01:46 from 50 16:02:15 for my set of sb-features, i like to keep things under 50 thousand bytes 16:02:55 45, not 50 16:03:32 after recent changes it dipped into 45056048, now i'm reclaiming it back to 44990512 16:05:00 i can't seem to move away from that number 16:09:41 re defstruct slot names, http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Issues/iss111-writeup.html may be a propos. 16:09:58 summary: no one knows. 16:10:49 I'm siding with Moon: default constructors should act like automatically constructed BOA constructors. 16:18:09 but they went with NOT-BOUND 16:21:14 stassats: I sort-of feel that all platforms should have access to every platform's pathname algebra 16:21:22 just that the default host should be different 16:21:32 it is not a strong feel, but a sort-of feel 16:22:10 Krystof: it would make sense, yes, but so far it isn't presented in any way 16:22:27 so, i'll disable it until someone find a way to use it 16:23:04 fair enough 16:24:10 *stassats* got a hold of a windows machine 16:24:15 and asdf is indeed broken 16:32:45 Krystof: did they? where is it specified? 16:36:16 ah, yes "The symbols which name the slots must not be used by the implementation as the names for the lambda variables in the constructor function" 16:36:43 which make no sense for BOA :\ 16:41:24 well... given that slots are named by the symbol-name, is that also true for BOA constructors? 16:43:44 attila_lendvai [~attila_le@92.47.248.110] has joined #sbcl 16:43:44 -!- attila_lendvai [~attila_le@92.47.248.110] has quit [Changing host] 16:43:44 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 16:49:40 -!- slyrus [~chatzilla@107.200.11.207] has quit [Ping timeout: 264 seconds] 16:53:04 -!- jaimef [jaimef@dns.mauthesis.com] has quit [Read error: Connection reset by peer] 17:02:19 looks like the solution for windows is to use pwd -W, not just pwd 17:03:24 -!- Xach [~xach@pdpc/supporter/professional/xach] has left #sbcl 17:03:42 jaimef [jaimef@dns.mauthesis.com] has joined #sbcl 17:11:01 -!- fisxoj [~fisxoj@2620:101:f000:9c00:224:7eff:feda:1209] has quit [Ping timeout: 245 seconds] 17:25:26 suddenly, i get unexpected success on windows for some pathname stuff 17:26:08 after the disablements 17:29:55 bah, asdf is still broken on windows 17:31:19 or i haven't updated my setup to the new asdf locations 17:32:04 indeed 17:44:37 slyrus [~chatzilla@107.200.11.207] has joined #sbcl 18:20:38 -!- jaimef [jaimef@dns.mauthesis.com] has quit [Remote host closed the connection] 18:48:58 perhaps ^ can be used as an escape character for pathnames on windows 18:49:13 \ doesn't do a good job 18:49:38 then again, it won't be portable anyhow and using explicit make-pathname is better 19:06:11 -!- Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has quit [Ping timeout: 272 seconds] 19:07:46 Bike [~Glossina@wl-nat109.it.wsu.edu] has joined #sbcl 19:09:33 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 19:10:17 jaimef [jaimef@dns.mauthesis.com] has joined #sbcl 19:28:19 fisxoj [~fisxoj@dyn-129-97-41-230.dynamic.uwaterloo.ca] has joined #sbcl 19:29:09 -!- jaimef [jaimef@dns.mauthesis.com] has quit [Remote host closed the connection] 19:29:36 jaimef [jaimef@dns.mauthesis.com] has joined #sbcl 19:35:52 rpg [~rpg@198-74-7-110.fttp.usinternet.com] has joined #sbcl 19:45:28 -!- slyrus [~chatzilla@107.200.11.207] has quit [Ping timeout: 264 seconds] 19:47:19 slyrus [~chatzilla@107.200.11.207] has joined #sbcl 19:50:26 edgar-rfx [~GOD@HSI-KBW-109-193-013-113.hsi7.kabel-badenwuerttemberg.de] has joined #sbcl 19:52:54 -!- specbot [~specbot@common-lisp.net] has quit [Disconnected by services] 19:52:59 specbot [~specbot@common-lisp.net] has joined #sbcl 19:55:40 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 264 seconds] 20:05:45 -!- Bike [~Glossina@wl-nat109.it.wsu.edu] has quit [Ping timeout: 244 seconds] 20:09:31 -!- edgar-rft [~GOD@HSI-KBW-109-193-013-113.hsi7.kabel-badenwuerttemberg.de] has quit [Remote host closed the connection] 20:09:35 -!- reb [user@nat/google/x-osgiblmgiwekeewt] has quit [Remote host closed the connection] 20:09:35 reb [user@nat/google/session] has joined #sbcl 20:09:35 -!- reb [user@nat/google/session] has quit [Changing host] 20:09:35 reb [user@nat/google/x-tpsvrbxcnbekpyuy] has joined #sbcl 20:09:36 -!- reb [user@nat/google/x-tpsvrbxcnbekpyuy] has quit [Remote host closed the connection] 20:09:36 reb [user@nat/google/session] has joined #sbcl 20:09:37 -!- reb [user@nat/google/session] has quit [Changing host] 20:09:37 reb [user@nat/google/x-johbjhdskpummlam] has joined #sbcl 20:16:25 Bike [~Glossina@wl-nat109.it.wsu.edu] has joined #sbcl 20:21:31 ferada [~ferada@37.221.196.86] has joined #sbcl 20:25:03 stassats [~stassats@wikipedia/stassats] has joined #sbcl 20:25:42 good evening, so how does/would sbcl handle cpu-specific features e.g. for something like the following / what is the general policy on that? http://paste.lisp.org/display/139808 20:26:37 you could do (:guard (member :popcount *backend-subfeatures*)) 20:28:02 i'm always planning on spending some time to make microarchitecture-specific more easy to define and to enable, but never get around to it 20:28:25 when is *backend-subfeatures* populated? (cos its empty for me) 20:28:38 by hand 20:29:37 ah, i see. thank you 20:30:14 thats something where looking at the cpuid automatically would probably come in handy 20:30:26 not really 20:31:17 i probably meant cpuinfo, popcnt is indicated with a flag 20:31:32 no, it's cpuid 20:31:40 but that would make the produced binary be specific to your current cpu 20:31:56 which is probably not what you want to happen automatically 20:32:22 another question answered :) 20:32:47 so the same decision for runtime doesn't exist? 20:33:11 i don't see it being worth it 20:33:24 yeah ... me neither when i think about it 20:34:05 a manual -march=native is worth it 20:35:24 runtime selectable stubs would make sense for SIMDiefied stuff, if sbcl had any 20:35:57 but it would only make sense for deployment 20:36:16 popcount as an assembly routine would make sense though 20:36:32 swapping that code at runtime might not be *too* hard 20:36:54 it's only marginally faster, at least on sandy bridge 20:37:52 is it possible for a macro to determine whether an entry of the :funs slot of the lexical environment will be a function or a closure? 20:38:29 scymtym_: nope. it might not be impossible to determine when something will definitely not be a closure. 20:39:20 pkhuong: i see, thanks 20:42:50 what '(:absolute "x" "y" :up :back) would mean? 20:43:25 looks like :back can't be resolved at creation time 20:43:46 -!- edgar-rfx is now known as edgar-rft 20:44:06 i wanted to avoid having directories with :back in them, doesn't seem possible anymore 20:48:32 sdemarre [~serge@91.180.77.67] has joined #sbcl 20:49:52 pkhuong: would (sset-empty (lambda-calls-or-closes CLAMBDA)) be sufficient (although not necessary)? 20:53:09 ok, i'm really not sure how to handle '(:absolute "x" "y" :up :back), we're just translating :up into .., but :back, being syntactic, can't be translated into .. 20:53:14 it would have to be split up 20:53:22 nobody would probably use it 20:53:51 huh? isn't '(:absolute "x" "y" :up :back) the same as '(:absolute "x" "y")? 20:55:15 not if /x/y -> /foo/bar I think 20:55:31 I thought :back was supposed to just mean syntactically, remove the last element. 20:55:45 huh 20:55:46 whereas :up traverses the actual filesystem. 20:56:03 what would :back :back mean then? 20:56:12 remove the last two elements 20:56:16 no, it means "go upwards in directory structure" 20:56:36 foom: that's inconsistent with your previous answer 20:56:40 No it's not 20:56:49 scymtym_: I don't think that's computed at macroexpansion-time. 20:56:57 well no ok it's not absolutely inconsistent 20:57:16 " :up differs from :back only in file systems that support multiple names for directories" 20:57:23 '(:absolute "x" "y" :up) is "/x/y/../" 20:57:34 not really 20:57:52 "if the resulting list contains a string or :wild immediately followed by :back, both of them are removed." 20:57:57 clhs merge-pathnames 20:57:57 http://www.lispworks.com/reference/HyperSpec/Body/f_merge_.htm 20:58:02 it's the directory you get when starting at /x/y/ and going up one directory level semantically 20:58:14 :back doesn't remove itself or :up 20:58:34 clhs 19.2.2.4.3 20:58:35 Restrictions on Examining a Pathname Directory Component: http://www.lispworks.com/reference/HyperSpec/Body/19_bbdc.htm 20:58:49 Krystof: that is what /x/y/../ means 20:59:14 in posix we notate that as /x/y/../ but that doesn't mean that it's a directory with three components the last of which is ".." 20:59:15 :back removing an :up just doesn't make any sense 20:59:41 it's a place in the filesystem, call it '(:absolute "x") in the common case 20:59:54 Shrug. I don't see why it doesn't make any sense. 21:01:03 :back doesn't remove :back 21:01:16 neither does :up remove :up 21:01:21 :up never removes anything 21:01:39 :up is "..", which, because of symlinks, you can't do anything to without probing the filesystem 21:02:09 pkhuong: it seems to work in some cases (http://paste.lisp.org/display/139809) and would like to only use the information for a particular best-effort optimization 21:04:16 CLHS says that :back doesn't remove :ups, but if it were silent on the issue, it would still makes zero sense to do so 21:04:48 IMO it makes fine sense: other languages have similar things to syntactically remove a component of the path. 21:05:00 They don't treat ".." any differently than "foo" 21:07:04 maybe other langauges have :remove-previous component, but it's clearly said that :up and :back is the same, and only differ in the presence of symlinks 21:08:05 if you merge a path ending in :up, and a path beginning in :back, and the will suddenly cancel each other, that would be a surprise 21:09:09 CLHS also says that :back doesn't depend on the filesystem. Which, if you don't allow it to remove the :up, it now does. 21:09:16 It's no longer a syntactic construct 21:09:45 :up depends on the filesystem, not :back 21:11:04 after you resolve :up, then :back can perform its syntactic tricks 21:13:57 rpg_ [~rpg@198-74-7-110.fttp.usinternet.com] has joined #sbcl 21:14:54 it also says "to resolve a pathname containing :up to a pathname whose directory component contains only :absolute and strings requires probing the file system." 21:15:50 -!- rpg [~rpg@198-74-7-110.fttp.usinternet.com] has quit [Ping timeout: 240 seconds] 21:16:19 Am I wrong to think that (merge-pathnames (make-pathname :directory '(:relative "frob")) (make-pathname :directory '(:absolute "foo" "bar" :up))) 21:16:30 should result in '(:absolute "foo" "bar" :up "frob")? 21:18:35 'cause it doesn't on ccl or clisp; they return (:ABSOLUTE "foo" "frob"), as if it said :back. 21:19:05 -!- rpg_ [~rpg@198-74-7-110.fttp.usinternet.com] has quit [Ping timeout: 272 seconds] 21:23:26 clisp treats :up as :back 21:23:50 so does ccl 21:24:50 Well, that seems bogus. ;p 21:26:03 seems like only lispworks doesn't remove :up with :back 21:26:32 while treating :up as symlink-following, that is 21:26:44 *pkhuong* suggests a new channel: ##cl-pathnames 21:27:47 -!- sdemarre [~serge@91.180.77.67] has quit [Ping timeout: 246 seconds] 21:28:02 i can't see anybody using both :up :back, only if it's merged with two unrelated pathnames 21:29:02 almost nobody actually uses :back at all 21:30:56 well, if it was broken and nobody complained, then let it be like it is, i just need to fix (truename (make-pathname :directory '(:absolute "x" :back))) 21:31:09 because it doesn't seem like two people can agree on anything regarding pathnames 21:31:25 not even mentioning different implementations 21:33:48 even though it's made clear by ":up differs from :back only in file systems that support multiple names for directories, perhaps via symbolic links." 21:34:28 (i'm just too lazy to implement the splitting algorithm) 21:35:02 Well, I don't think it's clear at all. I think that's a very indirect way of saying it, that perhaps indicates nobody even thought about the issue at all. 21:35:36 But, +1 for defaulting to leaving things the way they work currently, whatever that is. :P 21:35:51 it is a mess 21:36:10 only lispworks gets it right by me 21:37:24 and merge-pathnames also says that :back after "a string or :wild" removes it 21:49:29 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 272 seconds] 21:54:12 Sagane [~Sagane@177.100-226-89.dsl.completel.net] has joined #sbcl 22:03:23 -!- ASau [~user@p54AFFE1B.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 22:05:19 ASau [~user@p54AFFE1B.dip0.t-ipconnect.de] has joined #sbcl 22:06:44 -!- fisxoj [~fisxoj@dyn-129-97-41-230.dynamic.uwaterloo.ca] has quit [Ping timeout: 260 seconds] 22:17:11 scymtym [~user@ip-5-147-115-29.unitymediagroup.de] has joined #sbcl 22:42:22 -!- prxq [~mommer@x2f65451.dyn.telefonica.de] has quit [Quit: Leaving] 23:00:33 -!- Sagane [~Sagane@177.100-226-89.dsl.completel.net] has quit [Read error: Connection reset by peer] 23:08:35 -!- oleo [~oleo@xdsl-78-35-147-183.netcologne.de] has quit [Ping timeout: 246 seconds] 23:10:19 stassats [~stassats@wikipedia/stassats] has joined #sbcl 23:15:49 -!- milanj [~milanj@cable-178-148-2-202.dynamic.sbb.rs] has quit [Quit: Leaving] 23:21:28 oleo [~oleo@xdsl-78-35-168-216.netcologne.de] has joined #sbcl 23:57:03 -!- kwmiebach [~kwmiebach@xdsl-87-78-6-88.netcologne.de] has quit [Ping timeout: 240 seconds] 23:57:59 kwmiebach [~kwmiebach@xdsl-87-78-0-67.netcologne.de] has joined #sbcl