Re: [GRASS-dev] Python Scripting

[Jachym Cepicky]

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 PROTECTED]>:
>
> Glynn Clements wrote:
>
>> > As to existing modules, what about a helper function to access then?
>> >
>> > module.executeModule( name="r.stats", options={ "input":
>> > "elevation.dem,slope,aspect", "fs": ",", "output": "elev.csv"},
>> > flags=["q", "1", "n", "g"] )
>>
>> This idea has occurred to me. Some comments:
>>
>> Pass argument values as Python values, e.g. passing multiple values as
>> lists, passing numeric types directly, etc, and have the interface
>> convert them to strings. Pass the flags as a single string.
>>
>> module.execute( "r.stats",
>> options = { "input": ["elevation.dem", "slope", "aspect"],
>> "fs": ",",
>> "output": "elev.csv" },
>> flags = "q1ng" )
>>
>> Provide a lower-level function which simply generates the command to
>> pass to Popen(), for cases where you want to interact with the child
>> process.
>
> I have attached a first draft of such a module, which also includes a
> wrapper function for g.parser (for which an example script is also
> attached).
>
> --
> Glynn Clements <[EMAIL PROTECTED]>
>
>
> import os
> import os.path
> import sys
> import types
> import subprocess
>
> def _make_val(val):
>if isinstance(val, types.StringType):
>return val
>if isinstance(val, types.ListType):
>return ",".join(map(_make_val, val))
>if isinstance(val, types.TupleType):
>return _make_val(list(val))
>return str(val)
>
> def make_command(prog, options = [], flags = "", overwrite = False, quiet = 
> False, verbose = False):
>args = [prog]
>if overwrite:
>args.append("--o")
>if quiet:
>args.append("--q")
>if verbose:
>args.append("--v")
>if flags:
>args.append("-%s" % flags)
>for opt, val in options.iteritems():
>args.append("%s=%s" % (opt, _make_val(val)))
>return args
>
> def start_command(prog, options = [], flags = "", overwrite = False, quiet = 
> False, verbose = False, **kwargs):
>args = make_command(prog, options, flags, overwrite, quiet, verbose)
>return subprocess.Popen(args, **kwargs)
>
> def run_command(*args, **kwargs):
>ps = start_command(*args, **kwargs)
>return ps.wait()
>
> def _parse_env():
>options = {}
>flags = {}
>for var, val in os.environ.iteritems():
>if var.startswith("GIS_OPT_"):
>opt = var.replace("GIS_OPT_", "", 1).lower()
>options[opt] = val;
>if var.startswith("GIS_FLAG_"):
>flg = var.replace("GIS_FLAG_", "", 1).lower()
>flags[flg] = bool(int(val));
>return (options, flags)
>
> def parser():
>if not os.getenv("GISBASE"):
>print >> sys.stderr, "You must be in GRASS GIS to run this program."
>sys.exit(1)
>
>if len(sys.argv) > 1 and sys.argv[1] == "@ARGS_PARSED@":
>return _parse_env()
>
>argv = sys.argv[:]
>name = argv[0]
>if not os.path.isabs(name):
>argv[0] = os.path.normpath(os.path.join(sys.path[0], name))
>
>os.execvp("g.parser", [name] + argv)
>raise OSError("error executing g.parser")
>
> #!/usr/bin/env python
>
> # g.parser demo script for python programing
>
> import grass
>
> #%Module
> #%  description: g.parser test script (python)
> #%End
> #%flag
> #%  key: f
> #%  description: a flag
> #%END
> #%option
> #% key: raster
> #% type: string
> #% gisprompt: old,cell,raster
> #% description: raster input map
> #% required : yes
> #%end
> #%option
> #% key: vector
> #% type: string
> #% gisprompt: old,vector,vector
> #% description: vector input map
> #% required : yes
> #%end
> #%option
> #% key: option1
> #% type: string
> #% description: an option
> #% required : no
> #%end
>
> if __name__ == "__main__":
>(options, flags) = grass.parser()
>
>print ""
>if flags['f']:
>print "Flag -f set"
>else:
>print "Flag -f not set"
>
>#test if parameter present:
>if options['option1']:
>print "Value of option1: '%s'" % options['option1']
>
>print "Value of raster= option: '%s'" % options['raster']
>print "Value of vector= option: '%s'" % options['vector']
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
Jachym Cepicky
e-mail: jachym.cepicky gmail com
URL: http://les-ejk.cz
GPG: http://www.les-ejk.cz/pgp/jachym_cepicky-gpg.pub
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 7 development started

[Maris Nartiss]

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 ordinary coders[1] should do?

Currently I see that most of development is done in trunk and Martin is merging 
back to develbranch_6 [2]. 
How long we are planning to sit on two chairs and when trunk (finally) will be 
broken?

IMHO "software engineers" should break trunk in incompatible way and ordinary 
"coders" should work on modules in devbranch_6 till trunk is fixed (after major 
incompatible lib changes). Then we could port modules from dev to trunk. IMHO 
there's no use to play catch-up-with-lib-changes for modules in trunk while 
libs are not GRASS-7 ready.

Sorry for rant,
Maris.

1. http://lists.osgeo.org/pipermail/grass-dev/2008-July/038992.html
2. 
http://trac.osgeo.org/grass/search?changeset=on&q=merged+from+trunk&page=4&noquickjump=1


2008/6/13, Markus Neteler <[EMAIL PROTECTED]>:
> On Tue, Jun 10, 2008 at 7:04 AM, Markus Neteler <[EMAIL PROTECTED]> wrote:
> ...
>> Procedure:
>> Server-side:
>> - announce date/time of "indent" code reformatting
>> - publish the final parameter set
>> - run on 7.x.trunk, submit
>> - run on 6.4.branch, submit
>>
>> You local SVN copy:
>> - DON'T UPDATE YET but run
>>svn status
>> - files with local uncommitted changes ("M") need to be treated
>>   with the indent command on the *unsubmitted* changed files
>>   to avoid later update conflicts
>> - *then* update from SVN to re-sync with "svn update"
>>
>> Makes sense? Can we go ahead?
>
> Getting curious now :)
>
> Markus
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] PYTHONPATH question

[Michael Barton]

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 might  
help in other circumstances.


Michael


On Jul 29, 2008, at 8:37 PM, Glynn Clements wrote:



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 differently - one (2.5.1)
for OSX Leopard, the other (2.5.2) for Tiger and also-works-on-
Leopard.  The Mac Python list would have a better idea if this a
workable solution, or crazy.


Right. Python code isn't likely to care about the specific version,
but binary extensions might.

Michael Barton wrote:


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 different python, you should just be able to use: [path
to desired python] myscript.py.

So what is the best way to make sure that the 'default' python is  
used

in a script?


If by "default", you mean "first in $PATH", then use the /usr/bin/env
trick.

Of course, there's no guarantee that $PATH will be the same in all
contexts. E.g. if you modify PATH in ~/.bash_profile, you may get a
different result when running a script from a terminal compared to
running the same script from a GUI application.

If you want to guarantee consistency above all else, use
#!/usr/bin/python in the script. But then we would need to process
such scripts during installation (e.g. MSys doesn't have
/usr/bin/python, and it doesn't have symlinks so you can't just make
/usr/bin/python a symlink to the actual program).

--
Glynn Clements <[EMAIL PROTECTED]>


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] PYTHONPATH question

[Glynn Clements]

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 differently - one (2.5.1)  
> for OSX Leopard, the other (2.5.2) for Tiger and also-works-on- 
> Leopard.  The Mac Python list would have a better idea if this a  
> workable solution, or crazy.

Right. Python code isn't likely to care about the specific version,
but binary extensions might.

Michael Barton wrote:

> 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 different python, you should just be able to use: [path  
> to desired python] myscript.py.
> 
> So what is the best way to make sure that the 'default' python is used  
> in a script?

If by "default", you mean "first in $PATH", then use the /usr/bin/env
trick.

Of course, there's no guarantee that $PATH will be the same in all
contexts. E.g. if you modify PATH in ~/.bash_profile, you may get a
different result when running a script from a terminal compared to
running the same script from a GUI application.

If you want to guarantee consistency above all else, use
#!/usr/bin/python in the script. But then we would need to process
such scripts during installation (e.g. MSys doesn't have
/usr/bin/python, and it doesn't have symlinks so you can't just make
/usr/bin/python a symlink to the actual program).

-- 
Glynn Clements <[EMAIL PROTECTED]>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] PYTHONPATH question

[Glynn Clements]

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/Frameworks/Python.framework/Versions/Current/bin/python)

So that will be the first one in the path (although it may be
referenced through a symlink).

As for the "hashed" part, bash maintains a hashtable of name to
pathname mappings, so that it doesn't have to scan $PATH each time. It
discards the mapping if PATH is modified, although you can use "hash
-r" to manually discard the hashtable.

The only time that the hashing is likely to make itself visibile is if
you add an existing program to a directory which appears earlier in
$PATH. In that situation, bash will continue to use the hashed
location even after the same name has appeared in an earlier
directory.

> >> So what to do to make this work?
> >>
> >> #!/usr/bin/env python 
> >>
> >> This works on my Mac. Does it work for others?
> >
> > The use of /usr/bin/env is a hack to make it look for "python" in
> > $PATH. The #! syntax requires an absolute path, but there's no telling
> > where python will be installled (Python isn't part of POSIX, so you
> > can't rely up on it being installed in /usr/bin).
> >
> > The actual purpose of env is to run commands with a modified
> > environment. The reason it's being used here (without any environment
> > changes) is just because it allows the program to run to be specified
> > as a name rather than a full path, and because /usr/bin/env will
> > always be available.
> 
> So is this OK? If so, we should put this in the WIKI. Is there a  
> better alternative, since we don't know where python is going to be  
> installed?

The /usr/bin/env trick seems to be quite widely used, and there
doesn't appear to be any other way to make a python script which looks
for python in the path.

OTOH, for your particular system, it's probably a good idea to make
/usr/bin/python refer to whichever version has the most-populated
site-packages directory, as that's the most useful version.

-- 
Glynn Clements <[EMAIL PROTECTED]>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] PYTHONPATH question

[Glynn Clements]

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 suffix and add .py to PATHEXT.
2. Create a .bat wrapper (as is currently done for shell scripts).
3. Explicitly invoke the script via python.

-- 
Glynn Clements <[EMAIL PROTECTED]>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS-user] r.watershed speed-up

[Michael Barton]

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 results--as if it IS the real world. We should not  
assume a priori that because they differ slightly that the new one is  
worse. We should at least consider the possibility that the new  
r.watershed.fast algorithm is equally good as the original in that it  
can replicate it to such a high degree. The small differences between  
the two could simply be where both are less able to model real  
landscapes (flat areas) and produce equally good estimates even though  
they differ slightly. It is also possible that the new algorithm makes  
r.watershed.fast an even closer match to reality than r.watershed and  
the differences are where the new modules is better than the old one.  
These are empirical questions.


Michael

