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
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,
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
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
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
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 Ckey 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
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.
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 Ckey values, whilch take
RA various modifiers to say how to play
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
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)
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 @@
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
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
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
At 9:48 PM +0100 2/12/04, Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
A few more mod ops
+=item Bcmod(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
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
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
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
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:
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
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
21 matches
Mail list logo
