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

Re: [Pharo-project] Questions about ToolSet

by Mariano Martinez Peck

On Wed, Feb 3, 2010 at 9:29 AM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi, > > I think that introducing more global state is not a good idea. > > I believe a cleaner solution would be to create have ToolSet default > return an instance of a ToolSetImplementation, and then create a > instance variables in the ToolSetImplementation for these tools and > let me customize it from outside and accessors :) > . Like this you do not create > unnecessary global state. > > Thanks Doru!!! I like much more my suggestion. Actually it was just what I come to mind at that time. The real purpose was to see if other people agree there is a problem in ToolSet. Thanks! I created the issue http://code.google.com/p/pharo/issues/detail?id=1915 Now, when someone have time, can hack there :) > Cheers, > Doru > > > On 3 Feb 2010, at 09:11, George Herolyants wrote: > > > Hi, Mariano > > > > I also confronted this problem when I was writing some extension of > > NewInspector. And I agree, the current process of registering of new > > tools is ugly. I solved the problem with writing some code, which > > created an anonymous class which merged behaviour of all the tool sets > > passed to it as arguments and installed this class as default tool > > set. Tricky way, but it worked, IIRC :). > > > > But I think there should be cleaner way. Maybe something similar to > > what you propose, but without introducing new names in the global > > namespace. Maybe we can do define all those tool classes as class > > variables and define a protocol in ToolSet or StandardToolSet to > > install (and maybe even use new settings framework to do it)? > > > > What do you think? > > > > George > > > > 2010/2/3 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> Hi folks. I found I big problem with the way ToolSet works or at > >> least with > >> the way I think it works. Right now, there is the class ToolSet with > >> certain methods like API and then a class side method to register a > >> XXX > >> ToolSet as default. So, we have for example, the StandardToolSet > >> which > >> implements/overrides some of the methods of ToolSet. Of course, > >> that ToolSet > >> (StandardToolSet) is the default. Evaluate ToolSet default and you > >> will get > >> that one. Becuase that is done is StandardToolSet class >> initialize > >> > >> Now...the first question, why StandardToolSet doesn't extend from > >> ToolSet > >> ? shouldn't that be better ? > >> > >> Anyway, this is the big problem. The only way right now to change the > >> toolset is to create a new class and register it. Suppose I want to > >> install > >> NewInspector and put in the ToolSet that now, the inspector to use is > >> NewInspector instead of old Inspector. The only way I see right now > >> is to > >> create new class and implement the method inspectorClassOf: As > >> you can > >> see, NewInspector had to do that in class NewInspectorToolSet. They > >> had to > >> create that class just to implement that method and register it... > >> > >> Now, suppose I want to install shout, and I want to say that the > >> default > >> workspace is SHWorkspace (shout one), not the normal one. > >> Ok...easy, I do > >> the same of the NewInspector (but changing the method openWorkspace > >> instead > >> of inspectorClassOf:) ....but...I cannot register 2 toolsets. So, I > >> have or > >> NewInspectorToolSet or ShoutToolSet. Of course, this has no sense > >> AT ALL. > >> > >> So, my proposal is to change ToolSet, so that any tool can change > >> certain > >> things, without needing to do that. Examples: > >> > >> For example, in StandardToolSet, we have: > >> > >> StandardToolSet >> openWorkspace > >> Workspace open > >> > >> I would change that for something like: > >> > >> > >> StandardToolSet >> openWorkspace > >> (Smalltalk at: #WorkspaceClassName) open > >> > >> Of course Smalltalk at: #WorkspaceClassName must be initialized > >> the first > >> time with something like Smalltalk at: #WorkspaceClassName put: > >> Workspace > >> > >> I don't like the name WorkspaceClassName, we should look for better > >> names. > >> > >> Then, I can just have a post do it when loading Shout that evaluates: > >> > >> (Smalltalk at: #WorkspaceClassName put: SHWorkspace) > >> > >> Here there is no need to create subclasses neither to register a new > >> toolset. > >> > >> Ok...this is an example, but the idea is to apply this to most cases. > >> > >> What do you think ? > >> > >> Mariano > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "It's not what we do that matters most, it's how we do it." > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 3, 2010

Re: [Pharo-project] What about a "real" research group (was: Do you want to discuss about papers?)

