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 brasspen@gmail.com 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; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Talks to plants on their own level.
squeak-dev@lists.squeakfoundation.org