From spencer.graves at structuremonitoring.com  Sat May 21 23:04:12 2011
From: spencer.graves at structuremonitoring.com (Spencer Graves)
Date: Sat, 21 May 2011 14:04:12 -0700
Subject: [Rd] non-R package development
In-Reply-To: <alpine.LFD.2.02.1105212141150.10934@gannet.stats.ox.ac.uk>
References: <4DD70F84.2060401@structuremonitoring.com>
	<BANLkTinpON=8_61GHG-fmy0TmR+EBK6qGg@mail.gmail.com>
	<4DD8140A.4080705@structuremonitoring.com>
	<alpine.LFD.2.02.1105212141150.10934@gannet.stats.ox.ac.uk>
Message-ID: <4DD828CC.7060301@structuremonitoring.com>

Dear Prof. Ripley:



On 5/21/2011 1:48 PM, Prof Brian Ripley wrote:
> On Sat, 21 May 2011, Spencer Graves wrote:
>
>> p.s. I've used subversion successfully with LaTeX, R and Python.  I 
>> tried it with MS Word *.rtf format and found it was next to 
>> impossible, because any conflict produced an indecipherable diff file 
>> comparison.
>
> .rtf is not a Word format, although it is a Microsoft one.  It is used 
> a lot more widely.
>
> In any case .rtf is pretty indecipherable, so expect diffs to be too! 
> As it was the base format for earlier forms of MS help, at one time I 
> did get quite good at deciphering it.  As I recall I had .rtf files in 
> CVS then --- and just checking, R has a License.rtf and that is ASCII 
> not binary.
>
> So I think the 'indecipherable' is entirely about .rtf and not about svn.


       Agreed.  I used RTF in part because it is ASCII not binary.  I 
had gotten excellent results from other types of ASCII files but learned 
what you just reported, that and the SVN diff function works great for 
other material in ASCII (including LaTeX), but not RTF -- which is 
arguably almost binary.  ;-)


       Thanks for the comment.
       Spencer

>
>>
>> ########################
>> Hi, Barry:
>>
>>
>>      Thanks very much.
>>
>>
>>      Does the "python setup.py build" process include procedures for 
>> unit testing -- and preferably producing a manual of the module in 
>> *.pdf and other formats?  Where can I read more about this (beyond 
>> "http://docs.python.org/install/index.html")?
>>
>>
>>      I've been using Python almost daily for over 2 years now, but I 
>> my uses are mostly routine now, and I don't have easy access to a 
>> Python expert for questions like this.  Standard recommendations for 
>> Python suggests placing documentation in a certain format at the 
>> beginning of each *.py code file and function definition.  It also 
>> includes ending each *.py file with a section starting, 'if __name__ 
>> == "__main__":', when is a place where unit tests could be recorded, 
>> though I've been told that is not recommended.  I have not so far 
>> found anything that checks if all functions and arguments are 
>> documented and runs examples, like I get from "R CMD check".  (I 
>> routinely put unit tests in examples, sometimes with "\dontshow".  R 
>> experts have criticized me for suggesting people put unit tests in 
>> the examples sections. I do it, because it's easy and useful.  At 
>> some point, I may try the "RUnit" package.)
>>
>>
>>      Thanks again,
>>      Spencer
>>
>>
>> On 5/21/2011 6:48 AM, Barry Rowlingson wrote:
>>> On Sat, May 21, 2011 at 2:04 AM, Spencer Graves
>>> <spencer.graves at structuremonitoring.com>  wrote:
>>>
>>>>       I routinely use the "R CMD check", etc., process with 
>>>> Subversion for
>>>> version control and collaborative development.  I've looked for 
>>>> similar
>>>> capabilities for other languages, so far without success.
>>>   Python has a similar package build system based around a directory
>>> structure with a 'setup.py' at its root - you may have seen this if
>>> youve ever installed a python package from source. This python script
>>> enables you to do things like 'python setup.py build' and 'python
>>> setup.py install' to build and install the package, as well as run
>>> tests, build distributable archives and so on. There's probably a way
>>> to get a boilerplate package structure all ready to start developing
>>> but I cant think what it is off the top of my head.
>>>
>>> SVN and most other version control systems will play nicely with
>>> text-based program development, so get checking in your python,
>>> matlab, and unix scripts. If LabVIEW has a binary format then you can
>>> normally check these in but you won't get meaningful 'diffs' out of
>>> the system to see what has changed between revisions.
>>>
>>> Barry
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>



[Rd] non-R package development
Spencer Graves