by CÃ©drick BÃ©ler

> CÃ©drick: I like the idea, however, I think your idea may be a > "consequence" of my idea. side note: This is not really my idea but an idea ;) ideas are in the air :)) > You can do all steps at the same time, but I rather go step by step. We > first create the list, we create a group, we join people, we discuss, we > learn, and after that, eventually it will naturally arrive a moment where we > want to have our own real group. > yes I agree. I just wanted to point out a simple wiki at first could be cool too. Just to see a brief presentation of people... > > So...I will create the list right now :) > yes that's cool :) Let see how it goes... > > Mariano > > 2010/2/3 CÃ©drick BÃ©ler <cdrick65(a)gmail.com> > >> I'm ok for such a list... >> >> Nevertheless, I'm wondering if we could go a bit further by doing a kind >> of research group with a proper web site listing all people involved and the >> projects there're working on. We could then establish some categories and >> eventually sub-groups. List all published papers, gives ressources to >> people... >> >> We could also have a workshop every year (in ESUG or eventually >> independantly). More importantly than discussions on papers, I think we need >> to characterise people and their "expertise" area... >> >> For instance, I'm interested in some areas that are not really focussed in >> Computer Science problematics (new compiler, traits, etc...). >> >> To me Smalltalk is the vehicle (a fun one) to experiment my research >> stuffs. Here are some areas I'm working on: >> -Case Based Reasoning - essentially similarity measure with uncertainty >> -Constraint Satisfaction Programming (more interested in open models) and >> especially the coupling between CBR and CSP >> -NARS, a kind of General AI (logical stuff) >> -Dynamic open models in general -> Coevolution of model and their >> instances (something I'd really like to dig into) >> -Modeling Imperfect Information, ie. incomplete, uncertain, umprecise (-> >> so as to model expert information) - I would like to apply that to poker >> game in the future :) - This is maybe the central aspect of my work >> >> Here is a quick list of what I do or plan to do... Having a central web >> site would be excellent for visibility (of course a mailing can be setup >> too), both for Smalltalk and for people doing research with it. >> >> What others think ? >> Would you be ok for a central wiki where each person describe in one page >> what their research is, what their future projects are, what they need >> are... We could gather all confs calls that are potentially interesting... >> Of course this need some setup and reflexion to structure the group/website >> but I think it worth it... And count me in if people like the idea. >> >> CÃ©drick >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- CÃ©drick

Feb. 3, 2010

Re: [Pharo-project] What about a "real" research group (was: Do you want to discuss about papers?)

by CÃ©drick BÃ©ler

> > > > > > Here is a quick list of what I do or plan to do... Having a central web > site would be excellent for visibility (of course a mailing can be setup > too), both for Smalltalk and for people doing research with it. > > for the moment having it low profile is also a good way. > What do you mean by low-profile... only a mailing-list ? or a small site with minimum information and link to personnal web sites ? > > > What others think ? > > Would you be ok for a central wiki where each person describe in one page > what their research is, what their future projects are, what they need > are... We could gather all confs calls that are potentially interesting... > Of course this need some setup and reflexion to structure the group/website > but I think it worth it... And count me in if people like the idea. > > Yes something like lambda the ultimate > :) I would nevertheless choose a name with smalltalk and research or academic keywords for visibility purpose :) > > > > > CÃ©drick > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- CÃ©drick

Feb. 3, 2010

Re: [Pharo-project] What about a "real" research group (was: Do you want to discuss about papers?)

by Mariano Martinez Peck

