Re: [perl #57634] [RFC] Remove .globalconst from PIR

2008-08-16 Thread Allison Randal

Klaas-Jan Stol wrote:


Therefore, my proposal is to remove the .globalconst directive;
whenever you need to have a global const, use .const outside of a
subroutine.
whenever you need to have a local const (in a sub), use .const inside a
subroutine.


If we're going to remove one, let's deprecate .const outside of sub 
blocks, and make .globalconst mean a global constant everywhere. 
Consistency is a good thing, but so are clear distinctions between 
similar-but-different things.


Allison


Re: Fwd: [perl #57656] [PROPOSAL][PIR] change PIR sugar for concat into .. (or something else)

2008-08-16 Thread Allison Randal

Klaas-Jan Stol wrote:


On Wed Aug 06 05:53:07 2008, kjs wrote:

My proposal would be to change the concatenate dot into .., which looks
like it, but is more explicit, and will prevent such mistakes.


I agree that there should be some change. I've run into this problem
myself in the past, and it's very frustrating. I don't like having to
take into account whitespace to resolve syntactic ambiguities,
especially not in something which is basically an assembly language.


The example in the original ticket is an IMCC parsing problem. The code:

  foo . bar()

should absolutely never be parsed as a CONCAT operation. The dot should 
only be parsed as CONCAT when it's accompanied by an '=':


$S0 = hi . there

or

$S1 .= there

because it is simple syntactic sugar for the 'concat' opcode, which 
always either takes a destination argument, or a self-modifying first 
source argument.


Space is never allowed around the method-call dot.


I like .. and ~. I also like +, if we can get IMCC to reliably
understand that when used on strings it performs concatenation instead
of some crazy addition. I definitely don't like . since our best
practices involves quoting method names such as foo.'bar' which raises
all sorts of ambiguity.


From common HLLs, '+' is the only one that makes any sense. And, it's 
impossible in a low-level language like PIR, because PIR would have no 
way of knowing whether to dispatch the following to 'concat' or 'add':


$P0 = $P1 + $P2

So, proposal rejected. In any case where the dot is unclear, you can 
always use:


$S0 = concat hi, there

or

concat $S0, hi, there

PIR really is just an assembly language with a tiny bit of syntactic 
sugar. It's not an HLL.


Allison


Re: interpreter persistence issues

2008-08-16 Thread Allison Randal

Jeff Horwitz wrote:
i'd like to have an option in mod_parrot to clear all user-generated 
data (globals, namespaces, subs, etc.) from an interpreter, leaving any 
bytecode that has been loaded (e.g. compilers).  the point here is to 
eliminate problems caused by data persistence on hosted web servers, 
which is one of several reasons why many hosting companies don't offer 
mod_perl. the persistence might even cause problems with pipp/PHP, as 
it's not expected for data to persist, so this is something mod_parrot 
needs to support.


i'm sure we'd have to provide some significant hints to whatever routine 
is doing the dirty work, but before i even start to look at this, is it 
even possible with our current architecture?  can we get close?


It would be tricky at the moment. It'll be much easier once security 
sandboxing is in place. You'll be able to run mod_parrot code in a 
virtual interpreter that only has access to make local modifications, 
though it can read from the parent interpreter. (Think of it as a COW 
scheme, or lexical interpreters.) So, you can discard the cheap local 
overlay to get rid of local changes, and still have the full interpreter 
running in the background with all its loaded modules.


Helpful, but not absolutely necessary, would be a list of what should 
persist and what shouldn't. PHP might provide a good starting point for 
the list. It's not just a matter of keep loaded modules but discard 
variables because loaded bytecode may create package or class variables 
too.


Allison


Re: [perl #57636] [TODO][PDD19] Document the reason for :unique_reg flag

2008-08-16 Thread Allison Randal

chromatic wrote:

On Thursday 07 August 2008 08:26:19 Bob Rogers wrote:


I once suggested a null register allocator that would do this
globally, but this is a better idea.  The only use case I can think of
is debugging, particularly of the register allocator, but that's still
important.


In theory, that's what the vanilla register allocator does.  In practice, 
somehow something sometimes turns on the graph-based allocator, which has a 
couple of bugs.  PGE trips this occasionally.


The graph-based allocator is currently completely disabled, and may be 
ripped out.


:unique_reg is a useful feature. For one thing, it's a compiler 
optimization to skip the allocation code on certain variables. And, 
we're likely to run through multiple register allocator algorithms over 
the years, so the ability to protect certain variables from register 
alligators is likely to find future use.


When disabling optimizations, you generally want to do it for the 
smallest area possible, so turning off allocation for particular 
variables is better than turning it off for an entire subroutine. But, 
if we find that supporting :unique_reg for particular variables makes it 
overly difficult to implement future register allocators, we can 
deprecate it then and switch to a per-subroutine selector.


Allison


[perl #57942] [BUG] Smolder failure [linelength, compilers/pirc]

2008-08-16 Thread James Keenan via RT
On Fri Aug 15 18:33:59 2008, [EMAIL PROTECTED] wrote:
 
 And I, for one, find myself going to the Smolder site much more often
 than our 'official' site these days -- precisely because I can spot new
 test failures more quickly there and jump in with a quick fix.  


As I did just now:

I refreshed my Smolder page, saw that the ratio was 99.99%, clicked on
this TAP: 
http://smolder.plusthree.com/app/public_projects/tap_stream/3959/436

Did an 'svn up', fixed the file in question, committed.  

http://www.parrotvm.org/svn/parrot/revision?rev=30267

All within 5 minutes as I was on my way out the door.




Re: interpreter persistence issues

2008-08-16 Thread Jeff Horwitz

On Sat, 16 Aug 2008, Allison Randal wrote:


Jeff Horwitz wrote:
i'd like to have an option in mod_parrot to clear all user-generated data 
(globals, namespaces, subs, etc.) from an interpreter, leaving any bytecode 
that has been loaded (e.g. compilers).  the point here is to eliminate 
problems caused by data persistence on hosted web servers, which is one of 
several reasons why many hosting companies don't offer mod_perl. the 
persistence might even cause problems with pipp/PHP, as it's not expected 
for data to persist, so this is something mod_parrot needs to support.


i'm sure we'd have to provide some significant hints to whatever routine is 
doing the dirty work, but before i even start to look at this, is it even 
possible with our current architecture?  can we get close?


It would be tricky at the moment. It'll be much easier once security 
sandboxing is in place. You'll be able to run mod_parrot code in a virtual 
interpreter that only has access to make local modifications, though it can 
read from the parent interpreter. (Think of it as a COW scheme, or lexical 
interpreters.) So, you can discard the cheap local overlay to get rid of 
local changes, and still have the full interpreter running in the background 
with all its loaded modules.


Helpful, but not absolutely necessary, would be a list of what should persist 
and what shouldn't. PHP might provide a good starting point for the list. 
It's not just a matter of keep loaded modules but discard variables because 
loaded bytecode may create package or class variables too.


the virtual interpreter scheme would certainly do the trick, as we can 
initialize things the way we want (loading compilers, etc.) in the parent 
and never touch it again.  this also lets the HLL layer determine if and 
when to discard the local changes, and mod_parrot will just provide the 
appropriate hooks to do so.  when in doubt, pass the buck to the HLL 
layer.  :)


so i guess i'll table this issue until the sandboxing is in place.

-jeff


Re: Merged pdd25cx branch

2008-08-16 Thread Allison Randal

François Perrad wrote:


Ok, Lua tests pass, but the behavior has changed.
(The tests were written to check the exception message, not the full 
back trace)
The pushaction allowed to retrieve the backtrace where the exception 
occurred.
The backtrace from the exception handler is alway the same (docall - 
main),

so it has no interest in an user point of view.

Previously :
$ ./parrot languages/lua/lua.pbc -e error 'user_exception'
lua.pbc: EVAL_1:34: user_exception
stack traceback:
languages/lua/src/lib/luaaux.
pir:205 in function 'lua_error'
languages/lua/src/lib/luabasic.pir:336 in function 'error'
EVAL_1:34 in function 'main_10'
languages/lua/src/lib/luaaux.pir:916 in function 'docall'
lua.pir:353 in function 'dostring'
lua.pir:247 in function 'runargs'
lua.pir:120 in function 'main'

Now:
$ ./parrot languages/lua/lua.pbc -e error 'user_exception'
lua.pbc: _._:0: user_exception
stack traceback:
languages/lua/src/lib/luaaux.pir:920 in function 'docall'
lua.pir:353 in function 'dostring'
lua.pir:247 in function 'runargs'
lua.pir:120 in function 'main'


Okay. A record of the original location where the exception was thrown 
is certainly an important feature to add. Wouldn't it be more useful if 
you could pass it in as an additional option to 'throw', or if the 
exception object stored the information for you automatically?


We added a 'stacktrace' attribute to the exception object so we could 
keep this information persistently. But, it's not currently storing 
anything. The general idea is that it will run the stack trace once when 
the exception is thrown, and keep the information around (as a string or 
as a more useful datastructure) for use by the exception handler, or any 
subsequent rethrows. Will that provide what you need?


Allison


Re: Merged pdd25cx branch

2008-08-16 Thread Allison Randal

Bob Rogers wrote:

   From: Allison Randal [EMAIL PROTECTED]

   The biggest changes you'll notice are the new exception system, a vastly 
   reduced usage of the remaining stack (though it's not completely removed 
   yet), and the fact that pushaction subs no longer fire on scope exit 
   (pushaction will likely be deprecated).


And be replaced by what?

   I seem to be an underutilized resource here.  I would dearly love to
help with this (among other things), but can't do anything unless you're
willing to tell me where you're going.


We're going to a completely stackless virtual machine.

What I need from you is information on how you were using pushaction, so 
I can figure out what the appropriate replacement is. Is it only 
UNWIND_PROTECT and SPECIAL variables? And, how are you implementing 
those using 'pushaction'?


The actions we have now are tied to a context (currently a subroutine 
scope), as a handler for a particular control exception (not an error 
exception). They can effectively implement the same features as 
'pushaction', but in a safer, continuation-friendly, non-global way.


I'm not entirely clear yet how you're using 'pushaction', so I don't 
know if control actions are the best replacement, or if some other 
feature will be a better replacement


Allison


RE: November

2008-08-16 Thread Conrad Schneiker
 From: Carl 

 We're pleased to annouce the release of November, a wiki engine written
 in Perl 6.
 
 November is:
 
 * ...a proof-of-concept of what Rakudo Perl 6 can do today.
 * ...released early rather than when it's done.
 * ...meant to promote interest and involvement in Perl 6/Rakudo/Parrot
   development.
 
 To learn more, please browse the slides from the YAPC:EU 2008 lightning
 talk:
 
  http://viklund.pp.se/november.pdf

I have added your link to the Official Perl 6 wiki here:

 
(http://www.perlfoundation.org/perl6/index.cgi?perl_6_articles_and_presentat
ions)

(Anyone else producing interesting Perl 6 articles and presentations should
also add links to that page.)

 November is free, released under the Artistic License 2.0, and
 available
 online:

http://github.com/viklund/november/ 

Great! 

By the way, in the U.S., Thanksgiving day happens to be in November. 
So thanks in advance.

Do you plan to make a publicly-usable version of this wiki available,
perhaps
on the feather development system?

Best regards,
Conrad Schneiker

www.AthenaLab.com

Official Perl 6 Wiki — http://www.perlfoundation.org/perl6 
Official Parrot Wiki — http://www.perlfoundation.org/parrot 




[perl #57964]

2008-08-16 Thread [EMAIL PROTECTED] (via RT)
# New Ticket Created by  [EMAIL PROTECTED] 
# Please include the string:  [perl #57964]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57964 





[perl #57972] Implement eqv and === operators

2008-08-16 Thread [EMAIL PROTECTED] (via RT)
# New Ticket Created by  [EMAIL PROTECTED] 
# Please include the string:  [perl #57972]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57972 


- No dependencies


[perl #57966] Implement Whatever (

2008-08-16 Thread [EMAIL PROTECTED] (via RT)
# New Ticket Created by  [EMAIL PROTECTED] 
# Please include the string:  [perl #57966]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57966 





[perl #57974] Implement missing infix:xx= operator

2008-08-16 Thread [EMAIL PROTECTED] (via RT)
# New Ticket Created by  [EMAIL PROTECTED] 
# Please include the string:  [perl #57974]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57974 


- Awaiting parser improvements to properly parse and
handle infix_postfix_meta_operator


[perl #57980] Fix bugs with nested ?? !!

2008-08-16 Thread [EMAIL PROTECTED] (via RT)
# New Ticket Created by  [EMAIL PROTECTED] 
# Please include the string:  [perl #57980]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57980 


- Awaiting parser improvements (PGE)


[perl #57976] Implement infix:orelse

2008-08-16 Thread [EMAIL PROTECTED] (via RT)
# New Ticket Created by  [EMAIL PROTECTED] 
# Please include the string:  [perl #57976]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57976 


- Requires some specialized structures, perhaps a new PAST::Op pasttype (PCT)


[perl #57978] Implement last/redo/next/continue control exceptions

2008-08-16 Thread [EMAIL PROTECTED] (via RT)
# New Ticket Created by  [EMAIL PROTECTED] 
# Please include the string:  [perl #57978]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57978 


- Needs last/redo/next/continue exceptions in PCT (PCT)


[perl #57984] Finish implementing given and check/fix tests in S04-statements\given.t

2008-08-16 Thread [EMAIL PROTECTED] (via RT)
# New Ticket Created by  [EMAIL PROTECTED] 
# Please include the string:  [perl #57984]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57984 


- Need resumable exceptions (Parrot)


[perl #57982] Fix lambda expression parse bug when used as rvalue

2008-08-16 Thread [EMAIL PROTECTED] (via RT)
# New Ticket Created by  [EMAIL PROTECTED] 
# Please include the string:  [perl #57982]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57982 


- Needs parser/PGE fix (PGE)


[perl #58012] Empty contextualizer @() should be same as @($/)

2008-08-16 Thread [EMAIL PROTECTED] (via RT)
# New Ticket Created by  [EMAIL PROTECTED] 
# Please include the string:  [perl #58012]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58012 


- File an RT ticket for this with test case


[perl #58010] Implement ::?CLASS

2008-08-16 Thread [EMAIL PROTECTED] (via RT)
# New Ticket Created by  [EMAIL PROTECTED] 
# Please include the string:  [perl #58010]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58010 


- Update in actions.pm to define compiler variable


[perl #57986] ) in array indexes

2008-08-16 Thread [EMAIL PROTECTED] (via RT)
# New Ticket Created by  [EMAIL PROTECTED] 
# Please include the string:  [perl #57986]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57986 


- need an implementation of Whatever


[perl #58002] Implement state variables

2008-08-16 Thread [EMAIL PROTECTED] (via RT)
# New Ticket Created by  [EMAIL PROTECTED] 
# Please include the string:  [perl #58002]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58002 


- Need to fix lexical and initialization issues (Parrot)


[perl #58020] Fix problem with using Str as a type constraint or in MMD

2008-08-16 Thread [EMAIL PROTECTED] (via RT)
# New Ticket Created by  [EMAIL PROTECTED] 
# Please include the string:  [perl #58020]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58020 


- File an RT ticket for this?


[perl #57968] Fix issues with Int type constraint and Integer PMCs

2008-08-16 Thread [EMAIL PROTECTED] (via RT)
# New Ticket Created by  [EMAIL PROTECTED] 
# Please include the string:  [perl #57968]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57968 


- awaiting .HLL capabilities


[perl #57996] Make m/.../ syntax for constructing a regex work

2008-08-16 Thread [EMAIL PROTECTED] (via RT)
# New Ticket Created by  [EMAIL PROTECTED] 
# Please include the string:  [perl #57996]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57996 


- Update grammar.pg (short-term), or wait for STD.pm integration


[perl #58018] Fix MMD-related bugs in S03-operators\range.t

2008-08-16 Thread [EMAIL PROTECTED] (via RT)
# New Ticket Created by  [EMAIL PROTECTED] 
# Please include the string:  [perl #58018]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58018 


- Need to refactor comparison ops in rakudo to avoid or handle 'cmp'


[perl #58000] Comparison operators on junctions should return junction of True/False

2008-08-16 Thread [EMAIL PROTECTED] (via RT)
# New Ticket Created by  [EMAIL PROTECTED] 
# Please include the string:  [perl #58000]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58000 


- Needs junction dispatcher


[perl #58022] Implement return type coercion (as) and constraint (of)

2008-08-16 Thread [EMAIL PROTECTED] (via RT)
# New Ticket Created by  [EMAIL PROTECTED] 
# Please include the string:  [perl #58022]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58022 





[perl #57960] Inconsistent for loop semantics

2008-08-16 Thread Carl Mäsak
# New Ticket Created by  Carl Mäsak 
# Please include the string:  [perl #57960]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57960 


r30258:
$ ./perl6 -e '.say for [1,2,3]' # as expected
1
2
3

$ ./perl6 -e 'for [1,2,3] { .say }' # shouldn't that be the same?
1 2 3

$ ./perl6 -e 'for [1,2,3] - $a { say $a }' # or this?
1 2 3

$ ./perl6 -e 'for [1,2,3].list { .say }' # how do I make it...
1 2 3

$ ./perl6 -e 'for @([1,2,3]) { .say }' # ...loop over the elements?
1 2 3

$ ./perl6 -e 'for [1,2,3].clone { .say }' # aha! um...
1
2
3

All in all, it's difficult to actually loop on the contents of an
array at present. The semantics are not very consistent. I'm hoping
this is a bug.


[perl #57998] Fix modulo bugs and MMD-related bugs for += and -= (S03-operators\arith.t)

2008-08-16 Thread [EMAIL PROTECTED] (via RT)
# New Ticket Created by  [EMAIL PROTECTED] 
# Please include the string:  [perl #57998]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57998 


- Awaiting parser improvements to properly parse and
handle infix_postfix_meta_operator


[perl #58006] Fix .{key} parsefail when (hash index into $_)

2008-08-16 Thread [EMAIL PROTECTED] (via RT)
# New Ticket Created by  [EMAIL PROTECTED] 
# Please include the string:  [perl #58006]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58006 


- likely parser bug (Rakudo grammar.pg)


[perl #57990] Implement prefix:\ operator

2008-08-16 Thread [EMAIL PROTECTED] (via RT)
# New Ticket Created by  [EMAIL PROTECTED] 
# Please include the string:  [perl #57990]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57990 


- Need some clarity in spec and spectests for Capture objects


[perl #58008] Implement loops and conditionals taking pointy blocks

2008-08-16 Thread [EMAIL PROTECTED] (via RT)
# New Ticket Created by  [EMAIL PROTECTED] 
# Please include the string:  [perl #58008]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58008 


- Needs some minor PCT updates (PCT)


[perl #57988] Implement Rat data type

2008-08-16 Thread [EMAIL PROTECTED] (via RT)
# New Ticket Created by  [EMAIL PROTECTED] 
# Please include the string:  [perl #57988]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57988 


- awaiting clearer spec/understanding of the relationship between Num and Rat


[perl #57992] Implement infinite ranges

2008-08-16 Thread [EMAIL PROTECTED] (via RT)
# New Ticket Created by  [EMAIL PROTECTED] 
# Please include the string:  [perl #57992]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=57992 


- awaiting Whatever implementation


[perl #58024] Implement .perl on code objects

2008-08-16 Thread [EMAIL PROTECTED] (via RT)
# New Ticket Created by  [EMAIL PROTECTED] 
# Please include the string:  [perl #58024]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58024 


- Need a clarification of what .perl should return here


Re: Merged pdd25cx branch

2008-08-16 Thread Bob Rogers
   From: Allison Randal [EMAIL PROTECTED]
   Date: Sat, 16 Aug 2008 17:52:08 +0200

   We're going to a completely stackless virtual machine.

But Parrot is already stackless.  The dynamic_env slot to which I assume
you refer is really a tree with upward pointers.

   What I need from you is information on how you were using pushaction, so 
   I can figure out what the appropriate replacement is. Is it only 
   UNWIND_PROTECT and SPECIAL variables? 

Yes.

   And, how are you implementing those using 'pushaction'?

Was [1] not detailed enough?  This message links to [2] (from my YAPC
talk), which has working examples (up until the merge at least).  If you
need more detail, please be specific, though it will probably have to
wait until after the Parrot release.

   The actions we have now are tied to a context (currently a subroutine 
   scope), as a handler for a particular control exception (not an error 
   exception). 

It sounds like you're trying to tell me that I should not be using
continuations to implement *any* sort of nonlocal control flow.  If so,
it would have been kinder to say so before I put my time into a YAPC
talk where that was the central theme.

   They can effectively implement the same features as 'pushaction', but
   in a safer, continuation-friendly, non-global way.

You've completely lost me.  Not only do they have to be global (for some
definition of global), as far as I was concernced they had been safe
and continuation-friendly until the pdd25cx merge.

   I'm not entirely clear yet how you're using 'pushaction', so I don't 
   know if control actions are the best replacement, or if some other 
   feature will be a better replacement

   Allison

At a minimum, I need to be able to return values.

   But wait a minute:  Aren't these features documented somewhere?  If
so, please point me there, and maybe I can figure out what I need on my
own.  If not, why not?

-- Bob

[1]  
http://groups.google.com/group/perl.perl6.internals/browse_thread/thread/bb32cedc3456599a/c8822b8e854fa565?hl=enlnk=stq=pushaction+unwind-protect#c8822b8e854fa565

[2]  http://rgrjr.dyndns.org/perl/acsip/actions.html


[svn:parrot-pdd] r30272 - trunk/docs/pdds

2008-08-16 Thread rgrjr
Author: rgrjr
Date: Sat Aug 16 18:57:04 2008
New Revision: 30272

Modified:
   trunk/docs/pdds/pdd24_events.pod
   trunk/docs/pdds/pdd25_concurrency.pod

Log:
[typos] Neither pdd24_events.pod nor pdd25_concurrency.pod is in draft.


Modified: trunk/docs/pdds/pdd24_events.pod
==
--- trunk/docs/pdds/pdd24_events.pod(original)
+++ trunk/docs/pdds/pdd24_events.podSat Aug 16 18:57:04 2008
@@ -3,7 +3,7 @@
 
 =head1 NAME
 
-docs/pdds/draft/pdd24_events.pod - Parrot Events
+docs/pdds/pdd24_events.pod - Parrot Events
 
 =head1 ABSTRACT
 

Modified: trunk/docs/pdds/pdd25_concurrency.pod
==
--- trunk/docs/pdds/pdd25_concurrency.pod   (original)
+++ trunk/docs/pdds/pdd25_concurrency.pod   Sat Aug 16 18:57:04 2008
@@ -3,7 +3,7 @@
 
 =head1 NAME
 
-docs/pdds/draft/pdd25_concurrency.pod - Parrot Concurrency
+docs/pdds/pdd25_concurrency.pod - Parrot Concurrency
 
 =head1 ABSTRACT
 


NEWS update for Parrot 0.7.0

2008-08-16 Thread Bob Rogers
   From: Bob Rogers [EMAIL PROTECTED]
   Date: Fri, 15 Aug 2008 12:45:56 -0400

  Parrot release 0.7.0 is due out this coming Tuesday, so now is the
   time to start focusing on . . . updating such things as the NEWS and
   PLATFORMS files . . .

I've fleshed out NEWS based on svn log; please give it a look, because
I'm sure I've missed lots.  In particular, I didn't say anything about
Cardinal, Pipp, and Tcl, because the commits for these languages tended
to make my eyes glaze.  TIA,

-- Bob


New in 0.7.0 [r29473 through r30270]
- Specification
  + PDD27: add multisub lookup
- Languages
  + Cardinal (Ruby):
  + Lua:
- [opengl4lua branch merge?]
  + Pipp (PHP):
  + Pugs (Perl 6):
- removed due to bit rot
  + Rakudo (Perl 6):
- updated the Rakudo roadmap
- Perl 6 multi dispatch
- dispatch with slurpies
- class attributes (my $.x)
- now up to 2196 passing tests
  + Tcl:
- [lots]
- Compilers
  + PCT:
- :scope('register') for PAST::Var nodes
  + PIRC:
- PIR registers now use the vanilla register allocator
- all PASM output now uses PASM registers
- all .locals and $registers are mapped
- Configuration
  + tests now clean up after themselves
  + improved parallel test support
  + ports/cygwin added
  + Darwin problems fixed
- Deprecations
  + .pragma n_operators is deprecated
  + old PASM register syntax (without $) is deprecated
  + bare (unquoted) method names are deprecated
  + #line will be replaced with .line
  + .HLL_map syntax will change
  + .loadlib is now separate from .HLL
  + mmdvtregister and mmdvtablefind opcodes are deprecated
  + removed getfd, getclass opcodes, plus numeric get_attr and set_attr
- Implementation
  + new concurrency implementation (see PDD25)
  + new say opcode
  + Exception PMC now captures a return continuation
- Tools
  + parrot_debugger renamed from pdb, numerous tweaks
- Miscellaneous


[perl #58032] [BUG] languages/perl6/t/pmc/perl6multisub-dispatch-tiebreak.t: filename is too long

2008-08-16 Thread via RT
# New Ticket Created by  James Keenan 
# Please include the string:  [perl #58032]
# in the subject line of all future correspondence about this issue. 
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58032 


We appear to have a coding standard which limits us to 32 characters  
in a file's basename.  This particular test file has 33 characters.

not ok 3 - Filenames length

#   Failed test 'Filenames length'
#   at t/codingstd/filenames.t line 101.
# Filename with with more than 32 chars found in 1 files:
# languages/perl6/t/pmc/perl6multisub-dispatch-tiebreak.t:33 chars


Jonathan:  Perhaps you could delete the 'perl6' at the beginning of  
the basenames of these 4 files:

languages/perl6/t/pmc/perl6multisub-basic.t
languages/perl6/t/pmc/perl6multisub-dispatch-arity.t
languages/perl6/t/pmc/perl6multisub-dispatch-tiebreak.t
languages/perl6/t/pmc/perl6multisub-dispatch-type.t

'perl6' is already contained in the pathname, so having it in the  
basename is superfluous.

Thank you very much.
kid51