Parrot Runtime Library
Andrew Whitworth
runtime/parrot/library/*. Some of these such as distutils and nciutils
are pretty important prerequisites for many other ecosystem projects.
Distutils relies on a variety of libraries (osutils, lwp, http,
archive, etc) to do it's work so they are used anywhere distutils is.
There are some libraries, on the other hand, that I can't really find
anywhere that they are used. Some of the libraries we offer are
extremely old, written in very old PIR (or even raw PASM!) syntax.
They are not easy to maintain and are not really serving as good
examples for how to write a language-agnostic bytecode library for
Parrot's ecosystem. In addition building all these files that nobody
uses adds to the total build time, and tests for these libraries add
non-negligible time to "make test".
I propose we review these libraries. The ones that aren't being used
should be deleted or moved out to external repos. The ones that are
being used may be good candidates to re-write in something better than
PIR (Winxed and NQP are obvious alternatives). Here's a quick initial
list of libraries that I think we can delete or move to an external
location:
GCI
Iter
Math
OpenGL
Parrot (runtime/parrot/library/Parrot, not the VM)
parrotlib
Pg
Range
SDL
Stream
String
Tcl
I would love to hear what other people think about these files.
--Andrew Whitworth
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
Jonathan "Duke" Leto
In general, I am +1 to moving stuff out of core but not deleting,
unless the thing is untested/broken, then I am +1 to deletion.
In general, I am +1 to translating hand-coded PASM to PIR or Winxed in
our libraries.
One other thing to take note of:
Some of these elderly libraries may be very valuable for our test
coverage, we should monitor how removing them changes our test
coverage.
Another question: Does Rakudo or other HLLs use any of the stuff on
the proposed chopping block?
Duke
--
Jonathan "Duke" Leto <jona...@leto.net>
Leto Labs LLC
209.691.DUKE // http://labs.leto.net
NOTE: Personal email is only checked twice a day at 10am/2pm PST,
please call/text for time-sensitive matters.
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
Moritz Lenz
Am 21.03.2012 13:58, schrieb Andrew Whitworth:
> Pg
...
> I would love to hear what other people think about these files.
I have tried to use the Pg lib to make a Perl 6 module that interfaces
with postgres. I've written a number of tickets about it (I specifically
remember some instabilities, and the inabiilty to report errors properly).
As it is, it's not very useful, but it could be, if anybody ever got
around to maintain it. I'd really appreciate that.
Roughly the same can be said about OpenGL: if it worked, it would be
very interesting from a Perl 6 perspective. The last few times I've
tried to run some OpenGL examples, I was rather underwhelmed though (and
even if it worked for me, at least half of those on #perl6 who tried it
didn't get it to run).
IMHO all the other libraries can go away.
Cheers,
Moritz
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
Andrew Whitworth
> I have tried to use the Pg lib to make a Perl 6 module that interfaces with
> postgres. I've written a number of tickets about it (I specifically remember
> some instabilities, and the inabiilty to report errors properly).
>
> As it is, it's not very useful, but it could be, if anybody ever got around
> to maintain it. I'd really appreciate that.
There is a PL/Parrot project in the ecosystem which is probably a
better home for this module than the parrot core repo. If it's going
to get any love at all, that's where it would happen.
> Roughly the same can be said about OpenGL: if it worked, it would be very
> interesting from a Perl 6 perspective. The last few times I've tried to run
> some OpenGL examples, I was rather underwhelmed though (and even if it
> worked for me, at least half of those on #perl6 who tried it didn't get it
> to run).
I was under the impression that we had a separate OpenGL-related repo
somewhere but I can't find it now. I might be wrong. In either case a
graphics-related library might very well do better as a separate repo.
Christoph Otto
> On Wed, Mar 21, 2012 at 9:51 AM, Moritz Lenz
> <mor...@faui2k3.org> wrote:
> > I have tried to use the Pg lib to make a Perl 6 module that
> > interfaces with postgres. I've written a number of tickets about it
> > (I specifically remember some instabilities, and the inabiilty to
> > report errors properly).
> >
> > As it is, it's not very useful, but it could be, if anybody ever got
> > around to maintain it. I'd really appreciate that.
>
> There is a PL/Parrot project in the ecosystem which is probably a
> better home for this module than the parrot core repo. If it's going
> to get any love at all, that's where it would happen.
If Parrot's intended as a foundation for HLLs and libraries, we should
only keep libraries in core that match one of the following criteria:
The library should be necessary for the Parrot build, be something
that we expect most HLLs to use as-is, or show library hackers how to
do something that they'd have trouble finding elsewhere. I'm happy
moving anything else into a separate repo, either a junk drawer or a
dedicated project.
As an aside, I'm more than happy to see such projects added to
all_hll_test (which we can rename to test_all_the_things or something
more appropriate) so that they're less likely to end up bitrotted.
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
Andrew Whitworth
either directly translated into winxed or replaced with something
similar-but-better. I keep that project pretty well tested and
maintained, although it's not a suitable home for all these things (Pg
and OpenGL being two obvious examples that don't belong).
If we add these projects to the test_all_* make target, and include
them in plumage for easy access, I don't see there being any real
hardship.
Having criteria laid out for library inclusion is a good thing. cotto++
--Andrew Whitworth
Allison Randal
>
> If Parrot's intended as a foundation for HLLs and libraries, we should
> only keep libraries in core that match one of the following criteria:
> The library should be necessary for the Parrot build, be something
> that we expect most HLLs to use as-is, or show library hackers how to
> do something that they'd have trouble finding elsewhere. I'm happy
> moving anything else into a separate repo, either a junk drawer or a
> dedicated project.
+1 to clearing out unused/unmaintained libraries. In the Debian/Ubuntu
packages I don't install the full Parrot library, I only install:
Test/*
Data/*
dumper.pir
dumper.pbc
Getopt/Obj.pbc
distutils.pbc
HLL.pbc
Regex.pbc
P6Regex.pbc
PCT.pbc
PCT/*
P6object.pbc
Parrot/Exception.pbc
config.pir
config.pbc
nqp-setting.pbc
opsc.pbc
PGE.pbc
PGE/*
TGE.pbc
This is a carefully grown list starting with an absolute minimum, and
adding over the years as various languages complain that they need X or
Y library to build or run. I imagine even some of those could be deleted
or moved to separate repos now, as various toolkits and language
implementations have changed their dependencies. I'd be happy to
volunteer TGE for the chopping block.
I'm also happy to help any of the new separate libraries in setting up
their Debian/Ubuntu packaging so they can be easily pulled in as
automatic dependencies.
Allison
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
NotFound
> Roughly the same can be said about OpenGL: if it worked, it would be
> very interesting from a Perl 6 perspective. The last few times I've
> tried to run some OpenGL examples, I was rather underwhelmed though (and
> even if it worked for me, at least half of those on #perl6 who tried it
> didn't get it to run).
The opengl examples in the winxed repo works fine:
examples/fly.winxed
examples/glcubes.winxed
examples/opengl.winxed
--
Salu2
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
Jonathan "Duke" Leto
Just as a datapoint, I think our OpenGL support is very fragile
depending on the exact version and implementation of OpenGL that is
installed. Our configure system could probably get smarter to make
sure the proper versions, header files, extensions/etc are available.
Duke
--