The cancellation behavior makes no sense to me. I expect ?one(0, 1,
2, 2) to return false. That happens whether or not it collapses the
2's to one 2, but not if it ignores/cancels them.
The question is, what should ?one(0, 1, 1) return? I think it's
pretty clearly false, which implies that junc
# New Ticket Created by Brad Bowman
# Please include the string: [perl #60530]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60530 >
Hello,
I tried the first example in docs/embed.pod but it needed a few
tweaks to get run
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #60528]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60528 >
Rakudo r32629 sometimes dies when assigning a readonly variable to
itself, and sometimes
On Thu, Nov 13, 2008 at 03:21:45PM -0800, Carl Mäsak wrote:
> Rakudo r32629 sometimes dies when assigning a readonly variable to
> itself, and sometimes not.
>
> $ ./perl6 -e 'for -> $foo { $foo = $foo; say $foo }' # dies, good
> Cannot assign to readonly variable.
> [...]
>
> $ ./perl6 -e 'for
# New Ticket Created by Will Coleda
# Please include the string: [perl #60540]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=60540 >
This tcl code (a snippet from the official tcl test suite) runs out of
memory on partcl.
HaloO
Jon Lang wrote:
Larry Wall wrote:
eqv and === autothread just like any other comparisons. If you really
want to compare the contents of two junctions, you have to use the
results of some magical .eigenmumble method to return the contents
as a non-junction. Possibly stringification will
On Thu, Nov 13, 2008 at 07:19:31PM -0600, Patrick R. Michaud wrote:
: S06:2362 says:
:
: You can get the current routine name by calling C<&?ROUTINE.name>.
: (The outermost routine at a file-scoped compilation unit is always
: named C<&MAIN> in the file's package.)
:
: Is this the sam
On Thu, 13 Nov 2008, chromatic wrote:
> On Monday 03 November 2008 09:38:11 Andy Dougherty wrote:
>
> > > 3. 1 of the tests appears to fail depending on how the OS initial-
> > > cases 'Inf'. Again, could this be addressed in a hints file?
> >
> > This too is a long-standing problem: See [perl
On 2008 Nov 14, at 12:14, Larry Wall wrote:
On Thu, Nov 13, 2008 at 07:19:31PM -0600, Patrick R. Michaud wrote:
: S06:2362 says:
:
: You can get the current routine name by calling C<&?
ROUTINE.name>.
: (The outermost routine at a file-scoped compilation unit is
always
: named C<&
On Fri, Nov 14, 2008 at 01:50:59PM -0500, Brandon S. Allbery KF8NH wrote:
> WHat *is* the outermost scope in that case? When is code in that scope
> executed? I could see this as being a hack to allow a module to be used
> either directly as a main, or "use"d; the former ignoring top level scop
On Fri, Nov 14, 2008 at 2:42 PM, Bernhard Schmalhofer via RT
<[EMAIL PROTECTED]> wrote:
> On Mo. 16. Jun. 2008, 16:50:13, coke wrote:
>> On Wed Jan 16 03:41:56 2008, [EMAIL PROTECTED] wrote:
>> > While the fix to my particular problem is simple enough, it is
>> apparent
>> > that there's enough bit
Dave has left a new comment on your post "Register allocation in a PIR
compiler":
Hope you don't mind if I mention a couple of points. Presumably
these "freed" registers are being spilled to memory, meaning that they
are assigned to a stack location. I don't see how that can be a benefit
if the vi
Author: coke
Date: Fri Nov 14 13:21:29 2008
New Revision: 32647
Modified:
trunk/docs/pdds/pdd19_pir.pod
Changes in other areas also in this revision:
Modified:
trunk/DEPRECATED.pod
trunk/compilers/imcc/imcc.l
trunk/compilers/imcc/imclexer.c
trunk/t/compilers/imcc/syn/regressions.t
Sex, 2008-11-14 às 09:14 -0800, Larry Wall escreveu:
> That's correct. We could fix it two ways. Either the mainline code
> gets a consistent new name, or the outermost scope is redefined to an INIT
> if there is a user-defined MAIN. I can argue it both ways.
I'd argue that there's an implicit
Author: coke
Date: Fri Nov 14 15:38:08 2008
New Revision: 32651
Modified:
trunk/docs/pdds/pdd19_pir.pod
Changes in other areas also in this revision:
Modified:
trunk/DEPRECATED.pod
trunk/compilers/imcc/imcc.y
trunk/compilers/imcc/imcparser.c
Log:
Resolve RT#57432, remove [DEPRECATED]
Author: coke
Date: Fri Nov 14 16:33:41 2008
New Revision: 32652
Modified:
trunk/docs/pdds/pdd19_pir.pod
Changes in other areas also in this revision:
Modified:
trunk/DEPRECATED.pod
trunk/compilers/imcc/imcc.y
trunk/compilers/imcc/imcparser.c
trunk/languages/dotnet/build/builtins.pl
On Friday 14 November 2008 18:13:48 Will Coleda via RT wrote:
> Here's a very simple patch:
>
> Index: imcc.l
> =
> ==
> --- imcc.l (revision 32647)
> +++ imcc.l (working copy)
> @@ -305,7 +305,12 @@
>
>
> <*>[ISNP]{DIGIT}{
17 matches
Mail list logo
