"Hoehle, Joerg-Cyril" <Joerg-Cyril.Hoehle@...> writes:
> by now we've heard some arguments, partly based on personal bias
> (including mine). Somebody suggested a vote.
> Instead, I suggest we put the pros and cons black on white, so based on
> facts, and agreement could come out, or Sam can make a decision.
> Please help complete (or correct) the following:
I am very busy at the moment with weekends away and work and so cannot put
much, if any, time into clisp or this discussion. However, I am still trying
to do a little on dirkey and other cygwin features when possible.
Regarding *features*, then I have these comments for now. I apologise if
these have been covered by others recently. I know there has been some
discussion, but I'm way behind with it at the moment.
First question which might resolve the issue is, why would a user use a
cygwin based Clisp rather than a native Win based Clisp?
For me it is because I do not have MSVC or mingw32 and gcc/cygwin build of
Clisp is quite easy. It is a slight inconvenience that dir-key and other
features are not there, which is why I'm helping extend Clisp/cygwin. Dos
pathnames would be useful, but unix pathnames are ok.
I suspect that some code might use #+win32 when there would be a better
feature to use, though that might not exist. For example, pathnames is often
a problem for portable programs. Should they use #+win32, #+unix, #+amiga,
... etc? Perhaps there should be :pathnames=dos, :pathnames=unix,
I might have misunderstood exactly what you meant below, so excuse me if I
just point out something you already know.
> [CYGWIN-CLISP means: CLISP compiled with CYGWIN]
> Pro #+WIN32 == CLISP-CYGWIN is a MS-Windows app because
> + it can (in theory?) feature all things a "native" CLISP can (with how many modifications, if any?):
> # SYS::REGISTRY
> # DIRKEY (Peter Burwood could comment on the necessary changes)
DIR-KEY is already a feature, no need to tie in with #+win32
> # gdi (code unchanged between Dan's cygwin and mine using MS-VC)
> +-+-? making features available is just a matter of adding || defined(UNIX_CYGWIN) to selected defined(WIN32_NATIVE) places (pro), or code must be modified and carefully examined (contra).
> + the hypothetical user doesn't care whether his/her CLISP was compiled natively or not??
> + code from other Lisps already uses #+win32 to detect availability of the typical MS-Windows features mentioned above (a contradiction in effect?).
I agree, #+win32 is often wrong.
> + Lisp code uses #+WIN32 to detect the need for :DOS EOL convention when
> writing files and should do so with CYGWIN-CLISP as well.
> Contra #+WIN32
> - it doesn't understand pathnames like "C:\\foo\\bar.txt"
This could be accommodated. We could provide a cygwin compiled version of
clisp that supports Win (dos) pathnames or Cygwin (unix) pathnames, decided
at compile time.
> - even if it would, (shell (format nil "NOTEPAD.EXE ~A" (namestring
> pathname))) would not work, because MS-Windows/DOS applications do not
> recognize C:/foo/bar.txt.
I might be misremembering here, but the RISC OS port had a similar issue.
When the pathname was being passed to the OS, it was necessary to do some
conversion. This was because of the way pathnames commonly exist under RISC
OS versus a lot of Lisp code. Anyway, I'll skip the issues, because it'll be
a while before I can even check that one.
The important fact is that I think internal CLisp representation for
pathnames can be different from external representation. Sorry I can't think
of a good example atm.
> - it needs a specially compiled cygz.dll instead of zlib.dll (why?)
I don't know, but possibly to avoid name clashes and PATH issues. Cygwin
having cygz.dll means that the MS zlib.dll won't get loaded by Cygwin
apps. Why though? Perhaps MS dlls cannot be mixed with Cygwin code?
> - code from other Lisps already uses #+win32 to detect availability of the
> typical MS-Windows features but breaks on pathnames, shell and other
> distinguishing features.
Some code might use #+win32 because there was no reasonable alternative.
Backwards compatibility would need to be kept for some time if
:pathnames=dos was used.
> Pro #+UNIX == CYGWIN is a UNIX app because
> + SYSCALLS is there, including file-stat, sysinfo, resolve_host_ipaddr, bogomips
> + everything a programmer expects from a UNIX environment is (or can be) there:
SYSCALLS is already a feature, so it doesn't matter about #+win32 or #+unix.
> # readline library, gettext
> # /bin/sh
> # (run-command "/bin/sh emacs &"), or (run-command "/bin/sh emacs" :wait nil) all work as expected.
> # all POSIX functions, even gamma() and lgamma() (currently disabled for -DWIN32_NATIVE).
Anyone for #+POSIX ?
> + it could support (sys::dynload-module "module.so")
Isn't this #+DYN-FFI or whatever the feature is?
> + it integrates smoothly in a mixed UNIX+MS-Windows X11 windowing system environment, where DISPLAY is set to various hosts.
> - it does not integrate smoothly into such an environment, because "typical" X programs are not there or behave differently, e.g. netscape, XEmacs. However, ports of pbm, imagemagick, xv and even xterm work.
> Contra #+UNIX == CYGWIN should not disguise as a UNIX app because
> - the user may have installed a minimal cygwin, i.e. all typical UNIX commands are missing (ls, /bin/sh etc.) -- is that choice possible (or available via the cygwin installation?)
Yes, it is quite possible to be missing many Unix commands. In fact I am
positive that I can run Clisp/Cygwin with one or two dlls - I have checked
this, I just can't find my notes about dlls needed.
> It appears to that PRO&CONTRA are very much dictated by the user's
> environment: whether s/he has a complete UNIX-like environment and makes
> active use of it, or whether s/he sees CYGWIN-CLISP just as CLISP running
> on MS-Windows and doesn't care how it was compiled.
> Maybe we should add to config.lisp:
> ;; CYGWIN users: you can choose whether you want either :UNIX or :WIN32
> ;; on your feature list. But don't choose both.
> after the initial image has been generated, i.e. the core CLISP got the things that match its C half.
I'm almost tempted to suggest get rid of win32 and unix because those
features just mean too many different things to many people. Maybe that's