|
|
Log in / Subscribe / Register

Malcolm: Usability improvements in GCC 8

Malcolm: Usability improvements in GCC 8

Posted Mar 16, 2018 14:15 UTC (Fri) by ledow (guest, #11753)
Parent article: Malcolm: Usability improvements in GCC 8

Finally some sense in a compiler output.

It was understandable back in the day for things like "Syntax error on line 3". That was enough to go on, a decent human could track the error down, and your compiler was tiny and efficient.

Nowadays? Sorry, but there's no excuse. Let's spend some of that precious time and deep tree-making analysis to actually pinpoint the problem, why it's there, and take a stab at the most likely fix (e.g. if(a = b) should suggest correction to ==, etc.)

My favourite GCC error that I've received in real life was this:

expected 'struct Player *' but argument is of type 'struct Player *'

Nope. Don't spend ages looking for the wrong space or fancy Unicode or something. It complained because one file defined struct Player one way, and another another way. And because of the way it was done, there were no compilation errors until you get this, because it only sees the wrong definition (so it doesn't warn you of a double-definition anyway). And obviously, in any IDE, when you click on the struct it takes you to the definition that you expect and you're baffled why it does that. Maybe only for a minute or two, or only if you have certain flags turned on (I think it was -Wall -Werror, but whatever), but I loved that message so much I screenshot it.

I'm still waiting for the day when the compiler / application / OS not only flags errors but YOU TELL IT what was wrong and it tries to correct in future from that. Imagine that. An application does something you don't want. You click on the little ? button in the window. You point it at the thing that's wrong (the button that isn't enabled, the field that's greyed out, the wrong size listed for a file, the inaccessible path on the filesystem, etc.) It asks you what's wrong, you select from some options and tell it what you EXPECT to have happened. And then it tells you why. "That button is disabled because this checkbox isn't ticked." "You can't press submit because the two password fields don't match".

In a way, you could make an entire programming language based on that. Start with a blank sheet. Query it. When it asks what you expect, draw a button on the screen. It now knows to draw a button. Now click the button. Nothing happens. Click the ? and point at the button. Scroll back through all the mouse moves and clicks it detected. What were you expecting on the button click? The *dropdown select* colour of this *click* window to turn *click* this colour. Now it does it.

Of course, it would be limited but I'm honestly waiting for a system that's based more on what the user wants/expects than what the designer intended. Where you say "No, you did that wrong" and then correct it.

It would make a nice basis for AI training (if you believe that'll be viable this century) but also it should be possible to say "Well, this bit of code says no, and the reason it says no is because of this condition, and the user obviously isn't aware of the condition".


to post comments

Malcolm: Usability improvements in GCC 8

Posted Mar 16, 2018 19:04 UTC (Fri) by ballombe (subscriber, #9523) [Link] (4 responses)

> In a way, you could make an entire programming language based on that. Start with a blank sheet. Query it. When it asks what you expect, draw a button on the screen. It now knows to draw a button. Now click the button. Nothing happens. Click the ? and point at the button. Scroll back through all the mouse moves and clicks it detected. What were you expecting on the button click? The *dropdown select* colour of this *click* window to turn *click* this colour. Now it does it.

Congrats, you invented smalltalk!

Malcolm: Usability improvements in GCC 8

Posted Mar 17, 2018 13:03 UTC (Sat) by orsayman (guest, #123153) [Link] (3 responses)

> Congrats, you invented smalltalk!

I was about to say the same thing ! Those smallatalkers do amazing things (like debugging Python code inside Smalltalk).

Malcolm: Usability improvements in GCC 8

Posted Mar 17, 2018 14:34 UTC (Sat) by ledow (guest, #11753) [Link] (2 responses)

Really? I don't think the below has any correlation whatsoever with my description.

exampleWithNumber: x
| y |
true & false not & (nil isNil) ifFalse: [self halt].
y := self size + super size.
#($a #a "a" 1 1.0)
do: [ :each |
Transcript show: (each class name);
show: ' '].
^x < y

Maybe we have "programmer-syndrome" again, like whoever originally did the error messages for gcc, where because it's technically possible to figure out what's going on that must be good enough?

Malcolm: Usability improvements in GCC 8

Posted Mar 18, 2018 2:59 UTC (Sun) by nivedita76 (guest, #121790) [Link]

This from the wiki page:
An example of how Smalltalk can use reflection is the mechanism for handling errors. When an object is sent a message that it does not implement, the virtual machine sends the object the doesNotUnderstand: message with a reification of the message as an argument. The message (another object, an instance of Message) contains the selector of the message and an Array of its arguments. In an interactive Smalltalk system the default implementation of doesNotUnderstand: is one that opens an error window (a Notifier) reporting the error to the user. Through this and the reflective facilities the user can examine the context in which the error occurred, redefine the offending code, and continue, all within the system, using Smalltalk-80's reflective facilities.[23][24]

Malcolm: Usability improvements in GCC 8

Posted Mar 26, 2018 5:23 UTC (Mon) by Kamilion (subscriber, #42576) [Link]

Here, this video might help.

https://www.youtube.com/watch?v=AnrlSqtpOkw&t=137s

A retrospective on what smalltalk could do in the mid 70s.

Malcolm: Usability improvements in GCC 8

Posted Mar 20, 2018 14:50 UTC (Tue) by nix (subscriber, #2304) [Link] (2 responses)

It's not just GCC that generates errors like that, of course. A month or so ago I spent some time fixing this utterly mystifying DTrace error message:

translator member pr_fname definition uses incompatible types : "char [16]" = "char [16]"

Er, yeah, right, that explains everything! The actual error was that one "char" was actually "char on a system where char == unsigned char" and the other was a signed "char" since the system was mistakenly assuming that char is always signed -- so the types were not identical, but of course the internal signedness of char is not being printed out in random error messages...

(Of course this was an error in an *implementation*. If a legitimate user got this error, it would be a sign that someone, probably me, had screwed up.)

Malcolm: Usability improvements in GCC 8

Posted Mar 20, 2018 17:19 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (1 responses)

In C, "char", "signed char", and "unsigned char" are all three distinct types. "char" may or may not be signed, but it is not 100% replaceable with the explicit variants.

See this[1] SO answer.

[1]https://stackoverflow.com/questions/75191/what-is-an-unsi...

Malcolm: Usability improvements in GCC 8

Posted Mar 21, 2018 14:31 UTC (Wed) by nix (subscriber, #2304) [Link]

Yes indeed: I kind of assumed that knowledge from the readers. This was a bug in implementation code that was erroneously assuming the identity of char and signed char, and fell over when ported to a platform in which the C char type was unsigned.

Malcolm: Usability improvements in GCC 8

Posted Mar 20, 2018 15:04 UTC (Tue) by nix (subscriber, #2304) [Link]

It would make a nice basis for AI training (if you believe that'll be viable this century) but also it should be possible to say "Well, this bit of code says no, and the reason it says no is because of this condition, and the user obviously isn't aware of the condition".
This sort of thing ("saliency detection") is pretty routine now, at least for spotting overfitting and acting as a guide to figure out why your network is going nuts. You train a network to analyze the state of the target network so it can discern what the other network considers most important in some input, then look at that. (Another way to do it is to have the saliency-detection system repeatedly perturb the input to the target system in some minor way, see if its output changes, then report the regions where perturbations caused the output to change.)


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds