Forum

salut, j'ouvre ce post suite à la conversation sur les vins lancée par pg80 et la réponse de Jybz.

pour commencer, un peu de philo afin de préciser le vocabulaire:

« L’idée, c’est l’unité qui se transforme en pluralité par le moyen de l’espace et du temps, forme de notre aperception intuitive ;
le concept au contraire, c’est l’unité extraite de la pluralité, au moyen de l’abstraction qui est un procédé de notre entendement ;

le concept peut être appelé – unitas post rem - , l’idée – unitas ante rem -.

Indiquons enfin une comparaison qui exprime bien la différence entre concept et idée :

le concept ressemble à un récipient inanimé ; ce qu’on y dépose reste bien placé dans le même ordre ; mais on n’en peut tirer ( par les jugements analytiques ) rien de plus que ce que l’on y a mis ( par la réflexion synthétique ) ;

l’idée, au contraire, révèle à celui qui l’a conçue des représentations toutes nouvelles au point de vue du concept du même nom, elle est comme un organisme vivant, croissant et prolifique, capable en un mot de produire ce que l’on n’y a pas introduit.

Arthur Schopenhauer


Outre la clarification de vocabulaire entre "concept" et "idée", je trouve ce texte parfait pour introduire mon sujet.

il me semble en effet, que la distinction faite ici peut s'appliquer;
l'univers du "clicodrome" soit le GUI, à les caractéristiques du concept : un récipient inanimé dans lequel on retrouve tous ce que les concepteurs y ont mis, dans le bon ordre;
et la console, au contraire, c'est l'espace vivant et prolifique, capable de produire ce que l'on n'y a pas introduit.

maintenant, si on fait le lien avec la notion de liberté, c'est sûr que dans l'interface graphique, c'est plutôt limité, tandis qu'avec la ligne de commande, ça repousse les limites ( à la liberté) beaucoup plus loin.

le problème avec la ligne de commande, c'est qu'il faut avoir des idées ...

WOuaou, c'est beau. J'ai besoin de quelques temps pour m'approprier ce nouveau paradigme idée/concept CLI/GUI, merci !

Je comprends que je suis dans le vrai et dans le vivant en utilisant la console !

Ou, comme l'aurait dit René, « Codigo ergo sum » (« Je code, donc je suis. »)

Peut-être aussi, qu'il y a un décalage trop important entre ceux qui code et la société, par exemple, même certains membre de ma famille qui sont bon en informatique (au point de savoir utiliser ./configure make make install), me coupent net quand je pars dans une conversation sur du code, alors avec ceux qui n'ont aucune idée du code, c'est pas un sujet tabou, mais ça ne restera que des monologues, impossible d'échanger sur ce sujet.

Ce sujet est alors devenu exclusivement réservé aux camarades de classe qui ont plaisir à coder, ceux n'en n'ayant pas le plaisir sentiront un couteau remuer dans une plaie, celle des exams et des notes difficiles.

Bien, qui reste-il pour en discuter ? D'autres programmeurs, mais... Entre python, C, ASM, C++, C#, java, javascript, perl (15) (très aimé chez mageia), perl 16, html (oui, pas de prog mais texte structuré), shell (bash, zsh, sh), css, php, mysql (oui ce n'est pas un langage de prog, mais de requêtes), rust, pascal, ... Il y en a d'autre encore !

