Fork me on GitHub
#parinfer
<
2016-01-07
>
shaunlebron00:01:40

@cfleming: yeah, I tried going down that road when performance was an issue

shaunlebron00:01:32

I eventually removed it for simplicity when performance became much better

shaunlebron00:01:27

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

shaunlebron00:01:07

thanks @darwin! will read this tonight

cfleming01:01:29

I think in this case the parsing is not going to be the complexity, probably, since the parsing here is fairly trivial

cfleming01:01:47

And top-level forms are totally self-contained.

cfleming01:01:39

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.

cfleming01:01:30

@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?

chrisoakman02:01:55

@cfleming: what you are describing with top-level forms is exactly how atom-parinfer works

chrisoakman02:01:24

I call it the "parent expression hack" and it seems to be fine; have had zero complaints about it in the wild

cfleming02:01:43

So that doesn’t use the single-js-file implementation?

chrisoakman02:01:24

it does use the single-js-file version of parinfer; I just updated to v1.4.0 in fact

cfleming02:01:43

Ok, so where does the hack come in?

chrisoakman02:01:45

but on any change in the buffer I just "look up" and "look down" for the nearest parent expression

cfleming02:01:07

So you just run the standard parinfer on a subset of the buffer?

chrisoakman02:01:46

and I use those simple regex to determine it

chrisoakman02:01:05

there are cases where this will break of course, but no one has complained so far

cfleming02:01:26

Ok, thanks. I’ll take a look and think about it a bit

chrisoakman02:01:45

are you thinking you'll need a Java implementation for Cursive?

cfleming02:01:13

Yeah, I’ll probably port the JS version to Kotlin

cfleming02:01:43

And I’ll probably also migrate it to use some of the Cursive infrastructure (I have a fast lexer, for example)

cfleming02:01:54

Although for a first version I’ll just try a straight port.

chrisoakman02:01:09

I was able to port parinfer.js to parinfer.py in a single evening, and I don't know Python

chrisoakman02:01:15

just as an FYI in terms of ease of porting

cfleming02:01:25

Yeah, it looked fairly straightforward, thanks

cfleming02:01:47

So do you apply the hack in both modes?

chrisoakman02:01:52

I've considered playing around with writing a Java implementation if you think it might be useful; I have never written Java before

chrisoakman02:01:06

99% of the time people will be in indent mode

chrisoakman02:01:19

Shaun hates this hack, but oh well 😉

cfleming02:01:29

I’ll OSS my Kotlin version when it’s done

chrisoakman02:01:09

parinfer.py uses the same tests as parinfer.js

chrisoakman02:01:17

nice way to know if you've done the port correctly

shaunlebron06:01:23

@darwin: thanks I read through part of his braindump on parsing

shaunlebron06:01:49

I think he is essentially caching the state of the parser at each line

shaunlebron06:01:12

I had problems with that

shaunlebron06:01:19

there wasn’t a problem for simple edits which produced valid input for Parinfer

shaunlebron06:01:14

but multiple edits have to be batched if the function is debounced

shaunlebron06:01:02

and they must be batched further across edits producing bad input

shaunlebron06:01:33

I hope to just get some thoughts on this problem after documenting what I have so far