Fwd: I checked and I do not find the BitBltPlugin

> From: John M McIntosh <[hidden email]>
> Date: August 19, 2009 8:36:28 AM CEDT
> To: Stéphane Ducasse <[hidden email]>
> Subject: Re: I checked and I do not find the BitBltPlugin
> Reply-To: [hidden email]
>
> 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 <[hidden email]
>>> > 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 <[hidden email]>   Twitter:  
> squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://
> www.smalltalkconsulting.com
> =
> =
> =
> =
> =
> ======================================================================
>
>
>
>

> Thanks john for this nice explanation. We should put it on the web.
>
>
> Begin forwarded message:
>
>> From: John M McIntosh <[hidden email]>
>> Date: August 19, 2009 8:36:28 AM CEDT
>> To: Stéphane Ducasse <[hidden email]>
>> Subject: Re: I checked and I do not find the BitBltPlugin
>> Reply-To: [hidden email]
>>
>> 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 <[hidden email]
>>>>> 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 <[hidden email]>   Twitter:
>> squeaker68882
>> Corporate Smalltalk Consulting Ltd.  http://
>> www.smalltalkconsulting.com
>> =
>> =
>> =
>> =
>> =
>> =
>> =====================================================================
>>
>>
>>
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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 <[hidden email]>
>>> Date: August 19, 2009 8:36:28 AM CEDT
>>> To: Stéphane Ducasse <[hidden email]>
>>> Subject: Re: I checked and I do not find the BitBltPlugin
>>> Reply-To: [hidden email]
>>>
>>> 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 <[hidden email]
>>>>>> 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 <[hidden email]>   Twitter:
>>> squeaker68882
>>> Corporate Smalltalk Consulting Ltd.  http://
>>> www.smalltalkconsulting.com
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> ====================================================================
>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> --
> =
> =
> =
> =
> =
> ======================================================================
> John M. McIntosh <[hidden email]>   Twitter:
> squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://
> www.smalltalkconsulting.com
> =
> =
> =
> =
> =
> ======================================================================
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project