Andrei Zhabinski

I'm definitely ok with registering a new version. I think I already set version 0.3.0 in Project.toml in one of tge PRs, so we don't need to bump it any...

I reverted the version to 0.2 (the latest registered is 1.1), but JuliaHub doesn't let me register the package: > User dfdx is not a member of the org FluxML...

Let's revive this issue. If I understand correctly, we are stuck on a Julia-friendly representation of ONNX graphs, either in a form of computational graph, or in a form of...

> As for the repeated vertex issue, I'd totally forgotten about it!. This is something we've been trying to work out recently because it affects all weight tying. See FluxML/Flux.jl#1592,...

In a quickly evolving discussion I forgot to answer @DrChainsaw 's questions! > Ghost looks awesome and I absolutely see how I would love to throw out the ad-hoc tracing...

> Do we want the operators in this repo? I suppose they might be dead weight for e.g. ONNX2Flux.jl unless one tries to first load the model in the generic...

Here's a [draft of the loader](https://github.com/dfdx/ONNX.jl/blob/dfdx/tape/src/load.jl) based on `Ghost.Tape`. It only partially implements a single operation (`Conv`) and replaces all the others with `identity`, but with `eval=false` (i.e. not trying...

I've added a few more operations and created [the PR][1] to easier track the changes. So far adding/migrating operations is easy as long as there's a counterpart in NNlib. Unfortunately...

> Any thoughts on `Val`-dispatch vs dict of functions with op as key? I see 2 ways to implement replacement of an operation: 1. Using a global dict to store...

> The main loading function will loop over `ctx.backends` calling `load_node!` accordingly. Oh, sorry, I misinterpreted your idea and thought of backends as a way to replace particular operations, not...