Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Parrot 1.0.0 Released

timothy posted more than 5 years ago | from the take-a-beak dept.

Perl 120

outZider writes "Parrot 1.0.0 was released last night! The release of Parrot 1.0 provides the first "stable" release to developers, with a supportable, stable API for language developers to build from. For those who don't know, Parrot is a virtual machine for dynamic languages like Perl, PHP, Python, and Ruby, and is best known as the virtual machine for Rakudo, the reference implementation of Perl 6."

cancel ×

120 comments

Sorry! There are no comments related to the filter you selected.

Lord of the Bytecodes (3, Funny)

Anonymous Coward | more than 5 years ago | (#27245315)

One Bytecode to rule them all, One Bytecode to describe them, One Bytecode to bring them all and in the OS bind them.

Re:Lord of the Bytecodes (1, Funny)

Yvan256 (722131) | more than 5 years ago | (#27245367)

And that bytecode is.... 42.

Re:Lord of the Bytecodes (1, Informative)

Poltras (680608) | more than 5 years ago | (#27249151)

'C'?

Re:Lord of the Bytecodes (2, Informative)

IpalindromeI (515070) | more than 5 years ago | (#27254657)

ASCII character 42 (decimal) is '*'. ASCII character 0x42 (hex) is 'B'. Sorry, try again.

Parrot 1.0.0 Released (2, Funny)

Anonymous Coward | more than 5 years ago | (#27245887)

Parrot 1.0.0 was released last night! The release of Parrot 1.0 provides the first "stable" release to developers, with a supportable, stable API for language developers to build from. For those who don't know, Parrot is a virtual machine for dynamic languages like Perl, PHP, Python, and Ruby, and is best known as the virtual machine for Rakudo, the reference implementation of Perl 6.

SQUAWK! On topic!

Re:Parrot 1.0.0 Released (2, Funny)

grcumb (781340) | more than 5 years ago | (#27249169)

SQUAWK! On topic!

For god's sake, someone nail his feet to the pedestal.

Re:Parrot 1.0.0 Released (0)

Anonymous Coward | more than 5 years ago | (#27251025)

He's pinin' for the fjords!

Down too?! (1)

x78 (1099371) | more than 5 years ago | (#27245377)

Umm is it me or has the internet been slashdotted?!
The 2 times I want to read TFA as well, bah!

Re:Down too?! (3, Informative)

Volanin (935080) | more than 5 years ago | (#27245521)

This is the first time I heard about Parrot, and it really got my attention as well.
I know it's common knowlegde, but you can get more information in wikipedia:

http://en.wikipedia.org/wiki/Parrot_virtual_machine [wikipedia.org]

Enjoy!

Re:Down too?! (2, Funny)

DragonWriter (970822) | more than 5 years ago | (#27245555)

Umm is it me or has the internet been slashdotted?!

Probably; that usually happens when someone posts a link to the internet on Slashdot. Someone really needs to update the server for the internet.

Re:Down too?! (1)

jo42 (227475) | more than 5 years ago | (#27248165)

It's pining for the fjords.

Um, "yay!"? (0)

Anonymous Coward | more than 5 years ago | (#27245383)

Sorry, exclamation points in summaries always throw me off.

Slashdotted parrot (4, Funny)

davidwr (791652) | more than 5 years ago | (#27245425)

I'll tell you what's wrong with it, my lad. 'E's slashdotted, that's what's wrong with it!

Re:Slashdotted parrot (4, Funny)

Yvan256 (722131) | more than 5 years ago | (#27245607)

Not it's not! It's just swapping!

Re:Slashdotted parrot (1)

Millennium (2451) | more than 5 years ago | (#27245693)

That server wouldn't 'voom' 'cause you put four million requests through it! 'E's bleedin' slashdotted!

Re:Slashdotted parrot (1)

Camann (1486759) | more than 5 years ago | (#27246309)

Remarkable VM, the Parrot, idn'it, ay? Beautiful interface!

Re:Slashdotted parrot (0)

Anonymous Coward | more than 5 years ago | (#27247689)

The interface doesn't come into it - e's deadlocked!

Re:Slashdotted parrot (3, Funny)

QRDeNameland (873957) | more than 5 years ago | (#27247637)

It's pining for the DWORDs!

:) I wish I had another mod point for you. (1)

toby (759) | more than 5 years ago | (#27257601)

n/t

Is it really ready? (1)

TheLink (130905) | more than 5 years ago | (#27245433)

What's the performance and stability like?

I remember doing some benchmarks more than a year ago and plain perl 5 was faster.

Hope it's much better now...

Re:Is it really ready? (1)

jandrese (485) | more than 5 years ago | (#27245457)

I would hope that the release version will be more stable than the early beta you must have used over a year ago...

Re:Is it really ready? (1, Interesting)

Anonymous Coward | more than 5 years ago | (#27245895)

I would hope that the release version will be more stable than the early beta you must have used over a year ago...

'Early'? Because nothing good came out of the first six years of development?

Re:Is it really ready? (0)

Anonymous Coward | more than 5 years ago | (#27246559)

4-5 years worth of alphas from what I remember.

Compiler for Perl? (1)

Futurepower(R) (558542) | more than 5 years ago | (#27245877)

Slightly off topic: Is there a compiler for Perl, that is not based on bytecode, and therefore is difficult to decompile?

Re:Compiler for Perl? (3, Funny)

drinkypoo (153816) | more than 5 years ago | (#27246033)

Slightly off topic: Is there a compiler for Perl, that is not based on bytecode, and therefore is difficult to decompile?

I thought perl source was considered sufficiently obfuscated that it was safe from reverse-engineering in source form. Why on Earth would you want to do something like this anyway?

Re:Compiler for Perl? (1)

chromatic (9471) | more than 5 years ago | (#27246293)

I thought perl source was considered sufficiently obfuscated that it was safe from reverse-engineering in source form.

If you don't know Perl, you may have difficulty reading programs written in Perl. (I have a similar problem with Mandarin.) If you do know Perl, try B::Deparse [cpan.org] for decoding obfuscated Perl.

Re:Compiler for Perl? (0)

Anonymous Coward | more than 5 years ago | (#27246861)

It's impossible to read Mandarin, it's a spoken dialect. Chinese is the written language. Of course, they do have the simplified and traditional versions of written chinese.

Re:Compiler for Perl? (1)

chromatic (9471) | more than 5 years ago | (#27247615)

It's impossible to read Mandarin, it's a spoken dialect. Chinese is the written language.

Even so, over a billion people seem to get by speaking some dialect of Chinese; clearly my ignorance of the language is no barrier to their communication!

Re:Compiler for Perl? (0, Redundant)

Eric Smith (4379) | more than 5 years ago | (#27249163)

I wrote a two-pass cross-assembler in Perl some years back, but I still can't make heads or tails of most Perl code I see. It seems like a write-only language to me.

Re:Compiler for Perl? (1)

mevets (322601) | more than 5 years ago | (#27250871)

seems like? What exactly do they have to do it to get you to drop the 'seems like'? I'm pretty sure they can't think of anything else to do to it. Maybe behave like perl(n) where n is current stardate div larrywalls_birthday mod 6?

Re:Compiler for Perl? (1)

Phroggy (441) | more than 5 years ago | (#27248855)

Perl is very difficult to read if you don't know Perl, by which I mean all of Perl. It's a very complex language with tons of operators and quirky syntax, which means if you encounter something you're not familiar with, you can't look it up in a reference, because you don't even know what you're looking for.

Typically, most people don't learn they entire language; they learn a subset of the language that allows them to do what they need to do. That's fine, and you should be able to read your own programs without any trouble, but since the subset of the language you learned isn't the same as the subset of the language some other guy learned, you won't be able to read his code, and he won't be able to read yours.

Once you've advanced to the point of learning the entire language and can wrap your brain around all of the syntax, only then does reading other people's code become feasible.

And then, of course, there's deliberate obfuscation.

#!/usr/bin/perl

use strict;
use warnings;

my $q='XyLEoNgGmGjkrhPrrJtctlhe,auesenaoOmCnEfc';
for(sort split''=>substr$q,11,22,'Kfkz'){my$d=ord
substr$q,0,1,'';print"\e[".(ord uc chr $d^64).chr
(($d&32)/32+67)if($d<122);print}print"\n"#phroggy

Re:Compiler for Perl? (3, Interesting)

Onymous Coward (97719) | more than 5 years ago | (#27252343)

Perl is very difficult to read if you don't know Perl, by which I mean all of Perl.

Rather...

Perl is very difficult to read if you don't know Perl, by which I mean as much of Perl as the guy who wrote the program used.

But, yeah, I'm with you. The basic idea is that you can't read Perl if you're not literate. At least to the degree of the author of the work you're reading. So, basically, anyone who says Perl is hard to read is a bystander.

Perl can be hard to read if you don't know it. But it can be wonderfully concise if you do. That concision is valuable, so I'll take that. Even if it means having to learn the language first.

Re:Compiler for Perl? (1)

Phroggy (441) | more than 5 years ago | (#27258413)

Perl is very difficult to read if you don't know Perl, by which I mean all of Perl.

Rather...

Perl is very difficult to read if you don't know Perl, by which I mean as much of Perl as the guy who wrote the program used.

Knowing as much of Perl as the guy who wrote the program, in terms of percentage of the language, isn't enough. You have to know the same subset of Perl that the other guy used. If you know 3/4 of the language, and he knows 2/3 of the language, there is no guarantee that your 3/4 will wholly include his 2/3. To be sure that you know his 2/3 of the language, you have to learn the whole language. That was my point.

And hell yeah, Perl kicks ass. :-)

Re:Compiler for Perl? (0)

Anonymous Coward | more than 5 years ago | (#27254175)

You don't need to understand all of Perl to understand a given Perl program - you just need to understand the subset of Perl that is being used there.

And honestly, isn't the same true for any language? Myself, for example, I know C but not C++, and if you gave me a complicated C++ program with lots of templates and whatever else C++ has in terms of advanced and arcane features, I'd be at a total loss if I tried to understand it, too.

But that wouldn't mean the program is flawed - or that C++ is flawed. I know languages like PHP have made (some) people expect that they can understand (most of) any new language in a matter of minutes and think that if they can't, the language is flawed, but that simply isn't correct.

Re:Compiler for Perl? (4, Insightful)

hardburn (141468) | more than 5 years ago | (#27246173)

Perl 5 isn't really bytecode at all. It basically just walks the parse tree directly.

Perl 6/Parrot is bytecode just as those from Python or Java have come to expect. Perl 5 could be reimplemented this way, but nobody seems to want to bother.

If your goal is to obfuscate your code to prevent people from copying it, please give up [perlmonks.org] .

Re:Compiler for Perl? (1)

Goaway (82658) | more than 5 years ago | (#27246463)

Perl 5 isn't really bytecode at all. It basically just walks the parse tree directly.

Yeah, no, that's not actually true.

http://www.xav.com/perl/lib/B/Bytecode.html [xav.com]

Re:Compiler for Perl? (0)

Anonymous Coward | more than 5 years ago | (#27250253)

That's a third party library that marshals and unmarshals into a bytecode format that has nothing to do with the way Perl actually represents things internally.

Re:Compiler for Perl? (2, Informative)

hardburn (141468) | more than 5 years ago | (#27251639)

http://search.cpan.org/~nwclark/perl-5.8.9/ext/B/B/Bytecode.pm [cpan.org] :

NOTICE

There are also undocumented bugs and options.

THIS CODE IS HIGHLY EXPERIMENTAL. USE AT YOUR OWN RISK.

AUTHORS

Originally written by Malcolm Beattie and modified by Benjamin Stuhl .

Rewritten by Enache Adrian , 2003 a.d.

B::Bytecode is an experimental feature that's been largly abandoned since 2003. Perl5 is too much of a mess to make a bytecode compiler work. That's why Parrot exists.

Re:Compiler for Perl? (0)

Anonymous Coward | more than 5 years ago | (#27250713)

Dear sir,

        Respectfully, fuck off. If you want to build opaque closed systems please stay away from my languages.

Re:Is it really ready? (4, Informative)

hardburn (141468) | more than 5 years ago | (#27246003)

Version 1 is supposed to be reasonably complete and provide a consistent API for language developers.

Version 2 is intended to be the production-ready version. According to the roadmap laid out last Dec., that's due to come in another year. So far, they've stuck to the roadmap pretty well.

From the Release Announcement (0, Insightful)

Anonymous Coward | more than 5 years ago | (#27245487)

You're packing a suitcase for a place none of us has been
        A place that has to be believed to be seen
        You could have flown away
        A singing bird in an open cage
        Who will only fly, only fly for freedom...

        What you've got they can't deny it
        Can't sell it, can't buy it
        Walk on...

        -- U2, "Walk On"

Did Bono take time of from being a pompous narcisist to contribute to the project? What other reason is there for this inane drivel being reproduced in the release announcement?

At least it's text only and we were spared a blast of bland, derivative corporate rock. I stopped reading after "U2", "Walk On" -- "Fuck Off" more like!

Re:From the Release Announcement (2, Insightful)

chromatic (9471) | more than 5 years ago | (#27245833)

What other reason is there for this inane drivel being reproduced in the release announcement?

Tolkein didn't write a line of Perl 5 either, yet Larry quotes him in his release announcements. Epigraphs are long-established literary traditions.

Re:From the Release Announcement (0)

Anonymous Coward | more than 5 years ago | (#27247741)

The less you know, the more you believe.
-- Bono (on a momentary visit to reality)

Bono isn't Tolkein, he's a smarmy, insincere and egotistical corporate rock "artist". Reproducing his terrible poetry serves no purpose, neither presenting context nor inviting comparison. If epigraphs consisted of dull words to be interpreted literally, nobody would bother.

Or is the context that the parrot project (like Bono) is courting idolatry by being presented as some kind of saviour? Thats the most charitable literary comparison I can come up with.

Re:From the Release Announcement (1)

chromatic (9471) | more than 5 years ago | (#27249145)

If epigraphs consisted of dull words to be interpreted literally, nobody would bother.

Tolkein wrote some turgid prose himself.

Of course, I named my latest Parrot release after an Ed Wood movie, so we've always hewed toward the postmodern "refer to something" approach rather than trying to appease the literary critics of the world. It's a release announcement. If you want to correct bad poetry in the world, start with some of the social networking sites.

Larry said it best... (0)

Anonymous Coward | more than 5 years ago | (#27250103)

Post-Modernism was a reaction against Modernism. It came quite early to music and literature, and a little later to architecture. And I think it's still coming to computer science.
-- Larry Wall

Re:From the Release Announcement (2, Funny)

dkleinsc (563838) | more than 5 years ago | (#27246079)

When we all know the real announcement ought to have been "Brawk! Ready to sail"

Re:From the Release Announcement (2, Informative)

Henry Bone (691064) | more than 5 years ago | (#27250161)

I like those lyrics. The song's about Aung San Suu Kyi [wikipedia.org] .

She's one courageous lady and I think the song is a decent tribute.

Each to his own though.

I can't believe it! (-1, Troll)

Anonymous Coward | more than 5 years ago | (#27245565)

1.0 is finally released! Whoo hoo! Through all that hard work and determination, they made it just in time for everyone to continue ignoring it.

--
Java: New, hip, and cool
.NET: Copycat, Microsoft style
Parrot: Ooo! Ooo! Me too! Me too! Hey, wait up guys!

Re:I can't believe it! (3, Interesting)

mr_mischief (456295) | more than 5 years ago | (#27246725)

Considering the JVM is a stack machine VM for statically typed languages, .NET is a stack machine VM for statically-typed languages, and Parrot is a register machine VM built for dynamically-typed languages perhaps it's not so "me too".

Re:I can't believe it! (2, Interesting)

Anonymous Coward | more than 5 years ago | (#27247851)

The differences aren't nearly as profound as you might think. Keep in mind that when the software is translated from bytecode to native code via JIT is when the real magic happens.

Since the Java and .NET implementations are further abstracted from the underlying hardware implementation, their VMs have a lot of opportunity to optimize between the registers and the stack. They can even undo certain optimizations and realign their mappings between stack and registers. (The ability to reoptimize is why the JVM is referred to as "Hotspot". It looks carefully for "hot spots" in the code where much of the execution time is being spent, then optimizes the code according to how it has been used at runtime.)

The Parrot VM's use of registers makes it easier to map those registers to the underlying hardware, but it makes it more difficult for the JIT to decide what belongs in a register and what should be moved to stack. The bytecode may force the use of registers that end up not being ideal at runtime. Similarly, the VM may miss the opportunity to move critical stack information to registers, thereby slowing down the execution of the code. The obvious solution is to abstract away from the registers and treat them as part of the stack. From there, the JIT can treat these values holistically. And thus we end up with a solution that looks a lot like a stack-based VM.

Mod grandparent up. Mod parent down.

Re:I can't believe it! (3, Informative)

mj41 (1200515) | more than 5 years ago | (#27248417)

The Case for Virtual Register Machines [psu.edu] , Brian Davis, Andrew Beatty, Kevin Casey, David Gregg and John Waldron, 12.6.2003, PDF

Re:I can't believe it! (1, Insightful)

Anonymous Coward | more than 5 years ago | (#27249905)

The paper is a case for interpreted register virtual machines, but it only makes a passing reference to virtual machines with just-in-time compilers.

Re:I can't believe it! (1)

epine (68316) | more than 5 years ago | (#27251257)

I find that somewhat typical of beautiful theories. Everything is wonderful with stack based interpreters until someone points out that it borks the branch predictor. Good luck cooking up a telepathic branch predictor. (And you thought your original problem was hard?)

As for the JIT comment, most of the Java code I use on a daily basis (Eclipse, JIRA) suffers from extreme lurch.

Why does it take two minutes to close and reload the same Eclipse workspace? I think the network mandated virus scanner is so busy looking under the JIT compiler's skirt, it can't get anything done. Hardly a panacea.

These "Java moments" are livable, but I wouldn't discourage anyone from trying a different approach.

Re:I can't believe it! (1, Insightful)

Anonymous Coward | more than 5 years ago | (#27254239)

As for the JIT comment, most of the Java code I use on a daily basis (Eclipse, JIRA) suffers from extreme lurch.

Swapping. The Windows VMM is extremely aggressive, swapping out any memory that hasn't been accessed recently, even if that memory isn't needed by another program. Unfortunately, this plays out badly when the garbage collector comes along and tries to scan the heap. The result is a lot of thrashing.

Linux doesn't have nearly the same difficulties with Java "lurching" as Windows does, because the Linux VMM is a bit more liberal in letting memory hang around. (Though Eclipse is likely to be a bad test case. The SWT framework isn't as optimized on Linux as it is on Windows. Try running Netbeans on both and see the difference.)

If you think about it, there's no conceivable way that slower CPU execution can lead to long, intermittent pauses of the type you describe. Poor Virtual Memory Managers, however, are an exact fit.

Windows VMM has been improperly tuned for years now. Microsoft has not recognized that modern PCs have a LOT more memory, leading to excess swapping. Vista supposedly makes an effort to fix this issue, though I have not personally tested it.

Re:I can't believe it! (1)

popeyethesailor (325796) | more than 5 years ago | (#27252481)

Interestingly, Opera's new ECMAscript engine has a register-based byte-code instruction set.

http://my.opera.com/core/blog/2009/02/04/carakan [opera.com]

Re:I can't believe it! (2, Informative)

AKAImBatman (238306) | more than 5 years ago | (#27254395)

That's because register-based interpreters are faster than stack-based interpreters. Generally speaking, the fewer instructions you run in a bytecode interpreter, the faster it will execute. That is the argument made in the paper posted by mj41 above.

When you throw a JIT into the mix, things change rapidly. You stop being concerned about the interpreter speed and begin worrying more about machine code optimizations. What's good for the goose may be good for the gander, but what's good for the interpreter is not always good for the JIT.

Interestingly, there is only one Javascript JIT in wide distribution at the moment. That is Chrome's V8. Tamarin is also used in Flash 9 & 10 and is expected in future versions of Firefox.

Unfortunately, JITs are much more resource intensive to develop and maintain than interpreters. Thus a small company like Opera isn't going to make a JIT their first priority. A fast interpreter makes a lot more sense from their perspective. Especially when the Javascript engine spends the vast majority of its time in native APIs.

Re:I can't believe it! (1)

chromatic (9471) | more than 5 years ago | (#27258255)

What's good for the goose may be good for the gander, but what's good for the interpreter is not always good for the JIT.

That doesn't mean a register machine is any worse than a stack machine for JITting. In particular, some of the Dis papers from the Plan 9 research suggest that avoiding unnecessary memory access can improve execution speed as well. The approach they suggest there is clever register allocation with a register-based machine. For example, if you inline function calls, the JIT can reallocate the registers so there's no overhead of even passing parameters and receiving arguments.

yeah right (-1, Troll)

Anonymous Coward | more than 5 years ago | (#27245597)

Parrot is a twinkle in Larry Wall's eye and you know it.

Perl 6 reference implementation (1)

oldhack (1037484) | more than 5 years ago | (#27245657)

So there is a spec for Perl 6? Now there is something novel from Perl camp.

Re:Perl 6 reference implementation (3, Insightful)

outZider (165286) | more than 5 years ago | (#27245681)

Surprisingly. The idea is to do a full language specification, so there can be many implementations of a language, similar to how Java (theoretically) works. This is also why there is an absolutely huge, yet incomplete, test suite. More tests are passing weekly, but more tests are being generated weekly.

1.0 is for a stable API (4, Informative)

tcsh(1) (683224) | more than 5 years ago | (#27245669)

Remember that their plans for the 1.0 release was for a stable API for language implementors, not highly optimized performance.

VM question (3, Interesting)

benjfowler (239527) | more than 5 years ago | (#27245755)

Question from somebody who's done some compiler work with VMs but not Parrot...

What does Parrot do that other VMs can't (e.g. the .NET dynamic language runtime on the CLR, or the JVM?)

Without knowing better, it seems like a lot of duplicated effort to me...

Re:VM question (5, Informative)

outZider (165286) | more than 5 years ago | (#27245819)

I'm not very good with thedetailed explanation, as I am not a Parrot developer, but Parrot's VM is geared toward dynamically typed languages like Perl, Python, Ruby, and PHP. The JVM and CLR are geared toward static typed languages, which is why dynamic language ports to the CLR generally require code changes and cleanup to work properly under those environments.

Parrot gives all the benefits of a virtual machine to the dynamic side of the language aisle, while being incredibly easy to extend and build on, and is open source from the start.

Re:VM question (2, Insightful)

VGPowerlord (621254) | more than 5 years ago | (#27246245)

I'm not very good with thedetailed explanation, as I am not a Parrot developer, but Parrot's VM is geared toward dynamically typed languages like Perl, Python, Ruby, and PHP. The JVM and CLR are geared toward static typed languages, which is why dynamic language ports to the CLR generally require code changes and cleanup to work properly under those environments.

[Citation needed]

So, any Jython/IronPython or JRuby/IronRuby people around to share their insights?

Re:VM question (1)

outZider (165286) | more than 5 years ago | (#27246335)

Big citation needed. I don't know enough about them for it to be completely accurate on code modification, and it's likely a lot has changed since I last looked, so I'm prepared to admit I'm totally wrong. All I do know is that Parrot is tailored to dynamic languages.

Re:VM question (1)

ChunderDownunder (709234) | more than 5 years ago | (#27249569)

I fall into neither of those python/ruby groups you mention... My understanding is that they've had to perform some magic behind the scenes with class loaders and reflection etc to obtain reasonable performance. Sun's hotspot vm doesn't support tail-recursion, so lisp dialect clojure has had to add language keywords to simulate it.

Sun have made some progress in this area by hiring some of the jruby developers, introducing new bytecodes [jcp.org] and prototyping a new language independent vm [java.net] .

Re:VM question (0)

Anonymous Coward | more than 5 years ago | (#27252161)

Pynie? more like Py-not:

Pynie: a Python compiler for Parrot.
>>> def f(): pass
>>>
>>> f()

ok, that worked...

>>> def f(x):
syntax_error at line 1, near "def f(x):\n"
>>> def f(x):
syntax_error at line 1, near "def f(x):\n"

uhh, yeah, that's nothing like how Python works at the command line... I can't define functions?

>>> 1+2

uhh, ok, let's not actually be useful and print the result.

>>> print 1+2
3

there we go, now we're getting something that's working.

>>> import sys
No result object

uh-oh, import sys doesn't work?

>>> dir()
>>> print dir()
Null PMC access in get_string()

ok, I was expecting something here...

>>> locals()
>>> print locals()
Null PMC access in get_string()

and here...

>>> print globals()
Null PMC access in get_string()

and here...

>>> for i in xrange(40): pass
too few arguments passed (1) - 3 params expected

ok, so I can't do a simple loop w/ an xrange.

>>> for i in range(40): pass
>>>

Oh, cool, I can do useless loops with range. Let's expand on that:

>>> for i in range(40):
syntax_error at line 1, near "for i in r"

Oh, no multi-line statements again.

Ok, let's see how it preforms, let's run pystone, the simplest Python benchmark:

No result object
current instr.: 'pynie;PCT;Grammar;item' pc 86 (src\PCT\Grammar.pir:87)
called from Sub 'pynie;Pynie;Grammar;Actions;stringliteral' pc 106182 (src/gen_actions.pir:4249)
called from Sub 'pynie;Pynie;Grammar;stringliteral' pc 65316 (src/gen_grammar.pir:24667)
called from Sub 'pynie;Pynie;Grammar;literal' pc 62423 (src/gen_grammar.pir:23499)
called from Sub 'pynie;Pynie;Grammar;atom' pc 79972 (src/gen_grammar.pir:30259)
called from Sub 'pynie;Pynie;Grammar;primary' pc 77604 (src/gen_grammar.pir:29390)
called from Sub 'pynie;PGE;OPTable;parse' pc 1995 (compilers/pge/PGE/OPTable.pir:566)
called from Sub 'pynie;Pynie;Grammar;is_test' pc 92325 (src/gen_grammar.pir:34896)
called from Sub 'pynie;Pynie;Grammar;in_test' pc 91282 (src/gen_grammar.pir:34501)
called from Sub 'pynie;Pynie;Grammar;not_test' pc 90880 (src/gen_grammar.pir:34347)
called from Sub 'pynie;Pynie;Grammar;and_test' pc 89781 (src/gen_grammar.pir:33934)
called from Sub 'pynie;Pynie;Grammar;or_test' pc 88926 (src/gen_grammar.pir:33616)
called from Sub 'pynie;Pynie;Grammar;expression' pc 87449 (src/gen_grammar.pir:33070)
called from Sub 'pynie;Pynie;Grammar;expression_list' pc 67291 (src/gen_grammar.pir:25508)
called from Sub 'pynie;Pynie;Grammar;expression_stmt' pc 35202 (src/gen_grammar.pir:13186)
called from Sub 'pynie;Pynie;Grammar;simple_stmt' pc 33932 (src/gen_grammar.pir:12744)
called from Sub 'pynie;Pynie;Grammar;stmt_list' pc 3753 (src/gen_grammar.pir:1391)
called from Sub 'pynie;Pynie;Grammar;statement' pc 3480 (src/gen_grammar.pir:1285)
called from Sub 'pynie;Pynie;Grammar;file_input' pc 1685 (src/gen_grammar.pir:603)
called from Sub 'pynie;Pynie;Grammar;TOP' pc 536 (src/gen_grammar.pir:118)
called from Sub 'pynie;PCT;HLLCompiler;parse' pc 665 (src\PCT\HLLCompiler.pir:400)
called from Sub 'pynie;PCT;HLLCompiler;compile' pc 428 (src\PCT\HLLCompiler.pir:301)
called from Sub 'pynie;PCT;HLLCompiler;eval' pc 920 (src\PCT\HLLCompiler.pir:519)
called from Sub 'pynie;PCT;HLLCompiler;evalfiles' pc 1275 (src\PCT\HLLCompiler.pir:688)
called from Sub 'pynie;PCT;HLLCompiler;command_line' pc 1470 (src\PCT\HLLCompiler.pir:789)

This is Python?

Re:VM question (0)

Anonymous Coward | more than 5 years ago | (#27246927)

Java 7 introduces a new bytecode (InvokeDynamic) to improve support for dynamic languages on the JVM. It will be interesting to watch the situation develop, hopefully parrot will bring increased competition.

Re:VM question (1)

master_p (608214) | more than 5 years ago | (#27252861)

So, the only real difference between JVM and Parrot is dynamic dispatch? it certainly sounds like work duplication to me.

The JVM bytecode spec defines a Turing-complete machine. Why isn't dynamic dispatch implemented in it?

Everyone nowadays has a VM...

Re:VM question (3, Informative)

bernh (1122565) | more than 5 years ago | (#27245893)

Note that .NET and JVM have been built with a focus on static languages like C# and Java. As far as I know Parrot is a register based virtual machine and should be especially suited for _dynamic_ languages like Perl, Python, Ruby, ... Time will tell if the theoretic advantages here will result in a better real-world performance as the other VMs.

Re:VM question (1)

Trepidity (597) | more than 5 years ago | (#27249435)

One interesting feature of the competition is that .NET and JVM are also looking to make themselves more friendly to dynamic languages, so it's not a totally stationary target. The most promising seems to be the proposal to add an "invokedynamic" bytecode [jcp.org] to the JVM, which would allow [headius.com] a bunch of stuff dynamic languages do to be handled by the JVM (instead of them having to build their own dispatch mechanisms on top of it).

Re:VM question (1)

Randle_Revar (229304) | more than 5 years ago | (#27245901)

I don't know about better, but Parrot is different from the jvm and clr, in that it is register-based, rather than stack-based. And of course Parrot is Open Source. The clr is not and jvm was not at the time parrot was started.

Mono (1)

tepples (727027) | more than 5 years ago | (#27247693)

And of course Parrot is Open Source. The clr is not and jvm was not at the time parrot was started.

This CLR is free software [mono-project.com] , but then it wasn't released until 2004.

Re:VM question (0)

Anonymous Coward | more than 5 years ago | (#27245905)

What does Parrot do that other VMs can't

Magic Cookies.

Re:VM question (0)

Anonymous Coward | more than 5 years ago | (#27245967)

For one thing, it's a genuine open-source project. The design and specification are controlled by the community, not by Microsoft or Sun.

For another, it's tailored to the needs of dynamically-typed languages. The JVM sucks for this, while Microsoft's DLR is of little interest because it's Windows-only and probably patented up to its eyeballs (unlike the CLR, it's not an open standard).

On a technical level, Parrot is interesting because it uses registers (like a real-life processor), where most other VMs are wholly stack-based. In theory this may make it faster; in practice it's probably just a curiosity, given how much money Sun and Microsoft have invested in optimising their offerings.

Re:VM question (0)

Anonymous Coward | more than 5 years ago | (#27246179)

How about comparing it to other open source frameworks like LLVM and C--?

Re:VM question (2, Informative)

mr_mischief (456295) | more than 5 years ago | (#27247075)

Parrot is at a higher level than LLVM. Parrot deals with things like multiple dispatch, garbage collection, closures, and more at the virtual machine level. LLVM is meant to be an efficient way to target a real machine in the back end of a compiler that supports optimization and JIT.

Parrot could actually target LLVM as a backend. There have actually been tests showing that Parrot compiles under llvm-gcc. Something has to be the front end for any compiler or virtual machine, and Parrot is that. The back end will need to be tweaked for different targets anyway, and LLVM may well be one of those.

Re:VM question (4, Informative)

mj41 (1200515) | more than 5 years ago | (#27247783)

chromatic said on reddit.com: [reddit.com]

"It's not so much that the CLR's limitations prevent it from running dynamic languages but that the CLR's limitations require you to invent a lot of your own infrastructure to run dynamic languages. If the CLR in itself assumes that it can resolve all method dispatches (or jump targets or attribute accesses) statically at compile time, you have to invent your own dynamicity atop that. If the CLR does not support first class functions, you have to invent your own approach. If the CLR does not support first-class continuations, you have to invent your own calling structure. Ditto named parameters, optional parameters, default parameters, and whatever other features that the CLR doesn't support.

I'm not saying that the CLR doesn't support all of those features -- I know that it does support some of them, to some degree. The DLR supports more. The question is whether Turing equivalence (and I hate this argument) is sufficient, or whether you're better off not inventing your own method dispatch system."

Re:VM question (2, Informative)

RAMMS+EIN (578166) | more than 5 years ago | (#27249559)

Personally, I believe they are all doing it wrong, and all in the same way. They all assume things about the programming languages that will target the VM, and build the VM to support the constructs they've assumed the language will use.

I am much more in favor of a language-agostic approach. In my own TurboVM [sourceforge.net] , I have instead chosen to implement a simple, RISC-like instruction set, reasoning that this would allow the same techniques that are used to implement existing languages on real hardware to be used to implement languages on TurboVM. No need to work around the fact that you get objects and methods, garbage collection, dynamic typing, etc. when you don't want them - TurboVM gives what a real machine would give you, without any bias towards specific programming languages.

Re:VM question (1, Insightful)

Anonymous Coward | more than 5 years ago | (#27249753)

How's TurboVM different from LLVM, which I believe has the same goals?

The original Parrot was an April Fool's joke (5, Informative)

ptbarnett (159784) | more than 5 years ago | (#27246493)

The original Slashdot article from almost 8 years ago: Perl + Python = Parrot [slashdot.org] .

It included a mock press release: Perl and Python Announce Joint Development [perl.org] .

And a joint "interview" of Larry and Guido [perl.com] .

O'Reilly Media even tossed in a bogus book announcement: Programming Parrot in a Nutshell [oreilly.com] .

A few days later, O'Reilly published The Story Behind the Parrot Prank [oreilly.com] .

The name was eventually adopted by this project.

Re:The original Parrot was an April Fool's joke (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#27247277)

Joke's on them because Perl is now considered a legacy language and nobody cares about parrot.

Re:The original Parrot was an April Fool's joke (0)

Anonymous Coward | more than 5 years ago | (#27248111)

Perl is now considered a legacy language

Considered by whom?

Re:The original Parrot was an April Fool's joke (1)

outZider (165286) | more than 5 years ago | (#27248243)

The same douchebags that think PHP is enterprise.

Re:The original Parrot was an April Fool's joke (0)

Anonymous Coward | more than 5 years ago | (#27248837)

Well people in the real world tend to use PHP, yes. Not sure what other point you were trying to make?

Re:The original Parrot was an April Fool's joke (0)

Anonymous Coward | more than 5 years ago | (#27249721)

The biggest douchebags are the ones who think 'enterprise' means anything.

Re:The original Parrot was an April Fool's joke (1)

DuckDodgers (541817) | more than 5 years ago | (#27250655)

www.indeed.com is a search engine to look through several different job sites. They have 18,000 Perl developer openings listed.

The language is far from dead.

Re:The original Parrot was an April Fool's joke (1)

mj41 (1200515) | more than 5 years ago | (#27247925)

See Perl 6 and Parrot links [perl6.cz] - chronological catalogue of more than 500 links. Full Parrot and Perl 6 related history.

The lesson from this (0)

Anonymous Coward | more than 5 years ago | (#27246779)

Be very careful with your April Fool's jokes. They may someday become reality.

Re:The lesson from this (1)

Randle_Revar (229304) | more than 5 years ago | (#27247273)

Hopefully next up: Google moon base

Benchmarks (1)

FunkyELF (609131) | more than 5 years ago | (#27247159)

Hurry up and get the languages that target it up on http://shootout.alioth.debian.org/ [debian.org]

Perl 6 before end of century? (1)

cruff (171569) | more than 5 years ago | (#27247995)

So, we might actually see something called Perl 6 released before the end of the century? They've only been talking about it for ever, it seems.

Re:Perl 6 before end of century? (2, Informative)

mj41 (1200515) | more than 5 years ago | (#27248133)

There is Perl 6 [rakudo.org] release each month.

Voom! (0)

Anonymous Coward | more than 5 years ago | (#27250177)

They must have pulled the nails that held it to its perch!

Congrats Parrot Team! (1)

BeforeCoffee (519489) | more than 5 years ago | (#27252115)

Tectonic shifts in computing begin with humble first steps like this. I know it was years worth of work, and you had to suffer lots of naysayers along the way. So, great job, and I hope to see less humble moves as we go forward.

Cheers,
Dave

Parrot development goals for each major release (1)

Cochonou (576531) | more than 5 years ago | (#27252353)

The next goals are outlined here [parrot.org] .
Basically, they target one major release every six months, bumping each time the version number by 0.5. The next focus are:
1.5: integration, interoperation, and embedding
2.0: production users
2.5: portability
3.0: independence from other languages (everything is parrot on parrot)

Dr Sbaitso ? (1)

freaker_TuC (7632) | more than 5 years ago | (#27252965)

Dr Sbaitso [wikipedia.org] , are you back?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?