/* Topic des codeurs [6] */

tshirtman · Le 29/09/2011, à 19:30

tout ça pour un fizzbuzz oO

grim7reaper · Le 29/09/2011, à 19:38

Rolinh a écrit :

@grim: c'est juste que j'ai implémenté un thread pour la copie de manière complètement barbare juste pour voir si ça fonctionnait mais ça ne me libérait pas la GUI quand même.

C’est normal que la GUI ne reprenne pas la main : à la fin de on_apply_clicked tu fais un pthread_join donc tu attends la fin du thread (donc on_apply_clicked ne se termine pas tant que ton thread n’est pas fini => c’est comme si t’avais rien fait).

Je ne connais pas tes besoins, mais peut-être que pthread_detach (au lieu de pthread_join) serait plus adapté à ton cas ?

Dernière modification par grim7reaper (Le 29/09/2011, à 19:40)

The Uploader · Le 29/09/2011, à 20:14

tshirtman a écrit :

tout ça pour un fizzbuzz oO

Un premier kata de TDD/Agile utilisant FizzBuzz.

Le FizzBuzz en lui même ne fait que 11 lignes:

class FizzBuzzer
    def fizzbuzz
        hfb = {}
        for i in Range.new(1, 100)
            result = i/3 != 0 ? "Fizz" : ""
            result = i/5 != 0 ? result + "Buzz" : result
            hfb.merge! i => result
        end
        return hfb
    end
end

@Rolinh : C'est bien en C ton copieur ? Tu peux regarder du côté du dialogue d'état des opérations sur les fichiers de Thunar pour "asynchroniser" les opérations et la GUI via des threads, si j'ai bien suivi les récents mails sur la ml xfce.

Dernière modification par The Uploader (Le 29/09/2011, à 20:18)

Rolinh · Le 29/09/2011, à 20:42

@grim: merci pour le pthread_detach. Ça à l'air de fonctionner. Il s'agit de proprer ça maintenant.
En revanche, j'ai toujours des soucis avec la progress bar. Pas moyen de la faire fonctionner!

xapantu · Le 29/09/2011, à 21:22

