<div class="gmail_quote">On Tue, Jun 28, 2011 at 9:05 PM, Andrew Wiley <span dir="ltr"><<a href="mailto:wiley.andrew.j@gmail.com" target="_blank">wiley.andrew.j@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><div></div><div>On Tue, Jun 28, 2011 at 3:13 PM, Nick Sabalausky <span dir="ltr"><a@a.a></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

"Michel Fortin" <<a href="mailto:michel.fortin@michelf.com" target="_blank">michel.fortin@michelf.com</a>> wrote in message<br>
news:iudhf9$2dr9$1@digitalmars.com...<br>
> On 2011-06-28 15:39:42 -0400, Walter Bright <<a href="mailto:newshound2@digitalmars.com" target="_blank">newshound2@digitalmars.com</a>><br>
> said:<br>
><br>
>> On 6/28/2011 12:13 PM, Jacob Carlborg wrote:<br>
>>> Since most of the applications and most the libraries (basically all<br>
>>> that ships<br>
>>> with Mac OS X) are universal there's usually no problem of<br>
>>> running/building both<br>
>>> 32 and 64bit software.<br>
>><br>
>> I'll explain the motivation for 64 bit only DMD binaries:<br>
>><br>
>> 1. It cuts the testing time in half. This is a significant deal for me,<br>
>> as adding another hour to the test cycle slows things down a lot.<br>
>><br>
>> 2. It speeds downloading the dmd package.<br>
>><br>
>> The only reason to have a 32 bit binary is if there are x86 Macs 10.5 or<br>
>> later that are incapable of running 64 bit code.<br>
><br>
> Well, you could ship the next DMD version 64-bit only and of you get<br>
> complains you bring back the 32-bit version as a universal binary.<br>
><br>
> But you'll definitely rule out users of Apple's early Intel computers. I<br>
> think the last Apple model with a 32-bit CPU was the "Mac Mini (Late<br>
> 2006)", which was replaced mid 2007 with a Core 2 Duo model.<br>
><br>
> As for increasing the download speed, you could try one of these too:<br>
><br>
> * separate per-OS packages<br>
> * separate source package<br>
> * separate documentation package<br>
> * faster server<br>
<br>
* use 7z<br>
<br>
Using 7z instead of zip or tarballs has shrunk the size of my packaged<br>
Goldie releases down to roughly one-quarter the size of a zip or tar.bz2<br>
(Yes, ~75% decrease is size). Of course, that's probably an extreme case,<br>
but I just tried making a 7z of DMD 2.053, and it came out to just under 9MB<br>
(vs just over 15MB for the official zip release), so fairly close to half<br>
the size. Still pretty damn good.<br>
<br>
And I really see no reason why any programmer shouldn't have a 7z-capable<br>
extractor these days. Heck, it's pretty typical on Linux, and it's built<br>
into WinRar. Zip and tarballs are like MP3's: They're still everywhere, but<br>
only because of inertia, not because of any inherent merit, of which there<br>
really isn't any. 7z is like moving to Vorbis (Except that I think 7z<br>
support is probably more common than Vorbis support, which is unfortunate<br>
for Vorbis fans like me, but that's even more OT...).<br>
<br>
<br></blockquote><div><br></div></div></div><div>Have you tried xz on Linux? I think WinRar supports it on Windows, but I haven't checked in a while. </div></div><br>
</blockquote></div><div><br></div><br>
<div>I just tried using WinRAR to open a tar.xz file, and it didn't work.</div>