Mark Sparshatt wrote:
From the description in PDD15 I'm not sure how to hand languages where
a class is also an object. Where Foo is an instance of Foo' which is an
instance of Class.
Could this be handled during compilation?
The compiler could produce the classes Foo and Foo' and use something
Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]> wrote:
> Comments welcome on any part of this whole scheme.
I really like the cleanup. But the whole scheme needs more steps: That's
mainly probing for much more items, e.g. threads, signals, socket
stuff, which isn't quite simple. You first have to de
Arthur Bergman <[EMAIL PROTECTED]> wrote:
> On 12 Mar 2004, at 19:26, Leopold Toetsch wrote:
>> ... When this stack limit isn't set, stack walking can not be done
>> and all PMCs in hardware CPU registers and on the stack are missed,
>> which normally leads to ugly DOD bugs - they are really hard
Jens Rieks <[EMAIL PROTECTED]> wrote:
> Hi,
> .namespace ["Source"]
> .sub open method
> .pcc_begin_return
> .pcc_end_return
> .end
> fails with
> error:imcc:parse error, unexpected PARROT_OP, expecting IDENTIFIER
Parrot opcode names are basically reserved words. There are some
exceptions, where
At 10:22 PM + 3/12/04, Mark Sparshatt wrote:
Hi,
I've been reading PDD15. It seems that if the object foo is an
instance of the class Foo then foo is a ParrotObject pmc and Foo is
a ParrotClass pmc.
From the description in PDD15 I'm not sure how to hand languages
where a class is also an o
Okay, I was going to wait till I finished, but with Real Life
interfering as it has the last couple days, I'd like to get something
out on the list for Piers to link to. ;^)
I've made some fairly significant changes to Configure in the last week
or so. Starting from the top:
1. If you aut
Okay, so I'm fiddling around in the guts of the object system getting
the groundwork laid for some speed increases (I hope--we're just
barely faster than perl 5 when doing the equivalent of perl's tie
with the base object type) and one thing occurred--should we have the
base object system parti
Hi,
another day, another bug... :-)
$ tar xzf err4.tgz
$ cd err4
$ ../parrot main.imc
main.imc: calling method readFile...
get_string() not implemented in class 'SArray'
I can not see whats wrong with it. It works only if the called method
does not use ".param"...
jens
err4.tgz
Description: a
Hi,
.namespace ["Source"]
.sub open method
.pcc_begin_return
.pcc_end_return
.end
fails with
error:imcc:parse error, unexpected PARROT_OP, expecting IDENTIFIER
jens
Hi,
I've been reading PDD15. It seems that if the object foo is an instance
of the class Foo then foo is a ParrotObject pmc and Foo is a ParrotClass
pmc.
From the description in PDD15 I'm not sure how to hand languages where
a class is also an object. Where Foo is an instance of Foo' which is
Matt Greenwood wrote:
> Firstly, you have made an assumption that the addition here is
> equivalent to OR and carry, which may be correct for certain
> representations of integral datatypes, but certainly isn't for any
> kind of floating point arithmetic that I know of.
True enough, but I think I g
On 12 Mar 2004, at 19:26, Leopold Toetsch wrote:
Nicholas Clark <[EMAIL PROTECTED]> wrote:
On Thu, Mar 11, 2004 at 10:33:24PM +0100, Leopold Toetsch wrote:
All PMCs are anchored properly?
Yes. Arthur and I got it down to the appended test case, which is
pure C
embedding and extending parrot.
I a
At 8:34 PM +0100 3/12/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
... (Though arguably
anything you make a method call on really is an object :)
or a class.
Well... only because classes are objects. Or objects are classes.
Possibly both, this OO stuff confuses me sometimes
Steve Fink <[EMAIL PROTECTED]> wrote:
> The attached patch should remove all of the conflicts, and replace
> them with a single shift/reduce conflict that appears to be a bug in
> the actual grammar, namely:
> x = x . x
Ah yes. Or course, Thanks a lot, applied.
leo
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 11, 2004 at 10:33:24PM +0100, Leopold Toetsch wrote:
>> All PMCs are anchored properly?
> Yes. Arthur and I got it down to the appended test case, which is pure C
> embedding and extending parrot.
I already had mailed earlier with Arthur abo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> ... (Though arguably
> anything you make a method call on really is an object :)
or a class.
leo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 8:27 AM +0100 3/12/04, Leopold Toetsch wrote:
>>
>>@LOAD or other pragmas are only evaluated on the first statement of a
>>compilation unit. Branching inmidst some code isn't supported.
>>It's not likely that this will get changed.
> We need to fix that
> How, exactly, is taking two strings, making a third string that's big
> enough to contain both, and copying the contents of those two strings
> into the third one like taking two numbers, doing a binary OR with
> carry, and storing the result in a third number?
Firstly, you have made an assumpti
At 6:14 PM + 3/12/04, Peter Haworth wrote:
I have some issues with the way attributes are referenced. According to the
PDD:
classoffset Ix, Py, Sz
Returns the offset of the first attribute for class Sz in object Py.
getattribute Px, Py, Iz
Returns attribute Iz of object Py and puts i
Matt Greenwood wrote:
> why have both concat and
> add...?
How, exactly, is taking two strings, making a third string that's big
enough to contain both, and copying the contents of those two strings
into the third one like taking two numbers, doing a binary OR with
carry, and storing the result
I have some issues with the way attributes are referenced. According to the
PDD:
> classoffset Ix, Py, Sz
>
> Returns the offset of the first attribute for class Sz in object Py.
>
> getattribute Px, Py, Iz
>
> Returns attribute Iz of object Py and puts it in Px. Note that the
> attribute
At 9:57 AM -0800 3/12/04, Steve Fink wrote:
On Mar-12, Dan Sugalski wrote:
At 9:49 AM +0100 3/12/04, Leopold Toetsch wrote:
>Dan Sugalski wrote:
>
>>Calling a method:
>>
>> object.variable(pararms)
>
>Do we need the more explicit pcc_call syntax too:
>
> .pcc_begin
> .arg x
> .m
On Mar-12, Dan Sugalski wrote:
> At 9:49 AM +0100 3/12/04, Leopold Toetsch wrote:
> >Dan Sugalski wrote:
> >
> >>Calling a method:
> >>
> >> object.variable(pararms)
> >
> >Do we need the more explicit pcc_call syntax too:
> >
> > .pcc_begin
> > .arg x
> > .meth_call PObj, ("meth" | PMeth )
At 8:55 AM -0500 3/12/04, Matt Greenwood wrote:
I completely agree that you would have multiple *of the same* opcode for
the different types. I guess the question I was (too delicately) asking,
is why you have opcodes that are usually in standard libraries, and even
some that aren't. For example; f
At 12:25 PM + 3/12/04, Arthur Bergman wrote:
Hi,
Tracking down test failures in ponie I noticed some tests using
SIGINT failing, they don't fail when I change the tests using
SIGUSR1, making me think that parrot somehow hijacks SIGINT but not
other signals.
Is this per design or is it some
At 9:49 AM +0100 3/12/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
Calling a method:
object.variable(pararms)
Do we need the more explicit pcc_call syntax too:
.pcc_begin
.arg x
.meth_call PObj, ("meth" | PMeth ) [, PReturnContinuation ]
.result r
.pcc_end
Sure. Or we could m
At 8:27 AM +0100 3/12/04, Leopold Toetsch wrote:
Jens Rieks <[EMAIL PROTECTED]> wrote:
the following patch adds 4 more tests to t/pmc/sub.t
Thanks for the tests. Applied.
One of the new tests ('load_bytecode @LOAD second sub - imc') is currently
failing.
@LOAD or other pragmas are only evaluate
At 6:06 PM -0500 3/11/04, Matt Greenwood wrote:
Hi all,
I have a newbie question. If the answer exists in a doc, just
point the way (I browsed the docs directory). What is the design
rationale for so many opcodes in parrot? What are the criteria for
adding/deleting them?
Whether we have a l
This is Ponie, development release 2
"And, isn't sanity really just a one-trick ponie anyway? I mean all
you get is one trick, rational thinking, but when you're good and
crazy, oooh, oooh, oooh, the sky is the limit." -- the tick
Welcome to this second deve
I completely agree that you would have multiple *of the same* opcode for
the different types. I guess the question I was (too delicately) asking,
is why you have opcodes that are usually in standard libraries, and even
some that aren't. For example; fact, exsec..., why have both concat and
add...?
Hi,
Tracking down test failures in ponie I noticed some tests using SIGINT
failing, they don't fail when I change the tests using SIGUSR1, making
me think that parrot somehow hijacks SIGINT but not other signals.
Is this per design or is it something that should be fixed?
Arthur
Hi,
On Friday 12 March 2004 08:57, Leopold Toetsch wrote:
> Jens Rieks <[EMAIL PROTECTED]> wrote:
> > $ ../parrot dumper_1.imc
> > parrot: src/packfile.c:2783: store_sub_in_namespace: Assertion `ns <
> > pf->const_table->const_count' failed.
> > aborted.
>
> Fails differently here:
>
> error:imcc:
On Thu, Mar 11, 2004 at 10:33:24PM +0100, Leopold Toetsch wrote:
> Nicholas Clark <[EMAIL PROTECTED]> wrote:
>
> > If parrot's garbage collector is changed from the default (compacting, IIRC)
> > to the either libc or malloc, then ponie only fails 6 tests.
>
> > As I understand it parrot's defaul
[Matt == [EMAIL PROTECTED] on Thu, 11 Mar 2004 18:06:56 -0500]
Matt> What is the design rationale for so many opcodes in parrot?
Completeness and performance. Many of the opcodes are type-specific
variants of other multi-type opcodes.
Given that 99+% of parrot code will be automatically generat
Dan Sugalski wrote:
Calling a method:
object.variable(pararms)
Do we need the more explicit pcc_call syntax too:
.pcc_begin
.arg x
.meth_call PObj, ("meth" | PMeth ) [, PReturnContinuation ]
.result r
.pcc_end
leo
On Mar-11, Leopold Toetsch wrote:
> Jens Rieks <[EMAIL PROTECTED]> wrote:
>
> > attached is a patch to t/pmc/object-meths.t that adds a test that is
> > currently failing because IMCC rejects code like self."blah"()
>
> Yep. It produces reduce/reduce conflicts. Something's wrong with
> precedence
Jens Rieks <[EMAIL PROTECTED]> wrote:
> $ ../parrot dumper_1.imc
> parrot: src/packfile.c:2783: store_sub_in_namespace: Assertion `ns <
> pf->const_table->const_count' failed.
> aborted.
Fails differently here:
error:imcc:fixup_bsrs: couldn't find addr of sub '__lookup_method'
The reason seems t
Simon Glover <[EMAIL PROTECTED]> wrote:
> On Thu, 11 Mar 2004, Jens Rieks wrote:
>> $ tar xzf err2.tgz
>> $ cd err2
>> $ ../parrot t/pmc/dumper_1.imc
>> parrot: src/hash.c:256: promote_hash_key: Assertion `key' failed.
>> aborted
>>
>> It is caused by 'callmethod "dumper"' (err2/library/dumper.im
Matt Greenwood <[EMAIL PROTECTED]> wrote:
> Hi all,
> I have a newbie question. If the answer exists in a doc, just
> point the way (I browsed the docs directory). What is the design
> rationale for so many opcodes in parrot?
We have four different register types. They have to be covered by
Jens Rieks <[EMAIL PROTECTED]> wrote:
> the following patch adds 4 more tests to t/pmc/sub.t
Thanks for the tests. Applied.
> One of the new tests ('load_bytecode @LOAD second sub - imc') is currently
> failing.
@LOAD or other pragmas are only evaluated on the first statement of a
compilation un
40 matches
Mail list logo
