thedude a écrit 2062 commentaires

C'est bien ça : pour être utilisateur sur Mac, il faut se plier à ce qui a été pensé à la place de l'utilisateur. Donc, je ne suis pas fait pour Mac.
C'est pas possible autant de mauvaise foi!!!
T'as pas l'impression que ton argument est retournable?
Que sous linux, il faut se plier a ce qui a ete pense a la place de l'utilisateur parce que le bouton maximise met en plein ecran?

Evidemment qu'il faut se plier aux raccourcis qui ont ete concu.

Apres, tes exemples avec safari me font lever un sourcil, je me rappelle honnetement pas de la derniere fois ou j'ai clique sur le bouton vert pour mon navigateur. Comme macos a l'intelligence de se rappeler la taille de la fenetre, c'est un reglage auquel je touche jamais.
Tu noteras pour le coup que c'est pareil sous windows avec chrome que je ne redimensionne que tres rarement.
Mon chrome au taff fait 1400px de large, notamment a cause de la barre de bookmark assez fournie, celui a la maison doit faire dans les 1024+ (mais pas des masses de plus).
Ca me laisse 200px (taff) a 400px (maison) pour afficher plein de trucs, genre mon IE pour tester l'appli, mes explorateurs de fichier ou mon eclipse pour switcher plus facilement qu'en cliquant la barre des taches.

L'exemple du monde parait etre un bug, je jetterais un oeil en rentrant ce soir.

Par contre, je suis content d'avoir ma fenetre du finder qui se met a la bonne taille sans m'afficher 600*400 pixels vides. Idem pour text edit ou n'importe quelle autre appli d'ailleurs.

J'attends toujours un quelconque argument en faveur du maximiser pour tous, a part le "mais c'est mieux comme ca, parce qu'on a toujours fait comme ca".
Par contre, pour le mode fenetre, t'as un gros gain de place utilise a l'ecran qui te permet d'afficher plein d'autre chose a cote, et ca c'est rudement pratique.

quelle est la part de traffic depuis ces mirroirs? Je doute que ca donne a free un poids demesure.
pourquoi un accord gagnant gagnant ne pourrait pas etre mis en avant? Ca contribue ou ca contribue pas?
Pourquoi diable est ceque free n'a pas le droit de retirer des avantages de sa contrib?

oui et non.

avi est amene a mourir et mp4/mkv sont de bons remplacants.

Par contre, ce qui me saoule beaucoup du coup, cest que le support de l'ac3 dans mp4 par quicktime est pour le moins rock n roll et que le mkv ne me plais pas plus que ca (sans compter que l'ajout d'une piste subtitle a l'air de faire ramer le bestiau).

