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

[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 
>  
> 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: The new Dict syntax in 0.4 is very verbose

[Michael Turok]

That is elegantif I only could follow how it works

On Thursday, September 3, 2015 at 4:40:54 PM UTC-4, Mike Innes wrote:
>
> FWIW I mocked up a json syntax macro:
>
> using MacroTools, Lazy
>
> import MacroTools: prewalk
>
> function prockey(key)
>   @capture(key, (a_:b_) | (a_=>b_)) || error("Invalid json key $key")
>   isa(a, Symbol) && (a = Expr(:quote, a))
>   :($a=>$b)
> end
>
> function procmap(d)
>   @capture(d, {xs__}) || return d
>   :(Dict{Any, Any}($(map(prockey, xs)...)))
> end
>
> macro json(ex)
>   @>> ex prewalk(procmap) esc
> end
>
> Michael's original example becomes:
>
> data = @json {
> displayrows: 20,
> cols: [
> { col: "l1" },
> { col: "l2" },
> { col: "l3" },
> { col: "num", display: true },
> { col: "sum", display: true, conf: { style: 1, func: { 
> method: "sum", col: "num"  } } }
> ]
>   # ...
> }
>
> You might argue that it's actually nicer than the original.
>
> On Thu, 3 Sep 2015 at 21:22 Scott Jones  > wrote:
>
>> Another use is marking off the keyword arguments or parameters.
>>
>>
>> On Thursday, September 3, 2015 at 3:11:34 PM UTC-4, Jonathan Malmaud 
>> wrote:
>>>
>>> What are the other uses of ; in Julia? I can only think of suppressing 
>>> output on the REPL and separating expressions on a single line - neither 
>>> seems inconsistent or really related at all to the use within []. 
>>>
>>> On Thursday, September 3, 2015 at 3:06:22 PM UTC-4, Scott Jones wrote:



 On Thursday, September 3, 2015 at 1:47:07 PM UTC-4, Sean Marshallsay 
 wrote:
>
> [1:10;] is simply a consequence of matrix literal syntax (like [1:10; 
> 11:20]) and gets translated into vcat(1:10). It might be a bit confusing 
> but there's no point in making it a special case
>

 Yes, I understand that, and that too is not consistent with the use of 
 ; outside of [ ].
 spaces, colon, semicolon, and commas are all treated specially instead 
 of [ ], which can be rather confusing.
 Some of that special behavior is being deprecated, but some remains.
  

>>>

[julia-users] Emacs, ESS and julia-mode

[Michael Turok]

Anyone here running julia under ESS in emacs?

It seems that emacs's ess-mode for julia isn't quite as happy lately - 
especially with some changes in 0.4 (related to REPL changes, possibly?).   
For example, help() doesn't do anything...perhaps b/c the REPL now expects 
"?" to do something useful.

Anyone have any suggestions?   (Or am I moving to atom+hydrogen later 
today?)

*Julia 0.3:*
julia> help(Pkg.init)
Base.Pkg.init(meta::String=DEFAULT_META, branch::String=META_BRANCH)


   Initialize "Pkg.dir()" as a package directory. This will be done
   automatically when the "JULIA_PKGDIR" is not set and
   "Pkg.dir()" uses its default value. As part of this process,
   clones a local METADATA git repository from the site and branch
   specified by its arguments, which are typically not provided.
   Explicit (non-default) arguments can be used to support a custom
   METADATA setup.


julia> 

*Julia 0.4*




*julia> help(Pkg.init)ERROR: UndefVarError: help not definedjulia> *

Re: [julia-users] Emacs, ESS and julia-mode

[Michael Turok]

The issue is that ?Pkg.init isn't recognized either - is there some special 
REPL handling?

julia> ?Pkg.init
ERROR: UndefVarError: ? not defined


julia> 


On Thursday, September 17, 2015 at 9:11:54 AM UTC-4, Mauro wrote:
>
> Well, help is not a function in 0.4 anymore.  Use ?Pkg.init 
>
> Can't help with the other ESS things.   I've tried it for a bit but it 
> introduced a noticeable lag so I switch back to just using julia-mode.el 
>
> On Thu, 2015-09-17 at 14:32, Michael Turok  > wrote: 
> > Anyone here running julia under ESS in emacs? 
> > 
> > It seems that emacs's ess-mode for julia isn't quite as happy lately - 
> > especially with some changes in 0.4 (related to REPL changes, 
> possibly?).   
> > For example, help() doesn't do anything...perhaps b/c the REPL now 
> expects 
> > "?" to do something useful. 
> > 
> > Anyone have any suggestions?   (Or am I moving to atom+hydrogen later 
> > today?) 
> > 
> > *Julia 0.3:* 
> > julia> help(Pkg.init) 
> > Base.Pkg.init(meta::String=DEFAULT_META, branch::String=META_BRANCH) 
> > 
> > 
> >Initialize "Pkg.dir()" as a package directory. This will be done 
> >automatically when the "JULIA_PKGDIR" is not set and 
> >"Pkg.dir()" uses its default value. As part of this process, 
> >clones a local METADATA git repository from the site and branch 
> >specified by its arguments, which are typically not provided. 
> >Explicit (non-default) arguments can be used to support a custom 
> >METADATA setup. 
> > 
> > 
> > julia> 
> > 
> > *Julia 0.4* 
> > 
> > 
> > 
> > 
> > *julia> help(Pkg.init)ERROR: UndefVarError: help not definedjulia> * 
>
>

Re: [julia-users] Emacs, ESS and julia-mode

[Michael Turok]

Thank you!  And for that pointer to the doc string

On Thursday, September 17, 2015 at 9:55:52 AM UTC-4, Stephen Eglen wrote:
>
> As one of the ESS developers, I will try and fix this with 0.4.  From 
> quick inspection, it looks like I can get the same help from the command 
> line using:
>
>
> -
>
> julia> Base.Docs.@repl pwd
>
> search: pwd powermod print_with_color
>
>
>   pwd() -> AbstractString
>
>
>   Get the current working directory.
>
> -
>
>
> If that looks right, I'll try to add that.
>
> On Thursday, September 17, 2015 at 2:33:29 PM UTC+1, Andrei Zh wrote:
>>
>> ESS mode's integration with Julia's REPL is quite simple and can't handle 
>> special sequences. It's a pity that `help()` function has been removed from 
>> 0.4, I didn't see it before your post.
>>
>> There was a discussion regarding better REPL (network REPL?) recently, 
>> but AFAIK nobody is working on such solution yet.
>>
>>
>> On Thursday, September 17, 2015 at 4:16:33 PM UTC+3, Michael Turok wrote:
>>>
>>> The issue is that ?Pkg.init isn't recognized either - is there some 
>>> special REPL handling?
>>>
>>> julia> ?Pkg.init
>>> ERROR: UndefVarError: ? not defined
>>>
>>>
>>> julia> 
>>>
>>>
>>> On Thursday, September 17, 2015 at 9:11:54 AM UTC-4, Mauro wrote:
>>>>
>>>> Well, help is not a function in 0.4 anymore.  Use ?Pkg.init 
>>>>
>>>> Can't help with the other ESS things.   I've tried it for a bit but it 
>>>> introduced a noticeable lag so I switch back to just using 
>>>> julia-mode.el 
>>>>
>>>> On Thu, 2015-09-17 at 14:32, Michael Turok  
>>>> wrote: 
>>>> > Anyone here running julia under ESS in emacs? 
>>>> > 
>>>> > It seems that emacs's ess-mode for julia isn't quite as happy lately 
>>>> - 
>>>> > especially with some changes in 0.4 (related to REPL changes, 
>>>> possibly?).   
>>>> > For example, help() doesn't do anything...perhaps b/c the REPL now 
>>>> expects 
>>>> > "?" to do something useful. 
>>>> > 
>>>> > Anyone have any suggestions?   (Or am I moving to atom+hydrogen later 
>>>> > today?) 
>>>> > 
>>>> > *Julia 0.3:* 
>>>> > julia> help(Pkg.init) 
>>>> > Base.Pkg.init(meta::String=DEFAULT_META, branch::String=META_BRANCH) 
>>>> > 
>>>> > 
>>>> >Initialize "Pkg.dir()" as a package directory. This will be done 
>>>> >automatically when the "JULIA_PKGDIR" is not set and 
>>>> >"Pkg.dir()" uses its default value. As part of this process, 
>>>> >clones a local METADATA git repository from the site and branch 
>>>> >specified by its arguments, which are typically not provided. 
>>>> >Explicit (non-default) arguments can be used to support a custom 
>>>> >METADATA setup. 
>>>> > 
>>>> > 
>>>> > julia> 
>>>> > 
>>>> > *Julia 0.4* 
>>>> > 
>>>> > 
>>>> > 
>>>> > 
>>>> > *julia> help(Pkg.init)ERROR: UndefVarError: help not definedjulia> * 
>>>>
>>>>

[julia-users] Pretty printing julia (or enscript?)

[Michael Turok]

Anyone have a preferred pretty printer for julia source code - or any 
enscript states file around?

Michael

[julia-users] Passing in Dict for Variable Number of Keyword Arguments like Python

[Michael Turok]

Is there a way to pass in a dictionary for the keyword arguments that have 
a varargs specification, much like python?

Note that this works in julia for passing in arrays/tuples for the 
non-keyword arguments.

*julia> foo(;kwargs...) = return kwargs*
*foo (generic function with 1 method)*

*julia> foo(x=1,y=2)*
*2-element Array{Any,1}:*
* (:x,1)*
* (:y,2)*

*julia> d = { :a=> 97, :b => 95 }*
*Dict{Any,Any} with 2 entries:*
*  :b => 95*
*  :a => 97*

*julia> foo(d...)*
*ERROR: `foo` has no method matching foo(::(Symbol,Int64), 
::(Symbol,Int64))*

Python example: 
 

>>> def foo(**kwargs):  return kwargs
... 
>>> foo(x=1,y=2)
{'y': 2, 'x': 1}
>>> dict = { "a" : 97, "b" : 95 }
>>> foo(**dict)
{'a': 97, 'b': 95}
>>> 

[julia-users] Re: Passing in Dict for Variable Number of Keyword Arguments like Python

[Michael Turok]

Simon/Mauro:  thank you!

On Tuesday, March 31, 2015 at 3:35:16 PM UTC-4, Simon Kornblith wrote:
>
> julia> foo(;d...)
> 2-element Array{Any,1}:
>  (:a,97)
>  (:b,95)
>
> Note the semicolon. Otherwise the Dict is splatted as positional arguments.
>
> Simon
>
> On Tuesday, March 31, 2015 at 3:29:47 PM UTC-4, Michael Turok wrote:
>>
>> Is there a way to pass in a dictionary for the keyword arguments that 
>> have a varargs specification, much like python?
>>
>> Note that this works in julia for passing in arrays/tuples for the 
>> non-keyword arguments.
>>
>> *julia> foo(;kwargs...) = return kwargs*
>> *foo (generic function with 1 method)*
>>
>> *julia> foo(x=1,y=2)*
>> *2-element Array{Any,1}:*
>> * (:x,1)*
>> * (:y,2)*
>>
>> *julia> d = { :a=> 97, :b => 95 }*
>> *Dict{Any,Any} with 2 entries:*
>> *  :b => 95*
>> *  :a => 97*
>>
>> *julia> foo(d...)*
>> *ERROR: `foo` has no method matching foo(::(Symbol,Int64), 
>> ::(Symbol,Int64))*
>>
>> Python example: 
>>  
>>
>> >>> def foo(**kwargs):  return kwargs
>> ... 
>> >>> foo(x=1,y=2)
>> {'y': 2, 'x': 1}
>> >>> dict = { "a" : 97, "b" : 95 }
>> >>> foo(**dict)
>> {'a': 97, 'b': 95}
>> >>> 
>>
>>

Re: [julia-users] loading local resources in module

[Michael Turok]

Hi Stefan,

How is this different from Base.source_path()?

Thanks,
Michael

On Tuesday, April 21, 2015 at 6:17:48 AM UTC-4, Stefan Karpinski wrote:
>
> There's a @__FILE__ macro that gives the path name of the current source 
> file, so if you want to load resources relative to that, you can do 
> joinpath(dirname(@__FILE__), "test", "data"). We might want to expose this 
> as @__DIR__ or something like that.
>
> On Mon, Apr 20, 2015 at 5:50 PM, Michael Francis  > wrote:
>
>> I'd like to load some local files from a module package directory. This 
>> is akin to the way java has resources. If this were julia code I could just 
>> include( 'foo.jl' ) and that will do mostly the right thing. Is there an 
>> equivalent without having to perform string math on Pkg.dir() ... 
>>
>> I've seen the following in DataFrames - Is this the idiomatic way 
>>
>> cd(Pkg.dir("DataFrames", "test", "data")) do ... and then perform file 
>> reads ? 
>>
>> Thanks
>>
>>
>

[julia-users] Defining a function in different modules

[Michael Turok]

Hi,

What is the idiomatic way to create a function value() in different 
modules, dispatched on different arguments, without getting the 
warning/error about conflicting with an existing identifier?

It seems like there is an order dependency with the example below.   Seems 
like the 2nd module defines value(), unless you had already used value() 
prior to importing the 2nd module.   

Note that if I do the same with get() a function defined in Base, I don't 
get an error. 

Code and output from julia REPL below.

Any help appreciated,
Michael

# this is mike.jl

# --
module Foo
# --
importall Base
type FooType end

value(x::FooType) = "Foo::value"
get(x::FooType) = "Foo::get"

export value

end

# --
module Bar
# --
importall Base

type BarType end

value(x::BarType) = "Bar::value"
get(x::BarType) = "Bar::get"

export value

end

Using this in the REPL: 
julia> workspace() ; include("mike.jl")

julia> using Foo

julia> value(Foo.FooType())
"Foo::value"

julia> using Bar
Warning: using Bar.value in module Main conflicts with an existing 
identifier.

julia> value(Bar.BarType())
ERROR: `value` has no method matching value(::BarType)

# -

julia> workspace() ; include("mike.jl")

julia> using Foo

julia> using Bar

julia> value(Foo.FooType())
ERROR: `value` has no method matching value(::FooType)

julia> value(Bar.BarType())
"Bar::value"

# -

julia> workspace() ; include("mike.jl")

julia> using Bar

julia> using Foo

julia> value(Foo.FooType())
"Foo::value"

julia> value(Bar.BarType())
ERROR: `value` has no method matching value(::BarType)

julia> 

[julia-users] Re: Defining a function in different modules

[Michael Turok]

Note that this can be made to work by tearing a page from Base:  we can a 
module (SuperSecretBase), that defines a stub value() function. We then use 
importall SuperSecretBase in each of Foo and Bar.But this means that 
any module we create would need to declare its functions into 
SuperSecretBase.

julia> workspace() ; include("mike.jl")

julia> using Foo

julia> using Bar

julia> value(Bar.BarType())
"Bar::value"

julia> value(Foo.FooType())
"Foo::value"

julia> 

Modified code follows: 

module SuperSecretBase
value() = nothing
export value
end

# --

module Foo

importall SuperSecretBase

importall Base
type FooType end

value(x::FooType) = "Foo::value"
get(x::FooType) = "Foo::get"

export value

end

# --

module Bar

importall SuperSecretBase

importall Base

type BarType end

value(x::BarType) = "Bar::value"
get(x::BarType) = "Bar::get"

export value

end




On Tuesday, April 21, 2015 at 9:26:01 AM UTC-4, Michael Turok wrote:
>
> Hi,
>
> What is the idiomatic way to create a function value() in different 
> modules, dispatched on different arguments, without getting the 
> warning/error about conflicting with an existing identifier?
>
> It seems like there is an order dependency with the example below.   Seems 
> like the 2nd module defines value(), unless you had already used value() 
> prior to importing the 2nd module.   
>
> Note that if I do the same with get() a function defined in Base, I don't 
> get an error. 
>
> Code and output from julia REPL below.
>
> Any help appreciated,
> Michael
>
> # this is mike.jl
>
> # --
> module Foo
> # --
> importall Base
> type FooType end
>
> value(x::FooType) = "Foo::value"
> get(x::FooType) = "Foo::get"
>
> export value
>
> end
>
> # --
> module Bar
> # --
> importall Base
>
> type BarType end
>
> value(x::BarType) = "Bar::value"
> get(x::BarType) = "Bar::get"
>
> export value
>
> end
>
> Using this in the REPL: 
> julia> workspace() ; include("mike.jl")
>
> julia> using Foo
>
> julia> value(Foo.FooType())
> "Foo::value"
>
> julia> using Bar
> Warning: using Bar.value in module Main conflicts with an existing 
> identifier.
>
> julia> value(Bar.BarType())
> ERROR: `value` has no method matching value(::BarType)
>
> # -
>
> julia> workspace() ; include("mike.jl")
>
> julia> using Foo
>
> julia> using Bar
>
> julia> value(Foo.FooType())
> ERROR: `value` has no method matching value(::FooType)
>
> julia> value(Bar.BarType())
> "Bar::value"
>
> # -
>
> julia> workspace() ; include("mike.jl")
>
> julia> using Bar
>
> julia> using Foo
>
> julia> value(Foo.FooType())
> "Foo::value"
>
> julia> value(Bar.BarType())
> ERROR: `value` has no method matching value(::BarType)
>
> julia> 
>

Re: [julia-users] Roadmap for 0.4?

[Michael Turok]

Going back to this thread:   do we have a roadmap for 0.4 somewhere?   I 
see the milestone issues, but not a formal roadmap specification as 
described below.

Thanks!
Michael

On Tuesday, July 29, 2014 at 12:49:49 PM UTC-4, Stefan Karpinski wrote:
>
> There is no official roadmap for 0.4 yet – just a collection of ideas in 
> various people's heads and spread across our mailing group and GitHub 
> discussions. A few major changes that come to mind off the top of my head:
>
>- array views
>- string + I/O revamp
>- pkg revamp (again)
>- static compilation
>- multithreading
>- built-in debugger
>
> That is a pretty significant set of features. As always, there's a chance 
> that not all of these will make it into 0.4, but I'm fairly confident about 
> most of these.
>
>
> On Tue, Jul 29, 2014 at 12:41 PM, D johnson  > wrote:
>
>> I saw the Roadmap for 0.3 here: 
>> https://github.com/JuliaLang/julia/issues/4853
>>
>> But I cannot find the Roadmap for 0.4...  Does anyone know where that is 
>> located?
>>
>> thx
>>
>
>

Re: [julia-users] Using Julia program as computation backend

[Michael Turok]

I have to admit that I looked at Morsel and JuliaWebAPI (back when it was 
JuliaBox.jl).I found Morsel to have a more intuitive API in the way you 
describe your routes.

But looks like Mux might be an even better solution.

On Tuesday, May 19, 2015 at 8:53:59 PM UTC-4, Eric Forgy wrote:
>
> Hi Roman,
>
> I have a simple toy model (Morsel) using REST API (well http anyway) that 
> I'm happy with, but Julia Computing (i.e. Viral :)) is convincing me to go 
> with JuliaWebAPI.jl  (formally 
> JuliaBox.jl). I'd be happy to see more people take interest and help 
> improve JuliaWebAPI for exactly this purpose. It currently supports REST 
> and ZeroMQ.
>
> Best regards,
> Eric
>
>
> On Wednesday, May 20, 2015 at 6:22:38 AM UTC+8, Jeff Waller wrote:
>>
>>
>>
>> On Monday, May 18, 2015 at 10:55:10 AM UTC-4, Roman Kravchik wrote:
>>>
>>> Thanks for the link.
>>> But it seems to be like CGI-style operation - eval julia expression and 
>>> i'm not sure it's a perspective direction.
>>>
>>
>> Hmm, if I I'm understanding this correctly, then no, it's not CGI-like; 
>> there is no exec-ing of a process per call.
>>
>

[julia-users] Self-Referential Types and GC and WeakRef

[Michael Turok]

In looking at the manual for incompletely initialized classes (click here 
),
 
with an example of a SelfReferential class, wouldn't you want to wrap this 
in a WeakRef()?

Or does the GC know what to do when it encounters a circular reference 
already?

Thanks,
Michael

Re: [julia-users] Self-Referential Types and GC and WeakRef

[Michael Turok]

Thanks folks!I guess that's also why WeakRef() isn't documented.  ;-)

