Re: [julia-users] Optional Arguments for Do-Block Syntax for Functions
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 > 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
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
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
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
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
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
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
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/
[julia-users] Re: Complex parallel computing implementation
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) >
[julia-users] Complex parallel computing implementation
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
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
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
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
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)
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&sa=D&sntz=1&usg=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)
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)
> 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)
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 ca
Re: [julia-users] Help please: how to expand dictionary into (local ?) variables with the same name as the keys and the corresponding values
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 > 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 >> > 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
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 > 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 >> > 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
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 > 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
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 > 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
> 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 > 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 >>>> 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
quot;\")\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 "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 >>> wrote: >>> >>>> Thanks >>>> >>>> Maybe I wasn't clear enough - otherwi
Re: [julia-users] Help please: how to expand dictionary into (local ?) variables with the same name as the keys and the corresponding values
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 > 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 >>> 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" :> >
Re: [julia-users] Help please: how to expand dictionary into (local ?) variables with the same name as the keys and the corresponding values
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 wou
Re: [julia-users] Help please: how to expand dictionary into (local ?) variables with the same name as the keys and the corresponding values
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 >>>> > 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
Re: [julia-users] Help please: how to expand dictionary into (local ?) variables with the same name as the keys and the corresponding values
> 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 > 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 >>> 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 >>&g
Re: [julia-users] Help please: how to expand dictionary into (local ?) variables with the same name as the keys and the corresponding values
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 >> 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 &g
Re: [julia-users] Help please: how to expand dictionary into (local ?) variables with the same name as the keys and the corresponding values
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 > 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 P
Re: [julia-users] Help please: how to expand dictionary into (local ?) variables with the same name as the keys and the corresponding values
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 >>> 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 >>>> > 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
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 >> 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 >>>> 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
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
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 > 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 >>> 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
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 > 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
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.
Re: [julia-users] Help please: how to expand dictionary into (local ?) variables with the same name as the keys and the corresponding values
Thanks, but I don't know what the dict contains, it is user defined.
[julia-users] Help please: how to expand dictionary into (local ?) variables with the same name as the keys and the corresponding values
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?
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 > 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?
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
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è >>>> >>>> >>
[julia-users] Re: ANN: New Julia Packages website
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
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
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
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
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
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
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
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
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?
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?
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?
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
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
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
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
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
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
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?
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 > > > > > > > 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?
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 > > 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 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?
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
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!
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!
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
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!
[julia-users] Re: Use Variable in Regex (interpolate)
Great one, thanks! Re shorter way, it can be written as a one-liner: result = matchall(Regex("^$(var)+"), mystring) marți, 17 martie 2015, 23:49:57 UTC+1, David P. Sanders a scris: > > > > El martes, 17 de marzo de 2015, 15:14:35 (UTC-6), Julia User escribió: >> >> How to use a julia variable in a regex string (interpolate). >> >> var = " " >> reg = r"^$(var)+" # Something like this >> result = matchall(reg, mystring) >> >> >> Is there a way to make this work? >> > > How about the following? I don't know if there's a shorter way. > > > var = " " > reg_string = "^$(var)+" # standard Julia string > reg = Regex(reg_string) # make a regular expression out of the string > result = matchall(reg, mystring) > > > > Best, > David. > > > >> >> Thanks >> >> >> >>
Re: [julia-users] Parametric types... types?!
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?!
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
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
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
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
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
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
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
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
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
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?
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 > 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 >>> 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 >>>> > 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 >>>>>>>> $
Re: [julia-users] Re: How to run a detached command and return execution to the parent script?
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 > 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 >>> 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. >>>>>> >>>>
Re: [julia-users] Re: How to run a detached command and return execution to the parent script?
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 >> 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?
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 > 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?
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 > 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 > > > 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 comm
Re: [julia-users] Re: How to run a detached command and return execution to the parent script?
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 > 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 >>>> >>> >
[julia-users] Re: How to run a detached command and return execution to the parent script?
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 >> >
[julia-users] Re: How to run a detached command and return execution to the parent script?
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?
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] Multiple submodules inside a main module, with each submodule in one file
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 > 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 >>> 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() >>>> pri
[julia-users] Re: Pipe operator and functions with multiple arguments
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 >> >>
[julia-users] Re: Pipe operator and functions with multiple arguments
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
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 > 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] Pipe operator and functions with multiple arguments
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
[julia-users] Multiple submodules inside a main module, with each submodule in one file
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!