Contenu | Rechercher | Menus

Annonce

DVD, clés USB et t-shirts Ubuntu-fr disponibles sur la boutique En Vente Libre

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#2276 Le 23/12/2014, à 15:28

grim7reaper

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

Y’en a qui ont jeté un œil à Rust ?
Perso je trouve que le langage a pas mal de points super intéressants :
- enfin un langage qui met le concept d’ownership au cœur du langage
- la gestion de mémoire par région (comme Cyclone ou les version temps-réel du GC de Java)
- les types genre Option/Result + pattern matching
- Cargo (pas trop joué avec, mais semble sympa au premier abord)

Et malgré cela, il reste bas-niveau, runtime optionnel et suit la philosophie du zero-cost abstraction.
Pour le moment, j’ai lu le guide + 2-3 autres documents et bidouillé un peu avec mais j'attends la v1 avant de faire des trucs sérieux.

Bon il lui manque quand même des trucs plus ou moins dispensable (genre memory pool (me semble difficile à intégrer au langage cela dit)), aucun langage n’est parfait.

Hors ligne

#2277 Le 23/12/2014, à 18:53

The Uploader

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

J'avoue que Rust a l'air sympa comme un remplaçant crédible du C.
Le top serait d'avoir une norme ISO une fois que le langage sera un minimum stabilisé.

Dernière modification par The Uploader (Le 23/12/2014, à 18:54)


- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4800 SE, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster 16 ISA PnP, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10

Hors ligne

#2278 Le 24/12/2014, à 11:24

grim7reaper

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

The Uploader a écrit :

J'avoue que Rust a l'air sympa comme un remplaçant crédible du C.

Du C mais aussi du C++.

The Uploader a écrit :

Le top serait d’avoir une norme ISO une fois que le langage sera un minimum stabilisé.

Je ne sais pas si Mozilla veut se lancer là dedans, à voir… C’est un investissement quand même, et ça rend les évolutions plus lente.
Ruby l’a fait parce que c’était une condition pour que ça puisse être utilisé par le gouvernement ou les administrations japonaise il me semble.

Y’a assez peu de langage standardisé ISO au final (enfin dont les évolutions sont « régulièrement » standardisé comme C, C++ et Ada par exemple)
Si on compte tout les les langages standardisé ISO même une seule fois, y’en a un peu plus:

Hors ligne

#2279 Le 24/12/2014, à 14:39

The Uploader

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

Tiens j'ai aussi une question : quelqu'un a déjà testé QML ? C'est bien comparé au XAML ? (je pense surtout aux multiples types de panels : StackPanel, WrapPanel, Canvas, Grid, DockPanel ..., au DataBinding, aux Commandes, et aux DataTemplate, aux ControlTempltate, ainsi qu'à la localization - bien que j'utilise surtout parce que c'est plus pratique la WPF Localization Extension -, ainsi qu'aux Behaviors et à la validation).

Bon déjà j'ai noté que c'était largement moins verbeux, ce qui est LE point noir du XAML, malgré toutes ses qualités.

