The site has MathML (pMML) representations that can be downloaded.
HN user
kevinb7
I wonder if this project, at least VCL compiler part of it, could've benefited from the use of a parser generator. I understand going slow, but using a parser generator would've allowed for faster development of VCL freeing up time to add more features so it isn't so hard to write for.
I believe that `strictFunctionTypes` only applies to callbacks. TypeScript is okay with the following code even with that option turned on:
class Animal {}
class Cat extends Animal { meow() {} }
class Dog extends Animal { woof() {} }
function foo(animals: Animal[]) {
animals.push(new Dog)
}
const cats: Cat[] = [new Cat];
foo(cats);
https://www.typescriptlang.org/play/#code/MYGwhgzhAECCB2BLAt...This really depends on what you care about. Flow is much better at ensuring type safety in your code while TypeScript has some pretty glaring holes in this respect. In particular, TypeScript allows covariant assignment and param passing which makes it really easy to write unsafe code.
The questions themselves don't have to be visible, just a list of who's next when asking a question or making a comment.
KaTeX strives to match LaTeX's behavior so it may actual be an issue with the screen readability of LaTeX. We're currently discussing ways to improve this in https://github.com/KaTeX/KaTeX/issues/1848. If you're seeing other issues please file a bug report.
My limited understanding of MathJax is that it uses the browser to measure glyphs. KaTeX on the other hand includes metrics for many of its glyphs. Where things get a little tricky is i18n. There are many languages which our current fonts don't cover and thus we have no metrics for them (we make some educated guess about some unicode ranges). It would be really nice if browsers implemented a Font Metrics API, unfortunately efforts to do so appear stalled at the moment.
I've tended to view JIRA as "the worst of all project tracking tools, except for all the other ones"
I've seen heard this opinion a number of times and I don't believe it's true. TargetProcess is a better project tracking tool. It has a deeper hierarchy for organizing work. It has the concept of teams built-in and allows you to view work across multiple teams and/or projects. It also provides a way to do roadmaps built-in. Everything is included and everything is designed to work well together.
As for the specific criticism about not being able to get a high-level and low-level view in one tool, I think the reason why JIRA does poorly at the high-level view is that it has a very shallow hierarchy of work entities. It has epics => user stories => sub tasks. While projects can also be used to organize work, JIRA unfortunately binds the concept of sprints which is more of a team thing to projects. Thus it's difficult for one team to work on multiple projects or multiple teams to work on a single project.
TargetProcess on the other hand has a separate entities for teams and sprints which allows projects to be used for organizing work. It also has an additional level in the work hierarchy providing the following levels: project => epic => feature => user story => task. This deep hierarchy allows you to group work into larger groups allowing you to see both the high-level and the low-level.
I think part of BuckleScript's speed may come from the source language, OCaml, being easier to parse. There may also be fewer passes necessary to transform OCaml to JavaScript.
Does anyone know the actual spec for this binary AST can be found? In particular I'm curious about the format of each node type.
While SVG can do a lot, there are certain things that it isn't optimized for. In particular animating lots of shapes simultaneously. The animation of the globe exploding into a bunch of triangles from the slides is a good (bad?) example of this. Also, there can also be inconsistencies is in the rendering of SVGs between browsers.
Nice work. The drawing recognition feature seemed to work well. One little thing that could be improve is enforcing a minimum font size so that deeply nested fractions don't become unreadably small.
I had experimental WebGL 2 support turned on. Turning it off, fixed the problem.
There's a lot of compile to JS languages. It'd be interesting to see how many frontend devs are migrating to these languages for at least some of their projects.
After briefly testing on Mac OS:
- Chrome ~60fps
- Firefox ~25fps + fans spinning up
- Safari (hangs on loading screen)
Many of the WebGL demos I try in Safari just don't work, but the demo doesn't provide any kind of error message other than in the console. I have two wishes:
- Apple would get their act together with WebGL support
- demos would handle WebGL errors more gracefully
The shared memory and atomics proposal was approved as part of the ES2017 spec. https://github.com/tc39/ecmascript_sharedmem
I wish I could see what people are tooting about without having to create an account.
Typr.js doesn't seem to have a way to write out fonts after editing them. In what way is it more versatile?
Is there a way to batch requests? I'd like to be able to get/set more than one value at a time. It'd also be nice to be able to get a list of all my keys just in case I forget.
It looks like injected H2O2 gets recycled in the kat-mco and kat-pco reactions.
It looks hack.chat is using KaTeX under the hood. We recently added support for environments, but haven't implemented {align} yet. If anyone's interest in helping please see https://github.com/Khan/KaTeX/issues/61.
The example was adapted from internal documentation as an example of how templating works with our i18n component. There's still lots I have to learn about i18n. "familyName" and "givenName" would be more general, but there might still be some edges cases that doesn't cover.