emacs-20101122 windows binaries

emacs-20101122 windows binaries

[Sean Sieger]

The trunk was built and runs successfully on Windows.  Binaries have
been published in

http://alpha.gnu.org/gnu/emacs/windows/

Re: emacs-20101122 windows binaries

[Eric Lilja]

On 2010-11-22 23:11, Sean Sieger wrote:
> The trunk was built and runs successfully on Windows.  Binaries have
> been published in
>
> http://alpha.gnu.org/gnu/emacs/windows/
>
>
>

Why is it ~9 MB smaller than the previous set (and I'm talking about the 
NOT-barebin version)?

-EL

Re: emacs-20101122 windows binaries

[Eric Lilja]

On 2010-11-23 03:20, Eric Lilja wrote:
> On 2010-11-22 23:11, Sean Sieger wrote:
>> The trunk was built and runs successfully on Windows. Binaries have
>> been published in
>>
>> http://alpha.gnu.org/gnu/emacs/windows/
>>
>>
>>
>
> Why is it ~9 MB smaller than the previous set (and I'm talking about the
> NOT-barebin version)?
>
> -EL
>
>
>

Unpacked the difference is almost 30 MB and the reason is that the 
binaries in this latest set are much smaller than before. emacs.exe, for 
instance, went from 37.6 MB to 13.8 MB. I have no idea if this hints at 
a problem at all.

- EL

Re: emacs-20101122 windows binaries

[Jason Rumney]

Eric Lilja <mindcooler@gmail.com> writes:

> Unpacked the difference is almost 30 MB and the reason is that the
> binaries in this latest set are much smaller than before. emacs.exe,
> for instance, went from 37.6 MB to 13.8 MB. I have no idea if this
> hints at a problem at all.

I guess no debug info has been included (probably not a good idea for
snapshots).

Re: emacs-20101122 windows binaries

[Sean Sieger]

Jason Rumney <jasonr@gnu.org> writes:

    I guess no debug info has been included (probably not a good idea for
    snapshots).

My bad:

 - Snapshots should or should not include debug info?
 - Pretests should or should not include debug info?
 - Releases should or should not include debug info?

Re: emacs-20101122 windows binaries

[Stefan Monnier]

>     I guess no debug info has been included (probably not a good idea for
>     snapshots).

> My bad:

>  - Snapshots should or should not include debug info?
>  - Pretests should or should not include debug info?

These two should have debug info, yes.  They're mostly distributed to
help people fix bugs before the release.

>  - Releases should or should not include debug info?

I'm OK either way on this one.


        Stefan

Re: emacs-20101122 windows binaries

[Eli Zaretskii]

> From: Sean Sieger <sean.sieger@gmail.com>
> Date: Tue, 23 Nov 2010 11:01:00 -0500
> 
>  - Snapshots should or should not include debug info?

They should.

>  - Pretests should or should not include debug info?

They should.

>  - Releases should or should not include debug info?

It is IMO slightly better to ship the release without debug info.

Re: emacs-20101122 windows binaries

[Lennart Borgman]

>>  - Releases should or should not include debug info?
>
> It is IMO slightly better to ship the release without debug info.

Why not ship to versions of the release binaries, with and without debug info?

Re: emacs-20101122 windows binaries

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Tue, 23 Nov 2010 19:39:41 +0100
> Cc: Sean Sieger <sean.sieger@gmail.com>, emacs-devel@gnu.org
> 
> >>  - Releases should or should not include debug info?
> >
> > It is IMO slightly better to ship the release without debug info.
> 
> Why not ship to versions of the release binaries, with and without debug info?

Because it's pointless.  If we want to give users release binaries
with debug info, we should just ship such a binary, period.

Re: emacs-20101122 windows binaries

[Lennart Borgman]

