L3 : Programme

Yes, Darth tu vas être content (et tout ceux sur OSX)

voilà à quoi ressemble l'interface avec les nouveaux boutons !

L3_1.17.2_GenButton.tiff (229.89 Kio) Vu 309 fois

Yes C'est parti, lundi une nouvelle version avec cette amélioration visuel et qui permettra d'avoir une homogénéité de l'interface entre les différents OS.

excellent Falex, je reprend le trading semaine prochaine impatient de voir tout ça en œuvre

Super donc ça me laisse une semaine pour finir le débug.
J'suis à 50% de la v1.18, j'ai mis les boutons.
Là je corrige des noms de variables, un peu de toilettage, j'ai recentrer les zone de SL.
Je pense qu'elle va être bien cette 1.18.

Après je suis tenter de passer à une 2.0 qui aurait pour principal changement le déplacement du chois de l'epic, non plus dans la fenêtre de login mais dans la fenêtre de ticket.

Salut les amis, je suis de retour de vacances, je viens de checker vite fait les derniers post.
Yopi> je vois que tu avais des corrections de bugs sur le programmation neuro-linguistique DAY (scaling factor), les as tu corrigées? sinon je peux m'en occuper cette semaine.
Je n'avais pas intégrer le salions factor dans cette fonction.

Falex > pour le choix de l'epic directement dans la fenêtre principale , j'avais fait une ebauche pour changer l'epic directement à la volée sans devoir redémarrer L3, si ca t'intéresse...ca fonctionnait

Il me semble que c'est bon depuis la 1.17 à vérifier

---

Idem oui envoi que l'on compare

pour les epics, email d'IG

Une liste globale d'EPIC sera envoyée à la rentrée

En attendant, une autre solution serait de prendre ce lien et de faire un clic droit sur le graphique, le code EPIC apparait.
Il y a un bloc de recherche de valeur en bas à droite pour passer d'une valeur à une autre rapidement.

J'espère que cela aidera un peu la communauté, en attendant un solution plus complète.

Je regarde à ca demain car mes sources sont au bureau...j'ai fait ca il y a bien 2 mois...Mais en gros j'avais scinder la fonction login en 2...
une partie connexion Api token et une partie connexion EPIC, il me semble
Ensuite à chaque changement dans le combobox, je relancais la fonction login puis la fonction avec le new epic... c'était peut être pas très propre mais ca fonctionnait sur la 1.13 ou 1.14 (je ne sais plus trop mais j'avais dev ca sur une de ces versions la)

Benoist> Je ne sais pas si tu as vu mais j'ai répondu a ton mail cet après-midi

Guilux > je lis mes emails le lendemain avec 24 heures de retard

t'as le temps Benoist

Guilux se reloger n'est pas utile, par contre faut que je regarde comment changer la souscription du flux LS

Je le suis fait une version L3 pour rentrer des OL uniquement avec changement d'épice mais comme je n'avais pas besoin des flux LS je n'ai pas encore creusé ce point

Tout a fait , se relog n'est pas utile mais c'était le moyen le plus rapide que j'avais trouvé pour modifié la fonction

Il me semble que l'on peut souscrire à plus d'une dizaine de table lightstreamer (50 de mémoire)
Pour se désinscrire d'une table il faut utlise la méthode delete de la classe lsclient. Pour faire du multiple instrument on peux très bien imagnier une combobox sur la fenêtre principale et à chaque changement d'instrument, une "désouscription/souscription".


Personellement j'utilise la méthode suivante:
Si on a souscrit à plusieurs marchés, lors d'un "price update" l'essentiel est de savoir à quel epic cela correspond. Pour mon appli j'ai modifié le fichier igls.py À la ligne 354 j'ai ajuste ajouté:

Code : #

 fields.insert(0, self.item_ids)

Je souscris à la table des prix comme ça:

Code : #

