Hi, I started to build some needed external plugins (they are being build with Cocoa CogMT)... but I found some plugins still using carbon lib (SerialPlugin, MIDIPlugin)... and also, there are some others (B3DAcceleratorPlugin) who I didn't include it because uses carbon very intensively.
So, I wonder how to proceed with this plugins? I would like to have a "carbon clean vm", so I prefer to gently ask to the plugin owners to rewrite their sources to not use carbon.
What do you think?
Cheers, Esteban
pd: if someone want to test the already included plugins, they are: FloatMathPlugin AsynchFilePlugin SerialPlugin Mpeg3Plugin CroquetPlugin JoystickTabletPlugin MIDIPlugin
(Mpeg3Plugin looks very suspicious right now: )
On Sat, Mar 26, 2011 at 12:39:06PM -0300, Esteban Lorenzano wrote:
Hi, I started to build some needed external plugins (they are being build with Cocoa CogMT)... but I found some plugins still using carbon lib (SerialPlugin, MIDIPlugin)... and also, there are some others (B3DAcceleratorPlugin) who I didn't include it because uses carbon very intensively.
So, I wonder how to proceed with this plugins? I would like to have a "carbon clean vm", so I prefer to gently ask to the plugin owners to rewrite their sources to not use carbon.
What do you think?
Cheers, Esteban
pd: if someone want to test the already included plugins, they are: FloatMathPlugin AsynchFilePlugin SerialPlugin Mpeg3Plugin CroquetPlugin JoystickTabletPlugin MIDIPlugin
(Mpeg3Plugin looks very suspicious right now: )
FloatMathPlugin, Mpeg3Plugin, and CroquetPlugin are very core to Cobalt, and I really don't want to see them broken. I don't know what Carbon is, but I'd prefer you make a VM with the plugins as they currently exist before changing them, so we can have a working, cog-compatable VM to fall back on.
On Sat, Mar 26, 2011 at 01:21:18PM -0400, Matthew Fulmer wrote:
On Sat, Mar 26, 2011 at 12:39:06PM -0300, Esteban Lorenzano wrote:
Hi, I started to build some needed external plugins (they are being build with Cocoa CogMT)... but I found some plugins still using carbon lib (SerialPlugin, MIDIPlugin)... and also, there are some others (B3DAcceleratorPlugin) who I didn't include it because uses carbon very intensively.
So, I wonder how to proceed with this plugins? I would like to have a "carbon clean vm", so I prefer to gently ask to the plugin owners to rewrite their sources to not use carbon.
What do you think?
Cheers, Esteban
pd: if someone want to test the already included plugins, they are: FloatMathPlugin AsynchFilePlugin SerialPlugin Mpeg3Plugin CroquetPlugin JoystickTabletPlugin MIDIPlugin
(Mpeg3Plugin looks very suspicious right now: )
FloatMathPlugin, Mpeg3Plugin, and CroquetPlugin are very core to Cobalt, and I really don't want to see them broken. I don't know what Carbon is, but I'd prefer you make a VM with the plugins as they currently exist before changing them, so we can have a working, cog-compatable VM to fall back on.
That said, I'll be more than happy to throw the cobalt testers against the refactored plugins if you can provide a prebuilt VM
yes... I was building those plugins for you :) the problem with "carbon" is that it is a legacy library for osx, and it will be discontinued some time soon (now you have to use "cocoa"). Right now, I'm having a bunch of "deprecated" warnings, but I'm afraid in next version of osx (lion), maybe carbon will not be ready (not that they said something, it is just my fear). Also, for compatibility reasons, is not good to keep "carbon" plugins into a "cocoa" vm. So... the "keep all as is" is not an option. I can keep the plugins for awhile, but they need to be rewritten using cocoa sometime soon. Of course, I can help there, but with my time and knowledge limitations :)
Finally, the new vms and plugins are been built in pharo hudson server http://ci.pharo-project,org... you can test all Cocoa Cog X projects :)
Cheers, Esteban
pd: a test on the Mpeg3Plugin would be cool, I'm suspicious the plugin is built, but it wont work properly...
El 26/03/2011, a las 2:23p.m., Matthew Fulmer escribió:
On Sat, Mar 26, 2011 at 01:21:18PM -0400, Matthew Fulmer wrote:
On Sat, Mar 26, 2011 at 12:39:06PM -0300, Esteban Lorenzano wrote:
Hi, I started to build some needed external plugins (they are being build with Cocoa CogMT)... but I found some plugins still using carbon lib (SerialPlugin, MIDIPlugin)... and also, there are some others (B3DAcceleratorPlugin) who I didn't include it because uses carbon very intensively.
So, I wonder how to proceed with this plugins? I would like to have a "carbon clean vm", so I prefer to gently ask to the plugin owners to rewrite their sources to not use carbon.
What do you think?
Cheers, Esteban
pd: if someone want to test the already included plugins, they are: FloatMathPlugin AsynchFilePlugin SerialPlugin Mpeg3Plugin CroquetPlugin JoystickTabletPlugin MIDIPlugin
(Mpeg3Plugin looks very suspicious right now: )
FloatMathPlugin, Mpeg3Plugin, and CroquetPlugin are very core to Cobalt, and I really don't want to see them broken. I don't know what Carbon is, but I'd prefer you make a VM with the plugins as they currently exist before changing them, so we can have a working, cog-compatable VM to fall back on.
That said, I'll be more than happy to throw the cobalt testers against the refactored plugins if you can provide a prebuilt VM
-- Matthew Fulmer (a.k.a. Tapple)
On Sat, Mar 26, 2011 at 03:07:15PM -0300, Esteban Lorenzano wrote:
yes... I was building those plugins for you :) the problem with "carbon" is that it is a legacy library for osx, and it will be discontinued some time soon (now you have to use "cocoa"). Right now, I'm having a bunch of "deprecated" warnings, but I'm afraid in next version of osx (lion), maybe carbon will not be ready (not that they said something, it is just my fear). Also, for compatibility reasons, is not good to keep "carbon" plugins into a "cocoa" vm. So... the "keep all as is" is not an option. I can keep the plugins for awhile, but they need to be rewritten using cocoa sometime soon. Of course, I can help there, but with my time and knowledge limitations :)
Finally, the new vms and plugins are been built in pharo hudson server http://ci.pharo-project,org... you can test all Cocoa Cog X projects :)
I only see cog and stack vm's on hudson. I'm havn't been able to test vm's recently if the showstopper bug in cog is fixed yet: http://code.google.com/p/cog/issues/detail?id=3
I have noticed a lot of discussion about the ffi plugin, so maybe opengl will work on cog again. I'll try to test
On Sat, Mar 26, 2011 at 12:39:06PM -0300, Esteban Lorenzano wrote:
Hi, I started to build some needed external plugins (they are being build with Cocoa CogMT)... but I found some plugins still using carbon lib (SerialPlugin, MIDIPlugin)... and also, there are some others (B3DAcceleratorPlugin) who I didn't include it because uses carbon very intensively.
So, I wonder how to proceed with this plugins? I would like to have a "carbon clean vm", so I prefer to gently ask to the plugin owners to rewrite their sources to not use carbon.
What do you think?
Hi Esteban,
I think that these issues are in the platforms support code, so I fear that the plugin owner might be you at this point ;-)
I'm afraid that I am not knowledgeable about OS X development, but I know that in many cases John has been able to adopt code from the unix platforms tree for things like this. Maybe other people with OS X expertise can volunteer to help also?
Dave
El 26/03/2011, a las 3:10p.m., David T. Lewis escribió:
On Sat, Mar 26, 2011 at 12:39:06PM -0300, Esteban Lorenzano wrote:
Hi, I started to build some needed external plugins (they are being build with Cocoa CogMT)... but I found some plugins still using carbon lib (SerialPlugin, MIDIPlugin)... and also, there are some others (B3DAcceleratorPlugin) who I didn't include it because uses carbon very intensively.
So, I wonder how to proceed with this plugins? I would like to have a "carbon clean vm", so I prefer to gently ask to the plugin owners to rewrite their sources to not use carbon.
What do you think?
Hi Esteban,
I think that these issues are in the platforms support code, so I fear that the plugin owner might be you at this point ;-)
ouch!, I was afraid someone would say that :) yes... I can help, but sometimes (for example for the B3DAcceleratorPlugin) it needs some work/understanding... and it will take some time to achieve a full list of plugins running (in other cases, the work is easy... and of course, not all plugins needs carbon lib. So, now... I wanted to have the plugins Matthew ask for (no other reason that he asked for them... :) and then move the others plugins as soon as I have time...
I'm afraid that I am not knowledgeable about OS X development, but I know that in many cases John has been able to adopt code from the unix platforms tree for things like this. Maybe other people with OS X expertise can volunteer to help also?
Dave
On Sat, Mar 26, 2011 at 03:18:45PM -0300, Esteban Lorenzano wrote:
ouch!, I was afraid someone would say that :) yes... I can help, but sometimes (for example for the B3DAcceleratorPlugin) it needs some work/understanding... and it will take some time to achieve a full list of plugins running (in other cases, the work is easy... and of course, not all plugins needs carbon lib. So, now... I wanted to have the plugins Matthew ask for (no other reason that he asked for them... :) and then move the others plugins as soon as I have time...
oh. I missed that you said B3DAcceleratorPlugin. This is the most important plugin cobalt needs, as it contains the logic to allocate an opengl buffer. without it, cobalt won't even start.
On Sat, Mar 26, 2011 at 03:18:45PM -0300, Esteban Lorenzano wrote:
El 26/03/2011, a las 3:10p.m., David T. Lewis escribi?:
On Sat, Mar 26, 2011 at 12:39:06PM -0300, Esteban Lorenzano wrote:
Hi, I started to build some needed external plugins (they are being build with Cocoa CogMT)... but I found some plugins still using carbon lib (SerialPlugin, MIDIPlugin)... and also, there are some others (B3DAcceleratorPlugin) who I didn't include it because uses carbon very intensively.
So, I wonder how to proceed with this plugins? I would like to have a "carbon clean vm", so I prefer to gently ask to the plugin owners to rewrite their sources to not use carbon.
What do you think?
Hi Esteban,
I think that these issues are in the platforms support code, so I fear that the plugin owner might be you at this point ;-)
ouch!, I was afraid someone would say that :) yes... I can help, but sometimes (for example for the B3DAcceleratorPlugin) it needs some work/understanding... and it will take some time to achieve a full list of plugins running (in other cases, the work is easy... and of course, not all plugins needs carbon lib. So, now... I wanted to have the plugins Matthew ask for (no other reason that he asked for them... :) and then move the others plugins as soon as I have time...
That sounds like the right approach to me :)
Also, you will find that for things like SerialPlugin or MIDIPlugin, there are other people in the vm/squeak/pharo community who may have a specific interest in these plugins, and who may be able to help.
Dave
I'm afraid that I am not knowledgeable about OS X development, but I know that in many cases John has been able to adopt code from the unix platforms tree for things like this. Maybe other people with OS X expertise can volunteer to help also?
Dave
On 26 March 2011 19:10, David T. Lewis lewis@mail.msen.com wrote:
On Sat, Mar 26, 2011 at 12:39:06PM -0300, Esteban Lorenzano wrote:
Hi, I started to build some needed external plugins (they are being build with Cocoa CogMT)... but I found some plugins still using carbon lib (SerialPlugin, MIDIPlugin)... and also, there are some others (B3DAcceleratorPlugin) who I didn't include it because uses carbon very intensively.
So, I wonder how to proceed with this plugins? I would like to have a "carbon clean vm", so I prefer to gently ask to the plugin owners to rewrite their sources to not use carbon.
What do you think?
Hi Esteban,
I think that these issues are in the platforms support code, so I fear that the plugin owner might be you at this point ;-)
I'm afraid that I am not knowledgeable about OS X development, but I know that in many cases John has been able to adopt code from the unix platforms tree for things like this. Maybe other people with OS X expertise can volunteer to help also?
Can't help there. While carbon VM (in Mac OS dir) were written mostly in C, a Cocoa branch is almost complete rewrite in Objective-C, which i never had worked with. And of course i know little about MacOS APIs
Dave
vm-dev@lists.squeakfoundation.org
-
David T. Lewis -
Esteban Lorenzano -
Igor Stasenko -
Matthew Fulmer