I was looking at this bug report:

https://issues.dlang.org/show_bug.cgi?id=2138

and sure enough it doesn't handle zipfiles with more than 65K files.

and I checked the code and its pretty limited on what it will even read.

Which got me to wondering, why reinvent the wheel?  Can std.zip use libzip instead of rewriting it?

-Andy

On Sun, 25 Jan 2015 16:02:33 +0000, AndyC wrote:

> I was looking at this bug report:
> 
> https://issues.dlang.org/show_bug.cgi?id=2138
> 
> and sure enough it doesn't handle zipfiles with more than 65K files.
> 
> and I checked the code and its pretty limited on what it will even read.
> 
> Which got me to wondering, why reinvent the wheel?  Can std.zip use libzip instead of rewriting it?

'cause there is no libzip on windows by default, and there are GNU/Linux, FreeBSD and other OSes where libzip can absent. making it "required" dependency for dmd is not a very good move.

and integrating more and more C libraries in dmd source tree is not a good idea too.

yet i found std.zip handy sometimes, so i'm happy that we have it in Phobos.

On Sunday, 25 January 2015 at 18:40:54 UTC, ketmar wrote:
> On Sun, 25 Jan 2015 16:02:33 +0000, AndyC wrote:
>
>> I was looking at this bug report:
>> 
>> https://issues.dlang.org/show_bug.cgi?id=2138
>> 
>> and sure enough it doesn't handle zipfiles with more than 65K files.
>> 
>> and I checked the code and its pretty limited on what it will even read.
>> 
>> Which got me to wondering, why reinvent the wheel?  Can std.zip use
>> libzip instead of rewriting it?
>
> 'cause there is no libzip on windows by default, and there are GNU/Linux,
> FreeBSD and other OSes where libzip can absent. making it "required"
> dependency for dmd is not a very good move.
>
> and integrating more and more C libraries in dmd source tree is not a
> good idea too.
>
> yet i found std.zip handy sometimes, so i'm happy that we have it in
> Phobos.

Its handy, yes, until you hit one of its many limitations, then what will you do?

Which is less work:
1) include libzip in the install as a requirement, and write a D interface for it.
2) reimplement all of it in D?

I don't honestly know.

More C libraries means D is more useful faster and with less bugs.  Seems like a win to me.

-Andy

On Sun, 25 Jan 2015 20:56:04 +0000, AndyC wrote:

> Its handy, yes, until you hit one of its many limitations, then what will you do?
i didn't come into any limitations yet. my scripts and other software was able to process any zips i trhowed at 'em.

but if i'll really hit any of std.zip limitiation... well, this is a clear sign that i should think about using custom archive format.

> Which is less work:
> 1) include libzip in the install as a requirement, and write a D
> interface for it.
> 2) reimplement all of it in D?
3. don't use zip, as something is already gone wrong.

> I don't honestly know.
> 
> More C libraries means D is more useful faster and with less bugs. Seems like a win to me.
one can write libzip wrapper and publish it in dub. this way Phobos will don't get an additional dependence, but those who need better zip support can easily get it.

On Sunday, 25 January 2015 at 21:19:59 UTC, ketmar wrote:
> On Sun, 25 Jan 2015 20:56:04 +0000, AndyC wrote:
>
>> Its handy, yes, until you hit one of its many limitations, then what
>> will you do?
> i didn't come into any limitations yet. my scripts and other software was
> able to process any zips i trhowed at 'em.
>
> but if i'll really hit any of std.zip limitiation... well, this is a
> clear sign that i should think about using custom archive format.
>
>> Which is less work:
>> 1) include libzip in the install as a requirement, and write a D
>> interface for it.
>> 2) reimplement all of it in D?
> 3. don't use zip, as something is already gone wrong.
>
>> I don't honestly know.
>> 
>> More C libraries means D is more useful faster and with less bugs. Seems like a win to me.
> one can write libzip wrapper and publish it in dub. this way Phobos will
> don't get an additional dependence, but those who need better zip support
> can easily get it.

Is it worth creating a higher tier within code.dlang.org of libraries considered to be of high quality that may have a semi-official stamp?  When you know your way around, you can see what is actively maintained and take a peek at the source, but it is one more friction for newcomers when it is not clear which library to use when Phobos doesn't fully do what you want.

On 2015-01-25 at 17:02, AndyC wrote:
> I was looking at this bug report:
>
> https://issues.dlang.org/show_bug.cgi?id=2138
>
> and sure enough it doesn't handle zipfiles with more than 65K files.


If all you need is the ability to read archives with more than 65K files,
I have created a small patch for std.zip to support reading Zip64:

http://fgda.pl/static/std_zip.patch

The writing part of Zip64 archives isn't done, but that should be only
a little harder to do. All other limitations of std.zip are still present.

But testing would be required. I haven't tried to unpack archives
with this code yet, only listed their contents.

On Mon, 26 Jan 2015 02:09:17 +0000, Laeeth Isharc wrote:

> Is it worth creating a higher tier within code.dlang.org of libraries considered to be of high quality that may have a semi-official stamp? When you know your way around, you can see what is actively maintained and take a peek at the source, but it is one more friction for newcomers when it is not clear which library to use when Phobos doesn't fully do what you want.

i believe that there were some ideas about "ranking" projects in dub repository, and they were discussed in NGs. yet i don't remember the conclusions, 'cause i'm not using dub, has no plans to use dub and so i'm not really motivated enough to track such discussions.

On Monday, 26 January 2015 at 02:17:29 UTC, ketmar wrote:
> On Mon, 26 Jan 2015 02:09:17 +0000, Laeeth Isharc wrote:
>
>> Is it worth creating a higher tier within code.dlang.org of libraries
>> considered to be of high quality that may have a semi-official stamp? When you know your way around, you can see what is actively maintained
>> and take a peek at the source, but it is one more friction for newcomers
>> when it is not clear which library to use when Phobos doesn't fully do
>> what you want.
>
> i believe that there were some ideas about "ranking" projects in dub
> repository, and they were discussed in NGs. yet i don't remember the
> conclusions, 'cause i'm not using dub, has no plans to use dub and so i'm
> not really motivated enough to track such discussions.

Understood.  I guess you don't need to use dub the program, to use code.dlang.org the index as just a directory.

On Monday, 26 January 2015 at 02:14:00 UTC, FG wrote:
> http://fgda.pl/static/std_zip.patch

How about submitting this patch as a pull request?

http://wiki.dlang.org/Pull_Requests

On Sunday, 25 January 2015 at 21:19:59 UTC, ketmar wrote:
> On Sun, 25 Jan 2015 20:56:04 +0000, AndyC wrote:
>
>> Its handy, yes, until you hit one of its many limitations, then what
>> will you do?
> i didn't come into any limitations yet. my scripts and other software was
> able to process any zips i trhowed at 'em.
>
> but if i'll really hit any of std.zip limitiation... well, this is a
> clear sign that i should think about using custom archive format.
>
>> Which is less work:
>> 1) include libzip in the install as a requirement, and write a D
>> interface for it.
>> 2) reimplement all of it in D?
> 3. don't use zip, as something is already gone wrong.
>
>> I don't honestly know.
>> 
>> More C libraries means D is more useful faster and with less bugs. Seems like a win to me.
> one can write libzip wrapper and publish it in dub. this way Phobos will
> don't get an additional dependence, but those who need better zip support
> can easily get it.

I believe dub already has a good zip implementation on it, but I don't think it's a libzip wrapper IIRC - I think it's pure D wrapped about std.zlib for the actual deflate decompression.