I just tagged redo 0.10. This version includes only a small number of changes on top of 0.07:
Avery Pennarun (3): Import latest options.py from bup. md-to-man.do: suggest how to install markdown/BeautifulSoup Change definitions of $1,$2,$3 to match djb's redo.
The most important one is that last one: it changes the meaning of $1 and $2 to match djb's original, now that I know (I think) what it is. I hope this is the first and last "major, breaking" API change to redo. Future changes should hopefully either affect almost nobody (eg. changes to the rules relating to dependencies on directories, which you shouldn't be doing anyway) or be backward compatible (eg. new commands or internal implementation changes).
Nevertheless, there's a reason this version number is still so low: I'm not guaranteeing *anything*. It's more important, this early in the life/adoption of redo, to make sure it's designed cleanly rather than avoiding a few growing pains. I hope this doesn't cause anyone too much pain and suffering. Just in case it does, I left a --old-args option in place; if you run "redo --old-args targetname" it will build targetname (and all its dependencies) using the old definitions of $1 and $2 instead of the new lines. You can also set REDO_OLD_ARGS=1 in your environment to make the old behaviour the default. The old-args feature will go away eventually though, so I encourage you to migrate your .do scripts now.
I hope you like the new version! Please email the list if you experience any weirdness.
On Sat, Dec 31, 2011 at 03:02:52AM -0500, Avery Pennarun wrote: > I hope you like the new version! Please email the list if you > experience any weirdness.
I experienced a weirdness.
Steps to reproduce:
1. Create a new directory. 2. Create another file "test.do" with the following contents:
redo-ifchange "$1"
3. Run "/path/to/redo test"
What I expected to happen:
Some kind of "recursion detected" message, or perhaps "deadlock detected" or even "stack overflow".
What actually happened:
Traceback (most recent call last): File "/home/st/Code/redo/redo-ifchange", line 33, in <module> f.add_dep('m', t) File "/home/st/Code/redo/state.py", line 271, in add_dep assert(self.id != src.id) AssertionError
This is obviously an error I encountered while porting from the old argument numbering scheme to the new; I guess it's not terribly likely that people will ever set up cyclic dependencies in the future, but it would be nice if the error message made it a little more clear what was going on.
On Sat, Dec 31, 2011 at 4:01 AM, Tim Allen <screwt...@froup.com> wrote: > What actually happened:
> Traceback (most recent call last): > File "/home/st/Code/redo/redo-ifchange", line 33, in <module> > f.add_dep('m', t) > File "/home/st/Code/redo/state.py", line 271, in add_dep > assert(self.id != src.id) > AssertionError
> This is obviously an error I encountered while porting from the old > argument numbering scheme to the new; I guess it's not terribly likely > that people will ever set up cyclic dependencies in the future, but it > would be nice if the error message made it a little more clear what was > going on.
Okay, confirmed. This is obviously not an actual regression (it would have happened before too) but still worth fixing. Shouldn't be too hard to arrange.
I just encountered a related problem. I have a tree of mutually-dependant items. redo just runs forever. This is suboptimal. I will just break the cycle manually for now (by not explicitly listing one of the dependencies), but it would be nice if redo could break cycles itself.
On Saturday, December 31, 2011 9:02:52 AM UTC+1, apenwarr wrote:
> Change definitions of $1,$2,$3 to match djb's redo.
> The most important one is that last one: it changes the meaning of $1 > and $2 to match djb's original, now that I know (I think) what it is. > I hope this is the first and last "major, breaking" API change to > redo. Future changes should hopefully either affect almost nobody > (eg. changes to the rules relating to dependencies on directories, > which you shouldn't be doing anyway) or be backward compatible (eg. > new commands or internal implementation changes).
> Where did you find information on this being djb's original intention?
Could you link or quote it?
I've been googling for a while now and the only reference to any $<NUMBER> variables I've been able to find is the offhand remark "The second [way] is to specify the filename $3, which is provided by redo." on http://cr.yp.to/redo/atomic.html.
> On Saturday, December 31, 2011 9:02:52 AM UTC+1, apenwarr wrote:
>> Change definitions of $1,$2,$3 to match djb's redo.
>> The most important one is that last one: it changes the meaning of $1
>> and $2 to match djb's original, now that I know (I think) what it is.
>> I hope this is the first and last "major, breaking" API change to
>> redo. Future changes should hopefully either affect almost nobody
>> (eg. changes to the rules relating to dependencies on directories,
>> which you shouldn't be doing anyway) or be backward compatible (eg.
>> new commands or internal implementation changes).
> Where did you find information on this being djb's original intention? Could
> you link or quote it?
> I've been googling for a while now and the only reference to any $<NUMBER>
> variables I've been able to find is the offhand remark "The second [way] is
> to specify the filename $3, which is provided by redo." on
> http://cr.yp.to/redo/atomic.html.
I emailed him and he told me explicitly in a private email. I think
he also said he doesn't really care, but I figure there's no sense in
being gratuitously different.
