[Pharo-project] Fwd: I checked and I do not find the BitBltPlugin
Thanks john for this nice explanation. We should put it on the web. Begin forwarded message:
From: John M McIntosh <johnmci@smalltalkconsulting.com> Date: August 19, 2009 8:36:28 AM CEDT To: Stéphane Ducasse <stephane.ducasse@inria.fr> Subject: Re: I checked and I do not find the BitBltPlugin Reply-To: johnmci@smalltalkconsulting.com
The way this works is that plugins are compiled either into the VM, or as external. For the macintosh carbon VM most plugins are internal, versus for unix they are external.
What happens when the plugin is referenced we first look for the plugin as an external plugin, if not found then we look for the plugin as an internal entry point in the VM binary (aka internal plugin).
However when for example you stick the bitblit external plugin in either the applications's resource folder or in a folder called Plugins in the same directory as the *.app then it will load the external plugin versus using the internal plugin.
So if you had a Plugins folder around it could have seen the bitblit plugin there and override the behavior for bitblt that was compiled in May
SqueakPluginsBuiltInOrLocalOnly
when set to true makes the lookup logic only consider unix libraries or os-x bundles in the ./Plugins folder in the same directory as the app, or the application Resources folder, or as a foo.framework in the /System/Library/Frameworks/.
To turn this feature off and then consider the other 80+ choices of library locations and library names set SqueakPluginsBuiltInOrLocalOnly to false.Turning the feature on avoids a couple of hundred stat calls at startup time as the VM hunts for external versions of internal plugins. It was added to reduce overhead and help the macIntel migration were we provided new universal binaries that live in the application Resources folder since we cann't load powerpc plugins on macintel machines if we found them first in the ./Pugins folder
On 18-Aug-09, at 11:21 PM, Stéphane Ducasse wrote:
OK!!!!!! I was not aware of that optional behavior.
stef On Aug 19, 2009, at 12:17 AM, John M McIntosh wrote:
Yes it is optional and I did not make it the default. But if you download and install it, then it would override the vm behavor
Sent from my iPhone
On 2009-08-18, at 3:13 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
in the VM 4.1.1beta2U that I could download from your web page. Is it normal? Now I understand why I got problem with juan code I do not understand how it worked once. May be I got an older vm with the plugin Stef
-- = = = = = ====================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = ======================================================================
k, there is lots of behaviour in the macintosh Carbon VM explained in http://www.smalltalkconsulting.com/html/squeakinfoplist.html which people don't realize is there. On 19-Aug-09, at 12:18 AM, Stéphane Ducasse wrote:
Thanks john for this nice explanation. We should put it on the web.
Begin forwarded message:
From: John M McIntosh <johnmci@smalltalkconsulting.com> Date: August 19, 2009 8:36:28 AM CEDT To: Stéphane Ducasse <stephane.ducasse@inria.fr> Subject: Re: I checked and I do not find the BitBltPlugin Reply-To: johnmci@smalltalkconsulting.com
The way this works is that plugins are compiled either into the VM, or as external. For the macintosh carbon VM most plugins are internal, versus for unix they are external.
What happens when the plugin is referenced we first look for the plugin as an external plugin, if not found then we look for the plugin as an internal entry point in the VM binary (aka internal plugin).
However when for example you stick the bitblit external plugin in either the applications's resource folder or in a folder called Plugins in the same directory as the *.app then it will load the external plugin versus using the internal plugin.
So if you had a Plugins folder around it could have seen the bitblit plugin there and override the behavior for bitblt that was compiled in May
SqueakPluginsBuiltInOrLocalOnly
when set to true makes the lookup logic only consider unix libraries or os-x bundles in the ./Plugins folder in the same directory as the app, or the application Resources folder, or as a foo.framework in the /System/Library/Frameworks/.
To turn this feature off and then consider the other 80+ choices of library locations and library names set SqueakPluginsBuiltInOrLocalOnly to false.Turning the feature on avoids a couple of hundred stat calls at startup time as the VM hunts for external versions of internal plugins. It was added to reduce overhead and help the macIntel migration were we provided new universal binaries that live in the application Resources folder since we cann't load powerpc plugins on macintel machines if we found them first in the ./Pugins folder
On 18-Aug-09, at 11:21 PM, Stéphane Ducasse wrote:
OK!!!!!! I was not aware of that optional behavior.
stef On Aug 19, 2009, at 12:17 AM, John M McIntosh wrote:
Yes it is optional and I did not make it the default. But if you download and install it, then it would override the vm behavor
Sent from my iPhone
On 2009-08-18, at 3:13 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
in the VM 4.1.1beta2U that I could download from your web page. Is it normal? Now I understand why I got problem with juan code I do not understand how it worked once. May be I got an older vm with the plugin Stef
-- = = = = = = ===================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = = =====================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
Indeed it works so well that we do not imagine :) Stef On Aug 19, 2009, at 9:27 AM, John M McIntosh wrote:
k, there is lots of behaviour in the macintosh Carbon VM explained in http://www.smalltalkconsulting.com/html/squeakinfoplist.html which people don't realize is there.
On 19-Aug-09, at 12:18 AM, Stéphane Ducasse wrote:
Thanks john for this nice explanation. We should put it on the web.
Begin forwarded message:
From: John M McIntosh <johnmci@smalltalkconsulting.com> Date: August 19, 2009 8:36:28 AM CEDT To: Stéphane Ducasse <stephane.ducasse@inria.fr> Subject: Re: I checked and I do not find the BitBltPlugin Reply-To: johnmci@smalltalkconsulting.com
The way this works is that plugins are compiled either into the VM, or as external. For the macintosh carbon VM most plugins are internal, versus for unix they are external.
What happens when the plugin is referenced we first look for the plugin as an external plugin, if not found then we look for the plugin as an internal entry point in the VM binary (aka internal plugin).
However when for example you stick the bitblit external plugin in either the applications's resource folder or in a folder called Plugins in the same directory as the *.app then it will load the external plugin versus using the internal plugin.
So if you had a Plugins folder around it could have seen the bitblit plugin there and override the behavior for bitblt that was compiled in May
SqueakPluginsBuiltInOrLocalOnly
when set to true makes the lookup logic only consider unix libraries or os-x bundles in the ./Plugins folder in the same directory as the app, or the application Resources folder, or as a foo.framework in the /System/Library/Frameworks/.
To turn this feature off and then consider the other 80+ choices of library locations and library names set SqueakPluginsBuiltInOrLocalOnly to false.Turning the feature on avoids a couple of hundred stat calls at startup time as the VM hunts for external versions of internal plugins. It was added to reduce overhead and help the macIntel migration were we provided new universal binaries that live in the application Resources folder since we cann't load powerpc plugins on macintel machines if we found them first in the ./Pugins folder
On 18-Aug-09, at 11:21 PM, Stéphane Ducasse wrote:
OK!!!!!! I was not aware of that optional behavior.
stef On Aug 19, 2009, at 12:17 AM, John M McIntosh wrote:
Yes it is optional and I did not make it the default. But if you download and install it, then it would override the vm behavor
Sent from my iPhone
On 2009-08-18, at 3:13 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
in the VM 4.1.1beta2U that I could download from your web page. Is it normal? Now I understand why I got problem with juan code I do not understand how it worked once. May be I got an older vm with the plugin Stef
-- = = = = = = = ==================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = = = ====================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- = = = = = ====================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = ======================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (2)
-
John M McIntosh -
Stéphane Ducasse