Matt Fowles <[EMAIL PROTECTED]> wrote:
> Leo~
> Why bother with the IS_NULL check if we have the "n_" variant already?
> Why not have one option unconditionally use the destination pmc and
> the other unconditionally create a new destination pmc?
I think, we can just have one method with the sam
Chip Salzenberg wrote:
> 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 some
Chip Salzenberg wrote:
As for the autrijus/leo IRC event: Much of it seemed to be things that
autrijus Really Needed To Know, but which without context would not
likely make a good general informational message. If I'm wrong about
that, I invite autrijus or leo to summarize what was discussed
Chromatic <[EMAIL PROTECTED]> wrote:
> -(INTVAL)IGLOBALS_CLASSNAME_HASH, classname_hash);
> +(INTVAL)IGLOBALS_CLASSNAME_HASH, interpreter->class_hash);
Oouch. Good catch, thanks - applied.
leo
Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> According to Ron Blaschke:
>> - After I changed the linkage, some dynclasses failed, during access
>> of C. No surprise, as the array is only
>> C<#define PARROT_MAX_CLASSES 100>
>> long. After I changed it to 1000, the tests passed. Why gets no one
Cory Spencer <[EMAIL PROTECTED]> wrote:
> 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.
When I'm investigating GC bugs, the usual procedure is like this:
-
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
[ lazy.tgz ]
> Some experiments - might be quite wrong.
That might have been a bit too terse. In yesterday's IRC session,
Autrijus asked about another missing Parrot feature: lazy evaluation. I
had experimented with it a bit and the outcome is in the ta
# New Ticket Created by FranÃois PERRAD
# Please include the string: [perl #34605]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=34605 >
After Dan's response concerning "Parrot_Exec_OS_Command interface ?".
He says : Thi
According to Ron Blaschke:
> Chip Salzenberg wrote:
> > How many variables need to be exported currently? I'd consider it an
> > API feature if there were no exported variables whatsoever ...
>
> Let's see...
> Parrot_base_vtables
> pio_stdio_layer
> op_jit
> yyin
>
> I guess that's it.
That's
According to Leo Toetsch:
> Chip Salzenberg <[EMAIL PROTECTED]> 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 Th
Below inline attached is a scheme for an abstraction layer around
calling conventions.
Comments welcome,
leo
Parrot Calling Conventions
1) Rational
Calling conventions and opcodes (and of course the semantics of these)
define the ABI of the Parrot VM. Any change in the ABI creates
incompatibili
Jeff Horwitz <[EMAIL PROTECTED]> wrote:
> 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.
Steadily evolving, great.
> major changes include support for parrot 0.1.2 (phoenix), the beginnings
> of a thread-safe
Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> OK, no point in dividing that. It's been suggested to create a
> libparrotvm at some point, with PBC support but no imcc/pir/ast(?);
> but given our target languages, I don't see that it would get much
> usage...?
No eval-like functionality. OTOH it c
According to Leo Toetsch:
> Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> > It's been suggested to create a libparrotvm at some point, with
> > PBC support but no imcc/pir/ast(?); but given our target
> > languages, I don't see that it would get much usage...?
>
> No eval-like functionality. OTOH i
On Tue, 29 Mar 2005, Leopold Toetsch wrote:
> Jeff Horwitz <[EMAIL PROTECTED]> wrote:
> > 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.
>
> Steadily evolving, great.
>
> > major changes include support for
Leopold Toetsch wrote:
One thing still missing is to retrieve the current namespace inside a
subroutine, which will be in RSN, e.g.:
$P0 = interpinfo .INTERPINFO_CURRENT_NAMESPACE
Actually it is:
$P0 = interpinfo .INTERPINFO_CURRENT_SUB
ns = $P0."get_name_space"()
See the new tests in namespa
# New Ticket Created by FranÃois PERRAD
# Please include the string: [perl #34606]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=34606 >
With this small patch, parrot.exe is installed.
Today, the file MANIFEST.generated
Leopold Toetsch wrote:
Cory Spencer <[EMAIL PROTECTED]> wrote:
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.
Running valgrind (on supported platforms, obvious
Nick Glencross wrote:
The DOD certainly has a few things flagged up, which I'm going to
quickly investigate to see if they are serious or not...
I've learned alot about DOD since earlier (and watched telly). Not as
straightforward as I thought it would be to find if these traces should
be consid
Nick Glencross wrote:
I've learned alot about DOD since earlier (and watched telly). Not as
straightforward as I thought it would be to find if these traces should
be considered serious or not (I would say any logic based on unitialised
values will bite one day!).
Ok, now I understand. This is i
# New Ticket Created by Peter Sinnott
# Please include the string: [perl #34608]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=34608 >
Moving the declaration of s up to the top of the block so declarations
are grouped to
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Mon, 28 Mar 2005 11:27:58 +0200
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 additio
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
> +void freeze(visit_info *info) {
> +IMAGE_IO *io = info->image_io;
> +io->vtable->push_integer(INTERP, io, PMC_int_val(SELF));
> +STRING * s = string_from_cstring(INTERP, PMC_data(SELF),
> PMC_int_val2(SELF)/BITS
Peter Sinnott <[EMAIL PROTECTED]> wrote:
> Moving the declaration of s up to the top of the block so declarations
> are grouped together and gcc2.x is happy.
Thanks, applied.
leo
Bob Rogers <[EMAIL PROTECTED]> wrote:
> I guess I was hoping for access to a lower-level mechanism. FWIW,
> Common Lisp is an example of a dynamic HLL that doesn't allow certain
> ops to be overloaded (at least not directly).
Overloading is a syntactic construct that the compiler supports (or
no
Nick Glencross <[EMAIL PROTECTED]> wrote:
> Ok, now I understand. This is inspecting the C runtime stack (I think).
> The Interpreter remembers the bottom address, and then when the time
> comes, a routine runs the depth of the stack.
Yes. Exactly.
> The values on the stack are then checked whet
François" PERRAD <[EMAIL PROTECTED]> wrote:
> --- data.pl.orig 2005-02-21 11:56:08.0 +0100
> +++ data.pl 2005-03-19 11:53:30.0 +0100
^^^
Please provide one patch for #34605 and #34606, diffed from Parrot root
directory one directory outside, so that they can be ap
27 matches
Mail list logo
