adding external plugins to Squeak 4.2 on the Mac

>
>
> Hi--
>
>     I'm adapting the Spoon remote-browsing support for Squeak 4.2. I
> use an external plugin (Flow). On the Mac, if I build a stock 4.2 VM
> myself and add my Flow bundle to the Resources folder, it works. If I
> add the Flow bundle to the Resource folder of the offically-built VM, it
> doesn't work. Is the released VM binary expecting external plugin
> bundles to be special in some way?
>

>
>
> Hi--
>
>     Igor writes:
>
>> > I'm adapting the Spoon remote-browsing support for Squeak 4.2. I
>> > use an external plugin (Flow). On the Mac, if I build a stock 4.2 VM
>> > myself and add my Flow bundle to the Resources folder, it works. If
>> > I add the Flow bundle to the Resource folder of the offically-built
>> > VM, it doesn't work.
>>
>> do you rename you plugin? because if i remember correctly there's a
>> check that module name (compiled into a plugin) should be same as
>> library file name. Otherwise VM refuses to use it.
>
>     Well, that wouldn't explain why the unmodified 4.2 VM that I built
> myself works; it's the same external primitives code.
>
>> And again, problem with loading plugins is pain in the ass. We should
>> create an interface where language side could instruct VM to load
>> modules explicitly with good error reporting (if plugin cannot be
>> loaded).
>
>     Yeah, there actually is decent error-reporting code in the Mac VM,
> but it requires a rather obscure flag to be set in order to run. When I
> build a VM I always remove the check and force it to run all the time.
>
>     Well, I guess I need the very person who built the release VM to
> tell me why it won't load my plugin (by using a debugger with access to
> the source file paths mentioned in the debugging symbols). This appears
> to be John McIntosh. John, would you please grab [1] and let me know?
>
>
>     thanks!
>
> -C
>
> [1] http://dl.dropbox.com/u/15188004/Flow%20test.zip
>
> --
> Craig Latta
> www.netjam.org/resume
> +31 6 2757 7177
> + 1 415 287 3547
>
>
>

>
> On Sun, Jul 17, 2011 at 11:57:54AM +0200, Craig Latta wrote:
>>
>>
>> Hi John (and Esteban :) --
>>
>>      Cool, that was it! I'm embarrassed I'd forgotten about that. I
>> still have no idea what the release Mac VM binary has for VM_PROXY_MAJOR
>> and VM_PROXY_MINOR, though, I just removed the check entirely from my
>> plugin. :)
>>
>>      So... clearly there should be some way for plugin authors to be
>> able to check those values on a VM that someone else built? A
>> command-line argument, perhaps? I didn't see one mentioned by running
>> the VM with -help, but I guess I'll check the sources now, to be sure...
>> at any rate it should be mentioned in the help message.
>
> Craig,
>
> This seems like a pretty good idea to me. Now that you mention it, I'm
> surprised no one thought to do this before. Attached change set provides
> primitives that answer the VM_PROXY_MAJOR and VM_PROXY_MINOR for the VM,
> as well as for plugins (internal or external). If this looks good, I'll
> add it to VMMaker trunk (it should work for oscog also).

>
>
> Hi John (and Esteban :) --
>
>     Cool, that was it! I'm embarrassed I'd forgotten about that. I
> still have no idea what the release Mac VM binary has for VM_PROXY_MAJOR
> and VM_PROXY_MINOR, though, I just removed the check entirely from my
> plugin. :)
>
>     So... clearly there should be some way for plugin authors to be
> able to check those values on a VM that someone else built?

> A
> command-line argument, perhaps? I didn't see one mentioned by running
> the VM with -help, but I guess I'll check the sources now, to be sure...
> at any rate it should be mentioned in the help message.
>
>     Sorry if I'm duplicating any previous discussion.
>
>
>     thanks again,
>
> -C
>
> --
> Craig Latta
> www.netjam.org/resume
> +31   6 2757 7177
> + 1 415  287 3547
>
>

>
> Hi:
>
> On 19/07/11 02:59, Eliot Miranda wrote:
>>
>>
>> How about a command-line argument that prints/answers a system attribute?
>>  The system attributes are just strings, so they can be printed without
>> loading an image etc.  It won't look as nice as myvm -printProxyversion,
>> it'll look like myvm -sysattr 1010 -sysattr 1011, but it'll be general.
>
> Since I am currently again frustrated with 'someone else system', please
> keep in mind that 'Sunday programmers' like me will understand
> -printProxyversion without needing to search for it on the internet, but
> sysattr 1011 is not directly useful, except if the command-line would also
> provide a mechanism to translate that code to something understandable.
>

>
> On 19 July 2011 09:55, Stefan Marr <[hidden email]> wrote:
> >
> > Hi:
> >
> > On 19/07/11 02:59, Eliot Miranda wrote:
> >>
> >>
> >> How about a command-line argument that prints/answers a system attribute?
> >> ??The system attributes are just strings, so they can be printed without
> >> loading an image etc. ??It won't look as nice as myvm -printProxyversion,
> >> it'll look like myvm -sysattr 1010 -sysattr 1011, but it'll be general.
> >
> > Since I am currently again frustrated with 'someone else system', please
> > keep in mind that 'Sunday programmers' like me will understand
> > -printProxyversion without needing to search for it on the internet, but
> > sysattr 1011 is not directly useful, except if the command-line would also
> > provide a mechanism to translate that code to something understandable.
> >
>
> Same for me. I don't see why it needs to be obscure, if we can use
> symbolic names instead of numbers.
> After all, we making these interfaces for humans, not for machine.
>
> We have different positions on that with Eliot:
> Eliot  adding new numbers by extending existing interface (to access
> the system attributes).
> While i think that it would be better to have primitives with
> corresponding names, which explaining what attribute value it
> returns and what it serves for.
>
> IMO, saving developer's time is much better than saving few bytes in
> VM binary (because of using numbers instead of name).