Forum comments in chronological order

Anonymous
Thu 4-Feb-2021 22:57

This thing is awesome! The technical details section is quite interesting as well.

Nicely done.

Anonymous
Fri 5-Feb-2021 04:27

i did not intend to report abuse

Anonymous
Thu 18-Feb-2021 18:59

The type of syntax highlighting that is helpful for understanding meaning depends on the complexity of the language. For most programming languages the syntax is highly simplified, so simply denoting different types of tokens is sufficient to help catch the majority of mistakes like unterminated strings.

For English just highlighting token types doesn't help much. You generally already know what type all the tokens are. It's the relationship between them that gets fuzzy due to the much more complex syntax.

Which is why a "syntax-highlighted" English sentence looks like:

Well, I can't inline it. So just go here:

https://media.npr.org/assets/img/2014/08/20/gregor2_custom-c8214189bda85b6ce9baafc8dc9f3143bcda6ae3-s1600-c85.jpg

Anonymous
Tue 23-Feb-2021 04:24

Hi Linus, you might find interesting this somewhat related paper in which they figure out how to use (modern) DRAM to do massively parallel operations, by exploiting the same "activating multiple rows" behaviour:

https://parallel.princeton.edu/papers/micro19-gao.pdf

There's also this paper from late 2013 (while you released SafeVSP in early 2013 - coincidence or hidden inspiration...?) where they also exploit that behaviour to do in-DRAM copying, but it's only theoretical as they didn't actually attempt it with real parts and only mention to the effect that it's "not allowed", unlike the above paper which actually tried it and discovered it already works:

https://users.ece.cmu.edu/~omutlu/pub/rowclone_micro13.pdf

I bet this effect is reproducible with all DRAM ever made, from the ones used in the C64 to the latest DDRs.

Anonymous
Sun 28-Feb-2021 22:16

Dear Mr. Linus Åkesson,

Thank you for the extremely informative article. I'm an amateur programmer and Linux newbie and trying to wrap my head around TTY as I'm exploring the capabilities of the new "iSH" iPad app which runs Alpine Linux inside an x86 emulator on iPadOS on an iPad. The Alpine Linux wikis ay that Alpine Linux can be set up to do graphics and a GUI, but I've not been able to so via the iSH app. When I try to do so, my X or Xorg or xterm programs usually either tell me that they "Can't open display"or that it "Cannot find a free VT: Not a tty". When I use the Linux tty command, it shows the active tty as /dev/pts/0 which I understand would be expected since I am in a Bash shell inside Linux typing the command. I wrote the app developer who indicated that the App isn't really set up to graphics. Setting the env $DISPLAY to the host:0.0 also does not help.

My questions for you that I'm confused about is how could the App not be able to do graphics, access the display, or find a free tty if it is able to display the text characters on the terminal? Why can't X11 use the same procedure that the Bash Linux shell uses to display text characters on my iPad to display graphics? I did notice that the same difficulty comes up when using Alpine Linux Docker containers--they seem to only natively display text characters in a terminal window. I read that one can set up such Alpine Linux Docker containers to display graphics/GUI information but to do so one has to set up the Docker container to specifically transmit such graphic information to the local computer's tty display. I'm guessing that the difficulty Alpine Linux Docker containers might have in natively displaying graphic/GUI information (as opposed to text character shell information) might be related to the same limitation I might be having in trying to get the Alpine Linux kernel in the iSH app to display graphic/GUI information on my iPad but don't understand mechanistically why.

If you could explain the difference between Linux being able to display character text information on a tty display versus being able to display graphic/GUi information on the same tty display (perhaps with some supplemental diagrams to your original article), I (and suspect others) would greatly appreciate it.

Thanks,
MIke