On Jul 29, 2008, at 3:41 PM, <[EMAIL PROTECTED]> wrote:


Date: Tue, 29 Jul 2008 20:46:02 +0200
From: Markus Metz <[EMAIL PROTECTED]>
Subject: Re: [GRASS-user] r.watershed speed-up
To: Charles Ehlschlaeger <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Dear Chuck,

r.watershed is a much valued tool in GRASS, for me the best watershed
analsis tool not only in GRASS, therefore I thought about a a way to
keep the results identical too. I am also aware that the closer the
results produced by changes in the algorithm are to the results  
produced

by original algorithm, the higher the chances that it will be accepted
by the community.

With regard to your suggestion, I would not adjust DEM values, because
in larger regions the minimum possible increment is already there in  
the
data, i.e. there are no gaps in the data distribution that can be  
filled

with adjusted values. One theoretical way out would be to read in DEMs
as FCELL or DCELL, but then there is the floating point comparison
problem. (I tried against better knowledge, it doesn't work).  
Regarding

the breadth first search, where do you see breadth first values are different>? You lost me there. I don't see differences in  
how
points are searched between the two versions, but maybe I have not  
fully

understood the original algorithm. As far as I have understood the
original algorithm, the list of astar_pts following astar_pts.nxt is
kept in ascending order using elevation. If there are already points
with equal elevation, the new point is inserted after all other points
with the same elevation (line 91 in original do_astar.c), so that the
point inserted first (of several points with equal elevation) will be
removed first (line 19 in original do_astar.c). This is still the case
in the new algorithm (insertion: line 136, removal: lines 31 and 192)
most of the time. If the binary heap becomes fairly large and there  
are

many points with equal elevation, there might be an exception. Please
let me know if I got something wrong there!

Another possibility to produce the exact same results like in the
original version would be to go recursively down the heap and pick the
point added earliest from all points with elevation equal to the root
point. This is easy to implement, but it would have slowed down the
search algorithm somewhat and I wanted to get something lightening  
fast.


I have one main argument why it is not a disaster if the results are  
not

100% identical:
The order in which neighbouring cells are added is in both versions,
with respect to the focus cell:
low, up, left, right, upper right corner, lower left corner, lower  
right

corner, upper left corner
This order is always kept, irrespective of the already established  
flow

direction, thus it is a random order and there is not really a reason
why the algorithm should stick to that order. I think a rare  
replacement

of that random order (2% difference of flow direction in Moritz
Lennert's test) with another random order (binary heap shuffling) is  
not
a disaster and the result is still valid. I did build in a check to  
make

results more similar, but there are still scenarios when this check
doesn't catch.

So my main question to you, the original author of r.watershed, is,  
if a

rare violation to the (in my opinion random) order in which neighbours
are added to the list would cause the results to be no longer valid.
The other question is if I should provide now a version that really
produces identical results, or if I first sort out the problem of how
neighbours are (should be) added to and removed from the list. BTW, I
tried to change the order of adding neighbours to the list too, taking
into account the already established flow direction. It produces very
straight lines in flat terrain, which is ok in hydrological terms, but
some randomness looked better. Flat terrain in th

[GRASS-dev] Re: [GRASS GIS] #238: error at wxGUI startup

[GRASS GIS]

#238: error at wxGUI startup
---+
  Reporter:  msieczka  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  closed   
  Priority:  major |   Milestone:  6.4.0
 Component:  wxGUI | Version:  svn-develbranch6 
Resolution:  wontfix   |Keywords:   
  Platform:  Linux | Cpu:  x86-64   
---+
Changes (by martinl):

  * status:  new => closed
  * resolution:  => wontfix

Comment:

 Recently I have changed format of the settings file, see r32334. Please
 update your settings file manually or re-create it.

 Closing ticket...

 Martin

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #238: error at wxGUI startup

[GRASS GIS]

#238: error at wxGUI startup
--+-
 Reporter:  msieczka  |   Owner:  grass-dev@lists.osgeo.org
 Type:  defect|  Status:  new  
 Priority:  major |   Milestone:  6.4.0
Component:  wxGUI | Version:  svn-develbranch6 
 Keywords:|Platform:  Linux
  Cpu:  x86-64|  
--+-
 develbranch6 r32363

 Start GRASS with wxGUI - an error is printed to the console:

 {{{
 Error: Reading settings from file  failed.
Details: need more than 1 value to unpack
Line: 'vdigit:symbolNodeOne:color:(255, 0, 0, 255):enabled:True'
 Error: Reading settings from file  failed.
Details: need more than 1 value to unpack
Line: 'vdigit:symbolNodeOne:color:(255, 0, 0, 255):enabled:True'
 }}}

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] PYTHONPATH question

[Michael Barton]

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 different python, you should just be able to use: [path  
to desired python] myscript.py.


So what is the best way to make sure that the 'default' python is used  
in a script?


Michael
__
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

On Jul 29, 2008, at 2:59 PM, William Kyngesburye wrote:


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 set PYTHONPATH, all interpreters will find modules in those
directories (it will even override system modules, so don't put the
system directories in PYTHONPATH, only site-packages). If PYTHONPATH
is unset, each version will use its own site-packages directory.

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 differently - one (2.5.1)  
for OSX Leopard, the other (2.5.2) for Tiger and also-works-on- 
Leopard.  The Mac Python list would have a better idea if this a  
workable solution, or crazy.


-
William Kyngesburye 
http://www.kyngchaos.com/

First Pogril: Why is life like sticking your head in a bucket filled  
with hyena offal?
Second Pogril: I don't know.  Why IS life like sticking your head in  
a bucket filled with hyena offal?

First Pogril: I don't know either.  Wretched, isn't it?

-HitchHiker's Guide to the Galaxy




___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] PYTHONPATH question

