Re: [9fans] Pegasus 2.6 is released

Re: [9fans] Pegasus 2.6 is released

[Kenji Arisawa]

Sorry,

http://plan9.aichi-u.ac.jp/pegasus/eman-2.6/

Kenji Arisawa

On 2009/02/01, at 13:41, lucio@proxima.alt.za wrote:

>> Pegasus 2.6 is released with new WebDAV script written in Lua.
>> Take a look at http://plan9/remoty/pegasus/eman-2.6/ for more
>> details.
>
> We need a little bit more than "plan9" in the host name :-)
>
> ++L

[9fans] Pegasus 2.6 is released

[Kenji Arisawa]

Hello,

Pegasus 2.6 is released with new WebDAV script written in Lua.
Take a look at http://plan9/remoty/pegasus/eman-2.6/ for more details.

Enjoy

Kenji Arisawa

Re: [9fans] Pegasus 2.6 is released

[lucio]

> Pegasus 2.6 is released with new WebDAV script written in Lua.
> Take a look at http://plan9/remoty/pegasus/eman-2.6/ for more details.

We need a little bit more than "plan9" in the host name :-)

++L

Re: [9fans] Pegasus 2.6 is released

[Kenji Arisawa]

Sorry,

http://plan9.aichi-u.ac.jp/pegasus/eman-2.6/

Kenji Arisawa

On 2009/02/01, at 13:41, lucio@proxima.alt.za wrote:

>> Pegasus 2.6 is released with new WebDAV script written in Lua.
>> Take a look at http://plan9/remoty/pegasus/eman-2.6/ for more
>> details.
>
> We need a little bit more than "plan9" in the host name :-)
>
> ++L
>
>

Re: [9fans] Pegasus 2.6 is released

[John Barham]

Kenji Arisawa wrote:

> Pegasus 2.6 is released with new WebDAV script written in Lua.
> Take a look at http://plan9/remoty/pegasus/eman-2.6/ for more details.

Do you have a non-local URL host name?

Re: [9fans] Pegasus 2.6 is released

[andrey mirtchovski]

http://plan9.aichi-u.ac.jp/pegasus/eman-2.6/

Re: [9fans] Pegasus 2.6 is released

[John Barham]

> Pegasus 2.6 is released with new WebDAV script written in Lua.

Interesting that you used Lua.  I think it's generally
under-appreciated but IMO is very well designed and philosophically a
good fit for Plan 9.  However, inasmuch as you had to build a custom
interpreter to add features for Pegasus this exposes a weakness of
Plan 9 in that it can't dynamically load libraries at run-time which
is the normal extension mechanism for scripting languages on other
platforms.

Can someone comment on how feasible it would be to add general support
for dynamically loading libraries to Plan 9?  Is there some structural
reason why it can't be done or is it just that nobody has done the
work yet?  Note that I am specifically not asking about "shared"
libraries...

  John

Re: [9fans] Pegasus 2.6 is released

[erik quanstrom]

> However, inasmuch as you had to build a custom
> interpreter to add features for Pegasus this exposes a weakness of
> Plan 9 in that it can't dynamically load libraries at run-time which
> is the normal extension mechanism for scripting languages on other
> platforms.

pegasus is written in c, not a scripting language.
i believe lua is used as one possible language for
cgi.

the argument that if the normal extension
mechanism for scripting languages is x,
thereforenot having x is a weakness seems
a version of argumentum ad populum.

doesn't dynamic loading seem at odds with the
tools approach?  the more complex the interface,
the less general the tool.

- erik

Re: [9fans] Pegasus 2.6 is released

[John Barham]

> the argument that if the normal extension
> mechanism for scripting languages is x,
> thereforenot having x is a weakness seems
> a version of argumentum ad populum.
>
> doesn't dynamic loading seem at odds with the
> tools approach?  the more complex the interface,
> the less general the tool.

