Re: [Monotone-devel] Hooks
Ludovic Brenta wrote: I'm not very comfortable with lua either and my first move was to write a shell script along the lines of: #!/bin/sh head=$(mtn automate get_base_workspace_revision) parent=$(mtn automate select p:$head) sed -i -r 's,old_revision \[.*\],old_revision [$parent],' _MTN/revision but this approach fails as soon as the head has more than one parent. That's why, until now, I stuck to the manual way. How about this?: count=$(mtn automate parents $head|wc -l|sed 's/ //g') if [ $count != 1 ]; then echo Cannot undo. More than one parent. exit fi parents=$(mtn automate parents $head) sed -i -r 's,old_revision \[.*\],old_revision [$parent],' _MTN/revision ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Hooks
Daniel Carrera writes: Ludovic Brenta wrote: I'm not very comfortable with lua either and my first move was to write a shell script along the lines of: #!/bin/sh head=$(mtn automate get_base_workspace_revision) parent=$(mtn automate select p:$head) sed -i -r 's,old_revision \[.*\],old_revision [$parent],' _MTN/revision but this approach fails as soon as the head has more than one parent. That's why, until now, I stuck to the manual way. How about this?: count=$(mtn automate parents $head|wc -l|sed 's/ //g') if [ $count != 1 ]; then echo Cannot undo. More than one parent. exit fi parents=$(mtn automate parents $head) sed -i -r 's,old_revision \[.*\],old_revision [$parent],' _MTN/revision Looks reasonable. Note though that I wrote my proposal directly in the mail and didn't test it. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Hooks...
Richard Levitte [EMAIL PROTECTED] writes: So I've a proposal to make this easier, and it's to have a hook registry in monotone, and changing the way hooks are implemented to be anonymous functions that are used as arguments to a registration function, 'add_hook' perhaps? That would at least make it easy to verify that _all_ hooks are mentioned in the manual; presumably there could be a list hooks command that would dump the hook registry. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Hooks...
Hallo, On 9/5/07, Richard Levitte [EMAIL PROTECTED] wrote: So I've a proposal to make this easier, and it's to have a hook registry in monotone, and changing the way hooks are implemented to be anonymous functions that are used as arguments to a registration function, 'add_hook' perhaps? Yeah, it's a good proposal. Give events names and then: add_hook(event, func) -- adds a hook and returns an id remove_hook(event, id) -- remove previously added hook Cheers, -- -alex http://www.ventonegro.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Hooks...
In message [EMAIL PROTECTED] on Wed, 5 Sep 2007 09:34:01 -0300, Alex Queiroz [EMAIL PROTECTED] said: asandroq Hallo, asandroq asandroq On 9/5/07, Richard Levitte [EMAIL PROTECTED] wrote: asandroq asandroq So I've a proposal to make this easier, and it's to have a hook asandroq registry in monotone, and changing the way hooks are implemented to be asandroq anonymous functions that are used as arguments to a registration asandroq function, 'add_hook' perhaps? asandroq asandroq asandroq Yeah, it's a good proposal. Give events names and then: asandroq asandroq add_hook(event, func) -- adds a hook and returns an id asandroq remove_hook(event, id) -- remove previously added hook We need to think a few steps further, me thinks: - What do we do with the values returned by the hook functions, especially if one event has more than one hook function registered? - Do we want to make it possible to give a priority to hook functions? That would require a priority parameter to add_hook(). - Do we want a third function that returns information about a hook, such as how many functions are attached and their identities (the id returned by add_hook()), and whatever other data there may be. - Do we want to be able to identify some hook functions by name? Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Hooks...
On Wed, Sep 05, 2007 at 02:47:52PM +0200, Richard Levitte wrote: We need to think a few steps further, me thinks: - What do we do with the values returned by the hook functions, especially if one event has more than one hook function registered? On registration you have a priority. Registration errors if two functions are registered with the same priority. Result: total ordering between registered hook functions. Each hook can return one of three values: everything ok; non-fatal error; fatal error. - Do we want to make it possible to give a priority to hook functions? That would require a priority parameter to add_hook(). Yep. See above. - Do we want a third function that returns information about a hook, such as how many functions are attached and their identities (the id returned by add_hook()), and whatever other data there may be. How do imagine this to be used? I don't see the value of it from the hook's perspective, and whilst it could be valueable to a user, if the user doesn't know what hooks they have registered then they have other problems. - Do we want to be able to identify some hook functions by name? Probably useful with regard to error reporting. Matthew -- Matthew Sackman http://www.wellquite.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Hooks...
In message [EMAIL PROTECTED] on Wed, 5 Sep 2007 13:54:23 +0100, Matthew Sackman [EMAIL PROTECTED] said: matthew On Wed, Sep 05, 2007 at 02:47:52PM +0200, Richard Levitte wrote: matthew We need to think a few steps further, me thinks: matthew matthew - What do we do with the values returned by the hook functions, matthewespecially if one event has more than one hook function registered? matthew matthew On registration you have a priority. Registration errors if matthew two functions are registered with the same priority. Result: matthew total ordering between registered hook functions. OK. matthew Each hook can return one of three values: everything ok; matthew non-fatal error; fatal error. Good. We need to decide how that should work, because nil doesn't necessarely imply an error (let alone that it doesn't describe the fatality of an error). matthew - Do we want a third function that returns information matthewabout a hook, such as how many functions are attached and matthewtheir identities (the id returned by add_hook()), and matthewwhatever other data there may be. matthew matthew How do imagine this to be used? I don't see the value of it matthew from the hook's perspective, and whilst it could be valueable matthew to a user, if the user doesn't know what hooks they have matthew registered then they have other problems. Right, and all users are always aware of what is in /etc/monotonerc... Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Hooks...
Hallo, On 9/5/07, Richard Levitte [EMAIL PROTECTED] wrote: Good. We need to decide how that should work, because nil doesn't necessarely imply an error (let alone that it doesn't describe the fatality of an error). The hooks could return two values: The hook result and a status code or string. Cheers, -- -alex http://www.ventonegro.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Hooks...
On Wed, Sep 05, 2007 at 01:54:23PM +0100, Matthew Sackman wrote: How do imagine this to be used? I don't see the value of it from the hook's perspective, and whilst it could be valueable to a user, if the user doesn't know what hooks they have registered then they have other problems. If a user doesn't know what hooks they may have registered, getting a list of them might help them debug their other problems. -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Hooks...
On Wed, Sep 05, 2007 at 03:19:02PM +0200, Richard Levitte wrote: In message [EMAIL PROTECTED] on Wed, 5 Sep 2007 13:54:23 +0100, Matthew Sackman [EMAIL PROTECTED] said: matthew Each hook can return one of three values: everything ok; matthew non-fatal error; fatal error. Good. We need to decide how that should work, because nil doesn't necessarely imply an error (let alone that it doesn't describe the fatality of an error). Right, so if it was Haskell and not lua then it'd be (a, ErrorStatus) where a is polymorphic in the type of the result of the hook. I suggest something similar - a tuple where one indicates the result of the hook (or nil if no result) and the other indicates the error. But this opens up a large pot of worms. If the hook is some sort of does x have permission to do y then when do you stop? Is it a conjunction or disjunction of results? Or is it a 3-valued logic and you just go through the list of hooks until you find a definitive True/False? In which case, what happens if all functions return meh? Bother. Maybe this should only be permitted on hooks that don't return a result. It makes in rather easier... simplest thing first and all that? matthew - Do we want a third function that returns information matthewabout a hook, such as how many functions are attached and matthewtheir identities (the id returned by add_hook()), and matthewwhatever other data there may be. matthew matthew How do imagine this to be used? I don't see the value of it matthew from the hook's perspective, and whilst it could be valueable matthew to a user, if the user doesn't know what hooks they have matthew registered then they have other problems. Right, and all users are always aware of what is in /etc/monotonerc... Well quite. Matthew ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Hooks...
On Wed, Sep 05, 2007 at 02:47:52PM +0200, Richard Levitte wrote: We need to think a few steps further, me thinks: - What do we do with the values returned by the hook functions, especially if one event has more than one hook function registered? - Do we want to make it possible to give a priority to hook functions? That would require a priority parameter to add_hook(). - Do we want a third function that returns information about a hook, such as how many functions are attached and their identities (the id returned by add_hook()), and whatever other data there may be. - Do we want to be able to identify some hook functions by name? How can we answer any of these without first thinking about use cases? I mean, obviously we could just make up a bunch of machinery with lots of shiny dials and moving parts and then look at it admiringly from time to time, but presumably the goal is to solve real problems :-). The one that comes to my mind is I want netsync hooks called for my CIA notifier *and* my commit mail notifier. This is pretty easy now, just define a hook that calls the others, but anyway, if we wanted more formal machinery for that, then obviously what it would be was a way to register a list of netsync notifier hooks, which are called in some arbitrary order whenever the relevant event occurred, with return values and errors ignored, and no need for any other fancy stuff. Maybe there are other use cases too that I'm not thinking of, they might have other requirements. -- Nathaniel -- So let us espouse a less contested notion of truth and falsehood, even if it is philosophically debatable (if we listen to philosophers, we must debate everything, and there would be no end to the discussion). -- Serendipities, Umberto Eco ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Hooks...
In message [EMAIL PROTECTED] on Wed, 5 Sep 2007 07:20:01 -0700, Nathaniel Smith [EMAIL PROTECTED] said: njs but presumably the goal is to solve real problems :-). Right. However, there are such things as foreseeable problems as well, as long as we don't go too far into lah-lah-land. njs The one that comes to my mind is I want netsync hooks called for njs my CIA notifier *and* my commit mail notifier. This is pretty njs easy now, just define a hook that calls the others, but anyway, njs if we wanted more formal machinery for that, then obviously what njs it would be was a way to register a list of netsync notifier njs hooks, which are called in some arbitrary order whenever the njs relevant event occurred, with return values and errors ignored, njs and no need for any other fancy stuff. Are you saying that we should make this a special case for the netsync hooks? I've no problem with that per se (actually, it could even be easier to code that directly in Lua), but I'm wondering what to do next time an issue like this comes up. Another special solution? njs Maybe there are other use cases too that I'm not thinking of, njs they might have other requirements. Point, which also leads to specific special solutions. (this is a little of a pick your religion thingy, just like the bazaar and the cathedral ;-)) Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Hooks...
On Wed, Sep 05, 2007 at 04:50:26PM +0200, Richard Levitte wrote: In message [EMAIL PROTECTED] on Wed, 5 Sep 2007 07:20:01 -0700, Nathaniel Smith [EMAIL PROTECTED] said: njs but presumably the goal is to solve real problems :-). Right. However, there are such things as foreseeable problems as well, as long as we don't go too far into lah-lah-land. Sure. All I'm saying is, let's forsee them :-). (Though, YAGNI has its strong points too.) njs The one that comes to my mind is I want netsync hooks called for njs my CIA notifier *and* my commit mail notifier. This is pretty njs easy now, just define a hook that calls the others, but anyway, njs if we wanted more formal machinery for that, then obviously what njs it would be was a way to register a list of netsync notifier njs hooks, which are called in some arbitrary order whenever the njs relevant event occurred, with return values and errors ignored, njs and no need for any other fancy stuff. Are you saying that we should make this a special case for the netsync hooks? I've no problem with that per se (actually, it could even be easier to code that directly in Lua), but I'm wondering what to do next time an issue like this comes up. Another special solution? I don't know -- presumably it depends on the issue? I'm not saying the netsync hooks are the only thing that might benefit from this kind of solution, just the only one I can think of. (I didn't think about it very long.) By all means suggest more. -- Nathaniel -- In mathematics, it's not enough to read the words you have to hear the music ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Hooks...
Matthew Sackman [EMAIL PROTECTED] writes: On Wed, Sep 05, 2007 at 03:19:02PM +0200, Richard Levitte wrote: In message [EMAIL PROTECTED] on Wed, 5 Sep 2007 13:54:23 +0100, Matthew Sackman [EMAIL PROTECTED] said: matthew Each hook can return one of three values: everything ok; matthew non-fatal error; fatal error. Good. We need to decide how that should work, because nil doesn't necessarely imply an error (let alone that it doesn't describe the fatality of an error). Right, so if it was Haskell and not lua then it'd be (a, ErrorStatus) where a is polymorphic in the type of the result of the hook. I suggest something similar - a tuple where one indicates the result of the hook (or nil if no result) and the other indicates the error. But this opens up a large pot of worms. If the hook is some sort of does x have permission to do y then when do you stop? Is it a conjunction or disjunction of results? Or is it a 3-valued logic and you just go through the list of hooks until you find a definitive True/False? In which case, what happens if all functions return meh? Bother. Maybe this should only be permitted on hooks that don't return a result. It makes in rather easier... simplest thing first and all that? Is there an inventory of what the current hooks do? We don't want to have to rewrite a lot of current hook functions for this. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] hooks documentation error
Evan Martin [EMAIL PROTECTED] writes: From http://monotone.ca/docs/Hooks.html, with italics represented /like this/: note_netsync_revision_received (new_id, revision, certs, session_id) Called by monotone after the revision /new_id/ is received through netsync. /revision/ is the text of the revision, what would be given by monotone cat revision /new_id/. I'm not sure what this is trying to say but certainly monotone cat revision doesn't do anything useful unless you have a file called revision in your database. The docs probably need updating, though I'm not sure what to. mtn cat _MTN/revision is sorta what I think it's getting at, but that doesn't work and don't know which command dumps the, uh, revision (as in a block of text) of a particular revision (as in hash of that block of text). It's just out of date. I think mtn automate get_revision /new_id/ is the current equivalent to cat revision. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
