Hamish wrote:
> > I have checked $PATHEXT which contains beside EXE
> > also PY extension.
> > The problem is that sh.exe ignores PATHEXT, right?
>
> I'm pretty sure that is correct, PATHEXT is only
> recognized by DOS & cmd.exe
Right. But note that "cmd.exe" doesn't just mean running cmd.exe
i
Michael wrote:
> >> In our recursive landscape evolution module
> >> (r.landscape.evol.py),
...
> There are other things we're doing like working
> through long lists that might be speeded up,
> but these are in Python and Java, not GRASS.
> So they can't be helped by parallelization.
For help in
Martin wrote:
> when working with CLI (sh.exe) in winGRASS7, I am
> able to launch C-modules, eg.
> r.buffer2
>
> but not a python script
> r.buffer -> command not found
>
> The user has to type
> r.buffer.py
>
> I have checked $PATHEXT which contains beside EXE
> also PY extension.
> The problem
Michael:
> So improvements to the segment library should
> help both
[r.cost and r.walk]
Perhaps better stated as learning how to run the
segment library in parallel. The changes would be
in the modules AFAIU, not in the library per se.
(although perhaps the could be, or both the lib and
module wo
Hi all,
when working with CLI (sh.exe) in winGRASS7, I am able to launch C-modules, eg.
r.buffer2
but not a python script
r.buffer -> command not found
The user has to type
r.buffer.py
I have checked $PATHEXT which contains beside EXE also PY extension.
The problem is that sh.exe ignores PAT
Seth wrote:
> If you decide to use opencl, keep in contact and I
> might be able to help. I'm traveling for at least
> the next few days, though.
I plan to work on adding OpenCL support to the build
system soon after the OpenMP support is done.
the last missing piece for the OpenMP stuff is to
a
On Dec 3, 2011, at 3:38 PM, Hamish wrote:
> Michael wrote:
>> I lost the previous thread but wanted to respond
>> to your question about which modules might
>> benefit from speedup.
>> In our recursive landscape evolution module
>> (r.landscape.evol.py), the two GRASS modules that
>> take the mo
Hi,
2011/12/3 Hamish :
>> currently GIRC file is stored on Windows in
>>
>> $HOME/.grassrc6
>
> hmmm, I thought that already had happened. I guess
> not.
>
>> This location seems to be probably quite weird
>> for normal Windows user. I would suggest to store
>> GISRC in `$APPDATA\GRASS6\rc`.
>
> I
Michael wrote:
> I lost the previous thread but wanted to respond
> to your question about which modules might
> benefit from speedup.
> In our recursive landscape evolution module
> (r.landscape.evol.py), the two GRASS modules that
> take the most time are r.watershed, r.stats, and
> r.walk, espec
If you decide to use opencl, keep in contact and I might be able to help. I'm
traveling for at least the next few days, though.
~Seth
via iPhone
On Dec 3, 2011, at 3:07 PM, Barton Michael wrote:
> I lost the previous thread but wanted to respond to your question about which
> modules might
I lost the previous thread but wanted to respond to your question about which
modules might benefit from speedup.
In our recursive landscape evolution module (r.landscape.evol.py), the two
GRASS modules that take the most time are r.watershed, r.stats, and r.walk,
especially r.watershed and r.s
#1444: g.parser does not filter for duplicate output map statements
--+-
Reporter: neteler | Owner: grass-dev@…
Type: defect | Status: reopened
Priority: minor|
#1444: g.parser does not filter for duplicate output map statements
--+-
Reporter: neteler | Owner: grass-dev@…
Type: defect | Status: reopened
Priority: minor|
Hi Markus,
2011/12/2 Markus Neteler :
[...]
>> I think
>> that this period is perfect for GUI modules reorganization also in
>> devbr6/relbr64. I would suggest the roadmap below:
>>
>> 1) within next days reorganize wxGUI modules in devbr6 based on the
>> layout from trunk
>
> You mean: shuffle
2011/12/3 Hamish :
>> It would require to update URL in g.extension and
>> GRASS Addons Wiki page.
most of the broken links should be fixed [1].
Martin
[1]
http://grass.osgeo.org/grass-wiki/index.php?title=GRASS_AddOns&action=historysubmit&diff=14457&oldid=14413
--
Martin Landa * http://geo.
Hamish wrote:
> also fwiw, "run commands" from the era when ~/.files
> were `source`d at program startup is pretty
> meaningless in this context. if it were going to be
> renamed (ie in trunk :-) perhaps it is better to
> change it to something more understandable than a
> semi-obsolete two lette
2011/12/3 Hamish :
> And that we should do it before releasing 6.4.2
> with its (hopefully) working-for-everyone release
> of g.extension.[*]
should be done in r49504 (devbr6) and r49505 (relbr64).
Martin
--
Martin Landa * http://geo.fsv.cvut.cz/~landa
_
Hi,
2011/12/3 Hamish :
>> I think that it would be better just to move such
>> dirs to `grass6`.
>
> After reviewing this experiment I'm thinking the
> same thing.
done in r49502 & r49503.
[...]
Martin
--
Martin Landa * http://geo.fsv.cvut.cz/~landa
__
18 matches
Mail list logo