On Tuesday, May 26, 2015 at 4:06:29 PM UTC-4, Stefan Karpinski wrote:
>
> Yes, that's right. Cycles are collected by mark-and-sweep GC – when a 
> cyclic structure is no longer reachable, none of it is marked, allowing it 
> to be freed during the sweep phase.
>
> On Tue, May 26, 2015 at 11:37 AM, Yichao Yu  > wrote:
>
>> On Tue, May 26, 2015 at 11:31 AM, Michael Turok > > wrote:
>> > In looking at the manual for incompletely initialized classes (click 
>> here),
>> > with an example of a SelfReferential class, wouldn't you want to wrap 
>> this
>> > in a WeakRef()?
>> >
>> > Or does the GC know what to do when it encounters a circular reference
>> > already?
>>
>> AFAICT, circular reference is only an issue for reference counting.
>> Julia's mark and sweep GC doesn't have that problem.
>>
>> >
>> > Thanks,
>> > Michael
>>
>
>

[julia-users] Debugger

[Michael Turok]

Is there anyone currently focusing on building an AST-level debugger that 
can navigate stack frames and not require modifying code to insert 
instrumentation stubs, etc?

While the LLVM JIT debugger referenced in the below thread from December 
2013 is interesting, seems like there might be more low-lying fruit out 
there.

