gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Re: clc and pathnames


From: Camm Maguire
Subject: [Gcl-devel] Re: clc and pathnames
Date: 25 Feb 2004 20:57:59 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings, and thanks again for this!  Pathnames, at least
non-logical, are working to my knowledge.  Can you give a brief
summary of commands that need to be invoked which break under GCL at
present? 

take care,

Dennis Decker Jensen <address@hidden> writes:

> Hi Camm
> 
> The previous weekend I made the script for common-lisp-controller
> (clc).  However, I cannot test it until pathnames, physical as
> well as logical, are implemented in GCL.  Just about every aspect
> (by nature) of clc depends on it.
> 
> I've noticed you've had some problems regarding pathnames
> versus namestrings.  Once ANSI pathnames are in, you should not
> need to fuzz around with `.', `..' and such things in strings.
> Instead of substituting or concatenating strings, think of
> merging pathnames.  Use pathnames everywhere references to files
> are used -- instead of strings, and rely on ANSI CL functions
> to do the converting to namestrings only in the last possible
> instance where they absolutely are needed.
> 
> While skimming the docs I found out that pathnames unfortunately
> are not self-contained.  The directory component of pathnames
> allows some syntax with semantic behaviour, which relies on data
> in the actual filesystem underneath (symbolic links, shortcuts
> or what ever the platform calls them), but then again that
> should not be necessary to deal with until namestrings are used
> (in the last possible instance, as late as possible).  It also
> means that one cannot reconstruct the original pathname from
> the constructed namestring.  Hmmm...  Need to do more digging.
> 
> Sorry for the longish letter.  I tend to speculate too much
> out in the open.
> 
> This means that CL-controller will have to wait for pathnames
> in 2.7.X
> 
> Yours
> 
> Dennis Decker Jensen
> 
> P.S. Leaving aside pathnames, a lot of the cl-packages also
> relies on UFFI -- Universal Foreign Function Interface to work.
> AFAICT it can be implemented on top of a native FFI.  Although it
> is far from perfect (so people on c.l.c. keep telling) it is
> well supported, so maybe this also should be on a wish list
> or something?  BTW. I find GCL's connection to C compelling in
> this area, even though I haven't programmed in C for four years
> now.  Perhaps FFI is so simple in GCL that UFFI is not needed?
> Obviously I don't know...
> 
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah




reply via email to

[Prev in Thread] Current Thread [Next in Thread]