nicooo a écrit 36 commentaires

Hello,

Qu'est-ce que tu veux dire par "pas cohérent" ?
Dans Pacman, lui et les fantômes se déplacent bien pixel par pixel. Par contre ils sont effectivement contraints par les murs du labyrinthe, ce qui fait qu'ils sont toujours sur une 'case', ou entre deux.

Pour le vaisseau ce serait une idée de le placer dans le labyrinthe et qu'il doive respecter les murs, mais ça le rendrait pas mal plus difficile à jouer. J'y réfléchis !

Pour le mode solo, ça se joue au clavier… ou avec une manette en twin-sticks ;)

Depuis la version 0.9.2 publiée hier, les contrôles sont affichés dans le jeu avant le début de partie.
Pour jouer en solo twin-sticks, appuie deux fois sur le bouton X de la manette pour "join" deux fois et contrôler les deux persos avec la même manette.

Merci pour l'info !
Je ne connaissais pas, effectivement c'est un peu le même esprit.

Le jeu vient même de passer en version 0.9.2 !
Un peu plus facile, avec de la slow motion en bonus. :)

Pour cet exemple, deux workflows semblent appropriés.

Le premier est à planifier à 1h du matin, et va récupérer les données sur le FTP. La tâche pourra utiliser les retry schedules pour réessayer jusqu'à ce que les données soient disponibles.

Le deuxième workflow est à planifier à 5h du matin, il fera les traitements sur les données récupérées et les enverra sur un autre serveur.
Il pourra attendre que les données soient disponibles via les retry schedules.
Autre possibilité, en définissant une même file d'attente de concurrence 1 pour les deux tâches dans les deux workflows, on est sûr que le traitement des données ne débutera pas avant qu'elles aient été récupérées.

Pour le démarrage du workflow, il semble que le planifier quotidiennement à 2h00 réponde à ce cas d'utilisation.
Pour le couper à une certaine heure, il n'existe pas encore d'option dans evQueue. Après discussion avec l'équipe, nous opterions pour une « durée maximale de workflow » (ici 4 heures).
Cependant, comment tuer le workflow ? Violemment à coup de kill -9 ?

En attendant, il est possible de planifier un deuxième workflow à exécuter tous les jours à 6h00, qui s'occuperait de terminer la tâche de synchronisation (quelle que soit la manière choisie).

Il s'agit bien ici de queues, donc de files d'attente, et pas de threads.

Nicolas - UFC-Que Choisir

Bonjour devnewton,

Si je comprends bien, une contrainte au plus tôt consiste à dire « exécuter cette deuxième tâche dès qu'une première est terminée ». Ceci est le fonctionnement de base d'evQueue : un workflow est un enchaînement de tâches qui s'exécutent l'une après l'autre, dans l'ordre.
Sur cette capture d'écran, extraite de l'exemple d'un workflow qui fait l'équivalent de ls | wc -l, la deuxième tâche wc -l doit attendre que la première ls soit terminée avant de démarrer. Ça tombe bien car elle prend en entrée le résultat du ls.

Note qu'il est possible de mettre plusieurs tâches au même niveau (dans un même job) ; ces tâches s'exécuteront en parallèle, et quand toutes seront terminées, la ou les tâche(s) du job suivant pourra(ont) commencer à s'exécuter. C'est une implémentation du concept de barrière de synchronisation.

Pour revenir à la contrainte au plus tôt, il existe également une fonctionnalité avancée (evQueueWait) qui permet de formuler une condition très précise qu'une tâche devra attendre avant d'être lancée. Cependant, la combinaison de tâches à exécuter en parallèle et/ou de manière séquentielle suffit à répondre à la majeure partie des besoins.

Je ne vois pas trop ce qui pourrait coller à une exécution au plus tard dans evQueue. La date ou l'heure de fin d'un workflow n'étant pas connue à l'avance, on ne peut pas commencer « X temps avant ça ». Ai-je mal saisi la question ?

Nicolas - UFC-Que Choisir

Pour la planification à intervalle régulier, voir la partie de la documentation sur les « Scheduled Workflows ».

Les workflows peuvent être exécutés sur une machine distante, paramétrable dans l'onglet « host » pour les workflows planifiés.

Si vous le souhaitez nous avons mis le code sur github !

Bonjour LupusMic,

Nous ne trouvons pas dérangeant de « se prendre des coups » en montrant le code. Après tout si les gens ne sont pas contents ils n'ont aucune obligation de lire ou d'utiliser le code.
Et même si les remarques ne sont pas forcément formulées avec gentillesse, on peut en faire ressortir des bons conseils applicables pour améliorer le code.

Concernant htmlentities, il n'apparaît qu'à un seul endroit, et c'est une tâche interne (qui certes n'a pas à faire partie du projet).
Pour le C++, pouvez-vous nous envoyer une version plus détaillée des modifications proposées (sur dev at evqueue dot net) ?

Merci d'avance

Il n'est pas vraiment question de créer une communauté, dont nous n'aurions pas le temps de nous occuper et en laquelle nous ne voyons à ce jour pas d'intérêt majeur.
Obtenir des retours est toujours une bonne chose, mais ce n'est pas la raison principale de la « libération » du logiciel.
Il ne s'agit pas non plus des raisons « sociales » que vous décrivez.

La demande d'ouverture à la communauté étant déjà insistante alors que l'annonce ne date que d'hier, nous allons probablement mettre le projet sur github (à défaut d'une solution équivalente en libre, malheureusement).
Nous doutons cependant que beaucoup contribueront.

C'est justement parce que c'est un logiciel dont nous avions besoin en interne, et que nous n'avons pas trouvé d'alternative solide (comme votre premier message indiquait également), que nous avons développé evQueue.
Maintenant qu'il est là, autant en faire profiter tout le monde… Même si ça peut paraître naïf ou idiot, c'est une notion qui est même incluse dans la GPL ! (« This program is distributed in the hope that it will be useful »)
Énormément de logiciels libres (et surtout de grands projets) ont eu ce même cheminement.
L'entreprise derrière le logiciel n'a rien à perdre à le publier sous licence libre, si ce n'est le temps justement de le publier.

Espérant avoir répondu à vos questions,
Nicolas