Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])

[Nicolas Cellier]

Hi Torsten,
it's early enough for that change to happen in all dialects, no backward
compatibility support necessary, no deprecation policy, so if Pharo comes
with good selectors we can make them universal.

Nicolas

2017-09-11 19:06 GMT+02:00 Torsten Bergmann :

> And me ...
>
> Squeak and Cuis have the same name/implementation for - pin, unpin,
> isPinned, setPinned: (private) as we have in Pharo
> now (now also in the same method categories) and unnecessary
> differences/incompatibilities in the Kernel would not make much sense.
>
> If it would really be necessary to change them it would only make sense to
> change them equally on all Open-Smalltalk
> VM based systems. Currently I also do not see any necessity.
>
> If there are clashes for Calypso tabs then why not change it there (with
> more specific method names like #isPinnedTab. #isPinnedToWindow
> or #isPinnedToBrowser)
>
> Bye
> T.
>
>
> Gesendet: Montag, 11. September 2017 um 14:16 Uhr
> Von: "Esteban Lorenzano" 
> An: "Pharo Development List" 
> Betreff: Re: [Pharo-dev] Maybe better pinning messages? (inspired by
> [Pinning Objects in Pharo])
>
> yes, me :)
>
> I do not see a reason to change them, tbh.
> for me they are comprensible as they are now and it does not adds more
> information pinInMemory or pinMemory.
>
> Esteban
>
>
>
>
> On 11 Sep 2017, at 11:56, Denis Kudriashov  ionisi...@gmail.com]> wrote:
>
> Anybody else?
>
> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek  mailto:pavel.kriva...@gmail.com]>:
>
>
> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov  ionisi...@gmail.com]>:
> Hi.
>
> We now have very generic message names:
> - pin
> - unpin
> - setPinned:
> - isPinned
>
> Problem that they collide with possible domain related names.
> For example I implemented pinning of tabs in Calypso and I found that I
> overrides #pin and #isPinned messages. Then I fix it with different names.
> Probably menus also uses pin word but without overrides
>
> What you think about renaming pinning messages? Something like:
> - pinMemory
>
> I would use pinInMemory
>
> -- Pavel
>
>
> - unpinMemory
> - isMemoryPinned
> - setPinnedMemory:
> - pinMemoryDuring: (if we will introduce it)
>
> I think it is easy to do now because not much code uses pinning
>
>

Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])

[Peter Uhnák]

> for me they are comprensible as they are now and it does not adds more
information pinInMemory or pinMemory.

it is not about comprehension, but about not mixing meta and domain
selectors.

On Mon, Sep 11, 2017 at 7:06 PM, Torsten Bergmann  wrote:

> And me ...
>
> Squeak and Cuis have the same name/implementation for - pin, unpin,
> isPinned, setPinned: (private) as we have in Pharo
> now (now also in the same method categories) and unnecessary
> differences/incompatibilities in the Kernel would not make much sense.
>
> If it would really be necessary to change them it would only make sense to
> change them equally on all Open-Smalltalk
> VM based systems. Currently I also do not see any necessity.
>
> If there are clashes for Calypso tabs then why not change it there (with
> more specific method names like #isPinnedTab. #isPinnedToWindow
> or #isPinnedToBrowser)
>
> Bye
> T.
>
>
> Gesendet: Montag, 11. September 2017 um 14:16 Uhr
> Von: "Esteban Lorenzano" 
> An: "Pharo Development List" 
> Betreff: Re: [Pharo-dev] Maybe better pinning messages? (inspired by
> [Pinning Objects in Pharo])
>
> yes, me :)
>
> I do not see a reason to change them, tbh.
> for me they are comprensible as they are now and it does not adds more
> information pinInMemory or pinMemory.
>
> Esteban
>
>
>
>
> On 11 Sep 2017, at 11:56, Denis Kudriashov  ionisi...@gmail.com]> wrote:
>
> Anybody else?
>
> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek  mailto:pavel.kriva...@gmail.com]>:
>
>
> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov  ionisi...@gmail.com]>:
> Hi.
>
> We now have very generic message names:
> - pin
> - unpin
> - setPinned:
> - isPinned
>
> Problem that they collide with possible domain related names.
> For example I implemented pinning of tabs in Calypso and I found that I
> overrides #pin and #isPinned messages. Then I fix it with different names.
> Probably menus also uses pin word but without overrides
>
> What you think about renaming pinning messages? Something like:
> - pinMemory
>
> I would use pinInMemory
>
> -- Pavel
>
>
> - unpinMemory
> - isMemoryPinned
> - setPinnedMemory:
> - pinMemoryDuring: (if we will introduce it)
>
> I think it is easy to do now because not much code uses pinning
>
>

Re: [Pharo-dev] argh, tests are failing!

[Juraj Kubelka]

Hi Guillermo,

I have not found better solution. Waiting without a timeout threshold is not 
nice and makes it difficult to run all tests. 
If you have better idea how to sync and test two processes, I will appreciate 
it. 
Otherwise I will use a higher timeout.

Cheers,
Juraj

> El 11-09-2017, a las 06:55, Guillermo Polito  
> escribió:
> 
> Hi Juraj,
> 
> think that it may really depend on the machine and the state of the system. 
> Slower slave machines could not really work with that timeout...
> 
> The question is how could we make such test more robust.
> 
> On Sun, Sep 10, 2017 at 6:41 PM, Juraj Kubelka  > wrote:
> Hi,
> 
> I have checked the EventRecorderTests and it works on my computer. The only 
> reason that it might not work on other cases is that there an assert for 
> 'semaphore waitTimeoutMSecs: 200’. I can put higher timeout if necessary. The 
> timeout 200 has worked for couple of years, right?. There might be another 
> issue.
> 
> Cheers,
> Juraj
> 
>> El 10-09-2017, a las 10:13, Guillermo Polito > > escribió:
>> 
>> Hi all,
>> 
>> Since a couple of builds we have consistently failing the following tests:
>> 
>> GT.EventRecorder.Tests.Core.GTEventRecorderTest.testDeliverNow2 
>> 
>> GT.EventRecorder.Tests.Core.GTEventRecorderTest.testNotDeliveredDataShouldBeResent
>>  
>> 
>> Kernel.Tests.Processes.MutexTest.testFailedCriticalSectionShouldUnblockWaitingOne
>>  
>> 
>> ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol
>>  
>> 
>> ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol
>>  
>> 
>> ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol
>>  
>> 
>> ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol
>>  
>> 
>> ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol
>>  
>> 
>> ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol
>>  
>> 
>> ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol
>>  
>> 
>> 
>> 
>> Green builds are the only hard metric to say if the build is healthy or not.
>> 
>> - We should not integrate anything until the build is green again...
>> 
>> Also, we spent with Pablo a lot of time to have a green build in all 
>> platforms...  I'd like to spend my time in other fun stuff than the CI :/
>> 
>> -- 
>>
>> Guille Polito
>> 
>> Research Engineer
>> 

Re: [Pharo-dev] argh, tests are failing!

[Stephane Ducasse]

>
>
>>
> As Pavel said, the iceberg version that is included in the system is the
> one described in
>
> BaselineOfIDE >> loadIceberg
>
> Metacello new
> baseline: 'Iceberg';
> repository: 'github://pharo-vcs/iceberg:v0.5.7';
> load.
> (Smalltalk classNamed: #Iceberg) enableMetacelloIntegration: true.
>
> So updating that method with the new iceberg version and pushing that to
> Pharo should be enough.
>

Good to know that.


> In any case, my mail was there just to raise the issue of the failing
> tests. We should care about failing tests, and I'll cry out loud everytime
> they are broken, just to make it explicit.
>

I agree.

Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])

[Torsten Bergmann]

And me ... 

Squeak and Cuis have the same name/implementation for - pin, unpin, isPinned, 
setPinned: (private) as we have in Pharo 
now (now also in the same method categories) and unnecessary 
differences/incompatibilities in the Kernel would not make much sense. 

If it would really be necessary to change them it would only make sense to 
change them equally on all Open-Smalltalk 
VM based systems. Currently I also do not see any necessity.

If there are clashes for Calypso tabs then why not change it there (with more 
specific method names like #isPinnedTab. #isPinnedToWindow 
or #isPinnedToBrowser)

Bye
T.
 

Gesendet: Montag, 11. September 2017 um 14:16 Uhr
Von: "Esteban Lorenzano" 
An: "Pharo Development List" 
Betreff: Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning 
Objects in Pharo])

yes, me :)
 
I do not see a reason to change them, tbh.
for me they are comprensible as they are now and it does not adds more 
information pinInMemory or pinMemory.
 
Esteban
 

 

On 11 Sep 2017, at 11:56, Denis Kudriashov 
mailto:dionisi...@gmail.com]> wrote: 

Anybody else?
 
2017-08-31 10:29 GMT+02:00 Pavel Krivanek 
mailto:pavel.kriva...@gmail.com]>:
 
 
2017-08-31 10:24 GMT+02:00 Denis Kudriashov 
mailto:dionisi...@gmail.com]>:
Hi.
 
We now have very generic message names:
- pin
- unpin
- setPinned:
- isPinned
 
Problem that they collide with possible domain related names. 
For example I implemented pinning of tabs in Calypso and I found that I 
overrides #pin and #isPinned messages. Then I fix it with different names.
Probably menus also uses pin word but without overrides
 
What you think about renaming pinning messages? Something like:
- pinMemory
 
I would use pinInMemory
 
-- Pavel
 

- unpinMemory
- isMemoryPinned
- setPinnedMemory:
- pinMemoryDuring: (if we will introduce it)
 
I think it is easy to do now because not much code uses pinning

Re: [Pharo-dev] Build #111

[Torsten Bergmann]

If we can keep it green each day with a new build number will 
be a release day ;)

Have fun
T. 
 

Gesendet: Montag, 11. September 2017 um 18:23 Uhr
Von: "Stephane Ducasse" 
An: "Pharo Development List" 
Betreff: Re: [Pharo-dev] Build #111

Thanks you guys!!!
 
 
On Mon, Sep 11, 2017 at 5:31 PM, Denis Kudriashov 
mailto:dionisi...@gmail.com]> wrote:
I add another push request

 
2017-09-11 17:16 GMT+02:00 Guillermo Polito 
mailto:guillermopol...@gmail.com]>:
Ahh It's a different one!

 
On Mon, Sep 11, 2017 at 5:14 PM, Denis Kudriashov 
mailto:dionisi...@gmail.com]> wrote:
But this SemaphoreTest is not mine :). Now I only improve MutexTest

 
2017-09-11 17:09 GMT+02:00 Guillermo Polito 
mailto:guillermopol...@gmail.com]>:
Hi all,
 
since the build #111 there is a new version of iceberg. I'll let Esteban get 
into the details of that. From what respects to me, this build fixes 9 failing 
tests:
 
https://github.com/pharo-project/pharo/pull/267[https://github.com/pharo-project/pharo/pull/267]
 
The build has however one failing test that fails randomly:
 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/]
 
 
Kernel.Tests.Processes.SemaphoreTest.testMutualExclusion[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/lastCompletedBuild/testReport/Kernel.Tests.Processes/SemaphoreTest/testMutualExclusion/]
 
Denis has proposed a solution for that, so we will have a green build back soon 
:)

 --

   
Guille Polito
 
