Thanks Cedric and Tim.
Tom (@tbreloff on github) had suggested status tags[0] for tagging
packages on various criteria, or stages of development. He wrote a
script which I merged, so it would be nice if various package authors
submitted data for their package status.
If this works, then perhaps we
I wonder if anyone has ever tried to build a "package2vec" or even
"function2vec", along the lines of "word2vec". There's so much usable
information in code and comments, and it would be cool to provide that info
in an Atom tooltip, say.
On Monday, March 28, 2016 at 9:40:59 AM UTC-4, Tim Holy
I sometimes find https://github.com/svaksha/Julia.jl can be useful. It's a hard
problem to keep all this organized, though, so more searchable tools might be
a good idea. I'm not aware of any efforts to provide this, so it seems like an
area ripe for an impactful contribution!
--Tim
On
Jean-François, have you looked at Julia.jl? No tags, but it's nicely
categorized.
On Sunday, March 27, 2016 at 10:11:16 PM UTC-4, Jean-François Baffier wrote:
>
> Maybe I missed a a more recent thread but I would like how things are
> going for the packages organization. It is currently hard to
Skimming pkg.julialang.org is pleasantly impossible with 904 registered
packages. This smells exponential growth.
Is there a tool to simply download the text files in all of the packages?
Last time I checked, I wasn't able to do that with github commands.
I think it would be impossible to
Maybe I missed a a more recent thread but I would like how things are going
for the packages organization. It is currently hard to look for a package
when you know what functionality you're looking. It is even harder when you
look for something general.
What about a tag list ? (keywords
That's fair – I'm not entirely sure those should all go in one
organization, but it suppose it could be helpful to have a sort of
catch-all organization for mathematical packages that don't yet have a more
specialized organization to live in.
On Thu, Jan 29, 2015 at 10:41 AM, Hans W Borchers
JuliaMAT does seem like a clearer org name for Matlab/Octave compatibility
and support.
On Thu, Jan 29, 2015 at 9:24 AM, Viral Shah vi...@mayin.org wrote:
If the goal is to support MATLAB-like capabilities and syntax, perhaps
JuliaMAT is the right organization name. This could have a variety
JuliaMath seems far too broad for a name for an organization. But a
JuliaNumberTheory org or something would be good. Not a pithy name, so
something better would be welcomed.
On Jan 29, 2015, at 9:55 AM, Hans W Borchers hwborch...@gmail.com wrote:
No, the intention was not to just include
I don't know what organizations would look like in this area, but more
generally, there's been discussion around discoverability of packages. Even
for a set of packages that would get no advantage development- or
consistency- wise from bringing them under an organization (or if there's
not
If the goal is to support MATLAB-like capabilities and syntax, perhaps JuliaMAT
is the right organization name. This could have a variety of matlab
compatibility packages, .mat file readers, compatibility packages, MATCall, etc.
-viral
On 29-Jan-2015, at 4:37 pm, Hans W Borchers
Our METADATA design allows us to have, for example, a curated METADATA - much
like Debian’s stable, testing, etc. Packages meeting certain criteria are the
only ones that could go into the curated METADATA.
-viral
On 29-Jan-2015, at 5:52 pm, Steven Sagaert steven.saga...@gmail.com wrote:
No, the intention was not to just include MATLAB-like capabilities and
syntax.
I would like to have a JuliaMath organization that could encompass all kinds
of mathematical and numerical packages. For example also some packages with
algebraic number theory or elliptic curves functionality, that
There's not so much about number theory at the moment, it's more a prospect
of
future contributions.
How would you name an organization that, e.g., could include packages like
Calculus[2], Roots
Polynomial[s], TaylorSeries
Elliptic, LambertW
ApproxFun, ApproxXD, Grid, Dierckx
Organizations only make sense when there are:
a) a critical mass of contributors focused around a common theme, and
b) the theme is sufficiently focused to the extent that common code
infrastructure can be shared and reused.
Correct me if I'm wrong, but I simply don't see how the proposed list
I absolutely agree, and your description is very helpful in understanding
what
a Julia organization shall be.
But see, then Julia organizations are not an equivalent to CRAN Task
Views.
There should exist something inbetween an organization and the package list,
maybe a classification
I think the approach should be to add keywords/labels to the package
metadata.
On Thu, Jan 29, 2015 at 3:18 PM, Hans W Borchers hwborch...@gmail.com
wrote:
I absolutely agree, and your description is very helpful in understanding
what
a Julia organization shall be.
But see, then Julia
I have found the curated deibans by research topic from svaksha very
useful when looking for a certain method:
https://github.com/svaksha/Julia.jl
+1 Steven Sagaerts comment on less is more, coming from an experienced R
user.
On Thursday, 29 January 2015 23:13:37 UTC+1, Stefan Karpinski
Great that so many are contributing to Julia, but I would question whether such
a large number of packages will be healthy in the long run. It will make it
very difficult for new users to use Julia effectively.
Just noticed on http://pkg.julialang.org/pulse.html that we are at 499
registered packages with at least one version tagged that are Julia 0.4-dev
compatible (493 on Julia 0.3).
Thanks to all the package developers for their efforts in growing the Julia
package ecosystem!
20 matches
Mail list logo
