I have something similar in PyWPS code [1], but this looks much nicer
to me. Looking forward to adopt this.
Jachym
[1]
http://wald.intevation.org/plugins/scmsvn/viewcvs.php/trunk/pywps/Process/Process.py?rev=541&root=pywps&view=markup
look after "def cmd"
2008/7/18 Glynn Clements <[EMAIL PROTEC
Hello all!
I understand that it's summer outside (for most of us) and thus nobody wants to
sit inside and do any coding (including myself). Still I want to understand how
GRASS 7 development will be done. This thread/discussion seems to end nowwhere.
Can somebody make small announcement what o
Thanks for the series of explanations. It sounds like there is no
perfect solution, but that #!/usr/bin/env python will be most likely
to work on most systems.
For my own system, I might add a PYTHONPATH line to my .profile that
references both 'system' and 'macpython' site-packages. This m
William Kyngesburye wrote:
> > Given that the two versions are almost identical (2.5.1 vs 2.5.2), I
> > suggest setting PYTHONPATH to contain both modules' site-packages
> > directories, and nothing else.
>
> Or make sure the correct python is running.
>
> They are similar versions, but compiled
Michael Barton wrote:
> >> So it IS the shebang at the top.
> >
> > Is "python" an alias? In the shell, type "alias python" and
> > "type python".
>
> anthgradpc7:~ cmbarton$ alias python
> -bash: alias: python: not found
> anthgradpc7:~ cmbarton$ type python
> python is hashed
> (/Library/Fram
Michael Barton wrote:
> Anyway, it looks like the shebang should be #!/usr/bin/env python
> unless that is a problem on a non-Mac system. What about Windows?
For MSys, "#!/usr/bin/env python" is fine. Natively, Windows doesn't
understand #! syntax, so you would need to either:
1. Add a .py su
I just want to note something very tactfully mentioned below. That is,
all such algorithms are estimates of real watershed behavior. AFAICT,
r.watershed produces a very good estimate of these parameters and
dynamics. Nevertheless, we should be careful about trying to exactly
replicate its r
#238: error at wxGUI startup
---+
Reporter: msieczka | Owner: grass-dev@lists.osgeo.org
Type: defect| Status: closed
Priority: major | Milestone: 6.4.0
#238: error at wxGUI startup
--+-
Reporter: msieczka | Owner: grass-dev@lists.osgeo.org
Type: defect| Status: new
Priority: major | Milestone: 6.4.0
C
The important thing is that additional libraries like wxpython and
matplotlib get installed for the default version, whatever that is. We
want to make sure that a script is running the same python that you
get when you type "python" from the command line. If you *want* to run
it through a d
On Jul 29, 2008, at 3:30 PM, Glynn Clements wrote:
Michael Barton wrote:
See below...
William has already identified the core problem: scripts are using a
different version of Python to the interactive interpreter, and
presumably only one of the two versions has matplotlib installed.
If you
Michael Barton wrote:
> See below...
William has already identified the core problem: scripts are using a
different version of Python to the interactive interpreter, and
presumably only one of the two versions has matplotlib installed.
If you set PYTHONPATH, all interpreters will find modules i
voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
On Jul 29, 2008, at 1:03 PM, Glynn Clements wrote:
So it IS the shebang at the top.
Is "python" an alias? In the shell, type "alias python" and
"type python".
anthgradpc7:~ cmbarton$ alias python
-bash: alias
Michael Barton wrote:
> > It looks like, when run from a python script in GRASS, you're
> > getting the system python.
> >
> > Yet, when you run python itself from GRASS, you get the python.org
> > Python. What is the shebang line (first line) in your python
> > script, it may be pointing
On Jul 29, 2008, at 11:03 AM, William Kyngesburye wrote:
On Jul 29, 2008, at 12:42 PM, Michael Barton wrote:
Looking more closely, one is in...
/Library/Frameworks/Python.framework/Versions/2.5/bin/python
and the other is in...
/System/Library/Frameworks/Python.framework/Versions/2.5/bin/p
On Jul 29, 2008, at 12:42 PM, Michael Barton wrote:
Looking more closely, one is in...
/Library/Frameworks/Python.framework/Versions/2.5/bin/python
and the other is in...
/System/Library/Frameworks/Python.framework/Versions/2.5/bin/python
Is one of these a System Python, or has MacPython shi
On Jul 29, 2008, at 10:34 AM, William Kyngesburye wrote:
On Jul 29, 2008, at 12:15 PM, Michael Barton wrote:
cmb-MBP-2:~ cmbarton$ ls -l /usr/bin/python
lrwxr-xr-x 1 root wheel 72 May 9 15:32 /usr/bin/python -> ../../
System/Library/Frameworks/Python.framework/Versions/2.5/bin/python
c
On Jul 29, 2008, at 11:59 AM, Michael Barton wrote:
On Jul 29, 2008, at 9:54 AM, Michael Barton wrote:
Weird. When I do 'show original' for /usr/bin/python, it shows as a
symlink to
/System/Library/Frameworks/Python.framework/Versions/2.5/bin/python
...which is a symlink to /System/Library
On Jul 29, 2008, at 12:15 PM, Michael Barton wrote:
cmb-MBP-2:~ cmbarton$ ls -l /usr/bin/python
lrwxr-xr-x 1 root wheel 72 May 9 15:32 /usr/bin/python -> ../../
System/Library/Frameworks/Python.framework/Versions/2.5/bin/python
cmb-MBP-2:~ cmbarton$ ls -l /usr/local/bin/python
lrwxr-xr-x
On Jul 29, 2008, at 10:16 AM, William Kyngesburye wrote:
On Jul 29, 2008, at 11:54 AM, Michael Barton wrote:
So it IS the shebang at the top.
So what to do to make this work?
#!/usr/bin/env python
This works on my Mac. Does it work for others?
Are those literally in the shebang
On Jul 29, 2008, at 11:54 AM, Michael Barton wrote:
So it IS the shebang at the top.
So what to do to make this work?
#!/usr/bin/env python
This works on my Mac. Does it work for others?
Are those literally in the shebang? I don't know the finer
details of env, but that doesn't
On Jul 29, 2008, at 10:10 AM, William Kyngesburye wrote:
On Jul 29, 2008, at 11:59 AM, Michael Barton wrote:
On Jul 29, 2008, at 9:54 AM, Michael Barton wrote:
Weird. When I do 'show original' for /usr/bin/python, it shows as
a symlink to
/System/Library/Frameworks/Python.framework/Vers
On Jul 29, 2008, at 9:54 AM, Michael Barton wrote:
On Jul 29, 2008, at 9:37 AM, William Kyngesburye wrote:
[coming out of lurking on this one]
It looks like, when run from a python script in GRASS, you're
getting the system python.
Yet, when you run python itself from GRASS, you get th
On Jul 29, 2008, at 9:37 AM, William Kyngesburye wrote:
[coming out of lurking on this one]
It looks like, when run from a python script in GRASS, you're
getting the system python.
Yet, when you run python itself from GRASS, you get the python.org
Python. What is the shebang line (first
On Jul 29, 2008, at 11:22 AM, Michael Barton wrote:
GRASS 7.0.svn (Spearfish60_test):~ > histogram_mpldemo.py
* sys.argv ***
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/scripts/
histogram_mpldemo.py
* sys.path ***
/Applications/Grass/GRASS-7.0.app/Conte
On 29/07/08 15:40, Glynn Clements wrote:
Moritz Lennert wrote:
> To use it, you need to link the program with -lmcheck (this ensures
that mcheck() is called before the first malloc()),
Sorry, need some help on this one. Tried adding -lmcheck to CFLAGS1 in
include/Make/Platform.make, but get
Glynn,
See below...
On Jul 29, 2008, at 6:36 AM, Glynn Clements wrote:
Michael Barton wrote:
AFAICT, everything works without $PYTHONPATH in all cases EXCEPT in
a script running under the GRASS parser.
So what changes before and after g.parser?
In the scripts which I have seen so far, th
#237: r.watershed: speed improvement
--+-
Reporter: mmetz| Owner: grass-dev@lists.osgeo.org
Type: enhancement | Status: new
Priority: minor| Milestone: 6.4.0
#237: r.watershed: speed improvement
--+-
Reporter: mmetz| Owner: grass-dev@lists.osgeo.org
Type: enhancement | Status: new
Priority: minor| Milestone: 6.4.0
On Jul 28, 2008, at 9:34 AM, Glynn Clements wrote:
William Kyngesburye wrote:
Looks like we need the tcltk header paths.
In that case, I think that we're better off ditching the OSX-
specific
stuff in its entirety and going back to -I, -L and -l switches. No
-F,
no -framework.
We need
Moritz Lennert wrote:
> > > To use it, you need to link the program with -lmcheck (this ensures
> >> that mcheck() is called before the first malloc()),
> >
> > Sorry, need some help on this one. Tried adding -lmcheck to CFLAGS1 in
> > include/Make/Platform.make, but get the following during
Michael Barton wrote:
> >> AFAICT, everything works without $PYTHONPATH in all cases EXCEPT in
> >> a script running under the GRASS parser.
> >
> > So what changes before and after g.parser?
> >
> > In the scripts which I have seen so far, the imports are at the top
> > level, so they will be ex
#201: v.in.geonames wxGUI window crashes or freezes when "Verbose module output"
is checked
---+
Reporter: msieczka | Owner: martinl
Type: defect| Status: reopened
Priority: criti
#237: r.watershed: speed improvement
---+
Reporter: mmetz | Owner: grass-dev@lists.osgeo.org
Type: enhancement| Status: new
Priority: minor | Mile
On 29/07/08 10:01, Moritz Lennert wrote:
On 24/07/08 21:39, Glynn Clements wrote:
> To use it, you need to link the program with -lmcheck (this ensures
that mcheck() is called before the first malloc()),
Sorry, need some help on this one. Tried adding -lmcheck to CFLAGS1 in
include/Make/Plat
On 24/07/08 21:39, Glynn Clements wrote:
> To use it, you need to link the program with -lmcheck (this ensures
that mcheck() is called before the first malloc()),
Sorry, need some help on this one. Tried adding -lmcheck to CFLAGS1 in
include/Make/Platform.make, but get the following during co
On 28/07/08 19:50, chris carleton wrote:
Hello All - I have a question about the v.rast.stats script. I want to
maintain a MASK for the process in order to isolate portions of the
raster and attaching those stats to the vector table. In the script, any
user defined mask is temporarily renamed,
37 matches
Mail list logo
