May 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] cant remove accept: method

by Sean Allen

Pharo 1.0 I have a class that has a method accept: that is no longer used. When I go to remove it, I get the message: Possible call to accept: in XXXX Browse? If you do no, it doesn't remove the method. If you do yes, you can only browse, not remove. How can I remove the method short of filing out the class, removing the method and filing the class back in?

May 24, 2010

Re: [Pharo-project] Rome Canvas to replace an ordinary canvas [Was: Re: Rendering fonts on OpenGL ]

by StÃ©phane Ducasse

> Ok. Let me start. Excellent I want to learn. And I will ask cyrille to read all that. The first things is that we should get Rome working then we fix the api. > Rome/Athens adds variouls extension methods to classes which are > involved with graphics. > Here is one of them: > > GradientFillStyle>>installOnRomePluginCanvas: aCanvas > | colorStops i | > colorStops := WordArray new: colorRamp size * 3. > i := 0. > colorRamp do: [:stop | > colorStops at: (i:=i+1) put: (stop key * 65536.0) rounded. > colorStops at: (i:=i+1) put: stop value privateRGB. > colorStops at: (i:=i+1) put: stop value privateAlpha]. > radial == true > ifTrue: [ > aCanvas primFillRadialGradientOriginX: origin x asFloat > y: origin y asFloat > directionX: direction x asFloat > y: direction y asFloat > normalX: self normal x asFloat > y: self normal y asFloat > colorStops: colorStops] > ifFalse: [ > aCanvas primFillLinearGradientOriginX: origin x asFloat > y: origin y asFloat > directionX: direction x asFloat > y: direction y asFloat > colorStops: colorStops] > > Good: > - a conversion method is context sensitive (it takes a canvas as an argument) > Bad: > - this conversion method will work only for Rome plugin and nothing else. how to you see that? > This means, that if i'd want to use different canvas, i will need to > add another method > which will perform a conversion. you lost me there. But I ;m sure that you will explain it to me :) > But this can be avoided, if we provide a generic canvas method to > create a gradient fills. > Then this method could be renamed to #installOnRomeCanvas: > and implementation will consist of messages, sent to canvas to build a > gradient fill. do you have a sketch that I follow the example 100% > Another example: > > asRomeFill , asRomeFont > > - this is bad. > Its not a context-sensitive. And therefore , an implementation of > these methods assumes that it will provide > the most suitable conversion of fill or font for Rome backend. > But depending on backend, it may not be the case! > So, all methods like this, should always use a canvas as argument and > talk back to canvas > to perform a conversion. I see we need a factory and the canvas will play this role. Stef > >> Stef >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 24, 2010

Re: [Pharo-project] Concurrency in Pharo?

by StÃ©phane Ducasse

you know dabbledb, cmsbox and other are all based on squeak/pharo so you heart does not have to sink yet :) Stef On May 24, 2010, at 8:36 PM, Andrei Stebakov wrote: > I've been really impressed with what Seaside and Pier were capable of and really wanted to start my new web project with Pharo. > I learned that Pharo (and most other open source ST implementations) only use green threads, having no ability to use a multi-core CPU systems. > For those of you with experience building mid to heavy load web sites, how do you expect them to scale up on using just one core? > Is Pharo a right tool for that? > Maybe Pharo (Squeak) has something up its sleeve to handle this, but my heart really sank when I learned about this issue... > > Thank you, > Andrei > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 24, 2010

Re: [Pharo-project] Rome Canvas to replace an ordinary canvas [Was: Re: Rendering fonts on OpenGL ]

by Igor Stasenko