Research Engineer
French National Center for Scientific Research - 
http://www.cnrs.fr[http://www.cnrs.fr]
 
 
Web: http://guillep.github.io[http://guillep.github.io]
Phone: +33 06 52 70 66 13
 
 --

   
Guille Polito
 
Research Engineer
French National Center for Scientific Research - 
http://www.cnrs.fr[http://www.cnrs.fr]
 
 
Web: http://guillep.github.io[http://guillep.github.io]
Phone: +33 06 52 70 66 13

Re: [Pharo-dev] Build #111

[Stephane Ducasse]

Thanks you guys!!!


On Mon, Sep 11, 2017 at 5:31 PM, Denis Kudriashov 
wrote:

> I add another push request
>
> 2017-09-11 17:16 GMT+02:00 Guillermo Polito :
>
>> Ahh It's a different one!
>>
>> On Mon, Sep 11, 2017 at 5:14 PM, Denis Kudriashov 
>> wrote:
>>
>>> But this SemaphoreTest is not mine :). Now I only improve MutexTest
>>>
>>> 2017-09-11 17:09 GMT+02:00 Guillermo Polito :
>>>
 Hi all,

 since the build #111 there is a new version of iceberg. I'll let
 Esteban get into the details of that. From what respects to me, this build
 fixes 9 failing tests:

 https://github.com/pharo-project/pharo/pull/267

 The build has however one failing test that fails randomly:

 https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20p
 ull%20request%20and%20branch%20Pipeline/job/development/

  Kernel.Tests.Processes.SemaphoreTest.testMutualExclusion
 

 Denis has proposed a solution for that, so we will have a green build
 back soon :)

 --



 Guille Polito


 Research Engineer

 French National Center for Scientific Research - *http://www.cnrs.fr*
 



 *Web:* *http://guillep.github.io* 

 *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>

>>>
>>>
>>
>>
>> --
>>
>>
>>
>> Guille Polito
>>
>>
>> Research Engineer
>>
>> French National Center for Scientific Research - *http://www.cnrs.fr*
>> 
>>
>>
>>
>> *Web:* *http://guillep.github.io* 
>>
>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>>
>
>

Re: [Pharo-dev] Build #111

[Denis Kudriashov]

I add another push request

2017-09-11 17:16 GMT+02:00 Guillermo Polito :

> Ahh It's a different one!
>
> On Mon, Sep 11, 2017 at 5:14 PM, Denis Kudriashov 
> wrote:
>
>> But this SemaphoreTest is not mine :). Now I only improve MutexTest
>>
>> 2017-09-11 17:09 GMT+02:00 Guillermo Polito :
>>
>>> Hi all,
>>>
>>> since the build #111 there is a new version of iceberg. I'll let Esteban
>>> get into the details of that. From what respects to me, this build fixes 9
>>> failing tests:
>>>
>>> https://github.com/pharo-project/pharo/pull/267
>>>
>>> The build has however one failing test that fails randomly:
>>>
>>> https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20p
>>> ull%20request%20and%20branch%20Pipeline/job/development/
>>>
>>>  Kernel.Tests.Processes.SemaphoreTest.testMutualExclusion
>>> 
>>>
>>> Denis has proposed a solution for that, so we will have a green build
>>> back soon :)
>>>
>>> --
>>>
>>>
>>>
>>> Guille Polito
>>>
>>>
>>> Research Engineer
>>>
>>> French National Center for Scientific Research - *http://www.cnrs.fr*
>>> 
>>>
>>>
>>>
>>> *Web:* *http://guillep.github.io* 
>>>
>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>>>
>>
>>
>
>
> --
>
>
>
> Guille Polito
>
>
> Research Engineer
>
> French National Center for Scientific Research - *http://www.cnrs.fr*
> 
>
>
>
> *Web:* *http://guillep.github.io* 
>
> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>

Re: [Pharo-dev] Build #111

[Guillermo Polito]

Ahh It's a different one!

On Mon, Sep 11, 2017 at 5:14 PM, Denis Kudriashov 
wrote:

> But this SemaphoreTest is not mine :). Now I only improve MutexTest
>
> 2017-09-11 17:09 GMT+02:00 Guillermo Polito :
>
>> Hi all,
>>
>> since the build #111 there is a new version of iceberg. I'll let Esteban
>> get into the details of that. From what respects to me, this build fixes 9
>> failing tests:
>>
>> https://github.com/pharo-project/pharo/pull/267
>>
>> The build has however one failing test that fails randomly:
>>
>> https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20p
>> ull%20request%20and%20branch%20Pipeline/job/development/
>>
>>  Kernel.Tests.Processes.SemaphoreTest.testMutualExclusion
>> 
>>
>> Denis has proposed a solution for that, so we will have a green build
>> back soon :)
>>
>> --
>>
>>
>>
>> Guille Polito
>>
>>
>> Research Engineer
>>
>> French National Center for Scientific Research - *http://www.cnrs.fr*
>> 
>>
>>
>>
>> *Web:* *http://guillep.github.io* 
>>
>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>>
>
>


-- 



Guille Polito


Research Engineer

French National Center for Scientific Research - *http://www.cnrs.fr*




*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Build #111

[Denis Kudriashov]

But this SemaphoreTest is not mine :). Now I only improve MutexTest

2017-09-11 17:09 GMT+02:00 Guillermo Polito :

> Hi all,
>
> since the build #111 there is a new version of iceberg. I'll let Esteban
> get into the details of that. From what respects to me, this build fixes 9
> failing tests:
>
> https://github.com/pharo-project/pharo/pull/267
>
> The build has however one failing test that fails randomly:
>
> https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%
> 20pull%20request%20and%20branch%20Pipeline/job/development/
>
>  Kernel.Tests.Processes.SemaphoreTest.testMutualExclusion
> 
>
> Denis has proposed a solution for that, so we will have a green build back
> soon :)
>
> --
>
>
>
> Guille Polito
>
>
> Research Engineer
>
> French National Center for Scientific Research - *http://www.cnrs.fr*
> 
>
>
>
> *Web:* *http://guillep.github.io* 
>
> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>

[Pharo-dev] Build #111

[Guillermo Polito]

Hi all,

since the build #111 there is a new version of iceberg. I'll let Esteban
get into the details of that. From what respects to me, this build fixes 9
failing tests:

https://github.com/pharo-project/pharo/pull/267

The build has however one failing test that fails randomly:

https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/

 Kernel.Tests.Processes.SemaphoreTest.testMutualExclusion


Denis has proposed a solution for that, so we will have a green build back
soon :)

-- 



Guille Polito


Research Engineer

French National Center for Scientific Research - *http://www.cnrs.fr*




*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])

[Esteban A. Maringolo]

I understand it's not about the intention revealing of the selector, but
about not making #pin:/#unpin: a kind of "reserved selector" as many
implemented in Object.

Regards,

Esteban A. Maringolo

2017-09-11 9:16 GMT-03:00 Esteban Lorenzano :

> yes, me :)
>
> I do not see a reason to change them, tbh.
> for me they are comprensible as they are now and it does not adds more
> information pinInMemory or pinMemory.
>
> Esteban
>
>
> On 11 Sep 2017, at 11:56, Denis Kudriashov  wrote:
>
> Anybody else?
>
> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek :
>
>>
>>
>> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov :
>>
>>> Hi.
>>>
>>> We now have very generic message names:
>>> - pin
>>> - unpin
>>> - setPinned:
>>> - isPinned
>>>
>>> Problem that they collide with possible domain related names.
>>> For example I implemented pinning of tabs in Calypso and I found that I
>>> overrides #pin and #isPinned messages. Then I fix it with different names.
>>> Probably menus also uses pin word but without overrides
>>>
>>> What you think about renaming pinning messages? Something like:
>>> - pinMemory
>>>
>>
>> I would use pinInMemory
>>
>> -- Pavel
>>
>>
>>> - unpinMemory
>>> - isMemoryPinned
>>> - setPinnedMemory:
>>> - pinMemoryDuring: (if we will introduce it)
>>>
>>> I think it is easy to do now because not much code uses pinning
>>>
>>
>>
>
>

Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])

[Esteban Lorenzano]

yes, me :)

I do not see a reason to change them, tbh.
for me they are comprensible as they are now and it does not adds more 
information pinInMemory or pinMemory.

Esteban


> On 11 Sep 2017, at 11:56, Denis Kudriashov  wrote:
> 
> Anybody else?
> 
> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek  >:
> 
> 
> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov  >:
> Hi.
> 
> We now have very generic message names:
> - pin
> - unpin
> - setPinned:
> - isPinned
> 
> Problem that they collide with possible domain related names. 
> For example I implemented pinning of tabs in Calypso and I found that I 
> overrides #pin and #isPinned messages. Then I fix it with different names.
> Probably menus also uses pin word but without overrides
> 
> What you think about renaming pinning messages? Something like:
> - pinMemory
> 
> I would use pinInMemory
> 
> -- Pavel
>  
> - unpinMemory
> - isMemoryPinned
> - setPinnedMemory:
> - pinMemoryDuring: (if we will introduce it)
> 
> I think it is easy to do now because not much code uses pinning
> 
> 

Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])

[Norbert Hartl]

I don't think we should come up with a new naming scheme every now and then. If 
I look at the read-only support there the selector is

beReadOnlyObject

so in this case it should be

bePinnedObject

I didn't like the extra Object at the end but now I think it makes it clear and 
still steps aside for user code to implement something like pin/unpin/bePinned

Norbert



> Am 11.09.2017 um 11:56 schrieb Denis Kudriashov :
> 
> Anybody else?
> 
> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek  >:
> 
> 
> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov  >:
> Hi.
> 
> We now have very generic message names:
> - pin
> - unpin
> - setPinned:
> - isPinned
> 
> Problem that they collide with possible domain related names. 
> For example I implemented pinning of tabs in Calypso and I found that I 
> overrides #pin and #isPinned messages. Then I fix it with different names.
> Probably menus also uses pin word but without overrides
> 
> What you think about renaming pinning messages? Something like:
> - pinMemory
> 
> I would use pinInMemory
> 
> -- Pavel
>  
> - unpinMemory
> - isMemoryPinned
> - setPinnedMemory:
> - pinMemoryDuring: (if we will introduce it)
> 
> I think it is easy to do now because not much code uses pinning
> 
> 

Re: [Pharo-dev] Iceberg causes 64 bit VM core dump on Ubuntu

[Alistair Grant]

On Mon, Sep 11, 2017 at 12:45:34PM +0200, stephan wrote:
> 
> On 11-09-17 11:38, Alistair Grant wrote:
> >> Stephan
> >
> > Thanks for taking a look at this.
> >
> > I realised that this was a bad example after I posted it.  This script
> > also demonstrates the problem:
> 
> But how can it work if you are trying to use file attributes that you can
> not access?

It can't, that's why it is a bad example :-)


> Your new script does not write a core dump, but the console says

OK, the good news is that someone else can reproduce the problem.

