|
From: Nikita Z. <coo...@ma...> - 2018-03-08 21:22:26
|
Somehow discussion moved out of mailing list. Last time i got email
without any field like to or cc, containing mailing list address. And
replied out of it without carry (it was automatically set _to_ to
sfeam's email).
In Wed, 07 Mar 2018 16:40:45 -0800
sfeam <eam...@gm...> wrote:
> Given the current implementation, it is not possible to return an
> array from an expression. The closest I can see is to pass an array
> in and replace the individual entries. Because it is passed by
> reference, the changes will be visible to the rest of the program.
> Of course you must free any strings or datablocks before your replace
> them.
The biggest trouble is lack of any doc about api, even in headers (that
was heppy to find mention in external.c, that object, passed to
gnuplot_init must be freed, and i did it in fini func, i still don't
get crash due to double free, which would likely happen, be i
misunderstood.
> > Yeah, i thinked deeper about was i wrote - i would express it a bit
> > different: what if same function, exported by plugin, can be
> > imported several times - with different names and arguments number?
> >
> > I was self in doubt before, because had not idea, in what form it
> > may be implemented. In other words, any importable plugin symbol
> > may have several gnuplot-side faces, or aliases, with different
> > name and args amount. This would make variadic arguments even less
> > needed. Plugin-side code should get different argn parameter,
> > depending on used face.
>
> Yes, I think that is possible without changing the current code.
I already discovered it :) One thing, that caused me to check it - that
when i repeated import command with same arguments, it did not complain.
I guess, this feature would be even more convenient for cases, when
plugin has one API-level function, which serves to call dynamically
defined functions, taking name and arguments, but with one note:
For now this has to be implemented by following sequence (example):
> import plugin_func_exec_1a(f_id, a1) from "plugin:func_exec"
> import plugin_func_exec_2a(f_id, a1, a2) from "plugin:func_exec"
> import plugun_func_exec_3a(f_id, a1, a2, a3) from "plugin:func_exec"
> r = plugin_func_add('f1', '1/x')
> r = plugin_func_add('f2', 'x^2 / sin(y)')
> r = plugin_func_add('f3', 'expr1')
> plugin_f1(x) = plugin_func_exec1a('f1', x)
> plugin_f2(x,y) = plugin_func_exec2a('f2', x, y)
> plugin_f3(x,y,z) = plugin_func_exec3a('f3', x, y, z)
or for simplicity
> plugin_f4(x) = plugin_func_exec3a('f4', x, 0, 0)
(I omit essential calls to load definitions to plugin, lets guess it is
done)
Here each dynamic function, defined in gnuplot, needs backend func,
which will pass f_id to plugin. The later case, with 'f4', will pass
more args, than function needs, though it doesn't look critical… better
more than less. But another technical issue, is that there are 2
virtual calls before real one.
However there might be another approach, with just 1 virtual call:
> import plugin_f1(='f1', x) from "plugin2:func_exec"
> import plugin_f2(='f2', x,y) from "plugin2:func_exec"
> import plugin_f3(='f3', x, =3.28, y, =0, =V) from "plugin2:func_exec"
(all numbers are from inhead /dev/random)
This variant relies on default value substitution. These virtuals will
call real aggregator with 2, 3 and 6 arguments respectively (and plugin
will get respective argn), but interface for gnuplot cli interface side
will be: plugin_f1(x), plugin_f2(x,y) and plugin_f3(x,y).
Only one virtual calls, yet with some positions prefilled. Substitution
of middle arguments, as in 3rd, would allow to define more
specific virtuals for one plugin-side virtual... it is hard for me to
guess all possible cases, where this particular feature (in 3rd case)
mey be useful. One thing, that only visited my head, is for 3d
function, when first function drawes surface with all arguments, and
second has some argument static, for example to draw slice, which will
be visible with another color (some case, when give them feature, and
they will find use for it). By preceding defaults with '=' it is
possible to use variables as values, not as placeholders.
> Here is a more polished version of the patch.
> It allows an array to be passed, but only if it is being passed
> as the sole argument to an external function (i.e. a plugin).
> I've tested this a bit.
> Please let my know if it is useful for your work.
> It can probably be added to the gnuplot development version
> if it is useful for a real-world application.
>
> Ethan
>
Due to above, i don't know, what approach is better... another
unclearance, due to lack of api doc - how value array defines its end?
Whilc for datasetarray it is NULL-terminated pointers array, for array
of struct value's it would be something else. Is it INVALID_VALUE
|