Dynamic loading allows scripting languages to load arbitrary binary
extensions at run-time.  Without dynamic loading in Plan 9 you need to
recompile the Lua (or Python) interpreters to statically link in your
binary extensions, so in this case dynamic loading makes the tool more
general.  (FWIW, as has been pointed out on this list previously,
Inferno applications can dynamically load modules at run-time.)

  John

Re: [9fans] Pegasus 2.6 is released

[Francisco J Ballesteros]

Can't you just execute new processes to "load" your
extensions?

I understand that's not a dll, but I'm really scared of
dlls after looking at what happen to linux. At least separate
binaries still work if you change libraries.

Just wondering.

On Sun, Feb 1, 2009 at 8:27 AM, John Barham <jbarham@gmail.com> wrote:
>> the argument that if the normal extension
>> mechanism for scripting languages is x,
>> thereforenot having x is a weakness seems
>> a version of argumentum ad populum.
>>
>> doesn't dynamic loading seem at odds with the
>> tools approach?  the more complex the interface,
>> the less general the tool.
>
> Dynamic loading allows scripting languages to load arbitrary binary
> extensions at run-time.  Without dynamic loading in Plan 9 you need to
> recompile the Lua (or Python) interpreters to statically link in your
> binary extensions, so in this case dynamic loading makes the tool more
> general.  (FWIW, as has been pointed out on this list previously,
> Inferno applications can dynamically load modules at run-time.)
>
>  John
>
>

Re: [9fans] Pegasus 2.6 is released

[erik quanstrom]

> > the argument that if the normal extension
> > mechanism for scripting languages is x,
> > thereforenot having x is a weakness seems
> > a version of argumentum ad populum.
> >
> > doesn't dynamic loading seem at odds with the
> > tools approach?  the more complex the interface,
> > the less general the tool.
>
> Dynamic loading allows scripting languages to load arbitrary binary
> extensions at run-time.  Without dynamic loading in Plan 9 you need to
> recompile the Lua (or Python) interpreters to statically link in your
> binary extensions, so in this case dynamic loading makes the tool more
> general.  (FWIW, as has been pointed out on this list previously,
> Inferno applications can dynamically load modules at run-time.)

why do you assume that lua or whatever is not sufficient
for the task?  maybe it's the language itself that needs fixing.

otoh, my experience building websites is that i've never wanted
arbitrary functionality in the cgi.  once things got sufficiently
compliated, it made sense to build a server to manage
user sessions and whatnot.

- erik

Re: [9fans] Pegasus 2.6 is released

[sqweek]

On Sun, Feb 1, 2009 at 4:27 PM, John Barham <jbarham@gmail.com> wrote:
> Dynamic loading allows scripting languages to load arbitrary binary
> extensions at run-time.  Without dynamic loading in Plan 9...

 You're missing the beauty of 9p. Who needs dynload() when you have mount()?
-sqweek

Re: [9fans] Pegasus 2.6 is released

[erik quanstrom]

> On Sun, Feb 1, 2009 at 4:27 PM, John Barham <jbarham@gmail.com> wrote:
>> Dynamic loading allows scripting languages to load arbitrary binary
>> extensions at run-time.  Without dynamic loading in Plan 9...
>
>  You're missing the beauty of 9p. Who needs dynload() when you have mount()?

this thinking goes back to the beginning with pipes
and the shell.  to use object-oriented language out of place,
any program that produces or consumes a byte stream
can be extended by another program that produces or
consumes a byte stream.

with a thread library program that passes messages
on channels, one could do similar extensions by replacing
one end of the channel in a similar manner to replacing
a program in a regular pipe.  though message typing would
limit the generality of the arrangement.

- erik

Re: [9fans] Pegasus 2.6 is released

[Roman V. Shaposhnik]

On Tue, 2009-02-03 at 04:25 +0900, sqweek wrote:
> On Sun, Feb 1, 2009 at 4:27 PM, John Barham <jbarham@gmail.com> wrote:
> > Dynamic loading allows scripting languages to load arbitrary binary
> > extensions at run-time.  Without dynamic loading in Plan 9...
>
>  You're missing the beauty of 9p. Who needs dynload() when you have mount()?

I was going to say exactly that! dynload() is really not very well
suited for a highly distributed age. I have come to realize that
it is nothing but an unfortunate optimization of R out of RPC.

Now, making 'R' fast (if your caller-callee is on the same node, etc)
is very much desired. Trying to get rid of it, or pretend that
it is not needed -- is doomed.

Thanks,
Roman.

Re: [9fans] Pegasus 2.6 is released

[John Barham]

>  You're missing the beauty of 9p. Who needs dynload() when you have mount()?

Mount allows me to add new names to the process namespace.  Dynload
allows me to call functions or access data in a library that is not
known to the process (e.g., scripting language interpreter) until
runtime.  They solve different problems.

  John

Re: [9fans] Pegasus 2.6 is released

[erik quanstrom]

>>  You're missing the beauty of 9p. Who needs dynload() when you have mount()?
>
> Mount allows me to add new names to the process namespace.  Dynload
> allows me to call functions or access data in a library that is not
> known to the process (e.g., scripting language interpreter) until
> runtime.  They solve different problems.

there is no fundamental reason they could not solve the same problem.
why are you so keen to remove the rpc?

- erik

Re: [9fans] Pegasus 2.6 is released

[David Leimbach]

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

On Mon, Feb 2, 2009 at 1:22 PM, John Barham <jbarham@gmail.com> wrote:

> >  You're missing the beauty of 9p. Who needs dynload() when you have
> mount()?
>
> Mount allows me to add new names to the process namespace.  Dynload
> allows me to call functions or access data in a library that is not
> known to the process (e.g., scripting language interpreter) until
> runtime.  They solve different problems.


They solve the same class of problems, if you step back far enough.

If your application's mechanism of dealing with processing is to use the
namespace, then binding new functionality over old is roughly equivalent to
a plugin mechanism.

I mean sure you could use FTP to transfer files, but the old shell based
tools are automagically plugged in with network capabilities when they deal
with a FTP backed namespace right?  So without any binary loader
capabilities "cp" "mv" and other existing "small programs" are now "plugged
in".

Dave



>
>
>  John
>
>

