Re: JIT & branches under the Sun
Stephane Peiry <[EMAIL PROTECTED]> wrote:
> mh ok, I do get the stabs file, and apparently the reason no objfile gets
> created is that "as" complains with loads of warnings and some errors when
> given the stab file.
I see. Your libc's sprintf seems to be missing the "0x" prefix for the
"%p" format. Can you verfy that with a small test:
$ cat p.c
#include
int main(void) {
printf("main %p\n", main);
return 0;
}
$ cc -Wall p.c && ./a.out
main 0x8048400
I see two ways to work around that:
1) have a test for above case and double the lines in jit_debug.c that
use %p
#ifdef PARROT_LIBC_SPRINTF_P_IS_OK
... %p
else
... 0x%p
#endif
(a define for a specific $arch is fine in the first place)
2) use Parrot_sprintf and friends.
As this whole stuff is system dependend anyway I'd use 1) for now.
> .stabs "set.pasm",100,0,0,0
> .stabs "jit_func:F(0,1)",36,0,1,267f10
# line 2 - last item ought to be 0x267f10
leo
Obfuscated Parrot
# obf1.pasm bounds 1 trace 0 split P0, '', "\nrekcaH torraP rehtona tsuJ" add I1, 3 add I2, 4 branch I2 pack S23, 793, I1, I0 branch I2 add I2, 382, I1 branch I2 new S23, 911, I0, I0 branch I1 transcode S23, S0, -19 end Have fun, leo
Re: Obfuscated Parrot
Another one, OO-style with subroutines: $ cat obf2.pasm bounds 1 trace 0 newclass P0, "Just another Parrot Hacker\n" shift S0, P5 does I0, P0, S0 add I0, 4 bsr I0 pack S0, 381, I0, I0 invoke ret $ parrot obf2.pasm Just another Parrot Hacker leo
Re: Object spec
At 5:18 PM -0500 2/13/04, Simon Glover wrote: Here's a patch to fix various typos etc. that I noticed on going over the spec. D'oh! Applied, thanks. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Object spec
At 5:35 PM -0500 2/13/04, Simon Glover wrote:
A few questions:
1) How is the search order for the parents of a particular class
specified? In particular, is this determined at the Parrot level
or at the language level? Can it change at runtime?
It's determined by the method invocation code.
2) Re. the classoffset op: how does this work when multiple parent
classes specify the same attribute?
For instance, suppose 'foo' is the first attribute specified in
classes 'Bar' and 'Baz', which are theselves unrelated (i.e. 'Bar'
doesn't inherit from 'Baz', nor vice versa), but which are both
parent classes of a third class 'Qux'. Now, if P0 holds an object
of class 'Qux', does:
classoffset I0, P0, 'Bar'
return the same value as:
classoffset I0, P0, 'Baz'
or not?
Nope. When the Qux class is constructed the offsets for each of its
parent classes (and their parent classes,a nd so on) are calculated,
and are effectively custom on a per-class basis. So if we had the
following classes with attributes:
Bar:
a
b
c
Baz:
x
y
z
and we had Qux and Xyzzy like so:
Qux: isa(Bar, Baz)
Xyzzy: isa(Baz, Bar)
Then you had code that looked like:
new P0, .Qux
new P1, .Xyzzy
classoffset I0, P0, 'Bar'
classoffset I1, P1, 'Bar'
print I0
print "\n"
print I1
print "\n"
you'd get:
2
5
(Because the first few attributes are reserved) *However*
Attribute "b" is always at classoffset("Bar") + 1, regardless of
where Bar is in the attribute list.
Basically any class code that directly accesses attributes should
first query where that class's base offset is for the object in
question and work from there.
I think I need to add in an example section.
3) If more than one parent class specifies a particular attribute,
do all of these parents have to be removed before the attribute
is removed?
Currently yes. That also means a class can have its attributes in the
hierarchy only once, regardless of how many times it actually appears.
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Object spec
At 5:29 AM +0100 2/15/04, LF wrote: While I'm still working on the vtable and supporting code section, most of the revamp of PDD15 (objects!) is checked into the repository. It'd be worth checking it out and checking it out, as this would be the time to get comments in. great to see this, i guess everyone will agree. well, i have some questions... what i couldn't find is how to register a method address and name with a class, so that fetchmethod will return it? am i looking in the wrong place? Not gotten there yet. :) By default methods are in class namespaces, so fetchmethod would (by default, mind) just look in each class namespace in the parent array for the method until it finds one. We're going to provide method caches, since otherwise performance will really suck, but that's an optimiziation. the instantiate opcode takes 'metadata' as its second argument. how is this supposed to be constructed and when is this method of creating a new class appropriate instead of newclass and subclass ops? I was wondering if someone'd catch that. The metadata stuff is entirely unspecified, but it's in there for later. (Or, rather, not-quite-now) It's to be used in the case where you have all the info for a class at instantiation time and want to be able to say "make me a class with parents X, Y, and Z, and eighteen attributes with these names" and do it in one go, rather than as a series of addparent and addattribute ops. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Rules for method resolution?
At 11:50 PM -0500 2/14/04, Michal Wallace wrote: Maybe for python, findmethod and getprop (or whatever the new eqivalent is) are the same... But I'd suspect that getprop is all any (working) python compiler will use. I've chopped out everything but this bit, since it's perfectly valid, and I think it's the important bit -- getprop and findmethod may well do exactly the same thing on python objects, and that's just fine. From what I can tell, the rule when fetching a 'property' (that is, a named thingie tacked onto a PMC) is "return a bound method doodad if it exists, otherwise return the property result" The big question is whether you treat the returned value as a plain scalar thing, or as a subroutine. That is, if you do: x = object.some_name can you then do: x(1, 2, 3) or not? I'm not sure that, in the general case, too many compilers will use findmethod anyway, as I'm not sure it's too common an activity, and I think (but may be wrong) that making the result bound won't be universal at all. This may well be a case where a python compiler actually emits a chunk 'o code, perhaps something like: fetchmethod METHOD, OBJECT, "Foo" isnull METHOD, getproperty bind SUB_PMC, OBJECT, METHOD return SUB_PMC getproperty: getprop PROPERTY, OBJECT, "Foo" isnull PROPERTY, whine return PROPERTY whine: throw UNBINDABLE_NAME, "Can't bind Foo" or something kinda sorta like that. (Assuming we provide a bind op to turn an object/method pair into a sub PMC that, when called, acts like you called the method on the object) I *think* I'd prefer the PMC findmethod vtable entry to return an unbound method, since I think I'd like to have the plain method invocation use that vtable entry to find the method, and if so I'd like to use the result in the cache system as well. I've no problem providing a binding scheme as part of the core, nor of providing some sort of mutant "method_or_prop" op that looks for a method and, if no joy, looks for a property. We may end up with some sort of compiler game here, though. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Object spec
At 10:31 AM +0100 2/14/04, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: While I'm still working on the vtable and supporting code section, most of the revamp of PDD15 (objects!) is checked into the repository. It'd be worth checking it out and checking it out, as this would be the time to get comments in. 1) Why is the existing opcode B now B? Or do they different things? Same thing. The difference is a result of my lousy memory and lack of research. 2) B isn't really needed. set I0, PClass["attr"] exists and is working Pretty much all of the current object stuff is getting yanked out and replaced. It's first draft and needs redoing. And finally - I asked that already a few times - how does B<"attr"> above really look like? Is this a full qualified name? Or only when two classes have the same attribute? That was specified in the PDD. *If* a class is looking up by name, something it generally won't do, it uses the fully-qualified name of the attribute, in the format that the class wants. Since a class is soley responsible for its naming scheme this should be reasonably safe. Please have a look at t/pmc/obj*.t for the current state. Those'll need to be redone as well. Something for later, when the spec is done. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Rules for method resolution?
At 10:12 AM -0500 2/15/04, Michal Wallace wrote:
On Sun, 15 Feb 2004, Luke Palmer wrote:
> But I think findmethod is a good idea, cross-language-wise. Each
language has a different idea of what a method is, and they can
store it that way. As long as findmethod is vtableable, you can
hook it up to whatever system your language uses.
I was thinking the same thing as I wrote my post
last night... But I'm not convinced.
Suppose I do something like this:
x = parrot.find("perl::whatever")
x.method()
Is that second line a method call or a function call?
Got me. I can't see any way it wouldn't be a method call, honestly.
It's also very language dependent, being syntax and all--if python
says its a method call, it's a method call. (If x is a bound method
which you have to call first and then call a method on its return
value, well... that makes things a bit more interesting in spots but
not for the compiler)
Snipping the multimethod example, multimethod lookup is done by the
core as part of the provided "find me the method that matches" code.
If you use that code to do the lookup you get MMD. If you don't, you
won't.
In fact, since I'm on the subject, properties and
attributes also have this problem.
Properties and attributes have a much bigger problem. Two, actually.
First, they're private and may *not* be exposed, so non-class code
can't ever see them. (Well, OK, shouldn't ever see them without
cheating) Second, as they're class-private, there can (and will) be
duplicate names in there.
While I'd love 'em to be interchangeable, they're not going to be.
Python code won't ever see what we're calling attributes unless it
makes an explicit call to go look. (or Guido alters the syntax, which
is both unlikely and arguably a bad thing, or at least parrot's a bad
reason to do it)
Random code, in most languages (including perl 6 and python) that does:
y = foo.bar
will either get the bar property or the result of bar method, but
never (any of) the bar attributes. (And yes, before someone else
jumps in, languages can mark attributes public, but that means the
language compiler generates an lvalue method, reducing the problem to
a previous one :)
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
[PATCH] library/sort.imc
Hi, The following patch adds parameter checking to _sort(). Wrong parameters are now reported (no exceptions are used yet). I've also added 3 more tests in t/pmc/sort.t (included in patchfile) jens Index: library/sort.imc === RCS file: /cvs/public/parrot/library/sort.imc,v retrieving revision 1.1 diff -u -w -r1.1 sort.imc --- library/sort.imc 12 Feb 2004 07:36:02 - 1.1 +++ library/sort.imc 16 Feb 2004 17:52:47 - @@ -45,7 +45,6 @@ .sub _sort .param pmc array -.param pmc function .param int start .local int i .local int size @@ -54,6 +53,22 @@ .local pmc minval .local int v +# check number of INT args +if I1 == 0 goto NOINT +if I1 == 1 goto OK +ERROR: +print "_sort Syntax:\n" +print "_sort( array )\n" +print "_sort( array, startoffset )\n" +branch END +NOINT: +set start, 0 +OK: +# check number of STR args +if I2 != 0 goto ERROR +# check number of PMC args +if I3 != 1 goto ERROR + size = array # already sorted if size <= 1 goto END @@ -73,7 +88,7 @@ SKIP: inc i if i < size goto LOOP -if start > minpos goto SKIP2 +if start >= minpos goto SKIP2 tmp = array[start] array[start] = minval array[minpos] = tmp Index: t/pmc/sort.t === RCS file: /cvs/public/parrot/t/pmc/sort.t,v retrieving revision 1.1 diff -u -w -r1.1 sort.t --- t/pmc/sort.t 12 Feb 2004 07:36:05 - 1.1 +++ t/pmc/sort.t 16 Feb 2004 17:52:47 - @@ -1,7 +1,7 @@ #! perl -w use strict; -use Parrot::Test tests => 6; +use Parrot::Test tests => 9; output_is(<<'CODE', <<'OUT', "sorting already sorted numbers"); ##PIR## @@ -283,4 +283,121 @@ foxtrot golf hotel +OUT + +output_is(<<'CODE', <<'OUT', "sorting letters"); +##PIR## +.sub _main +.local pmc array +.local int i +.local int j +.local pmc tmp + +new array, .PerlArray +push array, "w" +push array, "x" +push array, "h" +push array, "y" + +_sort( array ) +i = 0 +j = array +LOOP: +set tmp, array[i] +print tmp +print "\n" +inc i +if i < j goto LOOP +end +.end +.include "library/sort.imc" +CODE +h +w +x +y +OUT + +output_is(<<'CODE', <<'OUT', "sorting PerlString letters"); +##PIR## +.sub _main +.local pmc array +.local int i +.local int j +.local pmc tmp + +new array, .PerlArray +new tmp, .PerlString +set tmp, "w" +push array, tmp + +new tmp, .PerlString +set tmp, "x" +push array, tmp + +new tmp, .PerlString +set tmp, "h" +push array, tmp + +new tmp, .PerlString +set tmp, "y" +push array, tmp + +_sort( array ) +i = 0 +j = array +LOOP: +set tmp, array[i] +print tmp +print "\n" +inc i +if i < j goto LOOP +end +.end +.include "library/sort.imc" +CODE +h +w +x +y +OUT + +output_is(<<'CODE', <<'OUT', "sorting strings"); +##PIR## +.sub _main +.local pmc array +.local int i +.local int j +.local pmc tmp + +new array, .PerlArray +new tmp, .PerlString +push array, "hello" +push array, "hash2" +push array, "hello2" +push array, "2" +push array, "bbb" +push array, "bb" +push array, "1" + +_sort( array ) +i = 0 +j = array +LOOP: +set tmp, array[i] +print tmp +print "\n" +inc i +if i < j goto LOOP +end +.end +.include "library/sort.imc" +CODE +1 +2 +bbb +bb +hash2 +hello +hello2 OUT
[PATCH] library/dumper.imc
Hi,
The following patch adds parameter checking to _dumper(), as well as
PMC property dumping.
Wrong parameters are now reported (no exceptions are used yet).
Tests are added to t/pmc/dumper.t, included in this patchfile.
jens
Index: t/pmc/dumper.t
===
RCS file: /cvs/public/parrot/t/pmc/dumper.t,v
retrieving revision 1.1
diff -u -w -r1.1 dumper.t
--- t/pmc/dumper.t 12 Feb 2004 07:36:05 - 1.1
+++ t/pmc/dumper.t 16 Feb 2004 18:04:36 -
@@ -1,7 +1,7 @@
#! perl -w
use strict;
-use Parrot::Test tests => 6;
+use Parrot::Test tests => 8;
output_is(<<'CODE', <<'OUT', "dumping array of sorted numbers");
##PIR##
@@ -281,7 +281,6 @@
}
"hash1" => PerlHash {
"hash2" => PerlHash {
-"hello3" => "world3",
"array1" => PerlArray (size:5) [
"this",
"is",
@@ -292,8 +291,114 @@
"name" => "parrot",
}
],
+"hello3" => "world3",
},
"hello" => "world",
"hello2" => "world2",
}
+OUT
+
+output_is(<<'CODE', <<'OUT', "properties");
+##PIR##
+.sub _main
+.local pmc str
+.local pmc array
+
+new array, .PerlArray
+push array, "test1"
+push array, "test2"
+
+new str, .PerlString
+set str, "value1"
+setprop array, "key1", str
+
+new str, .PerlString
+set str, "value2"
+setprop array, "key2", str
+
+_dumper( array )
+
+end
+.end
+.include "library/dumper.imc"
+CODE
+PerlArray (size:2) [
+"test1",
+"test2"
+] with-properties: {
+"key1" => "value1",
+"key2" => "value2",
+}
+OUT
+
+output_is(<<'CODE', <<'OUT', "indent string");
+##PIR##
+.sub _main
+.local pmc hash1
+.local pmc hash2
+.local pmc array1
+.local pmc array2
+.local string name
+.local string indent
+
+new hash1, .PerlHash
+new hash2, .PerlHash
+new array1, .PerlArray
+new array2, .PerlArray
+
+set hash1["hash2"], hash2
+set hash2["array"], array1
+set hash1["test1"], "test1"
+set hash2["test2"], "test2"
+push array1, 1
+push array1, array2
+push array2, "test"
+setprop hash1, "array2", array2
+name = "hash"
+indent = "|"
+_dumper( name, hash1, indent )
+_dumper( name, hash1, indent )
+print "name = '"
+print name
+print "'\nindent = '"
+print indent
+print "'\n"
+end
+.end
+.include "library/dumper.imc"
+CODE
+|"hash" => PerlHash {
+|"hash2" => PerlHash {
+|"array" => PerlArray (size:2) [
+|1,
+|PerlArray (size:1) [
+|"test"
+|]
+|],
+|"test2" => "test2",
+|},
+|"test1" => "test1",
+|} with-properties: {
+|"array2" => PerlArray (size:1) [
+|"test"
+|],
+|}
+|"hash" => PerlHash {
+|"hash2" => PerlHash {
+|"array" => PerlArray (size:2) [
+|1,
+|PerlArray (size:1) [
+|"test"
+|]
+|],
+|"test2" => "test2",
+|},
+|"test1" => "test1",
+|} with-properties: {
+|"array2" => PerlArray (size:1) [
+|"test"
+|],
+|}
+name = 'hash'
+indent = '|'
OUT
Index: library/dumper.imc
===
RCS file: /cvs/public/parrot/library/dumper.imc,v
retrieving revision 1.2
diff -u -w -r1.2 dumper.imc
--- library/dumper.imc 14 Feb 2004 17:05:26 - 1.2
+++ library/dumper.imc 16 Feb 2004 18:04:36 -
@@ -151,11 +151,43 @@
.param pmc dump
.param string indent
+# check the number of INT args
+if I1 != 0 goto ERROR
+# check the number of PMC args
+if I3 != 1 goto ERROR
+# check the number of STR args
+if I2 > 2 goto ERROR
+if I2 < 0 goto ERROR
+if I2 == 2 goto NAMED
+if I2 == 0 goto UNNAMED
+
+# I2 == 1; no ident specified
+set indent, ""
+
+NAMED:
_helper()
_do_dumper_named( name, dump, indent )
print "\n"
+.pcc_begin_return
+.return 1
+.pcc_end_return
+
+UNNAMED:
+_helper()
+_do_dumper_unnamed( dump, "" )
+print "\n"
.pcc_begin_return
+.return 1
+.pcc_end_return
+
+ERROR:
+print "_dumper Syntax:\n"
+print "_dumper( pmc )\n"
+print "_dumper( name, pmc )\n"
+print "_dumper( name, pmc, indent )\n\n"
+.pcc_begin_return
+.return 0
.pcc_end_return
.end
@@ -211,6 +243,13 @@
restoreall
DONE:
+prophash cb, dump
+unless cb goto END
+
+print " with-properties: "
+_dump_Hash( cb, indent )
+
+END:
.pcc_begin_return
.pcc_end_return
.end
@@ -274,6 +313,19 @@
.sub _dump_PerlHash
.param pmc hash
.param string indent
+
+print "PerlHash "
+_dump_Hash( hash, indent )
+.pcc_begin_return
+.pcc_end_return
+.end
+
+#
+# Dumps a 'generic' Hash
+#
+.sub _dump_Hash
+.param pmc hash
+.param string indent
.local string subindent
.local pmc i
[PATCH] IO fixes for Win32
flags_to_win32 sets fdwShareMode to FILE_SHARE_DELETE, which is not supported
in win98 and will cause the CreateFile to fail, so the ParrotIO is NULL, and
subsequent PIO_read on its io PMC will return -1. When len is -1, some tests
in t/src/io.t will think it's positive since it has it as a UINTVAL (should
be an INTVAL) causing it to loop forever. Also using -1 as an index into the
buffer could overwrite that len variable, making it actually positive. And it
uses ParrotIO* where it should be using PMC* (dosen't really matter but it's
nice to use the right type of pointer). Furthermore, test 13 fails since it
expects a 6 byte file, but actually creates one larger than that because
of \n -> \r\n translation.
__
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html--- io/io_win32.c~ Wed Feb 4 07:46:48 2004
+++ io/io_win32.c Mon Feb 16 10:41:18 2004
@@ -103,7 +103,7 @@
*fdwCreate = OPEN_EXISTING;
}
-*fdwShareMode = FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE;
+*fdwShareMode = FILE_SHARE_READ | FILE_SHARE_WRITE;
if (flags & PIO_F_APPEND) {
/* dealt with specially in _write and _puts */
}
--- io.t~ Mon Feb 9 01:10:46 2004
+++ io.tMon Feb 16 11:00:26 2004
@@ -11,6 +11,7 @@
my $content = @_ ? shift : "This is a test\n";
open(FILE, ">$name") or die "Failed to create $name";
+ binmode FILE;
print FILE $content;
close(FILE);
@@ -69,7 +70,7 @@
the_test(struct Parrot_Interp *interpreter,
opcode_t *cur_op, opcode_t *start)
{
-ParrotIO *io;
+PMC *io;
char *p;
io = PIO_STDOUT(interpreter);
@@ -100,15 +101,15 @@
the_test(struct Parrot_Interp *interpreter,
opcode_t *cur_op, opcode_t *start)
{
-ParrotIO *io;
+PMC *io;
char buf[1024];
-UINTVAL len;
+INTVAL len;
io = PIO_open(interpreter, NULL, "temp.file", "<");
len = PIO_read(interpreter, io, buf, sizeof(buf)-1);
PIO_close(interpreter, io);
-buf[len] = '\0';
+buf[len < 0 ? 0 : len] = '\0';
PIO_printf(interpreter, "%s", buf);
io = PIO_open(interpreter, NULL, "temp.file", "<");
@@ -117,8 +118,8 @@
do {
len = PIO_read(interpreter, io, buf, 3);
-buf[len] = '\0';
- /* dont write trailing spaces */
+buf[len < 0 ? 0 : len] = '\0';
+/* don't write trailing spaces */
PIO_printf(interpreter, "%d: %s\n", len, len ? buf : "EOF");
} while (len > 0);
@@ -142,7 +143,7 @@
the_test(struct Parrot_Interp *interpreter,
opcode_t *cur_op, opcode_t *start)
{
-ParrotIO *io;
+PMC *io;
io = PIO_open(interpreter, NULL, "temp.file", ">>");
PIO_write(interpreter, io, "Parrot flies.\n", 14);
@@ -166,8 +167,8 @@
the_test(struct Parrot_Interp *interpreter,
opcode_t *cur_op, opcode_t *start)
{
-ParrotIO *io;
-size_t len;
+PMC *io;
+INTVAL len;
char buf[1024];
io = PIO_open(interpreter, NULL, "temp.file", "<");
@@ -175,7 +176,7 @@
do {
len = PIO_read(interpreter, io, buf, sizeof(buf)-1);
-buf[len] = '\0';
+buf[len < 0 ? 0 : len] = '\0';
PIO_printf(interpreter, "%d: %s", len, len ? buf : "EOF");
} while (len > 0);
Re: [perl #25825] [PATCH] imcc/t/syn/file.t fails with a non-english locale
lAdam Thomason wrote: > Hmm, this is still wrong. The error message isn't just a function of the locale; it's also dependent on the OS. > AIX is now back to expecting "No such file or directory" courtesy of LANG=C > when the imcc error is "A file or directory in the path name does not exist." > That's English, just not the right English. > It looks like this is going to need a more involved fix that doesn't monkey with the locale > and just does what IMCC is doing: calling strerror from C code. I have added a new patch to http://rt.perl.org/rt3/Ticket/Display.html?id=25825, which somehow didn't make it to the list. The patch file_t_20040215.patch uses following strategy: i. Ask Perl5 for the platform dependent numeric value of ENOENT ii. Ask parrot for the platform dependent error message for ENOENT For doing this I added a new op in 'ops/sys.ops': + err(out STR, in INT) + + Get the system error message for the system error code $2 + and store it in $1. + This new op is implemented with 'strerror()'. Would it be nice to have a list of system error codes in 'runtime/parrot/include'? -- /* [EMAIL PROTECTED] */ GMX ProMail (250 MB Mailbox, 50 FreeSMS, Virenschutz, 2,99 EUR/Monat...) jetzt 3 Monate GRATIS + 3x DER SPIEGEL +++ http://www.gmx.net/derspiegel +++
Re: Rules for method resolution?
Dunno why it is, but I tried to post a message about 30 hours ago and nothing ever showed up in the NNTP archive. So I re-subscribed again figuring that'd speed things up. You should see my perl box: ... WELCOME to [EMAIL PROTECTED] confirm subscribe to [EMAIL PROTECTED] GOODBYE from [EMAIL PROTECTED] confirm unsubscribe from [EMAIL PROTECTED] WELCOME to [EMAIL PROTECTED] confirm subscribe to [EMAIL PROTECTED] ... *ANYWAY* Sorry if I get some of the details wrong or talk about something that's already been covered. I haven't quite kept up with the mailing list recently. As I see it, there are 2 basic ways you can handle the methodcall/property issue: Way 1: HL code -> pseudo-parrot code python: v = x.y -> c = getprop(x, "y") (v now contains a bound method) v() -> call( v ) x.y() -> callmeth( x, "y" ) ruby: x.y -> getprop(x, "y") x.y() -> callmeth(x, "y") It is then up to the object to decide whether getprop should return a bound method or the result of calling the named method. Way 2: same as way 1 except for ruby: x.y -> callmeth(x, "y") As this would result the behavior a ruby programmer would tend to expect if x was a python object and y was an accessor method. Still, it should be up to the object to decide what getprop should do, but if more languages went this route, it would be more common for getprop to return bound methods instead of the result of calling the method, as languages that don't expect to ever get a method by saying "x.y" would always call a method and never deal with properties. Way 1 seems cleaner on a low level. OTOH, it could cause problems when calling accessor methods on a python object from ruby. But I think in this case it is the responsibility of the python programmer to name accessor methods as 'get_color()' as opposed to just 'color()', which looks to the programmer like a property rather than a method. __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html
New Parrot-targetting language: ConfigScript3
And now for my earlier post that never showed up... http://togos.dhs.org/projects/configscript3/ It expects * ruby 1.8.0 to be installed as /usr/bin/ruby * the files under lib/ to be installed where ruby will find them (cp -R lib/* /usr/lib/ruby/site_ruby) programs are bin/configscript (the interpreter/compiler) and bin/test (runs tests) usage: configscript file.cs ; execute file.cs configscript -o file.imc file.cs ; compile to imcc configscript -o file.pbc file.cs ; compile to pbc configscript -o - file.cs ; compile to imcc on stdout see t/* for example scripts ConfigScript3 uses a custom OO AST between the parser and the IMCC outputter called "GenScript3", which I plan to write more front-ends (Ruby?) and back-ends (Jasm?) for. I hope you like it, and I hope this was the right place to post this :) - TOGoS (http://togos.dhs.org/) __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html
Re: [PATCH] library/sort.imc
Jens Rieks <[EMAIL PROTECTED]> wrote: > The following patch adds parameter checking to _sort(). > Wrong parameters are now reported (no exceptions are used yet). > I've also added 3 more tests in t/pmc/sort.t (included in patchfile) Thanks, applied. leo
Re: [PATCH] library/dumper.imc
Jens Rieks <[EMAIL PROTECTED]> wrote: > The following patch adds parameter checking to _dumper(), as well as > PMC property dumping. > Wrong parameters are now reported (no exceptions are used yet). > Tests are added to t/pmc/dumper.t, included in this patchfile. Thanks, applied. leo
