Re: Is this patch allowed to get in? (Re: file_peek() minimum delay set to 1 millisecond)
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote: *) Tried out git for this. git diff and blame are fast and works nicely, but is there some gui tool to do this kind of thing even more conveniently? I tried to use git-gui blame but couldn't make it go past the latest change. What is the repository URL? I'd like to try this a little myself. git clone git://git.cuci.nl/pike to get started, the repository trails pikefarm by an hour or so at most. -- Sincerely, Stephen R. van den Berg. Even if man could understand women, he still wouldn't believe it.
Re: Is this patch allowed to get in? (Re: file_peek() minimum delay set to 1 millisecond)
Martin Stjernholm, Roxen IS @ Pike developers forum wrote: *) Tried out git for this. git diff and blame are fast and works nicely, but is there some gui tool to do this kind of thing even more conveniently? I tried to use git-gui blame but couldn't make it go past the latest change. Personally I have used gitk a lot, but not specifically for blame/annotation traversal, maybe it supports it though. Sorry, can't offer more specific pointers here currently. -- Sincerely, Stephen R. van den Berg. Even if man could understand women, he still wouldn't believe it.
Re: Is this patch allowed to get in? (Re: file_peek() minimum delay set to 1 millisecond)
git clone git://git.cuci.nl/pike Ok, that seems to give me 7.7. How do I get for example nt-tools or 7.0? How do I get bin/rsqld.pike from 2004-04-24? How do I use log to find that src/modules/_math was originally called src/modules/math?
Re: Is this patch allowed to get in? (Re: file_peek() minimum delay set to 1 millisecond)
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote: git clone git://git.cuci.nl/pike Ok, that seems to give me 7.7. It actually gives you more, you just don't see it yet. How do I get for example nt-tools or 7.0? git branch git branch -r shows you the landscape you have access to. Either access the branches directly with e.g.: git log origin/7.7 git checkout origin/7.7 or preferably create local version for them: git branch origin/7.7 7.7 # copy remote branch to local git fetch origin 7.7:7.7# sync local branch with remote repository git branch origin/7.0 7.0 git fetch origin 7.0:7.0 git branch origin/nt-tools nt-tools git fetch origin nt-tools:nt-tools How do I get bin/rsqld.pike from 2004-04-24? For starters try: git blame lib/modules/Tools.pmod/Standalone.pmod/rsqld.pike You'll notice commit hash-ids in the leftmost column and original filenames in which those lines were contained back then. E.g. to show the file at a particular point in time in the past try: git show 559221f8:bin/rsqld.pike How do I use log to find that src/modules/_math was originally called src/modules/math? Try: git blame src/modules/_math/math.c -- Sincerely, Stephen R. van den Berg. Even if man could understand women, he still wouldn't believe it.
Re: Is this patch allowed to get in? (Re: file_peek() minimum delay set to 1 millisecond)
How do I use log to find that src/modules/_math was originally called src/modules/math? Try: git blame src/modules/_math/math.c Well, ok, I guess I underspecified the question. Yes, you can see from this output that the file has at some point had this name (but you can't know that it's the _original_ name, it might have had another name before that). What I mean was, how can I find the actual rename operation, which should contain the time of the rename, the old pathname and the new pathname. (The blame trick would not have worked if all the lines had (eventually) changed after the rename.)
Re: Is this patch allowed to get in? (Re: file_peek() minimum delay set to 1 millisecond)
Stephen R. van den Berg wrote: This is the patch in question, it is simple, reduces latency *a lot* (and improves pgsql.pike performance by a factor of 2 or so; I could imagine the boost is similar in other I/O-type of applications): I have to correct myself. Apparently my refactoring of the pgsql driver made the difference less. I.e. without the patch there is an 80% chance of being 22% slower, and a 20% chance of having roughly the same performance. With or without the patch, the pgsql driver still beats the old postgres driver by a landslide. -- Sincerely, Stephen R. van den Berg. There are 10 types of people in the world. Those who understand binary and those who do not.
