# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #22337]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=22337 >
The next stage for getting faster DOD runs:
The relevant DOD flags are moved into an
>Small PMC (SPMC), a half sized PMC has double performance in stress.pasm
[...]
Ah, this again. :)
Perhaps it is time to get "multiple gc regimes can coexist" working?
Though having this capability is IMHO a Right Thing(tm) long-term,
I had been thinking of it as a task for a later time.
# New Ticket Created by Simon Glover
# Please include the string: [perl #22343]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=22343 >
Currently, if you're in the debugger, and do anything that causes an
internal_excepti
Bill Atkins <[EMAIL PROTECTED]> wrote:
> Am I correct in assuming that Parrot's JIT will eventually be able to produce
> directly-executable files, like .exe's?
Probably not via the JIT. The current approach (pbc2c.pl: producing a .c
source from bytecode) seems more general. This still needs some
Bryan C. Warnock <[EMAIL PROTECTED]> wrote:
> Is there is reason not to s/\.constant/.const/g for consistency's sake?
The difference is, that PASM did define an untyped variant:
.constant FOO 42
PIR Syntax is:
.const int FOO = 42
I'm ok with tossing the PASM variant, its barely used (only
Mitchell N Charity <[EMAIL PROTECTED]> wrote:
> Perhaps it is time to get "multiple gc regimes can coexist" working?
Sounds good, but AFAIK doesn't work - or isn't practical. I can only
imagine to have some #defines in place, to switch/test different
schemes, as currently LEA allocator.
> In add