[-- Attachment #2: Type: text/html, Size: 1609 bytes --]

Re: [9fans] Pegasus 2.6 is released

[Roman V. Shaposhnik]

On Mon, 2009-02-02 at 13:32 -0800, David Leimbach wrote:

> I mean sure you could use FTP to transfer files, but the old shell
> based tools are automagically plugged in with network capabilities
> when they deal with a FTP backed namespace right?  So without any
> binary loader capabilities "cp" "mv" and other existing "small
> programs" are now "plugged in".

Right. That plus the fact that the "plugin" is now generally available
over the network makes it much more interesting.

In fact, these current trend towards REST in web services seems
to be a validation of 9P view of the world.

Thanks,
Roman.

Re: [9fans] Pegasus 2.6 is released

[erik quanstrom]

> Right. That plus the fact that the "plugin" is now generally available
> over the network makes it much more interesting.
>
> In fact, these current trend towards REST in web services seems
> to be a validation of 9P view of the world.

it's interesting to compare this with the sleezy not-paths
that e.g. gnome programs can take, like uris.  great as long
as long as you don't care to use anything but gnome tools.

i suppose you could link sed &c against gnome.  but that's
crass, even by linux standards.

- erik

Re: [9fans] Pegasus 2.6 is released

[Anthony Sorace]

erik wrote:

> it's interesting to compare this with the sleezy not-paths
> that e.g. gnome programs can take, like uris.  great as long
> as long as you don't care to use anything but gnome tools.

i had that debate with a kde-loving linux admin. i had been explaining
why plan 9 was interesting or significant, and he countered with the
kde example. i was marginally impressed by the number of protocols
they handled, but when i asked how you'd use it with cat and friends,
he said "no, just use kate".

i reeled, stuttered, tried to get out something that sounded like
"layering violation", and ran away. it wasn't even a cost/benefit
argument; there wasn't any recognition of the costs.

Re: [9fans] Pegasus 2.6 is released

[erik quanstrom]

> i had that debate with a kde-loving linux admin. i had been explaining
> why plan 9 was interesting or significant, and he countered with the
> kde example. i was marginally impressed by the number of protocols
> they handled, but when i asked how you'd use it with cat and friends,
> he said "no, just use kate".
>
> i reeled, stuttered, tried to get out something that sounded like
> "layering violation", and ran away. it wasn't even a cost/benefit
> argument; there wasn't any recognition of the costs.

does he also plans to build a tcp/ip stack into his
applications?  maybe we could dispense with the kernel.
it's complicated anyway.  each application could drive
hardware itself.  but to make this easier, we'll used shared
libraries.  the only system service we'd need is a shared library
loader.

- erik

Re: [9fans] Pegasus 2.6 is released

[Anthony Sorace]

you, um... never mind. what can i say?

http://www.gnu.org/manual/gawk/html_node/Special-Network.html#Special-Network

Re: [9fans] Pegasus 2.6 is released

[Bruce Ellis]

Can I just say hahahahahahaha.

Or maybe welcome to the 80's.

brrucee

On Tue, Feb 3, 2009 at 9:57 AM, Anthony Sorace <anothy@gmail.com> wrote:
> you, um... never mind. what can i say?
>
> http://www.gnu.org/manual/gawk/html_node/Special-Network.html#Special-Network
>
>

Re: [9fans] Pegasus 2.6 is released

[lucio]

> maybe we could dispense with the kernel.
> it's complicated anyway.  each application could drive
> hardware itself.  but to make this easier, we'll used shared
> libraries.  the only system service we'd need is a shared library
> loader.

There's your final word in microkernels.  Throw away security and
things get a lot less complicated.  The human brain does not have,
that I am aware, security boundaries, why can't we model our personal
computers on that?

++L

PS: In jest, of course, but there's some value...

Re: [9fans] Pegasus 2.6 is released

[Bruce Ellis]

Or as Mark V. Shaney once said ...

"Why can't everyone wake up at 3am, totally confused".

I'm not sure of the relevance.

brucee

On Tue, Feb 3, 2009 at 3:26 PM,  <lucio@proxima.alt.za> wrote:
>> maybe we could dispense with the kernel.
>> it's complicated anyway.  each application could drive
>> hardware itself.  but to make this easier, we'll used shared
>> libraries.  the only system service we'd need is a shared library
>> loader.
>
> There's your final word in microkernels.  Throw away security and
> things get a lot less complicated.  The human brain does not have,
> that I am aware, security boundaries, why can't we model our personal
> computers on that?
>
> ++L
>
> PS: In jest, of course, but there's some value...
>
>
>

Re: [9fans] Pegasus 2.6 is released

[ron minnich]

On Mon, Feb 2, 2009 at 8:26 PM,  <lucio@proxima.alt.za> wrote:
>> maybe we could dispense with the kernel.
>> it's complicated anyway.  each application could drive
>> hardware itself.  but to make this easier, we'll used shared
>> libraries.  the only system service we'd need is a shared library
>> loader.

um, sadly, this *is* the norm nowadays in HPC. And here you all
thought you were joking.

ron

Re: [9fans] Pegasus 2.6 is released

[David Leimbach]

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

On Mon, Feb 2, 2009 at 2:30 PM, Anthony Sorace <anothy@gmail.com> wrote:

> erik wrote:
>
> > it's interesting to compare this with the sleezy not-paths
> > that e.g. gnome programs can take, like uris.  great as long
> > as long as you don't care to use anything but gnome tools.
>
> i had that debate with a kde-loving linux admin. i had been explaining
> why plan 9 was interesting or significant, and he countered with the
> kde example. i was marginally impressed by the number of protocols
> they handled, but when i asked how you'd use it with cat and friends,
> he said "no, just use kate".
>
> i reeled, stuttered, tried to get out something that sounded like
> "layering violation", and ran away. it wasn't even a cost/benefit
> argument; there wasn't any recognition of the costs.
>
> Right but when you consider KDE runs on windows, then it's not as much of a
layering violation... no more than Java is I guess anyway.
The layering violation that I usually point at is the /dev/tcp created by
the bash shell :-).

