On 21/10/2021 1:23 p.m., Jens Oehlschlägel wrote:
Thanks Duncan,
I finally found the reason for the mysterious dispatch-failure: I had an
unwanted and unexported replicated definition of the 'clone' generic in
ff's namespace (a left-over).
I still don't understand how this prevented the proper
Thanks Duncan,
I finally found the reason for the mysterious dispatch-failure: I had an
unwanted and unexported replicated definition of the 'clone' generic in
ff's namespace (a left-over).
I still don't understand how this prevented the proper dispatch since
the duplicate in ff's namespace
Duncan's version is much clearer than my solution, and the only reason I
use my version is so that the source reference of the function looks
neater, and so that auto-code-indentation won't mess up my source reference
either.
If none of that made sense, don't worry about it, use Duncan's approach.
> Duncan Murdoch
> on Thu, 21 Oct 2021 08:09:02 -0400 writes:
> I agree with almost everything Deepayan said, but would add one thing:
> On 21/10/2021 3:41 a.m., Deepayan Sarkar wrote:
> ...
>> My suggestion is having a package-specific environment, and Duncan's
>
I agree with almost everything Deepayan said, but would add one thing:
On 21/10/2021 3:41 a.m., Deepayan Sarkar wrote:
...
My suggestion is having a package-specific environment, and Duncan's
is to have a function-specific environment. If you only need this for
this one function, then that sh
On Thu, Oct 21, 2021 at 12:15 PM Rolf Turner wrote:
>
>
> On Thu, 21 Oct 2021 02:03:41 -0400
> Duncan Murdoch wrote:
>
> > On 21/10/2021 12:40 a.m., Andrew Simmons wrote:
> > > I think the simplest answer is to store the variable in the
> > > functions frame. I'm assuming here that the only plot.
