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
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
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
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
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
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
[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
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
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:
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
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...?
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
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 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 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
> -Original Message-
> From: Larry Wall [mailto:[EMAIL PROTECTED]
> On Thu, Mar 11, 2004 at 11:38:11AM +, Andy Wardley wrote:
> : Larry Wall wrote:
> : > multi sub *scramble (String $s) returns String {...}
> : [...]
> : > Or you can just call it directly as a function:
> : > sc
> -Original Message-
> From: Larry Wall [mailto:[EMAIL PROTECTED]
> On Thu, Mar 11, 2004 at 06:49:44AM -0800, Gregor N. Purdy wrote:
> : So, will "mutatingness" be a context we'll be able to inquire on
> : in the implementation of a called routine?
>
> Probably not, but it's vaguely possi
On Fri, 12 Mar 2004 10.51, Damian Conway wrote:
> There are also cases where something like:
>
> $a ||= $b;
>
> or:
>
> $a += $b;
>
> changes the type of value in $a. Should we flag those too? Currently we do
> warn on the second one if $a can't be cleanly coerced to numeric. Would
> th
> -Original Message-
> From: Damian Conway [mailto:[EMAIL PROTECTED]
>
> Larry wrote:
>
> > On the other hand, I suspect most people will end up declaring it
> >
> > int method
> > self:rotate (int $a is rw) {...}
> >
> > in any event, and reserve the =rotate for .=rotate, which c
Austin Hastings writes:
>
>
> > -Original Message-
> > From: Larry Wall [mailto:[EMAIL PROTECTED]
> > On Thu, Mar 11, 2004 at 06:49:44AM -0800, Gregor N. Purdy wrote:
> > : So, will "mutatingness" be a context we'll be able to inquire on
> > : in the implementation of a called routine?
>
"Larry Wall" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Unfortunately we can't just use topicalization to say
>
> my Cat $tom = .new()
>
> because most people won't expect simple assignment to break their
> current topic.
>
> So another option is to replace = with somethin
On Fri, Mar 12, 2004 at 03:47:22AM -0500, Austin Hastings wrote:
> > -Original Message-
> > From: Larry Wall [mailto:[EMAIL PROTECTED]
> >
> > Now in the specific case of . and .= we don't exactly have a normal
> > binary operator, because the right side is not an expression.
>
> $tis.=«
On Fri, Mar 12, 2004 at 12:29:36PM +1100, Deborah Pickett wrote:
: That triggered a thought about unary operators. What about:
:
: $a !=;# i.e., $a = ! $a;
Well, an argument could be made that the corresponding syntax is really:
!= $a;
But you have to read the
A = B ==> A
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
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 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
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
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
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
> 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
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
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> ... (Though arguably
> anything you make a method call on really is an object :)
or a class.
leo
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
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
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
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
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,
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
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
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
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
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
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
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
On 3/12/04 12:43 PM, Larry Wall wrote:
> Some good questions only have bad answers. This might be one of them.
I have been watching this thread with increasing unease, asking myself
exactly what the potential benefit is of this proposed feature and syntax.
I'm all for saving some typing, but yees
On Fri, Mar 12, 2004 at 09:19:46AM -0800, Dave Whipp wrote:
: Why are we mixing the concepts of assignment and topicalization --
: especially in a way that doesn't generalize. Why can't we invent a
: "topicalization" operator, analogous to the old binding operator, that
: simply sets its LHS as th
Larry Wall wrote:
Now, if we had a unary = that assigned to the current topic, we could do
it with the existing topicalizer as
given my Dog $dog { = .new }
But I'm not recommending that approach, because I dislike unary =, and
because I don't want every declaration to have to say "given".
"Oh, it's got lots of Japanese in it, I'd better read it..." :)
[EMAIL PROTECTED] (Larry Wall) writes:
> Some will argue that since English doesn't have a grammatical
> postfix topicalizer like Japanese, we should stick with something
> like more English-like:
>
> $x = (.a + .b + .c given $f
Please bare with me, I do follow this list, but sporadically.
What it all boils down to, obviously, is that we, as lazy programmers, want
to have to type less, but still leave the code make sense when read. So to
me, that should automatically throw out stuff such as C<$x = ( $foo § .a +
.b + .c )
And I do think people would rebel at using Latin-1 for that one.
I get enough grief for Â...Â. :-)
I can imagine that these cause some trouble with people using a charset
other than ISO-8859-1 (Latin-1) that works well with 8 bit, like Greek,
Arabic, Cyrillic and Hebrew.
For these guys Unicode is
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
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
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
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
54 matches
Mail list logo
