You are here

openmxExtra

6 posts / 0 new
Last post
JWiley's picture
Offline
Joined: 03/25/2011 - 07:53
openmxExtra

It may be a bit early for an extra package with OpenMx still being so actively developed, but I wonder if a public package might be a convenient place to bundle beta/test/hack/mildly useful functions together? This is really a question for the community as I strongly dislike the idea of adding to the developers workload (unless of course it involves cool new OpenMx features....then I'm all for working them round the clock ;).

For example, Ryne has a function on the forums for standardizing estimates, another thread has a way to get modification indices, another one has fit indices. I find myself regularly sourcing some of these files in, which works, but

Would people be interested in a sort of 'community sandbox' package where anyone could write, add, edit, functions for use with OpenMx? Would OpenMxers be willing to put (and update) their hacks, etc. in a public package if I set it up and maintained it?

If there's interest, I would probably use github or google code. Both are pretty good at allowing social coding so multiple people can contribute, edit, and comment and one can easily link to specific .R files so they could be referenced on this forum easily. github has the advantage that Hadley has even written the devtools package which allows one to install straight from github, google code has the advantage that I'm still using subversion and not terribly eager of switching to git ;) The purpose would just be to collect the code fragments from this forum and that may be hiding away on users systems that are too specific/buggy to be officially released anywhere but are still useful for what they do.

Just thinking out loud, maybe a lousy idea.

Ryne's picture
Offline
Joined: 07/31/2009 - 15:12
It's a good idea, but we have

It's a good idea, but we have to get the implementation exactly right. I'll bring it up at a future developer's meeting.

One of the challenges is managing who has read/write access to the package, and how we decide what goes into it. We certainly can't have erroneous code, so some degree of error-checking and peer review is required. Similarly, all code must be documented and supported, and we'll have to figure out what to do if the original author of a commonly used function stops offering support. There is certainly need to keep the bar for inclusion higher than "this code was on the OpenMx forums". On the other hand, it should be relatively easy to provide useful content, so that we don't miss out on great functions and patches because its half as much work as a journal article with very little credit (properly providing credit for community submissions to OpenMx is a larger issue). And having a library is a great idea, because we'll get more support and users by being on CRAN.

Other issues:
-backwards compatability.
-dealing with cross-over (do we want four different standardization functions, and how do we decide which ones are included?).
-intersection with the core release. What happens when OpenMx takes on some, but not all, of the functionality of an existing openMxExtra function? What happens when OpenMx takes on all of the features of a function, but with a different spec?
-every other issue that CRAN deals with when dealing with base release vs. libraries.
-things I'm not thinking of.

I'll point you to discussions of the omx and imx function prefixes (use the search bar) and the genEpi library that holds a series of functions for OpenMx and genetic epidemiology. While it may not sound like it, I'm very positive about this idea. I just don't want to see this idea fail because we didn't foresee an obstacle we could have avoided.

Finally, the name doesn't work, because "MxEx" will be prone to misspellings as the same phoneme has two different spellings in the package ("x" and "ex"). But if you get down to the point that we're only arguing about the name, then you have a pretty successful idea.

JWiley's picture
Offline
Joined: 03/25/2011 - 07:53
*I am not committed to any of

I am not committed to any of these thoughts, just thinking outloud.
I think a lot of the points you raise come down to what the purpose of this package is. Is it a way for the community to extend OpenMx, a way for the developers to extend OpenMx, a free for all staging ground for new ideas, extended beta testing? If it is going to be submitted to CRAN, it definitely needs to not include erroneous code (at least as well as can be determined). If it is sort of a community scratch pad that assumes you are accessing it via a version control system and installing from source, it targets a grown up user base that should be big enough patch up the scratches they get from buggy code. I had in mind a place to prototype, so...

