some goals for the next release
Leopold Toetsch
* namespaces: create a PDD based on Matt's document
* interfaces: start some brainstorming, what we might need in Parrot
core
* bytecode & library loading: needs rewriting and major cleanup
* config module cleanup: auto/jit.pm and gen/icu.pm comes to my mind
(and why /gen anyway?)
Something else?
Enough, I think, in combination with other already ongoing stuff,
leo
Roger Browne
I would be pleased to have a design decision made regarding inheritance
of attributes in Parrot objects.
See the last few comments here:
https://rt.perl.org/rt3/Ticket/Display.html?id=36411
for the design questions that arose.
Regards,
Roger Browne
Joshua Hoblitt
> This is an unordered collection of my thoughts towards a next release:
Not just the steps themselves need work, there is still some fairly
substantial work left to be done on the configure framework as part of
my refactoring project. This has been going rather slowly because it's
usually bad to major radical changes to a build system as things always
break, my available tuits have been rather low lately, and this isn't
'test driven development' so I'm having to be doubly cautious about
breakage on platforms I don't have access too. My Parrot tuits
situation should be improved for the last week of December (a
'vacation') and I'm hoping to complete most if not all of the
refactoring work then.
A summary of what's been done so far:
- All of the steps have been renamed from a .pl -> .pm file extension
(that was not as trivial as I had hoped)
- The Configure::Data class is no longer created as part of a step and
now lives under lib/. It's been partially cleaned up renamed to
Parrot::Configure::Data.
- All of the steps now inherit from Parrot::Configure::Step::Base.
- A step's description and result text and now retrieved via class
methods.
- The $(MAKE_C) abomination has been removed from the Makefile templates
and a Make configure step as been added.
- Some work has been done towards getting `make -jN` to work (almost
there)
What still needs to be done:
- The framework itself needs tests!!!
- Each step needs to have it's own namespace. This is when the switch
to Module::Pluggable will happen.
- Parrot::Configure::Step needs to be cleaned up.
- Most of the steps need both style and logical clean ups.
- It should be possible to specify the paths to all utilities via
environment variables. Similar to how the new probes for lex and yacc
work.
- Parrot::Configure::RunSteps renamed to Parrot::Configure and the list
of steps to be run moved into Configure.pl
- Steps need an option passing mechanism to specifying things like, we
require versions x, y or z of flex (or fail). This means reworking
the way CLI options are passed into tests.
- A clean bailout mechanisms. Currently there is no 'nice' way for a
step to signal a failure, configuration always proceeds.
- CLI options need some minor tweaks
- Many steps should be broken up
- The debugging traces could be neater
- A usable log file would be handy
- Makefile dependencies still aren't being setup rigorously
- Last but not least, Leo's point about reviewing what the configuration
steps are actually doing.
Cheers,
-J
--
Jonathan Worthington
> * interfaces: start some brainstorming, what we might need in Parrot core
translator. Also I would really like to have support for:-
* Static methods
* Class level attributes (associated with the class, not the object - these
may be possible already though?)
* Abstract classes
> * bytecode & library loading: needs rewriting and major cleanup
Sure. And I'm tempted to put off the HLL debug stuff and start shuffling
some packfile code into PMCs (cleaning it up in the process), as we
discussed way back at YAPC::EU. Otherwise it'll just me more code to
re-work later. Ah, and uni is over for a month and a bit, so I got tuits
again. Yay!
Jonathan
Jerry Gay
> Not just the steps themselves need work, there is still some fairly
> substantial work left to be done on the configure framework as part of
> my refactoring project. This has been going rather slowly because it's
> usually bad to major radical changes to a build system as things always
> break, my available tuits have been rather low lately, and this isn't
> 'test driven development' so I'm having to be doubly cautious about
> breakage on platforms I don't have access too. My Parrot tuits
> situation should be improved for the last week of December (a
> 'vacation') and I'm hoping to complete most if not all of the
> refactoring work then.
>
<snip what's been done>
> What still needs to be done:
>
> - The framework itself needs tests!!!
>
> - Each step needs to have it's own namespace. This is when the switch
> to Module::Pluggable will happen.
>
> - Parrot::Configure::Step needs to be cleaned up.
>
> - Most of the steps need both style and logical clean ups.
>
> - It should be possible to specify the paths to all utilities via
> environment variables. Similar to how the new probes for lex and yacc
> work.
>
> - Parrot::Configure::RunSteps renamed to Parrot::Configure and the list
> of steps to be run moved into Configure.pl
>
> - Steps need an option passing mechanism to specifying things like, we
> require versions x, y or z of flex (or fail). This means reworking
> the way CLI options are passed into tests.
>
> - A clean bailout mechanisms. Currently there is no 'nice' way for a
> step to signal a failure, configuration always proceeds.
>
> - CLI options need some minor tweaks
>
> - Many steps should be broken up
>
> - The debugging traces could be neater
>
> - A usable log file would be handy
>
> - Makefile dependencies still aren't being setup rigorously
>
> - Last but not least, Leo's point about reviewing what the configuration
> steps are actually doing.
>
wow... that's a lot of work. of course, the configure system is quite
complex. might i suggest you break this down into bite sized chunks
and create tickets for them? it seems some of these are pretty
straightforward tasks that might be attacked by anyone with perl skils
and tuits. in particular, i have a feeling there are quite a few
lurkers out there--this may be a way to get some of them involved.
also, it seems the setup of makefile dependencies is not directly
related to the configure refactoring. there is currently one step:
generate all makefiles. splitting this out into *at least* two steps
(core makefiles, languages makefiles) is important for HLL designers,
who must suffer through a parrot rebuild when their language makefiles
change. but the makefile dependency changes, i feel, will happen
parallel to the configure effort, as i think my project to shuffle
directories around will affect this.
~jerry
Andy Dougherty
> What still needs to be done:
> - CLI options need some minor tweaks
I think they need some major design. In particular, it would be
nice to have a documented consistent interface to setting or
unsetting various things. Then, it would be *very* nice to have a
glossary somewhere (e.g. like perl5's Porting/Glossary.pod) that defined
what all the various things are the could be set.
Here's an example: Recent changes broke jit compilation on SPARC. How
can I re-configure so that parrot tries to build without jit? Running
Configure.pl --help gives the following promising-looking option:
--jitcapable Use JIT
But how do you turn it off? Do you use --no-jitcapable?
--jitcapable=undef? --nojitcapable? --jitcapable=0?
Short of actually reading the code, there's no way to know.
I happen to like perl5's Configure -D and Configure -U option syntax, but
I can imagine other syntax too, as long as it's consistent, documented,
and easy-to-use.
> - The debugging traces could be neater
>
> - A usable log file would be handy
>
> - Makefile dependencies still aren't being setup rigorously
>
> - Last but not least, Leo's point about reviewing what the configuration
> steps are actually doing.
I'd also add:
- An option to just run the generation phase. For example, suppose
you're working on fixing up the makefile root.in. It'd be nice to just
run Configure.pl --generate (or some such) and have it regenerate the
generated files without having to go through and re-run all of the
Configure.pl tests.
--
Andy Dougherty doug...@lafayette.edu