I happened to be back using a Squeak image to run the VM simulator and
wanted to report my experience that it was a *joy* to again be able to
use to delete methods from the System Browser. Over the past
>12 months rather than complain about the double-key shortcuts, I've
given myself time to
Impressive analysis! This is worth to discuss these findings in an academic
venue.
Alexandre
> On Jun 9, 2016, at 6:56 PM, Tudor Girba wrote:
>
> Hi,
>
> Juraj, Andrei and I did a rough analysis collected from 94 computers over the
> past 7 months. Of these, only 42
Hi,
Juraj, Andrei and I did a rough analysis collected from 94 computers over the
past 7 months. Of these, only 42 recorded more than 9 sessions so we only
focused on these. It can be because the rest switched off the data collection
in the meantime. We also excluded the computers of the GT
On Thu, Jun 9, 2016 at 3:26 PM, Esteban Lorenzano
wrote:
> But well… is done :)
> behold the new pharo-nosql organisation!
>
> https://github.com/pharo-nosql
>
> already running with travis ci (appveyor is on the way, in fact is done, I
> just need to modify the vm :P)
>
>
Hi,
> On Jun 9, 2016, at 10:23 AM, Andrei Chis wrote:
>
>
>
> On Wed, Jun 8, 2016 at 9:28 AM, stepharo wrote:
>
>
>
> Le 7/6/16 à 12:00, Andrei Chis a écrit :
>> Hi Peter,
>>
>> On Tue, Jun 7, 2016 at 12:05 AM, Peter Uhnak
So it is clear that we need configurations that will be created and
managed automatically and will enable swapping of repositories. We had
already several discussions on this theme and from my point of view we
need:
- own separate repository for every semi-external project. So
something
2016-06-09 13:21 GMT-03:00 Martin Dias :
> On Thu, Jun 9, 2016 at 9:07 AM, Yanni Chiu wrote:
>> On Thu, Jun 9, 2016 at 2:58 AM, Esteban Lorenzano
>> wrote:
>>> And finally, more we move, more we have encourage to improve the
On Thu, Jun 9, 2016 at 9:07 AM, Yanni Chiu wrote:
> On Thu, Jun 9, 2016 at 2:58 AM, Esteban Lorenzano
> wrote:
>
>>
>> And finally, more we move, more we have encourage to improve the tools,
>> complete the missing parts…
>>
>
> About a year ago I
Branch: refs/tags/60074
Home: https://github.com/pharo-project/pharo-core
Branch: refs/heads/6.0
Home: https://github.com/pharo-project/pharo-core
Commit: f826c9d2a2e22c127482ee6138fc8a0515c1914d
https://github.com/pharo-project/pharo-core/commit/f826c9d2a2e22c127482ee6138fc8a0515c1914d
Author: Jenkins Build Server
Date:
2016-06-09 16:32 GMT+02:00 stepharo :
> I have a mental block to contributing to part of Pharo maintained in
>> external repositories. Maybe its unreasonable, but it just *feels*
>> like too much friction. If I've worked on an issue, I. just. want.
>> to. submit. it!
>>
>
>
Branch: refs/tags/60073
Home: https://github.com/pharo-project/pharo-core
Branch: refs/heads/6.0
Home: https://github.com/pharo-project/pharo-core
Commit: 6a81dea7b05b7017ebbcd7a9363fea0545ee74cd
https://github.com/pharo-project/pharo-core/commit/6a81dea7b05b7017ebbcd7a9363fea0545ee74cd
Author: Jenkins Build Server
Date:
Le 9/6/16 à 09:04, Marcus Denker a écrit :
On 08 Jun 2016, at 19:46, stepharo wrote:
60072
18451 Do not use #ifNotNilDo:ifNil:, #ifNil:ifNotNilDo:, #ifNotNilDo:
https://pharo.fogbugz.com/f/cases/18451
Is there a rule for such case?
Indeed, there are!
On Thu, Jun 9, 2016 at 3:42 PM, Pavel Krivanek wrote:
>
>
> 2016-06-08 19:40 GMT+02:00 stepharo :
>>
>> ***THANKS*** Pavel.
>>
>> Yes it is the best way to make sure that nobody wants to work at this
>> level. We discussed this problem during the last
Cargo will not fix the dependency mess.
maybe it will be easy the process, but it will not fix the real problem: we
have a system that’s not made in a modular way. We are working hard to make it
possible, but until we finish that there will be fixes that will touch more
than one “module” and
> On 09 Jun 2016, at 10:03, Denis Kudriashov wrote:
>
> So does we all agree to commit fixes for external packages by slices without
> new configs?
that would break the bootstrap process, so no.
Esteban
>
> 2016-06-09 9:42 GMT+02:00 Pavel Krivanek
On Thu, Jun 9, 2016 at 9:58 AM, Pavel Krivanek wrote:
> We cannot do that right now. I hope that we will replace configurations with
> Cargo.
When Cargo will be deployed ?
--
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
We cannot do that right now. I hope that we will replace configurations
with Cargo.
-- Pavel
2016-06-09 10:03 GMT+02:00 Denis Kudriashov :
> So does we all agree to commit fixes for external packages by slices
> without new configs?
>
> 2016-06-09 9:42 GMT+02:00 Pavel
On Thu, Jun 9, 2016 at 10:23 AM, Andrei Chis
wrote:
>
>
> On Wed, Jun 8, 2016 at 9:28 AM, stepharo wrote:
>
>>
>>
>> Le 7/6/16 à 12:00, Andrei Chis a écrit :
>>
>> Hi Peter,
>>
>> On Tue, Jun 7, 2016 at 12:05 AM, Peter Uhnak
On Wed, Jun 8, 2016 at 9:28 AM, stepharo wrote:
>
>
> Le 7/6/16 à 12:00, Andrei Chis a écrit :
>
> Hi Peter,
>
> On Tue, Jun 7, 2016 at 12:05 AM, Peter Uhnak wrote:
>
>> Hi,
>>
>> Privacy>>sendDiagnosticsAndUsageData should be ternary, not binary.
>>
>>
So does we all agree to commit fixes for external packages by slices
without new configs?
2016-06-09 9:42 GMT+02:00 Pavel Krivanek :
>
>
> 2016-06-08 19:40 GMT+02:00 stepharo :
>
>> ***THANKS*** Pavel.
>>
>> Yes it is the best way to make sure that
2016-06-08 19:40 GMT+02:00 stepharo :
> ***THANKS*** Pavel.
>
> Yes it is the best way to make sure that nobody wants to work at this
> level. We discussed this problem during the last board meeting. This is why
> I proposed the following process.
>
> When the core Pharo
> On 08 Jun 2016, at 19:46, stepharo wrote:
>
>
>> 60072
>> 18451 Do not use #ifNotNilDo:ifNil:, #ifNil:ifNotNilDo:, #ifNotNilDo:
>> https://pharo.fogbugz.com/f/cases/18451
>>
>>
>
> Is there a rule for such case?
>
Indeed, there are!
RBRuleIfNotEmptyDo
yes, this is one of my intentions: MongoTalk and Voyage are very co-dependent
tools and needs to be close.
for example, we have a new MongoTalk version and Voyage depends on it, but
there is no stable configuration so people is having a lot of problems. Of
course this is easy fixable, but if
> On 09 Jun 2016, at 08:58, Esteban Lorenzano wrote:
>
> well, I think is the opposite: at this moment all active voyage developers
> are already using git/github (because voyage is being developed there, just
> in mine repository)… and it happens they are also the
Hi,
> On 09 Jun 2016, at 00:51, Stephan Eggermont wrote:
>
> On 08/06/16 11:54, Esteban Lorenzano wrote:
>> Using github we can benefit of their tools to improve our process
>> (issue tracker, travis and appveyor, etc.) and we will improve
>> project visibility.
>
> I fear
27 matches
Mail list logo