gaaaaaAab a écrit 1393 commentaires

j'ai peut-être répondu à côté. J'ai vu passer sftp, j'ai répondu sftp :)

Mais sur le fond, c'est la même question. Est-ce que tes fichiers sont bien créés avec le droit w pour le groupe, et sshfs, pour une raison encore à trouver, le zappe au moment du transfert, ou est-ce que sshfs n'y est pour rien ?

(c'est facile à tester. un fichier local avec les bons droits et une copie sur le montage en sshfs)

je viens de faire quelques tests avec sftp, et, en dehors du fait qu'il faut redémarrer le serveur ssh après la modif de la config, j'attire ton attention sur le fait que sftp ne rajoute pas le droit w sur le groupe. Il applique juste le umask. Donc si le droit w n'est pas présent pour le groupe sur le fichier avant le transfert par sftp, il n'y sera toujours pas après.

Plus globalement, vu que tu as trois sources potentielles de nouveaux fichiers dans tes répertoires, ça sera plus simple si tu découpes ton problème en trois questions distinctes, et que tu debug ta config en les prenant une par une.

je pensais plus aux langages qui produisent du code natif. Pour les langages interprétés ou ayant une VM, c'est plus beaucoup facile.

Je ne connaissais pas graalvm. Ça pourrait être intéressant. Dommage qu'Oracle ait ses sales pattes dedans …

quasiment tous les autres peuvent appeler une fonction C alors que l'inverse est très souvent faux.

ça, c'est juste de l'interface. On peut imaginer un monde dans lequel tous les langages comprennent et sont capables de fabriquer un truc compatible C, sans qu'il n'y ait une seule ligne de C nul part.

C a un écosystème énorme comparé à Go ou Rust.

oui, mais comme tu viens de le rappeler, (quasi) tous les langages sont capables d'appeler du C. Ils peuvent hériter (sous certaines conditions) d'une grande partie de l'écosystème du C.

Bref, vouloir prendre la place de C, c'est un doux rêve.

Je ne pense pas qu'un seul langage puisse venir remplacer le C sur tous ses domaines d'usage. Par contre, j'arrive à imaginer que le C soit remplacé au fil de l'eau par des langages spécialisés sur de nombreux domaines, et dans d'étranges éons, sur tous.

Ça se comporte comme les variables d'environnement (même si ça n'en est pas). Si tu modifies le umask dans un processus, tous les processus fils hériteront de cet umask, mais pas les autres processus.

Pour tes utilisateurs qui sont des serveurs web, ça vaut le coup de regarder dans la doc ce qui est préconisé pour la config de l'umask.

non, ce n'est pas la même chose. umask définit le masque de permission qui va être appliqué pour tous les nouveaux fichiers. Tant que tu ne crées pas de nouveaux fichiers, l'effet d'umask est nul. D'autre part, quand tu modifies ton umask, ça n'a aucune incidence sur les fichiers déjà créés. Je pense que pour toi, c'est intéressant de combiner les deux. umask pour que les nouveaux fichiers soient créés avec le droit en écriture pour le groupe, et chmod pour que les fichiers déjà existants obtiennent ce droit.

Soit-dit en passant, chmod 770, c'est un peu violent. Tu peux faire plus fin. C'est possible de ne rajouter que le droit en écriture pour le groupe sans toucher aux autres permissions (avec chmod g+w)

$ umask 
0022
$ touch fichier1
$ ls -l fichier1 
-rw-r--r-- 1 gab gab 0 Sep  8 22:39 fichier1
$ umask 0002
$ touch fichier2
$ ls -l fichier*
-rw-r--r-- 1 gab gab 0 Sep  8 22:39 fichier1
-rw-rw-r-- 1 gab gab 0 Sep  8 22:40 fichier2
$ chmod g+w fichier1 
$ ls -l fichier*
-rw-rw-r-- 1 gab gab 0 Sep  8 22:39 fichier1
-rw-rw-r-- 1 gab gab 0 Sep  8 22:40 fichier2

Note qu'après la modif du umask, les droits de fichier1 n'ont pas été modifié.

La configuration d'umask se fait souvent dans le .profile.

tu peux configurer le umask (masque de permission pour la création de fichiers)

