je n'ai jamais programmé en cocoa, seulement en java et assembleur (je
connais un peu applescript) je souhaite faire un petit bout d'essai en
cocoa.
j'ai une base de données (aujourd'hui se sont des objets java, mais pour
construire cette bd j'ai des fichiers textes que je pourrais convertir).
cette base de données décrit la système des appellations de vin
(ambition mondiale, réalisation france quasi totale et quelques autres
pays démarés)
donc je voudrai m'essayer en cocoa sur un exemple concret : représenter
dans une fenêtre l'arbre des appellations "mondiales"
(copie écran à http://yvon-thoraval.com/jCave/)
et ensuite les feuilles sur les cépages
(copie écran à
http://yvon-thoraval.com/jCave/index.php?page=vp-view&lang=fr&mode=zoom)
et ainsi de suite pour traduire mon appli java en cocoa.
(outre appellations et cépages dans mon appli il y a un carnet
d'adresses et une gestion des bouteilles en cave)
où trouver des infos pour démarrer ainsi ?
exemples ?
supposons maintenant que je finisse cette appli en cocoa. Bon des gens
me demandent la même chose sous unix et win* y a t'il moyen de traduire
depuis du cocoa ou faut-il tout refaire ?
une fois que le code java est passé au hotspot (ou JIT) quelle est la difference?
cette question * trouble * mon esprit...
normalement aucune (avec Objective-C), si j'ai bien compris.
une.bevueVOTEZ
Schmurtz wrote:
Si la partie lente de ton code forme un bloc (ie, qu'elle n'est pas éparpillé dans toute l'appli), ou alors peut être centraliser sur une seule classe, il fait savoir que tu peux garder tout ton code java et ne réécrire que les fonctions coûteuses de cette classe en C.
ben, c'est intéressant ce que tu dis because, la partie lente c'est ma base de donnée (objet) et sa gestion (recherche multi critères).
donc il faut que je me senseigne comment on fait une persistence en C...
le reste c'est l'affichage (actuellement du swingX ie swing amélioré) qui est assez proche, fonctionnellement, de ce qu'on peut faire en cocoa (chez sun certaines particularités des tables en cocoa sont prises en design goal par exemple le sorting...)
ce que je dois, à part l'ui, implémenter en c c'est la persistence d'objets tels que :
public class Bottle { public String description; public String appellation; public Integer vintage; public ArrayList composition;
[...]
public SimpleDate buyDate; public SimpleDate lastPriceDate; public String drinkWith;
public Bottle() { } }
j'entre (pour l'instant) une bouteille comme ça :
Bottle symphorine = new Bottle(); symphorine.description = "Cuvée Symphorine sélection 1998"; symphorine.appellation = "Grand Cru Blanc de Blancs"; symphorine.vintage = new Integer(1998);
et pour l'entrer dans la bd :
ObjectContainer db = null; db.set((Bottle) symphorine); db.commit(); db.close();
enfin la recherche multi-critères se fait en générant un filtre sur un arbre de contraintes du genre :
et os contient toutes les bouteilles dont le millésime est de 1998.
Schmurtz <moi@ici.com> wrote:
Si la partie lente de ton code forme un bloc (ie, qu'elle n'est pas
éparpillé dans toute l'appli), ou alors peut être centraliser sur une
seule classe, il fait savoir que tu peux garder tout ton code java et ne
réécrire que les fonctions coûteuses de cette classe en C.
ben, c'est intéressant ce que tu dis because, la partie lente c'est ma
base de donnée (objet) et sa gestion (recherche multi critères).
donc il faut que je me senseigne comment on fait une persistence en C...
le reste c'est l'affichage (actuellement du swingX ie swing amélioré)
qui est assez proche, fonctionnellement, de ce qu'on peut faire en cocoa
(chez sun certaines particularités des tables en cocoa sont prises en
design goal par exemple le sorting...)
ce que je dois, à part l'ui, implémenter en c c'est la persistence
d'objets tels que :
public class Bottle {
public String description;
public String appellation;
public Integer vintage;
public ArrayList composition;
[...]
public SimpleDate buyDate;
public SimpleDate lastPriceDate;
public String drinkWith;
public Bottle() {
}
}
j'entre (pour l'instant) une bouteille comme ça :
Bottle symphorine = new Bottle();
symphorine.description = "Cuvée Symphorine sélection 1998";
symphorine.appellation = "Grand Cru Blanc de Blancs";
symphorine.vintage = new Integer(1998);
et pour l'entrer dans la bd :
ObjectContainer db = null;
db.set((Bottle) symphorine);
db.commit();
db.close();
enfin la recherche multi-critères se fait en générant un filtre sur un
arbre de contraintes du genre :
Si la partie lente de ton code forme un bloc (ie, qu'elle n'est pas éparpillé dans toute l'appli), ou alors peut être centraliser sur une seule classe, il fait savoir que tu peux garder tout ton code java et ne réécrire que les fonctions coûteuses de cette classe en C.
ben, c'est intéressant ce que tu dis because, la partie lente c'est ma base de donnée (objet) et sa gestion (recherche multi critères).
donc il faut que je me senseigne comment on fait une persistence en C...
le reste c'est l'affichage (actuellement du swingX ie swing amélioré) qui est assez proche, fonctionnellement, de ce qu'on peut faire en cocoa (chez sun certaines particularités des tables en cocoa sont prises en design goal par exemple le sorting...)
ce que je dois, à part l'ui, implémenter en c c'est la persistence d'objets tels que :
public class Bottle { public String description; public String appellation; public Integer vintage; public ArrayList composition;
[...]
public SimpleDate buyDate; public SimpleDate lastPriceDate; public String drinkWith;
public Bottle() { } }
j'entre (pour l'instant) une bouteille comme ça :
Bottle symphorine = new Bottle(); symphorine.description = "Cuvée Symphorine sélection 1998"; symphorine.appellation = "Grand Cru Blanc de Blancs"; symphorine.vintage = new Integer(1998);
et pour l'entrer dans la bd :
ObjectContainer db = null; db.set((Bottle) symphorine); db.commit(); db.close();
enfin la recherche multi-critères se fait en générant un filtre sur un arbre de contraintes du genre :
et os contient toutes les bouteilles dont le millésime est de 1998.
Bruno CAUSSE
dans l'article 1gwidll.gx45uj18e5dc6N%, Une bévue à a écrit le 13/05/05 18:29 :
cette question * trouble * mon esprit...
normalement aucune (avec Objective-C), si j'ai bien compris.
Si "NOUS" avons bien compris :-). Alors soit le compilateur java est codé avec les pieds, soit objective-c est "lent/rapide" comme java.
Un rapport entre 2 & 3 entre du java "optimisé : (reutilisation des objets aucune creation d'objet dans les parties chaudes, Pas ou tres peu de GC ect....)" et du c/c++ optimisé est le facteur que je retiens. D'autres benchs diront que java est plus rapide que du c++ (plaisanterie)
Mais tiens nous au courant.
PS: pour les habitués de java, C++ c'est la prehistoire en codage
dans l'article 1gwidll.gx45uj18e5dc6N%une.bevueVOTEZ@NONfree.fr, Une bévue à
une.bevueVOTEZ@NONfree.fr a écrit le 13/05/05 18:29 :
cette question * trouble * mon esprit...
normalement aucune (avec Objective-C), si j'ai bien compris.
Si "NOUS" avons bien compris :-). Alors soit le compilateur java est codé
avec les pieds, soit objective-c est "lent/rapide" comme java.
Un rapport entre 2 & 3 entre du java "optimisé : (reutilisation des objets
aucune creation d'objet dans les parties chaudes, Pas ou tres peu de GC
ect....)" et du c/c++ optimisé est le facteur que je retiens. D'autres
benchs diront que java est plus rapide que du c++ (plaisanterie)
Mais tiens nous au courant.
PS: pour les habitués de java, C++ c'est la prehistoire en codage
dans l'article 1gwidll.gx45uj18e5dc6N%, Une bévue à a écrit le 13/05/05 18:29 :
cette question * trouble * mon esprit...
normalement aucune (avec Objective-C), si j'ai bien compris.
Si "NOUS" avons bien compris :-). Alors soit le compilateur java est codé avec les pieds, soit objective-c est "lent/rapide" comme java.
Un rapport entre 2 & 3 entre du java "optimisé : (reutilisation des objets aucune creation d'objet dans les parties chaudes, Pas ou tres peu de GC ect....)" et du c/c++ optimisé est le facteur que je retiens. D'autres benchs diront que java est plus rapide que du c++ (plaisanterie)
Mais tiens nous au courant.
PS: pour les habitués de java, C++ c'est la prehistoire en codage
une.bevueVOTEZ
Bruno CAUSSE wrote:
PS: pour les habitués de java, C++ c'est la prehistoire en codage
oui, c'est pour cette raison que je mentionnait le fait que, dans ma préhistoire, j'avais codé en assembleur...
Bruno CAUSSE <envoi@lesSpam.fr> wrote:
PS: pour les habitués de java, C++ c'est la prehistoire en codage
oui, c'est pour cette raison que je mentionnait le fait que, dans ma
préhistoire, j'avais codé en assembleur...
À part ça, j'imagine que ce sera du cocoa écrit en java ?
Non, si j'envisage cocoa c'est pour Objective-C, le but est d'obtenir qqc de + rapide que java...
l'écriture est différente, mais la compilation doit donner un code sensiblement identique...
lucsky
Bruno Causse wrote:
avec des pools d'objets reutilisables on peut limiter (spectaculairement) les ralentissements du GC de plus sur un bi-pro il peut etre // au traitement
Ca commence à faire beaucoup de si... :>
-- Luc Heinrich -
Bruno Causse <pasde.bcausse.spam@wanadoo.fr> wrote:
avec des pools d'objets reutilisables on peut limiter
(spectaculairement) les ralentissements du GC
de plus sur un bi-pro il peut etre // au traitement
avec des pools d'objets reutilisables on peut limiter (spectaculairement) les ralentissements du GC de plus sur un bi-pro il peut etre // au traitement
Ca commence à faire beaucoup de si... :>
-- Luc Heinrich -
une.bevueVOTEZ
gilles wrote:
l'écriture est différente, mais la compilation doit donner un code sensiblement identique...
ben alors, je ferai juste un petit essai...
gilles <gillesrobert@free.fr> wrote:
l'écriture est différente, mais la compilation doit donner un code
sensiblement identique...
