[julia-users] Black screen/window with OpenGL
Hi! I just installed the OpenGL.jl, SDL.jl, and GLUT.jl packages, and tried to run some of the NeHe tutorials. But no matter which one I tried, the result is only black. With SDL.jl, I get a window titled e.g. NeHe Tut 2 with only black contents. When it has focus, it responds to the q button to quit the tutorial, but the window itself doesn't close until I exit Julia (and never responds to its close button). With GLUT.jl, I get black in full screen until I press q. I built NeHe tutorial 2 for Linux/SDL from the NeHe homepage, and it displays a white triangle and square as expected. I'm at a loss how to debug this. Does anyone have any ideas? I'm on ubuntu 13.04 and my graphics driver is listed as GeForce 9500M GS/PCIe/SSE2. Thanks, Toivo
Re: [julia-users] pmap/map avoid return by value
Hi Amit, Well in my case I'm parsing a bunch of files, store results in dictionaries which are merged back into one big array of dictionaries. Since each file can be parsed independently pmap seems to be good and clean fit. But because size of each Dictionary is quite big merging the data back is super slow. Perhaps pmap is not best answer to this problem and I should look further into shared arrays (which unfortunately I haven't had time right now) kuba
[julia-users] Inlining question
I have a small test-case which is slow when benchmarked from a loop, but fast when benchmarked from a function: using Images function expensive(img) img[1, 2] * img[3, 4] + img[5, 6] - img[7, 8] end function benchmark(img) for i in 1:100 expensive(img) end end function main() img = Image(float32(randn(10, 10))) # this is fast gc_disable() @time benchmark(img) gc_enable() # this is slow gc_disable() @time for i in 1:100 expensive(img) end gc_enable() end main() As per Tim Holy (Images.jl issue #74) this is because Julia can't inline the getindex call when expensive() is being called from a loop rather than from a function. Why is that though? Isn't img a local variable, with a known type, which should result in a fully type-inferred version of expensive()? Why is it specialized even more when it is called from one level deeper? Oddly enough, making img a global improves performance of the slow case by about 50%, and doesn't alter the fast case... Now I'm confused. Best, Tim
Re: [julia-users] Re: Addition of (unused uninstatiated) type, slows down program by 25%
You should definitely open an issue about this – if your timings are right it's definitely not desirable behaviour. https://github.com/JuliaLang/julia/issues?state=open On 31 May 2014 11:00, mike c coolbutusel...@gmail.com wrote: I've narrowed down the problem. It's not a profiling problem. Julia seems to have a step-change in speed when there are too many functions of a similar signature. I've made a short example that reproduces this slowdown: http://pastebin.com/iHAa2Cws Run the code once as-is, and then uncomment the intersect() function which is currently disabled and run it again. I see a 20% drop in speed. Note: This intersect function is NEVER actually being called. And the type it is related to is NEVER INSTANTIATED. I think this probably qualifies as a bug, but it may just be the price to pay for multiple dispatch when there are too many functions (in this case 5 functions) to choose from.
[julia-users] parsers?
are there any libraries for parsing in julia? either parser combinator or something more traditional (maybe a wrapper for something like antlr)? all i can find is an old discussion started by leah h in which jeff b suggests doing everything in julia. that included a pointer to https://github.com/astrieanna/juliaparsec/blob/master/juliaparsec.jl from dan l which is, well, as he says, rather basic. i'm not sure i agree, but i don't want to write my own combinator lib either. i guess i'm looking for things like a clean separation between grammar and implementation, support for errors with line numbers, speed, easy debugging... andrew
[julia-users] Re: Will Julia be ready for commercial deployment within a time-frame of 3 years?
Hello, On Saturday, May 31, 2014 4:40:02 PM UTC+2, Robert Gates wrote: Dear Julia users: my colleagues and I are planning on writing cross-platform (Linux variants, OS X, Windows) commercial software for the research community, preferably in Julia. Our projected release date will be some time in the next 3-4 years. It is crucial to user-friendliness and protection of intellectual property that Julia supports (and documents) its compilation to stand-alone processor-native code. If that code depends on shared-libraries, it should be possible to install these together with the distributed application without incurring licensing issues in a commercial context. Further, it will be necessary to develop full-featured GUIs with interactive 3D plotting features such as patch with full alpha transparency. Of course it is imperative that such implementations be easy to interface with and stable enough for commercial deployment. The question we are left with: will Julia be ready in 3-4 years? If we use Julia, will we be faced with having to debug Julia packages instead of our own code? Will the end-user ever notice that we have used Julia for development? We have heard that C, Fortran can be called easily in Julia, i.e., we should be able to call solver such as PARDISO without issue? This will be crucial, as our problems rely on the solution of large, unsymmetric, and possibly indefinite systems. Of course, we needn't have every feature imaginable by man, and we will be happy to contribute to the Julia project if anything exotic should arise. Regards, Robert + coworkers *Prediction is very difficult, especially about the future (Niels Bohr).* Let's try: * deployability is a common topic, so it's expected there will be effort spend * saving IP in code is a common topic, so someone will have a solution and share (hopefully) * you and your colleagues are happy to contribute to Julia, at least your effort will be spend The hard thing is: 3D GUI. I made my own experiences with toolkits and drawing/painting libraries and i'd say, you need an expert anyway (choosing julia or not). Even if you only adapt an available solution, it's hard to make it work, robust, maintainable and user-friendly.
Re: [julia-users] parsers?
There was a nice looking PEG system previewed a few days ago if you search the users list (and I think there was another one several months back by Michael Fox). On Sat, May 31, 2014 at 1:22 PM, andrew cooke and...@acooke.org wrote: are there any libraries for parsing in julia? either parser combinator or something more traditional (maybe a wrapper for something like antlr)? all i can find is an old discussion started by leah h in which jeff b suggests doing everything in julia. that included a pointer to https://github.com/astrieanna/juliaparsec/blob/master/juliaparsec.jl from dan l which is, well, as he says, rather basic. i'm not sure i agree, but i don't want to write my own combinator lib either. i guess i'm looking for things like a clean separation between grammar and implementation, support for errors with line numbers, speed, easy debugging... andrew
Re: [julia-users] parsers?
https://groups.google.com/d/msg/julia-users/t56VxOX1vvk/nszQYWP_pm4J https://groups.google.com/d/msg/julia-users/6jz3Ow5SAAE/TgKHQ48gUG4J thanks! On Saturday, 31 May 2014 14:04:28 UTC-4, Isaiah wrote: There was a nice looking PEG system previewed a few days ago if you search the users list (and I think there was another one several months back by Michael Fox). On Sat, May 31, 2014 at 1:22 PM, andrew cooke and...@acooke.org javascript: wrote: are there any libraries for parsing in julia? either parser combinator or something more traditional (maybe a wrapper for something like antlr)? all i can find is an old discussion started by leah h in which jeff b suggests doing everything in julia. that included a pointer to https://github.com/astrieanna/juliaparsec/blob/master/juliaparsec.jl from dan l which is, well, as he says, rather basic. i'm not sure i agree, but i don't want to write my own combinator lib either. i guess i'm looking for things like a clean separation between grammar and implementation, support for errors with line numbers, speed, easy debugging... andrew
[julia-users] Re: Stiff ODE solver available now?
Hil, DASSL.jl supports multiple equtions, I have just added an example to the readme file [1]. If you need any further help with setting up DASSL.jl I am ready to help you. [1] https://github.com/pwl/DASSL.jl/blob/master/README.md W dniu czwartek, 29 maja 2014 19:31:19 UTC+2 użytkownik Frederick napisał: Hi, DASSL doesn't work. Multiple equations. Tried to do as Alex suggested. 1) download the appropriate file from http://sourceforge.net/projects/juliadeps-win/files/ for sundials on 32 bit -- sundials-2.5.0-x86 ... for sundials on 64 bit -- sundials-2.5.0-i686... 2) extract and place in known folder (placed in folder libDLLs in the .julia folder in C:/Users/Username/ where all the other packages are kept) NOTE: withing libDLLs is the file LICENSE and the folder usr within the folder usr are the folders bin, include and lib (and so forth keeping same structure as zip) 3) edit the juliarc.jl file (in Windows, found in the Julia/etc/julia folder of the Windows version) add push!(DL_LOAD_PATH, C:/pat/to/libDLLs/usr) and save Result when running test code in Sundials package: error compiling ode: could not load module libsundials_cvode: The specified module could not be found. And not working yet. Tried also paths of... C:/path/to/libDLLs/ and C:/path/to/libDLLs/usr/bin Questions: where is the .juliarc.jl file to be found? I found a juliarc.jl file in the Julia/etc/julia folder. But this file does not have the dot at the beginning of the file name. Is this the file to alter, or is it a template to copy, rename with the preceding dot, and place... where? which folder should be referenced with the LOAD_PATH? is libDLLs enough? or do I want a specific folder within that? Further suggestions? Once this works, I would suggest adding the explicit instructions to the Sundials readme... and maybe to the other Packages requiring similar dependencies. And thanks for the continued help, all.
[julia-users] Re: Will Julia be ready for commercial deployment within a time-frame of 3 years?
Robert, These questions are hard to answer without knowing a little bit more about what you are planning. How many people will be working on the project. What are the tools used to date? What would be the considered alternative to Julia? These are quite essential questions. If the alternative would be for instance C++/Qt it would also be an option to do the UI in Qt and just the numerics in Julia. I have investigated this approach myself and written documentation on embedding Julia in C that is now part of the Julia manual. Embedding Julia is actually straight forward. I have also been experimenting with a pure Julia approach using Gtk.jl. And while this went surprisingly well and is definitely a lot of fun I would probably use the embedding approach in a commercial product because it is a little less risky. Note that all this is personal experience. You will have to make your own picture in order to make a decision. Cheers, Tobi Am Samstag, 31. Mai 2014 16:40:02 UTC+2 schrieb Robert Gates: Dear Julia users: my colleagues and I are planning on writing cross-platform (Linux variants, OS X, Windows) commercial software for the research community, preferably in Julia. Our projected release date will be some time in the next 3-4 years. It is crucial to user-friendliness and protection of intellectual property that Julia supports (and documents) its compilation to stand-alone processor-native code. If that code depends on shared-libraries, it should be possible to install these together with the distributed application without incurring licensing issues in a commercial context. Further, it will be necessary to develop full-featured GUIs with interactive 3D plotting features such as patch with full alpha transparency. Of course it is imperative that such implementations be easy to interface with and stable enough for commercial deployment. The question we are left with: will Julia be ready in 3-4 years? If we use Julia, will we be faced with having to debug Julia packages instead of our own code? Will the end-user ever notice that we have used Julia for development? We have heard that C, Fortran can be called easily in Julia, i.e., we should be able to call solver such as PARDISO without issue? This will be crucial, as our problems rely on the solution of large, unsymmetric, and possibly indefinite systems. Of course, we needn't have every feature imaginable by man, and we will be happy to contribute to the Julia project if anything exotic should arise. Regards, Robert + coworkers
[julia-users] Re: Will Julia be ready for commercial deployment within a time-frame of 3 years?
On Saturday, May 31, 2014 10:40:02 AM UTC-4, Robert Gates wrote: my colleagues and I are planning on writing cross-platform (Linux variants, OS X, Windows) commercial software for the research community, preferably in Julia. Our projected release date will be some time in the next 3-4 years. It is crucial to user-friendliness and protection of intellectual property that Julia supports (and documents) its compilation to stand-alone processor-native code. If that code depends on shared-libraries, it should be possible to install these together with the distributed application without incurring licensing issues in a commercial context. Since all of those things are basically possible now, although precompilation is not easy to use, I would be pretty confident that they would be working smoothly in 3-4 years. Further, it will be necessary to develop full-featured GUIs with interactive 3D plotting features such as patch with full alpha transparency. By develop, do you mean that you plan to develop 3d plotting yourself? Or that you will be relying on someone else to develop it for you? Full-featured 3d plotting software takes years to develop; your best bet would be to wrap a mature library like VTK. There is actually already a proof-of-concept wrapper at https://github.com/ihnorton/VTK.jl The question we are left with: will Julia be ready in 3-4 years? If we use Julia, will we be faced with having to debug Julia packages instead of our own code? No matter what language or libraries you use, you always face the possibility of bugs in the library. Julia is surprisingly stable for a language that is still in its early stages, the main question is what Julia libraries you are going to rely on. But almost certainly you will run into things that are less mature than if you are using widely deployed 10+ year-old libraries in Python or C++. Will the end-user ever notice that we have used Julia for development? No, there is no reason you have to make this user-visible, even now. We have heard that C, Fortran can be called easily in Julia, i.e., we should be able to call solver such as PARDISO without issue? This will be crucial, as our problems rely on the solution of large, unsymmetric, and possibly indefinite systems. Right now, you will have to write wrappers yourself, but I have no doubt that we'll see usable PETSc wrappers within the next year or two, and you can call PARDISO that way. But it shouldn't be particularly hard to call PARDISO yourself, especially in shared memory.
Re: [julia-users] Compilation to hardware (ASICs)
It seems the idea of JIT Hardware Compilation has been around for a while: http://link.springer.com/chapter/10.1007%2F978-3-540-78791-4_12#page-1 http://www.informationweek.com/jit-compilation-to-hardware/d/d-id/1073781? http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=arnumber=6567576url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D6567576 On Friday, May 30, 2014 8:58:29 PM UTC-3, Jameson wrote: JIT hardware? I guess that is a reasonably logical next step after doing JIT software compilers JIT FGPA sounds almost reasonable. Last time I checked, the Xilinx FGPA coprocessor was very expensive (like new luxury car expensive), but is anyone doing stuff like that already? On Friday, May 30, 2014, David Ainish david@gmail.com javascript: wrote: Nice projects on those links. LegUp http://legup.eecg.utoronto.ca/ looks good. I'm new to Julia so this may be a silly question... For that workflow (LLVM IR - FPGA/ASIC), does Julia already emit IR code? if not, once Julia is able to emit IR code, would it be possible to use a tool like LegUp to create an ASIC? The workflow IR - ASIC would be a two-steps workflow. While it's a good option, there could be an integrated workflow that would give very interesting possibilities tied to Julia's dynamic nature. Dreaming out loud, at the time we can 3D print microprocessors, if part of our code requires intensive processing and that task could be parallelized, we could 3D print for instance 100 processors of that specific task and Julia spread the work over those 100 ASICs. Or translate the code that requires more computational power dynamically to any available FPGA. On Thursday, May 29, 2014 7:00:15 PM UTC-3, Matt Bauman wrote: It seems like there are several groups working on an LLVM IR to FPGA/ASIC compiler. That'd be the way to do it. Make julia emit the IR, and then compile that to your ASIC. http://stackoverflow.com/questions/3664692/creating-a- vhdl-backend-for-llvm Google search: llvm ir hardware (asic|fpga) https://encrypted.google.com/search?safe=offhl=enq=llvm+ir+hardware+%28asic%7Cfpga%29oq=llvm+ir+hardware+%28asic%7Cfpga%29gs_l=serp.3...112583.114690.0.114921.7.7.0.0.0.0.154.567.5j2.7.00...1c.1.45.serp..7.0.0.jqB_jKu49fw On Thursday, May 29, 2014 5:26:40 PM UTC-4, John Myles White wrote: If someone wrote code to do that, I don't see why it wouldn't be possible. -- John On May 29, 2014, at 11:44 AM, David Ainish david@gmail.com wrote: 3D printing is growing at a rapid pace and in a few years it will be possible to 3D print our own integrated circuits and microprocessors. Would it be possible for Julia in the future to do Hardware compilation http://en.wikipedia.org/wiki/Hardware_compilation and 3D print ASICs http://en.wikipedia.org/wiki/ASIC from our Julia code?
Re: [julia-users] Re: Addition of (unused uninstatiated) type, slows down program by 25%
On Sunday, 1 June 2014 00:21:07 UTC+10, Simon Kornblith wrote: Yes, this is kind of a toy solution to a toy example. It sounds like what you describe is implementable as: f(i, object, objects..) = min(intersect(object, i), f(i, objects...)) f(i) = 0.0 I did try something like that in the example code, but it turned out slower than the naive looping case. (It's also possible that dynamic dispatch isn't actually a bottleneck in your code, depending on how much is happening in the intersect function.) There's quite a bit happening in each intersect function, I think dynamic dispatch is probably not a big part of the overall runtime, but I'll take any performance improvements that I can get. Since the objects are set in stone once the program starts, is it possible to convert the list of objects into the list of functions that must be called. I.e. do the dynamic dispatch lookup *once* and then cache that in another structure/array? Mike.
Re: [julia-users] Type stability of map - is there a better way to do this?
There are a number of issues about type inference for `map` and similar
functions. See 6692 and the issues linked therein:
https://github.com/JuliaLang/julia/pull/6692
On Fri, May 30, 2014 at 4:27 AM, Tomas Lycken tomas.lyc...@gmail.com
wrote:
I have a `DataArray{Float64,1}` named `ps` with a bunch of values I'd like
to map to their bin indices in a histogram, and a function `histidx` that
maps a single value (based on endpoints of the histogram and number of
bins). I try the following:
idxs = map(p - histidx(minx, maxx, Nbins, p), ps)
and the result is a `DataArray{Any,1}`. However, I know that `histidx` can
only return integers:
function histidx(xmin, xmax, Nbins::Integer, x)
if x = xmin
return 1
elseif x = xmax
return Nbins
else
return iceil((x-xmin)/((xmax-xmin)/Nbins))
end
end
Why isn't map able to infer that the type of the resulting array could be
tighter?
I try to help it in various ways, but without success:
julia typeof(map(p - histidx(minx, maxx, Nbins, p)::Integer, ps))
DataArray{Any,1}
julia foo() = map(p - histidx(minx, maxx, Nbins, p); typeof(foo())
DataArray{Any,1}
The only thing that seems to work is manually doing this on the underlying
data instead:
julia typeof(map(p - histidx(minx, maxx, Nbins, p), ps.data))
Array{Int64,1}
This is troublesome, since it a) requires me to handle `Array`s and
`DataArray`s differently when I do this mapping, and b) doesn't allow for
missing data in the `DataArray`s.
I think the correct behavior should be to return a DataArray{Int64,1},
with each `NA` value mapped to `NA` in the output.
// T
[julia-users] Re: Surprising behavior of singleton types
On Saturday, May 31, 2014 1:08:29 PM UTC-4, Iain Dunning wrote:
And I don't necessarily think this is wrong - look at the code it generates
f{t,n}(::Type{Array{t,n}},::Array{t,n}) at none:3
f{t,n}(::Type{Array{t,N}},::Array{t,n}) at none:2
There is nothing to distinguish these two from a dispatch perspective -
its just picking the one defined last.
n ≠ N
This is the bug I mentioned yesterday where Array{T} reads back as Array{T,
N}.
Or maybe I didn't understand what you meant by a dispatch perspective.
I checked that reversing the order of the arguments doesn't change this, so
it's not an issue of the order of resolving static parameters.
Which part of the manual is wrong?
The part that says Type{xxx} matches only the object xxx.
Re: [julia-users] parsers?
I should add that PEGParser's code is fairly new and untested (besides having an uninspired name). I'm also hoping to have better action semantics soon. On Saturday, May 31, 2014 2:17:27 PM UTC-4, andrew cooke wrote: https://groups.google.com/d/msg/julia-users/t56VxOX1vvk/nszQYWP_pm4J https://groups.google.com/d/msg/julia-users/6jz3Ow5SAAE/TgKHQ48gUG4J thanks! On Saturday, 31 May 2014 14:04:28 UTC-4, Isaiah wrote: There was a nice looking PEG system previewed a few days ago if you search the users list (and I think there was another one several months back by Michael Fox). On Sat, May 31, 2014 at 1:22 PM, andrew cooke and...@acooke.org wrote: are there any libraries for parsing in julia? either parser combinator or something more traditional (maybe a wrapper for something like antlr)? all i can find is an old discussion started by leah h in which jeff b suggests doing everything in julia. that included a pointer to https://github.com/astrieanna/juliaparsec/blob/master/juliaparsec.jl from dan l which is, well, as he says, rather basic. i'm not sure i agree, but i don't want to write my own combinator lib either. i guess i'm looking for things like a clean separation between grammar and implementation, support for errors with line numbers, speed, easy debugging... andrew
