Atualizações do SQ X

Aqui é onde podemos discutir as atualizações do SQ X e as notícias.

Este tópico foi renomeado de SQ4 Early preview. Os posts antigos, não mais relevantes, são ou serão apagados e arquivados.

A questão está em limpar nosso fórum de coisas antigas e não relevantes.

Mark, obrigado por sua resposta. Aguardamos ansiosamente a compilação 118.

Concordo plenamente que o intervalo entre as atualizações seja de uma vez por mês para testar tudo corretamente.

Olá Mark,

Entendo o que você está dizendo, no entanto, dado o estágio ainda "um pouco" cheio de bugs do SQX, acho que é melhor manter um ciclo de lançamento rápido. Primeiro, porque isso reduz a duplicação de relatórios de bugs sobre o mesmo problema - as chances de várias pessoas relatarem os mesmos problemas são maiores com um cronograma de lançamento mais longo. Em segundo lugar, muitas vezes os bugs que são relatados agora são de natureza crucial para muitos usuários. Anteriormente, eles tinham a chance de corrigi-los esperando no máximo duas semanas, agora é um mês, o que é muito tempo na minha opinião.

Concordo plenamente em desacelerar as coisas quando o SQX estiver mais estável, mas, no momento, esse não é o caso e até mesmo coisas básicas ainda estão quebradas. Ninguém está esperando uma atualização perfeita em todas as quatro semanas, considerando o estágio atual do software. Em vez disso, as pessoas estão procurando correções rápidas de bugs no momento. Sou totalmente a favor de manter o ritmo "rápido" por enquanto, com lançamentos de duas semanas e correção de bugs o mais rápido possível. Quando as coisas se estabilizarem e ficarem mais estáveis, 4 semanas serão suficientes, pois os bugs relatados não serão mais tão cruciais quanto são agora.

Apenas meus dois centavos.

Uma alternativa para um ciclo de lançamento mais longo, de quatro semanas, seria diminuir o escopo e manter o ciclo de duas semanas. Isso tornaria o processo mais viável para a equipe de desenvolvimento. Isso também permite um ciclo de feedback mais rápido, de modo que os bugs importantes serão corrigidos mais rapidamente. Além disso, também tem as vantagens que o geektrader já mencionou. Apenas meus dois centavos...

Meus dois centavos: o ciclo de duas semanas não funciona. Melhor 4 semanas e menos bugs

Meus dois centavos: Concordo com Geektrader, feliz com o ciclo de 2 semanas, enquanto há muitos bugs para corrigir, mesmo que o número de bugs corrigidos seja menor.

... Meus dois centavos... com base em minha experiência de PM em desenvolvimento de software:

- Bugs pequenos, fáceis, com impacto mínimo nos testes e nos riscos - ciclo de lançamento de 2 semanas (menor).

- Bugs grandes, mais complicados, com mais testes e maior impacto de risco - ciclo de lançamento de 4 semanas (menor).

Acima, com base na ausência de novos recursos no SQX até que o SQX tenha, no mínimo, os recursos e ofertas equivalentes do SQ3.x.x e do EA Wizard (Algo Wizard no SQX).

Isso proporcionaria transparência e geraria confiança em toda a comunidade da base de clientes na abordagem de ter um produto de software robusto, confiável e de qualidade que "faz o que está escrito na caixa".

Também concordo com o geektrader, mantenha o ciclo de duas semanas nos próximos meses e priorize a correção dos bugs existentes. Quando eles caírem para um nível aceitável, passe para um ciclo de lançamento mais longo e comece a adicionar novos recursos

Fizemos um acordo por enquanto - o B118 será lançado em 3 semanas - na próxima sexta-feira (25.2).

Tenho uma solicitação - Alguns usuários relataram problemas de memória no B117, mas não consegui reproduzi-los. Não detectamos nenhum vazamento de memória no Build 117.
Em meus testes, o SQ X funciona com 8 GB de RAM sem nenhum problema e funciona por dias sem esgotar a memória. Tentei todas as configurações que me foram enviadas.

Se alguns de vocês ainda tiverem problemas de memória - o que significa que o SQ consumirá toda a memória e produzirá uma mensagem de erro após uma longa execução -, abra um tíquete de bug e anexe sua configuração a ele.

Observe que o problema de memória NÃO é se você simplesmente alocar pouca memória para o SQ - se o SQ usar apenas 4 GB, ou se você usar algo complicado no Retester e isso for corrigido com o aumento da memória disponível, então isso não é um problema.

O problema ocorre somente se a memória continuar crescendo constantemente quando o SQ for executado por um longo período.

Há algum plano futuro para integrar o Quant Analyzer ao SQX?

como isso foi feito com o EA wizard e o downloader do Tickdata.

Oi Marc,

O Build 118 será lançado hoje?

Desculpe-me, mas não lançaremos a versão 118 hoje. No último momento, finalmente encontramos e reproduzimos o motivo de alguns vazamentos de memória - isso acontece apenas em circunstâncias especiais - e estamos corrigindo o problema.

A compilação 118 será lançada na segunda ou terça-feira da próxima semana.

Partizanas - Sim, a funcionalidade de QA será integrada ao SQ X, e a adicionaremos continuamente nas próximas versões.

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

Também sou usuário do OVO e o utilizo com a SQX. Seria uma boa opção testar no nível do tick!

Pelo que vejo, nesse caso, o SQX deve ser capaz de importar arquivos hst MT4 gerados pelo OVO Renko Builder.

DalFX escreveu:

@keinc301Há alguma tarefa para isso? Eu daria meu voto a ela! Também sou usuário do OVO e usá-lo com o SQX, para testar no nível de tick seria uma boa opção! Pelo que vejo, nesse caso, o SQX deve ser capaz de importar arquivos hst MT4 gerados pelo OVO Renko Builder.

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

Está na seção a ser feita mais tarde. Só espero que agora seja mais tarde 🙂

E os dados tick a tick são a única maneira de testar o renkos com precisão. É lento, mas outros métodos podem atrapalhar drasticamente os testes. Portanto, é muito importante que eu tenha uma opção para renderizar a resolução de ticks no renkos. A maioria dos EAs baseados no renkos falha porque os dados não podem ser processados com precisão.

Com tantos bugs até mesmo na funcionalidade existente (você deu uma olhada no site do rastreador de bugs??), este não é um bom momento para permitir que eles adicionem algo tão complicado como isso. Sinceramente, isso significa apenas uma bagunça maior de tudo. Eu também tenho muitas ideias, mas ainda não adicionei todas elas ao rastreador, simplesmente porque primeiro o básico precisa funcionar PERFEITAMENTE - não apenas bem, mas PERFEITO, pois estamos negociando dinheiro de verdade aqui. Portanto, dê-lhes um tempo e espere, como todos nós, com as solicitações de novos recursos e, em vez disso, concentre-se em relatar bugs sobre a funcionalidade existente que está quebrada.