Voilà, donc sur l'ensemble de la population, une infime partie est apte à discuté de programmation, et cette partie est encore divisée entre les langages ! Encore je généralise en prenant mon cas pour exemple, mais je ne peux que C, shell, java et python (je ne compte pas l'ASM, je peux, mais il me faut le bouquin du jeu d'instruction de µP pour réaliser une prog, je ne connais pas par cœur). Je ne peux pas discuter avec quelqu'un qui fait du javascript/php, car les paradigmes de programmation sont différents, la syntaxe est différente, etc. Et enfin, on peut encore séparer cette portion de portion de la population avec des compétences sur des domaines différents.
Exemple : quelqu'un qui fait du C pour du firmware d'un microcontroleur a des compétences différente que celui qui fait du C pour un serveur d'un chat (je pense notamment aux serveur IRC de freenode, https://github.com/freenode/ircd-seven/tree/master/src ), dans un cas, ou trouvera beaucoup d'opération binaires sur des registres (µC) (charger une valeur dans un registre, enclencher un processus électronique en plaçant un bit à 1 dans un registre, se retrouver dans une interruption pour le traitement du résultat), dans l'autre cas ou trouvera beaucoup d'opérations sur des chaines de caractères (serveur de chat, donc des messages, des pseudonymes, des noms de salons, tel pseudonyme, avec tels droits, écrit dans ce salon, dont tant d'autre pseudonymes sont inscrit, le message doit être redistribué). Donc après la langue de programmation, il y a le domaine d'activité. De plus que les outils peuvent être différents, l'utilisations de systèmes d'exploitation en temps réel (FreeRTOS, µC/OS II, ...) ou des librairies pour discuter avec des serveurs comme les API pour les réseaux sociaux.

Parallèlement, le français écrit bien avec des lettres latines, comme les polonais, mais on ne se comprend pas. Les grecs, les russes, alphabet cyrilliques, les perses, les égyptiens, alphabet arabe, mais ne se comprennent pas non plus. On peut partager des mêmes langues écrites, mais sans se comprendre. Si l'exemple est trop tiré par les cheveux, dites vous que je comprends vieilles personnes du nord de france, mais je ne comprends pas un mot des vieux toulousains, l'accent est trop différent, même si la syntaxe et les mots sont les mêmes. Ou encore, que j'estime m'exprimer correctement en français, pourtant, je ne comprends pas les textes de lois remplis de double négations, de mots polysémiques.

Peut-on là encore dire qu'on partage la même langue, mais... pas la même culture ?

tu as raison, tout est question de culture;
mais c'est en la diffusant qu'on la fait vivre;

la culture, c'est souvent lié à une pratique;

c'est ce qui m'a le plus perturbé quand j'ai démarré avec linux : j'avais une culture du "pascal" et j'entrais dans une autre culture, celle du C et C++;
exemple de pratique différente : en pascal je n'ai jamais démarré une session d'édition vide, mais je suis toujours parti d'un "template" approprié;
en C, c'est le contraire, je pars toujours d'un fichier vide;

donc, oui, suivant les langages utilisés et ce qu'on en fait, ça engendre des cultures différentes;
il y a tout de même un point commun, c'est le "bash" que l'on utilise tous plus ou moins;

un autre sujet qui pourrait être "interdisciplinaire", c'est la question des fichiers .csv;
ça semble être un standard de communication;
localc , postgresql, python, R, tout le monde sait lire des fichiers .csv;

outre le fait que du point de vue de la sécurité ce n'est pas idéal, de manipuler et communiquer des données sous forme texte, en C c'est pas pratique;
1ére question :
existe-t-il une librairie pour lire et écrire facilement des fichiers .csv en C;

2ème question, une sorte de corrolaire:
lorsqu'on a un fichier écrit en C, séquentiel, de "struct" qui sont en fait les data des nœuds d'une data structure que l'on a sauvegardé, comment fait-on pour faire comprendre à python de lire ce fichier; j'ai suivi quelques vidéos sur cython, mais j'ai pas trouvé cela, a aucun moment j'ai vu comment faire des "fread" en python;

la raison à tous cela, c'est que les data récupérées, sont quasiment jamais propres, au sens de la normalisation pour la sgbdr, et que s'il s'agit juste de "slicer" un peu avec python, c'est Ok, mais si on veut produire des données un peu plus sophistiquées pour alimenter la base de données, faut passer par du C; en ce format .csv me fait suer, je préferrais communiquer antre C, python et postgresql autrement que par des .csv, mais plutôt avec des fichiers de "struct" C .

Restons mesurés marc-andré. Sujet "interdisciplinaire", faut pas exagérer, tout juste un problème de définition de fichier inter-programmes.

Les fichiers csv. En C, j'imagine que ça ça doit se faire finger in the nose (une 'tite boucle sur les lignes, une 'tite boucle sur les virgules). Le problème, c'est surtout que le csv n'a pas de réelle spécification, et qu'il faut connaître la structure de ce que l'on lit pour en faire quoique ce soit. Et le problème est le même quelque soit le langage.
Quant à la sécurité, si c'est en interne, ce n'est pas un problème. Si ça transite à l'extérieur, c'est le même problème que les messages, il faut crypter.

Pas la peine, ce n'est pas si compliqué, j'ai cherché, on trouve tout de suite sur ternet : http://public.iutenligne.net/informatique/algorithme-et-programmation/priou/LangageC/1762_lecture_dun_fichier_csv_dans_un_programme_en_langage_c.html

Le type "struc" dont tu parles est spécifique à C (d'après ce que j'ai vu), python ne peut donc pas l'interpréter implicitement, il faut forcément lui expliciter.

Aujourd'hui, il existe le XML comme format avancé pour échanger des données. Il présente l'avantage d'une structuration forte avec un format libre et permet à n'importe quel langage disposant de l'API DOM de l'assimiler. Et d'un certain nombre d'utilitaires et de langages pour le manipuler. Mais, tout n'est pas résolu pour autant, il faut forcément s'entendre sur le vocabulaire des balises qui structurent les documents échangés...

Je ne sais pas ce que c'est que tes données mais tout dépend de leur volume et de leur qualité. Et, par définition, les SGBD sont suceptibles. Si le volume n'est pas important et la qualité très faible, il est peut-être préférable d'envisager un traitement de nettoyage ou de pré-traitement humain. Ou de réseau neuronal, mais ça, je n'ai jamais fait .

Édité par magnux77 Le 05/04/2019 à 19h16

merci pour le lien, c'est toujours intéressant de voir comment d'autres ont fait;
chercher sur internet, c'est une chose que je ne sais pas bien faire, je ne trouve jamais ce que je cherche, c'est désespérant!

oui, en C, c'est des boucles pénibles à écrire pour lire un csv;
XML, je vais regarder un peu;

J'ai utilisé "lire csv langage c".


Ah ! Si tu n'aimes pas les boucles, alors arrête la programmation algorithmique ! Pour lire des fichiers, en algo, il n'y a pas trop le choix.

Le fichier csv, c'est juste "comma separated value", c'est juste un fichier texte avec des valeurs séparées par une virgule.

En C, bash, python, tous, ça se lit ligne par ligne, éléments par éléments avec la virgule.
Tu peux avoir une ligne d'entête. En fait, le fichier, c'est toi qui donne son format.

La "struct"ure en C, c'est toi qui la défini. Ensuite, j'espère que la structure est un tableau ou contient un tableau (peut simplement être un pointeur), et écrire les éléments dans un CSV, ligne par ligne, éléments par éléments de la ligne.

Si le CSV ne te plait pas, trop "tableau" (car c'est avant tout utilisé pour les tableurs (a mon avis), et être lisible en texte), tu as aussi le JSON.
En C, tu as une librairie cJSON qui fonctionne assez bien, je l'utilise dans des projets embarqué, donc statique, mais il me semble qu'il est possible de choisir entre statique et dynamique. Pour python, je ne sais pas quel lib existe, mais surement plusieurs ! C'est aussi un fichier texte, mais structuré, les éléments ne sont pas nécessairement pareil comme les valeurs d'un tableau. Voir l'exemple de wiki : https://fr.wikipedia.org/wiki/JavaScript_Object_Notation#Exemple

Bonjour,
Pour la lecture des fichiers CSV en python, tu disposes d'une bibliothèque dédiée : https://docs.python.org/fr/3/library/csv.html
En autre format d'échange, si les besoins sont simples, même avec une structure complexe, il existe le format YAML, plus simple que le XML. Et ici aussi, on trouve une bibliothèque pour le lire en Python. https://pyyaml.org/wiki/PyYAMLDocumentation

bon, bien voilà une conversation intéressante.
du coup, grâce au lien de magnus77, j'y ai passé la soirée, pour essayer de faire un truc assez propre;
ma première version pour lire du csv en C était moche;
mais le truc que tu fais en python avec une ligne de code, en C, tu y passes la soirée!
c'est d'autant idiot que dans chaque programme par lequel ces donnés vont passer, de lo-calc à python, postgresql ou C, chaque fois, c'est leur aspect numérique qui nous intéresse, car se sont des "valeurs" et pas du texte, mais faut se taper ces conversions en csv;
bon, et puis, même plus élégant, c'est difficile de faire un truc générique en C; en fait, il faut réécrire une routine pour chaque fichiers csv différents;

dans une vidéo, j'ai vu un exemple d'appel en cython de fonction C standard :
- de strlen de "string.h" et de time et localtime de "time.h"
il faut faire un wrapper qui est appelable ensuite depuis python;
mais j'ai pas vu d'exemple avec "stdio.h", j'imagine que c'est plus complexe, car il faut enchaîner le fopen, le fread et le fclose, et donc faire un wrapper pour chacune, et aussi un pour la structure de donnée;
je vais creuser la question, car j'aimerai bien lire en python des fichiers C binaires.

Je ne sais pas vers quel but tu te déplaces, mais je ne suis pas certain que tu choisisses le chemin le plus confortable.
Tu l'auras compris, je suis un aficionados de Python.

Pour cela, il semble n'y avoir aucun souci :
https://docs.python.org/3/library/struct.html#struct.unpack
Évidemment, pour ce type de fichiers, il faut connaître l'ordre et la taille de chaque champs, et également l'ordre des octets qui ne semble pas standard.
Ici, il y a une discussion pour des formats binaires Fortran, mais je pense que c'est transposable au C. Il y a aussi une proposition avec numpy.

Lire des fichiers C binaires ?
Désolé je ne comprends pas.
Des fichiers C, sont des fichiers textes, lisible en mode texte.
Les structures, une fois compilé dans un programme binaires, ne sont plus que des pointeurs sur des valeurs.