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

Re: [Pharo-project] 1.2 vision

by laurent laffont

+ More HelpSystem. + MetacelloRepository GUI, newbies struggle to find a package, must be easy. Laurent On Sun, Jun 27, 2010 at 10:31 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Hi all > > Of course we will integrate changes and changes and improvements.... now I > believe that it would be nice to build a common > vision. Here what I would like to get in 1.2. > > Now it does not mean that this is a definitive list and that we will have > the energy to do all but like > that you know that you can put energy do build this common vision :) > > - better infrastructure for integrating rb composite queries into > the system > The idea is to introduce a superclass on top of > systemDictionary and to define there an API that > is compatible with the one of RB (and potentially modified > the one of RB) > > - another step towards using announcement for system notification > > - better tools for dev > > - have a look at the RB change model so that we could get a real > undo and changes > > - clean Monticello so that package logic stays in package so that we > can plug RPackage into the system. > Right now this looks too brittle to do anything > > - make sure that we can have RPackage on the side of PakageInfo (we > got really nice benchmark) > > - New Compiler in beta > > - Helvetia hooks > > - ROME API > > - Sophie Event Hierarchy > > - Define some architectural action to get the system more modular > > - Hudson infrastructure > > - metacello to manage core > > - metacelloRepository for 1.0/1.1/1.2 > Gofer > > - squeak collection optimisation? > > - Alien > > Open points: > > - What do we do with ToolBuilder? Not clear to me. > > - What should be done at the level of polymorph? > - What should be done a the level of Pluggable**** > can we use the fact that we have now block closure > to get it better. > > As you guess it will not come simply but this is important that we all head > towards a common understanding > > > Stef > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 27, 2010

Re: [Pharo-project] SystemNavigation#allSendersOf: vs SystemNavigation#allReferencesTo:

by laurent laffont

In PharoInbox: SLICE-Issue-2593-SystemNavigationAddSelectorsReferingTo-LaurentLaffont.1 Apply Benoit St-Jean patch + add non-regression test Laurent Laffont On Sun, Jun 27, 2010 at 10:01 AM, Benoit St-Jean <bstjean(a)hotmail.ca> wrote: > Fix attached. > > Hope this helps! > > > > ----------------- > Benoit St-Jean > A standpoint is an intellectual horizon of radius zero. > (Albert Einstein) > > > > > ------------------------------ > From: laurent.laffont(a)gmail.com > Date: Sun, 27 Jun 2010 08:33:52 +0200 > To: pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] SystemNavigation#allSendersOf: vs > SystemNavigation#allReferencesTo: > > Hi, > > in Autotest I search for all senders of a method. The first version > used SystemNavigation#allSendersOf: which sometimes returns wrong results (I > think). For example: > > senders := (SystemNavigation default allSendersOf: #methodsFor:). > senders size. "answers 18" > senders collect: [:aReference| aReference compiledMethod]. > > debuggers open as ChangeSet#scanCategory doesn't exist (it's on the class > side but allSendersOf: returns #scanCategory reference on class side and > instance side). > > With #allReferencesTo: > > senders := (SystemNavigation default allReferencesTo: #methodsFor:). > senders size. "answers 16" > > Is this a bug in #allSendersOf: or I don't understand ? > > Cheers, > > Laurent Laffont > > http://pharocasts.blogspot.com/ > http://magaloma.blogspot.com/ > > ------------------------------ > Enter for a chance to get your town photo on Bing.ca! Submit a Photo Now! > <http://go.microsoft.com/?linkid=9734383> >

June 27, 2010

Re: [Pharo-project] 1.2 vision

by Benoit St-Jean

