Michel Pelletier <[EMAIL PROTECTED]> wrote:
> $P0 = new .PerlArray
> pop $P1, $P0
> kills the process with a 'Array index out of bounds!'. Is there a way
> to get an exception I can catch out of this?
We have to through an IndexError exception for Python. But that's not
done yet.
> -Michel
le
Stephane Peiry <[EMAIL PROTECTED]> wrote:
> On Mon, Aug 16, 2004 at 10:20:46AM +0200, Leopold Toetsch wrote:
>> "gtk-signal-connect" or "g-signal-connect" isn't found here. I can't
>> check the symbols of the lib, this dam** OS has symbols stripped. The
>> other box has only gtk-1.2.
> actually
On Mon, 16 Aug 2004 20:54:34 -0700
chromatic <[EMAIL PROTECTED]> wrote:
> On Mon, 2004-08-16 at 11:30, Michel Pelletier wrote:
>
> > I've noticed there are ops for interfaces, but no implementation or
> > ppd yet.
>
> Perl 6 has roles which are much more useful than interfaces -- in
> fact, inte
On Tue, 17 Aug 2004 08:54:32 +0200
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Michel Pelletier <[EMAIL PROTECTED]> wrote:
>
> > $P0 = new .PerlArray
> > pop $P1, $P0
>
> > kills the process with a 'Array index out of bounds!'. Is there a way
> > to get an exception I can catch out of this?
>
Michel Pelletier writes:
> > We have to through an IndexError exception for Python. But that's not
> > done yet.
>
> Okay, I'll keep depth checking. I thought about attempting a patch, but
> Larry says return an undef containing an unthrown exception, Dan wonders
> if it should be an empty undef,
Mattia Barbon <[EMAIL PROTECTED]> wrote:
> Hello,
> this patch:
> 1) removes the necessity of having "#define enum_class_Foo -1"
>in the dynpmc file
> 2) makes DYNSUPER fail at compile time instead of at runtime
> 3) makes MDD declarations work, as long as there isn't a circular
>depende
Will Coleda <[EMAIL PROTECTED]> wrote:
> Nothing serious, just trying to clean up a few nits in assorted POD.
Thanks, applied.
leo
> Mattia Barbon <[EMAIL PROTECTED]> wrote:
>
> > Hel=
lo,
> > this patch:
> > 1) removes the necessity of having "#define enu=
m_class_Foo -1"
> >in the dynpmc file
> > 2) makes DYNSUPER fail at=
compile time instead of at runtime
> > 3) makes MDD declarations work, =
as long as there isn't
# New Ticket Created by Nicholas Clark
# Please include the string: [perl #31208]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31208 >
---
osname= darwin
osvers= 7.3.0
arch= darwin-64int-2level
cc= ccache gcc
--
# New Ticket Created by Nicholas Clark
# Please include the string: [perl #31209]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31209 >
---
osname= linux
osvers= 2.6.6
arch= x86_64-linux-thread-multi
cc= cc
---
F
> $ make -C dynclasses
> /Users/nick/Sandpit/maint/bin/perl5.8.3 ../classes/pmc2c2.pl --dump foo.pmc
> /Users/nick/Sandpit/maint/bin/perl5.8.3 ../classes/pmc2c2.pl --c foo.pmc
> can't find file 'foo.dump' in path '/Users/nick/Parrot/parrot24/classes/..',
'/Users/nick/Parrot/parrot24/classes' at ../
At 8:54 PM -0700 8/16/04, chromatic wrote:
On Mon, 2004-08-16 at 11:30, Michel Pelletier wrote:
I've noticed there are ops for interfaces, but no implementation or ppd
yet.
Perl 6 has roles which are much more useful than interfaces -- in fact,
interfaces are degenerate roles. See Apocalypse 12
Nicholas Clark (via RT) wrote:
# New Ticket Created by Nicholas Clark
# Please include the string: [perl #31209]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31209 >
---
osname= linux
osvers= 2.6.6
arch= x86_64-linux-
This needs some docs, but I figured I'd throw out the short
description to the list since they've come up, and we ought to finish
them.
For parrot, interfaces are *very* simple things. An interface is a
string tag which can be attached to a class. Each class can have
multiple interface tags at
> since presumably interfaces are a bit more uniquely named than
> methods, and an object may be able to do something some class does
> while not actually being in that class.
>
should interface names be registered somewhere?
how are collisions handled?
i can imagine a scenario where multiple
At 10:55 AM -0400 8/17/04, Gay, Jerry wrote:
> since presumably interfaces are a bit more uniquely named than
methods, and an object may be able to do something some class does
while not actually being in that class.
should interface names be registered somewhere?
Nope.
how are collisions handle
The summary: request for architectural analysis.
The motivation: there are certain languages, possibly including perl 6,
that will benefit from the ability to flow from one parrot interpreter
to another. For example:
#!//googlestorage/programs/perl7.08032005
use remote qw( :googlecompute-shared
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> This needs some docs, but I figured I'd throw out the short
> description to the list since they've come up, and we ought to finish
> them.
$ cat does.pasm
new P0, .Array
does I0, P0, "array"
print I0
does I0, P0, "scalar"
print I0
At 12:11 PM -0400 8/17/04, Felix Gallo wrote:
The summary: request for architectural analysis.
The motivation: there are certain languages, possibly including perl 6,
that will benefit from the ability to flow from one parrot interpreter
to another.
We could add a few keywords and call the language
I don't know what's eating my mail, but evidently the attachment never
made it out. I tracked down this particular problem and fixed it for
the actual case I was using, which was not a PerlHash at all but
rather my own custom Match PMC for use in regexes. The attached patch
resolves the exact sympt
Oh, and while I have my fingers crossed, I may as well throw in the
original test patch as well. I'll let these messages go to hell
together.
Urk! Except I used stupid filenames, and swapped the attachments. So
this attachment is actually the patch. Need more sleep.
? src/py_func.str
Index: src/ke
I needed to create a Match PMC object for holding the match groups
(parenthesized expressions and capturing rules) from a regex match.
Unfortunately, it works by using another new PMC type, the MatchRange
PMC, to signal that an element of its hashtable should be interpreted
specially (as a substrin
Oh, and here's my test code for the Match PMC. This is really just a
copy of t/pmc/perlhash.t (since the Match PMC is supposed to behave
like a hash for the most part), but with one added test case at the
end showing how this would be used to store and retrieve
hypotheticals.
Index: t/pmc/match.t
=
Dan writes:
> Anyway, there *is* a threefold plan, involving quotas,
> privileges/capabilities, and restricted embedding environments.
If there's a link out there, I must've missed it. Is there one?
> >clock time (ulimit style)
>
> This'd be a per-interpreter, per-user quota.
Depending on
On Tue, Aug 17, 2004 at 03:15:01AM -0600, Luke Palmer wrote:
: Michel Pelletier writes:
: > > We have to through an IndexError exception for Python. But that's not
: > > done yet.
: >
: > Okay, I'll keep depth checking. I thought about attempting a patch, but
: > Larry says return an undef contai
At 1:30 PM -0400 8/17/04, Felix Gallo wrote:
Dan writes:
Anyway, there *is* a threefold plan, involving quotas,
privileges/capabilities, and restricted embedding environments.
If there's a link out there, I must've missed it. Is there one?
There isn't. I'll go fix that with PDD 18, Security and
On Tue, Aug 17, 2004 at 02:01:31PM -0400, Dan Sugalski wrote:
> Yep, per-interpreter means per-thread. Each thread gets an
> interpreter. (Logically, at least. There'll only ever be one OS
> thread in an interpreter at any one time, though I suppose it's
> possible an interpreter could move from
On Tue, Aug 17, 2004 at 10:10:14AM -0700, Steve Fink wrote:
> I don't know what's eating my mail, but evidently the attachment never
> made it out. I tracked down this particular problem and fixed it for
perl.org's list server software eats attachments named /\.t$/
It appears sufficiently ingraine
Dan Sugalksi wrote:
>
> VMS's (and yes, for the grammar wonks, that apostrophe is actually
> correct)
I'd lay even odds that VMS would qualify for the "ancient proper names"
exception...
William Strunk, Jr. (1869-1946). The Elements of Style. 1918.
>
> II. ELEMENTARY RULES OF USAGE
>
>
At 7:30 PM +0100 8/17/04, Nicholas Clark wrote:
On Tue, Aug 17, 2004 at 02:01:31PM -0400, Dan Sugalski wrote:
Yep, per-interpreter means per-thread. Each thread gets an
interpreter. (Logically, at least. There'll only ever be one OS
thread in an interpreter at any one time, though I suppose it's
1) We're going to have MMD for functions soon
2) Function invocation and return continuation invocation's
essentially identical
3) Therefore returning from a sub/method can do MMD return based on
the return values
Someone probably ought to think about what sort of syntax you might
add to a lang
On Tue, Aug 17, 2004 at 09:01:39AM +0200, Leopold Toetsch wrote:
> >> It returns a PerlUndef.
> > 60 dlfunc P2, P1, "g_signal_connect", "lptpP" - \
> > P2=NCI=PMC(0x8363fd0), P1=ParrotLibrary=PMC(0x8364108), ,
> > 65 store_global "Gtk::g_signal_connec", P2 - , \
> >P2=Per
On Tue, Aug 17, 2004 at 04:08:34PM -0400, Dan Sugalski wrote:
> 1) We're going to have MMD for functions soon
> 2) Function invocation and return continuation invocation's
> essentially identical
> 3) Therefore returning from a sub/method can do MMD return based on
> the return values
>
> Someon
Dan~
This is the coolest things I have heard all day. I am not sure that
my brain is entirely around what situations it would be useful in yet.
But it is really cool.
It seems to me that it would probably be most useful in the tail call
setting where you are just passing the result from one fun
On Tue, 2004-08-17 at 16:22, Felix Gallo wrote:
> On Tue, Aug 17, 2004 at 04:08:34PM -0400, Dan Sugalski wrote:
> > 1) We're going to have MMD for functions soon
> > 2) Function invocation and return continuation invocation's
> > essentially identical
> > 3) Therefore returning from a sub/method c
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> > What I'm planning on is a VMS-style quota, privilege, and identifier
>>> system.
>>
>> Pagan heretic -- you shall burn in the purifying flames of RSTS/E!
DS> Mmmm, RSTS/E. And BASIC/PLUS 2.6. Now *those* were the days. Now,
On Tue, 17 Aug 2004 03:15:01 -0600
Luke Palmer <[EMAIL PROTECTED]> wrote:
> Michel Pelletier writes:
> > > We have to through an IndexError exception for Python. But that's not
> > > done yet.
> >
> > Okay, I'll keep depth checking. I thought about attempting a patch, but
> > Larry says return a
Michel Pelletier <[EMAIL PROTECTED]> wrote:
> if Perl or other languages want an undef returned, it would seem to make
> more sense that they assume to cost of catching the exception and
> turning it into an undef, than everyone else turning the undef into an
> exception.
I believe that this is ex
38 matches
Mail list logo
