Slashdot Mirror

Seeing as how parrot is being developed pretty much entirely by Perl developers (heck, the development is being done on the perl6-internals mailing list), I think it's unlikely that it'll ever be adopted by the Python community.

Does Parrot even support real type systems, or does it only support Perl's broken "scalars are scalars" type system?

• IV (integer)
• NV (floating-point)
• STRING (encoding-independent string)
• PMC (Parrot Magic Cookie)

Vtable Datatypes

The next major thing that Parrot needs to implement is PMCs; these are almost like Perl 5's SVs, only more so. A PMC is an object of some type, which can be instructed to perform various operations. So when we say

inc P1

to increment the value in PMC register 1, the increment method is called on the PMC - and it's up to the PMC how it handles that method.

PMCs are how we plan to make Parrot language-independent - a Perl PMC would have different behavior from a Python PMC or a Tcl PMC. The individual methods are function pointers held in a structure called a vtable, and each PMC has a pointer to the vtable which implements the methods of its "class." Hence a Perl interpreter would link in a library full of Perl-like classes and its PMCs would have Perl-like behavior.

[ read more ]

• Apocalypse 2
  • Built-in Data Types
  • Variables
  • Properties
• Exegesis 2

• Apocalype 1
• Apocalypse 2
• Exegesis 2
• Apocalypse 3
• Exegesis 3
• Apocalypse 4

• perl6-language at perl.org
• perl6-internals at perl.org

Seeing as how parrot is being developed pretty much entirely by Perl developers (heck, the development is being done on the perl6-internals mailing list), I think it's unlikely that it'll ever be adopted by the Python community.

Does Parrot even support real type systems, or does it only support Perl's broken "scalars are scalars" type system?

• IV (integer)
• NV (floating-point)
• STRING (encoding-independent string)
• PMC (Parrot Magic Cookie)

Vtable Datatypes

The next major thing that Parrot needs to implement is PMCs; these are almost like Perl 5's SVs, only more so. A PMC is an object of some type, which can be instructed to perform various operations. So when we say

inc P1

to increment the value in PMC register 1, the increment method is called on the PMC - and it's up to the PMC how it handles that method.

PMCs are how we plan to make Parrot language-independent - a Perl PMC would have different behavior from a Python PMC or a Tcl PMC. The individual methods are function pointers held in a structure called a vtable, and each PMC has a pointer to the vtable which implements the methods of its "class." Hence a Perl interpreter would link in a library full of Perl-like classes and its PMCs would have Perl-like behavior.

[ read more ]

• Apocalypse 2
  • Built-in Data Types
  • Variables
  • Properties
• Exegesis 2

• Apocalype 1
• Apocalypse 2
• Exegesis 2
• Apocalypse 3
• Exegesis 3
• Apocalypse 4

• perl6-language at perl.org
• perl6-internals at perl.org

Seeing as how parrot is being developed pretty much entirely by Perl developers (heck, the development is being done on the perl6-internals mailing list), I think it's unlikely that it'll ever be adopted by the Python community.

Does Parrot even support real type systems, or does it only support Perl's broken "scalars are scalars" type system?

• IV (integer)
• NV (floating-point)
• STRING (encoding-independent string)
• PMC (Parrot Magic Cookie)

Vtable Datatypes

The next major thing that Parrot needs to implement is PMCs; these are almost like Perl 5's SVs, only more so. A PMC is an object of some type, which can be instructed to perform various operations. So when we say

inc P1

to increment the value in PMC register 1, the increment method is called on the PMC - and it's up to the PMC how it handles that method.

PMCs are how we plan to make Parrot language-independent - a Perl PMC would have different behavior from a Python PMC or a Tcl PMC. The individual methods are function pointers held in a structure called a vtable, and each PMC has a pointer to the vtable which implements the methods of its "class." Hence a Perl interpreter would link in a library full of Perl-like classes and its PMCs would have Perl-like behavior.

[ read more ]

• Apocalypse 2
  • Built-in Data Types
  • Variables
  • Properties
• Exegesis 2

• Apocalype 1
• Apocalypse 2
• Exegesis 2
• Apocalypse 3
• Exegesis 3
• Apocalypse 4