Other issues:
-backwards compatability [[diff earlier version till you find what you missed]]
-dealing with cross-over (do we want four different standardization functions, and how do we decide which ones are included?) [[as many as needed/people with ability to write them have need of them---a nice uniform one would happen eventually and probably be what is integrated into OpenMx itself]]
-intersection with the core release. What happens when OpenMx takes on some, but not all, of the functionality of an existing openMxExtra function? What happens when OpenMx takes on all of the features of a function, but with a different spec? [[deprecation/removal as soon as someone gets around to realizing it is now redundant with a feature in OpenMx]]
-every other issue that CRAN deals with when dealing with base release vs. libraries.
-things I'm not thinking of. [[pure R code or could it include other languages?]]

You sound perpetually positive, Ryne. Seriously, I love the energy on this project and openness to thoughts and ideas (and how gentle the corrections of faulty thinking are).

I see your point about the name, that said, there are quite a few *Extra packages:
latticeExtra
gridExtra
vcdExtra
in development on Rforge/google/github
ggExtra
zooExtra
and I think there is some benefit to consistency (so I would argue for that specific capitalization too), but like you, I think the name can be hammered out after other important logistics are considered.

tbrick's picture
Offline
Joined: 07/31/2009 - 15:10
A sandbox could be excellent

A sandbox could be excellent as a tool to help community developers try things before recommending them to the dev team. Also as a way to archive and better share some of the tools and toys that we share on the forums.

Most of the issues listed above can be handled by having someone maintain the package and do some basic checking on what goes into it and what gets removed from it. For example, the four functions that standardize could be merged into a single function, or (if there are significant differences among them) all kept.

If it's likely to have features roll out into the OpenMx trunk (which I'd hope it would), I would focus less on backward-compatibility--it's a sandbox, after all. People could use the feature requests forum to discuss what they're using, and we could use that to decide what features are worthwhile to roll into the main distribution.

I'd actually recommend NOT making this an R package, but rather a collection of individual function-files with maybe a core "OpenMExtra.R" file to source everything. For the user, this means that everything can be combined into a single source line, but also allows users to keep just the files they need for a given analysis if they're worried about backward compatibility. It also means people can check out just the function files they want/need, and that might give us some extra information about what people are using.

But:
The big question is about support--bug fixes and maintenance and such. We could keep it informal--that is, if you have a problem with omExtraStandardizationNumberFour(), ask in the OpenMExtra forum and see if somebody can help out, with a warning to users that these are not formally supported by the project.

I'd still be worried that people would start to expect full support for the extra functions from the dev team, though, and we really can't be supporting everybody's sandbox code. As you say, though, we're all adults here. If we write THIS IS A SANDBOX THAT ISN'T FORMALLY SUPPORTED BY THE OPENMX PROJECT enough times in big enough letters, we might be able to keep that kind of problem to a minimum. Might also help to keep the appropriate forums on the github or Googlecode site, too, to insulate the devs a bit, but that has the downside of making it tougher to keep up on both sites.

Tim Bates put together a googlecode project with some of the GenEpi functions that he and several other folks (Hermine, Ryne, and Michael Spiegel among them). He might have some insights into this as well.

jpritikin's picture
Offline
Joined: 05/24/2012 - 00:35
GIT mirror available

There is now a GIT mirror of the subversion trunk at:

https://gitorious.org/openmx/openmx

I will set up a cron job to keep this synchronized (in one direction) with the subversion repo.

Nobody has an obligation to use GIT, this is just a step towards making the source code more accessible for GIT enthusiasts.

mdewey's picture
Offline
Joined: 01/21/2011 - 13:24
Is this all too complex?

There is nothing to prevent people writing extension packages and putting them on CRAN. For example look at the packages listed in the depends field for sem (to take an example close to OpenMx). I have not investigated them in detail but a couple of them look like the sort of functions Joshua mentions. One advantage of that would be that the maintainer is clearly specified and is responsible for bugs and so on. Having a semi-official openmxExtra risks having the worse of both world with OpenMx developers being held to account for what they do not control.