Trying Alien

I forgot that there are two kinds of plugins: internal and external. And
IA32ABI is both internal and included in each Cog virtual machine.
If I download Squeak 5.0 onto my Ubuntu 15.04 laptop from the homepage
and execute:

Smalltalk listBuiltinModules do: [:ea| Transcript cr; show: ea]

I can see IA32ABI is clearly loaded. Then I can go to
squeaksource.com/Alien and load Alien into then execute in a Workspace.

Alien exampleCqsort.

This will produce an array of numbers.

(Time millisecondsToRun: [100 timesRepeat: [Alien exampleCqsort]]) / 100.0

This will return ~1.0.

So, it looks like trying it out is not so hard. I'm not sure what it all
means, but I have a successful control experiment at this point to work
with. Perhaps I need to read the documentation now to explain what I'm
seeing?

A plugin repository would not account for internal plugins, but I still
think it's a good idea. It could focus and foster external plugin hacking.

The issue about what kind of repository (ftp.squeak.org, GitHub,
TravisCI) is where a URL will point. Wherever client that socket is
accessed by, either  SqueakMap or a browser, seems to be a subordinate
issue people could decide for themselves.

Chris

On 06-09-2015, at 9:20 AM, Chris Cunnington <[hidden email]> wrote:
> A plugin repository would not account for internal plugins, but I still think it's a good idea. It could focus and foster external plugin hacking.

Well, yes and no - don’t forget that all plugins are supposed to be compilable for either case and that the vm is supposed to check for an external plugin before looking at the internal ones. That latter part was intended to allow for over-riding buggy internal plugins in our original ‘spec’, such as it was. Part of any plugin repository should be the inclusion of all plugins; then we can easily grab one to test if an internal plugin is suspected buggy.

We shouldn’t forget that plugins are unloadable too. Or at least, they’re supposed to be! This is intended to  help in development and testing of the plugins; you can write, build, try (which loads) and unload, rinse & repeat. Even internal plugins can be unloaded and in fact you ought to be able to have a running system, grab a new/fixed/experimental external version of XYPlugin, unload the already in use internal XYPlugin and make a call to an XYPlugin routine.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Talks to plants on their own level.