Fork me on GitHub
#calva
<
2019-06-11
>
pez06:06:45

So, about those missing printouts. It is because currently the Calva nrepl client stops listening for messages once it gets a done from the nrepl server. So when that go-loop returns (which is immediately), I close the door and the stdout arriving after that are smashed to death against that door (though, they are softer than marshmallows, so you don't hear the sound unless you have super human ears). If I keep the door opened, the messages are printed as expected. But I am quite in the dark on how to handle this properly. Seems my housekeeping is not really prepared for this. If anyone of you guys is good with concurrency and listeners like this, I'd welcome some help a lot. Maybe then we can look at how to support nrepl streaming output as well.

bringe14:06:28

I'm not sure if I will have the time the dig into the code, but unfortunately I'll have to go back to the previous version of Calva until this works since my daily workflow relies a lot on these logs. I must admit, I have never used Emacs, and it looks like it would take me a while to get it set up and get used to it for Clojure. I have every intention to stick with the new Calva in the future πŸ™‚. Maybe I can try to find the time to hack on the code.

pez14:06:07

You can do what I do, work with Calva in the debugger. Then just change that line I pointed out to return false instead and see how that works. Would be cool to leverage this bug to get you started with Calva dev. πŸ˜ƒ

bringe15:06:48

I am attempting this now, but not seeing that change make the print statements work =(. I may be doing something wrong. I have the latest of Calva in my own fork. I changed that line to return false in the eval function. I followed the how-to-contribute directions and started all the watch tasks, then hit F5. In the extension development host I opened a new repl. I ran the code and I'm actually seeing print statements but they are delayed.

bringe15:06:40

I'm not sure if my change was picked up or not. The only thing I don't understand is step 5 -> Go back to the Calva code and connect to the REPL. Choose to connect to the :calva-lib cljs REPL.

bringe15:06:55

Not sure how to do that or if it's necessary to test my change

pez15:06:21

That's only necessary if you work with the cljs code.

bringe15:06:43

To be fair, this go-loop sample code does not work in legacy calva either, but that's just using lein repl in cmd/powershell. However, for some reason my actual project logs seem to work.

bringe15:06:53

Β―\(ツ)/Β―

pez15:06:55

It's funny you get the printouts on the same line.

pez15:06:19

What do you mean with delay? How much is it delayed?

bringe15:06:21

Well, I think it should be that way since the code is using print and not println

bringe15:06:31

Several seconds

bringe15:06:36

like 20+ maybe

pez15:06:00

Strange. But it probably has to do with it being print and not println. Can you try?

bringe15:06:01

Those user=> prompts are from me hitting Enter to try to see output. Then I just left it alone and was doing something in another window and saw it print a bunch at once

bringe15:06:11

Sure one minute

pez15:06:01

We don't do streaming yet, so I'm guessing nrepl is buffering stuff.

bringe15:06:11

Yeah seems that way

bringe15:06:20

I know pretty much nothing about this stuff though, but happy to test

pez15:06:39

I don't know enough either. It's a journey of learning.

pez15:06:51

You could try if streaming makes a difference.

bringe15:06:59

What do you mean?

pez15:06:27

In that link that Bozhidar gave me in that issue about pretty printing. There was info there about how to enable nrepl to stream the results.

pez15:06:20

It could make those print calls not wait 20+ seconds. But that is just a guess.

bringe15:06:30

Sounds logical

bringe15:06:53

Ahh so println actually prints the statements real time

pez15:06:55

Depending on your workflow, you could get away with opening a terminal in vscode and run lein repl :connect there, and then use that repl for the commands where you need the output properly handled.

bringe15:06:06

when returning false in eval

pez15:06:10

Yeah, that was what I thought it would.

bringe15:06:01

print seems to print all buffer data every ~60 seconds

pez15:06:05

And maybe streaming would stop that.

pez15:06:33

I'm not by a computer, so can't help much right now.

bringe15:06:03

No problem. If I get some time I will look into it

pez10:06:32

I think I have fixed your unrelated issue, @brandon.ringe. πŸ˜ƒ Please give latest Calva a spin.

bringe14:06:08

It works πŸŽ‰

bringe14:06:12

Closed issue

Yadia12:06:32

wow! new Calva is awsome! thanks :+1:

lspector14:06:47

Congrats on the new version and thanks for all of your work on this! I'm trying to get my sea legs. Jack-in seems to work fine (yea!), and I get a CLJ REPL pane, but when I put this in my editor pane:

(dotimes [i 100]
  (println i))
and run the Clava: evaluate current form (or selection) command I get nothing in CLJ REPL, the numbers from 0 to 99 but with extra newlines in Output:Calva Says (followed by => nil on its own line), and => nil overlaid on the editor pane. I would very much like to get the numbers from 0 to 99 without extra newlines (that is, exactly and only what my code printed), followed by the indication of the return value, => nil) somewhere. I don't mind much if it's in the CLJ REPL or the output pane, but I'd like the program output to appear, unadulterated, somewhere. I would also like not to ever have anything overlaid on the editor pane. IMNSHO that should show only the text that is in the file being edited. Is there an alternative command I could be using to get the behavior I'm looking for?

pez15:06:02

There is a command for evaluating the current form in the repl window

pez15:06:25

As well as the top level form.

pez15:06:00

Welcome back, btw!

lspector16:06:21

Thanks! Ahh! Calva: Send current form (or selection) to the REPL window.... This is the key to the castle!

pez16:06:59

You can also copy the last results to the clipboard: ctrl+alt+c ctrl+c.

lspector16:06:57

Nice -- thanks.

bringe16:06:07

@pez setting nrepl.middleware.pprint/stream? to true seemed to fix to go-loop logging issue!

bringe16:06:26

Even returning true from the messageHandler fn

pez16:06:14

That's interesting. And cool.

bringe17:06:25

@pez false alarm πŸ˜‘ . Did not build the code so changes weren't running. Stream does not fix it, still have to return false for it to work.

bringe17:06:03

I can work with it like this though, I wonder the effects of always returning false.

pez17:06:46

I see those handlers piling up, never cleaned away. We need to figure out what that means and how to deal with it.

bringe15:06:34

Just curious, how are you seeing them?

pez16:06:36

In my sleep. They wake me up. Haha. It is just the way I speak. What I mean is that I worry about it. 😎

bringe18:06:19

Oh, haha. 😎

Jacob Haag18:06:02

Is it possible to peek definitions of re-frame events with the new Calva extension?

pez19:06:03

@jacobhaag17, no, not currently. There was someone starting some work on that, but I don’t think he finished it.