Ubuntu-fr

tshirtman

Re : /* Topic des codeurs couche-tard [2] */

on pourras écrire des listing de commandes et les passer en paramettre à clfb? y'aura moyen d'écrire des commentairs dans ces fichiers?

---

Le blog de tshirtman, du python, du shell, du libre, et d'autres choses.
Mon petit frère écrit des trucs biens!
Ultimate smash friends, un smash bros like, libre paquet natty!

Rolinh

Re : /* Topic des codeurs couche-tard [2] */

J'utilise Apache, dans l'immédiat, lighttpd, j'envisageais d'y passer, mais c'est pas encore d'actualité.

Moi j'envisage de switcher mon serveur de ubuntu server + Apache à NetBSD + nginx m'enfin bon, je le ferais pendant ces prochaines vacances.
Mais si tu as un serveur Apache, alors c'est parfait.

Il faut commencer par installer les paquets mercurial (logique quoi) puis, dans /etc/apache2 j'ai créé un dossier hg dans lequel j'ai un fichier main.conf qui contient ceci:

ScriptAliasMatch        ^/hg(.*)        /home/robin/www/hg/hgwebdir.cgi$1
<Directory /home/robin/www/hg>
        Options ExecCGI FollowSymLinks
        AllowOverride None
        AuthType Basic
        AuthName "Mercurial repositories"
        AuthUserFile /home/robin/www/hg/hgusers
        Require valid-user
</Directory>

Là, c'est un repos privé. Pour y accéder, il faut être un utilisateur déclaré dans le fichier hgusers mais tu peux aussi virer la partie authentification.
Il faut bien sûr remplacer ton path par celui qui va bien
Et dans la conf de ton sites-available rajoute cette ligne:

Include /etc/apache2/hg/main.conf

Puis dans ton dossier mercurial(mon dossier hg dans www pour moi), il faut créer le fichiers hgusers (utilise htpasswd -c ) avec les users mercurial.
J'ai également mis le script cgi hgwebdir.cgi que tu peux trouver dans /usr/share/doc/mercurial/examples/hgwebdir.cgi
Il te faut aussi un fichier repos dans lequel tu mets ceci:

[collections]
repos/ = repos/

et tu peux donc init tes repositories dans repos (il faudrait que j'explique plus en détails comment init un repos)

Voilà, en gros et vraiment à l'arrache ^^
Après, si t'as un accès ssh, tu peux le cloner facilement avec hg clone ssh://user@tonserveur.com:port/path/vers/ton/repo
Bon, vraiment à l'arrache comme explication (j'attend tes questions ). Faut que je mette dans ma TODO liste de tutos pour mon site ^^

Dernière modification par Rolinh (Le 13/12/2010, à 15:47)

Elzen

Re : /* Topic des codeurs couche-tard [2] */

@Rolinh : merci pour l'explication. J'suis pas sûr d'avoir le temps de tester là, mais j'essayerai ça au plus tard pendant les vacances et j'te tiendrai au courant

Comme ça

typedef struct 
{
  GtkWidget widget;
  /* autres champs */
} GtkContainer;

Et quand on fait comme ça, on peut caster l'un en l'autre et réciproquement  ? oO

Par contre, ça me semble tendu à gérer les ../repertoire courant (enfin, va sûrement falloir que je revoie mon approche quoi ^_^).

