Le topic de la programmation, string, chaînes, cuir et compagnie

**rOut** · 28/09/2011, 10h01

Bah non parce que je veux générer du code avec potentiellement des instructions préprocesseur dedans. Donc si je fais passer le préprocesseur, il va tout m'enlever. Il me faut quelque chose d'autre.

**Møgluglu** · 28/09/2011, 10h26

Met ton code C++ dans des printf.

Sérieusement, je rejoins le newbie pour conseiller un compilo source-to-source, et tu rajoutes les pragma, attributs et mots-clefs que tu veux dans le langage en entrée. C'est certainement ridiculement overkill, certes.

**deathdigger** · 28/09/2011, 16h25

Une question Mysql :
On peut utiliser des if/else en Mysql comme l'indique la doc ici :
http://dev.mysql.com/doc/refman/5.0/...statement.html

(on peut même utiliser des CASE)

Mais là, c'est indiqué pour des fonctions, mais peut-on le faire tout simplement dans une bête requête ?

J'ai essayé ça à titre d'exemple :

Code:

UPDATE `test`
IF
 nb>10 AND id=2 THEN SET nb= nb-10 WHERE id=2
ELSE

 nb=0 WHERE id=2
 END IF

Mais ça ne fonctionne pas, quelqu'un aurait une idée ?

**DaP** · 28/09/2011, 19h07

Je ne connais pas MySQL, mais c'est sûrement pour les procédures stockées cette syntaxe. Tu veux exécuter ça du côté client ou serveur ?

**rOut** · 28/09/2011, 19h12

Tu veux exécuter ça du côté client ou serveur ?

Du SQL ?

**Møgluglu** · 28/09/2011, 19h35

Bah il demande si c'est côté Control Unit ou côté Processing Elements qu'il faut exécuter le code.

Ah pardon, j'avais vu un IF et un WHERE, j'ai confusé avec Fortran 90.

(En jargon mySQL, ils appellent effectivement "server" le euh… serveur.)

**DaP** · 28/09/2011, 20h41

Envoyé par rOut

Du SQL ?

Lis les messages ? Il veut faire un IF dans son SQL et linke la documentation des procédures stockées, je lui demande si il veut vraiment exécuter son IF du côté serveur.

**GrandFather** · 28/09/2011, 20h56

Envoyé par deathdigger

Mais ça ne fonctionne pas, quelqu'un aurait une idée ?

MySQL prend certes des libertés avec l'ANSI SQL, mais là c'est un peu too much même pour lui...

Utilise plutôt ce genre de syntaxe:

Code:

UPDATE `test`SET nb = (CASE WHEN nb > 10 THEN nb - 10 ELSE 0 END) WHERE id = 2

**Grosnours** · 29/09/2011, 09h08

Bon, j'ai une petite question conne et quasi-philosophique (ou pas).
Imaginons que j'ai une appli avec une cinquantaine d'assets graphiques et un moteur un peu touffu (complexe mais pas compliqué non plus, dans les 5k lignes) derrière pour faire tourner le tout. Comme c’était pas trop énorme tout était dans un seul fichier pour l'instant (oui berk je sais).
Maintenant il faut que je décline ceci en 7 thèmes totalement différents avec 5 variations chacun.
Je vois trois possibilités :
- j'externalise les 7 thèmes, laisse le moteur où il est. Mais alors cela voudra dire qu'il faudra que je passe tout le contexte (assets + toutes les structures de données derrières) à chaque appel du moteur, que je me fade une myriade de getter/setter et cela me parait

et méga-lourdingue même si c'est sans doute plus propre conceptuellement.
- j'internalise tous les 7 thèmes et leurs déclinaisons avec le moteur, ce qui fait un fichier gigantesque (35 fois déclarer tous les assets

) et je gère le tout à coup de structures dynamiques. Avantage : c'est scalable autant que je le veux. C'est ce que je fais pour le moment et cela marche mais cela me parait peu élégant (doux euphémisme) et le code devient illisible (on remplace un appel à un asset/donnée par un appel à celui-ci dans sa structure dynamique).
- je la joue gros porc et je fais une solution intermédiaire en ayant 7 fichiers (un par thème) qui contiennent chacun le moteur. Avantage : je n'ai quasiment aucun boulot à faire.