On Tue, Nov 23, 2010 at 8:22 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Date: Tue, 23 Nov 2010 19:39:41 +0100
>> Cc: Sean Sieger <sean.sieger@gmail.com>, emacs-devel@gnu.org
>>
>> >>  - Releases should or should not include debug info?
>> >
>> > It is IMO slightly better to ship the release without debug info.
>>
>> Why not ship to versions of the release binaries, with and without debug info?
>
> Because it's pointless.  If we want to give users release binaries
> with debug info, we should just ship such a binary, period.

Please explain why you think that.

Re: emacs-20101122 windows binaries

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Tue, 23 Nov 2010 20:28:33 +0100
> Cc: sean.sieger@gmail.com, emacs-devel@gnu.org
> 
> On Tue, Nov 23, 2010 at 8:22 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> From: Lennart Borgman <lennart.borgman@gmail.com>
> >> Date: Tue, 23 Nov 2010 19:39:41 +0100
> >> Cc: Sean Sieger <sean.sieger@gmail.com>, emacs-devel@gnu.org
> >>
> >> >>  - Releases should or should not include debug info?
> >> >
> >> > It is IMO slightly better to ship the release without debug info.
> >>
> >> Why not ship to versions of the release binaries, with and without debug info?
> >
> > Because it's pointless.  If we want to give users release binaries
> > with debug info, we should just ship such a binary, period.
> 
> Please explain why you think that.

I just did, above.

Re: emacs-20101122 windows binaries

[Lennart Borgman]

On Tue, Nov 23, 2010 at 8:52 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Date: Tue, 23 Nov 2010 20:28:33 +0100
>> Cc: sean.sieger@gmail.com, emacs-devel@gnu.org
>>
>> On Tue, Nov 23, 2010 at 8:22 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> >> From: Lennart Borgman <lennart.borgman@gmail.com>
>> >> Date: Tue, 23 Nov 2010 19:39:41 +0100
>> >> Cc: Sean Sieger <sean.sieger@gmail.com>, emacs-devel@gnu.org
>> >>
>> >> >>  - Releases should or should not include debug info?
>> >> >
>> >> > It is IMO slightly better to ship the release without debug info.
>> >>
>> >> Why not ship to versions of the release binaries, with and without debug info?
>> >
>> > Because it's pointless.  If we want to give users release binaries
>> > with debug info, we should just ship such a binary, period.
>>
>> Please explain why you think that.
>
> I just did, above.

In what way is "pointless" an explanation?

Re: emacs-20101122 windows binaries

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Tue, 23 Nov 2010 20:56:11 +0100
> Cc: sean.sieger@gmail.com, emacs-devel@gnu.org
> 
> >> > Because it's pointless.  If we want to give users release binaries
> >> > with debug info, we should just ship such a binary, period.
> >>
> >> Please explain why you think that.
> >
> > I just did, above.
> 
> In what way is "pointless" an explanation?

I meant the second sentence.

Re: emacs-20101122 windows binaries

[Lennart Borgman]

On Tue, Nov 23, 2010 at 10:07 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Date: Tue, 23 Nov 2010 21:57:39 +0100
>>
>> On Tue, Nov 23, 2010 at 9:50 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> >> From: Lennart Borgman <lennart.borgman@gmail.com>
>> >> Date: Tue, 23 Nov 2010 20:56:11 +0100
>> >> Cc: sean.sieger@gmail.com, emacs-devel@gnu.org
>> >>
>> >> >> > Because it's pointless.  If we want to give users release binaries
>> >> >> > with debug info, we should just ship such a binary, period.
>> >> >>
>> >> >> Please explain why you think that.
>> >> >
>> >> > I just did, above.
>> >>
>> >> In what way is "pointless" an explanation?
>> >
>> > I meant the second sentence.
>>
>> Can you then explain if you think there is any reason not to ship the
>> release binaries with debug info?
>
> I said it is slightly better, that's all.  The reason is disk space,
> of course: 30MB is a lot for a binary.

Why do you then think it is pointless to ship both binaries with debug
info and without it?