[William Kyngesburye]

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 set PYTHONPATH, all interpreters will find modules in those
directories (it will even override system modules, so don't put the
system directories in PYTHONPATH, only site-packages). If PYTHONPATH
is unset, each version will use its own site-packages directory.

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 differently - one (2.5.1) for  
OSX Leopard, the other (2.5.2) for Tiger and also-works-on-Leopard.   
The Mac Python list would have a better idea if this a workable  
solution, or crazy.


-
William Kyngesburye 
http://www.kyngchaos.com/

First Pogril: Why is life like sticking your head in a bucket filled  
with hyena offal?
Second Pogril: I don't know.  Why IS life like sticking your head in a  
bucket filled with hyena offal?

First Pogril: I don't know either.  Wretched, isn't it?

-HitchHiker's Guide to the Galaxy


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] PYTHONPATH question

[Glynn Clements]

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 in those
directories (it will even override system modules, so don't put the
system directories in PYTHONPATH, only site-packages). If PYTHONPATH
is unset, each version will use its own site-packages directory.

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.

-- 
Glynn Clements <[EMAIL PROTECTED]>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] PYTHONPATH question

[Michael Barton]

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: python: not found
anthgradpc7:~ cmbarton$ type python
python is hashed (/Library/Frameworks/Python.framework/Versions/ 
Current/bin/python)




So what to do to make this work?

#!/usr/bin/env python 

This works on my Mac. Does it work for others?


The use of /usr/bin/env is a hack to make it look for "python" in
$PATH. The #! syntax requires an absolute path, but there's no telling
where python will be installled (Python isn't part of POSIX, so you
can't rely up on it being installed in /usr/bin).

The actual purpose of env is to run commands with a modified
environment. The reason it's being used here (without any environment
changes) is just because it allows the program to run to be specified
as a name rather than a full path, and because /usr/bin/env will
always be available.


So is this OK? If so, we should put this in the WIKI. Is there a  
better alternative, since we don't know where python is going to be  
installed?


Michael
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] PYTHONPATH question

[Glynn Clements]

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 to the system python?
> >
> >
> > On Jul 27, 2008, at 7:40 PM, Michael Barton wrote:
> >
> >>> Is "python" the actual executable, or is it a front-end script?
> >>
> >> /usr/bin/python and /usr/local/bin/python are symlinks to /Library/ 
> >> Frameworks/.../python2.5, which is an executable. I've checked and  
> >> this is the only "python" in my path
> >
> > /usr/bin/python should be a symlink to the SYSTEM python.
> 
> 
> 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/Frameworks/Python.framework/ 
> Versions/2.5/bin/python2.5
> 
> BUT, if I start it...
> 
> cmb-MBP-2:~ cmbarton$ python
> Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53)
> [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>  >>>
> cmb-MBP-2:~ cmbarton$ /usr/bin/python
> Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17)
> [GCC 4.0.1 (Apple Inc. build 5465)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> ^D
> cmb-MBP-2:~ cmbarton$ /usr/bin/python2.5
> Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17)
> [GCC 4.0.1 (Apple Inc. build 5465)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>  >>>
> cmb-MBP-2:~ cmbarton$ /usr/local/bin/python
> Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53)
> [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>  >>>
> 
> So it IS the shebang at the top.

Is "python" an alias? In the shell, type "alias python" and
"type python".

> So what to do to make this work?
> 
> #!/usr/bin/env python 
> 
> This works on my Mac. Does it work for others?

The use of /usr/bin/env is a hack to make it look for "python" in
$PATH. The #! syntax requires an absolute path, but there's no telling
where python will be installled (Python isn't part of POSIX, so you
can't rely up on it being installed in /usr/bin).

The actual purpose of env is to run commands with a modified
environment. The reason it's being used here (without any environment
changes) is just because it allows the program to run to be specified
as a name rather than a full path, and because /usr/bin/env will
always be available.

-- 
Glynn Clements <[EMAIL PROTECTED]>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] PYTHONPATH question

[Michael Barton]

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/python

Is one of these a System Python, or has MacPython shifted where it  
installs?


Michael



I thought that would be obvious: /System/Library/... is the system  
python.  The MacPython packagers would have been out of their minds  
to install in there.


You never know...

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?


Michael




Technically, they're both "MacPython", or just plain "Python" since  
the MacPython packaging became the official distribution.  But it's  
still helpful to say "system python" and "MacPython" (or as I say,  
"python.org python") to distinguish between the two.


Apple builds the standard [Mac]Python, just in the system location  
(and a few tweaks, like site-packages in /Library/Python).


-
William Kyngesburye 
http://www.kyngchaos.com/

"Oh, look, I seem to have fallen down a deep, dark hole.  Now what  
does that remind me of?  Ah, yes - life."


- Marvin




___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] PYTHONPATH question

[William Kyngesburye]

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 shifted where it  
installs?


Michael



I thought that would be obvious: /System/Library/... is the system  
python.  The MacPython packagers would have been out of their minds to  
install in there.


Technically, they're both "MacPython", or just plain "Python" since  
the MacPython packaging became the official distribution.  But it's  
still helpful to say "system python" and "MacPython" (or as I say,  
"python.org python") to distinguish between the two.


Apple builds the standard [Mac]Python, just in the system location  
(and a few tweaks, like site-packages in /Library/Python).


-
William Kyngesburye 
http://www.kyngchaos.com/