$ umask
0022
$ touch tst_umask
$ umask 0002
$ touch tst_umask_1
$ ls -l tst_umask*
-rw-r--r-- 1 gab gab 0 Sep  8 20:01 tst_umask
-rw-rw-r-- 1 gab gab 0 Sep  8 20:01 tst_umask_1

ouais, faut que je remette à gnome et que j'apprenne LaTeX ! :D

Question annexe:

D'après ce que je vois sur le net, il y a des alternatives similaires sous Windows. Dans ta recommandation, qu'est-ce qui te fait préférer présenter WinSCP plutôt que sshfs ?

À partir du moment ou j'ai écris que je commence à faire partie des vieux grincheux, j'en prends également bonne note.

Quand j'ai fait ma formation Linux en 1999, mon formateur nous avait donné ce sens au mot Linux.

je ne dis pas que ce n'est pas un sens possible, simplement que le fait que ce soit le sens du nom Linux depuis les origines me paraît incorrect. En tout cas, entre un formateur Linux random de 1999 et wikipedia, je sais auquel j'accorde le plus de confiance.

NB Tu n'étais peut-être pas né en 1991 ?

c'est un peu hors sujet, mais si

Tu t'es spécialisé dans le tuning de vim ? ;+)

Dans l'exemple que j'ai donné, il y a 3 caractères qui sont du vim, le reste, c'est du shell. ':' pour le mode commande, c'est pas du tuning, c'est le b.a.-ba de vim. '%' sélection de tout le fichier (c'est l'équivalent de Ctrl-a, ne viens pas me dire que c'est une fonctionnalité avancée), ! permet d'invoquer le shell. Je veux bien considérer que '!' fait partie d'un usage un peu avancé de vim (mais c'est franchement pas du tuning). Quand tu dois apprendre que tu as des fonctionnalités en appuyant sur F4 ou sur F7 de ton éditeur, c'est la même chose, c'est de la connaissance de base des fonctionnalités du logiciel que tu utilises.

je colle ici mon .vimrc, je pense que les utilisateurs de vim te confirmeront que c'est super basique:

~$ cat ~/.vimrc 
syntax on
set background=dark
set tabstop=8
set hlsearch

je te laisse tuner ton mc ;-)

Comme liberforce et ZeroHeure, c'est aussi la première fois que je vois Linux être présenté comme un acronyme. Je ne l'avais jamais vu passer avant, et je commence aussi à faire partie des vieux grincheux qui utilisent Linux depuis longtemps. Ça ressemble à un backronyme. Ça serait intéressant de voire de quand date sa première apparition.

Si je peux me permette de copier le ton de ton commentaire, ce n'est pas parce que tu ne sais pas que Linux Is Not UniX est un backronyme que ça n'en n'est pas un. Ce n'est pas connu depuis longtemps !

Dans mc, la fonction Remplacer, c'est la touche F4. mc prend en charge les expressions régulières ! Pour la recherche, c'est F7.

Si tu as un config dont tu es content, c'est cool, j'ai aucun problème avec ça :)

Je n'ai pas dit que vim avait plus de fonctionnalités (encore que, il en a probablement plus que l'éditeur de mc, mais vu que j'utilise probablement moins de 5 % des fonctionnalités de vim, ce n'est pas un point pertinent). Je dis qu'il est plus polyvalent. Donc, à productivité égale, je le trouve plus intéressant. Mais c'est une évaluation subjective lié aux contextes dans lesquels je suis amené à utiliser un éditeur de texte. Quand tu te log sur un Unix non Linux, non BSD, t'es déjà content d'avoir vim plutôt que vi, alors mc, aucune chance qu'il soit installé.

D'ailleurs, si tu utilises WinSCP pour rapatrier un fichier localement pour l'éditer avec ton éditeur préféré, on va se comprendre. Moi aussi j'utilise en priorité l'éditeur de texte qui me plaît. Après, on va pas s'écharper sur quel éditeur de texte est le plus puissant. Ils proposent tous des fonctionnalités de base et des fonctionnalités avancées similaires. C'est une question de préférence personnelle. Le fait que vim ne te convienne pas, c'est tout à fait audible. Que tu en conclues que vim ne convient à personne, c'est incorrect. Et c'est facile à démontrer, vu qu'il y a des contre exemple, c'est-à-dire des gens à qui vim convient très bien.

Je ne vois pas en quoi vi/vim apporterait de la productivité supplémentaire

