Re: [julia-users] Optional Arguments for Do-Block Syntax for Functions

[Adrian Salceanu]

Got it, thanks

vineri, 11 noiembrie 2016, 19:11:28 UTC+1, Stefan Karpinski a scris:
>
> You can use a name like _ but otherwise, no, there's no way to do this.
>
> On Fri, Nov 11, 2016 at 11:46 AM, Adrian Salceanu <adrian@gmail.com 
> > wrote:
>
>> I love the block syntax for functions as it provides great readability 
>> and I'm using it heavily as a design pattern to enclose code behind 
>> authorization or caching. 
>>
>> For example: 
>>
>> function article_edit(params::Dict{Symbol,Any}; a::Article = Article())
>>   with_authorization(:edit, unauthorized_access, params) do auth_scopes
>> article = SearchLight.is_persisted(a) ? a : SearchLight.find_one!!(
>> Article, params[:article_id])
>> ejl(:admin, :article, layout = :admin, article = article, params = 
>> params) |> respond
>>   end
>> end
>>
>> I was wondering if there's any way to make the auth_scopes param 
>> optional for the cases when the users are not interested in this passed 
>> value. Similarly to how in the ruby blocks you're not required to capture 
>> the values that are passed into, if you don't want them. It will help to 
>> greatly reduce the noise, especially when multiple params are expected. 
>>
>
>

[julia-users] Optional Arguments for Do-Block Syntax for Functions

[Adrian Salceanu]

I love the block syntax for functions as it provides great readability and 
I'm using it heavily as a design pattern to enclose code behind 
authorization or caching. 

For example: 

function article_edit(params::Dict{Symbol,Any}; a::Article = Article())
  with_authorization(:edit, unauthorized_access, params) do auth_scopes
article = SearchLight.is_persisted(a) ? a : SearchLight.find_one!!(
Article, params[:article_id])
ejl(:admin, :article, layout = :admin, article = article, params = 
params) |> respond
  end
end

I was wondering if there's any way to make the auth_scopes param optional 
for the cases when the users are not interested in this passed value. 
Similarly to how in the ruby blocks you're not required to capture the 
values that are passed into, if you don't want them. It will help to 
greatly reduce the noise, especially when multiple params are expected. 

Re: [julia-users] using or import a specific package version

[Adrian Salceanu]

