[M3devel] [M3commit] CVS Update: cm3

Thu Feb 21 21:16:41 CET 2008

I'm not convinced that it is *harmless* to change the code to treat "/"
and "\" the same.  This seems like a potential "can of worms" that may
create side-effects not well understood at this time.

My understanding of the original design of things is that the desire
was to provide standardized interfaces that allowed the programmer to
construct and manipulate paths independent of the OS's path separator. 
If you use the standardized interfaces you don't have a problem;
however, if you try to provide complete paths as literals, then yes, you
are introducing an OS-specific behavior into your code--which is not a
good thing if you want your code to be portable between OS.  

I have code that manipulates paths and runs properly on both Windows
and Unix without any source code modifications BECAUSE I use the
standard interfaces to build and manipulate paths.

Please let me know why you think it is important to change the behavior
of the existing code.  BTW, when you change such behavior, you are
changing the contract set up by the interface and any documentation
(comments) in that interface.  Whenever such a contract change is made,
ALL modules everywhere that import this interface must be examined to
see if the changes in the contract will adversely affect or break the
desired behavior of the module.

I think we need to be very careful here!

Regards,
Randy

>>> Jay <jayk123 at hotmail.com> 2/21/2008 7:56 AM >>>
"Maybe"?

I'd like to make "progress" on what I have -- mainly slash
independence, no colon hack on Unix.
And then see about making much more progress.

M3Path compromises a few bits of functionality, some of which could go
in libm3, but not all.

It has "path cleanup", of a sort that was strongly suggested here to be
wrong.
That is, "cleanup" of a/./b to a/b, a/../b to b.
Incorrect in the face of links.
But still general purpose if people want it.
The code that does this work I think can stand a rewrite. It is
currently limited to 31 slashes and after that it just silently ignores
stuff. If you reverse the path first, do the work, reverse again, you
can support unlimited lengths with small fixed memory (smaller than it
currently uses to support limit lengths).

It has "path conversion" between "host" and "target".
This is specially just changing slashes around.
It does not deal with "drive letters".

It deals with "file types".
This is an area that probably does not belong in libm3.
"types" are, you know, .m3, .i3, reasonably simple, but also libfoo.a
vs. foo.lib.
There is code to pick apart paths to "in that way", which I find..a
little unusual.

I did already change the Win32 Pathname implementation to
always/usually treat forward and backward slashes as the same. That goes
pretty far.

I believe the Pathname abstraction is that a path is essentially an
array of strings, you can add/remove from either end, add to one or the
other or both ends, and join two.

An issue I'm avoiding..because I don't want to pollute the code with
calls out ot Cygwin, is "correct" conversion between Win32 and Cygwin
paths. Generally the conversion is c:\foo <=> /cygdrive/foo.

I haven't seen how "network paths" are handled.

Path handling is a surprisingly large rats nest of subtle behaviors and
I'm not sure I really want to open it.

Really, there are a few Win32 behaviors that i haven't gotten into..

Even if you ignore Win32 -- what about case sensitivity? Even on Mac
and presumably Unix (to a Mac or Windows server), you can encounter case
insensitive file systems. The current Modula-3 code is not prepared for
that.

One of my favorite sob stories here, I've probably told it here, is
that I have a low end NAS (it won't boot lately..). It runs Linux, of
course (I said it is low end). I downloaded it source, extracted it,
xcopied, xcopyied it again incrementally. That fails. Because some of
the file names start with a dot and on Unix, that means they are hidden
and cannot be unhidden..

So this whole "hidden" thing is not portable, just as colons in paths
are not portable, but they work just fine if you stay on one system...

Let me get M3Path to where I want it, and repair the Unix colon
behavior, and see about rewriting the "cleanup" code... as long as folks
are happy with how it ends up, I'm not sure I want to puruse it much
more. There are much bigger fish...

Oh, I already have code on my system so that when we read ROOT,
CM3_INSTALL, CM3_ROOT from the command line and/or environment, those
paths get "fixed up" -- slashes reversed. That should help a lot here,
without much pollution..

One thing I'm not sure about is the treatment of backward slashes
equivalent to forward slashes on Posix.
Maybe better just to do that fixup upon a few certain inputs. And have
Win32 use either, but Posix only forward.
It's "harmless" but loose.

There this general problem of "user input" vs. "internal, strongly
typed, analyzed, rule-following" data.
As well as then presenting the internal data back to the user in the
form he expected.

It's is fine if I saw cm3 -DROOT=c:\\foo and internally it is c:/foo
but when an error message is reported, in case I am going to copy/paste
the paths in it to file.open, it should be back with backward slashes.
This is not simple. You could maintain two parallel representations as
you muck with the path. Not great. You could "characterize" the form of
the user in put (which slash directory), keep that around, it's just one
bit, and use it to guide the later presentation...

 - Jay

> Date: Thu, 21 Feb 2008 11:42:25 +0100
> From: wagner at elegosoft.com 
> To: jayk123 at hotmail.com 
> CC: mika at async.caltech.edu; m3devel at elegosoft.com 
> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
> 
> Quoting Jay <jayk123 at hotmail.com>:
> 
> > I have some ideas here that I am pretty certain WILL be
acceptable.
> > But I'd like to know if the current behavior really isn't.
> >
> > The ideas are:
> > 1)
> > (* A well designed approach might look like this, however how do 
> > we determine the target behavior?
> > Seps_t = RECORD (* Whenever a character must be "written", 
> > DirSepChar is used. DirSepChar and DirSepCharAlt compare equal. 
> > *) DirSepChar : CHAR; DirSepCharAlt : CHAR; VolSep 
> > : CHAR; DirSepText : TEXT; END;
> > SepKind_t = { Unix, Win, Winx };
> >
> > CONST
> > Seps = ARRAY SepKind_t OF Seps_t { (* Unix *) Seps_t { '/', 
> > '/', '\000', "/" }, (* Win *) Seps_t { '\\', '/', ':', 
> > "\\" }, (* Winx *) Seps_t { '/', '\\', ':', "/" }, };
> > *)
> > and then I think m3middle would have to specify the behavior of
each 
> > target -- of course most are "Unix".
> >
> > 2) less work for now, very much like the current behavior, except 
> > Colon changes from CONST to VAR and is ':' if the environment 
> > variable OS == "Windows_NT", else '\000'. The support for 
> > backslashes could key off this too, though I believe it is FAR less

> > controversial.
> >
> > Also, I want to move m3path.m3 into a lower layer so it useable a 
> > little more.
> > Like into m3quake (QPath?) or m3middle (M3Path?).
> >
> > However I worry about the effect on source control history.
> > Advise?
> >
> > For now I've got one path function in one m3quake file, another
path 
> > function in another m3quake file, and everything else remaining in

> > cm3/src/M3Path.m3.
> 
> I agree that we should have one central abstraction of the pathanme
> type. What about pushing it further into libm3/.../Pathname? This
would
> need carefully checking of compatibility of course. Also I wouldn't
> like to see variables exposed in such a module; we should use
> functions or procedures for everything there.
> 
> Do you see any problem in providing such a globally unique and
> compatible abstraction?
> 
> Could you provide a complete (documented) Pathname module that could
be
> discussed on this list and tested by everybody interested?
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45
86 95
> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz:
Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
DE163214194
> 

Shed those extra pounds with MSN and The Biggest Loser! Learn more. (
http://biggestloser.msn.com/ ) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080221/8619d399/attachment-0002.html>