websocket-test.el fails on 32 bit machine

[tkf]

Here is the full tracebacks:
https://gist.github.com/3046935

I checked in Emacs 24.1.50.1 and 23.1.1. Some machine information:

% uname -m
i686
% lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 10.10
Release:        10.10
Codename:       maverick

In 64 bit machine, the test was fine. Note that websocket.el actually works in the 32 bit machine. I haven't notice the problem at all until now.

Furthermore, @epatters and @Boothead report that loading websocket.el fails with load-with-code-conversion: Arithmetic overflow error: "4294967296" while reading the number 4294967296. Note that I have no problem loading websocket.el even though most-positive-fixnum (=536870911) is smaller than 4294967296.

The original report is here: tkf/emacs-ipython-notebook#8

[ahyatt]

I'm not sure I understand the gist. Those are my tests, but I don't see that my tests are doing anything with testing out powers of 2. For instance, in the first broken test, websocket-encode-frame, I just test out encoding strings of length 200 and 7000. But your test seems to be doing something else. Am I missing something?

Also, the error with parsing 4294967296 seems plausible, at least when byte-compiling. I'll fix that somehow.

[tkf]

I think you can see that some integer is overflowing in the websocket-to-bytes test. Don't you think overflow can break some test cases, because you are using a big number which cannot represented in the integer object?

In Emacs 23.1:

Test websocket-to-bytes condition:
    (ert-test-failed
     ((should
       (equal 70000
          (websocket-get-bytes ... 8)))
      :form
      (equal 70000 -300647710720000.0)
      :value nil :explanation
      (different-types 70000 -300647710720000.0)))

In Emacs 24.1:

Test websocket-to-bytes condition:
    (wrong-type-argument integerp 1.6298145055770874e-05)

BTW, these difference is maybe from this change in 23.2:

* Incompatible Lisp Changes in Emacs 23.2

** The Lisp reader turns integers that are too large/small into floats.
For instance, on machines where `536870911' is the largest integer,
reading `536870912' gives the floating-point object `536870912.0'.

This change only concerns the Lisp reader; it does not affect how
actual integer objects overflow.

-- http://www.gnu.org/software/emacs/NEWS.23.2 (via http://stackoverflow.com/questions/2975653)

[ahyatt]

That's really interesting, thanks for finding that issue. Yeah, I understand the issue, just not that gist. I'm working on replacing things with calc in appropriate places. It will slow some things down, but hopefully sending packets that are longer than ~4GB long is going to rare.

[tkf]

Thanks!

[ahyatt]

Should be fixed in cf885f0. Since I can't reproduce the issue, please re-open this bug if it does not fix the issue.

[gcr]

...Amazing. I literally found emacs-ipython-notebook minutes before you fixed this bug.

Your fix works for me. Arch linux 32-bit, Emacs 23.1. Before, (require 'websocket) would fail with load-with-code-conversion: Arithmetic overflow error: "4294967296"

With latest master, it works fine.

Thanks.

[ahyatt]

@tkf, also if you find that this fixes your users issues (such as it seems to have done for @gcr, yay), then I'll update the version number.

[tkf]

Wow, that's super fast! Unfortunately I can't access 32-bit machine now. I will tell the result when check it.

@gcr, thanks for checking and comment! I guess then it should work on my machine.

[epatters]

websocket.el now loads without error on my 32-bit system also. At one point, I did get an Arithmetic error while using emacs-ipython-notebook, but I have not been able to reproduce it. I will report back if I encounter more problems.

[tkf]

I tweaked test to run it in 32-bit system. Please check #19. It seems that websocket.el itself works properly.