Re: emacs-20101122 windows binaries

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Tue, 23 Nov 2010 22:10:59 +0100
> 
> On Tue, Nov 23, 2010 at 10:07 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> From: Lennart Borgman <lennart.borgman@gmail.com>
> >> Date: Tue, 23 Nov 2010 21:57:39 +0100
> >>
> >> On Tue, Nov 23, 2010 at 9:50 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> >> From: Lennart Borgman <lennart.borgman@gmail.com>
> >> >> Date: Tue, 23 Nov 2010 20:56:11 +0100
> >> >> Cc: sean.sieger@gmail.com, emacs-devel@gnu.org
> >> >>
> >> >> >> > Because it's pointless.  If we want to give users release binaries
> >> >> >> > with debug info, we should just ship such a binary, period.
> >> >> >>
> >> >> >> Please explain why you think that.
> >> >> >
> >> >> > I just did, above.
> >> >>
> >> >> In what way is "pointless" an explanation?
> >> >
> >> > I meant the second sentence.
> >>
> >> Can you then explain if you think there is any reason not to ship the
> >> release binaries with debug info?
> >
> > I said it is slightly better, that's all.  The reason is disk space,
> > of course: 30MB is a lot for a binary.
> 
> Why do you then think it is pointless to ship both binaries with debug
> info and without it?

It should be clear: it's even more disk space waste.

Re: emacs-20101122 windows binaries

[Lennart Borgman]

On Tue, Nov 23, 2010 at 10:18 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Date: Tue, 23 Nov 2010 22:10:59 +0100
>>
>> On Tue, Nov 23, 2010 at 10:07 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> >> From: Lennart Borgman <lennart.borgman@gmail.com>
>> >> Date: Tue, 23 Nov 2010 21:57:39 +0100
>> >>
>> >> On Tue, Nov 23, 2010 at 9:50 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> >> >> From: Lennart Borgman <lennart.borgman@gmail.com>
>> >> >> Date: Tue, 23 Nov 2010 20:56:11 +0100
>> >> >> Cc: sean.sieger@gmail.com, emacs-devel@gnu.org
>> >> >>
>> >> >> >> > Because it's pointless.  If we want to give users release binaries
>> >> >> >> > with debug info, we should just ship such a binary, period.
>> >> >> >>
>> >> >> >> Please explain why you think that.
>> >> >> >
>> >> >> > I just did, above.
>> >> >>
>> >> >> In what way is "pointless" an explanation?
>> >> >
>> >> > I meant the second sentence.
>> >>
>> >> Can you then explain if you think there is any reason not to ship the
>> >> release binaries with debug info?
>> >
>> > I said it is slightly better, that's all.  The reason is disk space,
>> > of course: 30MB is a lot for a binary.
>>
>> Why do you then think it is pointless to ship both binaries with debug
>> info and without it?
>
> It should be clear: it's even more disk space waste.

Why do you think that giving the users the choice to download either
binaries with debug info or without it is "even more disk space
waste"?

Re: emacs-20101122 windows binaries

[Jason Rumney]

Sean Sieger <sean.sieger@gmail.com> writes:

> Jason Rumney <jasonr@gnu.org> writes:
>
>     I guess no debug info has been included (probably not a good idea for
>     snapshots).
>
> My bad:
>
>  - Snapshots should or should not include debug info?
>  - Pretests should or should not include debug info?

Snapshots and Pretests are primarily for testing, so including debug
info is essential.

>  - Releases should or should not include debug info?

In my experience, users complain (still in 2010) about the size of the
binary if it changes drastically between releases. So shipping without
debug info avoids such complaints at the expense that bugs are harder to
debug (but most users that would be willing to debug for you will be
using the snapshots or willing to build from source anyway).

Re: emacs-20101122 windows binaries

[Lennart Borgman]

