embedding parrot fails, many symbols not exported properly [win32]

[particle]

t/src/compiler.t (soon to be renamed t/src/embed.t) is failing on win32 due to lack of properly exported symbols. previously, this passed everywhere because it was linking with static libparrot and had full access to parrot internals. after i have a ticket number for this issue, i'll change the file to follow the rules and only #include 'embed.h', so linker errors due to unresolved externals will occur everywhere. expect this at about r36548. i'll skip all the tests, so trunk stays stable-ish. expect the test file to be renamed in another commit following shortly afterwards.

seems, at the moment, the only way to embed parrot is via static linking. this stinks. ~jerry

[Infinoid]

include/parrot/parrot.h says:

/* Only parrot core files should include this file.
   Extensions should include <parrot/extend.h>.
   Programs embedding parrot should include <parrot/embed.h>.
*/

Currently as an embedder, there's nothing you can include to get basic typedefs like STRING and PMC. Extend.h has Parrot_String and Parrot_PMC which both resolve to "void *", which should be good enough to call things like PMC_IS_NULL(), I guess. Embed.h has neither of those, and nothing equivalent that I can see.

My question is: what's the difference between an embedder and an extension? Is compiler.t correct in expecting to have access to these internals? Does that make it an extension instead of an embedder? What would mod_parrot be considered? Not knowing anything about it, I'd consider it an embedder, but I would bet it needs a lot more than embed.h currently provides.

Looking at the mod_parrot sources, I see that they include all 3 of parrot.h, embed.h and extend.h. That doesn't seem right.

[NotFound]

There main difference between extending and embedding is that the embedder creates the parrot interpreter (sometimes this is said as 'it has main', but can be a library that embeds for the benefit of other programs). The embedder usually communicates with the interpreter in the same ways as extensions, so the embedder is usually also an extender.

The test probably access the internals for convenience, for comparing internal and external view. Or maybe actually don't do it, and the header remains even when no longer needed.

And if extenders or embedders needs things that are not accessible from the outside, we must provide ways, not allow/force them to pokeing in internals.

[jhorwitz]

Been away for a month or so, so not having looked at them yet, I'm guessing that the embedding tests should be updated to use the proper Parrot_* types and exported functions. Jerry has taken the first step by forcing them to break in the right places. Cleanup will be tedious but not difficult.

But as NotFound said, the line between embedder and extender is very fuzzy here, something which Allison and I have talked about often. In fact, an application that ONLY uses the functions in embed.h can't really do much other than run some bytecode and exit. Not terribly useful.

If you do look at the mod_parrot source, there is almost no use of Parrot internal datatypes -- only the opaque external types like Parrot_PMC and Parrot_String. There are functions that obviate almost any need to access the internals, and I've documented many of those in docs/embed.pod (parrot source). The only time I do use the internal types is in the custom PMC and modparrot_backtrace, which is a gross hack and will be replaced with something cleaner.

[allison]

The answer is that we should have only one external API, used for both extend and embed. We've already started merging the documentation for the two into a single unified API, the code needs to follow.

So,

• Only one header file to include for both
• Any Parrot feature that's available in one, is available in the other

[nwellnhof]

You should be able to get Windows code to work by defining PARROT_IN_EXTENSION at the top of your .c file and then including parrot/parrot.h. That's also what Rakudo does.

It is a rather ugly solution, but it should be OK until we have a clearly defined API.