Bob Rogers <[EMAIL PROTECTED]> wrote:
> IMHO, one can have too much overloading. It seems cleaner to
> distinguish between "+, the (sometimes overloaded) HLL operator" and
> "add, the Parrot addition operator" so that compiled code can opt out of
> the overloading when the compiler knows that it
Chromatic <[EMAIL PROTECTED]> wrote:
> The current CVS HEAD has failed for about a week or so at the point
> where Parrot tries to generate its configuration library.
Strange.
> (gdb) bt
> #0 0x100b74f0 in pobject_lives (interpreter=0x103ac910, obj=0x35)
> at src/dod.c:196
> #1 0x10278d7c
Bob Rogers <[EMAIL PROTECTED]> wrote:
> ... If the prefix is disabled via
> PARROT_TEST, this fixes the immediate problem:
> [EMAIL PROTECTED]> PARROT_TEST=1 perl -Ilib t/dynclass/foo.t
> 1..1
> ok 1 - abs
> [EMAIL PROTECTED]>
> But shouldn't "make test" do this by default? Oth
Matt Fowles <[EMAIL PROTECTED]> wrote:
> Leo~
> On Sun, 27 Mar 2005 16:37:41 +0200, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>> 5) infix method signature change:
>>
>>METHOD PMC* add( [INTERP, SELF,] PMC* rhs, PMC ´*dest) {
>> if (!dest)
>> dest = pmc_new(INTERP, SELF->vtable->b
Ron Blaschke <[EMAIL PROTECTED]> wrote:
> After
> Failed Test Stat Wstat Total Fail Failed List of Failed
> ---
> t\op\spawnw.t2 512 32 66.67% 2-3
Great.
[ ... the plan ]
> Comments are highly ap
Cory Spencer <[EMAIL PROTECTED]> wrote:
> ---354891615-125901741-966306=:18075
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
> I've been writing a Lisp implementation on top of Parrot for the last
> several months (and I'm just about at the point where I'm ready to unleash
> it
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> 5) infix method signature change:
>METHOD PMC* add( [INTERP, SELF,] PMC* rhs, PMC ´*dest) {
> if (!dest)
> dest = pmc_new(INTERP, SELF->vtable->base_type);
> ...
> return dest;
>}
> If the destination PMC is passed in, i
# New Ticket Created by Nick Glencross
# Please include the string: [perl #34592]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=34592 >
Folks,
This patch makes some small cosmetic changes to the md5 library, harness
and
Nick Glencross <[EMAIL PROTECTED]> wrote:
> This patch makes some small cosmetic changes to the md5 library, harness
> and tests (comments and formatting).
Thanks, applied.
leo
Matt Diephouse <[EMAIL PROTECTED]> wrote:
> This patch (a) adds comments before each subroutine describing its
> parameters, its return values, and what it does, and (b) allows
> unbalanced {} to be used inside of strings and comments in PMC code.
Thanks, applied.
leo
Leo~
On Mon, 28 Mar 2005 12:22:29 +0200, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>
> > 5) infix method signature change:
>
> >METHOD PMC* add( [INTERP, SELF,] PMC* rhs, PMC ´*dest) {
> > if (!dest)
> > dest = pmc_new(INTERP, SELF-
Some experiments - might be quite wrong.
leo
lazy.tgz
Description: GNU Unix tar archive
According to Ron Blaschke:
> - Parrot should be told during Configure to be built static
> or dynamic (shared); it should probably be dynamic on most systems
Yes.
> - The parrot library should be named C and
> C on Windows
OK, but will Windows allow delimiter(s) on the DLL name? Without
them,
mod_parrot 0.2 is now available from http://www.smashing.org/mod_parrot or
from SVN at http://svn.perl.org/parrot-modules/mod_parrot.
major changes include support for parrot 0.1.2 (phoenix), the beginnings
of a thread-safe interpreter pool, support for more apache hooks,
updated documentation, an
Quoting #parrot:
<@autrijus> when I say ".local pmc foo", what happens at INS?
< leo> nothing - that just declares the name "foo" being a P symbol
<@autrijus> and its scope is... .sub ?
< leo> yep, .sub / .end
<@autrijus> so there's no notion of lexical scopes?
<@autrijus>
Immediately after asking this:
> How is Perl 6 supposed to implement its idea of %MY:: if there's no
> lexical scoping other than in .subs, and there are no nested .subs?
... I read the *rest* of the IRC log, and ... well, let's just say I
feel a bit silly for not having read the whole transcript
Since #parrot has many Parrot people talking about Parroty things all
the time, it's been suggested that we log #parrot somewhere. The sad
thing about IRC logs, however, is that they're 99% dross and only 1%
precious metals. Of course that 1% is often uniquely valuable.
So I'd like to suggest th
Chip Salzenberg wrote:
> According to Ron Blaschke:
>> - The parrot library should be named C and
>> C on Windows
> OK, but will Windows allow delimiter(s) on the DLL name? Without
> them, there's an ambiguity (is "parrot110.dll" 1.10 or 11.0?).
> Also, Parrot release numbers currently have thr
At 04:08 PM 3/28/2005, Ron Blaschke wrote:
> On the one hand, IMCC doesn't really help you _run_ code, so I'm not
> inclined to see it part of libparrot. On the other hand, I haven't
> grokked the entire code base organization, so I could be Greatly
> Missing The Point.
> On the gripping hand, if
MrJoltCola wrote:
> At 04:08 PM 3/28/2005, Ron Blaschke wrote:
>> > On the one hand, IMCC doesn't really help you _run_ code, so I'm not
>> > inclined to see it part of libparrot. On the other hand, I haven't
>> > grokked the entire code base organization, so I could be Greatly
>> > Missing The Po
According to Ron Blaschke:
> The idea [of parrot01.dll] was mainly stolen from other projects,
> guess it's some sort of convention on Windows. [...] Adding all
> three parts, with dots, will work nicely, too, I guess.
That'd be great. If you get pushback from something that matters,
like an im
At 04:44 PM 3/28/2005, Ron Blaschke wrote:
MrJoltCola wrote:
> At 04:08 PM 3/28/2005, Ron Blaschke wrote:
>> > On the one hand, IMCC doesn't really help you _run_ code, so I'm not
>> > inclined to see it part of libparrot. On the other hand, I haven't
>> > grokked the entire code base organization
On Mon, 2005-03-28 at 11:42 +0200, Leopold Toetsch wrote:
> > (gdb) bt
> > #0 0x100b74f0 in pobject_lives (interpreter=0x103ac910, obj=0x35)
> > at src/dod.c:196
> > #1 0x10278d7c in Parrot_SArray_mark (interpreter=0x103ac910,
> > pmc=0x1056c540)
> > at classes/sarray.c:276
>
> At that
On Mon, 2005-03-28 at 17:41 -0800, chromatic wrote:
> It looks like the first element of interpreter->iglobals is wrong.
Obviously storing a null pointer in there doesn't help. Here's a patch
that fixes things for me.
Now gdb says:
Breakpoint 1, Parrot_SArray_mark (interpreter=0x103ac920,
pmc=
On Mon, 2005-03-28 at 17:41 -0800, chromatic wrote:
(apologies if this appears multiple times; I had the wrong address
earlier)
> It looks like the first element of interpreter->iglobals is wrong.
Obviously storing a null pointer in there doesn't help. Here's a patch
that fixes things for me.
I've come across another garbage collection/DOD issue that I'm trying to
solve (without much success) and would appreciate some tips/advice on how
to locate the source of the problem.
It appears (based on my tests) to cause strings to be marked as dead
objects before their time. It appears to
Leopold Toetsch wrote:
William Coleda <[EMAIL PROTECTED]> wrote:
When invoking a PIR-defined object from C, what's the proper call?
pmc_new ? (Does that handle class_init) ?
I don't understand the question. Do you want to instantiate an object?
If yes, just do the same as the respective opcodes
After a IRC meeting with Leo, I've outlined my roadmap of how to make the three
compiler backends in Pugs to work in concert to provide a much faster evaluator:
http://use.perl.org/~autrijus/journal/23890
Note that existing code in the Eval monad need not be rewritten; also
Pugs will still ru
28 matches
Mail list logo
