/* Topic des codeurs couche-tard [3] */

Sir Na Kraïou · Le 24/01/2011, à 23:23

.

gnuuat · Le 24/01/2011, à 23:39

j'ai besoin de conseils en Python...

class Matrix:
    __columns = 0
    __rows = 0
    __matrix = []

    def __init__(self, columns, rows = None):
        """Constructor"""
        self.__columns = int(columns)
        if rows == None:
            rows = columns
        self.__rows = int(rows)
        for i in range(self.__rows):
            row = []
            for j in range(self.__columns):
                row.append(0)
            self.__matrix.append(row)

class MatrixContainer:
    __matrix = []
    def __init__(self, entries):
       self. __matrix = Matrix(len(entries), 1)
        for i in range(entries):
            self.__matrix[i] = entries[i]

if __name__ == '__main__':
    entries_1 = [23, 42, 1337, 4423]
    entries_2 = [46, 84, 2674, 8846, -23, -42, -1337, -4423]
    container_1 = MatrixContainer(entries_1)
    container_2 = MatrixContainer(entries_2)

J'ai un code dans le genre qui est assez long, et apperement Python n'apprécie pas que je réutilise MAtrixContainer() pour créer de nouvelles variables... Il me réutilise la première instanciation et plante lamentablement...

tshirtman · Le 24/01/2011, à 23:55

les variables que tu déclare dans le namespace de la classe sont communes à toutes les instances de la classes, je ne me sert jamais de ça (sauf pour les singletons ou trucs de ce genre, ou une classe dont les instances ont des numéros par exemple, il te faut un compteur) donc utilise self.__matrix dans ton initialisation, et ne déclare pas de class.__matrix au dessus je dirait…

sauf si j'ai mal compris ce que tu veux faire bien sur…

gnuuat · Le 25/01/2011, à 00:01

Ok, c'est vrai que depuis le C, j'ai tendance à vouloir mettre des variables avant le __init__...
D'ailleurs il me semblait avoir vu une classe permettant de construire l'objet (et de le détruire : __del__() ).
Je vais essayer dès demain .

Rolinh · Le 25/01/2011, à 00:10

.

grim7reaper · Le 25/01/2011, à 00:12

#define LATSIZ 11        /* Taille du champ latitude. */
#define LONSIZ 12        /* Taille du champ longitude. */

#define LATPOS 18        /* Position du champ latitude. */
#define LONPOS 29        /* Position du champ longitude. */

char buff1[LATSIZ + 1];  /* Latitude. */
char buff2[LONSIZ + 1];  /* Longitude. */
unsigned short pos;      /* Position dans la trame. */
char car;                /* Caractere courant. */
char bad_trame;          /* Flag : 1 si la trame est mauvaise, sinon 0. */
char EOT;                /* End Of Trame. */

void main()
{
    /* Initialisation des flags. */
    bad_trame = 1;
    EOT = 0;

    /* Initialisation du LCD. */
    Lcd_Config(&PORTB, 4, 5, 6, 3, 2, 1, 0);
    Lcd_Cmd(LCD_CLEAR);
    Lcd_Cmd(LCD_CURSOR_OFF);

    /* Initialisation du port serie.
    * 8 bit, 4800 baud rate, pas de bit de parite... */
    USART_init(4800);

    while(1)
    {
        if(USART_Data_Ready())
        {
            car = (char)USART_Read();
            /* Debut de trame */
            if(car == '$')        
            {
                pos = 1;
                bad_trame = 0;
            }
            else if(!bad_trame)
            {
                switch(pos)
                {
                    case 3:
                        bad_trame = (car != 'R');
                        pos++;
                        break;
                    case 17:
                        bad_trame = (car != 'A');
                        pos++;
                        break;
                    case LATPOS:
                        while(pos < LATPOS + LATSIZ)
                        {
                            if(USART_Data_Ready())
                            {
                                buff1[pos-LATPOS] = (char)USART_Read();
                                pos++;
                            }
                        }
                        buff1[LATSIZ] = '\0';
                        break;
                    case LONPOS:
                        while(pos < LONPOS + LONSIZ)
                        {
                            if(USART_Data_Ready())
                            {
                                buff2[pos-LONPOS] = (char)USART_Read();
                                pos++;
                            }
                        }
                        buff2[LONSIZ] = '\0';
                        EOT = 1;
                        break;
                    default:
                        pos++;
                        break;
                }
            }
        }
        if(EOT)
        {
            EOT = 0;
            LCD_Cmd(LCD_CLEAR);
            LCD_Cmd(LCD_CURSOR_OFF);
            /* LCD_Out(row, columns, text) */
            LCD_Out(1, 1, buff1);
            LCD_Out(2, 1, buff2);
        }
    }
}