Suggestions: 1) Something like VW MemoryPolicy would probably be beneficial in the long-term instead of polluting SmalltalkImage with a zillion #initializeMemorySettingsProfileForWhatever to customize the Pharo GC parameters for Seaside, QF or whatever else. 2) SystemNavigation needs a cleanup/revisit. 3) Utilities needs a cleanup/revisit. 4) The "more..." menu in the file browser is a mess, a real big mess! Needs cleanup/revisit. My 2 cents. ----------------- Benoit St-Jean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) > From: stephane.ducasse(a)inria.fr > Date: Sun, 27 Jun 2010 10:31:47 +0200 > To: Pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] 1.2 vision > > Hi all > > Of course we will integrate changes and changes and improvements.... now I believe that it would be nice to build a common > vision. Here what I would like to get in 1.2. > > Now it does not mean that this is a definitive list and that we will have the energy to do all but like > that you know that you can put energy do build this common vision :) > > - better infrastructure for integrating rb composite queries into the system > The idea is to introduce a superclass on top of systemDictionary and to define there an API that > is compatible with the one of RB (and potentially modified the one of RB) > > - another step towards using announcement for system notification > > - better tools for dev > > - have a look at the RB change model so that we could get a real undo and changes > > - clean Monticello so that package logic stays in package so that we can plug RPackage into the system. > Right now this looks too brittle to do anything > > - make sure that we can have RPackage on the side of PakageInfo (we got really nice benchmark) > > - New Compiler in beta > > - Helvetia hooks > > - ROME API > > - Sophie Event Hierarchy > > - Define some architectural action to get the system more modular > > - Hudson infrastructure > > - metacello to manage core > > - metacelloRepository for 1.0/1.1/1.2 > Gofer > > - squeak collection optimisation? > > - Alien > > Open points: > > - What do we do with ToolBuilder? Not clear to me. > > - What should be done at the level of polymorph? > - What should be done a the level of Pluggable**** > can we use the fact that we have now block closure to get it better. > > As you guess it will not come simply but this is important that we all head towards a common understanding > > > Stef > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _________________________________________________________________ Learn more ways to connect with your buddies now http://go.microsoft.com/?linkid=9734388

June 27, 2010

Re: [Pharo-project] [Vm-dev] Re: [squeak-dev] OSCog updated

by Andrey Larionov

Maybe this is network related issue? On Sun, Jun 27, 2010 at 09:48, Lukas Renggli <renggli(a)gmail.com> wrote: > Sometimes it survives 30 requests, sometimes it crashes > right after the first request. In the console I get: > > Â nanosleep: Invalid argument > Â Exited with exit code: 1 > > How can I further debug this? I cannot reproduce it with the tests. It > only happens (randomly) when using Seaside through the webbrowser.

June 27, 2010

[Pharo-project] 1.2 vision

by StÃ©phane Ducasse

Hi all Of course we will integrate changes and changes and improvements.... now I believe that it would be nice to build a common vision. Here what I would like to get in 1.2. Now it does not mean that this is a definitive list and that we will have the energy to do all but like that you know that you can put energy do build this common vision :) - better infrastructure for integrating rb composite queries into the system The idea is to introduce a superclass on top of systemDictionary and to define there an API that is compatible with the one of RB (and potentially modified the one of RB) - another step towards using announcement for system notification - better tools for dev - have a look at the RB change model so that we could get a real undo and changes - clean Monticello so that package logic stays in package so that we can plug RPackage into the system. Right now this looks too brittle to do anything - make sure that we can have RPackage on the side of PakageInfo (we got really nice benchmark) - New Compiler in beta - Helvetia hooks - ROME API - Sophie Event Hierarchy - Define some architectural action to get the system more modular - Hudson infrastructure - metacello to manage core - metacelloRepository for 1.0/1.1/1.2 Gofer - squeak collection optimisation? - Alien Open points: - What do we do with ToolBuilder? Not clear to me. - What should be done at the level of polymorph? - What should be done a the level of Pluggable**** can we use the fact that we have now block closure to get it better. As you guess it will not come simply but this is important that we all head towards a common understanding Stef

June 27, 2010

Re: [Pharo-project] SystemNavigation#allSendersOf: vs SystemNavigation#allReferencesTo:

by StÃ©phane Ducasse

