Contenu | Rechercher | Menus

Annonce

Ubuntu 16.04 LTS
Commandez vos DVD et clés USB Ubuntu-fr !

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.

#1 Le 13/04/2016, à 09:46

grim7reaper

/* Topic des codeurs [9] */

Bienvenue dans le TdC 0x9.
Ceci est la suite de ce fil.

Historique des précédents fils :
        • Topic des codeurs couche-tard [0] : du 14 avril 2010 au 12 juin 2010 (100 pages).
        • Topic des codeurs couche-tard [1] : du 12 juin 2010 au 5 septembre 2010 (100 pages).
        • Topic des codeurs couche-tard [2] : du 5 septembre 2010 au 16 décembre 2010 (100 pages).
        • Topic des codeurs couche-tard [3] : du 16 décembre 2010 au 28 février 2011 (100 pages).
        • Topic des codeurs couche-tard [4] : du 28 février 2011 au 6 juin 2011 (101 pages).
        • Topic des codeurs couche-tard [5] : du 6 juin 2011 au 10 septembre 2011 (100 pages).
        • Topic des codeurs [6] : du 10 septembre 2011 au 4 février 2012 (100 pages).
        • Topic des codeurs [7] : du 04 février 2012 au 17 novembre 2012 (100 pages).
        • Topic des codeurs [8] : du 17 novembre 2012 au 13 avril 2016 yikes (101 pages).

Amusez-vous bien, et produisez-nous du beau code. smile

Et n’oubliez pas notre devise :

import Control.Concurrent (threadDelay)
import Data.List          (intersperse)

main :: IO ()
main = sequence_ $ cycle (intersperse waitOneSec printMotto ++ [waitOneSec])
    where printMotto = map putStrLn ["In", "Code", "We", "Trust!"]
          waitOneSec = threadDelay 1000000

Hors ligne

#2 Le 13/04/2016, à 09:49

grim7reaper

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

J'ai pas remis le défi du TdC vu que ça n’avait pas l’air d’avoir un gros succès ^^"
Je le remettrai si les gens veulent.



The Uploader a écrit :

Ruby, c'est la vie.

Ouais, pour scripter rapidement c’est cool.
Mais pour développer de gros trucs je préfère quand même le typage statique et fort (Ada, Haskell, Rust, …), c’est tellement plus agréable.

Hors ligne

#3 Le 13/04/2016, à 13:30

The Uploader

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

Pareil, je l'utilise exclusivement pour les scripts. C'est tellement plus agréable que Bash.

(oui bon je suis sous Windows, donc PowerShell s'impose j'imagine. Sauf que non, juste non. Ruby + ConEmu + Bash (apporté par Git for Windows) + Gow ça me va très bien)

Pour les trucs sérieux -> typage statique et fort.

Dernière modification par The Uploader (Le 13/04/2016, à 13:33)


- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4200, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster AWE64, 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

#4 Le 14/04/2016, à 02:10

Oni_Shadow

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

Pourquoi faire une nouvelle section toutes les cent pages ?


Travaux sur Unity 8 abandonné ? Pas par tout le monde !
─▶ Travaux sur les téléphones opéré par Ubport
─▶ Travaux sur le DE opéré par l’équipe de Yunit
N’hésitez pas à contribuer, toute aide est la bienvenue :) Premier objectif : passage de Mir à Wayland.

Hors ligne

#5 Le 14/04/2016, à 10:44

grim7reaper

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

À une époque, le forum avait des problèmes avec les long sujets et il a été décidé de limiter les sujets à 100 pages.
Je ne sais pas si le problème est toujours d’actualité (quand je vois les topic des photos et du cinéma, je dirait que ça n’a pu lieu d’être en effet…).

Hors ligne

#6 Le 14/04/2016, à 12:11

Elzen

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

