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 * htt
#82: grass would not start
---+
Reporter: timmie |Owner: osgeo4w-...@lists.osgeo.org
Type: defect | Status: reopened
Priority: major |Component: Installer
Ve
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:
>
> - fixe
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
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
htt
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
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
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
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
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 al
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 r
(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 e
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
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 unaffec
14 matches
Mail list logo
