Re: Problems with the url package on w32?

Re: Problems with the url package on w32?

[Magnus Henoch]

Does anyone know what to do about this?


> Mathias Dahl <brakjoller@gmail.com> writes:
>
>>> Does (make-network-process :name "http" :buffer "http-localhost"
>>>                            :host "127.0.0.1" :service 80
>>>                            :nowait t)
>>> work?
>>
>> I get no error but it returns `nil'. I guess it should return a
>> process object, right?
>
> Yes.  Does it work with hosts other than localhost?

[ it doesn't ]

> The direct cause of the `nil' return value is this code in process.c:
>
>   if (s < 0)
>     {
>       /* If non-blocking got this far - and failed - assume non-blocking is
> 	 not supported after all.  This is probably a wrong assumption, but
> 	 the normal blocking calls to open-network-stream handles this error
> 	 better.  */
>       if (is_non_blocking_client)
> 	  return Qnil;
>
> This seems to be a bug of some sort.  The documentation doesn't
> mention that make-network-process might ever return nil.  I see four
> possible solutions; someone who knows Windows should look at this.
>
> 1. Make non-blocking connections work on Windows.
> 2. Make (featurep 'make-network-process '(:nowait t)) return nil on
>    Windows.
> 3. Document that make-network-process returns nil if it fails to
>    create a non-blocking socket.
> 4. Make make-network-socket do a blocking connect if a non-blocking
>    connect fails, and document that.
>
> Magnus

Re: Problems with the url package on w32?

[Richard Stallman]

    > 1. Make non-blocking connections work on Windows.
    > 2. Make (featurep 'make-network-process '(:nowait t)) return nil on
    >    Windows.
    > 3. Document that make-network-process returns nil if it fails to
    >    create a non-blocking socket.
    > 4. Make make-network-socket do a blocking connect if a non-blocking
    >    connect fails, and document that.

Why not make it signal an error if it can't do what was requested?

Re: Problems with the url package on w32?

[Magnus Henoch]

Richard Stallman <rms@gnu.org> writes:

>     > 1. Make non-blocking connections work on Windows.
>     > 2. Make (featurep 'make-network-process '(:nowait t)) return nil on
>     >    Windows.
>     > 3. Document that make-network-process returns nil if it fails to
>     >    create a non-blocking socket.
>     > 4. Make make-network-socket do a blocking connect if a non-blocking
>     >    connect fails, and document that.
>
> Why not make it signal an error if it can't do what was requested?

Hm... that might work.  IMO it should be easy for a program to find
out what happened (non-blocking connect doesn't work in this case), so
it can perform a certain remedy (doing a blocking connect instead).  A
specific error "nowait-not-supported" could be the solution.

Magnus

Re: Problems with the url package on w32?

[Kim F. Storm]

Magnus Henoch <mange@freemail.hu> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>>     > 1. Make non-blocking connections work on Windows.
>>     > 2. Make (featurep 'make-network-process '(:nowait t)) return nil on
>>     >    Windows.
>>     > 3. Document that make-network-process returns nil if it fails to
>>     >    create a non-blocking socket.
>>     > 4. Make make-network-socket do a blocking connect if a non-blocking
>>     >    connect fails, and document that.
>>
>> Why not make it signal an error if it can't do what was requested?
>
> Hm... that might work.  IMO it should be easy for a program to find
> out what happened (non-blocking connect doesn't work in this case), 

A non-blocking connect is requested by making the socket non-blocking
before calling connect ...

How would it know that connect failed because it requested a
non-blocking connect vs. other error codes?

>                                                                     so
> it can perform a certain remedy (doing a blocking connect instead).  A
> specific error "nowait-not-supported" could be the solution.

If :nowait t doesn't work on Windoze,
(featurep 'make-network-process '(:nowait t)) should return nil.  

But why doesn't it work on Windoze?  Could someone please investigate it?

If this is a general problem, BROKEN_NON_BLOCKING_CONNECT should
be defined in window...

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

Re: Problems with the url package on w32?

[Kim F. Storm]

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

> If :nowait t doesn't work on Windoze,
> (featurep 'make-network-process '(:nowait t)) should return nil.  
>
> But why doesn't it work on Windoze?  Could someone please investigate it?
>
> If this is a general problem, BROKEN_NON_BLOCKING_CONNECT should
> be defined in window...


Would someone please check if this patch gives "good" results on Windows,
that is, make
  (featurep 'make-network-process '(:nowait t))
return nil, and not have any other bad effects on network connections.



*** ms-w32.h	15 Dec 2006 01:26:24 +0100	1.41
--- ms-w32.h	19 Dec 2006 16:45:18 +0100	
***************
*** 137,142 ****
--- 137,147 ----
  
  #define HAVE_SOCKETS 1
  
+ /* But our select implementation doesn't allow us to make non-blocking
+    connects.  So until that is fixed, this is necessary:  */
+ 
+ #define BROKEN_NON_BLOCKING_CONNECT 1
+ 
  /* Define this symbol if your system has the functions bcopy, etc. */
  
  #define BSTRING

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

Re: Problems with the url package on w32?

[Juanma Barranquero]

On 12/19/06, Kim F. Storm <storm@cua.dk> wrote:

> Would someone please check if this patch gives "good" results on Windows,
> that is, make
>   (featurep 'make-network-process '(:nowait t))
> return nil

Yes.

> and not have any other bad effects on network connections.

Well, I didn't do any extensive check, but the TCP server still works
OK from a local connection.

                    /L/e/k/t/u

Re: Problems with the url package on w32?

[Kim F. Storm]

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

> On 12/19/06, Kim F. Storm <storm@cua.dk> wrote:
>
>> Would someone please check if this patch gives "good" results on Windows,
>> that is, make
>>   (featurep 'make-network-process '(:nowait t))
>> return nil
>
> Yes.

Thank you.  I have installed it now.

Actually, no other system defines BROKEN_NON_BLOCKING_CONNECT, but
it seems that I must have expected problems when I wrote the
non-blocking code, and thus added that option to disable it easily.

Too bad nobody cared to make non-blocking connects work on Windows 
before the release ...

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

Re: Problems with the url package on w32?

[Juanma Barranquero]

On 12/20/06, Kim F. Storm <storm@cua.dk> wrote:

> Too bad nobody cared to make non-blocking connects work on Windows
> before the release ...

In my case, it's not about care, it's about knowledge. That's one of
the (many) parts of Emacs that I still don't grasp at all.

Perhaps we need Emacs developer's workshops :)

                    /L/e/k/t/u

Re: Problems with the url package on w32?

[Lennart Borgman]

Kim F. Storm wrote:
> storm@cua.dk (Kim F. Storm) writes:
>
>   
>> If :nowait t doesn't work on Windoze,
>> (featurep 'make-network-process '(:nowait t)) should return nil.  
>>
>> But why doesn't it work on Windoze?  Could someone please investigate it?
>>
>> If this is a general problem, BROKEN_NON_BLOCKING_CONNECT should
>> be defined in window...
>>     
>
>
> Would someone please check if this patch gives "good" results on Windows,
> that is, make
>   (featurep 'make-network-process '(:nowait t))
> return nil, and not have any other bad effects on network connections.
>
>
>
> *** ms-w32.h	15 Dec 2006 01:26:24 +0100	1.41
> --- ms-w32.h	19 Dec 2006 16:45:18 +0100	
> ***************
> *** 137,142 ****
> --- 137,147 ----
>   
>   #define HAVE_SOCKETS 1
>   
> + /* But our select implementation doesn't allow us to make non-blocking
> +    connects.  So until that is fixed, this is necessary:  */
> + 
> + #define BROKEN_NON_BLOCKING_CONNECT 1
> + 
>   /* Define this symbol if your system has the functions bcopy, etc. */
>   
>   #define BSTRING
>   
I tried to test, but I see Juanma has already done that now. Good.

However I noticed another very strange thing. I just tried to appy the 
patch with ediff-patch, using gnuwin32 binaries. It just hangs. Or 
rather patch seems to loop.

    emacs -Q (latest binaries built after pretest release today)
    C-x C-f .... ms-w32.h
    C-x C-f .... the-patch.diff
    M-x ediff-patch-buffers
    (answers with the default, ie the buffers from above)

Well, I was wrong... - after 5 min the patch was ready ... 3GHz, 
everything else runs fine...

There seem to be a bug here on some level. Has anyone else seen this?

Re: Problems with the url package on w32?

[Juanma Barranquero]

On 12/20/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:

> There seem to be a bug here on some level. Has anyone else seen this?

I never apply a patch from inside Emacs. When the patch is not kosher
(spaces changed by your e-mail program, crlf/lf issues, etc.) it is
perfectly possible to get "hunk applied" messages for hunks that
weren't really applied.

                    /L/e/k/t/u

Re: Problems with the url package on w32?

[Lennart Borgman]

Juanma Barranquero wrote:
> On 12/20/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:
>
>> There seem to be a bug here on some level. Has anyone else seen this?
>
> I never apply a patch from inside Emacs. When the patch is not kosher
> (spaces changed by your e-mail program, crlf/lf issues, etc.) it is
> perfectly possible to get "hunk applied" messages for hunks that
> weren't really applied.
>
>                    /L/e/k/t/u

So I am not alone in seeing the problem at least. But (oh, this is 
memories from the past!) since it is only text files we patch here why 
are cr-lf etc a problem? Can't ediff-patch handle these for us? (And we 
take the responsibility for ignoring spaces - I guess there is ediff 
support for this in this case too?)

Re: Problems with the url package on w32?

[Juanma Barranquero]

On 12/20/06, Lennart Borgman <lennart.borgman.073@student.lu.se> wrote:

> So I am not alone in seeing the problem at least.

No. But I haven't ever taken the time to investigate it.

> since it is only text files we patch here why
> are cr-lf etc a problem? Can't ediff-patch handle these for us? (And we
> take the responsibility for ignoring spaces - I guess there is ediff
> support for this in this case too?)

Good questions...

                    /L/e/k/t/u

Re: Problems with the url package on w32?

[Eli Zaretskii]

> Date: Wed, 20 Dec 2006 00:54:00 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> I never apply a patch from inside Emacs.

I do, but I do it with "M-|", not with Ediff.

> When the patch is not kosher
> (spaces changed by your e-mail program, crlf/lf issues, etc.) it is
> perfectly possible to get "hunk applied" messages for hunks that
> weren't really applied.

Never had such problems with my method, since the shell command output
is displayed by M-|.

Re: Problems with the url package on w32?

[Juanma Barranquero]

On 12/20/06, Eli Zaretskii <eliz@gnu.org> wrote:

> I do, but I do it with "M-|", not with Ediff.

I don't use ediff either. I was talking of cutting a patch from an
e-mail, for example, pasting it into a buffer, M-x diff-mode'ing and
doing C-c C-a. If your e-mail program did somehow alter the patch
(which Gmail does, unless you take pains to extract the patch from the
original view), C-c C-a often mistakenly says that it's applying hunks
which it's not.

> Never had such problems with my method, since the shell command output
> is displayed by M-|.

That only means that you method works, not that diff-mode or ediff
don't have a problem :-)

                    /L/e/k/t/u

Re: Problems with the url package on w32?

[Eli Zaretskii]

> Date: Wed, 20 Dec 2006 10:07:15 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: lennart.borgman.073@student.lu.se, emacs-devel@gnu.org
> 
> I don't use ediff either. I was talking of cutting a patch from an
> e-mail, for example, pasting it into a buffer, M-x diff-mode'ing and
> doing C-c C-a.

Too complicated, IMHO, and also could produce problems on w32 (due to
CRLF nuisance in conjunction with the ported Patch's inability to DTRT
when there's EOL mismatch between the patched file and the patch).
What I do is simpler: set the region around the diffs in the email
buffer, and then type these commands:

	C-x RET c unix RET
	M-| patch -d /path/to/emacs/directory -p0 --binary

(Depending on the exact form of file names in the diffs, the argument
to the -d switch and/or the level given to -p may need to be
different.)

This works reliably for me, and if the diffs were munged by email, I
get a failure message in the minibuffer and a .rej file left to be
handled manually.

> > Never had such problems with my method, since the shell command output
> > is displayed by M-|.
> 
> That only means that you method works, not that diff-mode or ediff
> don't have a problem :-)

I was replying to your message where you seemed to imply that running
Patch from within Emacs is inherently unstable or unreliable.

Re: Problems with the url package on w32?

[Juanma Barranquero]

On 12/20/06, Eli Zaretskii <eliz@gnu.org> wrote:

> What I do is simpler: set the region around the diffs in the email
> buffer, and then type these commands:

I assume you read e-mail from within Emacs. I never do that.

> I was replying to your message where you seemed to imply that running
> Patch from within Emacs is inherently unstable or unreliable.

I talked of "apply[ing] a patch from inside Emacs", which could be
understood as referring to running an external patch, but I also
talked of "get[ting] 'hunk applied' messages". For the record, what
I'm saying is that `diff-apply-hunk' is unreliable.

                    /L/e/k/t/u

Re: Problems with the url package on w32?

[Stefan Monnier]

> original view), C-c C-a often mistakenly says that it's applying hunks
> which it's not.

This is the first time I hear of such a problem with C-c C-a.
For the record I know of the following problems:
- C-c C-a may apply the patch at the wrong placem if the context is not
  sufficiently discriminating.
- C-c C-a may claim the patch was already applied when it's not (typically
  again because the context is not sufficiently discriminating).