Hopefully Esteban can solve it quickly, otherwise I'll eventually try
and narrow it down (I'm side-tracked with tax returns at the moment
:-().


Thanks!
Alistair


> *** Error in `./lib/pharo/5.0-201708312323/pharo': malloc(): memory
> corruption: 0x7fee9d0acfa0 ***
> === Backtrace: =
> /lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7fee9c4ac7e5]
> /lib/x86_64-linux-gnu/libc.so.6(+0x8213e)[0x7fee9c4b713e]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x54)[0x7fee9c4b9184]
> ./lib/pharo/5.0-201708312323/pharo[0x4c2510]
> [0x1c01318]
> === Memory map: 
> 0040-0053b000 r-xp  08:02 22679114 
> /home/stephan/Desktop/testpharo/pharo-linux-x86_64threaded-201708312323-caa8241/lib/pharo/5.0-201708312323/pharo
> 0073b000-0073c000 r--p 0013b000 08:02 22679114 
> /home/stephan/Desktop/testpharo/pharo-linux-x86_64threaded-201708312323-caa8241/lib/pharo/5.0-201708312323/pharo
> 0073c000-0074d000 rw-p 0013c000 08:02 22679114 
> /home/stephan/Desktop/testpharo/pharo-linux-x86_64threaded-201708312323-caa8241/lib/pharo/5.0-201708312323/pharo
> 0074d000-00816000 rw-p  00:00 0
> 01af6000-01b71000 rw-p  00:00 0 [heap]
> 01b71000-01b72000 rwxp  00:00 0 [heap]
> 01b72000-01bd9000 rw-p  00:00 0 [heap]
> 01c0-01d5e000 rwxp  00:00 0
> 01d5e000-06f0 rw-p  00:00 0
> 7fee8c00-7fee8c021000 rw-p  00:00 0
> 7fee8c021000-7fee9000 ---p  00:00 0
> 7fee920fe000-7fee92114000 r-xp  08:02 37491026
> /lib/x86_64-linux-gnu/libgcc_s.so.1
> 7fee92114000-7fee92313000 ---p 00016000 08:02 37491026
> /lib/x86_64-linux-gnu/libgcc_s.so.1
> 7fee92313000-7fee92314000 rw-p 00015000 08:02 37491026
> /lib/x86_64-linux-gnu/libgcc_s.so.1
> 7fee92314000-7fee92319000 r-xp  08:02 37488133
> /lib/x86_64-linux-gnu/libnss_dns-2.23.so
> 7fee92319000-7fee92519000 ---p 5000 08:02 37488133
> /lib/x86_64-linux-gnu/libnss_dns-2.23.so
> 7fee92519000-7fee9251a000 r--p 5000 08:02 37488133
> /lib/x86_64-linux-gnu/libnss_dns-2.23.so
> 7fee9251a000-7fee9251b000 rw-p 6000 08:02 37488133
> /lib/x86_64-linux-gnu/libnss_dns-2.23.so
> 7fee9251b000-7fee9251d000 r-xp  08:02 37491093
> /lib/x86_64-linux-gnu/libnss_mdns4_minimal.so.2
> 7fee9251d000-7fee9271c000 ---p 2000 08:02 37491093
> /lib/x86_64-linux-gnu/libnss_mdns4_minimal.so.2
> 7fee9271c000-7fee9271d000 r--p 1000 08:02 37491093
> /lib/x86_64-linux-gnu/libnss_mdns4_minimal.so.2
> 7fee9271d000-7fee9271e000 rw-p 2000 08:02 37491093
> /lib/x86_64-linux-gnu/libnss_mdns4_minimal.so.2
> 7fee9271e000-7fee92727000 r-xp  08:02 37488139
> /lib/x86_64-linux-gnu/libcrypt-2.23.so
> 7fee92727000-7fee92926000 ---p 9000 08:02 37488139
> /lib/x86_64-linux-gnu/libcrypt-2.23.so
> 7fee92926000-7fee92927000 r--p 8000 08:02 37488139
> /lib/x86_64-linux-gnu/libcrypt-2.23.so
> 7fee92927000-7fee92928000 rw-p 9000 08:02 37488139
> /lib/x86_64-linux-gnu/libcrypt-2.23.so
> 7fee92928000-7fee92956000 rw-p  00:00 0
> 7fee92956000-7fee92a25000 r-xp  08:02 57287405
> /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6
> 7fee92a25000-7fee92c25000 ---p 000cf000 08:02 57287405
> /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6
> 7fee92c25000-7fee92c28000 r--p 000cf000 08:02 57287405
> /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6
> 7fee92c28000-7fee92c2a000 rw-p 000d2000 08:02 57287405
> /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6
> 7fee92c2a000-7fee92c2b000 rw-p  00:00 0
> 7fee92c2b000-7fee92c72000 r-xp  08:02 57285008
> /usr/lib/x86_64-linux-gnu/libhx509.so.5.0.0
> 7fee92c72000-7fee92e71000 ---p 00047000 08:02 57285008
> /usr/lib/x86_64-linux-gnu/libhx509.so.5.0.0
> 7fee92e71000-7fee92e73000 r--p 00046000 08:02 57285008
> /usr/lib/x86_64-linux-gnu/libhx509.so.5.0.0
> 7fee92e73000-7fee92e75000 rw-p 00048000 08:02 57285008
> /usr/lib/x86_64-linux-gnu/libhx509.so.5.0.0
> 7fee92e75000-7fee92e76000 rw-p  00:00 0
> 7fee92e76000-7fee92e84000 r-xp  08:02 57284000
> /usr/lib/x86_64-linux-gnu/libheimbase.so.1.0.0
> 7fee92e84000-7fee93083000 ---p e000 08:02 57284000
> /usr/lib/x86_64-linux-gnu/libheimbase.so.1.0.0
> 7fee93083000-7fee93084000 r--p d000 08:02 57284000
> /usr/lib/x86_64-linux-gnu/libheimbase.so.1.0.0
> 7fee93084000-7fee93085000 rw-p e000 08:02 57284000
> /usr/lib/x86_64-linux-gnu/libheimbase.so.1.0.0
> 7fee93085000-7fee930ac000 r-xp  08:02 57284002
> /usr/lib/x86_64-linux-gnu/li

Re: [Pharo-dev] Can Realm (DB) and Pharo play together (or can we have a Pharo Realm Object Server to ROS) ?

[Denis Kudriashov]

Hi Cedrick.

Look at Voyage https://github.com/pharo-nosql/voyage. Maybe Realm can be
easily supported as another backend.

2017-09-10 12:14 GMT+02:00 Cédrick Béler :

> Hello all,
>
> I’ve spent some time in the summer in what I call my quest to the ultimate
> and easy and fun architecture to prototype some personal administration
> apps and have fun :-)
> I’ll share some experience and wonder if there are alternative in Pharo.
>
> I want app that are mobile firsts, then manageable with a computer (for
> more complex administrative tasks).
> I want them reactive (I especially like reactive data driven application
> like meteor.js), ubiquitous around my devices and not always connected
> (offline-first - this is very important if not the first objective).
>
> Ok, so I was lurking around looking for server and mobile distributed
> databases and I finally found Realm (https://realm.io/products/
> realm-mobile-platform/) which is a cool architecture plenty of promises,
> well documented, lots of tutorials... The architecture is composed of 2
> products:
> - Realm DB [1] that runs on mobile device - multiplatform - fully
> open-source - performant - an object DB with some limitation though
> - Realm Object Server (ROS) [2] - provide two-way data sync simple and
> easy - BUT proprietary even if free for developers … the entry point for
> serious developments (in particular access programmatically to the server)
> is very expensive ! 1500$mo !
>
> The developer edition with is free is already quite outstanding to me.
> Looks at this demo page on GitHub [3] !
>
> But… without any control to the ROS, I find ROS quite limited finally. I
> may then use the DB part, ROS free for what really need sync reactivity
> between devices or between group of people (like a black board), but store
> all less transient information to WhateverNoSQLDB probably in REST.
>
> Anyway I want to share that with you because it rings a smalltalk bell in
> my head… it’s about object data, live feeling, and I want to use Pharo on
> the server :)
>
> Maybe some people here have thought of an alternative ROS in Pharo or
> Gemstone ? Any ideas or remarks ?
> I was aware of sebastian Flow living full-stack framework attempt but
> don’t know more.
>
> TIA
> Cédrick
>
> NB: Pharo looks more and more great ! Congratulations guys for you job ! I
> hope ESUG was nice.
> I’ve just tried Telepharo on Pharo 6 (64 bit). Really great work too... It
> works like a charm, out of the box on low cost dedicated ubuntu servers [4]
> => 10€mo
> Pharo 64 tinyBenchmarks is 2,75 times slower than on my Mac mini Core i5
> 2,5GHz from 2012 with SSD (I guess it’s not that bad and usable for
> personal applications servers). I think it’ about 3 times faster than on a
> raspberry Pi.
> Mac mini (32 bit version):  '1329870129 bytecodes/sec; 108576799 sends/sec’
> Dedibox Low Cost server (64 bit version)’  '595695171 bytecodes/sec;
> 39441333 sends/sec'
>
> NB2: to download/install Pharo from command line, on the web site
> instructions, it seems it lacks the trailing slash. I had to add it.
>
> curl get.pharo.org/64*/* | bash
>
>
> [1] https://realm.io/products/realm-mobile-database/
> [2] https://realm.io/products/realm-mobile-platform/
> [3] https://github.com/realm-demos
> [4] https://www.online.net/fr/serveur-dedie/dedibox-sc
>
>
>

Re: [Pharo-dev] Iceberg causes 64 bit VM core dump on Ubuntu

[stephan]

On 11-09-17 11:38, Alistair Grant wrote:
>> Stephan
>
> Thanks for taking a look at this.
>
> I realised that this was a bad example after I posted it.  This script
> also demonstrates the problem:

But how can it work if you are trying to use file attributes that you 
can not access?


Your new script does not write a core dump, but the console says

*** Error in `./lib/pharo/5.0-201708312323/pharo': malloc(): memory 
corruption: 0x7fee9d0acfa0 ***

=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7fee9c4ac7e5]
/lib/x86_64-linux-gnu/libc.so.6(+0x8213e)[0x7fee9c4b713e]
/lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x54)[0x7fee9c4b9184]
./lib/pharo/5.0-201708312323/pharo[0x4c2510]
[0x1c01318]
=== Memory map: 
0040-0053b000 r-xp  08:02 22679114 
/home/stephan/Desktop/testpharo/pharo-linux-x86_64threaded-201708312323-caa8241/lib/pharo/5.0-201708312323/pharo
0073b000-0073c000 r--p 0013b000 08:02 22679114 
/home/stephan/Desktop/testpharo/pharo-linux-x86_64threaded-201708312323-caa8241/lib/pharo/5.0-201708312323/pharo
0073c000-0074d000 rw-p 0013c000 08:02 22679114 
/home/stephan/Desktop/testpharo/pharo-linux-x86_64threaded-201708312323-caa8241/lib/pharo/5.0-201708312323/pharo

