Hi Dave, Chris,
I had written a plugin for previous version of MW, which now I have adapted to be run with new MW version (0.4.5).
These are the change I applied after looking at the changes in the core:
- First copying the content of the header and cpp file in the new template
- Changing the name of MonkeyWorksCore to MWorksCore wherever needed in the plugin
- Replacing “new_stimulus->load(defaultDisplay.get());” with “new_stimulus->load(defaultDisplay);” in the factory cpp file.
- Replacing “drawInUnitSquare(StimulusDisplay *display)” with “drawInUnitSquare(shared_ptr display)”
- removing “frozenClone()” method
I am not sure if this is the best method to adapt previously written plugin to the new MW version, but the plugin successfully compiled.
The problem now is that when I run an experiment which uses the plugin I see an error indicating “ERROR: Failed to create object”, and “ERROR: No factory for object type” and the experiment does not load in the MW.
Do you have any clue about the possible cause of this problem?
MacOS X 10.6.3, 2.26GHz core 2 Duo, 4GB RAM, MacBookPro5,5
Thanks,
Alireza
P.S. Is there any policy regarding updating previously written plugin when MW core is changing?
Hi Alireza,
The problem now is that when I run an experiment which uses the plugin I see an error indicating “ERROR: Failed to create object”, and “ERROR: No factory for object type” and the experiment does not load in the MW.
The “No factory for object type” error indicates that MWorks hasn’t loaded the plugin. Are you sure that it’s being installed in the correct location? Core plugins should go in /Library/Application Support/MWorks/Plugins/Core.
If the plugin is installed correctly, then perhaps MWorks has tried and failed to load the plugin bundle. One possible reason for this is that the plugin links against frameworks or shared libraries that aren’t on standard search paths. You can see what libraries your plugin links against using the otool command:
otool -L MyPlugin.bundle/Contents/MacOS/MyPlugin
Typically, the output will contain the full (i.e. absolute) path to each linked framework or library. If any paths are missing, then MWServer probably won’t be able to load the plugin.
P.S. Is there any policy regarding updating previously written plugin when MW core is changing?
I’m not sure what you’re asking. Can you elaborate a bit?
Chris
Thank you so much dear Chris for you fast and helpful reply.
I double checked: the plugin does exist in the /Library/Application Support/MWorks/Plugins/Core.
As far as the libraries are concerned, I had added the OpenGL framework to the project. After reading your comment, I changed the path from relative to absolute (some other options for path of framework), but it did not work.
Perhaps this is the cause of the problem since I noticed OpenGL headers are included in AppKit.Framework, but I could not make the plugin be compiled without adding opengl framework separately (in fact there were several linker errors indicating it does recognize opengl commands).
I also added the path of opengl framework to the system path (.profile file in home directory), again it did not help. I assume MW server uses this path to access libraries (Am I right?)
Regarding the plugin updating, since people might have made plugins for MW, once there are some major changes in the core that are going to affect plugin (like changing the class Data to Datum or removing the method frozenClone() ), it would make maintenance/adapting the plugin with new version of MW core a bit difficult. What I was asking is whether there is a way to announce MW core changes affecting stimulus-related core plugins more explicitly for plugin developers.
Thanks again,
Alireza
I’m not sure why you had to add the OpenGL framework to your project. Let me think about that a bit.
One issue with trying to debug your problem is that any error messages generated when plugins are loaded are being lost. I’ve just made some changes to MWorksCore so that the messages get sent to the console. The changes are in the nightly build. I’d recommend downloading it and testing your plugin against it. (Be sure to do a custom install and select the “Development files” component, which is not included in a standard install).
When you run the server from the nightly build, you should see messages listing loaded plugins in /var/log/system.log. For example, if your plugin is called MyPlugin, then you should see a message like this:
... Loading MyPlugin
If the plugin fails to load, then the “Loading” message should be followed immediately by a message like
... WARNING: Plugin module (MyPlugin) failed to load: ...
That line should contain a message from dlopen indicating why the plugin wasn’t loaded. Please give it a try and let me know what you find.
Regarding the plugin updating, since people might have made plugins for MW, once there are some major changes in the core that are going to affect plugin (like changing the class Data to Datum or removing the method frozenClone() ), it would make maintenance/adapting the plugin with new version of MW core a bit difficult. What I was asking is whether there is a way to announce MW core changes affecting stimulus-related core plugins more explicitly for plugin developers.
I understand. No, there’s currently no formal mechanism for updating plugin developers about core changes. I think that’s the case mostly because, historically, only a couple of people have written MWorks plugins. Now that more folks are developing plugins, we may want to think about a better way to update them when the APIs change. In any case, we’ll also make an effort to note any API changes relevant to plugin authors in the release notes.
Chris
I’m not sure why you had to add the OpenGL framework to your project. Let me think about that a bit.
I figured it out. You were correct to add OpenGL to the list of linked frameworks. I’ve added it in the Xcode template, too.
However, I don’t think linking against OpenGL is preventing your plugin from loading. Please let me know what (if any) errors you see in the log.
Chris
Hi Chris,
Thank you, I downloaded the nightly build of MW. But when I tried to compile the plugin, there were errors about the boost lib. Apparently, it cannot find boost library. Is everything ok with nightly build version? There were not errors before with the previous build (from Dave) MW0.4.5.
Are yours and Dave’s MW builds coming from the same source code?
If yes, how come that they behave differently in terms of dependencies on the libraries?
Anyway, how do you recommend me to add boost lib to the plugin?
Alireza
The nightly build is generated from the latest source on GitHub. I don’t know what version of the source Dave used to generate the build he gave you or why it would differ in a significant way from the nightly build. As such, I’m going to refer you to Dave for further help on this issue.
Chris
My installer was built from the very same source.
Is there a way you could just give me access to your code? I’m guessing that we can get to the bottom of this a lot faster if we don’t have to do it as a series of questions and answers.
Is there a way you could just give me access to your code? I’m guessing that we can get to the bottom of this a lot faster if we don’t have to do it as a series of questions and answers.
It would be nice. Davide is going to share it with you.
Thank you in advance,
Alireza