Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Ask The Parrot 25 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • Supported Platforms (Score:4, Interesting)

    by chbarr (1337) <chbarr@rocketmail.com> on 2002.04.29 14:30 (#7697) Homepage
    Which platforms will Parrot support? Specifically, will there be a port of Parrot (and, in turn, hopefully Perl 6) to PalmOS?

  • Other languages (Score:3, Interesting)

    by Ovid (2709) on 2002.04.29 14:38 (#7698) Homepage Journal

    I'm excited as heck about Perl6. I can't wait to start taking advantage of coroutines, continuations, and hyper-operators. Since Parrot is being built largely with Perl6 in mind, this suggests that Parrot will have a flexibility that few other languages can touch. While much of the Perl community seems excited about this, I can't help but wonder about non-Perl communities? We'd like to see other languages such as Python or Java use the Parrot VM, but do their communities see any benefit to using Parrot?

    Rephrased: we're inviting other people to the party. Do they want to come?

    • I think you'll see Ruby and Python jump on for the performance increase if nothing else.

    • From what I've heard there are a lot of other Ruby people who see benefits to using Parrot. The ones who don't already will quickly be won over by the improved speed and flexibility. I'm sure a lot of these people will also contribute to the project. I see it as a start of a beautiful friendship :).

      Rephrased: If you build it, they will come.

    • I think Python will be on in no time. Python has a thing for multiple implementations. I think that as the tension between the two settles down then Parrot is coming at just the right time. My guess is that there'll be a Parrot based implementation in no time, and then some clever fellow will get Python and Perl to talk . . . and I will hug them tightly. :)

      • Python and Perl already talk: zope-perl [zope.org]. Even though it looks like this is Zope specific, you can use the underlying pyperl [cpan.org] module from any Python program. The only restriction is that your main program must be in Python.

  • mod_perl (Score:2, Interesting)

    by ChrisDolan (2855)
    How well suited will Parrot be as a mod_perl replacement? Will there be any features that will make Parrot better than mod_perl (other than Perl 6 support)?

  • Is it a BEEFY Parrot? (Score:3, Insightful)

    by erikharrison (2764) on 2002.04.29 18:22 (#7711)
    I realize that some of this is dependent on Perl 6 design, but what kind of performance increase is there, potentially. Is there in fact, a performance boost, or is Parrot really a maintainabilty/feature choice?
  • What functionality do you expect to deliver in a Parrot 1.0 release? Is it just Perl 6.0 support (with other languages supported or unsupported as the case may be) or are things like JVM/CLR support considered must-have?

    I know with predominantly volunteer efforts timeframes are notoriously difficult, but is there a date by which you _hope_ to have parrot-based systems (with 1.0 features above) in production?

  • Parrot Inspirations (Score:4, Interesting)

    by johnseq (1046) on 2002.04.29 18:41 (#7714) Journal
    Was there particular virtual machine prior art that played a major role inspiring Parrot's design?

    If I was interested in learning more about the philosophy behind the Parrot VM are there any specific projects/languages/papers you could point me to (that weren't necessarily about Parrot)?
  • Is Parrot the place and will it...

    - implement Copy-on-write strings?

    - implement smart strings? IE using a tree structure for appends, insertions, etc.

    - lazy arrays ala (0..Inf)?

  • Release date (Score:4, Interesting)

    by bdumm (3090) on 2002.04.29 23:15 (#7719)
    When is this bird going to fly?

    • A corollary to this question: What are the plans to coordinate the Parrot release with the Perl 6 release? Will Parrot 1.0 coincide with Perl 6.0, or are there sub-milestones that you'll be trying to synchronize to? Or will the timelines be essentially independent of each other?

  • Documentation (Score:3, Insightful)

    by 2shortplanks (968) on 2002.04.30 4:37 (#7727) Homepage Journal
    How do you feel about the level of documentation and commenting in the current project?

    Do you feel that someone wanting to use Parrot for their own ends could just pick up and work, or do you think that they'd have a big learning curve first?

  • persistence (Score:2, Interesting)

    by mtk (3091)
    josh pritikin integrated ObjectStore into perl. and while ObjectStore is problematic (pointer swizzling on the back of SEGV's), the goal is golden: simple, transparent persistence for perl runtime data. i'm not talking about DBFile and friends. i'm talking about storing arbitrary graphs of data (e.g. a hash whose values are hash references), perhaps under a transaction. i'm not asking if parrot will implement something like this. i just want to know that the developers have thought about the issue. i'
  • Have you an idea about the implementation of the "official" p52p6 translator ? OK, that's not really parrot-related. Just to know how you feel about this.

  • Will Parrot support timely, well-ordered destructors? Perl's reference counting provides this but such appears to be impossible with "modern garbage collection".

    "Well-ordered" means that if $x references (depends on) $y (and there is no circular dependence), then $x's destructor will fire before $y's.

    "Timely" means that destructors fire quite quickly so that they can free related resources for reuse.

    For example, an easy and powerful technique is to construct a "lock" object that automatically rel

  • I have heard that perl has fast regular expressions in part because the code has good locality for both data and instructions, which keeps them inside of the processor cache.

    I have heard that the previous perl regex engine beautification attempts were abandoned due to speed problems. Is parrot going to preserve the speed-is-more-important-than-beautiful-code philosophy?

    --
    It should work perfectly the first time! - toma
  • Hello. I'm really looking forward for the final parrot. Of course, like everyone else, I would like to know, when it will be finished. But my 2 "real" questions: One of the major benefits of parrot (for me) will be the possibility, to give my software to customers without the source. Will it be possible, to run software developed in perl on a foreign computer, without first installing perl? Will there be a port to Windows Computers (i assume)? I have no knowledge about internals like "register based machi

  • So Perl6 is going to be a compiler for Parrot. And being a regular compiler, rather than the just-in-time dynamic sort Perl5 has, one would tend to think that compiler performance will be a bit less important; compile once, run repeatedly. And rumor even has it that Perl6 will be designed in such a fashion that non-Damians will be able to parse it.

    So what are our prospects for a Perl compiler written in Perl?

    At a glance, from a distance, by a layman, it seems like you could do a pretty r

  • I understand that Parrot is to run Perl 6 primarily and that those hacking on it are all Perl Hackers (tm). But do you feel that the level to which Parrot, at least the assembler, is too much in the Perlish idiom? Are you afraid that you might scare off other languages? (And if you are, then why did you do it? What made it worth the sacrifice?)
    -Erik
  • I know that Perl 5 has had a chequered history with embracing the subject of threads. What of the Parrot? In particular, this could be important to the future take-up, as Parrot aims to be a common bytecode for several languages including Java.

    Also, can Parrot be run in a multi-CPU environment (SMP), and is there provision for instruction interlocks or spinlocks across the configuration?

  • I'd like to expand greatly upon these questions, but I'm rushed for time; the questions are being collected now.

    What are the plans for safe, sandboxed code in Parrot? It would be nice to be able to run untrusted code. It would be nicer still if the Parrot could cooperate with browsers in this capacity... we might have language-independant browser scripting, rather than being locked into JavaScript or the like.

    It would be most interesting if the Parrot found its way into, say, the Linux

    • Sandbox...

      I really would like to hear a good answer to this - it was the question I was going to ask. More specifically, the JVM has proved to be a particularly secure piece of software (yes there have been security bugs, but not nearly as many as other products with such a large market reach). We really need to study carefully how they've implemented sandboxing in the JVM.

      Does someone have a task to do that, and will we be following their implementation, or at least copying what's good about it?
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.