Update nex.go

[marsjupiter1]

No description provided.

[purpleidea]

The formatting fixes look okay, but these should be in a separate commit please.
As for the big removal, some explanation about why you're doing this and why it makes sense would be helpful please.

[marsjupiter1]

File: fxtest
Build ID: 9f70f84ca9321f175a032e02eb9a0e39679560e2
Type: cpu
Time: Oct 14, 2019 at 8:14am (UTC)
Duration: 19.83mins, Total samples = 1190.23s ( 100%)
Showing nodes accounting for 1158.07s, 97.30% of 1190.23s total
Dropped 410 nodes (cum <= 5.95s)
flat flat% sum% cum cum%
551.10s 46.30% 46.30% 958.91s 80.57% runtime.selectgo /usr/local/go/src/runtime/select.go
139.68s 11.74% 58.04% 139.68s 11.74% runtime.lock /usr/local/go/src/runtime/lock_futex.go
132.83s 11.16% 69.20% 132.83s 11.16% runtime.unlock /usr/local/go/src/runtime/lock_futex.go
65.20s 5.48% 74.68% 204.83s 17.21% runtime.selunlock /usr/local/go/src/runtime/select.go
48.80s 4.10% 78.78% 48.80s 4.10% runtime.selparkcommit /usr/local/go/src/runtime/select.go
46.24s 3.88% 82.66% 54.58s 4.59% runtime.sellock /usr/local/go/src/runtime/select.go
31.66s 2.66% 85.32% 38.14s 3.20% runtime.selectsend /usr/local/go/src/runtime/select.go
28.69s 2.41% 87.73% 37.06s 3.11% runtime.selectrecv /usr/local/go/src/runtime/select.go
22.83s 1.92% 89.65% 22.83s 1.92% runtime.aeshashbody /usr/local/go/src/runtime/asm_amd64.s
20.47s 1.72% 91.37% 20.57s 1.73% runtime.newselect /usr/local/go/src/runtime/select.go
18.65s 1.57% 92.94% 18.65s 1.57% runtime.(*waitq).dequeue /usr/local/go/src/runtime/chan.go
11.83s 0.99% 93.93% 11.83s 0.99% runtime.duffcopy /usr/local/go/src/runtime/duff_amd64.s
8.86s 0.74% 94.67% 8.86s 0.74% runtime.selectgo /usr/local/go/src/runtime/stubs.go
8.42s 0.71% 95.38% 48.05s 4.04% _/home/martin/dev/massign/bob/fx.glob..func677 /home/martin/dev/massign/bob/fx/generated_fxnn.go
8.25s 0.69% 96.07% 975.99s 82.00% _/home/martin/dev/massign/bob/fx.glob..func678 /home/martin/dev/massign/bob/fx/generated_fxnn.go
5.85s 0.49% 96.57% 30.63s 2.57% _/home/martin/dev/massign/bob/fx.glob..func676 /home/martin/dev/massign/bob/fx/generated_fxnn.go
5.81s 0.49% 97.05% 17.64s 1.48% _/home/martin/dev/massign/bob/fx.glob..func675 /home/martin/dev/massign/bob/fx/generated_fxnn.go
2.71s 0.23% 97.28% 135.52s 11.39% runtime.selparkcommit
0.17s 0.014% 97.30% 54.75s 4.60% _/home/martin/dev/massign/bob/fx.glob..func677
0.02s 0.0017% 97.30% 38.18s 3.21% _/home/martin/dev/massign/bob/fx.glob..func676

[dragonsinth]

I don't think you actually need to rip out the ability to stop. The problem is the for loop and default case in the select-- it causes the select to instantly complete, and the for loop to spin in a busy wait.

All you really need is something like this:

select {
case <- ch_stop:
  return
case ch <- frame{matchi, text, line, column}:
}

We don't need the inner for loop, or the sent / stopped vars.

[marsjupiter1]

Sounds sensible. But what I would comment is that what ever happens seems to build up, what I found was that on a successful compile the channel were left open, but closing them did not help. Calling Stop() did close them but not solve the problem. Despite apparently always managing to escape the select, my run of a few hundred unit tests would start off slow and get slower and slower until something in golang exploded.
I will give your suggestion a try when I have the time and see what happens, but simplification is always good and the stop channel seems unneeded.
I really think the scanner and go subprocess is also over complex. Back in the day lexers used to work without a subprocess and managed to support "unput"!

[dragonsinth]

well yeah, that's why #38 ... but it's complicated to move all the state into struct fields that is currently being closed over