Dan Sugalski <[EMAIL PROTECTED]> writes: > >The ability to embed arbitrary data in a pbc file under a > >named section. This data needs to be readable by the program > >when it runs, but is otherwise ignored by the rest of Parrot. > > Right, good call. This'll make perl's named embedded filehandles > (__DATA__ and suchlike things--I'm pretty sure Larry and Damian have > Evil Things in mind for this at some point in perl 6) a lot easier as > well.
My proposed extension of the packfile format is going in this direction. But I'm not sure at the moment not sure about string encodings in the segment directory. I was thinking about limiting to ASCII because its an internal. Allowing diffrent encodings opens a can of worms. UTF-8 only may also be a possiblity. Furthermore a part of the namespace should be reserved for internal use only. ATM I use all-caps names, but think also about dot-prefix. > A binary data chunk section with named directory for it (per bytecode > segment, I think) would work pretty well for this. I'm not sure if I understand you correctly: You talk about more than one bytecode segment in a packfile and each of them has its own associated directory with independed namespace. Trickey. But it should be possible. Having a root directory segment and sub directories. > I don't think we'll > need it writable, though. Hopefully not, though there is the potential > for interesting things if it is. The main problem with writing to a pbc is the concurrend access. You need some kind of locking. But for read-only access no write should be required so you will never know if some other process is reading the file you want to change, and the reading process has no chance to be sure that the file will not change. But it would be nice if you could write a new packfile. This would be very handy for writing compilers. bye b.
