Subject: [clisp-list] cygwin

From: [email-masked]
Date: Thu Apr 25 12:55:05 2002

The goal of the cygwin project IS to lie to the user or developer.
Thats why it exists.
Dan Stanger

---

From: "Thomas F. Burdick" <[email-masked]>
Date: Thu Apr 25 13:14:54 2002

> The goal of the cygwin project IS to lie to the user or developer.

The goal of Cygwin is to provide a POSIX-compatibility layer on top of
Windows.  In a great many ways the system still looks like windows,
but if you limit yourself strictly to POSIX, you're (theoretically)
fine.  I'd think it would be appropriate to have a :posix feature for
cygwin, but now :unix.  It seems like a :unix feature will cause more
problems than it would solve, and if a piece of software is
conditionalized such that it *can* work with #+(and unix mswindows),
then the person porting it to CLISP/Cygwin can just do:

  (let ((*features* #+cygwin (cons :unix *features)
                    #-cygwin *features*))
    (load-system))

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'

---

From: Randall R Schulz <[email-masked]>
Date: Thu Apr 25 13:37:04 2002

Hi,

I've been following this, and although I'd say it's not at all obvious what 
to do, I lean towards _not_ enabling the :mswindows feature for the 
Cygwin-hosted version of CLISP. For any practical purpose, the fact that 
there's Windows "down below" is neither apparent nor meaningfully accessible.

Cygwin does accept both kinds of path names, it's true, but first and 
foremost it is a POSIX emulation environment. To a first, and very good 
approximation, Cygwin is a Unix-like environment, not Windows.

Perhaps the entire feature scheme needs to be rethought in face of 
emulation environments like Cygwin and Wine?

Randall Schulz
Mountain View, CA USA

---

From: Marco Antoniotti <[email-masked]>
Date: Fri Apr 26 06:39:34 2002

> X-Sender: [email-masked]
> From: Randall R Schulz <[email-masked]>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
> Sender: [email-masked]
> X-BeenThere: [email-masked]
> X-Mailman-Version: 2.0.9-sf.net
> Precedence: bulk
> Date: Thu, 25 Apr 2002 13:22:55 -0700
> 
> Hi,
> 

So, your argument is that :unix with :cygwin is "a matter of
practicality".  I.e. we are in a "worse is better" vs. "the right
thing" fight.

> emulation environments like Cygwin and Wine?

It surely looks like this.  As a matter of fact I may be convinced
that the right combination of features may be

     (and :posix :mswindows)

or

     (and :cygwin :posix :mswindows)

But please!  No :unix on a MS Windows implementation.

Cheers

-- 
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group        tel. +1 - 212 - 998 3488
719 Broadway 12th Floor                 fax  +1 - 212 - 995 4122
New York, NY 10003, USA                 http://bioinformatics.cat.nyu.edu
                    "Hello New York! We'll do what we can!"
                           Bill Murray in `Ghostbusters'.

---

From: Sam Steingold <[email-masked]>
Date: Fri Apr 26 08:11:40 2002

> * In message <[email-masked]>
> * On the subject of "Re: [clisp-list] cygwin"
> * Sent on Fri, 26 Apr 2002 09:38:15 -0400
> * Honorable Marco Antoniotti <[email-masked]> writes:
>

could you please trim these before replying?
Quoting things like "Precedence" and "X-Mailman-Version" makes no sense.
You can keep "Date" and "Sender", if you really want, but...
[just in case: each of my 4 lines above contain important information,
 as opposed to "Content-Type" and "X-BeenThere"]

> > Cygwin does accept both kinds of path names, it's true, but first
> > and foremost it is a POSIX emulation environment. To a first, and
> > very good approximation, Cygwin is a Unix-like environment, not
> > Windows.

yes.  if you want a CLISP with #+WIN32, you can compile CLISP with
mingw of MSVC.  CLISP under cygwin does not understand "c:\\foo\\bar"
and thus has no right to have #+WIN32.
How many people out there have things like
(defvar *my-path* #+win32 "c:\\foo\\bar" #-win32 "~/foo/bar")

> No :unix on a MS Windows implementation.

clisp compiled by cygwin is not a MS Windows implementation.
if cygwin will be ported to, say, macos, clisp/cygwin will not be a
macos implementation.

I agree with Joerg 100%.

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.palestine-central.com/> <http://www.mideasttruth.com/>
The world is coming to an end.  Please log off.

---

From: Randall R Schulz <[email-masked]>
Date: Fri Apr 26 08:54:13 2002

Marco,

>practicality".  I.e. we are in a "worse is better" vs. "the right

I'm not "fighting" for, against or about anything. I never advocate for a 
"worse is better" perspective, not do I see how such a characterization 
fits my observation that Cygwin programs are insulated from the MS Windows 
environment below.

>But please!  No :unix on a MS Windows implementation.

Cygwin is certainly a POSIX environment, so not to have :posix seems wrong.

I don't have a strong opinion on this and probably don't understand CLISP 
well enough to make a strong statement, but if I'm advocating anything, 
it's that :mswindows is inappropriate for the Cygwin port.

If I get some time, I'll try to pose a "philosophical" question about this 
for the Cygwin list to see what programmers doing Cygwin ports of similar 
programming environments do in circumstances like these.

However, to compound the problem, I have to point out that Sam's remark:

>... CLISP under cygwin does not understand "c:\\foo\\bar"

Is not exactly true, at least not as far as the Cygwin underpinnings are 
concerned. Cygwin includes name and PATH translation routines, and more to 
the point, it is itself perfectly capable of understanding file name 
strings in either native Windows format or in POSIX format.

The problem, if there is one, is for programs that examine path names 
rather than treat them as structureless blobs to be accepted, saved and / 
or passed on. Programs that believe they understand path name syntax and 
that want to take advantages of Cygwin's flexibility of path name syntax 
must know that they're in a dual-syntax environment.

Perhaps, Sam, what you're saying is that as a program that does examine and 
parse path names CLISP must be configured to assume one or the other formats?

>Marco Antoniotti

Randall Schulz
Mountain View, C USA

---

From: Marco Antoniotti <[email-masked]>
Date: Mon Apr 29 07:41:07 2002

> From: Sam Steingold <[email-masked]>
> Date: 26 Apr 2002 11:07:44 -0400
> 
  ...
> if cygwin will be ported to, say, macos, clisp/cygwin will not be a

It is your decision to make, not mine. I still hold to my opinion that
the right thing to do is to correctly identify the host OS.  Putting
:unix in *features* in the case of cygwin is not IMHO optimal.

However, I do understand that the set of *features* is too
implementation dependent to be something to be argued for.  It is
something the writers of portable code will have to live with.

Cheers