- C-c C-a may also occasionally fail to apply a patch even though it should
  succeed (e.g. because the hunk it too big which breaks the code that
  tries to ignore space-changes).

If you know of any other problem, please report it,


        Stefan

Re: Problems with the url package on w32?

[Juanma Barranquero]

On 12/20/06, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> If you know of any other problem, please report it,

What I've seen many times is like your third item, but the hunks are
not necessarily big.

I've never investigated it, but I think it is related to changes in
space and/or end-of-line conventions in the patch.

                    /L/e/k/t/u

Re: Problems with the url package on w32?

[Stefan Monnier]

>> If you know of any other problem, please report it,

> What I've seen many times is like your third item, but the hunks are
> not necessarily big.

I.e. C-c C-a fails to apply the hunk (i.e. doesn't change the buffer at
all), and correctly tells the user about this failure?

If so, it's a "minor" bug.

> I've never investigated it, but I think it is related to changes in
> space and/or end-of-line conventions in the patch.

I'd be interested to learn more about it, so please send me the data next
time you encounter such a case.


        Stefan

Re: Problems with the url package on w32?

[Juanma Barranquero]

On 12/21/06, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> I.e. C-c C-a fails to apply the hunk (i.e. doesn't change the buffer at
> all), and correctly tells the user about this failure?
>
> If so, it's a "minor" bug.