Bref, j'ai le choix entre laisser tomber le 5.1 dans les films, en chier copieux pour faire marcher quicktime avec l'ac3 dans du mp4 (si j'y arrive avant qu'apple patche son foutu qt pour ne pas avoir a reassigner les channels audio, a supposer qu'ils le fassent un jour) ou rester a la version 0.9.3 avec avi+ac3.

Mais continuer a encoder de l'ac3 dans de l'avi alors que c'est pas cense marche, c'est pas une solution long terme non plus.

c'est bien ce que je dit.
Il faut saigner, souffrir pour ne pas etre un sale profiteur du libre.
Un accord gagnant gagnant est totalement inconcevable apparement.

Tu parles d'un esprit de partage...

moi j'aimerais bien qu'ils se bougent le cul pour m'envoyer un cheque de 10 000 euros, mais je doute que ca arrive.
Pourquoi?
Parce que, comme pour leurs modifs du kernel, ils n'ont aucune obligation de le faire, meme s'ils peuvent le faire si ca les chante.

Quand a enerver plus d'un libriste, c'est pas dur, suffit de s'approcher d'un bout de code gpl pour que certains commencent a grogner (tout en se vantant de "partager" a cote).

Quand a profiter a mort du libre, je suis loin d'etre convaincu que free qui heberge nombre de mirroirs et distribue vlc dans qq millions de foyers se contentent uniquement de "profiter" a mort du libre.
Apres, t'aurais ptetre prefere qu'ils fournissent une solution basee sur WMP? Ou leur propre player proprio?
Plutot que d'utiliser des technos ouvertes.

M'enfin, toujours le meme probleme, tant que t'as pas prete allegeance a rms, ni lui a offert droit du cuissage sur toutes les femelles de ta famille, t'es un "mechant qui profite a mort du libre, bouh, caca".

ben d'un autre cote, personne l'empeche de maximiser sa fenetre, l'utilisateur, c'est juste que le raccourci en haut a gauche est plus malin que "tout ou rien" et demande a l'application de quelle taille elle a besoin (note bien le mot "besoin") et lui donne.
S'il se trouve que le besoin est plus grand que l'ecran, alors ca maximise, il est pas bien fait le monde?
Personne n'a jamais pretendu que ce bouton voulait dire "met l'appli en plein ecran".

Ensuite pour la maximisation, tu assumes que le bouton vert veut dire maximisation parce que windows lui a donne ce sens, mais je suis pas sur qu'il ait jamais voulu dire autre chose que "aggrandit la fenetre a la taille dont elle a besoin".

tu noteras pourtant que:
- les boutons ne sont pas place au meme endroit
- ils n'ont pas la meme couleur/forme/icone
- ils n'ont pas le meme ordre

Pourquoi donc partir du principe que le bouton vert a droite fait la meme chose que le bouton du milieu avec une icone differente sous windows ou linux?

Que dire des applis dont la taille est fixee sinon?
Et sinon, quel est l'interet d'afficher une page web avec des lignes 450 caracteres ou 400 pixels vide de part et d'autre de la page, sinon emmerder l'utilisateur?
Les applis webs? J'ose esperer que l'appli web va declarer une taille qui lui convient (potentiellement plus grand que l'ecran si besoin, auquel cas on retombe sur la maximisation).

Bref, a part "parce que" je vois pas trop de raison valables a la critique.

ils sont passe a la 0.9.4 tres recemment d'ailleurs.

Interface amelioree, support du rip des VobSub dans une track differente pour les mkv (wouhou!!), ajout du dts passthrough, support de coreaudio pour l'aac sous macos et apparement integration de la derniere version de x264 qui va plus vite plus loin et plus mieux.
Et en cadeau bonux, un live preview qui permet de voir si on a pas oublier le filtre de desentrelacage et autres joyeusetes.

Ils ont en revanche droppe le support de l'avi et de l'ogv si je ne m'abuse.

Bref, (presque) que du bon, me reste plus qu'a regler un dernier pb avec ce foutu quicktime/frontrow et le mp4+ac3/dts qui se melange les pinceaux sur l'assignation des 6 canaux et ca sera du tres tres bon (d'ailleurs si quelqu'un s'y est deja frotte, je suis preneur d'infos, meme si j'ai une pitite idee de comment m'en sortir).

Ah, et apparement, ils supportent l'encodage d'image blu ray (non chiffrees malheureusement), ce qui est tres agreable aussi.

apple est au contraire tres sobre, epure et tres loin du bling bling.

C'est propre et bien leche, mais certainement pas bling bling.
Regarde les couleurs utilisees de base pour t'en convaincre, par exemple (teinte grises/noires avec un peu de bleu pas franchement youpi yahoo fluo, c'est la fete).

calme toi, dans le fond on est d'accord, j'essaye juste d'expliquer pourquoi un point de vue different est defendable.
Je defend pas boulay, il troll comme un fou et le post de beagf plus bas sur l'ouverture de la communaute me parait tres pertinent a la lecture de ce fil.

Cela dit, meme si je saisi tres bien la difference entre interprete et jit, j'ai toujours tendance a faire une distinction entre jit et compile nativement. Le code compile nativement tourne tout seul. Le code a jit ne peut pas tourner sans un enorme bout d'autre code qui va se placer entre le cpu et le bytecode pour le transformer en code executable a la volee.

Meme si je trouve que l'approche jit est plus maline, souple et agreable pour le developpeur, ca n'empeche pas que ce sont des approches tres differentes, et qu'il est comprehensible de faire une difference entre compilation native et compilation bytecode.

Je sais tres bien que mettre du code interprete en cache n'est pas du jit, mais s'il ya cache, c'est qu'il ya une forme de compilation, non? Le texte est analyse lexicalement, syntaxiquement, puis semantiquement et transforme en tokens de haut niveau, token qui seront ensuite execute par l'automate de l'interprete, mais t'as une bonne partie de la chaine de compile qui est faite et cachee, donc l'un dans l'autre...
Les frontieres sont extremements floues dans ce domaine, c'est pourquoi j'ai du mal a accepter une vision tranchee (d'un cote comme de l'autre, tu noteras).

Et oui, j'ai tres bien saisi que le bytecode est targete pour une machine virtuelle (hence, le terme compilation), et que ta vm peut etre retournee sous forme de lib.

Ridicule. Un langage est un langage, point.
Beaucoup de langages peuvent se compiler et s'interpréter. La présence d'une VM est une problématique différente.

Un langage est un langage, certes, mais tu ne m'enleveras pas de l'idee est que chaque langage vient avec une philosophie.
Et cette philosophie inclue la chaine de compilation, interprete, bytecode ou natif pur.
Et ca inclue aussi le runtime de base du langage, et le fait de savoir si on peut faire confiance a une couche en dessous, qui va verifier que tu ne dereference pas un pointeur null, que t'as acces a tel api d'ecriture sur le disque qui va verifier tes droits et tout ce genre de connerie, couche qui s'appelle une VM, verifie la signature du code, que la version de la lib est la bonne etc.

Faire du java sans le rt.jar ni la jvm je vois pas franchement l'interet. Tu te tapes un langage ultra verbeux avec une semantique ultra limitee et peux expressive, avec une implem des generics inutilisable des que tu cherches a aller plus loin que List et tu doit en plus te taper tout les checks d'integrite pour pas que ton code explose en plein vol.
De meme pour les "libs" d'aop qui fonctionnent en manipulant en temps reel le bytecode, je doute que ca soit faisable decemment avec du code natif (ou en tout cas, j'aimerais bien voir comment).

