Parrot 2.10.0 Pesquet's released!
On behalf of the Parrot team, I'm proud to announce Parrot 2.10.0 Pesquet's. Parrot is a virtual machine aimed at running all dynamic languages. Parrot 2.10.0 is available on Parrot's FTP site (ftp://ftp.parrot.org/pub/parrot/releases/devel/2.10.0/), or follow the download instructions at http://parrot.org/download. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Git on our source code repository/a to get the latest and best Parrot code. SHA digests for this release are: 159249a3a6025677353c393e4878e800874a466fdc6c049a6e081876137b669a parrot-2.10.0.tar.gz 4fa2b042b14ceefc0ce56295cb8f5b6575308a8fba781668812920dfb7180442 parrot-2.10.0.tar.bz2 Parrot 2.10.0 News: - Core + We are on github now! https://github.com/parrot/parrot + Configure, build and test subsystems were made Git-aware + New parrot_config key 'osvers' which contains Operating System Version information + Updated to the latest nqp-rx + A proper exception is now thrown on IO read errors + Garbage Collector optimizations and memory leak fixes + Deprecated charset ops were removed + Configure system learned to detect IPv6 + The mk_language_shell and create_language scripts have not yet been ported to Git. - Documentation + How To Use Git to work on Parrot https://github.com/parrot/parrot/blob/master/docs/project/git_workflow.pod + Git Terminology https://github.com/parrot/parrot/blob/master/docs/project/git_terminology.pod - Platforms - Testing + Increased coverage on: String, FixedBooleanArray, PMCProxy, LexPad - Community + Macports portfile updated to 2.6.0 + A Fedora package for PL/Parrot ( postgresql-plparrot ) was created This package allows you to write stored procedures for PostgreSQL in PIR or Rakudo Perl 6 http://pl.parrot.org + Parrot Foundation is teaming up with The Perl Foundation and taking part in Google Code-In 2010. Learn about it and how to get involved here: http://trac.parrot.org/parrot/wiki/GoogleCodeIn2010Tasks http://leto.net/perl/2010/11/parrot-foundation-the-perl-foundation-google-code-in.html Thanks to all our contributors for making this possible, and our sponsors for supporting this project. Our next release is 21 December 2010. Enjoy!
Re: Lessons to learn from ithreads (was: threads?)
On Fri, Oct 15, 2010 at 10:56 AM, Tim Bunce tim.bu...@pobox.com wrote: ... Another important issue here is portability of concepts across implementations of perl6. I'd guess that starting a thread with a fresh interpreter is likely to be supportable across more implementations than starting a thread with cloned interpreter. ... Well volunteered! ;) Tim. Hi, I don't have much to offer on the topic of concurrency, but as someone who is in the process of slowly implementing a native-ish code compiler for Perl 6 (technically probably a compiler to LLVM assembly with the intention of then compiling to native code), I'd like to remind everyone that not every implementation will have an interpreter. I don't think you actually necessarily mean an interpreter here, but rather whatever structure is analogous to that which, in an interpreter, would hold the interpreter's global state. If this is the case, I think it may be helpful to state more precisely what state you think would need to be cloned or recreated between threads or processes and what would not. Also, it is important to consider how different designs will affect the complexity and performance of concurrency primitives for Perl 6 implementations (especially for more common implementation strategies), but neither interpreter nor VM appears in a quick grepping of S17. I don't think that should change. -- Tyler Curtis
Re: pattern alternation (was Re: How are ...)
On Thu, Aug 5, 2010 at 12:28 PM, Aaron Sherman a...@ajs.com wrote:
While that's a nifty special case (I'm sure it will surprise me someday, and
I'll spend a half hour debugging before I remember this mail), it doesn't
help in the general case (see my example grammar, below).
In the general case, no. In the case of your grammar, and all
grammars, it does help.
All regex routines, when called standalone, are anchored to the
beginning and end of the string. So, having ^ and $ at the
beginning and end of your TOP is a no-op unless some other rule calls
it as a subrule.
S05 says: In general, the anchoring of any subrule call is controlled
by its calling context. When a regex, token, or rule method is called
as a subrule, the front is anchored to the current position (as with
:p), while the end is not anchored, since the calling context will
likely wish to continue parsing. However, when such a method is
smartmatched directly, it is automatically anchored on both ends to
the beginning and end of the string. and that The basic rule of
thumb is that the keyword-defined methods never do implicit .*?-like
scanning, while the m// and s// quotelike forms do such scanning in
the absence of explicit anchoring.
Given that the Grammar.parse is specified to create a new Grammar
object and directly match its TOP(or the value of the :rule adverb)
method, without any specification that it does implicit .*? like
scanning, I think that Grammar.parse should always anchor. This
doesn't appear to work quite properly in Rakudo currently. It anchors
to the beginning but not to the end. I'm about to check if there's a
rakudobug for this already, and submit it if not.
After doing some more thinking and comparing this to other languages
(python, for example has match which matches only at the start of a
string), it seems to me that there is a sort of out-of-band need to have a
more general solution at match time. Here's my second pass suggestion:
m:r / m:rooted -- Match is rooted on both ends (^...$)
m:rs / m:rootedstart - Match is rooted at the start of string (^, ala
Python re.match)
m:re / m:rootedend - Match is rooted at the end of string ($)
m:rn / m:rootednone - Match is not rooted (default)
m:o / m:oneline - Modify :r and friends to use ^^/$$
Here's one way I can see that being routinely used:
# Simplistic shell scripts
rule TOP :r {stmt*} # Match the whole script
rule stmt :r :o { cmd arg* } # One statement per line
:oneline or similar might be useful. I'm not sure about :rootedend and
:rootedstart. :rooted is useful only in one situation: when implicitly
matching against the topic. You could do m:r/ foo /; to match
against the topic, but regex { foo }; would not do what you want (I
think). I don't know if doing an anchored match against the topic is
really important enough to justify an adverb just so you don't have to
do $_ ~~ regex { foo }.
The other way to go about that would be with parameterized adverbs. I'm not
sure how comfy people are with those, but they're in the spec. So this:
m:r / m:rooted -- Match is rooted (default is ^...$)
Parameters:
:s / :start -- Match is rooted only at start (^)
:e / :end -- Match is rooted only at end ($)
[note: :s :e should produce a warning]
:n / :none -- Match is not rooted (null modifier)
[note: combining :n with :s or :e should warn]
:o / :oneline -- Use ^^ and $$ instead of ^ and $
[note: combining :o with :n should warn?]
So our statement matching grammar becomes:
rule TOP :r {stmt*}
rule stmt :r(:o) { cmd arg* }
The clown nose is just a side benefit ;-)
Seriously, though, I prefer :r(:o) because :r:o looks like it should be the
opposite of :rw (there is no :ro, as far as I know).
PS: I see no reason that any of this is needed for 6.0.0
--
Aaron Sherman
Email or GTalk: a...@ajs.com
http://www.ajs.com/~ajs
--
Tyler Curtis