Regarde du côté des fonctions idle pour changer la valeur de ta progressbar à chaque itération de la main loop de gtk... (j'ai pas d'exemple en tête, en Vala, faut juste faire Idle.add( () => { code });, c'est un peu plus compliquer en C, du genre g_idle_add)

The Uploader · Le 29/09/2011, à 21:59

version proprée :

#! /usr/bin/env ruby
require "test/unit"

#    Exercice FizzBuzz :
#    - si x/3 != 0 : Fizz
#    - si x/5 != 0 : Buzz
#    - si les deux : FizzBuzz
#    - si aucun : rien
# Et ce jusqu'à 100

class FizzBuzzer
    def fizzbuzz
        hfb = {}
        for i in Range.new(1, 100)
            result = i/3 != 0 ? "Fizz" : ""
            result = i/5 != 0 ? result + "Buzz" : result
            hfb.merge! i => result
        end
        return hfb
    end
end

class TestMyObject < Test::Unit::TestCase

    def initialize(arg)
        initialize_fizzbuzzer
        super
    end

    def initialize_fizzbuzzer
        @myfizzbuzobj = FizzBuzzer.new
    end

    def test_gives_a_hash_of_one_hundred_pairs
        assert_not_nil @myfizzbuzobj.fizzbuzz
        assert_equal Hash, @myfizzbuzobj.fizzbuzz.class
        assert_equal 100, @myfizzbuzobj.fizzbuzz.size
    end

    def test_is_fizzbuzz
        hfb = @myfizzbuzobj.fizzbuzz
        for i in Range.new(1, 100)
            assert_not_nil hfb[i]
            assert_equal "Fizz", hfb[i] if i/3 != 0 and i/5 == 0
            assert_equal "Buzz", hfb[i] if i/3 == 0 and i/5 != 0
            assert_equal "FizzBuzz", hfb[i] if i/3 != 0 and i/5 != 0
            assert_equal "", hfb[i] if i/3 == 0 and i/5 == 0
        end
    end
end

Rolinh · Le 29/09/2011, à 22:41

@grim: ça à l'air de fonctionner comme on le voulait maintenant. On a tâcher de faire ça propre mais si tu vois un oubli n'hésite pas hein

@xapantu: merci. Je regarderais de ce côté.

Dernière modification par Rolinh (Le 29/09/2011, à 22:42)

grim7reaper · Le 29/09/2011, à 22:43

De rien
J’essaye de rejeter un œil dès que possible.

Sinon c’est quoi le souci avec la progress bar ? La mise à jour ?

Dernière modification par grim7reaper (Le 29/09/2011, à 22:44)

Rolinh · Le 29/09/2011, à 22:46

Ouais. En fait, elle ne s'update pas et à la fin de la copie elle se complète d'un seul coup.

grim7reaper · Le 29/09/2011, à 22:50

Tu fais l’update où et comment ?

Édit : c’est bon j’ai vu.

Sinon, tu as mis 100 secondes pour g_timeout_add_seconds (ça me paraît un peu long), c’est normal ?

Dernière modification par grim7reaper (Le 29/09/2011, à 23:22)

The Uploader · Le 30/09/2011, à 08:12

tshirtman a écrit :

tout ça pour un fizzbuzz oO

Tout ça pour un fichu FizzBuzz en Java avec TDD fait avec IntelliJ!

Vive Ruby + Vim.

Dernière modification par The Uploader (Le 30/09/2011, à 08:13)

Rolinh · Le 30/09/2011, à 08:40

Désolé, j'étais parti me coucher.
Alors pour le coup des 100 secondes c'est juste que... c'était une erreur ^^ En fait, on utilisait une autre fonction avant et il me semble qu'elle prenait des millisecondes.
Du coup j'ai corrigé mais le problème ne vient pas de là.

En fait, il y a un problème avec le calcul de la taille. La taille de la queue passe subitement de la taille originale à 0 (remarqué cela en printant la valeur de l'élément depuis dequeue de queue.c). D'ailleurs, un des problèmes vient du fait que l'on enlève de la taille de la queue la taille de l'élément courant au moment où on le dequeue. C'est une erreur particulièrement flagrante sur les gros fichiers qui prennent du temps à se copier. Faudrait faire quoi? Stater le fichier de destination? Faire un thread avec une fonction qui va voir dans la destination ce qui a effectivement été copié? Si tu as une bonne suggestion, je suis preneur.
Je crois que je vais aller fouiner dans le code de scp pour voir comment ils gèrent ça.

EDIT: j'suis trop bête... J'ai trouvé un moyen tout propre de faire ça (détails plus tard)

Dernière modification par Rolinh (Le 30/09/2011, à 08:57)

grim7reaper · Le 30/09/2011, à 09:14

Rolinh a écrit :

Alors pour le coup des 100 secondes c'est juste que... c'était une erreur ^^ En fait, on utilisait une autre fonction avant et il me semble qu'elle prenait des millisecondes.

Ok, c’est bien ce qu’il me semblait.

Rolinh a écrit :

En fait, il y a un problème avec le calcul de la taille. La taille de la queue passe subitement de la taille originale à 0 (remarqué cela en printant la valeur de l'élément depuis dequeue de queue.c).

Oui, j’avais remarqué ça aussi en faisant des tests

Rolinh a écrit :

EDIT: j'suis trop bête... J'ai trouvé un moyen tout propre de faire ça (détails plus tard)

Bon cool alors, j’attends ta solution.

Bon /me go chercher son nouveau PC

Rolinh · Le 30/09/2011, à 09:56

En fait, j'avais premièrement utilisé g_timeout_add qui prend des millisecondes en paramètre pour passer à g_timeout_add_second qui prend des secondes...
Je suis revenu en arrière et utilise g_timeout_add finalement, pour plus de précision.

Pour l'histoire de la taille: avant, l'erreur était de vouloir ajuster la taille lorsqu'on enlevait l'élément de la queue. En fait, le fix est tout simple: la queue de copie et une variable globale et est de type list, définit dans list.h. Ce type comprend la taille de la liste dont le calcul se fait en ajoutant la taille d'un fichier au moment de son ajout à la liste de copie.
Le process de copie appel la fonction copy de copy.c qui copie effectivement. Cette fonction comprend la variable wcount de type ssize_t qui correspond à la taille de ce que l'on écrit dans le filedescriptor tant que le fichier n'a pas fini d'être copié. Il suffit donc de déduire la valeur de wcount à la taille de la queue globale à chaque morceau copié. Cela donne de plus une barre de progression super précise (ça change des barres "à la windows" qui vont en 5 secondes à 90% et reste bloquées à 90% pendant 10mn ).

EDIT: le commit en question

EDIT2: j'avais oublié le cas ou le fichier est mappé en mémoire ^^ (nouveau commit donc)

Dernière modification par Rolinh (Le 30/09/2011, à 10:20)

grim7reaper · Le 30/09/2011, à 11:18

Ouais c’est comme ça que j’aurais fait moi aussi

Cela dit, ta gestion du read et des write me semble un peu drastique (il y a des cas que tu considères comme des erreurs alors que c’est facilement récupérable).
Je repasserais pour donner plus de détails.

Keldath · Le 30/09/2011, à 11:21

@The Uploader : tu ne dois pas utiliser le modulo à la place ?
En reprenant ta façon de faire, en Python :

#!/usr/bin/env python

def fizzbuzz():
    res_fb = {}
    for x in range(1, 101):
        res = not x % 3 and "Fizz" or ""
        res = not x % 5 and "{0}Buzz".format(res) or res
        res_fb[x] = res or x
    return res_fb

import pprint
pprint.pprint(fizzbuzz())

Rolinh · Le 30/09/2011, à 11:35

@grim: c'est possible. Il y a tellement de choses à peaufiner/retoucher... L'idée c'est surtout d'arriver aux fonctionnalités souhaitées pour cette première version de LinCopier puis après de faire une phase bêta où on reprendra tout le code afin de peaufiner, corriger et optimiser au mieux.

valAa · Le 30/09/2011, à 11:50

Bah oui The Uploader, ton FizzBuzz renvoie "FizzBuzz" pour tous les nombres >= 5...

Dernière modification par valAa (Le 30/09/2011, à 11:52)

The Uploader · Le 30/09/2011, à 12:04

Keldath a écrit :

@The Uploader : tu ne dois pas utiliser le modulo à la place ?
En reprenant ta façon de faire, en Python :

#!/usr/bin/env python

def fizzbuzz():
    res_fb = {}
    for x in range(1, 101):
        res = not x % 3 and "Fizz" or ""
        res = not x % 5 and "{0}Buzz".format(res) or res
        res_fb[x] = res or x
    return res_fb

import pprint
pprint.pprint(fizzbuzz())

Ah ouais, tests merdiques! >_<

grim7reaper · Le 30/09/2011, à 12:08

Les tests étaient censés le détecter, mais comme les tests sont foireux eux aussi

@Rolinh : en fait, quand tu fais read ou write tu considères que la copie a foiré si ça renvoie -1 ou si tu n’as pas tout écrit.
Mais c’est pas si simple.
POSIX (enfin The Open Group Base Specifications, c-à-d le truc équivalent qui ne coûte pas une burne) nous dit

The Open Group Base Specifications a écrit :

If write() is interrupted by a signal before it writes any data, it shall return -1 with errno set to [EINTR].
If write() is interrupted by a signal after it successfully writes some data, it shall return the number of bytes written.

Idem pour read :

The Open Group Base Specifications a écrit :

If a read() is interrupted by a signal before it reads any data, it shall return -1 with errno set to [EINTR].
If a read() is interrupted by a signal after it has successfully read some data, it shall return the number of bytes read.

Donc si tu reçois -1 il faut pas crier à l’erreur tout de suite et d’abord tester errno. S’il vaut EINTR t’a juste été interrompu donc il suffit de retenter l’écriture (ou la lecture).
Idem, si tu n’as pas tout écrit c’est pas dramatique.

Bon pour le moment, ton code semble pas utiliser les signaux (quoique que GTK ou la GLIB le font peut-être par derrière, donc on ne sait jamais), mais autant être blindé.
De même, depuis Linux 2.4.9 il semblerait que EINTR ne soit jamais positionné tant que tu bosses sur des fichiers (j’avais lu ça quelque part sur la lkml), même en NFS (par contre il peut toujours apparaître quand tu bosses avec des sockets, fifos ou pipes). Mais bon, comme je suppose que tu vises aussi BSD (et que là je ne connais pas le comportement) vaut mieux pas se baser là-dessus.

Pour info, ce comportement (interruption des appels système « lent » pour donner la main au gestionnaire de signal) vient de la philosophie UNIX :

https://secure.wikimedia.org/wikipedia/en/wiki/Unix_philosophy a écrit :

In these cases Ken Thompson and Dennis Ritchie favored simplicity over perfection. The Unix system would occasionally return early from a system call with an error stating that it had done nothing—the "Interrupted System Call", or an error number 4 (EINTR) in today's systems. Of course the call had been aborted in order to call the signal handler. This could only happen for a handful of long-running system calls, i.e. read(), write(), open(), select(), etc. On the plus side, this made the I/O system many times simpler to design and understand. The vast majority of user programs were never affected because they didn't handle or experience signals other than SIGINT or Control-C and would die right away if one was raised. For the few other programs—things like shells or text editors that respond to job control key presses—small wrappers could be added to system calls so as to retry the call right away if this EINTR error was raised. Thus, the problem was solved in a simple manner.

Dernière modification par grim7reaper (Le 30/09/2011, à 12:24)

The Uploader · Le 30/09/2011, à 12:29

FizzBuzz bon:

class FizzBuzzer
    def fizzbuzz
        hfb = {}
        for i in Range.new(1, 100)
            result = (i%3).zero? == true ? "Fizz" : ""
            result = (i%5).zero? == true ? result + "Buzz" : result
            hfb.merge! i => result
        end
        return hfb
    end
end

(prouvé par un puts )

Maintenant mes tests restent foireux.

(oui je sais là pour le coup je fais pas vraiment du TDD )

grim7reaper · Le 30/09/2011, à 12:37

The Uploader a écrit :

FizzBuzz bon:

class FizzBuzzer
    def fizzbuzz
        hfb = {}
        for i in Range.new(1, 100)
            result = (i%3).zero? == true ? "Fizz" : ""
            result = (i%5).zero? == true ? result + "Buzz" : result
            hfb.merge! i => result
        end
        return hfb
    end
end

            result = (i%3).zero? ? "Fizz" : ""
            result = (i%5).zero? ? result + "Buzz" : result

Fixed.
C’est moche de tester les booléens contre true ou false.

The Uploader · Le 30/09/2011, à 12:38

J'me disais bien que j'avais fait un brain fart.

Merci.

edit, version OK:

#! /usr/bin/env ruby
require "test/unit"

# Licence: WTFPLv2

#    Exercice FizzBuzz :
#    - si x divisible par 3 : Fizz
#    - si x divisible par 5 : Buzz
#    - si les deux : FizzBuzz
#    - si aucun : rien
# Et ce jusqu'à 100

class FizzBuzzer
    def fizzbuzz
        hfb = {}
        for i in Range.new(1, 100)
            result = (i%3).zero? ? "Fizz" : ""
            result = (i%5).zero? ? result + "Buzz" : result
            hfb.merge! i => result
        end
        return hfb
    end
end

class TestMyObject < Test::Unit::TestCase

    def initialize(arg)
        initialize_fizzbuzzer
        super
    end

    def initialize_fizzbuzzer
        @myfizzbuzobj = FizzBuzzer.new
    end

    def test_gives_a_hash_of_one_hundred_pairs
        assert_not_nil @myfizzbuzobj.fizzbuzz
        assert_equal Hash, @myfizzbuzobj.fizzbuzz.class
        assert_equal 100, @myfizzbuzobj.fizzbuzz.size
    end

    def test_is_fizzbuzz
        hfb = @myfizzbuzobj.fizzbuzz
        for i in Range.new(1, 100)
            assert_not_nil hfb[i]
            assert_equal "Fizz", hfb[i] if (i%3).zero? and !(i%15).zero?
            assert_equal "Buzz", hfb[i] if (i%5).zero? and !(i%15).zero?
            assert_equal "FizzBuzz", hfb[i] if (i%15).zero?
            assert_equal "", hfb[i] if !(i%3).zero? and !(i%5).zero?
        end
    end
end

max@max-laptop> ./fizzbuzz.rb                                                                                                                                              ~/Dev/csii-3/agile/FizzBuzz
Loaded suite ./fizzbuzz
Started
..
Finished in 0.001938 seconds.

2 tests, 203 assertions, 0 failures, 0 errors, 0 skips

Test run options: --seed 30008

Dernière modification par The Uploader (Le 30/09/2011, à 12:43)

The Uploader · Le 30/09/2011, à 12:53

Bon maintenant c'est 3D, avec le framework XNA (C#):

using System;
using System.Collections.Generic;
using System.Linq;
using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Audio;
using Microsoft.Xna.Framework.Content;
using Microsoft.Xna.Framework.GamerServices;
using Microsoft.Xna.Framework.Graphics;
using Microsoft.Xna.Framework.Input;
using Microsoft.Xna.Framework.Media;

namespace Fractales
{
    /// <summary>
    /// This is the main type for your game
    /// </summary>
    public class Game1 : Microsoft.Xna.Framework.Game
    {
        GraphicsDeviceManager graphics;
        SpriteBatch spriteBatch;

        public Game1()
        {
            graphics = new GraphicsDeviceManager(this);
            Content.RootDirectory = "Content";
        }

        /// <summary>
        /// Allows the game to perform any initialization it needs to before starting to run.
        /// This is where it can query for any required services and load any non-graphic
        /// related content.  Calling base.Initialize will enumerate through any components
        /// and initialize them as well.
        /// </summary>
        protected override void Initialize()
        {
            // TODO: Add your initialization logic here

            base.Initialize();
        }

        /// <summary>
        /// LoadContent will be called once per game and is the place to load
        /// all of your content.
        /// </summary>
        protected override void LoadContent()
        {
            // Create a new SpriteBatch, which can be used to draw textures.
            spriteBatch = new SpriteBatch(GraphicsDevice);

            // TODO: use this.Content to load your game content here
        }

        /// <summary>
        /// UnloadContent will be called once per game and is the place to unload
        /// all content.
        /// </summary>
        protected override void UnloadContent()
        {
            // TODO: Unload any non ContentManager content here
        }

        /// <summary>
        /// Allows the game to run logic such as updating the world,
        /// checking for collisions, gathering input, and playing audio.
        /// </summary>
        /// <param name="gameTime">Provides a snapshot of timing values.</param>
        protected override void Update(GameTime gameTime)
        {
            // Allows the game to exit
            if (GamePad.GetState(PlayerIndex.One).Buttons.Back == ButtonState.Pressed)
                this.Exit();

            // TODO: Add your update logic here

            base.Update(gameTime);
        }

        /// <summary>
        /// This is called when the game should draw itself.
        /// </summary>
        /// <param name="gameTime">Provides a snapshot of timing values.</param>
        protected override void Draw(GameTime gameTime)
        {
            GraphicsDevice.Clear(Color.CornflowerBlue);

            // TODO: Add your drawing code here

            base.Draw(gameTime);
        }
    }
}

Sous Windows bien sûr..

Rolinh · Le 30/09/2011, à 13:00

@grim: c'est comme ça que tu voyais la chose?
Merci pour les infos à propos

Sinon, je suis en train de chercher un bug mais c'est pas très fructueux. En lançant une copie d'un dossier comportant plusieurs milliers de petits fichiers et dossiers, je me retrouve face à un "Error opening file : Too many open files". J'imagine donc qu'il y a un close qui ne doit pas marcher quelque part ou un oubli dans un cas particulier mais je n'arrive pas à mettre le doigt dessus.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#451 Le 29/09/2011, à 19:30

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

#452 Le 29/09/2011, à 19:38

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

#453 Le 29/09/2011, à 20:14

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

#454 Le 29/09/2011, à 20:42

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

#455 Le 29/09/2011, à 21:22

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

#456 Le 29/09/2011, à 21:59

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

#457 Le 29/09/2011, à 22:41

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

#458 Le 29/09/2011, à 22:43

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

#459 Le 29/09/2011, à 22:46

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

#460 Le 29/09/2011, à 22:50

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

#461 Le 30/09/2011, à 08:12

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

#462 Le 30/09/2011, à 08:40

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

#463 Le 30/09/2011, à 09:14

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

#464 Le 30/09/2011, à 09:56

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

#465 Le 30/09/2011, à 11:18

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

#466 Le 30/09/2011, à 11:21

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

#467 Le 30/09/2011, à 11:35

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

#468 Le 30/09/2011, à 11:50

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

#469 Le 30/09/2011, à 12:04

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

#470 Le 30/09/2011, à 12:08

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

#471 Le 30/09/2011, à 12:29

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

#472 Le 30/09/2011, à 12:37

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

#473 Le 30/09/2011, à 12:38

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

#474 Le 30/09/2011, à 12:53

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

#475 Le 30/09/2011, à 13:00

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

Pied de page des forums