No. C-c C-a says "hunk applied" (something like that) and the hunk is
*not* applied.

> I'd be interested to learn more about it, so please send me the data next
> time you encounter such a case.

I'll do.

                    /L/e/k/t/u

Re: Problems with the url package on w32?

[Stefan Monnier]

>> I.e. C-c C-a fails to apply the hunk (i.e. doesn't change the buffer at
>> all), and correctly tells the user about this failure?
>> 
>> If so, it's a "minor" bug.

> No. C-c C-a says "hunk applied" (something like that) and the hunk is
> *not* applied.

Then it's not like 3 and it's a major bug.  If it says "applied" it should
have been applied.

>> I'd be interested to learn more about it, so please send me the data next
>> time you encounter such a case.
> I'll do.

Thanks,


        Stefan

Re: Problems with the url package on w32?

[Lennart Borgman]

Stefan Monnier wrote:
>>> If you know of any other problem, please report it,
>>>       
>
>   
>> What I've seen many times is like your third item, but the hunks are
>> not necessarily big.
>>     
>
> I.e. C-c C-a fails to apply the hunk (i.e. doesn't change the buffer at
> all), and correctly tells the user about this failure?
>
> If so, it's a "minor" bug.
>   

I think that on w32 several things can happen. The main problem is the 
line endings and the ability of different patch.exe on w32 to handle 
them. I sent a link to my tests earlier. They are probably difficult to 
understand by just reading that page, I can't even remember myself anymore.

