Ubuntu-fr

HP

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

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

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 :

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

grim7reaper

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

http://pix.toile-libre.org/upload/origi … 170161.jpg

C’est mon fond d’écran au labo

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)

---

Blog

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.

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.

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

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

:!pakman

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

Le système d'imports de python ne m'a l'air pas très bien foutu
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)

---

...

tshirtman

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

Salut

Le système d'imports de python ne m'a l'air pas très bien foutu
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.

++

---

Le blog de tshirtman, du python, du shell, du libre, et d'autres choses.
Mon petit frère écrit des trucs biens!
Ultimate smash friends, un smash bros like, libre paquet natty!

:!pakman

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

Merci tshirtman, ça me semble logique maintenant

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

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

---

...

Dr Le Rouge

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

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é

Mais je vais trouver une autre soluce

Voui 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

Mindiell

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

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

---

Développeur indépendant

:!pakman

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

Voui 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

---

...

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…

---

Le blog de tshirtman, du python, du shell, du libre, et d'autres choses.
Mon petit frère écrit des trucs biens!
Ultimate smash friends, un smash bros like, libre paquet natty!

:!pakman

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?

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.

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

---

...

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)

grim7reaper

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

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

---

Blog

The Uploader

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

Sortie de Ruby 2.0

---

- 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

Rolinh

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

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

Ah bon? Pas de soucis chez moi

C'est combien un grand volume?

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

Je vais regarder ça en arrivant chez moi.

Merci

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

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

grim7reaper

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

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

Ah bon? Pas de soucis chez moi

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

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)

---

Blog

grim7reaper

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

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).

---

Blog

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.

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?).

The Uploader

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

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

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.
Mais là MIR ça sent le nawak à plein nez.

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

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.

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

:!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...

---

...

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]

The Uploader

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...

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.

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

:!pakman

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

Merci pour les explications

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

---

...