Sheehan Olver comments

Results 1181 comments of


                                            Sheehan Olver

prevent loading other extensions when precompiling an extension

Put another way: if package B depends on A, then it’s natural that an extension for B depends on an extension on A

prevent loading other extensions when precompiling an extension

I don't understand your example. What's the alternative solution? It might be possible I can move functions/types into LazyArrays.jl in this case. But it seems like a major flaw in...

prevent loading other extensions when precompiling an extension

I still don’t understand the issue being solved. A directed tree doesn’t form cycles….

prevent loading other extensions when precompiling an extension

I think I need a mathematical description to be convinced it’s not an implementational issue. Packages with (or without) extensions are simply a tree. How does a cycle come up?...

prevent loading other extensions when precompiling an extension

Could a simple solution be that if an extensionA depends on extensionB it needs to list it in the Project.toml? I.e. https://github.com/JuliaArrays/LazyArrays.jl/blob/d3e51078551d98ba951525931c77b2f259bfea29/Project.toml#L25 Would become ``` LazyArraysBlockBandedMatricesExt = ["LazyArraysBandedMatricesExt", "BlockBandedMatrices"] ```

Move SparseArrays dependency to extension

"my_" is a very bad naming convention. I have no idea what these are for!

Move SparseArrays dependency to extension

I think even just beginning with`_` would be fine, eg., `LazyArrays._issparse`.

Move SparseArrays dependency to extension

But we would need a comment explaining the design

Move SparseArrays dependency to extension

If you bump the minor version (1.x) I can merge and tag

Extremely slow BLAS muladd when α,β are Int

Note that `mul!` uses native BLAS, where `default_blasmul!` and `tiled_blasmul!` are Julia code, that were copied from LinearAlgebra. Here gives an indication of what's going on: ```julia julia> @time mul!(C,...