[perl #39986] Create Default PackFile for New Interpreter (Parrot C API)

[Chromatic]

# New Ticket Created by chromatic
# Please include the string: [perl #39986]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39986 >

Hi there,

When creating a new interpreter with Parrot_new(), it should be possible to
compile and run code through Parrot_compile_string() without having to read
and load bytecode from disk.

Unfortunately, there's no default PackFile. I've tried to add one, but I
can't quite set it up correctly or use NULL pointer checks to avoid the
necessary code.

I'll check in a test case in t/src/extend.t as soon as I get a bug number.

-- c

[Chromatic]

On Friday 28 July 2006 07:26, Guest via RT wrote:

> This should be fixed now with r13613.

Hm, sort of. Is there any reason not to call it from Parrot_new() and not
make the C API users do it? I don't really want to require them to
understand the use of packfiles or pull in parrot/packfile.h either.

(I don't understand the use of returning a packfile from PackFile_new_dummy()
either; is there a reason it's not void?)

I applied this patch and things still work.

-- c

[Leopold Toetsch]

Am Freitag, 28. Juli 2006 18:41 schrieb chromatic:
> Hm, sort of.  Is there any reason not to call it from Parrot_new() and not
> make the C API users do it?

Well, when the next (and maybe common) step is:

pf = Parrot_readbc(interp, sourcefile);

then the creation of the dummy PF structure was in vain. I.e. the dummy is
only needed for _compile_string and friends.

We could create a new API

Parrot_new_with_PF(Parrot_Interp parent, const char *pf_name)

or such though, which does both.

leo

[Chromatic]

I would use this one all the time instead of Parrot_new() then (and I don't
know why pf_name is necessary; that's just noise that people shouldn't have
to provide -- why make people pass in "dummy" if they'll always pass
in "dummy"?). In general, I don't know *how* users will use the embedded
Parrot, whether they'll ever load any bytecode or will only ever always
compile code from strings.

To my mind, instead of having two calls which do almost similar things
depending on how well you predict code paths, we ought to have a single
default which does something harmless in the load_bc() case and does
something necessary in the other case.

-- c

[Chip Salzenberg]

The whole question of packfiles is something I hadn't approached before, and
now that I have, I wonder: Why does a packfile needs to exist at all when
compiling into the in-memory interpreter? There are some answers to that
question I'd accept, but it's still a question that needs answering.

As for any further improvements, I fear they will have to wait for 0.4.7.

PS: Cage cleaners should detect and possibly correct all that namespace pollution.
Yuck.
--
Chip Salzenberg <ch...@pobox.com>

[Chromatic]

On Thursday 03 August 2006 11:18, Chip Salzenberg wrote:

> The whole question of packfiles is something I hadn't approached before,
> and now that I have, I wonder: Why does a packfile needs to exist at all
> when compiling into the in-memory interpreter? There are some answers to
> that question I'd accept, but it's still a question that needs answering.

The trivial answer is that there are a lot of functions where Parrot assumes
it has compiled code available. All of them could check for a packfile and
raise an exception if not, but making it impossible to create an interpreter
*without* at least some data there (even if it's an empty packfile) could cut
down on that reptition.

> PS: Cage cleaners should detect and possibly correct all that namespace
> pollution. Yuck.

In the external API, you mean? Isn't there a bug for creating macros to avoid
prefixing Parrot_ to all internal-only functions?

-- c

[Andy Lester]

On Aug 3, 2006, at 2:05 PM, chromatic wrote:

>> PS: Cage cleaners should detect and possibly correct all that
>> namespace
>> pollution. Yuck.
>
> In the external API, you mean? Isn't there a bug for creating
> macros to avoid
> prefixing Parrot_ to all internal-only functions?

That is one of my first big tasks, yes.

--
Andy Lester => an...@petdance.com => www.petdance.com => AIM:petdance

[Chip Salzenberg]

On Thu, Aug 03, 2006 at 12:05:13PM -0700, chromatic wrote:
> On Thursday 03 August 2006 11:18, Chip Salzenberg wrote:
> > The whole question of packfiles is something I hadn't approached before,
> > and now that I have, I wonder: Why does a packfile needs to exist at all
> > when compiling into the in-memory interpreter? There are some answers to
> > that question I'd accept, but it's still a question that needs answering.
>
> The trivial answer is that there are a lot of functions where Parrot assumes
> it has compiled code available.

But the compiled code wouldn't necessarily have to live in a structure
compatible with on-disk storage. But of course such a commonality would
simplify things. OK.

> > PS: Cage cleaners should detect and possibly correct all that namespace
> > pollution. Yuck.
>
> In the external API, you mean? Isn't there a bug for creating macros to avoid
> prefixing Parrot_ to all internal-only functions?

Yes, but that's at least potentially orthogonal: pollution ne inconvenience.
--
Chip Salzenberg <ch...@pobox.com>