> > You can't predict when the last time a module is going to get used...
>
> I'm not suggesting you need to. I'm saying that, just as all
> UNITCHECKs are
> guaranteed to run before any main CHECK, we might want a UNITEND that's
> guaranteed to execute before any main END.
Perhaps this is one of
Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]> wrote:
> F doesn't test freezing and thawing strings or floats.
> Is this because the functionality hasn't been implemented yet?
Exactly. Sould be simple though. Please have a look at
classes/perlint.pmc (or such) that implement the freeze/thaw vtables
> >
> > "within reason". Thats where we're way off right now.
>
> Let's keep a bit of perspective here. The non-Parrot:: contents of lib
> accounts for only 4.6% of the non-ICU content (and only 1.5% if you
> count ICU in the total size). It's difficult to see that as
> unreasonable, or as "bl
Thank you!
All is ok,
but when "make test" - errors
occuring(attached to this message)
After this errors testing continues(some tests have
"okay" < 100%)
And then it hands-up on:
t/src/extendok 11/13
Is it ok for cygwin?
- Original Message -
From:
T
Thank you!
All is ok,
but when "make test" - errors
occuring(attached to this message)
After this errors testing continues(some tests have
"okay" < 100%)
And then it hands-up on:
t/src/extendok 11/13
Is it ok for cygwin?
- Original Message -
From:
T
Dmitry Nikolayev wrote:
Did Somebody try to assemble parrot on CygWin?
I tried...
perl configure.pl - ok
You'll need to use:
perl Configure.pl --define=inet_aton
make - and error ocured:
gcc -o parrot.exe -s -L/usr/local/lib -g imcc/main.o blib/lib/libparrot.a -lcrypt
blib/lib/libparrot.a(io
I figure it's about time for Parrot programs to be able to look at
Parrot's configuration, so I'm trying to implement a library equivalent
to Parrot::Config. My current thoughts on implementation involve three
elements:
1. A Configure step that writes and executes a Parrot program. Said
On Fri, Mar 05, 2004 at 04:17:12PM -0600, Rod Adams wrote:
> Given the fact that use of these blocks are overall quite rare, and
> potentially very confusing to the casual perl hacker who encounters one
> of them, I propose a rather different tact:
>
> BEGIN => EXECUTE_ON_PARSE
> CHECK => EXECUT
Did Somebody try to assemble parrot on CygWin?
I tried...
perl configure.pl - ok
make - and error ocured:
gcc -o parrot.exe -s -L/usr/local/lib -g imcc/main.o blib/lib/libparrot.a -lcrypt
blib/lib/libparrot.a(io_unix.o)(.text+0x8f7): In function `PIO_sockaddr_in':
/inst/parrot/io/io_unix.c:626
Larry asked:
And how would it differ from END?
Like CHECKs, ENDs execute in reverse order. Which generally means that main
END executes before module ENDs (unless we're careful to put our main END
before our module loads -- which is subtle and counterintuitive). Sometimes it
would be handy to
Damian Conway wrote in perl.perl6.language :
>
> I'd favour UNITCHECK and CHECK, mainly for the greater compatibility with
> Perl 5 and with software engineering jargon.
As far as Perl 5 is concerned, it appears that most people who write
CHECK mean UNITCHECK. Including you :)
> And because MAIN
Larry Wall wrote:
On Fri, Mar 05, 2004 at 06:45:58PM -, Rafael Garcia-Suarez wrote:
: Of course :) the main problem is not that CHECK blocks are executed
: late (just at the end of the compilation phase); it's that they're
: executed too early, notably in some persistent environment, notably
:
On Sat, Mar 06, 2004 at 08:47:25AM +1100, Damian Conway wrote:
: Does that imply a UNITEND as well?
Why would you want to unite North Dakota?
And how would it differ from END? You can't predict when the last
time a module is going to get used...
Larry
Larry wrote:
Anybody got opinions on the naming of these beasts? Certainly *not*
renaming CHECK is more compatible with Perl 5.
I'd favour UNITCHECK and CHECK, mainly for the greater compatibility with
Perl 5 and with software engineering jargon.
And because MAINCHECK is *ugly*. ;-)
So ugly th
Larry Wall wrote in perl.perl6.language :
>
> Possibly a CHECK block that is compiled after end of main compilation
> should translate itself to a UNITCHECK. But maybe it should be an error.
>
> But it's also possible that CHECK should mean "unit check", and
> there should be an explicit MAINCHE
On Fri, Mar 05, 2004 at 06:45:58PM -, Rafael Garcia-Suarez wrote:
: Of course :) the main problem is not that CHECK blocks are executed
: late (just at the end of the compilation phase); it's that they're
: executed too early, notably in some persistent environment, notably
: mod_perl (or mod_p
Larry Wall wrote in perl.perl6.language :
>: In perl 5 those blocks are executed at the
>: transition between the compilation and the execution phase *of the main
>: program*. This is convenient for some purposes (the O and B::* modules)
>: and inconvient for others (Attribute::Handlers, etc. etc.)
On Fri, Mar 05, 2004 at 01:57:40PM -, Rafael Garcia-Suarez wrote:
: While we're at it. Is there some precise definition of the CHECK/INIT
: blocks for perl 6 right now ?
Yes, the same precise definition as anything else we haven't defined yet:
"That works exactly the same as in Perl 5, until w
On Mar 4, 2004, at 2:48 PM, Arcady Goldmints (via RT) wrote:
A few tests are failing with JIT on powerpc linux, even though
everything
works perfectly fine without JIT. The tests in question are
t/op/integer.t 1 and 33, and t/op/stacks.t 1-5. These seem to have in
common the fact that they use al
On Mar 4, 2004, at 7:50 PM, Robert Spier wrote:
IMHO, the releases better include everything necessary to build the
application, within reason. Consistency and simplicity counts for a
lot.
Why create headaches we don't need?
"within reason". Thats where we're way off right now.
Let's keep a bit
Jens Rieks <[EMAIL PROTECTED]> wrote:
> Hi,
> The following code crashes parrot if run with -t (trace).
Some more notes:
- it happens with or w/o ARENA_DOD_FLAGS
- it happens with the copying GC or with --gc=libc
- it does not happen with DOD/GC disabled
- I did not find any breakage in e.g. ex
Larry Wall wrote in perl.perl6.language :
>
> In theory, yes, if you ask it to check in a CHECK block, and if you're
> willing for the check to assume that no eval or INIT block is going
> to supply the missing sub before it's actually called, and that no
> run-time code is going to alias the sub
On Thu, Mar 04, 2004 at 11:04:38PM +, Nigel Sandever wrote:
: On the basis of what is known so far, will p6 be able to detect
: undefined subs at compile time?
In theory, yes, if you ask it to check in a CHECK block, and if you're
willing for the check to assume that no eval or INIT block is
Jens Rieks <[EMAIL PROTECTED]> wrote:
> Hi,
> The following code crashes parrot if run with -t (trace).
> It seems to be due to an unused .param, see line marked with XXX.
The unused param doesn't harm. The problem is memory corruption very
likely due to the PIO_printf code inside trace.c (or st
Jens Rieks <[EMAIL PROTECTED]> wrote:
> the attached pasm code prints
>: A
>: error!
> instead of only "A" as expected.
The "__init" code is run in its own run loop. This may (as in your
example) have an "end" opcode, which is just the same as "invoke P1",
i.e. a return from the "__init" subrouti
Jerome Quelin wrote in perl.perl6.internals :
>
> But what should those addresses do when receiving a message?
> - parrotbug: should open a RT ticket?
> - status-ok: ?
> - status-nok: should open a RT ticket?
Excuse me from stepping in, but I don't see why three adresses are
necessary. From my (l
# New Ticket Created by Jens Rieks
# Please include the string: [perl #27418]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=27418 >
Hi,
the attached pasm code prints
: A
: error!
instead of only "A" as expected.
jens
On the basis of what is known so far, will p6 be able to detect undefined subs
at compile time?
Regards, Nigel.
# New Ticket Created by Arcady Goldmints
# Please include the string: [perl #27414]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=27414 >
A few tests are failing with JIT on powerpc linux, even though everything
works p
Robert Spier wrote:
> > The mails are indeed sent to parrotbug, parrotstatus-ok and
> > parrotstatus-nok (at parrotcode.org) for resp. bug reports, ok
> > reports or nok reports. And since I don't think those addresses are
> > set up...
> Not yet. I'm nudging Ask regularly about this.
But what sh
30 matches
Mail list logo