It Works !
Bon c'est pas le code le plus élégant que j'ai fait (mais bon, les conditions sont un peu particulière là aussi…), mais il fonctionne (il récupère bien les morceaux voulu de certaines trames fourni par la puce GPS). Bon, par contre faudra que j'ajoute quelques commentaires…
Je suis paré pour le TP de demain
Pour le void main() et les globales, je rappelle, à toutes fins utiles , que c'est plus ou moins normal.

Sinon, pour le CLFB aussi j'ai bien bossé ce soir :
- lecture du fichier de conf' => OK
- reconnaissance du type mime => OK
- lancement du programme qui va bien (je gère plusieurs programme pour un type donné ) => quasi-OK, juste un petit problème au niveau du passage des options au programme appelé (dans certains cas seulement, mais je crois avoir localisé le problème)..

Sur ce, BN World !

tshirtman · Le 25/01/2011, à 00:22

@gnuuat: ben si tu définit __del__ il sera appelé l'hors de la destruction de l'objet, ça marche toujours , bon en python, tu es pas toujours sur qu'il sera détruit un jour, si tu référence tes objets un peu dans tous les sens, faut être un peu rigoureux (dans USF c'est juste pas terrible de ce coté là)

bonne nuit

kamui57 · Le 25/01/2011, à 00:30

bn

Pylades · Le 25/01/2011, à 03:03

Plop sans code (à part Xkb).

cm-t · Le 25/01/2011, à 03:03

'Nuit;

samυncle · Le 25/01/2011, à 04:04

.

Compteur du TdCCT · Le 25/01/2011, à 07:42

Scores totaux, depuis le début :

1) 2401    nesthib
2) 2273    samuncle
3) 1944    Pylade
4) 1559    Кຼزດ
5) 1184+5  grim7reaper /* ./viewtopic.php?pid=3486252#p3486252 */
6) 1130    cm-t
7) 799    Р☢w ! ✰ :mad: ✰ (эй !)
8) 790    helly
9) 783    \\Ouranos//
10) 626    gnuuat
11) 538    Lagierl
12) 388    tshirtman
13) 196    Askelon
14) 189    Kanor
15) 187    Rolinh
16) 172    nathéo
17) 154    The Uploader
18) 121    ǤƦƯƝƬ
19) 93    petifrancais
20) 78    edge_one
20) 78    pierguiard
22) 74    kamui57
23) 70    gulp
24) 39    Le Rouge
25) 37    ilagas
26) 30    keny
27) 25    GentooUser
27) 25    Morgiver
27) 25    xapantu
30) 24    ไ୦บเઢ'
30) 24    Steap
32) 21    :!pakman
33) 20    CROWD
33) 20    d10g3n
35) 18    Ph3nix_
36) 15    timsy
37) 14    kouskous
38) 12    stratoboy
38) 12    sailing
38) 12    sakul
41) 11    alexises
41) 11    Crocoii
43) 10    Toineo
43) 10    NutMotion
43) 10    pseudovingtcinqcaracteres
43) 10    pfriedZ
43) 10    CasseTaTele
48) 8    Mornagest
49) 7    Vista
50) 6    Zeibux
50) 6    ubuntlin
50) 6    asma.geek
53) 5    tendances-tdct
53) 5    kinouchou
53) 5    gustare
56) 4    danychou56
56) 4    Neros
56) 4    Biaise
56) 4    totoflute
56) 4    pinballyoda ㋛
61) 3    Revan26914
62) 2    SoJaS
62) 2    ceric
64) 1    geenux

Répartition Posts/heure

Compteur du TdCCT · Le 25/01/2011, à 07:42

Scores de la période en cours :

1) 208    samuncle
2) 200    nesthib
3) 172    Pylade
4) 144    Кຼزດ
5) 135    grim7reaper
6) 106    Rolinh
7) 94    gnuuat
8) 82    cm-t
9) 67    Р☢w ! ✰ :mad: ✰ (эй !)
10) 61    The Uploader
11) 49    helly
12) 40    tshirtman
13) 21    :!pakman
14) 20    Lagierl
15) 15    \\Ouranos//
15) 15    kamui57
17) 10    CasseTaTele
18) 7    Le Rouge
19) 5    gustare
20) 4    Kanor
21) 3    Steap
21) 3    xapantu

