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}{
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
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]
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 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
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
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
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 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 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 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
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
# 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.
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 "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
# 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
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
17 matches
Mail list logo