Normalement, le problème n'est plus d'actualité. Mais garder le changement à 100 pages n'est pas plus mal, je trouve (ça se fait sur d'autres forums qui n'ont jamais eu ce soucis, pour des questions d'archivage et de facilité de lecture, notamment (d'ailleurs, l'autre jour où je cherchais ça, la découpe en plusieurs topics avec le post de rappel au début de chaque m'a bien aidé à le retrouver)).

Sinon, votre discussion en cours me fait penser : ça existe, un tableau synthétique rapide résumant la liste des principaux langages cools et leurs caractéristiques (typage fort/faible & statique/dynamique, paradgimes supportés, compilé/interprété, façon de délimiter les blocs…) ?

Hors ligne

#7 Le 14/04/2016, à 17:01

HP

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

The Uploader a écrit :

Pareil, je l'utilise exclusivement pour les scripts. C'est tellement plus agréable que Bash.

+1


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

Hors ligne

#8 Le 14/04/2016, à 20:35

Oni_Shadow

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

pourquoi préféré Ruby à python pour les scripts ?
par ailleurs participez-vous au développement de Diaspora* ?


Travaux sur Unity 8 abandonné ? Pas par tout le monde !
─▶ Travaux sur les téléphones opéré par Ubport
─▶ Travaux sur le DE opéré par l’équipe de Yunit
N’hésitez pas à contribuer, toute aide est la bienvenue :) Premier objectif : passage de Mir à Wayland.

Hors ligne

#9 Le 14/04/2016, à 21:13

HP

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

Oni_Shadow a écrit :

pourquoi préféré Ruby à python pour les scripts ?

Parce que Ruby est supérieur…
Pas de prise de tête avec des bytes et des strings
Pour gem et bundler
Pour la facilité déconcertante de gérer des process, forks, threads…
Pour l'expressivité, la souplesse, la métaprogrammation… et j'en passe.


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

Hors ligne

#10 Le 14/04/2016, à 21:29

grim7reaper

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

Oni_Shadow a écrit :

pourquoi préféré Ruby à python pour les scripts ?

Parce que je préfère la philosophie de Ruby (et je le fait que j’ai un background Perl doit jouer aussi).
Cela dit je fais aussi beaucoup de Python (3.X surtout, faut pas déconner (mais 2.7 voir 2.6 quand j’ai pas le choix hmm)).
Je fais même sûrement plus de Python que de Ruby d’ailleurs sad (parce que Python dispose de bibliothèques abouties dans bien plus de domaines que Ruby (IMHO, c’est la faute à RoR qui trop mis le focus de la communauté Ruby sur le Web, au détriment des autres domaines…)).

Oni_Shadow a écrit :

par ailleurs participez-vous au développement de Diaspora* ?

Nope.
Pourquoi ?

Hors ligne

#11 Le 14/04/2016, à 21:42

Oni_Shadow

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

D'accord pour python.
Pour diaspora* , je sais que les dev sont principalement allemands et franćais, comme il y a peu de dev ruby (du moins, il me semble), je demandais....


Travaux sur Unity 8 abandonné ? Pas par tout le monde !
─▶ Travaux sur les téléphones opéré par Ubport
─▶ Travaux sur le DE opéré par l’équipe de Yunit
N’hésitez pas à contribuer, toute aide est la bienvenue :) Premier objectif : passage de Mir à Wayland.

Hors ligne

#12 Le 18/04/2016, à 20:59

vv221

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

Salut les codeurs !

Si vous êtes joueurs, vous connaissez peut-être ScummVM, un moteur natif qui permet de faire tourner toute une collection de "vieux" jeux allant des Monkey Island aux Gobliiins en passant par Beneath a Steel Sky et Flight of the Amazon Queen (ces deux derniers sont dans les dépôts de Debian).
Il se trouve qu’un de leurs devs souhaite apporter à ce moteur la gestion de Starship Titanic, un jeu d’énigmes et d’aventure réalisé par le grand, l’unique, l’inénarrable Douglas Adams ! Si vous ne connaissez pas ce monsieur, commencez par rougir de honte puis courez chez votre libraire lui demander la trilogie en cinq tomes du Guide du Voyageur Galactique, plus connue sous le diminutif de "H2G2".

Dans ce but, ils ont besoin de coups de main, en particulier pour comprendre le code en assembleur du jeu original (pour Windows) et pour ré-implémenter celui-ci au sein de ScummVM en C++.

Vous pouvez en lire un peu plus à ce sujet par ici :
Implementing Starship Titanic in ScummVM (blogspot.fr)

Vous pouvez contacter le développeur à l’initiative de ce projet sur les forums de GOG.com :
https://www.gog.com/forum/starship_tita … ip_titanic

Merci par avance à tous ceux qui pourront donner un coup de main, et aux autres qui prendront le temps de poster quelques encouragements pour ce courageux développeur wink


