Re: [GRASS-dev] 6.4.6 menudata.xml build error

2016-09-05 Thread Moritz Lennert 

On 05/09/16 22:20, Veronica Andreo wrote:


On Sep 5, 2016 2:11 PM, "Markus Neteler" > wrote:


On Mon, Sep 5, 2016 at 1:48 PM, Moritz Lennert
>

wrote:

> On 05/09/16 13:15, Maciej Sieczka wrote:
>>
>> W dniu 05.09.2016 o 10:45, Markus Neteler pisze:
>>>
>>> On Mon, Sep 5, 2016 at 10:08 AM, Maciej Sieczka

>

>>> wrote:

 W dniu 05.09.2016 o 01:32, Anna Petrášová pisze:
>
>
> but nothing will change in svn (except for the

howto_release.txt), so

> can't you just make a new package?


 If you asked me - release is meant to be immutable. But please do

what

 you think is right.
>>>
>>>
>>> No idea what's right.
>>> The tarball was wrong, the SVN tag is right.
>>
>>
>> So this is a bit less of an issue then.
>>
>>> What is the best practice for packaging errors? I remember that there
>>> were issues once in a PROJ4 tarball as well. But I don't recall how
>>> they dealt with it.
>>>
>>> A new full release of 6 would be a major PITA, with hours of work for
>>> me which I just spent recently on this topic.
>>
>>
>> Yup, the PITA factor should never be understimated; but easily is

from a

>> distance.
>>
>> Thanks for the new tarball. It builds fine. Hopefully nobody picked up
>> the old one for their builds.
>
>
> I think this is the major issue. Packagers who packaged immediately

after

> the announcement might have used the tar ball.

Maybe yes but
- I didn't announce it yet as usual


It was announced on the web page on Aug 29, no ?


- the Web pages still point to the old 6.4.5 version

> We should at least announce on all lists the fact that there was an

error in

> the tarball and that it is now corrected.

I did that earlier today in a README next to the tarball.

Will now edit the CMS announcement and update the download pages to
point to the new 6.4.6 (I meant to do that earlier, luckily it did not
happen yet :) )


Ops! I did change the link in the main page of the wiki some days ago...
sorry... I thought I was helping with that :P


Youn were, don't worry.

Both Windows and Mac links are still for 6.4.4 in fact (what happened to 
6.4.5 ?).


And if the only announcement was on the web page and nowhere else, I 
think we can live with it.


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

Re: [GRASS-dev] 6.4.6 menudata.xml build error

2016-09-05 Thread Veronica Andreo 
On Sep 5, 2016 2:11 PM, "Markus Neteler"  wrote:
>
> On Mon, Sep 5, 2016 at 1:48 PM, Moritz Lennert
>  wrote:
> > On 05/09/16 13:15, Maciej Sieczka wrote:
> >>
> >> W dniu 05.09.2016 o 10:45, Markus Neteler pisze:
> >>>
> >>> On Mon, Sep 5, 2016 at 10:08 AM, Maciej Sieczka 
> >>> wrote:
> 
>  W dniu 05.09.2016 o 01:32, Anna Petrášová pisze:
> >
> >
> > but nothing will change in svn (except for the howto_release.txt),
so
> > can't you just make a new package?
> 
> 
>  If you asked me - release is meant to be immutable. But please do
what
>  you think is right.
> >>>
> >>>
> >>> No idea what's right.
> >>> The tarball was wrong, the SVN tag is right.
> >>
> >>
> >> So this is a bit less of an issue then.
> >>
> >>> What is the best practice for packaging errors? I remember that there
> >>> were issues once in a PROJ4 tarball as well. But I don't recall how
> >>> they dealt with it.
> >>>
> >>> A new full release of 6 would be a major PITA, with hours of work for
> >>> me which I just spent recently on this topic.
> >>
> >>
> >> Yup, the PITA factor should never be understimated; but easily is from
a
> >> distance.
> >>
> >> Thanks for the new tarball. It builds fine. Hopefully nobody picked up
> >> the old one for their builds.
> >
> >
> > I think this is the major issue. Packagers who packaged immediately
after
> > the announcement might have used the tar ball.
>
> Maybe yes but
> - I didn't announce it yet as usual
> - the Web pages still point to the old 6.4.5 version
>
> > We should at least announce on all lists the fact that there was an
error in
> > the tarball and that it is now corrected.
>
> I did that earlier today in a README next to the tarball.
>
> Will now edit the CMS announcement and update the download pages to
> point to the new 6.4.6 (I meant to do that earlier, luckily it did not
> happen yet :) )

