> At 6:16 PM -0400 8/20/02, John Porter wrote:
> >Dan Sugalski wrote:
> >> I expect a UINTVAL should be sufficient to hold the counter.
> >
> >Why? Because you don't expect a perl process to run longer
> >than a couple hours? Or because rollover won't matter?
>
> Rollover won't really matter mu
> I have a clean version that's up to date, and as everybody seems to
> be happy with it I'm going to go ahead and commit it now.
Ah-ha! I found a showstopper! Oh, it's a little late for that, isn't it?
:)
Anyways, cd to languages/BASIC, run basic.pl, type "LOAD wumpus", and
watch it die on "Not
> This adds logical shift right opcodes. They are essential for bit shifting
> negative values without sign extension getting in the way.
Applied, thanks.
Mike Lambert
This is what you'll need. It uses dlopen(), and is likely Bad in a number
of other ways, but if you're on a fairly normal UNIX, it should allow imcc
to grok what P6C produces for regexes.
/s
? languages/imcc/a.out
? languages/imcc/anyop.c
? languages/imcc/anyop.h
? languages/imcc/a.pasm
?
I just put a rough cut at them in CVS. To actually use them, you'll need
to apply a rather brutal patch/hack to IMCC, which I'll post to the list
shortly. This does not use Jeff's grammar -- I wanted to get what I had
into CVS before taking a look at that. Enjoy,
/s
The subject pretty much says it all. The format pretty much corresponds
to the upcoming Exegesis. Major changes were to the modifiers, and a few
syntax changes in the depths.
Sean, feel free to take what you can use (if anything) from this and
delete the rest.
--
Jeff <[EMAIL PROTECTED]>
On Sun, 2002-08-18 at 18:53, Brent Dax wrote:
> # And do we need a RFC like definition of should/may/must/mustn't?
>
> If so, I'd suggest the definition be patched into PDD0, so it's shared
> by all PDDs instead of repeating the definitions everywhere.
Noted.
--
Bryan C. Warnock
bwarnock@(gtem
At 6:16 PM -0400 8/20/02, John Porter wrote:
>Dan Sugalski wrote:
>> I expect a UINTVAL should be sufficient to hold the counter.
>
>Why? Because you don't expect a perl process to run longer
>than a couple hours? Or because rollover won't matter?
Rollover won't really matter much, if we're ca
Dan Sugalski wrote:
> I expect a UINTVAL should be sufficient to hold the counter.
Why? Because you don't expect a perl process to run longer
than a couple hours? Or because rollover won't matter?
--
John Douglas Porter
On Tue, Aug 20, 2002 at 09:12:36PM +0200, Leopold Toetsch wrote:
> Leopold Toetsch (via RT) wrote:
>
> >attached patch uses now a similar startup code for native compiled
> >programs like test_main.c.
>
> Rediffed and additional patch to compile natively .pasm containing keyed
> access (pack_k
On Tue, Aug 20, 2002 at 07:39:28PM +0200, Leopold Toetsch wrote:
>
> Dunno, how expensive getBucket is, but wouldn't it be faster, to check,
> if a GC run was actually done, and only then recalculate the pointers?
> This would apply too similar operations (clone ...) too.
Probably not worth it.
Would it make people's lives easier and potentially faster if we
added a GC_GENERATION field to the interpreter, one we increment
every time we do a GC or DOD run? I expect a UINTVAL should be
sufficient to hold the counter.
This way things that might have to do pointer recalcs or whatever can
Jason Gloudon (via RT) wrote:
>
> find_bucket as writen is GC-unsafe. This patch corrects this, by not reusing
> old values of bucket pointers across calls to string_compare, which can invoke
> compaction, causing the bucket to move.
Dunno, how expensive getBucket is, but wouldn't it be faster
Hi,
Attached shell script (for systems with a shell) runs all parrot tests
natively compiled either static or shared.
It uses the perl6 driver for this, which has (since I ran out of disc
space first ;-) an explicit option to delete the ~2MB static executables
after successful tests.
(perl6
Leopold Toetsch (via RT) wrote:
> attached patch uses now a similar startup code for native compiled
> programs like test_main.c.
Rediffed and additional patch to compile natively .pasm containing keyed
access (pack_key was not export in lib/Parrot/Types.pm).
please apply,
leo
--- Types
# New Ticket Created by Jason Gloudon
# Please include the string: [perl #16670]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=16670 >
find_bucket as writen is GC-unsafe. This patch corrects this, by not reusing
old valu
Explained far more throughly at http://pike.ida.liu.se/ than I can in an
e-mail.
It really looks like an intriguing language, with a (supposedly) very
fast runtime, (again, supposedly) beating Perl, Python, Tcl, and Java in
execution times. Unfortunately I've been unable to get it to compile
Just replying to [EMAIL PROTECTED] does not seem to
forward to the list. Ok, here once again to perl6-internals
Mike Lambert (via RT) <[EMAIL PROTECTED]> writes:
> Looking at the patch, it seems rather GCC-specific. The checking for
> "no-X" versus "X" in the warnings flags seems to be rather no
Chris Dutton wrote:
> Maybe I'm just doing something wrong...
> Then when I try to run perl6, via "perl perl6" to avoid @INC issues, I get:
>
> "Code must live with a function"
>
> Trying to compile hw.p6.
What does hw.p6 look like? Anyways:
sub main() {
# your code goes here
my $a
19 matches
Mail list logo
