• AndyC (9/9) Jan 25 2015 I was looking at this bug report:
• ketmar (8/18) Jan 25 2015 'cause there is no libzip on windows by default, and there are GNU/Linux...
• AndyC (11/36) Jan 25 2015 Its handy, yes, until you hit one of its many limitations, then
• ketmar (9/19) Jan 25 2015 i didn't come into any limitations yet. my scripts and other software wa...
• Laeeth Isharc (7/33) Jan 25 2015 Is it worth creating a higher tier within code.dlang.org of
• ketmar (5/11) Jan 25 2015 i believe that there were some ideas about "ranking" projects in dub=20
• Laeeth Isharc (3/21) Jan 25 2015 Understood. I guess you don't need to use dub the program, to
• ketmar (6/23) Jan 25 2015 you are right, directory can be browsed in searched from web browser. ye...
• weaselcat (3/40) Jan 25 2015 Just being able to sort by popularity would be a pretty big
• weaselcat (4/30) Jan 25 2015 I believe dub already has a good zip implementation on it, but I
• FG (8/11) Jan 25 2015 If all you need is the ability to read archives with more than 65K files...
• Vladimir Panteleev (3/4) Jan 25 2015 How about submitting this patch as a pull request?
• FG (3/7) Jan 26 2015 OK, I will. First I'll run some tests and perhaps also do the writer.
• FG (3/4) Jan 27 2015 Thanks for this suggestion. The expanded patch is now merged:

"AndyC" <andy squeakycode.net> writes:

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

ketmar <ketmar ketmar.no-ip.org> writes:

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

 I was looking at this bug report:
=20
 https://issues.dlang.org/show_bug.cgi?id=3D2138
=20
 and sure enough it doesn't handle zipfiles with more than 65K files.
=20
 and I checked the code and its pretty limited on what it will even read.
=20
 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,=20
FreeBSD and other OSes where libzip can absent. making it "required"=20
dependency for dmd is not a very good move.

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

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

"AndyC" <andy squeakycode.net> writes:

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

ketmar <ketmar ketmar.no-ip.org> writes:

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=20
able to process any zips i trhowed at 'em.

but if i'll really hit any of std.zip limitiation... well, this is a=20
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.
=20
 More C libraries means D is more useful faster and with less bugs.=20
 Seems like a win to me.

one can write libzip wrapper and publish it in dub. this way Phobos will=20
don't get an additional dependence, but those who need better zip support=20
can easily get it.=

"Laeeth Isharc" <Laeeth.nospam nospam-laeeth.com> writes:

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.

ketmar <ketmar ketmar.no-ip.org> writes:

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?=20
 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=20
repository, and they were discussed in NGs. yet i don't remember the=20
conclusions, 'cause i'm not using dub, has no plans to use dub and so i'm=20
not really motivated enough to track such discussions.=

"Laeeth Isharc" <laeethnospam nospamlaeeth.com> writes:

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.

ketmar <ketmar ketmar.no-ip.org> writes:

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

 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.

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

you are right, directory can be browsed in searched from web browser. yet=20
i'm not interested in that too, 'cause googling by "dlang" either returns=20
something on the first pages, and this indicates the "liveness" of the=20
project, or can't find anything to show me right away, which means "ok,=20
i'll do it myself then". ;-)=

"weaselcat" <weaselcat gmail.com> writes:

On Monday, 26 January 2015 at 02:09:18 UTC, Laeeth Isharc wrote:
 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.

Just being able to sort by popularity would be a pretty big 
improvement.

"weaselcat" <weaselcat gmail.com> writes:

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.

FG <home fgda.pl> writes:

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.

"Vladimir Panteleev" <vladimir thecybershadow.net> writes:

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

FG <home fgda.pl> writes:

On 2015-01-26 at 03:41, Vladimir Panteleev wrote:
 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


OK, I will. First I'll run some tests and perhaps also do the writer.
Wouldn't want to waste your time on something that doesn't work.

FG <home fgda.pl> writes:

On 2015-01-26 at 03:41, Vladimir Panteleev wrote:
 How about submitting this patch as a pull request?

Thanks for this suggestion. The expanded patch is now merged:
https://github.com/D-Programming-Language/phobos/pull/2914