Hi Glynn,
I have created a ticket for this issue:
http://trac.osgeo.org/grass/ticket/1752
So we can discuss this using the trac ticket system.
Best regards
Soeren
2012/10/1 Glynn Clements :
>
> Sören Gebbert wrote:
>
>> > The ideal solution would be to store runs of >= 254^2 as multiple
>> > run
Sören Gebbert wrote:
> > The ideal solution would be to store runs of >= 254^2 as multiple
> > runs. That would maintain backward compatibility while avoiding the
> > bug. But that would require re-writing Rast3d_rle_encode() and
> > Rast3d_rle_count_only(); there's no way that G_rle_codeLength a
2012/9/24 Glynn Clements :
>
> Sören Gebbert wrote:
>
>> >> i have tested the raster3d library and most of the related modules
>> >> intensively.
>> >> I rediscovered an ugly bug in the 3D raster run length encoding (RLE)
>> >> compression implementation and modified the library test to catch it.
Sören Gebbert wrote:
> >> i have tested the raster3d library and most of the related modules
> >> intensively.
> >> I rediscovered an ugly bug in the 3D raster run length encoding (RLE)
> >> compression implementation and modified the library test to catch it.
> >> I am unable to fix the RLE co
Hi Glynn,
2012/9/23 Glynn Clements :
>
> Sören Gebbert wrote:
>
>> i have tested the raster3d library and most of the related modules
>> intensively.
>> I rediscovered an ugly bug in the 3D raster run length encoding (RLE)
>> compression implementation and modified the library test to catch it.
Sören Gebbert wrote:
> i have tested the raster3d library and most of the related modules
> intensively.
> I rediscovered an ugly bug in the 3D raster run length encoding (RLE)
> compression implementation and modified the library test to catch it.
> I am unable to fix the RLE compression bug.
Hi,
i have tested the raster3d library and most of the related modules intensively.
I rediscovered an ugly bug in the 3D raster run length encoding (RLE)
compression implementation and modified the library test to catch it.
I am unable to fix the RLE compression bug. But it seems to me that
the ex
Markus Neteler wrote:
> thanks for r53256 (Eliminate XDR dependency from raster3d library).
> Question: can the XDR test now be eliminated from configure[.in]?
That was done in r53257.
--
Glynn Clements
___
grass-dev mailing list
grass-dev@lists.osg
On Thu, Sep 20, 2012 at 10:19 AM, Markus Neteler wrote:
...
> All GRASS 7 now compiles with the Android cross-compiler (after taking out
> XDR from configure[.in]) except for these two:
Glynn,
thanks for r53256 (Eliminate XDR dependency from raster3d library).
Question: can the XDR test now be e
Sören Gebbert wrote:
> More tests are needed, but I think it can be committed since it looks
> pretty stable.
Done in r53256. Removal of configure checks to follow.
--
Glynn Clements
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.
I am testing it.
So far the raster3d test suite runs fine as well as the module tests for
r3.cross.rast, r3.out.vtk, r3.mapcalc and r3.univar.
More tests are needed, but I think it can be committed since it looks
pretty stable. I did not detected any memory leaks yet with valgrind.
Best regards
S
Chemin, Yann (IWMI) wrote:
> Tested in Ubuntu 12.04 64 bit
> SVN compiles well all the way
I know that it compiles. The question is whether it works, i.e. can
read and write the existing 3D grid format correctly.
Markus has confirmed that reading works (although we need to test all
of int, floa
Markus Neteler wrote:
> All GRASS 7 now compiles with the Android cross-compiler (after taking out
> XDR from configure[.in]) except for these two:
> make[4]: Entering directory `/home/neteler/grass70/raster/r.terraflow'
> arm-linux-androideabi-g++ ... -std=gnu++0x ...
NOTE ---
list
Subject: Re: [GRASS-dev] Grass SVN in Android, display issue
Glynn Clements wrote:
> Currently, the configure script shouldn't abort if it can't find the
> XDR functions. If you remove the AC_MSG_ERROR, you need to add XDRLIB=
> so that it's always defined.
That shou
On Thu, Sep 20, 2012 at 9:08 AM, Glynn Clements
wrote:
>
> Markus Neteler wrote:
>
>> /home/neteler/grass70/dist.arm-unknown-linux-androideabi/bin/g.mkfontcap
>> -s > /home/neteler/grass70/dist.arm-unknown-linux-androideabi/etc/fontcap
>> /bin/sh:
>> /home/neteler/grass70/dist.arm-unknown-linux-a
Markus Neteler wrote:
> /home/neteler/grass70/dist.arm-unknown-linux-androideabi/bin/g.mkfontcap
> -s > /home/neteler/grass70/dist.arm-unknown-linux-androideabi/etc/fontcap
> /bin/sh:
> /home/neteler/grass70/dist.arm-unknown-linux-androideabi/bin/g.mkfontcap:
> cannot execute binary file
This s
On Wed, Sep 19, 2012 at 4:22 PM, Glynn Clements
wrote:
...
>> I'll look into the G3D XDR issue.
>
> Can someone test the attached patch? Not necessarily on Android; the
> first priority is ensuring that it doesn't break anything on existing
> platforms.
I have applied it locally and used the slov
On Wed, Sep 19, 2012 at 3:19 PM, Glynn Clements
wrote:
...
>> So, a high percentage of the GRASS modules do compile now (186
>> compiled, 34 fail, most of them due to the G3D lib XDR issue).
Wonderful, all patches solve the previously indicated problems.
Remaining are lib/form/ (who cares..) and
Glynn Clements wrote:
> Currently, the configure script shouldn't abort if it can't find the
> XDR functions. If you remove the AC_MSG_ERROR, you need to add XDRLIB=
> so that it's always defined.
That should have said "... should abort if ...".
> > So, a high percentage of the GRASS modules do
Markus Neteler wrote:
> > r53219 has moved the XDR functions from lib/raster to lib/gis.
> > lib/raster3d should be converted to use these.
>
> OK - a todo.
> This also affects several g.* modules and v.colors, v.surf.bspline and
> some more
> vector modules which link the G3D library, no surpri
On Tue, Sep 18, 2012 at 11:08 PM, Glynn Clements
wrote:
>
> Markus Neteler wrote:
>
>> I have (hopefully) fixed the includes in r53207, now libgis compiles.
>
> You probably shouldn't be including either of those headers directly.
> I suspect that the "correct" fix is just:
>
> #ifdef HAVE
Markus Neteler wrote:
> I have (hopefully) fixed the includes in r53207, now libgis compiles.
You probably shouldn't be including either of those headers directly.
I suspect that the "correct" fix is just:
#ifdef HAVE_TERMIOS_H
#include
#endif
> The next and last libra
On Tue, Sep 18, 2012 at 3:39 PM, Glynn Clements
wrote:
> Markus Neteler wrote:
>> ls.c: In function 'G_ls_format':
...
> If the platform defines TIOCGWINSZ, you'd think that it would define
> "struct winsize" somewhere; although it's anyone's guess as to where
> (on Linux, it's in ).
I see it her
Markus Neteler wrote:
> A few issues are in the library part:
>
> ls.c: In function 'G_ls_format':
> ls.c:173: error: storage size of 'size' isn't known
> make[3]: *** [OBJ.arm-unknown-linux-androideabi/ls.o] Error 1
> make[3]: Leaving directory `/home/neteler/grass70/lib/gis'
>
> --> use #ifde
>Markus N wrote:
>> PS: Maybe it is useless to run GRASS on Android but maybe not.. :)
Hamish B. Wrote:
>on-site field data entry tool & swiss army knife.
Highly Agree! I can see this being very useful.
Doug
Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
developers list
Subject: Re: [GRASS-dev] Grass SVN in Android, display issue
Markus N wrote:
> PS: Maybe it is useless to run GRASS on Android but maybe not.. :)
on-site field data entry tool & swiss army knife.
best,
Hamish
___
grass-dev mailing lis
Markus N wrote:
> PS: Maybe it is useless to run GRASS on Android but maybe not.. :)
on-site field data entry tool & swiss army knife.
best,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
: neteler.os...@gmail.com [neteler.os...@gmail.com] on behalf of Markus
Neteler [nete...@osgeo.org]
Sent: Tuesday, September 18, 2012 2:25 AM
To: Chemin, Yann (IWMI)
Cc: GRASS developers list
Subject: Re: [GRASS-dev] Grass SVN in Android, display issue
On Mon, Sep 17, 2012 at 5:47 AM, Chemin, Yann (IWMI
On Mon, Sep 17, 2012 at 5:47 AM, Chemin, Yann (IWMI) wrote:
> Hi all,
>
> I am looking for ways to display wxGUI of GRASS (trunk version) in Android.
Just curious: did you compile GRASS 7 on Android?
I just tried with a cross compiled
(arm-gp2x-linux-gcc-c++-4.1.2-13.fc17.x86_64),
using Marco Be
Chemin, Yann (IWMI) wrote:
> I am looking for ways to display wxGUI of GRASS (trunk version) in
> Android.
>
> The problem is that Android is not bound to X server, and that Linux
> images are directing their display to localhost:0 instead of X:0
>
> So what happens is that you can view Ubuntu
Hi all,
I am looking for ways to display wxGUI of GRASS (trunk version) in Android.
The problem is that Android is not bound to X server, and that Linux images are
directing their display to localhost:0 instead of X:0
So what happens is that you can view Ubuntu Unity in a VNC client bound to
l
31 matches
Mail list logo