0074d000-00816000 rw-p  00:00 0
01af6000-01b71000 rw-p  00:00 0 [heap]
01b71000-01b72000 rwxp  00:00 0 [heap]
01b72000-01bd9000 rw-p  00:00 0 [heap]
01c0-01d5e000 rwxp  00:00 0
01d5e000-06f0 rw-p  00:00 0
7fee8c00-7fee8c021000 rw-p  00:00 0
7fee8c021000-7fee9000 ---p  00:00 0
7fee920fe000-7fee92114000 r-xp  08:02 37491026 
/lib/x86_64-linux-gnu/libgcc_s.so.1
7fee92114000-7fee92313000 ---p 00016000 08:02 37491026 
/lib/x86_64-linux-gnu/libgcc_s.so.1
7fee92313000-7fee92314000 rw-p 00015000 08:02 37491026 
/lib/x86_64-linux-gnu/libgcc_s.so.1
7fee92314000-7fee92319000 r-xp  08:02 37488133 
/lib/x86_64-linux-gnu/libnss_dns-2.23.so
7fee92319000-7fee92519000 ---p 5000 08:02 37488133 
/lib/x86_64-linux-gnu/libnss_dns-2.23.so
7fee92519000-7fee9251a000 r--p 5000 08:02 37488133 
/lib/x86_64-linux-gnu/libnss_dns-2.23.so
7fee9251a000-7fee9251b000 rw-p 6000 08:02 37488133 
/lib/x86_64-linux-gnu/libnss_dns-2.23.so
7fee9251b000-7fee9251d000 r-xp  08:02 37491093 
/lib/x86_64-linux-gnu/libnss_mdns4_minimal.so.2
7fee9251d000-7fee9271c000 ---p 2000 08:02 37491093 
/lib/x86_64-linux-gnu/libnss_mdns4_minimal.so.2
7fee9271c000-7fee9271d000 r--p 1000 08:02 37491093 
/lib/x86_64-linux-gnu/libnss_mdns4_minimal.so.2
7fee9271d000-7fee9271e000 rw-p 2000 08:02 37491093 
/lib/x86_64-linux-gnu/libnss_mdns4_minimal.so.2
7fee9271e000-7fee92727000 r-xp  08:02 37488139 
/lib/x86_64-linux-gnu/libcrypt-2.23.so
7fee92727000-7fee92926000 ---p 9000 08:02 37488139 
/lib/x86_64-linux-gnu/libcrypt-2.23.so
7fee92926000-7fee92927000 r--p 8000 08:02 37488139 
/lib/x86_64-linux-gnu/libcrypt-2.23.so
7fee92927000-7fee92928000 rw-p 9000 08:02 37488139 
/lib/x86_64-linux-gnu/libcrypt-2.23.so

7fee92928000-7fee92956000 rw-p  00:00 0
7fee92956000-7fee92a25000 r-xp  08:02 57287405 
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6
7fee92a25000-7fee92c25000 ---p 000cf000 08:02 57287405 
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6
7fee92c25000-7fee92c28000 r--p 000cf000 08:02 57287405 
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6
7fee92c28000-7fee92c2a000 rw-p 000d2000 08:02 57287405 
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6

7fee92c2a000-7fee92c2b000 rw-p  00:00 0
7fee92c2b000-7fee92c72000 r-xp  08:02 57285008 
/usr/lib/x86_64-linux-gnu/libhx509.so.5.0.0
7fee92c72000-7fee92e71000 ---p 00047000 08:02 57285008 
/usr/lib/x86_64-linux-gnu/libhx509.so.5.0.0
7fee92e71000-7fee92e73000 r--p 00046000 08:02 57285008 
/usr/lib/x86_64-linux-gnu/libhx509.so.5.0.0
7fee92e73000-7fee92e75000 rw-p 00048000 08:02 57285008 
/usr/lib/x86_64-linux-gnu/libhx509.so.5.0.0

7fee92e75000-7fee92e76000 rw-p  00:00 0
7fee92e76000-7fee92e84000 r-xp  08:02 57284000 
/usr/lib/x86_64-linux-gnu/libheimbase.so.1.0.0
7fee92e84000-7fee93083000 ---p e000 08:02 57284000 
/usr/lib/x86_64-linux-gnu/libheimbase.so.1.0.0
7fee93083000-7fee93084000 r--p d000 08:02 57284000 
/usr/lib/x86_64-linux-gnu/libheimbase.so.1.0.0
7fee93084000-7fee93085000 rw-p e000 08:02 57284000 
/usr/lib/x86_64-linux-gnu/libheimbase.so.1.0.0
7fee93085000-7fee930ac000 r-xp  08:02 57284002 
/usr/lib/x86_64-linux-gnu/libwind.so.0.0.0
7fee930ac000-7fee932ac000 ---p 00027000 08:02 57284002 
/usr/lib/x86_64-linux-gnu/libwind.so.0.0.0
7fee932ac000-7fee932ad000 r--p 00027000 08:02 57284002 
/usr/lib/x86_64-linux-gnu/libwind.so.0.0.0
7fee932ad000-7fee932ae000 rw-p 00028000 08:02 57284002 
/usr/lib/x86_64-linux-gnu/libwind.so.0.0.0
7fee932ae000-7fee932b5000 r-xp  08:02 57286661 
/usr/lib/x86_64-linux-gnu/libffi.so.6.0.4
7fee932b5000-7fee934b4000 ---p 7000 08:02 57286661 
/usr/lib/x86_64-linux

Re: [Pharo-dev] Can Realm (DB) and Pharo play together (or can we have a Pharo Realm Object Server to ROS) ?

[stephan]

On 11-09-17 11:37, Cédrick Béler wrote:
I do a lot of iOS development.  I've looked at Realm.  I don't trust 
it.  I do like Sqlite.  


https://danluu.com/file-consistency/

Re: [Pharo-dev] argh, tests are failing!

[Pavel Krivanek]

2017-09-11 12:07 GMT+02:00 Guillermo Polito :

>
>
> On Sun, Sep 10, 2017 at 7:16 PM, Torsten Bergmann  wrote:
>
>> Hi,
>>
>> to explain:
>>
>> we have lots of uncategorized methods and non commented classes. For some
>> time we had to accept this ugly situation that old and legacy code. For
>> Pharo 4 and 5
>> I invested a lot of time to clean this up right before the release date.
>> But with 6.0 such a round was not done and in 6.0 and 6.1 it looks like a
>> mess again.
>>
>> Why? Because we introduced new features and code and never defined a
>> certain level of quality for code we include.  But our initial goal with
>> Pharo was (and
>> hopefully still is) to cleanup things up and do better than before.
>>
>> So we should not forget about quality and so I spend some time last on
>> this again - now for Pharo 7. For instance #setUp and #tearDown in SUnit
>> should be
>> in "running" as it was defined for TestCase subclasses. Also #hash and #=
>> should be in "comparing" protocol. Also the goal is coming back to an image
>> where
>> all methods are categorized and where all classes have a comment.
>>
>> But for me it absolutely makes no sense to reinvest the time over and
>> over into the same cleanups while others can easily make a mess again.
>>
>> So we should RAISE THE QUALITY BAR to ensure that we keep with such a
>> quality level. Especially as see each build to be a release and the real
>> release once
>> a year often is more or less a snapshot.
>>
>> So I also wrote a new test called "ProperMethodCategorizationTest" and
>> while cleaning up #hash it was green. So ProperMethodCategorizationTest
>> .testHashMethodNeedsToBeInComparingProtocol
>> showed no problem and I committed and have sent a Pull request. This
>> looked like any other new contribution.
>>
>
> Yes yes, I can't agree more. We need to add Lint rules running by default
> also.
>

I will try to prepare a small tool that will collect information about
health status of a build that will be stored as a STON file next to the
image (at least for the development versions). Then we can generate the
same information about incoming PRs and display changes. This way we will
be able to see effects of the PR like what new dependencies it added, what
new rules are failing and so on.
It should not reject then automatically but to be a support for the PR
review.

-- Pavel


>
>
>>
>> What I did not knew at this time was that Iceberg code is not in git
>> repository - but managed externally. So while I fixed the code in my image
>> with wrongly categorized hash
>> method in an Iceberg class (IceSemanticVersion) the system did not show
>> me that this change did not move to GitHub.
>
>
>> Now I know - but this has such bad side effect when we do changes and
>> these packages are in the image - but not managed with the pharo repository.
>>
>
> Yep, this should be fixed as soon as we have multiple
> subdirectories/subprojects in iceberg. As soon as that is supported we will
> probably move iceberg to a subtree structure as explained in here:
>
> https://www.slideshare.net/GuillePolito1/understanding-
> the-pharo-dev-process-79632181/1
> https://github.com/guillep/PharoIntegrationProcess/wiki/
> Analysis-of-sub-project-storage-alternatives
>
>
>
>>
>> Long story short: one can not fix this situation with a simple PR as
>> Iceberg code is not under the "pharo" repo umbrella.
>>
>> I already submitted a PR for Iceberg
>>
>>  https://github.com/pharo-vcs/iceberg/pull/458
>>
>> and Esteban included that already - but only in Iceberg. We now need to
>> include Iceberg.
>>
>> Several lessons learned from my side:
>>   - doing changes and having green tests in the image is not enough
>>   - also doing a commit and PR does not mean all of your changes are on
>> GitHub
>>   - it is not a good situation when a part of the image code is managed
>> with "pharo" repository and another part is managed externally - I see this
>> as a problem of
>> the new process we should discuss and address
>>   - we should nonetheless try to define tests to show the edges where we
>> can improve and cleanup (without a test it would not have been noticed that
>> while I did my best
>> to cleanup the current way of managing Iceberg prevented my fix to be
>> into the image in the first place)
>>
>
> While the test is an improvement over the current situation, I ask myself
> if this particular validation of the protocols shouldn't be a Renraku rule.
>
>
>>
>> I dont know what need to be done to include a new iceberg version or when
>> this will happen from Estebans side - but as soon as it is done this test
>> should be green again.
>>
>
> As Pavel said, the iceberg version that is included in the system is the
> one described in
>
> BaselineOfIDE >> loadIceberg
>
> Metacello new
> baseline: 'Iceberg';
> repository: 'github://pharo-vcs/iceberg:v0.5.7';
> load.
> (Smalltalk classNamed: #Iceberg) enableMetacelloIntegration: true.
>
> So updating that method with the new iceberg v

Re: [Pharo-dev] argh, tests are failing!

[Guillermo Polito]

On Mon, Sep 11, 2017 at 7:19 AM, Stephane Ducasse 
wrote:

> Hi torsten
>
> From a process I think that we decided that external packages should
> be managed like the following:
>
> - PR (from people) to change the code in Pharo
> + issues a PR to Iceberg.
>
> - then Iceberg team merge PR +
> issue a new PR for Pharo integration
>
> So I think that this is what you describe too?
>

Yes, that's what I described in ESUG too :)

https://www.slideshare.net/GuillePolito1/understanding-the-pharo-dev-process-79632181/34?src=clipshare

On the way back from ESUG we discussed with Esteban a way to support this
kind of scenarios cleanly and without needing too much of a refactor ;)


