- Pharo-dev - lists.pharo.org

[Pharo-project] RE : RE : RE : NewClassOrganizer
by Philippe Back Sept. 9, 2012

Sept. 9, 2012

300Megs with Eclipse. With the base install you mean. We do hit triple that over here... SOA/JEE and some CLM plugins involved. Ah RAM is cheap. The problem is that all programs think they need it all these days. Philippe Back GOUBIER Thierry <thierry.goubier(a)cea.fr> a Ã©crit : WzYou are a very directive kind of person, when it comes to thoses things... If a user want it classified his way, who am I to change his ordering ? No, the solution isn't yet another level of ill-defined "pattern matching" to try to get that result. Smalltalk has, from the beginning, been able to show good practice by letting it's developpers set well though-out conventions themselves, and by giving them the freedom to do so (maybe not consciously in some cases, but still). Regressing on that isn't good. Well, I personnaly will rebuilt yet another RPackage like system to get what I need, obviously. By the way, have you noticed that on some systems, Pharo 2.0 starts to feel slow to use ? Thierry ________________________________________ De : pharo-project-bounces(a)lists.gforge.inria.fr [ pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Camillo Bruni [ camillobruni(a)gmail.com] Date d'envoi : dimanche 9 septembre 2012 13:25 Ã : Pharo-project(a)lists.gforge.inria.fr Objet : Re: [Pharo-project] RE : NewClassOrganizer On 2012-09-09, at 13:18, GOUBIER Thierry <thierry.goubier(a)cea.fr> wrote: > > ________________________________________ > De : pharo-project-bounces(a)lists.gforge.inria.fr [ pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Camillo Bruni [ camillobruni(a)gmail.com] > Date d'envoi : dimanche 9 septembre 2012 12:48 > Ã : Pharo-project(a)lists.gforge.inria.fr > Objet : Re: [Pharo-project] NewClassOrganizer > >> Ordering of protocols should happen in the Browser not in the model. > > Hum, it looks like to save a few lines there, it's gonna cost a few thousands lines and caching complexity in the Browser. I doubt that you'll need any caching there, for any given protocol finding the proper methods should be O(1), so the only thing that's left is ordering the protocol. - define a global ordered collection of predefined categories which will be sorted first - sort the rest alphabetically... so that's an O(n) lookup overhead for the all the entries. given that there is hardly any class defining 100 protocols you can redo that calculation as often as you want... >> Protocols are simple dictionary entries, the old implementation simply >> did not want to use dicts for performance / space reasons. > >> I doubt that we will add explicit ordering to protocols... > > Then the new implementation looks worse than the previous one, from a GUI point of view in addition to the performance / space ones. not at all... the old categories are a big mess without any documentation => nobody will every maintain that and as mentioned above, the only trade-off is space, which honestly you cannot complain about unless we hit something like a 300MB boundary like Eclipse...

3 2

[Pharo-project] NewClassOrganizer
by GOUBIER Thierry Sept. 9, 2012

Sept. 9, 2012

Hi all, I'm looking at the NewClassOrganizer package. Is that part of the system reimplementation effort ? In it, I'm worried by ClassOrganization>>addCategory: aProtocolName before: aUselessArgument. I want to be able to fix the ordering of protocols when I develop (it's more to my taste, as an old-timer, to have usually initialization / instance creation on top of the protocol list, and private at the bottom... Alphabetical ordering of protocols is far less satisfying, and an implementation which force an internal reordering contrary to my whishes would be problematic). Thierry

2 5

[Pharo-project] RE : RE : RE : NewClassOrganizer
by Philippe Back Sept. 9, 2012

Sept. 9, 2012

I happen to like to be able to have the protocols the way Thierry describes. Protocols are a distinctive feature of Smalltalk. Why allow ourselves anything else than stellar support for them? Private goes to the bottom, accessors to the top. And the rest the way we want it. Anyway, we'll soon have the TG_patch... Philippe Back GOUBIER Thierry <thierry.goubier(a)cea.fr> a Ã©crit : You are a very directive kind of person, when it comes to thoses things... If a user want it classified his way, who am I to change his ordering ? No, the solution isn't yet another level of ill-defined "pattern matching" to try to get that result. Smalltalk has, from the beginning, been able to show good practice by letting it's developpers set well though-out conventions themselves, and by giving them the freedom to do so (maybe not consciously in some cases, but still). Regressing on that isn't good. Well, I personnaly will rebuilt yet another RPackage like system to get what I need, obviously. By the way, have you noticed that on some systems, Pharo 2.0 starts to feel slow to use ? Thierry ________________________________________ De : pharo-project-bounces(a)lists.gforge.inria.fr [ pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Camillo Bruni [ camillobruni(a)gmail.com] Date d'envoi : dimanche 9 septembre 2012 13:25 Ã : Pharo-project(a)lists.gforge.inria.fr Objet : Re: [Pharo-project] RE : NewClassOrganizer On 2012-09-09, at 13:18, GOUBIER Thierry <thierry.goubier(a)cea.fr> wrote: > > ________________________________________ > De : pharo-project-bounces(a)lists.gforge.inria.fr [ pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Camillo Bruni [ camillobruni(a)gmail.com] > Date d'envoi : dimanche 9 septembre 2012 12:48 > Ã : Pharo-project(a)lists.gforge.inria.fr > Objet : Re: [Pharo-project] NewClassOrganizer > >> Ordering of protocols should happen in the Browser not in the model. > > Hum, it looks like to save a few lines there, it's gonna cost a few thousands lines and caching complexity in the Browser. I doubt that you'll need any caching there, for any given protocol finding the proper methods should be O(1), so the only thing that's left is ordering the protocol. - define a global ordered collection of predefined categories which will be sorted first - sort the rest alphabetically... so that's an O(n) lookup overhead for the all the entries. given that there is hardly any class defining 100 protocols you can redo that calculation as often as you want... >> Protocols are simple dictionary entries, the old implementation simply >> did not want to use dicts for performance / space reasons. > >> I doubt that we will add explicit ordering to protocols... > > Then the new implementation looks worse than the previous one, from a GUI point of view in addition to the performance / space ones. not at all... the old categories are a big mess without any documentation => nobody will every maintain that and as mentioned above, the only trade-off is space, which honestly you cannot complain about unless we hit something like a 300MB boundary like Eclipse...

1 0

[Pharo-project] RPackage question
by Goubier Thierry Sept. 9, 2012

Sept. 9, 2012

I'm trying to see what's happening with bug 6647, since it's pretty dangerous for development on Pharo 2.0 at the moment, and annoying as well. So I'm looking at RPackageOrganizer packages key and is there a reason for some keys to have quotes and others not ? for example : #Nautilus and #'Ring-Core-Kernel' Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

3 4

[Pharo-project] git support
by Camillo Bruni Sept. 8, 2012

Sept. 8, 2012

who will help? max and I, stimulated by ESUG, worked on the latest version of FS-Git to make it stable again. we are very close to have a complete set of git tools written in pharo ready! missing ======= - a better mc integration - a cypress compatible fileout format - complete interaction with the git protocol - a direct way to commit stuff as always my time is somewhat limited as well and we're the only two developers working on it... The current work is available here: http://ss3.gemstone.com/ss/FSGit-Experimental.html https://github.com/dalehenrich/FSGit best cami

6 15

[Pharo-project] [ANN] Dr. Geo 12.10 for GNU-Linux/Windows/MACOSX
by Hilaire Fernandes Sept. 8, 2012

Sept. 8, 2012

Hello, After the Android version, here are the workstations release 12.10 of DrGeo. http://drgeo.eu Thanks Hilaire

1 0

[Pharo-project] RPackage, Monticello and the removal of PackageInfo
by Esteban Lorenzano Sept. 8, 2012

Sept. 8, 2012

Hi, As you know, we want to replace the old PackageInfo structure with RPackage. Last weeks Pharo 2.0 has been really unstable because of this effort, and it will be unstable yet a few days more, so I want to review the actions we are taking, so you know why this happnes and the result we want to obtain. So... first: Why replace PackageInfo and PackageOrganizer? The short answer is: because they suck :) The more or less long answer is: because their existence introduces a lot of penalties in the system, and forces to a lot of workarounds to manage what should be a simple system categories manager... take for instance the match MCPackage-PackageInfo-Class categories. Each MCPackage maps to a unique PackageInfo, but package info contains string pattern matched class categories. Tools uses this and well... performance is frankly disappointing in many case. Like this, there are lots of other reasons. So... RPackage will solve this by keeping a view of the system, not having to calculate it everytime. RPackage will keep also the list of classes, extension, etc. so tools can operate with them in a better/faster way. Question is: How to migrate in the less painful way? Attempt 1) Let each RPackage be one PackageInfo. We first thought this was the best path so, we spend some time moving in that direction. The advantage is that migration from Monticello and PackageInfo is trivial, but then the problems started to happen: PackageInfo (and current RPackage) contains N class categories so, there is an impedance mismatch between what we was seeing and what users/tools expect (they work with class categories, not with RPackage or PackageInfo). To solve that, we added class categories as RPackage tags (yep RPackage allows you to tag classes). But then we need to update in ver annoying ways the tools. And we also has now the fact that class categories are now a tag into an RPackage. Something really obscure and that was causing a lot of pain... So, we rolled back... Attempt 2) Let each Class Category be one RPackage. Ok, this is very simple (and that's the beauty on it)... each tools and conventions will match perfectly. Only problem here is that now, Monticello is not compatible anymore. So, we worked on the concept of RPackageSet, to replace PackageInfo use into Monticelo packages (we need them to load/save packages and stay compatible). RPackageSet is exactly what its name says: a set of RPackage instances (created on the fly, by pattern matching, so, is still some kind of a hack), that is polymorphic with PackageInfo in the monticello context. Thus, everything in the system can remain unchanged (or almost no change, the refactoring engine needs some adjusts). One extra bonus with this approach is that it let us think on more cool refactors in the future: we can for instance replace class categories (now a symbol) with an RPackage... and continue simplifying the system in several ways. ...and that's where we are now. We are working hard on stabilizing the system, but that will take still some days more... after that, we will be really close to the PackageInfo removal. PLEASE: PackageInfo users, take this into account: PackageInfo will pass away... and is one of the parts of the system that cannot be deprecated, they has to be completely removed, prepare your tools for the rise of RPackage :) Cheers, Esteban

