This post may cover lots of separate issues, but they interact and big
picture clarity would be useful. Appologies if some issues have been
resolved and I havent read enough to know better.
Some assumptions:
Parrot will be used in several independent spaces.
Apart from the perl6 space, it would be ideal as the underlying
engine for Mozilla scripting.
(I am unaware about how parrot is regarded in other language
communities to understand whether it will be develop into an essential
part of their community - in the same way as parrot is vital to perl6 -
or whether it is an interesting feasibility project)
Developers in independent spaces may/will not know or care about needs
in other spaces.
As Parrot evolves there will be increasingly more add-ons / languages
Some problems I have faced:
Getting all the right links right is frustrating
I was trying to get the SDL examples to work, which required a
specifically named links to two libraries AND the existence of a ttf
font in the path.
Configuration
Different problem spaces will require different configurations and
environments (by which here I take to mean libraries that are developed
independently from Parrot, eg. Gtk).
I dont think it is possible to decide upon a base set of libraries to
probe for. What is essential for one problem space is irrelevant for
another. Compromising and including both is not an elegant solution,
leading to bloat and increased startup times.
I suggest a configuration file that lists the libraries and dependencies
to be probed for when parrot starts up. If the configuration file also
provides helpful error messages when a probe does not work, that will
aid when dependencies need to be added to a system.
It is possible that each library/module could have its own configuration
file and initiation, or that a single configuration file is maintained
for Parrot and when new modules/packages are installed into a local
system, the configuation file is modified.
To my way of thinking: Windows uses the centralised approach with the
registry; unixen use both centralised configs in /etc and local ones
typically as ~/.configurations
Whereas a centralised configuration file means you know where to go to
do something, they get complex and accrete cruft. A distributed system
allows software to put stuff all over the place and I sometimes can work
out where to go or what to change. So there are pluses and minuses to both.
A policy set now by the Parrot development team would be very effective
in guiding the development of parrot in the way it interacts with its
environment. The policy does not have to be perfect, just flexible.
Base Libraries
I suggest that NO base libraries are expected by Parrot.
Parrot should only have a pluggable means for testing for libraries via
the configuration. All libraries would then have to conform to some set
of standards.
It is for a distribution to include libraries and the appropriate
configuration file.
A clear policy by the Parrot development team about what a base library
should look like and where it should be located will allow for
flexibility and the ability for developers to pick and choose.
Aviary
Parrot needs an analog to CPAN. Since all the variants of Parrot tend to
get bird-like names, an aviary is where birds are kept.
An effective on-line repository system will enhance the widespread
utilisation of Parrot
There was/is a long discussion in perl6 land about where CPAN should go
for perl6. There are several issues (that I have been able to
disentangle, but there may be more).
a) The structure of the local directory tree where dependencies /
libraries should reside (this is somewhat OS dependent)
b) The way the components are packaged in the central repository
c) What is packaged in the central library - viz., source or binary
d) resolution of dependency questions (other packages that the target
package relies on)
e) resolution of versionning questions (which versions of the target
package exist on the archive)
f) resolution of authorisation questions (is a package safe to use)
g) installation - the process by which a new module/library/package is
installed locally, and dependencies are identified so that they can be
installed as well.
I would recommend that the Parrot developers take the opportunity now to
develop policies about the above as it will encourage diversity of
development and use.
Respectfully,
Richard
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