CÃ©drick: I like the idea, however, I think your idea may be a "consequence" of my idea. You can do all steps at the same time, but I rather go step by step. We first create the list, we create a group, we join people, we discuss, we learn, and after that, eventually it will naturally arrive a moment where we want to have our own real group. So...I will create the list right now :) Mariano 2010/2/3 CÃ©drick BÃ©ler <cdrick65(a)gmail.com> > I'm ok for such a list... > > Nevertheless, I'm wondering if we could go a bit further by doing a kind of > research group with a proper web site listing all people involved and the > projects there're working on. We could then establish some categories and > eventually sub-groups. List all published papers, gives ressources to > people... > > We could also have a workshop every year (in ESUG or eventually > independantly). More importantly than discussions on papers, I think we need > to characterise people and their "expertise" area... > > For instance, I'm interested in some areas that are not really focussed in > Computer Science problematics (new compiler, traits, etc...). > > To me Smalltalk is the vehicle (a fun one) to experiment my research > stuffs. Here are some areas I'm working on: > -Case Based Reasoning - essentially similarity measure with uncertainty > -Constraint Satisfaction Programming (more interested in open models) and > especially the coupling between CBR and CSP > -NARS, a kind of General AI (logical stuff) > -Dynamic open models in general -> Coevolution of model and their > instances (something I'd really like to dig into) > -Modeling Imperfect Information, ie. incomplete, uncertain, umprecise (-> > so as to model expert information) - I would like to apply that to poker > game in the future :) - This is maybe the central aspect of my work > > Here is a quick list of what I do or plan to do... Having a central web > site would be excellent for visibility (of course a mailing can be setup > too), both for Smalltalk and for people doing research with it. > > What others think ? > Would you be ok for a central wiki where each person describe in one page > what their research is, what their future projects are, what they need > are... We could gather all confs calls that are potentially interesting... > Of course this need some setup and reflexion to structure the group/website > but I think it worth it... And count me in if people like the idea. > > CÃ©drick > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 3, 2010

Re: [Pharo-project] What about a "real" research group (was: Do you want to discuss about papers?)

by StÃ©phane Ducasse

On Feb 3, 2010, at 1:18 PM, CÃ©drick BÃ©ler wrote: > I'm ok for such a list... > > Nevertheless, I'm wondering if we could go a bit further by doing a kind of research group with a proper web site listing all people involved and the projects there're working on. We could then establish some categories and eventually sub-groups. List all published papers, gives ressources to people... > > We could also have a workshop every year (in ESUG or eventually independantly). More importantly than discussions on papers, I think we need to characterise people and their "expertise" area... > > For instance, I'm interested in some areas that are not really focussed in Computer Science problematics (new compiler, traits, etc...). > > To me Smalltalk is the vehicle (a fun one) to experiment my research stuffs. Here are some areas I'm working on: > -Case Based Reasoning - essentially similarity measure with uncertainty > -Constraint Satisfaction Programming (more interested in open models) and especially the coupling between CBR and CSP > -NARS, a kind of General AI (logical stuff) > -Dynamic open models in general -> Coevolution of model and their instances (something I'd really like to dig into) > -Modeling Imperfect Information, ie. incomplete, uncertain, umprecise (-> so as to model expert information) - I would like to apply that to poker game in the future :) - This is maybe the central aspect of my work I would really like to see how we can map that to do software analysis > > Here is a quick list of what I do or plan to do... Having a central web site would be excellent for visibility (of course a mailing can be setup too), both for Smalltalk and for people doing research with it. for the moment having it low profile is also a good way. > What others think ? > Would you be ok for a central wiki where each person describe in one page what their research is, what their future projects are, what they need are... We could gather all confs calls that are potentially interesting... Of course this need some setup and reflexion to structure the group/website but I think it worth it... And count me in if people like the idea. Yes something like lambda the ultimate > > CÃ©drick > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 3, 2010

Re: [Pharo-project] Fwd: Communicating Event Loops

by StÃ©phane Ducasse

Igor You know Concurrent Smalltalk was certainly like that too. Now my point is that this is good to share ideas that there are old or not. Already discussed or not. For example I would like to see the cost of it at the level of the GC. Stef >> Begin forwarded message: >> >>> From: Tom Van Cutsem <tvcutsem(a)vub.ac.be> >>> Date: February 3, 2010 5:13:00 AM GMT+01:00 >>> To: SOFT members <soft(a)soft.vub.ac.be> >>> Cc: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>> Subject: Communicating Event Loops >>> >>> Hi, >>> >>> For those interested in concurrency control: last week I gave a presentation about AmbientTalk's concurrency model at a meeting for Javascript industry developers. The presentation was recorded, and if you're interested you can see it here: >>> http://ssjs.pbworks.com/Communicating-Event-Loops >>> >>> (towards the end there is an interesting discussion about the pros and cons of Erlang-style vs AmbientTalk-style concurrency) >>> >>> Cheers, >>> Tom >> >> >> _______________________________________________ >> 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

