Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.
I have to say that Jeff and Stefan (and of course all the other from the core team) do an awesome job. I have been waiting myself for responses of Jeff but with a software project that big it is absolutely normal that one will not always get an immediate response to every bug report. If someone thinks that the community or the development model has a problem this can be discussed on the mailing list or the issue tracker. What I absolutely not get is the critique about the issues in Julia packages. It is the entire point to decouple core and packages so that these can be independently maintained. And this is how we should proceed. We just need some default packages that are so mature that they can hold the standard of Julia core. And I also think that we will make Jeffs (Keno, Jameson, ..) life easier when Julia core bugs are really core bugs and not issues in the (to large) base library. Am Dienstag, 30. Dezember 2014 07:49:04 UTC+1 schrieb Keno Fischer: That thing about build stats? Probably grabbing the wrong numbers, which wasn't true, and could be easily spot checked by using the script pointed in my linked post. I apologize for missing that part if your post (and I added a follow up comment to the hacker news discussion once you pointed that out). I did actually go back and look at it, but I somehow must have read over it. It wasn't meant of a criticism of your methodology - I was simply looking at the recent travis build and the only ones failing were development branches and those with dependency issues. I'm still not entirely convinced that the Travis numbers are a good indicator of build status for Julia, because of the dependency issue which comes up way more often than julia changes breaking, as well as the way we uses branches may be different from other projects - nevertheless, let's rest that debate. This whole discussion turned a little more adversarial than I had hoped it would. Still, I expect we can at least take some points away from this whole thing and I hope that this experience didn't entirely ruin you're experience with Julia - maybe try it again after it matures a little more. On Tue, Dec 30, 2014 at 6:11 AM, Dan Luu dan...@gmail.com javascript: wrote: Hi Jeff, That's a lot of claims, so let me just respond to one, that my post implies ... that we don't understand our own code. Where I've been vague and imply something it's because I don't like calling people out by name. I literally stated the opposite in my post, saying that the Julia core team can hold all of the code in their collective heads. I'm guessing the objection is to the line code that even the core developers can't figure out because it's too obscure, but that refers to the vague anecdote in the previous paragraph. The plural here is a side effect of being vague, not an implication that you can't figure it out your own code. If it helps clear the air, the specifics are that when I ask Stefan how something works the most common response I get is that I should ask you or the mailing list since it's your code and he doesn't really understand it. He could probably figure it out, but it's enough of a non-trivial effort that he always forwards me to someone else. You might object that I never actually emailed you, but that's because I've seen what happened Leah emailed you, with plenty of reminder emails, when she was working on her thesis and trying to figure out things that would help her finish her thesis. Most emails didn't get a response, even with a reminder or two, and I figured I'd get the same treatment since I don't even know you. I understand that you must be incredibly busy, between doing your own thesis and also being the most prolific contributor to Julia. But perhaps you can see why, in this case, I might not expect my questions to be received with gratitude. There are some easily verifiable claims in my post that got pushback. That plotting bug? Probably because I'm using master, which wasn't true and could have been checked by anyone with a release build handy. That thing about build stats? Probably grabbing the wrong numbers, which wasn't true, and could be easily spot checked by using the script pointed in my linked post. In the past, I've talked to someone about the build being broken and gotten the response that it worked for him, and when I pointed out that Travis had been broken for half a day I got some response about how Travis often has spurious fails. The bug eventually got fixed, a few days later, but in the meantime the build was broken and there was also a comment about how people shouldn't expect the build on master to not be broken. I'm being vague again because I don't see calling people out as being very productive, but if you prefer I can dig through old chat logs the dredge up the specifics. Now, you say that responses to bug reports aren't responses to blog posts. That's true,
Re: [julia-users] in-place copying mutable vs immutable
Is x = copy(y) the same as x = y for immutables??
For this question the @which macro is very useful. It tells you that
julia @which copy(1)
copy(x::Union(AbstractString,TopNode,LambdaStaticData,(Any...,),Symbol,DataType,UnionType,Function,QuoteNode,Number))
at operators.jl:174
and that definition is just a no-up, so the answer is yes for the types in
that defintion.
Is there a better way using dispatch? Something like SetMax!{KImmutable,
VMutable}
I have often wanted to dispatch of Mutable/Immutable, but these properties
go across of the declared type tree. My understand is that the declared
subtype relation will also in the future be restricted to have one
supertype, i.e. a tree structure, and therefore it doesn't seem likely that
you'll be able to write a type the way you proposed.
2014-12-30 8:56 GMT+01:00 Greg Plowman greg.plow...@gmail.com:
I am trying to define a composite type for holding pairs (similar to Dict,
I suppose), where I keep track of a max key and associated value.
I want to define a function that checks and sets new max as below:
type MaxPair{K,V}
key::K
value::V
end
function SetMax!{K,V}(pair::MaxPair{K,V}, key::K, value::V)
if key pair.key
copy!(pair.key, key)
copy!(pair.value, value)
end
return pair
end
I originally had:
pair.key = copy(key)
pair.value = copy(value)
which worked fine, but in my case key is usually Int, and value is some
sort of array (or possibly composite type).
For efficiency I thought the in-place copy!() would be better, but copy!()
is not defined for Int (presumably for immutable types in general).
I could of course, use
pair.key = copy(key) # should this just be pair.key = key for immutables
copy!(pair.value, value)
Is x = copy(y) the same as x = y for immutables??
but in an effort to keep type general, I thought the following might work
function SetMax!{K,V}(pair::MaxPair{K,V}, key::K, value::V)
if key pair.key
if isimmutable(pair.key)
pair.key = key
else
copy!(pair.key, key)
end
if isimmutable(pair.value)
pair.value = value
else
copy!(pair.value, value)
end
end
return pair
end
Is anything wrong with this?
Is there a better way using dispatch?
Something like SetMax!{KImmutable, VMutable}
Thanks, Greg
[julia-users] as_strided
Numpy has a great little function called `as_strided` that let's you construct a view into an array with different strides (http://scipy-lectures.github.io/advanced/advanced_numpy/). It ends up being really handy for moving window type things and some other numpy-fu. Does Julia have a comparable function?
Re: [julia-users] as_strided
Maybe sub and slice is what you are looking for. 2014-12-30 4:09 GMT+01:00 samuel_ainswo...@brown.edu: Numpy has a great little function called `as_strided` that let's you construct a view into an array with different strides ( http://scipy-lectures.github.io/advanced/advanced_numpy/). It ends up being really handy for moving window type things and some other numpy-fu. Does Julia have a comparable function?
[julia-users] using Gtk.jl?
Hello colleagues, i tried to grep METADATA, but somehow the only package to require Gtk.jl seems to be GtkSourceWidget.jl. Can anyone here report a package that uses Gtk.jl, especially the signal_connect functions? I'm somehow stuck, and some code that works would be great inspiration... Wishing a happy day, Andreas
Re: [julia-users] using Gtk.jl?
Tobias K. (tknopp on github) has an unregistered package called Julietta. ImaveView has an optional Gtk dependency. On Dec 30, 2014 8:39 AM, Andreas Lobinger lobing...@gmail.com wrote: Hello colleagues, i tried to grep METADATA, but somehow the only package to require Gtk.jl seems to be GtkSourceWidget.jl. Can anyone here report a package that uses Gtk.jl, especially the signal_connect functions? I'm somehow stuck, and some code that works would be great inspiration... Wishing a happy day, Andreas
Re: [julia-users] using Gtk.jl?
ImageView (on my phone...) On Dec 30, 2014 8:45 AM, Isaiah Norton isaiah.nor...@gmail.com wrote: Tobias K. (tknopp on github) has an unregistered package called Julietta. ImaveView has an optional Gtk dependency. On Dec 30, 2014 8:39 AM, Andreas Lobinger lobing...@gmail.com wrote: Hello colleagues, i tried to grep METADATA, but somehow the only package to require Gtk.jl seems to be GtkSourceWidget.jl. Can anyone here report a package that uses Gtk.jl, especially the signal_connect functions? I'm somehow stuck, and some code that works would be great inspiration... Wishing a happy day, Andreas
[julia-users] Re: using Gtk.jl?
Hi Andreas, In https://github.com/tknopp/Julietta.jl/ you will find various uses of signal_connect. Unfortunately I don't think that Julietta is currently working due to some changes in the listview interface. Other than that I usually look at the test file. Cheers, Tobi Am Dienstag, 30. Dezember 2014 14:39:20 UTC+1 schrieb Andreas Lobinger: Hello colleagues, i tried to grep METADATA, but somehow the only package to require Gtk.jl seems to be GtkSourceWidget.jl. Can anyone here report a package that uses Gtk.jl, especially the signal_connect functions? I'm somehow stuck, and some code that works would be great inspiration... Wishing a happy day, Andreas
[julia-users] Re: using Gtk.jl?
@Isaiah :-) Am Dienstag, 30. Dezember 2014 14:54:47 UTC+1 schrieb Tobias Knopp: Hi Andreas, In https://github.com/tknopp/Julietta.jl/ you will find various uses of signal_connect. Unfortunately I don't think that Julietta is currently working due to some changes in the listview interface. Other than that I usually look at the test file. Cheers, Tobi Am Dienstag, 30. Dezember 2014 14:39:20 UTC+1 schrieb Andreas Lobinger: Hello colleagues, i tried to grep METADATA, but somehow the only package to require Gtk.jl seems to be GtkSourceWidget.jl. Can anyone here report a package that uses Gtk.jl, especially the signal_connect functions? I'm somehow stuck, and some code that works would be great inspiration... Wishing a happy day, Andreas
Re: [julia-users] using Gtk.jl?
Hello colleague, On Tuesday, December 30, 2014 2:46:40 PM UTC+1, Isaiah wrote: ImageView (on my phone...) but if ImageView uses Gtk, then why grep -R fails? lobi@orange4:~/.julia/v0.3/METADATA/ImageView/versions$ grep -R Gtk None0.1.2/requires:Tk 0.0.23/requires:Tk 0.0.2/requires:Tk 0.0.15/requires:Tk 0.1.6/requires:Tk 0.1.8/requires:Tk 0.0.5/requires:Tk 0.0.7/requires:Tk 0.0.0/requires:Tk 0.0.16/requires:Tk 0.0.18/requires:Tk 0.0.8/requires:Tk 0.0.10/requires:Tk 0.0.6/requires:Tk 0.1.0/requires:Tk 0.1.1/requires:Tk 0.1.5/requires:Tk 0.0.13/requires:Tk 0.0.14/requires:Tk 0.0.17/requires:Tk 0.0.20/requires:Tk 0.0.9/requires:Tk 0.1.9/requires:Tk 0.0.19/requires:Tk 0.0.11/requires:Tk 0.1.7/requires:Tk 0.0.4/requires:Tk 0.0.1/requires:Tk 0.0.22/requires:Tk 0.1.3/requires:Tk 0.0.21/requires:Tk 0.0.12/requires:Tk 0.1.4/requires:Tk 0.0.3/requires:Tk while lobi@orange4:~/.julia/v0.3/METADATA/ImageView/versions$ grep -R Tk
Re: [julia-users] using Gtk.jl?
Hello colleague, On Tuesday, December 30, 2014 2:46:40 PM UTC+1, Isaiah wrote: ImageView (on my phone... if ImageView uses Gtk, then why does lobi@orange4:~/.julia/v0.3/METADATA/ImageView/versions$ grep -R Gtk None while lobi@orange4:~/.julia/v0.3/METADATA/ImageView/versions$ grep -R Tk gives me a long list?
Re: [julia-users] using Gtk.jl?
Do a `git checkout gtk` to check out the gtk branch. --Tim On Tuesday, December 30, 2014 05:56:07 AM Andreas Lobinger wrote: Hello colleague, On Tuesday, December 30, 2014 2:46:40 PM UTC+1, Isaiah wrote: ImageView (on my phone...) but if ImageView uses Gtk, then why grep -R fails? lobi@orange4:~/.julia/v0.3/METADATA/ImageView/versions$ grep -R Gtk None0.1.2/requires:Tk 0.0.23/requires:Tk 0.0.2/requires:Tk 0.0.15/requires:Tk 0.1.6/requires:Tk 0.1.8/requires:Tk 0.0.5/requires:Tk 0.0.7/requires:Tk 0.0.0/requires:Tk 0.0.16/requires:Tk 0.0.18/requires:Tk 0.0.8/requires:Tk 0.0.10/requires:Tk 0.0.6/requires:Tk 0.1.0/requires:Tk 0.1.1/requires:Tk 0.1.5/requires:Tk 0.0.13/requires:Tk 0.0.14/requires:Tk 0.0.17/requires:Tk 0.0.20/requires:Tk 0.0.9/requires:Tk 0.1.9/requires:Tk 0.0.19/requires:Tk 0.0.11/requires:Tk 0.1.7/requires:Tk 0.0.4/requires:Tk 0.0.1/requires:Tk 0.0.22/requires:Tk 0.1.3/requires:Tk 0.0.21/requires:Tk 0.0.12/requires:Tk 0.1.4/requires:Tk 0.0.3/requires:Tk while lobi@orange4:~/.julia/v0.3/METADATA/ImageView/versions$ grep -R Tk
Re: [julia-users] using Gtk.jl?
Thanks, Tim! Didn't realize that wasn't merged. On Tue, Dec 30, 2014 at 9:00 AM, Tim Holy tim.h...@gmail.com wrote: Do a `git checkout gtk` to check out the gtk branch. --Tim On Tuesday, December 30, 2014 05:56:07 AM Andreas Lobinger wrote: Hello colleague, On Tuesday, December 30, 2014 2:46:40 PM UTC+1, Isaiah wrote: ImageView (on my phone...) but if ImageView uses Gtk, then why grep -R fails? lobi@orange4:~/.julia/v0.3/METADATA/ImageView/versions$ grep -R Gtk None0.1.2/requires:Tk 0.0.23/requires:Tk 0.0.2/requires:Tk 0.0.15/requires:Tk 0.1.6/requires:Tk 0.1.8/requires:Tk 0.0.5/requires:Tk 0.0.7/requires:Tk 0.0.0/requires:Tk 0.0.16/requires:Tk 0.0.18/requires:Tk 0.0.8/requires:Tk 0.0.10/requires:Tk 0.0.6/requires:Tk 0.1.0/requires:Tk 0.1.1/requires:Tk 0.1.5/requires:Tk 0.0.13/requires:Tk 0.0.14/requires:Tk 0.0.17/requires:Tk 0.0.20/requires:Tk 0.0.9/requires:Tk 0.1.9/requires:Tk 0.0.19/requires:Tk 0.0.11/requires:Tk 0.1.7/requires:Tk 0.0.4/requires:Tk 0.0.1/requires:Tk 0.0.22/requires:Tk 0.1.3/requires:Tk 0.0.21/requires:Tk 0.0.12/requires:Tk 0.1.4/requires:Tk 0.0.3/requires:Tk while lobi@orange4:~/.julia/v0.3/METADATA/ImageView/versions$ grep -R Tk
[julia-users] in-place copying mutable vs immutable
Note that the PriorityQueue type in Base may do what you want.
[julia-users] Re: using Gtk.jl?
You can also find some basic examples here: https://github.com/jverzani/GtkInteract.jl/ On Tuesday, December 30, 2014 8:39:20 AM UTC-5, Andreas Lobinger wrote: Hello colleagues, i tried to grep METADATA, but somehow the only package to require Gtk.jl seems to be GtkSourceWidget.jl. Can anyone here report a package that uses Gtk.jl, especially the signal_connect functions? I'm somehow stuck, and some code that works would be great inspiration... Wishing a happy day, Andreas
Re: [julia-users] Julia for mobile app development
I hope we'll one day have ObjectiveC.jl running on iOS, but that day is a long way off. On 30 December 2014 at 02:06, Stefan Karpinski ste...@karpinski.org wrote: You'd have to get Julia running on a mobile phone first, which we may be getting close to but as far as I know has not been accomplished yet. On Mon, Dec 29, 2014 at 8:18 PM, ccsv.1056...@gmail.com wrote: Are there any package in the works for an NUI or some mobile GUI for Julia?
[julia-users] Re: using Gtk.jl?
As well, there are some examples in some unfinished notes here: https://gist.github.com/jverzani/836e4c065862cab4ee50 On Tuesday, December 30, 2014 8:39:20 AM UTC-5, Andreas Lobinger wrote: Hello colleagues, i tried to grep METADATA, but somehow the only package to require Gtk.jl seems to be GtkSourceWidget.jl. Can anyone here report a package that uses Gtk.jl, especially the signal_connect functions? I'm somehow stuck, and some code that works would be great inspiration... Wishing a happy day, Andreas
[julia-users] Re: using Gtk.jl?
This looks pretty cool!!! Would be awesome to integrate it into the Gtk.jl documentation! Am Dienstag, 30. Dezember 2014 15:59:15 UTC+1 schrieb j verzani: As well, there are some examples in some unfinished notes here: https://gist.github.com/jverzani/836e4c065862cab4ee50 On Tuesday, December 30, 2014 8:39:20 AM UTC-5, Andreas Lobinger wrote: Hello colleagues, i tried to grep METADATA, but somehow the only package to require Gtk.jl seems to be GtkSourceWidget.jl. Can anyone here report a package that uses Gtk.jl, especially the signal_connect functions? I'm somehow stuck, and some code that works would be great inspiration... Wishing a happy day, Andreas
Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.
The Travis complaint is valid and really difficult. We rely on Travis pretty heavily since it's a great tool, but there's something peculiar that I don't think anyone fully understands about the Travis environment (VM config? amount of memory? dunno), Julia's runtime, or the combination of the two, that leads to failures that we never see locally. For example https://github.com/JuliaLang/julia/issues/9176 describes an issue that has been present, ongoing, and intermittently causing Travis builds to fail for over a month now. I stopped adding to my list of occurrences after 25 not because it stopped happening, but because it didn't seem worth the effort to continue finding and chronicling each time. The lack of responses probably indicates no one else has been able to reproduce it locally either, or has any idea what's causing it. I wish Julia didn't have this kind of problem. I think we all do. I wouldn't feel comfortable tagging a release in the current state of master, but we're not anywhere near an RC for 0.4 yet so hopefully there's time to maybe figure some of this stuff out. And perfect is the enemy of the good, etc. On Monday, December 29, 2014 10:49:04 PM UTC-8, Keno Fischer wrote: That thing about build stats? Probably grabbing the wrong numbers, which wasn't true, and could be easily spot checked by using the script pointed in my linked post. I apologize for missing that part if your post (and I added a follow up comment to the hacker news discussion once you pointed that out). I did actually go back and look at it, but I somehow must have read over it. It wasn't meant of a criticism of your methodology - I was simply looking at the recent travis build and the only ones failing were development branches and those with dependency issues. I'm still not entirely convinced that the Travis numbers are a good indicator of build status for Julia, because of the dependency issue which comes up way more often than julia changes breaking, as well as the way we uses branches may be different from other projects - nevertheless, let's rest that debate. This whole discussion turned a little more adversarial than I had hoped it would. Still, I expect we can at least take some points away from this whole thing and I hope that this experience didn't entirely ruin you're experience with Julia - maybe try it again after it matures a little more. On Tue, Dec 30, 2014 at 6:11 AM, Dan Luu dan...@gmail.com javascript: wrote: Hi Jeff, That's a lot of claims, so let me just respond to one, that my post implies ... that we don't understand our own code. Where I've been vague and imply something it's because I don't like calling people out by name. I literally stated the opposite in my post, saying that the Julia core team can hold all of the code in their collective heads. I'm guessing the objection is to the line code that even the core developers can't figure out because it's too obscure, but that refers to the vague anecdote in the previous paragraph. The plural here is a side effect of being vague, not an implication that you can't figure it out your own code. If it helps clear the air, the specifics are that when I ask Stefan how something works the most common response I get is that I should ask you or the mailing list since it's your code and he doesn't really understand it. He could probably figure it out, but it's enough of a non-trivial effort that he always forwards me to someone else. You might object that I never actually emailed you, but that's because I've seen what happened Leah emailed you, with plenty of reminder emails, when she was working on her thesis and trying to figure out things that would help her finish her thesis. Most emails didn't get a response, even with a reminder or two, and I figured I'd get the same treatment since I don't even know you. I understand that you must be incredibly busy, between doing your own thesis and also being the most prolific contributor to Julia. But perhaps you can see why, in this case, I might not expect my questions to be received with gratitude. There are some easily verifiable claims in my post that got pushback. That plotting bug? Probably because I'm using master, which wasn't true and could have been checked by anyone with a release build handy. That thing about build stats? Probably grabbing the wrong numbers, which wasn't true, and could be easily spot checked by using the script pointed in my linked post. In the past, I've talked to someone about the build being broken and gotten the response that it worked for him, and when I pointed out that Travis had been broken for half a day I got some response about how Travis often has spurious fails. The bug eventually got fixed, a few days later, but in the meantime the build was broken and there was also a comment about how people shouldn't expect the build on master to not be broken. I'm being vague
Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.
Thanks, Tim! On Mon, Dec 29, 2014 at 10:39 PM, Tim Holy tim.h...@gmail.com wrote: For anyone who wants to help with the test coverage issue, I just posted some instructions here: https://github.com/JuliaLang/julia/issues/9493 --Tim On Monday, December 29, 2014 06:55:37 PM Ravi Mohan wrote: Fwiw the correct engineering response here seems to be to acknowledge the subset of Dan's criticisms that are valid/reasonable, fix those, and get back to work. Criticising Dan's motives etc isn't a productive path (imo) If there are low hanging fruit fixes on such a successful project,(the build/test thing certainly seems to be one) that is a *good* thing. Yes the HN crowd can be a bit rough (I am plinkplonk on HN, fwiw) , and often unreasonable, but hey anyone running an open source project can't afford to get disturbed by weird discussions on HN. All projects have bugs, and if someone has an uncanny knack for surfacing heisenbugs, that is a good thing, irrespective of communication style. My 2 cents (I am just tinkering with Julia and don't use it anger yet, but after some discussion with Viral (who is my neighbor) am considering jumping in - Julia is a brilliant project). As a prospective contributor to Julia, I am encouraged by Stefan's approach to this) regards, Ravi
[julia-users] Re: using Gtk.jl?
That's the plan, eventually. --J On Tuesday, December 30, 2014 10:09:34 AM UTC-5, Tobias Knopp wrote: This looks pretty cool!!! Would be awesome to integrate it into the Gtk.jl documentation! Am Dienstag, 30. Dezember 2014 15:59:15 UTC+1 schrieb j verzani: As well, there are some examples in some unfinished notes here: https://gist.github.com/jverzani/836e4c065862cab4ee50 On Tuesday, December 30, 2014 8:39:20 AM UTC-5, Andreas Lobinger wrote: Hello colleagues, i tried to grep METADATA, but somehow the only package to require Gtk.jl seems to be GtkSourceWidget.jl. Can anyone here report a package that uses Gtk.jl, especially the signal_connect functions? I'm somehow stuck, and some code that works would be great inspiration... Wishing a happy day, Andreas
[julia-users] ldltfact factorization for symmetric matrices
The help for ldltfact says:
Base.ldltfact(A) - LDLtFactorization
Compute a factorization of a positive definite matrix A such
that A=L*Diagonal(d)*L' where L is a unit lower triangular
matrix and d is a vector with non-negative elements.
But for a general positive definite matrix it does not work.
In fact the header of the function is
function ldltfact{T}(M::SymTridiagonal{T})
Or I miss something?
Giovanni
Re: [julia-users] Julia for mobile app development
Once it's running on ARM it should be possible to use the C API to call into Julia code from ObjC, right? I suppose that doesn't address the OP question about GUI dev in Julia, but at least using Julia for compute within a mobile app should be pretty feasible in the not-so-distant future. peace, s On Tue, Dec 30, 2014 at 9:50 AM, Mike Innes mike.j.in...@gmail.com wrote: I hope we'll one day have ObjectiveC.jl running on iOS, but that day is a long way off. On 30 December 2014 at 02:06, Stefan Karpinski ste...@karpinski.org wrote: You'd have to get Julia running on a mobile phone first, which we may be getting close to but as far as I know has not been accomplished yet. On Mon, Dec 29, 2014 at 8:18 PM, ccsv.1056...@gmail.com wrote: Are there any package in the works for an NUI or some mobile GUI for Julia?
[julia-users] Macro scoping (or hygiene?) problems
I’m doing some metaprogramming for Interpolations.jl, and I’m getting stuck
at an error that I think is due to scoping issues in my nested quotes, and
I’ve stared at this for so long now I’m not getting anywhere.
I can do the following
matching(d) = quote
println(Matching: , $d)
end
nonmatching(d) = quote
println(Not matching: , $d)
end
@ngenerate N T function example{T,N}(A::Array{T,N}, xs::NTuple{N,Real}...)
@nexprs N dim-begin
@nexprs N d-begin
if d==dim
eval(matching(d))
else
eval(nonmatching(d))
end
end
end
end
example(rand(2,2), 1.5, 0.7)
and get the expected output:
Matching: 1
Not matching: 2
Not matching: 1
Matching: 2
Examining with macroexpand, I see that the eval calls are still there, but
for performance reasons I want to avoid them, so I try to rewrite it to use
eval(ngenerate(...)) instead of @ngenerate ...:
#matching and nonmatching defined as before
ex = ngenerate(
:N,
:T,
:(example{T,N}(A::Array{T,N}, xs::NTuple{N,Real}...)),
N-quote
@nexprs $N dim-begin
@nexprs $N d-begin
if d==dim
$(matching(d))
else
$(notmatching(d))
end
end
end
end
)
eval(ex)
example(rand(2,2), 1.5, 0.7)
But this doesn’t work: I get ERROR: d not defined on $(matching(d)) (and,
if I comment that one out, $(nonmatching(d))). I’ve tried $(matching($d))
(ERROR:
error compiling anonymous: syntax: prefix $ in non-quoted expression) as
well as $(matching(esc(d))) and $(esc(matching(d))) (both ERROR: d not
defined), and I’m at a loss for what to try (these errors are all thrown at
the stage of *defining* the quoted expression, so macroexpand hasn’t helped
me here either, as I don’t get any expression to call it on…).
Eventually, this will be used to do different things for different array
dimensions like here, but with both matching and nonmatching also
dispatching on types of some additional arguments that I left out for
simplicity, and choosing expressions by means of multiple dispatch this way
is really at the core of Interpolations.jl, so I can’t move the contents of
matching and nonmatching out of their respective functions.
Thanks in advance for any ideas that get me forward,
// Tomas
Re: [julia-users] Julia for mobile app development
In principle, although last time I checked Apple doesn't allow apps to use JIT compilation, so we'd need fully static compilation first. I don't know exactly what the precompilation roadmap looks like, but my understanding is that static binaries will rely on the Julia runtime / JIT, at least to begin with. On 30 December 2014 at 16:55, Spencer Russell spencer.f.russ...@gmail.com wrote: Once it's running on ARM it should be possible to use the C API to call into Julia code from ObjC, right? I suppose that doesn't address the OP question about GUI dev in Julia, but at least using Julia for compute within a mobile app should be pretty feasible in the not-so-distant future. peace, s On Tue, Dec 30, 2014 at 9:50 AM, Mike Innes mike.j.in...@gmail.com wrote: I hope we'll one day have ObjectiveC.jl running on iOS, but that day is a long way off. On 30 December 2014 at 02:06, Stefan Karpinski ste...@karpinski.org wrote: You'd have to get Julia running on a mobile phone first, which we may be getting close to but as far as I know has not been accomplished yet. On Mon, Dec 29, 2014 at 8:18 PM, ccsv.1056...@gmail.com wrote: Are there any package in the works for an NUI or some mobile GUI for Julia?
Re: [julia-users] Julia for mobile app development
Bummer. Some quick googling seems to confirm that Apple still doesn't allow JIT-compiled code. They do allow interpreted code, but only if the code is shipped with the app and not loaded from elsewhere. Can you clarify static binaries will rely on the Julia runtime / JIT, at least to begin with? If I understand the Apple rules, basically it will disallow jumping to any dynamically-generated code. So the Julia runtime shouldn't pose a problem, as long as the executable code isn't generated on the fly. peace, s On Tue, Dec 30, 2014 at 12:09 PM, Mike Innes mike.j.in...@gmail.com wrote: In principle, although last time I checked Apple doesn't allow apps to use JIT compilation, so we'd need fully static compilation first. I don't know exactly what the precompilation roadmap looks like, but my understanding is that static binaries will rely on the Julia runtime / JIT, at least to begin with. On 30 December 2014 at 16:55, Spencer Russell spencer.f.russ...@gmail.com wrote: Once it's running on ARM it should be possible to use the C API to call into Julia code from ObjC, right? I suppose that doesn't address the OP question about GUI dev in Julia, but at least using Julia for compute within a mobile app should be pretty feasible in the not-so-distant future. peace, s On Tue, Dec 30, 2014 at 9:50 AM, Mike Innes mike.j.in...@gmail.com wrote: I hope we'll one day have ObjectiveC.jl running on iOS, but that day is a long way off. On 30 December 2014 at 02:06, Stefan Karpinski ste...@karpinski.org wrote: You'd have to get Julia running on a mobile phone first, which we may be getting close to but as far as I know has not been accomplished yet. On Mon, Dec 29, 2014 at 8:18 PM, ccsv.1056...@gmail.com wrote: Are there any package in the works for an NUI or some mobile GUI for Julia?
Re: [julia-users] Julia for mobile app development
:-) Well what is called julia runtime does exactly that: generate code on the fly (just in time) Julia currently has no interpreter but Jameson has some experimental code to use an LLVM interpreter Tobi Am Dienstag, 30. Dezember 2014 18:22:54 UTC+1 schrieb Spencer Russell: Bummer. Some quick googling seems to confirm that Apple still doesn't allow JIT-compiled code. They do allow interpreted code, but only if the code is shipped with the app and not loaded from elsewhere. Can you clarify static binaries will rely on the Julia runtime / JIT, at least to begin with? If I understand the Apple rules, basically it will disallow jumping to any dynamically-generated code. So the Julia runtime shouldn't pose a problem, as long as the executable code isn't generated on the fly. peace, s On Tue, Dec 30, 2014 at 12:09 PM, Mike Innes mike.j...@gmail.com javascript: wrote: In principle, although last time I checked Apple doesn't allow apps to use JIT compilation, so we'd need fully static compilation first. I don't know exactly what the precompilation roadmap looks like, but my understanding is that static binaries will rely on the Julia runtime / JIT, at least to begin with. On 30 December 2014 at 16:55, Spencer Russell spencer@gmail.com javascript: wrote: Once it's running on ARM it should be possible to use the C API to call into Julia code from ObjC, right? I suppose that doesn't address the OP question about GUI dev in Julia, but at least using Julia for compute within a mobile app should be pretty feasible in the not-so-distant future. peace, s On Tue, Dec 30, 2014 at 9:50 AM, Mike Innes mike.j...@gmail.com javascript: wrote: I hope we'll one day have ObjectiveC.jl running on iOS, but that day is a long way off. On 30 December 2014 at 02:06, Stefan Karpinski ste...@karpinski.org javascript: wrote: You'd have to get Julia running on a mobile phone first, which we may be getting close to but as far as I know has not been accomplished yet. On Mon, Dec 29, 2014 at 8:18 PM, ccsv.1...@gmail.com javascript: wrote: Are there any package in the works for an NUI or some mobile GUI for Julia?
[julia-users] Re: in-place copying mutable vs immutable
If you also want to look at the implementation of a function, the @less and @edit macros is very time saving alternatives to @which. kl. 15:34:56 UTC+1 tirsdag 30. desember 2014 skrev Steven G. Johnson følgende: Note that the PriorityQueue type in Base may do what you want.
Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.
On Tue, Dec 30, 2014 at 12:11 AM, Dan Luu dan...@gmail.com wrote: If it helps clear the air, the specifics are that when I ask Stefan how something works the most common response I get is that I should ask you or the mailing list since it's your code and he doesn't really understand it. He could probably figure it out, but it's enough of a non-trivial effort that he always forwards me to someone else. You might object that I never actually emailed you, but that's because I've seen what happened Leah emailed you, with plenty of reminder emails, when she was working on her thesis and trying to figure out things that would help her finish her thesis. Most emails didn't get a response, even with a reminder or two, and I figured I'd get the same treatment since I don't even know you. I understand that you must be incredibly busy, between doing your own thesis and also being the most prolific contributor to Julia. But perhaps you can see why, in this case, I might not expect my questions to be received with gratitude. Sending questions or issues directly to maintainers of open source projects that could be posted in public on mailing lists or issue trackers is inconsiderate – both to the person you're asking and to all the people who might have been interested, now or in the future, but who are excluded from your private conversation. If you post a question or problem on julia-dev, julia-users, or GitHub (or StackOverflow or Quora), there's a decent chance that I will answer it or at least chime in. There is also a large chance that someone else will answer the question instead, relieving me of that effort – and there's a very large chance that their answer will be better that the one I would have given. That discussion will also be there in the future for others to see. Perhaps most importantly, it's not uncommon for these discussions to spur action – and usually I'm not the one acting. When you email me directly, you are forcing me to be the one to act. So my action is is this: I will tell you to post it in public, basically regardless of what the question is. If there's something that needs to be discussed privately, no problem, but all of these things were clearly not in that category.
Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.
+1 to everything Stefan said. Even for internals arcana, by a quick headcount there are (at very least) 10-15 people not named Jeff who have spent significant time in various parts of src/ and can point people in the right direction on questions about almost everything except (possibly) type inference --- all of whom are fairly active on the mailing lists. So the odds of getting an answer here are good, as evidenced by a number of recent discussions on -dev. There are certainly some misses, but bumping unanswered questions after a day or three is fine -- preferably along with some brief sketch of current understanding and in some cases a more focused question to get things going, such as what is this struct for or where do I set a breakpoint to watch this behavior. On Tue, Dec 30, 2014 at 1:52 PM, Stefan Karpinski ste...@karpinski.org wrote: On Tue, Dec 30, 2014 at 12:11 AM, Dan Luu dan...@gmail.com wrote: If it helps clear the air, the specifics are that when I ask Stefan how something works the most common response I get is that I should ask you or the mailing list since it's your code and he doesn't really understand it. He could probably figure it out, but it's enough of a non-trivial effort that he always forwards me to someone else. You might object that I never actually emailed you, but that's because I've seen what happened Leah emailed you, with plenty of reminder emails, when she was working on her thesis and trying to figure out things that would help her finish her thesis. Most emails didn't get a response, even with a reminder or two, and I figured I'd get the same treatment since I don't even know you. I understand that you must be incredibly busy, between doing your own thesis and also being the most prolific contributor to Julia. But perhaps you can see why, in this case, I might not expect my questions to be received with gratitude. Sending questions or issues directly to maintainers of open source projects that could be posted in public on mailing lists or issue trackers is inconsiderate – both to the person you're asking and to all the people who might have been interested, now or in the future, but who are excluded from your private conversation. If you post a question or problem on julia-dev, julia-users, or GitHub (or StackOverflow or Quora), there's a decent chance that I will answer it or at least chime in. There is also a large chance that someone else will answer the question instead, relieving me of that effort – and there's a very large chance that their answer will be better that the one I would have given. That discussion will also be there in the future for others to see. Perhaps most importantly, it's not uncommon for these discussions to spur action – and usually I'm not the one acting. When you email me directly, you are forcing me to be the one to act. So my action is is this: I will tell you to post it in public, basically regardless of what the question is. If there's something that needs to be discussed privately, no problem, but all of these things were clearly not in that category.
Re: [julia-users] Julia for mobile app development
We can do what Mike described above with --compile=all. That will generate at least working code for everything, with the notable exception of staged functions. --compile=no will turn off the JIT. However something we still need to do is separate libjulia and libjulia-codegen, so there can be a version of the runtime that doesn't include LLVM. I'm not sure what to do about staged functions. I suppose in --compile=all mode, if a staged function throws an error then compilation should also stop with an error, instead of moving the call to runtime as usual. On Tue, Dec 30, 2014 at 1:23 PM, Tobias Knopp tobias.kn...@googlemail.com wrote: :-) Well what is called julia runtime does exactly that: generate code on the fly (just in time) Julia currently has no interpreter but Jameson has some experimental code to use an LLVM interpreter Tobi Am Dienstag, 30. Dezember 2014 18:22:54 UTC+1 schrieb Spencer Russell: Bummer. Some quick googling seems to confirm that Apple still doesn't allow JIT-compiled code. They do allow interpreted code, but only if the code is shipped with the app and not loaded from elsewhere. Can you clarify static binaries will rely on the Julia runtime / JIT, at least to begin with? If I understand the Apple rules, basically it will disallow jumping to any dynamically-generated code. So the Julia runtime shouldn't pose a problem, as long as the executable code isn't generated on the fly. peace, s On Tue, Dec 30, 2014 at 12:09 PM, Mike Innes mike.j...@gmail.com wrote: In principle, although last time I checked Apple doesn't allow apps to use JIT compilation, so we'd need fully static compilation first. I don't know exactly what the precompilation roadmap looks like, but my understanding is that static binaries will rely on the Julia runtime / JIT, at least to begin with. On 30 December 2014 at 16:55, Spencer Russell spencer@gmail.com wrote: Once it's running on ARM it should be possible to use the C API to call into Julia code from ObjC, right? I suppose that doesn't address the OP question about GUI dev in Julia, but at least using Julia for compute within a mobile app should be pretty feasible in the not-so-distant future. peace, s On Tue, Dec 30, 2014 at 9:50 AM, Mike Innes mike.j...@gmail.com wrote: I hope we'll one day have ObjectiveC.jl running on iOS, but that day is a long way off. On 30 December 2014 at 02:06, Stefan Karpinski ste...@karpinski.org wrote: You'd have to get Julia running on a mobile phone first, which we may be getting close to but as far as I know has not been accomplished yet. On Mon, Dec 29, 2014 at 8:18 PM, ccsv.1...@gmail.com wrote: Are there any package in the works for an NUI or some mobile GUI for Julia?
Re: [julia-users] Julia for mobile app development
You could use the method tracking approach to deal with staged functions, too. Say you include running tests as a compilation step. You compile what you can, run the tests with jit enabled (which generates a bunch of specialised code, including for staged functions), then dump that code in a binary. That could greatly benefit the startup time of compiled code, since if you have good tests you'll barely need the JIT at runtime at all. Which then means you can remove the JIT without sacrificing performance. How does that sound? On 30 Dec 2014 20:10, Jeff Bezanson jeff.bezan...@gmail.com wrote: We can do what Mike described above with --compile=all. That will generate at least working code for everything, with the notable exception of staged functions. --compile=no will turn off the JIT. However something we still need to do is separate libjulia and libjulia-codegen, so there can be a version of the runtime that doesn't include LLVM. I'm not sure what to do about staged functions. I suppose in --compile=all mode, if a staged function throws an error then compilation should also stop with an error, instead of moving the call to runtime as usual. On Tue, Dec 30, 2014 at 1:23 PM, Tobias Knopp tobias.kn...@googlemail.com wrote: :-) Well what is called julia runtime does exactly that: generate code on the fly (just in time) Julia currently has no interpreter but Jameson has some experimental code to use an LLVM interpreter Tobi Am Dienstag, 30. Dezember 2014 18:22:54 UTC+1 schrieb Spencer Russell: Bummer. Some quick googling seems to confirm that Apple still doesn't allow JIT-compiled code. They do allow interpreted code, but only if the code is shipped with the app and not loaded from elsewhere. Can you clarify static binaries will rely on the Julia runtime / JIT, at least to begin with? If I understand the Apple rules, basically it will disallow jumping to any dynamically-generated code. So the Julia runtime shouldn't pose a problem, as long as the executable code isn't generated on the fly. peace, s On Tue, Dec 30, 2014 at 12:09 PM, Mike Innes mike.j...@gmail.com wrote: In principle, although last time I checked Apple doesn't allow apps to use JIT compilation, so we'd need fully static compilation first. I don't know exactly what the precompilation roadmap looks like, but my understanding is that static binaries will rely on the Julia runtime / JIT, at least to begin with. On 30 December 2014 at 16:55, Spencer Russell spencer@gmail.com wrote: Once it's running on ARM it should be possible to use the C API to call into Julia code from ObjC, right? I suppose that doesn't address the OP question about GUI dev in Julia, but at least using Julia for compute within a mobile app should be pretty feasible in the not-so-distant future. peace, s On Tue, Dec 30, 2014 at 9:50 AM, Mike Innes mike.j...@gmail.com wrote: I hope we'll one day have ObjectiveC.jl running on iOS, but that day is a long way off. On 30 December 2014 at 02:06, Stefan Karpinski ste...@karpinski.org wrote: You'd have to get Julia running on a mobile phone first, which we may be getting close to but as far as I know has not been accomplished yet. On Mon, Dec 29, 2014 at 8:18 PM, ccsv.1...@gmail.com wrote: Are there any package in the works for an NUI or some mobile GUI for Julia?
[julia-users] Re: Converting string to module type/Programmatically using modules
I get a different expression from parsing foo: julia versioninfo() Julia Version 0.3.3 Commit b24213b (2014-11-23 20:19 UTC) Platform Info: System: Linux (i686-pc-linux-gnu) CPU: Intel(R) Atom(TM) CPU N570 @ 1.66GHz WORD_SIZE: 32 BLAS: libblas LAPACK: liblapack LIBM: libm LLVM: libLLVM-3.3 julia parse(import foo) :($(Expr(:import, :foo))) julia parse(import foo, bar, baz) :($(Expr(:toplevel, :($(Expr(:import, :foo))), :($(Expr(:import, :bar))), :( $(Expr(:import, :baz)) This is returning the needed expression, but it's returning it like a function instead of executing it: julia macro dynamic_import(modules) quote ex = Expr(:toplevel) names = map(m - symbol(split(m, '.')[1]), $modules) for name in names push!(ex.args, Expr(:import, name)) end return ex end end julia @dynamic_import [Newton.jl, MyTest.jl] :($(Expr(:toplevel, :($(Expr(:import, :Newton))), :($(Expr(:import, :MyTest )) I thought I almost got this! :D El lunes, 29 de diciembre de 2014 21:45:45 UTC-6, Joshua Adelman escribió: I'm attempting to do some dynamic module loading and subsequent processing and can't quite figure something out. I think I have a reasonable (albeit maybe not idiomatic) mechanism for dynamically importing a set of modules. See my stackoverflow question and the subsequent self answer: http://stackoverflow.com/q/27696356/392949 My next question is, after I've dynamically/programmatically imported a bunch of modules, is there a way of iterating over that set of modules? Specifically, if I store the module names as strings (e.g. [mod00, mod01, mod02]) and each module contains some function `func` that isn't exported, how would I call `mod00.func()` if I only know the string mod00? I think this comes down to converting the string to a Module type, but I'm not sure and haven't come up with something workable after a few passes through the docs. Any suggestions would be very much appreciated. Josh
[julia-users] Re: Converting string to module type/Programmatically using modules
You don’t need the quote ... end block since you’re creating the expression manually using Expr objects. Removing that and changing $modules to modules.args should work alright I think. — Mike On Tuesday, 30 December 2014 22:52:55 UTC+2, Ismael VC wrote: I get a different expression from parsing foo: julia versioninfo() Julia Version 0.3.3 Commit b24213b (2014-11-23 20:19 UTC) Platform Info: System: Linux (i686-pc-linux-gnu) CPU: Intel(R) Atom(TM) CPU N570 @ 1.66GHz WORD_SIZE: 32 BLAS: libblas LAPACK: liblapack LIBM: libm LLVM: libLLVM-3.3 julia parse(import foo) :($(Expr(:import, :foo))) julia parse(import foo, bar, baz) :($(Expr(:toplevel, :($(Expr(:import, :foo))), :($(Expr(:import, :bar))), :($(Expr(:import, :baz)) This is returning the needed expression, but it's returning it like a function instead of executing it: julia macro dynamic_import(modules) quote ex = Expr(:toplevel) names = map(m - symbol(split(m, '.')[1]), $modules) for name in names push!(ex.args, Expr(:import, name)) end return ex end end julia @dynamic_import [Newton.jl, MyTest.jl] :($(Expr(:toplevel, :($(Expr(:import, :Newton))), :($(Expr(:import, : MyTest)) I thought I almost got this! :D El lunes, 29 de diciembre de 2014 21:45:45 UTC-6, Joshua Adelman escribió: I'm attempting to do some dynamic module loading and subsequent processing and can't quite figure something out. I think I have a reasonable (albeit maybe not idiomatic) mechanism for dynamically importing a set of modules. See my stackoverflow question and the subsequent self answer: http://stackoverflow.com/q/27696356/392949 My next question is, after I've dynamically/programmatically imported a bunch of modules, is there a way of iterating over that set of modules? Specifically, if I store the module names as strings (e.g. [mod00, mod01, mod02]) and each module contains some function `func` that isn't exported, how would I call `mod00.func()` if I only know the string mod00? I think this comes down to converting the string to a Module type, but I'm not sure and haven't come up with something workable after a few passes through the docs. Any suggestions would be very much appreciated. Josh
[julia-users] Re: Macro scoping (or hygiene?) problems
So I do not totally understand the goal of what you are trying to achieve,
but could you try to do this with a macro?
macro value(d)
@show d
quote
println(d at runtime , $d)
end
end
@ngenerate N T function example{T,N}(A::Array{T,N}, xs::NTuple{N,Real}...)
@nexprs N dim-begin
@nexprs N d-begin
@value(d)
end
end
end
example(rand(2,2), 1.5, 0.7)
So at least the value of d is know at the time when the macro value is run
and you could then call expression generating code based on that value.
dispatching on types of some additional arguments
That sounds like you should/could use staged functions for that.
On Tuesday, 30 December 2014 17:59:37 UTC+1, Tomas Lycken wrote:
I’m doing some metaprogramming for Interpolations.jl, and I’m getting
stuck at an error that I think is due to scoping issues in my nested
quotes, and I’ve stared at this for so long now I’m not getting anywhere.
I can do the following
matching(d) = quote
println(Matching: , $d)
end
nonmatching(d) = quote
println(Not matching: , $d)
end
@ngenerate N T function example{T,N}(A::Array{T,N}, xs::NTuple{N,Real}...)
@nexprs N dim-begin
@nexprs N d-begin
if d==dim
eval(matching(d))
else
eval(nonmatching(d))
end
end
end
end
example(rand(2,2), 1.5, 0.7)
and get the expected output:
Matching: 1
Not matching: 2
Not matching: 1
Matching: 2
Examining with macroexpand, I see that the eval calls are still there,
but for performance reasons I want to avoid them, so I try to rewrite it to
use eval(ngenerate(...)) instead of @ngenerate ...:
#matching and nonmatching defined as before
ex = ngenerate(
:N,
:T,
:(example{T,N}(A::Array{T,N}, xs::NTuple{N,Real}...)),
N-quote
@nexprs $N dim-begin
@nexprs $N d-begin
if d==dim
$(matching(d))
else
$(notmatching(d))
end
end
end
end
)
eval(ex)
example(rand(2,2), 1.5, 0.7)
But this doesn’t work: I get ERROR: d not defined on $(matching(d)) (and,
if I comment that one out, $(nonmatching(d))). I’ve tried $(matching($d))
(ERROR: error compiling anonymous: syntax: prefix $ in non-quoted
expression) as well as $(matching(esc(d))) and $(esc(matching(d))) (both
ERROR:
d not defined), and I’m at a loss for what to try (these errors are all
thrown at the stage of *defining* the quoted expression, so macroexpand
hasn’t helped me here either, as I don’t get any expression to call it on…).
Eventually, this will be used to do different things for different array
dimensions like here, but with both matching and nonmatching also
dispatching on types of some additional arguments that I left out for
simplicity, and choosing expressions by means of multiple dispatch this way
is really at the core of Interpolations.jl, so I can’t move the contents of
matching and nonmatching out of their respective functions.
Thanks in advance for any ideas that get me forward,
// Tomas
[julia-users] Re: Converting string to module type/Programmatically using modules
Thank you Michael I got it! julia macro dynamic_import(modules) ex = Expr(:toplevel) names = map(m - symbol(split(m, '.')[1]), modules.args) for name in names push!(ex.args, Expr(:import, name)) end return ex end julia @dynamic_import [Newton.jl, MyTest.jl] julia Newton Newton julia MyTest MyTest El martes, 30 de diciembre de 2014 15:05:34 UTC-6, Michael Hatherly escribió: You don’t need the quote ... end block since you’re creating the expression manually using Expr objects. Removing that and changing $modules to modules.args should work alright I think. — Mike On Tuesday, 30 December 2014 22:52:55 UTC+2, Ismael VC wrote: I get a different expression from parsing foo: julia versioninfo() Julia Version 0.3.3 Commit b24213b (2014-11-23 20:19 UTC) Platform Info: System: Linux (i686-pc-linux-gnu) CPU: Intel(R) Atom(TM) CPU N570 @ 1.66GHz WORD_SIZE: 32 BLAS: libblas LAPACK: liblapack LIBM: libm LLVM: libLLVM-3.3 julia parse(import foo) :($(Expr(:import, :foo))) julia parse(import foo, bar, baz) :($(Expr(:toplevel, :($(Expr(:import, :foo))), :($(Expr(:import, :bar))), :($(Expr(:import, :baz)) This is returning the needed expression, but it's returning it like a function instead of executing it: julia macro dynamic_import(modules) quote ex = Expr(:toplevel) names = map(m - symbol(split(m, '.')[1]), $modules) for name in names push!(ex.args, Expr(:import, name)) end return ex end end julia @dynamic_import [Newton.jl, MyTest.jl] :($(Expr(:toplevel, :($(Expr(:import, :Newton))), :($(Expr(:import, : MyTest)) I thought I almost got this! :D El lunes, 29 de diciembre de 2014 21:45:45 UTC-6, Joshua Adelman escribió: I'm attempting to do some dynamic module loading and subsequent processing and can't quite figure something out. I think I have a reasonable (albeit maybe not idiomatic) mechanism for dynamically importing a set of modules. See my stackoverflow question and the subsequent self answer: http://stackoverflow.com/q/27696356/392949 My next question is, after I've dynamically/programmatically imported a bunch of modules, is there a way of iterating over that set of modules? Specifically, if I store the module names as strings (e.g. [mod00, mod01, mod02]) and each module contains some function `func` that isn't exported, how would I call `mod00.func()` if I only know the string mod00? I think this comes down to converting the string to a Module type, but I'm not sure and haven't come up with something workable after a few passes through the docs. Any suggestions would be very much appreciated. Josh
[julia-users] Re: Converting string to module type/Programmatically using modules
No prob. — Mike On Tuesday, 30 December 2014 23:13:01 UTC+2, Ismael VC wrote: Thank you Michael I got it! julia macro dynamic_import(modules) ex = Expr(:toplevel) names = map(m - symbol(split(m, '.')[1]), modules.args) for name in names push!(ex.args, Expr(:import, name)) end return ex end julia @dynamic_import [Newton.jl, MyTest.jl] julia Newton Newton julia MyTest MyTest El martes, 30 de diciembre de 2014 15:05:34 UTC-6, Michael Hatherly escribió: You don’t need the quote ... end block since you’re creating the expression manually using Expr objects. Removing that and changing $modules to modules.args should work alright I think. — Mike On Tuesday, 30 December 2014 22:52:55 UTC+2, Ismael VC wrote: I get a different expression from parsing foo: julia versioninfo() Julia Version 0.3.3 Commit b24213b (2014-11-23 20:19 UTC) Platform Info: System: Linux (i686-pc-linux-gnu) CPU: Intel(R) Atom(TM) CPU N570 @ 1.66GHz WORD_SIZE: 32 BLAS: libblas LAPACK: liblapack LIBM: libm LLVM: libLLVM-3.3 julia parse(import foo) :($(Expr(:import, :foo))) julia parse(import foo, bar, baz) :($(Expr(:toplevel, :($(Expr(:import, :foo))), :($(Expr(:import, :bar ))), :($(Expr(:import, :baz)) This is returning the needed expression, but it's returning it like a function instead of executing it: julia macro dynamic_import(modules) quote ex = Expr(:toplevel) names = map(m - symbol(split(m, '.')[1]), $modules) for name in names push!(ex.args, Expr(:import, name)) end return ex end end julia @dynamic_import [Newton.jl, MyTest.jl] :($(Expr(:toplevel, :($(Expr(:import, :Newton))), :($(Expr(:import, : MyTest)) I thought I almost got this! :D El lunes, 29 de diciembre de 2014 21:45:45 UTC-6, Joshua Adelman escribió: I'm attempting to do some dynamic module loading and subsequent processing and can't quite figure something out. I think I have a reasonable (albeit maybe not idiomatic) mechanism for dynamically importing a set of modules. See my stackoverflow question and the subsequent self answer: http://stackoverflow.com/q/27696356/392949 My next question is, after I've dynamically/programmatically imported a bunch of modules, is there a way of iterating over that set of modules? Specifically, if I store the module names as strings (e.g. [mod00, mod01, mod02]) and each module contains some function `func` that isn't exported, how would I call `mod00.func()` if I only know the string mod00? I think this comes down to converting the string to a Module type, but I'm not sure and haven't come up with something workable after a few passes through the docs. Any suggestions would be very much appreciated. Josh
[julia-users] Re: Converting string to module type/Programmatically using modules
Joshua 've updated your question on Stack Overflow: http://bit.ly/1wz5n5U You could also generalize this line: module_files = filter(r^mod[0-9][0-9].jl$, readdir()) By abstracting it into a function: julia module_files(dir=.) = filter(r^mod[0-9][0-9].jl$, readdir(dir)) module_files (generic function with 2 methods) So you may use it like this: julia @dynamic_import module_files() Cheers! Ismael VC El lunes, 29 de diciembre de 2014 21:45:45 UTC-6, Joshua Adelman escribió: I'm attempting to do some dynamic module loading and subsequent processing and can't quite figure something out. I think I have a reasonable (albeit maybe not idiomatic) mechanism for dynamically importing a set of modules. See my stackoverflow question and the subsequent self answer: http://stackoverflow.com/q/27696356/392949 My next question is, after I've dynamically/programmatically imported a bunch of modules, is there a way of iterating over that set of modules? Specifically, if I store the module names as strings (e.g. [mod00, mod01, mod02]) and each module contains some function `func` that isn't exported, how would I call `mod00.func()` if I only know the string mod00? I think this comes down to converting the string to a Module type, but I'm not sure and haven't come up with something workable after a few passes through the docs. Any suggestions would be very much appreciated. Josh
Re: [julia-users] Julia for mobile app development
Yes, that is a good approach to static compiling, but it doesn't fully handle staged functions unless you're sure the tests cover all paths and all possible types. If you miss a case, for normal functions the worst that can happen is a slowdown due to using unspecialized code. For staged functions, there is nothing to call, unless all staged functions always return something for (Any...). On Tue, Dec 30, 2014 at 3:47 PM, Mike Innes mike.j.in...@gmail.com wrote: You could use the method tracking approach to deal with staged functions, too. Say you include running tests as a compilation step. You compile what you can, run the tests with jit enabled (which generates a bunch of specialised code, including for staged functions), then dump that code in a binary. That could greatly benefit the startup time of compiled code, since if you have good tests you'll barely need the JIT at runtime at all. Which then means you can remove the JIT without sacrificing performance. How does that sound? On 30 Dec 2014 20:10, Jeff Bezanson jeff.bezan...@gmail.com wrote: We can do what Mike described above with --compile=all. That will generate at least working code for everything, with the notable exception of staged functions. --compile=no will turn off the JIT. However something we still need to do is separate libjulia and libjulia-codegen, so there can be a version of the runtime that doesn't include LLVM. I'm not sure what to do about staged functions. I suppose in --compile=all mode, if a staged function throws an error then compilation should also stop with an error, instead of moving the call to runtime as usual. On Tue, Dec 30, 2014 at 1:23 PM, Tobias Knopp tobias.kn...@googlemail.com wrote: :-) Well what is called julia runtime does exactly that: generate code on the fly (just in time) Julia currently has no interpreter but Jameson has some experimental code to use an LLVM interpreter Tobi Am Dienstag, 30. Dezember 2014 18:22:54 UTC+1 schrieb Spencer Russell: Bummer. Some quick googling seems to confirm that Apple still doesn't allow JIT-compiled code. They do allow interpreted code, but only if the code is shipped with the app and not loaded from elsewhere. Can you clarify static binaries will rely on the Julia runtime / JIT, at least to begin with? If I understand the Apple rules, basically it will disallow jumping to any dynamically-generated code. So the Julia runtime shouldn't pose a problem, as long as the executable code isn't generated on the fly. peace, s On Tue, Dec 30, 2014 at 12:09 PM, Mike Innes mike.j...@gmail.com wrote: In principle, although last time I checked Apple doesn't allow apps to use JIT compilation, so we'd need fully static compilation first. I don't know exactly what the precompilation roadmap looks like, but my understanding is that static binaries will rely on the Julia runtime / JIT, at least to begin with. On 30 December 2014 at 16:55, Spencer Russell spencer@gmail.com wrote: Once it's running on ARM it should be possible to use the C API to call into Julia code from ObjC, right? I suppose that doesn't address the OP question about GUI dev in Julia, but at least using Julia for compute within a mobile app should be pretty feasible in the not-so-distant future. peace, s On Tue, Dec 30, 2014 at 9:50 AM, Mike Innes mike.j...@gmail.com wrote: I hope we'll one day have ObjectiveC.jl running on iOS, but that day is a long way off. On 30 December 2014 at 02:06, Stefan Karpinski ste...@karpinski.org wrote: You'd have to get Julia running on a mobile phone first, which we may be getting close to but as far as I know has not been accomplished yet. On Mon, Dec 29, 2014 at 8:18 PM, ccsv.1...@gmail.com wrote: Are there any package in the works for an NUI or some mobile GUI for Julia?
Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.
On Tuesday, December 30, 2014 5:02:00 PM UTC-5, Jim Garrison wrote: Part of the reason I was inclined to think that exceptions are unsupported is that I often see my code segfault if I create an exception e.g. by pressing Ctrl+C. For instance, if I open the REPL, and type julia x = rand(4000,4000) julia x * x and press Ctrl+C during execution, I nearly always get a segfault. In Python I almost never see a segfault as an exception unwinds (and when I do, I file a bug). But in Julia it seems to be the norm for me. I'm not seeing a segfault in this particular case on my machine, but in general the difficulty is that external C libraries (such as openblas) are rarely interrupt-safe: stopping them at a random part and then restarting the function call will often crash. My suggestion has been to defer ctrl-c interrupts (SIGINT signals) around external C calls (ccall), but this has not been implemented yet: https://github.com/JuliaLang/julia/issues/2622 (My understanding is that Python similarly disables interrupts in external C library: http://stackoverflow.com/questions/14271697/ctrlc-doesnt-interrupt-call-to-shared-library-using-ctypes-in-python) And when I run the release-0.3 branch under valgrind (even something as simple as the empty script `julia -e `), the results can be somewhat scary (at least that is my interpretation). Valgrind tends to report false positives in language runtimes using mark-and-sweep garbage collection, if I recall correctly Steven
Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.
And when I run the release-0.3 branch under valgrind (even something as simple as the empty script `julia -e `), the results can be somewhat scary (at least that is my interpretation). Valgrind tends to report false positives in language runtimes using mark-and-sweep garbage collection, if I recall correctly The valgrind issues I saw last time I ran it (2 mo. ago) were mostly (possibly all) missing suppressions for core calls like memcpy. I haven't yet tried with the latest valgrind version as suggested here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758905 On Tue, Dec 30, 2014 at 5:27 PM, Steven G. Johnson stevenj@gmail.com wrote: On Tuesday, December 30, 2014 5:02:00 PM UTC-5, Jim Garrison wrote: Part of the reason I was inclined to think that exceptions are unsupported is that I often see my code segfault if I create an exception e.g. by pressing Ctrl+C. For instance, if I open the REPL, and type julia x = rand(4000,4000) julia x * x and press Ctrl+C during execution, I nearly always get a segfault. In Python I almost never see a segfault as an exception unwinds (and when I do, I file a bug). But in Julia it seems to be the norm for me. I'm not seeing a segfault in this particular case on my machine, but in general the difficulty is that external C libraries (such as openblas) are rarely interrupt-safe: stopping them at a random part and then restarting the function call will often crash. My suggestion has been to defer ctrl-c interrupts (SIGINT signals) around external C calls (ccall), but this has not been implemented yet: https://github.com/JuliaLang/julia/issues/2622 (My understanding is that Python similarly disables interrupts in external C library: http://stackoverflow.com/questions/14271697/ctrlc-doesnt-interrupt-call-to-shared-library-using-ctypes-in-python ) And when I run the release-0.3 branch under valgrind (even something as simple as the empty script `julia -e `), the results can be somewhat scary (at least that is my interpretation). Valgrind tends to report false positives in language runtimes using mark-and-sweep garbage collection, if I recall correctly Steven
Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.
Just my two cents here Jim but I've been using v0.4 (usually updated daily) extensively since the summer and have only run into one segfault (which sat very firmly in I'm doing something stupidly unsafe here territory). I would argue that if you run into a segfault Julia is definitely not behaving and you should file an issue. On Tuesday, 30 December 2014 22:02:00 UTC, Jim Garrison wrote: On Monday, December 29, 2014 9:27:41 PM UTC-5, Stefan Karpinski wrote: On Mon, Dec 29, 2014 at 9:07 PM, jrgar...@gmail.com wrote: I would really like if I could throw and catch an exception without needing to consider that my program might panic as a result of doing so. I just looked through the entire corpus of Julia code I have written so far, and the only places I catch exceptions are when the exception is actually due to calling a Python API via PyCall. I am willing to accept that using exceptions is not a very Julian way of doing things, but I still want them to work when they are needed. Panic is the Go term for throw. Your Julia program will not panic if you throw an exception – throw/catch works just fine. Stefan, I misunderstood so thank you for the clarification. Part of the reason I was inclined to think that exceptions are unsupported is that I often see my code segfault if I create an exception e.g. by pressing Ctrl+C. For instance, if I open the REPL, and type julia x = rand(4000,4000) julia x * x and press Ctrl+C during execution, I nearly always get a segfault. In Python I almost never see a segfault as an exception unwinds (and when I do, I file a bug). But in Julia it seems to be the norm for me. Somewhat related, I also experience intermittent segfaults on exit on a cluster I use at UCSB unless I set OPENBLAS_NUM_THREADS=1. (I'd like to get a stack trace on this and file a real bug, but I've been unable so far to find where the core dumps disappear to even with sysadmin help, and the problem goes away when I run julia under gdb). And when I run the release-0.3 branch under valgrind (even something as simple as the empty script `julia -e `), the results can be somewhat scary (at least that is my interpretation). Together these things imply to me that not enough effort/testing is being put into ensuring that resources are cleaned up correctly as julia terminates, but I'm curious if others have different takes on this. I've been using Julia since September and overall I feel like I am hitting real bugs at a much higher rate than a few per year (and can in that sense relate to Dan's post). But for me Julia has made me so much more productive that even dealing with these issues is more fun (and productive) than my former days of using C++. As such, I'd really like to do what I can to ensure overall trend is heading in the direction of increased stability over time. I have a few ideas for things to do, but am curious to know first what people think of my above assessment.
[julia-users] Re: [ANN] SQLite.jl package update
Do you think it would make sense to extract some common functionality and function names in a DB package? There was some discussion about that here https://github.com/JuliaDB/DBDSQLite.jl/issues/1 but the problem is SQLite.jl is currently slightly too SQLite-specific for this to be an easy task and I don't think any of us really have the impetus to do it. No harm opening an issue though if it's something you're interested in. Heck you could even give it a go yourself if you want. Great work! Thanks! On Monday, 29 December 2014 16:39:01 UTC, Valentin Churavy wrote: Great work! Do you think it would make sense to extract some common functionality and function names in a DB package? There is https://github.com/JuliaDB/DBI.jl . I like the interface you provided and would like to use parts of it for the Postgres driver I am working on. - Valentin On Monday, 29 December 2014 07:57:20 UTC+1, Jacob Quinn wrote: Hey all, We've been working on a fairly major upgrade of the SQLite.jl package over the last few months and are happy to announce a new release. This is a breaking change with the most recent tagged version in METADATA, so if you wish to stay on the old API version, just run `Pkg.pin(SQLite)`. Otherwise, to see the updates, you can simply run `Pkg.update()` if the `SQLite.jl` package is already installed, or run `Pkg.add(SQLite)` to install the package for the first time. The newer package boasts some great updates including a more Julian interface (the older package was modeled after the sqldf R package), the removal of DataFrames dependency making the package much more lightweight, but still easy to feed the new `SQLite.ResultSet` type into a DataFrame; there are also some awesome features allowing the use of custom julia scalar and aggregate functions in SQL statements by registering the julia function. Usage of custom Julia types is also supported for storing and loading in SQL tables (using the serialization interface). We've tried to put in many more tests and push the docs further along, but are of course always looking to improve. For those unfamiliar, SQLite is a lightweight, relational database system easy to run on a local machine. It's extremely handy for working with medium to large datasets that still fit on a single machine (MBs to GBs). It supports SQL statements to create, update, and delete relational tables, as well as select statements to perform calculations, or subset specific datasets. -Jacob Quinn and Sean Marshallsay
[julia-users] Re: Using Julia with other (GC) languages
You can interact with GCed languages by writing C like Julia, i.e. working with c_malloc and c_free directly. It's not exactly the nicest way of working but doing that will avoid the garbage collector. On Friday, 26 December 2014 22:54:28 UTC, Páll Haraldsson wrote: I know you can call C from Julia and therefore most other (non-GC) languages. And with embedding, vice versa. Of course you always can call other languages, say with RPC etc. but wander what the limitations are to call directly. It seems to me you can call C because it is not a garbage-controlled language. And when embedding Julia in C then you get the whole runtime and it is similar to embedding Prolog in C. I've just not looked to much into embedding. Would you say calling in that direction is more difficult because of it or some other reason? It seems to me you would want Julia to be the master language on top because it has GC (and is the more powerful language). In theory, calling other GC languages such as Java or C# should be possible but not in practice (without copying/RPC) because you can have only on GC, right? Still calling Python is possible, because it uses reference counting, not true GC? But it also has GC for cycles. So maybe there is no difficulty with GC or is that part just disabled? And: I know about the current situation with calling C++. For old Python code (even on Windows) and numpy (or whatever) that calls C++ (Microsoft's Visual Studio), since Julia can call Python, should there really be any reason for it be difficult to call C++ if it is only indirectly? Best regards, Palli.
Re: [julia-users] Re: [ANN] SQLite.jl package update
Yeah, I'd say there's definite interest in providing a DBI interface. See the link Sean posted for more of the discussion. It's on my to-do list :) -Jacob On Tue, Dec 30, 2014 at 4:12 PM, Sean Marshallsay srm.1...@gmail.com wrote: Do you think it would make sense to extract some common functionality and function names in a DB package? There was some discussion about that here https://github.com/JuliaDB/DBDSQLite.jl/issues/1 but the problem is SQLite.jl is currently slightly too SQLite-specific for this to be an easy task and I don't think any of us really have the impetus to do it. No harm opening an issue though if it's something you're interested in. Heck you could even give it a go yourself if you want. Great work! Thanks! On Monday, 29 December 2014 16:39:01 UTC, Valentin Churavy wrote: Great work! Do you think it would make sense to extract some common functionality and function names in a DB package? There is https://github.com/JuliaDB/ DBI.jl. I like the interface you provided and would like to use parts of it for the Postgres driver I am working on. - Valentin On Monday, 29 December 2014 07:57:20 UTC+1, Jacob Quinn wrote: Hey all, We've been working on a fairly major upgrade of the SQLite.jl package over the last few months and are happy to announce a new release. This is a breaking change with the most recent tagged version in METADATA, so if you wish to stay on the old API version, just run `Pkg.pin(SQLite)`. Otherwise, to see the updates, you can simply run `Pkg.update()` if the `SQLite.jl` package is already installed, or run `Pkg.add(SQLite)` to install the package for the first time. The newer package boasts some great updates including a more Julian interface (the older package was modeled after the sqldf R package), the removal of DataFrames dependency making the package much more lightweight, but still easy to feed the new `SQLite.ResultSet` type into a DataFrame; there are also some awesome features allowing the use of custom julia scalar and aggregate functions in SQL statements by registering the julia function. Usage of custom Julia types is also supported for storing and loading in SQL tables (using the serialization interface). We've tried to put in many more tests and push the docs further along, but are of course always looking to improve. For those unfamiliar, SQLite is a lightweight, relational database system easy to run on a local machine. It's extremely handy for working with medium to large datasets that still fit on a single machine (MBs to GBs). It supports SQL statements to create, update, and delete relational tables, as well as select statements to perform calculations, or subset specific datasets. -Jacob Quinn and Sean Marshallsay
Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.
On Mon, Dec 29, 2014 at 3:37 PM, Dan Luu dan...@gmail.com wrote: I have a stable .3 build I use for all my Julia scripts and IIRC that's where I saw the dates issue with Gadfly. I dunno, maybe I should only use older releases? This seems to be at odds with this claim in the blog post: When I worked around that I ran into a regression that caused plotting to break large parts of the core language https://github.com/JuliaLang/julia/issues/8631, so that data manipulation had to be done before plotting. That change only exists on master, not in the 0.3.x stable releases. So it seems likely that you were actually using the unstable development version of Julia when you encountered all of these problems. Otherwise you could not have encountered that bug.
Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.
On Tuesday, December 30, 2014 06:40:30 PM Stefan Karpinski wrote: That change only exists on master, not in the 0.3.x stable releases. So it seems likely that you were actually using the unstable development version of Julia when you encountered all of these problems. Otherwise you could not have encountered that bug. Actually, while that particular construction is only available in julia 0.4, it turned out upon deeper investigation that you can trigger the same bug on 0.3: see, for example, https://github.com/JuliaLang/Color.jl/issues/68 This is the issue (one of two, actually), that I branded convertalypse, and in my view it's one of the nastier bugs that has ever lurked this long in julia base: this definitely qualifies as a wart to be embarrassed about. It wasn't discovered until long after julia 0.3's release, unfortunately, and it has been extremely hard to track down. I tried 3 times myself (devoting big chunks of a day to it), and failed to make any real progress. Fortunately, within the last 24 hours, our superhero Jameson Nash seems to have just diagnosed the problem and proposed a fix. https://github.com/JuliaLang/julia/issues/8631#issuecomment-68336062. Hopefully the same fix will apply on julia 0.3, too. Best, --Tim
Re: [julia-users] Can I throw an error in c code just like Rcpp's stop() in Julia
Thanks! jl_error() is what I want here.
This might help:
http://docs.julialang.org/en/release-0.3/manual/embedding/#throwing-julia-exceptions
On Wed, Dec 24, 2014 at 10:41 PM, 良无 out...@gmail.com javascript:
wrote:
In C or C++ code, I have a function:
void funcname(...){
...
assert(0);
...
}
if I run `ccall((:funcname, libpath), Void, (...), ...)` in Julia , it
will terminate the Julia process.
How can I replace assert() with other function to throw an error in Julia?
ccall((:funcname, libpath), Void, (...), ...)
ERROR:
I am sorry that I can not make it clear, and I just come to Julia from
the R world.
Thanks. ;-)
I'm afraid I still don't get it. What do you want to do?
On Dec 24, 2014, at 8:15 PM, 良无 out...@gmail.com wrote:
If you want to release an R package to CRAN, R Core will force you to
check this by R CMD check:
- Compiled code should never terminate the R process within which it is
running. Thus C/C++ calls to assert/abort/exit, Fortran calls to STOP and
so on must be avoided. Nor may R code call q().
Le mercredi 24 décembre 2014 à 08:36 -0800, 良无 a écrit :
In my origin C++ code, I use assert(), but if I want to use this code
in Julia, maybe I need to replace it with other functions. In R, I
can
use Rcpp::stop(). Is there any easy way to do it in Julia with C or C
++ code.
IIUC, you want to raise a Julia exception from C code, right?
And it seems that Julia does not have R CMD check like stuff yet. It
does not check this kind of issue.
You mean, running a test suite? See
http://docs.julialang.org/en/latest/stdlib/test/
and how most packages do this, for example
https://github.com/JuliaStats/StatsBase.jl/tree/master/test
Regards
[julia-users] ANN: ApproxFun v0.05 with support for piecewise and singular functions
ApproxFun is a package for approximating functions and solving differential equations. ApproxFun v0.05 adds support for piecewise and singular functions. For example, we can sample a function with semicircle or other Jacobi singularities: x=Fun(identity,[-1,1]) sample(exp(x)*sqrt(1-x^2),100) sample((1-x)^0.123/(1+x)^0.567,100) Or integrate the absolute value of sin: x=Fun(identity,[-5,5]) sum(abs(sin(x))) Or even solve PDEs with discontinuous coefficients. Other improvements include 2-5x faster ODE solving, so that now an ODE requiring a million unknowns can be solved in one second, and preliminary support for high precision functions. Thanks go to Gustavo Goretkin (MIT) and Mikael Slevinsky (Oxford) for many contributions! Note: Julia v0.4 is not supported due to issue #9378
Re: [julia-users] Re: Julia v0.3.4
The Homebrew tap https://github.com/staticfloat/homebrew-julia now has a bottled version of 0.3.4 available. -E On Sun, Dec 28, 2014 at 11:30 PM, i.costi...@me.com wrote: When is v0.3.4 likely to be available on homebrew? On Monday, 29 December 2014 13:30:21 UTC+11, Elliot Saba wrote: All I can think of is that I fixed it and then re-uploaded the old broken .dmg. I'm sorry for all the wasted time here, please try again https://s3.amazonaws.com/julialang/bin/osx/x64/0.3/julia-0.3.4-osx10.7+.dmg, it should work now. -E On Sun, Dec 28, 2014 at 2:50 PM, Stefan Karpinski ste...@karpinski.org wrote: We went through a fairly tedious and time-consuming process to get OS X developer licenses specifically so you wouldn't have to do that sort of thing so hopefully this can be fixed. Elliot, do you need me to do anything here? On Sun, Dec 28, 2014 at 3:59 PM, Christoph Ortner christop...@gmail.com wrote: If I allow apps from anywhere in security and privacy settings, then it works ok. (I guess this is what you called Gatekeeper?) Christoph
Re: [julia-users] Dan Luu's critique of Julia: needs commented code, better testing, error handling, and bugs fixed.
I haven't quite fixed it yet, although I've pushed it from the realm of a heisenbug to an issue with the return value of typeintersect for some specific inputs. I'm guessing however that this is one question where Jeff's expertise (in type system design) is rather critical, over emailing a distribution list (although all the information I've gather is on the issue tracker, if there's a lurking type-theorist on this list)... :) On Tue Dec 30 2014 at 9:29:57 PM Stefan Karpinski stefan.karpin...@gmail.com wrote: Ah, that's good to know. Even better that Jameson may have fixed it! On Dec 30, 2014, at 8:10 PM, Tim Holy tim.h...@gmail.com wrote: On Tuesday, December 30, 2014 06:40:30 PM Stefan Karpinski wrote: That change only exists on master, not in the 0.3.x stable releases. So it seems likely that you were actually using the unstable development version of Julia when you encountered all of these problems. Otherwise you could not have encountered that bug. Actually, while that particular construction is only available in julia 0.4, it turned out upon deeper investigation that you can trigger the same bug on 0.3: see, for example, https://github.com/JuliaLang/Color.jl/issues/68 This is the issue (one of two, actually), that I branded convertalypse, and in my view it's one of the nastier bugs that has ever lurked this long in julia base: this definitely qualifies as a wart to be embarrassed about. It wasn't discovered until long after julia 0.3's release, unfortunately, and it has been extremely hard to track down. I tried 3 times myself (devoting big chunks of a day to it), and failed to make any real progress. Fortunately, within the last 24 hours, our superhero Jameson Nash seems to have just diagnosed the problem and proposed a fix. https://github.com/JuliaLang/julia/issues/8631#issuecomment-68336062. Hopefully the same fix will apply on julia 0.3, too. Best, --Tim
Re: [julia-users] ldltfact factorization for symmetric matrices
It does look like ldltfact is only defined for SymTridiagonal at the
moment. You're welcome to open an issue about implementing the LDLt
Cholesky for general matrices.
On Tue Dec 30 2014 at 11:49:30 AM Giovanni Maria Marchetti
giovanni.m.marche...@gmail.com wrote:
The help for ldltfact says:
Base.ldltfact(A) - LDLtFactorization
Compute a factorization of a positive definite matrix A such
that A=L*Diagonal(d)*L' where L is a unit lower triangular
matrix and d is a vector with non-negative elements.
But for a general positive definite matrix it does not work.
In fact the header of the function is
function ldltfact{T}(M::SymTridiagonal{T})
Or I miss something?
Giovanni
