[M3devel] [M3commit] CVS Update: cm3

[Jay]

I made one change to the Win32 Pathname implementation and that will be it unless there is more thought and consensus.
That change is to treat forward and backward slashes "the same", essentially as the underlying layer (kernel32.dll) already does.
Is this not ok?
You do all realize that Win32 /largely/ accepts forward slashes just fine, right?
There are some exceptions.It is the functions in kernel32.dll that accept them.
Not necessarily shlwapi.dll and definitely not the file.open dialogs.
There is way in which forward slashes don't work. I can explain later.
 
M3Path currently has "strange" behavior on Posix for colon and backward slash. I have the colon and I think backslash parts fixed on my machine.
Essentially I have:
 
CONST
  Slash = '/';
VAR (* formerly CONST *)
  Backslash := '\000'; (* initial value for Posix *)  Colon := '\000'; (* initial value for Posix *)IsDirSep(ch)
   return (ch = Slash OR ch = Backslash)
 
IsSep(ch)
   return (ch = Slash OR ch = Backslash OR ch = Colon)
 
I do actually worry about nulls in strings sometimes but nobody else seems to.
Allowing nulls is an advantage of approaches that keep a length separate.
I believe the previous code was already sleazy this way.
BEGIN (* Module initialization *) LocalSlash := Text.GetChar ( Pathname.Join ("a", "b"), 1);
 IF LocalSlash = '\\' THEN
  BackSlash := '\\';
  Colon := ':';
 ELSE
   OS := Env.Get ("OS");
   IF OS # NIL AND Text.Equal (OS, "Windows_NT") THEN
    same thing
   END END;
 
The point being to accept colons and backslashes on NT386 and Cygwin.
 
One thing I don't quite get and people here probably don't realize is that the compiler tries to traffice in both host and target paths.
It's not just about portabily using the host system, as people are so happy with the existing libm3 for.
Now, I'm not sure what the point is, and I am skeptical it even works.
I think the point might be for when bootstrapping, maybe to use the .M3SHIP files on the target.
 
This need to deal with more than just the host system's paths MIGHT be something for libm3.
Some way to "sniff" a path for its type, and then deal with it using the interfaces.
This is probably easily done just be exposing PathPosix and PathWin32, which implement themselves and Path.
The interface could just be Path to start, plus an explicit "create" function to get started, and maybe a "get" function to get the string as a regular string.
 
A function "FixUp" or specifically "CleanupSlashes" that changes runs of slashes to single slashes, and "RemoveSingleDots" and "RemoveDoubleDots" might be ok to provide but you'd have to call them manually.
 
Gotta go,
 - Jay


Date: Thu, 21 Feb 2008 15:16:41 -0500From: rcoleburn at scires.comTo: wagner at elegosoft.com; jayk123 at hotmail.comCC: m3devel at elegosoft.comSubject: Re: [M3devel] [M3commit] CVS Update: cm3

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:/foobut 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. 
_________________________________________________________________
Helping your favorite cause is as easy as instant messaging. You IM, we give.
http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080222/e0d97af1/attachment-0002.html>