[GRASS5] GEM in CVS

GRASS GIS GRASS GIS developer
1

Thanks to Markus' help,
the code for the GRASS Extensions Manager (GEM) is now in the CVS.
Seeing that gis.m has made quite some progress lately and that
it will likely become the default GUI for the next stable GRASS,
this means we will be able to offer users a simple and seamless
way to download and add extensions to a running GRASS installation.
Perhaps this would be a good point to think which modules
could in the future be developed outside the GRASS base and put into
extensions.
In the next weeks I will hopefully find some time to update all
the extensions on my webpage so you can try the integration
of extensions with gis.m

Best,

Benjamin

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeo-Information Science)
Institut für Ur- und Frühgeschichte
(Institute of Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

2

Thanks to Markus' help,
the code for the GRASS Extensions Manager (GEM) is now in the CVS.

Congratulations Benjamin. GEM has great potential to help expand the
current reach and depth of GRASS in many institutions and fields of
study, as well as opening up a lot of the add-ons to a wider audience.

Perhaps this would be a good point to think which modules
could in the future be developed outside the GRASS base and put into
extensions.

It is my opinion that existing modules should not be removed from the
main distribution. GRASS should provide a wide range of basic GIS and
modelling tools to all users. I think having a full strength integrated
package, by default, is really a great selling point. This is especially
true when you consider that many of the professional GIS migrants come
from a situation of having had to, over the years, repeatedly purchase
expensive toolkits just to cover their basic needs. It is prohibitively
expensive (without breaking the law) to try out other packages which are
even slightly outside of your primary needs.

For myself, the luxury of having numerous data analysis tools right at
my fingertips, which would normally only exist outside of my usual
discipline, has really helped to broaden my scientific horizons and
analyze my data (and think!) in all sorts of interesting new ways.

Splitting GRASS up in terrain analysis, satellite imagery, hydrologic
modelling, wildfire, etc packages to me doesn't encourage a culture of
inclusiveness and giving back, but rather establishes a series of code
fiefdoms and encourages needless forking.

The great thing about GEM is that it makes it easy for folks to
collaborate with us from within their own framework, even if I'm not
at all thrilled that this might make it easier for non-Free software
to get a free ride on our hard work.

I am just worried about losing some of the best benefits that the GPL
gifts us (reinvestment of code), as well as the certain probability of
seldom used (but important to some) modules drifting outside of the
shorthanded development effort and being lost due to neglect. We need to
cherish our niche users, that's why they came here in the first place,
and they're the ones most likely to start tinkering. Side-lining them
would be a huge mistake IMO.

If GRASS grows to be a 3-CD download, I reserve the right to change my
mind.

cheers,
Hamish

3

Hi,
i just tried to install a GRASS extension via GEM.
But after the semi successful installation, my gis.m manager wont start anymore. :frowning:

This is what i have done:

I compiled GEM as it is written in the docu, then i installed the RasterTools Extension with:

gem -v --install=/home/soeren/src/RasterTools.tar.gz --grass=/usr/local/grass-6.1.cvs

This warning occurs while the installation:

WARNING: Unknown format of index.html. Unable to register HTML man pages.

Then i startet grass61 and the gis.m manager stoped with this error:

Mapset <testmapset> in Location <TestLocation>
GRASS 6.1.cvs > Error in startup script: unmatched open brace in list
    while executing
"llength $menu"
    (procedure "MainFrame::create" line 62)
    invoked from within
"MainFrame::create .mainframe -menu \n\ \"&File\"\ all\ file\ 1\ \{\n\t\ \{casca d\ \"Import\"\ \{\}\ \"\"\ 1\ \{\t\t\t\n\ \t\t\{cascad\ \"Raster\ map\"..."
    ("eval" body line 1)
    invoked from within
"eval MainFrame::create $path $args"
    (procedure "MainFrame" line 1)
    invoked from within
"MainFrame .mainframe -menu $descmenu -textvariable Gm::status -progressvar Gm::prgindic "
    (procedure "Gm::create" line 29)
    invoked from within
"Gm::create"
    (procedure "main" line 29)
    invoked from within
"main $argc $argv"
    (file "/usr/local/grass-6.1.cvs/etc/gm/gm.tcl" line 522)

The error is an unopen brace ... well .... but i have absolutely no clue of tcl and where to look
for this???
Can somebody please help me to get the gis.m back to work, without removing and installing grass again?

Many Thanks
Soeren

On Thursday 04 May 2006 09:10, Benjamin Ducke wrote:

Thanks to Markus' help,
the code for the GRASS Extensions Manager (GEM) is now in the CVS.
Seeing that gis.m has made quite some progress lately and that
it will likely become the default GUI for the next stable GRASS,
this means we will be able to offer users a simple and seamless
way to download and add extensions to a running GRASS installation.
Perhaps this would be a good point to think which modules
could in the future be developed outside the GRASS base and put into
extensions.
In the next weeks I will hopefully find some time to update all
the extensions on my webpage so you can try the integration
of extensions with gis.m

Best,

Benjamin

4

No panic,

to get gis.m back to work, just delete the menu hook in $GISBASE/etc/gm/Xtns/.

Quick fix:
There should be a file with the extension .gem in there.
This is the source of your trouble. Delete it and
gis.m will start again!

Explanation:
Extensions store menu files for gis.m in $GISBASE/etc/gm/Xtns
These files are snippets of tcl menu code with extension .gem
They must be properly formatted tcl programs!
The format is, unfortunately, a little bit tricky and every
bracket counts :wink:

But the good thing is that this allows you to use arbitratily
complex menu entries for your extension.

I suspect that your extension has a file entries-gisman2 in its
extension directory. This file contains the tcl code to be installed.
For a single module it should look something like this:

cascad "MyExtension" {} "" $tmenu {{command "Run my command" {} "r.my.cmd" {} -command {execute r.my.cmd }}}

If you don't want any of this right now, just delete entries-gisman2 from your extension files and nothing will be installed.

Don't worry about the warning. It is caused by a recent change
in the layout of $GISBASE/docs/html/index.html
I will fix this as soon as I get CVS access running.

Sören Gebbert wrote:

Hi,
i just tried to install a GRASS extension via GEM.
But after the semi successful installation, my gis.m manager wont start anymore. :frowning:

This is what i have done:

I compiled GEM as it is written in the docu, then i installed the RasterTools Extension with:

gem -v --install=/home/soeren/src/RasterTools.tar.gz --grass=/usr/local/grass-6.1.cvs

This warning occurs while the installation:

WARNING: Unknown format of index.html. Unable to register HTML man pages.

Then i startet grass61 and the gis.m manager stoped with this error:

Mapset <testmapset> in Location <TestLocation> GRASS 6.1.cvs > Error in startup script: unmatched open brace in list
    while executing
"llength $menu"
    (procedure "MainFrame::create" line 62)
    invoked from within
"MainFrame::create .mainframe -menu \n\ \"&File\"\ all\ file\ 1\ \{\n\t\ \{casca d\ \"Import\"\ \{\}\ \"\"\ 1\ \{\t\t\t\n\ \t\t\{cascad\ \"Raster\ map\"..."
    ("eval" body line 1)
    invoked from within
"eval MainFrame::create $path $args"
    (procedure "MainFrame" line 1)
    invoked from within
"MainFrame .mainframe -menu $descmenu -textvariable Gm::status -progressvar Gm::prgindic "
    (procedure "Gm::create" line 29)
    invoked from within
"Gm::create"
    (procedure "main" line 29)
    invoked from within
"main $argc $argv"
    (file "/usr/local/grass-6.1.cvs/etc/gm/gm.tcl" line 522)

The error is an unopen brace ... well .... but i have absolutely no clue of tcl and where to look for this???
Can somebody please help me to get the gis.m back to work, without removing and installing grass again?

Many Thanks
Soeren

On Thursday 04 May 2006 09:10, Benjamin Ducke wrote:

Thanks to Markus' help,
the code for the GRASS Extensions Manager (GEM) is now in the CVS.
Seeing that gis.m has made quite some progress lately and that
it will likely become the default GUI for the next stable GRASS,
this means we will be able to offer users a simple and seamless
way to download and add extensions to a running GRASS installation.
Perhaps this would be a good point to think which modules
could in the future be developed outside the GRASS base and put into
extensions.
In the next weeks I will hopefully find some time to update all
the extensions on my webpage so you can try the integration
of extensions with gis.m

Best,

Benjamin

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeo-Information Science)
Institut für Ur- und Frühgeschichte
(Institute of Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

5

On 5/4/06, Hamish <hamish_nospam@yahoo.com> wrote:

For myself, the luxury of having numerous data analysis tools right at
my fingertips, which would normally only exist outside of my usual
discipline, has really helped to broaden my scientific horizons and
analyze my data (and think!) in all sorts of interesting new ways.

I think that there are good examples of free software using
repositories of add-on packages very effectively. For example, R (the
statistics package) comes with basic functionality out of the box, but
there are dozens (maybe hundreds) of cool add-on packages that can be
downloaded and installed with a click of the mouse.

Being included in the GRASS-sanctioned package manager would be pretty
good motivation to make your code free.

The key, I think, is having a nice interface to the packages that
encourages browsing the package list and makes it really easy to
download, install and remove packages as needs change. (Note that R
packages even update the installed html manual when a new package is
downloaded!)

--
David Finlayson

6

I think that there are good examples of free software using
repositories of add-on packages very effectively. For example, R (the
statistics package) comes with basic functionality out of the box, but
there are dozens (maybe hundreds) of cool add-on packages that can be
downloaded and installed with a click of the mouse.

Sure, I've used it.

Being included in the GRASS-sanctioned package manager would be pretty
good motivation to make your code free.

Your code doesn't have to be Free to use the GEM. One of the strongest
points GEM brings to GRASS is easy integration of in-house (proprietary)
code into the main GRASS system. Customization and flexibility are
great. However, this can be used as an easy end-run around the GPL - you
are prohibited from distributing Free and non-Free binaries together.
AFAIU, the GEM will let you distribute non-Free source with GRASS
legally, and then automatically compile once at the user end.

This will help some folks out who would otherwise be stuck in a legal
bind, I'm not against helping them. I don't want us to make it too easy
for people, so they won't bother to put up a fight with their boss to
get some code released as GPL.

I hope that makes my point more clear, I am not at all anti-GEM, just
wondering how we would handle possible GPL-abuse and dilution of effort.

Hamish

7

Hmmm, interesting points being raised here.
Frankly, I developed GEM with purely functional
aspects in mind and did not worry about license
issues.
But since this is our software, I guess we are
free to add any license we want to GEM!
A dogmatic approach would be to add a license to
GEM that prohibits its use with non-GPL code.
Maybe we should have a vote on that?

Benjamin

Hamish wrote:

I think that there are good examples of free software using
repositories of add-on packages very effectively. For example, R (the
statistics package) comes with basic functionality out of the box, but
there are dozens (maybe hundreds) of cool add-on packages that can be
downloaded and installed with a click of the mouse.

Sure, I've used it.

Being included in the GRASS-sanctioned package manager would be pretty
good motivation to make your code free.

Your code doesn't have to be Free to use the GEM. One of the strongest
points GEM brings to GRASS is easy integration of in-house (proprietary)
code into the main GRASS system. Customization and flexibility are
great. However, this can be used as an easy end-run around the GPL - you
are prohibited from distributing Free and non-Free binaries together.
AFAIU, the GEM will let you distribute non-Free source with GRASS
legally, and then automatically compile once at the user end.

This will help some folks out who would otherwise be stuck in a legal
bind, I'm not against helping them. I don't want us to make it too easy
for people, so they won't bother to put up a fight with their boss to
get some code released as GPL.

I hope that makes my point more clear, I am not at all anti-GEM, just
wondering how we would handle possible GPL-abuse and dilution of effort.

Hamish

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeo-Information Science)
Institut für Ur- und Frühgeschichte
(Institute of Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg