Re: Questions about abstract pmcs
Stéphane Payrard [EMAIL PROTECTED] wrote: 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. I don't think that we need the type names of abstract PMCs. Unlike other pmcs, abstract pmcs have names that are all lower case, is that deliberate? Yes. What is the difference between declaring a pmc as Cnoinit or as Cabstract? Currently when one is set, the other is also set. Cabstract is unimplemented. 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. The Cisa of derived type shows abstract base types too. That's probably enough. For now, I'd rather not have vtables for these (each unused piece of memory is kind of an overhead). But it could be, that we finally have real Cabstract base types, that implement some useful functionality on behalf of derived child classes. stef leo
JVM as a threading example (threads proposal)
This is a threading proposal, in the form of a collection of notes. Rationale: We need to constantly compare parrot to the JVM, and in particular have a deep understanding of cases where the JVM performs well (or better than parrot). The reason for this is obvious: the JVM is the product of several years of RD, and we need to benefit from that where we can. Of course, there are places where the two will necessarily differ (due to differences such as static v. dynamic typing of their target languages), but these necessary differences don't account for everything, and it's important for us to understand if individual performance differences are fundamental, or incidental. In particular, it's instructive to look at Java's threading strategy, and its impact on GC. I have 2 fundamental assumptions: 1) As stated by others before, Parrot needs to guarantee that its internal state is protected, even in the absence of proper synchronization by user code, though user-visible data structures may become corrupted from the user's perspective. (That is, a hash might suddenly lose some entries, but it can't become corrupted in such a way that a crash or memory leak might result.) To put it formally, no sequence of byte code can have the possibility of causing an attempt to read from, or write to, unallocated memory. [That may not cover all cases of corruption, but it gets at the main point.] This is particularly important in an embedded context--we want to be able to guarantee that bad bytecode can't crash the process in which parrot is embedded. Note that Java seems to provide similar guarantees (more on this below). 2) My second assumption is that if we can provide a safe and performant implementation which allows full-access threads (that is, without data-access restrictions imposed between threads), then access-restricted threads (such as Perl 5's ithreads) can be implemented on top of this. Note that thread creation in the access-restricted case will necessarily be slower, due to the need to copy (or COW-copy) additional data structures. So the theme is taking lessons from the JVM wherever we can. The focus is on how we can provide safe and high-performance threading without data-access restrictions between threads (in light of assumption 2 above). Notes and considerations: 1) As mentioned above, Java seems to guarantee robustness in the absence of proper user-level synchronization. In particular, section 2.19 of the JVM spec http://java.sun.com/docs/books/vmspec/2nd-edition/html/ Concepts.doc.html#33308 states the following: When a thread uses the value of a variable, the value it obtains is in fact a value stored into the variable by that thread or by some other thread. This is true even if the program does not contain code for proper synchronization. For example, if two threads store references to different objects into the same reference value, the variable will subsequently contain a reference to one object or the other, not a reference to some other object or a corrupted reference value. (There is a special exception for long and double values; see §8.4.) (It also further states, In the absence of explicit synchronization, an implementation is free to update the main memory in an order that may be surprising. Therefore, the programmer who prefers to avoid surprises should use explicit synchronization.) (Section 8.1 http://java.sun.com/docs/books/vmspec/2nd-edition/html/ Threads.doc.html#22197 also clarifies, A variable is any location within a program that may be stored into. This includes not only class variables and instance variables, but also components of arrays.) 2) It seems that Java provides these guarantees in part by relying on the atomicity of stores of 32-bit sized data. (This is atomic in the sense of no word tearing, meaning that when such a value is written to a memory location, any thread reading that location will see either the old or the new value, and not some other value.) Section 8.4 of the JVM spec http://java.sun.com/docs/books/vmspec/2nd-edition/html/ Threads.doc.html#22244 implies this, albeit indirectly. Due to the ubiquity of the JVM, it seems reasonable for Parrot to similarly rely on atomic stores, without compromising the range of platforms on which parrot can run. In practice, modern processors likely provide such a guarantee natively, without the need for explicit locking (though explicit locking could be employed in the seemingly rare case of a platform which provides threads but not atomic memory updates). If Java is relying on some other mechanism here, we need to understand what that is. 3) There seem to be 3 basic categories of things which need thread-safety: data structures internal to the VM (eg, opcode arrays, register stacks), variables (globals, registers, etc.; most importantly, those which hold references to aggregate
Re: JVM as a threading example (threads proposal)
At 01:29 -0800 1/12/04, Jeff Clites wrote: I'll publish some actual benchmarking numbers, with source code, separately. (They're just sort of interesting to have on hand.) If you're benchmarking Perl 5 ithreads for memory usage, you might want to have a look at Benchmark::Thread::Size. Liz
Re: [PATCH] Continuations now close over register stacks
Luke Palmer [EMAIL PROTECTED] wrote: This patch re-implements the register backing stacks as PObjs (so they can be garbage-collected), honors their COW flags, and adds them to the interpreter context (where they should be, honest!). As a healthy side-effect, it encapsulates their behavior nicely into register.c, when before their guts were splattered all over the source. Applied, thanks. Some remarks WRT the patch: 1) struct RegStack doesn't need the chunk_size data member top-data.buflen has the exact size So ctx.type_reg_stack could be a general StackChunkBuf 2) pad, control and user stacks could very likely use the same stack infrastructure. COW copying of these is still b0rken but needed as well. 3) The LEA allocators implementation does only handle COW copying of string memory. This should be fixed, that is, allocate one sizeof(int) + the requested memory and consider the memory at buffer+size as the refcount (used during DOD) - or increment bufstart by sizeof(int), so that the actual allocated memory ptr is at bufstart - sizeof(int). But that has to be consistent for strings and plain buffers. 4) Several Parrot_allocate_zeroed could be just Parrot_allocate as the memory is either copied over or initialized later. And finally a remark WRT COWed Buffers: 5) cow_copy_context() could still be wrong. Both contexts share the same Buffer header. When now this shared buffer header is marked COW each change to the context would unshare the buffer by creating a distinct copy. This also means, that if the COWed stack copy isn't changed in the Sub and after return from the Sub an item is pushed on that stack, it would be copied. I know that I did this for other buffers in the context but it is wrong somehow - IMHO. COWed strings also seem to suffer from that problem. Both buffer headers are marked COW. Even if the shared copy goes out of scope, the COW flag remains - so changing that string later would do a copy of the buffer first, which isn't needed as there is only one user of the buffer left. It could be simpler if we have an explicit refcount for COWed objects. We need that during DOD anyway with some overhead. Takers for these steps wanted, please drop a short note. thanks, leo
[perl #24880] [PATCH] A few more jitted ops on ppc, and build_tools/jit2h.pl modification
# New Ticket Created by Jeff Clites # Please include the string: [perl #24880] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=24880 Here is a patch to add a few more jitted ops to core.jit for ppc (noop, neg_i, neg_n, abs_n, abs_i). It also modifies build_tools/jit2h.pl slightly to allow for templates based on other templates (the patch just moves a block of code already in the script). This makes some things a bit tidier, but if it's problematic then I can rework the patch to core.jit to work without it. JEff more-ppc-jitted-ops.patch Description: Binary data
Docs and releases
Has a date been set for the next release? Are the docs (especially the PDDs) upto date on best practices? If not, will that be a goal for the next release? Tim.
Re: [perl #24880] [PATCH] A few more jitted ops on ppc, and build_tools/jit2h.pl modification
Jeff Clites [EMAIL PROTECTED] wrote: Here is a patch to add a few more jitted ops to core.jit for ppc (noop, neg_i, neg_n, abs_n, abs_i). Thanks, applied. It also modifies build_tools/jit2h.pl slightly to allow for templates based on other templates (the patch just moves a block of code already in the script). This makes some things a bit tidier, but if it's problematic then I can rework the patch to core.jit to work without it. No problem with that. JEff leo
Re: Docs and releases
Tim Bunce [EMAIL PROTECTED] wrote: Has a date been set for the next release? No, not yet. But I can imagine to have a release in February. It of course depends on progress WRT objects and threads. Are the docs (especially the PDDs) upto date on best practices? No. Not much better then as of 0.0.13. If not, will that be a goal for the next release? Having docs in sync is a permanent goal :) Tim. leo
Back, and digging through
I've only got a couple hundred messages to dig through, so this ought to be fun. :) Don't be too surprised if I end up sending mail on things that've already been dealt with, since I'm trying not to let anything get Warnocked this time through. (I fully expect it'll happen, but at least I can try...) I see we've got one thread proposal. I'll read through it and see where things go from there. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Docs and releases
At 11:52 AM + 1/12/04, Tim Bunce wrote: Has a date been set for the next release? Nope. I suppose we could shoot for another holiday release, if someone's got a good february one. Are the docs (especially the PDDs) upto date on best practices? Alas not, no. If not, will that be a goal for the next release? Yeah, I think getting the docs better will be an aggressive goal for the next release. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: patch to support nums, strings and pmcs as attributes
At 10:22 PM +0100 1/10/04, Stéphane Payrard wrote: --- classes/parrotobject.pmc.orig 2003-12-06 01:00:29.0 +0100 +++ classes/parrotobject.pmc2004-01-10 21:09:08.0 +0100 Keen. And, while worth applying, I'm not sure it should go to parrotobject. (Or, rather, I think it ought not, and should instead be applied to default or one of the array/hash base classes instead) Access to actual attribute slots for a PMC ought be done through a separate vtable entry. I'm not sure if I've talked about this any in the past, but even if I have objects have dragged on so long I'm not surprised nobody remembers. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Contextual calls
At 1:11 AM -0700 1/11/04, Luke Palmer wrote: I was uneasy when the Cnum_eq and Cstr_eq 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. Then your compiler is going to have to do an awful lot of work when emitting bytecode. This is an acceptable thing. Separate and distinguishable string and numeric comparisons are deeply fundamental to almost every language I can think of, including perl 6. There will, occasionally, be cases where you need to use a generic equality and count on multimethod dispatch for proper handling, but that doesn't eliminate the need for string and numeric comparisons. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Continuations don't close over register stacks
Picking the last entry in this thread to reply to...
Here's the scoop with register stacks, stacks in general, and continuations.
The pointers to all these stack tops *should* be part of a
continuation, the same as the registers themselves should be. When a
continuation is taken, all the frames to the top should be marked
COW, and any access to the frames should copy them.
This does have the interesting side-effect of preserving integer
and float values across continuations, while allowing string and PMC
values to fluctuate. That is, since string and PMC stack entries are
pointers, changes to their contents propagate across continuations,
while changes to ints and floats do not. This has some ramifications
for code saving loop counters and whatnot on the stack. Short (though
not all that satisfying) answer--deal with it, or use a PMC.
Stack frames should probably just be globs of stack frame entry
memory with a pobj stuck on the front, allocated in one big hunk
(with pointers fixed up on allocation), to make DODing the things
easier. That is, a stack chunk should have the structure:
struct hunk {
struct pobj header;
INTVAL used;
INTVAL avail;
struct hunk *upchain;
struct regframe RegisterFrame[FRAMES_PER_HUNK];
}
more or less. When one's allocated the pointers in the header get set
to point to the body, or whatever, with flags set appropriately.
Modifying one marked COW should just copy the whole wad to a new hunk
and adjust the header pointers as need be.
To avoid massive thrashing, we should add a frameclose op, to mark a
frame as closed and start a new one regardless of how many entries
might still be free in the frame. When the interpreter is about to do
something that'll result in a COW marking of the frame it closes the
frame off and starts a new one (though marking a topmost entry as COW
could automatically close it. There are issues there)
Also to avoid thrashing some, adding a multi-entry pop will help.
Dropping 2 or more stack entries may toss an entire COW'd frame,
avoiding the need to make a copy just for the purpose of messing
around with the used/avail counts to drop it two or three ops later.
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: [PATCH] Continuations now close over register stacks
At 1:02 AM -0500 1/9/04, Michal Wallace wrote: I changed my compiler to call savetop before every function call, and that passes my tests but I'm having trouble visualizing why. Would I ever NOT want to call savetop before creating a continuation? Sure. The only reason to call savetop is if you want to save R16-31 of all four register sets. The only reason you'd do this is if you actually *care* about the contents of those four sets. If you don't care about one or more set, for example because your code is entirely PMC based and thus doesn't use the I, S, or N registers, you wouldn't -- it's a waste. Also, if your compiler's code analysis determines that none of the registers of a particular set are read without a previous write, then there'd be no reason to save that set. It's a matter of tracking register content lifetimes -- if all the registers in a set are effectively dead there's no reason to preserve the contents on the stack. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: More object stuff
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... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: More object stuff
At 6:03 PM + 1/11/04, 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. 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. 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. 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. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
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
PMC template generator. Perl 5 task
Okay, here's a task for the perl 5 proficient. I may have mentioned this before, but maybe not. What we need, or at least could really use, is a script that automatically generates missing vtable methods for PMCs. Not defaulting, the way we have now, but actual real working entries. For example, if we have a (non-hypothetical) Integer class which has get/set integer as real working vtable entries, the template generator should be able to construct get/set string, number, and PMC functions, a String class should be able to have get/set integer, number, and pmc functions, and so on. The binary vtable ops are also constructable this way in part, as are the keyed variants. (If there's a _keyed variant, the _keyed_int variant is constructable, and vice versa) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: patch to support nums, strings and pmcs as attributes
Dan Sugalski [EMAIL PROTECTED] wrote: At 10:22 PM +0100 1/10/04, Stéphane Payrard wrote: --- classes/parrotobject.pmc.orig 2003-12-06 01:00:29.0 +0100 +++ classes/parrotobject.pmc 2004-01-10 21:09:08.0 +0100 Keen. And, while worth applying, I'm not sure it should go to parrotobject. It is already applied. ... (Or, rather, I think it ought not, and should instead be applied to default or one of the array/hash base classes instead) The ParrotObject attribute accessors are mainly wrappers only adding the reserved internal count and then passing the method on to the array. The keyed_str variants additionally do a lookup for the attribute index first. Access to actual attribute slots for a PMC ought be done through a separate vtable entry. I'm not sure if I've talked about this any in the past, but even if I have objects have dragged on so long I'm not surprised nobody remembers. I'm pretty sure that attribute access wasn't mentioned yet. So I had implemented integers some time ago. Please have a look at t/pmc/object*.t for some experiments with attribute access syntax (and even a method call). I had also asked about attribute name mangling, but the thread drifted off towards globals name mangling, so this is still not addressed. leo
Re: yield op?
At 3:29 AM -0500 1/9/04, Michal Wallace wrote: It seems to me that invoke() is doing the right thing by swapping the context, but that there needs to be a yield() method (and opcode?) to balance it out. Yes, there does need to be one, or rather there needs to be something to refresh a continuation with the current information, since we don't really have a yield as such. This brings up some nasty issues with coroutines that we need to address, so compilers can emit the proper sequence of code to get or not get a new coroutine as they need. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
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: nci
Tim Bunce wrote: I see Dan says in his blog Yeah, I know, we should use libffi, and we may as a fallback, if we don't just give in and build up the function headers everywhere. I'm not familiar with libffi so this may be a dumb question, but why the apparent reluctance to use it? The reluctance probably doesn't have anything to do with its very liberal licensing terms... The libffi was originally produced by Cygnus, but is now actively maintained as part of GCC. http://sources.redhat.com/libffi/ http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libffi/LICENSE -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com garrett at scriptpro dot com
Re: lookahead for parrot/perl[5|6]?
At 8:27 PM + 1/11/04, Ewan Birney wrote: 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). D'oh! Time to get the website rev'd. I'll go dig up our volunteer for that and get it fixed. As for times: Now - an ideal world would be: Perl-5 or Perl-5 like syntax for lightweight scripting Indeterminate future. Java or Java-like syntax for objects The low-level object design will be done by Jan 30th. An consistent, few-cornor case, executation engine that can handle circular references and threads Circular refs are not a problem. Threads will have a finished design by this friday. I expect an implementation within three or four weeks. (I make no bets on when we've a fully bug-free thread implementation. If we did we might well be the first one ever... :) Embeddable in Apache like mod_perl Already doable, in a crude way. Doing this properly should take about two weeks of time for someone familiar with Apache's embedding interface. (With that time coincident with me having free time if it exposes some parrot issues that need resolving) perl6 as a language looks cute, but... is not so necessary. Just *not* going there. :) After Forth and DecisionPlus, I'm half-ready to implement INTERCAL then never touch a computing instrument more complex than an abacus... 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? For an Alpha, we need threads and objects, which have a time up there. We also need design and framework for proper async IO, events, runtime code loading, and notifications. (Partial implementations are in already for some of that) Having said that, I think we may put some off for Alpha 1. Its distinctly possible we'll have an a1 release for OSCON 2004, since we (well, *I*) will need alpha functionality to make sure the pie goes in the right direction. And, out of interest, what is the rate limiting step for this (amount of coffee given to Dan?) In large part, yes. Communication bandwidth and latency is also an issue -- there are things that we could clear up in a week if we got a half-dozen of the interested parties in a room with lots of white board space, coffee, and someone to take good notes that take a month or more to trickle out on the list. I realise this is a somewhat frustrating question to answer, but any answers (even partial) would help The frustrating questions are usually frustrating because they're important and we don't like the answers. Those are the ones that really ought to be dealt with first, like it or not. :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: More object stuff
At 4:07 PM + 1/12/04, Harry Jackson wrote: 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. Definitely. However... Having seen code in production, generally the fields aren't changeable and are known at compile-time, or folks are writing generic code (for better or worse). In the first case people use hash access because they know there's a name and city field in the results, and in the second case they're iterating across the keys and pulling out values. Since folks are going to wrap the results in a hash regardless of whether it's a good idea or not (not going there... :) we might as well have it in at the very lowest level where we can get the information most efficiently. 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. 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) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Continuations don't close over register stacks
Dan Sugalski [EMAIL PROTECTED] wrote:
struct hunk {
struct pobj header;
INTVAL used;
INTVAL avail;
Only one of these is needed (and currently used: used)
struct hunk *upchain;
struct regframe RegisterFrame[FRAMES_PER_HUNK];
I'd rather not have the store statically inside the hunk:
- small objects code currently has an upper limit for sized header pools
- more and differently sized pools impose negative effects on DOD times
- it needs more code duplication
leo
Re: Docs and releases
At 4:47 PM + 1/12/04, Tim Bunce wrote: On Mon, Jan 12, 2004 at 09:33:57AM -0500, Dan Sugalski wrote: At 11:52 AM + 1/12/04, Tim Bunce wrote: Has a date been set for the next release? Nope. I suppose we could shoot for another holiday release, if someone's got a good february one. Valentines day? :-) I was thinking that was mostly a US holiday, and a pathetically commercial one at that (not, mind, that we've got much else at the moment, but I'm *not* going there... :) [ On a whim I thought I'd google for parrot and valentine: http://www.bram.net/humor-archive/1999-Feb/msg00012.html ] Are the docs (especially the PDDs) upto date on best practices? Alas not, no. If not, will that be a goal for the next release? Yeah, I think getting the docs better will be an aggressive goal for the next release. I think that's wise. While parrot gains features and abilities at a steady pace the attractiveness of parrot as a development platform grows exponentially. The developers _of_ parrot need to keep in mind the needs of those poised on the edge of developing _in_ parrot. Yeah, very good point. I need to scrawl down my recent experiences before I forget, which would be somewhat unfortunate. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
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: PMC template generator. Perl 5 task
Dan Sugalski writes: Okay, here's a task for the perl 5 proficient. I may have mentioned this before, but maybe not. What we need, or at least could really use, is a script that automatically generates missing vtable methods for PMCs. Not defaulting, the way we have now, but actual real working entries. For example, if we have a (non-hypothetical) Integer class which has get/set integer as real working vtable entries, the template generator should be able to construct get/set string, number, and PMC functions, a String class should be able to have get/set integer, number, and pmc functions, and so on. The binary vtable ops are also constructable this way in part, as are the keyed variants. (If there's a _keyed variant, the _keyed_int variant is constructable, and vice versa) If there are no takers by Friday, I'll take this on. This is right up my alley :-) Luke
Re: [CONGRATS] Dan for 1st commercial use of Parrot :)
At 3:24 PM -0500 1/9/04, Melvin Smith wrote: :) Heh. It's not in production yet! Looking darned good, though. Good enough to stand up in front of the company principals and put on a non-rigged dog and pony show. (I know, boggle at the prospect, a DP with no tricks :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: lookahead for parrot/perl[5|6]?
And, out of interest, what is the rate limiting step for this (amount of coffee given to Dan?) In large part, yes. Communication bandwidth and latency is also an issue -- there are things that we could clear up in a week if we got a half-dozen of the interested parties in a room with lots of white board space, coffee, and someone to take good notes that take a month or more to trickle out on the list. I realise this is a somewhat frustrating question to answer, but any answers (even partial) would help The frustrating questions are usually frustrating because they're important and we don't like the answers. Those are the ones that really ought to be dealt with first, like it or not. :) :) that answered my question. Many thanks Dan... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
A warning: The short task list
In no order, but the week's Dan makes up his mind list: *) Namespaces *) PMC init params *) Thread design As well as getting PDD16 patched up some. Might add more as I dig back through the backlog (only a few hundred messages left to go...) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Questions about abstract pmcs
On Mon, Jan 12, 2004 at 10:05:51AM +0100, Leopold Toetsch wrote: Stéphane Payrard [EMAIL PROTECTED] wrote: 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. I don't think that we need the type names of abstract PMCs. If one wants to add typechecking to imcc, it is necessary to have abstract/noinit types. Example: .sym scalar var new var, .Perlint # the instance is a substype of Cscalar Unlike other pmcs, abstract pmcs have names that are all lower case, is that deliberate? Yes. What is the difference between declaring a pmc as Cnoinit or as Cabstract? Currently when one is set, the other is also set. Cabstract is unimplemented. 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. The Cisa of derived type shows abstract base types too. That's probably enough. For now, I'd rather not have vtables for these (each unused piece of memory is kind of an overhead). There is not so many abstract pmc types and one could manage to use shorter vtables for these types with init methods that trigger exceptions. Other methods entries are not necessary (except for some introspection purpose) because they will never be called. But it could be, that we finally have real Cabstract base types, that implement some useful functionality on behalf of derived child classes. My understanding is that we already have that. Cnoinit types define methods used by derived types. So I still fail to understand the difference between Cnoinit and Cabstract leo -- stef
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
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. With an array they come out in the order they are aksed for. 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. 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). 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.) JEff
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
Harry Jackson wrote: I think that there are a lot of people who would help but the learning curve seems too 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. [...] Harry Jackson If there are any shy lurkers out there please speak now or forever hold your peace. Yes, I'm a shy lurker.
Re: nci
On Sat, Jan 10, 2004 at 09:42:14PM +, Tim Bunce wrote: On Sat, Jan 10, 2004 at 08:31:21PM +0100, Leopold Toetsch wrote: Jeff Clites [EMAIL PROTECTED] wrote: I assume the plan is to get on-the-fly building of NCI stubs working everywhere. Platforms where that works don't need the functions generated by build_nativecall.pl, but right now that's only i386; it's a JIT-like and pretty difficult piece of code to write, but it should eventually work on every platform which supports JIT, at least. It looks like, that we can't get each possible permutation of signatures built statically. This would also boost executable size beyond any reasonable limits. I'ts a JIT-like code but its not too difficult to implement and indpendent of JIT is implemented. It just needs a bit of knowledge of the architectures ABI (how functions get their params and return these) and of course how to implement that. I'm really not an assembly code hacker, but JITted NIC for i386 was implemented really quickly. I see Dan says in his blog Yeah, I know, we should use libffi, and we may as a fallback, if we don't just give in and build up the function headers everywhere. I'm not familiar with libffi so this may be a dumb question, but why the apparent reluctance to use it? In http://www.nntp.perl.org/group/perl.perl6.internals/253 I see Garrett Goebel quotes Bruno Haible saying I could agree to the LGPL license. Perl could then use ffcall as a shared library (linked or via dlopen) And I see http://www.parrotcode.org/docs/faq.pod.html says Code accepted into the core interpreter must fall under the same terms as parrot. Library code (for example the ICU library we're using for Unicode) we link into the interpreter can be covered by other licenses so long as their terms don't prohibit this. So it seems there's no licensing issue preventing parrot using libffi. Is that right? Are there any others? Tim.
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: nci
At 10:13 AM -0600 1/12/04, Garrett Goebel wrote: Tim Bunce wrote: I see Dan says in his blog Yeah, I know, we should use libffi, and we may as a fallback, if we don't just give in and build up the function headers everywhere. I'm not familiar with libffi so this may be a dumb question, but why the apparent reluctance to use it? The reluctance probably doesn't have anything to do with its very liberal licensing terms... Nope. The two issues were portability and the prospect of a library which isn't ours that we'd need to maintain if we were distributing it. I'm fine with someone taking a stab at teaching Configure to probe for it on platforms that don't have the JIT building up function headers already, and teaching nci.c to use it in that case. (As long as the order of preference is JIT building functions, libffi, current hackish NCI scheme is maintained) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Docs and releases
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. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: More object stuff
At 4:50 PM + 1/12/04, Harry Jackson wrote: 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. 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. 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. 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 ;-) Heh. Isn't error handling always fun? I think I need to put exceptions on this week's todo list. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Docs and releases
I'm currently building some docs related modules which will allow us to create an html tree from the pod, inline stuff included. I cleaned up all the pod errors last week and was going to report on that but got sidetracked when I realised that POD::Checker diverged somewhat from Perl's own pod standards, and that POD-Simple was the way to go. See http://www.nntp.perl.org/group/perl.pod-people/1092 for the details. Once we have an html tree, I'm expecting that problems with the content will be more apparent and hence quicker to identify and solve. For the moment the idea is just to build the html locally, though when it is respectable it would be good to have it also online. I'll aim to have something decent in place for next release, so we can toot toot about it. Mike On 12 Jan 2004, at 15:33, Dan Sugalski wrote: At 11:52 AM + 1/12/04, Tim Bunce wrote: Has a date been set for the next release? Nope. I suppose we could shoot for another holiday release, if someone's got a good february one. Are the docs (especially the PDDs) upto date on best practices? Alas not, no. If not, will that be a goal for the next release? Yeah, I think getting the docs better will be an aggressive goal for the next release. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Docs and releases
Well, one thing that people can contribute that doesn't require much (if any) knowledge of the internals is tests (whether in PASM, PIR, or one of the other languages that run on top of Parrot). Tests that uncover bugs are particularly helpful! Simon
Tests! Tests are your friend! (was Re: Docs and releases)
At 1:26 PM -0500 1/12/04, Simon Glover wrote: Well, one thing that people can contribute that doesn't require much (if any) knowledge of the internals is tests (whether in PASM, PIR, or one of the other languages that run on top of Parrot). Tests that uncover bugs are particularly helpful! Absolutely. I definitely don't want to underestimate the value of tests -- they're amazingly helpful. They also don't have to necessarily be dull grab one op, make sure it works, move on sorts of things, though those are good. More abusive tests of IMCC's allocators (using lots of .local or temp variables), or the garbage collector (allocating and freeing up masses of data) are also quite useful, as are tests designed specifically to make parrot fall down and die in as nasty a way as possible. Destruction testing is handy if you're trying to make sure you can't be destroyed... :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Continuations don't close over register stacks
At 5:47 PM +0100 1/12/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
struct hunk {
struct pobj header;
INTVAL used;
INTVAL avail;
Only one of these is needed (and currently used: used)
struct hunk *upchain;
struct regframe RegisterFrame[FRAMES_PER_HUNK];
I'd rather not have the store statically inside the hunk:
- small objects code currently has an upper limit for sized header pools
Doesn't mean we have to use them, honestly. A separate arena for them is fine.
- more and differently sized pools impose negative effects on DOD times
While true, we're already walking the stack frame areas, so I'm not
sure it'll work out that way.
- it needs more code duplication
True, unless we yank out existing special-purpose code. If stack
frame PMCs end up looking to the DOD like array PMCs, well... less
code to deal with, since we'll be using the array code that already
exists. The tradeoff is code in the allocator, but I'm not sure it'll
actually be more code, just different code.
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
RE: nci
Tim Bunce wrote: Tim Bunce wrote: I see Dan says in his blog Yeah, I know, we should use libffi, and we may as a fallback, if we don't just give in and build up the function headers everywhere. I'm not familiar with libffi so this may be a dumb question, but why the apparent reluctance to use it? In http://www.nntp.perl.org/group/perl.perl6.internals/253 I see Garrett Goebel quotes Bruno Haible saying I could agree to the LGPL license. Perl could then use ffcall as a shared library (linked or via dlopen) And I see http://www.parrotcode.org/docs/faq.pod.html says Code accepted into the core interpreter must fall under the same terms as parrot. Library code (for example the ICU library we're using for Unicode) we link into the interpreter can be covered by other licenses so long as their terms don't prohibit this. So it seems there's no licensing issue preventing parrot using libffi. Is that right? Are there any others? My bad. In my comments on Dan's blog, I confused libffi with ffcall. Both do roughly the same thing... The libffi was originally produced by Cygnus, but is now part of GCC. http://sources.redhat.com/libffi/ http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libffi/LICENSE ffcall was produced by Bruno Haibel as part of his CLISP package. http://www.haible.de/bruno/packages-ffcall.html ffcall used to be considered more mature/stable, but since libffi was included in GCC the general impression true or not is that libffi is more actively maintained. From mailing lists and csv logs, it looks like both are actively maintained... -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com garrett at scriptpro dot com
Re: patch to support nums, strings and pmcs as attributes
On Sun, Jan 11, 2004 at 07:33:12PM +0100, Stéphane Payrard wrote: 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. Thanks, applied Nicholas Clark
Re: Docs and releases
Harry Jackson wrote: If there are any shy lurkers out there please speak now or forever hold your peace. Poit. That's me.
Re: JVM as a threading example (threads proposal)
On Monday, January 12, 2004, at 04:29 , Jeff Clites wrote: 5) Java seems to use a check-in/check-out model for access to global data, in which global data lives in a central store, but is copied back-and-forth to thread-local storage for modification. I don't fully understand the performance benefit which I assume this provides, but this is something else we need to understand. It's discussed in detail in the threads section of the JVM spec, http://java.sun.com/docs/books/vmspec/2nd-edition/html/ Threads.doc.html. The passage in question being: Every thread has a working memory in which it keeps its own working copy of variables that it must use or assign. As the thread executes a program, it operates on these working copies. The main memory contains the master copy of every variable. There are rules about when a thread is permitted or required to transfer the contents of its working copy of a variable into the master copy or vice versa. This is very obliquely phrased, but it refers to the register file and stack frame. Or, since the Java bytecode is stack-based, it refers to the stack. Gordon Henriksen [EMAIL PROTECTED]
Re: More object stuff
On Monday, January 12, 2004, at 11:37 , Dan Sugalski wrote:
At 4:07 PM + 1/12/04, Harry Jackson wrote:
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.
Definitely. However... Having seen code in production, generally the
fields aren't changeable and are known at compile-time, or folks are
writing generic code (for better or worse). In the first case people
use hash access because they know there's a name and city field in
the results, and in the second case they're iterating across the keys
and pulling out values.
Since folks are going to wrap the results in a hash regardless of
whether it's a good idea or not (not going there... :) we might as well
have it in at the very lowest level where we can get the information
most efficiently.
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. :)
Gordon Henriksen
[EMAIL PROTECTED]
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
[PATCH] Small register stack fix
This fixes a rather obvious and silly oversight in my patch. Luke Index: src/register.c === RCS file: /cvs/public/parrot/src/register.c,v retrieving revision 1.35 diff -u -r1.35 register.c --- src/register.c 12 Jan 2004 09:50:26 - 1.35 +++ src/register.c 12 Jan 2004 19:54:36 - @@ -107,7 +107,8 @@ struct RegisterChunkBuf* buf = new_bufferlike_header(interpreter, sizeof(struct RegisterChunkBuf)); *buf = *chunk; - +PObj_COW_CLEAR((PObj*)buf); + Parrot_block_DOD(interpreter); Parrot_allocate_zeroed(interpreter, (PObj*)buf, stack-chunk_size); Parrot_unblock_DOD(interpreter);
[PATCH] new_noinit and init ops
I have somewhat a predicament. I want to create a continuation, and
have that continuation stored in the register stack that it closes over
(this is how I'm implementing a loop with continuations). Unless I'm
having a major braino, I don't think this is possible at the moment.
I got around this by adding two ops: new_noinit and init. I've included
a patch that implements them. Other solutions welcome.
Luke
Index: ops/pmc.ops
===
RCS file: /cvs/public/parrot/ops/pmc.ops,v
retrieving revision 1.16
diff -u -r1.16 pmc.ops
--- ops/pmc.ops 31 Dec 2003 11:54:38 - 1.16
+++ ops/pmc.ops 12 Jan 2004 19:54:45 -
@@ -52,6 +52,15 @@
Like above. The forth argument is a property hash - it isn't copied in,
only referended. The initializer may be NULL.
+=item Bnew_noinit(out PMC, in INT)
+
+Just like above, but doesn't initialize the PMC. You must call Binit
+on it before using it.
+
+=item Binit(in PMC)
+
+Initializes a PMC created with new_noinit.
+
=cut
op new(out PMC, in INT) {
@@ -60,9 +69,6 @@
abort(); /* Deserve to lose */
}
- /* Why?? If we're creating a continuation, the continuation PMC
- * needs to be in the destination register before its init method
- * copies the registers. */
$1 = pmc_new_noinit(interpreter, $2);
$1-vtable-init(interpreter, $1);
goto NEXT();
@@ -84,6 +90,19 @@
$1-vtable-init_pmc_props(interpreter, $1, $3, $4);
goto NEXT();
}
+# }
+
+op new_noinit(out PMC, in INT) {
+ if ($2 = 0 || $2 = enum_class_max) {
+internal_exception(1, Illegal PMC enum (%d) in new\n, (int)$2);
+ }
+ $1 = pmc_new_noinit(interpreter, $2);
+ goto NEXT();
+}
+
+op init(in PMC) {
+ $1-vtable-init(interpreter, $1);
+ goto NEXT();
}
Re: [PATCH] new_noinit and init ops
Luke Palmer writes:
...
goto NEXT();
@@ -84,6 +90,19 @@
$1-vtable-init_pmc_props(interpreter, $1, $3, $4);
goto NEXT();
}
+# }
^
Don't mind that. I thought I saw an extra one, and commented it out to
make sure I wasn't being stupid. Wasn't, and forgot to uncomment.
Luke
+
+op new_noinit(out PMC, in INT) {
+ if ($2 = 0 || $2 = enum_class_max) {
+internal_exception(1, Illegal PMC enum (%d) in new\n, (int)$2);
+ }
+ $1 = pmc_new_noinit(interpreter, $2);
+ goto NEXT();
+}
+
+op init(in PMC) {
+ $1-vtable-init(interpreter, $1);
+ goto NEXT();
}
Re: [PATCH] new_noinit and init ops
At 1:00 PM -0700 1/12/04, Luke Palmer wrote: I have somewhat a predicament. I want to create a continuation, and have that continuation stored in the register stack that it closes over (this is how I'm implementing a loop with continuations). Erm. I don't think this is the right way to do this. Before I go any further, though -- you've a reason to not store this PMC in either a pad slot or the global stash, and just having it in a register is insufficient? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Questions about abstract pmcs
Stéphane Payrard [EMAIL PROTECTED] wrote: Example: .sym scalar var new var, .Perlint # the instance is a substype of Cscalar .sym pmc var is as good. There isn't any difference. Its even simpler for compiler writers. My understanding is that we already have that. Cnoinit types define methods used by derived types. So I still fail to understand the difference between Cnoinit and Cabstract AFAIK: Cabstract would be the thing with a vtable which is never instantiated. It could be useful for overriding a bunch of dynamic vtable methods on behalf of derived types. We don't have that currently. stef leo
Re: Questions about abstract pmcs
At 7:30 PM +0100 1/12/04, Leopold Toetsch wrote: Stéphane Payrard [EMAIL PROTECTED] wrote: Example: .sym scalar var new var, .Perlint # the instance is a substype of Cscalar .sym pmc var is as good. There isn't any difference. Its even simpler for compiler writers. Which brings up a question. What's the difference between .local and .sym? -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
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: [PATCH] new_noinit and init ops
On Mon, 12 Jan 2004, Luke Palmer wrote: I have somewhat a predicament. I want to create a continuation, and have that continuation stored in the register stack that it closes over (this is how I'm implementing a loop with continuations). Unless I'm having a major braino, I don't think this is possible at the moment. I got around this by adding two ops: new_noinit and init. I've included a patch that implements them. Other solutions welcome. Hmm. That sounds like Coroutine. Also, when you invoke any kind of sub with the calling conventions, it's already in P0. Can't you store that in a local variable on the invoke? Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
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: Questions about abstract pmcs
On Mon, Jan 12, 2004 at 03:16:50PM -0500, Dan Sugalski wrote: At 7:30 PM +0100 1/12/04, Leopold Toetsch wrote: Stéphane Payrard [EMAIL PROTECTED] wrote: Example: .sym scalar var new var, .Perlint # the instance is a substype of Cscalar .sym pmc var is as good. There isn't any difference. Its even simpler for compiler writers. Which brings up a question. What's the difference between .local and .sym? -- Currently, there is none. So I went for the shortest: grep -n -e LOCAL imcc.l imcc.l:181:.sym return(LOCAL); imcc.l:206:.localreturn(LOCAL); -- stef Dan
Re: [PATCH] Small register stack fix
Luke Palmer [EMAIL PROTECTED] wrote: This fixes a rather obvious and silly oversight in my patch. +PObj_COW_CLEAR((PObj*)buf); I don't think that works or better let's say: it's ok 50 percent - for the new buf chunk, but the old one, which maybe hasn't any refering COWed copy anymore still has the COW flag on that buffer. Comments towards my COW comments are more then welcome. The refount ideas is like this: 1) Prelims - the refcount is living somewhere after the shared PObj's bufstart - COWed copys get a new Buffer header (like strings do) (Both are given for strings, refcounts are already used for DOD/GC) 2) Functionality - a freshly COWed PObj has a refcount of 2 (we have two PObjs now) - another COW copy increases the refcount by 1 - operations like copy_chunk(or unmake_COW) are only needed if the refcount is = 2 - operations like unmake_COW clear the COW flag of the destination - that is the above patch - *and* decrease the refcount - DOD on POBj with refcount = 1 works like normal, i.e. the COW flag, if any, can be cleared - DOD with PObj with refcount = 2 is like now, we have to recalulcate the refcount (object might be dead in the meantime). leo
Re: cvs commit: parrot/t/pmc objects.t
Nicholas Clark [EMAIL PROTECTED] wrote:
(courtesy of St phane Payrard)
Sté{f,phane} that's still iso_8859_1. Nick, *they* are talking about
unicode operators and code.
,--[ man 7 iso_8859_1 ]
| 351 233 E9 é LATIN SMALL LETTER E WITH ACUTE
`--
SCNR,
leo
Re: [PATCH] Small register stack fix
At 10:09 PM +0100 1/12/04, Leopold Toetsch wrote: Luke Palmer [EMAIL PROTECTED] wrote: This fixes a rather obvious and silly oversight in my patch. +PObj_COW_CLEAR((PObj*)buf); I don't think that works or better let's say: it's ok 50 percent - for the new buf chunk, but the old one, which maybe hasn't any refering COWed copy anymore still has the COW flag on that buffer. I think I'd as soon leave COW-marked buffers as COW forever, or until they're garbage collected. Most stack segments that get marked COW are either going to be unreferenced, in which case the COW status is irrelevant, or are on a code path likely to create a continuation with a handle on the COW'd chunk thus making its COW status reasonable. Since this is going to be invisible to user code, we can leave it as is for now and revisit the entire scheme in its entirety later if we want to do an optimizing run across the source. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Questions about abstract pmcs
Dan Sugalski [EMAIL PROTECTED] wrote: Which brings up a question. What's the difference between .local and .sym? They are equivalent for plain code. *But* C.local was already used for local labels inside macros of assembler.pl - so is it now - and it was used for declaring variables in imcc. $ perldoc imcc/docs/macros.pod That means C.sym is the only way to declare a variable inside a macro. When we have the external macro preprocessor, we can easily get rid of that ambuigity. leo
Re: [PATCH] Small register stack fix
Dan Sugalski [EMAIL PROTECTED] wrote: At 10:09 PM +0100 1/12/04, Leopold Toetsch wrote: I think I'd as soon leave COW-marked buffers as COW forever, or until they're garbage collected. I'm thinking of that: 1) main creates and calls sub1 which returns - sub1 doesn't mess with the Buffer (PObj, stack) 2) main changes that Buffer - currently that would provoke an unneeded unamke_COW - copy the Buffer. The stack is any one of register frames, user, lexicals, and control for continations. Then we have currently the warnings Buffer for all subs. are either going to be unreferenced The problem is the calling context IMHO. And DOD isn't run that often as main might call new subs. Since this is going to be invisible to user code, we can leave it as is for now and revisit the entire scheme in its entirety later if we want to do an optimizing run across the source. That's true. But while at that again, it may be worth some more thoughts. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk leo
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: [PATCH] Small register stack fix
Dan Sugalski writes: At 10:09 PM +0100 1/12/04, Leopold Toetsch wrote: Luke Palmer [EMAIL PROTECTED] wrote: This fixes a rather obvious and silly oversight in my patch. +PObj_COW_CLEAR((PObj*)buf); I don't think that works or better let's say: it's ok 50 percent - for the new buf chunk, but the old one, which maybe hasn't any refering COWed copy anymore still has the COW flag on that buffer. I think I'd as soon leave COW-marked buffers as COW forever, or until they're garbage collected. Most stack segments that get marked COW are either going to be unreferenced, in which case the COW status is irrelevant, or are on a code path likely to create a continuation with a handle on the COW'd chunk thus making its COW status reasonable. I agree with Dan here. Thinking about the common cases, marking COW means marking immutable, as in a continuation. Once that's made, it will never become mutable again. Indeed, once the continuation gets collected, then you can unmark the stack, but half of it's probably already copied and in use somewhere else instead. But that patch needs to go in anyway, as copying something so you can mutate it and then keeping it cow is... silly at best. Luke Since this is going to be invisible to user code, we can leave it as is for now and revisit the entire scheme in its entirety later if we want to do an optimizing run across the source. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [PATCH] new_noinit and init ops
Michal Wallace writes: On Mon, 12 Jan 2004, Luke Palmer wrote: I have somewhat a predicament. I want to create a continuation, and have that continuation stored in the register stack that it closes over (this is how I'm implementing a loop with continuations). Unless I'm having a major braino, I don't think this is possible at the moment. I got around this by adding two ops: new_noinit and init. I've included a patch that implements them. Other solutions welcome. Hmm. That sounds like Coroutine. Uh, how so? Are we mixing up Continuation/Coroutine vocabulary again? Also, when you invoke any kind of sub with the calling conventions, it's already in P0. Can't you store that in a local variable on the invoke? Yeah, I wouldn't normally consider it pad material, but that does seem like the cleanest way at the moment. Luke
find_global failing
Hi, I currently have a file named win32.pasm containing the following:- saveall loadlib P1, 'user32' dlfunc P2, P1, 'MessageBoxA', 'llttl' store_global 'MessageBox', P2 # MANY MORE LINES LIKE THIS restoreall I compile that file to a .pbc file, which works out OK. In then have an imc file that starts like this:- .sub _MAIN # Load Win32 library. load_bytecode win32.pbc # Look up MessageBox function. find_global $P1, MessageBox Executing that results in the following error:- Global 'MessageBox' not found in file '(unknown file)' near line -1
Re: Docs and releases
Harry~ You have outlined my situation exactly. I completely agree. Matt Harry Jackson wrote: 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: Docs and releases
Ping. One quiet lurker here. I'd like to help out, but not really sure where to start. Given Dan's suggestion, I think I might start looking at some more abusive-type tests. Destruction and dissection can be fun. I'd be happy to help out in other newbie-type ways, too. --Kevin Harry Jackson wrote: 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: [PATCH] new_noinit and init ops
On Mon, 12 Jan 2004, Luke Palmer wrote: Michal Wallace writes: On Mon, 12 Jan 2004, Luke Palmer wrote: I have somewhat a predicament. I want to create a continuation, and have that continuation stored in the register stack that it closes over (this is how I'm implementing a loop with continuations). Hmm. That sounds like Coroutine. Uh, how so? Are we mixing up Continuation/Coroutine vocabulary again? :) Well... A Coroutine is a pausable, resumable continuation, right? Or basically a closure with a continuation inside it. I was just guessing how you might be implementing the loop. It sounds like a recursive tail call, but that struck me as a job for goto instead of a continuation. So I thought maybe you needed the continuation to save for later, and that made me think of a Coroutine. That's what was running through my head anyway. As for why I mentioned it based on all those assumptions... uhh, beats me. My real point was just the part about the calling conventions the thing you're calling in P0. :) Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
Re: [PATCH] new_noinit and init ops
Michal Wallace writes: On Mon, 12 Jan 2004, Luke Palmer wrote: Michal Wallace writes: On Mon, 12 Jan 2004, Luke Palmer wrote: I have somewhat a predicament. I want to create a continuation, and have that continuation stored in the register stack that it closes over (this is how I'm implementing a loop with continuations). Hmm. That sounds like Coroutine. Uh, how so? Are we mixing up Continuation/Coroutine vocabulary again? :) Well... A Coroutine is a pausable, resumable continuation, right? Or basically a closure with a continuation inside it. Both of those sentences seem wildly redundant to me. I think we might be stuck on vocabulary. We're surely both understanding the same thing in different ways. A continuation is one snapshot -- it never changes, it never runs. To invoke the continuation is to take you back to that snapshot and start running from there. To invoke it a second time is exactly like invoking it the first time. A coroutine is like a variable that holds continuations, and updates itself whenever it yields. I guess that's the best way I can put it with my affliction against coming up with good similes. I think this is what you were saying... maybe. But it's easy to implement a loop using a single continuation. Like this: newsub $P0, .Continuation, again again: # ... loop body invoke $P0 That's not *exactly* what I was doing. All I was doing was implementing a loop that called subs repeatedly with a backtrack continuation, so they could jump out at any point in their execution. It seemed odd that there was no way to keep the continuation I was giving everyone around without using a lexical pad. It's working now (there are some weird things going on though which I'm trying to track down), and I don't really mind the lexical pad. Luke I was just guessing how you might be implementing the loop. It sounds like a recursive tail call, but that struck me as a job for goto instead of a continuation. So I thought maybe you needed the continuation to save for later, and that made me think of a Coroutine. That's what was running through my head anyway. As for why I mentioned it based on all those assumptions... uhh, beats me. My real point was just the part about the calling conventions the thing you're calling in P0. :) Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
Mr Parrot's Neighborhood
On Mon, 12 Jan 2004, Luke Palmer wrote:
Well... A Coroutine is a pausable, resumable continuation, right?
Or basically a closure with a continuation inside it.
Both of those sentences seem wildly redundant to me. I think we might
be stuck on vocabulary. We're surely both understanding the same thing
in different ways.
Yes. I was understanding it in the wrong way. :)
A continuation is one snapshot -- it never changes, it never runs.
To invoke the continuation is to take you back to that snapshot and
start running from there. To invoke it a second time is exactly
like invoking it the first time.
Thanks. I'd heard this a million times but putting it this way
made it click for me.
I've been thinking about continuations as if they were like
python functions. In python, functions are objects. You can
define them interactively at the prompt and then look inside
them and see some representation of their bytecode.
But with parrot, there's just one big long line of instructions.
A .pcc_sub isn't an object, just a little segment of the list of
instructions.
Okay... Here's a metaphor I'm working on to try and help me
understand how to picture all this. It's not finished (see
the end). Feedback appreciated:
===
MR PARROT'S NEIGHBORHOOD
Mr Parrot lives on a very long street. Each house on the
street contains an opcode. His job is to go door to door
and follow the instructions of the little ops.
Mr Parrot carries with him as much paper as he can carry.
Each sheet has 16 boxes on it, and he has eight different
stacks of them:
int 0..15 int 16..31
num 0..15 num 16..31
str 0..15 str 16..31 # should be string, I know
pmc 0..15 pmc 16..31
He also has about a zillion pockets on him. He can put
things in his pockets (and of course keep track of where
they are by writing it down in a pmc box). Every once
in a while, he goes through his pockets and throws out
anything he doesn't need anymore.
So starts at the first address, performs the instruction,
and then goes to whatever that opcode says. She might ask
him to write a number down in one of the boxes (set I0, 3)
or to copy one box to another (set I0, I1) or an object
to keep track of, or something equally simple.
Usually when he's done with the op, he just goes next door,
but sometimes the op tells him to go somewhere else, either
explicitly (goto label) or based on the values in the
boxes (le I0, I1, label) or the objects in his pockets
(le P0, P1, label).
Often, an op will tell him to copy the top sheet on one
(or some or all) of the stacks and put the copy on top
(push) or throw away the top sheet (pop). He gets
really mad if you tell him to throw away the last sheet,
or if a stack gets so big he can't carry it anymore.
Every once in a while, the op will tell Mr. Parrot to
do something like this:
- make copies of all your stacks of paper
- put the copies inside a briefcase
- write this delivery address on the briefcase
- (possibly) write a return address on the briefcase
- put the briefcase in your pocket
Is that an accurate portrayal of a continuation?
##
Now... I only described the register stacks. In docs/pmc/subs.pod
it lays out the differences between the different kinds of Subs.
It has this table:
Subtype ControlstackPadStack UserStack Warnings
Sub- - - C
Closure- C - C
Continuation C C C C
Coroutine C C C C
RetContinuationX X X X
C ... COWed copy is in context
X ... is in context
- ... isn't.
My problem is that I don't know what a Control stack, pad stack,
user stack, and warnings are.
Here's my guess:
ControlStack {
This is another set of smaller papers. One box each.
if Mr. Parrot meets a ret op, he takes the
top sheet and goes to whatever address is on it.
When we call a Sub, we write the return address on
the top sheet. Same with a closure.
** I don't understand what happens here when we call
a continuation.
}
PadStack {
Hmm. Does this mean lexical pads? In which case, it's
a list of friendly names that he uses to remind him
which box or pocket a particular thing is in.
}
UserStack {
By process of elimination, this would be the eight
register stacks?
}
Warnings {
** Beats me. Is this for holding exception handlers?
}
Final questions:
What's a context?
How would I picture Eval? Does that involve building new houses?
A coroutine is like a variable that holds continuations, and updates
itself whenever it yields. I guess that's the best way I can put
it with my affliction
Re: Docs and releases
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 :-/) 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 - make gives an implicit declaration of posix_memalign, but doesn't seem to have problems beyond this - a lot of warnings about implicitly truncating to unsigned type - a lot of warnings about discarding qualifiers (I don't know how much people worry about these kinds of things, but I found with the software I'm working on atm, that implicity truncation to unsigned was a problem found only on LinuxPPC, but not on LinuxX86, something to do with differences between the gcc's) 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 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. I'm really impressed with the amount of work people are doing on parrot and related stuff. Keep up the good work! :-) Later Paul -- [EMAIL PROTECTED] Department of Physics University of Queensland St Lucia Brisbane Queensland 4072 Australia Quantum Mechanics: the dreams stuff is made of.
