Obsidian a écrit 5299 commentaires

Non, mais il a dit « Sous Windows, si possible ».
Comme en plus, ce genre d'info profite à tout le monde, ton commentaire a donc bien sa place ici ! :-)

Tu peux aussi voir ici:
http://jipe.homelinux.org/bash_scripts/mp32ogg.html(...)

Sinon peut-être que sox peut le faire maintenant, j'ai pas vérifié ...

Audacity doit faire cela bien ...

Parce qu'il suffit d'un seul secteur défectueux pour tout compromettre.

Un FS minimaliste est effectivement indiqué pour récupérer le maximum d'espace disponible, mais il faut au minimum garantir l'intégrité du support ...

Très bien ! :-)

En fait, on voit surtout que dans le secteur de la recherche, Unix est très privilégié. Moralité, les gens érudits choisissent d'eux-même le meilleur système (attention: un troll se cache dans ce commentaire) ...

Sinon moi je viens de manger une pomme. Je fais un journal ?

Tu veux dire qu'à toi tout seul, tu a réussi à absorber Apple ? Ben oui, fais un journal ! Une news de première page, même ! :-) Sinon, peux-tu nous dire ce que sera le futur de MacOS X ?

Et un [+] bien mérité !

Il n'y a donc pas de quoi s'inquiéter, 640Ko^W1 Ti/s ce sera largement suffisant pour tout le monde !

C'est ce que disait Bill Gates aussi ...
Ceci dit je ne suis pas pressé de voir arriver une technologie qui a nécessairement besoin d'un taux de transfert aussi élevé pour fonctionner correctement.

En tout cas, pour l'instant, c'est effectivement une bonne nouvelle. Espérons que l'on ne gaspillera pas cette ressource !

Je pense que chaque fois que l'on traite un fichier en read-only, on devrait utiliser mmap. Cela laisse carte blanche à l'OS quant à la manière dont il va gérer le chargement. Le mappage d'un fichier en mémoire s'appuie sur la gestion de la mémoire virtuelle, à ceci près que les données sont directement lues ou écrites dans le fichier concerné plutôt que dans un fichier ou une partition de swap.

C'est vraiment ce qu'il y a de plus rapide et de plus simple à la fois.

En revanche, pour utiliser mmap, il faut forcément que:

• Le fichier soit un fichier régulier et de taille définie (on ne s'imaginerait pas mapper en mémoire un truc comme /dev/zero par exemple);
• Dé préférence, avoir le fichier sur un filesystem local, sinon tout le gain en performance est grêvé par les accès réseau, dont on ne peut d'ailleurs plus prévoir quand ils auront lieu. Et même sans cela, en local, le système peut faire des optimisations et aller lire directement les secteurs du disque. Sur d'autres filesystem, la fonction doit quand même passer par des appels fichiers standard.

Ceci dit, ces deux conditions sont remplies 90% du temps. De plus, quand on travaille sur des fichiers de plusieurs Gigas, cela permet au système de savoir exactement ce que tu comptes faire et de s'organiser en conséquence. Si tu travailles sur une machine multi-utilisateurs, tes collègues t'en seront reconnaissants.

Je ne sais pas si c'est a cela qu'il font reférence, mais il me semble que la poudre bleue ou verte qui brille dans la nuit, cela existe déjà:

http://www.google.fr/search?q=Phosphorescent+powder&ie=UTF-8&am(...)

http://www.unitednuclear.com/glow.htm(...)

Succursale ou contrefaçon ? :-)

Héhéhé, il faut dire que le rapport précisait qu'il s'agissait d'un « composé chimique incolore, inodore et insipide, mais qui peut s'avérer mortel en cas d'inhalation accidentelle » ! C'est effectivement incontestable :-)

le mec bourré avec sa voiture tuning-tuning s'est encastré dedans, il est mort.

« Darwin à l'oeuvre » pour reprendre un commentaire plus haut.

« Non, non, non ... 10% maximum ! », dixit un quidam interrogé par Philippe Vandel.

Authentique !

Il y a mieux: Il y a quelque temps, à l'époque des attentats (mais avant ceux de Madrid), on avait retrouvé chez des « islamistes » des composants électroniques (donc pouvant servir à réaliser des détonateurs), mais également des bouteilles de perchlorure de fer, lequel pouvait soit disant exploser dans des conditions adéquates ...

