Mathieu Schroeter a écrit 130 commentaires

En effet, l'ARM c'est une autre question. Je me suis même demandé si j'allais faire aussi un build FreeBSD. Et comme tu dis, j'ai supposé que l'auteur parle bien de l'architecture x86-32.

Tu as tout compris car c'est pas le plus fun de pondre des binaires. Surtout que pour Windows je dois passer par une clef hardware pour signer les binaires et l'installateur (y a peut être moyen de faire supporter par Linux en cross mais je n'ai pas vraiment le temps et l'envie). Et pour macOS je suis toute façon obligé de booter le Mac exprès car c'est le seul moyen de signer un .app. Et le SDK Apple en cross c'est très compliqué (on le faisait il y a très longtemps avec le projet GeeXboX, que des builds cross pour macOS mais ce temps là est révolu).

Le plus simple ça reste Linux avec une signature GPG sur l'AppImage. Un pote s'occupe du paquet Debian officiel un de ces 4.

Je ne vois aucun intérêt de faire du 32 bits en 2017. Je n'ai donc pas l'intention de compiler moi-même pour cette architecture que je considère personellement comme obsolète.

Il faut faire un :

git clone --recursive https://github.com/blupi-games/planetblupi-dev.git

pour prendre les sous-modules avec.

Principalement parce que j'ai envie de le faire tout seul.

Merci

le design de l'UEFI n'est pas de la responsabilité de Microsoft

C'est juste une question mais pourquoi les partitions de boot EFI doivent utiliser FAT32 ? Y'a vraiment aucun lien entre Microsoft et UEFI ?

Je répète que c'est une question, ce n'est pas sarcastique.

Hello,

Pour le fun j'ai testé le code suivant avec le compilateur CL de Microsoft en toolset vc140.

#include <iostream>

int t[6] = { 0, 0, 0, 0, 0, 0 };

struct A
{
  A () { ++t[0]; }
  A (A const&) { ++t[1]; }
  A& operator=(A const&) { ++t[2]; return *this; }
//#if __cplusplus > 201100
  A (A &&) { ++t[3]; }
  A& operator=(A &&) { ++t[4]; return *this; }
//#endif
  ~A () { ++t[5]; }
};

A f () { return A (A ()); }

int main ()
{
  { A a = A (A (A (f ()))); }

  std::cout << "Dflt = " << t[0] << "\n"
    "Copy = " << t[1] << "\n"
    "CpAs = " << t[2] << "\n"
//#if __cplusplus > 201100
    "Move = " << t[3] << "\n"
    "MvAs = " << t[4] << "\n"
//#endif
    "Dtor = " << t[5] << '\n';
}

Résultats :

Dflt = 1
Copy = 0
CpAs = 0
Move = 3
MvAs = 0
Dtor = 4

A priori CL ne sait pas faire l'élision aussi efficacement que g++ et clang++ dans ce cas de figure.

Et le lien sans la date pointe toujours sur le dernier:
http://88.80.16.63/torrent/cablegate/cablegate.7z.torrent

Question 2 : quel environnement de build utilisez vous ? Bon ok question idiote :) disons plutot "est ce un projet from scratch ou bien en collaboration avec par exemple BuildRoot ? )

A l'origine le projet a été écrit "from scratch" et pour le plaisir de faire les choses par soi-même par les deux fondateurs du projet GeeXboX (dont l'auteur de la news). Puis le toolchain a été amélioré par beaucoup d'autres contributeurs. Jusqu'à OpenBricks il n'y avait aucune promotion de nos outils. Bien que parfois il y avait quelqu'un qui passait sur notre devel-list pour proposer des patchs parce qu'il utilisait le toolchain à d'autres fin que pour le multimédia par exemple. Un intérêt pour certaines personnes de passer par un toolchain GeeXboX modifié que par un buildroot, etc,... était donc bien réel.
Personnellement j'ai utilisé le toolchain GeeXboX pour équiper un robot dans un labo. Néanmoins, faisant partie du team c'est "normal" que je ne sois pas passé par un autre outil.

Un des gros avantages de GeeXboX c'est à mon avis sa simplicité. Sans documentation c'est facile à comprendre comment ça fonctionne. Puis un deuxième point que je considère très important par rapport aux autres solutions c'est qu'il est orienté shell script. Je trouve indigeste les toolchains orientés Makefiles (comme buildroot) ou Bitbake (comme OE). Mais c'est une question de goût je suppose.

Si si.. les sources d'HL2 étaient bien sur le net.

C'est toujours possible de forcer une localisation dans le fichier de configuration.

Il n'y a aucune régression, mais uniquement plus de choix pour les utilisateurs. Le mono-fenêtre est optionnel.

J2SE c'est un framework (grossièrement un amas de bibliothèques), quel est donc le rapport avec la libc (une seule bibliothèque) ?

Le problème principal c'est les fork() et exec*(), qui devraient être gérés par Evil mais ce n'était pas encore le cas la dernière fois que j'ai essayé de l'utiliser. Et pthread-win32 fait l'affaire à part pour quelques détails. A noter aussi quelques accrochages avec les changements de priorités sur les threads. Mais là aussi il n'y a rien d'insurmontable.

Reste à avoir l'envie de le faire. :)

