[Gwyddion-users] running non-interactive

[Arian Sanusi]

Hi all,

I was wondering if it's possible to run gwyddion non-interactive/scripted e.g. from a Makefile, like image-magick's convert does for images.
I found documentation and examples to extend gwyddion by writing modules, this is not what I have in mind.

Best,

Arian

[Andrés Muñiz Piniella]

Post by Arian Sanusi
Hi all,
I was wondering if it's possible to run gwyddion
non-interactive/scripted e.g. from a Makefile, like image-magick's
convert does for images.
I found documentation and examples to extend gwyddion by writing
modules, this is not what I have in mind.

I think there is a python import gwy?

[David Nečas (Yeti)]

Post by Arian Sanusi
I was wondering if it's possible to run gwyddion
non-interactive/scripted e.g. from a Makefile, like image-magick's
convert does for images.

Not really but kind of. You cannot run Gwyddion itself in such manner
because it is not externally scriptable. What you can do is either:

- Write a standalone Python script that starts ‘import gwy’ (importing
the standalone gwy.so Python module) and mostly works like a pygwy
script run from within Gwyddion.

- Write a C program. See gwybatch for an example
http://gwyddion.net/apps/#gwybatch

To run data processing modules, as opposed to just calling DataField
methods and other fucntions, some more work is necessary to pretend your
program is Gwyddion. Register loaded file to the data browser:

GwyContainer *data = gwy_file_load(filename, GWY_RUN_NONINTERACTIVE, &err);
gwy_app_data_browser_add(data);
gwy_app_data_browser_set_keep_invisible(data, TRUE);

Set settings values to specifiy module behaviour:

GwyContainer *settings = gwy_app_settings_get();
gwy_container_set_double_by_name(settings, "/module/whatever/param", 1.4);

Run some data processing module:

gwy_app_data_browser_select_data_field(data, 0);
gwy_process_func_run("proc_func_name", data, GWY_RUN_IMMEDIATE);

There is some boilerplate code necessary but that can be generally
copied from gwybatch.

In Python it is similar (actually very similar to pygwy scripts).

Regards,

Yeti


------------------------------------------------------------------------------

[Arian Sanusi]

Hi Yeti,

Yeti: thank you, I'm not sure why I haven't tried the python way before. Part of it is that the idea that the python module lives in the libgwyddion2-0 deb did not occur to me.
Now I'm getting a bit of progress. It just feels rather unpythonic.

One thing I stumbled upon: I'm using debian testing's package (2.45) whose gwy module looks for these libraries:

libgwyapp2.so, libgwydgets2.so, libgwyddion2.so, libgwydraw2.so, libgwyprocess2.so, libgwymodule2.so

however they exist only with an additional .0 (libgwyapp2.so.0 etc) which are symlinks to the actual library. additional symlinks witout the dot-zeros help the python module getting started. Is that a packaging error or rather a bug in the build script?

Best,

Arian

[David Nečas (Yeti)]

Post by Arian Sanusi
It just feels rather unpythonic.

Well, a hand-maintained Python API could probably feel more pythonic but
there is not one willing to do that so what you have got is a C API
crudely hewn into a Python form...

Post by Arian Sanusi
One thing I stumbled upon: I'm using debian testing's package (2.45)
libgwyapp2.so, libgwydgets2.so, libgwyddion2.so, libgwydraw2.so,
libgwyprocess2.so, libgwymodule2.so
however they exist only with an additional .0 (libgwyapp2.so.0 etc)
which are symlinks to the actual library. additional symlinks witout
the dot-zeros help the python module getting started. Is that a
packaging error or rather a bug in the build script?

The right ones should come with the -dev package. If you do not want
the long story, just accept it kind of makes sense (you are going to
develop with Gwyddion so you need the -dev package). The only trouble
is that (IIUC) gwy.so is in the main package. I am not sure about the
Debian policies; I would either put it to a separate package or into the
-dev package...

Regards,

Yeti


------------------------------------------------------------------------------

[Arian Sanusi]

Post by David Nečas (Yeti)
Well, a hand-maintained Python API could probably feel more pythonic but
there is not one willing to do that so what you have got is a C API
crudely hewn into a Python form...

sure, no criticism intended :)

Post by David Nečas (Yeti)
The right ones should come with the -dev package. If you do not want
the long story, just accept it kind of makes sense (you are going to
develop with Gwyddion so you need the -dev package). The only trouble
is that (IIUC) gwy.so is in the main package. I am not sure about the
Debian policies; I would either put it to a separate package or into the
-dev package...

I actually looked for a python-gwyddion or similar named package, but that's obviously not debian policy. wrt -dev package: I'm developing stuff, alright. But once other start just using the stuff I write, how does that apply?

[David Nečas (Yeti)]

Post by Arian Sanusi
I actually looked for a python-gwyddion or similar named package, but
that's obviously not debian policy. wrt -dev package: I'm developing
stuff, alright. But once other start just using the stuff I write, how
does that apply?

Then the requirement is the same but makes much less sense.

The entire thing is a complex workaround for another problem... We
could dlopen() the .0 library – except that would break in other OSes
such as OS X where the naming scheme is different. So until someone
explains me how to fix it better and cross-platform it is probably going
to stay this way. Yes, you need the development Gwyddion package to run
standalone python scripts, which is an annoyance, but it is something
that can be clearly formulated and followed and things just work then.

Regards,

Yeti


------------------------------------------------------------------------------