How about a new pretest?

How about a new pretest?

[Juanma Barranquero]

2006/10/27 - 22.0.90
2006/11/18 - 22.0.91
2006/12/18 - waiting... :)

                    /L/e/k/t/u

Re: How about a new pretest?

[Chong Yidong]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> 2006/10/27 - 22.0.90
> 2006/11/18 - 22.0.91
> 2006/12/18 - waiting... :)

It's been waiting on a few big issues, including the now-resolved
C-mode slowness problem.  The main sticking point now is the signal
handling stuff that Kim started up about two weeks ago.  I have no
idea what's going on over there.

Re: How about a new pretest?

[Nick Roberts]

Chong Yidong writes:
 > "Juanma Barranquero" <lekktu@gmail.com> writes:
 > 
 > > 2006/10/27 - 22.0.90
 > > 2006/11/18 - 22.0.91
 > > 2006/12/18 - waiting... :)
 > 
 > It's been waiting on a few big issues, including the now-resolved
 > C-mode slowness problem.  The main sticking point now is the signal
 > handling stuff that Kim started up about two weeks ago.  I have no
 > idea what's going on over there.

I think each pretest tarball should be a release candidate.  So I can't see the
point of a new pretest while bugs are still listed in FOR-RELEASE, other than
to create the illusion that the release is getting nearer.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: How about a new pretest?

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Tue, 19 Dec 2006 08:38:32 +1300
> Cc: Juanma Barranquero <lekktu@gmail.com>, Emacs Devel <emacs-devel@gnu.org>
> 
> I think each pretest tarball should be a release candidate.

I'm not aware of such a policy.  A pretest should fix grave bugs, so
that people could use it in day-to-day work and make sure the bugs are
indeed fixed, and we should strive to make each new release cleaner
and less buggy than the previous one, but that's about it.

> So I can't see the point of a new pretest while bugs are still
> listed in FOR-RELEASE, other than to create the illusion that the
> release is getting nearer.

I don't see any serious bugs in today's FOR-RELEASE, and a cleaner
pretest _does_ make the release nearer, IMO.

Re: How about a new pretest?

[Juanma Barranquero]

On 12/18/06, Nick Roberts <nickrob@snap.net.nz> wrote:

> I think each pretest tarball should be a release candidate.

Obviously, I don't. My own position is in 100% agreement with Eli's.

                    /L/e/k/t/u

Re: How about a new pretest?

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Mon, 18 Dec 2006 12:54:15 -0500
> Cc: Emacs Devel <emacs-devel@gnu.org>
> 
> "Juanma Barranquero" <lekktu@gmail.com> writes:
> 
> > 2006/10/27 - 22.0.90
> > 2006/11/18 - 22.0.91
> > 2006/12/18 - waiting... :)
> 
> It's been waiting on a few big issues, including the now-resolved
> C-mode slowness problem.  The main sticking point now is the signal
> handling stuff that Kim started up about two weeks ago.  I have no
> idea what's going on over there.

If the problem with C-mode slowness was resolved, I'd suggest to make
a new pretest.

Kim, are your proposed changes important enough to wait for them?  For
that matter, can they wait until after the release?

Re: How about a new pretest?

[Kim F. Storm]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Chong Yidong <cyd@stupidchicken.com>
>> Date: Mon, 18 Dec 2006 12:54:15 -0500
>> Cc: Emacs Devel <emacs-devel@gnu.org>
>> 
>> "Juanma Barranquero" <lekktu@gmail.com> writes:
>> 
>> > 2006/10/27 - 22.0.90
>> > 2006/11/18 - 22.0.91
>> > 2006/12/18 - waiting... :)
>> 
>> It's been waiting on a few big issues, including the now-resolved
>> C-mode slowness problem.  The main sticking point now is the signal
>> handling stuff that Kim started up about two weeks ago.  I have no
>> idea what's going on over there.
>
> If the problem with C-mode slowness was resolved, I'd suggest to make
> a new pretest.
>
> Kim, are your proposed changes important enough to wait for them?  For
> that matter, can they wait until after the release?

It is an API change (in the handling of SIGUSR1, SIGUSR2) - so it would
definitely be better to get them done before the release!!

If we agree to roll a new pretest soon, I can make the necessary changes
later today or tomorrow...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: How about a new pretest?

[Kim F. Storm]

storm@cua.dk (Kim F. Storm) writes:

> It is an API change (in the handling of SIGUSR1, SIGUSR2) - so it would
> definitely be better to get them done before the release!!
>
> If we agree to roll a new pretest soon, I can make the necessary changes
> later today or tomorrow...

I just installed the changes (including docs).

So there's one less excuse for not make a new pretest ... 

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: How about a new pretest?

[Chong Yidong]

storm@cua.dk (Kim F. Storm) writes:

> storm@cua.dk (Kim F. Storm) writes:
>
>> It is an API change (in the handling of SIGUSR1, SIGUSR2) - so it would
>> definitely be better to get them done before the release!!
>>
>> If we agree to roll a new pretest soon, I can make the necessary changes
>> later today or tomorrow...
>
> I just installed the changes (including docs).
>
> So there's one less excuse for not make a new pretest ... 