Java, c'est un langage a VM, meme si la spec du langage en soit est techniquement decorrelle de la vm, mais je n'arrive pas a imaginer un seul interet a implementer le langage en dehors de la vm. De meme, j'ai jamais compris a quoi pouvait bien servir gcj (bon, ok, jvm pas libre tout ca, mais c'est plus le cas).
Certes, ta la lib de base, mais c'est quoi l'interet de perdre la portabilite pour des perfs sensiblement equivalentes?

C'est pareil pour C#, python, javascript et tout le tralala.
Javascript est designe pour tourne sur une VM. Un interpreteur etant une forme tres primitive (mais vraiment tres primitive) de VM, et vu que personne n'a utilise le js pour autre chose que de faire des bandeaux dans la barre d'etat, les navigateurs ont toujours eu une approche interpretation, c'est pas parce qu'il se sont reveille face a flex et silverlight et on sorti l'artillerie lourde de VM efficace que ca veut dire que le langage a un quelconque sens compile en code natif sans avoir de jit. Et si t'as du jit, t'as une vm en dessous, on retombe donc sur: js est un langage designe pour avoir une vm (primitive ou evoluee) en dessous.

Lisaac qui est designe pour etre execute de facon native.
Mais s'il est faisable d'ecrire un compilo lisaac qui target mono ou le bytecode de la jvm, personne ne le fera parce que ca n'a pas de sens.
De meme pour du C, compiler un langage aussi aride que C vers du bytecode et le faire tourner dans une vm, j'ai du mal a voir l'interet.

