Expletive/Objects and pdd15
In PDD 15 it says Creating a new class with attributes Adding the attributes a and b to the new class Foo: newclass $P0, Foo addattribute $P0, a, Foo::a # This is offset 0 addattribute $P0, b, Foo::b # This is offset 1 maybe I'm just being a numpty but should this not be Creating a new class with attributes Adding the attributes a and b to the new class Foo: newclass $P0, Foo addattribute $P0, a # Foo::a This is offset 0 addattribute $P0, b # Foo::b This is offset 1 I tried it the other way but could not add attributes to objects but I can do. newclass $P0, Foo addattribute $P0, a If this is the case there is a patch for pdd15 attached. Harry --- pdd15_objects.pod 2004-03-26 21:57:16.0 + +++ pdd15_objects_new.pod 2004-03-27 22:10:50.0 + @@ -441,8 +441,8 @@ Adding the attributes Ca and Cb to the new class CFoo: newclass $P0, Foo - addattribute $P0, a, Foo::a # This is offset 0 - addattribute $P0, b, Foo::b # This is offset 1 + addattribute $P0, a # Foo::a This is offset 0 + addattribute $P0, b # Foo::b This is offset 1 =head2 Instantiating an object
Re: Dependency cleanup in generated makefile
Dan Sugalski wrote: I've fixed up the dependency problem in the makefile generation that was getting in the way of multithreaded makes. Shouldn't cause any problems, but it never hurts to double-check these things elsewhere. Was that were make -jN was failing. I tried to get this running for ages and got absolutely nowhere with it, it was like walking in a minefield. Harry -- Regards, Harry Jackson.
Re: Objects and time
Leon Brocard wrote: Dan Sugalski sent the following bits through the ether: Objects please! I would second that. I would prefer a cool release to a cool date ;-) Harry Jackson
Re: Backward branch, warnocked.
Pete Lomax wrote: Leo clarified this as a problem with backward branch circa 3/12/03: Sorry to be a pain in the butt, but I need to be told that there has been no improvement in the last two months on this ;-( ..sub _main goto L1 test: $I1 = 1 ret L1: $I2 = 2 call test print $I2 # prints 1, not 2 end ..end Surely it can't just be me that thinks this is rather fundamental? How fundamental *is* the problem, can it *ever* be fixed? Again, sorry to be a pain, but I'd like the truth/an update, please! Or some hints... file level variables... better ways to code this... Pete PS use parrot -o and examine the output .pasm:, $I1 and $I2 (or ..local int i, .local int j) get assigned the same register. Not sure if this answers your question. At the bottom of this email there is a bit taken from the IMCC.faq, I have pointed to the bit that I think may tell us what has happened. When the above piece of code gets converted to pasm we get 1 _main: 2 branch L1 3 test: 4 set I16, 1 5 ret 6 L1: 7 set I16, 2 8 bsr test 9 print I16 10 end 11 12 This is a branch not a subroutine call so IMCC as per the spec does not take care of the scoping in this case. To code it using subs we could use 1 .sub _main prototyped 2.sym Sub connect 3newsub connect, .Sub, _connect 4 5 $I1 = 2 6 .pcc_begin prototyped 7 .pcc_call connect 8 retconnect: 9 .pcc_end 10 print $I1 11 end 12 .end 13 14 .sub _connect 15 $I1 = 1 16 print $I1 17 .pcc_begin_return 18 .pcc_end_return 19 .end This prints 12 as expected. Harry Taken from the IMCC.faq What are IMC variables? IMC has 2 classes of variables, symbolic registers and named variables. Both are mapped to real registers, but there are a few minor differences. Named variables must be declared. They may be global or local, and may be qualified by a namespace. Symbolic registers, on the other hand, do not need declaration, -but their scope never extends outside of a subroutine unit. Symbolics registers basically give compiler front ends an easy way to generate code from their parse trees or AST. To generate expressions compilers have to create temporaries. Symbolic Registers (or Temporaries) Symbolic registers have a $ sign for the first character, have single letter (S,N,I,P) for the second character, and 1 or more digits for the rest. By the 2nd character IMCC determines which set of Parrot registers it belongs to.
Re: Some minor decisions and timetables
Dan Sugalski wrote: Okay, here's a quick scoop and status. *) I'd like to shoot for a Feb 14th release. Names wanted. (I'm partial to the bleeding heart release, but not that partial) You can always find some reference to a bird in it somewhere http://www.newadvent.org/cathen/15254a.htm We could name it after the following painting/painter Valentine Cameron Prinsep or one of his names. When people ask why we named it after a saint we can tell them we didn't, we named it after a painter. He painted the following picture. http://www.artmagick.com/paintings/painting3593.aspx she was having a bad hair day. Or in a show of support for our fellow parrots: We could call it the kakapo release or at least dedicate it to the kakapo. Not sure if everyone would think a nearly extinct parrot is a good metaphor ;-) http://news.bbc.co.uk/1/hi/sci/tech/1849686.stm Or we could go with the lovebird release. Lovebirds are some of the smallest types of parrot. Please read more here. http://www.parrotparrot.com/lovebirds/ *) I'm just going to get the final damn object stuff finished. It's 80% there and I should just stop wincing every time I look at objects... This would be lovely. *) It's time for doc patches! If folks have helpful suggestions or experiences, post a patch to docs/practical_notes.pod in a =head2 section. Not as good as a full tutorial, but better than nothing. Patch at the top so things slot in with a minimum of patch whining. *) I'll try and patch up the docs, and I'll concentrate on the PDDs, but any help on them is greatly appreciated. *Especially* IMCC docs. Do we need an NCI section in the IMCC.faq. If the vote is yes I do not mind knocking something up. Harry
Re: Backward branch, warnocked.
Dan Sugalski wrote: Your code is fine. It *should* work. That it doesn't is a bug, which needs fixing. For now you're going to have to work around it. I would have swore the code was wrong. Am I being naive thinking that a call to a sub is different than what looked like a call to a label. On further investigation I had a look at operation.pod and found the following statement 67 68 To determine the life range of variables, the code gets separated into 69 pieces, called Bbasic blocks. A Bbasic block starts at a label, 70 which can get jumped to, and ends at a branch instruction. This meant my last post was severely flawed. I then decided to try the following code and it seems to work 1 .sub _main 2 goto L1 3 test: 4 $I1 = 1 5 branch L2 6 L1: 7 8 $I2 = 2 9 call test 10 L2: 11 print $I2 # prints 2 as expected 12 end 13 .end I have changed ret to branch L2 and added the L2 label. So for some reason the compiler can now see that we are in a basic block and saves the state acordingly or at least that is what appears. The pasm is as follows. 1 _main: 2 branch L1 3 test: 4 set I16, 1 5 print I16 6 branch L2 7 L1: 8 set I17, 2 9 bsr test 10 L2: 11 print I16 12 print I17 13 end Can someone clarify what on earth just happened here. Is ret not seen as a branch by IMCC so it has no idea it is in a block. I have had a look at cfg.c but it is a bit beyond me what is happening in there. Harry
Re: Messages delayed, out of order
Simon Cozens wrote: I think the mail servers for cpan.org/perl.org are having to shift rather a lot of mail at the moment, for some reason. For those that are unaware there is currently a rather serious virus in the wild at the moment and a lot of mailing lists are being afffected. I think its called the MyDoom virus or some such terribly script kiddy like name. So, if you receive an email with subject hello and a zipped attachment then delete it. As far as I am aware it only affects the smell checker of those on loonix H
Re: Problem during make test
Leopold Toetsch wrote: Harry Jackson [EMAIL PROTECTED] wrote: RHAS 2.1 dev edition Harry, do you still see these hanging parrot programs? chromatic, do you run a DeadRat (sorry) linux too? RedHat is well known to provide b0rken patches to otherwise running software. Could you try to up/down/side-grade *libpthread* (*not* glibc, at least if its separate). I am no longer using deadrat. I am now using Debian and it seems to have cured my problem ;-) Harry
Re: cvs commit: parrot/imcc imcc.l
Melvin Smith wrote: At 08:44 PM 1/9/2004 +, Harry Jackson wrote: So, are they staying, staying for now or not sure yet? I have a few hundred lines of imcc that uses macros and if they are being removed then I would rather change now and save myself some pain later. I think we are going to have an alternative to C.constant builtin to IMCC, the best suggestion seems to be C.define As far as macros, I guess we will keep them for the near future. I think its time to create a new branch for imcc development, so lets see how things work out. It may be that we can keep them in some form. One thing to consider: when we put an API on top of IMCC, macros won't translate; they are only for the text version. Thankfully this will not affect me. I am unable to find the email now but I remember someone mentioning breaking the pre-processor out of IMCC and into its own program, it was probably yourself. I have a few questions about this. What are the requirements on the pre-processor. I am pretty rusty with C and decided that I would oil my joints a little so I have been playing with a toy pre-processor (Thank god for KR). I know I should probably work with the one already there and not re-invent the wheel, I am also sure there are better ways to do it than the way I am doing it but.. ;-) This is as far as I have got and roughly how things are processed. $ preprocess filename.imc 1. Ignore comments where the *#* comes before text. If there is any text before the # I process the line as a normal statement # This line will not be processed .pcc_call blah # This line will be processed 2. Recursively process .include files ie .include /file/blah/blah goto step 1. 3. Store macro declarations in a hash table ie 146 .macro PQgetvalue(RES, tuple_num, count, data) 147 P0 = global PostgreSQL::PQgetvalue 148 I5 = .tuple_num 149 I6 = .count 150 P5 = .RES 151 invoke 152 .data = S5 153 .endm gets stored as PQgetvalue and a linked list holds each line up to the .endm. This is the area I need some clarification on. How is the current pre-processor handling arguments to the macros. Do they need to be pre-processed and if so in what ways. 4. Find macro calls by name assuming they have been found in Step 3 ie .PRINT(RES) and replace with the macro text. Using the name PRINT I access the hashtable traverse the linked list of lines printing them out as I go along. There are a few minor bugs in it which I am working on. I was just wondering what other types of things would the pre-processor need to handle. If you managed to get this far and are still interested. I have used a seriously hacked version of the dbj2 hash to store the macros. I had a look at the one in KR and thought I would have a look for a few others and this was the first one I found on google. http://www.cs.yorku.ca/~oz/hash.html Harry
Re: [PATCH] Fix imcpasm tests on Win32
Leopold Toetsch wrote: Jonathan Worthington [EMAIL PROTECTED] wrote: The attached patch fixes a problem in imcc/TestCompiler.pm which was causing all imcpasm tests to fail on Win32. Applied, as well as the icu.pl patch. [ Please provide patches relative to parrot root to simplify applying ] Do you mean we should be using: cvs -Q diff -c patchfile.txt when creating our patches rather than just diff'ing two files and then sending them with [PATCH] in the subject. Harry
Re: postgres lib
Dan Sugalski wrote: At 2:59 PM +0100 1/16/04, LF wrote: hello i noticed that harry jackson is writing a postgres interface to wrap the nci functions. i'd like him to show what he's written so far and give his comments guess i'm not the only one hoping to test it Just something to bear in mind: Please do not assume anything about this code with regards to its suitability as a driver etc. I only did it because Dan wanted something to ease the pain of using libpq via Parrot. It does this in _areas_ but has not really been tested yet, its a bit of a mess as it stands at the moment but works for selects. It is probably OK to use it to play with or learn IMCC and to see how to use the NCI interface but none of it will become production code! Some of the IMCC guru's may have some questions as to its suitability to learn anything from ;-) :) Harry, if you're OK with this, go ahead and check it in. If you don't have checkin privs, grab a perl.org account and we'll get you some. I have an account username hjackson. Where is it going to go in the tree? I will try and get it tidied up a bit and check it in, do you want insert/update to be fully working as well. For those of you thinking its a silly question ;-) trust me it's not as straight forward as you might think operation ;-). I believe you want this for a demo (your post 12/02/03 18:35 ) What sort of thing is it for? Harry
Re: Docs and releases
Paul Cochrane wrote: If there are any shy lurkers out there please speak now or forever hold your peace. I'll admit to being a shy lurker... (and have rudimentary C knowledge, but a bit low on the elbow grease atm :-/) Another one, we are getting more and more of them pop up from all over the place, so come on you lot speak up and I might compile a list of things to do if its any help. This also gives me an opportunity to mention to anyone with more time (and possibly ability) than me, that parrot is having problems on LinuxPPC. The specifics are: - parrot hangs on t/op/arithmetics when doing make test I had this exact same error. I still have no idea what caused it but thanks for confirming I am not going crazy. I tried all of the following deleted the source tree and started again nope Upgraded gcc --- nope Upgraded Perl --- nope reinstalled every perl module I could think of - nope Replaced redhat AS with Debian - yep The last item was a last resort because I had spent to much time faffing around trying to find out what caused the error at that time thinking it was local to my machine/me, obviously not. Here's some more info that may help. $ uname -a Linux 2.4.19-r6 #7 Tue Apr 22 16:54:53 EST 2003 ppc 740/750 GNU/Linux $ gcc --version 2.95.3 $ perl --version This is perl, v5.8.0 built for powerpc-linux I was on 5.6.1 when I got the arithmetic error. I hope any of this helps, and if it's possible for me to contribute, even some reasonably trivial task (something possibly like what Melvin mentioned earlier in the week re: macros) would be ok. Well it certainly made me feel better. I'm really impressed with the amount of work people are doing on parrot and related stuff. Keep up the good work! :-) I don't know where some of them get the time. Harry
Re: Shy Lurking
Robert Eaglestone wrote: Well, I may be shy, and I may lurk, but I'm willing and able to contribute. I've coded C professionally, on and off, since 1992, and I like to tinker with things, and I'm not too terrible at documentation. I think a good place to start digging in would be updating docs, though I can be turned to other directions, too. Anyone have suggestions? Rob If you want to flex some C muscle you could start by finishing this doc http://www.parrotcode.org/docs/strings.pod.html If you scroll to the bottom it has a work in progress and it will also introduce you to how parrot works with strings. I relied on it quite heavily just recently and a finished document would be very hand particularly with example of usage etc. Harry
Re: Docs and releases
Mark Solinski wrote: I'm also a shy lurker but would love to help in any way I can. I have twenty+ years experience in C/C++/OOP. Is there a reasonable place to start? Bloody hell man, what took you so long ;-). With that amount of experience, take your pick. http://www.parrotcode.org/todo Harry
Re: Parrot String Doc
Stéphane Payrard wrote: Le Tue, Jan 13, 2004 at 03:06:18PM -0600, le valeureux mongueur Robert Eaglestone a dit: OK, I'm looking at the Parrot String documentation, and I've got questions. It's not like the docs are a total mess, they just need some fleshing out. Yeah, that's it. So here I go. Here's the page I'm looking at: http://www.parrotcode.org/docs/strings.pod.html And here are my questions. Or, rather, notes which have questions in them. * OK, I'm game, is 'String' a new thing that's been added to C in the last ten years? I can't find it defined anywhere; my brain must have gone to mush. STRING, CString are different names for a Cstruct parrot_string_t. Strings are garbage collected. All garbage collected entities are accessible thru a pointer to a Cstruct pobj_t that is an union discriminated by the member Cflags. I did notice that they refer to the same struct which is something I found confusing. I noticed them being used interchangeably in places and was wondering if the we should just be using just STRING as per instructions in the documentation and change all references of String to reflect this. Harry
Re: More object stuff
Dan Sugalski wrote: At 9:05 PM +0100 1/11/04, Leopold Toetsch wrote: 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. For posgres, that's easy (which is part of the problem) -- there *is* no structure. There's a single function that takes a row/column coordinate and returns the value. If you make a query that returns, say, 7 rows with 13 columns each, you have to call this function 91 times to get all the data back... Thankyou Dan. I was about to reply honest, you put it much better than me anyway. Harry
Re: More object stuff
Dan Sugalski wrote: Well... What I'd like, I think, is something simple and straightforward. Right now we've got to fetch each column for each row one by one, which is a pain in the neck if you want to get a full row back. Having a fetchrow that returned an Array with the value for column one in the 0th slot, column 2 in the 1st slot and so on would be about 80% of the solution. I have done this part. Having a fetchrow_hash that returned a Hash where the keys are the column names and the values are the column values would be most of the rest. I read somewhere that accessing a hash was slightly slower than accessing and array which is one reason why I never used it. The other reason is that if I name the fileds in the hash then the user needs to know the names to access them or perform some magic to get them. With an array they come out in the order they are aksed for. Another reason not to use the hash method above is that you are moving column names around that will not change throughout the transaction (is this not more bulky than using arrays). Should we not return the names and types first and then subsequent rows in arrays indexed in order of retrieval. I like this method becasue thats how I have already done it ;-) just being biased. If you wanted to go the rest of the way and add an extra array version (where you get an array of rows, with each row entry being either a row array or a row hash) I think we'd be about where we'd love to be. It is entirely up to you lot. If you want it on a stamp I will see what I can come up with ;-) Harry Jackson.
Re: More object stuff
Dan Sugalski wrote: That works too. If the information's available someone'll build what they want. Whichever way you're comfortable with. (Though given my preferences, I'd add in the hash fetch version as part of the low-level interface) Roger: To clarify you want: 1. You want a hash with key value fieldnamefieldvalue done similar to 80 getnext: 81 82 .pcc_begin prototyped 83 .pcc_call fetchrow_hash 84 nextrow: 85 .result rowhash 86 .result answer 87 .pcc_end where each call to the function will return the hash containg the next rows data. Do you have any requests for anything else on, around or near this before I start. I should be able to ruffle something up pretty quickly. Harry Jackson Disclaimer: The lib is not very robust at the moment I am just trying to get an interface sorted out so I can then get on with coding behind it rather than chasing goal posts. I am really loking forward to all the error handling ;-)
Re: Docs and releases
Tim Bunce wrote: The developers _of_ parrot need to keep in mind the needs of those poised on the edge of developing _in_ parrot. I think that there are a lot of people who would help but the learning curve seems to high. I for one am finding it a pretty steep curve at the moment and am always worried about making an ass of myself when posting. I decided to hell with it, if you're ain't in you won't win. Smoothing the path for newcommers, of both types, is very important. I spent quite a bit of time fishing around the outskirts for stuff to do ie looking for some simple tasks etc and was dismayed to find none. There are no lists of things anywhere although I believe Leo compiled one which got warnocked. I know its a pain but a list of easy to complete tasks would be rather helpful for any shy lurkers with some pointers on where to start maybe not now but later. Harry Jackson If there are any shy lurkers out there please speak now or forever hold your peace.
Re: More object stuff
Jeff Clites wrote: On Jan 12, 2004, at 8:07 AM, Harry Jackson wrote: Dan Sugalski wrote: Having a fetchrow_hash that returned a Hash where the keys are the column names and the values are the column values would be most of the rest. I read somewhere that accessing a hash was slightly slower than accessing and array which is one reason why I never used it. The other reason is that if I name the fileds in the hash then the user needs to know the names to access them or perform some magic to get them. The names will be known--they are the column names (or aliases) used in the query. select * from table_name This does not tell me the names of the tables or anything about the order they are going to come out in. The nice thing about a hash (that I've found when using DBI) is that you don't have a problem if you end up inadvertently changing the order in which the columns are returned, when modifying a query. That is one advantage I never thought of and a fairly good one. Hopefully the actual strings used as the keys can be re-used. (That is, each hash can use the same string instance for a given key. I believe that Perl5 does this for hash keys.) Yes inded they can, it was a bit short sighted on my part not noticing this although the fact the exist is overhead but that is just me being pedantic ;-) I am currently working on a way to do it at the moment. Could someone tell me who exactly will be taking advantage of this library ie at what level are we pitching it at. I seriously doubt that most developers are going to even see the implimentation of this, rather its the guys coding drivers etc in which case its those guys that are going to be worried about the user interface. Or am I off the mark here. Harry
Re: Docs and releases
Robert Eaglestone wrote: Yes, I'm a shy lurker. Are there any more, don't be shy, there might be a lot of barking but no one bites at least I have not had anyone bite me _yet_. Is there anyone on the list who wants to help but does not know where to start. If you are really that shy email me off list. I can think of at least one simple task that needs doing and all it requires is some rudimentary C and a generous helping of elbow grease. Harry
Re: More object stuff
Gordon Henriksen wrote:
fetchrow_hashref is definitely a very useful, but my favorite (and also
the most efficient) DBI methodology is bind_columns. DBI maintains a
list of references corresponding to columns in the result set, and when
the result set is advanced, stores the values into the variables
referenced. e.g., Perl 5:
my $sth = $dbh-prepare(select a, b, c from tab);
$sth-execute;
$sth-bind_columns(\my($a, $b, $c));
while ($sth-fetch) {
print a: $a, b: $b, c: $c\n;
}
Equivalent to:
my $sth = $dbh-prepare(select a, b, c from tab);
$sth-execute;
$sth-bind_col(0, \my $a);
$sth-bind_col(1, \my $b);
$sth-bind_col(2, \my $c);
while ($sth-fetch) {
print a: $a, b: $b, c: $c\n;
}
So if you're going to basically go all out in emulating DBI's fetch_*
permutations, don't forget this one. :)
I am not really trying to emulate any methods at the moment it just
happens that these ways come naturally to Perl Hackers. In fact the
entire way the data comes out is open for debate and it might be a good
time to add a few nice features to it if anyone can think of any.
I doubt if any of the functionality that currently exists will be
changed but this is not up to me, all that stuff is at a much higher
layer of abstraction than where I am currently digging.
Harry Jackson
Re: Questions about abstract pmcs
Dan Sugalski wrote: Which brings up a question. What's the difference between .local and .sym? I was hoping someone would ask this. Harry
Re: More object stuff
Dan Sugalski wrote: At 4:50 PM + 1/12/04, Harry Jackson wrote: done similar to 80 getnext: 81 82 .pcc_begin prototyped 83 .pcc_call fetchrow_hash 84 nextrow: 85 .result rowhash 86 .result answer 87 .pcc_end where each call to the function will return the hash containg the next rows data. Yep, that's it. Here's the result handle, gimme a row of data as a hash. If you want to keep state such that it's a real iterator, that's fine. If you want to leave it so that the user of the library has to be explicit with which row they want, that's fine too. Ok. I have the following working after a fashion After connecting and various other contortions we get to the extraction of the data part which involves the following. 133 getnext: 134 onfield = 0 135 .pcc_begin prototyped 136 .pcc_call fetchrow_hash 137 retfetchhash: 138 .result record_hash 139 .result answer 140 .pcc_end We have returned a Hash where (key,value) = (field_name, data) The following shows roughly what I had to do to display it. I am using a global HASH called MetaData that stores various bits about the current statement being executed. 141 nextfieldhash: 142 143 FieldData = TupleData[onfield] 144 field_name = FieldData[0] 145 146 value = record_hash[field_name] 147 .PRINT(, value, #) 148 if onfield == fnum goto nextrowhash 149 inc onfield 150 branch nextfieldhash 151 nextrowhash: 152 print \n 153 ne 0, answer, getnext For the speed freaks displaying 1 rows to screen takes. This can be improved as much as my code which could be quite a bit. Rows real0m5.436s user0m1.590s sys 0m0.320s Do you have any requests for anything else on, around or near this before I start. I should be able to ruffle something up pretty quickly. Nope, can't think of anything yet. Phew. Harry Jackson
Re: More object stuff
Harry Jackson wrote: The following shows roughly what I had to do to display it. I am using a global HASH called MetaData that stores various bits about the current statement being executed. Sorry: missed a bit The MetData is where I get the TupleData Array and the associated FieldData Array from. 141 nextfieldhash: 142 143 FieldData = TupleData[onfield] 144 field_name = FieldData[0] 145 146 value = record_hash[field_name] 147 .PRINT(, value, #) 148 if onfield == fnum goto nextrowhash 149 inc onfield 150 branch nextfieldhash 151 nextrowhash: 152 print \n 153 ne 0, answer, getnext
Re: Docs and releases
Dan Sugalski wrote: At 5:01 PM + 1/12/04, Harry Jackson wrote: Tim Bunce wrote: and am always worried about making an ass of myself when posting. Dammit, and here I was trying to lead by example. It's OK! :) Smoothing the path for newcommers, of both types, is very important. I spent quite a bit of time fishing around the outskirts for stuff to do ie looking for some simple tasks etc and was dismayed to find none. There are no lists of things anywhere although I believe Leo compiled one which got warnocked. I know its a pain but a list of easy to complete tasks would be rather helpful for any shy lurkers with some pointers on where to start maybe not now but later. I try to throw out mail to the list when there's something simple that needs doing, but those haven't been gathered up into a TODO list or anything. While not a good thing, it increases their odds of making it out, at the expense of things falling off the end of the world. I have noticed a few of them and I think they should be compiled into a list. In fact, there's a job for someone if they want it. One of the shy lurkers who emailed me off list (you know who you are) suggested something similar to what the linux kernel guys have. I have no idea how successful this is: http://janitor.kernelnewbies.org/ Would people be interested in a similar thing to this. This question is really aimed at the lurkers who are willing to contribute some of their time, so speak up if you're one of them. Harry
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: 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
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 62 63 fnum = MetaData
Re: nci
I have tested the patches below now. Could someone have a look at them
and see if they can get commited especially the patch to the
call_list.txt file.
Harry
Harry Jackson wrote:
Some questions
Please note:
I have been unable to test these patches with make test due to the
problems I mentioned in an earler post. I have managed to get the
postgres lib working again and I am hoping this is the only thing I have
affected with these patches although if someone would like to apply and
try them I would appreciate it.
I am getting errors when trying to load the libpq library. I added a few
lines to the /parrot/build_tools/build_nativecall.pl script to see what
was going on when I got the core dump. I have attached a patch to add
these. There may be some problems with it. I was also thinking that it
would be handy to have the facility to print out variables in the
message, what do people think?
I noticed that there are several signatures missing from call_list.txt
so I added these as well. Patch attached. There where quite a few which
probably means I am barking up the wrong tree.
On side note: I was reading the docs on strings and noticed that we
should always be using STRING but I have noticed a few references to
String while rummaging around. From what I can gather they are one and
the same and String is redundant. Is this the case?
On another side note I noticed a reference to TWEAKS, purely by
chance. For those not in the know
From the summarizer:
TWEAKS
(Takers Wanted -- Effort And Knowledge Sought).
http://xrl.us/o2g
From what I can gather this is a list of tasks compiled by leo that
need to be carried out and help is required. I think it would be a good
idea to have a well kept todo list particularly for tasks that are
fairly easy to complete. I am sure there are people on this list like
myself who do not mind doing the smaller stuff (including documention
;-) in order to get to know the guts. Although some of the stuff leo is
asking for is not that small.
On another side note I noticed the string.pod documentations asks at the
bottom
Should the following functions be mentioned? string_append,
string_from_cstring, string_from_int, string_from_num, string_index,
string_replace, string_set, string_str_index, string_to_cstring,
string_to_int, string_to_num, string_transcode.
Yes they should, it is things like this that would be good to
put on the TWEAKS along with where or how to start[1]. The
strings doc has been one of the handiest I have found to date.
Harry (on a side note) Jackson
1. If anyone wants to take it on and is unsure where to start. Use the
folowing file.
/parrot/include/parrot/string_funcs.h
file to see what each of the functions do and try some of them and
document what you do in strings.pod and submit your results. I will
probably make some entries on it myself if no one else does.
--- build_nativecall.pl Tue Dec 30 15:54:20 2003
+++ build_nativecall.pl.new Tue Dec 30 15:53:09 2003
@@ -143,7 +143,6 @@
* Notes:
* References:
*/
-
#include parrot/parrot.h
#if defined(HAS_JIT) defined(I386) defined(threaded_NCI_is_ok)
@@ -207,8 +206,13 @@
to a function that can call it. */
void *
build_call_func(struct Parrot_Interp *interpreter, PMC *pmc_nci,
-String *signature)
+STRING *signature)
{
+
+STRING *ns;
+STRING *message;
+char *c;
+
#if defined(CAN_BUILD_CALL_FRAMES)
/* This would be a good place to put the code that builds the
frames. Undoubtedly painfully platform-dependent */
@@ -221,7 +225,20 @@
UNUSED(pmc_nci);
if (0 == string_length(signature)) return F2DPTR(pcf_v_v);
$icky_global_bit
-PANIC(Unknown signature type);
+
+
+/*
+ These three lines have been added to aid debugging. I want to be able to
+ see which signature has an unknown type. I am sure someone can come up
+ with a neater way to do this.
+ */
+ns = string_make(interpreter, is an unknown signature type, 30, NULL, 0, NULL);
+message = string_concat(interpreter, signature, ns, 0);
+
+// I think there may be memory issues with this but if we get to here we are
+// aborting.
+c = string_to_cstring(interpreter, message);
+PANIC(c);
return NULL;
#endif
}
--- call_list.txt Tue Dec 30 15:54:20 2003
+++ call_list.txt.new Tue Dec 30 15:53:34 2003
@@ -181,6 +181,18 @@
# Oddball ones for postgres
p ptiLTLLi
+p t
+p ttt
+c p
+t p
+v pp
+t tl4
+t t4
+p pt
+p pi33ipi
+t pii
+p pi
+i pitl
# The following are used by library/pcre.imc
p tiB3P
Re: nci
Harry Jackson wrote: I have tested the patches below now. Could someone have a look at them and see if they can get commited especially the patch to the call_list.txt file. # New in libpq.so.3.1 t pt p ptit33i i ptit33i i ptiit33i c pi I have jsut added the above signatures to my call_list due to an upgrade to postgres and was wondering what plans are there for managing the call_list. If every time there is a minor update to a lib and several new signatures get added this file is going to get quite large. I am sure someone has already thought of this and I have just missed the thread. Harry
Some imc questions
I am trying to create an array of global functions from the postgres library mainly to ease passing parameters amongst other things. I have snipped some repetitive code out. I am sure that there are a few errors in the way I am using imc so any corrections or pointers would be much appreciated, I am quite new to it. I have been using the docs to try and pick this up and I am having a hard time... imcc.faq version December 2001 hint hint. 1 .pcc_sub _MAIN prototyped 2 .param pmc argv 3 .include /home/parrot/parrot/library/postgres.pasm 4 .include /home/parrot/lib/postgreslib.imc 5 .include /home/parrot/lib/Commandlib.imc 6 7 8 9 dbstring = host=lhost dbname=Forum user=user password=password 10 11 print Entering Connect\n 12 .pcc_begin prototyped 13 .arg Command 14 .arg dbstring 15 .pcc_call connect 16 retconnect: 17 .result CONN 18 .result int_answer 19 .result message 20 .pcc_end 21 .PRINT(Connection Message = , message, \n) 22 .PRINT(Connection state = , int_answer, \n) 23 eq -1, int_answer, fail 24 eq 1, int_answer, go 25 fail: 26 .PRINT(\n, message, \n) 27 end 28 go: 29 30 query = select * from parrot 31 print Entering Send Query \n 32 .pcc_begin prototyped 33 .arg Command 34 .arg CONN 35 .arg query 36 .pcc_call pqsendquery 37 ret: 38 .result message 39 .pcc_end postgreslib.imc contains sub definitions as follows 47 .sym Sub pqsendquery 48 newsub pqsendquery, .Sub, _pqsendquery 49 .local pmc PQSENDQUERY 50 PQSENDQUERY = global PostgreSQL::PQsendQuery 51 52 53 54 .sym Sub PQconnectStart 55 newsub PQconnectStart, .Sub, p_PQconnectStart_t 56 .local pmc PQCONNECTSTART 57 58 PQCONNECTSTART = global PostgreSQL::PQconnectStart 59 60 61 .sym Sub PQconnectPoll 62 newsub PQconnectPoll, .Sub, i_PQconnectPoll_p 63 .local pmc PQCONNECTPOLL 64 65 PQCONNECTPOLL = global PostgreSQL::PQconnectPoll 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 5 Command[1] = PQCONNECTPOLL 6 Command[18] = PQSTATUS 7 Command[31] = PQSENDQUERY 8 9 #Command[2] = PQCONNECTDB 10 #Command[3] = PQSETDBLOGIN 11 #Command[4] = PQFINISH 12 #Command[5] = PQCONNDEFAULTS 13 #Command[6] = PQCONNINFOFREE 14 #Command[7] = PQRESETSTART 15 #Command[8] = PQRESETPOLL 16 #Command[9] = PQRESET 17 #Command[10] = PQREQUESTCANCEL The first function call to connect works and the array Command gets passed into the funtion as follows. You will notice below that to get it to work I had to take a local copy of the passed in array or it got clobbered??? 241 .pcc_sub _connect prototyped 242 .param PerlArray Command 243 .param PerlString s 244 .local PerlString message 245 message = new PerlString 246 247 .local PerlArray C 248 C = new PerlArray 249 C = Command 250 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 Various magic things happen in this function and we get a connection to postgres and pass the CONN back out. When I call the next funtion on line 32 above the call works but the Array has not been passed correctly. You can see in the following function that I am taking a local copy again. 192 .pcc_sub _pqsendquery prototyped 193 .param PerlArray Command 194 .param pmc CONN 195 .param PerlString query 196 .local PerlArray C 197 C = new PerlArray 198 C = Command 199 .local int answer 200 .local PerlString message 201 .PRINT(Sending query now\n, query, \n\n) 202 P0 = C[31] 203 P5 = CONN 204 S5 = query 205 invoke 206 answer = I5 207 eq 0, answer, error 208 eq 1, answer, good 209 error: 210 .PQerrorMessage(CONN, message) 211 branch finish 212 good: 213 message = Successful\n 214 finish: 215 .pcc_begin_return 216 .return message 217.pcc_end_return 218 end 219 .end Running this fails with the followng error. set_string_native() not implemented in class 'PerlArray' which suggests that I am trying to set an Array to a string which is obviously wrong. I am pretty sure that I am butchering imc syntax throughout this but it has got me a bit stumped.
Re: cvs commit: parrot/imcc imcc.l
Melvin Smith wrote: But, if you want macros to stay, let them stay. So, are they staying, staying for now or not sure yet? I have a few hundred lines of imcc that uses macros and if they are being removed then I would rather change now and save myself some pain later. H
Re: Configure.pl Error
Harry Jackson wrote:
I am now trying to get Parrot running on debian and have noticed the
following error while running perl Configure.pl
Determining some sizes...Linker failed (see test.ldo) at
lib/Parrot/Configure/Step.pm line 233
Parrot::Configure::Step::cc_build() called at
config/auto/sizes.pl line 39
Configure::Step::runstep('undef') called at
lib/Parrot/Configure/RunSteps.pm line 68
Parrot::Configure::RunSteps::runsteps('Parrot::Configure::RunSteps','jitcapable',0,'debugging',1)
called at Configure.pl line 94
This is a very minimal system at the moment so I might not have
everything installed. I am hoping that someone may have seen his before.
For anyone that ever encounters this problem in the future delete the
source tree and check out the source again. It worked for me.
H
Configure.pl Error
I am now trying to get Parrot running on debian and have noticed the
following error while running perl Configure.pl
Determining some sizes...Linker failed (see test.ldo) at
lib/Parrot/Configure/Step.pm line 233
Parrot::Configure::Step::cc_build() called at
config/auto/sizes.pl line 39
Configure::Step::runstep('undef') called at
lib/Parrot/Configure/RunSteps.pm line 68
Parrot::Configure::RunSteps::runsteps('Parrot::Configure::RunSteps','jitcapable',0,'debugging',1)
called at Configure.pl line 94
This is a very minimal system at the moment so I might not have
everything installed. I am hoping that someone may have seen his before.
Harry
Re: This week's summary
The Perl 6 Summarizer wrote: Problems with make test Harry Jackson couldn't get his build of parrot to finish running make test. After a certain amount of thrashing about by the team, Dan narrowed it down to issues with the mutant '2.96' version of GCC that some versions of Red Hat used for a while. This is currently the list's best guess as to the root of the problem, but it's not absolutely certain. If it does turn out to be the compiler, the config suite will have to be rejigged to detect and warn. I got fed up beating around the bush so I took some drastic action. I installed apt-get for redhat and did a massive upgrade and that sorted out the parrot problems but introduced several others that I wont go into (not parrot related). Now knowing I have not got dodgy hardware I decided to bite the bullet and install Debain, I have been missing apt-get for some time now. I now have debain running and am just about to test parrot and try and get postgres and a few other things back to normal. Don't use IMCC macros Bernhard Schmalhofer found what looked like a bug in IMCC's macro support. This prompted Melvin Smith to expedite the removal of IMCC macro support as threatened some weeks ago. However, it turned out that that wasn't actually the seat of the bug. But if you like IMCC macros now is the time to make a *very* good case to Melvin, I doubt you'll convince him though; macros belong in a preprocessor. http://tinyurl.com/3e3cg I was unaware of this. I must have missed a thread somewhere. I have been using macros quite a bit in the postgres lib but I am pretty sure if my parrot will start to squak properly I can do without them, if it dosn't I'll ring its neck. I was using macros for all the global function calls. I originally tried to get them all into an array/hash but was having some fun doing this (I am pretty sure this is nothing to do with imcc, rather my dodgy parrot ;-) The Piemark is ready Dan forwarded the announcement that the Pie-thon Parrot Benchmark (which I've unilaterally decided to call the Piemark) code is ready. Let's make sure it's Guido not Dan who gets Pie eyed in Portland this year. I really need to read more of the archives to find out what the crack is here. 1 Dan will win his bet with Guido, and that the Python.Net people will be so embarrassed by the piemark that they won't publish numbers. I am not 100% sure what this involves yet but its a bet and in a manner of speaking I'm gunning for the parrot. Harry
Re: Thread Question and Suggestion -- Matt
Matt Fowles wrote: I understand if this suggestion is dismissed for violating the rules, but I would like an answer to the question simply because I do not know the answer. The most admiral reason for asking a question and I doubt it will be dismissed. H
Re: Problem during make test
Dan Sugalski wrote: Let us know either way -- if upgrading gcc works then we're going to have to figure out how RH/GCC2.96 is breaking things so we can make it not happen. :( I have now upgraded gcc to 3.3.2 and I am getting the same error. We are still freezing during test. I have also noticed something that might be my crap imc or related to the problem Can someone tell me if there is an error in the code below. When I run it repeatedly from the command line it sometimes freezes ie it prints the contents of the array and then just stops and I need to do a CTRL-C to get back to the command line. .pcc_sub _MAIN prototyped .param pmc argv .local PerlArray a a = new PerlArray .local PerlString s s = new PerlString a = 10 a[0] = Zero a[1] = One a[2] = Two a[3] = Three a[4] = Four a[5] = Five a[6] = Six a[7] = Seven a[8] = Eight s = a[2] print \n print s print \n end .end I have also tried the above code using the set syntax and I get the same problem. Are there any recommended examples of IMC in the source tree and which docs are the most recent. I have noticed that there are a lot of different ways of doing things (typical perl). I am trying to pick it up from the FAQ, some examples and the docs but its an uphill struggle. For instance I have noticed that set a[0], one or a[0] = one appear to do the same thing. I cannot confirm that they do due to the bug above. I have got to the point where I am trying to put rows from Postgres into arrays and this is slowing me down a bit. Harry
Re: Problem during make test
Leopold Toetsch wrote: Harry Jackson [EMAIL PROTECTED] wrote: Can someone tell me if there is an error in the code below. The code is fine. it repeatedly from the command line it sometimes freezes ie it prints the contents of the array and then just stops and I need to do a CTRL-C to get back to the command line. Your are sure that there is no hardware problem? Run memcheck for a couple of hours for example. I managed to compile gcc which is a fairly good indication that my hardware is ok but you never know. I will try memtest86 and see how it goes. They are the same. The first one is PASM syntax, the second is PIR syntax. E.g. running your imc trouble code $ parrot -o- hj.imc _MAIN: new P16, 31 # .PerlArray new P17, 36 # .PerlString set P16, 10 set P16[0], Zero ... yields the generated PASM code (with variables names allocated to Parrot registers). I tried that as well, it spits out identical PASM each time but on the odd occasion I need to use CTRL-C to get back to the shell. H
Re: Problem during make test
Dan Sugalski wrote: [EMAIL PROTECTED] pbin]$ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 2731 (Red Hat Linux 7.2 2.96-108.1) Yeah, that was the one, unfortunately. Try disabling the JIT during configuration and seeing if that takes care of the problem. If so, we'll need to update configure to do that automatically, since I think we're going to end up running into this for years. :( No Joy. I will upgrade gcc and see what happens. Harry Jackson
Re: Problem during make test
Leopold Toetsch wrote: Do you have a SMP machine with SMP enabled in your OS? The unpredictable behavior of your freezes makes me think, that it could be related to multi-threading. OTOH arithmetic tests or such don't utilize threads and no events are being generated. I am running a Cray X1 ( I wish ). I am on a redhat box on a bog standard single Athlon XP1700. I am stumped. Harry
Re: Problem during make test
Dan Sugalski wrote: Just out of curiosity... what version of gcc are you running? We were having no end of problems with the JIT and one of the mutant versions of 2.95 that redhat was packaging up at one point. [EMAIL PROTECTED] pbin]$ gcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 2731 (Red Hat Linux 7.2 2.96-108.1) RHAS 2.1 dev edition Harry Jackson
nci
Some questions
Please note:
I have been unable to test these patches with make test due to the
problems I mentioned in an earler post. I have managed to get the
postgres lib working again and I am hoping this is the only thing I have
affected with these patches although if someone would like to apply and
try them I would appreciate it.
I am getting errors when trying to load the libpq library. I added a few
lines to the /parrot/build_tools/build_nativecall.pl script to see what
was going on when I got the core dump. I have attached a patch to add
these. There may be some problems with it. I was also thinking that it
would be handy to have the facility to print out variables in the
message, what do people think?
I noticed that there are several signatures missing from call_list.txt
so I added these as well. Patch attached. There where quite a few which
probably means I am barking up the wrong tree.
On side note: I was reading the docs on strings and noticed that we
should always be using STRING but I have noticed a few references to
String while rummaging around. From what I can gather they are one and
the same and String is redundant. Is this the case?
On another side note I noticed a reference to TWEAKS, purely by
chance. For those not in the know
From the summarizer:
TWEAKS
(Takers Wanted -- Effort And Knowledge Sought).
http://xrl.us/o2g
From what I can gather this is a list of tasks compiled by leo that
need to be carried out and help is required. I think it would be a good
idea to have a well kept todo list particularly for tasks that are
fairly easy to complete. I am sure there are people on this list like
myself who do not mind doing the smaller stuff (including documention
;-) in order to get to know the guts. Although some of the stuff leo is
asking for is not that small.
On another side note I noticed the string.pod documentations asks at the
bottom
Should the following functions be mentioned? string_append,
string_from_cstring, string_from_int, string_from_num, string_index,
string_replace, string_set, string_str_index, string_to_cstring,
string_to_int, string_to_num, string_transcode.
Yes they should, it is things like this that would be good to
put on the TWEAKS along with where or how to start[1]. The
strings doc has been one of the handiest I have found to date.
Harry (on a side note) Jackson
1. If anyone wants to take it on and is unsure where to start. Use the
folowing file.
/parrot/include/parrot/string_funcs.h
file to see what each of the functions do and try some of them and
document what you do in strings.pod and submit your results. I will
probably make some entries on it myself if no one else does.
--- build_nativecall.pl Tue Dec 30 15:54:20 2003
+++ build_nativecall.pl.new Tue Dec 30 15:53:09 2003
@@ -143,7 +143,6 @@
* Notes:
* References:
*/
-
#include parrot/parrot.h
#if defined(HAS_JIT) defined(I386) defined(threaded_NCI_is_ok)
@@ -207,8 +206,13 @@
to a function that can call it. */
void *
build_call_func(struct Parrot_Interp *interpreter, PMC *pmc_nci,
-String *signature)
+STRING *signature)
{
+
+STRING *ns;
+STRING *message;
+char *c;
+
#if defined(CAN_BUILD_CALL_FRAMES)
/* This would be a good place to put the code that builds the
frames. Undoubtedly painfully platform-dependent */
@@ -221,7 +225,20 @@
UNUSED(pmc_nci);
if (0 == string_length(signature)) return F2DPTR(pcf_v_v);
$icky_global_bit
-PANIC(Unknown signature type);
+
+
+/*
+ These three lines have been added to aid debugging. I want to be able to
+ see which signature has an unknown type. I am sure someone can come up
+ with a neater way to do this.
+ */
+ns = string_make(interpreter, is an unknown signature type, 30, NULL, 0, NULL);
+message = string_concat(interpreter, signature, ns, 0);
+
+// I think there may be memory issues with this but if we get to here we are
+// aborting.
+c = string_to_cstring(interpreter, message);
+PANIC(c);
return NULL;
#endif
}
--- call_list.txt Tue Dec 30 15:54:20 2003
+++ call_list.txt.new Tue Dec 30 15:53:34 2003
@@ -181,6 +181,18 @@
# Oddball ones for postgres
p ptiLTLLi
+p t
+p ttt
+c p
+t p
+v pp
+t tl4
+t t4
+p pt
+p pi33ipi
+t pii
+p pi
+i pitl
# The following are used by library/pcre.imc
p tiB3P
Re: Strangeness with '.sub' in macros
Bernhard Schmalhofer wrote:
Hi,
Could sombody test the attached script on another machine?
I'm working here on a Linux laptop:
I am geting a seg fault. Its fine when the second call is commented out.
I am not sure if any of the following is any use to you.
The follwoing PASM was part generated from your IMC, I added the bits
between ###. This calls the sub twice I am not sure if it is any use
to you. Please see some output from GDB at the end.
_main:
set P16, P1
newsub P16, 45, _dummy
@pcc_sub_call_2:
set I5, 1
set P0, P16
set I0, 1
set I1, 0
set I2, 0
set I3, 0
savetop
invokecc
restoretop
###
set I5, 2
set I0, 1
set I1, 0
set I2, 0
set I3, 0
savetop
invokecc
restoretop
###
end
_dummy:
print dummy was called with:
print I5
print \n
@pcc_sub_ret_25:
set I0, 1
set I1, 0
set I2, 0
set I3, 0
set I4, 0
invoke P1
[EMAIL PROTECTED] pbin]$ gdb parrot
GNU gdb Red Hat Linux (5.1-1)
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-redhat-linux...
(gdb) b runops_jit
Breakpoint 1 at 0x8075236: file src/interpreter.c, line 422.
(gdb) run -j -d test.pbc
Starting program: /home/parrot/bin/parrot -j -d test.pbc
[New Thread 1024 (LWP 17090)]
[New Thread 2049 (LWP 17091)]
[New Thread 1026 (LWP 17092)]
Address of base segment is (nil)
Address of base segment is (nil)
*** Parrot VM: JIT core ***
*** Parrot VM: Setting up ARGV array in P5. Current argc: 1 ***
0: test.pbc
[Switching to Thread 1024 (LWP 17090)]
Breakpoint 1, runops_jit (interpreter=0x8214a08, pc=0x400180d0) at
src/interpreter.c:422
422 jit_f jit_code = (jit_f) D2FPTR(init_jit(interpreter, pc));
(gdb) n
423 (jit_code) (interpreter, pc);
(gdb) n
Address of base segment is 0x400180d0
dummy was called with: 1
425 return NULL;
(gdb) n
426 }
(gdb) n
runops_int (interpreter=0x8214a08, offset=0) at src/interpreter.c:633
633 interpreter-lo_var_ptr = old_lo_var_ptr;
(gdb) n
634 if ((interpreter-resume_flag RESUME_RESTART)
(gdb) n
553 while (interpreter-resume_flag RESUME_RESTART) {
(gdb) n
638 }
(gdb) n
runops_ex (interpreter=0x8214a08, offset=0) at src/interpreter.c:652
652 if (interpreter-resume_flag RESUME_ISJ) {
(gdb) n
679 }
(gdb) n
runops (interpreter=0x8214a08, offset=0) at src/interpreter.c:709
709 }
(gdb) n
Parrot_runcode (interpreter=0x8214a08, argc=1, argv=0xb980) at
src/embed.c:514
514 }
(gdb) n
main (argc=1, argv=0xb980) at imcc/main.c:551
551 Parrot_destroy(interpreter);
(gdb) n
552 if (output)
(gdb) n
554 mem_sys_free(interpreter-imc_info);
(gdb) n
555 Parrot_exit(0);
(gdb) n
*** Parrot VM: Dumping GC info ***
Total memory allocated = 139264
DOD runs = 0
Collect runs = 0
Collect memory = 0
Active PMCs = 1024
Active buffers = 6144
Total PMCs = 1024
Total buffers = 6144
Header allocations since last collect = 7
Memory allocations since last collect = 1
Program exited normally.
(gdb)
Harry Jackson
Re: Problem during make test
Jeff Clites wrote:
Here are 3 things to try:
1) When it hangs there, check with 'top' to see if it is using CPU (ie,
is it blocking, or in an infinite loop).
Already done that and it is eating no cycles.
2) Try running one of the tests which blocks, individually. If you can
get it to happen this way, then run it in gdb and see what it's doing.
(Or, attach to an already blocked one from 'make test'--this is assuming
it's parrot that's actually blocking, and not t/harness.)
When run individually I get the same error. Complete freeze at what
appears to be an arbitrary point.
Running gdb
0x080a7625 in Perl_sv_gets ()
(gdb) n
Single stepping until exit from function Perl_sv_gets,
which has no line number information.
0x0809d254 in Perl_do_readline ()
(gdb) n
Single stepping until exit from function Perl_do_readline,
which has no line number information.
0x08099fd8 in Perl_runops_standard ()
(gdb) n
Single stepping until exit from function Perl_runops_standard,
which has no line number information.
t/op/arithmeticsok 13/18
This is where gdb freezes execution. CTL-C then frees it up to continue
until the next one freezes.
3) Try building from a clean checkout, and see if that shows the
problem. If not, it's probably something you've changed and don't realize.
I have tried something a bit more drastic. Deleted the entire tree and
downloaded it again (sorry about the bandwidth).
I have also tried strace and got the following.
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x401fe000
read(3, #! perl -w\n\nuse Parrot::Test tes..., 4096) = 4096
brk(0x81e2000) = 0x81e2000
close(3)= 0
munmap(0x401fe000, 4096)= 0
pipe([3, 4])= 0
pipe([5, 6])= 0
fork() = 19676
close(4)= 0
close(6)= 0
read(5, , 4) = 0
close(5)= 0
fcntl64(0x3, 0x3, 0xb5c4, 0)= 0
fstat64(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x401fe000
_llseek(3, 0, 0xb410, SEEK_CUR) = -1 ESPIPE (Illegal seek)
fcntl64(0x3, 0x2, 0x1, 0x1d)= 0
read(3, 1..18\n, 4096)= 6
read(3,
Doing a ps ax reveals the following (ignore the test number it keeps
changing)
20802 pts/11 S 0:00 make test
21598 pts/11 S 0:00 perl t/harness --gc-debug --running-make-test
-b t/op/00ff-dos.t t/op/00ff-unix.t t/op/arithmetics.t t/op/basic.t
21610 pts/11 S 0:00 perl -w t/op/arithmetics.t
21620 pts/11 S 0:00 ./parrot --gc-debug -b t/op/arithmetics_4.pasm
21621 pts/11 S 0:00 ./parrot --gc-debug -b t/op/arithmetics_4.pasm
21622 pts/11 S 0:00 ./parrot --gc-debug -b t/op/arithmetics_4.pasm
From all of this I am guessing that something has corrupted a module in
Perl at least that is all I can think of.
Harry Jackson
Re: Problem during make test
Jeff Clites wrote:
On Dec 30, 2003, at 3:11 PM, Harry Jackson wrote:
2) Try running one of the tests which blocks, individually. If you
can get it to happen this way, then run it in gdb and see what it's
doing. (Or, attach to an already blocked one from 'make test'--this
is assuming it's parrot that's actually blocking, and not t/harness.)
When run individually I get the same error. Complete freeze at what
appears to be an arbitrary point.
Running gdb
0x080a7625 in Perl_sv_gets ()
I meant try running parrot in the debugger--Perl is probably hanging b/c
it's waiting for parrot to exit. For instance, see if the following
hangs, and if so run it in gdb:
../parrot --gc-debug -b t/op/arithmetics_4.pasm
[parrot]$ ./parrot --gc-debug -b t/op/arithmetics_4.pasm
4123
4123
[parrot]$ ./parrot --gc-debug -b t/op/arithmetics_3.pasm
3877
3877
[parrot]$ ./parrot --gc-debug -b t/op/arithmetics_2.pasm
0
1234567890
1234567890
0
1234567890
1234567890
[parrot]$ ./parrot --gc-debug -b t/op/arithmetics_1.pasm
0
-1234567890
1234567890
0
-1234567890
1234567890
Looks good to me. I have taken the drastic measure of upgrading to 5.8.2
and... no change. I am still locking up during tests, or should I
say, parrot is still locking up during tests, I seem to be continuing
along fine which is why I am still complaining ;-)
I have also tried strace and got the following.
Try this on parrot rather than Perl.
strace on parrot gets to
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
wait4(-1, [WIFEXITED(s) WEXITSTATUS(s) == 0], 0, NULL) = 8423
--- SIGCHLD (Child exited) ---
sigreturn() = ? (mask now [])
write(1, : blib/lib/libparrot.a\n, 23: blib/lib/libparrot.a
) = 23
rt_sigprocmask(SIG_BLOCK, [HUP INT QUIT TERM XCPU XFSZ], NULL, 8) = 0
vfork() = 8424
--- SIGCHLD (Child exited) ---
sigreturn() = ? (mask now [HUP INT QUIT TERM
XCPU XFSZ])
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
wait4(-1, [WIFEXITED(s) WEXITSTATUS(s) == 0], 0, NULL) = 8424
rt_sigprocmask(SIG_BLOCK, [HUP INT QUIT TERM XCPU XFSZ], NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
stat64(blib/lib/libparrot.a, {st_mode=S_IFREG|0664, st_size=18102092,
...}) = 0
write(1, cc -o parrot -Wl,-E -g imcc/ma..., 98cc -o parrot -Wl,-E
-g imcc/main.o blib/lib/libparrot.a -lnsl -ldl -lm -lcrypt -lutil -lpthread
) = 98
rt_sigprocmask(SIG_BLOCK, [HUP INT QUIT TERM XCPU XFSZ], NULL, 8) = 0
vfork() = 8425
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
wait4(-1, [WIFEXITED(s) WEXITSTATUS(s) == 0], 0, NULL) = 8425
--- SIGCHLD (Child exited) ---
sigreturn() = ? (mask now [])
rt_sigprocmask(SIG_BLOCK, [HUP INT QUIT TERM XCPU XFSZ], NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
stat64(parrot, {st_mode=S_IFREG|0775, st_size=4133629, ...}) = 0
stat64(test_prep, 0xbfffddf0) = -1 ENOENT (No such file or
directory)
stat64(testb, 0xbfffddf0) = -1 ENOENT (No such file or
directory)
write(1, /usr/local/bin/perl5.8.2 t/harne...,
106/usr/local/bin/perl5.8.2 t/harness --gc-debug --running-make-test -b
t/op/*.t t/pmc/*.t t/native_pbc/*.t
) = 106
rt_sigprocmask(SIG_BLOCK, [HUP INT QUIT TERM XCPU XFSZ], NULL, 8) = 0
vfork() = 8428
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
t/op/00ff-dos...ok
t/op/00ff-unix..ok
t/op/arithmeticsok 15/18
freeze punk it's the police.
I am now convinced that due to the baffling nature of the problem that
it will be something stupid.
Harry Jackson
pdd16
I might be going mad here and maybe I have been up too long but, does: http://dev.x.perl.org/perl6/pdd/pdd16_native_call.html have two identical Parrot_callback_C and Parrot_callback_D function signatures. Harry Jackson
I could not resist
I was searching on google for core.html parrot and the first link took me to http://www.gurney.co.uk/parrots/dandan.html Do we have a facilty for number 5. H
Problem during make test
During
[EMAIL PROTECTED] parrot]$ make test
echo imcc/imcc.y -d -o imcc/imcparser.c
imcc/imcc.y -d -o imcc/imcparser.c
perl -e 'open(A,qq{$_}) or die foreach @ARGV' imcc/imcc.y.flag
imcc/imcparser.c imcc/imcparser.h
perl t/harness --gc-debug --running-make-test -b t/op/*.t t/pmc/*.t
t/native_pbc/*.t
t/op/00ff-dos...
This is as far as it gets. I am assuming since no one else has noticed
this that it is a problem with my set up but I am at a bit of a loss as
to what has happened to cause it.
It gets even stranger. If I do a make clean and make test again it does
not necessarily stop in the same place each time ie.
perl t/harness --gc-debug --running-make-test -b t/op/*.t t/pmc/*.t
t/native_pbc/*.t
t/op/00ff-dos...ok
t/op/00ff-unix..
sometime it gets as far as the aritmetic tests. Has anyone seen this
before. My myconfig is at the bottom of the page.
On a side note I noticed some warnings about a predeclared variable in
/parrot/ops/core.ops line 1059. Patch attached.
Summary of my parrot 0.0.13 configuration:
configdate='Mon Dec 29 21:21:06 2003'
Platform:
osname=linux, archname=i386-linux
jitcapable=1, jitarchname=i386-linux,
jitosname=LINUX, jitcpuarch=i386
execcapable=1
perl=perl
Compiler:
cc='gcc', ccflags=' -I/usr/local/include',
Linker and Libraries:
ld='gcc', ldflags=' -L/usr/local/lib',
cc_ldflags='',
libs='-lnsl -ldl -lm -lcrypt -lutil -lpthread'
Dynamic Linking:
so='.so', ld_shared='-shared -L/usr/local/lib',
ld_shared_flags=''
Types:
iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4,
ptrsize=4, ptr_alignment=4 byteorder=1234,
nv=double, numvalsize=8, doublesize=8
--- core.opsMon Dec 29 22:06:55 2003
+++ core.ops.newMon Dec 29 22:07:59 2003
@@ -1056,7 +1056,7 @@
VTABLE_type(interpreter, overflow) != enum_class_Null
((elems_in_array = VTABLE_get_integer(interpreter, overflow)) != 0)) {
INTVAL cur_elem;
- INTVAL start = 0;
+ start = 0;
if ($2 11) {
start = $2 - 11;
}
Re: More object stuff
Dan Sugalski wrote: At 1:02 PM + 12/27/03, Harry Jackson wrote: Being fairly new to parrot and probably naive I can see a few different ways of doing this. A C wrapper ie: parrot/classes/parrotdbi.pmc etc A C wrapper ie: parrot/dynclasses/parrotdbi.pmc etc A loadable pasm function library that uses the current libpq/(other libs) and available available ops. I'd go with option 3, the loadable pasm library that uses the current libpq. I think that, right now, there's no need for anything else. That may turn out to be incorrect, but if so we can try Plan B. (Which involves either extending Parrot or getting the C extension stuff working) OK. I will start on it now. I will probably have lots of questions while doing this. Tim's right -- dodge the DBD/DBI names for right now. We're going to have enough of a headache with those later, what with there being both Ruby and Perl versions that use it. (Possibly Python too, I'm not sure) I was only using them as examples. I will leave them pretty generic ie for the time being. 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. This'll probably be the basis for the DB driver interface for Parrot's DBI library, so this is your chance to make a mark. :) Cheers for the opportunity. Always happy to pass on work to other people. :) As soon as I have a something of worth I will post the details. H
Re: More object stuff
Dan Sugalski wrote: Dunno if I replied, but... Next step is a higher level wrapper, if you're up for fiddling with Postgres itself. Stuff like a single call to connect (right now you have to make the connect call and poll over and over again), I did some benchmarks using your original library a few weeks ago and I did find the polling business a bit odd. I replied a while back asking asking if anyone had any pointers or examples on where to start this no matter how simple but I think Warnock's Dilema #2 may have kicked in. Being fairly new to parrot and probably naive I can see a few different ways of doing this. A C wrapper ie: parrot/classes/parrotdbi.pmc etc A C wrapper ie: parrot/dynclasses/parrotdbi.pmc etc A loadable pasm function library that uses the current libpq/(other libs) and available available ops. 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. This'll probably be the basis for the DB driver interface for Parrot's DBI library, so this is your chance to make a mark. :) Cheers for the opportunity. Harry
Re: Licenses and library code
Dan Sugalski wrote: We're starting to check in library code, which brings up the annoying issue of licensing. Since we haven't been able to go the easy (i.e. all public domain) route for parrot we need to deal with this. The license on Parrot itself is straightforward enough, albeit a bit odd what with ICU being included with a different license. (And I do need to clarify what Parrot does and doesn't lay claim to) For the library, though... snip I recommend putting the above post or something similar into a README in the library directory. H
Re: More object stuff
Dan Sugalski wrote: It's util/ncidef2pasm.pl, actually. build_nativecall builds the stub routines for the interpreter if a JIT isn't available. The definitions of the characters are the same, but ncidef2pasm's a bit better documented. (There's embedded POD) Invocation is: perl util/ncidef2pasm.pl definition_file output.pasm I have done postgres.declarations, please see below. Woo! And, might I add, hoo! :) Thanks. Do you want me to do anything else with it. The script above works fine on the file. h
Re: More object stuff
Dan Sugalski wrote: Yep, though that's a big part of it. postgres.pasm is generated from postgres.declarations, FWIW--there's a script in the library somewhere. Is /parrot/build_tools/build_nativecall.pl the script in question and if so whats its usage. I have done postgres.declarations, please see below. I have made guesses based on /parrot/build_tools/build_nativecall.pl where I was unsure as to the type to be used. Where I was not sure of the type I have included the declaration from libpq-fe.h as a comment just above the entry in the new postgres.declarations. All new entries from the 7.4 file have been included in the file as follows New In 7.4 New function The entries appear in the order they where encountered in libpq-fe.h which differs considerably from the 7.3 version. If anyone is interested the following URL will take you to the Postgres web interface for libpq-fe.h. http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/interfaces/libpq/libpq-fe.h Revision 1.100 As for the OO wrapper. Are you after a pasm library that takes advantage of objects and hides the details of libpq-fe.h? I think I could start something if no one else has already started anything. Yep, that's what I was thinking of. If you take a look, there are parts of the interface that are somewhat awkward to use from a higher level -- the record fetching code is definitely skewed down to the bottom end of things. Certainly fine enough, but it'd be nice to be able to get back an array or hash for a record rather than having to query individual fields. :) I will probably need a bit of help with this. To coin a phrase I am still very much slipping on the parrot guts. You guys seem to be producing material at a fair pace :-) If there is already any material, docs, examples or a wrapper already written for another library please point me at it. Harry [package] PostgreSQL [lib] libpq [defs] # From libpq-fe.h Revision 1.100 p PQconnectStart t i PQconnectPoll p p PQconnectdb t p PQsetdbLogin t t t t t t t v PQfinish p p PQconndefaults v PQconninfoFree p i PQresetStart p i PQresetPoll p #extern void PQreset(PGconn *conn); # This was set to c PQreset p was this correct. v PQreset p i PQrequestCancel p t PQdb p t PQuser p t PQpass p t PQhost p t PQport p t PQtty p t PQoptions p i PQstatus p # New In 7.4 i PQtransactionStatus p t PQparameterStatus p t i PQprotocolVersion p # t PQerrorMessage p i PQsocket p i PQbackendPID p i PQclientEncoding p i PQsetClientEncoding p t # New In 7.4 i PQsetErrorVerbosity p i # v PQtrace p p v PQuntrace p # Need function pointers. Can't do that yet # New IN 7.4 #i PQsetNoticeReceiver p p # # i PQsetNoticeProcessor p p p PQexec p t # New In 7.4 #extern PGresult *PQexecParams(PGconn *conn, # const char *command, # int nParams, # const Oid *paramTypes, # const char *const * paramValues, # const int *paramLengths, # const int *paramFormats, # int resultFormat); p PQexecParams p t i i 3 3 i #extern PGresult *PQexecPrepared(PGconn *conn, # const char *stmtName, # int nParams, # const char *const * paramValues, # const int *paramLengths, # const int *paramFormats, # int resultFormat); p PQexecPrepared p t i t 3 3 i # i PQsendQuery p t # New In 7.4 #extern int PQsendQueryParams(PGconn *conn, # const char *command, # int nParams, # const Oid *paramTypes, # const char *const * paramValues, # const int *paramLengths, # const int *paramFormats, # int resultFormat); i PQsendQueryParams p t i i t 3 3 i #extern int PQsendQueryPrepared(PGconn *conn, # const char *stmtName, # int nParams, # const char *const * paramValues, # const int *paramLengths, # const int *paramFormats, # int resultFormat); i PQsendQueryPrepared p t i t 3 3 i # p PQgetResult p i PQisBusy p i PQconsumeInput p p PQnotifies p # New In 7.4 #extern int PQputCopyData(PGconn *conn, const char *buffer, int nbytes); i PQputCopyData p t i #extern int PQputCopyEnd(PGconn *conn, const char *errormsg); i PQputCopyEnd p t #extern int PQgetCopyData(PGconn *conn, char **buffer, int async); i PQgetCopyData p t i # i PQgetline p t i i PQputline p t i PQgetlineAsync p t i i PQputnbytes p t i i
Re: More object stuff
Dan Sugalski wrote: If someone'd like to take a shot at making a nice OO wrapper for Postgres, especially if they'd like to upgrade the postgres interface to 7.4, I would very much appreciate it. It'd be a nice demo, and a good start on a DBI module for us. (And yeah, there's an element of do my job for me here. Sorry 'bout that) Could you be more specific. If part of what you want is the following files updated to reflect libpq-7.4 then I am more than willing to do it for you. parrot/library/postgres.declarations parrot/library/postgres.pasm Although I imagine there is more to it than this ;-) As for the OO wrapper. Are you after a pasm library that takes advantage of objects and hides the details of libpq-fe.h? I think I could start something if no one else has already started anything. Harry Jackson (no longer surnameless ;-)
Re: Word for the day: Undocumentation
Forgive me if I am looking in the wrong place for some of this stuff. I only started looking at this today. --- Michael Scott [EMAIL PROTECTED] wrote: I'm fine with that, I understand why - this is not a rant - but I do think that Parrot has a steep learning curve and that good documentation is essential if we want to lower it. The potential benefits seem obvious. I had a read through intro.pod (found a very minor error, patch submitted ) and decided that I might be able to write some tests but I am having a hell of a time trying to find out what tests have been written and which havn't. I have written a few _simple_ tests and deliberately broken a few others and I would like to write a few but I have no idea what needs doing. I have also been unable to find out if there is any sort of methodolgy to the testing. I have had a look through ./parrot/t/* and found a lot of test files but very little actual details on what each test was testing. I could infer from the code what most of the tests are trying to achieve but some docs would be nice. If there are more docs can someone point me at them (I have read most of ./parrot/docs/*.pod) and any other pod I have been able to find. After all that I suppose I should volunteer some time. I have some time on my hands at the moment and would like to get involved in some fashion. Unfortunately I am not a C guru but I am quite happy to write tests[0] in assembler or do documentation. In what areas do people think documentation or tests are most needed, I would be happy to start with the docs first until I am more comfortable with the code, ideas, advice? H [0] As soon as I am comfortable with the assembler, most of the easier tests seem to have been written. __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
Re: Word for the day: Undocumentation
Forgive me if I am looking in the wrong place for some of this stuff. I am quite new to this. --- Michael Scott [EMAIL PROTECTED] wrote: I'm fine with that, I understand why - this is not a rant - but I do think that Parrot has a steep learning curve and that good documentation is essential if we want to lower it. The potential benefits seem obvious. I had a read through the intro.pod and decided that I might be able to write some tests but I am having a hell of a time trying to find out what tests have been written and which ones have not. I have written a few _simple_ tests and deliberately broken a few others and I would like to contribute some but I have no idea what needs doing. I have also been unable to find out if there is any sort of methodolgy to the testing. I have had a look through ./parrot/t/* and found a lot of test files but very little actual details on what each test was testing. I could infer from the code what each test was trying to achieve but some docs would be nice. If there are more docs can someone point me at them (I have read most of ./parrot/docs/*.pod). After all that I suppose I should volunteer for something. I have some time on my hands at the moment and would like to get involved in some fashion. Unfortunately I am not a C guru but I am quite happy to write tests[0] in assembler or do documentation. In which areas do people think documentation or tests are most needed, I would be happy to start with the docs first until I am more comfortable with the code, ideas, advice? H [0] As soon as I am comfortable with the assembler, most of the easier tests seem to have been written. __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