Indeed, there seem to be no more technical issues left in FOR-RELEASE,
so I've rolled a new tarball.  22.0.92 is now available at the usual
spot:

  ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.92.tar.gz
  ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.91-22.0.92.xdelta.sig

Re: How about a new pretest?

[Lennart Borgman]

Chong Yidong wrote:
> storm@cua.dk (Kim F. Storm) writes:
>
>   
>> storm@cua.dk (Kim F. Storm) writes:
>>
>>     
>>> It is an API change (in the handling of SIGUSR1, SIGUSR2) - so it would
>>> definitely be better to get them done before the release!!
>>>
>>> If we agree to roll a new pretest soon, I can make the necessary changes
>>> later today or tomorrow...
>>>       
>> I just installed the changes (including docs).
>>
>> So there's one less excuse for not make a new pretest ... 
>>     
>
> Indeed, there seem to be no more technical issues left in FOR-RELEASE,
> so I've rolled a new tarball.  22.0.92 is now available at the usual
> spot:
>
>   ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.92.tar.gz
>   ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.91-22.0.92.xdelta.sig
>   

If anyone is interested I have uploaded new binaries for w32, built just 
after the tarball release. See

    http://www.emacswiki.org/cgi-bin/wiki/CategoryWThirtyTwo

Re: How about a new pretest?

[Juanma Barranquero]

On 12/19/06, Chong Yidong <cyd@stupidchicken.com> wrote:

> 22.0.92 is now available at the usual spot:
>
>   ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.92.tar.gz

Bootstraps OK on Windows XP Home, with gcc (GCC) 3.4.5 (mingw special).

                    /L/e/k/t/u

Re: How about a new pretest?

[David Kastrup]

Chong Yidong <cyd@stupidchicken.com> writes:

> Indeed, there seem to be no more technical issues left in
> FOR-RELEASE, so I've rolled a new tarball.  22.0.92 is now available
> at the usual spot:

Well, we still have 10 days left for releasing Emacs 22 in 2006.

-- 
David Kastrup

Re: How about a new pretest?

[Juanma Barranquero]

On 12/20/06, David Kastrup <dak@gnu.org> wrote:

> Well, we still have 10 days left for releasing Emacs 22 in 2006.

And avoid updating all these copyrights once again *before* the release. :)

                    /L/e/k/t/u

Re: How about a new pretest?

[Richard Stallman]

I think we should try to fix these two problems now.  The first one
should be easy.  Meanwhile, I think someone prematurely removed the
item about documenting gpg-agent.  People are working on it, but it
hasn't been finished yet.

** make-network-process :nowait t doesn't work for non-local targets
   on Windows.
   If it cannot be fixed, (featurep 'make-network-process '(:nowait t))
   should return nil.

** monnier@iro.umontreal.ca, Nov 24:
  gnus-summary-tick-article-forward doesn't work any more?

Re: How about a new pretest?

[Jason Rumney]

Richard Stallman wrote:
> I think we should try to fix these two problems now.  The first one
> should be easy.
>   
> ** make-network-process :nowait t doesn't work for non-local targets
>    on Windows.
>   
I have looked at this several times myself in the past, and others have 
looked since and made some more progress, but it isn't as simple as it 
should be.
The problem starts with the fact that the native select() on Windows 
only works for network sockets. But Emacs uses select() for subprocess 
I/O, so a long time ago, back when Emacs used an external program for 
network sockets, someone wrote a replacement for select() on w32 to 
handle subprocess I/O (and only subprocess I/O). Network socket support 
had to be added back in to this, then more recently :nowait support was 
added. The resulting code is difficult to understand and debug, and I'm 
sure if it was written from scratch to include non-blocking support for 
sockets, the code would look very different than it does today.

>    If it cannot be fixed, (featurep 'make-network-process '(:nowait t))
>    should return nil.
>   
I think this is probably the right solution for this release, unless 
someone who has the time and has not already tried to understand the 
code wants to try to fix it now.
Otherwise we could look at rewriting the select implementation from 
scratch after the release.

Re: How about a new pretest?

[Kim F. Storm]

Jason Rumney <jasonr@gnu.org> writes:

> Richard Stallman wrote:
>> I think we should try to fix these two problems now.  The first one
>> should be easy.
>>   ** make-network-process :nowait t doesn't work for non-local
>> targets
>>    on Windows.
>>   
> I have looked at this several times myself in the past, and others
> have looked since and made some more progress, but it isn't as simple
> as it should be.

No, but it doesn't seem too complicated either.

The code would look pretty much like the _sys_wait_accept code (using
FD_CONNECT rather than FD_ACCEPT).

In sys_connect, we would have to arrange for the reader_thread to
first wait for _sys_wait_connect (e.g. by a new flag FILE_CONNECT
set by sys_connect if FILE_NDELAY is set).

Finally, sys_select would have to look into wdesc too, basically just
waiting for the status to change to STATUS_READ_SUCCEEDED (and do
the obvious things in that case).


