Call for B0rked
Chromatic
In a recent discussion with Chip and Leo, the idea came up to ask for a
list of very specific TODO items -- specifically things that should work
but don't.
We'll gather a list and figure out what's up, whether someone fixed it
since then, whether the docs are misleading, or whether it's still in a
state of brokenness. Here's your chance to say "Hm, I tried this and
thought it should work but it blew up and I don't know what to do."
I know Autrijus at YAPC::NA mentioned that the lexical implementation
didn't really work.
I think that nested ManagedStruct and UnManagedStruct PMCs share state
between them, so you can't have two independent data structures -- but
I'm not completely sure.
Anything else?
-- c
Will Coleda
parrot/Overview.html, as well as in docs/ROADMAP
However, I vote for the following, which are more specific:
Unfinished Opcodes:
https://rt.perl.org/rt3//Ticket/Display.html?id=32544 (split) [should
be doable if we s/regexp/perl 6 rule/ and use PGE.]
Missing Vtables:
o https://rt.perl.org/rt3//Ticket/Display.html?id=31867
(ResizablePMCArray)
o https://rt.perl.org/rt3//Ticket/Display.html?id=32374
(ResizableIntegerArray)
o https://rt.perl.org/rt3//Ticket/Display.html?id=34394 (splice)
Missing PDDs:
o https://rt.perl.org/rt3//Ticket/Display.html?id=33918 (PDD 10)
o https://rt.perl.org/rt3//Ticket/Display.html?id=33919 (PDD 12)
o https://rt.perl.org/rt3//Ticket/Display.html?id=33920 (PDD 13)
Make Perl a /language:
o https://rt.perl.org/rt3//Ticket/Display.html?id=32642 (don't have
perl deps in static classes)
o https://rt.perl.org/rt3//Ticket/Display.html?id=32646 (make Perl
PMCs dynamic)
this touches the related but more vague:
o https://rt.perl.org/rt3//Ticket/Display.html?id=31633 (let
languages be self contained - right now many languages are in the
manifest, using the global config, etc. as far as perl goes, this
could let us move perl PMCs into languages/perl[6]).
Misc:
o generate accurate file/line number information in stack traces.
(ISTR this was still b0rked.)
o https://rt.perl.org/rt3//Ticket/Display.html?id=33923 (get name of
parrot executable)
o Namespaces: I think Matt Diephouse is preparing an email on this.
(Thanks, Matt!)
o Give invokable PMCs a canonical way to store their associated HLL
source and argument information. (I probably owe an email about this.
Ping me if you want it sooner than later.)
o Add rules engines for perl5-ish RE's in PGE: (I specifically want
http://www.tcl.tk/man/tcl8.5/TclCmd/re_syntax.htm, but having a perl5-
ish one I can subclass would be just dandy. =-)
Hope this helps!
Matt Diephouse
> In a recent discussion with Chip and Leo, the idea came up to ask for a
> list of very specific TODO items -- specifically things that should work
> but don't.
AFAICT, there's currently no support for:
- Lexical/anonymous classes
- Submethods
It's possible that there's a way to emulate these or that I've just
missed how they would be done.
Also, is rx.ops obsolete? PGE seems to be the new solution. If so, can
we get rid of rx.ops? Or is rx.ops still going to be used for
something?
--
matt diephouse
http://matt.diephouse.com
Patrick R. Michaud
>
> However, I vote for the following, which are more specific:
>
> Unfinished Opcodes:
>
> https://rt.perl.org/rt3//Ticket/Display.html?id=32544 (split) [should
> be doable if we s/regexp/perl 6 rule/ and use PGE.]
In recent discussions (and for a variety of reasons) I've been advocating
that the definition of the split opcode should be modified so that
it separates based on a constant string rather than a regular
expression or perl 6 rule. There are several places where this
would be helpful to PGE, and separating on constant strings ought to
be optimizable to be a lot faster than what a p6 rule can do.
For splitting on regular expressions, PGE can then provide its own
split method or function that doesn't require hooking into the
opcode vtable. What's more, it would potentially be able to do
splits on any pattern expression, not just those written with perl 6
rules syntax.
> o Add rules engines for perl5-ish RE's in PGE: (I specifically want
> http://www.tcl.tk/man/tcl8.5/TclCmd/re_syntax.htm, but having a perl5-
> ish one I can subclass would be just dandy. =-)
Oh, we can probably work on this one. :-)
Pm
Tim Bunce
> Hi all,
>
> In a recent discussion with Chip and Leo, the idea came up to ask for a
> list of very specific TODO items -- specifically things that should work
> but don't.
Not very specific, but: "whatever Ponie needs most".
I'm sure Nicholas can come up with something more specific!
Tim.
Joshua Hoblitt
probably a large group of people that would like to contribute a few
hours per work to Parrot development but that there are no TODO tasks
that can be done reasonable accomplished at that level of commitment.
Chip stated that my he feels my position is incorrect and that there are
probably a lot of people that could contribute but are merely unaware of
this fact. So I've spent some time digging through the TODO items and,
by my estimates, none of the items as defined could be reasonably
completed in a few hours (excluding Leo). So what exactly am I
proposing? I'd like to add the TODO list to the TODO list. ;)
Specifically, all of the TODO items should be decomposed into well
defined tasks that could be completed in N hours or less. Where 4 is
probably a good value for N.
Cheers,
-J
--
On Wed, Aug 31, 2005 at 04:04:45PM -0700, chromatic wrote:
Andy Dougherty
> Hi all,
>
> In a recent discussion with Chip and Leo, the idea came up to ask for a
> list of very specific TODO items -- specifically things that should work
> but don't.
It should be possible to Configure and build parrot with a compiler other
than the one that built the underlying perl. Even with --ask, Parrot
insists on picking up inappropriate items from the perl5 %Config.
--
Andy Dougherty doug...@lafayette.edu
Leopold Toetsch
> For splitting on regular expressions, PGE can then provide its own
> split method or function
^^^^^^
Sic. C<split> shouldn't be an opcode at all. It's a library function or
more specifically a method inside some namespace. E.g.
String.split
Rule.split
...
But that's more like an implementation detail, which means, what
currently looks like the C<split> opcode will eventually dispatch to a
class implementing a C<split> method.
> Pm
leo
Leopold Toetsch
$ perl Configure.pl cc=XX cxx=XX link=XX ld=XX
should do it. But selecting just a different 'cc' should be enough to
default all to the new C compiler.
leo
Andy Dougherty
Yes, I agree that *should* do it. My point is it *doesn't* work.
--
Andy Dougherty doug...@lafayette.edu
Leopold Toetsch
> AFAICT, there's currently no support for:
>
> - Lexical/anonymous classes
> - Submethods
Yep.
> Also, is rx.ops obsolete? PGE seems to be the new solution. If so, can
> we get rid of rx.ops? Or is rx.ops still going to be used for
> something?
rx_ opcodes are broken for several reasons: they are non-reentrant due
to the usage of IntStack and because there is no state kept. The
character class handling leaks memory like a sieve. The opcodes could
probably just get removed. OTOH we might eventually collect common PGE
sequences into quite similar opcodes (w/o the bugs of course).
leo
Leopold Toetsch
> Hi all,
>
> In a recent discussion with Chip and Leo, the idea came up to ask for a
> list of very specific TODO items -- specifically things that should work
> but don't.
Some of the items in this thread are TODOs, some bugs, and some could be
noops. I'll try to classify items in this thread.
> I know Autrijus at YAPC::NA mentioned that the lexical implementation
> didn't really work.
Lexicals are subject to an upcoming design document. While the
implementation basically works, it doesn't really fit into HLLs
expectations. The static, compiler-visible lexicals of one sub can be
"flattened" and will be directly mapped to Parrot registers. The current
approach of fully dynamic lexicals can be minimized, depending on the
strict-ness of the HLL.
> I think that nested ManagedStruct and UnManagedStruct PMCs share state
> between them, so you can't have two independent data structures -- but
> I'm not completely sure.
Not AFAIK. A *Struct PMC holds the names and offsets of one C structure.
Nested structures aren't really different here, there is just another
*Struct PMC for the nested structure. The ManagedStruct owns
additionally the memory occupied by the structure, while the
UnManagedStruct points to memory external to Parrot.
> -- c
leo
Leopold Toetsch
> Is it just me or is it b0rked to have a file named src/parrot.c that
> does nothing while the entry point for the parrot executable lives in
> imcc/main.c?
Around 2 years ago test_main.c was Parrot's main and imcc was a
standalone PIR->PASM translator. With the integration of imcc, Parrot
got embedded into the latter and imcc/main.c became the main entrypoint.
But this is probably just an intermediate step. Parrot integrates
currently three "compilers": PASM, PIR, and PAST. But compilers can be
registered at runtime too. Therefore Parrot startup will eventually look
like this:
- start main in src/parrot.c
- determine source file type to compile/run
- handle execution over to xxx-compiler or to pbc-run.
leo
Matt Diephouse
> > Also, is rx.ops obsolete? PGE seems to be the new solution. If so, can
> > we get rid of rx.ops? Or is rx.ops still going to be used for
> > something?
>
> rx_ opcodes are broken for several reasons: they are non-reentrant due
> to the usage of IntStack and because there is no state kept. The
> character class handling leaks memory like a sieve. The opcodes could
> probably just get removed. OTOH we might eventually collect common PGE
> sequences into quite similar opcodes (w/o the bugs of course).
In that case, I vote we remove them. There's no sense keeping them
around when we have svn. This will have the added benefit of speeding
up compilation (especially the computed goto core) on some platforms.
Patrick R. Michaud
I vote to remove them also. I don't have any plans to use them
within PGE -- my preference would be to do some analysis of PGE
code generation and execution (and other modules similar to that),
then build opcodes that optimize that.
Pm