self.dict_price_table[epic] = igls.Table(self.ls_client,
									   mode=igls.MODE_DISTINCT,
									   item_ids='CHART:' + epic + ':TICK',
									   schema='UTM BID OFFER',                                                             item_factory=lambda row: tuple(float(v) for v in row)

du coup à chaque update je reçois une ligne contenant l'epic:

Code : #

['CHART:IX.D.DAX.IMF.IP:TICK', u'11204.9', u'11211.9']

que j'extrait avec une regex. En python ça donne ça:

Code : #

epic_updated = re.search(':(.*?):', epic_chart).group(1)

Je peux ainsi facilement identifier à quel instrument appartient l'update et ainsi mettre à jour les bons champs. Utile si on a des pos sur plusieurs marché.

Je pense qu'il y a certainement plus "pythonic" mais ça marche plutôt bien.

J'aime bien l'approche de chacun.

De mon côté, j'ai simplement créer deux variables epic1 et epic2 (je la fais courte) et je lance la connexion au flux LS pour chaque epic.
En plus des deux variable, ça me fait doubler les fonction events.priceupdate (1 et 2).

... Un peu lourd surtout pas très (voir pas du tout scalable.

Ton idée béni est pas mal du tout.

-> Idée d'amélioration (peut-être), plutôt de que de faire un agrégat de texte CHART:XXXX:TICK, pourquoi ne pas faire une simple liste (que tu as déjà en plus) voir un dictionnaire (je pense que le plus pythoniens c'est le dico comme ça on a jamais à se préoccuper de l'ordre de la liste) ...

Finalement la fonction igls.py renvoi ce que l'on veut ...

Perso je gère un dict de table ls auxquelles je souscris/désouscris en fonction de mes choix. Dans les faits je m'en sers en fait uniquement pour une déconnection propre car je n'atteint que rearement les limites LS.
J'ai au max 7-8 tables de prix et ça n'affecte pas les perf vu que c'est une tâche effectuée dans un thread.

L'avantage de pouvoir identifier ce que l'on reçoit c'est si on a des positions sur plusieurs marché. Pour la L3 il me semble que l'epic est accessible dans le dict des positions ouvertes. Dans ce cas quand on reçoit une update on peut faire

Code : #

for epic in dict_openposition[deal_id][epic]:
      if epic_recu == epic:
          update
      else:
          continue

pour mettre à jour la liste des pos ouvertes et

Code : #

if epic_recu == personnal.epic:
    update boutons
else:
    return

Pour mettre à jour les bouttons, le personnal.epic étant mis à jour à chaque changement dans la combobox.

Ca fait un moment que je n'ai pas suivi les updates, mais avec quelques ajustements ça devrait le faire....

En fait l'agregat de texte, je n'ai pas trop le choix (enfin je crois )
C'est la syntaxe qui est demandée pour sourscrire à une table (l'item_id), l'pic à proprement parler n'est pas accessible depuis la classe Table. A moins de modifié le fichier igls, mais on sort un peu de l'esrpit du truc qui se veut général.

Si tu veux que je fasse une beta pour la 2.0, je peux me pencher dessus

Dans la syntaxe de base, maroxe utilise MARKET:epic

Tu vois une différence entre MARKET:{epic} et CHART:{epic}:TICK.

Dans la doc de l'API, MARKET est en MERGE mode alors que CHART est en DISTINCT mode ...
Extrait de la doc expliquant la différence des deux modes (https://labs.ig.com/streaming-api-guide) :

* DISTINCT indicates that each update should yield a notification and is required for trade notifications. MERGE indicates that updates occurring very close together should only yield one update, and is used for account and price notifications to regulate the update rate)

---

Finalement une architecture qui serai bien :
Comme l'appel du Listen, crée un novuea thread peut)être que le plus simple et pour garder au maximummum la structure actuel, consisterai à ajouter un paramètre, à savoir l'epic.
Comme ça on peut écouter tous les flux que l'on veut, chaque appel à events.process_price_update serait totalement indépendant et scalable sans avoir rien à faire ...

pour les epics, email d'IG

Une liste globale d'EPIC sera envoyée à la rentrée

En attendant, une autre solution serait de prendre ce lien et de faire un clic droit sur le graphique, le code EPIC apparait.
Il y a un bloc de recherche de valeur en bas à droite pour passer d'une valeur à une autre rapidement.

J'espère que cela aidera un peu la communauté, en attendant un solution plus complète.

Merci Benoist pour le retour.

Effectivement le client graphique en Flash, donne l'epic quand on fait un clique droit.
Mais c'est vraiment pas pratique pour récuperer une liste d'epic en masse.

Matema vient de l'envoyer la liste des epics DE. y'a plsu qu'a intégrer dans la V1.18.

Il me semble que la fontion listen est déjà dans un thread car quand j'ai développé mon appli avec Qt, ça m'a posé un problème de communication entre threads, le main et le daemon qui gère le flux LS.

Pour la syntaxe de souscription comme je fais des graphiques en ticks j'ai simplement suivi la doc pour souscrire au chart, je ne me suis pas trop posé de questions. Et je t'avoue que j'ai pas trop compris la différence, même avec la doc

Je progresse en Python à force de décortiquer les fonction.

igls est relativement bein écrit ou en tout cas utilise des appel et des imbrications avec lesquels je ne suis pas très à laise.

aujourd'huoi c'etait un court sur *args et *kwargs : http://gothamblog.nemocorp.info/posts/args-kwargs-demystifies.html

C'est super en fait

Moi, je suis plus à l'aise avec "argh"!

Désolé, je dégage vite fait.
La pollution était si tentante!