Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#751 Le 01/03/2013, à 18:29

HP

Re : /* Topic des codeurs [8] */

Mindiell a écrit :

Les tests unitaires ne servent pas à grand chose si tu ne dev pas en mode TDD […]

Faux


cat /dev/urandom >/dev/null 2>&1 #github

Hors ligne

#752 Le 01/03/2013, à 21:42

The Uploader

Re : /* Topic des codeurs [8] */

Alors là j'ai rien compris. Mais alors RIEN. Mais ça marche.

J'essaie d'intégrer un patch qui intègre l'émulation entièrement par DOSBox (sans l'aide de dgVoodoo, donc) trouvé sur les forums vogons de la 3DFX Voodoo 1.

Les avantages sont les suivants :

- higher compatibility with [game] titles (even those with integrated [glide2x].ovl)
- portability
- integration with dosbox internal renderer: full-screen, different output modes and video capture would be supported
- no need of external libs
- d3d support for win9x games !!!

Le patch rajoute quelques fichiers dans src/hardware/ :

pci.cpp
voodoo_data.h
voodoo_main.h
voodoo_raster.h
voodoo_types.h
voodoo_func.h
voodoo_main.cpp

en plus de modifier dosbox.cpp :

diff -urN -x '*.rej' -x '*~' -x '*.orig' -x Makefile.in -x configure -x config.h.in -x all-wcprops -x entries -x '*.svn*' dosbox_orig/src/dosbox.cpp dosbox/src/dosbox      .cpp
   --- dosbox_orig/src/dosbox.cpp  2010-11-27 15:56:28.000000000 +0100
   +++ dosbox/src/dosbox.cpp       2010-11-06 11:18:16.000000000 +0100
   @@ -76,6 +76,8 @@
   
   
    void KEYBOARD_Init(Section*);  //TODO This should setup INT 16 too but ok ;)
   +void PCI_Init(Section*);
   +void VOODOO_Init(Section*);
    void JOYSTICK_Init(Section*);
    void MOUSE_Init(Section*);
    void SBLASTER_Init(Section*);
   @@ -446,6 +448,9 @@
           secprop->AddInitFunction(&VGA_Init);
           secprop->AddInitFunction(&KEYBOARD_Init);
   
   +       secprop->AddInitFunction(&PCI_Init); //PCI bus
   +       secprop->AddInitFunction(&VOODOO_Init); //Voodoo
   +
           secprop=control->AddSection_prop("mixer",&MIXER_Init);
           Pbool = secprop->Add_bool("nosound",Property::Changeable::OnlyAtStart,false);
           Pbool->Set_help("Enable silent mode, sound is still emulated though.");

et quelques autres fichiers existants.

(c'est basé en partie sur l'émulation des cartes Voodoo 1/2/Banshee/Rush de MAME. Sauf que là on émule que la Vooodoo 1)

je compile :

...
g++  -march=x86-64 -mtune=core2 -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2   -Wl,-O1,--sort-common,--as-needed,-z,relro -o dosbox dosbox.o  cpu/libcpu.a debug/libdebug.a dos/libdos.a fpu/libfpu.a  hardware/libhardware.a gui/libgui.a ints/libints.a misc/libmisc.a shell/libshell.a hardware/serialport/libserial.a libs/gui_tk/libgui_tk.a -lSDL_sound -lasound -lm -ldl -lpthread -L/usr/lib -lSDL -lpng -lz -lSDL_net -lX11 -lGL
dosbox.o: dans la fonction « DOSBOX_Init() »:
dosbox.cpp:(.text+0x1994): référence indéfinie vers « PCI_Init(Section*) »
dosbox.cpp:(.text+0x19a3): référence indéfinie vers « VOODOO_Init(Section*) »
hardware/libhardware.a(memory.o): dans la fonction « MEM_GetPageHandler(unsigned long) »:
memory.cpp:(.text+0xb3): référence indéfinie vers « voodoo_pagehandler »
ints/libints.a(bios.o): dans la fonction « INT1A_Handler() »:
bios.cpp:(.text+0x1b99): référence indéfinie vers « pci_callback »
collect2: erreur: ld a retourné 1 code d'état d'exécution
make[3]: *** [dosbox] Erreur 1
make[3] : on quitte le répertoire « /home/max/Dev/dosbox/src/dosbox-0.74/src »
make[2]: *** [all-recursive] Erreur 1
make[2] : on quitte le répertoire « /home/max/Dev/dosbox/src/dosbox-0.74/src »
make[1]: *** [all-recursive] Erreur 1
make[1] : on quitte le répertoire « /home/max/Dev/dosbox/src/dosbox-0.74 »
make: *** [all] Erreur 2
==> ERREUR : Une erreur s'est produite dans build().

