Home > Archive > PERL Miscellaneous > March 2004 > Re: Building Perl with Open Watcom
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: Building Perl with Open Watcom
|
|
| Ilya Zakharevich 2004-03-27, 12:00 am |
| I realized that it makes sense to update the Newsgroups line too late;
so the only purpose of this post is to cross-post to c.l.p.m.
I wrote in article <c3noc0$a7e$1@agate.berkeley.edu>:
> [A complimentary Cc of this posting was NOT [per weedlist] sent to
> Mat Nieuwenhoven
> <mnieuw@don'tincludethis@zap.a2000.nl>], who wrote in article <zavrhjmncnay.huz5lh0.pminews@news.text.chello.nl>:
>
> As I said, this is only an uneducated guesswork on my side; I meant
> all the POSIXish stuff which is AFAIK missing in VAC: what I can
> immediately remember is exec() (which is used much more frequently
> than fork()), an ability to treat a socket as a file descriptor, and
> some minor-but-tedious stuff auto-translation of /dev/tty and
> /dev/null, etc. Doing tell()/s () on text files is a problem with
> many compilers as well. "Reliable" treatment of ^Z in text files?
> sbrk() (optional for perl, but may improve functionality a lot)?
> Reliable command-line argument quoting/dequoting and globbing (so that
> arguments to spawnve() correspond 1-to-1 to argv[] array)? wait()?
> alarm()? select() on many kinds of file descriptors?
>
> The fact is that Perl is (together with other uses) a glue to system's
> functionality, and POSIX is a very convenient common denominator. So
> a lot of available Perl software assumes that the current perl
> executable is capable of POSIXish behaviour.
>
> Perl build process is very configurable, and is able to auto-detect
> most of capabilities of the current build environment. It should not
> be hard to compile a build of perl with any (no matter how stupid)
> compiler. The problems with the build will be twofold:
>
> a) as I explained before, a lot of Perl scripts will not work with
> this build.
>
> b) *a lot* of stuff in the test suite will fail, and it will be very
> hard to distinguish the bugs of the build environment (worsened by
> the possible bugs in the auto-detection phase) versus the
> restrictions of the build environment not taken into account by
> the test suite.
>
> To fix b), one needs to sifter through all the test suite failures,
> and update the test suite to take into account all the new
> restrictions coming with this new build environment.
>
> To fix a) one needs to sifter through each new Perl script and
> "improve" it by changing all the "POSIXish" stuff (like "/dev/null")
> to the "portable" one (like File::Spec->null(). I put "improve" in
> quotes since this *is* an improvement in the portability of the
> script, but is a step back in maintainability of the script due to
> increase in the amount of code).
>
> From my POV, it is much easier to fix this on the level of perl guts;
> this is the design goal of my OS/2 port; e.g., it uses a Bourne-syntax
> shell for those system()/exec()s which require shell, as opposed to
> %COMSPEC%.
>
>
> The largest gap of (non Cygwin) perls on Window is a botched emulation
> of fork() - which EMX does almost perfectly. BTW, the 50% number I
> gave was related to "easy to convert from Win32 branches"; the
> remaining 50% is technically possible, but (I think) would require
> some new code.
>
>
> Any way you would like (but I did not hear about the Watcom branch).
>
>
> I trust your judgement on this (w.r.t. to Win32 port).
>
> Hope this helps,
> Ilya
| |
| Mat Nieuwenhoven 2004-03-27, 12:00 am |
| Ilya Zakharevich <nospam-abuse@ilyaz.org> wrote in
news:c3np13$agb$1@agate.berkeley.edu:
<snip>
[color=darkred]
Watcom has a number of exec() funtions: execl, execle, execlp, execlpe,
execv, execve, execvp and execvpe, plus their wide-char equivalents. It
this what you mean?
[color=darkred]
This I don't know. For OS/2 at least you have separate calls for dealing
with sockets (like send/receive), I don't know if normal file calls
(write/read) would work.
[color=darkred]
This is not Posix stuff, surely?
[color=darkred]
You refer to the CR/LF problems when a file is opened in text mode?.
Don't know how Watcom behaves here, I've never tried it, I tend to open
files binary. Do you have a test case?
[color=darkred]
What is supposed to happen when a ^Z is encountered? Normally it would
be the last char of a file added by bad editors, but what if I paste it
in the middle?
[color=darkred]
Watcom does have a sbrk. Under non-DOS, it returns a newly allocated
block of memory (rounded up to a multiple of 4k). Is this the one you
mean?
[color=darkred]
There is no cmd line parsing in Watcom as far as I know. Are you
referring to the fact if getopt is part of the clib?
[color=darkred]
Watcom's wait returns the exit status and process ID of the first child
process that terminates.
[color=darkred]
Not present in Watcom at the moment. Doesn't this send a particular
signal to the process after a specified time? In the list of signals
supported by Watcom (7 plus 3 OS/2 specific) I see nothing that looks
like an alarm signal.
[color=darkred]
select isn't in Watcom libs, it is part an OS-supplied lib. So I think
it is unlikely to work on other than socket handles.
[color=darkred]
Hm. Watcom doesn't have a fork. I'm not sure if it should be added.
Maybe in the interest of portability.
Mat Nieuwenhoven
| |
| Ilya Zakharevich 2004-03-27, 12:00 am |
| [A complimentary Cc of this posting was sent to
Mat Nieuwenhoven
<mnieuw@zap.dontincludethis.a2000.nl>], who wrote in article < Xns94B58B590DC5Emnieuwzapdontinclude@195
.129.110.143>:
>
> Watcom has a number of exec() funtions: execl, execle, execlp, execlpe,
> execv, execve, execvp and execvpe, plus their wide-char equivalents. It
> this what you mean?
Nope. No misprint here.
>
> This is not Posix stuff, surely?
This is why I explicitly wrote "POSIXish", not POSIX. ;-) I think all
reasonable POSIXification translate these too...
>
> You refer to the CR/LF problems when a file is opened in text mode?.
> Don't know how Watcom behaves here, I've never tried it, I tend to open
> files binary. Do you have a test case?
A sketch: open a large text file; read a thousand lines; read several
more bytes; tell(); repeat reading; s() back; did you get to
exactly the same position in the *CRLF-translated* stream?
>
> What is supposed to happen when a ^Z is encountered? Normally it would
> be the last char of a file added by bad editors, but what if I paste it
> in the middle?
EMX treats ^Z specially only if it is the last byte of the file, or
(maybe only for TTY?) if it is immediately followed by \r? \n.
>
> Watcom does have a sbrk. Under non-DOS, it returns a newly allocated
> block of memory (rounded up to a multiple of 4k). Is this the one you
> mean?
Good. So at least one (optional) of the requirements is met...
>
> There is no cmd line parsing in Watcom as far as I know.
Com'on, you mean argc/argv is not supported? ;-) A C compiler on OS/2
can't work without command-line parsing...
>
> Watcom's wait returns the exit status and process ID of the first child
> process that terminates.
What about "Signal which killed it" part?
>
> Not present in Watcom at the moment. Doesn't this send a particular
> signal to the process after a specified time? In the list of signals
> supported by Watcom (7 plus 3 OS/2 specific) I see nothing that looks
> like an alarm signal.
This would restrict functionality *a lot*. Most scripts which need a
timed read() would use alarm()...
Hope this helps,
Ilya
| |
| Mat Nieuwenhoven 2004-03-27, 12:01 am |
| On Tue, 23 Mar 2004 21:12:47 +0000 (UTC), Ilya Zakharevich wrote:
:>[A complimentary Cc of this posting was sent to
:>Mat Nieuwenhoven
:><mnieuw@zap.dontincludethis.a2000.nl>], who wrote in article
which won't work because of the mangled address..
< Xns94B58B590DC5Emnieuwzapdontinclude@195
.129.110.143>:
:>> >> As I said, this is only an uneducated guesswork on my side; I meant
:>> >> all the POSIXish stuff which is AFAIK missing in VAC: what I can
:>> >> immediately remember is exec() (which is used much more frequently
:>> >> than fork())
:>>
:>> Watcom has a number of exec() funtions: execl, execle, execlp, execlpe,
:>> execv, execve, execvp and execvpe, plus their wide-char equivalents. It
:>> this what you mean?
:>
:>Nope. No misprint here.
I just looked into the Perl 5.8.3 source, and I cannot see a single exec(
there. I see spawnl , spawnvp, execvp, execl (e.g. in os2\os2.c around line
1419),
which is all standard clib stuff, also according to
http://www.opengroup.org/onlinepubs...tions/exec.html . What am I
missing?
:>> >> some minor-but-tedious stuff auto-translation of /dev/tty and
:>> >> /dev/null, etc.
:>>
:>> This is not Posix stuff, surely?
:>
:>This is why I explicitly wrote "POSIXish", not POSIX. ;-) I think all
:>reasonable POSIXification translate these too...
Ok, so if it's coded already there's no Watcom dependency.
:>> >> Doing tell()/s() on text files is a problem with many compilers as
:>> >> well.
:>>
:>> You refer to the CR/LF problems when a file is opened in text mode?.
:>> Don't know how Watcom behaves here, I've never tried it, I tend to open
:>> files binary. Do you have a test case?
:>
:>A sketch: open a large text file; read a thousand lines; read several
:>more bytes; tell(); repeat reading; s() back; did you get to
:>exactly the same position in the *CRLF-translated* stream?
My tests indicates it works perfectly. 8600 line file with semi-random
spotchecks get it right every time (finding the nth line with n changing
after each hit, then reading some, then store tell() pos plus next 12 bytes
in an array. At end, reverse through array-stored positions backward and read
and compare).
:>
:>> >> "Reliable" treatment of ^Z in text files?
:>>
:>> What is supposed to happen when a ^Z is encountered? Normally it would
:>> be the last char of a file added by bad editors, but what if I paste it
:>> in the middle?
:>
:>EMX treats ^Z specially only if it is the last byte of the file, or
:>(maybe only for TTY?) if it is immediately followed by \r? \n.
Reading stops on the very first EOF (x1A) which is encountered, even if it is
in the middle of the file. The EOF doesn't show up in the input stream.
:>> >> sbrk() (optional for perl, but may improve functionality a lot)?
:>>
:>> Watcom does have a sbrk. Under non-DOS, it returns a newly allocated
:>> block of memory (rounded up to a multiple of 4k). Is this the one you
:>> mean?
:>
:>Good. So at least one (optional) of the requirements is met...
:>
:>> >> Reliable command-line argument quoting/dequoting and globbing (so
:>> >> that arguments to spawnve() correspond 1-to-1 to argv[] array)?
:>>
:>> There is no cmd line parsing in Watcom as far as I know.
:>
:>Com'on, you mean argc/argv is not supported? ;-) A C compiler on OS/2
:>can't work without command-line parsing...
Of course Watcom has the normal argc/argv stuff. I thought you were referring
to some parsing library function. I'm not sure what you mean by
quoting/dequoting and globbing, though. I think Linux's getopt will treat
(ignore the single quotes) '-l h' and '-lh' the same, I'm pretty sure that
for Watcom the first case shows up as 2 arguments.
:>> >> wait()?
:>>
:>> Watcom's wait returns the exit status and process ID of the first child
:>> process that terminates.
:>
:>What about "Signal which killed it" part?
You are referring, I guess, to macros such as WTERMSIG which can interpret
the return value. Watcom doesn't have that. I'm not sure if it is easy to add
without breaking existing functionality, the returned status word is already
fully taken, although I think there's some room for a byte value in case of
an unhandled SIGTERM. But this could break existing code.
:>> >> alarm()?
:>>
:>> Not present in Watcom at the moment. Doesn't this send a particular
:>> signal to the process after a specified time? In the list of signals
:>> supported by Watcom (7 plus 3 OS/2 specific) I see nothing that looks
:>> like an alarm signal.
:>
:>This would restrict functionality *a lot*. Most scripts which need a
:>timed read() would use alarm()...
SIGALRM isn't part of the C spec, is it? It is Posix. Would be nice to add
but not so easy for the non-Linux targets (Dos, OS/2 and Win32), I think.
Linux has a kernel call for it.
Mat Nieuwenhoven
| |
| Ilya Zakharevich 2004-03-27, 12:01 am |
| [A complimentary Cc of this posting was sent to
Mat Nieuwenhoven
<mnieuw@don'tincludethis@zap.a2000.nl>], who wrote in article <zavrhjmncnay.hv7w7g0.pminews@news.text.chello.nl>:
> :>> Watcom has a number of exec() funtions: execl, execle, execlp, execlpe,
> :>> execv, execve, execvp and execvpe, plus their wide-char equivalents. It
> :>> this what you mean?
> :>
> :>Nope. No misprint here.
>
> I just looked into the Perl 5.8.3 source, and I cannot see a single exec(
> there. I see spawnl , spawnvp, execvp, execl (e.g. in os2\os2.c around line
> 1419),
> which is all standard clib stuff, also according to
> http://www.opengroup.org/onlinepubs...tions/exec.html . What am I
> missing?
Probably it was me who is missing something. Let me see (I'm
traveling, but I have a laptop with a pretty complete setup)... You
are right, I mixed the Perl syntax `exec()' with C one; Perl's call is
translated to one of the appropriate C calls (IIRC, one uses spawn*()
with P_OVERLAY (sp?) flag).
> :>> >> some minor-but-tedious stuff auto-translation of /dev/tty and
> :>> >> /dev/null, etc.
> :>>
> :>> This is not Posix stuff, surely?
> :>This is why I explicitly wrote "POSIXish", not POSIX. ;-) I think all
> :>reasonable POSIXification translate these too...
>
> Ok, so if it's coded already there's no Watcom dependency.
Hmm??? Since, as I expected, Watcom does no POSIXification, I do not
see how one can expect anything good here...
> :>A sketch: open a large text file; read a thousand lines; read several
> :>more bytes; tell(); repeat reading; s() back; did you get to
> :>exactly the same position in the *CRLF-translated* stream?
>
> My tests indicates it works perfectly. 8600 line file with semi-random
> spotchecks get it right every time (finding the nth line with n changing
> after each hit, then reading some, then store tell() pos plus next 12 bytes
> in an array. At end, reverse through array-stored positions backward and read
> and compare).
All this with CRLF translation enabled? Good, this is as good as EMX does...
> :>EMX treats ^Z specially only if it is the last byte of the file, or
> :>(maybe only for TTY?) if it is immediately followed by \r? \n.
>
> Reading stops on the very first EOF (x1A) which is encountered, even if it is
> in the middle of the file. The EOF doesn't show up in the input stream.
In my experience, this logic creates a lot of trouble...
> :>> >> Reliable command-line argument quoting/dequoting and globbing (so
> :>> >> that arguments to spawnve() correspond 1-to-1 to argv[] array)?
> :>>
> :>> There is no cmd line parsing in Watcom as far as I know.
> :>
> :>Com'on, you mean argc/argv is not supported? ;-) A C compiler on OS/2
> :>can't work without command-line parsing...
>
> Of course Watcom has the normal argc/argv stuff. I thought you were referring
> to some parsing library function. I'm not sure what you mean by
> quoting/dequoting and globbing, though. I think Linux's getopt will treat
> (ignore the single quotes) '-l h' and '-lh' the same, I'm pretty sure that
> for Watcom the first case shows up as 2 arguments.
I do not mean getopt. Just the usual spawn*() and exec*() calls, and
whether the child will *always* see exactly the same argv/argc as
specified. Also, how the child can glob the given arguments. E.g.,
EMX's glob-the-argv function will not glob the arguments which were
quoted on the original command line.
> :>What about "Signal which killed it" part?
>
> You are referring, I guess, to macros such as WTERMSIG which can interpret
> the return value. Watcom doesn't have that. I'm not sure if it is easy to add
> without breaking existing functionality, the returned status word is already
> fully taken, although I think there's some room for a byte value in case of
> an unhandled SIGTERM. But this could break existing code.
Such things are impossible to add as an afterthought. To do this, EMX
restricts the return value to 8-bit (as POSIX does)... But in the
Perl case, this will restrict the functionality of working scripts
only a tiny bit; however, debugging/test-suite will be less reliable.
> :>This would restrict functionality *a lot*. Most scripts which need a
> :>timed read() would use alarm()...
>
> SIGALRM isn't part of the C spec, is it?
Com'on, you know that it is not possible to write anything useful
using C spec's alone (with a few obvious exceptions ;-). You can't
even read a directory.... So mentioning C specs in context of porting
is futile...
Hope this helps,
Ilya
|
|
|
|
|