Le topic de la programmation: Et envoyez des sioux!

[Tramb]

Je parle de la standardisation de Common Lisp et de la naissance d'un outil industriel pratique

[Helix]

Ok, on est d'accord donc.

[GrandFather]

Quand, durant un autre siècle, j'avais démarré le dév Lisp m'avait laissé de marbre, par contre j'avais vraiment accroché avec Prolog, sans doute inspiré par cet aphorisme d'Alphonse Allais : « la logique mène à tout, à condition d'en sortir ». Le langage a eu son heure de gloire durant les années 80, avec l'engouement pour les systèmes experts et les débuts de l'I.A.

Les japonais avaient même sorti des puces dédiées à la logique des prédicats, mais leur échec commercial a aussi sonné le glas du langage...

[Møgluglu]

Merci du partage et de l'anecdote

De rien. L'anecdote ici c'est que le microprocesseur LISP n'avait pas d'ALU. Pas besoin d'addition pour faire CONS, CAR et CDR, il suffit de savoir ajouter 1 à une adresse (ou passer à l'adresse suivante, selon une séquence arbitraire). Si on veut des entiers, on construit l'arithmétique de Peano par dessus avec des listes.

Parenthèse hardware :
Le cours "MIT'78" de Lynn Conway était un des éléments clés de ce qu'on a appelé la révolution VLSI : des méthodes de conception de circuits radicalement simplifiées qui ont permis de passer à l'échelle à des circuits à des millions de transistors, et ouvert la voie au modèle fabless-foundry moderne, par opposition aux quelques géants du semiconducteur dont les designers gardent jalousement leurs secrets des années 1970.
Plutôt que de défendre son point de vue face à des industriels franchement sceptiques, Conway a écrit un livre de cours en collaboration avec un académique reconnu (Mead), et enseigné ses nouvelles méthodes en laissant croire aux étudiants qu'ils apprenaient les pratiques standard de l'industrie. Puis elle a laissé les résultats parler d'eux-même, et les étudiants ont naturellement appliqué ce qu'ils ont appris dans l'industrie. Vers 2000, on a aussi découvert qu'elle avait inventé le superscalaire out-of-order en 1965 dans une vie antérieure, mais c'est une autre histoire.

[ducon]

C'était bien du Lisp nature. Et pour moi c'est l'anagramme de slip...

Et de pils.

[Helix]

C'était bien du Lisp nature. Et pour moi c'est l'anagramme de slip...

Et de pils.

Ça fait deux fêtes !

[William Vaurien]

Pour en revenir à des préoccupations plus terre à terre, vous auriez des conseils pour une lib cgi-bin en C ?
Dans notre entreprise de découpage et de mise au placard de la vieille application en C nous sommes en train de la rendre REST service compatible:

Elle peut maintenant faire des appels à un 'coeur' business via des appels REST, ce qui va limiter les nouveaux dev à la couche UI.

Maintenant nous voulons pouvoir aller dans l'autre sens: pouvoir appeler les dizaines de fonctions métier que nous n'allons pas ré-écrire de suite et pouvoir les utiliser dans les nouvelles applications.

Pour le moment cette vieille app utilise un truc proprio nommé "Prolifics Panther"
(attention je vends du rêve) :


Ce truc prend en charge les requête HTTP au travers d'un cgi-bin, mais c'est une boite noire et impose plein de limitations qui font que je veux le bazarder et passer sur un un cgi-bin ouvert pour créer ce point d'accès REST.

Maintenant j'ai fait le tour de différents site web avec la recherche 'C cgi-bin lib' et je trouve que c'est un peu la misère: toutes les libs semblent obsolètes et peu maintenues, rien ne donne vraiment envie...

Je me demande si passer par un frontal en php ou python ne serait pas plus simple: un truc qui ferait le post-processing de la requête (filtrage des headers, sécurité, mise en forme des paramètres) et qui ensuite appellerait le binaire C donnant accès à l'application.

Je pensais à PHP ou python pour ne pas devoir gérer/monitorer un serveur en plus de ce que nous avons déjà.

Vous feriez quoi ?

[yuushiro]

Dans un ancien projet, j'avais du code VB6 qui devait appeler des webservices SOAP, j'avais fait ça dans une DLL en C/C++.
Je t'avoue ne pas savoir si c'était la meilleure solution, mais en tout cas ça faisait le job.

[FB74]

Bouquins orientés programmation jeux:
https://www.humblebundle.com/books/g...elopment-books

[vectra]

so much underrated quote

[deathdigger]

Pour en revenir à des préoccupations plus terre à terre, vous auriez des conseils pour une lib cgi-bin en C ?
Dans notre entreprise de découpage et de mise au placard de la vieille application en C nous sommes en train de la rendre REST service compatible:

