search order for plugins

 
Hi,

In platforms/unix/vm/sqUnixExternalPrims.c:
231   if ((   handle= tryLoading(    "./",                  pluginName))
232       || (handle= tryLoadingPath("SQUEAK_PLUGIN_PATH",  pluginName))
233       || (handle= tryLoading(    VM_LIBDIR"/",          pluginName))
234       || (handle= tryLoadingPath("LD_LIBRARY_PATH",     pluginName))
235       || (handle= tryLoading(    "",                    pluginName))

The most likely place to find plugins would be the directory where the
squeakvm executable is located. So, shouldn't the search start from that
directory? The current directory is not a reliable location and should be
tried only as a last resort.

An strace of squeak (3.7.7) startup reveals 181 attempts to open of which
179 fails with ENOENT.

Regards .. Subbu

 
I'll note the Mac carbon VM has a info.plist flag that is turned on  
to ensure the tryLoading logic tries less hard and considers the  
internall bundle's application folder first so
the the number of opens is *considerably* less.

On Apr 26, 2007, at 11:48 AM, subbukk wrote:

--
========================================================================
===
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===

 
subbukk wrote:
> An strace of squeak (3.7.7) startup reveals 181 attempts to open of which
> 179 fails with ENOENT.

Why is that a problem?

Cheers,
   - Andreas

 
On Friday 27 April 2007 1:40 am, Ian Piumarta wrote:
> On Apr 26, 2007, at 11:48 AM, subbukk wrote:
> > The most likely place to find plugins would be the directory where the
> > squeakvm executable is located. So, shouldn't the search start from
> > that
> > directory?
>
> No.  If the search started in VM_LIBDIR then there would be no way to
> override a system-wide installed plugin with a per-user personalised
> plugin.
There is the command line override to take care of special cases. The logic:
   libpath = -plugin option if given followed by dirname of argv[0]
should handle all cases without penalizing the most common case.
BTW, isn't VM_LIBDIR set at compile time? The actual location would depend on
the package maintainer, so I would prefer $(dirname $0) to VM_LIBDIR.

> > The current directory is not a reliable location and should be
> > tried only as a last resort.
>
> You are probably right.  However, it was placed first to allow
> overriding of a system-wide plugin before SQUEAK_PLUGIN_PATH was
> invented.  Now that a knowledgeable user can set that variable to
> override installed plugins, './' should probably go away entirely.
Env variables are required to influence the running env of multiple commands.
In our case, there is only one command. A command line option should suffice
to modify the behavior. IMHO, env variables are an overkill.

The current code is not wrong. It is just more complex than what it should be
raising the risk of code rot. Squeak VM's strong points are its simplicity,
portability and compactness. I thought it pertinent to point out an
opportunity for simplification.

Regards .. Subbu

 
On Apr 27, 2007, at 8:53 , subbukk wrote:

Ian, I did not see your reply on-list ... which may explain why you  
appear "silent" at times ;)

Maybe you're posting with the wrong address?

> There is the command line override to take care of special cases.  
> The logic:
>    libpath = -plugin option if given followed by dirname of argv[0]
> should handle all cases without penalizing the most common case.
> BTW, isn't VM_LIBDIR set at compile time? The actual location would  
> depend on
> the package maintainer, so I would prefer $(dirname $0) to VM_LIBDIR.

Well, I'd like an automatic way to detect VM_LIBDIR. But $0 is  
unreliable - it can be set to anything by the executing process.  
Also, in a regular install squeak happens to be a symlink so even if  
$0 is set correctly you'ld get the wrong directory. I doubt there is  
even a x-platform way to find the path to the currently running  
executable ... under Linux one might look at /proc/self/exe but that  
won't work on most other unices. Still, it would be rather convenient  
to have that.

>>> The current directory is not a reliable location and should be
>>> tried only as a last resort.
>>
>> You are probably right.  However, it was placed first to allow
>> overriding of a system-wide plugin before SQUEAK_PLUGIN_PATH was
>> invented.  Now that a knowledgeable user can set that variable to
>> override installed plugins, './' should probably go away entirely.

Yes, I'd like that to go away for OLPC where every unnecessary disk  
search hurts ...

- Bert -

 
On Apr 26, 2007, at 11:53 PM, subbukk wrote:

> There is the command line override to take care of special cases.

Which just sets the same internal variable as is set by  
SQUEAK_PLUGIN_PATH.

>    libpath = -plugin option if given followed by dirname of argv[0]

There is no guarantee that argv[0] contains anything beyond the word  
'squeak'.

> BTW, isn't VM_LIBDIR set at compile time?

It's based on the configured ${prefix}.

> the package maintainer, so I would prefer $(dirname $0) to VM_LIBDIR.

See above.

> In our case, there is only one command. A command line option  
> should suffice

There is an option.  Every env var has a corresponding option (and  
that takes precedence).

Cheers,
Ian