SQ X Aktualisierungen

Hier können wir über SQ X Updates und Neuigkeiten diskutieren.

Dieses Thema wurde umbenannt von SQ4 Early preview. Die alten, nicht mehr relevanten Beiträge sind oder werden gelöscht und archiviert.

Es geht darum, unser Forum von altem, nicht relevantem Zeug zu befreien.

Mark, danke für deine Antwort. Ich freue mich auf Build 118.

Ich stimme voll und ganz zu, dass die Aktualisierungsintervalle einmal im Monat sein sollten, um alles richtig zu testen.

Hallo Mark,

Ich verstehe, was Sie sagen, aber in Anbetracht des immer noch "etwas" fehlerhaften Stadiums von SQX, denke ich, dass es besser ist, einen schnellen Veröffentlichungszyklus beizubehalten. Erstens, weil dadurch die Anzahl der doppelten Fehlerberichte zum gleichen Problem verringert wird - die Wahrscheinlichkeit, dass mehrere Leute die gleichen Probleme melden, ist bei einem längeren Veröffentlichungszeitplan höher. Zweitens sind die Fehler, die jetzt gemeldet werden, oft von entscheidender Bedeutung für viele Benutzer. Früher hatten sie die Chance, sie zu beheben, indem sie maximal 2 Wochen warten mussten, jetzt ist es ein Monat, das ist meiner Meinung nach zu lang.

Ich stimme voll und ganz zu, die Dinge zu verlangsamen, sobald SQX stabiler ist, aber im Moment ist das nicht der Fall und selbst grundlegende Dinge sind immer noch fehlerhaft. Niemand erwartet ein perfektes Update alle 4 Wochen, wenn man den aktuellen Stand der Software bedenkt. Stattdessen suchen die Leute jetzt nach schnellen Fehlerbehebungen. Ich bin dafür, dass wir es vorerst bei 2-wöchigen Veröffentlichungen belassen und die Fehler so schnell wie möglich ausbügeln. Wenn sich die Dinge erst einmal eingependelt haben und stabiler sind, sind 4 Wochen sicher in Ordnung, da die gemeldeten Fehler nicht mehr so entscheidend sein werden wie jetzt.

Nur meine 2 Cents.

Eine Alternative zu einem längeren 4-wöchigen Veröffentlichungszyklus wäre eine Verkleinerung des Umfangs und die Beibehaltung des 2-Wochen-Zyklus. Das würde es für das Entwicklungsteam praktikabler machen. Es ermöglicht auch einen schnelleren Feedback-Zyklus, so dass die wichtigen Fehler schneller behoben werden. Abgesehen davon hat es auch die Vorteile, die geektrader bereits erwähnt hat. Nur meine 2 Cents ...

meine 2 Cent : 2 Wochen Zyklus funktioniert nicht . Besser 4 Wochen und weniger Bugs

Meine 2 Cents: Stimme mit Geektrader überein, bin zufrieden mit dem 2-Wochen-Zyklus, auch wenn die Anzahl der behobenen Fehler geringer ist.

...Meine 2 Cents...basierend auf meiner Erfahrung als Softwareentwicklungs-PM:

- Kleine, einfache Bugs mit minimalen Test- und Risikoauswirkungen - 2-wöchiger (kleiner) Veröffentlichungszyklus.

- Große, komplizierte, umfangreichere Tests und risikoreichere Fehler - 4-wöchiger (kleiner) Veröffentlichungszyklus.

Die obigen Ausführungen basieren auf der Annahme, dass es keine neuen Funktionen in SQX geben wird, bis SQX mindestens die gleichen Funktionen und Angebote wie SQ3.x.x und EA Wizard (Algo Wizard in SQX) aufweist.

Dies würde für Transparenz sorgen und in der gesamten Kundengemeinschaft Vertrauen in das Konzept eines robusten, zuverlässigen und qualitativ hochwertigen Softwareprodukts schaffen, das "hält, was es auf der Verpackung verspricht".

Außerdem muss ich geektrader zustimmen: Bleiben Sie in den nächsten Monaten bei dem 2-Wochen-Zyklus und machen Sie die Behebung der vorhandenen Bugs zur Priorität, wenn sie auf ein akzeptables Niveau sinken, wechseln Sie zu einem längeren Veröffentlichungszyklus und fangen Sie dann an, neue Funktionen hinzuzufügen