Jouer sur Ubuntu ? Facile !

Hors ligne

#13 Le 23/04/2016, à 02:12

Oni_Shadow

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

Je me pose une question, et je me suis dit qu'ici serait certainement le meilleur endroit pour obtenir une réponse. Connaître un langage bas niveau comme rust, c/++ à-t-il encore du sens pour les non-professionnel ? Je veux dire, hormis certaines application ciblée (système d'exploitation, jeux vidéo, logiciels à haute performance), je ne vois plus trop l’Intérêt.
Il y avait bien l'embarqué avant, mais avec l'explosion de pico-ordinateurs et de l'IdO, l'embarqué à souvent des systèmes bien plus puissant qu'avant pouvant supporter jusqu'à Java, python ou du Web sans soucis.

Il doit y avoir des applications qui m'échappe, aussi me tourné-je vers vous smile


Travaux sur Unity 8 abandonné ? Pas par tout le monde !
─▶ Travaux sur les téléphones opéré par Ubport
─▶ Travaux sur le DE opéré par l’équipe de Yunit
N’hésitez pas à contribuer, toute aide est la bienvenue :) Premier objectif : passage de Mir à Wayland.

Hors ligne

#14 Le 25/04/2016, à 09:17

grim7reaper

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

@vv221 : pas trop mon domaine/centre d’intérêt.



Oni_Shadow a écrit :

Je me pose une question, et je me suis dit qu'ici serait certainement le meilleur endroit pour obtenir une réponse. Connaître un langage bas niveau comme rust, c/++ à-t-il encore du sens pour les non-professionnel ?

- C : ça peut-être utile de le connaître pour contribuer à des projets libres (y’en a encore pas mal en C) et pour la « culture » (c’est un langage important dans l’histoire de l’info et il en a inspiré pas mal d’autres). Mais pour faire des nouveau dev’, non clairement pas (trop de manque, trop facile de faire des programmes buggué et/ou avec des failles de sécurité, …)
- C++ : idem que le C, avec moins de manque quand même (mais mal branlé aussi, même si ça s‘arrange avec mes dernières versions il part de loin…) et le côté culture étant moins prononcé je pense.
- Rust : je pense qu’il y a un intérêt à y jeter un œil car c’est un langage assez bien pensé et qui met en avant des concepts important (ownership, memory safety sans GC, typage fort, …) qui sont totalement raté par d’autres langages (Java, Go, …). Donc lui ça peut valoir le coup je pense.

Oni_Shadow a écrit :

Il y avait bien l'embarqué avant, mais avec l'explosion de pico-ordinateurs et de l'IdO, l'embarqué à souvent des systèmes bien plus puissant qu'avant pouvant supporter jusqu'à Java, python ou du Web sans soucis.

Y’a encore beaucoup d’embarqué qui a des contraintes fortes.
Et c’est pas parce que tu as plus de ressources qu’il faut les gaspiller. C’est avec ce genre de raisonnement qu’on se retrouve à valider la loi de Wirth…

Hors ligne

#15 Le 25/04/2016, à 15:50

Oni_Shadow

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

D'accord, merci pour ces précisions. smile


Travaux sur Unity 8 abandonné ? Pas par tout le monde !
─▶ Travaux sur les téléphones opéré par Ubport
─▶ Travaux sur le DE opéré par l’équipe de Yunit
N’hésitez pas à contribuer, toute aide est la bienvenue :) Premier objectif : passage de Mir à Wayland.

Hors ligne

#16 Le 25/04/2016, à 16:58

Elzen

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

J'ai sans doute déjà posé la question il y a un moment, mais, il y a des gens qui s'y connaissent en Makefile, dans le coin ?

Dans mon manuscrit de thèse, les illustrations doivent être converties en PDF, vu que LaTeX et le SVG, ç'n'est pas trop ça. Donc j'ai besoin d'une règle de ce genre-là :

SVGs=$(wildcard */*.svg)
ILLUs=$(SVGs:.svg=.pdf)

%.pdf: %.svg
	rsvg-convert -f pdf $< -o $@

Seulement, il n'y a pas que les dessins qui doivent être en PDF pour être intégrés. Il y a aussi, notamment, les courbes. Donc j'ai aussi besoin d'une règle de ce genre-là :

TSVs=$(wildcard */*.tsv)
PLTs=$(wildcard */*.plt)
CURVs=$(PLTs:.plt=.pdf)

%.pdf: %.tsv %.plt
	gnuplot $<

Et là, fatalement, ça coince, parce que ça fait deux⁽¹⁾ règles « %.pdf », donc la seconde n'est pas prise en compte.

Je vois deux moyens de contourner le problème : d'une part, utiliser des extensions supplémentaire pour s'y retrouver, du type :

SVGs=$(wildcard */*.svg)
ILLUs=$(SVGs:.svg=-illu.pdf)