pfiou, c'est dur ce matin.

Auquel cas, lisaac serait le premier langage compile a prototype, mais il s'est fait grille la politesse par les langage a VM a prototype.

en fait non, il s'est meme fait griller la politesse par les langage compile a prototype, vu que si j'ai bien suivi, jscript.net sans l'utilisation d'eval peut compiler AOT et ne pas utiliser de generation de code en runtime?

Super, je vais pas te donner tout le code généré par le compilateur.
Je sais bien, c'etait une question rethorique.
Tu sais tres bien qu'il faut embarquer un compilateur pour ca, c'etait juste une facon (certes qq peu trollesque) de le faire remarquer.

Ce bytecode est traité après de manière classique par le CLR, et donc compilé en code natif à la volée avant exécution.
Oui, je suis pas idiot et je me doute bien que c'est comme ca qu'il fonctionne, MS a une VM plutot bien gaulee, ca serait dommage de pas l'utiliser.

Oui, celà nécessite un runtime qui s'occupe d'implémenter eval, n'en reste pas moins que le code est tôt ou tard compilé en code natif avant exécution (plutôt tard pour le cas de eval).
Oui, j'ai fait la meme remarque (et pour eval, c'est meme tres tres tard, puisque semantiquement tu ne peux pas compiler avant d'arriver sur l'appel. Mais c'est pas ce qui est important aussi).

On pourrait aussi dire la meme chose pour un langage interprete: au final, ca va tourner sur le processeur, ya donc du code machine qui est genere d'une facon ou d'une autre.
Tu n'oserais pas pretendre pour autant qu'un langage interprete est compile?
Pour une implem vraiment bateau d'un langage interprete, c'est effectivement pas compile, mais quiconque de cense va implementer un cache pour pas reinterpreter la meme focntion en permanence, et tu te retrouves donc avec une generation de code, aka compilation.

Ce que je veux dire c'est que l'argument: au final, on genere du code machine pour l'executer, donc c'est compile un peu biaise, tu vas necessairement devoir generer du code machine a un moment ou un autre, sinon ton bout de code, il va pas te servir a grand chose.

2 choses :
- cette limitation s'applique à l'AOT pour Mono 2.0. En mode JIT, qui reste de la compilation sans aucune interprétation, les generics sont totalement supportés.
- cette limitation n'existe plus dans les version plus récentes, Mono 2.0, c'est vieux.
Oui, je me doute bien, j'ai pas precise dans mon commentaire, mais je n'ai jamais doute un instant que MS ne supportait pas ca, donc pas de raison que mono ne puisse le faire.

Ensuite le soucis vient d'une fonction, eval. Aucun doute que si Lisaac avait l'équivalent ils n'auraient d'autre choix que de faire de la compilation à la volée.
Certes, mais eval fait partie de javascript. Supporter tout javascript sauf eval, c'est supporter un subset de javascript. Si tu peux pas supporter eval en natif, tu ne supportes pas JavaScript en natif, juste un subset.
Tres honnetement, ca me derangerais pas plus que ca, je trouve ca heretique de pouvoir executer du code qui vient de n'importe ou, mais ca reste un truc qui fait partie du langage.

Bref, au final, tout ce long thread vient, je pense d'un probleme tout con: vous avez l'air de considerer qu'il n'y a que 2 type de langages: compile ou pas.
Tu vois mono comme compile, vu qu'il y a une phase de compilation. On peut pas dire que t'as tord, mais on peut pas dire que t'as raison non plus.
Il voit mono comme non compile, vu qu'il target une archi qui n'existe pas, et que le bytecode est de trop haut niveau pour etre considere comme du code machine. On peut pas dire qu'il a tord, mais on peut pas dire qu'il a raison non plus.

Bref, le probleme c'est peut etre qu'il faut introduire une troisieme categorie, ce qui nous laisse avec:
- interprete
- langage a VM
- langage compile.

