Steve Fink:
# > > - Easy to forget to remove temporaries from the root set
# > > - Easy to double-anchor objects and forget to remove the
# temporary
# > >anchoring
# > > - longjmp() can bypass the unanchoring
# >
# > The temporary objects could be stored in a stack, which is
# popped whe
On Tue, 31 Dec 2002, Dan Sugalski wrote:
> >I don't think any ops do that presently (that would take a PMC** param).
> Oh, sure, lots do. Remember the ops get a pointer to the PMC
> register, which is itself a pointer. Whatever you stuff in there is
> what the register is set to.
Right, I meant P
On Dec-31, Jerome Vouillon wrote:
> On Mon, Dec 30, 2002 at 04:00:55PM -0800, Steve Fink wrote:
> > =head1 Solution 3: Explicity root set augmentation
> >
> > A final possible solution is to provide a mechanism to temporarily
> > anchor an otherwise unanchored object to the root set. (eg, have an
On Mon, Dec 30, 2002 at 11:09:07PM +, Jerome Quelin wrote:
> # New Ticket Created by Jerome Quelin
> # Please include the string: [perl #19610]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=19610 >
>
>
> Thanks to
Currently Parrot is picking up Perl's C compiler flags. Perl is quite
deliberately attempting to set -fno-strict-aliasing, to stop gcc using
ANSI's aliasing rules to infer possible optimisations; optimisations that
will actually break Perl's code.
(Don't ask me to remember exactly what the aliasin
At 9:30 AM -0500 12/31/02, Jim Cromie wrote:
Nicholas Clark wrote:
Admittedly my program may not be portable Ook! as it does assume that
cells wrap round from 255 to 0
The original brainfuck version worked fine on Leon's interpreter.
(I find Ook! too hard - I'm just another brainfuck monkey)
Ni
At 9:00 AM -0500 12/31/02, Jim Cromie wrote:
Dan Sugalski wrote:
You're looking to encode data in the low X bits (where X is 2 or 4
for 32 or 64 bit machines), right?
yes- precisely!
It's a clever thing to do, but one I admit I mistrust. Either it
means we have to check every pointer that mi
At 2:32 PM -0500 12/31/02, David Robins wrote:
On Tue, 31 Dec 2002, Dan Sugalski wrote:
At 1:29 PM -0500 12/31/02, David Robins wrote:
>Maybe I missed it in the original thread, but what was the
resolution on how
>to create and return a new PMC in PMC ops that take a "PMC* dest" param?
If
Nicholas Clark wrote:
Admittedly my program may not be portable Ook! as it does assume that
cells wrap round from 255 to 0
The original brainfuck version worked fine on Leon's interpreter.
(I find Ook! too hard - I'm just another brainfuck monkey)
Nicholas Clark
.
I hesitate to suggest (se
On Tue, 31 Dec 2002, Dan Sugalski wrote:
> At 1:29 PM -0500 12/31/02, David Robins wrote:
> >Maybe I missed it in the original thread, but what was the resolution on how
> >to create and return a new PMC in PMC ops that take a "PMC* dest" param?
>
> If the op defines the destination as getting a b
# New Ticket Created by Nicholas Clark
# Please include the string: [perl #19630]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=19630 >
I was seeing this:
Generating config.h...done.
Generating feature.h...done.
Writing P
Dan Sugalski wrote:
At 7:35 AM -0500 12/31/02, Jim Cromie wrote:
pardon the lack of clue I reveal here, but..
on 32 bit box, a void* has 3 values which are illegal/unaligned;
void* ptr;
if (ptr & 0x00) {
/* ok */
} else {
/* some exceptional situation */
}
is there any concievable use
On Tue, Dec 31, 2002 at 06:18:36PM +0100, Jerome Quelin wrote:
> Nice to see how dummy languages make the whole stuff advance... :o)
Then there's the zcode interpreter...
(dynamic opcode library loading, foreign bytecode translation)
Nicholas Clark
At 1:29 PM -0500 12/31/02, David Robins wrote:
Maybe I missed it in the original thread, but what was the resolution on how
to create and return a new PMC in PMC ops that take a "PMC* dest" param?
Should I submit my pmc_placement_new() (also in that thread) as a patch?
(morph isn't sufficient beca
Maybe I missed it in the original thread, but what was the resolution on how
to create and return a new PMC in PMC ops that take a "PMC* dest" param?
Should I submit my pmc_placement_new() (also in that thread) as a patch?
(morph isn't sufficient because I don't want to coerce the destination into
On Tue, 31 Dec 2002, Jim Cromie wrote:
> pardon the lack of clue I reveal here, but..
>
> on 32 bit box, a void* has 3 values which are illegal/unaligned;
>
> void* ptr;
> if (ptr & 0x00) {
ITYM if(!(ptr & 0x3))
> /* ok */
> } else {
> /* some exceptional situation */
> }
> is there any
At 12:49 PM -0500 12/31/02, Dan Sugalski wrote:
At 6:18 PM +0100 12/31/02, Jerome Quelin wrote:
Leopold Toetsch wrote:
> - currently I'm just printing on stdout the resulting parrot code,
> I lack an eval instruction in Parrot. Dan, Leo? :-)
Here is the solution of our perl6 bootstrapping pr
At 7:35 AM -0500 12/31/02, Jim Cromie wrote:
pardon the lack of clue I reveal here, but..
on 32 bit box, a void* has 3 values which are illegal/unaligned;
void* ptr;
if (ptr & 0x00) {
/* ok */
} else {
/* some exceptional situation */
}
is there any concievable use of this which doesnt i
[EMAIL PROTECTED] (Jerome Quelin) writes:
> Thanks to our dear summarizer, I'm now known (from a googlism point of
> view) as 'one of the "let's implement a bunch of languages on parrot"
> crew'. So, in order to prove him right definitely (and also because
> orang-utans should also benefit from
At 6:18 PM +0100 12/31/02, Jerome Quelin wrote:
Leopold Toetsch wrote:
> - currently I'm just printing on stdout the resulting parrot code,
> I lack an eval instruction in Parrot. Dan, Leo? :-)
Here is the solution of our perl6 bootstrapping problem, I'll make an
I ops ...
Nice to see how
At 6:17 PM +0100 12/30/02, Leopold Toetsch wrote:
Dan Sugalski wrote:
At 11:45 AM +0100 12/30/02, Leopold Toetsch wrote:
A "simple" PMC would be a typical scalar (num or int) without
properties. Attaching properties to such a PMC would need
promoting it to a "complex" PMC.
We can't promote
pardon the lack of clue I reveal here, but..
on 32 bit box, a void* has 3 values which are illegal/unaligned;
void* ptr;
if (ptr & 0x00) {
/* ok */
} else {
/* some exceptional situation */
}
is there any concievable use of this which doesnt interfere with
legitimate bus-errors (ie exi
Leopold Toetsch wrote:
> > - currently I'm just printing on stdout the resulting parrot code,
> > I lack an eval instruction in Parrot. Dan, Leo? :-)
> Here is the solution of our perl6 bootstrapping problem, I'll make an
> I ops ...
Nice to see how dummy languages make the whole stuff advance...
# New Ticket Created by Jerome Quelin
# Please include the string: [perl #19626]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=19626 >
> Because what I said I'd really like (apart from "moon on a stick",
> "a new apocalyps
On Monday 30 December 2002 21:30, Leopold Toetsch wrote:
> Jerome Quelin (via RT) wrote:
> > # New Ticket Created by Jerome Quelin
> > # Please include the string: [perl #19610]
> > # in the subject line of all future correspondence about this issue.
> > # http://rt.perl.org/rt2/Ticket/Display.ht
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #19622]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=19622 >
I did write:
[1] which BTW seems bogus to me: pool_compact() may be called (when
th
On Mon, Dec 30, 2002 at 04:00:55PM -0800, Steve Fink wrote:
> =head1 Solution 3: Explicity root set augmentation
>
> A final possible solution is to provide a mechanism to temporarily
> anchor an otherwise unanchored object to the root set. (eg, have an
> array of objects associated with the inter
On a minor note, re
CALL_VTABLE_0(meth, interp, pmc)
CALL_VTABLE_1(meth, interp, pmc, arg1)
CALL_VTABLE_2(meth, interp, pmc, arg1, arg2)
I suggest reordering arguments to
CALL_VTABLE_1(interp, meth, pmc, arg1)
or CALL_VTABLE_1(interp, pmc, meth, arg1)
Current parrot apis seem to all
Regards
base_vtable ... name, type, ...
var_vtable ... get_integer, set_integer, ...
val_vtable ... add, sub, ...
prop_vtable ... property functions (set/getprop are different, depending
on the existence of the property hash)
I think this might rephrase as
obj
Mitchell N Charity wrote:
I think this might rephrase as
object contains:
- object core
- properties
- customizations of object
- customizations of value
- obj core
- properties
- variable access
- value manipulation
[ - methods ]
Ok, it sounds like the motivation for
Mitchell N Charity wrote:
On a minor note, re
CALL_VTABLE_0(meth, interp, pmc)
CALL_VTABLE_1(meth, interp, pmc, arg1)
CALL_VTABLE_2(meth, interp, pmc, arg1, arg2)
I suggest reordering arguments to
CALL_VTABLE_1(interp, meth, pmc, arg1)
or CALL_VTABLE_1(interp, pmc, meth, arg1)
Cur
Steve Fink wrote:
... So I decided to summarize the various approaches in
hopes that something will jump out at someone.
Great document, thanks for all the work of summarizing this.
(2) point out what's wrong with my "variant 5: generational
stack",
I think, it moves the problems
Just so everyone doesn't have to go digging through the archives...
Here are links to the postings, and some extracts which seemed to
provide context for the current thread.
http://nntp.x.perl.org/group/perl.perl6.internals/12804
http://nntp.x.perl.org/group/perl.perl6.internals/12809
http://nntp
Nicholas Clark sent the following bits through the ether:
> This is possibly a big stuff wish list. I'm not sure how many are on the "maybe
> never" list.
I'm a bear of very little brain, errr, a man of few wishes. I wish for:
o objects
o a "make install" which does something sensible
Leo
34 matches
Mail list logo
