Re: [GRASS-dev] [GRASS GIS] #2105: Missing guidelines for testing

2013-10-29 Thread GRASS GIS 
#2105: Missing guidelines for testing
+---
 Reporter:  wenzeslaus  |   Owner:  
grass-dev@…  
 Type:  task|  Status:  new 
 
 Priority:  normal  |   Milestone:  7.0.0   
 
Component:  Tests   | Version:  
svn-trunk
 Keywords:  testing, tests, PyUnit, doctest, testsuite  |Platform:  All 
 
  Cpu:  Unspecified |  
+---

Comment(by wenzeslaus):

 I agree with [comment:4 huhabla (comment 4)] that the tests should be
 primarily in Python. We actually already did the decision: GRASS modules
 which are scripts are in Python. The reasons for this were probably stated
 at that point but let's recall them:
  * it's easier than C/C++ to write and run and more flexible if necessary
 when doing special things (might apply to tests)
  * once you need to write an if statement, Python is simpler to write and
 read than Bash (and same applies to strings and `sed`, `awk`, ...)
  * although most of the GRASS developers and power users writes in Bash a
 lot, the common language for most of the developers is Python (today and
 probably in the future too)
  * Python is a general purpose language (both scripts and complicated
 applications are possible)

 And as for the additional complexity of Python comparing to Bash
 (comment:5), the module test is not only a call of the module which would
 be easier to write in Bash. If the module returned 0 or not, is not
 enough. It is usually needed to set region, prepare data, call the module
 and test the output. Which is actually the same as it is said about
 writing unit tests in general: The test for the function can be longer
 than the function itself. So, I don't expect tests to be simple, although
 I wish them to be.

 However, I would like to point out that we have quite different ''units''
 to test, basically modules, C function and Python functions. For some of
 them the choices are unclear but for Python libraries, Python testing is
 just the best choice. There are even `unittest` and `doctest` in the
 standard distribution (`doctest` is compatible with `unittest`), so we
 don't need to use something external. No need to write some new things.

 C/C++, on the other hand, requires some more thinking and unfortunately,
 it is hard to follow KISS principle, because it is not simple with them.
 There is no standard or build-in way of testing, so writing some special
 code is inevitable. You can write some testing programs but sooner or
 later you need some special code to compare results, manage tests, etc.

 Besides some classic ''unit test'' frameworks for C/C++ there could be
 something which uses Doxygen to extract tests from doc (similarly to
 Python doctest) and also something which uses abilities of LLVM/clang (JIT
 compiler, C++ interpreter) but I have never searched for it. However, we
 would have probably a lot of problems with using some 3rd party solution
 or, so all these options are not usable. See also
 [http://hub.qgis.org/projects/quantum-gis/wiki/Developers_Manual#Unit-
 Testing QGIS Unit Testing] which uses Qt and CTest testing frameworks.

 Especially for the C/C++ modules, instead of writing testing programs to
 test their internal functions, we can also implement something like a
 `--test` option which would be available only when certain `#define` would
 be active (using make/configure) and testing functions would be directly
 in the module and dependent on the `#define` value. Common testing
 functions can be in some library.

 Here is the summary of options I see as doable, probable and acceptable.

 Python libraries Python:
  * `unittest` and `doctest`

 Functions in Python modules:
  * `unittest` and `doctest`

 Interface of C/C++ libraries:
  * interface by `unittest` and `doctest` through `ctypes`

 Internal (`static`, `private`, ...) functions in C/C++ libraries:
  * testing programs
  * generate `ctypes` interface and then `unittest` and `doctest`

 Functions in C/C++ modules:
  * testing programs
  * generate `ctypes` interface and then `unittest` and `doctest`
  * `--test` parameter for module

 C/C++ modules and Python modules:
  * `unittest` and `doctest`
  * Bash/shell scripts

 I don't know if the `ctypes` generation for testing purposes would be
 possible but if yes, it seems to be a good option. However, you still
 cannot test ``static`` functions in that way.

 There are five other main areas of the testing topic:
  * recursive running of tests (`make test`)
  * reports/outputs
   * output after `make test` is necessary
   * HTML or parsable text or XML would be really useful for online
 presentation
  * automatic/online

