pluggable everything

[allison]

A blanket wishlist item to change a substantial part of the core to dynamic extensions. The first step of the task is reviewing Parrot core to decide what parts might be good candidates for a pluggable architecture.

[Quevlar]

Hi,

The idea that I have about a plugin is that consist of two parts.

A group of files that are going to be transformed for a set of tools(like a compiler).

A configuration script that have the parameters passed to this tools.

The script is something like

[plugin] plugin_name = myplugin plugin_dir = /home/miuser/myplugindir #or '/home/miuser/miplugin' installed_plugin = /usr/local/application #is installed in /usr/local/application/myplugin

[compiler] compiler_name = gcc install_root = installed_plugin #output_extension = #if output_extension is a comment uses the default extension

It can be parsed using regex

The apache configuration file uses something like namespaces or blocks

I think tests can be plugins

It's only one instruction

[script] language_used = perl

All the languages can be made pluggins, and thinking in nanoparrot pasm and pir can be handled like plugins too.

Sincerely,

Igor

[Infinoid]

We already have dynamic and pluggable HLLs, PMCs, and ops. We also have dynamic (though not yet pluggable) runcores and GCs. Similarly, I/O objects are pluggable because they're just PMCs. Though the I/O subsystem itself may or may not be layerable enough to take full advantage of that... I would love to be able to push an "ssl" layer onto an existing tcp connection filehandle, but maybe the intention is to use PMC subclassing for that (somehow) instead.

There are two further candidates I can find which might be suitable for pluggability: charsets and encodings. I wasn't able to find anything else suitable for hotplugging in my (naive, 10-minute) review of the Parrot core. Though I'm sure there will be more things by the time parrot version 3.6 rolls around.

[whiteknight]

Replying to Infinoid:

We already have dynamic and pluggable HLLs, PMCs, and ops. We also have dynamic (though not yet pluggable) runcores and GCs. Similarly, I/O objects are pluggable because they're just PMCs.

I think we're also going to want to include compiler front-ends in this list. IMCC and PIRC should be able to be swapped out for other front-ends if wanted.

As to the idea of a pluggable GC, I think that it is certainly very possible to do. Once we've modified Parrot to support compacting/compiling GCs, we will be able to deinitialize one core without finalizing it, initialize the next core, and then move all the headers from one to the other. Some cores may have an interchangable storage format so we could just move the pools from one to the other. In other cases will will have to allocate new pools and arenas and move the headers to them. So long as we are not in the middle of a mark or a sweep phase, it should be very possible to hot-plug cores at runtime.

[coke]

imcc and pirc shouldn't be swappable, long term. Long term we should have one or the other. (short term yes, so we can actually test the new one.)

GC is nice to have as pluggable, but there's another ticket to eliminate most of the non-default options. (leaving a don't-use-this version as the only other alternative.)

As soon as "the first part" in the description is covered, this ticket should be closed and specific tickets for those identified candidates should be opened.

[whiteknight]

I disagree, I think compiler frontends should be swappable. We need to think about languages that choose to write a compiler frontend in C instead of PCT. They should have an easy straight-forward pluggable interface to swap their compiler for IMCC/PIRC.

[coke]

Are you suggesting that we provide a way for end users of parrot to override the PIR, PASM, and PASM1 compilers used by parrot itself?

[whiteknight]

If a user was so industrious as to write his own compiler for PIR or PASM, they should definitely be able to use that instead, yes. We need to think bigger though. What if a person wanted to write the compiler for an HLL in Lex/Yacc/C instead of in PCT? What if the Lua team wanted to write the Lua parser in C for performance reasons? They would swap out IMCC with a pluggable Lua compiler frontend and use that to compile directly to bytecode.

Also think about runtime calls to compreg, which could load either a .pbc library file that contained a PCT-based compiler, or could load a shared binary library that implements the frontend for it instead. This is how the PIR compreg could work, and could be loadable dynamically if needed (and not loaded at all if not needed).

[coke]

I think "allowing users to compile from their HL directly to bytecode" (+1) is not the same as "allow someone to replace the builtin PIR/PASM/PASM1 compilers" (-1)

Note that if they swapped out the IMMC compiler with something that compiled a HLL instead of PIR they would break anything that compiled PIR, which is most HLLs.

[whiteknight]

Think of it as "Allow the user to swap the default compiler frontend with a module of their choosing". I don't imagine that a user will ever take the effort to implement their own PIR compiler, that's a huge waste of effort for zero gain. Instead, they will be writing their own frontends in C that compile languages that are not PIR/PASM, and actually tell parrot to never load IMCC/PIRC at all.

[jkeenan]

Milestone 3.6 deleted

[jkeenan]

Does keeping this wishlist item open in our bug tracking system serve any useful purpose?

If someone wants to propose "to change a substantial part of the core to dynamic extensions," wouldn't that purpose be better served by drafting a proposal and publishing it first as a blog post or on parrot-dev?

Thank you very much.

kid51

[bacek]

Hello.

+1 for jkeenan propose to close this ticket as wontfix due very broad description.

-- Bacek