Je regarde le dossier src/hardware... Effectivement pci.o et voodoo_main.o n'existent pas.

Pas grave, je modifie src/hardware/Makefile* pour les inclure :

$ make
make : pas de règle pour construire .deps/pci.Po
make : pas de règle pour constuire .deps/voodoo_main.Po

Pas de bol.

Je regarde les différents fichiers de génération (autogen.sh, Makefile*, configure, ...). Des centaines de lignes de codes générés dans chaque fichier. >_<'

Bon j'me dis que je vais déplacer src/hardware/voodoo*.h dans dosbox-0.74/include/ (juste parce que ce serait plus propre) et que pour pci.h je peux aller me faire voir (je n'aurais plus qu'à le créer). Je relance un :

./autogen.sh && ./configure && make clean && make

pour voir si par hasard ça change quelque chose (au cas où).

... J'obtiens un binaire dosbox ! pci.o et voodoo_main.o ont été crées avant de créer dosbox.o.

O_O

J'hésite entre un "vive les autohells ! /o\" et ceci :
1362170161.jpg
neutral

Dernière modification par The Uploader (Le 01/03/2013, à 22:00)


- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4800 SE, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster 16 ISA PnP, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10

Hors ligne

#753 Le 01/03/2013, à 22:10

grim7reaper

Re : /* Topic des codeurs [8] */

C’est mon fond d’écran au labo big_smile

Sinon chezmoiçamarche (testé avec dosbox 0.74).
Bon j’ai dû ajouter un #include <stddef.h> dans include/dos_inc.h et un #include <stdio.h> dans src/hardware/voodoo_func.h.
Mais après ça, c’est passé comme une lettre à la poste.

Dernière modification par grim7reaper (Le 01/03/2013, à 22:11)

Hors ligne

#754 Le 02/03/2013, à 00:09

The Uploader

Re : /* Topic des codeurs [8] */

En fait je dois bien rajouter pci.cpp et voodoo_main.cpp à certaines lignes existantes dans src/hardware/Makefile* pour que ça passe chez moi :

src/hardware/Makefile :

am_libhardware_a_OBJECTS = adlib.$(OBJEXT) dma.$(OBJEXT) \
	gameblaster.$(OBJEXT) hardware.$(OBJEXT) iohandler.$(OBJEXT) \
	joystick.$(OBJEXT) keyboard.$(OBJEXT) memory.$(OBJEXT) \
	mixer.$(OBJEXT) pcspeaker.$(OBJEXT) pic.$(OBJEXT) \
	sblaster.$(OBJEXT) tandy_sound.$(OBJEXT) timer.$(OBJEXT) \
	vga.$(OBJEXT) vga_attr.$(OBJEXT) vga_crtc.$(OBJEXT) \
	vga_dac.$(OBJEXT) vga_draw.$(OBJEXT) vga_gfx.$(OBJEXT) \
	vga_other.$(OBJEXT) vga_memory.$(OBJEXT) vga_misc.$(OBJEXT) \
	vga_seq.$(OBJEXT) vga_xga.$(OBJEXT) vga_s3.$(OBJEXT) \
	vga_tseng.$(OBJEXT) vga_paradise.$(OBJEXT) cmos.$(OBJEXT) \
	disney.$(OBJEXT) gus.$(OBJEXT) mpu401.$(OBJEXT) ipx.$(OBJEXT) \
	ipxserver.$(OBJEXT) dbopl.$(OBJEXT) pci.$(OBJEXT) voodoo_main.$(OBJEXT)