On 24 May 2010 21:16, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Guess what is my choice :) > >>>>> >> Yes. But i want to stress, what meaning we are putting into 'API'. > > the real one :) >> >> API is protocols, not classes. > > >> So, a code which renders something using API, should use only messages >> sent to a canvas object. >> The difference could be illustrated by following: >> >> a) >> drawOn: aCanvas >> >> Â path := RomePath new. >> Â path moveTo: .. lineTo:... close. >> Â aCanvas strokePath: path >> >> b) >> drawOn: aCanvas >> >> Â path := aCanvas newPath. >> Â path moveTo: .. lineTo:... close. >> Â aCanvas strokePath: path >> >> In case a) you are introducing a dependency on a concrete path >> implementation(RomePath). >> in case b) you asking a canvas to provide a path instance, which >> conforms to a path protocol. >> >> Here lies the main difference, which either gives you a freedom of >> choice, or otherwise makes your code inflexible. >> That's what i mean by no dependecy. > > I understood it :) > >> In case b), a rendering backend is >> free to use own data structures >> to optimally reify a path(s), while in case a) you forcing a canvas to >> have an intimate knowledge about RomePath >> - a concrete implementation, which may not fit best for canvas and >> hence it will waste cycles converting a path >> representation into more appropriate form, in order to render it. >> >> That's why, if we follow path b), then morphic rendering could be >> completely autonomous, >> and do not depend on concrete Rome API implementation. >> And enforcing it from a very starting, will make sure that we won't >> introduce unnecessary >> dependencies and inflexibility. > > so this is why it would be good to have a concrete scenario to stress and validate > the Athens new canvas > I would really like to see how the one of Morphic 30 will fit into it too. > Me too! > So let us start like that: > Â Â Â Â - design your API with flexibility in mind + ROME from the point of you of Canvas method > Â Â Â Â - give feedback about athens inflexibility > Â Â Â Â - we update it > Â Â Â Â - we iterate > the goal should be that at the end we can get really fast a different back-end. > With a bit of chance we will d the same with Morphic30 and we will have a cool system. > Ok. Let me start. Rome/Athens adds variouls extension methods to classes which are involved with graphics. Here is one of them: GradientFillStyle>>installOnRomePluginCanvas: aCanvas | colorStops i | colorStops := WordArray new: colorRamp size * 3. i := 0. colorRamp do: [:stop | colorStops at: (i:=i+1) put: (stop key * 65536.0) rounded. colorStops at: (i:=i+1) put: stop value privateRGB. colorStops at: (i:=i+1) put: stop value privateAlpha]. radial == true ifTrue: [ aCanvas primFillRadialGradientOriginX: origin x asFloat y: origin y asFloat directionX: direction x asFloat y: direction y asFloat normalX: self normal x asFloat y: self normal y asFloat colorStops: colorStops] ifFalse: [ aCanvas primFillLinearGradientOriginX: origin x asFloat y: origin y asFloat directionX: direction x asFloat y: direction y asFloat colorStops: colorStops] Good: - a conversion method is context sensitive (it takes a canvas as an argument) Bad: - this conversion method will work only for Rome plugin and nothing else. This means, that if i'd want to use different canvas, i will need to add another method which will perform a conversion. But this can be avoided, if we provide a generic canvas method to create a gradient fills. Then this method could be renamed to #installOnRomeCanvas: and implementation will consist of messages, sent to canvas to build a gradient fill. Another example: asRomeFill , asRomeFont - this is bad. Its not a context-sensitive. And therefore , an implementation of these methods assumes that it will provide the most suitable conversion of fill or font for Rome backend. But depending on backend, it may not be the case! So, all methods like this, should always use a canvas as argument and talk back to canvas to perform a conversion. > Stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

May 24, 2010

Re: [Pharo-project] Concurrency in Pharo?

by Lukas Renggli

> I've been really impressed with what Seaside and Pier were capable of and > really wanted to start my new web project with Pharo. GemStone/S runs Seaside and Pier and scales across multiple CPUs infinitely, if scalability with Pharo should be a problem. Lukas -- Lukas Renggli www.lukas-renggli.ch

May 24, 2010

Re: [Pharo-project] Concurrency in Pharo?

by Dale Henrichs