Auquel cas, lisaac serait le premier langage compile a prototype, mais il s'est fait grille la politesse par les langage a VM a prototype.

Personne a tord, personne a raison.
D'un point de vue purement theorique, oui, tu peux compiler ton code javascript vers un code machine qui va faire ce que tu veux.
Va bien falloir si tu veux le faire tourner sur un processeur de toutes facons.

Apres, si JavaScript (et pas un langage derive de JavaScript, du javascript quoi), est compilable en code natif, donne moi le code natif (archi de ton choix), du bout de code suivant:

var x=5;
eval("var z=5");
eval("x+=z");
alert(x);

Et encore, je suis gentil, les parametres d'eval sont des constantes, ton compilo js pourrait etre assez malin pour derouler le contenu d'eval (mais bon courage pour implementer ca de facon semantiquement correct, genre redeclaration de variable qui doit generer une erreur runtime et non a la compilation et tout ce genre de joyeusete).
Rajoute les closures par dessus toutes ces joyeusete, tu vas t'amuser.

Mon petit doigt me dit que tu vas devoir embarquer un bout de code natif tellement gros qu'on pourra aisement qualifier ton binaire de VM compilant un code inexecutable tel quel, et donc le placer dans la categorie des langages non compile nativement.
Apres, tu peux te limiter a subset du langage, comme Mono le fait si j'en crois le site web. Ca ne supporte d'ailleurs pas les generics, c'est ballot quand meme, ca fait un peu retour a java 1.4.

Reste apres le pignolage pour savoir ce que compiler veut dire, par opposition a compiler nativement, qui qu'est arrive le premier et qui qu'a la plus grosse, je ne m'aventurerais pas sur cette pente savonneuse. Sauf pour la plus grosse, c'est moi bien evidemment.
Personellement, dans le contexte, j'ai compris ce qu'il voulait dire, mais c'est surement aussi parce que je connais deja lisaac et que je sais qu'en vrai, ca genere du C derriere, donc j'ai naturellement fait l'association compiler = compiler nativement.

Toujours est il que certain langages sont par nature tres dynamiques et leur execution de facon semantiquement correcte ne peut se faire qu'en compilant a la volee leur code.
JavaScript en fait partie.
D'aucuns considerent qu'une compilation a la volee en prerequis exlue d'emblee pour le qualificatif "compilation native", et quelque part, c'est dur de leur donner tord.

Apres, ca veut pas dire que le code compile, c'est du code de tatoue, de dur, de vrai, avec des couilles grosses comme des pasteques et que le bytecode c'est pour les tapettes ne pouvant se passer de leur flexi felix.

Allez, pti bisou la?

et je continues de boycotter tout ce qui est israelien

Question bete, juif ou israelien? c'est pas exactement la meme chose, mais si c'est le premier cas, aux us, t'es mal barre quand meme.

Quid d'une boite israelienne dirigee par des athees/agnostiques/non feuj?

C'est pas parce que le service est payant que la foobox ou le boitier tele sont loue.
Tu sais pourtant tres bien que la ligne de defense de free, c'est que les boitiers sont un equipement reseau leur appartenant, qu'ils exploitent eux et qu'ils doivent entreposer chez le client pour des raisons techniques.
T'as beau repeter que parce que de l'argent est echange, la foobox est loue, mais a part repeter que c'est comme ca et pis c'est tout, t'as jamais rien prouve jusqu'a present.

Faut pas prendre les avocats de Free pour des cons, c'est pas comme si xavier niel etait pas un habitue des situations border line, et c'est pas comme si free regorgeant pas de techie bien au fait des tenants et aboutissants des licences libres.

Apres libre a toi de considerer que Free est un lapin de 3 jours qui n'a pas etudie en detail la question avant de lancer son offre, revolutionnaire a l'epoque, de freebox, et de baser tout son business model FAI la dessus.

