Hi,
I get it running (on Linux, winGRASS untested) when setting up the
LD_LIBRARY_PATH at system level:
su
echo "`grass71 --config path`/lib" > /etc/ld.so.conf.d/grass71.conf
ldconfig
exit
# run as normal user:
python python_test_ctypes.py
...
precip_annual@user1
/home/neteler/grassdata/nc_spm_0
On 09/05/14 10:59, Markus Neteler wrote:
Hi,
I get it running (on Linux, winGRASS untested) when setting up the
LD_LIBRARY_PATH at system level:
su
echo "`grass71 --config path`/lib" > /etc/ld.so.conf.d/grass71.conf
ldconfig
exit
# run as normal user:
python python_test_ctypes.py
...
precip_an
On 09.05.2014 00:31, Markus Neteler wrote:
On Thu, May 8, 2014 at 11:26 PM, Nikos Alexandris
wrote:
...
Could it be due to a difference in wxPython installations? In the
working
machine I have version 2.9.4.1-r2 and in the faulty one 3.0.0.0?
But this
shouldn't be a problem, right? The Re
On 08.05.2014 11:11, Nikos Alexandris wrote:
A fresh, (make dist)clean(ed) and error-free configured & compiled
grass7_trunk under Funtoo (3.12.18-KS.01) won't launch:
# /osgeo/grass70_release/bin.x86_64-unknown-linux-gnu $ ./grass70
/usr/bin/python2.7: can't open file
'/osgeo/src/grass7_trun
On Fri, May 9, 2014 at 11:52 AM, Moritz Lennert
wrote:
> On 09/05/14 10:59, Markus Neteler wrote:
>>
>> Hi,
>>
>> I get it running (on Linux, winGRASS untested) when setting up the
>> LD_LIBRARY_PATH at system level:
>>
>> su
>> echo "`grass71 --config path`/lib" > /etc/ld.so.conf.d/grass71.conf
>
On Fri, May 9, 2014 at 9:12 AM, Markus Neteler wrote:
> On Fri, May 9, 2014 at 11:52 AM, Moritz Lennert
> wrote:
> > On 09/05/14 10:59, Markus Neteler wrote:
> >>
> >> Hi,
> >>
> >> I get it running (on Linux, winGRASS untested) when setting up the
> >> LD_LIBRARY_PATH at system level:
> >>
> >>
I think that it's better to hide implementation details such as the
Map_info structure, then we don't have to worry about user code making
unexpected changes in the Map_info structures. As long as we keep track of
open maps, close/delete them when needed and implement the accessor
functions, the us
Markus,
I think it's good time to remove redundant modules and "sync" g.mlist and
g.mremove parameters before releasing 7.0. Are there missing features from
g.mlist/g.mremove that g.list/g.remove has?
Huidae
On Fri, May 2, 2014 at 10:47 AM, Markus Neteler wrote:
> On Fri, May 2, 2014 at 3:01