Enfin bref je veux surtout pas revenir aux évènements avec la couche présentation fortement liée au reste. Et les DataTemplate ça permet de dire "pour ce type, on va utiliser cette affichage" (on peut en abuser, c'est à dire ne faire QUE des DataTemplate pour l'UI, mais c'est pas la faute de WPF...).

Je trouve aucun bon bouquin dessus, et très peu de documenation sur le Web (d'ailleurs dans l'idéal ce serait plus une application s'appuyant sur le KDE Framework 5 qu'une application Qt pure : ça devrait pouvoir s'intégrer à KDE 5 - notamment utiliser le dialogue d'ouverture de fichier de KDE sous KDE et non celui de Qt -, mais aussi à Windows 7 et ses JumpLists).
Alors que sur WPF, j'ai WPF 4.5 Unleashed qui est très bien fait.

Le but serait de me refaire un front-end pour DOSBox, mais multiplateforme cette fois (bon par contre pour le développement, j'ai bien essayé Netbeans/Eclipse/whatever plutôt que Visual Studio mais à chaque fois c'est trop limité ou trop instable. Le seul truc que j'ai pas vraiment essayé c'est KDevelop).

Dernière modification par The Uploader (Le 24/12/2014, à 14:48)


- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4800 SE, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster 16 ISA PnP, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10

Hors ligne

#2280 Le 24/12/2014, à 15:12

grim7reaper

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

The Uploader a écrit :

Tiens j'ai aussi une question : quelqu'un a déjà testé QML ?

Nope.
Je fais déjà rarement des interfaces graphiques, et quand j'en fait c'est tellement simpliste que le faire « à l’ancienne » me suffit.

The Uploader a écrit :

Je trouve aucun bon bouquin dessus

Apparemment Créer des applications avec Qt 5 traite beaucoup de QML et QtQuick.

The Uploader a écrit :

(bon par contre pour le développement, j'ai bien essayé Netbeans/Eclipse/whatever plutôt que Visual Studio mais à chaque fois c'est trop limité ou trop instable. Le seul truc que j'ai pas vraiment essayé c'est KDevelop)

Ha ouais ?
À chaque fois que j'ai du utiliser Visual Studio, le truc que j'ai toujours pensé c'est : « y’a des gens qui payent pour ça ?! »
Mais bon, j'étais peut-être tombé sur des versions de merde…

Hors ligne

#2281 Le 24/12/2014, à 16:11

The Uploader

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

La version Express est merdique, mais en gratuit et officiel t'as maintenant la version Community (VS 2013 Community Edition with Update 4 pour être exact) ce qui correspond à la version premium si j'ai bien compris (bref le truc juste en dessous de la version ultimate). Parmi les évolutions notables -> ça prend en charge git nativement (même si je préfère toujours commiter en ligne de commande avec msysgit).

Avec Nunit pour les tests unitaires, CodeMaid pour nettoyer les fichiers à la sauvegarde, (et ReSharper pour ceux qui veulent étendre les capacités de refactoring de VS et qui ont des sous), c'est pas mal. smile

Bon niveau libre un collègue m'a conseillé Eclipse... Faudrait que je regarde de nouveau... Mais je lorgne plutôt du côté de KDevelop, surtout quand ce dernier sera passé à KF5.


- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4800 SE, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster 16 ISA PnP, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10

Hors ligne

#2282 Le 26/12/2014, à 18:32

grim7reaper

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

The Uploader a écrit :

La version Express est merdique, mais en gratuit et officiel t'as maintenant la version Community (VS 2013 Community Edition with Update 4 pour être exact) ce qui correspond à la version premium si j'ai bien compris (bref le truc juste en dessous de la version ultimate). Parmi les évolutions notables -> ça prend en charge git nativement (même si je préfère toujours commiter en ligne de commande avec msysgit).

Avec Nunit pour les tests unitaires, CodeMaid pour nettoyer les fichiers à la sauvegarde, (et ReSharper pour ceux qui veulent étendre les capacités de refactoring de VS et qui ont des sous), c'est pas mal. smile

mkay, très orienté C# tout ça…
Bon, de toute façon je suis clairement pas ciblé par VS vu que c'est du Windows-only (et que je n’utilise Windows ni à la maison, ni au boulot).

The Uploader a écrit :

Bon niveau libre un collègue m'a conseillé Eclipse... Faudrait que je regarde de nouveau... Mais je lorgne plutôt du côté de KDevelop, surtout quand ce dernier sera passé à KF5.

KDevelop à ses côtés sympa en effet (support de CMake en natif par exemple).

Hors ligne

#2283 Le 31/12/2014, à 17:14

Elzen

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

Dites, les gens, j'me demandais…

un clavier virtuel, ça fonctionne en générant de faux événements X pour simuler l'appui sur des touches réelles, ou bien il existe un autre moyen d'envoyer du texte vers une application donnée ?

Je pensais créer une petite appli susceptible d'émuler le ctrl+shift+U sur les applications non-GTK, et potentiellement même de le remplacer sur les applis GTK, en rajoutant quelques fonctionnalités (visualisation du caractère avant insertion, recherche par nom, éventuellement caractères fréquents…), mais il faudrait un moyen générique d'insérer le caractère dans l'appli, et ce n'est pas forcément évident…

Potentiellement, je pourrais faire ça en squattant un presse-papier (PRIMARY + clic milieu, ça doit se gérer assez bien), mais ça ne me paraît pas le moyen le plus propre de procéder.

Hors ligne

#2284 Le 01/01/2015, à 11:07

grim7reaper

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

Elzen a écrit :

Dites, les gens, j'me demandais…

un clavier virtuel, ça fonctionne en générant de faux événements X pour simuler l'appui sur des touches réelles, ou bien il existe un autre moyen d'envoyer du texte vers une application donnée ?

J’ai l’impression que ça passe très souvent par X en effet.
xvkbd, onboard et kvkbd font tous appel à XTestFakeKeyEvent.
Le seul qui sort du lot c’est GOK en utilisant SPI_generateKeyboardEvent.

Du coup, pour Wayland je sais pas trop comment ça va se passer. J’ai cru comprendre qu’il fallait passer par wl_input_method_context_commit_string (mais j’ai pas vraiment trouvé de doc à par ça…)
À la limite, faut regarder le code d’ibus car on dirait qu’il a eu un patch pour le support de Wayland.

Hors ligne

#2285 Le 01/01/2015, à 20:20

Elzen

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

Merci pour les infos (tu connaissais plus de claviers virtuels que moi ^^) et pour le coup de main sur le fichier UnicodeData.

J'ai opté, dans l'immédiat, pour SPI_generateKeyboardEvent : ça semble bien marcher (mieux que XTestFakeKeyEvent que je n'avais pas réussi à faire marcher comme ça les précédentes fois où j'avais essayé). Pour la compatibilité avec Wayland, on verra quand j'attaquerai la vers Python3/Qt.

Du coup, l'outil est codé et intégré à Touhy smile

Hors ligne

#2286 Le 01/01/2015, à 20:43

grim7reaper

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

Elzen a écrit :

Merci pour les infos (tu connaissais plus de claviers virtuels que moi ^^) pour le coup de main sur le fichier UnicodeData.

De rien wink
À la base je ne connaissais que kvkbd, c’est en cherchant que j’ai trouvé les autres.

Elzen a écrit :

J'ai opté, dans l'immédiat, pour SPI_generateKeyboardEvent

Attention : c’est fourni par le binding C AT-SPI qui semble en voie de dépréciation :

https://developer.gnome.org/at-spi-cspi/ a écrit :

This module is heading towards planned deprecation.

Hors ligne

#2287 Le 03/01/2015, à 16:19

Elzen

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

Je vais faire un peu de mauvais esprit, mais « en voie de » dépréciation, ça a l'air d'être plus pérenne que certains autres éléments utilisés ^^"

Il y a pas mal de choses que je ne saurais pas remplacer dans la version actuelle (à commencer par la libwnck, qui est le composant central des outils de l'environnement proprement dit), mais j'envisage de commencer à me pencher un peu plus sérieusement sur la version Python3/Qt pour le développement des applications : il y en a sûrement quelques unes que je peux recoder directement en version récente.

Ceci dit, de toute façon, ça dépendra du temps que j'aurai pour travailler là-dessus.

Hors ligne

#2288 Le 26/02/2015, à 00:02

grim7reaper

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

Tiens,aujourd’hui je suis tombé sur un article intéressant.

Stijn de Gouw & al. ont publié un article dans lequel ils tentent de prouver le bon fonctionnement de l’algorithme de tri Timsort (utilisé dans Python, puis dans Java) en utilisant des méthodes formelles (chose qui devrait être faite plus souvent, mais ce n’est pas toujours faisaible malheureusement et ça demande beaucoup plus de travail que de faire de simples tests) et au passage ils ont trouvé un bug (pas vraiment impactant en Python, mais facilement reproductible en Java).

Pour finir sur une note trollesque, je comprends pourquoi Java bouffe tant de mémoire maintenant. Quand on voit la réaction des dev’…

The reaction of the Java developer community to our report is somewhat disappointing: instead of using our fixed (and verified!) version of mergeCollapse(), they opted to increase the allocated runLen “sufficiently”. As we showed, this is not necessary. In consequence, whoever uses java.utils.Collection.sort() is forced to over allocate space. Given the astronomical number of program runs that such a central routine is used in, this leads to a considerable waste of energy.

Sinon, dans le même genre (mais plus ancien), encore une preuve que les overflow c’est le mal (même quand c’est pas UB comme en C et C++).
On devrait avoir plus de langages (surtout dans les nouveaux qui sortent) qui traitent les overflow comme des erreurs, comme Ada et Rust par exemple.

Hors ligne

#2289 Le 07/04/2015, à 13:05

The Uploader

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

Très intéressant. Merci Grim' smile

grim' a écrit :

On devrait avoir plus de langages (surtout dans les nouveaux qui sortent) qui traitent les overflow comme des erreurs, comme Ada et Rust par exemple.

J'ai du mal à voir la nouveauté. Java et C# renvoient une exception. C'est ce dont tu parles ?

Je suis tombé là dessus aujourd'hui, comme ici on désigne souvent Automake comme Autohell j'étais curieux de savoir le retour :
Switch from CMake to Autotools

Bon perso je n'utilise ni CMake ni Autotools...



Édit: désolé The Uploader, j’ai modifié ton message au lieu de le citer >_< (j’espère que je l’ai restauré correctement)

Dernière modification par grim7reaper (Le 07/04/2015, à 16:19)


- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4800 SE, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster 16 ISA PnP, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10

Hors ligne

#2290 Le 07/04/2015, à 16:20

grim7reaper

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

Bon, cette fois voilà ma réponse ^^"

The Uploader a écrit :

Très intéressant. Merci Grim' smile

grim' a écrit :

On devrait avoir plus de langages (surtout dans les nouveaux qui sortent) qui traitent les overflow comme des erreurs, comme Ada et Rust par exemple.

J'ai du mal à voir la nouveauté. Java et C# renvoient une exception. C'est ce dont tu parles ?

Java renvoie une exception en cas d’integer overflow ? Tu es sûr de ça ?
Il me semble que ça wrap silencieusement (par contre c’est défini, pas comme en C et C++ où tu as un undefined behavior).

Pour C# idem, rien par défaut (bon ça reste mieux que Java, C# à un mot-clef checked mais bon c’est pas par défaut : c’est la responsabilité du programmeur de l‘utiliser et je suppose que c’est rarement utilisé…).

En Rust et Ada, c’est par défaut (en Ada tu peux même définir des entiers limités (et bien plus encore)).
Ada est vraiment un super langage pour un truc aussi vieux (même s’il continue d’évoluer et de s‘enrichir, la plupart des bonnes idées était là depuis les débuts). Le Hibou en faisait vraiment une publicité déplorable…
Rust aussi est super intéressant (mais il est plus récent aussi, donc il peut directement partir dans les nouveauté sans s’encombrer de retro-compatibilité).

The Uploader a écrit :

Je suis tombé là dessus aujourd'hui, comme ici on désigne souvent Automake comme Autohell j'étais curieux de savoir le retour :
Switch from CMake to Autotools

Bon perso je n'utilise ni CMake ni Autotools...

En effet, la migration dans ce sens est plutôt rare.
Cela dit :
- Cmake peut avoir une target uninstall (c’est pas par défaut, c’est vrai)
- il est portable aussi (même sur Windows, alors que les autotools…) et il laisse le dev’ utiliser ce qu’il veux (ça te génère du Makefile, du fichier de projet Visual, CodeBlock, KDevelop, …)
- ça gère aussi la traduction (Rolinh l’a fait pour dfc) et la documentation (Doxygen c‘est quelques lignes dans ton CMakeList.txt).

Mais bon, CMake a ses défauts aussi, c’est bien vrai (mais l’article ne les aborde pas vraiment j’ai l’impression).

Dernière modification par grim7reaper (Le 07/04/2015, à 16:29)

Hors ligne

#2291 Le 08/04/2015, à 14:15

The Uploader

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

grim7reaper a écrit :

Bon, cette fois voilà ma réponse ^^"

The Uploader a écrit :

Très intéressant. Merci Grim' smile

grim' a écrit :

On devrait avoir plus de langages (surtout dans les nouveaux qui sortent) qui traitent les overflow comme des erreurs, comme Ada et Rust par exemple.

J'ai du mal à voir la nouveauté. Java et C# renvoient une exception. C'est ce dont tu parles ?

Java renvoie une exception en cas d’integer overflow ? Tu es sûr de ça ?

Oups. J'avais en tête ce cas : http://stackoverflow.com/questions/2642 … d-behavior
=> de UB on passe à une exception en Java et C# ( IndexOutOfRangeException en C#)

Mais pour l'integer overflow, le C# c'est pareil qu'en Java : http://stackoverflow.com/questions/2056 … r-int-in-c

By default, C# does not check for arithmetic overflow on integers. You can change this with the /checked compiler option or by enabling "Check for arithmetic overflow/underflow" in Visual Studio (project properties - Build - Advanced).

You can use checked and unchecked keywords to override the default on a case-by-case basis. If you rely on checking taking place in a piece of code, explicitly enabling it using checked would be a good idea.

int j = checked(i * 2);

checked
{
    int j = i * 2;
    // Do more stuff
}

Note that floating point operations never throw an OverflowException, and decimal operations always throw an OverflowException. See also C# operators.

grim7reaper a écrit :

En effet, la migration dans ce sens est plutôt rare.
Cela dit :
- Cmake peut avoir une target uninstall (c’est pas par défaut, c’est vrai)
- il est portable aussi (même sur Windows, alors que les autotools…) et il laisse le dev’ utiliser ce qu’il veux (ça te génère du Makefile, du fichier de projet Visual, CodeBlock, KDevelop, …)
- ça gère aussi la traduction (Rolinh l’a fait pour dfc) et la documentation (Doxygen c‘est quelques lignes dans ton CMakeList.txt).

Mais bon, CMake a ses défauts aussi, c’est bien vrai (mais l’article ne les aborde pas vraiment j’ai l’impression).

Intéressant. S'il faut choisir en Autotools et CMake pour un projet Qt, je prendrais CMake.

Dernière modification par The Uploader (Le 08/04/2015, à 14:20)


- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4800 SE, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster 16 ISA PnP, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10

Hors ligne

#2292 Le 08/04/2015, à 21:10

grim7reaper

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

The Uploader a écrit :

Ouais, le bound-checking c’est assez standard de nos jours (et Ada le faisait déjà en 1983).
Ça commence même à arriver dans le hardware via Intel (mais bon, c’est lourd : il faut adapter le noyau, le compilateur, …).

The Uploader a écrit :

Intéressant. S'il faut choisir en Autotools et CMake pour un projet Qt, je prendrais CMake.

Il me semble que CMake s’utilise assez bien avec Qt (KDE est passé à CMake il me semble).

Hors ligne

#2293 Le 09/04/2015, à 15:09

The Uploader

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

Un truc intéressant sur linuxfr :

Genre, je veux que les bibliothèques s’installent dans /usr/lib64 et non dans /usr/lib (c’est l’option qui a été retenue pour Slackware64), quelle est l’option à utiliser ? Avec un projet autoconfisqué, ce sera toujours --with-libdir=/usr/lib64. Avec CMake, ce sera tantôt -DLIB_SUFFIX=64, tantôt -DWANT_LIB64, tantôt -DLIB_INSTALL_DIR=/usr/lib64, tantôt -Dpackage_INSTALL_LIB_DIR (avec package dépendant du projet)…

Je veux installer les pages de manuel dans /usr/man au lieu de /usr/share/man ? Avec les autotools, ce sera toujours --with-mandir=/usr/man. Avec CMake, ce sera tantôt -DMAN_DIR=, tantôt -DMAN_INSTALL_DIR=, tantôt -Dpackage_MAN_PATH=…

Je veux changer le répertoire des fichiers de configuration ? Avec les autotools, ce sera toujours --with-sysconfdir=. Avec CMake ? Au choix, -DSYSCONFDIR=, -DSYSCONF_INSTALL_DIR=…

Je veux stripper les binaires à l’installation ? Avec les autotools, make install-strip, toujours. Avec CMake, parfois on peut faire make install/strip, et parfois non, il faut stripper à la main après.

Et je tape sur CMake, mais les 99 prétendus prétendants à la succession des Autotools ont le même problème.

Dès que je dois installer un logiciel à partir des sources (ce que je fais relativement fréquemment, puisque j’ai choisi d’utiliser une distribution qui fournit de base peu de paquets) et que je ne vois pas de configure dans l’archive, je pousse un soupir « purée, alors c’est quoi cette fois le système de build et c’est quoi les options à utiliser pour ce projet ? »

http://linuxfr.org/nodes/103718/comments/1597667

M'enfin bon je trouve ça un peu limite. J'installe rarement depuis le sources et l'endroit du man je m'en fiche un peu du moment qu’il est trouvé avec la commande man...

grim7reaper a écrit :

Ouais, le bound-checking c’est assez standard de nos jours (et Ada le faisait déjà en 1983).
Ça commence même à arriver dans le hardware via Intel (mais bon, c’est lourd : il faut adapter le noyau, le compilateur, …).

Ça me rappelle le kernel mode / user mode au niveau CPU. J'avais du mal à croire au début que ce soit globalisé, mais en fait c'est pas toujours implémenté niveau hardware, ça dépend de l'archi.

Dernière modification par The Uploader (Le 09/04/2015, à 15:09)


- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4800 SE, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster 16 ISA PnP, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10

Hors ligne

#2294 Le 21/05/2015, à 08:11

The Uploader

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

Game Developers Conference - Parallelizing the Naughty Dog Engine using Fibers
Ou comment le moteur de The Last of Us fut optimisé/reachitercturé pour arriver à 60 fps dans la version Remastered du jeu sur PS4. smile

Dernière modification par The Uploader (Le 21/05/2015, à 08:12)


- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4800 SE, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster 16 ISA PnP, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10

Hors ligne

#2295 Le 25/05/2015, à 15:47

grim7reaper

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

Ça semble intéressant mais y’a pas moyen d’avoir au moins les slides en PDF ?
La vidéo ne se lance même pas chez moi donc bon, dommage.

Édit : ha, c’est bon.
Bon bah je regarderais quand j’aurais le temps (j’ai les vidéos de Bret Victor à finir d’abord, pour le moment j’ai vu que « Stop Drawing Dead Fish »).

Dernière modification par grim7reaper (Le 25/05/2015, à 15:49)

Hors ligne

#2296 Le 02/06/2015, à 16:44

grim7reaper

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

The Uploader a écrit :

Game Developers Conference - Parallelizing the Naughty Dog Engine using Fibers
Ou comment le moteur de The Last of Us fut optimisé/reachitercturé pour arriver à 60 fps dans la version Remastered du jeu sur PS4. smile

Bon j’ai finalement trouvé du temps pour la regarder, la façon dont ils ont parallèlisés le moteur est intéressante.

Dans un autre genre, voici l’histoire d’un bug qui se fait remarquer à haut niveau mais dont l‘origine est très basse : « The discovery of Apache ZooKeeper’s poison packet »

Hors ligne

#2297 Le 07/06/2015, à 19:00

The Uploader

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

Content que ça t'ai intéréssé. smile

J'espère que la suite sera tout aussi intéressante :
Ça pourrait se nommer "dans les méandres du PC" mais en vrait ça s'appelle...
Porting Quake II sous DOS
Part 2
part 3
big_smile

grim7reaper a écrit :

Dans un autre genre, voici l’histoire d’un bug qui se fait remarquer à haut niveau mais dont l‘origine est très basse : « The discovery of Apache ZooKeeper’s poison packet »

Yép, je vais voir ça. J'ai pas eu le temps jusqu'ici. Merci. smile

Dernière modification par The Uploader (Le 07/06/2015, à 19:01)


- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4800 SE, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster 16 ISA PnP, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10

Hors ligne

#2298 Le 11/06/2015, à 09:25

grim7reaper

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

The Uploader a écrit :

Dans le même genre "Let's Compile like it's 1992" => Compilation du Wolfenstein 3D de 1992 sous DosBOX avec Borland C++ 3.1.

Hors ligne

#2299 Le 11/06/2015, à 12:50

The Uploader

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

lol

Génial ! Merci. smile

Je voulais justement m'essayer à la création d'un jeu DOS ^^


- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4800 SE, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster 16 ISA PnP, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10

Hors ligne

#2300 Le 12/06/2015, à 08:46

grim7reaper

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

Quel de genre de jeux ?
Tu vas faire ça en C du coup, non ?
T’as pas trop perdu la main avec tout ton C# récemment (Brace Yoursef SEGFAULT is Coming) ? tongue

Hors ligne