Bot de trading

[As_sembleur]

Bonjour aux ForHumeur,

A l'approche de mes 75 ans (c'est vrai), je voudrais développer un bot de trading en PureBasic que que je viens de découvrir et qui me paraît très puissant.

Quelqu'un pourrait-il m'aider à chercher ce qui existe sur ce topic sur le forum ou bien me guiser dans ma recherche ?

Egalement, en parcourant la doc de PB, j'ai vu un article qui disait comment structurer un programme en PB et je n'arrive pas à remettre la main dessus.
Y-a-t'il un tuto à propos de cela ?

Merci beaucoup.

[Ar-S]

Bonjour et bienvenu.
Je n'ai jamais croisé de code pour ce genre d'action.
Pour le trading, la plateforme doit te proposer une API. Il vous faudra donc utiliser les commandes dédiées au net de purbasic.
Intéressez vous à HTTPRequest, c'est ce dont vous devriez avoir besoin.

[As_sembleur]

Merci pour cette prompt réponse.

Ma question était double : Est-ce que quelqu'un à déjà développé ce genre de logiciel et comment voir sur le forum ou les applis déjà développées si il existe un logiciel dont je pourrais m'inspirer. J'ai trouvé quelquechose sur Github mais cela ne fonctionne qu'en ligne de commande (basé sur linux). Il n'y a pas d'interface graphique. Je crois qu'il est développé en python et JSON. D'où mon intérêt pour PureBasic.

Un aparté : Au cours de ma carrière professionnelle j'ai développé des automatismes industriels et, comme un grand nombre d'électroniciens, j'ai dû me mettre à l'informatique dans les années 80'. J'ai alors écrit sur des feuilles volantes des programmes en assembleur (compilés à la main en hexadécimal, s'il vous plait ...) pour différents microcontrôleurs et microprocesseurs (8080, 6800, Z80, 68705, HPC46400, ...). Après, j'ai utilisé le Basic (GWBasic, QB64, Visual Basic) et maintenant, j'ai trouvé PureBasic qui me semble très complet, puissant et assez simple à "maîtriser" quand on a bien acquis sa structure et sa syntaxe. J'ai très peu utilisé le "C" par contre je suis capable de dire, en voyant le code C, ce qui peut être généré en assembleur et là où son les GOTO si décriés en BASIC. La programmation structurée n'est pas l'apanage des languages évolués mais est directement liée à la rigueur du programmeur.

Cela fait environ 6 mois à 1 an que je m'intéresse au bot de trading et effectivement, il y a plusieurs parties pour cette application (comme la grande majorité des applications d'ailleurs)

- Le développement du GUI (quoi afficher, comment intervenir, combien de fenêtres, etc.)
- La gestion des fichiers et des bases de données
- Le contact via des API avec une ou des plateforme de trading (binance, coinmarketcap, coinhouse, Kraken, ...) pour obtenir les cotations antérieures et la cotation courante d'une crypto.
- Egalement le contact pour Connaitre le solde d'un compte, acheter une crypto, vendre une crypto, convertir une crypto et le tout via d'autres API et dans ce cas avec une clé privée.

C'est une aventure passionnante.

Si quelqu'un est intéressé pour m'aider à construire cela, j'en serais très heureux.
J'aurais besoin d'aide pour contrôler l'architecture du programme dès le départ (organigramme général, définition des tâches logicielles, facilité de maintenance, organisation des procédures, des form, gestion de SQLite, affichage efficace de graphiques. Etc. Etc.

Bon, je suis un peu prolixe mais cela me semble nécessaire.

Bonne journée à tous.

[boddhi]

Bienvenu @As_sembleur,

Ma question était double

Je n'ai pas cru voir la deuxième question dans la suite de ton déroulé

J'aurais besoin d'aide pour contrôler l'architecture du programme dès le départ [...]

Il n'y a pas de règle architecturale absolue. Mais en général, pour ce type d'application, on construit l'interface utilisateur, on créé une boucle (While...Wend, Repeat...Until, etc au choix) chargée d'intercepter les évènements déclenchés par l'utilisateur et à partir desquels on lance des actions soit codées directement à l'intérieur de la boucle soit, si le jeu d'instructions est plutôt long (mais cela n'est pas une obligatoire, c'est plus par souci de lisibilité et surtout pour la possibilité de pouvoir y recourir à plusieurs endroits du code) de faire appel à des procédures qui jouent le rôle d'un Gosub...Return.
Dans ce dernier cas, la seule règle qui s'impose, c'est qu'au moment de la compilation, les procédures doivent être connues (par le compilateur) avant leur appel. Donc, deux possibilités :
• Une procédure a été écrite avant son 1er appel :

Code : Tout sélectionner

Procedure MaProcedure() ; Procédure qui contient le jeu d'instructions
  [...]
