[Monotone-devel] Re: 0.36 error on cygwin
Lapo Luchini wrote: $ mtn -d .monotone/it.lapo.mtn --debug pull lapo.it it.lapo.homedir [...] mtn: searching for '_MTN' directory with root '/' mtn: '_MTN' not found in '/home/lapo' with '' removed mtn: '_MTN' not found in '/home' with 'lapo' removed mtn: /home/lapo/packaging/tmp/monotone-0.36/unix/fs.cc:124: detected error 'E(false)' violated mtn: [...] mtn: error: error accessing file //_MTN: No such host or network path Fixed. Please someone take a look at: % mtn diff -r 4c7504ea -r 22a49837 (I will take a look at buildbots after the propagation, anyway...) Lapo ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Further update to notification script
This morning my mailbox was full of error reports - I wasn't caching the current time but looking it up twice and of course it can change. So he's a patch to fix that and I've also updated the README file for contrib. Could someone commit the patch please? Many thanks, Matthew -- Matthew Sackman http://www.wellquite.org/ # # old_revision [4c7504ea753f15bde2abc80e0e74dfc0951735e4] # # patch contrib/README # from [a5a965b9b3fed717621b8c216ec226756a95e568] #to [9c675c56a2e014932a16079f1a580b427c2cff15] # # patch contrib/monotone-mail-notify-standalone.lua # from [b451b8b6da1a0f92dcb9d372fe1935972f9eafaa] #to [f7912c79e41bff48c12b54e25bad92a03d5bc031] # --- contrib/README a5a965b9b3fed717621b8c216ec226756a95e568 +++ contrib/README 9c675c56a2e014932a16079f1a580b427c2cff15 @@ -64,7 +64,10 @@ See individual files for licenses. for use. -- monotone-mail-notify-standalone.lua: a mail notification script which - runs without any other external dependencies than /usr/bin/mail and offers an individual per-branch recipient configuration with a syntax - similar to the one found in ~/.monotone/read-permissions + similar to the one found in ~/.monotone/read-permissions. + It writes out details of each revision received to files which are then + picked up by the monotone-mail-notify-standalone.sh script which requires + shell, source-highlight and mime-construct to build nicely structured + emails with summaries of the revision and its diffs. --- contrib/monotone-mail-notify-standalone.lua b451b8b6da1a0f92dcb9d372fe1935972f9eafaa +++ contrib/monotone-mail-notify-standalone.lua f7912c79e41bff48c12b54e25bad92a03d5bc031 @@ -133,9 +133,11 @@ do if j # (rev_data[certs][author]) then reply_to = reply_to .. , end end -local outputFileRev = io.open(_base .. rev_data[revision] .. os.time() .. .rev.txt, w+) -local outputFileHdr = io.open(_base .. rev_data[revision] .. os.time() .. .hdr.txt, w+) +local now = os.time() +local outputFileRev = io.open(_base .. rev_data[revision] .. now .. .rev.txt, w+) +local outputFileHdr = io.open(_base .. rev_data[revision] .. now .. .hdr.txt, w+) + local to = for j,addr in pairs(rev_data[recipients]) do to = to .. addr ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: [monotone wiki] Änderung von ISO14000 环境管理体系认证的意义 von 521jin gke8866
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all! Could we please do something permanently against the recent spam flood in the wiki? I'd vote for disabling anonymous edits, but if anyone has some time (and access to the wiki) to play with akismet or else, feel free. Thomas. - -- only dead fish swim with the stream: http://thomaskeller.biz/blog Am Anfang war das Wort: http://www.schäuble-muss-weg.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHCeOMaf7NlBYNEJIRAii6AJ9IXA3uaHn2nXtbYrUZQewam8VjDACgswAn ZYwyLNwbkliPu08hnac64ys= =kKrg -END PGP SIGNATURE- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] colored diffs [Was: [PATCH] parent selector 'p:xxx']
Derek Scherger wrote: (What's this diffc-0.3 thing?) It's just some perl script that colorizes diffs in a way that seems to look nice. It used to be available at http://download.gnu.org/diffc-0.3 but I can't seem to get there at the moment. Personally, I use FreeBSD's cdiff (both on FreeBSD and on Cygwin): http://www.freebsd.org/cgi/cvsweb.cgi/ports/textproc/cdiff/src/ Lapo ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: [PATCH] parent selector 'p:xxx'
Ethan Blanton wrote: Even when it is correct, for Pidgin it often has 3-5 parallel lines at two columns apiece, and often it mistakenly draws O(a lot) of parallel lines. BTW: As far as correctness goes, I think it is correct. The problem is it is usually run on a restricted set of nodes and proper use of daggy fixes lead to merges with very old nodes (and thus very long arcs in the overall DAG). Lapo ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Further update to notification script
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthew Sackman schrieb: This morning my mailbox was full of error reports - I wasn't caching the current time but looking it up twice and of course it can change. So he's a patch to fix that and I've also updated the README file for contrib. Could someone commit the patch please? Applied in 3ae9515ab35b20ff8b04376fd768ccb867f233af, I also renamed the files and removed the -standalone part we've talked about. Thomas. - -- only dead fish swim with the stream: http://thomaskeller.biz/blog Am Anfang war das Wort: http://www.schäuble-muss-weg.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHCelxaf7NlBYNEJIRAgSuAKDoAcF/cf0Nh9xJXb3uTdEUE7IRRACdG7jg 5QVwuuYFnRgQ7LTukSxACuA= =iz3C -END PGP SIGNATURE- ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Further update to notification script
On Mon, Oct 08, 2007 at 10:25:21AM +0200, Thomas Keller wrote: Applied in 3ae9515ab35b20ff8b04376fd768ccb867f233af, I also renamed the files and removed the -standalone part we've talked about. Many thanks indeed. 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] Further update to notification script
Seems like you should just get commit access to me... Who's in charge of adding people to the server these days? Richard? On Mon, Oct 08, 2007 at 08:33:16AM +0100, Matthew Sackman wrote: This morning my mailbox was full of error reports - I wasn't caching the current time but looking it up twice and of course it can change. So he's a patch to fix that and I've also updated the README file for contrib. Could someone commit the patch please? Many thanks, Matthew -- Matthew Sackman http://www.wellquite.org/ # # old_revision [4c7504ea753f15bde2abc80e0e74dfc0951735e4] # # patch contrib/README # from [a5a965b9b3fed717621b8c216ec226756a95e568] #to [9c675c56a2e014932a16079f1a580b427c2cff15] # # patch contrib/monotone-mail-notify-standalone.lua # from [b451b8b6da1a0f92dcb9d372fe1935972f9eafaa] #to [f7912c79e41bff48c12b54e25bad92a03d5bc031] # --- contrib/READMEa5a965b9b3fed717621b8c216ec226756a95e568 +++ contrib/README9c675c56a2e014932a16079f1a580b427c2cff15 @@ -64,7 +64,10 @@ See individual files for licenses. for use. -- monotone-mail-notify-standalone.lua: a mail notification script which - runs without any other external dependencies than /usr/bin/mail and offers an individual per-branch recipient configuration with a syntax - similar to the one found in ~/.monotone/read-permissions + similar to the one found in ~/.monotone/read-permissions. + It writes out details of each revision received to files which are then + picked up by the monotone-mail-notify-standalone.sh script which requires + shell, source-highlight and mime-construct to build nicely structured + emails with summaries of the revision and its diffs. --- contrib/monotone-mail-notify-standalone.lua b451b8b6da1a0f92dcb9d372fe1935972f9eafaa +++ contrib/monotone-mail-notify-standalone.lua f7912c79e41bff48c12b54e25bad92a03d5bc031 @@ -133,9 +133,11 @@ do if j # (rev_data[certs][author]) then reply_to = reply_to .. , end end -local outputFileRev = io.open(_base .. rev_data[revision] .. os.time() .. .rev.txt, w+) -local outputFileHdr = io.open(_base .. rev_data[revision] .. os.time() .. .hdr.txt, w+) +local now = os.time() +local outputFileRev = io.open(_base .. rev_data[revision] .. now .. .rev.txt, w+) +local outputFileHdr = io.open(_base .. rev_data[revision] .. now .. .hdr.txt, w+) + local to = for j,addr in pairs(rev_data[recipients]) do to = to .. addr ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel -- 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] [PATCH] parent selector 'p:xxx'
On Sun, Oct 07, 2007 at 09:58:14PM -0600, Derek Scherger wrote: Ethan Blanton wrote: I believe that it should; if it is more than just a few columns wide, it tends to make diffs and commit messages wrap on terminals they are meant to accommodate, and it displays an unfortunate tendency to be far more than a few columns wide. Even when it is correct, for Pidgin it often has 3-5 parallel lines at two columns apiece, and often it mistakenly draws O(a lot) of parallel lines. This seems fixable -- we know how wide the terminal is (the ticker code needs this), we know that the graph becomes *completely* useless when wrapping happens, so we can just teach monotone to do the Right Thing (i.e. disable the graph when it gets too wide, perhaps only for portions of time when it is too wide). There are a lot of other ways that the graphs are not as smart as they could be, and currently require --no-graph -- e.g., if you use --no-merges (like one of the examples upthread) then right now you basically have to use --no-graph. So that's easy to make right-by-default too. The other example given was as part of a hack to create a command that mtn should have anyway -- so when we add that command, that need for --no-graph will disappear as well. The graphs would also be more useful if log output were shorter (and esp. the merge output were less completely stupid than it is now -- showing every file touched on either side of the merge makes No Sense). Another thought. Maybe what we really need is something like .csvrc where you can specify the default options that you generally want with specific commands. I'm not sure how you would occasionally un-set options that were set like this though. This would be an easy way to make this problem go away, but I'm not convinced that it's the correct one. It seems to me that the problems with the graphs are more specific, and fixable as such. -- Nathaniel -- If you can explain how you do something, then you're very very bad at it. -- John Hopfield ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Further update to notification script
On Mon, Oct 08, 2007 at 02:10:28AM -0700, Nathaniel Smith wrote: Seems like you should just get commit access to me... Who's in charge of adding people to the server these days? Richard? I did used to have commit access - I definately sent my pubkey to Richard a while back. But then after the servers changed I think my write access was removed/lost, which is fair enough as I hadn't done any work for some time... Matthew ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: colored diffs [Was: [PATCH] parent selector 'p:xxx']
Lapo Luchini wrote: Derek Scherger wrote: (What's this diffc-0.3 thing?) It's just some perl script that colorizes diffs in a way that seems to look nice. It used to be available at http://download.gnu.org/diffc-0.3 but I can't seem to get there at the moment. Personally, I use FreeBSD's cdiff (both on FreeBSD and on Cygwin): http://www.freebsd.org/cgi/cvsweb.cgi/ports/textproc/cdiff/src/ We could, in fact, add a --color option to mtn diff itself... Pro: no need to have perl, no need to constantly pipe things Cons: probably need an external one in the system anyway Also mtn log and mtn status would have a big benefit from colors, in fact. It could be nice to use them... should probably be off by default, but turnable on by default using an hook or something. Does anyone object if I implement that? ;-) Lapo ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: [PATCH] parent selector 'p:xxx'
Lapo Luchini spake unto us the following wisdom: Ethan Blanton wrote: Even when it is correct, for Pidgin it often has 3-5 parallel lines at two columns apiece, and often it mistakenly draws O(a lot) of parallel lines. BTW: As far as correctness goes, I think it is correct. The problem is it is usually run on a restricted set of nodes and proper use of daggy fixes lead to merges with very old nodes (and thus very long arcs in the overall DAG). In this case, correct is in the eye of the beholder. It might be technically correct, but still be presenting useless information which makes it functionally incorrect. As an example, if I log only a dozen revisions, and there is only one divergence and merge within those dozen revisions, there should be no more than two lines -- but sometimes there will be tens of lines from the first revision to the very last, representing (I presume) parallel and unrelated divergences. I think Richard Levitte sent an example of this to the list, some time back. That said, there are places in the Pidgin history where the graph code shows tens of parallel revisions, where monotone-viz shows two or three -- they can't both be right, if they are both displaying the same data. ;-) Ethan -- The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, On Crimes and Punishments, 1764 signature.asc Description: Digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: colored diffs [Was: [PATCH] parent selector 'p:xxx']
On Oct 8, 2007, at 4:04 PM, Lapo Luchini wrote: Lapo Luchini wrote: Derek Scherger wrote: (What's this diffc-0.3 thing?) It's just some perl script that colorizes diffs in a way that seems to look nice. It used to be available at http://download.gnu.org/ diffc-0.3 but I can't seem to get there at the moment. Personally, I use FreeBSD's cdiff (both on FreeBSD and on Cygwin): http://www.freebsd.org/cgi/cvsweb.cgi/ports/textproc/cdiff/src/ We could, in fact, add a --color option to mtn diff itself... There are, in fact, two entries in the ROADMAP about this that I added when using cogito in another project. Cogito automatically pages output internally (if the output is directed to a terminal) and has an option to enable colored output for log and diff. These two features were very nice, and hence why I put them in that file ;) -- Julio M. Merino Vidal [EMAIL PROTECTED] ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Break after kill_rev_locally
I today had to use mtn db kill_rev_locally rev where rev was the head of a branch. First, everything looked just fine. I freshly checked out a new workspace (now based on the previous revision on the branch which is now the new head), performed a mtn log to be sure that just the previous head revision got dropped, etc. Then I edited the sources and tried to commit the changes: Bang! | $ mtn ci -m adjust key modify commands | mtn: beginning commit on branch 'OSSP.ase.src.TMP.keys' | terminate called after throwing an instance of 'std::logic_error' | what(): lru_writeback_cache.hh:99: invariant 'I(_dirty.empty())' violated | mtn: fatal signal: Abort trap: 6 | this is almost certainly a bug in monotone. | please send this error message, the output of 'mtn --full-version', | and a description of what you were doing to monotone-devel@nongnu.org | do not send a core dump, but if you have one, | please preserve it in case we ask you for information from it. The only way to rescue the situation was to restore the database from the last UFS snapshot (luckily no other changes happended in the meantime) in order to be able to proceed again. For me this looks like mtn db kill_rev_locally rev does not remove _all_ related information of rev and that some remaining/dangling information causes the subsequent commit to break. Hmm... Unfortunately, I was not able to repeat this with a simple test where I created a fresh database, performed three commits and killed the third commit :-( Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: colored diffs [Was: [PATCH] parent selector 'p:xxx']
On Mon, Oct 08, 2007, Julio M. Merino Vidal wrote: [...] From the screenshots you posted, I don't see how you are piping mtn's output to your engine. Did you replace the mtn executable with a script that executes the real one and pipes the output? Yes, OSSP p2 can be either activated via a shell alias (in GNU bash: alias mtn=p2 mtn) or via automatically generated wrapper symlinks (e.g. p2 --generate ~/.p2/wrapper plus PATH=~/.p2/wrapper:$PATH). For interactively entered commands there is no difference. For indirectly called commands (e.g. make executing gcc and OSSP p2 should provide error colorization for gcc) the aliasing doesn't work and the symlink wrappers have to be used. In the screenshots I used the wrapper symlink for mtn, but the alias would just fine, too. OSSP p2 itself spawns the mtn command itself and connects its stdin to the stdin of mtn and intercepts the stdout and stderr of the mtn command in an I/O multiplexing way. The this way captured outputs are then passed through one or more plugins which in turn use regular expression based output post-processing. The plugins theirself can be either written programmatically as Perl modules or in a declarative way via an OSSP cfg style configuration file. The mtn plugin is coded as a Perl module. After the output post-processing OSSP p2 sends the output to its own stdout and stderr channels. This whole approach is a lot more tricky than it sounds on the first spot because of line-based output buffering, interrupts through signals, the pager has to read interactive keyboard input not from stdin but /dev/tty to not conflict with data for the command on stdin, etc. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Break after kill_rev_locally
Ralf S. Engelschall [EMAIL PROTECTED] writes: I today had to use mtn db kill_rev_locally rev where rev was the head of a branch. First, everything looked just fine. I freshly checked out a new workspace (now based on the previous revision on the branch which is now the new head), performed a mtn log to be sure that just the previous head revision got dropped, etc. Then I edited the sources and tried to commit the changes: Bang! | $ mtn ci -m adjust key modify commands | mtn: beginning commit on branch 'OSSP.ase.src.TMP.keys' | terminate called after throwing an instance of 'std::logic_error' | what(): lru_writeback_cache.hh:99: invariant 'I(_dirty.empty())' violated | mtn: fatal signal: Abort trap: 6 | this is almost certainly a bug in monotone. | please send this error message, the output of 'mtn --full-version', | and a description of what you were doing to monotone-devel@nongnu.org | do not send a core dump, but if you have one, | please preserve it in case we ask you for information from it. The only way to rescue the situation was to restore the database from the last UFS snapshot (luckily no other changes happended in the meantime) in order to be able to proceed again. For me this looks like mtn db kill_rev_locally rev does not remove _all_ related information of rev and that some remaining/dangling information causes the subsequent commit to break. Hmm... Unfortunately, I was not able to repeat this with a simple test where I created a fresh database, performed three commits and killed the third commit :-( I had the same, or a very similar symptom after killing the head of a branch that happened to be a propagate (A to B) node. I then did mtn propagate B A (which was what I really intended) and got an exception. The killed revision and the new revision had the same revision ID. To correct the problem, I synced the offending database into a fresh one and could then proceed with the propagate and commit. -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: colored diffs [Was: [PATCH] parent selector 'p:xxx']
On 10/8/07, Lapo Luchini [EMAIL PROTECTED] wrote: We could, in fact, add a --color option to mtn diff itself... [...] Also mtn log and mtn status would have a big benefit from colors, in fact. It could be nice to use them... should probably be off by default, but turnable on by default using an hook or something. Does anyone object if I implement that? ;-) It's a good idea but you need to be careful how you implement it. Hardwiring VT220 color control codes would be bad. So would making us depend on ncurses. I'd suggest a set of Lua hooks that know the necessary escape sequences for the most common TERM= settings (xterm, etc) and can query the 'tput' utility for less common ones. You could also use this to get at the line-drawing characters for asciik... zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] pulling restricted branches
Hi there! I have trouble pulling from monotone.ca for a while now: Whenever I try to pull from there I end up with this message: mtn: warning: protocol error while processing peer monotone.ca: 'received network error: anonymous access to branch 'au.asn.ucc.matt.botan.monotone-2' denied by server' Afterwards the pull stops (with about 150byte having gone in and out). Would it be possible to have monotone just ignore the branch and continue after giving that warning? How can I change the default branch pattern used by pull? Manually giving net.venge.\* after a pull is somewhat tiresome;-) How can I find out which branch pattern is currently in use? What is the recommended branch pattern for monotone.ca? net.venge.* seems to work, but I am afraid to miss out some of the cool new stuff using it;-) Thanks for your time (and monotone of course!) Best Regards, Tobias ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: pulling restricted branches
Tobias Hunger wrote:
mtn: warning: protocol error while processing peer monotone.ca: 'received
network error: anonymous access to branch 'au.asn.ucc.matt.botan.monotone-2'
denied by server'
Non every branch is readable anonymously, on that server.
How can I change the default branch pattern used by pull? Manually giving
net.venge.\* after a pull is somewhat tiresome;-)
% mtn pull/sync/push --set-default server pattern
How can I find out which branch pattern is currently in use?
% mtn ls vars
What is the recommended branch pattern for monotone.ca? net.venge.* seems to
work, but I am afraid to miss out some of the cool new stuff using it;-)
I usually use '{net.venge.monotone,net.venge.monotone.*}' which is
already more than the simple monotone (some external apps actually
reside under that branch).
Lapo
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: colored diffs [Was: [PATCH] parent selector 'p:xxx']
Zack Weinberg spake unto us the following wisdom: On 10/8/07, Lapo Luchini [EMAIL PROTECTED] wrote: We could, in fact, add a --color option to mtn diff itself... [...] Also mtn log and mtn status would have a big benefit from colors, in fact. It could be nice to use them... should probably be off by default, but turnable on by default using an hook or something. Does anyone object if I implement that? ;-) It's a good idea but you need to be careful how you implement it. Hardwiring VT220 color control codes would be bad. So would making us depend on ncurses. ncurses is far less odious than boost -- most systems actually *have* ncurses, and it doesn't kick compilation times into the stratosphere, either. ;-) I agree that hardcoding escape sequences is a bad idea, but I really think ncurses is the right answer. Worst case scenario, it could be compile-time optional, and color output could simply be ommitted on systems without ncurses (does such a system exist?). I'd suggest a set of Lua hooks that know the necessary escape sequences for the most common TERM= settings (xterm, etc) and can query the 'tput' utility for less common ones. You could also use this to get at the line-drawing characters for asciik... Down this path lies madness. You're reinventing terminfo. Ethan -- The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, On Crimes and Punishments, 1764 signature.asc Description: Digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: colored diffs [Was: [PATCH] parent selector 'p:xxx']
On 10/8/07, Ethan Blanton [EMAIL PROTECTED] wrote: It's a good idea but you need to be careful how you implement it. Hardwiring VT220 color control codes would be bad. So would making us depend on ncurses. ncurses is far less odious than boost -- most systems actually *have* ncurses, and it doesn't kick compilation times into the stratosphere, either. ;-) Well, probably it wouldn't be much trouble, but I must point out that GNU ls manages to have optional colorized output without depending on ncurses (however, I have no idea how that feature works). I'd suggest a set of Lua hooks that know the necessary escape sequences for the most common TERM= settings (xterm, etc) and can query the 'tput' utility for less common ones. You could also use this to get at the line-drawing characters for asciik... Down this path lies madness. You're reinventing terminfo. Not so - it's just a more arms-length version of the code we would write if we used ncurses directly. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: colored diffs [Was: [PATCH] parent selector 'p:xxx']
On Mon, Oct 08, 2007 at 08:32:45PM +0100, Zack Weinberg wrote: It's a good idea but you need to be careful how you implement it. Hardwiring VT220 color control codes would be bad. So would making us depend on ncurses. I'd suggest a set of Lua hooks that know the necessary escape sequences for the most common TERM= settings (xterm, etc) and can query the 'tput' utility for less common ones. You could also use this to get at the line-drawing characters for asciik... Before going this route, could you expand on hardwiring VT220 color control codes would be bad? Are there any terminals we actually care about that this would fail on? (Note that the grep and ls maintainers have both answered no to this question; search for the string '33[' in their source code. ls at least appears to also have a whitelist of $TERM values that are colorizable, dunno about grep.) -- Nathaniel -- Eternity is very long, especially towards the end. -- Woody Allen ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: colored diffs [Was: [PATCH] parent selector 'p:xxx']
On 10/8/07, Nathaniel Smith [EMAIL PROTECTED] wrote: I'd suggest a set of Lua hooks that know the necessary escape sequences for the most common TERM= settings (xterm, etc) and can query the 'tput' utility for less common ones. Before going this route, could you expand on hardwiring VT220 color control codes would be bad? Are there any terminals we actually care about that this would fail on? I was under the impression that the control codes for 256-color xterm were significantly different than the codes for VT220; for instance. But if the grep and ls maintainers have decided that VT220 codes plus whitelist is good enough for them, then that's good enough for me too. :-) zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Re: colored diffs [Was: [PATCH] parent selector 'p:xxx']
Zack Weinberg spake unto us the following wisdom: On 10/8/07, Ethan Blanton [EMAIL PROTECTED] wrote: It's a good idea but you need to be careful how you implement it. Hardwiring VT220 color control codes would be bad. So would making us depend on ncurses. ncurses is far less odious than boost -- most systems actually *have* ncurses, and it doesn't kick compilation times into the stratosphere, either. ;-) Well, probably it wouldn't be much trouble, but I must point out that GNU ls manages to have optional colorized output without depending on ncurses (however, I have no idea how that feature works). GNU ls hardwires VT220 color codes, and there is a list of acceptable TERM names for which it is used. I think it consults COLORTERM as well, but I'm not sure -- I'd have to check the documentation. I'd suggest a set of Lua hooks that know the necessary escape sequences for the most common TERM= settings (xterm, etc) and can query the 'tput' utility for less common ones. You could also use this to get at the line-drawing characters for asciik... Down this path lies madness. You're reinventing terminfo. Not so - it's just a more arms-length version of the code we would write if we used ncurses directly. The tput part is -- which is slow, but correct. The other part is the reinventing terminfo bit. ;-) It also makes the assumption that TERM=foo means the same thing in every location, which it may or may not. I guess I really don't see ncurses as a problem, but maybe I'm too old-fashioned. ;-) Ethan -- The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, On Crimes and Punishments, 1764 signature.asc Description: Digital signature ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Further update to notification script
In message [EMAIL PROTECTED] on Mon, 8 Oct 2007 02:10:28 -0700, Nathaniel Smith [EMAIL PROTECTED] said: njs Seems like you should just get commit access to me... Who's in njs charge of adding people to the server these days? Richard? Until I apply some policy stuff, yes. 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] Further update to notification script
In message [EMAIL PROTECTED] on Mon, 8 Oct 2007 10:36:32 +0100, Matthew Sackman [EMAIL PROTECTED] said: matthew On Mon, Oct 08, 2007 at 02:10:28AM -0700, Nathaniel Smith wrote: matthew Seems like you should just get commit access to me... Who's matthew in charge of adding people to the server these days? Richard? matthew matthew I did used to have commit access - I definately sent my matthew pubkey to Richard a while back. But then after the servers matthew changed I think my write access was removed/lost, which is matthew fair enough as I hadn't done any work for some time... Uhmmm, I can't have added it before the server change, because I didn't have that kind of access. Thing is, I can't see any public key with your name in the database that I have, so it's likely that you were never added by me. Please send me your public key and I'll add it. 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