mmmh, ben au temps pour moi alors.
J'etais intimement persuade que les compilos utilisaient des heuristique pour des optimisations poussees, genre predire les branchement, et que ce genre d'algos n'etaient pas deterministes (bien que produisant un code correct).
La doc de ce flag n'aide pas franchement en plus.

Dont acte.

je suis pas convaincu que ca aide a arreter en quoi que ce soit.

Un des gros problemes avec les addictions, c'est le rituel qui va autour.

Le fumeur de bedos aiment bien preparer son filtre, rouler son tonje, faire son collage, tasser son bedo, que sais je encore.
L'heroinomane se plait a preparer sa mixture dans sa cuillere, le coke a se faire des lignes parfaitement egales pendant 45 minutes.
L'alcoolique aime bien deboucher la bouteille, voir l'alcool couler, se faire son petit cocktail, y mettre ses pitits glacons.

Demande a la plupart des accros a un produit de simplement consommer le produit sans le rituel, ca enleve une grande partie de l'attrait. Je n'aurais JAMAIS pense a acheter des bedos deja roule.

Bref, la tu rajoutes du rituel autour de la clope, donc ca rend les choses encore pire.

T'evites generalement de faire ca devant une ecole.

Sinon, rouler (des clopes) a une main sans regarder la clope, ca se fait.
Pour avoir fumer un nombre incalculables de bedos devant des films (donc sans enlever les yeux de l'ecran), rouler c'est quelque chose qui se fait au toucher de toutes facons.

Ensuite, une clope est assez courte, le tabac tres facile a rouler, le filtre donne un tres bon repere tactile, c'est un geste d'environ 1 seconde.
Oui je sais, ca reste une seconde de distraction, mais avec les yeux sur la route, les 2 pieds dispos et l'autre main de dispo.
On est tres loin d'une distraction genre telephone, et c'est pas pire que de bavasser avec qq1 a cote.
Pour quelqu'un d'habitue pour qui rouler est un reflexe, pas pour les autres.

c'est pas tant le tabac le pb, c'est plutot l'habitude. Et en fumant des bedos, tu la prend l'habitude.

J'ai pas specialement de dependance sur le tabac (les 3 fois ou j'ai arrete, ca me titillait le premier jour, peut etre le deuxieme mais c'est tout). Je n'ai aucun probleme a passer 18h00 dans des avions + aeroports sans fumer. Par contre des que j'ai franchi la porte, le reflexe reprend le dessus et paf, j'allume.

Nan, le vrai probleme, c'est de perdre l'habitude de la clope avec le cafe (le fameux CCC, cafe clope caca), apres le repas, avec sa binouze, apres l'amour, en conduisant, que sais je encore.
Ca m'arrive de rester 45 minutes avec une clope pas allumee a la main. Quand je fumais des roulees qui mettent beaucoup plus de temps a se consummer et s'eteignent en permanence, je fumais beaucoup moins, mais j'avais une clope a la main quasi en permanence.

ah, ben si c'est nawak, ca doit vouloir dire que le flag -fno-guess-branch-probability est une blague, de meme que ce commentaire sur le flag: This means that different runs of the compiler on the same program may produce different object code.

'fin j'dis ca...
j'dis rien!!!

1) reste a avoir strictement le meme compilo avec strictement les memes options de compile
2) meme dans ce cas, certaines optimisations sont non deterministe me semble t il. T'auras au mieux un binaire "proche". Reste encore a se rendre compte qu'il est effectivement proche, les diff sur du code binaire ca marche pas au poil.

Ou est ce que tu veux que ca aille, a part DSC?

oui, ben avec un binaire tout court, c'est pas possible de verifier que le code fourni a servi a faire le binaire, donc bon...

pardon, reponse un peu rapide.
L'utilisateur prend les libertes qu'on lui donne ou va voir ailleurs.
Quand aux developpeur, ben s'il a pas contribue au kernel, il est dans la categorie sus citee donc bon...

ah.
Et pourquoi il s'inclue dedans, via on, alors?

on ne peut plus tolérer les protections hardware.

C'est qui, on?