On Wed, Nov 24, 2010 at 12:00 AM, Jason Rumney <jasonr@gnu.org> wrote:
> Sean Sieger <sean.sieger@gmail.com> writes:
>
>> Jason Rumney <jasonr@gnu.org> writes:
>>
>>     I guess no debug info has been included (probably not a good idea for
>>     snapshots).
>>
>> My bad:
>>
>>  - Snapshots should or should not include debug info?
>>  - Pretests should or should not include debug info?
>
> Snapshots and Pretests are primarily for testing, so including debug
> info is essential.
>
>>  - Releases should or should not include debug info?
>
> In my experience, users complain (still in 2010) about the size of the
> binary if it changes drastically between releases. So shipping without
> debug info avoids such complaints at the expense that bugs are harder to
> debug (but most users that would be willing to debug for you will be
> using the snapshots or willing to build from source anyway).

I offer the same question as I did before: Is there any advantage of
shipping both binaries with debug info and without it? (In separate
downloads, of course.)

RE: emacs-20101122 windows binaries

[Drew Adams]

> In my experience, users complain (still in 2010) about the size of the
> binary if it changes drastically between releases. So shipping without
> debug info avoids such complaints at the expense that bugs are harder to
> debug

Dumb question: Just what do you guys mean by "shipping"?  Don't we just post the
files on the Internet and let users download them?

In that case, I would think that the only drawbacks to our providing both
versions (debug or not) would be disk space at GNU (and other sites for
downloading) and preparation time for Emacs developers (twice the work, whatever
it might be).

Users could themselves decide whether they want to pay the penalties of
additional local disk space and increased download time (and build time?).

What am I missing wrt "shipping"?

Re: emacs-20101122 windows binaries

[Stephen J. Turnbull]

Lennart Borgman writes:

 > Why do you think that giving the users the choice to download either
 > binaries with debug info or without it is "even more disk space
 > waste"?

The reason for making debug binaries available is to encourage their
use.  If there is good reason to encourage non-beta-testers to use
debug binaries, then we should not ship non-debug binaries because
debug binaries cost the user extra disk space, and (perhaps) a tiny
bit of load time or run-time performance, and we need to overcome that
disincentive.

On the contrary, if there's no particular reason to encourage that,
then we shouldn't impose the costs on users at all.

Of course there may be some ambiguity, in which case offering the
choice might be a good idea.  But remember, this isn't like offering
debug versions of standard libraries in an OS distro, where people may
be building their apps with debug options, and need to trace a problem
into the standard libraries.  Rather, Emacs is an end-user
application, and people who would be able and willing to debug at that
level are very likely already beta testers, building with debug
options on.

RE: emacs-20101122 windows binaries

[Stephen J. Turnbull]

Drew Adams writes:

 > Users could themselves decide whether they want to pay the penalties of
 > additional local disk space and increased download time (and build time?).

Users have less information about the value of the debug information.
If we encourage people who don't have gdb installed to use debug
builds, what have we gained? :-)