Elle peut maintenant faire des appels à un 'coeur' business via des appels REST, ce qui va limiter les nouveaux dev à la couche UI.

Maintenant nous voulons pouvoir aller dans l'autre sens: pouvoir appeler les dizaines de fonctions métier que nous n'allons pas ré-écrire de suite et pouvoir les utiliser dans les nouvelles applications.

Pour le moment cette vieille app utilise un truc proprio nommé "Prolifics Panther"
(attention je vends du rêve) :
http://docs.prolifics.com/panther/ht...s/ovinheri.gif

Ce truc prend en charge les requête HTTP au travers d'un cgi-bin, mais c'est une boite noire et impose plein de limitations qui font que je veux le bazarder et passer sur un un cgi-bin ouvert pour créer ce point d'accès REST.

Maintenant j'ai fait le tour de différents site web avec la recherche 'C cgi-bin lib' et je trouve que c'est un peu la misère: toutes les libs semblent obsolètes et peu maintenues, rien ne donne vraiment envie...

Je me demande si passer par un frontal en php ou python ne serait pas plus simple: un truc qui ferait le post-processing de la requête (filtrage des headers, sécurité, mise en forme des paramètres) et qui ensuite appellerait le binaire C donnant accès à l'application.

Je pensais à PHP ou python pour ne pas devoir gérer/monitorer un serveur en plus de ce que nous avons déjà.

Vous feriez quoi ?

En C, ça va être compliqué. Si tu veux le passer en full web, PHP ou asp.Net, sinon, Java (j'ai d'ailleurs vu que Netbeans avait sorti son propre GUI) ou C# (plus WPF que winform, histoire de partir sur un truc récent).

[Nattefrost]

Je me demande si passer par un frontal en php ou python ne serait pas plus simple: un truc qui ferait le post-processing de la requête (filtrage des headers, sécurité, mise en forme des paramètres) et qui ensuite appellerait le binaire C donnant accès à l'application.

Je pensais à PHP ou python pour ne pas devoir gérer/monitorer un serveur en plus de ce que nous avons déjà.

Vous feriez quoi ?

Pour PHP je vais pas pouvoir t'aider mais pour python si je comprend bien la problématique, une application bottle (minimaliste, syntaxe très chouette), flask (core léger mais pluggable dans tous les sens selon les besoins, syntaxe proche de bottle) ou django (gros monolithe avec des plugins spécialisés) doivent faire le job.
A noter qu'y a aussi pyramid mais je le connais moins et a priori niveau features il se trouve entre flask et django.

Perso j'opterai pour flask, ça reste souple et relativement simple dans ton cas d'utilisation : un endpoint http => une fonction dans laquelle tu fais ton traitement et t'appelle le programme C avec les bons flags.

[William Vaurien]

Après discussion avec mon chef adoré, qui n'aime pas quand c'est trop compliqué, les plans ont changés...
quand je lui ai parlé de binding avec du python ou du Java j'ai vu dans son regard que ça n'allait pas être possible.
Du coup on abandonne le REST à ce niveau, ce sera du RESTouille...

On va probablement garder le truc des années 80. Ce truc a un moteur de templates.
Sauf que les templates (du HTML avec des {{placeholders}}) doivent être rassemblées dans une lib compilé en langage proprio, et que les placeholders doivent faire 255 chars max ("au début des années 80 tada dada..."). Les urls des requêtes sont tronquées aussi après 255 chars

Donc pour envoyer des paquets de json c'est un peu limite, sauf en utilisant le truc magique du framework moisi: la grille. Une grille avec un nombre fixe de colonnes et de lignes, il faut pas déconner non plus !

Avec 10 colonnes et 100 (ou 200) lignes on commence à être plus à l'aise.
Donc je vais faire un POC pour automatiser le split de la charge de retour en éléments de 255 max, et voir si le langage de template tient la charge lors du ré-assemblage de la grille en un 'texte' complet.

J'ai l'impression d'être un shadock et de payer pour un virage pris à moitié vers l'an 2000: "Les gars, l'avenir c'est le web ! Ouais faisons une appli web en C !"

- - - Mise à jour - - -

Perso j'opterai pour flask, ça reste souple et relativement simple dans ton cas d'utilisation : un endpoint http => une fonction dans laquelle tu fais ton traitement et t'appelle le programme C avec les bons flags.

Oui je pensais bien à un truc comme ça, voir même en Java car on a déjà tout un paquet de trucs réutilisables pour filtrer les requêtes: un petit Spring boot rest dans un coin qui prépare les paramètres d'appels au C et récupère la réponse à envoyer au client.

Reste à espérer que le rendu de la grille ne soit pas très performant et que je puisse utiliser une telle solution.

[Nattefrost]

