ltratt

10 ms·

91.
Preventing an optimising compiler from removing or reordering code(theunixzoo.co.uk)
3 points by ltratt 5y ago|0 comments
92.
The Evolution of a Research Paper(tratt.net)
2 points by ltratt 6y ago|0 comments
93.
by ltratt 6y ago
[Warning: over-serious response coming.] There's a big "cattle grid" sign a little way before it, so I don't think that's a realistic worry. As an aside, that road is long, but a dead end: it leads up to a beauty sp
94.
by ltratt 6y ago
I'm not an IDE person myself (I'm a neovim person), but I'd love to see someone integrate such an approach into an IDE! The algorithm is free available and the implementation in Rust (grmtools) the same. If you wanted to reus
95.
by ltratt 6y ago
> Is this a separate thing that would be integrated into an IDE or would it make more sense as part of the compiler? As things stand it's most easily used in a batch setting (e.g. a compiler). I don't think it would take much,
96.
by ltratt 6y ago
Alas, most parser generators don't have very good error recovery (and some have such terrible error recovery that I think it's worse than not having any!). It turns out that this isn't inevitable: there's been a long str
97.
by ltratt 6y ago
I also have a C920: it's fairly infamous for the "Smurf effect", where it tends to make everything look unnaturally blue. Setting the "white_balance_temperature" setting manually improves this situation substantiall
98.
by ltratt 6y ago
PHP is an... interesting... language to implement. The de facto standard PHP interpreters have become very fast over time. It's been a long time since I measured HHVM, but it always used to have very good warm-up time. I always felt it
99.
by ltratt 6y ago
> My understanding is that Wagner's thesis is mostly concerned with "history-sensitive" error recovery in an IDE: using earlier syntax trees as an additional input to the error recovery process in order to better understan
100.
by ltratt 6y ago
> For error recovery, do any parsers have a notion of which tokens are more likely to be wrong? lrpar has a %avoid_insert declaration which allows users to say "these token types are better avoided if there are other equivalently go
101.
by ltratt 6y ago
tree-sitter is excellent stuff! It's heavily inspired by Tim Wagner's PhD thesis (original site seems to be down, but https://web.archive.org/web/20150919164029/https://www.cs.be... works). IMH
102.
by ltratt 6y ago
I think we are in agreement that skipping over large chunks of input is rarely a good idea. In Section 7 ("Using error recovery in practice") we show how you can make fine-grained decisions about what to do when recovery has happe
103.
by ltratt 6y ago
Co-author here. If you want to quickly play with this on the command-line with your favourite Yacc grammar, a simple way is to use nimbleparse https://crates.io/crates/nimbleparse ('cargo install nimbleparse'
104.
by ltratt 7y ago
Community wisdom has long held that good error recovery is impossible for automatically generated parsers and I unquestioningly accepted that wisdom for years. When I was building a Yacc system in Rust, I eventually investigated further, an
105.
by ltratt 7y ago
No.
106.
by ltratt 7y ago
I don't pretend to have a total picture of all the possibilities, and there's quite a bit of not-always-explainable variation in what I do know, but I think it would be fair to say that people in this field are quite some way from
107.
by ltratt 7y ago
I lead a PL/VMs/compilers research group and the number of organisations interested in hiring people in this area keeps growing and growing. Now, that's not to say that there are ever going to be hundreds of thousands people
108.
by ltratt 7y ago
I completely agree: the poor quality of error reporting in parsing tools is a significant reason not to use them. When I started looking into this a couple of years back, what surprised me is how much work there's been in this spread o
109.
by ltratt 7y ago
History suggests that, for a good approximation of the truth, the resources put into a language implementation (and, in particular, into JIT compiling VMs) strongly correlate with its performance. So V8 and HotSpot, for example, both have g
110.
by ltratt 7y ago
> Pure compiler jobs are far and wide between. In an absolute sense, this is true. There are never likely to be hundreds of thousands of compiler jobs. In a relative sense, this isn't true. I run a PL research group with a heavy foc
111.
by ltratt 7y ago
The problem is more-or-less as bad for a normal distribution as it is for a skewed distribution (I'd have said the distribution from my examples is right skewed, not that it makes any difference to my argument): the minimum gives you n
112.
by ltratt 7y ago
In my experience people think/hope that the minimum tells them the performance of their program when all noise is removed. However, this is based on the assumption that programs have a single performance point which, as the Stabilizer
113.
by ltratt 7y ago
Benchmarking is hard -- I've spent far more time investigating it then I ever wanted to. Much of the advice in this article matches the advice I give when people are foolish enough to ask me (though CPU pinning can have very odd result
114.
by ltratt 8y ago
> They correctly point out that error handling is by far the biggest one, and usually ends up being the biggest part of a parser for a language, full of crufts and strange mixtures of semantics and syntax. Add to this that you frequently
115.
by ltratt 8y ago
My experience is different. I've converted two or three grammars from recursive descent to LR recently. In each case, the recursive descent authors have made surprising mistakes, resolving ambiguities in ways that violate the intended
116.
by ltratt 8y ago
The hard time limit on UK PhDs is a recent-ish thing, which started coming in around 2010ish from memory (as is usual with such things, there was a fairly long phase-in, which messes with my memory). Broadly speaking, anyone who started in
117.
by ltratt 8y ago
LALRPOP is an LR parser, which is a very different formalism to PEG: it's easy to write a grammar in either that's difficult/impossible to express in the other. If you'll permit the immodesty, another Rust parser is lrpa
118.
by ltratt 8y ago
> The problem with yacc/bison-style LALR parser generators is that you end up with an LALR parser. Which works great on syntactically correct code, but trying to get a reasonable error message out of one is about as much fun as repe
119.
by ltratt 8y ago
The best place to start with Krun is its GitHub page https://github.com/softdevteam/krun/
120.
by ltratt 8y ago
In general, yes, you're reading the timings right, but there's a couple of factors to consider. First, the JIT compiler has often done most of its work during the first in-process iteration, so the plots are not generally followin

More ›