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

**Sekigo Le Magnifique** · 01/10/2011, 10h36

Bon, avec pdb, ça ne donne rien. Il ne me donne aucune information.
Quand je met quiet=True, ça ne fait rien. J'ai essayé avec un script un peu plus complet, mais il finit par planter dans le render, vu que init ne passe pas. Quoi qu'il advienne, il y a une erreur de segmentation.

Pour mon pc avec nvidia, c'est bien le driver proprio qui est installé.

Le display est bien renseigné. Et les drivers sont bien chargés.

J'ai essayé divers trucs 3D, et excepté tout ce qui est en rapport avec soya, tout passe correctement. J'ai essayé aussi de tester avec python-opengl, avec les exemples fournis, et aucun problème dans les rendus.

Maintenant, je ne sais pas pourquoi il passe avec gdb et pas quand je lance le script tout seul. Ça me gave. Et je ne comprends pas pourquoi il marche chez toi, et sur aucun de mes pc.

Bon, cet aprèm, je vais essayer de compiler les sources de soya, et je verrais ce que ça donne en brut. Si j'ai un problème avec soya proprement dit, ou avec les patchs de Debian. Et j'enverrais un rapport de bug sur le site correspondant.

Putain, j'étais parti pour tester vite fait Soya en plus. À la base, je voulais utiliser panda3d, mais j'avais un problème de version sur une dépendance.

Edit: Bon, ça me gave. J'ai des erreurs dans tout les sens quand j'essaie de compiler. J'abandonne.

**DaP** · 01/10/2011, 15h35

Envoyé par Sekigo Le Magnifique

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.

C'est pas du Cython justement, vu à quoi ressemblent les erreurs ? Honnêtement, le mieux à faire c'est de voir si le bug a été reporté aux développeurs.

**Tomaka17** · 01/10/2011, 18h35

J'y connais rien à Python, mais le truc qui me semblerait le plus logique c'est que Soya a été mal compilé ou un fichier a été corrompu pendant le téléchargement ou un truc du genre
Ou alors une incompatibilité entre ta version de Soya et ta version de Python

**Sekigo Le Magnifique** · 01/10/2011, 18h59

Non, non. J'ai vérifié en long, en large et en travers, les versions de python et de soya ne sont pas à incriminer (du moins, il n'y a pas incompatibilité). La version de python utilisé dans gdb est la même que celle utilisé dans l'environnement courant. Car, je le rappelle, ça fonctionne avec gdb, mais pas en stand-alone.
Pour le Cython, c'est, je pense, la même utilité que Pyrex. Mais c'est ce dernier qui a été utilisé.

Pour les rapports de bugs, j'ai déjà été checké à gauche et à droite. Je n'en ai rien tiré de bien intéressant. Mais bon, en même temps, Google est bien pollué par les parasites qui récupèrent les données des maillings list. Et du coup, c'est super chiant de séparer le bon grain de l'ivraie.

J'attendrais une nouvelle version (.... la dernière datant de 2010, mais bon) de Soya, Python ou Pyrex (pour recompiler).

De toute façon, j'ai laissé tomber, comme dit plus haut. J'aurais bien voulu savoir pourquoi ça fonctionnais DANS gdb, et pas à l'extérieur. Mais ça dépasse mes limites, et j'en ai un peu ras le bol.

**rOut** · 01/10/2011, 19h16

Il y a un bout de code dans soya qui "attend" qu'OpenGL soit prêt. C'est bien la première fois que je vois ça, mais admettons.
Il fait ça de la manière suivante:

Code:

	# Wait until OpenGL is REALLY ready
	cdef int i
	from time import sleep
	if not quiet:
		sys.stdout.write("* Soya * OpenGL initialization ")
	for i from 0 <= i < 10:
		if glGetString(GL_RENDERER) != NULL: break
		if not quiet:
			sys.stdout.write(".")
		sleep(0.1)
	else:
		sys.stderr.write("\n* Soya * ERROR : OpenGL is not ready... Soya will crash soon i guess :-(\n")
	if not quiet:
		sys.stdout.write(" [OK]\n")