libhardware_a_SOURCES = adlib.cpp dma.cpp gameblaster.cpp hardware.cpp iohandler.cpp joystick.cpp keyboard.cpp \
                        memory.cpp mixer.cpp pcspeaker.cpp pic.cpp sblaster.cpp tandy_sound.cpp timer.cpp \
			vga.cpp vga_attr.cpp vga_crtc.cpp vga_dac.cpp vga_draw.cpp vga_gfx.cpp vga_other.cpp \
			vga_memory.cpp vga_misc.cpp vga_seq.cpp vga_xga.cpp vga_s3.cpp vga_tseng.cpp vga_paradise.cpp \
			cmos.cpp disney.cpp gus.cpp mpu401.cpp ipx.cpp ipxserver.cpp dbopl.cpp pci.cpp voodoo_main.cpp
include ./$(DEPDIR)/pci.Po
include ./$(DEPDIR)/voodoo_main.Po

src/hardware/Makefile.in :

am_libhardware_a_OBJECTS = adlib.$(OBJEXT) dma.$(OBJEXT) \
	gameblaster.$(OBJEXT) hardware.$(OBJEXT) iohandler.$(OBJEXT) \
	joystick.$(OBJEXT) keyboard.$(OBJEXT) memory.$(OBJEXT) \
	mixer.$(OBJEXT) pcspeaker.$(OBJEXT) pic.$(OBJEXT) \
	sblaster.$(OBJEXT) tandy_sound.$(OBJEXT) timer.$(OBJEXT) \
	vga.$(OBJEXT) vga_attr.$(OBJEXT) vga_crtc.$(OBJEXT) \
	vga_dac.$(OBJEXT) vga_draw.$(OBJEXT) vga_gfx.$(OBJEXT) \
	vga_other.$(OBJEXT) vga_memory.$(OBJEXT) vga_misc.$(OBJEXT) \
	vga_seq.$(OBJEXT) vga_xga.$(OBJEXT) vga_s3.$(OBJEXT) \
	vga_tseng.$(OBJEXT) vga_paradise.$(OBJEXT) cmos.$(OBJEXT) \
	disney.$(OBJEXT) gus.$(OBJEXT) mpu401.$(OBJEXT) ipx.$(OBJEXT) \
	ipxserver.$(OBJEXT) dbopl.$(OBJEXT) pci.$(OBJEXT) voodoo_main.$(OBJEXT)
libhardware_a_SOURCES = adlib.cpp dma.cpp gameblaster.cpp hardware.cpp iohandler.cpp joystick.cpp keyboard.cpp \
                        memory.cpp mixer.cpp pcspeaker.cpp pic.cpp sblaster.cpp tandy_sound.cpp timer.cpp \
			vga.cpp vga_attr.cpp vga_crtc.cpp vga_dac.cpp vga_draw.cpp vga_gfx.cpp vga_other.cpp \
			vga_memory.cpp vga_misc.cpp vga_seq.cpp vga_xga.cpp vga_s3.cpp vga_tseng.cpp vga_paradise.cpp \
			cmos.cpp disney.cpp gus.cpp mpu401.cpp ipx.cpp ipxserver.cpp dbopl.cpp pci.cpp voodoo_main.cpp
@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/pci.Po@am__quote@
@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/voodoo_main.Po@am__quote@

src/hardware/Makefile.am :

libhardware_a_SOURCES = adlib.cpp dma.cpp gameblaster.cpp hardware.cpp iohandler.cpp joystick.cpp keyboard.cpp \
                        memory.cpp mixer.cpp pcspeaker.cpp pic.cpp sblaster.cpp tandy_sound.cpp timer.cpp \
			vga.cpp vga_attr.cpp vga_crtc.cpp vga_dac.cpp vga_draw.cpp vga_gfx.cpp vga_other.cpp \
			vga_memory.cpp vga_misc.cpp vga_seq.cpp vga_xga.cpp vga_s3.cpp vga_tseng.cpp vga_paradise.cpp \
			cmos.cpp disney.cpp gus.cpp mpu401.cpp ipx.cpp ipxserver.cpp dbopl.cpp pci.cpp voodoo_main.cpp