Feb. 3, 2010

[Pharo-project] What about a "real" research group (was: Do you want to discuss about papers?)

by CÃ©drick BÃ©ler

I'm ok for such a list... Nevertheless, I'm wondering if we could go a bit further by doing a kind of research group with a proper web site listing all people involved and the projects there're working on. We could then establish some categories and eventually sub-groups. List all published papers, gives ressources to people... We could also have a workshop every year (in ESUG or eventually independantly). More importantly than discussions on papers, I think we need to characterise people and their "expertise" area... For instance, I'm interested in some areas that are not really focussed in Computer Science problematics (new compiler, traits, etc...). To me Smalltalk is the vehicle (a fun one) to experiment my research stuffs. Here are some areas I'm working on: -Case Based Reasoning - essentially similarity measure with uncertainty -Constraint Satisfaction Programming (more interested in open models) and especially the coupling between CBR and CSP -NARS, a kind of General AI (logical stuff) -Dynamic open models in general -> Coevolution of model and their instances (something I'd really like to dig into) -Modeling Imperfect Information, ie. incomplete, uncertain, umprecise (-> so as to model expert information) - I would like to apply that to poker game in the future :) - This is maybe the central aspect of my work Here is a quick list of what I do or plan to do... Having a central web site would be excellent for visibility (of course a mailing can be setup too), both for Smalltalk and for people doing research with it. What others think ? Would you be ok for a central wiki where each person describe in one page what their research is, what their future projects are, what they need are... We could gather all confs calls that are potentially interesting... Of course this need some setup and reflexion to structure the group/website but I think it worth it... And count me in if people like the idea. CÃ©drick

Feb. 3, 2010

Re: [Pharo-project] Fwd: Communicating Event Loops

by Marcus Denker

On Feb 3, 2010, at 12:34 PM, Igor Stasenko wrote: > On 3 February 2010 10:33, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> I think that this would be the first mail to smalltalk-research >> > Err, what you mean? > > All i could say, that this scheme already discussed on squeak-dev > couple of years ago... This is exactly the way where i think we should > eventually go to. So what is new about it? Do we request that only new things are discussed on Smalltalk-research? LOOM is very old, too... in general, there is a lot of wisdom espececially in old papers. Partly because it was possible to publish easily cool ideas without having to have every open question already answered. ... the good old days :-) The problem is that if new people start, they have to read old papers. Else how can they learn? There are even things that experienced people don't know. For example, because they did not do research in this direction in the past. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 3, 2010

Re: [Pharo-project] Fwd: Communicating Event Loops

by Igor Stasenko

On 3 February 2010 10:33, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I think that this would be the first mail to smalltalk-research > Err, what you mean? All i could say, that this scheme already discussed on squeak-dev couple of years ago... This is exactly the way where i think we should eventually go to. So what is new about it? > Begin forwarded message: > >> From: Tom Van Cutsem <tvcutsem(a)vub.ac.be> >> Date: February 3, 2010 5:13:00 AM GMT+01:00 >> To: SOFT members <soft(a)soft.vub.ac.be> >> Cc: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> Subject: Communicating Event Loops >> >> Hi, >> >> For those interested in concurrency control: last week I gave a presentation about AmbientTalk's concurrency model at a meeting for Javascript industry developers. The presentation was recorded, and if you're interested you can see it here: >> http://ssjs.pbworks.com/Communicating-Event-Loops >> >> (towards the end there is an interesting discussion about the pros and cons of Erlang-style vs AmbientTalk-style concurrency) >> >> Cheers, >> Tom > > > _______________________________________________ > 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.

Feb. 3, 2010

Re: [Pharo-project] akuhn/SUnit: run faster tests first & step through tests

by StÃ©phane Ducasse

this loads well in the latest 1,1 core :) so now we should really have a look and these cool changes Stef On Jan 6, 2010, at 2:38 PM, Adrian Kuhn wrote: > SystemChangeNotifier uniqueInstance > noMoreNotificationsFor: TestCase. > Gofer it > disablePackageCache; > squeaksource: 'akuhn'; > package: 'SUnit'; > package: 'SUnitGUI'; > load.

Feb. 3, 2010