std.zip has been fixed, and will go out in the next update.

I wasn't having a go at the lib, I was asking whether anyone has actually written a powerful utility with it yet?

Maybe this could be a dsource.org project.


"Walter" <walter@digitalmars.com> wrote in message news:c65dof$314c$3@digitaldaemon.com...
> std.zip has been fixed, and will go out in the next update.
>
>

In article <c65enl$129$1@digitaldaemon.com>, Matthew says...
>
>I wasn't having a go at the lib, I was asking whether anyone has actually written a powerful utility with it yet?
>
>Maybe this could be a dsource.org project.
>

(It not powerfull and) it's not independent:
when one deletes files from leds the files
will be sent to a zip archive (next release).
Then there is an utility to view, recover or delete
the files from the archive.
The archive can contain any number of version of each
file and stores the project from where the file was deleted.
It will be powerfull when a limit to the size of the archive
and to the number of versions for each file can be respected.

Anyone know if the std.zip can read .jar (from java's jar utility)
files? i.e. are they using the same compression method?
(anything else required?)
The first try I made I got a buffer error (not a zip error!?).

Ant

AFAIK, .jar uses WinZip compatible format (and I've never had a problem using it with them), so they should be compatible with D's zip

"Ant" <Ant_member@pathlink.com> wrote in message news:c65mhk$dnk$1@digitaldaemon.com...
> In article <c65enl$129$1@digitaldaemon.com>, Matthew says...
> >
> >I wasn't having a go at the lib, I was asking whether anyone has actually
written
> >a powerful utility with it yet?
> >
> >Maybe this could be a dsource.org project.
> >
>
> (It not powerfull and) it's not independent:
> when one deletes files from leds the files
> will be sent to a zip archive (next release).
> Then there is an utility to view, recover or delete
> the files from the archive.
> The archive can contain any number of version of each
> file and stores the project from where the file was deleted.
> It will be powerfull when a limit to the size of the archive
> and to the number of versions for each file can be respected.
>
> Anyone know if the std.zip can read .jar (from java's jar utility)
> files? i.e. are they using the same compression method?
> (anything else required?)
> The first try I made I got a buffer error (not a zip error!?).
>
> Ant
>
>

FWIW, I'd expect to hook it into Dsc.server for compressing output sent to the client ...


"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c65enl$129$1@digitaldaemon.com...
> I wasn't having a go at the lib, I was asking whether anyone has actually
written
> a powerful utility with it yet?
>
> Maybe this could be a dsource.org project.
>
>
> "Walter" <walter@digitalmars.com> wrote in message news:c65dof$314c$3@digitaldaemon.com...
> > std.zip has been fixed, and will go out in the next update.
> >
> >
>
>

"Ant" <Ant_member@pathlink.com> wrote in message news:c65mhk$dnk$1@digitaldaemon.com...
> Anyone know if the std.zip can read .jar (from java's jar utility)
> files? i.e. are they using the same compression method?
> (anything else required?)
> The first try I made I got a buffer error (not a zip error!?).

jar files are just renamed zip files. It should work. I must commend Sun for using an existing format and not annoying everyone by inventing a new proprietary one of dubious superiority.

I've felt many times that the .lib and .a formats should be dumped and zip used instead.