Less than a week to 1.0

fx options leverage You should be following parrot.org for all your parroty goodness, but in case this blog is your main connection...

...1.0 is due on Tuesday next week!

Parrot 0.9.1 "Final Countdown" released!

o/~ We're leaving together,

       but still its farewell o/~

o/~ And maybe we'll come back,

       To earth, who can tell? o/~

o/~ I guess there is no one to blame

       We're leaving ground

           Will things ever be the same again? o/~

o/~ It's the Final Countdown...

       The Final Countdown  o/~

--Europe, "The Final Countdown"

fx trade On behalf of the Parrot team, I'm proud to announce Parrot 0.9.1

"Final Countdown." Parrot (http://parrot.org/) is a virtual machine aimed

at running all dynamic languages.

Parrot 0.9.1 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.9.1 News:

- Implementation

  + Support for portable 'Inf', 'NaN' and -0.0

  + pbc_disassemble prints constants in constants table

  + New experimental BigNum implementation

  + Pair is now a dynamic loadable PMC

  + Various function name sanification

  + New implementation of Strings component

  + Replace various PMC value union access code by VTABLE method invocations

  + Replace various PMC value unions by ATTRibutes

  + Removed SArray PMC. Use FixedPMCArray instead.

- Documentation

  + Book

    - updates to Chapter 2 (getting started)

    - updates to Chapter 3 (PIR basics)

    - updates to Chapter 4 (PIR subroutines)

    - updates to Chapter 10 (HLLs)

    - updates to Chapter 12 (opcodes)

  + Function documentation

  + Pod documentation style modernized; no longer Perl 5 style.

  + PMC has an additional acronym: Poly Morphic Container

  + The DOD (Dead Object Detection) acronym is no longer used;

    use 'GC' to refer to the Garbage Collector component.

- Compilers

  + IMCC

    - :named flag can now take string registers as argument

    - A single '=cut' directive is now ignored (without initial Pod directive)

    - :vtable subs now have proper access to 'self' pseudo variable

- Languages

  + add new 'Pod' documentation parser

  + Pipp (PHP implementation):

    - Pipp is now at http://github.com/bschmalhofer/pipp

    - support for 'print', 'dirname', 'implode', 'str_replace',

    - various grammar fixes

  + ECMAScript

    + add 'quit', 'readline' builtins

    + fix 'Boolean' type and 'print' builtin

  + Lua

    - left the nest and is now at http://github.com/fperrad/lua/

  + Rakudo

    - left the nest and is now at http://github.com/rakudo/rakudo/

    - build instructions can be found at http://tinyurl.com/rakudo

  + lazy-k

    - left the nest and is now at http://github.com/bschmalhofer/lazy-k.git

  + unlambda

    - left the nest and is now at http://github.com/bschmalhofer/unlambda/

  + WMLScript

    - left the nest and is now at http://github.com/fperrad/wmlscript.git

  + removed Zcode implementation

- Tools

  + pmc2C

    - ATTRs are now inherited automatically in subclassing PMCs

- Deprecations

  + Parrot_readbc, Parrot_loadbc renamed to Parrot_pbc_read, Parrot_pbc_load.

  + .HLL_map directive in favour of 'hll_map' method on Parrot interpreter

  + Data::Escape library

- Tools

  + pbc_disassemble options added

  + pbc_dump renamed from pdump

- Miscellaneous

  + Parrot is now Copyright Parrot Foundation

  + Parrot's SVN repository is now hosted at https://svn.parrot.org

  + Various code cleanups, consting, 64-bit incompatibilities and other bug fixes

how to invest in Netflix shares Many thanks to all our contributors for making this possible, and our sponsors

for supporting this project.  Our next scheduled release is 17 March 2009.

Enjoy!

Readers Needed!

One of our key requirements for the release next Tuesday is improved documentation. Documentation is key, because it's the doorway through which new users will enter the world of Parrot. I've been doing a lot of work on documentation recently, along with several of the other developers. The problem is that from inside the project we can't always see where the holes are, and what the confusing bits are going to be. So, I'm asking for a little help from people who aren't current Parrot users or developers:

We need you!

We need people to read over the documentation and find the problem spots. What parts are confusing? What material isn't well covered, or isn't covered at all? What do you wish we talked about more? What information do you need in order to get started working with Parrot?

You can check out the source repository using SVN from https://svn.parrot.org/parrot/trunk/, you can find our documentation in the docs/ directory. Many of the files here, although not all of them, are used to populate our online documentation too (the online documentation has it's own problems too). We have a comprehensive book in development in the directory docs/book/, which contains a lot of material arranged in a linear narrative. All these things need some help.

We need suggestions, comments, even questions. Because answering your questions will help us to identify the information that is missing from our docs. We need patches, if you're able and want to contribute. Leave comments here on this blog with ideas, open a ticket at trac, or post a message to our mailinglist. It doesn't matter how you send us your reviews and your fixes, so long as you send a lot of them! We need help from readers and reviewers, especially people who aren't current Parrot users or developers, people who don't already have the answers. We need your help.

svn repository move

Heads up! In the short term, parrot's svn repository will be relocating from perl.org to parrot.org.

When this happens, there will be a small amount of downtime, and after that you'll be able to keep working with a simple 'svn switch' in your checkout.

We were going to try to squeeze this in today, but that's been postponed. More details on the schedule as they become available.

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
is a virtual machine aimed at running all dynamic languages.

Parrot 0.8.2 is available via CPAN
(soon), or follow the download
instructions. For those who would like to develop on Parrot, or help
develop Parrot itself, we recommend using href="http://subversion.tigris.org/">Subversion on
our 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)

