you dont need 256 codepoints so you can neatly represent an octet (whatever that is), you just need 2 bits. you can just stack as many diacritical marks you want on any glyph. either the renderer allows practically unlimited or it allows 1/none. in either case that's a vuln. what would be really earth shattering is what i was hoping this article was: a way to just embed "; rm -rf ~/" into text without it being rendered. you also definitely dont need rust for this unless you want to exclude 90% of the programmer population.
I think the Rust is more readable for bytemucking stuff than dynamic languages because the reader doesn't have to infer the byte widths, but for what it's worth the demo contains a TypeScript implementation: https://github.com/paulgb/emoji-encoder/blob/main/app/encodi...
An octet is a group of 8 bits. Today we normally use the word "byte" instead. The term is often used in older internet protocols and comes from an era where bytes were not necessarily 8 bits.
competing with what? your score doesnt vary based on others.
i came here to laugh at this thread.. no different than calculators and google both of which were misused in the same way. and then people who are "worried" about it and use that as an excuse to do it themselves. and now you know why the tech industry sucks
> competing with what? your score doesnt vary based on others.
Grading on a curve is very much a thing. Rarer in lower levels but not completely unheard of.
Even if it weren't GPA is still used for ranking students for opportunities like college or summer programs with limited slots. The effect of GPT'd homework depends on how well they perform on the tests though but some classes are predominantly take home work or at least were when I was going through school.
their slow as hell and incredibly inefficient to build graphics on top of
> but many are powered by the same graphics technologies used in video games
what does that mean? obviously they have to render text to graphics at some point
> The first trick is "overwrite, don't clear". If you clear the "screen" and then add new content, you risk seeing a blank or partially blank frame for a brief moment.
> The second trick would be to write new content in a single write to standard output.
its just luck when any of these work
> The third trick would be to use the Synchronized Output protocol;
this could work...
> With these three tricks in place you can create very smooth animation as long as you can deliver updates at regular intervals. Textual uses 60fps as a baseline. Any more than that probably isnt going to be noticeable.
no, anything above 60hz will be noticeable more smooth and less laggy. also this isnt a question about bigger=better. youll notice jank even if you run 75fps on 60hz or 60fps on 75hz, and of course with unsynchronized rendering there will be jank and other artifacts even with Xfps on Xhz.
> Now that you can have smooth animation in the terminal, the question becomes should you?
nothing you demonstrated was smooth, just better than current broken (terminal) shit. and no, because the thing terminals miss out on is being able to scroll at just a constant pixel/time rate and actually follow the mouse precisely and without lag. as you can see in the video you cant do this because the terminal cant do this period because they can only move one font width/height per step. then if we actually explore this issue well soon find out a 125hz mouse polling rate adds tons of jank, and well discover 60hz is too slow to be smooth even with perfect sync, then that you need a CRT to have legible text at such a slow framerate. your video looks like a slightly faster windows 3.0. which is good for a terminal, but bad compared to what graphics could do even 20 years ago (at 60hz), no your not scrolling at 60hz, because thats impossible in the terminal.
none of this means i want what Windows / GTK / KDE / android / ... came up with where you press a button and the program then starts slowly animating something like its (ironically) a type writer instead of just doing what i said. you lose your position in scrolling because its done wrong, the "smooth scrolling" shit in firefox or whatever is just a poor (oblivious) attempt at the solution