[-- Attachment #2: Type: text/html, Size: 1443 bytes --]

Re: [9fans] Pegasus 2.6 is released

[ron minnich]

On Mon, Feb 2, 2009 at 1:32 PM, David Leimbach <leimy2k@gmail.com> wrote:

> They solve the same class of problems, if you step back far enough.
> If your application's mechanism of dealing with processing is to use the
> namespace, then binding new functionality over old is roughly equivalent to
> a plugin mechanism.


I hate to be the one to bring this up but ... if you are providing
some extended (e.g.) math functionality to a program with a shared
library, people are going to be upset with you if you argue that it
can be done with RPC.

I hope the reason is obvious :-)

ron

Re: [9fans] Pegasus 2.6 is released

[erik quanstrom]

> I hate to be the one to bring this up but ... if you are providing
> some extended (e.g.) math functionality to a program with a shared
> library, people are going to be upset with you if you argue that it
> can be done with RPC.

i thought we were talking about linking c into scripting languages.
you're not using python to actually do the calcuations, are you?

- erik

Re: [9fans] Pegasus 2.6 is released

[ron minnich]

On Mon, Feb 2, 2009 at 2:14 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>> I hate to be the one to bring this up but ... if you are providing
>> some extended (e.g.) math functionality to a program with a shared
>> library, people are going to be upset with you if you argue that it
>> can be done with RPC.
>
> i thought we were talking about linking c into scripting languages.
> you're not using python to actually do the calcuations, are you?
>

not me. But a depressingly large number of people do, nowadays.

ron

Re: [9fans] Pegasus 2.6 is released

[erik quanstrom]

> not me. But a depressingly large number of people do, nowadays.

i don't drink enough to keep up with modern developments.

- erik

Re: [9fans] Pegasus 2.6 is released

[Roman V. Shaposhnik]

On Mon, 2009-02-02 at 14:12 -0800, ron minnich wrote:
> On Mon, Feb 2, 2009 at 1:32 PM, David Leimbach <leimy2k@gmail.com> wrote:
>
> > They solve the same class of problems, if you step back far enough.
> > If your application's mechanism of dealing with processing is to use the
> > namespace, then binding new functionality over old is roughly equivalent to
> > a plugin mechanism.
>
>
> I hate to be the one to bring this up but ... if you are providing
> some extended (e.g.) math functionality to a program with a shared
> library, people are going to be upset with you if you argue that it
> can be done with RPC.
>
> I hope the reason is obvious :-)

It is. It is a trivial case, after all. In non-trivial ones, the
same kind of discussion used to be quite popular in OpenMP vs.
MPI circles. And I shouldn't be the one to tell you where it
is going, right?

Thanks,
Roman.

Re: [9fans] Pegasus 2.6 is released

[Francisco J Ballesteros]

But can't you `script' by calling an external program, sending it your
input, and reading its output?

I understand that if you have a language (say limbo) that requires loadable
modules then it's another thing.

However, if you want, say, to be able to process web pages or whatever just
by applying different modules. Why can't them be different processes?

You can just pipe your data through them.

