Re: [Webmacro-devel] Bug in repeating invocations of #eval, and future directions of webmacro

[Alex F. <al...@fi...>]

On 29 November 2011 23:15, Guy Bolton King <gu...@wa...> wrote:

<snip>


> Sorry, I've not been checking my mail as rigorously as normal, so I've
> missed most of this thread.  Picking up here (briefly) to dispel some
> confusion:
>
> The last change made to webmacro in CVS was on 2011-05-16:
>
>
> https://github.com/alex-fiennes/webmacro/commit/591206790c75d0f8419a4913657c49dc10b1e57c
>
> The change Tim made to dependencies was on 2010-02-21:
>
>
> https://github.com/alex-fiennes/webmacro/commit/1810052e862974cf4619532390dc0fa8cb5e5768
>
> Both changes are included in the github repo; I don't know what additional
> changes Alex has made to the dependencies.
>

I've review the commit at
https://github.com/alex-fiennes/webmacro/commit/79b05cdccea0dfaf4ebc0ae30e6ea60372c9d96eand
I suspect that I had jumped to conclusions.  A combination of missing
the commit that happened post 2.1 to switch to java.util.concurrent, and
then running eclipse's Tidy Imports routine when I first checked out the
github repo, and then reviewing Broker and noticing that it had added
java.util.concurrent.ConcurrentHashMap (and failing to notice that it had
actually just re-ordered the imports) made me assume that switching across
to java.util.concurrent had been done by me rather than Tim.  Sorry for the
confusion...


> In short: the github repo includes _all_ changes from the sourceforge CVS
> repo.  No changes have been missed.
>
> If you wish to maintain a repo on sourceforge, I'd clone the github one
> and push it upstream to sourceforge's git hosting, and abandon the CVS
> repo: you can always take a copy of the old CVS repo from sourceforge
> beforehand, or I can send it to you as I have one.
>
> What I would advise against is backporting into the CVS tree, as at that
> point you will start to have to manually maintain two source trees in
> painfully different SCMs.
>

utterly agree.

it probably makes sense if people who care about what direction things go
in review the commits that I've made to date (
https://github.com/alex-fiennes/webmacro/commits/master) and if they are
all fine then we can make this into the current master branch.  If any of
it is problematic then I can talk to Guy about setting it up in a branch.

Once this has been done, then we should have a chat about how we are going
to move ahead with new development work.  However I suspect that I will
just make a skunkworks branch and play around with things.  I would really
like to get error messages to be a little bit easier to debug when you have
deeply nested #eval statements...


> Lastly, I apologise for appearing to have rail-roaded the move to git: in
> my defense, I'd like to point out that the git repo has enabled the
> experimental work that lead Alex to finding a bug, and that the git repo we
> now have (which tracks the 2.2 re-org correctly) records the history of
> this project with greater fidelity than CVS did.
>

Yup.  I had fully intended to have this conversation at an earlier date,
but I wasn't expecting to find anything that I though might need to go back
into the public stuff and was just preparing to experiment a bit so just
pressed on with things.  However I think that the end result might be quite
good.

How many people on this list might be interested in getting into design
decisions for future development on webmacro?

Alex


> Best regards, and good luck,
>
> Guy.
>



-- 
Alex Fiennes
email: al...@fi...
mobile:  +44 (0)7813 832662
office: +44 (0)1875 823 310