frames: adjustable insight, no separate output

[paulp]

First of all, it's so good! Even in its present form it is tempting to use in preference to the standard repl, which is quite an achievement at this stage. I teach a class to middle schoolers using scala and this is instantly my go-to tool for instruction.

It's only because it's so good that I've used it long enough to have a pile of issues to report.

This one is a feature request, but it would be super valuable for usability: as nearly as I can tell the ratio between the size of the insight window and the size of the code window is 50/50. If I could drag this (I need more code and less insight) it would be greatly appreciated.

I noticed that console output goes to a little window on the bottom (also not resizable? Don't remember.) I immediately started gaming it to print to the insight window by letting it print expression results rather than actually calling println, because that's where I want to look - where I'm already looking.

In this environment I can't see the benefit of a third window. After all, you can only get one of "insight" or "output" at a time: if it didn't compile, there's no output. If it did compile, there's no insight (at least not "compiler error message" insight.)

With respect to expression result positioning: I can see the virtue of lining up the result with the expression, but it would be great if I could turn it off. In practice I will invariably have some method definitions, and it is clearer to the novice mind if those come first. As it stands that means there's a bunch of unnecessary whitespace in the right hand column, with the output fluctuating with each line of code. And you can't maintain the correspondence anyway: if I have a five-line result from a one-line expression, the next expression's result is four lines off.

Thanks for this great work.

[MasseGuillaume]

Hi @paulp, thanks for your support. Your post + tweet gave us even more energy. We will fix those issues as quick as possible.

resizing: CodeBrew-io/Frontend#14

In this environment I can't see the benefit of a third window. After all, you can only get one of "insight" or "output" >at a time: if it didn't compile, there's no output. If it did compile, there's no insight (at least not "compiler error >message" insight.) I immediately started gaming it to print to the insight window by letting it print expression results rather than actually calling println, because that's where I want to look - where I'm already looking.

Ok you prefer to have console print in the insight view rather than having a third console window. I also like the idea. Rational behind the 3rd window is that it could be easy to copy paste only the result. Having the println in the insight, one would have to copy line by line to assemble the result.

As it stands that means there's a bunch of unnecessary whitespace in the right hand column, with the output >fluctuating with each line of code. And you can't maintain the correspondence anyway: if I have a five-line result ?>from a one-line expression, the next expression's result is four lines off.

positioning: jedesah/scala-codesheet-api#23

I can see the virtue of lining up the result with the expression, but it would be great if I could turn it off.

do you mean not having insight for some definitions ?

@NoInsight def ...

do you prefer having the insight inlined with the code or on a separate column?
http://i.stack.imgur.com/1PzJv.png vs
http://www.chris-granger.com/images/030/instarepl.png

[paulp]

Ok you prefer to have console print in the insight view rather than having a third console window. I also like the idea. Rational behind the 3rd window is that it could be easy to copy paste only the result. Having the println in the insight, one would have to copy line by line to assemble the result.

I'm not sure what you mean here. I can select the result all by itself from the insight window. For reasons I don't know, cmd-C doesn't work from the insight frame (it does from the other two) but given that it's properly selected it's hard to believe it can't be placed on the clipboard.

do you mean not having insight for some definitions ?

I mean treating the righthand column as a dumb stdout, so I can control the presentation without having to game it.

I'd after having that expression result on line 1. If you want to keep thet UI uncluttered, any kind of hook into the display logic would suffice, e.g. you could expose a codebrew package object with some magic methods. There are other elements which warrant exposure, like the example synthesis. It will be distracting to novices when it tries to get clever dreaming up arguments. I'd much rather it came up with List(1, 2, 3) for def f(xs: List[Int]) = xs.sum than the List(3, 5, 7) it actually uses. Are these hardcoded? If you're not already using scalacheck and Arbitrary/Gen, then you could allow me to create an instance of Arbitrary[List[Int]] and use that... implicits with low priority defaults seem like a good way to allow more customization without adding more buttons.

[MasseGuillaume]

Having a way to specify your Arbitrary/Gen make sense. For now, if you provide default argument it will use them instead.

The insight view is really neat when it works
from : https://codebrew.io/masgui/NXDd6MOHR_GcuNCcMa4qQg
to: https://codebrew.io/shmed/an3Sv1cFQP-a3sJ5qltkxg

It look like you are facing:
jedesah/scala-codesheet-api#12

P.S. glad you like the dark side :-)

[paulp]

P.S. glad you like the dark side :-)

If only they knew the power...

[jedesah]

About the generation of function argument values. Right now we are not using the Arbitrary/Gen pattern from ScalaCheck although I have thought about how we could use it.

Indeed, it would be very nice for the user to declare their own generators for types. What I like right now with the current solution is that the user does not have to do that if they don't have some custom need.

To my knowledge, ScalaCheck does not have a generic Generator for case classes which I find unfortunate. I was toying with the idea of writing one but I'm not sure if it can be done. This would not only allow us to adopt the ScalaCheck generators without losing functionality but also benefit users of ScalaCheck, I think, irrespective of Codebrew.

I still have a lot to learn about reflection and macros (especially macros). @paulp Are you familiar with whether or not this could be accomplished using macros?

[paulp]

@jedesah I think so, investigate https://github.com/milessabin/shapeless-macros .