Good First Issues in Julia

src/ecdf.jl consists of a single deprecation: @deprecate ECDF(x) StatsBase.ecdf(x) The replacement refers to the module name StatsBase, which is not bound inside QuantEcon: the package only does using StatsBase: ecdf and import StatsBase: sample, and neither brings the module name into scope. Every call to ECDF therefore fails: julia> using QuantEcon julia> ECDF([1.0, 2.0, 3.0]) ERROR: UndefVarError: `StatsBase` not defined in `QuantEcon` The deprecation was added in #196 (2017, first released in v0.14.1), and the import was already selective at that commit. The tests only cover ecdf, so the failure has gone unnoticed. Proposal Remove the deprecation: delete src/ecdf.jl and its include in src/QuantEcon.jl. Since no call to ECDF can have worked, there is nothing left to deprecate. ecdf, which QuantEcon re-exports from StatsBase, is not affected. The alternative is to repair it as `@deprecate` ECDF(x) ecdf(x), which works, but that would revive a name that has been unusable for years on

I was working on speeding up the RGB<->XYZ conversion 7 years ago. (cf. issue #351) The problem is v^2.4 and v^(1/2.4) used in the so-called gamma curve of sRGB. In the end, for the RGB{N0f8}→XYZ{Float32} conversion, I chose to use LUTs. Using LUTs is probably the fastest approach for CPU computation. For GPU computation as well, a Float32 × 256 LUT is small enough that I don't think it would become a bottleneck. However, when using a LUT, some form of instruction is required to make it shareable on the GPU. (cf. issue #587) Since this package deals with colors rather than images, AFAIK there is no way for the method or compiler to determine whether the data is in a GPU array or a CPU array. (From a long-term perspective, we might end up implementing ColorsGPUCompilerExt etc., but it is too large a project for me to shoulder alone.) If we were to stop using a LUT in order to improve GPU suitability, how much slowdown on the CPU would be acceptable? Edit: Further consideration is sti

Some values for some parameters in the CSG primitives would not make sense, for example negative values for the radius of a sphere, etc. We should revisit all constructors with the aim of: restricting parametric types to what's allowed in the docstring verifying the input parameters and throwing errors if they do not make sense For example, struct Ellipsoid{T,CO,TR<:T,TP<:Nothing,TT<:Nothing} <: AbstractVolumePrimitive{T, CO} r::TR φ::TP θ::TT origin::CartesianPoint{T} rotation::SMatrix{3,3,T,9} function Ellipsoid{T,CO,TR,TP,TT} where {T,CO,TR,TP,TT} if r < 0 throw(ArgumentError("Radius $(r) of ellipsoid is negative")) end if !isnothing(φ) throw(ArgumentError("Only full ellipsoids in φ are supported")) end if !isnothing(θ) throw(ArgumentError("Only full ellipsoids in θ are supported")) end if !isrotation(rotation) throw(ArgumentError("The matrix $(rotation) does not describe a rotation")) end new{T,CO,TR,TP,TT

The following program: f(x) = Core.bitcast(Core.LLVMPtr{UInt32,1}, x) f(0.0) makes Julia report: IntToPtr source must be an integral %8 = inttoptr double %1 to ptr addrspace(1), !dbg !17 LLVM ERROR: Broken module found, compilation aborted! [219902] signal 6 (-6): Aborted in expression starting at /tmp/test.jl:2 pthread_kill at /lib/x86_64-linux-gnu/libc.so.6 (unknown line) gsignal at /lib/x86_64-linux-gnu/libc.so.6 (unknown line) abort at /lib/x86_64-linux-gnu/libc.so.6 (unknown line) _ZN4llvm18report_fatal_errorERKNS_5TwineEb.cold at /home/fuzz/WorkSpace/fusion-fuzz/projects/julia/julia-src/usr/bin/../lib/libLLVM.so.22.1jl (unknown line) _ZN4llvm18report_fatal_errorEPKcb at /home/fuzz/WorkSpace/fusion-fuzz/projects/julia/julia-src/usr/bin/../lib/libLLVM.so.22.1jl (unknown line) _ZN4llvm12VerifierPass3runERNS_6ModuleERNS_15AnalysisManagerIS1_JEEE at /home/fuzz/WorkSpace/fusion-fuzz/projects/julia/julia-src/usr/bin/../lib/libLLVM.so.22.1jl (unknown line) run at /home/fuzz/WorkSpace/

I don't have time to work on this repo anymore, so looking for maintainers to help. @FedeClaudi, should we transfer the repo to an organisation to ease maintaining ?

Inside a @compile trace, Core.Compiler.return_type (and therefore Base.promote_op) reports a non-concrete Union{TracedRArray, TracedRNumber} for reductions over a TracedRArray. Outside a trace, inference of the very same call is exact. MWE Only dependency is Reactant: using Reactant using Reactant: TracedRArray function f(v) println("inside a trace: ", Core.Compiler.return_type(sum, Tuple{typeof(v)})) return sum(v) end println("outside a trace: ", Base.infer_return_type(sum, (TracedRArray{Float32, 1},))) x = Reactant.to_rarray(rand(Float32, 4)) @compile f(x) outside a trace: Reactant.TracedRNumber{Float32} inside a trace: Union{TracedRArray, Reactant.TracedRNumber} Scope Not every call is affected — it is specifically the reductions that go from an array to a scalar. Querying return_type from inside a trace: call inferred inside a trace inferred outside identity(::TracedRArray{Float32,1}) TracedRArray{Float32, 1} same length(::TracedRArray{Float32,1}) Int64 same

Hey there! I just ran into this very sneaky edge case, don't have a simple MWE but the error message should be sufficient. It happens when broadcasting over zero-dimensional arrays (aka scalars). ERROR: MethodError: similar(::Base.Broadcast.Broadcasted{…}, ::Type{…}, ::Tuple{}) is ambiguous. Candidates: similar(::Base.Broadcast.Broadcasted{Reactant.TracedRArrayOverrides.AbstractReactantArrayStyle{N}}, ::Type{<:Reactant.TracedRNumber{T}}, dims) where {T<:Union{Complex{Int16}, Complex{Int32}, Complex{Int64}, Complex{Int8}, Complex{UInt16}, Complex{UInt32}, Complex{UInt64}, Complex{UInt8}, Core.BFloat16, Bool, Float16, Float32, Float64, Int16, Int32, Int64, Int8, UInt16, UInt32, UInt64, UInt8, Reactant.F8E4M3B11FNUZ, Reactant.F8E4M3FN, Reactant.F8E4M3FNUZ, Reactant.F8E5M2, Reactant.F8E5M2FNUZ, ComplexF64, ComplexF32}, N} @ Reactant.TracedRArrayOverrides ~/.julia/packages/Reactant/ct5sa/src/TracedRArray.jl:298 similar(::Base.Broadcast.Broadcasted{Reactant.TracedRArrayOverrides

bubble/dew, LLE, VLLE, and other equilibrium functions spinodals SLE functions electrolyte functions The work is mechanical: strip the units at the start (ustrip) , then add the corresponding units back at the end (with_output_unit). Some notes: no output input argument, it will probably be removed on future versions, one can just define output = nothing inside the code of each method to make the implementation easier compositions have mol units, molar fractions do not need units.

with the new unitful system in place, one could tentatively add a lightweight unit system that only handles our input units. One problem that i have with Unitful.jl is that it does not handle mass fractions; a mass fraction is in the "nullspace" of units (mass/mass). We can simulate molar fractions by passing molar amounts that sum to one, and we can pass mass amounts via Units, but mass fractions are still not handled. If someone is interested, it just needs to overload uzstrip (#624)

Describe the feature you'd like to have I mean, this looks just incredible: https://github.com/fredrikekre/DocumenterCodeBlocks.jl Given that our document is structured primarily around a main tutorial and multiple runnalbe examples, this is just fantastic! If possible we can start implementing it package by package!

As discussed in this discourse thread by @tpapp, it might be nice to have an unsplat function that is the semantic inverse of splat (it takes a function of a tuple and turns it into a function of separate arguments). Implementation could be as simple as: import Base: Splat, splat # for testing this code outside of Base """ unsplat(f) Given a function `f(t)` that takes a single tuple `t` of parameters, return a function `g = unsplat(f)` that behaves similar to `g(args...) = f(args)`; that is, `unsplat(f)` accepts the arguments as separate parameters and bundles them together into a tuple for `f`. This function is the inverse of [`splat`](@ref). """ unsplat(f) = f ∘ tuple # make splat and unsplat literal inverses of one another unsplat(s::Splat) = s.f splat(f::ComposedFunction{<:Any,typeof(tuple)}) = f.outer

I found that the link for deal.II step-7 on Helmholtz equation gives an error as Am I right ? Is that my PC or for all is the same ? Maybe it is not a big deal.

I had Claude generate a mortar contact implementation and then asked what was awkward about it. This is what it wrote. Putting it up in case it could be useful. 🤖 desires for contact 🤖 What Ferrite needs to provide for contact mechanics on top Ferrite's role is to provide general FEM building blocks; algorithms like contact belong in satellite packages (a future FerriteContact.jl / FerriteMortar.jl). This document derives, from the requirements of a proper contact solver, the primitives such a package needs from Ferrite core — what exists today, what is missing, and what the smallest useful core additions would be. 1. What a contact solver has to do Any serious contact package ends up with this pipeline, independent of the specific method: Search: find candidate surface pairs (broad phase), then closest-point / ray projections between non-matching surfaces (narrow phase), in the current (deformed) configuration. Pairing/integration domains: node-to-segment pairs (NTS), or mo

I think it's good to have a AMR roadmap for the various open topics left. The ordering is driven by dependencies and API instead of importance. Happy to discuss and reorder. (Already discussed with the lazy guy @claude) Roadmap #1413 — ForestBWG as the grid (lazy materialization facade, drop NonConformingGrid) First because every later item touches the boundary it reshapes: where conformity_info lives, what materialization emits, and the cell-numbering lifecycle / reclose!. Landing it last would mean building those against NonConformingGrid + explicit creategrid and churning them afterwards. It's also the smallest of the five. #1411 — Transient adaptivity: old-to-new cell id map and solution transfer Biggest user-facing unlock (time-dependent problems), and deliberately scoped to linear Lagrange, so it needs nothing from #1409/#1410. It composes naturally with the facade: the epoch bump in refine!/coarsen! is exactly the moment to emit the old-to-new map, and reclose! is its nat

This is essentially porting the CUDA extension to AMDGPU . This comes primarily down to the registration of the matrix formats.

Right now the device assembler is a separate struct without the sorting logic and without the atomics. We should merge the device assembler with the other assemblers to keep features parity without duplicating the code.

Description DocumenterVitepress.jl is a more modern frontend for Documenter, based on vitepress. It has grown significantly in popularity, and is used to host docs for frameworks such as Makie.jl. I think it would be nice to offer users the option to use vitepress during the onboarding process and set it up for them. Validation and testing The setup is not much more complicated than base Documenter, but it does generate some more files which need validation. You get new .vitepress/ and components/ folders which host several vue and typescript assets. The build process also differs slightly from base documenter, see getting started. Docs are served from docs/build/1, which can trip you up. Motivation Described above Target audience Anyone who is motivated by great, modern looking docs. Can you help? Ofcourse

#780 adds adaptive mesh refinement for Quadrilateral (2D) and Hexahedron (3D) grids via a p4est-style forest of octrees (ForestBWG). The same machinery could support Line grids in 1D — a forest of binary trees — but this is deliberately left out of the initial PR (review discussion). Compared to the 2D/3D case, 1D is structurally much simpler, which makes this a nice self-contained follow-up: OctantBWG{1, 2} ("bintant"): 1 coordinate, level + x; Morton index degenerates to the plain binary code, children/parent/vertices are one-liners. The inter-tree connectivity is trivial: a macro edge ("tree face") is a single vertex shared by at most two trees, so there are no orientations, no corner/edge permutation tables (ℛ/𝒬/𝒫 etc. are not needed at all) — the transform machinery collapses to a mirror-or-shift of one coordinate. 2:1 balancing reduces to vertex balancing; there are no hanging nodes in a conforming sense (a refined/unrefined interface meets in a shared vertex), so

julia> s = "x;;;; y" "x;;;; y" julia> ft(s) "x;;;;\ny" There's an argument here that we should get rid of three of those semicolons.

The following warnings are being emitted by our test suite: Warning: maximum number of subdivisions reached `maxsubdiv=32768`, try increasing the keyword argument `maxsubdiv`. └ @ HAdaptiveIntegration ~/.julia/packages/HAdaptiveIntegration/OeagO/src/integrate.jl:120 ┌ Warning: maximum number of subdivisions reached `maxsubdiv=32768`, try increasing the keyword argument `maxsubdiv`. └ @ HAdaptiveIntegration ~/.julia/packages/HAdaptiveIntegration/OeagO/src/integrate.jl:120 As far as I know, there is no method to print the exact lines that are emitting the warning, so we need to run tests one by one in the REPL to discover the root of the issue. It is likely emitted by some test that calls centroid as we changed the fallback to use h-adaptive integration.

Just to clarify - in your paper you mention testing on Frontier, but in both the README and the tests you report it to be broken. If it is not working, what are the blockers? Thank you in advance!

Can there be consideration for an alternative @data usage syntax as follows? @data module MyType Variant1 Variant2 end This is a wild, change-of-syntax request. I believe it can be added in without breaking current syntax. But I have at least two reasons why: It reduces friction with linters regarding false errors regarding namespace clashes. For example: This linting error is quite annoying. Happy for a workaround if anyone has one, especially if @data module is decided to not be planned. Edit: I think let works, haven't tried all Moshi feature with it yet. Edit 2: let does not work - it just gets rid of the linted error: ERROR: LoadError: ArgumentError: expect begin ... end block, got let It helps convey - especially to those new to the package (e.g. #49) that @data is helping to construct a module.

Issue Description When using the SlabOceanSST surface model, any surface temperature specified via surface_condition in a case setup file (under src/setups/) is silently overwritten during model initialization. The overwrite occurs in src/config/model_getters.jl L835, where the slab ocean's prognostic sea surface temperature is initialized from values defined in src/setups/common/prognostic_variables.jl L216. This is the correct and intended behavior for SlabOceanSST — the surface temperature is a prognostic variable owned by the slab ocean component and should not be externally prescribed — but because no warning is emitted, users who have also specified a surface_condition temperature in their case setup may not realize their value is being ignored. This is particularly likely to cause confusion when adapting an existing case (which may have a prescribed SST set via surface_condition) to use SlabOceanSST, or when debugging a case where the expected initial surface temperature is

Would it be possible to add an option that controls the whitespace surrounding (nested) brackets? I'm one of the few people that think the following f( g( h( a[ 1 ] ), b ) ) is more readable than f(g(h(a[1]), b)) The above example is a bit extreme but even just h( a[ 1 ], b ) looks nicer to me than h(a[1], b) I assume whitespace lovers don't really agree on whether f( g( x ) ) is better than f( g(x) ) (i.e. extra whitespace after every opening and before every closing bracket vs only for nested brackets) so I would propose to have two options extra whitespace only for nested expressions. The inner most brackets of any subexpression have regular spacing. f(g(h(a[1], b), k(x))) would become f( g( h( a[1], b ), k(x) ) ) extra whitespace after every opening and before every closing bracket f(g(h(a[1], b), k(x))) would become f( g( h( a[ 1 ], b ), k( x ) ) ) I'm sorry if this is too much of a niche request and I hope I don't start a flamewar here (a bit hard to avoid though when posting

We still need to adjust the code in a few places to get full interactivity within our recipes. For instance, consider the following MWE: using Meshes using Random import GLMakie as Mke boxes = rand(Box, 10) balls = rand(Ball, 10) tetra = rand(Tetrahedron, 10) geoms = shuffle([boxes; balls; tetra]) fig = Mke.Figure() sld = Mke.Slider(fig[1, 1], range=1:length(geoms)) ax3 = Mke.Axis3(fig[2, 1], aspect=:data) sub = Mke.@lift geoms[1:$(sld.value)] viz!(ax3, sub) Mke.on(sld.value) do i Mke.autolimits!(ax3) end fig Because the slider starts with only the first geometry, the direct access to plot[objectid][] registers a single recipe in the compute graph, no matter how much we move the slider: Meshes.jl/ext/geomset.jl Line 14 in 416dfeb geoms = parent(plot.object[]) We need to refactor the code to handle heterogeneous vectors of geometries. There are other places that rely

the intent of the pre-commit config is presumably to make sure that JuliaFormatter is formatted with the current version of itself. JuliaFormatter.jl/.pre-commit-config.yaml Line 8 in 09da91d entry: "jlfmt --inplace" however invoking jlfmt does not necessarily achieve that as jlfmt could be literally any version of JuliaFormatter. it will only give the right behaviour if the person running it has done ]app dev . before that.

The following never finishes for me, the julia process just keeps spinning at 100%: julia> import GeoArtifacts julia> using GeoTables julia> using Meshes #using Plots julia> using CairoMakie julia> BRA = GeoArtifacts.GADM.get("BRA", depth = 0) 1×3 GeoTable over 1 GeometrySet ┌─────────────┬─────────────┬───────────────────────────────┐ │ GID_0 │ COUNTRY │ geometry │ │ Categorical │ Categorical │ MultiPolygon │ │ [NoUnits] │ [NoUnits] │ 🖈 GeodeticLatLon{WGS84Latest} │ ├─────────────┼─────────────┼───────────────────────────────┤ │ BRA │ Brazil │ Multi(1007×PolyArea) │ └─────────────┴

Consider: s = """ (; a= >=(1)) (; a=2) (; a=+2) (; a=+x) (; a=+x/2) (; a=+(2)) """ using JuliaFormatter: format_text as ft ft(s; whitespace_in_kwargs=false) |> println Looking at #360 and #361 the real underlying reason behind that PR was to make sure that the first of the above did not get converted into (; a=>=1), which would fail to parse as => is an operator. However, looking at the actual code in #361 it's very clear that the intent was to parenthesise anything on the RHS that began with an operator. This is overly cautious, because =+ is not a valid operator and thus things like (; a=+x) parse totally fine. Now, recent versions of JuliaFormatter have led to changes in the underlying operator-detection mechanism. This is the outcome with several different versions of JuliaFormatter: v1.0.62 v2.5.2 # 1011 (; a=(>=(1))) (; a=(>=(1))) (; a=(>=(1))) (; a=2) (; a=2) (; a=2) (; a=+2) (; a=+2) (; a=+2) (; a=+x) (; a=(+x)

TODO for a new minor release : fix Highlights with JuliaDocs/Highlights.jl#81; fix #281; ...

Basic support for polydeg = 0 on the TreeMesh was implemented in #1489, including a specialization of the plotting routines using Plots.jl. It would be nice to extend this plotting support to higher dimensions. For example, I currently get julia> using Trixi, Plots julia> equations = LinearScalarAdvectionEquation2D(1.0, 1.0) ┌──────────────────────────────────────────────────────────────────────────────────────────────────┐ │ LinearScalarAdvectionEquation2D │ │ ═══════════════════════════════ │ │ #variables: ……………………………………………………………… 1