Thanks. SystemNavigation is the result of a merge between behavior defined in browser and systemdictionary so having a nice pass over it would be great. http://code.google.com/p/pharo/issues/detail?id=2592 Stef On Jun 27, 2010, at 10:01 AM, Benoit St-Jean wrote: > Fix attached. > > Hope this helps! Sure it does Benoit did you sign the license agreement? Stef > > > ----------------- > Benoit St-Jean > A standpoint is an intellectual horizon of radius zero. > (Albert Einstein) > > > > > From: laurent.laffont(a)gmail.com > Date: Sun, 27 Jun 2010 08:33:52 +0200 > To: pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] SystemNavigation#allSendersOf: vs SystemNavigation#allReferencesTo: > > Hi, > > in Autotest I search for all senders of a method. The first version used SystemNavigation#allSendersOf: which sometimes returns wrong results (I think). For example: > > senders := (SystemNavigation default allSendersOf: #methodsFor:). > senders size. "answers 18" > senders collect: [:aReference| aReference compiledMethod]. > > debuggers open as ChangeSet#scanCategory doesn't exist (it's on the class side but allSendersOf: returns #scanCategory reference on class side and instance side). > > With #allReferencesTo: > > senders := (SystemNavigation default allReferencesTo: #methodsFor:). > senders size. "answers 16" > > Is this a bug in #allSendersOf: or I don't understand ? > > Cheers, > > Laurent Laffont > > http://pharocasts.blogspot.com/ > http://magaloma.blogspot.com/ > > Enter for a chance to get your town photo on Bing.ca! Submit a Photo Now! <SystemNavigation-addSelectorsReferingTointospecialbyte.st>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 27, 2010

Re: [Pharo-project] SystemNavigation#allSendersOf: vs SystemNavigation#allReferencesTo:

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=2592 :) On Jun 27, 2010, at 10:16 AM, laurent laffont wrote: > On Sun, Jun 27, 2010 at 10:01 AM, Benoit St-Jean <bstjean(a)hotmail.ca> wrote: > Fix attached. > > Hope this helps! > > > Thank you. http://code.google.com/p/pharo/issues/detail?id=2593 > > Laurent > > > ----------------- > Benoit St-Jean > A standpoint is an intellectual horizon of radius zero. > (Albert Einstein) > > > > > From: laurent.laffont(a)gmail.com > Date: Sun, 27 Jun 2010 08:33:52 +0200 > To: pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] SystemNavigation#allSendersOf: vs SystemNavigation#allReferencesTo: > > Hi, > > in Autotest I search for all senders of a method. The first version used SystemNavigation#allSendersOf: which sometimes returns wrong results (I think). For example: > > senders := (SystemNavigation default allSendersOf: #methodsFor:). > senders size. "answers 18" > senders collect: [:aReference| aReference compiledMethod]. > > debuggers open as ChangeSet#scanCategory doesn't exist (it's on the class side but allSendersOf: returns #scanCategory reference on class side and instance side). > > With #allReferencesTo: > > senders := (SystemNavigation default allReferencesTo: #methodsFor:). > senders size. "answers 16" > > Is this a bug in #allSendersOf: or I don't understand ? > > Cheers, > > Laurent Laffont > > http://pharocasts.blogspot.com/ > http://magaloma.blogspot.com/ > > Enter for a chance to get your town photo on Bing.ca! Submit a Photo Now! > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 27, 2010

Re: [Pharo-project] SystemNavigation#allSendersOf: vs SystemNavigation#allReferencesTo:

by laurent laffont

