Reprise du message précédent :

Absolument

pour le coup c'est un bon investissement : tu regretteras moins ton abo Udemy quand elle ramènera une Medal Fields
 

pense au prix horaire de ton coiffeur, considère la criticité des actes en questions. Je pense qu'ils se touchent un peu, mais c'est pas forcément déconnant.

enculés de jeunes qui veulent de la work/life balance, si ça se trouve ils veulent même être heureux ? Putain ça me dégoute
 

 
Moi pour les coups de hache je fais une mixture bouse de vache / pissenlit / amanite tue-mouche, en cataplasme. Y'a tous les produits pas loin.

 
Mandatory https://www.youtube.com/watch?v=Ni0YfrSK570  
 
Perso je suis fan des cabinets médicaux : y'a toujours un docteur, j'ai des RDV dans la journée si besoin, dans tous les cas dans la semaine, c'est super. Comme ils sont un pool de 4 ils ont la thune pour une mini labo d'analyse, donc quand j'y vais 80% des résultats de ma prise de sang sont dispo sous 10min pendant que je parle avec ma doctoresse.
Je comprends malheureusement très bien le médecin qui veut pas bosser 80h / semaines parce que c'est le seul dans un rayon de 30km, à etre sur la route tous les jours et devoir éviter les gens bourrés sur leur tracteur (attention, un jugement de valeur sur la campagne a pu se glisser bien involontairement dans cette phrase. Je tiens pourtant à dire que le dernier accident de bagnole de ma mère c'était dans son camion (elle étant antiquaire), sur une route parfaitement droite et dégagée. Le fermier a démarré juste devant le camion. Réponse de l'intéressé (qui a miraculeusement survévu), avec l'accent bressan qui va bien  : Oh, bah yé cru qu'ç'étôt un tracteurrrrrr.)
 

mais non enfin, ils ont GAGNÉ LA COUPE DU MONDE ! ça va forcément mettre fin à la pauvreté, créer un système d'éducation égalitaire et performant, mettre fin à la corruption.
Y'a déjà des headlines de journaux dans ce sens.
Note que je suis content pour Messi, il l'avait pas dans sa collection celle là, et pis si ça fait plaisir à la population j'y vois aucun mal, mais je doute fortement que ça change quoi que ce soit. La prime FIFA va partir à la fédération qui va en filer la grosse partie aux joueurs en prime de matchs / buts, ils vont construire 2 terrains de street soccer pour que les gamins jouent pied nus sur de l'asphalte au lieu de la terre battue, pis ça va s'arreter là.
 

Après tout un tas d'amélioration, j'ai passé mon day19 part 2 de 5.5 secondes à 6.2 secondes

Le mieux que je fais c'est 70 s
 
edit : c'est tombé à 1,5 s en remplaçant le BFS par un DFS

Ouais le DFS est une super mauvaise idée ici
 
Sur le thread de solutions /u/boojum a une super optimisation, une version beaucoup plus smart de celle que j'avais proposé, mais ça impose une valeur globale

Ah mais je le fais déjà ça

 
edit : du coup je poste mon code, il reste surement d'autres optimisations à trouver : https://topaz.github.io/paste/#XQAA [...] 44oUP92abh

Dites, c'est normal que le fichier de base de données de SQLite enregistre tout en SQL dans un fichier texte ? Je suis super surpris.

non, t'as soit un dump, soit un fichier de log du driver, ou un truc du style.

Somme des termes d'une suite arithmétique : première.

Ça fait 30 ans, donc

C'est qu'une option de lisibilité mais un truc auquel j'ai songé (mais que j'ai pas encore fait) c'est de stocker les robots, resources, et couts de robots dans un array BE (geode, obsidian, clay, ore), comme ça tu peux juste faire une comparaison lexicale pour savoir si t'as atteint tes seuils (de resources pour construire un bot, de production pour les bots, ...). en fait j'ai plus de comparaisons de ce style dans mon code, et essayer d'appliquer le changement rend juste le code plus lent.
 