https://groups.google.com/forum/#!searchin/julia-users/debugger/julia-users/zEqWxn7HDVo/ZTRZh4ziR9kJ

Re: [julia-users] Debugger

[Michael Turok]

Right, but I'm interested in an debugger that would work without a custom 
compilation of LLVM, and would work with a stock release of julia 0.3*.

On Tuesday, June 2, 2015 at 11:11:09 AM UTC-4, Isaiah wrote:

> https://groups.google.com/d/msg/julia-dev/gcZ5dZJni5o/VYaLkCd756cJ
>
> On Tue, Jun 2, 2015 at 11:07 AM, Michael Turok  > wrote:
>
>> Is there anyone currently focusing on building an AST-level debugger that 
>> can navigate stack frames and not require modifying code to insert 
>> instrumentation stubs, etc?
>>
>> While the LLVM JIT debugger referenced in the below thread from December 
>> 2013 is interesting, seems like there might be more low-lying fruit out 
>> there.
>>
>>
>> https://groups.google.com/forum/#!searchin/julia-users/debugger/julia-users/zEqWxn7HDVo/ZTRZh4ziR9kJ
>>
>
>

Re: [julia-users] Debugger

[Michael Turok]

Yes - but it hasn't gotten much attention over the last two years (and 
sorry, I thought I had mentioned Debug.jl in my initial post).