On Sun, Jun 27, 2010 at 10:01 AM, Benoit St-Jean <bstjean(a)hotmail.ca> wrote: > Fix attached. > > Hope this helps! > Thank you. http://code.google.com/p/pharo/issues/detail?id=2593 <http://code.google.com/p/pharo/issues/detail?id=2593>Laurent ----------------- > Benoit St-Jean > A standpoint is an intellectual horizon of radius zero. > (Albert Einstein) > > > > > ------------------------------ > From: laurent.laffont(a)gmail.com > Date: Sun, 27 Jun 2010 08:33:52 +0200 > To: pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] SystemNavigation#allSendersOf: vs > SystemNavigation#allReferencesTo: > > Hi, > > in Autotest I search for all senders of a method. The first version > used SystemNavigation#allSendersOf: which sometimes returns wrong results (I > think). For example: > > senders := (SystemNavigation default allSendersOf: #methodsFor:). > senders size. "answers 18" > senders collect: [:aReference| aReference compiledMethod]. > > debuggers open as ChangeSet#scanCategory doesn't exist (it's on the class > side but allSendersOf: returns #scanCategory reference on class side and > instance side). > > With #allReferencesTo: > > senders := (SystemNavigation default allReferencesTo: #methodsFor:). > senders size. "answers 16" > > Is this a bug in #allSendersOf: or I don't understand ? > > Cheers, > > Laurent Laffont > > http://pharocasts.blogspot.com/ > http://magaloma.blogspot.com/ > > ------------------------------ > Enter for a chance to get your town photo on Bing.ca! Submit a Photo Now! > <http://go.microsoft.com/?linkid=9734383> >

June 27, 2010

Re: [Pharo-project] SystemNavigation#allSendersOf: vs SystemNavigation#allReferencesTo:

by Benoit St-Jean

Fix attached. Hope this helps! ----------------- Benoit St-Jean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) From: laurent.laffont(a)gmail.com Date: Sun, 27 Jun 2010 08:33:52 +0200 To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] SystemNavigation#allSendersOf: vs SystemNavigation#allReferencesTo: Hi, in Autotest I search for all senders of a method. The first version used SystemNavigation#allSendersOf: which sometimes returns wrong results (I think). For example: senders := (SystemNavigation default allSendersOf: #methodsFor:). senders size. "answers 18"senders collect: [:aReference| aReference compiledMethod]. debuggers open as ChangeSet#scanCategory doesn't exist (it's on the class side but allSendersOf: returns #scanCategory reference on class side and instance side). With #allReferencesTo: senders := (SystemNavigation default allReferencesTo: #methodsFor:).senders size. "answers 16" Is this a bug in #allSendersOf: or I don't understand ? Cheers,Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/ _________________________________________________________________ Learn more ways to connect with your buddies now http://go.microsoft.com/?linkid=9734388

June 27, 2010

Re: [Pharo-project] SystemNavigation#allSendersOf: vs SystemNavigation#allReferencesTo:

by Benoit St-Jean

Look like the suspect is in SystemNavigation and is here (change "class" to "behavior" when creating the Method reference): addSelectorsReferingTo: aSymbol in: class to: sortedSenders special: special byte: byte {class. class class} do: [:behavior| (behavior thoroughWhichSelectorsReferTo: aSymbol special: special byte: byte) do: [ :sel | sortedSenders add: (MethodReference class: behavior selector: sel) ]] ----------------- Benoit St-Jean A standpoint is an intellectual horizon of radius zero. (Albert Einstein) From: laurent.laffont(a)gmail.com Date: Sun, 27 Jun 2010 08:33:52 +0200 To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] SystemNavigation#allSendersOf: vs SystemNavigation#allReferencesTo: Hi, in Autotest I search for all senders of a method. The first version used SystemNavigation#allSendersOf: which sometimes returns wrong results (I think). For example: senders := (SystemNavigation default allSendersOf: #methodsFor:). senders size. "answers 18"senders collect: [:aReference| aReference compiledMethod]. debuggers open as ChangeSet#scanCategory doesn't exist (it's on the class side but allSendersOf: returns #scanCategory reference on class side and instance side). With #allReferencesTo: senders := (SystemNavigation default allReferencesTo: #methodsFor:).senders size. "answers 16" Is this a bug in #allSendersOf: or I don't understand ? Cheers,Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/ _________________________________________________________________ MSN Dating: Find someone special. Start now. http://go.microsoft.com/?linkid=9734384

June 27, 2010