Damien Cassou a écrit 50 commentaires

Je suis aussi l'heureux possesseur d'un Kinesis contoured advantage depuis 3 ans. Je recommande à tous, mais il est cher.

Si vous cherchez des paquetages Emacs récents pour votre Debian ou votre Ubuntu : http://emacs.naquadah.org/

Ce projet va dans la direction de dabbledb qui a malheureusement fermé ses portes depuis 1 an (racheté par Twitter). Une vidéo montre les capacités qu'avait dabbledb. Par exemple, les bases de données avaient plusieurs tables qui pouvaient se référencer ce que ne semble pas encore permettre EditableGrid. dabbledb permettait aussi d'avoir des vues sous forme de cartes pour les données de type adresses. dabbledb permettait aussi de grouper des éléments dans les vues : par exemple, dans le cas d'une table Livres, je pouvais voir toutes les lignes d'un auteur regroupées avec le nom de l'auteur au-dessus (et donc sans colonne 'auteur' ce qui rend la lecture plus agréable). dabbledb me manque et j'espère que EditableGrid ira dans le même sens.

Il ne me semble pas avoir dit que dabbledb était implémenté en Smalltalk avec le framework web Seaside :-).

La même vidéo avec un peu plus de contexte : http://www.pharocasts.com/2010/08/see-how-to-get-data-from-url-parse-xml.html

Merci à Laurent pour tous ses screencasts et pour m'avoir aidé avec la dépêche.

Je suis d'accord avec toi. L'intégration avec l'extérieur représente le gros de notre travail actuellement : utilisation de git comme backend (Cypress), utilisation de Pharo pour écrire des scripts (Coral), micro noyau (pour intégrer Pharo dans d'autres environnements), …

Tout à fait d'accord. Sans avoir vu cette demande, j'en ai rédigée une similaire : http://linuxfr.org/suivi/trier-les-liens-lors-de-la-redaction-d-une-depeche

Preum's

Malheureusement, je n'ai pas la version originale de l'entretien

Salut,

excellent jeu. Si tu veux qu'on envoie des patchs, ça serait peut-être plus simple de mettre un lien pour télécharger une archive avec toutes les sources.

Certains étaient en train de préparer une autre news sur le sujet. Elle est un peu plus complète : http://code.google.com/p/pharo/wiki/Pharo10FrenchAnnouncemen(...)

Je ne sais pas comment est implémenté le passage de messages en Objective-C, mais je sais que certains langages ont un algorithme de recherche de la méthode a appeler (en fonction des arguments et du type). En ce qui concerne ooc, l'appel d'une fonction membre implique seulement deux déréférencements de pointeurs, donc c'est relativement peu coûteux.

Je dois manquer quelque chose. Dans l'exemple suivant:


class Wheel {

func roll {printf("Quelque-chose ne tourne pas rond.\n");}

}

class BetterWheel from Wheel {
override roll {printf("Pierre qui roule n'amasse pas mousse\n");}
}

func main {

BetterWheel bw = new;

Wheel w2 = (Wheel) bw; // cast as in C/Java
w2.roll; // prints "Pierre qui roule", etc.

}


Lors de la compilation de w2.roll, tu associes l'appel à roll à la méthode roll de Wheel (le type statique de w2). Lors de l'exécution, il te faut exécuter la méthode roll de BetterWheel et pas celle de Wheel.

Le principe de base étant de partir de la classe dynamique de l'objet pour remonter la chaîne d'héritage jusqu'à tomber sur une implémentation de la méthode appelée.

C'est pas ça que tu fais ?

- Objective-C utilise l'envoi de messages au lieu de l'appel de méthode

Pour moi «envoi de message» signifie juste que tu vas choisir la méthode à appeler (son implémentation) au moment de l'exécution et pas de la compilation. Quand tu fais de l'objet, je ne vois pas bien comment tu pourrais faire autrement : tu choisis la méthode en fonction du type dynamique de ton objet que tu ne connais pas, par définition, au moment de la compilation. Tu as une autre définition qui te permet de dire que vous avez 2 approches différentes ?

Merci de faire cette sélection régulièrement. Je trouve que c'est une très bonne idée.