Thanks to all our contributors for making this possible, and our sponsors
for supporting this project. Our next release is 20 January 2009.

Enjoy!

Parrot development speed

Yesterday there was some converation on #parrot about our development momentum; since I had the numbers easily available I put together a small chart:



This shows the number of commits to the Parrot repository within any given month; the regression line shows the (linear) rate of increase over the past two years.

So, not only are we making progress on Parrot, but measured by commits the rate of progress is increasing as well.

Memory Management in PIRC

Introduction

PIRC is a new implementation of the PIR language, and currently under heavy construction. While the code is documented, it does not provide an easy overview of implementation issues and design decisions. In order to solve this documentation gap, I'm writing these design decisions in a series of parrotblog.org articles. This very short article discusses the memory management of PIRC. 

The current PIR compiler, IMCC, has had a lot of memory leaks, most of which have been solved by now. Although conceptually manual memory management through malloc() and free() is very simple and straightforward, things become ugly once you loose overview of when datastructures go out of scope, and as a result you forget to free the memory. In PIRC a different approach is taken.

Note that instead of using malloc() and free() directly, you should use mem_sys_allocate() and mem_sys_free(), respectively, which are provided by Parrot.

Cheater!

PIRC parses the PASM or PIR input, builds a data structure, and generates a Parrot Byte Code file (a so-called Packfile). (at the moment of writing, the PBC is not generated yet, but work is underway to fix this; might take a while, though). The data structures that are created represent the PASM or PIR program being parsed, and as such can be considered an Abstract Syntax Tree.

As these data structures are used throughout the compilation phase, PIRC can cheat with memory management. Instead of freeing the memory of the data structures by manually calling mem_sys_free(), PIRC keeps track of all allocated memory blocks. Only when PIRC is done with the bytecode generation will it release all resources. This is fine, because the data structures are needed up to the end anyway, so memory is not occupied longer than necessary.

Poor Man's Garbage Collector

Whenever PIRC needs memory, a block of memory is allocated through Parrot's memory allocation function, mem_sys_allocate() (or a variant, which zeroes out all bytes). Before returning a pointer to the allocated block of memory, however, PIRC stores a pointer to the block of memory as well (in a list), and only then is the pointer to the block returned.

When PIRC is done with compiling, it will go through the list of memory pointers, and release the memory pointed to by each of the pointers. In a sense, you could consider this a garbage collector, except that there's no reuse of memory (but there's no need to anyway).

"Wait a minute," you might say, where are these pointers stored then? Well, of course, these pointers are stored in an extensible list, as we don't know the number of pointers to store beforehand. Surely the list cannot be allocated and store a pointer to itself.  This is fine, because the problem of keeping track of memory is now isolated to a single point in the program. The nodes in the list of allocated memory pointers are allocated directly through Parrot's memory functions. When all stored pointers are mem_sys_free()d, we only have to remember to mem_sys_free() these nodes. 

In this way, there's no need to worry about when pointers should be freed: it's done automatically, as long as PIRC allocates its memory through its built-in memory management system.

List of Pointers

Obviously, we don't want to create a new node for each pointer to store. Instead, a node can store a number of pointers, currently set to 512. So, after allocating memory for 512 times, a new node is created. This number of 512 was decided upon after some experimentation, but might prove too low for real world PIR input. As it's #define'd, it's easy to change, though.

Summary

In this very short article, I described how PIRC does its memory management. PIRC cheats a bit, by storing each pointer to an allocated block of memory in a special list. Once PIRC is done with compiling, all these pointers are passed to mem_sys_free(), Parrot's free() function (one by one, obviously). This way, you don't have to worry about when to free the memory in PIRC.