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 clarif
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 ra
On Sun, Jun 21, 2009 at 6:39 AM, Frank Warmerdam 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 few days to
> sh
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 director
+1 also from me. A useful extention to configure.
And harmless.
Markus
On Sat, Jun 20, 2009 at 2:10 PM, Yann Chemin wrote:
> +1
>
> I have found simple data parallelism being beneficial for satellite
> imagery processing (like Landsat) even with a simple dual core.
>
> Yann
>
> 2009/6/20 GRASS GI
On Fri, Jul 3, 2009 at 6:26 PM, Martin Landa wrote:
> 2009/7/3 Hamish :
>>> 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 digging through too many emails alm
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 lot
Hi,
2009/7/3 Hamish :
>> 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 write new scrip
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,
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
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 algorithm
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 r
Hi,
2009/7/2 John A Stevenson :
> 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 in Python). In GRASS7 there is
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
#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
> > > 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
16 matches
Mail list logo