• perl6-language at perl.org
• perl6-internals at perl.org

It's one thing to program in good style, but it's another to have the language force you to. Yes, I'm still resentful over that.

It's a well known fact, even among Perl advocates, that the vast majority of Perl code is indecipherable. It isn't impossible to write fairly clean code in Perl, but the language certainly doesn't encourage it.

Please, don't argue Perl vs. Python, it will only start pointless flame wars. Let's agree that it's just a matter of taste. Remember, There's More Than One Way To Do It. I personally prefer Perl, but it's a totally subjective opinion. Perl and Python are more or less equally powerful languages today. But what I'm really looking forward to is Parrot, i.e. the virtual machine for Perl 6 and, I hope, also for Python, Ruby, Tcl and maybe few other good languages. It's a VM and a low-level assembly language for that VM - the language, to which Perl 6 (and hopefully other high-level languages) will be compiled to (as a layer between Perl and the VM bytecode) like C is compiled to machine-specific Assembbler (between C and the machine code). See the examples of Parrot use and read Parrot: Some Assembly Required to see what it is. Also the perl6-internals at perl.org mailing list archives is a good place to start. I'd love to see Perl and Python playing nice together, thanks to Parrot. It'd be really cool if I could write a program in Perl with someone who writes his part in Python, and another one writing in Ruby. I would just use their classes and objects, they would just use mine as well, without worrying about the language of our implementation. Parrot can be the answer here. Would it be the end of language flame wars? I do hope so.

Read Larry's Apocalypses -- 1, 2, 3 and 4 -- to see what I mean.

Read Larry's Apocalypses -- 1, 2, 3 and 4 -- to see what I mean.

Read Larry's Apocalypses -- 1, 2, 3 and 4 -- to see what I mean.

Read Larry's Apocalypses -- 1, 2, 3 and 4 -- to see what I mean.

A couple other languages/environments you may wish to look at are:

• Delphi 6/Kylix (Object Pascal)
• Perl 5 with ActiveState's IDE

I don't have much experience with Delphi 6/Kylix or Object Pascal, but Perl 5 will handle most of your requirements.

Personally, I would go back to your boss and ask why he needs all these features. The list of requirements sounds more like a buzzword-compliant list of programming language features that a typical PHB would come up with than a real requirements list. For example, if a design document hasn't been created, it's likely that this list of requirements is bogus.

NOTE: I found Cliff's question appended to the end of this story very confusing. It's orthogonal to the original question, at best. At worst, it's going to cause two entirely separate topics of discussion which will be difficult to distinguish when reading comments.

Mail Audit Article

Exactly, and well said.

It actually impresses me that some open source leaders actually go for this kind of marketing plot.

See de Icaza's intentions to make .NET the framework for Gnome....Stallman was more than mad when he heard about it here in Brasil past week. Icaza actually believed that there was openness to the Microsoft framework, and that it could be safely used for the Gnome.

Them same situation we got here, you could adopt the JVM for any project actually, but it is closed technology nonetheless and very well masked as open and platform-neutral.

For true open source, platform independence see Perl. Be careful though, Perl is extremely biased towards non-commercial, non-arrogant, non-crashin, non-biased open-source UNICES :)!!!!

From the statement:

The CIL has one feature not found in Java though: it is byte code representation that is powerful enough to be used as a target for many languages: from C++, C, Fortran and Eiffel to Lisp and Haskell including things like Java, C#, JavaScript and Visual Basic in the mix.

Let's forget for a minute what the source of this new byte code language, or standard, is. If it truly delivers the above, that would be quite an accomplishment, and probably a good thing. Remember I said, forget about the source for a moment... :)

What I wonder is, how does for example parrot measure up against that? Parrot seems to be moving quite slowly, but I might be mistaken since I am not involved. Since it apparently is the new engine for perl 6, I'd say it must have something going behind it. :)

Anyhow, one of the things with parrot is at least said to be the possibility to compile a lot of other languages besides perl, such as python or java into parrot byte code - something that indeed would be a good thing for portability and the ease of running a little of whatever on any platform. I am not sure how deep these plans actually go, and how feasible it really is.