Making multiple builds available is an admin PITA (if you know how to
do better, please advise, but that's been my experience) and the disk
space can add up fast (since modularized installs are detested by most
users; they want a one-file-download-and-no-questions-asked-install).

Re: emacs-20101122 windows binaries

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Tue, 23 Nov 2010 22:33:04 +0100
> Cc: emacs-devel@gnu.org
> 
> On Tue, Nov 23, 2010 at 10:18 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> From: Lennart Borgman <lennart.borgman@gmail.com>
> >> Date: Tue, 23 Nov 2010 22:10:59 +0100
> >>
> >> On Tue, Nov 23, 2010 at 10:07 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> >> From: Lennart Borgman <lennart.borgman@gmail.com>
> >> >> Date: Tue, 23 Nov 2010 21:57:39 +0100
> >> >>
> >> >> On Tue, Nov 23, 2010 at 9:50 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> >> >> From: Lennart Borgman <lennart.borgman@gmail.com>
> >> >> >> Date: Tue, 23 Nov 2010 20:56:11 +0100
> >> >> >> Cc: sean.sieger@gmail.com, emacs-devel@gnu.org
> >> >> >>
> >> >> >> >> > Because it's pointless.  If we want to give users release binaries
> >> >> >> >> > with debug info, we should just ship such a binary, period.
> >> >> >> >>
> >> >> >> >> Please explain why you think that.
> >> >> >> >
> >> >> >> > I just did, above.
> >> >> >>
> >> >> >> In what way is "pointless" an explanation?
> >> >> >
> >> >> > I meant the second sentence.
> >> >>
> >> >> Can you then explain if you think there is any reason not to ship the
> >> >> release binaries with debug info?
> >> >
> >> > I said it is slightly better, that's all.  The reason is disk space,
> >> > of course: 30MB is a lot for a binary.
> >>
> >> Why do you then think it is pointless to ship both binaries with debug
> >> info and without it?
> >
> > It should be clear: it's even more disk space waste.
> 
> Why do you think that giving the users the choice to download either
> binaries with debug info or without it is "even more disk space
> waste"?

Having both binaries in the same zip archive doesn't give users more
choice.

Re: emacs-20101122 windows binaries

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Wed, 24 Nov 2010 00:06:42 +0100
> Cc: Sean Sieger <sean.sieger@gmail.com>, emacs-devel@gnu.org
> 
> I offer the same question as I did before: Is there any advantage of
> shipping both binaries with debug info and without it? (In separate
> downloads, of course.)

You never made clear that you are talking about separate downloads,
until now.

Having separate downloads is fine, assuming that Sean (or whoever
prepares the zip archives) can handle the extra workload.

RE: emacs-20101122 windows binaries

[Drew Adams]

s> Making multiple builds available is an admin PITA (if you know how to
s> do better, please advise, but that's been my experience) and the disk
s> space can add up fast (since modularized installs are detested by most
s> users; they want a one-file-download-and-no-questions-asked-install).

Unless I'm missing something you are echoing what I said:

d> In that case, I would think that the only drawbacks to
d> our providing both versions (debug or not) would be disk
d> space at GNU (and other sites for downloading) and
d> preparation time for Emacs developers (twice the work,
d> whatever it might be).

I was asking whether those are the only drawbacks for Emacs dev - they are the
only ones I could think of.  You seem to be confirming that they are (and
emphasizing their importance).

"Shipping" seems to have disappeared from the discussion, so I suppose my guess
that we don't do any shipping was also accurate.

Thanks for the clarification.

RE: emacs-20101122 windows binaries

[Stephen J. Turnbull]

Drew Adams writes:

 > Unless I'm missing something you are echoing what I said:

Sorry 'bout that.  Most of what you write is worth reading, but even
so I run out of time. :-)

 > "Shipping" seems to have disappeared from the discussion, so I suppose my guess
 > that we don't do any shipping was also accurate.

I know GNU does some shipping, I've seen the discs, but whether it's a
real factor for Emacs somebody else would have to answer.

Re: emacs-20101122 windows binaries

[Stefan Monnier]

> You never made clear that you are talking about separate downloads,
> until now.
> Having separate downloads is fine, assuming that Sean (or whoever
> prepares the zip archives) can handle the extra workload.

Actually, this discussion made me realize that we want the release
package to be distributed without debug info: if we need debug info we
might as well ask the user to install the snapshot version.


        Stefan

Re: emacs-20101122 windows binaries

[Sean Sieger]

Jason Rumney <jasonr@gnu.org> writes:

    >  - Releases should or should not include debug info?

    In my experience, users complain (still in 2010) about the size of the
    binary if it changes drastically between releases. So shipping without
    debug info avoids such complaints at the expense that bugs are harder to
    debug (but most users that would be willing to debug for you will be
    using the snapshots or willing to build from source anyway).

Stefan Monnier <monnier@iro.umontreal.ca> writes:

    Actually, this discussion made me realize that we want the release
    package to be distributed without debug info: if we need debug info we
    might as well ask the user to install the snapshot version.

Thank you for your patience (I looked in my .notes:  this is the second
time both of you have told me this) and for thinking this out.