On 10/2/07, Allison Randal <[EMAIL PROTECTED]> wrote:
>
> [EMAIL PROTECTED] wrote:
> >
> >>> The big overall cunning plan is to remove ".local" for this purpose
> >>> (defining labels), and to use ".local" ONLY for declaring variables.
> >>> Then, once all ".local" (in macros) are replaced by ".lab
On 10/2/07, Allison Randal <[EMAIL PROTECTED]> wrote:
>
> Klaas-Jan Stol (via RT) wrote:
> >
> > Hi,
> >
> > This proposal is about resolving method names: bare words or quoted
> >
> > it might be that i'm not well informed on this issue, so please correct
> me
> > where I go wrong.
> >
> >
> > IMC
# New Ticket Created by James Keenan
# Please include the string: [perl #45919]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=45919 >
Until Sept 24, lib/Parrot/BuildUtil.pm was one of those Perl 5
components of Parrot wh
Author: allison
Date: Mon Oct 1 17:22:21 2007
New Revision: 21728
Modified:
trunk/docs/pdds/draft/pdd25_concurrency.pod
Log:
[pdd] Reference to java memory and threads for concurrency PDD.
Modified: trunk/docs/pdds/draft/pdd25_concurrency.pod
[EMAIL PROTECTED] wrote:
The big overall cunning plan is to remove ".local" for this purpose
(defining labels), and to use ".local" ONLY for declaring variables.
Then, once all ".local" (in macros) are replaced by ".label", we can
start replacing ".sym"s by ".local", so that ".sym" can be remov
Nuno 'smash' Carvalho wrote:
Still working on it. Sorry, but haven't had much free time lately, but
i'll try to finish this ASAP.
Great.
KJS, you might take a pass over it too. You've had a lot of good cleanup
suggestions.
Allison
My goal was to wrap up the pdd15oo branch by the end of September. We're
quite close. The two remaining big things are PGE and multiple dispatch,
and then test cleanup. Thanks to chromatic and particle for their work
on the tests.
I've been giving chromatic small tasks to work on, which seems
Klaas-Jan Stol (via RT) wrote:
Hi,
This proposal is about resolving method names: bare words or quoted
it might be that i'm not well informed on this issue, so please correct me
where I go wrong.
IMCC currently allows for method call syntax like this:
foo.bar()
foo."bar"()
Both invoke the
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #45917]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=45917 >
In src/exceptions.c there is the todo item:
"XXX this check should better be in Parrot
On Mon Oct 01 14:36:55 2007, ptc wrote:
> In src/exceptions.c there is mention about "exception being still in
TODO".
> This means that something about exceptions is not yet finished, and
needs
> to be implemented so that the code mentioned here (near
> rethrow_c_exception()) can be completed. S
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #45915]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=45915 >
In src/exceptions.c there is mention about "exception being still in TODO".
This means
Hi,
I have announced it elsewhere but I hope it is OK to do it here as well.
On 31 December 2007 we are going to have a one day Perl Workshop in
Israel http://act.perl.org.il/ilpw2007/
Following the workshop, between 1-5 January 2008 we are going to have a
Hackathon in Tel Aviv. http://act.perl.o
On Oct 1, 2007, at 12:45 PM, jerry gay wrote:
On 10/1/07, Paul Cochrane via RT
<[EMAIL PROTECTED]> wrote:
src/exceptions.c has a todo comment in it:
* XXX TODO get rid of all the internal_exceptions or call them
* with an interpreter arg
The fact that we can't completely get rid o
On 10/1/07, Paul Cochrane via RT
<[EMAIL PROTECTED]> wrote:
> src/exceptions.c has a todo comment in it:
>
> * XXX TODO get rid of all the internal_exceptions or call them
> * with an interpreter arg
>
> The fact that we can't completely get rid of internal_exception() has
> already been
This time I'm going to add some text to the ticket...
For the umteenth time...
src/exceptions.c has a todo comment in it:
* XXX TODO get rid of all the internal_exceptions or call them
* with an interpreter arg
The fact that we can't completely get rid of internal_exception() has
al
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #45907]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=45907 >
This transaction appears to have no content
Sorry for the extra email in everyone's inbox. I was trying to use
the rt command line tool but stuffed up.
Paul
On 01/10/2007, via RT Paul Cochrane <[EMAIL PROTECTED]> wrote:
> # New Ticket Created by Paul Cochrane
> # Please include the string: [perl #45905]
> # in the subject line of all fu
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #45905]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=45905 >
This transaction appears to have no content
Author: allison
Date: Mon Oct 1 09:51:59 2007
New Revision: 21716
Modified:
trunk/docs/pdds/draft/pdd24_events.pod
Log:
[pdd] Adding URL to Events PDD so all can see.
Modified: trunk/docs/pdds/draft/pdd24_events.pod
===
Parrot Bug Summary
http://rt.perl.org/rt3/NoAuth/parrot/Overview.html
Generated at Mon Oct 1 13:00:01 2007 GMT
---
* Numbers
* New Issues
* Overview of Open Issues
* Ticket Status By Version
* Requestors with mo
On 10/1/07, Nuno 'smash' Carvalho <[EMAIL PROTECTED]> wrote:
> Greetins parrot people,
>
> On 9/28/07, Allison Randal <[EMAIL PROTECTED]> wrote:
> > Smash and I have been communicating about about the PIR PDD
> > (docs/pdds/draft/pdd19_pir.pod). He has started it, and is continuing to
> > refine it
Greetins parrot people,
On 9/28/07, Allison Randal <[EMAIL PROTECTED]> wrote:
> Smash and I have been communicating about about the PIR PDD
> (docs/pdds/draft/pdd19_pir.pod). He has started it, and is continuing to
> refine it. Anyone is welcome to pitch in on that. He'll let me know when
> it's r
On Sun, Sep 30, 2007 at 10:20:51AM -0700, chromatic wrote:
> Maybe, depending on how portable it is. man 3 memchr here says that it
> conforms to SVr4, 4.3BSD, and C99. The latter concerns me slightly.
FreeBSD's man page says:
STANDARDS
The memchr() function conforms to ISO/IEC 9899:1990
23 matches
Mail list logo