Rappelons que le perchlorure de fer sert à révéler les circuits imprimés, que tout électronicien amateur en a au moins un flacon chez lui, et que si ce perchlorure peut être explosif dans les « conditions adéquates », il le sera à mon avis toujours moins que de l'alcool à brûler, par exemple.

Bref, cela m'a fortement rappelé l'usage illicite de PHP ( http://bbspot.com/News/2000/6/php_suspend.html(...) ), sauf que cette fois c'était sérieux, et fortement relayé par les journalistes. Comment entretenir une psychose ...

Au fait, de telles news sont-elles encore compatibles avec notre LEN bienveillante ?

C'est clair ! Parfois je me demande ce qui se passe dans la tête du PDG de cette boite. Microsoft a tout tenté pour couler ce trublion, et voila qu'il leur donne le moyen de le faire ...

A moins que ce soit volontaire. Après avoir tout tenté dans cette affaire, c'est peut-être un moyen d'en finir à bon compte et avec un bon pactole ...

Qui vivra verra.

Excellent ! Et puis d'ailleurs, dès le premier paragraphe, on lit:

I saw my first Masquerade at Penguicon 1.0, in April 2003. I decided that that looked like fun, and I wanted to do something like it. I'd idly pondered a TRON costume in the past, and this seemed like the perfect venue for it, being a cross between a Linux and SF con.

Finalement, il y a bien un rapport ! :-)

En effet, ce doit être tout à fait légal, mais je pense qu'avec trois combinaisons, tu as plus à perdre à utiliser ce type de stockage que du code conventionel. En ce sens, réaliser une démo tenant en 8Ko par ce moyen tient plus de la prouesse que de la gruge ...

Non, les -D sont interdits par le règlement. Sinon ce serait effectivement trop facile.
Par contre, dans l'exemple présent, il ne s'agissait pas de données compressées mais d'un bout de code assembleur appelé par un pointeur de fonction ...

A noter que sans espace ni tab ni \n, le fichier ne doit pas faire plus de 8192 octets

C'est avec les espaces, tabulations et retours chariot que le fichier ne doit pas dépasser 8192 octets. Sans ces caractères, le nombre de signes doit précisément être inférieur à 4096 !

Sans cela, à propos des démos en mode texte, il est précisé qu'aucun appel à une API externe autre que la SDL n'est autorisé, ni aucun appel système spécifique à un OS (Exit Direct3D ou X11). On doit en outre utiliser le C ou C++ ANSI.

La question, donc: A-t-on droit au printf, faisant partie de standard C ANSI, étant totalement portable, mais appartenant à la bibliothèque standard du C (donc accessible via une API).

Si oui, tant mieux, je fais un appel bidon à la SDL et je code toute ma démo en mode texte,
Si non, c'est ennuyeux parce que je n'aurais pas le droit non plus aux malloc par exemple ...

Alors a ce sujet, j'en profite pour reposter ce que je viens d'écrire dans un journal. Des trucs du style:

void main (void)
{
     char x[] { 0xb8,0x00,0x4c,0xcd,0x21 };
     ((void (*)(void))x)();
}

... sont-ils autorisés ? :-) Cela me rappelle le temps où, lorsque les L4G commençaient à devenir vraiment à la mode, on s'était amusé à estimer la taille du plus petit exécutable réalisable sous DOS. J'étais descendu à 2 octets: CD 20. Une vieille interruption servant à terminer un programme aux premiers temps du DOS. Je me suis quand même fait battre: 1 octet avec RET, stocké dans un COM, en sachant que la pile pointait initialement sur un mot à 0000 en fin de segment, que le début dudit segment débutait toujours par le PSP, et que par norme ce PSP débutait, lui, par CD 20. C'est en tout cas une très bonne chose. Cela fait vivre les démos, devenues rares avec la débauche de puissance et la domination quasi-totale du PC, et cela rappelle aux jeunes programmeurs ce qu'est l'optimisation. Un seul mot: Bravo.

A-t-on le droit pour autant d'écrire des trucs du style:

void main (void)
{
     char x[] { 0xb8,0x00,0x4c,0xcd,0x21 };
     ((void (*)(void))x)();
}

Moi c'est la première chose que je ferais ! :-)

Au fait, *.sxw, ça veut dire Word sux ?

De toute façon, l'égout et l'écouleur, ça ne se discute pas ! :-)

Je plussoie avec véhémence !
Je ne connaissais pas du tout, et je pense que cela me rendra aussi de nombreux services ! Merci.