[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
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@inria.fr Date: Sun, 27 Jun 2010 10:31:47 +0200 To: Pharo-project@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@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
+ 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@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@lists.gforge.inria.fr 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 <stephane.ducasse@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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 <stephane.ducasse@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <stephane.ducasse@inria.fr> 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 <stephane.ducasse@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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 <stephane.ducasse@inria.fr> 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 <stephane.ducasse@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] 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 Pharo-project@lists.gforge.inria.fr 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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Tue, Jun 29, 2010 at 12:23 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
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
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 :)
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: pharo-project-bounces@lists.gforge.inria.fr [mailto: pharo-project-bounces@lists.gforge.inria.fr] 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Eliot, It sounds as though you have the right idea. Here's hoping you are able to release it. Bill ________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Eliot Miranda Sent: Tuesday, June 29, 2010 4:01 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.2 vision On Tue, Jun 29, 2010 at 12:23 PM, Stéphane Ducasse <stephane.ducasse@inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: 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 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 :)
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: pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [mailto:pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] 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 Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Tuesday, June 29, 2010 2:23 PM To: Pharo-project@lists.gforge.inria.fr 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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <stephane.ducasse@inria.fr>:
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (7)
-
Benoit St-Jean -
Eliot Miranda -
Germán Arduino -
laurent laffont -
Pavel Krivanek -
Schwab,Wilhelm K -
Stéphane Ducasse