Re: [Chicken-users] Bug in canonical-path?
Hi, Ivan Raikov <[EMAIL PROTECTED]> writes: >I have been meaning to port the Haskell FilePath library to > Chicken, because I find its API to be quite elegant and better > organized than the existing file name manipulation routines in > Chicken. This discussion has prompted me to create the filepath egg, > which is an almost verbatim transliteration of the Haskell code, with > a few Chicken-specific idioms here and there. I have included a flag > parameter, which can be used to enable "Posix" mode or "Windows" > mode for path name parsing and manipulation. The Windows mode supports > weird things like UNC names and is aware of the DOS reserved names > (CON, PRN, etc). I would appreciate it if people look at it, as I > would like to see some variant of this API supersede the existing > Chicken path manipulation stuff. Pathname handling routines is one of the few libraries I spent a lot of time working on for common-scheme, so you may want to look at that (I punted on Windows issues though). PLT also has an extensive pathname handling library, which handles all the Windows weirdness. Your filepath port looks nice. A few comments from what I've skimmed so far: * You're working with lists of characters instead of strings (logical since that maps directly to the Haskell). Working with them allows a convenient functional implementation but can be slow. * Note if you work with substrings rather than character lists, you don't need to (and shouldn't) use utf8-strings, since path names are really just byte-vectors. * The separator inserted for Windows is '\'. Since Windows recognizes '/', would it be better to just use that for all cases? (I don't know, I'm asking the Windows users). * Some people expect path normalization to resolve symlinks. This is a separate operation - both are useful, you should be clear to document that your version doesn't do this. * A concept of the current directoy and resolving relative paths to that is important. * Expanding ~user directories is useful. * Version info is another thing sometimes included in pathname halding (see CL). -- Alex ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in canonical-path?
On Thu, Oct 30, 2008 at 12:46 AM, Ivan Raikov <[EMAIL PROTECTED]> wrote: > > Actually, I think it would be nice to have a tool that can > automatically create a custom Chicken shared library that only > includes the units that user specifies, and perhaps that can also > statically link eggs to that library. For example, if I want to deploy > a standalone application that does not use the regex and tcp units, > but uses matchable and filepath, this hypothetical tool would be able > to create a Chicken library that includes statically compiled > syntax-case, matchable and filepath, but no regex or tcp units. What > do people think about this? This is already possible by appropriate juggling of linking commands and/or static linking of applications. Generally, this is a great idea. The devil is in the details, like platform-specific linking and compile-time vs run-time issues. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in canonical-path?
Actually, I think it would be nice to have a tool that can automatically create a custom Chicken shared library that only includes the units that user specifies, and perhaps that can also statically link eggs to that library. For example, if I want to deploy a standalone application that does not use the regex and tcp units, but uses matchable and filepath, this hypothetical tool would be able to create a Chicken library that includes statically compiled syntax-case, matchable and filepath, but no regex or tcp units. What do people think about this? -Ivan Peter Bex <[EMAIL PROTECTED]> writes: > I think Ivan is not suggesting _adding_ this to core, but rather > _replacing_ what we have in core with this. In total, this should > have the net effect of adding nothing (though I don't know how big > both libraries are). ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in canonical-path?
On Wed, 29 Oct 2008, Peter Bex wrote: On Wed, Oct 29, 2008 at 11:03:30AM +0100, felix winkelmann wrote: On Wed, Oct 29, 2008 at 9:04 AM, Ivan Raikov <[EMAIL PROTECTED]> wrote: Hi all, I have been meaning to port the Haskell FilePath library to Chicken, because I find its API to be quite elegant and better organized than the existing file name manipulation routines in Chicken. This discussion has prompted me to create the filepath egg, which is an almost verbatim transliteration of the Haskell code, with a few Chicken-specific idioms here and there. I have included a flag parameter, which can be used to enable "Posix" mode or "Windows" mode for path name parsing and manipulation. The Windows mode supports weird things like UNC names and is aware of the DOS reserved names (CON, PRN, etc). I would appreciate it if people look at it, as I would like to see some variant of this API supersede the existing Chicken path manipulation stuff. That library looks useful - nice port, Ivan. I would keep these things in extensions, though. There is already too much stuff in the core (I know I keep repeating this, but I'm really concerned about it). I think Ivan is not suggesting _adding_ this to core, but rather _replacing_ what we have in core with this. In total, this should have the net effect of adding nothing (though I don't know how big both libraries are). filepath is fairly large. canonical-path and friends, together, are tiny. they are not addressing the same set of issues, regardless. again: canonical-path does not do existence checking. it is not meant to. it is intended to create localised canonical forms of a path in any representation as an aid to installation and naming portability. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in canonical-path?
On Wed, Oct 29, 2008 at 11:43 AM, Peter Bex <[EMAIL PROTECTED]> wrote: >> >> I would keep these things in extensions, though. There is already too much >> stuff in the core (I know I keep repeating this, but I'm really concerned >> about >> it). > > I think Ivan is not suggesting _adding_ this to core, but rather > _replacing_ what we have in core with this. In total, this should > have the net effect of adding nothing (though I don't know how big > both libraries are). The current stuff is relatively minimal, compared to the full filepath library. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in canonical-path?
On Wed, Oct 29, 2008 at 11:03:30AM +0100, felix winkelmann wrote: > On Wed, Oct 29, 2008 at 9:04 AM, Ivan Raikov <[EMAIL PROTECTED]> wrote: > > > > Hi all, > > > > I have been meaning to port the Haskell FilePath library to > > Chicken, because I find its API to be quite elegant and better > > organized than the existing file name manipulation routines in > > Chicken. This discussion has prompted me to create the filepath egg, > > which is an almost verbatim transliteration of the Haskell code, with > > a few Chicken-specific idioms here and there. I have included a flag > > parameter, which can be used to enable "Posix" mode or "Windows" > > mode for path name parsing and manipulation. The Windows mode supports > > weird things like UNC names and is aware of the DOS reserved names > > (CON, PRN, etc). I would appreciate it if people look at it, as I > > would like to see some variant of this API supersede the existing > > Chicken path manipulation stuff. > > > > That library looks useful - nice port, Ivan. > > I would keep these things in extensions, though. There is already too much > stuff in the core (I know I keep repeating this, but I'm really concerned > about > it). I think Ivan is not suggesting _adding_ this to core, but rather _replacing_ what we have in core with this. In total, this should have the net effect of adding nothing (though I don't know how big both libraries are). Cheers, Peter -- http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth pgpvY0rR91YHG.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in canonical-path?
On Wed, Oct 29, 2008 at 9:04 AM, Ivan Raikov <[EMAIL PROTECTED]> wrote: > > Hi all, > > I have been meaning to port the Haskell FilePath library to > Chicken, because I find its API to be quite elegant and better > organized than the existing file name manipulation routines in > Chicken. This discussion has prompted me to create the filepath egg, > which is an almost verbatim transliteration of the Haskell code, with > a few Chicken-specific idioms here and there. I have included a flag > parameter, which can be used to enable "Posix" mode or "Windows" > mode for path name parsing and manipulation. The Windows mode supports > weird things like UNC names and is aware of the DOS reserved names > (CON, PRN, etc). I would appreciate it if people look at it, as I > would like to see some variant of this API supersede the existing > Chicken path manipulation stuff. > That library looks useful - nice port, Ivan. I would keep these things in extensions, though. There is already too much stuff in the core (I know I keep repeating this, but I'm really concerned about it). cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in canonical-path?
Hi all, I have been meaning to port the Haskell FilePath library to Chicken, because I find its API to be quite elegant and better organized than the existing file name manipulation routines in Chicken. This discussion has prompted me to create the filepath egg, which is an almost verbatim transliteration of the Haskell code, with a few Chicken-specific idioms here and there. I have included a flag parameter, which can be used to enable "Posix" mode or "Windows" mode for path name parsing and manipulation. The Windows mode supports weird things like UNC names and is aware of the DOS reserved names (CON, PRN, etc). I would appreciate it if people look at it, as I would like to see some variant of this API supersede the existing Chicken path manipulation stuff. -Ivan Vincent Manis <[EMAIL PROTECTED]> writes: > I strongly disagree with this particular recommendation. Sometimes I > have code running on Unix that manipulates Windows file names > (thanks to VirtualBox, that's something I want to do more often, > these days). I recommend a design that has a flag with settings such > as `this is a Windows name', `this is a Unix name', and a default > setting of `this is a name for the OS I'm currently on', which can > certainly work the way Peter suggests. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in canonical-path?
On Tue, 28 Oct 2008, John Cowan wrote: Elf scripsit: In Windows, \ and / are interchangeable in system calls, although the command shell, the desktop, and other file windows and dialogue boxes don't accept \ but only /. I should have said "don't accept / but only \", of course. this is not strictly true; during installation of files (eg for chicken-setup) some calls are done through the command shell. In which case the code should be specialized for that purpose. this was the original intent. the / notation has certain other concerns as well, mostly involving drive letter. Well, yes: a path beginning [A-Za-z]:[/\\] is absolute on Windows but not on Unix. That too is a special case. see above. i will be adding flags to it for handling special cases at my earliest convenience. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in canonical-path?
Elf scripsit: > >In Windows, > >\ and / are interchangeable in system calls, although the command shell, > >the desktop, and other file windows and dialogue boxes don't accept \ > >but only /. I should have said "don't accept / but only \", of course. > this is not strictly true; during installation of files (eg for > chicken-setup) some calls are done through the command shell. In which case the code should be specialized for that purpose. > the / notation has certain other concerns as well, mostly involving > drive letter. Well, yes: a path beginning [A-Za-z]:[/\\] is absolute on Windows but not on Unix. That too is a special case. -- John Cowan http://www.ccil.org/~cowan [EMAIL PROTECTED] "After all, would you consider a man without honor wealthy, even if his Dinar laid end to end would reach from here to the Temple of Toplat?" "No, I wouldn't", the beggar replied. "Why is that?" the Master asked. "A Dinar doesn't go very far these days, Master.--Kehlog Albran Besides, the Temple of Toplat is across the street." The Profit ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in canonical-path?
On Sun, 26 Oct 2008, John Cowan wrote: Peter Bex scripsit: It would be better to make the behaviour be system-specific, instead of adding flags. On Windows, *always* treat slashes as backslashes. On Unix, *only* accept slashes with no additional translation steps. (I'm not sure Windows doesn't allow slashes in filenames, but I don't think it does) Unix, of course, treats \ as an ordinary filename character. In Windows, \ and / are interchangeable in system calls, although the command shell, the desktop, and other file windows and dialogue boxes don't accept \ but only /. Inside Chicken, therefore, / is entirely portable and no translation is ever necessary. this is not strictly true; during installation of files (eg for chicken-setup) some calls are done through the command shell. the / notation has certain other concerns as well, mostly involving drive letter. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in canonical-path?
On Sun, 26 Oct 2008, Peter Bex wrote: On Sun, Oct 26, 2008 at 01:19:42AM -0700, Elf wrote: ~$ touch abc\\298.test csi> (find-files "." regular-file? (lambda (x y)(print x) (print (file-stat (canonical-path x) ./abc\298.test Error: (file-stat) cannot access file - No such file or directory: "/home/matt/stuff/tools/lmbk/abc/298.test" this isn't a bug; it has to handle both windows and unix paths. i can add optional flags for specifying behaviour of slash and backslash, if desired. It would be better to make the behaviour be system-specific, instead of adding flags. On Windows, *always* treat slashes as backslashes. On Unix, *only* accept slashes with no additional translation steps. (I'm not sure Windows doesn't allow slashes in filenames, but I don't think it does) the idea was to allow for system-independent handling of pathnames with proper resolution. since the system for which a given path string was written is not knowable, it properly converts any relative (or absolute) path into the proper form for the local architecture. Also, why does file-stat interpret the backslash in the first place? AFAIK you can mix slashes and backslashes in Windows, so you shouldn't have to do anything at all. file-stat doesnt interpret the backslash, its canonical-path which does. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in canonical-path?
Peter Bex scripsit: > It would be better to make the behaviour be system-specific, instead of > adding flags. On Windows, *always* treat slashes as backslashes. On Unix, > *only* accept slashes with no additional translation steps. (I'm not sure > Windows doesn't allow slashes in filenames, but I don't think it does) Unix, of course, treats \ as an ordinary filename character. In Windows, \ and / are interchangeable in system calls, although the command shell, the desktop, and other file windows and dialogue boxes don't accept \ but only /. Inside Chicken, therefore, / is entirely portable and no translation is ever necessary. -- Ambassador Trentino: I've said enough. I'm a man of few words. Rufus T. Firefly: I'm a man of one word: scram! --Duck Soup John Cowan <[EMAIL PROTECTED]> ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in canonical-path?
On 2008-Oct-26, at 11:50, Peter Bex wrote: It would be better to make the behaviour be system-specific, instead of adding flags. On Windows, *always* treat slashes as backslashes. On Unix, *only* accept slashes with no additional translation steps. (I'm not sure Windows doesn't allow slashes in filenames, but I don't think it does) I strongly disagree with this particular recommendation. Sometimes I have code running on Unix that manipulates Windows file names (thanks to VirtualBox, that's something I want to do more often, these days). I recommend a design that has a flag with settings such as `this is a Windows name', `this is a Unix name', and a default setting of `this is a name for the OS I'm currently on', which can certainly work the way Peter suggests. -- vincent ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in canonical-path?
On Sun, Oct 26, 2008 at 01:19:42AM -0700, Elf wrote: > > ~$ touch abc\\298.test > > > > csi> (find-files "." regular-file? (lambda (x y)(print x) > > (print (file-stat (canonical-path x) > > > > ./abc\298.test > > Error: (file-stat) cannot access file - No such file or > > directory: "/home/matt/stuff/tools/lmbk/abc/298.test" > > > > > > this isn't a bug; it has to handle both windows and unix paths. i can add > optional flags for specifying behaviour of slash and backslash, if desired. It would be better to make the behaviour be system-specific, instead of adding flags. On Windows, *always* treat slashes as backslashes. On Unix, *only* accept slashes with no additional translation steps. (I'm not sure Windows doesn't allow slashes in filenames, but I don't think it does) Also, why does file-stat interpret the backslash in the first place? AFAIK you can mix slashes and backslashes in Windows, so you shouldn't have to do anything at all. Cheers, Peter -- http://sjamaan.ath.cx -- "The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music." -- Donald Knuth pgpPz3M6uNtEi.pgp Description: PGP signature ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] Bug in canonical-path?
On Sat, 25 Oct 2008, Matthew Welland wrote: ~$ touch abc\\298.test csi> (find-files "." regular-file? (lambda (x y)(print x) (print (file-stat (canonical-path x) ./abc\298.test Error: (file-stat) cannot access file - No such file or directory: "/home/matt/stuff/tools/lmbk/abc/298.test" this isn't a bug; it has to handle both windows and unix paths. i can add optional flags for specifying behaviour of slash and backslash, if desired. -elf ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] Bug in canonical-path?
~$ touch abc\\298.test csi> (find-files "." regular-file? (lambda (x y)(print x) (print (file-stat (canonical-path x) ./abc\298.test Error: (file-stat) cannot access file - No such file or directory: "/home/matt/stuff/tools/lmbk/abc/298.test" ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