wir haben vorerst einen Kompromiss gefunden - B118 wird in 3 Wochen veröffentlicht - nächsten Freitag (25.2.)

Ich habe eine Bitte - Einige Benutzer haben von Speicherproblemen in B117 berichtet, aber ich kann sie nicht reproduzieren. Wir haben in Build 117 kein Speicherleck entdeckt.
In meinen Tests arbeitet SQ X mit 8 GB RAM ohne Probleme, es läuft tagelang, ohne den Speicher zu erschöpfen. Ich habe jede Einstellung ausprobiert, die mir zugeschickt wurde.

Wenn einige von euch immer noch Probleme mit dem Speicher haben - was bedeutet, dass SQ den gesamten Speicher verbraucht und nach einem langen Lauf eine Fehlermeldung ausgibt -, öffnet bitte ein Bug-Ticket und fügt eure Konfiguration dort ein.

Bitte beachten Sie, dass das Speicherproblem NICHT darin besteht, dass Sie SQ einfach zu wenig Speicher zuweisen - wenn SQ nur 4 GB verwendet oder wenn Sie etwas Kompliziertes in Retester verwenden und das Problem durch eine Erhöhung des verfügbaren Speichers behoben wird, dann ist dies kein Problem.

Das Problem tritt nur auf, wenn der Speicher ständig wächst, wenn SQ lange Zeit läuft.

Gibt es Pläne für die Integration von Quant Analyzer in SQX?

wie das mit dem EA-Assistenten und dem Tickdata-Downloader gemacht wurde.

Hallo Marc,

wird Build 118 heute veröffentlicht?

Es tut mir leid, wir werden Build 118 heute nicht veröffentlichen. Im letzten Moment haben wir endlich den Grund für einige Speicherlecks gefunden und reproduziert - es passiert nur unter besonderen Umständen - und wir beheben es.

Build 118 wird am Montag oder Dienstag nächster Woche veröffentlicht.

Partizanen - Ja, die Funktionalität von QA wird in SQ X integriert werden, wir werden sie in den nächsten Builds kontinuierlich hinzufügen.

@Mark, since we’re moving to updates in 4 week intervals, is there any chance we can see OVO Renko support with tick by tick testing in Build 119 now that custom timeframes are possible?

@keinc301, is there task for it ? I would put my vote to it!

Ich benutze auch OVO und verwende es mit SQX, um auf Tick-Ebene zu testen, wäre eine gute Option!

Wie ich sehe, sollte SQX in diesem Fall in der Lage sein, von OVO Renko Builder generierte hst MT4-Dateien zu importieren.

DalFX schrieb:

@keinc301Gibt es eine Aufgabe dafür? Ich würde meine Stimme dafür abgeben! Ich bin Benutzer von OVO als auch und mit ihm mit SQX, um auf Tick-Ebene zu testen, wäre schön Option! Wie ich sehe, in diesem Fall SQX sollte in der Lage sein, hst MT4-Dateien von OVO Renko Builder generiert importieren.

https://roadmap.strategyquant.com/tasks/sq4_0991

Es steht in der Rubrik "Später zu erledigen". Ich hoffe nur, dass jetzt später ist 🙂 .

Und Tick-by-Tick-Daten sind die einzige Möglichkeit, Renkos genau zu testen. Es ist langsam, aber andere Methoden können Tests dramatisch durcheinander bringen. So Rendering Tick Auflösung auf Renkos wurde wirklich wichtig für mich, eine Option für haben. Die meisten Ea's, die auf Renkos basieren, scheitern, weil die Daten nicht genau verarbeitet werden können.

Bei so vielen Fehlern in der bestehenden Funktionalität (haben Sie einen Blick auf die Bug-Tracker-Seite geworfen??) ist dies kein guter Zeitpunkt, um etwas so Kompliziertes wie dieses hinzuzufügen. Das bedeutet nur ein noch größeres Durcheinander, ehrlich gesagt. Ich habe auch so viele Ideen, aber ich habe sie noch nicht alle in den Tracker eingetragen, einfach weil zuerst die Grundlagen PERFEKT funktionieren müssen - nicht nur gut, sondern PERFEKT, wir handeln hier mit echtem Geld. Also gönnen Sie ihnen eine Pause und warten Sie, wie wir alle, mit neuen Funktionswünschen und konzentrieren Sie sich stattdessen auf die Meldung von Fehlern bei bestehenden Funktionen, die nicht funktionieren.