gnuuat · Le 25/01/2011, à 10:46

@tshirtman : merci !
Apparemment, les objets en python ont des attributs dynamiques (on peut en rajouter à la volée)...
Les définir en dehors d'une méthode, c'est rendre l'objet statique .

pour __del__, ça permet de dire au garbage collector que tu n'utilisera plus l'objet (avec del), et donc qu'il pourra le virer quand il lui plaira.

Edit !
Par contre que penses tu de ça :

class MyObject:
    def __init__(self):
        """Initialisator"""
        self.__myList = []
    def __del__(self):
        """Destructor"""
        del self.__myList
        self.__myList = None

le __del__ fait implicitement appel à del des attributs...Du coup je ne sais pas si c'est si utile que ça ?
Et les mettre à None après un del... C'est bien en Python ?

Dernière modification par gnuuat (Le 25/01/2011, à 10:55)

tshirtman · Le 25/01/2011, à 11:31

je faisait ça à une époque, mais en fait tu fais juste la même chose que ce que feras l'interpréteur si tu fais un del() sur ta dernière référence à l'objet, ou que tu réassigne la dernière variable le référençant...

il faut utiliser __del__ seulement si tu as des traitements spéciaux à faire (fermeture d'une base sql, sauvegarde dans un fichier, log de la disparition de l'objet...)

pour assigner None je pense que ça sert à rien là.

Et oui en python les attributs sont dynamiques, si tu veux des attributs statiques (et optimisés) tu peux utiliser les slots, mais je ne crois pas que tu puisse interdire l'ajout d'autres attributs plus tard (même depuis l'extérieur de ta classe).

Кຼزດ · Le 25/01/2011, à 23:26

tshirtman a écrit :

Et oui en python les attributs sont dynamiques, si tu veux des attributs statiques (et optimisés) tu peux utiliser les slots, mais je ne crois pas que tu puisse interdire l'ajout d'autres attributs plus tard (même depuis l'extérieur de ta classe).

J'avais lu un truc qui permettait d'utiliser les slots de manière dynamique (et donc de profiter des optimisations moins presque tous les inconvénients).

grim7reaper · Le 25/01/2011, à 23:27

Hello World !

/me a écrit :

- lancement du programme qui va bien (je gère plusieurs programme pour un type donné ) => quasi-OK, juste un petit problème au niveau du passage des options au programme appelé (dans certains cas seulement, mais je crois avoir localisé le problème)..

Done.
Finalement, c'était un peu plus complexe (et chiant du coup) que prévu, mais maintenant ça me semble OK.
Sinon, je pense (j'espère) avoir atteint une forme stable pour ma REPL dans le CLFB donc je la poste (c'est peut-être mon premier bout de code qui restera inchangé jusqu'a la version finale \o/… ou pas.)

repl :: Bool -> Magic -> Config -> InputT IO ()
repl v db conf = do dir <- liftIO $ currentDir
                    maybeInput <- getInputLine $ prompt dir
                    case maybeInput of
                         Nothing   -> return () -- EOF (generally Ctrl+D)
                         Just line -> do cmd <- liftIO $ decodeCmd (getUserArgs line) db conf
                                         case cmd of
                                               -- No Operation
                                              [NOP msg]  -> showAndLoop (NOP msg)
                                              -- Internal commands
                                              [Quit]     -> outputStrLn $ show Quit
                                              [Verbose]  -> showAndLoop Verbose
                                              [Warranty] -> showAndLoop Warranty
                                              [Copying]  -> showAndLoop Copying
                                              [Help]     -> showAndLoop Help
                                              -- Shell commands
                                              _ -> do if v
                                                         then mapM_ (outputStrLn.show) cmd
                                                         else return ()
                                                      liftIO $ execCmd cmd
                                                      repl v db conf

En ce qui concerne mes histoires de GPS, j'ai pas mal avancé : stockage et relecture des trames en mémoire (l'EEPROM du PIC, communication série) opérationnelles.
Enfin, « des » c'est un bien grand mot, j'en cale que 12 en fait (mémoire de 256 octets inside) . J'aurais pu monter à 13 en modifiant un peu mon format de stockage mais bon ça faisait pas mal de code en plus pour un gain relativement faible (1 octet/trame).

Par contre, quand je suis passé sur une mémoire externe (toujours une EEPROM, mais protocole I²C cette fois), bah la lecture et/ou l'écriture foire (seule les 4-5 premières trames sont lisible). Sûrement un problème de délai (jdois un peu trop bombarber la mémoire ^^, faut que je regarde les chronogrammes de la doc plus attentivement…)

Dernière modification par grim7reaper (Le 26/01/2011, à 02:17)

Sir Na Kraïou · Le 26/01/2011, à 00:02

·.·

gnuuat · Le 26/01/2011, à 00:22

Р☢w ! ✰

✰ (эй !) a écrit :

·.·

·)

grim7reaper · Le 26/01/2011, à 00:32

Alessandro Rubini a écrit :

I would like to thank the people that made this work possible. First of all, the incredible patience of Federica, who went as far as letting me review the first edition during our honeymoon, with a laptop in the tent.

Ha ouais quand même ^^

Dernière modification par grim7reaper (Le 26/01/2011, à 04:46)

The Uploader · Le 26/01/2011, à 00:33

oh le geek!

Il avait pas peur pour son mariage...

BN;

Dernière modification par The Uploader (Le 26/01/2011, à 00:34)

Pylades · Le 26/01/2011, à 01:10

:]