>
> Like that we do not have deadlock and can always have a stable version.
>
> Stef
>
>
>
>
>
>
> On Sun, Sep 10, 2017 at 7:16 PM, Torsten Bergmann  wrote:
> > Hi,
> >
> > to explain:
> >
> > we have lots of uncategorized methods and non commented classes. For
> some time we had to accept this ugly situation that old and legacy code.
> For Pharo 4 and 5
> > I invested a lot of time to clean this up right before the release date.
> But with 6.0 such a round was not done and in 6.0 and 6.1 it looks like a
> mess again.
> >
> > Why? Because we introduced new features and code and never defined a
> certain level of quality for code we include.  But our initial goal with
> Pharo was (and
> > hopefully still is) to cleanup things up and do better than before.
> >
> > So we should not forget about quality and so I spend some time last on
> this again - now for Pharo 7. For instance #setUp and #tearDown in SUnit
> should be
> > in "running" as it was defined for TestCase subclasses. Also #hash and
> #= should be in "comparing" protocol. Also the goal is coming back to an
> image where
> > all methods are categorized and where all classes have a comment.
> >
> > But for me it absolutely makes no sense to reinvest the time over and
> over into the same cleanups while others can easily make a mess again.
> >
> > So we should RAISE THE QUALITY BAR to ensure that we keep with such a
> quality level. Especially as see each build to be a release and the real
> release once
> > a year often is more or less a snapshot.
> >
> > So I also wrote a new test called "ProperMethodCategorizationTest" and
> while cleaning up #hash it was green. So ProperMethodCategorizationTest.
> testHashMethodNeedsToBeInComparingProtocol
> > showed no problem and I committed and have sent a Pull request. This
> looked like any other new contribution.
> >
> > What I did not knew at this time was that Iceberg code is not in git
> repository - but managed externally. So while I fixed the code in my image
> with wrongly categorized hash
> > method in an Iceberg class (IceSemanticVersion) the system did not show
> me that this change did not move to GitHub.
> >
> > Now I know - but this has such bad side effect when we do changes and
> these packages are in the image - but not managed with the pharo repository.
> >
> > Long story short: one can not fix this situation with a simple PR as
> Iceberg code is not under the "pharo" repo umbrella.
> >
> > I already submitted a PR for Iceberg
> >
> >  https://github.com/pharo-vcs/iceberg/pull/458
> >
> > and Esteban included that already - but only in Iceberg. We now need to
> include Iceberg.
> >
> > Several lessons learned from my side:
> >   - doing changes and having green tests in the image is not enough
> >   - also doing a commit and PR does not mean all of your changes are on
> GitHub
> >   - it is not a good situation when a part of the image code is managed
> with "pharo" repository and another part is managed externally - I see this
> as a problem of
> > the new process we should discuss and address
> >   - we should nonetheless try to define tests to show the edges where we
> can improve and cleanup (without a test it would not have been noticed that
> while I did my best
> > to cleanup the current way of managing Iceberg prevented my fix to
> be into the image in the first place)
> >
> > I dont know what need to be done to include a new iceberg version or
> when this will happen from Estebans side - but as soon as it is done this
> test should be green again.
> >
> > Thanks
> > T.
> >
> >
> > Gesendet: Sonntag, 10. September 2017 um 18:24 Uhr
> > Von: "Stephane Ducasse" 
> > An: "Pharo Development List" 
> > Betreff: Re: [Pharo-dev] argh, tests are failing!
> >
> > Yes we know but have no idea how to recategorise Iceberg protocols
> >
> > On Sun, Sep 10, 2017 at 1:03 PM, Pavel Krivanek <
> pavel.kriva...@gmail.com[mailto:pavel.kriva...@gmail.com]> wrote:
> >
> > Of course you are right, the Integrators should really take care on it.
> >
> > Before it were only common random failures but the main problem is with
> this PR:
> > https://github.com/pharo-project/pharo/pull/264[https:/
> /github.com/pharo-project/pharo/pull/264]
> >
> > The new test testHashMethodNeedsToBeInComparingProtocol fails on
> classIceSemanticVersi

Re: [Pharo-dev] argh, tests are failing!

[Guillermo Polito]

On Sun, Sep 10, 2017 at 7:16 PM, Torsten Bergmann  wrote:

> Hi,
>
> to explain:
>
> we have lots of uncategorized methods and non commented classes. For some
> time we had to accept this ugly situation that old and legacy code. For
> Pharo 4 and 5
> I invested a lot of time to clean this up right before the release date.
> But with 6.0 such a round was not done and in 6.0 and 6.1 it looks like a
> mess again.
>
> Why? Because we introduced new features and code and never defined a
> certain level of quality for code we include.  But our initial goal with
> Pharo was (and
> hopefully still is) to cleanup things up and do better than before.
>
> So we should not forget about quality and so I spend some time last on
> this again - now for Pharo 7. For instance #setUp and #tearDown in SUnit
> should be
> in "running" as it was defined for TestCase subclasses. Also #hash and #=
> should be in "comparing" protocol. Also the goal is coming back to an image
> where
> all methods are categorized and where all classes have a comment.
>
> But for me it absolutely makes no sense to reinvest the time over and over
> into the same cleanups while others can easily make a mess again.
>
> So we should RAISE THE QUALITY BAR to ensure that we keep with such a
> quality level. Especially as see each build to be a release and the real
> release once
> a year often is more or less a snapshot.
>
> So I also wrote a new test called "ProperMethodCategorizationTest" and
> while cleaning up #hash it was green. So ProperMethodCategorizationTest.
> testHashMethodNeedsToBeInComparingProtocol
> showed no problem and I committed and have sent a Pull request. This
> looked like any other new contribution.
>

Yes yes, I can't agree more. We need to add Lint rules running by default
also.


>
> What I did not knew at this time was that Iceberg code is not in git
> repository - but managed externally. So while I fixed the code in my image
> with wrongly categorized hash
> method in an Iceberg class (IceSemanticVersion) the system did not show me
> that this change did not move to GitHub.


> Now I know - but this has such bad side effect when we do changes and
> these packages are in the image - but not managed with the pharo repository.
>

Yep, this should be fixed as soon as we have multiple
subdirectories/subprojects in iceberg. As soon as that is supported we will
probably move iceberg to a subtree structure as explained in here:

https://www.slideshare.net/GuillePolito1/understanding-the-pharo-dev-process-79632181/1
https://github.com/guillep/PharoIntegrationProcess/wiki/Analysis-of-sub-project-storage-alternatives



>
> Long story short: one can not fix this situation with a simple PR as
> Iceberg code is not under the "pharo" repo umbrella.
>
> I already submitted a PR for Iceberg
>
>  https://github.com/pharo-vcs/iceberg/pull/458
>
> and Esteban included that already - but only in Iceberg. We now need to
> include Iceberg.
>
> Several lessons learned from my side:
>   - doing changes and having green tests in the image is not enough
>   - also doing a commit and PR does not mean all of your changes are on
> GitHub
>   - it is not a good situation when a part of the image code is managed
> with "pharo" repository and another part is managed externally - I see this
> as a problem of
> the new process we should discuss and address
>   - we should nonetheless try to define tests to show the edges where we
> can improve and cleanup (without a test it would not have been noticed that
> while I did my best
> to cleanup the current way of managing Iceberg prevented my fix to be
> into the image in the first place)
>

While the test is an improvement over the current situation, I ask myself
if this particular validation of the protocols shouldn't be a Renraku rule.


>
> I dont know what need to be done to include a new iceberg version or when
> this will happen from Estebans side - but as soon as it is done this test
> should be green again.
>

As Pavel said, the iceberg version that is included in the system is the
one described in

BaselineOfIDE >> loadIceberg

Metacello new
baseline: 'Iceberg';
repository: 'github://pharo-vcs/iceberg:v0.5.7';
load.
(Smalltalk classNamed: #Iceberg) enableMetacelloIntegration: true.

So updating that method with the new iceberg version and pushing that to
Pharo should be enough.

In any case, my mail was there just to raise the issue of the failing
tests. We should care about failing tests, and I'll cry out loud everytime
they are broken, just to make it explicit.


> Thanks
> T.
>
>
> Gesendet: Sonntag, 10. September 2017 um 18:24 Uhr
> Von: "Stephane Ducasse" 
> An: "Pharo Development List" 
> Betreff: Re: [Pharo-dev] argh, tests are failing!
>
> Yes we know but have no idea how to recategorise Iceberg protocols
>
> On Sun, Sep 10, 2017 at 1:03 PM, Pavel Krivanek  mailto:pavel.kriva...@gmail.com]> wrote:
>
> Of course you are right, the Integrators should really take care on it.
>
> Before it we

Re: [Pharo-dev] argh, tests are failing!

[Guillermo Polito]

Thanks Denis

On Mon, Sep 11, 2017 at 11:35 AM, Denis Kudriashov 
wrote:

> I will take a look into Mutex
>
> 2017-09-10 10:13 GMT+02:00 Guillermo Polito :
>
>> Hi all,
>>
>> Since a couple of builds we have consistently failing the following tests:
>>
>>
>>- GT.EventRecorder.Tests.Core.GTEventRecorderTest.testDeliverNow2
>>
>> 
>>- GT.EventRecorder.Tests.Core.GTEventRecorderTest.testNotDeliv
>>eredDataShouldBeResent
>>
>> 
>>- Kernel.Tests.Processes.MutexTest.testFailedCriticalSectionSh
>>ouldUnblockWaitingOne
>>
>> 
>>- ReleaseTests.Categorization.ProperMethodCategorizationTest.t
>>estHashMethodNeedsToBeInComparingProtocol
>>
>> 
>>- ReleaseTests.Categorization.ProperMethodCategorizationTest.t
>>estHashMethodNeedsToBeInComparingProtocol
>>
>> 
>>- ReleaseTests.Categorization.ProperMethodCategorizationTest.t
>>estHashMethodNeedsToBeInComparingProtocol
>>
>> 
>>- ReleaseTests.Categorization.ProperMethodCategorizationTest.t
>>estHashMethodNeedsToBeInComparingProtocol
>>
>> 
>>- ReleaseTests.Categorization.ProperMethodCategorizationTest.t
>>estHashMethodNeedsToBeInComparingProtocol
>>
>> 
>>- ReleaseTests.Categorization.ProperMethodCategorizationTest.t
>>estHashMethodNeedsToBeInComparingProtocol
>>
>> 
>>- ReleaseTests.Categorization.ProperMethodCategorizationTest.t
>>estHashMethodNeedsToBeInComparingProtocol
>>
>> 
>>
>>
>>
>> Green builds are the only hard metric to say if the build is healthy or
>> not.
>>
>> - We should not integrate anything until the build is green again...
>>
>> Also, we spent with Pablo a lot of time to have a green build in all
>> platforms...  I'd like to spend my time in other fun stuff than the CI :/
>>
>> --
>>
>>
>>
>> Guille Polito
>>
>>
>> Research Engineer
>>
>> French National Center for Scientific Research - *http://www.cnrs.fr*
>> 
>>
>>
>>
>> *Web:* *http://guillep.github.io* 
>>
>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>>
>
>


-- 



Guille Polito


Research Engineer

French National Center for Scientific Research - *http://www.cnrs.fr*




*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Can Realm (DB) and Pharo play together (or can we have a Pharo Realm Object Server to ROS) ?

[Serge Stinckwich]

Hi Cedrick,
If you want to develop mobile app, you should discuss with Noury and have a
look to Pharo/JS:
https://pharojs.github.io/

​Can you move such discussions on pharo-users mailing-list and not
pharo-dev ?
Thank you.​


On Sun, Sep 10, 2017 at 12:14 PM, Cédrick Béler  wrote:

