roadmap for 1.4
Locked
12
12
 
|
Hi guys
here is a kind of dump of roadmap for 1.4 first level is to make sure that we have only one single image. - load FileSystem -> so that we can start to integrate and improve the fileSystem API - Load shout, Ocompletion, RBEngine (not OB) so that we can change what should be changed for RPackage to work - Ring -> so that we can start to integrate it - Fuel -> so that we can deprecate SmartRefStream (there may be a problem with mcz (not sure)). - I want Opal in 1.4 too. - continue to remove StringHolder hierarchy - Morphic improvements Comments are welcomed. Stef |
|
|
On Sat, Jun 18, 2011 at 2:59 PM, Stéphane Ducasse <[hidden email]> wrote: Hi guys Yes for Morphic ! + a FFI that a stupid idiot like me can use + keymapping Laurent
|
|
|
In reply to this post by Stéphane Ducasse
Looks good!
Alexandre On 18 Jun 2011, at 08:59, Stéphane Ducasse wrote: > Hi guys > > here is a kind of dump of roadmap for 1.4 first level is to make sure that we have only one single image. > > - load FileSystem > -> so that we can start to integrate and improve the fileSystem API > > - Load shout, Ocompletion, RBEngine (not OB) so that we can change what should be changed for RPackage to work > > - Ring > -> so that we can start to integrate it > > - Fuel > -> so that we can deprecate SmartRefStream (there may be a problem with mcz (not sure)). > > - I want Opal in 1.4 too. > > - continue to remove StringHolder hierarchy > > - Morphic improvements > > Comments are welcomed. > > Stef > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
|
|
In reply to this post by Stéphane Ducasse
Are they all of equal importance? To me it sounds really a lot. And it looks like 1.4 will last quite long until it will be released. What happened to the zinc integration btw.?
Norbert Am 18.06.2011 um 14:59 schrieb Stéphane Ducasse <[hidden email]>: > Hi guys > > here is a kind of dump of roadmap for 1.4 first level is to make sure that we have only one single image. > > - load FileSystem > -> so that we can start to integrate and improve the fileSystem API > > - Load shout, Ocompletion, RBEngine (not OB) so that we can change what should be changed for RPackage to work > > - Ring > -> so that we can start to integrate it > > - Fuel > -> so that we can deprecate SmartRefStream (there may be a problem with mcz (not sure)). > > - I want Opal in 1.4 too. > > - continue to remove StringHolder hierarchy > > - Morphic improvements > > Comments are welcomed. > > Stef > > |
|
|
On Sat, Jun 18, 2011 at 5:18 PM, Norbert Hartl <[hidden email]> wrote: Are they all of equal importance? To me it sounds really a lot. And it looks like 1.4 will last quite long until it will be released. What happened to the zinc integration btw.? Zinc is already in 1.3.
Laurent.
|
User-friendly FFI (was Re: roadmap for 1.4)
|
|
In reply to this post by laurent laffont
On 2011-Jun-18, at 9:07 , laurent laffont wrote: > + a FFI that a stupid idiot like me can use I'm working on it, aiming for a paper at IWST. I posted a request for opinion and help on this yesterday, but got little response (perhaps because it was part of another thread). See: http://lists.gforge.inria.fr/pipermail/pharo-project/2011-June/050298.html ../Dave |
|
|
In reply to this post by NorbertHartl
On Jun 18, 2011, at 5:18 PM, Norbert Hartl wrote: > Are they all of equal importance? no > To me it sounds really a lot. And it looks like 1.4 will last quite long until it will be released. no it can be fast. One of the point is to have the code under our nose so that we can really integrate code. For example, that the browser uses ring as a start. That I can work on RBEngine changes related to RPackage. > What happened to the zinc integration btw.? It is integrated and working well since a while :) > > Norbert > > > > Am 18.06.2011 um 14:59 schrieb Stéphane Ducasse <[hidden email]>: > >> Hi guys >> >> here is a kind of dump of roadmap for 1.4 first level is to make sure that we have only one single image. >> >> - load FileSystem >> -> so that we can start to integrate and improve the fileSystem API >> >> - Load shout, Ocompletion, RBEngine (not OB) so that we can change what should be changed for RPackage to work >> >> - Ring >> -> so that we can start to integrate it >> >> - Fuel >> -> so that we can deprecate SmartRefStream (there may be a problem with mcz (not sure)). >> >> - I want Opal in 1.4 too. >> >> - continue to remove StringHolder hierarchy >> >> - Morphic improvements >> >> Comments are welcomed. >> >> Stef >> >> > |
Re: User-friendly FFI (was Re: roadmap for 1.4)
|
|
In reply to this post by Dave Mason-3
Excellent idea Dave!!!
Stef On Jun 18, 2011, at 5:59 PM, Dave Mason wrote: > > On 2011-Jun-18, at 9:07 , laurent laffont wrote: > >> + a FFI that a stupid idiot like me can use > > I'm working on it, aiming for a paper at IWST. I posted a request for opinion and help on this yesterday, but got little response (perhaps because it was part of another thread). > > See: http://lists.gforge.inria.fr/pipermail/pharo-project/2011-June/050298.html > > ../Dave > |
|
|
In reply to this post by Stéphane Ducasse
I should add a repository for distribution.
Stef On Jun 18, 2011, at 2:59 PM, Stéphane Ducasse wrote: > Hi guys > > here is a kind of dump of roadmap for 1.4 first level is to make sure that we have only one single image. > > - load FileSystem > -> so that we can start to integrate and improve the fileSystem API > > - Load shout, Ocompletion, RBEngine (not OB) so that we can change what should be changed for RPackage to work > > - Ring > -> so that we can start to integrate it > > - Fuel > -> so that we can deprecate SmartRefStream (there may be a problem with mcz (not sure)). > > - I want Opal in 1.4 too. > > - continue to remove StringHolder hierarchy > > - Morphic improvements > > Comments are welcomed. > > Stef > > |
|
|
In reply to this post by Stéphane Ducasse
Hi Stef!
do you mean integrating all them in the Core? Or maybe follow Markus' idea of having just one image? Maybe that's an important discussion to have too :). I can give a hand for the repository stuff. Should we replicate repositories + metacello configs in order to be able to freeze them, isn't it? Guille On Sat, Jun 18, 2011 at 9:59 AM, Stéphane Ducasse <[hidden email]> wrote: Hi guys |
Re: User-friendly FFI (was Re: roadmap for 1.4)
|
|
In reply to this post by Dave Mason-3
On Sat, Jun 18, 2011 at 5:59 PM, Dave Mason <[hidden email]> wrote:
Thank you for this work. The most important for me is to be able to use yaz / Z39.50 (http://www.indexdata.com/yaz) on Linux at least, but my tries have always end to a vm crash ......
Laurent.
|
|
|
In reply to this post by Guillermo Polito
Hi, I think that the best idea is to have one image for the system developers and end-users (for example, I almost never used full Pharo so it lost one tester). On the other hand we should continue with the modularization to allow to generate headless kernel image, gopher image, basic morphic image etc. on the request with bootstrapping. To have smallest possible image is not the main goal of the effort around PharoKernel. The main goal is to have beauty modular system where all dependencies all described well and packages can be easily loaded and unloaded. The buildserver can generate all the set of images for special purposes so it will be more natural then now when we have two main images. -- Pavel
|
|
|
On 19/06/11 1:27 AM, Pavel Krivanek wrote:
> Hi, > > I think that the best idea is to have one image for the system > developers and end-users (for example, I almost never used full Pharo so > it lost one tester). On the other hand we should continue with the > modularization to allow to generate headless kernel image, gopher image, > basic morphic image etc. on the request with bootstrapping. To have > smallest possible image is not the main goal of the effort around > PharoKernel. The main goal is to have beauty modular system where all > dependencies all described well and packages can be easily loaded and > unloaded. The buildserver can generate all the set of images for special > purposes so it will be more natural then now when we have two main images. +1 Me too - I never use full Pharo. I build the image I want from Core. If there were a suitable special purpose image built as outlined above, then that image would be my new starting point. If not, then I guess I would have to start from whatever Core+Dev image results from the process, and then unload stuff (or, if it isn't too big, use it as is). |
|
|
In reply to this post by Guillermo Polito
On Jun 18, 2011, at 10:29 PM, Guillermo Polito wrote: > Hi Stef! > > do you mean integrating all them in the Core? Or maybe follow Markus' idea of having just one image? yes > Maybe that's an important discussion to have too :). > I can give a hand for the repository stuff. Should we replicate repositories + metacello configs in order to be able to freeze them, isn't it? What we want is to avoid to have two images to maintain. Now what I would love to have is the following one configuration for the image that the build system always load and we get something smaller that the current dev. The idea is that core should not be used but there and just as a seed to build the system So I would love to see how we could manage update with Metacello because we would have bootstrap the process seed1 + MT1 => Pharo1 Pharo1 + modifications => MT2 + seed2 (optionally) seed1 or seed2 + MT2 => Pharo2 + modifications Stef > > Guille > > On Sat, Jun 18, 2011 at 9:59 AM, Stéphane Ducasse <[hidden email]> wrote: > Hi guys > > here is a kind of dump of roadmap for 1.4 first level is to make sure that we have only one single image. > > - load FileSystem > -> so that we can start to integrate and improve the fileSystem API > > - Load shout, Ocompletion, RBEngine (not OB) so that we can change what should be changed for RPackage to work > > - Ring > -> so that we can start to integrate it > > - Fuel > -> so that we can deprecate SmartRefStream (there may be a problem with mcz (not sure)). > > - I want Opal in 1.4 too. > > - continue to remove StringHolder hierarchy > > - Morphic improvements > > Comments are welcomed. > > Stef > > > |
|
|
In reply to this post by Yanni Chiu
this is why I want to have a distribution repository and one click load of what we want.
Now in addition we need to have the powerful tools inside the system (core) because we should be able to use the best tools to manage the changes. Stef >> Hi, >> >> I think that the best idea is to have one image for the system >> developers and end-users (for example, I almost never used full Pharo so >> it lost one tester). On the other hand we should continue with the >> modularization to allow to generate headless kernel image, gopher image, >> basic morphic image etc. on the request with bootstrapping. To have >> smallest possible image is not the main goal of the effort around >> PharoKernel. The main goal is to have beauty modular system where all >> dependencies all described well and packages can be easily loaded and >> unloaded. The buildserver can generate all the set of images for special >> purposes so it will be more natural then now when we have two main images. > > +1 > > Me too - I never use full Pharo. I build the image I want from Core. If there were a suitable special purpose image built as outlined above, then that image would be my new starting point. If not, then I guess I would have to start from whatever Core+Dev image results from the process, and then unload stuff (or, if it isn't too big, use it as is). > > |
|
|
In reply to this post by Pavel Krivanek-3
On Sun, Jun 19, 2011 at 7:27 AM, Pavel Krivanek <[hidden email]> wrote:
+1
-- Mariano http://marianopeck.wordpress.com |
|
|
In reply to this post by Pavel Krivanek-3
On Jun 19, 2011, at 7:27 AM, Pavel Krivanek wrote: > Hi, > > I think that the best idea is to have one image for the system developers and end-users (for example, I almost never used full Pharo so it lost one tester). On the other hand we should continue with the modularization to allow to generate headless kernel image, gopher image, basic morphic image etc. on the request with bootstrapping. To have smallest possible image is not the main goal of the effort around PharoKernel. The main goal is to have beauty modular system where all dependencies all described well and packages can be easily loaded and unloaded. The buildserver can generate all the set of images for special purposes so it will be more natural then now when we have two main images. Yes yes yes but :) we should have a set of tools that are working together and we should not be responsible of making sure that all the possible combination work. I would like to get a process (as I mentioned in the other mail) seed + MetacelloSpec + modification => seed' + MetacelloSpec' and that we are able to build hudson that takes aSeed + a spec => run all the tests + run all the quality check Right now we have seed + list of package + modification => seed' + list of package' and we get in trouble when we modify seed parts that influence external package so what we want is to have seed + metacello = the minimal tools that we need to be efficient modifying seed for me OB Engine Shout O/Ecompletion Stef > > -- Pavel > > > > 18.6.2011 v 22:29, Guillermo Polito <[hidden email]>: > >> Hi Stef! >> >> do you mean integrating all them in the Core? Or maybe follow Markus' idea of having just one image? Maybe that's an important discussion to have too :). >> I can give a hand for the repository stuff. Should we replicate repositories + metacello configs in order to be able to freeze them, isn't it? >> >> Guille >> >> On Sat, Jun 18, 2011 at 9:59 AM, Stéphane Ducasse <[hidden email]> wrote: >> Hi guys >> >> here is a kind of dump of roadmap for 1.4 first level is to make sure that we have only one single image. >> >> - load FileSystem >> -> so that we can start to integrate and improve the fileSystem API >> >> - Load shout, Ocompletion, RBEngine (not OB) so that we can change what should be changed for RPackage to work >> >> - Ring >> -> so that we can start to integrate it >> >> - Fuel >> -> so that we can deprecate SmartRefStream (there may be a problem with mcz (not sure)). >> >> - I want Opal in 1.4 too. >> >> - continue to remove StringHolder hierarchy >> >> - Morphic improvements >> >> Comments are welcomed. >> >> Stef >> >> >> |
|
|
What if we try integrating MetacelloBrowser in that PharoCoreWithVitamins? That can solve our one-click-download problem!
Dale, Alex, how's the state of MetacelloBrowser? I've just downloaded it in 1.3 and it works. I got ashamed by the amount of options in the menu, but I managed to find how to load a configuration and a version, jeje. Cheers, Guille On Sun, Jun 19, 2011 at 7:02 AM, Stéphane Ducasse <[hidden email]> wrote:
|
|
|
In reply to this post by Yanni Chiu
Le 19/06/2011 08:10, Yanni Chiu a écrit :
> +1 > > Me too - I never use full Pharo. I build the image I want from Core. If > there were a suitable special purpose image built as outlined above, Same, I don't use anylonger full phaor for dev image nor to distribute drgeo Hilaire |
|
|
In reply to this post by Guillermo Polito
> Dale, Alex, how's the state of MetacelloBrowser? I've just downloaded it in 1.3 and it works. I got ashamed by the amount of options in the menu, but I managed to find how to load a configuration and a version, jeje.
I currently suspended my work on the browser. Unfortunately, I do not have much resources to allocate on it right now. Alexandre > > Cheers, > Guille > > On Sun, Jun 19, 2011 at 7:02 AM, Stéphane Ducasse <[hidden email]> wrote: > > On Jun 19, 2011, at 7:27 AM, Pavel Krivanek wrote: > > > Hi, > > > > I think that the best idea is to have one image for the system developers and end-users (for example, I almost never used full Pharo so it lost one tester). On the other hand we should continue with the modularization to allow to generate headless kernel image, gopher image, basic morphic image etc. on the request with bootstrapping. To have smallest possible image is not the main goal of the effort around PharoKernel. The main goal is to have beauty modular system where all dependencies all described well and packages can be easily loaded and unloaded. The buildserver can generate all the set of images for special purposes so it will be more natural then now when we have two main images. > > Yes yes yes but :) we should have a set of tools that are working together and we should not be responsible of making sure that all the possible combination work. > I would like to get a process (as I mentioned in the other mail) > seed + MetacelloSpec + modification => seed' + MetacelloSpec' > > and that we are able to build hudson that takes > aSeed + a spec > => run all the tests + run all the quality check > > Right now we have > seed + list of package + modification => seed' + list of package' > > and we get in trouble when we modify seed parts that influence external package > > so what we want is to have > seed + metacello = the minimal tools that we need to be efficient modifying seed > for me > OB Engine > Shout > O/Ecompletion > > Stef > > > > > > -- Pavel > > > > > > > > 18.6.2011 v 22:29, Guillermo Polito <[hidden email]>: > > > >> Hi Stef! > >> > >> do you mean integrating all them in the Core? Or maybe follow Markus' idea of having just one image? Maybe that's an important discussion to have too :). > >> I can give a hand for the repository stuff. Should we replicate repositories + metacello configs in order to be able to freeze them, isn't it? > >> > >> Guille > >> > >> On Sat, Jun 18, 2011 at 9:59 AM, Stéphane Ducasse <[hidden email]> wrote: > >> Hi guys > >> > >> here is a kind of dump of roadmap for 1.4 first level is to make sure that we have only one single image. > >> > >> - load FileSystem > >> -> so that we can start to integrate and improve the fileSystem API > >> > >> - Load shout, Ocompletion, RBEngine (not OB) so that we can change what should be changed for RPackage to work > >> > >> - Ring > >> -> so that we can start to integrate it > >> > >> - Fuel > >> -> so that we can deprecate SmartRefStream (there may be a problem with mcz (not sure)). > >> > >> - I want Opal in 1.4 too. > >> > >> - continue to remove StringHolder hierarchy > >> > >> - Morphic improvements > >> > >> Comments are welcomed. > >> > >> Stef > >> > >> > >> > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |