--============_-1271321419==_============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"


>Hi folks
>I have almost ready the 2.6 VM for OS/2, but I'm having a problem and
>need help.
>The Applescript support is in the startUpList in the standard image.
>This means that it tries to load TestOSAPlugin.dll when Squeak starts.
>But this dll exists only for Mac. I'm getting an error message
>complaining about this when I start Squeak. I don't like avoiding any
>module loading error, and I don't want to need a special image for OS/2.
>What is done about this in the other platforms?
>Thanks
>Juan Manuel Vuletich

As I understand it, the failure to load a plugin should not, by 
itself, result in any error messages.  (How else would Smalltalk be 
able to test for the presence of the plugin?).

I inferred these semantics, rightly or wrongly, by tracking the logic 
for handling pluggable primitives in the MacOS support code:  As 
understood, when

	<primitive: 'foo' module: 'bar'>

is executed, and it is the first execution of module 'bar,' and the 
..dll, shared library or other such thing is not found, the primitive 
should simply fail without an error message, leaving the calling 
method to determine how to respond in the "follow up" Smalltalk code.

Thus, at least on the MacOS VM, the existing code startUp for 
Applescript checks for the plugin and does nothing quietly if it is 
not present.  (The absence of the TestOSAPlugin in the system release 
is not a machine-dependent feature -- even for MacOS systems, the 
plugin must be installed before Applescript will work.  Nevertheless, 
the system reports no error if the TestOSAPlugin is not present)  I 
have confirmed this by running the standard image both with and 
without the TestOSAPlugin shared library.

Precisely what error messages are you getting?

In any case, the attached changeset provides a workaround providing a 
release function for Applescript, and includes a postscript releasing 
Applescript from the startUp.  I am not certain whether the problem 
described above, however, is a problem arising from Applescript, or a 
bug in the OS/2 plugin mechanics, in which case the changeset need 
not be incorporated into the general release.

If it is not an OS/2 issue, and I have simply misunderstood how 
plugins are supposed to work, the changeset can be added to the 
release and we'll simply advise those who want to use the plugin to 
initialize first (It's primary advantage for the moment is as an 
example how to use the new plugin compiler).  If so, I'll revise 
Applescript to be more system-sensitive, once I understand from where 
the problem has arisen.

--============_-1271321419==_============
Content-Type: text/plain; name="Applescript2.24Oct521pm.cs"
 ; x-mac-type="65417070"
 ; x-mac-creator="43534F6D"
Content-Disposition: attachment; filename="Applescript2.24Oct521pm.cs"
Content-Transfer-Encoding: imap_stub

0,462,2.2,2886,0,

--============_-1271321419==_============--