[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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 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.

	writeZArchive { arg akv;
		akv = akv.asZArchive;
		grid.do({ arg ev;
		akv.writeItem(gridsize); // possibly different than grid.size
	readZArchive { arg akv;
		grid = Array.fill( akv.readItem(Integer),{ arg i;
		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.


sc-dev mailing list