Ce qui sous entend que pendant un moment, glGetString(GL_RENDERER) renvoie NULL. A mon avis c'est le cas pour les autres appels, même si ce test est passé. Il faudrait ajouter les tests pour les autres valeurs des paramètres de glGetString, mais bon... je trouve ça quand même étonnant de devoir attendre comme ça. L'initialisation n'est pas asynchrone à priori.

**Tomaka17** · 01/10/2011, 19h46

Peut être que OpenGL est initialisé dans un thread différent, et que le code plus haut est là pour attendre que le thread en question ait dépassé un certain point
Au quel cas la présence du débuggeur ralentirait suffisamment le programme pour que ce soit le cas, par contre si tu l'exécutes directement ça ne l'est pas

Encore une fois c'est une simple supposition

**moimadmax** · 01/10/2011, 20h06

Si un pro du Access me lit. Je bloque sur une connerie depuis plusieurs heures.
J'ai récupérer une base de logs au format access que je doit imprimer. J'ai donc créer une autre base ou j'ai ajouter la base de log en table liés (afin de pouvoir changer de base de logs plus facilement). Et dans cette base fraichement crée, j'ai fait un état. Jusque là tout va bien.
Dans ces logs les dates sont au format Unix. J'ai donc ~~créer~~ pomper une petite fonction que voilà:

Code:

Function ts2hr(ts)
    Dim temp
    temp = ts
    temp = (ts + 2209161600#) / 86400
    ts2hr = Format(temp, "dd/mm/yy hh:nn:ss")
End Function

Bon au début elle faisait une ligne mais j'ai du décomposer.
Et le problème vient que lorsque, dans les propriétés du champ de l'état je mets la source du contrôle à =ts2hr([ALARM_TIME].[Valeur])
Ben ca ne fonctionne pas et je ne comprend pas pourquoi.
- Il me sort : erreur d'execution 13

incompatibilité de Type. Et lorsque dans le code je mets un espion sur la variable elle contient Erreur 0. Et elle est du type Variant/error
- Bien sur le champ est de type numérique.
- Ma fonction est bonne car si je remplace ts par une valeur de ma base la date correspond.
- L'appel de fonction est bon car si je le remplace par =ts2hr(12) ca me donne 01/01/1970 00:00:12.
- J'avais essayé de transmettre que [ALARM_TIME] et de faire le .Value dans le code mais c'est Erreur d'execution 2427

Expression sans paramètre.

Je hais access. C'est sensé être simple et je trouve ca super compliqué. En Php/Mysql ca serai déjà fait depuis longtemps.

En tout cas merci pour l'aide.

Je vais manger ça va me défouler.

**DaP** · 01/10/2011, 23h58

Envoyé par Sekigo Le Magnifique

Non, non. J'ai vérifié en long, en large et en travers, les versions de python et de soya ne sont pas à incriminer (du moins, il n'y a pas incompatibilité). La version de python utilisé dans gdb est la même que celle utilisé dans l'environnement courant. Car, je le rappelle, ça fonctionne avec gdb, mais pas en stand-alone.
Pour le Cython, c'est, je pense, la même utilité que Pyrex. Mais c'est ce dernier qui a été utilisé.

Pour les rapports de bugs, j'ai déjà été checké à gauche et à droite. Je n'en ai rien tiré de bien intéressant. Mais bon, en même temps, Google est bien pollué par les parasites qui récupèrent les données des maillings list. Et du coup, c'est super chiant de séparer le bon grain de l'ivraie.

J'attendrais une nouvelle version (.... la dernière datant de 2010, mais bon) de Soya, Python ou Pyrex (pour recompiler).

De toute façon, j'ai laissé tomber, comme dit plus haut. J'aurais bien voulu savoir pourquoi ça fonctionnais DANS gdb, et pas à l'extérieur. Mais ça dépasse mes limites, et j'en ai un peu ras le bol.

Le tracker est là : http://gna.org/bugs/?group=soya
C'est du tracas pour rien d'essayer de debugger si tu as juste les références vers le fichier .c.

