[GRASS-dev] Re: [GRASS-SVN] r39185 - grass/branches/develbranch_6/gui/wxpython/docs

[Martin Landa]

Hi,

2009/9/13  :
> Author: helena
> Date: 2009-09-13 16:13:38 -0400 (Sun, 13 Sep 2009)
> New Revision: 39185

are you planning to backport this patch and r39184 backport to trunk
and relbr64? The documentation should consistent in all active
branches at this point.

Martin

-- 
Martin Landa  * http://gama.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [osgeo4w] #82: grass would not start

[OSGeo4W]

#82: grass would not start
---+
Reporter:  timmie  |Owner:  osgeo4w-...@lists.osgeo.org
Type:  defect  |   Status:  reopened   
Priority:  major   |Component:  Installer  
 Version:  |   Resolution: 
Keywords:  grass   |  
---+
Comment (by timmie):

 Hello,
 this problem still exists on my Windows XP computer with latest Grass
 (WinGRASS-6.4.0SVN-r38959-1-Setup.exe).

 The failure is definately not caused by PythonXY but by the way Python is
 included in the windows packages.

 I tried to debug:
 1) deinstalled GRASS
 2) deinstalled PythonXY
 3) installed latest GRASS => works fine.
 4) installed offical Python 2.5 =>
 http://www.python.org/ftp/python/2.5.4/python-2.5.4.msi
 5) installed offical pywintypes =>
 http://sourceforge.net/projects/pywin32/files/pywin32/Build%20214/pywin32-
 214.win32-py2.5.exe/download

 6) tried to start GRASS => no success, same error message.

 Thus, this bug is a blocker for all who have python installed besides a
 GRASS install on windows.

-- 
Ticket URL: 
OSGeo4W 
OSGeo4W is the Windows installer for the OSGeo stack.___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: v.surf.rst fixes

[Markus Neteler]

Helena,

On Wed, Aug 5, 2009 at 5:35 PM, Helena Mitasova  wrote:
> Markus,
>
> after some testing here,
> it seems that the latest fixes in  v.surf.rst submitted in dev_6 branch
> (grass65)  work
> and if there are no objections they can be included in the GRASS64 release.
> The changes:
>
> - fixed segfault if only scol is given and other instances of wrong
>  combination of parameters (including having quietly interpolating
>  categories for 3d vector data if you forget to set layer=0, which I did
>  many times)
> - fixed running out of memory problem for large point data sets (usually
>  caused problems for 10mil + points)
> - added -z flag (but layer=0 still works, in case you have some scripts with
> that) to interpolate the z-coordinate values

... was this ever submitted to 6.4? Would it be risky?

> There is still an outstanding problem with offset2 int variable overflow (on
> my machine
> for rasters around 40,000x40,000), I am just waiting the hear from Glynn on
> what the
> correct fix is - I am hoping it is as simple as changing the type of offset2.
> If anybody knows how to handle these issues properly I can post more details,

I have no idea...

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

[GRASS-dev] Re: r38992 Vect_get_num return long

[Martin Landa]

Hi,

2009/9/13 Markus Metz :
> AFAIKT, r38992 Vect_get_num return long has no effect because the number of
> features (for each type) is stored as plus_t which is int. If you want to

Right, I postponed this problem, thanks for raising it up.

> prepare the vector libs to support more than INT_MAX objects, I would
> suggest to use
>
> plus_t Vect_get_num_primitives(const struct Map_info *, int);
>
> etc and then think about what type is appropriate for plus_t.

Seems to be a good idea.

> I would suggest *not* to use long because long is the same like int on 32
> bit (4 bytes) and the same like long long int on 64 bit (8 bytes), i.e. a
> vector written with 64 bit may not be readable with 32 bit which is against
> all the efforts to keep the vector format independent of
> platform/architecture/compiler. Some unsigned integer type should work, else
> some checks would be needed similar to what Glynn recently implemented to
> get an integer type of size 8 in port_init.c. E.g. use long if possible else
> use long long if possible else fatal error, no integer of size 8 available
> (or is there something else that could have a size of 8 ?).

