Re: [Monotone-devel] Error handling via automate
Nathaniel Smith wrote: (In fact 'automate stdio' makes me quite nervous for this reason already. I would feel better if part of its contract was that it would exit after an error, and it was the client's responsibility to restart it.) Speaking as someone who's writing something to use automate, I wouldn't have a problem with this strategy. automate stdio optimises for repeated strings of commands. Restarting the process isn't optimal, but it doesn't seem like it's a huge cost in the case of an error. -- Jon Bright Silicon Circus Ltd. http://www.siliconcircus.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Error handling via automate
Jon Bright schrieb: Nathaniel Smith wrote: (In fact 'automate stdio' makes me quite nervous for this reason already. I would feel better if part of its contract was that it would exit after an error, and it was the client's responsibility to restart it.) Speaking as someone who's writing something to use automate, I wouldn't have a problem with this strategy. automate stdio optimises for repeated strings of commands. Restarting the process isn't optimal, but it doesn't seem like it's a huge cost in the case of an error. This, however, doesn't solve at all the problem how a client application should be able to weight the fatalness of an error. If a user types in a revision ID by hand into an input field to which he wants to update (maybe he was pointed to it explicitely and doesn't use some nice selector interface), it may be sufficient for automate update or automate certs to tell the user f.e. the revision is unknown and not to exit completly. A subsequent mtn pull might fix this little problem already, so there is no need to exit from the process. IMHO one should *only* exit from the main process if further commands of the same and/or similar type will fail because of it as well, like no workspace found, database needs to be migrated, database locked and stuff like this. Most of those things already happen on stdio startup, but not all (I'd need to dive into mtn's code to make you a complete list, since I don't know exactly myself), like the previously stated database is locked error states. Thomas. -- - I know that I don't know. (Sokrates) Guitone, a frontend for monotone: http://guitone.berlios.de Music lyrics and more: http://musicmademe.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Error handling via automate
On Mon, Sep 11, 2006 at 12:55:36PM +0200, Jon Bright wrote: Thomas Keller wrote: This, however, doesn't solve at all the problem how a client application should be able to weight the fatalness of an error. Right. Being that the current error handling doesn't have any knowledge about fatalness, though, I'd suggest: 1. Make errors exit from automate stdio 2. Provide a way to mark errors as don't need restart 3. Mark non-fatal errors as don't need restart as and when they're discovered and manually examined to make sure that that's true. And one can also use step 3 to incrementally figure out which errors can occur for each command, and give them a number and document them. So we'd have two classes of errors, unknown errors which give a natural language message and exit stdio, and known errors which give a numeric message in addition to a natural language message, are documented, and do not cause stdio to exit. With the number of the former decreasing and the number of the latter increasing, over time. -- Nathaniel -- The Universe may / Be as large as they say But it wouldn't be missed / If it didn't exist. -- Piet Hein ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Error handling via automate
Nathaniel Smith schrieb: Another possibility in this particular case would be automate update simply require that the caller provide the target revision; then this error can't happen. Instead, the caller would go to get the target for the update, discover there were multiple candidates, and then ask the user (or whatever) before calling update at all. Theoretically this is possible, yes, obviously there is the small chance that between mtn automate heads and mtn automate updates a db transaction happens, which commits a new head and therefor result in an update to a (maybe) unwanted revision. Yes, the chance is very, very small, but I don't feel good about this =) Thomas. -- - I know that I don't know. (Sokrates) Guitone, a frontend for monotone: http://guitone.berlios.de Music lyrics and more: http://musicmademe.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Error handling via automate
Daniel Carosone schrieb: Would an 'automate' locale/translation, with machine-friendly messages like this, be unreasonable? I'd vote for that, definitely. Thomas. -- - I know that I don't know. (Sokrates) Guitone, a frontend for monotone: http://guitone.berlios.de Music lyrics and more: http://musicmademe.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Error handling via automate
Timothy Brownawell schrieb: Probably, yes. I don't really think that's the kind of thing gettext is designed for. (Also, AIUI, using gettext would require that you actually *install* monotone, so the translation files get put in the right place. Probably not a nice thing to require for making automate work correctly.) I was recently told that one could compile monotone in such a way that you point the `localedir` to something like `pwd`/po if you run make inside the checked out dir and this seems to work nicely. Better to just have our errors include an error code and not rely on translation machinery for that. In the end I'm fine with either way. One has to ensure though that the placing of an error identifier *inside* a translation is never changed e.g. because of grammatical issues, so it should be predefined like E123: locale error message here Thomas. -- - I know that I don't know. (Sokrates) Guitone, a frontend for monotone: http://guitone.berlios.de Music lyrics and more: http://musicmademe.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Error handling via automate
On Sun, Sep 10, 2006 at 12:34:56PM +1000, Daniel Carosone wrote: Would an 'automate' locale/translation, with machine-friendly messages like this, be unreasonable? Aside from being insane, I think it isn't possible -- you can't just use arbitrary strings for locales, at least on some systems (like linux) you have to actually build the supporting stuff system-wide for each locale you want to have available. (E.g., you would have to write something to /etc/locale.gen, then re-run locale-gen as root, etc.) -- Nathaniel -- Of course, the entire effort is to put oneself Outside the ordinary range Of what are called statistics. -- Stephan Spender ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Error handling via automate
On Sun, Sep 10, 2006 at 10:00:11AM +0200, Thomas Keller wrote: Nathaniel Smith schrieb: Another possibility in this particular case would be automate update simply require that the caller provide the target revision; then this error can't happen. Instead, the caller would go to get the target for the update, discover there were multiple candidates, and then ask the user (or whatever) before calling update at all. Theoretically this is possible, yes, obviously there is the small chance that between mtn automate heads and mtn automate updates a db transaction happens, which commits a new head and therefor result in an update to a (maybe) unwanted revision. Yes, the chance is very, very small, but I don't feel good about this =) It could just as well happen that immediately after you run 'update', but before you have a chance to even look at your shiny new workspace, some new revision arrives that, had it arrived just a few seconds earlier, you would rather have updated to it. Oh well, we have to get used to that possibility; lucky thing our tool works perfectly correctly either way :-). (In fact, the situation is logically the same as if someone committed a new revision to some _other_ database, and the reason you don't see it is not because of a race condition in update, but because it hasn't even been pushed yet. Lots easier to relax than to worry about such things.) -- Nathaniel -- Damn the Solar System. Bad light; planets too distant; pestered with comets; feeble contrivance; could make a better one myself. -- Lord Jeffrey ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Error handling via automate
On Sun, Sep 10, 2006 at 02:45:28AM -0700, Nathaniel Smith wrote: On Sun, Sep 10, 2006 at 12:34:56PM +1000, Daniel Carosone wrote: Would an 'automate' locale/translation, with machine-friendly messages like this, be unreasonable? Aside from being insane, I think it isn't possible Oh well, then I guess we have to make the messages in the code be the machine-friendly error code ones, and move the current default english messages out to translations like the others. Pity, I thought this might be a way to avoid that :) This means a lot of churn for translators now, but might eventually mean they get a similar benefit of stability as far as a fixed reference for each message. -- Dan. pgptN09Dn5XT5.pgp Description: PGP signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Error handling via automate
On Mon, 2006-09-11 at 13:08 +1000, Daniel Carosone wrote: On Sun, Sep 10, 2006 at 02:45:28AM -0700, Nathaniel Smith wrote: On Sun, Sep 10, 2006 at 12:34:56PM +1000, Daniel Carosone wrote: Would an 'automate' locale/translation, with machine-friendly messages like this, be unreasonable? Aside from being insane, I think it isn't possible Oh well, then I guess we have to make the messages in the code be the machine-friendly error code ones, and move the current default english messages out to translations like the others. Pity, I thought this might be a way to avoid that :) This means a lot of churn for translators now, but might eventually mean they get a similar benefit of stability as far as a fixed reference for each message. Or do the numeric error code + human-readable message thing, where the machine-friendly version is independent of the human-friendly version. Tim -- Free (experimental) public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Error handling via automate
On Fri, Sep 08, 2006 at 04:27:30PM +0200, Thomas Keller wrote: I'm currently struggle how to accomplish proper error handling for errors which are spit out by monotone's automate commands (and specifically mtn automate stdio). [...] Indeed -- thanks for the good summary of the issues. Error handling is a huge issue for automate, because all of monotone is written with the assumption that as soon as anything goes at all wrong, we kill the whole program. Therefore, there is no thought put into whether an error can ever leave us in an dangerous state, and no serious testing of any error unwind logic. In general we probably are pretty clean, but it only takes one nasty bug to corrupt data... (In fact 'automate stdio' makes me quite nervous for this reason already. I would feel better if part of its contract was that it would exit after an error, and it was the client's responsibility to restart it.) So one of the parts of extending automate (possibly the single biggest part) will be coming up with sensible error handling strategies, and making the core code play more nicely with it. Now consider that we get mtn automate update implemented some time in the future, and think about the fact that one cannot update to the newest revision automagically as long as there are multiple heads floating around. I assume the error which such a mtn automate update would give me will be pretty similar to the one the current mtn update would spit out. And there is the problem: If one cannot update because of multiple heads, this is a nonfatal error, since the user could get the choice of selecting the appropriate revision he'd like to update to. This error needs to be handled differently from a fatal error, as other operations on the currently viewed workspace (like add, drop, commit) aren't affected at all by the fact that there are multiple heads. Another possibility in this particular case would be automate update simply require that the caller provide the target revision; then this error can't happen. Instead, the caller would go to get the target for the update, discover there were multiple candidates, and then ask the user (or whatever) before calling update at all. Now I don't say distinguish between fatal and nonfatal errors, but I'd like to have a more general distinction of all errors than the native languaged based errors which are currently used. This distinction could be a globally defined error code, an error string or alike and would be either spit out directly if something goes wrong, or could be asked for by some get_error automate command (or vice versa). There are not many alternatives to this other than starting the stdio pipe with LC_MESSAGES=C and parse the original english strings[0], but this would affect all error strings and for some, like the above mentioned database error I'd surely like to have the proper (German) translation. I'd throw such an error to the user as its only him who can resolve it and in this case a native error would be far better than an English one. Right -- parsing is terrible, no-one should ever have to do that. You probably want both some sort of machine readable thing (i.e., a number or short string, which is documented and part of the interface), plus a human-readable message, so clients can pick which they want to use on a case-by-case basis. Possibly the structure of SMTP/HTTP/FTP/... style response codes are a useful precedent? Or possibly there should be a small set of errors defined on a per-command basis? -- Nathaniel -- The Universe may / Be as large as they say But it wouldn't be missed / If it didn't exist. -- Piet Hein ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Error handling via automate
On Sat, Sep 09, 2006 at 06:57:51PM -0700, Nathaniel Smith wrote: Another possibility in this particular case would be automate update simply require that the caller provide the target revision; then this error can't happen. Instead, the caller would go to get the target for the update, discover there were multiple candidates, and then ask the user (or whatever) before calling update at all. Sounds good. resolve it and in this case a native error would be far better than an English one. Possibly the structure of SMTP/HTTP/FTP/... style response codes are a useful precedent? Or possibly there should be a small set of errors defined on a per-command basis? Would an 'automate' locale/translation, with machine-friendly messages like this, be unreasonable? -- Dan. pgpHvbBaRQs52.pgp Description: PGP signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Error handling via automate
On Sun, 2006-09-10 at 12:34 +1000, Daniel Carosone wrote: Possibly the structure of SMTP/HTTP/FTP/... style response codes are a useful precedent? Or possibly there should be a small set of errors defined on a per-command basis? Would an 'automate' locale/translation, with machine-friendly messages like this, be unreasonable? Probably, yes. I don't really think that's the kind of thing gettext is designed for. (Also, AIUI, using gettext would require that you actually *install* monotone, so the translation files get put in the right place. Probably not a nice thing to require for making automate work correctly.) Better to just have our errors include an error code and not rely on translation machinery for that. Tim -- Free (experimental) public monotone hosting: http://mtn-host.prjek.net ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Error handling via automate
Hi all! I'm currently struggle how to accomplish proper error handling for errors which are spit out by monotone's automate commands (and specifically mtn automate stdio). Currently stdio only allows to distinguish three states: 0: no error 1: a syntax error popped up 2: any other error popped up Error no. 1 doesn't pop up at all if my interface properly feeds the needed command name and arguments into stdio (and this practically always happens since all commands I use are predefined), so basically stdio can only tell me there was an error or there was no error. Now comes the hard part: If there was an error, this error is obviously printed out via stdio as well, and, this error is of course translated and targeted to the end user, but not to my interface / program. However, I need to distinguish certain errors from others which come from there and base my further actions on the *type* of the error which popped up (let us call them fatal and nonfatal errors). To give you an example what I mean, consider the following error printed out via stdio: error: sqlite error: database is locked - another mtn process needs exclusive write access to a certain db, therefor no other actions are possible with this db until the write lock is released - if my GUI loads a new workspace, it triggers automate inventory to build the tree of files and its states. this fails with a locked db and is a fatal error for any further workspace actions since if I cannot build a tree, I have no UI to display to the user Now consider that we get mtn automate update implemented some time in the future, and think about the fact that one cannot update to the newest revision automagically as long as there are multiple heads floating around. I assume the error which such a mtn automate update would give me will be pretty similar to the one the current mtn update would spit out. And there is the problem: If one cannot update because of multiple heads, this is a nonfatal error, since the user could get the choice of selecting the appropriate revision he'd like to update to. This error needs to be handled differently from a fatal error, as other operations on the currently viewed workspace (like add, drop, commit) aren't affected at all by the fact that there are multiple heads. Now I don't say distinguish between fatal and nonfatal errors, but I'd like to have a more general distinction of all errors than the native languaged based errors which are currently used. This distinction could be a globally defined error code, an error string or alike and would be either spit out directly if something goes wrong, or could be asked for by some get_error automate command (or vice versa). There are not many alternatives to this other than starting the stdio pipe with LC_MESSAGES=C and parse the original english strings[0], but this would affect all error strings and for some, like the above mentioned database error I'd surely like to have the proper (German) translation. I'd throw such an error to the user as its only him who can resolve it and in this case a native error would be far better than an English one. Suggestions? Thomas. [0] Of course one has to cross the fingers that these strings do not change too often (i.e. wording) as it would break the interface... -- - I know that I don't know. (Sokrates) Guitone, a frontend for monotone: http://guitone.berlios.de Music lyrics and more: http://musicmademe.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