(c'est là où j'ai du faire une erreur quand j'ai eu gcc qui disait qu'il n'avait aucune règle, blabla)

Changer les voodoo*.h de place pour les mettre dans include n'avait rien changé en fait.
Donc en fait j'ai pas encore trouvé le moyen pour que ce soit présent à l'origine (vu que ce sont des fichiers générés).

Bon j'ai pas encore testé le binaire qui en résulte... J'verrais ça demain.

grim' a écrit :

Bon j’ai dû ajouter un #include <stddef.h> dans include/dos_inc.h

Ça y est déjà chez moi (sans patch). Étrange.

J'ai dû aussi rajouter

#include <stdio.h>

à voodoo_func.h

J'aimerais bien qu'une compilation d'un projet X avec un patch tiers Y se passe toute seule chez moi aussi de temps en temps. hmm

Mon premier vrai contact avec les autohells a fini ainsi en tout cas :
jackiechanwtf.png

Dernière modification par The Uploader (Le 02/03/2013, à 00:25)


- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4800 SE, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster 16 ISA PnP, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10

Hors ligne

#755 Le 02/03/2013, à 01:32

:!pakman

Re : /* Topic des codeurs [8] */

Le système d'imports de python ne m'a l'air pas très bien foutu mad
J'aimerais importer un module qui se trouve dans le dossier parent, et sur internet, pas mal de gens disent qu'il faut modifier une variable d'environnement...

Edit : comme ça :

import sys
sys.path.insert(0,'..')

Je trouve ça lourd comme solution, vous avez une autre idée ? (Il n'existe sans doute pas d'autres solutions, mais au cas ou...)

Dernière modification par :!pakman (Le 02/03/2013, à 01:34)


...

Hors ligne

#756 Le 02/03/2013, à 01:53

tshirtman

Re : /* Topic des codeurs [8] */

Salut smile

:!pakman a écrit :

Le système d'imports de python ne m'a l'air pas très bien foutu mad
J'aimerais importer un module qui se trouve dans le dossier parent, et sur internet, pas mal de gens disent qu'il faut modifier une variable d'environnement...

Edit : comme ça :

import sys
sys.path.insert(0,'..')

Je trouve ça lourd comme solution, vous avez une autre idée ? (Il n'existe sans doute pas d'autres solutions, mais au cas ou...)

En fait, on importe des modules, ou packages, ce n'est pas très logique d'importer quelque chose qui n'est pas dans ton dossier, si ton projet lui même n'est pas un package…

exemple:

 gabriel@tochange:/tmp/my_project$ tree                      
.
└── my_package
    ├── __init__.py
    ├── main.py
    ├── module1
    │   ├── __init__.py
    │   ├── __init__.pyc
    │   ├── test.py
    │   └── test.pyc
    └── module2
        ├── __init__.py
        └── __init__.pyc

./my_package/module2/__init__.py

def test_module2():
    print "tested!"

./my_package/module1/test.py

import module2


def test():
    module2.test_module2()

./my_package/main.py

from module1 import test

test.test()

les fichiers non indiqués sont vides.

là vu que notre projet est un package, les modules peuvent importer les modules de façon relative à la racine de celui-ci.

++ smile

Hors ligne

#757 Le 02/03/2013, à 02:24

:!pakman

Re : /* Topic des codeurs [8] */

Merci tshirtman, ça me semble logique maintenant wink

En fait, je voulais faire un truc dégeu :
- Je déclare dans un fichier python des variables globales, renseignées par l'utilisateur pour configurer le programme, a la racine même du projet.
- J'importe ce fichier dans tous les autres fichiers, situés dans des sous dossiers (il fallait donc que je remonte à la racine).

Mais je vais trouver une autre soluce tongue

Dernière modification par :!pakman (Le 02/03/2013, à 02:27)


...

Hors ligne

#758 Le 02/03/2013, à 09:59

Dr Le Rouge

Re : /* Topic des codeurs [8] */

:!pakman a écrit :

En fait, je voulais faire un truc dégeu :
- Je déclare dans un fichier python des variables globales, renseignées par l'utilisateur pour configurer le programme, a la racine même du projet.

Même moi qui suis loin d'être programmeur, je suis choqué yikes

Mais je vais trouver une autre soluce tongue

Voui tongue Tu pourrais peut-être encapsuler toutes les variable globales en question dans une class config ? Comme ça, tu as juste à mettre des trucs du genre

foo = conf.getBar()

dans tes modules sans avoir besoin d'importer quoi que ce soit. Double effet kisskool : en documentant la classe config, tu documentes la configuration et l'interface utilisateur en même temps.


C'est deux suites de Cauchy qui veulent aller à la soirée 'no limit'. Hélas, à l'entrée le videur leur dit : "désolé, c'est complet !".
mon site perso (π²/6.fr) et mon blog

Hors ligne

#759 Le 02/03/2013, à 10:21

Mindiell

Re : /* Topic des codeurs [8] */

HP a écrit :
Mindiell a écrit :

Les tests unitaires ne servent pas à grand chose si tu ne dev pas en mode TDD […]

Faux

J'attendais mieux comme réponse. Je suis un peu déçu smile

Hors ligne

#760 Le 02/03/2013, à 13:12

:!pakman

Re : /* Topic des codeurs [8] */

Le Rouge a écrit :

Voui tongue Tu pourrais peut-être encapsuler toutes les variable globales en question dans une class config ? Comme ça, tu as juste à mettre des trucs du genre

foo = conf.getBar()

dans tes modules sans avoir besoin d'importer quoi que ce soit. Double effet kisskool : en documentant la classe config, tu documentes la configuration et l'interface utilisateur en même temps.

Oui, c'est pas bête du tout wink


...

Hors ligne

#761 Le 03/03/2013, à 00:40

tshirtman

Re : /* Topic des codeurs [8] */

Hum, tu peut tout à fait mettre config.py à la racine (ça en fera un module config), et l'importer depuis les autres modules, non?

Sinon c'est quand même mieux de passer par ConfigParser et d'avoir un vrai fichier de config, en fait…

Hors ligne

#762 Le 03/03/2013, à 13:22

:!pakman

Re : /* Topic des codeurs [8] */

tshirtman a écrit :

Hum, tu peut tout à fait mettre config.py à la racine (ça en fera un module config), et l'importer depuis les autres modules, non?

En fait pour mettre en oeuvre cette solution, vu que les autres modules sont dans des sous dossiers, j'aurais eu besoin de remonter d'un dossier pour trouver le config.py lors de l'import du module.

tshirtman a écrit :

Sinon c'est quand même mieux de passer par ConfigParser et d'avoir un vrai fichier de config, en fait…

ConfigParser, ça m'a l'air pas mal, merci smile


...

Hors ligne

#763 Le 03/03/2013, à 15:15

Rolinh

Re : /* Topic des codeurs [8] */

Un utilisateur m'a reporté un bug plutôt dérangeant dans dfc: il échoue sur les trop grand volumes apparemment.
Le soucis vient de statvfs(3). Grim (ou quelqu'un d'autre), si tu as une idée, je suis preneur. Pour ma part je suis en train de chercher une solution (sans avoir moyen de la tester malheureusement puisqu'il m'est impossible de reproduire le bug).

EDIT: après avoir parcouru cette page, j'ai l'impression qu'il me faudrait quelque chose comme "-D_FILE_OFFSET_BITS=64" et "LARGEFILE_SOURCE" à 1. Le bug touche apparemment uniquement Linux (puisque statvfs(3) n'est pas utilisé pour les *BSD et OSX) mais je n'en suis pas certain et il faut quand même que le fix ne casse pas la portabilité.

