Reprise du message précédent :

 
Cette stratégie a déjà été essayée. Il revient quand même.

Pas sur, faudrait que le parser de Forum de Flaie nous extraies des stats la-dessus car j'ai l'impression que quelqu'un finit tjrs pas craquer ce qui relances d'autant la machine...
 
Avec en plus un visualisation en gif et ce serait au top !

BTW, flask + blueprint c'est cômême pas mal du tout.    
 
C'est marrant, c'est en aidant ma fille que je me suis mis à python. à ce rythme, je sens que je vais modifier notre stack au boulot. (bon faudrait former certains devs - remarque, je peux aussi les virer et en prendre d'autres   )

Content de voir que ça existe toujours Flask, mon époque Python est loin derrière moi, à l'époque j'étais content de tourner "low level" python avec falcon, ça marchait plutôt bien

Pour des trucs que tu jettes pas après quelques heures, j'avoue que je préfère Django, notamment si t'as du templating serveur (et même pour une API pure, Django avec rest-framework est pas trop mal de mémoire, même si ça fait longtemps que j'ai pas pratiqué).  
Parce que dès que tu retrouves à intégrer a ton app flask un ORM (SQLA typiquement) + un moteur de template (aka Jinja2) + un truc de validation de formulaire + éventuellement un générateur d'admin CRUD... Bin ça finit par ressembler fortement à Django moins bien intégré quoi, sans la doc de qualité qui va avec.

 
Bah dans l'implem basique de Dijkstra t'as pas de liste de nœuds visités et t'en as pas vraiment besoin je crois.
Tu gagnes quelques comparaisons mais elles sont pas vraiment coûteuses.

masklinn, cado : https://blog.sesse.net/blog/tech/20 [...] mysql.html

Ca m'étonne un peu, sans ca (via un set ou un deuxième graphe que tu remplis des noeuds que tu as déjà considéré), sinon tu vas aller itérer des noeuds qui ne servent à rien

Les soluces c'est toujours vers le bas et vers la droite jusqu'à la fin ou ça peut être plus tordu ?

ça peut.
 
genre
 

D'ailleurs ma solution marche sur l'exemple et tous les exemples simples que je fais mais se plante de 1 sur mon input, ça me saoule là

non

C'est jamais très différent par contre.

Ma première solution consistait à partir de la solution naïve ne considérant que les chemins vers le bas ou la gauche, puis de raffiner quelques fois. Il me semble qu'on peut se contenter de raffiner max(rows, columns) fois. En tout cas c'est passé.

Oui sur le principe mais ça serait pas la première fois que les inputs de l'AoC soient arrangeants

Mais il repart aussi, généralement, c’est comme les enfants il s’accroche beaucoup moins quand tu réagis pas.

Vieux

ça fait 2h que Dijkstra tourne sur la partie 2, j'y crois

 
L'algo de base tu pars de l'ensemble des nœuds et tu les enlèves au fur et à mesure que tu les traites, donc oui c'est déjà géré.
Après il se peut que tu réévalues plusieurs fois la distance optimale pour un même nœud, mais dans le pire cas c'est juste une comparaison d'entiers, ça va.

 
Oui je regarde aussi Django. Par contre, pour être honnête, les ORM j'en suis revenu. On a bcp utilisé Doctrine avec nos projets en PHP par exemple, et plus le temps passe, moins on utilise. Au bout du compte, je trouve que ça manque de souplesse et de toutes manières, tu te retrouves souvent à "reverse engineer" ce que fait ton ORM quand il y a un problème que tu ne comprends pas. Dès que ça devient complexe, on utilise du SQL.
Mais vu où j'en suis maintenant, c'est clair que je vais aussi étudier Django. Ne serait-ce que pour mon CV et être capable de manager des teams plus tard qui l'utilisent.
Ce que je trouve intéressant avec Flask, c'est que ça a l'air vraiment flexible tout en restant très lisible et facile à structurer.

 
C'est passé

C'est moi ou JSON c'est de la merde ?  
 
J'ai pas fait de web assez longtemps avant de rejoindre Google pour m'en rendre compte, mais c'est quoi ce format d'enculé ? Tu peux pas mettre une virgule ou un commentaire sans te faire cracher à la gueule. Ah mais ouais, c'est fait pour être lu par les machines et par les humains. Trop malin.

Facile !

oui, mais y'a YAML encore en pire.

J'imagine chaque pixel qui s'allume toutes les 50 secondes
 
https://imgur.com/a/UkuN0S3

This

C'est toi.

C'est pas fait pour être écrit par des humains.

Les commentaires ont pas été intégrés à dessein, parce qu'à la base c'est un format d'échange (et que pour Crockford avoir des commentaires garantissait que ça soit mésutilisé comme des meta-instructions), et les virgules... c'est parce-que c'est sur base des objets litéraux JS (d'où le nom) qui avaient cette limitation malheureuse à l'époque.

Après ça veut pas dire qu'il est utilisé à bon escient, les gens qui utilisent le JSON comme format de configuration sont des imbéciles finis. Mais ça n'a rien à voir avec le langage, c'est comme dire que protobuf c'est merdique parce que c'est impossible à éditer à la main.

'tain j'ai passé 49 min sur skype avec le développeur du logiciel, j'ai toujours pas compris comment marchent les axes dans le fichier qu'il génère

 
C'est le web  

Parce que c'est un format d'échange, de données, etc.. et qu'un JSON sur une ligne ça doit rester la même chose qu'un json sur plusieurs lignes.

Tu as oublié les vilains mots il me semble, c'est pas clair ton message

Sympa le timelapse de ta solution

XML? SOAP? ASN.1? CORBA?

Ça me fait une belle jambe. J'ai besoin d'en écrire j'espère que j'irai pas en taule.

Bah si justement les protobuf ont un format pour les humains et un format pour les machines. Et du coup les deux sont mieux, parce qu'effectivement c'est deux trucs très différent.

Je savais que json était pourri pour les machines : ça prend de la place, c'est galère de faire des trucs retro-compatibles. Je croyais sincèrement que c'était parce que c'était fait pour les humains. Je réalise aujourd'hui que ni l'un ni l'autre.

XDR?

Tu peux faire ça avec du JSON, tu l'écris avec <ce que tu veux> et tu sérialises derrière

Et AFAIK c'est pas le cas de protobuf, ya pas de sérialisation lisible des messages, ya au mieu une sérialisation de débugging, sauf si tu considères que ça c'est lisible:

wat

Une assertion qui veut pas dire grand chose.

C'est un format textuel, ça a ses avantages, mais ça garanti rien (cf... XML par exemple).

XML c'est largement superior

Il y a le format textproto pour ça. C'est pas fait pour être utilisé pour les machines, mais ça sert de représentation utilisable par les humains. On peut y mettre des commentaires, autant de lignes vides et d'espaces qu'on veut. Je croyais que json était similaire au textproto, j'ai réalisé que pas du tout.

Bah il me semble que c'est le cas d'utilisation phare du protobuf. Renommer un champ, supprimer, ajouter peut être fait d'un côté ou de l'autre sans prévenir l'autre. Je me doute que ça se fait en json aussi mais c'est forcément plus de travail.

C'est un (mauvais) méta-langage donc tu peux (mal) définir n'importe quelle saleté avec (genre une sérialisation XML pour ton JSON).
 
C'est moins lisible, moins écrivable, plus lourd, plus ambigu, plus lent, plus risqué. Sauf si t'as besoin d'un format de type documentaire dans lequel tu mixe texte et instructions de processing, je vois pas comment il est possible de dire un truc pareil.

Et c'est censé servir à quoi si une machine peut pas l'utiliser?

Parce-que encore une fois, si t'as besoin d'un compilo entre les deux tu peux faire pareil avec JSON, tu peux écrire des sexp et sérialiser ça en json si ça t'amuse, je suis sûr que tous les lisps avec plus de 3 utilisateurs ont un lecteur et un sauveur.

Bof. Je sais pas trop ce que protobuf fait là dessus à part mettre du garbage dans les champs que tu "supprimes", ce que tu peux faire en JSON. Tu peux toujours ajouter un champ, les implems statiquement typées vont l'ignorer (enfin toute celles à quelles j'ai eu affaire) et les autres c'est le client qui regarde pas. À la limite tu gagnes de pouvoir renommer un champ vu que les labels existent pas dans le format de sérialisation.

Mais bon t'as surtout complètement raté ce que je disais, te concentrant sur l'arbre pour ignorer la forêt. Pas que tes réponses soit pour un sou satisfaisantes, notes.

J'ai peut-être mal démarré cette conversation. Je ne comprends pas ce que tu suggères.

Je veux écrire un test unitaire, pour vérifier que quand mon service reçoit certaines données, il renvoit une certaine réponse. Les données d'entrée sont du json. Est-ce qu'il y a un moyen commode d'écrire ce JSON, si possible en ligne dans mon test (pas dans un fichier à part) ?