Andrei, GemStone/S and GLASS provides a free for commercial use multi-vm environment that provides "image-based persistence". With an annual license you can use multiple vms across multiple cores. A number of folks using GemStone develop in Pharo and deploy in GemStone, so that mode of operation is realistic... Dale Mariano Martinez Peck wrote: > This is a good question. I don't have experience by myself but I can tell you what I think it is usually done: > > 1) For one CPU: > > If the image don't need to be saved (no need of in image persistence) you can take the same VM and load N number of images running at the same .image. You can even not use .changes and .sources. Each image in different port. Then, you have in front of them a web server (Apache or friends) and you do load balance. The only thing you should take care with Seaside is to have AFFINITY -> the same client should go always to the same image while a conversation occurs. This is just a web-server setting. > > 2) For multiple core, I am thinking, maybe I am wrong, you may be able to load different vms. For assigning each VM to a particular CPU. I don't know windows, but in Linux (maybe I am wrong) I think you can specify where to exclusively run a process. The, for each VM you do 1). > Do you know if this can work? > > Finally, there are different VM that aim not necessary multiple CPU but similar: > > - COG VM > - Hydra > > I cc'ed may developers of them so that they can help you. > > Cheers > > Mariano > > > 2010/5/24 Andrei Stebakov <lispercat(a)gmail.com<mailto:lispercat@gmail.com>> > I've been really impressed with what Seaside and Pier were capable of and really wanted to start my new web project with Pharo. > I learned that Pharo (and most other open source ST implementations) only use green threads, having no ability to use a multi-core CPU systems. > For those of you with experience building mid to heavy load web sites, how do you expect them to scale up on using just one core? > Is Pharo a right tool for that? > Maybe Pharo (Squeak) has something up its sleeve to handle this, but my heart really sank when I learned about this issue... > > Thank you, > Andrei > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

May 24, 2010

Re: [Pharo-project] Concurrency in Pharo?

by Mariano Martinez Peck

This is a good question. I don't have experience by myself but I can tell you what I think it is usually done: 1) For one CPU: If the image don't need to be saved (no need of in image persistence) you can take the same VM and load N number of images running at the same .image. You can even not use .changes and .sources. Each image in different port. Then, you have in front of them a web server (Apache or friends) and you do load balance. The only thing you should take care with Seaside is to have AFFINITY -> the same client should go always to the same image while a conversation occurs. This is just a web-server setting. 2) For multiple core, I am thinking, maybe I am wrong, you may be able to load different vms. For assigning each VM to a particular CPU. I don't know windows, but in Linux (maybe I am wrong) I think you can specify where to exclusively run a process. The, for each VM you do 1). Do you know if this can work? Finally, there are different VM that aim not necessary multiple CPU but similar: - COG VM - Hydra I cc'ed may developers of them so that they can help you. Cheers Mariano 2010/5/24 Andrei Stebakov <lispercat(a)gmail.com> > I've been really impressed with what Seaside and Pier were capable of and > really wanted to start my new web project with Pharo. > I learned that Pharo (and most other open source ST implementations) only > use green threads, having no ability to use a multi-core CPU systems. > For those of you with experience building mid to heavy load web sites, how > do you expect them to scale up on using just one core? > Is Pharo a right tool for that? > Maybe Pharo (Squeak) has something up its sleeve to handle this, but my > heart really sank when I learned about this issue... > > Thank you, > Andrei > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 24, 2010

Re: [Pharo-project] Cross-fork Metacello configurations

by Dale Henrichs

Miguel Enrique CobÃ¡ Martinez wrote: > > I don't dislike Squeak usage but changing a emerging technology that is > being used in a given way and that appears to be working (I've done the > Magma configuration and I tested it worked on Squeak and Pharo) but this > new Squeak usage of Metacello really discourages to try to keep the > Magma for other distros than Pharo. It really is a gratuitous change and > I don't really have the time to sync two ways to use the same > technology. > > Miguel, I'm not going to defend how the Squeak folks are using Metacello, but I will say that they have a slightly different use case and they are currently exploring the possibilities in support of that use case. For the moment I would take a wait and see attitude, while continuing to maintain your cross-platform configurations. Think of your users...Magma is used on both Squeak and Pharo and a cross -platform configuration _is_ the best way for you to publish the information... In the absolutely worst case scenario (i.e., impossible to load the Magma config because of class name conflicts) it will be possible for your users to unload the "configuration package" and use your config, then reload the "configuration package". Hopefully, the Squeak folks will settle on an approach that is compatible with cross-platform configs without requiring drastic measures... Dale

May 24, 2010

[Pharo-project] Concurrency in Pharo?

by Andrei Stebakov