"Oh, look, I seem to have fallen down a deep, dark hole.  Now what  
does that remind me of?  Ah, yes - life."


- Marvin


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] PYTHONPATH question

[Michael Barton]

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

cmb-MBP-2:~ cmbarton$ ls -l /usr/local/bin/python
lrwxr-xr-x  1 root  wheel  68 May  9 23:07 /usr/local/bin/python - 
> ../../../Library/Frameworks/Python.framework/Versions/2.5/bin/ 
python

cmb-MBP-2:~ cmbarton$



They're each pointing to the right python.


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 shifted where it  
installs?


Michael






#!/usr/bin/env python



No. The  was just me questioning if I should use that format.


So, it should work, and run Mac Python.  Or did you not have that  
there before, and *now* it's working?



-
William Kyngesburye 
http://www.kyngchaos.com/

"Mon Dieu! but they are all alike.  Cheating, murdering, lying,  
fighting, and all for things that the beasts of the jungle would not  
deign to possess - money to purchase the effeminate pleasures of  
weaklings.  And yet withal bound down by silly customs that make  
them slaves to their unhappy lot while firm in the belief that they  
be the lords of creation enjoying the only real pleasures of  
existence


- the wisdom of Tarzan




___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] PYTHONPATH question

[William Kyngesburye]

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/Frameworks/ 
Python.framework/Versions/2.5/bin/python2.5





Note that when I do a 'show original' for both symlinks /usr/bin/ 
python and /usr/local/bin/python, they both go to the same place:


/System/Library/Frameworks/Python.framework/Versions/2.5/bin/python

But one calls the System 2.5.1 and the other one calls the MacPython  
2.5.2


Michael



By "show original", do you mean right-click->show original in the  
Finder?


What about:

ls -l /usr/bin/python
ls -l /usr/local/bin/python

-
William Kyngesburye 
http://www.kyngchaos.com/

"Oh, look, I seem to have fallen down a deep, dark hole.  Now what  
does that remind me of?  Ah, yes - life."


- Marvin


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] PYTHONPATH question

[William Kyngesburye]

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  1 root  wheel  68 May  9 23:07 /usr/local/bin/python - 
> ../../../Library/Frameworks/Python.framework/Versions/2.5/bin/python

cmb-MBP-2:~ cmbarton$



They're each pointing to the right python.


#!/usr/bin/env python



No. The  was just me questioning if I should use that format.


So, it should work, and run Mac Python.  Or did you not have that  
there before, and *now* it's working?



-
William Kyngesburye 
http://www.kyngchaos.com/

"Mon Dieu! but they are all alike.  Cheating, murdering, lying,  
fighting, and all for things that the beasts of the jungle would not  
deign to possess - money to purchase the effeminate pleasures of  
weaklings.  And yet withal bound down by silly customs that make them  
slaves to their unhappy lot while firm in the belief that they be the  
lords of creation enjoying the only real pleasures of existence


- the wisdom of Tarzan


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] PYTHONPATH question

[Michael Barton]

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?  I don't know the finer  
details of env, but that doesn't look right.  Try removing them:


#!/usr/bin/env python



No. The  was just me questioning if I should use that format.

Michael
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] PYTHONPATH question

[William Kyngesburye]

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 look right.  Try removing them:


#!/usr/bin/env python

-
William Kyngesburye 
http://www.kyngchaos.com/

"We are at war with them. Neither in hatred nor revenge and with no  
particular pleasure I shall kill every ___ I can until the war is  
over. That is my duty."


"Don't you even hate 'em?"

"What good would it do if I did? If all the many millions of people of  
the allied nations devoted an entire year exclusively to hating the  
 it wouldn't kill one ___ nor shorten the war one day."


 "And it might give 'em all stomach ulcers."

- Tarzan, on war

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] PYTHONPATH question

[Michael Barton]

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/Versions/2.5/bin/python

...which is a symlink to /System/Library/Frameworks/ 
Python.framework/Versions/2.5/bin/python2.5





Note that when I do a 'show original' for both symlinks /usr/bin/ 
python and /usr/local/bin/python, they both go to the same place:


/System/Library/Frameworks/Python.framework/Versions/2.5/bin/python

But one calls the System 2.5.1 and the other one calls the  
MacPython 2.5.2


Michael



By "show original", do you mean right-click->show original in the  
Finder?


Yup




What about:

ls -l /usr/bin/python
ls -l /usr/local/bin/python



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  1 root  wheel  68 May  9 23:07 /usr/local/bin/python - 
> ../../../Library/Frameworks/Python.framework/Versions/2.5/bin/python

cmb-MBP-2:~ cmbarton$





-
William Kyngesburye 
http://www.kyngchaos.com/

"Oh, look, I seem to have fallen down a deep, dark hole.  Now what  
does that remind me of?  Ah, yes - life."


- Marvin




___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] PYTHONPATH question

[Michael Barton]

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 the python.org  
Python.  What is the shebang line (first line) in your python  
script, it may be pointing to the system python?



On Jul 27, 2008, at 7:40 PM, Michael Barton wrote:


Is "python" the actual executable, or is it a front-end script?


/usr/bin/python and /usr/local/bin/python are symlinks to /Library/ 
Frameworks/.../python2.5, which is an executable. I've checked and  
this is the only "python" in my path


/usr/bin/python should be a symlink to the SYSTEM python.




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/Frameworks/Python.framework/ 
Versions/2.5/bin/python2.5





Note that when I do a 'show original' for both symlinks /usr/bin/ 
python and /usr/local/bin/python, they both go to the same place:


/System/Library/Frameworks/Python.framework/Versions/2.5/bin/python

But one calls the System 2.5.1 and the other one calls the MacPython  
2.5.2


Michael

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] PYTHONPATH question

[Michael Barton]

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 line) in your python  
script, it may be pointing to the system python?



On Jul 27, 2008, at 7:40 PM, Michael Barton wrote:


Is "python" the actual executable, or is it a front-end script?


/usr/bin/python and /usr/local/bin/python are symlinks to /Library/ 
Frameworks/.../python2.5, which is an executable. I've checked and  
this is the only "python" in my path


/usr/bin/python should be a symlink to the SYSTEM python.




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/Frameworks/Python.framework/ 
Versions/2.5/bin/python2.5


BUT, if I start it...

cmb-MBP-2:~ cmbarton$ python
Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
cmb-MBP-2:~ cmbarton$ /usr/bin/python
Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> ^D
cmb-MBP-2:~ cmbarton$ /usr/bin/python2.5
Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
cmb-MBP-2:~ cmbarton$ /usr/local/bin/python
Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>

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?

Michael




___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] PYTHONPATH question

[William Kyngesburye]

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/Contents/MacOS/scripts
/Library/Python/2.5/site-packages/GDAL-1.5.2-py2.5-macosx-10.5- 
i386.egg

/Applications/Grass/GRASS-7.0.app/Contents/MacOS/etc/python
/Users/cmbarton
/usr/local/lib/wxPython-unicode-2.8.8.1/lib/python2.5/site-packages
/usr/local/lib/wxPython-unicode-2.8.8.1/lib/python2.5/site-packages/ 
wx-2.8-mac-unicode
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python25.zip

/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/plat-darwin
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/plat-mac
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/plat-mac/lib-scriptpackages
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/ 
python
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/lib-tk
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/lib-dynload

/Library/Python/2.5/site-packages
/usr/local/lib/wxPython-unicode-2.8.8.1/lib/python2.5
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/ 
python/PyObjC





Traceback (most recent call last):
 File "/Applications/Grass/GRASS-7.0.app/Contents/MacOS/scripts/ 
histogram_mpldemo.py", line 104, in 

   import matplotlib
ImportError: No module named matplotlib
GRASS 7.0.svn (Spearfish60_test):~ >


[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 line) in your python script,  
it may be pointing to the system python?



On Jul 27, 2008, at 7:40 PM, Michael Barton wrote:


Is "python" the actual executable, or is it a front-end script?


/usr/bin/python and /usr/local/bin/python are symlinks to /Library/ 
Frameworks/.../python2.5, which is an executable. I've checked and  
this is the only "python" in my path


/usr/bin/python should be a symlink to the SYSTEM python.

-
William Kyngesburye 
http://www.kyngchaos.com/

"Oh, look, I seem to have fallen down a deep, dark hole.  Now what  
does that remind me of?  Ah, yes - life."


- Marvin


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] d.thematic.area: need for a bit of help in C-programming/debugging

[Moritz Lennert]

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 the following during compilation:


gcc: -lmcheck: linker input file unused because linking not done

How do I link ?


Duh, obviously this message appears only each of the individual .c 
files. Linking is done afterwards...


Sorry for the noise,


Actually, I should have said LINK_FLAGS rather than CFLAGS1.


Yes, found that one out in the meantime. I seem to have narrowed the 
problem down to a particular pointer, but haven't had the time to see 
where exactly it overflows.


Thanks!

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] PYTHONPATH question

[Michael Barton]

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, the imports are at the top
level, so they will be executed on both occasions. I can't think of
any reason why an import would fail when the script is run initially
but then work when the script is re-invoked from g.parser.

Can you add commands to print sys.argv and sys.path (and, if you can
import "os", os.environ) to the top of the script, and see what is
changing before and after g.parser.


I'm not sure I understand. The structure is a 'standard GRASS script'
for Python.

##

#!/usr/bin/python


At this point, put:

import sys
print sys.argv
print sys.path

import os
print os.environ


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/Contents/MacOS/scripts
/Library/Python/2.5/site-packages/GDAL-1.5.2-py2.5-macosx-10.5-i386.egg
/Applications/Grass/GRASS-7.0.app/Contents/MacOS/etc/python
/Users/cmbarton
/usr/local/lib/wxPython-unicode-2.8.8.1/lib/python2.5/site-packages
/usr/local/lib/wxPython-unicode-2.8.8.1/lib/python2.5/site-packages/ 
wx-2.8-mac-unicode
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python25.zip

/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/ 
plat-darwin
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/ 
plat-mac
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/ 
plat-mac/lib-scriptpackages
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/ 
python
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/ 
lib-tk
/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/ 
lib-dynload

/Library/Python/2.5/site-packages
/usr/local/lib/wxPython-unicode-2.8.8.1/lib/python2.5
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/ 
python/PyObjC


* os.environ ***

_
HISTFILE
GRASS_FONT
GRASS_HTML_BROWSER
TERM_PROGRAM_VERSION
CVS_RSH
GRASS_SH
USER
HOME
PATH
GRASS_GNUPLOT
DISPLAY
TERM_PROGRAM
LANG
GRASS_ADDON_PATH
TERM
Apple_PubSub_Socket_Render
INFOPATH
SHLVL
SECURITYSESSIONID
GRASS_PAGER
HISTSIZE
EDITOR
MANPATH
GISBASE
CVSROOT
TK_LIBRARY
GRASS_PERL
PYTHONPATH
SSH_AUTH_SOCK
GRASS_HTML_BROWSER_MACOSX
TCL_LIBRARY
DYLD_LIBRARY_PATH
PWD
SHELL
GRASS_XTERM
GRASS_ADDON_ETC
GRASS_OS_STARTUP
TMPDIR
PERL5LIB
GRASS_LD_LIBRARY_PATH
GRASS_PROJSHARE
GRASS_PYTHON
__CF_USER_TEXT_ENCODING
GRASS_WISH
GISRC
GRASS_TCLSH
GRASS_VERSION
GRASS_FONT_CAP
LOGNAME
GIS_LOCK
COMMAND_MODE
Traceback (most recent call last):
  File "/Applications/Grass/GRASS-7.0.app/Contents/MacOS/scripts/ 
