J'avais besoin de le dire, c'est vraiment de la merde, une gestion calamiteuse des objets, rien que deepcopy un objet faut avoir fait bac+5 haxxor, pas de mulithreading, l'asynchrone pourri à coup de settimeout partout dans ton code

go next

Ahah je comprends qu'on puisse être à bout mais il faut savoir structurer et encadrer son JS pour éviter de se casser le nez dessus et ça demande de la pratique

Mais oui l'objet en JS c'est vraiment moche

Pour le settimeout tu devrai regarder du côté des promise et des fonctions async await car normalement tu n'as pas besoin de faire de settimeout

Le 27 février 2020 à 10:49:48 wowisclassic a écrit :
J'avais besoin de le dire, c'est vraiment de la merde, une gestion calamiteuse des objets, rien que deepcopy un objet faut avoir fait bac+5 haxxor, pas de mulithreading, l'asynchrone pourri à coup de settimeout partout dans ton code

go next

mauvais dev ...

c'est le langage que j'apprécie le moins en vanilla, je trouve ça brouillon, expérimental mais bon je travaille quand même dessus.

Le 27 février 2020 à 12:13:39 UndeadMarston6 a écrit :
Ahah je comprends qu'on puisse être à bout mais il faut savoir structurer et encadrer son JS pour éviter de se casser le nez dessus et ça demande de la pratique

Mais oui l'objet en JS c'est vraiment moche

Pour le settimeout tu devrai regarder du côté des promise et des fonctions async await car normalement tu n'as pas besoin de faire de settimeout

j'ai été ban, sorry mais c'est moi

donc disais je, le probleme en fait c'est que js ne supporte pas le multithreading et on essaie d'emuler quelque chose de semblable en délayant avec settimeout, c'est vrai que ça n'a pas directement à voir avec les promises, mais ça à voir avec le crawler que je developpe en ce moment ; j'ai besoin de gerer une queue, de la remplir d'une part et de la vider d'une autre. j'ai des problemes de memoire, parce que la queue se remplit plus vite qu'elle ne se vide. j'aurais besoin de stop le crawler pour continuer à vider la queue mais le probleme c'est que beaucoup d'appels sont bloquants, j'ai été oblige de recoder pas mal de methode (genre foreach). et là j'aurais besoin de copier en profondeur l'objet courant, c'est d'une difficulte sans nom en js pour peu que l'objet soit un peu complexe.

soit c'est moi qui suis trop imprégné de ce qui se fait en cpp (et que je ne bite donc rien au fonctionnement de javascript), soit y'a des problemes qui ne peuvent pas être résolus en nodej. j'pense que je vais reserver mon utilisation de node pour d'autres projets genre des panels ce genre de truc.

Le 27 février 2020 à 12:17:25 20_cent_2017 a écrit :

Le 27 février 2020 à 10:49:48 wowisclassic a écrit :
J'avais besoin de le dire, c'est vraiment de la merde, une gestion calamiteuse des objets, rien que deepcopy un objet faut avoir fait bac+5 haxxor, pas de mulithreading, l'asynchrone pourri à coup de settimeout partout dans ton code

go next

mauvais dev ...

d'accord charles henry

alors c'est vrai qu'il y a un tas de libs qui pourraient m'aider, on m'en a cité quelques uness (lodash par ex), mais franchement ça me saoule d'avoir à faire grossir mon node_module pour des choses que je considère elementaires.

Le 27 février 2020 à 12:32:06 mov_eax_0 a écrit :
c'est le langage que j'apprécie le moins en vanilla, je trouve ça brouillon, expérimental mais bon je travaille quand même dessus.

d'accord là dessus

après y'a de bons trucs, j'trouve vraiment que v8 est un petit bijou, j'aime bien l'ecosystem nodejs en general mais là c'est trop, je me sens excessivement limité par son usage.

