On Thursday 09 March 2006 20:06, Flavio S. Glock wrote:
> I'll not to be technical - I'm posting links to the programs, and the
> #perl6 conversations are all logged in http://colabti.de - so feel
> free to go read the sources.
That's a big wad of code. Suppose I want to run it so I can see what
Hi all!
We had a discussion here about the pros and cons of using Module::Install with
"use inc::Module::Install" in the Makefile.PL, and bundling it along. Well,
now a showstopping bug happened in Module::Install and several modules that
included the affected version suffered:
http://search.c
In a library (languages/lua/lib/luastring.pir), I declare a global variable
("mt_string"):
.namespace [ "Lua" ]
.HLL "Lua", "lua_group"
.sub init :load, :anon
...
.local pmc _lua_mt_string
_lua_mt_string = new .LuaTable
global "mt_string" = _lua_mt_string
...
In a PMC met
Francois PERRAD wrote:
In a library (languages/lua/lib/luastring.pir), I declare a global
variable ("mt_string"):
.namespace [ "Lua" ]
.HLL "Lua", "lua_group"
.sub init :load, :anon
...
.local pmc _lua_mt_string
_lua_mt_string = new .LuaTable
global "mt_string" = _lua_mt_stri
Hi all,
now the following should work:
.HLL "Foo", "Foo_group"
.HLL_map .Sub, .FooSub
.sub foo # typeof gives 'FooSub'
...
(given that the HLL 'Foo' has defined a 'FooSub', which C Sub [1])
Closures and coroutines should be mappable too now.
There is one test[2], which is
Moin,
On Friday 10 March 2006 12:26, Shlomi Fish wrote:
> Hi all!
>
> We had a discussion here about the pros and cons of using
> Module::Install with "use inc::Module::Install" in the Makefile.PL, and
> bundling it along. Well, now a showstopping bug happened in
> Module::Install and several modu
On Fri, Mar 10, 2006 at 13:36:26 +0100, Tels wrote:
> So the bug might not affect everyone - but it is bad and makes me
> re-consider using Module::Install only when necessary.
Module::Install makes sense for applications and deployment and all
that For regular CPAN modules I think it's overk
Yuval Kogman wrote:
> The problem with these is that Module::Signature fails when it
> should warn if the key is not present in the user's keyring.
>
> If this technical issue is solved then regardless of whether or not
> signature tests are useless (i think they are, but then again i also
> think
S06/Splicing finishes with:
A quasiquote is not a block (even if the delimiters are curlies),
so any declaration of a variable is taken to be part of the block
surrounding the macro call location. Add your own {...} if you want
a block to surround your declarations.
I read this as meaning th
On Mar 8, 2006, at 14:30, Leopold Toetsch wrote:
2)
Default Namespace
The default namespace PMC will implement Parrot's current
behavior.
The current implementation allows a nested namespace and a variable to
have the same name (via the hack of prepending "\0" to namespace
n
On Fri, Mar 10, 2006 at 05:33:01PM +0100, Leopold Toetsch wrote:
> >a) Parrot's default namespace is untyped (raw). This means that a
> >variable/subroutine can't have the same name as a namespace. This
> >could break existing code.
> >
> >b) Otherwise, Parrot's namespace is (half-)typed, at leas
On Mar 10, 2006, at 17:45, Chip Salzenberg wrote:
Ah, well, I'm sorry to report that (a) was the correct answer; Parrot's
default should be entirely untyped.
Sorry I didn't catch this earlier, but I'm actually on the road today,
so
it's a good thing I caught it now before users could start co
I've implemented a fair amount of pdd21, mostly the invisible internals
part currently. Before I start with the final changes (and possibly
start breaking existing code), I'd like to summarize the planned
behavior.
Code snippet # NameSpace::name
.sub main
Brad Bowman wrote:
> and against the spirit of the "my $COMPILING::x" in earlier versions of
> S06.
> Regardless of the "not a block" status of a q:code, I think that it's
> lexicals should only be visible within the q:code by default. If this
> is the intention of the above phrase the it should b
2006/3/10, chromatic <[EMAIL PROTECTED]>:
> On Thursday 09 March 2006 20:06, Flavio S. Glock wrote:
>
> > I'll not to be technical - I'm posting links to the programs, and the
> > #perl6 conversations are all logged in http://colabti.de - so feel
> > free to go read the sources.
>
> That's a big wa
On Sat, Mar 11, 2006 at 03:40:59AM +0800, Audrey Tang wrote:
: Brad Bowman wrote:
: > and against the spirit of the "my $COMPILING::x" in earlier versions of
: > S06.
: > Regardless of the "not a block" status of a q:code, I think that it's
: > lexicals should only be visible within the q:code by d
Leopold Toetsch wrote:
> .HLL "perl5"," # new top-level namespace
> .sub 'x' # perl5::x
Will there be a way to get back into the default top-level namespace?
e.g.:
.HLL ""
or
.HLL "parrot"
My Amber compiler is currently adding a few extra su
On Mar 10, 2006, at 23:09, Roger Browne wrote:
Will there be a way to get back into the default top-level namespace?
e.g.:
.HLL ""
or
.HLL "parrot"
My Amber compiler is currently adding a few extra subs to some of the
standard parrot PMCs, and I won't be able to do this if I'm in the
Tels wrote:
Moin,
On Friday 10 March 2006 12:26, Shlomi Fish wrote:
Hi all!
We had a discussion here about the pros and cons of using
Module::Install with "use inc::Module::Install" in the Makefile.PL, and
bundling it along. Well, now a showstopping bug happened in
Module::Install and several
19 matches
Mail list logo
