Math.Round opens the browser print dialog (2019) | Hacker News Reader

Math.Round opens the browser print dialog (2019)

github.com

69 pointsdavikr25 comments

Sometime in the Swift 3 timeframe (2018? 2019?) Apple renamed all their APIs to match their new guidelines. Objective-C methods get bridged to Swift almost directly, which means you can often call functions that were designed decades ago without it looking all that different from all your other code.

Two unrelated facts about Swift are that it has "implicit self" in that inside an instance method, you can call any other instance method without qualifying the access to indicate that it's happening on the current object. Also, it has a free function, print, that is basically its equivalent to std::cout or System.out.println or console.log in other languages. It's a common debugging technique, in particular. Perhaps you can see where this is going…

When writing apps on macOS, one makes their own custom NSWindows and NSViews. One method, -print:, invokes the system print dialog by default. This, of course, got named NSWindow.print(_:)/NSView.print(_:), which promptly made any code that tried to log a view or window from a context where those were visible suddenly start trying to literally print. Kind of amusing that the literal action of "printing", which today lives on as "printing" output to the screen, ends up meeting its roots with a name overload collision.

(If you're wondering, the function was eventually renamed to NSWindow.printWindow(_:) and NSView.printView(_:) to solve this issue.)

> Apple renamed all their APIs

How did they prevent this change from causing a huge compatibility nightmare?

By not promising compatibility up-front. Swift applications were supposed to ship with their own copy of the Swift standard library up to when Swift got a stable ABI in Swift 5.

IIRC, they also provided migration scripts. Certainly their Xcode tools provided hints indicating the renaming of functions.

I used to mainly develop in C++ and implicit this was so frustrating. Nowadays it’s mostly Python and the explicit self is simply not an issue. (I also worked on Objective-C code at some point and that’s also fine.) Why any designer of a new language would think implicit self/this is a good idea is so beyond me.

It's convenient and mostly not an issue.

Gotta love the AOL-level "[happened to] me too!" comments... After maybe the 4th or 5th "me too!" comment, you're not giving any more information by adding that it happened to you too..

[1] http://www.catb.org/jargon/html/A/AOL-.html

There’s the worse comment, “I’m not seeing that behavior.” Those are especially helpful.

And then there’s the owner/company response to a trouble report: “nobody has reported this”

> There’s the worse comment, “I’m not seeing that behavior.” Those are especially helpful.

On the contrary those are helpful. It means the steps to reproduce are unclear or incomplete.

True, insofar as knowing that the problem doesn't affect everyone.

But often the key people responsible use that phrase as a shield to seemingly reject the suggestion that there is a problem.

I've experienced this so many times with ISPs over the years. I offer them a lot of details, but the most common initial (and final) response is "nobody else has reported this". Obviously the first person reporting a problem will be in this situation.

Developers aren't telepaths though. It is the reporter's responsibility to describe the problem in enough detail that anyone can reproduce it.

> But often the key people responsible use that phrase as a shield to seemingly reject the suggestion that there is a problem.

Have you ever been on the other side of this? If a single person reports that something sometimes doesn't work, they don't know under what circumstances it doesn't work or have any meaningful description on how to make it do the problematic thing, and nobody else is experiencing it - 9 times out of 10 its a problem with the reporter. Even if it isn't, the description of the problem is so vague and useless there's nothing to be done.

I think its psycohological - users don't have a lot of power and want to feel they are doing something.

In the phabricator bug tracker there is a feature i like called tokens where users can award tokens to a bug (i guess its the same as github reacting to the bug, but i like how phab did the ui better). Lets users note that it is affecting them without derailing the conversation.

And it is useful to have a rough count of how many users are affected by a bug. Especially for the harder to reproduce ones where it is unclear if investigating is worth it.

I'm sure that contributes but there's another side to the issue that drives it. Getting devs and especially commercial vendors to pay attention to the issue. It's become all to common place for vendors to abuse their bug reporting systems to minimize the impact of problems they can't or don't want to deal with like closing multiple reports as duplicates while ignoring the primary one. How often have people had to come on HN and post their issue here to pressure a vendor to address it? Unfortunately the social commentary dogpile has been one of the few effective methods lately.

Vendors don't owe it to you to fix your bugs unless you have some sort of support agreement that says otherwise.

Its not abusive to close duplicate reports of a bug that is not currently prioritized. It would be impossible to prioritize every single bug.

That's like saying Ford doesn't owe it to you to fix a defective vehicle because they don't feel it's a priority.

If its not safety critical and you don't have a warranty then they don't

Even worse IMO are all the screenshots of print dialogues.. not screen recordings showing the behaviour, just screenshots after an alleged reproduction... Not that there's any particular reason to disbelieve them - it just doesn't add anything to the claim, there's no particular reason to disbelieve them absent a screenshot of a print dialogue either. It's like 'my computer will not boot [photo of a computer powered off]'.

Oh my gosh I also noticed that!

Same here on Firefox

Discussed at the time:

Math.Round opens the browser print dialog - https://news.ycombinator.com/item?id=20228089 - June 2019 (61 comments)

I had the same bug recently, as I was switching between Python and JS and instinctively wrote "print(...)" in JS.

Took me a few seconds to find the issue after almost going crazy about why the freakin' print dialog was opening constantly.

This seems to be both .NET and in the browser, so my first thought was "is this a Blazor (1) issue?" i.e. for .NET targeting WASM in the browser.

It could be, Blazor dates back to 2018 and this bug is from 2019, this is the kind of thing that happens in the early days.

The parent repo name and readme is more informative as to the scope, and confirms that somewhat: https://github.com/dotnet/try

> Welcome to the Try .NET repo. ... Online, powered by Blazor, Users can run and edit code all in the browser.

It's an amusing bug, but not a current or widespread issue.

1) https://en.wikipedia.org/wiki/Blazor

TLDR: There was a error handler that used print(error) instead of console.log(error).

And window.print() opens up the print dialog, and the window scope is the top one.

Has me curious if it was a scope thing where there was, at one time, a locally scoped print()...or just the usually-writes-python guy was trying to debug something and forgot to remove that.

The comments are something else; the discussions actually reached even global warming.

Reply on news.ycombinator.com