Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I fixed a bug in Atom

davidvgalbraith.com

Post reply on HN
Print view View original

111–120 of 189 posts

Re: How I fixed a bug in Atom

#111

Post by nly »

anotheryou wrote: post #59
Lazare wrote: post #45

Earlier quoted context omitted.

Sometimes I feel like the difference between a junior, intermediate, and senior developers is that the junior hasn't yet figured out how to use regexps, the intermediate dev has, and the senior dev has figured out not to. I kid, but...really. The number of times I've seen people burnt by non-trivial regexps in production code is absurd. "Oh, I need to mangle this CSV that's in the wrong format"? Sure, write a one-off…

out of curiosity: what would you use for the URL validation? (but i get this is difficult: https://gist.github.com/dperini/729294 )

Well, it's clear to see why people are lead astray. In this case, RFC 3986, which defines what a URI actually is, itself actually proposes a regex[0]. It even claims, and I quote, 'the "first-match-wins" algorithm is identical to the "greedy" disambiguation method used by POSIX regular expressions'. Of course, it doesn't actually validate anything... it just performs rudimentary field extraction. Trying to do anything beyond that with regex is madness.

The ABNF grammar is fairly simple though and, I think, free of ambiguities. I've had luck converting it straight in to PEG form. It's not a trivial or wholly useful endeavour though, and, if you do so, remember to check the errata. For HTTP you'll also have to add in the changes from RFC 7230[1].

Oh, and of course, none of this validates DNS names, their labels, etc. for length, the "LDH rule", or the public suffix list[2], or IP addresses to check whether they have publicly routable prefixes.

Bottom line is, if you want to validate a URL, the best thing to do, much like e-mail, is to just try and GET it.

[0] https://tools.ietf.org/html/rfc3986#appendix-B

[1] https://tools.ietf.org/html/rfc7230#section-2.7.1

[2] https://publicsuffix.org/

Re: How I fixed a bug in Atom

#113

Post by jdmichal »

jeffbr13 wrote: post #71

Isn't arbitrarily-long nesting or matching any sort of palindrome, where you count up and down, the classic case of something you should never do with a regex, because they're finite automata? People don't build parsers because of masochism, but because regular expressions are provably insufficient to capture things like nesting. You need to go at least one level up on the Chomsky hierarchy[1] to pushdown automata fo…

I found this on the ground. Did you drop it?

[1] https://en.wikipedia.org/wiki/Chomsky_hierarchy#The_hierarch...

Re: How I fixed a bug in Atom

#114

Post by nacs »

Klathmon wrote: post #74
lucaspiller wrote: post #6

I haven't worked on Atom or Electron apps (although it's on my todo list), but does the Chromium debugger not work inside them?

Yes it does, and that was my biggest annoyance with this article. The chrome debugger with breakpoints, profilers, and a whole slew of other goodies is great for this sort of debugging. Yeah, sometimes i need to avoid it because turning it on can actually slow the code down significantly, but the profiler would have been perfect to see where the time was spent here with just a few clicks.

> that was my biggest annoyance with this article

Perhaps a core contributor or someone who regularly works on the code-base would have approached it with the full suite of debugging tools available as you mention.

However, I get the impression that the author of this article is not one of those and simply wanted to crack open his editor to fix this one problem he saw (and happened to learn more about Atom, Coffeescript and regexps along the way).

Being upset over a great open-source contribution because they used "non-ideal" methods to arrive at a solution is just silly.

Re: How I fixed a bug in Atom

#116

Post by hvis »

masklinn wrote: post #83
mbrock wrote: post #81

Earlier quoted context omitted.

I've never used a language mode that worked properly in all cases. That's why I've stopped using them, aside from very clever and extraordinarily useful ones like paredit. It terrifies me to think about how these language modes contain regexps for matching regexp syntax. Of course those are wrong.