Dernière modification par Rolinh (Le 03/03/2013, à 15:39)

Hors ligne

#764 Le 03/03/2013, à 18:03

grim7reaper

Re : /* Topic des codeurs [8] */

J'ai une erreur quand je veux aller voir le rapport de bug hmm
C'est combien un grand volume?
Je vais regarder ça en arrivant chez moi.

Hors ligne

#765 Le 03/03/2013, à 20:18

The Uploader

Re : /* Topic des codeurs [8] */


- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4800 SE, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster 16 ISA PnP, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10

Hors ligne

#766 Le 03/03/2013, à 21:55

Rolinh

Re : /* Topic des codeurs [8] */

grim7reaper a écrit :

J'ai une erreur quand je veux aller voir le rapport de bug hmm

Ah bon? Pas de soucis chez moi hmm

grim7reaper a écrit :

C'est combien un grand volume?

Apparemment, + de 2To. La personne en question a reporté un problème sur un volume de 3.8To.

grim7reaper a écrit :

Je vais regarder ça en arrivant chez moi.

Merci smile

@The Uploader: ça fait quelques jour déjà wink

Dernière modification par Rolinh (Le 03/03/2013, à 21:55)

Hors ligne

#767 Le 03/03/2013, à 22:15

grim7reaper

Re : /* Topic des codeurs [8] */

