[M3devel] FW: more path stuff, sorry

[Daniel Alejandro Benavides D.]

Hi all:
Does pm3 treat NT386GNU paths as POSIX class? I think if one take the definition the Interface Pathname, NT386GNU target should not have access directly to use POSIX paths but Win32 ones because of:
"A Pathname.T (or just a pathname) is a text conforming to the syntax of the underlying operating system" in
http://www.opencm3.net/doc/help/gen_html/libm3/src/os/Common/Pathname.i3.html
But if we think in "the underlying operating system" as the cygwin api, it should be the natural POSIX paths.
I agree Pathname is a common interface, but what happens with that sense of portability we want? Maybe the answer is in the cygwin api; the non-standard functions of converting one style to the other: http://cygwin.com/cygwin-api/cygwin-functions.html .
See http://www.cygwin.com/cygwin-ug-net/using.html#using-pathnames
for the main notes of compatibility. It seems clear that cygwin can use both kind of path styles, so it's not a problem to use just one of POSIX or Win32 paths. So defining a Pathname of type POSIX style for NT386GNU, it is  not resign to the more capable functions of cygwin?
I mean if Pathname accept both kind of forward and back slashes in different Pathnames it should be defined a new kind of Pathname syntax. Oh I remember saw the mix of both kind of slashes in pm3 quake/config files of NT386GNU :) Is this really confusing or unthinkable?
I think this is clear for some of yous (NT386GNU should just accept POSIX paths, not even a Win32 one, and obviously not a mix of the two syntax in a same path), but it is not for me.
In my opinion both styles should be acceptable without defining a new kind of path syntax, and convert only using the cygwin api functions. For instance when using netbios resources but also trying to mount disks partitions on the cygwin mount table file we need both kind of syntax. Is that even logical?
Thanks in advance.

Tony Hosking <hosking at cs.purdue.edu> escribió: Jay, there is an underlying principle here that you seem to be missing so I will make it explicit.  Cross-product systems tend to acquire unmanageable complexity, especially when it comes to testing.  By making each target one personality we are able to test machine-dependent code in isolation from machine-independent code.  Often, when something breaks on one target I will test on another just to isolate the problem.  This is a very powerful approach and I am very leery of destroying any ability to do this -- it allows us to maintain the high-level portability of most Modula-3 code while isolating the small fraction of machine-/target-dependent stuff.





 

On Apr 22, 2008, at 12:28 AM, Jay wrote:

[truncated]...





---------------------------------
From: jayk123 at hotmail.com
To: rcoleburn at scires.com; m3devel at elegosoft.com
Subject: RE: [M3devel] more path stuff, sorry
Date: Tue, 22 Apr 2008 04:19:52 +0000

There's no dependency, no linkage. Just a few simple string operations.
I'll probably remove it tonight.
 
Modula-3 has a split personality no matter what, in that it calls into very varying underlying layers, often trafficing in their specific data formats.
It's just that it can strive to aid portability between them or not, by accepting either input and massaging it to work, vs. passing it along "unchanged" (well, that's not what happens actually). If there were no ambiguous cases and the Posix systems on Windows were consistent in their conventions, I'd be more for it. But the ambiguity and varying Posix conventions weaken the case tremendously.
 
 - Jay


---------------------------------
Date: Mon, 21 Apr 2008 23:14:00 -0400
From: rcoleburn at scires.com
To: m3devel at elegosoft.com
Subject: Re: [M3devel] more path stuff, sorry

I concur wholeheartedly.  I absolutely DO NOT want native NT386 to have any knowledge of or dependency on Cygwin.
Regards,
Randy

>>> Tony Hosking <hosking at cs.purdue.edu> 4/21/2008 9:44 PM >>>

Why would native NT386 know anything at all about Cygwin.  I say just avoid split personalities like the plague.  Similarly, I'd be happy for NT386GNU (i.e., Cygwin?) to simply behave like a POSIX build (modulo native threads perhaps).



On Apr 21, 2008, at 7:15 PM, Jay wrote:

Maybe this is dubious.

The question is, like, should native NT386 cm3 accept /cygdrive/c/foo and translate to c:\foo?
Or trickier, /usr/bin/foo and translate to c:\cygwin\usr\bin\foo?
And vice versa, should NT386GNU accept c:\foo?

...






       
---------------------------------

Enviado desde Correo Yahoo!
La bandeja de entrada más inteligente.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080423/7167dbbb/attachment-0002.html>