Surcouf propose des ordinateurs portables et fixes avec système d'exploitation en option (http://www.surcouf.com/Operation/operation.aspx?page=/OP/int(...)

En fait, si tu regardes les urls de la news, elles pointent presque toutes vers seaside.st qui est un site web écrit en Seaside (en fait, c'est fait avec le CMS Pier qui est implémenté au dessus de Seaside). Donc, les urls sont bien bookmarkables.

En fait, si tu codais en Smalltalk comme en Java ou en PHP, ta remarque serait tout à fait valable. Sauf qu'en Smalltalk (avec les IDE comme Squeak ou Cincom Smalltalk), tu as accès au code des bibliothèques que tu utilises aussi facilement qu'à ton propre code. Ce qui fait que quand tu souhaites utiliser une classe, tu commences par ouvrir un navigateur de code sur cette classe et tu peux voir immédiatement son commentaire et ses méthodes. C'est un des gros avantages par rapport à une approche de type documentation séparée : on a la doc et le code juste sous la main pour bien voir ce qui se passe.

http://www.cincomsmalltalk.com

La question n'est pas bête du tout, mais la réponse se trouve en partie dans la nouvelle :-). Ce que j'apprécie tout particulièrement dans Seaside :

- l'approche composant qui permet de vraiment découper son application web en petites parties réutilisables.
- la génération de code XHTML à partir de code Smalltalk.
- les outils de développement directement accessible dans le navigateur.
- sa simplicité une fois qu'on a lâché les ponts avec ce que l'on connaît déjà.
- le langage Smalltalk

En fait, ton Seaside va tourner derrière un serveur web qui va faire le load balancing entre plusieurs serveurs et plusieurs machines. Par contre, il est vrai que Seaside reste gourmand en mémoire même si la situation a été grandement améliorée avec cette nouvelle version.

En fait, je suis presque sûr qu'il y avait bien moins de classes commentées que 99 dans la version précédente. Le 99 auquel tu fais références est la base qui a servi à Roger Whitney pour écrire les 45 autres commentaires. Mais Lukas et Philippe en avait déjà commenté un bon paquet avant.

Il faut voir aussi que Seaside (sauf erreur) existait avant Ruby on Rails (2002 environ pour Seaside, 2004 pour Rails) et avant beaucoup d'autres frameworks web.

Comme d'autres l'ont dit, l'approche est complètement différente et apprendre à utiliser Seaside permet de mieux se rendre compte des limitations des autres frameworks.

C'est parce que les gens "restent sur ruby on rails" ou Java que Smalltalk n'a pas une grosse communauté. Je pense que l'apprentissage de Smalltalk et de Seaside peut apporter beaucoup même si l'on n'en fait pas au quotidien.

C'est aussi comme cela que je l'ai compris.

Ma prochaine carte graphique sera une AMD si cette annonce est confirmée dans les faits.

> Un truc que je trouve pas terrible dans Smalltalk est la déclaration des variables au début du bloc, une idée qui a fait son temps et a ajouter a la liste des mauvaise idée dont on doit se débarrasser: la déclaration des variable lors de leur première affectation est une bien meilleure idée.

Le problème ne se pose pas vraiment en Smalltalk. La taille moyenne d'une méthode doit être de 7 lignes environ. Contrairement aux autres langages, déclarer toutes les variables au début du bloc rend le code plus court : on déclare toutes les variables en une seule ligne. Par exemple pour déclarer 2 variables :

|persons folders|

Pour installer Seaside, vous avez besoin d'une machine virtuelle ainsi que de l'image.

- La machine virtuelle peut se trouver dans votre système de paquetage si vous en avez un. Sinon : http://www.squeakvm.org/.

- Vous trouverez l'image sur le site officiel ou directement sur http://damien.cassou.free.fr/squeak-web/.

Pour avoir le code source de Squeak et éviter un message d'erreur au démarrage, télécharger http://damien.cassou.free.fr/squeak-dev/SqueakV39.sources et placer le fichier avec la VM ou avec l'image.

N'hésitez pas à demander sur les mailing listes ou sur IRC. Voir http://www.squeak.org/Community/.