Parrot Libraries
Leopold Toetsch
- runtime/parrot/*/
- library/
1) We should probably decide to use just one for simplicity.
2) Library search paths and appropriate helper functions inside Parrot
are still needed.
3) we need some scheme to organize lib paths
4) Library testing is needed as well
Comments welcome,
leo
Jens Rieks
On Wednesday 07 April 2004 08:50, Leopold Toetsch wrote:
> - runtime/parrot/*/
This directory does only include generated files, doesn't it?
> - library/
Maybe move it to runtime/library?
We can also create a runtime/t/ (or t/runtime) where the library tests can go
to.
> 1) We should probably decide to use just one for simplicity.
ack
> 2) Library search paths and appropriate helper functions inside Parrot
> are still needed.
What about an PMC array? Each PMC can then represent a directory
Parrot does the C equivalent of "set file, dir[name]", if the file returned
is a ParrotIO it is used to read the library file.
> 3) we need some scheme to organize lib paths
What about
runtime/parrot for parrot's generated files
runtime/library for PIR/PASM libs working "out of the box" parrot
directories like runtime/perl6, runtime/tcl...
for other languages and everything that needs a special backend to be usable
the backend can just add the runtime path to parrot's library path
> 4) Library testing is needed as well
indeed.
is it okay to use (e.g. the streams) examples as test basis?
A test can then simply include the example code and check its output.
This way, we know that the examples are working and do not have duplicated
code. On the other hand, it can make problems if someone modifies an example
and then runs the tests.
jens
Leopold Toetsch
> Hi,
> On Wednesday 07 April 2004 08:50, Leopold Toetsch wrote:
>> - runtime/parrot/*/
> This directory does only include generated files, doesn't it?
Almost. We have in CVS:
- runtime/parrot/include/DWIM.imc
- runtime/parrot/include/Getopt_Long.imc
- runtime/parrot/chartypes/*.TXT
- runtime/parrot/include/*.pasm is autogenerated
>> - library/
> Maybe move it to runtime/library?
or runtime/parrot/lib
> We can also create a runtime/t/ (or t/runtime) where the library tests
> can go to.
or runtime/parrot/t
>> 1) We should probably decide to use just one for simplicity.
> ack
>> 2) Library search paths and appropriate helper functions inside Parrot
>> are still needed.
> What about an PMC array? Each PMC can then represent a directory
Yep.
> Parrot does the C equivalent of "set file, dir[name]", if the file returned
> is a ParrotIO it is used to read the library file.
This still needs platform support for e.g. path_concat(path, file)
>> 3) we need some scheme to organize lib paths
> What about
> runtime/parrot for parrot's generated files
Generated or not doesn't matter. Both must be present at runtime.
> directories like runtime/perl6, runtime/tcl...
Yep.
>> 4) Library testing is needed as well
> indeed.
> is it okay to use (e.g. the streams) examples as test basis?
Sure. Test is test. But more low-level stuff is needed to. Examples
start with to much of functionality normally.
> jens
leo
Dan Sugalski
>We still have two locations for runtime stuff:
>- runtime/parrot/*/
>- library/
Let's move everything to runtime/parrot
>1) We should probably decide to use just one for simplicity.
>2) Library search paths and appropriate helper functions inside
>Parrot are still needed.
Yeah. I see the discussion of that died :(
>3) we need some scheme to organize lib paths
We might want to think about library metadata as well. I'm
half-tempted to go with a full-blown database of installed modules
rather than play "walk the filesystem" games.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Jens Rieks
> At 8:50 AM +0200 4/7/04, Leopold Toetsch wrote:
> >We still have two locations for runtime stuff:
> >- runtime/parrot/*/
> >- library/
>
> Let's move everything to runtime/parrot
> >1) We should probably decide to use just one for simplicity.
> >2) Library search paths and appropriate helper functions inside
> >Parrot are still needed.
>
> Yeah. I see the discussion of that died :(
>
> >3) we need some scheme to organize lib paths
>
> We might want to think about library metadata as well. I'm
> half-tempted to go with a full-blown database of installed modules
> rather than play "walk the filesystem" games.
Maybe a bit overkill, but what about SQLite?
jens
Dan Sugalski
Definitely overkill. We want something that we can map in and get
access to quickly, with a minimum of fuss. I was thinking more like a
chunk of bytecode with a frozen data structure in it. I'm not sure we
want to be making SQL queries every time we do a use or require. (On
the other hand, it may come to a point where that's the reasonable
thing to do, though I think I shall be very scared... :)
Jens Rieks
On Wednesday 07 April 2004 12:48, Leopold Toetsch wrote:
> > We can also create a runtime/t/ (or t/runtime) where the library tests
> > can go to.
>
> or runtime/parrot/t
Where should the tests go to? I'll move them then, and add some more tests for
the other libraries.
After thinking a bit more about it, I vote for t/library. Putting them into
the runtime directory is IMO not so good because they are not needed at
runtime.
jens