Re: More object stuff
Harry Jackson <[EMAIL PROTECTED]> wrote: > I am at the point now where I need to know what type of format you want > the data to come out in. The first question is: how are these data returned in C. If that's a defined structure, I'd overlay this structure with an UnManagedStruct PMC and then access the structure with accessors of that PMC - neede still some types as well as handling of nested types - but this avoid creating of new objects and should be rather efficient. > Harry Jackson leo
Re: More object stuff
Harry Jackson wrote:
Dan Sugalski wrote:
> getting back a full row as an array, getting back a full
row as a hash, and stuff like that. Nothing fancy, and nothing that
high-level, but enough to work the basics without quite as manual work
as the current libpg requires.
OK.
I am at the point now where I need to know what type of format you want
the data to come out in.
We have the following options although some of them will be impractical
in production. I can drop the data into any type of structure currently
available to Parrot at least I am pretty sure I can.
I can create the entire dataset and return this out to the caller as a
hash of arrays or some other structure. For large datasets this will be
completey impractical but I am highlighting it as an option for testing
or possibly avoiding multiple calls between Parrot and Any Old Language
(AOL).
We can call a funtion to return the data in any format you want ie a
single record per call gets passed back. This method will probably be
the closest to most libraries in circulation and is the one that makes
most sense to me. It could be extended to pass back N records depending
on what the caller wants, this might be faster than making lots ot AOL
calls to Parrot but would involve some more work on our part.
For later use would it make it easier for people at a higher abstraction
if some metadata gets passed about the data ie the very first row
returned contains an array of types subsequent calls will return. Perl
is lovely the way it converts types but this might not be very practical
for other languages that are a bit more strict about stuff like this. At
the moment I am using "strings" for all the data coming from the
database but this wont work for everyone. This needs to be decided now
to avoid a re-write later. It would make my life easier if the guys at
the top where to deal with type conversion but I am not sure this is
good choice.
The following is what I have come up with to date as far as accessing
data in Postgres is concerned. There is very little error handling in
the library at the moment which is something that needs to be addressed
but I can start work on that as soon as the API has been agreed on.
I am fishing for some feedback to see if this is suitable or if it needs
to be changed. The following code is an example of extracting 10,000
rows with field names and types. The types are integers which are local
to Postgres so we probably need to come up with an agreed format for
type identifiers.
1 .pcc_sub _MAIN prototyped
2 .param pmc argv
The first lib is the standard pasm lib that ships with the parrot
source. The second i simply a lib I have created to hold some function
declarations etc.
3 .include "/home/parrot/parrot/library/postgres.pasm"
4 .include "/home/parrot/lib/postgreslib.imc"
5 .local string dbstring
6 dbstring = "host=host dbname=Forum user=u password=pass"
7 .local int answer
8 print "Entering Connect\n"
The call to connect makes whatever calls etc required to get a
connection to the database.
9
10 .pcc_begin prototyped
11 .arg dbstring
12 .pcc_call connect
13 retconnect:
14 .result CONN
15 .result answer
16 .result message
17 .pcc_end
The MetaData hash contains various meta data about the connection ie
filed types and names.
18
19 .local PerlHash MetaData
20 MetaData = new PerlHash
21 MetaData = global "MetaData"
22
23 .PRINT("Connection Message = ", message, " \n")
24 .PRINT("Connection state = ", answer, " \n")
25 eq -1, answer, fail
26 eq 1, answer, go
27 fail:
28 .PRINT("\n", message, "\n")
29 end
30 go:
31
32 .local string query
33 query = "select * from parrot"
34
35 print "Entering Send Query \n"
36 .pcc_begin prototyped
37 .arg CONN
38 .arg query
39 .pcc_call pqsendquery
40 pqsendquery:
41 .result message
42 .pcc_end
The pqgetresult call will populate the MetaData hash with details of the
call.
43
44 .PRINT("Execution = ", message, "\n")
45 .pcc_begin prototyped
46 .arg CONN
47 .pcc_call pqgetresult
48 retrecords:
49 .pcc_end
50 .local int rowcounter
51 rowcounter = MetaData["ROWCOUNT"]
52 eq -1, rowcounter, finished
53
The following bit of code is here to test that fieldnames and types have
been filled correctly.
54
55 .local int Oid_type
56 .local int onfield
57 onfield = 1
58 .local PerlArray TupleData
59 TupleData = new PerlArray
60 TupleData = MetaData["FIELDDATA"]
61 .local int fnum
Questions about abstract pmcs
Abstract pmcs should appear in core_pmcs.h and pmctypes.pasm because one needs them as base pmcs so as to declare pseudo-registers. This is a prerequisite to add pmc type checking to imcc. Working on a patch to fix that, I got some questions to be answered. Unlike other pmcs, abstract pmcs have names that are all lower case, is that deliberate? What is the difference between declaring a pmc as C or as C? Currently when one is set, the other is also set. For sake of some kind of introspection, it may useful to generate a vtable in the C file generated for an abstract class albeit with init methods that trigger exception. -- stef
Re: .sym var removed/replaced?
> At 11:01 PM + 1/11/04, Jonathan Worthington wrote: > >Hi, > > > >In t/examples/pni/win32api.t I have this:- > > > > # Load user32.dll library and the MessageBoxA API. > > .sym var libuser32 > > .sym var MessageBoxA > > loadlib libuser32, "user32" > > dlfunc MessageBoxA, libuser32, "MessageBoxA", "llttl" > > > >Which used to work fine, however now I get:- > > > >error:imcc:Unknown PMC type 'var' > > > >What should I now be using in place of var? > > That ought to be: > >.local pmc libuser32 > > though it looks like ".sym pmc" might work. > > Switching over from .sym to .local is probably the right thing to do, though. Thanks - and here's a patch. Jonathan win32api.imc.diff Description: Binary data
Re: .sym var removed/replaced?
At 11:01 PM + 1/11/04, Jonathan Worthington wrote: Hi, In t/examples/pni/win32api.t I have this:- # Load user32.dll library and the MessageBoxA API. .sym var libuser32 .sym var MessageBoxA loadlib libuser32, "user32" dlfunc MessageBoxA, libuser32, "MessageBoxA", "llttl" Which used to work fine, however now I get:- error:imcc:Unknown PMC type 'var' What should I now be using in place of var? That ought to be: .local pmc libuser32 though it looks like ".sym pmc" might work. Switching over from .sym to .local is probably the right thing to do, though. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
.sym var removed/replaced?
Hi, In t/examples/pni/win32api.t I have this:- # Load user32.dll library and the MessageBoxA API. .sym var libuser32 .sym var MessageBoxA loadlib libuser32, "user32" dlfunc MessageBoxA, libuser32, "MessageBoxA", "llttl" Which used to work fine, however now I get:- error:imcc:Unknown PMC type 'var' What should I now be using in place of var? Thanks, Jonathan
lookahead for parrot/perl[5|6]?
First off apologies if there is some posting/site which details this well - I started at www.parrotcode.org and spent a while fruitlessly wondering why noone had posted at the mailing list archive nicely html'ified http://archive.develooper.com/[EMAIL PROTECTED]/ for a while before finding the far more useful active state site (which would be nice to link from parrotcode.org for occassional watchers like myself). Anyway, even with search I couldn't find an answer... so... i'm hoping someone can enlighten me. I run a large a Perl5 based project and although we are rather dangerously addicted to Perl5, the reference counting GC, lack of good threads and inability to have (optional) compile-time checking is a real pain in the arse for the amount of code we have. We also have a parallel Java API for our system, and although Java does behave v. annoyingly in some cornor cases in some implementations the strong compile-time checking and then the cute integration with Jython for lightweigt scripting is pretty close to heaven... [Yup; we have played with Inline::Java - got burnt one year ago, we are taking it for a spin in another project now, but this does seem essentially clunky] Now - an ideal world would be: Perl-5 or Perl-5 like syntax for lightweight scripting Java or Java-like syntax for objects An consistent, few-cornor case, executation engine that can handle circular references and threads Embeddable in Apache like mod_perl perl6 as a language looks cute, but... is not so necessary. So... my question is - Can anyone give me dates for the above features in the parrot/perl[5|6] path? Is it "sometime in 2004" for an alpha release or "sometime in 2005" for an alpha release or "we're really not sure, check back in 6 months?" And, out of interest, what is the rate limiting step for this (amount of coffee given to Dan?) I realise this is a somewhat frustrating question to answer, but any answers (even partial) would help thanks ewan
Re: [perl #24866] [PATCH] Unified harness for IMCC tests
On Jan 11, 2004, at 3:10 AM, Leopold Toetsch wrote: Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote: 'make fulltest' gives 6 reports. 5 reports for different parrot options plus 1 report for t/src/*.t. Dou you see a simple way, to run all tests in one harness for "fulltest". That would need some configure hints, which run-loops are available and then run one test X times in a loop with the appropriate run-loop switch - or something like that. I have a patch which lets you run multiple sets of tests in t/harness, and get one summary at the end. (I was working a bit on the same problem as Bernhard, but from a different direction, so I think we have met in the middle.) Essentially, it lets you do things such as this: perl t/harness -b t/op/*.t t/pmc/*.t t/src/*.t -j t/op/*.t t/pmc/*.t instead of having to do: perl t/harness -b t/op/*.t t/pmc/*.t t/src/*.t perl t/harness -j t/op/*.t t/pmc/*.t and gives you a single summary at the end. Unfortunately it requires modification of Test::Harness to allow multiple sets of tests to be summarized together, so we'd have to add that to the repository along with our other Test:: modules. But it's a straightforward modification. I'll clean up my t/harness changes to make them relative to Bernhard's patch, and send it all in. JEff
Re: yield op?
On Sun, 11 Jan 2004, Leopold Toetsch wrote: > Michal Wallace <[EMAIL PROTECTED]> wrote: > > When you invoke a Coroutine, it calls swap_context() > > from src/sub.c ... There's an else clause in there > > that either swaps or restores theinterpreter stack, > > but as far as I can tell, swap_context() is ONLY > > called when entering a coroutine - not when we're > > suspending it. > > No, swap_context() is called for each invoke of the Coroutine, that is > ok. But (as with Continuations) the register frame stacks are *not* > swapped. So the "zero" in your example (in P16) is shared between the > Coroutine and main. Yes, that's what I meant. It's called each time you invoke the coroutine. I don't understand why it doesn't have to be swapped back each time you suspend the coroutine. But then again, I tried fixing it myself and it didn't work... Maybe I'll understand once I see how you fix it. > If no one hollers, I'll apply Luke's patch WRT register stacks and > Continuations and then fix Coroutines. Awesome! Thanks! Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
Re: patch to support nums, strings and pmcs as attributes
On Sun, Jan 11, 2004 at 12:33:16PM +0100, Leopold Toetsch wrote:
> Stéphane Payrard <[EMAIL PROTECTED]> wrote:
>
> Thanks, applied - plus ...
>
> > INTVAL get_integer_keyed (PMC* attr) {
> > - return SELF.get_integer_keyed_str(key_string(interpreter, attr));
> > +int flag = PObj_get_FLAGS(attr) & KEY_type_FLAGS;
>
> ... a comment, why we might need that.
>
> leo
Also the following patch exercises all the variations including
the susmentioned access thru a key pmc that may contain either a
string or an int.
A previous version I tried to attach to a mail and eventually got
attached as a Fortran file must be ignored. With the present
patch, the test is now included in objects.t instead of being a
separate file.
--
stef
--- t/pmc/objects.t.orig2003-12-05 17:00:25.0 +0100
+++ t/pmc/objects.t 2004-01-11 19:21:48.0 +0100
@@ -1,6 +1,6 @@
#! perl -w
-use Parrot::Test tests => 22;
+use Parrot::Test tests => 24;
use Test::More;
output_is(<<'CODE', <<'OUTPUT', "findclass (base class)");
@@ -565,3 +565,271 @@
130
140
OUTPUT
+
+
+output_is(<<'CODE', (join '', map { "$_\n" }42..65), "attributes");
+ newclass P0, "Foo"
+ find_type I1, "Foo"
+ addattrib I0, P0, "b"
+ addattrib I0, P0, "l"
+ addattrib I0, P0, "a"
+ new P1, I1
+
+ set P1["Foo\x00a"], 42
+ set I2, P1["Foo\x00a"]
+ print I2
+ print "\n"
+
+ set S0, "Foo\x00a"
+ set P1[S0], 43
+ set I2, P1[S0]
+ print I2
+ print "\n"
+
+ set P1[2], 44
+ set I2, P1[2]
+ print I2
+ print "\n"
+
+ set I3, 2
+ set P1[I3], 45
+ set I2, P1[I3]
+ print I2
+ print "\n"
+
+
+
+ new P2, .Key
+ set P2, "Foo\x00a"
+
+ set P1[P2], 46
+ set I2, P1[P2]
+ print I2
+ print "\n"
+
+ new P2, .Key
+ set P2, 0
+
+ set P1[P2], 47
+ set I2, P1[P2]
+ print I2
+ print "\n"
+
+
+
+# strings
+
+ set P1["Foo\x00a"], "48"
+ set S2, P1["Foo\x00a"]
+ print S2
+ print "\n"
+
+ set S0, "Foo\x00a"
+ set P1[S0], "49"
+ set S2, P1[S0]
+ print S2
+ print "\n"
+
+ set P1[2], "50"
+ set S2, P1[2]
+ print S2
+ print "\n"
+
+ set I3, 2
+ set P1[I3], "51"
+ set S2, P1[I3]
+ print S2
+ print "\n"
+
+
+
+ new P2, .Key
+ set P2, "Foo\x00a"
+
+ set P1[P2], "52"
+ set S2, P1[P2]
+ print S2
+ print "\n"
+
+ new P2, .Key
+ set P2, 0
+
+ set P1[P2], "53"
+ set S2, P1[P2]
+ print S2
+ print "\n"
+
+# pmc
+
+
+ set P1["Foo\x00a"], 54
+ set P4, P1["Foo\x00a"]
+ print P4
+ print "\n"
+
+ set S0, "Foo\x00a"
+ set P1[S0], 55
+ set P4, P1[S0]
+ print P4
+ print "\n"
+
+ set P1[2], 56
+ set P4, P1[2]
+ print P4
+ print "\n"
+
+ set I3, 2
+ set P1[I3], 57
+ set P4, P1[I3]
+ print P4
+ print "\n"
+
+
+
+ new P2, .Key
+ set P2, "Foo\x00a"
+
+ set P1[P2], 58
+ set P4, P1[P2]
+ print P4
+ print "\n"
+
+ new P2, .Key
+ set P2, 0
+
+ set P1[P2], 59
+ set P4, P1[P2]
+ print P4
+ print "\n"
+
+
+ set P1["Foo\x00a"], "60"
+ set P4, P1["Foo\x00a"]
+ print P4
+ print "\n"
+
+ set S0, "Foo\x00a"
+ set P1[S0], "61"
+ set P4, P1[S0]
+ print P4
+ print "\n"
+
+ set P1[2], "62"
+ set P4, P1[2]
+ print P4
+ print "\n"
+
+ set I3, 2
+ set P1[I3], "63"
+ set P4, P1[I3]
+ print P4
+ print "\n"
+
+
+
+ new P2, .Key
+ set P2, "Foo\x00a"
+
+ set P1[P2], "64"
+ set P4, P1[P2]
+ print P4
+ print "\n"
+
+ new P2, .Key
+ set P2, 0
+
+ set P1[P2], "65"
+ set P4, P1[P2]
+ print P4
+ print "\n"
+ end
+CODE
+
+my $output_re = join '', map { "$_.00.*[\\n\\r]+" } 4..15;
+$output_re = qr/^$output_re$/;
+output_like(<<'CODE', $output_re , "float attributes");
+ newclass P0, "Foo"
+ find_type I1, "Foo"
+ addattrib I0, P0, "b"
+ addattrib I0, P0, "l"
+ addattrib I0, P0, "a"
+ new P1, I1
+
+
+ set P1["Foo\x00a"], 4.1
+ set N2, P1["Foo\x00a"]
+ print N2
+ print "\n"
+
+
+ set S0, "Foo\x00a"
+ set P1[S0], 5.1
+ set N2, P1[S0]
+ print N2
+ print "\n"
+
+
+ set P1[2], 6.1
+ set N2, P1[2]
+ print N2
+ print "\n"
+
+ set I3, 2
+ set P1[I3], 7.1
+ set N2, P1[I3]
+ print N2
+ print "\n"
+
+ new P2, .Key
+ set P2, "Foo\x00a"
+ set P1[P2], 8.1
+ set N2, P1[P2]
+ print N2
+ print "\n"
+
+ new P2, .Key
+ set P2, 0
+ set P1[P2], 9.1
+ set N2, P1[P2]
+ print N2
+ print "\n"
+
+ set P1["Foo\x00a"], 10.1
+ set P4, P1["Foo\x00a"]
+ print P4
+ print "\n"
+
+ set S0, "Foo\x00a"
+ set P1[S0], 11.1
+ set P4, P1[S0]
+ print P4
+ print "\n"
+
+ set P1[2], 12.1
+ set P4, P1[2]
+ print P4
+ print "\n"
+
+ set I3, 2
+ set P1[I3], 13.1
+ set P4, P1[I3]
+ print P4
+ print "\n"
+
+
+ new P2, .Key
+ set P2, "Foo\x00a"
+ set P1[P2], 14.1
+ set P4, P1[P2]
+ print P4
+ print "\n"
+
+ new P2, .Key
+ set P2, 0
+ set P1[P2], 15.1
+ set P4, P1[P2]
Re: More object stuff
Dan Sugalski wrote: > getting back a full row as an array, getting back a full row as a hash, and stuff like that. Nothing fancy, and nothing that high-level, but enough to work the basics without quite as manual work as the current libpg requires. OK. I am at the point now where I need to know what type of format you want the data to come out in. We have the following options although some of them will be impractical in production. I can drop the data into any type of structure currently available to Parrot at least I am pretty sure I can. I can create the entire dataset and return this out to the caller as a hash of arrays or some other structure. For large datasets this will be completey impractical but I am highlighting it as an option for testing or possibly avoiding multiple calls between Parrot and Any Old Language (AOL). We can call a funtion to return the data in any format you want ie a single record per call gets passed back. This method will probably be the closest to most libraries in circulation and is the one that makes most sense to me. It could be extended to pass back N records depending on what the caller wants, this might be faster than making lots ot AOL calls to Parrot but would involve some more work on our part. For later use would it make it easier for people at a higher abstraction if some metadata gets passed about the data ie the very first row returned contains an array of types subsequent calls will return. Perl is lovely the way it converts types but this might not be very practical for other languages that are a bit more strict about stuff like this. At the moment I am using "strings" for all the data coming from the database but this wont work for everyone. This needs to be decided now to avoid a re-write later. It would make my life easier if the guys at the top where to deal with type conversion but I am not sure this is good choice. The following is the table that I am testing this against. There are only very few of the basic types here although for what I have done at the moment the types have no real affect. This table is loaded with 1 records (not realistic data). Table "public.test" Column |Type | Modifiers +-+--- _key | integer | not null _bigint8 | bigint | _bool | boolean | _char | character(10) | _varchar | character varying(100) | _float8| double precision| _int | integer | _float4| real| _int2 | smallint| _text | text| _timestamp | timestamp without time zone | default now() Indexes: parrot_pkey primary key btree (_key) For the speed freaks doing "select * from test" real0m0.997s user0m0.630s sys 0m0.010s Displaying all 1 records to screen as follows 9996 9176 t a Varchar here 9176 9176 9176 9176 smallint <- Text here -> timestamp 2004-01-11 16:45:28.79144 9997 2182 t a Varchar here 2182 2182 2182 2182 smallint <- Text here -> timestamp 2004-01-11 16:45:28.79379 9998 4521 t a Varchar here 4521 4521 4521 4521 smallint <- Text here -> timestamp 2004-01-11 16:45:28.79614 4152 t a Varchar here 4152 4152 4152 4152 smallint <- Text here -> timestamp 2004-01-11 16:45:28.79849 real0m4.189s user0m0.570s sys 0m0.280s Any requests, pointers, advice, abuse or general chit chat welcome. Harry Jackson
[RESEND] Q: Array vs SArray
[ warnocked ] Leopold Toetsch <[EMAIL PROTECTED]> wrote: > The set_integer_native() vtable method of arrays is implemented > inconsistently. The old historical way in Array was to set an initial > size. My implementation in SArray OTOH only reserves the needed store, > but doesn't change the element count. > new P0, .SArray > set P0, 2 > set I0, P0 # SArray.elements() > print I0 > new P1, .Array # or .PerlArray > set P1, 2 > set I1, P1 # Array.elements() > print I1 > print "\n" > end > 02 > This is bad. But it gets worse: You can do "push P0, x" twice on the > SArray, filling the first 2 elements. You can't do that on Array. It > would set the element #2 which is beyond the preset element count - push > is currently not usable for Array PMCs. (PerlArray works basically like > Array but does auto-extend) > I'd like to unify the behavior and get best from these two worlds: > 1) can set an initial store size and (if really needed) > 2) can set an initial element count, not-yet set values are NULL. > One further note, while at Array/PerlArray: the class dependency is > suboptimal. PerlArray isa Array isa list. The underlying list is > auto-extending and does no bounds checking. Array does bounds-checking. > PerlArray doesn't bounds check. So for better performace and simpler > code, the dependency of PerlArray and Array should be swapped. > Comments welcome, > leo leo
[RESEND] Re: pdd03 and method calls
[ I think this still needs some clarification ] Leopold Toetsch <[EMAIL PROTECTED]> wrote: > Dan Sugalski <[EMAIL PROTECTED]> wrote: >> At 10:42 PM +0100 12/17/03, Leopold Toetsch wrote: >>>While playing with calling threaded subs, I came along a thing which >>>I think might be suboptimal: >>>pdd03 states that the method PMC should go into P2. This doesn't >>>really play with Perl5 <-> Perl6 interoperbility IMHO. Perl5 methods >>>are plain subs, where the first param is the object. >> PDD 03 states that the *object* goes in P2. > Yep, typo - sorry. >> This works out just fine >> with perl 5 style method calls, where the argument list doesn't >> distinguish the object other than by position. What happens is that >> when a perl 5 sub is called, @_ is a combination of P2 if it's >> non-NULL, and the remaining PMC registers. It's slightly more work >> for the perl 5 code generator to handle the check, but other than >> that it shouldn't be a problem. > That seems to indicate, that we have to expose the whole parameter > passing to HLLs and that Perl5 (and probably other languages) can't use > the builtin PIR shortcuts (or we have to provide both schemes depending > on some pragma directive). > Additionally to the test: > isnull P2, no_object# must be set to NULL on non-method calls > we would need 2 code paths: For leaf subs[1], one can use registers as > is, one would need rearanging the param regs. > And as outlined by Juergen it doesn't fit very well for calling NCI PMC > class methods: We would need another signature letter to denote the > object. > That's of course all doable but is adding assymmetry to method calls, > which I don't like much. > [1] these just use P5..Pn as passed in. > leo leo
Re: yield op?
Michal Wallace <[EMAIL PROTECTED]> wrote: > Hey all, > When you invoke a Coroutine, it calls swap_context() > from src/sub.c ... There's an else clause in there > that either swaps or restores theinterpreter stack, > but as far as I can tell, swap_context() is ONLY > called when entering a coroutine - not when we're > suspending it. No, swap_context() is called for each invoke of the Coroutine, that is ok. But (as with Continuations) the register frame stacks are *not* swapped. So the "zero" in your example (in P16) is shared between the Coroutine and main. If no one hollers, I'll apply Luke's patch WRT register stacks and Continuations and then fix Coroutines. leo
Re: additional test file for parrotobject.pmc
On Sat, Jan 10, 2004 at 10:30:47PM +0100, Stéphane Payrard wrote: > retry You're trying to attache a file with a name ending in .t ? They get eaten. I forget why. And I forget why it's not been possible to change the configuration on the list software to tell it that it's on a diet. Nicholas Clark
Re: Some imc questions
Leopold Toetsch wrote: Harry Jackson <[EMAIL PROTECTED]> wrote: 251 .local pmc CONN 252 .local int int_answer 253 print "About to Connect\n" 254 P0 = C[0] 255 S5 = s 256 invoke 257 CONN = P5 Calling the sub is something like this (untested): .pcc_begin prototyped .arg dbstring .nci_call PQCONNECTSTART .result CONN .pcc_end Running this fails with the followng error. set_string_native() not implemented in class 'PerlArray' If such errors occur it helps to run the code with tracing turned on: $ parrot -t code.imc and to have a look at the generated PASM $ parrot -o- code.imc | less I have been reading the pasm using this method without tracing and it has highlighted my abuse of pdd03 which up until now has been rather enthusiastic. I have stared changing the code to adhere to the calling conventions a bit more. Harry
Re: [perl #24868] [PATCH] floor/ceil ops
Lars Balker Rasmussen <[EMAIL PROTECTED]> wrote: > I have added floor and ceil ops (like I did for floor in september, > but noone noticed). Thanks, applied. leo
Re: configure on windows
On Tue, Nov 18, 2003 at 09:57:02AM -0500, Dan Sugalski wrote: > FWIW, with these changes rather than using the literal "perl" use $^X > instead. That picks up the perl being used rather than whatever comes > first in the search path, which may not be the perl being used for > configure. There was a time when the first perl in my $PATH was /bin/false I might make that the case on my tinderbox. Muahahahahaha. Nicholas Clark
Re: [perl #24866] [PATCH] Unified harness for IMCC tests
On Sun, Jan 11, 2004 at 12:10:16PM +0100, Leopold Toetsch wrote: > Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote: > > Hi, > > > this patch is an attempt at resolving an item from 'parrot/TODO': > >Unify t/* and imcc/t/* tests, so that one harness has just one > > result summary. > > Fine, thanks - applied. It broke my tinderbox, because it assumed that . was in $PATH I committed a fix. Nicholas Clark
Re: [perl #24866] [PATCH] Unified harness for IMCC tests
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote: > Hi, > this patch is an attempt at resolving an item from 'parrot/TODO': >Unify t/* and imcc/t/* tests, so that one harness has just one > result summary. Fine, thanks - applied. > 'make fulltest' gives 6 reports. 5 reports for different parrot options plus > 1 report for t/src/*.t. Dou you see a simple way, to run all tests in one harness for "fulltest". That would need some configure hints, which run-loops are available and then run one test X times in a loop with the appropriate run-loop switch - or something like that. > CU, Bernhard leo
Re: [perl #24867] [PATCH] more t/src cleanup
Lars Balker Rasmussen <[EMAIL PROTECTED]> wrote: > I have rewritten some more of the tests in t/src to use the "proper" > approach to doing resource-juggling. The tests that I haven't touched > don't seem to be reliant on this. Thanks, applied leo
Re: patch to support nums, strings and pmcs as attributes
Stéphane Payrard <[EMAIL PROTECTED]> wrote:
Thanks, applied - plus ...
> INTVAL get_integer_keyed (PMC* attr) {
> - return SELF.get_integer_keyed_str(key_string(interpreter, attr));
> +int flag = PObj_get_FLAGS(attr) & KEY_type_FLAGS;
... a comment, why we might need that.
leo
Re: [PATCH] The Return of the Priority DOD
On Sat, Jan 10, 2004 at 04:25:58PM -0800, Jeff Clites wrote: > allocate chunks of memory with arbitrary power-of-2 alignment. So all > the platforms being tested on the tinders probably have this. (Of > course, you can manually set ARENA_DOD_FLAGS to false in the source, > for testing.) My tinderbox running on FreeBSD definitely didn't have it, and the OpenBSD tinderbox returned from burning to success at the same time as mine. (Not that I've checked the actual case of its failure, but I think only one patch got committed around then) Nicholas Clark
Re: Some imc questions
Harry Jackson <[EMAIL PROTECTED]> wrote: > Commanlib.imc is where I will build an array to contain all the subs to > call. >1 .local PerlArray Command >2 Command = new PerlArray >3 >4 Command[0] = PQCONNECTSTART I'd toss that part that generateds the command array. > 241 .pcc_sub _connect prototyped > 246 > 247 .local PerlArray C > 248 C = new PerlArray > 249 C = Command This doesn't copy the command array, its just gets an alias, i.e. both C and Command point to the original Array. I'd just retrieve the global here. > 251 .local pmc CONN > 252 .local int int_answer > 253 print "About to Connect\n" > 254 P0 = C[0] > 255 S5 = s > 256 invoke > 257 CONN = P5 Calling the sub is something like this (untested): .pcc_begin prototyped .arg dbstring .nci_call PQCONNECTSTART .result CONN .pcc_end > Running this fails with the followng error. > set_string_native() not implemented in class 'PerlArray' If such errors occur it helps to run the code with tracing turned on: $ parrot -t code.imc and to have a look at the generated PASM $ parrot -o- code.imc | less > Harry leo
Re: [PATCH] The Return of the Priority DOD
Nicholas Clark <[EMAIL PROTECTED]> wrote: > How come most tinderboxes kept going without failing? What's making the > choice on the value of ARENA_DOD_FLAGS ? ARENA_DOD_FLAGS is turned on by default. If there is no memalign or such library function (which it depends on), this define is disabled. > Nicholas Clark leo
Re: [PATCH] bug in clear_live_bits
Luke Palmer <[EMAIL PROTECTED]> wrote: > sweep 0 was making parrot segfault for me. The patch explains why. Oops, thanks - applied, leo
Re: Contextual calls
Luke Palmer <[EMAIL PROTECTED]> wrote: > I was uneasy when the C and C vtable entries were first > proposed. Sure, they get the job done for Perl 5, but Perl 6 is > expanding its notion of context beyond those compiled in. You're > supposed to be able to add, say, "nontransitive ring" context if you > want. When adding a "nontransitive ring" that has to be expressed in terms of existing PIR. Context handling is up to the HLL compiler. > num_eq $P0, $P1, foo > str_eq $P0, $P1, bar > Becomes > context .NUMERIC > eq $P0, $P1, foo > context .STRING > eq $P0, $P1, bar > This works efficiently since context often propigates inward, as in: Doubling opcodes isn't efficient. The Perl6 compiler has to know the context, so it can emit the correct compare opcode. > Luke leo
Contextual calls
I was uneasy when the C and C vtable entries were first
proposed. Sure, they get the job done for Perl 5, but Perl 6 is
expanding its notion of context beyond those compiled in. You're
supposed to be able to add, say, "nontransitive ring" context if you
want.
There needs to be a way to pass context into not only sub calls, but
vtable methods, and maybe even certain non-vtable ops. Rather than add
an extra op parameter for each of these, I propose we make it stateful,
like:
num_eq $P0, $P1, foo
str_eq $P0, $P1, bar
Becomes
context .NUMERIC
eq $P0, $P1, foo
context .STRING
eq $P0, $P1, bar
This works efficiently since context often propigates inward, as in:
if $x + $y > $z {...}
---
num
num
---
bool
And that, like classes, contexts would be specified by integer
descriptor, or at worst, constant PMC.
This might also be modified to fit in nicely with the proposed "key
registers" idea.
Luke