> Hello all,
>
> I’ve spent some time in the summer in what I call my quest to the ultimate
> and easy and fun architecture to prototype some personal administration
> apps and have fun :-)
> I’ll share some experience and wonder if there are alternative in Pharo.
>
> I want app that are mobile firsts, then manageable with a computer (for
> more complex administrative tasks).
> I want them reactive (I especially like reactive data driven application
> like meteor.js), ubiquitous around my devices and not always connected
> (offline-first - this is very important if not the first objective).
>
> Ok, so I was lurking around looking for server and mobile distributed
> databases and I finally found Realm (https://realm.io/products/
> realm-mobile-platform/) which is a cool architecture plenty of promises,
> well documented, lots of tutorials... The architecture is composed of 2
> products:
> - Realm DB [1] that runs on mobile device - multiplatform - fully
> open-source - performant - an object DB with some limitation though
> - Realm Object Server (ROS) [2] - provide two-way data sync simple and
> easy - BUT proprietary even if free for developers … the entry point for
> serious developments (in particular access programmatically to the server)
> is very expensive ! 1500$mo !
>
> The developer edition with is free is already quite outstanding to me.
> Looks at this demo page on GitHub [3] !
>
> But… without any control to the ROS, I find ROS quite limited finally. I
> may then use the DB part, ROS free for what really need sync reactivity
> between devices or between group of people (like a black board), but store
> all less transient information to WhateverNoSQLDB probably in REST.
>
> Anyway I want to share that with you because it rings a smalltalk bell in
> my head… it’s about object data, live feeling, and I want to use Pharo on
> the server :)
>
> Maybe some people here have thought of an alternative ROS in Pharo or
> Gemstone ? Any ideas or remarks ?
> I was aware of sebastian Flow living full-stack framework attempt but
> don’t know more.
>
> TIA
> Cédrick
>
> NB: Pharo looks more and more great ! Congratulations guys for you job ! I
> hope ESUG was nice.
> I’ve just tried Telepharo on Pharo 6 (64 bit). Really great work too... It
> works like a charm, out of the box on low cost dedicated ubuntu servers [4]
> => 10€mo
> Pharo 64 tinyBenchmarks is 2,75 times slower than on my Mac mini Core i5
> 2,5GHz from 2012 with SSD (I guess it’s not that bad and usable for
> personal applications servers). I think it’ about 3 times faster than on a
> raspberry Pi.
> Mac mini (32 bit version):  '1329870129 bytecodes/sec; 108576799 sends/sec’
> Dedibox Low Cost server (64 bit version)’  '595695171 bytecodes/sec;
> 39441333 sends/sec'
>
> NB2: to download/install Pharo from command line, on the web site
> instructions, it seems it lacks the trailing slash. I had to add it.
>
> curl get.pharo.org/64*/* | bash
>
>
> [1] https://realm.io/products/realm-mobile-database/
> [2] https://realm.io/products/realm-mobile-platform/
> [3] https://github.com/realm-demos
> [4] https://www.online.net/fr/serveur-dedie/dedibox-sc
>
>
>



-- 
Serge Stinckwich
UCN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/

Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])

[Denis Kudriashov]

Anybody else?

2017-08-31 10:29 GMT+02:00 Pavel Krivanek :

>
>
> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov :
>
>> Hi.
>>
>> We now have very generic message names:
>> - pin
>> - unpin
>> - setPinned:
>> - isPinned
>>
>> Problem that they collide with possible domain related names.
>> For example I implemented pinning of tabs in Calypso and I found that I
>> overrides #pin and #isPinned messages. Then I fix it with different names.
>> Probably menus also uses pin word but without overrides
>>
>> What you think about renaming pinning messages? Something like:
>> - pinMemory
>>
>
> I would use pinInMemory
>
> -- Pavel
>
>
>> - unpinMemory
>> - isMemoryPinned
>> - setPinnedMemory:
>> - pinMemoryDuring: (if we will introduce it)
>>
>> I think it is easy to do now because not much code uses pinning
>>
>
>

Re: [Pharo-dev] argh, tests are failing!

[Guillermo Polito]

Hi Juraj,

think that it may really depend on the machine and the state of the system.
Slower slave machines could not really work with that timeout...

The question is how could we make such test more robust.

On Sun, Sep 10, 2017 at 6:41 PM, Juraj Kubelka 
wrote:

> Hi,
>
> I have checked the EventRecorderTests and it works on my computer. The
> only reason that it might not work on other cases is that there an assert
> for 'semaphore waitTimeoutMSecs: 200’. I can put higher timeout if
> necessary. The timeout 200 has worked for couple of years, right?. There
> might be another issue.
>
> Cheers,
> Juraj
>
> El 10-09-2017, a las 10:13, Guillermo Polito 
> escribió:
>
> Hi all,
>
> Since a couple of builds we have consistently failing the following tests:
>
>
>- GT.EventRecorder.Tests.Core.GTEventRecorderTest.testDeliverNow2
>
> 
>- GT.EventRecorder.Tests.Core.GTEventRecorderTest.
>testNotDeliveredDataShouldBeResent
>
> 
>- Kernel.Tests.Processes.MutexTest.testFailedCriticalSectionShoul
>dUnblockWaitingOne
>
> 
>- ReleaseTests.Categorization.ProperMethodCategorizationTest.
>testHashMethodNeedsToBeInComparingProtocol
>
> 
>- ReleaseTests.Categorization.ProperMethodCategorizationTest.
>testHashMethodNeedsToBeInComparingProtocol
>
> 
>- ReleaseTests.Categorization.ProperMethodCategorizationTest.
>testHashMethodNeedsToBeInComparingProtocol
>
> 
>- ReleaseTests.Categorization.ProperMethodCategorizationTest.
>testHashMethodNeedsToBeInComparingProtocol
>
> 
>- ReleaseTests.Categorization.ProperMethodCategorizationTest.
>testHashMethodNeedsToBeInComparingProtocol
>
> 
>- ReleaseTests.Categorization.ProperMethodCategorizationTest.
>testHashMethodNeedsToBeInComparingProtocol
>
> 
>- ReleaseTests.Categorization.ProperMethodCategorizationTest.
>testHashMethodNeedsToBeInComparingProtocol
>
> 
>
>
>
> Green builds are the only hard metric to say if the build is healthy or
> not.
>
> - We should not integrate anything until the build is green again...
>
> Also, we spent with Pablo a lot of time to have a green build in all
> platforms...  I'd like to spend my time in other fun stuff than the CI :/
>
> --
>
> Guille Polito
>
> Research Engineer
> French National Center for Scientific Research - *http://www.cnrs.fr*
> 
>
>
> *Web:* *http://guillep.github.io* 
> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>
>
>


-- 



Guille Polito


Research Engineer

French National Center for Scientific Research - *http://www.cnrs.fr*




*W

Re: [Pharo-dev] poor state of fuel

[Norbert Hartl]

> Am 11.09.2017 um 09:35 schrieb H. Hirzel :
> 
>> On 9/10/17, Norbert Hartl  wrote:
>> Max,
>> 
>> Just an update. Martin commited a new package that solves the
>> encoding/decoding of SmallInteger and Character. Together with the patch
>> from nicolas my dumps work again
>> 
>> Norbert
> 
> You mean you managed to export Fuel objects in Pharo 4 and import them
> in Pharo 6.1?
> 
No, written in 6.1 64 bit and read in 6.1 bit 64 bit.

Norbert
> --Hannes
> 
> 
>>> Am 29.08.2017 um 21:42 schrieb Max Leske :
>>> 
>>> Thanks Tim.
>>> 
>>> Norbert, I just saw that I have already created an issue for the 64-bit
>>> problems. I don’t know whether tackling that will help you though. In any
>>> case, I’ll see that we try to work on those problems.
>>> 
>>> I can’t give you an exact timeline because I will be on holiday but I
>>> guess I can make an integration by around mid September.
>>> 
>>> Cheers,
>>> Max
>>> 
>>> 
>>> 
 On 29 August 2017 at 16:09:06, Tim Mackinnon (tim@testit.works) wrote:
 
 As a small data point, a fuel file written out on AWS Lambda Linux (not
 sure what version - I think it's an ubuntu, but they don't really say),
 is readable on OS X 64bit .
 
 So it seems like you must have found something unusual.
 
 Tim
 
 Sent from my iPhone
 
> On 29 Aug 2017, at 11:13, Max Leske  wrote:
> 
> Hi Norbert,
> 
> We still maintain Fuel.
> 
> I was not aware of the problem you describe. Could you open an issue on
> github (https://github.com/theseion/Fuel/issues) with a detailed
> explanation and, if possible, steps to reproduce the problem?
> 
> Cheers,
> Max
> 
>> On 29 August 2017 at 11:04:34, Norbert Hartl (norb...@hartl.name)
>> wrote:
>> 
>> I'm migrating most of my projects to pharo 6.1 at the moment. I come
>> from pharo 4, I skipped pharo 5. I use 64 bit which removes a lot of
>> stuff that does not need to be installed and makes deployment better.
>> That really feels much better.
>> 
>> I use jenkins and there if a test fails a fuel dump is written to disk.
>> The jenkins server is ubuntu linux with the vm of the opensuse build.
>> My laptop has Mac OS and cannot read back those fuel dumps. I use the
>> same image version on jenkins and my laptop. Both are 64bit.
>> 
>> I asked that on discord and there was a mentioning that not only the 64
>> bit fuel has problems. So I wanted to ask what is the state of fuel
>> right now. I consider fuel one of the core technologies in pharo and it
>> is sad if it just stops working.
>> 
>> Any feedback is highly appreciated,
>> 
>> Norbert
>> 
>> 

Re: [Pharo-dev] Iceberg causes 64 bit VM core dump on Ubuntu

[Alistair Grant]

Hi Stef,

On Mon, Sep 11, 2017 at 11:03:58AM +0200, stephan wrote:
> On 10-09-17 11:23, Alistair Grant wrote:
> >Iceberg enableMetacelloIntegration: true.
> >Metacello new
> > repository: 'github://akgrant43/FileAttributes/src';
> > baseline: 'FileAttributes';
> > load.
> 
> Pharo-7.0.0-alpha.build.110.sha.5827735.arch.64bit
> pharo-linux-x86_64threaded-201708312323-caa8241
> 
> Ubuntu 16.04LTS
> 
> When loading: PrimitiveFailed: primitive #primFileMasks in
> FileAttributesPluginPrims failed
> 
> Stephan

Thanks for taking a look at this.

I realised that this was a bad example after I posted it.  This script
also demonstrates the problem:


| pharoRepository |

Iceberg enableMetacelloIntegration: true.
Metacello new
repository: 'github://akgrant43/pharo-akgosprocess/mc';
baseline: 'AKGOSProcess';
load.
pharoRepository := IceRepository registry detect: [ :each | each name = 
'pharo-akgosprocess' ].
pharoRepository pull.


Less manual steps :-)


Thanks again,
Alistair

Re: [Pharo-dev] Can Realm (DB) and Pharo play together (or can we have a Pharo Realm Object Server to ROS) ?

[Cédrick Béler]

Hi Todd, 

> I do a lot of iOS development.  I've looked at Realm.  I don't trust it.  I 
> do like Sqlite.  I have written the following frameworks for iOS.
> 
> https://github.com/tblanchard/objectivefmdb 
> 
> 
> I use it constantly on iOS development.  I would like to port it to Pharo, 
> possibly with GLORP front end.
> 
> I have an equivalent library written in PHP (I like PHP for server work) that 
> works against a PostgreSQL database.
> 
> I use this a lot to field iOS apps with server back ends very quickly.  I'm 
> happy to share it all.

Thanks for sharing. I definitely will have a look soon.

> 
> But I think trying to get Realm, a proprietary data store to work well with 
> Pharo something of a waste of time due to the proprietary nature of it.

Just to be sure, If I understand well, the realm data store (on mobiles 
devices) is fully open source (Apache 2.0). I think it was not the case at 
start in 2014 but it is now. They are seen as an alternative to SQLite. 
https://github.com/realm  

This is the other component of the architecture that is closed source (the 
realm object server).

> 
> I am happy to help you out though - I've written a LOT of persistence active 
> record type things and am pretty dang handy with GLORP as well.
> 
> Drop me a note if you want to collaborate.

Thanks for the proposition, 

See you soon

Cédrick


> 
> -Todd Blanchard
> tblanch...@mac.com 
> 
> 
>> On Sep 10, 2017, at 3:14 AM, Cédrick Béler > > wrote:
>> 
>> Hello all,
>> 
>> I’ve spent some time in the summer in what I call my quest to the ultimate 
>> and easy and fun architecture to prototype some personal administration apps 
>> and have fun :-)
>> I’ll share some experience and wonder if there are alternative in Pharo.
>> 
>> I want app that are mobile firsts, then manageable with a computer (for more 
>> complex administrative tasks).
>> I want them reactive (I especially like reactive data driven application 
>> like meteor.js), ubiquitous around my devices and not always connected 
>> (offline-first - this is very important if not the first objective).
>> 
>> Ok, so I was lurking around looking for server and mobile distributed 
>> databases and I finally found Realm 
>> (https://realm.io/products/realm-mobile-platform/ 
>> ) which is a cool 
>> architecture plenty of promises, well documented, lots of tutorials... The 
>> architecture is composed of 2 products: 
>> - Realm DB [1] that runs on mobile device - multiplatform - fully 
>> open-source - performant - an object DB with some limitation though
>> - Realm Object Server (ROS) [2] - provide two-way data sync simple and easy 
>> - BUT proprietary even if free for developers … the entry point for serious 
>> developments (in particular access programmatically to the server) is very 
>> expensive ! 1500$mo !
>> 
>> The developer edition with is free is already quite outstanding to me. Looks 
>> at this demo page on GitHub [3] ! 
>> 
>> But… without any control to the ROS, I find ROS quite limited finally. I may 
>> then use the DB part, ROS free for what really need sync reactivity between 
>> devices or between group of people (like a black board), but store all less 
>> transient information to WhateverNoSQLDB probably in REST.  
>> 
>> Anyway I want to share that with you because it rings a smalltalk bell in my 
>> head… it’s about object data, live feeling, and I want to use Pharo on the 
>> server :) 
>> 
>> Maybe some people here have thought of an alternative ROS in Pharo or 
>> Gemstone ? Any ideas or remarks ?
>> I was aware of sebastian Flow living full-stack framework attempt but don’t 
>> know more.
>> 
>> TIA
>> Cédrick
>> 
>> NB: Pharo looks more and more great ! Congratulations guys for you job ! I 
>> hope ESUG was nice. 
>> I’ve just tried Telepharo on Pharo 6 (64 bit). Really great work too... It 
>> works like a charm, out of the box on low cost dedicated ubuntu servers [4] 
>> => 10€mo
>> Pharo 64 tinyBenchmarks is 2,75 times slower than on my Mac mini Core i5 
>> 2,5GHz from 2012 with SSD (I guess it’s not that bad and usable for personal 
>> applications servers). I think it’ about 3 times faster than on a raspberry 
>> Pi.
>> Mac mini (32 bit version):  '1329870129 bytecodes/sec; 108576799 sends/sec’
>> Dedibox Low Cost server (64 bit version)’  '595695171 bytecodes/sec;   
>> 39441333 sends/sec'
>> 
>> NB2: to download/install Pharo from command line, on the web site 
>> instructions, it seems it lacks the trailing slash. I had to add it.
>> curl get.pharo.org/64 / | bash
>> 
>> [1] https://realm.io/products/realm-mobile-database/ 
>>  
>> [2] https://realm.io/products/realm-mobile-platform/ 
>>  
>> [3] https://github.com/real

Re: [Pharo-dev] argh, tests are failing!

[Denis Kudriashov]

I will take a look into Mutex

2017-09-10 10:13 GMT+02:00 Guillermo Polito :

> Hi all,
>
> Since a couple of builds we have consistently failing the following tests:
>
>
>- GT.EventRecorder.Tests.Core.GTEventRecorderTest.testDeliverNow2
>
> 
>- GT.EventRecorder.Tests.Core.GTEventRecorderTest.
>testNotDeliveredDataShouldBeResent
>
> 
>- Kernel.Tests.Processes.MutexTest.testFailedCriticalSectionShoul
>dUnblockWaitingOne
>
> 
>- ReleaseTests.Categorization.ProperMethodCategorizationTest.
>testHashMethodNeedsToBeInComparingProtocol
>
> 
>- ReleaseTests.Categorization.ProperMethodCategorizationTest.
>testHashMethodNeedsToBeInComparingProtocol
>
> 
>- ReleaseTests.Categorization.ProperMethodCategorizationTest.
>testHashMethodNeedsToBeInComparingProtocol
>
> 
>- ReleaseTests.Categorization.ProperMethodCategorizationTest.
>testHashMethodNeedsToBeInComparingProtocol
>
> 
>- ReleaseTests.Categorization.ProperMethodCategorizationTest.
>testHashMethodNeedsToBeInComparingProtocol
>
> 
>- ReleaseTests.Categorization.ProperMethodCategorizationTest.
>testHashMethodNeedsToBeInComparingProtocol
>
> 
>- ReleaseTests.Categorization.ProperMethodCategorizationTest.
>testHashMethodNeedsToBeInComparingProtocol
>
> 
>
>
>
> Green builds are the only hard metric to say if the build is healthy or
> not.
>
> - We should not integrate anything until the build is green again...
>
> Also, we spent with Pablo a lot of time to have a green build in all
> platforms...  I'd like to spend my time in other fun stuff than the CI :/
>
> --
>
>
>
> Guille Polito
>
>
> Research Engineer
>
> French National Center for Scientific Research - *http://www.cnrs.fr*
> 
>
>
>
> *Web:* *http://guillep.github.io* 
>
> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>

Re: [Pharo-dev] Directory structure on files.pharo.org

[Guillermo Polito]

On Mon, Sep 11, 2017 at 10:55 AM, stephan  wrote:

> This looks like it is missing directories.
> On the other hand, perhaps exposing the build steps as directories might
> not be the best idea, as that is unlikely to remain stable.
> http://files.pharo.org/image/70/


Yeh, also so far people will use mostly the latest minimal and full images.
All intermediate steps are stored just because we can.

But if you have some idea/proposal on how to enhance it, we could do it


>
>
> Stephan
>
>
>


-- 



Guille Polito


Research Engineer

French National Center for Scientific Research - *http://www.cnrs.fr*




*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Iceberg causes 64 bit VM core dump on Ubuntu

[stephan]

On 10-09-17 11:23, Alistair Grant wrote:

Iceberg enableMetacelloIntegration: true.
Metacello new
repository: 'github://akgrant43/FileAttributes/src';
baseline: 'FileAttributes';
load.


Pharo-7.0.0-alpha.build.110.sha.5827735.arch.64bit
pharo-linux-x86_64threaded-201708312323-caa8241

Ubuntu 16.04LTS

When loading: PrimitiveFailed: primitive #primFileMasks in 
FileAttributesPluginPrims failed


Stephan

THERE_BE_DRAGONS_HERE
PrimitiveFailed: primitive #primFileMasks in FileAttributesPluginPrims failed
11 September 2017 11:00:56.536121 am

VM: unix - x86_64 - linux-gnu - CoInterpreter VMMaker.oscog-eem.2266 uuid: 0501d71a-3185-4bdb-a99c-76a5fbbeee22 Sep  1 2017
StackToRegisterMappingCogit VMMaker.oscog-eem.2262 uuid: 8b531242-de02-48aa-b418-8d2dde0bec6c Sep  1 2017
VM: 201708312323 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Fri Sep 1 01:23:24 2017 +0200 $ Plugins: 201708312323 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $

Image: Pharo7.0alpha.build.110.sha.58277359523f18a81b762579c80043c898ab74f4 [Build information: alpha.build.110.sha.58277359523f18a81b762579c80043c898ab74f4]

FileAttributesPluginPrims(Object)>>primitiveFailed:
	Receiver: a FileAttributesPluginPrims
	Arguments and temporary variables: 
		selector: 	#primFileMasks
	Receiver's instance variables: 
a FileAttributesPluginPrims

FileAttributesPluginPrims(Object)>>primitiveFailed
	Receiver: a FileAttributesPluginPrims
	Arguments and temporary variables: 

	Receiver's instance variables: 
a FileAttributesPluginPrims

FileAttributesPluginPrims>>primFileMasks
	Receiver: a FileAttributesPluginPrims
	Arguments and temporary variables: 

	Receiver's instance variables: 
a FileAttributesPluginPrims

FileAttributesPluginPrims class>>reset
	Receiver: FileAttributesPluginPrims
	Arguments and temporary variables: 
		masks: 	nil
	Receiver's instance variables: 
		superclass: 	Object
		methodDict: 	a MethodDictionary(#cantAllocateMemory->FileAttributesPluginPrims>>...etc...
		format: 	0
		layout: 	a FixedLayout
		instanceVariables: 	nil
		organization: 	a ClassOrganization
		subclasses: 	{UnixFileAttributesPluginPrims. WindowsFileAttributesPluginPrims}
		name: 	#FileAttributesPluginPrims
		classPool: 	a Dictionary(#Encoder->a ZnUTF8Encoder #S_IFBLK->nil #S_IFCHR->nil #...etc...
		sharedPools: 	an OrderedCollection()
		environment: 	a SystemDictionary(lots of globals)
		category: 	#'FileSystem-Attributes'
		traitComposition: 	{}
		localSelectors: 	nil


FileAttributesPluginPrims class>>initialize
	Receiver: FileAttributesPluginPrims
	Arguments and temporary variables: 

	Receiver's instance variables: 
		superclass: 	Object
		methodDict: 	a MethodDictionary(#cantAllocateMemory->FileAttributesPluginPrims>>...etc...
		format: 	0
		layout: 	a FixedLayout
		instanceVariables: 	nil
		organization: 	a ClassOrganization
		subclasses: 	{UnixFileAttributesPluginPrims. WindowsFileAttributesPluginPrims}
		name: 	#FileAttributesPluginPrims
		classPool: 	a Dictionary(#Encoder->a ZnUTF8Encoder #S_IFBLK->nil #S_IFCHR->nil #...etc...
		sharedPools: 	an OrderedCollection()
		environment: 	a SystemDictionary(lots of globals)
		category: 	#'FileSystem-Attributes'
		traitComposition: 	{}
		localSelectors: 	nil


MCMethodDefinition>>postloadOver:
	Receiver: a MCMethodDefinition(FileAttributesPluginPrims>>#initialize)
	Arguments and temporary variables: 
		aDefinition: 	nil
	Receiver's instance variables: 
		classIsMeta: 	true
		source: 	'initialize

	Encoder := ZnCharacterEncoder newForEncoding: ''utf8''.
	...etc...
		category: 	#initialize
		selector: 	#initialize
		className: 	#FileAttributesPluginPrims
		timeStamp: 	'GitHub 8/9/2017 09:41:37'


[ :each | each postloadOver: (self obsoletionFor: each) ] in MCPackageLoader>>basicLoadDefinitions
	Receiver: a MCPackageLoader
	Arguments and temporary variables: 
		each: 	a MCMethodDefinition(FileAttributesPluginPrims>>#initialize)
	Receiver's instance variables: 
		requirements: 	#()
		unloadableDefinitions: 	a SortedCollection()
		obsoletions: 	a Dictionary()
		additions: 	an OrderedCollection(a MCMethodDefinition(FileSystemStore>>#attribut...etc...
		removals: 	an OrderedCollection()
		errorDefinitions: 	an OrderedCollection()
		provisions: 	a Set(#GLMUIThemeExtraIcons #OSWindowGenericRenderer #ZnMultiPartFo...etc...
		methodAdditions: 	an OrderedCollection(a MethodAddition a MethodAddition a Metho...etc...


[ :each | 
| newLabel |
"Special handling for first and last element"
(count = 0
	or: [ count + 1 = size
			or: [ (Time millisecondsSince: lastUpdate) >= msecs ] ])
	ifTrue: [ bar current: count.
		oldLabel = (newLabel := (labelBlock cull: each) ifNil: [ oldLabel ])
			ifFalse: [ bar label: newLabel.
oldLabel := newLabel ].
		lastUpdate := Time millisecondClockValue ].
aBlock value: each.
count := count + 1 ] in [ :bar | 
labelBlock := aStringOrBlock isString
	ifTrue: [ bar label: aStringOrBlock.
		[ :dummyItem | aStringOrBlock ] ]
	ifFalse: [ aStringOrBlock ].
self

[Pharo-dev] Directory structure on files.pharo.org

[stephan]

This looks like it is missing directories.
On the other hand, perhaps exposing the build steps as directories might 
not be the best idea, as that is unlikely to remain stable.

http://files.pharo.org/image/70/

Stephan

Re: [Pharo-dev] Fuel Materialization Error

[Max Leske]

Hi Sean,

That cluster has been renamed. Of course, that change should be reflected
in different version numbers. Unfortunately, the version number in 6.1 is
not correct (thanks for finding that; I've logged it here:
https://pharo.fogbugz.com/f/cases/20405/Fuel-Version-number-is-incorrect-for-the-code-present-in-Pharo-6
).

Now, even though you can load 1.9.4 into Pharo 6.1 that alone will not do
you any good, as MethodContext has been renamed to Context (which is
reflected in Fuel in the changed cluster name).
>From the top of my head you would need to:
1. load Fuel 1.9.4 (i.e., load the configuration and the
"(ConfigurationOfFuel project version; '1.9.4') load")
2. load your file with a migration in which you rename "MethodContext" to
"Context" (see
https://rmod.inria.fr/web/software/Fuel/Version1.9/Documentation/Migration)

I fear that you may run into other problems later on, but I hope this helps
at least a little.

Cheers,
Max



On 9 September 2017 at 04:28:35, Sean P. DeNigris (s...@clipperadams.com)
wrote:

I'm trying to serialize in Pharo 4.0 and materialize in Pharo 6.1. Although
both images claim Fuel 194, when materializing I'm getting: "KeyNotFound:
key #FLMethodContextCluster not found in SystemDictionary". Anyone know
what
the problem is?

Thanks!



-
Cheers,
Sean
-- 
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] poor state of fuel

[H. Hirzel]

On 9/10/17, Norbert Hartl  wrote:
> Max,
>
> Just an update. Martin commited a new package that solves the
> encoding/decoding of SmallInteger and Character. Together with the patch
> from nicolas my dumps work again
>
> Norbert

You mean you managed to export Fuel objects in Pharo 4 and import them
in Pharo 6.1?

--Hannes


>> Am 29.08.2017 um 21:42 schrieb Max Leske :
>>
>> Thanks Tim.
>>
>> Norbert, I just saw that I have already created an issue for the 64-bit
>> problems. I don’t know whether tackling that will help you though. In any
>> case, I’ll see that we try to work on those problems.
>>
>> I can’t give you an exact timeline because I will be on holiday but I
>> guess I can make an integration by around mid September.
>>
>> Cheers,
>> Max
>>
>>
>>
>>> On 29 August 2017 at 16:09:06, Tim Mackinnon (tim@testit.works) wrote:
>>>
>>> As a small data point, a fuel file written out on AWS Lambda Linux (not
>>> sure what version - I think it's an ubuntu, but they don't really say),
>>> is readable on OS X 64bit .
>>>
>>> So it seems like you must have found something unusual.
>>>
>>> Tim
>>>
>>> Sent from my iPhone
>>>
>>> On 29 Aug 2017, at 11:13, Max Leske  wrote:
>>>
 Hi Norbert,

 We still maintain Fuel.

 I was not aware of the problem you describe. Could you open an issue on
 github (https://github.com/theseion/Fuel/issues) with a detailed
 explanation and, if possible, steps to reproduce the problem?

 Cheers,
 Max

> On 29 August 2017 at 11:04:34, Norbert Hartl (norb...@hartl.name)
> wrote:
>
> I'm migrating most of my projects to pharo 6.1 at the moment. I come
> from pharo 4, I skipped pharo 5. I use 64 bit which removes a lot of
> stuff that does not need to be installed and makes deployment better.
> That really feels much better.
>
> I use jenkins and there if a test fails a fuel dump is written to disk.
> The jenkins server is ubuntu linux with the vm of the opensuse build.
> My laptop has Mac OS and cannot read back those fuel dumps. I use the
> same image version on jenkins and my laptop. Both are 64bit.
>
> I asked that on discord and there was a mentioning that not only the 64
> bit fuel has problems. So I wanted to ask what is the state of fuel
> right now. I consider fuel one of the core technologies in pharo and it
> is sad if it just stops working.
>
> Any feedback is highly appreciated,
>
> Norbert
>
>

Re: [Pharo-dev] Iceberg causes 64 bit VM core dump on Ubuntu

[Alistair Grant]

On Sun, Sep 10, 2017 at 08:38:56AM -0700, Eliot Miranda wrote:
> Alistair,
> 
> in both your crash dumps the crash is in malloc called from libgit right?.

I'm not sure, the backtrace just shows:

> > === Backtrace: =
> > /lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f76d34b37e5]
> > /lib/x86_64-linux-gnu/libc.so.6(+0x8213e)[0x7f76d34be13e]
> > /lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x54)[0x7f76d34c0184]
> > /home/alistair/pharo7/vm64/pharo-vm/lib/pharo/5.0-201708271955/pharo[0x4c24d0]
> > [0x1c01318]


> Can you build a debug vm and run under gdb and try and narrow down?

I tried building a debug vm but it didn't build libgit2 or libssh2.
I've never become familiar with the Make system and have only used gdb
about 3 times in my entire life and none of those were in the last 15
years, so I was hoping to avoid this. :-)

Anyway, I'll start trying to build a debug vm and see what I can find -
but it will be slow (limited time as well as lack of experience).

Cheers,
Alistair


> _,,,^..^,,,_ (phone)
> 
> > On Sep 10, 2017, at 5:46 AM, Alistair Grant  wrote:
> > 
> > Hi Esteban,
> > 
> > Another script which causes the crash:
> > 
> > | location pharoRepository origin upstream |
> > 
> > Iceberg enableMetacelloIntegration: true.
> > Metacello new
> >repository: 'github://akgrant43/pharo-akgosprocess/mc';
> >baseline: 'AKGOSProcess';
> >load.
> > pharoRepository := IceRepository registry detect: [ :each | each name = 
> > 'pharo-akgosprocess' ].
> > self halt.
> > pharoRepository pull.
> > 
> > 
> > I can step through to:
> > 
> > IceLibgitLocalRepository>>changedFilesBetween:and:
> > BlockClosure>>on:do:
> > IceCommitInfo>>changedPackagesToCommitInfo:
> > IceCommitInfo>>changedPackagesTo:
> > IceRepository>>pullFrom:
> > IceRepository>>pull
> > UndefinedObject>>DoIt
> > OpalCompiler>>evaluate
> > 
> > and on the next step (somewhere inside #withRepoDo:):
> > 
> > 
> > *** Error in 
> > `/home/alistair/pharo7/vm64/pharo-vm/lib/pharo/5.0-201708271955/pharo': 
> > malloc(): memory corruption: 0x7f76c96b0f40 ***
> > === Backtrace: =
> > /lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f76d34b37e5]
> > /lib/x86_64-linux-gnu/libc.so.6(+0x8213e)[0x7f76d34be13e]
> > /lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x54)[0x7f76d34c0184]
> > /home/alistair/pharo7/vm64/pharo-vm/lib/pharo/5.0-201708271955/pharo[0x4c24d0]
> > [0x1c01318]
> > === Memory map: 
> > 0040-0053b000 r-xp  00:29 370964 
> > /home/alistair/pharo7/vm64/pharo-vm/lib/pharo/5.0-201708271955/pharo
> > 0073b000-0073c000 r--p 0013b000 00:29 370964 
> > /home/alistair/pharo7/vm64/pharo-vm/lib/pharo/5.0-201708271955/pharo
> > 0073c000-0074d000 rw-p 0013c000 00:29 370964 
> > /home/alistair/pharo7/vm64/pharo-vm/lib/pharo/5.0-201708271955/pharo
> > 0074d000-00816000 rw-p  00:00 0 
> > 01b5-01bf4000 rw-p  00:00 0  
> > [heap]
> > 01c0-01d5e000 rwxp  00:00 0 
> > 01d5e000-07d8 rw-p  00:00 0 
> > ...

Re: [Pharo-dev] About Git support for windows

[H. Hirzel]

A note: Both variants below do not look nice because of the code
starting at the first column.


Some of the method body code lines start in the first column:

Morph class>>obtainArrowheadFor: aPrompt defaultValue: defaultPoint [
"Allow the user to supply a point to serve as an arrowhead size.
Answer nil if we fail to get a good point"
| result |
result := UIManager default request: aPrompt initialAnswer:
defaultPoint asString.
result isEmptyOrNil ifTrue: [^ nil].
^ [(Point readFrom: result readStream)] on: Error do: [:ex | nil].]

vs.

Morph class>>obtainArrowheadFor: aPrompt defaultValue: defaultPoint
[
"Allow the user to supply a point to serve as an arrowhead size.
Answer nil if we fail to get a good point"
| result |
result := UIManager default request: aPrompt initialAnswer:
defaultPoint asString.
result isEmptyOrNil ifTrue: [^ nil].
^ [(Point readFrom: result readStream)] on: Error do: [:ex | nil].
]







What about adding 4 leading spaces, easy to remove when parsing.


Morph class>>obtainArrowheadFor: aPrompt defaultValue: defaultPoint [
"Allow the user to supply a point to serve as an arrowhead size.
Answer nil if we fail to get a good point"
| result |
result := UIManager default request: aPrompt initialAnswer:
defaultPoint asString.
result isEmptyOrNil ifTrue: [^ nil].
^ [(Point readFrom: result readStream)] on: Error do: [:ex | nil].]

vs.

Morph class>>obtainArrowheadFor: aPrompt defaultValue: defaultPoint
[
"Allow the user to supply a point to serve as an arrowhead size.
Answer nil if we fail to get a good point"
| result |
result := UIManager default request: aPrompt initialAnswer:
defaultPoint asString.
result isEmptyOrNil ifTrue: [^ nil].
^ [(Point readFrom: result readStream)] on: Error do: [:ex | nil].
]

--Hannes

On 9/11/17, Stephane Ducasse  wrote:
> I read all the morph class and I like the ending ] at the beginning of
> the line (even if I know the rectangle concern for ifTrue beck
> formatting)
> Why because it identifies really well the end of a method.
>
> It is especially good for method finishing with conditionals.
>
> ]
>
> Esteban
>
> could you generate the same class with
>
> MethodDeclaration
>  [
>  
>  ]
>
> I would like to browse it to see how the eye catch fast.
>
> because
>
> MethodDeclaration
>  [
>  
> ]
> is not that nice
>
> so may be
>
> MethodDeclaration [
>  
> ]
>
> is a good compromise (because end of method is more important to spot that
> beginning.
>
> Stef
>
>