Re: [perl #39751] unbug - [EMAIL PROTECTED]: tru64 core dump: t/dynoplibs/myops_4.pir

[Jarkko Hietaniemi]

Chip Salzenberg via RT wrote:
> parrot obeys you
> when you ask it politely
> to halt and catch fire

The test harness
should kindly be told about
this confusing anomaly
I never could get my
haikus to work

-- 
Jarkko Hietaniemi <[EMAIL PROTECTED]> http://www.iki.fi/jhi/ "There is this 
special
biologist word we use for 'stable'.  It is 'dead'." -- Jack Cohen

Dealing with subordinate runloops

[Bob Rogers]

   From: Allison Randal <[EMAIL PROTECTED]>
   Date: Thu, 03 Aug 2006 11:51:52 -0700

   Bob Rogers wrote:

   >From: Leopold Toetsch <[EMAIL PROTECTED]>
   >Date: Thu, 27 Jul 2006 20:50:18 +0200
   >
   >There's no way to get full Continuations working around such C code 
barriers, 
   >except by *not* entering secondary runloops at all for these cases. This
   >could be achieved by (optionally) returning a new PC for all vtable/MMD
   >functions that is, by changing the internal (C) calling conventions of 
   >all the PMC code.
   > 
   > I see a solution for simpler cases, that might even work for custom sort
   > functions, though it's certainly not painless.  Here's what I would like
   > to do for calling actions:

   Bob, could you briefly write up the problem and proposed solution as a
   [PDD] ticket for the extending, embedding, and external C API PDDs
   (10-12, and possibly 2 and 23)? How we handle exceptions and
   control-flow across C/Parrot boundaries is an important question, and I
   want to make sure we address it.

   Thanks,
   Allison

There are several possible variations on this theme, and all of them
involve a fair amount of pain, though applied in different places.  So I
think more discussion is necessary before picking a direction.

   I had hoped to produce a POC to seed the process, but didn't get
enough tuits.  I'll have some time this weekend, though, and will at the
very least post an analysis Sunday night, with or without POC.

   Does that sound alright?

-- Bob

Impending release of Parrot 0.4.6

[Chip Salzenberg]

Parrot 0.4.6 will be released Real Soon Now, probably this weekend.  No code
slush will be needed ... assuming I can manipulate Subversion to my will and
create a release branch.

Smokes and PLATFORMS would welcome your attention.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: [perl #40030] [PATCH] compiler/imcc missing dependency

[fonseka]

On 8/2/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:



On 8/2/06, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Am Mittwoch, 2. August 2006 19:52 schrieb [EMAIL PROTECTED]:
> > > There must be some other problem elsewhere.
> >
> > Found the problem... it was MY problem... I had rests of an old
instalation
> > of parrot in my /usr/local/lib, and gcc was pulling libparrot from
there,
> > making the hole process borked...
>
> Strange. I tried hard to resolve:
> http://rt.perl.org/rt3//Public/Bug/Display.html?id=39742
> and didn't see any bad interaction of an installed Parrot (albeit there
are a
> lot of such reports, that there is one).


I don't really know how to solve this problem... AFAIK gcc pulls by default
libs from /usr/local/lib or /usr/lib as soon as you do -l... You can
pass -L/path to gcc, but maybe the deafult search paths has priority over
the hand-defined ones. Guess I'll have to digg it more...



I see this in my generated Makefile:

LINKFLAGS  =  -L/usr/local/lib -Wl,-E
...
LDFLAGS=  -L/usr/local/lib

So gcc is pulling libraries from that dir, and if i got an old
libparrot there, it will probably broke the make process is this
helpfull??


> leo
>



--
Will work for bandwidth



--
Will work for bandwidth

[perl #39750] [EMAIL PROTECTED]: tru64 core dump: t/examples/japh_12.pasm

[Chip Salzenberg via RT]

Fixed in svn by deleting that never-will-work-again japh,
which hacked internals in an amazingly evil way.

[perl #39751] unbug - [EMAIL PROTECTED]: tru64 core dump: t/dynoplibs/myops_4.pir

[Chip Salzenberg via RT]

parrot obeys you
when you ask it politely
to halt and catch fire

[perl #39752] [EMAIL PROTECTED]: tru64 core dump: t/op/lexicals_27.pir

[Chip Salzenberg via RT]

Fixed in svn.
Actual bug was causing malloc(0).
Proximate bug is that, on tru64, malloc(0) fails.  :-)

[perl #39753] [EMAIL PROTECTED]: tru64 core dump: t/pmc/io_1.pir

[Chip Salzenberg via RT]

Until we know what these I/O ops should do, seg faults aren't
unexpected.  Nor are they something we can meaningfully fix.

This ticket now depends on the review of the I/O pdd.

[perl #39754] [EMAIL PROTECTED]: tru64 core dump: t/pmc/resizablebooleanarray_20.pasm

[Chip Salzenberg via RT]

This ticket now depends on ResizeableBooleanArray rewrite.

[perl #40066] rewrite ResizeableBooleanArray

[via RT]

# New Ticket Created by  Chip Salzenberg 
# Please include the string:  [perl #40066]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=40066 >


ResizeableBooleanArray is just plain bad.  Rewrite it.

PS: FixedBooleanArray ain't that great either.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: [perl #39756] [EMAIL PROTECTED]: tru64 core dump: t/examples/japh_10.pasm

[Leopold Toetsch]

Am Donnerstag, 3. August 2006 23:29 schrieb Chip Salzenberg:
> Wow.  So I've just learned that our test harness ignores seg faults.  

Nope. It's Test::* TODO magic. From t/examples/japh.t:

# known reasons for failure
my %todo = ( 1  => 'opcode "pack" is gone',
 2  => 'opcode "pack" is gone',
 4  => 'namespace has changed',
 9  => 'P1 is no longer special',
 10 => 'core dump',
 ... 

Todo tests are run and supposed to fail or not to give the correct result, but 
they are running ...

> > run --gc-debug t/examples/japh_10.pasm

This *does* of course segfault.

leo

[perl #40065] STM first merge tracking ticket

[via RT]

# New Ticket Created by  Chip Salzenberg 
# Please include the string:  [perl #40065]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=40065 >


This ticket will track the first merge of STM, which should get basic
threading working again.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: [perl #39756] [EMAIL PROTECTED]: tru64 core dump: t/examples/japh_10.pasm

[Chip Salzenberg]

Wow.  So I've just learned that our test harness ignores seg faults.  Which
explains why t/examples/japh.t keeps reporting "all tests successful" when
actually they're mostly segfaulting and otherwise failing.

This particular japh uses threading, which is known not to work until the
STM work by Charles Reiss (woggle) is merged.

I'm deferring this ticket appropriately.

On Thu, Jul 06, 2006 at 11:12:34PM -0700, Jarkko Hietaniemi wrote:
> # New Ticket Created by  Jarkko Hietaniemi 
> # Please include the string:  [perl #39756]
> # in the subject line of all future correspondence about this issue. 
> # http://rt.perl.org/rt3/Ticket/Display.html?id=39756 >
> 
> 
> (dbx) run --gc-debug t/examples/japh_10.pasm
> run --gc-debug t/examples/japh_10.pasm
> thread 0x3 signal Segmentation fault at   [clone_interpreter:63 
> +0xc,0x120122738
> ]   d->run_core = s->run_core;
> (dbx) p d
> (nil)
> (dbx) where
> >  0 clone_interpreter(dest = 0x14049f618, self = 0x1404a22c8) 
> > ["src/pmc/parrotinterpreter.pmc":63, 0x120122738]
>1 pt_thread_run(interp = 0x1401c4000, dest_interp = 0x14049f618, sub = 
> 0x14049f500) ["src/thread.c":147, 0x1200b8e58]
>2 pt_thread_run_3(interp = 0x1401c4000, dest_interp = 0x14049f618, sub = 
> 0x14049f500) ["src/thread.c":221, 0x1200b8ff4]
>3 pcf_v_JOP( = 0x1200bea5c,  = 0x1200bea5c,  = 0x1200bea5c, interpreter = 
> 0x1401c4000, self = 0x14022d608) ["src/nci.c":3266, 0x1201d0520]
>4 Parrot_NCI_invoke( = 0x1200c48c4,  = 0x1200c48c4, interpreter = 
> 0x1401c4000, pmc = 0x14022d608, next = 0x1404deb10) ["src/pmc/nci.c":146, 
> 0x120178668]
>5 Parrot_invokecc_p(cur_opcode = 0x1404deb00, interpreter = 0x1401c4000) 
> ["src/ops/core.ops":414, 0x1200c48c0]
>6 runops_slow_core(interpreter = 0x1401c4000, pc = 0x1404deb00) 
> ["src/runops_cores.c":180, 0x12014b208]
>7 runops_int( = 0x1404dea00,  = 0x1404dea00, interpreter = 0x1401c4000, 
> offset = 0) ["src/interpreter.c":775, 0x1200f9bb8]
>8 runops(interpreter = 0x1401c4000, offs = 0) ["src/inter_run.c":81, 
> 0x1200f7f60]
>9 runops_args(interpreter = 0x1401c4000, sub = 0x14049f640, obj = 
> 0x1401214c0, meth = (nil), sig = 0x140061298 = "vP", ap = struct {
> _a0 = 0x11fffbf40
> _offset = 24
> }) ["src/inter_run.c":182, 0x1200f8290]
>   10 Parrot_runops_fromc_args(interpreter = 0x1401c4000, sub = 0x14049f640, 
> sig
> = 0x140061298 = "vP") ["src/inter_run.c":276, 0x1200f8460]
>   11 Parrot_runcode(interpreter = 0x1401c4000, argc = 1, argv = 0x11fffc028) 
> ["src/embed.c":802, 0x1200a6384]
>   12 main(argc = 1, argv = 0x11fffc028) ["compilers/imcc/main.c":681, 
> 0x120088f60]
> (dbx)
> 
> Summary of my parrot 0.4.5 (r13183) configuration:
>   configdate='Fri Jul  7 00:08:51 2006'
>   Platform:
> osname=dec_osf, archname=alpha-dec_osf
> jitcapable=0, jitarchname=nojit,
> jitosname=dec_osf, jitcpuarch=alpha
> execcapable=0
> perl=/u/vieraat/vieraat/jhi/Perl/Platform/OSF1/bin/perl
>   Compiler:
> cc='cc', ccflags='-std -D_INTRINSICS -fprm d -ieee -I/p/include 
> -DLANGUAGE_C -pthread -D_XOPEN_SOURCE=500',
>   Linker and Libraries:
> ld='ld', ldflags=' -L/p/lib',
> cc_ldflags='',
> libs='-lm -lutil -lpthread -laio -lrt -lgmp'
>   Dynamic Linking:
> share_ext='.so', ld_share_flags='-shared -expect_unresolved "*" -O4 -msym 
> -std -L/p/lib',
> load_ext='.so', ld_load_flags='-shared -expect_unresolved "*" -O4 -msym 
> -std -L/p/lib'
>   Types:
> iv=long, intvalsize=8, intsize=4, opcode_t=long, opcode_t_size=8,
> ptrsize=8, ptr_alignment=8 byteorder=12345678, 
> nv=double, numvalsize=8, doublesize=8
> 

-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: Parrot news: namespace ops good, (some) namespace methods bad; key-accepting ops

[Allison Randal]

Chip Salzenberg wrote:
> 
> Matt suggests that the "get" meme is better for retrieving from a single
> known location, while the "find" meme is better for looking in multiple
> places until success.  If you agree, then "find_lex" can remain with its
> current name.  As can, for similar reasons, "find_type".

For consistency, I'd be more inclined to use get/set universally for
untyped symbol access (for the raw names including literal HLL name
mangling), and find/add universally for typed symbol access (with
HLL-specific name mangling handled automatically, or at least by passed
parameters).

"find_type" would fall into the latter set, because it retrieves the
type by unmangled name ("Foo") and not mangled name ("::Foo" for Perl 6
if it ends up going that way).

Allison

Re: [perl #39926] :init attribute (was Re: Implement .loadlib pragma in IMCC)

[jerry gay]

On 8/3/06, Chip Salzenberg <[EMAIL PROTECTED]> wrote:

On Thu, Aug 03, 2006 at 01:31:26PM -0700, Allison Randal via RT wrote:
> Patrick R. Michaud wrote:
> >
> > I'd like there to be an :init pragma to mark subs that are to be
> > executed anytime the file is loaded.  In the case of loading from
> > the command line, the :init subs should be executed prior to the
> > :main sub.
>
> Agreed and approved.

Cool.  So noted in http://rt.perl.org/rt3/Ticket/Display.html?id=39926.

> I was going to say "approved and added to the relevant PDD", but there
> doesn't seem to be a PDD documenting these subroutine attributes.

Ah, the PIR pdd rears its nonexistent head again.


the current location for this documentation is
docs/imcc/calling_conventions.pod. See the "Subpragma" section
~jerry

Re: [perl #39778] Segfault when using a Namespace with an Iterator

[Leopold Toetsch]

Am Donnerstag, 3. August 2006 22:27 schrieb Chip Salzenberg:
> So, is the namespace iteration working now ... at least enough to close the
> ticket that says "segfault" in large friendly lettes?

The segfault in the first place wasn't related to namespaces at all, more to 
hash iteration abuse/bug/inconvenience. So yes, I think.

leo

Re: [svn:parrot-pdd] r13740 - in trunk: . docs/pdds

[Allison Randal]

Matt Diephouse wrote:
>> Namespace opcodes now accept arrays to select multidimensional
>> namespaces again. The namespace object methods for setting/retrieving
>> namespaces and globals are eliminated as redundant.
>
> How does this handle the case where namespaces have a sigil or some
> other sort of name mangling? Aren't the get/set namespace methods an
> essential part of the typed interface?

The get/set_namespace methods were part of the untyped interface (so any
name mangling had to be handled manually). The typed interface uses
find_namespace and add_namespace.

Allison

Re: [perl #39776] [BUG] PGE core dump

[Chip Salzenberg]

On Mon, Jul 10, 2006 at 02:18:21PM -0500, Patrick R. Michaud wrote:
> I totally agree that PGE probably needs to provide better syntax
> error checking in situations such as this, thus I'm leaving this
> ticket open, or will add a new more descriptive one soon.

But why the core dump in this case?  Why not a thrown exception?

(I ask to know whether I should try to fix this before 0.4.6)
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: [perl #39926] :init attribute (was Re: Implement .loadlib pragma in IMCC)

[Chip Salzenberg]

On Thu, Aug 03, 2006 at 01:31:26PM -0700, Allison Randal via RT wrote:
> Patrick R. Michaud wrote:
> > 
> > I'd like there to be an :init pragma to mark subs that are to be
> > executed anytime the file is loaded.  In the case of loading from
> > the command line, the :init subs should be executed prior to the
> > :main sub.
> 
> Agreed and approved.

Cool.  So noted in http://rt.perl.org/rt3/Ticket/Display.html?id=39926.

> I was going to say "approved and added to the relevant PDD", but there
> doesn't seem to be a PDD documenting these subroutine attributes.

Ah, the PIR pdd rears its nonexistent head again.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: Parrot news: namespace ops good, (some) namespace methods bad; key-accepting ops

[Chip Salzenberg]

On Thu, Aug 03, 2006 at 11:18:04AM -0700, Allison Randal wrote:
> Chip Salzenberg wrote:
> > (And of course I repeat a gentle reminder that the old find_global and
> > store_global opcodes will eventually [eventually!] go away, so convert
> > to the {get,make}*namespace and {get,set}*global opcodes instead.)
> 
> Which reminds me that we need to propagate the change to lexicals too:
> get_lexical and set_lexical, instead of find_lex and store_lex. We might
> as well make it one deprecation cycle for the whole set.

Matt suggests that the "get" meme is better for retrieving from a single
known location, while the "find" meme is better for looking in multiple
places until success.  If you agree, then "find_lex" can remain with its
current name.  As can, for similar reasons, "find_type".

OTOH, I'll grant that "store" isn't as good a cognate as "find", but I'm not
sure we have a good word for "look around until you find the thing I name,
and then set it to this value."

So if we can't find a really good pair of words to replace get/set in the
searching case like lexicals, then maybe we'll just have to use get/set and
let the "lex" be the clue.

PS: In some HLLs (e.g. Tcl (AFAIK))) there is no searching to speak of,
so it's not a universally applicable concept.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: [perl #39926] :init attribute (was Re: Implement .loadlib pragma in IMCC)

[Allison Randal]

Patrick R. Michaud wrote:
> 
> I'd like there to be an :init pragma to mark subs that are to be
> executed anytime the file is loaded.  In the case of loading from
> the command line, the :init subs should be executed prior to the
> :main sub.

Agreed and approved. I was going to say "approved and added to the
relevant PDD", but there doesn't seem to be a PDD documenting these
subroutine attributes.

Allison

Re: [perl #39778] Segfault when using a Namespace with an Iterator

[Chip Salzenberg]

So, is the namespace iteration working now ... at least enough to close the
ticket that says "segfault" in large friendly lettes?
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: [perl #39986] Create Default PackFile for New Interpreter (Parrot C API)

[Chip Salzenberg]

On Thu, Aug 03, 2006 at 12:05:13PM -0700, chromatic wrote:
> On Thursday 03 August 2006 11:18, Chip Salzenberg wrote:
> > The whole question of packfiles is something I hadn't approached before,
> > and now that I have, I wonder: Why does a packfile needs to exist at all
> > when compiling into the in-memory interpreter?  There are some answers to
> > that question I'd accept, but it's still a question that needs answering.
> 
> The trivial answer is that there are a lot of functions where Parrot assumes 
> it has compiled code available.

But the compiled code wouldn't necessarily have to live in a structure
compatible with on-disk storage.  But of course such a commonality would
simplify things.  OK.

> > PS: Cage cleaners should detect and possibly correct all that namespace
> > pollution. Yuck.
> 
> In the external API, you mean?  Isn't there a bug for creating macros to 
> avoid 
> prefixing Parrot_ to all internal-only functions?

Yes, but that's at least potentially orthogonal: pollution ne inconvenience.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: Fix symbol table namespace pollution

[Chip Salzenberg]

On Thu, Aug 03, 2006 at 03:03:08PM -0400, Will Coleda wrote:
> http://www.parrotcode.org/cage-cleaners/todo.html

Hey, that's neat.

> http://xrl.us/owsd (Link to rt.perl.org)

Hey, that's neater!

> Enjoy.

Done, thanks.  :-)
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

[perl #40060] [CAGE] Fix non-symbol-table namespace pollution in public headers

[via RT]

# New Ticket Created by  Chip Salzenberg 
# Please include the string:  [perl #40060]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=40060 >


Public headers are the ones in C directory.  These are
included by embedders and extenders.  They must not declare or define any
symbol that isn't clearly Parrot-specific.  Prefixing symbols with C
or C is the easiest & safest way, but it can lead to a lot of
verbosity, so I'm willing to entertain exceptions or new conventions.

It's OK for public headers might have non-public parts protected with
C<#ifdef PARROT_IN_CORE>.  Those non-public parts might #define shorter
versions of the public symbols, e.g. C<#define foo Parrot_foo>.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: [perl #39986] Create Default PackFile for New Interpreter (Parrot C API)

[Andy Lester]

On Aug 3, 2006, at 2:05 PM, chromatic wrote:

PS: Cage cleaners should detect and possibly correct all that  
namespace

pollution. Yuck.


In the external API, you mean?  Isn't there a bug for creating  
macros to avoid

prefixing Parrot_ to all internal-only functions?


That is one of my first big tasks, yes.

--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance

[perl #40061] Parrot release 0.4.7

[via RT]

# New Ticket Created by  Chip Salzenberg 
# Please include the string:  [perl #40061]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=40061 >


This is a milestone ticket for the release of parrot 0.4.7
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: [perl #39986] Create Default PackFile for New Interpreter (Parrot C API)

[chromatic]

On Thursday 03 August 2006 11:18, Chip Salzenberg wrote:

> The whole question of packfiles is something I hadn't approached before,
> and now that I have, I wonder: Why does a packfile needs to exist at all
> when compiling into the in-memory interpreter?  There are some answers to
> that question I'd accept, but it's still a question that needs answering.

The trivial answer is that there are a lot of functions where Parrot assumes 
it has compiled code available.  All of them could check for a packfile and 
raise an exception if not, but making it impossible to create an interpreter 
*without* at least some data there (even if it's an empty packfile) could cut 
down on that reptition.

> PS: Cage cleaners should detect and possibly correct all that namespace
> pollution. Yuck.

In the external API, you mean?  Isn't there a bug for creating macros to avoid 
prefixing Parrot_ to all internal-only functions?

-- c

Re: Fix symbol table namespace pollution

[Will Coleda]

Chip:

http://www.parrotcode.org/cage-cleaners/todo.html

already has a link to:

http://xrl.us/owsd (Link to rt.perl.org)

Enjoy.

On Aug 3, 2006, at 2:55 PM, Chip Salzenberg wrote:


On Thu, Aug 03, 2006 at 11:51:40AM -0700, jerry gay wrote:

can not the rt repository be canon for cage cleaners tasks?
it is already for bugs, todo items, and patches.
there is a link to rt already in the See Also section of cage/ 
todo.pod.

if you prefer, i can add this task to cage/todo.pod.


That would be fairly neat, actually.  Searches should be easy since  
"cage"
isn't a term of art in the Parrot source.  A link on parrotcode.org  
to an

appropriately pre-formatted search would improve the ease of use.
--
Chip Salzenberg <[EMAIL PROTECTED]>



--
Will "Coke" Coleda
[EMAIL PROTECTED]

Re: [perl #39988] [BUG] Exceptions + Vtable Methods

[Allison Randal]

Bob Rogers wrote:
> 
>There's no way to get full Continuations working around such C code 
> barriers, 
>except by *not* entering secondary runloops at all for these cases[1]. 
> This 
>could be achieved by (optionally) returning a new PC for all vtable/MMD 
>functions that is, by changing the internal (C) calling conventions of all 
>the PMC code.
> 
> I see a solution for simpler cases, that might even work for custom sort
> functions, though it's certainly not painless.  Here's what I would like
> to do for calling actions:

Bob, could you briefly write up the problem and proposed solution as a
[PDD] ticket for the extending, embedding, and external C API PDDs
(10-12, and possibly 2 and 23)? How we handle exceptions and
control-flow across C/Parrot boundaries is an important question, and I
want to make sure we address it.

Thanks,
Allison

[perl #40059] [CAGE] Fix symbol table namespace pollution

[via RT]

# New Ticket Created by  Chip Salzenberg 
# Please include the string:  [perl #40059]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=40059 >


Extern functions and variables must have names that begin with C.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: Fix symbol table namespace pollution

[Chip Salzenberg]

On Thu, Aug 03, 2006 at 11:51:40AM -0700, jerry gay wrote:
> can not the rt repository be canon for cage cleaners tasks?
> it is already for bugs, todo items, and patches.
> there is a link to rt already in the See Also section of cage/todo.pod.
> if you prefer, i can add this task to cage/todo.pod.

That would be fairly neat, actually.  Searches should be easy since "cage"
isn't a term of art in the Parrot source.  A link on parrotcode.org to an
appropriately pre-formatted search would improve the ease of use.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: [CAGE] Fix symbol table namespace pollution

[Andy Lester]

On Aug 3, 2006, at 1:51 PM, jerry gay wrote:

i'm sorry, andy. can not the rt repository be canon for cage  
cleaners tasks?

it is already for bugs, todo items, and patches.
there is a link to rt already in the See Also section of cage/ 
todo.pod.

if you prefer, i can add this task to cage/todo.pod.
let me know.


I'd rather use the TODO.pod at this point.  When there are so many  
high-level tasks, and not very well documented, I think RT isn't a  
good tool.  I want people to be able to very easily look at the doc,  
and add code where possible.  RT doesn't excel at that.


Andy

--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance

Re: [CAGE] Fix symbol table namespace pollution

[jerry gay]

On 8/3/06, Andy Lester <[EMAIL PROTECTED]> wrote:


On Aug 3, 2006, at 1:24 PM, Chip Salzenberg wrote:

> Extern functions and variables must have names that begin with
> C.

I am way out of tuits lately.  Can you please add this to cage/
todo.pod for me?  Or someone?


i'm sorry, andy. can not the rt repository be canon for cage cleaners tasks?
it is already for bugs, todo items, and patches.
there is a link to rt already in the See Also section of cage/todo.pod.
if you prefer, i can add this task to cage/todo.pod.
let me know.
~jerry

Re: Fix symbol table namespace pollution

[Chip Salzenberg]

On Thu, Aug 03, 2006 at 01:29:20PM -0500, Andy Lester wrote:
> I am way out of tuits lately.  Can you please add this to cage/ 
> todo.pod for me?  Or someone?

Already done.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

[perl #40058] Disambiguate usage of class PMCs from class name lookup (pdd15, pdd06, pdd19)

[via RT]

# New Ticket Created by  Chip Salzenberg 
# Please include the string:  [perl #40058]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=40058 >


The new 'subclass' opcode variants demonstrates the inherent ambiguity
between class names and class PMCs; merely being a PMC or not isn't enough
to distinguish the intent of specifying class vs. class name.  (Keys are
PMCs.)  This should be resolved in a general way for all class-accepting
opcodes.


CURRENT STATE OF PLAY

There are currently five distinct ways to identify a class, some or all of
which are used by various opcodes:

 (1) Class PMC itself (in P reg)

 (2) INTVAL type number (I reg or integer constant)

 (3) STRING type name (S reg or string constant)

 (4) String PMC type name (String PMC in P reg or PMC constant)

 (5) Key PMC type name (Key PMC in P reg[*] or PMC constant)

 [*] The P reg version of this is new in my latest changes.
 It's not used widely (if at all), and only works for
 selected opcodes.


KNOWN FUTURE DEVELOPMENTS

It's already decided that we're moving class PMCs into the normal namespace
tree.  This change will eliminate many uses of the class-lookup opcodes, but
not all: There's a two-level search will still be required, where the
universal ['parrot'] HLL provides the fallback for class names not defined
locally -- e.g. C could return ['yourHLL';'Integer']
if you've defined that, or else ['parrot';'Integer'] if you haven't.


SUGGESTIONS

I. Opcode cleanup

   It seems to me that we should carefully distinguish two types of opcodes:
(a) opcodes that use class PMCs or numbers
(b) opcodes that look up class PMCs by name, and return a PMC or a number

   Type A opcodes would use lookup methods 1 and 2.
  PMC parameters would always be class PMCs.

   Type B opcodes would use lookup methods 3, 4, and 5.
  PMC parameters would always be names.

II. Eliminate simple string names for classes, using Keys exclusively

   There's little reason IMO to continue to support simple strings for class
   names; it multiplies opcodes for the special case of simple class names.
   Always using keys would serve as well.

-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: [perl #39986] Create Default PackFile for New Interpreter (Parrot C API)

[Chip Salzenberg]

The whole question of packfiles is something I hadn't approached before, and
now that I have, I wonder: Why does a packfile needs to exist at all when
compiling into the in-memory interpreter?  There are some answers to that
question I'd accept, but it's still a question that needs answering.

As for any further improvements, I fear they will have to wait for 0.4.7.

PS: Cage cleaners should detect and possibly correct all that namespace 
pollution.
Yuck.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: [CAGE] Fix symbol table namespace pollution

[Andy Lester]

On Aug 3, 2006, at 1:24 PM, Chip Salzenberg wrote:

Extern functions and variables must have names that begin with  
C.


I am way out of tuits lately.  Can you please add this to cage/ 
todo.pod for me?  Or someone?


--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance

[CAGE] Fix non-symbol-table namespace pollution in public headers

[Chip Salzenberg]

Public headers are the ones in C directory.  These are
included by embedders and extenders.  They must not declare or define any
symbol that isn't clearly Parrot-specific.  Prefixing symbols with C
or C is the easiest & safest way, but it can lead to a lot of
verbosity, so I'm willing to entertain exceptions or new conventions.

It's OK for public headers might have non-public parts protected with
C<#ifdef PARROT_IN_CORE>.  Those non-public parts might #define shorter
versions of the public symbols, e.g. C<#define foo Parrot_foo>.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

[CAGE] Fix symbol table namespace pollution

[Chip Salzenberg]

Extern functions and variables must have names that begin with C.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: Parrot news: namespace ops good, (some) namespace methods bad; key-accepting ops

[Allison Randal]

Chip Salzenberg wrote:
> 
> (And of course I repeat a gentle reminder that the old find_global and
> store_global opcodes will eventually [eventually!] go away, so convert
> to the {get,make}*namespace and {get,set}*global opcodes instead.)

Which reminds me that we need to propagate the change to lexicals too:
get_lexical and set_lexical, instead of find_lex and store_lex. We might
as well make it one deprecation cycle for the whole set.


> Note on an insteresting design issue: The new 'subclass' opcode variants
> demonstrates the inherent ambiguity between class names and class PMCs;
> merely being a PMC or not isn't enough to distinguish the intent of
> specifying class vs. class name.  (Keys are PMCs.)  This should be resolved
> in a general way for all class-accepting opcodes.

This is worthy of a ticket on PDD 15 (plus 6 and 19).

Allison

Re: [perl #40002] TGE Refactor / Compiler Tools Object

[jerry gay]

On 8/3/06, Allison Randal <[EMAIL PROTECTED]> wrote:

Kevin Tew wrote:
> Patrick R. Michaud via RT wrote:
>> So, if we're going to allow other languages in the transform
>> bodies, we may want a "hereis" or podly {{...}}, {{{...}}} syntax to
>> delimit the transform bodies.  At the moment I'm leaning towards the
>> {{...}} form, if only because PGE is already using it.

I'm comfortable with multiplying curly brackets. We may also ultimately
offer a "shorthand" form something like:

  t///

And allow all the perlish alternate delimiters.

> How about here doc style?
> This was mentioned on IRC by either Coke or Particle, I had the the same
> idea.

We talked about that at OSCON. The problem is that it encourages people
to think of the body of transform rules as strings. They aren't strings,
they're code blocks.


that may be a perl5 way of looking at it, but having written countless
pir tests with heredoc syntax, i for one am used to thinking of them
as more than just strings. but as long as there's a syntax that works,
i don't really care what it looks like

 pir_output_is( <<'CODE', <<'OUTPUT', 'description' );
 .sub 'main' :main
   say 'ok 1'
 .end
 CODE
 ok 1
 OUTPUT

~jerry

Re: [perl #40002] TGE Refactor / Compiler Tools Object

[Patrick R. Michaud]

On Thu, Aug 03, 2006 at 11:21:57AM -0600, Kevin Tew wrote:
> Patrick R. Michaud via RT wrote:
> >
> >In discussions with Allison at OSCON, I noted that we needed to reconsider
> >the syntax slightly.  We don't want TGE to have to know how to parse every
> >language, and it may not be reasonable to expect every compiler to expose
> >a parser.  So, if we're going to allow other languages in the transform
> >bodies, we may want a "hereis" or podly {{...}}, {{{...}}} syntax to
> >delimit the transform bodies.  At the moment I'm leaning towards the 
> >{{...}}
> >form, if only because PGE is already using it.
> >
> >Pm
> >
> >  
> How about here doc style?
> This was mentioned on IRC by either Coke or Particle, I had the the same 
> idea.

Sorry, "heredoc" is what I meant by "hereis" above.  But yes, I'm thinking we'll
allow some form of heredoc.

Actually, {{, {{{,   may end up simply being shortcuts that say "heredoc 
with }}, }}}, 
as the end marker...".

Pm

Re: [perl #40002] TGE Refactor / Compiler Tools Object

[Allison Randal]

Kevin Tew wrote:
> Patrick R. Michaud via RT wrote:
>> So, if we're going to allow other languages in the transform
>> bodies, we may want a "hereis" or podly {{...}}, {{{...}}} syntax to
>> delimit the transform bodies.  At the moment I'm leaning towards the
>> {{...}} form, if only because PGE is already using it.

I'm comfortable with multiplying curly brackets. We may also ultimately
offer a "shorthand" form something like:

  t///

And allow all the perlish alternate delimiters.

> How about here doc style?
> This was mentioned on IRC by either Coke or Particle, I had the the same
> idea.

We talked about that at OSCON. The problem is that it encourages people
to think of the body of transform rules as strings. They aren't strings,
they're code blocks.

Allison

Re: [perl #40002] TGE Refactor / Compiler Tools Object

[Kevin Tew]

Patrick R. Michaud via RT wrote:


In discussions with Allison at OSCON, I noted that we needed to reconsider
the syntax slightly.  We don't want TGE to have to know how to parse every
language, and it may not be reasonable to expect every compiler to expose
a parser.  So, if we're going to allow other languages in the transform
bodies, we may want a "hereis" or podly {{...}}, {{{...}}} syntax to
delimit the transform bodies.  At the moment I'm leaning towards the {{...}}
form, if only because PGE is already using it.

Pm

  

How about here doc style?
This was mentioned on IRC by either Coke or Particle, I had the the same 
idea.

Parrot news: namespace ops good, (some) namespace methods bad; key-accepting ops

[Chip Salzenberg]

For those of you not watching the Parrot subversion log (and why not?):

 * Opcodes {get,make}*namespace and {get,set}*global again accept arrays of
   names in place of constant keys ...
 * ... obviating the corresponding Namespace PMC methods, which are now gone.
 * Time to 'make realclean'.

(And of course I repeat a gentle reminder that the old find_global and
store_global opcodes will eventually [eventually!] go away, so convert
to the {get,make}*namespace and {get,set}*global opcodes instead.)

In the process of the above change, these more fundamental low-level changes
were needed (or at least helpful):

 * Keys passed to opcodes as plain values -- i.e. as namespace or class
   identifier rather than for their classic indexing purpose -- are now
   encoded in opcodes differently, as "_pc" ("inconst PMC") rather than
   the historical and ambiguous "_kc" ("inconst KEY").

 * Therefore if you can get a Key PMC into a PMC register, many of the
   key-accepting opcodes will accept the key via the register.  However,
   some won't; see "Note" below.

 * Op parameters "in PMC" used to be silently treated as "invar PMC" (i.e.
   no PMC constants allowed).  This is no longer true.  However, most
   opcodes still behave just like before, thanks to a massive search-and-
   replace of "in PMC" with "invar PMC".

Note on an insteresting design issue: The new 'subclass' opcode variants
demonstrates the inherent ambiguity between class names and class PMCs;
merely being a PMC or not isn't enough to distinguish the intent of
specifying class vs. class name.  (Keys are PMCs.)  This should be resolved
in a general way for all class-accepting opcodes.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: RE: wiki

[Matt Todd]

IMHO, this isn't a matter of either-or, but of concurrent development along
2 related tracks:


You're right, it doesn't have to be either-or.


[snip]

It would be good to have (1) ASAP.

There's no reason that people who are interested in (2) have to be
interested in (1) or vice versa.


I agree that this makes sense, and if you did this it wouldn't be a
problem whatsoever. However, I think that, with rapid prototyping and
whatnot, we can actually get an original, minimal, working wiki, and
build from there. The database design will go together quickly, some
kind of architecture can go up quickly (scaffolding, if you will), and
then development on the most important, essential parts will come
first. Then, as the wiki is being used concurrently with the
development of it, you have a good deal of immediate feedback on
what's wrong and what needs to be changed.

But, really, that's my idea of how it should be done: I am neither the
one with the money, nor the one capable of doing it all on my own. I
just really loathe the idea of having to go from the one to the next,
when the latter will do what we need just as well with a little bit of
effort. It's important to start the project with a certain goal for
quality, but doing it rapidly.

But, as of right now, nobody's really been thinking the same (or those
that have haven't spoken up) so I can't get a community moving on it
just yet. And, personally, I've been pretty swamped with work so
learning Perl6 has been on the backburner (along with Haskell and
Scheme, unfortunately).

M.T.

RE: wiki

[Conrad Schneiker]

> From: Amir E. Aharoni [mailto:[EMAIL PROTECTED]
> 
> 2006/8/3, Matt Todd <[EMAIL PROTECTED]>:
> > I'll be honest, I was willing to put in some effort for something
> > substantial and original, but I'm not too keen on just remaking or
> > porting an old solution.

Please see my response below.

> Just in case i am misunderstood - i'm not talking about the platform,
> i'm talking about content. If there is content, it can be later
> converted to any great Perl 6 CMS - that's what we have Perl for in
> the first place.
> 
> I just think that the Exegeses and the Synopses can grow much faster in a
> wiki,
> even if the platform is not too cool initially.
> (MediaWiki is good enough for me.)
> 
> I'd gladly write documentation for Perl 6, but unfortunately i don't
> know it (yet) half as well as Perl 5. If there was a functioning wiki,
> i'd make at least small contributions, though 

Exactly.

IMHO, this isn't a matter of either-or, but of concurrent development along
2 related tracks:

(1) Installing some reasonable existing Wiki on feather. It would serve the
very valuable role of accumulating Perl 6 content, and would be the primary
*interim* Perl 6 *oriented* Wiki.

(2) Developing a *new* (substantially, increasingly) Perl 6 *based* Wiki on
feather. One of the design requirements would be some mechanism for
automatically porting its initial content from the *interim* Perl 6
*oriented* Wiki.

It would be good to have (1) ASAP. 

There's no reason that people who are interested in (2) have to be
interested in (1) or vice versa. 

Best regards,
Conrad Schneiker

http://perl.net.au/wiki/Perl_6_Users_FAQ (Moved from AthenaLab to Perl 6
Wiki.)

www.AthenaLab.com (Nano-electron-beam and micro-neutron-beam technology.)

Re: [perl #39905] [TODO] TGE - line number reporting.

[Will Coleda]

From docs/compiler_faq.pod:

=head2 How do I embed source locations in my code for debugging?

You can do this using either the C and C opcodes or
with C-like C<#line> comments:

  #line 27 "my_source.file"

Simply set the source file name or line number whenever it changes.
But note that currently (Parrot 0.3.0) both are ignored in the lexer.



On Aug 3, 2006, at 11:30 AM, Patrick R. Michaud wrote:


On Fri, Jul 21, 2006 at 03:03:07PM -0700, Will Coleda wrote:

# New Ticket Created by  Will Coleda
# Please include the string:  [perl #39905]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39905 >


Once a .tg file is compiled to a .pir file, any errors in the
embedded PIR are reported against the line number
of the generated PIR file.

Instead, the line numbers should be reported against the original .tg
file.


Is there an imcc pragma for setting the line number to be reported
for an error?  Or what's the general approach to getting the generated
PIR file to report the correct line number?

Pm



--
Will "Coke" Coleda
[EMAIL PROTECTED]

Re: [perl #39905] [TODO] TGE - line number reporting.

[Patrick R. Michaud]

On Fri, Jul 21, 2006 at 03:03:07PM -0700, Will Coleda wrote:
> # New Ticket Created by  Will Coleda 
> # Please include the string:  [perl #39905]
> # in the subject line of all future correspondence about this issue. 
> # http://rt.perl.org/rt3/Ticket/Display.html?id=39905 >
> 
> 
> Once a .tg file is compiled to a .pir file, any errors in the  
> embedded PIR are reported against the line number
> of the generated PIR file.
> 
> Instead, the line numbers should be reported against the original .tg  
> file.

Is there an imcc pragma for setting the line number to be reported
for an error?  Or what's the general approach to getting the generated
PIR file to report the correct line number?

Pm

RE: wiki

[Amir E. Aharoni]

2006/8/3, Matt Todd <[EMAIL PROTECTED]>:

I'll be honest, I was willing to put in some effort for something
substantial and original, but I'm not too keen on just remaking or
porting an old solution.

M.T.


Just in case i am misunderstood - i'm not talking about the platform,
i'm talking about content. If there is content, it can be later
converted to any great Perl 6 CMS - that's what we have Perl for in
the first place.

I just think that the Exegeses and the Synopses can grow much faster in a wiki,
even if the platform is not too cool initially.
(MediaWiki is good enough for me.)

I'd gladly write documentation for Perl 6, but unfortunately i don't
know it (yet) half as well as Perl 5. If there was a functioning wiki,
i'd make at least small contributions, though 

Re: RE: wiki

[Matt Todd]

I'll be honest, I was willing to put in some effort for something
substantial and original, but I'm not too keen on just remaking or
porting an old solution.

M.T.

Re: [perl #40002] TGE Refactor / Compiler Tools Object

[Patrick R. Michaud]

On Fri, Jul 28, 2006 at 08:43:27AM -0700, Kevin Tew wrote:
> 
> What bullet items will the TGE refactor consist of?

Keeping in mind that the "TGE refactor" really also includes refactoring
PAST and POST, we have...

> * better command-line arg processor, like getopts, but returning a capture

Yes.

> * optimization levels based on level, group related optimizations which 
> may occur during different transform steps

Eventually this will happen, but I don't know if it'll be in the first
round of refactoring.

> * support for languages other than PIR
> * generic PAST/POST nodes for short-circut ands and ors
> * basic conditional and case constructs, there exists a common semantic 
> for if/else, it should be represented in a common way in PAST
> * for and while loop generation

Yes, yes, yes, and yes.

> * label management.
> * scope management.

Scope management definitely in this first refactor; label management may
wait slightly (or I'll just invite someone else to do it :-).

> *38761 * *[TODO] 
> TGE, precompile more *

I'll wait and see on this one.

>   [EMAIL PROTECTED]
> *39831 * *TGE - 
> Needs more diagnostics on failure. 
> *

Definitely.

>   [EMAIL PROTECTED]
> *39854 * 
> *[PATCH] 
> adds preamble section to tge grammar to allow for includes and global 
> defines *

I'm working this one out.  There *will* be a way to set pragmas (e.g.,
so that the :language(...) modifier isn't specified on every transform).

>   [EMAIL PROTECTED]
> *39897 * 
> *[PATCH] 
> TGE - add basic syntax error 
> *
>   [EMAIL PROTECTED]
> *39905 * *[TODO] 
> TGE - line number reporting. 
> *

We'll definitely add better line number reporting.

>   [EMAIL PROTECTED]
> *39913 * *[BUG] 
> TGE - Can't use } in the transform definitions. 
> *

In discussions with Allison at OSCON, I noted that we needed to reconsider
the syntax slightly.  We don't want TGE to have to know how to parse every
language, and it may not be reasonable to expect every compiler to expose
a parser.  So, if we're going to allow other languages in the transform
bodies, we may want a "hereis" or podly {{...}}, {{{...}}} syntax to
delimit the transform bodies.  At the moment I'm leaning towards the {{...}}
form, if only because PGE is already using it.

Pm

Re: PGE/TGE and the future.

[Patrick R. Michaud]

On Fri, Jul 28, 2006 at 08:46:50AM -0600, Kevin Tew wrote:
> I'm seeking information regarding TGE's design goals, aspirations, 
> future plans, etc.
> 
> I see that Perl6 implements its own version of PAST and POST nodes.
> Is it possible to share basic PAST and POST nodes and extend them for 
> particular  HLL needs?
> I know that different HLLs  share a lot  of the same semantics, they 
> also have huge differences.

I'm in the process of unifying the various PAST implementations into a
common form that can (hopefully) be used by many languages.  The basics
will be available, but there will also be a way to add extensions or
override behaviors for various HLLs.

> If there is a common set of goals or objectives for compiler tools that 
> Cardinal can contribute to or utilize, I would like to do so.
> This is an offer to help build and test the compiler tools. :)
> 
> I just want to start a discussion about compiler tools and learn what 
> information, I've missed.

Excellent!  At the moment I'm working on updating the compiler tools
draft into an official PDD for comments and suggestion, as well as
putting some code that demonstrates the pieces.  Look for this in
the next five days or so!

Pm

Re: Initialization and Finalization hooks

[Leopold Toetsch]

Am Dienstag, 1. August 2006 23:21 schrieb Kevin Tew:
> Syntax:
>
> END '{' expr.. '}'
>
> Registers finalize routine. The block followed after |END| is evaluated
> just before the interpreter termination. Unlike |BEGIN|, |END| blocks
> shares their local variables, just like blocks.

I've put together the current possiblities to achieve the effect of END.
I don't know if it's sufficient, though.

See the last 5 or so t/pmc/exception.t or r13768 - r13770.

leo

Re: Array Definitions

[Audrey Tang]

在 2006/8/2 下午 2:48 時，Arthur Ramos Jr. 寫到：

I'm new to the mailing lists. I've just started reading all the  
Apocalypse and

Exegeses with the goal of becoming involved in some manner.


Try reading the Synopses first. :-)

The Apocalypses and Exegesis are no longer updated, and has diverged  
considerably with the current spec.



One question I have is
whether there will be a change to matrix coding. I'd personally  
like to see a

simplification from the C coding. For example:

Rather than (or in addition to) the C style:

array[0][1][2] = 42;

change it to (or allow the use of) the simplification:

array[0,1,2] = 42;


@array[0;1;2] is the current syntax; see S09 for details.

Cheers,
Audrey



PGP.sig
Description: This is a digitally signed message part

Array Definitions

[Arthur Ramos Jr.]

I'm new to the mailing lists. I've just started reading all the Apocalypse and 
Exegeses with the goal of becoming involved in some manner. One question I have 
is 
whether there will be a change to matrix coding. I'd personally like to see a 
simplification from the C coding. For example:

Rather than (or in addition to) the C style:

array[0][1][2] = 42;

change it to (or allow the use of) the simplification:

array[0,1,2] = 42;

Thank you for this consideration.

Sincerely,

Art Ramos
AKA lensman

Re: [perl #40030] [PATCH] compiler/imcc missing dependency

[Nick Glencross]

On 02/08/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

On 8/2/06, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>
> Am Mittwoch, 2. August 2006 19:52 schrieb [EMAIL PROTECTED]:
> > > There must be some other problem elsewhere.
> >
> > Found the problem... it was MY problem... I had rests of an old
> instalation
> > of parrot in my /usr/local/lib, and gcc was pulling libparrot from
> there,
> > making the hole process borked...
>
> Strange. I tried hard to resolve:
> http://rt.perl.org/rt3//Public/Bug/Display.html?id=39742
> and didn't see any bad interaction of an installed Parrot (albeit there
> are a
> lot of such reports, that there is one).


I don't really know how to solve this problem... AFAIK gcc pulls by default
libs from /usr/local/lib or /usr/lib as soon as you do -l... You can
pass -L/path to gcc, but maybe the deafult search paths has priority over
the hand-defined ones. Guess I'll have to digg it more...


I think that the comments in this entry are still valid.

  http://rt.perl.org/rt3/Public/Bug/Display.html?id=38217#txn-128692

There's was also a stab at a patch in r11320, but I botched it (in the
embedded interface) and it was reverted. It's still a good starting
point for anyone that would like to run with it,

Cheers,

Nick

random thoughts on making parrot compiler faster

[Joshua Hoblitt]

A significant portion of parrots build time is spent running
tools/build/pmc2c.pl & tools/build/c2str.pl.  Neither of these programs
loads Parrot::Config and there isn't/shouldn't be any system dependent
behavior.  Does it make sense for the code generation to be a
--maintainer processes only?

-J

--


pgphkpvJd1LJf.pgp
Description: PGP signature

RE: wiki

[Conrad Schneiker]

> From: Amir E. Aharoni
>
> There was so much talk about perl6 wiki, that i couldn't follow
> it anymore.
> 
> Is there a currently working wiki where actual perl6 documentation can
> be read/written?

Not that I know of, at least not in the sense of being a widely-accepted and
presently-active focal point of such activity.
 
> Is it http://perl.net.au/wiki/ ? It doesn't seem to be very full
> of info ...

No one has come up with a better alternative, AFAIK. There seems to be
substantial reluctance to use anything that isn't Perl-based and isn't a
semi-ultimate venue.

If someone put an existing Perl-based Wiki on (say) feather (a Perl 6
development machine), that might be sufficiently widely appealing to take
off, usage-wise. Juerd has a perl6 URL that he offered for the Perl6
implementation of a Perl6 Wiki that he might be willing to make available
for such an interim Wiki. 

Best regards,
Conrad Schneiker

http://perl.net.au/wiki/Perl_6_Users_FAQ (Moved from AthenaLab to Perl 6
Wiki.)

www.AthenaLab.com (Nano-electron-beam and micro-neutron-beam technology.)