On Fri, 17 Oct 2003, Adam Thomason wrote:
> # New Ticket Created by "Adam Thomason"
> # Please include the string: [perl #24239]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=24239 >
>
> Two issues while building parr
On Fri, Oct 17, 2003 at 06:13:24PM -0600, Jim Cromie wrote:
>
> 1st the PatchMonster, now the Pumpking.
> we watch in awe as the World Domination Plan unfolds.
>
> whats next, the WhiteHouse ?
Schwarzenegger, now Tötsch... there is a pattern here, but AEIOU
is more ambitious than merely occupyi
# New Ticket Created by "Adam Thomason"
# Please include the string: [perl #24239]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=24239 >
Two issues while building parrot on OpenBSD 3.3/i386:
* arpa/inet.h doesn't include
On Fri, 17 Oct 2003, Jim Cromie wrote:
> Dan Sugalski wrote:
>
> >Hey folks.
> >
> >It's that time of year again, when the patch pumpkin passes paws. Hands,
> >rather. Steve Fink now joins the ranks of Parrot Pumpkings Emeritus,
> >having shepherded a number of releases out the door. We wish him
Dan Sugalski wrote:
Hey folks.
It's that time of year again, when the patch pumpkin passes paws. Hands,
rather. Steve Fink now joins the ranks of Parrot Pumpkings Emeritus,
having shepherded a number of releases out the door. We wish him a happy
retirement and hope the nervous twitches stop soon.
On Fri, 17 Oct 2003, Simon Glover wrote:
>
> How do we create a Parrot_STRING in an extension? Parrot_Ints
> and Parrot_Floats are easy, since they're just declarations, and
> for PMCs there's Parrot_PMC_new, but there doesn't appear to be
> an equivalent for strings.
We don't yet -- it's an
How do we create a Parrot_STRING in an extension? Parrot_Ints
and Parrot_Floats are easy, since they're just declarations, and
for PMCs there's Parrot_PMC_new, but there doesn't appear to be
an equivalent for strings.
Simon
On Fri, 17 Oct 2003, Simon Glover wrote:
>
> On Fri, 17 Oct 2003, Dan Sugalski wrote:
>
> > On Fri, 17 Oct 2003, Simon Glover wrote:
> >
> > >
> > > What, if any, validation of their input should the register access
> > > functions in the extension API do? Currently, they don't do any,
> > > wh
On Fri, 17 Oct 2003, Dan Sugalski wrote:
> On Fri, 17 Oct 2003, Simon Glover wrote:
>
> >
> > What, if any, validation of their input should the register access
> > functions in the extension API do? Currently, they don't do any,
> > which means that you can create a buffer overflow simply by
On Fri, 17 Oct 2003, Simon Glover wrote:
>
> What, if any, validation of their input should the register access
> functions in the extension API do? Currently, they don't do any,
> which means that you can create a buffer overflow simply by using
> a register number >31 or <0; eg,
>
>Parro
What, if any, validation of their input should the register access
functions in the extension API do? Currently, they don't do any,
which means that you can create a buffer overflow simply by using
a register number >31 or <0; eg,
Parrot_set_intreg(interpreter, 1, 100);
reli
Dan Sugalski <[EMAIL PROTECTED]> writes:
> On Fri, 17 Oct 2003, Leopold Toetsch wrote:
>
> > Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >
> > > Put them *back*, please, unless you're going to fix core.pm.
> >
> > Done. op2pm.pl now has the renumbering. Its simpler and cleaner.
> >
> > Now, that 12
Hey folks.
It's that time of year again, when the patch pumpkin passes paws. Hands,
rather. Steve Fink now joins the ranks of Parrot Pumpkings Emeritus,
having shepherded a number of releases out the door. We wish him a happy
retirement and hope the nervous twitches stop soon.
Replacing him as th
On Fri, 17 Oct 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > Put them *back*, please, unless you're going to fix core.pm.
>
> Done. op2pm.pl now has the renumbering. Its simpler and cleaner.
>
> Now, that 1237 opcodes are fixed numbered, shall we remove the
> finger-
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Put them *back*, please, unless you're going to fix core.pm.
Done. op2pm.pl now has the renumbering. Its simpler and cleaner.
Now, that 1237 opcodes are fixed numbered, shall we remove the
finger-printing? Currently we just don't read PBCs, when the
fing
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Juergen Boemmels <[EMAIL PROTECTED]> wrote:
>
> > Have a small number of _real_ core.ops which have fixed assigned
> > numbers below say 256.
>
> The problem with this approach is the JIT/EXEC subsystem. Dynamically
> loaded oplibs and JIT don't play
At 02:49 PM 10/17/2003 +0200, Leopold Toetsch wrote:
Melvin Smith <[EMAIL PROTECTED]> wrote:
> I've asked this before: Please, someone give me an example
> where a dynamic opcode lib gives us something
> that a well designed set of core ops and an extension
> interface does not.
Can you explain th
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> On Fri, 17 Oct 2003, Leopold Toetsch wrote:
>> *If* we renumber opcodes, then lib/Parrot/OpLib/core.pm should be sorted.
>> This file is the base (and holds the numbering) of all utilities using
>> ops. When this file is ordered to our needs, *no* other ch
PIR next phase plans:
(Note: I'd prefer to stay away from AST discussion here, I'm aware that we
eventually wish to pass AST directly to IMCC, but I'd like to shelve
that for
a different thread)
1. .class, .field and .method directive support
These will have to change the packfile forma
On Fri, 17 Oct 2003, Leopold Toetsch wrote:
> Juergen Boemmels <[EMAIL PROTECTED]> wrote:
>
> > Have a small number of _real_ core.ops which have fixed assigned
> > numbers below say 256.
>
> The problem with this approach is the JIT/EXEC subsystem. Dynamically
> loaded oplibs and JIT don't play t
Melvin Smith <[EMAIL PROTECTED]> wrote:
> I've asked this before: Please, someone give me an example
> where a dynamic opcode lib gives us something
> that a well designed set of core ops and an extension
> interface does not.
Can you explain the difference? Dynamic opcode libraries are extension
Juergen Boemmels <[EMAIL PROTECTED]> wrote:
> Have a small number of _real_ core.ops which have fixed assigned
> numbers below say 256.
The problem with this approach is the JIT/EXEC subsystem. Dynamically
loaded oplibs and JIT don't play together. To make this work, it would
need probably a tota
On Fri, 17 Oct 2003, Melvin Smith wrote:
> At 08:55 AM 10/17/2003 -0400, Dan Sugalski wrote:
> >On Fri, 17 Oct 2003, Juergen Boemmels wrote:
> >
> > > Why not this way:
> > >
> > > Have a small number of _real_ core.ops which have fixed assigned
> > > numbers below say 256. This ops never change d
On Fri, 17 Oct 2003, Melvin Smith wrote:
> At 12:53 PM 10/17/2003 +0200, Juergen Boemmels wrote:
> >Robert Spier <[EMAIL PROTECTED]> writes:
> >
> > > > The goals are to assign permanent numbers to the opcodes. What the
> > > > numbers are is generally irrelevant, but they must be constant across
At 08:55 AM 10/17/2003 -0400, Dan Sugalski wrote:
On Fri, 17 Oct 2003, Juergen Boemmels wrote:
> Why not this way:
>
> Have a small number of _real_ core.ops which have fixed assigned
> numbers below say 256. This ops never change during the lifetime of
> parrot. All other libs are inited (not nec
On Fri, 17 Oct 2003, Juergen Boemmels wrote:
> Why not this way:
>
> Have a small number of _real_ core.ops which have fixed assigned
> numbers below say 256. This ops never change during the lifetime of
> parrot. All other libs are inited (not necessary loaded) at byte-code
> loadtime. The byteco
On Fri, 17 Oct 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 1:07 AM +0200 10/17/03, Leopold Toetsch wrote:
> >>
> >>I don't know yet, what are the goals of this patch. There is not any
> >>sign in the list, that ops should be numbered like that and so on ...
>
> >
On Thu, 16 Oct 2003, Robert Spier wrote:
> > The goals are to assign permanent numbers to the opcodes. What the
> > numbers are is generally irrelevant, but they must be constant across
> > all systems for the lifetime of parrot.
>
> At first glance, gut reaction, that seems "really hard"(tm) and
At 12:53 PM 10/17/2003 +0200, Juergen Boemmels wrote:
Robert Spier <[EMAIL PROTECTED]> writes:
> > The goals are to assign permanent numbers to the opcodes. What the
> > numbers are is generally irrelevant, but they must be constant across
> > all systems for the lifetime of parrot.
>
> At first g
Robert Spier <[EMAIL PROTECTED]> writes:
> > The goals are to assign permanent numbers to the opcodes. What the
> > numbers are is generally irrelevant, but they must be constant across
> > all systems for the lifetime of parrot.
>
> At first glance, gut reaction, that seems "really hard"(tm) a
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 1:07 AM +0200 10/17/03, Leopold Toetsch wrote:
>>
>>I don't know yet, what are the goals of this patch. There is not any
>>sign in the list, that ops should be numbered like that and so on ...
> The goals are to assign permanent numbers to the opcodes.
31 matches
Mail list logo
