Fixed in r28763.
Thanks,
Jonathan
I'm attaching this bug report to an existing ticket (RT#56184) because
I believe they are in fact the same problem. But I think this
description may make the problem more clear.
Summary: Lexical access from immediate blocks in closures don't work.
Consider the following Perl 6 code:
sub f
After a hiatus of several months and a discussion with particle and
chromatic at YAPC, I have resumed work on testing of the Parrot
configuration step classes.
One of the benefits of this work is that it guarantees that there is >=
1 person who has actually looked at the code of each step class in
Hi Coke, Andrew, Chromatic,
I have not considered this branch as a candidate for research on the Parrot
GC, but had a look @ it. As it seems, it wouldn't be of much use as its
*quite* old.
Regards,
Senaka
On Sat, Jun 28, 2008 at 1:19 AM, Will Coleda via RT <
[EMAIL PROTECTED]> wrote:
> On Mon J
On Tue Jun 06 07:40:55 2006, leo wrote:
> It's easy to add 'invalide' code to .pmc files. E.g. I had defined:
>
> METHOD parent() {
> return PMC_pmc_val(SELF) ? PMC_pmc_val(SELF) : PMCNULL;
> }
>
> Due to the absence of a return value, the PMC compiler just ignores this
> 'method
On Tue May 13 05:21:32 2008, rurban wrote:
> 2008/5/13 Andrew Whitworth via RT [EMAIL PROTECTED]>:
> > is this ticket (#51944) resolved? I don't see any outstanding todo
> items
> > here that need to be considered further, and the submitted patch
> has
> > already been applied. Can we close this
On Mon Jun 09 17:13:42 2008, Whiteknight wrote:
> On Fri, Jun 6, 2008 at 11:36 PM, Will Coleda via RT
> <[EMAIL PROTECTED]> wrote:
> > On Tue Nov 27 14:08:00 2007, pmichaud wrote:
> >> Today we cleaned up a lot of the unused branches of the
> >> Parrot repository. One of the branches that remains
On Wed Mar 07 08:52:19 2007, acalpini wrote:
> Jerry Gay (via RT) ha scritto:
> > i suspect there's trouble with the platform-specific c/h files,
> given
> > the nature of the warnings during build. the configure/make output
> is
> > below.
> >
>
> the only relevant warning I see is:
>
> > config
On Fri, Jun 27, 2008 at 11:24 AM, chromatic <[EMAIL PROTECTED]> wrote:
>> @@ -877,6 +951,8 @@
>> PMC_sync(p)->owner = dest_interp;
>> }
>> else {
>> +/* XXX: This error-handling is bad, we should do
>> +
Minor update: instead of
void * unused
use
INTVAL unused
to avoid compiler warnings. =-)
--
Will "Coke" Coleda
On Friday 27 June 2008 06:22:02 [EMAIL PROTECTED] wrote:
> Modified:
>trunk/src/headers.c
>
> Log:
> [core] update function-level documentation in src/headers.c, add a few XXX
> notes concerning questions and suggestions I have.
>
> Modified: trunk/src/headers.c
> --- trunk/src/headers.c
On Thu Jun 26 22:21:22 2008, [EMAIL PROTECTED] wrote:
> On Thursday 26 June 2008 20:02:18 Will Coleda via RT wrote:
>
> > Attached, find a patch that allows us to specify a ":deprecated"
> flag (post
> > op, ala :flow). It also adds a new parrot warning (configurable with
> > warningson) level cal
# New Ticket Created by Klaas-Jan Stol
# Please include the string: [perl #56410]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=56410 >
without any internet connection at home you get really bored.
that means, time for so
Larry Wall wrote:
> On Thu, Jun 26, 2008 at 04:50:21PM +0200, Moritz Lenz wrote:
> : I assume that 'Num' is meant to be a non-complex.
> : Then it seems to make sense to assume:
> : Int is Rat
> : Rat is Num
> : Num is Complex
> : or am I off again?
>
> Well, there's this little thing called Lisko
Larry Wall wrote:
but probably what the financial insitutions
want is special fixed-point types that assume a divisor anyway.
Would any financial institution care to comment?
Some (VAT tax) computations are defined, by law, to be executed
with a cetain precision. You have to be able to contr
15 matches
Mail list logo
