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

“It is never a compiler error”

blog.plover.com

Post reply on HN
Print view View original

141–150 of 280 posts

Re: “It is never a compiler error”

#141

Post by eridius »

davidbanham wrote: post #85
eridius wrote: post #72

Earlier quoted context omitted.

This comment has me rather confused. iOS updates webkit at the same time that macOS does; namely, when releasing a major OS update. And they both use the same webkit too. It should not be possible for a webkit bug to be fixed in macOS but still be unfixed in iOS after a major version update (and since you say "wkwebview came" this means there was a major version update).

The OSX app wasn't using Safari's webkit. node-webkit bundles it's own copy of webkit. wkwebview quite possibly brought a major version update, but it sure didn't include the patch we needed. Whether that was because Apple works from a fork that didn't include that patch or the major version was still older than the version we needed, I don't know. There was just no way to get that kind of information out of them.

Could node-webkit have been using a fork? Even if Apple is using a fork internally, surely they must sync up with the public WebKit project periodically, and especially when releasing new major OS versions.

Re: “It is never a compiler error”

#142

Post by bzbarsky »

mottomotto wrote: post #9
keithnoizu wrote: post #6

You gotta through a lot of those sort of expectations out of the windows when working with js. . . imho

It is silly to kick JavaScript in this example because the bug* is in the library of a custom JavaScript interpreter not a common runtime. * https://github.com/code-dot-org/JS-Interpreter/pull/23

While true, the use of sort() to sort an array of numbers in JS is ... complicated. It works for the single-digit-number case, but if you can have multi-digit numbers you better remember to pass a comparator function to get numeric sorting, because JS sort() defaults to lexicographic sort. So it will sort 10 before 2 by default.

Re: “It is never a compiler error”

#143

Post by amichal »

bitwize wrote: post #130

I came across a bug in the JDK/JRE 1.0.1 relating to GridBagLayouts. Sometimes they would just ignore the directives the programmer specified and lay things out any damn place they liked. I only reported it after checking and rechecking and rechecking that I had use the GridBagLayout API exactly according to the documentation. It was fixed in Java 1.0.3.

GridBagLayout was the worst back then. It almost got banned in my office and we had several views with gross manual implementations of it because whatever we wanted to do triggered insanity and writing the few constraints see wanted to work procedurally was way easier

Re: “It is never a compiler error”

#144

Post by harry8 »

openasocket wrote: post #135
harry8 wrote: post #132

Earlier quoted context omitted.

So I made the case with evidence that it doesn't always perform fewer comparisons and it it doesn't always perform fewer swaps. While it probably does, depending on implementation details use more memory. Do feel free to actually make your case with evidence, that I would be interested in reading. What is it with this thread and "nyer, you're wrong" responses? It's not helpful, not clever, not useful and not pleasant…

> While it probably does, depending on implementation details use more memory Have you actually looked at the insertion sort algorithm? It doesn't allocate any additional memory. Neither does bubble sort or selection sort. Knuth does some analysis of Bubble Sort in Volume 3 of the Art of Computer Programming, which proves bubble sort performs more comparisons and more swap operations than insertion sort. To quote the…

1,2,3,4,6,5,7

6 comparisons, 1 swap with bubble and it stops. I make it 7 memory reads and 2 memory writes.

Insertion and selection sorts are going to run in half that time? I'd really like to see that! I think Knuth might be talking about a general case of any data rather than the topic being discussed here, but no, I haven't read Knuth on bubble sort so I can't be sure. I may do so now so thank you for the pointer. Arguments from authority really can be informative and useful despite their other shortcomings.

Re: “It is never a compiler error”

#145

Post by hossbeast »

empath75 wrote: post #28
cperciva wrote: post #18

Sadly, I've lost count of how many compiler bugs I've tripped over through the years. Often it's compiler crashes -- those are usually easy to get fixed, especially when (as tends to be the case with LLVM) they are caused by assertions failing -- but I've also tripped over compiler hangs (there's a variable in the tarsnap code with an utterly bogus volatile specifier in order to avoid the problematic optimization on…

If you’re the kind of programmer who is likely to find compiler errors, you probably know who you are. For 99% of programmers, the chances that you have discovered one is small.

Nothing magical about writing a compiler. The humans that make them introduce bugs, like with all software.

Re: “It is never a compiler error”

#146

Post by saagarjha »

goialoq wrote: post #36
pjungwir wrote: post #35

Back in 2010 I wanted to try out Scala. I fired up the REPL and did this: scala> 1+2 res0: Int = 12 Here is a blog post I wrote about it at the time: https://illuminatedcomputing.com/posts/2010/11/no-luck-tryin... I was running under Cygwin and the issue was something about the Java-based readline library. I filed a ticket (linked in my blog post but the link is broken now), but the maintainers' response was somethin…

What's old is new again: https://www.google.com/search?q=ios+1+2+3

This isn't related…

Re: “It is never a compiler error”

#147

Post by jandrese »

kod wrote: post #97

Funny that he mentions that any bug in perl's if statement would be caught within a year. I had a project that lost $150,000+ because of a bug in perl's sprintf (but not printf, mind you). https://rt.perl.org/Public/Bug/Display.html?id=82418 Yep, that ticket was open for well over a year.

We just had the article on what a nightmare Unix Locale is.

Re: “It is never a compiler error”

#148

Post by [deleted] »

throwaway613834 wrote: post #46
cperciva wrote: post #18

Sadly, I've lost count of how many compiler bugs I've tripped over through the years. Often it's compiler crashes -- those are usually easy to get fixed, especially when (as tends to be the case with LLVM) they are caused by assertions failing -- but I've also tripped over compiler hangs (there's a variable in the tarsnap code with an utterly bogus volatile specifier in order to avoid the problematic optimization on…

To be fair, I've also lost count of the number of times my compiler has compiled things correctly. ;)

[deleted]

Re: “It is never a compiler error”

#149

Post by FullyFunctional »

I still remember my First Time. As a very novice coder (it was in the 1980s so I was young) I was using Microsoft C 3.0 (I think) and couldn't believe my program didn't work. It took understanding the assembly to discover that it was a compiler bug. It shook me to the core; before I had never even imagined that something like this could be wrong.

I later did find bugs in GCC (version ~ 1.37), but since it's pretty robust these days, notably the regression suite is a lot better than it used to be.

Re: “It is never a compiler error”

#150

Post by jandrese »

jontro wrote: post #59
dclowd9901 wrote: post #58

I don't understand the env in which this happened, because cracking open my console, I get > [5, 4, 5, 1].sort().join('') > "1455"

They are using a sandboxed javascript interpreter. https://github.com/code-dot-org/JS-Interpreter See the pull request here https://github.com/code-dot-org/JS-Interpreter/pull/23

Basically, the chance that it is a compiler bug is proportional to the inverse of the number of people using it. You probably didn't find a bug in gcc. It's definitely possible that you found a bug in some bespoke javascript interpreter that few people have ever even heard of.
Post reply on HN