Ça devrait être une étape dans le développement (car l'auteur original d'Enna souhaite le voir sous Windows, et depuis longtemps d'ailleurs), mais je ne pense pas que ça sera fait dans un futur proche.

Peut être qu'il aimerait des GIF animés? Qu'est-ce que t'en penses?

Je ne saurais dire si Geexbox est laid, je ne l'ai jamais vu., Il faudra que tu me le présentes. Et il n'y a pas si longtemps, des collègues me disaient 'Linux c'est moche'. Peut être que tu pourras aussi me le présenter, car j'ai toujours voulu le voir.

Quoi qu'il en soit, si mon code est aussi laid que Geexbox, je ne dois pas risquer grand chose. :)

Techniquement c'est pas difficile à faire, libplayer le permet indirectement. Mais ça demande du hack dans Enna.

Dit autrement, c'est pas possible dans l'état actuel.

J'ai personnellement rejoins le team GeeXboX uniquement par intérêt personnel. Il faut être clair. Souvent on le fait pour sois, comme ajouter une nouvelle fonctionnalité parce qu'on en a besoin à un moment ou un autre (avec le temps les choses évoluent car certaines responsabilités apparaissent et donc certaines choses doivent se faire parce qu'il le faut et non plus parce qu'on en a envie).

Le fait que se sois du logiciel libre laisse la porte ouverte à tout le monde. Et je n'ai jamais vu dans ces projets la moindre concurrence. GeeXboX a un intérêt bien particulier. C'est avant tout une distribution fait maison. Le toolchain est facile à comprendre et l'ensemble fonctionne bien. Ce projet permet de comprendre comment se construit un système basé sur Linux sans faire des efforts monstrueux. Et puis à cette époque j'avais besoin d'un petit media center pour le salon. C'était une bonne occasion de s'y intéresser. Le design et l'ergonomie j'en avais rien a faire tant que ça lisait les fichiers que je voulais

Je trouve décevant le genre de réponse 'quel intérêt?'. Tous les projets en ont, au moins pour les gens qui y participent.


Après pour les personnes extérieurs, et bien c'est très simple, si ça les intéressent alors tant mieux.. sinon tant pis. Honnêtement s'il y a que 10 personnes qui utilisent Enna dans le monde, ou alors 10000 ça ne me change pas la vie. Je ne travail pas pour ces gens. L'avantage d'en avoir 10000 c'est d'avoir plus de rapports de bugs (pas toujours de très bonnes qualités mais c'est mieux que rien), et surtout d'avoir des gens qui proposent des patchs (et là c'est déjà beaucoup plus limité).


Maintenant XBMC.. je l'ai testé et c'est très sympa.. même qu'on a repiqué des idées dans Enna. Au niveau sources il ne m'intéresse pas du tout. En plus la sortie est uniquement OpenGL a priori. Maintenant pourquoi ne pas bosser sur XBMC??
La division des efforts je n'y crois pas.. Pourquoi travailler sur un projet où l'on en a pas envie? A moins d'être payé... ça serait discutable..

Autre exemple.. Freevo.. c'est super, j'aime bien .. d'ailleurs un temps on a voulu utiliser Freevo2 comme GUI pour GeeXboX 2. Mais on a laissé tombé pour différentes raisons. Personnellement j'ai aucune envie de faire du Python. Alors quel intérêt de travailler avec l'équipe de Freevo surtout si on préfère le C? Et il y a d'autres raisons aussi..


Bref.. chacun à ses propres intérêts dans chaque projet. A mon avis se sont particulièrement les utilisateurs qui voient de la concurrence entre les projets. Ou alors ceux qui ont des intérêts financiers..

Bien sûr, tout ce que je dis n'engage que moi.. je ne connais pas vraiment les intérêts des autres membres du team.

Oui c'est bien Enna qui servira à la prochaine version de GeeXboX. L'ancienne interface (GeeXboX 1.x) est très rigide; non pas par choix, mais pour des raisons techniques. L'ancienne est basée sur OSD d'MPlayer, et il ne faut pas rêver, c'est très limité (néanmoins c'est très léger). La nouvelle est basé sur les EFL et ça n'a donc plus rien à voir. Par rapport à l'ancienne interface on peut même aller jusqu'à dire que les seules limitations sont le temps, la motivation et l'imagination.

Par défaut Enna est configuré en software_x11. Tu peux passer en OpenGL mais il faut le modifier via le fichier de config $HOME/.enna/enna.cfg .. c'est beaucoup plus réactif.

Mplayer et Xine par exemple possède déjà des mécanismes gérant en 'externe' le CSS ('decss'),

MPlayer et xine utilisent la libdvdcss qu'il ne faut pas confondre avec DeCSS. L'implémentation est différente.

Depuis Karmic, il est possible d'annuler le check (le système le propose) sans passer par un CTRL+C.

Pour libpthread je ne suis pas sûr de comprendre où tu veux en venir?
Si tu fais référence à des choses tel que (t1 == t2) au lieu d'un pthread_equal(t1, t2) par exemple, le premier se plante sous Windows vu que se sont des structures. En général c'est une bonne raison pour envoyer un patch au projet.
C'est jamais une grosse affaire à corriger, et je serais étonné que le mainteneur du projet qui aurait ce type de "bug" refuse, vu que ce serait de toute façon une mauvaise utilisation de pthread.

gEDA permet de sortir les schémas en PostScript, et KiCad permet également de tracer en plus en SVG. gEDA est assez vieux aussi, il a dans les 7 ans, et le PostScript a toujours été là à ma connaissance (ce qui est assez logique ceci dit).