/* Topic des codeurs [7] */

tshirtman · Le 24/10/2012, à 11:01

Mindiell a écrit :

tshirtman a écrit :
Kivy est vraiment un bon choix pour faire du dev mobile, à condition que les quelques contraintes ne soient pas un soucis pour toi, les contraintes
Tu parles pas mal d'android, ça marche bien aussi sur iOS ?
Tu fais comment les tests sur ta machine ?
Comment ça on est pas sur le forum du support de Kivy ?

oui, ça marche aussi sur ios, j'ai juste pas de device pour ça, et comme tout dev iOS, il faut un mac et une licence iOS dev (100€/ans) pour avoir le droit de développer, kivy ne change rien à ça, on est obligé de passer par xcode pour compiler.

Pour les tests sur ma machine, je lance mon programme kivy, comme n'importe quel programme, j'utilise la souris au lieu de mes doigts, et si besoin, j'utilise l'émulation multitouch intégré au touch provider "mouse", qui est tout simple, si tu fait un clic droit, il considère que le doigt reste posé quand tu relache le clic, et il laisse un petit rond rouge comme repère, qu'il supprime quand tu refait un clic gauche dessus.

Pour la completion python, et tout le reste d'ailleurs, je trouve que Eclipse est vraiment bien foutu et intègre plein de choses. Je sias que certains pourraient hurler, mais un IDE libre aussi bien foutu c'est agréable (même s'il est lourd).

j'ai jamais réussis à le supporter, certes, il propose énormément d'aide, mais c'est vraiment une machine de guerre quoi… enfin bon, quand je vois ma config vim, je peut pas prétendre que ce soit plus facile à utiliser qu'eclipse, c'est juste que c'est mes choix…

:!pakman · Le 24/10/2012, à 12:06

C'est la guerre entre un pote et moi, lui c'est Vim jusqu'à la mort, moi c'est Eclipse forever
Il a installé le plugin Vim dans Eclipse (on doit savoir s'en servir), et ça c'est classe

Dernière modification par :!pakman (Le 24/10/2012, à 12:07)

The Uploader · Le 24/10/2012, à 12:14

Vim. What else ?

Les machines de guerre style Eclipse, Visual Studio, et Rubymine, j'en suis revenu. Y'a parfois des côtés sympas, mais y'a trop de problèmes qui vont avec...

nathéo · Le 24/10/2012, à 13:03

Emacs !

:!pakman · Le 24/10/2012, à 13:17

nathéo a écrit :

Emacs !

Tirez dessus !

nathéo · Le 24/10/2012, à 16:10

Vim est un éditeur de sous évolués.

Dernière modification par nathéo (Le 24/10/2012, à 16:18)

Pylades · Le 24/10/2012, à 16:22

Nan mais on se calme, les enfants !

sweetly · Le 24/10/2012, à 17:01

Le Rouge a écrit :

sweetly : parce que les problèmes viennent plus souvent d'un mauvais algorithme que d'une faute de frappe (code plus court et plus simple en théorie) ?
J'en sais rien hein, c'est juste une théorie qui vient de me venir à l'esprit ^^

J'avais zappé ça. (je posais la question pourquoi les crash étaient plus fréquents en récursif, selon nathéo). Je dirais, surtout au niveau des étudiants débutants que c'est la façon de penser récursive qui pose problème. Mais idem, juste une théorie.

tshirtman · Le 24/10/2012, à 17:09

http://ergoemacs.org/emacs/emacs_hand_p … brity.html

The Uploader · Le 24/10/2012, à 17:22

Ça fait peur...

nathéo · Le 24/10/2012, à 17:50

tshirtman a écrit :

http://ergoemacs.org/emacs/emacs_hand_p … brity.html

Michael Tiemann a écrit :

But the root cause was not Emacs—it was the punative design of the QWERTY keyboard, a legacy of the industrial era when complex keyboard mechanisms were not able to keep up with the speed of human fingers. …

sweetly · Le 24/10/2012, à 18:02

nathéo a écrit :

tshirtman a écrit :
http://ergoemacs.org/emacs/emacs_hand_p … brity.html
Michael Tiemann a écrit :
But the root cause was not Emacs—it was the punative design of the QWERTY keyboard, a legacy of the industrial era when complex keyboard mechanisms were not able to keep up with the speed of human fingers. …

Sachant que son développeur originel s'est usé les mains jusqu'à risquer de ne plus programmer en l'utilisant, on peut en conclure qu'Emacs est bel et bien fait en dépit du bon sens. Une sorte de logiciel masochiste. M'étonne pas, tiens.

tshirtman · Le 24/10/2012, à 18:02

Alors pourquoi les utilisateurs de vi/vim sont ils moins touchés?

grim7reaper · Le 24/10/2012, à 18:07

tshirtman a écrit :

Alors pourquoi les utilisateurs de vi/vim sont ils moins touchés?

Source ?
C’est pas parce qu’il n’y a pas un site web ergovim.org que les utilisateurs de Vim ne sont pas sujet aux RSI.
Franchement, tu trouves 10 gus qui ont utilisés emacs et qui on des RSI et tu en conclus que emacs implique des RSI. Pas très scientifique comme raisonnement, et pas solide (niveau stat’, la taille de l’échantillon est plus que foireux).

The Uploader · Le 24/10/2012, à 18:12

a-programmers-guide-to-healing-rsi

Dernière modification par The Uploader (Le 24/10/2012, à 18:12)

HP · Le 24/10/2012, à 18:14

nathéo a écrit :

Emacs !

+1

tshirtman · Le 24/10/2012, à 19:52

grim7reaper a écrit :

tshirtman a écrit :
Alors pourquoi les utilisateurs de vi/vim sont ils moins touchés?
Source ?
C’est pas parce qu’il n’y a pas un site web ergovim.org que les utilisateurs de Vim ne sont pas sujet aux RSI.
Franchement, tu trouves 10 gus qui ont utilisés emacs et qui on des RSI et tu en conclus que emacs implique des RSI. Pas très scientifique comme raisonnement, et pas solide (niveau stat’, la taille de l’échantillon est plus que foireux).

Bon, non, je n'ai pas de source, c'est plus une observation non scientifique, qui montre que les plus gros utilisateurs d'emacs, sont très sujet aux rsi, et on a pas (à ma connaissance) de telles observation chez les gros utilisateurs de vi/vim… mais oui, c'est pas scientifique.

Cela dit, il y a beaucoup d'utilisateurs d'emacs et de vim dans le monde, donc y'a de quoi faire des études statistiques importantes je pense…

grim7reaper · Le 24/10/2012, à 20:21

tshirtman a écrit :

grim7reaper a écrit :
tshirtman a écrit :
Alors pourquoi les utilisateurs de vi/vim sont ils moins touchés?
Source ?
C’est pas parce qu’il n’y a pas un site web ergovim.org que les utilisateurs de Vim ne sont pas sujet aux RSI.
Franchement, tu trouves 10 gus qui ont utilisés emacs et qui on des RSI et tu en conclus que emacs implique des RSI. Pas très scientifique comme raisonnement, et pas solide (niveau stat’, la taille de l’échantillon est plus que foireux).
Bon, non, je n'ai pas de source, c'est plus une observation non scientifique, qui montre que les plus gros utilisateurs d'emacs, sont très sujet aux rsi, et on a pas (à ma connaissance) de telles observation chez les gros utilisateurs de vi/vim… mais oui, c'est pas scientifique.

[troll]Peut-être parce qu’il n’existe pas de gros utilisateurs de Vim [/troll]

tshirtman a écrit :

Cela dit, il y a beaucoup d'utilisateurs d'emacs et de vim dans le monde, donc y'a de quoi faire des études statistiques importantes je pense…

Oui, et il y en a même qui utilise les deux (comme moi, bien que je sois majoritairement sur Emacs maintenant).

Sinon CMake c’est cool, mais SCons c’est vraiment bien aussi.
Là je bidouille du Java, et CMake ne gère pas Java donc j’ai jeté un œil à SCons. Et ma foi c’est plutôt pas mal foutu (mais je resterais sur CMake pour le C, le C++ et le Fortran (quoique pour celui là, à voir)).
Un exemple de fichier SConstruct que je viens de me faire :

from glob import glob

env = Environment()
env.Append(JAVACFLAGS = ['-cp', ':'.join(glob('lib/*.jar'))])
env.Append(JARCHDIR = ['bin'])
env.Java(target = 'bin', source = 'src')
env.Jar(target = 'JavaUtils.jar', source = 'bin')

Elzen · Le 24/10/2012, à 20:54

Le Rouge a écrit :

ArkSeth a écrit :
[un truc] pourrait assez bien matcher le cahier des charges
Tu t'es cru à une réunion powerpoint avec des commerciaux ?

Je ne vois pas, mais alors, pas du tout, le rapport entre ce que je viens de dire et des commerciaux et/ou un logiciel/format privatif

Sinon, en l'absence d'autres suggestions et vu que le truc me plaît bien, j'pense partir sur le jeu

The Uploader · Le 24/10/2012, à 20:55

Encore un clone de UFO : Enemy Unknown libre (en plus de UFO : AI, et du jeu en réseau UFO2000), mais qui a besoin, comme UFO2000, des données du jeu DOS de 1993 : OpenXCom.

C'est en C++, le code a l'air assez propre, et y'a même ce qu'il faut pour le compiler avec CMake (on dirait, en tout cas).

Dernière modification par The Uploader (Le 24/10/2012, à 21:02)

The Uploader · Le 25/10/2012, à 12:53

Mike Massonnet a écrit :

xfce4-vala 4.10.2 is now available for download from

http://archive.xfce.org/src/bindings/xf … .2.tar.bz2
http://archive.xfce.org/src/bindings/xf … ar.bz2.md5
http://archive.xfce.org/src/bindings/xf … r.bz2.sha1
SHA1 checksum: c4558d5761d9150f3d5b79ffd1b1f8a6f751095f
MD5 checksum: afcca7cb5ae84b9a9a621a352eaf59c4

What is xfce4-vala?
===================
Xfce4 Vala provides bindings for the Xfce framework.
Vala is a new programming language that aims to bring modern programming
language features to GNOME developers without imposing any additional
runtime requirements and without using a different ABI compared to
applications and libraries written in C.
http://wiki.xfce.org/vala-bindings
Website:
http://goodies.xfce.org/projects/bindings/start

Release notes for 4.10.2
========================
Added garcon (package, VAPI, and test program).
Updated API to Xfce 4.10.0.
Updated package to Vala 0.16.

Ça me donne vraiment envie de m'y remettre.

Dernière modification par The Uploader (Le 25/10/2012, à 12:54)

nathéo · Le 25/10/2012, à 15:28

Yo. Je repasse dans le coin car j'ai besoin de quelques petites explications sur les listes chainées : donc là j'ai à faire une fonction my_params_in_list qui crée une nouvelle liste en y mettant les paramètres de la ligne de commande. Devant être prototypée de cette manière :

t_list *my_params_in_list(int ac, char **av);

Mais je ne pense pas assez maîtriser les structure pour définir un type qui inclue une fonction, alors serait-il possible de m'éclairer sur le sujet s'il vous plait ?

:!pakman · Le 25/10/2012, à 15:58

nathéo a écrit :

Yo. Je repasse dans le coin car j'ai besoin de quelques petites explications sur les listes chainées : donc là j'ai à faire une fonction my_params_in_list qui crée une nouvelle liste en y mettant les paramètres de la ligne de commande. Devant être prototypée de cette manière :
t_list *my_params_in_list(int ac, char **av);
Mais je ne pense pas assez maîtriser les structure pour définir un type qui inclue une fonction, alors serait-il possible de m'éclairer sur le sujet s'il vous plait ?

Je crois qu'en C tu peux placer des fonctions à l’intérieur des structures, enfin, sans doute à l'aide de pointeurs sur fonctions.
Il me semble que le code de la fonction en elle-même n'est pas présente dans la structure, ça évite sans doute de créer x fonctions qui font toutes le même boulot.
grim pourrait sans doute nous éclairer

Faudrait que je me remette au C, sérieusement (nous on à fait les structures, mais en Java, c'est pas le même niveau )

Dernière modification par :!pakman (Le 25/10/2012, à 16:01)

nathéo · Le 25/10/2012, à 16:11

Du coup ça voudrait dire qu'on ne définit que le prototype de la fonction dans la structure ? Et que par conséquent toutes les variables ou autre qui seront utilisées dans la fonction (enfin je veux dire pour l'écriture de la fonction) devront provenir de la structure ?

Enfin concernant le fait de mettre les paramètres entrés en ligne de commande dans la fonction, je pense que je peux déjà le faire en utiliser argv, argc et une petite boucle. Pour ensuite l'assigner à la liste, je pense aussi pour y arriver en définissant la valeur des variables de la structure (avec quelque chose du type t_list->av = av[i] pour i étant inférieur ou égal à la valeur de argc et t_list->ac = ac) sachant que dans le main ac sera remplacé par argc et av par argv.

Mais voilà, le truc de la fonction inclu dans la définition du type, pour le moment ça ne passe pas pour moi...

Pour le moment ma structure ressemble à ça :

#ifdef LIST_H_
#define LIST_H_

struct t_list;
{
  char param;
  int ac;

  struct t_list *next;
};

t_list *my_params_in_list(int ac, char **av);

#endif

Dernière modification par nathéo (Le 25/10/2012, à 16:46)

grim7reaper · Le 25/10/2012, à 18:06

nathéo a écrit :

Mais je ne pense pas assez maîtriser les structure pour définir un type qui inclue une fonction, alors serait-il possible de m'éclairer sur le sujet s'il vous plait ?

Mais pourquoi tu veux mettre la fonction DANS la structure ?
Ça marche très bien sans faire ça…
Du genre :

#ifndef H_LIST_LS_20121025175105
#define H_LIST_LS_20121025175105

struct list_s
{
    char* av;
    int ac;
    struct list_s* next;
};

struct list_s* my_params_in_list(int ac, char* av[]);

#endif /* H_LIST_LS_20121025175105 */

et l’implémentation qui va avec :

#include <stdlib.h>
#include <stdio.h>

#include "natheo.h"

int main(int argc, char* argv[])
{
    struct list_s* param = my_params_in_list(argc, argv);

    while(param != NULL)
    {
        puts(param->av);
        param = param->next;
    }

    return 0;
}

struct list_s* my_params_in_list(int ac, char* av[])
{
    int i;
    struct list_s* head = NULL;
    for(i = ac; i > 0; --i)
    {
        struct list_s* node = malloc(sizeof *node);
        node->ac = i;
        node->av = av[i - 1];
        node->next = head;
        head = node;
    }

    return head;
}

Bon c’est un truc crade à la va-vite (mais comme c’est comme ça que vous apprenez à coder, j’allais pas trop me cassez le cul non plus hein :]).
Dans du vrai code j’aurais fait une structure plus propre, créé une fonction add ou append, etc., gérer les erreurs d’allocations et libérer la mémoire.

:!pakman a écrit :

Je crois qu'en C tu peux placer des fonctions à l’intérieur des structures, enfin, sans doute à l'aide de pointeurs sur fonctions.

Toutafé.

!pakman a écrit :

Il me semble que le code de la fonction en elle-même n'est pas présente dans la structure, ça évite sans doute de créer x fonctions qui font toutes le même boulot.
grim pourrait sans doute nous éclairer

Ouais possible, je t’avouerais que je ne connais pas la raison réelle (mais ce que tu dis semble pas idiot), c’est peut-être explicité dans la norme.

Dernière modification par grim7reaper (Le 25/10/2012, à 18:07)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#2276 Le 24/10/2012, à 11:01

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

#2277 Le 24/10/2012, à 12:06

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

#2278 Le 24/10/2012, à 12:14

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

#2279 Le 24/10/2012, à 13:03

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

#2280 Le 24/10/2012, à 13:17

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

#2281 Le 24/10/2012, à 16:10

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

#2282 Le 24/10/2012, à 16:22

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

#2283 Le 24/10/2012, à 17:01

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

#2284 Le 24/10/2012, à 17:09

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

#2285 Le 24/10/2012, à 17:22

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

#2286 Le 24/10/2012, à 17:50

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

#2287 Le 24/10/2012, à 18:02

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

#2288 Le 24/10/2012, à 18:02

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

#2289 Le 24/10/2012, à 18:07

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

#2290 Le 24/10/2012, à 18:12

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

#2291 Le 24/10/2012, à 18:14

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

#2292 Le 24/10/2012, à 19:52

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

#2293 Le 24/10/2012, à 20:21

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

#2294 Le 24/10/2012, à 20:54

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

#2295 Le 24/10/2012, à 20:55

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

#2296 Le 25/10/2012, à 12:53

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

#2297 Le 25/10/2012, à 15:28

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

#2298 Le 25/10/2012, à 15:58

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

#2299 Le 25/10/2012, à 16:11

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

#2300 Le 25/10/2012, à 18:06

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

Pied de page des forums