Re: Traits: to renew OO inheritance in a hacker style discussion
Larry Wall wrote: Yes, that's a very good paper, which is why Perl 6 now has something called Roles, which are intended to degenerate either to Traits or Interfaces. My take on it is that Roles' most important, er, role will be to abstract out the decision to compose or delegate. But we'd like them to function as interfaces when the Role is "abstract", and we'd like them to function as Traits when you don't happen to specify any state attributes. But for hiding the delegation decision, you at least have to allow the amount of state that lets you remember the object you're delegating to. Of course, the Traits paper didn't go into traits with state, though it did mention it as a future research topic. We're just doing that future research for them. :-) Perfect ! My stupid question still apply. Will it be possible to have 'Exclusion' which forms a new trait|Role by removing a method from an existing trait|Role ? or should I read some docs on Roles to be smarter ? Thanks. -Dmitry By the way, we distinguish Traits from traits (which are compile-time properties applied by "is". To apply a Role we use "does". Larry
Re: The Sort Problem (was: well, The Sort Problem)
At 11:52 PM -0700 2/12/04, Luke Palmer wrote: But it needs some major syntax work so it can feel more like it's a part of the language instead of a library function. Not, mind, that I think Perl's syntax needs to be changed at all to accommodate. Since everyone's well past mad here and deep into drug-induced brain damage territory... If you're *really* looking to get fancy, why not just allow the sort specification to be done with SQL? Comfortable, well-understood, already has a decade or so of stupid things welded into it (so everyone can stop trying to think up new stupid things to weld in), and there are several grammars for it so it'd be no work to speak of for me. Heck, you could even unify map, grep, and sort and, if you fed in a list of pair lists or hashes, return parts of each record^Wlist element rather than the whole thing. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: The Sort Problem (was: well, The Sort Problem)
Friday 13 February 2004 15:02, Dan Sugalski wrote: > > If you're *really* looking to get fancy, why not just allow the > sort specification to be done with SQL? Comfortable, > well-understood, already has a decade or so of stupid things welded > into it [...] > > Heck, you could even unify map, grep, and sort [...] > That would be postmodern indeed. -angel
Re: Traits: to renew OO inheritance in a hacker style discussion
On Thu, 2004-02-12 at 14:03, chromatic wrote: > On Thu, 2004-02-12 at 05:52, Aaron Sherman wrote: > > > Perhaps I'm slow, but I don't see the difference between a trait and a > > Java interface other than the fact that traits appear to be more of a > > run-time construct. > > The easy answer is that interfaces completely suck while traits don't. > :) Ok, so what you're saying is that they're solving for exactly the same thing, but you don't like the Java implementation. Cool, I just wanted to see if I understood what a trait was. Interfaces are a great feature, IMHO, and if Perl 6 can implement them (as Larry suggests) in an even more flexible and well integrated way (via roles), I'm all for it. -- Aaron Sherman <[EMAIL PROTECTED]> Senior Systems Engineer and Toolsmith "It's the sound of a satellite saying, 'get me down!'" -Shriekback
Re: The Sort Problem
On Thu, 2004-02-12 at 18:50, Uri Guttman wrote:
> there are only a short list of key comparisons possible, int, string,
> float and maybe unicode. i separate int from float since they do have
> different internals in the GRT. it is one area where you do expose
> stuff. otherwise you could just use number.
And comparing in a particular language (as Dan pointed out in his Parrot
talk); comparing sets (e.g. numeric comparison, but odds and evens are
separate); ordering by string length; ordering by string-to-numeric
value with esoteric exceptions (software versions); etc.
Comparison is essentially always numeric, but only if you reduce your
inputs to numbers, and that's often not terribly efficent (e.g. you can
reduce any ascii string to:
chr(substr($s,0,1))+chr(substr($s,1,1))*128+...
and then comparing. The only limitation is that you'll have to use
Math::BigInt to do the comparison.
> simple. pick almost any language char set other than US ascii. many have
> special collating sequences. i am not anything close to a unicode expert
> but i have seen this issue. in fact setting the LANG (or some other)
> environment variable will affect many programs by changing the collating
> order.
Ok, yes. This was Dan's example, and is EXACTLY why I think you want to
use map once for key extraction and then sort's expression for
comparison.
> that is scary. do you realize that the sort block will be called for
> each comparison?
Yes why would it not be? How do you compare, say, IPv6 addresses if
not by performing a logically-ored comparison between each octet? I
certainly don't want to instantiate a Math::BigInt just to compare two
128-bit values.
> AS> @new1 = sortpairs {$_[0] <=> $_[1]} map {[$_,$_]} @old1;
>
> AS> @new2 = sortpairs {$_[0] <=> $_[1] || $_[4] cmp $_[3]} map
> AS> {[getkeys($_),$_]} @old2;
>
> where is getkeys defined?
It was an example. It's whatever you like. In some cases, that might
just be:
sub getkeys {
my $object = shift;
return @{$object->keys};
}
or perhaps:
sub getkeys {
my $string = shift;
return(length($string),$string); # Order by length and then ascii order
}
It was just an example. sortpairs was the interesting part.
> how do you know what indexes to use for each
> comparison? what happened to $_[2]? your call to $comp is passed 2
> arguments but the second example accesses 4 arguments.
You missed a layer of extraction there. $comp is passed each parameter
PAIR.
So if your input is [1,2,3,4,"moo"], then you are comparing the keys 1,
2, 3 and 4 and your value is "moo".
> AS> The second example really illustrates the point that you can swap the
> AS> direction of key order and mechanism to compare them at your whim.
>
> AS> Now, you just need to call sortpairs with any array of arrays of keys
> AS> (with trailing value).
>
> add a third key to that. quickly!
ok, easy:
@new2 = sortpairs {$_[0] <=> $_[1] || $_[4] cmp $_[3] ||
ACME::Compare::Thingulas->compare($_[5],$_[6])} map {[getkeys($_),$_]} @old2;
Please notice that the ONLY change is in the way I call it, not in
sortpairs. sortpairs still works just fine.
> a more straightforward api (which is close to what i will do in
> Sort::GRT) is (p5 code)
>
> my $sort = Sort::GRT->new(
>
> keys=> [
> { descending => 1,
> type => float,
> extract => '$_->{amount},
> },
> { extract => 'substr( $_->{date}, 0, 4)' },
> ]
> ) ;
The value of extract should be a subref, not a string (thus having
closure status, and therefore access to context).
I think you and I are in violent agreement. I just look at this as a
problem that doesn't need solving because Schwartzian Transforms do all
the work for me. You look at it as something needing encapsulation.
That's cool, but sematically, we're doing the same work.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
The Problem Roles Try To Solve
On Fri, 2004-02-13 at 11:02, Aaron Sherman wrote: > On Thu, 2004-02-12 at 14:03, chromatic wrote: > > The easy answer is that interfaces completely suck while traits don't. > > :) > Ok, so what you're saying is that they're solving for exactly the same > thing, but you don't like the Java implementation. Yes and no. I don't think Java interfaces actually solve anything except "let's not change the bytecode spec *again*". At least they acknowledge that single-inheritance isn't the be-all end-all of objects, but the second wrongest way to improve polymorphism is to add a second type of polymorphism with a separate implementation, philosophy, and syntax. The first, of course, is just to ignore the problem. The right way to improve polymorphism is to find common ground between inheritance, delegation, composition, aggregation, and reimplementation, make that your baseline, and support those techniques equally well. That has implications for the type system, the core libraries, and method dispatch, so it's much harder than copying an existing language and throwing out the parts you don't like. Then again, many things that are difficult are worth doing. -- c
Re: Semantics of vector operations
This is still raging. I was going to let it slide. I hate the mechanics
behind squeeky wheels. Makes it harder to evaluate arguments for their
merits by clogging the filters. Okey, enough metaphores.
On 0, Luke Palmer <[EMAIL PROTECTED]> wrote:
>
> > Agreed. Cryptic, but in a different way than usual. I'd rather see
> > plain old keywords as long as I'm typing things out or making that
> > many key-strokes.
> >
> > sub each (*);
> >
> > each @arr += 3;
> >
> > each @arr += each @foo;
>
> That would be a hard macro to write. Not impossible, of course :-)
>
> I'm not sure it's a good idea to change the syntax just because Unicode
> is unavailable. There was a definite reason for bundling the "each"
> modifiers near the operator, and we'd be changing that. You also get
> ambiguities regarding to which operator the C applies if there is
> more than one.
>
> On the other hand, it does read quite wonderfully, unlike the seeming
> alternative:
>
> @arr each += each @foo;
>
> What about just a function?
>
> each(&infix:+= , @arr, @foo)
>
> Such that the Unicode is the only way to get at the syntactic shortcut?
> We've done a lot to make functions readable in a lot of ways. Indeed,
> there are many ways the function could work. A function that operates
> on alternating arguments may not be unhandy either:
I really like this too. It is like Lisp's special forms: "apply operator to data
in interesting way". It opens the door for numerous other operations in
a generic system. Maybe Damian will champion this for us =)
Taken to an ugly extreme, it could look like the correlation I wrote for
AI::FuzzyLogic, where sets permutate, correlate, or aggregate. Creating a framework
where this can exist outside of core prevents something horrid from being
suggested for core =)
>
> each(&infix:+= , zip(@arr, @foo))
>
> But that's getting pretty far away from what the operators originally
> intended.
This isn't very far away from map when used on built-ins.
@foo = map &infix:*, zip(@foo, @bar);
map -> $a is rw, $b { $a *= $b }, zip @foo, @bar; # except that zip would copy in
all probability
each() as a map type operator that applies operators (and other closures), modifying
the LHS, covers what people want to do with vectorized operators and covers
gaps in map.
So, in summary, I really like Luke's proposal.
-scott
>
> > Larry Wall suggested reading >> and << as "each".
> >
> > This would require a small comprimise on the p5 each. Or else it could be
> > named "vector". Shouldn't be a problem with %hash.keys, %hash.values,
> > %hash.each anyway.
>
> Perl5 C is going away anyway, in favor of the new construct:
>
> for %hash.kv -> $k, $v {
> ...
> }
>
> > This wouldn't implement as an operator very well, admittedly, but more like
> > a control keyword. It would seem closely related to foreach, though.
>
> Which is also going away :-)
>
> > What happens when there are a bunch of the puppies? Vectorizing operators
> > do the right thing, working according to the rules of precedence. "each"
> > would have to just share one iterator per statement, or else do ugly things
> > to the rest of the statement. It would be very difficult to do something like:
> >
> > (each @foo + each @bar) + (each @baz + each @baz)
>
> Don't worry about implementation. That's not our job.
>
> It would probably be implemented as a macro that just put it back into
> the Unicode notation.
>
> > This would lend itself a P5 backport that did overload on its argument, too. If
> > it found that the thing on the right hand side was also overloaded into the
> > same class, it is could use a single iterator on both sides, otherwise it would
> > treat the 2nd argument as a scalar. This would solve the "single iterator
> > per line" problem for p5 atleast. It would work correctly. Any number of
> > vectorized arrays could be floating around in an expression, each interacting
> > with each other correctly.
>
> Of course you mean "損interacting with束 other correctly." :-)
>
> > Would it be possible to subclass things on the fly, returning a specialized
> > object representing the argument that knew how to vectorize when asked to add?
> > Aren't add, substract, multiply, and so on, implemented as class methods in
> > Perl 6, much like Perl 5's overload module?
>
> No! And I couldn't be happier! They're multimethods, dispatching based
> on I their arguments, not just the left one.
>
> Luke
Re: The Sort Problem (was: well, The Sort Problem)
Here's my stab at a sort syntax, pulling syntax over from REs:
@out
<== sort key:ri($_->[2]), key:s($_->[4])
<== @in;
Basicly, you have a list of RE syntax like C values, whilch take
various modifiers to say how to play with that key, and then an expr on
how to generate the key given element $_.
Possible modifiers: (verbose versions welcome)
:rreverse/descending
:n force numeric comparisons
:s force string comparisons (default)
:u unicode (implies :s)
:i case insensitive (implies :s)
:l localized collation order
:x call custom compare sub (a la P5)
This allows:
@out = sort keys %hash; # everything gets defaulted
@out = sort key:x{myfunc($a) cmp myfunc($b)}(), @in; # handy for P5
migration, but not much else
@out = sort key(myfunc($_)), @in; # same as above, but much better.
@out = sort key(%lookup{$_->{remotekey}}), key:ir($_->{priority}), @in;
# complex in P5, easy here.
Advantages:
- Uses syntax idioms used elsewhere in P6.
- Common cases are easy
- Decent huffman coding.
Disadvantages:
- Do we really want things that look like REs that are not REs?
- If we do this, are we setting ourselves up to create other RE-like
creatures for grep, for, etc, to the point
where people will start wanting to roll their own in modules?
Thoughts?
-- Rod
Re: The Sort Problem
Am Freitag, 13. Februar 2004 01:40 schrieb Larry Wall:
> On Thu, Feb 12, 2004 at 04:29:58PM -0500, Uri Guttman wrote:
> : again, confusing. why should the order of a binary operator mean so
> : much? the order of a sort key is either ascending or descending. that is
> : what coders want to specify. translating that to the correct operator
> : (cmp or <=>) and the correct binary order is not the same as specifying
> : the key sort order and key type (int, string, float).
>
> Uri is dead on with this one, guys.
As I listen to this mails, I get the feeling that something like this is
wanted:
Key generation:
@unsorted_temp = map {
$k1=$_.func1('a');# ASC
$k2=$_.func2('we'); # DESC
[ $_, $k1, $k2 ];
} @unsorted;
Now we've got an array with keys and the objects.
Sorting:
@sorted = sort {
$a->[1] cmp $b->[1] ||
$b->[2] <=> $a->[2] ||
} @unsorted_temp;
These things would have to be said in P6.
So approx.:
@sorted = @unsorted.sort(
keys => [ { $_.func1('a'); },
{ $_.func2('we'); } ],
cmp => [ cmp, <=> ],
order => [ "asc", "desc"],
key_generation => "lazy",
);
That would explain what I want.
Maybe we could turn the parts around:
@sorted = @unsorted.sort(
1 => [ { $_.func1('a'); }, cmp, "asc"],
2 => [ { $_.func2('we'); }, <=>, "desc"],
);
or maybe use a hash instead of an array:
@sorted = @unsorted.sort(
1 => [ key => { $_.func1('a'); }, op => cmp, order => "asc"],
2 => [ key => { $_.func2('we'); }, op => <=>, order => "desc"],
);
If that's too verbose? I don't think so; I've stumbled often enough on $a <=>
$b vs. $b <=> $a and similar, and the above just tells what should be done.
Regards,
Phil
Re: The Sort Problem
> "RA" == Rod Adams <[EMAIL PROTECTED]> writes:
RA> Here's my stab at a sort syntax, pulling syntax over from REs:
RA> @out
RA> <== sort key:ri($_->[2]), key:s($_->[4])
RA> <== @in;
RA> Basicly, you have a list of RE syntax like C values, whilch take
RA> various modifiers to say how to play with that key, and then an expr
RA> on how to generate the key given element $_.
RA> Possible modifiers: (verbose versions welcome)
RA> :rreverse/descending
RA> :n force numeric comparisons
RA> :s force string comparisons (default)
RA> :u unicode (implies :s)
RA> :i case insensitive (implies :s)
RA> :l localized collation order
RA> :x call custom compare sub (a la P5)
i would support longer modifier names as aliases like rules do.
also numeric comparisons can be float or int. semantically they are the
same but it does affect internal stuff if you do a GRT implementation. i
hate to see this exposure of internals but if we want speed here it
needs to be shown.
RA> This allows:
RA> @out = sort keys %hash; # everything gets defaulted
RA> @out = sort key:x{myfunc($a) cmp myfunc($b)}(), @in; # handy for P5
RA> migration, but not much else
RA> @out = sort key(myfunc($_)), @in; # same as above, but much better.
RA> @out = sort key(%lookup{$_->{remotekey}}), key:ir($_->{priority}),
RA> @in; # complex in P5, easy here.
overall i like it.
RA> Advantages:
RA> - Uses syntax idioms used elsewhere in P6.
RA> - Common cases are easy
RA> - Decent huffman coding.
huffman isn't needed here IMO. sort isn't called so often so longer
modifier names are not a hinderance. rules will be called way more often
so short modifier aliases are useful huffman there. a good syntax that
handles multiple keys and is easy to remember and read is more important
than brevity. and you can spread keys out over multiple lines:
@out = sort
key( %lookup{ .{remotekey} } ),
key:insensitive:descending:locale( 'somewhere' )( .{priority} ),
key:float ( substr( 0, 10 ) ),
key:integer ( /foo(\d+)bar/ ),
key:compare( { ^$a <=> ^$b } )( /(\d+)$/ ),
key:compare( \&my_compare_sub ) ( /(\d+)$/ ),
@in ;
i think the . replaces $_->. in fact IIRC -> isn't used anymore for
deref.
do we need , between keys? sort basically will expect a list (without
commas?) of keys and then a list of data.
note that the code in key needs to be called in a list context so
grabbing (which i did perl5 style there. gotta get perl6::rules from
damian!) will work. maybe rules can deal with that in a better way than
i can think of.
note that i passed an argument to the locale modifier.
note that the custome compare callbacks can be a block or a sub
name/ref. the callback sub would be passed 2 args as usual.
do we need the ==> or <== stuff anywhere?
RA> Disadvantages:
RA> - Do we really want things that look like REs that are not REs?
other than the short names, it doesn't look like rule stuff.
RA> - If we do this, are we setting ourselves up to create other RE-like
RA> creatures for grep, for, etc, to the point
RA> where people will start wanting to roll their own in modules?
well, with the long names that isn't a problem.
RA> Thoughts?
drop the short names. but i like it. let's see if it passes larry's
muster.
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs http://jobs.perl.org
Object spec
While I'm still working on the vtable and supporting code section, most of the revamp of PDD15 (objects!) is checked into the repository. It'd be worth checking it out and checking it out, as this would be the time to get comments in. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Compiling parrot, cvs head
I know head can not compile at all, but maybe this can help to know that the following tests fail on my Slackware Linux: t/pmc/signalNOK 2# Failed test (t/pmc/signal.t at line 44) t/pmc/signalNOK 4# Failed test (t/pmc/signal.t at line 44) t/pmc/signalok 6/6# Looks like you failed 2 tests of 6. t/pmc/signaldubious Test returned status 2 (wstat 512, 0x200) DIED. FAILED tests 2, 4 Failed 2/6 tests, 66.67% okay (less 2 skipped tests: 2 okay, 33.33%) If unespected, I can send more details, if expected: good :-) Best regards, Alberto
Re: Object spec
Here's a patch to fix various typos etc. that I noticed on going over the spec. Simon --- pdd15_objects.pod.old Fri Feb 13 17:06:46 2004 +++ pdd15_objects.pod Fri Feb 13 17:10:08 2004 @@ -174,7 +174,7 @@ =item * -remove interfaces +Remove interfaces =back @@ -209,13 +209,13 @@ hold all the per-object instance data. ParrotClass PMCs hold all the class-specific information. Instantiating a new OO class creates a new ParrotClass PMC, and enters the new OO class into Parrot's PMC class -table, at which point it is indistiguishable from any other PMC +table, at which point it is indistinguishable from any other PMC class. (This doesn't mean that non-ParrotClass things can be subclassed or treated as an OO class. Neither is that forbidden. Just unimplemented) It's important to note that I 'standard' classes are -ParrotClass PMC instancess, and I 'standard' objects are +ParrotClass PMC instances, and I 'standard' objects are ParrotObject PMCs. We do I create a brand new PMC class for each OO class, and they all share the ParrotClass or ParrotObject vtable, respectively. This distinction is mostly an artifact of the @@ -252,7 +252,7 @@ The class attribute name hash. Keys are the fully qualified attribute names (in whatever format the language governing the class wants) and -the values are the offset from the beginnign of the attribute array of +the values are the offset from the beginning of the attribute array of the particular attribute. =back @@ -265,7 +265,7 @@ ParrotClass PMCs also have the "I am a class" flag set on them. -The ParrotObject PMC is an array of metainformation and +The ParrotObject PMC is an array of meta-information and attributes. The elements of this array are: =over 4 @@ -317,7 +317,7 @@ =item setattr Px, Sy, Pz -Set the attribute of obbect Px with the fully qualified name Sy to Pz +Set the attribute of object Px with the fully qualified name Sy to Pz =item fetchmethod Px, Py, Sz
Re: Object spec
A few questions: 1) How is the search order for the parents of a particular class specified? In particular, is this determined at the Parrot level or at the language level? Can it change at runtime? 2) Re. the classoffset op: how does this work when multiple parent classes specify the same attribute? For instance, suppose 'foo' is the first attribute specified in classes 'Bar' and 'Baz', which are theselves unrelated (i.e. 'Bar' doesn't inherit from 'Baz', nor vice versa), but which are both parent classes of a third class 'Qux'. Now, if P0 holds an object of class 'Qux', does: classoffset I0, P0, 'Bar' return the same value as: classoffset I0, P0, 'Baz' or not? 3) If more than one parent class specifies a particular attribute, do all of these parents have to be removed before the attribute is removed? Regards, Simon
Re: cvs commit: parrot/imcc/t/syn file.t
ld require compiling an intermediate C prograAdam Thomason wrote: Hmm, this is still wrong. The error message isn't just a function of the locale; it's also dependent on the OS. AIX is now back to expecting "No such file or directory" courtesy of LANG=C when the imcc error is "A file or directory in the path name does not exist." That's English, just not the right English. It looks like this is going to need a more involved fix that doesn't monkey with the locale and just does what IMCC is doing: calling strerror from C code. That would require compiling an intermediate C program and capturing its output in the test script. Last time this was brought up on IRC there wasn't an existing scaffold for doing that easily; has that changed? As usual there is a bewildering array of possibilities: i. There is already a scaffold for doing this, it just needs to be used ii. Forget about this test altogether Propably not a good idea iii. Do it with Perl5 and Inline::C This would force people to install Inline::C, or worse having it in the Parrot distribution. iv. Have a small test program written in C This would propably be easy to implement, it just adds to the overall complexity of Parrot. v. Parrot provides a catalogue of error messages How about a PMC, perhaps a read only PerlHash, that maps error messages to error numbers? This would also be nice for I18N. When there is consensus on what to do, then I would be willing to try to make it work. CU, Bernhard Adam -Original Message- From: Leopold Toetsch [mailto:[EMAIL PROTECTED] Sent: Thursday, February 12, 2004 5:19 AM To: Jens Rieks Cc: [EMAIL PROTECTED] Subject: Re: cvs commit: parrot/imcc/t/syn file.t Jens Rieks <[EMAIL PROTECTED]> wrote: The test has to be located inside the eval, this construct has no effect. Might it be better to set LANG to 'C', instead of 'en'? Thanks, applied. leo -- ** Bernhard Schmalhofer Senior Developer Biomax Informatics AG Lochhamer Str. 11 82152 Martinsried, Germany Tel: +49 89 895574-839 Fax: +49 89 895574-825 eMail: [EMAIL PROTECTED] Website: www.biomax.com **
Re: JIT & branches under the Sun
Stephane Peiry <[EMAIL PROTECTED]> wrote: > While playing with JIT on Suns, I've found out that the following pasm code: > set I1, 2 >LOOP: sub I1, 1 > ifI1, LOOP > print "end\n" > end > never finishes.. that is: parrot -j loop.pasm hangs forever (never printing > 'end') while the non-jitted "parrot loop.pasm" prints 'end' and finishes > there as expected. I don't know suns JIT code nor the assembler syntax, but it seems that the two subcc lines are broken: emitm_subcc_r(NATIVECODE, MAP[1], emitm_g(0), emitm_g(0)); If I understand that correctly it should read: emitm_subcc_r(NATIVECODE, MAP[1], MAP[1], emitm_g(0)); (and similar a few lines below) - at least when compared to other code that uses subcc_r. > Thanks, > Stephane > PS.: placing a 'print I1' within the loop resolves the problem, That could clear g(0) ... leo
Re: cvs commit: parrot/src resources.c string.c utils.c
At 9:48 PM +0100 2/12/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
A few more mod ops
+=item B(out PMC, in INT, in INT)
I'm not sure if this is a good idea. We currently don't have any such
kind of ops that takes 2 natural types and spits out a new PMC
Yeah, good point.
BTW, the doc above has out PMC, the implementation is:
+op cmod(in PMC, in INT, in INT) {
so that's b0rken anyway.
D'oh! That's what I get for doing a half-hack job. Dammit. I'll go
fix that. Well, OK, I'll go yank 'em, as this is a very good point:
But implementing *one* such opcode (cmod) implies that we have it for
all math ops for symmetry reasons.
A further note: while its safe to add opcodes w/o updating ops.num, the
next adding of unregistered ops might break the ops numbering (and
existing PBCs), so its not really recommended ;)
I'm OK with not numbering officially straight off, at least until
things get hashed out a bit. In this case it's especially wise, as
the extra mod/cmod ops are going to get yanked. :)
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Rules for method resolution?
So, as I dive into PDD15 as promised and get objects spec'd out so they can finally be implemented, I've come across the problem of method resolution. We've got, or will have, two ways to invoke methods. The first is a simple: callmethod "methodname" which calls the named method on the object in the object slot, does all the funky lookups and whatnot, and slams the method PMC into the . That's fine. May even mandate a: callmethod Pobject, "methodname" which'll move the object to the object slot. Or not. But that's beside the point. We also have to have a way to fetch the method PMC for a named method for later use, which is where the interesting bits come in. This is required for a number of reasons, including Python, so we have to have it. The question is... *When* is the name resolved? That is, if we do: findmethod P4, Pobject, "methodname" does the method PMC that gets stuck in P4 represent the method "methodname" for the object *at that point in time* or does it represent the method *at the time it is invoked*? That is, do we defer actual lookup until invocation, or do we resolve at method find time? This has some implications for when methods are overridden and namespaces swapped in and out, so it's (unfortunately) not an academic exercise. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Rules for method resolution?
At 11:38 AM -0500 2/13/04, Dan Sugalski wrote: which calls the named method on the object in the object slot, does all the funky lookups and whatnot, and slams the method PMC into the . That sentence should end "into the appropriate register." -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[PATCH] library/sdl_types.imc #2
Hi, This patch fixes _SDL_WaitEvent a bit; SDL_WaitEvent returns an integer and not a SDL_Event. It also introduces _SDL_PollEvent which is mostly a copy of _SDL_WaitEvent. Finally, _SDL_loop is modified to allow an "idle" event entry that gets called if no events are pending. If such an event is defined, _SDL_PollEvent is used to check whether events are pending. The idle callback is made every 50ms, "timer callback" might be a better name. Maybe it can even be extenended to a more general timer callback; SDL supports timer itself, but the problem that C callbacks are not yet supported well enough. It is also necessary to add code for SDL_PollEvent to library/sdl.pasm. I propose to rename this file to sdl_init.pasm; I'am working on a sdl.imc file that makes it much easier to use SDL with PIR, because it hides much of the 'internals'. I will send the file to the list in a few minutes (the documentation if not yet sufficient at the moment). jens diff -u -w -r1.6 sdl_types.imc --- library/sdl_types.imc 12 Feb 2004 18:42:37 - 1.6 +++ library/sdl_types.imc 13 Feb 2004 16:51:18 - @@ -345,10 +345,12 @@ .sym pmc WaitEvent WaitEvent = global "SDL::WaitEvent" + .sym int ret + .pcc_begin prototyped .arg event .nci_call WaitEvent - .result event + .result ret .pcc_end # dunno what this is @@ -357,6 +359,38 @@ .pcc_begin_return .return event + .return ret + .pcc_end_return +.end + +=item _SDL_Poll_Event() + +XXX - not ready to expose this one yet + +=cut + +.pcc_sub _SDL_PollEvent + .sym pmc event + event = _new_SDL_Event() + + .sym pmc PollEvent + PollEvent = global "SDL::PollEvent" + + .sym int ret + + .pcc_begin prototyped + .arg event + .nci_call PollEvent + .result ret + .pcc_end + + # dunno what this is + .local string type + typeof type, event + + .pcc_begin_return + .return event + .return ret .pcc_end_return .end @@ -375,19 +409,43 @@ .param pmc events .sym pmc event + .sym int type + .sym Sub callback + .sym num nexttime + .sym num curtime + + time nexttime + add nexttime, 0.05 loop: + defined type, events["idle"] + if type goto poll + branch wait +poll: + type = _SDL_PollEvent() + event = P5 + + time curtime + if curtime < nexttime goto noidle + set callback, events["idle"] + .pcc_begin prototyped + .pcc_call callback + .pcc_end + time nexttime + add nexttime, 0.05 +noidle: + if type == 1 goto process + sleep 0.025 + branch poll +wait: event = _SDL_WaitEvent() - - .sym int type +process: set type, event['type'] if type == 0 goto loop exists $I0, events[type] if $I0 == 0 goto loop - - .sym Sub callback if type == 2 goto _key_event if type == 3 goto _key_event
RE: Rules for method resolution?
> We also have to have a way to fetch the method PMC for a named method > for later use, which is where the interesting bits come in. > > This is required for a number of reasons, including Python, so we > have to have it. The question is... *When* is the name resolved? That > is, if we do: > > findmethod P4, Pobject, "methodname" > > does the method PMC that gets stuck in P4 represent the method > "methodname" for the object *at that point in time* or does it > represent the method *at the time it is invoked*? That is, do we > defer actual lookup until invocation, or do we resolve at method find > time? > > This has some implications for when methods are overridden and > namespaces swapped in and out, so it's (unfortunately) not an > academic exercise. > -- is it too much trouble to implement both, and give the HLLs a choice of which they call? would 'findmethod_sooner' and 'findmethod_later' be too difficult to implement, or too large to add to the core ops? what do you lose by offering both, as opposed to one or the other? i wish i had more answers than questions... --jerry *no longer just a lurker* ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance.
RE: Rules for method resolution?
At 12:32 PM -0500 2/13/04, Gay, Jerry wrote: > We also have to have a way to fetch the method PMC for a named method for later use, which is where the interesting bits come in. This is required for a number of reasons, including Python, so we have to have it. The question is... *When* is the name resolved? That is, if we do: findmethod P4, Pobject, "methodname" does the method PMC that gets stuck in P4 represent the method "methodname" for the object *at that point in time* or does it represent the method *at the time it is invoked*? That is, do we defer actual lookup until invocation, or do we resolve at method find time? This has some implications for when methods are overridden and namespaces swapped in and out, so it's (unfortunately) not an academic exercise. -- is it too much trouble to implement both, and give the HLLs a choice of which they call? Well... the problem is that at the point of call you really don't know which type you have, and arguably ought not know, and just do whatever the PMC thinks is proper, presuming the find returned a PMC that Does The Right Thing. Which answers the question, in its own way -- I'll make it "it depends" and leave it up to the class authors/language designers to decide what the heck to do with pre-looked-up methods. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[NEW] library/sdl.imc
Hi, here is an easy to use (with PIR code) wrapper of the SDL library. It tries to hide all internals of the wrapper and makes the most important SDL functions directly available in PIR code. jens =head1 TITLE library/sdl.imc - PIR interface to SDL =head1 SYNOPSIS .include "library/sdl.imc" # _main is the entry point of SDL apps .sub _main .local pmc screen .local pmc events # init SDL _SDL_Init( SDL_INIT_VIDEO ) # set the videomode screen = _SDL_SetVideoMode( 320, 420, 0, SDL_SWSURFACE ) # .. create your own event entries ... events = _create_events() # start the event loop _SDL_loop( events ) # shut SDL down _SDL_Quit() .pcc_begin_return .return 0 .pcc_end_return .end =head1 DESCRIPTION This wrapper provides access to the SDL library. Please also refer to the SDL documentation for more information about the functions presented here. =head1 FUNCTIONS This library provides the following functions: =over 4 =cut # this is where the execution starts .sub _init_crt _init() # call the SDL main function _main() end .end .include "library/sdl_types.imc" .include "library/sdl_constants.imc" .include "library/sdl_image.imc" .include "library/dumper.imc" .sub _init .include "library/sdl.pasm" _init_SDL_Image() .pcc_begin_return .pcc_end_return .end .const int SDL_INIT_TIMER = 0x0001 .const int SDL_INIT_AUDIO = 0x0010 .const int SDL_INIT_VIDEO = 0x0020 .const int SDL_INIT_CDROM = 0x0100 .const int SDL_INIT_JOYSTICK= 0x0200 # Don't catch fatal signals .const int SDL_INIT_NOPARACHUTE = 0x0010 # Not supported on all OS's .const int SDL_INIT_EVENTTHREAD = 0x0100 .const int SDL_INIT_EVERYTHING = 0x =item _SDL_Init( flags ) Initializes the SDL library. =over 4 =item flags you can XOR one or more of the following constants to initialize the specific SDL subsystems: SDL_INIT_TIMER, SDL_INIT_AUDIO, SDL_INIT_VIDEO, SDL_INIT_CDROM, SDL_INIT_JOYSTICK, SDL_INIT_NOPARACHUTE, SDL_INIT_EVENTTHREAD, SDL_INIT_EVERYTHING =back Please refer to the SDL documentation for more information about the meanings of the flags. =cut .sub _SDL_Init .param int mask .local pmc nci pushp nci nci = global "SDL::Init" .pcc_begin prototyped .arg mask .nci_call nci .result mask .pcc_end popp nci .pcc_begin_return .return mask .pcc_end_return .end .const int SDL_SWSURFACE = 0x .const int SDL_HWSURFACE = 0x0001 .const int SDL_ASYNCBLIT = 0x0004 # Available for SDL_SetVideoMode() .const int SDL_ANYFORMAT = 0x1000 .const int SDL_HWPALETTE = 0x2000 .const int SDL_DOUBLEBUF = 0x4000 .const int SDL_FULLSCREEN = 0x8000 .const int SDL_OPENGL = 0x0002 .const int SDL_OPENGLBLIT = 0x000A .const int SDL_RESIZABLE = 0x0010 .const int SDL_NOFRAME = 0x0020 # Used internally (read-only) .const int SDL_HWACCEL = 0x0100 .const int SDL_SRCCOLORKEY = 0x1000 .const int SDL_RLEACCELOK = 0x2000 .const int SDL_RLEACCEL= 0x4000 .const int SDL_SRCALPHA= 0x0001 .const int SDL_PREALLOC= 0x0100 =item _SDL_SetVideMode( width, height, bpp, flags ) Sets the video mode. You can specifiy a bpp of 0, which will use your desktop's current bit depth. The most commonly used flags are: =over 4 =item SDL_SWSURFACE Surface is in system memory =item SDL_HWSURFACE Surface is in video memory =item SDL_ASYNCBLIT Use asynchronous blits if possible =item SDL_ANYFORMAT Allow any video depth/pixel-format =item SDL_DOUBLEBUF Set up double-buffered video mode =item SDL_FULLSCREEN Surface is a full screen display =back =cut .sub _SDL_SetVideoMode .param int width .param int height .param int bpp .param int flags .local pmc screen_settings .local object screen new screen_settings, .PerlHash set screen_settings['width'], width set screen_settings['height'], height set screen_settings['bpp'],bpp set screen_settings['flags'], flags screen = _new_SDL_Screen( screen_settings ) global "MP_screen" = screen .pcc_begin_return .return screen .pcc_end_return .end =item _SDL_UpdateRect( screen, x, y, w, h ) Update the specified screen region. =cut .sub _SDL_UpdateRect .param pmc screen .param int x .param int y .param int w .param int h .local pmc nci .local pmc rect .local int ret pushp nci pushp rect nci = global "SDL::UpdateRect" new rect, .PerlHash set rect["x"], x set rect["y"], y set rec
