On Thu, 29 Jun 2017, Allin Cottrell wrote:
On Thu, 29 Jun 2017, Allin Cottrell wrote:
> On Thu, 29 Jun 2017, Marcin Błażejowski wrote:
[...]
>> Let me explain what that package does. It's just the script you send
>> three days ago, but saved in the package form organized as follows:
>>
>> 1. foo1() and foo(2) are private functions.
>> 2. foo3() is a public function which calls foo1() and foo2() within the
>> mpi block. After that gretlmpi complains on call to unknown function.
>
> Thanks, Marcin. I see that it works OK if I edit the gfn to make foo1() and
> foo2() public. So I guess what's happening is just that --send-functions is
> not including any private functions. I'll take a closer look...
Hmm, it's not that we're excluding the private functions when we write out
the functions-file to be sourced by gretlmpi.
Here's my diagnosis. First, functions that are private to package X are
"found" only when a public function from package X is executing. That's
correct, it has to be that way. However, when you call foo1 or foo2 (private)
from foo3, foo3 is executing only in the initial gretl process, it's not
executing in any of the gretlmpi processes. Therefore foo1 and foo2 are
"invisible" in gretlmpi. To make them visible they either need to be public,
or foo3 has to be executed under mpi.
In principle we could attempt a complex hack: if mpi is invoked within a
packaged function F, then use some mechanism to pretend that F is executing
within the subordinate gretlmpi processes. But I think this would both
difficult and error prone.
OK, I was too pessimistic. I think I found a nice simple way of
passing on the name of the caller function (if any) when invoking mpi.
Try current git.
Allin