In order for g.parser to work, the file teste.py needs to be in
your PATH.
Glynn wrote:
This is actually a bug in G_parser() and G_gui(). menuform.py is
being passed the base filename rather than the complete path.
There isn't any other reason why the script needs to be in the
#610: r.sun: incidout uses 0 instead of NULL
-+--
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: closed
Priority: normal | Milestone: 6.5.0
Hamish wrote:
In order for g.parser to work, the file teste.py needs to be in
your PATH.
Glynn wrote:
This is actually a bug in G_parser() and G_gui(). menuform.py is
being passed the base filename rather than the complete path.
There isn't any other reason why the script
Hi,
2009/7/2 John A Stevenson john.steven...@manchester.ac.uk:
My module is a shell script that works as a wrapper to the algorithm so that
it can be run from within GRASS, in much the same way as r.surf.nnbathy
too much work to rewrite it to Python? (If I can suggest please write
new modules
Hello all, and sorry for cross-posting,
this week I worked on removing parameters hardwired in the code, binding
them to the interface instead.
Therefore, now it is possible use all widgets in gstat and automap
pages, i.e. pick up the model from a list, set sill, nugget and range;
set the output
Hi Martin,
Martin Landa wrote:
too much work to rewrite it to Python?
I have in my mind to write a python version at some stage, as it isn't a
complicated script. But first I need to learn python...
I uploaded a shell script first as I have had a paper accepted about the
denoising
Martin wrote:
In GRASS7 there is no extra support for shell scripts.
This is IMO a huge, huge mistake.
I am fine that all future run-time scripts shipped with GRASS 7+ be written
in python, but I think it is a serious strategic error to force users to
learn python and rewrite all their private
Week 6 (July 3, 2009)
What did I do this week:
Fixed the Grass Raster Rendering in Ossim-Gdal plug-in, now we can
load grass raster data type (Byte, Uint16, Float32, Float64) in
imagelinker and Ossimplanet.
The rendering works great, all the ossim function like “img2rr,
create_histo,
Hi,
2009/7/3 Hamish hamis...@yahoo.com:
In GRASS7 there is no extra support for shell scripts.
This is IMO a huge, huge mistake.
I do not claim that it shouldn't be possible to run shell scripts in
GRASS7. Most of the restrictions in our lives are bad at the end;-)
Anyway I highly suggest to
Martin,
the discussion here is not about whether to write NEW scripts as
shell scripts
but whether anybody who has many shell scripts will have to rewrite
them into Python to be able to run them in GRASS7. Imagine you have
20 old,
stable, well tested scripts doing complex workflows and a
On Fri, Jul 3, 2009 at 6:26 PM, Martin Landalanda.mar...@gmail.com wrote:
2009/7/3 Hamish hamis...@yahoo.com:
In GRASS7 there is no extra support for shell scripts.
This is IMO a huge, huge mistake.
I do not claim that it shouldn't be possible to run shell scripts in
GRASS7.
Hi (just
+1 also from me. A useful extention to configure.
And harmless.
Markus
On Sat, Jun 20, 2009 at 2:10 PM, Yann Cheminyann.che...@gmail.com wrote:
+1
I have found simple data parallelism being beneficial for satellite
imagery processing (like Landsat) even with a simple dual core.
Yann
Hamish wrote:
So (IIU this C*), why should the removal of shell script support not be
reverted? What does it cost us to keep shell script support?**
[*] I suspect I may not.
The support which has been removed is limited to the build system.
If you include Script.make, the directory must
On Sun, Jun 21, 2009 at 6:39 AM, Frank Warmerdamwarmer...@pobox.com wrote:
Folks,
The database storage for the PROJ.4, GDAL and GRASS Trac instances have
been upgraded from sqlite1 to Postgres on trac.osgeo.org (osgeo1). Before
upgrading the rest of the Trac instances we are giving these a
Martin wrote:
Anyway I highly suggest to write new scripts in Python, see
[1]. Probably it's personal point of view, but writing shell
scripts was always pain for me and I can hardly imagine person
(without previous scripting experience) who prefers to learn
how to write shell scripts rather
Hamish:
So (IIU this C*), why should the removal of shell script
support not be reverted? What does it cost us to keep shell
script support?**
[*] I suspect I may not.
Glynn:
The support which has been removed is limited to the
build system.
Thank you for the clarification; sorry
16 matches
Mail list logo
