Pour ceux que ça pourrait intéresser, j'ai écrit une documentation sur le
fonctionnement du système des ports freebsd:
http://www.lpthe.jussieu.fr/~talon/freebsdports.html (resp .pdf .tex).
D'ailleurs est-ce que vous savez comment on fait pour déclarer une durée de vie à un objet de façon à ce qu'il vire rapidement du cache squid?
Quelques éléments de réponse ici (c'est un thème assez épineux) : http://www.mnot.net/cache_docs/#CONTROL
On peut aussi supprimer des éléments du cache de Squid manuellement, en utilisant squidclient et PURGE, mais il faut que la config le permette : http://www.squid-cache.org/Doc/FAQ/FAQ-7.html#ss7.5
J'ai lu ça, merci beaucoup, je n'avais pas la moindre idée que toutes ces choses existaient!
--
Michel TALON
Damien Wyart <damien.wyart@free.fr> wrote:
* talon@lpthe.jussieu.fr (Michel Talon) in fr.comp.os.bsd:
D'ailleurs est-ce que vous savez comment on fait pour déclarer une
durée de vie à un objet de façon à ce qu'il vire rapidement du cache
squid?
Quelques éléments de réponse ici (c'est un thème assez épineux) :
http://www.mnot.net/cache_docs/#CONTROL
On peut aussi supprimer des éléments du cache de Squid manuellement, en
utilisant squidclient et PURGE, mais il faut que la config le permette :
http://www.squid-cache.org/Doc/FAQ/FAQ-7.html#ss7.5
J'ai lu ça, merci beaucoup, je n'avais pas la moindre idée que toutes ces
choses existaient!
D'ailleurs est-ce que vous savez comment on fait pour déclarer une durée de vie à un objet de façon à ce qu'il vire rapidement du cache squid?
Quelques éléments de réponse ici (c'est un thème assez épineux) : http://www.mnot.net/cache_docs/#CONTROL
On peut aussi supprimer des éléments du cache de Squid manuellement, en utilisant squidclient et PURGE, mais il faut que la config le permette : http://www.squid-cache.org/Doc/FAQ/FAQ-7.html#ss7.5
J'ai lu ça, merci beaucoup, je n'avais pas la moindre idée que toutes ces choses existaient!
--
Michel TALON
espie
In article <edrrl9$2brk$, Michel Talon wrote:
F. Senault wrote:
Chez moi ça se présente comme ça:
Michel Talon The FreeBSD ports system. <---- le titre. August 2006
Vous avez tous raison, ça vient d'un comportement bizarre de Hevea. J'ai trouvé une parade, et maintenant il n'y a plus ce problème. Merci bien.
Au fait, tu as corrige les "s qui deviennent des eszet et autres a-trema ?
Damien Wyart
[ Questions sur squid ]
* (Michel Talon) in fr.comp.os.bsd:
J'ai lu ça, merci beaucoup, je n'avais pas la moindre idée que toutes ces choses existaient!
Pour montrer que le thème est riche, il y a deux livres d'O'Reilly là-dessus (et ils sont incomplets sur certains points) : http://book.web-cache.com/index-two.html http://squidbook.org/index-two.html
-- DW
[ Questions sur squid ]
* talon@lpthe.jussieu.fr (Michel Talon) in fr.comp.os.bsd:
J'ai lu ça, merci beaucoup, je n'avais pas la moindre idée que toutes
ces choses existaient!
Pour montrer que le thème est riche, il y a deux livres d'O'Reilly
là-dessus (et ils sont incomplets sur certains points) :
http://book.web-cache.com/index-two.html
http://squidbook.org/index-two.html
J'ai lu ça, merci beaucoup, je n'avais pas la moindre idée que toutes ces choses existaient!
Pour montrer que le thème est riche, il y a deux livres d'O'Reilly là-dessus (et ils sont incomplets sur certains points) : http://book.web-cache.com/index-two.html http://squidbook.org/index-two.html
-- DW
talon
Marc Espie wrote:
Au fait, tu as corrige les "s qui deviennent des eszet et autres a-trema ?
Non, je n'ai même pas remarqué. Comme je disais, c'est du TeX qui a été converti en html par hevea, et que j'ai mis là pour la commodité. S'il faut aller pinailler à l'intérieur pour corriger les conneries que peut faire hevea, je ne vais pas le faire, ça c'est sûr. Il y a un pdf au même endroit, et aussi le source tex, (freebsdports.pdf, freebsdports.tex).
Incidemment, l'une des raisons pour lesquelles j'ai écrit ce document est que je voulais écrire un programme python pour calculer l'INDEX. Je viens de le finir. Il copie fidèlement ce que fait bsd.ports.mk, comme logique. C'est à dire qu'on extraît les valeurs de certaines variables en utilisant make -V dans chaque port, puis on traîte ces valeurs jusqu'à obtenir l'index, par une foule d'opérations cachées dans certaines "targets" de bsd.ports.mk puis un perl script. Là je fais toutes les opérations dans mon programme python. J'ai fait ça sur un sous arbre des ports correspondant à mes 600 paquets installés, et voici ce que ça donne, selon les messages de mon prog:
The tree (600 ports) takes 82.4282870293 seconds to explore. Now computing the recursively extended dependencies. Took 0.1138920784 seconds. Now converting to packages and sorting. Last phase takes 0.897161006927 seconds. Total time has been 83.4409840107 seconds.
La dernière phase correspond à remplacer toutes les origines par le nom de paquet correspondant et les mettre dans l'ordre. Je craignais que ça ne soit couteux. En fait pas du tout, toutes les opérations du programme coutent seulement une seconde! Tout le mal vient de l'exécution de "make", grosso modo chaque make prend en moyenne 0.138s, donc sur 16000 ports ça fait 36 minutes. Je vais essayer de paralléléliser les make pour gagner un peu de temps. Ces chiffres sont sur un PIV monoproc 3Ghz.
--
Michel TALON
Marc Espie <espie@lain.home> wrote:
Au fait, tu as corrige les "s qui deviennent des eszet et autres a-trema ?
Non, je n'ai même pas remarqué. Comme je disais, c'est du TeX qui a été
converti en html par hevea, et que j'ai mis là pour la commodité. S'il faut
aller pinailler à l'intérieur pour corriger les conneries que peut faire
hevea, je ne vais pas le faire, ça c'est sûr. Il y a un pdf au même
endroit, et aussi le source tex, (freebsdports.pdf, freebsdports.tex).
Incidemment, l'une des raisons pour lesquelles j'ai écrit ce document est que
je voulais écrire un programme python pour calculer l'INDEX. Je viens de le
finir. Il copie fidèlement ce que fait bsd.ports.mk, comme logique. C'est à
dire qu'on extraît les valeurs de certaines variables en utilisant make -V
dans chaque port, puis on traîte ces valeurs jusqu'à obtenir l'index, par une
foule d'opérations cachées dans certaines "targets" de bsd.ports.mk puis un
perl script. Là je fais toutes les opérations dans mon programme python. J'ai
fait ça sur un sous arbre des ports correspondant à mes 600 paquets installés,
et voici ce que ça donne, selon les messages de mon prog:
The tree (600 ports) takes 82.4282870293 seconds to explore.
Now computing the recursively extended dependencies.
Took 0.1138920784 seconds. Now converting to packages and sorting.
Last phase takes 0.897161006927 seconds.
Total time has been 83.4409840107 seconds.
La dernière phase correspond à remplacer toutes les origines par le nom de
paquet correspondant et les mettre dans l'ordre. Je craignais que ça ne soit
couteux. En fait pas du tout, toutes les opérations du programme coutent
seulement une seconde! Tout le mal vient de l'exécution de "make", grosso
modo chaque make prend en moyenne 0.138s, donc sur 16000 ports ça fait 36
minutes. Je vais essayer de paralléléliser les make pour gagner un peu de
temps. Ces chiffres sont sur un PIV monoproc 3Ghz.
Au fait, tu as corrige les "s qui deviennent des eszet et autres a-trema ?
Non, je n'ai même pas remarqué. Comme je disais, c'est du TeX qui a été converti en html par hevea, et que j'ai mis là pour la commodité. S'il faut aller pinailler à l'intérieur pour corriger les conneries que peut faire hevea, je ne vais pas le faire, ça c'est sûr. Il y a un pdf au même endroit, et aussi le source tex, (freebsdports.pdf, freebsdports.tex).
Incidemment, l'une des raisons pour lesquelles j'ai écrit ce document est que je voulais écrire un programme python pour calculer l'INDEX. Je viens de le finir. Il copie fidèlement ce que fait bsd.ports.mk, comme logique. C'est à dire qu'on extraît les valeurs de certaines variables en utilisant make -V dans chaque port, puis on traîte ces valeurs jusqu'à obtenir l'index, par une foule d'opérations cachées dans certaines "targets" de bsd.ports.mk puis un perl script. Là je fais toutes les opérations dans mon programme python. J'ai fait ça sur un sous arbre des ports correspondant à mes 600 paquets installés, et voici ce que ça donne, selon les messages de mon prog:
The tree (600 ports) takes 82.4282870293 seconds to explore. Now computing the recursively extended dependencies. Took 0.1138920784 seconds. Now converting to packages and sorting. Last phase takes 0.897161006927 seconds. Total time has been 83.4409840107 seconds.
La dernière phase correspond à remplacer toutes les origines par le nom de paquet correspondant et les mettre dans l'ordre. Je craignais que ça ne soit couteux. En fait pas du tout, toutes les opérations du programme coutent seulement une seconde! Tout le mal vient de l'exécution de "make", grosso modo chaque make prend en moyenne 0.138s, donc sur 16000 ports ça fait 36 minutes. Je vais essayer de paralléléliser les make pour gagner un peu de temps. Ces chiffres sont sur un PIV monoproc 3Ghz.
--
Michel TALON
Ducrot Bruno
Bonjour,
On Mon, 11 Sep 2006 16:15:53 +0000 (UTC), Michel Talon wrote:
Marc Espie wrote:
Au fait, tu as corrige les "s qui deviennent des eszet et autres a-trema ?
Non, je n'ai même pas remarqué. Comme je disais, c'est du TeX qui a été converti en html par hevea, et que j'ai mis là pour la commodité. S'il faut aller pinailler à l'intérieur pour corriger les conneries que peut faire hevea, je ne vais pas le faire, ça c'est sûr. Il y a un pdf au même endroit, et aussi le source tex, (freebsdports.pdf, freebsdports.tex).
D'un autre côté, il me semble qu'il vaut mieux écrire ``ceci'' plutôt que "ceci".
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
Bonjour,
On Mon, 11 Sep 2006 16:15:53 +0000 (UTC), Michel Talon
<talon@lpthe.jussieu.fr> wrote:
Marc Espie <espie@lain.home> wrote:
Au fait, tu as corrige les "s qui deviennent des eszet et autres a-trema ?
Non, je n'ai même pas remarqué. Comme je disais, c'est du TeX qui a été
converti en html par hevea, et que j'ai mis là pour la commodité. S'il faut
aller pinailler à l'intérieur pour corriger les conneries que peut faire
hevea, je ne vais pas le faire, ça c'est sûr. Il y a un pdf au même
endroit, et aussi le source tex, (freebsdports.pdf, freebsdports.tex).
D'un autre côté, il me semble qu'il vaut mieux écrire ``ceci'' plutôt
que "ceci".
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
On Mon, 11 Sep 2006 16:15:53 +0000 (UTC), Michel Talon wrote:
Marc Espie wrote:
Au fait, tu as corrige les "s qui deviennent des eszet et autres a-trema ?
Non, je n'ai même pas remarqué. Comme je disais, c'est du TeX qui a été converti en html par hevea, et que j'ai mis là pour la commodité. S'il faut aller pinailler à l'intérieur pour corriger les conneries que peut faire hevea, je ne vais pas le faire, ça c'est sûr. Il y a un pdf au même endroit, et aussi le source tex, (freebsdports.pdf, freebsdports.tex).
D'un autre côté, il me semble qu'il vaut mieux écrire ``ceci'' plutôt que "ceci".
-- Bruno Ducrot
-- Which is worse: ignorance or apathy? -- Don't know. Don't care.
talon
Ducrot Bruno wrote:
D'un autre côté, il me semble qu'il vaut mieux écrire ``ceci'' plutôt que "ceci".
C'est exact, j'ai mis systématiquement des " au lieu de ``, par paresse. Peut être que emacs sait faire le remplacement automatiquement. je regarderai.
Ducrot Bruno <ducrot@echo.fr> wrote:
D'un autre côté, il me semble qu'il vaut mieux écrire ``ceci'' plutôt
que "ceci".
C'est exact, j'ai mis systématiquement des " au lieu de ``, par paresse.
Peut être que emacs sait faire le remplacement automatiquement. je regarderai.
D'un autre côté, il me semble qu'il vaut mieux écrire ``ceci'' plutôt que "ceci".
C'est exact, j'ai mis systématiquement des " au lieu de ``, par paresse. Peut être que emacs sait faire le remplacement automatiquement. je regarderai.
talon
Ducrot Bruno wrote:
D'un autre côté, il me semble qu'il vaut mieux écrire ``ceci'' plutôt que "ceci".
Corrigé merci beaucoup.
Ducrot Bruno <ducrot@echo.fr> wrote:
D'un autre côté, il me semble qu'il vaut mieux écrire ``ceci'' plutôt
que "ceci".
On peut aussi supprimer des éléments du cache de Squid manuellement, en utilisant squidclient et PURGE, mais il faut que la config le permette :
rm(1) fonctionne également.
-- Sameh
Damien Wyart
On peut aussi supprimer des éléments du cache de Squid manuellement, en utilisant squidclient et PURGE, mais il faut que la config le permette :
* Sameh Ghane in fr.comp.os.bsd:
rm(1) fonctionne également.
Pour vider le cache mémoire aussi ?
Ceci dit, je m'avance un peu puisque la doc de Squid (célèbre pour sa qualité...) ne précise pas ce que fait exactement le purge. Mais même si ça purgeait sur disque ça me semble plus facile de passer une adresse d'objet que de retrouver le fichier correspondant dans les arborescences multi-niveaux de Squid... Ou alors quelque chose m'échappe.
Bref, votre remarque qui se veut cassante n'est pas forcément complètement pertinente à mon avis.
-- DW
On peut aussi supprimer des éléments du cache de Squid
manuellement, en utilisant squidclient et PURGE, mais il faut que
la config le permette :
* Sameh Ghane <sush.sp4m@PourIX.com> in fr.comp.os.bsd:
rm(1) fonctionne également.
Pour vider le cache mémoire aussi ?
Ceci dit, je m'avance un peu puisque la doc de Squid (célèbre pour sa
qualité...) ne précise pas ce que fait exactement le purge. Mais même si
ça purgeait sur disque ça me semble plus facile de passer une adresse
d'objet que de retrouver le fichier correspondant dans les arborescences
multi-niveaux de Squid... Ou alors quelque chose m'échappe.
Bref, votre remarque qui se veut cassante n'est pas forcément
complètement pertinente à mon avis.
On peut aussi supprimer des éléments du cache de Squid manuellement, en utilisant squidclient et PURGE, mais il faut que la config le permette :
* Sameh Ghane in fr.comp.os.bsd:
rm(1) fonctionne également.
Pour vider le cache mémoire aussi ?
Ceci dit, je m'avance un peu puisque la doc de Squid (célèbre pour sa qualité...) ne précise pas ce que fait exactement le purge. Mais même si ça purgeait sur disque ça me semble plus facile de passer une adresse d'objet que de retrouver le fichier correspondant dans les arborescences multi-niveaux de Squid... Ou alors quelque chose m'échappe.
Bref, votre remarque qui se veut cassante n'est pas forcément complètement pertinente à mon avis.
