Allison Randal wrote:
> There's an easy way to ensure the clash between method names and
> local variables never happens: always wrap the method name in quotes.
There's a sort-of-related problem with parameter names and local
variable names, but wrapping them in quotes isn't an available
workaro
I try to update and test Lua PMC.
I take inspiration in code of Tcl and Amber.
It's OK for these 2 PMC :
pmclass LuaNumber hll Lua maps Float
pmclass LuaString hll Lua maps String
But for :
pmclass LuaBoolean hll Lua maps Boolean
I don't know if autoboxing (maps Boolean
Thanks Matt and Chip. It's going to take a while to digest all that, but
already I have a question:
> Synopsis
> - Languages should contain their namespaces
Suppose my application is multi-HLL. For example, some parts of it are
written in Python and some in Ruby. Suppose I take one small part
> I take inspiration in code of Tcl and Amber.
My inspiration for the Amber PMCs was from the PMCs of Lua and Tcl :-)
Roger.
Pardon my ignorance here.
>From an application programmer's (which is what I used to be) point of view
I'd want to be able to write/use code from multiple HLLs without any danger
of them stamping all over each other's data.
I'd assumed Parrot would be enforcing namespace integrity and not assumin
On Dec 2, 2005, at 0:42, Allison Randal wrote:
I realize this is a side effect of the fact that method names are
actually strings, but it's an unfortunate result.
.sub main :main
newclass $P1, 'Thingy'
$P2 = new 'Thingy'
$P2.snark()
end
.end
.namespace [ "Thingy" ]
.sub sna
On Dec 2, 2005, at 10:50, François PERRAD wrote:
I try to update and test Lua PMC.
I take inspiration in code of Tcl and Amber.
It's OK for these 2 PMC :
pmclass LuaNumber hll Lua maps Float
pmclass LuaString hll Lua maps String
But for :
pmclass LuaBoolean hll Lua ma
"Leopold Toetsch" <[EMAIL PROTECTED]> wrote:
Jonathan Worthington wrote:
$ parrot -o breaks2.pbc breaks2.pir
$ parrot breaks2.pbc example.dll
directory_pack segment 'BYTECODE_EVAL_1' used size 158 but reported 160
Same answer as Jerry - works here on x86/linux.
Ugh. And if I build Parrot o
Michael Lacey wrote:
> I'd want to be able to write/use code from multiple HLLs without any danger
> of them stamping all over each other's data.
As I see it, HLLs are just languages, and it's not the _language_ that
"stamps all over" the data. It's really the code-generating tools that
have the p
# New Ticket Created by Will Coleda
# Please include the string: [perl #37814]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37814 >
Backstory: I downloaded this tcl file:
http://cvs.sourceforge.net/viewcvs.py/tcl/tcl/li
# New Ticket Created by Will Coleda
# Please include the string: [perl #37815]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37815 >
File:
languages/tcl/lib/builtins/flush.pir (exists, stub)
Spec:
http://www.tcl.tk
# New Ticket Created by Will Coleda
# Please include the string: [perl #37816]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37816 >
- svn rename languages/tcl/lib/commands/return.pir to languages/tcl/
lib/builtins/retu
# New Ticket Created by Will Coleda
# Please include the string: [perl #37817]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37817 >
File:
languages/tcl/lib/builtins/return.pir (pending another ticket)
Spec:
http:
I've just posted a few small tickets to RT for PIR work that Tcl
needs doing. These chunks should be fairly encapsulated.
If you'd like to work on one of them, just claim it in RT, or ping
me via email, IRC, or lily.
Regards, and thanks in advance!
The next release is due this weekend. I'll start release procedure at
Sun 4th, ~13:00 UTC.
The usual terms apply:
- no bigger changes to Parrot core, especially nothing that could break
the build or Parrot
- please test on all available platforms and 'make smoke' and/or update
PLATFORMS
- ple
> As I see it, HLLs are just languages, and it's not the _language_
> that "stamps all over" the data. It's really the code-generating
> tools that have the potential to mess about with data
Quite so, tho I wasn't aware that the tools might not have a one-to-one
relationship with languages.
I was
On 12/1/05, Matt Diephouse <[EMAIL PROTECTED]> wrote:
> After many months and lots of work, I'm happy to present you with the
> latest namespace spec draft. Comments are most welcome: to quote Chip,
> "The rest of the discussion would benefit from more eyes."
>
yay! your hard work shows... this was
jerry gay <[EMAIL PROTECTED]> wrote:
> On 12/1/05, Matt Diephouse <[EMAIL PROTECTED]> wrote:
> > User Defined Namespaces
> > All HLLs should prefix any namespaces with the lowercased name of
> > the HLL (so there's no question of what to capitalize). So Perl 5's
> > CGI
On Fri, Dec 02, 2005 at 11:50:15AM -0500, Matt Diephouse wrote:
> With that in mind, there are two possible ways to name namespaces and
> compilers:
>
> 1. Lowercase or uppercase them all. The Pugs code works with little or
> no effort.
And always use Unicode Normalised form C?
Nicholas Clark
On Dec 2, 2005, at 7:31, Matt Diephouse wrote:
[ Just a few notes, more to come. I've to read it some more times. ]
Naming Conventions
HLL Private Namespaces
HLLs should use a namespace with an underscore and the
lowercased
name of the HLL to store any private items.
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>
> On Dec 2, 2005, at 7:31, Matt Diephouse wrote:
>
> [ Just a few notes, more to come. I've to read it some more times. ]
>
> > Naming Conventions
>
> > HLL Private Namespaces
> > HLLs should use a namespace with an underscore and the
> > l
1. LANGUAGES AND NAMESPACES
In my previous messages, I was concerned that languages were being
shoehorned too tightly into their own namespaces.
But after a careful reading about "import_into", I am happy that each
language has sufficient ability to insert its symbols into the namespace
of anothe
Roger Browne <[EMAIL PROTECTED]> wrote:
> 1. LANGUAGES AND NAMESPACES
>
> In my previous messages, I was concerned that languages were being
> shoehorned too tightly into their own namespaces.
>
> But after a careful reading about "import_into", I am happy that each
> language has sufficient abilit
Hi, attached a patch with a start on the implementation of flush.pir
Note that ParrotIO.pmc doesn't seem to have a method to find out what
mode it is opened in, so that check cannot be done.
regards,
kj
Will Coleda (via RT) wrote:
# New Ticket Created by Will Coleda
# Please include the st
> HLL Private Namespaces
> HLLs should use a namespace with an underscore and the lowercased
> name of the HLL to store any private items. For instance, Tcl should
> use the "_tcl" namespace to store the subroutines that make up the
> compiler.
Is it the intenti
When one person takes over the module of another on CPAN via co-maint a
first-come tranfer, what happens to the RT stuff?
I'm in the process of taking over Net::Blogger from Aaron Straup Cope
(ASCOPE). I'm already set for first-come in PAUSE for that module now.
There are open RT issues that I'd
I've wondered about this myself. I've taken over Class::Trait but I
can't take ownership of the RT requests.
Cheers,
Ovid
--- "Christopher H. Laco" <[EMAIL PROTECTED]> wrote:
> When one person takes over the module of another on CPAN via co-maint
> a
> first-come tranfer, what happens to the RT
On Fri, Dec 02, 2005 at 12:10:24PM -0800, Ovid ([EMAIL PROTECTED]) wrote:
> I've wondered about this myself. I've taken over Class::Trait but I
> can't take ownership of the RT requests.
RT should do it automagically. Email Jesse directly if not.
xoxo,
Andy
--
Andy Lester => [EMAIL PROTECTED]
Andy Lester wrote:
> On Fri, Dec 02, 2005 at 12:10:24PM -0800, Ovid ([EMAIL PROTECTED]) wrote:
>> I've wondered about this myself. I've taken over Class::Trait but I
>> can't take ownership of the RT requests.
>
> RT should do it automagically. Email Jesse directly if not.
>
> xoxo,
> Andy
>
On Fri, Dec 02, 2005 at 03:19:42PM -0500, Christopher H. Laco ([EMAIL
PROTECTED]) wrote:
> For which, first-come, or do all of the co-maints have full RT access as
> well?
I don't know.
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Andy Lester wrote:
> On Fri, Dec 02, 2005 at 12:10:24PM -0800, Ovid ([EMAIL PROTECTED]) wrote:
>> I've wondered about this myself. I've taken over Class::Trait but I
>> can't take ownership of the RT requests.
>
> RT should do it automagically. Email Jesse directly if not.
>
> xoxo,
> Andy
>
Hello,
How can you match a literal "#" in a rule?
\# or only \x{23}?
S05 seems clear "# now always introduces a comment",
and \# is not listed in the escapes.
But then Perl 5 has \# so I assume it's just an omission...
Brad
--
A person who knows but a little will put on and air of knowledge
On Fri, 2005-12-02 at 01:31 -0500, Matt Diephouse wrote:
> import_into($P0, ...)
> Import items from the current namespace into the namespace in $P0.
It might be clearer to change the name to "export_into", because it is
being called on - and controlled by - the source:
source_nam
Roger Browne <[EMAIL PROTECTED]> wrote:
> > HLL Private Namespaces
> > HLLs should use a namespace with an underscore and the lowercased
> > name of the HLL to store any private items. For instance, Tcl should
> > use the "_tcl" namespace to store the subroutines that ma
On Fri, Dec 02, 2005 at 09:26:12PM +0100, Brad Bowman wrote:
> How can you match a literal "#" in a rule?
> \# or only \x{23}?
>
> S05 seems clear "# now always introduces a comment",
> and \# is not listed in the escapes.
>
> But then Perl 5 has \# so I assume it's just an omission...
Short an
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #37819]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37819 >
With both Sun's cc and gcc, builds of parrot on the sun4 architecture now
fail with:
rc-cc B--- - - -- 20051202
+solaris8-sparc-gcc3.4.3 B-- -- - -- 20051202
solaris9-sparc-gcc3.3.2 B-Y/2 - Y YY/2 20050814
solaris10-sparc-gcc3.4.3 B Y*7 Y/1 20050804
tru64-alpha-gcc 8
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #37818]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37818 >
config/init/hints/solaris.pl contains several callbacks or
triggers to deal with vari
Leopold Toetsch wrote:
- please test on all available platforms and 'make smoke' and/or
update PLATFORMS
With the recent Stash changes and (I presume) a fix to avoid reloading
pbc files, we're passing all tests on HP-UX!
Something's happened to spoil languages in the last day, but I don't b
it seems punie's using way too much memory. in fact, it's running out
of memory on my 512MB system, and peaks at 480MB usage during PAST
generation on my machine with 1.5GB. these are win32, using msvc, and
the command i ran was
D:\usr\local\parrot\trunk\languages\punie>..\..\parrot punie2.pir dem
On 12/2/05, jerry gay <[EMAIL PROTECTED]> wrote:
> i'm afraid adding tracing info will bring either system to its knees.
> perhaps there's some other way for me to help debug?
Okay, I haven't looked into the source at all, but I have one theory:
If Punie now uses Allison's attribute grammar imple
jerry gay wrote:
it seems punie's using way too much memory. in fact, it's running out
of memory on my 512MB system, and peaks at 480MB usage during PAST
generation on my machine with 1.5GB. these are win32, using msvc, and
the command i ran was ...
Seems like way too much memory considering th
Andy Lester wrote:
On Fri, Dec 02, 2005 at 12:10:24PM -0800, Ovid ([EMAIL PROTECTED]) wrote:
I've wondered about this myself. I've taken over Class::Trait but I
can't take ownership of the RT requests.
RT should do it automagically. Email Jesse directly if not.
As I found out when taki
It's likely that this is the result of my half done configure
refactoring.
The -lxlibmieee issue appears to have been simple and may have been
fixed in r10318. Please let me know.
As for the other issues, could you run `perl Configure.pl --verbose=2`
and post the output as an attachment?
Thanks
In rev 10317, parrot segfaults if the sub named in ":outer" is not
defined in the current compilation unit. The patch fixes the symptom,
and adds a test. (But the error message could be improved.)
-- Bob Rogers
The attached test case fails in rev 10317 as follows:
[EMAIL PROTECTED]> ./parrot -o lex-test-2-sub.pbc lex-test-2-sub.pir
[EMAIL PROTECTED]> ./parrot lex-test-2-main.pir
parrot: src/hash.c:243: hash_thaw: Assertion `info->extra_flags ==
EXTRA_IS_COUNT' failed.
Aborted
[EMA
It's not magic, there is an option in RT for the old owner to give it
away (which solves a subset of cases) but for me at least it was counter
intuitive.
The hideously old version of RT on rt.cpan.org is being replace shortly,
and I imagine that Jesse will have way of taking maint changes into
47 matches
Mail list logo
