Suggestions d'améliorations pour prorealtime

[tontondubled]

chouette

merci de l'info

[Blia]

J'ai remarqué que les "Espaces de travail" n'enregistrent pas dans le cloud la taille de la police de caractères.
C'est gênant..

J'utilise deux PC différents, l'un avec un écran 4K, l'autre non. Quand j'ai lancé prt sur mon deuxième PC, il a chargé le dernier espace de travail utilisé (celui de l'écran 4K), c'est normal. Mais quand j'ai chargé mon espace de travail spécial "petit écran", il a semble t-il repositionné les fenêtres mais la police de caractères est celle utilisée sur mon écran 4K.

Je ne sais pas si je suis clair mais en tous cas, il y a un problème à ce niveau.

[Benoist Rousseau]

solution : Tu enregistres deux sessions distinctes, une pour ton pc hd une pour ton pc 4K c'est ce que je fais j'ai des config pour chaque pc et pc portable selon leur résolution, leur nombre d'écrans etc

[Blia]

Benoist : Qu'entends tu par des "sessions différentes" ? Des sessions Windows ?

- : merci pour le lien. Content de voir que tu aimes aussi ce genre de fonctionnalité. C'est pourquoi j'aimerais que ce soit disponible directement dans prt

[Benoist Rousseau]

non de multiples sessions prorealtime tu peux en sauvegarder autant que tu veux 1 par pc

cela règle tes problème de couleurs, d'écrans, de positions etc

j'ai 6 config différentes en tout sur le cloud, j'appelle la bonne selon le pc

[Blia]

Ces sessions sont présentes dans la version Complète ou juste dans la Premium ?
Car je ne vois aucun gestionnaire de session dans la Complète.

[Benoist Rousseau]

Je n’ai que la version premium. Je ne sais pas pour la version Light. J’ai un nombre de configurations illimités et je peux switcher de l’une à l’autre via les touches Fx. Utile pour une configuration matin après midi ou volatilité faible volatilité par exemple sur le même pc

Si tu ne l’as pas sur la complete tu ne l’auras jamais. prt donne la premium qu’à ses clients.

[Blia]

Dès que j'ai découvert PRT, je me suis demandé pourquoi ils avaient opté pour Java plutôt que C++. Sauf erreur de ma part, Java est plus lent que C++ (c'est ce que je lis depuis toujours). Certes, l'avantage de Java c'est sa portabilité mais il serait ~ 2.5 fois plus lent que le C++ dans l'exécution des applications.

Alors, je m'interroge, au tout début, les développeurs de PRT ont-ils choisi Java en estimant que la portabilité prévalait sur la rapidité ? Pourtant, si le scalping requiert une bonne machine, il en va de même pour l'application de trading, non ?

Savez vous s'ils prévoient (un jour ou l'autre) de porter leur application dans un autre langage ?

[Benoist Rousseau]

J'ai passé des A/R en moins de 100 ms on ne peut pas faire plus rapide c'est Eurex qui est le plus lent en bout de chaine avec ses ordinateurs quand tu vois le détail de la transmission ^^ Un autre exemple, prt a une infrastructure > à la bourse italienne en terme technique. Quand il y a eu la grosse journée de volatilité il y a quelques semaines prt n'a eu aucun ralentissement en diffusant les cours de dizaines de places boursières et dizaines de milliers d'actions dans le monde simultanément. La bourse de Milan était saturée et envoyait les cours avec un retard de plusieurs minutes et beaucoup de brokers étaient OUT ^^ Il y a une qualité derrière que tu n'imagines pas, data center dédiés, des centaines de machines optimisées etc Tu le vois rien qu'avec ig prt a plus de tick qu'ig lui même faut-il-trader-avec-prorealtime-ou-la-v ... 14544.html

Oui il y aura des évolutions cela fait 17 ans qu'ils évoluent mais ça reste top secret

[takapoto]

L’avantage de Java est sa portabilité.
Son code est auto-compilé sur l’OS cible et est aussi efficace que du C.

Le vrai problème de Java est sa gestion de la mémoire, ce qui le fait paraître plus lent que du C quand les tests sont effectués sur la même machine.

En effet, Java ne permet pas de libérer manuellement la mémoire qu’il utilise.
Sous Java, la mémoire est libérée quand nécessaire par un système automatique alors qu’un programmeur C la libère quand il veut (s’il n’oublie pas).

Java a donc simplement besoin de plus de mémoire que le C pour produire le même résultat.

La solution, pour obtenir avec Java des performances équivalentes au C, est d’avoir plus de mémoire sur sa machine.

C’est ce que fait Benoist.

[Benoist Rousseau]

Ils ont fait le choix il y a 17 ans. Vous auriez fait quel choix en 2001 en vous remettant en situation ?

[Blia]

OK à l'époque peut-être, mais depuis, de l'eau a coulé sous les ponts. 17 ans c'est une éternité en informatique. Ils "pourraient" prévoir de porter leur application phare (ce n'est qu'une interrogation de ma part, je sais que le portage d'application prend du temps et de l'argent), surtout avec l'engouement pour le micro-scalping.

[takapoto]

Blia, tu devrais faire équipe avec BearIsDead qui veut réécrire facebook en trois mois, et peut-être que d'ici l'été, on aurait un magnifique prt réécrit avec la dernière technologie à la mode

[Benoist Rousseau]

Je pensais avoir été clair. C’est prévu Blia mais je ne peux pas en dire plus pour des raisons évidentes.

[Blia]

Ah désolé, j'ai le cerveau mou ce matin (ou sûrement tout le temps ) , j'avais pas compris.
takapoto : réécrire facebook. lol.

[Blia]

On est d'accord là-dessus.

[Djobydjoba]

Un certain nombre de modules des terminaux Bloomberg sont encore en Cobol/Fortan. Une tannée à maintenir, car il faut trouver les compétences sur ces vieux langages.
Edit : enfin, apparemment la migration vers C++/ javascript a été faite.

[takapoto]

Je verrais bien la nouvelle version de prt développée avec le couple TypeScript/Angular...

[Blia]

Autre suggestion : pouvoir modifier le volume de l'application (notifications sonores). Comme le font les jeux vidéo, en fait.

Actuellement, on règle ce volume avec le volume général de Windows... Pas forcément l'idéal si on écoute de la musique avec une autre application.

Voici une image pour illustrer cette idée :

Spoiler:

volume_mockup.png (123.98 Kio) Vu 603 fois

[Benoist Rousseau]

très bonne idée