Javascript: NaN (Gültigkeitsbereich?)

[Verwirrnix]

Ich spiele gerade ein wenig mit dem "JsonHttpRequest", der allgemein als "XmlHttpRequest" bezeichnet wird. Das Zeug ist ziemlich unfertig, das Js gelinde gesagt "OldSchool".

Zum Problem: Dieses Skript liefert die Daten:

• http://www.fastix.org/test/netzlast.php (oder)
• http://www.fastix.org/test/netzlast.php?device=eth0 (oder)
• http://www.fastix.org/test/netzlast.php?device=lo

Ausgewertet werden diese Daten durch Javascript in der problematischen Seite.

Bis heute abend ging das. Dann ging ich einkaufen …

Effekte:

• Im aktuellen Firefox (Version 57, Ubuntu, 64 Bit) läuft es.
• Im Chromium Version 63.0.3239.84 (Offizieller Build) Built on Ubuntu , running on Ubuntu 16.04 (64-Bit) läuft es solange wie die Entwicklertools offen sind. Macht man die zu gibt es NaN-Geningel. Macht man die Entwicklertools wieder auf läuft der Ticker sauber weiter.
• Im Midori (0.5.11) läuft es nicht. Meckert "NaN".

Sicherheitshalber mal das aktuell gelieferte JSON:

{
  "eth0":
    {
      "RX":696506606592,
      "TX":565241147157
    },
  "time":1515091897.98112
}

Hint:

1. Mit den anderen (kleineren) Zahlen auf dem Home-Server geht es. Angeblich soll Js aber mindestens 15 Stellen als Integer bringen.

2. parseInt() und parseFloat() habe ich schon erfolgsfrei versucht.

[MudGuard]

Hi,

• Im Chromium Version 63.0.3239.84 (Offizieller Build) Built on Ubuntu , running on Ubuntu 16.04 (64-Bit) läuft es solange wie die Entwicklertools offen sind. Macht man die zu gibt es NaN-Geningel. Macht man die Entwicklertools wieder auf läuft der Ticker sauber weiter.

das deutet auf ein Timing-Problem hin - mit Entwicklertool ist's langsamer, weil die Debug-Sachen ermittelt werden.

1. Mit den anderen (kleineren) Zahlen auf dem Home-Server geht es. Angeblich soll Js aber mindestens 15 Stellen als Integer bringen.

hm. Ein 32-Bit Integer hat den Wertebereich von -2147483648 bis 2147483648 (an einem der Enden um 1 weniger, kann mir nie merken, an welchem), also bis zu 10 Ziffern.

Ein 64-Bit Integer hätte den Wertebereich von -9223372036854775808 bis 9223372036854775808 (an einem der Enden um 1 weniger), also bis zu 19 Ziffern.

15 Ziffern wären sehr ungewöhnlich.

Dein RX/TX hat jeweils 12 Ziffern.

cu,
Andreas a/k/a MudGuard

[Verwirrnix]

Hm. An den AddOns liegt es nicht. Gerade getestet. An den Zahlen auch nicht. Ich habe gerade eben mal auf dem home-server die Zahlen fpr RX und TX soweit erhöht, dass diese noch etwas größer als auf dem Webserver sind. Der Fehler tritt dann nicht auf.

Bleibt Dein:

das deutet auf ein Timing-Problem hin

Allerdings habe ich es auch mit einem Socks-Proxy im Web versucht, der die Ladezeit vom Home-Server verlängern sollte. Da trat das Problem dann aber trotzdem nicht auf…

Die Requests auf syncron oder asynchron zu setzen ändert auch nichts...

Ich bin ratlos.

[Gunnar Bittersmann]

@@MudGuard

(an einem der Enden um 1 weniger, kann mir nie merken, an welchem)

Protip: Versuche gar nicht erst dir zu merken, was du dir einfach herleiten kannst.

Bei signed integer ist das höchtswertige Bit das Vorzeichen.

Nehmen wir der Einfachheit halber mal 8 Bit (mit großen Zahlen wird das nicht besser):
00000000 ist 0
00000001 ist 1
00000010 ist 2
⋮
Höchstwertiges Bit 0 haben also 0 und die positiven Zahlen – bis
01111111 = 2⁷ − 1 = 127

10000000 ist eine negative Zahl: −2⁷ = −128
10000001 ist −127
⋮
11111111 ist −1

Der Bereich für signed integer geht bei 8 Bit demnach von −128 bis 127.

Oder anders:
Höchstwertiges Bit 0 haben 0 und die positiven Zahlen. Höchstwertiges Bit 1 haben die negativen Zahlen.

Da es genausoviele Bitfolgen mit höchstwertigem Bit 0 wie Bitfolgen mit höchstwertigem Bit 1 gibt, gibt es im darstellbaren Bereich wegen der 0 eine positive Zahl weniger als es negative Zahlen gibt.

LLAP 🖖

[Verwirrnix]

das deutet auf ein Timing-Problem hin - mit Entwicklertool ist's langsamer, weil die Debug-Sachen ermittelt werden.

Danke, das war (ist) richtig. Dann will ich mal den Code aufräumen und das Problem beseitigen. Danach stimmt aber die URL nicht mehr.

[Regina Schaukrug]

das deutet auf ein Timing-Problem hin - mit Entwicklertool ist's langsamer, weil die Debug-Sachen ermittelt werden.

Danke, das war (ist) richtig.

Durch intensives Debuggen erkannt: Wenn sich zwei dieser "XmlHttpRequest" (auf die selbe Ressource?) überkreuzen dann liefert der zweite bei allen oder einigen Browsern einfach einen leeren .responceText zurück.

Setzt aber brav this.readyState auf 4 und this.status auf 200…

Ich denke, genau das sollte so nicht stattfinden.

[asdf]

Durch intensives Debuggen erkannt: Wenn sich zwei dieser "XmlHttpRequest" (auf die selbe Ressource?) überkreuzen dann liefert der zweite bei allen oder einigen Browsern einfach einen leeren .responceText zurück. Setzt aber brav this.readyState auf 4 und this.status auf 200…

Ich denke, genau das sollte so nicht stattfinden.

Ich denke, das ist abhängig vom Inhalt der tatsächlichen Response.

[Verwirrnix]

Durch intensives Debuggen erkannt: Wenn sich zwei dieser "XmlHttpRequest" (auf die selbe Ressource?) überkreuzen dann liefert der zweite bei allen oder einigen Browsern einfach einen leeren .responceText zurück. Setzt aber brav this.readyState auf 4 und this.status auf 200…

Ich denke, genau das sollte so nicht stattfinden.

Ich denke, das ist abhängig vom Inhalt der tatsächlichen Response.

Ein definitiv nicht-leerer String. Enthält JSON. Soll die nächsten Werte für den Ticker liefern. Ich hab Einiges (sehr viel) umgestellt. Das Zeug läuft jetzt und konfiguriert sich auch selbst auf sinnvolle Werte (z.B. Netzwerkkarte mit dem höchsten Traffik). Ich habe den Netzwerk-Ticker veröffentlicht.

Danke an alle, die geholfen haben.