Hi there,
I'd like to load a custom module from a custom location. In order to do
this via import/using I need to first put include(moduleFile.jl) statement.
Every time I have include() in more then one file I get: Warning: replacing
module.
The custom module is in the same location as my main
Le jeudi 25 décembre 2014 à 23:32 -0800, ele...@gmail.com a écrit :
I had thought that top level == global, but Milan's statement:
No, `global n` is only needed when `n` is in the global scope. Here `n`
is not global, it's local to the enclosing scope.
suggests its not the case.
You'll need to use `@compat` in v0.3.3:
julia Dict(zip(abc,123))
ERROR: `Dict{K,V}` has no method matching Dict{K,V}(::Zip2{ASCIIString,
ASCIIString})
julia using Compat
julia @compat Dict(zip(abc,123))
Dict{Char,Char} with 3 entries:
'c' = '3'
'b' = '2'
'a' = '1'
Hello,
I have a function, Solve(Data::DataFrame, Method::String), where I do some
math operations on Data, but these operations are vastly different for each
Method. I call one function, Solve, because I don't want to obfuscate my
code when I'm calling this.
So that leaves me with sorting out
How about making a type for your solver methods like so
immutable Method{Name}
para1::Int
para2::Float64
...
end
method_a = Method{:A}(p1, p2, ...)
method_b = Method{:B}(p1, p2, ...)
# Then the solve function could be
function solve(data::DataFrame, method::Method{:A})
#
This is great!
transifex looks good, and I wish you the best of luck. I'm no use in
Spanish or German, but if I see a great (updated) manual in a few languages
in 6 month time, I might look into translating to Norwegian.
I just want to give a word of warning that the Julia documentation isn't
No, the release-0.3 branch (that we tag 0.3.x releases from) only receives
bug fixes that (hopefully) doesn't break backward compatibility. Everything
is captured in the Numerous bugfixes bullet.
You can look at the list of commits
We have not been doing a very good job of updating NEWS.md on the
release-0.3 branch, so there's nothing specific. Lots of bug fixes have
been getting backported, you can compare the commit list
via https://github.com/JuliaLang/julia/compare/v0.3.0...v0.3.1 or similar
url's.
On Thursday,
I should point out that although Tony answered your question for looking at
0.3.1 vs. 0.3.0, we are just now releasing 0.3.4, so you can substitute the
0.3.1 with 0.3.4 in the URL linked above for the same effect.
-E
On Fri, Dec 26, 2014 at 3:03 AM, Tony Kelman t...@kelman.net wrote:
We have
Hello all! The latest bugfix release of the 0.3.X Julia line has been
released. Binaries are available from the usual place
http://julialang.org/downloads/, and as is typical with such things,
please report all issues to either the issue tracker
https://github.com/JuliaLang/julia/issues, or
I started this thread long time ago with a question about rounding rules
and the IEEE floating point standard. I felt like being criticized for even
thinking Julia could follow the round-to-even rule. Now I learn that
Julia version 0.4 will apply this rule (as default?).
We had similar
I had a (fixable) problem installing on my Macbook Air. Upon first launch
in a terminal window I got this error:
Warning: error initializing module LinAlg:
ErrorException(error compiling __init__: error compiling check_blas: error
compiling openblas_get_config: could not load module
It can be difficult to remember all threads on the mailing list that relate
to changes made in Julia. Hence, it is very helpful when users make cross
references such that you are doing here. A link to the exact issues on
github would be even better so here they are
Thank you very much Ivar!
There has been requests for adding more languages to the project already,
Russian and Portuguese, but actually translating them will be
responsibility of whomever works for them, I can only focus in Spanish.
I'm well aware that the docs aren't static, which is in fact
If it helps at all, I saw that exact issue a few days back, on 0.3 and 0.4.
I had to delete and rebuild the openblas included in the Julia repo. I
don't know exactly how the Julia 0.3.x builds work but a stale openblas may
be causing issues.
On 26 December 2014 at 16:13, Tony Kelman
Hi Ismael,
First of all, thanks for doing this :)
I am not sure if you announced your plans to work on this in advance, so
sorry if I missed it and thus the opportunity to provide early feedback.
The last time I saw the issue of translating the documentation using a
translation platform being
I don't know if this is a problem with core Julia, with Compat.jl or with
my own code, but I can't figure out how to get this working.
On Julia 0.3, I can do iround(1//2) without problems (yielding 1), but I
can't figure out how to do this with the 0.4 method names and Compat:
julia using
Hi Everyone:
I just decided to upgrade to Julia v0.4 and ran into the following error
when trying to compile from source (I’m running Yosemite 10.10.1). Anyone
else run into this problem and know how to fix it? —Cheers
==
All 3 tests passed
==
Making check
You need to install cmake and make it available on your path:
http://www.cmake.org/download/
-- John
On Dec 26, 2014, at 2:07 PM, Ethan Anderes ethanande...@gmail.com wrote:
Hi Everyone:
I just decided to upgrade to Julia v0.4 and ran into the following error when
trying to compile from
Thanks John. I guess that was obvious from the error message. Sorry for the
noise.
--Ethan
On Friday, December 26, 2014 11:09:04 AM UTC-8, John Myles White wrote:
You need to install cmake and make it available on your path:
http://www.cmake.org/download/
-- John
On Dec 26, 2014, at
No worries. Adding a cmake dependency is a big change for Julia.
-- John
On Dec 26, 2014, at 2:13 PM, Ethan Anderes ethanande...@gmail.com wrote:
Thanks John. I guess that was obvious from the error message. Sorry for the
noise.
--Ethan
On Friday, December 26, 2014 11:09:04 AM UTC-8,
Here are two methods in two different modules:
julia methods(FEMMHeatDiffusionModule.distribloads)
# 1 method for generic function distribloads:
distribloads(self::FEMMHeatDiffusion,assembler,geom::NodalField{Float64},temp::N
odalField{Float64},fi::ForceIntensity{Float64},m::Int64) at
I've identified the problem. fixup-libgfortran was sad because all the
consumers of libgfortran linked to lib{gfortran,quadmath,gcc_s} via the
public paths, which look like /usr/local/lib/gcc/4.9/xxx, whereas
libgfortran internally linked to libquadmath via a private path, which
looks like
This is aliasing. Almost all languages allow this.
-- John
Sent from my iPhone
On Dec 26, 2014, at 2:49 PM, Bradley Setzler bradley.setz...@gmail.com
wrote:
Hi,
I cannot explain this behavior. I apply a function to a variable in the
workspace, the function initializes its local
Julia passes arrays by reference and always has:
http://julia.readthedocs.org/en/latest/manual/arrays/#multi-dimensional-arrays
On Fri, Dec 26, 2014 at 2:49 PM, Bradley Setzler bradley.setz...@gmail.com
wrote:
Hi,
I cannot explain this behavior. I apply a function to a variable in the
Why would you want this behavior? How could you possibly benefit from
modifying X anytime you modify Y just because Y=X initially? If I wanted to
modify X, I would modify X itself, not Y.
Bradley
On Friday, December 26, 2014 1:53:12 PM UTC-6, John Myles White wrote:
This is aliasing.
The main reason is performance; passing and aliasing arrays this way (those
are two different concepts, which work together to make this particular
example a little confusing) allow for writing code that is as fast as
possible, by leaving the coder in control of when a copy is made and when
it
On Friday, 26 December 2014 06:14:34 UTC-6, Hans W Borchers wrote:
I started this thread long time ago with a question about rounding rules
and the IEEE floating point standard. I felt like being criticized for even
thinking Julia could follow the round-to-even rule. Now I learn that
Julia
Thanks Tomas, the similar command will be very useful in avoiding this
issue.
Thank you also for a thoughtful and informative response, Tomas.
Bradley
PS - For what it's worth, R does not have this behavior.
On Friday, December 26, 2014 2:05:44 PM UTC-6, Tomas Lycken wrote:
The main
Glad to be of service! =)
Languages treat both aliasing and argument passing differently, so it
really just takes a little while to experiment and see how this language
plays out what you're trying to do. For what it's worth, Julia also has a
style convention to end all method names with a
I'm also sorry if you felt like you were being criticized in any way for
proposing alternate behaviors. Please keep in mind that any disagreement is
just that – disagreement. Even if everyone seems disagree with you, please
do make your case. As you've noted, they may change their minds – or they
Unfortunately, backporting the new Dict constructor approach to 0.3 would
be a fairly large breaking change, so people will have to rely on Compat
for now for that functionality.
On Fri, Dec 26, 2014 at 5:07 AM, Ismael VC ismael.vc1...@gmail.com wrote:
You'll need to use `@compat` in v0.3.3:
I wander if the convention should have been made the other way as not all
will know it at first..
If you do not want your arguments touched then you can trivially make a
non-mutating wrapper using the similar function. It seems that could have
been automated.. Maybe you can with a macro?
It's sort of unfortunate that we need to depend on both make and cmake, but
c'est la vie – we also depend on both C and Fortran compilers. Life's
complicated when you need to build a lot of software.
On Fri, Dec 26, 2014 at 2:14 PM, John Myles White johnmyleswh...@gmail.com
wrote:
No worries.
Well I was told that historicaly people were encouraged not to spend too
much energy translating the docs because they are not static (and I see
that still hasn't changed). I thought there wasn't much interest, so I left
the idea for a while and stoped looking for advance in this field.
But
Thank you for that fix! Works for me.
On Wednesday, December 3, 2014 9:09:46 PM UTC-5, Tobias Jone wrote:
Inside the Mongo.jl file, what is const MONGO_LIB defined as? If
it's currently libmongoc, try explicitly setting the suffix, eg const
MONGO_LIB = libmongoc-1.0
Bit of a late
The problem lies in detecting (or, rather, teaching the compiler to detect)
if a function - or any of the functions it calls - mutates an argument;
this is a fairly difficult problem.
If you take a look at the Julia standard library, you'll see that a lot of
functions have both mutating and
I mentioned Julia as a good alternative to Ceylon language in their forum
(for linear algebra).
First of all, I assume you could call Ceylon (in theory at least, or vice
versa, I don't know to much about Ceylon). And second, I'm not sure I agree
with the responses I got. It seems they (or I?)
Whether this is surprising to you or not depends entirely what language you
are coming from. For Matlab and R users, this is a significant difference.
For people coming from C, C++, Fortran, Python, Ruby, Perl, Java, and Lisp,
this is unsurprising. You can easily implement the non-mutating
None of those are particularly good reasons. It boils down to Julia
doesn't do Java-style OO well, but believe it or not Java-style OO isn't
the only way you can build a large program.
To take a couple of specific points as examples, you can use composition
Oh, man. Suggesting a different language on a language's mailing list –
that's throwing down the gauntlet! I think I'll write a reply on the ceylon
list about some of the factual claims about Julia.
On Fri, Dec 26, 2014 at 4:41 PM, Páll Haraldsson pall.haralds...@gmail.com
wrote:
I mentioned
I think this have to be fixed in Compat, so that's probably the right place
to open an issue (or preferably a PR).
You also don't need @compat, because (currently) Compat just generically
defines
the new functions
If it can't be fixed in Compat, we might consider it a bug in Julia 0.3 and
fix it in a new 0.3.5 point release.
Ivar
kl. 23:03:51 UTC+1 fredag 26. desember 2014 skrev Ivar Nesje følgende:
I think this have to be fixed in Compat, so that's probably the right
place to open an issue (or
Thanks - then at least I know that it's not a user error. I'll take a look
at Compat and see if I can figure out a fix.
// Tomas
On Friday, December 26, 2014 11:07:14 PM UTC+1, Ivar Nesje wrote:
If it can't be fixed in Compat, we might consider it a bug in Julia 0.3
and fix it in a new
Duty calls...!
http://xkcd.com/386/
On Friday, December 26, 2014 10:58:06 PM UTC+1, Stefan Karpinski wrote:
Oh, man. Suggesting a different language on a language's mailing list –
that's throwing down the gauntlet! I think I'll write a reply on the ceylon
list about some of the factual
My understanding is that cmake is more a replacement for autotools than
make, since on *nix platforms (at least), it generates Makefiles.
Cheers!
Kevin
On Friday, December 26, 2014, Stefan Karpinski ste...@karpinski.org wrote:
It's sort of unfortunate that we need to depend on both make and
I'm sorry, I wanted to correct them myself. Not expecting anyone (else) to
since I started this.. I think I know a good thing when I see one. I just
though maybe I'm missing something getting those responses and wandered if
my admiration of Julia was somewhat misplaced.
Maybe I should just
LOL!!! (A good xkcd link always does that.)
On Friday, December 26, 2014, Tomas Lycken tomas.lyc...@gmail.com wrote:
Duty calls...!
http://xkcd.com/386/
On Friday, December 26, 2014 10:58:06 PM UTC+1, Stefan Karpinski wrote:
Oh, man. Suggesting a different language on a language's
Submitted: https://github.com/JuliaLang/Compat.jl/pull/34
// T
On Friday, December 26, 2014 11:08:16 PM UTC+1, Tomas Lycken wrote:
Thanks - then at least I know that it's not a user error. I'll take a look
at Compat and see if I can figure out a fix.
// Tomas
On Friday, December 26, 2014
On Friday, December 26, 2014 5:32:39 PM UTC-5, Páll Haraldsson wrote:
Maybe I should just put my blinders on, just not look at other languages
more. I'm pretty convinced all the others I know are obsolete (for new
code).. I just might be missing something with the newer languages.
Julia
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
Don't worry. I am a long-term ... user and as such got used to really harsh
criticism. As others have noted, this is - besides Ruby - the most friendly
mailing list I have seen (and I am sometimes not living up to that
standard). What irritates me a bit are these back-and-forth decisions. I
Note, I said I know. You may know more languages. Wander what the top 3
are (if Julia isn't top 1).
Still, languages have died out (mostly) and I think we need fewer
languages, not more.
I do not see a good reason for C++ any more (is the exception handling in
Julia as least as good as
I think we need more languages if only because I think we've barely started
to explore the programming language design space – it's a very non-convex
optimization problem. Sure, some languages are close to local optima, but
you never know what's going to happen when you start combining things in
On Fri, Dec 26, 2014 at 6:00 PM, Hans W Borchers hwborch...@gmail.com
wrote:
What irritates me a bit are these back-and-forth decisions. I accepted
.+ for scalar plus vector operations (with a bit of teeth grinding, but
listening to a good mathematical analogy), used it in some programs, only
is this thread still alive? a phc package would be good...
On Monday, June 23, 2014 5:26:34 AM UTC-7, Andrei Berceanu wrote:
By the way I recently stumbled upon NLSolve.jl, and asked them if they
would be interested in PHCpack
https://github.com/EconForge/NLsolve.jl/issues/12
Still no
when trying to download Mac OS X Package (.dmg)
Error
CodeNoSuchKey/Code
MessageThe specified key does not exist./Message
Keybin/osx/x64/0.3/julia-0.3.4-osx10.7 .dmg/Key
...
also tried to remove the space between 10.7 and .dmg on the path, but same
NoSuchKey
and in support of Stefan's language/software observations, the hardware
aspect is nearly as important,
but perhaps more subtle ...
AMD and ARM are committed to the HSA movement (bit.ly/1E2mOWq) recognizing
that CPUs, GP/GPUs,
FPGAs and perhaps other new SoC developments will increasingly
Hi,
I am porting a matlab random number generation from multivariate T
distribution and attached, I am converting the mvtrnd.m function of Matlab.
This is mixed version of Julia and original Matlab scripts and nonetheless
of my series of the modifications, it still making a error to me.
Last
IIUC import collisions are on name only, not by signature.
From https://github.com/JuliaLang/julia/issues/4345 I understand that this
is because the two `distribloads` methods are methods of different
functions, one function defined in FEMMHeatDiffusionModule and one
in FEMMAcousticsModule.
You have a typo at line 31. It's not
nagrin=3;
but
nargin=3
Sábado, 27 de Dezembro de 2014 1:50:03 UTC, jspark escreveu:
Hi,
I am porting a matlab random number generation from multivariate T
distribution and attached, I am converting the mvtrnd.m function of Matlab.
This is mixed
On Saturday, December 27, 2014 8:54:28 AM UTC+10, 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
You might also be interested in MvTDist in Distributions.jl:
https://github.com/JuliaStats/Distributions.jl/blob/master/src/multivariate/mvtdist.jl
On Friday, 26 December 2014 19:50:03 UTC-6, jspark wrote:
Hi,
I am porting a matlab random number generation from multivariate T
distribution
Try again?
-E
Thanks for the link, I didn't know about that Github feature.
While most of the commits are bugfixes, there are some new features, e.g.
https://github.com/JuliaLang/julia/commit/e00a07a02a93fbec40d44ff473328a4897a6d5f5
and
Having read the issues (https://github.com/JuliaLang/julia/issues/4345), I
think I have a better understanding of the complexity involved in importing
functions of the same name. While I think some legitimate uses are
eliminated if such imports are prohibited, the potential tripping points
are
It generates Makefile by default, but it can also generate project files
for MSVC or XCode, or you can generate Ninja files which can be quite a bit
faster than make for incremental builds. At the moment the only thing we're
using it for by default is libgit2, which uses cmake as its only build
Dear Julia Users,
I would like to silence the output of packages, but am having trouble doing so.
This applies to package-generated info() messages occuring due to using calls
as well as to the output of external programs, e.g. a solver. Basically I'd
like to redirect everything except my own
On Wednesday, December 24, 2014 5:29:45 PM UTC-5, Milan Bouchet-Valat wrote:
Again, if you can improve the manual, feel free to make suggestions. It
looks like the meaning of global could use some more explicit
definition.
Thanks, Milan. Created issue #9469. I'm happy to try my hand at
Hi everybody,
I am working about integer arrays and I need Int64 NaN.
Have any solutions for this problem?
Thanks in advance.
Kenan
On Saturday, December 27, 2014 5:29:27 PM UTC+10, Kenan KARAGÜL wrote:
Hi everybody,
I am working about integer arrays and I need Int64 NaN.
A NaN is a floating point value using an otherwise illegal set of bits,
there is no set of bitse of an int64 that does not represent a valid
71 matches
Mail list logo
