Re: Distributed testing idea
Le mercredi 11 février 2004 à 13:24, Michael G Schwern écrivait: > > So what I need is some way to set up a network of test servers such that > I can say "test this module for me" and my testing client would ship it > to as many test servers as it can find and get the results back all in > just a few minutes. > Yet another useful thing would be that the "web test server" could act as a gateway to several tests servers. For example, imagine someone that has several hosts, each having several Perl versions on their home network. There is only one IP leading to this network, so one web server should be enough to ask for the distribution to be tested on one or several of the available targets. -- Philippe "BooK" Bruhat Few things in life are so dependable as the incompetence of those who know precisely what they are doing. (Moral from Groo The Wanderer #5 (Pacific))
Re: The Sort Problem
Uri Guttman writes:
> > "LP" == Luke Palmer <[EMAIL PROTECTED]> writes:
>
> LP> Uri Guttman writes:
> >> because that would be the default comparison and the extracted key value
> >> would be stringified unless some other marker is used. most sorts are on
> >> strings so this would be a useful huffman and removal of a redundancy.
>
> LP> While I like where most of this is going, I beg to differ on this point.
> LP> I end up sorting numbers more often then strings, except when I'm
> LP> sorting the keys of a hash. I'm always annoyed in my one liners when I
> LP> have to write out:
>
> LP> sort { $a <=> $b } ...
>
> LP> And I'd be thrilled if it were as easy as:
>
> LP> sort { +$_ } ...
>
> oh, i don't want to see <=> anywhere in sort code. i don't mind + or int
> as markers for that. you seem to actually be agreeing with me that
> strings are the default key type and + is needed for a numeric sort. but
> do you do integer or float sorts? and as i said, i don't like the
> asymmetry of int vs +.
Usually integer. But specifying integer is usually an optimization
guideline, whereas there is a much greater semantic difference between
sorting strings and floats. C deserves to be longer as just an
optimization guideline.
And yes, I agree that string should be default.
Luke
Re: The Sort Problem
Damian Conway writes:
> type KeyExtractor ::= Code(Any) returns Any;
>
> type Comparator ::= Code(Any, Any) returns Int;
>
> type Criterion::= KeyExtractor
> | Comparator Pair(KeyExtractor, Comparator)
> ;
>
> type Criteria ::= Criterion
> | Array of Criterion
> ;
>
> multi sub *sort(Criteria $by = {$^a cmp $^b}: [EMAIL PROTECTED]) {...}
This is neat stuff. But in order for this to work, we're relying on a
I sophisticated type system. Reminiscent of C++ templates,
actually. And while I love C++ templates for academic challenges, they
don't seem quite what Perl is looking for.
This is pattern matching more than it is type comparison. And Perl's
all about pattern matching. I'm just wondering whether it needs I
pattern archetectures.
If things like this are going to be happening (and thanks, Damian, for
demonstrating exactly how powerful this can be), I'd like types to at
least look more like regexes. Implementation difficulty has not been a
concern of Perl The Language's since the beginning.
Since I'm usually not good at these philosophical posts, I'll show some
examples.
multi sub infix:equals ( (Any) $x, ($1) $y ) { $x eq $y }
multi sub infix:equals ( Any $x, Any $y ) { undef }
Might be a way of nicely comparing apples to apples and rejecting
everything else as unequal. I don't really like the delcaration order
dependency, though. Perhaps:
multi sub infix:equals ({
$x := (Any), $y := ($1) { $x eq $y }
| $x := (Any), $y := (Any) { undef }
});
Which is I starting to look like rules (which is what I wanted).
My summarizing thesis is: if the type system is going to be this rich a
sublanguage, why not make it a formal one? [1]
Luke
[1] Keep in mind that I'm fine with it I becoming a sublanguage,
and relying on user-written code to do this kind of fancy matching. I'm
just saying if we want to make it a rich and powerful pattern matching
system, it ought to look like patterns.
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: 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: 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: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] 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);
[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
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: The Sort Problem
Damian Conway wrote:
Uri persisted:
> but int is needed otherwise? int is more commonly a sort key than
float.
> it just feels asymetrical with one having a symbol and the other a
named
> operator.
Sorry, but that's the way the language works. The more general and usual
conversion (to number, not to integer) has the shorter name.
For the record, I do a lot of statistical work. On the sorts where I
care about speed, I'm using floats far more often than ints. Uri's usage
obviously varies from mine. Let's not hack up the language to make sort
more efficient for some arguable benefit.
I would entertain, however, C and C comparators (and
functions in core) that pretty much (if not precisely) alias C<+> and
C<~>, forcing said type.
> DC> If you don't explicitly cast either way, C just DWIMs by
> DC> looking at the actual type of the keys returned by the extractor.
> DC> If any of them isn't a number, it defaults to C.
>
> that doesn't work for me. the GRT can't scan all keys before it decides
> on what comparison operator is needed. the GRT needs to merge keys as
> they are extracted and it needs to do the correct conversion to a byte
> string then and not later. you can't DWIM this away if you want the
> optimization.
EXACTLY!!! So, if you want the GRT to kick in, you have to make sure the
return type of your block is appropriate. If you don't give the
compiler that
hint, you don't get the optimized sorting.
When fed a number that it doesn't trust to be an int or a float,
couldn't the GRT store the number with C? (ok,
there's some prepping for sign and endian, but you get the point) Seems
like a not-terrible way to handle the issue.
Here's another example (all praise be to Rod!):
@teams = sort [
# 1 parameter so it's a key extractor...
{+ $^team->{WinPct} },
# 2 parameters so it's a comparator...
{ ($^a->{Conference} eq $^b->{Conference}
? ($^b->{ConfWinPct} <=> $^a->{ConfWinPct} ||
$^b->{ConfWon}<=> $^a->{ConfWon}||
$^a->{ConfLost} <=> $^b->{ConfLost})
: ($^a->{Division} eq $^b->{Division}
? ($^b->{DivWinPct} <=> $^a->{DivWinPct} ||
$^b->{DivWon}<=> $^a->{DivWon}||
$^a->{DivLost} <=> $^b->{DivLost})
: 0
)
},
# 1 parameter each so all three are key extractors...
{+ $^team->{Won} } is descending,
{+ $^team->{Lost} },
{+ $^team->{GamesPlayed} } is descending,
] @teams;
Now that's just spiffy. Except in moving from my P5 version to your P6
version, you have to s/?/??/ and s/:/::/, IIRC.
> DC> But you *can't* apply C to a Code reference.
> then how did you apply 'is insensitive'?
I applied it to the *block* (i.e. a closure definition).
That's not the same thing as a Code reference.
> what i am saying is i think that you need to go back to the drawing
> board to find a clean syntax to mark those flags.
No, I think we have it...just put the appropriate trait on the extractor
*block* when you define it.
I really don't see the problem with
@out = sort {lc $_}, @in;
It's short, simple, unambiguous, IMO very clean. But if people want to
take a tool that we're creating anyways elsewhere in the language
(traits) to provide another way to do it, that's fine too.
> i just don't like the reverse args concept at all. it is not
> semantically useful to sorting. sorts care about ascending and
> descending, not a vs b in args.
The problem is that sometimes comparator logic is suffiently complex that
a single comparator needs to have a "bit each way", as in Rod's
football team comparator above.
What my football example was meant to show is that no matter how much we
abuse poor C in the name of progress, we need to have a way to
drop it all and go back to how we did it in P5, for those truly
pathological cases where nothing else works. If people don't trust this,
I'll come up with something worse.
As a side note, the reason I couldn't find the original sort in question
is that I later scraped it in favor of a more robust 100 line sub to
figure out who ranked where.
But in more common case, how much it break things to have
type Comparator ::= Code(Any, Any) returns Int;
become
type Comparator ::= Code(Any, Any) returns Int
| '!' Code(Any, Any) returns Int;
where the '!' sets the reverse/descending trait?
So we could get things like:
@out = sort {!~ $_} @in;
@out = sort {!+ -M} @in;
@out = sort {! &complex} @in;
Overall, Damian's proposal looks very good.
Yeah Damian!
-- Rod Adams
PS -- Only pure and utter insanity would lead someone to not make string
the default sort comparator, and I don't think I've heard anyone here
me
Re: Traits: to renew OO inheritance in a hacker style discussion
On Fri, Feb 13, 2004 at 01:22:38PM +0300, Dmitry Dorofeev wrote: : My stupid question still apply. : Will it be possible to have : 'Exclusion' which forms a new trait|Role by removing a method from an : existing trait|Role ? There will certainly be some way to exclude or at least hide the method from a role. The trick is to prevent people from making false assumptions about whether the object can bark just because $object.does(Dog) returns true. Or maybe it's not that important, if we can train people to rely on multiple dispatch to decide these things. : or should I read some docs on Roles to be smarter ? Right after I finish writing them... :-) Larry
Re: Multiply perl versions.
Ruslan U. Zakirov wrote: Hello, all. I have several questions about multiply perl versions. Im not sure this Q is on-topic, but here goes. (btw, its multiple, as in many, not multiply, as opposite of divide) 1) I have got RH9 and FreeBSD and when I was setting up perl5.8.1 script ask me "do I want override old perl exec file", but on FreeBSD I wasn't asked. I want same prefix for all versions of perl, but want split @INC absolutely(It's ok, i've done it), but I want new version don't overwrite old perl binary file(/usr/bin/perl). sh Configure -Uusrinstallbin sh Configure -?for help cat config.sh to see existing configuation 2) Is there an easy way to use current perl configuration info(perl -V) to build new one, even better if I can use current configuration as default, but adjust changes to it. rerunning Configure automatically reuses your previous config.sh, you can override it by using -O option, with -D, -U 3) May be it's better to split prefix, isn't it? For eg: /usr/bin/perl5.8.2/, /usr/bin/perl5.8.3 Probably. Alhough shared prefix works (I have: $ ls /usr/local/lib/perl5/ 5.6.2 5.8.0 5.8.1 5.8.2 5.8.3 5.9.0 site_perl /usr/local/lib/perl5/site_perl: 5.6.1 5.6.2 5.8.0 5.8.1 5.8.2 5.8.3 5.9.0 ), there are a few areas of conflict: 1. perl exe is overwritten by last install. (ameliorated by also installing /usr/local/bin/perl5.8.x) 2. cant have unthreaded/threaded of same version, unless manually renamed ( but they can coexist in lib, ex: lib/5.8.x/i686-linux-thread-multi ) 3. cant have static/shared libperl without separate prefixes (unless Ive over-simplified) 4. others ? 4) Is it save to use same @INC with 5.8.x branch? Im not sure what youre getting at - @INC is computed during Configure, and generally does the right thing: 5.8.3 will include 5.8.[0-2] automatically. Best regards. Ruslan. .
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
