Nathan Zimmerberg
Nathan Zimmerberg
This seems to be indirectly causing some issues. Ref: https://github.com/JuliaIO/TranscodingStreams.jl/issues/234
VariantCallFormat.jl looks to support Automa v1 now, thanks to https://github.com/rasmushenningsson/VariantCallFormat.jl/pull/17
So that you know, ZipFile.jl can be super slow when compressing large files: https://discourse.julialang.org/t/file-zipping-taking-longer-for-large-files/115963. I made https://github.com/JuliaIO/ZipArchives.jl to save Zarr data in a `.zip` file, but it might also be...
From what I can tell, the underlying C library is not threadsafe, so this package doesn't attempt to be threadsafe either. Maybe this should be better documented?
I fixed this by using: ```julia using Meshing: MarchingTetrahedra, isosurface using GeometryBasics: Mesh, TriangleFace, Vec, Point xr,yr,zr = ntuple(_->LinRange(-1,1,50),3) f = x -> sum(sin, 5 * x) sdf = [f(Vec(x,y,z))...
> Interesting approach. We may still want to consider the finalizer. Yes, having a finalizer should be compatible with this PR, and would also prevent memory leaks.
@mkitti Could you review this PR again, I think I addressed your comments.
It has some minor conflicts that need to be resolved. I also want to try to maintain support for older versions of TranscodingStreams.
This is waiting on #84
Maybe the `initialize` and `finalize` methods in this package can be removed, and instead initialize on construction and finalize using a finalizer?