This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-01-07
Channels
- # admin-announcements (69)
- # alda (8)
- # beginners (6)
- # boot (182)
- # cider (10)
- # cljs-dev (24)
- # cljsrn (17)
- # clojars (70)
- # clojure (142)
- # clojure-brasil (5)
- # clojure-czech (1)
- # clojure-poland (4)
- # clojure-russia (96)
- # clojurescript (115)
- # community-development (37)
- # component (6)
- # cursive (11)
- # datomic (32)
- # events (4)
- # funcool (6)
- # hoplon (17)
- # ldnclj (10)
- # lein-figwheel (24)
- # mount (12)
- # om (141)
- # onyx (7)
- # parinfer (48)
- # re-frame (24)
- # reagent (31)
@cfleming: yeah, I tried going down that road when performance was an issue
I eventually removed it for simplicity when performance became much better
tried adding it back in again, but tracking state between was not as simple as I expected so I’ve temporarily written it off for now
here are my thoughts of why I ditched it again: https://github.com/shaunlebron/parinfer/issues/75#issuecomment-167716479
thanks @darwin! will read this tonight
I think in this case the parsing is not going to be the complexity, probably, since the parsing here is fairly trivial
I think as long as your restart points are top-level forms (i.e. I’m going to process from the start of this top level form to the end of this other one) I’d hope it should be pretty similar to processing a whole file.
@shaunlebron: I haven’t looked at the code sorry - could this currently be run over top level forms (assuming you can identify them) independently, i.e. with a fresh copy of the state for each one?
@cfleming: what you are describing with top-level forms is exactly how atom-parinfer works
I call it the "parent expression hack" and it seems to be fine; have had zero complaints about it in the wild
@chrisoakman: Oh, good to know
it does use the single-js-file version of parinfer; I just updated to v1.4.0 in fact
but on any change in the buffer I just "look up" and "look down" for the nearest parent expression
correct
https://github.com/oakmac/atom-parinfer/blob/master/src-cljs/atom_parinfer/core.cljs#L191-L221
and I use those simple regex to determine it
there are cases where this will break of course, but no one has complained so far
are you thinking you'll need a Java implementation for Cursive?
And I’ll probably also migrate it to use some of the Cursive infrastructure (I have a fast lexer, for example)
I was able to port parinfer.js to parinfer.py in a single evening, and I don't know Python
just as an FYI in terms of ease of porting
I've considered playing around with writing a Java implementation if you think it might be useful; I have never written Java before
99% of the time people will be in indent mode
Shaun hates this hack, but oh well 😉
this also might be useful: https://github.com/oakmac/sublime-text-parinfer/issues/23
parinfer.py uses the same tests as parinfer.js
nice way to know if you've done the port correctly
@darwin: thanks I read through part of his braindump on parsing
I think he is essentially caching the state of the parser at each line
I had problems with that
there wasn’t a problem for simple edits which produced valid input for Parinfer
but multiple edits have to be batched if the function is debounced
and they must be batched further across edits producing bad input
I hope to just get some thoughts on this problem after documenting what I have so far