C'est pour ça que je l'ai mis en option
(Je vois une approche possible, mais il y a probablement moyen de faire autrement : récupérer le répertoire courant dans une variable, tenter de se déplacer vers le répertoire indiqué, et si le répertoire courant n'a pas changer, afficher)

Je me posais justement la question moi aussi.

Et t'as une idée ? ^^

J'aurais peut-être vu une option là aussi, genre

./clfb -e 'commande'

Voire

./clfb -e 'commande1;commande2;commande3'

Mais je ne sais pas, à vous de voir.

-e, c'est pour les terminaux, non ? Pour les shell, en général, c'est plutôt -c, non ?
Mais c'est envisageable, oui (voir plus bas )

On peut garder le ^D en parallèle ?

Bien sûr ^^

Si fichier2 est un entier, il me semble que ça entre en conflit avec les appels de programmes.

Yep, en effet… y a conflit aussi si fichier2 vaut - et autres subtilités de ce genre…

Je ne suis pas sûr d'avoir bien compris. Tu peux réexpliquer ?

C'est le comportement qu'on avait déjà défini
Soit on est dans repertoire et on affiche le contenu, soit on y est pas et on y va. Mais comme j'me suis dit que c'était pas forcément évident, je laisse la possibilité qu'il n'affiche le contenu que quand on demande . ou ./, et que si on demande n'importe quoi d'autre qui correspond au répertoire courant, on essaye quand même d'aller dedans.

C'est-à-dire ?
Ouvrir vraiment le répertoire (ça me semble limité au niveau intérêt) où tout les fichiers qu'il y a dedans.

C'est-à-dire que si tu as nautilus d'installé, repertoire 1 (par exemple) ouvrira le répertoire dans nautilus.

on pourras écrire des listing de commandes et les passer en paramettre à clfb? y'aura moyen d'écrire des commentairs dans ces fichiers?

C'est envisageable ^^
Disons que dans ce cas, par rapport à la remarque de grim7reaper précédente, on pourrait dire que « clfb -c "commande" » lance la commande, et que « clfb fichier » essaye de lire le contenu du fichier et de l'appliquer.
(Par contre, quand on met une commande pour modifier les droits d'accès, si on garde les specs précédentes, il ne faut pas oublier les guillemets, sinon le shell considérera ce qui suit le # comme un commentaire…)

---

Elzen : polisson, polémiste, polymathe ! (ex-ArkSeth)
Un script pour améliorer quelques trucs du forum.
La joie de t'avoir connu surpasse la peine de t'avoir perdu…
timezone[blocklist]

grim7reaper

Re : /* Topic des codeurs couche-tard [2] */

Comme ça

typedef struct 
{
  GtkWidget widget;
  /* autres champs */
} GtkContainer;

Et quand on fait comme ça, on peut caster l'un en l'autre et réciproquement  ? oO

Le C te laisserai toujours caster (après faut faire gaffe à ce que tu fais si tu veux pas avoir de soucis à l'exécution). Cela dit, je passerais plutôt par des pointeurs pour faire mes manips et mes cast.

(Je vois une approche possible, mais il y a probablement moyen de faire autrement : récupérer le répertoire courant dans une variable, tenter de se déplacer vers le répertoire indiqué, et si le répertoire courant n'a pas changer, afficher)

J'ai eu exactement la même idée

Je me posais justement la question moi aussi.

Et t'as une idée ? ^^

Non, pas vraiment (j'ai cru en avoir une, mais en fait c'était moche et bancale…)

-e, c'est pour les terminaux, non ? Pour les shell, en général, c'est plutôt -c, non ?
Mais c'est envisageable, oui (voir plus bas )

Bah j'ai mis -e parce c'est comme ça que fonctionne l'interpréteur Perl et c'est le premier truc qui m'est venu à l'esprit. Mais j'ai pensé à -c aussi. C'est comme tu veux

Si fichier2 est un entier, il me semble que ça entre en conflit avec les appels de programmes.

Yep, en effet… y a conflit aussi si fichier2 vaut - et autres subtilités de ce genre…

Ouais, c'est pas cool. Il faudrait trouvé autre chose.

Sinon, Ok pour tes explications. C'est plus clair maintenant.

Dernière modification par grim7reaper (Le 13/12/2010, à 20:35)

---

Blog

Pylades

Re : /* Topic des codeurs couche-tard [2] */

Je voulais parler de plein de trucs mais j'ai oublié…

---

“Any if-statement is a goto. As are all structured loops.
“And sometimes structure is good. When it’s good, you should use it.
“And sometimes structure is _bad_, and gets into the way, and using a goto is just much clearer.”
                Linus Torvalds – 12 janvier 2003

xapantu

Re : /* Topic des codeurs couche-tard [2] */

Bon, encore une question…

Ce genre de truc :

#include…

GtkWidget* mywidget;

void mywidget_init(GtkWidget* mywidget_)
{
mywidget = mywidget_;
}
void mywidget_update_state(gboolean state)
{
/* opération sur mywidget… /
}

Le fait de mettre un pointeur en global c'est une mauvaise chose ? Je veux dire, c'est mieux de le passer dans chaque fonction ? Parce qu'avec un pointeur, ça va, mais si on fait des opérations sur beaucoup de widgets en même temps, ça me semble très très lourd de ne rien mettre en global.

Steap

Re : /* Topic des codeurs couche-tard [2] */

Bon, encore une question…

Ce genre de truc :

#include…

GtkWidget* mywidget;

void mywidget_init(GtkWidget* mywidget_)
{
mywidget = mywidget_;
}
void mywidget_update_state(gboolean state)
{
/* opération sur mywidget… /
}

Le fait de mettre un pointeur en global c'est une mauvaise chose ? Je veux dire, c'est mieux de le passer dans chaque fonction ? Parce qu'avec un pointeur, ça va, mais si on fait des opérations sur beaucoup de widgets en même temps, ça me semble très très lourd de ne rien mettre en global.

Ce serati beaucoup plus propre en passant le widget en paramètre, imho.

Sinon, concernant ce navigateur de fichiers en ligne de commande... Quel est l'intérêt ? :-p

---

GNU Guix, un gestionnaire de paquets fonctionnel.

grim7reaper

Re : /* Topic des codeurs couche-tard [2] */

Le fait de mettre un pointeur en global c'est une mauvaise chose ?

Ouais, ça ne me semble guère justifié ici.

Je veux dire, c'est mieux de le passer dans chaque fonction ?

Oui, sans aucun doute.
Les globales c'est casses couilles à deboguer.

Parce qu'avec un pointeur, ça va, mais si on fait des opérations sur beaucoup de widgets en même temps, ça me semble très très lourd de ne rien mettre en global.

D'où l'intérêt d'utiliser des structures, mais on à dit qu'on le ferait plus tard donc patience

---

Blog

xapantu

Re : /* Topic des codeurs couche-tard [2] */

Parce qu'avec un pointeur, ça va, mais si on fait des opérations sur beaucoup de widgets en même temps, ça me semble très très lourd de ne rien mettre en global.

D'où l'intérêt d'utiliser des structures, mais on à dit qu'on le ferait plus tard donc patience

Non, là, je prends l'exemple du panneau de droite, avec les styles, position, etc…

Supposons que je veuille cacher l'onglet "styles" quand c'est une image. L'appel de la fonction va forcément se trouver dans un sombre fichier qui n'a pas accès au builder et aux widgets (ou en tout cas, qui ne devrais pas). Du coup, si je veut le cacher, comment je fais ? Faire parvenir le builder dans ces fonctions là me semble compliqué ? Et surtout, comment on fais pour que ces fonctions le garde ? Je le met en global là bas ? Enfin bon, je vois pas vraiment comment faire…

Je me disais naïvement que les variables globale sur un seul fichier c'était encore justifié... (j'ai bien fait de demander )

grim7reaper

Re : /* Topic des codeurs couche-tard [2] */

L'appel de la fonction va forcément se trouver dans un sombre fichier qui n'a pas accès au builder et aux widgets (ou en tout cas, qui ne devrais pas).

Bah alors c'est mal foutu s'il doit modifier des trucs auxquels il ne devrait pas avoir accès…

Du coup, si je veut le cacher, comment je fais ? Faire parvenir le builder dans ces fonctions là me semble compliqué ? Et surtout, comment on fais pour que ces fonctions le garde ? Je le met en global là bas ? Enfin bon, je vois pas vraiment comment faire…

J'ai pas du tout regardé l'architecture de la GUI, mais il y a peut-être moyen de faire autrement.
Dans le cas contraire, on passera par une globale si ça ce justifie mais j'aimerais franchement qu'on n'en rajoute aucune tant qu'on a pas nettoyer les autres merdes qui traînent (sinon on va jamais s'en sortir).
Quand le code sera propre, on pourra mieux regarder ça et faire ce qu'il faut. En ajouter maintenant, je le sens vraiment mal…

Je me disais naïvement que les variables globale sur un seul fichier c'était encore justifié... (j'ai bien fait de demander )

Oui, à la limite. Comme j'ai dis on pourra voir ça,  mais là tu déclarais une variable globale à tout le programme, pas juste au fichier.

---

Blog

tshirtman

Re : /* Topic des codeurs couche-tard [2] */

on pourras écrire des listing de commandes et les passer en paramettre à clfb? y'aura moyen d'écrire des commentairs dans ces fichiers?

C'est envisageable ^^
Disons que dans ce cas, par rapport à la remarque de grim7reaper précédente, on pourrait dire que « clfb -c "commande" » lance la commande, et que « clfb fichier » essaye de lire le contenu du fichier et de l'appliquer.
(Par contre, quand on met une commande pour modifier les droits d'accès, si on garde les specs précédentes, il ne faut pas oublier les guillemets, sinon le shell considérera ce qui suit le # comme un commentaire…)

on pourra faire des test en fonction de l'état de fichiers ou d'autres choses?

---

Le blog de tshirtman, du python, du shell, du libre, et d'autres choses.
Mon petit frère écrit des trucs biens!
Ultimate smash friends, un smash bros like, libre paquet natty!

xapantu

Re : /* Topic des codeurs couche-tard [2] */

L'appel de la fonction va forcément se trouver dans un sombre fichier qui n'a pas accès au builder et aux widgets (ou en tout cas, qui ne devrais pas).

Bah alors c'est mal foutu s'il doit modifier des trucs auxquels il ne devrait pas avoir accès…

Du coup, si je veut le cacher, comment je fais ? Faire parvenir le builder dans ces fonctions là me semble compliqué ? Et surtout, comment on fais pour que ces fonctions le garde ? Je le met en global là bas ? Enfin bon, je vois pas vraiment comment faire…

J'ai pas du tout regardé l'architecture de la GUI, mais il y a peut-être moyen de faire autrement.

Hum, l'"architecture" de la GUI ? Et bah tu vas vite en tirer des conclusions…

Je me disais naïvement que les variables globale sur un seul fichier c'était encore justifié... (j'ai bien fait de demander )

Oui, à la limite. Comme j'ai dis on pourra voir ça,  mais là tu déclarais une variable globale à tout le programme, pas juste au fichier.

Ah ? j'ai pas du tout comprendre alors

Je pensais que quand on déclarait une variable globale dans un fichier .c, ça n'était pas accessible des autres fichiers… (et je ne vois d'ailleurs pas comment ils pourraient y avoir accès ?)

Enfin bon, peut-être qu'il faudrait plutôt penser ça avec une seule variable globale pour toutes le gui, on accèderait aux widgets adéquats par l'intermédiaire de fonctions dédiées à tous ça…

edit : bon, je vais me renseigner un peu plus sur la portée des variables, moi…

Dernière modification par xapantu (Le 13/12/2010, à 22:07)

Rolinh

Re : /* Topic des codeurs couche-tard [2] */

Ah, vous m'énervez avec votre gestionnaire de fichier... Je n'ai vraiment pas le temps mais j'aurais bien aimé participer... :s
Je me contenterais de faire des commentaires sur les bouts de code que vous posterez ^^
Par contre, je verrais bien un petit concours de noël histoire que je sois en "vacances" et que j'ai un minimum de temps à dispo.

Steap

Re : /* Topic des codeurs couche-tard [2] */

Je pensais que quand on déclarait une variable globale dans un fichier .c, ça n'était pas accessible des autres fichiers… (et je ne vois d'ailleurs pas comment ils pourraient y avoir accès ?)

C'est tout à fait possible :

foo.c :

int foo = 42;

bar.c :

#include <stdio.h>
extern int foo;

int
main(void)
{
    printf ("foo = %d\n", foo);

    return 0;
}

Résultat :

$ ./bar
foo = 42

---

GNU Guix, un gestionnaire de paquets fonctionnel.

xapantu

Re : /* Topic des codeurs couche-tard [2] */

Bah oui, mais là, tu la déclare en extern dans le header, si je fais ni l'un ni l'autre, ça risque rien, si ?

Quoique, c'est vrai que c'est pas franchement une bonne idée quand même ces histoires de variables globales…

Rolinh

Re : /* Topic des codeurs couche-tard [2] */

c'est pas franchement une bonne idée quand même ces histoires de variables globales…

Clairement. C'est la solution de facilité de ceux qui apprennent à coder (comme utiliser scanf ou autre horreur du genre...) de mettre les variables en global. Parfois, cela se justifie mais il faut qu'il y ait une bonne raison.

Elzen

Re : /* Topic des codeurs couche-tard [2] */

Le C te laisserai toujours caster (après faut faire gaffe à ce que tu fais si tu veux pas avoir de soucis à l'exécution). Cela dit, je passerais plutôt par des pointeurs pour faire mes manips et mes cast.

Nan mais c'est vraiment comme ça que c'est fait ? Ça a l'air moche… si on caste, comment le truc sait que c'est ce truc-là qu'on veut ?

on pourra faire des test en fonction de l'état de fichiers ou d'autres choses?

Plaît-il ?

Bah j'ai mis -e parce c'est comme ça que fonctionne l'interpréteur Perl et c'est le premier truc qui m'est venu à l'esprit. Mais j'ai pensé à -c aussi. C'est comme tu veux

J'préfère -c, personnellement. Mais bon, tu peux faire les deux, en même temps, ça coûte pas plus cher ^^

Ouais, c'est pas cool.

Antislash ?
Genre \1 pour un fichier appelé 1 et \- pour un fichier appelé -. C'est plus ou moins à ça qu'est censé servir l'antislash, à la base, ce me semble. Et t'façon, appeler un fichier juste par un numéro ou un signe comme -, saymoche.

---

Elzen : polisson, polémiste, polymathe ! (ex-ArkSeth)
Un script pour améliorer quelques trucs du forum.
La joie de t'avoir connu surpasse la peine de t'avoir perdu…
timezone[blocklist]

Steap

Re : /* Topic des codeurs couche-tard [2] */

Le C te laisserai toujours caster (après faut faire gaffe à ce que tu fais si tu veux pas avoir de soucis à l'exécution). Cela dit, je passerais plutôt par des pointeurs pour faire mes manips et mes cast.

Nan mais c'est vraiment comme ça que c'est fait ? Ça a l'air moche… si on caste, comment le truc sait que c'est ce truc-là qu'on veut ?

Bienvenue dans les langages de bas niveau.

Qu'est-ce qui te choque, précisément ?

---

GNU Guix, un gestionnaire de paquets fonctionnel.

Elzen

Re : /* Topic des codeurs couche-tard [2] */

Bah qu'un pointeur sur une structure A contenant un pointeur sur une structure B puisse être considéré comme un pointeur sur la structure B.
Que ça soit considéré comme un pointeur sur un pointeur sur la structure B (donc en ignorant la suite du contenu de la strucutre A), je comprendrais.
Mais qu'il utilise un pointeur pour rebondir comme ça d'une adresse mémoire à une autre, j'vois pas comment ça peut marcher

Edit : ah, mais il n'y a pas d'* dans le code indiqué par grim7reaper À force de mettre des pointeurs partout, j'en imagine là où il n'y en a pas ^^"
Effectivement, si la structure B est directement inclue dans la structure A, genre à la tête avec des trucs dedans en plus, je comprends mieux ^^
Et effectivement, ça ne me choque pas outre mesure.

Par contre, j'en reviens à notre histoire d'il y a quelques temps, vous savez, le coup du sizeof Raison de plus pour utiliser sizeof(type) plutôt que sizeof *variable, des fois qu'on déclarerait la variable comme étant d'un type parent ^^

Dernière modification par ArkSeth (Le 13/12/2010, à 22:39)

---

Elzen : polisson, polémiste, polymathe ! (ex-ArkSeth)
Un script pour améliorer quelques trucs du forum.
La joie de t'avoir connu surpasse la peine de t'avoir perdu…
timezone[blocklist]

helly

Re : /* Topic des codeurs couche-tard [2] */

Ça alors, mais oui ! C'est un BN oO !
Bon, demain, exam de java, BLAM
edit :.

Dernière modification par helly (Le 14/12/2010, à 01:09)

---

Archlinux-wmii-dwb.
Un problème résolu ? Faites le savoir en mettant [résolu] à côté du titre de votre topic.
Un problème non résolu ? Faites le savoir en insultant ceux qui cherchent à vous aider.
Un site bleu super remasterised©, un wiki cherchant des volontaires pour traduire un site.

tshirtman

Re : /* Topic des codeurs couche-tard [2] */

on pourra faire des test en fonction de l'état de fichiers ou d'autres choses?

Plaît-il ?

ben si on peut faire des scripts, ce serait bien de pouvoir faire ou non des actions en fonction de divers conditions :]

Dernière modification par tshirtman (Le 13/12/2010, à 22:57)

---

Le blog de tshirtman, du python, du shell, du libre, et d'autres choses.
Mon petit frère écrit des trucs biens!
Ultimate smash friends, un smash bros like, libre paquet natty!

Elzen

Re : /* Topic des codeurs couche-tard [2] */

Prévoir des boucles et des conditionnelles ?

Mouais… c'est vrai que pour un fichier de script, ça se justifierait presque, mais bon, c'est censé être un navigateur de fichier, pas un shell…
Après, si tu peux préciser un peu ton idée, 'faut voir…

(Tiens, par contre, il faudrait peut-être aussi prévoir des options pour créer un répertoire, un fichier vide… et éventuellement des fichiers préstructurés, peut-être…)

(Eh, dis, ça pourrait faire un genre de jeu concours vaguement régulier, ça, non ? Genre le « challenge-TdCCT », un logiciel à coder avec des points à la clef pour les meilleurs productions ? Ou pas.)

---

Elzen : polisson, polémiste, polymathe ! (ex-ArkSeth)
Un script pour améliorer quelques trucs du forum.
La joie de t'avoir connu surpasse la peine de t'avoir perdu…
timezone[blocklist]

tshirtman

Re : /* Topic des codeurs couche-tard [2] */

Mon idée c'était de savoir jusqu'ou j'arriverais faire approcher votre concept d'un shell, sans que vous l'appeliez un shell

---

Le blog de tshirtman, du python, du shell, du libre, et d'autres choses.
Mon petit frère écrit des trucs biens!
Ultimate smash friends, un smash bros like, libre paquet natty!

grim7reaper

Re : /* Topic des codeurs couche-tard [2] */

Bah oui, mais là, tu la déclare en extern dans le header, si je fais ni l'un ni l'autre, ça risque rien, si ?

Il me semble que par défaut c'est global à tout le programme (bon après je ne suis plus sûr à 100 % vu que je n'en utilise jamais).
Il faut utiliser static pour restreindre la portée

(comme utiliser scanf ou autre horreur du genre...)

scanf n'est pas mauvais en soi, il y a juste beaucoup de gens qui ne savent pas l'utiliser, c'est tout…

Effectivement, si la structure B est directement inclue dans la structure A, genre à la tête avec des trucs dedans en plus, je comprends mieux ^^

Oui, c'est comme ça que ça doit être pour émuler l'héritage.

Ma nuit blanche me rattrape : BN World !

Dernière modification par grim7reaper (Le 13/12/2010, à 23:15)

---

Blog

Kanor

Re : /* Topic des codeurs couche-tard [2] */

Il n'a pas le droit. C est beau, C est pure... C parfait!

Heu ouais, peut-être pas quand même

@Kanor : bah ça devrait lui faire plaisir alors.
Mais comment tu vois qu'il fonctionne avec Python 3 ?

J'ai testé

---

Un blog avec du mordant
Liste de bons liens pour apprendre python et plus