Craig one reason a plugin won't load is an issue with the major/minor version numbers in the headers. There could be disagreement there and you would need to check what is compiled into the VM versus what is in your plugin. see what #define VM_PROXY_MINOR is

also see notes form June 16th "[Vm-dev] Re: heads-up on sqVirtualMachine harmonization"

Failure via

/* Note: This is coded so that is can be run from Squeak. */

EXPORT(sqInt) setInterpreter(struct VirtualMachine* anInterpreter) { sqInt ok;

interpreterProxy = anInterpreter; ok = interpreterProxy->majorVersion() == VM_PROXY_MAJOR; if (ok == 0) { return 0; } ok = interpreterProxy->minorVersion() >= VM_PROXY_MINOR; return ok; }

On Sun, Jul 17, 2011 at 12:31 AM, Craig Latta craig@netjam.org wrote:

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

I still have no idea what the release Mac VM binary has for VM_PROXY_MAJOR and VM_PROXY_MINOR, though...

Hm, I should wake up before posting. :) Of course I could step through my plugin in Xcode to see this info, but it would still be nice to be able to get it from the command line.

thanks again,

-C

-- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547

...I am almost sure you did it, but be sure that the flag SqueakPluginsBuiltInOrLocalOnly in Info.plist is false.

Yeah, I did that first, but it was the version info issue that John mentioned earlier.

thanks,

-C

-- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547

Hi David,

On Sun, Jul 17, 2011 at 12:25 PM, David T. Lewis lewis@mail.msen.com wrote:

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).

I don't think this meets the usecase. One may not be able to run an image of certain plugins cannot be loaded, so providing an accessor which requires a functional image is insufficient. Craig asks for a cmmand-line switch and that's reasonably easy to do, and seems to me to be the right approach. On the other hand, adding vm parameters or system attributes that answer VM_PROXY_MAJOR and VM_PROXY_MINOR seems reasonable. Personally I don't like adding endless primitives (those strings add up in space) when existing query facilities are extensible and easily extended (such as getSystemAttribute: and vmParameterAt:). Adding an accessor that wraps the getSystemAttribute:/vmParameterAt: is fine and overall the extension plus the wrapper requires less space than adding a long-named primitive (whose name is in the list of registered internal named primitives, along with the space overhead of the entry), the symbol name for the primitive in the image plus the primitive method.

Parsimony is a virtue, or as my grandmother used to say, many a mickle makes a muckle.

2¢ Eliot

Dave

But wiktionary says your grand mother does not use the academically correct form:

http://en.wiktionary.org/wiki/many_a_mickle_makes_a_muckle

Though maybe only French love bureaucracy enough to pay an academy for defining correct usage of language ;)

Nicolas

2011/7/17 David T. Lewis lewis@mail.msen.com

On Sun, Jul 17, 2011 at 12:57:44PM -0700, Eliot Miranda wrote:

...

Parsimony is a virtue, or as my grandmother used to say, many a mickle makes a muckle.

I like your grandmother's point of view. A good deal of useful guidance packed into six words :)

Dave

Hi Bert--

It is *right* that the VM will refuse to load...

Right, right, I have no qualm with the policy. There should just be a simple way for me to tell what some random VM is expecting, by a simple query at the command line. I shouldn't even need an object memory, much less get to the point of an error happening.

-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.

Thanks Stefan

On 19 July 2011 09:55, Stefan Marr squeak@stefan-marr.de 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).

On Tue, Jul 19, 2011 at 04:12:39PM +0200, Igor Stasenko wrote:

On 19 July 2011 09:55, Stefan Marr squeak@stefan-marr.de 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).

I also prefer the explicit names, either named primitives or command line parameters. To me the rationale is that system attributes or vm parameters require an coordinated effort to keep track of the assignments. That's fine for a small number of developers, but it is not scalable as we move forward with larger numbers of people doing creative development of VMs.

There are a few things that really do need to be coordinated between the various VM projects, such as image format number assignments to support new VMs and object memories. But this kind of coordination is difficult to maintain, and requiring agreement on trivial matters (such as "what is the meaning of attribute nnn?") can inhibit progress for people trying to advance their own work without waiting for agreement from everyone else.

So in my view it is a good thing to use explicit names, even if it does have some technical disadvantages.

Dave

On Wed, Jul 20, 2011 at 05:11:00PM +0200, Bert Freudenberg wrote:

On 20.07.2011, at 04:40, David T. Lewis wrote:

...

So in my view it is a good thing to use explicit names, even if it does have some technical disadvantages.

Dave

Should the primitives take symbolic names too, then? They could easily be changed to accept a string in addition to an index.

I don't really think that this matters one way or the other, as long as it is consistent from the point of view of the image. The point I want to make is that numbered system attributes or vm parameters imply coordinating the definition of these parameters amongst the various developers and VM projects (i.e. parameter number N should mean more or less the same thing on RoarVM as it means on Cog, etc). In contrast, it is unlikely that any two VM development projects would separately define a primitive called #primitiveNumberOfActiveCores, and therefore this approach requires less coordination between the various interested parties. It is also simpler from the point of view of the image, because it does not require the image to interpret some parameter value based on what flavor of VM it happens to be running on.

As a technical matter I don't much care how these things are implemented. As a social and process issue, I would prefer to avoid things that require coordination and agreement between the interested parties, because these things tend to inhibit progress for the various VM projects (RoarVM, Cog, 64-bit images, etc) and also tend to produce confusion between branches (a personal concern for me).

Dave