
<HTML><HEAD>

<META http-equiv=Content-Type content="text/html; charset=iso-8859-15">

<META content="MSHTML 6.00.6000.16608" name=GENERATOR></HEAD>

<BODY style="MARGIN: 4px 4px 1px; FONT: 10pt Tahoma">

<DIV>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.</DIV>

<DIV> </DIV>

<DIV>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.  </DIV>

<DIV> </DIV>

<DIV>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.</DIV>

<DIV> </DIV>

<DIV>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.</DIV>

<DIV> </DIV>

<DIV>I think we need to be very careful here!</DIV>

<DIV> </DIV>

<DIV>Regards,</DIV>

<DIV>Randy<BR><BR>>>> Jay <jayk123@hotmail.com> 2/21/2008 7:56 AM >>><BR>"Maybe"?<BR> <BR>I'd like to make "progress" on what I have -- mainly slash independence, no colon hack on Unix.<BR>And then see about making much more progress.<BR> <BR>M3Path compromises a few bits of functionality, some of which could go in libm3, but not all.<BR> <BR>It has "path cleanup", of a sort that was strongly suggested here to be wrong.<BR>That is, "cleanup" of a/./b to a/b, a/../b to b.<BR>Incorrect in the face of links.<BR>But still general purpose if people want it.<BR>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).<BR> <BR>It has "path conversion" between "host" and "target".<BR>This is specially just changing slashes around.<BR>It does not deal with "drive letters".<BR> <BR>It deals with "file types".<BR>This is an area that probably does not belong in libm3.<BR>"types" are, you know, .m3, .i3, reasonably simple, but also libfoo.a vs. foo.lib.<BR>There is code to pick apart paths to "in that way", which I find..a little unusual.<BR> <BR>I did already change the Win32 Pathname implementation to always/usually treat forward and backward slashes as the same. That goes pretty far.<BR> <BR>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.<BR> <BR>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.<BR> <BR>I haven't seen how "network paths" are handled.<BR> <BR>Path handling is a surprisingly large rats nest of subtle behaviors and I'm not sure I really want to open it.<BR> <BR>Really, there are a few Win32 behaviors that i haven't gotten into..<BR> <BR>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.<BR> <BR>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..<BR> <BR>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...<BR> <BR>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...<BR> <BR>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..<BR> <BR>One thing I'm not sure about is the treatment of backward slashes equivalent to forward slashes on Posix.<BR>Maybe better just to do that fixup upon a few certain inputs. And have Win32 use either, but Posix only forward.<BR>It's "harmless" but loose.<BR> <BR>There this general problem of "user input" vs. "internal, strongly typed, analyzed, rule-following" data.<BR>As well as then presenting the internal data back to the user in the form he expected.<BR> <BR>It's is fine if I saw cm3 -DROOT=c:\\foo and internally it is c:/foo<BR>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...<BR> <BR> - Jay<BR><BR></DIV>

<DIV>

<HR id=stopSpelling>

</DIV>

<DIV><BR>> Date: Thu, 21 Feb 2008 11:42:25 +0100<BR>> From: wagner@elegosoft.com<BR>> To: jayk123@hotmail.com<BR>> CC: mika@async.caltech.edu; m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] [M3commit] CVS Update: cm3<BR>> <BR>> Quoting Jay <jayk123@hotmail.com>:<BR>> <BR>> > I have some ideas here that I am pretty certain WILL be acceptable.<BR>> > But I'd like to know if the current behavior really isn't.<BR>> ><BR>> > The ideas are:<BR>> > 1)<BR>> > (* A well designed approach might look like this, however how do <BR>> > we determine the target behavior?<BR>> > Seps_t = RECORD (* Whenever a character must be "written", <BR>> > DirSepChar is used. DirSepChar and DirSepCharAlt compare equal. <BR>> > *) DirSepChar : CHAR; DirSepCharAlt : CHAR; VolSep <BR>> > : CHAR; DirSepText : TEXT; END;<BR>> > SepKind_t = { Unix, Win, Winx };<BR>> ><BR>> > CONST<BR>> > Seps = ARRAY SepKind_t OF Seps_t { (* Unix *) Seps_t { '/', <BR>> > '/', '\000', "/" }, (* Win *) Seps_t { '\\', '/', ':', <BR>> > "\\" }, (* Winx *) Seps_t { '/', '\\', ':', "/" }, };<BR>> > *)<BR>> > and then I think m3middle would have to specify the behavior of each <BR>> > target -- of course most are "Unix".<BR>> ><BR>> > 2) less work for now, very much like the current behavior, except <BR>> > Colon changes from CONST to VAR and is ':' if the environment <BR>> > variable OS == "Windows_NT", else '\000'. The support for <BR>> > backslashes could key off this too, though I believe it is FAR less <BR>> > controversial.<BR>> ><BR>> > Also, I want to move m3path.m3 into a lower layer so it useable a <BR>> > little more.<BR>> > Like into m3quake (QPath?) or m3middle (M3Path?).<BR>> ><BR>> > However I worry about the effect on source control history.<BR>> > Advise?<BR>> ><BR>> > For now I've got one path function in one m3quake file, another path <BR>> > function in another m3quake file, and everything else remaining in <BR>> > cm3/src/M3Path.m3.<BR>> <BR>> I agree that we should have one central abstraction of the pathanme<BR>> type. What about pushing it further into libm3/.../Pathname? This would<BR>> need carefully checking of compatibility of course. Also I wouldn't<BR>> like to see variables exposed in such a module; we should use<BR>> functions or procedures for everything there.<BR>> <BR>> Do you see any problem in providing such a globally unique and<BR>> compatible abstraction?<BR>> <BR>> Could you provide a complete (documented) Pathname module that could be<BR>> discussed on this list and tested by everybody interested?<BR>> <BR>> Olaf<BR>> -- <BR>> Olaf Wagner -- elego Software Solutions GmbH<BR>> Gustav-Meyer-Allee 25 / Geb�ude 12, 13355 Berlin, Germany<BR>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<BR>> http://www.elegosoft.com | Gesch�ftsf�hrer: Olaf Wagner | Sitz: Berlin<BR>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<BR>> <BR><BR><BR></DIV>

<DIV>

<HR>

</DIV>

<DIV>Shed those extra pounds with MSN and The Biggest Loser! <A href="http://biggestloser.msn.com/" target=_new>Learn more.</A> </DIV></BODY></HTML>