TSVs=$(wildcard */*.tsv)
PLTs=$(wildcard */*.plt)
CURVs=$(PLTs:.plt=-curv.pdf)

%-illu.pdf: %.svg
	rsvg-convert -f pdf $< -o $@

%-curv.pdf: %.tsv %.plt
	gnuplot $<

(Mais je trouve ça assez moche et pas pratique à l'usage, genre c'est lourd à taper dans les \includegraphics), et d'autre part, ranger ça dans des répertoires particuliers, du type :

SVGs=$(wildcard illus/*.svg)
ILLUs=$(SVGs:.svg=.pdf)

TSVs=$(wildcard curvs/*.tsv)
PLTs=$(wildcard curvs/*.plt)
CURVs=$(PLTs:.plt=.pdf)

illus/%-illu.pdf: illus/%.svg
	rsvg-convert -f pdf $< -o $@

curvs/%.pdf: curvs/%.tsv curvs/%.plt
	gnuplot $<

(Mais ce n'est pas pratique au niveau rangement, pour retrouver quel fichier sert à quelle partie du manuscrit). Ce que j'aimerais, c'est un règle qui ressemblerait à :

SVGs=$(wildcard */*.svg)
ILLUs=$(SVGs:.svg=.pdf)

TSVs=$(wildcard */*.tsv)
PLTs=$(wildcard */*.plt)
CURVs=$(PLTs:.plt=.pdf)

%.pdf [IF IN $(ILLUs)]: %.svg
	rsvg-convert -f pdf $< -o $@

%.pdf [IF IN $(CURVs)]: %.tsv %.plt
	gnuplot $<

Mais je n'ai rien trouvé qui y ressemble jusque là. Vous sauriez si c'est faisable ? Et dans le cas contraire, laquelle des deux manières de contourner ci-dessus vous semble la moins moche ?

Edit : ah, ben, à force de chercher, on dirait bien que la bonne façon de faire est :

