> > Packages blessed by julialang, to be sure, but perhaps separate from the > core. >
Yes, there is a broad consensus that this will be the long-term direction. https://github.com/JuliaLang/julia/issues/5155 On Fri, Apr 17, 2015 at 11:08 AM, Sebastian Good < [email protected]> wrote: > Certainly the licensing is important from a commercial aspect, but I think > this is also an interesting discussion from a core vs packages > perspective. Python is separate from numpy, but indeed no one is under the > illusion that they should work against any other sort of array package. > Core linear algebra and array cleverness seems comfortable in Julia’s Base, > but with so many different kinds of users of Julia — even just considering > those doing math& science with it — things like solvers and sparse arrays > certainly feel like they could be in packages. Packages blessed by > julialang, to be sure, but perhaps separate from the core. > > On April 16, 2015 at 12:32:06 PM, Viral Shah ([email protected]) wrote: > > The useful parts of SuiteSparse are all GPL. So, for a GPL-free build, it > is straightforward to completely avoid using SuiteSparse. > > One of the things I want is to have a version of Julia built with Intel > compilers and linked to MKL. Julia can already use Intel's BLAS, LAPACK, > LIBM, and FFT routines. There is also a VML package for vector math > functions. The only big missing piece is sparse solvers - but perhaps that > is ok for people, who can use Intel's sparse solvers or MUMPS or something > else. > > -viral > > On Thursday, April 16, 2015 at 7:51:38 PM UTC+5:30, Isaiah wrote: >> >> I recently annotated the license list to give myself (and others) a >> quick-look grasp of the license situation: >> >> >> https://github.com/JuliaLang/julia/commit/d2ee85d1135fd801f1230530f39f05369f6384df >> >> I agree with Tony that in the short-term, distributing a GPL-free binary >> ourselves is not a priority, but pull requests to make the situation >> clearer or to make a GPL-free build simpler would be fine. For example, >> there could be a NO_GPL Makefile variable, and a macro on the Julia side to >> annotate and selectively exclude GPL stuff from the system image (FFTW and >> Rmath should be, respectively, easy and very easy to exclude, however I'm >> not sure how deeply entangled the SuiteSparse stuff is). >> >> >> >> On Thu, Apr 16, 2015 at 10:04 AM, Tony Kelman <[email protected]> wrote: >> >>> It's certainly a long-term goal. 0.4 is far enough behind-schedule >>> already that it's very unlikely to happen by then. Like most things in open >>> source, it's limited by available labor. People who want to see it happen >>> will need to help out if they want it to happen faster. For this particular >>> issue of GPL dependencies, the most useful places to contribute would be >>> helping set up BinDeps for the forked Rmath-julia library so it does not >>> need to be built by base and Distributions.jl can still work well and be >>> easy to install, and asking on the "New DFT API" pull request whether there >>> are specific areas where Steven Johnson needs help - likely answers are >>> benchmarking, conflict resolution to rebase to master, and setting up FFTW >>> as a package with automatic BinDeps etc. >>> >>> Removing things from Base has proven difficult to do smoothly, and while >>> it will be necessary to slim down the mandatory runtime dependencies for >>> embedding, static compilation, and less-restrictive licensing use cases, a >>> lot of work still needs to be done to figure out how to manage code >>> migrations in the least disruptive manner possible. I don't think this is >>> the primary concern of any core Julia developers or contributors at the >>> moment (in fact several people have said they would strongly prefer to not >>> remove any other code from Base until after 0.4.0 is released, and I agree >>> with that), but help and contributions are always welcome. >>> >>> >>> On Wednesday, April 15, 2015 at 6:51:44 AM UTC-7, Sebastian Good wrote: >>>> >>>> Is producing a non-GPL Julia build still on the radar? It might be a >>>> nice goal for the 0.4 release, even if we have to build it ourselves (e.g. >>>> against MKL, etc.) >>>> >>>> On Monday, April 21, 2014 at 5:00:47 PM UTC-4, Steven G. Johnson wrote: >>>>> >>>>> >>>>> >>>>> On Monday, April 21, 2014 4:40:38 PM UTC-4, Tobias Knopp wrote: >>>>>> >>>>>> Yes this is awesome work you have done there. Do you plan to >>>>>> implement the real-data FFT, DCT and DST in pure Julia also? Then one >>>>>> could >>>>>> really think about moving FFTW into a package. Hopefully its author is ok >>>>>> with that ;-) >>>>>> >>>>> >>>>> I plan to implement real-data FFTs, and move FFTW into a package. >>>>> >>>>> Pure-Julia DCT and DST are not in my immediate plans (they are a PITA >>>>> to do right because there are 16 types, of which 8 are common); my feeling >>>>> is that the need for these is uncommon enough that it's not terrible to >>>>> have these in a package instead of in Base. (Hadamard transforms and >>>>> MDCTs are also currently in packages.) >>>>> >>>> >>