https://github.com/toivoh/Debug.jl/graphs/code-frequency

Feels like there could be a lot of work there that would be tremendously 
helpful, but not sure if people are focused on it (and instead attention is 
on being able to seamlessly navigate from julia -> c).   

Is anyone working on extending the functionality there, or is it viewed as 
a developmental dead end?

Michael

On Tuesday, June 2, 2015 at 11:31:04 AM UTC-4, Tim Holy wrote:
>
> https://github.com/toivoh/Debug.jl 
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Ftoivoh%2FDebug.jl&sa=D&sntz=1&usg=AFQjCNFVItS_nt9vtR2lzYEoYZu8ZhxJwA>
>  
>
> --Tim 
>
> On Tuesday, June 02, 2015 08:21:51 AM Michael Turok wrote: 
> > Right, but I'm interested in an debugger that would work without a 
> custom 
> > compilation of LLVM, and would work with a stock release of julia 0.3*. 
> > 
> > On Tuesday, June 2, 2015 at 11:11:09 AM UTC-4, Isaiah wrote: 
> > > https://groups.google.com/d/msg/julia-dev/gcZ5dZJni5o/VYaLkCd756cJ 
> > > 
> > > On Tue, Jun 2, 2015 at 11:07 AM, Michael Turok  > > 
> > > > wrote: 
> > >> Is there anyone currently focusing on building an AST-level debugger 
> that 
> > >> can navigate stack frames and not require modifying code to insert 
> > >> instrumentation stubs, etc? 
> > >> 
> > >> While the LLVM JIT debugger referenced in the below thread from 
> December 
> > >> 2013 is interesting, seems like there might be more low-lying fruit 
> out 
> > >> there. 
> > >> 
> > >> 
> > >> 
> https://groups.google.com/forum/#!searchin/julia-users/debugger/julia-use 
> > >> rs/zEqWxn7HDVo/ZTRZh4ziR9kJ 
>
>

