Re: [sc-dev] Use ZArchive for Object-readBinaryArchive, writeBinaryArchive

[crucial felix <felix@xxxxxxxxxxxxxxxxxxx>]

On Jan 9, 2006, at 7:50 PM, Scott Wilson wrote:
> On 9 Jan 2006, at 14:21, stefan kersten wrote:
> > are there any limitations (speed, shared references, etc) in
> > ZArchive?

ZArchive is meant for raw data like arrays.  Its fast, and it  
compresses strings/symbols and repeated values.

But it is not meant to just take any ad hoc object and store it.  If  
the object has asCompileString support then it can store that.

It is NOT meant for things with shared references. It will make  
duplicates when you re load.

It is however extensible.  You can support ZArchive in your class and  
write a custom save/load sequence -- storing whatever you want and  
then retrieving it in the same order.  To be safe against wrong-order  
bugs (if you are still developing your class and can't make up your  
mind) you could put your crap in a dict and store that.

But if you are saving long sequences or automation (like I am) then  
your object can pack and unpack in the most efficient way it knows how.

It can also pass the archive to its children and let them pack in  
their own way.

> Maybe felix can elaborate. Seems pretty fast in my tests. I noticed  
> it does have a version instance var, which makes me wonder if it  
> might change in the future.

the version number is for your own use.  (well for mine actually)
in case your Song object changes its format, it can consult the  
version number.

TrackerColumn
	writeZArchive { arg akv;
		akv = akv.asZArchive;
		akv.writeItem(grid.size);
		grid.do({ arg ev;
			ev.writeZArchive(akv,this);
		});
		akv.writeItem(gridsize); // possibly different than grid.size
		akv.writeItem(stepsPerBeat.asInteger);
		
		//1.3
		akv.writeItem(volMod);
	}
	readZArchive { arg akv;
		grid = Array.fill( akv.readItem(Integer),{ arg i;
			this.class.eventClass.readZArchive(akv)
		});
		gridsize = akv.readItem(Integer);
		stepsPerBeat = akv.readItem(Integer);
		if(akv.version >= 13,{
			volMod = akv.readItem;
		});
	}


for most purposes, you can just ignore the version number.



> > what's wrong with the primitives, btw?
>
> They're dependent upon the instance variables in the corresponding  
> classes not changing. Thus if any classes are changed old archives  
> may become incompatible.

worse than that, it corrupts the whole language and all hell breaks  
loose.

they should be commented out right away really.  i'm guilty of  
leaving them there, sorry.
it was only mentioned on the list by jmc.

in summary: ZArchive is specialized for larger data storage and is  
useful for that. but it isn't an object archiver as such.

but ZArchive could use asTextArchive so that it could store any  
object even ones that don't have asCompileString support

and some archive format could be devised that uses the shared  
references system and yet saves a binary file using ZArchive




> I believe this has already happened. The text archives are safe for  
> this, and so is ZArchive according to its help file.
>
> S.
>
> _______________________________________________
> sc-dev mailing list
> sc-dev@xxxxxxxxxxxxxxx
> http://www.create.ucsb.edu/mailman/listinfo/sc-dev