donc disais je, le probleme en fait c'est que js ne supporte pas le multithreading et on essaie d'emuler quelque chose de semblable en délayant avec settimeout, c'est vrai que ça n'a pas directement à voir avec les promises, mais ça à voir avec le crawler que je developpe en ce moment ; j'ai besoin de gerer une queue, de la remplir d'une part et de la vider d'une autre. j'ai des problemes de memoire, parce que la queue se remplit plus vite qu'elle ne se vide. j'aurais besoin de stop le crawler pour continuer à vider la queue mais le probleme c'est que beaucoup d'appels sont bloquants, j'ai été oblige de recoder pas mal de methode (genre foreach). et là j'aurais besoin de copier en profondeur l'objet courant, c'est d'une difficulte sans nom en js pour peu que l'objet soit un peu complexe.

Ok je vois, effectivement c'est p-e pas avec le js que tu auras le plus d'efficacité sur ce sujet
Dans ce cas la tu vas p-e devoir faire un petit micro-service dans un autre langage pour cette feature en particulier ?

Le 27 février 2020 à 12:32:06 mov_eax_0 a écrit :
c'est le langage que j'apprécie le moins en vanilla, je trouve ça brouillon, expérimental mais bon je travaille quand même dessus.

Je suis totalement d'accord avec ça, je trouve que le JS c'est très bien mais ça demande beaucoup de rigueur pour avoir quelques choses de solide

soit c'est moi qui suis trop imprégné de ce qui se fait en cpp (et que je ne bite donc rien au fonctionnement de javascript), soit y'a des problemes qui ne peuvent pas être résolus en nodejs

ya un peu des deux je pense.

multithreading et on essaie d'emuler quelque chose de semblable en délayant avec settimeout

Non, oublie le multithreading avec javascript, faut penser asynchrone et event loop. Si tu veux paralléliser des traitements tu peux lancer deux instances de ton programme avec des paramètres différents et un socketio / redis pour communiquer.

Apres pour ton probleme specifiquement, j'irai voir du côté des streams ou de la lib rxjs qui permet de faire du backpressure

Hello,
je code beaucoup sur JS, moi aussi je trouve que c'est de la grosse bonne daube mais je vais te donner quelques astuces.
Utilise TYPESCRIPT dès que tu le peux.
Pour ta copie d'objet des fois il y a pas plus efficace que :
var objCopy=JSON.parse(JSON.stringify(objOriginal));

Ta pas choisie le bon langage ....

Je te laisse méditer dessus ...js c'est pour de la manipulation du dom hein ....

Go python, go go .....voir c

Le 27 février 2020 à 12:47:00 UndeadMarston6 a écrit :

donc disais je, le probleme en fait c'est que js ne supporte pas le multithreading et on essaie d'emuler quelque chose de semblable en délayant avec settimeout, c'est vrai que ça n'a pas directement à voir avec les promises, mais ça à voir avec le crawler que je developpe en ce moment ; j'ai besoin de gerer une queue, de la remplir d'une part et de la vider d'une autre. j'ai des problemes de memoire, parce que la queue se remplit plus vite qu'elle ne se vide. j'aurais besoin de stop le crawler pour continuer à vider la queue mais le probleme c'est que beaucoup d'appels sont bloquants, j'ai été oblige de recoder pas mal de methode (genre foreach). et là j'aurais besoin de copier en profondeur l'objet courant, c'est d'une difficulte sans nom en js pour peu que l'objet soit un peu complexe.

Ok je vois, effectivement c'est p-e pas avec le js que tu auras le plus d'efficacité sur ce sujet
Dans ce cas la tu vas p-e devoir faire un petit micro-service dans un autre langage pour cette feature en particulier ?

Sûrement oui, mais ça m'emmerde voir une techno qui propose pouvoir gérer toute la stack et finalement n'assure même pas la moitié de ce qu'elle propose.

Le 27 février 2020 à 12:32:06 mov_eax_0 a écrit :
c'est le langage que j'apprécie le moins en vanilla, je trouve ça brouillon, expérimental mais bon je travaille quand même dessus.

Je suis totalement d'accord avec ça, je trouve que le JS c'est très bien mais ça demande beaucoup de rigueur pour avoir quelques choses de solide

Cette pseudo rigueur est particulière à js alors

Le 27 février 2020 à 14:23:07 dark_drow a écrit :

soit c'est moi qui suis trop imprégné de ce qui se fait en cpp (et que je ne bite donc rien au fonctionnement de javascript), soit y'a des problemes qui ne peuvent pas être résolus en nodejs

ya un peu des deux je pense.

je pense aussi