> I've never used a language mode that worked properly in all cases. You need a full parser for that to happen, most mode authors don't bother[0]. JS2-mode ( https://github.com/mooz/js2-mode/ ) does that (or attempts to). Most syntactic colorisers are souped-up tokenisers, not actual parsers. It suffices in 99% of cases, but breaks badly elsewhere. [0] it would help if more languages made fast parsing machinery exter…

I'm fairly sure that Emacs's go-mode, which doesn't use a full-blown parser, won't make the mistake of treating a paren inside a string as if it were outside either. Or if it did, that would be easy to fix.

Emacs has a generic lightweight parsing facility that can tell you if you're inside a string, or a comment, or how to skip over a string, or a pair of matching parens/braces/brackets, and so on.

Re: How I fixed a bug in Atom

#117

Post by Tyr42 »

Grrr, that's not a Regular expression at all. I think you'd be better off looping over the string and counting the number of ( and )s in a loop, guaranteed linear time.

I wish people would stop abusing regular expressions.

Re: How I fixed a bug in Atom

#118

Post by ngoldbaum »

pilif wrote: post #110

In general, when you are working on a problem and you think "let me use a regex for that" and then you come up with ^\s*[^\s()}]+(? [^()]*\((?:\g |[^()]*)\)[^()]*)*[^()]*\)[,]?$ to solve your problem, then you have IMHO come across a problem which you should not be solving using regular expressions. Case in point is counting and balancing parentheses which is very easily done using a single loop over the string in qu…

The issue seems to be that Atom uses regular expressions as part of the internal API it uses to separate Atom core from add-on modules.

Re: How I fixed a bug in Atom

#119

Post by Klathmon »

nacs wrote: post #114
Klathmon wrote: post #74

Earlier quoted context omitted.

Yes it does, and that was my biggest annoyance with this article. The chrome debugger with breakpoints, profilers, and a whole slew of other goodies is great for this sort of debugging. Yeah, sometimes i need to avoid it because turning it on can actually slow the code down significantly, but the profiler would have been perfect to see where the time was spent here with just a few clicks.

> that was my biggest annoyance with this article Perhaps a core contributor or someone who regularly works on the code-base would have approached it with the full suite of debugging tools available as you mention. However, I get the impression that the author of this article is not one of those and simply wanted to crack open his editor to fix this one problem he saw (and happened to learn more about Atom, Coffeescr…

I probably could have worded it differently, but I'm not upset about it, it just makes me sad that people might not know that these tools exist!

I often use the same kind of thing for debugging (console.log('got here')) because it's sometimes too much work to leave the code to just get an understanding of if something is hit or not.

When i started reading the article i was really hoping he would use the profiling tools. I just feel sad that they are being overlooked a lot of the time, and this is a textbook perfect use case for it!

Re: How I fixed a bug in Atom

#120

Post by hvis »

mbrock wrote: post #86
masklinn wrote: post #83

Earlier quoted context omitted.

> I've never used a language mode that worked properly in all cases. You need a full parser for that to happen, most mode authors don't bother[0]. JS2-mode ( https://github.com/mooz/js2-mode/ ) does that (or attempts to). Most syntactic colorisers are souped-up tokenisers, not actual parsers. It suffices in 99% of cases, but breaks badly elsewhere. [0] it would help if more languages made fast parsing machinery exter…

The issue tracker for js2-mode illustrates that such a parsing approach is no guarantee of real-world accuracy either. https://github.com/mooz/js2-mode/issues The goal just shifts from having a semi-accurate regexp tokenizer, to having the language mode's complex parser match the complex parser of the language it targets—which will pretty much never happen, unless the language is exquisitely simple, like maybe restri…

js2-mode supports ES6 fairly accurately. But of course, that's not enough, people keep asking for new things: JavaScript mixed with HTML, Facebook Flow support, JSX, new ES7 (still unstable) syntax extensions, and so on.

It would be easier with a more stable language. I.e. not JavaScript, which is still going through growing pains.

Even so, "25 Open, 204 Closed" seems pretty good to me.

Post reply on HN