MZZip and extensions

Hi Everybody, Hi Seth,

I have been playing with #MZZipUnzipApp, which is an app that links to a DLL (or two?) supplied with VA Smalltalk V8.6 for zipping and unzipping files.  With Seth Berman's help (mostly Seth's, thanks Seth) a few errors in #MZZipUnzipApp have been found and fixed (included in the attached file).

Note to Seth: If I remember correctly, the only thing I fixed in #MZZipUnzipApp was #date in #MZZipFileInfo, where you used an offset at 56 that should have been 0 (56 is the offset in #MZUnzFileInfo for #date).

I have created some extensions to the classes in #MZZipUnzipApp (also included in the attached file).  I think #MZZipUnzipApp is great but it is at a very low level and close to the DLL used to zip/unzip.  As such, a few methods to deal with saving files and converting dates and times were needed.  I have created these as extensions to some of the classes in #MZZipUnzipApp and a few other #Cfs... classes and #DateAndTime.

There are about six methods for zipping and two for unzipping.  Any time a path to a file is required, an instance of String or an instance CfsPath is acceptable.  The zip methods return a boolean that indicates overall success of failure.  The unzip methods return the number of files unzipped.

This brings me to my question for group discussion.  Should these methods return error objects when there is a problem?  What I have so far meets my needs but I an willing to do more work if the group thinks it valuable.  On that note I am willing to make the code available to anyone that wants it as I have done with the attachment and to let Instantiations include it in the product and make whatever changes they like.  Since the code is all extensions, it can just be moved to the appropriate classes in #MZZipUnzipApp and get ride of my app.

Back to my question about returning error objects.  This requires some though and discussion.  Should a method stop on the first error?  Or should it continue and return a collection of each error?  For example, when zipping multiple files, one or more might be missing but some would be zipped just fine.

I will be happy to hear what everyone thinks.

Lou

There are about six methods for zipping and two for unzipping.  Any time a path to a file is required, an instance of String or an instance CfsPath is acceptable.  The zip methods return a boolean that indicates overall success of failure.  The unzip methods return the number of files unzipped.

This brings me to my question for group discussion.  Should these methods return error objects when there is a problem?  ...

Back to my question about returning error objects.  This requires some though and discussion.  Should a method stop on the first error?  Or should it continue and return a collection of each error?  For example, when zipping multiple files, one or more might be missing but some would be zipped just fine.

Hi Richard,

Thanks for the suggestion about exceptions.  I think throwing an exception will be easier than returning multiple error objects.  Once Seth has a chance to look at things maybe we can come to a consensus that will allow Instantiations to include it in the product.

The zip/unzip methods are on the class side.  I forgot to mention that we could put them on the instance side (maybe on a new class) where the last error could be remembered.

Lou

On Friday, June 27, 2014 7:58:30 AM UTC-7, Louis LaBrunda wrote:

There are about six methods for zipping and two for unzipping.  Any time a path to a file is required, an instance of String or an instance CfsPath is acceptable.  The zip methods return a boolean that indicates overall success of failure.  The unzip methods return the number of files unzipped.

 

This brings me to my question for group discussion.  Should these methods return error objects when there is a problem?  ...

Back to my question about returning error objects.  This requires some though and discussion.  Should a method stop on the first error?  Or should it continue and return a collection of each error?  For example, when zipping multiple files, one or more might be missing but some would be zipped just fine.

I am not a fan of multi-contract return types. It is little different from languages (and usage patterns) that require you to check for null/nil after every call.

Use exceptions. That is what they are for. You can have the low-level methods throw detail exceptions with the higher-level methods recasting them. For example, if you find a malformed file, you can throw an error which describes the problem in detail. The façade-level method catches the detailed error and rethrows a more general error. If you return from the general exception, the façade-level method continues with the next file.

A Smalltalk-specific mechanism involves using Blocks. If you configure the component with an error handler, you control what you do with the errors. In some ways, this is less flexible and the above-mentioned exception handling scheme, although internally, it can use the general/detailed error mechanism, too.


Of course, this depends on whether the artefacts actually allow skipping and continuing. e.g. a gzip file compresses a single file, not a directory, so once you find an error, there really isn't any way to safely skip it and move on.

The zip/unzip methods are on the class side.  I forgot to mention that we could put them on the instance side (maybe on a new class) where the last error could be remembered.

Hi Seth and Everybody,

