[RkWard-devel] Basic help system in SVN

[SJR]

Am Montag, 8. Januar 2007 20:00 schrieb Thomas Friedrichsmeier:
> On Monday 08 January 2007 19:29, SJR wrote:
> > Great! How much use can be made of images?
>
> You can add images using the regular HTML <img src="..."/>. Note the "/>"
> at the end, this needs to be valid XML, i.e. all tags need to be closed.

xmllint (http://xmlsoft.org/xmllint.html)
checkXML
Our friends? Maybe :)
BTW, also available from Quanta

> The src-reference should always be relative. It is interpreted relative the
> whereever the .rkh-file is located (i.e. generally you'll write <img
> src="image.png"/>). Generally .png is the preferred file format. Image
> files are not yet added the distribution automatically, so please give me a
> note before the release, if you add images.

Let's see. I think most of "my" stuff won't need images. Just in case 
that ... .

>
> Please keep images to illustrate functionality, only, not for layouting or
> prettification purposes.

Of course. No need to make thinks pretty here.

>
> > Good news! Lately there are many updates of RKWard. I will try to find
> > some time and places to announce it more general when the time for the
> > release has come. Maybe Newsforge or ..., we will see. Certainly will
> > will need some Updates of the translations.
>
> Yes, but I intend to create a separate branch in SVN in a while, then wait
> for 1 or 2 weeks during which only documentation, translation updates, and
> bugfixes will be allowed (but development can continue in the main branch).
> So it will be time to do the translations, then.

Okay

>
> > There were some really bad mistakes in
> > the German translation (fixed some weeks ago) due to changes in the
> > "core" of RKWard (possible?). The same applies to the french as far as I
> > could see.
>
> Actually, I don't really know, how
> make package-messages
> works internally. I know, that it tries to keep translations, where strings
> have only changed slightly (a good thing). Probably somehow something bad
> happened, here, but I don't know how to avoid this.

Unfortunately I can't provide you examples. I can just say that the English 
string were complete different from for example the previous created German 
translation.

>
> > Feature freeze since last week here. I planed to add round() to the
> > distribution plug-ins (the output is awefull to read right now if a
> > vector of data is entered) but this would require some time and therefore
> > I'll postpone it to the next release.
>
> round () probably is not the right way to do it though. Or rather, this
> should be a matter of the output routines, not something you do to the
> results to make them prettier. We could probably round all printed results
> to a certain number of digits right now, but the downside is, that then the
> precision will be lost for good, even if you happen to need it.
>

Okay. I keep it the old way.

> One of the long term TODOs is to find a way for the user to adjust the
> *displayed* precision on the fly, while the full precision would always be
> stored in the output. That's easier said then done, however...

I can imagine that. No hurry. RKWard is still a teenager!

>
> > Great, good that you follow practices as other projects have.
>
> I'm trying to get there...

You will. Sure.

>
> > Regarding bug fixes. I think it would be beneficial to have some kind of
> > test suite/tools (as other software project (Gnumeric for handling of
> > XLS-files e.g.) have. This could be for example set of data or functions
> > to be used before every new release. By using them everybody could
> > semi-automatically test RKWard. Of course not for this or the next
> > release but for those in future. I'm not aware if something exists for R
> > (I doubt that). More precise, a test suite could consist of set of data
> > which are known to be difficult to handle (size 32k -> 64k e.g.? or
> > whatever) in combination with typical workflow scenarios (start plug-in
> > see if required packes are loaded, test if logic makes sense ...). Or
> > some kind of check list one has to go through before a plug-in is
> > officially is released. This would be even more important when new
> > contributors commit changes. I long term it's maybe impractical to expect
> > that you (Thomas) will have the time to check each plug-in bit for bit.
> > After all RKWard is aimed to be used in science and there is nothing more
> > worse than a tool that produces faulty results (something that RKward
> > doesn't do right now of course ;) ). I guess you know what I mean. I will
> > try to come up with some thought but right now I have no idea how to
> > design something. To be honest a rather difficult and complex task if not
> > even impossible to realize.
>
> All true. But in fact, the problem is, how to do this right.

I was wondering too. ;)

> One thing that 
> might help in this task would be, if it was possible to run plugins
> programatically from R code (the settings to be chosen in the GUI would be
> given as pairs of id->value). Well, still not easy to do.
>

Also not needed right now. Everything is still manageable by hand. Though the 
pace of RKWard is quite high right now. I would say no bug rather a release 
hunt here. Just kidding! It just requires some diligence.

> Regards
> Thomas

Stefan