"Léviter" me semble plus proche, car le verbe "voler" implique que le véhicule est actif (entrain de ce déplacer, ou se maintenir en position) alors que atterrire et amerrire implique que le véhicule est passif.
Pas forcément : un ballon dirigeable, par exemple, est un aéronef qui peut être statique. De fait, de la même façon qu'un hydravion « amerrit » parce que ce sont ses flotteurs qui le portent, il est tout-à-fait possible d'envisager un engin spatial sous la forme d'un très grand ballon chargé de gaz et qui vienne se poser sur la haute atmosphère d'un astre quelconque (pourvu qu'il en soit doté, bien sûr).
C'est pour ça qu'au bout d'un moment, on a fini par dire « se poser », tout simplement, ce qui a l'avantage de fonctionner partout. Vive l'interopérabilité.
Si tu veux mais ça ne changera RIEN à ton problème de terminal. Le seul moyen d'empêcher sa fermeture serait de lui envoyer une séquence de code, CSI, OSC ou autres qui lui en donne explicitement l'instruction mais après avoir rapidement parcouru la liste de ces séquences et les sources de xterm hier soir, je n'ai rien vu qui ressemble de près ou de loin à cela.
En revanche, un langage de programmation tel que le C ou le Python te permettrait effectivement d'ouvrir tes propres fenêtres et de les gérer comme tu le souhaites, mais c'est un autre niveau. Sans être vraiment difficile, il faut quand même initialiser un contexte, gérer une boucle principale, etc.
Juste un petit détail : tous les commentaires ici sont munis de leur propre lien « répondre ». Comme Linuxfr.org organise les discussions en arbre, ce qui est à la fois rare et très agréable, c'est mieux si tu veilles à les utiliser. :-)
Pour le reste, il faut savoir que lorsque tu ouvres un terminal, tu n'ouvres pas un shell comme si tu ouvrais une « boîte DOS ». Tu crées en fait un véritable terminal virtuel qui s'exploite à travers une pseudo liaison série. Par défaut, le fait de lancer un xterm provoque automatiquement le lancement d'un shell qui y est relié, mais ce n'est pas nécessairement le cas. Il peut très bien rester passif jusqu'à ce qu'une application externe prenne d'elle-même l'initiative d'envoyer quelque chose vers ce port.
Cela veut dire le terminal X-Term et l'application qui tourne dedans ne sont pas du tout liés entre eux et qu'ils ne communiquent qu'à travers une sorte de pipe bidirectionnel. Donc, tu ne peux pas empêcher le xterm de se refermer puisque c'est une application distincte. Tu peux simplement agir en conséquence.
Bref, quand tu auras D6D d'être de retour dans le présent, fais-moi 6gne.
Bof, de toutes façons, à l'heure d'iPot, ça ne sert plus à rien de rester dans le présent.
D'ailleurs le chrono-télé-travail, c'est l'avenir (ou le passé, enfin c'est pas le présent, quoi).
— Même dans ce fil, reconnais que mon commentaire initial reste beaucoup plus utile que les tiens ;
— Ça fait 13 ans maintenant que je participe à ce forum et je pense modestement avoir rendu service à un certain nombre de personnes ;
— Quitte à poster pour ne rien dire, essaie au moins de relire le fil avant de poster, ça m'évitera d'avoir à me répéter et d'augmenter le niveau de bruit.
C'est ce que je dis : « -b » était approprié mais la man page Linux déclare que c'est une option GNU, et comme l'option n'était pas disponible du tout sur un des mes shells sous OpenBSD, je m'en suis tenu à ce que j'avais écrit et je ne suis pas allé voir si le LS d'AIX proposait la même option. J'aurais dû.
Essaie d'utiliser l'auto-complétion avec la touche TAB. Si le shell est propre, soit il te l'encadrera avec des guillemets ou des « quotes », soit il te mettra des anti-slashes devant les caractères à problème. Sinon, tu peux toujours essayer un « find . -inum | hexdump » ou autre éditeur hexa pour voir s'il te les affiche explicitement.
Pour dépoussiérer une franchise vieillissante, l'éditeur d'un jeu vidéo à décidé de faire subir un viol à son héroïne. […]
La miss est plaquée au sol ; les mains attachées dans le dos (…). […]
Le tollé couve lentement mais sûrement et commence à se propager. Heureusement, c'est la fin du vendredi et le code source du jeu n'est pas disponible.
Par contre, les complotistes vont pouvoir passer le weekend à se demander si des "ultra-féministes" - n'ayons pas peu des mots - ne sont pas en train de
faire un raid dans cet univers informatique qui semblait si tranquille.
D'un autre côté, si c'est Lara Croft qui ligote un type au sol et qui le viole, ça ferait encore plus de ventes, je crois…
Ah, moi c'est l'inverse, c'est le logo « corporate » que je préfère. Et le dernier, au contraire, me fait l'effet d'une application X-Window mal configurée qui se rabattrait sur la fonte par défaut faute de trouver la bonne. Il est bien possible, malgré tout, que ce logo ait fait l'objet d'un vrai travail et que les caractères aient été dessinés individuellement mais, malgré tout, j'ai l'impression de voir la fonte Arial.
Je pense qu'un tel logo se fait en trois minutes sous Excel, carreaux compris. :-)
Il y a des esprits chagrins qui lui reprochent d'avoir mélangé C et C++ mais en réalité, il fait le tour de ce qui est réellement commun aux deux langages jusqu'au chapitre 8, à partir duquel le reste est C++ only. Je le trouve exhaustif, bien structuré, il est en français et, cerise sur le gâteau, en GFDL.
En principe, toutefois, on ne peut rien reprocher à un tel câble s'il n'est pas frappé du logo USB officiel, et il y a effectivement des chances pour qu'il ne le soit pas.
Un journal qui parle de langage C, qui tente de résoudre un cas de figure technique et qui finit en troll politico-sexiste dès le cinquième niveau d'imbrication : pas de doute, on est bien sur DLFP. Tout va bien. :-)
C'est une très bonne chose en soi ! Mais il est important de le faire uniquement pour les cas non définis par la norme ou alors explicitement marqués comme indéfinis par elle. Et en l'occurrence, dans le dernier draft de C99 (n1256.pdf), section § 6.7.2.1, on lit :
6.7.2.1 Structure and union specifiers
…
13
Within a structure object, the non-bit-field members and the units in which bit-fields
reside have addresses that increase in the order in which they are declared. A pointer to a structure object, suitably converted, points to its initial member (or if that member is a
bit-field, then to the unit in which it resides), and vice versa. There may be unnamed
padding within a structure object, but not at its beginning.
Donc, tu es sûr que l'adresse du premier élément d'une structure sera toujours l'adresse de la structure elle-même avec tout compilateur qui se respecte (et qui, surtout, respecte la norme), ce qui permet d'échafauder de façon tout-à-fait officielle et sans warning des montages comme celui de XEvent.
Ça s'explique également par le fait que le padding est généralement utilisé à des fins d'alignement et que, si tu dois aligner un membre, alors tu auras besoin d'aligner de la même façon la structure entière d'une manière générale.
Oui mais justement, même pour quelques octets, c'est plus simple et plus efficace : en fait, la méthode des décalages telle que tu l'as écrite n'est intéressante qu'à partir du moment où ta file tient sur un seul entier (ou que les mots que tu empiles ne sont pas multiples de huit bits). Dès que tu dépasses 8 octets (si l'on considère le cas du long long), alors tu es obligé d'utiliser plusieurs variables consécutives.
De là, soit tu utilises une boucle et un pointeur, ce qui t'oblige à déclarer des variables supplémentaires, soit tu gères manuellement chacun de tes registres en contrôlant à chaque fois s'il est concerné en fonction de la valeur de « count ». Tu gagnes quatre octets de RAM mais tu perds 64 octets de ROM. Ce genre de chose est effectivement à prendre en compte dans le cas de micro-contrôleurs, mais pas sur PC. Pas seulement parce que la quantité de RAM disponible est considérable, mais surtout parce que c'est la même dans les deux cas.
C'est vrai, mais ça te permet en revanche de gérer une file d'une longueur arbitraire sans avoir à décaler tout son contenu. Avec 4 octets, la différence est subtile, avec 4096 elle devient beaucoup plus nette.
Oui, c'est parce que j'ai un raccourci trop rapide, en effet.
Le principe demeure cela dit mais en fait, c'est déjà ce que tu fais à l'entrée. Tu décales à l'empilement et tu vas chercher la bonne position au dépilement. C'est effectivement l'un ou autre.
Oui, mais mon compilateur fait du padding avant le premier membre pour arranger mon explication !
Si tu as trouvé un compilateur qui accepte de faire du copinage, c'est très bien. :-)
Mais autrement, d'une manière générale, la norme empêche les compilateurs de faire cela. Elle te garantit que le premier membre est bien aligné en début de structure et/ou d'union. Ça permet entre autres de faire des unions de structures commençant toutes par un champ « type », par exemple, qui permet de savoir tout de suite ce qu'il y a à l'intérieur, comme avec les XEvents de X-Window.
Quand tu fais ceci, tu récupères l'octet situé à la position « count », mais tu n'effaces pas le contenu de « data », et tu ne tiens pas compte du fait non plus que ta file peut être vide (sauf pour la gestion de « count »). Ça veut dire d'une part que si tu continues à dépiler une file vide, tu vas obtenir à chaque fois la dernière valeur dépilée qui peut être non nulle.
Puisque tu utilises déjà des opérateurs de décalage sur des registres du même format, pourquoi ne t'en sers-tu pas pour décaler directement le contenu de ta file ?
[^] # Re: Complications inutiles
Posté par Obsidian . En réponse au journal Neil Armstrong bronsonisé. Évalué à 3.
Pas forcément : un ballon dirigeable, par exemple, est un aéronef qui peut être statique. De fait, de la même façon qu'un hydravion « amerrit » parce que ce sont ses flotteurs qui le portent, il est tout-à-fait possible d'envisager un engin spatial sous la forme d'un très grand ballon chargé de gaz et qui vienne se poser sur la haute atmosphère d'un astre quelconque (pourvu qu'il en soit doté, bien sûr).
[^] # Re: Complications inutiles
Posté par Obsidian . En réponse au journal Neil Armstrong bronsonisé. Évalué à 10.
« Ætherrir ? » :-)
[^] # Re: Complications inutiles
Posté par Obsidian . En réponse au journal Neil Armstrong bronsonisé. Évalué à 6.
Ça s'appelle « voler », en fait. :-)
[^] # Re: Complications inutiles
Posté par Obsidian . En réponse au journal Neil Armstrong bronsonisé. Évalué à 9.
C'est pour ça qu'au bout d'un moment, on a fini par dire « se poser », tout simplement, ce qui a l'avantage de fonctionner partout. Vive l'interopérabilité.
[^] # Re: Re :
Posté par Obsidian . En réponse au message interception de fermeture de fenêtre. Évalué à 5.
Si tu veux mais ça ne changera RIEN à ton problème de terminal. Le seul moyen d'empêcher sa fermeture serait de lui envoyer une séquence de code, CSI, OSC ou autres qui lui en donne explicitement l'instruction mais après avoir rapidement parcouru la liste de ces séquences et les sources de xterm hier soir, je n'ai rien vu qui ressemble de près ou de loin à cela.
En revanche, un langage de programmation tel que le C ou le Python te permettrait effectivement d'ouvrir tes propres fenêtres et de les gérer comme tu le souhaites, mais c'est un autre niveau. Sans être vraiment difficile, il faut quand même initialiser un contexte, gérer une boucle principale, etc.
[^] # Re: Re :
Posté par Obsidian . En réponse au message interception de fermeture de fenêtre. Évalué à 4.
Juste un petit détail : tous les commentaires ici sont munis de leur propre lien « répondre ». Comme Linuxfr.org organise les discussions en arbre, ce qui est à la fois rare et très agréable, c'est mieux si tu veilles à les utiliser. :-)
Pour le reste, il faut savoir que lorsque tu ouvres un terminal, tu n'ouvres pas un shell comme si tu ouvrais une « boîte DOS ». Tu crées en fait un véritable terminal virtuel qui s'exploite à travers une pseudo liaison série. Par défaut, le fait de lancer un xterm provoque automatiquement le lancement d'un shell qui y est relié, mais ce n'est pas nécessairement le cas. Il peut très bien rester passif jusqu'à ce qu'une application externe prenne d'elle-même l'initiative d'envoyer quelque chose vers ce port.
Cela veut dire le terminal X-Term et l'application qui tourne dedans ne sont pas du tout liés entre eux et qu'ils ne communiquent qu'à travers une sorte de pipe bidirectionnel. Donc, tu ne peux pas empêcher le xterm de se refermer puisque c'est une application distincte. Tu peux simplement agir en conséquence.
[^] # Re: L'auto-hébergement d'amateur, ce fléau
Posté par Obsidian . En réponse au journal Newton Adventure la soluce 1/6: la terrible jungle. Évalué à 2.
Bof, de toutes façons, à l'heure d'iPot, ça ne sert plus à rien de rester dans le présent.
D'ailleurs le chrono-télé-travail, c'est l'avenir (ou le passé, enfin c'est pas le présent, quoi).
→[].
[^] # Re: caractères bizare dans le nom de fichier ?
Posté par Obsidian . En réponse au message Copier un fichier qui "n'existe pas". Évalué à 7.
Bon, puisqu'on est vendredi :
— Même dans ce fil, reconnais que mon commentaire initial reste beaucoup plus utile que les tiens ;
— Ça fait 13 ans maintenant que je participe à ce forum et je pense modestement avoir rendu service à un certain nombre de personnes ;
— Quitte à poster pour ne rien dire, essaie au moins de relire le fil avant de poster, ça m'évitera d'avoir à me répéter et d'augmenter le niveau de bruit.
Allez zou ! →[].
[^] # Re: caractères bizare dans le nom de fichier ?
Posté par Obsidian . En réponse au message Copier un fichier qui "n'existe pas". Évalué à 1.
C'est ce que je dis : « -b » était approprié mais la man page Linux déclare que c'est une option GNU, et comme l'option n'était pas disponible du tout sur un des mes shells sous OpenBSD, je m'en suis tenu à ce que j'avais écrit et je ne suis pas allé voir si le LS d'AIX proposait la même option. J'aurais dû.
[^] # Re: caractères bizare dans le nom de fichier ?
Posté par Obsidian . En réponse au message Copier un fichier qui "n'existe pas". Évalué à 2.
Exact. C'est écrit « OPTIONS GNU » dans les man pages linux et ça ne marche pas sous OpenBSD, donc je n'étais pas allé chercher plus loin.
[^] # Re: caractères bizare dans le nom de fichier ?
Posté par Obsidian . En réponse au message Copier un fichier qui "n'existe pas". Évalué à 4.
Essaie d'utiliser l'auto-complétion avec la touche TAB. Si le shell est propre, soit il te l'encadrera avec des guillemets ou des « quotes », soit il te mettra des anti-slashes devant les caractères à problème. Sinon, tu peux toujours essayer un « find . -inum | hexdump » ou autre éditeur hexa pour voir s'il te les affiche explicitement.
[^] # Re: Ça suffit maintenant
Posté par Obsidian . En réponse au journal Il n'y a pas que le sexisme des linuxiens qui fait débat. Évalué à 3.
Envoie un patch.
# Changeons le thème
Posté par Obsidian . En réponse au journal Il n'y a pas que le sexisme des linuxiens qui fait débat. Évalué à 10.
D'un autre côté, si c'est Lara Croft qui ligote un type au sol et qui le viole, ça ferait encore plus de ventes, je crois…
→[]
[^] # Re: Plagiat évident !!!!!
Posté par Obsidian . En réponse au journal Nouveau logo MS. Évalué à 2.
Ah, moi c'est l'inverse, c'est le logo « corporate » que je préfère. Et le dernier, au contraire, me fait l'effet d'une application X-Window mal configurée qui se rabattrait sur la fonte par défaut faute de trouver la bonne. Il est bien possible, malgré tout, que ce logo ait fait l'objet d'un vrai travail et que les caractères aient été dessinés individuellement mais, malgré tout, j'ai l'impression de voir la fonte Arial.
Je pense qu'un tel logo se fait en trois minutes sous Excel, carreaux compris. :-)
# Par d'erreur…
Posté par Obsidian . En réponse au journal Nouveau logo MS. Évalué à 7.
Moi je trouve que c'est surtout un plagiat de ceci :-)
[^] # Re: Que pensez-vous de…
Posté par Obsidian . En réponse au message Recherche bonne source pour apprendre le C++. Évalué à 3.
Moi j'aime beaucoup le cours de Christian Casteyde : http://casteyde.christian.free.fr/cpp/cours/online/book1.html
Il y a des esprits chagrins qui lui reprochent d'avoir mélangé C et C++ mais en réalité, il fait le tour de ce qui est réellement commun aux deux langages jusqu'au chapitre 8, à partir duquel le reste est C++ only. Je le trouve exhaustif, bien structuré, il est en français et, cerise sur le gâteau, en GFDL.
[^] # Re: cable ordinaire
Posté par Obsidian . En réponse au message Cable micro-usb pour smartphone. Évalué à 5.
En principe, toutefois, on ne peut rien reprocher à un tel câble s'il n'est pas frappé du logo USB officiel, et il y a effectivement des chances pour qu'il ne le soit pas.
[^] # Re: compteur ?
Posté par Obsidian . En réponse au journal Parlons C, parlons pipe !. Évalué à 5.
Un journal qui parle de langage C, qui tente de résoudre un cas de figure technique et qui finit en troll politico-sexiste dès le cinquième niveau d'imbrication : pas de doute, on est bien sur DLFP. Tout va bien. :-)
[^] # Re: ça marche !
Posté par Obsidian . En réponse au journal Et Dieu inventa le soutien gorge !. Évalué à 3.
C'est une très bonne chose en soi ! Mais il est important de le faire uniquement pour les cas non définis par la norme ou alors explicitement marqués comme indéfinis par elle. Et en l'occurrence, dans le dernier draft de C99 (n1256.pdf), section § 6.7.2.1, on lit :
Donc, tu es sûr que l'adresse du premier élément d'une structure sera toujours l'adresse de la structure elle-même avec tout compilateur qui se respecte (et qui, surtout, respecte la norme), ce qui permet d'échafauder de façon tout-à-fait officielle et sans warning des montages comme celui de XEvent.
Ça s'explique également par le fait que le padding est généralement utilisé à des fins d'alignement et que, si tu dois aligner un membre, alors tu auras besoin d'aligner de la même façon la structure entière d'une manière générale.
[^] # Re: compteur ?
Posté par Obsidian . En réponse au journal Parlons C, parlons pipe !. Évalué à 2.
Oui mais justement, même pour quelques octets, c'est plus simple et plus efficace : en fait, la méthode des décalages telle que tu l'as écrite n'est intéressante qu'à partir du moment où ta file tient sur un seul entier (ou que les mots que tu empiles ne sont pas multiples de huit bits). Dès que tu dépasses 8 octets (si l'on considère le cas du long long), alors tu es obligé d'utiliser plusieurs variables consécutives.
De là, soit tu utilises une boucle et un pointeur, ce qui t'oblige à déclarer des variables supplémentaires, soit tu gères manuellement chacun de tes registres en contrôlant à chaque fois s'il est concerné en fonction de la valeur de « count ». Tu gagnes quatre octets de RAM mais tu perds 64 octets de ROM. Ce genre de chose est effectivement à prendre en compte dans le cas de micro-contrôleurs, mais pas sur PC. Pas seulement parce que la quantité de RAM disponible est considérable, mais surtout parce que c'est la même dans les deux cas.
[^] # Re: compteur ?
Posté par Obsidian . En réponse au journal Parlons C, parlons pipe !. Évalué à 1.
C'est vrai, mais ça te permet en revanche de gérer une file d'une longueur arbitraire sans avoir à décaler tout son contenu. Avec 4 octets, la différence est subtile, avec 4096 elle devient beaucoup plus nette.
[^] # Re: Constante invalide
Posté par Obsidian . En réponse au journal Parlons C, parlons pipe !. Évalué à 2.
Oui, c'est parce que j'ai un raccourci trop rapide, en effet.
Le principe demeure cela dit mais en fait, c'est déjà ce que tu fais à l'entrée. Tu décales à l'empilement et tu vas chercher la bonne position au dépilement. C'est effectivement l'un ou autre.
[^] # Re: ça marche !
Posté par Obsidian . En réponse au journal Et Dieu inventa le soutien gorge !. Évalué à 2.
Si tu as trouvé un compilateur qui accepte de faire du copinage, c'est très bien. :-)
Mais autrement, d'une manière générale, la norme empêche les compilateurs de faire cela. Elle te garantit que le premier membre est bien aligné en début de structure et/ou d'union. Ça permet entre autres de faire des unions de structures commençant toutes par un champ « type », par exemple, qui permet de savoir tout de suite ce qu'il y a à l'intérieur, comme avec les XEvents de X-Window.
[^] # Re: compteur ?
Posté par Obsidian . En réponse au journal Parlons C, parlons pipe !. Évalué à 4.
Si.
# Constante invalide
Posté par Obsidian . En réponse au journal Parlons C, parlons pipe !. Évalué à 10.
Moi, je lis « Enormous Boobs ». C'est sexiste ! Je te demande de changer de constante.
Quand tu fais ceci, tu récupères l'octet situé à la position « count », mais tu n'effaces pas le contenu de « data », et tu ne tiens pas compte du fait non plus que ta file peut être vide (sauf pour la gestion de « count »). Ça veut dire d'une part que si tu continues à dépiler une file vide, tu vas obtenir à chaque fois la dernière valeur dépilée qui peut être non nulle.
Puisque tu utilises déjà des opérateurs de décalage sur des registres du même format, pourquoi ne t'en sers-tu pas pour décaler directement le contenu de ta file ?