On Mon, Feb 2, 2009 at 11:18 PM, Roman V. Shaposhnik <rvs@sun.com> wrote:
> On Mon, 2009-02-02 at 14:12 -0800, ron minnich wrote:
>> On Mon, Feb 2, 2009 at 1:32 PM, David Leimbach <leimy2k@gmail.com> wrote:
>>
>> > They solve the same class of problems, if you step back far enough.
>> > If your application's mechanism of dealing with processing is to use the
>> > namespace, then binding new functionality over old is roughly equivalent to
>> > a plugin mechanism.
>>
>>
>> I hate to be the one to bring this up but ... if you are providing
>> some extended (e.g.) math functionality to a program with a shared
>> library, people are going to be upset with you if you argue that it
>> can be done with RPC.
>>
>> I hope the reason is obvious :-)
>
> It is. It is a trivial case, after all. In non-trivial ones, the
> same kind of discussion used to be quite popular in OpenMP vs.
> MPI circles. And I shouldn't be the one to tell you where it
> is going, right?
>
> Thanks,
> Roman.
>
>
>

Re: [9fans] Pegasus 2.6 is released

[Roman V. Shaposhnik]

On Mon, 2009-02-02 at 23:22 +0100, Francisco J Ballesteros wrote:
> But can't you `script' by calling an external program, sending it your
> input, and reading its output?

Well, the way I see it: exec'ing is just a way to get to a transient
channel. Its no different from that very same channel being present
permanently in /srv or /mnt/factotum/rpc. There's *slightly* less
overhead with pipes, but that's about it.

Thanks,
Roman.

Re: [9fans] Pegasus 2.6 is released

[Richard Miller]

> if you are providing
> some extended (e.g.) math functionality to a program with a shared
> library, people are going to be upset with you if you argue that it
> can be done with RPC.
>
> I hope the reason is obvious :-)

Not obvious to me.  In today's (well, tomorrow's) massively multicore
world, I would expect a remote call to a process in another core, with
its own instruction cache, could easily be more efficient than a local
procedure call.

Re: [9fans] Pegasus 2.6 is released

[ron minnich]

On Tue, Feb 3, 2009 at 2:55 AM, Richard Miller <9fans@hamnavoe.com> wrote:

> Not obvious to me.  In today's (well, tomorrow's) massively multicore
> world, I would expect a remote call to a process in another core, with
> its own instruction cache, could easily be more efficient than a local
> procedure call.
>

well, there's remote calls and remote calls. Remote calls that go
through some shared memory queue are one thing. But a remote call that
goes through the kernel? You'd better have lots of work to amortize
that cost. The packages I've seen do not.

thanks

ron

Re: [9fans] Pegasus 2.6 is released

[erik quanstrom]

> > Not obvious to me.  In today's (well, tomorrow's) massively multicore
> > world, I would expect a remote call to a process in another core, with
> > its own instruction cache, could easily be more efficient than a local
> > procedure call.
> >
>
> well, there's remote calls and remote calls. Remote calls that go
> through some shared memory queue are one thing. But a remote call that
> goes through the kernel? You'd better have lots of work to amortize
> that cost. The packages I've seen do not.

ignorant question.

is the cost in latency or cycles?  if the cost is latency
and your application is parallel, could the simple trick
of having multple outstanding help?

- erik

Re: [9fans] Pegasus 2.6 is released

[ron minnich]

Here's the best answer I can give, check this out:
http://www.scipy.org/

But as for introducing parallelism to cover the latency, it's an old
trick and works well. But do you want to be the one to tell people,
"you're going to have to introduce parallelism and fingernail-pulling
bugs because I want you to use RPC, not shared libraries". I'm sure
not going to do it, I've been handed my head enough times by the
programmers :-)

One thing I've learned: some people will take a hit of a factor of
1000 in performance to preserve their concept of what is easy to use.
Hence things like scipy. It works well for many people.

ron

Re: [9fans] Pegasus 2.6 is released

[erik quanstrom]

> One thing I've learned: some people will take a hit of a factor of
> 1000 in performance to preserve their concept of what is easy to use.
> Hence things like scipy. It works well for many people.

thanks for the reference.

this is an interesting problem.  most of the time a 1000x hit is
a great deal in the interest of simplicity.  the trick is finding
the problems you're willing to pay for.

to the original complaint about gnome and its ilk:
i don't see the argument against using file servers (rpc) instead
of shared libraries (creating a super-secret wormhole world).
it's not like the ftp/http transfers aren't all of the slowness,
at least to a first-order approximation.

