[julia-users] Announcement: Escher.jl - a toolkit for beautiful Web UIs in pure Julia

[Shashi Gowda]

Hello all!

I have been working on a package called *Escher* over the past several
months.

It is now quite feature-rich and ready to use in some sense. I put together
an overview here:

   https://shashi.github.io/Escher.jl/*

My aim is to converge at a UI toolkit that any Julia programmer can use to
create rich interactive GUIs and deploy them over the web, *within minutes*.

Escher simplifies the web platform into a simple and pleasant pure-Julia
library. You don't need to learn or write HTML or CSS or JavaScript. Many
problems associated with traditional web development basically disappear.
There is no need to write separate front-end and back-end code, layouts are
tractable and similar to layouts in the original TeX. Communication is done
under-the-hood as and when required. No boiler plate code. Things just look
great by default.

Briefly, here is how Escher works under the hood:

- A UI is an immutable Julia value that is converted to a Virtual DOM

using the Patchwork  library.
  Compose graphics and Gadfly plots also get rendered to Virtual DOM as
well.
- Subsequent updates to a UI are sent as patches to the current UI over a
websocket connection
- Input widgets send messages to the server over the same websocket
connection
- Complex things like tabs, slideshows, code editor, TeX and dropdown menus
are set up as custom HTML elements using the Web Component
 specification, mainly using the Polymer library
. These things are just Virtual DOM nodes in
the end.


This is still a work in progress, I am very happy to receive any critique
on this thread, and bug reports on Github
. I am very excited to see what you
will create with Escher.

Thanks! :)
Shashi

* - Escher uses some bleeding-edge Web features, this page might not work
so well on Safari, should work well on a decently new Chrome, and on
Firefox if you wait for long enough for all the assets to load. I will be
fixing this in due time, and also working on a cross-browser testing
framework.

PS: I have been dealing with RSI issues of late and my hands will
appreciate any help with expanding the documentation! See
https://github.com/shashi/Escher.jl/issues/26 if you wish to help.

Re: [julia-users] Re: [Slightly OT] Creating JuliaCon presentation slides as a Jupyter notebook

[Shashi Gowda]

It's pretty easy to make slideshows with Escher


function main(window)

 push!(window.assets, "animation")

 slideshow([
   slide1,
   slide2,...
 ])
end

slide1, slide2,... can be any Escher compositions.

On Fri, Jun 5, 2015 at 11:43 AM, Scott T  wrote:

> I've done this for a couple of talks, including
> https://github.com/swt30/ioa-julia-tutorials/blob/master/welcome-to-julia.ipynb.
> It's not too hard - to get started, turn on the "Slideshow" cell toolbar
> and then get experimenting. To make the slides, run
> ipython nbconvert --to slides --post serve slideshow.ipynb
>
> The main limitation is that it can be tricky to access some of the more
> advanced features of Reveal.js from the notebook. I couldn't figure out how
> to include slide backgrounds, for example, since you have to add a
> "data-background" attribute to a slide section, which are created
> automatically by the notebook for you. But it's really easy to include any
> Markdown / LaTeX maths / HTML and the slides look very nice. You can add a
> custom.css file in the same folder to style your presentation - for
> example, changing the font size for MathJax. I also found this useful for
> customizing some of the settings (theme, transition, and so on):
> http://www.damian.oquanta.info/posts/change-the-ipython-slides-defaults-with-an-ipython-config-file.html
>
> Scott T
>
> On Thursday, 4 June 2015 15:49:15 UTC+1, Douglas Bates wrote:
>>
>> The JuliaCon2015 organizers have suggested preparing conference
>> proceedings in the form of Jupyter notebooks, which I think is a great
>> idea.  I have considered going further and preparing presentation slides
>> using Jupyter.  I know this can be done but many of the search engine hits
>> on the topic seem out of date.  Can anyone suggest a discussion or sample
>> notebook regarding this?
>>
>

Re: [julia-users] Escher demos

[Shashi Gowda]

consume is essentially an alias to lift. Escher now lets you embed
interactive UIs in static surroundings. So your example can be simplified
to:

using Color

with_hue(hue, tile=size(4em, 4em, empty)) =
fillcolor(HSV(hue, 0.6, 0.6), tile)

function main(window)
push!(window.assets, "widgets")

xt = Input(0)

vbox(
subscribe(slider(0:360), xt),
consume(with_hue, xt)
)

end




On Tue, Jun 23, 2015 at 12:29 PM, Leonardo  wrote:

> Hello,
> I'm a newbie in Julia but I'm very interested to use it in scientific /
> numeric application with some minimal User Interface, and I think that
> Escher is great for this scope, useful also for remote computation.
>
> Unfortunately I've some problem running simple demos (I use win32 Julia
> in Win7 with latest Firefox)
>
> Trying to understand use of buttons, I've found example *form.jl *included
> in Escher, but it display at the bottom of page Dict{Any,Any}() and
> button doesn't work.
>
> Moreover I've extracted from *Reactive Programming Guide* (*reactive.jl*
> doc included in Escher) a simple hue example (attached), but doesn't work
> in original version because julia cannot found consume()
> using Escher
> using Color
>
>
> xt = Input(0)
>
> with_hue(hue, tile=size(4em, 4em, empty)) =
> fillcolor(HSV(hue, 0.6, 0.6), tile)
>
> function main(window)
> # Load HTML dependencies related to widgets
> push!(window.assets, "widgets")
>
> lift(xt) do x
> slider_and_huebox(x) = vbox(
> subscribe(slider(0:360), xt),
> "The current hue is: $x",
> with_hue(x)
> )
>
> consume(slider_and_huebox,xt)
> end
> end
>
> (I've found a consume()in Julia in file *task.jl*, but it has a
> completely different signature and use)
>
>
> Maybe I made trivial mistakes, but I cannot found right solutions.
> Someone can help me?
>
> Many thanks in advance
>
> Leonardo
>
>

Re: [julia-users] Re: Julia Summer of Code

[Shashi Gowda]

An update:

We have 2 more accepted JSoC projects, thanks to further funding from The
Moor Foundation and MIT.

*Kyunghun Kim* <https://github.com/moon6pence> will be working on HPGPU
Programming for Julia (mentored by Tim Holy)
*Brian Cohen <https://github.com/notthemessiah>* will be working on
implementing a test suit for Escher.jl (mentored by me)


On Tue, Jun 23, 2015 at 5:24 AM, David Anthoff  wrote:

