A vision for Parrot

ruby-talk
1

Frodo Morris wrote:

Daniel Pfeiffer wrote:

Hi,
Apache would essentially have a mod_parrot. Maybe, if this can be
tested very hard, we’d even have a Parrot kernel module for all
Unices supporting that. Then exec() could perform compiled scripts
right away, like machine code :slight_smile:

I would have thought that a more platform-independent version of
this would be, say, a parrotd, which sits on top of the kernel,
intercepts calls to exec() bytecode and spawns the relevant processes.

What advantage would this have over putting a #! line in the bytecode?

Most existing *nix kernels (except some very old ones) will look at the
#!, parse out the path to an executable program, and the run it.

I may be wrong. This parrotd system would also help in projects like
Beowulfs (although why you’d be using byte-compiled languages in
parallel computing is beyond me), because you could use inetd or
similar to spawn a parrot when data was received on a certain port.

I don’t really see the point of having a parrotd, except if you want to
create something vaguely like PersistantPerl.

···

–
my $n = 2; print +(split //, ‘e,4c3H r ktulrnsJ2tPaeh’
…“\n1oa! er”)[map $n = ($n * 24 + 30) % 31, (42) x 26]

2

Benjamin Goldberg wrote:

Frodo Morris wrote:

Daniel Pfeiffer wrote:

Hi,
Apache would essentially have a mod_parrot. Maybe, if this can be
tested very hard, we’d even have a Parrot kernel module for all
Unices supporting that. Then exec() could perform compiled scripts
right away, like machine code :slight_smile:

I would have thought that a more platform-independent version of
this would be, say, a parrotd, which sits on top of the kernel,
intercepts calls to exec() bytecode and spawns the relevant processes.

What advantage would this have over putting a #! line in the bytecode?

Faster, better, cheaper.
Imagine if parrot could understand all interpreted code. Why not leave
it running, so that any Perl/Python/Tcl/Ruby/Java/sh/BASIC/whatever code
can get to it immediately? A parrotd exec would consist of: “Run this.”
“OK”. A #! consists of “Does this file exist?” “Yes.” “Does it
work?” “Yes.” “OK, run this.” “OK”. I contend that a properly set up
parrotd should be faster than the equivalent “each language set up
separately” environment.

···

–
FM

3

Frodo Morris wrote:

What advantage would this have over putting a #! line in the bytecode?
Faster, better, cheaper.
Imagine if parrot could understand all interpreted code. Why not leave
it running, so that any Perl/Python/Tcl/Ruby/Java/sh/BASIC/whatever code
can get to it immediately? A parrotd exec would consist of: “Run this.”
“OK”. A #! consists of “Does this file exist?” “Yes.” “Does it
work?” “Yes.” “OK, run this.” “OK”. I contend that a properly set up
parrotd should be faster than the equivalent “each language set up
separately” environment.

But not quite more secure. Imagine userX running a script that does
something nasty - like replace some command and then wait for root to
call it. This was a very simple example, since probably parrot would
recreate interpreters per script, but I guess it still could be possible
since it would be the same process…

I guess it’s a lot safer to just fork as it is now.

···

–
WK (written at Stardate 56849.3)

“Data typing is an illusion. Everything is a sequence of bytes.”
-Todd Coram

4

Frodo Morris wrote:

Benjamin Goldberg wrote:

Frodo Morris wrote:

Daniel Pfeiffer wrote:

Hi,
Apache would essentially have a mod_parrot. Maybe, if this can be
tested very hard, we’d even have a Parrot kernel module for all
Unices supporting that. Then exec() could perform compiled scripts
right away, like machine code :slight_smile:

I would have thought that a more platform-independent version of
this would be, say, a parrotd, which sits on top of the kernel,
intercepts calls to exec() bytecode and spawns the relevant
processes.

What advantage would this have over putting a #! line in the
bytecode?

Faster, better, cheaper.
Imagine if parrot could understand all interpreted code.

It can’t. Parrot can only understand parrot bytecode.

Why not leave it running, so that any Perl/Python/Tcl/Ruby/Java/sh/
BASIC/whatever code can get to it immediately?

Ignoring the problem of compiling those languages down to parrot
bytecode…

How should the kernel detect that a parrot-bytecode file is, in fact,
parrot bytecode?

For normal exe files, there’s the execute bit and some standard headers.
For normal scripts, there’s the execute bit and the #! line.

