#587: WinGRASS: can't open a map for wxDigitizing
-------------------------------+--------------------------------------------
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: wxGUI | Version: 6.4.0 RCs
Keywords: wingrass digitize | Platform: MSWindows XP
Cpu: x86-32 |
-------------------------------+--------------------------------------------
(moved here from osgeo4w bug # 37 http://trac.osgeo.org/osgeo4w/ticket/37
because it is seen both in the OSGeo4W and stand-alone installers)
* wx-vdigit: toolbar comes up but always "No vector map selected for
editing.". In layer list I can choose "Start editing" and a "please wait
while map is opened for editing" message comes up on the bottom status
bar, but the "Stop editing" menu item never ungreys.
tested with both 6.4.0svn binary installers (latest).
both r36287?
#587: WinGRASS: can't open a map for wxDigitizing
---------------------------+------------------------------------------------
Reporter: hamish | Owner: martinl
Type: defect | Status: closed
Priority: major | Milestone: 6.4.0
Component: wxGUI | Version: 6.4.0 RCs
Resolution: duplicate | Keywords: wingrass digitize
Platform: MSWindows XP | Cpu: x86-32
---------------------------+------------------------------------------------
Comment (by hamish):
Replying to [comment:4 martinl]:
> Replying to [comment:2 hamish]:
> > oh, ok. the installer's help "About GRASS" popup says it is based on
r36287 so just a working off an older build.
>
> well, it's revision of wxgui.py not the latest revision of the build.
Which is confusing.
and/or wrap up ($cleaned$) GIS_H_VERSION into a new grass.py function.
> > ps- what'll it take to get the digitizer working for the
> > wingrass builds?
>
> to fix swig issues;-) Building vdigit/nviz extension is
> possible. Anyway they fail because of the swig error.
#587: WinGRASS: can't open a map for wxDigitizing
---------------------------+------------------------------------------------
Reporter: hamish | Owner: martinl
Type: defect | Status: closed
Priority: major | Milestone: 6.4.0
Component: wxGUI | Version: 6.4.0 RCs
Resolution: duplicate | Keywords: wingrass digitize
Platform: MSWindows XP | Cpu: x86-32
---------------------------+------------------------------------------------
Comment (by hamish):
Replying to [comment:8 glynn]:
>
{{{ #define GIS_H_DATE "$Date$"
}}}
>
> Converting it into the desired format will require some
> processing commands in configure.in or the Makefiles.
.... such as | cut -f2 -d'$' ? or do you mean date string format?
#587: WinGRASS: can't open a map for wxDigitizing
---------------------------+------------------------------------------------
Reporter: hamish | Owner: martinl
Type: defect | Status: closed
Priority: major | Milestone: 6.4.0
Component: wxGUI | Version: 6.4.0 RCs
Resolution: duplicate | Keywords: wingrass digitize
Platform: MSWindows XP | Cpu: x86-32
---------------------------+------------------------------------------------
Comment (by glynn):
Replying to [comment:9 hamish]:
> > Converting it into the desired format will require some
> > processing commands in configure.in or the Makefiles.
>
> .... such as | cut -f2 -d'$' ? or do you mean date string format?
I mean for any format other than the one SVN uses for $Date$.
#587: WinGRASS: can't open a map for wxDigitizing
---------------------------+------------------------------------------------
Reporter: hamish | Owner: martinl
Type: defect | Status: closed
Priority: major | Milestone: 6.4.0
Component: wxGUI | Version: 6.4.0 RCs
Resolution: duplicate | Keywords: wingrass digitize
Platform: MSWindows XP | Cpu: x86-32
---------------------------+------------------------------------------------
Comment (by hamish):
Replying to [comment:11 martinl]:
> >
{{{ #define GIS_H_DATE "$Date$"
}}}
>
> done in r37043.
any objections to backporting this?
> The patch for g.version attached (comments?)
* keep it easily parsable (on one line), and as backwards compatible as
possible for existing script parsing.
* (for grass 7 only) s/GRASS/GRASS GIS/
* flags for diff't info? (only if needed)
* modify doc/howto_release.txt to say that GRASS_VERSION_DATE should be
manually set to the release day for official releases, and for SVN builds
take it from GIS_H_DATE?
* append the numeric value portion of GIS_H_VERSION (ie rev #) to
GRASS_VERSION_NUMBER in the g.version output if 'svn' is found in
GRASS_VERSION_NUMBER. so it automatically looks like "6.4.0svn32001"
This way it could be backwards compatible for g6 script parsing.
* is GRASS_VERSION_UPDATE_PKG relevant anymore for grass >= 5?
after some more thought and investigation, gis.h's version while useful
isn't as good as it could be (could be unchanged for months, especially in
the stable branch)
- I propose to add a new -r flag to g.version to display raw
GIS_H_VERSION and GIS_H_DATE strings (no need to shell script style them
AFAICT). This will help people debug situations when the program detects a
libgis/module version mismatch. updated patch attached to this ticket.
either-
- add an hook script in the svn server to automatically write the present
rev and date to a file in the checkin branch. is that possible without
doubling the rev count? (or setting off an endless loop..). "svnlook
youngest .`" and "`svnlook date .`" might help. see http://svnbook.red-
bean.com/en/1.5/svn.reposadmin.create.html#svn.reposadmin.create.hooks
... the goal being that g.version could report like
{{{
GRASS GIS 7.0svn37123 (May 2009)
}}}
where the rev number/date was the current branch's latest modification.
This would end up in grass.py as grass.script.revision() or something so
the Help->About window in the GUI could report something accurate.
for formal releases I would guess to skip all the svn stuff and just
hardcode "6.4.0" and "1 May 2009".
thanks for mentioning `svn info`, I hadn't seen that.
However, AFAICT "`svn info`" and "`svnversion`" both give the rev number
of the entire repo, not the latest change to that branch.
using the "`svn log`" method would keep the version unchanged for e.g.
GRASS 5.4.2 since the last time that branch was actually modified.
otherwise all branches+trunk versions change each time any modification is
made globally (e.g. to grass-web or trunk), when in fact they haven't
changed at all.
the downside of `svn log` is that it is rather slow and requires internet
access.