[julia-users] Re: Getting information about containing module, file, line number, method/type, etc.

[Michael Turok]

One other observation is that the AST contains file/line number information 
for blocks defined within it.

Not sure how the backtrace and the AST annotations are intended to interact.

On Monday, June 8, 2015 at 8:47:18 AM UTC-4, Tom Breloff wrote:
>
> 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: API deployments on JuliaBox

[Michael Turok]

Hi Tanmay,

Is there an example of enabling the API endpoints when building a 
stand-alone juliabox instance?

Thanks,
Michael

On Sunday, September 27, 2015 at 9:25:44 PM UTC-4, tanmaykm wrote:
>
> Hi Miguel,
>
> Server instances are created per API. Server instances are stateless, and 
> are reused across API calls and across users. Based on load, an API can 
> also have more than one server instances.
>
> Server instances are brought up on a clean Julia container. They do not 
> have any files from the user's account. So listing the files will show a 
> folder that is mostly empty.
>
> While registering an API endpoint, you are required to submit a short 
> bootstrap code. When a new instance of the API server needs is brought up, 
> the bootstrap code is executed on a clean Julia container on startup. The 
> bootstrap code should then pull the remaining code/data to handle API calls.
>
> It is possible to pull from non public repos or private S3 URLs too, by 
> embedding the access keys in the bootstrap code. The bootstrap code is 
> visible only to the publisher (that is you for all of your APIs). We have 
> thought about having better support for non-public repos and pre-build 
> docker images with binary code as well in the future.
>
> Also, JuliaBox does not currently provide any permanent storage for the 
> APIs. But it is possible to access storage/databases like (e.g. S3, 
> DynamoDB) over the internet.
>
> Best,
> Tanmay
>
> On Sunday, September 27, 2015 at 11:44:32 PM UTC+5:30, Miguel Belbut 
> Gaspar wrote:
>>
>> Hi,
>>
>> Thanks for this, it is a very interesting feature.
>>
>> I think I have the same question as the previous post, which I think 
>> wasn't addressed by tanmaykm's answer:
>>
>> Is the server created per-user? If I expose a ls() command, will it list 
>> my own account home files?
>> I tried using require(Juliaset.jl/src/Juliaset.jl) instead of 
>> Pkg.clone(...) as the API command, after having sync'ed the Juliaset.jl git 
>> to my Juliabox account, but that doesn't seem to work.
>>
>> Is that by design, i.e., the APIs must have publicly-available source?
>> Or is it just a current limitation and if so, are there any plans to 
>> allow using non-public repos or source files in  some way?
>>
>> Cheers,
>>
>> Miguel
>>
>> On Tuesday, September 15, 2015 at 11:44:55 AM UTC+1, tanmaykm wrote:
>>>
>>> Hi,
>>>
>>> yes, that's right. The APIs will let you share useful functionalities as 
>>> REST APIs to other users.
>>>
>>> The API published with name "list_it" can be accessed at 
>>> https://api.juliabox.org/list_it/...
>>> The "..." above refer to the exact method being called and the 
>>> parameters it expects.
>>> From anywhere (including from within the JuliaBox container), any 
>>> mechanism to invoke HTTP can be used.
>>> All APIs are accessible to everyone, unless the API implementation 
>>> imposes some authorization.
>>>
>>> a couple of examples of JuliaBox APIs can be found at:
>>> - https://github.com/tanmaykm/Juliaset.jl
>>> - https://github.com/tanmaykm/JuliaWebAPI.jl
>>>
>>> Best,
>>> Tanmay
>>>

