je suis a la recherche d'aide sur l'utilisation de endian.h avec config.h
dans le but de convertir des fichier compilés sous unix solaris en
BIG-ENDIAN en fichier LITTLE-ENDIAN.
je travail actuellement sur linux debian 3.0 woody
BER, au moins, permet d'omettre l'information de typage dans certains contextes, où la structure est fixe et connue d'avance. Dans les
Je vois ce que tu veux dire. Effectivement, si le type peut être omis, alors le BER permet de coder des informations de manière plus 'compacte' que le DER (je n'ai jamais joué avec le CER ou le PER).
Les types du modèle, définis dans le ASN.1, sont plus complexe que ça. Dans le pire de cas, le type est spécifié par un nom distingué. Mais ce qui était prévu par notre protocol (je ne sais pas quelle partie était du BER pûr, et quelle partie du protocol qui s'en servait), c'était de décrire un certain nombre de types complexe lors de l'établissement de la connexion, en les affectant un numéro, et puis, par la suite, quand on envoyait un tel type, on donnait le numéro, puis on envoyait toutes les données du type, dans l'ordre prédéterminé, et sans indication de type pour les sous-objets. Dans notre cas, beaucoup des sous-objets étaient des enum, dont le type exigeait normalement un nom distingué. Sans optimization, il fallait cinq ou six octets pour le type, puis un octet de donnée.
Dans la pratique, je crois qu'on n'a jamais implémenté l'optimisation. En fait, le nombre de messages n'était pas énorme, et les connexions étaient très rapide (de l'ordre d'un à quatre gigabaud). La quantité d'octets n'était donc pas un problème.
Mais le type ne prend qu'un seul octet, même en DER, donc le 'surcoût' est bien moindre qu'en XML, où il faut bien plus d'octets pour préciser le contexte, et souvent autant pour le fermer (balise fermante).
C'est vraiment la balise fermante que je trouve de trop en XML. C'est une information rédondante, qui, dans la plupart des applications (ou le XML est généré par l'ordinateur) ne sert absolument à rien.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, Tél. : +33 (0)1 30 23 45 16
Erwann ABALEA <erwann@abalea.com> wrote in message
news:<Pine.LNX.4.33.0307031411360.7251-100000@patchwork.seclogd.org>...
BER, au moins, permet d'omettre l'information de typage dans
certains contextes, où la structure est fixe et connue
d'avance. Dans les
Je vois ce que tu veux dire. Effectivement, si le type peut être omis,
alors le BER permet de coder des informations de manière plus
'compacte' que le DER (je n'ai jamais joué avec le CER ou le PER).
Les types du modèle, définis dans le ASN.1, sont plus complexe que
ça. Dans le pire de cas, le type est spécifié par un nom distingué. Mais
ce qui était prévu par notre protocol (je ne sais pas quelle partie
était du BER pûr, et quelle partie du protocol qui s'en servait),
c'était de décrire un certain nombre de types complexe lors de
l'établissement de la connexion, en les affectant un numéro, et puis,
par la suite, quand on envoyait un tel type, on donnait le numéro, puis
on envoyait toutes les données du type, dans l'ordre prédéterminé, et
sans indication de type pour les sous-objets. Dans notre cas, beaucoup
des sous-objets étaient des enum, dont le type exigeait normalement un
nom distingué. Sans optimization, il fallait cinq ou six octets pour le
type, puis un octet de donnée.
Dans la pratique, je crois qu'on n'a jamais implémenté l'optimisation.
En fait, le nombre de messages n'était pas énorme, et les connexions
étaient très rapide (de l'ordre d'un à quatre gigabaud). La quantité
d'octets n'était donc pas un problème.
Mais le type ne prend qu'un seul octet, même en DER, donc le 'surcoût'
est bien moindre qu'en XML, où il faut bien plus d'octets pour
préciser le contexte, et souvent autant pour le fermer (balise
fermante).
C'est vraiment la balise fermante que je trouve de trop en XML. C'est
une information rédondante, qui, dans la plupart des applications (ou le
XML est généré par l'ordinateur) ne sert absolument à rien.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, Tél. : +33 (0)1 30 23 45 16
BER, au moins, permet d'omettre l'information de typage dans certains contextes, où la structure est fixe et connue d'avance. Dans les
Je vois ce que tu veux dire. Effectivement, si le type peut être omis, alors le BER permet de coder des informations de manière plus 'compacte' que le DER (je n'ai jamais joué avec le CER ou le PER).
Les types du modèle, définis dans le ASN.1, sont plus complexe que ça. Dans le pire de cas, le type est spécifié par un nom distingué. Mais ce qui était prévu par notre protocol (je ne sais pas quelle partie était du BER pûr, et quelle partie du protocol qui s'en servait), c'était de décrire un certain nombre de types complexe lors de l'établissement de la connexion, en les affectant un numéro, et puis, par la suite, quand on envoyait un tel type, on donnait le numéro, puis on envoyait toutes les données du type, dans l'ordre prédéterminé, et sans indication de type pour les sous-objets. Dans notre cas, beaucoup des sous-objets étaient des enum, dont le type exigeait normalement un nom distingué. Sans optimization, il fallait cinq ou six octets pour le type, puis un octet de donnée.
Dans la pratique, je crois qu'on n'a jamais implémenté l'optimisation. En fait, le nombre de messages n'était pas énorme, et les connexions étaient très rapide (de l'ordre d'un à quatre gigabaud). La quantité d'octets n'était donc pas un problème.
Mais le type ne prend qu'un seul octet, même en DER, donc le 'surcoût' est bien moindre qu'en XML, où il faut bien plus d'octets pour préciser le contexte, et souvent autant pour le fermer (balise fermante).
C'est vraiment la balise fermante que je trouve de trop en XML. C'est une information rédondante, qui, dans la plupart des applications (ou le XML est généré par l'ordinateur) ne sert absolument à rien.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, Tél. : +33 (0)1 30 23 45 16
Arnaud Meurgues
wrote:
forcement pour tout ce qu'il fait. (À mon avis, tout programme qui génère du texte doit générer du LaTeX. Mais je crois que c'est un argument perdu d'avance:-).)
À vrai dire, ce n'est pas ce que je voudrais qu'ils génère. Je préfèrerais un format qui sépare bien le texte de la mise en page.
Arnaud
kanze@gabi-soft.fr wrote:
forcement pour tout ce qu'il fait. (À mon avis, tout programme qui
génère du texte doit générer du LaTeX. Mais je crois que c'est un
argument perdu d'avance:-).)
À vrai dire, ce n'est pas ce que je voudrais qu'ils génère. Je
préfèrerais un format qui sépare bien le texte de la mise en page.
forcement pour tout ce qu'il fait. (À mon avis, tout programme qui génère du texte doit générer du LaTeX. Mais je crois que c'est un argument perdu d'avance:-).)
À vrai dire, ce n'est pas ce que je voudrais qu'ils génère. Je préfèrerais un format qui sépare bien le texte de la mise en page.
Arnaud
kanze
Arnaud Meurgues wrote in message news:<3f05824f$0$12430$...
wrote:
forcement pour tout ce qu'il fait. (À mon avis, tout programme qui génère du texte doit générer du LaTeX. Mais je crois que c'est un argument perdu d'avance:-).)
À vrai dire, ce n'est pas ce que je voudrais qu'ils génère. Je préfèrerais un format qui sépare bien le texte de la mise en page.
C-à-d ? L'essentiel, c'est un format avec un mark-up logique, de façon à pouvoir changer la mise en page sans avoir à régénérer le texte. Jusqu'à là, HTML ferait l'affaire, mais il est plus limité que LaTeX, et surtout, les engins de formattage que je connais font un travail bien mois beau.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, Tél. : +33 (0)1 30 23 45 16
Arnaud Meurgues <arnaud@meurgues.non.fr.invalid> wrote in message
news:<3f05824f$0$12430$626a54ce@news.free.fr>...
kanze@gabi-soft.fr wrote:
forcement pour tout ce qu'il fait. (À mon avis, tout programme qui
génère du texte doit générer du LaTeX. Mais je crois que c'est un
argument perdu d'avance:-).)
À vrai dire, ce n'est pas ce que je voudrais qu'ils génère. Je
préfèrerais un format qui sépare bien le texte de la mise en page.
C-à-d ? L'essentiel, c'est un format avec un mark-up logique, de façon à
pouvoir changer la mise en page sans avoir à régénérer le texte. Jusqu'à
là, HTML ferait l'affaire, mais il est plus limité que LaTeX, et
surtout, les engins de formattage que je connais font un travail bien
mois beau.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, Tél. : +33 (0)1 30 23 45 16
Arnaud Meurgues wrote in message news:<3f05824f$0$12430$...
wrote:
forcement pour tout ce qu'il fait. (À mon avis, tout programme qui génère du texte doit générer du LaTeX. Mais je crois que c'est un argument perdu d'avance:-).)
À vrai dire, ce n'est pas ce que je voudrais qu'ils génère. Je préfèrerais un format qui sépare bien le texte de la mise en page.
C-à-d ? L'essentiel, c'est un format avec un mark-up logique, de façon à pouvoir changer la mise en page sans avoir à régénérer le texte. Jusqu'à là, HTML ferait l'affaire, mais il est plus limité que LaTeX, et surtout, les engins de formattage que je connais font un travail bien mois beau.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, Tél. : +33 (0)1 30 23 45 16
Arnaud Meurgues
Christophe de Vienne wrote:
Que penses-tu de DocBook ?
Pas grand chose car je ne connais pas.
ça correspond assez à ce que tu cherches non ?
C'est possible. D'après ce que j'ai feuilleté sur docbook.org, ça ressemble à ce que j'aimerais avoir. C'est même très intéressant.
Arnaud
Christophe de Vienne wrote:
Que penses-tu de DocBook ?
Pas grand chose car je ne connais pas.
ça correspond assez à ce que tu cherches non ?
C'est possible. D'après ce que j'ai feuilleté sur docbook.org, ça
ressemble à ce que j'aimerais avoir. C'est même très intéressant.
C'est possible. D'après ce que j'ai feuilleté sur docbook.org, ça ressemble à ce que j'aimerais avoir. C'est même très intéressant.
Arnaud
Christophe de Vienne
Julien Blanc wrote:
Christophe de Vienne wrote:
Sinon comme programme/format interessant, il y a Lyx. C'est du WYSIWYM (M pour Mean), et ça utilise LatTex pour produire le document final.
bof... Lyx m'a toujours laissé très circonspect. Je le trouve assez moche, assez mal foutu, et au final aussi difficile à utiliser qu'un word qui est plus joli. L'avantage serait le rendu LaTeX derrière, mais bon... Je crois vraiment qu'au final on va beaucoup plus vite à écrire directement du LaTeX qu'à passer par un outil assez mal foutu tel que Lyx.
hum hum. On ne vas pas lancer un débat mais je ne suis pas d'accord... En tous les cas je t'invite à essayer la dernière version (1.3.2) avec le frontend QT, et tu verras que c'est sans comparaison avec ce que tu as pu en voir.
-- Christophe de Vienne Experience is something you don't get until just after you need it. Oliver's Law.
Julien Blanc wrote:
Christophe de Vienne wrote:
Sinon comme programme/format interessant, il y a Lyx. C'est du WYSIWYM (M
pour Mean), et ça utilise LatTex pour produire le document final.
bof... Lyx m'a toujours laissé très circonspect. Je le trouve assez
moche, assez mal foutu, et au final aussi difficile à utiliser qu'un
word qui est plus joli. L'avantage serait le rendu LaTeX derrière, mais
bon... Je crois vraiment qu'au final on va beaucoup plus vite à écrire
directement du LaTeX qu'à passer par un outil assez mal foutu tel que Lyx.
hum hum. On ne vas pas lancer un débat mais je ne suis pas d'accord... En
tous les cas je t'invite à essayer la dernière version (1.3.2) avec le
frontend QT, et tu verras que c'est sans comparaison avec ce que tu as pu
en voir.
--
Christophe de Vienne
Experience is something you don't get until just after you need it.
Oliver's Law.
Sinon comme programme/format interessant, il y a Lyx. C'est du WYSIWYM (M pour Mean), et ça utilise LatTex pour produire le document final.
bof... Lyx m'a toujours laissé très circonspect. Je le trouve assez moche, assez mal foutu, et au final aussi difficile à utiliser qu'un word qui est plus joli. L'avantage serait le rendu LaTeX derrière, mais bon... Je crois vraiment qu'au final on va beaucoup plus vite à écrire directement du LaTeX qu'à passer par un outil assez mal foutu tel que Lyx.
hum hum. On ne vas pas lancer un débat mais je ne suis pas d'accord... En tous les cas je t'invite à essayer la dernière version (1.3.2) avec le frontend QT, et tu verras que c'est sans comparaison avec ce que tu as pu en voir.
-- Christophe de Vienne Experience is something you don't get until just after you need it. Oliver's Law.
kanze
Arnaud Meurgues wrote in message news:<3f0a8c09$0$12465$...
wrote:
préfèrerais un format qui sépare bien le texte de la mise en page. C-à-d ?
C'est-à-dire qu'il n'y ait aucune info de mise en page dans le texte, mais seulement une information structurelle. Quelque chose comme le couple HTML/CSS, mais mieux découplé. LaTeX n'est pas complétement découplé non plus et contient des informations de mise en page.
Pas normalement. Au moins, pas le LaTeX que j'écris moi. (On peut, évidemment, toujours s'échapper au TeX, sur lequel il est bâti. Mais c'est tricher.)
Un document LaTeX se divise en fait en deux parties, un en-tête et le corps du document. Dans le corps du document, normalement, il n'y a rien que du formattage logique. Dans l'en-tête, on précise comment traiter les éléments logiques, au moyen du « documentclass », des packages, et des commandes qu'on définit. Mais rien n'empèche à créer son propre « documentclass », qui se base sur un documentclass existant, et qui inclut les packages et définit les commandes dont on aura besoin. De manière à ce que la seule commande dans l'en-tête soit la spécification du documentclass ; le fichier ne contient alors rien d'autre de formattage physique.
XML/XSLT pourrait être un candidat, mais il est trop complexe parce que pas assez spécialisé.
L'essentiel, c'est un format avec un mark-up logique, de façon à pouvoir changer la mise en page sans avoir à régénérer le texte.
Mais sauf erreur, LaTeX ne se limite pas à un markup logique. Il contient (ou peut contenir) aussi des informations physiques.
Normalement pas du tout dans le corps du document, et la plupart du temps, seulement à travers l'inclusion des packages dans l'en-tête. Et si certains package ont bien affaire au formattage physiques (palatino, par exemple), d'autres sont plus abstraits -- ils spécifient l'encodage en entrée, par exemple, ou la langue, et d'autres ne concerne que le contenu -- le titre, par exemple (qu'on spécifie dans l'en-tête parce que dans certains styles, il peut apparaître sur chaque page).
Jusqu'à là, HTML ferait l'affaire, mais il est plus limité que LaTeX, et surtout, les engins de formattage que je connais font un travail bien mois beau.
Là, je suis d'accord avec toi.
Beauté qui se paie en temps CPU. LaTeX est sans doute parmi les moins rapides des systèmes de formattage. Mais de nos jours, au moins d'avoir des besoins énormes...
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Arnaud Meurgues <arnaud@meurgues.non.fr.invalid> wrote in message
news:<3f0a8c09$0$12465$626a54ce@news.free.fr>...
kanze@gabi-soft.fr wrote:
préfèrerais un format qui sépare bien le texte de la mise en page.
C-à-d ?
C'est-à-dire qu'il n'y ait aucune info de mise en page dans le texte,
mais seulement une information structurelle. Quelque chose comme le
couple HTML/CSS, mais mieux découplé. LaTeX n'est pas complétement
découplé non plus et contient des informations de mise en page.
Pas normalement. Au moins, pas le LaTeX que j'écris moi. (On peut,
évidemment, toujours s'échapper au TeX, sur lequel il est bâti. Mais
c'est tricher.)
Un document LaTeX se divise en fait en deux parties, un en-tête et le
corps du document. Dans le corps du document, normalement, il n'y a rien
que du formattage logique. Dans l'en-tête, on précise comment traiter
les éléments logiques, au moyen du « documentclass », des packages, et
des commandes qu'on définit. Mais rien n'empèche à créer son propre
« documentclass », qui se base sur un documentclass existant, et qui
inclut les packages et définit les commandes dont on aura besoin. De
manière à ce que la seule commande dans l'en-tête soit la spécification
du documentclass ; le fichier ne contient alors rien d'autre de
formattage physique.
XML/XSLT pourrait être un candidat, mais il est trop complexe parce
que pas assez spécialisé.
L'essentiel, c'est un format avec un mark-up logique, de façon à
pouvoir changer la mise en page sans avoir à régénérer le texte.
Mais sauf erreur, LaTeX ne se limite pas à un markup logique. Il
contient (ou peut contenir) aussi des informations physiques.
Normalement pas du tout dans le corps du document, et la plupart du
temps, seulement à travers l'inclusion des packages dans l'en-tête. Et
si certains package ont bien affaire au formattage physiques (palatino,
par exemple), d'autres sont plus abstraits -- ils spécifient l'encodage
en entrée, par exemple, ou la langue, et d'autres ne concerne que le
contenu -- le titre, par exemple (qu'on spécifie dans l'en-tête parce
que dans certains styles, il peut apparaître sur chaque page).
Jusqu'à là, HTML ferait l'affaire, mais il est plus limité que
LaTeX, et surtout, les engins de formattage que je connais font un
travail bien mois beau.
Là, je suis d'accord avec toi.
Beauté qui se paie en temps CPU. LaTeX est sans doute parmi les moins
rapides des systèmes de formattage. Mais de nos jours, au moins d'avoir
des besoins énormes...
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Arnaud Meurgues wrote in message news:<3f0a8c09$0$12465$...
wrote:
préfèrerais un format qui sépare bien le texte de la mise en page. C-à-d ?
C'est-à-dire qu'il n'y ait aucune info de mise en page dans le texte, mais seulement une information structurelle. Quelque chose comme le couple HTML/CSS, mais mieux découplé. LaTeX n'est pas complétement découplé non plus et contient des informations de mise en page.
Pas normalement. Au moins, pas le LaTeX que j'écris moi. (On peut, évidemment, toujours s'échapper au TeX, sur lequel il est bâti. Mais c'est tricher.)
Un document LaTeX se divise en fait en deux parties, un en-tête et le corps du document. Dans le corps du document, normalement, il n'y a rien que du formattage logique. Dans l'en-tête, on précise comment traiter les éléments logiques, au moyen du « documentclass », des packages, et des commandes qu'on définit. Mais rien n'empèche à créer son propre « documentclass », qui se base sur un documentclass existant, et qui inclut les packages et définit les commandes dont on aura besoin. De manière à ce que la seule commande dans l'en-tête soit la spécification du documentclass ; le fichier ne contient alors rien d'autre de formattage physique.
XML/XSLT pourrait être un candidat, mais il est trop complexe parce que pas assez spécialisé.
L'essentiel, c'est un format avec un mark-up logique, de façon à pouvoir changer la mise en page sans avoir à régénérer le texte.
Mais sauf erreur, LaTeX ne se limite pas à un markup logique. Il contient (ou peut contenir) aussi des informations physiques.
Normalement pas du tout dans le corps du document, et la plupart du temps, seulement à travers l'inclusion des packages dans l'en-tête. Et si certains package ont bien affaire au formattage physiques (palatino, par exemple), d'autres sont plus abstraits -- ils spécifient l'encodage en entrée, par exemple, ou la langue, et d'autres ne concerne que le contenu -- le titre, par exemple (qu'on spécifie dans l'en-tête parce que dans certains styles, il peut apparaître sur chaque page).
Jusqu'à là, HTML ferait l'affaire, mais il est plus limité que LaTeX, et surtout, les engins de formattage que je connais font un travail bien mois beau.
Là, je suis d'accord avec toi.
Beauté qui se paie en temps CPU. LaTeX est sans doute parmi les moins rapides des systèmes de formattage. Mais de nos jours, au moins d'avoir des besoins énormes...
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
