marvy

Okay nice. IRC finally makes sense. Seems kind of like Discord. Sounds pretty nice actually.

Okay, so the magic ingredient is that variables that are marked "stable" are treated specially. Nice!

Never tried Slack, so that comparison doesn't help too much :)

But I think I'm getting the idea now. It's a similar idea to a typical instant messenger, except that since the protocol is standard, you have federation that actually works, much like someone who uses gmail can email someone else who uses yahoo.

Plus you have the concept of a channel, which seems to have no direct analog in a typical instant messenger, but seems to be essentially a persistent chatroom that doesn't vanish even if nobody is in the channel at the moment.

Is that about right?

If I understand the persistence stuff correctly, programs don't do explicit I/O but instead just run forever and thus use normal variables and data structures to store state.

This sounds very convenient until one fine day you decide add a new feature, so you need to change your code, but the new code has different variables and there may not be any sensible way to "port" the data.

Here's a question I've vaguely wondered but never mustered the effort to actually look up: how does IRC work? Like, if two people want to talk to each other over IRC, do they need to be connected to the same same IRC server at the same time?

If so, does that mean that IRC is basically like instant messaging along the lines of AOL Instant Messanger, or Google chat? Or is there something that makes IRC very different?

Can you still comment if you get all the quiz questions wrong?

I assume that mods have "local" powers in specific sub-reddits and admins have global sitewide powers?

> It grew out of the MaximeVM project at Sun labs.

I think you mean MaxineVM :)

Thanks! I think that answers my question. Since kernel threads will likely have 64KB stacks or even more, this is still a huge win, even for 32-bit code I guess.

I don't see why you need to wait for that. You already know the memory usage for 64-bit, and you implied elsewhere in this thread that memory usage is the key metric that makes these things cheaper than kernel threads. So you should be able to give an order of magnitude guesstimate even if no 32-bit port is in the works yet. Or no?

32-bit means you have at most 4 gigs of address space to play with; pron implied that lower memory usage is the key savings of fibers vs threads, so I assume a 32-bit JVM will hit a memory limit a lot sooner.

How many parked "fibers" do you think a 32-bit JVM might be able to handle once loom is ready for prime time? A thousand? A million? Somewhere in between?

good point

I'm guessing no one is crazy enough to consider line numbers part of the public API. And yet... I could imagine myself writing code like this if I were desperate enough, even though I would know perfectly well that my code would probably break the never next time I upgrade.

I didn't watch it either, but...

Does your language have exceptions? Do the exceptions support stack traces? Do those stack traces have line numbers? Well then...

    // old code: version 1.2.3
    if(problem1) throw new Exception();
    if(problem2) throw new Exception();

Meanwhile, we have client code that catches the exception and then inspects the line number to see whether it was caused by problem1 or by problem2.

(You may say that this is crazy and no one would do such a thing. Maybe so. But this at least proves that it's theoretically possible. Also, you'd be surprised at what some people will do.)

Anyway, we upgrade to the new code:

    // new code: version 1.2.4
    // Helpful comment here; no other changes.
    if(problem1) throw new Exception();
    if(problem2) throw new Exception();

And of course this comment messes up all the line numbers, at which point we can have anything from misleading error messages to system meltdown, depending on what the client code used the line number for.

How about just "fed"?

It would have been under "Theoretical Computer Science" but that section is a stub because it actually got broken out into its own article.

fair enough but is this really the least destructive action you could take?

But no one is proposing to break anything in this discussion, right?

Python has a long-standing rule that you can't nest statements inside expressions. In my opinion, this is a good rule for a whitespace-sensitive language. (This is also why lambdas can only be a single expression.)

Thus, making match an expression would imply that each case must also be an expression, which would seriously restrict when you can use match.

(Lambdas already have that problem, but there it's not so bad because you can always use a named function. In this case, you would have to fall back to if/else chains.)

> awful for the users, but are required by law

I am really curious what sort of law does this. (Though maybe I'm better off not knowing...?)

It would imply that our brains are using currently-unknown physics, since all current theories are computable.

re: PeerJ: I missed that, nice!

re: semantics vs visual layout of math... Wikipedia says OpenMath is a thing, but... that only solves half the problem. Once you have a format that encodes what you want, someone has to actually it.

Like, if some writes x^{-1} and f^{-1}, it's hard for a computer to figure out that the first one means "the number you get when you divide 1 by x", whereas the second one means "the function you get when you compute the inverse of f".

And if the author can't be bothered to slow down and say which is which, then the reader will have to guess.

re: HTML to arxiv: not ready for prime time, if you actually follow that link.

re: kerning: TeX's advantage here is not fundamental, I think. Just need a good font, as far as I know. (Actually that's not far; I know almost nothing here.)

re: layout: CSS is finally getting good at this from what I hear.

re: talk: looks familiar; maybe I should re-watch it.

So basically, give up on LaTeX to PDF as the primary workflow. Either convert LaTeX to semantic HTML instead of to PDF (probably doable for simple cases... \emph to <em>, \section to <h2>, \begin{tabular) to <table>, and so on), or better yet just author HTML without going through LaTeX at all. If needed, convert the semantic HTML to PDF as well, for printing or whatever, and then the PDF might end up sane.

Fine, fair enough. If fixing TeX is hopeless, then so be it. I assumed it just needed a few small tweaks, maybe combined with slightly cleverer PDF viewers. Guess I was wrong.

But then what should people use for math? I suppose there's MathJax, which seems to have put some thought into accessibility.

There's still a problem though. I can't help but notice that the journal you linked to is a biology journal. In some math/CS circles which are TeX's "home turf", TeX is far more entrenched to the point where I'm not sure such things even exist. For instance, arxiv sort of supports HTML, but not really:

https://arxiv.org/help/submit_html

So there I guess step 1 is to make HTML a viable option.

I just tried in Chrome; at least for page 2 it actually did a bit better than my browser: it actually managed to preserve the line breaks! (I don't have Safari installed.)

(Also, if you look closely, the summation signs are not gone, they are replaced by the letter P. Which is not helpful I admit.)

Do you think there's any place here for education/advocacy? For instance, everyone who makes web pages knows to provide alt text for images.

If there was a standard package that everyone knew they had to include or else it breaks everything from ctrl-F to copy/paste to screen readers, presumably people would use it, right?

I'm less interested in speculating what would have been if troff had "won", (though it is indeed fun to speculate), and more interested in how to fix the mess we're in now, so that 10 years in the future, blind people have better choices than OCR.

(Though OCR is still an improvement over the best option in the 1980s I bet. Though I wasn't around so just guessing.)

> Subcaption works perfectly for that

I'm not saying it doesn't work. I'm saying that if your needs are simple enough, you can get away without it.

I meant they might be so closely related that you want them share the same caption and figure number and everything.

No need to go on, that's already more than I bargained for, thank you so much for taking the time to respond :)

I suspect we're using different PDF viewers; I'm using the one that comes with my browser.

The results are somewhat less disastrous than you describe, but still bad. (I'm seeing maybe half the problems you mentioned.) I'm a bit curious which viewer you're using.

I can describe what happens when I copy/paste the stuff you mentioned on pages 2/8/etc., and if you're interested I will, but if you're not interested let me ask a slightly different question:

Rather than try to get the screen reader to make sense of the final PDF, would it be easier to just download the original page source from arxiv and let the screen reader deal with that?

Just tried copying across a line break on page 9, seems to work:

Here the potential function is, to say the least, not very simple.

Okay, nice, but maybe overkill, unless you want to refer to them separately within the main text?