Hi,
On Monday 12 September 2011, meik michalke wrote:
> > Thus, the main focus should be on stabilizing / documenting, where
> > necessary.
>
> ok, good point.
that said, I still intend to do some moderate feature additions, too. But yes,
whatever you do, please make sure it will be in a releas
hi,
am Montag 12 September 2011 (09:33) schrieb Thomas Friedrichsmeier:
> On Sunday 11 September 2011, meik michalke wrote:
> > is that done by manually editing rpackage_install.cmake.in
>
> yes.
ok, done that (and fixed the first issue too, as you could read...). hope this
works out now. at le
Hi,
On Sunday 11 September 2011, meik michalke wrote:
> today's journey gave me the opportunity to fix the value pseudotag issues
> in XiMpLe. so it should parse any complex XML trees now, and therefore we
> should probably arm these two packages in SVN.
>
> is that done by manually editing rpack
hi,
am Mittwoch 07 September 2011 (09:42) schrieb Thomas Friedrichsmeier:
> So I will leave it up to you to decide, when this is ready for a wider
> audience.
today's journey gave me the opportunity to fix the value pseudotag issues in
XiMpLe. so it should parse any complex XML trees now, and th
Hi,
On Monday 05 September 2011, meik michalke wrote:
> a train ride later, the basic functions for this are in place now.
keep riding those trains!
> but they're not installed by default yet. once you had a look and think
> that would be helpful, just go on and change that ;-)
I won't have a d
hi,
a train ride later, the basic functions for this are in place now. you can
follow the examples for rk.plugin.skeleton() in the docs to see it in action.
inspect the generated XML, JS and rkh files in /tmp/SquaretheCircle, then.
Am Freitag, 2. September 2011, 09:03:06 schrieb Thomas Friedric
Hi,
On Thursday 01 September 2011, meik michalke wrote:
> for instance, you can assume that every varaible in the dialog
> will be used in the JS file at some point, so they could all be added
> there automatically as well. the same way you could have an automatic help
> file outlined -- then it r
hi,
thanks for the suggestions!
am Donnerstag 01 September 2011 (12:24) schrieb Thomas Friedrichsmeier:
> On Saturday 27 August 2011, meik michalke wrote:
> > and non-empty tags without value or children turn into empty tags, i need
> > to preserve that type info someway.
i fixed that one in the
hi,
am Donnerstag 01 September 2011 (12:30) schrieb Thomas Friedrichsmeier:
> I must admit, I don't find this more convenient than editing XML, directly,
and i must admit that in some cases it doesn't even save a lot of typing...
> but tastes differ, so why not.
yes, i from my perspective can w
Hi,
On Tuesday 30 August 2011, meik michalke wrote:
> i've cleaned up a lot. i removed all rk.* functions from XiMpLe and put
> them in a package of their own, rkwardplugdev, which depends on XiMpLe.
> they are also all documented now, and some new ones were added:
> rk.XML.cbox()
> rk.XML.row()
Hi,
On Saturday 27 August 2011, meik michalke wrote:
> there's only one more thing which is so not working... it's reading XML
> nodes which have a text value with embedded other XML nodes. and non-empty
> tags without value or children turn into empty tags, i need to preserve
> that type info som
hi,
am Samstag 27 August 2011 (12:54) schrieb Thomas Friedrichsmeier:
> > should this go into another package (rkwardplugdev?) or something already
> > present?
>
> I'm not sure, how far we will go, here. If you are going to add a whole
> bunch more functions along those lines, then, yes, these
hi,
Am Samstag, 27. August 2011, 12:54:07 schrieb Thomas Friedrichsmeier:
> On Friday 12 August 2011, meik michalke wrote:
> > i tried to make the XML paste function rather generic, although this is
> > just a first round... but with some tweaking we could later re-use it,
> > e.g., to write helpf
Hi,
On Friday 12 August 2011, meik michalke wrote:
> i tried to make the XML paste function rather generic, although this is
> just a first round... but with some tweaking we could later re-use it,
> e.g., to write helpful functions like
>
> rk.create.tabbook(tabs=2, labels=c("Data", "Options"))
hi,
am Donnerstag 11 August 2011 (18:22) schrieb meik michalke:
> well, i'll try to write at least the paste() based function in the
> meantime ;-)
done. i uploaded a new file to rkward/rbackend/rpackages/rkward/R, called
"rk.write.about.R".
it contains four functions
- rk.write.about() # the
hi,
Am Donnerstag, 11. August 2011, 17:58:43 schrieb Thomas Friedrichsmeier:
> hm, I don't like the thought of having a duplicate structure, if we can
> reasonably avoid it. If users start to mix editing by hand and editing via
> a function, this will lead to inconsistencies.
yeah, i don't find
Hi,
On Thursday 11 August 2011, meik michalke wrote:
> yes, for the writing part paste()ing it together should be easy. in case we
> want to go the other direction and read/parse the XML tree, reliably
> writing that ourselves would be a little more demanding.
>
> it would be helpful to have an u
hi,
Am Donnerstag, 11. August 2011, 09:29:20 schrieb Thomas Friedrichsmeier:
> On Thursday 11 August 2011, meik michalke wrote:
> > yes, that was exactly where i was going. it would also be nice to have a
> > simple dialog for that, where you could type in some basic info.
>
> True. And that dial
On Thursday 11 August 2011, Thomas Friedrichsmeier wrote:
> True. And that dialog itself could be implemented as a plugin, I think.
Actually, one thing that is missing, before this can be implemented as a
plugin, cleanly, is a facility to define "sets" of options, e.g. to allow
specification of
On Thursday 11 August 2011, meik michalke wrote:
> > You mention producing this info by a script, and I think it would really
> > be a good idea to have something roughly equivalent to
> > package.skeleton() for rkward plugins, indeed.
>
> yes, that was exactly where i was going. it would also be
hi,
am Mittwoch 10 August 2011 (19:05) schrieb Thomas Friedrichsmeier:
> all of that sounds quite straight-forward, and maybe you are right that
> this should eventually become the _only_ supported way to distribute
> add-on plugins. However, I am a bit reluctant to remove the GHNS-based
> approac
Hi,
On Wednesday 10 August 2011, meik michalke wrote:
> in summary, there's only two differences:
> - a valid DESCRIPTION needs to be added (which is very easy, using
>write.dcf(), which i just discovered for myself... see below)
> - all the previous contets move unchanged as they are from t
hi,
Am Montag, 8. August 2011, 17:41:26 schrieb meik michalke:
> you can easily create an "R package" that has no real package payload (like
> i said, a valid DESCRIPTION file is roughly it). so we'd just have to
> alter the specification of external plugins a little, so that each
> external RKWa
Hi,
On Tuesday 09 August 2011, meik michalke wrote:
> > (Timing is a bit difficult, since the metric of interest is time spent
> > with cold disk cache. When the disk cache is hot,
> > .rk.get.installed.packages() is pretty fast, anyway).
>
> doesn't installed.packages() chache its results anyway
hi,
am Dienstag 09 August 2011 (19:36) schrieb Thomas Friedrichsmeier:
> In fact the scanning is faster than I had expected, though. But still, it
> seems to make up ~10% of the time spend in .rk.get.installed.packages(),
> and so perhaps that can be enhanced a bit.
try again:
- there's now th
hi,
am Dienstag 09 August 2011 (19:36) schrieb Thomas Friedrichsmeier:
> Why not limit the search to those packages with Enhances: rkward?
funny, i remember starting that way, but not why i changed it... ;-) but
you're right.
> (Timing is a bit difficult, since the metric of interest is time sp
Hi,
On Tuesday 09 August 2011, meik michalke wrote:
> i just committed a small change to .rk.get.installed.packages() in svn. it
> adds two new elements to the list, one is a logical vector (whether
> "Enhances" in DESCRIPTION lists "rkward"), and the last one lists the
> found pluginmaps with ful
hi,
Am Montag, 8. August 2011, 10:49:52 schrieb Thomas Friedrichsmeier:
> RKWard currently runs installed.packages() on each session startup. When
> many packages are installed, that can cost several seconds, esp. while the
> disk cache is cold. Perhaps this pain could at least be shared
i just
hi,
am Montag 08 August 2011 (17:41) schrieb meik michalke:
> i've already added "Enhances: rkward" to the DESCRIPTIONS of my two
> packages (but they're not in the repo, i'll upload them later this
> evening).
ok, they're up now, if you'd like to try:
install.packages("klausuR", repos="http:/
hi,
Am Montag, 8. August 2011, 10:49:52 schrieb Thomas Friedrichsmeier:
> On Wednesday 03 August 2011, meik michalke wrote:
> > i mean, why not simply have R's packaging system
> > manage RKWard's add-ons as well?
>
> it would probably make sense to add support for this, indeed. However, the
> cu
Hi,
On Wednesday 03 August 2011, meik michalke wrote:
> i mean, why not simply have R's packaging system
> manage RKWard's add-ons as well? it souldn't be too hard to let RKWard
> scan (newly installed) packages for 'rkward' subdirectories with
> pluginmaps, maybe use a special 'src/Makefile' targ
31 matches
Mail list logo