ça dépend à quoi on le compare. Comparé au notepad de base de la fin des années 90, c'est clair que vi/vim permet d'être plus productif. Pour cette discussion, je considère qu'on parle d'éditeurs de texte avancés.

Moi je vois en quoi vim m'apporte de la productivité dans mon usage personnel. Mais je ne sais pas si ça apporterait de la productivité dans l'absolu. Je ne crois pas avoir vraiment abordé la productivité dans mon commentaire précédente d'ailleurs.

Là dessus, la seule chose que je peux affirmer, c'est que la maîtrise de l'éditeur que tu utilises va te faire gagner en productivité, quelque soit l'éditeur. Mais bon, c'est une évidence.

Avec vim, je sais sélectionner des sections d'un fichier, les mouliner dans des commandes du shell et récupérer le résultat. Par exemple, trier le fichier en cours et éliminer les doublons, ça se fait avec :%!sort -u. Je ne sais pas le faire avec un autre éditeur. Je suis plus productif avec vim.

J'ose croire que, sur ce point au moins, tout le monde peut être d'accord.

je veux bien t'accorder que vim n'est pas Denis friendly, mais pas plus ;)

Dans ton article:

Nous avions surtout en commun d’avoir une profonde détestation pour la complexité inutile de l’éditeur vi

Je ne dis pas que c'est la même chose, mais ça serait une phrase que pourrait dire un développeur C à qui on apprend la syntaxe C++ sans lui avoir expliquer les concept de la programmation objet. S'il continue à faire du C en C++, il va aussi trouver qu'il y a beaucoup de complexité inutile.

L'approche vi/vim est singulière dans la distinction entre le mode commande et le mode édition. Pour quelqu'un qui écrit simplement son courrier, je suis d'accord que la distinction entre ces modes est de la complexité inutile.

Par contre, dans certains contextes, pour un informaticien, la richesse des possibilité de déplacements/recherche dans un ou plusieurs fichiers est vraiment un gros plus.
Certes, ces fonctionnalités (et parfois plus) vont se retrouver dans IDE moderne. Mais un IDE est un outil spécialisé. Vim est un outil polyvalent et installé sur plus de plateformes. Tu peux coder, faire ton courrier, consulter un log sur la prod, …

Le choix d'utiliser vim ou pas se place dans un contexte plus général d'utilisation d'un éditeur de texte. Si tu n'utilises un éditeur de texte que pour coder dans les langages supportés par ton IDE, évidemment, il n'y a pas particulièrement de raison d'utiliser vi/vim. Si tu "factorises" ton activité d'édition de code dans toutes tes activités, ça devient intéressant de sélectionner un éditeur puissant et d'apprendre à s'en servir.

NB: tu peux remplacer vi/vim par emacs, la réflexion générale est identique.

je veux juste savoir si la programmation du jeu 3D n'a rien à voir avec
la 2D et il faut tout oublier et commencer quelque chose de nouveau avec la 3D

Si c'est juste pour du rendu (genre un jeu de plateforme 2D avec un background 3D, parfois appelé 2,5D), la conversion ne doit pas poser de problème autre que purement technique (faire le rendu 3D et balancer un plan 2D par dessus dans lequel le gameplay se déroule).

