[note: this discussion got initiated outside this list]
Markus Neteler wrote:
One example as "seed" may be sufficient to get other people
interested, something like a proof of concept. This may break
the barrier to do more python and perl with GRASS.
Well, I managed to get a Grass error message from a Perl program 
I made a simple Swig interface file into which I added the main() from r.slope.aspect with a new name:
int r_slope_aspect (int argc, char **argv);
With this I get the wrapper code and the Grass Perl module. Then I made a simple Makefile.PL for the Perl extension, which lists the shared grass libs and object code files from the wrapper and the r_slope_aspect. Makefile.PL is standard, after running it gives Makefile, which is for making the necessary binaries for the Grass module and installing the module etc. I put into the test code a function call:
Grass::r_slope_aspect(1,['abc']);
which gives me the Grass error "ERROR: LOCATION_NAME not set"
I have a Grass database and I get the same error running r.slope.aspect.
I had to comment out a lot of declarations from gisdefs.h because the functions are non-existing and Perl does not tolerate that.
The tedious part would be to write typemaps for all structs in Grass code. Converting all modules into functions is a more difficult job but could probably be automated (with a suitable Perl program of course).
Ari
--
Prof. Ari Jolma
Kartografia ja Geoinformatiikka / Cartography and Geoinformatics
Teknillinen Korkeakoulu / Helsinki University of Technology
POBox 1200, 02015 TKK, Finland
Email: ari.jolma at tkk.fi URL: http://www.tkk.fi/~jolma
Ari Jolma wrote:
[note: this discussion got initiated outside this list]
Markus Neteler wrote:
>One example as "seed" may be sufficient to get other people
>interested, something like a proof of concept. This may break
>the barrier to do more python and perl with GRASS.
>
>
Well, I managed to get a Grass error message from a Perl program
I made a simple Swig interface file into which I added the main() from
r.slope.aspect with a new name:
int r_slope_aspect (int argc, char **argv);
With this I get the wrapper code and the Grass Perl module. Then I made
a simple Makefile.PL for the Perl extension, which lists the shared
grass libs and object code files from the wrapper and the
r_slope_aspect. Makefile.PL is standard, after running it gives
Makefile, which is for making the necessary binaries for the Grass
module and installing the module etc. I put into the test code a
function call:
Grass::r_slope_aspect(1,['abc']);
which gives me the Grass error "ERROR: LOCATION_NAME not set"
I have a Grass database and I get the same error running r.slope.aspect.
Are you running this from within a GRASS session? The GRASS libraries
require a number of environment variables to be set.
--
Glynn Clements <glynn@gclements.plus.com>
Glynn Clements wrote:
Ari Jolma wrote:
Well, I managed to get a Grass error message from a Perl program
I made a simple Swig interface file into which I added the main() from r.slope.aspect with a new name:
Are you running this from within a GRASS session? The GRASS libraries
require a number of environment variables to be set.
Yes, I know, but that was not the point, sorry it was probably not very evident from my post. The point was that Markus was toying with the idea of having a scripting (Perl, Python,..) interface to Grass library and modules and presented it to me. I had some time and wanted to study Swig anyway so I tried it and was able to make a Perl interface to the libraries and embed the r.slope.aspect app into it (as a function with the name r_slope_aspect). The next step would not be for me to get the program actually working (with the env vars) but make it into a standard Perl module distribution, which would install the normal way (perl Makefile.PL; make; make test; install -- it would require Grass sources and swig) so people (with more Grass use experience) could try it and we could perhaps get the ball rolling. I *think* I know now how to make such a distribution (perhaps it would be Geo-Grass-0.01.tar.gz in CPAN) but I need perhaps a day to make it (it would include the libs and some apps) -- but I can also give my knowledge/results so far to someone else who wants to work on this.
We could also discuss a bit how such Perl interface should work / look like. Using Swig makes it easier to port the interface to Python and other languages.
Ari