The new GC is very nice. --T
On Monday, February 23, 2015 11:57:38 PM Simon Danisch wrote: > Great to hear =) Well it's a rocky road, to be honest... But I think it'll > pay off double in the end! I'm a little afraid of Julia's garbage > collector, but besides that Julia seems to be very fit for high performance > graphics. > > 2015-02-23 23:48 GMT+01:00 Samuel Colvin <[email protected]>: > > I had no idea until today about your effort to use Julia for graphics. > > It's really exciting. > > > > If graphics is becoming one of Julia's "core purposes" then work on > > graphics at a low level isn't wasted. > > > > It sounds like on most of this we're actually agreeing. > > > > I'm as keen as anyone for JavaScript to be a stop gap before something > > better, just that right now it's the best stop gap. > > > > > > -- > > > > Samuel Colvin > > [email protected], > > 07801160713 > > > > On 23 February 2015 at 22:41, Simon Danisch <[email protected]> wrote: > >> *"To qualify what I mean by "easier", I guess I mean: "Easier in most > >> cases for most developers", c and c++ are all very well, but the > >> popularity > >> and ease of development of JavaScript can't be argued with."* > >> > >> That's exactly why I hope that Julia will replace javascript, also for > >> graphics. Like this we have both scientific and graphics algorithms in > >> the > >> same language, which would be huge! > >> > >> Concerning WebGL, I believe that WebGL itself is for the most things not > >> that much slower. It's just more restrictive and doesn't have some > >> options > >> to really speed things up (complicated topic really). > >> So "simple OpenGL" will have very comparable performance to WebGL. > >> Also the whole stack around it makes it difficult, to interactively > >> change and upload huge amounts of values from within julia... > >> Well, all can surely be done with a lot of magic, but I think you end up > >> with the same amount of work, like you would end up with when you cleanly > >> implement it with Julia. > >> While the latter leaves you with an incredible base to do even bigger > >> things (Like having game engines and physics engines, OpenCL/CUDA and the > >> like, which would be a great benefit for the scientific community). > >> > >> Am Montag, 23. Februar 2015 18:38:45 UTC+1 schrieb Samuel Colvin: > >>> To coincide (approximately) with the release of Bokeh v0.8.0 I've > >>> released a significantly improved version of Bokeh.jl: > >>> > >>> http://bokeh.github.io/Bokeh.jl/ > >>> > >>> This is the first plotting library I've built and the first proper Julia > >>> package. I would therefore really appreciate any feedback on the > >>> plotting > >>> interface and the structure of the package itself. > >>> > >>> Bokeh.jl is still a bit rough round the edges and missing some basic > >>> features, but the examples above demonstrate what it can do. > >>> > >>> Bokeh <http://bokeh.pydata.org/en/latest/> is an interactive plotting > >>> library originally developed for python which uses HTML & Javascript as > >>> it's backend to display and manipulate plots. > >>> > >>> Whether by using Bokeh or other libraries, web technologies are the > >>> obvious option for Julia to get great visualization/graphics/UI without > >>> the pain. > >>> > >>> I suggest (and I assume I'm about to get shot down) that the Julia > >>> community stops messing around with any OS specific graphics code and > >>> adopts HTML for all future visualizations. Are there any cases where > >>> that > >>> wouldn't work?
