HN user

j4_james

123 karma
Posts0
Comments74
View on HN
No posts found.

Agreed. The only thing that VS-15 is supposed to do is give the emoji a "text presentation", which the spec suggests as "black & white". And every example they show of a text presentation is exactly the same width as the emoji presentation.

Changing a character's width from wide to narrow after it has already been output is fraught with problems for a terminal. Imagine trying to write a "narrow" text presentation emoji in the bottom right corner of the screen. You'd think it should fit, but the emoji is received before the VS-15 selector, and that doesn't fit, so the terminal is forced to wrap the text, triggering a scroll of the entire page. By the time the VS-15 arrives, there's no way to undo all of that.

And for another example, try using IRM (insert replace mode) to insert a text presentation emoji in the middle of some existing text. If it was really narrow, you'd expect it to insert enough space for just one character, but it actually inserts two spaces, only occupying one of them, and then leaving an unexpected gap. And the more of these "narrow" characters you insert, the bigger the gap becomes.

VS-16 changing a text presentation character from narrow to wide doesn't share these problems. And that behaviour is supported by the spec text, which says that emoji should generally have a square aspect ratio. And at one time the East Asian Width spec specifically mentioned VS-16 making narrow characters wide (but said nothing about VS-15 making wide characters narrow).

This was also an option on many "Glass TTY" terminals - it was called the margin bell - and even some modern terminal emulators still have that option. The exact semantics vary, but it's usually triggered when entering content around 8 characters from the right margin.

"ANSI" is what people call it when they are working from paltry and incomplete samizdat doco of how this stuff works

People just use "ANSI" as a shorthand for ANSI X3.64-1979. And that was the standard that DEC used for their VT100+ range of terminals, which in turn became the de facto standard from which most modern terminal emulators are derived. If you read the DEC documentation, you'll find many references to "ANSI standard", "ANSI controls", "ANSI colors", etc. I don't think this is because they were ignorant of the subject matter, considering that they were members of the committee that produced that standard.

And ECMA-48 is essentially just the European equivalent of ANSI X3.64, and was developed in parallel. But obviously an American company like DEC or Microsoft would more likely be working from the American version of the standard rather than the European one.

FYI, there are a few terminals that can set the window size in pixels (with `CSI 4 t`). And it's also worth mentioning that there were already terminal emulators back in the 1980s that supported in-band resize notifications (lookup `VTEEWR` - Enable Window Event Reports).

The author mentions problems with flow control, but I'm fairly certain I got that working in MAME. If I remember correctly, you need to enable XON/XOFF in the VT102 configuration (it's one of the bits you can toggle on the SET-UP B page), and also enable it in MAME's Machine Configuration menu.

Also make sure your modem settings in MAME match the settings configured on the VT102. I have them both set to 19200 baud 8N1. I've just done a quick test now, and I can definitely make it through tests 1 and 2 in vttest without the output getting corrupted.

I should also mention that I've got the RS232 device set to null_modem (which is hooked up to a socat instance via MAME's bitbanger feature), rather than the pty configuration that they're using. I'm not sure if that could make a difference to the way the flow control works.

They have a working VT240 which supports the Sixel, ReGIS, and Tektronix graphics protocols. They also have partially working VK100, which is a bit like a VT100 with some graphics support (I think just ReGIS). They don't have a working VT125 as far as I know.

Smooth scrolling on the VT100 was 6 lines per second, but on later terminals you could adjust the speed to a certain degree, as much as 18 lines per second on the level 5 terminals. It's possible you'd still hate it even at that speed, but I wouldn't right it off completely just because you disliked the VT100 implementation.

On later DEC terminals you could also set left and right margins (lookup DECSLRM). They didn't support smooth scrolling when those margins were enabled, but I don't see why a modern terminal emulator couldn't handle that.

Interestingly, when you create a file name from the WSL shell using reserved Windows characters, those characters will get mapped to unicode codepoints from the private use area when viewed in Windows. So for example a colon (\u003A) will show up in Windows as \uF03A.

This means you can create a filename in Windows using the character \uF03A, and that character will show up in the WSL shell as a colon. You can even do the same thing with "regular" characters, e.g. using \uF061 instead of "a", and produce a filename that appears to be ASCII in the WSL shell, but is not actually accessible.

In case anyone cares, this is an option in Visual Studio too. Under "Text Editor > All Languages > Scroll Bars", you have the option to "Use map mode for vertical scroll bar". Can also be configured on a per-language basis.

Well if you're Russian (or one of the many other nationalities that uses a Cyrillic character set), then that's still not going to help you. If you visit аррІе.com (all Cyrillic characters) you wouldn't get any warning that it wasn't apple.com (all Latin characters). It's a rather euro-centric solution to the problem.

The thing is, why should an English speaking person get a warning when they visit a Cyrillic url, but a Russian speaking person doesn't get a warning when visiting a url with Latin characters? Why is apple.com assumed to be legitimate and аррІе.com is considered the fraud?

In fact I'm almost sure that browsers originally used to disable IDNs using some kind of scheme that relied on language preferences back when they first started being used. I suspect they eventually abandoned that approach for this very reason. It only seems like a good idea if you're English speaking (or at least some other Latin-based language).

