1.2 vision
Locked
 
|
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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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: [hidden email] > Date: Sun, 27 Jun 2010 10:31:47 +0200 > To: [hidden email] > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project Enter for a chance to get your town photo on Bing.ca! Submit a Photo Now! _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
+ 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 <[hidden email]> wrote: Hi all _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
**Yes** I really want to come up with a pragma and to annotate tests to populate the help.
On Jun 27, 2010, at 10:45 AM, laurent laffont wrote: > + 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 <[hidden email]> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
We should also clean the package naming structure
XXX XXX-Core XXX-Test-Core XXX-Foo XXX-Test-Foo Stef On Jun 29, 2010, at 3:42 PM, Stéphane Ducasse wrote: > **Yes** I really want to come up with a pragma and to annotate tests to populate the help. > > > On Jun 27, 2010, at 10:45 AM, laurent laffont wrote: > >> + 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 <[hidden email]> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
Stef,
It all sounds great. I probably care less about Alien than I do about what it is supposed to do well: callbacks. We need callbacks, and we need to be able to do callbacks that return double. That can come from Alien, Native Boost, or a plugin that makes FFI able to handle callbacks. Callbacks should not come at a cost of making every call harder to do, which **might** be the case with Alien. It would also be nice to have an analog to Dolphin's overlapped calls (calls made on a separate thread that block only the calling Smalltalk process, and not the entire image). SSL would also be nice. Overlapped calls would greatly simplify creating it, as then one could safely use OpenSSL's blocking calls on separate threads. The alternative is to do non-blocking calls, which is considerably more work than letting the OS handle the multi-tasking. Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse Sent: Sunday, June 27, 2010 3:32 AM To: Pharo Development 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On Jun 29, 2010, at 6:15 PM, Schwab,Wilhelm K wrote: > Stef, > > It all sounds great. I probably care less about Alien than I do about what it is supposed to do well: callbacks. We need callbacks, and we need to be able to do callbacks that return double. That can come from Alien, Native Boost, or a plugin that makes FFI able to handle callbacks. Callbacks should not come at a cost of making every call harder to do, which **might** be the case with Alien. the only way to make progress on this front is to propose some code. > It would also be nice to have an analog to Dolphin's overlapped calls (calls made on a separate thread that block only the calling Smalltalk process, and not the entire image). I think that eliot is working on threaded something for Cog > > SSL would also be nice. Overlapped calls would greatly simplify creating it, as then one could safely use OpenSSL's blocking calls on separate threads. The alternative is to do non-blocking calls, which is considerably more work than letting the OS handle the multi-tasking. > > Bill > > > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse > Sent: Sunday, June 27, 2010 3:32 AM > To: Pharo Development > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On Tue, Jun 29, 2010 at 12:23 PM, Stéphane Ducasse <[hidden email]> wrote:
We have a functional prototype that does overlapped calls. Its a multi-threaded VM based on David Simmons' ideas that allows only one thread to execute Smalltalk at any one time. Again I can't say anything either way as to when or whether this will be released. But we did finally release Cog , so at least there's a precedent :)
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
Hi:
Between the dev tools I think that a complete shrink and disable programmer facilities (as was talked in the thread of some time ago) will be useful to people using Pharo for business. Cheers. 2010/6/27 Stéphane Ducasse <[hidden email]>: > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
Stef,
There are places where I can help; writing a callback framework is probably not one of them. But my point is that if, as has been hinted in a few places, Alien gives us callbacks and makes the ordinary things hard, then we might not have not bought much in the process. Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Stéphane Ducasse Sent: Tuesday, June 29, 2010 2:23 PM To: [hidden email] Subject: Re: [Pharo-project] 1.2 vision On Jun 29, 2010, at 6:15 PM, Schwab,Wilhelm K wrote: > Stef, > > It all sounds great. I probably care less about Alien than I do about what it is supposed to do well: callbacks. We need callbacks, and we need to be able to do callbacks that return double. That can come from Alien, Native Boost, or a plugin that makes FFI able to handle callbacks. Callbacks should not come at a cost of making every call harder to do, which **might** be the case with Alien. the only way to make progress on this front is to propose some code. > It would also be nice to have an analog to Dolphin's overlapped calls (calls made on a separate thread that block only the calling Smalltalk process, and not the entire image). I think that eliot is working on threaded something for Cog > > SSL would also be nice. Overlapped calls would greatly simplify creating it, as then one could safely use OpenSSL's blocking calls on separate threads. The alternative is to do non-blocking calls, which is considerably more work than letting the OS handle the multi-tasking. > > Bill > > > > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On Behalf Of > Stéphane Ducasse > Sent: Sunday, June 27, 2010 3:32 AM > To: Pharo Development > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Eliot Miranda-2
Eliot,
It sounds as
though you have the right idea. Here's hoping you are able to release
it.
Bill
From: [hidden email] [mailto:[hidden email]] On Behalf Of Eliot Miranda Sent: Tuesday, June 29, 2010 4:01 PM To: [hidden email] Subject: Re: [Pharo-project] 1.2 vision On Tue, Jun 29, 2010 at 12:23 PM, Stéphane Ducasse <[hidden email]>
wrote:
We have a functional prototype that does overlapped calls. Its a
multi-threaded VM based on David Simmons' ideas that allows only one thread to
execute Smalltalk at any one time. Again I can't say anything either way
as to when or whether this will be released. But we did finally release
Cog , so at least there's a precedent :)
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Eliot Miranda-2
>
> > We have a functional prototype that does overlapped calls. Its a multi-threaded VM based on David Simmons' ideas that allows only one thread to execute Smalltalk at any one time. Again I can't say anything either way as to when or whether this will be released. But we did finally release Cog , so at least there's a precedent :) I like precedent like that one :) Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
Hi,
I added to the issue http://code.google.com/p/pharo/issues/detail?id=2105 the remodularization code, please look at it, it must split packages Announcements, Graphics and Multilingual. In the mentioned example the package named XXX cannot exist because it covers other packages. It would be absolutely amazing to have it integrated soon, than we could continue on the methods level. Cheers, -- Pavel On Tue, Jun 29, 2010 at 4:27 PM, Stéphane Ducasse <[hidden email]> wrote: > We should also clean the package naming structure > > XXX > XXX-Core > XXX-Test-Core > XXX-Foo > XXX-Test-Foo > > Stef > > On Jun 29, 2010, at 3:42 PM, Stéphane Ducasse wrote: > >> **Yes** I really want to come up with a pragma and to annotate tests to populate the help. >> >> >> On Jun 27, 2010, at 10:45 AM, laurent laffont wrote: >> >>> + 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 <[hidden email]> 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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
I will !
Stef On Jun 30, 2010, at 4:15 PM, Pavel Krivanek wrote: > Hi, > > I added to the issue > http://code.google.com/p/pharo/issues/detail?id=2105 the > remodularization code, please look at it, it must split packages > Announcements, Graphics and Multilingual. In the mentioned example the > package named XXX cannot exist because it covers other packages. > > It would be absolutely amazing to have it integrated soon, than we > could continue on the methods level. > > Cheers, > -- Pavel > > On Tue, Jun 29, 2010 at 4:27 PM, Stéphane Ducasse > <[hidden email]> wrote: >> We should also clean the package naming structure >> >> XXX >> XXX-Core >> XXX-Test-Core >> XXX-Foo >> XXX-Test-Foo >> >> Stef >> >> On Jun 29, 2010, at 3:42 PM, Stéphane Ducasse wrote: >> >>> **Yes** I really want to come up with a pragma and to annotate tests to populate the help. >>> >>> >>> On Jun 27, 2010, at 10:45 AM, laurent laffont wrote: >>> >>>> + 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 <[hidden email]> 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 >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |