Pkg.jl
Pluto.jl
Pkg.jl | Pluto.jl | |
---|---|---|
5 | 78 | |
603 | 4,880 | |
1.0% | - | |
9.0 | 9.5 | |
3 days ago | 4 days ago | |
Julia | JavaScript | |
GNU General Public License v3.0 or later | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Pkg.jl
-
Julia 1.9 Highlights
There was a "bug" (or just unhandled caching case) that effected the Pluto notebook system that required precompilation each time. This is because Pluto notebooks kept a manifest (so they always instantiated with the same packages every time for full reproducibility) and the instantiation of that manifest triggered not just package running but also precompilation. That was fixed in https://github.com/JuliaLang/Pkg.jl/pull/3378, with a larger discussion in https://discourse.julialang.org/t/first-pluto-notebook-launc.... That should largely remove this issue as in included in the v1.9 release (it was first in v1.9-RC2 IIRC).
-
Unable to load PDMats package.
The closest thing I got to is this and I don't even understand what they are saying.
-
Why Fortran is easy to learn
Julia's compiler is made to be extendable. GPUCompiler.jl which adds the .ptx compilation output for example is a package (https://github.com/JuliaGPU/GPUCompiler.jl). The package manager of Julia itself... is an external package (https://github.com/JuliaLang/Pkg.jl). The built in SuiteSparse usage? That's a package too (https://github.com/JuliaLang/SuiteSparse.jl). It's fairly arbitrary what is "external" and "internal" in a language that allows that kind of extendability. Literally the only thing that makes these packages a standard library is that they are built into and shipped with the standard system image. Do you want to make your own distribution of Julia that changes what the "internal" packages are? Here's a tutorial that shows how to add plotting to the system image (https://julialang.github.io/PackageCompiler.jl/dev/examples/...). You could setup a binary server for that and now the first time to plot is 0.4 seconds.
Julia's arrays system is built so that most arrays that are used are not the simple Base.Array. Instead Julia has an AbstractArray interface definition (https://docs.julialang.org/en/v1/manual/interfaces/#man-inte...) which the Base.Array conforms to, and many effectively standard library packages like StaticArrays.jl, OffsetArrays.jl, etc. conform to, and thus they can be used in any other Julia package, like the differential equation solvers, solving nonlinear systems, optimization libraries, etc. There is a higher chance that packages depend on these packages then that they do not. They are only not part of the Julia distribution because the core idea is to move everything possible out to packages. There's not only a plan to make SuiteSparse and sparse matrix support be a package in 2.0, but also ideas about making the rest of linear algebra and arrays themselves into packages where Julia just defines memory buffer intrinsic (with likely the Arrays.jl package still shipped with the default image). At that point, are arrays not built into the language? I can understand using such a narrow definition for systems like Fortran or C where the standard library is essentially a fixed concept, but that just does not make sense with Julia. It's inherently fuzzy.
-
MlJ.jl: A Julia Machine Learning Framework
This is exacerbated by the fact that Julia's Pkg.jl does not yet support conditional/optional dependencies [0]. A lot of these meta packages tend to pull everything but the kitchen sink.
[0]: https://github.com/JuliaLang/Pkg.jl/issues/1285
-
Adding packages in Julia extremely painful
The LTS release is over two years old, and Julia has received a lot of developer attention since then, resulting in new features and performance improvements that tutorial authors don't want to do without. You can safely use the latest stable release (v1.5.3), although you may also want to apply the Git registry fix (https://github.com/JuliaLang/Pkg.jl/issues/2014#issuecomment-730676631) for further improvements in download/setup speed.
Pluto.jl
-
Potential of the Julia programming language for high energy physics computing
I thought that notebook based development and package based development were diametrically opposed in the past, but Pluto.jl notebooks have changed my mind about this.
A Pluto.jl notebook is a human readable Julia source file. The Pluto.jl package is itself developed via Pluto.jl notebooks.
https://github.com/fonsp/Pluto.jl
Also, the VSCode Julia plugin tooling has really expanded in functionality and usability for me in the past year. The integrated debugging took some work to setup, but is fast enough to drop into a local frame.
https://code.visualstudio.com/docs/languages/julia
Julia is the first language I have achieved full life cycle integration between exploratory code to sharable package. It even runs quite well on my Android. 2023 is the first year I was able to solve a differential equation or render a 3D surface from a calculated mesh with the hardware in my pocket.
- Pluto.jl: Simple, reactive programming environment for Julia
-
Ask HN: Why don't other languages have Jupyter style notebooks?
Re Julia there is also pluto.jl that is another notebook-like environment for julia. It's been a few years since I played with it but it looked cool, for example it handles state differently so you don't get into the same messes as with ipython notebooks. https://plutojl.org/
- Pluto: Simple Reactive Notebooks for Julia
-
Looking for a Julia gui framework with a demo like EGUI
For this, Notebooks are often used. Julia offers a uniquely nice and interactive Pluto notebook for the web https://github.com/fonsp/Pluto.jl
- Excel Labs, a Microsoft Garage Project
-
IPyflow: Reactive Python Notebooks in Jupyter(Lab)
I believe this is what Pluto sets out to do for Julia.
I used it as part of the āComputational Thinkingā with Julia course a year or two back. Even then the beta software was very good and some of the demos the Pluto dev showed were nothing short of amazing
https://plutojl.org/
- For Julia is there some thing like VSCode's python interactive window?
-
What have you "washed your hands of" in Python?
I think what you want is Pluto!
-
Show HN: Out of order execution in Jupyter notebooks is a solved problem
I like how Pluto.jl handles this:
> Pluto offers an environment where changed code takes effect instantly and where deleted code leaves no trace. Unlike Jupyter or Matlab, there is no mutable workspace, but rather, an important guarantee:
> At any instant, the program state is completely described by the code you see.
[1] https://github.com/fonsp/Pluto.jl
What are some alternatives?
TriangularSolve.jl - rdiv!(::AbstractMatrix, ::UpperTriangular) and ldiv!(::LowerTriangular, ::AbstractMatrix)
vim-slime - A vim plugin to give you some slime. (Emacs)
maptrace - Produce watertight polygonal vector maps by tracing raster images
rmarkdown - Dynamic Documents for R
AutoMLPipeline.jl - A package that makes it trivial to create and evaluate machine learning pipeline architectures.
Weave.jl - Scientific reports/literate programming for Julia
parca-demo - A collection of languages and frameworks profiled by Parca and Parca agent
Dash.jl - Dash for Julia - A Julia interface to the Dash ecosystem for creating analytic web applications in Julia. No JavaScript required.
Fortran-code-on-GitHub - Directory of Fortran codes on GitHub, arranged by topic
IJulia.jl - Julia kernel for Jupyter
llvm-project - Fork of https://github.com/llvm/llvm-project
Tables.jl - An interface for tables in Julia