|
From: Alex F. <al...@fi...> - 2011-11-27 21:00:25
|
Tim On 27 November 2011 19:46, Tim Pizey <ti...@pa...> wrote: > Hi Alex, > > Great to hear from you, not so great that you have found a bug ! > :-) it is trivial to fix... > [snip] > > > So I'm going to patch EvalDirective to sort this out which brings me > onto my > > second point. > > I've been doing a bit of playing around with webmacro myself and I've > got a > > clone of the git repository that Guy Bolton-King took of the sourceforge > CVS > > repository and this is sitting at > https://github.com/alex-fiennes/webmacro > > I do not understand why you are using a copy of someone else's copy of > webmacro? You are a committer, so should be using the trunk. primarily because I initially made the github copy because I wanted to experiment with some ideas that might or might not have been sensible to include in the public viewpoint and it was so much easier to handle branches in git. > > This has been a gentle experiment so far because I haven't found anything > > that is actually broken yet, but come this bug then I suspect that I > might > > well start using my branch for production stuff rather than just playing > > around with ideas. > > Who else other than me is still using webmacro and should I just > continue to > > work on my github branch and move forwards? Failing that, do people > want me > > to backport changes across to sourceforge? > > > Stuff that I have been initially working on in github is: > > > > removing the dependencies on the EDU.oswego.cs.dl.util.concurrent > packages > > This is done: > > http://webmacro.sourceforge.net/dependencies.html > > I wasn't aware that this had been done. In fact I wasn't aware that anything had been done to webmacro for some time. This either means that my mail filters are misconfigured or I am not subscribed to the appropriate mailing lists. Has there been a release recently? > > and using the java concurrent packages > > adding in generics declarations as required so that the package will > compile > > cleanly against modern java. > > > > What I am planning to work on is: > > > > adding in support for invoking varargs methods from inside templates > > a certain amount of refactoring to use more of google guava libraries as > > appropriate > > better error reporting on nested templet invocations > > I do not know about this, but would aim towards zero external dependencies. I am still pondering things, but I like the caching tools that are being put into guava at present and I would definitely like to look at integration of the Broker to this. > > If people want to let me know whether or not any of this is of interest > to > > anyone then we can work out how to move forwards. If I don't hear back > from > > anyone then I will assume that everyone has moved on to new pastures and > I > > will just continue down the path outlined above. > > I would like to understand why you and Guy have forked WM. > I think that Guy didn't actually fork it but rather used it as a proof of concept to transfer CVS history into git. I don't think that he still has his github copy of it floating around. Mine is primarily because I wanted to play around with some ideas that might be controversial or at least involve changes to APIs and the like. > Is it just because WM is not using Git? > > If so please, lets put the effort into getting the cvs to git > transfer done. > In which case Guy has some scripts which will facilitate this, but I'll let him answer this. > It seems that by using Guy's copy you have missed out on the work > I have done and are proposing to redo it. > I've already redone it. We can compare notes... > It is great to see someone taking an interest, but I would really like > it if this was going on within the project not outside. > Git is great and I think WM should move to it, but to be using a copy > before the trunk has been transferred seems a recipe for wasted work. > I agree. I just wasn't aware that any work was taking place on trunk. I'll speak to Guy and review the differences between head on CVS and where I am at and make a decision as to the most sensible course of action. If we do switch to git, then will sourceforge support hosting this, or is github a more sensible place to put it? Alex -- Alex Fiennes email: al...@fi... mobile: +44 (0)7813 832662 office: +44 (0)1875 823 310 |