vmagnin a écrit 436 commentaires

Effectivement, gtk-fortran n'utilise pas du tout la programmation objet du Fortran moderne. Je ne sais pas ce qu'il serait possible de faire avec GTK et je ne sais pas quel est le niveau de complexité que ça impliquerait.

Merci pour le lien sur les Grammar. Je jetterai un oeil à ce concept !

Les expressions régulières/rationnelles sont effectivement une des plus belles choses que j'ai découvertes en informatique depuis une douzaine d'années, avec les mécanismes des shells Unix. Je me suis longtemps contenté des wildcards du DOS…

C'est sûr que que ce serait plus rigoureux et robuste d'utiliser l'introspection. Je m'y étais intéressé dans la première année du projet :
https://github.com/vmagnin/gtk-fortran/issues/27

Apparemment, à l'époque dans les choses qui m'avaient bloquées, il y avait un manque de documentation et le fait qu'il n'y avait pas de fichier gir pour la librairie Cairo qui était importante pour le graphisme dans le projet (ou peut-être que je ne l'avait pas trouvé).

Les choses se sont probablement améliorées depuis :
https://gi.readthedocs.io/en/latest/

Sur le long terme, ça pourrait être une option de se ré-intéresser à ce sujet. Pour l'instant le parser est très satisfaisant, mais c'est effectivement chatouilleux. Le problème des expressions régulières n'est pas tant de les écrire pour récupérer quelque chose de précis, mais de gérer les petites variations de conventions de codage d'un fichier à l'autre (on parse 757 fichiers dans GTK 3.24.8).

C'est à peu près ce que dit Claire L. Evans : « Quand l’informatique a pris de la valeur, les femmes ont dû quitter le terrain » :
https://www.lemonde.fr/pixels/article/2019/03/23/claire-l-evans-quand-l-informatique-a-pris-de-la-valeur-les-femmes-ont-du-quitter-le-terrain_5440125_4408996.html

Bonjour mino60,

si je comprends bien, tu voudrais écrire du python dans un script bash. Voici une solution :

#!/bin/bash

echo "#!/usr/bin/env python3
print('Je suis un serpent')
exit()" > script.py

chmod +x script.py

./script.py

exit 0

Et le résultat :

$ ./essai.sh
Je suis un serpent
$ 

La fatigue…

A noter que les barrettes actuelles me semblent plutôt fiables.

Bonjour,

personnellement, je prendrais du moyen de gamme, dans une marque connue : 20-25 € me paraît raisonnable. 7 € j'éviterais…

Après bien sûr ça dépend de l'usage. Les critères principaux pour la RAM sont la vitesse (accès, transfert…), la fiabilité et le prix. Par exemple, si c'est pour faire de la bureautique, la vitesse importe peu. Si l'ordinateur a déjà un certain âge, il faut de la RAM raisonnablement fiable (elle n'a pas besoin de durer 12 ans). Donc un prix moyen. Et ça suffira à rendre l'ordinateur plus agréable à utiliser et à prolonger sa durée d'usage (donc c'est plus écologique que d'en changer).

Si c'est toujours sous Lubuntu, 4 Go sera très suffisant pour être à l'aise.

A noter que les barrettes actuelles me semble plutôt fiable. Ca fait quand même pas mal d'années que je n'ai pas eu de problème de barrette mémoire bien que j'utilise pas mal d'ordis.

Je viens d'installer le paquet flang-7 sur une Debian Sid. Ca marche bien sur les petits programmes que j'ai essayés. Par contre avec mon projet gtk-fortran, il compile (longuement) quelques fichiers puis affiche des erreurs :

F90-S-0087-Non-constant expression where constant expression required (/home/osboxes/gtk-fortran/src/gtkenums-auto.f90: 355)
...
C'est un fichier qui contient des énumérateurs Fortran dont la valeur est pour quelques-uns définie par une expression:

enum, bind(c) !GModuleFlags
enumerator :: G_MODULE_BIND_LAZY = ISHFTC(1, 0)
enumerator :: G_MODULE_BIND_LOCAL = ISHFTC(1, 1)
enumerator :: G_MODULE_BIND_MASK = INT(z'03')
end enum
D'après la norme Fortran (>=2003), on peut utiliser des scalar-int-constant-expr pour définir les énumérateurs. Et une telle expression est définie ainsi :

A constant expression is an expression with limitations that make it suitable for use as initializer, or named constant. It is an expression in which each operation is intrinsic…

Les fonctions ISHFTC() et INT() sont pourtant des fonctions intrinsèques du langage. Avec gfortran, ça passe sans problème. Avec ifort 2015 également.

J'imagine qu'il me faudra attendre un peu que le nouveau compilateur f18 soit opérationnel et disponible sous forme de paquet.

Merci pour ce thread très intéressant. Je ne savais pas que NVIDIA était derrière Flang, et je n'avais pas vu ce nouveau projet f18 de réécriture de Flang en C++. Avec pour but de faire partie du projet LLVM à côté de Clang.

Merci beaucoup pour l'info,
effectivement, j'ai une machine virtuelle avec une Debian Sid et je vois un paquet :

flang-7/unstable 20181226-2 amd64
Fortran compiler front-end for LLVM

Je testerai la semaine prochaine.

Bonjour,
si j'ai bien compris LLVM est une infrastructure pour construire des compilateurs et Clang le compilateur C correspondant. En ce moment, je commence à m'intéresser au compilateur Fortran Flang qui utilise LLVM (même si je n'ai pas réussi à l'installer pour l'instant avec le gestionnaire de paquets Spack dont ils parlent sur leur site).

• Quels sont les rapports entre Flang et LLVM: est-ce qu'il fait partie du projet LLVM ou est-ce un projet à part ?
• Quelqu'un a-t-il déjà utilisé Flang ? Qu'en pensez-vous ?

J'utilise depuis des années gfortran qui fait partie de GCC et j'en suis très content. Mais c'est toujours intéressant de compiler un code sur plusieurs compilateurs, ça permet parfois de détecter des anomalies.