[perl #47764] [TODO] COW for one or all users of a modified string

2007-11-24 Thread via RT
# New Ticket Created by  Bernhard Schmalhofer 
# Please include the string:  [perl #47764]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=47764 


In docs/memory_internals.pod there is a XXX item:

  Copying GC uses a CBuffer_Tail after the end of the actual variable 
length
  string and marks such COW strings with CTAIL_moved and stores the 
new address
  in the buffer header, so other users of this string can be updated to 
reuse the
  same string (XXX one or all other users?).

I have no idea whether this has been decided and implemented yet.
This issue was also mentioned in docs/ROADMAP.pod








Current roadmap for Perl 6 on Parrot

2007-11-24 Thread Patrick R. Michaud
I've just written up a brief road map with the current status
and development plans for the Perl 6 on Parrot compiler, and
thought I'd share it here as well.  It's also available as
languages/perl6/ROADMAP in the Parrot repository, for people
who want to look at it there.

Before going too far, I should point out that there are several
Perl 6 language translators in progress -- at least two of these 
include Pugs and KindaPerl6.  These are available from 
http://www.pugscode.org/ , and I highly recommend looking at
the work they are doing.  In particular, if writing Perl 6
programs is your interest (as opposed to developing a compiler), 
then Pugs currently supports the widest set of Perl 6 language 
features.


Building the Perl 6 on Parrot compiler
--

The compiler and toolchain that I've been focusing on developing
is for the Parrot virtual machine ( http://www.parrotcode.org/ ).
The Perl 6 Compiler for Parrot is called perl6, and it currently
lives in the languages/perl6/ directory of the Parrot repository.

To build the perl6 compiler, first get a working copy of Parrot,
then change to the languages/perl6/ subdirectory and type make.
This will build the compiler into a file called perl6.pbc.
The .pbc stands for Parrot bytecode, and represents an
an executable Parrot module.

To run a program with perl6, one then issues a command like

$ parrot perl6.pbc hello.pl

Parrot does not yet support a #! syntax that allows us to run
Perl 6 scripts directly from the command line, but that will
undoubtedly be coming soon.

If the perl6 compiler is invoked without a script argument
(i.e., parrot perl6.pbc), it enters a small interactive 
mode that allows Perl 6 statements to be executed from the 
command line.

After the compiler is built, one can run make test to run
the local test suite, or make spectest to download and run
selected tests from the Pugs repository.

I will note here that we've all collectively decided that the
Pugs repository will be the home of the official Perl 6 test
suite for the forseeable future.  Thus, it's the source of
tests that all of the development efforts should target.
A lot of effort over the next few months will be spent
in re-organizing the test suite and ensuring that it accurately
reflects the current Perl 6 specification as given by the 
synopses documents ( http://dev.perl.org/perl6/doc/synopsis.html ).


Structure of the compiler as of 2007-11-01
--

Before describing where we're going, it may be useful to briefly
outline where we've been.  As of early November 2007, the 
perl6 compiler is divided up into four major components:

1.  the parsing grammar (src/parser/Grammar.pg)
2.  some parsing support subroutines (src/parser/*.pir)
3.  the AST transformation (src/PAST/Grammar.tg)
4.  runtime support (src/builtins/, src/classes/, src/pmc/)   

The parsing grammar is written using Perl 6 regular expressions
(Synopsis 5) -- the version of regular expressions that were in 
effect at the beginning of the year.  More on this in a bit.  
The Parser Grammar Engine (PGE) is used to compile the grammar 
into a working parser.  The parsing support routines are used 
to parse constructs (e.g., quoted literals) that are more easily 
parsed procedurally than with regular expressions.

The AST transformation uses another tool called the Tree
Grammar Engine (TGE) to convert a parse tree into an
abstract syntax tree representation known as PAST-pm.  The
PAST-pm toolchain is then able to perform the remainder of
the code generation and execute the program.

The runtime support consists of some basic types and operators,
which are currently written in a mix of PIR and C.  Extensions
are expected to be bootstrapped using Perl 6.


Where things are headed next


While the design and implementation of the perl6 compiler has
remained fairly static throughout 2007, a number of other things
have been occurring that will spark a substantial redesign.

First, as of Parrot 0.5.0 we now have a shiny new object model 
that eliminates many of the obstacles that had been impeding 
work on the compiler.  

Another significant change has been the development of a
standard grammar for Perl 6, known as STD.pm [1].  Larry started
the STD.pm grammar earlier this year based on the grammars written 
for Pugs and perl6, and partially as a result of this grammar 
there's been some substantial redesign and improvement to 
Synopsis 5 (Regexes).  

So, one of the things we will be doing soon is to redesign the
perl6 compiler using a grammar that is much closer to STD.pm .
We aren't quite ready to use STD.pm directly, because it relies
somewhat on having a working Perl 6 implementation, as well
as some new constructs that aren't implemented by Parrot's
regex engine.  It may be a while before all of this is ready,
so we'll use a modified-but-similar-structure grammar for now,
and work towards convergence with 

[svn:parrot-pdd] r23020 - trunk/docs/pdds/draft

2007-11-24 Thread kjs
Author: kjs
Date: Sat Nov 24 11:11:16 2007
New Revision: 23020

Modified:
   trunk/docs/pdds/draft/pdd19_pir.pod

Log:
[pdd19] clarify text for single quoted strings. Replace char string with 
single quoted string, as suggested by pmichaud++ and masak++.

Modified: trunk/docs/pdds/draft/pdd19_pir.pod
==
--- trunk/docs/pdds/draft/pdd19_pir.pod (original)
+++ trunk/docs/pdds/draft/pdd19_pir.pod Sat Nov 24 11:11:16 2007
@@ -115,12 +115,12 @@
 
 =over 4
 
-=item 'char constant'
+=item 'single-quoted string constant'
 
 Are delimited by single-quotes (C'). They are taken to be ASCII encoded. No
 escape sequences are processed.
 
-=item string constants
+=item double-quoted string constants
 
 Are delimited by double-quotes (C). A C inside a string must be escaped
 by C\.  Only 7-bit ASCII is accepted in string constants; to use characters


Re: [perl #31633] [TODO] Allow Languages to be self contained

2007-11-24 Thread Will Coleda


On Nov 24, 2007, at 4:26 PM, Bernhard Schmalhofer via RT wrote:


On Mi. 05. Jul. 2006, 12:17:12, bernhard wrote:


Contrive things so that no code whatsover must be maintained outside
of the language specific directory. This includes:


When adding Eclectus I had to edit following files:
- config/gen/makefiles/languages.in
- config/gen/languages.pm
- languages/LANGUAGES_STATUS.pod


And someone else updated MANIFEST for you. =-)


Adding info to LANGUAGES_STATUS.pod is reasonable.

config/gen/languages.pm handles the configuration of languages.
Primarily configuration is the generation of the file LANGUAGE/ 
Makefile.

I propose that languages should follow the 'dotnet' way, that does
configuration with:

   cd LANGUAGE; perl Configure.pl.

Thus gen::languages could simply loop through the the subdirs of the
'languages' directory.

The language specific targets of 'languages/Makefile' could also be
generated from a loop over the subdirs of 'languages'.

The root Makefile also has a list of generated Makefiles of the
languages. This list could be done away with, with cleaning up is done
with 'make languages-realclean'.

Any comments ?



Seems reasonable.


--
/* [EMAIL PROTECTED] */



--
Will Coke Coleda
[EMAIL PROTECTED]




[perl #31633] [TODO] Allow Languages to be self contained

2007-11-24 Thread Bernhard Schmalhofer via RT
On Mi. 05. Jul. 2006, 12:17:12, bernhard wrote:

  Contrive things so that no code whatsover must be maintained outside
  of the language specific directory. This includes:

When adding Eclectus I had to edit following files:
- config/gen/makefiles/languages.in
- config/gen/languages.pm
- languages/LANGUAGES_STATUS.pod

Adding info to LANGUAGES_STATUS.pod is reasonable.

config/gen/languages.pm handles the configuration of languages.
Primarily configuration is the generation of the file LANGUAGE/Makefile.
I propose that languages should follow the 'dotnet' way, that does
configuration with:

   cd LANGUAGE; perl Configure.pl.

Thus gen::languages could simply loop through the the subdirs of the
'languages' directory.

The language specific targets of 'languages/Makefile' could also be
generated from a loop over the subdirs of 'languages'.

The root Makefile also has a list of generated Makefiles of the
languages. This list could be done away with, with cleaning up is done
with 'make languages-realclean'.

Any comments ?

-- 
/* [EMAIL PROTECTED] */