On Sep 12, 2004, at 8:43 PM, Luke Palmer wrote:
Jeff Clites writes:
On Sep 7, 2004, at 6:26 AM, Dan Sugalski wrote:
*) Namespaces are hierarchical
So we can have [foo; bar; baz] for a namespace. Woo hoo and all
that. It'd map to the equivalent perl namespace of foo::bar::baz.
How does this
Jeff Clites [EMAIL PROTECTED] wrote:
And again, I don't so much object to the idea of nested namespaces--I
just feel that they'll slow down symbol lookups, without giving us much
in return. I'm afraid we're adding complexity we don't need.
One thing this buys you is that you can have a Perl
On Sep 12, 2004, at 11:29 PM, Brent 'Dax' Royal-Gordon wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
And again, I don't so much object to the idea of nested namespaces--I
just feel that they'll slow down symbol lookups, without giving us
much
in return. I'm afraid we're adding complexity we don't
On Sep-09, Brent 'Dax' Royal-Gordon wrote:
Tiny nit: for consistency with other Configure source files, this
should probably be named dynclasses_pl.in. No big deal, though.
Consistency is good, and you're the authority. Change committed.
Jeff Clites writes:
On Sep 12, 2004, at 8:43 PM, Luke Palmer wrote:
Jeff Clites writes:
On Sep 7, 2004, at 6:26 AM, Dan Sugalski wrote:
*) Namespaces are hierarchical
So we can have [foo; bar; baz] for a namespace. Woo hoo and all
that. It'd map to the equivalent perl namespace of
Matt Diephouse wrote:
On Sat, 11 Sep 2004 11:44:06 +0200, Leopold Toetsch [EMAIL PROTECTED] wrote:
1) pop off the buffered I/O layer:
Here's a patch that uses option one.
Thanks, applied,
leo
Stéphane Payrard wrote:
When routines declared with the @LOAD pragma are in the main
segment, they are not executed. This is probably not a problem
because the code of these routines could be easly moved in the
main routine but that should be either fixed or documented.
Yep. Updated docs.
Thanks,
Luke Palmer wrote:
Jeff Clites writes:
On Sep 7, 2004, at 6:26 AM, Dan Sugalski wrote:
*) Namespaces are hierarchical
So we can have [foo; bar; baz] for a namespace. Woo hoo and all
that. It'd map to the equivalent perl namespace of foo::bar::baz.
How does this hierarchical nature manifest? I
Stephane Peiry (via RT) wrote:
This is needed when the actual structure already exist outside of
parrot and we want it to work on it (see: Parrot_PMC_set_pointer
in include/parrot/extend.h).
Thanks, applied - #31539 as well.
leo
On Mon, 6 Sep 2004, Aaron Sherman wrote:
Sized low-level types are named most generally by appending the number
of bits to a generic low-level type name:
[...] int1 int2 int4 int8 int16 int32 int64
Ok, so Parrot doesn't have those. Parrot has int.
The above generic low-level types are
I went digging through my spam box last night and found this from
back in august, from Daniel Grunblatt. (It hit just a couple of
blacklists apparently...) Forwarding on as he requested:
From: Daniel Grunblatt [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: IA64 and HPPA JIT
Date: Mon, 9 Aug
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sunday 12 September 2004 10:08 pm, Jeff Clites wrote:
I'd say that the language-level namespaces should get nice reverse-DNS
names, like [com.perl.perl5], or whatever's appropriate.
No, no, no, no. Bad Java programmer! :)
The reverse-DNS
At 3:31 AM -0600 9/11/04, Thomas Fjellstrom wrote:
On September 8, 2004 04:34 pm, Dan Sugalski wrote:
At 11:02 PM +0100 9/8/04, Richard Jolly wrote:
Hi,
newbie
Can someone provide clarification on what mixing languages will look
like in practice, or point me to where its explained?
It's
On Sep 13, 2004, at 6:38 AM, Timm Murray wrote:
On Sunday 12 September 2004 10:08 pm, Jeff Clites wrote:
I'd say that the language-level namespaces should get nice reverse-DNS
names, like [com.perl.perl5], or whatever's appropriate.
No, no, no, no. Bad Java programmer! :)
Ha, it's actually one
On Mon, 2004-09-13 at 07:19, [EMAIL PROTECTED] wrote:
On Mon, 6 Sep 2004, Aaron Sherman wrote:
Sized low-level types are named most generally by appending the number
of bits to a generic low-level type name:
[...] int1 int2 int4 int8 int16 int32 int64
Ok, so Parrot doesn't have
This week on perl6-compiler
Yes you read that right; development of the Perl 6 compiler now has its
own mailing list. Hopefully, in the coming weeks, the current
perl6-internals list will get renamed parrot-internals to reflect that
split.
As I write this, groups.google.com
On September 13, 2004 07:52 am, Dan Sugalski wrote:
At 3:31 AM -0600 9/11/04, Thomas Fjellstrom wrote:
On September 8, 2004 04:34 pm, Dan Sugalski wrote:
At 11:02 PM +0100 9/8/04, Richard Jolly wrote:
Hi,
newbie
Can someone provide clarification on what mixing languages will
At 9:00 AM -0600 9/13/04, Thomas Fjellstrom wrote:
On September 13, 2004 07:52 am, Dan Sugalski wrote:
At 3:31 AM -0600 9/11/04, Thomas Fjellstrom wrote:
On September 8, 2004 04:34 pm, Dan Sugalski wrote:
At 11:02 PM +0100 9/8/04, Richard Jolly wrote:
Hi,
newbie
Can someone
The Perl 6 Summarizer wrote:
Namespaces
(Am I the only person who wants to repeat Namespaces! with the same
intonation used for 'Monorail!' in the Simpsons?)
Not any more...
# New Ticket Created by Will Coleda
# Please include the string: [perl #31550]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=31550
matt wishes http://parrotcode.org/docs included the imcc docs
(from #parrot)
It'd be nice if the current documentation split between IMCC and Parrot was resolved, since they're the same thing
now. Lots of good stuff is buried in imcc/docs, and should be integrated with the primary
documentation in docs.
Attached is a patch (and a tarball) that fulfills the TODO from
# New Ticket Created by Will Coleda
# Please include the string: [perl #31554]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=31554
Opcodes -
Mark IN/OUT register usage of ops. This is mainly for stack push/pop
(web patch already applied by our industrious webmaster!)
William Coleda wrote:
Attached is a patch (and a tarball) that fulfills the TODO from earlier
today that at least adds the existing IMCC documentation into the
parrotcode repository.
You're right, of course. (The fact that this patch sat for over 2 months after your
comment
didn't help. =-)
Removed the date reference all together, resolving ticket.
[EMAIL PROTECTED] - Tue Jun 29 10:21:38 2004]:
On Mon, 2004-06-28 at 21:28, Will Coleda wrote:
Minor update to the
Thanks, (somewhat belatedly) applied.
[EMAIL PROTECTED] - Thu Feb 19 02:26:02 2004]:
Index: imcc/docs/macros.pod
=
==
RCS file: /cvs/public/parrot/imcc/docs/macros.pod,v
retrieving revision 1.7
diff -u -d -r1.7 macros.pod
The compile error has changed:
error:imcc:Sub isn't a PMC
in file 'bar.imc' line 5
But, IMO, this should still barf on the declaration of index instead.
[coke - Sun Oct 19 18:01:33 2003]:
Is there a way to get this to barf on .local rather than the call to
index?
(Was a bit confusing,
This got fixed while I wasn't looking. =-)
Now runs fine WITH the _dumper, even at 100,000. It's slow, but it doesn't crash. =-)
Closing.
[coke - Thu Mar 25 21:34:27 2004]:
.sub main
.param pmc argv
$S0 = argv[1]
$I2 = $S0
$P2 = new PerlHash
$I0 = 1
loop:
if
27 matches
Mail list logo