YAML custom load: Segmentation faults

Hello all,

using ruby 1.8.1 (2003-12-25) [i386-mingw32], I get segmentation faults
using YAML to deserialize a class of my own. The class is registered as
a domain type in YAML called !tua.ch,2004/ai/neural. (Yes it is a remake
of LibNeural).

Here's the deserialization code; I would like to know if I am doing
something conceptually wrong or if its just YAML who's crashing because
of a bug when not using objectmaker:

- --------------------------------------
YAML::add_domain_type(AI::NeuralNet::YAMLDOMAIN,
AI::NeuralNet::YAMLLOCATION) do |type, val|
~ net = AI::NeuralNet.new( *val['sizes'] )

~ o = val['output']
~ o.each_with_index do |w, i|
    net.set_weights(AI::NeuralNet::LAYER_OUTPUT, i, w)
~ end

~ h = val['hidden']
~ h.each_with_index do |w, i|
~ net.set_weights(AI::NeuralNet::LAYER_HIDDEN, i, w)
~ end

~ net
end
- ---------------------------------------

Note that the YAML.load call returns an object of type AI::NeuralNet
with the correct dimensions and weights, but once I try to call into the
object, I get a

/lib/data/set.rb:158: [BUG] rb_gc_mark(): unknown data type
0x0(0x2a14698) non object
ruby 1.8.1 (2003-12-25) [i386-mingw32]

I guess the exact location of the bug is not important, because that is
just the point the garbage collection kicks in.

I am getting rather desperate, and I will have to abolish YAML later in
the day to finish my work here, but any suggestions on making YAML work
are welcome.

Best regards,
kaspar

semantics & semiotics
code manufacture

www.tua.ch/ruby

/lib/data/set.rb:158: [BUG] rb_gc_mark(): unknown data type
0x0(0x2a14698) non object
ruby 1.8.1 (2003-12-25) [i386-mingw32]

I guess the exact location of the bug is not important, because that is
just the point the garbage collection kicks in.

No, it's important.

try to use a recent version of YAML and Syck from CVS

Guy Decoux

ts wrote:

"K" == Kaspar Schiess <eule@space.ch> writes:

> /lib/data/set.rb:158: [BUG] rb_gc_mark(): unknown data type
> 0x0(0x2a14698) non object
> ruby 1.8.1 (2003-12-25) [i386-mingw32]

> I guess the exact location of the bug is not important, because that is
> just the point the garbage collection kicks in.

No, it's important.

try to use a recent version of YAML and Syck from CVS

Guy Decoux

I did, but the problem stayed: Then I checked my code and the error was
there. So sorry for the detour and thank you for replying.

Nice side-effect is that I have the newest syck installed :wink:

Yours,
kaspar

semantics & semiotics
code manufacture

www.tua.ch/ruby