[julia-users] Re: Writing a mutable function (exclamation mark function)
does this help any? julia a = 1 1 julia function inc() a = a+1 end inc (generic function with 1 method) julia inc() ERROR: UndefVarError: a not defined in inc at none:2 julia function inc() global a = a+1 end inc (generic function with 1 method) julia inc() 2 julia inc() 3 julia inc() 4 julia inc() 5 julia function make_inc(start) a = start function inc() a = a + 1 end end make_inc (generic function with 1 method) julia inc2 = make_inc(99) inc (generic function with 1 method) julia inc2() 100 julia inc2() 101 julia inc2() 102 also http://julia.readthedocs.org/en/latest/manual/variables-and-scoping/ andrew On Monday, 8 June 2015 11:34:47 UTC-3, dwo...@gmail.com wrote: I'm currently trying to understand how functions with an exclamation mark at the end work. I know the exclamation mark is just a notational point however I'm currently confused at how to actually write a mutable function. If a = 1 function add_one(a) return a + 1 end running add_one(a) twice outputs: 2 2 how would I create add_one!(a) to output: 2 3
[julia-users] Re: Simple Conjugate Gradients coded in Julia is much faster than cholfact
Hi Dominique. I was not aware of this library. Thanks ! On Thursday, June 4, 2015 at 10:31:24 AM UTC-3, Dominique Orban wrote: FWIW, on your example, here's the time taken by the CG implemented in Krylov.jl (https://github.com/optimizers/Krylov.jl) julia A = sprand(1,1,0.01); A = A'+A; A=A+100*rand()*speye(1,1); julia b = A * ones(1); julia cg(A, b, rtol=1.0e-10, atol=1.0e-10); julia @time cg(A, b, rtol=1.0e-10, atol=1.0e-10); elapsed time: 0.047595623 seconds (1136352 bytes allocated) Preallocation doesn't save much time in this case, but quite a bit of memory: julia using LinearOperators julia Ap = zeros(1); julia op = LinearOperator(1, Float64, p - A_mul_B!(1.0, A, p, 0.0, Ap)) julia cg(op, b, rtol=1.0e-10, atol=1.0e-10); julia @time cg(op, b, rtol=1.0e-10, atol=1.0e-10) elapsed time: 0.0450219 seconds (241552 bytes allocated) This CG doesn't support preconditioning, but that would be quite trivial to add. On Monday, June 1, 2015 at 3:12:01 PM UTC+2, Eduardo Lenz wrote: Hi Andreas...Its me again :0) Its just an example ..I agree that it is quite unfair :0) But we are solving very large 3D homogeneization problems (basically, 3D finite elements) and the diference is still very impressive. Specially if you consider the amount of memory needed to solve such systems with cholfact when compared to this iterative method. This code is a very basic modification of the traditional CG method, where the cofficient matrix is changed in order to scale the diference between the larger and the smaller eigenvalues. I am realy amazed with the speed of sparse multiplications in Julia...its very fast ! On Monday, June 1, 2015 at 10:05:18 AM UTC-3, Andreas Noack wrote: I think the chosen matrix has very good convergence properties for iterative methods, but I agree that iterative methods are very useful to have in Julia. There is already quite a few implementations in https://github.com/JuliaLang/IterativeSolvers.jl I'm not sure if these methods cover the one you chose, so you could have a look and see if there is something to contribute there. Den søndag den 31. maj 2015 kl. 21.37.23 UTC-4 skrev Eduardo Lenz: Hi. One of my students is solving some large sparse systems (more than 20K equations). The coeficient matrix is symmetric and positive definite, with large sparsivity (1% of non zero elements in some cases). After playing around a little bit with cholfact we decided to compare the time with a very simple implementation of the conjugate gradient method with diagonal scaling. The code is in https://gist.github.com/CodeLenz/92086ba37035fe8d9ed8#file-gistfile1-txt https://www.google.com/url?q=https%3A%2F%2Fgist.github.com%2FCodeLenz%2F92086ba37035fe8d9ed8%23file-gistfile1-txtsa=Dsntz=1usg=AFQjCNHejjwPU4C7HybkkB2Y_kY2sPA7zQ And, as for example, the solution of Ax=b for julia A = sprand(1,1,0.01); A = A'+A; A=A+100*rand()*speye(1,1) takes 16 seconds with cholfact(A) and 600 milliseconds !!! with DCGC (tol=1E-10) Also, as expected, the memory consumption with CG is very low, allowing the solution of very large systems. The same pattern is observed for different leves of sparsivity and for different random matrices. I would like to thank the Julia developers for such amazing tool !
Re: [julia-users] Re: Announcement: Escher.jl - a toolkit for beautiful Web UIs in pure Julia
Great!!! :D On Mon, Jun 8, 2015 at 1:41 PM, Simon Danisch sdani...@gmail.com wrote: This looks great =) Am Montag, 8. Juni 2015 18:23:21 UTC+2 schrieb 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 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. -- -- Filipe Braida do Carmo - BSc em Ciência da Computação - Universidade Federal do Rio de Janeiro - UFRJ Mestre em Engenharia de Sistemas e Computação - PESC/COPPE/UFRJ Doutorando em Engenharia de Sistemas e Computação - PESC/COPPE/UFRJ
[julia-users] Re: Announcement: Escher.jl - a toolkit for beautiful Web UIs in pure Julia
Shashi: This looks really cool. And I'll be trying it out soon... thanks for the effort. 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.
Re: [julia-users] spawning processes remotely and locally
Julia 0.4 supports auto*host which will launch as many workers on host as cores. On Tue, Jun 9, 2015 at 12:29 AM, Matt Wolff mbwo...@gmail.com wrote: I was poking around the julia parallel tutorial and source, it looks like if you spin up a cluster using a --machinefile, (where every process is on it's own machine), that the remote workers would not be able to spin up additional local processes. For example, if you spin up a 4 machine cluster, and each worker has 4 cores, you can't run addprocs() on the workers to utilize the 4 locally available worker cores. Is there something on the julia roadmap to be able to leverage free cores on a worker? Or is this something that can be done with the current julia implementation? As an example, here is a quick script I wrote to test this: #run this function from the master node function dostuff() @everywhere include(parallel/testworkers.jl) for worker in workers() remotecall(worker, testworkers, 12) end end #each workers executes this function testworkers(numberofinterns::Int) addprocs(numberofinterns) nheads = @parallel (+) for i=1:200 Int(rand(Bool)) end println(finished) end
[julia-users] Re: a simple function which changes the order of a vector (by modifying the argument)
Thank you John. I can see that x[:]=x[srt] does the trick. Am Montag, 8. Juni 2015 18:28:16 UTC+2 schrieb bernhard: All I would like to sort a vector according to a given index (or permutation). I understand that the code below produces a false (last evaluation below) due to the fact that the function creates a local copy of x. How can I modify my function such that x is in sorted differently (i.e. such that the argument is modified)? Thank you in advance. x=rand(5) anothervector=rand(5) mypermutation=sortperm(x) function change_order!(x,srt) x=x[srt] nothing end before=copy(anothervector) change_order!(anothervector,mypermutation) before==anothervector[mypermutation] #false before==anothervector #true, this should be false before[mypermutation]==anothervector #false, this should be true
Re: [julia-users] Re: Converting [0x20202020,0x20202020] to an ASCIIString
Thanks for the help. I would have thought the correct way would raise an
inexact error. Thanks for following up with this.
On Mon, Jun 8, 2015 at 8:50 PM, Kevin Squire kevin.squ...@gmail.com wrote:
I've used the first syntax many times, and somehow find it more
intuitive. Perhaps this is another candidate for
https://github.com/JuliaLang/julia/issues/11557 (although the use is
slightly different).
Kevin
On Mon, Jun 8, 2015 at 11:47 AM, Scott Jones scott.paul.jo...@gmail.com
wrote:
Easy mistake, I had the same problem the first time I tried to use
reinterpret.
You need to do:
reinterpret(Uint8, spaces)
On Monday, June 8, 2015 at 3:28:14 PM UTC+2, Glen H wrote:
Hi,
Is there a built-in to convert a Vector{Uint32} to an ASCIIString? The
Uint32 represents 8-bit ASCII. I tried:
julia spaces = [0x20202020,0x20202020]
2-element Array{UInt32,1}:
0x20202020
0x20202020
julia reinterpret(Vector{Uint8}, spaces)
ERROR: type does not have a canonical binary representation
in reinterpret at array.jl:111
julia bytestring(spaces)
ERROR: MethodError: `bytestring` has no method matching
bytestring(::Array{UInt32,1})
I could write the data to an IOBuffer and then do takebuf_string but I
was hoping for a more efficient method.
Glen
[julia-users] Best Julian practices for a function with a set of options
I have a function, originally from C, that I've now rewritten entirely in Julia. It takes a set of options, 3 currently, that determine what is done when certain types of poorly encoded UTF data is found. They are all just set or unset (true or false). Should they be keyword arguments? How should I do it so that julia can generate a version for the common case of no options set (i.e. not having the run-time checks on the options)? Thanks, Scott
Re: [julia-users] Best Julian practices for a function with a set of options
I'd start with the keyword version, making sure to declare the type of each keyword argument (in contrast with regular arguments, type declarations have a performance impact for keyword arguments). Test your code. If you find this is too slow, then switch to fixed-position arguments. You can define your function like this: function foo(x, bool1 = false, bool2 = false, bool3 = false) body end and then the bool arguments will be optional. This will have no performance penalty, but the caller needs to supply these bools in the proper order. Best, --Tim On Monday, June 08, 2015 01:56:02 AM Scott Jones wrote: I have a function, originally from C, that I've now rewritten entirely in Julia. It takes a set of options, 3 currently, that determine what is done when certain types of poorly encoded UTF data is found. They are all just set or unset (true or false). Should they be keyword arguments? How should I do it so that julia can generate a version for the common case of no options set (i.e. not having the run-time checks on the options)? Thanks, Scott
[julia-users] Re: Writing a mutable function (exclamation mark function)
http://julia.readthedocs.org/en/release-0.3/manual/faq/#i-passed-an-argument-x-to-a-function-modified-it-inside-that-function-but-on-the-outside-the-variable-x-is-still-unchanged-why http://www.johnmyleswhite.com/notebook/2014/09/06/values-vs-bindings-the-map-is-not-the-territory/ On Monday, June 8, 2015 at 7:34:47 AM UTC-7, dwor...@gmail.com wrote: I'm currently trying to understand how functions with an exclamation mark at the end work. I know the exclamation mark is just a notational point however I'm currently confused at how to actually write a mutable function. If a = 1 function add_one(a) return a + 1 end running add_one(a) twice outputs: 2 2 how would I create add_one!(a) to output: 2 3
[julia-users] Converting [0x20202020,0x20202020] to an ASCIIString
Hi,
Is there a built-in to convert a Vector{Uint32} to an ASCIIString? The
Uint32 represents 8-bit ASCII. I tried:
julia spaces = [0x20202020,0x20202020]
2-element Array{UInt32,1}:
0x20202020
0x20202020
julia reinterpret(Vector{Uint8}, spaces)
ERROR: type does not have a canonical binary representation
in reinterpret at array.jl:111
julia bytestring(spaces)
ERROR: MethodError: `bytestring` has no method matching
bytestring(::Array{UInt32,1})
I could write the data to an IOBuffer and then do takebuf_string but I was
hoping for a more efficient method.
Glen
[julia-users] Re: example for ccall use and fortran
Pay attention as real*8 is not standard Fortran but just a quite common
extension accepted by most compilers. :-)
Il giorno sabato 30 maggio 2015 21:10:39 UTC+2, Andre Bieler ha scritto:
Ok so I have a few simple examples working for ccalling fortran functions
and subroutines from Julia.
Maybe someone will find this useful examples when first looking into
calling fortran from julia.
compile the following fortran module with
*gfortran simplemodule.f95 -o simplemodule.so -shared -fPIC*
```
!fileName = simplemodule.f95
module simpleModule
implicit none
contains
function foo(x)
integer :: foo, x
foo = x * 2
end function foo
subroutine bar(x, a, b)
integer, intent(in) :: x
integer, intent(out) :: a, b
a = x + 3
b = x * 3
end subroutine bar
subroutine keg(x, a, b)
real*8, intent(in) :: x
real*8, intent(out) :: a, b
a = x + 3.0
b = x * 3.0
end subroutine keg
subroutine ruf(x, y)
real*8, dimension(3), intent(in) :: x
real*8, dimension(3), intent(out) :: y
integer :: i
DO i = 1, 3
y(i) = 2*x(i)
END DO
end subroutine ruf
end module simplemodule
```
then you can use the following julia script to call the functions from the
shared library.
```
x1 = 7
a1 = [0]
b1 = [0]
r1 = ccall((:__simplemodule_MOD_foo,
/home/abieler/testPrograms/fortranShardLib/simplemodule.so), Int64,
(Ptr{Int64},), x1)
println(r1)
println()
ccall((:__simplemodule_MOD_bar,
/home/abieler/testPrograms/fortranShardLib/simplemodule.so), Void,
(Ptr{Int64}, Ptr{Int64}, Ptr{Int64}), x1, a1, b1)
println(a1[1])
println(b1[1])
println()
x2 = 7.0
a2 = Cdouble[1.0]
b2 = Cdouble[1.0]
ccall((:__simplemodule_MOD_keg,
/home/abieler/testPrograms/fortranShardLib/simplemodule.so), Void,
(Ptr{Float64}, Ptr{Float64}, Ptr{Float64}), x2, a2, b2)
println(a2[1])
println(b2[1])
println()
x3 = [1.0, 2.0, 3.0]
y3 = [0.0, 0.0, 0.0]
ccall((:__simplemodule_MOD_ruf,
/home/abieler/testPrograms/fortranShardLib/simplemodule.so), Void,
(Ptr{Float64}, Ptr{Float64}), x3, y3)
println(y3)
```
[julia-users] Debugging Julia code via gbd/llddb
I wonder whether it is possible to debug Julia code using gdb/lldb. So far I have only used different IDEs debuggers, and thus have no experience with gdb/lldb. I tried searching for this, but only came across debuging Julia itself / Julias C-code, but nothing specific to debugging the Julia code (or I was not able to understand it) So my question is, given the code: x=1 print(x) Can I debug this using gdb/lldb, inserting a breakpoint after the first line, then dropping to the REPL and changing x to 2, resuming the program and getting the updated 2 printed? If so, could you please describe along this simple example how to do it :)?
[julia-users] Re: Getting information about containing module, file, line number, method/type, etc.
I'm sure this won't work in every case, but depending on your usage you could model after the hack at the beginning of this file: https://github.com/joshday/OnlineStats.jl/blob/master/src/log.jl On Saturday, June 6, 2015 at 4:46:44 AM UTC-4, Scott Jones wrote: I have been trying to find out some way in Julia of getting information about what the current file name line number is, and also the containing module(s), method or type, etc., in a macro. I'd looked to see if there was anything like __LINE__, but I wasn't able to find anything similar so far... Thanks, Scott
[julia-users] Re: Converting [0x20202020,0x20202020] to an ASCIIString
Easy mistake, I had the same problem the first time I tried to use
reinterpret.
You need to do:
reinterpret(Uint8, spaces)
On Monday, June 8, 2015 at 3:28:14 PM UTC+2, Glen H wrote:
Hi,
Is there a built-in to convert a Vector{Uint32} to an ASCIIString? The
Uint32 represents 8-bit ASCII. I tried:
julia spaces = [0x20202020,0x20202020]
2-element Array{UInt32,1}:
0x20202020
0x20202020
julia reinterpret(Vector{Uint8}, spaces)
ERROR: type does not have a canonical binary representation
in reinterpret at array.jl:111
julia bytestring(spaces)
ERROR: MethodError: `bytestring` has no method matching
bytestring(::Array{UInt32,1})
I could write the data to an IOBuffer and then do takebuf_string but I was
hoping for a more efficient method.
Glen
[julia-users] Re: Debugging Julia code via gbd/llddb
This is being worked on (and will use lldb), but it's still under very heavy development. A bit of information: https://groups.google.com/forum/#!topic/julia-dev/gcZ5dZJni5o On Monday, June 8, 2015 at 6:56:48 AM UTC-5, axsk wrote: I wonder whether it is possible to debug Julia code using gdb/lldb. So far I have only used different IDEs debuggers, and thus have no experience with gdb/lldb. I tried searching for this, but only came across debuging Julia itself / Julias C-code, but nothing specific to debugging the Julia code (or I was not able to understand it) So my question is, given the code: x=1 print(x) Can I debug this using gdb/lldb, inserting a breakpoint after the first line, then dropping to the REPL and changing x to 2, resuming the program and getting the updated 2 printed? If so, could you please describe along this simple example how to do it :)?
[julia-users] Announcement: Escher.jl - a toolkit for beautiful Web UIs in pure Julia
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] a simple function which changes the order of a vector (by modifying the argument)
All I would like to sort a vector according to a given index (or permutation). I understand that the code below produces a false (last evaluation below) due to the fact that the function creates a local copy of x. How can I modify my function such that x is in sorted differently (i.e. such that the argument is modified)? Thank you in advance. x=rand(5) anothervector=rand(5) mypermutation=sortperm(x) function change_order!(x,srt) x=x[srt] nothing end before=copy(anothervector) change_order!(anothervector,mypermutation) before==anothervector[mypermutation] #false before==anothervector #true, this should be false before[mypermutation]==anothervector #false, this should be true
[julia-users] Re: a simple function which changes the order of a vector (by modifying the argument)
http://julia.readthedocs.org/en/release-0.3/manual/faq/#i-passed-an-argument-x-to-a-function-modified-it-inside-that-function-but-on-the-outside-the-variable-x-is-still-unchanged-why http://www.johnmyleswhite.com/notebook/2014/09/06/values-vs-bindings-the-map-is-not-the-territory/ On Monday, June 8, 2015 at 9:28:16 AM UTC-7, bernhard wrote: All I would like to sort a vector according to a given index (or permutation). I understand that the code below produces a false (last evaluation below) due to the fact that the function creates a local copy of x. How can I modify my function such that x is in sorted differently (i.e. such that the argument is modified)? Thank you in advance. x=rand(5) anothervector=rand(5) mypermutation=sortperm(x) function change_order!(x,srt) x=x[srt] nothing end before=copy(anothervector) change_order!(anothervector,mypermutation) before==anothervector[mypermutation] #false before==anothervector #true, this should be false before[mypermutation]==anothervector #false, this should be true
Re: [julia-users] Sublists in Julia's doc strings
*shrugs shoulders* I pretty much am horrible at API design. For a non-performance-critical API, keyword arguments would be the recommended approach. The old-school Julia pre-kwarg dispatch pyramid (with n-argument forms dispatching to the n+1 argument form with a default n+1th argument) will perform better but is often pretty hard to use and a pain in the butt to write. An option type with kwarg constructor might be the best compromise (since you only pay the kwarg penalty once to construct the option structure) but I have no idea whether that's been done and/or has caught on. On Saturday, June 6, 2015 at 12:02:36 AM UTC-5, Scott Jones wrote: Well, not sure if it is a bug, just a difference in Markdown variants (that’s the big problem with Markdown, IMO, there are a number of slightly different versions), or something that just wasn’t implemented yet. Although, your comment, made clear something to me… although originally the check_string function was a wrapper around C code, and so had a very C-style interface, I was pushed by the Julian community to do a pure Julia implementation, so there’s no reason to be bound by C API. What would you recommend, as a more Julia interface, where you have a set of options (in this case, all boolean flags)? (I wonder if one of the more Julian ways might even be more efficient, if it allowed the compiler to generate a more specific version of the function) Thanks, Scott Ah, that wasn't clear. Might just be another enhancement request for the Markdown parser, then? On Friday, June 5, 2015 at 12:28:53 PM UTC-5, Scott Jones wrote: I was not asking about that, but rather that Julia's Markdown handling doesn't seem to be handling sublists as the Markdown examples I've seen... which I showed in the doc string... Sent from my iPhone On Jun 5, 2015, at 5:02 PM, Patrick O'Leary patrick.ole...@gmail.com wrote: Since this is a very C-style interface, perhaps `man 2 open` which uses that style of option flag will get you somewhere? On Friday, June 5, 2015 at 7:47:49 AM UTC-5, Scott Jones wrote: I've been trying to write documentation for my Julia functions in a way that others will find acceptable, but will still be useful to me. I have a keyword argument, options, that has several different possible values or'ed in. I would like to describe that, but it doesn't come out nicely: @doc docSilly function long description ### Input Arguments: 1. abc Description of argument 2. def Description of argument ### Keyword Argument: * options **option1 Description of option 1 **option2 Description of option 2 ### Returns: * A UTF32String ### Throws: * ArgumentError - foo
[julia-users] Re: Announcement: Escher.jl - a toolkit for beautiful Web UIs in pure Julia
This looks great =) Am Montag, 8. Juni 2015 18:23:21 UTC+2 schrieb 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 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.
