Mises à jour du SQ X

C'est ici que nous pouvons discuter des mises à jour et des nouvelles de SQ X.

Ce sujet a été renommé de SQ4 Early preview. Les anciens messages, qui ne sont plus pertinents, sont ou seront supprimés et archivés.

Il s'agit de nettoyer notre forum des vieilles choses non pertinentes.

Mark, merci pour votre réponse. J'attends avec impatience la version 118.

Je suis tout à fait d'accord pour que l'intervalle entre les mises à jour soit d'une fois par mois afin de tout tester correctement.

Bonjour Mark,

Je comprends ce que vous dites, cependant, étant donné le stade encore "quelque peu" bogué de SQX, je pense qu'il est préférable de conserver un cycle de publication rapide. Tout d'abord parce que cela réduit le nombre de rapports de bogues en double concernant le même problème - avec un calendrier de publication plus long, il y a plus de chances que plusieurs personnes signalent les mêmes problèmes. Deuxièmement, les bogues signalés en ce moment sont souvent d'une importance cruciale pour de nombreux utilisateurs. Auparavant, ils avaient la possibilité de les faire corriger en attendant un maximum de 2 semaines, maintenant c'est un mois, c'est trop long à mon avis.

Je suis tout à fait d'accord pour ralentir les choses une fois que SQX sera plus stable, mais pour l'instant ce n'est pas le cas et même des choses basiques sont encore cassées. Personne ne s'attend à une mise à jour parfaite toutes les 4 semaines étant donné l'état actuel du logiciel. Au lieu de cela, les gens recherchent des corrections de bugs rapides en ce moment. Je suis d'accord pour rester "rapide" pour l'instant avec des versions de 2 semaines et pour éliminer les bugs aussi vite que possible. Une fois que les choses se seront stabilisées, 4 semaines suffiront, car les bugs signalés ne seront plus aussi cruciaux qu'aujourd'hui.

Ce n'est que mon avis.

Une alternative à un cycle de publication plus long de 4 semaines serait de réduire le champ d'application et de s'en tenir au cycle de 2 semaines. Cela serait plus facile pour l'équipe de développement. Cela permet également un cycle de retour d'information plus rapide, de sorte que les bogues importants seront corrigés plus rapidement. A part cela, il y a aussi les avantages que geektrader a déjà mentionnés. Ce n'est que mon avis...

Mon point de vue : un cycle de 2 semaines ne fonctionne pas. Mieux vaut 4 semaines et moins d'insectes

Mes 2 cents : D'accord avec Geektrader, satisfait du cycle de 2 semaines alors qu'il y a beaucoup de bugs à corriger, même si le nombre de bugs corrigés est plus petit.

...Mes 2 cents...basés sur mon expérience de PM en développement de logiciels :

- Petits bogues, faciles, avec un minimum d'impact sur les tests et les risques - cycle de publication (mineure) de 2 semaines.

- Bugs importants, plus compliqués, tests plus poussés et risque d'impact plus élevé - cycle de publication de 4 semaines (mineures).

Ce qui précède est basé sur l'absence de nouvelles fonctionnalités dans SQX jusqu'à ce que SQX ait au moins des fonctionnalités et des offres équivalentes à SQ3.x.x et EA Wizard (Algo Wizard dans SQX).

Cela permettrait d'assurer la transparence et de susciter la confiance de l'ensemble de la communauté des clients dans l'approche visant à obtenir un produit logiciel robuste, fiable et de qualité qui "fait ce qu'il dit sur la boîte".

Je suis également d'accord avec geektrader, il faut s'en tenir au cycle de 2 semaines pour les deux prochains mois et faire de la correction des bogues existants une priorité, lorsqu'ils auront atteint un niveau acceptable, il faudra passer à un cycle de publication plus long et commencer à ajouter de nouvelles fonctionnalités.

nous avons fait un compromis pour l'instant - B118 sera publié dans 3 semaines - vendredi prochain (25.2.)

J'ai une demande à formuler - certains utilisateurs ont signalé des problèmes de mémoire dans la version B117, mais je ne suis pas en mesure de les reproduire. Nous ne détectons aucune fuite de mémoire dans la Build 117.
Dans mes tests, SQ X fonctionne avec 8 Go de RAM sans aucun problème, il tourne pendant des jours sans épuiser la mémoire. J'ai essayé tous les paramètres qui m'ont été envoyés.

Si certains d'entre vous rencontrent encore des problèmes de mémoire - c'est-à-dire que SQ consomme toute la mémoire et produit un message d'erreur après une longue exécution - veuillez ouvrir un ticket de bogue et y joindre votre configuration.

Veuillez noter que le problème de mémoire n'est PAS dû au fait que vous allouez simplement trop peu de mémoire à SQ - si SQ n'utilise que 4 Go, ou si vous utilisez quelque chose de compliqué dans Retester et que le problème est résolu en augmentant la mémoire disponible, il ne s'agit pas d'un problème.

Le problème ne se pose que si la mémoire continue de croître constamment lorsque la SQ fonctionne pendant une longue période.

Est-il prévu d'intégrer Quant Analyzer dans SQX ?

comment cela a été fait avec EA wizard et Tickdata downloader.

Bonjour Marc,

La Build 118 sera-t-elle publiée aujourd'hui ?

Je suis désolé, nous ne publierons pas la version 118 aujourd'hui. Au dernier moment, nous avons finalement trouvé et reproduit la raison de certaines fuites de mémoire - cela ne se produit que dans des circonstances particulières - et nous sommes en train de la corriger.

La version 118 sera publiée lundi ou mardi de la semaine prochaine.

Partizanas - Oui, les fonctionnalités de QA seront intégrées dans SQ X, nous les ajouterons continuellement dans les prochaines versions.

@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!

Je suis également utilisateur d'OVO et je l'utilise avec SQX, tester au niveau du tick serait une option intéressante !

Dans ce cas, SQX devrait pouvoir importer les fichiers MT4 hst générés par OVO Renko Builder.

DalFX a écrit :

@keinc301Y a-t-il une tâche à accomplir ? Je voterais en sa faveur ! Je suis également utilisateur d'OVO et je l'utilise avec SQX, tester au niveau du tick serait une option intéressante ! Dans ce cas, SQX devrait pouvoir importer les fichiers MT4 hst générés par OVO Renko Builder.

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

C'est dans la section "à faire plus tard". J'espère juste que c'est maintenant que ça se fera plus tard 🙂 .

Les données tic-tac par tic-tac sont le seul moyen de tester renkos avec précision. C'est lent, mais d'autres méthodes peuvent perturber les tests de façon spectaculaire. C'est pourquoi il est très important pour moi d'avoir une option pour la résolution des tick sur renkos. La plupart des ea basés sur renkos échouent parce que les données ne peuvent pas être traitées avec précision.

Avec encore tant de bugs même dans la fonctionnalité existante (avez-vous jeté un coup d'œil au site de suivi des bugs ??), ce n'est pas le bon moment pour les laisser ajouter quelque chose d'aussi compliqué que cela. Honnêtement, cela ne ferait qu'aggraver le désordre. J'ai aussi beaucoup d'idées, mais je ne les ai pas encore toutes ajoutées au tracker, simplement parce qu'il faut d'abord que les bases fonctionnent PARFAITEMENT - pas seulement bien, mais PARFAITEMENT, nous sommes en train d'échanger de l'argent réel ici. Alors, donnez-leur une pause et attendez, comme nous tous, avec les demandes de nouvelles fonctionnalités et concentrez-vous plutôt sur le signalement des bogues sur les fonctionnalités existantes qui sont cassées.