perso j'ai deja parlé et listé haxe a coté d'autre technos plus haut pour Tamarin, ce que tu ne comprends pas c'est que la VM de Flash/AIR donc le projet est updaté avant que les updates arrivent dans Flash/AIR par ex les worker on les a dans Tamarin, bref on peut pas dire que c'est abandonné.
Le mardi 4 décembre 2012 09:55:38 UTC, shoe[box] a écrit : > > oO > > Perso je pensais que l'on faisais une discussion constructive pour "un > bilan de 2012" concernant la flash plateforme et les alternatives. > La ce que tu fais c'est camper sous tes position. > > Je n'ai jamais été vindicatif ( comme toi ), ni imposé Haxe, j'ai bien > précisé à plusieurs reprise que c'est mon ressenti et ma solution pour mon > cas perso, et je la partage car c'était le but de cette discussion. > > Après c'est ton choix très bien si ça corresponds à tes besoins c'est > super. > > Mais pas mal de tes propos m'ont fait un peu halluciner: > > - ignorer l'iPad 1 ??? 60% des tablettes Apple. > > - Si tu avais regardé correctement et avec impartialité tu te serai rendu > compte que l'API filesystem est ici : > http://www.haxenme.org/api/types/sys/io/File.html. > C'est un mirroir de la classe File de CPP difficile de faire plus > complet... > > - "*mon bench il est tres simple, a chaque fois, mais vraiment a chaque > fois, qu'on parle de AS3/AIR/Flash Platform/Tamarin...* (...)" ??? > C'est ça tes arguments ? Tu te rends bien compte que c'est exactement les > arguments que tu m'a servis pour dénigrer Haxe. > > - Tamarin : tu doit être le seul dev dessus, et coté Mozzila ça a pas été > mis a jour depuis 2008.... donc.... mort ( soyons réaliste ). > > etc. > > Après c'est ton choix très bien, perso je n'impose rien contrairement à > toi. > > // > > Le mardi 4 décembre 2012 01:07:32 UTC+1, zwetan a écrit : >> >> mouais >> >> alors point par point >> >> je sais pas comment tu as programmé ton jeu mais sous iPad 1, forcément y >> a pas bcp de ressources >> a la sortie de AIR 3.1 , iPad 2 etait sorti depuis longtemps, viser iPad >> 1 c'est etre un peu maso >> ou alors vraiment tres bien gerer la memoire et se metttre en rendering >> GPU et faire du blitting >> Starling sous iPad 1 par contre roulle tres bien >> >> le ralentissent relié au Touch j'ai jamais vu ca, mais bon a nouveau sous >> mobile/tablet il faut tres bien gerer >> la memoire, specialement avec les events oui meme les natifs >> >> memoire limitee a cause de la machine virtuelle ... je dirais on s'en >> fout si tu geres bien ta memoire, >> ici on a des grosse app iOS qui consomme 1MB de memoire en idle, max 16MB >> en utilisation >> les meme app sans bien gerer la memoire ca part tres vite en couille avec >> memory leak etc. >> >> tester iOS en passant par iTunes pas de soucis, ca s'automatise meme >> avant AIR 3.4 qui permet >> de passer par du debug USB ou l'emulateur, ah oui forcément si tu build >> tout a la main ca fait long a chaque fois >> >> la limite OTA est passé a 50MB avec iOS 5 qui etait dispo au moment de >> AIR 3.1, >> note tu as la meme limite de 50MB avec Android, comme n'importe quelle >> app il faut gerer les ressources, >> a nouveau ici on gere de apps qui peuvent synchroniser de 500MB at 6GB de >> donnees (oui 6GB je deconne pas) >> >> le nombre de devices limités euh regarde les stats, sous Android AIR peut >> cibler dans les 90% ou plus >> et iOS avec les vieux devices etant automatiquement non-supporté par >> Apple ca revient a peu pres au meme, >> bref supporté ARM v6 c'est comme dire que tu voudrais supporter un PC >> DX386 aujourd'hui... >> >> si tu veux en dev mobile il faut pas s'attendre a ce que ce soit comme >> sous desktop ou sur le browser tournant sur le desktop, il faut faire 300% >> plus d'effort pour la gestion et l'allocation des ressources, juste charger >> une image avec la class Loader, si les events ne sont pas bien nettoyés de >> la memoire ca cree du memory leak, et sous un iPad 1 avec 256MB de RAM ca >> part tres tres tres vite en sucette >> >> c'est simple tous les gens que je vois se plaindre de AIR et en >> particulier en dev iOS, >> c'est quand ils dev a peu pres leur 1ere app mobile et que l'OS force la >> fermeture de l'appli >> car elle consomme trop de memoire >> >> Qd tu dis que molehill (euh Stage3D hein c'est plus en beta depuis >> longtemps) ca ameliore un peu les choses, >> désolé mais c'est risible, Stage3D ameliore ENORMEMENT les choses, c'est >> sur ca change de la programmation >> display list mais ca va extremement plus vite meme sous un vieux iPad 1 >> ou iPhone 3GS >> >> oui OK des fois il faut attendre un update AIR pour regler qlqs soucis >> sur des nouveaux devices mais >> tu vois pour le Nexus 7, des le 1er jour sans update AIR j'ai pu mettre >> des apps AIR dessus sans grand soucis >> (j'avais un Nexus 7 des le 1er aout) >> >> bcp de gens se plaignent de ANE, perso je prefer avoir ANE que rien du >> tout, >> ah oui c'est plus compliqué, mais ca donne la liberté d'étendre comme on >> veut >> et de mon point de vue c'est tres proche de la production de classes >> natives avec Tamarin, >> je trouve ca pratique et puissant. >> >> Pour tes multi-apk sous Android, tu sais que avec un seul jeu d'asset et >> un seul APK tu peux dynamiquement generer >> les assets pour pleins d'ecrans differents et/ou downloader ces assets, >> bref 10MB de machine virtuelle oui on s'en fout, >> ou en fait non on s'en fout pas on les veut, parce que ca nous donne tous >> les API Flash/AIR et des trucs sympa comme >> le P2P (qui est genial pour synchroniser des assets) >> >> pour le coté Adobe, je pense que tu as manqué une étape, >> Adobe crees des outils HTML5 et abandonné le player Flash pour mobile >> mais ils n'ont pas supprimés de dev AIR, au contraire ils font des updates >> reguliers (AIR 3.0, 3.1, 3.2, 3.3, 3.4, 3.5 etc.) >> >> regarde ca >> http://www.businessinsider.com/future-of-digital-slides-2012-11 >> >> ce slide en particulier >> http://www.businessinsider.com/future-of-digital-slides-2012-11#-106 >> >> sur mobile les gens veullent des apps pas des web apps, >> on s'en fout qu'il n'y ait pas de plugin flash pour mobile on a AIR >> >> >> et je finirais juste sur >> "moults tests et benchmarks de plusieurs technos que Haxe NME est >> largement sortis du lot." >> >> mouais bah on doit pas avoir les meme tests et benchmarks >> >> mon bench il est tres simple, a chaque fois, mais vraiment a chaque fois, >> qu'on parle de AS3/AIR/Flash Platform/Tamarin >> il y a toujours un mec pour venir te dire que ouhlala tu devrais utiliser >> Haxe parce que c'est bien plus mieux >> on lui reponds "non on est pas intéressé", tu vois on lui dit meme pas >> que Haxe c'est de la bouse >> ou que c'est pas joli, on est juste pas intéressé, bah le mec apres il >> continu on sortant >> que AS3/AIR/Flash Platform/Tamarin/etc. (tous les trucs qui nous >> interesse) >> c'est de la bouse et que haxe c'est bien plus mieux >> >> et ca me soule grave >> >> donc OK comparons, je sais pas, par ex l'API FileSystem >> >> http://www.haxenme.org/api/types/sys/FileSystem.html >> http://www.haxenme.org/api/types/nme/filesystem/File.html >> Haxe NME FileSystem API est moins bien et moins complet que >> >> >> http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/filesystem/package-detail.html >> le AIR FileSystem API qui est moins bien et moins complet que >> >> http://code.google.com/p/redtamarin/wiki/FileSystem >> le redtamarin FileSystem API >> >> comme quoi un produit de niche qui a l'air moribond et voir deja mort >> ca fait un peu mieux que ton tres cher Haxe NME >> >> zwetan >> >> Le dimanche 2 décembre 2012 22:18:18 UTC, shoe[box] a écrit : >>> >>> >>> Yop Eka :) >>> >>> Que exemples de problèmes ( sur de nombreux ) que j'ai connu fin d'année >>> dernière ( Air 3.1 je pense de mémoire sans Stage3D ) sur un jeu très >>> simple: >>> >>> - Coté ralentissement, par exemple sous iPad 1, mon app perdait 20 a >>> 30fps si le navigateur web ( safari ) de l'iPad était ouvert ( bug >>> mystère >>> soumis à Adobe ) >>> - Ralentissement lié au Touch par exemple, dès que ton doigt se >>> déplace tu perds 20fps ( et sans bubbling... et un controle des >>> mouseenabled ) >>> - Mémoire limitée par l'utilisation de la mémoire par la machine >>> virtuelle ( lance un profiler de mémoire sous ton iPad et regarde la >>> mémoire utilisée par une appli vide vs une appli Air vide ). >>> - Le process de test sous iOS par exemple était ingérable ( passer >>> par iTunes... ) en développement ( même si je sais ils ont enfin corrigé >>> le >>> tir ) >>> - Même si maintenant la limite des 20Mo en 3G a été levée on atteint >>> rapidement les 50Mo avec une appli universelle si il faut compter >>> 10-15Mo >>> de machine virtuelle.. >>> - Un nombre de devices / OS ciblables limité par les besoins de la >>> machine virtuelle. Perso j'ai envie de cibler un maximun de devices et >>> d'OS >>> ( même du vieu ARMV6, du blackberry... ) pour faire un max de ventes. >>> >>> ( ... ) >>> >>> J'avais fait un post sur mon blog ( que j'ai tenté de ressuciter ) début >>> d'année qui en parlais : http://www.shoe-box.org/blog/?p=19 >>> >>> Coté performance, soyons francs Molehill et les dernières version de AIr >>> ont un peu amélioré les choses ( pour précision je suis dans la prerelease >>> de MoleHill depuis quasi le début et j'ai bien pu en tâter l'évolution ), >>> mais reste encore pas mal de problèmes pour moi. >>> Le fait que Adobe a voulu faire différents des autre avec l'AGAL au lieu >>> d'utiliser des shader opengl comme tout le monde... >>> Les nombreux problèmes sous Android. >>> Le wmode direct qui est pas supporté sur 50% des machines avec flash >>> player... >>> La gestion des extensions native sous AIR qui est bien trop complexe >>> pour un truc aussi simple... >>> Le délai d'attente entre la sortie d'un nouveau device et sa >>> compatibilitée avec AIR ( exemple : iPad Mini, iPhone5 , nexus 7 ) >>> >>> Et de toute façon si on me demande de la 3D sur mobile, perso je n'irai >>> pas sur AIR mais sur Unity qui pour moi est bien plus stable / puissant / >>> performant sur mobile, et est fait pour cela. >>> >>> Quand tu parle de 10Mo de machine virtuelle c'est pas grand chose, >>> j'ignore si tu a vendu sur des stores, mais 10-15Mo de différence c'est >>> énorme (surtout si tu a 40Mo d'assets), énormément de plaintes et mauvais >>> commentaires prennent source dans le poids de ton application. >>> Surtout lorsque la personne n'a que 256Mo de stockage par exemple. >>> Et le commentaire reste le nerf de la guerre si tu veux ressortir sur >>> les stores. >>> * >>> Coté haxe :* >>> >>> Perso je fait du jeu sur mobile & tablettes ( souvent des apps >>> universelles avec multi-apk coté android ), et c'est après de moults tests >>> et benchmarks de plusieurs technos que Haxe NME est largement sortis du lot. >>> Perso je suis ouvert à toute nouvelle techno qui permettra de remplir >>> mes besoins de performance et de stabilités et de multi devices et >>> aujourd'hui une seule permet de remplir mes attentes. >>> >>> J'ignore ou tu a vu cela, mais Haxe2 n'est pas du tout basé sur l'AS2, >>> c'est de l'AS3 avec des features supplémentaires ( dont certains ont >>> commencé a être ajoutées au player flash : inlining, typage fort...), et >>> Haxe évolu bien plus vite que l'AS3 ( Haxe 3 est en béta ) >>> Après j'ignore pourquoi Haxe fait peur aux devs flash, qui ont pleins >>> d'aprioris sur le sujet ( compliqué, trop différent de l'AS3, sert a >>> rien... ) alors que ce sont bien souvent que des clichés, surtout avec NME. >>> >>> Après tu parle de coder en C++, lorsque tu utilise Haxe tu te rends pas >>> compte mais c'est bien ce que tu fait, car cela génére un project c++ : >>> Donc oui tu code en C sans le savoir. >>> Perso j'ai trouvé une évolution très intéressante dans mon métier >>> d'évoluer vers le C++ / Java / ObjectiveC pour coder une extension native. >>> Je suis pas un pro coder dans ces langages, mais je peut remplir >>> facilement mes besoins si l’extension n’existe pas déjà. >>> >>> Aprés tu me fait sourire en parlant de Tamarin, mais c'est un produit de >>> niche.. qui intéresse bien peut de devs, et qui selon mon ressenti à l'air >>> moribond ( voir déjà mort ). >>> >>> *Coté Adobe:* >>> Soyons francs coté Adobe ( de l'aveu même de l'équipe dirigeante ), >>> flash est le passé, même si j'ai adoré flash ( et que je l'aime encore >>> beaucoup pour sa simplicité ( dieu que je regrette l'époque du proto ) ) il >>> faut être réaliste : ça sent la fin. >>> De nombreux développeurs du flash player et AIR ont été supprimé coté >>> Adobe , et toute l'équipe de développement à été réduite comme peau de >>> chagrin >>> Adobe mise sur le full HTML5 ( a tord à mon avis ) et va je pense peut à >>> peut étouffer dans l'oeuf AIR ( même si c'est que mon avis et qu'il >>> n'engage que moi ). >>> >>> >>> Je pense que l'ont est dans un métier ou il faut pas rester dans ses >>> pantoufles et savoir évoluer ( c'est même ce qui pour moi fait l'attrait du >>> métier ). >>> Perso j'ai connu des devs qui m'ont maintenu pendant des année que l'AS2 >>> - AS3 ne battra jamais l'AS1 et que le MVC ne sert toujours à rien qu'il >>> est mieux de tout coder dans une seule classe dans le fla.... >>> >>> Après c'est mon avis personnel, qu'il faut nuancer selon les besoins de >>> chacun... >>> >>> shoe[box] // >>> >>> >>> Le dimanche 2 décembre 2012 11:30:29 UTC+1, ekameleon a écrit : >>>> >>>> Hello :) >>>> >>>> Faudrait que tu sois plus précis quand tu parles de "ralentissement >>>> bizarre..." . Tu as compilé avec quelle version de AIR , avec Stage3D, >>>> etc. >>>> ? >>>> >>>> Pour moi on peut faire beaucoup de chose avec AIR reste à voir ce que >>>> tu entends par "aller plus vite" car pour comparer faut avoir un code >>>> identique et une architecture propre au final. >>>> >>>> Sinon faut arrêter de dire que Haxe c'est comme l'AS3... c'est faux. Il >>>> y a des outils différents et surtout c'est basé sur l'AS2 donc pas du tout >>>> pareil au niveau des possibilités du langage et de la façon >>>> d'architecturer >>>> le code. >>>> >>>> Qu'un développeur soit à l'aise pour coder avec Haxe c'est une chose. >>>> Maintenant dire que c'est presque pareil (tu dis "quelques différences >>>> mineur au niveau du code") c'est totalement faux... C'est différent, comme >>>> je JS.NET est différent du JS standard et de la norme ECMAScript >>>> standard. >>>> >>>> Ensuite dire qu'il y a une communauté énorme Haxe... pourquoi pas. >>>> Reste que c'est toujours pareil ... tiens je veux utiliser JQuery ou une >>>> autre library JS avec Haxe, tiens je veux utiliser tel framework AS3 en >>>> Haxe .. Quelqu'un peut la développer ? Alors oui c'est toujours possible >>>> de >>>> s'y mettre mais bon... Pour moi Haxe reste un langage de niche... il a sa >>>> valeur c'est certain mais faut arrêter de dire que c'est génial d'être >>>> dans >>>> un code de niche.. pour moi c'est pareil avec tous les langages que l'on >>>> voit en ce moment Dart, etc. Qui continuent à proposer une couche pour >>>> faire mieux que ce qui existe déjà mais au final pour faire ce que le le >>>> langage de base fait déjà... Si tu compiles avec Haxe du JS, dans la page >>>> HTML c'est toujours du JS qui sera interprété et quand tu compiles pour le >>>> FlashPlayer en Haxe c'est toujours une VM derrière... >>>> >>>> En gros tu veux faire un truc bas niveau sur le mobile ? Code en C++ ... >>>> >>>> Maintenant ce que dis au dessus Zwetan est très vrai.. commence un >>>> développement en équipe avec Haxe.. en cours de route les gens qui bossent >>>> dessus se barrent (changement de travail, abandon du projet, etc.) et tu >>>> te >>>> retrouves avec un code avec très peu de gens qui peuvent le reprendre... >>>> >>>> Code en JS, code en ActionScript, code en Java et là on peut trouver >>>> des gens pour continuer, améliorer, reprendre du code comme il faut. >>>> >>>> Donc moi je veux bien qu'on me dise que telle ou telle techno c'est le >>>> top du top.. reste que pour moi toutes les technos sont top quand elles >>>> sont maitrisées et avec une expertise correcte. >>>> >>>> Je pense très clairement qu'un environnement AS3/AS4 client/serveur >>>> (AIR/Tamarin) avec tout ce qu'il faut dedans permet de faire beaucoup >>>> beaucoup de chose... >>>> >>>> Sinon le coup de "soyons chauvin" .. on s'en fou ;) Quand on fait de >>>> l'opensource ou du code faut penser "international" .. heureusement que >>>> Haxe est en anglais.. mais sérieux quand je vois des codes avec des >>>> commentaires en japonais ou russe.. ou des codes comme dans SPIP avec des >>>> surcouches en français... c'est pas possible de restreindre autant >>>> l'accessibilité du langage ou de l'environnement de développement. >>>> >>>> Dernier truc.. intégrer la VM dans une application mobile c'est pas >>>> trop un soucis vu tout ce qu'elle permet de faire... tu nous parles de >>>> 10Mo >>>> ? c'est quoi 10 Mo au niveau d'une application aujourd'hui ? Et encore si >>>> tu veux rentrer dans le débats qu'il faut absolument mettre dans >>>> l'application que ce qui nous intéresse et pas le reste... bah ok.. code >>>> en >>>> C++ ou Objective C et from scratch dans tous les cas ;) Personnellement je >>>> préfère utiliser une VM qui est testée, optimisée jour après jours et >>>> respectant l'expérience d'un développement de plusieurs années.... >>>> >>>> Quand tu vois ce qui arrive en ce moment avec l'Adobe ASC2 : >>>> http://labsdownload.adobe.com/pub/labs/asc2/air_sdk_asc2_p4_releasenotes.pdf >>>> >>>> J'aimerai voir comment Haxe va pouvoir suivre ce genre d'évolution.. il >>>> est certain que Haxe pourra évoluer avec ses développeurs dans le temps >>>> mais à partir de maintenant il va aller dans sa direction et Adobe dans >>>> une >>>> autre... personnellement quand tu vois ce que va proposer dans l'avenir >>>> avec l'AS4, les optimisations de la VM, etc. la FlashPlatform... moi je >>>> continue à penser que je peux orienter mon développement autour de cette >>>> techno. Il est clair que je ne fais plus beaucoup de site en Flash mais de >>>> l'application mobile, des applications desktops avec Arduino, Leap Motion, >>>> Kinect, des tables tactiles, etc. Tout devient possible et avec une techno >>>> que je maitrise depuis des années au niveau du code et des méthodologies >>>> pour créer les assets, les UIs, etc... >>>> >>>> Bref... tout cela pour dire qu'il y aura toujours d'autres technos mais >>>> impossible de croire une seconde que pour le moment faudrait que j'aille >>>> ailleurs pour continuer de bosser. >>>> >>>> ++ :) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Le 2 décembre 2012 11:03, shoe[box] <shoe...@gmail.com> a écrit : >>>> >>>>> >>>>> Salut les flasheurs. >>>>> >>>>> Perso j'ai fait mon changement de techno début d'année après pas mal >>>>> de ratés avec AIR et 10ans de dev flash. >>>>> >>>>> LA techno a mon avis ( après en avoir testé de très nombreuses ) est >>>>> *HAXE >>>>> *avec *NME *( www.haxenme.org ) >>>>> >>>>> J'ai l'impression que pour tout les devs Haxe fait peur, a tord. >>>>> Quelques arguments: >>>>> >>>>> - NME permet de faire la même chose qu'en flash ( avec quelques >>>>> différence mineur niveau code ) mais avec des performances bien meilleurs >>>>> que AIR pour les jeux 2D. >>>>> Coté 3D le support complet est en cours de dev et sera dispo fin >>>>> d'année ce sera du full opengl es2. >>>>> >>>>> - Il n'y a pas de machine virtuelle qui pompe plein de ressources... >>>>> cela génère du code natif. C'est "blazing fast". >>>>> Il y a pas mal de bench comparatif sur le blog de Joshua Granick >>>>> http://www.joshuagranick.com/blog/ dont un >>>>> bunnymark<http://www.joshuagranick.com/blog/2011/09/01/benchmarking-nme-with-bunnymark/> >>>>> . >>>>> >>>>> - C'est une techno française :) ( soyons un peu chauvin ) >>>>> >>>>> - Ca permet de compiler le même code ( attention la liste est longue ) >>>>> sur : Android , iOS , BlackBerry , Windows Phone ( bientôt ) , HTML5 , >>>>> windows , mac , flash , linux.... >>>>> >>>>> - C'est complétement open-source, avec une communauté active >>>>> http://haxe-foundation.org/ http://haxe.org >>>>> >>>>> - De nombreuse librairies existent déjà : lib.haxe.org >>>>> >>>>> - Comme ça utilise les outils de compilation natif, l'apk / ipa... >>>>> final ne contient pas 10mo de machine virtuelle. >>>>> >>>>> - Les extensions natives sont bien plus simple que sous AIR. >>>>> Ça permet par exemple d'utiliser des gestures réellement natif ( cf ma >>>>> lib hypertouch : https://github.com/shoebox/HyperTouch ) >>>>> >>>>> Et ça marche, je l'ai encore utilisé sur mon dernier jeu ( un peu de >>>>> pub : Arkeon sur >>>>> PlayStore<https://play.google.com/store/apps/details?id=fr.hyperfiction.arkeon>/ >>>>> AppStore >>>>> <https://itunes.apple.com/fr/app/id569189853?mt=8>/ Amazon >>>>> AppStore<http://www.amazon.com/HYPERFICTION-ARKEON-Kindle-Tablet-Edition/dp/B009YG2T1Y/ref=sr_1_1?s=mobile-apps&ie=UTF8&qid=1354442353&sr=1-1&keywords=arkeon>/ >>>>> BlackBerry >>>>> AppWorld<http://appworld.blackberry.com/webstore/content/19227952/?lang=en>) >>>>> et ça fonctionne parfaitement, pas de ralentissements bizarre comme sous >>>>> AIR... >>>>> >>>>> Perso ça m'a pris un mois d'adaptation, et jamais je ne penserai à >>>>> revenir en arrière. >>>>> Quand vous aurez gouté aux macros / itérateurs... vous vous demanderez >>>>> comment vous faisiez avant :) >>>>> >>>>> shoe[box] // >>>>> >>>>> >>>>> Le vendredi 30 novembre 2012 16:05:33 UTC+1, alftuga a écrit : >>>>> >>>>>> Salut a tous j’espère que Zwetan ne vas pas se fâcher que je poste >>>>>> cette question. :) >>>>>> Alors je suis en train de terminer un projet en flex. >>>>>> Et pour l'année qui vient je pense que je vais devoir changer >>>>>> de technologie... >>>>>> Parce que tout le monde autour de moi me dis que flash est mort :( >>>>>> J'aimerais savoir ce que vous pensez as3 c'est mort? >>>>>> Je ne vois plus grand monde parler de nouveaux projet... >>>>>> J'aimerais avoir un conseille sur quelle language je puisse investir >>>>>> sachant d'avance que je veut pas faire du javascript. >>>>>> Du Java peut être? >>>>>> Merci d'avance. >>>>>> >>>>> -- >>>>> Vous recevez ce message, car vous êtes abonné au groupe Google >>>>> Groupes FCNG. >>>>> Cette discussion peut être lue sur le Web à l'adresse >>>>> https://groups.google.com/d/msg/fcng/-/QgXoNIh6FYQJ. >>>>> >>>>> Pour envoyer un message à ce groupe, adressez un e-mail à >>>>> fc...@googlegroups.com. >>>>> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse >>>>> fcng+uns...@googlegroups.com. >>>>> Pour plus d'options, consultez la page de ce groupe : >>>>> http://groups.google.com/group/fcng?hl=fr >>>>> >>>> >>>> -- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes FCNG. Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msg/fcng/-/WULEkhDMHIYJ. Pour envoyer un message à ce groupe, adressez un e-mail à fcng@googlegroups.com. Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse fcng+unsubscr...@googlegroups.com. Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/fcng?hl=fr
