MZZip and extensions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

MZZip and extensions

Louis LaBrunda

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

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

MZZipPlus.dat (198K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: MZZip and extensions

Seth Berman
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

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

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

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: MZZip and extensions

Richard Sargent
Administrator
In reply to this post by Louis LaBrunda
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.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: MZZip and extensions

Louis LaBrunda

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 12:23:30 PM UTC-4, Richard Sargent wrote:
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.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: MZZip and extensions

Richard Sargent
Administrator
On Friday, June 27, 2014 12:08:57 PM UTC-7, Louis LaBrunda wrote:
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.

I always advocate putting features on the instance side (reserving the right to say that in some cases, class side does make sense).

Additionally, let "last error" be a behaviour, not an attribute. Use a collection. Record all the errors. There will be a time when someone needs to see all of them.
In fact, it is often the first error (also a behaviour) which is more relevant. [Compilers are much better these days, but we have all seen the cascade of errors from an initial, simple syntax error.]

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: MZZip and extensions

Louis LaBrunda
In reply to this post by Seth Berman

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


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

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: MZZip and extensions

jtuchel
Hi Lou,

I can't speak for Seth or John, but I would advise you to look into the "new" exception mechanism, which is Class based, meaning you subclass Exception (or Error) instead of using the newChild: stuff. 

There are many reasons, one of them being that the class based exception handling is much more portable and documented also outside of the VA ST universe. 

But better take Seth's or John's opinion than mine. Maybe they know of good reasons to do something else... 

Joachim


Am Mittwoch, 30. Juli 2014 16:07:02 UTC+2 schrieb Louis LaBrunda:

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

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: MZZip and extensions

Richard Sargent
Administrator
In reply to this post by Louis LaBrunda
On Wednesday, July 30, 2014 7:07:02 AM UTC-7, Louis LaBrunda wrote:
... 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?

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

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: MZZip and extensions

Louis LaBrunda

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.

Do you have an example I can look at?  The doc's seem to be about using the old instance based #newChild stuff.

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: MZZip and extensions

Seth Berman
In reply to this post by Louis LaBrunda
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

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: MZZip and extensions

Louis LaBrunda
Hi Seth,


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

On Wednesday, July 30, 2014 12:42:05 PM UTC-4, Seth Berman wrote:
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

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: MZZip and extensions

Louis LaBrunda
In reply to this post by Seth Berman

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


On Wednesday, July 30, 2014 12:42:05 PM UTC-4, Seth Berman wrote:
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

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

KscMZZipExtensions.dat (61K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: MZZip and extensions

Seth Berman
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

On Friday, August 1, 2014 3:54:44 PM UTC-4, Louis LaBrunda wrote:

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


On Wednesday, July 30, 2014 12:42:05 PM UTC-4, Seth Berman wrote:
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

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: MZZip and extensions

Louis LaBrunda
Hi Seth,

On Wednesday, August 6, 2014 3:28:34 PM UTC-4, Seth Berman wrote:
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

Richard made an interesting suggestion (thanks Richard) about how to name the method to signal the exception in my other post about exceptions.  I will think about a better name (for the signaling class method) and use it or both the plain name and a new one and then post the extensions to the goodies.  I am open to suggestions for the method name so if anyone has any ideas, post them here.

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.