Re: The reason for scads of keyed variants
At 11:17 PM +0200 9/1/03, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: [ heavily snipped ] Now, for aggregates that hold PMCs ... ... and on JITted cores there's no win at all. For aggregates that *don't* hold PMCs, though, that's where the win is. If we don't have direct operations on aggregate elements but instead have to do a fetch and perform the operation on what we fetch, it means we have to create a temporary PMC for each 'fake' entry, one potentially with a fair amount of knowledge about how the aggregate works, which means that every aggregate will need to provide two vtables, one for itself and one for an aggregate entry. I don't see the point here especially why we would need a temporary PMC. If we have an array of packed ints, I just need a pointer to the element to work on it. This is very similar to the Ckey opcode I had in some of my proposals. We can't do that. There's insufficient information about the variables at compiletime to do anything other than call into the PMC to do the operation, so the internal representation's irrelevant. As far as parrot is concerned, it's a PMC and it doesn't know anything about the inside. Going with direct operations on keyed aggregates, then, makes the code somewhat more dense, since we only need to access one vtable per operand rather than two (one to fetch the data and one to operate on it). That's balanced somewhat by having to have two sets of PMC opcodes, one that operates on all parts keyed and one that doesn't. Not when you need 64 opcodes for the keyed variants. 64:1 isn't somewhat balanced. Erm you need to redo your math. Even *if* we went with a full set of keyed and unkeyed parameters (and I don't see a reason to do so, though we certainly can) it's not 64. At worst it's 16 for three-arg ops, and that's for both the keyed int, keyed normal, and nonkeyed version. More information's available if anyone wants it, but this *is* the way we're going unless someone proves that it's suboptimal in the common case. Implementation details wanted ;-) I'll go thump the ops preprocessor, then. There's no reason to actually write all the code for it, as it can be autogenerated. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [RfC] vtable-dump
At 12:03 PM +0200 8/31/03, Leopold Toetsch wrote:
Benjamin Goldberg [EMAIL PROTECTED] wrote:
class freezer {
class thawer {
class cloner {
[ big snip ]
Do you expect that these are overridden by some languages using parrot?
I.e. that ponie tries to implement a freezer that writes output for
Storable?
Languages can't override these on a per-PMC class basis. At best they
can override the representation of frozen or thawed PMCs on a global
basis if, for example, someone really wanted output in XML or YAML
instead of a packed binary format.
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: [RfC] vtable-dump
At 6:37 PM +0200 8/29/03, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: On Fri, 29 Aug 2003, Leopold Toetsch wrote: I think, we need a general solution for freeze, dump and clone. As shown the latter is broken. That would be IMHO an iterator interface with a callback function taking and returning a void*. Right, what I want is for the system freeze/thaw routines to have a standard way to encode a variety of core types (ints, floats, strings), lists, and hashes, as well as a way to handle self-referential, circular, and shared data in the dumped PMC data. It's the only way to safely do this, since we can't count on all the different PMC classes to handle dumping arrays of arrays of references to the same end PMC properly. Which we have to if we want this to work right. The freeze(), dump() and clone() would be vtables which are called by the iterator. So this functions hould have the same signature. No iterator. When you call freeze on a PMC, that PMC is responsible for any sort of iteration that may have to be done. (Though there is the issue of blowing stack, which we'll have to address) Aren't you saying the opposite of above here? I want to be able to traverse from a given start point (being it the own interpreter or some PMC) as deeply down as there is something. You did say, that we don't recursively mark() because of recursion depth. clone(), dump(), freeze() all have these same issues (plus self-referntial structures). No, I'm just not being clear, so lets fix that. We don't need any special iterator, since we already have one--the DOD iterator, which is not only sufficient for our needs its likely the only thing that *can* have sufficient information to do the iteration. The -freeze or -thaw methods in the vtables are sufficient to freeze or thaw a PMC, but aren't going to be driving the freezing/thawing. The way things work is this: The freeze opcode takes a PMC as a parameter. The DOD tracing system is set up. The first PMC's freeze vtable function is called. When it returns (and we'll get to what it does later) the freeze op follows the chain and calls the next PMC's freeze, then the next, and so forth until it runs out of PMCs to freeze. This may, for simple PMCs, stop after the first--there may be no traversal at all. The freeze vtable method of a PMC is responsible for handing off parts of the PMC to the freezing and thawing encoding subsystem (which itself turns those parts into bits on the wire or characters in a file or string). The encoding subsystem should have a way to encode: Single values: STRING * (so we can save encoding, charset, and language) Integers Floats Binary data PMCs frozen bytecode Name/value pair (where the value is one of the above bits, or a set of name/value pairs, or a list of values) Lists of values (where the list can be a set of name/value pairs, or lists of values) Meta data--Internal structure stuff (flags, PMC class name, and whatnot) Not that complex -- this gets 95% of what any PMC class would need, and the remaining 5% can get shoved as binary data into a value thing. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Parrot - 100% Gnu.NET ?
At 8:06 PM +0200 9/1/03, Clemens Eisserer wrote: Hi there! I´m a java programmer and I´m not really experienced with perl. But I´ve searched a long time for a system like .NET that can´t be controlled by Microsoft through Patents. Do be aware that Microsoft may still hold patents that affect Parrot, as might IBM, HP, and whoever owns what used to be Bell Labs these days. Amongst others. Independent development is *no* protection against patents. Just ask the other guys who independently invented the telephone. (Remember them? No? Neither does anyone else :) I really like languages which are deployed compiled to bytecode, no problems with ABI-changes or with compiliers, once compiled link everywhere. Thats the reason why I linke Java really much, but there are some points, which are really showstoppers: *Java isnt free, *Swing is t slow to be useful. Erm--bytecode doesn I think that parrot could be the Gnu-version of .NET and could be a realy benefit for the whole opensource-world. No 20 runtimes need to be installed on a system - parrot would do the job better than each could alone (Because if many apps rely on parrot the JIT will be tuned by guys from IBM ;-) ). We thought the same about Java when it came out. Alas you'll find a half-dozen different JVMs installed on some systems. (Not, mind, that I want to do the same, but it is possible that it'll happen) But in my opinion parrot needs a more complete classpath that perl5 currently has. Hrm? I'm completely lost here. Library search functionality should be at least as good, if not better, than perl 5, and it's been my experience that perl 5's library search capabilities were better than any Java I've had the misfortunte to deal with. Might just have had some bad experiences. So, my question: Is it planned to include a complete classpath into parrot, including gui, network, db, sound functionality No. Networking yes, probably some DB functionality (at least DBI and xDBM style access, though unlikely no actual SQL DB drivers. Possibly flat file SQL access, we'll see), but no sound or GUI stuff. That's all very platform-specific, or really really ugly. Not to say that there won't be good cross-platform libraries--I'd be thrilled if there was a good Tk or wXwindows library for Parrot, but we're not going to ship with them. Please let me know what you think about the idea to include a complete classpath into parrot. If you want a complete *library* shipping with Parrot, you're going to be rather disappointed I'm afraid. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Parrot - 100% Gnu.NET ?
At 1:04 PM -0600 9/1/03, Luke Palmer wrote: Clemens Eisserer writes: Hi there! Ië¾m a java programmer Uh oh :-) and Ië¾m not really experienced with perl. [...] I think that parrot could be the Gnu-version of .NET and could be a realy benefit for the whole opensource-world. No 20 runtimes need to be installed on a system - parrot would do the job better than each could alone (Because if many apps rely on parrot the JIT will be tuned by guys from IBM ;-) ). But in my opinion parrot needs a more complete classpath that perl5 currently has. There is a big problem with that: it kinda precludes the whole community thing that made everyone love Perl 5. In particular, CPAN. The plan for Perl 6, at least, is to include almost nothing in the base distribution, so administrators are forced to install some stuff from CPAN order for Perl to be useful at all[1]. Not entirely true. There's going to be a decoupling between the core distribution, mainly parrot and its supporting stuff, and perl (and python, and ruby) but there'll be an all-in-one install for them all, so a trip to CPAN won't actually be necessary. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[PATCH] pdd7
This patch adds a new item to the must part of pdd7.
Pdd7's still missing:
A. Solving the problem of typedef struct a *a
Summarizng Leo's, Juergen's, and Brent's ideas,
I propose the following:
To have an underscore prepended to the stuct ParrotInterp.
To use ParrotInterp defined as typedef struct _ParrotInterp *ParrotInterp
only in embeding/extending code.
To use Interp defined as typedef struct _ParrotInterp { ... } Interp for
internals only.
To put this in the must part of pdd7
B. Naming structs.
I propose to use the style that Juergen's already been using in io.h for a
while.
In other words:
typedef stuct _pobj_t { ... } pobj_t
typedef struct _ParrotInterp *ParrotInterp
typedef struct _RunProfiler { ... } RunProfiler
That style would be out of troubles for any compiler.
That should be put in instead of structs should start with ...
C. #if defined/undefined vs 0/1 issue
I'm for ifdef/ifndef.
D. Function parametres in declarations.
At the monent, pdd7 says that we mustn't omit them in declarations.
I propose to omit them. The advantage is: We wouldn't run the risk to
having a keyword of C++ as a parameter, we would have nothing
to coordinate with parameters in definitions. The drawback is: We would
lose a lot of helpful information that we could have obtained while
exploring
the headers.
And as a matter-of-course, we should put it into the must part.
---
One of the criticisms of Perl 5 is that its source code is
impenetrable to newcomers, due to such things as inconsistent or
obscure variable naming conventions, lack of comments in the source
code, and so on. We don't intend to make the same mistake when writing
Parrot. -- Dave Mitchell (or maybe PDD7 itself, who knows)
pdd7.diff
Description: Binary data
Re: [PATCH] File Spec
Though I haven't been following this thread, it seems you're coming up with some File::Spec-like thing for Parrot? Exactly. I'd recommend looking at Ken Williams' excellent Path::Class module Surely, I will. So yes, you must distinguish between concatenating directories and files. You also must worry about volumes. Yeah .. I'll consider that. Tanks alot, Michael
imcc pasm generation
Should I expect: parrot -o foo.pasm foo.imc parrot foo.pasm args to work like: parrot foo.imc args ? (it doesn't appear to be de-mangling two different outer: labels, each of which is in it's own enclosing .sub) I'm trying to track down a bug where a .local var that's a PerlArray is getting replaced with a PerlInt at some point, and I'm trying to figure out why. Presuming I'm somehow stepping on that PMC register in a subroutine I'm calling, and thought looking at the pasm might help me track down where it was occurring. Better suggestions on how to debug .imc in general appreciated. =-) -- Will Coke Coledawill at coleda dot com
Re: imcc pasm generation
Will Coleda writes: Should I expect: parrot -o foo.pasm foo.imc parrot foo.pasm args to work like: parrot foo.imc args No. imcc doesn't emit local labels properly (as you seem to have discovered). ? (it doesn't appear to be de-mangling two different outer: labels, each of which is in it's own enclosing .sub) I'm trying to track down a bug where a .local var that's a PerlArray is getting replaced with a PerlInt at some point, and I'm trying to figure out why. Presuming I'm somehow stepping on that PMC register in a subroutine I'm calling, and thought looking at the pasm might help me track down where it was occurring. Sounds to me like you're confusing imcc's control flow analysis. Make sure you're conforming to the calling conventions and using savetop, etc. when you should (or using .pcc_*, which does this for you). Better suggestions on how to debug .imc in general appreciated. =-) print? parrot -t? Those have usually been sufficient for me. I've never been able to use pdb very well... The 'trace' opcode is pretty nice, too. Luke -- Will Coke Coledawill at coleda dot com
Re: The reason for scads of keyed variants
Dan Sugalski [EMAIL PROTECTED] wrote: At 11:17 PM +0200 9/1/03, Leopold Toetsch wrote: I don't see the point here especially why we would need a temporary PMC. If we have an array of packed ints, I just need a pointer to the element to work on it. This is very similar to the Ckey opcode I had in some of my proposals. We can't do that. There's insufficient information about the variables at compiletime to do anything other than call into the PMC to do the operation, so the internal representation's irrelevant. As far as parrot is concerned, it's a PMC and it doesn't know anything about the inside. We don't loose the abstraction with a special Ckey opcode. This Ckey opcode is the abstraction: get a pointer to an item in the aggregate (or prepare for a LHS). This is a vtable method of the aggregate. Splitting the 3-keyed operations down to simpler parts, that's it - no permutations. Not when you need 64 opcodes for the keyed variants. 64:1 isn't somewhat balanced. Erm you need to redo your math. So I'll try. We have 4 different addressing modes of one single keyed argument: set_p_k set_p_kc set_p_ki set_p_kic Now when we want to support 3-keyed operations there are 4*4*4 different opcodes of an all-3-keyed operation (+ some more if one isn't keyed). If we only have e.g. op_p_k_p_k_p_k we are missing the nice optimization of integer indices, we have to go through key_integer(), have to check for NULL keys and we need a full fledged (albeit) constant Key PMC per argument. Further: you have to implement type morphing, range checking BIG* promotion in the non-keyed variants and in the keyed vtable variants too. This is error-prone and a waste of memory. Anf finally, you are saying that these are most usefull for aggregate containing non-PMCs. What about @a[i] = @b[i] + 1; or the equivalent Perl6 vector operations[1]. More permutaions on opcodes to implement these? ... Even *if* we went with a full set of keyed and unkeyed parameters (and I don't see a reason to do so, though we certainly can) it's not 64. At worst it's 16 for three-arg ops, and that's for both the keyed int, keyed normal, and nonkeyed version. What I'm missing here? Implementation details wanted ;-) I'll go thump the ops preprocessor, then. There's no reason to actually write all the code for it, as it can be autogenerated. But please with a Configure switch to turn it off ;-) [1] I expect the most speed gain here, when we can optimize to hell. @a = @b + 1 // @a, @b are known to be arrays of packed int n = @b.elements() c = n / CHUNK_SIZE r = n % CHUNK_SIZE for i (0..c-1) ptra = @a.make_chunk(i) ptrb = @b.get_chunk(i) for (1..CHUNK_SIZE) *ptr++ = *ptrb++ + 1 // do rest ... @a.elements = @b.elements This would be a seqence of some specialized opcodes (enventually with a runtime check in front) and its fully JITtable. leo
Re: [RfC] vtable-dump
Dan Sugalski [EMAIL PROTECTED] wrote: At 6:37 PM +0200 8/29/03, Leopold Toetsch wrote: Aren't you saying the opposite of above here? I want to be able to traverse from a given start point (being it the own interpreter or some PMC) as deeply down as there is something. You did say, that we don't recursively mark() because of recursion depth. clone(), dump(), freeze() all have these same issues (plus self-referntial structures). No, I'm just not being clear, so lets fix that. We don't need any special iterator, since we already have one--the DOD iterator, which is not only sufficient for our needs its likely the only thing that *can* have sufficient information to do the iteration. While a general iterator would be very similar to the DOD iterator, we can't use it IMHO: - this prohibits DOD runs during clone/thaw, when we run out of free headers[1] - it would need an extra function pointer to call the actual vtable (mark, freeze, clone ...) - we have currently shortcuts for DOD marking (is_PMC_ptr ..) which don't play nicely with it probably and most important: - we must track duplicates (or restore pointers to these during thaw/clone) while marking (pobject_lives) just returns here. This would slow down DOD runs remarkably. ... The encoding subsystem should have a way to encode: Basically packfile extensions. Yep. [1] when we want to thaw/clone big structures, we should have some means to estimate the amount of needed headers. If we will not have enough, we do a DOD run before clone/thaw and then turn DOD off - it will not yield any more free headers anyway. This can avoid a couple of DOD runs that do just nothing except burning a lot of cycles and massive cache pollution. To achieve this, we might call aggregates.elements() first by means of the iterator again or with some depth restriction and returning, when we reach the free-header limit. leo
Re: imcc pasm generation
Will Coleda [EMAIL PROTECTED] wrote: Should I expect: [ Luke already did answer it, but some more hints ] parrot -o foo.pasm foo.imc parrot foo.pasm args to work like: parrot foo.imc args No. as mentioned. The most useful thing here probably is: $ parrot -o- foo.imc # | less to have a quick look at PASM output. This output is nor intended for running any more (label mangling and .pcc_sub handling are not implemented in PASM mode). I'm trying to track down a bug where a .local var that's a PerlArray is getting replaced with a PerlInt at some point, and I'm trying to figure out why. Presuming I'm somehow stepping on that PMC register in a subroutine I'm calling, and thought looking at the pasm might help me track down where it was occurring. Which calling conventions are you using? Better suggestions on how to debug .imc in general appreciated. =-) $ parrot --help-debug $ parrot -d18 foo.imc 21 | less # or $ parrot -d18 foo.imc foo.debug 21 does give you details of life analysis and register allocation. Also the register allocator isn't yet finished (or totally switched to Parrot Calling Conventions). If too many variables (16) are used across a function call, they are not preserved yet. Will Coke Coledawill at coleda leo
Re: The reason for scads of keyed variants
Leopold Toetsch writes: Dan Sugalski [EMAIL PROTECTED] wrote: At 11:17 PM +0200 9/1/03, Leopold Toetsch wrote: I don't see the point here especially why we would need a temporary PMC. If we have an array of packed ints, I just need a pointer to the element to work on it. This is very similar to the Ckey opcode I had in some of my proposals. We can't do that. There's insufficient information about the variables at compiletime to do anything other than call into the PMC to do the operation, so the internal representation's irrelevant. As far as parrot is concerned, it's a PMC and it doesn't know anything about the inside. We don't loose the abstraction with a special Ckey opcode. This Ckey opcode is the abstraction: get a pointer to an item in the aggregate (or prepare for a LHS). This is a vtable method of the aggregate. Splitting the 3-keyed operations down to simpler parts, that's it - no permutations. And I think you're saying that it'll be illegal to use this pointer PMC if the aggregate changes or anything like that, so the proxy can be as dumb and fast as possible... right? And that it wouldn't really need a header. So it wouldn't really be a PMC. But that's okay, I think. I'm wondering how the actual ops would look in this case though. foo a[x], b[y] turns into: key P0, a[x] key P1, b[y] foo P0, P1 How does foo know that it's working on fake PMCs? Or am I missing your vision (probably am)? [1] I expect the most speed gain here, when we can optimize to hell. @a = @b + 1 // @a, @b are known to be arrays of packed int FWIW, that does something entirely useless[1]: the equivalent of: @a = (1 + @b) x @a I think you meant to say: @a = @b + 1 n = @b.elements() c = n / CHUNK_SIZE r = n % CHUNK_SIZE for i (0..c-1) ptra = @a.make_chunk(i) ptrb = @b.get_chunk(i) for (1..CHUNK_SIZE) *ptr++ = *ptrb++ + 1 // do rest ... @a.elements = @b.elements This would be a seqence of some specialized opcodes (enventually with a runtime check in front) and its fully JITtable. That would be, um, very cool. PDL, eat your heart out! Luke [1] I'm saying that word with full awareness of its connotations on a list like this :-) leo
Re: The reason for scads of keyed variants
Luke Palmer [EMAIL PROTECTED] wrote: Leopold Toetsch writes: And I think you're saying that it'll be illegal to use this pointer PMC if the aggregate changes or anything like that, so the proxy can be as dumb and fast as possible... right? And that it wouldn't really need a header. So it wouldn't really be a PMC. But that's okay, I think. It would be a Key PMC probably with some extra flags. I didn't much think about details yet. Its basically that part inside current keyed set operations that gets at the value inside the aggregate. This part of code is currently repeated all over followed by an get- or set_type something operation basically. For aggregates holding basic types a C-pointer would be enough. I'm wondering how the actual ops would look in this case though. foo a[x], b[y] turns into: key P0, a[x] key P1, b[y] foo P0, P1 Yes. The first one would be Ckey_lhs or such. How does foo know that it's working on fake PMCs? Or am I missing your vision (probably am)? It doesn't matter for PMCs. The Ckey_lhs for Ca has to prepare a new PMC slot in the aggregate, P0 points at it, Cfoo sets the value then. I think you meant to say: @a = @b + 1 Oops, yes of course. n = @b.elements() c = n / CHUNK_SIZE r = n % CHUNK_SIZE for i (0..c-1) ptra = @a.make_chunk(i) ptrb = @b.get_chunk(i) for (1..CHUNK_SIZE) *ptr++ = *ptrb++ + 1 // do rest ... @a.elements = @b.elements This would be a seqence of some specialized opcodes (enventually with a runtime check in front) and its fully JITtable. That would be, um, very cool. PDL, eat your heart out! I dunno, which of the many acronyms of PDL you are applying here :-) But anyway such optimizations make vector ops fly at optimized C level speed. Fat multikeyed opcodes wont't do that. Luke leo
Re: [RfC] vtable-dump
On Tue, 2 Sep 2003, Leopold Toetsch wrote: and no, not that one inside DOD, that one doesn't handle duplicates. Yes, yes it *does* handle duplicates. Otherwise it'd get caught in infinite loops every time it came across a circular data structure. That's what the next pointer in the PObj header gets used for, amongst other things. Dan
Re: [RfC] vtable-dump
Dan Sugalski [EMAIL PROTECTED] wrote:
On Tue, 2 Sep 2003, Leopold Toetsch wrote:
and no, not that one inside DOD, that one doesn't handle duplicates.
Yes, yes it *does* handle duplicates. Otherwise it'd get caught in
infinite loops every time it came across a circular data structure. That's
what the next pointer in the PObj header gets used for, amongst other
things.
It does handle duplicates like so:
void pobject_lives(struct Parrot_Interp *interpreter, PObj *obj)
{
/* if object is live or on free list return */
if (PObj_is_live_or_free_TESTALL(obj)) {
return;
}
/* mark it live */
PObj_live_SET(obj);
So if it was mark()ed already we return. That's not possible for freeze,
thaw, dump, clone whatever. These must keep track of already visited
objects via an hash for freeze, dump, clone, and via an ID array for
thaw.
Dan
leo
Re: [RfC] vtable-dump
On Tue, 2 Sep 2003, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
On Tue, 2 Sep 2003, Leopold Toetsch wrote:
and no, not that one inside DOD, that one doesn't handle duplicates.
Yes, yes it *does* handle duplicates. Otherwise it'd get caught in
infinite loops every time it came across a circular data structure. That's
what the next pointer in the PObj header gets used for, amongst other
things.
It does handle duplicates like so:
void pobject_lives(struct Parrot_Interp *interpreter, PObj *obj)
{
/* if object is live or on free list return */
if (PObj_is_live_or_free_TESTALL(obj)) {
return;
}
/* mark it live */
PObj_live_SET(obj);
So if it was mark()ed already we return. That's not possible for freeze,
thaw, dump, clone whatever. These must keep track of already visited
objects via an hash for freeze, dump, clone, and via an ID array for
thaw.
No, this isn't necessary. What you need to do when freezing an already
frozen PMC is to emit a marker label that refers to the original version
of the PMC, or always emit the marker when a PMC freezes another PMC and
defer actual freezing of the PMC until the master freeze function walks
over the PMC to freeze it.
Dan
Re: [PATCH] pdd7
On Tue, Sep 02, 2003 at 06:39:23AM +0300, Vladimir Lipskiy wrote: C. #if defined/undefined vs 0/1 issue I'm for ifdef/ifndef. For complex combinations of conditionals you have to write things like #if defined(A) || defined (B) but I think that we can live with that. D. Function parametres in declarations. At the monent, pdd7 says that we mustn't omit them in declarations. I propose to omit them. The advantage is: We wouldn't run the risk to having a keyword of C++ as a parameter, we would have nothing to coordinate with parameters in definitions. The drawback is: We would lose a lot of helpful information that we could have obtained while exploring the headers. One solution is to put the parameters in /* comments */ in the declarations. Nicholas Clark
Re: [RfC] vtable-dump
Dan Sugalski [EMAIL PROTECTED] wrote: On Tue, 2 Sep 2003, Leopold Toetsch wrote: So if it was mark()ed already we return. That's not possible for freeze, thaw, dump, clone whatever. These must keep track of already visited objects via an hash for freeze, dump, clone, and via an ID array for thaw. No, this isn't necessary. What you need to do when freezing an already frozen PMC is to emit a marker label that refers to the original version of the PMC, So I have to do a lookup to get the marker, or... ... or always emit the marker when a PMC freezes another PMC and defer actual freezing of the PMC until the master freeze function walks over the PMC to freeze it. on first freeze generate a maker (store it where in the PMC?) and then... When I defer freezing of the aggregate the thawing doesn't work. When everything gets defered, you have to walk the whole defered list again, for simple types too, which already would have been done. Then in another run, the marker has to get cleared. *If* that works it still adds extra complexity to DOD. Dan leo
Re: [RfC] vtable-dump
On Tue, 2 Sep 2003, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: On Tue, 2 Sep 2003, Leopold Toetsch wrote: So if it was mark()ed already we return. That's not possible for freeze, thaw, dump, clone whatever. These must keep track of already visited objects via an hash for freeze, dump, clone, and via an ID array for thaw. No, this isn't necessary. What you need to do when freezing an already frozen PMC is to emit a marker label that refers to the original version of the PMC, So I have to do a lookup to get the marker, or... Or nothing. Freezing a PMC that refers to one or more PMCs will have to handle this. ... or always emit the marker when a PMC freezes another PMC and defer actual freezing of the PMC until the master freeze function walks over the PMC to freeze it. on first freeze generate a maker (store it where in the PMC?) and then... When I defer freezing of the aggregate the thawing doesn't work. When everything gets defered, you have to walk the whole defered list again, for simple types too, which already would have been done. Then in another run, the marker has to get cleared. Nope. First off, the freeze and thaw code *must* deal with potentially self-referential or circular data structures. They're depressingly common, and to not be able to handle something as simple as: $foo = \$foo; freeze($foo); would be a big problem. As would this: $foo[0] = \$bar; $foo[1] = \$bar; freeze(@foo); generating a structure that, when reconstituted, had elements 0 and 1 pointing to different PMCs. So with that in mind, handling labels and deferred or already-instantiated PMCs is a necessity. Doing the walk is *also* easy. You clear the next PMC pointer, just as with a normal DOD run setup. call the DOD mark on the inital PMC, and call its freeze routine. Inside the freeze for the PMC, it calls mark on any PMCs it needs frozen, which will then go on the list if they've not already been frozen. A marker for that PMC, probably based on the PMC header address, goes in the frozen data structure. When the initial freeze routine exits, the freeze code just follows the next for DOD pointer chain, calling freeze on each of those PMCs, until it runs off the end of the chain, just as the DOD does. Now, granted, we won't use the DOD's intimate knowledge of base array/hash types, rather deferring to their freeze routines, but that's fine and as it should be. Reconstituting these things may be somewhat problematic, but there's not much for it--reconstituting circular data structures that require some sort of active setup is problematic in general. *If* that works it still adds extra complexity to DOD. It doesn't add anything to the DOD. Worst case it turns out that disabling a DOD sweep during a freeze is untenable, which is possible. In that case we'll need an alternate pointer chain. Dan
[CVS ci] Factoring out the io layer iteration to helper functions.
Hello, Now I use my brand new commit access: Non-Terminal IO-Layers often call down to the lower-lying layers. Until now this was done in a while-loop reimplemented in every upper layer (At the moment there is only one io_buf but there will be more). This commit introduces new io_system private helper-functions which do the iteration of the layer-stack. PIO_xxx_down() walks the layersstack starting at the passed in layer, and calls the first implementation of the API it finds. All manual versions of the iteration are replaced by this helper functions. This commit is internal to the PIO subsystem, it should have no effect on the rest of parrot. bye boe -- Juergen Boemmels[EMAIL PROTECTED] Fachbereich Physik Tel: ++49-(0)631-205-2817 Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906 PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Re: [RfC] vtable-dump
Dan Sugalski [EMAIL PROTECTED] wrote: Doing the walk is *also* easy. You clear the next PMC pointer, just as with a normal DOD run setup. call the DOD mark on the inital PMC there is no mark() for a plain PMC scalar (and no next pointer inside the PMC). If the PMC has a mark routine this calls pobject_lives() (setting the live flag) and puts complex PMCs but *not all* on the next for GC pointer. Some get their live flag directly set. Using the DOD functionality doesn't match freeze, thaw, dump at all and interferes with DOD runs. Please have a look at dod.c Dan leo
Re: [RfC] vtable-dump
On Tue, 2 Sep 2003, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: Doing the walk is *also* easy. You clear the next PMC pointer, just as with a normal DOD run setup. call the DOD mark on the inital PMC there is no mark() for a plain PMC scalar (and no next pointer inside the PMC). If the PMC has a mark routine this calls pobject_lives() (setting the live flag) and puts complex PMCs but *not all* on the next for GC pointer. Some get their live flag directly set. Every PMC should have a next_for_GC pointer. You moved it to the ext structure, but it's there, and they all ought to have one. Any PMC that gets frozen *will* have one, as it needs to have it for traversal to work properly. Using the DOD functionality doesn't match freeze, thaw, dump at all and interferes with DOD runs. Oh, nonsense, it doesn't at all interfere with things. I designed it with this as one of the applications for the DOD system. It should also work reasonably well for destruction ordering. If it's been changed in a way that makes this untenable, it needs to be fixed so it does. Dan
Re: [RfC] vtable-dump
Dan Sugalski [EMAIL PROTECTED] wrote: Every PMC should have a next_for_GC pointer. You moved it to the ext structure, ... I moved it there for a good reason: speed. The smaller a PMC the faster is the interpreter. ... but it's there, and they all ought to have one. Any PMC that gets frozen *will* have one, as it needs to have it for traversal to work properly. Ok. Its a macro and back again in a second *if* needed. Using the DOD functionality doesn't match freeze, thaw, dump at all and interferes with DOD runs. Oh, nonsense, it doesn't at all interfere with things. Calling mark sets the live flag on PMC headers. When you use mark() you have to reset the whole arena after a single clone. I expect a lot of clone()s to be emitted by the HLL. If we don't use mark() we are almost at my proposal: have an extra traverse() vtable, that gets a vtable pointer doing freeze, thaw, clone, or dump. If you want to have a general traverse() for DOD too (currents mark?) then you have to pass in a function pointer - or put each and every item on the next_for_GC list. When you have a PerlArray containing 100.000 plain PerlInts, you have your linked list with 100.001 entries or one entry. You have polluted caches or not - that's it (I'm speaking of DOD here). ... I designed it with this as one of the applications for the DOD system. It should also work reasonably well for destruction ordering. If it's been changed in a way that makes this untenable, it needs to be fixed so it does. Or the design ;-) And I still don't see, how you will handle duplicate lookup of self-referential structures for freeze and thaw with a linked list of items alone. Dan leo
Re: Parrot - 100% Gnu.NET ?
Clemens, classpath I guess the proper term would be class library. The path is only where you look for the libraries :). It doesn't seem to be the Perl way to limit yourself to one option only (There's more than one way to do it). Of course we wouldn't want five different implementations of Unicode, and it makes sense to ship _one_. However, people might want to use different GUIs -- e.g. wxWindows, TK, native Windows GUI, Aqua, ... Basic network classes, on the other hand, might be something that might be shipped with Parrot. Sound is a whole different beast -- implementations vary wildly across systems, and I'm not sure whether it is possible to have a high-performance cross-platform implementation that satisifes 90% of users. On the other hand, I don't think we only have the choice between shipping all libraries like Java and having a complicated install system (for the average GUI-loving end user) like CPAN. There's a couple of middle options: For bytecode based packages: - Parrot bytecode executables might be packages that contain the necessary libraries in bytecode format (e.g. wxWindows). - Installers might include libraries (in bytecode) and install them if needed (install = simple copy) For binary (platform-dependant) packages: Usually, people just ship these statically linked against those libs that can't be typically expected to be installed on the system. So I guess for Parrot apps distributed in binary, there's not much of a problem. For apps shipped as bytecode, it still needs to be discussed what is going to be provided: - Preferably a small package ( 5 - 10 MB) that lets people use Parrot apps quickly. - A huge package complete with Perl/Python/PHP/Befunge/hq9+/... support so that everybody will have 95% of everything they are ever gonna need - Or both? Liebe Grüße, Christian (since you started the German greetings thingie ;-)) -- [EMAIL PROTECTED] - http://www.web42.com/crenz/ - http://www.web42.com/ Surely what a man does when he is taken off his guard is the best evidence for what sort of man he is. -- C.S. Lewis, Mere Christianity
Re: [PATCH] File Spec
Though I haven't been following this thread, it seems you're coming up with some File::Spec-like thing for Parrot? I'd recommend looking at Ken Williams' excellent Path::Class module which gives you actual file and directory objects. EXTREMELY useful when you're in an ultra-cross platform environment such as Parrot. I wish I had them for MakeMaker instead of fucking around with File::Spec. Consider using Path::Class for inspiration rather than File::Spec. On Mon, Sep 01, 2003 at 02:38:36PM +0300, Vladimir Lipskiy wrote: Leo wrote: Albeit File::Spec is using catfile and catdir, I don't like the function names (cat file is on *nix what type file is on Win*). Maybe concat_pathname and concat_filename is better. Yes, indeed. I'm for having concat_pathname only since this patch or the File::Spec module makes no difference when concatenates paths and files (though I can be mistaken on account of VMS, Dan? (~:). So catdir and catfile give the same result. Morever, catfile is sort of a wrapper around catdir and does nothing smarter than just calling catdir on all platforms. On VMS catfile and catdir do very different things because VMS filepath syntax distinguishs between files and directories explicitly. Unix: /dir1/dir2/dir3 /dir1/dir2/file Windows: \dir1\dir2\dir3 \dir1\dir2\file VMS: [dir1.dir2.dir3] [dir1.dir2]file So yes, you must distinguish between concatenating directories and files. You also must worry about volumes. Unix: No user visible concept of a volume Windows: VOLUME:\dir1\dir2\file VMS: VOLUME:[dir1.dir2]file -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ Operation Thrusting Peach
Fwd: Re: Parrot Z-machine
Darn. I was all set to write an amusing email about how I wasn't offended that noone responded to my email, when someone went and responded to my mail. OTOH, in the meantime I got my fifteen bytes of fame in the P6 summary, plus the opportunity to play this week's Perl Golf instead of mucking about with Z-code and PASM. [I'd better apologize up front for verbosity. Hard to believe I play Perl Golf, really.] --- Nicholas Clark [EMAIL PROTECTED] wrote: On Thu, Aug 28, 2003 at 06:17:07AM -0700, Amir Karger wrote: Hi. Hugely newbie at Parroting, but think it's the coolest. Good stuff. I hope it stays that with the inevitable setbacks and annoyances that will come while gaining experience. Strange how almost no language (or software project in general) remains perfect, isn't it? I still think Befunge-93 is close to perfect (simple enough to learn quickly, but hilariously crooked), but they had to go add all those silly opcodes (like reading from a file. Whatever for, when you can store data in your program?!) for Befunge-98. - Is it not being ported because of a lack of tuits, or because it's extremely hard? I think it's party because of tuits, and party because to be done properly it requires a couple of big features to be added to parrot, notably 1: dynamic opcode loading 2: dynamic bytecode conversion (This is the point where someone tells me that dynamic opcode loading now works) I would tell you, but I wouldn't even know if I was lying or not. This is the point where you tell me that I can work on pieces of the problem without having all this working, and when I've finished a large part of the job, one of the core Parroters will be inspired to hack up #s 1 and 2 overnight while at some YAPC instead of sleeping or drinking beer. We'd need dynamic opcode loading because we don't want to have the Z-machine specific opcodes compiled into every parrot (or every other specialist set of opcodes) Surely the majority of Parrot coders will want to use Z-machine opcodes?! We'd want dynamic bytecode conversion because we want parrot to be able to directly load Z-code files, rather than having to first run an external program to convert them. Ah. I thought this was true, when I saw Dan's quote that Z-code would run natively. However, I wanted it not to be true because it sounded scary. I kind of figured I would need to implement all the Z-machine opcodes in order to get this to work, so you'd be calling Z opcodes instead of parrot ones. But I'm still confused about how you deal with the Z-code Header, which is a bunch of data, not opcodes, and which doesn't follow (by a longshot) the Parrot bytecode format specification. And Dan pointed out that Z-code has 16-bit words, not Parrot's 32. I guess this is what you mean by dynamic bytecode conversion. Only I don't have the first idea how this is supposed to happen. (Are there docs about it I'm supposed to be reading?) Is this different from running a Perl script to put the Z-code header into a Parrot data object and create a Parrot header? However, I don't think that we'd need them in place to begin working on a Z-code port. (We'd just have to arrange to link in any specialist Z-code ops for a while, and to convert Z-code before loading it) Aha! So now all you need to do is tell me how to do *that*. RTFM's welcomed, as long as I don't have to R ALL of TFMs. Would it begin by doing a non-native port that does use a Perl translator? - A Perl 6 Summary from last year claimed Josh Wilmes was going to work on it. Does anyone know if he is and, if so, how far he's gotten? I have no idea This is where Josh jumps in, sends me 90%-finished code and says he'll give me all the credit if I write up the documentation. - Whether or not it's extremely hard, would it be useful to have some of the easy parts done by a newbie who can hack assembly but not well enough to put into the parrot core? In that case, which would be the easy parts? I've no idea. Well, then, we make a great pair! How familiar are you with Z-code? Um, somewhat. The Z-machine has been ported to PalmOS, but save files aren't compatible. I started working on a Perl script to convert them, but got distracted by a neat Perl Golf competition. In the meantime, though, I read the Z-machine spec and played with some headers and, most importantly, subscribed to the Z-machine mailing list where I can ask lots of questions. To be honest, given the shape (as it were) of my tuits and my knowledge of Z and Parrot, I'm more hoping to get the ball rolling on this and then have some experts do the hard stuff (Some versions of the Z-machine support sound, graphics) than to create a complete implementation. But we'll see. It doesn't look like Parrot will be finished next week either. About all that I know (and I may be wrong) is that it fits in a virtual machine with 128K total memory, I believe later versions (post-Infocom) allow up to a whopping
Re: Parrot Z-machine
Darn. I was all set to write an amusing email about how I wasn't offended that noone responded to my email, when someone went and responded to my mail. OTOH, in the meantime I got my fifteen bytes of fame in the P6 summary, plus the opportunity to play this week's Perl Golf instead of mucking about with Z-code and PASM. [I'd better apologize up front for verbosity. Hard to believe I play Perl Golf, really.] [Also, apologies if this is a repost. I think I sent this only to Nicholas.] --- Nicholas Clark [EMAIL PROTECTED] wrote: On Thu, Aug 28, 2003 at 06:17:07AM -0700, Amir Karger wrote: Hi. Hugely newbie at Parroting, but think it's the coolest. Good stuff. I hope it stays that with the inevitable setbacks and annoyances that will come while gaining experience. Strange how almost no language (or software project in general) remains perfect, isn't it? I still think Befunge-93 is close to perfect (simple enough to learn quickly, but hilariously crooked), but they had to go add all those silly opcodes (like reading from a file. Whatever for, when you can store data in your program?!) for Befunge-98. - Is it not being ported because of a lack of tuits, or because it's extremely hard? I think it's party because of tuits, and party because to be done properly it requires a couple of big features to be added to parrot, notably 1: dynamic opcode loading 2: dynamic bytecode conversion (This is the point where someone tells me that dynamic opcode loading now works) I would tell you, but I wouldn't even know if I was lying or not. This is the point where you tell me that I can work on pieces of the problem without having all this working, and when I've finished a large part of the job, one of the core Parroters will be inspired to hack up #s 1 and 2 overnight while at some YAPC instead of sleeping or drinking beer. We'd need dynamic opcode loading because we don't want to have the Z-machine specific opcodes compiled into every parrot (or every other specialist set of opcodes) Surely the majority of Parrot coders will want to use Z-machine opcodes?! We'd want dynamic bytecode conversion because we want parrot to be able to directly load Z-code files, rather than having to first run an external program to convert them. Ah. I thought this was true, when I saw Dan's quote that Z-code would run natively. However, I wanted it not to be true because it sounded scary. I kind of figured I would need to implement all the Z-machine opcodes in order to get this to work, so you'd be calling Z opcodes instead of parrot ones. But I'm still confused about how you deal with the Z-code Header, which is a bunch of data, not opcodes, and which doesn't follow (by a longshot) the Parrot bytecode format specification. And Dan pointed out that Z-code has 16-bit words, not Parrot's 32. I guess this is what you mean by dynamic bytecode conversion. Only I don't have the first idea how this is supposed to happen. (Are there docs about it I'm supposed to be reading?) Is this different from running a Perl script to put the Z-code header into a Parrot data object and create a Parrot header? However, I don't think that we'd need them in place to begin working on a Z-code port. (We'd just have to arrange to link in any specialist Z-code ops for a while, and to convert Z-code before loading it) Aha! So now all you need to do is tell me how to do *that*. RTFM's welcomed, as long as I don't have to R ALL of TFMs. Would it begin by doing a non-native port that does use a Perl translator? - A Perl 6 Summary from last year claimed Josh Wilmes was going to work on it. Does anyone know if he is and, if so, how far he's gotten? I have no idea This is where Josh jumps in, sends me 90%-finished code and says he'll give me all the credit if I write up the documentation. - Whether or not it's extremely hard, would it be useful to have some of the easy parts done by a newbie who can hack assembly but not well enough to put into the parrot core? In that case, which would be the easy parts? I've no idea. Well, then, we make a great pair! How familiar are you with Z-code? Um, somewhat. The Z-machine has been ported to PalmOS, but save files aren't compatible. I started working on a Perl script to convert them, but got distracted by a neat Perl Golf competition. In the meantime, though, I read the Z-machine spec and played with some headers and, most importantly, subscribed to the Z-machine mailing list where I can ask lots of questions. To be honest, given the shape (as it were) of my tuits and my knowledge of Z and Parrot, I'm more hoping to get the ball rolling on this and then have some experts do the hard stuff (Some versions of the Z-machine support sound, graphics) than to create a complete implementation. But we'll see. It doesn't look like Parrot will be finished next week either. About all that I know (and I may be wrong) is that it fits in a virtual machine with 128K
Re: Parrot Z-machine
A couple more questions on the coding front: (1) Even though it's supposed to be native Parrot support, I'm still allowed to write in PIR, right? Because that'll be translated to pasm and thereby be native. (2) WinFrotz, one of the popular C Z-machine runtimes, is GPL. If I steal code or ideas from there, does Parrot or this piece of it have to be GPL only instead of GPL/Artistic? I am happily ignorant about licensing issues. -Amir __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
[PATCH] Add explicit close to t/syn/file.t tests
I don't know why this didn't show up anywhere else, but on Solaris 8 with
perl5.00503, the imcc/t/syn/file.t tests that tried to load temp.pbc were
all failing. The reason turned out to be that the temp.imc files hadn't
been flushed to disk yet. Explicitly closing the files ensures
that they are written before we try to compile them.
diff -r -u parrot-cvs/languages/imcc/t/syn/file.t
parrot-andy/languages/imcc/t/syn/file.t
--- parrot-cvs/languages/imcc/t/syn/file.t Thu Aug 21 13:47:27 2003
+++ parrot-andy/languages/imcc/t/syn/file.t Tue Sep 2 15:47:21 2003
@@ -139,6 +139,7 @@
end
.end
ENDF
+close FOO;
# compile it
system(.$PConfig{slash}imcc$PConfig{exe} -o temp.pbc temp.imc);
@@ -171,6 +172,7 @@
end
.end
ENDF
+close FOO;
# compile it
system(.$PConfig{slash}imcc$PConfig{exe} -o temp.pbc temp.imc);
@@ -208,6 +210,7 @@
end
.end
ENDF
+close FOO;
# compile it
system(.$PConfig{slash}imcc$PConfig{exe} -o temp.pbc temp.imc);
@@ -240,6 +243,7 @@
end
.end
ENDF
+close FOO;
# compile it
output_is('CODE', 'OUT', call sub in external imc, return);
@@ -272,6 +276,7 @@
end
.end
ENDF
+close FOO;
# compile it
SKIP:
@@ -356,6 +361,7 @@
end
.end
ENDF
+close FOO;
# compile it
system(.$PConfig{slash}imcc$PConfig{exe} -o temp.pbc temp.imc);
--
Andy Dougherty [EMAIL PROTECTED]
Re: [PATCH] pdd7
C. #if defined/undefined vs 0/1 issue I'm for ifdef/ifndef. For complex combinations of conditionals you have to write things like #if defined(A) || defined (B) Sure. But I didn't precisely mean ifdef/ifndef. I was and am for defined/undefined and used ifdef/ifndef there just as a shortcut. I think I should clarify the problem. The problem relates to the Configure script. Before running the script, we could pass some configure options like --jitcapable=0 or --cgoto=1. Plus we have some places in the script where we define compiler flags like -DHAVE_COMPUTED_GOTO. And finally we set up some #defines in config_h.in and feature_in.h like #define PARROT_HAS_MEMALIGN However, as to source code, you have nothing to do to find disagreements in there, like in interpreter.c, line 27: #ifdef HAVE_COMPUTED_GOTO # include parrot/oplib/core_ops_cg.h # include parrot/oplib/core_ops_cgp.h #endif in the same file, line 354 #if HAVE_COMPUTED_GOTO oplib_init_f init_func = PARROT_CORE_CGP_OPLIB_INIT; #else /* HAVE_COMPUTED_GOTO */ oplib_init_f init_func = PARROT_CORE_OPLIB_INIT; #endif /* HAVE_COMPUTED_GOTO */ We aren't consistent and have got to fix that, anyhow, though we don't have any design decision on that. We shall replace -DHAS_JIT, -DHAVE_COMPUTED_GOTO, -DGC_IS_MALLOC with something, but with what? Should it be either #define PARROT_HAS_COMPUTED_GOTO or #define PARROT_HAS_COMPUTED_GOTO 0/1 ? And so on. There is a pile of work. I don't argue that we have to make those alternations after P 010's been released, yeah it's so. But at first we should decide what we replace the disagreements with. D. Function parametres in declarations. At the monent, pdd7 says that we mustn't omit them in declarations. I propose to omit them. The advantage is: We wouldn't run the risk to having a keyword of C++ as a parameter, we would have nothing to coordinate with parameters in definitions. The drawback is: We would lose a lot of helpful information that we could have obtained while exploring the headers. One solution is to put the parameters in /* comments */ in the declarations. So you propose the following void internal_exception(int /* exitcode */, const char * /* format */, ...); Hmm. I don't mind but still there are some shortcomings: a) types like a pointer to something are mixing up with comments. b) It could punch a newbie in the stomach; so we would be obliged to go and to add an expalanation into each header. What's the other think? Could I ask ya, Nicholas, a question that's out of place? I ain't lurking about the p5p doings, so I am knida out of info, anyway, has Ilya Zakharevich come back?
Re: [RfC] vtable-dump
Leopold Toetsch wrote:
[snip]
[1] when we want to thaw/clone big structures, we should have some means
to estimate the amount of needed headers. If we will not have enough, we
do a DOD run before clone/thaw and then turn DOD off - it will not yield
any more free headers anyway. This can avoid a couple of DOD runs that
do just nothing except burning a lot of cycles and massive cache
pollution.
To achieve this, we might call aggregates.elements() first by means of
the iterator again or with some depth restriction and returning, when we
reach the free-header limit.
Even with a depth restriction, a recursive estimate can produce
misleading results due to circular references. Only actually walking
the structure can get the number right. However, walking the structure
*twice* would be silly. So, begin with an estimate of unknown
(serialize an integer -1), and then, after the whole thing has been
frozen, we seek backwards (if that's possible) and replace that
unknown with the actual number of pmcs that were serialized.
--
$a=24;split//,240513;s/\B/ = /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print [EMAIL PROTECTED]
]\n;((6=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))redo;}
Re: Parrot Z-machine
Amir Karger [EMAIL PROTECTED] wrote: I got my fifteen bytes of fame in the P6 summary ... Geewhillikins ... But you can always get more: Convert it into Unicode (~: _VL_ But how can we do it if we don't know what it is? Why, blame it all, we've GOT to do it. Don't I tell you it's in the books? Do you want to go to doing different from what's in the books, and get things all muddled up?
PIO Questions.
I'm looking for, but not finding, information regarding the character
type and encoding on parrot io objects.
As an example of why... I found this in io.ops :
op write(in PMC) {
PMC *p = $1;
STRING *s = (VTABLE_get_string(interpreter, p));
if (s) {
PIO_write(interpreter, PIO_STDOUT(interpreter),
s-strstart, s-bufused);
}
goto NEXT();
}
Surely, blinding writing the bytes that are in a string, without
checking that the string's encoding and type match that of the stream,
is wrong.
I would expect something like:
op write(in PMC) {
PMC *p = $1;
STRING *s = VTABLE_get_string(interpreter, p);
if( s ) {
PMC *o = PIO_STDOUT(interpreter);
string_transcode(interpreter, s,
PIO_encoding(interpreter, o),
PIO_chartype(interpreter, o), s);
PIO_write(interpreter, o, s-strstart, s-bufused);
}
goto NEXT();
}
Except that I can't seem to find any PIO_encoding and PIO_chartype
functions.
#
Actually... I think that the op print(in PMC) and write(in PMC) are
designed wrong. Instead of asking for a string, and printing that
string, they should call a print_self and/or write_self vtable method on
the PMC, passing in the PIO object. In turn, the default
implementations of those methods should print or write the results of
DYNSELF.get_string() to that PIO object.
This way, a PMC whose string representation is very large doesn't need
to serialize itself to a string before it can be printed -- it can print
itself directly to the PIO object, thus avoiding allocating memory for
that big string, and probably lots of copying.
To avoid loss of synchronization between the get_string form of a pmc
and the print_self/write_self form of a pmc, one should be able to
define a string's get_string as creating a new stringstream PIO object,
printing itself to that stream, and returning the corresponding string.
However, there doesn't (yet) seem to be a stringstream layer. When do
we expect to have one?
#
PIO_putps converts to a cstring, then calls PIO_puts.
Since PIO_puts doesn't take a length, obviously it must be determining
the length of the string based on the presence of a nul character in
it. Thus, we cannot use PIO_puts to print binary data. This means that
PIO_write must be used. Since there's no op write(in STR), the only way
to do it from parrot is to create a PerlString, store our Sreg into it,
then call write. Blech.
#
Shouldn't everything in io_unix.c (except for pio_unix_layer) be
static? This isn't just about namespace pollution -- it slows down
linking and dynamic loading. I think.
Hmm, the same applies to the other io_foo.c files.
#
Why does PIO_unix_seek clear errno before calling lseek?
#
Why does PIO_unix_tell have a temp variable pos?
--
$a=24;split//,240513;s/\B/ = /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print [EMAIL PROTECTED]
]\n;((6=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))redo;}
Re: Parrot Z-machine
On Tuesday 02 September 2003 13:09, Amir Karger wrote: A couple more questions on the coding front: (1) Even though it's supposed to be native Parrot support, I'm still allowed to write in PIR, right? Because that'll be translated to pasm and thereby be native. (2) WinFrotz, one of the popular C Z-machine runtimes, is GPL. If I steal code or ideas from there, does Parrot or this piece of it have to be GPL only instead of GPL/Artistic? I am happily ignorant about licensing issues. So I take it the goal is to to teach parrot to understand z-machine opcodes, rather than simply writing a z-machine interpreter that runs on parrot, or rewriting inform to compile to parrot? I'm sure it's much harder that way (especially since I'm sure someone's going to follow the dotGnu lead and implement C for parrot before we're all said and done and you could just recompile one of the more portable z-machine emulators!), but you'd certainly get mad geek respect. And since there's already a scheme implementation for z-code, you'd kill two birds with one - er, parrot. Zellyn
Re: Parrot Z-machine
Zellyn Hunter writes: On Tuesday 02 September 2003 13:09, Amir Karger wrote: A couple more questions on the coding front: (1) Even though it's supposed to be native Parrot support, I'm still allowed to write in PIR, right? Because that'll be translated to pasm and thereby be native. (2) WinFrotz, one of the popular C Z-machine runtimes, is GPL. If I steal code or ideas from there, does Parrot or this piece of it have to be GPL only instead of GPL/Artistic? I am happily ignorant about licensing issues. So I take it the goal is to to teach parrot to understand z-machine opcodes, rather than simply writing a z-machine interpreter that runs on parrot, or rewriting inform to compile to parrot? I doubt it. I think a z-machine to parrot converter, making some of the more complex ops sub calls or something, would be best. We need to work with the z-machine bytecode directly, though, because many games are distributed without source. And perhaps, once dynamic opcode loading is ready, those sub calls can turn into real ops for speed. But that's not important at the moment: the important thing (well, as important as z-machine can be :-) is to get the translator working. Luke I'm sure it's much harder that way (especially since I'm sure someone's going to follow the dotGnu lead and implement C for parrot before we're all said and done and you could just recompile one of the more portable z-machine emulators!), but you'd certainly get mad geek respect. And since there's already a scheme implementation for z-code, you'd kill two birds with one - er, parrot. Zellyn
Re: [RfC] vtable-dump
At 8:38 PM +0200 9/2/03, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: Every PMC should have a next_for_GC pointer. You moved it to the ext structure, ... I moved it there for a good reason: speed. The smaller a PMC the faster is the interpreter. Right, and this part is only needed by the DOD sweep, the freeze/thaw code, and the destruction ordering code, so since it's in the ext struct it won't get in the way for normal usage. ... but it's there, and they all ought to have one. Any PMC that gets frozen *will* have one, as it needs to have it for traversal to work properly. Ok. Its a macro and back again in a second *if* needed. That's easy, then, as it is. :) Besides, from looking at pobj.h, it's already there, so I'm not sure what we'd need to do. Perhaps I need to resync. Using the DOD functionality doesn't match freeze, thaw, dump at all and interferes with DOD runs. Oh, nonsense, it doesn't at all interfere with things. Calling mark sets the live flag on PMC headers. When you use mark() you have to reset the whole arena after a single clone. I expect a lot of clone()s to be emitted by the HLL. I expect very few clones to be emitted. Past history indicates that it's an unusual operation. Besides, there's nothing wrong with setting the live flag, since the PMCs *are* alive. We don't care about the live flag for this, what we care is that the PMC is put on the traversal list. If we don't use mark() we are almost at my proposal: have an extra traverse() vtable, that gets a vtable pointer doing freeze, thaw, clone, or dump. If you want to have a general traverse() for DOD too (currents mark?) then you have to pass in a function pointer - or put each and every item on the next_for_GC list. When you have a PerlArray containing 100.000 plain PerlInts, you have your linked list with 100.001 entries or one entry. You have polluted caches or not - that's it (I'm speaking of DOD here). So you shortcut in the normal course of DOD? I suppose--I presume you've benchmarked to see if testing all the flags of the contained PMCs when marking the container is faster than just throwing them on the list and checking them when you get to them? I can see that being the case in some cases, but I'm concerned that it'll consume more memory and take more time in some reasonably common cases. ... I designed it with this as one of the applications for the DOD system. It should also work reasonably well for destruction ordering. If it's been changed in a way that makes this untenable, it needs to be fixed so it does. Or the design ;-) Yep. In this case, though, design flaws turn out not to be the case. :-P And I still don't see, how you will handle duplicate lookup of self-referential structures for freeze and thaw with a linked list of items alone. The same way the DOD sweep handles it, unless you've changed things beyond recognition. The way it used to work is that when you marked a PMC as live, it got put on the end of the chain unless the PMC's next pointer field is non-NULL, in which case it's already been put on the list, and nothing happens. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Parrot - 100% Gnu.NET ?
At 8:53 PM +0200 9/1/03, Christian Renz wrote: Clemens, classpath I guess the proper term would be class library. The path is only where you look for the libraries :). It doesn't seem to be the Perl way to limit yourself to one option only (There's more than one way to do it). I'd worry less about the Perl way to do it, since we're more concerned with the Parrot way to do it, and that's when we have one way that's good enough we ship it, so people don't have to re-invent the bikeshed, or choose from a half-dozen identically shaped but different colored sheds. Which means that we ship a core that's as small as feasable, and an add-on pack (which we'll likely also ship with the core for an all-in-one install) with the best things we can find that are cross-platform enough to be useful. That means we'll shoot for a good set of networking modules for the various RFC protocols, a generic SQL database front-end, an (ick :) XML parser, a variety of cross-platform tools (filename conversions and whatnot), a set of xDBM interface modules, and some other stuff. Don't forget there is an issue of us wanting to be a good core for more than just perl. The Python parrot package would have Python's standard module set, the Ruby package would have ruby's modules, and the Perl package would have the perl modules. There's a fair amount of overlap and I expect people both want their modules and *don't* want two or three alternate versions of the same modules installed. I could be wrong, of course. GUI stuff's a massive pain, as you either get cross-platform which is ugly and awkward everywhere, or platform-specfic and useless anywhere but on the platform in question. And I'm pretty sure that, no matter *how* Insanely Great the OS X Cocoa interface modules are, they're not going to do MSWin folks much good. :) As for sound... Yeesh. There's a swamp I don't have enough castles for. However, since we have a good native interface it should mean that many modules that now require a compiler for can be done entirely in parrot bytecode, which should mean that it's far easier for people to install and reduce a lot of the pain. Also we've a fair amount of experience in the perl world with network module installation systems--we know some things that do work, and some things that don't, and I expect we should be able to leverage that to make a system better than what we have now. (Which, honestly, is pretty darned good, especially given the limited information it has available to work with) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