However I do have a suggestion: It would be good to have a function in 
emacs handling the problems with different line endings for patch. This 
could be used for diff-apply-hunk and other similar functions in ediff.

This function could do something like this:

   1) read the file(s) to patch and the patch.
   2) if line endings are the same and can be used by the tools just 
apply the patch
   3) otherwise write rewrite the files with new line endings as needed 
and apply the patch. Switch back to old line endings for the patched 
file if necessary.

Without something like this I think we can not get patch to work from 
emacs reliable on w32. It would be a benefit for other platforms be able 
to I believe.

Re: Problems with the url package on w32?

[Stefan Monnier]

>> I.e. C-c C-a fails to apply the hunk (i.e. doesn't change the buffer at
>> all), and correctly tells the user about this failure?
>> If so, it's a "minor" bug.
> I think that on w32 several things can happen. The main problem is the line
> endings and the ability of different patch.exe on w32 to handle them. I sent

diff-mode's C-c C-a does not use any external tool, only elisp code.


        Stefan

Re: Problems with the url package on w32?

[Lennart Borgman]

Stefan Monnier wrote:
> diff-mode's C-c C-a does not use any external tool, only elisp code.
>   
Thanks, I did not know.

Re: Problems with the url package on w32?

[Lennart Borgman]

Juanma Barranquero wrote:
> On 12/20/06, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> I do, but I do it with "M-|", not with Ediff.
>
> I don't use ediff either. I was talking of cutting a patch from an
> e-mail, for example, pasting it into a buffer, M-x diff-mode'ing and
> doing C-c C-a. If your e-mail program did somehow alter the patch
> (which Gmail does, unless you take pains to extract the patch from the
> original view), C-c C-a often mistakenly says that it's applying hunks
> which it's not.

