Given that we have our own terminal functionality and ncurses is generally considered to be not so easy to use, it may be worthwhile to have our own ncurses-like library. But better and simpler, of course. This terminal stuff is a lot easier if you make the radical assumption that people are using hardware from later than 1978.
On Sat, May 24, 2014 at 11:23 AM, Keno Fischer <[email protected] > wrote: > There is NCurses bindings for Julia which used to work before Terminals > was integrated into Julia: https://github.com/loladiro/NCurses.jl. Now > I'm not sure anymore. Will put it on the list of things to do, but no > promises. > > > On Sat, May 24, 2014 at 5:14 PM, Patrick O'Leary <[email protected] > > wrote: > >> It might be possible to PyCall into urwid, though I don't know if there's >> a way to rectify the event loops. >> >> >> On Friday, May 23, 2014 3:05:10 PM UTC-5, Adam Smith wrote: >>> >>> Sweet, that one turns out surprisingly well! When I get further on the >>> main project I'm building in Julia, I want to add a watchdog process that >>> dumps graphs of various app metrics (cpu usage over time, etc.) with >>> TextPlots. Is there a good ncurses-type package for re-drawing a UI in the >>> terminal? I couldn't find one yet. >>> >>> On Friday, May 23, 2014 3:56:59 PM UTC-4, Stefan Karpinski wrote: >>>> >>>> This is so cool: >>>> >>>> julia> plot(cumsum(randn(1000))) >>>> >>>> 2.73641 ⡤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⠤⢤ >>>> ⡇⡼⠇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢸ >>>> ⡇⡇⢃⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢸ >>>> ⡇⠀⢈⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣀⡀⠀⠀⠀⠀⠀⠀⠀⠀⢸ >>>> ⡇⠀⠐⡇⠀⠀⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠠⡴⡄⠀⡀⡾⠅⠀⠀⠀⠀⠀⠀⠀⠀⢸ >>>> ⡇⠀⠀⠚⢀⢠⢣⠀⠀⠀⠄⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣬⠋⣧⠀⣰⠁⠄⢀⠀⠀⠀⠀⠀⠀⠀⢸ >>>> ⡇⠀⠀⢈⣃⢘⠙⠦⠀⢀⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠠⠀⠀⠀⡁⠀⠈⣦⡖⠀⢃⣺⠀⠀⠀⠀⠀⠀⠀⢸ >>>> ⡇⠀⠀⠸⢕⡏⠨⢛⢰⡸⢻⣄⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⢀⣒⣖⠀⠄⠘⣧⡅⠐⠇⠀⠀⠮⠀⠀⠹⠃⠆⠀⠀⠀⠀⠀⠀⢸ >>>> ⡇⠀⠀⠀⠐⠃⠀⠨⣶⠏⠀⠛⣅⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢰⢼⣨⡻⢛⢬⠃⡅⢹⢩⠘⠀⠀⠀⠀⠀⠀⠈⠀⣄⠀⠀⠀⠀⠀⠀⢸ >>>> ⡇⠀⠀⠀⠀⠀⠀⠀⠈⠁⠀⠀⢣⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠐⣦⡄⠀⠀⠀⠀⠀⠀⠀⡊⡍⠇⠁⠐⡝⢷⠃⠀⠘⡕⠀⠀⠀⠀⠀⠀⠀⠀⢹⡿⣃⠀⣀⠀⠀⢸ >>>> ⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢈⠀⠀⠀⠀⠀⠀⠀⠀⡆⢀⠀⠘⡸⠛⣳⠄⢀⠀⠆⠀⠀⠀⡃⠁⠀⠀⠀⠀⠘⠀⠀⠀⠋⠀⠀⠀⠀⠀⠀⠀⠀⠈⠀⢸⣾⡷⠀⠀⢸ >>>> ⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠘⠁⠀⠀⠀⢠⠀⠀⢐⢇⣨⢈⡞⠏⠀⠙⣣⣺⣞⡅⠀⠀⢀⠃⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠋⠘⡄⡀⢸ >>>> ⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢧⣴⣅⣆⣜⢆⠀⢸⠘⡳⡾⠀⠀⠀⠀⢈⡱⢱⢩⠀⠀⠸⠁⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣡⠀⢸ >>>> ⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠸⠏⠿⢫⠍⢹⡄⡖⢠⠁⠁⠀⠀⠀⠀⠈⠁⠀⢨⣄⣨⡮⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠙⠀⢸ >>>> ⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠇⡆⠐⠀⠀⠀⠀⠀⠀⠀⠀⠀⠐⠋⠛⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢸ >>>> ⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠺⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢸ >>>> ⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠈⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢸ >>>> -35.0016 ⠓⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠒⠚ >>>> 1 >>>> 1000 >>>> >>>> >>>> >>>> >>>> On Fri, May 23, 2014 at 3:02 PM, Adam Smith <[email protected]>wrote: >>>> >>>>> Sigh, I had a nagging feeling it was supposed to be plural. I did one >>>>> more (hopefully final) rename to TextPlots.jl: https://github. >>>>> com/sunetos/TextPlots.jl and updated the source/readme and such. >>>>> >>>>> >>>>> On Friday, May 23, 2014 2:18:54 PM UTC-4, Stefan Karpinski wrote: >>>>> >>>>>> There's a convention to name packages plurally – i.e. TextPlotsrather >>>>>> than >>>>>> TextPlot. This is nice partly because using TextPlots reads more >>>>>> naturally than using TextPlot, but more importantly because if you, >>>>>> as is likely, end up having a type called TextPlot, then you don't >>>>>> get a name collision. >>>>>> >>>>>> On Fri, May 23, 2014 at 10:56 AM, Mike Innes <[email protected]>wrote: >>>>>> >>>>>>> Incidentally, interop with other packages without a hard dependency >>>>>>> is something that's around the corner, so you will be able to do this >>>>>>> soon. >>>>>>> >>>>>>> >>>>>>> On 23 May 2014 15:32, Adam Smith <[email protected]> wrote: >>>>>>> >>>>>>>> Thanks all for the feedback! I have renamed it to TextPlot.jl, >>>>>>>> added support for plotting just about any combination of >>>>>>>> functions/vectors/matrix, made the API more flexible for Gadfly >>>>>>>> compatibility, and greatly expanded the documentation/examples. It is >>>>>>>> now >>>>>>>> quite a bit more powerful than ASCIIPlots: https://github.com >>>>>>>> /sunetos/TextPlot.jl >>>>>>>> >>>>>>>> Ivar: I like the idea of having this be a backend for one of the >>>>>>>> other plotting packages, but the dependency would need to be the other >>>>>>>> direction. Meaning, they would need to add support for TextPlot, not >>>>>>>> the >>>>>>>> other way around. Right now TextPlot has zero dependencies, so you can >>>>>>>> use >>>>>>>> it in basically any environment, including a console-only server >>>>>>>> connected >>>>>>>> over SSH. Installing Gadfly requires quite a few dependencies on other >>>>>>>> packages, including Cairo and other graphical packages if you want PNG >>>>>>>> charts (for iTerm2+IPython inline charts, a similar use case to this >>>>>>>> one). >>>>>>>> TextPlot would be quite useful for machines that cannot build all those >>>>>>>> other packages, so I don't want to make TextPlot depend on any of those >>>>>>>> packages. >>>>>>>> >>>>>>>> I think TextPlot is pretty capable already; please let me know if >>>>>>>> you can think of anything it's missing! >>>>>>>> >>>>>>>> >>>>>>>> On Friday, May 23, 2014 5:24:50 AM UTC-4, Ivar Nesje wrote: >>>>>>>>> >>>>>>>>> Yes, that was definitely my intention to suggest. It looks to me >>>>>>>>> like ASCIIPlots.jl and DotPlot.jl solves the same problem in a very >>>>>>>>> similar >>>>>>>>> way, and whether to use Unicode for higher resolution seems like >>>>>>>>> something >>>>>>>>> I would expect to be an option. >>>>>>>>> >>>>>>>>> Anyway, the ultimate goal for ASCII art plots, would be to >>>>>>>>> implement it as a backend for one of the normal plotting packages. >>>>>>>>> >>>>>>>>> Ivar >>>>>>>>> >>>>>>>>> kl. 10:06:42 UTC+2 fredag 23. mai 2014 skrev Tobias Knopp følgende: >>>>>>>>>> >>>>>>>>>> I think "merge" was meant as: Lets create one uniform package and >>>>>>>>>> join the efforts. Since ASCIIPlots is not actively maintained I >>>>>>>>>> think it >>>>>>>>>> would be really great if you could take the lead to make an awsome >>>>>>>>>> text >>>>>>>>>> plotting tool. >>>>>>>>>> >>>>>>>>>> I like the name TextPlot by the way. >>>>>>>>>> >>>>>>>>>> Am Donnerstag, 22. Mai 2014 17:42:06 UTC+2 schrieb Adam Smith: >>>>>>>>>>> >>>>>>>>>>> TextPlot seems like a good name. >>>>>>>>>>> >>>>>>>>>>> Thanks for the offer on merging, but again, there's really >>>>>>>>>>> nothing to merge. Adding scatterplots to dotplot will be trivial; >>>>>>>>>>> I'll do >>>>>>>>>>> that soon (making dotplot's features a superset of ASCIIPlots). >>>>>>>>>>> There is >>>>>>>>>>> nothing compatible/overlapping between these two (small) codebases >>>>>>>>>>> for >>>>>>>>>>> merging to make sense. >>>>>>>>>>> >>>>>>>>>>> I would be curious what John Myles White thinks about a more >>>>>>>>>>> complete terminal plotting package for Julia. ASCIIPlots clearly >>>>>>>>>>> imitates >>>>>>>>>>> Matlab's plotting functions ("imagesc"), and I was going for >>>>>>>>>>> something >>>>>>>>>>> closer to Mathematica or Maple (which are more symbolic-oriented >>>>>>>>>>> than >>>>>>>>>>> Matlab), since I think the syntax is prettier. However, I know a >>>>>>>>>>> large >>>>>>>>>>> portion of Julia's users are also Matlab users, so if >>>>>>>>>>> Matlab-compatibility >>>>>>>>>>> is a goal, you may want to keep the packages separate. >>>>>>>>>>> >>>>>>>>>>> On Thursday, May 22, 2014 11:25:01 AM UTC-4, Leah Hanson wrote: >>>>>>>>>>>> >>>>>>>>>>>> Maybe something like TextPlot would be a good merged name? It >>>>>>>>>>>> conveys what the package does (text plots) rather than how it does >>>>>>>>>>>> it >>>>>>>>>>>> (Braille characters). >>>>>>>>>>>> >>>>>>>>>>>> Having a more complete plotting package for the terminal would >>>>>>>>>>>> move towards having a way to make `plot` just work when you start >>>>>>>>>>>> up a >>>>>>>>>>>> Julia REPL, which I think is a goal. I'd be happy to help merge >>>>>>>>>>>> them, but >>>>>>>>>>>> probably won't have time for a couple weeks. >>>>>>>>>>>> >>>>>>>>>>>> -- Leah >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, May 22, 2014 at 7:49 AM, Adam Smith < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I'm not totally opposed to it, but my initial reaction is not >>>>>>>>>>>>> to: >>>>>>>>>>>>> >>>>>>>>>>>>> 1. I don't necessarily agree about the name. I personally >>>>>>>>>>>>> think "dot plot" has a nice ring to it, and it is a more >>>>>>>>>>>>> accurate >>>>>>>>>>>>> description of what it does (using Braille characters). This >>>>>>>>>>>>> very >>>>>>>>>>>>> specifically exploits Unicode (non-ASCII) characters, so >>>>>>>>>>>>> calling it an >>>>>>>>>>>>> ASCII plot would be misleading (for those who want the >>>>>>>>>>>>> restricted character >>>>>>>>>>>>> set for some reason). >>>>>>>>>>>>> 2. There's not really a single line of code they have in >>>>>>>>>>>>> common, so there's nothing to "merge": it would just be a >>>>>>>>>>>>> rename. I didn't >>>>>>>>>>>>> look at the code of ASCIIPlots before making it, and we chose >>>>>>>>>>>>> completely >>>>>>>>>>>>> different APIs. For example, ASCIIPlots doesn't have a way to >>>>>>>>>>>>> plot >>>>>>>>>>>>> functions, and DotPlot doesn't (yet) have a way to scatterplot >>>>>>>>>>>>> an array. >>>>>>>>>>>>> 3. They are both quite small and simple (dotplot is ~100 >>>>>>>>>>>>> lines of code, ascii is ~250); merging would probably be more >>>>>>>>>>>>> work than >>>>>>>>>>>>> either originally took to create. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Thursday, May 22, 2014 1:31:10 AM UTC-4, Ivar Nesje wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Would it make sense to merge this functionality into >>>>>>>>>>>>>> ASCIIPlots? To me that seems like a better name, and John Myles >>>>>>>>>>>>>> White is >>>>>>>>>>>>>> likely to be willing to transfer the repository if you want to >>>>>>>>>>>>>> be the >>>>>>>>>>>>>> maintainer. That package started from code posted on the mailing >>>>>>>>>>>>>> list, and >>>>>>>>>>>>>> the author thought it was a joke. John packaged it for others to >>>>>>>>>>>>>> use. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>> >>>> >