I finally have some time to play with the zip stuff again.  I like Richard's suggestion about using exceptions.  What do you think?  I have seen posts by Joachim and John about exceptions.  Something about class vs instance, new vs old, I don't remember for sure, I will have to look them up.  If I go that route, what kind should I use?

I would really like to do this in a way the will have Instantiations add the code to the existing #MZZipUnzipApp.  #MZZipUnzipApp is easy to use and as far as it goes it is fine but without my code or something like it one can unzip a file to the disk with its original date/time.  You also have to write a fair amount of code to zip one or more files.  I can and will put the code in the goodies collection if Instantiations doesn't pick it up.  But people don't always remember to look at the goodies before jumping in and reinventing the wheel. 

So, with a little guidance, I will try to write code that Instantiations will be happy to pick up.

Lou

Nice catch Lou on the date offset for zip info...I have made the correction.

Thanks for these extensions...we will take a deeper look.

-- Seth

... Something about class vs instance, new vs old, I don't remember for sure, I will have to look them up.  If I go that route, what kind should I use?

Hi Richard and Joachim.

Always use the class-based (ANSI) exception mechanism unless you have a compelling reason to back to the instance-based exception mechanism.

Thanks for the kind words.  I think I understand the class-based exceptions and I'm working on folding them in to what I have so far.  I have removed the use of  #abrSimpleFilename (I think there was only one spot) and replaced it with sending "asPath fileName" to what is either a string or a CfsPath.  As the Cfs... stuff is already required to read/write files to the disk, this doesn't add a new dependency.

The inflate/deflate stream stuff sounds interesting!  I have a zip stuff and the send it out over a socket.  Right now I have to zip it to a file then read the zipped file to send it out on the socket.  If I could zip to a stream/string I could send that out on the socket and be done with it.

I will post me class-based exception code here when it's ready.  Hopefully, someone will check it out and point out any problems.

Lou

Hi Louis (and everybody else),

Exceptions:

As far as exceptions go, I would echo what Richard and Joachim have stated...which is to use ANSI class-based exceptions (on:do:) as opposed to the instance-based exceptions (when:do:).

One place you can see an example is in the SUnit Framework.

Zip Extensions:

First, I want to thank you Louis for doing this.  There are two areas that you have helped improve.  The first being some basic fixes to the underlying MZZip framework.  These fixes have been applied and are in our current build.

The second area is a set of useful extensions for creation/manipulation of zip files which also simplifies things at this low level.

The holdup has for two reasons.

1. We are at the very tail end of the release and are working to get our items in, so I've been trying to fit this in.  From what I have seen, there is just a small amount to do, such as the exceptions and prereq dep management (for example, we can't reference #abrSimpleFilename in the MZ layer which just prereqs Kernel). 

2. I'm still not completely sure if it's a competing requirement, but we have been working on a more general inflate/deflate smalltalk stream implementation that will end up overlapping (though not completely).  So I would preferably like one way for users to work with compressed data (files, sockets, image formats or whatever) that involve inflate/deflate compression algorithms.  Naturally, zip adds a few more concepts to the mix which is why I say it's not necessarily a duplication of effort.

I wanted to be sure to get you a prompt reply, but I don't have an answer for you just yet.   I will work to get you one.

Thanks again for the great additions and fixes

-- Seth

On Wednesday, July 30, 2014 10:07:02 AM UTC-4, Louis LaBrunda wrote:

Hi Seth and Everybody,

I finally have some time to play with the zip stuff again.  I like Richard's suggestion about using exceptions.  What do you think?  I have seen posts by Joachim and John about exceptions.  Something about class vs instance, new vs old, I don't remember for sure, I will have to look them up.  If I go that route, what kind should I use?

I would really like to do this in a way the will have Instantiations add the code to the existing #MZZipUnzipApp.  #MZZipUnzipApp is easy to use and as far as it goes it is fine but without my code or something like it one can unzip a file to the disk with its original date/time.  You also have to write a fair amount of code to zip one or more files.  I can and will put the code in the <a href="http://vastgoodies.com/" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fvastgoodies.com%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNFuxnr60lH1eJZumpU0ZdEEA3DfSQ';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fvastgoodies.com%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNFuxnr60lH1eJZumpU0ZdEEA3DfSQ';return true;">goodies collection if Instantiations doesn't pick it up.  But people don't always remember to look at the goodies before jumping in and reinventing the wheel. 

So, with a little guidance, I will try to write code that Instantiations will be happy to pick up.

Lou

On Friday, June 27, 2014 11:40:09 AM UTC-4, Seth Berman wrote:

