From: Russ M. <rus...@ya...> - 2008-08-14 14:30:10
|
I have added a function of my own devising to asdf:*system-definition-search-functions* that relies on DIRECTORY doing something smart with wild pathnames. I have no idea whether this is standard or not. However I have certainly noticed a difference between the behavior of abcl and sbcl in this case. In abcl on my system I get this: CL-USER> (directory #P"/home/users/russm/work/lisp/*/*.asd") NIL But in sbcl on my system I get this: CL-USER> (directory #P"/home/users/russm/work/lisp/*/*.asd") (#P"/home/users/russm/work/lisp/asdf/cclan.asd" #P"/home/users/russm/work/lisp/cl-containers/cl-containers-test.asd" #P"/home/users/russm/work/lisp/cl-containers/cl-containers.asd" #P"/home/users/russm/work/lisp/cl-ppcre-1.3.2/cl-ppcre-test.asd" #P"/home/users/russm/work/lisp/cl-ppcre-1.3.2/cl-ppcre.asd" #P"/home/users/russm/work/lisp/cl-who-0.11.0/cl-who.asd" #P"/home/users/russm/work/lisp/clsql-4.0.3/clsql-aodbc.asd" #P"/home/users/russm/work/lisp/clsql-4.0.3/clsql-db2.asd" #P"/home/users/russm/work/lisp/clsql-4.0.3/clsql-mysql.asd" #P"/home/users/russm/work/lisp/clsql-4.0.3/clsql-odbc.asd" #P"/home/users/russm/work/lisp/clsql-4.0.3/clsql-oracle.asd" #P"/home/users/russm/work/lisp/clsql-4.0.3/clsql-postgresql-socket.asd" #P"/home/users/russm/work/lisp/clsql-4.0.3/clsql-postgresql.asd" #P"/home/users/russm/work/lisp/clsql-4.0.3/clsql-sqlite.asd" #P"/home/users/russm/work/lisp/clsql-4.0.3/clsql-sqlite3.asd" #P"/home/users/russm/work/lisp/clsql-4.0.3/clsql-tests.asd" #P"/home/users/russm/work/lisp/clsql-4.0.3/clsql-uffi.asd" #P"/home/users/russm/work/lisp/clsql-4.0.3/clsql.asd" #P"/home/users/russm/work/lisp/flexi-streams-0.14.0/flexi-streams.asd" #P"/home/users/russm/work/lisp/iterate-1.4.3/iterate.asd" #P"/home/users/russm/work/lisp/ltk-0.91/ltk-mw.asd" #P"/home/users/russm/work/lisp/ltk-0.91/ltk-remote.asd" #P"/home/users/russm/work/lisp/ltk-0.91/ltk.asd" #P"/home/users/russm/work/lisp/metatilities/metatilities.asd" #P"/home/users/russm/work/lisp/slime/swank.asd" #P"/home/users/russm/work/lisp/trivial-gray-streams-2006-09-16/trivial-gray-streams.asd" #P"/home/users/russm/work/lisp/uffi-1.6.0/uffi-tests.asd" #P"/home/users/russm/work/lisp/uffi-1.6.0/uffi.asd") CL-USER> Am I relying on non-standard behavior? If not, perhaps I'll try to fix abcl's DIRECTORY implementation. If so, does anyone know how to achieve something similar with abcl? Thanks, -russ |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-08-14 15:05:23
|
On Thu, Aug 14, 2008 at 4:30 PM, Russ McManus <rus...@ya...> wrote: > > I have added a function of my own devising to > asdf:*system-definition-search-functions* that relies on DIRECTORY > doing something smart with wild pathnames. > > I have no idea whether this is standard or not. However I have > certainly noticed a difference between the behavior of abcl and sbcl > in this case. > > In abcl on my system I get this: > > CL-USER> (directory #P"/home/users/russm/work/lisp/*/*.asd") > NIL > > But in sbcl on my system I get this: > > CL-USER> (directory #P"/home/users/russm/work/lisp/*/*.asd") > (#P"/home/users/russm/work/lisp/asdf/cclan.asd" > #P"/home/users/russm/work/lisp/cl-containers/cl-containers-test.asd" > #P"/home/users/russm/work/lisp/cl-containers/cl-containers.asd" > #P"/home/users/russm/work/lisp/cl-ppcre-1.3.2/cl-ppcre-test.asd" > #P"/home/users/russm/work/lisp/cl-ppcre-1.3.2/cl-ppcre.asd" > #P"/home/users/russm/work/lisp/cl-who-0.11.0/cl-who.asd" > #P"/home/users/russm/work/lisp/clsql-4.0.3/clsql-aodbc.asd" > #P"/home/users/russm/work/lisp/clsql-4.0.3/clsql-db2.asd" > #P"/home/users/russm/work/lisp/clsql-4.0.3/clsql-mysql.asd" > #P"/home/users/russm/work/lisp/clsql-4.0.3/clsql-odbc.asd" > #P"/home/users/russm/work/lisp/clsql-4.0.3/clsql-oracle.asd" > #P"/home/users/russm/work/lisp/clsql-4.0.3/clsql-postgresql-socket.asd" > #P"/home/users/russm/work/lisp/clsql-4.0.3/clsql-postgresql.asd" > #P"/home/users/russm/work/lisp/clsql-4.0.3/clsql-sqlite.asd" > #P"/home/users/russm/work/lisp/clsql-4.0.3/clsql-sqlite3.asd" > #P"/home/users/russm/work/lisp/clsql-4.0.3/clsql-tests.asd" > #P"/home/users/russm/work/lisp/clsql-4.0.3/clsql-uffi.asd" > #P"/home/users/russm/work/lisp/clsql-4.0.3/clsql.asd" > #P"/home/users/russm/work/lisp/flexi-streams-0.14.0/flexi-streams.asd" > #P"/home/users/russm/work/lisp/iterate-1.4.3/iterate.asd" > #P"/home/users/russm/work/lisp/ltk-0.91/ltk-mw.asd" > #P"/home/users/russm/work/lisp/ltk-0.91/ltk-remote.asd" > #P"/home/users/russm/work/lisp/ltk-0.91/ltk.asd" > #P"/home/users/russm/work/lisp/metatilities/metatilities.asd" > #P"/home/users/russm/work/lisp/slime/swank.asd" > #P"/home/users/russm/work/lisp/trivial-gray-streams-2006-09-16/trivial-gray-streams.asd" > #P"/home/users/russm/work/lisp/uffi-1.6.0/uffi-tests.asd" > #P"/home/users/russm/work/lisp/uffi-1.6.0/uffi.asd") > CL-USER> > > Am I relying on non-standard behavior? If not, perhaps I'll try to > fix abcl's DIRECTORY implementation. If so, does anyone know how to > achieve something similar with abcl? >From my reading of the spec this is exactly the required behaviour. So, a fix would be much appreciated! Any ideas on how you will approach the issue? Bye, Erik. |
From: Ville V. <vil...@gm...> - 2008-08-14 16:12:16
|
On Thu, Aug 14, 2008 at 6:05 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: > On Thu, Aug 14, 2008 at 4:30 PM, Russ McManus <rus...@ya...> wrote: >> I have added a function of my own devising to >> asdf:*system-definition-search-functions* that relies on DIRECTORY >> doing something smart with wild pathnames. > >From my reading of the spec this is exactly the required behaviour. > So, a fix would be much appreciated! Any ideas on how you will > approach the issue? I did a quick analysis of this. directory invokes wild-pathname-p (in pathnames.lisp), which in turn invokes %wild-pathname-p, which is implemented in java in Pathname.java. This further invokes coerceToPathname in Lisp.java, which then creates a Pathname object by casting or converting. Pathname constructor (once again in Pathname.java) just invokes an init function. Then, in init, the path is actually split up. It checks whether the path is relative (by looking whether it starts with . or ..), handles bang paths for jar files, expands home directory on unix platforms, and then finally finds the last occurrence of a path separator. Then it looks at a file separator (.) and then tries to locate a single * with a String.equals function. Looks a bit fishy to me, for matching wildcard paths.. But, there's hope - init invokes parseDirectory, where wildcards seem to be handled correctly, since it tokenizes the string. So, I'll need to check whether something like (directory #P"/home/users/russm/work/lisp/*/foo.asd") works, then it could be that just the filename portion is problematic. To me, the directory wildcard stuff looks ok. I have no further solution or a patch yet, but maybe someone finds this analysis useful for further digging. I may be able to find time later to pursue this further, but I thought the quick-analysis might be useful. HTH, -VJV- |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-08-14 16:45:12
|
On Thu, Aug 14, 2008 at 5:51 PM, Ville Voutilainen <vil...@gm...> wrote: > On Thu, Aug 14, 2008 at 6:05 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: >> On Thu, Aug 14, 2008 at 4:30 PM, Russ McManus <rus...@ya...> wrote: >>> I have added a function of my own devising to >>> asdf:*system-definition-search-functions* that relies on DIRECTORY >>> doing something smart with wild pathnames. >> >From my reading of the spec this is exactly the required behaviour. >> So, a fix would be much appreciated! Any ideas on how you will >> approach the issue? > > I did a quick analysis of this. directory invokes wild-pathname-p (in > pathnames.lisp), which in turn invokes > %wild-pathname-p, which is implemented in java in Pathname.java. This > further invokes > coerceToPathname in Lisp.java, which then creates a Pathname object by > casting or converting. > Pathname constructor (once again in Pathname.java) just invokes an > init function. > > Then, in init, the path is actually split up. It checks whether the > path is relative (by looking > whether it starts with . or ..), handles bang paths for jar files, > expands home directory on > unix platforms, and then finally finds the last occurrence of a path > separator. Then it looks > at a file separator (.) and then tries to locate a single * with a > String.equals function. Looks > a bit fishy to me, for matching wildcard paths.. > > But, there's hope - init invokes parseDirectory, where wildcards seem > to be handled correctly, > since it tokenizes the string. > > So, I'll need to check whether something like > (directory #P"/home/users/russm/work/lisp/*/foo.asd") > works, then it could be that just the filename portion is problematic. > To me, the > directory wildcard stuff looks ok. Thanks for the analysis. I came to my conclusion by reading about #p being equal to #.(parse-namestring ..); this means that the problem might be in PARSE-NAMESTRING. Or, at least, the solution should affect both PARSE-NAMESTRING and #p. I'm at least hoping that the reader already parses the directory spec, leaving that spec to be handled correctly by DIRECTORY. Bye, Erik. |
From: Ville V. <vil...@gm...> - 2008-08-14 17:14:54
|
> Thanks for the analysis. I came to my conclusion by reading about #p > being equal to #.(parse-namestring ..); this means that the problem > might be in PARSE-NAMESTRING. Or, at least, the solution should affect > both PARSE-NAMESTRING and #p. parse-namestring also invokes the coerceToPathname function at least in one place, which once again invokes the pathname construction. |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-08-14 17:19:43
|
On Thu, Aug 14, 2008 at 6:45 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: > On Thu, Aug 14, 2008 at 5:51 PM, Ville Voutilainen > <vil...@gm...> wrote: >> On Thu, Aug 14, 2008 at 6:05 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: >>> On Thu, Aug 14, 2008 at 4:30 PM, Russ McManus <rus...@ya...> wrote: >>>> I have added a function of my own devising to >>>> asdf:*system-definition-search-functions* that relies on DIRECTORY >>>> doing something smart with wild pathnames. >>> >From my reading of the spec this is exactly the required behaviour. >>> So, a fix would be much appreciated! Any ideas on how you will >>> approach the issue? >> >> I did a quick analysis of this. directory invokes wild-pathname-p (in >> pathnames.lisp), which in turn invokes >> %wild-pathname-p, which is implemented in java in Pathname.java. This >> further invokes >> coerceToPathname in Lisp.java, which then creates a Pathname object by >> casting or converting. >> Pathname constructor (once again in Pathname.java) just invokes an >> init function. >> >> Then, in init, the path is actually split up. It checks whether the >> path is relative (by looking >> whether it starts with . or ..), handles bang paths for jar files, >> expands home directory on >> unix platforms, and then finally finds the last occurrence of a path >> separator. Then it looks >> at a file separator (.) and then tries to locate a single * with a >> String.equals function. Looks >> a bit fishy to me, for matching wildcard paths.. >> >> But, there's hope - init invokes parseDirectory, where wildcards seem >> to be handled correctly, >> since it tokenizes the string. >> >> So, I'll need to check whether something like >> (directory #P"/home/users/russm/work/lisp/*/foo.asd") >> works, then it could be that just the filename portion is problematic. >> To me, the >> directory wildcard stuff looks ok. > > Thanks for the analysis. I came to my conclusion by reading about #p > being equal to #.(parse-namestring ..); this means that the problem > might be in PARSE-NAMESTRING. Or, at least, the solution should affect > both PARSE-NAMESTRING and #p. > > I'm at least hoping that the reader already parses the directory spec, > leaving that spec to be handled correctly by DIRECTORY. Based on your remarks I did some research of my own. However, I have no time to fix it now. Again, contributions welcome. The problem is in directory.lisp, in the fragment below: (if (wild-pathname-p pathname) (let ((namestring (directory-namestring pathname))) (when (and namestring (> (length namestring) 0)) #+windows (let ((device (pathname-device pathname))) (when device (setq namestring (concatenate 'string device ":" namestring)))) (let ((entries (list-directory namestring)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Here the code assumes that if the namestring is wild, then the directory-namestring isn't. Obviously in our example, that's incorrect. Neither does the spec require it to be. (matching-entries ())) Hope that helps. Bye, Erik. |
From: Ville V. <vil...@gm...> - 2008-08-17 18:45:02
Attachments:
directory-abcl-patch
|
On Thu, Aug 14, 2008 at 8:19 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: > Based on your remarks I did some research of my own. However, I have > no time to fix it now. Again, contributions welcome. > The problem is in directory.lisp, in the fragment below: > > (if (wild-pathname-p pathname) > (let ((namestring (directory-namestring pathname))) > (when (and namestring (> (length namestring) 0)) > #+windows > (let ((device (pathname-device pathname))) > (when device > (setq namestring (concatenate 'string device ":" namestring)))) > (let ((entries (list-directory namestring)) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Here the code assumes that if the namestring is wild, then the > directory-namestring isn't. Obviously in our example, that's > incorrect. Neither does the spec require it to be. Could you try the attached patch? It was a bit painful to get together, I'm no lisp guru and abcl build is not lightning fast. It seems to work correctly but due to lack of time I haven't been able to test it that much. It works for a couple of scenarios, like in my test function (defun test-directory () (format t "~a~%" (directory "/home/ville/projects/lisp/abcl/directory/*/*/*.txt")) (format t "~a~%" (directory "/home/ville/projects/lisp/abcl/directory/*/a/*.txt")) (format t "~a~%" (directory "/home/ville/projects/lisp/abcl/directory/*"))) I have a directory structure where I have abcl/directory/foo and abcl/directory/bar. These contain subdirectories a, b, c, d, which in turn contain a couple of text files each. So far the patch seems to work. HTH, -VJV- P.S. Russell's patch probably works too, but I wanted to try an approach that contains less java calls. |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-08-20 19:46:58
|
Index: directory.lisp =================================================================== --- directory.lisp (revision 11286) +++ directory.lisp (working copy) @@ -1,6 +1,7 @@ ;;; directory.lisp ;;; ;;; Copyright (C) 2004-2007 Peter Graves +;;; Copyright (C) 2008 Ville Voutilainen ;;; $Id: directory.lisp,v 1.7 2007-03-15 18:56:28 piso Exp $ ;;; ;;; This program is free software; you can redistribute it and/or @@ -28,6 +29,33 @@ :type nil :version nil))) Hi Ville, Thanks for another patch! You mentioned not being an experienced Lisp Hacker. In my comments I'm going to assume you want to learn more about the different options you could have used to solve a problem. +(defun list-directories-with-wildcards (pathname) + (let* ((result ()) + (directory (pathname-directory pathname)) + (first-wild (position-if #'wild-p directory)) + (non-wild (or (and first-wild + (subseq directory 0 first-wild)) directory)) + (wild (and first-wild (subseq directory first-wild))) Regarding both WILD and NON-WILD, I don't believe the AND operator is guaranteed to return the last element, so, best would be to use IF instead of OR, testing the FIRST-WILD condition as the IF test. Regarding your WILD code, SUBSEQ creates a copy of the subsequence. That means, it allocates new cons cells. However, in this case, you want *all* elements after a specific one. You can do that with NTHCDR, which doesn't copy the cons cells. Depending on your lisp implementation, this may or may not really be important: some lisps create cons cells as fast as walking the cdr-chain of the object. However, given that we're working with ABCL, every new cons cell needs to be allocated as a Java object - with full initialization in the Java engine. That being the case, you want to prevent consing as much as possible. + (newpath (make-pathname :directory non-wild + :name nil :type nil :defaults pathname)) + (entries (list-directory newpath))) + (if (not wild) + (setf result entries) If we were only able to return a value from DOLIST, we could reduce the above form to just 'entries'. And, as a matter of fact: you can. DOLIST takes an optional 3rd parameter: the so-called 'result form'. That would reduce the need to SETF the 'result' variable. + (dolist (entry entries) + (let* ((pathname (pathname entry)) + (directory (pathname-directory pathname)) + (filename (file-namestring pathname)) + (rest-wild (cdr wild))) + (when filename + (setf directory (append directory (list filename)))) + (when rest-wild + (setf directory (append directory rest-wild))) + (setf result + (append (list-directories-with-wildcards + (make-pathname :directory directory + :defaults newpath)) result))))) However, before you make the change of using DOLIST with its 3-argument form, there's a reason not to use the above construct at all: DOLIST/SETF/APPEND can be replaced with MAPCAN. MAPCAN concatenates the returned lists, stringing them together into 1. To that extent, it uses NCONC: the destructive cousin of APPEND. APPEND creates a copy of all the lists it's being passed. So, for the same reason as the one given above, the approach you take should be avoided - if at all possible: it conses too much. I have a question: does your code *only* expand the directories at higher levels, or does it also expand the files there? If it also expands the files (only to be removed later because they don't match), this too may be done more efficiently - reducing the need to instantiate objects. I have been taking a stab at this problem myself (before I knew you were too), however, my solution also has issues: I didn't use the "wild-p" function, which I probably should have. I like that about yours. Do you want to look at my code and integrate both solutions into a single patch? This is my version - which comes after pathname-as-file in directory.lisp: (defun wild-directory-p (pathname) (some #'(lambda (c) (eq c :wild)) (pathname-directory pathname))) (defun add-pathname-dir-component (pathname subdir) (make-pathname :defaults pathname :directory (append (pathname-directory pathname) (list subdir)))) "Takes a directory specification as returned from PATHNAME-DIRECTORY and expands that into a list of paths in the filesystem. In case there's no wild component, it returns a list of 1 element, its argument." (defun resolve-wild-parents (pathname &optional (components (pathname-directory pathname))) "Takes a directory specification as returned from PATHNAME-DIRECTORY and expands that into a list of paths in the filesystem. In case there's no wild component, it returns a list of 1 element, its argument." (if (print (some #'(lambda (c) (eq c :wild)) components)) ;; we're a wild path! - somewhere... (let* ((parents (resolve-wild-parents pathname (butlast components))) (component (car (last components)))) (mapcan #'(lambda (parent) (if (not (eq component :wild)) (let ((subdir (add-pathname-dir-component parent component))) (when subdir (list subdir))) (remove-if (complement #'file-directory-p) (list-directory parent)))) parents)) (list (make-pathname :directory components :defaults pathname ;; be sure to return a directory and possibly a host, not a file :name nil :type nil :version nil)))) (defun directory (pathspec &key) (let ((pathname (merge-pathnames pathspec))) (when (logical-pathname-p pathname) (setq pathname (translate-logical-pathname pathname))) (if (wild-pathname-p pathname) (let ((namestring (directory-namestring pathname))) (when (and namestring (> (length namestring) 0)) ;; #+windows ### 20080815: Lets see how it works without this: ;; the first thing that happens in list-directory is "coerceToPathname"... ;; (let ((device (pathname-device pathname))) ;; (when device ;; (setq namestring (concatenate 'string device ":" namestring)))) (let ((entries (mapcan #'(lambda (dir) (list-directory dir)) (resolve-wild-parents pathname))) (matching-entries ())) (dolist (entry entries) (cond ((file-directory-p entry) (when (pathname-match-p (pathname-as-file entry) pathname) (push entry matching-entries))) ((pathname-match-p entry pathname) (push entry matching-entries)))) matching-entries))) ;; Not wild. (let ((truename (probe-file pathname))) (if truename (list (pathname truename)) nil))))) Bye, Erik. |
From: Ville V. <vil...@gm...> - 2008-08-20 21:07:20
|
On Wed, Aug 20, 2008 at 10:47 PM, XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX wrote: First of all, thanks for the advice, it's always nice to have this kind of help. Then to the rebuttals. :) > Regarding both WILD and NON-WILD, I don't believe the AND operator is guaranteed > to return the last element, so, best would be to use IF instead of OR, testing > the FIRST-WILD condition as the IF test. The hyperspec (http://www.lispworks.com/documentation/HyperSpec/Body/m_and.htm) disagrees. It claims that the (result of the) last form is returned. About consing: I wanted to get the algorithm to work, performance was secondary. I am aware of destructive functions (nconc et al) but I chose to avoid them for the time being. I'd really like to have profiling data before I start worrying about append vs. nconc, for example. Even more so since this is an i/o operation. I'm not against optimizing it, even if just for not bogging the cpu too much - I just doubt whether the whole runtime of directory listing is affected much by consing. > To that extent, it uses NCONC: the destructive cousin of APPEND. > APPEND creates a copy > of all the lists it's being passed. So, for the same reason as the one Not all of them, I suppose - append is permitted to not copy the last list given to it. > I have a question: does your code *only* expand the directories at > higher levels, or > does it also expand the files there? If it also expands the files > (only to be removed > later because they don't match), this too may be done more efficiently > - reducing the > need to instantiate objects. I assume that by higher levels you mean subdirectories? Yes, the code expands files - the list-directory function just returns empty set of entries for those. I decided to avoid filtering out non-directories, since this was really not an attempt to make a perfect patch, just to get the wildcard listing to work with reasonable (read: very little) effort. I don't mind the improvement suggestions, though. I'm also not at all surprised that there are improvement ideas since I really did not strive for perfection. I suppose it's actually quite easy to filter out files by using the pathname functions, it's just that I'm not very familiar with lisp pathname stuff and I decided to push the patch as soon as I got it working. > Do you want to look at my code and integrate both solutions into a single patch? I can give it a shot. I'll likely have some questions about your code along the way, but I'll try creating some sort of synthesis-patch. :) later, -VJV- |
From: Ville V. <vil...@gm...> - 2008-08-24 18:19:24
Attachments:
directory-abcl-patch2
|
So, I have a brand-new patch. Attached, as usual. Some remarks follow. On Thu, Aug 21, 2008 at 12:07 AM, Ville Voutilainen <vil...@gm...> wrote: >> Regarding both WILD and NON-WILD, I don't believe the AND operator is guaranteed >> to return the last element, so, best would be to use IF instead of OR, testing I haven't touched this part of the patch. So, the patch 1) uses nthcdr and nbutlast for the wild/non-wild split 2) uses mapcan 3) uses nconc in the function given to mapcan. I created a separate helper, because I don't like flets or lambdas in the middle of code. We have only one list given to mapcan, thus the function used by mapcan takes only one param. I needed it to take three so I create and return the function bound to parameters of the creator function (create-directory-recurser). >> I have a question: does your code *only* expand the directories at >> higher levels, or >> does it also expand the files there? If it also expands the files >> (only to be removed >> later because they don't match), this too may be done more efficiently >> - reducing the >> need to instantiate objects. This may still need some additional work, Erik, can you describe how to do this, in general? I haven't spent much energy on this, but it's something that cannot be done just by looking at the file names returned by the list-directory function, I suppose. Or can it? Do the directories have an ending slash/backslash? No time to investigate further at this point, I have limited time to spend for abcl hacking. I'll check if I can find something for this, but in the meantime, please look at this revised patch and tell me what you think. |
From: Ville V. <vil...@gm...> - 2008-08-25 20:09:05
Attachments:
directory-abcl-patch3
|
>>> I have a question: does your code *only* expand the directories at >>> higher levels, or >>> does it also expand the files there? If it also expands the files > This may still need some additional work, Erik, can you describe > how to do this, in general? I haven't spent much energy on this, but Well, I have a new version that does not attempt recursion into non-directories (and thus does not attempt to list contents of non-directories). I'm not sure if that's sufficient, but here's yet another version of the patch. This last modification was done by removing the pointless concatenation of file-namestring before recursion, it's nil for directories. So now I just check the file-namestring and don't recurse at all if it exists. Any more issues? For me, it looks like this patch is done. -VJV- |
From: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - 2008-09-02 20:56:27
|
On Tue, Sep 2, 2008 at 7:59 PM, Ville Voutilainen <vil...@gm...> wrote: > On Mon, Aug 25, 2008 at 11:09 PM, Ville Voutilainen > <vil...@gm...> wrote: >> Well, I have a new version that does not attempt recursion into >> non-directories (and thus does not attempt to list contents of >> non-directories). I'm not sure if that's sufficient, but here's yet >> another version of the patch. This last modification was done >> by removing the pointless concatenation of file-namestring >> before recursion, it's nil for directories. So now I just check >> the file-namestring and don't recurse at all if it exists. >> Any more issues? For me, it looks like this patch is done. > > Hi Erik, any progress wrt this patch? Thanks for the heads up: it's committed now. Thanks for the patch too btw. Bye, Erik. |