Re: [hatari-devel] memory snapshot format/issues

[David Savinkoff <dsavnkff@xxxxxxxxx>]

----- Nicolas Pomarède wrote:
> Le 11/05/2015 02:19, David Savinkoff a écrit :
> 
> >> Would require allocating space for it in RAM first so that the items
> >> are all present for sorting.  IMHO not necessary in Hatari's own
> >> snapshot reading code.
> >>
> >
> > Sorting the file makes a rigid unambiguous specification which
> > prevents abuse. To be robust; Hatari should request the data it
> > needs, Not relying on the order it was stored.
> >
> 
> 
> Hi
> 
> but assuming the file is plain text (which I also think would be a 
> better idea, as I already wrote about it some months ago), it's better 
> to have different sections with variables in them, instead of a flat 
> file sorted by name.
> 
> eg:
> 
> [MFP1]
> timerA = 12
> timerC = 18
> timerA_Name = timer A
> 
> [YM2149]
> volA=13
> envper=48
> ...
> 
> This doesn't mean we rely on the stored order, the component for example 
> asks for timerA_Name, then timerA, maybe this is not in the same order 
> than what is stored in the save file, but scanning the same section 
> several time will hardly be noticeable, we're talking about 20-30 
> variables per section, maybe 100 in max case.
> 
> IMO That's much better than :
> 
> mfp1_timerA = 12
> mfp1_timerC = 18
> ym2149_volA = 13
> ...
> 
> we have list of "variable = value", value is some ascii text and it's up 
> to the corresponding component to tell if "value" should be read as text 
> or as int or as bool or as float ...
> 

Your specification looks good because it does not rely on the order
of the entries. Scanning the same section several times to find an
entry is similar to sorting, so I'm ok with it. :D

Note that the subsections (similar to sub-directories) should also
not rely on the order of entries.