> 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 foc
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
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 ol
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
在 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
co
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 p
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.
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 co
> 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.
>
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
> p
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.
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 fil
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 currentl
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
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'.
(An
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
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
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
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 lean
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
Extern functions and variables must have names that begin with C.
--
Chip Salzenberg <[EMAIL PROTECTED]>
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
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
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 f
# 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
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]>
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 th
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
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
# 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
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 c
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
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
# 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 <[EMAI
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
# 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 exte
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]>
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
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]>
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
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
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
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?
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 sor
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/
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
>
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, "fi
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 Ch
# 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 worki
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
# 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 t
This ticket now depends on ResizeableBooleanArray rewrite.
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.
Fixed in svn.
Actual bug was causing malloc(0).
Proximate bug is that, on tru64, malloc(0) fails. :-)
parrot obeys you
when you ask it politely
to halt and catch fire
Fixed in svn by deleting that never-will-work-again japh,
which hacked internals in an amazingly evil way.
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
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]>
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,
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
bio
60 matches
Mail list logo
