From: Blake M. <bl...@mc...> - 2008-08-16 16:46:47
|
If I compile a files named ttt.lisp I get another file named ttt.abcl. If I then type: (load "ttt") abcl loads "ttt.lisp". As in many other lisps, it would be nice if load used the following algorithm: 1. If a file extension is explicitly named, use it. i.e. (load "ttt.lisp") or (load "ttt.abcl") 2. If the user types: (load "ttt") and there is only ttt.lisp OR ttt.abcl (but not both) load the one it finds. 3. If both exist, load the one with the latest modification date. This would allow code or users to load files (without the extension) and always (and automatically) get the correct one. Thanks. Blake McBride |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-08-17 07:48:36
|
On Sat, Aug 16, 2008 at 6:46 PM, Blake McBride <bl...@mc...> wrote: > > If I compile a files named ttt.lisp I get another file named ttt.abcl. If I > then type: > > (load "ttt") > > abcl loads "ttt.lisp". As in many other lisps, it would be nice if load > used the following algorithm: > > 1. If a file extension is explicitly named, use it. i.e. > > (load "ttt.lisp") > or > (load "ttt.abcl") > > 2. If the user types: > > (load "ttt") > > and there is only ttt.lisp OR ttt.abcl (but not both) load the one it finds. > > 3. If both exist, load the one with the latest modification date. > > > > This would allow code or users to load files (without the extension) and > always (and automatically) get the correct one. Heh. I hadn't noticed that, however, it explains some of the behaviour I'd seen so far. I'm looking into it - although contributions are still welcome ofcourse! Bye, Erik. |
From: Ville V. <vil...@gm...> - 2008-08-18 15:27:09
|
On Sun, Aug 17, 2008 at 10:48 AM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: > On Sat, Aug 16, 2008 at 6:46 PM, Blake McBride <bl...@mc...> wrote: >> If I compile a files named ttt.lisp I get another file named ttt.abcl. If I >> then type: >> (load "ttt") >> abcl loads "ttt.lisp". As in many other lisps, it would be nice if load >> used the following algorithm: <<<<-------algorithm snipped----->>> > Heh. I hadn't noticed that, however, it explains some of the behaviour > I'd seen so far. I'm looking into it - although contributions are > still welcome ofcourse! load uses a primitive %load, which is defined in Load.java and uses Load.load(). The code does handle adding .lisp but does not handle adding .abcl, nor does it handle the case where both exist. I'll look into it, I think I can cook something up. There's a bit of copy-pasteish code for handling file-not-found cases and adding .lisp and retrying. My plan is to consolidate these into a helper function and add .abcl handling with the timestamp checking (for cases where both .lisp and .abcl are found) into the new helper. Stay tuned. -VJV- |
From: Ville V. <vil...@gm...> - 2008-08-18 20:28:19
Attachments:
Load-abcl-patch
|
> Stay tuned. Patch attached. I added a helper function that concats the suffixes .lisp and .abcl and checks the modification dates if files for both suffixes are found, as I planned. I modified the original Load filename parameter to be non-final, since it was just easier to reassign it after modification. The code still contains more copy-pasteish stuff than I'd like (the isFile queries, the getName reassigns), but I didn't like to return that stuff through parameters, since returning through a parameter looks horrible in java, especially for immutable objects where I'd need an array. A separate (inner) class or something like that for the return value of addExtension is also a bit too much for me to tolerate. According to my tests, with this patch load works as desired. I tested loading with full filename, then without suffix and modded the modification date of my .lisp and .abcl files. AFAIK this loads the correct file in all cases. HTH, -VJV- |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-08-20 09:50:27
|
Hi! (quickly replying as I'm online for a short time) On Mon, Aug 18, 2008 at 10:28 PM, Ville Voutilainen <vil...@gm...> wrote: >> Stay tuned. > > Patch attached. I added a helper function that concats the suffixes > .lisp and .abcl > and checks the modification dates if files for both suffixes are > found, as I planned. It's a great patch, almost what I had in mind after finding the source of the issue, indeed. I like the fact that you factored out some code. > I modified the original Load filename parameter to be non-final, since > it was just easier to reassign it after modification. The code still > contains more > copy-pasteish stuff than I'd like (the isFile queries, the getName > reassigns), but > I didn't like to return that stuff through parameters, since returning > through a parameter > looks horrible in java, especially for immutable objects where I'd > need an array. > A separate (inner) class or something like that for the return value > of addExtension > is also a bit too much for me to tolerate. The code is nice as it is. However, I have 2 remarks: 1) you could make use of the fact that - according to the File() docstring - "new File(filename) == new File(dir, filename)" when dir == null. 2) File.getName() doesn't work for me when using absolute paths (where the ABCL file isn't in the current directory); maybe File.getPath() works? > According to my tests, with this patch load works as desired. I tested loading > with full filename, then without suffix and modded the modification date of > my .lisp and .abcl files. AFAIK this loads the correct file in all cases. Could you give the patch another round please? I can commit after the above 2 issues are addressed. Bye, Erik. |
From: Ville V. <vil...@gm...> - 2008-08-20 10:35:13
|
> The code is nice as it is. However, I have 2 remarks: > 1) you could make use of the fact that - according to the File() > docstring - "new File(filename) == new File(dir, filename)" when dir > == null. Ok, I wondered whether Java is smart enough to handle a null dir parameter for File constructor. Naturally I did not read the docs or try it out. :D But this cleans up the code, because we no longer need two almost-identical cases. > 2) File.getName() doesn't work for me when using absolute paths (where > the ABCL file isn't in the current directory); maybe File.getPath() > works? I'll check it out, I'll provide an improved patch. -VJV- |
From: Ville V. <vil...@gm...> - 2008-08-20 17:32:28
Attachments:
Load-abcl-patch2
|
>> 1) you could make use of the fact that - according to the File() >> docstring - "new File(filename) == new File(dir, filename)" when dir >> == null. Yes, this really works. Done in the new patch (attached). >> 2) File.getName() doesn't work for me when using absolute paths (where >> the ABCL file isn't in the current directory); maybe File.getPath() >> works? getPath() seems to work. I tested additionally with absolute path where the path does not point to current directory, and also with relative path. I made the null check in addExtension so that it checks in the beginning and returns, I don't like unnecessary indentation. I also removed copy-pasteish file/filename reassignment (it is done in every case, the duplication in both branches of if-else was totally unnecessary). I even eliminated the else, since we only use the dir value if the path is not absolute. I also removed the unnecessary isFile booleans, since the new patch is refactored so that the existence of the file is checked in only two places, both being the only places in their respective functions and thus there is no need for a separate variable. Now the code looks IMHO much better. If I'm not mistaken, the patch delta is 32 lines removed, 37 added (modified lines are included here, of course), so we got the "intelligent" loading feature with five more lines thanks to the refactoring. |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-08-20 22:31:32
|
On Wed, Aug 20, 2008 at 7:32 PM, Ville Voutilainen <vil...@gm...> wrote: >>> 1) you could make use of the fact that - according to the File() >>> docstring - "new File(filename) == new File(dir, filename)" when dir >>> == null. > > Yes, this really works. Done in the new patch (attached). > >>> 2) File.getName() doesn't work for me when using absolute paths (where >>> the ABCL file isn't in the current directory); maybe File.getPath() >>> works? > > getPath() seems to work. I tested additionally with absolute path where > the path does not point to current directory, and also with relative path. Thanks for your patch! I committed it (with slight tweaks) in r11289. Bye, Erik. |