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

[Glynn Clements]

Markus Neteler wrote:

>   I am speaking about "Quit" and "Help" in the entrance page and the
> module dialog buttons.
> 
>   I have used strace and it does not open any wxpython locale file
> (other JA files yes).

>  Apparently the same problem applies - wxstd.mo not considered?

It appears that wxPython's NLS needs to be explicitly initialised by
creating a wx.Locale() object[1], and this isn't happening.

http://wiki.wxpython.org/Internationalization

http://docs.wxwidgets.org/stable/wx_wxlocale.html

[1] You don't need to *do* anything with the object; simply creating
it makes it active:

The call of this function has several global side effects
which you should understand: first of all, the application
locale is changed - note that this will affect many of
standard C library functions such as printf() or strftime(). 
Second, this wxLocale object becomes the new current global
locale for the application and so all subsequent calls to
wxGetTranslation() will try to translate the messages using
the message catalogs for this locale.

I'm guessing that we may need to explicitly revert e.g. LC_NUMERIC to
avoid writing files with a comma as the decimal separator.

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

[GRASS-dev] [GRASS GIS] #872: spelling mistakes in man pages

[GRASS GIS]

#872: spelling mistakes in man pages
---+
 Reporter:  hamish |   Owner:  grass-dev@lists.osgeo.org
 Type:  defect |  Status:  new  
 Priority:  trivial|   Milestone:  6.5.0
Component:  default| Version:  svn-trunk
 Keywords:  man, help  |Platform:  All  
  Cpu:  All|  
---+
 Hi,

 Debian's lintian package checker reported these (potential) spelling
 mistakes in man pages:

 http://lintian.debian.org/maintainer/pkg-grass-
 de...@lists.alioth.debian.org.html#grass

 GRASS 6.4.0~rc5+40109-1

 {{{
 #  W spelling-error-in-manpage

 * usr/share/man/man1/d.nviz.1grass.gz paramters parameters
 * usr/share/man/man1/d.nviz.1grass.gz seperated separated
 * usr/share/man/man1/htmlmapdriver.1grass.gz accomodate accommodate
 * usr/share/man/man1/photo.2image.1grass.gz choosen chosen
 * usr/share/man/man1/r.in.gdal.1grass.gz comand command
 * usr/share/man/man1/r.le.pixel.1grass.gz ang and
 * usr/share/man/man1/r.out.vtk.1grass.gz choosen chosen
 * usr/share/man/man1/r.out.vtk.1grass.gz choosen chosen
 * usr/share/man/man1/r.profile.1grass.gz seperated separated
 * usr/share/man/man1/r.sun.1grass.gz explicitely explicitly
 * usr/share/man/man1/r.tileset.1grass.gz seperate separate
 * usr/share/man/man1/r.tileset.1grass.gz seperated separated
 * usr/share/man/man1/r.tileset.1grass.gz seperated separated
 * usr/share/man/man1/r.tileset.1grass.gz seperated separated
 * usr/share/man/man1/r3.out.vtk.1grass.gz choosen chosen
 * usr/share/man/man1/v.surf.idw.1grass.gz specifed specified
 * usr/share/man/man1/v.to.points.1grass.gz paramter parameter
 * usr/share/man/man1/variables.1grass.gz dependant dependent
 * usr/share/man/man1/variables.1grass.gz dependant dependent
 * usr/share/man/man1/variables.1grass.gz dependant dependent
 }}}

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

[GRASS-dev] Re: [GRASS GIS] #782: Please provide swig generated stuff in distributed tarballs

[GRASS GIS]

#782: Please provide swig generated stuff in distributed tarballs
--+-
  Reporter:  frankie  |   Owner:  grass-dev@lists.osgeo.org
  Type:  enhancement  |  Status:  new  
  Priority:  normal   |   Milestone:  6.4.0
 Component:  SWIG (all bindings)  | Version:  svn-trunk
Resolution:   |Keywords:   
  Platform:  All  | Cpu:  Unspecified  
--+-
Changes (by neteler):

  * milestone:  6.5.0 => 6.4.0

Comment:

 I have downgraded swig, recompiled 6.4 from scratch and still no wxGUI (it
 comes up when removing wx-nviz and wx-vdigit):

 {{{
 GRASS 6.4.0svn (nc_spm_08):~/grass64/dist.x86_64-unknown-linux-
 gnu/etc/wxpython/vdigit > ldd _grass6_wxvdigit.so  | grep wx
 libwx_gtk2u-2.8.so.0 => /usr/lib/wxPython/lib/libwx_gtk2u-2.8.so.0
 (0x7f2d1f12f000)

 swig -version
 SWIG Version 1.3.36
 }}}

 Do I have to recompile all wx RPM packages as well?

 Markus

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

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

[Markus Neteler]

On Fri, Jan 15, 2010 at 2:27 AM, Glynn Clements
 wrote:
>
> Martin Landa wrote:
>
>> >>> Are you sure that the buttons are translated on your machine
>> >>> without these changes?
>> >>
>> >> yes. Martin
>> >
>> > As mentioned: not on Mandriva, not on XP.
>> > Confirmed also on Windows7 from another colleague.. Due you have
>> > unsubmitted changes?
>>
>> tested on Debian GNU/Linux and MS Windows XP with Czech locale.
>> Buttons are localized without need to define label manually (tomorrow
>> I will test on MS Windows Server 2008). I would incline to find out
>> why it's not working on your system and to revert your changes.
>
> The built-in translations should be in e.g.:
>
> C:\Program 
> Files\Python26\Lib\site-packages\wx-2.8-msw-unicode\wx\locale\ja\LC_MESSAGES\wxstd.mo

