[GenABEL-dev] GenABEL tutorials to SVN

[L.C. Karssen]

Dear Yurii,

On 12/03/13 21:47, Yurii Aulchenko wrote:
> Dear All,
> 
> Many thanks for your valuable input!
> 
> This is how it looks now: I have cleaned up the data/code (actually,
> only one chapter - on stratified analyses - really suffered and does not
> make much sense anymore; most of the others were rather ok). 

That's good news. Glad that most of the tutorial is still in
good/reasonable shape.

> I put the
> data on the GenABEL.org site; 

With that you mean the free/non-problematic data, I assume.

> and made a small chapter fetching the data
> following Lennart's suggestion (using 'download.file').
> 
> I am ready to submit the resulting code.
> 
> I think I should make a new directory - say, 'tutorials' - at the same
> level, as 'pkg', 'tags', 'www' and then will have a sub-directory called
> 'GenABEL_general' to keep this general tutorial. What do you think?

I agree. That seems the most logical way. Alternatively we can put
tutorials in the same directory as the respective package (e.g.
pkg/GenABEL), but that will probably mess up r-forge's automatic package
building even more (than it is now because of the way we need the
filevector files).


Best,

Lennart.

> 
> best wishes,
> Yurii
> 
> On Sun, Mar 10, 2013 at 11:24 PM, L.C. Karssen <lennart at karssen.org
> <mailto:lennart at karssen.org>> wrote:
> 
>     Dear all,
> 
>     On 08-03-13 09:37, Yurii Aulchenko wrote:
>     > Here is another question: for the tutorials we need relative large
>     data
>     > sets (as text files or in RData or other binary format).
> 
>     Good question, I hadn't thought of that yet.
> 
>     >
>     > On one hand, it is handy to have "all in"; on the other hand - why
>     > putting files which are either binary and/or not likely to change to
>     > SVN? - this is not logical.
> 
>     True. Having binary data in SVN is not ideal. On the other hand, a
>     definition of what goes into a revision control system is: all the files
>     that cannot be created by other files. From that point of view having
>     the data sets in SVN isn't a problem and it does give us the benefit of
>     the "all in" system.
> 
>     >
>     > The only thing I can think of is to put data files to some server and
>     > then as the first part of the tutorial to "pull" it e.g. using wget.
>     > Does affect cross-platform compatibility though... Also, where we put
>     > the files? - Drupal? - if we have say 100 Megs in data, would it
>     > generate too much traffic so the bill becomes somewhat sensible?
> 
>     We could try that. We still have quite some room on our server account:
>     space and network bandwith are > 90% unused.
> 
>     >
>     > I am really not sure what to do in this respect.
> 
> 
>     All in all, I think we should have the data in SVN. We don't want to
>     make building the documentation too hard. Working around the non-free
>     data will be hard enough work.
>     I tried to find out if there is a maximum of storage on the R-forge SVN
>     server, but I couldn't find an answer.
> 
> 
>     Lennart.
> 
>     >
>     > Yurii
>     >
>     > On Fri, Mar 8, 2013 at 9:30 AM, Yurii Aulchenko
>     > <yurii.aulchenko at gmail.com <mailto:yurii.aulchenko at gmail.com>
>     <mailto:yurii.aulchenko at gmail.com
>     <mailto:yurii.aulchenko at gmail.com>>> wrote:
>     >
>     >     Ok, great, I think this is the way to go.
>     >
>     >     Will make an account of private/public files, will push things to
>     >     SVN (hopefully some time next week), and see what we can do :)
>     >
>     >     best wishes,
>     >     Yurii
>     >
>     >
> 

-- 
-----------------------------------------------------------------
L.C. Karssen
Utrecht
The Netherlands

lennart at karssen.org
http://blog.karssen.org

Stuur mij aub geen Word of Powerpoint bestanden!
Zie http://www.gnu.org/philosophy/no-word-attachments.nl.html
------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: OpenPGP digital signature
URL: <http://lists.r-forge.r-project.org/pipermail/genabel-devel/attachments/20130313/c2dbe8ff/attachment-0001.sig>