+1
On Wed, Jan 4, 2012 at 1:45 PM, Norbert Hartl wrote:
> Can we lower tension a bit? To me it sounds as you are pretty much in sync.
>
> Am 03.01.2012 um 09:09 schrieb Stéphane Ducasse:
>
>>
>
> Then my question is: How can anybody use Pharo that does not want to
> use your changes o
Can we lower tension a bit? To me it sounds as you are pretty much in sync.
Am 03.01.2012 um 09:09 schrieb Stéphane Ducasse:
>
Then my question is: How can anybody use Pharo that does not want to
use your changes of AST and FS?
>>>
>>> Normally we talk and we reach a consensus.
>>>
>>> Then my question is: How can anybody use Pharo that does not want to
>>> use your changes of AST and FS?
>>
>> Normally we talk and we reach a consensus.
>
> The issue here is that FS was a separately maintained package that was (and
> apparently still is) loaded into different places.
On 02/01/12 2:58 PM, Stéphane Ducasse wrote:
On Jan 2, 2012, at 8:42 PM, Lukas Renggli wrote:
How can the core of pharo work with FS if FS is not loaded in Pharo?
Then my question is: How can anybody use Pharo that does not want to
use your changes of AST and FS?
Normally we talk and we re
>>
>>
>>> - Announcements-*: A big problem, but simple enough to work around.
>>> - FileSystem-*: A big problem, the method renaming make it impossible
>>> to use it with any code that depends on the official version.
>>
>> How can the core of pharo work with FS if FS is not loaded in Pharo?
>
On Jan 2, 2012, at 8:42 PM, Lukas Renggli wrote:
- beside RB and Announcements, are there other things that could be
problematic
>>>
>>> Anything that is forked and changed, and that has existing could
>>> become a potential problem:
>>>
>>> - AST-*: No changes at the moment.
>>
>>
>>> - beside RB and Announcements, are there other things that could be
>>> problematic
>>
>> Anything that is forked and changed, and that has existing could
>> become a potential problem:
>>
>> - AST-*: No changes at the moment.
>
> We plan to change it.
> I asked camillo to discuss the changes
On Jan 2, 2012, at 6:24 PM, Lukas Renggli wrote:
>> - beside RB and Announcements, are there other things that could be
>> problematic
>
> Anything that is forked and changed, and that has existing could
> become a potential problem:
>
> - AST-*: No changes at the moment.
We plan to change it
> - beside RB and Announcements, are there other things that could be
> problematic
Anything that is forked and changed, and that has existing could
become a potential problem:
- AST-*: No changes at the moment.
- Announcements-*: A big problem, but simple enough to work around.
- FileSystem-*:
This is indeed important. I tried several times to use Pharo 1.4 but I could
not really work with it unfortunately. I am stuck with 1.3
> Please, let's discuss this roadmap. Not listing wishes, but actionable points.
>
> I start with some questions:
> - beside RB and Announcements, are there oth
and wizard issues...
Dale
- Original Message -
| From: "Guillermo Polito"
| To: Pharo-project@lists.gforge.inria.fr, metace...@googlegroups.com
| Sent: Sunday, June 19, 2011 7:08:25 AM
| Subject: Re: [Pharo-project] roadmap for 1.4
|
| What if we try integrating Meta
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
On Jun 19, 2011, at 4:24 PM, Tudor Girba wrote:
> Hi,
>
> Sounds good.
>
> Is there a coordinated effort for Morphic improvements?
Not that I know.
What we will try is to
- review changes proposed by fernando
- write some text of widgets and clean the system with ben
Stef
>
Hi,
Sounds good.
Is there a coordinated effort for Morphic improvements?
Cheers,
Doru
On 18 Jun 2011, at 14: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
>
> 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 ha
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
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
> all
On Sun, 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
> allo
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
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
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 k
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
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,
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 integr
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
integ
On Sat, Jun 18, 2011 at 5:18 PM, Norbert Hartl 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.
>
> Norbert
>
>
>
>
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 :
> Hi guys
>
> here is a kind of dump of roadmap for 1.4
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 fileSyste
On Sat, 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, O
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
Hi
I will harvest later today the fix of gabriel for license cleaning.
I would like that we continue this effort and check the tests.
I saw that some traits tests are yellow now.
I will try to harvest the speed up of multibytestream proposed by
nicolas.
Stef
__
31 matches
Mail list logo