- "Oui allô ? Il y a des parasites sur la ligne, ça doit être à cause de la différence de continuum temporel. Ha voila le signal est établi: Ici l'enfer, j'appelle pour vous donner des nouvelles d'un certain William. Il est bien arrivé et il va bien, du moins aussi bien que possible. "

Sans dec' !

[William Vaurien]

Il y a deux postes d'enfer ouverts (sur Genève) MP s'il y a des canards intéressés, plutôt profile backend java avec des notions en C

(je peux juste transmettre le lien pour postuler et éventuellement faire du lobbying si vous passer le filtre impitoyable des RH)

Il faut noter qu'à côté il y a plein de trucs sympa à faire en Java et Vaadin (toute la partie SpringBoot pour le REST, l'appli de remplacement, et tout un tas d'autres trucs).

[deathdigger]

Après discussion avec mon chef adoré, qui n'aime pas quand c'est trop compliqué, les plans ont changés...
quand je lui ai parlé de binding avec du python ou du Java j'ai vu dans son regard que ça n'allait pas être possible.
Du coup on abandonne le REST à ce niveau, ce sera du RESTouille...

On va probablement garder le truc des années 80. Ce truc a un moteur de templates.
Sauf que les templates (du HTML avec des {{placeholders}}) doivent être rassemblées dans une lib compilé en langage proprio, et que les placeholders doivent faire 255 chars max ("au début des années 80 tada dada..."). Les urls des requêtes sont tronquées aussi après 255 chars

Donc pour envoyer des paquets de json c'est un peu limite, sauf en utilisant le truc magique du framework moisi: la grille. Une grille avec un nombre fixe de colonnes et de lignes, il faut pas déconner non plus !

Avec 10 colonnes et 100 (ou 200) lignes on commence à être plus à l'aise.
Donc je vais faire un POC pour automatiser le split de la charge de retour en éléments de 255 max, et voir si le langage de template tient la charge lors du ré-assemblage de la grille en un 'texte' complet.

J'ai l'impression d'être un shadock et de payer pour un virage pris à moitié vers l'an 2000: "Les gars, l'avenir c'est le web ! Ouais faisons une appli web en C !"

- - - Mise à jour - - -



Oui je pensais bien à un truc comme ça, voir même en Java car on a déjà tout un paquet de trucs réutilisables pour filtrer les requêtes: un petit Spring boot rest dans un coin qui prépare les paramètres d'appels au C et récupère la réponse à envoyer au client.

Reste à espérer que le rendu de la grille ne soit pas très performant et que je puisse utiliser une telle solution.

Je n'arrive même pas à comprendre ce que tu dis

[vectra]

J'ai l'impression d'être un shadock et de payer pour un virage pris à moitié vers l'an 2000: "Les gars, l'avenir c'est le web ! Ouais faisons une appli web en C !"
.

En 1997, j'ai un pote qui a fait ça pour sa boîte (CGI, tout ça), et à l'époque c'était apparement une bonne idée.
Il y a plus de 20 ans déjà...

[William Vaurien]

Aujourd'hui problème en prod. En cause une table avec deux colonnes de clé primaire, l'une avec contrainte et l'autre sans
La nouvelle colonne, avec contrainte, a été rajouté il y a peu lors d'une maintenance "parce que dans celle sans contrainte, avait des doublons"

Apparemment les tables les plus antiques de l'appli, datant d'avant la mort du catcheur André Roussimoff, dit André le Géant du fait de son physique plus que remarquable (2m24 pour 235 kgs), c'était courant de ne pas mettre de contrainte (voir elles n'étaient pas implémentées dans les SGBD ?).

Evidemment en l'absence d'une couche unifiée d'accès aux données les centaines de requêtes dispersées dans le code n'ont pas toutes été mises à jour.

- - - Mise à jour - - -

En 1997, j'ai un pote qui a fait ça pour sa boîte (CGI, tout ça), et à l'époque c'était apparement une bonne idée.
Il y a plus de 20 ans déjà...

J'avais fais ça en stage d'IUT aussi vers la même époque. En C également.

J'en avais conclu rapidement que le C n'était pas fait pour le web...

[vectra]

C'était exactement ça aussi. Là, la boîte était contente pour des histoires de perfs, mais faut dire qu'à l'époque, on n'avait pas les mêmes machines qu'aujourd'hui.

[newbie06]

J'en avais conclu rapidement que le C n'était pas fait pour le web...

Sacrilège, C, c'est comme CommonLISP, c'est bon à tout faire ! ... Et comme tout ce qui est bon à tout faire ça n'est idéal nulle part

J'avais écrit un mini serveur Web en C sur une carte embarquée y'a 15 ans, juste pour le fun et parce que je suis un pervers qui ne fait que du C. Au final on a tous fait des Weberies en C, j'ai l'impression.

PS - @ducon si tu passes par là, j'ai mis des accents... Merci à toi pour le rappel à l'ordre.

[ducon]