**gregounech** · 10/10/2011, 14h37

Bon voila, ca fait deux semaines que j'ai commence mes cours sur Haskell, et putain je galere bien quand meme.

**Møgluglu** · 10/10/2011, 15h39

Tiens bon, après tu seras respecté et craint, et tu pourras dire "une monade est un endofoncteur muni de deux transformations naturelles, et alors?"

**TiNitro** · 10/10/2011, 16h42

+1

**gregounech** · 13/10/2011, 04h05

Envoyé par Møgluglu

Tiens bon, après tu seras respecté et craint, et tu pourras dire "une monade est un endofoncteur muni de deux transformations naturelles, et alors?"

Hmmm, ok.

Je suis en plein boulot sur Haskell la justement, et c'est a faire pour demain 9h...

---------- Post added at 03h05 ---------- Previous post was at 02h58 ----------

Bon, je viens de m'impressionner en reussissant du premier coup une question donc du coup, je vais vous envoyer la question et ma reponse pour montrer mon niveau merdique.

Envoyé par Question

Write a function contains :: String -> String -> Bool that returns True if the first
string contains the second as a substring (this exercise is the same as the last of the optional
exercises of the previous tutorial).
Main> contains "Example" "amp"
True
Main> contains "Example" "xml"
False

Envoyé par Reponse

contains :: String -> String -> Bool
contains xs [] = False
contains [] ys = False
contains (x:xs) ys |take (length ys) (x:xs) == ys = True
|otherwise = contains xs ys

**Møgluglu** · 13/10/2011, 10h14

Haskell c'est beau.

Suivant le contexte de la question, tu triches peut-être un peu avec ton take (length ys). Même, c'est pas très beau, parce que (lenght ys) va parcourir la chaîne ys pour trouver sa longueur, puis la comparaison va encore reparcourir les 2 chaînes ensemble. Alors que l'esprit de l'exo semble être de t'obliger à éplucher chacune des chaînes caractère par caractère, en faisant les bons matchings et les bons appels récursifs.

D'ailleurs, aucune chaîne ne contient la chaîne vide? Le fait que ce cas ne soit (quasiment) jamais utilisé suggère qu'il y a un problème.

Mais c'est bien ce que t'as fait, hein.

**gregounech** · 13/10/2011, 10h55

PUTEEZEEEEEEEEEEEEE

Mon réveil ne marche vraiment pas.

**Grosnours** · 13/10/2011, 10h58

Ceci dit Mogluglu a parfaitement raison, l'exo est là pour te faire faire du pattern matching et de la récursion a fond les bidons, je doute que ta solution soit la bonne.
Il faut vraiment s’imprégner de la philosophie de la prog fonctionnelle, ce qui est un peu rude au début parfois, et puis cela ira tout seul.

**Tomaka17** · 13/10/2011, 13h35

Je sens la présence des démons de la programmation fonctionnelle sur ce topic

Vade retro Haskell

**olih** · 13/10/2011, 13h38

Le scheme c'est marrant.
*idée positive du jour*

**Tomaka17** · 13/10/2011, 13h42