Nice catch Lou on the date offset for zip info...I have made the correction.

Thanks for these extensions...we will take a deeper look.

-- Seth

Hi Seth and Everybody,

I have finished the changes to my MZ zip extension (see attached).  They now use class-based exceptions.  They throw resumable exceptions when they encounter an error such as one or more files not found in a list of files to zip.

The zip and unzip methods answer the number of files zipped or unzipped (files inflated from a zip file).

This version adds only the Cfs stuff as a prerequisite (reference to #abrSimpleFilename is gone).

Seth, I have added a few classes to define the exceptions but everything else is an extension of existing MZ or other classes.  If you like you can keep the app separate but if you choose to use it I think it would be easy/better to move the MZ extensions right into their respective classes, move the extensions of other classes and the new classes right into the ZMZipUnzipApp and add CommonFileSystem as a prerequisite.

I hope this will be helpful.

Lou

Hi Louis (and everybody else),

Exceptions:

As far as exceptions go, I would echo what Richard and Joachim have stated...which is to use ANSI class-based exceptions (on:do:) as opposed to the instance-based exceptions (when:do:).

One place you can see an example is in the SUnit Framework.

Zip Extensions:

First, I want to thank you Louis for doing this.  There are two areas that you have helped improve.  The first being some basic fixes to the underlying MZZip framework.  These fixes have been applied and are in our current build.

The second area is a set of useful extensions for creation/manipulation of zip files which also simplifies things at this low level.

The holdup has for two reasons.

1. We are at the very tail end of the release and are working to get our items in, so I've been trying to fit this in.  From what I have seen, there is just a small amount to do, such as the exceptions and prereq dep management (for example, we can't reference #abrSimpleFilename in the MZ layer which just prereqs Kernel). 

2. I'm still not completely sure if it's a competing requirement, but we have been working on a more general inflate/deflate smalltalk stream implementation that will end up overlapping (though not completely).  So I would preferably like one way for users to work with compressed data (files, sockets, image formats or whatever) that involve inflate/deflate compression algorithms.  Naturally, zip adds a few more concepts to the mix which is why I say it's not necessarily a duplication of effort.

I wanted to be sure to get you a prompt reply, but I don't have an answer for you just yet.   I will work to get you one.

Thanks again for the great additions and fixes

-- Seth

On Wednesday, July 30, 2014 10:07:02 AM UTC-4, Louis LaBrunda wrote:

Hi Seth and Everybody,

I finally have some time to play with the zip stuff again.  I like Richard's suggestion about using exceptions.  What do you think?  I have seen posts by Joachim and John about exceptions.  Something about class vs instance, new vs old, I don't remember for sure, I will have to look them up.  If I go that route, what kind should I use?

I would really like to do this in a way the will have Instantiations add the code to the existing #MZZipUnzipApp.  #MZZipUnzipApp is easy to use and as far as it goes it is fine but without my code or something like it one can unzip a file to the disk with its original date/time.  You also have to write a fair amount of code to zip one or more files.  I can and will put the code in the <a href="http://vastgoodies.com/" target="_blank" onmousedown="this.href='http://www.google.com/url?q\75http%3A%2F%2Fvastgoodies.com%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNFuxnr60lH1eJZumpU0ZdEEA3DfSQ';return true;" onclick="this.href='http://www.google.com/url?q\75http%3A%2F%2Fvastgoodies.com%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNFuxnr60lH1eJZumpU0ZdEEA3DfSQ';return true;">goodies collection if Instantiations doesn't pick it up.  But people don't always remember to look at the goodies before jumping in and reinventing the wheel. 

So, with a little guidance, I will try to write code that Instantiations will be happy to pick up.

Lou

On Friday, June 27, 2014 11:40:09 AM UTC-4, Seth Berman wrote:

Nice catch Lou on the date offset for zip info...I have made the correction.

Thanks for these extensions...we will take a deeper look.

-- Seth

Hi Lou,

Thanks for the updates....looking good.

My recommendation is to put it in Vast Goodies and we can pick up the extensions for next release for inclusion with our existing inflate/deflate streaming support requirement.

As I've stated, the fixes we went over will already be there for the upcoming release (and a few more).  We have built the test suites for these, but we need to do the same for the extensions and we have simply run out of time.

I will update the case for our inflate/deflate req to make sure these get rolled in.

Thanks again...the extensions are definitely worthwhile and make zip nicer to work with.

-- Seth