31–40 of 64 posts
Nice! svn support would be useful (ignore .svn directories) and the -r option is easy to remember, but perhaps not so much in line with the already messy standard Unix options (-r or -R for recursive operation). Note that specifically for Go source code, there is "go fix -r" for syntax/context-aware code replacement (see "godoc fix").
Earlier quoted context omitted.
Well you see... It's in Python, which breaks the deal for me (I despise slow startup). But interactive mode sounds interesting, that's something I'll consider implementing.
By slow startup do you mean 0.01s of wall time? This sounds more like a prejudice than a decision with a strong technical basis.
Also it was written when I had HDD (not SSD) and codebase was on an encrypted image. It made enormous difference to me.
find ~/my/docs/ -type f -name '*.txt' -exec sed -i.bak 's/inheritance/composition/g' {} + This will search all files ending in `.txt` and will exec `sed 's/inheritance/composition/g'` on it. Sed modifies files in-place and saves a backup file with .bak extension (-i.bak) and is called the minimum necessary times (-exec +). My best advice to someone using the command line is to learn `find` + `xargs` or, even better,…
Compare with "gr what-is-it -r here-you-go". I do not have to remember all that argument hell.
# bash
# find/replace
function fr {
local pattern=$1
local replacement=$2
local program
if [[ -z "$replacement" ]]
then
program="grep $pattern"
else
program="sed -i s/$pattern/$replacement/g"
fi
while read line
do
$program "$line"
done
}
# usage
find . | fr find-this
find . | fr replace-this with-thatOkay, so what I learnt from this: 1. You've imported droundy/goopt, wsxiaoys/terminal really easily. The first provides option-parsing, and the second provides helpers for emitting ANSI escape codes. 2. Practically everything is overloaded. You can == to strcmp(), + to concatenate strings. 3. path/filepath gives you some nice goodies for path manipulation. But you have to deal with the fallouts of making naive assump…
"proudly declares that it will not use any modern advances to compiler technology"
Where? I've read most of the available documentation, blog-posts etc. and have yet to come across a statement even vaguely resembling this.
"what the final program looks like is secondary concern"
Have you read about "go fmt"? The entire idea of it is to format the code to a standard. You don't need to use it, but it's recommended and, frankly, makes every other language without a similar feature seem like "what the final program looks like is secondary concern".
You're welcome to your opinion, but I think you'd best do some more research before making such statements without references.
Earlier quoted context omitted.
Should be fixed, can you download new version please?
Working! Do you use colors? They don't work the same in DOS, I believe. I'm seeing some escape sequences. ←[0;32;49mRS\terms.tex ←[0m←[1;39;49m←[0;33;49m25:←[0m ←[0;39;43mOEM←[0m & \\ \hline
Edit: argh, outputting colors on windows means making system calls. Which means cgo and good-bye cross-compiling. I'll probably just strip all colors...
Earlier quoted context omitted.
By slow startup do you mean 0.01s of wall time? This sounds more like a prejudice than a decision with a strong technical basis.
By slow startup I mean that 0.1s is the fastest small Python program using optparse, os, sys, re will start up on my system (i7 2.0, ssd). Search and replace tool will be slower. I constantly get 0.02s-0.3s results from 'gr' on my small-to-medium repositories (up to ~80k sloc). 'ack' takes more than a second usually. Also it was written when I had HDD (not SSD) and codebase was on an encrypted image. It made enormous…
Earlier quoted context omitted.
By slow startup I mean that 0.1s is the fastest small Python program using optparse, os, sys, re will start up on my system (i7 2.0, ssd). Search and replace tool will be slower. I constantly get 0.02s-0.3s results from 'gr' on my small-to-medium repositories (up to ~80k sloc). 'ack' takes more than a second usually. Also it was written when I had HDD (not SSD) and codebase was on an encrypted image. It made enormous…
btw, here is ag, which also looks .xignore files: https://github.com/ggreer/the_silver_searcher
Earlier quoted context omitted.
Compare with "gr what-is-it -r here-you-go". I do not have to remember all that argument hell.
Well, one can write an one-line shell alias (or script) instead of reinventing the wheel by rewriting the whole thing anew in Go. (Which is certainly good as learning experience for Go, but the end result is easier to achieve with the shell)
Earlier quoted context omitted.
Working! Do you use colors? They don't work the same in DOS, I believe. I'm seeing some escape sequences. ←[0;32;49mRS\terms.tex ←[0m←[1;39;49m←[0;33;49m25:←[0m ←[0;39;43mOEM←[0m & \\ \hline
Eh, it's not very easy to fix that unfortunately. I opened an issue and will try to work on this a bit, but then in a meanwhile... Maybe I can strip colors for outputting things on windows. Edit: argh, outputting colors on windows means making system calls. Which means cgo and good-bye cross-compiling. I'll probably just strip all colors...
Okay, so what I learnt from this: 1. You've imported droundy/goopt, wsxiaoys/terminal really easily. The first provides option-parsing, and the second provides helpers for emitting ANSI escape codes. 2. Practically everything is overloaded. You can == to strcmp(), + to concatenate strings. 3. path/filepath gives you some nice goodies for path manipulation. But you have to deal with the fallouts of making naive assump…
You are right on target. Go was designed to be boring[1][2]. Programming language should not be about tricks and traps. It's a tool. Tools are not built for beauty. They are built for functionality.
[1]http://talks.golang.org/2012/splash.article [2]http://aeronotix.pl/blog/go-is-boring
In [1](2.Introudction) even the inventors agree that Go can be boring to some people. Guess what, It's boring by design.