1 - Tu peux aussi utiliser pstack (google pstack)
2 - Sinon, apparemment il existe des methodes dans la glibc pour faire un display de la stack trace... (sauf que j'arrive pas a mettre le nom sur ces fameuses methodes ...)
3 - Derniers recours, utiliser __builtin_frame_address() and __builtin_return_address() qui sont des methodes de gcc ...
Dans le cas de Nosica, non seulement c'est pas dur a implementer, mais en plus c'est efficace...
En fait, ca ne prend du temps que dans le cas ou tu utilises vraiment la feature... (visiteur, covariance)
Merci l'analyse globale ... !! :-)
Si tu changeais pas de nick sans arret ... :-)
D'ailleurs en parlant de Nosica, j'ai trouve un truc sympa : finalement je vais garder l'invariance, mais je vais ajouter les multi methodes (multiple dispatch).
Du coup ca me permettra de faire de la covariance, sauf que je serai type safe a la compilation et au runtime ...
Qu'est ce que t'en dis ?
OK je vois ...
C++ : le type template n'existe pas vraiment au runtime ...
Java : la classe generique est un vrai type, y compris au runtime
Par contre, le fait de creer une classe generique qui prend un fait un Object au runtime a son pour et son contre :
Pour : Une seule classe creee
Contre : implique de rajouter des casts de facon automatique alors que le type check a prouve qu'il n'y en avais pas besoin ... Bizarre ...
Rajouter des contraintes sur les types parametriques a l'aide du mot clef "implements", c'est assez marrant, c'est la solution qu'on a retenu pour Nosica il y a plus de deux ans ...
Sinon, je suis assez content de voir que ce qu'ils appellent la bonne methode (vrai type, contraintes sur les types) c'est ce qu'on a implemente en Nosica des le depart ... Sauf qu'on cree N vrai types a partir d'un type generique, du coup on peut optimiser chaque version independemment des autres versions, et surtout avoir une version type safe a la compilation et au runtime.
On peut aussi compiler integralement une class generique sans qu'elle soit utilisee ...
Le compilo est ecrit en Java ... En attendant de pouvoir s'auto compiler ...
Le compilo Nosica produit ensuite un source en C qui est compile pour obtenir l'executable ... C'est a dire que le C nous sert de macro assembleur portable ...
Pourquoi ne pas utiliser la JVM ? Tout simplement parce que on veut des performances (on veut pouvoir rivaliser avec le C en terme de temps d'execution). Maintenant comme pour SmartEiffel rien n'empeche de construire un back end qui produit du code Java ou du bytecode ...
La portabilite n'est pas l'Argument que l'on met en avant, c'est un des arguments. L'argument que l'on met le plus en avant c'est l'analyse globale du code.
L'idee des categories (aspect) me semble interressante, cependant je n'ai jamais vu de vrai code l'utilisant. Je sais qu'il est actuellement tres difficile d'implementer la programmation aspect car ca necessite un ensemble d'outil assez lourd a mettre en place au runtime ...
On va se repeter : eviter tout ce qui est du style *String* ou certains caracteres sont interpretes ...
Ensuite :
char *fir;
uint ui=(uint)iod.size();
iod.readBlock(fir,ui);
Tu n'as pas alloue ton 'fir' ... T'as pas peur toi ...
qcs=(QCString)cc;
T'utilises un cast, alors que tu n'as pas construit l'objet ... T'as pas peur toi ...
QTextStream ts(s);
On avait dit, pas de *TextStream, pas de *String* ...
Le reste est du meme acabit ...
Essaye un truc simple :
#define CHUNK_SIZE 100
QFile file(); // pseudo code, je te laisse le soin de l'initialiser
QSocket socket(); // pareil
char data[CHUNK_SIZE];
while (!file.atEnd())
{
Q_LONG read = file.readBlock(data, CHUNK_SIZE);
Q_LONG written = socket.writeBlock(data, read);
if (written == -1)
{
// an error occurred
}
}
Excuse moi, mais sérieusement, t'appelle ca une solution ?
Et tu dis que c'est typé ?
Tu sais ce que ca veut dire que la verification de type a la compilation ?
Parce que au cas ou t'aurais pas remarque c'est de ca qu'on parle ...
Excuse mon ignorance, mais en quoi l'implementation de Java est-elle plus simple que celle de C++ ?
Pour l'utilisation, a priori ca a l'air de pas mal se ressembler ...
Pour la creation de template ? Mis a part qu'il n'y a plus le mot clef "template", le reste ressemble pas mal non ?
Pas d'accord, il s'agit d'un hack immonde du compilo qui par derriere va aller te chercher un StringBuffer ...
Bref, du grand n'importe quoi ...
Il ne s'agit pas d'etre sexy ou quoique ce soit, il suffit d'utiliser a bon escient les outils dont on dispose.
Un operateur + sur un entier se comprend.
Un operateur + sur un velo ne se comprend pas.
De la meme maniere
Une methode changeDeVitesse sur un velo se comprend
Une methode changeDeVistesse sur un entier ne se comprend pas
Alors evidemment, on pourrait s'amuser a faire des methodes explicites sur les entiers.
Une methode add, une methode mul, ... Mais pourquoi se compliquer la vie alors qu'on peut faire des choses simples ... ?
Il ne s'agit pas d'etre sexy, mais d'etre efficace ...
N'importe quoi.
Les classes virtuelles te permettent de faire du polymorphisme, alors que la genericite te permet d'adaptater un algorithme a un type...
Ca permet entre autre d'avoir des vrais containers types, au lieu de ces infames Vector que l'on a en Java ...
Il y a plusieurs serveurs CVS ? Ah bon ?
Non, la je crois qu'il n'y a qu'une seule implementation : cvs (qui fait a la fois client et serveur suivant comment tu le lances ...)
A mon avis, tu vas avoir besoin d'imprimer la page info de CVS.
Ca fait mal au debut, mais on s'y fait ! :-)
Posté par Epsos .
En réponse au journal Xine.
Évalué à 2.
Si tu nous expliquais quel est le diagnostique ?
Ca plante ? pas d'image ? pas de son ?
Enfin bref pas tres detaille tout ca ...
Sinon, une solution magique si t'es sous Mandrake : tu ajoute plf comme source dans urpmi, et ensuite : 'urpmi xine' ... Et tu ne te posera plus de question ...
Ca peut avoir plusieurs causes :
1 - ta base rpm est a la rue : reconstruit la (rpm --rebuild je crois)
2 - le nom que tu utilise dans 'rpm -q -a | grep' n'est pas le meme que celui que tu utilises dans rpmdrake
Tu peux essayer en ligne de commande avec urpmi, urpme, urpmf et urpmq.
C'est dommage que tu files pas le nom de ton package ca serait plus facile pour les exemples.
Mettons qu'il s'appelle toto ton prog.
$> rpm --rebuilddb
$> urpmf toto ==> ca va te dire quel package correspond au programme toto
toto-0.1.1-2mdk.rpm
$> urpmi toto-0.1.1
Si le urpmf ne te renvoie rien, tu peux essayer 'urpmq toto' qui est un peu plus bourrin (ca cherche tous les fichiers dans tous les packages qui contiennent la chaine toto)
S'il est deja installe, essaye un 'urpme toto' ...
Sinon, peut etre que ton package est liste dans /etc/urpmi/skip.list
Oui, chaque objet reference (pouvant faire de l'heritage et du polymorphisme dynamique) derive de Object. Et l'implementation de Object garde un numero unique qui permet de savoir le type de l'objet au runtime (via instanceof ou cast). Cet id n'est pas accessible a l'utilisateur, c'est juste un detail d'implementation.
Pour la definition de polymorphisme, voila quelques exemples pour essayer d'eclairer un peu tout ca :
1 - Genericite aka polymorphisme statique aka template aka polymorphisme parametrique :
class Toto
{
T someData;
T getSomeData() { return someData; }
}
Toto t; // Toto est parametre par int
int i = t.getSomeData;
En OCaml, tu ne specifie pas le parametre T je crois, car implicitement toutes les methodes sont generique non ?
2 - Polymorphisme dynamique aka polymorphisme aka polymorphisme d'inclusion
interface A
{
}
class AImpl implements A
{
}
class Toto
{
public sub f(A a) {}
}
Toto toto = new Toto();
toto.f(new AImpl()); // accepte les sous types
3 - Polymorhisme dynamique aka polymorphisme veut aussi dire (en OCaml je sais pas)
class A
{
public sub f() {}
}
class B extends A
{
public sub f() {}
}
A a = new B();
a.f(); // appelle en fait B.f()
C'est aussi appele "late binding", car ce n'est qu'au runtime que tu sais effectivement quelle methode tu vas appeler en fonction du vrai type de a. En Nosica, le late binding est resolu pendant la compilation grace a l'analyse globale. En SmartEiffel aussi. En c++ et en Java, ce mecanisme n'est resolu qu'au runtime.
En C++ aussi tu peux separer heritage de sous typage.
Dans la pratique ca sert pas a grand chose (oui ca sert dans certains cas, mais je trouve que l'emploi de cette solution est assez discutable)
En Eiffel aussi tu peux le faire...
Le probleme quand tu utilise ce genre de chose, c'est que tu confond souvent interface et implementation... et ca c'est MAL :-)
En Nosica, les types references font a la fois de l'heritage et du sous typage. Les types primitifs font de l'heritage, mais pas de sous typage.
Un cast a toujours ete sur en Java.
En C++ le cast est sur a condition d'utiliser la bonne facon de faire (dynamic_cast)
En Nosica le cast est sur aussi...
Ca veut dire quoi ? Ca veut dire que dans les cas ambigus, il y a un test au runtime et le lancement d'une exception ...
Dans tous les cas tu ne pourras prendre un type B pour un type A s'il n'y a aucun rapport entre les deux. En plus s'il n'y a vraiment aucun rapport entre les deux, tu te fais jeter a la compil. Les cas un peu tendancieux sont ceux qui proviennent du downcasting ... Mais d'apres ce que j'en comprend, que tu fasses de l'invariance ou de la covariance il y aura forcement des cast (meme s'ils sont caches), et donc forcement des cas ou tu peux avoir un runtime failure.
Pour ce qui est de l'Ocaml, le peu que j'en connaisse ne m'a pas trop seduit. La plupart de la programmation objet en Ocaml est de la programmation generique (aka polymorphisme statique), et pas de la vrai programmation dynamique (aka polymorphisme dynamique).
De plus le systeme de variable unmutable impose un style de programmation que je n'aime pas du tout. Il est souvent obligatoire de passer par des algos recursifs a cause de ca.
Pour finir, si tu vas sur http://caml.inria.fr/FAQ/FAQ_EXPERT-eng.html#polymorphisme(...) tu verras qu'il existe un certains nombre de limitations au langage.
1 - Les tableaux sont des types comme les autres.
Il est possible de surcharger leurs methodes comme n'importe quel autre type ...
Les tableaux ne sont pas des types primitifs, ce sont des types references. Et ils sont invariants ...
2 - Non, on n'autorise pas a appeler une methode sans les () si elle n'a pas de parametres.(1 seule facon de faire c'est notre motto) Par contre l'utilisateur peut tres bien definir des proprietes ...
Ex :
class Toto
{
private A a;
public A propery a() const { return a; }
}
Toto toto = new Toto();
A a = toto.a; // call Toto.property a
3 - On a essaye d'etre le moins verbeux possible. (j'ai horreur de Eiffel a cause de ca)
4 - Le fameux ';' Effectivement on le traine, et je pense qu'on va le garder. C'est pas tres utile pour le langage effectivement, par contre c'est tres utile pour ce qui est du reporting d'erreur de la reprise sur erreur ...
5 - Quelque chose en plus... Et bien, il me semble que Nosica a deja quelque chose en plus :-) Bien sur, rien de revolutionnaire, mais pleins de petites choses qui en font je l'espere un langage sur, souple et efficace.
Pour ce qui est des trucs de killer, Nico a souleve pas mal de points importants pour ce qui est de l'optimisation. On espere un jour pouvoir faire du multithreading automatique pour accelerer les boucles ... (voir le forum pour plus de details)
[^] # Re: strace plus au niveau ??
Posté par Epsos . En réponse au journal strace plus au niveau ??. Évalué à 1.
pour la doc gcc sur __builtin_frame_address() and __builtin_return_address()
[^] # Re: strace plus au niveau ??
Posté par Epsos . En réponse au journal strace plus au niveau ??. Évalué à 3.
Voir http://www.gnu.org/manual/glibc-2.2.5/html_node/Backtraces.html#Bac(...)
[^] # Re: strace plus au niveau ??
Posté par Epsos . En réponse au journal strace plus au niveau ??. Évalué à 1.
2 - Sinon, apparemment il existe des methodes dans la glibc pour faire un display de la stack trace... (sauf que j'arrive pas a mettre le nom sur ces fameuses methodes ...)
3 - Derniers recours, utiliser __builtin_frame_address() and __builtin_return_address() qui sont des methodes de gcc ...
[^] # Re: L'avenir ...
Posté par Epsos . En réponse à la dépêche Java Virtual Machine 1.4.2 beta. Évalué à 1.
En fait, ca ne prend du temps que dans le cas ou tu utilises vraiment la feature... (visiteur, covariance)
Merci l'analyse globale ... !! :-)
[^] # Re: On les sent aux abois !
Posté par Epsos . En réponse à la dépêche Java Virtual Machine 1.4.2 beta. Évalué à 1.
Ca fait plaisir de voir qu'il y a des gens qui suivent !! :-)
[^] # Re: L'avenir ...
Posté par Epsos . En réponse à la dépêche Java Virtual Machine 1.4.2 beta. Évalué à 1.
D'ailleurs en parlant de Nosica, j'ai trouve un truc sympa : finalement je vais garder l'invariance, mais je vais ajouter les multi methodes (multiple dispatch).
Du coup ca me permettra de faire de la covariance, sauf que je serai type safe a la compilation et au runtime ...
Qu'est ce que t'en dis ?
[^] # Re: Pour rentrer dans les details
Posté par Epsos . En réponse à la dépêche Java Virtual Machine 1.4.2 beta. Évalué à 1.
C++ : le type template n'existe pas vraiment au runtime ...
Java : la classe generique est un vrai type, y compris au runtime
Par contre, le fait de creer une classe generique qui prend un fait un Object au runtime a son pour et son contre :
Pour : Une seule classe creee
Contre : implique de rajouter des casts de facon automatique alors que le type check a prouve qu'il n'y en avais pas besoin ... Bizarre ...
Rajouter des contraintes sur les types parametriques a l'aide du mot clef "implements", c'est assez marrant, c'est la solution qu'on a retenu pour Nosica il y a plus de deux ans ...
Sinon, je suis assez content de voir que ce qu'ils appellent la bonne methode (vrai type, contraintes sur les types) c'est ce qu'on a implemente en Nosica des le depart ... Sauf qu'on cree N vrai types a partir d'un type generique, du coup on peut optimiser chaque version independemment des autres versions, et surtout avoir une version type safe a la compilation et au runtime.
On peut aussi compiler integralement une class generique sans qu'elle soit utilisee ...
Content !! :-)
[^] # Re: ça à l'air pas mal ...
Posté par Epsos . En réponse à la dépêche Java Virtual Machine 1.4.2 beta. Évalué à 1.
Le compilo Nosica produit ensuite un source en C qui est compile pour obtenir l'executable ... C'est a dire que le C nous sert de macro assembleur portable ...
Pourquoi ne pas utiliser la JVM ? Tout simplement parce que on veut des performances (on veut pouvoir rivaliser avec le C en terme de temps d'execution). Maintenant comme pour SmartEiffel rien n'empeche de construire un back end qui produit du code Java ou du bytecode ...
La portabilite n'est pas l'Argument que l'on met en avant, c'est un des arguments. L'argument que l'on met le plus en avant c'est l'analyse globale du code.
L'idee des categories (aspect) me semble interressante, cependant je n'ai jamais vu de vrai code l'utilisant. Je sais qu'il est actuellement tres difficile d'implementer la programmation aspect car ca necessite un ensemble d'outil assez lourd a mettre en place au runtime ...
Tu as d'autres infos la dessus ?
(sinon, je t'invite a venir poser tes questions sur le forum du site (http://nosica.ng-market.net/forum(...) )
[^] # Re: petite question sur les transfert dans le protocole http
Posté par Epsos . En réponse au journal petite question sur les transfert dans le protocole http. Évalué à 1.
[^] # Re: L'avenir ...
Posté par Epsos . En réponse à la dépêche Java Virtual Machine 1.4.2 beta. Évalué à 1.
[^] # Re: Pas si simple ...
Posté par Epsos . En réponse à la dépêche Java Virtual Machine 1.4.2 beta. Évalué à 1.
[^] # Re: Java Virtual Machine 1.4.2 beta
Posté par Epsos . En réponse à la dépêche Java Virtual Machine 1.4.2 beta. Évalué à 4.
[^] # Re: La genericité ...
Posté par Epsos . En réponse à la dépêche Java Virtual Machine 1.4.2 beta. Évalué à 5.
Pour l'utilisation, a priori ca a l'air de pas mal se ressembler ...
Pour la creation de template ? Mis a part qu'il n'y a plus le mot clef "template", le reste ressemble pas mal non ?
Alors c'est quoi la difference fondamentale ?
(je suis vraiment dans l'ignorance la ...)
[^] # Re: 100% D'accord ... sauf ;)
Posté par Epsos . En réponse à la dépêche Java Virtual Machine 1.4.2 beta. Évalué à 9.
Bref, du grand n'importe quoi ...
Il ne s'agit pas d'etre sexy ou quoique ce soit, il suffit d'utiliser a bon escient les outils dont on dispose.
Un operateur + sur un entier se comprend.
Un operateur + sur un velo ne se comprend pas.
De la meme maniere
Une methode changeDeVitesse sur un velo se comprend
Une methode changeDeVistesse sur un entier ne se comprend pas
Alors evidemment, on pourrait s'amuser a faire des methodes explicites sur les entiers.
Une methode add, une methode mul, ... Mais pourquoi se compliquer la vie alors qu'on peut faire des choses simples ... ?
Il ne s'agit pas d'etre sexy, mais d'etre efficace ...
[^] # Re: Java Virtual Machine 1.4.2 beta
Posté par Epsos . En réponse à la dépêche Java Virtual Machine 1.4.2 beta. Évalué à 7.
Les classes virtuelles te permettent de faire du polymorphisme, alors que la genericite te permet d'adaptater un algorithme a un type...
Ca permet entre autre d'avoir des vrais containers types, au lieu de ces infames Vector que l'on a en Java ...
[^] # Re: petite question sur les transfert dans le protocole http
Posté par Epsos . En réponse au journal petite question sur les transfert dans le protocole http. Évalué à 1.
Prefere un truc du genre *BinaryStream ...
La raison est que certains caracteres sont interpretes a la volee ...
Le \b, le \0 et d'autres caracteres ...
Lorsque tu lis un fichier binaire, fais toujours gaffe a ne jamais interpreter ce que tu lis : utilise un flux de lecture binaire ...
La doc QT suggere d'utiliser les readBlock sur QIODevice ...
Par l'intermediaire d'un QFile pour ce qui est de lire le fichier ...
Pour l'envoi sur la socket, QSocket est un QIODevice aussi, utilise la methode writeBlock ...
[^] # Re: Free ?
Posté par Epsos . En réponse au journal Free ?. Évalué à 3.
Ils se payent sur la connexion RTC ...
Sur leur solution pro ils touchent un max aussi ...
T'inquiete pas pour eux va ... Ils sont en pleines formes !
[^] # Re: Serveur CVS, lequel choisir ?
Posté par Epsos . En réponse au journal Serveur CVS, lequel choisir ?. Évalué à 4.
Non, la je crois qu'il n'y a qu'une seule implementation : cvs (qui fait a la fois client et serveur suivant comment tu le lances ...)
A mon avis, tu vas avoir besoin d'imprimer la page info de CVS.
Ca fait mal au debut, mais on s'y fait ! :-)
[^] # Re: Xine
Posté par Epsos . En réponse au journal Xine. Évalué à 2.
Ca plante ? pas d'image ? pas de son ?
Enfin bref pas tres detaille tout ca ...
Sinon, une solution magique si t'es sous Mandrake : tu ajoute plf comme source dans urpmi, et ensuite : 'urpmi xine' ... Et tu ne te posera plus de question ...
A+
# Re: pb de base rpm
Posté par Epsos . En réponse au journal pb de base rpm. Évalué à 3.
1 - ta base rpm est a la rue : reconstruit la (rpm --rebuild je crois)
2 - le nom que tu utilise dans 'rpm -q -a | grep' n'est pas le meme que celui que tu utilises dans rpmdrake
Tu peux essayer en ligne de commande avec urpmi, urpme, urpmf et urpmq.
C'est dommage que tu files pas le nom de ton package ca serait plus facile pour les exemples.
Mettons qu'il s'appelle toto ton prog.
$> rpm --rebuilddb
$> urpmf toto ==> ca va te dire quel package correspond au programme toto
toto-0.1.1-2mdk.rpm
$> urpmi toto-0.1.1
Si le urpmf ne te renvoie rien, tu peux essayer 'urpmq toto' qui est un peu plus bourrin (ca cherche tous les fichiers dans tous les packages qui contiennent la chaine toto)
S'il est deja installe, essaye un 'urpme toto' ...
Sinon, peut etre que ton package est liste dans /etc/urpmi/skip.list
Vala ...
[^] # Re: Keith Packard viré de XFree86
Posté par Epsos . En réponse à la dépêche Keith Packard viré de XFree86. Évalué à 0.
[^] # Re: Nosicalight version 0.2
Posté par Epsos . En réponse au journal Nosicalight version 0.2. Évalué à 1.
[^] # Re: Nosicalight version 0.2
Posté par Epsos . En réponse au journal Nosicalight version 0.2. Évalué à 1.
M'enfin, quand on voit des truc genre Obelix/Mobilix on est jamais trop prudent ...
[^] # Re: Nosicalight version 0.2
Posté par Epsos . En réponse au journal Nosicalight version 0.2. Évalué à 1.
En C++ le cast est sur a condition d'utiliser la bonne facon de faire (dynamic_cast)
En Nosica le cast est sur aussi...
Ca veut dire quoi ? Ca veut dire que dans les cas ambigus, il y a un test au runtime et le lancement d'une exception ...
Dans tous les cas tu ne pourras prendre un type B pour un type A s'il n'y a aucun rapport entre les deux. En plus s'il n'y a vraiment aucun rapport entre les deux, tu te fais jeter a la compil. Les cas un peu tendancieux sont ceux qui proviennent du downcasting ... Mais d'apres ce que j'en comprend, que tu fasses de l'invariance ou de la covariance il y aura forcement des cast (meme s'ils sont caches), et donc forcement des cas ou tu peux avoir un runtime failure.
Pour ce qui est de l'Ocaml, le peu que j'en connaisse ne m'a pas trop seduit. La plupart de la programmation objet en Ocaml est de la programmation generique (aka polymorphisme statique), et pas de la vrai programmation dynamique (aka polymorphisme dynamique).
De plus le systeme de variable unmutable impose un style de programmation que je n'aime pas du tout. Il est souvent obligatoire de passer par des algos recursifs a cause de ca.
Pour finir, si tu vas sur http://caml.inria.fr/FAQ/FAQ_EXPERT-eng.html#polymorphisme(...) tu verras qu'il existe un certains nombre de limitations au langage.
[^] # Re: Nosicalight version 0.2
Posté par Epsos . En réponse au journal Nosicalight version 0.2. Évalué à 1.
Il est possible de surcharger leurs methodes comme n'importe quel autre type ...
Les tableaux ne sont pas des types primitifs, ce sont des types references. Et ils sont invariants ...
2 - Non, on n'autorise pas a appeler une methode sans les () si elle n'a pas de parametres.(1 seule facon de faire c'est notre motto) Par contre l'utilisateur peut tres bien definir des proprietes ...
Ex :
class Toto
{
private A a;
public A propery a() const { return a; }
}
Toto toto = new Toto();
A a = toto.a; // call Toto.property a
3 - On a essaye d'etre le moins verbeux possible. (j'ai horreur de Eiffel a cause de ca)
4 - Le fameux ';' Effectivement on le traine, et je pense qu'on va le garder. C'est pas tres utile pour le langage effectivement, par contre c'est tres utile pour ce qui est du reporting d'erreur de la reprise sur erreur ...
5 - Quelque chose en plus... Et bien, il me semble que Nosica a deja quelque chose en plus :-) Bien sur, rien de revolutionnaire, mais pleins de petites choses qui en font je l'espere un langage sur, souple et efficace.
Pour ce qui est des trucs de killer, Nico a souleve pas mal de points importants pour ce qui est de l'optimisation. On espere un jour pouvoir faire du multithreading automatique pour accelerer les boucles ... (voir le forum pour plus de details)