histogram_mpldemo.py", line 104, in 

import matplotlib
ImportError: No module named matplotlib
GRASS 7.0.svn (Spearfish60_test):~ >



.

This works fine if I type the following on at the GRASS command  
prompt

before executing

PYTHONPATH="/Library/Frameworks/Python.framework/Versions/2.5/lib/
python2.5/site-packages"$PYTHONPATH


There ought to be a colon between the literal and $PYTHONPATH.


Typo in the email. It is usually there.



Unless it's started with the -S switch, the Python interpreter
performs an automatic "import site". This module adds the
site-packages directory to sys.path; it also adds each subdirectory
which is named in one fo the site-packages/*.pth files.

http://docs.python.org/lib/module-site.html

It shoudn't be necessary for PYTHONPATH to be set unless you need to
use modules which aren't installed in Python's lib directory.

Are any of the other PYTHON* environment variables set? If
$PYTHONSTARTUP is set, that could cause an interactive interpreter to
behave differently from a script.


Not that I've set anywhere. $PYTHONSTARTUP is not set.




You could try starting python with and without the -S flag, printing
sys.path in each case. It's possible that there's some oddity in your
setup that is causing site.py to misbehave.


with -S does not have any site-packages; without -S has site-packages.  
See below.


GRASS 7.0.svn (Spearfish60_test):~ > python
Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53)
[GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> print '\n'.join(sys.path)

/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site- 
packages/Dabo-0.8.3-py2.5.egg
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site- 
packages/setuptools-0.6c8-py2.5.egg
/Library/Frameworks/Python.framework/Version

[GRASS-dev] Re: [GRASS GIS] #237: r.watershed: speed improvement

[GRASS GIS]

#237: r.watershed: speed improvement
--+-
  Reporter:  mmetz|   Owner:  grass-dev@lists.osgeo.org
  Type:  enhancement  |  Status:  new  
  Priority:  minor|   Milestone:  6.4.0
 Component:  Raster   | Version:  6.3.0
Resolution:   |Keywords:  r.watershed speed
  Platform:  All  | Cpu:  All  
--+-
Comment (by mmetz):

 I have a stupid question: in what form?
 Only the files I changed, diff output, or the whole directory with
 modified front and makefiles so that the front will be called
 r.watershed.fast and call r.watershed.ram.fast instead of r.watershed.ram?

 I did not yet attach the code because the mailing list etiquette strongly
 discourages that and it is publicly available at
 http://markus.metz.giswork.googlepages.com/r.watershed_fast_version.tar.gz

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #237: r.watershed: speed improvement

[GRASS GIS]

#237: r.watershed: speed improvement
--+-
  Reporter:  mmetz|   Owner:  grass-dev@lists.osgeo.org
  Type:  enhancement  |  Status:  new  
  Priority:  minor|   Milestone:  6.4.0
 Component:  Raster   | Version:  6.3.0
Resolution:   |Keywords:  r.watershed speed
  Platform:  All  | Cpu:  All  
--+-
Changes (by msieczka):

  * platform:  Unspecified => All
  * cpu:  Unspecified => All

Comment:

 Please attach the code.

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] debugging nviz with TclTk 8.5 aqua

[William Kyngesburye]

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 needed the -framework flags because -l would get the system tcltk
symlinks.


Er, not if you also use -L, surely?

Yes, because the aqua framework does not install lib symlinks - there  
is nothing to link to using -ltcl -ltk.  So we must use the -framework  
flags.






Tcltk aqua is half a framework, in effect, because the includes are  
not quite right.  It may be considered a bug, but the tcltk developers  
may just have been lazy and expect us to use -I flags.  It doesn't  
seem to bother anyone to do so, or it would have been noticed and  
fixed long ago.


-
William Kyngesburye 
http://www.kyngchaos.com/

"We are at war with them. Neither in hatred nor revenge and with no  
particular pleasure I shall kill every ___ I can until the war is  
over. That is my duty."


"Don't you even hate 'em?"

"What good would it do if I did? If all the many millions of people of  
the allied nations devoted an entire year exclusively to hating the  
 it wouldn't kill one ___ nor shorten the war one day."


 "And it might give 'em all stomach ulcers."

- Tarzan, on war

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] d.thematic.area: need for a bit of help in C-programming/debugging

[Glynn Clements]

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 compilation:
> > 
> > gcc: -lmcheck: linker input file unused because linking not done
> > 
> > How do I link ?
> 
> 
> Duh, obviously this message appears only each of the individual .c 
> files. Linking is done afterwards...
> 
> Sorry for the noise,

Actually, I should have said LINK_FLAGS rather than CFLAGS1.

-- 
Glynn Clements <[EMAIL PROTECTED]>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] PYTHONPATH question

[Glynn Clements]

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 executed on both occasions. I can't think of
> > any reason why an import would fail when the script is run initially
> > but then work when the script is re-invoked from g.parser.
> >
> > Can you add commands to print sys.argv and sys.path (and, if you can
> > import "os", os.environ) to the top of the script, and see what is
> > changing before and after g.parser.
> 
> I'm not sure I understand. The structure is a 'standard GRASS script'  
> for Python.
> 
> ##
> 
> #!/usr/bin/python

At this point, put:

import sys
print sys.argv
print sys.path

import os
print os.environ

When you run the script, you should get two lots of output, one from
before g.parser, one from when the script is re-invoked. Unless
g.parser is never being invoked in the first place.

> This works fine if I type the following on at the GRASS command prompt  
> before executing
> 
> PYTHONPATH="/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
> python2.5/site-packages"$PYTHONPATH

There ought to be a colon between the literal and $PYTHONPATH.

> I thought I'd show you how setting PYTHONPATH in Init.sh was causing  
> the trouble, but discovered something that seems a bit odd. I tried  
> unsetting PYTHONPATH and got the same results as before.
> 
> GRASS 7.0.svn (Spearfish60_test):~ > $PYTHONPATH
> bash: /Applications/Grass/GRASS-7.0.app/Contents/MacOS/etc/python:: No  
> such file or directory

To print a variable, use "echo", e.g. "echo $PYTHONPATH". If you just
type "$PYTHONPATH", the shell will try to execute its value as a
command.

> GRASS 7.0.svn (Spearfish60_test):~ > export PYTHONPATH=""
> GRASS 7.0.svn (Spearfish60_test):~ > $PYTHONPATH
> GRASS 7.0.svn (Spearfish60_test):~ >
> GRASS 7.0.svn (Spearfish60_test):~ > histogram_mpldemo.py
> Traceback (most recent call last):
>File "/Applications/Grass/GRASS-7.0.app/Contents/MacOS/scripts/ 
> histogram_mpldemo.py", line 93, in 
>  import matplotlib
> ImportError: No module named matplotlib
> 
> 
> If I start Python from the GRASS command prompt, sys.path is as before  
> and $PYTHONPATH is unset.  So what is setting the search path for  
> Python modules now?

Unless it's started with the -S switch, the Python interpreter
performs an automatic "import site". This module adds the
site-packages directory to sys.path; it also adds each subdirectory
which is named in one fo the site-packages/*.pth files.

http://docs.python.org/lib/module-site.html

It shoudn't be necessary for PYTHONPATH to be set unless you need to
use modules which aren't installed in Python's lib directory.

Are any of the other PYTHON* environment variables set? If
$PYTHONSTARTUP is set, that could cause an interactive interpreter to
behave differently from a script.

You could try starting python with and without the -S flag, printing
sys.path in each case. It's possible that there's some oddity in your
setup that is causing site.py to misbehave.

-- 
Glynn Clements <[EMAIL PROTECTED]>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #201: v.in.geonames wxGUI window crashes or freezes when "Verbose module output" is checked

[GRASS GIS]

#201: v.in.geonames wxGUI window crashes or freezes when "Verbose module output"
is checked
---+
  Reporter:  msieczka  |   Owner:  martinl 
  Type:  defect|  Status:  reopened
  Priority:  critical  |   Milestone:  6.4.0   
 Component:  wxGUI | Version:  svn-develbranch6
Resolution:|Keywords:  
  Platform:  Linux | Cpu:  x86-64  
---+
Changes (by martinl):

  * status:  closed => reopened
  * resolution:  fixed =>

Comment:

 Ticket reopened. I have commented-out EnsureCaretVisible() in goutput
 module (r32357). This method is quite useful, need to be fixed or figured
 out why it's sometimes crashing.

 Martin

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #237: r.watershed: speed improvement

[GRASS GIS]

#237: r.watershed: speed improvement
---+
 Reporter:  mmetz  |   Owner:  grass-dev@lists.osgeo.org
 Type:  enhancement|  Status:  new  
 Priority:  minor  |   Milestone:  6.4.0
Component:  Raster | Version:  6.3.0
 Keywords:  r.watershed speed  |Platform:  Unspecified  
  Cpu:  Unspecified|  
---+
 I want to suggest a new sorting algorithm for  in
 r.watershed.

 The A * Search is only interested in the cell with the lowest elevation
 within the list of candidates, in case of several cells with equal
 elevation, in the cell that was added earliest to the list. This can be
 done with a binary min-heap and would not change the A * algorithm, it
 would provide near identical results with a substantial increase in speed.

 Using a binary min-heap, r.watershed is faster than r.terraflow. Compared
 to the currently used linear array, speed improvement with a binary heap
 as sorting method is not constant, but increases with the number of cells
 analysed.

-- 
Ticket URL: 
GRASS GIS 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] d.thematic.area: need for a bit of help in C-programming/debugging

[Moritz Lennert]

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/Platform.make, but get the following during compilation:


gcc: -lmcheck: linker input file unused because linking not done

How do I link ?



Duh, obviously this message appears only each of the individual .c 
files. Linking is done afterwards...


Sorry for the noise,

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] d.thematic.area: need for a bit of help in C-programming/debugging

[Moritz Lennert]

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 compilation:


gcc: -lmcheck: linker input file unused because linking not done

How do I link ?

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.rast.stats

[Moritz Lennert]

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, but I don't see a place in the 
script where a mask is created - by the script - for use in the stats 
operation. So, can I just take out the mask renaming portion of the 
script? 


AFAICT, it depends on whether you want to use the mask also on the cover 
vector map. If yes, then just remove that part, if not, then move it to 
just before the line saying "#loop over cats and calculate statistics:" 
(line 274).


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev