https://github.com/treeform/print
Use print the same way you would use echo for print-debugging. It prints objects the "Nim way" with syntax highlighting. Even with refs, pointers, or cycles!
let
a = 3
b = "hi there"
c = "oh\nthis\0isit!"
d = @[1, 2, 3]
d2 = [1, 2, 3]
f = Foo(a:"hi", b:@["a", "abc"], c:1234)
print a, b, c, d, d2, f
a=3 b="hi there" c="oh\nthis\0isit!" d=@[1, 2, 3] d2=[1, 2, 3] f=Foo(a:"hi", b:@["a", "abc"], c:1234)
I made print because echo would not print some things. And even when it printed stuff it was some times in a strange format. My aim with print is to be able to print something for anything you try to print and print it the "Nim way".
Another thing I want is every time I use echo I need to specify what it is some thing like: echo "a = ", $a. With`print` it does the labels for you print a gets turned into echo "a = ", prettyPrint(a). This means I can just throw a print a and know I will be able to find it in a large stream of prints because they all say what they are printing.
Syntax highlighting is also cool, you can feel like a real hacker using it.
Some times structures are deeply nested. You can use json's echo pretty %a to indent and print them, but some times it goes to far breaking small things all on their own line. This is some thing I did not want. The print library tires to print everything on a line till it hits an edge (as defined by your terminal) then it starts nesting, kind of like nimpretty would with source code.
When printing complex structures they might have cycles. I keep a table of objects already visited, and say "..." if I see a cycle.
Give it a star and try it out, feed back is appreciated!
This looks really good ! I was actually thinking about making something like this as I often found myself repeating the same patterns when echoing stuff.
Is this compatible with the logging module ? Can I log the pretty format as easily as I print it ?
Is there a way to set-up fixed length output for aligning stuff easily when printing ?
My aim with print is to be able to print something for anything you try to print and print it the "Nim way".
That sounds a lot like debugging with pretty-printed expressions. Are there major differences between print and the dump proc in the sugar module?
@Clonk Not compatible with logging, but that can be added if there is enough demand. You can set the global variable printWidth to the width you want like 80 or 120.
@digitalcraftsman I did not know about dump. Thank you for mentioning it. From my quick test, differences with dump:
I would say print is a better version of dump as well?
Please let me know if there is some thing print can't print or crashes on! I'll fix it.
@cblake Not sure what you are getting at? I use the 16 ANSI colors which you can configure in your terminal editor. If the user can't see some colors they can change them to fit what works for them, including just setting them to monochrome. I am sure users are pretty used to this and have setup their terminal color themes accordingly? I think the default 16 ANSI are ugly and I have my own theme.
@digitalcraftsman thank you for trying print out!
I used the 16 ANSI
Exactly - you use them hard coded at compile-time to cyan or red or whatnot into all your prettyPrint overloads. This is not the best.
users are pretty used to this and have setup their terminal color themes accordingly?
I have my own themes as well, but actually, this causes a lot of controversy and inspires soft-switches to request disabling colorization entirely like no color.
Users cannot edit their terminal color palettes to accommodate your library's color selections because other programs (with other color requirements) share the same terminal. Telling users to make their whole terminal environment monochrome because they don't like your color selections for this one library seems fairly user-hostile to me.
Granted, config files are atypical for libraries. An environment variable like LS_COLORS might be more typical (though that eg. is a program). Not sure there is a perfect solution. The bare minimum you should have is a global var/API where your users can disable colorization at compile-time, though I think one can do better & I linked to my examples.
@cblake if you don't want colors its easy to disable with printColors = false in your file. It will automatically go into no-color mode if you pipe stuff to a file anytime when it detect not-a-terminal.
I don't think I will add a whole color-configuration system, I feel that's too much?
Great job!
I was absolutely looking for something like that! Well done! :)
isatty is ok as a way to default colors on/off, but again a run-time override switch to (en|dis)able is better than a compile-time switch. Re-directing to a file or pipe the end user may not want to have to parse or filter out escape sequences. Or on the other hand because there is maybe a lot of output for such redirected text, color could be especially helpful to see the needle in the haystack. Only the end user can really know and it can vary at run-time. So, for example, the Nim compiler itself in colorizing its messages has a nim c --colors:on|off.
As another more concrete follow-up on my initial example, high contrast usually helps color perception. Some people do black backgrounds (and some even say it helps them sleep better...). Others do white (and this was popular enough to have so-called "paper white" terminals be popular in the 90s even when color had gotten cheap). You talk of the 16 colors, but 8 of those are the bright bank foregrounds best with a black background and the other 8 are dark best with the paper white background. All the light from the whiteness makes pupils dilate more and for some people that can improve resolution at the retina. There is no terminal portable way to query what kind of background is even happening at run-time, and some might switch to black backgrounds after 6pm or whatever.
Nim is a fantastic static language, but all this color stuff just seems both fundamentally dynamic and personal for biological & historical reasons that will maybe never go away. So, run-time setups help, are often overlooked in a first pass, and needn't be so hard.
But, hey, It's your library. It can be as minimal as you want. :-) The value of features is often subjective. I am just suggesting things in an attempt to help be more user-friendly to a wider variety of consumers. It's not intended as negative criticism. But this is all probably a conversation better held as some PR on your repo. So, maybe I will do that. :-)