Le (Lisp (ça (a (l'air (très (fun (aussi)))))))

**Møgluglu** · 13/10/2011, 13h56

T'as oublié deux parenthèses :
(Le (Lisp (ça (a (l'air (très (fun (aussi))))))))

**deathdigger** · 13/10/2011, 15h03

F#TW

Petite question Silverlight (ben ouais personne en parle

) :
Je suis en train de tester cette petite chose, et c'est plutôt sympa, mais une interrogation me taraude :
Peut-on faire quelque chose de joli graphiquement sans passer par la case Expression Blend ?

**Grosnours** · 13/10/2011, 16h11

Silverlight, Silverlight....
Ah, tu parles de la techno morte-vivante Microsoft donc on ne cesse d'humilier et martyriser les devs ?

**Møgluglu** · 13/10/2011, 17h12

F#, c'est le portage de Fortran 77 pour .Net ?

**smokytoks** · 13/10/2011, 17h24

Envoyé par deathdigger

Peut-on faire quelque chose de joli graphiquement sans passer par la case Expression Blend ?

Non.

**Grosnours** · 13/10/2011, 18h53

Envoyé par Møgluglu

F#, c'est le portage de Fortran 77 pour .Net ?

Non, le "portage" de SML/CAML sur .NET, une sorte de Graal à mes yeux...

**deathdigger** · 13/10/2011, 19h49

Envoyé par Grosnours

Silverlight, Silverlight....
Ah, tu parles de la techno morte-vivante Microsoft donc on ne cesse d'humilier et martyriser les devs ?

Ça reste toujours mieux que du flash

Niveau performance, c'est sympa, ça revient bien moins cher que de faire du flash, et au moins tu es pas obligé de tester 107 ans pour voir si c'est compatible avec tous les navigateurs

J'aurais pu le faire en Webdev c'est vrai...

**smokytoks** · 13/10/2011, 19h56

Envoyé par deathdigger

J'aurais pu le faire en Webdev c'est vrai...

Vade retro !

**Grosnours** · 13/10/2011, 20h10

Envoyé par deathdigger

Ça reste toujours mieux que du flash

Niveau performance, c'est sympa, ça revient bien moins cher que de faire du flash, et au moins tu es pas obligé de tester 107 ans pour voir si c'est compatible avec tous les navigateurs

Flash Builder est gratos (enfin si tu es soit étudiant, soit personnel de fac, soit chômeur), la version 4.5 te permet directement de déployer sur toutes les plateformes, le plugin déployé sur plus de 95% du parc (et tu peux toujours faire du Air si tu veux atteindre les Ipad/Iphone) donc s'il y a bien une chose qu'on ne fait jamais quand on développe en flash c'est de passer du temps pour s'assurer de la compatibilité. Sans compter que cette techno n'a pas été suicidée plusieurs fois de suite par son propre créateur, contrairement à Silverlight. C'est d'ailleurs la principale chose qui m'ennuie avec ce dernier qui est sinon une alternative tout à fait intéressante.

M'est avis que ceux qui comptent sur une mort rapide de flash/silverlight (voire de tous les plugins en général) en comptant sur HTML5 vont au devant de grosses désillusions.

**TiNitro** · 13/10/2011, 20h31

Envoyé par deathdigger

Peut-on faire quelque chose de joli graphiquement sans passer par la case Expression Blend ?

Si, mais c'est chiant. Mais l'interface étant entièrement décrite en XAML (XML donc), tu peux faire une interface de la mort avec le Notepad si tu veux...

**Møgluglu** · 13/10/2011, 21h16

Envoyé par Grosnours

Non, le "portage" de SML/CAML sur .NET, une sorte de Graal à mes yeux...

Ah oui, une façon de cumuler les inconvénients d'un langage dont la syntaxe est aussi moche que celle du C et dont la sémantique est aussi incompréhensible que celle de Haskell avec la lourdeur d'un environnement comme .Net. Ça c'est la classe.

Envoyé par Grosnours

Silverlight, Silverlight....
Ah, tu parles de la techno morte-vivante Microsoft donc on ne cesse d'humilier et martyriser les devs ?

Ah, ça y est je me souviens, vous parlez du truc qui s'affiche dans un carré dans certaines pages web et qui dit vous n'avez pas le plugin Silverlight ou le plugin Silverlight s'est vautré, veuillez rebooter ? Heureusement, personne ne s'en sert.

**Skiant** · 13/10/2011, 22h26

Envoyé par Grosnours

M'est avis que ceux qui comptent sur une mort rapide de flash/silverlight (voire de tous les plugins en général) en comptant sur HTML5 vont au devant de grosses désillusions.

Surtout que le HTML5 c'est pas un langage de progra. Ce que les gens appellent "HTML5" quand ils parlent de trucs remplaçant Flash, c'est du Javascript avec parfois un peu de sémantique HTML5 en support.

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

Outils de la discussion

Règles de messages