EndProcedure
MaProcedure() ; Appel de la procédure

Ici, le code s'exécutera sans souci.

• Une procédure a été écrite après son 1er appel :

Code : Tout sélectionner

MaProcedure() ; Appel de la procédure
Procedure MaProcedure() ; Procédure qui contient le jeu d'instructions
  [...]
EndProcedure

Ici, le code ne pourra être compilé parce que la procédure n'a pas été définie avant son appel.
Il faudra ajouter l'instruction Declare (déclarer la procédure donc) avant le 1er appel :

Code : Tout sélectionner

Declare MaProcedure()
MaProcedure() ; 1er appel de la procédure
  [...]
MaProcedure() ; 2e appel de la procédure
Procedure MaProcedure() ; Procédure qui contient le jeu d'instructions
  [...]
EndProcedure

 
Autre conseil très important qui fait gagner beaucoup de temps en terme de débogage, l'utilisation de l'instruction EnableExplicit.
Généralement placée en tout début de code, elle oblige le programmeur à déclarer toutes ses variables (et leur typage s'il est différent de celui par défaut) avant leur utilisation. On peut trouver cela contraignant mais elle évite bien des soucis. Le contrôle se faisant en amont de la compilation, elle évite bien des erreurs en aval, lors de l'exécution, et dispense en conséquence de l'écriture de code de gestion d'erreurs potentielles en lien.

Pour résumer, en terme architectural, il n'y pas de règle stricte. PB est assez souple pour tout permettre pour peu qu'on s'y prenne de la bonne manière. On a connu sur le forum des membres (très très rares certes) qui se refusaient à utiliser les procédures et ne juraient que par les Goto, Gosub...Return.
L'intérêt de l'utilisation des procédures est à mes yeux incontournable ne serait-ce qu'en termes de réemploi et de lisibilité.

Personnellement, je construis mes applis fenêtrées plus ou moins, selon les contraintes, de la manière suivante :
• Initialisation des plugins
• Déclaration des structures
• Déclaration des Enumeration
• Déclaration des constantes
• Macros
• Déclaration des tableaux, listes et maps
• Déclaration des variables globales
• Déclaration des procédures
• Import des fichiers inclus (code, images, etc)
• Traitement des données (images, sons, etc) inclus en DataScetion
• Fonctions (procédures qui retournent un résultat) globales (pouvant être appelées par n'importe quelle fenêtre)
• Procédures globales (pouvant être appelées par n'importe quelle fenêtre)

et ensuite, pour chaque fenêtre :
• Fonctions locales (qui ne seront appelées que par la fenêtre)
• Procédures locales
• Boucle d'évènements de la fenêtre locale (s'ils ne sont pas gérés par la boucle d'évènements de la fenêtre principale)
• Définition de l'UI de la fenêtre locale

puis
• Boucle d'évènements de la fenêtre principale
• Définition de l'UI de la fenêtre principale

et enfin,
• Appel de la procédure qui lance la fenêtre principale
• Données des DataSection

Cette façon de procéder est en partie l'héritage de l'époque lointaine où j'utilisais VisualBasic et son niveau d'organisation.

Bien évidemment, cette arborescence pourra un peu différer, notamment lorsqu'il n'y a pas de fenêtre parente prédominante.

Voilà, voilà pour l'aspect architectural. Quant aux aspects techniques, tu trouveras sur le forum français, anglais (et allemand) tout plein de codes qui répondront en partie à tes besoins et si tel n'est pas le cas, n'hésite pas à poster pour demander de l'aide, il se trouvera toujours une bonne âme pour essayer de (t'aider à) résoudre ton problème.

PS : Dans PB, F1 est une touche magique !!!

[As_sembleur]

Merci Boddhi_darma,

Je n'ai pas cru voir la deuxième question dans la suite de ton déroulé

Oui, le doublé n"est pas évident.

Autre conseil très important qui fait gagner beaucoup de temps en terme de débogage, l'utilisation de l'instruction EnableExplicit.

J'utilise effectivement la directive EnableExplicit, c'est vrai que cela permet de gagner beaucoup de temps de débogage.

Concernant l'architecture du programme :

Tout d'abord, je te remercie grandement de partager ta manière de travailler. Je retrouve là l'essence d'une personne qui fait les choses proprement.
Ta manière m'éclaire beaucoup sur les capacités de PB et je vais vraiment m'en inspirer.

- Si je comprends bien, le compilateur doit être monopasse (ce qui le rend très rapide) à cause de ce que tu m'expliques sur la déclaration des procédures.
A propos de cela, j'avais, houu ! il y a quelques dizaines d'années, créé un "pré""pré"assembleur qui me permettait d'avoir plus de souplesse d'écriture et de facilité de maintenance (c'est fondamental en assembleur).

J'avais créé des prédirectives uniques (différentes de celles de l'assembleur) :

RAM0. déclaration de variables en ram de l'adresse 0 à 255 (h00 à hFF) ou certaines instructions spécifiques peuvent être éxécutées
RAM. déclaration de variable en ram au-delà de 255 (h0100)
INIT. les programmes lancés à l'initialisation en mémoire FLASH (timers, SCI, SPI, E/S, ...)
PROG. le code de l'application en mémoire FLASH
TIMER. les routines en IT pour les timers du programme (de 1mS à 65535 mS) en mémoire FLASH
IT. les routines en IT (interruption) en mémoire FLASH

Quand je déclenchais l'assemblage, via un batch (.bat), je prenais le prog source général, je le lisais et j'ouvrais tous les "include", l'un aprés l'autre pour séparer les prédirectives décrites ci-dessus dans des fichiers séparés que je rassemblais ensuite dans le bon ordre dans un seul fichier pour lancer l'assemblage. C'était très souple et d'une maintenance très aisée. Mon plus gros programme faisait plus de 6000 lignes (code et commentaires, très importants les "vrais" commentaires en assembleur). Une fois assemblé, cela donnait moins de 10 Ko !!! Que fait-on aujourd'hui avec 10 Ko ! Hein, je vous le dis, moi ! mdr

J'aurais appécié que cette philosophie soit envisagée en PB. C'est simple à mettre en place. Tiens, c'est vrai, je vais y penser !
Cela demanderait 2 passes mais la première serait très rapide.

En automatisme, on utilise le Grafcet https://www.heh.be/processim/aide/Rappe ... rafcet.htm (programmation par étape et transition) et j'avais un noyau, un moteur, très simple, d'environ 10 lignes soient 10 instructions, grâce au mode d'adressage indexé, qui faisait dérouler plusieurs grafcet indépendants très rapidement.
Le temps de passage d'une transition ou d'une étape à une autre était constant et très court.
La synchronisation des tâches, si nécessaire, se faisait par bit d'état testé et positionné en RAM0. (sémaphore, flag, ...)
C'était un multitâche temps réel avec le matériel de l'époque, et ... ça fonctionnait même en milieu explosible (gaz butane et proprane, ...)

Je me demande si cette "astuce" ne pourrait pas être reprise en PB pour gagner en vitesse ?

Pour la petite histoire, j'avais également développé une astuce qui me permettait de créer des étiquettes en quantité sans me prendre le crâne.

S00 (numéro du grafcet ou "séquenceur")
P00 (numéro de phase, c'est-à-dire étape ou transition)
L00 (étiquette dans cette phase)

par exemple S10P12L62 grafcet 10, phase 12, label 62 que j'aurais pu simplifier en S101262 ou G101262 ou encore étape E101262 ou Transition T101262.
L'intégration de "pré" et "post" étape se basait sur le même principe. Les étaoes/transitions étaient très majoritairement des sous-programmes assez courts.
Toute sortie de programme ou de grafcet se faisait avec un label L99 ou L09, ce qui aidait à la lecture. Aucun sous-programme n'était bloquant.
En attente d'un évènement, d'une réponse, je quittais le grafcet pour y revenir à cet endroit très vite dés que possible, souvent moins de 100 à 500 microsecondes, ce qui avec un microcontrôleur à 4 MHz était très correct.

Bon, je suis encore prolixe. Merci encore bodhi, tu m'écraire beucoup et je vais m'atteler en parallèle aux API vers les plateformes. Je crois que c'est une étape importante.

[boddhi]

Si je comprends bien, le compilateur doit être monopasse

Je n'y connais absolument rien en assembleur, je ne m'aventurerai donc absolument pas à argumenter ou développer tes propos.
Toutefois, je ne crois pas dire de conneries en confirmant que le compilo est monopasse pour les raisons évoquées.

Que fait-on aujourd'hui avec 10 Ko ! Hein, je vous le dis, moi ! mdr

Aujourd'hui t'as plus rien pour 100 balles ! comme disait déjà mes parents...
Plus sérieusement, PB a encore pour lui de produire des exécutables légers en comparaison de ce que produisent d'autres logiciels de la même catégorie. C'est l'un des facteurs, même si ce n'est pas le plus prédominant, qui font qu'un certain nombre d'entre-nous l'ont adopté.

[As_sembleur]

Aujourd'hui t'as plus rien pour 100 balles ! comme disait déjà mes parents...

Ah ! Mon bon monsieur, tout fout le camp.

PB a encore pour lui de produire des exécutables légers

C'est vrai, les touts petits programmes d'essai que j'ai compilés semblent assez léger. Mais dans ce genre de chose, on peut avoir facilement des surprises.

Bon, je commence à me débrouiller avec les API de la plateforme de cryptomonnaies de Binance. Leur doc est assez bien faite bien qu'écrite de la main gauche (oups ! Je suis gaucher !)

Je vais bientôt tenter quelques "ping" et si cela se passe bien, je ferais une demande de cotations antérieures, puis, dans un futur inconnu, je tenterais l'utilisation des routines de travail sur un compte (tiens, c'est un vieux mot les "routines") :
- J'ouvrirais un compte avec 50 € par exemple
- Lecture de l'état du compte
- lecture des cotations en live à différents intervalles de temps
- achat d'une crypto (pas cher, pas cher)
- vente d'une crypto (très chère, très chère) mdr
- je ferais la liste et testerais toutes les API dont j'ai besoin et je les rangerais bien au chaud pour plus tard

Après cela, je serais déjà très bien avancé. Cette partie, essentielle, sera à priori terminée.

Le travail reviendra à s'occuper de la gestion de toutes ces données en local, dans le PC et de définir une stratégie de placement, ce qui nécessite la connaissance du vocabulaire boursier et de l'apprentissage des méthodes de décision via des tutos.

Je reviendrai alors peut-être vers le forum car je n'ai aucune connaissance sur l'utilisation des SGBD du genre Sqlite. Je vois très bien comment cela est organisé, commet cela fonctionne, mais je n'en ai jamais eu besoin. C'est là que l'on voit la spécificité des outils en informatique. On peut avoir des connaissances et une expérience très pointues et être coi devant un nouvel outil. En fait, il se peut que je n'utilise pas de SGBD.

Une dernière question.
Anciennement, les 8086 et suivants fonctionnaient en mémoire paginée de 64Ko par page avec une base de 16 bits ce qui faisait un adressage étendu de 32 bits donc 4 Go.
Est-ce que c'est encore valable aujourd'hui ou bien les microprocesseurs d'aujourd'hui (pentium et core par exemple) adressent-ils directement 32 ou 64 bits ?

Bonne journée et merci

[As_sembleur]

Bonjour à tous,

J'ai beaucoup avancé et appris sur les API, HTTP, Websocket, Github, etc.
Je réussi maintenant à me connecter à Binance pour avoir des infos générales.

Il me reste, pour pouvoir travailler sur un compte, à établir les demandes de consultation de compte, d'exchange de monnaie, de positionner des limites, etc. Pour cela, j'ai obtenu une clé privée et une clé API que je dois utiliser pour signer les demandes d'ordres appliqués au compte.
Et, ces demandes doivent être signées !
La doc de Binance donne les conditions de la signature des messages et un exemple de transfert, sous linux, en C++, je pense ?

Bash script

#!/usr/bin/env bash

# Set up authentication:
API_KEY="put your own API Key here" #Ex : "CAvIjXy3F44yW6Pou5k8Dy1swsYDWJZLeoK2r8G4cFDnE9nosRppc2eKc1T8TRTQ"
PRIVATE_KEY_PATH="test-prv-key.pem" #même longueur de clé : 64 caractères

# Set up the request:
API_METHOD="POST"
API_CALL="api/v3/order"
API_PARAMS="symbol=BTCUSDT&side=SELL&type=LIMIT&timeInForce=GTC&quantity=1&price=0.2"

# Sign the request:
timestamp=$(date +%s000) # conversion en millisecondes
api_params_with_timestamp="$API_PARAMS&timestamp=$timestamp"
signature=$(echo -n "$api_params_with_timestamp" \
| openssl dgst -sha256 -sign "$PRIVATE_KEY_PATH" \
| openssl enc -base64 -A)

# Send the request :
curl -H "X-MBX-APIKEY: $API_KEY" -X "$API_METHOD" \
"ht_tps://api.binance.com/$API_CALL?$api_params_with_timestamp" \
--data-urlencode "signature=$signature"

#attention : J'ai ajouté un underscore dans "ht_tps" pour que le texte ne se mette pas comme un lien raccourci (en bleu)

- Ma première question : Est-ce que la bibliothèque "cipher" de pb répond à la norme demandée RSASSA-PKCS1-v1_5 algorithm with SHA-256 ?
Si oui, quel paramètre dois-je utiliser dans ceux qui sont possibles ?

- Ma deuxième question : Je suppose que pb est converti en C ou C++ avant d'être compilé, comme dans QB64. Est-ce que je peux intégrer directement du C ou C++ via une directive du compilateur dans pb (comme pour l'assembleur) ?
Si oui, comment faire et si il est nécessaire d'ajouter une bibliothéque SSL, quelle version dois-je utiliser et dans quel répertoire dois-je l'intégrer (je pense à priori en /lib) ?

Remarque subsidiaire : Je suppose que le compilateur pb ne charge que les fonctions nécessaires des librairies dans l'exécutable ?

Quand cela fonctionnera, je serais heureux, très heureux d'avoir réussi cela !

Merci et bon week-end.