Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
sjolsen
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
41 ms
·
151.
▲
by
sjolsen
12y ago
It isn't. It's a part of the type "ResultT1."
152.
▲
by
sjolsen
12y ago
Speaking specifically about C++, lambdas are good for this, if not quite syntactically ideal: AwesomenessT largerFunction(Foo1 foo1, Foo2 foo2) { ResultT1 result1 = [&] { Bar bar = barFromFoo1(foo1);
153.
▲
by
sjolsen
12y ago
> tray icons Some end up being minuscule (I'm looking at a ~1px-wide ownCloud icon right now) and the location is definitely non-obvious. I didn't even know Gnome 3 had a system tray for about a month, until I accidentally pu
154.
▲
by
sjolsen
12y ago
> Settings → Keyboard → Shortcuts, the ‘Typing’ section Thank you! > a non-obvious spot No kidding; the Compose key being an actual key, it really belongs with the rest of the keyboard mapping settings. I guess since they removed that
155.
▲
by
sjolsen
12y ago
A lot of this reflects something I've noticed about development in the Gnome world: they decide exactly how interfaces should be used, and lock that in. As time progresses, they drop more and more customizability out of their products,
156.
▲
by
sjolsen
12y ago
Assembly code would fail to demonstrate the point. The graphs are meant to demonstrate that, temporally speaking, the basic actions being performed by the abstract machine are partially ordered. A consequence of these actions being temporal
157.
▲
by
sjolsen
12y ago
An algorithm not listed is that using "derivatives:" http://matt.might.net/articles/parsing-with-derivatives/ . I don't know if it can be implemented efficiently enough to displace simpler (less powe
158.
▲
by
sjolsen
12y ago
>what if I want to assign the pointer dereference to `tmp` to improve readability I personally find code like that harder to follow. The first version is clearer than the second (and you forgot to take the address of foo->bar->baz[
159.
▲
by
sjolsen
12y ago
>I usually use objdump -d objfile.o to look at assembly output You can also compile to assembly with -S. I think it's clearer that way.
160.
▲
by
sjolsen
12y ago
That's basic dataflow analysis. Unless one of those pointers is to a volatile object, I'd be very surprised if any halfway serious compiler produced more than one access to foo->bar->baz[i] unless "meep" has
161.
▲
by
sjolsen
12y ago
>if you believe for a nanosecond that we need source-level compatibility to get the benefits of inlining You do. Yes, there's LTO, but to do it effectively relies on storing source code or information derived from it in the intermed
162.
▲
by
sjolsen
12y ago
>re-write the prototype >ABI compatibility In other words, conversion overhead and indirection, respectively. There is no substitute for having an inline definition available at the point of use.
163.
▲
by
sjolsen
12y ago
> You aren't aware just how many security-critical C programs invoke potentially undefined behaviour today. It doesn't take much experience with C to appreciate something of the magnitude of difficulty of keeping a million line
164.
▲
by
sjolsen
12y ago
>Is this program "almost certainly wrong" No, that one's a consequence of C's insane type system. The solution here isn't to change the semantics of signed integer arithmetic. The solution is to change integer pr
165.
▲
by
sjolsen
12y ago
>The problem they're trying to address is that C compliers take advantage of undefined behavior for optimizations That's not a problem. That's a good thing. >Such optimizations can cause very strange, unintuitive behavi
166.
▲
by
sjolsen
12y ago
>This is not a feature for a programmer to use to make their work easier It makes it possible to use C definitions directly and inline with no conversion overhead or indirection. When your work is writing fast code, the ability to levera
167.
▲
by
sjolsen
12y ago
I don't really see what's to be accomplished by most of the points of this. A program that invokes undefined behaviour isn't just invalid; it's almost certainly _wrong_. Shifting common mistakes from undefined behaviour
168.
▲
by
sjolsen
12y ago
Vim does the orthogonality thing better, I'll admit, but Emacs' separate chords tend to follow useful patterns, too. For example, moving forward a character is C-f, moving forward a word is M-f, and moving a balanced expression fo
169.
▲
by
sjolsen
12y ago
At least it's a "home-row pinky" with Emacs' Ctrl, too. :) Personally, though, I don't find the worst strain comes from the placement of Ctrl. The worst comes from the awful staggered layout of keyboards that serves
170.
▲
by
sjolsen
12y ago
Programs that "do one thing well" are utterly useless unless you can compose them. Emacs is a tool that composes programs that do one thing well, like Bash or X. Emacs, as has been said time and again, is not a text editor. It is,
171.
▲
by
sjolsen
12y ago
Because it means you don't have to jump in and out of different modes. The biggest thing that kept me from using vim was _constantly_ typing in normal mode and trying to issue commands in insert mode. Is constantly hitting the Escape k
172.
▲
by
sjolsen
12y ago
The "chance" here is the probability of the second crash will happen given the first crash happens. Because the first crash is given, its probability should be taken to be 1. There's also whether the probability of a crash oc
173.
▲
by
sjolsen
12y ago
I haven't found that Emacs has made it harder to use other editors. It's just made me realize how horrible it's always been to use them, hammering away at the arrow keys, using the mouse way more often than should be necessar
174.
▲
by
sjolsen
12y ago
I find it very strange that you've thrown LOOP in there. It may not be as sexy as canned functional algorithms or simple recursion, but for complex algorithms, it's an absolute joy to use. I couldn't count the number of times
175.
▲
by
sjolsen
12y ago
CLOS is verbose if all you're doing is encapsulating some state. If, on the other hand, you plan on doing anything remotely interesting, it's very succinct and expressive. Trying to emulate the functionality of CLOS' multiple
176.
▲
by
sjolsen
12y ago
>no manual management Of memory. Any other resource, you've basically got C with UNWIND-PROTECT and a cheap Schrödingerian knock-off of destructors.
177.
▲
by
sjolsen
12y ago
The problem with TCO in C++ is destructors; unless you're using a very limited set of types, they all but guarantee you're going to have code to execute after returning from what would otherwise be a tail call.
178.
▲
by
sjolsen
13y ago
Emacs Lisp is interpreted (or byte-interpreted), and (GNU) Emacs is written almost exclusively in it, so startup can be dog-slow. Once it's up and running, though, I've always found it pretty snappy.