Btw, I noticed that the way the reader thread does "recv 1 byte" to
wait for input means that for a datagram socket, it actually discards
most datagrams.  So it would probably be better to use FD_READ to
wait for incoming data on sockets...


Well, I might give it a shot after Xmas.


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: How about a new pretest?

[Richard Stallman]

    >> I think we should try to fix these two problems now.  The first one
    >> should be easy.
    >>   ** make-network-process :nowait t doesn't work for non-local
    >> targets
    >>    on Windows.

    Well, I might give it a shot after Xmas.

Making the code report that the feature doesn't exist on MS Windows
has solved the problem.  Now we're talking about adding a feature.

That shouldn't be done until after the release.  But I hope that if
this is done then, it won't be done by you.  The reason is that improving
Emacs for Windows alone is not as important as improving it for free systems.
You are very capable of making the sorts of improvements that will
really make Emacs better for users.  I hope you will focus on them.

Re: How about a new pretest?

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     >> I think we should try to fix these two problems now.  The first one
>     >> should be easy.
>     >>   ** make-network-process :nowait t doesn't work for non-local
>     >> targets
>     >>    on Windows.
>
>     Well, I might give it a shot after Xmas.
>
> Making the code report that the feature doesn't exist on MS Windows
> has solved the problem.  Now we're talking about adding a feature.

Unfortunately, I just discovered (by reading the code) that datagram
support is severely broken on Windows -- it can send datagrams, but
not receive them reliably.

So datagram support should probably be disabled too.  

> That shouldn't be done until after the release.  But I hope that if
> this is done then, it won't be done by you.  

I'd hope so too - but nobody else seems to be capable of understanding
the code...

>                                              The reason is that improving
> Emacs for Windows alone is not as important as improving it for free systems.

IMO, it is not "improving for Windows alone" ... it is a matter of making
the Windows port work like the other ports.  


> You are very capable of making the sorts of improvements that will
> really make Emacs better for users.  I hope you will focus on them.

Sure ...  I just hope we get Emacs 22 out of the door soon, so we can
get on with some of the projects which have been on-hold for years now.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: How about a new pretest?

[Stefan Monnier]

> Unfortunately, I just discovered (by reading the code) that datagram
> support is severely broken on Windows -- it can send datagrams, but
> not receive them reliably.

> So datagram support should probably be disabled too.  

I don't know of any elisp code that uses datagram sockets, so it's not
a big deal, is it?

> IMO, it is not "improving for Windows alone" ... it is a matter of making
> the Windows port work like the other ports.  

I think it only makes sense if it allows simplification of other
(generic) code.


        Stefan

Re: How about a new pretest?

[Richard Stallman]

    Unfortunately, I just discovered (by reading the code) that datagram
    support is severely broken on Windows -- it can send datagrams, but
    not receive them reliably.

    So datagram support should probably be disabled too.  

Would you please do that?  It should be a quick and easy change, right?

Re: How about a new pretest?

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Unfortunately, I just discovered (by reading the code) that datagram
>     support is severely broken on Windows -- it can send datagrams, but
>     not receive them reliably.
>
>     So datagram support should probably be disabled too.  
>
> Would you please do that?  It should be a quick and easy change, right?

Yes.  Done.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: How about a new pretest?

[Richard Stallman]

    >                                              The reason is that improving
    > Emacs for Windows alone is not as important as improving it for free systems.

    IMO, it is not "improving for Windows alone" ... it is a matter of making
    the Windows port work like the other ports.  

Right, but that is lower priority than making Emacs work better on GNU.
I usually don't spend time on Windows issues myself, and I hope you too
will leave them to others.

Re: How about a new pretest?

[Lennart Borgman]

Richard Stallman wrote:
>     >                                              The reason is that improving
>     > Emacs for Windows alone is not as important as improving it for free systems.
> 
>     IMO, it is not "improving for Windows alone" ... it is a matter of making
>     the Windows port work like the other ports.  
> 
> Right, but that is lower priority than making Emacs work better on GNU.
> I usually don't spend time on Windows issues myself, and I hope you too
> will leave them to others.


I understand the priority, but I think we also should take into account 
that there currently are a bigger amount of bugs on the w32 side.

Re: How about a new pretest?

[Richard Stallman]

    I understand the priority, but I think we also should take into account 
    that there currently are a bigger amount of bugs on the w32 side.

Features not supported on Windows are not bugs.

Re: How about a new pretest?

[Lennart Borgman]

Richard Stallman wrote:
>     I understand the priority, but I think we also should take into account 
>     that there currently are a bigger amount of bugs on the w32 side.
> 
> Features not supported on Windows are not bugs.


That was not what I wrote about.

Re: How about a new pretest?

[Richard Stallman]

    > ** make-network-process :nowait t doesn't work for non-local targets
    >    on Windows.
    >   
    I have looked at this several times myself in the past, and others have 
    looked since and made some more progress, but it isn't as simple as it 
    should be.

That is sufficient of evidence that it is hard.

    >    If it cannot be fixed, (featurep 'make-network-process '(:nowait t))
    >    should return nil.
    >   
    I think this is probably the right solution for this release, 

I am satisfied with that solution.