I tried to look into the problem with ediff-patch a bit. It took quite 
some time to figure out what is going on. There are different bugs and 
misfeatures.

1) First ediff-patch-file--internal calls call-process-region with a 
shell as its program. This means that the file arguments must be 
converted with convert-standard-filename. This is a clear bug.

2) Then ediff-shell has a bad initialization value in my opinion. On w32 
it is initialized to the value of shell-file-name at that time. There is 
not very much sense in that. ediff-shell is used only 
ediff-patch-file--internal. There it overrides shell-file-name. It would 
be much better to initialize it to nil and then use this value only if 
it is set. Otherwise shell-file-name should be used.

3) There is something very strange when calling patch this way from 
emacs. It takes up to 10 s to apply that little patch Kim sent if 
cmdproxy with gnuwin32 binaries or Cygwin is used as inferior shells. 
Applying the patch from outside Emacs does not take any time at all with 
gnubinaries in cmd.exe. Using MSYS for the inferior shell on the other 
hand takes very little time. Is there something wrong with cmdproxy and 
the call of it from emacs?

Should I send patches for 1 + 2?

Re: Problems with the url package on w32?

[Lennart Borgman]

Lennart Borgman wrote:
> Juanma Barranquero wrote:
>> On 12/20/06, Eli Zaretskii <eliz@gnu.org> wrote:
>>
>>> I do, but I do it with "M-|", not with Ediff.
>>
>> I don't use ediff either. I was talking of cutting a patch from an
>> e-mail, for example, pasting it into a buffer, M-x diff-mode'ing and
>> doing C-c C-a. If your e-mail program did somehow alter the patch
>> (which Gmail does, unless you take pains to extract the patch from the
>> original view), C-c C-a often mistakenly says that it's applying hunks
>> which it's not.
>
> I tried to look into the problem with ediff-patch a bit. It took quite 
> some time to figure out what is going on. There are different bugs and 
> misfeatures.
>
> 1) First ediff-patch-file--internal calls call-process-region with a 
> shell as its program. This means that the file arguments must be 
> converted with convert-standard-filename. This is a clear bug.
>
> 2) Then ediff-shell has a bad initialization value in my opinion. On 
> w32 it is initialized to the value of shell-file-name at that time. 
> There is not very much sense in that. ediff-shell is used only 
> ediff-patch-file--internal. There it overrides shell-file-name. It 
> would be much better to initialize it to nil and then use this value 
> only if it is set. Otherwise shell-file-name should be used.
>
> 3) There is something very strange when calling patch this way from 
> emacs. It takes up to 10 s to apply that little patch Kim sent if 
> cmdproxy with gnuwin32 binaries or Cygwin is used as inferior shells. 
> Applying the patch from outside Emacs does not take any time at all 
> with gnubinaries in cmd.exe. Using MSYS for the inferior shell on the 
> other hand takes very little time. Is there something wrong with 
> cmdproxy and the call of it from emacs?
>
> Should I send patches for 1 + 2?

