Re: [9fans] APE and 9 together

Re: [9fans] APE and 9 together

[Alexander Povolotsky]

Welcome to "industrial strength" reality of "time to market" and "holding
the market share", which call on "backwards compatibility", modularity,
reusability and so on.
<forsyth@caldo.demon.co.uk <mailto:forsyth@caldo.demon.co.uk>> wrote in
message
<news:20010430111816.81B30199F6@mail.cse.psu.edu>...
> i don't think scope rules would be enough but that's why i suggested
> that if people really want to try they should just get on with it,
> and work out and test the details to allow the result to be assessed.
> they've got the source.
>
> in an earlier posting i was trying to point out that
> the APE library must maintain non-trivial state because the kernel
> doesn't implement what's required to emulate sockets and select (amongst
others),
> nor would i for one particularly like it to do so. thus
> accessing a file descriptor using the Plan 9 system calls -- whether
> the interface functions live in a different scope or not -- would not
> update the state the APE functions need to maintain. having those routines
> live in different scopes wouldn't suffice to fix it.
>
> that makes it hard to have Plan 9 native code invoke
> imported libraries compiled with APE. that could well be annoying.
> (if the imported software is self-contained
> commands, as with sim, or Icon or many other things i've
> imported, APE is fine.)
>
> on the other hand, at least some of the functions in the Plan 9
> libraries that invoke system calls (eg, open, read) or C library calls
> expect the Plan 9 behaviour, and wouldn't work without source changes
> if linked with the APE library. that makes it hard to have a program
> use arbitrary Plan 9 libraries and APE simultaneously (in general,
> although there are many useful specific exceptions).
>
> it's a horrible thought, though, that there could be a slippery slope
> that means that we never, ever get to simplify anything ever again
> because we need to keep compatibility.
>
>

Re: [9fans] APE and 9 together

[forsyth]

[-- Attachment #1: Type: text/plain, Size: 1610 bytes --]

i don't think scope rules would be enough but that's why i suggested
that if people really want to try they should just get on with it,
and work out and test the details to allow the result to be assessed.
they've got the source.

in an earlier posting i was trying to point out that
the APE library must maintain non-trivial state because the kernel
doesn't implement what's required to emulate sockets and select (amongst others),
nor would i for one particularly like it to do so.  thus
accessing a file descriptor using the Plan 9 system calls -- whether
the interface functions live in a different scope or not -- would not
update the state the APE functions need to maintain.  having those routines
live in different scopes wouldn't suffice to fix it.

that makes it hard to have Plan 9 native code invoke
imported libraries compiled with APE.  that could well be annoying.
(if the imported software is self-contained
commands, as with sim, or Icon or many other things i've
imported, APE is fine.)

on the other hand, at least some of the functions in the Plan 9
libraries that invoke system calls (eg, open, read) or C library calls
expect the Plan 9 behaviour, and wouldn't work without source changes
if linked with the APE library.  that makes it hard to have a program
use arbitrary Plan 9 libraries and APE simultaneously (in general,
although there are many useful specific exceptions).

it's a horrible thought, though, that there could be a slippery slope
that means that we never, ever get to simplify anything ever again
because we need to keep compatibility.


[-- Attachment #2: Type: message/rfc822, Size: 1996 bytes --]

From: "Douglas A. Gwyn" <DAGwyn@null.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] the declaration of main()
Date: Mon, 30 Apr 2001 09:25:16 GMT
Message-ID: <3AEB4415.7B320F15@null.net>

forsyth@caldo.demon.co.uk wrote:
> I don't want that cost in native Plan 9 programs.  I know, I know,
> they could have used `p9read' or `sys_read' instead and avoided the
> main POSIX names and then you could use both ...

What this points out is that we need something like namespaces.