[M3devel] [M3commit] CVS Update: cm3

[Jay]

As long as \ never occurs, no change.
Even if it does..think about it.
Before \ was treated as a "regular" character, allowed in paths.
It is very unlikely, but not impossible, that \ ever occured, and then it is also unlikely, but not impossible, for the opens with \ to succeed at the next level down. It is more likely to have failed. And then it is very unlikely, but again not impossible, to imagine that code could be depending on this failure.
 
Every single line changed is a change that must be thought through.
The implementation is the interface.
It is impossible to separate out something smaller and claim it is all other code depends on.
For any given change, I can probably come up with code that it broke.
 
If you use more memory, there could be code on the verge of running out of memory that you pushed over the edge.
If you expand some limit, there could be code relying on things having smaller limits.
If you make something faster, you can expose a race condition, that was already there but tending not to occur.
If you make something slower, well, people will just complain.
If all I do is add some new functions, well, like memory, I was almost out of disk space or more realistically virtual address space, and now I am. This is a real example. I have seen some code break just because other code grew in size.
The code was arguably buggy, but that is besides the point.
 
That doesn't mean that nothing can be changed.
You just have to apply reason.
 
So, for the case of backward slashes in Posix paths, is treating them like forward slashes dangerous?This is only in M3Path.m3, that the compiler uses. It is not in the more widely used Pathname module in libm3.
 
I'm going to undo th change and leave it only for "NT386GNU", and I have to double double check that it helps there..well, I know it helps upon input.
 
Imagine you have a text file with some paths and you move it across machines..
Do you:
  invent a new abstract "path" to store in the file, and write translation on either side ?
  adopt an existing form and translate on foreign systems ? 
  adopt what looks very nearly like very system's format and be a little careful ?
  In the form you chose, can you represent anything that is possibly valid?
   Or do get a bit lazy and disallow some paths, like forward slashes (legal on Mac OS remember) ? 
 
A start to an abstract representation is an array of strings, and the strings can have any character, and they have a length stored (don't depend on either space or null termination).
a "text" file format becomes less convenient now, because there is no delimiter, you have to store the length.
You can still do that as text, it's just less convenient to edit.
 
If you can get away with only storing full paths, that is probably an adequate represenation.
 
If you want some indirection, it is probably useful to decide some "roots", some common prefixes, and factor that out somehow. But this depends on the application.
 
And/Or maybe on the recieving end there is a "search algorithm".
 
I'm just saying, this area is complicated, I know it is complicated.
 
Forward slashes usually do have the same meaning on Win32 as backward slashes AND my goal here to make the system easier to use for anyone, such as myself, using NT386 and NT386GNU. I shouldn't have to set install root and the source root differently between them. Maybe this is just me and I'm lazy and I should suck it up, but if I only have one drive, the ability to use just /cm3 and /dev2/cm3.2 is so close to already being there..and furthermore...if someone is using NT386GNU, but any "normal" Windows editor (ie: not Cygwin vi/emacs), they will want errors printed out with backward slashes so they can copy/paste them into their editor.
 
I guess the "presentation format" should be user configurable.
Where "presentation format" could be limited what slash to use.
Leaving the user to possibly prefix with c: or /cygdrive/c, which is at least less tedious than changing all the slashes..
 
That's kind of the thing -- user input and output paths should be more flexible and/or configurable than internal forms. However internal forms should not be warped much or at all to handle this, only input/output functions that mediate between the two. One form caters to various users with various tastes. One form caters to code that is simpler to have just one form and benefits not at all from other forms. The "temptation" though is to make them the same.
 
Anyway, I have this "FixupPath" function that should basically make things this way.
I maybe can remove the allowance for the different slashes anywhere else.
The output issue is bothering me less right now than the input issue, and even the input issue I had mostly sucked up anyway. I think I was hitting some other problem not related to my own taste/laziness that made me revisit this. As it was, I had already "rewritten" M3Path.m3 twice and then abandoned it, figuring that the original authors had already figured this stuff out and it must already be right..but then I looked at it more and no longer thing that. I don't believe the "naming convention" declared in config files ever did much. All that determined things was the runtime probed slash that Pathname.i3 used. So, making NT386GNU use forward slashes but otherwise Windows naming conventions didn't work. I don't think, correct me if I'm wrong, I don't think libfoo.a vs. foo.lib should be tied with / vs. \.
However, I also don't mind switching to libfoo.a for NT386GNU (a target I'm not likely to use once it work..).
Maybe I should move on to that. Well, can't leave things as they are anyway...
 
 - 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. 
_________________________________________________________________
Connect and share in new ways with Windows Live.
http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080222/1b8e8f92/attachment-0002.html>