- erik

Re: [9fans] Pegasus 2.6 is released

[Roman V. Shaposhnik]

On Mon, 2009-02-02 at 13:22 -0800, John Barham wrote:
> >  You're missing the beauty of 9p. Who needs dynload() when you have
> mount()?
>
> Mount allows me to add new names to the process namespace.  Dynload
> allows me to call functions or access data in a library that is not
> known to the process (e.g., scripting language interpreter) until
> runtime.  They solve different problems.

Depends on your point of view. Except for accessing data directly
in the same address space, dynload() is just a way of doing fast
RPC. In that line of thought, 9P offers you a very similar mechanism.

I think the most obvious example of how 9P can be used to provide the
kind of extensibility that folks usually associate with dynload()
is factotum. Especially if you compare it with things like PAM.

Thanks,
Roman.

Re: [9fans] Pegasus 2.6 is released

[Charles Forsyth]

using a variant of something we developed and then
re-developed for Inferno, you can dynamically load
C modules at run time, and unusually, with type checking,
with support in the compilers and loaders.

well, i say "modules", but of course the language pre-dates
them. people pretend.  it uses import/export tables with type signatures.
those are stashed in the a.out (viz. DYN_MAGIC in a.out.h)
so they stay together.

Re: [9fans] Pegasus 2.6 is released

[lucio]

> well, i say "modules", but of course the language pre-dates
> them. people pretend.  it uses import/export tables with type signatures.
> those are stashed in the a.out (viz. DYN_MAGIC in a.out.h)
> so they stay together.

It's not what the OP suggested.  Nor are Nemo's reservation valid.
We're talking about loading source modules into an interpreter.  This
means that different modules may be loaded, sometimes even by the same
instruction and that libraries are not terribly significant unless the
invoker gets the sequence wrong, which is a programming error.

The remaining reservation is security, can somebody replace a module
with a Trojan horse?  In Plan 9 the risk is much smaller, I dare not
say non-existent.

Recent instances of the Korn shell have this feature.  Bolsky and Korn
describe these features in some details in "The New Korn Shell", 1995.

++L

Re: [9fans] Pegasus 2.6 is released

[erik quanstrom]

On Sun Feb  1 06:57:13 EST 2009, lucio@proxima.alt.za wrote:
> > well, i say "modules", but of course the language pre-dates
> > them. people pretend.  it uses import/export tables with type signatures.
> > those are stashed in the a.out (viz. DYN_MAGIC in a.out.h)
> > so they stay together.
>
> It's not what the OP suggested.  Nor are Nemo's reservation valid.
> We're talking about loading source modules into an interpreter.  This
> means that different modules may be loaded, sometimes even by the same
> instruction and that libraries are not terribly significant unless the
> invoker gets the sequence wrong, which is a programming error.

not true.  this is the original quote.

> Dynamic loading allows scripting languages to load arbitrary binary
> extensions at run-time.  Without dynamic loading in Plan 9 you need to

- erik

Re: [9fans] Pegasus 2.6 is released

[John Barham]

> using a variant of something we developed and then
> re-developed for Inferno, you can dynamically load
> C modules at run time, and unusually, with type checking,
> with support in the compilers and loaders.

Is the code to do this available for public consumption?

Re: [9fans] Pegasus 2.6 is released

[ron minnich]

On Mon, Feb 2, 2009 at 9:38 AM, John Barham <jbarham@gmail.com> wrote:
>> using a variant of something we developed and then
>> re-developed for Inferno, you can dynamically load
>> C modules at run time, and unusually, with type checking,
>> with support in the compilers and loaders.
>
> Is the code to do this available for public consumption?
>
>

I think we're going in circles again. IIRC my discussion of dynload
for python should point at what Charles et. al. enabled and what I
subsequently used to do dynload for python, which is usable in
general, esp. if your code is type-safe (unlike Python).

ron