cm-t · Le 26/01/2011, à 01:12

'Nuit;

gnuuat · Le 26/01/2011, à 01:28

#!/usr/bin/env python
from future import past

print(past('present'))

nesthib · Le 26/01/2011, à 03:24

plop

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1526 Le 24/01/2011, à 23:23

Re : /* Topic des codeurs couche-tard [3] */

#1527 Le 24/01/2011, à 23:39

Re : /* Topic des codeurs couche-tard [3] */

#1528 Le 24/01/2011, à 23:55

Re : /* Topic des codeurs couche-tard [3] */

#1529 Le 25/01/2011, à 00:01

Re : /* Topic des codeurs couche-tard [3] */

#1530 Le 25/01/2011, à 00:10

Re : /* Topic des codeurs couche-tard [3] */

#1531 Le 25/01/2011, à 00:12

Re : /* Topic des codeurs couche-tard [3] */

#1532 Le 25/01/2011, à 00:22

Re : /* Topic des codeurs couche-tard [3] */

#1533 Le 25/01/2011, à 00:30

Re : /* Topic des codeurs couche-tard [3] */

#1534 Le 25/01/2011, à 03:03

Re : /* Topic des codeurs couche-tard [3] */

#1535 Le 25/01/2011, à 03:03

Re : /* Topic des codeurs couche-tard [3] */

#1536 Le 25/01/2011, à 04:04

Re : /* Topic des codeurs couche-tard [3] */

#1537 Le 25/01/2011, à 07:42

Re : /* Topic des codeurs couche-tard [3] */

#1538 Le 25/01/2011, à 07:42

Re : /* Topic des codeurs couche-tard [3] */

#1539 Le 25/01/2011, à 10:46

Re : /* Topic des codeurs couche-tard [3] */

#1540 Le 25/01/2011, à 11:31

Re : /* Topic des codeurs couche-tard [3] */

#1541 Le 25/01/2011, à 23:26

Re : /* Topic des codeurs couche-tard [3] */

#1542 Le 25/01/2011, à 23:27

Re : /* Topic des codeurs couche-tard [3] */

#1543 Le 26/01/2011, à 00:02

Re : /* Topic des codeurs couche-tard [3] */

#1544 Le 26/01/2011, à 00:22

Re : /* Topic des codeurs couche-tard [3] */

#1545 Le 26/01/2011, à 00:32

Re : /* Topic des codeurs couche-tard [3] */

#1546 Le 26/01/2011, à 00:33

Re : /* Topic des codeurs couche-tard [3] */

#1547 Le 26/01/2011, à 01:10

Re : /* Topic des codeurs couche-tard [3] */

#1548 Le 26/01/2011, à 01:12

Re : /* Topic des codeurs couche-tard [3] */

#1549 Le 26/01/2011, à 01:28

Re : /* Topic des codeurs couche-tard [3] */

#1550 Le 26/01/2011, à 03:24

Re : /* Topic des codeurs couche-tard [3] */

Pied de page des forums