I've been really impressed with what Seaside and Pier were capable of and really wanted to start my new web project with Pharo. I learned that Pharo (and most other open source ST implementations) only use green threads, having no ability to use a multi-core CPU systems. For those of you with experience building mid to heavy load web sites, how do you expect them to scale up on using just one core? Is Pharo a right tool for that? Maybe Pharo (Squeak) has something up its sleeve to handle this, but my heart really sank when I learned about this issue... Thank you, Andrei

May 24, 2010

[Pharo-project] PhD thesis potentially in Smalltalk

by StÃ©phane Ducasse

Hi guys This team has a Phd position which can be done in Smalltalk. Christophe Dony is an old smalltalk fan in the south of france. He supervised the PhD of Luc fabresse who is working with Noury (and working on Socket for Pharo right now). If you are interested please contact chouki directly. Stef Begin forwarded message: > From: Chouki TIBERMACINE <Chouki.Tibermacine(a)lirmm.fr> > Date: May 15, 2010 11:59:01 PM GMT+02:00 > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Cc: Christophe Dony <dony(a)lirmm.fr>, Bouraqadi Noury <bouraqadi(a)gmail.com>, Fabresse Luc <fabresse(a)ensm-douai.fr> > Subject: Re: [Lmo-conference] ThÃ¨se en ingÃ©nierie des composants logiciels Ã Montpellier > > VoilÃ la version anglaise. > > Chouki. > > --- > TITLE: A Reflective Component-Oriented Programming Language > > SUPERVISORS: Chouki TIBERMACINE (tibermacin(a)lirmm.fr) and Christophe DONY (dony(a)lirmm.fr) > > FUNDING: French Government Fellowship (~1500 euros gross salary per month) > > PLACE: LIRMM, CNRS and Montpellier University (South of France) > > SUBJECT: > > Research on the modeling and implementation of applications by assembling components is growing up more and more. Component-based development allows the definition of independent software modules which are put in libraries, available on catalog, and assemblable as deployment and runtime units. > > In our research lab, we developed a voluntarily simple component-oriented programming language (SCL), which allowed an original and innovative integration of the concepts of component, port, interface, connector and aspect (see [1]). > > Component languages are used now in modeling environments in association with architecture description languages. We would like to study, on the basis of SCL, a reflective solution mixing a programming and an architecture description language, which allows: > - to link entities of conceptual reuse (component descriptors) with units of integration (component instances), > - via a reflective architecture and an API of meta-programming, allowing introspection and intercession, to describe with the same language architectures, constraints on these architectures (non-functional constraints as specified in [2]), and model transformations. > > Two SCL prototypes have been implemented in Smalltalk and Ruby. A prototype of the new language can be developed in JAVA or another language, and integrated with the Eclipse plugin of modeling component-based application (CLACS). > > [1] Luc Fabresse, Christophe Dony, and Marianne Huchard. > Foundations of a simple and unified component-oriented language. > Journal of Computer Languages, Systems and Structures, 34(2-3):130-149, Elsevier 2008. > > [2] Chouki Tibermacine, RÃ©gis Fleurquin, and Salah Sadou. > A family of languages for architecture constraint specification. > Journal of Systems and Software 83(5):815-831, Elsevier 2010. > --- > > Le 15/05/10 22:52, StÃ©phane Ducasse a Ã©crit : >> tu as une version en anglais? >> >> Stef >> >> On May 15, 2010, at 10:43 PM, Chouki TIBERMACINE wrote: >> >> >>> C'est ok pour l'orienter sur notre sujet. >>> Merci d'avance :-) . >>> >>> Chouki. >>> >>> Le 15/05/10 22:13, StÃ©phane Ducasse a Ã©crit : >>> >>>> chouki >>>> >>>> je peux le contacter en lui disant que notre bourse a ete supprimee et que votre sujet peut l'interesser. >>>> J'attends ton ok. >>>> >>>> Stef >>>> >>>> >>>> >>>>> Oui, bien sÃ»r, avec plaisir ;-) . >>>>> >>>>> Chouki. >>>>> >>>>> Le 15/05/10 21:51, StÃ©phane Ducasse a Ã©crit : >>>>> >>>>> >>>>>> chouki >>>>>> >>>>>> si vous etes vraiment pret a avoir un mec qui parait bon en langage et qui est interesse je peux vous mettre en contact >>>>>> avec un des etudiants tchec dont nous avons recu un cv pour une these langage (mais que pour des raisons de strategie inria nous >>>>>> avons du abandonnee). Nous l'aurions surement embauche si la these ne devait pas etre allouee sur un autre sujet. >>>>>> >>>>>> Stef >>>>>> >>>>>> On May 15, 2010, at 9:14 PM, Chouki TIBERMACINE wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Merci StÃ©phane pour ces prÃ©cisions. >>>>>>> >>>>>>> En fait, on propose d'utiliser Java pour la future implÃ©mentation pour la simple raison qu'il est trÃ¨s difficile de nos jours de trouver un Ã©tudiant qui soit bon et qui voudrait bien travailler sur Smalltalk. >>>>>>> Si vous avez Ã Lille un bon Ã©tudiant Ã nous recommander, on est preneur. On le fera travailler sur Smalltalk (et Pharo) ;-) . >>>>>>> >>>>>>> On va regarder de prÃ¨s CLIC. Merci pour l'info :-) . >>>>>>> >>>>>>> Chouki. >>>>>>> >>>>>>> Le 15/05/10 17:04, StÃ©phane Ducasse a Ã©crit : >>>>>>> >>>>>>> >>>>>>> >>>>>>>> quel est la pertinence d'utiliser Java? >>>>>>>> conquerir le monde au travers d'eclipse? Bonne chance. :) >>>>>>>> >>>>>>>> peut etre que vous devriez contacter noury car il a un modele a composant >>>>>>>> CLIC >>>>>>>> >>>>>>>> Nous on s'amuse bien avec >>>>>>>> http://www.pharo-project.org >>>>>>>> >>>>>>>> et pas de societes aiment cela donc cela ne doit pas etre si mauvais que cela >>>>>>>> et c'est que le debut :) >>>>>>>> >>>>>>>> >>>>>>>> Stef >>>>>>>> >>>>>>>> PS: java c'est plus a la mode. maintenant c'est javascript :) >>>>>>>> et javascript va avoir les traits aussi ... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On May 15, 2010, at 2:12 PM, Chouki TIBERMACINE wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> --- Merci de diffuser autour de vous >>>>>>>>> >>>>>>>>> THÃSE EN GÃNIE LOGICIEL / PROGRAMMATION >>>>>>>>> >>>>>>>>> TITRE : Langage rÃ©flexif de programmation par composants >>>>>>>>> >>>>>>>>> ENCADRANTS : Chouki TIBERMACINE (tibermacin(a)lirmm.fr) et Christophe DONY >>>>>>>>> (dony(a)lirmm.fr) >>>>>>>>> >>>>>>>>> BOURSE : Allocation de recherche MENRT >>>>>>>>> >>>>>>>>> LIEU : LIRMM, CNRS et UniversitÃ© de Montpellier >>>>>>>>> >>>>>>>>> RÃSUMÃ : >>>>>>>>> >>>>>>>>> Les recherches sur la modÃ©lisation et l'implÃ©mentation d'applications >>>>>>>>> par assemblages de composants sont maintenant passÃ©es Ã l'Ã©chelle. Le >>>>>>>>> dÃ©veloppement par composants vise Ã permettre la production de >>>>>>>>> composants indÃ©pendants stockÃ©s dans des bibliothÃ¨ques, consultables sur >>>>>>>>> catalogue et assemblables en unitÃ©s d'exÃ©cution et de dÃ©ploiement. >>>>>>>>> >>>>>>>>> Nous avons rÃ©alisÃ© au LIRMM un langage de programmation par composants >>>>>>>>> (SCL) volontairement simple, qui a permis une intÃ©gration originale et >>>>>>>>> novatrice des concepts de composant, de port, d'interface, de >>>>>>>>> connecteurs et d'aspects (voir [1]). >>>>>>>>> >>>>>>>>> Les langages Ã composants s'utilisent maintenant en intÃ©gration dans les >>>>>>>>> environnements de modÃ©lisation et en connexion avec un langage de >>>>>>>>> description d'architecture. Nous souhaitons Ã©tudier, sur les bases de >>>>>>>>> SCL, un langage mixte, de programmation et de modÃ©lisation >>>>>>>>> d'architectures, rÃ©flexif, qui permettra : >>>>>>>>> - de faire le lien entre les entitÃ©s de rÃ©utilisation conceptuelles que >>>>>>>>> sont les descripteurs de composants et les unitÃ©s d'intÃ©gration que sont >>>>>>>>> les instances de composants, >>>>>>>>> - via une architecture rÃ©flexive et une API de mÃ©ta-programmation >>>>>>>>> permettant l'introspection et l'intercession, d'Ã©crire, ou de dÃ©crire, >>>>>>>>> avec le mÃªme langage des architectures, des contraintes sur ces >>>>>>>>> architectures (contraintes non-fonctionnelles selon les modÃ¨les >>>>>>>>> dÃ©veloppÃ©s par C. Tibermacine dans [2]), ainsi que des transformations >>>>>>>>> de modÃ¨les. >>>>>>>>> >>>>>>>>> Deux prototypes de SCL ont Ã©tÃ© implÃ©mentÃ©s en Smalltalk et en Ruby. Un >>>>>>>>> prototype de ce nouveau langage pourra Ãªtre dÃ©veloppÃ© en JAVA ou autre >>>>>>>>> et intÃ©grÃ© au plugin Eclipse de modÃ©lisation d'applications par >>>>>>>>> composants, CLACS. >>>>>>>>> >>>>>>>>> [1] Luc Fabresse, Christophe Dony, and Marianne Huchard. >>>>>>>>> Foundations of a simple and unified component-oriented language. >>>>>>>>> Journal of Computer Languages, Systems and Structures, 34(2-3):130-149, >>>>>>>>> Elsevier 2008. >>>>>>>>> >>>>>>>>> [2] Chouki Tibermacine, RÃ©gis Fleurquin, and Salah Sadou. >>>>>>>>> A family of languages for architecture constraint specification. >>>>>>>>> Journal of Systems and Software 83(5):815-831, Elsevier 2010. >>>>>>>>> >>>>>>>>> Bien cordialement, >>>>>>>>> >>>>>>>>> Christophe Dony& Chouki Tibermacine. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Chouki TIBERMACINE, PhD >>>>>>>>> Associate Professor in Computer Science >>>>>>>>> LIRMM - CNRS and University of Montpellier II - France >>>>>>>>> Office Phone: +33(or 0).467.149.724 >>>>>>>>> Lab Fax: +33(or 0).467.418.500 >>>>>>>>> Web Page: http://www.lirmm.fr/~tibermacin/ >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Lmo-conference mailing list >>>>>>>>> Lmo-conference(a)email.polytech.unice.fr >>>>>>>>> http://email.polytech.unice.fr/mailman/listinfo/lmo-conference >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> -- >>>>>>> Chouki TIBERMACINE, PhD >>>>>>> Associate Professor in Computer Science >>>>>>> LIRMM - CNRS and University of Montpellier II - France >>>>>>> Office Phone: +33(or 0).467.149.724 >>>>>>> Lab Fax: +33(or 0).467.418.500 >>>>>>> Web Page: http://www.lirmm.fr/~tibermacin/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> -- >>>>> Chouki TIBERMACINE, PhD >>>>> Associate Professor in Computer Science >>>>> LIRMM - CNRS and University of Montpellier II - France >>>>> Office Phone: +33(or 0).467.149.724 >>>>> Lab Fax: +33(or 0).467.418.500 >>>>> Web Page: http://www.lirmm.fr/~tibermacin/ >>>>> >>>>> >>>>> >>> >>> -- >>> Chouki TIBERMACINE, PhD >>> Associate Professor in Computer Science >>> LIRMM - CNRS and University of Montpellier II - France >>> Office Phone: +33(or 0).467.149.724 >>> Lab Fax: +33(or 0).467.418.500 >>> Web Page: http://www.lirmm.fr/~tibermacin/ >>> >>> > > > -- > Chouki TIBERMACINE, PhD > Associate Professor in Computer Science > LIRMM - CNRS and University of Montpellier II - France > Office Phone: +33(or 0).467.149.724 > Lab Fax: +33(or 0).467.418.500 > Web Page: http://www.lirmm.fr/~tibermacin/ >

May 24, 2010