maxbrunsfeld

12 ms·

91.
by maxbrunsfeld 10y ago
Pausing is very straightforward with bottom up algorithms like GLR. The entire state of the parse is stored in an explicit stack data structure, as opposed to implicitly in the program's call stack as with top-down algorithms. So resum
92.
by maxbrunsfeld 10y ago
I'm curious about the source of the slowness of the IDL operations. Is it specific to the DOM, or is he referring to overhead that exists for any bindings between JS and C++?
93.
by maxbrunsfeld 11y ago
This looks great. Bookmarked for when I get around to learning Rust.
94.
Rendering Improvements(blog.atom.io)
73 points by maxbrunsfeld 11y ago|12 comments
95.
by maxbrunsfeld 11y ago
> one thing that struck me is that markers can't be zero-width. Well, they can but they won't show up. I'm wondering if this is related to the technique mentioned here Thanks for bringing this up. It's not a fundament
96.
by maxbrunsfeld 11y ago
The best tool for that (and any profiling in Atom) is chromium's built-in profiler. See the flame graphs in the blog post.
97.
by maxbrunsfeld 11y ago
Packages can definitely have a significant impact on Atom's performance. You can observe all kinds of events, and binding a slow handler to certain events like text changes and cursor movements can make the editor feel sluggish. It&#
98.
by maxbrunsfeld 11y ago
Yes it does. Currently, syntax-highlighting and soft-wrap are disabled for these files. We're continuing to work on optimizations and structural improvements to the editor that will allow it to support arbitrarily large files with the
99.
by maxbrunsfeld 11y ago
There's still some major algorithmic optimization to be done regarding the time it takes to run the find-and-replace search. The optimizations discussed in this blog post were more focused on the performance of editing the buffer in
100.
by maxbrunsfeld 11y ago
> The difference seems to be that Go has a preferred way to do it: explicit case analysis and early returns. In other words, there is no way to abstract over the case analysis in Go. It sounds like you're saying this is a good thing
101.
by maxbrunsfeld 11y ago
From the left-hand side of the `=>` arrows in the `match` expression.
102.
by maxbrunsfeld 11y ago
> I really want Rust to succeed, but I think they took a wrong turn with error handling. Wow, I have exactly the opposite impression. I am so excited by how elegantly error handling is done in Rust. > Having to write all that error ha
103.
by maxbrunsfeld 11y ago
Yes.
104.
by maxbrunsfeld 11y ago
Would you mind opening an issue for this on atom/atom? There are a couple of open issues related to full-screen on OSX, but this sounds more serious than any of the existing issues.
105.
by maxbrunsfeld 11y ago
That screenshot uses the new default UI and syntax themes. Both are called `One Dark`. I think the UI theme is quite amazing; it adapts to complement whatever syntax theme you're using. See simurai's blog post: http://b
106.
A tool for generating fakes for testing in go(github.com)
1 points by maxbrunsfeld 12y ago|0 comments
107.
by maxbrunsfeld 13y ago
CTRL-h doesn't behave the same as backspace on OS-X. This makes it hard to use for me. Cool idea though.
108.
by maxbrunsfeld 13y ago
I've been editing typescript using JetBrains webstorm. It works pretty well.
109.
by maxbrunsfeld 14y ago
Another very cool take on this idea: https://github.com/nathansobo/space-pen
110.
by maxbrunsfeld 15y ago
I didn't know what to make of that comment. Dynamic this-binding is used heavily in any OO javascript code; it's not a feature that should be ignored when designing the new syntax. To me, writing 'this' as part of the parameter list for met
111.
by maxbrunsfeld 15y ago
As another former physics student, I'm excited about this too. I think my understanding of physics would benefit greatly if the various mathematical formalisms used to describe its different aspects were unified systematically. I'm starting
112.
Haskell and Syntactic Complexity(arcanesentiment.blogspot.com)
3 points by maxbrunsfeld 15y ago|0 comments