[GRASS-stats] Some refactoring and fixing

[Rainer M Krug]

Rainer M Krug <Rainer at krugs.de> writes:

> Roger Bivand <Roger.Bivand-aX1nC9UfZf8 at public.gmane.org> writes:
>
>> On Tue, 27 Jan 2015, Rainer M Krug wrote:
>>
>>> Hi
>>>
>>> I just committed a few of commits which refactor the code of readRAST,
>>> writeRAST, readVECT & writeVECT by creating internal fi=unctions for
>>> reading / writing for plugin / non-plugin and moving the default values
>>> (get...Options()) into the function definitions.
>>
>> Good, thanks; I've updated the default values in the help files. It's
>> easy to check for discrepancies in spgrass/pkg:
>>
>> R CMD build spgrass7
>> R CMD check spgrass7_0.1-0.tar.gz
>
> Thanks - haven't thought about about the check - will do the next time.
>
>
>
>>
>> Maybe we could quieten the progress bar in the output from checking?
>> As in:
>>
>> pkg/spgrass7.Rcheck/spgrass7.Rout
>>
>> (local file, not added to repository, created by R CMD check if run in
>> spgrass/pkg).
>>
>>>
>>> Also, I added tryCatch blocks to close open connections and to reset
>>> echoCmdOption. I ran the examples before each commit and I did not see
>>> any errors or changed behavior.
>>>
>>> Apologies for the typos in the commit messages - I only saw them later.
>>>
>>> To stick with consistency, I would recommend to rename the package to
>>> spgrass7 and to look into the possibility to create a meta-package which
>>> uses spgrass6 or spgrass7 (I don't know about the GRASS 5 interface -
>>> haven't used it) depending on the GRASS GIS version set / loaded.
>>>
>>
>> I've renamed spgrass as spgrass7 - when you update, the change will
>> propagate.
>
> Thanks - got it.
>
>> I'm unsure about a metapackage, maybe block version 7 in
>> spgrass6 (following the parameter and flag name harmonisation).
>
> Yes - spgrass6 for 6.x, spgrass7 for 7.x.
>
> Will respnd in more detail tomorrow.

OK - I just committed a blocking mechanism which for spgrass6 and
spgrass7 so that they

a) when R is started in GRASS, the package can not be loaded if the
versions are not compatible and
b) initGRASS raises an error if the GRASS GIS version in gisBase is not
compatible with the package version

If you think this is the right approach, the help files still need to be
amended to reflect this change.

I was thinking if it would make sense to introduce an overwrite
mechanism for these checks to enable "non-standard" use or testing?

I haven't looked at references for GRASS 7.0 in spgrass6 yet.

Cheers,

Rainer

>
> Thanks,
>
> Rainer
>
>
>>
>> Best wishes,
>>
>> Roger
>>
>>> Cheers,
>>>
>>> Rainer
>>>
>>>

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer at krugs.de

Skype:      RMkrug

PGP: 0x0F52F982
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 494 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/grass-stats/attachments/20150128/164f19cb/attachment.pgp>