Hacker News: ralph

New comment by ralph in "Colorized man pages"

ralph — Fri, 19 Aug 2016 15:13:45 +0000

I find searching bash(1) just fine with less(1) and do it quite often. The groff mailing list, the main discussion point for all things troff, is slowly chipping away at adding more semantic information to man pages. The BSDs have been making progress here.

New comment by ralph in "Colorized man pages"

ralph — Fri, 19 Aug 2016 15:11:58 +0000

`info foo | less' has it produce the whole "page" as plain text, suitable for easy reading and regexp searching.

Google+ accepts and ignores parameters in URL path segments

ralph — Mon, 01 Jul 2013 11:16:42 +0000

Article URL: https://plus.google.com/115649437518703495227/posts/afc9dRGh7Sv

Comments URL: https://news.ycombinator.com/item?id=5969859

Points: 2

# Comments: 0

New comment by ralph in "Go 1.1.1 is released"

ralph — Thu, 13 Jun 2013 23:32:15 +0000

If it's not thought interesting then it won't meet the front page?

New comment by ralph in "Go 1.1.1 is released"

ralph — Thu, 13 Jun 2013 09:18:52 +0000

Dupe. https://news.ycombinator.com/item?id=5872550

New comment by ralph in "ffind: a sane replacement for command line file search"

ralph — Sun, 09 Jun 2013 16:11:04 +0000

Is this not equivalent and avoids running grep(1) once for each path?

    find -exec grep -iH ${1?} {} +

Though it still runs grep on directories.

New comment by ralph in "Facts about Wayland vs X"

ralph — Sat, 08 Jun 2013 15:44:15 +0000

OK, I've gone and read the OP's text rather than just the quoted part. It seems he's talking about combining multiple X screens into one logical coordinate space, like I expect one or more of the existing extensions do, e.g. Xinerama.

New comment by ralph in "Facts about Wayland vs X"

ralph — Sat, 08 Jun 2013 09:43:36 +0000

Coordinates in the X protocol are signed 16-bit so a screen can run from 0 to 32,767 along an edge. I agree though, the initial complaint is unclear and may be about something else.

New comment by ralph in "How Go uses Go to build itself"

ralph — Thu, 06 Jun 2013 18:07:48 +0000

Yes, C across AIX, Suns, Silicon Graphics, whatever those HP ones were, and others. Platform differences were common, bugs rare because many had been before me and they could always be worked around; I didn't have to fix a C compiler. When writing a compiler the aim is to fix the compiler.

This isn't getting us anywhere. We disagree. I value the opinion of that lot given their many decades of experience. I used to have your opinion, based on textbooks. They've made a good point, one I can see has considered thought behind it.

New comment by ralph in "How Go uses Go to build itself"

ralph — Thu, 06 Jun 2013 12:10:23 +0000

Yes, because of the stableness of the C compiler, bigger test audience, etc., compared to a new language under rapid development.

New comment by ralph in "How Go uses Go to build itself"

ralph — Thu, 06 Jun 2013 10:11:43 +0000

This is flawed AFAICS. It assumes that because 1.0 is fixed in specification that there are no bugs in the implementation. To return to my original point, these smart guys are on the record stating that's why they didn't do a self-hosting compiler; good enough for me. :-)

New comment by ralph in "How Go uses Go to build itself"

ralph — Wed, 05 Jun 2013 13:10:36 +0000

Sorry, I don't understand. You seem to be saying there's only two versions of the compiler, one written in a foreign language, e.g. C, the other in a subset, e.g. Gosub, called G-2. But then there's "whatever is the current version of the language", which suggests to me incremental improvements, e.g. the language develops as experience is gained rather than being fully planned on day one. So doesn't G-2 undergo changes to implement these? You may keep calling it G-2 but there are many (I never said thousands) of versions of it.

New comment by ralph in "How Go uses Go to build itself"

ralph — Wed, 05 Jun 2013 09:42:29 +0000

That's not how the books say to do it, and you're right, given who created Go you'd think they'd know this stuff. :-)

Many generations of the compiler are created. Let's say the compiler-in-C is worked on until it compiles subset Gosub1 which is just enough to write compiler-in-Gosub1 that duplicates compiler-in-C's behaviour. From now, compiler-in-C atrophies. G-2 features are implemented in G-1's compiler, though nothing uses them yet. The compiler's source then uses these, making it G-2 source, only compilable by a G-2-grokking compiler.

Weeks later we have a G-40 where a bug is discovered, introduced in G-20. It wasn't in the compiler-in-C so that's not useful. Choices include fixing it at `head', which can sometimes be awkward as described earlier, or fixing the initial G-20 implementation and then rolling forward all changes from there assuming the fix doesn't break code that was depending on the errant behaviour.

New comment by ralph in "How Go uses Go to build itself"

ralph — Wed, 05 Jun 2013 00:28:08 +0000

Seemingly often enough that it deterred them with Go. No, you may not be able to revert to before the bug was introduced as it may be the bug was there ever since that feature was added. As soon as it is self-hosted, the old compiler becomes quickly irrelevant, i.e. the code rapidly diverts from what it can compile.

New comment by ralph in "How Go uses Go to build itself"

ralph — Tue, 04 Jun 2013 16:26:27 +0000

The Go developers have said they deliberately didn't try and write Go in Go because they've done that with other languages, possibly Alef, I forget, and a bug can arise where the fix is obvious if it wasn't that the bug exists and would be triggered by the fix. Instead, a more awkward fix has to be figured out that doesn't trigger the bug. Of course, once the bug is fixed the original straightforward fix can be substituted but it's all unwanted hassle.

New comment by ralph in "Golang heap corruption during garbage collection"

ralph — Tue, 04 Jun 2013 16:12:36 +0000

But then the debugger can't be called ogle.

New comment by ralph in "Relative Line Numbers in Vim"

ralph — Mon, 03 Jun 2013 09:54:54 +0000

Pre-vim, one would get quite proficient at judging line distances, e.g. 11yy, through practice. Mind you, that was probably helped by text being a fixed size on a serial terminal and bigger than much text today. However, I do wonder if the article is over-promoting movement by lines. Movement commands like ), }, ]], and good old / should be readily considered as well.

New comment by ralph in "Poll: Full-time software engineers in London, what's your annual salary?"

ralph — Sat, 01 Jun 2013 18:11:00 +0000

Here's a £ sign for someone to edit in.

New comment by ralph in "A faster way to delete millions of files in a directory"

ralph — Sat, 01 Jun 2013 15:35:52 +0000

It's not that I'd use Perl for the task, just that I don't think rsync is special. Indeed, rsync has the overhead of forking a child and communicating empty/'s bareness.

New comment by ralph in "A faster way to delete millions of files in a directory"

ralph — Sat, 01 Jun 2013 10:08:50 +0000

This Perl beats rsync by quite a margin here.

    perl -e 'opendir D, "."; @f = grep {$_ ne "." && $_ ne ".."} readdir D;
        unlink(@f) == $#f + 1 or die'

It goes a bit quicker still if @f and the error handling are omitted.

The original article is comparing different things some of the time, e.g. find is having to stat(2) everything to test if it's a file.