[Regression] loading / saving chain to / from &str path is no longer possible in 0.0.30 about markov HOT 6 CLOSED

Yes, I intend for serialization support to be re-added, but unfortunately, we can no longer do so with JSON. #5 addresses this, and I'm looking for help on it.

from markov.

@aatxe sorry, but #5 is very unclear, e.g.

The reason for this is that in JSON, the only valid object key is a string. So, we'll need to implement our own format to serialize it to (or find another existing format that works better).

What are the requirements for a new format?

What you wrote seems to mean "something other than JSON, that will be able to store other(?) than key = string value stuff"

Also, as for someone know knows ~nothing about markov chains, I have no idea why saving nth order chains wouldn't work with JSON.. and quick googling about nth order chains didn't help either.

Now, about helping - I usually prefer not to waste my time on helping with code that is not licensed under something with strong copyleft.. with that being said, I doubt that I could help anyway, since I don't know what is (was rather) being saved/loaded, and what is needed to be saved/loaded now.

I guess I'll just stick to 0.0.29 for time being.

from markov.

JSON objects map strings to values. This worked fine with serialization when the internal representation of the Markov chains was a HashMap<Rc<T>, HashMap<Rc<T>, u32>>. This is because Rc<T> serializes just like T. In a second-order Markov chain, you'd have a mapping like so: HashMap<(Rc<T>, Rc<T>), HashMap<Rc<T>, u32>> where you map a pair of two keys in succession to the keys that may follow them. To support an arbitrary nth-order Markov chain, we use HashMap<Vec<Rc<T>>, HashMap<Rc<T>, u32>>. Both the specific second-order and arbitrary nth-order Markov chains could not be expressed as JSON objects because of the restriction that the keys be strings. So, yes, to answer your question, the only requirement is that it can express a mapping from Vec<Rc<T>> to a mapping from Rc<T> to a number.

from markov.

Fixed in #18.

from markov.

My bad, spoke to soon. Not positive this is properly fixed yet.

from markov.

Fixed in 5655cd4a166a2f6822508cba6d67511ef2069d2e.

from markov.