> Congratulations, looks like a great list!
>
>
>
> *From:* julia-users@googlegroups.com [mailto:julia-users@googlegroups.com]
> *On Behalf Of *Jiahao Chen
> *Sent:* Tuesday, June 9, 2015 11:15 PM
> *To:* julia-users@googlegroups.com
> *Subject:* [julia-users] Re: Julia Summer of Code
>
>
>
> I am pleased to announce the list of accepted participants and projects
> for the 2015 Julia Summer of Code:
>
>-
>- *Ambuj Agrawal*, Improving debug information generation in Julia
>(mentor: Keno Fischer @Keno <https://github.com/Keno>)
>- *David Gold (@ <https://github.com/davidagold>davidagold
><https://github.com/davidagold>)*, Nullable arrays (mentor: John Myles
>White @johnmyleswhite <https://github.com/johnmyleswhite>)
>- *Jacob Quinn (@quinnj <https://github.com/quinnj>)*, Pipelines.jl:
>composable streams for data transfer and processing (mentor: Viral B. Shah
>@ViralBShah <https://github.com/ViralBShah>)
>- *Jarrett Revels (@jrevels <https://github.com/jrevels>)*, Automatic
>differentiation (mentors: Miles Lubin @mlubin
><https://github.com/mlubin> and Theodore Papamarkou @scidom
><https://github.com/scidom>)
>- *Kenta Sato (@bicycle1885 <https://github.com/bicycle1885>)*,
>Efficient data structures and algorithms for sequence analysis in BioJulia
> (mentor: Daniel C. Jones @dcjones <https://github.com/dcjones>)
>    - *Rohit Varkey Thankachan (@
><https://github.com/rohitvarkey>rohitvarkey
><https://github.com/rohitvarkey>)*, Compose3D.jl: declarative 3D
>graphics (mentors: Shashi Gowda @shashi <https://github.com/shashi>
>and Simon Danisch @SimonDanisch <https://github.com/SimonDanisch>)
>- *Simon Danisch (@ <https://github.com/SimonDanisch>SimonDanisch
><https://github.com/SimonDanisch>)*, GLVisualize.jl: OpenGL
>visualization in Julia (mentor: Keno Fischer @Keno
><https://github.com/Keno>)
>
> Congratulations to the selected participants and a big thank you to all
> the mentors who agreed to donate their time toward improving Julia.
>
>
>
> Thanks also to the other committee members Alan Edelman, Keno Fischer,
> Miles Lubin, Shashi Gowda, Stefan Karpinski, and Viral Shah for their
> efforts in evaluating the many proposals received.
>

Re: [julia-users] Escher/Compose/Gadfly for heavy visualization

[Shashi Gowda]

For UIs with a million different things any browser is going to be
unusable. You could render your Compose images to PNG and use it with
Escher though - that should be pretty easy on the browser. But then your
bottleneck will be getting Cairo to compile Compose graphics to PNG really
fast. I am unsure about GLVisualize, Simon might be able to tell you about
it further.

On Wed, Jul 1, 2015 at 11:26 PM, Tom Breloff  wrote:

> Has anyone used Escher/Compose/Gadfly for interactive
> visualization/plotting with lots of data (million's of updates)?  Is there
> support for 3D visualization as part of this ecosystem? If not, is it
> planned?  Any performance gotchas I need to worry about?  Bandwidth
> issues?  Missing functionality? etc
>
> Does anyone split their gui/backend into 2 different Julia processes for
> cpu-heavy processing?  Are there built-in methods for updating the gui/viz
> like that or do I have to roll my own with zmq or similar?
>
> Any opinions in the matter would be appreciated.  I'm on the fence whether
> I should commit to a web gui for everything I do or whether I should still
> do some things with Qt, or perhaps GLVisualize.
>
>

[julia-users] Re: Announcement: Escher.jl - a toolkit for beautiful Web UIs in pure Julia

[Shashi Gowda]

@Robert

This discussion was continued here:

https://github.com/shashi/Escher.jl/issues/1#issuecomment-124576960



On Sun, Jul 26, 2015 at 8:49 PM, Robert Feldt 
wrote:

> Michael,
>
> This is not exactly what you are asking for but at least there are some
> plans for integrating Vega.jl (d3-based) and Escher.jl at some point:
>
> https://github.com/johnmyleswhite/Vega.jl/issues/16
>
> If you/others know about other ways to have d3-based/interactive graphs
> in/with Escher please share.
>
> Regards,
>
> Robert Feldt
>
>
> Den fredag 24 juli 2015 kl. 19:10:49 UTC+2 skrev Michael Turok:
>>
>> Package looks beautiful.
>>
>> I see that you are using Gadfly, and using rendering offered up by the
>> Compose package.
>>
>> Any thoughts about how I would render a d3-based infrastrcture?
>>
>> Michael
>>
>> On Monday, June 8, 2015 at 12:23:21 PM UTC-4, Shashi Gowda wrote:
>>>
>>> Hello all!
>>>
>>> I have been working on a package called *Escher* over the past several
>>> months.
>>>
>>> It is now quite feature-rich and ready to use in some sense. I put
>>> together an overview here:
>>>
>>>https://shashi.github.io/Escher.jl/*
>>>
>>> My aim is to converge at a UI toolkit that any Julia programmer can use
>>> to create rich interactive GUIs and deploy them over the web, *within
>>> minutes*.
>>>
>>> Escher simplifies the web platform into a simple and pleasant pure-Julia
>>> library. You don't need to learn or write HTML or CSS or JavaScript. Many
>>> problems associated with traditional web development basically disappear.
>>> There is no need to write separate front-end and back-end code, layouts are
>>> tractable and similar to layouts in the original TeX. Communication is done
>>> under-the-hood as and when required. No boiler plate code. Things just look
>>> great by default.
>>>
>>> Briefly, here is how Escher works under the hood:
>>>
>>> - A UI is an immutable Julia value that is converted to a Virtual DOM
>>> <http://en.wikipedia.org/wiki/React_%28JavaScript_library%29#Virtual_DOM>
>>> using the Patchwork <https://github.com/shashi/Patchwork.jl> library.
>>>   Compose graphics and Gadfly plots also get rendered to Virtual DOM as
>>> well.
>>> - Subsequent updates to a UI are sent as patches to the current UI over
>>> a websocket connection
>>> - Input widgets send messages to the server over the same websocket
>>> connection
>>> - Complex things like tabs, slideshows, code editor, TeX and dropdown
>>> menus are set up as custom HTML elements using the Web Component
>>> <http://webcomponents.org/> specification, mainly using the Polymer
>>> library <http://polymer-project.org/>. These things are just Virtual
>>> DOM nodes in the end.
>>>
>>>
>>> This is still a work in progress, I am very happy to receive any
>>> critique on this thread, and bug reports on Github
>>> <https://github.com/shashi/Escher.jl>. I am very excited to see what
>>> you will create with Escher.
>>>
>>> Thanks! :)
>>> Shashi
>>>
>>> * - Escher uses some bleeding-edge Web features, this page might not
>>> work so well on Safari, should work well on a decently new Chrome, and on
>>> Firefox if you wait for long enough for all the assets to load. I will be
>>> fixing this in due time, and also working on a cross-browser testing
>>> framework.
>>>
>>> PS: I have been dealing with RSI issues of late and my hands will
>>> appreciate any help with expanding the documentation! See
>>> https://github.com/shashi/Escher.jl/issues/26 if you wish to help.
>>>
>>

[julia-users] Re: Interact - basic usage

[Shashi Gowda]

using Reactive, Interact

idx = slider(1:3)
display(idx)
array_elem = lift(i -> A[i], idx)

Or, to the same effect

@manipulate for 1=1:3
   A[i]
end


On Sunday, August 2, 2015 at 6:38:40 AM UTC+5:30, Júlio Hoffimann wrote:
>
> Hi,
>
> Suppose I have:
>
> idx = slider(1:3)
>
> How do I use the value stored in the widget to index an array, let's say 
> A[idx]? I tried playing with signal() and @lift, but none worked. Could you 
> please explain what is the correct approach?
>
> -Júlio
>

Re: [julia-users] Interact and PyPlot - @lift and withfig()

[Shashi Gowda]

Hi,

Easiest way to do this is with @manipulate and `withfig` as you have
discovered.

I'm inclined to remove @lift from reactive since it's hard to implement
correctly and has caused frustrating problems. (also it's not eval-free)

I recommend you use the lift function instead.

s = slider(1:10)
display(s)
lift(x -> greyim(eye(x)), s)

Should do the trick for you.

With PyPlot, this will be:

f = figure()
lift(s) do slider_val
   withfig(f) # This basically says "do the drawing on the same plot f."
    plot something with slider_val...
end






On Mon, Aug 3, 2015 at 12:06 AM, Júlio Hoffimann 
wrote:

> Hi,
>
> Suppose I have:
>
> s = slider(1:10)
> img = @lift eye(s)
>
> How can I create the interactive plot in Jupyter using @lift?
>
> @lift imshow(img)
>
> I know @manipulate has the withfig() option where we can pass the PyPlot
> Figure object, what about @lift?
>
> -Júlio
>

Re: [julia-users] Interact and PyPlot - @lift and withfig()

[Shashi Gowda]

On Mon, Aug 3, 2015 at 12:30 AM, Júlio Hoffimann 
wrote:

> Hi Shashi, thank you very much for your help.
>
> What is slider_val in your code snippet? I actually have multiple sliders
> and other widgets that I want to play with before plotting. Is there any
> version of @manipulate where I can pass all sorts of widgets at once?
>
> @manipulate slider, checkbox, togglebuttons, ... withfig() do
>  ... plot commands ...
> end
>
> -Júlio
>
> 2015-08-02 11:51 GMT-07:00 Shashi Gowda :
>
>> Hi,
>>
>> Easiest way to do this is with @manipulate and `withfig` as you have
>> discovered.
>>
>> I'm inclined to remove @lift from reactive since it's hard to implement
>> correctly and has caused frustrating problems. (also it's not eval-free)
>>
>> I recommend you use the lift function instead.
>>
>> s = slider(1:10)
>> display(s)
>> lift(x -> greyim(eye(x)), s)
>>
>> Should do the trick for you.
>>
>> With PyPlot, this will be:
>>
>> f = figure()
>> lift(s) do slider_val
>>withfig(f) # This basically says "do the drawing on the same plot f."
>> plot something with slider_val...
>> end
>>
>>
>>  slider_val is the argument to the do block.

You can do:

lift(widget1, widget2, widget3) do a, b, c
   withfig(f) # This basically says "do the drawing on the same plot f."
    a, b, c are widget values...
end

or

@manipulate for a=slider(1:3), b=slider(2:4), c=checkbox()
...use a,b,c here...
end


>>
>>
>>
>> On Mon, Aug 3, 2015 at 12:06 AM, Júlio Hoffimann <
>> julio.hoffim...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> Suppose I have:
>>>
>>> s = slider(1:10)
>>> img = @lift eye(s)
>>>
>>> How can I create the interactive plot in Jupyter using @lift?
>>>
>>> @lift imshow(img)
>>>
>>> I know @manipulate has the withfig() option where we can pass the PyPlot
>>> Figure object, what about @lift?
>>>
>>> -Júlio
>>>
>>
>>
>

Re: [julia-users] Re: JuliaCon 2015 videos

[Shashi Gowda]

If you have Escher installed and ready to go (See instructions on
escher-jl.org) you can safely skip the first 20 mins of my Escher.jl video.

A better talk on Escher is this one I gave recently at a conference in
Bangalore: https://youtu.be/UeVUsOX5rAo?t=150 it definitely packs more
content in lesser time.

On Tue, Aug 18, 2015 at 9:42 PM, Frank Kampas  wrote:

> The optimization video is private
>
>
> On Thursday, August 13, 2015 at 1:22:09 PM UTC-4, Viral Shah wrote:
>>
>> Folks,
>>
>> I am happy to announce that the videos are almost all ready, and I will
>> start posting them in batches. I am starting with Jeff’s talk on our
>> Youtube channel:
>>
>> https://www.youtube.com/user/JuliaLanguage
>>
>> Direct link to the video:
>>
>> https://www.youtube.com/watch?v=xUP3cSKb8sI
>>
>> -viral
>>
>>
>>
>>

Re: [julia-users] speed comparison with Mathematica

[Shashi Gowda]

The first time you run a function with a certain tuple of types of
arguments it gets just-in-time compiled adding to the time you measure.
Subsequent runs will be faster and allocate much less memory. Try:

fib(n) = n < 2 ? n : fib(n-1) + fib(n-2)
@time(fib(20))
@time(fib(20))

and consider the second result.


On Fri, Sep 18, 2015 at 1:23 AM, Frank Kampas  wrote:

> On julialang.org, it is stated that Julia is about 170 times faster than
> Mathematica for the the test "fib".  I get about a factor 2.
>
> Julia:
>
> fib(n) = n < 2 ? n : fib(n-1) + fib(n-2)
> println(@time(fib(20)))
>
> elapsed time: 0.001868071 seconds (33280 bytes allocated)
> 6765
>
>
> Mathematica:
>
>
> In[1]:= AbsoluteTiming[fib = 
> Compile[{{n,_Integer}},If[n<2,n,fib[n-1]+fib[n-2
> Out[1]= {0.000134563,CompiledFunction[Argument count: 1
> Argument types: {_Integer}]}
>
>
>
> In[2]:= AbsoluteTiming[fib[20]]
> Out[2]= {0.00385017,6765}
>
>
>
>
>

Re: [julia-users] Escher image

[Shashi Gowda]

You can put the image in the assets/ directory under the directory you
started the server in and then show it with image("assets/img.jpg")

On Tue, Sep 29, 2015, 11:50 AM Yakir Gagnon <12.ya...@gmail.com> wrote:

> How do you show a local image (say it’s in the directory where you ran escher
> --serve)?
> ​
>

Re: [julia-users] Escher plotting example

[Shashi Gowda]

You need Gadfly.inch in place of inch. It's because of a  new change in
Julia 0.4 - if two packages (in this case Escher and Gadfly) export two
different things with the same name (in this case inch), Julia requires you
to fully qualify it (such as Gadfly.inch or Escher.inch). You can use
Escher.inch when setting the width / height of an Escher object and
Gadfly.inch when setting the dimensions of a Gadfly plot in drawing

On Wed, Sep 30, 2015 at 8:56 AM, Yakir Gagnon <12.ya...@gmail.com> wrote:

> I’m trying to use Escher as the main GUI for a program I’m writing. I need
> to replot some data every time the user changes a slider. The plotting.jl
> example seems like the best point to start at. But I get the following
> error (shown only in the browser, not at the shell): UndefVarError: inch
> not defined
>
> Has anyone managed to plot some data and have a (say) slider update it in
> Escher?
> ​
>

Re: [julia-users] Escher plotting example

[Shashi Gowda]

here is the change you need:

https://github.com/shashi/Escher.jl/commit/d2b5c57dd91abc74901821120f57e020809b3bb1

On Wed, Sep 30, 2015 at 9:45 AM, Shashi Gowda 
wrote:

> You need Gadfly.inch in place of inch. It's because of a  new change in
> Julia 0.4 - if two packages (in this case Escher and Gadfly) export two
> different things with the same name (in this case inch), Julia requires you
> to fully qualify it (such as Gadfly.inch or Escher.inch). You can use
> Escher.inch when setting the width / height of an Escher object and
> Gadfly.inch when setting the dimensions of a Gadfly plot in drawing
>
> On Wed, Sep 30, 2015 at 8:56 AM, Yakir Gagnon <12.ya...@gmail.com> wrote:
>
>> I’m trying to use Escher as the main GUI for a program I’m writing. I
>> need to replot some data every time the user changes a slider. The
>> plotting.jl example seems like the best point to start at. But I get the
>> following error (shown only in the browser, not at the shell): UndefVarError:
>> inch not defined
>>
>> Has anyone managed to plot some data and have a (say) slider update it in
>> Escher?
>> ​
>>
>
>

Re: [julia-users] julia WebSocket receiving but not sending binary data.

[Shashi Gowda]

Hey, it looks like WebSockets.jl wasn't setting the right flags in
WebSocket packets for binary data. This patch makes your code work
https://github.com/JuliaWeb/WebSockets.jl/pull/16 :)


On Mon, Aug 25, 2014 at 6:53 PM, Altieres Del-Sent <
altieresdels...@gmail.com> wrote:

> HI,
>
> I am testing the websocket because I want to use it to send e receive
> binary data. So far the sending from browser to client has worked but the
> sending from the server to the client ( more important) it's not, it gives
> me the message. I will probably will switch to a base64, but anyone has
> anyidea how to solve that?
>
> ERROR: read: end of file
>
>  in read at iobuffer.jl:68
>
>  in read at stream.jl:641
>
>  in write at stream.jl:749
>
>  in read_frame at C:\Users\altieres\.julia\WebSockets\src\WebSockets.jl:189
>
>
> I have the follow code in the server
>
> using HttpServer
>
> using WebSockets
>
>
> wsh = WebSocketHandler() do req,client
>
> while true
>
> msg = read(client)
>
> floatArray = reinterpret(Float64,msg)
>
>
> for t in floatArray
>
> print(t)
>
> print("\n")
>
> end
>
> write(client, reinterpret(Uint8,[1.0,2.0,3.0]))
>
> end
>
>   end
>
>
> server = Server(wsh)
>
> run(server,8090)
>
> and the follow in the cliente...
>
> 
> 
> TODO supply a title
> 
> 
> 
> var ws = new WebSocket("ws://localhost:8090");
> ws.onmessage = function(msg) {
> var result = new Float64Array(msg.data);
> var str = "";
> for(var i = 0; i < result.length;i++) {
> str += result[i];
> }
> document.getElementById("log").textContent = str;
> };
>
> ws.onopen = function (event) {
> var array = new Float64Array(300);
> for(var i = 0; i < 300; i++) {
> array[i] = i;
> }
> ws.send(array);
> };
>
>
> 
>
> 
> 
> TODO write content
> 
> 
>
>
>
>

Re: [julia-users] live plotting in PyPlot.jl?

[Shashi Gowda]

@Sheehan

There is now Interact.jl (Pkg.add("Interact")) which lets you travel your
for-loops with sliders and such widgets, to put it one way. Here's an
example notebook showing how you can do interactive plotting with Gadfly or
PyPlot:
http://nbviewer.ipython.org/github/JuliaLang/Interact.jl/blob/master/doc/notebooks/Interactive%20Plotting.ipynb



On Mon, Sep 1, 2014 at 12:28 PM, Sheehan Olver 
wrote:

>
> Got GLPlot working, it's awesome!  The following does a movie of a
> solution to wave equation on a square using latest version of ApproxFun
> (the color is weird since I haven't figured that part out yet):
>
>
>
> window = createdisplay(w=1000,h=1000,eyeposition=Vec3(1,1,1),
> lookat=Vec3(0))
>
> function zcolor(i, j, t)
> x = float32(i - 0.5)
> z = float32(j - 0.5)
> radius = sqrt((x * x) + (z * z))
>
> r = sin(10.0f0 * radius + t)
> g = cos(10.0f0 * radius + t)
> b = radius
> return Vec4(r,g,b, 1)
> end
> yy=xx=-1.:.05:1.
> N=length(xx)
> color = [zcolor(i/N, j/N, 15) for i=1:N, j=1:N];
>
>
> h=0.01;
> u0=TensorFun((x,y)->exp(-10x.^2-20(y-.1).^2))
> d=Interval()⊗Interval()
> L=I-h^2*lap(d);
> B=dirichlet(d);
> S=schurfact([B,L],80);
>
> u=Array(TensorFun,1)
> u[1]=u0
> u[2]=u0
> n=2;
>
>
> GLPlot.glClearColor(1,1,1,0)
> m=400
> for k=n+1:n+m
> u[k]=(S\[zeros(4),2u[k-1]-u[k-2]])
> vals=[u[k][x,y] for x in xx,y in yy];
> texdata=map(Vec1,vals)
> obj   = glplot(texdata, primitive=SURFACE(), color=color);
> GLPlot.glClear(GLPlot.GL_COLOR_BUFFER_BIT | GLPlot.GL_DEPTH_BUFFER_BIT)
> render(obj)
> yield()
>  GLFW.SwapBuffers(window.glfwWindow)
> end
> n+=m
>
> On 21 Aug 2014, at 9:51 am, Simon Danisch  wrote:
>
> Good to hear.
> The test looks funny, as I overlay everything GLPlot is able to do ;)
> I should remove example.jl, as it uses legacy code.
> I'm not sure about the surface example, though... Did you change anything?
> This might be due to a change of the output from imread (Images.jl) and
> shouldn't be a problem if you use your own arrays.
> I'll have a look at this tomorrow...
>
>
> 2014-08-20 23:58 GMT+02:00 Sheehan Olver :
>
>> OK I rebuilt julia and cleared my .julia folder, which seems to have
>> cleared that issue.  Pkg.test(“GLPlot”) seems to work, though the output
>> looks funny.   I also get the following:
>>
>> julia> include("surface.jl")
>> INFO: loaded GLFW 3.0.4 Cocoa NSGL chdir menubar dynamic from
>> /Users/solver/.julia/v0.4/GLFW/deps/usr64/lib/libglfw
>> ERROR: Color Format RGBA not supported
>>  in error at error.jl:21
>>  in Texture at
>> /Users/solver/.julia/v0.4/GLAbstraction/src/GLTexture.jl:156
>>  in include at ./boot.jl:245
>>  in include_from_node1 at ./loading.jl:128
>> while loading /Users/solver/.julia/v0.4/GLPlot/example/surface.jl, in
>> expression starting on line 24
>>
>> julia> include("example.jl")
>> INFO: loaded GLFW 3.0.4 Cocoa NSGL chdir menubar dynamic from
>> /Users/solver/.julia/v0.4/GLFW/deps/usr64/lib/libglfw
>> ERROR: Cam not defined
>>  in include at ./boot.jl:245
>>  in include_from_node1 at ./loading.jl:128
>> while loading /Users/solver/.julia/v0.4/GLPlot/example/example.jl, in
>> expression starting on line 25
>>
>>
>> On 20 Aug 2014, at 9:37 pm, Tim Holy  wrote:
>>
>> > You might need a Pkg.update(), or Pkg.build("Images") if the update
>> doesn't
>> > solve it.
>> >
>> > --Tim
>> >
>> > On Wednesday, August 20, 2014 09:23:16 PM Sheehan Olver wrote:
>> >> OK Now I get
>> >>
>> >> could not open file
>> >> /Users/solver/.julia/v0.3/Images/src/ioformats/../../deps/deps.jl while
>> >> loading
>> /Users/solver/.julia/v0.3/Images/src/ioformats/libmagickwand.jl, in
>> >> expression starting on line 24 while loading
>> >> /Users/solver/.julia/v0.3/Images/src/Images.jl, in expression starting
>> on
>> >> line 38 while loading
>> >> /Users/solver/.julia/v0.3/GLAbstraction/src/GLTexture.jl, in expression
>> >> starting on line 1 while loading
>> >> /Users/solver/.julia/v0.3/GLAbstraction/src/GLTypes.jl, in expression
>> >> starting on line 40 while loading
>> >> /Users/solver/.julia/v0.3/GLAbstraction/src/GLAbstraction.jl, in
>> expression
>> >> starting on line 8
>> >> On 20 Aug 2014, at 9:06 pm, Simon Danisch  wrote:
>> >>> Yes I do =)
>> >>> You need to install Images.jl properly with its dependency.
>> >>> https://github.com/timholy/Images.jl
>> >>> I should at some point load this conditional, as you don't really need
>> >>> Images.jl as long as you don't read images from your HD.
>> >>>
>> >>>
>> >>> 2014-08-20 13:01 GMT+02:00 Sheehan Olver :
>> >>> OK I cloned all the necessary projects but get the following error on
>> OS
>> >>> X, and thoughts?
>> >>>
>> >>> julia> include("surface.jl")
>> >>> ERROR: error compiling Texture: error compiling __Texture#30__: error
>> >>> compiling imread: error compiling imread: error compiling MagickWand:
>> >>> could not load module : dlopen(.dylib, 1): image not found>
>> >>> in GLFont at /Users/solver/.julia/v0.3/GLText/src/types.jl:97
>> >>> in inittext

Re: [julia-users] Currying in Julia

[Shashi Gowda]

Here's a macro for currying. Since there are vararg functions we will need
to specify the number of arguments to curry away at.

macro curry(n, f)
syms = [gensym() for i=1:n]
foldl((ex, sym)  -> Expr(:->, sym, ex), Expr(:call, f, syms...),
reverse(syms))
end

add4 = @curry 4 +

add4(1)(2)(3)(4)
#=> 10
foldr(|>, add4, [1:4])
#=> 10

This is really really slow though.


On Tue, Sep 2, 2014 at 2:50 AM, Michael Louwrens <
michael.w.louwr...@outlook.com> wrote:

> I just wanted to add an example of function currying in Julia.
>
> It isn't exactly pretty but it does work! I don't expect it to be
> performant however.
>
> julia>
> function Add(x)
>return function f(y)
>  return x + y
>  end
>end
>
>
> Add (generic function with 1 method)
>
> julia> Add(1)(2)
> 3
>
> A simple example, but it does show basic currying working fine.
>

Re: [julia-users] Currying in Julia

[Shashi Gowda]

Actually, I'm not sure about the slowness. :)

julia> g = @curry 100 +
(anonymous function)

julia> @time foldr(|>, g, [1:100])
elapsed time: 0.468942365 seconds (594640 bytes allocated) # A lot of this
is for compiling g
5050

julia> @time foldr(|>, g, [1:100])
elapsed time: 0.000155383 seconds (71712 bytes allocated)
5050

julia> @time +([1:100]...)
elapsed time: 0.000209564 seconds (26792 bytes allocated)
5050



On Tue, Sep 2, 2014 at 4:14 AM, Shashi Gowda 
wrote:

> Here's a macro for currying. Since there are vararg functions we will need
> to specify the number of arguments to curry away at.
>
> macro curry(n, f)
> syms = [gensym() for i=1:n]
> foldl((ex, sym)  -> Expr(:->, sym, ex), Expr(:call, f, syms...),
> reverse(syms))
> end
>
> add4 = @curry 4 +
>
> add4(1)(2)(3)(4)
> #=> 10
> foldr(|>, add4, [1:4])
> #=> 10
>
> This is really really slow though.
>
>
> On Tue, Sep 2, 2014 at 2:50 AM, Michael Louwrens <
> michael.w.louwr...@outlook.com> wrote:
>
>> I just wanted to add an example of function currying in Julia.
>>
>> It isn't exactly pretty but it does work! I don't expect it to be
>> performant however.
>>
>> julia>
>> function Add(x)
>>return function f(y)
>>  return x + y
>>  end
>>end
>>
>>
>> Add (generic function with 1 method)
>>
>> julia> Add(1)(2)
>> 3
>>
>> A simple example, but it does show basic currying working fine.
>>
>
>

Re: [julia-users] Re: GtkInteract

[Shashi Gowda]

This is very cool!

I really love how there is no lag in the example and things seem so
responsive. Added a link in the Interact.jl README.

One of Interact's goals is to make such adaptions hassle-free. Please do
file issues if you think some change to Interact can make your code neater.


On Sun, Sep 7, 2014 at 11:41 AM, Iain Dunning  wrote:

> Don't think I need this personally, but just wanted to say - looks cool!
>
> On Saturday, September 6, 2014 4:35:33 PM UTC-4, j verzani wrote:
>>
>> The new Interact.jl package allows you to use interactive widgets such as
>> sliders, dropdowns and checkboxes to play with your Julia code within an
>> IJulia session. It is pretty neat, in particular the `@manipulate` macro.
>> For those times where IJulia is not convenient, but the console is, I've
>> made a small wrapper package GtkInteract.jl that creates these widgets in
>> Gtk with the expectation that Winston will be used for graphics. If you are
>> interested in such a thing, you can try it out by cloning the package:
>> Pkg.clone("https://github.com/jverzani/GtkInteract.jl.git";).
>>
>>

Re: [julia-users] Re: GtkInteract

[Shashi Gowda]

It would be nice if the same code that begins with `using Interact` can run
in multiple environments. But this arrangement is cool too. Right now, all
IJulia specific stuff is in Interact/src/IJulia. It was initially a
separate package, then we put it inside Interact for convenience. The main
thing the IJulia specific part does is override writemime(::IO, ::MIME,
::Signal) and  writemime(::IO, ::MIME, ::Widget) to set up communication
and invoke IPython widgets.

This highly dated document
https://github.com/JuliaLang/Interact.jl/blob/master/DESIGN.md describes
some of the initial ideas about separating environment specifics from
widget models.


On Sun, Sep 7, 2014 at 12:15 PM, Shashi Gowda 
wrote:

> This is very cool!
>
> I really love how there is no lag in the example and things seem so
> responsive. Added a link in the Interact.jl README.
>
> One of Interact's goals is to make such adaptions hassle-free. Please do
> file issues if you think some change to Interact can make your code neater.
>
>
> On Sun, Sep 7, 2014 at 11:41 AM, Iain Dunning 
> wrote:
>
>> Don't think I need this personally, but just wanted to say - looks cool!
>>
>> On Saturday, September 6, 2014 4:35:33 PM UTC-4, j verzani wrote:
>>>
>>> The new Interact.jl package allows you to use interactive widgets such
>>> as sliders, dropdowns and checkboxes to play with your Julia code within an
>>> IJulia session. It is pretty neat, in particular the `@manipulate` macro.
>>> For those times where IJulia is not convenient, but the console is, I've
>>> made a small wrapper package GtkInteract.jl that creates these widgets in
>>> Gtk with the expectation that Winston will be used for graphics. If you are
>>> interested in such a thing, you can try it out by cloning the package:
>>> Pkg.clone("https://github.com/jverzani/GtkInteract.jl.git";).
>>>
>>>
>

Re: [julia-users] GtkInteract

[Shashi Gowda]

Tim, is there a way to show Compose output in ImageView? Will be nice to
have SVG rendering - that's the fastest Compose backend. It would also let
Gadfly plots show up.


On Sun, Sep 7, 2014 at 5:35 PM, Tim Holy  wrote:

> John, this sounds very interesting. At some point I will need to do a bit
> of
> an overhaul on ImageView, and I certainly plan to take a close look at this
> package.
>
> Best,
> --Tim
>
> On Saturday, September 06, 2014 01:35:33 PM j verzani wrote:
> > The new Interact.jl package allows you to use interactive widgets such as
> > sliders, dropdowns and checkboxes to play with your Julia code within an
> > IJulia session. It is pretty neat, in particular the `@manipulate` macro.
> > For those times where IJulia is not convenient, but the console is, I've
> > made a small wrapper package GtkInteract.jl that creates these widgets in
> > Gtk with the expectation that Winston will be used for graphics. If you
> are
> > interested in such a thing, you can try it out by cloning the package:
> > Pkg.clone("https://github.com/jverzani/GtkInteract.jl.git";).
>
>

Re: [julia-users] Julia iPython notebook doesn't display inline graphics

[Shashi Gowda]

Which package are you using for plotting? Gadfly and PyPlot currently work
well with IJulia as far as I know.

On Sun, Sep 7, 2014 at 7:21 PM, Bruno Morgado  wrote:

> Hi all,
>
> I'm trying to get started with Julia but I'm having some troubles.
>
> After finally getting to get iJulia to run and starting a notebook in the
> browser, I can finally follow and execute all the code, but I still can't
> see any inline graphs.
> The code runs correctly (first it complained about missing Cairo but I
> installed that), but it doesn't show anything inline.
>
> How do I fix this?
>

Re: [julia-users] Re: how to use union!(s, iterable)

[Shashi Gowda]

What is exactly is s? If you want to create a set,

two_d_array = reshape([1:4], 2, 2)
s = union!(Set{Int}(), two_d_array)

seems to work.

Re: [julia-users] Interact + PyPlot: only update when releasing slider

[Shashi Gowda]

Unfortunately, the @manipulate macro can only rerun the expression at every
update of any of its input.

What you need here is Reactive
's `sampleon`
function:

using Reactive, Interact
f = figure();

α=slider(1:0.1:3)
β=slider(1:0.1:3)
γ=slider(1:0.1:3)
replot = button("Replot") # Commit your changes
map(display, α, β, γ, replot) # optional

sampled_coeffs = sampleon(redo, lift(tuple, α, β, γ))

withfig(f)

@lift plot(apply(fun, sampled_coeffs))

IPython doesn't do update on release, Interact, in fact, uses the same
widgets. What it does do is have at most 4 updates at any given time in the
processing pipeline (any more updates replace the last update in the queue).

On Mon, Sep 8, 2014 at 8:45 PM, Andrei Berceanu 
wrote:

> Another option would be to use drop-down boxes with selectable values or
> custom text boxes instead of sliders, at least as a temporary fix. Anyone
> knows how I can do that?
> By the way, iirc, IPython does have the update-on-release mechanism
> implemented in their interactive widget functionality.
>
> On Monday, September 8, 2014 4:10:05 PM UTC+2, John Myles White wrote:
>>
>> I suspect the only way to do this is to change Interact so that it
>> exposes a minimum time threshold before it registers a state change.
>>
>>  — John
>>
>> On Sep 8, 2014, at 4:16 AM, Andrei Berceanu 
>> wrote:
>>
>> > I have some code along the lines of
>> >
>> > f = figure()
>> > @manipulate for α=1:0.1:3, β=1:0.1:3, γ=1:0.1:3; withfig(f) do
>> > y = fun(α,β,γ)
>> > PyPlot.plot(x, y)
>> > end
>> > end
>> >
>> > where fun is a *very slow* function to evaluate. Is there any way to
>> tell @manipulate to update the resulting plot only after I release the
>> sliders? Otherwise what I get is, I release them to the desised values and
>> then have to wait ages for all the intermediate plots to be drawn.
>> >
>> > Tnx!
>>
>>

Re: [julia-users] Interact + PyPlot: only update when releasing slider

[Shashi Gowda]

John's suggestion is also a good way to do this. You can sample the signals
at a specific interval instead of on button clicks:

# At 2 fps, with repeats dropped.
sampled_coeffs = droprepeats(sampleon(fps(2), lift(tuple, α, β, γ)))

On Mon, Sep 8, 2014 at 9:36 PM, Shashi Gowda 
wrote:

> Unfortunately, the @manipulate macro can only rerun the expression at
> every update of any of its input.
>
> What you need here is Reactive
> <http://julialang.org/Reactive.jl/api.html#sample-and-merge>'s `sampleon`
> function:
>
> using Reactive, Interact
> f = figure();
>
> α=slider(1:0.1:3)
> β=slider(1:0.1:3)
> γ=slider(1:0.1:3)
> replot = button("Replot") # Commit your changes
> map(display, α, β, γ, replot) # optional
>
> sampled_coeffs = sampleon(redo, lift(tuple, α, β, γ))
>
> withfig(f)
>
> @lift plot(apply(fun, sampled_coeffs))
>
> IPython doesn't do update on release, Interact, in fact, uses the same
> widgets. What it does do is have at most 4 updates at any given time in the
> processing pipeline (any more updates replace the last update in the queue).
>
> On Mon, Sep 8, 2014 at 8:45 PM, Andrei Berceanu 
> wrote:
>
>> Another option would be to use drop-down boxes with selectable values or
>> custom text boxes instead of sliders, at least as a temporary fix. Anyone
>> knows how I can do that?
>> By the way, iirc, IPython does have the update-on-release mechanism
>> implemented in their interactive widget functionality.
>>
>> On Monday, September 8, 2014 4:10:05 PM UTC+2, John Myles White wrote:
>>>
>>> I suspect the only way to do this is to change Interact so that it
>>> exposes a minimum time threshold before it registers a state change.
>>>
>>>  — John
>>>
>>> On Sep 8, 2014, at 4:16 AM, Andrei Berceanu 
>>> wrote:
>>>
>>> > I have some code along the lines of
>>> >
>>> > f = figure()
>>> > @manipulate for α=1:0.1:3, β=1:0.1:3, γ=1:0.1:3; withfig(f) do
>>> > y = fun(α,β,γ)
>>> > PyPlot.plot(x, y)
>>> > end
>>> > end
>>> >
>>> > where fun is a *very slow* function to evaluate. Is there any way to
>>> tell @manipulate to update the resulting plot only after I release the
>>> sliders? Otherwise what I get is, I release them to the desised values and
>>> then have to wait ages for all the intermediate plots to be drawn.
>>> >
>>> > Tnx!
>>>
>>>
>

Re: [julia-users] Interact + PyPlot: only update when releasing slider

[Shashi Gowda]

using Reactive, Interact
using PyPlot

f = figure();

α=slider(1:0.1:3)
β=slider(1:0.1:3)
γ=slider(1:0.1:3)
replot = button("Replot") # Commit your changes
map(display, [α, β, γ, replot]) # optional

coeffs = sampleon(replot, lift(tuple, α, β, γ))

@manipulate for x = coeffs; withfig(f) do
plot(fun(x...))
end
end

Sorry, in my rush to reply, I left behind some typos and bad thinking.
Tried this, it works.

On Tue, Sep 9, 2014 at 2:28 PM, Andrei Berceanu 
wrote:

> Thank you both for the suggestions! I am currently trying the "Replot"
> button approach, but ran into some errors, as follows:
>
> using Reactive, Interact
> using PyPlot
>
> fun(α, β, γ) = cos(α + sin(β+γ)) #example function
>
> f = figure();
>
> α=slider(1:0.1:3)
> β=slider(1:0.1:3)
> γ=slider(1:0.1:3)
> replot = button("Replot") # Commit your changes
> map(display, α, β, γ, replot) # optional
> -->  `start` has no method matching start(::Slider{Float64})
>
> sampled_coeffs = sampleon(redo, lift(tuple, α, β, γ))
> -->  redo not defined
>
> withfig(f)
> @lift plot(apply(fun, sampled_coeffs))
> --> `withfig` has no method matching withfig(::Figure)
>
>
> On Monday, September 8, 2014 6:10:59 PM UTC+2, Shashi Gowda wrote:
>>
>> John's suggestion is also a good way to do this. You can sample the
>> signals at a specific interval instead of on button clicks:
>>
>> # At 2 fps, with repeats dropped.
>> sampled_coeffs = droprepeats(sampleon(fps(2), lift(tuple, α, β, γ)))
>>
>> On Mon, Sep 8, 2014 at 9:36 PM, Shashi Gowda  wrote:
>>
>>> Unfortunately, the @manipulate macro can only rerun the expression at
>>> every update of any of its input.
>>>
>>> What you need here is Reactive
>>> <http://julialang.org/Reactive.jl/api.html#sample-and-merge>'s
>>> `sampleon` function:
>>>
>>> using Reactive, Interact
>>> f = figure();
>>>
>>> α=slider(1:0.1:3)
>>> β=slider(1:0.1:3)
>>> γ=slider(1:0.1:3)
>>> replot = button("Replot") # Commit your changes
>>> map(display, α, β, γ, replot) # optional
>>>
>>> sampled_coeffs = sampleon(redo, lift(tuple, α, β, γ))
>>>
>>> withfig(f)
>>>
>>> @lift plot(apply(fun, sampled_coeffs))
>>>
>>> IPython doesn't do update on release, Interact, in fact, uses the same
>>> widgets. What it does do is have at most 4 updates at any given time in the
>>> processing pipeline (any more updates replace the last update in the queue).
>>>
>>> On Mon, Sep 8, 2014 at 8:45 PM, Andrei Berceanu 
>>> wrote:
>>>
>>>> Another option would be to use drop-down boxes with selectable values
>>>> or custom text boxes instead of sliders, at least as a temporary fix.
>>>> Anyone knows how I can do that?
>>>> By the way, iirc, IPython does have the update-on-release mechanism
>>>> implemented in their interactive widget functionality.
>>>>
>>>> On Monday, September 8, 2014 4:10:05 PM UTC+2, John Myles White wrote:
>>>>>
>>>>> I suspect the only way to do this is to change Interact so that it
>>>>> exposes a minimum time threshold before it registers a state change.
>>>>>
>>>>>  — John
>>>>>
>>>>> On Sep 8, 2014, at 4:16 AM, Andrei Berceanu 
>>>>> wrote:
>>>>>
>>>>> > I have some code along the lines of
>>>>> >
>>>>> > f = figure()
>>>>> > @manipulate for α=1:0.1:3, β=1:0.1:3, γ=1:0.1:3; withfig(f) do
>>>>> > y = fun(α,β,γ)
>>>>> > PyPlot.plot(x, y)
>>>>> > end
>>>>> > end
>>>>> >
>>>>> > where fun is a *very slow* function to evaluate. Is there any way to
>>>>> tell @manipulate to update the resulting plot only after I release the
>>>>> sliders? Otherwise what I get is, I release them to the desised values and
>>>>> then have to wait ages for all the intermediate plots to be drawn.
>>>>> >
>>>>> > Tnx!
>>>>>
>>>>>
>>>
>>

Re: [julia-users] intermediate results with reduce / FoldList

[Shashi Gowda]

In this particular case, cumsum does exactly this,

julia> cumsum([1:10])
10-element Array{Int64,1}:
  1
  3
  6
 10
 15
 21
 28
 36
 45
 55

I guess that would be idiomatic Julia ;)

An equivalent foldl would be
foldl((a, b) -> push!(a, a[end]+b), Int[1], [2:10])
10-element Array{Int64,1}:
  1
  3
  6
 10
 15
 21
 28
 36
 45
 55

A generic cumfoldl would be

julia> cumfoldl(f, x0, itr) = foldl((a, b) -> push!(a, f(a[end], b)),
[itr[1]], itr[2:end])
cumfoldl (generic function with 1 method)

julia> cumfoldl(*, 0, map(string, 1:10))
10-element Array{ASCIIString,1}:
 "1"
 "12"
 "123"
 "1234"
 "12345"
 "123456"
 "1234567"
 "12345678"
 "123456789"
 "12345678910"


I often find it useful to remind myself that foldl(push!, eltype(list)[],
list) constructs the same list and take it from there.

Re: [julia-users] intermediate results with reduce / FoldList

[Shashi Gowda]

or rather,

julia> cumfoldl(f, x0, itr) = foldl((a, b) -> push!(a, f(a[end], b)), [x0],
itr)
julia> cumfoldl(*, "0", map(string, 1:10))
11-element Array{ASCIIString,1}:
 "0"
 "01"
 "012"
 "0123"
 "01234"
 "012345"
 "0123456"
 "01234567"
 "012345678"
 "0123456789"
 "012345678910"


On Tue, Sep 9, 2014 at 9:15 PM, Shashi Gowda 
wrote:

> In this particular case, cumsum does exactly this,
>
> julia> cumsum([1:10])
> 10-element Array{Int64,1}:
>   1
>   3
>   6
>  10
>  15
>  21
>  28
>  36
>  45
>  55
>
> I guess that would be idiomatic Julia ;)
>
> An equivalent foldl would be
> foldl((a, b) -> push!(a, a[end]+b), Int[1], [2:10])
> 10-element Array{Int64,1}:
>   1
>   3
>   6
>  10
>  15
>  21
>  28
>  36
>  45
>  55
>
> A generic cumfoldl would be
>
> julia> cumfoldl(f, x0, itr) = foldl((a, b) -> push!(a, f(a[end], b)),
> [itr[1]], itr[2:end])
> cumfoldl (generic function with 1 method)
>
> julia> cumfoldl(*, 0, map(string, 1:10))
> 10-element Array{ASCIIString,1}:
>  "1"
>  "12"
>  "123"
>  "1234"
>  "12345"
>  "123456"
>  "1234567"
>  "12345678"
>  "123456789"
>  "12345678910"
>
>
> I often find it useful to remind myself that foldl(push!, eltype(list)[],
> list) constructs the same list and take it from there.
>

Re: [julia-users] Re: 3D interactive plots in IJulia

[Shashi Gowda]

It should be possible to use 3D (surf etc) plots from PyPlot with
Interact.jl in IJulia.

On Wed, Mar 4, 2015 at 7:06 AM, Jack Minardi  wrote:

> I've used matplotlib's 3D plotting capabilities successfully through
> PyPlot.jl in the past.
>
> On Tuesday, March 3, 2015 at 10:38:32 AM UTC-5, Andrei Berceanu wrote:
>>
>> Is there some Julia library that allows one to do create 3D (surface
>> plots) in the IJulia notebook and then rotate them interactively, using the
>> mouse?
>>
>> //A
>>
>

Re: [julia-users] Creating custom IJulia widgets

[Shashi Gowda]

That's a pretty accurate write-up! :) Thanks for posting this.

As you might have figured out Interact's widgets rely on IPython's built-in
widgets, which are described here
https://github.com/ipython/ipython/wiki/IPEP-23:-Backbone.js-Widgets - but
that document is not very comprehensive, so I had to read some IPython code
that orchestrates these widgets. If you want to use these widgets though,
then you might just want to use Interact, the example notebooks give an
overview of how to use them in different ways (although the most popular is
@manipulate)

On Mon, Mar 9, 2015 at 7:49 AM, Avi Ruderman  wrote:

> Hi all,
>
> I spent the last couple of days building some custom IJulia widgets. I
> struggled to find a clear explanation online of how to do this. So I
> thought I would put together a small notebook with what I have learned
> along the way in case others may find this useful.
>
>
> http://nbviewer.ipython.org/urls/gist.githubusercontent.com/avrahamruderman/116845471f0d79942aff/raw/fb1f659e635f4585ebb449aa2519deffd15aba31/writing-custom-ijulia-widgets.ipynb
>
> I would really welcome suggestions for improvement as I am sure the code
> can be greatly improved (this is my first time building something with
> JavaScript.)
>
> Cheers,
> Avi
>

Re: [julia-users] Re: Informal Call for a Julia π - day challenge

[Shashi Gowda]

Late to the party but here's a simple monte carlo simulation visualized

using Reactive, Interact, Compose
randpoint() = (rand(), rand())
isin(x, y) = 0.25 > (x-0.5)^2 + (y-0.5)^2
Compose.set_default_graphic_size(8inch, 8inch)

@manipulate for switch=false,
t=fpswhen(switch, 10),
point=lift(x -> randpoint(), t),
points=foldl(push!, Any[randpoint()], point),
incount=foldl((x, y) -> x + isin(y...), 1, point),
count = foldl((x, y) -> x+1, 1, point)

compose(context(),
(context(), text(0, 0.1, "π ≊ $(4*incount/count)")),
[(context(), fill("red"), circle(x, y, 0.005)) for (x, y) in
points]...,
(context(), fill("lightblue"), circle()))
end

Also http://arxiv.org/pdf/1404.1499v2.pdf ;)

On Sun, Mar 15, 2015 at 6:01 AM, David P. Sanders 
wrote:

>
>
> El sábado, 7 de marzo de 2015, 11:59:47 (UTC-6), Alan Edelman escribió:
>>
>> With about a week left, I'd love to find out how many digits of  π  we
>> can get only from Julia.
>>
>> Perhaps we can coordinate a worldwide distributed computation this week.
>>
>>
>>
> In a different direction, it seems not to be well known that we can
> calculate *rigorous bounds*
> on π using just floating-point aritmetic. I have made an example notebook
> that may be viewed here:
>
> http://nbviewer.ipython.org/gist/dpsanders/3e69e4a2d4f5b5727258
>
> [Comments of course welcome!]
>
> Best,
> David.
>
>
>

Re: [julia-users] strange behaviour of togglebuttons in Interact.jl

[Shashi Gowda]

Not a bug, if you are passing in your own input signal to widgets, you need
to take care of maintaining the right initial values. It's also better to
use OrderedDict from DataStructures package here to keep the ordering of
the key-value pairs.



On Tue, Mar 24, 2015 at 7:39 PM, Andrei Berceanu 
wrote:

> Consider the following code
>
>
>
>
>
>
> *using Reactive, Interactα = Input(0)togglebuttons(["one" => 1, "two" =>
> 2], signal=α)signal(α)*I would expect the value of *α *to change after
> executing the *togglebuttons*(..) line, however this is not the case.
> *signal(α) *on the next line shows that *α *is still 0, even though one
> of the buttons is pre-selected. One has to press the buttons at least once
> to change the value of *α*.
> Can this behaviour be changed? Is it a bug?
>

Re: [julia-users] strange behaviour of togglebuttons in Interact.jl

[Shashi Gowda]

using Interact, Reactive

α = Input(2)
display(togglebuttons(["one" => 1, "two" => 2], signal=α))
signal(α)

results in "two" being selected initially. If you want to set initial label
to be selected, you can use the value_label keyword argument

If you want the selection to change wrt another signal, you will need to
lift the togglebuttons and set the value_label, but the value in the input
won't change without user interaction...

I may not have understood your question fully well. I hope you can play
around with value_label and let me know where you get!

Thanks
Shashi


On Tue, Mar 24, 2015 at 10:23 PM, Andrei Berceanu 
wrote:

> OK, I see. Now my problem is that, in my code, the initial value should
> then depend on another signal, and I have found no way of resolving this.
> The actual code I have is
>
>
>
>
>
>
>
>
>
>
> *lift(a -> togglebuttons(["Landau" => ( (n,m) ->
> one(Complex{Float64}), (n,m) -> one(Complex{Float64}),
> (n,m) -> exp(-im*2π*a*m), (n,m) -> exp(im*2π*a*m) ),
> "Symmetric" => ((n,m) -> exp(-im*π*a*n), (n,m) ->
> exp(im*π*a*n),(n,m) -> exp(-im*π*a*m), (n,m) ->
> exp(im*π*a*m))], signal=ft), α)*
>
> So I would like to initialize *ft* beforehand with, say, the first value
> in my Dict, the one under the key "Landau", but this depends on the value
> of the signal *α.*
> On Tuesday, March 24, 2015 at 3:43:04 PM UTC+1, Shashi Gowda wrote:
>>
>> Not a bug, if you are passing in your own input signal to widgets, you
>> need to take care of maintaining the right initial values. It's also better
>> to use OrderedDict from DataStructures package here to keep the ordering of
>> the key-value pairs.
>>
>>
>>
>> On Tue, Mar 24, 2015 at 7:39 PM, Andrei Berceanu 
>> wrote:
>>
>>> Consider the following code
>>>
>>>
>>>
>>>
>>>
>>>
>>> *using Reactive, Interactα = Input(0)togglebuttons(["one" => 1, "two" =>
>>> 2], signal=α)signal(α)*I would expect the value of *α *to change after
>>> executing the *togglebuttons*(..) line, however this is not the case.
>>> *signal(α) *on the next line shows that *α *is still 0, even though one
>>> of the buttons is pre-selected. One has to press the buttons at least once
>>> to change the value of *α*.
>>> Can this behaviour be changed? Is it a bug?
>>>
>>
>>

Re: [julia-users] strange behaviour of togglebuttons in Interact.jl

[Shashi Gowda]

using Reactive, Interact, DataStructures
p = Input(3.);
α = @lift p/2;

m = @lift Input(α);
lift(a -> togglebuttons(OrderedDict(["one", "two"], [a,2a]), signal=m), α)

Here if you notice,

typeof(p) == Input{Float64}
typeof(α) == Input{Float64}
typeof(m) == Input{Input{Float64}}

But the `signal` keyword argument needs to be of type Input{Float64} since
the values held by the toggle buttons are Float64 numbers, and so it
crashes.

Now, I don't really understand what you are trying to do with the line m =
@lift Input(α). Could you tell me what the value of m should be according
to your problem be when you select "one" and "two" respectively, i.e in
terms of the value of p?



Now my hunch is that you are trying to do something like this:

Let me start from a vanilla togglebuttons connected to a signal m.


using Reactive, Interact, DataStructures

m = Input(1.0)
x = togglebuttons(OrderedDict(zip(["one", "two"], [1.0,2.0])), signal=m)
display(x)
display(m)

Now m contains either 1.0 or 2.0 depending on user's selection. I imagine
you want to multiply this number to another number taken from another
signal, say α, which you can do like this:

p = Input(3.0)
α = @lift p/2;

product = lift(*, α, m)

product  is now a signal that updates when *either* p or m updates and
holds the value: value(α) * value(m)


Another thing you might be trying to do is set the select one of the toggle
buttons when some other signal updates. Let us examine this.


toggled = Input(1.0)
the_other_signal =  # Some Float64 signal


x = lift(v -> togglebuttons(OrderedDict(zip(["one", "two"], [1.0,2.0])),
signal=toggled, value_label=v), the_other_signal)

display(x)


Now say you want a signal that updates when *either* the toggle buttons
update or the_other_signal updates, then you will need to merge these two
signals, because the toggle buttons will only update `toggled` if the user
deliberately clicks on it.

so, you would go


my_final_signal_phew = merge(toggled, the_other_signal)

Now you have everything you wanted: The toggle button will update in the
view when the_other_signal changes, and my_final_signal_phew will update
when either the user's selection changes or the_other_signal changes.

I hope that helps!

Re: [julia-users] Re: Julia Summer of Code

[Shashi Gowda]

A possible project on the UI side of things is expanding functionality in
Escher.jl (https://github.com/shashi/Escher.jl)

Escher is a work-in-progress declarative UI library which lets you make Web
UIs in pure Julia. It works well with Reactive.jl to allow you to create
interactive visualizations/dashboads.

There are 2 possible projects that are suitable for a 3-month period of
work.

1. Testing infrastructure and tests - this should involve using something
like Selenium
2. Expanding the library to include: spreadsheets, Table lens, and/or
anything else you think might be good to have in a Julia UI toolkit

If you are interested, let me know, we can do a hangout at a suitable time
and I will give you an overview of the package. It will be great if others
can spread the word about this project if you have someone in mind who you
think can help out here, especially since there is not much time left.

@Brian, I don't understand what you mean by adding Elm-style FRP to
Jupyter. Currently any Reactive.jl Signal can be shown in a Jupyter
notebook and it will be re-rendered on update.

On Thu, May 28, 2015 at 11:23 AM, Viral Shah  wrote:

> Please do ask everyone who is interested in participating to send their
> project description and mentors also to julia...@googlegroups.com
>
> The last date is June 1, after which we can take a call on how many
> proposals we have received and which ones to fund.
>
> -viral
>
> On Thu, May 28, 2015 at 10:16 AM, Jiahao Chen  wrote:
>
>> Reposting from a question I got offline:
>>
>> IterativeSolvers.jl implements a basic GKL SVD, but it has not been
>> tested for performance with distributed arrays. The project I have in mind
>> will consist of benchmarking and rewriting any necessary parts for speed.
>> Most of the work I foresee coming from improving the speed of parallel
>> matrix-vector products, and particularly implementing linear algebra
>> operations for sparse distributed matrices, which don't exist right now.
>>
>> There are also questions of how to deal with numerical stability issues
>> and reorthogonalization, and how to design an implementation that allows
>> users fine-grained control of reorthogonalization for speed-accuracy
>> tradeoffs.
>>
>> Thanks,
>>
>> Jiahao Chen
>> Research Scientist
>> MIT CSAIL
>>
>>
>> Thanks,
>>
>> Jiahao Chen
>> Research Scientist
>> MIT CSAIL
>>
>> On Thu, May 28, 2015 at 11:43 AM, Jiahao Chen  wrote:
>>
>>> I'd be happy to mentor someone working on parallel linear algebra. The
>>> simplest thing to do that will have very high impact is to implement high
>>> performance iterative (Golub-Kahan-Lanczos) SVD, similar to what is
>>> implemented in PROPACK. I'm also interested in a randomized SVD version
>>> similar to what is described in Halko, Martinsson and Tropp,
>>> doi:10.1137/090771806.
>>>
>>> I'm sure there are plenty of ODE projects around, but I would like to
>>> see someone take up the implementation of geometric integrators in ODE.jl.
>>>
>>> Thanks,
>>>
>>> Jiahao Chen
>>> Research Scientist
>>> MIT CSAIL
>>>
>>
>>
>
>
> --
> -viral
>

Re: [julia-users] IJulia is much slower than Julia just in terminal

[Shashi Gowda]

On Sun, Sep 28, 2014 at 2:41 PM,  wrote:
> I found IJulia is much slower than Julia just in terminal, is that normal?
In what sense exactly? It's normal that you find the interactions slow,
because there are hoops each of your input has to go through to get
evaluated by IJulia and come back as output. Did you time a particular
expression (e.g. using @time) in both places and found that it's slower on
the notebook? That would be a bug.


> Also, the interrupt key just restart Julia kernel rather than Ctrl-C it.
> Is it normal?
>
Yes, this is the intended behavior of the interrupt button. It only stops
the kernel for the current notebook.


> Or, do the IPython or IJulia in my server have some problem?
>
No.

[julia-users] typejoin and other expressions in super type parameter

[Shashi Gowda]

Consider:

julia> abstract A{T}

julia> type B{X, Y} <: A{typejoin(X, Y)}
  x::X
  y::Y
   end

julia> super(typeof(B(1, "a")))
A{ASCIIString}

julia> super(typeof(B("a", 1)))
A{Int64}

Which is odd.

And,
julia> type C{X} <: A{super(X)}
 x::X
   end
ERROR: `super` has no method matching super(::Type{X})

Which I could not understand, X seems to be treated as something that
exists when the type declaration is interpreted...

How does Julia deal with expressions in place of super type parameters?

If possible, I would like to dispatch on the typejoin of `X` and `Y` in
`B{X, Y}`. How can I do this?

Thanks,
Shashi

Re: [julia-users] Re: ANN: FactCheck v0.2

[Shashi Gowda]

+1000

I love this package.

On Thu, Nov 6, 2014 at 5:48 AM,  wrote:

> That's is really really exciting!
>
> I think, write code let me understand things, and test let me know the
> code!
>
>
> Iain Dunning於 2014年11月6日星期四UTC+8上午1時35分11秒寫道：
>
>> Hi all,
>>
>> I've just tagged FactCheck.jl v0.2 in METADATA.
>>
>> FactCheck was started by Zach Allaun a long long time ago in Julia terms
>> (March 2013), and was one of (if not the) first testing package for Julia.
>> Julia has managed to accumulate a large number of testing packages, but
>> none are as widely used as FactCheck.
>> However, it wasn't actively maintained anymore.
>> For that reason, we have moved FactCheck to the JuliaLang org on Github,
>> and I've refactored it a bit and even added some new features.
>> The last pre-move, pre-refactor release was 0.1.2, and I'll bump to 0.3.x
>> when new features are added.
>>
>> NEWS.md, for the FactCheck 0.2 release
>>
>> * NEW: Custom test messages, e.g. `@fact 1=>2 "two != one"`
>> * NEW: Added a compact mode, enable with `FactCheck.setstyle(:compact)`
>> * NEW: Added a `@pending` test type that is a no-op but records its 
>> existence.
>> * CHANGE: Minimum Julia version bumped to 0.3
>> * CHANGE: Colored output handled by Julia itself - to get colored output run 
>> with `julia --color`.
>> * CHANGE: `exitstatus` no longer exits Julia, instead throws an uncaught 
>> exception.
>> * REMOVED: `irrelevant` assertion helper.
>> * REMOVED: `@runtest` macro - was partially broken anyway.
>> * Re-written README. Simpler, explains all features, builds up incrementally 
>> to more advanced options.
>> * General refactoring of code base.
>>
>>
>> I hope this encourages wider use of FactCheck, and as more people use it, 
>> I'm sure more feature requests/issues/PRs will come in and make it better 
>> for everyone.
>>
>>
>> Finally, I don't want to say "don't make new testing packages" because there 
>> are different styles of testing.
>>
>> *But*: I'd strongly encourage people to contribute to making FactCheck 
>> better rather than starting their own.
>>
>>
>> Thanks,
>>
>> Iain
>>
>>

Re: [julia-users] Re: Full blown GUI programming with Julia+JS

[Shashi Gowda]

On Thu, Nov 6, 2014 at 6:58 PM, Job van der Zwan 
wrote:

> On Wednesday, 5 November 2014 18:16:18 UTC+1, Viral Shah wrote:
>>
>> SVG document
>>
>
> Wait, does that mean that the best browser for this is a recent version of 
> *Internet
> Explorer?!*
>
> At least, last time I checked (admittedly, quite a while ago) it had the
> best SVG support and performance.
>

What's best is relative ;-) I personally haven't used IE in years, so I
wouldn't know. This was tested on Chrome, it it works great. WebKit has
great SVG support.

Re: [julia-users] Full blown GUI programming with Julia+JS

[Shashi Gowda]

In light of what Patchwork can do, and staying future proof, I am more
concerned about Web Components support, which IE seems to be still
"considering" http://jonrimmer.github.io/are-we-componentized-yet/

More on web components here:
http://css-tricks.com/modular-future-web-components/

On Fri, Nov 7, 2014 at 8:19 PM, Job van der Zwan 
wrote:

> What's best is relative ;-) I personally haven't used IE in years, so I
>> wouldn't know.
>>
> Of course ;). For the record, neither have I (which would explain my
> outdated info, see below)
>
> On Thursday, 6 November 2014 20:23:46 UTC+1, Jameson wrote:
>>
>> Completely OT and [citation needed]. However, fwiw, IE didn't add SVG
>> support until IE9
>>
>
> Sorry, sorry. I was just joking because I remember IE being the first to
> support hardware accelerated SVG and surprising everyone by beating the
> other browsers in this department [0]. My own tests at the time had similar
> results. But that was a lot of versions ago, if I run some more recent
> benchmarks[1][2], they're much closer. On Windows, that is -IIRC Firefox
> doesn't have hardware acceleration on Linux yet, for example.
>
> Anyway, the only real issue seems to be that SVG still still doesn't scale
> very well[3] (in terms of elements, not resolution of course), so as long
> as you don't have too many GUI elements it shouldn't matter much.
>
> [0]
> http://joeloughton.com/blog/web-applications/svg-vs-canvas-performance/
> [1] http://jsperf.com/html-vs-svg-vs-canvas/26 (FF beats Chrome beats IE
> on my machine)
> [2] https://www.mapbox.com/osmdev/2012/11/20/getting-serious-about-svg/ -
> (check the unrounded/rounded performance links, Chrome beats IE beats FF on
> my machine)
> [3] http://frozeman.de/blog/2013/08/why-is-svg-so-slow/
>

Re: [julia-users] JuliaBox

[Shashi Gowda]

Hello David,

Sorry about that. You can use the invite code G01014. How many others do
you want to invite? A handful should be fine. Just do not publish it online.

Thank you

On Tue, Nov 11, 2014 at 12:15 AM, David Higgins 
wrote:

> Hi,
>
> Does anyone if JuliaBox  is open to applications
> to use it these days? I came across it in the ArXiV paper about Julia
> mentioned here
> .
> I'm a current Julia user but I have a number of colleagues who would be
> interested in a sandboxed, non-install version to play with before making
> the jump to installation. I made the mistake of suggesting JuliaBox before
> verifying that it was possible to create an account, it seems it's invite
> only for now.
>
> Thanks,
> Dave.
>

Re: [julia-users] JuliaBox

[Shashi Gowda]

On Tue, Nov 11, 2014 at 1:01 AM, Shashi Gowda 
wrote:

>
> Just do not publish it online.
>

Oops I meant to send it to David directly. If anyone else wants a code,
please let me know.

Re: [julia-users] JuliaBox

[Shashi Gowda]

Sure :) Happy to let them in.

On Tue, Nov 11, 2014 at 1:02 AM, David Higgins 
wrote:

> Thanks Ivar.
>
> 5 people Shashi, all academics so I'd like to get them interested.
>
> Dave.
>
> On Monday, 10 November 2014 19:31:17 UTC, Shashi Gowda wrote:
>>
>> Hello David,
>>
>> Sorry about that. You can use the invite code G01014. How many others do
>> you want to invite? A handful should be fine. Just do not publish it online.
>>
>> Thank you
>>
>> On Tue, Nov 11, 2014 at 12:15 AM, David Higgins 
>> wrote:
>>
>>> Hi,
>>>
>>> Does anyone if JuliaBox <http://www.juliabox.org> is open to
>>> applications to use it these days? I came across it in the ArXiV paper
>>> about Julia mentioned here
>>> <https://groups.google.com/d/msg/julia-users/DtjfcslGcMw/s-QBbFnelugJ>.
>>> I'm a current Julia user but I have a number of colleagues who would be
>>> interested in a sandboxed, non-install version to play with before making
>>> the jump to installation. I made the mistake of suggesting JuliaBox before
>>> verifying that it was possible to create an account, it seems it's invite
>>> only for now.
>>>
>>> Thanks,
>>> Dave.
>>>
>>
>>

Re: [julia-users] Re: JuliaBox

[Shashi Gowda]

No you won't have sudo access since that may lead to a broken container.
You can however compile programs in your home directory which will persist
across sessions. If you require some package that might be generally useful
to others as well do open an issue at github.com/JuliaLang/JuliaBox

Regards

On Fri, 14 Nov 2014 20:36 Erik Schnetter  wrote:

> On Thu, Nov 13, 2014 at 11:25 PM, Viral Shah  wrote:
> > Basically, JuliaBox gives you hosted IJulia and a persistent filesystem.
> So,
> > you are not restricted to your local device. There is also a shell and
> > ability to sync Google Drive and Github repos, or simply upload your
> files,
> > install packages, etc.
>
> Can I install packages with sudo (if so, what's the password), or
> should I do this in my home directory there?
>
> -erik
>
> --
> Erik Schnetter 
> http://www.perimeterinstitute.ca/personal/eschnetter/
>

Re: [julia-users] Reviewing a Julia programming book for Packt

[Shashi Gowda]

I got this request too. Not going to reply. I wonder who is writing it.

On Sat, Dec 6, 2014 at 4:58 AM,  wrote:

> Have had the same problem with other open source projects I participate
> in, they spam anybody prominent on the ML or github.
>
> The resulting books seem to contain large parts consisting of the projects
> manuals, often verbatim.
>
> Cheers
> Lex
>
> On Saturday, December 6, 2014 3:45:19 AM UTC+10, Stefan Karpinski wrote:
>>
>> Yes, as the contact has been so relentlessly spammy, I've started to
>> treat it as spam.
>>
>> On Fri, Dec 5, 2014 at 12:23 PM, Iain Dunning  wrote:
>>
>>> I also refused to review for them, both in this new wave of spam and the
>>> previous one, on the basis that I don't think such a book should exist
>>> (yet). I also felt that by being a reviewer, I'm authorizing the use of my
>>> name for a product I have no control over (they can just ignore what you
>>> say). They seem like a bunch of crooks to be honest.
>>
>>
>>

Re: [julia-users] ijulia with multiple versions

[Shashi Gowda]

In fact there is a way to do this.

Just go to the REPL with the Julia version you want to switch to and run
Pkg.build("IJulia"). This replaces the julia profile files in ~/.ipython to
use the right Julia executable.

Re: [julia-users] Gadfly in userimg.jl

[Shashi Gowda]

@Joshua, if you do Pkg.update() and get the latest Gadfly, you should be
able to precompile it.


Homebrew.jl had a new release 5 hours ago as well, did you try updating? We
were getting the UndefVarError(var=:STDERR) with Compose, this happens when
the code you are loading wants to print an error message (I think). Does
`using HDF5` work for you if you build without precompiling? You should not
have any load time errors for this to work.

I was able to fix Compose precompilation problem by accounting for the
error case
https://github.com/JuliaLang/JuliaBox/issues/123#issuecomment-67187273

On Wed, Dec 17, 2014 at 7:58 AM, Tim Holy  wrote:
>
> If you'd like some help fixing this, please open an issue over at HDF5.jl.
> If
> you do, please be explicit about the commands you're executing that lead to
> such error messages.
>
> --Tim
>
> On Tuesday, December 16, 2014 11:12:58 AM Joshua Job wrote:
> > I'm on Mac OS X, but I get an error from HDF5 calling/pulling in the
> > Homebrew package with
> >
> > > error during bootstrap: LoadError(at "sysimg.jl" line 286: LoadError(at
> > > "/Users/joshuajob/julia-0.3/base/userimg.jl" line 1: LoadError(at
> > > "/Users/joshuajob/.julia/v0.3/HDF5/src/HDF5.jl" line 1: LoadError(at
> > > "/Users/joshuajob/.julia/v0.3/HDF5/src/plain.jl" line 14: LoadError(at
> > > "/Users/joshuajob/.julia/v0.3/Homebrew/src/Homebrew.jl" line 345:
> > > UndefVarError(var=:STDERR))
> >
> >  It probably would work fine if I was on Linux.
> >
> > On Friday, December 12, 2014 11:21:39 PM UTC-5, Tim Holy wrote:
> > > HDF5 _should_ work---I just put in a bunch of work to fix some problems
> > > that
> > > were preventing precompilation. But, you must be using HDF5 0.4.7 (or
> > > master).
> > >
> > > --Tim
> > >
> > > On Friday, December 12, 2014 06:47:55 PM Joshua Job wrote:
> > > > Hello all,
> > > >
> > > > Is there anyone else who has attempted to precompile Gadfly using
> > > > userimg.jl? It keeps claiming that the variable STD_ variables
> > > > (STDIN,STDOUT,STDERR) are not defined, and this seems to be a pretty
> > > > common/general issue (it also comes up when trying to precompile
> HDF5,
> > > > etc.). I've pulled the load time on Gadfly down to about 15 seconds
> by
> > > > precompiling DataFrames, but it'd be really nice if I could just put
> > >
> > > "using
> > >
> > > > My,Most,Used,Packages" unto my juliarc.jl file and not have a solid
> 30
> > > > second startup time for a new instance of Julia.
> > > >
> > > > I'm wondering if a) is this an issue only I have and b) if not, is
> there
> > > > some way to make it so the STD_ variables are all defined prior to
> > > > running/compiling userimg.jl?
>
>

Re: [julia-users] [ANN] Blink.jl – Web-based GUIs for Julia

[Shashi Gowda]

I love the display system

in Blink. This makes much more sense than the current display stack
mechanism. First, it lets you show things on different (even multiple)
displays. Second, classification of output as Tabular, Graphical and
Textual (and finer classifications) is really useful, something the current
display stack based mechanism lacks.

Very much for moving it into Base!

On Tue, Jan 6, 2015 at 2:00 AM, Mike Innes  wrote:

> The writemime methods and the display system are largely orthogonal – the
> display system concerns itself with routing output to a suitable display
> device (terminal, Blink window, whatever) while writemime simply provides
> the implementation. In other words, I'm only really focused on the
> `display` function, and that work looks completely compatible with my
> proposed changes.
>
> On 5 January 2015 at 19:41, Ivar Nesje  wrote:
>
>> Have you seen https://github.com/JuliaLang/julia/pull/8987?
>>
>>
>

Re: [julia-users] Re: GSoC 2016 - Simple persistent distributed storage Project

[Shashi Gowda]

Hello,

I think ComputeFramework is not a good starting point for this project,
it's meant to be used for computing on large matrices and such. Amit (cc'd
here) has thought about distributed dictionaries and will have more inputs
on your project.

I would say you should start by listing the features you would like to have
in such a package and then figuring out some implementation plan. You
should look at the documentation on the parallel computing primitives in
Julia http://docs.julialang.org/en/latest/manual/parallel-computing/ since
it's likely you will use them as the basic building blocks.

Thanks

On Sat, Mar 19, 2016 at 10:03 PM, Mike Innes  wrote:

> For something ComputeFramework related, it's likely that Shashi Gowda
> would be interested in mentoring. You could try opening issues for queries
> as well. We're flexible about mentoring if you have someone in mind, but in
> general we'll try to match proposals with people who are known to the
> community.
>
> On Fri, 18 Mar 2016 at 12:47 Soujanya Ponnpalli <
> soujanya.ponnapa...@gmail.com> wrote:
>
>> Hello!
>>
>> I've started taking a look at the package ComputeFramework.jl. I have a
>> few queries and would want some information regarding them.
>>
>> Could you tell me how I could get in touch with potential mentors for
>> this project? Is it the case that there are a few fixed mentors amongst
>> which one shall get convinced to mentor me, or is it that anyone with
>> domain specific knowledge and experience in Julia can mentor me on this
>> project?
>>
>> Looking forward to hear from you,
>> Soujanya Ponnapalli.
>>
>> On Sun, Mar 13, 2016 at 11:06 PM, Mike Innes 
>> wrote:
>>
>>> Hey Soujanya,
>>>
>>> Glad to have your interest! I don't know a lot about this project
>>> personally, but you might be interested to take a look at the recent work
>>> on ComputeFramework.jl <https://github.com/shashi/ComputeFramework.jl>,
>>> which is in a similar area. Getting stuck in over there would be a great
>>> way to meet potential mentors and get a hard start on the project.
>>>
>>> Cheers,
>>> Mike
>>>
>>> On Friday, 11 March 2016 14:35:06 UTC, Soujanya Ponnpalli wrote:
>>>>
>>>> Hello!
>>>>
>>>> I am Soujanya Ponnapalli, a junior at International Institute of
>>>> Information Technology, Hyderabad (IIIT-H), majoring in Computer Science
>>>> and Engineering (CSE). I got introduced to Julia at International
>>>> Parallel and Distributed Processing Symposium - IPDPS 2015 and was
>>>> taken aback by the features of Julia like performance efficiency, parallel
>>>> and distributed computation support.
>>>>
>>>> I would rate my competency level in C++, Java and Python as
>>>> intermediate and getting my hands on Julia. I would like to contribute to
>>>> the project " Simple persistent distributed storage" as I'm interested
>>>> in Distributed Systems. My experience in this field includes,
>>>> implementing a file system similar to HDFS in java.
>>>>
>>>> I would be thankful if I could get some information regarding,
>>>> 1. What is expected from your side, in context to this project?
>>>> 2. How do I contact the mentors and get involved in the project
>>>> discussions?
>>>>
>>>> Regards,
>>>> Soujanya Ponnapalli.
>>>>
>>>>
>>

Re: [julia-users] Converting hex ints

[Shashi Gowda]

You can use reinterpret. It's fast!

julia> a = [UInt8(i) for i=1:4]
4-element Array{UInt8,1}:
 0x01
 0x02
 0x03
 0x04

julia> reinterpret(UInt32, a)
1-element Array{UInt32,1}:
 0x04030201


On Wed, Apr 27, 2016 at 11:05 PM, Achu  wrote:

> Hi
>
> I'm trying to read a data stream off a server for our motion capture
> system. The protocol
> says that
> the first four bytes represent the size of the whole packet and I can read
> that using readbytes(). To convert four UInt8s into one UInt32, I'm
> using
> s=bytes2hex(a) #where a is a Vector UInt8, 4
> parse(UInt32,"0x"*s)
>
> Is there a better way to do this?
>
> Thanks!
> Achu
>

Re: [julia-users] Converting hex ints

[Shashi Gowda]

Oh yes, I was just going to say that's a better way.

On Wed, Apr 27, 2016 at 11:12 PM, Stefan Karpinski 
wrote:

> read(io, UInt32). Depending on the endianness of the data stream, you may
> or may not need to call ntoh on that.
>
> On Wed, Apr 27, 2016 at 1:35 PM, Achu  wrote:
>
>> Hi
>>
>> I'm trying to read a data stream off a server for our motion capture
>> system. The protocol
>> says that
>> the first four bytes represent the size of the whole packet and I can read
>> that using readbytes(). To convert four UInt8s into one UInt32, I'm
>> using
>> s=bytes2hex(a) #where a is a Vector UInt8, 4
>> parse(UInt32,"0x"*s)
>>
>> Is there a better way to do this?
>>
>> Thanks!
>> Achu
>>
>
>

Re: [julia-users] Reactive.jl toy example problem

[Shashi Gowda]

This is definitely a bug... I'll look into fixing it. Thanks!

Re: [julia-users] Re: Compose.jl drawing in IJulia

[Shashi Gowda]

The diameter of a circle without a specified radius is taken to be the
width of the context iirc. The default width of the drawing surface is
greater than its height, resulting in the clipping of some part of the
circle.

Making the drawing surface a square will show it properly. You can do this
by running:

Compose.set_default_graphic_size(10inch, 10inch)

before you draw anything else.

On Tue, May 3, 2016 at 5:57 PM, Christoph Ortner  wrote:

>
> Here is an Python output
>
>
>
> 
>
>
> here is the PNG file:
>
>
>
> 
>
>
> but this is not the only problem I get, sometimes I see the whole image,
> but it is deformed. I couldn't reproduce that on a simple example though.
>
>
> Christoph
>
>
> On Tuesday, 3 May 2016 13:08:23 UTC+1, Andreas Lobinger wrote:
>>
>> Hello colleague,
>>
>> how did you set the correct dimensions?
>>
>> On Tuesday, May 3, 2016 at 10:53:59 AM UTC+2, Christoph Ortner wrote:
>>>
>>> If I create a context using `compose`, and then call  `display(ctx)`,
>>> then I end up with an image that looks roughly right but doesn't have the
>>> correct dimensions.
>>>
>>> How can I fix it?
>>>
>>> Thanks,
>>>Christoph
>>>
>>>

Re: [julia-users] Re: Compose.jl drawing in IJulia

[Shashi Gowda]

Yes, you can use draw for that

draw(SVG(10inch, 10inch), ...your compose context here...)

you can also change SVG to PNG in IJulia - recommended if there are too
many objects in the image

On Tue, May 3, 2016 at 10:28 PM, Christoph Ortner <
christophortn...@gmail.com> wrote:

> Thank you - can I also specify the dimensions of the image on a case by
> case basis?
>
> Christoph
>
>
> On Tuesday, 3 May 2016 15:43:41 UTC+1, Shashi Gowda wrote:
>>
>> The diameter of a circle without a specified radius is taken to be the
>> width of the context iirc. The default width of the drawing surface is
>> greater than its height, resulting in the clipping of some part of the
>> circle.
>>
>> Making the drawing surface a square will show it properly. You can do
>> this by running:
>>
>> Compose.set_default_graphic_size(10inch, 10inch)
>>
>> before you draw anything else.
>>
>> On Tue, May 3, 2016 at 5:57 PM, Christoph Ortner 
>> wrote:
>>
>>>
>>> Here is an Python output
>>>
>>>
>>>
>>> <https://lh3.googleusercontent.com/-p4LCQ_xf5pI/VyiY7I-WdcI/BvM/fh0Ra6-V5Wkf-QEXzKF5bJXm7a3XVUaDwCLcB/s1600/Screen%2BShot%2B2016-05-03%2Bat%2B13.25.51.png>
>>>
>>>
>>> here is the PNG file:
>>>
>>>
>>>
>>> <https://lh3.googleusercontent.com/-gRmUGFJEX8s/VyiYyV1D-nI/BvI/hGz_tJ8_glsX2M5Mq1Xh9KsLt3ULrg_QQCLcB/s1600/temp.png>
>>>
>>>
>>> but this is not the only problem I get, sometimes I see the whole image,
>>> but it is deformed. I couldn't reproduce that on a simple example though.
>>>
>>>
>>> Christoph
>>>
>>>
>>> On Tuesday, 3 May 2016 13:08:23 UTC+1, Andreas Lobinger wrote:
>>>>
>>>> Hello colleague,
>>>>
>>>> how did you set the correct dimensions?
>>>>
>>>> On Tuesday, May 3, 2016 at 10:53:59 AM UTC+2, Christoph Ortner wrote:
>>>>>
>>>>> If I create a context using `compose`, and then call  `display(ctx)`,
>>>>> then I end up with an image that looks roughly right but doesn't have the
>>>>> correct dimensions.
>>>>>
>>>>> How can I fix it?
>>>>>
>>>>> Thanks,
>>>>>Christoph
>>>>>
>>>>>
>>

Re: [julia-users] Reactive.jl - Resetting an accumulator

[Shashi Gowda]

This is a commonly recurring pattern. Here is a walk through of a nice
solution to this:

*Step 1. Create the types to give richer meaning to updates*

abstract Action# optional
immutable Update <: Action
   val
end
immutable Reset <: Action end

# ... many more such action types can be added as and when required...


*Step 2. Define an combine function which does the right thing given
different kinds of updates*

combine(prev, u::Update) = max(prev, u.val)
combine(prev, ::Reset) = 0.0

# ... can add more as you create Action types


*Step 3. Merge signals of actions*

You will need to create a single source of Signal{Action} using merge

Say you have a reset_btn_clicks (probably coming from a button labeled
"Reset"), you can merge them

updates = map(Update, x)
resets = map(_ -> Reset, reset_btn_clicks)

actions = merge(updates, resets)


*Step 4. use foldp*

peak_x = foldp(combine, actions)


now display/plot peak_x.

The benefit of this approach is it is extensible and makes your code easy
to understand. You can add functionality by simply defining new Action
type, a combine method to update previous state, and finally adding it to
the merged signal of actions.


On Wed, May 4, 2016 at 10:18 PM, Achu  wrote:

> Hi
>
> I have a signal x Signal{Float64} and I have this other signal that
> defined by peak_x=foldp(max,0.0,x). Is there a way for me to reinitialize 
> peak_x
> back to 0?
>
> Thanks!
> Achu
>

Re: [julia-users] Re: Compose.jl animation

[Shashi Gowda]

You can create animations with Interact.jl and Compose.jl using IJulia (not
any REPL). For more info on how to do this, see Interact.jl example
notebook on animation
.
If you want to create gifs or videos of the animation from the REPL, then
you should give Reel.jl  a go.
On 09-Jun-2016 6:09 AM, "Cedric St-Jean"  wrote:

This may not satisfy your needs, but I do Compose.jl animations in IJulia
with IJulia.clear_output.

for i in 1:10
IJulia.clear_output(true)
draw(SVGJS(100mm, 100mm),  compose(context(0.001,0.001,1,1),circle(1,1,
i/10)))
sleep(1)
end

I believe that you could also do it at the REPL by writing a .gif (I think
Plots.jl does that) and displaying it somehow, but I can't help you there...


On Wednesday, June 8, 2016 at 5:10:32 PM UTC-4, Ford O. wrote:
>
> Is it actually possible to create animations with Compoe or do I have to
> pick another library?

Re: [julia-users] Re: Compose.jl animation

[Shashi Gowda]

Yes, this is because the canvas is not square

Run
Compose.set_default_graphic_size(5inch, 5inch)

Before drawing the picture...

On 11-Jun-2016 8:08 PM, "Michael Borregaard"  wrote:
>
> It is not a full answer, but you should check ctxpromise() for the size.
I think the distribution is because the canvas is not square and you use
relative positions to specify circle centers. You can set the size
parameters in the context call. Sorry I realise this is really useless in
terms of help but may point you in the right direction.

Re: [julia-users] Re: Compose.jl animation

[Shashi Gowda]

using ComposeDiff should help...

The memory leak happens on the browser when you redraw the compose
graphic...

On Fri, Jun 17, 2016 at 6:05 PM, Ford O.  wrote:

> So I have found the source of memory leak:
>
> using Interact, Reactive, Compose
>
> @manipulate for frame = fps(300)
> compose(context(), rectangle(), fill("grey"))
> end
>
> But still don't know how to fix it.
>

Re: [julia-users] Adding tuples

[Shashi Gowda]

Base.:+{N}(a::NTuple{N}, b::NTuple{N}) = ntuple(i -> a[i] + b[i], Val{N})

should be slightly faster and should not allocate unlike

Base.:+{N}(a::NTuple{N}, b::NTuple{N}) = ntuple(i -> a[i] + b[i], N)


On Wed, Aug 10, 2016 at 8:36 PM, 'Bill Hart' via julia-users <
julia-users@googlegroups.com> wrote:

> This code seems to be (about 50%) faster than recursive functions:
>
> Base.:+{N}(a::NTuple{N}, b::NTuple{N}) = ntuple(i -> a[i] + b[i], N)
>
>
> But this seems (about 50%) slower:
>
>  ((a[i] + b[i] for i = 1:N)...)
>
>
> Anyway, I can use the first method, until I find something faster. It's
> definitely way more convenient. Thanks.
>
> Bill.
>
>
>
> On 10 August 2016 at 16:56, Erik Schnetter  wrote:
>
>> The built-in type `CartesianIndex` supports adding and subtracting, and
>> presumably also multiplication. It is implemented very efficiently, based
>> on tuples.
>>
>> Otherwise, to generate efficient code, you might have to make use of
>> "generated functions". These are similar to macros, but they know about the
>> types upon which they act, and thus know the value of `N`. This is a bit
>> low-level, so I'd use this only if (a) there is not other package
>> available, and (b) you have examined Julia's performance and found it
>> lacking.
>>
>> I would avoid overloading operators for `NTuple`, and instead us a new
>> immutable type, since overloading operations for Julia's tuples can have
>> unintended side effects.
>>
>> -erik
>>
>>
>> On Wed, Aug 10, 2016 at 9:57 AM, 'Bill Hart' via julia-users <
>> julia-users@googlegroups.com> wrote:
>>
>>> Does anyone know an efficient way to add NTuples in Julia?
>>>
>>> I can do it using recursive functions, but for various reasons this is
>>> not efficient in my context. I really miss something like tuple(a[i] + b[i]
>>> for i in 1:N) to create the resulting tuple all in one go (here a and b
>>> would be tuples).
>>>
>>> The compiler doesn't do badly with recursive functions for handling
>>> tuples in very straightforward situations, but for example, if I want to
>>> create an immutable type based on a tuple the compiler doesn't seem to be
>>> able to handle the necessary optimisations. At least, that is what I infer
>>> from the timings. Consider
>>>
>>> immutable bill{N}
>>>d::NTuple{N, Int}
>>> end
>>>
>>> and I want to add two bill's together. If I have to add the tuples
>>> themselves using recursive functions, then I no longer seem to be able to
>>> do something like:
>>>
>>> A[i] = B[i] + C[i] efficiently, where A, B and C are arrays whose
>>> elements are of type bill.
>>>
>>> I know how to handle tuples via arrays, but for efficiency reasons I
>>> certainly don't want to do that, e.g. tuple([a[i] + b[i] for i in 1:N]...).
>>>
>>> Bill.
>>>
>>
>>
>>
>> --
>> Erik Schnetter  http://www.perimeterinstitute.
>> ca/personal/eschnetter/
>>
>
>

Re: [julia-users] Prevent Escher from evaluating signals on start

[Shashi Gowda]

You can pass in an init=empty keyword argument to lift / consume, and the
initial value of the signal will be an empty UI. The actual value will be
computed next time the input signal udpates. You should also provide a
typ=Any kwarg to lift / consume so that if you replace empty with something
that is not Empty, you do not get a type conversion error. something like:

selected_tab = Input(1)
vbox(
tabs(["a", "b"]) >>> selected_tab,
lift(selected_tab, typ=Any, init=empty) do page_no
// compute page at page_no
end
)

may be what you need. To avoid recomputing when you switch to tab 1 and
then to tab 2 and then back to tab 1, you will need to memoize the function
you pass to lift...


On Wed, Oct 14, 2015 at 6:06 PM, Yakir Gagnon <12.ya...@gmail.com> wrote:

> Title...
> I have a bunch of tabs and it all takes time to load. I don't need the
> functions to evaluate before the user presses on something. Any easy way i
> can prevent all the signals from running their functions when the pages
> load up?

Re: [julia-users] Escher image update

[Shashi Gowda]

This is browser caching at work

one way to resolve this is to just imread the image instead of loading it
using image() which just creates the equivalent of an  HTML tag...

e.g.

using Images

run(`convert a.jpg  assets/a.jpg`)
imread("assets/a.jpg")


On Wed, Oct 14, 2015 at 3:52 AM, Yakir Gagnon <12.ya...@gmail.com> wrote:

>
>
> I have some widgets that run imagemagick updating images in `assets/`, and
> the only way I can get those to update with `image` is to change their
> names...
> So if I just do this:
> ```julia
> run(`convert a.jpg  assets/a.jpg`)
> image("assets/a.jpg")
> ```
> the image doesn't get updated. But this craziness works:
> ```julia
> name = rand(Int)
> run(`convert a.jpg  assets/$name.jpg`)
> image("assets/$name.jpg")
> ```
> Isn't there a better way?
>

Re: [julia-users] Escher image update

[Shashi Gowda]

Sorry the problem is actually not even browser caching... what happens is
Escher thinks there is nothing to update because the URL attribute remains
the same...

imread is a good solution although slower. Another good solution is the one
you yourself gave if you can figure out a way to clean up all the temporary
files it creates.

On Wed, Oct 14, 2015 at 10:19 PM, Shashi Gowda 
wrote:

> This is browser caching at work
>
> one way to resolve this is to just imread the image instead of loading it
> using image() which just creates the equivalent of an  HTML tag...
>
> e.g.
>
> using Images
>
> run(`convert a.jpg  assets/a.jpg`)
> imread("assets/a.jpg")
>
>
> On Wed, Oct 14, 2015 at 3:52 AM, Yakir Gagnon <12.ya...@gmail.com> wrote:
>
>>
>>
>> I have some widgets that run imagemagick updating images in `assets/`,
>> and the only way I can get those to update with `image` is to change their
>> names...
>> So if I just do this:
>> ```julia
>> run(`convert a.jpg  assets/a.jpg`)
>> image("assets/a.jpg")
>> ```
>> the image doesn't get updated. But this craziness works:
>> ```julia
>> name = rand(Int)
>> run(`convert a.jpg  assets/$name.jpg`)
>> image("assets/$name.jpg")
>> ```
>> Isn't there a better way?
>>
>
>

Re: [julia-users] Prevent Escher from evaluating signals on start

[Shashi Gowda]

Memoization means storing the result of a function and then using the
stored value when the function is called with the same arguments.

See https://github.com/simonster/Memoize.jl

On Thu, Oct 15, 2015 at 9:16 AM, Yakir Gagnon <12.ya...@gmail.com> wrote:

> Thanks Shashi,
> But while that prevents stuff in another tab from running before that
> other tab is in focus, stuff runs twice when that tab gets focused...!?
> Maybe that's what you meant with "you will need to memorize the function
> you pass to lift..." but in that case I don't understand what you mean.
>
> Thanks again for the awesome work!
>
>
> Yakir Gagnon
> The Queensland Brain Institute (Building #79)
> The University of Queensland
> Brisbane QLD 4072
> Australia
>
> cell +61 (0)424 393 332
> work +61 (0)733 654 089
>
> On Thu, Oct 15, 2015 at 2:46 AM, Shashi Gowda 
> wrote:
>
>> You can pass in an init=empty keyword argument to lift / consume, and
>> the initial value of the signal will be an empty UI. The actual value will
>> be computed next time the input signal udpates. You should also provide a
>> typ=Any kwarg to lift / consume so that if you replace empty with something
>> that is not Empty, you do not get a type conversion error. something like:
>>
>> selected_tab = Input(1)
>> vbox(
>> tabs(["a", "b"]) >>> selected_tab,
>> lift(selected_tab, typ=Any, init=empty) do page_no
>> // compute page at page_no
>> end
>> )
>>
>> may be what you need. To avoid recomputing when you switch to tab 1 and
>> then to tab 2 and then back to tab 1, you will need to memoize the function
>> you pass to lift...
>>
>>
>> On Wed, Oct 14, 2015 at 6:06 PM, Yakir Gagnon <12.ya...@gmail.com> wrote:
>>
>>> Title...
>>> I have a bunch of tabs and it all takes time to load. I don't need the
>>> functions to evaluate before the user presses on something. Any easy way i
>>> can prevent all the signals from running their functions when the pages
>>> load up?
>>
>>
>>
>

Re: [julia-users] Re: [Escher] lower and upper bound sliders automatically adjust not to intersect

[Shashi Gowda]

Hi Yakir,

you're right l will only update in response to user action.

how about using l′ = lift(min, u, l) instead of l?


On Wed, Nov 4, 2015 at 8:53 AM, Yakir Gagnon <12.ya...@gmail.com> wrote:

> OK, there is a problem with this:
> the new slider that gets created every time we update u doesn’t update l.
> l gets updated only after we try to change its subscribed slider, not
> before. This is problematic because I lifted l and u and if they’re
> overlapping then I get errors.
> I’ll get back to this…
>
> On Wednesday, November 4, 2015 at 11:43:08 AM UTC+10, Yakir Gagnon wrote:
>
> I thought others might find this useful:
>> Two sliders that don’t overlap. The second’s upper bound is automatically
>> adjusted so not to overlap with the first’s value.
>>
>> u = Input(100)
>> l = Input(0)
>> function main(window)
>> push!(window.assets, "widgets")
>>
>> vbox(slider(1:100, value = 100) >>> u,
>> consume(u) do x
>> slider(0:(x - 1), value = 0) >>> l
>> end
>> )
>> end
>>
>> ​
>>
> ​
>

Re: [julia-users] Escher show pdf file

[Shashi Gowda]

I assume you mean to embed a PDF viewer in your Escher page... This would
require wrapping something like pdf.js  and
shouldn't be hard to do. I'll open a github issue for this feature.


On Mon, Nov 2, 2015 at 2:37 PM, Yakir Gagnon <12.ya...@gmail.com> wrote:

> I guess this is for the future, but in case it’s easy and already here, I
> sure could use some kind of pdf viewing in Escher…
> So something like the image(path_to_image) -> tile from the Content API,
> only for a (local, in assets) pdf.
>
> Thanks for all the great work!
>
> A slow work around will be to (imagemagick) convert the pdf to an image
> first.
> ​
>

[julia-users] Re: Escher Spinner

[Shashi Gowda]

On Saturday, November 7, 2015 at 4:21:09 AM UTC+5:30, Brandon Miller wrote:
>
> Code snippet: https://gist.github.com/r2dbg/14189258e9daee2cece6
>
> I'd like for the spinner on line 23 to spin while do_work() is running and 
> stop after do_work returns.  However, I can't seem to find a good way to do 
> this.  The form is blocking until all fields in plugsampler() are fulfilled.
>

Take a look at how the mc.jl example does something similar: 
https://github.com/shashi/Escher.jl/blob/master/examples/mc.jl#L24-L35

I think a better abstraction is possible for this though. A way to make a 
busy-signal for another signal?

Re: [julia-users] Memory leak for animated plots

[Shashi Gowda]

If you install Patchwork.jl , and
re-run your notebook, it should fix this issue. (you might also need to
pre-compile Compose again - can be done by removing the .ji file in
~/.julia/lib/v0.4/)

Compose (which Gadfly uses for rendering to SVG) doesn't depend on
Patchwork, but if you have it installed, it will use the Patchwork backend
when you render a @manipulate of plots - Patchwork will then try to
reconcile previously rendered DOM nodes so that there are no performance
penalties of this sort.

On Fri, Nov 20, 2015 at 10:48 PM, Andrew Keller 
wrote:

> I think this is exactly what is happening. Some findings:
>
> 1) run the code:
>
> using Interact, Gadfly
>> @manipulate for φ=0:π/16:4π, f=[:sin => sin, :cos => cos]
>> plot((θ)->f(θ+φ),0,25)
>> end
>
>
> 2) Chrome dev tools--> Profiles--> heap snapshot.
> 3) Click sin, cos, sin, cos, sin, cos, ... sin in the notebook
> 4) Take another heap snapshot and look in comparison view.
>
> It looks like among other things there are a lot of SVGPathElements and
> SVGTextElements that belong to detached DOM trees, suggesting the old plots
> never get properly disposed. If I instead capture a JS profile in the
> Chrome dev tools-->Timeline panel, it appears like the number of nodes and
> listeners increases without bound.
>
> Now suppose I use Winston instead of Gadfly. The memory still appears to
> leak, although the plots are a little more lightweight and the leak is
> slower.
>
> Anyway, I'll submit an issue to the jupyter/notebook repo later today
> although I wish I could pin down better where exactly the leak is coming
> from.
>
> On Thursday, November 19, 2015 at 10:35:31 AM UTC-8, Keno Fischer wrote:
>>
>> Sounds like the memory leak is on the browser side? Maybe something is
>> keeping a javascript reference to the plot? Potentially a Jupyter/IJulia
>> bug?
>>
>> On Thu, Nov 19, 2015 at 12:01 PM, Stefan Karpinski 
>> wrote:
>>
>>> This should work – if there's a memory leak that's never reclaimed by
>>> gc, that's a bug.
>>>
>>> On Thu, Nov 19, 2015 at 11:55 AM, Andrew Keller 
>>> wrote:
>>>
 Maybe generating a new plot every time is not great practice, on
 account of the performance hit. That being said, I think it's perfectly
 legitimate to do what I'm doing for prototyping purposes. I can achieve the
 frame rate I want and the main example shown on
 https://github.com/JuliaLang/Interact.jl does the same thing I do,
 generating a new plot each time.

 In fact, I'd encourage anyone reading this to just try that example,
 and repeatedly click between sin and cos. I'm able to make the memory
 consumption of my browser grow without bound. Surely someone besides myself
 has noticed this before! I don't think loading another package is a serious
 solution to the problem I'm describing, although your package certainly
 looks useful for other purposes.

 Just to reiterate, this is not a small memory leak; this is like a
 memory dam breach. I'm happy to help debug this but some assistance would
 be appreciated.


 On Thursday, November 19, 2015 at 7:11:55 AM UTC-8, Tom Breloff wrote:
>
> You're creating a new Gadfly.Plot object every update, which is a bad
> idea even if Gadfly's memory management was perfect. Plots.jl gives you 
> the
> ability to add to or replace the underlying data like this:
>
> using Plots
> gadfly()
> getxy() = (1:10, rand(10))
> plt = plot(x, y)
>
> # overwrite underlying plot data without building a new plot
> plt[1] = getxy()
>
>
> You can also use familiar push! and append! calls.
>
> Let me know if this helps, and please post issues if you find bugs. Of
> course the memory issue could be while redisplaying in IJulia, in which
> case this method won't help.
>
> On Thursday, November 19, 2015, Andrew Keller 
> wrote:
>
>> I'd like to use Interact to have a plot that updates frequently in a
>> Jupyter notebook, but it seems like there is a large memory leak 
>> somewhere
>> and I am having some trouble tracking down what package is responsible.
>> Within a few minutes of running, the following code will cause the memory
>> used by the web browser to balloon to well over 1 GB with no sign of
>> slowing down. It is almost like the memory allocated for displaying a
>> particular plot is never deallocated:
>>
>> using Reactive, Interact, Gadfly
>>
>> @manipulate for
>>> paused=false,
>>> dt = fpswhen(lift(!, paused), 10)
>>> plot(x=collect(1:10),y=rand(10))
>>> end
>>
>>
>> I can observe this problem using Julia 0.4.1, together with the most
>> recent releases of all relevant packages, in either Safari on OS X or
>> Chrome on Windows 10.
>>
>> Here's hoping someone has an idea of what's going on or advice for
>> how to t

Re: [julia-users] Memory leak for animated plots

[Shashi Gowda]

> Anyway, I'll submit an issue to the jupyter/notebook repo later today
although I wish I could pin down better where exactly the leak is coming
from.

the updating mechanism in Interact doesn't use jupyter a whole lot. It
happens in these lines of code
<https://github.com/JuliaLang/Interact.jl/blob/17f8864b1ad65f3bdef532254fe06d86f60974ec/src/IJulia/ijulia.js#L28-L32>

the jQuery empty <http://api.jquery.com/empty/> doc says "To avoid memory
leaks, jQuery removes other constructs such as data and event handlers from
the child elements before removing the elements themselves." - but it seems
something bad is still going on. I'll look into this.



On Fri, Nov 20, 2015 at 11:18 PM, Shashi Gowda 
wrote:

> If you install Patchwork.jl <http://github.com/shashi/Patchwork.jl>, and
> re-run your notebook, it should fix this issue. (you might also need to
> pre-compile Compose again - can be done by removing the .ji file in
> ~/.julia/lib/v0.4/)
>
> Compose (which Gadfly uses for rendering to SVG) doesn't depend on
> Patchwork, but if you have it installed, it will use the Patchwork backend
> when you render a @manipulate of plots - Patchwork will then try to
> reconcile previously rendered DOM nodes so that there are no performance
> penalties of this sort.
>
> On Fri, Nov 20, 2015 at 10:48 PM, Andrew Keller <
> andrew.keller...@gmail.com> wrote:
>
>> I think this is exactly what is happening. Some findings:
>>
>> 1) run the code:
>>
>> using Interact, Gadfly
>>> @manipulate for φ=0:π/16:4π, f=[:sin => sin, :cos => cos]
>>> plot((θ)->f(θ+φ),0,25)
>>> end
>>
>>
>> 2) Chrome dev tools--> Profiles--> heap snapshot.
>> 3) Click sin, cos, sin, cos, sin, cos, ... sin in the notebook
>> 4) Take another heap snapshot and look in comparison view.
>>
>> It looks like among other things there are a lot of SVGPathElements and
>> SVGTextElements that belong to detached DOM trees, suggesting the old plots
>> never get properly disposed. If I instead capture a JS profile in the
>> Chrome dev tools-->Timeline panel, it appears like the number of nodes and
>> listeners increases without bound.
>>
>> Now suppose I use Winston instead of Gadfly. The memory still appears to
>> leak, although the plots are a little more lightweight and the leak is
>> slower.
>>
>> Anyway, I'll submit an issue to the jupyter/notebook repo later today
>> although I wish I could pin down better where exactly the leak is coming
>> from.
>>
>> On Thursday, November 19, 2015 at 10:35:31 AM UTC-8, Keno Fischer wrote:
>>>
>>> Sounds like the memory leak is on the browser side? Maybe something is
>>> keeping a javascript reference to the plot? Potentially a Jupyter/IJulia
>>> bug?
>>>
>>> On Thu, Nov 19, 2015 at 12:01 PM, Stefan Karpinski >> > wrote:
>>>
>>>> This should work – if there's a memory leak that's never reclaimed by
>>>> gc, that's a bug.
>>>>
>>>> On Thu, Nov 19, 2015 at 11:55 AM, Andrew Keller 
>>>> wrote:
>>>>
>>>>> Maybe generating a new plot every time is not great practice, on
>>>>> account of the performance hit. That being said, I think it's perfectly
>>>>> legitimate to do what I'm doing for prototyping purposes. I can achieve 
>>>>> the
>>>>> frame rate I want and the main example shown on
>>>>> https://github.com/JuliaLang/Interact.jl does the same thing I do,
>>>>> generating a new plot each time.
>>>>>
>>>>> In fact, I'd encourage anyone reading this to just try that example,
>>>>> and repeatedly click between sin and cos. I'm able to make the memory
>>>>> consumption of my browser grow without bound. Surely someone besides 
>>>>> myself
>>>>> has noticed this before! I don't think loading another package is a 
>>>>> serious
>>>>> solution to the problem I'm describing, although your package certainly
>>>>> looks useful for other purposes.
>>>>>
>>>>> Just to reiterate, this is not a small memory leak; this is like a
>>>>> memory dam breach. I'm happy to help debug this but some assistance would
>>>>> be appreciated.
>>>>>
>>>>>
>>>>> On Thursday, November 19, 2015 at 7:11:55 AM UTC-8, Tom Breloff wrote:
>>>>>>
>>>>>> You're creating a new Gadfly.Plot object 

Re: [julia-users] Asynchronous Escher

[Shashi Gowda]

The monte carlo example does something like this:
https://github.com/shashi/Escher.jl/blob/master/examples/mc.jl

See specifically these lines
https://github.com/shashi/Escher.jl/blob/master/examples/mc.jl#L24-L40 may
give you a template for your own code.

On Sun, Jan 17, 2016 at 9:20 PM, Leonardo  wrote:

> Hi all,
> how can I build a (simple) Web-UI that must wait for long-running
> computation in Escher?
>
> Or (after a long computation), how can I generate asynchrounously a signal
> that "wake up" a web page rendered by Escher?
>
> Many thanks in advance
>
> Leonardo
>
>

Re: [julia-users] Escher global and local context

[Shashi Gowda]

Hi Leonardo

If you have a single Escher process serving multiple requests and you want
to share some state between them, my recommendation would be to put the
shared data in signal, which can optionally be persisted to disk/DB

something like

if !isdefined(:my_global_var) # this condition makes sure all your UIs are
referring to the same variable
my_global_signal = Signal(Any, initial_value)

# you could also persist this to disk/DB for re-reading later, if you
have a function that can do that.
Reactive.foreach(save_to_disk, my_global_signal)

# optionally you could save throttle(1.0, my_global_signal) to make
sure the state is saved at most once every second so as to not hit the disk
often
end

function main(window)
   # ... use my_global_signal here, to get and put updates: every client
will be notified of updates...
end



On Sun, Jan 31, 2016 at 5:47 PM, Leonardo  wrote:

> Hi all,
> I want write an application with a Web UI (e.g. a chat) that has a local
> state (specific for each client) and global one (a state bind to web
> server).
> These requirements are useful for example to permit communications between
> different client (e.g. into a chat) and/or handle centralized resources
> (like a DB connection shared by all client and created once into web
> server).
>
> How can I do that?
>
> Many thanks in advance
>
> Leonardo
>
>

Re: [julia-users] Escher example problem

[Shashi Gowda]

I believe this to be fixed now?

On Mon, Jan 11, 2016 at 1:09 PM, Leonardo  wrote:

> Hi, I've a problem running Escher's example plotting.jl caused by Gadfly:
>
> WARNING: using Gadfly.render in module Main conflicts with an existing
> identifier.
> WARNING: Method definition convert(Type{Escher.Tile}, Gadfly.Plot) in
> module Escher at C:\Users\Leonardo\.julia\v0.4\Escher\src\basics/lazyload.
> jl:73 overwritten in module Main at C:\Users\Leonardo\.julia\v0.4\Escher\
> src\basics\lazyload.jl:73.
> WARNING: Error requiring DataFrames from Main:
> LoadError: error in method definition: function Escher.render must be
> explicitly imported to be extended
>  in include at boot.jl:261
>  in include_from_node1 at loading.jl:304
>  in anonymous at C:\Users\Leonardo\.julia\v0.4\Requires\src\require.jl:60
>  in err at C:\Users\Leonardo\.julia\v0.4\Requires\src\require.jl:47
>  in anonymous at C:\Users\Leonardo\.julia\v0.4\Requires\src\require.jl:59
>  in withpath at C:\Users\Leonardo\.julia\v0.4\Requires\src\require.jl:37
>  in anonymous at C:\Users\Leonardo\.julia\v0.4\Requires\src\require.jl:58
>  in listenmod at C:\Users\Leonardo\.julia\v0.4\Requires\src\require.jl:21
>  in include at boot.jl:261
>  in include_from_node1 at loading.jl:304
>  in external_setup at C:\Users\Leonardo\.julia\v0.4\Escher\src\Escher.jl:
> 53
>  in include at boot.jl:261
>  in include_from_node1 at loading.jl:304
>  in loadfile at C:\Users\Leonardo\.julia\v0.4\Escher\src\cli\serve.jl:17
>  in anonymous at C:\Users\Leonardo\.julia\v0.4\Escher\src\cli\serve.jl:164
>  in anonymous at C:\Users\Leonardo\.julia\v0.4\Mux\src\Mux.jl:15
>  in anonymous at C:\Users\Leonardo\.julia\v0.4\Mux\src\Mux.jl:8
>  in splitquery at C:\Users\Leonardo\.julia\v0.4\Mux\src\basics.jl:28
>  in anonymous at C:\Users\Leonardo\.julia\v0.4\Mux\src\Mux.jl:8
>  in wcatch at C:\Users\Leonardo\.julia\v0.4\Mux\src\websockets_integration
> .jl:12
>  in anonymous at C:\Users\Leonardo\.julia\v0.4\Mux\src\Mux.jl:8
>  in todict at C:\Users\Leonardo\.julia\v0.4\Mux\src\basics.jl:21
>  in anonymous at C:\Users\Leonardo\.julia\v0.4\Mux\src\Mux.jl:12 (repeats
> 2 times)
>  in anonymous at C:\Users\Leonardo\.julia\v0.4\Mux\src\Mux.jl:8
>  in anonymous at C:\Users\Leonardo\.julia\v0.4\Mux\src\server.jl:38
>  in handle at C:\Users\Leonardo\.julia\v0.4\WebSockets\src\WebSockets.jl:
> 382
>  in on_message_complete at C:\Users\Leonardo\.julia\v0.4\HttpServer\src\
> HttpServer.jl:393
>  in on_message_complete at C:\Users\Leonardo\.julia\v0.4\HttpServer\src\
> RequestParser.jl:104
>  in http_parser_execute at C:\Users\Leonardo\.julia\v0.4\HttpParser\src\
> HttpParser.jl:92
>  in process_client at C:\Users\Leonardo\.julia\v0.4\HttpServer\src\
> HttpServer.jl:365
>  in anonymous at task.jl:447
> while loading C:\Users\Leonardo\.julia\v0.4\Escher\src\library\table.jl,
> in expression starting on line 34
> WARNING: Base.String is deprecated, use AbstractString instead.
>   likely near C:\Users\Leonardo\.julia\v0.4\Escher\bin\escher:49
> WARNING: Base.String is deprecated, use AbstractString instead.
>   likely near C:\Users\Leonardo\.julia\v0.4\Escher\bin\escher:49
> WARNING: Base.String is deprecated, use AbstractString instead.
>   likely near C:\Users\Leonardo\.julia\v0.4\Escher\bin\escher:49
> WARNING: Base.String is deprecated, use AbstractString instead.
>   likely near C:\Users\Leonardo\.julia\v0.4\Escher\bin\escher:49
> WARNING: Base.String is deprecated, use AbstractString instead.
>   likely near C:\Users\Leonardo\.julia\v0.4\Escher\bin\escher:49
> in call at C:\Users\Leonardo\.julia\v0.4\Compose\src\patchable.jl:21
> WARNING: Base.String is deprecated, use AbstractString instead.
>   likely near C:\Users\Leonardo\.julia\v0.4\Escher\bin\escher:49
> in call at C:\Users\Leonardo\.julia\v0.4\Compose\src\patchable.jl:21
> WARNING: Base.String is deprecated, use AbstractString instead.
>   likely near C:\Users\Leonardo\.julia\v0.4\Escher\bin\escher:49
> in call at C:\Users\Leonardo\.julia\v0.4\Compose\src\patchable.jl:21
> Error handling websocket connection:
> MethodError: `isfinished` has no method matching isfinished(::Compose.
> Patchable)
>  in draw at C:\Users\Leonardo\.julia\v0.4\Compose\src\container.jl:430
>  in compose_render at C:\Users\Leonardo\.julia\v0.4\Escher\src\basics\
> lazyload.jl:54
>  in render at C:\Users\Leonardo\.julia\v0.4\Escher\src\basics\lazyload.jl:
> 63
>  in render at C:\Users\Leonardo\.julia\v0.4\Escher\src\basics/tile.jl:89
>  in render at C:\Users\Leonardo\.julia\v0.4\Escher\src\basics/layout.jl:
> 290
>  in render at C:\Users\Leonardo\.julia\v0.4\Escher\src\basics/layout.jl:
> 462
>  in render at C:\Users\Leonardo\.julia\v0.4\Escher\src\basics/layout.jl:
> 471
>  in start_updates at C:\Users\Leonardo\.julia\v0.4\Escher\src\cli\serve.jl
> :115
>  in anonymous at C:\Users\Leonardo\.julia\v0.4\Escher\src\cli\serve.jl:181
>  in anonymous at C:\Users\Leonardo\.julia\v0.4\Mux\src\Mux.jl:15
>  in anonymous at C:\Users\Leonardo\.julia\v0.4\Mux\src\Mux.jl:8
>

Re: [julia-users] Escher global and local context

[Shashi Gowda]

On Sun, Jan 31, 2016 at 11:41 PM, Shashi Gowda 
wrote:

> Hi Leonardo
>
> put the shared data in signal, which can optionally be persisted to disk/DB
>

I meant to say  "put the shared data in a global signal"

Re: [julia-users] Escher global and local context

[Shashi Gowda]

Yes this is how you can share non signal variables as well. However, if you
use a non-signal variable to share state, your state updates will not be
propagated across clients one the main function has executed.

If you persist state like in the example, you can load it and make it the
initial value of the shared signal after a restart, picking up where you
left off

On Mon 1 Feb, 2016, 1:44 PM Leonardo  wrote:

> Hi Shashi,
> this technique is applicable also for non-Signal variables, right?
>
> However, persistence hints for Signals are very interestings ...
>
> Thanks
>
> Leonardo
>
>
> Il 31/01/2016 19:11, Shashi Gowda ha scritto:
> > Hi Leonardo
> >
> > If you have a single Escher process serving multiple requests and you
> > want to share some state between them, my recommendation would be to put
> > the shared data in signal, which can optionally be persisted to disk/DB
> >
> > something like
> >
> > if !isdefined(:my_global_var) # this condition makes sure all your UIs
> > are referring to the same variable
> >  my_global_signal = Signal(Any, initial_value)
> >
> >  # you could also persist this to disk/DB for re-reading later, if
> > you have a function that can do that.
> >  Reactive.foreach(save_to_disk, my_global_signal)
> >
> >  # optionally you could save throttle(1.0, my_global_signal) to make
> > sure the state is saved at most once every second so as to not hit the
> > disk often
> > end
> >
> > function main(window)
> > # ... use my_global_signal here, to get and put updates: every
> > client will be notified of updates...
> > end
> >
> >
> >
> > On Sun, Jan 31, 2016 at 5:47 PM, Leonardo  > <mailto:maxsa...@gmail.com>> wrote:
> >
> > Hi all,
> > I want write an application with a Web UI (e.g. a chat) that has a
> > local state (specific for each client) and global one (a state bind
> > to web server).
> > These requirements are useful for example to permit communications
> > between different client (e.g. into a chat) and/or handle
> > centralized resources (like a DB connection shared by all client and
> > created once into web server).
> >
> > How can I do that?
> >
> > Many thanks in advance
> >
> > Leonardo
> >
> >
>

[julia-users] Google Summer of Code 2016 - Ideas Page

[Shashi Gowda]

Hi all,

I have merged the previous ideas pages (2015, 2014) into a canonical one
https://julialang.org/soc/ideas-page (and set up the appropriate redirects)

Please add your Summer of Code ideas and edit previous ones here
https://github.com/JuliaLang/julialang.github.com/edit/master/soc/ideas-page.md

Let us also try and keep this page updated all year round so that ideas get
carried over to the next summer.

Julia will be applying for GSoC 2016. The organization application deadline
is on 19th, it will be nice to have a high quality ideas page by then.

Thank you

Re: [julia-users] Passing functions between processes.

[Shashi Gowda]

remotecall_fetch(() -> println("Hello world"), 2)

or

helloworld = () -> println("...")

gets sent properly.

In general a named generic function gets serialized by means of its name
and not body, and that's why you get an undefined value error.

(also you can't just close a named function in a anonymous function, e.g. ()
-> myfun() won't work unless myfun is already available on the remote
process.)


On Tue, Mar 1, 2016 at 7:21 PM, Pranav Bhat  wrote:

> Consider the following code:
>
> addprocs(2)
> function helloworld()
>println("Hello World")
> end
>
> remotecall_fetch(helloworld, 2)
>
> This throws an error because the function helloworld isn't defined on
> process 2. I've found a couple of workarounds:
> 1. Use @everywhere while declaring the function
> 2. Place the function in a file or module and include it everywhere.
>
> Are there any alternatives to this? I would like to pass around functions
> like they were regular data items.
>

Re: [julia-users] METADATA madness (my fault)

[Shashi Gowda]

It looks like some changes left behind by a half-done Pkg.tag are causing
this problem. These steps should get things back to normal, and publish the
new tag.

1. rm METADATA/ArbFloats -rf

2. git checkout METADATA/ArbFloats # if this directory did exist before you
tried to tag

3. I also suggest you then make sure you're on the latest commit on
JuliaLang/METADATA.jl repository:
git fetch origin
git checkout -b arb-floats origin/metadata-v2
this is required if your previous failed attempt left behind a commit.

4. Note that if you tried PkgDev.tag previously, you will have a tag in
your ArbFloats repository. You will need to remove that with git tag
--delete vX.Y.Z before performing PkgDev.tag(...) to get you the correct
new tag.

5. You're good to do PkgDev.tag("ArbFloats", :minor)

6. Finally push your new tag to your ArbFloats repository -- git push
origin vX.Y.Z

7. make a METADATA PR from your fork of METADATA.jl


On Tue, Sep 6, 2016 at 12:03 PM, Jeffrey Sarnoff 
wrote:

> I have yet to enter my package into the Julia ecosystem by publishing it
> or manually forking METADATA etc.
> As I was about to do that, I managed to destroy my local METADATA for the
> package. I can, by erasing the entry in METADATA (& cache & lib)
> use PkgDev to re-register the package, but when  I try to tag it, it gets
> all upset
>
> julia> PkgDev.tag("ArbFloats") # or julia> PkgDev.tag("ArbFloats",:minor)
>
> ERROR: METADATA/ArbFloats is dirty – commit or stash changes to tag
>  in #36 at /home/jas/.julia/v0.5/PkgDev/src/entry.jl:223 [inlined]
>  in with(::PkgDev.Entry.##36#44{String}, ::Base.LibGit2.GitRepo) at
> ./libgit2/types.jl:638
>  in tag(::String, ::Symbol, ::Bool, ::String) at
> /home/jas/.julia/v0.5/PkgDev/src/entry.jl:222
>  in 
> (::Base.Pkg.Dir.##2#3{Array{Any,1},PkgDev.Entry.#tag,Tuple{String,Symbol}})()
> at ./pkg/dir.jl:31
>  in 
> cd(::Base.Pkg.Dir.##2#3{Array{Any,1},PkgDev.Entry.#tag,Tuple{String,Symbol}},
> ::String) at ./file.jl:59
>  in #cd#1(::Array{Any,1}, ::Function, ::Function, ::String,
> ::Vararg{Any,N}) at ./pkg/dir.jl:31
>  in tag(::String, ::Symbol) at /home/jas/.julia/v0.5/PkgDev/
> src/PkgDev.jl:47
>
>
>
> What is the remedy?
>
>
>

Re: [julia-users] METADATA madness (my fault)

[Shashi Gowda]

On Tue, Sep 6, 2016 at 12:50 PM, Shashi Gowda 
wrote:

> It looks like some changes left behind by a half-done PkgDev.tag are
> causing this problem. These steps should get things back to normal, and
> publish the new tag.
>
> 1. rm METADATA/ArbFloats -rf
>
> 2. git checkout METADATA/ArbFloats # if this directory did exist before
> you tried to tag
>

I meant, cd METADTA; git checkout ArbFloats
(this resets the contents of the directory to the latest committed state)


> 3. I also suggest you then make sure you're on the latest commit on
> JuliaLang/METADATA.jl repository:
> git fetch origin
> git checkout -b arb-floats origin/metadata-v2
> this is required if your previous failed attempt left behind a commit.
>
> 4. Note that if you tried PkgDev.tag previously, you will have a tag in
> your ArbFloats repository. You will need to remove that with git tag
> --delete vX.Y.Z before performing PkgDev.tag(...) to get you the correct
> new tag.
>
> 5. You're good to do PkgDev.tag("ArbFloats", :minor)
>
> 6. Finally push your new tag to your ArbFloats repository -- git push
> origin vX.Y.Z
>
> 7. make a METADATA PR from your fork of METADATA.jl
>
>
> On Tue, Sep 6, 2016 at 12:03 PM, Jeffrey Sarnoff <
> jeffrey.sarn...@gmail.com> wrote:
>
>> I have yet to enter my package into the Julia ecosystem by publishing it
>> or manually forking METADATA etc.
>> As I was about to do that, I managed to destroy my local METADATA for the
>> package. I can, by erasing the entry in METADATA (& cache & lib)
>> use PkgDev to re-register the package, but when  I try to tag it, it gets
>> all upset
>>
>> julia> PkgDev.tag("ArbFloats") # or julia> PkgDev.tag("ArbFloats",:minor)
>>
>> ERROR: METADATA/ArbFloats is dirty – commit or stash changes to tag
>>  in #36 at /home/jas/.julia/v0.5/PkgDev/src/entry.jl:223 [inlined]
>>  in with(::PkgDev.Entry.##36#44{String}, ::Base.LibGit2.GitRepo) at
>> ./libgit2/types.jl:638
>>  in tag(::String, ::Symbol, ::Bool, ::String) at
>> /home/jas/.julia/v0.5/PkgDev/src/entry.jl:222
>>  in 
>> (::Base.Pkg.Dir.##2#3{Array{Any,1},PkgDev.Entry.#tag,Tuple{String,Symbol}})()
>> at ./pkg/dir.jl:31
>>  in 
>> cd(::Base.Pkg.Dir.##2#3{Array{Any,1},PkgDev.Entry.#tag,Tuple{String,Symbol}},
>> ::String) at ./file.jl:59
>>  in #cd#1(::Array{Any,1}, ::Function, ::Function, ::String,
>> ::Vararg{Any,N}) at ./pkg/dir.jl:31
>>  in tag(::String, ::Symbol) at /home/jas/.julia/v0.5/PkgDev/s
>> rc/PkgDev.jl:47
>>
>>
>>
>> What is the remedy?
>>
>>
>>
>

Re: [julia-users] Re: Webapp Deployment

[Shashi Gowda]

Hi Reuben,

what's in hello.jl ? There isn't a examples/hello.jl in Escher is there?

A file you are trying to serve should end with a function definition such
as:

function main(window) # must take an argumentend

And this function should return the UI object you want to render.

On Tue, Nov 1, 2016 at 9:50 PM, wookyoung noh  wrote:

> Hello, I'm a developer of Bukdu.
> https://github.com/wookay/Bukdu.jl
>
> it's an web development framework on top of HttpServer.jl
> Thanks!
>
> On Tuesday, November 1, 2016 at 1:08:01 PM UTC+9, Reuben Brooks wrote:
>>
>> Context: I love julia, and I've never built any kind of webapp. Most of
>> my programming experience is in Mathematica and Julia...hacking things
>> together (poorly) in Python when nothing else works.
>>
>> Problem: I have a script  / notebook in julia that pulls data from
>> sources, analyzes it, builds fancy plots, and has lots of nice information.
>> Now I want to build a basic webapp that will allow me to access this
>> information anywhere, anytime (will be updated regularly).
>>
>> Question 1: is there a julia package that suits my needs well, or should
>> I look at using some other fronted to create the frontend? Elm intrigues
>> me, as much for the learning as for the actual solution.
>>
>> Bottom line: I don't know enough about what I'm wading into to choose
>> wisely. What does the community suggest?
>>
>