Qu'est-ce que je fais ?

**rOut** · 29/09/2011, 09h58

Heu c'est une appli en quoi ?

**Grosnours** · 29/09/2011, 09h59

AS4.

**GrandFather** · 29/09/2011, 10h16

A vue de nez, c'est la première possibilité sans hésitation. Pour éviter que ce soit aussi lourdingue que tu le crains, il faut peut-être que tu repenses ton architecture en exploitant au maximum les possibilités de la POO, et en regroupant tes jeux d'asset sous forme de plugins. Chaque plugin contiendra le code qui lui permettra de « s'enregistrer » auprès du moteur, i.e. de lui faire part de sa présence, et également toutes les méthodes appelées en interne par le moteur et dont l'implémentation est spécifique à chaque plugin. De cette manière les données et les assets de chaque plugin ne sont pas exposées et le moteur n'a pas à en tenir compte (il ne fait qu'appeler les méthodes qui manipulent ces éléments).

C'est une architecture que j'ai déjà utilisée, pour un petit projet pro. Un « sniffer » SNMP qui va récupérer différentes valeurs de compteurs (niveau du toner, nombre d'impressions, etc.) des imprimantes branchées sur le réseau local. Les OID de ces compteurs varient selon les constructeurs, et parfois selon les modèles pour un même constructeur, et il arrive aussi qu'il soit nécessaire de leur faire subir un traitement supplémentaire pour obtenir un résultat exploitable. Pour éviter d'écrire un code monstrueux truffé de if/else ou de gros tableaux d'OID indexés par les modèles que je surveille, j'ai utilisé un système de plugin: chaque imprimante est gérée sous forme de plugin dans son propre fichier, situé dans un répertoire précis pour que le moteur puisse le charger au lancement, et présente une API commune à tous les plugins. Lorsqu'un nouveau modèle d'imprimante débarque, je n'ai qu'à écrire un nouveau fichier, et à le copier à cet endroit. Je n'ai absolument rien à retoucher dans le code existant.

**Marty** · 29/09/2011, 10h26

Envoyé par rOut

Qu'est ce qui t’intéresse dans le C++ ou le Delphi ? Est-ce simplement par curiosité ou soif d'apprendre, ou bien est-ce que tu as un but précis ?

Tu peux toujours commencer par des tutoriaux et lire les articles sur des sites comme le site du zero ou developpez.com

Les ouvrages, après... faut voir, il y en a tellement. (Personnellement je n'ai jamais touché un bouquin de C++ de ma vie)

Envoyé par TiNitro

Je sais bien qu'on réponds à des questions par des questions, mais connais-tu la programmation avec d'autres langages ?
Si oui, je rejoins rOut, quelques didacticiels voire un bouquin feront l'affaire.
Sinon, ça me parait difficile et peut-être une voie inutilement raide pour commencer (pourquoi pas le Pascal Objet (langage de programmation de Delphi) mais le C++ pour débuter en programmation, mauvaise idée).

Ah ben moi non plus, il n'y en avait pas quand j'ai commencé le C++. C'était l'époque ou la programmation par objet faisait partie de l'IA et ou pleins de gens pensaient que Objective C serait le langage du futur

Le but d'apprendre la programmation sur ce type de langage est professionnel. Dans le cadre de mes recherches, j'essaye de modéliser le déplacement d'espèces dans l'espace et d'autres trucs du style. Le langage Delphi et C++ sont apparemment les plus utilisés pour réaliser de type d'analyses. Perso, je n'y connais rien mais je fais un peu de programmation sous R (un logiciel de traitement statistique) qui est basé sur le langage S. Je m'amuse sur calculette aussi.

Quoiqu'il en soit, c'est un truc qui me plait.

Ok, je vais aller voir sur le site du zero ou developpez.com et si je comprends rien, j'essayerais de m'incruster au cours d'informatique de la fac.

**Grosnours** · 29/09/2011, 10h35

Envoyé par GrandFather

A vue de nez, c'est la première possibilité sans hésitation.

Moui, je suis bien d'accord en effet.
Bon seulement comme je suis en crunch mode, j'ai pris un petit raccourci.

Attention si vous avez l'estomac fragile ne lisez pas la suite !

Spoiler Alert!

**rOut** · 29/09/2011, 10h40

Et puis avec un peu de chance ils auront muté chacun dans leur coin et ne voudront pas réintégrer leur hôte d'origine.

**Grosnours** · 29/09/2011, 10h49

Mais non, mais non, quelle idée voyons !

**Sekigo Le Magnifique** · 29/09/2011, 11h50

Je me doute que je n'aurais pas de réponses, mais sait-on jamais. J'ai voulu tester Soya3D (un moteur 3D pour python) depuis ma Debian SID.

Seulement, j'ai une erreur bizarre (erreur de segmentation) lors du soya.init():

Code:

$ gdb python
GNU gdb (GDB) 7.3-debian
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/python...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/python 
[Thread debugging using libthread_db enabled]
Python 2.6.7 (r267:88850, Aug  3 2011, 15:19:01) 
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import soya
>>> soya.init()

Program received signal SIGSEGV, Segmentation fault.
__strlen_sse2 () at ../sysdeps/i386/i686/multiarch/strlen-sse2.S:46
46      ../sysdeps/i386/i686/multiarch/strlen-sse2.S: Aucun fichier ou dossier de ce type.
        in ../sysdeps/i386/i686/multiarch/strlen-sse2.S
(gdb) backtrace 
#0  __strlen_sse2 () at ../sysdeps/i386/i686/multiarch/strlen-sse2.S:46
#1  0x0809e64b in PyString_FromString ()
#2  0xb78e3d58 in __pyx_f_5_soya_dump_info () at _soya.c:5135
#3  __pyx_f_5_soya_init (__pyx_self=0x0, __pyx_args=0xb7bd202c, __pyx_kwds=0x0) at _soya.c:6386
#4  0x080d9e64 in PyEval_EvalFrameEx ()
#5  0x080dbb27 in PyEval_EvalCodeEx ()
#6  0x080dbc37 in PyEval_EvalCode ()
#7  0x080fc5ad in PyRun_InteractiveOneFlags ()
#8  0x080fc7a8 in PyRun_InteractiveLoopFlags ()
#9  0x080fc8c4 in PyRun_AnyFileExFlags ()
#10 0x0805e4e2 in Py_Main ()
#11 0x0805d6bb in main ()

Bon, c'est la première fois que j'utilise gdb.
Je ne comprends pas pourquoi il me manque le fichier strlen-sse2.S . Si je ne me trompe pas, ça corresponds à un machin du processeur. Et mes processeurs exploitent le sse2.
Et je ne parviens même pas à mettre la main sur le répertoire ../sysdeps/i386/i686/multiarch/strlen-sse2.S.

Je demande aussi si, à votre avis, ça vient de chez moi, ou dois-je faire un rapport de bug à Debian ?

**GrandFather** · 29/09/2011, 12h07

Envoyé par Grosnours

J'y crois. Fort.

Les actes de foi, en développement, ça ne donne toujours que du bon, c'est bien connu...

**rOut** · 29/09/2011, 12h10

Envoyé par Sekigo Le Magnifique

Je me doute que je n'aurais pas de réponses, mais sait-on jamais. J'ai voulu tester Soya3D (un moteur 3D pour python) depuis ma Debian SID.

Seulement, j'ai une erreur bizarre (erreur de segmentation) lors du soya.init():

Code:

$ gdb python
GNU gdb (GDB) 7.3-debian
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/python...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/python 
[Thread debugging using libthread_db enabled]
Python 2.6.7 (r267:88850, Aug  3 2011, 15:19:01) 
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import soya
>>> soya.init()

Program received signal SIGSEGV, Segmentation fault.
__strlen_sse2 () at ../sysdeps/i386/i686/multiarch/strlen-sse2.S:46
46      ../sysdeps/i386/i686/multiarch/strlen-sse2.S: Aucun fichier ou dossier de ce type.
        in ../sysdeps/i386/i686/multiarch/strlen-sse2.S
(gdb) backtrace 
#0  __strlen_sse2 () at ../sysdeps/i386/i686/multiarch/strlen-sse2.S:46
#1  0x0809e64b in PyString_FromString ()
#2  0xb78e3d58 in __pyx_f_5_soya_dump_info () at _soya.c:5135
#3  __pyx_f_5_soya_init (__pyx_self=0x0, __pyx_args=0xb7bd202c, __pyx_kwds=0x0) at _soya.c:6386
#4  0x080d9e64 in PyEval_EvalFrameEx ()
#5  0x080dbb27 in PyEval_EvalCodeEx ()
#6  0x080dbc37 in PyEval_EvalCode ()
#7  0x080fc5ad in PyRun_InteractiveOneFlags ()
#8  0x080fc7a8 in PyRun_InteractiveLoopFlags ()
#9  0x080fc8c4 in PyRun_AnyFileExFlags ()
#10 0x0805e4e2 in Py_Main ()
#11 0x0805d6bb in main ()

Bon, c'est la première fois que j'utilise gdb.
Je ne comprends pas pourquoi il me manque le fichier strlen-sse2.S . Si je ne me trompe pas, ça corresponds à un machin du processeur. Et mes processeurs exploitent le sse2.
Et je ne parviens même pas à mettre la main sur le répertoire ../sysdeps/i386/i686/multiarch/strlen-sse2.S.

Je demande aussi si, à votre avis, ça vient de chez moi, ou dois-je faire un rapport de bug à Debian ?

Le strlen-sse2.S c'est rien, juste qu'il ne trouve pas le code source de la fonction strnlen pour te l'afficher.

Pour avoir une backtrace plus sympa, installe "python-soya-dbg" et relance gdb.
Avant de faire run, tu peux faire

Code:

break _soya.c:5135

Il va te demander si tu veux un futur breakpoint, tu réponds oui.

Ensuite "run", et quand il se sera arrêté, tu fais un

Code:

info locals

ou encore

Code:

bt full

Ce qui va t'afficher les variables accessibles et leur valeur à l'endroit ou tu t'es arrêté.

C'est sans doute pas ça qui va beaucoup t'aider, mais ton erreur là c'est un strlen appelé sur une chaîne qui n'existe pas ou qui ne se termine pas.

**deathdigger** · 29/09/2011, 12h26

Envoyé par GrandFather

MySQL prend certes des libertés avec l'ANSI SQL, mais là c'est un peu too much même pour lui...

Utilise plutôt ce genre de syntaxe:

Code:

UPDATE `test`SET nb = (CASE WHEN nb > 10 THEN nb - 10 ELSE 0 END) WHERE id = 2

Bravo !

**Grosnours** · 30/09/2011, 20h28

La honte était trop forte, j'ai craqué et j'ai externalisé proprement ce crétin de moteur. Ce fut long et pénible (marre des journées de 14h de rang), mais je me sens enfin regagner un peu de ma dignité.

**Wanou** · 30/09/2011, 20h50

Envoyé par deathdigger

J'ai envie de dire que plus grand monde désactive JS, dans la mesure où 90% des gros sites l'utilisent (au hasard google, youtube, Msn, facebook). C'est un peu comme continuer à supporter IE6, à un moment faut arrêter de se prendre la tête pour une minorité.

Ben, c'est marrant, mais si je me base sur les stats des sites web pro que je gère... IE6... Ben c'est encore plus de 40% des clients. Et tous les IE confondus ca fait 98%. 2% pour Firefox, Chrome et safari: Les visites de mes collègues barbus.

**Skiant** · 30/09/2011, 21h08

Envoyé par Wanou

Ben, c'est marrant, mais si je me base sur les stats des sites web pro que je gère... IE6... Ben c'est encore plus de 40% des clients. Et tous les IE confondus ca fait 98%. 2% pour Firefox, Chrome et safari: Les visites de mes collègues barbus.

Ca dépend du type de site que tu fourgues, aussi. J'ai bossé dans une boite de com' et on avait des stats sur des sites très variés (notamment un gros site de télécom, une brasserie, des trucs plus "officiels" aussi) et on tournait en moyenne autour de 10% à 15% d'IE6, c'était il y a un an. Depuis, la situation a pas mal évolué je crois, les grosses boites commencent à lâcher petit à petit XP pour passer à Vista (et donc IE7 minimum).

Par contre dans l'administration, ouais, ça doit tourner autour de 60-70% de WinXP avec IE6.

Après, il reste une lueur d'espoir avec Google Chrome Frame, mais globalement le monde du browser est un triste recommencement, cf l'article super intéressant (et un peu triste aussi) de Paul Irish au sujet des nouvelles versions d'IE.

**rOut** · 30/09/2011, 21h21

Envoyé par Skiant

Ca dépend du type de site que tu fourgues, aussi. J'ai bossé dans une boite de com' et on avait des stats sur des sites très variés (notamment un gros site de télécom, une brasserie, des trucs plus "officiels" aussi) et on tournait en moyenne autour de 10% à 15% d'IE6, c'était il y a un an. Depuis, la situation a pas mal évolué je crois, les grosses boites commencent à lâcher petit à petit XP pour passer à Vista (et donc IE7 minimum).

Par contre dans l'administration, ouais, ça doit tourner autour de 60-70% de WinXP avec IE6.

Après, il reste une lueur d'espoir avec Google Chrome Frame, mais globalement le monde du browser est un triste recommencement, cf l'article super intéressant (et un peu triste aussi) de Paul Irish au sujet des nouvelles versions d'IE.

Huhu, souvenirs souvenirs.

**Tomaka17** · 30/09/2011, 22h08

À propos d'IE j'ai trouvé un truc positif (c'est suffisamment rare pour être noté)

IE10 est le premier browser à supporter les grids en CSS
À moins bien sûr qu'il se fasse griller par un autre browser avant sa sortie

Les grids ça permet de faire un genre de layout tableau, mais en CSS uniquement : tu dis tel élément possède x lignes et x colonnes, et ensuite chaque enfant direct peut être placé dans une ou plusieurs cases précises
Je suis presque prêt à troquer toutes les nouveautés de CSS3 contre ces grids ou un truc équivalent

**rOut** · 30/09/2011, 22h13

HTML/CSS qui se dirige lentement mais sûrement vers clone de Swing.

Enfin, on va dire que c'est bien.

**Sekigo Le Magnifique** · 30/09/2011, 22h23

Merci de ta réponse, rOut. Je n'avais pas checké avant ce thread.
Bon, j'ai essayé de faire ce que tu m'as dis, histoire d'avoir plus d'informations. Mais je suis totalement ignorant avec gdb.
Le seul truc qui m'a paru suspect (enfin.... le truc un peu différent des autres plutôt), c'est ça :

Code:

#2  0xb78e3d58 in __pyx_f_5_soya_dump_info () at _soya.c:5135
        __pyx_2 = <optimized out>
        __pyx_5 = 0x0
        __pyx_8 = 0x0
        __pyx_10 = 0x0
        __pyx_3 = 0x0
        __pyx_6 = 0x0
        __pyx_9 = 0x0
        __pyx_1 = 0xb6789f8c
        __pyx_4 = 0x0
        __pyx_7 = 0x0

Avant, c'est le machin avec strlen-sse2. Après, c'est une suite de variable qui ont l'air de correctement tourner.
Mais vu que j'ignore à quoi correspond le __pyx_2....
J'ai même été checké dans les sources de soya, pour voir. Bon, je n'y comprends rien, je ne suis qu'un modeste programmeur en python, pas en C.

Tant pis pour soya.

**rOut** · 30/09/2011, 22h48

T'as pas une stack trace plus complète ?
En fait je n'avais pas vu mais les sources de soya semblent être générées à partir d'autre chose, donc c'est assez chiant à débugguer. Les variables ont des noms générés, les fonctions pareil... et _soya.c fait genre 100k lignes. Pour la valeur "<optimized-out>" c'est rien d’intéressant, juste que le débuggueur n'a pas pu lire la valeur de la variable parce que la variable a été optimisée et qu'elle n'existe plus vraiment.

Sinon chez moi (debian unstable) ça marche sans problème, mais je n'ai pas l'air d'avoir la même version que toi.
Qu'est-ce que te donne "aptitude versions python-soya" ?

Sinon, c'est dans PyString_FromString qu'il plante, certainement parce que la valeur passée à cette fonction (qui est une chaine de caractères en C c'est à dire un pointeur vers un tableau de caractères en mémoire), est soit complètement invalide (un pointeur vers de la mémoire qui n'appartient pas au process), soit ne se termine pas par "\0" comme doit le faire tout chaîne en C.
A vue de nez, je dirais que ça plante dans un des trois appels:

Code:

  __pyx_3 = PyString_FromString(((char *))glGetString(GL_VERSION)); ...
  __pyx_4 = PyString_FromString(((char *)glGetString(GL_RENDERER))); ...
  __pyx_5 = PyString_FromString(((char *)glGetString(GL_VENDOR))); ...

C'est à dire que l'appel à "glGetString(...)" renvoie de la merde. Qu'est ce que t'indique 'glxinfo | grep "OpenGL"' ? Tu as bien un driver OpenGL correct ?

**Sekigo Le Magnifique** · 01/10/2011, 00h07

Pour soya, il utilise Pyrex, qui sert pour l'écriture des modules. Un truc en C qui utilise en partie la syntaxe de Python. Ça peut expliquer l'aspect gargantuesque de _soya.c

Pour la version (normalement, on utilise la même):

Code:

~$ aptitude versions python-soya
i   0.15~rc1-6                                          unstable                         500

Pour OpenGL :

Code:

~$ glxinfo | grep "OpenGL"
OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Intel(R) 945GME x86/MMX/SSE2
OpenGL version string: 1.4 Mesa 7.11
OpenGL extensions:

Là, c'est pour le netbook. Sur l'autre pc avec la carte nvidia, ça fait pareil, l'erreur de segmentation.

Et le backtrace complet :

Code:

Program received signal SIGSEGV, Segmentation fault.
__strlen_sse2 () at ../sysdeps/i386/i686/multiarch/strlen-sse2.S:46
46      ../sysdeps/i386/i686/multiarch/strlen-sse2.S: Aucun fichier ou dossier de ce type.
        in ../sysdeps/i386/i686/multiarch/strlen-sse2.S
(gdb) bt full
#0  __strlen_sse2 () at ../sysdeps/i386/i686/multiarch/strlen-sse2.S:46
No locals.
#1  0x0809e64b in PyString_FromString ()
No symbol table info available.
#2  0xb78e3d58 in __pyx_f_5_soya_dump_info () at _soya.c:5135
        __pyx_2 = <optimized out>
        __pyx_5 = 0x0
        __pyx_8 = 0x0
        __pyx_10 = 0x0
        __pyx_3 = 0x0
        __pyx_6 = 0x0
        __pyx_9 = 0x0
        __pyx_1 = 0xb6789f4c
        __pyx_4 = 0x0
        __pyx_7 = 0x0
#3  __pyx_f_5_soya_init (__pyx_self=0x0, __pyx_args=0xb7bd202c, __pyx_kwds=0x0)
    at _soya.c:6386
        __pyx_v_title = 0xb796a1e0
        __pyx_v_width = 640
        __pyx_v_height = 480
        __pyx_v_fullscreen = 0
        __pyx_v_resizeable = 1
---Type <return> to continue, or q <return> to quit---
        __pyx_v_create_surface = 1
        __pyx_v_sound = 0
        __pyx_v_sound_device = 0xb7bd20b0
        __pyx_v_sound_frequency = 44100
        __pyx_v_sound_reference_distance = 1
        __pyx_v_sound_doppler_factor = 0.00999999978
        __pyx_v_quiet = 0
        __pyx_v_soya = 0xb7bd24f4
        __pyx_v_SDL_UNICODE = 0x82601d0
        __pyx_v_atexit = 0x82601d0
        __pyx_r = <optimized out>
        __pyx_1 = 0x0
        __pyx_2 = <optimized out>
        __pyx_3 = <optimized out>
        __pyx_4 = <optimized out>
        __pyx_5 = 0x0
        __pyx_6 = 0x0
        __pyx_7 = 0x0
        __pyx_8 = 0x0
        __pyx_9 = 0x0
        __pyx_argnames = {0xb7915015 "title", 0xb79152f6 "width", 0xb7915991 "height", 
          0xb791501b "fullscreen", 0xb7915026 "resizeable", 0xb7915031 "create_surface", 
---Type <return> to continue, or q <return> to quit---
          0xb7915d67 "sound", 0xb7915040 "sound_device", 0xb791504d "sound_frequency", 
          0xb791505d "sound_reference_distance", 0xb7915076 "sound_doppler_factor", 
          0xb791508b "quiet", 0x0}
#4  0x080d9e64 in PyEval_EvalFrameEx ()
No symbol table info available.
#5  0x080dbb27 in PyEval_EvalCodeEx ()
No symbol table info available.
#6  0x080dbc37 in PyEval_EvalCode ()
No symbol table info available.
#7  0x080fc5ad in PyRun_InteractiveOneFlags ()
No symbol table info available.
#8  0x080fc7a8 in PyRun_InteractiveLoopFlags ()
No symbol table info available.
#9  0x080fc8c4 in PyRun_AnyFileExFlags ()
No symbol table info available.
#10 0x0805e4e2 in Py_Main ()
No symbol table info available.
#11 0x0805d6bb in main ()
No symbol table info available.

========
Sinon, euuuuuuh. J'ai un truc étrange qui s'est passé, pendant que j'écrivais ce message. Je colle le log complet :

Code:

Là, rien ne fonctionne
anh@debianLaptop:~$ python
Python 2.6.7 (r267:88850, Aug  3 2011, 15:19:01) 
[GCC 4.6.1] on linux2
>>> import soya
>>> soya.init()
Erreur de segmentation

Là, j'ai tapé machinalement sans faire gaffe, et paf, ça fonctionne.
Le code python est exactement le même.
anh@debianLaptop:~$ gdb
GNU gdb (GDB) 7.3-debian
This GDB was configured as "i486-linux-gnu".
(gdb) python 
>import soya
>soya.init()
>* Soya * Using Software Surface.
* Soya * Using 8 bits stencil buffer
* Soya * OpenGL initialization  [OK]

* Soya * version 0.15rc1
* Using OpenGL 1.4 Mesa 7.11
*   - renderer : Mesa DRI Intel(R) 945GME x86/MMX/SSE2
*   - vendor   : Tungsten Graphics, Inc
*   - maximum number of lights        : 8
*   - maximum number of clip planes   : 6
*   - maximum number of texture units : 8
*   - maximum texture size            : 2048 pixels

Du coup, avec la deuxième partie, j'ai une fenêtre qui s'ouvre, et le truc qui à l'air de fonctionner correctement. Maintenant, lancer gdb de cette manière à chaque fois que je veux tester du code, ce n'est pas vraiment pratique.
J'ai franchement rien compris là.

**rOut** · 01/10/2011, 00h53

Surtout que la deuxième partie c'est pas que tu débuggue un python mais que tu lances python dans gdb (gdb a la possibilité d’exécuter des scripts python pour aider à debugguer un programme).
Je pense quand même que ça a à voir avec le driver OpenGL... glGetString ne retourne 0 que s'il y a une erreur, et la spec dit que les chaines doivent être terminée par 0.

Ton PC avec la carte NVidia, c'est le driver proprio nvidia qui est installé ?

Peut être la création du contexte OpenGL qui se fait mal... Si tu fais 'export DISPLAY=:0' avant de lancer python ?

---------- Post added at 00h42 ---------- Previous post was at 00h35 ----------

Sinon pour débugguer du python, tu peux utiliser pdb:
Tu fais un script python qui contient :

Code:

import soya
soya.init()

Et ensuite pdb script.py, puis next pour executer la ligne "import...", et step pour aller pas à pas dans soya.init() (n, puis s pour chaque step marche aussi). Tu ne verras pas grand chose d'interessant, mais je vois qu'il commence par écrire au moins

Code:

* Soya * Using Software Surface.
* Soya * Using 8 bits stencil buffer
* Soya * OpenGL initialization  [OK]

Avant de faire l'appel à OpenGL, et je me dis que lorsqu'il plante il n'a peut être pas le temps d'écrire ça à l'écran. Il te dira peut être quelque chose de plus intéressant.

---------- Post added at 00h53 ---------- Previous post was at 00h42 ----------

Tu peux aussi essayer avec

Code:

import soya
soya.init(quiet=True)

Ce qui évite qu'il essaie de récupérer les infos qui font planter pour les afficher, mais bon... je pense que si un pauvre glGetString merde c'est que c'est pas bon signe pour la suite.

Discussion: Le topic de la programmation, string, chaînes, cuir et compagnie

Outils de la discussion

Règles de messages