Sam Ruby [EMAIL PROTECTED] wrote:
Leopold Toetsch wrote:
So *all* lookups (complete with the asterisks) does not mean *all* lookups.
How about invoke?
Let's first concentrate on simpler stuff like infix operators.
Citing S06: Operators are just subroutines with special names.
That
First, there was some dicussion not too long ago:
Subject: Numeric semantics for base pmcs [1]
Subject: Last bits of the basic math semantics
The current Integer PMC doesn't yet follow the results of these threads.
Basic behavior of that type is Perl6 or Python semantics, which is: it's
Ah! Now we are getting somewhere!
Leopold Toetsch wrote:
Sam Ruby [EMAIL PROTECTED] wrote:
Leopold Toetsch wrote:
So *all* lookups (complete with the asterisks) does not mean *all* lookups.
How about invoke?
Let's first concentrate on simpler stuff like infix operators.
OK, but the point is
Dan Sugalski [EMAIL PROTECTED] wrote:
pushmark 12
popmark 12
pushaction Psub
I've now implemented these bits. I hope it's correct, specifically, if a
return continuation in only captured, the action handler is not run.
See t/pmc/exceptions.t
Still missing is the throw opcode.
Sam Ruby [EMAIL PROTECTED] wrote:
Ah! Now we are getting somewhere!
Yeah. That's the goal.
So, why have I proceeded in this manner? Two reasons.
Fair enough, both.
So given that we have a set of language-neutral PMCs in core that do the
right thing, Python or Perl PMCs can inherit a lot
Leopold Toetsch wrote:
Good. Now Evil Leo (who can't program in Python ;) writes some piece of
code like this:
$ cat m.py
class M(type):
def __new__(meta, name, base, vars):
cls = type.__new__(meta, name, base, vars)
cls.__add__ = myadd
return cls
def myadd(self, r):
Leopold Toetsch [EMAIL PROTECTED] writes:
Piers Cawley [EMAIL PROTECTED] wrote:
Leopold Toetsch [EMAIL PROTECTED] writes:
... While S registers hold pointers, they have
value semantics.
Is that guaranteed? Because it probably needs to be.
It's the current implementation and tested.
Piers Cawley [EMAIL PROTECTED] wrote:
Leopold Toetsch [EMAIL PROTECTED] writes:
The problem I have is: do we know where registers may be reset? For
example:
$I0 = 10
loop:
$P0 = shift array
dec $I0
if $I0 goto loop
What happens if the array PMC's Cshift get overloaded
Attached is a patch that changes the split opcode to use an Array
instead of a PerlArray.
It also updates the documentation to note this.
All the tests still pass, and a grep in the languages/ directory shows
that no language implementations are effected.
- James
Will Coleda (via RT) wrote:
#
Leopold Toetsch wrote:
Sam Ruby [EMAIL PROTECTED] wrote:
Leopold Toetsch wrote:
Here's the part that you snipped that addresses that question:
And there is a piece that I haven't written yet that will do the
reverse: if MMD_ADD is called on a PyObject that has not provided
such
Leo~
On Wed, 8 Dec 2004 20:29:00 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote:
So my conclusion that (in combination with restoring registers to the
values of continuation creation) I,S,N registers are almost unusable is
correct?
I would disagree. Let me take the above example and work
Sam Ruby [EMAIL PROTECTED] wrote:
[ snipped - all ok }
If I define an __add__ method with 16 arguments, Python will not throw
an exception.
I didn't write that. I've said: *if* you call it via a + b, Python
throws an exception - that one I've shown. Anyway...
If this is done at runtime, the
Leopold Toetsch wrote:
Sam Ruby [EMAIL PROTECTED] wrote:
[ snipped - all ok }
If I define an __add__ method with 16 arguments, Python will not throw
an exception.
I didn't write that. I've said: *if* you call it via a + b, Python
throws an exception - that one I've shown. Anyway...
What you wrote
Is there a plan at any point to move to an svn repository from cvs?
I'd like to work on a patch to move all the perl* pmcs into dynclasses, which would involve quite a bit of file moving, and I'll happily wait for svn if we're going that way, since it'll be smoother.
Thanks, applied!
James deBoer wrote:
Attached is a patch that changes the split opcode to use an Array
instead of a PerlArray.
It also updates the documentation to note this.
All the tests still pass, and a grep in the languages/ directory shows
that no language implementations are effected.
-
Will~
On Wed, 08 Dec 2004 19:19:07 -0500, William Coleda [EMAIL PROTECTED] wrote:
Is there a plan at any point to move to an svn repository from cvs?
I'd like to work on a patch to move all the perl* pmcs into dynclasses, which
would involve quite a bit of file moving, and I'll happily
While I personally like the idea, I think it is unlikely given how
much slower svn is on sizable repositories. Of course I have not
tried it recently, so maybe that has changed...
All that being said, I am in absolutely no position of authority about this...
This is, and always has been,
On Wed, Dec 08, 2004 at 10:16:21PM -0500, Matt Fowles wrote:
While I personally like the idea, I think it is unlikely given how
much slower svn is on sizable repositories. Of course I have not
tried it recently, so maybe that has changed...
If you wish to try out a recent Subversion on some
18 matches
Mail list logo
