Parrot 4.7.0 "Hispaniolan" Released
On behalf of the Parrot team, I'm proud to announce Parrot 4.7.0, also known as "Hispaniolan". Parrot (http://parrot.org/) is a virtual machine aimed at running all dynamic languages. Parrot 4.7.0 is available on Parrot's FTP site (ftp://ftp.parrot.org/pub/parrot/releases/devel/4.7.0/), or by following 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 to retrieve the source code to get the latest and best Parrot code. Parrot 4.7.0 News: - Core + Added .all_tags() and .all_tagged_pmcs() methods to PackfileView PMC + Several build and coding standards fixes The SHA256 message digests for the downloadable tarballs are: 4360ac3dffafffaa00bce561c1329df8ad134019f76930cf24e7a875a4422a90 parrot-4.7.0.tar.bz2 c0bffd371dea653b9881ab2cc9ae5a57dc9f531dfcda0a604ea693c9d2165619 parrot-4.7.0.tar.gz Many thanks to all our contributors for making this possible, and our sponsors for supporting this project. Our next scheduled release is 18 September 2012. The release is indeed a day late. I apologize for the unusual lateness. --Andrew Whitworth
Parrot 4.4.0 "Banana Fanna Fo Ferret" Released!
Its existence guarantees nothing in itself, and the catalytic or Promethean moment only occurs when one individual is prepared to cease being the passive listener to such a voice and to become instead is spokesman, or representative. But it's important to remember the many dreary years when the prospect of victory appeared quite unattainable. On every day of those years, the "as if" pose had to be kept up, until its cumulative effect could be felt. -- Christopher Hitchens, Letters to a Young Contrarian On behalf of the Parrot team, I'm proud to announce the 4.4.0 release of Parrot "Banana Fanna Fo Ferret". Parrot (http://parrot.org/) is a virtual machine aimed at running all dynamic languages. Parrot 4.4.0 is available on Parrot's FTP site (ftp://ftp.parrot.org/pub/parrot/releases/stable/4.4.0/), or by following 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 to retrieve the source code to get the latest and best Parrot code. Parrot 4.4.0 News: - Core + Most internal calls to libc exit(x) have been replaced with Parrot_x_* API calls or PARROT_FORCE_EXIT - Documentation + 'pdd31_hll.pod' made stable in 'docs/pdds/'. + Updated main 'README' to 'README.pod' + Updated various dependencies, e.g., 'lib/Parrot/Distribution.pm'. + Updated all 'README' files to 'README.pod' files. + Added 'README.pod' files to top-level directories. - Tests + Update various tests to pull from new 'README.pod' + Updated 't/tools/install/02-install_files.t' to pull from new 'README.pod' - Community - Platforms - Tools + pbc_merge has been fixed to deduplicate constant strings and merge annotations segments The SHA256 message digests for the downloadable tarballs are: 348ce13fc136afc74a7b50b094f64d8cb00f83f0cd3d59acc6fa4e63c824fa4d parrot-4.4.0.tar.bz2 02495c0d11d3977a615bb76d3219f12bc6543b8cf12c596dfd5c35e98d95218a parrot-4.4.0.tar.gz Alvis Yardley (or a delegate) will release Parrot 4.5.0, the next scheduled monthly release, on June 16th 2012. Subsequent release managers are to be announced. A special thanks to our donors, contributors and volunteers for making this release possible. Enjoy! --Andrew Whitworth
Parrot 4.0.0 "Hyperstasis" released!
At one extreme, it is possible to approach the subject on a high mathematical epsilon-delta level, which generally results in many undergraduate students not knowing what's going on. At the other extreme, it is possible to wave away all the subtleties until neither the student nor the teacher knows what's going on. -Stanley J. Farlow, Preface to Partial Differential Equations for Scientists and Engineers On behalf of the Parrot team, I'm proud to announce Parrot 4.0.0, also known as "Hyperstasis". Parrot (http://parrot.org/) is a virtual machine aimed at running all dynamic languages. Parrot 4.0.0 is available on Parrot's FTP site (ftp://ftp.parrot.org/pub/parrot/releases/stable/4.0.0/), or by following 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 to retrieve the source code to get the latest and best Parrot code. Parrot 4.0.0 News: - Core + Several cleanups to the interp subsystem API + Cleanups and documentation additions for green threads and timers + Iterator PMC and family now implement the "iterator" role + A bug in Parrot_ext_try was fixed where it was not popping a context correctly - Documentation + Docs for all versions of Parrot ever released are now available at http://parrot.github.com - Tests + Timer PMC tests were converted from PASM to PIR The SHA256 message digests for the downloadable tarballs are: a1e0bc3de509b247b2cea4863cc202cdceeaa329729416115d3c20a162a0dd88 parrot-4.0.0.tar.bz2 a63d45f50f7dd8ba76395cd2af14108412398ac24b8d827db369221cdb37fada parrot-4.0.0.tar.gz Many thanks to all our contributors for making this possible, and our sponsors for supporting this project. Our next scheduled release is 21 February 2012. Enjoy! --Andrew Whitworth
Re: Close($file) required in Perl 6, unlike Perl 5
On Sun, Jul 17, 2011 at 4:21 AM, Moritz Lenz wrote: > Question to the Parrot developers: How could I implement DESTROY methods > in Rakudo? Is there any vtable I can override, or so? Note that such a > method might itself allocate new GCables. While not urgent, it's > important for us in the long run. We do have the ability to override VTABLE_destroy in a C-based PMC type, but that is not exposed through Object PMC. I suspect this capability could be exposed through 6model and the Rakudo PMC infrastructure, and a Sub could be invoked from there. Because of the sensitive nature of the timing, and because this has obviously not gotten any good test coverage or developer attention, it probably won't work so well. This hasn't been a high-priority issue so far, either amonst users or developers. If people are interested in seeing this happen, failing use-cases or even tickets requesting fixes would be a great place to start. My suggestion so far would be to add in a destroy override to 6model, try to use it, and see what blows up. Then open a ticket with Parrot and we'll do our best to make it work the way you need. --Andrew Whitworth
Re: Close($file) required in Perl 6, unlike Perl 5
On Mon, Jul 18, 2011 at 10:41 AM, Peter Lobsinger wrote: > The destructor does exactly that, but is not triggered by global teardown. That seems wrong to me, we should be sweeping pools and destroying PMCs on global teardown. If we aren't doing that, it's a bug. --Andrew Whitworth
Parrot 3.3.0 "Fire in the Sky" Released!
Nor is there any embarrassment in the fact that we're ridiculous, isn't it true? For it's actually so, we are ridiculous, light-minded, with bad habits, we're bored, we don't know how to look, how to understand, we're all like that, all, you, and I, and they! Now, you're not offended when I tell you to your face that you're ridiculous? And if so, aren't you material? You know, in my opinion it's sometimes even good to be ridiculous, if not better: we can the sooner forgive each other, the sooner humble ourselves; we can't understand everything at once, we can't start right out with perfection! To achieve perfection, one must first begin by not understanding many things! And if we understand too quickly, we may not understand well. --Fyodor Dostoevsky in "The Idiot" On behalf of the Parrot team, I'm proud to announce Parrot 3.3.0, also known as "Fire in the Sky". Parrot (http://parrot.org/) is a virtual machine aimed at running all dynamic languages. Parrot 3.3.0 is available on Parrot's FTP site (ftp://ftp.parrot.org/pub/parrot/releases/supported/3.3.0/), or by following 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 to retrieve the source code to get the latest and best Parrot code. Parrot 3.3.0 News: - Core + The isa and isa_pmc vtables can now be overridden from PIR + IMCC has a new improved external interface + A new IMCCompiler PMC adds prototype PDD31-alike functionality for the PIR and PASM compilers + New --with-llvm option to Configure.pl, which will link to LLVM if it is available - Community + Parrot Virtual Machine was accepted into Google Summer of Code 2011 - Ecosystem + Rosella adds a stable "Event" library to implement a publish/subscribe mechanism - Tests + The test coverage of the extend_vtable subsystem was greatly increased The SHA256 message digests for the downloadable tarballs are: 8f474d44a0137a3fd5296c019dbccc6ae64193ff12ce799babc362567115c1ad parrot-3.3.0.tar.bz2 99b81a84bf55a69bc3bbf8bf8dd65bee1417fd1c30c7d08c6859a7a3db892b8f parrot-3.3.0.tar.gz Many thanks to all our contributors for making this possible, and our sponsors for supporting this project. Our next scheduled release is 17 May 2011. Enjoy! --Andrew Whitworth
Re: reading binary stream?
That looks like a Parrot problem, trying to force input characters to UTF8. Can you open a ticket at trac.parrot.org for it? Thanks --Andrew Whitworth On Tue, Dec 28, 2010 at 5:41 AM, Hiroki Horiuchi wrote: > Hello. > > This program > -- > #!/usr/bin/env perl6 > > use v6; > > my $h = open '/dev/urandom', :r; > loop (;;) { > $h.getc; > } > -- > spits an error below. > -- > Malformed UTF-8 string > > in 'IO::getc' at line 5457:CORE.setting > in main program body at line 7:./getc.p6 > -- > How can I fix the problem? > > Thank you. > -- > Hiroki Horiuchi > >
Parrot 2.11.0 "At The ROFLBBQ" Released
On behalf of the Parrot team, I'm proud to announce Parrot 2.11.0 "At The ROFLBBQ". Parrot (http://parrot.org/) is a virtual machine aimed at running all dynamic languages. Parrot 2.11.0 is available on Parrot's FTP site, or by following 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 to retrieve the source code to get the latest and best Parrot code. Parrot 2.11.0 News: New in 2.11.0 - Core + Just In Time native call frame generation using LibFFI + PIR op find_codepoint is no longer experimental, it is now supported + Several public functions in libparrot have been brought up to standard naming conventions. + Improved linked-list implementation in GC + set_addr opcode is being replaced with the new set_label opcode in core libraries + Removed deprecated CodeString PMC + Added close, is_closed, read, readline methods to Socket + Added experimental MappedByteArray PMC type + Added Parrot_warn_experimental, to warn the user about experimental features + Code for frontend executables moved from src/ to frontend/ + Support for chunked receive in LWP library. + Added a "quickcover" make target - Languages + PIRC - left the nest and is currently at https://github.com/parrot/pirc/ + Community - Our README was translated into the following languages by Google Code-In students and mentors: Polish README.polski Spanish README.espanol German README.deutsch - Documentation - Tests + Test coverage increase on PMCs: String, Integer, NameSpace, Complex, EventHandler + 'make quickcover' target added to speed up most essential parts of coverage analysis + 'tools/dev/headerizer.pl' refactored to improve maintainability (no change in functionality) Many thanks to all our contributors for making this possible, and our sponsors for supporting this project. Our next scheduled release is 18 January 2011. The SHA256 sum for the download tarball is: 1a62db8793a5baf727a790d9fd58415dcc9f2c0c28b44608701b39792627241c Enjoy! --Andrew Whitworth
Parrot 2.4.0 "Sulfur Crest"
"So there me was beating boulder into powder because me couldn't eat it, and magic ball land in lap. Naturally me think, "All right, free egg." because me stupid and me caveman. So me spent about three days humping and bust open with thigh bone so me could eat it good. Then magic ball shoot Oog with beam, and next thing me know me go out and invent wheel out of dinosaur brain. Magic dino wheel rolls for three short distance until me eat it. The point is, me get smarter. Soon me walk upright, me feather back dirty, matted hair into wings for style, and me stop to use bathroom as opposed to me just doing it as me walk. " -- Oog, Aqua Teen Hunger Force On behalf of the Parrot team, I'm proud to announce Parrot 2.4.0 "Sulfur Crest." Parrot (http://parrot.org/) is a virtual machine aimed at running all dynamic languages. Parrot 2.4.0 is available on Parrot's FTP site, 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 Subversion on the source code repository to get the latest and best Parrot code. Parrot 2.4.0 News: - Core + Various long-standing bugs in IMCC were fixed + STRINGs are now immutable. + use STRINGNULL instead of NULL when working with strings + Fixed storage of methods in the NameSpace PMC + Added :nsentry flag to force method to be stored in the NameSpace + Added StringBuilder and PackfileDebug PMCs + Added experimental opcodes find_codepoint and unroll - Compilers + Fixed reporting of line numbers in IMCC + Removed deprecated NQP compiler, replaced with new NQP-RX + Removed NCIGen compiler - Deprecations + Tools to distribute on CPAN were removed + Deprecated dynpmcs have been removed to external repositories + Removed RetContinuation PMC + Removed CGoto, CGP, and Switch runcores - Tests + Many tests for the extend/embed interface were added + done_testing() is now implemented in Test::More - Tools + The fakexecutable tapir is renamed parrot-prove + Performance fixes to the pbc_to_exe tool + Fix data_json to work outside of trunk + The dynpmc GzipHandle (zlib wrapper) was added + The library Archive/Tar.pir was added. + The library Archive/Zip.pir was added. + The libraries LWP.pir, HTTP/Message.pir & URI.pir were added. - Miscellaneous + Six Parrot-related projects accepted to GSoC + Improve use of const and other compiler hints Many thanks to all our contributors for making this possible, and our sponsors for supporting this project. Our next scheduled release is 15 June 2010. Enjoy! --Andrew Whitworth
Re: Methodicals: A better way to monkey type
This idea strikes me as being extremely similar to C#'s extension methods, a feature that I've found to be particularly beneficial in many cases. The fact that these methodicals are lexically-scoped is especially nice, and the fact that they can be applied post-hoc to arbitrary data items that have no prior support for them (like Parrot objects) would be very nice to have on Parrot in particular where language interoperation could be a big deal in the future. +1 --Andrew Whitworth On Wed, Apr 21, 2010 at 3:16 AM, Stefan O'Rear wrote: > (The following describes a proposed extension to Perl 6, methodical scoped > operators or methodicals for short. It is written in the present tense for > simplicity but should be understood as the future conditional.) > > Normally, when you write a method call, the definition of the method is > entirely in the domain of the receiver's class: > > $object.make-me-a-sandwich; # $object gets to decide what this means > > However, this is not always how things work. > > $object.WHAT; # Larry says that WHAT should return the protoobject > > WHAT, WHENCE, postcircumfix:<[ ]>, and similar operators have semantics > (although not implementation) defined by the language itself. Currently, Perl > 6 > fakes this by having all values inherit from Any or Mu or Cool, which define > the basic, overridable versions of these method-like operators. This cheat > actually works pretty well in a homogeneous environment, but it fails if we > have > to consider objects from outside Perl 6. > > $parrot-array.WHAT; # Method WHAT not found for invocant of type ... > > The problem here is that scopes are conflated - WHAT is defined by the > language, which is approximately a lexical scope, while methods on an object > are in some entirely different scope. > > A methodical is an operator which syntactically behaves as a method but is > subject to scoping rules. Methodicals are defined using the ordinary method > keyword, qualified with my or our. (TODO: This seems the most natural syntax > to me, but it conflicts with existing usage. Which is more worth having on > it?) Methodicals do not need to be declared in classes, but they should > generally have declared receiver types. > > { > my method make-me-a-sandwich(Num:) { ... } > > 2.make-me-a-sandwich; # calls our method > > "ham".make-me-a-sandwich; # either an error, or method dispatch > } > > 2.make-ma-a-sandwich; # ordinary method dispatch > > The primary use case for methodicals is naturally in the setting. Many of the > methods which are currently defined on lower-level types could become > methodicals and they would be available on all values, in any code compiled > within the Perl 6 setting, without polluting the referencing environments of > non-Perl 6 code in the same object environment. > > my method WHAT($thing) { ... } > > Rakudo already uses something very much like an ad-hoc direct implementation > of > methodicals to handle postcircumfix operators. > > Methodicals are also useful in user code where the most natural phrasing of a > calculation is as a property of a system type, for instance from the > Mandelbrot > Advent example: > > my method mandel(Complex:) { > my $z = 0i; > for ^$max-iterations { > $z = $z * $z + self; > return 1 if ($z.abs > 2); > } > return 0; > } > > Since methodicals do not pollute global referencing environments, and do not > compromise encapsulation, MONKEY_TYPING is not needed here. > > A methodical defined inside a class functions much like a private method. > There may be something interesting here, but I'm not entirely sure what. > > There are two natural implementations of methodicals in terms of other > language > features. First, it is possible to treat methodicals as ordinary methods > (monkey typing under the hood), but with generated names; the true name is > bound to the program name only within the correct scope. If possible, the > methods should be treated as anonymous, accessible only though an opaque name > object. Care must be taken to prevent incorrect exposure of private fields > and > methods. > > Alternatively, a methodical can be desugared to a multi sub with the same > scope > as the methodical itself, changing statically named method calls into calls to > the methodical. This gives reflection invisibility and privacy for free, but > may require more work to get the multi call semantics exactly right. > > Thoughts? > > -Stefan > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkvOpjcACgkQFBz7OZ2P+dKJ4wCfUpWUDv2/PqYUF1k0hsYaiAns > HFAAn2K5SfcJnGq5xk1PIy0QG69LMrwR > =uvrz > -END PGP SIGNATURE- > >
Parrot 1.5.0 "TEH PARROTZ!" Released!
On behalf of the Parrot team, I'm proud to announce Parrot 1.5.0 "TEH PARROTZ!." Parrot (http://parrot.org/) is a virtual machine aimed at running all dynamic languages. Parrot 1.5.0 is available on Parrot's FTP site, 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 Subversion on the source code repository to get the latest and best Parrot code. Parrot 1.5.0 News: - Core + Removed several deprecated functions and features + Removed bsr, jsr, branch_cs, and ret opcodes + Removed global stacks system + Changed OPS file format to include explicit preamble + Changed all "new 'Iterator'" instructions into 'iter' instructions + Removed Configure.pl options for specifying non-working GC cores + Removed unexecuting code as found by Coverity + Improvements to the Parrot Debugger + Added experimental fixed-size structure allocator to the GC + Added experimental lazy arena allocation to the GC + Removed the defunct PASM1 compiler object + Refactored hashes, keys, and iterators + Added "corevm" make target to build Parrot without all the supporting libraries + Removed Random PMC type and added in a "rand" dynop + Optimization and Improvements to the NCI thunk generator + New include file libpaths.pasm - Compilers + Multiple .local with same name and different type is now an error on IMCC. - Platforms + Improved support for detecting Fink and Macports + Updated search directories for libraries - Documentation + "Parrot Developers Guide: PIR" released to publisher and available to purchase + Improved documentation about Parrot Debugger + Update PGE Documentation - Miscellaneous + Added tests + Fixes to code, documentation, and standards Many thanks to all our contributors for making this possible, and our sponsors for supporting this project. Our next scheduled release is 15 September 2009. Enjoy! --Andrew Whitworth
Parrot 1.3.0 "Andean Swift" released
On behalf of the Parrot team, I'm proud to announce Parrot 1.3.0 "Andean Swift." Parrot (http://parrot.org/) is a virtual machine aimed at running all dynamic languages. Parrot 1.3.0 is available on Parrot's FTP site, 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 Subversion on the source code repository to get the latest and best Parrot code. Parrot 1.3.0 News: - Core + Optimized parts of the IO system + Fixed inheritance hierarchy of FileHandle and Socket PMC types + Fixed leaks involving subroutines and Parrot_Context + Cleaned up and refactored GC internals, including fixes and optimizations + Optimized PMC class manipulations to use type numbers instead of string names + Fixed problems involving hashval calculations in strings + Removed unnecessary MULTI dispatches in built-in PMCs + Fixed memory leaks involving PMCs that were not properly destroyed + Fixed creation of PMCProxy PMCs in correct namespaces + Added preliminary Pipe support + Fixed cloning of Object PMCs + Added root_new opcode + Added initial versions of Packfile PMCs with read/write capabilities - Compilers + Fixed several memory leaks in IMCC + Updated PCT to use root_new opcode + Added support for keyword "self" in NQP - Documentation + Improved and expanded /docs/book + Updated project documentation + Defined 'experimental' status and procedures in DEPRECATED.pod - Miscellaneous + Cleaned code and improved code-level documentation + Various bugfixes, code cleanups, and coding standard fixes + Added an experimental compiler library to help use PIR libraries from HLLs + Updated OpenGL library and examples to support experimental HLL import Many thanks to all our contributors for making this possible, and our sponsors for supporting this project. Our next scheduled release is 21 July 2009. Enjoy! --Andrew Whitworth
Re: New CPAN
On Sat, May 30, 2009 at 7:56 AM, Mark Overmeer wrote: > * Andrew Whitworth (wknight8...@gmail.com) [090530 00:24]: >> I agree. Doing one thing well is so much better for everybody then >> doing a million things poorly. An assorted "blob of data" repository >> is far less valuable to the Perl5, Perl6, and Parrot communities then >> a dedicated library repository is. > > Why? Ever heart of extensible meta-data. Can be done in two ways. > The idea is tha, on the three levels of implementation (see recent > email in other thread), you have some meta-data. I'm not saying we *can't* create a general repository for all sorts of nonsense, I'm saying that we *shouldn't*. It doesn't matter what kind of meta data you use, or how you structure your URI, or whatever: It's a bad idea. In this case, we should follow the maxim that "less is more", and realize that a tighter focus will create better value. People are going to form a one-to-one association with your project and what they expect to find there. When I think "email", I immediately associate that in my mind with "gmail". When I think "encyclopedia", I make an immediate association to "wikipedia", and vice versa. What do we want people to think about when they think about CPAN, "dynamic software packages" or "all sorts of assorted garbage with extensible metadata". > The ONLY difference between a "specialized" implementation of an archive > and a flexible one like I propose, is that in the latter you are forced to > clearly assign meta-data facts to one of these three levels. But there is > no limitiation in the amount and content of the meta-data you can collect. If you want to create an infrastructure that is vastly extensible and too clever by half, that's you're prerogative. I don't care what software infrastructure we use for a new CPAN, nor what methodology is used to design it. What I do care about is that the final CPAN website that we end up with only contains packages related to Perl5, Perl6, and Parrot. Create a server that can theoretically handle images and other garbage if you want to, but we should make sure the site administrators disable that feature immediately. > Well, so your worries are unjustified. And the two simple solutions as > I promissed in the first line of my comment: > 1 Add three seperate meta-data fragments to one blob > 2 Create one meta-data file which contains all three components. > As simple as that. Again, we are capable of doing this from a technical standpoint. It's still a bad idea. --Andrew Whitworth
Re: New CPAN
On Fri, May 29, 2009 at 5:37 PM, Daniel Carrera wrote: > Mark Overmeer wrote: >> >> And the next consideration: when we have a piece of software which >> administers Perl5 or Perl6 or Nokia.bin or Elf. Why stop there? >> What is the overlap? It is basically all just some blob of data with >> some associated meta-data to search and retreive the blobs. It is only >> the client side install tool which looks into the content of the package. >> Why not allow pure pod releases? A small step to documents in any other >> format. Why not share holiday pictures? Also just a blob of data with >> some meta-data. > > Your idea of using CPAN to share holiday pictures is one of the things that > really turned me off from your CPAN6 proposal. I do want this to be about > Perl, you don't, and that's a point where we differ. In my examples, > Nokia.bin is so that mobile users don't have to compile software on their > tiny CPUs. I can see merit in adding Ruby modules because in a new Parrot > world, there is real opportunity for Perl and Ruby to share libraries with > each other (e.g. Perl on Rails). But when you start talking about sharing > holiday pictures, you have completely left the Perl realm and I am > completely turned off. I agree. Doing one thing well is so much better for everybody then doing a million things poorly. An assorted "blob of data" repository is far less valuable to the Perl5, Perl6, and Parrot communities then a dedicated library repository is. Adding metadata to something like the existing CPAN that describes language and implementation is a step that allows Perl6 libraries and maybe even POD-only releases (language="pod", platform="pod") to be supported in the short term and opens the possibility of multiple languages being supported in the future. However, adding these two bits of metadata cannot be used meaningfully to allow all sorts of random media, which is a Good Thing. We want a future CPAN to be "the place to go for supported and tested library packages for Perl and maybe other languages", not "the place where people dump assorted unrelated shit". --Andrew Whitworth
Parrot 0.8.2 "Feliz Loro" Released!
On behalf of the Parrot team, I'm proud to announce Parrot 0.8.2 "Feliz Loro." Parrot (http://parrotcode.org/) is a virtual machine aimed at running all dynamic languages. Parrot 0.8.2 is available via CPAN (soon), or follow the download instructions at http://parrotcode.org/source.html. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion on the source code repository to get the latest and best Parrot code. Parrot 0.8.2 News: - Implementation + fixed lexical semantics + added the 'capture_lex' opcode + added automatic resume for nonfatal exceptions + added multidispatch cache + applied miscellaneous performance improvements, including startup time + fixed several bugs and leaks found by Coverity Scan + removed race conditions from parallel testing - Compilers + IMCC - removed undocumented .param int => syntax - .line directive now only takes an integer argument - new .file directive to specify the file name being compiled + PCT - properly handles lexical generation and closure semantics - uses :subid instead of name lookups to reference PAST::Block nodes - added PAST::Control node type (exception handlers) + PGE - add support for and assertions - Match objects use Capture PMC instead of Capture_PIR + PIRC - add macro handling to PASM mode - disable vanilla register allocation in PASM mode, but do allow optimization - add tests and bug fixes - first bits of bytecode generation. No sub calling/returning yet. - Languages + Rakudo - fixed lexical handling and recursion - refactored subtypes implementation - support for quotes with multi-character delimiters - implemented list slices (Positional role) - list assignment - reduction meta operators - hyper meta operators - cross meta operators - more builtin functions - added Nil type - basic support for protos - iterator on filehandle objects - basic support for exception handlers - warn + Lua - added complex & mathx libraries - merged LuaClosure & LuaFunction PMC + Pipp - added support for a return value from user defined functions - added incomplete implemention of 'require_once' + Ecmascript - parser fixes, parses spidermonkey's top level test/shell.js - Deprecations + PARROT_API is now PARROT_EXPORT + PIR - :lexid is now :subid - .arg is now .set_arg - .result is now .get_result - .yield (in .begin/end_yield) is now .set_yield - .return (in .begin/end_return) is now .set_return - .namespace x / .endnamespace x syntax is removed + Capture_PIR (runtime/parrot/library/Parrot/Capture_PIR.pir) Many thanks to all our contributors for making this possible, and our sponsors for supporting this project. Our next scheduled release is 20 January 2009. Enjoy! --Andrew Whitworth