Le but est de ne pas perdre de vue le premier outil permettant de dialoguer avec la machine en même temps que l'édition de code source.
Et le but de it-edit et de me simplifier, la vie au maximum.
Comme avant it-edit, je travaillais avec kate et un terminal ouvert, j'ai décider de réunir les deux en un outil: sans devoir switcher de l'éditeur vers le terminal a chaque fois.
Je pense que même en développement:
Le processus de compilation doit être automatiser avec un Makefile.
Et non en configurant des projets avec des IDE.
Afin de savoir ce que l'on fait.
Créer un un Makefile pour un projet ne revient pas a configurer un IDE.
:note:
Vous pourrez jeter un oeil a mon générateur de projet qui ne fait guère plus que de générer un Makefile
"according to your settings":
le programme mk-project, qui n'est pas encore mûre pour en parler vraiment aux autre, même si je le mentionne içi.
Car il ne suffit pas d'appuyer sur un bouton pour, par exemple, choisir les options de compilation (enable/disable -O2 dans code bock), les IDE permette certes de tester différentes options rapidement comme tester le -O1 puis -O2 puis -O3 et cela est pratique a condition de savoir ce que l'on fait.
Mais savez vous ce que font les options d'optimisations réellement, y a de quoi se poser la question est-ce la peine de faire de l'optimisation dans la rédaction du code ?
Ces IDE peuvent être dangereux en termes de savoir, oublié par des surcouches, car il suffit d'activer telle ou telle option sans savoir a se soucier ce que cette option fait réellement a son programme.
Alors finalement l'on se crée un template une fois que l'on a sa formule mais si l'on vous vous retrouvez face a un terminal vous ne saurez limite même pas ce que c'est, nie la ou les lignes a taper pour compiler votre programme.
Ce n'est pas parce que j'automatise des taches grâce a make que je ne sais pas ce que je fait !
C'est le même principe que de se protéger contre soit même en C++ avec par exemple les smart pointers.
Chose que je trouve débile, se protéger contre soit même, comme si l'on ne savait qu'il faut libérer la mémoire que l'on a demander au heap.
Chose que l'on risque d'oublier a force d'utiliser constamment des smart pointers...
i.e si l'on débute avec constamment avec des smart pointers, il y des chances pour que cette lacune s'installe réellement, sans déconner !
Même si les smart pointers permettent d'éviter des memory leaks involontaires, je ne veut pas d'un objet encapsulant un pointeur plus lourd que la taille d'une adresse mémoire mais d'un pointeur brute rapide est puissant. vive get(), libéré.
Alors pour reprendre l'exemple du win d'au dessus qui est un étudiant/débutant:
que leur apprendre ?
Soit: que il faut ajouter le switch -mwindows pour masquer la console Windows au lancement du programme.
Soit: de compiler son projet "code-block" en mode "release".
La réponse est bien sur les deux,
mais que vont réellement retenir les étudiants ?
Le savoir ou le bouton pour compiler en mode "release".
En parlant de code-block il n'intègre pas de terminal mais il lance un xterm en mode debug.
Quand aux éditeurs de texte ou il est optionnellement possible d'intégrer un terminal avec certains, mais il le font de bien piètre manière je trouve pour celui qui a besoin d'un terminal dans son éditeur de nos jours (ce n'est pas pratique l'endroit et la taille du terminal, etc...), car c'est secondaires ce vieux truc de terminal intégrées.
J'ai implémenter ce vieux concept a ma sauce, car j'ai un coté rétro pour ce qui est du savoir.
Un port série réel n'existe quasiment plus aujourd'hui mais combien de moyens de connexion émulent le fonctionnement d'une connexion série nos jours: USB non ?
[^] # Re: Désolé dépêche refuser, donc auto-correction D.I.Y dans le journal.
Posté par Linuxator . En réponse au journal Changement subite du comportement de it-edit ?. Évalué à 1.
Le but est de ne pas perdre de vue
le premier outil permettant de dialoguer avec la machineen même temps que l'édition de code source.Et le but de it-edit et de me simplifier, la vie au maximum.
Comme avant it-edit, je travaillais avec kate et un terminal ouvert, j'ai décider de réunir les deux en un outil: sans devoir switcher de l'éditeur vers le terminal a chaque fois.
Je pense que même en développement:
Le processus de compilation doit être automatiser avec un Makefile.Et non en configurant des projets avec des IDE.
Afin de savoir ce que l'on fait.
Créer un un
Makefilepour un projet ne revient pas a configurer un IDE.:note:
Vous pourrez jeter un oeil a mon générateur de projet qui ne fait guère plus que de générer un
Makefile"according to your settings":
le programme mk-project, qui n'est pas encore mûre pour en parler vraiment aux autre, même si je le mentionne içi.
Car il ne suffit pas d'appuyer sur un bouton pour, par exemple, choisir les options de compilation (enable/disable -O2 dans code bock), les IDE permette certes de tester différentes options rapidement comme tester le -O1 puis -O2 puis -O3 et cela est pratique a condition de savoir ce que l'on fait.
Mais savez vous ce que font les options d'optimisations réellement, y a de quoi se poser la question
est-ce la peine de faire de l'optimisation dans la rédaction du code ?Ces IDE peuvent être dangereux en termes de savoir, oublié par des surcouches, car il suffit d'activer telle ou telle option sans savoir a se soucier ce que cette option fait réellement a son programme.
Alors finalement l'on se crée un template une fois que l'on a sa formule mais si l'on vous vous retrouvez face a un terminal vous ne saurez limite même pas ce que c'est, nie la ou les lignes a taper pour compiler votre programme.
Ce n'est pas parce que j'automatise des taches grâce a make que je ne sais pas ce que je fait !
C'est le même principe que de se protéger contre soit même en C++ avec par exemple les smart pointers.
Chose que je trouve débile, se protéger contre soit même, comme si l'on ne savait qu'il faut libérer la mémoire que l'on a demander au heap.
Chose que l'on risque d'oublier a force d'utiliser constamment des smart pointers...
i.e si l'on débute avec constamment avec des smart pointers, il y des chances pour que cette lacune s'installe réellement, sans déconner !
Même si les smart pointers permettent d'éviter des memory leaks involontaires, je ne veut pas d'un objet encapsulant un pointeur plus lourd que la taille d'une adresse mémoire mais d'un pointeur brute rapide est puissant. vive get(), libéré.
Alors pour reprendre l'exemple du win d'au dessus qui est un étudiant/débutant:
que leur apprendre ?
Soit: que il faut ajouter le switch -mwindows pour masquer la console Windows au lancement du programme.
Soit: de compiler son projet "code-block" en mode "release".
La réponse est bien sur les deux,
mais que vont réellement retenir les étudiants ?
Le savoir ou le bouton pour compiler en mode "release".
En parlant de code-block il n'intègre pas de terminal mais il lance un xterm en mode debug.
Quand aux éditeurs de texte ou il est optionnellement possible d'intégrer un terminal avec certains, mais il le font de bien piètre manière je trouve pour celui qui a besoin d'un terminal dans son éditeur de nos jours (ce n'est pas pratique l'endroit et la taille du terminal, etc...), car c'est secondaires ce vieux truc de terminal intégrées.
J'ai implémenter ce vieux concept a ma sauce, car j'ai un coté rétro pour ce qui est du savoir.
Un port série réel n'existe quasiment plus aujourd'hui mais combien de moyens de connexion émulent le fonctionnement d'une connexion série nos jours: USB non ?