Aggiornamenti SQ X

Qui è possibile discutere gli aggiornamenti e le novità di SQ X.

Questo argomento è stato rinominato da SQ4 Early preview. I vecchi post non più rilevanti sono o saranno cancellati e archiviati.

Il punto è ripulire il nostro forum da cose vecchie e non pertinenti.

Mark, grazie per la tua risposta. Attendo con ansia la build 118.

Sono assolutamente d'accordo sul fatto che l'intervallo di aggiornamento sia una volta al mese per testare tutto correttamente.

Ciao Mark,

Capisco quello che dici, tuttavia, dato lo stadio ancora "un po'" buggato di SQX, penso che sia meglio mantenere un ciclo di rilascio rapido. Innanzitutto perché in questo modo si riducono le segnalazioni di bug duplicati relativi allo stesso problema - le probabilità che diverse persone segnalino gli stessi problemi sono più alte con un programma di rilascio più lungo. In secondo luogo, spesso i bug segnalati in questo momento sono di natura cruciale per molti utenti. Prima avevano la possibilità di risolverli aspettando al massimo 2 settimane, ora un mese: a mio parere è troppo tempo.

Sono pienamente d'accordo sul rallentare le cose una volta che SQX sarà più stabile, tuttavia, in questo momento non è così e anche le cose di base sono ancora rotte. Nessuno si aspetta un aggiornamento perfetto per tutte e 4 le settimane, visto lo stato attuale del software. Al contrario, le persone sono alla ricerca di correzioni rapide dei bug in questo momento. Sono d'accordo sul fatto di mantenerlo "rapido" per ora con rilasci di 2 settimane e di eliminare i bug il più rapidamente possibile. Una volta che le cose si saranno sistemate e saranno più stabili, 4 settimane andranno sicuramente bene, dato che i bug segnalati non saranno più così cruciali come lo sono ora.

Solo i miei due centesimi.

Un'alternativa a un ciclo di rilascio più lungo di 4 settimane sarebbe quella di ridurre l'ambito e attenersi al ciclo di 2 settimane. Questo lo renderebbe più fattibile per il team di sviluppo. Permette anche un ciclo di feedback più rapido, quindi i bug importanti saranno risolti più velocemente. Oltre a questo, ha anche i vantaggi già menzionati da geektrader. Solo i miei due centesimi...

I miei 2 centesimi: il ciclo di 2 settimane non funziona. Meglio 4 settimane e meno insetti

I miei 2 centesimi: Sono d'accordo con Geektrader, sono contento del ciclo di 2 settimane mentre ci sono molti bug da risolvere, anche se il numero di bug risolti è minore.

... I miei 2 centesimi... basati sulla mia esperienza di PM di sviluppo software:

- Bug piccoli, facili, con un impatto minimo in termini di test e di rischio - Ciclo di rilascio (minore) di 2 settimane.

- Bug di grandi dimensioni, più complicati, più testati e a più alto rischio di impatto - ciclo di rilascio di 4 settimane (minore).

Quanto sopra si basa sull'assenza di nuove funzionalità in SQX fino a quando SQX non avrà almeno le funzionalità e le offerte equivalenti di SQ3.x.x e EA Wizard (Algo Wizard in SQX).

In questo modo si garantirebbe la trasparenza e la fiducia di tutta la comunità dei clienti nell'approccio a un prodotto software robusto, affidabile e di qualità che "fa quello che c'è scritto sulla scatola".

Sono anche d'accordo con geektrader, attenetevi al ciclo di 2 settimane per i prossimi due mesi e fate in modo che la correzione dei bug esistenti sia una priorità, quando scendono a un livello accettabile passate a un ciclo di rilascio più lungo e poi iniziate ad aggiungere nuove funzionalità.

abbiamo fatto un compromesso per ora - B118 sarà rilasciato tra 3 settimane - il prossimo venerdì (25.2.)

Ho una richiesta - Alcuni utenti hanno segnalato problemi di memoria nella B117, ma non sono in grado di riprodurli. Non rileviamo alcuna perdita di memoria nella Build 117.
Nei miei test SQ X funziona senza problemi con 8 GB di RAM, funziona per giorni senza esaurire la memoria. Ho provato tutte le impostazioni che mi sono state inviate.

Se alcuni di voi riscontrano ancora problemi di memoria - nel senso che SQ consuma tutta la memoria e produce un messaggio di errore dopo un'esecuzione prolungata - vi preghiamo di aprire un bug ticket e di allegare la vostra configurazione.

Si noti che il problema della memoria NON si verifica se si assegna semplicemente troppa poca memoria a SQ: se SQ utilizza solo 4 GB, o se si utilizza qualcosa di complicato in Retester e il problema si risolve aumentando la memoria disponibile, allora non è un problema.

Il problema si presenta solo se la memoria continua a crescere costantemente quando SQ funziona a lungo.

C'è qualche progetto futuro per integrare Quant Analyzer in SQX?

come è stato fatto con EA wizard e Tickdata downloader.

Ciao Marc,

La build 118 sarà rilasciata oggi?

Mi dispiace, ma oggi non rilasceremo la build 118. All'ultimo momento abbiamo finalmente trovato e riprodotto il motivo di alcune perdite di memoria, che si verificano solo in circostanze particolari, e lo stiamo risolvendo.

La build 118 sarà rilasciata lunedì o martedì della prossima settimana.

Partizanas - Sì, le funzionalità di QA saranno integrate in SQ X, e le aggiungeremo continuamente nelle prossime versioni.

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

Anch'io uso OVO e lo uso con SQX, testare a livello di tick sarebbe una bella opzione!

A mio avviso, in questo caso SQX dovrebbe essere in grado di importare i file hst MT4 generati da OVO Renko Builder.

DalFX ha scritto:

@keinc301, c'è un compito per questo? Io voterei per questo! Anch'io uso OVO e lo uso con SQX, per testare a livello di tick sarebbe una bella opzione! Come vedo in questo caso SQX dovrebbe essere in grado di importare i file hst MT4 generati da OVO Renko Builder.

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

E' nella sezione "da fare più tardi". Spero solo che ora sia più tardi 🙂

I dati tick by tick sono l'unico modo per testare accuratamente renkos. È lento, ma altri metodi possono incasinare drasticamente i test. Per questo motivo la risoluzione dei tick su renkos è stata davvero importante per me. La maggior parte degli ea basati su renkos fallisce perché i dati non possono essere elaborati con precisione.

Con ancora così tanti bug anche nella funzionalità esistente (avete dato un'occhiata al sito del bug tracker??), questo non è un buon momento per permettere loro di aggiungere qualcosa di così complicato. Onestamente, significherebbe solo un maggiore disordine di tutto. Anch'io ho molte idee, ma non le ho ancora aggiunte tutte al tracker, semplicemente perché prima le basi devono funzionare PERFETTAMENTE - non solo bene, ma PERFETTAMENTE, stiamo scambiando soldi veri qui. Perciò, come tutti noi, date loro tregua e aspettate con le richieste di nuove funzionalità e concentratevi invece sulla segnalazione di bug sulle funzionalità esistenti che non funzionano.