I have used DeclarativePackages 
(https://github.com/rened/DeclarativePackages.jl) - it's quite all right. 
Also, a while ago I've stumbled onto Playground 
(https://github.com/Rory-Finnegan/Playground.jl) but I haven't tried it 
myself. 


sâmbătă, 5 noiembrie 2016, 15:09:50 UTC+2, Steven G. Johnson a scris:
>
>
>
> On Saturday, November 5, 2016 at 12:38:41 AM UTC-4, Tom Lee wrote:
>>
>> Project-local environments sounds like exactly what I am after. Great to 
>> hear its being worked on. I guess we will need to wait until 0.6 for Pkg3?
>>
>
> No, you can do that now.
>
> insert!(LOAD_PATH, 1, mypath)
> insert!(Base.LOAD_CACHE_PATH, 1, mypath)
>
> will add mypath to the module and cache loading path.  Then you can put 
> whatever modules you want into mypath and they will take precedence over 
> the ones in the standard path.
>

[julia-users] Re: Webapp Deployment

[Adrian Salceanu]

My experience with Escher is limited to reading the docs and looking at the 
sources, but it seems to be related to loading the file (or it's content): 

function loadfile(filename)
if isfile(filename)
try
ui = include(filename)
if isa(ui, Function)
return ui
else
warn("$filename did not return a function")
return (w) -> Elem(:p, string(
filename, " did not return a UI function"
))
end
catch err
bt = backtrace()
return (win) -> Elem(:pre, sprint() do io
showerror(io, err)
Base.show_backtrace(io, bt)
end)
end
else
return (w) -> Elem(:p, string(
filename, " could not be found."
))
end
end
in https://github.com/shashi/Escher.jl/blob/master/src/cli/serve.jl

So maybe make sure the example files are accessible (readable)? 

You can use the usual communication paths: a new issue in GitHub or 
StackOverflow. Also, check if there's a Gitter channel for Escher. 


marți, 1 noiembrie 2016, 09:38:11 UTC+2, Reuben Brooks a scris:
>
> When I try to run the examples or basic hello.jl file in Escher, always 
> get this in browser: ".../Escher/examples/hello.jl did not return a UI 
> function"
>
> I don't see any issues filed on github with this, suspect it's something 
> on my end. What would be the appropriate channel for me to get some help on 
> this?
>
> On Tuesday, November 1, 2016 at 1:10:18 AM UTC-5, Adrian Salceanu wrote:
>>
>> Sounds like the answer is https://github.com/shashi/Escher.jl 
>>
>> It was built exactly for your use case and it's actually inspired by Elm 
>>
>>
>>
>> marți, 1 noiembrie 2016, 06:08:01 UTC+2, Reuben Brooks a scris:
>>>
>>> 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?
>>>
>>

[julia-users] Re: Webapp Deployment

[Adrian Salceanu]

Sounds like the answer is https://github.com/shashi/Escher.jl 

It was built exactly for your use case and it's actually inspired by Elm 



marți, 1 noiembrie 2016, 06:08:01 UTC+2, Reuben Brooks a scris:
>
> 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?
>

[julia-users] Re: eval in current scope

[Adrian Salceanu]

Yichao, not long ago I had a similar question (it was in the context of 
building a templating system), you were very kind and point me in the right 
direction. So I kept digging. 

Marius, sorry for piggy backing on your question, but I'm curious about 
some code that seems to do the trick. I'm curious if I'm missing anything. 

# A.jl
push!(LOAD_PATH, ".")

module A
using B

function a()
  @injectvar
  println("in a()")
  @show external_var
end

a()

try
  println("in A")
  @show external_var
catch ex
  @show ex
end

end

#B.jl
module B
export @injectvar

macro injectvar()
  esc(:(external_var = 5))
end

end

If I run A.jl I get: 

in a()
external_var = 5
in A
ex = UndefVarError(:external_var)


So external_var is defined in A.a() but not in A. 

# C.jl
push!(LOAD_PATH, ".")

module C
using A

A.a()

try
  println("in C")
  @show external_var
catch ex
  @show ex
end

end


Similarely, if I run C.jl I get

in a()
external_var = 5
in A
ex = UndefVarError(:external_var)
in a()
external_var = 5
in C
ex = UndefVarError(:external_var)


external_var is only available inside the function. 


marți, 27 septembrie 2016, 14:36:48 UTC+2, Jussi Piitulainen a scris:
>
> You might be able to wrap your expression so as to create a function 
> instead, and call the function with the values of the variables that the 
> actual expression depends on. In Python, because I haven't learned to 
> construct expressions in Julia yet and don't have the time to learn it now:
>
> def f(x): return eval("lambda x: x + 1")(x)
>
>
>
> tiistai 27. syyskuuta 2016 12.28.40 UTC+3 Marius Millea kirjoitti:
>>
>> Hi, is there a way to "eval" something in the current scope? My problem 
>> is the following, I've written a macro that, inside the returned 
>> expression, builds an expression which I need to eval. It looks like this,
>>
>> macro foo()
>> quote
>> ex = ...
>> eval_in_current_scope(ex)
>> end
>> end
>>
>> Now, you might say I'm using macros wrong and I should just be doing,
>>
>> macro foo()
>> ex = ...
>> end
>>  
>>
>> but in this case when I build "ex", it needs to occur at runtime since it 
>> depends on some things only available then. So is there any way to go about 
>> this? Thanks. 
>>
>>

Re: [julia-users] Julia's current state of web-programming

[Adrian Salceanu]

Escher is pretty cool, but it’s more about data interactions and
visualizations (dashboards?), rather than building full featured web apps
and products.

I’m working on Genie: https://github.com/essenciary/Genie.jl a full stack
MVC web framework for Julia, in the spirit of Rails or Django.

It now runs smoothly on both 0.4 and 0.5 - it’s still WIP, but it’s got
pretty much all the necessary features already (ORM, templating system,
authentication, authorization, caching, migrations, model validators, etc).
Also, it now takes full advantage of Julia’s parallel programming
capabilities, using multiple cores to handle requests, which is pretty
cool.

If you check here: http://genieframework.com/packages (built with Genie
btw) you’ll find a few more options - like Merly and Bukdu.

Other than that you have the low(er) level components: Mux, HttpServer,
WebSockets.

On September 22, 2016 at 17:44:11, Alexey Cherkaev (
alexey.cherk...@gmail.com) wrote:

Hi all,

What is the current state of web programming with Julia?

http://juliawebstack.org/ seems quite out of date (still suggesting to use
Morsel, which is marked as deprecated).

Escher looks quite nice (https://github.com/shashi/Escher.jl), but still
fails to build on both 0.4 and 0.5 versions (but it does seem to be
actively developed).

Thanks!
Alexey

[julia-users] Re: Complex parallel computing implementation

[Adrian Salceanu]

Thanks - haven't thought of using Dagger (don't have previous experience 
with it either). I've read the docs now but I'm not sure how using it would 
help, maybe I'm missing something? 

My problem is really about running deeply nested function calls across 
multiple modules, in parallel. Making the code available to the workers 
involves a lot of back tracking, module by module and function by function, 
prepending @everywhere, well... everywhere. Cherry picking function calls 
in a few thousands lines codebase to make it load across processes is a 
task for computers, not people. Is this the idiomatic Julia way, because it 
really feels like I'm misusing the language? Am I supposed to end up with 
tens of calls to @everywhere? - it doesn't feel right... 
 

luni, 12 septembrie 2016, 23:53:06 UTC+2, dnm a scris:
>
> Have you tried Dagger.jl <https://github.com/JuliaParallel/Dagger.jl> to 
> set up a DAG of computations you need performed?
>
> On Monday, September 12, 2016 at 5:04:26 PM UTC-4, Adrian Salceanu wrote:
>>
>> This is a random example of an error - not really sure how to debug this, 
>> seems to crash within the Postgres library. The dump is long but not really 
>> helpful. 
>>
>> 12-Sep 21:39:38:WARNING:root:Module __anon__ not defined on process 5
>> 12-Sep 21:39:38:WARNING:root:Module __anon__ not defined on process 3
>> 12-Sep 21:39:39:WARNING:root:Module __anon__ not defined on process 2
>> fatal error on fatal error on 3: ERROR: attempt to send to unknown socket
>> 4: ERROR: attempt to send to unknown socket
>> 12-Sep 21:39:39:WARNING:root:Module __anon__ not defined on process 3
>> 12-Sep 21:39:39:WARNING:root:Module __anon__ not defined on process 5
>> fatal error on 3: ERROR: attempt to send to unknown socket
>> 12-Sep 21:39:39:WARNING:root:Module __anon__ not defined on process 3
>> fatal error on 2: ERROR: attempt to send to unknown socket
>> ERROR: LoadError: On worker 2:
>> LoadError: On worker 2:
>> LoadError: LoadError: LoadError: LoadError: LoadError: 
>> ProcessExitedException()
>>  in yieldto at /usr/local/Cellar/julia/0.4.6_1/lib/julia/sys.dylib
>>  in wait at /usr/local/Cellar/julia/0.4.6_1/lib/julia/sys.dylib (repeats 
>> 3 times)
>>  in take! at /usr/local/Cellar/julia/0.4.6_1/lib/julia/sys.dylib (repeats 
>> 2 times)
>>  in remotecall_fetch at multi.jl:745
>>  in remotecall_fetch at multi.jl:750
>>  in anonymous at multi.jl:1396
>>
>> ...and 1 other exceptions.
>>
>>  in include_string at loading.jl:282
>>  in include_from_node1 at 
>> /usr/local/Cellar/julia/0.4.6_1/lib/julia/sys.dylib
>>  in require at /usr/local/Cellar/julia/0.4.6_1/lib/julia/sys.dylib
>>  in include_string at loading.jl:282
>>  in include_from_node1 at 
>> /usr/local/Cellar/julia/0.4.6_1/lib/julia/sys.dylib
>>  in require at /usr/local/Cellar/julia/0.4.6_1/lib/julia/sys.dylib
>>  in eval at 
>> /Users/adrian/Dropbox/Projects/jinnie/lib/Genie/src/Database.jl:1
>>  in include_string at loading.jl:282
>>  in include_from_node1 at 
>> /usr/local/Cellar/julia/0.4.6_1/lib/julia/sys.dylib
>>  in require at /usr/local/Cellar/julia/0.4.6_1/lib/julia/sys.dylib
>>  in include_string at loading.jl:282
>>  in include_from_node1 at 
>> /usr/local/Cellar/julia/0.4.6_1/lib/julia/sys.dylib
>>  in eval at /usr/local/Cellar/julia/0.4.6_1/lib/julia/sys.dylib
>>  in anonymous at multi.jl:1394
>>  in run_work_thunk at multi.jl:661
>>  in remotecall_fetch at multi.jl:734
>>  in remotecall_fetch at multi.jl:750
>>  in anonymous at multi.jl:1396
>> while loading /Users/adrian/.julia/v0.4/PostgreSQL/src/../deps/build.jl, 
>> in expression starting on line 9
>> while loading /Users/adrian/.julia/v0.4/PostgreSQL/src/PostgreSQL.jl, in 
>> expression starting on line 8
>> while loading 
>> /Users/adrian/Dropbox/Projects/jinnie/lib/Genie/database_adapters/PostgreSQLDatabaseAdapter.jl,
>>  
>> in expression starting on line 3
>> while loading 
>> /Users/adrian/Dropbox/Projects/jinnie/lib/Genie/src/Database.jl, in 
>> expression starting on line 7
>> while loading 
>> /Users/adrian/Dropbox/Projects/jinnie/lib/Genie/src/commands.jl, in 
>> expression starting on line 11
>>  in remotecall_fetch at multi.jl:735
>>  in remotecall_fetch at multi.jl:750
>>  in anonymous at multi.jl:1396
>>
>> ...and 1 other exceptions.
>>
>>  in sync_end at /usr/local/Cellar/julia/0.4.6_1/lib/julia/sys.dylib
>>  in anonymous at multi.jl:1405
>>  in include_string at loading.jl:282
>>  in include_from_node1 at 
>> /usr/local/Cellar/julia/0.4.6_1/lib/julia/sys.dylib
>

[julia-users] Re: Complex parallel computing implementation

[Adrian Salceanu]

This is a random example of an error - not really sure how to debug this, 
seems to crash within the Postgres library. The dump is long but not really 
helpful. 

12-Sep 21:39:38:WARNING:root:Module __anon__ not defined on process 5
12-Sep 21:39:38:WARNING:root:Module __anon__ not defined on process 3
12-Sep 21:39:39:WARNING:root:Module __anon__ not defined on process 2
fatal error on fatal error on 3: ERROR: attempt to send to unknown socket
4: ERROR: attempt to send to unknown socket
12-Sep 21:39:39:WARNING:root:Module __anon__ not defined on process 3
12-Sep 21:39:39:WARNING:root:Module __anon__ not defined on process 5
fatal error on 3: ERROR: attempt to send to unknown socket
12-Sep 21:39:39:WARNING:root:Module __anon__ not defined on process 3
fatal error on 2: ERROR: attempt to send to unknown socket
ERROR: LoadError: On worker 2:
LoadError: On worker 2:
LoadError: LoadError: LoadError: LoadError: LoadError: 
ProcessExitedException()
 in yieldto at /usr/local/Cellar/julia/0.4.6_1/lib/julia/sys.dylib
 in wait at /usr/local/Cellar/julia/0.4.6_1/lib/julia/sys.dylib (repeats 3 
times)
 in take! at /usr/local/Cellar/julia/0.4.6_1/lib/julia/sys.dylib (repeats 2 
times)
 in remotecall_fetch at multi.jl:745
 in remotecall_fetch at multi.jl:750
 in anonymous at multi.jl:1396

...and 1 other exceptions.

 in include_string at loading.jl:282
 in include_from_node1 at 
/usr/local/Cellar/julia/0.4.6_1/lib/julia/sys.dylib
 in require at /usr/local/Cellar/julia/0.4.6_1/lib/julia/sys.dylib
 in include_string at loading.jl:282
 in include_from_node1 at 
/usr/local/Cellar/julia/0.4.6_1/lib/julia/sys.dylib
 in require at /usr/local/Cellar/julia/0.4.6_1/lib/julia/sys.dylib
 in eval at 
/Users/adrian/Dropbox/Projects/jinnie/lib/Genie/src/Database.jl:1
 in include_string at loading.jl:282
 in include_from_node1 at 
/usr/local/Cellar/julia/0.4.6_1/lib/julia/sys.dylib
 in require at /usr/local/Cellar/julia/0.4.6_1/lib/julia/sys.dylib
 in include_string at loading.jl:282
 in include_from_node1 at 
/usr/local/Cellar/julia/0.4.6_1/lib/julia/sys.dylib
 in eval at /usr/local/Cellar/julia/0.4.6_1/lib/julia/sys.dylib
 in anonymous at multi.jl:1394
 in run_work_thunk at multi.jl:661
 in remotecall_fetch at multi.jl:734
 in remotecall_fetch at multi.jl:750
 in anonymous at multi.jl:1396
while loading /Users/adrian/.julia/v0.4/PostgreSQL/src/../deps/build.jl, in 
expression starting on line 9
while loading /Users/adrian/.julia/v0.4/PostgreSQL/src/PostgreSQL.jl, in 
expression starting on line 8
while loading 
/Users/adrian/Dropbox/Projects/jinnie/lib/Genie/database_adapters/PostgreSQLDatabaseAdapter.jl,
 
in expression starting on line 3
while loading 
/Users/adrian/Dropbox/Projects/jinnie/lib/Genie/src/Database.jl, in 
expression starting on line 7
while loading 
/Users/adrian/Dropbox/Projects/jinnie/lib/Genie/src/commands.jl, in 
expression starting on line 11
 in remotecall_fetch at multi.jl:735
 in remotecall_fetch at multi.jl:750
 in anonymous at multi.jl:1396

...and 1 other exceptions.

 in sync_end at /usr/local/Cellar/julia/0.4.6_1/lib/julia/sys.dylib
 in anonymous at multi.jl:1405
 in include_string at loading.jl:282
 in include_from_node1 at 
/usr/local/Cellar/julia/0.4.6_1/lib/julia/sys.dylib
 in require at /usr/local/Cellar/julia/0.4.6_1/lib/julia/sys.dylib
 in eval at /usr/local/Cellar/julia/0.4.6_1/lib/julia/sys.dylib
 in anonymous at multi.jl:1394
 in anonymous at multi.jl:923
 in run_work_thunk at multi.jl:661
 [inlined code] from multi.jl:923
 in anonymous at task.jl:63
while loading /Users/adrian/Dropbox/Projects/jinnie/lib/Genie/src/Genie.jl, 
in expression starting on line 1
 in remotecall_fetch at multi.jl:747
 in remotecall_fetch at multi.jl:750
 in anonymous at multi.jl:1396

...and 4 other exceptions.

 in sync_end at /usr/local/Cellar/julia/0.4.6_1/lib/julia/sys.dylib
 in anonymous at multi.jl:1405
 in include at /usr/local/Cellar/julia/0.4.6_1/lib/julia/sys.dylib
 in include_from_node1 at 
/usr/local/Cellar/julia/0.4.6_1/lib/julia/sys.dylib
 in process_options at /usr/local/Cellar/julia/0.4.6_1/lib/julia/sys.dylib
 in _start at /usr/local/Cellar/julia/0.4.6_1/lib/julia/sys.dylib
while loading /Users/adrian/Dropbox/Projects/jinnie/genie.jl, in expression 
starting on line 16

luni, 12 septembrie 2016, 23:01:51 UTC+2, Adrian Salceanu a scris:
>
> I was wondering if anybody can point me towards a tutorial or a large code 
> base using parallel computing. Everything that is discussed so far in the 
> docs and books is super simple - take a function, run it in parallel, the 
> end. 
>
> To explain, I'm working on a full stack MVC web framework - so think many 
> functions and a few types grouped in maybe 20 modules. Plus more or less 20 
> other external modules. The workflow that I'm after is: 
>
> 1. bootstrap - load the necessary components to start up the framework 
> (parsing command line args, loading configuration, setting up include 
> paths, etc)
> 2. 

[julia-users] Complex parallel computing implementation

[Adrian Salceanu]

I was wondering if anybody can point me towards a tutorial or a large code 
base using parallel computing. Everything that is discussed so far in the 
docs and books is super simple - take a function, run it in parallel, the 
end. 

To explain, I'm working on a full stack MVC web framework - so think many 
functions and a few types grouped in maybe 20 modules. Plus more or less 20 
other external modules. The workflow that I'm after is: 

1. bootstrap - load the necessary components to start up the framework 
(parsing command line args, loading configuration, setting up include 
paths, etc)
2. start an instance of HttpServer and listen to a port
3. when the server receives a request it invokes a function of the Router 
module which is the entry point into the MVC stack
4. once the Router gets the request, it's pushed up the MVC stack and at 
the end a HttpServer.Response instance is returned

That being said, 
a. my strategy is simple: for each request, spawn the function call at #3 
to a worker
b. imagine that what's at #4 represents 80% of the app, with a multitude of 
functions being invoked across a multitude of modules (ORM, controller, 
Models, Loggers, Databases, Caching, Sessions, Authentication, etc). 

Everything works great single process, but getting the stack to run on 
multiple workers it's a nightmare. I got it to the point where at #3 I can 
invoke a simple function call (something like returning a string or a date) 
and run it on multiple workers. But when I try to invoke the Router and 
snowball the framework, I end up in an avalanche of unknown references. 

The codebase is now littered with calls to @everywhere that add a lot of 
noise. But up to this point I still wasn't able to make it work. The errors 
come from deep within the Julia stack, the workers crash saying that a 
module or function can't be found but there's no stack trace to point me 
towards the location so it's really trial end error commenting and 
uncommenting "include" and "using" statements to see what gives, I get 
errors from within external modules, etc. 

I guess what I'm trying to say is that my experience with parallel 
computing applied to a large codebase is very frustrating. And I was 
wondering if anybody has done a parallel implementation in a larger 
codebase and has any tips on how to attack it. 


P.S.
I might be spoiled by Elixir, but ideally I'd like to be able to spawn 
processes and functions whenever I need, and have the compiler take care of 
making the code available across workers. 
Another thing that would be very useful, also inspired by Elixir, is the 
supervisor design pattern, to look over and restart the workers when they 
crash. 

[julia-users] Re: "WARNING: replacing module" when invoking function with @everywhere - but module not available otherwise

[Adrian Salceanu]

Thanks for the info and for the link, it's a good read. I wonder if anybody 
else has run into the issues Tim Holy mentions, with @everywhere using X. 

Cheers! 


vineri, 9 septembrie 2016, 20:23:22 UTC+2, Patrick Belliveau a scris:
>
> Hi,
>  Running your code effectively executes
>
> @everywhere using HttpServer
>
> This is known to generate those method redefinition warnings. The 
> behaviour of using in a parallel environment is a known unresolved bug. It 
> seems like the best syntax to use right now is
>
> import HttpServer #Executed only on master process
> @everywhere using HttpServer
>
> For a more detailed discussion and links to the relevant issues on github 
> see this thread 
> <https://groups.google.com/forum/#!searchin/julia-users/@everywhere$20using%7Csort:relevance/julia-users/UXrv1YNbYqY/9fEyfa_ECQAJ>
> .
>
> On Friday, September 9, 2016 at 10:04:53 AM UTC-7, Adrian Salceanu wrote:
>>
>> Hi, 
>>
>> I'm fumbling around with a little script with the end goal of running 
>> HttpServer handlers on multiple ports, in parallel, with each handler on a 
>> separate worker. 
>>
>> The code looks like this: 
>>
>> # parallel_http.jl
>> using HttpServer
>>
>>
>> function serve(port::Int)
>>   http = HttpHandler() do req::Request, res::Response
>>   Dates.now() |> string
>>   end
>>
>>
>>   server = Server(http)
>>   run(server, port)
>> end
>>
>>
>> function run_in_parallel()
>>   servers = Vector{RemoteRef}()
>>   for w in workers()
>> println("About to start server on $(8000 + w)")
>> push!(servers, @spawn serve(8000 + w))
>>   end
>>
>>
>>   servers
>> end
>>
>>
>> And in the REPL, running with julia -p 2: 
>>
>> julia> @everywhere include("parallel_http.jl")
>> WARNING: replacing module HttpServer
>> WARNING: Method definition write(Base.IO, HttpCommon.Response) in module 
>> HttpServer at /Users/adrian/.julia/v0.4/HttpServer/src/HttpServer.jl:178 
>> overwritten in module HttpServer at /Users/adrian/.julia/v0.4/HttpServer/
>> src/HttpServer.jl:178.
>> WARNING: replacing module HttpServer
>> WARNING: Method definition write(Base.IO, HttpCommon.Response) in module 
>> HttpServer at /Users/adrian/.julia/v0.4/HttpServer/src/HttpServer.jl:178 
>> overwritten in module HttpServer at /Users/adrian/.julia/v0.4/HttpServer/
>> src/HttpServer.jl:178.
>>
>>
>> julia> servers = run_in_parallel()
>> About to start server on 8002
>> About to start server on 8003
>> 2-element Array{RemoteRef{T<:AbstractChannel},1}:
>>   From worker 3: Listening on 0.0.0.0:8003...
>>  From worker 2: Listening on 0.0.0.0:8002...
>> RemoteRef{Channel{Any}}(2,1,17)
>>  RemoteRef{Channel{Any}}(3,1,18)
>>
>>
>> The WARNING seems to imply that I'm doing something wrong - but if I 
>> don't run "using" on each worker, to avoid the warning, the module is not 
>> available to the worker. Am i missing something? Is there a better way to 
>> do this? Thanks! 
>>
>>

[julia-users] "WARNING: replacing module" when invoking function with @everywhere - but module not available otherwise

[Adrian Salceanu]

Hi, 

I'm fumbling around with a little script with the end goal of running 
HttpServer handlers on multiple ports, in parallel, with each handler on a 
separate worker. 

The code looks like this: 

# parallel_http.jl
using HttpServer


function serve(port::Int)
  http = HttpHandler() do req::Request, res::Response
  Dates.now() |> string
  end


  server = Server(http)
  run(server, port)
end


function run_in_parallel()
  servers = Vector{RemoteRef}()
  for w in workers()
println("About to start server on $(8000 + w)")
push!(servers, @spawn serve(8000 + w))
  end


  servers
end


And in the REPL, running with julia -p 2: 

julia> @everywhere include("parallel_http.jl")
WARNING: replacing module HttpServer
WARNING: Method definition write(Base.IO, HttpCommon.Response) in module 
HttpServer at /Users/adrian/.julia/v0.4/HttpServer/src/HttpServer.jl:178 
overwritten in module HttpServer at /Users/adrian/.julia/v0.4/HttpServer/src
/HttpServer.jl:178.
WARNING: replacing module HttpServer
WARNING: Method definition write(Base.IO, HttpCommon.Response) in module 
HttpServer at /Users/adrian/.julia/v0.4/HttpServer/src/HttpServer.jl:178 
overwritten in module HttpServer at /Users/adrian/.julia/v0.4/HttpServer/src
/HttpServer.jl:178.


julia> servers = run_in_parallel()
About to start server on 8002
About to start server on 8003
2-element Array{RemoteRef{T<:AbstractChannel},1}:
  From worker 3: Listening on 0.0.0.0:8003...
 From worker 2: Listening on 0.0.0.0:8002...
RemoteRef{Channel{Any}}(2,1,17)
 RemoteRef{Channel{Any}}(3,1,18)


The WARNING seems to imply that I'm doing something wrong - but if I don't 
run "using" on each worker, to avoid the warning, the module is not 
available to the worker. Am i missing something? Is there a better way to 
do this? Thanks! 

[julia-users] Re: basic question on structuring modules

[Adrian Salceanu]

If you don't want to use a module you will have to explicitly include the 
file using 
include(path::AbstractString)

And the content of the file will be evaluated in the current context 
(providing mixin behavior). That should be OK for very short scripts / 
apps. 

For anything bigger you should use modules as they provide a namespace like 
structure and help you avoid the error prone task of having to manage file 
paths and includes manually. 

vineri, 9 septembrie 2016, 15:48:34 UTC+2, Neal Becker a scris:
>
> K leo wrote: 
>
> > The module name needs to be the same as the file, so in this case you 
> need 
> > to change the function name. 
> > 
> > On Friday, September 9, 2016 at 9:29:48 PM UTC+8, Neal Becker wrote: 
> >> 
> >> Let's say I have a simple module which contains 1 function called "foo" 
> >> 
> >> I might create foo.jl that contains 
> >> 
> >> foo.jl 
> >> module foo 
> >> 
> >> function foo ... 
> >> end 
> >> 
> >> end 
> >> 
> >> This doesn't work, it seems the module name collides with the function 
> >> name. 
> >> 
> >> foo.jl 
> >> module foo_mod 
> >> 
> >> function foo ... 
> >> end 
> >> 
> >> end 
> >> 
> >> This might be OK, but provokes a warning (here foo -> coef_from_func) 
> >> julia> using coef_from_func 
> >> WARNING: requiring "coef_from_func" in module "Main" did not define a 
> >> corresponding module. 
> >> 
> >> So as a newb, what is the basic way to package up a function like this? 
> >> 
> >> 
>
> If I want a file that just defines 1 function, should I be using a module? 
>   
> Is there a better alternative? 
>
>

[julia-users] Re: basic question on structuring modules

[Adrian Salceanu]

By convention, module names should be PascalCase. 

Thus, you'll end up with 

# Foo.jl 
module Foo 

function foo()
end 

end

Julia being case sensitive, there will be no name clashes. 


vineri, 9 septembrie 2016, 15:29:48 UTC+2, Neal Becker a scris:
>
> Let's say I have a simple module which contains 1 function called "foo" 
>
> I might create foo.jl that contains 
>
> foo.jl 
> module foo 
>
> function foo ... 
> end 
>
> end 
>
> This doesn't work, it seems the module name collides with the function 
> name. 
>
> foo.jl 
> module foo_mod 
>
> function foo ... 
> end 
>
> end 
>
> This might be OK, but provokes a warning (here foo -> coef_from_func) 
> julia> using coef_from_func 
> WARNING: requiring "coef_from_func" in module "Main" did not define a 
> corresponding module. 
>
> So as a newb, what is the basic way to package up a function like this? 
>
>

[julia-users] Re: Questions regarding Julia for general purpose programming (strings, modules, dispatch, inheritance)

[Adrian Salceanu]

That's what I thought too Steven, thanks for confirming it. Can't find any 
updates re `String` though, still talks about `AbstractString`... 


miercuri, 24 august 2016, 15:29:56 UTC+2, Steven G. Johnson a scris:
>
>
>
> On Wednesday, August 24, 2016 at 8:52:37 AM UTC-4, Adrian Salceanu wrote:
>>
>> Is the documentation available anywhere for 0.5? 
>>
>
> http://docs.julialang.org/en/latest/manual/ 
> <http://www.google.com/url?q=http%3A%2F%2Fdocs.julialang.org%2Fen%2Flatest%2Fmanual%2F=D=1=AFQjCNGQR_3N5YRs4PKVdAj7m7cfQ1SEbQ>
>
> although this is technically the bleeding-edge git-master manual (but it 
> is not too different from 0.5 at this point).   Once 0.5 is out,  
> http://docs.julialang.org/en/0.5/manual/ should have the stable manual.
>

[julia-users] Re: Questions regarding Julia for general purpose programming (strings, modules, dispatch, inheritance)

[Adrian Salceanu]

Is the documentation available anywhere for 0.5? 

miercuri, 24 august 2016, 14:01:44 UTC+2, Steven G. Johnson a scris:
>
>
>
> On Wednesday, August 24, 2016 at 5:18:05 AM UTC-4, Adrian Salceanu wrote:
>>
>> a. ASCIIStrings vs UTF8Strings. 
>>
>
> That distinction is going away in Julia 0.5; there is just one type, 
> String.
>
> b. indexing into UTF8 strings. Can bite if you're not careful, but Julia 
>> provides the necessary API to deal with this plus proper documentation. 
>> Just keep it in mind. 
>>
>
> Yes, there is talk of making this less error prone; 
> https://github.com/JuliaLang/julia/issues/9297
>

[julia-users] Re: Questions regarding Julia for general purpose programming (strings, modules, dispatch, inheritance)

[Adrian Salceanu]

> That distinction is going away in Julia 0.5; there is just one type, 
String. 

Yeee, that's great! I guess, with 0.5 RC3 now out, it's a good time to 
finally switch. 

miercuri, 24 august 2016, 14:01:44 UTC+2, Steven G. Johnson a scris:
>
>
>
> On Wednesday, August 24, 2016 at 5:18:05 AM UTC-4, Adrian Salceanu wrote:
>>
>> a. ASCIIStrings vs UTF8Strings. 
>>
>
> That distinction is going away in Julia 0.5; there is just one type, 
> String.
>
> b. indexing into UTF8 strings. Can bite if you're not careful, but Julia 
>> provides the necessary API to deal with this plus proper documentation. 
>> Just keep it in mind. 
>>
>
> Yes, there is talk of making this less error prone; 
> https://github.com/JuliaLang/julia/issues/9297
>

[julia-users] Re: Questions regarding Julia for general purpose programming (strings, modules, dispatch, inheritance)

[Adrian Salceanu]

Hi, 

A bit of context first. 

I'm working on building a full stack web framework in the tradition of 
Rails and Django (https://github.com/essenciary/Genie.jl). And not only 
that I use Julia for general purpose programming, I also come from a 
completely different background, doing almost exclusively web development 
for all my professional life (15 years now of Ruby, PHP, JS, etc). I'm 
building the framework from the outside in: developing a project and 
abstracting away common features into the framework. Here's the first 
project I deployed: http://genieframework.com/packages. It's been very 
stable, running for over 3 months now, no issues whatsoever. 

I'm now working on the second project, a blogging platform. Currently at 
about 5K lines of code, framework + implementation. It's not very big, but 
it's something. 

Now, to answer your questions: 

1. I've had a good experience with Strings. Can't comment about 0.5 as I'm 
still on 0.4.6 but so far so good. The heaviest things I did with strings 
were part of a templating system, parsing HTML files, extracting markup, 
etc. Dealing with hundreds of lines of HTML or files of tens of KB like a 
hot knife through butter. Of course, depending on your use case, milage 
might vary. 

Some things that stroke me as weird-ish about Strings: 

a. ASCIIStrings vs UTF8Strings. Say you work with external generated 
content that you get from a DB (or web or whatever). Depending on the 
actual content of the string, Julia will generate an ASCIIString or a 
UTF8String. And they don't automatically convert between each other, so if 
you expect one type and get the other, you'll get an error. So I ended up 
using AbstractString everywhere the type of string I'll get was unknown 
(which was almost everywhere) - but using Abstract types is a performance 
no-no according to the docs. So if any of the experienced Julia users could 
recommended a way to deal with this, that'd be awesome! I kept pondering 
about this but could not find a definitive answer. 

b. indexing into UTF8 strings. Can bite if you're not careful, but Julia 
provides the necessary API to deal with this plus proper documentation. 
Just keep it in mind. 

2. I did a bit of thinking on this one when implementing the ORM. You know, 
have your objects map to database tables, with one class per table and one 
instance per row, with properties mapped to table columns. So these types 
would be defined by the users of the framework, modeled according to their 
DB tables. And the framework provides a rich API for working with these 
objects and interacting with the underlying DB (all CRUD operations) 
without touching SQL. Traditionally, in Ruby or PHP, these models inherit 
from a base Model class and get all the needed behavior. 

In Julia I obtained the same effect by employing parametric methods. I have 
defined an AbstractModel and all the user models would extend it. And all 
the methods operate on {T<:AbstractModel}. Works great! 

3. a common design pattern in web frameworks in the mainstream OOP 
languages is to map standard CRUD operations to certain controller methods 
(by convention). So you'll have index() for listing, show() for one item, 
create() for adding, update() for updating, etc. All these methods take the 
same single param, which provides them context (usually data related to the 
request). 
Another design pattern is that you'll have a controller for each business 
object - and each controller will have the mentioned methods for 
manipulating its data. 

You can probably see where I'm going with this: the need to have lots of 
methods with the same name and same param and having to invoke the right 
one. 

In standard OOP, you have a controller class for each business object and 
the methods are encapsulated (ClientController, UserController, 
ProductController). Then you invoke the one you need. I approached things 
in the same manner in Julia - but this was kind of bad. I was forced to 
create empty concrete controller types just to be able to use them as 
additional params, to allow me to invoke the correct method. That felt 
crappy so I refactored my code to use modules instead of types for defining 
the controllers and it works great! 

So the point is, sometimes (many times?) you can't port design patterns 
from another language using the exact implementation. In both cases above, 
ORM and Controller, you need to take the core idea and implement it the 
Julia way. Otherwise you'll just force yourself onto the language and the 
end result will be suboptimal. 

4. I already touched this above - it's core, you can't live without it. And 
you should't try to. If you want to use Julia, that is core Julia and you 
need to embrace it as such. It takes a bit of getting used to, but once it 
clicks, it's natural. 

I'll close by touching on another aspect of Julia for general purpose 
programming. The community is great and all the Julia "seniors" are 
awesome, super-super helpful! I 

Re: [julia-users] Help please: how to expand dictionary into (local ?) variables with the same name as the keys and the corresponding values

[Adrian Salceanu]

Yes, absolutely, thanks so much! 

marți, 16 august 2016, 10:58:39 UTC+2, Mauro a scris:
>
> On Tue, 2016-08-16 at 10:29, Adrian Salceanu <adrian@gmail.com 
> > wrote: 
> > Oh, I see - I thought "global" meant "not explicitly enclosed in a 
> module". 
> > But then yes, I get your point since that's automatically included in 
> > "Main" which is just a module like any other. 
>
> Maybe have another read of 
> http://docs.julialang.org/en/release-0.4/manual/variables-and-scoping/ 
> which was overhauled half a year ago. 
>
> > marți, 16 august 2016, 10:18:57 UTC+2, Mauro a scris: 
> >> 
> >> On Tue, 2016-08-16 at 09:00, Adrian Salceanu <adrian@gmail.com 
> >> > wrote: 
> >> > Yichao, many thanks for taking so much time to help me through this, 
> >> that's 
> >> > very kind. 
> >> > 
> >> >> It has nothing to do with "compiling" a module. I'm just saying it's 
> >> not 
> >> > the right API. 
> >> > I understand your point now, it makes sense. 
> >> > 
> >> > 
> >> > would that still be in the global scope? 
> >> >> 
> >> > 
> >> >> Yes. 
> >> > Bummer! Then it appears that despite reading all the books on Julia 
> and 
> >> the 
> >> > docs a few times, I still don't have a good understanding of how 
> things 
> >> > should be approached. I expected that if I shove variables inside 
> >> modules 
> >> > and functions and sprinkle a good measure of type annotations and 
> >> "const" 
> >> > I'll be 80% good. 
> >> > 
> >> >> You can see what the expression object is with 
> >> > Yes, I was thinking about the same approach, thanks. 
> >> > 
> >> >> It's always global scope, if that's what you mean by OK. 
> >> > Yes, that's what I meant - and I was hoping it would not be. I still 
> >> don't 
> >> > get this: if in the middle of the parsing function I output 
> >> > "current_module()" and I get "Render", why is it global? 
> >> 
> >> Just checking: Are you aware that each module has its own global scope? 
> >> I.e. the top-level scope of each module is "global" (but separate from 
> >> the "global" scope of other modules). 
> >> 
> >> > Thanks 
> >> > Adrian, more confused about Julia than ever before 
> >> > 
> >> > 
> >> > marți, 16 august 2016, 01:19:14 UTC+2, Yichao Yu a scris: 
> >> >> 
> >> >> 
> >> >> 
> >> >> On Tue, Aug 16, 2016 at 4:37 AM, Adrian Salceanu <
> adrian@gmail.com 
> >> >> > wrote: 
> >> >> 
> >> >>> 
> >> >>> I was thinking about having the module itself defined in the 
> >> controller 
> >> >>> for example (or some other standalone .jl source file), completely 
> >> outside 
> >> >>> the templating engine itself, and then referencing the variables 
> >> defined 
> >> >>> within this module. Are you saying that in this case, the module 
> >> itself 
> >> >>> would not be compiled? 
> >> >>> 
> >> >> 
> >> >> 
> >> >> It has nothing to do with "compiling" a module. I'm just saying it's 
> >> not 
> >> >> the right API. A sane interface should allow the user to pass in 
> >> parameters 
> >> >> as arguments. Using a single module like this will also block any 
> kind 
> >> of 
> >> >> concurrency since calling the template with different parameters 
> will 
> >> >> either be impossible or have to modify globals. 
> >> >> 
> >> >> > In the module, and `include_string()` reference those globals. 
> >> >>> 
> >> >>> If I have 
> >> >>> 
> >> >>> module TplVars 
> >> >>>   const var1 = "foo" 
> >> >>>   const var2 = "bar" 
> >> >>>   const var3 = 42 
> >> >>> end 
> >> >>> 
> >> >>> and then from the template file I reference them 
> >> >>> 
> >> >>> ejl""" 
> >> >>> ... 
> >> >>>
> >> >>> $(TplVars.var1) 
> >> >>>
> >> >>>  
> >> >>> """ 
> >> >>> 
> >> >>> would that still be in the global scope? 
> >> >>> 
> >> >> 
> >> >> Yes. 
> >> >> 
> >> >> > How would I know that "lang" is the name of one of the vars, 
> without 
> >> >> rolling my own julia-like parser? 
> >> >> 
> >> >> (At template compilation time) Parse the expression using the julia 
> >> >> parser, iterate through the result object, check if the type of 
> >> expression 
> >> >> is supported and pull out the external references. 
> >> >> 
> >> >> You can see what the expression object is with 
> >> >> 
> >> >> ``` 
> >> >> julia> dump(:(lang == "en")) 
> >> >> Expr 
> >> >>   head: Symbol call 
> >> >>   args: Array{Any}((3,)) 
> >> >> 1: Symbol == 
> >> >> 2: Symbol lang 
> >> >> 3: String "en" 
> >> >>   typ: Any 
> >> >> ``` 
> >> >> 
> >> >> FWIW, what you want to implement is a julia-like parser anyway. 
> >> >> 
> >> >> > Right. So if I execute "eval()" and "include_string()" within a 
> >> module 
> >> >> other than Main (currently doing this into a dedicated Render 
> module) 
> >> would 
> >> >> that be ok? 
> >> >> 
> >> >> It's always global scope, if that's what you mean by OK. 
> >> >> 
> >> >> 
> >> 
>

Re: [julia-users] Help please: how to expand dictionary into (local ?) variables with the same name as the keys and the corresponding values

[Adrian Salceanu]

Oh, I see - I thought "global" meant "not explicitly enclosed in a module". 
But then yes, I get your point since that's automatically included in 
"Main" which is just a module like any other. 

marți, 16 august 2016, 10:18:57 UTC+2, Mauro a scris:
>
> On Tue, 2016-08-16 at 09:00, Adrian Salceanu <adrian@gmail.com 
> > wrote: 
> > Yichao, many thanks for taking so much time to help me through this, 
> that's 
> > very kind. 
> > 
> >> It has nothing to do with "compiling" a module. I'm just saying it's 
> not 
> > the right API. 
> > I understand your point now, it makes sense. 
> > 
> > 
> > would that still be in the global scope? 
> >> 
> > 
> >> Yes. 
> > Bummer! Then it appears that despite reading all the books on Julia and 
> the 
> > docs a few times, I still don't have a good understanding of how things 
> > should be approached. I expected that if I shove variables inside 
> modules 
> > and functions and sprinkle a good measure of type annotations and 
> "const" 
> > I'll be 80% good. 
> > 
> >> You can see what the expression object is with 
> > Yes, I was thinking about the same approach, thanks. 
> > 
> >> It's always global scope, if that's what you mean by OK. 
> > Yes, that's what I meant - and I was hoping it would not be. I still 
> don't 
> > get this: if in the middle of the parsing function I output 
> > "current_module()" and I get "Render", why is it global? 
>
> Just checking: Are you aware that each module has its own global scope? 
> I.e. the top-level scope of each module is "global" (but separate from 
> the "global" scope of other modules). 
>
> > Thanks 
> > Adrian, more confused about Julia than ever before 
> > 
> > 
> > marți, 16 august 2016, 01:19:14 UTC+2, Yichao Yu a scris: 
> >> 
> >> 
> >> 
> >> On Tue, Aug 16, 2016 at 4:37 AM, Adrian Salceanu <adrian@gmail.com 
> >> > wrote: 
> >> 
> >>> 
> >>> I was thinking about having the module itself defined in the 
> controller 
> >>> for example (or some other standalone .jl source file), completely 
> outside 
> >>> the templating engine itself, and then referencing the variables 
> defined 
> >>> within this module. Are you saying that in this case, the module 
> itself 
> >>> would not be compiled? 
> >>> 
> >> 
> >> 
> >> It has nothing to do with "compiling" a module. I'm just saying it's 
> not 
> >> the right API. A sane interface should allow the user to pass in 
> parameters 
> >> as arguments. Using a single module like this will also block any kind 
> of 
> >> concurrency since calling the template with different parameters will 
> >> either be impossible or have to modify globals. 
> >> 
> >> > In the module, and `include_string()` reference those globals. 
> >>> 
> >>> If I have 
> >>> 
> >>> module TplVars 
> >>>   const var1 = "foo" 
> >>>   const var2 = "bar" 
> >>>   const var3 = 42 
> >>> end 
> >>> 
> >>> and then from the template file I reference them 
> >>> 
> >>> ejl""" 
> >>> ... 
> >>>
> >>> $(TplVars.var1) 
> >>>
> >>>  
> >>> """ 
> >>> 
> >>> would that still be in the global scope? 
> >>> 
> >> 
> >> Yes. 
> >> 
> >> > How would I know that "lang" is the name of one of the vars, without 
> >> rolling my own julia-like parser? 
> >> 
> >> (At template compilation time) Parse the expression using the julia 
> >> parser, iterate through the result object, check if the type of 
> expression 
> >> is supported and pull out the external references. 
> >> 
> >> You can see what the expression object is with 
> >> 
> >> ``` 
> >> julia> dump(:(lang == "en")) 
> >> Expr 
> >>   head: Symbol call 
> >>   args: Array{Any}((3,)) 
> >> 1: Symbol == 
> >> 2: Symbol lang 
> >> 3: String "en" 
> >>   typ: Any 
> >> ``` 
> >> 
> >> FWIW, what you want to implement is a julia-like parser anyway. 
> >> 
> >> > Right. So if I execute "eval()" and "include_string()" within a 
> module 
> >> other than Main (currently doing this into a dedicated Render module) 
> would 
> >> that be ok? 
> >> 
> >> It's always global scope, if that's what you mean by OK. 
> >> 
> >> 
>

Re: [julia-users] Help please: how to expand dictionary into (local ?) variables with the same name as the keys and the corresponding values

[Adrian Salceanu]

Yichao, many thanks for taking so much time to help me through this, that's 
very kind.

> It has nothing to do with "compiling" a module. I'm just saying it's not 
the right API.
I understand your point now, it makes sense. 


would that still be in the global scope? 
>

> Yes.
Bummer! Then it appears that despite reading all the books on Julia and the 
docs a few times, I still don't have a good understanding of how things 
should be approached. I expected that if I shove variables inside modules 
and functions and sprinkle a good measure of type annotations and "const" 
I'll be 80% good. 

> You can see what the expression object is with
Yes, I was thinking about the same approach, thanks. 

> It's always global scope, if that's what you mean by OK.
Yes, that's what I meant - and I was hoping it would not be. I still don't 
get this: if in the middle of the parsing function I output 
"current_module()" and I get "Render", why is it global? 

Thanks
Adrian, more confused about Julia than ever before 


marți, 16 august 2016, 01:19:14 UTC+2, Yichao Yu a scris:
>
>
>
> On Tue, Aug 16, 2016 at 4:37 AM, Adrian Salceanu <adrian@gmail.com 
> > wrote:
>
>>
>> I was thinking about having the module itself defined in the controller 
>> for example (or some other standalone .jl source file), completely outside 
>> the templating engine itself, and then referencing the variables defined 
>> within this module. Are you saying that in this case, the module itself 
>> would not be compiled? 
>>
>
>
> It has nothing to do with "compiling" a module. I'm just saying it's not 
> the right API. A sane interface should allow the user to pass in parameters 
> as arguments. Using a single module like this will also block any kind of 
> concurrency since calling the template with different parameters will 
> either be impossible or have to modify globals.
>
> > In the module, and `include_string()` reference those globals.
>>
>> If I have 
>>
>> module TplVars
>>   const var1 = "foo"
>>   const var2 = "bar"
>>   const var3 = 42
>> end
>>
>> and then from the template file I reference them
>>
>> ejl"""
>> ... 
>>   
>> $(TplVars.var1)
>>   
>> 
>> """
>>
>> would that still be in the global scope? 
>>
>
> Yes.
>
> > How would I know that "lang" is the name of one of the vars, without 
> rolling my own julia-like parser?
>
> (At template compilation time) Parse the expression using the julia 
> parser, iterate through the result object, check if the type of expression 
> is supported and pull out the external references.
>
> You can see what the expression object is with
>
> ```
> julia> dump(:(lang == "en"))
> Expr
>   head: Symbol call
>   args: Array{Any}((3,))
> 1: Symbol ==
> 2: Symbol lang
> 3: String "en"
>   typ: Any
> ```
>
> FWIW, what you want to implement is a julia-like parser anyway.
>
> > Right. So if I execute "eval()" and "include_string()" within a module 
> other than Main (currently doing this into a dedicated Render module) would 
> that be ok? 
>
> It's always global scope, if that's what you mean by OK.
>
>

Re: [julia-users] Help please: how to expand dictionary into (local ?) variables with the same name as the keys and the corresponding values

[Adrian Salceanu]

Ah, of course! I don't know why I missed that, I was stuck looking for 
something that would be line aware, in the line of quote blocks. 

luni, 15 august 2016, 23:02:58 UTC+2, Stefan Karpinski a scris:
>
> On Mon, Aug 15, 2016 at 4:53 PM, Adrian Salceanu <adrian@gmail.com 
> > wrote:
>
>>
>> > parse() supports this by allowing you to parse expression by expression 
>> within the string
>>
>> I searched the docs (on the website and using Dash) but I could not find 
>> that - is it undocumented or something? 
>>
>
> It's the two-argument form:
>
>   parse(str, start; greedy=true, raise=true)
>
>   Parse the expression string and return an expression (which could later 
> be passed to eval for execution).
>   start is the index of the first character to start parsing. If greedy is 
> true (default), parse will try
>   to consume as much input as it can; otherwise, it will stop as soon as 
> it has parsed a valid expression.
>   Incomplete but otherwise syntactically valid expressions will return 
> Expr(:incomplete, "(error
>   message)"). If raise is true (default), syntax errors other than 
> incomplete expressions will raise an
>   error. If raise is false, parse will return an expression that will 
> raise an error upon evaluation.
>
> It returns the parsed code and the end position. You may want to use 
> greedy=false.
>

Re: [julia-users] Help please: how to expand dictionary into (local ?) variables with the same name as the keys and the corresponding values

[Adrian Salceanu]

> Not sure what do you mean by `mixin`. all of `include_string`, `eval` and 
`include` works in the scope of current module, none of them will see 
anything in the scope of the function that calls them.

Right. So if I execute "eval()" and "include_string()" within a module 
other than Main (currently doing this into a dedicated Render module) would 
that be ok? 

luni, 15 august 2016, 16:25:03 UTC+2, Yichao Yu a scris:
>
>
>
> On Sun, Aug 14, 2016 at 11:33 PM, Adrian Salceanu <adrian@gmail.com 
> > wrote:
>
>> Huhm... so re
>>
>> > defining globals
>>
>> According to the API docs: 
>>
>> *include_string**(code::AbstractString**[**, filename**]**)*
>>
>> Like include, except reads code from the given string rather than from a 
>> file. Since there is no file path involved, no path processing or fetching 
>> from node 1 is done.
>>
>>
>> But then I think you're right, the code is included / eval'd in Main - so 
>> it's not really like include(), which provides for mixin behavior? :-O 
>>
>>
> Not sure what do you mean by `mixin`. all of `include_string`, `eval` and 
> `include` works in the scope of current module, none of them will see 
> anything in the scope of the function that calls them.
>  
>
>> duminică, 14 august 2016, 17:13:28 UTC+2, Adrian Salceanu a scris:
>>>
>>> Thanks
>>>
>>> Maybe I wasn't clear enough - otherwise, can you please elaborate, I'm 
>>> definitely still poking around, any clarifications would be highly 
>>> appreciated. 
>>>
>>> > creating a new module
>>> -> the module is available at compile time (the users of the templating 
>>> system will place the vars in there, by convention). 
>>>
>>> > parse julia code
>>> -> it's not really parsing julia code, it has no meaning at the point. 
>>> It's simply basic string processing and it's fast - tried with a 10K lines 
>>> HTML file, no sweat. 
>>>
>>> > defining globals 
>>> -> why are they globals? include_string() is used inside a function, 
>>> inside a module within the app. 
>>>
>>> > eval in a module
>>> -> true, but then what can we do? That's the way of doing 
>>> metaprogramming in Julia, and it's widely used, isn't it? 
>>> I guess that would be the price for not having to do 
>>> print("...") like our ancestors used to in PHP or ASP, when not 
>>> being chased by tigers (or something around that age). 
>>>
>>>
>>> duminică, 14 august 2016, 15:01:47 UTC+2, Yichao Yu a scris:
>>>>
>>>>
>>>>
>>>> On Sun, Aug 14, 2016 at 6:13 PM, Adrian Salceanu <adrian@gmail.com> 
>>>> wrote:
>>>>
>>>>> Variables contained in a module and then parsed Julia code included 
>>>>> within a function using include_string(). 
>>>>>
>>>>> Any obvious performance issues with this approach? 
>>>>>
>>>>
>>>> Everything about it?
>>>> Literally every steps are hitting the slow path that is only meant to 
>>>> execute at compile time and not runtime. Including
>>>>
>>>> Creating a new module, parse julia code, eval in a module, defining 
>>>> globals.
>>>>  
>>>>
>>>>>
>>>>>
>>>>> duminică, 14 august 2016, 12:11:06 UTC+2, Adrian Salceanu a scris:
>>>>>>
>>>>>> OK, actually, that's not nearly half as bad. Variables contained in a 
>>>>>> module 
>>>>>>
>>>>>> include("src/Ejl_str.jl")
>>>>>> using Ejl
>>>>>>
>>>>>>
>>>>>> module _
>>>>>>   couñtry = "España"
>>>>>>   lang = "en"
>>>>>> end
>>>>>>
>>>>>>
>>>>>> function render_template()
>>>>>>   tpl_data = ejl"""
>>>>>> <% if _.lang == "en" :>
>>>>>> Hello from me, ...
>>>>>> <: else :>
>>>>>> Hola
>>>>>> <: end %>
>>>>>>
>>>>>>
>>>>>> %= _.couñtry == "España" ? "Olé" : "Aye"
>>>>>> moo
>>>>>> """
>>>>>>
>>>>>>
>>

Re: [julia-users] Help please: how to expand dictionary into (local ?) variables with the same name as the keys and the corresponding values

[Adrian Salceanu]

\npush!(output, \"   
>>  \")\nL9OHE6m05ZtELQIOMV8PPH0L = page_title\npush!(output, 
>> \"\$(L9OHE6m05ZtELQIOMV8PPH0L)\")\npush!(output, \"   
>>  \")\npush!(output, \"  \")\npush!(output, \" 
>>  \")\npush!(output, \"\")\nwHbq5V7InZ2OJKpatWu7MtUU = 
>> greeting\npush!(output, 
>> \"\$(wHbq5V7InZ2OJKpatWu7MtUU)\")\npush!(output, \"   
>>  \")\npush!(output, \"\")\nif 
>> is_logged_in\npush!(output, \"Edit 
>> account\")\nelse\npush!(output, \"   
>>  Login\")\nend\npush!(output, \"\")\npush!(output, \" 
>>  \")\npush!(output, \"\")\npush!(output, \"\")"
>>
>> Then this code is eval'd - at this time, the variables should already be 
>> in scope otherwise Julia won't find them. 
>>
>> Yes, the variables are only used to generate HTML code. So ideally they 
>> should only be visible in the minimum scope necessary to eval this code. 
>>
>> > Can you elaborate on why you want to access dictionary elements as 
>> local variables?
>>
>> I was hoping this could be an approach to eval the code with its vars in 
>> a non-global scope. Something in the lines of: 
>>
>> function render_tpl(output::AbstractString, vars::Dict{Symbol,Any})  # 
>> output would be the above generated code and vars the list of vars used in 
>> the template
>>   # code here to expand the vars dict into function local variables
>>   # code here to eval the output (which would be the "output = 
>> Vector{..." code above) -- this would automatically have access to the vars
>>   # return the resulted output Vector which now contains the rendered 
>> template 
>> end
>>
>> Thanks,
>> Adrian
>>
>> duminică, 14 august 2016, 17:59:40 UTC+2, Erik Schnetter a scris:
>>>
>>> Adrian
>>>
>>> Can you give more details for how the variables would be used? If the 
>>> variables are declared in a function, then there must be code that uses 
>>> them; how would this code know which variables exist? Is there e.g. a 
>>> globally known list of variables that will be provided? Or will the 
>>> variables e.g. only be used in strings to generate html code?
>>>
>>> You can generate the syntax tree for function that contains the 
>>> definitions from the dictionary, and then use `eval` to create the 
>>> function. (Alternatively, you can use a macro or a generated function.) 
>>> This is indeed one of the strengths of Julia, and it requires neither 
>>> string manipulation, nor parsing, nor creating files nor include.
>>>
>>> Here is an example:
>>>
>>> fun_expr(var, val) = quote
>>> function f(x)
>>> $var = $val
>>> x + y
>>> end
>>> end
>>>
>>> eval(fun_expr(:y, :42))
>>>
>>> `fun_expr` creates a syntax tree (an `Expr`) that defines a function. 
>>> The function is quoted. The function arguments `var` and `val` are inserted 
>>> into that function, forming an assignment. Thus `var` better be an 
>>> identifier (or something else that can be on the left of an assignment 
>>> operator), and `val` can be an arbitrary value. Given how the function 
>>> looks, `var` essentially has to be `y` since it's used in the next line; of 
>>> course, this was just my arbitrary choice.
>>>
>>> The call to `eval` then passes the respective arguments, choosing the 
>>> symbol `y` for the variable name, and the value `42` as value, and defines 
>>> the function `f`. If you then call `f(2)`, the result is 44.
>>>
>>> Of course, you can define this function `f` only once. Julia does not 
>>> allow changing functions. If you want to create many different functions, 
>>> you would use anonymous functions instead.
>>>
>>> Having said this -- it's not clear that this is indeed the right way to 
>>> address your problem; there might be a better solution. Can you elaborate 
>>> on why you want to access dictionary elements as local variables?
>>>
>>> -erik
>>>
>>>
>>>
>>> On Sun, Aug 14, 2016 at 11:13 AM, Adrian Salceanu <adrian@gmail.com> 
>>> wrote:
>>>
>>>> Thanks
>>>>
>>>> Maybe I wasn't clear enough - otherwise, can you please elaborate

Re: [julia-users] Help please: how to expand dictionary into (local ?) variables with the same name as the keys and the corresponding values

[Adrian Salceanu]

Thank you very much Yichao

I'm afraid then that I don't fully understand the consequences of all the 
steps in this workflow. Let me see if I get things right (sorry if some of 
my questions are dumb or seem obvious and thanks for your patience). 

> Unless the user only do that once at compile time (i.e. the template is 
only used once with no support of passing any template variables as 
function arguments) than it is runtime and not compile time.

I was thinking about having the module itself defined in the controller for 
example (or some other standalone .jl source file), completely outside the 
templating engine itself, and then referencing the variables defined within 
this module. Are you saying that in this case, the module itself would not 
be compiled? 

> It is, in `include_string()`
Ah sure. We're on the same page here, with the only exception that by 
"parse" I was referring to the parsing phase of the template (converting 
the special template markup) and considered "include_string()" more as a 
part of rendering the template (eval'ing the julia code together with the 
vars to generate the HTML code). 

> In the module, and `include_string()` reference those globals.

If I have 

module TplVars
  const var1 = "foo"
  const var2 = "bar"
  const var3 = 42
end

and then from the template file I reference them

ejl"""
... 
  
$(TplVars.var1)
  

"""

would that still be in the global scope? 


luni, 15 august 2016, 16:23:37 UTC+2, Yichao Yu a scris:
>
>
>
> On Sun, Aug 14, 2016 at 11:13 PM, Adrian Salceanu <adrian@gmail.com 
> > wrote:
>
>> Thanks
>>
>> Maybe I wasn't clear enough - otherwise, can you please elaborate, I'm 
>> definitely still poking around, any clarifications would be highly 
>> appreciated. 
>>
>> > creating a new module
>> -> the module is available at compile time (the users of the templating 
>> system will place the vars in there, by convention). 
>>
>
> Unless the user only do that once at compile time (i.e. the template is 
> only used once with no support of passing any template variables as 
> function arguments) than it is runtime and not compile time.
>  
>
>>
>> > parse julia code
>> -> it's not really parsing julia code, it has no meaning at the point. 
>> It's simply basic string processing and it's fast - tried with a 10K lines 
>> HTML file, no sweat. 
>>
>
> It is, in `include_string()`
>  
>
>>
>> > defining globals 
>> -> why are they globals? include_string() is used inside a function, 
>> inside a module within the app. 
>>
>
> In the module, and `include_string()` reference those globals.
>  
>
>>
>> > eval in a module
>> -> true, but then what can we do? That's the way of doing metaprogramming 
>> in Julia, and it's widely used, isn't it? 
>>
>
> Which should only be done at compile time, not runtime.
>  
>
>> I guess that would be the price for not having to do 
>> print("...") like our ancestors used to in PHP or ASP, when not 
>> being chased by tigers (or something around that age).
>>
>>
>> duminică, 14 august 2016, 15:01:47 UTC+2, Yichao Yu a scris:
>>
>>>
>>>
>>> On Sun, Aug 14, 2016 at 6:13 PM, Adrian Salceanu <adrian@gmail.com> 
>>> wrote:
>>>
>>>> Variables contained in a module and then parsed Julia code included 
>>>> within a function using include_string(). 
>>>>
>>>> Any obvious performance issues with this approach? 
>>>>
>>>
>>> Everything about it?
>>> Literally every steps are hitting the slow path that is only meant to 
>>> execute at compile time and not runtime. Including
>>>
>>> Creating a new module, parse julia code, eval in a module, defining 
>>> globals.
>>>  
>>>
>>>>
>>>>
>>>> duminică, 14 august 2016, 12:11:06 UTC+2, Adrian Salceanu a scris:
>>>>>
>>>>> OK, actually, that's not nearly half as bad. Variables contained in a 
>>>>> module 
>>>>>
>>>>> include("src/Ejl_str.jl")
>>>>> using Ejl
>>>>>
>>>>>
>>>>> module _
>>>>>   couñtry = "España"
>>>>>   lang = "en"
>>>>> end
>>>>>
>>>>>
>>>>> function render_template()
>>>>>   tpl_data = ejl"""
>>>>> <% if _.lang == "en" :>
>>>&g

Re: [julia-users] Help please: how to expand dictionary into (local ?) variables with the same name as the keys and the corresponding values

[Adrian Salceanu]

Here is the code for the examples: 

https://github.com/essenciary/ejl/blob/master/2.jl

luni, 15 august 2016, 10:20:18 UTC+2, Adrian Salceanu a scris:
>
> Erik, thank you very much.
>
> In a few lines, here is the use case (for a standard MVC web app): 
>
> 1. the user defines some template code which is stored in a view file. 
> Think HTML with embedded Julia code for interpolating variables, if/else, 
> loops, etc. 
> A very basic example would look like this: 
>
> 
>   
> 
>   %= page_title
> 
>   
>   
> 
>   %= greeting
> 
> 
>   <% if is_logged_in :>
> Edit account
>   <: else :>
> Login
>   <: end %>
> 
>   
> 
>
> 2. there are some very simple parsing rules, such as: 
> a. "%=" means the line should be interpreted as Julia and outputted, 
> b. "<% ... %>" defines a multiline Julia block 
> c. everything else should be considered raw output 
>
> 3. the variables used in the template have to be defined / set beforehand 
> by the user, usually in a controller file - and somehow be made available 
> to the template rendering function
>
> ---
>
> This means that: 
>
> a. I do not know the variables beforehand, they are user inputed as part 
> of the template. 
>
> b. also, it's not an issue of "This is indeed one of the strengths of 
> Julia, and it requires neither string manipulation, nor parsing, nor 
> creating files nor include.". I can not avoid creating, loading and parsing 
> files, because that's what I want to do. I want to allow the users to 
> create view files that are basically HTML files with embedded Julia code. 
>
> b. I'm looking for a way to load and interpret multiline template code 
> stored in a file. This seems to be tricky by itself as parse(...) works 
> line by line (not good for me, I need to interpret the whole block at once, 
> for example to handle if/else blocks) and I could not find a functional 
> alternative for quote ... end or a way to pass a string into a quote ... 
> end block. Like I said, the only thing close to achieving this would be 
> include_string()
>
> c. I'd like to do this in a performant manner by avoiding the dreaded 
> global scope (but not really by avoiding eval, which I think it's a 
> necessary evil in this case). 
>
> ---
>
> Strictly addressing your questions: 
> > If the variables are declared in a function, then there must be code 
> that uses them; how would this code know which variables exist? Is there 
> e.g. a globally known list of variables that will be provided? Or will the 
> variables e.g. only be used in strings to generate html code?
>
> I go over the template file line by line and generate Julia code (as a 
> string). This code is either logic (if/else, loops, etc) or raw output. For 
> instance, the parsing of the above template would generate the following 
> Julia code: 
>
> "output = Vector{AbstractString}()\npush!(output, 
> \"\")\npush!(output, \"  \")\npush!(output, \"   
>  \")\nL9OHE6m05ZtELQIOMV8PPH0L = page_title\npush!(output, 
> \"\$(L9OHE6m05ZtELQIOMV8PPH0L)\")\npush!(output, \"   
>  \")\npush!(output, \"  \")\npush!(output, \" 
>  \")\npush!(output, \"\")\nwHbq5V7InZ2OJKpatWu7MtUU = 
> greeting\npush!(output, 
> \"\$(wHbq5V7InZ2OJKpatWu7MtUU)\")\npush!(output, \"   
>  \")\npush!(output, \"\")\nif 
> is_logged_in\npush!(output, \"Edit 
> account\")\nelse\npush!(output, \"   
>  Login\")\nend\npush!(output, \"\")\npush!(output, \" 
>  \")\npush!(output, \"\")\npush!(output, \"\")"
>
> Then this code is eval'd - at this time, the variables should already be 
> in scope otherwise Julia won't find them. 
>
> Yes, the variables are only used to generate HTML code. So ideally they 
> should only be visible in the minimum scope necessary to eval this code. 
>
> > Can you elaborate on why you want to access dictionary elements as local 
> variables?
>
> I was hoping this could be an approach to eval the code with its vars in a 
> non-global scope. Something in the lines of: 
>
> function render_tpl(output::AbstractString, vars::Dict{Symbol,Any})  # 
> output would be the above generated code and vars the list of vars used in 
> the template
>   # code here to expand the vars dict into function local variables
>   # code here to eval the output (which would be the "ou

Re: [julia-users] Help please: how to expand dictionary into (local ?) variables with the same name as the keys and the corresponding values

[Adrian Salceanu]

Chris, thans very much for the suggestion. I checked it, but there's the 
issue of not knowing the number and the names of the variables beforehand. 

Per the docs: 

d = Dict{Symbol,Any}(:a=>5.0,:b=>2,:c=>"Hi!")
@materialize a, b, c = d
a == 5.0 #true
b == 2 #true
c == "Hi!" #true


This line here 
@materialize a, b, c = d

is the issue - I do not know that I have a, b, and c. I only have access to 
d; a, b and c are part of the template and they are interpolated in the 
template's code. So this line would have to be dynamically generated again 
by using keys(d) and maybe generating this as a string "@materialize a, b, 
c = d" and eval'ing it. Which seems to only move my original problem 
somewhere else? 

Thanks,
Adrian



duminică, 14 august 2016, 18:17:51 UTC+2, Chris Rackauckas a scris:
>
> Any issues with @materialize? It seems like it does exactly what you're 
> asking for...
>
> On Sunday, August 14, 2016 at 3:13:37 AM UTC-7, Adrian Salceanu wrote:
>>
>> Variables contained in a module and then parsed Julia code included 
>> within a function using include_string(). 
>>
>> Any obvious performance issues with this approach? 
>>
>>
>> duminică, 14 august 2016, 12:11:06 UTC+2, Adrian Salceanu a scris:
>>>
>>> OK, actually, that's not nearly half as bad. Variables contained in a 
>>> module 
>>>
>>> include("src/Ejl_str.jl")
>>> using Ejl
>>>
>>>
>>> module _
>>>   couñtry = "España"
>>>   lang = "en"
>>> end
>>>
>>>
>>> function render_template()
>>>   tpl_data = ejl"""
>>> <% if _.lang == "en" :>
>>> Hello from me, ...
>>> <: else :>
>>> Hola
>>> <: end %>
>>>
>>>
>>> %= _.couñtry == "España" ? "Olé" : "Aye"
>>> moo
>>> """
>>>
>>>
>>>   include_string(join(tpl_data, "\n"))
>>>   join(output, "\n")
>>> end
>>>
>>>
>>> render_template() |> println
>>>
>>> Hello from me, ...
>>>
>>>
>>> Olé
>>> moo
>>>
>>>
>>> duminică, 14 august 2016, 11:20:37 UTC+2, Adrian Salceanu a scris:
>>>>
>>>> Thanks
>>>>
>>>> Yes, I've thought about a few ways to mitigate some of these issues: 
>>>>
>>>> 1. in the app I can setup a module (like Render) and evaluate into this 
>>>> module exclusively. 
>>>> Hence, another approach might be to have some helper methods that setup 
>>>> the variables in the module and then eval the template itself inside the 
>>>> module too (must try though). So something in the lines of: 
>>>> set(:foo, "foo")
>>>> set(:bar, [1, 2, 3])
>>>> parse_tpl(ejl"""$(foo) and $(bar)""")
>>>> # all the above gets parsed in Render
>>>>
>>>> 2. break the parsing in 2 steps: 
>>>> a. reading the template string and parse it to generated Julia code (as 
>>>> strings) (an array of Julia code lines) - cache it 
>>>> b. (load strings from cache and) eval the code together with the vars 
>>>>
>>>> ===
>>>>
>>>> Another approach (which is how it's done in one of the Ruby templating 
>>>> engine) is to generate a full function definition, whose body parses the 
>>>> template and takes the variables as params. And then eval and execute the 
>>>> function with its params. However, I'm still struggling with the 
>>>> metaprogramming API as for instance parse() chokes on multiple lines, and 
>>>> I 
>>>> couldn't find a functional equivalent of a quote ... end blocks. But I'm 
>>>> hoping include_string() will do the trick (must test though). 
>>>>
>>>>
>>>> sâmbătă, 13 august 2016, 15:20:01 UTC+2, Yichao Yu a scris:
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Aug 13, 2016 at 8:06 PM, Adrian Salceanu <adrian@gmail.com
>>>>> > wrote:
>>>>>
>>>>>> That's pretty difficult as my goal is to use embedded Julia as the 
>>>>>> templating language. Similar to Ruby's ERB, ex: 
>>>>>> http://www.stuartellis.eu/articles/erb/
>>>>>>
>>>>>> So say in the template I have something like 
>>>>>

Re: [julia-users] Help please: how to expand dictionary into (local ?) variables with the same name as the keys and the corresponding values

[Adrian Salceanu]

ree for function that contains the 
> definitions from the dictionary, and then use `eval` to create the 
> function. (Alternatively, you can use a macro or a generated function.) 
> This is indeed one of the strengths of Julia, and it requires neither 
> string manipulation, nor parsing, nor creating files nor include.
>
> Here is an example:
>
> fun_expr(var, val) = quote
> function f(x)
> $var = $val
> x + y
> end
> end
>
> eval(fun_expr(:y, :42))
>
> `fun_expr` creates a syntax tree (an `Expr`) that defines a function. The 
> function is quoted. The function arguments `var` and `val` are inserted 
> into that function, forming an assignment. Thus `var` better be an 
> identifier (or something else that can be on the left of an assignment 
> operator), and `val` can be an arbitrary value. Given how the function 
> looks, `var` essentially has to be `y` since it's used in the next line; of 
> course, this was just my arbitrary choice.
>
> The call to `eval` then passes the respective arguments, choosing the 
> symbol `y` for the variable name, and the value `42` as value, and defines 
> the function `f`. If you then call `f(2)`, the result is 44.
>
> Of course, you can define this function `f` only once. Julia does not 
> allow changing functions. If you want to create many different functions, 
> you would use anonymous functions instead.
>
> Having said this -- it's not clear that this is indeed the right way to 
> address your problem; there might be a better solution. Can you elaborate 
> on why you want to access dictionary elements as local variables?
>
> -erik
>
>
>
> On Sun, Aug 14, 2016 at 11:13 AM, Adrian Salceanu <adrian@gmail.com 
> > wrote:
>
>> Thanks
>>
>> Maybe I wasn't clear enough - otherwise, can you please elaborate, I'm 
>> definitely still poking around, any clarifications would be highly 
>> appreciated. 
>>
>> > creating a new module
>> -> the module is available at compile time (the users of the templating 
>> system will place the vars in there, by convention). 
>>
>> > parse julia code
>> -> it's not really parsing julia code, it has no meaning at the point. 
>> It's simply basic string processing and it's fast - tried with a 10K lines 
>> HTML file, no sweat. 
>>
>> > defining globals 
>> -> why are they globals? include_string() is used inside a function, 
>> inside a module within the app. 
>>
>> > eval in a module
>> -> true, but then what can we do? That's the way of doing metaprogramming 
>> in Julia, and it's widely used, isn't it? 
>> I guess that would be the price for not having to do 
>> print("...") like our ancestors used to in PHP or ASP, when not 
>> being chased by tigers (or something around that age). 
>>
>>
>> duminică, 14 august 2016, 15:01:47 UTC+2, Yichao Yu a scris:
>>>
>>>
>>>
>>> On Sun, Aug 14, 2016 at 6:13 PM, Adrian Salceanu <adrian@gmail.com> 
>>> wrote:
>>>
>>>> Variables contained in a module and then parsed Julia code included 
>>>> within a function using include_string(). 
>>>>
>>>> Any obvious performance issues with this approach? 
>>>>
>>>
>>> Everything about it?
>>> Literally every steps are hitting the slow path that is only meant to 
>>> execute at compile time and not runtime. Including
>>>
>>> Creating a new module, parse julia code, eval in a module, defining 
>>> globals.
>>>  
>>>
>>>>
>>>>
>>>> duminică, 14 august 2016, 12:11:06 UTC+2, Adrian Salceanu a scris:
>>>>>
>>>>> OK, actually, that's not nearly half as bad. Variables contained in a 
>>>>> module 
>>>>>
>>>>> include("src/Ejl_str.jl")
>>>>> using Ejl
>>>>>
>>>>>
>>>>> module _
>>>>>   couñtry = "España"
>>>>>   lang = "en"
>>>>> end
>>>>>
>>>>>
>>>>> function render_template()
>>>>>   tpl_data = ejl"""
>>>>> <% if _.lang == "en" :>
>>>>> Hello from me, ...
>>>>> <: else :>
>>>>> Hola
>>>>> <: end %>
>>>>>
>>>>>
>>>>> %= _.couñtry == "España" ? "Olé" : "Aye"
>>>>> moo
>>>>> """
>&

Re: [julia-users] Help please: how to expand dictionary into (local ?) variables with the same name as the keys and the corresponding values

[Adrian Salceanu]

Huhm... so re

> defining globals

According to the API docs: 

*include_string**(code::AbstractString**[**, filename**]**)*

Like include, except reads code from the given string rather than from a 
file. Since there is no file path involved, no path processing or fetching 
from node 1 is done.


But then I think you're right, the code is included / eval'd in Main - so 
it's not really like include(), which provides for mixin behavior? :-O 

duminică, 14 august 2016, 17:13:28 UTC+2, Adrian Salceanu a scris:
>
> Thanks
>
> Maybe I wasn't clear enough - otherwise, can you please elaborate, I'm 
> definitely still poking around, any clarifications would be highly 
> appreciated. 
>
> > creating a new module
> -> the module is available at compile time (the users of the templating 
> system will place the vars in there, by convention). 
>
> > parse julia code
> -> it's not really parsing julia code, it has no meaning at the point. 
> It's simply basic string processing and it's fast - tried with a 10K lines 
> HTML file, no sweat. 
>
> > defining globals 
> -> why are they globals? include_string() is used inside a function, 
> inside a module within the app. 
>
> > eval in a module
> -> true, but then what can we do? That's the way of doing metaprogramming 
> in Julia, and it's widely used, isn't it? 
> I guess that would be the price for not having to do 
> print("...") like our ancestors used to in PHP or ASP, when not 
> being chased by tigers (or something around that age). 
>
>
> duminică, 14 august 2016, 15:01:47 UTC+2, Yichao Yu a scris:
>>
>>
>>
>> On Sun, Aug 14, 2016 at 6:13 PM, Adrian Salceanu <adrian@gmail.com> 
>> wrote:
>>
>>> Variables contained in a module and then parsed Julia code included 
>>> within a function using include_string(). 
>>>
>>> Any obvious performance issues with this approach? 
>>>
>>
>> Everything about it?
>> Literally every steps are hitting the slow path that is only meant to 
>> execute at compile time and not runtime. Including
>>
>> Creating a new module, parse julia code, eval in a module, defining 
>> globals.
>>  
>>
>>>
>>>
>>> duminică, 14 august 2016, 12:11:06 UTC+2, Adrian Salceanu a scris:
>>>>
>>>> OK, actually, that's not nearly half as bad. Variables contained in a 
>>>> module 
>>>>
>>>> include("src/Ejl_str.jl")
>>>> using Ejl
>>>>
>>>>
>>>> module _
>>>>   couñtry = "España"
>>>>   lang = "en"
>>>> end
>>>>
>>>>
>>>> function render_template()
>>>>   tpl_data = ejl"""
>>>> <% if _.lang == "en" :>
>>>> Hello from me, ...
>>>> <: else :>
>>>> Hola
>>>> <: end %>
>>>>
>>>>
>>>> %= _.couñtry == "España" ? "Olé" : "Aye"
>>>> moo
>>>> """
>>>>
>>>>
>>>>   include_string(join(tpl_data, "\n"))
>>>>   join(output, "\n")
>>>> end
>>>>
>>>>
>>>> render_template() |> println
>>>>
>>>> Hello from me, ...
>>>>
>>>>
>>>> Olé
>>>> moo
>>>>
>>>>
>>>> duminică, 14 august 2016, 11:20:37 UTC+2, Adrian Salceanu a scris:
>>>>>
>>>>> Thanks
>>>>>
>>>>> Yes, I've thought about a few ways to mitigate some of these issues: 
>>>>>
>>>>> 1. in the app I can setup a module (like Render) and evaluate into 
>>>>> this module exclusively. 
>>>>> Hence, another approach might be to have some helper methods that 
>>>>> setup the variables in the module and then eval the template itself 
>>>>> inside 
>>>>> the module too (must try though). So something in the lines of: 
>>>>> set(:foo, "foo")
>>>>> set(:bar, [1, 2, 3])
>>>>> parse_tpl(ejl"""$(foo) and $(bar)""")
>>>>> # all the above gets parsed in Render
>>>>>
>>>>> 2. break the parsing in 2 steps: 
>>>>> a. reading the template string and parse it to generated Julia code 
>>>>> (as strings) (an array of Julia code lines) - cache it 
>>>>> b. (load stri

Re: [julia-users] Help please: how to expand dictionary into (local ?) variables with the same name as the keys and the corresponding values

[Adrian Salceanu]

Thanks

Maybe I wasn't clear enough - otherwise, can you please elaborate, I'm 
definitely still poking around, any clarifications would be highly 
appreciated. 

> creating a new module
-> the module is available at compile time (the users of the templating 
system will place the vars in there, by convention). 

> parse julia code
-> it's not really parsing julia code, it has no meaning at the point. It's 
simply basic string processing and it's fast - tried with a 10K lines HTML 
file, no sweat. 

> defining globals 
-> why are they globals? include_string() is used inside a function, inside 
a module within the app. 

> eval in a module
-> true, but then what can we do? That's the way of doing metaprogramming 
in Julia, and it's widely used, isn't it? 
I guess that would be the price for not having to do 
print("...") like our ancestors used to in PHP or ASP, when not 
being chased by tigers (or something around that age). 


duminică, 14 august 2016, 15:01:47 UTC+2, Yichao Yu a scris:
>
>
>
> On Sun, Aug 14, 2016 at 6:13 PM, Adrian Salceanu <adrian@gmail.com 
> > wrote:
>
>> Variables contained in a module and then parsed Julia code included 
>> within a function using include_string(). 
>>
>> Any obvious performance issues with this approach? 
>>
>
> Everything about it?
> Literally every steps are hitting the slow path that is only meant to 
> execute at compile time and not runtime. Including
>
> Creating a new module, parse julia code, eval in a module, defining 
> globals.
>  
>
>>
>>
>> duminică, 14 august 2016, 12:11:06 UTC+2, Adrian Salceanu a scris:
>>>
>>> OK, actually, that's not nearly half as bad. Variables contained in a 
>>> module 
>>>
>>> include("src/Ejl_str.jl")
>>> using Ejl
>>>
>>>
>>> module _
>>>   couñtry = "España"
>>>   lang = "en"
>>> end
>>>
>>>
>>> function render_template()
>>>   tpl_data = ejl"""
>>> <% if _.lang == "en" :>
>>> Hello from me, ...
>>> <: else :>
>>> Hola
>>> <: end %>
>>>
>>>
>>> %= _.couñtry == "España" ? "Olé" : "Aye"
>>> moo
>>> """
>>>
>>>
>>>   include_string(join(tpl_data, "\n"))
>>>   join(output, "\n")
>>> end
>>>
>>>
>>> render_template() |> println
>>>
>>> Hello from me, ...
>>>
>>>
>>> Olé
>>> moo
>>>
>>>
>>> duminică, 14 august 2016, 11:20:37 UTC+2, Adrian Salceanu a scris:
>>>>
>>>> Thanks
>>>>
>>>> Yes, I've thought about a few ways to mitigate some of these issues: 
>>>>
>>>> 1. in the app I can setup a module (like Render) and evaluate into this 
>>>> module exclusively. 
>>>> Hence, another approach might be to have some helper methods that setup 
>>>> the variables in the module and then eval the template itself inside the 
>>>> module too (must try though). So something in the lines of: 
>>>> set(:foo, "foo")
>>>> set(:bar, [1, 2, 3])
>>>> parse_tpl(ejl"""$(foo) and $(bar)""")
>>>> # all the above gets parsed in Render
>>>>
>>>> 2. break the parsing in 2 steps: 
>>>> a. reading the template string and parse it to generated Julia code (as 
>>>> strings) (an array of Julia code lines) - cache it 
>>>> b. (load strings from cache and) eval the code together with the vars 
>>>>
>>>> ===
>>>>
>>>> Another approach (which is how it's done in one of the Ruby templating 
>>>> engine) is to generate a full function definition, whose body parses the 
>>>> template and takes the variables as params. And then eval and execute the 
>>>> function with its params. However, I'm still struggling with the 
>>>> metaprogramming API as for instance parse() chokes on multiple lines, and 
>>>> I 
>>>> couldn't find a functional equivalent of a quote ... end blocks. But I'm 
>>>> hoping include_string() will do the trick (must test though). 
>>>>
>>>>
>>>> sâmbătă, 13 august 2016, 15:20:01 UTC+2, Yichao Yu a scris:
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Aug 13, 2016 at 8:06 PM, Adrian Salceanu <adrian@gmail.

Re: [julia-users] Help please: how to expand dictionary into (local ?) variables with the same name as the keys and the corresponding values

[Adrian Salceanu]

Variables contained in a module and then parsed Julia code included within 
a function using include_string(). 

Any obvious performance issues with this approach? 


duminică, 14 august 2016, 12:11:06 UTC+2, Adrian Salceanu a scris:
>
> OK, actually, that's not nearly half as bad. Variables contained in a 
> module 
>
> include("src/Ejl_str.jl")
> using Ejl
>
>
> module _
>   couñtry = "España"
>   lang = "en"
> end
>
>
> function render_template()
>   tpl_data = ejl"""
> <% if _.lang == "en" :>
> Hello from me, ...
> <: else :>
> Hola
> <: end %>
>
>
> %= _.couñtry == "España" ? "Olé" : "Aye"
> moo
> """
>
>
>   include_string(join(tpl_data, "\n"))
>   join(output, "\n")
> end
>
>
> render_template() |> println
>
> Hello from me, ...
>
>
> Olé
> moo
>
>
> duminică, 14 august 2016, 11:20:37 UTC+2, Adrian Salceanu a scris:
>>
>> Thanks
>>
>> Yes, I've thought about a few ways to mitigate some of these issues: 
>>
>> 1. in the app I can setup a module (like Render) and evaluate into this 
>> module exclusively. 
>> Hence, another approach might be to have some helper methods that setup 
>> the variables in the module and then eval the template itself inside the 
>> module too (must try though). So something in the lines of: 
>> set(:foo, "foo")
>> set(:bar, [1, 2, 3])
>> parse_tpl(ejl"""$(foo) and $(bar)""")
>> # all the above gets parsed in Render
>>
>> 2. break the parsing in 2 steps: 
>> a. reading the template string and parse it to generated Julia code (as 
>> strings) (an array of Julia code lines) - cache it 
>> b. (load strings from cache and) eval the code together with the vars 
>>
>> ===
>>
>> Another approach (which is how it's done in one of the Ruby templating 
>> engine) is to generate a full function definition, whose body parses the 
>> template and takes the variables as params. And then eval and execute the 
>> function with its params. However, I'm still struggling with the 
>> metaprogramming API as for instance parse() chokes on multiple lines, and I 
>> couldn't find a functional equivalent of a quote ... end blocks. But I'm 
>> hoping include_string() will do the trick (must test though). 
>>
>>
>> sâmbătă, 13 august 2016, 15:20:01 UTC+2, Yichao Yu a scris:
>>>
>>>
>>>
>>> On Sat, Aug 13, 2016 at 8:06 PM, Adrian Salceanu <adrian@gmail.com> 
>>> wrote:
>>>
>>>> That's pretty difficult as my goal is to use embedded Julia as the 
>>>> templating language. Similar to Ruby's ERB, ex: 
>>>> http://www.stuartellis.eu/articles/erb/
>>>>
>>>> So say in the template I have something like 
>>>>
>>>> <% if foo == "bar" %>
>>>> Bar
>>>> <% else %>
>>>> Baz
>>>> <% end %>
>>>>
>>>> The idea is to use Julia itself to parse the code block and Julia will 
>>>> raise an error is foo is not defined. So I can't really look it up. 
>>>>
>>>
>>> It's ok to use the julia syntax and parser but it's a pretty bad idea to 
>>> use the julia runtime to actually evaluating the expression, and absolutely 
>>> not by making them reference to local variables.
>>>
>>> For a start you are not allowed to reference local variables by names 
>>> anyway.
>>> You also shouldn't allow reference to/overwrite of other local variables 
>>> (i.e. the template namespace should be fully isolated and independent of 
>>> any scope in the template engine).
>>>
>>> Since you want to eval, it seems that efficiency is not an issue, in 
>>> which case you can create an anonymous module and eval/create globals in 
>>> that module. This should also be reasonably fast if you are only using the 
>>> template once.
>>>
>>> If you want to use it multiple time and compile the template, you should 
>>> then scan for variable references in the expressions and process it from 
>>> there.
>>>  
>>>
>>>>
>>>> I can either do 
>>>>
>>>> <% if _[:foo] == "bar" %> 
>>>>
>>>> or 
>>>>
>>>> <% if _(:foo) == "bar" %>
>>>>
>>>> but it's not that nice. 
>>>>
>>>>
>>>> sâmbătă, 13 august 2016, 13:24:18 UTC+2, Yichao Yu a scris:
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Aug 13, 2016 at 7:13 PM, Adrian Salceanu <adrian@gmail.com
>>>>> > wrote:
>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> It's for a templating engine. The user creates the document (a 
>>>>>> string) which contains interpolated variables placeholders and markup. 
>>>>>> When 
>>>>>> the template is rendered, the placeholders must be replaced with the 
>>>>>> corresponding values from the dict.
>>>>>>
>>>>>> The lines in the template are eval-ed and so Julia will look for the 
>>>>>> variables in the scope. So the vars should be already defined.
>>>>>>
>>>>>
>>>>> You should explicitly look up those variables in the dict instead.
>>>>>  
>>>>>
>>>>>>
>>>>>> Yes, ultimately I can force the user to use a dict (or rather a 
>>>>>> function for a bit of semantic sugar) - which is preferable from a 
>>>>>> performance perspective, but less pretty end error prone from the user 
>>>>>> perspective.
>>>>>
>>>>>
>>>>>
>>>

Re: [julia-users] Help please: how to expand dictionary into (local ?) variables with the same name as the keys and the corresponding values

[Adrian Salceanu]

OK, actually, that's not nearly half as bad. Variables contained in a 
module 

include("src/Ejl_str.jl")
using Ejl


module _
  couñtry = "España"
  lang = "en"
end


function render_template()
  tpl_data = ejl"""
<% if _.lang == "en" :>
Hello from me, ...
<: else :>
Hola
<: end %>


%= _.couñtry == "España" ? "Olé" : "Aye"
moo
"""


  include_string(join(tpl_data, "\n"))
  join(output, "\n")
end


render_template() |> println

Hello from me, ...


Olé
moo


duminică, 14 august 2016, 11:20:37 UTC+2, Adrian Salceanu a scris:
>
> Thanks
>
> Yes, I've thought about a few ways to mitigate some of these issues: 
>
> 1. in the app I can setup a module (like Render) and evaluate into this 
> module exclusively. 
> Hence, another approach might be to have some helper methods that setup 
> the variables in the module and then eval the template itself inside the 
> module too (must try though). So something in the lines of: 
> set(:foo, "foo")
> set(:bar, [1, 2, 3])
> parse_tpl(ejl"""$(foo) and $(bar)""")
> # all the above gets parsed in Render
>
> 2. break the parsing in 2 steps: 
> a. reading the template string and parse it to generated Julia code (as 
> strings) (an array of Julia code lines) - cache it 
> b. (load strings from cache and) eval the code together with the vars 
>
> ===
>
> Another approach (which is how it's done in one of the Ruby templating 
> engine) is to generate a full function definition, whose body parses the 
> template and takes the variables as params. And then eval and execute the 
> function with its params. However, I'm still struggling with the 
> metaprogramming API as for instance parse() chokes on multiple lines, and I 
> couldn't find a functional equivalent of a quote ... end blocks. But I'm 
> hoping include_string() will do the trick (must test though). 
>
>
> sâmbătă, 13 august 2016, 15:20:01 UTC+2, Yichao Yu a scris:
>>
>>
>>
>> On Sat, Aug 13, 2016 at 8:06 PM, Adrian Salceanu <adrian@gmail.com> 
>> wrote:
>>
>>> That's pretty difficult as my goal is to use embedded Julia as the 
>>> templating language. Similar to Ruby's ERB, ex: 
>>> http://www.stuartellis.eu/articles/erb/
>>>
>>> So say in the template I have something like 
>>>
>>> <% if foo == "bar" %>
>>> Bar
>>> <% else %>
>>> Baz
>>> <% end %>
>>>
>>> The idea is to use Julia itself to parse the code block and Julia will 
>>> raise an error is foo is not defined. So I can't really look it up. 
>>>
>>
>> It's ok to use the julia syntax and parser but it's a pretty bad idea to 
>> use the julia runtime to actually evaluating the expression, and absolutely 
>> not by making them reference to local variables.
>>
>> For a start you are not allowed to reference local variables by names 
>> anyway.
>> You also shouldn't allow reference to/overwrite of other local variables 
>> (i.e. the template namespace should be fully isolated and independent of 
>> any scope in the template engine).
>>
>> Since you want to eval, it seems that efficiency is not an issue, in 
>> which case you can create an anonymous module and eval/create globals in 
>> that module. This should also be reasonably fast if you are only using the 
>> template once.
>>
>> If you want to use it multiple time and compile the template, you should 
>> then scan for variable references in the expressions and process it from 
>> there.
>>  
>>
>>>
>>> I can either do 
>>>
>>> <% if _[:foo] == "bar" %> 
>>>
>>> or 
>>>
>>> <% if _(:foo) == "bar" %>
>>>
>>> but it's not that nice. 
>>>
>>>
>>> sâmbătă, 13 august 2016, 13:24:18 UTC+2, Yichao Yu a scris:
>>>>
>>>>
>>>>
>>>> On Sat, Aug 13, 2016 at 7:13 PM, Adrian Salceanu <adrian@gmail.com> 
>>>> wrote:
>>>>
>>>>> Thanks
>>>>>
>>>>> It's for a templating engine. The user creates the document (a string) 
>>>>> which contains interpolated variables placeholders and markup. When the 
>>>>> template is rendered, the placeholders must be replaced with the 
>>>>> corresponding values from the dict.
>>>>>
>>>>> The lines in the template are eval-ed and so Julia will look for the 
>>>>> variables in the scope. So the vars should be already defined.
>>>>>
>>>>
>>>> You should explicitly look up those variables in the dict instead.
>>>>  
>>>>
>>>>>
>>>>> Yes, ultimately I can force the user to use a dict (or rather a 
>>>>> function for a bit of semantic sugar) - which is preferable from a 
>>>>> performance perspective, but less pretty end error prone from the user 
>>>>> perspective.
>>>>
>>>>
>>>>
>>

Re: [julia-users] Help please: how to expand dictionary into (local ?) variables with the same name as the keys and the corresponding values

[Adrian Salceanu]

Uh, that's nice! Thanks, I'll give it a try. 

sâmbătă, 13 august 2016, 18:42:04 UTC+2, Daniel O'Malley a scris:
>
> The populateexpression function from MetaProgTools might be helpful. For 
> example, you could do something like:
>
> julia> q = :(x + y + 3)
> :(x + y + 3)
>
> julia> eval(MetaProgTools.populateexpression(q, Dict("x"=>1, "y"=>2)))
> 6
>
> On Saturday, August 13, 2016 at 3:07:38 AM UTC-6, Adrian Salceanu wrote:
>>
>> Thanks, but I don't know what the dict contains, it is user defined. 
>
>

Re: [julia-users] Help please: how to expand dictionary into (local ?) variables with the same name as the keys and the corresponding values

[Adrian Salceanu]

Thanks

Yes, I've thought about a few ways to mitigate some of these issues: 

1. in the app I can setup a module (like Render) and evaluate into this 
module exclusively. 
Hence, another approach might be to have some helper methods that setup the 
variables in the module and then eval the template itself inside the module 
too (must try though). So something in the lines of: 
set(:foo, "foo")
set(:bar, [1, 2, 3])
parse_tpl(ejl"""$(foo) and $(bar)""")
# all the above gets parsed in Render

2. break the parsing in 2 steps: 
a. reading the template string and parse it to generated Julia code (as 
strings) (an array of Julia code lines) - cache it 
b. (load strings from cache and) eval the code together with the vars 

===

Another approach (which is how it's done in one of the Ruby templating 
engine) is to generate a full function definition, whose body parses the 
template and takes the variables as params. And then eval and execute the 
function with its params. However, I'm still struggling with the 
metaprogramming API as for instance parse() chokes on multiple lines, and I 
couldn't find a functional equivalent of a quote ... end blocks. But I'm 
hoping include_string() will do the trick (must test though). 


sâmbătă, 13 august 2016, 15:20:01 UTC+2, Yichao Yu a scris:
>
>
>
> On Sat, Aug 13, 2016 at 8:06 PM, Adrian Salceanu <adrian@gmail.com 
> > wrote:
>
>> That's pretty difficult as my goal is to use embedded Julia as the 
>> templating language. Similar to Ruby's ERB, ex: 
>> http://www.stuartellis.eu/articles/erb/
>>
>> So say in the template I have something like 
>>
>> <% if foo == "bar" %>
>> Bar
>> <% else %>
>> Baz
>> <% end %>
>>
>> The idea is to use Julia itself to parse the code block and Julia will 
>> raise an error is foo is not defined. So I can't really look it up. 
>>
>
> It's ok to use the julia syntax and parser but it's a pretty bad idea to 
> use the julia runtime to actually evaluating the expression, and absolutely 
> not by making them reference to local variables.
>
> For a start you are not allowed to reference local variables by names 
> anyway.
> You also shouldn't allow reference to/overwrite of other local variables 
> (i.e. the template namespace should be fully isolated and independent of 
> any scope in the template engine).
>
> Since you want to eval, it seems that efficiency is not an issue, in which 
> case you can create an anonymous module and eval/create globals in that 
> module. This should also be reasonably fast if you are only using the 
> template once.
>
> If you want to use it multiple time and compile the template, you should 
> then scan for variable references in the expressions and process it from 
> there.
>  
>
>>
>> I can either do 
>>
>> <% if _[:foo] == "bar" %> 
>>
>> or 
>>
>> <% if _(:foo) == "bar" %>
>>
>> but it's not that nice. 
>>
>>
>> sâmbătă, 13 august 2016, 13:24:18 UTC+2, Yichao Yu a scris:
>>>
>>>
>>>
>>> On Sat, Aug 13, 2016 at 7:13 PM, Adrian Salceanu <adrian@gmail.com> 
>>> wrote:
>>>
>>>> Thanks
>>>>
>>>> It's for a templating engine. The user creates the document (a string) 
>>>> which contains interpolated variables placeholders and markup. When the 
>>>> template is rendered, the placeholders must be replaced with the 
>>>> corresponding values from the dict.
>>>>
>>>> The lines in the template are eval-ed and so Julia will look for the 
>>>> variables in the scope. So the vars should be already defined.
>>>>
>>>
>>> You should explicitly look up those variables in the dict instead.
>>>  
>>>
>>>>
>>>> Yes, ultimately I can force the user to use a dict (or rather a 
>>>> function for a bit of semantic sugar) - which is preferable from a 
>>>> performance perspective, but less pretty end error prone from the user 
>>>> perspective.
>>>
>>>
>>>
>

Re: [julia-users] Help please: how to expand dictionary into (local ?) variables with the same name as the keys and the corresponding values

[Adrian Salceanu]

That's pretty difficult as my goal is to use embedded Julia as the 
templating language. Similar to Ruby's ERB, 
ex: http://www.stuartellis.eu/articles/erb/

So say in the template I have something like 

<% if foo == "bar" %>
Bar
<% else %>
Baz
<% end %>

The idea is to use Julia itself to parse the code block and Julia will 
raise an error is foo is not defined. So I can't really look it up. 

I can either do 

<% if _[:foo] == "bar" %> 

or 

<% if _(:foo) == "bar" %>

but it's not that nice. 


sâmbătă, 13 august 2016, 13:24:18 UTC+2, Yichao Yu a scris:
>
>
>
> On Sat, Aug 13, 2016 at 7:13 PM, Adrian Salceanu <adrian@gmail.com 
> > wrote:
>
>> Thanks
>>
>> It's for a templating engine. The user creates the document (a string) 
>> which contains interpolated variables placeholders and markup. When the 
>> template is rendered, the placeholders must be replaced with the 
>> corresponding values from the dict.
>>
>> The lines in the template are eval-ed and so Julia will look for the 
>> variables in the scope. So the vars should be already defined.
>>
>
> You should explicitly look up those variables in the dict instead.
>  
>
>>
>> Yes, ultimately I can force the user to use a dict (or rather a function 
>> for a bit of semantic sugar) - which is preferable from a performance 
>> perspective, but less pretty end error prone from the user perspective.
>
>
>

Re: [julia-users] Help please: how to expand dictionary into (local ?) variables with the same name as the keys and the corresponding values

[Adrian Salceanu]

Thanks

It's for a templating engine. The user creates the document (a string) which 
contains interpolated variables placeholders and markup. When the template is 
rendered, the placeholders must be replaced with the corresponding values from 
the dict.

The lines in the template are eval-ed and so Julia will look for the variables 
in the scope. So the vars should be already defined. 

Yes, ultimately I can force the user to use a dict (or rather a function for a 
bit of semantic sugar) - which is preferable from a performance perspective, 
but less pretty end error prone from the user perspective.

[julia-users] Help please: how to expand dictionary into (local ?) variables with the same name as the keys and the corresponding values

[Adrian Salceanu]

Hi, 

This seems to be a recurring question per my googlings, but still I could 
not find a satisfactory answer. 

I'm looking for a generic way of doing this: 

render_template(template_content, Dict(:greeting => "Hello", :greeted => 
"World", :other => Dict("foo" => 1)))

where 

function render_template(template_content, template_vars = Dict{Symbol,Any
}()) 
  # here instantiate template_vars keys with corresponding values, so that 
  # greeting = "Hello"
  # greeted = "World"
  # other = Dict("foo" => 1)
end

Thanks! 

Re: [julia-users] How to debug segmentation fault?

[Adrian Salceanu]

Thanks Jacob

Huhm, probably not worth spending time with debug builds of v0.4 when 0.5 
is just around the corner. Think it's time to upgrade to 0.5 and debug that 
if needed. 


marți, 9 august 2016, 17:58:10 UTC+2, Jacob Quinn a scris:
>
> There are many much more knowledgeable than me on this, but I know there's 
> a good section in the manual to help you get started: 
> http://docs.julialang.org/en/latest/devdocs/C/
>
> -Jacob
>
> On Tue, Aug 9, 2016 at 9:53 AM, Adrian Salceanu <adrian@gmail.com 
> > wrote:
>
>> I ran into an issue where apparently at random I get segmentation faults 
>> - how can I find out what exactly is causing the problem? 
>>
>> Here is the dump: 
>> signal (11): Segmentation fault: 11
>> julia_call_23669 at  (unknown line)
>> disposable_instance at /Users/adrian/Dropbox/Projects/jinnie/lib/Genie/
>> src/Model.jl:647
>> to_select_part at /Users/adrian/Dropbox/Projects/jinnie/lib/Genie/src/
>> Model.jl:262
>> to_fetch_sql at /Users/adrian/Dropbox/Projects/jinnie/lib/Genie/src/Model
>> .jl:542
>> find at /Users/adrian/Dropbox/Projects/jinnie/lib/Genie/src/Model.jl:40
>> jl_apply at /private/tmp/julia-20160615-15177-tdcnou/src/./julia.h:1331
>> find_one_by at /Users/adrian/Dropbox/Projects/jinnie/lib/Genie/src/Model.
>> jl:55
>> jl_apply at /private/tmp/julia-20160615-15177-tdcnou/src/./julia.h:1331
>> current_user at /Users/adrian/Dropbox/Projects/jinnie/app/resources/users
>> /model.jl:64
>> jl_apply at /private/tmp/julia-20160615-15177-tdcnou/src/gf.c:1691
>> with_authorization at /Users/adrian/Dropbox/Projects/jinnie/app/resources
>> /users/model.jl:82
>> articles at /Users/adrian/Dropbox/Projects/jinnie/app/resources/articles
>> /./modules/AdminController.jl:6
>> jl_apply at /private/tmp/julia-20160615-15177-tdcnou/src/./julia.h:1331
>> jl_f_invoke at /private/tmp/julia-20160615-15177-tdcnou/src/builtins.c:
>> 1114
>> invoke_controller at /Users/adrian/Dropbox/Projects/jinnie/lib/Genie/src/
>> Router.jl:187
>> jl_apply at /private/tmp/julia-20160615-15177-tdcnou/src/./julia.h:1331
>> match_routes at /Users/adrian/Dropbox/Projects/jinnie/lib/Genie/src/
>> Router.jl:73
>> route_request at /Users/adrian/Dropbox/Projects/jinnie/lib/Genie/src/
>> Router.jl:44
>> jl_apply at /private/tmp/julia-20160615-15177-tdcnou/src/./julia.h:1331
>> anonymous at /Users/adrian/Dropbox/Projects/jinnie/lib/Genie/src/
>> AppServer.jl:18
>> on_message_complete at /Users/adrian/.julia/v0.4/HttpServer/src/
>> HttpServer.jl:400
>> jl_apply at /private/tmp/julia-20160615-15177-tdcnou/src/./julia.h:1331
>> on_message_complete at /Users/adrian/.julia/v0.4/HttpServer/src/
>> RequestParser.jl:104
>> jlcapi_on_message_complete_21686 at  (unknown line)
>> http_parser_execute at /Users/adrian/.julia/v0.4/HttpParser/deps/usr/lib/
>> libhttp_parser.dylib (unknown line)
>> http_parser_execute at /Users/adrian/.julia/v0.4/HttpParser/src/
>> HttpParser.jl:92
>> process_client at /Users/adrian/.julia/v0.4/HttpServer/src/HttpServer.jl:
>> 365
>> jlcall_process_client_23170 at  (unknown line)
>> jl_apply at /private/tmp/julia-20160615-15177-tdcnou/src/./julia.h:1331
>> anonymous at task.jl:447
>> jl_apply at /private/tmp/julia-20160615-15177-tdcnou/src/./julia.h:1331
>> [1]50892 segmentation fault  ./genie.jl s
>>
>> and this is the last known function (which works ok in different 
>> circumstances): 
>>
>> function disposable_instance{T<:AbstractModel}(m::Type{T})
>>   if m <: AbstractModel
>> return m()
>>   else
>> error("$m is not a concrete subtype of AbstractModel")
>>   end
>> end
>>
>>
>

[julia-users] How to debug segmentation fault?

[Adrian Salceanu]

I ran into an issue where apparently at random I get segmentation faults - 
how can I find out what exactly is causing the problem? 

Here is the dump: 
signal (11): Segmentation fault: 11
julia_call_23669 at  (unknown line)
disposable_instance at /Users/adrian/Dropbox/Projects/jinnie/lib/Genie/src/
Model.jl:647
to_select_part at /Users/adrian/Dropbox/Projects/jinnie/lib/Genie/src/Model.
jl:262
to_fetch_sql at /Users/adrian/Dropbox/Projects/jinnie/lib/Genie/src/Model.jl
:542
find at /Users/adrian/Dropbox/Projects/jinnie/lib/Genie/src/Model.jl:40
jl_apply at /private/tmp/julia-20160615-15177-tdcnou/src/./julia.h:1331
find_one_by at /Users/adrian/Dropbox/Projects/jinnie/lib/Genie/src/Model.jl:
55
jl_apply at /private/tmp/julia-20160615-15177-tdcnou/src/./julia.h:1331
current_user at /Users/adrian/Dropbox/Projects/jinnie/app/resources/users/
model.jl:64
jl_apply at /private/tmp/julia-20160615-15177-tdcnou/src/gf.c:1691
with_authorization at /Users/adrian/Dropbox/Projects/jinnie/app/resources/
users/model.jl:82
articles at /Users/adrian/Dropbox/Projects/jinnie/app/resources/articles/./
modules/AdminController.jl:6
jl_apply at /private/tmp/julia-20160615-15177-tdcnou/src/./julia.h:1331
jl_f_invoke at /private/tmp/julia-20160615-15177-tdcnou/src/builtins.c:1114
invoke_controller at /Users/adrian/Dropbox/Projects/jinnie/lib/Genie/src/
Router.jl:187
jl_apply at /private/tmp/julia-20160615-15177-tdcnou/src/./julia.h:1331
match_routes at /Users/adrian/Dropbox/Projects/jinnie/lib/Genie/src/Router.
jl:73
route_request at /Users/adrian/Dropbox/Projects/jinnie/lib/Genie/src/Router.
jl:44
jl_apply at /private/tmp/julia-20160615-15177-tdcnou/src/./julia.h:1331
anonymous at /Users/adrian/Dropbox/Projects/jinnie/lib/Genie/src/AppServer.
jl:18
on_message_complete at /Users/adrian/.julia/v0.4/HttpServer/src/HttpServer.
jl:400
jl_apply at /private/tmp/julia-20160615-15177-tdcnou/src/./julia.h:1331
on_message_complete at /Users/adrian/.julia/v0.4/HttpServer/src/
RequestParser.jl:104
jlcapi_on_message_complete_21686 at  (unknown line)
http_parser_execute at /Users/adrian/.julia/v0.4/HttpParser/deps/usr/lib/
libhttp_parser.dylib (unknown line)
http_parser_execute at /Users/adrian/.julia/v0.4/HttpParser/src/HttpParser.
jl:92
process_client at /Users/adrian/.julia/v0.4/HttpServer/src/HttpServer.jl:365
jlcall_process_client_23170 at  (unknown line)
jl_apply at /private/tmp/julia-20160615-15177-tdcnou/src/./julia.h:1331
anonymous at task.jl:447
jl_apply at /private/tmp/julia-20160615-15177-tdcnou/src/./julia.h:1331
[1]50892 segmentation fault  ./genie.jl s

and this is the last known function (which works ok in different 
circumstances): 

function disposable_instance{T<:AbstractModel}(m::Type{T})
  if m <: AbstractModel
return m()
  else
error("$m is not a concrete subtype of AbstractModel")
  end
end

[julia-users] Re: ANN: New Julia Packages website

[Adrian Salceanu]

Sure, I'll take a look at the current source and then we can go into more 
details. 

In general though, I think it's important to come up with a higher level 
(branding/visual) strategy, in regards to Julia online resources. 

1. what's the value of (web) design. http://julialang.org/ looks a bit 
simple/dated, though that's not necessarily a bad thing. Some other 
languages have fancy home pages 
(http://www.scala-lang.org/, https://kotlinlang.org/, https://www.python.org/). 
Other go for a minimalist approach 
(https://swift.org/, http://elixir-lang.org/). The minimalist approach is 
nice and it's in line with what Julia has now. In my opinion the current 
website can stay pretty much as it is but ideally with an update in terms 
of typography. The serif font doesn't quite communicate "new, modern 
programming language and technology". 

2. how will the ecosystem be organized? For example, now the Pkg project 
(and the listing) is a subdomain of julialang.org. This hints that it's the 
same website and it might make sense to keep the same visual identity. 
Other technologies have opted to separate the package managers into 
distinct projects, with different websites and visual identities 
(https://hex.pm/, https://rubygems.org/, https://www.npmjs.com/, etc). 

A

miercuri, 13 iulie 2016, 14:07:26 UTC+2, Tony Kelman a scris:
>
> "Improvements" might mean up to and including complete replacement. The 
> main thing I'd want to be sure we keep is having a mechanism for uploading 
> automated nightly results from PackageEvaluator, building the pulse page 
> http://pkg.julialang.org/pulse.html, etc.
>
>
> On Wednesday, July 13, 2016 at 2:13:25 AM UTC-7, Adrian Salceanu wrote:
>>
>> Thanks Mosè! :) 
>>
>> I think Tony's idea is the best way to go about it. This website is more 
>> of a temporary patch as searching in pkg.julialang is inefficient (just 
>> browser search with little context and then if something looks interesting 
>> you have to open the repo, look around, get back, etc). Like I said, I'd 
>> very much prefer to collaborate on building a modern and useful package 
>> management and discovery ecosystem, something in the lines of 
>> https://hex.pm or https://rubygems.org - rather than spread our limited 
>> resources on similar projects. 
>>
>> Tony, happy to help, but we need to get more specific about improvements. 
>> If we're talking basic additions to the existing codebase, we can add 
>> search capabilities as I also expose this data through an API (ex: 
>> http://genieframework.com/api/v1/packages/search?q=tensorflow). If we're 
>> talking about building a modern platform, similar to say hex.pm then 
>> it's easier to extend the website I've built (as it's almost there). 
>>
>>
>> miercuri, 13 iulie 2016, 09:04:51 UTC+2, Tony Kelman a scris:
>>>
>>> Regarding package keywords, that would be something to include in the 
>>> Pkg3 manifest file, see https://github.com/JuliaLang/PkgDev.jl/issues/37 
>>> for initial thoughts.
>>>
>>> I'm pretty much maintaining pkg.julialang.org at the moment, we can 
>>> certainly consider improvements. The website source is in the JuliaCI 
>>> organization, as are the scripts that generate it (in PackageEvaluator.jl) 
>>> nightly.
>>>
>>>
>>> On Tuesday, July 12, 2016 at 9:52:05 AM UTC-7, Mosè Giordano wrote:
>>>>
>>>> Hi Adrian,
>>>>
>>>> nice website!
>>>>
>>>> What I'd like to have in a Julia packages website is categories.  This 
>>>> would greatly enhances the possibilities for the users to find the package 
>>>> they're looking for.  Currently one must use search strings, but they may 
>>>> not be very effective if the package author didn't use the exact words one 
>>>> is using in the search.  Of course this requires help from package 
>>>> authors.  I'm using a "keywords" cookie in the package comments like the 
>>>> one suggested in Emacs Lisp conventions: 
>>>> https://www.gnu.org/software/emacs/manual/html_node/elisp/Library-Headers.html#Library-Headers
>>>>   
>>>> Maybe something similar can be implemented in METADATA.jl and Pkg.generate 
>>>> could accept a category list as argument.  We can choose a set of 
>>>> "official" keywords that are listed in Julia packages websites.  I hope 
>>>> this will improve discoverability of packages.
>>>>
>>>> Bye,
>>>> Mosè
>>>>
>>>>
>>>> I've setup an early version of a Julia packages website, for your 
>>>>> pa

[julia-users] Re: ANN: New Julia Packages website

[Adrian Salceanu]

Thanks Mosè! :) 

I think Tony's idea is the best way to go about it. This website is more of 
a temporary patch as searching in pkg.julialang is inefficient (just 
browser search with little context and then if something looks interesting 
you have to open the repo, look around, get back, etc). Like I said, I'd 
very much prefer to collaborate on building a modern and useful package 
management and discovery ecosystem, something in the lines 
of https://hex.pm or https://rubygems.org - rather than spread our limited 
resources on similar projects. 

Tony, happy to help, but we need to get more specific about improvements. 
If we're talking basic additions to the existing codebase, we can add 
search capabilities as I also expose this data through an API (ex: 
http://genieframework.com/api/v1/packages/search?q=tensorflow). If we're 
talking about building a modern platform, similar to say hex.pm then it's 
easier to extend the website I've built (as it's almost there). 


miercuri, 13 iulie 2016, 09:04:51 UTC+2, Tony Kelman a scris:
>
> Regarding package keywords, that would be something to include in the Pkg3 
> manifest file, see https://github.com/JuliaLang/PkgDev.jl/issues/37 for 
> initial thoughts.
>
> I'm pretty much maintaining pkg.julialang.org at the moment, we can 
> certainly consider improvements. The website source is in the JuliaCI 
> organization, as are the scripts that generate it (in PackageEvaluator.jl) 
> nightly.
>
>
> On Tuesday, July 12, 2016 at 9:52:05 AM UTC-7, Mosè Giordano wrote:
>>
>> Hi Adrian,
>>
>> nice website!
>>
>> What I'd like to have in a Julia packages website is categories.  This 
>> would greatly enhances the possibilities for the users to find the package 
>> they're looking for.  Currently one must use search strings, but they may 
>> not be very effective if the package author didn't use the exact words one 
>> is using in the search.  Of course this requires help from package 
>> authors.  I'm using a "keywords" cookie in the package comments like the 
>> one suggested in Emacs Lisp conventions: 
>> https://www.gnu.org/software/emacs/manual/html_node/elisp/Library-Headers.html#Library-Headers
>>   
>> Maybe something similar can be implemented in METADATA.jl and Pkg.generate 
>> could accept a category list as argument.  We can choose a set of 
>> "official" keywords that are listed in Julia packages websites.  I hope 
>> this will improve discoverability of packages.
>>
>> Bye,
>> Mosè
>>
>>
>> I've setup an early version of a Julia packages website, for your package 
>>> discovery pleasure: http://genieframework.com/packages 
>>>
>>> Fair warning, this is a test case website for Genie.jl, the full stack 
>>> web framework I'm working on - and 90% of my focus was on building the 
>>> actual framework and the app, rather than the accuracy of the data. 
>>>
>>> That being said, the app works quite well as far as I can tell (feedback 
>>> welcome!) and compared to pkg.julialang.org it has a few extra 
>>> features:  
>>> * full text search in README 
>>> * it includes both METADATA registered packages and extra packages 
>>> crawled from GitHub (not all Julia packages on GitHub are included, this is 
>>> a know bug and I'm working on fixing it - but all the official packages are 
>>> there). 
>>> * lots of info at a glance, to help spot the best packages
>>> * modern UI
>>>
>>> If the core contributors (of whoever's maintaining pkg.julialang.org) 
>>> think this can be a useful replacement for pkg.julialang.org I'm happy 
>>> to donate it and contribute by extending it to add the missing features 
>>> (license, tests status, etc) and maintain it. Let me know. 
>>>
>>> Adrian
>>>
>>

[julia-users] Re: ANN: New Julia Packages website

[Adrian Salceanu]

I've now added a chat for Genie.jl :) 

vineri, 8 iulie 2016, 17:03:35 UTC+2, Adrian Salceanu a scris:
>
> Thanks Eric! 
>
> Yeah, the Rust package is pretty cool, I've stumbled onto it myself 
> earlier :-O
>
> Genie.jl, thanks! It's still early but I'm super hyped by the way it comes 
> out! 
>
> Yeah, I'm on Gitter, on JuliaLang and JuliaLangEs. 
>
> A
>
> vineri, 8 iulie 2016, 16:49:03 UTC+2, Eric Forgy a scris:
>>
>> Btw, Genie.jl also looks super cool +1. Are you on Gitter or?
>>
>> On Friday, July 8, 2016 at 10:37:59 PM UTC+8, Eric Forgy wrote:
>>>
>>> This looks pretty awesome. Thanks!
>>>
>>> I found a bunch of awesome looking new packages too with this, e.g. 
>>> Rust.jl :heart_eyes:
>>>
>>

[julia-users] Re: ANN: New Julia Packages website

[Adrian Salceanu]

Thanks Eric! 

Yeah, the Rust package is pretty cool, I've stumbled onto it myself earlier 
:-O

Genie.jl, thanks! It's still early but I'm super hyped by the way it comes 
out! 

Yeah, I'm on Gitter, on JuliaLang and JuliaLangEs. 

A

vineri, 8 iulie 2016, 16:49:03 UTC+2, Eric Forgy a scris:
>
> Btw, Genie.jl also looks super cool +1. Are you on Gitter or?
>
> On Friday, July 8, 2016 at 10:37:59 PM UTC+8, Eric Forgy wrote:
>>
>> This looks pretty awesome. Thanks!
>>
>> I found a bunch of awesome looking new packages too with this, e.g. 
>> Rust.jl :heart_eyes:
>>
>

[julia-users] ANN: New Julia Packages website

[Adrian Salceanu]

I've setup an early version of a Julia packages website, for your package 
discovery pleasure: http://genieframework.com/packages 

Fair warning, this is a test case website for Genie.jl, the full stack web 
framework I'm working on - and 90% of my focus was on building the actual 
framework and the app, rather than the accuracy of the data. 

That being said, the app works quite well as far as I can tell (feedback 
welcome!) and compared to pkg.julialang.org it has a few extra features:  
* full text search in README 
* it includes both METADATA registered packages and extra packages crawled 
from GitHub (not all Julia packages on GitHub are included, this is a know 
bug and I'm working on fixing it - but all the official packages are 
there). 
* lots of info at a glance, to help spot the best packages
* modern UI

If the core contributors (of whoever's maintaining pkg.julialang.org) think 
this can be a useful replacement for pkg.julialang.org I'm happy to donate 
it and contribute by extending it to add the missing features (license, 
tests status, etc) and maintain it. Let me know. 

Adrian

[julia-users] Re: Function that accepts AbstractString does not accept UTF8String? Help :-ss

[Adrian Salceanu]

And this works perfectly well too indeed, 
render{T<:AbstractString}(p::Dict{T})

I didn't realize the type of the value can be omitted, pretty cool! 


joi, 7 iulie 2016, 19:01:55 UTC+2, Adrian Salceanu a scris:
>
> Thanks Steven, 
>
> It works perfectly fine like this: 
>
> julia> function foo{T<:AbstractString, U<:Any}(p::Dict{T, U})
>@show p
>end
> foo (generic function with 2 methods)
>
> julia> foo(Dict("abc" => 123))
> p = Dict("abc"=>123)
> Dict{ASCIIString,Int64} with 1 entry:
>   "abc" => 123
>
> Still puzzled as to why the code has worked before and still works on 
> linux, but as long as this works I'm happy with it. Cheers!
>
> joi, 7 iulie 2016, 18:36:57 UTC+2, Steven G. Johnson a scris:
>>
>> You want
>>
>> render{T<:AbstractString}(p::Dict{T})
>>
>> See the bit about "invariant" types in 
>> http://docs.julialang.org/en/latest/manual/types/#parametric-composite-types
>>
>

[julia-users] Re: Function that accepts AbstractString does not accept UTF8String? Help :-ss

[Adrian Salceanu]

Thanks Steven, 

It works perfectly fine like this: 

julia> function foo{T<:AbstractString, U<:Any}(p::Dict{T, U})
   @show p
   end
foo (generic function with 2 methods)

julia> foo(Dict("abc" => 123))
p = Dict("abc"=>123)
Dict{ASCIIString,Int64} with 1 entry:
  "abc" => 123

Still puzzled as to why the code has worked before and still works on 
linux, but as long as this works I'm happy with it. Cheers!

joi, 7 iulie 2016, 18:36:57 UTC+2, Steven G. Johnson a scris:
>
> You want
>
> render{T<:AbstractString}(p::Dict{T})
>
> See the bit about "invariant" types in 
> http://docs.julialang.org/en/latest/manual/types/#parametric-composite-types
>

[julia-users] Re: Function that accepts AbstractString does not accept UTF8String? Help :-ss

[Adrian Salceanu]

Plus, per the example, the function does not take an AbstractString 
directly (my bad, bad subject) - but a Dict{AbstractString,Any}


joi, 7 iulie 2016, 18:43:31 UTC+2, Adrian Salceanu a scris:
>
> Thanks Steven, 
>
> That makes sense and I was thinking about the same thing...
>
> But what I don't get is, why has it worked till now and it still works on 
> my Ubuntu server, but no longer works on my Mac? 
>
>
>
> joi, 7 iulie 2016, 18:36:57 UTC+2, Steven G. Johnson a scris:
>>
>> You want
>>
>> render{T<:AbstractString}(p::Dict{T})
>>
>> See the bit about "invariant" types in 
>> http://docs.julialang.org/en/latest/manual/types/#parametric-composite-types
>>
>

[julia-users] Re: Function that accepts AbstractString does not accept UTF8String? Help :-ss

[Adrian Salceanu]

Thanks Steven, 

That makes sense and I was thinking about the same thing...

But what I don't get is, why has it worked till now and it still works on 
my Ubuntu server, but no longer works on my Mac? 



joi, 7 iulie 2016, 18:36:57 UTC+2, Steven G. Johnson a scris:
>
> You want
>
> render{T<:AbstractString}(p::Dict{T})
>
> See the bit about "invariant" types in 
> http://docs.julialang.org/en/latest/manual/types/#parametric-composite-types
>

[julia-users] Function that accepts AbstractString does not accept UTF8String? Help :-ss

[Adrian Salceanu]

Hi, 

I really don't know what to make of this? Am I missing something? Any help 
greatly appreciated. 

I have this function: 

function render(p::Dict{AbstractString,Any})

and I call it sending it 

Dict{UTF8String,Any}("search"=>Dict{UTF8String,Any}("rank"=>0.094717,
"headline"=>"**web** server for 2016.** Escher's built-in **web** server 
allows you to create interactive"),"links"=>Dict{UTF8String,Any}("self"=>
"/api/v1/packages/466"),"attributes"=>Dict{UTF8String,Any}("name"=>"Escher",
"url"=>"git://github.com/shashi/Escher.jl.git"),"id"=>466,"type"=>"packages"
)

and then I get

ERROR: MethodError: `render` has no method matching render(::Dict{UTF8String
,Any})
 [inlined code] from /Users/adrian/Dropbox/Projects/pkg_search/src/PkgSearch
.jl:156
 in __process_results#5__ at no file:0
 in _lookup at /Users/adrian/Dropbox/Projects/pkg_search/src/PkgSearch.jl:64
 in lookup at /Users/adrian/Dropbox/Projects/pkg_search/src/PkgSearch.jl:44

A

[julia-users] Re: Parametric constructor of concrete type accepting all subtypes of an(other) abstract type?

[Adrian Salceanu]

Never mind, after a re-re-read of the docs and a few other resources, it 
finally clicked :) 

type SQLFoo{T<:AbstractModel}
  model_name::Type{T}
  bar::Bool


  SQLFoo(model_name, bar) = new(model_name, bar)
end
SQLFoo{T<:AbstractModel}(model_name::Type{T}; bar::Bool = true) = SQLFoo{T}(
model_name, bar)


vineri, 10 iunie 2016, 20:21:18 UTC+2, Adrian Salceanu a scris:
>
> Hi,
>
> I don't know how to code this, any help appreciated. 
>
> I want to have a concrete type that has a field referencing any of the 
> subtypes of an(other) abstract type. How would I write that? 
>
> This is one of my many attempts: 
>
> type SQLFoo{T <: AbstractModel}
>   model_name::Type{T}
>
>
>   SQLFoo(model_name) = new(model_name)
> end
>
>
> julia> issubtype(Repo, AbstractModel)
> true
>
> julia> SQLFoo(Repo)
> ERROR: MethodError: `convert` has no method matching convert(::Type{SQLFoo
> {T<:AbstractModel}}, ::Type{Repo})
> This may have arisen from a call to the constructor SQLFoo{T<:
> AbstractModel}(...),
> since type constructors fall back to convert methods.
> Closest candidates are:
>   call{T}(::Type{T}, ::Any)
>   convert{T}(::Type{T}, ::T)
>  in call at essentials.jl:56
>
>
> Thanks,
> -- Adrian
>

[julia-users] Re: Parametric constructor of concrete type accepting all subtypes of an(other) abstract type?

[Adrian Salceanu]

A small update - I tried to simplify my example, but I removed too much. 

This version is easy, it's just: 

type SQLFoo{T <: AbstractModel}
  model_name::Type{T}
end

What I'm looking for is having optional args, such as: 

type SQLFoo{T <: AbstractModel}
  model_name::Type{T}
  bar::Bool

  SQLFoo(T; bar = true) = new(model_name, bar)
end

Is this possible? 


vineri, 10 iunie 2016, 20:21:18 UTC+2, Adrian Salceanu a scris:
>
> Hi,
>
> I don't know how to code this, any help appreciated. 
>
> I want to have a concrete type that has a field referencing any of the 
> subtypes of an(other) abstract type. How would I write that? 
>
> This is one of my many attempts: 
>
> type SQLFoo{T <: AbstractModel}
>   model_name::Type{T}
>
>
>   SQLFoo(model_name) = new(model_name)
> end
>
>
> julia> issubtype(Repo, AbstractModel)
> true
>
> julia> SQLFoo(Repo)
> ERROR: MethodError: `convert` has no method matching convert(::Type{SQLFoo
> {T<:AbstractModel}}, ::Type{Repo})
> This may have arisen from a call to the constructor SQLFoo{T<:
> AbstractModel}(...),
> since type constructors fall back to convert methods.
> Closest candidates are:
>   call{T}(::Type{T}, ::Any)
>   convert{T}(::Type{T}, ::T)
>  in call at essentials.jl:56
>
>
> Thanks,
> -- Adrian
>

[julia-users] Parametric constructor of concrete type accepting all subtypes of an(other) abstract type?

[Adrian Salceanu]

Hi,

I don't know how to code this, any help appreciated. 

I want to have a concrete type that has a field referencing any of the 
subtypes of an(other) abstract type. How would I write that? 

This is one of my many attempts: 

type SQLFoo{T <: AbstractModel}
  model_name::Type{T}


  SQLFoo(model_name) = new(model_name)
end


julia> issubtype(Repo, AbstractModel)
true

julia> SQLFoo(Repo)
ERROR: MethodError: `convert` has no method matching convert(::Type{SQLFoo{T
<:AbstractModel}}, ::Type{Repo})
This may have arisen from a call to the constructor SQLFoo{T<:AbstractModel
}(...),
since type constructors fall back to convert methods.
Closest candidates are:
  call{T}(::Type{T}, ::Any)
  convert{T}(::Type{T}, ::T)
 in call at essentials.jl:56


Thanks,
-- Adrian

[julia-users] Re: ANN: PkgSearch - a REPL utility for package discovery

[Adrian Salceanu]

Thanks for the feedback, happy to contribute. 


vineri, 3 iunie 2016, 22:40:50 UTC+2, Adrian Salceanu a scris:
>
> Hi, 
>
> I have released PkgSearch, a small REPL utility for package discovery. 
>
> Package discovery seemed to be a recurring issue, with many related 
> questions - and I can still remember how difficult was for me too, when I 
> started. So it might be a useful tool. 
> I've been using it for a few days and it's kind of neat, being able to 
> quickly search through all the publicly available packages without leaving 
> the REPL :) I hope you'll enjoy it! 
>
> It works in conjunction with an API which powers the actual search. On the 
> server side, a full text search is performed against the README files. It 
> covers both official packages and unofficial ones, searching for them on 
> GitHub (not in real time, the data is imported regularly). This GitHub 
> search is a bit naive still, so false positives might come up. 
>
> More details in the README, at https://github.com/essenciary/PkgSearch
>
> ===
>
> On a related note, the API providing the search results and all the 
> tooling for importing and processing the data is done with Genie (formerly 
> Jinnie) - the Julia web framework I've been working on for many months now. 
> It's not ready for prime time yet but this is definitely a major milestone! 
>
> With this occasion I've also added a very comprehensive README to give you 
> an idea about what it does, how it works and where it's heading. 
>
> You can find it here https://github.com/essenciary/genie - and if you 
> like it, please star it :) 
>
> Cheers,
> Adrian
>

[julia-users] Re: ANN: PkgSearch - a REPL utility for package discovery

[Adrian Salceanu]

Hi, thanks very much for the feedback, much appreciated. 

1. good point, haven't considered that as package names don't have spaces. 
But nonetheless, a search with spaces should definitely be all right. 
I fixed the issue and pushed on GitHub - it now considers whitespace as a 
keyword separator. So lookup("foo bar") is now equivalent to lookup("foo", 
"bar") or lookup(" foo ", "bar "), etc. 

The search is not case sensitive which I think makes sense and it's 
probably what's expected from a user's perspective? 

2. thanks for pointing that out, indeed, the GitHub search data was 
overwriting the data about the official packages. I fixed it. 

julia> PkgSearch.lookup("jump")
=
JuMP
-
Official package
-
git://github.com/JuliaOpt/JuMP.jl.git
-
 JuMP
≡≡


 Julia for Mathematical Programming



  JuMP is a domain-specific modeling language for **[mathematical 
programming
_

Cheers! 

sâmbătă, 4 iunie 2016, 14:07:59 UTC+2, Evan Fields a scris:
>
> Hi, this looks great. Two comments from playing around a little bit.
>
> 1) PkgSearch.lookup fails if any of the arguments contain a space. In 
> general maybe add to the documentation some notes about whitespace, case 
> sensitivity, etc.?
> 2) The search seems to get confused between package names and the 
> corresponding github respository name, which often differ by a .jl at the 
> end. For example, JuMP is one of the most used Julia packages, you can find 
> it on pkg.julialang.org, etc. But PkgSearch.details("JuMP") will give an 
> error. PkgSearch.details("JuMP.jl") gives the readme and associated info 
> from the correct git repo except labels the package unofficial.
>
> Let me know if you want me to open issues on github, etc. Great work 
> overall!
>

[julia-users] ANN: PkgSearch - a REPL utility for package discovery

[Adrian Salceanu]

Hi, 

I have released PkgSearch, a small REPL utility for package discovery. 

Package discovery seemed to be a recurring issue, with many related 
questions - and I can still remember how difficult was for me too, when I 
started. So it might be a useful tool. 
I've been using it for a few days and it's kind of neat, being able to 
quickly search through all the publicly available packages without leaving 
the REPL :) I hope you'll enjoy it! 

It works in conjunction with an API which powers the actual search. On the 
server side, a full text search is performed against the README files. It 
covers both official packages and unofficial ones, searching for them on 
GitHub (not in real time, the data is imported regularly). This GitHub 
search is a bit naive still, so false positives might come up. 

More details in the README, at https://github.com/essenciary/PkgSearch

===

On a related note, the API providing the search results and all the tooling 
for importing and processing the data is done with Genie (formerly Jinnie) 
- the Julia web framework I've been working on for many months now. It's 
not ready for prime time yet but this is definitely a major milestone! 

With this occasion I've also added a very comprehensive README to give you 
an idea about what it does, how it works and where it's heading. 

You can find it here https://github.com/essenciary/genie - and if you like 
it, please star it :) 

Cheers,
Adrian

[julia-users] Re: Ubuntu bug? Executing .jl files via shebang does nothing on Ubuntu 16.04 x64

[Adrian Salceanu]

OK, I figured out what causes the problem. 

It seems that on linux it does not like the --color=yes 

Removed that and it works as expected. 

Cheers! 

joi, 19 mai 2016, 19:48:04 UTC+2, Adrian Salceanu a scris:
>
> Hi, 
>
> There seems to be a problem with executing .jl scripts on Ubuntu 16.04 x64 
>
> Take this simple program in exec_text.jl
>
> #!/usr/bin/env julia --color=yes
> println("all good!")
>
>
> On Mac OS: 
> $ ./exec_test.jl
> all good!
>
>
> On Ubuntu it just hangs
> $ ./exec_test.jl
>
> [=> never returns, does nothing]
>
> This works as expected: 
> $ julia exec_test.jl
> all good!
>
> But this is not an acceptable solution as I need to execute my program in 
> order to pass command line args to it. Otherwise julia would just gobble up 
> the command line args intended for my script. 
>
> Thanks,
> Adrian
>

[julia-users] Ubuntu bug? Executing .jl files via shebang does nothing on Ubuntu 16.04 x64

[Adrian Salceanu]

Hi, 

There seems to be a problem with executing .jl scripts on Ubuntu 16.04 x64 

Take this simple program in exec_text.jl

#!/usr/bin/env julia --color=yes
println("all good!")


On Mac OS: 
$ ./exec_test.jl
all good!


On Ubuntu it just hangs
$ ./exec_test.jl

[=> never returns, does nothing]

This works as expected: 
$ julia exec_test.jl
all good!

But this is not an acceptable solution as I need to execute my program in 
order to pass command line args to it. Otherwise julia would just gobble up 
the command line args intended for my script. 

Thanks,
Adrian

[julia-users] Re: [ANN] Book: Julia High Performance

[Adrian Salceanu]

I quite enjoy it - nicely written, to the subject, makes for a very 
pleasant read. 

Also, nice to see that Packt has recently had a Julia offer of the day, 
including the 4 books on Julia they're published. They're all very good. 

I'm considering writing a book on web development with Julia - planning on 
starting in the next 6 -12 months. I was wondering what was the process for 
getting your book published with Packt? Are you happy with your choice of 
publisher? Why not something like LeanPub? Or finally, why not a web book, 
that you could keep updating, given that things might change considerably 
until Julia reaches v1 (and beyond). 

Cheers!

marți, 3 mai 2016, 01:17:57 UTC+2, Avik Sengupta a scris:
>
> Just wanted to let you know about the new book discussing the design and 
> development of high performance julia code. It discusses the tools you can 
> use to analyse the performance of your code, and ways to make it go faster, 
> using the full power of Julia's compiler.  Hope this is useful for some. 
>
> https://www.packtpub.com/application-development/julia-high-performance
>
> Regards
> -
> Avik
>
> (Incidentally, all the ebooks from the publisher are being discounted for 
> the next day or so)
>

Re: [julia-users] Why does julia use END for block end?

[Adrian Salceanu]

That's right Tim, it does work! Huhm... I can't exactly remember where I 
tripped into this one, as since I've abandoned this style and it's been a 
while. But yes, the explanation must be that the _first_ expression was not 
a boolean. 

Loving this, thanks very much! 

vineri, 6 mai 2016, 23:11:17 UTC+2, Tim Holy a scris:
>
> I think the problem was expr1, not expr2: you probably didn't make expr1 
> return a Bool. (Julia deliberately does not support "if cond" unless cond 
> is a 
> Bool.) 
>
> Demo of correct usage: 
>
> julia> x = 5 
> 5 
>
> julia> x == 4 && "hello" 
> false 
>
> julia> x == 5 && "world" 
> "world" 
>
> Best, 
> --Tim 
>
> On Friday, May 06, 2016 12:12:28 PM Adrian Salceanu wrote: 
> > The only place where I find the "end" requirement annoying is for one 
> line 
> > IF statements. When you have a short one liner, the "end" part just does 
> > not feel right. It would be nice if the "end" could be left out for one 
> > liners. Even PHP allows one to skip the accolades in such cases. 
> > 
> > If there's some other way of achieving this I'd love to hear about it. I 
> > don't like the ternary operator in this situation cause it forces me to 
> add 
> > the 3rd part as "nothing" or whatever. And doing "expr1 && expr2" only 
> > works when expr2 is "return" for instance, otherwise the compiler 
> complains 
> > about using a non-boolean in a boolean context. 
> > 
> > vineri, 6 mai 2016, 20:37:49 UTC+2, Stefan Karpinski a scris: 
> > > There is a long history of languages using this syntax, including 
> Algol, 
> > > Pascal, Ruby and Matlab. 
> > > 
> > > On Fri, May 6, 2016 at 2:26 PM, Ford Ox <ford...@gmail.com 
> > 
> > > 
> > > wrote: 
> > >> Is there any reasoning behind it? It seems to me like a weird choice 
> > >> since you have to type three letters, which is the complete opposite 
> of 
> > >> the 
> > >> goal of this language - being very productive (a lot work done with 
> > >> little 
> > >> code). 
> > >> On top of that, brain has to read the word every time your eyes look 
> at 
> > >> it so you spend more time also reading the code - tho this should be 
> easy 
> > >> to omit, by highlighting this keyword by other color than other 
> keywords 
> > >> (the current purple color in ATOM just drives me crazy, since it is 
> one 
> > >> of 
> > >> the most violent colors, so my eyes always try to read that useless 
> piece 
> > >> of information first, instead of the important code). 
>
>

Re: [julia-users] Why does julia use END for block end?

[Adrian Salceanu]

That's a good point, with the parenthesis it does work as expected in case 
of an assignment, thanks! 

vineri, 6 mai 2016, 22:31:42 UTC+2, Yichao Yu a scris:
>
> On Fri, May 6, 2016 at 3:12 PM, Adrian Salceanu 
> <adrian@gmail.com > wrote: 
> > The only place where I find the "end" requirement annoying is for one 
> line 
> > IF statements. When you have a short one liner, the "end" part just does 
> not 
> > feel right. It would be nice if the "end" could be left out for one 
> liners. 
> > Even PHP allows one to skip the accolades in such cases. 
> > 
> > If there's some other way of achieving this I'd love to hear about it. I 
> > don't like the ternary operator in this situation cause it forces me to 
> add 
> > the 3rd part as "nothing" or whatever. And doing "expr1 && expr2" only 
> works 
> > when expr2 is "return" for instance, otherwise the compiler complains 
> about 
> > using a non-boolean in a boolean context. 
>
> It shouldn't. Unless you are using the result in a boolean context. 
> The only case where this doesn't work is assignment, where `a && b = 
> c` is parsed as `(a && b) = c` and not `a && (b = c)`. This can be 
> workaround by adding parenthesis as shown above and maybe we can also 
> change the parser too? 
>
> > 
> > 
> > vineri, 6 mai 2016, 20:37:49 UTC+2, Stefan Karpinski a scris: 
> >> 
> >> There is a long history of languages using this syntax, including 
> Algol, 
> >> Pascal, Ruby and Matlab. 
> >> 
> >> On Fri, May 6, 2016 at 2:26 PM, Ford Ox <ford...@gmail.com> wrote: 
> >>> 
> >>> Is there any reasoning behind it? It seems to me like a weird choice 
> >>> since you have to type three letters, which is the complete opposite 
> of the 
> >>> goal of this language - being very productive (a lot work done with 
> little 
> >>> code). 
> >>> On top of that, brain has to read the word every time your eyes look 
> at 
> >>> it so you spend more time also reading the code - tho this should be 
> easy to 
> >>> omit, by highlighting this keyword by other color than other keywords 
> (the 
> >>> current purple color in ATOM just drives me crazy, since it is one of 
> the 
> >>> most violent colors, so my eyes always try to read that useless piece 
> of 
> >>> information first, instead of the important code). 
> >> 
> >> 
> > 
>

Re: [julia-users] Why does julia use END for block end?

[Adrian Salceanu]

The only place where I find the "end" requirement annoying is for one line 
IF statements. When you have a short one liner, the "end" part just does 
not feel right. It would be nice if the "end" could be left out for one 
liners. Even PHP allows one to skip the accolades in such cases. 

If there's some other way of achieving this I'd love to hear about it. I 
don't like the ternary operator in this situation cause it forces me to add 
the 3rd part as "nothing" or whatever. And doing "expr1 && expr2" only 
works when expr2 is "return" for instance, otherwise the compiler complains 
about using a non-boolean in a boolean context. 


vineri, 6 mai 2016, 20:37:49 UTC+2, Stefan Karpinski a scris:
>
> There is a long history of languages using this syntax, including Algol, 
> Pascal, Ruby and Matlab.
>
> On Fri, May 6, 2016 at 2:26 PM, Ford Ox  
> wrote:
>
>> Is there any reasoning behind it? It seems to me like a weird choice 
>> since you have to type three letters, which is the complete opposite of the 
>> goal of this language - being very productive (a lot work done with little 
>> code).
>> On top of that, brain has to read the word every time your eyes look at 
>> it so you spend more time also reading the code - tho this should be easy 
>> to omit, by highlighting this keyword by other color than other keywords 
>> (the current purple color in ATOM just drives me crazy, since it is one of 
>> the most violent colors, so my eyes always try to read that useless piece 
>> of information first, instead of the important code).
>>
>
>

Re: [julia-users] programminjuliahelp

[Adrian Salceanu]

Sure, like the Error says, "UndefVarError: x not defined” 

Julia does not know what x and y are you talking about when you reference them 
in the if statement. 

You need to declare them and provide their values (or declare them and get the 
values later from somewhere, input or database): 

x = 1 
y = 2

if x < y
  println("x is less than y")
elseif x > y
  println("x is greater than y")
else
  for i in 1:x
    print(i, ", ")
  end
end

On April 1, 2016 at 16:51:52, Angeliki Avramidou (angeliki.avrami...@gmail.com) 
wrote:

Hi,
Im a student of the University of the Aegean, and i need your help with a 
project in Julia. I  
have done this programm so far, but something is missing in the
beginning and i dont what i have to do to run the programm. Do i
have to put numbers?


  
if x < y

 println("x is less than y")

elseif x > y

 println("x is greater than y")

else

for i in 1:x

   print(i, ", ")

end



end





Thank you

[julia-users] Re: Almost at 500 packages!

[Adrian Salceanu]

James, that's great. 

I'd say the most efficient way of doing this is if I finish the API and you 
do the REPL package for querying the API and displaying the results. We can 
discuss the data and the structure of the responses and I can provide you 
with mock responses, so you won't have to wait while I develop the API. 

We can catch up over email, I'll follow up with more details. 

miercuri, 30 martie 2016, 14:19:24 UTC+2, James Fairbanks a scris:
>
> I am interested in this project and have some time on my hands over the 
> next few weeks.
>
> On Wednesday, March 30, 2016 at 5:55:16 AM UTC-4, Adrian Salceanu wrote:
>>
>> I begun working on such a tool a few weeks ago. 
>>
>> A) It goes over the METADATA (https://github.com/JuliaLang/METADATA.jl) 
>> for all the registered packages and then B) uses the GitHub API to get the 
>> README and additional stats (contributions, stars, followers, etc). 
>> Planning on C) exposing this as a REST-ful API and D) building a package 
>> that can be used from the REPL to search for packages using the API. 
>>
>> A and B are done (though not entirely production ready yet) - C and D are 
>> yet to come. 
>>
>> I'm building this as an application of a bigger project I'm working on - 
>> a full stack web framework. This is going to take more time (I have the ORM 
>> at 90% with basic controllers support and routing and serving via Mux) but 
>> I can extract just the requirements for this and make it available in a few 
>> weeks. 
>>
>> If anybody wants to contribute with ideas or dev time, I'd be happy to 
>> set up a repo ASAP. 
>>
>>
>> marți, 20 ianuarie 2015, 16:32:45 UTC+1, Iain Dunning a scris:
>>>
>>> Just noticed on http://pkg.julialang.org/pulse.html that we are at 499 
>>> registered packages with at least one version tagged that are Julia 0.4-dev 
>>> compatible (493 on Julia 0.3).
>>>
>>> Thanks to all the package developers for their efforts in growing the 
>>> Julia package ecosystem!
>>>
>>>

[julia-users] Re: Almost at 500 packages!

[Adrian Salceanu]

I begun working on such a tool a few weeks ago. 

A) It goes over the METADATA (https://github.com/JuliaLang/METADATA.jl) for 
all the registered packages and then B) uses the GitHub API to get the 
README and additional stats (contributions, stars, followers, etc). 
Planning on C) exposing this as a REST-ful API and D) building a package 
that can be used from the REPL to search for packages using the API. 

A and B are done (though not entirely production ready yet) - C and D are 
yet to come. 

I'm building this as an application of a bigger project I'm working on - a 
full stack web framework. This is going to take more time (I have the ORM 
at 90% with basic controllers support and routing and serving via Mux) but 
I can extract just the requirements for this and make it available in a few 
weeks. 

If anybody wants to contribute with ideas or dev time, I'd be happy to set 
up a repo ASAP. 


marți, 20 ianuarie 2015, 16:32:45 UTC+1, Iain Dunning a scris:
>
> Just noticed on http://pkg.julialang.org/pulse.html that we are at 499 
> registered packages with at least one version tagged that are Julia 0.4-dev 
> compatible (493 on Julia 0.3).
>
> Thanks to all the package developers for their efforts in growing the 
> Julia package ecosystem!
>
>

[julia-users] Run julia with -L and pass args to the loaded file

[Adrian Salceanu]

Is it possible to use 
$> julia -L filename.jl --env=test
and pass the additional args to the script, rather than to julia? 

I tried using various combinations, with and without  --  but to no avail. 
-L seems to always gobble everything following it. 

$> julia -L filename.jl --env=test
ERROR: unknown option `--env=test`

$> julia -L filename.jl -- --env=test
ERROR: could not open file /Users/adrian/Dropbox/Projects/jinnie/--

Cheers! 

Re: [julia-users] Parametric types... types?!

[Adrian Salceanu]

sâmbătă, 5 martie 2016, 22:59:33 UTC+1, Milan Bouchet-Valat a scris:
>
> Le samedi 05 mars 2016 à 13:42 -0800, Adrian Salceanu a écrit : 
> > Gentleman, I stumbled onto this one in my code, and despite trying 
> > all the possible combinations I could think of, no dice.  
> > 
> > I have this simple type hierarchy:  
> > 
> > abstract Model 
> > type Package <: Model 
> > type Repo <: Model 
> > 
> > The Model type is an ORM and it defines a series of methods that 
> > operate on Model subtypes.  
> > 
> > ex:  
> > function save{T<:Model}(m::T) 
> Note that this can be written more simply as: 
> function save(m::Model) 
>

I noticed that this works too, but I find that the longer syntax better 
transmits the notion that the method expects a subtype, rather than the 
type itself. Of course, this is lees important in Julia, where the super 
type can only be abstract. 
 

>
> (the longer syntax is only useful when T is a parameter of another 
> argument type) 
>
> > So far so good.  
> > 
> > Now, according to ORM architecture and design patterns, an instance 
> > of a subtype represents a table row, while the class itself 
> > represents the table. And of course there are plenty of such 
> > methods.  
> > For instance, the find_one_by function, which takes the type itself 
> > (the table).  
> > 
> > function find_one_by(m, column_name::SQLColumn, value::SQLInput) # 
> > this works, with m::Any 
> > 
> > The question is, how can I define this method so that it accepts all 
> > the types of the subtypes of Model?  
> > 
> > I tried multiple combinations, such as:  
> > function find_one_by{T<:Type{Model}}(m::T, column_name::SQLColumn, 
> > value::SQLInput) 
> > 
> > none was good. :( Any ideas?  
> Use this: 
> find_one_by{T<:Model}(m::Type{T}, ... 
>
>
It works! Wow, awesome! Many thanks!
 

>
>
> Regards 
>

[julia-users] Parametric types... types?!

[Adrian Salceanu]

Gentleman, I stumbled onto this one in my code, and despite trying all the 
possible combinations I could think of, no dice. 

I have this simple type hierarchy: 

abstract Model
type Package <: Model
type Repo <: Model

The Model type is an ORM and it defines a series of methods that operate on 
Model subtypes. 

ex: 
function save{T<:Model}(m::T)

So far so good. 

Now, according to ORM architecture and design patterns, an instance of a 
subtype represents a table row, while the class itself represents the 
table. And of course there are plenty of such methods. 
For instance, the find_one_by function, which takes the type itself (the 
table). 

function find_one_by(m, column_name::SQLColumn, value::SQLInput) # this 
works, with m::Any

The question is, how can I define this method so that it accepts all the 
types of the subtypes of Model? 

I tried multiple combinations, such as: 
function find_one_by{T<:Type{Model}}(m::T, column_name::SQLColumn, 
value::SQLInput)

none was good. :( Any ideas? 

[julia-users] Re: Globally enable / disable @time execution

[Adrian Salceanu]

Thanks Lutfullah - I see, makes sense. It's the hygienic macros, right? 

Good idea, I'll experiment with macroexpand and the 2 versions of code ;) 


luni, 29 februarie 2016, 12:37:03 UTC+1, Lutfullah Tomak a scris:
>
> Hi Adrian, I think macros always evaluated in parse time. AFAICT, While a 
> macro parsed, unescaped names prepended with current namespace and macro 
> local names are regenerated with GenSym to avoid collusions with names in 
> current scope. I think esc() is for escaping this kind of modifications to 
> parsed code. I find macroexpand very useful to look at what a macro returns 
> and track what should be changed accordingly.

[julia-users] Re: Globally enable / disable @time execution

[Adrian Salceanu]

If I'm not too cheeky, can you please explain the solution? With 
Kristoffer's code I was running into an UndefVarError - which is something 
I usually run into with my macros too. 
In this scenario, the local variables from the scope where the macro was 
called are not available to the ??? (macro or expression inside the macro). 
Looking at the definition of "esc()" am I correct to assume that without 
it, the expression is eagerly evaluated in the wrong context / scope (maybe 
at compile time?). 

duminică, 28 februarie 2016, 16:31:31 UTC+1, Toivo Henningsson a scris:
>
> I think you want to change the first case to
>
> macro devtime(ex)
> quote
> @time $(esc(ex))
> end
> end
>
> right? 
>
>

[julia-users] Re: Globally enable / disable @time execution

[Adrian Salceanu]

Indeed, I was now trying to debug Kristoffer's solution myself, as using 
the macro was throwing an UndefVarError

This works perfectly, many thanks! 


duminică, 28 februarie 2016, 16:31:31 UTC+1, Toivo Henningsson a scris:
>
> I think you want to change the first case to
>
> macro devtime(ex)
> quote
> @time $(esc(ex))
> end
> end
>
> right? 
>
>

[julia-users] Re: Globally enable / disable @time execution

[Adrian Salceanu]

Perfect, thank you very much! 

duminică, 28 februarie 2016, 16:09:36 UTC+1, Kristoffer Carlsson a scris:
>
> Maybe something like:
>
> if DEV
> macro devtime(ex)
> @time ex
> end
> else
> macro devtime(ex)
> esc(ex)
> end
>
> end
>
> And then use @devtime instead of @time
>
> On Sunday, February 28, 2016 at 4:03:23 PM UTC+1, Adrian Salceanu wrote:
>>
>> I have an application that runs in 2 environments, DEV and PROD. While 
>> running in DEV I'd like to see @time information for different expressions. 
>> But not in PROD. Any ideas about how can this be done so that I don't end 
>> up littering my code with conditionals, such as: 
>>
>> if DEV 
>>   @time expr 
>> else 
>>   expr
>> end
>>
>> Thanks!
>>
>

[julia-users] Globally enable / disable @time execution

[Adrian Salceanu]

I have an application that runs in 2 environments, DEV and PROD. While 
running in DEV I'd like to see @time information for different expressions. 
But not in PROD. Any ideas about how can this be done so that I don't end 
up littering my code with conditionals, such as: 

if DEV 
  @time expr 
else 
  expr
end

Thanks!

[julia-users] Re: Polymorphic functions definition

[Adrian Salceanu]

Thanks, I managed to figure it out by re-re-re-reading the docs. I was 
suspecting that the answer will be about parametric types. 

function df_to_m{T<:Jinnie.Jinnie_Model}(df::DataFrames.DataFrame, m::T) # 
works!


sâmbătă, 27 februarie 2016, 09:31:23 UTC+1, Adrian Salceanu a scris:
>
> Hi, 
>
> I stumbled upon an issue in my code and I can't quite figure out the 
> behavior. Any hints would be much appreciated, thanks in advance. 
>
> So, I have a function: 
>
> function df_to_m(df::DataFrames.DataFrame, m::Jinnie_Model)
>
> It iterates over each row of the df DataFrame and instantiates the 
> corresponding m model type, returning an array of m model instances. 
>
> For example, say if I have this DataFrame (*df*)
>
> 1x3 DataFrames.DataFrame
> | Row | name| url   | updated_at   
> |
>
> |-|-|---|--|
> | 1   | "Bokeh" | "git://github.com/bokeh/Bokeh.jl.git" | "2016-02-10 
> 19:21:57.209996" |
>
> I would call 
>
> df_to_m(df, Jinnie.Package()) 
>
> and expect to get 
>
> 1-element Array{Any,1}:
>  Jinnie.Package("packages","name","Bokeh","git://
> github.com/bokeh/Bokeh.jl.git")
>
> where Jinnie_Model is an abstract type defined in the Jinnie module as
>
> abstract Jinnie_Model
>
> and Jinnie.Package extends Jinnie_Model
>
> type Package <: Jinnie_Model
>   _table_name::AbstractString
>   _id::AbstractString
>   name::AbstractString
>   url::AbstractString
>
>   Package(; name = "", url = "") = new("packages", "name", name, url)
> end
>
> However, the problem is that df_to_m does not want to accept subtypes of 
> Jinnie_Model: 
>
> ERROR: MethodError: `df_to_m` has no method matching 
> df_to_m(::DataFrames.DataFrame, ::Jinnie.Package)
> Closest candidates are:
>   df_to_m(::DataFrames.DataFrame, ::Jinnie.Jinnie_Model)
>
> If I drop the type constraint in the function's definition, it works 
> great, as expected: 
>
> function df_to_m(df::DataFrames.DataFrame, m) # this version works
>
> ==
>
> My questions are: 
>
> 1. how can I get the function to accept subtypes of Jinnie_Model while 
> keeping the type constraint? 
>
> 2. I don't like passing instances like Jinnie.Package() and I would 
> rather pass the type itself Jinnie.Package into the polymorphic function. 
> It's a crappy code smell so I must be doing something wrong. 
>
> I experimented with defining the function as 
>
> function df_to_m(df::DataFrames.DataFrame, m::Type{Jinnie.Jinnie_Model})
>
> but got the same error, polymorphism be damned. 
>
> ERROR: MethodError: `df_to_m` has no method matching 
> df_to_m(::DataFrames.DataFrame, ::Type{Jinnie.Package})
> Closest candidates are:
>   df_to_m(::DataFrames.DataFrame, ::Type{Jinnie.Jinnie_Model})
>
> How could the function be defined to work with the types itself (rather 
> than instances) and be polymorphic as intended? 
>
> Thanks for your time. 
>
> Cheers
>

[julia-users] Re: Polymorphic functions definition

[Adrian Salceanu]

Still not sure though how to go about using the actual types as params, 
rather than an instance of that type. 


sâmbătă, 27 februarie 2016, 14:56:47 UTC+1, Adrian Salceanu a scris:
>
> Thanks, I managed to figure it out by re-re-re-reading the docs. I was 
> suspecting that the answer will be about parametric types. 
>
> function df_to_m{T<:Jinnie.Jinnie_Model}(df::DataFrames.DataFrame, m::T) # 
> works!
>
> Is this the only way? I'm fine with it (it's very explicit upon reading) 
> but it's unexpected coming from OOP where you get polymorphism out of the 
> box (subtypes can be used instead of the parent type, without needing 
> anything else).
>
>
> sâmbătă, 27 februarie 2016, 09:31:23 UTC+1, Adrian Salceanu a scris:
>>
>> Hi, 
>>
>> I stumbled upon an issue in my code and I can't quite figure out the 
>> behavior. Any hints would be much appreciated, thanks in advance. 
>>
>> So, I have a function: 
>>
>> function df_to_m(df::DataFrames.DataFrame, m::Jinnie_Model)
>>
>> It iterates over each row of the df DataFrame and instantiates the 
>> corresponding m model type, returning an array of m model instances. 
>>
>> For example, say if I have this DataFrame (*df*)
>>
>> 1x3 DataFrames.DataFrame
>> | Row | name| url   | updated_at 
>>   |
>>
>> |-|-|---|--|
>> | 1   | "Bokeh" | "git://github.com/bokeh/Bokeh.jl.git" | "2016-02-10 
>> 19:21:57.209996" |
>>
>> I would call 
>>
>> df_to_m(df, Jinnie.Package()) 
>>
>> and expect to get 
>>
>> 1-element Array{Any,1}:
>>  Jinnie.Package("packages","name","Bokeh","git://
>> github.com/bokeh/Bokeh.jl.git")
>>
>> where Jinnie_Model is an abstract type defined in the Jinnie module as
>>
>> abstract Jinnie_Model
>>
>> and Jinnie.Package extends Jinnie_Model
>>
>> type Package <: Jinnie_Model
>>   _table_name::AbstractString
>>   _id::AbstractString
>>   name::AbstractString
>>   url::AbstractString
>>
>>   Package(; name = "", url = "") = new("packages", "name", name, url)
>> end
>>
>> However, the problem is that df_to_m does not want to accept subtypes of 
>> Jinnie_Model: 
>>
>> ERROR: MethodError: `df_to_m` has no method matching 
>> df_to_m(::DataFrames.DataFrame, ::Jinnie.Package)
>> Closest candidates are:
>>   df_to_m(::DataFrames.DataFrame, ::Jinnie.Jinnie_Model)
>>
>> If I drop the type constraint in the function's definition, it works 
>> great, as expected: 
>>
>> function df_to_m(df::DataFrames.DataFrame, m) # this version works
>>
>> ==
>>
>> My questions are: 
>>
>> 1. how can I get the function to accept subtypes of Jinnie_Model while 
>> keeping the type constraint? 
>>
>> 2. I don't like passing instances like Jinnie.Package() and I would 
>> rather pass the type itself Jinnie.Package into the polymorphic 
>> function. It's a crappy code smell so I must be doing something wrong. 
>>
>> I experimented with defining the function as 
>>
>> function df_to_m(df::DataFrames.DataFrame, m::Type{Jinnie.Jinnie_Model})
>>
>> but got the same error, polymorphism be damned. 
>>
>> ERROR: MethodError: `df_to_m` has no method matching 
>> df_to_m(::DataFrames.DataFrame, ::Type{Jinnie.Package})
>> Closest candidates are:
>>   df_to_m(::DataFrames.DataFrame, ::Type{Jinnie.Jinnie_Model})
>>
>> How could the function be defined to work with the types itself (rather 
>> than instances) and be polymorphic as intended? 
>>
>> Thanks for your time. 
>>
>> Cheers
>>
>

[julia-users] Re: Polymorphic functions definition

[Adrian Salceanu]

Thanks, I managed to figure it out by re-re-re-reading the docs. I was 
suspecting that the answer will be about parametric types. 

function df_to_m{T<:Jinnie.Jinnie_Model}(df::DataFrames.DataFrame, m::T) # 
works!

Is this the only way? I'm fine with it (it's very explicit upon reading) 
but it's unexpected coming from OOP where you get polymorphism out of the 
box (subtypes can be used instead of the parent type, without needing 
anything else).


sâmbătă, 27 februarie 2016, 09:31:23 UTC+1, Adrian Salceanu a scris:
>
> Hi, 
>
> I stumbled upon an issue in my code and I can't quite figure out the 
> behavior. Any hints would be much appreciated, thanks in advance. 
>
> So, I have a function: 
>
> function df_to_m(df::DataFrames.DataFrame, m::Jinnie_Model)
>
> It iterates over each row of the df DataFrame and instantiates the 
> corresponding m model type, returning an array of m model instances. 
>
> For example, say if I have this DataFrame (*df*)
>
> 1x3 DataFrames.DataFrame
> | Row | name| url   | updated_at   
> |
>
> |-|-|---|--|
> | 1   | "Bokeh" | "git://github.com/bokeh/Bokeh.jl.git" | "2016-02-10 
> 19:21:57.209996" |
>
> I would call 
>
> df_to_m(df, Jinnie.Package()) 
>
> and expect to get 
>
> 1-element Array{Any,1}:
>  Jinnie.Package("packages","name","Bokeh","git://
> github.com/bokeh/Bokeh.jl.git")
>
> where Jinnie_Model is an abstract type defined in the Jinnie module as
>
> abstract Jinnie_Model
>
> and Jinnie.Package extends Jinnie_Model
>
> type Package <: Jinnie_Model
>   _table_name::AbstractString
>   _id::AbstractString
>   name::AbstractString
>   url::AbstractString
>
>   Package(; name = "", url = "") = new("packages", "name", name, url)
> end
>
> However, the problem is that df_to_m does not want to accept subtypes of 
> Jinnie_Model: 
>
> ERROR: MethodError: `df_to_m` has no method matching 
> df_to_m(::DataFrames.DataFrame, ::Jinnie.Package)
> Closest candidates are:
>   df_to_m(::DataFrames.DataFrame, ::Jinnie.Jinnie_Model)
>
> If I drop the type constraint in the function's definition, it works 
> great, as expected: 
>
> function df_to_m(df::DataFrames.DataFrame, m) # this version works
>
> ==
>
> My questions are: 
>
> 1. how can I get the function to accept subtypes of Jinnie_Model while 
> keeping the type constraint? 
>
> 2. I don't like passing instances like Jinnie.Package() and I would 
> rather pass the type itself Jinnie.Package into the polymorphic function. 
> It's a crappy code smell so I must be doing something wrong. 
>
> I experimented with defining the function as 
>
> function df_to_m(df::DataFrames.DataFrame, m::Type{Jinnie.Jinnie_Model})
>
> but got the same error, polymorphism be damned. 
>
> ERROR: MethodError: `df_to_m` has no method matching 
> df_to_m(::DataFrames.DataFrame, ::Type{Jinnie.Package})
> Closest candidates are:
>   df_to_m(::DataFrames.DataFrame, ::Type{Jinnie.Jinnie_Model})
>
> How could the function be defined to work with the types itself (rather 
> than instances) and be polymorphic as intended? 
>
> Thanks for your time. 
>
> Cheers
>

[julia-users] Polymorphic functions definition

[Adrian Salceanu]

Hi, 

I stumbled upon an issue in my code and I can't quite figure out the 
behavior. Any hints would be much appreciated, thanks in advance. 

So, I have a function: 

function df_to_m(df::DataFrames.DataFrame, m::Jinnie_Model)

It iterates over each row of the df DataFrame and instantiates the 
corresponding m model type, returning an array of m model instances. 

For example, say if I have this DataFrame (*df*)

1x3 DataFrames.DataFrame
| Row | name| url   | updated_at   
|
|-|-|---|--|
| 1   | "Bokeh" | "git://github.com/bokeh/Bokeh.jl.git" | "2016-02-10 
19:21:57.209996" |

I would call 

df_to_m(df, Jinnie.Package()) 

and expect to get 

1-element Array{Any,1}:
 Jinnie.Package("packages","name","Bokeh","git://github.com/bokeh/Bokeh.jl.git")

where Jinnie_Model is an abstract type defined in the Jinnie module as

abstract Jinnie_Model

and Jinnie.Package extends Jinnie_Model

type Package <: Jinnie_Model
  _table_name::AbstractString
  _id::AbstractString
  name::AbstractString
  url::AbstractString

  Package(; name = "", url = "") = new("packages", "name", name, url)
end

However, the problem is that df_to_m does not want to accept subtypes of 
Jinnie_Model: 

ERROR: MethodError: `df_to_m` has no method matching 
df_to_m(::DataFrames.DataFrame, ::Jinnie.Package)
Closest candidates are:
  df_to_m(::DataFrames.DataFrame, ::Jinnie.Jinnie_Model)

If I drop the type constraint in the function's definition, it works great, 
as expected: 

function df_to_m(df::DataFrames.DataFrame, m) # this version works

==

My questions are: 

1. how can I get the function to accept subtypes of Jinnie_Model while 
keeping the type constraint? 

2. I don't like passing instances like Jinnie.Package() and I would rather 
pass the type itself Jinnie.Package into the polymorphic function. It's a 
crappy code smell so I must be doing something wrong. 

I experimented with defining the function as 

function df_to_m(df::DataFrames.DataFrame, m::Type{Jinnie.Jinnie_Model})

but got the same error, polymorphism be damned. 

ERROR: MethodError: `df_to_m` has no method matching 
df_to_m(::DataFrames.DataFrame, ::Type{Jinnie.Package})
Closest candidates are:
  df_to_m(::DataFrames.DataFrame, ::Type{Jinnie.Jinnie_Model})

How could the function be defined to work with the types itself (rather 
than instances) and be polymorphic as intended? 

Thanks for your time. 

Cheers

Re: [julia-users] Re: How to run a detached command and return execution to the parent script?

[Adrian Salceanu]

Cheers! 

sâmbătă, 23 ianuarie 2016, 19:01:24 UTC+1, Stefan Karpinski a scris:
>
> Great! I'm glad you got it sorted out.
>
> On Fri, Jan 22, 2016 at 6:24 PM, Adrian Salceanu <adrian@gmail.com 
> > wrote:
>
>> No no, It's perfectly fine, it was my fault. What I haven't realized is 
>> that if I start the server async then my script will finish immediately, 
>> which also terminated the server. It was my responsibility to keep the 
>> whole app alive now. 
>>
>> It works like a charm! 
>>
>>
>> sâmbătă, 23 ianuarie 2016, 00:06:13 UTC+1, Stefan Karpinski a scris:
>>>
>>> The shell works with processes, Julia has tasks where are not the same 
>>> thing...
>>>
>>> On Fri, Jan 22, 2016 at 5:49 PM, Adrian Salceanu <adrian@gmail.com> 
>>> wrote:
>>>
>>>> The problem seems to that HttpServer can not run @async - it exits 
>>>> immediately. 
>>>>
>>>> ===
>>>>
>>>> using HttpServer
>>>>
>>>> http = HttpHandler() do req::Request, res::Response
>>>> Response( ismatch(r"^/hello/", req.resource) ? exit(2) : 404 )
>>>> end
>>>>
>>>> server = Server( http )
>>>> run( server, 8001 )  # <--- this works but blocks
>>>> @async run( server, 8001 ) # <--- this exits immediately
>>>>
>>>> ===
>>>>
>>>> It's not necessarily a problem that HttpServer blocks. But what drives 
>>>> me nuts is: if I run 
>>>> $ julia app.jl & 
>>>> in the shell, it works perfectly. The process is placed in the 
>>>> background, the server happily listens to the assigned port, etc. 
>>>>
>>>> Why can't I run the same command from within another julia process and 
>>>> get the same effect? 
>>>>
>>>>
>>>> vineri, 22 ianuarie 2016, 22:40:56 UTC+1, Stefan Karpinski a scris:
>>>>>
>>>>> @spawn runs a command on a (random) worker process. If you want to do 
>>>>> "background" work in the current process, you can use @async:
>>>>>
>>>>> julia> t = @async (sleep(5); rand())
>>>>> Task (runnable) @0x000112d746a0
>>>>>
>>>>> julia> wait(t)
>>>>> 0.14543742643271207
>>>>>
>>>>>
>>>>> On Fri, Jan 22, 2016 at 4:33 PM, Adrian Salceanu <adrian@gmail.com
>>>>> > wrote:
>>>>>
>>>>>> Oh! The ruby analogy made me think about actually spawning the 
>>>>>> detached command! Which produced the desired effect! 
>>>>>>
>>>>>> julia> @spawn run(detach(`ping www.google.com`))
>>>>>>
>>>>>>
>>>>>>
>>>>>> vineri, 22 ianuarie 2016, 22:29:27 UTC+1, Adrian Salceanu a scris:
>>>>>>>
>>>>>>> I guess what I'm looking for is the equivalent of Ruby's 
>>>>>>> Process#spawn
>>>>>>>
>>>>>>> In REPL: 
>>>>>>>
>>>>>>> >> pid = Process.spawn("ping www.google.com", :out => '/dev/null')
>>>>>>> 83210
>>>>>>> >> <-- the process is running in the 
>>>>>>> background and control has been returned to the REPL
>>>>>>>
>>>>>>>
>>>>>>> vineri, 22 ianuarie 2016, 22:06:01 UTC+1, Adrian Salceanu a scris:
>>>>>>>>
>>>>>>>> Hi, 
>>>>>>>>
>>>>>>>> I'm hammering at a web app and I'm trying to setup functionality to 
>>>>>>>> monitor the file system for changes and restart/reload the server 
>>>>>>>> automatically so the changes are picked up (I'm using Mux which uses 
>>>>>>>> HttpServer). 
>>>>>>>>
>>>>>>>> The approach I have in mind is: 
>>>>>>>>
>>>>>>>> 1. have a startup script which is run from the command line, 
>>>>>>>> something like: 
>>>>>>>> $ julia -L startup.jl
>>>>>>>>
>>>>>>>> 2. the startup script launches the web app, which starts the web 
>>>>>>>> server. My intention was to run 
>>>>>>&g

[julia-users] Re: How to run a detached command and return execution to the parent script?

[Adrian Salceanu]

I guess what I'm looking for is the equivalent of Ruby's Process#spawn

In REPL: 

>> pid = Process.spawn("ping www.google.com", :out => '/dev/null')
83210
>> <-- the process is running in the background and 
control has been returned to the REPL


vineri, 22 ianuarie 2016, 22:06:01 UTC+1, Adrian Salceanu a scris:
>
> Hi, 
>
> I'm hammering at a web app and I'm trying to setup functionality to 
> monitor the file system for changes and restart/reload the server 
> automatically so the changes are picked up (I'm using Mux which uses 
> HttpServer). 
>
> The approach I have in mind is: 
>
> 1. have a startup script which is run from the command line, something 
> like: 
> $ julia -L startup.jl
>
> 2. the startup script launches the web app, which starts the web server. 
> My intention was to run 
> $ julia -L app.jl 
> as a command inside startup.jl, detached, and have the startup.jl script 
> get back control, with app.jl running detached in the background. 
>
> 3. once startup.jl gets back control, it begins monitoring the file system 
> and when changes are detected, kills the app and relaunches it. 
>
> That was the theory. Now, I might be missing something but I can't find a 
> way to detach the command I'm running and get control back to the startup 
> script. And I tried a lot of things! 
>
> ===
>
> I'm providing simpler example using "ping", which also run indefinitely, 
> similar to the web server. 
>
> julia> run(detach(`ping "www.google.com"`)) # the command is detached and 
> continues to run after the julia REPL is closed, but at this point the REPL 
> does not get control, there's no cursor available in the REPL
> PING www.google.com (173.194.45.82): 56 data bytes
> 64 bytes from 173.194.45.82: icmp_seq=0 ttl=54 time=30.138 ms
> 64 bytes from 173.194.45.82: icmp_seq=1 ttl=54 time=30.417 ms
> ... more output ...
> 64 bytes from 173.194.45.82: icmp_seq=7 ttl=54 time=30.486 ms
> 64 bytes from 173.194.45.82: icmp_seq=8 ttl=54 time=30.173 ms
> ^CERROR: InterruptException:   
>   < here I press Ctrl+C and only now the REPL gets back 
> the cursor, with the command still running in the background
>
> ===
>
> Also, related to this, passing "&" into the command to detach does not 
> work as expected, the "&" is interpreted as argument of the command. Not 
> sure if this would help anyway to return control to the startup.jl script? 
>
> julia> run(detach(`ping "www.google.com" &`));
> usage: ping [-AaDdfnoQqRrv] [-b boundif] [-c count] [-G sweepmaxsize]
> [-g sweepminsize] [-h sweepincrsize] [-i wait] [−k 
> trafficclass]
> [-l preload] [-M mask | time] [-m ttl] [-p pattern]
> [-S src_addr] [-s packetsize] [-t timeout][-W waittime] [-z 
> tos]
> host
>ping [-AaDdfLnoQqRrv] [-b boundif] [-c count] [-I iface] [-i wait]
> [−k trafficclass] [-l preload] [-M mask | time] [-m ttl] [-p 
> pattern] [-S src_addr]
> [-s packetsize] [-T ttl] [-t timeout] [-W waittime]
> [-z tos] mcast-group
> ERROR: failed process: Process(`ping www.google.com &`, 
> ProcessExited(64)) [64]
>  in run at /usr/local/Cellar/julia/0.4.2/lib/julia/sys.dylib
>
> ===
>
> Thanks
>

[julia-users] How to run a detached command and return execution to the parent script?

[Adrian Salceanu]

Hi, 

I'm hammering at a web app and I'm trying to setup functionality to monitor 
the file system for changes and restart/reload the server automatically so 
the changes are picked up (I'm using Mux which uses HttpServer). 

The approach I have in mind is: 

1. have a startup script which is run from the command line, something 
like: 
$ julia -L startup.jl

2. the startup script launches the web app, which starts the web server. My 
intention was to run 
$ julia -L app.jl 
as a command inside startup.jl, detached, and have the startup.jl script 
get back control, with app.jl running detached in the background. 

3. once startup.jl gets back control, it begins monitoring the file system 
and when changes are detected, kills the app and relaunches it. 

That was the theory. Now, I might be missing something but I can't find a 
way to detach the command I'm running and get control back to the startup 
script. And I tried a lot of things! 

===

I'm providing simpler example using "ping", which also run indefinitely, 
similar to the web server. 

julia> run(detach(`ping "www.google.com"`)) # the command is detached and 
continues to run after the julia REPL is closed, but at this point the REPL 
does not get control, there's no cursor available in the REPL
PING www.google.com (173.194.45.82): 56 data bytes
64 bytes from 173.194.45.82: icmp_seq=0 ttl=54 time=30.138 ms
64 bytes from 173.194.45.82: icmp_seq=1 ttl=54 time=30.417 ms
... more output ...
64 bytes from 173.194.45.82: icmp_seq=7 ttl=54 time=30.486 ms
64 bytes from 173.194.45.82: icmp_seq=8 ttl=54 time=30.173 ms
^CERROR: InterruptException:   
  < here I press Ctrl+C and only now the REPL gets back 
the cursor, with the command still running in the background

===

Also, related to this, passing "&" into the command to detach does not work 
as expected, the "&" is interpreted as argument of the command. Not sure if 
this would help anyway to return control to the startup.jl script? 

julia> run(detach(`ping "www.google.com" &`));
usage: ping [-AaDdfnoQqRrv] [-b boundif] [-c count] [-G sweepmaxsize]
[-g sweepminsize] [-h sweepincrsize] [-i wait] [−k trafficclass]
[-l preload] [-M mask | time] [-m ttl] [-p pattern]
[-S src_addr] [-s packetsize] [-t timeout][-W waittime] [-z tos]
host
   ping [-AaDdfLnoQqRrv] [-b boundif] [-c count] [-I iface] [-i wait]
[−k trafficclass] [-l preload] [-M mask | time] [-m ttl] [-p 
pattern] [-S src_addr]
[-s packetsize] [-T ttl] [-t timeout] [-W waittime]
[-z tos] mcast-group
ERROR: failed process: Process(`ping www.google.com &`, ProcessExited(64)) 
[64]
 in run at /usr/local/Cellar/julia/0.4.2/lib/julia/sys.dylib

===

Thanks

[julia-users] Re: How to run a detached command and return execution to the parent script?

[Adrian Salceanu]

Oh! The ruby analogy made me think about actually spawning the detached 
command! Which produced the desired effect! 

julia> @spawn run(detach(`ping www.google.com`))



vineri, 22 ianuarie 2016, 22:29:27 UTC+1, Adrian Salceanu a scris:
>
> I guess what I'm looking for is the equivalent of Ruby's Process#spawn
>
> In REPL: 
>
> >> pid = Process.spawn("ping www.google.com", :out => '/dev/null')
> 83210
> >> <-- the process is running in the background 
> and control has been returned to the REPL
>
>
> vineri, 22 ianuarie 2016, 22:06:01 UTC+1, Adrian Salceanu a scris:
>>
>> Hi, 
>>
>> I'm hammering at a web app and I'm trying to setup functionality to 
>> monitor the file system for changes and restart/reload the server 
>> automatically so the changes are picked up (I'm using Mux which uses 
>> HttpServer). 
>>
>> The approach I have in mind is: 
>>
>> 1. have a startup script which is run from the command line, something 
>> like: 
>> $ julia -L startup.jl
>>
>> 2. the startup script launches the web app, which starts the web server. 
>> My intention was to run 
>> $ julia -L app.jl 
>> as a command inside startup.jl, detached, and have the startup.jl script 
>> get back control, with app.jl running detached in the background. 
>>
>> 3. once startup.jl gets back control, it begins monitoring the file 
>> system and when changes are detected, kills the app and relaunches it. 
>>
>> That was the theory. Now, I might be missing something but I can't find a 
>> way to detach the command I'm running and get control back to the startup 
>> script. And I tried a lot of things! 
>>
>> ===
>>
>> I'm providing simpler example using "ping", which also run indefinitely, 
>> similar to the web server. 
>>
>> julia> run(detach(`ping "www.google.com"`)) # the command is detached 
>> and continues to run after the julia REPL is closed, but at this point the 
>> REPL does not get control, there's no cursor available in the REPL
>> PING www.google.com (173.194.45.82): 56 data bytes
>> 64 bytes from 173.194.45.82: icmp_seq=0 ttl=54 time=30.138 ms
>> 64 bytes from 173.194.45.82: icmp_seq=1 ttl=54 time=30.417 ms
>> ... more output ...
>> 64 bytes from 173.194.45.82: icmp_seq=7 ttl=54 time=30.486 ms
>> 64 bytes from 173.194.45.82: icmp_seq=8 ttl=54 time=30.173 ms
>> ^CERROR: InterruptException: 
>> < here I press Ctrl+C and only now the REPL gets 
>> back the cursor, with the command still running in the background
>>
>> ===
>>
>> Also, related to this, passing "&" into the command to detach does not 
>> work as expected, the "&" is interpreted as argument of the command. Not 
>> sure if this would help anyway to return control to the startup.jl script? 
>>
>> julia> run(detach(`ping "www.google.com" &`));
>> usage: ping [-AaDdfnoQqRrv] [-b boundif] [-c count] [-G sweepmaxsize]
>> [-g sweepminsize] [-h sweepincrsize] [-i wait] [−k 
>> trafficclass]
>> [-l preload] [-M mask | time] [-m ttl] [-p pattern]
>> [-S src_addr] [-s packetsize] [-t timeout][-W waittime] [-z 
>> tos]
>> host
>>ping [-AaDdfLnoQqRrv] [-b boundif] [-c count] [-I iface] [-i wait]
>> [−k trafficclass] [-l preload] [-M mask | time] [-m ttl] [-p 
>> pattern] [-S src_addr]
>> [-s packetsize] [-T ttl] [-t timeout] [-W waittime]
>> [-z tos] mcast-group
>> ERROR: failed process: Process(`ping www.google.com &`, 
>> ProcessExited(64)) [64]
>>  in run at /usr/local/Cellar/julia/0.4.2/lib/julia/sys.dylib
>>
>> ===
>>
>> Thanks
>>
>

Re: [julia-users] Re: How to run a detached command and return execution to the parent script?

[Adrian Salceanu]

Thanks

Per my previous comment, unfortunately @async / @spawn cause the app / 
server to exit immediately. 

Let me give @persist a try. 

Cheers! 

vineri, 22 ianuarie 2016, 22:45:10 UTC+1, Erik Schnetter a scris:
>
> If you want to be able to terminate your local Julia process, and have 
> the server continue to run in the background, then you might want to 
> check out <https://github.com/eschnett/Persist.jl>. This does the 
> equivalent of run/detach, but in such a way that the detached process 
> runs as daemon. 
>
> Otherwise, if you don't need this functionality, then @async is the way to 
> go. 
>
> -erik 
>
> On Fri, Jan 22, 2016 at 4:40 PM, Stefan Karpinski <ste...@karpinski.org 
> > wrote: 
> > @spawn runs a command on a (random) worker process. If you want to do 
> > "background" work in the current process, you can use @async: 
> > 
> > julia> t = @async (sleep(5); rand()) 
> > Task (runnable) @0x000112d746a0 
> > 
> > julia> wait(t) 
> > 0.14543742643271207 
> > 
> > 
> > On Fri, Jan 22, 2016 at 4:33 PM, Adrian Salceanu <adrian@gmail.com 
> > 
> > wrote: 
> >> 
> >> Oh! The ruby analogy made me think about actually spawning the detached 
> >> command! Which produced the desired effect! 
> >> 
> >> julia> @spawn run(detach(`ping www.google.com`)) 
> >> 
> >> 
> >> 
> >> vineri, 22 ianuarie 2016, 22:29:27 UTC+1, Adrian Salceanu a scris: 
> >>> 
> >>> I guess what I'm looking for is the equivalent of Ruby's Process#spawn 
> >>> 
> >>> In REPL: 
> >>> 
> >>> >> pid = Process.spawn("ping www.google.com", :out => '/dev/null') 
> >>> 83210 
> >>> >> <-- the process is running in the 
> background 
> >>> >> and control has been returned to the REPL 
> >>> 
> >>> 
> >>> vineri, 22 ianuarie 2016, 22:06:01 UTC+1, Adrian Salceanu a scris: 
> >>>> 
> >>>> Hi, 
> >>>> 
> >>>> I'm hammering at a web app and I'm trying to setup functionality to 
> >>>> monitor the file system for changes and restart/reload the server 
> >>>> automatically so the changes are picked up (I'm using Mux which uses 
> >>>> HttpServer). 
> >>>> 
> >>>> The approach I have in mind is: 
> >>>> 
> >>>> 1. have a startup script which is run from the command line, 
> something 
> >>>> like: 
> >>>> $ julia -L startup.jl 
> >>>> 
> >>>> 2. the startup script launches the web app, which starts the web 
> server. 
> >>>> My intention was to run 
> >>>> $ julia -L app.jl 
> >>>> as a command inside startup.jl, detached, and have the startup.jl 
> script 
> >>>> get back control, with app.jl running detached in the background. 
> >>>> 
> >>>> 3. once startup.jl gets back control, it begins monitoring the file 
> >>>> system and when changes are detected, kills the app and relaunches 
> it. 
> >>>> 
> >>>> That was the theory. Now, I might be missing something but I can't 
> find 
> >>>> a way to detach the command I'm running and get control back to the 
> startup 
> >>>> script. And I tried a lot of things! 
> >>>> 
> >>>> === 
> >>>> 
> >>>> I'm providing simpler example using "ping", which also run 
> indefinitely, 
> >>>> similar to the web server. 
> >>>> 
> >>>> julia> run(detach(`ping "www.google.com"`)) # the command is 
> detached 
> >>>> and continues to run after the julia REPL is closed, but at this 
> point the 
> >>>> REPL does not get control, there's no cursor available in the REPL 
> >>>> PING www.google.com (173.194.45.82): 56 data bytes 
> >>>> 64 bytes from 173.194.45.82: icmp_seq=0 ttl=54 time=30.138 ms 
> >>>> 64 bytes from 173.194.45.82: icmp_seq=1 ttl=54 time=30.417 ms 
> >>>> ... more output ... 
> >>>> 64 bytes from 173.194.45.82: icmp_seq=7 ttl=54 time=30.486 ms 
> >>>> 64 bytes from 173.194.45.82: icmp_seq=8 ttl=54 time=30.173 ms 
> >>>> ^CERROR: InterruptException: 
> >>>> < here I press Ctrl+C and only now the REPL gets back the cursor, 
> with 
> >>>&

Re: [julia-users] Re: How to run a detached command and return execution to the parent script?

[Adrian Salceanu]

The problem seems to that HttpServer can not run @async - it exits 
immediately. 

===

using HttpServer

http = HttpHandler() do req::Request, res::Response
Response( ismatch(r"^/hello/", req.resource) ? exit(2) : 404 )
end

server = Server( http )
run( server, 8001 )  # <--- this works but blocks
@async run( server, 8001 ) # <--- this exits immediately

===

It's not necessarily a problem that HttpServer blocks. But what drives me 
nuts is: if I run 
$ julia app.jl & 
in the shell, it works perfectly. The process is placed in the background, 
the server happily listens to the assigned port, etc. 

Why can't I run the same command from within another julia process and get 
the same effect? 


vineri, 22 ianuarie 2016, 22:40:56 UTC+1, Stefan Karpinski a scris:
>
> @spawn runs a command on a (random) worker process. If you want to do 
> "background" work in the current process, you can use @async:
>
> julia> t = @async (sleep(5); rand())
> Task (runnable) @0x000112d746a0
>
> julia> wait(t)
> 0.14543742643271207
>
>
> On Fri, Jan 22, 2016 at 4:33 PM, Adrian Salceanu <adrian@gmail.com 
> > wrote:
>
>> Oh! The ruby analogy made me think about actually spawning the detached 
>> command! Which produced the desired effect! 
>>
>> julia> @spawn run(detach(`ping www.google.com`))
>>
>>
>>
>> vineri, 22 ianuarie 2016, 22:29:27 UTC+1, Adrian Salceanu a scris:
>>>
>>> I guess what I'm looking for is the equivalent of Ruby's Process#spawn
>>>
>>> In REPL: 
>>>
>>> >> pid = Process.spawn("ping www.google.com", :out => '/dev/null')
>>> 83210
>>> >> <-- the process is running in the background 
>>> and control has been returned to the REPL
>>>
>>>
>>> vineri, 22 ianuarie 2016, 22:06:01 UTC+1, Adrian Salceanu a scris:
>>>>
>>>> Hi, 
>>>>
>>>> I'm hammering at a web app and I'm trying to setup functionality to 
>>>> monitor the file system for changes and restart/reload the server 
>>>> automatically so the changes are picked up (I'm using Mux which uses 
>>>> HttpServer). 
>>>>
>>>> The approach I have in mind is: 
>>>>
>>>> 1. have a startup script which is run from the command line, something 
>>>> like: 
>>>> $ julia -L startup.jl
>>>>
>>>> 2. the startup script launches the web app, which starts the web 
>>>> server. My intention was to run 
>>>> $ julia -L app.jl 
>>>> as a command inside startup.jl, detached, and have the startup.jl 
>>>> script get back control, with app.jl running detached in the background. 
>>>>
>>>> 3. once startup.jl gets back control, it begins monitoring the file 
>>>> system and when changes are detected, kills the app and relaunches it. 
>>>>
>>>> That was the theory. Now, I might be missing something but I can't find 
>>>> a way to detach the command I'm running and get control back to the 
>>>> startup 
>>>> script. And I tried a lot of things! 
>>>>
>>>> ===
>>>>
>>>> I'm providing simpler example using "ping", which also run 
>>>> indefinitely, similar to the web server. 
>>>>
>>>> julia> run(detach(`ping "www.google.com"`)) # the command is detached 
>>>> and continues to run after the julia REPL is closed, but at this point the 
>>>> REPL does not get control, there's no cursor available in the REPL
>>>> PING www.google.com (173.194.45.82): 56 data bytes
>>>> 64 bytes from 173.194.45.82: icmp_seq=0 ttl=54 time=30.138 ms
>>>> 64 bytes from 173.194.45.82: icmp_seq=1 ttl=54 time=30.417 ms
>>>> ... more output ...
>>>> 64 bytes from 173.194.45.82: icmp_seq=7 ttl=54 time=30.486 ms
>>>> 64 bytes from 173.194.45.82: icmp_seq=8 ttl=54 time=30.173 ms
>>>> ^CERROR: InterruptException:   
>>>>   < here I press Ctrl+C and only now the REPL gets 
>>>> back the cursor, with the command still running in the background
>>>>
>>>> ===
>>>>
>>>> Also, related to this, passing "&" into the command to detach does not 
>>>> work as expected, the "&" is interpreted as argument of the command. Not 
>>>> sure if this would help anyway to return control to the startup.jl script? 
>>>>
>>>> julia> run(detach(`ping "www.google.com" &`));
>>>> usage: ping [-AaDdfnoQqRrv] [-b boundif] [-c count] [-G sweepmaxsize]
>>>> [-g sweepminsize] [-h sweepincrsize] [-i wait] [−k 
>>>> trafficclass]
>>>> [-l preload] [-M mask | time] [-m ttl] [-p pattern]
>>>> [-S src_addr] [-s packetsize] [-t timeout][-W waittime] [-z 
>>>> tos]
>>>> host
>>>>ping [-AaDdfLnoQqRrv] [-b boundif] [-c count] [-I iface] [-i 
>>>> wait]
>>>> [−k trafficclass] [-l preload] [-M mask | time] [-m ttl] 
>>>> [-p pattern] [-S src_addr]
>>>> [-s packetsize] [-T ttl] [-t timeout] [-W waittime]
>>>> [-z tos] mcast-group
>>>> ERROR: failed process: Process(`ping www.google.com &`, 
>>>> ProcessExited(64)) [64]
>>>>  in run at /usr/local/Cellar/julia/0.4.2/lib/julia/sys.dylib
>>>>
>>>> ===
>>>>
>>>> Thanks
>>>>
>>>
>

Re: [julia-users] Re: How to run a detached command and return execution to the parent script?

[Adrian Salceanu]

Oh, @async has worked actually! 

It correctly run the command, but the startup script itself was finishing 
and exiting immediately after. 

Thank you very much Stefan and Erik! 


vineri, 22 ianuarie 2016, 23:26:23 UTC+1, Adrian Salceanu a scris:
>
> Thanks! 
>
> @async works perfectly with your example. And also works great with 
> running the "ping" command. The problem is web app / Mux / HttpServer exit 
> immediately if run @async. Same with @spawn, the app exits immediately. 
>
>
> vineri, 22 ianuarie 2016, 22:40:56 UTC+1, Stefan Karpinski a scris:
>>
>> @spawn runs a command on a (random) worker process. If you want to do 
>> "background" work in the current process, you can use @async:
>>
>> julia> t = @async (sleep(5); rand())
>> Task (runnable) @0x000112d746a0
>>
>> julia> wait(t)
>> 0.14543742643271207
>>
>>
>> On Fri, Jan 22, 2016 at 4:33 PM, Adrian Salceanu <adrian@gmail.com> 
>> wrote:
>>
>>> Oh! The ruby analogy made me think about actually spawning the detached 
>>> command! Which produced the desired effect! 
>>>
>>> julia> @spawn run(detach(`ping www.google.com`))
>>>
>>>
>>>
>>> vineri, 22 ianuarie 2016, 22:29:27 UTC+1, Adrian Salceanu a scris:
>>>>
>>>> I guess what I'm looking for is the equivalent of Ruby's Process#spawn
>>>>
>>>> In REPL: 
>>>>
>>>> >> pid = Process.spawn("ping www.google.com", :out => '/dev/null')
>>>> 83210
>>>> >> <-- the process is running in the background 
>>>> and control has been returned to the REPL
>>>>
>>>>
>>>> vineri, 22 ianuarie 2016, 22:06:01 UTC+1, Adrian Salceanu a scris:
>>>>>
>>>>> Hi, 
>>>>>
>>>>> I'm hammering at a web app and I'm trying to setup functionality to 
>>>>> monitor the file system for changes and restart/reload the server 
>>>>> automatically so the changes are picked up (I'm using Mux which uses 
>>>>> HttpServer). 
>>>>>
>>>>> The approach I have in mind is: 
>>>>>
>>>>> 1. have a startup script which is run from the command line, something 
>>>>> like: 
>>>>> $ julia -L startup.jl
>>>>>
>>>>> 2. the startup script launches the web app, which starts the web 
>>>>> server. My intention was to run 
>>>>> $ julia -L app.jl 
>>>>> as a command inside startup.jl, detached, and have the startup.jl 
>>>>> script get back control, with app.jl running detached in the background. 
>>>>>
>>>>> 3. once startup.jl gets back control, it begins monitoring the file 
>>>>> system and when changes are detected, kills the app and relaunches it. 
>>>>>
>>>>> That was the theory. Now, I might be missing something but I can't 
>>>>> find a way to detach the command I'm running and get control back to the 
>>>>> startup script. And I tried a lot of things! 
>>>>>
>>>>> ===
>>>>>
>>>>> I'm providing simpler example using "ping", which also run 
>>>>> indefinitely, similar to the web server. 
>>>>>
>>>>> julia> run(detach(`ping "www.google.com"`)) # the command is detached 
>>>>> and continues to run after the julia REPL is closed, but at this point 
>>>>> the 
>>>>> REPL does not get control, there's no cursor available in the REPL
>>>>> PING www.google.com (173.194.45.82): 56 data bytes
>>>>> 64 bytes from 173.194.45.82: icmp_seq=0 ttl=54 time=30.138 ms
>>>>> 64 bytes from 173.194.45.82: icmp_seq=1 ttl=54 time=30.417 ms
>>>>> ... more output ...
>>>>> 64 bytes from 173.194.45.82: icmp_seq=7 ttl=54 time=30.486 ms
>>>>> 64 bytes from 173.194.45.82: icmp_seq=8 ttl=54 time=30.173 ms
>>>>> ^CERROR: InterruptException:   
>>>>>   < here I press Ctrl+C and only now the REPL 
>>>>> gets 
>>>>> back the cursor, with the command still running in the background
>>>>>
>>>>> ===
>>>>>
>>>>> Also, related to this, passing "&" into the command to detach does not 
>>>>> work as expected, the "&" is interpreted as argument of the command. Not 
>>>>> sure if this would help anyway to return control to the startup.jl 
>>>>> script? 
>>>>>
>>>>> julia> run(detach(`ping "www.google.com" &`));
>>>>> usage: ping [-AaDdfnoQqRrv] [-b boundif] [-c count] [-G sweepmaxsize]
>>>>> [-g sweepminsize] [-h sweepincrsize] [-i wait] [−k 
>>>>> trafficclass]
>>>>> [-l preload] [-M mask | time] [-m ttl] [-p pattern]
>>>>> [-S src_addr] [-s packetsize] [-t timeout][-W waittime] 
>>>>> [-z tos]
>>>>> host
>>>>>ping [-AaDdfLnoQqRrv] [-b boundif] [-c count] [-I iface] [-i 
>>>>> wait]
>>>>> [−k trafficclass] [-l preload] [-M mask | time] [-m ttl] 
>>>>> [-p pattern] [-S src_addr]
>>>>> [-s packetsize] [-T ttl] [-t timeout] [-W waittime]
>>>>> [-z tos] mcast-group
>>>>> ERROR: failed process: Process(`ping www.google.com &`, 
>>>>> ProcessExited(64)) [64]
>>>>>  in run at /usr/local/Cellar/julia/0.4.2/lib/julia/sys.dylib
>>>>>
>>>>> ===
>>>>>
>>>>> Thanks
>>>>>
>>>>
>>

Re: [julia-users] Re: How to run a detached command and return execution to the parent script?

[Adrian Salceanu]

Thanks! 

@async works perfectly with your example. And also works great with running 
the "ping" command. The problem is web app / Mux / HttpServer exit 
immediately if run @async. Same with @spawn, the app exits immediately. 


vineri, 22 ianuarie 2016, 22:40:56 UTC+1, Stefan Karpinski a scris:
>
> @spawn runs a command on a (random) worker process. If you want to do 
> "background" work in the current process, you can use @async:
>
> julia> t = @async (sleep(5); rand())
> Task (runnable) @0x000112d746a0
>
> julia> wait(t)
> 0.14543742643271207
>
>
> On Fri, Jan 22, 2016 at 4:33 PM, Adrian Salceanu <adrian@gmail.com 
> > wrote:
>
>> Oh! The ruby analogy made me think about actually spawning the detached 
>> command! Which produced the desired effect! 
>>
>> julia> @spawn run(detach(`ping www.google.com`))
>>
>>
>>
>> vineri, 22 ianuarie 2016, 22:29:27 UTC+1, Adrian Salceanu a scris:
>>>
>>> I guess what I'm looking for is the equivalent of Ruby's Process#spawn
>>>
>>> In REPL: 
>>>
>>> >> pid = Process.spawn("ping www.google.com", :out => '/dev/null')
>>> 83210
>>> >> <-- the process is running in the background 
>>> and control has been returned to the REPL
>>>
>>>
>>> vineri, 22 ianuarie 2016, 22:06:01 UTC+1, Adrian Salceanu a scris:
>>>>
>>>> Hi, 
>>>>
>>>> I'm hammering at a web app and I'm trying to setup functionality to 
>>>> monitor the file system for changes and restart/reload the server 
>>>> automatically so the changes are picked up (I'm using Mux which uses 
>>>> HttpServer). 
>>>>
>>>> The approach I have in mind is: 
>>>>
>>>> 1. have a startup script which is run from the command line, something 
>>>> like: 
>>>> $ julia -L startup.jl
>>>>
>>>> 2. the startup script launches the web app, which starts the web 
>>>> server. My intention was to run 
>>>> $ julia -L app.jl 
>>>> as a command inside startup.jl, detached, and have the startup.jl 
>>>> script get back control, with app.jl running detached in the background. 
>>>>
>>>> 3. once startup.jl gets back control, it begins monitoring the file 
>>>> system and when changes are detected, kills the app and relaunches it. 
>>>>
>>>> That was the theory. Now, I might be missing something but I can't find 
>>>> a way to detach the command I'm running and get control back to the 
>>>> startup 
>>>> script. And I tried a lot of things! 
>>>>
>>>> ===
>>>>
>>>> I'm providing simpler example using "ping", which also run 
>>>> indefinitely, similar to the web server. 
>>>>
>>>> julia> run(detach(`ping "www.google.com"`)) # the command is detached 
>>>> and continues to run after the julia REPL is closed, but at this point the 
>>>> REPL does not get control, there's no cursor available in the REPL
>>>> PING www.google.com (173.194.45.82): 56 data bytes
>>>> 64 bytes from 173.194.45.82: icmp_seq=0 ttl=54 time=30.138 ms
>>>> 64 bytes from 173.194.45.82: icmp_seq=1 ttl=54 time=30.417 ms
>>>> ... more output ...
>>>> 64 bytes from 173.194.45.82: icmp_seq=7 ttl=54 time=30.486 ms
>>>> 64 bytes from 173.194.45.82: icmp_seq=8 ttl=54 time=30.173 ms
>>>> ^CERROR: InterruptException:   
>>>>   < here I press Ctrl+C and only now the REPL gets 
>>>> back the cursor, with the command still running in the background
>>>>
>>>> ===
>>>>
>>>> Also, related to this, passing "&" into the command to detach does not 
>>>> work as expected, the "&" is interpreted as argument of the command. Not 
>>>> sure if this would help anyway to return control to the startup.jl script? 
>>>>
>>>> julia> run(detach(`ping "www.google.com" &`));
>>>> usage: ping [-AaDdfnoQqRrv] [-b boundif] [-c count] [-G sweepmaxsize]
>>>> [-g sweepminsize] [-h sweepincrsize] [-i wait] [−k 
>>>> trafficclass]
>>>> [-l preload] [-M mask | time] [-m ttl] [-p pattern]
>>>> [-S src_addr] [-s packetsize] [-t timeout][-W waittime] [-z 
>>>> tos]
>>>> host
>>>>ping [-AaDdfLnoQqRrv] [-b boundif] [-c count] [-I iface] [-i 
>>>> wait]
>>>> [−k trafficclass] [-l preload] [-M mask | time] [-m ttl] 
>>>> [-p pattern] [-S src_addr]
>>>> [-s packetsize] [-T ttl] [-t timeout] [-W waittime]
>>>> [-z tos] mcast-group
>>>> ERROR: failed process: Process(`ping www.google.com &`, 
>>>> ProcessExited(64)) [64]
>>>>  in run at /usr/local/Cellar/julia/0.4.2/lib/julia/sys.dylib
>>>>
>>>> ===
>>>>
>>>> Thanks
>>>>
>>>
>

Re: [julia-users] Re: How to run a detached command and return execution to the parent script?

[Adrian Salceanu]

No no, It's perfectly fine, it was my fault. What I haven't realized is 
that if I start the server async then my script will finish immediately, 
which also terminated the server. It was my responsibility to keep the 
whole app alive now. 

It works like a charm! 


sâmbătă, 23 ianuarie 2016, 00:06:13 UTC+1, Stefan Karpinski a scris:
>
> The shell works with processes, Julia has tasks where are not the same 
> thing...
>
> On Fri, Jan 22, 2016 at 5:49 PM, Adrian Salceanu <adrian@gmail.com 
> > wrote:
>
>> The problem seems to that HttpServer can not run @async - it exits 
>> immediately. 
>>
>> ===
>>
>> using HttpServer
>>
>> http = HttpHandler() do req::Request, res::Response
>> Response( ismatch(r"^/hello/", req.resource) ? exit(2) : 404 )
>> end
>>
>> server = Server( http )
>> run( server, 8001 )  # <--- this works but blocks
>> @async run( server, 8001 ) # <--- this exits immediately
>>
>> ===
>>
>> It's not necessarily a problem that HttpServer blocks. But what drives me 
>> nuts is: if I run 
>> $ julia app.jl & 
>> in the shell, it works perfectly. The process is placed in the 
>> background, the server happily listens to the assigned port, etc. 
>>
>> Why can't I run the same command from within another julia process and 
>> get the same effect? 
>>
>>
>> vineri, 22 ianuarie 2016, 22:40:56 UTC+1, Stefan Karpinski a scris:
>>>
>>> @spawn runs a command on a (random) worker process. If you want to do 
>>> "background" work in the current process, you can use @async:
>>>
>>> julia> t = @async (sleep(5); rand())
>>> Task (runnable) @0x000112d746a0
>>>
>>> julia> wait(t)
>>> 0.14543742643271207
>>>
>>>
>>> On Fri, Jan 22, 2016 at 4:33 PM, Adrian Salceanu <adrian@gmail.com> 
>>> wrote:
>>>
>>>> Oh! The ruby analogy made me think about actually spawning the detached 
>>>> command! Which produced the desired effect! 
>>>>
>>>> julia> @spawn run(detach(`ping www.google.com`))
>>>>
>>>>
>>>>
>>>> vineri, 22 ianuarie 2016, 22:29:27 UTC+1, Adrian Salceanu a scris:
>>>>>
>>>>> I guess what I'm looking for is the equivalent of Ruby's Process#spawn
>>>>>
>>>>> In REPL: 
>>>>>
>>>>> >> pid = Process.spawn("ping www.google.com", :out => '/dev/null')
>>>>> 83210
>>>>> >> <-- the process is running in the 
>>>>> background and control has been returned to the REPL
>>>>>
>>>>>
>>>>> vineri, 22 ianuarie 2016, 22:06:01 UTC+1, Adrian Salceanu a scris:
>>>>>>
>>>>>> Hi, 
>>>>>>
>>>>>> I'm hammering at a web app and I'm trying to setup functionality to 
>>>>>> monitor the file system for changes and restart/reload the server 
>>>>>> automatically so the changes are picked up (I'm using Mux which uses 
>>>>>> HttpServer). 
>>>>>>
>>>>>> The approach I have in mind is: 
>>>>>>
>>>>>> 1. have a startup script which is run from the command line, 
>>>>>> something like: 
>>>>>> $ julia -L startup.jl
>>>>>>
>>>>>> 2. the startup script launches the web app, which starts the web 
>>>>>> server. My intention was to run 
>>>>>> $ julia -L app.jl 
>>>>>> as a command inside startup.jl, detached, and have the startup.jl 
>>>>>> script get back control, with app.jl running detached in the background. 
>>>>>>
>>>>>> 3. once startup.jl gets back control, it begins monitoring the file 
>>>>>> system and when changes are detected, kills the app and relaunches it. 
>>>>>>
>>>>>> That was the theory. Now, I might be missing something but I can't 
>>>>>> find a way to detach the command I'm running and get control back to the 
>>>>>> startup script. And I tried a lot of things! 
>>>>>>
>>>>>> ===
>>>>>>
>>>>>> I'm providing simpler example using "ping", which also run 
>>>>>> indefinitely, similar to the web server. 
>>>>>>
>>>>>> julia> run(d

[julia-users] Pipe operator and functions with multiple arguments

[Adrian Salceanu]

I'm a bit puzzled by the behavior of the pipe operator when feeding values 
to functions expecting multiple arguments. Basically it doesn't seem to 
work at all. Am I missing something? 

Ex: 

julia> function show_off(x, y)
   println(x)
   println(y)
   end
show_off (generic function with 1 method)


julia> show_off(1, 2)
1
2


julia> 1 |> show_off(2)
ERROR: MethodError: `show_off` has no method matching show_off(::Int64)
Closest candidates are:
  show_off(::Any, ::Any)


julia> 1,2 |> show_off
ERROR: MethodError: `show_off` has no method matching show_off(::Int64)
Closest candidates are:
  show_off(::Any, ::Any)
 in |> at operators.jl:198


julia> (1,2) |> show_off
ERROR: MethodError: `show_off` has no method matching show_off(::Tuple{Int64
,Int64})
Closest candidates are:
  show_off(::Any, ::Any)
 in |> at operators.jl:198

Re: [julia-users] Multiple submodules inside a main module, with each submodule in one file

[Adrian Salceanu]

Thanks Adrian - that's a nice way to do it, much appreciated. 

If I'm not wrong, it's similar to what the manual says when it mentions 
mixins? Read about it but haven't realized it could be used to this effect 
:) 

The approach I went with for now is to use convention over configuration, 
mapping folder structure to modules names (also a common pattern in other 
places). Mentioning it in case someone else runs into the same problem, as 
an alternative. 

With a structure like this, framework code would go into lib/jinnie with 
modules named Jinnie_App, Jinnie_Packager, Jinnie_Router. While the user 
code would go into app/ 

tree .
.
├── app
│   ├── controllers
│   ├── models
│   └── views
├── bin
├── config
│   └── routes.jl
├── config.jl
├── db
├── doc
├── lib
│   ├── jinnie
│   │   ├── app.jl
│   │   ├── packager.jl
│   │   └── router.jl
│   └── tasks
├── log
├── packages.jl
├── public
├── test
├── tmp
└── vendor


16 directories, 6 files

Then in config.jl 

push!( LOAD_PATH, abspath(".") ) 
push!( LOAD_PATH, abspath("./config") )
push!( LOAD_PATH, abspath("./lib/jinnie") )

and from there on, "using". 

This ends up providing unique module names which visually indicate the 
hierarchy can be reversed to transform the names into paths. 


marți, 29 decembrie 2015, 17:54:12 UTC+1, Adrian Cuthbertson a scris:
>
> Julia's module system is very flexible. Check out Modules in the (0.4) 
> manual and also include, import, export, using, require, reload, whos, 
> workspace, current_module and probably some other related entries - it can 
> all be a bit confusing :).
>
> Here's an example which may do what you're looking for:
>
> $ cat fi_0.jl 
> module M0
> include("fi_1.jl")
> include("fi_2.jl")
> end
>
> $ cat fi_1.jl 
> module M1
> foo()="I'm foo"
> end
>
> $ cat fi_2.jl 
> module M2
>foo()="I'm foo too"
> end
>
> $ julia -q
> julia> include("fi_0.jl")
> M0
> julia> M0.M1.foo()
> "I'm foo"
> julia> M0.M2.foo()
> "I'm foo too"
>
> -- Adrian.
>
> On Tue, Dec 29, 2015 at 3:54 PM, Adrian Salceanu <adrian@gmail.com 
> > wrote:
>
>> Hi! 
>>
>> I'm trying to figure out how to split a module across multiple files. Or 
>> better put, to have multiple submodules inside a main module, with each 
>> submodule in one file. However, I always end up with the latest file 
>> overwriting the module code previously imported (last submodule overwrites 
>> the previous submodule). 
>>
>> Example: 
>>
>> =
>>
>> # file: a.jl
>> module Test
>>
>> module A
>>
>> export a
>>
>> function a()
>>   println("a")
>> end
>>
>> end
>>
>> end
>>
>> ==
>>
>> # file: b.jl
>>
>> module Test
>>
>> module B
>>
>> export b
>>
>> function b()
>>   println("b")
>> end
>>
>> end
>>
>> end
>>
>> ===
>>
>> Expected result: 
>> upon including both files in a 3rd file or REPL, Test.A.a() and 
>> Test.B.b() should both be in scope. 
>>
>> Actual result: 
>> last included file overwrites everything in Test, so either Test.A.a() or 
>> Test.B.b() are in scope, but not both. 
>>
>> 
>>
>> Where am I going with this? 
>> I'm interested in applying a design pattern common in ruby (rails) or 
>> elixir. In these languages one can split a module (or class/type 
>> definition) across multiple files and with each inclusion, the 
>> module/class/type is reopened, and the new methods are appended. 
>>
>> Why doing this? 
>> Coming from ruby/elixir, it's an excellent way of organizing a complex 
>> codebase. I'm coding a web framework and I want all the framework code to 
>> be in a Framework super-module - with submodules for each major feature, 
>> like Router, Server, Controller, etc. To encapsulate the framework code in 
>> a structure like Framework.Router, Framework.Server, etc. 
>> Then the user app, a instance implementation of the web framework would 
>> be in a module of it's own, say AppName, with it's own submodules for 
>> Routes, Config, etc. Resulting in AppName.Routes, AppName.Config, etc. 
>> (Similar to how rails organizes the apps). 
>>
>> Is this possible? If yes, how can it be done? 
>>
>> Many thanks for your time and your help, much appreciated! 
>>
>
>

[julia-users] Multiple submodules inside a main module, with each submodule in one file

[Adrian Salceanu]

Hi! 

I'm trying to figure out how to split a module across multiple files. Or 
better put, to have multiple submodules inside a main module, with each 
submodule in one file. However, I always end up with the latest file 
overwriting the module code previously imported (last submodule overwrites 
the previous submodule). 

Example: 

=

# file: a.jl
module Test

module A

export a

function a()
  println("a")
end

end

end

==

# file: b.jl

module Test

module B

export b

function b()
  println("b")
end

end

end

===

Expected result: 
upon including both files in a 3rd file or REPL, Test.A.a() and Test.B.b() 
should both be in scope. 

Actual result: 
last included file overwrites everything in Test, so either Test.A.a() or 
Test.B.b() are in scope, but not both. 



Where am I going with this? 
I'm interested in applying a design pattern common in ruby (rails) or 
elixir. In these languages one can split a module (or class/type 
definition) across multiple files and with each inclusion, the 
module/class/type is reopened, and the new methods are appended. 

Why doing this? 
Coming from ruby/elixir, it's an excellent way of organizing a complex 
codebase. I'm coding a web framework and I want all the framework code to 
be in a Framework super-module - with submodules for each major feature, 
like Router, Server, Controller, etc. To encapsulate the framework code in 
a structure like Framework.Router, Framework.Server, etc. 
Then the user app, a instance implementation of the web framework would be 
in a module of it's own, say AppName, with it's own submodules for Routes, 
Config, etc. Resulting in AppName.Routes, AppName.Config, etc. (Similar to 
how rails organizes the apps). 

Is this possible? If yes, how can it be done? 

Many thanks for your time and your help, much appreciated! 

[julia-users] Re: Pipe operator and functions with multiple arguments

[Adrian Salceanu]

Hi Ismael, 

I understand, thanks for your answer. I like the proposed solution, I'll 
give it a try. 

It's strange that the pipe operator won't work with type inference, seems 
to be working great with F#. However, comparing with F#, I can see how 
currying and partial function application can be more problematic, as 
technically (if I understood correctly) Julia functions / methods always 
take just one argument, a tuple. But this is even more reason to expect to 
be able to feed a tuple into the pipe operator and just work. 

I personally would love to see more support for the pipe operator and 
currying and partial function application to get rid of some of the 
parenthesis. 

- A


marți, 29 decembrie 2015, 18:17:21 UTC+1, Ismael Venegas Castelló a scris:
>
> Hi Adrian, that's the way it works now for now, single-input single-output 
> functions only, |> may be even deprecated in the future since type 
> inference doesn't work well at all for now, it's going to be removed from 
> Base it seems. Currying/function chaining has been discussed a lot at 
> GitHub.
>
> Here is a pull request I made to make what you want possible (it contains 
> links to several other similar discussions at GitHub), since I also just 
> expected it to work:
>
> * https://github.com/JuliaLang/julia/pull/14476
>
> You can see my solution (and other peoples solutions) there and decide 
> whether to use it or not yourself.
>
>
>
> El martes, 29 de diciembre de 2015, 11:02:09 (UTC-6), Adrian Salceanu 
> escribió:
>>
>> I'm a bit puzzled by the behavior of the pipe operator when feeding 
>> values to functions expecting multiple arguments. Basically it doesn't seem 
>> to work at all. Am I missing something? 
>>
>> Ex: 
>>
>> julia> function show_off(x, y)
>>println(x)
>>println(y)
>>end
>> show_off (generic function with 1 method)
>>
>>
>> julia> show_off(1, 2)
>> 1
>> 2
>>
>>
>> julia> 1 |> show_off(2)
>> ERROR: MethodError: `show_off` has no method matching show_off(::Int64)
>> Closest candidates are:
>>   show_off(::Any, ::Any)
>>
>>
>> julia> 1,2 |> show_off
>> ERROR: MethodError: `show_off` has no method matching show_off(::Int64)
>> Closest candidates are:
>>   show_off(::Any, ::Any)
>>  in |> at operators.jl:198
>>
>>
>> julia> (1,2) |> show_off
>> ERROR: MethodError: `show_off` has no method matching show_off(::Tuple{
>> Int64,Int64})
>> Closest candidates are:
>>   show_off(::Any, ::Any)
>>  in |> at operators.jl:198
>>
>>

Re: [julia-users] Multiple submodules inside a main module, with each submodule in one file

[Adrian Salceanu]

I see, that's interesting! Only Distributions.jl defines a module and the 
rest of the files are included and "scoped" in. 

Thanks for your help, much appreciated! 


marți, 29 decembrie 2015, 18:28:37 UTC+1, Adrian Cuthbertson a scris:
>
> You'll tend to find julia modules are organised around types and 
> implementations rather than modules. Have a look at 
> https://github.com/JuliaStats/Distributions.jl as an example of a pretty 
> complex package with many types and implementations and only one module. 
> But the approaches are evolving all the time :).
>
> On Tue, Dec 29, 2015 at 5:16 PM, Adrian Salceanu <adrian@gmail.com 
> > wrote:
>
>> Thanks Adrian - that's a nice way to do it, much appreciated. 
>>
>> If I'm not wrong, it's similar to what the manual says when it mentions 
>> mixins? Read about it but haven't realized it could be used to this effect 
>> :) 
>>
>> The approach I went with for now is to use convention over configuration, 
>> mapping folder structure to modules names (also a common pattern in other 
>> places). Mentioning it in case someone else runs into the same problem, as 
>> an alternative. 
>>
>> With a structure like this, framework code would go into lib/jinnie with 
>> modules named Jinnie_App, Jinnie_Packager, Jinnie_Router. While the user 
>> code would go into app/ 
>>
>> tree .
>> .
>> ├── app
>> │   ├── controllers
>> │   ├── models
>> │   └── views
>> ├── bin
>> ├── config
>> │   └── routes.jl
>> ├── config.jl
>> ├── db
>> ├── doc
>> ├── lib
>> │   ├── jinnie
>> │   │   ├── app.jl
>> │   │   ├── packager.jl
>> │   │   └── router.jl
>> │   └── tasks
>> ├── log
>> ├── packages.jl
>> ├── public
>> ├── test
>> ├── tmp
>> └── vendor
>>
>>
>> 16 directories, 6 files
>>
>> Then in config.jl 
>>
>> push!( LOAD_PATH, abspath(".") ) 
>> push!( LOAD_PATH, abspath("./config") )
>> push!( LOAD_PATH, abspath("./lib/jinnie") )
>>
>> and from there on, "using". 
>>
>> This ends up providing unique module names which visually indicate the 
>> hierarchy can be reversed to transform the names into paths. 
>>
>>
>> marți, 29 decembrie 2015, 17:54:12 UTC+1, Adrian Cuthbertson a scris:
>>>
>>> Julia's module system is very flexible. Check out Modules in the (0.4) 
>>> manual and also include, import, export, using, require, reload, whos, 
>>> workspace, current_module and probably some other related entries - it can 
>>> all be a bit confusing :).
>>>
>>> Here's an example which may do what you're looking for:
>>>
>>> $ cat fi_0.jl 
>>> module M0
>>> include("fi_1.jl")
>>> include("fi_2.jl")
>>> end
>>>
>>> $ cat fi_1.jl 
>>> module M1
>>> foo()="I'm foo"
>>> end
>>>
>>> $ cat fi_2.jl 
>>> module M2
>>>foo()="I'm foo too"
>>> end
>>>
>>> $ julia -q
>>> julia> include("fi_0.jl")
>>> M0
>>> julia> M0.M1.foo()
>>> "I'm foo"
>>> julia> M0.M2.foo()
>>> "I'm foo too"
>>>
>>> -- Adrian.
>>>
>>> On Tue, Dec 29, 2015 at 3:54 PM, Adrian Salceanu <adrian@gmail.com> 
>>> wrote:
>>>
>>>> Hi! 
>>>>
>>>> I'm trying to figure out how to split a module across multiple files. 
>>>> Or better put, to have multiple submodules inside a main module, with each 
>>>> submodule in one file. However, I always end up with the latest file 
>>>> overwriting the module code previously imported (last submodule overwrites 
>>>> the previous submodule). 
>>>>
>>>> Example: 
>>>>
>>>> =
>>>>
>>>> # file: a.jl
>>>> module Test
>>>>
>>>> module A
>>>>
>>>> export a
>>>>
>>>> function a()
>>>>   println("a")
>>>> end
>>>>
>>>> end
>>>>
>>>> end
>>>>
>>>> ==
>>>>
>>>> # file: b.jl
>>>>
>>>> module Test
>>>>
>>>> module B
>>>>
>>>> export b
>>>>
>>>> function b()
>>>>  

[julia-users] Re: Pipe operator and functions with multiple arguments

[Adrian Salceanu]

Thanks, I like it, nice one liner. 

Definitely useful for quick prototyping in REPL if too slow for production 
code. 

- A

marți, 29 decembrie 2015, 18:28:56 UTC+1, Ismael Venegas Castelló a scris:
>
> My proposal in the PR is:
>
> julia> show_off(x, y) = (@show x y; nothing)
> show_off (generic function with 1 method)
>
> julia> show_off(1, 2)
> x = 1
> y = 2
>
> julia> (1, 2) |> show_off
> ERROR: MethodError: `show_off` has no method matching 
> show_off(::Tuple{Int64,Int
> 64})
> Closest candidates are:
>   show_off(::Any, ::Any)
>  in |> at operators.jl:198
>  in eval at boot.jl:263
>
> julia> Base.|>(xs::Tuple, f) = f(xs...)
> |> (generic function with 7 methods)
>
> julia> (1, 2) |> show_off
> x = 1
> y = 2
>
> Note: splat *...* is slow, type inference is broken don't use this in 
> performance critical code. Since this is I/O it's ok I guess. Since |> may 
> be deprecated, in the future there also may be a package that allows to do 
> this and extend the functionality beyond, for now you have to define that 
> method yourself, if you decide t use it you can put the method definition 
> in you ~/.juliarc.jl configuration file.
>
>
>
> El martes, 29 de diciembre de 2015, 11:02:09 (UTC-6), Adrian Salceanu 
> escribió:
>>
>> I'm a bit puzzled by the behavior of the pipe operator when feeding 
>> values to functions expecting multiple arguments. Basically it doesn't seem 
>> to work at all. Am I missing something? 
>>
>> Ex: 
>>
>> julia> function show_off(x, y)
>>println(x)
>>println(y)
>>end
>> show_off (generic function with 1 method)
>>
>>
>> julia> show_off(1, 2)
>> 1
>> 2
>>
>>
>> julia> 1 |> show_off(2)
>> ERROR: MethodError: `show_off` has no method matching show_off(::Int64)
>> Closest candidates are:
>>   show_off(::Any, ::Any)
>>
>>
>> julia> 1,2 |> show_off
>> ERROR: MethodError: `show_off` has no method matching show_off(::Int64)
>> Closest candidates are:
>>   show_off(::Any, ::Any)
>>  in |> at operators.jl:198
>>
>>
>> julia> (1,2) |> show_off
>> ERROR: MethodError: `show_off` has no method matching show_off(::Tuple{
>> Int64,Int64})
>> Closest candidates are:
>>   show_off(::Any, ::Any)
>>  in |> at operators.jl:198
>>
>>