[GRASS-dev] GRASS6.4.1

[Helena Mitasova]

Markus,

would it be possible to prepare some plan / schedule  for releasing 6.4.1? 
There are a few things that do not work in 6.4 but work in 6.5. 

Although we just got through a semester with GRASS6.4 without any major 
disaster,
I got a more positive feedback from students using GRASS65 so obviously
GRASS6.4.1 release would be welcome. 

It would be great to get some idea whether we should plan for installing 
GRASS6.4.1 for
the next semester or stick with the current release.

thanks a lot

Helena 


On Nov 21, 2010, at 5:07 PM, Markus Neteler wrote:

> On Sun, Nov 21, 2010 at 4:33 PM, Radim Blazek  wrote:
>> The problem was with 6.4.0, current 6.4 svn seems to work OK.
> 
> Good - sooner or later we need to get out 6.4.1.
> 
> Markus
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev

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

Re: [GRASS-dev] Re: [GRASS GIS] #224: cache bug in DGLib

[Markus Neteler]

On Sun, Nov 21, 2010 at 4:33 PM, Radim Blazek  wrote:
> The problem was with 6.4.0, current 6.4 svn seems to work OK.

Good - sooner or later we need to get out 6.4.1.

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

Re: [GRASS-dev] CLI!=GUI

[Michael Barton]

6.4 was delayed to make it work on Windows. This included making a useable CLI 
for Windows. I don't use Windows but many many people do. Making GRASS work on 
Windows has been very very difficult, especially because of the recursive 
problem that there are few GRASS developers with Windows expertise because 
GRASS didn't run on Windows. Going through the pain of making this work greatly 
expanded the potential user base and potential developer base.The reason that 
GRASS can run on Windows is in a large part due to a complete restructuring of 
the user interface away from requiring X-Windows. That is, there was no way to 
use GRASS or visualize the results in a Windows environment until the 
co-development of the new GUI (beginning with TclTk in 6.3) and display 
drivers. 

There is nothing inherently wrong with releasing different parts of GRASS at 
different times.But trying to manage a single release cycle for GRASS has been 
pretty complicated and my hat is off to Markus. Trying to manage multiple 
release cycles would be more complicated. Some of the 6.4 blockers were with 
the GUI, but others were with the underlying modules (all of which run in CLI 
or GUI). For better of for worse, GRASS has a very conservative release cycle. 
This is because of the developer culture, not because of the GUI. 

Like Martin said, because GRASS is modular, anyone can compile it or use it 
with or without the GUI. I use it heavily with the GUI for some things. For 
others, I use it completely scripted, without any GUI, and called from a 
completely different environment. This kind of flexibility is a real value for 
this piece of software.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity 
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu











On Nov 21, 2010, at 10:00 AM,  wrote:

> 
> Message: 4
> Date: Sun, 21 Nov 2010 10:24:02 +0100
> From: "Francesco P. Lovergine" 
> Subject: Re: [GRASS-dev] CLI!=GUI
> To: grass-dev@lists.osgeo.org
> Message-ID: <20101121092402.gb2...@frankie.is-a-geek.org>
> Content-Type: text/plain; charset=us-ascii
> 
> On Sat, Nov 20, 2010 at 10:49:05PM +0100, Martin Landa wrote:
>> Hi,
>> 
>> 2010/11/20 Paolo Cavallini :
>> 
>>> I know it's an old thread, and that not everybody agrees, but I still 
>>> think, after
>>> talking with people more knowledgeable than me, that separating the core of 
>>> GRASS
>>> (libraries+CLI) from the GUI(s) will make the release and packaging process 
>>> faster
>>> and smoother, and the integration with other software, both desktop and 
>>> web, easier
>>> and cleaner.
>>> Can we revive the discussion about this?
>> 
>> well, my option is very subjective - wxGUI is going to be a solid GUI
>> for GRASS. Anyone can build it's own GRASS distribution without any
>> GUI (libraries and subset of the GRASS modules). But it's not task for
>> the core GRASS developers. They are creating solid environment ---
>> GRASS libraries + modules (CLI) and also the GUI. Feel free to take
>> what you what from this composition.
>> 
>> Martin
>> 
> 
> What Paolo is probably trying (also?) to say is that GUIs and core could
> have completely different release cycles. The GUI should be a component
> like any other, to be released when ready, but that should not become
> a permanent blocker of the release process, like did happen in the 
> 6.4 release. Many people (like me and many other) use Grass as a 
> scripting language and are completely uninterested in having a stable 
> GUI at all, but are interested in having a working stable core in 
> reasonable times. Of course, IMHO applies.
> 
> -- 
> Francesco P. Lovergine
> 
> 
> --

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

