PureBasic

Bonsoir,

Franchement l'utilisation de SetMailBody est peu détaillée... Pour le reste, je sais comment est fabriqué un mail... J'ai réalisé "l'équivalent" en Indy 10 qui n'est pas exempt de bugs mais dont la documentation est conséquente.
Car la recherche sur Google avec les mots clès "PureBasic SetMailBody" -qui normalement devrait être assez explicite- annonce environ 220 réponses qui finalement se réduisent à 2 pages de 10... et dont le résumé est :

Syntax : SetMailBody(#Mail, Body$)
Description : Change the #Mail body. GetMailBody() can be used to get it back.
Example:
InitNetwork()
If CreateMail(0, "test@purebasic.com", "Hello")
SetMailBody(0, "This is the body")
Debug GetMailBody(0) ; Will print "This is the body"
EndIf

C'est décevant et surtout peu explicite. En général, j'évite les langages, les bilbliothèques et les composants faiblement documentés. Il n'est pas question de ré-inventer la roue à chaque développement, mais un minimum d'autonomie me semble nécessaire : un langage non (ou mal) documenté ne permet pas cette approche autonome et je ne suis pas trop adepte de la recherche à tâtons. Je me vois mal à la remorque de la communauté... pour récupérer quelques trucs qui fonctionnent mais dont le mécanisme m'échappe... Car à terme, ils sont finalement très difficilement adaptables ("maintenables") à l'évolution des bibliothèques tierces (libmysql par exemple...).

Enfin, c'est que j'ai pensé des articles trouvés sur le forum en ce qui concerne PB et Mysql sachant que comme je l'ai déjà précisé les accès ODBC ne me donnent pas satisfaction. Là aussi, c'est délicat. Quand une méthode d'une bibliothèque ou un composant ne donne pas satisfaction, il faut disposer d'une alternative. Dans le cas présent sur le forum, j'ai rencontré plusieurs fois, si mySQL est "délicat", utilisez à la place Sqlite. Hum ! Il faut s'adapter au langage que l'on a choisi, peut-être pas dans ces termes où alors le choix n'était pas judicieux...

Donc je vous remercie pour votre aide et je vais arrêter ici la découverte de PB pour lequel je ne regrette vraiment pas le petit détour que j'ai réalisé... Je surveillerai avec intérêt son évolution.

Bonne continuation dans vos développements.
Cordialement. Gilles

Bonjour selzig,

Juste pour te répondre, je travaille moi aussi dans une boite de dev et PureBasic n'est résolument pas un langage destinée aux SSII, tu l'auras compris facilement. Il manque trop de composants rédhibitoires (Designer, Reporting, Support, Déploiement...).

PureBasic est clairement pour les passionnés, les nostalgiques, les débutants (et quelques rares professionnels malgré tout mais c'est très anecdotique) - et c'est assumé par la petite mais très motivée équipe de développement et même leurs utilisateurs. Ce langage est une niche à part. D'autant plus à part qu'il est proche du BASIC (bon certes), du C (accès direct aux API de l'OS hôte, et aux libs tierces) et proche aussi de l'assembleur à plusieurs égard. C'est un petit langage du dimanche qu'on utilise trop facilement en semaine... Pourtant je fais une cure...

Pour utiliser MySQL (entre autres) dans pas mal de langages, et donc en PureBasic, moi je sais que pour un programmeur, un vrai, ce n'est absolument pas difficile. Tout le monde pense que c'est difficile mais c'est juste par méconnaissance du sujet.

J'ai tout testé entre PureBasic et MySQL et tout a été possible...
Ce qu'il faut comprendre en PureBasic c'est quand il manque quelque chose en natif, on peut toujours le faire via des libs open-source (ou pas d'ailleurs), comme en C. Il faut juste faire quelques includes/wrappers et c'est parti.
Utiliser libmysql.lib est possible sans souci... J'ai fais une lib pour çà (et faut pas être sorcier pour y arriver) mais apparemment le site d'hébergement est HS. Mais j'ai tout sur mon dur si tu veux rentrer dans le vif du sujet. L'avantage d'utiliser les libs tierce c'est que là au moins la documentation fournie est exhaustive (ie. www.mysql.com)

@Flype

En te priant de m'excuser pour le léger affront que je poste ici, je te demande de laisser le temps faire et de ne pas répondre hâtivement d'une manière aussi maladroite.

Indirectement, tu prends Selzig pour un con. On ne sait pas son projet précisément. Et je comprends parfaitement que l'on n'ait pas à le savoir, pour des raisons de confidentialité, et donc d'aboutissement. En outre, prétendre que PB est ou n'est pas résolument destiné au développement en SSII c'est prétendre connaître l'intelligence de Selzig ainsi que son projet précisément.

C'est à Selzig, de découvrir par ses capacités ce qu'il a en face de lui au bout de quelques jours. Et dans le cas où il se rend compte qu'il contrôle la création de son produit grâce à ce compilateur, si on lui sort des vérités mal pensées, c'est à Fred que tu auras fait du tort.

Sans me faire passer pour un gourou. Le modèle de réponse à cette question, c'est:

Oui, PureBasic convient à une entreprise purement informatique dans ces domaines de domination énumérés ci-dessous...

Non, PureBasic ne convient à une entreprise purement informatique dans ces domaines de médiocrité énumérés ci-dessous...

Dire seulement l'une de ces deux parties, c'est prématuré. Un produit, c'est une résultante technico-commerciale et non un système purement technique. Cette subtilité que tu as négligé prend en compte l'existence superbes trésors logiciels non distribuables sur le Web (le créateur serait perdant dès la diffusion), tout comme elle prend en compte l'existence d'une terrible concurrence avec la Chine, l'Inde et le Maghreb (le rapport prix de l'outil/prix de la main d'oeuvre est nettement supérieur à celui de la France) dont la pression concurrentielle est telle qu'à ton status tu penses avoir forcément et sans aucun orgueil malicieux raison de ce que tu affirmes.

Ensuite, au cas où tu ne le saurais pas, je n'ai JAMAIS expédié un mail de manière automatique, ni usé de la librairie Mail! Pourtant, j'essaie quand même de comprendre ce qu'il veut! Si tu bosses en SSII, peut-être qu'une réponse technique à sa question technique aurait été plus judicieux, sachant que sa question technique est dans le titre et qu'il la redemande en milieu de page 1.

Donc, soit on le laisse galérer à chercher SetMailBody() sur Google comme il l'indique si clairement en haut de cette page.
Soit on l'aide! ça lui fera peut-être les pieds pour savoir si PureBasic est bonne chaussure...

@Selzig

Ne perds pas ton temps sur Google pour trouver la signification d'une instruction qui se trouve dans ton aide!

On va partir de tout ce que moi j'ignore et de tout ce que toi tu sais.

J'ignore ce que c'est qu'un mail dans sa représentation finale à l'écran parce que je n'ai jamais expédié un mail via un système automatisé.

Tu sais qu'un mail c'est un fichier.
Tu sais qu'un fichier c'est une chaîne ASCII.
Tu sais qu'une chaîne ASCII c'est un enchaînement de caractère ASCII.
Tu sais qu'un caractère ASCII, c'est un code de 0 à 255 qui a une représentation visuelle et/ou fonctionnelle.

Il y a dans l'aide la table ASCII pour savoir à quelle représentation correspond tel code.

Exemple : code 65 représente la lettre A majuscule
Exemple : code 48 représente le chiffre 0
Exemple : code 13 représente le retour chariot (comme l'appui sur la touche Entrée)

En Basic, on obtient la représentation d'un caractère ASCII avec Chr()
(De l'anglais CHaRacter = caractère)
Exemple: En Basic, on obtient le code ASCII d'une représentation avec Asc() (De l'anglais American Standard Code, l'abrégé du sigle ASCII)
Exemple: En Basic, une chaîne stockée dans le listing du programme doit être entre guillemets Le corps (anglais BODY) d'un mail c'est une chaîne texte.
Une chaîne texte c'est une chaîne où certains caractères entre 0 et 31 sont interdits. On va admettre que tous les caractères dont le code est entre 0 et 31 sont tous interdits, à l'exception de ceux que je préciserai plus bas.
Tous les autres caractères que tu peux donc voir dans l'aide (table ASCII) et qui ont code supérieur ou égal à 32 peuvent éventuellement exister dans une chaîne texte.

Une chaîne texte c'est comme la page d'un livre: c'est une succession de ligne. Pour séparer chaque ligne, on s'autorisera l'utilisation du caractère 13. C'est comme l'appui sur la touche [Entrée] dans un traitement de texte.

Exemple: Si un texte a 50 lignes, on ne va pas s'amuser à stocker une ligne immensément longue dans le listing du programme. Voici la méthode communément employée en Basic. L'instruction SetMailBody() contient deux arguments entre parenthères.
1er argument : le numéro du Mail en cours d'édition
2nd argument : le chaîne contenant le corps du mail

Donc, pour insérer un texte dans le corps de l'e-mail, on va procéder exactement comme l'exemple ci-dessus avec l'instruction MessageRequester().

Maintenant, dans ce texte qui va se trouver "emballé" entre des guillemets dans le listing du programme, le contenu n'est plus dans les normes du langage Basic, mais dans les normes MIME (Source Wikipedia).

Regarde notamment dans la section "Message en plusieurs parties". Tu auras l'exemple de texte que j'ai posté en page 1.
Moi, je ne peux pas faire le test car je n'ai pas une boîte mail qui supporte le SMTP et avec un système anti-spam qui m'empêche de faire des tests d'envoi de tout petits e-mail comme ça.

Donc, ce qui serait bien c'est que tu crées ton e-mail comme dans l'exemple Mail.PB dans l'aide et que tu insères ce bout de code ci-dessus avant l'instruction SendMail()

Est-ce que tu comprends l'astuce?
Est-ce que tu peux créer le code d'envoi du mail?"
Est-ce que ça marche?

Si on n'y arrive pas, une autre solution sera de récupèrer un mail de pub que tu as reçu et qui contient l'astuce d'affichage direct et de me le transmettre, j'étudierai de près octet par octet le phénomène. ça ne doit pas être compliqué...

Ollivier

@Olivier
sans volonté de mettre le souk , je voudrai attirer moi, ton attention
sur tes propre contradictions

tu ecris :

Ollivier a écrit :@Flype

Indirectement, tu prends Selzig pour un con.

puis ensuite tu te lance dans cet explication

Ollivier a écrit : @Selzig

Il y a dans l'aide la table ASCII pour savoir à quelle représentation correspond tel code.

Exemple : code 65 représente la lettre A majuscule
Exemple : code 48 représente le chiffre 0
Exemple : code 13 représente le retour chariot (comme l'appui sur la touche Entrée)

En Basic, on obtient la représentation d'un caractère ASCII avec Chr()
(De l'anglais CHaRacter = caractère)
Exemple:

Code : Tout sélectionner

Debug Chr(65) ; Affichera la lettre A

En Basic, on obtient le code ASCII d'une représentation avec Asc() (De l'anglais American Standard Code, l'abrégé du sigle ASCII)
Exemple:

Code : Tout sélectionner

Debug Asc("A") ; Affichera 65
Debug Asc("a') ; Affichera 97

En Basic, une chaîne stockée dans le listing du programme doit être entre guillemets

Code : Tout sélectionner

Debug "Bonjour entre deux guillemets"

Le corps (anglais BODY) d'un mail c'est une chaîne texte.
Une chaîne texte c'est une chaîne où certains caractères entre 0 et 31 sont interdits. On va admettre que tous les caractères dont le code est entre 0 et 31 sont tous interdits, à l'exception de ceux que je préciserai plus bas.
Tous les autres caractères que tu peux donc voir dans l'aide (table ASCII) et qui ont code supérieur ou égal à 32 peuvent éventuellement exister dans une chaîne texte.

Une chaîne texte c'est comme la page d'un livre: c'est une succession de ligne. Pour séparer chaque ligne, on s'autorisera l'utilisation du caractère 13. C'est comme l'appui sur la touche [Entrée] dans un traitement de texte.

question : qui prends Selzig pour un con ??

le mec , il est sensé etre un professionnel de la prog , je supose
qu'il connait le code ASCII non ?

Olivier , c'est souvent que je me marre vraiment en te lisant
change pas !

tu ecris

Pour séparer chaque ligne, on s'autorisera l'utilisation du caractère 13.

en fait il s'agit du caractere 10 (Line Feed) pour aller a la ligne !!

et plus exactement de la sequence 10 13

mais 10 suffit
la preuve *

Bonjour,

Merci à vous 2. J'ai vu sur internet une partie du travail de Flype sur l'utilisation de MySQL (des aticles qui datent de 2004/2005). Sur le ton employé, je ne me sens pas agressé mais même si c'était le cas, comme on dit, on est nécessairement le con de quelqu'un. C'est humain : cela rassure ou gratifie l'autre, celui qui ne l'est pas... et ne fait pas de mal au premier (puisqu'il l'est...). Donc le système perdure : c'est une "routine" psychologiquement stabilisante et sans danger.

Alors, Flype, j'ai vu le travail dont vous parlez que je ne m'estime pas et qui à ma connaissance n'est pas à jour. En tout cas on n'en trouve pas trace... Depuis mySQL 4, beaucoup d'eau est passée sous les ponts. Alors évidemment, tout dépend de ce que l'on veut faire.

Si on veut se concentrer sur l'applicatif (comme c'est mon cas), être obligé de maintenir régulièrement à jour "ses" bibliothèques d'accès à mySQL (pour suivre ses évolutions) devient rapidement difficile. Je l'ai fait un temps avec libmysql.pas. Cela nécessite en effet de se plonger dans un méandre de subtilités pour toujours faciles à comprendre... et qui compte tenu de mes modestes capacités m'empéchait en parallèle de continuer à développer proprement l'applicatif commandé par le client. A l'arrivée c'est frustrant, je le reconnais. Mais heureusement, il y a des équipes qui se concentrent sur le problème, des spécialistes qui tracent mySQL, ses évolutions... et celles d'autres BDD (par exemple ZeosLib)... Ceci nous permet de produire en aval un code réutilisable quelque soit la base de données (mySQL, sqLite, Postgresql, Oracle...). Après reste le problème économique retenu pour leur diffusion (communautés, sociétés à but lucratif)... ou le problème technique pour Flype (Hébergement HS ?)...

Pour Ollivier, recopier ligne à ligne le code d'un mail reçu est à mon avis, une très mauvaise méthode... Par contre, développer sa propre méthode pour arriver à générer le code et comparer avec celui qui semble-t-il fonctionne est à mon avis meilleur. De toute façon, cela n'a pas d'importance. Le projet a été maquetté une première fois dans un L4G sous Windows, pour modéliser les problèmes (notamment des bases mySQL très lourdes et la gestion du multithreading) puis ensuite être développé dans un langage compilé sous Windows et Linux. Pour découvrir PB, je me suis concentré simplement sur 2 points qui nous ont demandé un peu de savoir-faire (la génération du mail "HTML" à partir de pièces jointes et d'un fichier html, et l'accès rapide à une table mySQL hébergée donc distante de 400 000 adresses en maintenant la connexion persistante). Sans aucune prétention d'arriver à un code fonctionnel, j'ai rarement pratiqué le Basic, je me suis plutôt intéressé à la démarche nécessaire en PB : Téléchargement de la version de Démo, recherche d'une bonne doc sur les principes de programmation en PB (Fichier .doc trouvé facilement et répondant en effet à mes attentes), puis gestion du mail (le point de départ de la discussion) et recherche des méthodes de connexion à une base mySQL.

Pour en revenir à PB, visiblement vous aimez ce produit (Normal sur un forum qui lui est consacré)... et vous êtes des passionnés... mais, si je peux me permettre, sans porter préjudice à quiconque (la manière de vous traiter entre vous, membres du forum, me semble parfois étrange, aussi, je ne voudrais pas commettre d'impair) : intrinsèquement, tout produit mérite considération. Comme le dit Ollivier, il faut se placer dans la perspective de son utilisation une fois qu'il a été retenu par l'équipe de développement. Comme, je l'ai écrit, je trouve ce produit surprenant et "attachant", mais dans le cadre des développements que nous réalisons, il est inadapté, non pas au sens où "on ne peut pas faire" (on peut pratiquement toujours faire en contournant le problème dans un autre langage puis en compilant la dll, so, dylib associée), mais à celui de "nécessite trop d'investissements de contournements par rapport à la finalité de l'objectif". Objectif qui dans mon cas est de présenter au client son applicatif dans un temps limité (et déterminé à l'avance), à un coût également déterminé à l'avance.
D'autant que même avec un cahier des charges précis, les modifications demandées après la livraison (corrections, évolutions) requièrent souvent un travail non négligeable. Le critère d'adaptation "facile" est pour moi important. Par exemple, un client a changé d'hébergeur et de BDD : il est passé de mySQL à Postgresql. J'imagine mal la résolution du problème avec la lib de Flype : il faudrait ré-écrire une lib pour Postgresql pour pouvoir modifier le back-end du client. Reste évidemment la solution ODBC. Mais dès qu'une table prend un peu d'importance, entre un accès natif et un accès ODBC (même en utilisant un fetch partiel), il n'y a aucune comparaison pour alimenter une Grid.

Enfin économiquement, il me paraît impossible de demander au client de prendre en charge la mise à jour d'une librairie utilisée pour accéder à sa BDD !

Voilà pourquoi, j'ai décidé d'arrêter ma découverte de PureBasic. Cette discussion est intéressante mais n'arrivera pas à faire s'entendre des points de vue inconciliables mais néanmoins obligatoirement ccopératifs. Des développeurs d'accès aux BDD, il en faut pour des développeurs de mon genre. Mais, Flype, si tu as besoin de valoriser ton travail -ce qui me semble normal-, mercantilise-le... C'est aussi gratifiant... mais c'est une autre approche.

Cordialement. Gilles. (Oui Selzig c'est Gilles à l'envers avec une petite modification de CONsonne... Je sais Flype, je sais : quel ...!)

J'ai suivis ce sujet depuis le début . Personnellement j'utilise Purebasic au boulot pour le développement de petit outil. Purebasic est un language qui s'améliore peu a peu. selzig garde un oeil sur purebasic, peut être qu'un jour il sera devenu suffisamment mature pour tes besoins ! En tout cas merci d'être passé nous voir ! Et peut être a bientôt

Juste pour dire que je ne prends personne ici pour un con, ce n'est pas mon genre.

Comme dit selzig dans un de ces post :

Maintenant pour développer en SSII, une application de gestion "classique" [...]

Là-dessus, je suis désolé pour les ayatolas du PureBasic, mais d'autres langages sont très largement mieux armés.
Vous avez déjà cherché du travail dans le développement/la gestion de projet ?

Que trouve-t-on en grande majorité ? Java, C/C++, VB/C# .NET, PHP, et autres gros systèmes... C'est juste la réalité. Bien défendre PureBasic, ce n'est pas de nier ces réalités économiques. Si quelque chose n'existe pas en PureBasic il faut l'inventer (c'est tout à fait possible, conversion d'includes de libs tierces ou réécriture complète d'algorithmes). Dès lors la maintenabilité et le coût sont des facteurs rédhibitoires par rapport aux langages classiques de développement professionnel qui proposent déjà tout et bien plus encore que ce qu'on imagine quand on ne connait que PureBasic.

En milieu professionnel, le créneau le plus proche - à mon sens - de PureBasic, je veux dire les programmeurs les plus à même d'utiliser ce langage sont ceux issus du C ou VB6 (pas le C++). Ces programmeurs là seront les moins déconcertés, car la plupart du temps il faut savoir lire les fichiers d'includes C des librairies tierces et en faire une traduction PureBasic.
En revanche, les programmeurs issus des autres langages (objets pour la plupart) et qui représentent 99% des développements en SSII, n'ont aucun intérêt à se pencher sur un langage type PureBasic. Et ce ne serait-ce que pour une raison simple. En SSII, tout projet est conceptualisé/modélisé en UML, et généralement le code est prémaché par des outils puissants qui génèrent le code objet directement depuis des diagrammes.

J'ai envie de dire et alors, ce n'est pas le créneau de PureBasic. Comme l'ai dit PureBasic a sa propre niche. Ce n'est pas un gros mot. PureBasic est effectivement génial. Je l'utilise aussi au travail, et pour certains outils il se révèle très adapté notamment pour la légèreté de l'environnement de développement et pour la compacité du produit final (tant par la taille de l'exécutable que par le peu de dépendances requises) et surtout pour la rapidité du code en général. L'argument de PureBasic est là.

selzig a écrit :Bonjour, Depuis mySQL 4, beaucoup d'eau est passée sous les ponts.

L'include que j'avais écris (d'ailleurs je ne suis pas le seul, d'autres du forum anglais en on fait aussi) est une simple réécriture du fichier d'include en C proposé par l'API MySQL5.1 (et non v4, mauvaise langue - la dernière version datait de début 2008 pas plus). Traduire un fichier d'include C vers PureBasic est plutôt facile et même quasi-automatisable.
Ensuite j'ai fais plusieurs variantes de cette include, une en s'alignant le plus possible sur les commandes PureBasic natives (Sous-Système) et une autre avec une approche objet (iMySQL) en utilisant les interfaces.

Par exemple, un client a changé d'hébergeur et de BDD : il est passé de mySQL à Postgresql. [...] il faudrait ré-écrire une lib pour Postgresql

Oui mais là pareil, c'est assez facile, à peine deux ou trois jours de travail et encore. Le plus difficile étant effectivement la maintenance à chaque nouvelle version de la DLL officielle.

Mais, Flype, si tu as besoin de valoriser ton travail -ce qui me semble normal-, mercantilise-le... C'est aussi gratifiant... mais c'est une autre approche.

C'est marrant çà, j'avais fait cette include à la demande d'autres personnes sur le forum. Une fois mise à disposition personne ne l'a maintenue. Moi perso je m'en fous, quand j'ai besoin d'un truc je le trouve, je l'utilise ou je fais moi-même. Et basta je développe ce que j'ai à développer. C'était un acte de partage pur à un moment donné où quelqu'un en avais besoin, pas un acte d'engagement à vie. Je n'ai pas à faire de pub, je ne compte pas en faire des sous. Pour moi ce serait du vol manifeste de vendre une simple include PureBasic à peine remaniée qui propose ni plus ni moins que les fonctions de la DLL officielle MySQL. Tout ce que j'ai pu faire par le passé pour PureBasic a toujours été dans le plus pure esprit partage. A chaque fois les sources étaient fournies et libre de modification.
La vraie démarche salutaire pour PureBasic n'est pas dans la vente d'API pour des libs gratuites... Mais plutôt à l'inverse dans l'écriture d'un maximum d'includes pour les libs les plus connues et utilisées, certains l'ont bien compris comme Progi1984 qui en a proposé pleins déjà et moi un peu aussi.

Bonjour Flype,

Pour le c.., je n'avais pas ce sentiment en effet. C'est le ton général de votre forum qui me surprend un peu, un peu hautain je trouve : j'ai utilisé le forum débutant pour poser ma question...

l'API MySQL5.1 (et non v4)

Désolé, dans l'article que j'ai lu (http://www.purebasic.fr/french/viewtopi ... d6233c8ae2), en effet, le code faisait référence à Mysql 5 et PureBasic 4.0... J'ai lu trop vite et compte-tenu de la date de l'article, j'ai pensé Mysql 4 (Fév. 2006) quoique la 5 soit stable depuis octobre 2005.

Tout ce que j'ai pu faire par le passé pour PureBasic a toujours été dans le plus pure esprit partage.

Oui, j'aimerais aussi faire plus dans le "libre". Mais il ne faut pas porter non plus ce modèle au pinacle. L'autre, "l'affreux" a quand même une certaine utilité : savez-vous combien nous recevons par mois de CV de jeunes diplômés en informatique qui voudraient vivre de leur savoir (et souvent de leur passion) ?

L'un n'empêche pas l'autre, heureusement.

Cordialement. Gilles

selzig a écrit : C'est le ton général de votre forum qui me surprend un peu, un peu hautain je trouve

le Forum ? ou certaines reponses qui t'ont été faites ! ?

dans ce deuxième cas , ça engage l'auteur de la réponse , pas forcement tout le Forum

N'est - il - pas ?

Progi1984 a écrit :N'est - il - pas ?

oui , il est , il est !


(ref : Asterix chez les bretons)

Dobro a écrit :

Progi1984 a écrit :N'est - il - pas ?

oui , il est , il est !


(ref : Asterix chez les bretons)

Ce mec a une culture littéraire qui m'étonnera toujours.
C'est une sorte de mélange de Bernard PIVOT, de Maître Capello (sans le nourrain), et de Jean d'Ormesson du forum PureBasic!

Enjeux Les échos, n°238 Septembre 2007, page 5

"Rarement crise financière aura été plus prévisible que celle qui a débuté cet été et qui menace d'amputer la croissance mondiale en 2008. C'est une bulle mondiale sans précédent - Les niveaux d'endettement sont bien plus élevés aujourd'hui qu'en Octobre 1929, à la veille du grand krach - [...]"

@Ollivier
Pourquoi post-tu çà je vois pas trop.