Ops! I did change the link in the main page of the wiki some days ago...
sorry... I thought I was helping with that :P

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

Re: [GRASS-dev] How to: if undefined, set to NULL?

2016-09-05 Thread Nikos Alexandris 

Nikos Alexandris:


> Updated in sandbox, see: https://trac.osgeo.org/grass/changeset/69365
> Is it though correct?


Vaclav Petras wrote:


I was not looking at the logic but

if (hue == -1.0) {

is not safe. Although it will probably work most of the time if you set it
to the exactly same value (`hue = -1;`),


Glynn Clements  [2016-09-05 16:46:31 +0100]:


There's no "probably" about it. If you execute "hue = -1;", a
subsequent "if (hue == -1)" comparison *will* succeed.

Rounding error only occurs when the correct result isn't exactly
representable, which isn't the case here. It doesn't occur randomly.


If using -1 is good, it seems simpler (to me, the ignorant) than trying
introducing yet another boolean flag.

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

Re: [GRASS-dev] [GRASS GIS] #2558: wxgui: profile surface map, bivariate scatter plot, histogram of raster map broken with wxPython 3.0.2 but work fine fine with 2.8

2016-09-05 Thread GRASS GIS 
#2558: wxgui: profile surface map, bivariate scatter plot, histogram of raster 
map
broken with wxPython 3.0.2 but work fine fine with 2.8
---+-
  Reporter:  humu2015  |  Owner:  grass-dev@…
  Type:  defect| Status:  closed
  Priority:  major |  Milestone:  6.4.6
 Component:  wxGUI |Version:  6.4.5
Resolution:  fixed |   Keywords:  wxgui
   CPU:  All   |   Platform:  All
---+-

Comment (by msieczka):

 Replying to [comment:22 mlennert]:
 > Done.
 >
 > Maciej, could you test ?

 It's all OK as of 6.4.6 release. Thanks!

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] How to: if undefined, set to NULL?

2016-09-05 Thread Glynn Clements 

Vaclav Petras wrote:

> > Updated in sandbox, see: https://trac.osgeo.org/grass/changeset/69365
> >
> > Is it though correct?
> >
> 
> I was not looking at the logic but
> 
> if (hue == -1.0) {
> 
> is not safe. Although it will probably work most of the time if you set it
> to the exactly same value (`hue = -1;`),

There's no "probably" about it. If you execute "hue = -1;", a
subsequent "if (hue == -1)" comparison *will* succeed.

Rounding error only occurs when the correct result isn't exactly
representable, which isn't the case here. It doesn't occur randomly.

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

[GRASS-dev] GRASS 6 REQUIREMENTS update

2016-09-05 Thread Maciej Sieczka 

r.tileset and r.in.wms require `bc'.

r.in.wms highly recommends having `xml2' installed.

Maybe it's worth adding this to G6 REQUIREMENTS.html?

Maciek

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

Re: [GRASS-dev] 6.4.6 menudata.xml build error

2016-09-05 Thread Markus Neteler 
On Mon, Sep 5, 2016 at 1:48 PM, Moritz Lennert
 wrote:
> On 05/09/16 13:15, Maciej Sieczka wrote:
>>
>> W dniu 05.09.2016 o 10:45, Markus Neteler pisze:
>>>
>>> On Mon, Sep 5, 2016 at 10:08 AM, Maciej Sieczka 
>>> wrote:

 W dniu 05.09.2016 o 01:32, Anna Petrášová pisze:
>
>
> but nothing will change in svn (except for the howto_release.txt), so
> can't you just make a new package?


 If you asked me - release is meant to be immutable. But please do what
 you think is right.
>>>
>>>
>>> No idea what's right.
>>> The tarball was wrong, the SVN tag is right.
>>
>>
>> So this is a bit less of an issue then.
>>
>>> What is the best practice for packaging errors? I remember that there
>>> were issues once in a PROJ4 tarball as well. But I don't recall how
>>> they dealt with it.
>>>
>>> A new full release of 6 would be a major PITA, with hours of work for
>>> me which I just spent recently on this topic.
>>
>>
>> Yup, the PITA factor should never be understimated; but easily is from a
>> distance.
>>
>> Thanks for the new tarball. It builds fine. Hopefully nobody picked up
>> the old one for their builds.
>
>
> I think this is the major issue. Packagers who packaged immediately after
> the announcement might have used the tar ball.

Maybe yes but
- I didn't announce it yet as usual
- the Web pages still point to the old 6.4.5 version

> We should at least announce on all lists the fact that there was an error in
> the tarball and that it is now corrected.

I did that earlier today in a README next to the tarball.

Will now edit the CMS announcement and update the download pages to
point to the new 6.4.6 (I meant to do that earlier, luckily it did not
happen yet :) )

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

Re: [GRASS-dev] 6.4.6 menudata.xml build error

2016-09-05 Thread Moritz Lennert 

On 05/09/16 13:15, Maciej Sieczka wrote:

W dniu 05.09.2016 o 10:45, Markus Neteler pisze:

On Mon, Sep 5, 2016 at 10:08 AM, Maciej Sieczka  wrote:

W dniu 05.09.2016 o 01:32, Anna Petrášová pisze:


but nothing will change in svn (except for the howto_release.txt), so
can't you just make a new package?


If you asked me - release is meant to be immutable. But please do what
you think is right.


No idea what's right.
The tarball was wrong, the SVN tag is right.


So this is a bit less of an issue then.


What is the best practice for packaging errors? I remember that there
were issues once in a PROJ4 tarball as well. But I don't recall how
they dealt with it.

A new full release of 6 would be a major PITA, with hours of work for
me which I just spent recently on this topic.


Yup, the PITA factor should never be understimated; but easily is from a
distance.

Thanks for the new tarball. It builds fine. Hopefully nobody picked up
the old one for their builds.


I think this is the major issue. Packagers who packaged immediately 
after the announcement might have used the tar ball.


We should at least announce on all lists the fact that there was an 
error in the tarball and that it is now corrected.


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

Re: [GRASS-dev] 6.4.6 menudata.xml build error

2016-09-05 Thread Maciej Sieczka 

W dniu 05.09.2016 o 10:45, Markus Neteler pisze:

On Mon, Sep 5, 2016 at 10:08 AM, Maciej Sieczka  wrote:

W dniu 05.09.2016 o 01:32, Anna Petrášová pisze:


but nothing will change in svn (except for the howto_release.txt), so
can't you just make a new package?


If you asked me - release is meant to be immutable. But please do what
you think is right.


No idea what's right.
The tarball was wrong, the SVN tag is right.


So this is a bit less of an issue then.


What is the best practice for packaging errors? I remember that there
were issues once in a PROJ4 tarball as well. But I don't recall how
they dealt with it.

A new full release of 6 would be a major PITA, with hours of work for
me which I just spent recently on this topic.


Yup, the PITA factor should never be understimated; but easily is from a
distance.

Thanks for the new tarball. It builds fine. Hopefully nobody picked up
the old one for their builds.

Maciek

--
Maciej Sieczka
http://www.sieczka.org

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

Re: [GRASS-dev] 6.4.6 menudata.xml build error

2016-09-05 Thread Markus Neteler 
On Mon, Sep 5, 2016 at 10:08 AM, Maciej Sieczka  wrote:
> W dniu 05.09.2016 o 01:32, Anna Petrášová pisze:
>>
>> but nothing will change in svn (except for the howto_release.txt), so
>> can't you just make a new package?
>
> If you asked me - release is meant to be immutable. But please do what
> you think is right.

No idea what's right.
The tarball was wrong, the SVN tag is right.

What is the best practice for packaging errors? I remember that there
were issues once in a PROJ4 tarball as well. But I don't recall how
they dealt with it.

A new full release of 6 would be a major PITA, with hours of work for
me which I just spent recently on this topic.

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

Re: [GRASS-dev] 6.4.6 menudata.xml build error

2016-09-05 Thread Markus Neteler 
On Mon, Sep 5, 2016 at 1:32 AM, Anna Petrášová  wrote:
> On Sun, Sep 4, 2016 at 3:57 PM, Markus Neteler  wrote:
>> On Sun, Sep 4, 2016 at 8:57 PM, Anna Petrášová  wrote:
>>> On Sun, Sep 4, 2016 at 11:47 AM, Markus Neteler  wrote:
 On Sun, Sep 4, 2016 at 4:42 PM, Maciej Sieczka  
 wrote:
> I just tried building
> https://grass.osgeo.org/grass64/source/grass-6.4.6.tar.gz on Arch. All
> is OK besides this one:
>
> $ pwd
> /home/dane/devel/aur/grass6/src/grass-6.4.6/gui/wxpython
>
>
> $ make
> make: *** No rule to make target
> '/home/dane/devel/aur/grass6/src/grass-6.4.6/dist.x86_64-pc-linux-gnu/etc/wxpython/xml/menudata.xml',
> needed by 'menustrings.py'.  Stop.
...
> but nothing will change in svn (except for the howto_release.txt), so
> can't you just make a new package?

ok, done:
https://grass.osgeo.org/grass64/source/grass-6.4.6.tar.gz

@Maris: this contains also the missing file which I unfortunately
dropped before creating the tarball last time.

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

Re: [GRASS-dev] 6.4.6 menudata.xml build error

2016-09-05 Thread Maciej Sieczka 

W dniu 05.09.2016 o 01:32, Anna Petrášová pisze:

but nothing will change in svn (except for the howto_release.txt), so
can't you just make a new package?


If you asked me - release is meant to be immutable. But please do what
you think is right.

Maciek

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

Re: [GRASS-dev] Fwd: [GRASS-web] Question on history of Raster Tiling in GRASS

2016-09-05 Thread Markus Neteler 
On Mon, Sep 5, 2016 at 4:05 AM, Vaclav Petras  wrote:
...
> Well, there is 3D raster library which has tiling. Formerly called G3d (Grid
> 3D?, I suppose), committed on December 29, 1999 in r9499:
>
> https://trac.osgeo.org/grass/browser/grass/trunk/lib/g3d?rev=9499

Just for the record: the libray is much older (1994?).
On December 29, 1999 we uploaded the entire GRASS GIS code base in the
brand new CVS repository to be online a day before the famous "Year
2000" bug being expected.

> There might be some scientific paper referring to it but I didn't find it.
> Here is the current library doc:
>
> https://grass.osgeo.org/programming7/raster3dlib.html

The original G3D library was developed by
(https://grass.osgeo.org/home/credits/)
--> Olga and Roman Waupotitsch: floating point, 3D raster

For history, see also (at page bottom):
https://grass.osgeo.org/home/history/releases/

and
https://grass.osgeo.org/grass41/grass1to4history.html

I found some candidate publications coauthored by Roman Waupotitsch:
- http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.35.2375
- 
https://books.google.de/books/about/Simplifying_and_Deforming_Through_Hierar.html?id=psNrNwAACAAJ_esc=y

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

Re: [GRASS-dev] How to: if undefined, set to NULL?

2016-09-05 Thread Nikos Alexandris 


Nikos Alexandris:


Updated in sandbox, see: https://trac.osgeo.org/grass/changeset/69365
Is it though correct?



Vaclav Petras:


I was not looking at the logic but

if (hue == -1.0) {

is not safe. Although it will probably work most of the time if you set it
to the exactly same value (`hue = -1;`), but it is not portable because it
is exact comparison for floats/doubles. Generally, you need to do something
like

if (fabs(hue - (-1.0)) < GRASS_EPSILON) {

However, here it might be more appropriate to signal the good or bad state
of hue by some other variable:

hue_good = FALSE;

/* setting hue here together with hue_good = TRUE */

if (!hue_good) {

/* do the null set */


Thanks Vaclav. Will try that out -- a quick run tells me that I didn't
understand yet how to do it. Will get to it.


Also, it seems that the code is not consistent with FCELL versus DCELL. I
can see DCELL *rowbuffer and Rast_is_d_null_value but also
(FCELL)saturation as well as floats and doubles. Since the input claims to
be always DCELL, use DCELL/double everywhere.


See my other post, if you have some time. Ideally, it would be smart to
have the input be autodetected, be it CELL or DCELL, ranging in [0,
2^bitness-of-input-data) while the output will be always FCELL (hue in
[0.0,360.0] and saturation/lightness in [0.0,1.0].


Related to that, although I'm never sure about where is its appropriate to
use DCELL and where double (DCELL currently gets evaluated to double:
typedef double DCELL;). I would probably use DCELL everywhere in this
function; just to make it clear that we deal purely with cell values and
there is no need to switch to anything else.


But using DCELL everywhere is a bit of waisting, if I understand
correctly. I'd like to keep things clean, even if it appears to be
unnecessary to do so on first sight.

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