Re: [GRASS-dev] Re: [GRASS GIS] #224: cache bug in DGLib

[Radim Blazek]

The problem was with 6.4.0, current 6.4 svn seems to work OK.

Thanks
Radim

On Sat, Nov 20, 2010 at 2:29 PM, Markus Neteler  wrote:
> Hi Radim,
>
> On Sat, Nov 20, 2010 at 1:48 PM, Radim Blazek  wrote:
>> Hi all,
>> what is the current situation with cache bug in dglib?
>> I found that in 6.4.0 it is still buggy but it is enabled in Vlib/net.c,
>> so all the net modules may give wrong results.
>> Definitely if the cache is buggy it should not be enabled.
>
> Did you try with 6.4.0 or the (later fixed) 6.4.svn? If it still fails
> with the current 6.4.svn, do you have a test case?
>
>>> Ticket URL: 
>
> Markus
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: ERROR: G_realloc: during r.to.vect call

[antonio . rocha]

Hi Markus
I realized that I sent this email to the wrong mailing list. Here goes:


I believe it's ok:
projection: 1 (UTM)
zone:   -24
datum:  wgs84
ellipsoid:  wgs84
north:  9305500.0001
south:  9095770.0001
west:   444000
east:   689130
nsres:  30
ewres:  30
rows:   6991
cols:   8171
cells:  57123461

And my raster is:
|   Type of Map:  raster   Number of Categories:
3   |
 |   Data Type:
CELL   |
 |   Rows:
6991   |
 |   Columns:
8171   |
 |   Total Cells:
57123461   |
 |Projection: UTM (zone
-24)  |
 |N: 9305500.0001S: 9095770.0001   Res:
30 |
 |E: 689130W: 444000   Res:
30 |
 |   Range of data:min = 0  max =
3   |

So it matches. What might be causing this error/bug?

Antonio

Markus Neteler wrote:

2010/11/18 António Rocha :


Greetings

I'm running GRASS (in Windows) and, for a specific raster, when I try to run
v.to.rast I get this error:
ERROR: G_realloc: unable to allocate 3376 bytes at areas.c:678

1- Is this expectable?
2- is there any fix for this? If not, does anyone has any suggestion to
avoid this error?



Did you check the computation region with
g.region -p
? Just to be sure that extent and resolution are right...

Markus

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

Re: [GRASS-dev] CLI!=GUI

[Francesco P. Lovergine]

On Sat, Nov 20, 2010 at 10:49:05PM +0100, Martin Landa wrote:
> Hi,
> 
> 2010/11/20 Paolo Cavallini :
> 
> > I know it's an old thread, and that not everybody agrees, but I still 
> > think, after
> > talking with people more knowledgeable than me, that separating the core of 
> > GRASS
> > (libraries+CLI) from the GUI(s) will make the release and packaging process 
> > faster
> > and smoother, and the integration with other software, both desktop and 
> > web, easier
> > and cleaner.
> > Can we revive the discussion about this?
> 
> well, my option is very subjective - wxGUI is going to be a solid GUI
> for GRASS. Anyone can build it's own GRASS distribution without any
> GUI (libraries and subset of the GRASS modules). But it's not task for
> the core GRASS developers. They are creating solid environment ---
> GRASS libraries + modules (CLI) and also the GUI. Feel free to take
> what you what from this composition.
> 
> Martin
> 

What Paolo is probably trying (also?) to say is that GUIs and core could
have completely different release cycles. The GUI should be a component
like any other, to be released when ready, but that should not become
a permanent blocker of the release process, like did happen in the 
6.4 release. Many people (like me and many other) use Grass as a 
scripting language and are completely uninterested in having a stable 
GUI at all, but are interested in having a working stable core in 
reasonable times. Of course, IMHO applies.

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