Looking into this a bit more I can see that 3 is probably a problem with 
line endings and the patch program. There might be more problems since 
cmdproxy is involved in the case taking long time (or actually just 
hangs) but not in the other, I am not sure about that. The problem with 
the line endings are however certain, see the end of this file for some 
tests of different patch programs on w32 I finished a year ago:

   http://ourcomments.org/GNU/patchcrlf/readme.txt

Now I believe that this is possible to solve within ediff if ediff 
always makes sure that the patch file and the file to patch always have 
the same line endings (and perhaps that this can be choosen to LF or 
CRLF). Further I think that the patched file of course should have the 
same line endings as the original file.


Michael, what do you think about this? I think the main part of this can 
be done in ediff-patch-file--internal, or?

Re: Problems with the url package on w32?

[Richard Stallman]

    >     > 1. Make non-blocking connections work on Windows.
    >     > 2. Make (featurep 'make-network-process '(:nowait t)) return nil on
    >     >    Windows.
    >     > 3. Document that make-network-process returns nil if it fails to
    >     >    create a non-blocking socket.
    >     > 4. Make make-network-socket do a blocking connect if a non-blocking
    >     >    connect fails, and document that.
    >
    > Why not make it signal an error if it can't do what was requested?

    Hm... that might work.  IMO it should be easy for a program to find
    out what happened (non-blocking connect doesn't work in this case), so
    it can perform a certain remedy (doing a blocking connect instead).  A
    specific error "nowait-not-supported" could be the solution.

Does anyone argue against this?

Re: Problems with the url package on w32?

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     >     > 1. Make non-blocking connections work on Windows.
>     >     > 2. Make (featurep 'make-network-process '(:nowait t)) return nil on
>     >     >    Windows.
>     >     > 3. Document that make-network-process returns nil if it fails to
>     >     >    create a non-blocking socket.
>     >     > 4. Make make-network-socket do a blocking connect if a non-blocking
>     >     >    connect fails, and document that.
>     >
>     > Why not make it signal an error if it can't do what was requested?
>
>     Hm... that might work.  IMO it should be easy for a program to find
>     out what happened (non-blocking connect doesn't work in this case), so
>     it can perform a certain remedy (doing a blocking connect instead).  A
>     specific error "nowait-not-supported" could be the solution.
>
> Does anyone argue against this?

I just did!

I would like someone to investigate why the non-blocking connect
doesn't work, before deciding what to do.

Does if fail before calling connect (e.g. when setting the socket to
non-blocking), does it fail in the connect itself (what error code is
returned in that case), or does it fail because the emulated select on
w32 doesn't handle non-blocking connect well (it relies on the
write-descriptors).

Maybe a local non-blocking connect (127.0.0.1) succeeds because it
is actually handled as a blocking connect, and returns immediately,
whereas a non-local non-blocking connect fails because the select
system call doesn't work??

If this is the case, windoze doesn't support non-blocking connects,
so (featurep 'make-network-process '(:nowait t)) should return nil.

Perhaps the doc-string for make-network-process should mention using
featurep to check for sub-features.

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

Re: Problems with the url package on w32?

[Richard Stallman]

    I would like someone to investigate why the non-blocking connect
    doesn't work, before deciding what to do.

If it can be fixed to work, that is better than making it an error.
If people fix it soon, that's good.  But if nobody implements that
in 5 days, please let's make it an error.

The possibility of making it work right will still exist,
if someone wants to do it.

Re: Problems with the url package on w32?

[LENNART BORGMAN]

From: storm@cua.dk (Kim F. Storm)
> Too bad nobody cared to make non-blocking connects work on Windows 
> before the release ...


Yes, I agree. Maybe it is just because there seem to be too many subtle bugs that one stumble on on the w32 side. Problems with ported gnu applications, problems within Emacs... It wastes a lot of time that the code in some cases does not seem to be written to be portable from the beginning. A lack of structure I believe.

And of course not everyone has the knowledge about networking on both w32 and *nix which seems to be needed to fix those things.

Re: Problems with the url package on w32?

[Kim F. Storm]

LENNART BORGMAN <lennart.borgman.073@student.lu.se> writes:

> From: storm@cua.dk (Kim F. Storm)
>> Too bad nobody cared to make non-blocking connects work on Windows 
>> before the release ...
>
>
> Yes, I agree. Maybe it is just because there seem to be too many
> subtle bugs that one stumble on on the w32 side. Problems with
> ported gnu applications, problems within Emacs... It wastes a lot of
> time that the code in some cases does not seem to be written to be
> portable from the beginning. A lack of structure I believe.

The current code in process.c is written with portability in mind,
but nobody knows everything about every system -- so someone
who knows (or want to give it a try) must help with those corner
cases.

> And of course not everyone has the knowledge about networking on
> both w32 and *nix which seems to be needed to fix those things.

Someone with a debugger on w32 should be able to set a breakpoint
on Fmake_network_process (without my latest change!!) and see why
it returns nil when passed :nowait t.

Just knowing the return code from connect may tell us something
(if it gets that far).

When nobody volounteered to debug why server sockets didn't work,
I went ahead and did it myself (with kind assistance to build and
test from others).  And I certainly don't know anything about
WinSock programming.

I don't have time to do the same for non-blocking connects.

Besides, while non-functional server sockets was a severe
short-coming, not having non-blocking connect is mainly
inconvenient rather than fatal (as long as the code tries
a blocking connect if non-blocking isn't available).

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

Re: Problems with the url package on w32?

[Jason Rumney]

LENNART BORGMAN wrote:
> It wastes a lot of time that the code in some cases does not seem to be written to be portable from the beginning.
>   
Indeed. The lack of portability in Windows APIs does waste a lot of 
time. But we can't fix Windows, so we have to workaround the problems in 
Emacs instead.