Re: [julia-users] Where to publish numerical work using julia

[Sheehan Olver]

I think "not scientifically novel" is probably not the right choice of 
words: engineering is "science", and I would include software engineering 
in this.  If it's not novel on the software engineering side, and not novel 
on the underlying algorithm, then what's the point of publishing a paper?

On Thursday, October 16, 2014 at 4:25:57 AM UTC+11, Isaiah wrote:
>
> If the work is "I translated Conventional Algorithm Foo into Julia" then 
>> it probably wouldn't be that interesting
>
>  
> There have been some pushes to create a peer-reviewed publication path for 
> software that is not necessarily scientifically novel. I'm not familiar 
> with any in computational physics, but in statistics there is the Journal 
> of Statistical Software, and in neuroscience/imaging there are things like 
> the Insight Journal and the "Frontiers in..." imprints which have 
> software-specific tracks.
>
> It is a difficult thing to evaluate though, because aside from the 
> labor-intensiveness and other general problems of software review, the 
> value of a scientific software contribution may only be obvious after 
> several years of refinement and organic growth. This has been a problem for 
> Julia and other software creators based in academia, when seeking grant 
> funding.
>
> On Wed, Oct 15, 2014 at 11:47 AM, Jiahao Chen  > wrote:
>
>> I second what Stefan and Erik have said. If the work is new and original 
>> regardless of its implementation in Julia, then just submit it to where you 
>> would ordinarily submit such work. If the work is "I translated 
>> Conventional Algorithm Foo into Julia" then it probably wouldn't be that 
>> interesting, unless possibly you demonstrate how your implementation makes 
>> special use of unique language features, in which case that could be 
>> highlighted as the main point of the work.
>>
>> Thanks,
>>
>> Jiahao Chen
>> Staff Research Scientist
>> MIT Computer Science and Artificial Intelligence Laboratory
>>
>>
>

[julia-users] Re: [ANN] ScikitLearn.jl

[Sisyphuss]

Cool!

On Friday, March 18, 2016 at 5:11:47 PM UTC+1, Cedric St-Jean wrote:
>
> I'm happy to announce ScikitLearn.jl 
>  and ScikitLearnBase.jl 
> : a library pair that 
> brings the scikit-learn interface to Julia. 
>
>
> *Highlights*
>
>- Around 150 machine learning and statistical models accessed through 
>a uniform interface
>- Pipelines and FeatureUnions
>- Cross-validation
>- Model selection (hyperparameter tuning)
>- Feature extraction (text processing, one hot encoding, etc.)
>
> Check out the documentation 
> , quick start guide 
>  and example 
> gallery 
> .
>
>
> ScikitLearn.jl uses PyCall.jl for Python models, but the "glue" (eg. 
> Pipelines) was translated to make it possible to implement models in Julia. 
> For instance, one might pipeline a factor analysis model from Python into a 
> deep learning model written in Julia, and use grid search to optimize its 
> hyperparameters. 
>
>
> Any Julia type that implements the scikit-learn interface 
>  can be used with this 
> framework. If you have any issue supporting the interface for your library, 
> ping me @cstjean.
>
>
> Best,
>
> Cédric St-Jean
>

[julia-users] Re: How to get define a function from the AST or how to get @everywhere to export a function it was called with

[Jonathan Anderson]

after some iteration i found the following works

function run_slurm_helper(ex,num_workers)
 println(ex)
addprocs(SlurmManager(num_workers), partition="quick", t="00:01:00")

output = []
for i in workers()
out = fetch(@spawnat i eval(ex))
push!(output, out)
end

for i in workers()
rmprocs(i)
end

return output
end


run_slurm(f::Function;num_workers = 5) = run_slurm_helper(code_lowered(f
,())[1].args[3],num_workers)

run_slurm() do
 return (gethostname(), getpid())
end

but there might be a cleaner way.

On Thursday, March 17, 2016 at 11:04:40 AM UTC-5, Jonathan Anderson wrote:
>
> After reading the following post ( 
> https://groups.google.com/forum/#!searchin/julia-users/addprocs$20output$20SlurmManager/julia-users/VNjshcRJYR8/uJz0FkkQAAAJ
>  
> ) I decided to try the following
>
> function run_slurm(f::Function;num_workers = 5)
>
> addprocs(SlurmManager(num_workers), partition="quick", t="00:01:00")
>
> @everywhere f
>
> output = []
> for i in workers()
> out = fetch(@spawnat i f())
> push!(output, out)
> end
>
> for i in workers()
> rmprocs(i)
> end
>
> return output
> end
>
> run_slurm() do
>  return (gethostname(), getpid())
> end
>
> but it looks like i get the following error:
>
> UndefVarError: f not defined
>
> I've been looking into trying to get the definition and redefining it 
> using something like the following, but i'm lost as to how i could use this
>
> julia> lambda_info = eval(code_lowered(f,())[1])
> AST(:($(Expr(:lambda, Any[symbol("#self#")], Any[Any[Any[symbol("#self#"
> ),:Any,0]],Any[],0], :(begin  # none, line 1:
> return (top(tuple))((Main.gethostname)(),(Main.getpid)())
> end)
>
> From (
> https://stackoverflow.com/questions/14124456/access-the-ast-for-generic-functions-in-julia)
>  
> I've tried the following with no luck.
>
> julia> ccall(:jl_uncompress_ast, Any, (Any, Any), lambda_info, lambda_info
> .ast)
> 35
>
>

[julia-users] Re: Is there going to be an abstract type/trait-ocalypse?

[Jeffrey Sarnoff]

There is much discussion about the ways forward here is a good place to 
look:  https://github.com/JuliaLang/julia/issues/6975
fwiw, many people would like to be able to meld multiple kinds to express 
qualia and there is active interest in finding the elegant answer.



On Thursday, March 17, 2016 at 6:53:14 AM UTC-4, DNF wrote:
>
> I guess maybe this question is difficult to answer with any confidence; I 
> certainly have no particular insight. There have been previous discussions, 
> but I don't know what the prevailing opinion is currently.
>
> I just wanted to bump it, and add that this is exactly the kind of topic I 
> find *particularly *interesting, even when the answers are speculative.
>

[julia-users] Re: ANN: VegaLite.jl

[Dominik Moritz]

This is fantastic. I'll add links to all the packages that use/build on 
Vega-Lite to the website. Let us know if there is something we can help 
with.

On Tuesday, March 15, 2016 at 2:39:56 PM UTC-7, Frederic Testard wrote:
>
> The julia package VegaLite has just been added to the official repo ( 
> install with Pkg.add("VegaLite")  ). As the name suggests it provides 
> bindings to the VegaLite plotting library (yet another way to make graphs 
> with Julia !). VegaLite is a simplified version of Vega which reduces the 
> functionality but provides in turn a simpler way to define graphs (see 
> https://vega.github.io/vega-lite/).
>
> VegaLite uses graph descriptions in JSON but the julia syntax proposed by 
> the package looks more like the ggplot syntax where a series of functions 
> builds up the graph specs. You can check out the Quick tour/presentation at 
>  https://github.com/fredo-dedup/VegaLite.jl
>
> The supported backends are the standard REPL (a browser window will open), 
> Escher and Jupyter.
>
> Issues, enhancements proposals are of course welcome !
>
>
>
>
>

Re: [julia-users] Documentation effort for GSoC

[Mike Innes]

Hey Morten,

This looks like an interesting idea. Is (a) doable in three months? It
might be tricky, especially with the current state of Julia's web tooling.

I recommend taking a look over the Docile and Lexicon packages – Michael
Hatherly has made really great progress with some of these ideas, and you
might be able to get involved over there and figure out some more detailed
ideas.

Cheers,
Mike

On Tue, 15 Mar 2016 at 18:10 Morten Piibeleht 
wrote:

> I would like to put together a GSoC proposal targeting the
> documentation. Some thoughts have been on floating in my head as I
> have been using Julia for the past year and would be fun for me to work on.
>
> Specifically, the following could be specific enough the be a GSoC project:
>
> (a) A system for user notes/feedback on the docs.
>
> The idea is to have a system where the users could comment on every
> section of the documentation, probably also with a moderation system
> in place. Basically inspired by the PHP documentation, where every
> page (e.g. function) has notes attached.
>
> It would effectively make the docs update and improve more rapidly, by
> people sharing their thoughts and examples on particular functions,
> types etc, and on the other hand make it easy for others to find.
> These entries would complement the documentation, or function as a
> temporary placeholder documentation, if the documentation is lacking
> something. It would also offer a library of use cases etc. for people
> who would at some point hopefully edit the official documentation,
> helping to write better documentation in general.
>
> For the implementation, it depends what’s out there of course. Perhaps
> something existing could be tweaked for to fit Julia, Read the Docs
> extended or something written from scratch.
>
>
> (b) Automation tools & guidelines for the docs
>
> This one is a bit more vague, but would involve making the docs even
> more friendly to automatic parsing and then making use of that. For
> example, creating useful, thorough reference manuals for packages
> (like the Base has, but I haven't seen for packages). Moreover, even
> the Base could benefit from having more thorough information (e.g.
> exact function signature, automatically extracted from the code).
>
> Part of it would be figuring out and defining a good way to write
> documentation for packages, so that it could be used be automatic
> tools for displaying etc, and also how to display it in a useful
> manner. What I have in mind is something like doxygen or javadoc for
> Julia. I think it could also tie into the only documentation-related
> idea on the ideas page regarding having docs in the IDEs (under Juno).
>
>
> Would love to hear whether people think that these could be a useful
> and one of them make a reasonable GSoC project (and if so, whether
> there’s anyone willing to mentor it). Also, just to hopefully start a
> useful discussion, what other thoughts have people had to make the
> docs even better?
>
> Best,
> Morten
>

Re: [julia-users] Re: regression from 0.43 to 0.5dev, and back to 0.43 on fedora23

[Milan Bouchet-Valat]

Le mercredi 16 mars 2016 à 09:25 -0700, Johannes Wagner a écrit :
> just a little update. Tested some other fedoras: Fedora 22 with llvm
> 3.8 is also slow with julia 0.5, whereas a fedora 24 branch with llvm
> 3.7 is faster on julia 0.5 compared to julia 0.4, as it should be
> (speedup from inner loop parts translated into speedup to whole
> function).
> 
> don't know if anyone cares about that... At least the latest version
> seems to work fine, hope it stays like this into the final fedora 24
What's the "latest version"? git built from source or RPM nightlies?
With which LLVM version for each?

If from the RPMs, I've switched them to LLVM 3.8 for a few days, and
went back to 3.7 because of a build failure. So that might explain the
difference. You can install the last version which built with LLVM 3.8
manually from here:
https://copr-be.cloud.fedoraproject.org/results/nalimilan/julia-nightlies/fedora-23-x86_64/00167549-julia/

It would be interesting to compare it with the latest nightly with 3.7.


Regards



> > hey guys,
> > I just experienced something weird. I have some code that runs fine
> > on 0.43, then I updated to 0.5dev to test the new Arrays, run same
> > code and noticed it got about ~50% slower. Then I downgraded back
> > to 0.43, ran the old code, but speed remained slow. I noticed while
> > reinstalling 0.43, openblas-threads didn't get isntalled along with
> > it. So I manually installed it, but no change. 
> > Does anyone has an idea what could be going on? LLVM on fedora23 is
> > 3.7
> > 
> > Cheers, Johannes
> > 

[julia-users] Re: how to write a julia rand conformant randfloat() with exponent range given

[Jeffrey Sarnoff]

So far, I have:

   import Base:ldexp

   @vectorize_2arg Any ldexp

   function 
randfloat{T<:AbstractFloat}(sigRange::FloatRange{T},expRange::UnitRange{Int},n::Int)
  s = rand(sigRange,n)
  e = rand(expRange,n)
  ldexp(s,e) 
   end

On Saturday, March 19, 2016 at 12:06:32 AM UTC-4, Jeffrey Sarnoff wrote:
>
> I am not that familiar with rand stuff, and I'd like to get this right.
>
> The result should play well with other rand functions  and give n 
> ldexp(randSignficand, randExponent) values where the range for the 
> significand and the exponent are specifiable.
>
> Thanks for any guidance.
>

[julia-users] how to write a julia rand conformant randfloat() with exponent range given

[Jeffrey Sarnoff]

I am not that familiar with rand stuff, and I'd like to get this right.

The result should play well with other rand functions  and give n 
ldexp(randSignficand, randExponent) values where the range for the 
significand and the exponent are specifiable.

Thanks for any guidance.

[julia-users] JuliaCon 2016: Call For Proposals Deadline Extension

[Pontus Stenetorp]

Everyone,

Due to popular request we will be extending the deadline for the call
for proposals over the weekend.  We hope that this will allow those
that are running low on time to polish up their proposals and submit
them over the next few days.

Proposal submission form: http://goo.gl/forms/eXlP0KsQ1U
Call for Participation closes: March 20th, 23:59 (UTC-11)

On behalf of the JuliaCon 2016 organisers,
Pontus Stenetorp

[julia-users] Re: Google SoC '16: Native Julia solvers for ordinary differential equations, Julia|Quantum>, and Native Julia implementation of Holonomic Functions

[Chris Rackauckas]

  Taking a quick look at the paper you linked makes big use of symbolic 
computing algorithms to compute things like a Groebner basis. To get the 
infrastructure for what's proposed you would need a whole symbolic 
computing library, which is why they used Mathematica. I think implementing 
a fast and extendable symbolic computing library in Julia would be great 
because of its type system, but this sounds like a lot more than a GSoC 
project.
  
  If you want to put together quantum mechanics and differential equations, 
you could look into specialized solvers which are focused on those types of 
equations. PDE solvers for Schrodinger's equation and the like. Helping out 
with the complex numbers issues could be really interesting an insightful 
(see the julia-dev thread, and look up the issues) and would be required to 
go forward here. 

  However, quantum algorithms may be interesting in Julia, and maybe you 
could simulate their actual running (this would likely be a large project 
too...), but the quantum algorithm implementations themselves wouldn't be 
very useful. 

  But yes, I think a lot of people think that ODE is pretty high on the 
priority list. I've seen a few of the developers say things along those 
lines. There's a lot of very basic and useful things that need to be done. 
For sure there should be some tests to show that the algorithms are all 
implemented properly, and there should be more stiff solvers and the like.

On Tuesday, March 15, 2016 at 11:10:26 AM UTC-7, Joseph Obiajulu wrote:
>
> Hello All,
>
> My name is Joseph Obiajulu and I'm a junior studying mathematics and 
> computer science at Princeton University. I was looking through the project 
> ideas for potential GSoC projects on the Sage page, and I came across a 
> project idea concerning "Native Julia solvers for ordinary differential 
> equations." I have experience with differential equations from my math 
> training, as well as exposure to different numerical computing methods and 
> am starting to get my feet wet with coding in Julia, and so thought that I 
> might be able to contribute to the project. I wanted to ask on this mailing 
> list, especially to those who will mentor this project, where the best 
> place to start would be (I have a few ideas, but I wanted to ask those who 
> have put more thought into this question for advice). Also, I was wondering 
> if this is a high-priority project, or if there is another project that the 
> Julia community would rather have someone work on for the summer. 
>
> With that said, I also am thinking of proposing two of my own project 
> ideas (of course, I would only end up pursuing one over the summer, but I 
> figured it doesn't hurt to propose additional ideas). The first is working 
> to expand Julia|Quantum>. I have a particular interest in quantum mechanics 
> and especially quantum computing, and I thought a cool project would be to 
> work on implementing some of the long term JuliaQuantum project goals (see 
> these 
> goals here 
> ), as 
> well as maybe implementing simple quantum computing algorithms, such as 
> Shor's and Groover's. This idea is still very much in its infancy, so I'm 
> curious to hear what people think of it.
>
> The second is a native julia implementation of holonomic functions 
> . Holonomic functions 
> draw their strength from their closure properties, and often can simplify 
> some calculations (or at least that's what I've read, I'm still looking 
> into it). The following dissertation 
>  
> would be something I would work through as I try to implement standard 
> operations of holonomic functions (addition, multiplication, integration, 
> derivatives, etc). This is more of a 'Blue Sky' project, but I find it 
> particularly interesting, because it is probably the most "mathematically 
> heavy" one of the three I've proposed, and I that's something that get's me 
> excited, especially that it deals with analysis, which is my mathematical 
> focus.
>
> I'm eagerly awaiting to hear from the Julia community!
>
> Thanks for the help,
> Joseph
>

[julia-users] Re: ANN: NetworkViz.jl - Julia module for graph visualization

[Abhijith Anilkumar]

I'm ready to work in that direction. I always wanted to make this package 
work with packages other than LightGraphs and also backend-independent. 
I'll create a solid plan on what I intend to implement and post it here.

On Friday, March 18, 2016 at 3:15:35 AM UTC+5:30, Simon Danisch wrote:
>
> See that there is already GraphVisualize.jl 
> and I took a quick stab 
> at the issue with SignalView.jl 
> .
> Both are 2D right now, but should easily work for 3D as well. Note, that I 
> actually plan to create a ThreeJS backend for GLVisualize at some point ;)
> I can be a mentor for this project, if you don't mind making your project 
> a bit more independant from the backend!
>
>
> Am Donnerstag, 17. März 2016 14:17:15 UTC+1 schrieb Abhijith Anilkumar:
>>
>> Hi,
>>
>> I'm happy to announce the first registered version of NetworkViz.jl 
>> , a julia interface 
>> to visualize graphs using ThreeJS.jl 
>>  and Escher.jl 
>> . The package is tightly coupled 
>> with LightGraphs.jl . It 
>> uses Escher.jl to interactively modify the visualization. The following 
>> examples demonstrate what NetworkViz is capable of :
>>
>>
>>- WheelGraph Visualization 
>>
>>- Code-Mirror example 
>>
>>
>> I've planned to implement the following features in the future releases :
>>
>>- Implement different Graph Plotting algorithms
>>- Better Text Support 
>>- Blink Integration
>>- Generalize the package (to work with packages other than 
>>LightGraphs)
>>
>>
>> I would like to take this up as a GSoC project and continue working on 
>> the package. I would therefore like to ask if there is someone who would 
>> like to be a mentor for this project? 
>>
>> Please give your suggestions so that I can use it to improve the package 
>> and make it useful for the community. 
>>
>> Regards,
>> Abhijith
>>
>

Re: [julia-users] Re: Performance regression with latest master?

['Bill Hart' via julia-users]

It's actually a regression of more than a factor of 2 on the machine I'm 
using.

I'll try to further refine the commit range by hand today.

Bill.

On Wednesday, 16 March 2016 20:45:00 UTC+1, Bill Hart wrote:
>
> I can only partially bisect.
>
> The regression happens between:
>
> 75fc9104ee24 (more recent)
>
> and
>
> dc6b0de80550 (older)
>
> But few of the intervening commits actually build, so I can't refine it 
> further. There's something like 40 commits in that range.
>
> Bill.
>
> On 16 March 2016 at 18:28, Kristoffer Carlsson  
> wrote:
>
>> Can you bisect to the right commit?
>>
>> You can create a julia script that runs "exit(1)" on a bad commit and "
>> exit(0)" on a good commit.
>>
>> Then create a bisect_runner.sh with
>>
>> make || exit 125
>>
>> julia -e 'include("test_script.jl")'
>>
>> and then do a bisect run ./bisect_runner.sh after having marked a good 
>> and bad commit.
>>
>>
>>
>> On Wednesday, March 16, 2016 at 5:25:11 PM UTC+1, Bill Hart wrote:
>>>
>>> We are seeing a performance regression with a factor of 1.5 or 2.0 
>>> (depending on machine) for the following simple C interface code between 
>>> 0.4.2 and today's master (not sure where the problem initially showed up, 
>>> but within the last 50 days):
>>>
>>> import Base: +
>>>
>>> typealias ZZ Array{UInt, 1}
>>>
>>> function +(a::ZZ, b::Int)
>>>r = ZZ(length(a))
>>>ccall((:__gmpn_add_1, :libgmp), Void, (Ptr{UInt}, Ptr{UInt}, Int, 
>>> Int), r, a, 3, b)
>>>return r
>>> end
>>>
>>> function doit(n::Int)
>>>a = ZZ(3)
>>>a[1] = rand(UInt)
>>>a[2] = rand(UInt)
>>>a[3] = rand(UInt)
>>>
>>>for s = 1:n
>>>   a += s
>>>end
>>>
>>>return a
>>> end
>>>
>>> doit(10)
>>>
>>>
>>> I realise the example is not mathematically very meaningful, nor is it 
>>> the best way to compute anything in particular. It's cut down from a larger 
>>> example to illustrate the performance regression clearly.
>>>
>>> Bill.
>>>
>>>
>

[julia-users] Re: suppress deprecation warnings on all workers? (julia 0.4.3)

[Ryan Gardner]

Nevermind.  It was right there.  For anyone reading this later, what I was 
looking for was:

   addprocs(num_procs, exeflags="--depwarn=no")

(However, if there is a way to set depwarn=no in the code, that would still 
be valuable.)  Thanks.

Ryan


On Wednesday, March 16, 2016 at 9:52:47 AM UTC-4, Ryan Gardner wrote:
>
> I was running with --depwarn=no to suppress deprecation warnings.  Now I'm 
> parallelizing, and the warnings still seem to be printed for all the 
> workers (which is probably making everything super slow - they are printed 
> every single time they are hit, not just at parsing or compilation).
>
> Anyone know how to fix this?  Is there a way I can disable the deprecation 
> warnings in the code itself.  This would be ideal compared to the julia 
> command-line options anyway.
>
> (Yes, I would _love_ to fix all the warnings, but it's not an option.  I 
> don't control the code being run, and there are a zillion of them. 
>  Similarly, I'd love to upgrade to the latest and greatest julia, but then 
> this code that I'm using completely breaks, so that's not an option either.)
>
> Thanks.
>

[julia-users] Re: QML (Qt5) binding for Julia (GSOC?)

[Bart Janssens]

This could be either a missing Qt package, or the version is not recent 
enough. I don't use any recent QML commands, so it's safe to use QtQuick 
2.0 and Controls and Layouts version 1.0. I have updated the main.qml in 
the repo.

If you pass just QString("main.qml") as argument to QQmlApplicationEngine 
it will look in the current working directory. You should also be able to 
pass an absolute path. By default, the test runs in the test directory of 
the package, so the test looks for .julia/v0.4/QML/test/main.qml. maybe 
your .juliarc.jl did an override on that.

Cheers,

Bart

On Wednesday, March 16, 2016 at 8:22:29 PM UTC+1, Uwe Fechner wrote:
>
> Ok, I disabled my .juliarc.jl file.
>
> Now I get another error:
>
> julia> Pkg.test("QML")
> INFO: Testing QML
> QQmlApplicationEngine failed to load component 
> file:///home/ufechner/.julia/v0.4/QML/test/main.qml:1 module "QtQuick" 
> version 2.5 is not installed
>
> Any idea?
>
> On Wednesday, March 16, 2016 at 8:10:49 PM UTC+1, Uwe Fechner wrote:
>>
>> I am now on a different computer, and "using QML" now works.
>>
>> Pkg.test("QML") still fails, but with a different error:
>>
>> julia> Pkg.test("QML")
>> INFO: Testing QML
>> QQmlApplicationEngine failed to load component 
>> file:///home/ufechner/00PythonSoftware/FastSim/main.qml:-1 File not found
>>
>> Which file main.qml should I use for testing?
>> I have many files with this name on my computer.
>>
>>
>>
>>>

[julia-users] Re: ANN: VegaLite.jl

[Frederic Testard]

Thank you all for your encouraging interest !

Randy, sorry if you were working on VegaLite too. I am totally open on 
looking into a common approach with Vega.jl if it makes sense. The question 
is I think: should the user chose the plotting grammar from a single 
package by setting a parameter ( set_grammar("Vega")  or ("VegaLite") )  or 
make that choice by loading the needed package first (using Vega or 
VegaLite). In the latter solution, common functionality could still be done 
once by creating a package and having both packages depend on it.

Dominik, thanks. My main expectation from VegaLite is having in the 
layering functionality I know you are working on. Keep up the good work !

[julia-users] Re: Custom ranges

[James Fairbanks]

If you want to reap the benefits of the UnitRange,
such as a constant sized representation regardless of collection size,
then you can define your own type that satisfies the iterator interface.
This is the most flexible option and an explanation can be found in 
http://docs.julialang.org/en/release-0.4/manual/interfaces/.

If you are thinking of UnitRange as a lazy list, then you might be
interested in  https://github.com/MikeInnes/Lazy.jl. Lazy.jl is more
than you asked for but might have other functions that you want.

[julia-users] Re: ANN: VegaLite.jl

[Dominik Moritz]

I have a first layering PR at https://github.com/vega/vega-lite/pull/1241 
but it'll take a bit of testing before we officially announce it. But 
layering is coming. 

On Friday, March 18, 2016 at 3:05:07 PM UTC-7, Frederic Testard wrote:
>
> Thank you all for your encouraging interest !
>
> Randy, sorry if you were working on VegaLite too. I am totally open on 
> looking into a common approach with Vega.jl if it makes sense. The question 
> is I think: should the user chose the plotting grammar from a single 
> package by setting a parameter ( set_grammar("Vega")  or ("VegaLite") )  or 
> make that choice by loading the needed package first (using Vega or 
> VegaLite). In the latter solution, common functionality could still be done 
> once by creating a package and having both packages depend on it.
>
> Dominik, thanks. My main expectation from VegaLite is having in the 
> layering functionality I know you are working on. Keep up the good work !
>

[julia-users] Re: ReverseDiffSource on a nonlinear function with three plus variables

[Frederic Testard]

Sorry for the late reply too. 

Kristoffer is right, this is issue #25. I should really look into it, sorry.

[julia-users] Re: Registering / renaming CppWrapper

[Avik Sengupta]

Yes go for it. It'll be better for the repository to end in .jl. As to the 
name, let's see if there are any creative suggestions on this thread, but 
it's ultimately your decision. 

Regards
-
Avik

On Friday, 18 March 2016 08:52:53 UTC, Bart Janssens wrote:
>
> Hi,
>
> I'd like to register the CppWrapper package:
> https://github.com/barche/CppWrapper
>
> At the very least, I'll have to rename the github repo to CppWrapper.jl, 
> but while I'm at it I'd like to ask if there are any suggestions for a 
> better name? The package is meant to "wrap" a C++ library in a set of Julia 
> functions and types. Unlike Cxx.jl, there is no direct way to call C++ 
> functions, but a C++ file has to be written and compiled into a shared 
> library that can then be loaded using CppWrapper.
>
> Cheers,
>
> Bart
>

[julia-users] Re: [ECCN] What packages are included in the basic distribution of Julia

[Páll Haraldsson]

On Friday, March 18, 2016 at 9:39:11 AM UTC, Páll Haraldsson wrote:
>
>
> On Thursday, March 17, 2016 at 8:27:33 PM UTC, Naiyuan Chiang wrote:
>>
>>
>>  

> There is no reason for Julia to have crypto, since it is a language, and 
> as you say Crypto can be and is a package you can use. Others include 
> MbedTLS , GnuTLS 
> . I would even think it is 
> inappropriate [for any language] to include as you gave a reason.. There 
> would only be downsides and no upside as you can always just use a library.
>
 

> Just to be sure I checked as thoroughly as I can think of:
>
>
> I searched for "crypt", "SSL" and "TLS" (and some more strings) in the 
> Julia standard library in this way (and came up empty really):
>
> find /usr/share/julia/base/ |xargs grep SSL |less
>
> One "match":
>

Full disclosure. I searched even more thoroughly* e.g. for "AES", "RC4", 
"RC5" and "SHA" (but only found "SHA", that isn't *really* "crypto"(?) and 
not really implemented by Julia it seems):

/usr/share/julia/base/pkg/entry.jl:old == sha1 || error("$pkg 
v$ver SHA1 changed in METADATA – refusing to publish")
/usr/share/julia/base/pkg/entry.jl:# TODO: check that SHA1 isn't the 
same as another version

function publish(branch::AbstractString)
[..]
 sha1 = readchomp(joinpath("METADATA",path))
if Git.success(`cat-file -e origin/$branch:$path`, dir="METADATA")
old = Git.readchomp(`cat-file blob origin/$branch:$path`, 
dir="METADATA")
old == sha1 || error("$pkg v$ver SHA1 changed in METADATA – 
refusing to publish")
end


https://en.wikipedia.org/wiki/Secure_Hash_Algorithm

"The *Secure Hash Algorithm* is a family of cryptographic hash functions 
 published by 
the National Institute of Standards and Technology 
 
(NIST) as a U.S.  
Federal 
Information Processing Standard 
 
(FIPS)" is not used to ENcrypt (or decrypt), but for other things.

I was testing Julia 0.4.1, and testing can only prove things are there, not 
absence of stuff. Still I think I looked for the important stuff (in the 
right places) and as I said there is just no good reason to have crypto, 
strong or any kind in Julia. SHA seems to be implemented by git (or other 
external commands, see below), not Julia, but git is a dependency of Julia 
(the package system, not sure you can do without it, can in theory). I 
didn't dig much into SHA matches I found as I do not think important.



Here preinstalled(?) Unix (didn't check what happens on Windows) external 
command "sha1sum" is only USED:

/usr/share/julia/base/random.jl:seed = hash(seed, parse(UInt64, 
readall(pipeline(`ifconfig`, `sha1sum`))[1:40], 16))

## make_seed()
# make_seed methods produce values of type Array{UInt32}, suitable for 
MersenneTwister seeding

function make_seed()
try
return rand(RandomDevice(), UInt32, 4)
catch
println(STDERR, "Entropy pool not available to seed RNG; using 
ad-hoc entropy sources.")
seed = reinterpret(UInt64, time())
seed = hash(seed, UInt64(getpid()))
try
seed = hash(seed, parse(UInt64, readall(pipeline(`ifconfig`, 
`sha1sum`))[1:40], 16))
end
return make_seed(seed)
end
end

-- 
Palli.
 

[julia-users] Re: Hello, How do I find my mentor for GSoC2016?

[Jiahao Chen]

> I tried creating my own matrix power function using Python before, I used 
data parallelism(tiling), task parallelism(using topology) and pipelining 
parallelism(using lowered dependency).

As you say, attacking all levels of parallelism is very ambitious. However, 
I think working on just one of these parallelism structures would make for 
a good summer project. I would recommend you to pick one of these 
approaches and apply it to a widely used computation such as matrix-matrix 
multiplication.

I had a look at your Python implementation

https://github.com/usefulhyun/parallel_mmm/blob/master/prllmpow/prllmpow.py

and it is quite hard to understand. If you can translate the essential 
parts into Julia and show how you can use features like Julia types and 
overloading of Julia's generic functions like * to make the code readable 
yet efficient, then I think we can make a good case for your participation 
in the Google Summer of Code. Without a Julia code sample to evaluate, it 
is quite difficult to make a strong case for participation.