[julia-users] Re: API deployments on JuliaBox

[Michael Turok]

Thanks - will try!

On Wednesday, November 4, 2015 at 8:28:39 PM UTC-5, Tanmay K. Mohapatra 
wrote:
>
> Hi Michael,
>
> these two configuration changes should do it:
> - enable the "juliabox.plugins.api_admin" plugin (in 
> /jboxengine/conf/jbox.user) and rebuild (img_create.sh jbox)
> - have a hostname alias with "api." prefix pointing to the machine (e.g. 
> api.juliabox.org. the webserver routes all api.* requests to the api 
> handler and others to the interactive sessions handler)
>
> Best,
> Tanmay
>
> On Thursday, November 5, 2015 at 6:39:54 AM UTC+5:30, Michael Turok wrote:
>>
>> Hi Tanmay,
>>
>> Is there an example of enabling the API endpoints when building a 
>> stand-alone juliabox instance?
>>
>> Thanks,
>> Michael
>>
>> On Sunday, September 27, 2015 at 9:25:44 PM UTC-4, tanmaykm wrote:
>>>
>>> Hi Miguel,
>>>
>>> Server instances are created per API. Server instances are stateless, 
>>> and are reused across API calls and across users. Based on load, an API can 
>>> also have more than one server instances.
>>>
>>> Server instances are brought up on a clean Julia container. They do not 
>>> have any files from the user's account. So listing the files will show a 
>>> folder that is mostly empty.
>>>
>>> While registering an API endpoint, you are required to submit a short 
>>> bootstrap code. When a new instance of the API server needs is brought up, 
>>> the bootstrap code is executed on a clean Julia container on startup. The 
>>> bootstrap code should then pull the remaining code/data to handle API calls.
>>>
>>> It is possible to pull from non public repos or private S3 URLs too, by 
>>> embedding the access keys in the bootstrap code. The bootstrap code is 
>>> visible only to the publisher (that is you for all of your APIs). We have 
>>> thought about having better support for non-public repos and pre-build 
>>> docker images with binary code as well in the future.
>>>
>>> Also, JuliaBox does not currently provide any permanent storage for the 
>>> APIs. But it is possible to access storage/databases like (e.g. S3, 
>>> DynamoDB) over the internet.
>>>
>>> Best,
>>> Tanmay
>>>
>>> On Sunday, September 27, 2015 at 11:44:32 PM UTC+5:30, Miguel Belbut 
>>> Gaspar wrote:
>>>>
>>>> Hi,
>>>>
>>>> Thanks for this, it is a very interesting feature.
>>>>
>>>> I think I have the same question as the previous post, which I think 
>>>> wasn't addressed by tanmaykm's answer:
>>>>
>>>> Is the server created per-user? If I expose a ls() command, will it 
>>>> list my own account home files?
>>>> I tried using require(Juliaset.jl/src/Juliaset.jl) instead of 
>>>> Pkg.clone(...) as the API command, after having sync'ed the Juliaset.jl 
>>>> git 
>>>> to my Juliabox account, but that doesn't seem to work.
>>>>
>>>> Is that by design, i.e., the APIs must have publicly-available source?
>>>> Or is it just a current limitation and if so, are there any plans to 
>>>> allow using non-public repos or source files in  some way?
>>>>
>>>> Cheers,
>>>>
>>>> Miguel
>>>>
>>>> On Tuesday, September 15, 2015 at 11:44:55 AM UTC+1, tanmaykm wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> yes, that's right. The APIs will let you share useful functionalities 
>>>>> as REST APIs to other users.
>>>>>
>>>>> The API published with name "list_it" can be accessed at 
>>>>> https://api.juliabox.org/list_it/...
>>>>> The "..." above refer to the exact method being called and the 
>>>>> parameters it expects.
>>>>> From anywhere (including from within the JuliaBox container), any 
>>>>> mechanism to invoke HTTP can be used.
>>>>> All APIs are accessible to everyone, unless the API implementation 
>>>>> imposes some authorization.
>>>>>
>>>>> a couple of examples of JuliaBox APIs can be found at:
>>>>> - https://github.com/tanmaykm/Juliaset.jl
>>>>> - https://github.com/tanmaykm/JuliaWebAPI.jl
>>>>>
>>>>> Best,
>>>>> Tanmay
>>>>>
>>>>>>
>>>>>>

[julia-users] Re: Boost.Python-like CppWrapper package

[Michael Turok]

Bart - thank youvery interesting project

Very much in favor of having a way of statically interfacing to C++ from 
Julia (and we have started to think about also wanting SWIG, given that 
some interfaces already are described with it). 

Cxx is very interesting and differentiating, but still a bit far away from 
production use (plus, likely needing some form of precompilation, unless 
you want to ship around development header files).  

On Friday, November 13, 2015 at 3:51:34 AM UTC-5, Bart Janssens wrote:
>
> Hi Steven,
>
> Yes, that's exactly right. I'd just like to add that the specific use case 
> that I have in mind are C++ projects that already invested in a Python 
> interface using Boost.Python. The aim is to make it easy to add a Julia 
> interface with little effort.
> This is not intended to compete with Cxx.jl, depending on the exact nature 
> of the C++ project authors may prefer doing the wrapping work in C++ (with 
> CppWrapper.jl) or in Julia (with Cxx.jl).
>
> Cheers,
>
> Bart
>

[julia-users] Apache Arrow/Feather

[Michael Turok]

Any thoughts here on the efforts to build a unified dataframe format 
between R and Python via Apache Arrow (and Feather?)

Regards,
Michael