Right, I will change long to plus_t for now.

Martin

-- 
Martin Landa  * http://gama.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] 6.4 release

[Michael Barton]

For the record, I'm trying to fix the bug in zooming beyond the poles  
in latlon locations for TclTk. It's turned out to be more difficult  
than I thought, but I'm making progress.


Michael






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

[GRASS-dev] r38992 Vect_get_num return long

[Markus Metz]

AFAIKT, r38992 Vect_get_num return long has no effect because the number 
of features (for each type) is stored as plus_t which is int. If you 
want to prepare the vector libs to support more than INT_MAX objects, I 
would suggest to use


plus_t Vect_get_num_primitives(const struct Map_info *, int);

etc and then think about what type is appropriate for plus_t.

I would suggest *not* to use long because long is the same like int on 
32 bit (4 bytes) and the same like long long int on 64 bit (8 bytes), 
i.e. a vector written with 64 bit may not be readable with 32 bit which 
is against all the efforts to keep the vector format independent of 
platform/architecture/compiler. Some unsigned integer type should work, 
else some checks would be needed similar to what Glynn recently 
implemented to get an integer type of size 8 in port_init.c. E.g. use 
long if possible else use long long if possible else fatal error, no 
integer of size 8 available (or is there something else that could have 
a size of 8 ?).


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

Re: [GRASS-dev] suspicious warnings while compiling GRASS trunk (r39080)

[Markus Metz]

Glynn Clements wrote:

Markus Neteler wrote:
  
[...]

r39136, Fix diglib warnings



These mostly fix warnings related to Markus Metz' LFS changes, so
shouldn't be applicable to 6.4.
  
Thanks, I couldn't come up with something that works on both 32 bit and 
64 bit. Interesting solution you chose with PRI_OFF_T, I didn't know 
that is possible.


My compiler (gcc 4.3.2) on Linux 64bit now says that long long int is 
not the same like off_t, e.g.


cindex_rw.c:69: warning: format '%lld' expects type 'long long int', but 
argument 4 has type 'off_t'


although long long int and off_t are both of size 8 ???

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

Re: [GRASS-dev] OpenCL Parallelization

[Jeshua Lacock]

On Sep 12, 2009, at 12:21 PM, Benjamin Ducke wrote:


OpenCL can use CPUs and GPUs for parallel processing.
For all those operations that can be done more efficiently
on a GPU, there a potentially enormous performance gains.



Indeed. Precisely the reason why I think it is so compelling.

There are about the same number of transistors in my GPU that are in  
my CPU. Most of the time most of those transistors in my GPU are just  
sitting there idling (99% of the time I do not do any intensive 3D  
tasks), it sure would be nice to be able to put them to use.


And you can easily add more GPUs to machine, not the case with CPUs


Best,

Jeshua Lacock, Owner

phone: 208.462.4171

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

Re: [GRASS-dev] color tables

[Hamish]

Glynn wrote:
> These should be generated as part of the build process.
> Otherwise, there's no guarantee that they actually match the colour
> tables in lib/gis/colors 

great, looks good.

One thing I notice is that in grass7 the D_move_abs(), D_cont_rel()
line widths are heavier than they were in 6.x. (2px vs 1px wide)
Is it possible to make 1px again? An explicit D_line_width(0) just
makes it grey, I guess it has to be moved 1/2 a pixel from centered
on grid lines to centered mid-cell?? It seems to work ok in d.legend
which is pretty much the same code.

Also I notice that for d.colortable and d.legend that with D_end()
to close the polygon there is a pixel missing from the start/end
position here. see attached.  (hmmm, D_end() is a no-op?)


