[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] delayed pathname.d patch
From: |
Michael Koehne |
Subject: |
Re: [Gcl-devel] delayed pathname.d patch |
Date: |
Fri, 23 Apr 2004 22:04:34 +0200 |
User-agent: |
Mutt/1.3.28i |
Moin Mike Thomas,
> Whether this patch is really the cause or it has just triggered the strange
> path behaviour seen in the Maxima build I don't know, but the build now
> fails trying to compile pcl/pcl_pkg.lsp because the C compiler is fed a path
> with no device (C:) as follows:
I wonder how this patch sneaked out - impossile, as I delayed make-pathname
to get asdf up patch, and told Camm, that pathname.d is a big can of worms.
My current pathname.d has a complete rewrite of parse-namesting and
merge-namesting and need an other overhaul before I attack make-pathname
again. I'm currently even thinking about implementing translate-pathname
at a low level - valid pathname strings are now :
Lisp like
[host ':'] [';'] [directory ';']* [name ['.' type ['.' version]]]
RCP like
[host ':'] ['/'] [directory '/']* [name ['.' type ['.' version]]]
DOS like
[device ':'] ['/'] [directory '/']* [name ['.' type ['.' version]]]
URL like
[device ':'] ['//' host '/'] [directory '/']* [name ['.' type ['.' version]]]
I only know two systems who need device names: VM and some other.
I dont have any Lisp under VM and I avoid to touch the other system.
Both have single characters as devices, e.g: #P"C:FOO.LISP" or
#P"FOO LISP C". Both systems provide own facilities to ACCESS a
local or network drive or directory as a device. (ACCESS 191 A
on VM/370) I therefore deceided that single character string in
RCP/DOS notations are devices, while longer are hosts.
The ANSI standard does'nt tell how to map devices to a
system that does not have such a concept. So #P"C:FOO.LISP"
is untested, currently. But I plan to use translate-pathname
for LOGICAL-DEVICENAME-TRANSLATIONS similar to logical-pathname.
I could mail you my next version, to check if they are able to
build a gcl and your favourite software under the 'other os',
that I avoid to touch.
Bye Michael
--
mailto:address@hidden UNA:+.? 'CED+2+:::Linux:2.4.22'UNZ+1'
http://www.xml-edifact.org/ CETERUM CENSEO WINDOWS ESSE DELENDAM
- Re: [Gcl-devel] Re: delayed pathname.d patch, (continued)
- Re: [Gcl-devel] Re: delayed pathname.d patch, Camm Maguire, 2004/04/23
- RE: [Gcl-devel] Re: delayed pathname.d patch, Mike Thomas, 2004/04/27
- Re: [Gcl-devel] Re: delayed pathname.d patch, Camm Maguire, 2004/04/23
- RE: [Gcl-devel] Re: delayed pathname.d patch, Mike Thomas, 2004/04/27
- Re: [Gcl-devel] Re: delayed pathname.d patch, Michael Koehne, 2004/04/27
- RE: [Gcl-devel] Re: delayed pathname.d patch, Mike Thomas, 2004/04/28
- Re: [Gcl-devel] Re: delayed pathname.d patch, Camm Maguire, 2004/04/28
- RE: [Gcl-devel] Re: delayed pathname.d patch, Mike Thomas, 2004/04/28
- [Gcl-devel] Re: delayed pathname.d patch, Paul F. Dietz, 2004/04/28
- RE: [Gcl-devel] Re: delayed pathname.d patch, Mike Thomas, 2004/04/28
- Re: [Gcl-devel] delayed pathname.d patch,
Michael Koehne <=
- Re: [Gcl-devel] delayed pathname.d patch, Camm Maguire, 2004/04/23
- Re: [Gcl-devel] delayed pathname.d patch, Camm Maguire, 2004/04/23
- Re: [Gcl-devel] delayed pathname.d patch, Michael Koehne, 2004/04/23
- Re: [Gcl-devel] delayed pathname.d patch, Michael Koehne, 2004/04/27
- Re: [Gcl-devel] delayed pathname.d patch, Camm Maguire, 2004/04/28
- RE: [Gcl-devel] delayed pathname.d patch, Mike Thomas, 2004/04/30
- Re: [Gcl-devel] *features*, Camm Maguire, 2004/04/16