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