edit: pourquoi tu maj max_ge à chaque tour et pas juste quand t=0?
edit 2: je suis pas sûr que "seen" soit super utile, j'ai fait sans perso

T'aurais pas activé le query logging?
 
Sinon apparemment selon le SQLITE_TEMP_STORE et pragma temp_store, tu peux apparemment avoir un truc appelé "statements journal" qui est écrit, mais je sais pas ce que ça contient.

J'ai pas dit que c'était déconnant. Même si probablement un peu. Dans un contexte d'inflation, il faudrait qu'eux aussi soient revalorisés.
Mais 100% d'augment', aux frais de l'assurance maladie, donc de nos impôts, sans contrepartie et pendant que les salaires et cotisations n'augmentent pas en même temps que l'inflation, c'est hors-sol pour une population qui appartient tout de même aux 5% des ménages les plus aisés.
L'accès aux soins pour les plus pauvres serait encore plus dramatique.

seen était ma première tentative d'optimisation, il est resté depuis, mais en effet je peux le supprimer sans effet visible.
pour max_ge pareil, en faisant du BFS je me disais que ça pouvait avoir un sens, mais plus avec le DFS

Les seules options que j'ai passées à sqlite3_open_v2() sont
 
SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE | SQLITE_OPEN_WAL

En fait tu fais ton DFS 1x par unité de temps et tu regardes où en sont tes resources non?
 
Tu pourrais ptet gagner un peu en faisant l'inverse: tu choisis quel est le prochain bot à construire (modulo nécessité que tu peux précalculer facilement), et une fois que t'as fait ça tu peux brûler des étapes parce que si t'as besoin de 7 obsidian et que t'en fabriques 1/mn, tu peux juste avancer de 7mn et monter tes resources de 7xbot (après avoir décrémenté du coût du bot que tu veux constuire). Ça devrait faire moins d'états et de traffic.
 