If you're willing to turn off JavaScript, you can have all the same content, but with silky smooth performance.

On the "downside", though, you miss out on the social media sharing buttons, and auto-loading of the next article when you get to the bottom of the page.

Actually I think it's only 56K in pounds - 73K is the dollar value. It's confusing because the order of those values is swapped between the two maps. On the first map they have $73K (£56K), i.e. the dollar value is first. On the second map (adjusted for cost of living) they have £84K ($104K), i.e. the pound value is first.

Yeah. As someone who lives on navigable river, it's not uncommon for me to see boats flying signal flags for variety of reasons. There's not a wide range of usage here mind you - it's typically tugs and workboats flying the RY signal (you should proceed at slow speed when passing me), survey vessels flying IR (I am engaged in submarine survey work) or cruise ships flying the H signal (I have a pilot on board).

Naval vessels are kind of an interesting case though. They also fly the H flag when they have a pilot on board, but when they do so it's in combination with the answering pennant at the top of the hoist. I believe this is a standard practice when communicating with merchant marine vessels to indicate that the signal is based on the ICS rules and not the naval signal book which can mean something completely different. Naval vessels also often display their call sign using these signal flags when arriving and departing from port.

Minor bug report: I was testing a page that was using SVG Stacks[1], where multiple icons are encapsulated in a single SVG image and the individual icons are referenced via fragment identifiers. This caused the WebBS calculator to count the SVG image multiple times (once for each fragment reference), resulting in a score that was significantly worse than it should have been.

[1] http://simurai.com/blog/2012/04/02/svg-stacks

These rules are designed to prevent you mixing codepoints from different languages, so you couldn't register something that looked like gmail but with the English 'a' replaced with a Cyrillic 'a'. However, if the name you're trying to emulate can be reproduced entirely within another language's character set, you can still impersonate an existing domain.

For example, it may surprise you to know that http://www.еа.com and http://www.ea.com are two different websites, despite the URLs appearing identical. Edge at least renders the IDN version in its punycode form, but in Firefox and Chrome the URLs are indistinguishable. It's quite possible that's a result of my messing with the IDN settings in the past, though - I'm curious what others see for those links.

One technique I remember being used in DOS apps from many years ago was that the code would be encrypted in such a way that the next instruction to be executed would only be decrypted immediately before it was run. This was achieved by setting up the single step interrupt as the decrypter, and running the code in single step mode.

The fact that the code was encrypted meant the debugger couldn't disassemble it in any meaningful way, and also made it impossible to set a breakpoint (since the breakpoint would just end up being "decrypted" into some other opcode that would inevitably crash). The debugger also couldn't step through the code, because taking over the single step interrupt would prevent the decrypter from running, so you'd just be stepping through garbage.

The way I worked around this was by writing a debugger that could hook the single step interrupt in such a way that it still forwarded the interrupt onto the previous hook. I still couldn't set breakpoints, but I could step through the code, watching it decode itself as it proceeded.

This is a result of the fact that your projects most likely don't have dates assigned to them (not even sure that was an option in the old system) so they all end up crammed at the top of the timeline. Once you fill in an approximate launch date for each project (or whatever you feel is most appropriate), the timeline should start to look a little more sensible.

That said, I'm still not a big fan of the new look. I also prefer the apps section at the end rather than mixed in with my employment history.

HTML Kong 10 years ago

Bear in mind that the whole point of this exercise was to produce a game without using any JavaScript whatsoever. It was intended to be more of a technology demonstration than a playable game. As the article pointed out, you can find a much more accurate and playable implementation of the game on the Pica Pic website. http://pica-pic.com/

HTML Kong 10 years ago

Author here. It was done with a Python script that parses the CSS into a stream of characters annotated with metadata saying whether the character is allowed to be escaped and whether whitespace can be inserted before or after it. It's then just a matter of breaking up the stream where whitespace is permitted and using the escaping to pad segments to the exact size required.

Definitely not recommended in production. Other than the obvious inefficiency, it was only supported in Chrome fairly recently (even though the CSS escaping rules have remained largely unchanged for 20 years or so). In this case, though, the game itself depended on recent bug fixes in Chrome, so there wasn't much point in worrying about compatibility with older versions.

The Joel Test is sort of incorporated into Stack Overflow Jobs (previously Careers) in that a company has the option to include the results of their Joel Test when posting an ad on the site. However, there's no obvious way (at least that I could see) for a candidate to search for jobs that meet specific criteria in the test.

Also, the exact wording for the office part of the test is "Do programmers have quiet working conditions?" This usually means that working conditions might possibly be quiet if nobody else happened to be in the office at the same time as you. While many claim quiet working conditions, I've never seen one that actually provided private offices.

This is anecdotal of course, and just based on looking at photographs they've included on their website or Stack Overflow page, but every job I've viewed recently appears to have an open plan office. In some of the photos you even see people standing around having impromptu meetings in the middle of a group of desks where others are trying to work.

Remember this is just the companies that are actually claiming to provide programmers with quiet working conditions. I can't imagine what the noisy ones are like.