Re: Optionally make use of 'parallel' in a package

[Daniel Kraft]

Hi!

On 12.03.2015 22:24, Mike Miller wrote:
> On Thu, Mar 12, 2015 at 13:08:01 +0100, Daniel Kraft wrote:
>> In a package (level-set, to be precise) I want to make use of
>> 'pararrayfun' of the parallel package to utilise parallel computation.
>> However, I do not want to make level-set strongly dependent on parallel.
>>  Instead, I would like to simply fall back to single threading when the
>> parallel package is not installed.
> 
> Hi. That sounds reasonable to me. Personally, I would lean towards
> using something like this (untested):
> 
>   have_pararrayfun = logical (exist ("pararrayfun", "file"));
>   if (! have_pararrayfun)
>     warning (["foo: pararrayfun not found, using single-threaded\n" ...
>                You might want to install/load the parallel package."]);
>   endif
> 
> and leave it up to the user to make the function available in the load
> path, however they decide to do that. You could also make the warning
> more sophisticated (differentiate between pkg not installed vs not
> loaded) if you want by checking the status of pkg describe, see how
> __unimplemented__.m does it.

Yes, that sounds like a good idea.  My thoughts yesterday (after sending
the email) leaned into the same direction.  I. e., just checking whether
the function is available and then enabling or disabling multithreading
accordingly.

>> 1) Decide whether or not a particular package (in this case, 'parallel')
>> is installed.  I think this is possible with both the 'pkg' and 'ver'
>> functions.  Is there some recommended way to do it?
> 
> Isn't checking for the specific function you want to use more
> accurate? What if the package name changes in the future? What if
> someone wants to use their own compatible version of the function? Or
> use files from the parallel package without actually installing it as
> a package?

You are right.  I was thinking about checking for the package because of
autoloading it -- but I'm now convinced by your email and my own
thinking that that's not the best idea.

>> 2) If present, make sure that 'parallel' is loaded when I need it.  I
>> could use 'pkg load' / 'pkg unload' calls in PKG_ADD / PKG_DEL or the
>> called function itself.  However, this would mess with the user's
>> environment, right?  Is there a way to ensure that the package is loaded
>> only temporarily during my function without modifying the global
>> environment?
> 
> I don't think there is a way to locally scope changes to the load
> path. I would steer clear of modifying the load path automatically or
> attempting to modify and restore it without the user's explicit
> action.

Fully agree.  (Of course, one could check the status of the package like
in Olaf's email, and then load/unload only if the package was not
already loaded.  But that seems messy.  I'm probably going for just
checking the function and telling the user to load the package for
multithreading themselves if they want it.)

Yours,
Daniel

-- 
http://www.domob.eu/
OpenPGP: 1142 850E 6DFF 65BA 63D6  88A8 B249 2AC4 A733 0737
Namecoin: id/domob -> https://nameid.org/?name=domob
--
Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Mon-Pri

signature.asc
Description: OpenPGP digital signature