| french | english |
 |
|
| Créer un compte | |
| 30-06-08 / 23:57 : ArsTechnica : article sur Cappuccino (cjed) |
| ArsTechnica propose à son tour un article sur Cappuccino. On y trouve un exemple de code Objective-J comparé au code correspondant d'origine (Objective-C)... la syntaxe est identique (les seules différences sont la disparition du * pour les pointeurs et le suffixe des classes, CP au lieu de NS). On y apprend notamment que l'interpréteur Objective-J qui génère le javascript est suffisamment abstrait pour offrir l'indépendance vis à vis de la technologie d'implémentation : AppKit does generate DOM elements, but, in many ways, the DOM is just an implementation detail for us. If tomorrow every browser implemented SVG, and we thought Cappuccino should really run on SVG, we could rip out the guts and replace some of the code in AppKit and suddenly every app on top of Cappuccino would be running on top of SVG. L'absence de phase de compilation côté serveur (contrairement à GWT) assure non seulement un cycle de développement plus rapide (They make a change, hit refresh, and see it on the screen), mais permettra également à terme l'accessibility (accès à des fonctions système, lorsque les navigateurs auront évolué - ce qui est certain si on regarde le chemin parcouru depuis les débuts et le nombre d'extensions et plugins), chose impossible à partir de bytecode compilé côté serveur (cas de GWT). Les performances du preprocesseur ne semblent pas un souci d'après l'article et les commentaires comme toujours encore plus intéressants : the company [280 North] has a tool "to preprocess Objective-J code ahead of time, so you save client side execution and load time. like WebKit's use of the SquirrelFish interpreter, the extra time required to preprocess before the app starts running becomes less and less of an issue. Preloading images is a good idea, and something we've discussed. We want to come up with a generic solution for it, though, and we simply haven't had the time to do that yet. We will definitely tackle that problem at some point. Sending bytecode to the client won't gain you that much if you're using gzip compression. Besides, with offline support like what google gears allows, you're downloading the app once, and then running it from local storage (unless updates are made). This makes rich web apps feasible even on dial-up, because you have to incur the download cost just once. Throughout the course of building Cappuccino and 280 Slides we've frequently come up with ways that give us anywhere from 2x to 10x performance gains. We released 280 Slides because we felt the performance was adequate (in fact, it loads faster than both PowerPoint and Keynote on my mac), but we're always looking into ways to make it faster. Et tout cela a été réalisé par 3 personnes (ingénieurs travaillant à Apple) seulement ! Le framework est en cours de peaufinage avant la release publique (open source) : we reimplemented AppKit, Foundation, CoreGraphics, and parts of CoreAnimation. |
| Commenter |
| 29-06-08 / 16:15 : MacOSX : 4% des visites sur Internet, 4x Linux (cjed) |
| Selon une étude de XiTiMonitor du 1er janvier 2007 au 30 avril 2008, la part de marché de MacOSX aurait atteint les 4% sur le web (moyenne sur 170 222 sites), soit 4 fois plus que Linux (1%), et toujours infiniment moins que Windows (94,5% toutes versions confondues). De plus le nombre de Mac Intel, supérieur aux mac PPC depuis novembre 2007, ne cesserait de grimper, avec une baisse en parallèle des machines PPC (en partie due - mais pas seulement - à des renouvellements, d'où globalement des ventes de machines Intel - pour des switchers venant de Windows - en hause). La part de marché de MacOSX devrait donc continuer à augmenter et atteindre rapidement les 5%. Au délà d'un seuil à déterminer (probablement au-dessus de 10%) le mouvement de switch pourrait connaître une courbe d'accélération bien plus forte (effet de masse). Il ne faut pas oublier également que l'étude comptabilise forcément les surfers occasionnels depuis leur lieu de travail, or les entreprises sont majoritairement sur Windows. Le pourcentage de surfers sur mac depuis leur domicile est donc bien supérieur. |
| 1 commentaire |
| 28-06-08 / 00:59 : iPhone SDK beta 8 (cjed) |
| Une beta 8 du SDK iPhone est disponible. La version finale devrait donc arriver un peu plus tard que prévu, probalement juste avant la sortie officielle de l'iPhone3G (mi juillet). |
| Commenter |
| 26-06-08 / 01:21 : WebKit : Objective-C depuis du javascript (cjed) |
| Le framework Objective-C WebKit d'Apple (open source, et sert de moteur à Safari) permet de manipuler des objets Objective-C depuis du javascript. Pour ce faire ils sont wrappés dans un objet de type WebScriptObject. Ce dernier assure la conversion de type entre les deux langages (nombre javascript <--> NSNumber, etc.). Mais attention, ceci n'est évidemment possible que dans le contexte d'une application Cocoa (donc sur MacOSX uniquement), le WebScriptObject ne pouvant être récupéré que depuis une vue (Cocoa) de type WebView (en lui envoyant un message windowScriptObject et en bindant dans cet objet/wrapper javascript des objets Objective-C sur des clés, pour pouvoir ensuite les récupérer côté fonctions javascript). Cette possibilité est surtout utile lorsque des applications Cocoa font appel à des plugins qui se basent sur un langage de script, qui doit communiquer avec elles. C'est le même procédé que l'appel d'Objective-C depuis Java (mais bridge déprécié), Python et Ruby. Il est également possible de faire l'inverse, ie d'appeler du javascript (ou tout autre langage de scripting) depuis de l'Objective-C. On peut lire un article sur le sujet sur le site vacuous virtuoso, et récupérer un exemple sur le site ADC. |
| Commenter |
| 26-06-08 / 00:52 : Cappuccino : sources (cjed) |
| Le site carsonified propose dans un article sur Cappuccino et SproutCore des liens vers une partie des sources (javascript) du framework Cappuccino : le runtime Objective-J, un main, une implémentation de contrôleur dérivé. Il y manque toutefois les sources (référencés) de AppKit.j et Foundation.j (versions Objective-J des frameworks Cocoa). Mais déjà la taille très importante de cette partie des sources seulement permet d'entrevoir l'énorme travail réalisé. Pas étonnant que le framework ne soit pas encore disponible sur le site 280 North (l'annonce date d'il y a 10 jours)... Apple est peut être passée par là entre-temps (il s'agit de deux de ses employés). |
| Commenter |
| 24-06-08 / 00:56 : Snow Leopard : resolution independence (cjed) |
| L'indépendance à la résolution devrait finalement être activée dans Snow Leopard. On l'espérait lors d'une update de Leopard (de même que QuartzGL, auparavant nommé Quartz 2D Extreme dans Tiger). |
| Commenter |
| 21-06-08 / 13:55 : iPhone 3G / abonnement Orange : trop cher ? (cjed) |
| On s'attend à ce qu'Orange propose l'iPhone3G 8Go à partir de 99 euros. Sachant qu'actuellement Orange exige un abonnement iPhone spécifique, de 49 à 149 euros, le coût de l'appareil sur 2 ans d'abonnement plus élevé revient au minimum à 408 euros (49-32 * 24 si abonnement actuel à 32 euros/mois) ! On est donc bien au-dessus du prix d'achat sans abonnement, qui devrait être autour de 400 euros (sans compter que le prix de 99$ sera sans doute accessible uniquement pour l'abonnement le plus cher, ce qui amène à 500 euros). |
| Commenter |
| 21-06-08 / 13:43 : iPhone SDK beta7 (cjed) |
| La beta 7 du SDK iPhone est disponible depuis le 11 juin, mais il vaut mieux attendre la version finale, qui devrait apparaître dans une ou deux semaines (avant la sortie de l'iPhone 3G le 11 juillet dans le monde, et le 17 en France). |
| Commenter |
| 20-06-08 / 00:08 : Ajaxian : Cappuccino / Objective-J (cjed) |
| Ajaxian propose une présentation de Cappuccino de 280North (voir également l'application de démo 280slides) : I really like these guys. A couple of them worked on cool products at Apple, and it turns out that they started the language and runtime work back at school. Objective-J is the language that takes JavaScript and makes it Objective (as Obj-C did to C). Lots of square brackets. When the browser gets served .j files, it preprocesses them on the fly. This means that you can do things like, use standard JavaScript in places. Cappuccino is the port of the Cocoa framework. The guys talk a little about the toolchain an why they did this, and even how it enables future cool things such as generating a native Mac application from the same code. Cappuccino sera proposé bientôt en open source sur ce site. Dans les commentaires (où certaines personnes incultes - et/ou très impressionnées - critiquent l'Objective-C pour embrouiller les lecteurs) on peut lire des précisions intéressantes : JavaScript does not have any way of writing applications today in the same way mature platforms like Cocoa do. Cappuccino provides you with very high level features like copy-paste (of anything), undo and redo, document management and archiving, vector graphics and animation, etc etc. What else ? |
| Commenter |
| 19-06-08 / 23:46 : Premier retour sur SproutCore (cjed) |
| Voici ce qu'on peut dire sur SproutCore après avoir lu les premiers tutoriaux : - Il n'y a pas d'outil (pas d'éditeur de code, et pas d'outil Wysiwyg ), mais Interface Builder arrivera peut être par la suite (après tout il en va de même avec GWT). La création des répertoires et des fichiers se fait via la ligne de commande, le tout se base sur le langage de scripting Ruby. - les pages sont des .rhtml (framework de templating Erubis basé sur Ruby). On y définit les tags (labels, contrôles) dynamiques dans des scriptlets <%= %>. - 1ère notion importante, les bindings : on peut lier la valeur d'un label à une propriété d'un objet (défini dans des classes Javascript, voir plus loin), ou encore des contrôles (boutons par ex) à des méthodes du contrôleurs (actions à déclencher au changement d'état du contrôle). Point très important : si on change une propriété (d'un objet contrôleur par ex, ou modèle) en live (via le débugger de Firefox par ex), la valeur est mise à jour dans la vue. Les objets (javascript) sont donc vivants comme dans un runtime, et le binding assure un couplage faible (pas de modif de code requise). Cette approche est complètement différente d'un système de tags (Struts, JSF...) interprétés côté serveur, dont les valeurs, une fois la réponse HTML rendue renvoyée au client, sont immuables. - 2ème notion : les observers (KVO : key value observer) : des méthodes du contrôleur peuvent être déclenchées automatiquement lors de la modification de valeur d'une propriété (sorte de notification). Cette possibilité est à l'origine de nombreuses fonctionnalités/simplifications de mise en oeuvre (et de code) de Cocoa. - on définit une classe contrôleur facilement via un simple constructeur anonyme (méthode create), où on y met les actions ou les méthodes de notification (observers), et également les propriétés (possible sur classe modèle si on veut coller au MVC). Le but est de développer rapidement, en limitant le nombre de classes requises et les instanciations. Le Javascript utilisé est de haut niveau (orienté objet, avec getters et setters) et des APIs de gestion des tâches (timers, etc.) sont incluses (propriété privée _timer acessible par défaut pour traiter rapidement les cas simples). Il n'y a pas de phase de transformation comme avec GWT (coupe le cycle de développement) et le développement se veut le plus rapide possible, avec le moins de code possible. L'appel de services (webservices) côté serveur se fait via JSON-RPC (comme pour GWT et les clients WebObjects en Java Swing), du RPC avec syntaxe particulière (différente du XML-RPC). Il est donc possible d'appeler du code serveur (backend) créé avec n'importe quelle technologie : Java, PHP, etc. On peut s'attendre à ce qu'Apple propose la YellowBox (Cocoa complet, en Objective-C) dans un ou deux ans, afin de contrer Adobe et son AIR, et Microsoft. En attendant il reste des pistes pour introduire des fonctionnalités audio/vidéo côté client via SproutCore : nouveaux tags vidéo HTML5, QuickTime X en préparation pour Snow Leopard (pourrait être un concurrent du container Flash d'Adobe, QuickTime permettant déjà de créer des applications complètes dans un .mov). On attend également le rapprochement avec le framework Cappuccino, qui propose carrément un portage d'objets Cocoa en javascript, et une extension (runtime) du language javascript (Objective-J) - tout comme Objective-C est une extension du C -, qui permet d'appeler ces objets (une phase de compilation à la volée en javascript basique est effectuée, mais ceci est transparent contrairement à GWT). |
| Commenter |
| 19-06-08 / 23:03 : Tout sur le JavaBridge d'Apple de 1999 (cjed) |
| Dans un article de Stepwise datant de 1999 (!) on découvre le fonctionnement du JavaBridge d'Apple, abandonné récemment. Il s'agissait principalement de proxies, créés via JNI. Quant au connaît le problème de robustesse de telles solutions (une exception dans la méthode cible appelée - ici une méthode d'une classe Cocoa - provoque un plantage de l'appelant Java/JVM), sans compter les performances forcément dégradées, on comprend pourquoi Apple a fait ce choix (hors raisons stratégiques). IBM a d'ailleurs annoncé la suppression du support des APIs JNI dans Websphere (un problème pouvant entraîner le plantage de la JVM et donc du serveur tout entier). La solution de réécrire tout Cocoa en Java aurait été trop coûteuse (longue), limitée de toutes façons par les lacunes du runtime Java, et Apple espère attirer les développeurs vers Objective-C via le SDK iphone et ses nouveaux frameworks (UIKit - version spéciale de l'AppKit -, et le Cocoa Touch). |
| Commenter |
| 16-06-08 / 23:03 : SproutCore : Cocoa pour le web (cjed) |
| Alors que certains proposaient qu'Apple porte Cocoa sur Java, il semblerait qu'Apple ait préféré suivre le chemin de GWT, mais en mieux. Ainsi les informations sur le sujet issues de la WWDC2008 de la semaine dernière sont apparues aujourd'hui : Apple a présenté SproutCore, un framework Javascript inspiré du modèle MVC, qui a été repris, enrichi de concepts de Cocoa comme les bindings/property value changes, et amélioré en termes de vitesse. Il s'agit du framework ayant servi a développer la suite MobileMe, et il est open source (licence MIT). Site officiel Parallèlement Apple s'occupe à améliorer Javascript pour Safari 4, via SquirrelFish, un moteur just in time (Firefox4 utilisera un procédé similaire), qui devrait apporter au moins 50% de performances en plus. |
| Commenter |
| 15-06-08 / 23:07 : EFIX / YellowBox : un mac sinon rien (cjed) |
| EFIX annonce pour le 23 juin un dongle USB qui permettrait d'installer OSX sur n'importe quel PC. Ce hack, en plus d'être inderdit (et probablement rendu inopérant par Apple à chaque mise à jour système), ne semble pas parfait : problème de gestion du son ou encore du réseau. Le meilleur PC (le plus intéressant au niveau rapport qualité/prix) est de toutes façons le MacPro, qui fait marcher parfaitement OSX et Windows. De plus, même si Apple sortait Cocoa pour Windows (Yellow Box 2), les applications iLife n'y seraient certainement pas portées, puisqu'elles sont ce qui fait vendre un mac. Les versions OSX de ces applications, bien que compilées pour Intel, ne fonctionneraient pas dans la Yellow Box Windows, du fait par exemple que l'accès au contexte graphique (méthode spécifique graphicsPort) appelle une routine système bas niveau forcément différente sur OSX et Windows (donc recompilation nécessaire). Tout est donc vérrouillé pour que l'expérience Cocoa soit parfaite et complète uniquement depuis un mac. Ceci n'empêche pas la mise à disposition de Cocoa sur Windows (et Linux) pour servir de couche client riche aux applications d'enterprise, mais en aucun cas Apple ne fournira ses applications majeures. Le cas iTunes et QuickTime est différent, il s'agit de la plateforme permettant de promouvoir l'ipod, et de vendre les medias en ligne. |
| Commenter |
| 14-06-08 / 00:00 : Apple / client riche : transformateur nib2Ajax ? (cjed) |
| Avec le nouveau service (payant) MobileMe, Apple propose des applications client riche Ajax qui sont bien plus avancées que les services Google, et dont l'interface et l'ergonomie sont quasiment identiques aux versions Cocoa standalone... on a même droit à un effet CoverFlow. Se pourrait-il donc qu'Apple dispose d'un framework du type GWT, pour créer des applications client riche Ajax (avec peut-être même prise en compte / transformation des APIs de frameworks évolués type CoreAnimation, définies hors IB) ? On peut supposer que le transformateur se baserait sur une archive .nib (objets Cocoa sérialisés) créée via Interface Builder. Tout comme le projet open source abandonné (ou racheté par Apple) nib4j générait une application client Java Swing à partir d'un .nib... Ainsi IB serait la pièce centrale pour les développements, que la destination soit du HTML+javascript (Ajax), du Cocoa/Yellow Box 2, ou bien de l'Apple RCP (basé sur Cocoa et fournissant une gestion simplifiée de l'appel de webservices ?). A propos de nib4j (abandonné subitement... alors que même Apple le citait dans ses notes ADC au sujet des outils intéressants. Etait payant pour une utilisation commerciale. Version de démo PPC ici) : Design Java Swing-based UIs with Apple's Interface Builder : nib4j is a simple but powerfull Java library that permits the use of Apple's Interface Builder to design Swing-based user interfaces. It creates Swing menus, frames and dialogs from Carbon nib files and provides a complete separation of UI and application code. The new version supports the creation of cross-platform UIs with use of JGoodies Forms. With the nib4j Viewer you can try out your Swing interfaces without writing any code and do a cross-platform test showing different Look & Feels. nib4j is completely free for non-commercial use. A developer license is US$ 169. D'autres précisions ici : * Include Carbon nib files in your cross-platform Swing applications * Use "nib4j Viewer" for trying out your cross-platform UI without writing any code * Test your cross-platform UI with different Look & Feels * Support for about 30 different UI controls * Easiest application integration with just a few lines of code * Complete separation of UI and application code * Automatically generate Java classes with "nib4j Viewer" * Support for absolute and relative positioning/sizing of the UI controls * Support for a grid-based cross-platform layout using JGoodies Forms * Embed your own customized components in the generated Swing UI * Use real floating palette windows inside your Mac OS X Swing applications * Create group boxes with the original Mac OS X 10.3 style * Support for internationalization and localization * Define a custom focus cycle order within Interface Builder |
| Commenter |
| 10-06-08 / 22:58 : Snow Leopard : Grand Central, OpenCL, ZFS et UB ? (cjed) |
| Snow Leopard est annoncé pour juin 2009. Il apporte le technologie Grand Central pour développer facilement des applications utilisant au maximum les multiples noyaux (cores) processeurs, et le langage OpenCL (Open Computing Language, langage C qui se veut un standard ouvert) pour utiliser le GPU pour n'importe qu'elle tâche d'une application (Apple serait bien plus avancée que NVidia et son CUDA). Le 64 bits repousse la limite de la mémoire à 16To. Enfin MacOSX 10.6 intégrera QuickTime X (optimisé) et Safari 4 (50% plus rapide en javascript). Apparemment, via des copies d'écrans de la pré-version distribuée aux développeurs, les applications système seraient encore en universal binary, donc utilisables sur PowerPC (en espérant que cela ne change pas pour la version finale, impossible de toutes façons en cours de route, ou au pire seuls les G5s - 64 bits - seraient supportés). La copie d'écran des préférences laisse voir la mention du mode (ici 32 bits), qui suppose qu'Apple a conservé les deux types de fonctionnement - 32 bits et 34 bits - transparents (considéré comme un tour de force dans Leopard). Les G4 et Core Duo seraient donc peut être supportés. L'annonce d'une taille fortement diminuée de l'installation laisse pourtant penser que seules les machines Intel seront prises en compte (bien qu'il soit possible de n'installer que le code d'un type de processeur). Quant à Snow Leopard Server, il apporterait le système de fichier ZFS (128 bits) en lecture et écriture. Snow Leopard a été présenté comme allant servir de base à la prochaine déclinaison de MacOSX pour plusieurs années (1000 nouvelles fonctionnalités depuis 2000 déjà pour la déclinaison initiale). On peut donc s'attendre à un MacOSX 11 après Snow Leopard, qui apportera une interface Touch toute nouvelle (ce qui explique Leopard, un avant-goût seulement de Core Animation et de la technologie Touch). |
| Commenter |
| 09-06-08 / 22:35 : iPhone 3G (cjed) |
| Apple a présenté l'iPhone 3G (inclut également un GPS, utilisé notamment pas Google Maps). Le dos est en plastique noir, les bords plus fins, l'autonomie améliorée, et enfin l'audio serait amélioré (et la prise casque de format standard), mais toujours pas de caméra vidéo (seulement un appareil photo 2 megapixels). Tout cela à un prix d'achat deux fois moindre comparé au modèle précédents (199$ pour 8Go, 299 pour 16Go) ! Un nouveau système de synchronisation, MobileMe, a été présenté : il permet notamment, depuis une interface web riche, de gérer ses mails, adresses, agenda, photos, documents (comme les outils Google). Côté jeux, Pangea Software aurait présenté des versions iPhone de Enigmo et Cro-Mag Rally. |
| Commenter |
| 09-06-08 / 18:24 : YellowBox 2 / Apple WO Rich Client Platform ? (cjed) |
| On devrait savoir dans une heure (keynote d'ouverture de la WWDC2008 par Steve Jobs) si Cocoa débarque en masse
sur Windows (Yellow Box 2), et si Apple s'en sert également comme d'une Rich Client Platform multi OS,
en remplacement de la partie cliente acutelle de WebObjects (HTML et tags propriétaires). Pour le premier point il est clair que l'arrivée de la Yellow Box sur Windows est déjà entamée (APIs Core Foundation, procédurales, utilisées par Safari sur Windows), mais on attend le framework Cocoa objet complet (Foundation Kit, AppKit). Lancée (puis abandonnée au profit de la phase de transition Carbon) il y a 10 ans (98), la Yellow Box (à l'époque basée sur les API OpenStep) pourrait ressortir dans une nouvelle version (Yellow Box 2... tout comme Objective-C 2 est sorti il y a deux ans), basée sur les objets et APIs rajoutés à Cocoa depuis 2000. D'ailleurs Cocoa est à présent la cible de toutes les applications mac (Adobe l'utilise dans son dernier logiciel de retouche d'image, Snow Leopard utilisera davantage Cocoa, à la place du code actuel Carbon, transitoire à la base), et le SDK iPhone a quelque part servi également à faire découvrir Cocoa via le framework Cocoa Touch. Dans le livre Cocoa Programming (2002), partie APIs graphiques, on apprend que des handlers spécifiques (pointeurs sur des fonctions C propriétaires externes) sont présents (depuis 2001 déjà donc), afin de récupérer un contexte graphique autre que celui de MacOSX si besoin... Du point de vu applications d'entreprises orientées web, on sait qu'Apple doit fournir des indications sur le devenir (la suite) de WebObjects, et les rumeurs d'une équipe réduite pourraient être simplement une feinte, afin de créer la surprise comme Apple aime le faire (cf. le développement secret d'OSX pour Windows pendant 7 ans). En plus d'Objective-C 2 sorti il y a deux ans (et rajoutant notamment un Garbage Collector... pour tenter les programmeurs Java ?), on trouve un indice encore plus pertinent concernant ce domaine : le bridge Java est déprécié, donc toutes les applications WebObjects développées en Java ne seront plus supportées à terme (ne bénéficieront pas des nouvelles APIs de Cocoa). Mais pourquoi risquer de se fermer ce marché (et s'attirer la colère) sans raison ? Sauf si on a quelque chose à proposer à la place, de bien meilleur. Il se pourrait qu'Apple abandonne la partie serveur (WebServices : leur développement Java sous Eclipse, leur déploiement sous les serveurs IBM, etc.), domaine où J2EE est plus riche et semble avoir réussi (normes de connecteurs et d'archives, etc.), et se concentre sur la partie cliente, domaine où justement les besoins ont évolué (bureau métier, accès à des fonctions spécifiques du système, etc.), où les solutions actuelles sont multiples (RCP, Swing, GWT, Flex) mais où aucune ne s'impose (manque de normes également), et où aucune n'est réellement satisfaisante (javascript limité, peu robuste, peu sûr pour GWT, manque d'élégance de Swing et de son visual editor, accès limité aux fonctionnalités système depuis Java, lourdeur de mis en place de RCP et mêmes limitations, fonctionnement de type JVM/boite noire pour Flex - à la limite pourquoi pas une appli complète dans un container QuickTime moov, possible depuis 14 ans ?). Apple arriverait donc à point avec un Apple Rich Client Platform, basé sur la Yellow Box 2. A se demander s'ils n'avaient pas prévu ce retour d'ascenseur, en tous les cas le timing et les conditions sont parfaits. L'iphone a d'ailleurs eu droit à son framework client spécifique, l'UIKit (version de l'AppKit adaptée aux contraintes des interfaces des appareils mobiles)... On aurait un Apple RCP Kit ? La réponse au Silverlight que Microsoft tente d'imposer depuis des années (XAML et framework .NET de base installé d'office sur Windows).s |
| 4 commentaire |
| 07-06-08 / 23:06 : Apple / Nvidia CUDA (cjed) |
| Apple, qui s'appliquera principalement à l'optimisation des performances dans Leopard Snow (attendu pour début 2009), serait intéressée par le langage CUDA de Nvidia, qui permet de programmer un GPU comme s'il s'agissait d'un processeur général, et donc avec la précision nécessaire aux applications habituelles (les calculs effectués par un GPU à la base sont beaucoup moins précis, car destinés à l'affichage à l'écran, et non pas à une réutilisation). |
| Commenter |
| 05-06-08 / 00:49 : MacOSX 10.6 Snow Leopard (cjed) |
| D'après ArsTechnica Apple pourrait proposer au cours de la WWDC de la semaine prochaine une pré-version de MacOSX 10.6, dont le nom serait Snow Leopard. Ainsi le nouvel OS n'apporterait pas de nouvelle grande fonctionnalité, mais serait principalement optimisé (vitesse et stabilité), réécrit en Cocoa (notamment pour les parties graphiques), tirera encore plus partie du 64 bits, et devrait fonctionner uniquement sur Intel (afin de simplifier le travail des développeurs) ! Pour rappel certaines APIs auparavant uniquement accessibles en Carbon le sont maintenant en Cocoa, qui à présent l'architecture cible. Les possesseurs de G4 seront donc complètement "left in the snow"... |
| Commenter |