Mais calculer le skip forward est un peu chiant (c'est ce que je trouve moche chez moi mais je vois pas trop comment le sexifier)
 
Bon par contre comme ton code est pas uniforme ça va être chiant à implémenter.

Putain ils ont pété la fibre par chez moi.
Réparation prévu pour cette matinée, puis décalée au 22 fin de journée.
La 4G est saturée, j'avais pas prévu d'aller sur site les jours suivants

En fait le mobile est perturbé aussi sauf la 3G.. La grosse misère

Putain, en fait c'est le viewer intégré à Midnight Commander qui décode automatiquement les fichiers SQLite

Bon ben welcome la grippe, en arrêt pour la semaine, plus de cogip avant le 03/01 c'est tjrs ça

Comment on fait quand le réseau mobile est aussi impacté ?
https://suivi-des-incidents.orange.fr/service24

Ben dans'l'cul lulu

Oui s’tu veux jamais être impacté faut plus de backups: ADSL, cable, et satellite.  
 
Mais pour un particulier c’est un poil overkill.

Si, ça fonctionne

Bon courage et bon rétablissement. Moi ces temps-ci, c'est masque en public. C'est d'ailleurs ce que les pouvoirs publics recommandent, les hôpitaux étant en passe de saturer de nouveau.

 
FAUT PARALLELISER
 
ET UNE FOIS QUE CA MARCHE PAS FAUT RABBITMQ
 
ET APRES FAUT TOUT REFAIRE EN RUST

J'ai essayé de paralléliser, mais après le pruning ça fait que ralentir. REMBOURSEZ!

Wow wow wow, calmons nous

C'EST DÉJÀ EN RUST< REMBOURSEZ111

https://superfastpython.com/threadp [...] ach_Thread
dites, vous avez pas l'impression dans cet exemple qu'il donne le même threadlocal à tous les threads du pool ?
 
Je trouve pas d'autre exemple sur le net, je cherche à mettre un request.Session() et une connexion de DB dans chaque thread de mon pool.
 
edit:  

 

C’est normal, threading.local créée un proxy et gère la localité en interne.

Bon sinon visuellement avatar 2 c'est une tuerie.

Vu en 3d, ça apporte vraiment qqchose contrairement à d'autres films que j'ai vu.

Tu peux faire "pydoc _threading_local" dans ton terminal:

merci.
 
je crois que j'ai été me paumer dans les ronces là:
Je veux appeller la même fonction (hold_lol), une fois dans une boucle et une fois dans un threadpool:
 

class LOL
 
    def hold_lol(self, lol: PurchasableLol, db_connection: Connection = self.db_connection,
                    session: Session = requests.Session()) -> dict:
        # ....
 
    def hold_lols_list(self) -> List[dict]:
        with requests.Session() as s:
            with sqlalchemy.engine.create_engine(DATABASE_URL).connect() as db_connection:
                held_lols = []
                for lol in self.purchase_lol_list:
                    held_lol = self.hold_lol(lol, db_connection, s)
                    if held_lol:
                        held_lols.append(held_lol)
                    sleep(self.sleep_between_each_hold)
                return held_lols
 
    @staticmethod
    def init_thread(local, resources):
        res = {'db': sqlalchemy.engine.create_engine(DATABASE_URL).connect(), 'session': requests.Session()}
        local.resources = res
        resources.append(res)
 
    def hold_lol_thread(self, params):
        (lol, local) = params
        return self.hold_lol(lol, local.resources.db, local.resources.session)
 
    def hold_lols_list_ASYNC(self) -> List[dict]:
        local = threading.local()
        resources = []
        try:
            with concurrent.futures.ThreadPoolExecutor(initializer=self.init_thread,
                                                       initargs=(local, resources)) as executor:
                held_lols = executor.map(self.hold_lol_thread,
                                            zip(self.purchase_lols_list, local * len(self.purchase_lols_list)))
                held_lols = list(held_lols)
                held_lols = [item for item in held_lols if item]  # filtering the None values
                return held_lols
        finally:
            for r in resources:
                r.db.close()
                r.session.close()

 
la création et le nettoyage des resources par thread sent un poil le jardinage, j'ai raté un truc plus simple je pense.
 
edit: j'utilise le requests.Session() pour avoir du keepalive sur le serveur distant, parce qu'il y a du https et tout, ça rame.
 
edit2: je vois qu'un truc sur stack overflow https://stackoverflow.com/questions [...] r-shutdown  
et j'arrive pas à utiliser la recherche de github pour trouver un bon exemple.

class LOL
 
    def hold_lol(self, lol: PurchasableLol, db_connection: Connection = self.db_connection,
                    session: Session = requests.Session()) -> dict:
        # ....
 
    def hold_lols_list(self) -> List[dict]:
        with requests.Session() as s:
            with sqlalchemy.engine.create_engine(DATABASE_URL).connect() as db_connection:
                held_lols = []
                for lol in self.purchase_lol_list:
                    held_lol = self.hold_lol(lol, db_connection, s)
                    if held_lol:
                        held_lols.append(held_lol)
                    sleep(self.sleep_between_each_hold)
                return held_lols
 
    @staticmethod
    def init_thread(local, resources):
        res = {'db': sqlalchemy.engine.create_engine(DATABASE_URL).connect(), 'session': requests.Session()}
        local.resources = res
        resources.append(res)
 
    def hold_lol_thread(self, params):
        (lol, local) = params
        return self.hold_lol(lol, local.resources.db, local.resources.session)
 
    def hold_lols_list_ASYNC(self) -> List[dict]:
        local = threading.local()
        resources = []
        try:
            with concurrent.futures.ThreadPoolExecutor(initializer=self.init_thread,
                                                       initargs=(local, resources)) as executor:
                held_lols = executor.map(self.hold_lol_thread,
                                            zip(self.purchase_lols_list, local * len(self.purchase_lols_list)))
                held_lols = list(held_lols)
                held_lols = [item for item in held_lols if item]  # filtering the None values
                return held_lols
        finally:
            for r in resources:
                r.db.close()
                r.session.close()

Je suis pas sûr, le cleanup de threadlocals c'est toujours la merde.

Regarde toujours contextvars, c'est des threadlocals un peu plus velues qui marchent avec les coroutines. Quand je les ai testées ça marchait bien mais l'API est assez bizarre.

Pour SQLA tu devrais regarder les sessions, elles sont thread-safe, comme ça tu te fais pas chier. Malheureusement c'est pas le cas des sessions de requests. mais ça c'est moins grave de pas les fermer je pense.

Une autre considération potentielle (si tu veux vraiment faire ça bien et fermer tes requests.Session) c'est d'utiliser ExitStack au lieu de te faire chier à faire ton cleanup à la main:

class Lol:
    def hold_lols_list_ASYNC(self) -> List[dict]:
        local = threading.local()
        with ExitStack() s:
            with concurrent.futures.ThreadPoolExecutor(initializer=self.init_thread,
                                                       initargs=(local, s)) as executor:
                held_lols = executor.map(self.hold_lol_thread,
                                            zip(self.purchase_lols_list, local * len(self.purchase_lols_list)))
                held_lols = list(held_lols)
                held_lols = [item for item in held_lols if item]  # filtering the None values
                return held_lols
 
    @staticmethod
    def init_thread(local, resources):
        local.db = resources.enter_context(sqlalchemy.engine.create_engine(DATABASE_URL).connect())
        local.req = resources.enter_context(requests.Session())

truc du style (pas fan des staticmethods non plus mais YMMV)

Le 3e c'est du micro mais

held_lols = list(held_lols)
                held_lols = [item for item in held_lols if item]  # filtering the None values
                return held_lols

peut probablement être simplifié en

return list(filter(None, held_lols))

Accessoirement

def hold_lol_thread(self, params):
        (lol, local) = params
        return self.hold_lol(lol, local.resources.db, local.resources.session)

held_lols = executor.map(self.hold_lol_thread,
                                            zip(self.purchase_lols_list, local * len(self.purchase_lols_list)))

D'après la doc, comme le builtin `Executor.map` peut prendre plusieurs itérables (ça fait zipmap), donc tu peux simplifier en  

def hold_lol_thread(self, lol, local):
        return self.hold_lol(lol, local.resources.db, local.resources.session)

held_lols = executor.map(self.hold_lol_thread,
                                           self.purchase_lols_list, local * len(self.purchase_lols_list))

Et tu peux utiliser `itertools.repeat(local)` au lieu de bricoler avec des listes, comme un zip classique ça s'arrête à l'itérable le plus court donc normalement c'est utilisable avec des itérateurs infinis.

class Lol:
    def hold_lols_list_ASYNC(self) -> List[dict]:
        local = threading.local()
        with ExitStack() s:
            with concurrent.futures.ThreadPoolExecutor(initializer=self.init_thread,
                                                       initargs=(local, s)) as executor:
                held_lols = executor.map(self.hold_lol_thread,
                                            zip(self.purchase_lols_list, local * len(self.purchase_lols_list)))
                held_lols = list(held_lols)
                held_lols = [item for item in held_lols if item]  # filtering the None values
                return held_lols
 
    @staticmethod
    def init_thread(local, resources):
        local.db = resources.enter_context(sqlalchemy.engine.create_engine(DATABASE_URL).connect())
        local.req = resources.enter_context(requests.Session())

held_lols = list(held_lols)
                held_lols = [item for item in held_lols if item]  # filtering the None values
                return held_lols

return list(filter(None, held_lols))

Merci, je regarde tout ça.  
Je pense que l'Exitstatck est un bon deus ex machina, c'est carrément aller se brancher sur un système de defer à la go.
 
en tout cas merci, t'as au moins ouvert le jeu, je suis sous l'eau mentalement, et je peux pas trop tester le code, parce qu'on est dans des conditions qu'on va appeler "un petit poil antagonique".
 
Je corrige le filtrage, j'ai aussi corrigé l'orthographe en postant, mais on revient de loin niveau code style, il reste plus trop de route, mon collègue gaze bien et il voit l'intérêt de tout ça, je vais peut-être avoir une barre de warnings utilisable bientôt.

def hold_lol_thread(self, params):
        (lol, local) = params
        return self.hold_lol(lol, local.resources.db, local.resources.session)

held_lols = executor.map(self.hold_lol_thread,
                                            zip(self.purchase_lols_list, local * len(self.purchase_lols_list)))

def hold_lol_thread(self, lol, local):
        return self.hold_lol(lol, local.resources.db, local.resources.session)

held_lols = executor.map(self.hold_lol_thread,
                                           self.purchase_lols_list, local * len(self.purchase_lols_list))

merci pour tout, je vais le faire.

https://docs.sqlalchemy.org/en/14/o [...] hread-safe
J'ai pas l'impression que ce soit le cas ?

edit: y'a l'air d'y avoir ça https://docs.sqlalchemy.org/en/14/o [...] contextual , je vais devoir lire lentement, et avec le doigt.

Whop désolé pour le mensonge, heureusement que t’as vérifié

 
RAJOUTE DE L4ASM, UNE COUCHE DE TOKIO, JE SAIS PAS FAIT QUELQUE CHOSE POURQUOI TU METS LA CHARGE MENTALE SUR MOAAAA  
 
/ FOU / FOU /
 
   
 

J'aimerai tellement utiliser SQLA à la place de Django  

En même temps si tu commences jour 19 c’est chaud vu qu’AOC à toute une histoire de jour en jour.

Chuis pas persuadé que du sql alchemy de merde soit mieux que du django de merde notes.

C'est vrai que t'en a rien à foutre. Avec ton niveau de vie tu pourras toujours aller dans la médecine privée pendant que les gueux crèveront

Ce serait quoi l'alternative ?
Parce que django Jpp  

C'est quoi ton besoin ? Autant SQLA est très puissant, autant c'est aussi assez complexe de rentrer dedans et on s'est pris plusieurs fois les pieds dans le tapis.
Et ayant commencé par Django, j'avais très envie de jouer avec SQLA.

Mais aujourd'hui, à moins d'avoir un vrai besoin de construire des requêtes complètement dynamiques, je ne suis pas sur de choisir SQLA (si bien sur j'ai le choix du framework web associé, c'est sur qu'en Flask l'ORM de Django sera moins une solution ). Alors oui le query builder de Django est plus limité, mais du coup bin tu bascules direct au raw SQL... Et globalement ça fait aussi le taf, tu "perds" pas du temps à vouloir traduire une query SQL en code Python/SQLA.
Alors peut-être que notre approche n'était pas la bonne, mais ça nous est arrivé de nombreuses fois en SQLA d'avoir des (mauvaises) surprises quand on voulait traduire des requêtes SQL, pas forcément très complexes, en SQLA... Et ce qu'il nous donnait réellement en SQL sorti. Pas mal de problèmes notamment liés aux différences entre les .join / joinedload / eagerload. Après tout est écrit dans la doc au final, mais l'apprentissage est plus complexe qu'un Django avec ses "select_related" & basta (du moins le souvenir que j'en ai, ça fait quand même quelques années).

Edit: Y avait aussi la déclaration des modèles en SQLA, avec le double style impératif et déclaratif, qui était plus confusant qu'autre chose, mais ils ont pas mal fait le ménage et clarifié la doc depuis.