But parrot is where I would like to set my hopes, so can anyone tell me - do I wait in vain? Is CIL really the way to go? Or are we, in reality, simply stuck with different compilers and/or interpreters for different languages?

With regard to O'Reilly and Perl, don't forget that ORA still donates to YAS, hosts Perl.com, purchasing and publishing articles and news, and employs or partially funds people involved with Perl -- Nat Torkington, Jon Orwant, Simon Cozens (editing Perl.com). They're also paying royalties to Larry, Tom Christiansen, Tim Bunce, Randal Schwartz, Doug McEachern, Lincoln Stein, Jarkko Hietaniemi, et al.

Finally, I might point out that Perl's fine documentation is both voluminous and very close to the Camel in many spots. Some of the same people who work on Perl books (writing and editing) work on the FAQ and the included POD.

It may not be as direct a donation to Perl development as when Larry was a direct patron, but I think the company is still doing Good things. There will always be free resources for people to use, but I have no problem supporting good publishers like O'Reilly and Manning. If someone can set up a trust to produce free-as-in-speech documentation, I'll support that project too.

Virus is not a Latin word, it's an English word, and therefore follows English conventions: one virus, many viruses. It is based on the Latin 'vir' but is as English as all get out.

It's so goddamn easy, yet stupid, stuck-up computer geeks try to make themselves sound important by going around saying "virii" as if it were a Latin word.

Latin: vir, viri, a second-declension masculine noun meaning 'man'. 'viri' would mean either 'of {the,a} man' or 'the men'. 'virus', in the sense that we're talking here, is poorly-documented in the Latin at best. The Oxford English Dictionary gives its plural simply as 'viruses'. For more on this subject, check out this research into this very topic. I haven't read the entire page, but it seems to be well-documented and ready for consumption.

http://www.perl.com/language/misc/Artistic.html

See particularly clauses 5 and 8. You could look at other licenses named in the EULA as well, but this one happened to be handy....

-Carter

php also has built-in PDF editing and creation functions as well, FWIW.

LXXIV. PDF functions (PHP)

And here's the PDFlib for Perl which allows much of the same functionality (create/modify)

CPAN PDFLib

Also, last time I checked, I could still edit PDF files in Acrobat (authoring suite) or Illustrator.

I also remember programming a bit of Postscript in college as well... do PDF/PS really qualify as closed architectures?

Plural of Virus

You haven't done much (if any) research, have you? Actually, if you were half-way involved in a corporate environment that took linux seriously, you might have had a clue in the first place. So let's start building a reply:

The linux desktop is going nowhere fast, and for most of these projections to come true there would have to be a mass migration to the linux desktop which will not happen.

Debatable. But you are probably correct that there will not be a mass migration to a Linux desktop, at least in a short period of time. But you can't deny the efforts being made to push in that direction. With a few moves in the right direction I think Linux has a pretty good chance.

OEMS are stepping away from the linux desktop not towards it, so you will not be seeing "dual boots".

OEMs screwed it up all on their own. I recently ordered a Dell i8k laptop back when they were still "offerring" Linux preinstalled. If I chose Linux, Dell told me it would take 2-3 weeks to ship. However a Windows version could be shiped the next day. And do you seriously think Microsoft would let a OEM ship anything dual-booted with Windows?!?

I look back at the NT 4 domain model, and it wasn't great, but its better than anything in the linux camp.

You haven't played much with Samba, have you? Samba can completely replace NT4, Warp, and Netware services. That's the server side. On the client side there's Pam_Smb which can allow Linux to authenticate to NT/2000 domains. Red Hat 7.2 even gives you this option during install now.

And now with AD you have highly scalable enterprise ready directory services and no way to truly integrate linux.

We can argue about your definition of "truly", or I can go back to my Perl scripts that work with AD just fine.

Oh, and apocalypse? We've already had a few...

goddammit.

Hi, I currently work in the UC Davis sec lab (current project(s): HACQIT).

The basic problem with all IDS is in the confidence level of determining if something is an attack or just random garbage. Also, IDS have to be fast. If there's too much traffic (if you've been /.'d), you may not be able to check all attacks. Some methodogies start from the approach that deviating from a set of known safe operations is considered suspect. Other IDSes approach it from checking against a known-attack database. We're currently working on genetic algorithms and expert systems to correlate sensors and systems to detect and respond to attacks. The best approach I've seen is a complete kernel-level instrumentation of all system calls that's transparent and mostly undetectable. It would probably be DoS-able as well. The main prob is that you realy gotta have another comp to offload IDS checking.

Right now, nearly all IDSes are extremely primitive and consist of nothing more than snort rules and Perl scripts that call ipchains or something.

Btw, I went to RAID 2001 this year (hosted at UCD), it was fairly interesting.

I just remembered this article on www.perl.com about a guy, Jon Bjornstad, who has been doing some custom perl/Tk programming for his disabled friend, Sue.

Maybe it is too specialized in this context, but it is a very nice story, and a good example on how You can help, with your skills, with relatively small measures.

This is also the perfect example of "an itch to scratch" leading to something useful, and in this case it was even someone else's itch. :)

Here is a link to an article about a Perl project to help the disabled. It contains a link to the project's website, as well.

I use Mail::Audit and Mail::SpamAssassin in a Perl filter script now. Works great and I can add custom rules easily enough.

See link for details.

GNU already has an Artistic License. They never could resist a pun. Which is why I overlooked the link -- my aging brain confused "poetic" and artistic". And it's also why the Poetic License is less funny than it hoped to be.

The article is slashdotted, but if it's O'Reilly, then I'll bet he is talking about Perl's Artistic License.

I like csh a lot better because it's easier to configure, easier to use, and has a syntax that I like a lot better.

This reads like a troll, but it could be sincere, so I'll treat it seriously. How do you open more than two output file or more than one input file concurrently? csh has no primitives for opening and closing files beyond redirecting a single command or pipeline. Even for something as simple as redirecting stdout to one file and stderr to another, you have to jump through hoops.

I won't read back to you the famous Considered Harmful file, but the above point is probably the main reason I would never program with csh scripts. Sure, csh has some programming features Bourne shell lacks, but ksh/bash/POSIX have those same features. Opening and closing arbitrary files is something I do in my scripts all the time.

Hello, what planet are you on? The csh looks nothing like C. The syntax is clumsy and inflexible. See Csh Programming Considered Harmful.

Not only that, but csh is actually older than the bourne shell!!! It was derived from 6th Edition Unix, the bourne shell was new in 7th Edition. Talk about being slow to catch up...

Seriously, there is very little (most would say none) incentive to use csh anymore. Even in its tcsh incarnation, it's almost completely been superceded by zsh. You should check it out for your own sanity.

Should you desire, you can even turn on the god-awful insane history mechanism that all those weird-ass csh users seem to have gotten ingrained with...

Quantum::Entaglement

And who said that quantum computers a centurys away?? You can get started on your 386 right now, courtesy of CPAN!

Also, about that eliza chatbot: there is an easier way to get started (you may have seen this in this months linux journal, non?):

Anyway, next time someone complains about MS bloatware being so cheeky that they included a flight sim in a version of Excel, I shall point this out!

Readability has nothing to do with how complex a syntax is. I'd agree if you say that Perl has one of the most complex syntaxes, but I'd disagree if you say that makes it harder to read.

To give you an example, here's a small program written in Parrot assembler, which, being an assembly language, has a very simple syntax with few operators:

set I1, 0
set I2, 20
set I3, 1
set I4, 1
REDO:eqI1, I2, DONE, NEXT
NEXT:set I5, I4
add I4, I3, I4
set I3, I5
print I3
print "\n"
inc I1
branch REDO
DONE:end

Is this program easy to read? Did you find out what it does? Probably not -- it's characters might be more readable than Perl's, but it's not really readable since you don't easly understand it's meaning.

Readability is the combination of making it easy to understand what's going on in each single instruction, and making it easy to understand the algorithm. Understanding instructions is simple in Assembler (few, simple operators), but harder in Perl (what the hell does this operator do?). Understanding the algorithm is easier in Perl and harder in Assembler.

Somewhere between Assembler and human language is your personal preference and treshold for readability. For me, Perl is still readable while Assembler is often not. For others, Perl looks like a collection of junk characters.

