Re: PlotKit further maintenance
Alastair Tse
<mar...@eptcomputing.com> wrote:
> Hi all,
>
> I've been using PlotKit for a while on different projects, and have
> needed to fix/extend it from time to time. Amongst other things, I've
> got a mouseover tooltip feature for canvas, more flexibility in the
> formatting of data series and points, and a bunch of bugfixes. I'd
> like to integrate those changes back upstream.
>
> I recently imported the SVN history into Git and dumped it on Github
> at http://github.com/ept/plotkit -- and I only just noticed today that
> Per has already been maintaining a Git import at http://github.com/cederberg/plotkit-patches
> for months!
>
> Alastair, are you still active on this project? How would you like
> development to be taken further? I would suggest moving mainline
> development to Github, but if you're still interested in the project
> that should be your decision.
Hi,
Thanks for bringing this to my attention. I seriously didn't know that
there were already projects on github.
If it helps everyone if I start maintaining things on github, then
let's do it. I was actually interested in using Mercurial on Google
Code since they have just announced it. Are people partial to
git/github or would they be interested in any DVCS?
The google code SVN model wasn't working very well as it was difficult
for both me and others to accept patches. In fact many people who were
fixing bugs didn't know how to make patches and instead sent me their
edited versions which took quite a while to extract patches out of
because they might of been targetted to a an older version.
Cheers,
Alastair
>
> Per, it looks like our independent imports of the repository match up,
> so merging our respective patches with git should be a breeze. :) I
> can look into that.
>
> Best wishes
> Martin
>
--
Alastair Tse
[T] +44 7795 973639
[W] http://www.liquidx.net/
[MSN] liq...@hotmail.com [AIM] alastairtse [GTALK] alast...@gmail.com
Martin Kleppmann
I've been using PlotKit for a while on different projects, and have
needed to fix/extend it from time to time. Amongst other things, I've
got a mouseover tooltip feature for canvas, more flexibility in the
formatting of data series and points, and a bunch of bugfixes. I'd
like to integrate those changes back upstream.
I recently imported the SVN history into Git and dumped it on Github
at http://github.com/ept/plotkit -- and I only just noticed today that
Per has already been maintaining a Git import at http://github.com/cederberg/plotkit-patches
for months!
Alastair, are you still active on this project? How would you like
development to be taken further? I would suggest moving mainline
development to Github, but if you're still interested in the project
that should be your decision.
Per Cederberg
github! Please let me know if there is anything I can do to help
merging the two together.
Alastair: I started using Github for my various patches to PlotKit
just to keep them sorted and documented somewhere. And github.com
seemed to offer a nice UI on top of git, so why not. I don't have any
strong preference for git, rather the opposite, but together with
github it is currently hard to beat the integration it provides.
It would be great if we could move this project forward with a new
release sometime. MochiKit 1.4 has been out for a while and PlotKit
should perhaps be updated a bit for that...
Cheers,
/Per
Martin Kleppmann
On 25 Apr 2009, at 21:58, Per Cederberg wrote:
> Martin: Great to hear that you have another patchset for PlotKit on
> github! Please let me know if there is anything I can do to help
> merging the two together.
I've done the merge already, and it was fairly painless. I think in
some cases we had actually independently made exactly the same
change! :)
> Alastair: I started using Github for my various patches to PlotKit
> just to keep them sorted and documented somewhere. And github.com
> seemed to offer a nice UI on top of git, so why not. I don't have any
> strong preference for git, rather the opposite, but together with
> github it is currently hard to beat the integration it provides.
Github's UI is indeed pretty hard to beat; Github also has the (fairly
intangible) benefit that most "cool" web-related open source projects
seem to be happening there at the moment, so it's a good community to
be associated with.
So while I wouldn't exclude Mercurial, I've been very happy with
Github and would tend towards it.
Oh, you get some other really neat features too: for example, they
include templating for project websites and automatically run the
converter whenever you push to the Github repository. As an experiment
I set it up so that the existing documentation and tests are served
under http://ept.github.com/plotkit -- the existing Markdown documents
just needed some minor tweaking, and now GitHub automatically
transforms them into HTML on the fly (there's not much page styling at
the moment though).
With Github pages, all you need to do to update the website/
documentation is to do a git push to the gh-pages branch on Github. It
removes the hassle of having to manually run the converter and upload
the generated HTML files elsewhere. And it means that anybody who can
push to the repository can also update the docs; no separate login is
needed.
> It would be great if we could move this project forward with a new
> release sometime. MochiKit 1.4 has been out for a while and PlotKit
> should perhaps be updated a bit for that...
Yes, that would be worth looking into. Have you tried it?
While we're at it, a few more questions on which I'd like your opinion:
- In order to display the tests MochiKit is required. Alastair's
solution was to have it in a 'magic' path outside of the repository;
Per included the minified MochiKit in the git repository for
convenience. I would prefer to explicitly link to an external
repository, e.g. using git submodule, since that way everybody can run
the tests but we can also track changes in MochiKit. Would that be ok
for you?
- Include the packed version in the repository? I would prefer not to
include any automatically generated files. It's very easy to forget to
run the generator, it creates a lot of noise in the patchsets, it
makes merging branches a lot harder, and if different developers use
different packing algorithms you get complete chaos. It would be
preferable to only include a packed version in the zipfile of a
numbered release, but not check it into the repository.
- I'm also thinking of writing some unit tests and plugging them into
a continuous integration system, to avoid me accidentally breaking the
API when I add features. The way Github is serving the tests they
automatically point to the latest version of the sources on the master
branch, so they would be a good target for automated tests. Github can
notify an external service to run automated tests whenever a change is
pushed to the repository. How does that sound?
Best wishes
Martin
Per Cederberg
<mar...@eptcomputing.com> wrote:
>> It would be great if we could move this project forward with a new
>> release sometime. MochiKit 1.4 has been out for a while and PlotKit
>> should perhaps be updated a bit for that...
>
> Yes, that would be worth looking into. Have you tried it?
Well, this is perhaps mostly a code cleanup issue. PlotKit tinkers a
bit with MochiKit.Color.Color.prototype and calls
MochiKit.Base._exportSymbols... Both of which shouldn't really be
done.
I'm using MochiKit 1.5 (trunk) by the way.
> While we're at it, a few more questions on which I'd like your opinion:
>
> - In order to display the tests MochiKit is required. Alastair's
> solution was to have it in a 'magic' path outside of the repository;
> Per included the minified MochiKit in the git repository for
> convenience. I would prefer to explicitly link to an external
> repository, e.g. using git submodule, since that way everybody can run
> the tests but we can also track changes in MochiKit. Would that be ok
> for you?
I guess. But it seems a bit illogical to me to use the Debian git
repository for MochiKit.
Anyway. I added the file out of convenience, since anyone using
PlotKit will also be forced to download MochiKit. So it seems only
fair that we bundle a version of MochiKit that we know we are
compatible with. Anyone who cares for such issues can easily replace
it with another version.
> - Include the packed version in the repository? I would prefer not to
> include any automatically generated files. It's very easy to forget to
> run the generator, it creates a lot of noise in the patchsets, it
> makes merging branches a lot harder, and if different developers use
> different packing algorithms you get complete chaos. It would be
> preferable to only include a packed version in the zipfile of a
> numbered release, but not check it into the repository.
Yes, same problem for MochiKit actually.
But it is also important to make it simple for people to download the
software easily. And not just released versions. I personally like the
new MochiKit download approach:
http://svn.mochikit.com/mochikit/tags/MochiKit-1.4.2/packed/MochiKit/customize.html
http://svn.mochikit.com/mochikit/trunk/packed/MochiKit/customize.html
That uses the packed files in the repository, but now that Google App
Engine supports Java, perhaps the JS-minifier might be possible to
host online. Or is there a better solution?
> - I'm also thinking of writing some unit tests and plugging them into
> a continuous integration system, to avoid me accidentally breaking the
> API when I add features. The way Github is serving the tests they
> automatically point to the latest version of the sources on the master
> branch, so they would be a good target for automated tests. Github can
> notify an external service to run automated tests whenever a change is
> pushed to the repository. How does that sound?
Simple and meaningful tests seems nice. I think the MochiKit tests
(web page that displays the results) is a nice way to do it. One has
to test everything in all browsers anyway...
Cheers,
/Per
Martin Kleppmann
today.
I've added Per and Alastair as collaborators on GitHub (that's
assuming you are the user 'liquidx' on GitHub, Alastair?), which means
that you can directly push to the repository. Per has already pushed
some patches to it -- thank you!
On Apr 26, 5:10 pm, Per Cederberg <cederb...@gmail.com> wrote:
> >> It would be great if we could move this project forward with a new
> >> release sometime. MochiKit 1.4 has been out for a while and PlotKit
> >> should perhaps be updated a bit for that...
>
> > Yes, that would be worth looking into. Have you tried it?
>
> Well, this is perhaps mostly a code cleanup issue. PlotKit tinkers a
> bit with MochiKit.Color.Color.prototype and calls
> MochiKit.Base._exportSymbols... Both of which shouldn't really be
> done.
obvious problems. Have you had any specific issues with later versions
of MochiKit?
I agree though that it would be better not to tinker with MochiKit's
internals, as it's bound to cause compatibility problems sometime, if
not now.
> I guess. But it seems a bit illogical to me to use the Debian git
> repository for MochiKit.
the first git import of MochiKit I could find. Since then I've found
others, but they didn't seem terribly up-to-date or have the original
repository's branch and tag info. Given that there doesn't seem to be
any 'official' git import, maybe using git submodule isn't such a good
idea after all.
> But it is also important to make it simple for people to download the
> software easily. And not just released versions. I personally like the
> new MochiKit download approach:
>
> http://svn.mochikit.com/mochikit/tags/MochiKit-1.4.2/packed/MochiKit/customize.html
> http://svn.mochikit.com/mochikit/trunk/packed/MochiKit/customize.html
Presumably they wouldn't mind if we borrow that script? (It doesn't
seem to have an explicit license attached to it, but I guess
attribution should be enough.)
> That uses the packed files in the repository, but now that Google App
> Engine supports Java, perhaps the JS-minifier might be possible to
> host online. Or is there a better solution?
to me. I can look into that since I wanted to play with App Engine
Java at some point anyway.
> Simple and meaningful tests seems nice. I think the MochiKit tests
> (web page that displays the results) is a nice way to do it. One has
> to test everything in all browsers anyway...
(SimpleTest). Would you suggest using that, or sticking with something
more mainstream like JsUnit?
Martin
Martin Kleppmann
today.
I've added Per and Alastair as collaborators on GitHub (that's
assuming you are the user 'liquidx' on GitHub, Alastair?), which means
that you can directly push to the repository. Per has already pushed
some patches to it -- thank you!
On 26 Apr 2009, at 17:10, Per Cederberg wrote:
>>> It would be great if we could move this project forward with a new
>>> release sometime. MochiKit 1.4 has been out for a while and PlotKit
>>> should perhaps be updated a bit for that...
>>
>> Yes, that would be worth looking into. Have you tried it?
>
> Well, this is perhaps mostly a code cleanup issue. PlotKit tinkers a
> bit with MochiKit.Color.Color.prototype and calls
> MochiKit.Base._exportSymbols... Both of which shouldn't really be
> done.
I tried all the tests with MochiKit trunk today, and didn't notice any
obvious problems. Have you had any specific issues with later versions
of MochiKit?
I agree though that it would be better not to tinker with MochiKit's
internals, as it's bound to cause compatibility problems sometime, if
not now.
> I guess. But it seems a bit illogical to me to use the Debian git
> repository for MochiKit.
Yes, I didn't intend that to be a permanent solution -- it was just
the first git import of MochiKit I could find. Since then I've found
others, but they didn't seem terribly up-to-date or have the original
repository's branch and tag info. Given that there doesn't seem to be
any 'official' git import, maybe using git submodule isn't such a good
idea after all.
> But it is also important to make it simple for people to download the
> software easily. And not just released versions. I personally like the
> new MochiKit download approach:
>
> http://svn.mochikit.com/mochikit/tags/MochiKit-1.4.2/packed/MochiKit/customize.html
> http://svn.mochikit.com/mochikit/trunk/packed/MochiKit/customize.html
Agree about easy downloading. The MochiKit customiser is really neat!
Presumably they wouldn't mind if we borrow that script? (It doesn't
seem to have an explicit license attached to it, but I guess
attribution should be enough.)
> That uses the packed files in the repository, but now that Google App
> Engine supports Java, perhaps the JS-minifier might be possible to
> host online. Or is there a better solution?
Putting the minifier on App Engine sounds like an excellent solution
to me. I can look into that since I wanted to play with App Engine
Java at some point anyway.
> Simple and meaningful tests seems nice. I think the MochiKit tests
> (web page that displays the results) is a nice way to do it. One has
> to test everything in all browsers anyway...
MochiKit appears to use its homegrown unit testing framework
(SimpleTest). Would you suggest using that, or sticking with something
more mainstream like JsUnit?
Best wishes
Martin
--
Martin Kleppmann
Managing Director, Ept Computing Ltd.
Web: http://www.eptcomputing.com
Blog: http://www.yes-no-cancel.co.uk
Twitter: http://twitter.com/martinkl