02:12:30 -!- milanj [~milanj_@79-101-204-106.dynamic.isp.telekom.rs] has quit [Quit: Leaving] 02:23:36 Fare [~Fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has joined #ccl 02:23:37 hi 02:37:58 Hi! 02:44:45 Well, good night for me, now. :-) 02:44:54 Prompted by pcos, I'm trying to debug logical pathnames with asdf 02:44:56 it's a mess 02:45:36 Fare: by the way, usually pathnames to fasl files are logical pathnames when compiling with ccl. 02:46:04 (that's not too cool, since emacs or slime don't understand them AFAIK). 02:46:21 But otherwise I'm also in favor of logical pathnames in general. 02:46:40 Fare: the first thing to solve, is a good portability layer. 02:47:12 looks like string-to-pathname is not designed to work well when *default-pathname-defaults* is a logical pathname 02:47:13 Eg. translating a pathname built in upper case with :case :common to physical will give on unix systems either upper case or lower case pathnames. 02:47:45 You won't get anything good if you don't ensure that they behave and translate the same everywhere first. 02:48:15 or rather - it expects a logical pathname style of string. 02:48:28 :-/ 02:48:30 but find-load-file feeds it the resolved string 02:48:54 logical pathnames aren't logical, and certainly aint portable. 02:49:22 My solution would be to take logical pathname, but translate them to physical pathnames as soon as possible. 02:51:24 The simple-component-name in the grammar can be a string or symbol. How can we distinguish a string containing a logical pathname (fragment?) from a physical pathname? 02:52:05 Is there a way to specify that the system uses logical pathname instead of physical pathname for the components? 02:53:21 (:file "toto;titi" (:depends-on "toto/tata")) Is there a file named 'toto;titi' or is that a logical pathname fragment? 02:53:36 That said, Good night! 03:11:16 -!- alms_ [~alms_@209-6-130-32.c3-0.bkl-ubr1.sbo-bkl.ma.cable.rcn.com] has quit [Quit: alms_] 03:12:53 pjb: asdf has (asdf:system-relative-pathname ...) that plays this role. 03:13:52 in ASDF, the components use a portable syntax with / for directory separator -- independently from the syntax of directories on this filesystem. 03:14:14 (or rather, implementation and host, I should say) 03:15:56 So the problem would be that system-relative-pathname builds a physical pathname, but Pascal's customized code would expect a logical pathname? One cannot go back to logical pathname once we have a physical one (or very difficultly and haphazardly). 03:17:00 The solution would be to use logical pathnames internally. Hence what I said at the beginning, that can work only if we have consistent translations to each target plateforms (there are only two: unix and MS-Windows). 03:17:53 One advantage would be some simplification, eg. there could be a logical pathname FASL where the fasl would be stored, and it would be easy to configure logical pathname translations to map it wherever we want. 03:23:08 That would also mean that to be conforming, simple-component-names should be uppercased (and files should be lowercased on unix), unless we can de-facto standardize :case :local or mixed case logical pathnames and their translation. 03:23:37 (personnaly, I wouldn't mind upcasing them, but people would cringe. 03:35:18 no, on CCL, the problem is that (load "foo:a;b.asd") while *default-pathname-defaults* is #p"foo:a;" fails miserably. 03:36:29 (let ((*default-pathname-defaults* #P"ASDF:test;")) (ccl::FIND-LOAD-FILE #P"ASDF:test;test-force.asd.newest")) 04:56:50 -!- Fare [~Fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has quit [Ping timeout: 246 seconds] 06:57:13 jdz [~jdz@193.206.22.97] has joined #ccl 07:32:21 -!- rme [~rme@50.43.137.11] has quit [Quit: rme] 08:02:21 -!- krrrcks [~krrrcks@krrrcks.de] has left #ccl 14:42:02 alms_ [~alms_@173-162-137-153-NewEngland.hfc.comcastbusiness.net] has joined #ccl 15:06:48 Fare [~Fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has joined #ccl 15:32:05 -!- jdz [~jdz@193.206.22.97] has quit [Ping timeout: 246 seconds] 15:42:50 rme [~rme@50.43.137.11] has joined #ccl 16:18:14 -!- gbyers [~gb@c-68-84-152-249.hsd1.nm.comcast.net] has quit [Ping timeout: 260 seconds] 18:13:24 -!- pjb [~t@81.202.16.46.dyn.user.ono.com] has left #ccl 18:51:23 -!- billstclair [~billstcla@unaffiliated/billstclair] has quit [Quit: Linkinus - http://linkinus.com] 18:51:49 billstclair [~billstcla@p-74-209-20-105.dsl1.rtr.chat.fpma.frpt.net] has joined #ccl 18:51:49 -!- billstclair [~billstcla@p-74-209-20-105.dsl1.rtr.chat.fpma.frpt.net] has quit [Changing host] 18:51:49 billstclair [~billstcla@unaffiliated/billstclair] has joined #ccl 19:00:37 pjb [~t@81.202.16.46.dyn.user.ono.com] has joined #ccl 19:00:55 save-application has a :init-file parameter documented as "The pathname of a Lisp file to be loaded when the image starts up. You can place initialization expressions in this file, and use it to customize the behavior of the Lisp system when it starts up." 19:00:55 19:01:19 Ok, but how can I specify a pathname relative to the homedir of the user that will start the application up, not of the user that is generating the application? 19:01:44 #P"~/application-init.lisp" reads as /home/pjb/application-init.lisp 19:03:13 (pathname "~/application-init.lisp") 19:23:44 No, can't do: > Error of type CCL::SIMPLE-PROGRAM-ERROR: Incorrect keyword arguments in (:NAME "Application" :DIRECTORY #P"/Users/pjb/Desktop/" :COPY-IDE-RESOURCES T :INIT-FILE (PATHNAME "~/application-init.lisp")) . 19:23:44 19:23:57 Ie. I passed :init-form '(pathname "~/application-init.lisp") 19:24:16 obviously otherwise (pathname "~/application-init.lisp") returns the same as #P"~/application-init.lisp". 19:24:24 I tried with a lambda too, a patch is in order. 19:29:08 (ccl:native-to-pathname "~/foo/bar.lisp") 19:36:13 fe[nl]ix: that's not the question. The point is that at build-application or save-application time, you don't know what "~/" WILL be at run time! 19:36:46 You want to execute (pathname "~/") in the init function of the saved executable, not in the building image. 19:36:52 oh, right 19:37:06 I'm compiling a patched ccl 19:58:45 gbyers [~gb@c-68-84-152-249.hsd1.nm.comcast.net] has joined #ccl 20:17:08 pjb: you could install an :around method on ccl:application-init-file 20:32:03 Yes, or use "HOME:init-file.lisp" as a string. Then it would be resolved at run-time. 20:57:49 -!- alms_ [~alms_@173-162-137-153-NewEngland.hfc.comcastbusiness.net] has quit [Quit: alms_] 20:59:34 There are a lot of bugs in 1.8 20:59:57 Report them. 21:00:18 Sure. I'm making patches. 21:00:37 Just report them, please. 21:00:59 Well, I must be able to generate my application first. 21:01:07 It's faster for me to correct them. 21:01:35 It's mostly build-application that breaks, or the generated application (even before reaching my code). 21:04:36 I have seen no reason to believe that you understand simple issues; it'd be faster for whoever tries to address the bug reports if they don't have to deal with that. 21:05:54 pjb: do you still use logical-pathnames? 21:06:01 gbyers: thanks a lot for all the bug fixes 21:06:13 Fare: yes, but not in relation to ASDF. 21:06:30 I have more bugs from the ITA bugzilla, but some of them require narrowing down the issue on my side 21:06:48 pjb: logical-pathname's drive me insane 21:08:12 Fare: my problem currently with ASDF, is that I want it to generate fasl in HOST+implementation specific directories (NFS mounted home). I used to generate a ~/quicklisp/asdf-config/asdf-init.lisp file from by ~/rc/common.lisp, using asdf:run-shell-command to call hostname, but this breaks on several systems (eg. MS-Windows). So I'm writing a run-program portability layer. 21:08:42 I should read the doc on the new configuration of asdf binary locations 21:08:57 Well, by now it is "old". 21:09:00 yeah, asdf-output-translations can do that for you. 21:09:53 can't multiple hosts with same implementation share cache? 21:10:09 I mean, the default cache name tries to identify OS and architecture. 21:10:30 there's a run-program portability layer that works on windows in xcvb-driver. 21:10:40 No. 21:10:42 please don't reinvent wheels and fix any breakage in existing ones. 21:10:57 OK (but why not? - curious) 21:11:06 Each host has different processor or versions. 21:11:26 asdf::implementation-identifier tries to identify process and version, too 21:11:36 try (asdf::implementation-identifier) on various hosts. 21:11:37 With some implementations, merely recompiling the implementation makes it generate incompatible fas files. 21:11:55 alms_ [~alms_@173-162-137-153-NewEngland.hfc.comcastbusiness.net] has joined #ccl 21:11:57 ccl for instance has a fasl version number that's included in this 21:12:27 Besides, on different hosts, there may be different versions of the libraries. 21:12:42 which libraries? 21:13:03 user's. 21:13:08 well, one solution would be to properly extend implementation-identifier to make more distinctions. 21:13:14 Aren't user libraries in different pathnames? 21:13:24 Ye,s you must extend the implementat-identifier with the fully qualified hostname. 21:13:29 or "same" pathnames in different hosts lead to clashes? 21:13:33 Fare: not necessarily, on different hosts. 21:13:48 I remember the setup at my alma mater... 21:14:04 /usr/local/lisp/liba/source.lisp may be version 1.1 on kuiper.informatimago.com and version 2.1 on triton.informatimago.com. And both may share /home. 21:14:25 hum. 21:14:30 So if you compile them with the same implementation, you get a collision. 21:14:41 (compiling with same implementation on each host) 21:14:59 the solution might be to indeed have a :hostname keyword in addition to :implementation 21:15:29 the REAL solution would be to complete XCVB, and cache based on digest, not pathname+timestamp. 21:15:32 -!- alms_ [~alms_@173-162-137-153-NewEngland.hfc.comcastbusiness.net] has quit [Client Quit] 21:15:58 Hire minions! 21:16:10 If you submit an implementation of hostname for each of our many implementations (14 of them) or even just a subset of them, I'll merge it. 21:16:42 I have no idea how to get this information on windows, even less "portably" (to many lisps) 21:17:20 but yes, I do have this issue when sharing a /home between hosts - just not for fasl caching (so far) 21:18:24 I may have it again since I'm now at Google that has decent /home sharing. 21:19:29 <|3b|> how many implementations/platforms does (machine-instance) fail on? 21:19:55 machine-instance doesn't return the fqdn. 21:20:09 <|3b|> ah 21:21:12 most implem return the hostname. clisp "kuiper.lan.informatimago.com [192.168.7.2]" and allegro "#xa8c00207". 21:23:50 -!- Fare [~Fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has quit [Ping timeout: 246 seconds] 21:40:16 -!- gbyers [~gb@c-68-84-152-249.hsd1.nm.comcast.net] has left #ccl 21:44:50 -!- rme [rme@8CB7B04A.47C9A248.699BA7A6.IP] has quit [Quit: rme] 21:44:50 -!- rme [~rme@50.43.137.11] has quit [Quit: rme] 21:50:53 rme [~rme@50.43.137.11] has joined #ccl 22:30:43 Fare [~Fare@216.239.55.82] has joined #ccl 22:38:14 gbyers [~gb@c-68-84-152-249.hsd1.nm.comcast.net] has joined #ccl 22:49:56 -!- Fare [~Fare@216.239.55.82] has quit [Ping timeout: 246 seconds]