SVGs=$(wildcard */*.svg)
ILLUs=$(SVGs:.svg=.pdf)

TSVs=$(wildcard */*.tsv)
PLTs=$(wildcard */*.plt)
CURVs=$(PLTs:.plt=.pdf)

$(ILLUs): %.pdf: %.svg
	rsvg-convert -f pdf $< -o $@

$(CURVs): %.pdf: %.tsv %.plt
	gnuplot $<

big_smile
Pour la peine, je crois bien que je vais me farcir un petit article de blog sur les bêtises qu'on peut faire avec du LaTeX et du Makefile, un de ces jours. Depuis le temps, j'ai trouvé plein de bricoles chouettes à raconter ^^


(1) D'autant que, je simplifie, vu que j'ai aussi des fichus administratifs qui réclament que j'intègre certaines pages dans le manuscrit, en insistant beaucoup sur le fait que ça doit respecter précisément les dispositions, tailles et polices de leurs documents de référence, mais ne sont fichus de fournir lesdits documents de référence qu'en .doc(x)…
D'ailleurs, si quelqu'un connaît une commande pour convertir ce genre de trucs (enfin, leur reconversion en OpenDocument, 'faut pas exagérer) en PDFs, ça pourrait m'éviter d'avoir à lancer LibreOffice pour faire un export manuel…

Dernière modification par Elzen (Le 25/04/2016, à 17:56)

Hors ligne

#17 Le 25/04/2016, à 19:50

vv221

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

Elzen a écrit :

D'ailleurs, si quelqu'un connaît une commande pour convertir ce genre de trucs (enfin, leur reconversion en OpenDocument, 'faut pas exagérer) en PDFs, ça pourrait m'éviter d'avoir à lancer LibreOffice pour faire un export manuel…

unoconv, basé sur les bibliothèques de LibreOffice. Trouvable dans les dépôts de toute bonne distribution tongue
http://dag.wiee.rs/home-made/unoconv/


Jouer sur Ubuntu ? Facile !

Hors ligne

#18 Le 26/04/2016, à 00:23

Oni_Shadow

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

Des nouvelles d'Arpège enfait ? tongue


Travaux sur Unity 8 abandonné ? Pas par tout le monde !
─▶ Travaux sur les téléphones opéré par Ubport
─▶ Travaux sur le DE opéré par l’équipe de Yunit
N’hésitez pas à contribuer, toute aide est la bienvenue :) Premier objectif : passage de Mir à Wayland.

Hors ligne

#19 Le 06/05/2016, à 13:53

grim7reaper

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

Oni_Shadow a écrit :

Des nouvelles d'Arpège enfait ? tongue

Ça avance, très lentement mais ça progresse un peu ^^

Hors ligne

#20 Le 13/05/2016, à 15:01

Elzen

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

Mais si tu as envie de venir donner un coup de main, n'hésite pas tongue

Bon, de mon côté, j'ai codé un premier jet pour ce truc en PyGTK, parce que je voulais faire ça en vitesse et que donc j'ai pris ce à quoi j'étais le plus habitué. Puis j'me suis dit que, quand même, au bout d'un moment, 'faut arrêter les trucs obsolètes, alors j'ai tapé quelques lignes de Python 3/GTK 3, et j'ai lancé.

Donc, j'ai la joie de vous annoncer que le thème GTK 3 sur lequel j'avais passé pas mal de temps il y a quelques mois, et dont j'étais content parce que j'avais enfin réussi à donner une tronche vaguement présentable au truc, ne marche juste plus du tout, et que je vais vraisemblablement encore devoir batailler des lustres avec un truc n'ayant une très vague tronche de CSS juste pour avoir des outils qui ne soient pas uniformément gris.

C'est 'achement encourageant, j'vous jure ><

Hors ligne

#21 Le 13/05/2016, à 19:17

vv221

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

Elzen a écrit :

j'ai la joie de vous annoncer que le thème GTK 3 sur lequel j'avais passé pas mal de temps il y a quelques mois, et dont j'étais content parce que j'avais enfin réussi à donner une tronche vaguement présentable au truc, ne marche juste plus du tout

C’est pour une raison similaire qu’il n’y a pas de GTK 3.20 sur ma Sid tongue


Jouer sur Ubuntu ? Facile !

Hors ligne

#22 Le 14/05/2016, à 00:44

Elzen

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

Ça a l'air d'impacter pléthore de thèmes; c'est un incident spécifique à cette version, ou c'est juste qu'ils ont encore tout cassé ? En tout cas, le thème greybird a l'air de marcher (et sans warnings, en plus), ç'n'est pas franchement mon genre niveau esthétique, mais ça fera l'affaire pour l'instant.

Sinon, histoire de poster un peu de code sympa. Fichier padimport.py :

#! /usr/bin/env python2
# coding: Utf-8

import os, sys, urllib

f = urllib.urlopen(sys.argv[1]+"/export/txt")
pcode = f.read()
f.close()

if os.path.exists(sys.argv[2]):
    f = open(sys.argv[2], "r")
    fcode = f.read()
    f.close()
else: fcode = ""

if fcode != pcode:
    f = open(sys.argv[2], "w")
    f.write(pcode)
    f.close()

(Oui, je sais, python2, mais la lecture du pad en python3 me renvoie un objet bytes dont j'ai la flemme de chercher maintenant comment convertir proprement)

Associez à ça le Makefile suivant:

all: slides.pdf

slides.pdf: slides.tex
	xelatex slides.tex
	xelatex slides.tex

slides.tex: pad
	python padimport.py http://URL_DU_PAD $@

.PHONY: pad

(Bon, c'est du LaTeX, donc il faut aussi ajouter le clean qui va bien pour virer la tonne de fichiers de génération moches)

Et paf !, vous pouvez rédiger des slides à plusieurs, par exemple, et la compilation ne sera effectivement relancée que si quelqu'un a touché au pad depuis la dernière fois. Si on ajoute à ça un répertoire partagé montable par FUSE pour déposer les images, ça permet l'édition de slides totalement collaborative en temps réel \o/

Hors ligne

#23 Le 17/05/2016, à 13:17

The Uploader

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

Greybird c'est l'excellent thème phare du Shimmer Project, utilisé par Xubuntu depuis très longtemps.

Si tu veux un thème constamment à jour et qui est beau -> Hop ! Greybird (le seul, l'unique !) et c'est réglé.

(Vivement que GTK soit abandonné et que le code source de GTK atterrisse dans un seul et unique disque dur qui finira sa vie dans un incendie explosif ! tongue )

Dernière modification par The Uploader (Le 17/05/2016, à 13:19)


- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4200, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster AWE64, 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

#24 Le 17/05/2016, à 16:53

Elzen

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

*signale le message précédent comme spam*

Dites, les gens, j'ai un soucis que je ne pige pas avec GTK3.

#! /usr/bin/env python3
# coding: Utf-8

try:
    import gtk, cairo
    signal = "expose-event"
except ImportError:
    signal = "draw"
    __import__("gi").require_version('Gtk', '3.0')
    from gi.repository import Gtk as gtk, cairo

def _window_repaint(*args):
    cr = win.get_window().cairo_create()
    cr.set_source_rgba(0.0, 1.0, 0.0, 1.0)
    cr.set_operator(cairo.OPERATOR_SOURCE)
    cr.paint()

win = gtk.Window()
win.set_app_paintable(True)
win.connect(signal, _window_repaint)
win.connect("destroy", gtk.main_quit)
win.show_all()
gtk.main()

Lancé avec python2 et donc PyGTK, ceci me donne bien une fenêtre qui s'ouvre avec un fond vert.
Lancé avec python3 et donc PyGI, la fenêtre reste noire, et à la fermeture, j'ai ceci qui s'affiche:

TypeError: Couldn't find foreign struct converter for 'cairo.Context'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/gi/overrides/Gtk.py", line 1549, in main_quit
    _Gtk_main_quit()
SystemError: gi.FunctionInfo(main_quit) returned a result with an error set

Ça a le même genre d'effet chez vous ? Vous avez une idée du pourquoi du comment ?

Edit: résolu. En fait, ça a marché à partir du moment où j'ai installé le paquet python-gi-cairo. Il fallait quand même le trouver >< d'autant qu'il existe aussi, notamment, un paquet python-cairo qui, lui, ne change rien au problème oO

Et en fait, la ligne « cr.set_operator(cairo.OPERATOR_SOURCE) » ne fonctionne plus avec la version Python3? Et, je viens de faire le test, le programme marche très bien sans en Python2. J'avais dû copier-coller d'un code trouvé sur le net il y a des lustres et me le traîner pour rien depuis…

Dernière modification par Elzen (Le 18/05/2016, à 02:26)

Hors ligne

#25 Le 18/05/2016, à 08:26

grim7reaper

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

Elzen a écrit :

(Oui, je sais, python2, mais la lecture du pad en python3 me renvoie un objet bytes dont j'ai la flemme de chercher maintenant comment convertir proprement)

Version Python 3

#! /usr/bin/env python3
# coding: utf-8

import os
import urllib.request
import sys

with urllib.request.urlopen(sys.argv[1] + '/export/txt') as pad:
    new = pad.read().decode('utf-8')

try:
    with open(sys.argv[2], 'r', encoding='utf-8') as fp:
        old = fp.read()
except FileNotFoundError:
    old = ''

if new != old:
    with open(sys.argv[2], 'w', encoding='utf-8') as fp:
        fp.write(new)

Trois petites remarques :
- c’est plus propre/sûr d’utiliser "with … as" pour ouvrir les fichier (la fermeture est géré automatiquement, même en cas d‘exception).
- il faut mieux essayer d’ouvrir le fichier et attraper l’exception si souci plutôt que tester l’existence du fichier avant ouverture (risque de race : le fichier eput être supprimé entre la réussite de ton test et l’ouverture du fichier).
- toujours préciser les encodages utilisés (There Ain't No Such Thing As Plain Text).

Bon y’a peu de chance que ça importe dans un script de 25 lignes, mais je le dit quand même tongue



The Uploader a écrit :

(Vivement que GTK soit abandonné et que le code source de GTK atterrisse dans un seul et unique disque dur qui finira sa vie dans un incendie explosif ! tongue )

Ouais, Qt est tellement meilleur avec son préprocesseur/générateur de code maison…
Moi je je dis NCurses rule them all!

Dernière modification par grim7reaper (Le 18/05/2016, à 10:19)

Hors ligne