> (shouldn't those have been moved to lib/raster?).

fwiw they are used by v.colors too. (which will eventually be free
of r.* hacks)


Hamish



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

Re: [GRASS-dev] r39128 automatically choose appropriate geometry type

[Maris Nartiss]

Short note on nviz attributes - I suggest to NOT revert change that
broke this feature. I'm currently revriting attribute code, but I have
stuck in real life (work/family) and thus it will not be ready atleast
for next two weeks. It requires some redesign in OGSF, still I hope it
will be usefull also for 7.


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

Re: [GRASS-dev] i.plr.py Probabilistic Label Relaxation

[Markus Neteler]

On Fri, Sep 11, 2009 at 5:25 PM, Georg Kaspar  wrote:
> Dear GRASS developers,
> Today I finished a first attempt at writing a GRASS script in python for
> probabilistic label relaxation.
> The script uses a given sigfile to run i.maxlik for _every_ given signature
> and save the reject threshold results.
> These results are used as input for the relaxation process.
> This first version is  v e r y  slow (~ 2 min) for a 150x200 cell region and
> also the assignment of probabilities for 2 classes being next to each other
> is still very basic (1.0 if the classes are the same, 0.5 if not). But
> anyway, it seems to be working!
> This will be part of my diploma thesis and I would like to hear your
> comments. Naturally I am very interested in speeding up the whole process...
> This is my first self-made script for GRASS (not counting small
> helper-scripts), so please be kind ;)

Congratulations to your first script!

Perhaps you could post an example here (ideally based on the North Carolina
data set) to facilitate testing?

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

Re: [GRASS-dev] Re: [GRASS-stats] Sys.setlocale for GRASS6.4

[Markus Neteler]

(for the record)

On Sat, Sep 5, 2009 at 8:55 PM, Glynn Clements  wrote:
> Markus Neteler wrote:
>> >> @grass-dev: There are encoding issues with --interface-description
...
>> Apparently the Windows built was missing HAVE_LANGINFO_H or it
>> isn't properly set on Windows.
>
> This probably won't exist on Windows. I think that we can get the
> information from locale_charset(), declared in localcharset.h and
> defined in both libintl and libgettext.
>
> Can someone try the attached patch?

Glynn's patch has been backported to 6.5.svn and 6.4.svn. Hopefully
the problem is gone now.

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

Re: [GRASS-dev] suspicious warnings while compiling GRASS trunk (r39080)

[Markus Neteler]

On Sun, Sep 13, 2009 at 1:32 AM, Glynn Clements
 wrote:
> Markus Neteler wrote:
>
>> I have backported the relevant changes but I am unsure about
>> r39134, Attempt to determine message encoding on Windows [relevant for R]
>
> I think that this should be back-ported. Otherwise, I can't see
> --with-nls working on Windows, as --interface-description will
> generate invalid XML.

Ok, done (6.4 and 6.5).

>> r39136, Fix diglib warnings
>
> These mostly fix warnings related to Markus Metz' LFS changes, so
> shouldn't be applicable to 6.4.

Alright.

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

Re: [GRASS-dev] read_line bogus

[Markus Neteler]

On Sun, Sep 13, 2009 at 12:35 AM, Martin Landa  wrote:
> Hi,
>
> I realized that there is something wrong with vector library in devbr6
> and trunk, e.g.
>
> $ v.random out=p1 n=1000 --o
> ...
> Number of points: 1000
> ...
>
> $ v.info p1 -t | grep points
> points=1
>
> Relbe64 seems to be unaffected.

Confirmed for 6.4.

> Can someone reproduce this behaviour?

This version was ok:
URL: https://svn.osgeo.org/grass/grass/branches/develbranch_6
Repository Root: https://svn.osgeo.org/grass
Repository UUID: 15284696-431f-4ddb-bdfa-cd5b030d7da7
Revision: 39086

After update to 39166, even no problem...

System: Mandriva 2009.1, 64bit, no gcc optimization.

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