Re: [GRASS-dev] [osgeo4w-dev] hdf5dll.dll missing

2013-10-29 Thread Jürgen E . Fischer 
Hi Martin,

On Tue, 29. Oct 2013 at 14:52:19 +0100, Martin Landa wrote:
> The reported problem is
> 
> missing hdf5dll.dll library
> 
> Could be related to the recent introducing GDAL 1.10 in OSGeo4W
> environment (seems to be problem with liblas package)?

Maybe, but I don't see how.   gdal depends on gdal19dll and that contains the
old gdal19.dll and hdf5dll.dll.


Jürgen

-- 
Jürgen E. Fischer norBIT GmbH   Tel. +49-4931-918175-31
Dipl.-Inf. (FH)   Rheinstraße 13Fax. +49-4931-918175-50
Software Engineer D-26506 Norden   http://www.norbit.de
QGIS PSC member (RM)   IRC: jef on FreeNode 


-- 
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502

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

[GRASS-dev] hdf5dll.dll missing

2013-10-29 Thread Martin Landa 
Hi all,

recently I encountered problem with compiling GRASS7 in OSGeo4W
environment, namely with modules `r.in.lidar` and `v.in.lidar` (liblas
dependency). The reported problem is

missing hdf5dll.dll library

Could be related to the recent introducing GDAL 1.10 in OSGeo4W
environment (seems to be problem with liblas package)?

Thanks in advance for any tips, Martin

-- 
Martin Landa  * http://geo.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2095: GRASS changes for OSGeo4W 64bit

2013-10-29 Thread GRASS GIS 
#2095: GRASS changes for OSGeo4W 64bit
-+--
 Reporter:  jef  |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:   
Component:  Default  | Version:  6.4.3
 Keywords:  osgeo4w  |Platform:  MSWindows 7  
  Cpu:  x86-64   |  
-+--

Comment(by martinl):

 Patch applied in `trunk` (r58120) and `devbr6` branch (r58119). Before
 applying it in `relbr64` branch we should do some testing, please try the
 next `grass65-dev` OSGeo4W package.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2095: GRASS changes for OSGeo4W 64bit

2013-10-29 Thread GRASS GIS 
#2095: GRASS changes for OSGeo4W 64bit
-+--
 Reporter:  jef  |   Owner:  martinl
 Type:  enhancement  |  Status:  assigned   
 Priority:  normal   |   Milestone: 
Component:  Default  | Version:  6.4.3  
 Keywords:  osgeo4w  |Platform:  MSWindows 7
  Cpu:  x86-64   |  
-+--
Changes (by martinl):

 * cc: grass-dev@… (added)
  * owner:  grass-dev@… => martinl
  * status:  new => assigned


-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS-user] G7-gui and G64 add-on problems on Xubuntu (installation from grass/ubuntugis ppa)

2013-10-29 Thread Jürgen E . Fischer 
Hi Hamish,

On Tue, 29. Oct 2013 at 04:38:14 -0700, Hamish wrote:
> Tim wrote:
> > Yes, latest QGIS (daily) packaged based on nightly GRASS builds.
> > Th problem was that upstream was shipping the /debian files as
> > templates. These would need to be replaced by the build script.
 
> apparently the trick is to to edit the debian/changelog file,
> and on the first line replace UNRELEASED with the name of the
> distro version (template extension) you wish to use.

Or just follow in qgis' INSTALL 3.8[1] and add a changelog entry with something
like:

dch -l ~lucid --force-distribution --distribution lucid "lucid build"


Jürgen


[1] https://github.com/qgis/QGIS/blob/master/INSTALL#L304

-- 
Jürgen E. Fischer norBIT GmbH   Tel. +49-4931-918175-31
Dipl.-Inf. (FH)   Rheinstraße 13Fax. +49-4931-918175-50
Software Engineer D-26506 Norden   http://www.norbit.de
QGIS PSC member (RM)   IRC: jef on FreeNode 


-- 
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502

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