A parrotd exec would consist of: “Run this.” “OK”.
A #! consists of “Does this file exist?” “Yes.” “Does it
work?” “Yes.” “OK, run this.” “OK”.
I contend that a properly set up parrotd should be faster than the
equivalent “each language set up separately” environment.

The speed hit of exec() is not the time it takes to check if the file
named on the #! line exists and has the executable bit set… the speed
it is due to the time it takes to load that program into memory.

With that in mind, if you can special-case the kernel to pass scripts on
to special daemons, rather than loading up an interpreter for each
script, it will almost surely be faster, and not just for perl/parrot.

···

–
my $n = 2; print +(split //, ‘e,4c3H r ktulrnsJ2tPaeh’
…“\n1oa! er”)[map $n = ($n * 24 + 30) % 31, (42) x 26]

5

Frodo Morris wrote:

Benjamin Goldberg wrote:
…

What advantage would this have over putting a #! line in the bytecode?

Faster, better, cheaper.
Imagine if parrot could understand all interpreted code. Why not leave
it running, so that any Perl/Python/Tcl/Ruby/Java/sh/BASIC/whatever code
can get to it immediately?

Some years back, RMS proposed a standard ‘scripting’ language called
Guile. See, various languages like Tcl, Perl, Python, etc. were
being developed and none of them were 1) developed under the FSF nor
2) a variation of Scheme. (A simplified and perhaps biased
interpretation of mine.)

A key part of his proposal was that Guile would support translators
from other languages, like Python, C, etc., to Guile.

It didn’t happen. Writing those translators are hard because each
of the languages has different object models, which must be implemented
nearly perfectly. Guile is a full-fledge language built on years of
research into Lisp and scheme, so I would be surprised if it was any
easier to implement in Parrot’s byte code. It didn’t happen with
Guile, it’s even less likely to happen with Parrot.

I can “imagine if parrot …” But it isn’t going to happen without
huge amounts of work; comparable to writing Jython. (A Python
implementation written on top of Java rather than C.)

On the other hand, consider the gcc suite of tools. These convert C,
C++, Pascal, Fortran, Objective C, … into a more generic form. So
there is some known success in doing this. But I’ve looked at gcc
code and it isn’t something I want to hack, while I’ve contributed code
to Python’s C implementation.

				Andrew
				dalke@dalkescientific.com
6

Benjamin Goldberg goldbb2@earthlink.net writes:

Frodo Morris wrote:

Benjamin Goldberg wrote:

Frodo Morris wrote:
[…]

Why not leave it running, so that any Perl/Python/Tcl/Ruby/Java/sh/
BASIC/whatever code can get to it immediately?

Ignoring the problem of compiling those languages down to parrot
bytecode…

How should the kernel detect that a parrot-bytecode file is, in fact,
parrot bytecode?

For normal exe files, there’s the execute bit and some standard headers.
For normal scripts, there’s the execute bit and the #! line.

At least on BSD, /sys/kern/imgact_.c control which executable types
are allowed. There are imgact_aout.c, imgact_elf.c, imgact_gzip.c and
imgact_shell.c, and maybe one could add an imgact_parrot.c?

Regards,
Slaven

···

–
Slaven Rezic - slaven.rezic@berlin.de

Berlin Perl Mongers - http://berliner.pm.org
7

…
…

A key part of his proposal was that Guile would support translators
from other languages, like Python, C, etc., to Guile.

It didn’t happen. Writing those translators are hard because each
of the languages has different object models, which must be implemented
nearly perfectly. Guile is a full-fledge language built on years of
research into Lisp and scheme, so I would be surprised if it was any
easier to implement in Parrot’s byte code. It didn’t happen with
Guile, it’s even less likely to happen with Parrot.
…

Isn’t it a commonplace that the n x m translation problem is best solved
by having a common intermediate? This seems more efficient when

m+n < n*m

it seems that only those with sufficient muscle can force this on the
world eg Sun/IBM/M$. They can clearly see the need to support only one
backend.

Funnily enough they kept telling me that as soon as I switched to
F99/C++ etc etc that everything would be portable. Now the buzz is
C#/Mono or Java, and perhaps Parrot. As long as the wheels keep turning
and the $'s flow they’ll keep promising the next sliced bread.

···

–
Robin Becker

8

Benjamin Goldberg wrote:

Frodo Morris wrote:

Benjamin Goldberg wrote:

Frodo Morris wrote:

Daniel Pfeiffer wrote:

