[Top][All Lists]
[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