Rhô, pas de mal.

[William Vaurien]

Sacrilège, C, c'est comme CommonLISP, c'est bon à tout faire !

C'est un peu comme le tournevis et le marteau en bricolage. Tu peux tout faire avec ces deux outils...

Et je ne parlais pas des serveurs et autres browsers aux petits oignons, mais bien des CGI-BIN, les trucs qui servaientt à la base pour traiter le formulaire du 'livre d'or' de toute page web se respectant un tant soit peu en 1997.
Mais quand tu commences à vouloir faire des applications web dynamiques il y a mieux quand même. Comme perl par exemple

Tiens parlons en du perl, nous n'en parlons pas assez par ici, je suis sûr qu'il y a des adeptes planqués dans un coin

[Møgluglu]

Apparemment les tables les plus antiques de l'appli, datant d'avant la mort du catcheur André Roussimoff, dit André le Géant du fait de son physique plus que remarquable (2m24 pour 235 kgs), c'était courant de ne pas mettre de contrainte (voir elles n'étaient pas implémentées dans les SGBD ?).

Pourtant les bons SGBD gèrent les contraintes sur les champs depuis la mort de François Ferdinand, à peu près. Exemple moderne des années 50 : http://www.technikum29.de/en/compute...lating-machine


Noter les deux exemples de requêtes SQL au pied de la tabulatrice.

Avec en plus une trieuse et une interclasseuse comme dans tout SGBD, c'est très simple de détecter les doublons et les mettre de côté. Et ça dépote à plus de 150 cartes à la minute.

[William Vaurien]

ça ressemble a une émanation physique du code sur lequel je travail !

Et le coup des contraintes qui n'existait pas c'est l'excuse de mes collègues. Qui invoquent souvent 'une autre époque' pour justifier tout et son contraire...

[Møgluglu]

Je l'ai surement déjà posté, mais j'aime bien ce tuto sur comment câbler une requête genre SELECT SUM(x) GROUP BY y sur une tabulatrice IBM 403 : http://www.righto.com/2017/04/1950s-...plugboard.html

(Le mode d'emploi d'IBM avec ses illustrations et ses exemples est un trésor aussi : http://bitsavers.org/pdf/ibm/punched...02-403-419.pdf )

Et avec une interclasseuse tu peux faire des jointures.

[Helix]

Ah ah, sympa la correction d'erreurs !
Cela me rappelle mon projet en maîtrise, une grosse carte en wrapping avec deux FPGA.

[William Vaurien]

ça c'est du manuel, autre chose que les man pages des beatnick de Berkeley !
en plus à l'époque il ne pouvait même pas venir poster sur CPC pour raconter comment Jean-Bertrand avait branché les câbles comme un sagouin !

et par analogie, ça me fait aux synthés modulaires avec leurs dizaines de câbles, qui semble quand même plus fun :

[newbie06]

Les synthés modulaires me font penser aux GOTO, c'est tellement beau, j'en pleurerais

[vectra]

BMDJ: j'ai pu m'installer une GTX 660 d'occasion sur ma machine principale au travail
Cette qualitance et rapidance de la troisdé

J'attends encore nos machines de compète commandées pour le projet, mais en attendant, je rustine l'existant...



BMDJ2: première release de mon projet Kanban
Que le temps passe vite...

[vectra]

LDJ: je suis complètement perdu avec la manière dont CLion gère les sauvegardes et synchronisations de configurations (keymaps, ui, etc).

J'avais le plugin de synchro activé, et j'étais content de pouvoir retrouver la config du boulot à la maison, bien que je ne comprenais pas le flux de données.
Je m'étais dit qu'il suffisait de faire une connerie pour qu'elle se propage partout, et c'est à peu près ce qui s'est produit suite à l'effacement involontaire d'un raccourci clavier dont j'avais besoin, au travail.

Je me connecte à la maison sur le CLion windows, que je n'utilise quasi-jamais.
Cool, lui aussi a effacé le raccourci
Je le désenregistre de mon compte Jetbrains: pareil.
Je désinstalle complètement Clion pour le réinstaller en version d'évaluation: ouf, le raccourci d'origine est toujours présent. Je parviens à le faire et à noter en dur le nom de la fonction dont j'avais besoin.

Sauf que de retour au boulot, sans que je n'ait rien fait de particulier, tous mes settings d'ui et d'indentation ont sauté
J'en ai une copie assez ancienne sur fichier .jar, mais quand-même, ça fait chier.

Y'a pas moyen de récupérer un historique des configurations sauvées sur le compte Jetbrains? Ou c'est en mode "j'écrase tout lol, t'as qu'a exporter ta config à la main tous les soirs".
J'ai vu qu'il y a un moyen de mettre sa config sur git avec le plugin, mais là c'est un peu tard.
(Mais tout va bien du côté des touches, merci)