Hi,
Apache would essentially have a mod_parrot. Maybe, if this can be
tested very hard, we’d even have a Parrot kernel module for all
Unices supporting that. Then exec() could perform compiled scripts
right away, like machine code :slight_smile:

I would have thought that a more platform-independent version of
this would be, say, a parrotd, which sits on top of the kernel,
intercepts calls to exec() bytecode and spawns the relevant
processes.

What advantage would this have over putting a #! line in the
bytecode?

Faster, better, cheaper.
Imagine if parrot could understand all interpreted code.

It can’t. Parrot can only understand parrot bytecode.

Why not leave it running, so that any Perl/Python/Tcl/Ruby/Java/sh/
BASIC/whatever code can get to it immediately?

Ignoring the problem of compiling those languages down to parrot
bytecode…

How should the kernel detect that a parrot-bytecode file is, in fact,
parrot bytecode?

For normal exe files, there’s the execute bit and some standard headers.
For normal scripts, there’s the execute bit and the #! line.
It would be advantageous to performance if a pre-byte-compiled version
of the script hangs around that can be launched directly by parrot.
IANAE but doesn’t Python do this already? And doesn’t Java require this?

···

–
FM

9

Robin Becker robin@jessikat.fsnet.co.uk wrote in message news:3pE8dhAtvNy9EwoQ@jessikat.fsnet.co.uk…

it seems that only those with sufficient muscle can force this on the
world eg Sun/IBM/M$. They can clearly see the need to support only one
backend.

…each. :wink:

Well, I suppose Sun and IBM are sort of sharing.

Paul

P.S. Projects like Parrot only really tend to succeed if they either
produce results quickly enough for casually interested parties or have
enough direction and motivation for the prolonged period of time that
they aren’t producing highly usable output. Despite hearing about
Parrot occasionally, I’m not so sure that Parrot exhibits either of
these properties, but it would be nice to be proved wrong.

10

:Imagine if parrot could understand all interpreted code.

I would have to think for a bit to come up with a proof, but
it seems fairly likely to me that that would be impossible.

At the very least, for it to be possible, you would have to
program indefinite-length pointers and allow all available disk
space to be used as extended memory.

The problem that people keep forgetting is that Turing Equivilence
requires indefinite memory. Turing Machines are defined as having
infinite “tapes”. Given any finite memory size, I can come up with
an interpreter the emulation of which would not fit in that finite
memory size.

···

In article aqa2oa$8o1$1@news.ox.ac.uk, Frodo Morris <""> wrote:

Would you buy a used bit from this man??

11

Hi,

The problem that people keep forgetting is that Turing Equivilence
requires indefinite memory. Turing Machines are defined as having
infinite “tapes”. Given any finite memory size, I can come up with
an interpreter the emulation of which would not fit in that finite
memory size.

hmm, everytime I hear “bytecode interpreter” I imagine something like
higher level CPU (CISC/RISC doesn’t matter). And … if we have CPU,
“language X” compiler and assembler for that CPU, we might be able to
run “language X” anywhere the virtualCPU runs … therefore I don’t
understand your argumentation about TE. It might be slower than native
implementation of X, but it will be possible (at least) – without crazy
things like infinite resources. Everything depends on the three parts
mentioned above: compiler, assembler, b. interpreter.
I think parrot isn’t about “(si|e)mulation” … it’s about compilation.

Sincerely,
W.

···

–
Wejn <lists+rubytalk(at)box.cz>
(svamberk.net’s Linux section, fi.muni.cz student, linuxfan)

    Bored?  Want hours of entertainment?         <<<
      Just set the initdefault to 6!             <<<
12

Robin Becker wrote:

Funnily enough they kept telling me that as soon as I switched to
F99/C++ etc etc that everything would be portable.

Your confusion is in thinking that “portable” is a binary value. Fortran
was certainly more portable than assembler, as was C. Tcl is certainly
more portable than Fortran or C.

The other problem, of course, is that people keep improving their
capabilities, so what was portable is no longer adequate. Fortran is
quite portable, as long as you don’t want to do 3D graphics driven by a
data glove.

As long as you don’t want to do development in multiple languages or
dynamically load code safely over the net into some other OS process,
Tcl and Python are pretty good choices. Otherwise, you might want to
consider C# or Java.

See how it works? :slight_smile:

13

In article 3DC943CF.84A68F32@san.rr.com, Darren New dnew@san.rr.com
writes

Robin Becker wrote:

Funnily enough they kept telling me that as soon as I switched to
F99/C++ etc etc that everything would be portable.