multithreading et on essaie d'emuler quelque chose de semblable en délayant avec settimeout

Non, oublie le multithreading avec javascript, faut penser asynchrone et event loop. Si tu veux paralléliser des traitements tu peux lancer deux instances de ton programme avec des paramètres différents et un socketio / redis pour communiquer.

Apres pour ton probleme specifiquement, j'irai voir du côté des streams ou de la lib rxjs qui permet de faire du backpressure

je vais tout recoder en python

Le 27 février 2020 à 14:33:10 boucif a écrit :
Hello,
je code beaucoup sur JS, moi aussi je trouve que c'est de la grosse bonne daube mais je vais te donner quelques astuces.
Utilise TYPESCRIPT dès que tu le peux.
Pour ta copie d'objet des fois il y a pas plus efficace que :
var objCopy=JSON.parse(JSON.stringify(objOriginal));

ce hack ne fonctionne pas pour des objets avec des methodes. Ce qui est quand même assez courant.

class C {
    constructor() {
        this.hi ="hi";
    }

    sayHi() {
        console.log(this.hi)
    }

}

let obj = new C();
let obj_dump = JSON.parse(JSON.stringify(obj));

obj.sayHi()// works
obj_dump.sayHi() // not a function

Le 27 février 2020 à 16:05:06 Viking2Lyon a écrit :
Ta pas choisie le bon langage ....

Je te laisse méditer dessus ...js c'est pour de la manipulation du dom hein ....

Go python, go go .....voir c

cf les promesses de node

Node. js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.

je vais tout recoder en python

Attention, Python n'est pas non plus l'idéal pour du multithreading (GIL lock).

Ouais, je dois dire que je ne suis pas un grand fan de javascript non plus. C'est specifie bizarrement comme langage. Et c'est pas adapte au genre de chose que OP cherche a faire.
Faire un systeme producer/consumer c'est vraiment le boulot de langage comme C++, Go, ou Rust.

Le modele de parallelisme de Go ou Rust ont ete concu pour faire du producer/consumer. Mais ca s'ecrit tres bien en C++ aussi.

je vais tout recoder en python

Ouai autant rester sur node alors

Ah oui effectivement tu veux cloner l'objet avec ses méthodes, que le clone JS c'est souvent que les propriétés qui sont clonés ...

Le 27 février 2020 à 17:09:41 dark_drow a écrit :

je vais tout recoder en python

Ouai autant rester sur node alors

attendez mon topic "Python, c'est pourri"
non au jython !

Le 27 février 2020 à 17:02:01 godrik a écrit :
Ouais, je dois dire que je ne suis pas un grand fan de javascript non plus. C'est specifie bizarrement comme langage. Et c'est pas adapte au genre de chose que OP cherche a faire.
Faire un systeme producer/consumer c'est vraiment le boulot de langage comme C++, Go, ou Rust.

Le modele de parallelisme de Go ou Rust ont ete concu pour faire du producer/consumer. Mais ca s'ecrit tres bien en C++ aussi.

il me manquait ce terme de producer, consumer, merci beaucoup
j'ai été faire un peu de lecture, j'ai peut etre une implémentation à proposer

Le 27 février 2020 à 17:13:48 boucif a écrit :
Ah oui effectivement tu veux cloner l'objet avec ses méthodes, que le clone JS c'est souvent que les propriétés qui sont clonés ...

ça ça m'embête vraiment pour le coup

Le 27 février 2020 à 16:51:48 tsez93 a écrit :

je vais tout recoder en python

Attention, Python n'est pas non plus l'idéal pour du multithreading (GIL lock).

En l'occurence, j'ai l'impression qu'il veut faire des thread pour avoir de la concurrent, pas du parallelisme. Du coup, le GIL n'est peut etre pas un probleme.

Le 27 février 2020 à 17:26:49 godrik a écrit :

Le 27 février 2020 à 16:51:48 tsez93 a écrit :

je vais tout recoder en python

Attention, Python n'est pas non plus l'idéal pour du multithreading (GIL lock).

En l'occurence, j'ai l'impression qu'il veut faire des thread pour avoir de la concurrent, pas du parallelisme. Du coup, le GIL n'est peut etre pas un probleme.

faudra faire avec de toute façon