5 17

[Pharo-project] Zinc WebSockets Demo Movie
by Sven Van Caekenberghe Sept. 7, 2012

Sept. 7, 2012

Hi, Today I implemented two simple demos to show what is possible using Zinc WebSockets. 1. a simple chatroom - each client opens a websocket to the chatroom service running on the server - the server keeps track of all connected client web sockets - when a message comes in from any client it is distributed to all clients - each client shows all incoming messages 2. a simple, continously updated status view - a client connects and listens for incoming messages containing a status report - the server streams status reports to each connected client each second - in the web browser you get to see the Smalltalk image's clock, memory and process stats I made a 5 minute (silent ;-) movie showing 3 different browsers talking to one Pharo Smalltalk 2.0 image running a Zn server. Faster, but lower quality: http://youtu.be/CANkfSUbZIk Pixel perfect quality, but 45Mb: https://dl.dropbox.com/u/16235440/Zinc-WebSockets-Demo-20120907.mov The code can be found in http://mc.stfx.eu/ZincHTTPComponents packages Zinc-WebSockets-Core and Zinc-WebSockets-Tests best update all of Zn. Only tested on 2.0, but it should work on 1.4. This is still a work-in-progress. There are code comments but high level documentation is still missing. I am looking for adventureous testers though. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

1 0

[Pharo-project] Rounding float question again
by Denis Kudriashov Sept. 7, 2012

Sept. 7, 2012

Hello. I know there are many similar questions. Maybe somebody give me fast answer. 146.015 roundTo: 0.01 => 146.01 I guess internal representation of 146.015 is something like 146.014999999999... That's why rounding result is 146.01 But how I can round arbitrary float my math root? How to fix my example to get 146.02? Best regards, Denis

3 5

[Pharo-project] Programmer Day @ Buenos Aires
by NicolÃ¡s Paez Sept. 7, 2012

Sept. 7, 2012

Hello everyone, As may know, next Tuesday is the Programmer Day<http://www.programmerday.info/>and a non-profit organisation in Buenos Aires in organizing a conference at the City Hall. I was invited to give a presentation in this conference about the any topic I considered relevant for the occasion and I decided to talk about Pharo. Other speakers will be talking about Node.js, Web APIs and Cloud Computing. If you are around Buenos Aires and want to attend, just register here<http://www.mug.org.ar/Eventos/3806.aspx>, is free. Saludos! NicoPaez <http://nicopaez.wordpress.com/>

2 1