BSON.jl
BSON.jl copied to clipboard
JuliaIO
`setfield!: const field .names of type TypeName cannot be changed` on Julia 1.8
This came up in PkgEval:
Anonymous Functions: Error During Test at /home/pkgeval/.julia/packages/BSON/rOaki/test/runtests.jl:125
Got exception outside of a @test
setfield!: const field .names of type TypeName cannot be changed
Stacktrace:
[1] setproperty!(x::Core.TypeName, f::Symbol, v::Core.SimpleVector)
@ Base ./Base.jl:39
[2] newstruct_raw(cache::IdDict{Any, Any}, #unused#::Type{Core.TypeName}, d::Dict{Symbol, Any}, init::Module)
@ BSON ~/.julia/packages/BSON/rOaki/src/anonymous.jl:136
[3] (::BSON.var"#49#50")(d::Dict{Symbol, Any}, cache::IdDict{Any, Any}, init::Module)
@ BSON ~/.julia/packages/BSON/rOaki/src/extensions.jl:169
[4] raise_recursive(d::Dict{Symbol, Any}, cache::IdDict{Any, Any}, init::Module)
@ BSON ~/.julia/packages/BSON/rOaki/src/read.jl:92
[5] (::BSON.var"#18#21"{IdDict{Any, Any}, Module})(x::Dict{Symbol, Any})
@ BSON ~/.julia/packages/BSON/rOaki/src/read.jl:82
[6] applychildren!(f::BSON.var"#18#21"{IdDict{Any, Any}, Module}, x::Dict{Symbol, Any})
@ BSON ~/.julia/packages/BSON/rOaki/src/BSON.jl:19
[7] _raise_recursive(d::Dict{Symbol, Any}, cache::IdDict{Any, Any}, init::Module)
@ BSON ~/.julia/packages/BSON/rOaki/src/read.jl:82
[8] raise_recursive(d::Dict{Symbol, Any}, cache::IdDict{Any, Any}, init::Module)
@ BSON ~/.julia/packages/BSON/rOaki/src/read.jl:93
[9] (::BSON.var"#49#50")(d::Dict{Symbol, Any}, cache::IdDict{Any, Any}, init::Module)
@ BSON ~/.julia/packages/BSON/rOaki/src/extensions.jl:167
...
PkgEval log: https://s3.amazonaws.com/julialang-reports/nanosoldier/pkgeval/by_hash/f51f24c_vs_2ca8b0c/BSON.primary.log
It seems that the fields names and name of structs cannot be changed any longer since Julia 1.8.
We have a very similar issue in Stipple.jl, where we used setting the name field to provide redefineable structs. This comes in very handy during development.
It does still work without setting the name, but it doesn't look that nice.
@KristofferC Is there a possibility that this change will be revised or do we have to live with it. (I could understand that it is not desired to have names differing from ther variable names.)
Any idea how to work around this? Currently it means that I can not load a Flux model I have...
To be more precise: how would I go about debugging which part of the saved julia object has caused the error?
Any idea how to work around this? Currently it means that I can not load a Flux model I have...
Our work-around was to stay with Julia 1.7.3. 😄
To be more precise: how would I go about debugging which part of the saved julia object has caused the error?
AFAICT it's not about the saved object or BSON file. It's just deserialization code attempts to set the names field which is const as of Julia 1.8. I don't think we care about this field and don't need to set it. BSON.jl should be patched to ignore it, I think.
Well I would like to stick to 1.8 (using a M1 Mac for dev.) and for now the workaround is using JDL2.jl for the saving and Loading but a lot of libraries use BSON internally... I'll try out if something breaks if I just disable the offending line - and if the tests run through ^^
Well I would like to stick to 1.8 (using a M1 Mac for dev.) and for now the workaround is using JDL2.jl for the saving and Loading but a lot of libraries use BSON internally... I'll try out if something breaks if I just disable the offending line - and if the tests run through ^^
Seems like it is not the only field that can not be set... wrapper and mt lead to the same error... As this is a bit over my knowledge of Julia to fix r/n so I'll put it on backburner for now ^^
Is there any news on this issue ? I cannot exploit data I generated with an experiment due to this error. It is on a cluster so I have no control on the julia version.
It is on a cluster so I have no control on the julia version.
You can always just download Julia, extract it and run it. Or you can download the dataset, open it an older Julia version and save it in some other format.
Yeah that’s perhaps what I’ll have to do. Thought it is unideal because the “dataset” is a collection of trained neural nets that I will need to load to do inference with them. Doing it on my workstation will work but it will take significantly more time. If I had to retrain them however, I’d be stuck.
Is this fundamentally unfixable in 1.8 ?
From: Kristoffer Carlsson @.>
Sent: vendredi 21 octobre 2022 15:21
To: JuliaIO/BSON.jl @.>
Cc: Henri Dehaybe @.>; Comment @.>
Subject: Re: [JuliaIO/BSON.jl] setfield!: const field .names of type TypeName cannot be changed on Julia 1.8 (Issue #109)
It is on a cluster so I have no control on the julia version.
You can always just download Julia, extract it and run it. Or you can download the dataset, open it an older Julia version and save it in some other format.
— Reply to this email directly, view it on GitHubhttps://github.com/JuliaIO/BSON.jl/issues/109#issuecomment-1287350205, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALG3VIDBWM2RRMLDCQS26WLWELUITANCNFSM5O2NO5YA. You are receiving this because you commented.Message ID: @.@.>>
I see the Serialization stdlib already has routines which handle this and would naturally be more robust to Julia version bumps: https://github.com/JuliaLang/julia/blob/81813164963f38dcd779d65ecd222fad8d7ed437/stdlib/Serialization/src/Serialization.jl#L1296. Any reason BSON.jl couldn't use these instead of rolling its own (assuming there is anyone around to do so)?
The dg/anon branch should help get things running with a small caveat. It requires using invokelatest on the deserialised objects at the moment. I think i know how to address that but it should allow folks to try and use it now anyway.
