{"thread":{"id":"8253","subject":"[StGit PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current'","startedAt":"2007-05-20T20:03:57Z","lastAt":"2007-05-22T13:29:27Z","messageCount":15,"participants":["Robin Rosenberg","Yann Dirson","Karl Hasselström","Catalin Marinas"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"42774","messageId":"20070520200113.14633.90705.stgit@lathund.dewire.com","threadId":"8253","inReplyTo":"20070506150852.8985.98091.stgit@yoghurt","subject":"[StGit PATCH 0/2] Bash prompt updates","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg@dewire.com","sentAt":"2007-05-20T20:03:57Z","receivedAt":"2007-05-20T20:03:57Z","isPatch":true,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"Here is a fix to update the bash prompt so it does not\nuse the obsolete current file anymore.\n\nPart 2 is my version which uses a different format, mostly\nbecause '/' can be part of the branch name.\n\n-- robin\n"},{"id":"42773","messageId":"20070520200403.14633.26644.stgit@lathund.dewire.com","threadId":"8253","inReplyTo":"20070520200113.14633.90705.stgit@lathund.dewire.com","subject":"[StGit PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current'","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg@dewire.com","sentAt":"2007-05-20T20:04:03Z","receivedAt":"2007-05-20T20:04:03Z","isPatch":true,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>\n---\n\n contrib/stgbashprompt.sh |    4 ++--\n 1 files changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/contrib/stgbashprompt.sh b/contrib/stgbashprompt.sh\nindex 16bb39b..7c5dc76 100755\n--- a/contrib/stgbashprompt.sh\n+++ b/contrib/stgbashprompt.sh\n@@ -8,8 +8,8 @@ if [ \"$PS1\" ]; then\n \t\tgit_dir=$(git-rev-parse --git-dir 2> /dev/null) || return\n \t\tref=$(git-symbolic-ref HEAD 2> /dev/null) || return\n \t\tbr=${ref#refs/heads/}\n-\t\ttop=$(cat $git_dir/patches/$br/current 2>/dev/null) \\\n-\t\t\t&& top=\"/$top\"\n+\t\ttop=$(tail -1 $git_dir/patches/$br/applied 2>/dev/null) \\\n+\t\t\t&& top=\"/$top\";\n \t\techo \"[$br$top]\"\n \t}\n \tPS1='\\u@\\h:$(__prompt_git)\\W\\$ '\n"},{"id":"42775","messageId":"20070520200408.14633.12056.stgit@lathund.dewire.com","threadId":"8253","inReplyTo":"20070520200113.14633.90705.stgit@lathund.dewire.com","subject":"[StGit PATCH 2/2] Don't use / as separatar since it is common i branch names","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg@dewire.com","sentAt":"2007-05-20T20:04:08Z","receivedAt":"2007-05-20T20:04:08Z","isPatch":true,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>\n---\n\n contrib/stgbashprompt.sh |    6 +++---\n 1 files changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/contrib/stgbashprompt.sh b/contrib/stgbashprompt.sh\nindex 7c5dc76..732966a 100755\n--- a/contrib/stgbashprompt.sh\n+++ b/contrib/stgbashprompt.sh\n@@ -8,9 +8,9 @@ if [ \"$PS1\" ]; then\n \t\tgit_dir=$(git-rev-parse --git-dir 2> /dev/null) || return\n \t\tref=$(git-symbolic-ref HEAD 2> /dev/null) || return\n \t\tbr=${ref#refs/heads/}\n-\t\ttop=$(tail -1 $git_dir/patches/$br/applied 2>/dev/null) \\\n-\t\t\t&& top=\"/$top\";\n-\t\techo \"[$br$top]\"\n+\t\ttop=$(tail -1 $git_dir/patches/$br/applied 2>/dev/null)\n+\t\ttop=${top:-(none)}\n+\t\techo \"[$top@$br]\"\n \t}\n \tPS1='\\u@\\h:$(__prompt_git)\\W\\$ '\n fi\n"},{"id":"42787","messageId":"20070520204627.GR19253@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"8253","inReplyTo":"20070520200403.14633.26644.stgit@lathund.dewire.com","subject":"Re: [StGit PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current'","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-05-20T20:46:27Z","receivedAt":"2007-05-20T20:46:27Z","isPatch":true,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"Note that \"tail -1\" gives a warning with newer versions, \"tail -n 1\"\nshould be the proper call.\n\nAlso I'm not sure it is a good way to look at \"applied\" file, since\nKarl IIRC has plans to change this.  Better call \"stg top\" and not\ntouch that again :)\n\nOn Sun, May 20, 2007 at 10:04:03PM +0200, Robin Rosenberg wrote:\n> Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>\n> ---\n> \n>  contrib/stgbashprompt.sh |    4 ++--\n>  1 files changed, 2 insertions(+), 2 deletions(-)\n> \n> diff --git a/contrib/stgbashprompt.sh b/contrib/stgbashprompt.sh\n> index 16bb39b..7c5dc76 100755\n> --- a/contrib/stgbashprompt.sh\n> +++ b/contrib/stgbashprompt.sh\n> @@ -8,8 +8,8 @@ if [ \"$PS1\" ]; then\n>  \t\tgit_dir=$(git-rev-parse --git-dir 2> /dev/null) || return\n>  \t\tref=$(git-symbolic-ref HEAD 2> /dev/null) || return\n>  \t\tbr=${ref#refs/heads/}\n> -\t\ttop=$(cat $git_dir/patches/$br/current 2>/dev/null) \\\n> -\t\t\t&& top=\"/$top\"\n> +\t\ttop=$(tail -1 $git_dir/patches/$br/applied 2>/dev/null) \\\n> +\t\t\t&& top=\"/$top\";\n>  \t\techo \"[$br$top]\"\n>  \t}\n>  \tPS1='\\u@\\h:$(__prompt_git)\\W\\$ '\n> \n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n> \n> !DSPAM:4650aff673931961316905!\n> \n"},{"id":"42797","messageId":"20070520211103.17468.21373.stgit@lathund.dewire.com","threadId":"8253","inReplyTo":"20070520204627.GR19253@nan92-1-81-57-214-146.fbx.proxad.net","subject":"[PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current'","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg@dewire.com","sentAt":"2007-05-20T21:22:00Z","receivedAt":"2007-05-20T21:22:00Z","isPatch":true,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>\n\ns�ndag 20 maj 2007 skrev Yann Dirson:\n> Note that \"tail -1\" gives a warning with newer versions, \"tail -n 1\"\n> should be the proper call.\nMy man page doesn't mention -N being deprecated, but ok since -n 1 seems\nto work here too.\n \n> Also I'm not sure it is a good way to look at \"applied\" file, since\n> Karl IIRC has plans to change this.  Better call \"stg top\" and not\n> touch that again :)\n\nCalling stg is too slow to be be used here. I that command in my first draft\nfor this function and people complained (see the thread named \"Bash snippet\nto show branch and patch in bash prompt\"). It takes ~ 0.15s on here which is\nvery noticable, barely below my pain threshold. \n\nWe'll update the prompt when and if Karl breaks this.\n\nIt'd probably drain my battery too :/\n\n-- robin\n\n contrib/stgbashprompt.sh |    4 ++--\n 1 files changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/contrib/stgbashprompt.sh b/contrib/stgbashprompt.sh\nindex 16bb39b..f4817a1 100755\n--- a/contrib/stgbashprompt.sh\n+++ b/contrib/stgbashprompt.sh\n@@ -8,8 +8,8 @@ if [ \"$PS1\" ]; then\n \t\tgit_dir=$(git-rev-parse --git-dir 2> /dev/null) || return\n \t\tref=$(git-symbolic-ref HEAD 2> /dev/null) || return\n \t\tbr=${ref#refs/heads/}\n-\t\ttop=$(cat $git_dir/patches/$br/current 2>/dev/null) \\\n-\t\t\t&& top=\"/$top\"\n+\t\ttop=$(tail -n 1 $git_dir/patches/$br/applied 2>/dev/null) \\\n+\t\t\t&& top=\"/$top\";\n \t\techo \"[$br$top]\"\n \t}\n \tPS1='\\u@\\h:$(__prompt_git)\\W\\$ '\n"},{"id":"42800","messageId":"20070520212205.17468.71900.stgit@lathund.dewire.com","threadId":"8253","inReplyTo":"20070520204627.GR19253@nan92-1-81-57-214-146.fbx.proxad.net","subject":"[PATCH 2/2] Don't use / as separatar since it is common i branch names","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg@dewire.com","sentAt":"2007-05-20T21:24:15Z","receivedAt":"2007-05-20T21:24:15Z","isPatch":true,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"    Don't use / as separatar since it is common i branch names\n    \n    Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>\n\ndiff --git a/contrib/stgbashprompt.sh b/contrib/stgbashprompt.sh\nindex f4817a1..5927e67 100755\n--- a/contrib/stgbashprompt.sh\n+++ b/contrib/stgbashprompt.sh\n@@ -9,8 +9,8 @@ if [ \"$PS1\" ]; then\n \t\tref=$(git-symbolic-ref HEAD 2> /dev/null) || return\n \t\tbr=${ref#refs/heads/}\n \t\ttop=$(tail -n 1 $git_dir/patches/$br/applied 2>/dev/null) \\\n-\t\t\t&& top=\"/$top\";\n-\t\techo \"[$br$top]\"\n+\t\ttop=${top:-(none)}\n+\t\techo \"[$top@$br]\"\n \t}\n \tPS1='\\u@\\h:$(__prompt_git)\\W\\$ '\n fi\n"},{"id":"42861","messageId":"20070521074838.GA32510@diana.vm.bytemark.co.uk","threadId":"8253","inReplyTo":"20070520211103.17468.21373.stgit@lathund.dewire.com","subject":"Re: [PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current'","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-21T07:48:38Z","receivedAt":"2007-05-21T07:48:38Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-20 23:22:00 +0200, Robin Rosenberg wrote:\n\n> söndag 20 maj 2007 skrev Yann Dirson:\n>\n> > Also I'm not sure it is a good way to look at \"applied\" file,\n> > since Karl IIRC has plans to change this. Better call \"stg top\"\n> > and not touch that again :)\n>\n> Calling stg is too slow to be be used here. I that command in my\n> first draft for this function and people complained (see the thread\n> named \"Bash snippet to show branch and patch in bash prompt\"). It\n> takes ~ 0.15s on here which is very noticable, barely below my pain\n> threshold.\n>\n> We'll update the prompt when and if Karl breaks this.\n\nYes, I can confirm that I'm hard at work breaking this. :-) I'm trying\nout a way to get around the performance bug Catalin found, but I\ndidn't have time to finish it yesterday.\n\nIf that work is included, you could simply find the top patch by doing\ngit-show-ref and figuring out which patch has the same sha1 as HEAD.\n\nBut it sucks that stg starts so slowly. It has gotten better, I\nbelieve (I think Catalin did some work here?), but 150 ms doesn't\nreally qualify as \"instantaneous\".\n\n-- \nKarl Hasselström, kha@treskal.com\n      www.treskal.com/kalle\n"},{"id":"42876","messageId":"b0943d9e0705210231j75ef2e57o922f7899f4b5814b@mail.gmail.com","threadId":"8253","inReplyTo":"20070521074838.GA32510@diana.vm.bytemark.co.uk","subject":"Re: [PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current'","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2007-05-21T09:31:09Z","receivedAt":"2007-05-21T09:31:09Z","isPatch":true,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 21/05/07, Karl Hasselström <kha@treskal.com> wrote:\n> On 2007-05-20 23:22:00 +0200, Robin Rosenberg wrote:\n> > Calling stg is too slow to be be used here. I that command in my\n> > first draft for this function and people complained (see the thread\n> > named \"Bash snippet to show branch and patch in bash prompt\"). It\n> > takes ~ 0.15s on here which is very noticable, barely below my pain\n> > threshold.\n> >\n> > We'll update the prompt when and if Karl breaks this.\n>\n> Yes, I can confirm that I'm hard at work breaking this. :-) I'm trying\n> out a way to get around the performance bug Catalin found, but I\n> didn't have time to finish it yesterday.\n\nMy plan is to release a 0.13 version pretty soon but without the DAG\npatches as we might have to test them a bit more. The release after\n0.13 I'd like to be a 1.0-rc1 (including the DAG patches) unless we\nhave some other major changes pending.\n\n> But it sucks that stg starts so slowly. It has gotten better, I\n> believe (I think Catalin did some work here?), but 150 ms doesn't\n> really qualify as \"instantaneous\".\n\nI don't think we can get much slower than this. I modified stg to only\nload the modules needed for a given command but it still takes around\n150ms for a command like 'top'. I don't know any other python tricks\nto make it start faster.\n\nBTW, any of you would like to get added as a member to\ngna.org/projects/stgit (there are no advantages, only e-mail updates\nfor filed bug reports)?\n\nRegards.\n\n-- \nCatalin\n"},{"id":"42881","messageId":"20070521101540.GB32510@diana.vm.bytemark.co.uk","threadId":"8253","inReplyTo":"b0943d9e0705210231j75ef2e57o922f7899f4b5814b@mail.gmail.com","subject":"Re: [PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current'","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-21T10:15:40Z","receivedAt":"2007-05-21T10:15:40Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-21 10:31:09 +0100, Catalin Marinas wrote:\n\n> My plan is to release a 0.13 version pretty soon but without the DAG\n> patches as we might have to test them a bit more.\n\nThat's reasonable.\n\n> The release after 0.13 I'd like to be a 1.0-rc1 (including the DAG\n> patches) unless we have some other major changes pending.\n\nIt'd be great to do away with the need to \"stg init\", but that\nshouldn't really be a major change (but I haven't started looking at\nit yet). It would be nice if 1.0 had documentation that didn't have to\nmention \"stg init\".\n\n> I don't think we can get much slower than this.\n\nOh yes we can ... :-)\n\n> I modified stg to only load the modules needed for a given command\n> but it still takes around 150ms for a command like 'top'. I don't\n> know any other python tricks to make it start faster.\n\nI don't either. We might consider having plumbing written in C or\nsomething, and make sure that the plumbing can be called directly if\nthere's need, but it's going to complicate things greatly compared to\npure Python.\n\n> BTW, any of you would like to get added as a member to\n> gna.org/projects/stgit (there are no advantages, only e-mail updates\n> for filed bug reports)?\n\nFree bug reports? Sure, I'm in! (I just created a Gna! account: kha)\n\n-- \nKarl Hasselström, kha@treskal.com\n      www.treskal.com/kalle\n"},{"id":"42885","messageId":"20070521113915.GA3090@diana.vm.bytemark.co.uk","threadId":"8253","inReplyTo":"20070521101540.GB32510@diana.vm.bytemark.co.uk","subject":"Re: [PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current'","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-21T11:39:15Z","receivedAt":"2007-05-21T11:39:15Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-21 12:15:40 +0200, Karl Hasselström wrote:\n\n> We might consider having plumbing written in C or something, and\n> make sure that the plumbing can be called directly if there's need,\n> but it's going to complicate things greatly compared to pure Python.\n\nWhat I'm (foggily) envisioning here is to rewrite parts of StGIT (as\nlittle as possible) as a C library (libstgit.so?), and call the\nlibrary both from the Python code, and from a \"plumbing\" C program\n(stgit-helper?). We should not try to make the library API stable,\njust like the current git library.\n\nThere are two kinds of things we'd want to have in the library: (1)\nthings that are too slow to do in Python, and (2) things that need to\nbe available from stgit-helper in order to avoid Python's startup\ncost, such as top/applied/unapplied for the bash completion and bash\nprompt.\n\n-- \nKarl Hasselström, kha@treskal.com\n      www.treskal.com/kalle\n"},{"id":"42897","messageId":"b0943d9e0705210817n35e50a6bgb519b693984b3a4b@mail.gmail.com","threadId":"8253","inReplyTo":"20070521113915.GA3090@diana.vm.bytemark.co.uk","subject":"Re: [PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current'","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2007-05-21T15:17:22Z","receivedAt":"2007-05-21T15:17:22Z","isPatch":true,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 21/05/07, Karl Hasselström <kha@treskal.com> wrote:\n> On 2007-05-21 12:15:40 +0200, Karl Hasselström wrote:\n>\n> > We might consider having plumbing written in C or something, and\n> > make sure that the plumbing can be called directly if there's need,\n> > but it's going to complicate things greatly compared to pure Python.\n\nYes, it will complicate things. I think StGIT would have progressed at\na much slower pace if written in C :-).\n\n> What I'm (foggily) envisioning here is to rewrite parts of StGIT (as\n> little as possible) as a C library (libstgit.so?), and call the\n> library both from the Python code, and from a \"plumbing\" C program\n> (stgit-helper?). We should not try to make the library API stable,\n> just like the current git library.\n\nApart from the start-up time, I don't see other major slowdowns caused\nby Python. It would be useful to use a git library directly without\ninvoking external applications (I'm not sure what's the state of a\n\"libgit.a\" or what improvement we would get).\n\nAs for the start-up time, unless you write most of the commands in C,\nwe would still have to load Python modules. If you run stg-prof\ninstead of stg for a simple command like 'top', you can see that the\nmain function takes about 60-70ms, the rest to 150ms reported by the\nexternal 'time' is Python start-up and module loading.\n\nI had a quick try at using \"freeze.py\" to generate a binary (well, it\nincludes python bytecodes but it might save time on module look-up)\nbut it got confused by my optimisation to only load module commands\nbased on the stg arguments. Maybe we should try this first.\n\n> There are two kinds of things we'd want to have in the library: (1)\n> things that are too slow to do in Python, and (2) things that need to\n> be available from stgit-helper in order to avoid Python's startup\n> cost, such as top/applied/unapplied for the bash completion and bash\n> prompt.\n\nAs you probably guessed, I'm not really in favour of re-writing parts\nof StGIT in C, at least not in the near future, though anyone can fork\nand re-implement it :-).\n\n-- \nCatalin\n"},{"id":"42899","messageId":"20070521153952.GB6474@diana.vm.bytemark.co.uk","threadId":"8253","inReplyTo":"b0943d9e0705210817n35e50a6bgb519b693984b3a4b@mail.gmail.com","subject":"Re: [PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current'","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-21T15:39:52Z","receivedAt":"2007-05-21T15:39:52Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-21 16:17:22 +0100, Catalin Marinas wrote:\n\n> On 21/05/07, Karl Hasselström <kha@treskal.com> wrote:\n>\n> > On 2007-05-21 12:15:40 +0200, Karl Hasselström wrote:\n> >\n> > > We might consider having plumbing written in C or something, and\n> > > make sure that the plumbing can be called directly if there's\n> > > need, but it's going to complicate things greatly compared to\n> > > pure Python.\n>\n> Yes, it will complicate things. I think StGIT would have progressed at\n> a much slower pace if written in C :-).\n\nI agree. C is not a good language to write a whole application in. But\nfor the hot spots, C is a reasonable choice.\n\n> > What I'm (foggily) envisioning here is to rewrite parts of StGIT\n> > (as little as possible) as a C library (libstgit.so?), and call\n> > the library both from the Python code, and from a \"plumbing\" C\n> > program (stgit-helper?). We should not try to make the library API\n> > stable, just like the current git library.\n>\n> Apart from the start-up time, I don't see other major slowdowns\n> caused by Python.\n\nI haven't, either.\n\n> It would be useful to use a git library directly without invoking\n> external applications (I'm not sure what's the state of a \"libgit.a\"\n> or what improvement we would get).\n\nThere is no usable git library yet. But once there is, I agree we\nshould use it.\n\n> As for the start-up time, unless you write most of the commands in C,\n> we would still have to load Python modules. If you run stg-prof\n> instead of stg for a simple command like 'top', you can see that the\n> main function takes about 60-70ms, the rest to 150ms reported by the\n> external 'time' is Python start-up and module loading.\n\nMy suggestion was to have a small stand-alone C program that could do\nsome operations that need to be really fast, such as\ntop/applied/unapplied. It need not have a nice user interface since\nit's only going to be called by scripts (bash-completion and the\nlike), and it should only handle those operations that _must- avoid\nthe Python startup penalty. And for sanity reasons, it should share\ncode with stgit.\n\n> I had a quick try at using \"freeze.py\" to generate a binary (well,\n> it includes python bytecodes but it might save time on module\n> look-up) but it got confused by my optimisation to only load module\n> commands based on the stg arguments. Maybe we should try this first.\n\nI agree that we should try pure-Python optimizations first.\n\n> > There are two kinds of things we'd want to have in the library:\n> > (1) things that are too slow to do in Python, and (2) things that\n> > need to be available from stgit-helper in order to avoid Python's\n> > startup cost, such as top/applied/unapplied for the bash\n> > completion and bash prompt.\n>\n> As you probably guessed, I'm not really in favour of re-writing\n> parts of StGIT in C, at least not in the near future, though anyone\n> can fork and re-implement it :-).\n\nI wouldn't do it just for fun, either. But if it's a prerequisite to\nget good enough performance for something we really want, and all else\nhas failed, I'd be willing to argue for the introduction of a C\nlibrary and helper application.\n\n-- \nKarl Hasselström, kha@treskal.com\n      www.treskal.com/kalle\n"},{"id":"42916","messageId":"20070521185731.GS19253@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"8253","inReplyTo":"b0943d9e0705210231j75ef2e57o922f7899f4b5814b@mail.gmail.com","subject":"Re: [PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current'","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-05-21T18:57:31Z","receivedAt":"2007-05-21T18:57:31Z","isPatch":true,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Mon, May 21, 2007 at 10:31:09AM +0100, Catalin Marinas wrote:\n> BTW, any of you would like to get added as a member to\n> gna.org/projects/stgit (there are no advantages, only e-mail updates\n> for filed bug reports)?\n\nYou should not disregard the added bonus of being able to be assigned\nsome of the bugs and tasks reported there :)\n\nBest regards,\n-- \nYann.\n"},{"id":"42971","messageId":"b0943d9e0705220511u2b3ed46fg220af2cce26fef96@mail.gmail.com","threadId":"8253","inReplyTo":"20070521153952.GB6474@diana.vm.bytemark.co.uk","subject":"Re: [PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current'","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2007-05-22T12:11:13Z","receivedAt":"2007-05-22T12:11:13Z","isPatch":true,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 21/05/07, Karl Hasselström <kha@treskal.com> wrote:\n> My suggestion was to have a small stand-alone C program that could do\n> some operations that need to be really fast, such as\n> top/applied/unapplied. It need not have a nice user interface since\n> it's only going to be called by scripts (bash-completion and the\n> like), and it should only handle those operations that _must- avoid\n> the Python startup penalty. And for sanity reasons, it should share\n> code with stgit.\n\nThere is one more case to consider - people using NFS-mounted\ndirectories. The applied/unapplied commands would be even slower and\nthe language overhead be negligible.\n\nAnother workaround would be to always generate the applied/unapplied\nfiles when the stack structure changes.\n\n-- \nCatalin\n"},{"id":"42976","messageId":"20070522132927.GA12626@diana.vm.bytemark.co.uk","threadId":"8253","inReplyTo":"b0943d9e0705220511u2b3ed46fg220af2cce26fef96@mail.gmail.com","subject":"Re: [PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current'","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-05-22T13:29:27Z","receivedAt":"2007-05-22T13:29:27Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-05-22 13:11:13 +0100, Catalin Marinas wrote:\n\n> On 21/05/07, Karl Hasselström <kha@treskal.com> wrote:\n>\n> > My suggestion was to have a small stand-alone C program that could\n> > do some operations that need to be really fast, such as\n> > top/applied/unapplied. It need not have a nice user interface\n> > since it's only going to be called by scripts (bash-completion and\n> > the like), and it should only handle those operations that _must-\n> > avoid the Python startup penalty. And for sanity reasons, it\n> > should share code with stgit.\n>\n> There is one more case to consider - people using NFS-mounted\n> directories. The applied/unapplied commands would be even slower and\n> the language overhead be negligible.\n>\n> Another workaround would be to always generate the applied/unapplied\n> files when the stack structure changes.\n\nYes, we could do that. These files would only be accurate when the\nstack was last modified with StGIT and not plain git, but that might\nbe acceptable.\n\nHmm. Since the only way plain git modifies the stack is by changing\nHEAD (we assume the user doesn't manually mess with the patch refs),\nwe might also write down the value of HEAD for which the\napplied/unapplied files are valid, so that the caller could call \"stg\napplied\" if the applied file was out of date. But that's quite a\nhassle to have to reimplement every time.\n\n-- \nKarl Hasselström, kha@treskal.com\n      www.treskal.com/kalle\n"}]}