Rolinh a écrit :
grim7reaper a écrit :

J'ai une erreur quand je veux aller voir le rapport de bug hmm

Ah bon? Pas de soucis chez moi hmm

Ça fonctionne (depuis mon PC), mais depuis mon téléphone j’avais un truc genre « Erreur interne ».

Rolinh a écrit :
grim7reaper a écrit :

C'est combien un grand volume?

Apparemment, + de 2To. La personne en question a reporté un problème sur un volume de 3.8To.

Hum, oki.
Je vais voir si je peux avoir un volume aussi grand sous la main (des 2 To, pas de soucis, mais plus faut que je vois).

Mais à priori, ton diagnostic est le bon (si son système est 32 bits, il faut sûrement que tu actives les offsets en 64 bits via -D_FILE_OFFSET_BITS=64).
Je vais voir si je peux tester demain si je mets la main sur un gros volume.

Dernière modification par grim7reaper (Le 04/03/2013, à 08:39)

Hors ligne

#768 Le 04/03/2013, à 08:40

grim7reaper

Re : /* Topic des codeurs [8] */

grim7reaper a écrit :

Je vais voir si je peux tester demain si je mets la main sur un gros volume.

Bon, j’ai bien des gros volumes sous la main, mais il y a deux soucis : il n'y a pas cmake dessus et les machines sont en 64 bits (donc si le diagnostic est bon, peu de chance que le problème apparaisse).

Hors ligne

#769 Le 04/03/2013, à 14:25

Rolinh

Re : /* Topic des codeurs [8] */

Le rapporteur de bug m'a donné plus d'infos. Il utilise donc bien un système 32-bit (Debian testing). J'ai tenté de créer une machine virtuelle avec Debian testing en 32-bit et un disque de 3To afin d'essayer de reproduire le bug mais je n'y parviens pas, dfc me donne bien les bons résultats et ne plante pas.

Du coup, je pense que je vais créé un tarball avec le patch et demander au rapporteur de bug de me dire si le problème est toujours présent. Merci pour ton aide en tout cas.

Hors ligne

#770 Le 05/03/2013, à 11:39

Rolinh

Re : /* Topic des codeurs [8] */