Linux:
- I found /usr/lib/wxPython/share/locale/ja/LC_MESSAGES/wxstd.mo to be
absent, after
  reinstallation of the RPM package the file is now available.
  Reverting locally to the previous version, recompilation: button
translation lost.
  I am speaking about "Quit" and "Help" in the entrance page and the
module dialog buttons.

  I have used strace and it does not open any wxpython locale file
(other JA files yes).
  This are the accesses to wx:

  strace grass70 -wx 2 > log
   grep wx log
execve("/usr/local/bin/grass70", ["grass70", "-wx"], [/* 86 vars */]) = 0
execve("/usr/bin/python", ["python", "/usr/local/bin/grass70", "-wx"],
[/* 86 vars */]) = 0
open("/usr/lib64/python2.6/site-packages/wx.pth", O_RDONLY) = 4
read(4, "wx-2.8-gtk2-unicode\n", 8192)  = 20
stat("/usr/lib64/python2.6/site-packages/wx-2.8-gtk2-unicode",
{st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat("/usr/lib64/python2.6/site-packages/wx-2.8-gtk2-unicode",
{st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat("/usr/lib64/python2.6/site-packages/wx-2.8-gtk2-unicode",
{st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat("/usr/lib64/python2.6/site-packages/wx-2.8-gtk2-unicode/sitecustomize",
0x7fffcc543bd0) = -1 ENOENT (No such file or directory)
open("/usr/lib64/python2.6/site-packages/wx-2.8-gtk2-unicode/sitecustomize.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib64/python2.6/site-packages/wx-2.8-gtk2-unicode/sitecustomizemodule.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib64/python2.6/site-packages/wx-2.8-gtk2-unicode/sitecustomize.py",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib64/python2.6/site-packages/wx-2.8-gtk2-unicode/sitecustomize.pyc",
O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/python2.6/site-packages/wx-2.8-gtk2-unicode/usercustomize",
0x7fffcc543bd0) = -1 ENOENT (No such file or directory)
open("/usr/lib64/python2.6/site-packages/wx-2.8-gtk2-unicode/usercustomize.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib64/python2.6/site-packages/wx-2.8-gtk2-unicode/usercustomizemodule.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib64/python2.6/site-packages/wx-2.8-gtk2-unicode/usercustomize.py",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib64/python2.6/site-packages/wx-2.8-gtk2-unicode/usercustomize.pyc",
O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/python2.6/site-packages/wx-2.8-gtk2-unicode/org",
0x7fffcc5406e0) = -1 ENOENT (No such file or directory)
open("/usr/lib64/python2.6/site-packages/wx-2.8-gtk2-unicode/org.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib64/python2.6/site-packages/wx-2.8-gtk2-unicode/orgmodule.so",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib64/python2.6/site-packages/wx-2.8-gtk2-unicode/org.py",
O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib64/python2.6/site-packages/wx-2.8-gtk2-unicode/org.pyc",
O_RDONLY) = -1 ENOENT (No such file or directory)


 Relevant excerpts:
...
mprotect(0x7f640cd31000, 16384, PROT_READ) = 0
mprotect(0x604000, 4096, PROT_READ) = 0
mprotect(0x7f640cf56000, 4096, PROT_READ) = 0
munmap(0x7f640cf32000, 138951)  = 0
open("/usr/share/locale/locale-archive", O_RDONLY) = -1 ENOENT (No
such file or directory)
brk(0)  = 0x638000
brk(0x659000)   = 0x659000
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=2570, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7f640cf53000
read(3, "# Locale name alias data base.\n#"..., 4096) = 2570
read(3, "", 4096)   = 0
close(3)= 0
...
open("/usr/share/locale/ja/LC_MESSAGES/SYS_LC_MESSAGES", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=95, ...}) = 0
mmap(NULL, 95, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f640cf4d000
close(3)= 0
...

munmap(0x7f21ba11, 4096)= 0
open("/usr/lib64/python2.6/site-packages/wx.pth", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=20, ...}) = 0
fstat(4, {st_mode=S_IFREG|064

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

[Glynn Clements]

Martin Landa wrote:

> >>> Are you sure that the buttons are translated on your machine
> >>> without these changes?
> >>
> >> yes. Martin
> >
> > As mentioned: not on Mandriva, not on XP.
> > Confirmed also on Windows7 from another colleague.. Due you have
> > unsubmitted changes?
> 
> tested on Debian GNU/Linux and MS Windows XP with Czech locale.
> Buttons are localized without need to define label manually (tomorrow
> I will test on MS Windows Server 2008). I would incline to find out
> why it's not working on your system and to revert your changes.

The built-in translations should be in e.g.:

C:\Program 
Files\Python26\Lib\site-packages\wx-2.8-msw-unicode\wx\locale\ja\LC_MESSAGES\wxstd.mo

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

Re: [GRASS-dev] Re: [GRASS GIS] #869: Compile libs with -fexception

[Glynn Clements]

Martin Landa wrote:

> > Whichever approach is used, any code calling G_fatal_error() is
> > entitled to assume that it won't be called again, so it doesn't need
> > to perform clean-up.
> 
> OFT, some clean-up (at module level) would be reasonable, e.g. to
> delete output raster/vector map if module fails.

I was referring specifically to clean-up of in-memory data structures.

Output raster maps are written to a temporary file, which is renamed
into place when the map is closed. If an error occurs, it will result
in a temporary file being left behind, rather than affecting any
existing output map.

This could probably be handled better (e.g. support files are normally
overwritten in place), but this would be better addressed as part of a
more wide-ranging re-organisation of the database layout. There was
some discussion here a while back, although nothing concrete came of
it. It isn't easy to fix without substantially affecting the API.

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

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

[Martin Landa]

Hi,

2010/1/15 Markus Neteler :
>>> Are you sure that the buttons are translated on your machine
>>> without these changes?
>>
>> yes. Martin
>
> As mentioned: not on Mandriva, not on XP.
> Confirmed also on Windows7 from another colleague.. Due you have
> unsubmitted changes?

tested on Debian GNU/Linux and MS Windows XP with Czech locale.
Buttons are localized without need to define label manually (tomorrow
I will test on MS Windows Server 2008). I would incline to find out
why it's not working on your system and to revert your changes.

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: [GRASS-SVN] r40421 - grass/branches/develbranch_6/gui/wxpython

[Markus Neteler]

On Fri, Jan 15, 2010 at 12:13 AM, Martin Landa  wrote:
> Hi,
>
> 2010/1/15 Markus Neteler :
>
> [...]
>
>> Are you sure that the buttons are translated on your machine
>> without these changes?
>
> yes. Martin

As mentioned: not on Mandriva, not on XP.
Confirmed also on Windows7 from another colleague.. Due you have
unsubmitted changes?

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

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

[Martin Landa]

Hi,

2010/1/15 Markus Neteler :

[...]

> Are you sure that the buttons are translated on your machine
> without these changes?

yes. 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: [GRASS-SVN] r40421 - grass/branches/develbranch_6/gui/wxpython

[Markus Neteler]

Hi Martin,

as proven on Linux and Windows, they are not automatically
translated. I would be glad to not clutter the code and to revert
this. The shortcuts should work as before, see
http://trac.osgeo.org/grass/changeset/40442

In the translations, it will be in any case another shortcut since
the words are different.

Are you sure that the buttons are translated on your machine
without these changes?

Markus

On Thu, Jan 14, 2010 at 10:50 AM, Martin Landa  wrote:
> Hi,
>
> these buttons should be translated by the system's locales. I am not
> sure if it's good practice to translate them locally. At least you
> disabled standard shortcuts, e.g. &Help.
>
> Martin
>
> 2010/1/14  :
>> Author: neteler
>> Date: 2010-01-13 18:32:36 -0500 (Wed, 13 Jan 2010)
>> New Revision: 40421
>>
>> Modified:
>>   grass/branches/develbranch_6/gui/wxpython/gis_set.py
>> Log:
>> enable i18N for 'Quit' and 'Help'
>>
>> Modified: grass/branches/develbranch_6/gui/wxpython/gis_set.py
>> ===
>> --- grass/branches/develbranch_6/gui/wxpython/gis_set.py        2010-01-13 
>> 23:32:27 UTC (rev 40420)
>> +++ grass/branches/develbranch_6/gui/wxpython/gis_set.py        2010-01-13 
>> 23:32:36 UTC (rev 40421)
>> @@ -121,9 +121,11 @@
>>         self.bstart = wx.Button(parent=self.panel, id=wx.ID_ANY,
>>                                 label=_("Start GRASS"))
>>         self.bstart.SetDefault()
>> -        self.bexit = wx.Button(parent=self.panel, id=wx.ID_EXIT)
>> +        self.bexit = wx.Button(parent=self.panel, id=wx.ID_EXIT,
>> +                                label=_("Quit"))
>>         self.bstart.SetMinSize((180, self.bexit.GetSize()[1]))
>> -        self.bhelp = wx.Button(parent=self.panel, id=wx.ID_HELP)
>> +        self.bhelp = wx.Button(parent=self.panel, id=wx.ID_HELP,
>> +                                label=_("Help"))
>>         self.bbrowse = wx.Button(parent=self.panel, id=wx.ID_ANY,
>>                                  label=_("Browse"))
>>         self.bmapset = wx.Button(parent=self.panel, id=wx.ID_ANY,
>>
>> ___
>> grass-commit mailing list
>> grass-com...@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-commit
>>
>
>
>
> --
> 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

Re: [GRASS-dev] Re: [GRASS GIS] #869: Compile libs with -fexception

[Martin Landa]

Hi,

2010/1/14 Glynn Clements :

[...]

> Whichever approach is used, any code calling G_fatal_error() is
> entitled to assume that it won't be called again, so it doesn't need
> to perform clean-up.

OFT, some clean-up (at module level) would be reasonable, e.g. to
delete output raster/vector map if module fails.

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

Re: [GRASS-dev] Re: [GRASS GIS] #869: Compile libs with -fexception

[Glynn Clements]

Radim Blazek wrote:

> Thanks for the suggestion. The title of
> http://trac.osgeo.org/qgis/ticket/1878 is however "remove
> setjmp/longjmp in grass plugin&provider and use exceptions instead" so
> the intention was to remove setjmp/longjmp.
> I don't know exactly if there were problems with setjmp/longjmp or it
> was just attempt to improve the code. Using exceptions is certainly
> better.

Whichever approach is used, any code calling G_fatal_error() is
entitled to assume that it won't be called again, so it doesn't need
to perform clean-up.

If you leave the error handler via longjmp() or an exception, then
re-enter the GRASS libraries, all bets are off.

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

Re: [GRASS-dev] grass is a monad?

[Glynn Clements]

Paul Kelly wrote:

> So, I feel the idea behind Glynn's comments (and one that I guess I would 
> agree with) is that we encourage other projects to use GRASS by calling 
> the modules directly. As GRASS has so few developers compared to the 
> massive body of code, putting in extra development time to make GRASS work 
> in ways that have no benefit for GRASS is just too much effort.

That's about right.

Maybe I can elaborate:

1. The GRASS libraries handle errors by calling exit(). This avoids
the need for callers to explicitly handle errors and for either the
caller or callee to perform cleanup.

It's possible to avoid the call to exit() by installing an error
handler which longjmp()s out; However: it is implied that calling
G_fatal_error() relieves the caller of the responsibility to restore
GRASS data structures to a consistent state. If you longjmp() out of
the error handler, then make further calls to GRASS functions, they
may crash.

This is Not A Bug. Calling into GRASS after a fatal error *is* a bug.

2. The GRASS libraries don't bother tracking (and freeing) memory
which would only represent a fixed overhead for a GRASS module, or
which would typically not be freed until shortly before termination. 

If an operation uses a small amount of memory (e.g. a map name) and is
typically performed once or a few times per map, we don't care about
freeing it. A module will inevitably need some amount of memory for
each map which it opens, and if the difference between freeing and not
freeing means that the amount is 15Kb rather than 10Kb, then it
doesn't really matter.

It all gets returned to the OS when the module terminates anyhow.

If you try to write a persistent application which continually opens
and closes maps, eventually the accumulated leaks will cause it to run
out of memory.

This too is Not A Bug. Not isolating distinct operations in distinct
processes *is* a bug.

Both of these strategies make it much easier to both implement the
GRASS libraries and to use them, and they work perfectly well for the
libraries' intended purpose: writing GRASS modules.

If it means that they aren't suitable for other purposes, that is
Not A Bug.

For any changes, the main concern is how those changes impact GRASS
itself. If the changes impose extra effort on anyone writing GRASS
modules, or (to a lesser extent) anyone modifiying the libraries, then
those changes would be a net loss for GRASS.

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

[GRASS-dev] Re: [GRASS GIS] #869: Compile libs with -fexception

[GRASS GIS]

#869: Compile libs with -fexception
--+-
  Reporter:  rblazek  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  closed   
  Priority:  normal   |   Milestone:  6.5.0
 Component:  Compiling| Version:  unspecified  
Resolution:  worksforme   |Keywords:   
  Platform:  Unspecified  | Cpu:  All  
--+-
Comment (by frankie):

 Replying to [comment:9 rblazek]:
 > Replying to [comment:8 hamish]:
 > > fwiw, wrt. -fexceptions, Francesco commented on the DebianGIS list:
 > >
 > {{{
 >  This would be required for any C library linked by Qgis. This is out of
 discussion.
 >  Qgis has to manage correctly C libraries by providing wrappers to raise
 execeptions
 >  when C calls fail, else people will start asking that libc too supports
 >  exceptions, soon or later...
 > }}}
 >
 > Probably he does not know, that GRASS libraries can call exit(). No
 wrapper can help in that situation AFAIK.

 Right, libc and system calls ;-) Out of joking, those cases requires
 refining the library design, not dirty work arounds with limited results.

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

Re: [GRASS-dev] Re: [GRASS GIS] #869: Compile libs with -fexception

[Radim Blazek]

Thanks for the suggestion. The title of
http://trac.osgeo.org/qgis/ticket/1878 is however "remove
setjmp/longjmp in grass plugin&provider and use exceptions instead" so
the intention was to remove setjmp/longjmp.
I don't know exactly if there were problems with setjmp/longjmp or it
was just attempt to improve the code. Using exceptions is certainly
better.

Radim

On Thu, Jan 14, 2010 at 4:59 PM, Soeren Gebbert
 wrote:
> I use in vtk.grass-bridge (C++ -VTK GRASS wrapper) a different approach.
> http://code.google.com/p/vtk-grass-bridge/
>
> Replacing the G_fatal_error() function and using the setjmp/longjmp
> construct allows you to catch all errors from grass, inclusively stack
> restoration. Glynn made this suggestion. :)
>
> This function replace G_fatal_error(), to set with
> G_set_error_routine(vgb_error_handler);:
>
> int vgb_error_handler(const char *msg, int fatal)
> {
>    if (fatal == 0)
>    {
>        fprintf(stderr, "%s\n", msg);
>        return 1;
>    }
>    else
>    {
>        fprintf(stderr, "\n## Exceptiont called ###\n");
>        vgb_error_message = msg;
>        longjmp(vgb_stack_buffer, 1);
>    }
>    return 1;
> }
>
>
> This is an example how to handle fatal errors (old example, still
> check for return value):
>    if (!setjmp(vgb_stack_buffer))
>    {
>        if (Rast_get_row(this->Map, this->RasterBuff, idx, this->MapType) < 0)
>        {
>            error = 1;
>        }
>    }
>    else
>    {
>        this->InsertNextError(vgb_error_message);
>        return NULL;
>    }
>
> Code examples from:
> http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/Common/vtkGRASSDefines.h
> http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/Common/vtkGRASSInit.cxx
> http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/Raster/vtkGRASSRasterMapBase.cxx
>
> Soeren
>
>
> 2010/1/14 GRASS GIS :
>> #869: Compile libs with -fexception
>> --+-
>>  Reporter:  rblazek      |       Owner:  grass-...@lists.osgeo.org
>>      Type:  defect       |      Status:  closed
>>  Priority:  normal       |   Milestone:  6.5.0
>>  Component:  Compiling    |     Version:  unspecified
>> Resolution:  worksforme   |    Keywords:
>>  Platform:  Unspecified  |         Cpu:  All
>> --+-
>> Comment (by rblazek):
>>
>>  Replying to [comment:8 hamish]:
>>  > fwiw, wrt. -fexceptions, Francesco commented on the DebianGIS list:
>>  >
>>  {{{
>>  This would be required for any C library linked by Qgis. This is out of
>>  discussion.
>>  Qgis has to manage correctly C libraries by providing wrappers to raise
>>  execeptions
>>  when C calls fail, else people will start asking that libc too supports
>>  exceptions, soon or later...
>>  }}}
>>
>>  Probably he does not know, that GRASS libraries can call exit(). No
>>  wrapper can help in that situation AFAIK.
>>
>> --
>> Ticket URL: 
>> GRASS GIS 
>>
>> ___
>> 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
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Re: [GRASS GIS] #869: Compile libs with -fexception

[Soeren Gebbert]

I use in vtk.grass-bridge (C++ -VTK GRASS wrapper) a different approach.
http://code.google.com/p/vtk-grass-bridge/

Replacing the G_fatal_error() function and using the setjmp/longjmp
construct allows you to catch all errors from grass, inclusively stack
restoration. Glynn made this suggestion. :)

This function replace G_fatal_error(), to set with
G_set_error_routine(vgb_error_handler);:

int vgb_error_handler(const char *msg, int fatal)
{
if (fatal == 0)
{
fprintf(stderr, "%s\n", msg);
return 1;
}
else
{
fprintf(stderr, "\n## Exceptiont called ###\n");
vgb_error_message = msg;
longjmp(vgb_stack_buffer, 1);
}
return 1;
}


This is an example how to handle fatal errors (old example, still
check for return value):
if (!setjmp(vgb_stack_buffer))
{
if (Rast_get_row(this->Map, this->RasterBuff, idx, this->MapType) < 0)
{
error = 1;
}
}
else
{
this->InsertNextError(vgb_error_message);
return NULL;
}

Code examples from:
http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/Common/vtkGRASSDefines.h
http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/Common/vtkGRASSInit.cxx
http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/Raster/vtkGRASSRasterMapBase.cxx

Soeren


2010/1/14 GRASS GIS :
> #869: Compile libs with -fexception
> --+-
>  Reporter:  rblazek      |       Owner:  grass-...@lists.osgeo.org
>      Type:  defect       |      Status:  closed
>  Priority:  normal       |   Milestone:  6.5.0
>  Component:  Compiling    |     Version:  unspecified
> Resolution:  worksforme   |    Keywords:
>  Platform:  Unspecified  |         Cpu:  All
> --+-
> Comment (by rblazek):
>
>  Replying to [comment:8 hamish]:
>  > fwiw, wrt. -fexceptions, Francesco commented on the DebianGIS list:
>  >
>  {{{
>  This would be required for any C library linked by Qgis. This is out of
>  discussion.
>  Qgis has to manage correctly C libraries by providing wrappers to raise
>  execeptions
>  when C calls fail, else people will start asking that libc too supports
>  exceptions, soon or later...
>  }}}
>
>  Probably he does not know, that GRASS libraries can call exit(). No
>  wrapper can help in that situation AFAIK.
>
> --
> Ticket URL: 
> GRASS GIS 
>
> ___
> 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

[GRASS-dev] Re: [GRASS GIS] #869: Compile libs with -fexception

[GRASS GIS]

#869: Compile libs with -fexception
--+-
  Reporter:  rblazek  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  closed   
  Priority:  normal   |   Milestone:  6.5.0
 Component:  Compiling| Version:  unspecified  
Resolution:  worksforme   |Keywords:   
  Platform:  Unspecified  | Cpu:  All  
--+-
Comment (by rblazek):

 Replying to [comment:8 hamish]:
 > fwiw, wrt. -fexceptions, Francesco commented on the DebianGIS list:
 >
 {{{
  This would be required for any C library linked by Qgis. This is out of
 discussion.
  Qgis has to manage correctly C libraries by providing wrappers to raise
 execeptions
  when C calls fail, else people will start asking that libc too supports
  exceptions, soon or later...
 }}}

 Probably he does not know, that GRASS libraries can call exit(). No
 wrapper can help in that situation AFAIK.

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

[GRASS-dev] Re: [GRASS GIS] #869: Compile libs with -fexception

[GRASS GIS]

#869: Compile libs with -fexception
--+-
  Reporter:  rblazek  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  closed   
  Priority:  normal   |   Milestone:  6.5.0
 Component:  Compiling| Version:  unspecified  
Resolution:  worksforme   |Keywords:   
  Platform:  Unspecified  | Cpu:  All  
--+-
Comment (by hamish):

 fwiw, wrt. -fexceptions, Francesco commented on the DebianGIS list:

 {{{
 This would be required for any C library linked by Qgis. This is out of
 discussion.
 Qgis has to manage correctly C libraries by providing wrappers to raise
 execeptions
 when C calls fail, else people will start asking that libc too supports
 exceptions, soon or later...
 }}}

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

Re: [GRASS-dev] #787: v.in.db: add v.in.ogr-like "-t" option

[Michael Barton]

I stand (or sit at breakfast) corrected.

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: www.public.asu.edu/~cmbarton, http://csdc.asu.edu









On Jan 14, 2010, at 12:21 AM, Hamish wrote:

> Michael wrote:
>> All well and good for *nix OS's, but Windows doesn't have a pipe like this.
> 
> 
> sure it does, or at least DOS does.
> 
> C:\> dir | more
> 
> 
> IIRC, DOS borrowed this from CP/M, which borrowed it from UNIX.
> it's old school.
> 
> 
> Hamish
> 
> 
> 
> 

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

Re: [GRASS-dev] grass is a monad?

[Paul Kelly]

On Thu, 14 Jan 2010, Paolo Cavallini wrote:


Hi all.
Reading the recent post of Glynn:

Right now, I'm actively trying to think of ways to make life harder for anyone 
trying
to use the GRASS libraries for anything except GRASS modules.
http://trac.osgeo.org/grass/ticket/869#comment:1

I wonder if this is somehow a view shared by GRASS-PSC, and I ask myself what 
would
be the advantage of having GRASS as an isolate piece of software.
I would greatly appreciate devs opinions on this.


Well, Glynn's comment is clearly (as I see it anyway!) meant to be 
light-hearted/sarcastic. But it has some basis. The idea is not that GRASS 
should not be used be other projects, but we encourage other projects to 
use it by running GRASS modules - not by linking against the GRASS 
internal libraries directly. In the past few years a massive amount of 
work has gone into making the GRASS modules more Unix-like (do one thing 
simply and do it well, with no interactivity) - and while this annoyed me 
a bit for a while, I think it has opened up so many more opportunities for 
use of GRASS modules as a backend to other systems (e.g. the GRASS GUI) 
that it is a very good thing.


So, I feel the idea behind Glynn's comments (and one that I guess I would 
agree with) is that we encourage other projects to use GRASS by calling 
the modules directly. As GRASS has so few developers compared to the 
massive body of code, putting in extra development time to make GRASS work 
in ways that have no benefit for GRASS is just too much effort.


Best regards

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

[GRASS-dev] grass is a monad?

[Paolo Cavallini]

Hi all.
Reading the recent post of Glynn:

Right now, I'm actively trying to think of ways to make life harder for anyone 
trying
to use the GRASS libraries for anything except GRASS modules.
http://trac.osgeo.org/grass/ticket/869#comment:1

I wonder if this is somehow a view shared by GRASS-PSC, and I ask myself what 
would
be the advantage of having GRASS as an isolate piece of software.
I would greatly appreciate devs opinions on this.
All the best.
-- 
Paolo Cavallini: http://www.faunalia.it/pc
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Re: [GRASS GIS] #871: path length in v.net.path

[GRASS GIS]

#871: path length in v.net.path
--+-
  Reporter:  09091968 |   Owner:  grass-dev@lists.osgeo.org
  Type:  enhancement  |  Status:  new  
  Priority:  normal   |   Milestone:  6.5.0
 Component:  Vector   | Version:  unspecified  
Resolution:   |Keywords:  v.net.path   
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-
Changes (by martinl):

  * component:  default => Vector
  * milestone:  6.4.0 => 6.5.0

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

[GRASS-dev] [GRASS GIS] #871: path length in v.net.path

[GRASS GIS]

#871: path length in v.net.path
-+--
 Reporter:  09091968 |   Owner:  grass-dev@lists.osgeo.org
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  6.4.0
Component:  default  | Version:  unspecified  
 Keywords:  v.net.path   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--
 Hello,

 I am using v.net.path very succesful now (generating about 10 million
 routes without problem). The next step is creating a field in the database
 with the length of the path (i need the custom cost factor and the
 length).

 Using v.to.db on route sets of 300.000 features (x 45), is slower the the
 generation of the paths themselves. Since all information is available at
 the v.net.path  process, it is a good idea to add the length of the path
 in the database generated by v.net.path at record creation time. This
 would solve my problem in the best possible way...

 Is a update of v.net.path possible ???

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

[GRASS-dev] Re: [GRASS GIS] #869: Compile libs with -fexception

[GRASS GIS]

#869: Compile libs with -fexception
--+-
  Reporter:  rblazek  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  closed   
  Priority:  normal   |   Milestone:  6.5.0
 Component:  Compiling| Version:  unspecified  
Resolution:  worksforme   |Keywords:   
  Platform:  Unspecified  | Cpu:  All  
--+-
Comment (by rblazek):

 Replying to [comment:5 neteler]:
 > Radim, where do you want to see -fexceptions be used?

 In Lib.make? As Glynn pointed out, a test must be done if it is supported
 by compiler.

 BUT! You don't want to see Glynn's "dead body", I believe!

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

[GRASS-dev] Re: [GRASS GIS] #461: v.to.db crashes on a shapefile connected with v.external

[GRASS GIS]

#461: v.to.db crashes on a shapefile connected with v.external
---+
  Reporter:  msieczka  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  critical  |   Milestone:  6.4.0
 Component:  Vector| Version:  svn-develbranch6 
Resolution:|Keywords:   
  Platform:  Linux | Cpu:  x86-64   
---+
Comment (by mmetz):

 Replying to [comment:8 mmetz]:
 >
 > Going a bit further to the root of the problem: in this case const char
 *col passed to db_select_int() in lib/db/dbmi_client/select.c is a zero
 length string, you could do for 'col' the same test that's done for
 'where' and exit with an error.

 The following patch works for me

 {{{
 Index: select.c
 ===
 --- select.c(revision 40416)
 +++ select.c(working copy)
 @@ -115,6 +115,9 @@

  G_debug(3, "db_select_int()");

 +if (col == NULL || strlen(col) == 0)
 +   G_fatal_error(_("Missing column name"));
 +
  /* allocate */
  alloc = 1000;
  val = (int *)G_malloc(alloc * sizeof(int));
 @@ -203,6 +206,12 @@
  dbValue *value;
  dbTable *table;

 +if (key == NULL || strlen(key) == 0)
 +   G_fatal_error(_("Missing key column name"));
 +
 +if (col == NULL || strlen(col) == 0)
 +   G_fatal_error(_("Missing column name"));
 +
  G_zero(val, sizeof(dbValue));
  sprintf(buf, "SELECT %s FROM %s WHERE %s = %d\n", col, tab, key, id);
  db_init_string(&stmt);
 @@ -259,6 +268,12 @@

  G_debug(3, "db_select_db_select_CatValArray ()");

 +if (key == NULL || strlen(key) == 0)
 +   G_fatal_error(_("Missing key column name"));
 +
 +if (col == NULL || strlen(col) == 0)
 +   G_fatal_error(_("Missing column name"));
 +
  db_init_string(&stmt);

  sprintf(buf, "SELECT %s, %s FROM %s", key, col, tab);
 }}}

 Problem is when a module gives a broken sql string to
 db_execute_immediate(), hopefully that aborts with an error and not a
 segfault.

 Glynn's patch could be useful in other circumstances too.

 Markus M

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

[GRASS-dev] [GRASS GIS] #870: Duplicate Legend layer in tcltk

[GRASS GIS]

#870: Duplicate Legend layer in tcltk
-+--
 Reporter:  clerici  |   Owner:  grass-dev@lists.osgeo.org
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  6.4.0
Component:  Tcl  | Version:  unspecified  
 Keywords:   |Platform:  Linux
  Cpu:  Unspecified  |  
-+--
 When two or more legends (of the same or of different maps) are inserted
 in the GIS Manager through the "Add raster legend layer" button in tcltk
 GUI, they are correctly displayed, but if a legend is duplicated through
 the "Duplicated Layer button" an error is output when displaying and
 everything is frozen (see error.png and error.log).
 This with GRASS6.5(40448), 6.4, 6.3, 6.2.

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

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

[Martin Landa]

Hi,

these buttons should be translated by the system's locales. I am not
sure if it's good practice to translate them locally. At least you
disabled standard shortcuts, e.g. &Help.

Martin

2010/1/14  :
> Author: neteler
> Date: 2010-01-13 18:32:36 -0500 (Wed, 13 Jan 2010)
> New Revision: 40421
>
> Modified:
>   grass/branches/develbranch_6/gui/wxpython/gis_set.py
> Log:
> enable i18N for 'Quit' and 'Help'
>
> Modified: grass/branches/develbranch_6/gui/wxpython/gis_set.py
> ===
> --- grass/branches/develbranch_6/gui/wxpython/gis_set.py        2010-01-13 
> 23:32:27 UTC (rev 40420)
> +++ grass/branches/develbranch_6/gui/wxpython/gis_set.py        2010-01-13 
> 23:32:36 UTC (rev 40421)
> @@ -121,9 +121,11 @@
>         self.bstart = wx.Button(parent=self.panel, id=wx.ID_ANY,
>                                 label=_("Start GRASS"))
>         self.bstart.SetDefault()
> -        self.bexit = wx.Button(parent=self.panel, id=wx.ID_EXIT)
> +        self.bexit = wx.Button(parent=self.panel, id=wx.ID_EXIT,
> +                                label=_("Quit"))
>         self.bstart.SetMinSize((180, self.bexit.GetSize()[1]))
> -        self.bhelp = wx.Button(parent=self.panel, id=wx.ID_HELP)
> +        self.bhelp = wx.Button(parent=self.panel, id=wx.ID_HELP,
> +                                label=_("Help"))
>         self.bbrowse = wx.Button(parent=self.panel, id=wx.ID_ANY,
>                                  label=_("Browse"))
>         self.bmapset = wx.Button(parent=self.panel, id=wx.ID_ANY,
>
> ___
> grass-commit mailing list
> grass-com...@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-commit
>



-- 
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

Re: [GRASS-dev] build errors in trunk with make -j 4

[Markus Neteler]

On Thu, Jan 14, 2010 at 9:35 AM, Anne Ghisla  wrote:
> On Thu, Jan 14, 2010 at 5:10 AM, Glynn Clements wrote:
>> Markus Neteler wrote:
...
>> it could probably be
>> changed to either an old-style class:
>>
>>     class Controller:
>>
>> or a new-style class derived from "object":
>>
>>     class Controller(object):
>>
...
> Done in r40447. Thanks for pointing that out, hope it is solved now.
> class Log in the GUI already used old-style class syntax, so I
> chose the same for Controller.

great, now "compiling" again. Will launch the GRASS 7 snapshot now.

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

[GRASS-dev] Re: [GRASS GIS] #384: wxGUI: vdigit crashes on a big map

[GRASS GIS]

#384: wxGUI: vdigit crashes on a big map
---+
  Reporter:  msieczka  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  normal|   Milestone:  6.4.0
 Component:  wxGUI | Version:  svn-develbranch6 
Resolution:|Keywords:  vdigit   
  Platform:  Linux | Cpu:  x86-64   
---+
Changes (by hamish):

  * priority:  critical => normal

Comment:

 keeping open as it would be nice if vdigit closed a bit more gracefully if
 the map is too big, but downgrading severity as making things more memory
 efficient for really huge maps isn't quickly solvable or surprising.


 Hamish

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

Re: [GRASS-dev] build errors in trunk with make -j 4

[Anne Ghisla]

On Thu, Jan 14, 2010 at 1:18 AM, Glynn Clements
 wrote:
>
> The other issue (needing to use $GRASS_PYTHON for actual usage) is
> still outstanding.

Yes, I plan to solve it after the removal of some computation code
left in GUI file and some more refactoring.
Is it ok for you all, or $GRASS_PYTHON issue is more urgent?

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

[GRASS-dev] Re: [GRASS GIS] #842: wx location wizard: spincontrol busted for UTM zone

[GRASS GIS]

#842: wx location wizard: spincontrol busted for UTM zone
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  closed   
  Priority:  critical  |   Milestone:  6.4.0
 Component:  wxGUI | Version:  svn-develbranch6 
Resolution:  fixed |Keywords:  location wizard, utm 
  Platform:  Linux | Cpu:  x86-64   
---+
Changes (by hamish):

  * status:  new => closed
  * resolution:  => fixed

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

[GRASS-dev] Re: [GRASS GIS] #860: wxGUI: About Copyright missing its middle

[GRASS GIS]

#860: wxGUI: About Copyright missing its middle
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  critical  |   Milestone:  6.4.0
 Component:  wxGUI | Version:  svn-releasebranch64  
Resolution:|Keywords:  license  
  Platform:  Linux | Cpu:  x86-64   
---+
Comment (by hamish):

 Replying to [comment:4 neteler]:
 > I just recompiled: help -> about in 6.4 does no longer open a
 > Window. Confirmed on Linux and Windows (latest installer from
 > today).

 presumably this has now been fixed by the str(authors) l10n commit.

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

[GRASS-dev] Re: [GRASS GIS] #580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run

[GRASS GIS]

#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  closed   
  Priority:  blocker   |   Milestone:  6.4.0
 Component:  wxGUI | Version:  6.4.0 RCs
Resolution:  fixed |Keywords:  wingrass 
  Platform:  MSWindows XP  | Cpu:  Unspecified  
---+
Changes (by hamish):

  * status:  new => closed
  * resolution:  => fixed

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

Re: [GRASS-dev] build errors in trunk with make -j 4

[Anne Ghisla]

On Thu, Jan 14, 2010 at 5:10 AM, Glynn Clements
 wrote:
>
> Markus Neteler wrote:
>
>> In fact, the problem is even a new one:
>
>>     class Controller():
>>                      ^
>> SyntaxError: invalid syntax
>
>> [nete...@xblade14 v.krige]$ rpm -qf /usr/bin/python
>> python-2.4.3-8.FC4
>>
>> Python too old? It will be hard to update on that server.
>
> That syntax (new style class with no base classes) was introduced in
> Python 2.5. I doubt that it's actually necessary; it could probably be
> changed to either an old-style class:
>
>     class Controller:
>
> or a new-style class derived from "object":
>
>     class Controller(object):
>
> I think that we should still try to support 2.4, although the only way
> that accidental use of 2.5/2.6 features will be found is through
> running the code for real. Using new syntax features will cause
> --html-description to fail (as happened here), but using new
> functions, modules, classes, methods, etc won't.

Done in r40447. Thanks for pointing that out, hope it is solved now.
class Log in the GUI already used old-style class syntax, so I
chose the same for Controller.

regards,
Anne

> --
> Glynn Clements 
> ___
> 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

[GRASS-dev] Re: [GRASS GIS] #809: v.db.addtable consistently fails in winGrass

[GRASS GIS]

#809: v.db.addtable consistently fails in winGrass
--+-
  Reporter:  JonBall  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  closed   
  Priority:  critical |   Milestone:  6.4.0
 Component:  Vector   | Version:  svn-releasebranch64  
Resolution:  fixed|Keywords:  v.db.addtable, wingrass  
  Platform:  MSWindows Vista  | Cpu:  x86-64   
--+-
Comment (by hamish):

 db.login file change backported to 6.4 in r40446.

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

[GRASS-dev] Re: [GRASS GIS] #809: v.db.addtable consistently fails in winGrass

[GRASS GIS]

#809: v.db.addtable consistently fails in winGrass
--+-
  Reporter:  JonBall  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect   |  Status:  closed   
  Priority:  critical |   Milestone:  6.4.0
 Component:  Vector   | Version:  svn-releasebranch64  
Resolution:  fixed|Keywords:  v.db.addtable, wingrass  
  Platform:  MSWindows Vista  | Cpu:  x86-64   
--+-
Changes (by hamish):

  * status:  new => closed
  * resolution:  => fixed

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