That's ok, just don't judge the quality of a language by how it looks to you.

(BTW, the above parrot program prints the first 20 fibonacci numbers. I found it here.)

One of the coolest things about the Perl 6 development is that it leads to lots of improvements available right here, right now with Perl 5.

Attribute for example have been incorporated in perl 5.7.2, and a whole unch of new modules by Damian and others use them in tons of creative ways.

I am not sure this would have been done without the Perl 6 process. It forced the whole community to re-examine the language, take a step back and think of new ways to improve it. This would have been much more difficult if we had not had license to do it freely under the Perl 6 RFC process. This is the kind of things that keep a community alive and creative.

And BTW Perl 6 will still let you write quick'n dirty one-liners, and the first goal of the design of the interpretor is Speed (Larry mentionned "and it'has to be fast" about 25 times in 60 seconds in his last State of the Onion0.

I consider its use as a programming lanugage the mark of a rank amateur.

Don't believe me? Try this.

In fact, for me, the use of Lisp as the macro/extension language in Emacs is it's biggest weakness. I remember a particularly nice (closed-source and commercial, sigh) emacs work-alike I used back in the MS-DOS days called epsilon that used a dialect of C as its extension language - it was much easier to think in, and hack personal extensions for.

There is a project to allow use my current favorite language, Perl, to extend Emacs; and revisiting the CPAN archives for the author, I just noticed that he has abandoned the effort to directly embed perl into the executable. (Which I found off-putting, since it required a tricky combined compile of both - who has the time?) Instead, he now is working on a approach that uses pipes and soft (perl, lisp) scripting instead of embedding - mmm. I gonna download this and check it out!

Your criticism of the mail and news readers are on target - the are pretty bad, even for text-mode (I use mutt for mail, and I hardly ever use news - I surf /. instead if I am in that sort of mood). But it is absolutely fantastic for editing, especially the language modes, command-line in a buffer support (shell, telnet, SQL), ange-ftp, etc..

Geezz.. Apologies for the ramble...

If you've had a bad experience with PERL, give Perl a try!

There's been work to get similar things for the kernel, as well.

I'd personally be a little scared of testing kernel functions, but I've tested a lot of so-called "untestable" things lately. It's worth doing.

Apocalypse \A*poc"a*lypse\, n. [L. apocalypsis, Gr. ?, fr. ? to uncover, to disclose; ? from + ? to cover, conceal: cf. F. apocalypse.] 1. The revelation delivered to St. John, in the isle of Patmos, near the close of the first century, forming the last book of the New Testament. 2. Anything viewed as a revelation; a disclosure.

People get scared when they hear the word Apocalypse, but here I mean it in the good sense: a Revealing. An Apocalypse is supposed to reveal good news to good people. (And if it also happens to reveal bad news to bad people, so be it. Just don't be bad.)

Now, I even see people write "JAVA", and that's not even an acronym! Though I suppose one might infer that it's Just Another ....

Would those in attendance mind helping me by gently informing the users of this barbarism that "You sound like a freaking ignoramus!"? While I've got you, could you do the same for (stop here if you have a weak stomache and an appreciation for language) virii.

It wouldn't have sounded so important as

Pathetically
Eclectic
Rubbish
Lister

... which any REAL Perl h4xx0r knows that's what it really stands for... ;^)

...I will kick his or her ass. The proper plural for "virus" is "viruses". "Viri" and "virii" just make you look stupid. Please read this informative article for background information. Thank you.

A Perl virtual machine IS in the works. It's called Parrot. Unlike the April Fool's "Parrot", this is an actual initiative.

Idiot. Lameness filter encountered. Your comment violated the postercomment compression filter. Comment aborted

Step 1: Learn HTML
Step 2: Learn CSS (!!!)
Step 3: Learn Graphics (GIMP, Photoshop, Paintshop etc.)

Now you have basic Webdesign knowlededge and you can choose between two ways:
1. The developer way:
Step 4: Learn Perl/PHP
Step 5: Learn SQL/databases in general
Step 6: Get better in everything...
2. The desginer way:
Step 4: Learn Flash
Step 5: Get better in graphics, video design etc.
Step 6: Buy a Mac ;)

