[M3devel] [M3commit] CVS Update: cm3

[Tony Hosking]

I will dip my toe into this swamp only to make some high-level  
observations.  First, until we can come up with a well-specified  
abstraction in the form of a clean M3 interface I for one will find  
it increasingly difficult to follow the motivation and developments  
of any scheme.  In the face of that difficulty, I strongly prefer to  
stick to the current, non-portable, approach (ie, different path  
encodings for different targets maintained *separately*).  This will  
minimize disturbance for the many of us that only work on POSIX  
targets and need those to stay stable.  I am very nervous that my  
POSIX target will start to behave strangely or differently because of  
some interim commit to a rapidly evolving code base.  Hence, I  
applaud Olaf's suggestion that we come up with a clean design before  
we start hacking, and that the implementation stay off the critical  
path until it has been well-tested and understood.

On Feb 21, 2008, at 11:48 AM, Olaf Wagner wrote:

> Quoting Jay <jayk123 at hotmail.com>:
>> 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.
>
> OK.
>
>> 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".
>
> I see. This could be abstracted, too, though.
>
>> 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.
>
> OK. This is rather compiler specific.
>
>> 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.
>
> Yes, but it could be extended. There is also some support for
> different kinds of `roots'.
>
>> 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.
>
> I'll second that.
>
>> 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.
>
> Case sensitivity of file names should be handled centrally, too.
> It could be a property of a filename. But then that property needs to
> be set by someone - runtime, environment, user, application...
> As this is a big issue for portability of code, I'd say we should
> come up with some sound concept here, but of course that can be
> independent of your current work.
>
>> 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..
>
> `Hidden' on Unix usually only means that files are not shown with
> a simple `ls'. There's nothing special in the system to treat dot- 
> files
> different from others as far as I know.
>
>> 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...
>
> OK, I can understand that you just want to finishd your current work.
>
>> 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..
>
> It should help, but it also needs to be tested on different platforms.
>
>> 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.
>
> Yes, I'd be rather conservative there, too.
>
>> 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...
>
> One internal, abstract representation of the data, and two or more
> views on it (getPosixPath, getWindowsPath, ...) come to mind here.
>
> 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
>