Jacob Quinn

Some thoughts/initial work at increasing capacity in Parsers.jl: https://github.com/JuliaData/Parsers.jl/pull/98

I tried this a few more times and I'm seeing consistent results. Closing the notebook, choosing "Close and halt", clicking "Shutdown" or "Delete" even, none of these result in the...

Yes, still happening. I haven't had a chance to dig or explore any more, but I still can only kill the julia process by stopping the ipython command line app...

I ran into this little nugget perusing the IPython source: > # FIXME: Shutdown does not work on Windows due to ZMQ errors! > if now or sys.platform == 'win32':...

I'm not sure if it's the same ZMQ error, but I've noticed in developing my own ZMQ backend for Sublime-IJulia that trying to destroy the ZMQ context seems to error...

Certainly interesting to think about; related to `CSV.Chunks`, but would require quite a bit different implementation. I agree that I think it would require a pass to find the right...

There have been known issues with Juno/Atom having stale "baked in" versions of CSV.jl dependencies; there was also recently a bug that affected precompilation for 1.7 (though it was only...

What I've been told by core developers is that Julia 1.7 is not well supported for M1 architecture, but 1.8 should work much better (which is currently in beta and...

Pinging @piever to chime in, but as I understand it, a `StructArray` is a valid Tables.jl _source_, but doesn't currently have a _sink_ interface. i.e. the generic fallback `StructArray(x)` definitions...

It seems like `StructArray∘Tables.columntable` is the way to go to me. `CSV.read` is pretty well documented that you need to pass a valid sink function; `materializer` is usually just for...