Re: [GRASS-dev] [GRASS-user] G7-gui and G64 add-on problems on Xubuntu (installation from grass/ubuntugis ppa)

2013-10-29 Thread Hamish 
Tim wrote:
> Yes, latest QGIS (daily) packaged based on nightly GRASS builds.
> Th problem was that upstream was shipping the /debian files as
> templates. These would need to be replaced by the build script.

apparently the trick is to to edit the debian/changelog file,
and on the first line replace UNRELEASED with the name of the
distro version (template extension) you wish to use.

for anything resembling official/stable QGIS packages I'd
strongly recommend to stay with an already released
stable version of GRASS (i.e. 6.4.3, or for qgis development
nightly builds the 6.4 release branch). for experimental/
development packages, do as you like as long as they are
clearly labeled as such.


thanks,
Hamish

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

Re: [GRASS-dev] g.extension still broken in GRASS 7 on Mac

2013-10-29 Thread Michael Barton 
OK. This is weird.

I have installed on a different computer the same build of GRASS 7 that I 
tested this on last Friday, where it worked fine. 

Outside of the difference that the other computer is a Mac desktop (iMac) and 
this one is a laptop (MacBook Air), they are set up the same (OS, Python, etc). 
I am testing this on the same extensions that I tested last Friday. But now I 
get a permission denied error and clearly GRASS is trying to create a directory 
in the wrong place again. 

Both GRASS_ADDON_BASE and GRASS_ADDON_PATH are set correctly 

GRASS 7.0.svn (nc_spm_08):~ > $GRASS_ADDON_PATH
bash: :/Library/GRASS/7.0/Modules/bin: No such file or directory
GRASS 7.0.svn (nc_spm_08):~ > $GRASS_ADDON_BASE
bash: /Users/cmbarton/Library/GRASS/7.0/Modules: is a directory

Here is the error. I get the same thing even if I specify the proper directory 
by using the "prefix" argument.

GRASS 7.0.svn (nc_spm_08):~ > g.extension extension=r.stream.order
Fetching  from GRASS-Addons SVN (be patient)...
Compiling...
mkdir: /Applications/GRASS/bin: Permission denied
make: *** [/Applications/GRASS/bin] Error 1
ERROR: Compilation failed, sorry. Please check above error messages.

Where is it getting this path

If I make /Applications/GRASS writable by anyone, compilation succeeds. The 
compiled binary is installed correctly into the directory specified by 
$GRASS_ADDON_BASE and NOTHING is written to /Applications/GRASS/bin

This is completely bizarre.

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-965-8130/727-9746 (CSDC)
fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu












On Oct 25, 2013, at 3:17 PM, Michael Barton  wrote:

> Yes!!!
> 
> This works. Thanks much Martin! 
> 
> I test it with r.stream.order from the GRASS terminal and from the GUI 
> wrapper. Both work. So now it is working better than GRASS 6.4.
> 
> One question for what Bulent is experiencing. Do Mac users need to have the 
> Developer tools installed for g.extension to work? I'm assuming yes, but do 
> not know for sure. Also (maybe William can offer suggestion), does it matter 
> what SDKs are installed?
> 
> Michael
> __
> C. Michael Barton 
> Director, Center for Social Dynamics & Complexity
> Professor of Anthropology, School of Human Evolution & Social Change
> Arizona State University
> Tempe, AZ  85287-2402
> USA
> 
> voice:480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
> fax:  480-965-7671(SHESC), 480-727-0709 (CSDC)
> www:  http://csdc.asu.edu, http://shesc.asu.edu
>   http://www.public.asu.edu/~cmbarton
> 
> On Oct 25, 2013, at 1:18 AM, Martin Landa 
> wrote:
> 
>> Hi,
>> 
>> 2013/10/24 Glynn Clements :
>> 
>>> You can override RUN_GISRC on the make command line if you want to use
>>> a different $GISRC file.
>> 
>> right, done in r58103.
>> 
>> @Michael: please let us know if it works for you.
>> 
>> Martin
>> 
>> -- 
>> Martin Landa  * http://geo.fsv.cvut.cz/~landa
> 

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