Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ifs and &&s and Plan 9's Source Code

computationallyendowed.com

Post reply on HN
Print view View original

81–90 of 150 posts

Re: Ifs and &&s and Plan 9's Source Code

#81

Post by OldSchool »

glurgh wrote: post #75
OldSchool wrote: post #61

Perhaps the compiler wasn't relied upon to provide "short circuit" boolean eval? This code will compile that way no matter if it's available in the compiler or not. Honestly for the sake of being more robust, I'd add if(a != nil) after the first test of b. if(b != nil) if(a != nil) if ...

Short circuit is guaranteed by the language standard. On top of that, plan9 comes with its own C compiler so the people who wrote this also wrote the compiler used to compile it.

I see, I just have no idea how complete the Plan 9 tools are. Working with in-house domain specific language interpreters or compilers I've twice seen unary minus support missing so I assumed anything was possible when something's not fully commercialized.

Re: Ifs and &&s and Plan 9's Source Code

#82

Post by DannyBee »

rayiner wrote: post #24
Groxx wrote: post #11

Earlier quoted context omitted.

^ this is a detail which boggles my mind. why are our debuggers still line based? they're clearly not in every respect since you can basically always 'step in'to an && sub-expression, but nothing displays progress as you step through such things, nothing lets you put a breakpoint at some sub-expression, nearly every feature of every tool is delineated by lines as if they're the important part of a program.

Because something you do relatively early in the compiler is throw away all of the structure of the source, including flattening nested expressions into a linear IR. Mapping back to line numbers in the debugger is a bit hacky to begin with, and mapping back in an even more fine-grained way would be more complex still.

Both line and column information are completely carried through the process, and put into debug info, these days.

It's not hacky, it's actually completely well structured. Even debugging info for C/C++ macros is there and done properly.

None of this is new. DWARF2 (or 3 or 4), the standard debugging format for all non-MS compilers, has been able to do this well since 1993.

Re: Ifs and &&s and Plan 9's Source Code

#83

Post by supersillyus »

jamesaguilar wrote: post #7

Good luck using an auto formatter on a code base that uses this technique.

If I'm not mistaken, Plan9 comes with a code formatter, and this idiom is common in Plan9, so it seems likely that it is supported. http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/cb/

Re: Ifs and &&s and Plan 9's Source Code

#84

Post by DannyBee »

vault_ wrote: post #52
leoh wrote: post #26

Earlier quoted context omitted.

Not all debuggers are line-based. Many of LLVM's tools give descriptive errors ("expressive diagnostics"). Here's an example of gcc versus clang (a "frontend" for LLVM): $ gcc-4.2 -fsyntax-only -Wformat format-strings.c format-strings.c:91: warning: too few arguments for format $ clang -fsyntax-only format-strings.c format-strings.c:91:13: warning: '.*' specified field precision is missing a matching 'int' argument p…

That's not a debugger though; that's a compiler. All of the debuggers I've seen are line based with the option of single stepping through assembly. Hopefully the LLDB people will be able to modernize debugging to the degree that the clang guys have modernized error messages, but that still remains to be seen.

Given that LLVM is way behind on producing good debug info compared to GCC, i don't think LLDB is going to improve as quick as one would like.

Re: Ifs and &&s and Plan 9's Source Code

#85

Post by [deleted] »

rayiner wrote: post #24
Groxx wrote: post #11

Earlier quoted context omitted.

^ this is a detail which boggles my mind. why are our debuggers still line based? they're clearly not in every respect since you can basically always 'step in'to an && sub-expression, but nothing displays progress as you step through such things, nothing lets you put a breakpoint at some sub-expression, nearly every feature of every tool is delineated by lines as if they're the important part of a program.

Because something you do relatively early in the compiler is throw away all of the structure of the source, including flattening nested expressions into a linear IR. Mapping back to line numbers in the debugger is a bit hacky to begin with, and mapping back in an even more fine-grained way would be more complex still.

[deleted]

Re: Ifs and &&s and Plan 9's Source Code

#86

Post by RBerenguel »

slg wrote: post #4

This also provides an advantage when debugging. It will become immediately obvious which condition fails when stepping through the code. That isn't always the case with a long string of &&s.

Thought the same. If I need three && in an if condition, I nest (although I add brackets, I prefer having them). It makes easier debugging, easier reading and in case of need they are a good place to put some printfs

Re: Ifs and &&s and Plan 9's Source Code

#87

Post by jlgreco »

vy8vWJlco wrote: post #79
jlgreco wrote: post #43

Earlier quoted context omitted.

This also makes individual conditions slightly easier to comment out.

And yank/cut/copy, and re-order, and type-over, and... I have developed similar habits after using line-based editors. This is very easy code to modify. (Notice the return type on a line all its own.)

Exactly. You could easily consider this to be defensive code in a similar way as always using 'break' with the last case of a switch-case is defensive.

Re: Ifs and &&s and Plan 9's Source Code

#88

Post by [deleted] »

OldSchool wrote: post #61

Perhaps the compiler wasn't relied upon to provide "short circuit" boolean eval? This code will compile that way no matter if it's available in the compiler or not. Honestly for the sake of being more robust, I'd add if(a != nil) after the first test of b. if(b != nil) if(a != nil) if ...

[deleted]

Re: Ifs and &&s and Plan 9's Source Code

#89

Post by DannyBee »

wiml wrote: post #74
rayiner wrote: post #24

Earlier quoted context omitted.

Because something you do relatively early in the compiler is throw away all of the structure of the source, including flattening nested expressions into a linear IR. Mapping back to line numbers in the debugger is a bit hacky to begin with, and mapping back in an even more fine-grained way would be more complex still.

I don't think it's any harder to carry line-and-column annotations through the compilation process than it is to carry just line annotations. In fact many compilers do. Of course your debug information gets larger, but that's not usually a problem during development. On the other hand, an optimizing compiler already makes it pretty hard to single-line-step through a program (what with reordering, CSE, and more sophis…

So let's separate out the producer and consumer.

On the consumer side, knowing where you are is actually the least hard problem in optimized debugging, compared to things like tracking variables that got split up into multiple disjoint registers, or part in register/part in memory, etc

As for where you are, the line table already will tell you that the column number changed on pc address advance, but line number did not. Thus, you know that you moved an expression, but not a line.

GDB doesn't happen to support this, and simply looks steps until line number change.

But it's not fundamentally hard from the debugger perspective.

On the producer side: When it comes to knowing where you are, you know you can't produce a 1-1 mapping, so you don't try. You can of course, properly present inlined functions as if they were function calls, and gdb will even do this. But there are times when lines or expressions were merged, and there simply is no right answer.

Re: Ifs and &&s and Plan 9's Source Code

#90

Post by encoderer »

Dylan16807 wrote: post #78
encoderer wrote: post #39

Earlier quoted context omitted.

Maybe it comes from using Python as my go-to language (and that it's my favorite language) but i personally like to avoid non-essential braces and other minutia. Yes, of course, I know the argument: a one-line bracketless "if" can set-up a future developer for failure if they need to add an item to the conditional block. And if they for some reason decide not to read the actual conditional. And if they don't test it.…

Odd, since python is all about using the best way and not variants, that you would want to have some with braces and some without braces.

Sure, being "pythonic" is about having one best way.

But you're taking it to a level for snark that really isn't warranted. I can think of at least 4 ways to iterate a list. It's about doing something the easiest/best way for the circumstance.

Post reply on HN