Dites, il n'y a que moi qui ai cette impression ou bien Canonical essaie à nouveau de réinventer la roue avec Mir?
En fait, apparemment ils n'ont même pas cherché à contacter les développeurs de Wayland avant de se lancer là-dedans...
J'ai vraiment du mal à comprendre cette attitude à vouloir à chaque fois réinventer la roue (Bazaar, Upstart, ...),  au lieu d'adapter l'existant comme le permet justement le modèle open-source.
J'étais sûr qu'ils tablaient sur Wayland en plus (c'était prévu pour Ubuntu 12.10 non?).

Hors ligne

#771 Le 05/03/2013, à 13:49

The Uploader

Re : /* Topic des codeurs [8] */

Et M.S. avait dit qu'un nouveau serveur graphique ne servirait qu'à fragmenter la communauté...

Rolinh a écrit :

J'ai vraiment du mal à comprendre cette attitude à vouloir à chaque fois réinventer la roue (Bazaar, Upstart, ...),  au lieu d'adapter l'existant comme le permet justement le modèle open-source.

Quand RedHat sort PulseAudio ou systemd, ils réinventent la roue aussi. Mais comme la roue d'avant était carrée, on leur en veut pas. tongue
Mais là MIR ça sent le nawak à plein nez. hmm

Rolinh a écrit :

@The Uploader: ça fait quelques jour déjà wink

C'est bien plus intéressant sur linuxfr en fait (y'a bien plus de détails) : http://linuxfr.org/news/ruby-2-0-est-sorti
Je suis pas en retard, la dépêche est publiée depuis deux heures à l'heure où j'écris ces lignes. tongue

Dernière modification par The Uploader (Le 05/03/2013, à 13:53)


- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4800 SE, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster 16 ISA PnP, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10

Hors ligne

#772 Le 05/03/2013, à 13:57

:!pakman

Re : /* Topic des codeurs [8] */

C'est quoi la différence entre Python et Ruby ?
Je ne connait pas Ruby, mais j'ai l'impression que ça fournit exactement le même service que la plateforme Python...


...

Hors ligne

#773 Le 05/03/2013, à 14:14

nathéo

Re : /* Topic des codeurs [8] */

Il me semble qu'avec Ruby on a plus de libertés sur la manière dont on code, par exemple il existe plusieurs moyen de faire une même chose… Enfin je code juste quelques fois en Ruby, et c'est juste pour réaliser mes projets de math…


C'est rarement par le sarcasme qu'on élève son âme.
Le jus de la vigne clarifie l'esprit et l'entendement.
De quoi souffres-tu ? De l'irréel intact dans le réel dévasté ?
La liberté n'est qu'un vain fantôme, quand une classe d'hommes peut affamer l'autre impunément. timezone[America/Bogota]

Hors ligne

#774 Le 05/03/2013, à 14:23

The Uploader

Re : /* Topic des codeurs [8] */

:!pakman a écrit :

C'est quoi la différence entre Python et Ruby ?
Je ne connait pas Ruby, mais j'ai l'impression que ça fournit exactement le même service que la plateforme Python...

Pas trop non. La "philosophie"(*) du langage est très différente (même si les deux langages ont à peu près les mêms capacités et qu'un programme Ruby peut beaucoup ressembler à un programme Python, selon le style de code), et même s'il y a un paquet de gems disponibles il y a quelques manques (par exemple ruby n'a pas vraiment d'équivalent à PyGTK ou à pygame).

(*) Le plus évident est que Ruby hérite de la philosophie Perl qui dit qu'il devrait plusieurs manières de faire (les classes de la librairie standard ont des méthodes aux noms différents qui font la même chose), ce qui s'oppose carrément à Python :

There should be one-- and preferably only one --obvious way to do it.

http://www.python.org/dev/peps/pep-0020/

Pour ma part, j'en ai un peu marre des méthodes avec des noms multiples (ruby - je trouve ça de plus en plus débile), et des whitespaces qui changent selon l'éditeur (ce qui casse ton python -oui je sais j'aurais dû utiliser un vrai éditeur, blablabla), du coup ça fait quelques mois que je reviens plus ou moins au C. tongue

A lire :
Why's (poignant) guide to Ruby
Programming Ruby : The Pragmatic Programmer's Guide
The Ruby Way
The Well-Grounded Rubyist

Dernière modification par The Uploader (Le 05/03/2013, à 14:51)


- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4800 SE, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster 16 ISA PnP, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10

Hors ligne

#775 Le 05/03/2013, à 14:53

:!pakman

Re : /* Topic des codeurs [8] */

Merci pour les explications wink

Dernière modification par :!pakman (Le 05/03/2013, à 14:54)


...

Hors ligne