Your confusion is in thinking that “portable” is a binary value. Fortran
was certainly more portable than assembler, as was C. Tcl is certainly
more portable than Fortran or C.

The other problem, of course, is that people keep improving their
capabilities, so what was portable is no longer adequate. Fortran is
quite portable, as long as you don’t want to do 3D graphics driven by a
data glove.

As long as you don’t want to do development in multiple languages or
dynamically load code safely over the net into some other OS process,
Tcl and Python are pretty good choices. Otherwise, you might want to
consider C# or Java.

See how it works? :slight_smile:
yes you claim to have a better mousetrap :slight_smile: and suddenly ther are
1.5.2/2.0/2.1/2.2/2.3a1 versions of Python and 6.4/7.1…8.4 of Tcl and
I must buy the right C compiler or OS or things don’t really quite port
oh well there you go.

English was portable until everyone started using it :wink:

···

–
Robin Becker

14

Walter Roberson wrote:

···

In article aqa2oa$8o1$1@news.ox.ac.uk, Frodo Morris <“”> wrote:
:Imagine if parrot could understand all interpreted code.

I would have to think for a bit to come up with a proof, but
it seems fairly likely to me that that would be impossible.

At the very least, for it to be possible, you would have to
program indefinite-length pointers and allow all available disk
space to be used as extended memory.

The problem that people keep forgetting is that Turing Equivilence
requires indefinite memory. Turing Machines are defined as having
infinite “tapes”. Given any finite memory size, I can come up with
an interpreter the emulation of which would not fit in that finite
memory size.
Perdantick bast. :slight_smile:
Imagine if parrot could understand all currently- and popularly-
implemented interpreted languages.

–
FM

15

In article aqbimo$a36$1@news.ox.ac.uk, Frodo Morris
…
…

The problem that people keep forgetting is that Turing Equivilence
requires indefinite memory. Turing Machines are defined as having
infinite “tapes”. Given any finite memory size, I can come up with
an interpreter the emulation of which would not fit in that finite
memory size.
Perdantick bast. :slight_smile:
Imagine if parrot could understand all currently- and popularly-
implemented interpreted languages.

which language was it that got kicked to death by the others?

···

–
Robin Becker

16

Robin Becker wrote:

In article aqbimo$a36$1@news.ox.ac.uk, Frodo Morris
.
…

The problem that people keep forgetting is that Turing Equivilence
requires indefinite memory. Turing Machines are defined as having
infinite “tapes”. Given any finite memory size, I can come up with
an interpreter the emulation of which would not fit in that finite
memory size.
Perdantick bast. :slight_smile:
Imagine if parrot could understand all currently- and popularly-
implemented interpreted languages.

which language was it that got kicked to death by the others?

XML, but it wasn’t a programming language. And they all kicked to
death because XML parsing is now considered a MUST for any “sane”
language.

···

–
Giuseppe “Oblomov” Bilotta

“Da grande lotterò per la pace”
“A me me la compra il mio babbo”
(Altan)
(“When I grow up, I will fight for peace”
“I’ll have my daddy buy it for me”)

17

According to Wojciech Kocjan wojciech@n0spam-kocjan.org:
:But not quite more secure. Imagine userX running a script that does
:something nasty - like replace some command and then wait for root to
:call it. This was a very simple example, since probably parrot would
:recreate interpreters per script, but I guess it still could be possible
:since it would be the same process…

Each script would need to be done in a seperate safe interpreter which
goes away at the end of the script, so there was no cross process
pollination.

···

–
Tcl - The glue of a new generation. <URL: http://wiki.tcl.tk/ >
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer’s opinions.
<URL: mailto:lvirden@yahoo.com > <URL: http://www.purl.org/NET/lvirden/ >

18

A.M. Kuchling wrote:

There’s also the problem of motivation: who’s going to write those
translators?
…
Guile programmers? If they’re Guile programmers, they must like
programming in Scheme. Why would they work on translators for languages
they’ll never use?

And Guile programmrs is the right choice of words. Most Scheme
programmers does not use Guile. In most cases there are better
alternatives such as DrScheme and Bigloo.

19

I gather that’s what Tao’s Elate/Intent Virtual Processor does. I
never was able to find information about it apart from the new Amiga
related ones, though.

Massimiliano

···

On Thu, Nov 07, 2002 at 01:25:40AM +0900, Wejn wrote:

And … if we have CPU, “language X” compiler and assembler for that
CPU, we might be able to run “language X” anywhere the virtualCPU
runs …