Of course, you can try doing both ways, but in fact you will become only "master" of one of them.
X

I can sympathise with this approach, because I've been put in this situation before - but its really important that you let the submittor know why the patch wasn't applied, and not just let it fall into a little black hole.

One thing that really gets me going about some OS projects, (especially early projects on Freshmeat), is that they are, needlessly, locked to one platform.

I've sent simple patches to numerous projects to allow them to work on Windows NT/2000 - and the vast majority of the time I get no reply - or a snide reply back that the project is designed for Unix.

Granted it probably was, but thats not really a good reason to turn something down that makes the project more portable - I use Linux at home, and Windows at work. That shouldn't mean I have to use two mutually exclusive sets of tools..

Thank God for Perl, and Cygwin

"Parrot" is the development name for the internals of Perl 6, notably the interpreter. See, e.g., this explanation. Any similarity to a certain April Fools joke is probably intentional, but isn't to be taken literally.

It's the code name for the Perl 6 internals, as a continuation of the Parrot joke of April Fools fame.
The Parrot Squawks

This page explains in great detail why not:

http://language.perl.com/misc/virus.html

Additional support:

http://www.dictionary.com/cgi-bin/dict.pl?term=vir us

A search on Google for "viruses" turns up 1,480,000 hits.
A search on Google for "virii" turns up 38,200 hits.

Any technical literature written by professionals will NEVER EVER USE THE WORD VIRII! IT'S NOT A REAL WORD! The plural of "virus" is "viruses"!

http://www.mcafee.com - on the FRONT PAGE the word "viruses" is printed several times. "Virii" is not.

http://www.centralcommand.com - same deal.

I'm going to keep posting this on every virus story that comes up until everyone gets the damn hint!

What do you think it would cost to get people to stop saying "virii" and start using the proper plural of "virus," which is "viruses"?

I just love these funny languages. Nobody will ever use them, but after reading this, you don't feel like programming any more. The C language looks so crude, so cryptic, so non-human friendly after that...
There's a similar project for Perl called Lingua::Romana::Perligata . This is an awesome module written by Damian Conway, that let you program in Latin. Totally crazy.

This is the molecule known to most of you as acetylene.

If we're to make this correspond to last year's picture, then this hydrogen atom on the left is named Richard, and the one on the right is named Bill. (Hmm, they seem to be circling each other. How appropriate.) [Well, they were circling in my talk, anyway.] This carbon atom on the left is all the open source folks that are trying to cooperate constructively with commercial folks, and this other carbon atom is all the commercial folks trying to cooperate with open source folks. The bond in the middle is simultaneously the strongest bond and the weakest bond. It's the strongest bond, because it's a triple bond. It's also the weakest bond, because it's a very energetic bond, and could be broken by outside forces.

But not by inside forces.

Let me be specific. Some folks in this room are extremely leery of Bill. Others are extremely leery of Richard. These people tend to be leary not only of the opposite hydrogen, but also the opposite
carbon. They are supplying the repulsive forces, because they fear the opposite extreme.

At the same time, there are lots of good people who are actively supplying the attractive forces. Nobody has enough power to crush the two carbons together. Nobody has enough power to tear them
apart. They're in a metastable state. They have tensegrity. It's my hope that the open source movement achieves this kind of tensegrity.

That being said, acetylene is flammable. If it is abused too much, it can explode. I only ever had one unanticipated explosion when I was doing chemistry in my basement, and that was when I was
generating acetylene. I was an idiot, and was generating it in a small glass jar. Don't try this at home. Fortunately, it was a very small glass jar, and I was already wearing glasses at the time. I was shaken but unhurt. I don't play with acetylene much any more, because it is rather touchy stuff. So maybe, if you're thinking about starting a war between the open source folks and the commercial folks, you should think again. First of all, you'll be fighting against a lot of good folks, and you'll probably lose. Second of all, you might win, and the world will be split up into separate atoms.

Maybe that's what the hydrogens on the end want, but the carbons in the middle would really like to stick together and make something useful.

If we try hard enough, maybe we can make open source into something stable in the middle.