Par contre, s'il s'agit de convertir un gameplay 2D en gameplay 3D (et que ce n'est donc pas que du rendu), ça risque de ne pas bien marcher sans repenser sérieusement les contrôles, la conception des niveaux et potentiellement tout le jeu en fait.

Pour illustrer la question des contrôles, c'est le même genre de problèmes que rencontrent les gens qui développent pour la VR. Tout le "vocabulaire" d'interaction qui s'est mis en place au fil du temps pour la 3D, ça marche pas bien en VR. (Exemple de vocabulaire, quand les jeux 3D sont apparus, les manettes standards ne disposaient que d'un stick. Du coup, quand le contrôle de la caméra était possible, c'était souvent les gâchettes qui servait à contrôler son orientation, sachant qu'il n'y avait que deux gâchettes, et que le stick n'était pas clickable. Aujourd'hui, il y a souvent un stick dédié exclusivement au contrôle de la caméra).

Et pareil, le "vocabulaire" de la 2D n'est pas adapté à un gameplay 3D. Par exemple, pour un jeu de plateforme, c'est pas du tout évident de gérer correctement la profondeur et la longueur des sauts. Les premiers jeu de plateforme 3D sont catastrophiques tellement ils sont peut jouables.

Sur le plan technique, il y a aussi qu'en 2D, on peut se permettre de manipuler des entiers. Dès qu'on fait de la 3D, je pense qu'on n'a pas trop le choix que de passer en flottants, et ça tire toute une complexité et des nouvelles classes de problèmes.

Donc, à part pour une conversion 2D -> 3D cosmétique, je pense que les jeux en 2D et les jeux en 3D, c'est assez différent.

Après, ça veut pas forcément dire que rien n'est commun. Tout ce qui n'est pas du gameplay, du level design ou du rendu, ça peut se réutiliser. Par exemple un système d'inventaire, un système de gestion de points de vie et autres stats, un menu de configuration, un journal de quêtes, une pile réseau, un lobby, …

je rappelle à toutes fins utiles, que je ne développe pas, ni n'ai développé de jeux vidéos. Je serais ravi que quelqu'un me corrige et/ou complète si je dis nimp' :)

le principe de neutralité du net s'applique au niveau des opérateurs de telecom. Si tu estimes que tu as envie de bloquer des plages d'IP, tant que tu n'es pas un opérateur de télécom, tu fais bien comme tu veux. Sans avoir plus de contexte, c'est difficile d'évaluer si c'est une bonne idée de le faire ou pas.

Je suis assez néophyte en C++ (c'est un langage qui m'a fait fuir assez vite): est-ce que c'est une vraiment question sur le langage C++ ou plutôt sur ce que va faire un compilateur C++ ?

D'ailleurs, pour ce que j'ai lu sur le C++, j'ai l'impression que la séparation entre la spécification du langage est son implémentation n'est pas toujours simple à faire. Est-ce que c'est une impression très fausse ou il y a un peu de ça ?

(Et du coup, ça répondrait à ma première question)

c'est une des limites du logiciel propriétaire. Sans avoir accès aux binaires ou au code source, ça limite la connaissance de la communauté. J'ai répondu histoire de ne pas donner l'impression que tout le monde s'en fout. Et puis pypyodbc, ça aurait pu fonctionner. C'est peut-être un problème tout bête, mais j'ai peur que les gens spécifiquement compétents sur hyperfile-sql et python ne soient pas très nombreux.

Il faut se retourner vers l'éditeur pc soft, en espérant qu'il fournisse une assistance digne de ce nom. (Ou se débarrasser de windev et s'orienter vers un environnement plus ouvert si c'est possible).

Si Windev ne peut pas être remplacé, c'est quand même peut-être possible de contourner le problème en s'appuyant sur un autre SGBD. Quelqu'un dit là (stackoverflow, 3ème réponse) que windev fonctionne bien avec postgreSQL. Un autre avantage (si HSQL n'est pas trop intégré dans ton projet), c'est que partir sur une solution postreSQL permettrait plus facilement de dégager windev, à terme.

je ne connais pas hyperfile-sql mais j'ai un bon google-fu.

Par là , quelqu'un conseille d'utiliser pypyodbc (ré-implémentation en python pur de pyodbc). Ça se tente

la doc dit aussi que si tu veux une table sans clef primaire, tu dois préciser primary_key = False dans la class.

En passant, je comprends que, sur un exemple simple, tu aies choisis de ne pas mettre de clef primaire sur la table voiture. Mais dans la pratique, je déconseille très fortement. J'ai fait pas mal de DB relationnel, et jusqu'à présent, je n'ai pas d'exemple pour lequel c'était clair qu'il ne fallait pas avoir de clef primaire.

Pour ton exemple, dès que tu vas chercher à enrichir un peu ton modèle, l'absence de clef primaire sur Voiture risque de se faire sentir.

la doc peewee parle d'un type ForeignKeyField, pas ForeignKey pour la déclaration de personne_id dans la classe Voiture.

alors que c'est quand même rigolo de se moquer des voitures.

par rapport à ce que tu sembles vouloir dire, je crois que tu fais un contresens sur le mot réactionnaire.

j'ai appris il y a pas longtemps (une chronique sur arretsurimages) que l'accord des pluriels n'a pas toujours été masculins. On pouvait(peut ?) accorder sur le genre du nom le plus proche de l'adjectif. Ex: les hommes et les femmes sont égales.