[Pharo-dev] Bintray for Pharo7 images?

[Holger Freyther]

Hey,

I keep on clicking on the "bintray" badges to get to a recent Pharo7 image but 
after looking at the Jenkinsfile I don't see the script being invoked and given 
the timestamp of "201706" it seems no images were uploaded for a while? 
Should we remove the bintray badge or upload them again?

Would there be any objection to link to 
http://files.pharo.org/get-files/70/pharo.zip from the README.md to get the 
latest image/sources/changes?


cheers
holger

Re: [Pharo-dev] [Calypso] Toolbar and Statusbar Look - voting time

[Max Leske]

Right


On 13 September 2017 at 18:08:26, Torsten Bergmann (asta...@gmx.de) wrote:

Hi all,

as you know Denis Kudriashov does a fantastic job in implementing the new
Calypso system browser.
The plan is that at some point in time will be a replacement for Nautilus
in the standard image.
Even if not yet integrated one can already use it (either by loading from
catalog or github [1])

For me the more I use it (and get used to it) the more I like Calypso and I
guess others enjoy it too already.

But unfortunately there is a single but very prominently visible UI thing
that I dislike on the current look:

For the "Pharo3Theme" (light theme) the current implementation of Calypso
has a white toolbar in the
middle and a white status bar at the bottom. Technically Dennis sets the
colors of these morphs to
transparent to have this effect (see LEFT example of the attached
screenshot)


To me this lookes strange and unusual because
- usually (on Windows, GTK, Java Swing, Linux window managers) such areas
like a status bar follow the window color
and are displayed in gray when that is the default window theme color (see
[2], [3], [4])
- these white bars would better fit for the "Glamorous Whitespace" theme
(as this theme is already more white areas)

Also the current white bars do not make a pleasant contrast to the other
panes of Calypso:
- there is not really a visual distinction to the
package/class/protocol-tag/method panes and filters for the middle part
(toolbar)
- there is not really a visual distinction from the code pane for the
bottom part (statusbar)
- the divider line in the code pane just stops in a white area without
borders

To me this looks rather ugly and I would like Pharo to look more
professional and clean ;)

So I proposed a simple PR [5] today to change this and technically using
the window color of the theme - the result can be
seen on the right side of the attached screenshot and discussed with Denis
on Discord.

Denis on the other hand still likes the white approach on the left more
while I prefer the right one.

He wrote that he wants other people comment on this issue first to which I
agree and therefore I write this mail
to discuss it here on the dev-list and find out about what the majority in
the community prefers.

So it would be good if others could
- comment about their personal preference
- or just vote with "LEFT" (white/transparent) or "RIGHT" (window color) in
reply to this mail
- or make another proposal (which is only accepted with screenshot and PR
;)

Also please do not mix other UI discussions into this thread. Thanks in
advance!

Bye
T.

[1] https://github.com/dionisiydk/Calypso
[2]
http://cdn.osxdaily.com/wp-content/uploads/2011/08/show-status-bar-and-disk-space-lion.jpg
[3] http://i.stack.imgur.com/pgt5n.png
[4] http://python.zirael.org/gtk-statusbar1-1.png
[5] https://github.com/dionisiydk/Calypso/pull/91

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

[Eliot Miranda]

Hi Norbert,

> On Sep 13, 2017, at 3:18 PM, Norbert Hartl  wrote:
> 
> 
>> Am 14.09.2017 um 00:09 schrieb Eliot Miranda :
>> 
>> Hi Denis,
>> 
>> On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov  
>> wrote:
>>> Hi Eliot. 
>>> 
>>> I know and I only talk about new messages. I am not trying to rethink full 
>>> meta model of Smalltalk.
>>> By the way #class is very common message and it is handy to use short name. 
>>> But pinning messages will be used rarely in very specific applications. So 
>>> no much sense to preserve them in short version.  
>> 
>> Agreed.  So we have to decide whether to go with pinInMemory or pinObject, 
>> pinObject being suggested by Norbert because it matched isReadOnlyObject.  
>> Personally I like pinInMemory.  Norbert, do you feel strongly about 
>> pinObject et al?
>>  
> No I don't. It feels only good to me if there is a requirement not to 
> implement selectors that are likely to be used in user code. I'm ok with 
> pinInMemory although I asked myself where can it be pinned elsewhere if not 
> in memory. So the suffix in memory doesn't add anything but also moves the 
> selector out of user space. 

Well I think Denis' point is that pinInMemory removes ambiguity with pin for 
other uses and I agree.  So I for one am happy to change it to pinInMemory et 
al.
 
> 
> Norbert
> 
>>> 
>>> 2017-09-12 18:05 GMT+02:00 Eliot Miranda :
 Hi Denis,
 
 
> On Sep 12, 2017, at 2:39 AM, Denis Kudriashov  
> wrote:
> 
> I am really wonder guys. I thought you are not big funs of Object 
> protocol.
> Current pinning messages are a new set of very generic messages in the 
> Object.
 
 Yes, and that's because this is a fundamental property of all 
 non-immediate objects.  Do you object to the #class message?  Should it be 
 #classObject because it might conflict with #class used in an educational 
 or socioeconomic model?  All objects other than immediates can move.  
 Pinning stops that movement.  It applies generally.  So the protocol 
 belongs in Object.
 
 
> 
> About Norbert idea.
> - bePinnedObject is not bad convention. But I would prefer the memory 
> suffix because it reflects the low level behaviour.
> 
> 2017-09-11 14:16 GMT+02: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
 
>>> 
>> 
> 
>>> 
>> 
>> 
>> 
>> -- 
>> _,,,^..^,,,_
>> best, Eliot
> 

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

[David T. Lewis]

On Thu, Sep 14, 2017 at 12:18:34AM +0200, Norbert Hartl wrote:
> 
> > Am 14.09.2017 um 00:09 schrieb Eliot Miranda :
> > 
> > Hi Denis,
> > 
> > On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov  > > wrote:
> > Hi Eliot. 
> > 
> > I know and I only talk about new messages. I am not trying to rethink full 
> > meta model of Smalltalk.
> > By the way #class is very common message and it is handy to use short name. 
> > But pinning messages will be used rarely in very specific applications. So 
> > no much sense to preserve them in short version.  
> > 
> > Agreed.  So we have to decide whether to go with pinInMemory or pinObject, 
> > pinObject being suggested by Norbert because it matched isReadOnlyObject.  
> > Personally I like pinInMemory.  Norbert, do you feel strongly about 
> > pinObject et al?
> >  
> No I don't. It feels only good to me if there is a requirement not to 
> implement selectors that are likely to be used in user code. I'm ok with 
> pinInMemory although I asked myself where can it be pinned elsewhere if not 
> in memory. So the suffix in memory doesn't add anything but also moves the 
> selector out of user space. 
> 

+1

I also like pinInMemory because it is easy to read and it describes
exactly what the method does. It pins the object to some location in the
object memory. Once you stick a pin in it, the object stops moving around
in the object memory. Nice.

Dave

[Pharo-dev] Pharo 6.1 32bit/64bit on CentOS 7 with Iceberg

[Andrei Chis]

Hi,

Does anybody use Pharo 6.1 (32 or 64 bit) on CentOS 7?
I am getting randomly the following crash when trying to clone a repository
from github. While this might suggest some kind of of out memory error
there should be enough memory.

PrimitiveFailed: primitive #allocateExecutablePage in FFICallbackThunk
class failed
FFICallbackThunk class(Object)>>primitiveFailed:
FFICallbackThunk class(Object)>>primitiveFailed
FFICallbackThunk class>>allocateExecutablePage
[ ExecutablePages add: self allocateExecutablePage ] in FFICallbackThunk
class>>unusedBlockInExecutablePage in Block: [ ExecutablePages add: self
allocateExecutablePage...etc...
[ caught := true.
self wait.
blockValue := mutuallyExcludedBlock value ] in Semaphore>>critical: in
Block: [ caught := true
BlockClosure>>ensure:
Semaphore>>critical:
FFICallbackThunk class>>unusedBlockInExecutablePage
FFICallbackThunk class>>privateFinalizingNew
FFICallbackThunk class>>newCCall
CallbackForIA32(Callback)>>callbackEvaluator:
Callback class>>forCallbackEvaluator:
LGitTransportCertificateCheckCallback(FFICallback)>>signature:block:
LGitTransportCertificateCheckCallback class(FFICallback
class)>>signature:block:
LGitTransportCertificateCheckCallback class(LGitCallback class)>>on:
LGitRemoteCallbacks class>>newCertificateCheckCallback
LGitRemoteCallbacks class>>defaults
LGitRemoteCallbacks class>>withProvider:
LGitCloneOptions class>>withCredentialsProvider:
[ | repo cloneOptions |
repo := LGitRepository on: self location.
cloneOptions := LGitCloneOptions
withCredentialsProvider: IceCredentialsProvider default.
repo clone: url options: cloneOptions.
aBranchName ifNotNil: [ repo checkout: aBranchName ].
(LGitRemote of: repo named: 'origin')
lookup;
setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch:
in Block: [ | repo cloneOptions |...
[ self checkInitialized.
aBlock value ] in LGitGlobal class>>runSequence: in Block: [ self
checkInitialized
[ activeProcess psValueAt: index put: anObject.
aBlock value ] in LGitActionSequence(DynamicVariable)>>value:during: in
Block: [ activeProcess psValueAt: index put: anObject
BlockClosure>>ensure:
LGitActionSequence(DynamicVariable)>>value:during:
LGitActionSequence class(DynamicVariable class)>>value:during:
LGitGlobal class>>runSequence:
IceLibgitLocalRepository>>cloneRepositoryFrom:branch:
IceRepositoryCreator>>createRepository
[ (IceRepositoryCreator new
url: remoteUrl;
subdirectory: repoPath;
branchName: self projectVersion;
createRepository) register ] in
MCGitHubRepository>>getOrCreateIcebergRepository
in Block: [ (IceRepositoryCreator new...
OrderedCollection(Collection)>>detect:ifFound:ifNone:

Cheers,
Andrei

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

[Norbert Hartl]

> Am 14.09.2017 um 00:09 schrieb Eliot Miranda :
> 
> Hi Denis,
> 
> On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov  > wrote:
> Hi Eliot. 
> 
> I know and I only talk about new messages. I am not trying to rethink full 
> meta model of Smalltalk.
> By the way #class is very common message and it is handy to use short name. 
> But pinning messages will be used rarely in very specific applications. So no 
> much sense to preserve them in short version.  
> 
> Agreed.  So we have to decide whether to go with pinInMemory or pinObject, 
> pinObject being suggested by Norbert because it matched isReadOnlyObject.  
> Personally I like pinInMemory.  Norbert, do you feel strongly about pinObject 
> et al?
>  
No I don't. It feels only good to me if there is a requirement not to implement 
selectors that are likely to be used in user code. I'm ok with pinInMemory 
although I asked myself where can it be pinned elsewhere if not in memory. So 
the suffix in memory doesn't add anything but also moves the selector out of 
user space. 

Norbert

> 
> 2017-09-12 18:05 GMT+02:00 Eliot Miranda  >:
> Hi Denis,
> 
> 
> On Sep 12, 2017, at 2:39 AM, Denis Kudriashov  > wrote:
> 
>> I am really wonder guys. I thought you are not big funs of Object protocol.
>> Current pinning messages are a new set of very generic messages in the 
>> Object.
> 
> Yes, and that's because this is a fundamental property of all non-immediate 
> objects.  Do you object to the #class message?  Should it be #classObject 
> because it might conflict with #class used in an educational or socioeconomic 
> model?  All objects other than immediates can move.  Pinning stops that 
> movement.  It applies generally.  So the protocol belongs in Object.
> 
> 
>> 
>> About Norbert idea.
>> - bePinnedObject is not bad convention. But I would prefer the memory suffix 
>> because it reflects the low level behaviour.
>> 
>> 2017-09-11 14:16 GMT+02: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
>>> 
>>> 
>> 
>> 
> 
> 
> 
> 
> -- 
> _,,,^..^,,,_
> best, Eliot

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

[Eliot Miranda]

Hi Denis,

On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov 
wrote:

> Hi Eliot.
>
> I know and I only talk about new messages. I am not trying to rethink full
> meta model of Smalltalk.
> By the way #class is very common message and it is handy to use short
> name. But pinning messages will be used rarely in very specific
> applications. So no much sense to preserve them in short version.
>

Agreed.  So we have to decide whether to go with pinInMemory or pinObject,
pinObject being suggested by Norbert because it matched isReadOnlyObject.
Personally I like pinInMemory.  Norbert, do you feel strongly about
pinObject et al?


>
> 2017-09-12 18:05 GMT+02:00 Eliot Miranda :
>
>> Hi Denis,
>>
>>
>> On Sep 12, 2017, at 2:39 AM, Denis Kudriashov 
>> wrote:
>>
>> I am really wonder guys. I thought you are not big funs of Object
>> protocol.
>> Current pinning messages are a new set of very generic messages in the
>> Object.
>>
>>
>> Yes, and that's because this is a fundamental property of all
>> non-immediate objects.  Do you object to the #class message?  Should it be
>> #classObject because it might conflict with #class used in an educational
>> or socioeconomic model?  All objects other than immediates can move.
>> Pinning stops that movement.  It applies generally.  So the protocol
>> belongs in Object.
>>
>>
>>
>> About Norbert idea.
>> - bePinnedObject is not bad convention. But I would prefer the memory
>> suffix because it reflects the low level behaviour.
>>
>> 2017-09-11 14:16 GMT+02: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
>


>>>
>>>
>>
>


-- 
_,,,^..^,,,_
best, Eliot

Re: [Pharo-dev] [Calypso] Toolbar and Statusbar Look - voting time

[Esteban Lorenzano]

right.

> On 13 Sep 2017, at 19:01, Stephane Ducasse  wrote:
> 
> I agree Right is a lot better and I would love to get FastTable or
> related fixed so that we can see the filter input field at the end of
> the left pane.
> 
> On Wed, Sep 13, 2017 at 6:32 PM, Brad Selfridge  wrote:
>> "RIGHT" (window color)
>> 
>> 
>> --
>> Brad Selfridge
>> 913-269-2385
>> 
>> 
> 

Re: [Pharo-dev] Tricky Metaclass>>binding

[Denis Kudriashov]

Yes

13 сент. 2017 г. 18:59 пользователь "Stephane Ducasse" <
stepharo.s...@gmail.com> написал:

> I imagine that you imply keeping the cGlobalVariable binding for the
> real global variable.
>
> On Wed, Sep 13, 2017 at 4:52 PM, Denis Kudriashov 
> wrote:
> > So after discussion the solution would be:
> > - ClassBinding for instance side method literals and globals dictionary
> > (instead of GlobalVariable)
> > - MetaclassBinding for the last literal of class side methods. It will
> > include proper comment about where it is used and how, with description
> of
> > current trick
> >
> > 2017-09-13 16:45 GMT+02:00 Marcus Denker :
> >>
> >>
> >> > On 12 Sep 2017, at 17:33, Guillermo Polito  >
> >> > wrote:
> >> >
> >> > I don't know... I found the idea of having a Metaclass binding
> >> > strange...
> >> >
> >> > I mean,
> >> > - metaclasses are not stored in any name dictionary such as Smalltalk
> >> > - nobody references them directly in source code but by their direct
> >> > classes
> >> >
> >> > The metaclass binding is there just for one thing really: methods need
> >> > an association to know their class in case they have to do a super
> send. And
> >> > transitively this is a compiler problem also. But anybody else
> accesses
> >> > metaclasses' bindings.
> >> >
> >> yes, we need it just for the last literal.
> >>
> >> We added the “if there is a method, get the binding from there” we adde
> as
> >> else
> >> we would compiler every class side method with a new Association
> instance,
> >> which
> >> wastes lots of space.
> >>
> >> Marcus
> >
> >
>
>

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

[Todd Blanchard]

+1

> On Aug 31, 2017, at 1:29 AM, Pavel Krivanek  wrote:
> 
> I would use pinInMemory

Re: [Pharo-dev] [Calypso] Toolbar and Statusbar Look - voting time

[Sven Van Caekenberghe]

> On 13 Sep 2017, at 18:32, Brad Selfridge  wrote:
> 
> "RIGHT" (window color)

Yes, right seems better.

Re: [Pharo-dev] [Calypso] Toolbar and Statusbar Look - voting time

[Stephane Ducasse]

I agree Right is a lot better and I would love to get FastTable or
related fixed so that we can see the filter input field at the end of
the left pane.

On Wed, Sep 13, 2017 at 6:32 PM, Brad Selfridge  wrote:
> "RIGHT" (window color)
>
>
> --
> Brad Selfridge
> 913-269-2385
>
>

Re: [Pharo-dev] Tricky Metaclass>>binding

[Stephane Ducasse]

I imagine that you imply keeping the cGlobalVariable binding for the
real global variable.

On Wed, Sep 13, 2017 at 4:52 PM, Denis Kudriashov  wrote:
> So after discussion the solution would be:
> - ClassBinding for instance side method literals and globals dictionary
> (instead of GlobalVariable)
> - MetaclassBinding for the last literal of class side methods. It will
> include proper comment about where it is used and how, with description of
> current trick
>
> 2017-09-13 16:45 GMT+02:00 Marcus Denker :
>>
>>
>> > On 12 Sep 2017, at 17:33, Guillermo Polito 
>> > wrote:
>> >
>> > I don't know... I found the idea of having a Metaclass binding
>> > strange...
>> >
>> > I mean,
>> > - metaclasses are not stored in any name dictionary such as Smalltalk
>> > - nobody references them directly in source code but by their direct
>> > classes
>> >
>> > The metaclass binding is there just for one thing really: methods need
>> > an association to know their class in case they have to do a super send. 
>> > And
>> > transitively this is a compiler problem also. But anybody else accesses
>> > metaclasses' bindings.
>> >
>> yes, we need it just for the last literal.
>>
>> We added the “if there is a method, get the binding from there” we adde as
>> else
>> we would compiler every class side method with a new Association instance,
>> which
>> wastes lots of space.
>>
>> Marcus
>
>

Re: [Pharo-dev] [Calypso] Toolbar and Statusbar Look - voting time

[Brad Selfridge]

"RIGHT" (window color)


--
Brad Selfridge
913-269-2385

Re: [Pharo-dev] Tricky Metaclass>>binding

[Denis Kudriashov]

So after discussion the solution would be:
- ClassBinding for instance side method literals and globals dictionary
(instead of GlobalVariable)
- MetaclassBinding for the last literal of class side methods. It will
include proper comment about where it is used and how, with description of
current trick

2017-09-13 16:45 GMT+02:00 Marcus Denker :

>
> > On 12 Sep 2017, at 17:33, Guillermo Polito 
> wrote:
> >
> > I don't know... I found the idea of having a Metaclass binding strange...
> >
> > I mean,
> > - metaclasses are not stored in any name dictionary such as Smalltalk
> > - nobody references them directly in source code but by their direct
> classes
> >
> > The metaclass binding is there just for one thing really: methods need
> an association to know their class in case they have to do a super send.
> And transitively this is a compiler problem also. But anybody else accesses
> metaclasses' bindings.
> > ​
> yes, we need it just for the last literal.
>
> We added the “if there is a method, get the binding from there” we adde as
> else
> we would compiler every class side method with a new Association instance,
> which
> wastes lots of space.
>
> Marcus
>

Re: [Pharo-dev] Tricky Metaclass>>binding

[Marcus Denker]

> On 12 Sep 2017, at 17:33, Guillermo Polito  wrote:
> 
> I don't know... I found the idea of having a Metaclass binding strange...
> 
> I mean, 
> - metaclasses are not stored in any name dictionary such as Smalltalk
> - nobody references them directly in source code but by their direct classes
> 
> The metaclass binding is there just for one thing really: methods need an 
> association to know their class in case they have to do a super send. And 
> transitively this is a compiler problem also. But anybody else accesses 
> metaclasses' bindings.
> ​
yes, we need it just for the last literal.

We added the “if there is a method, get the binding from there” we adde as else
we would compiler every class side method with a new Association instance, which
wastes lots of space.

Marcus

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

[Ben Coman]

On Tue, Sep 12, 2017 at 11:23 PM, Peter Uhnák  wrote:

> Just a random idea, how about each time writing timestamps to
>> a different file name "timestamps.$HashOfClassSourceFile"
>> Then git would never complain of a conflict(??).
>>
>
> If I understand your proposal correctly, that would imo result in the
> following:
>
> accumulating endless list of timestamps.XXX files (there are no conflicts
> and thus no mechanism to get rid of them)
>

The Smalltalk code writing the class & timestamp files would take care of
removing old timestamp files, so linearly git would see one file added and
one removed, or after a merge, more than one timestamp file removed..


> still having conflict, because the #sourceHash is different (any two
> independent changes to a line will trigger conflict)
>

#sourceHash is only written to the timestamp file, so such a line is only
touched once when the timestamp file is created.


> plus added complexity and a lot more reading/processing CPU/disk required
>

yeah... :)

cheers -ben

Re: [Pharo-dev] Build #111

[Esteban Lorenzano]

hi,

for now, everything, at least 0.5.* series (but I want to port 0.6 too because 
of tonel and windows users)

Esteban

> On 13 Sep 2017, at 14:07, stephan  wrote:
> 
> What Iceberg changes will get ported to Pharo 6?
> 
> Stephan
> 
> 

Re: [Pharo-dev] Build #111

[stephan]

What Iceberg changes will get ported to Pharo 6?

Stephan

Re: [Pharo-dev] Tricky Metaclass>>binding

[Denis Kudriashov]

Yes.
In fact I just want avoid usage of general Association in that places.
So the question do we need two classes for instance and class side
bindings? Or single ClassBinding is enough? In that case class side binding
will have nil as a key (which would be the same for possible
ClassSideBinding)

2017-09-13 9:43 GMT+02:00 Stephane Ducasse :

> At the minimum having classBinding instead of GlobalBinding would be
> already a good step.
> Then since the metaclass and the class are a real couple could we not
> have an object shared by both (but it would cost one indirection).
>
> On Tue, Sep 12, 2017 at 5:33 PM, Guillermo Polito
>  wrote:
> > I don't know... I found the idea of having a Metaclass binding strange...
> >
> > I mean,
> > - metaclasses are not stored in any name dictionary such as Smalltalk
> > - nobody references them directly in source code but by their direct
> classes
> >
> > The metaclass binding is there just for one thing really: methods need an
> > association to know their class in case they have to do a super send. And
> > transitively this is a compiler problem also. But anybody else accesses
> > metaclasses' bindings.
>
>

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

[Stephane Ducasse]

Nice It should be added to the doc :)

On Tue, Sep 12, 2017 at 9:51 AM, Guillermo Polito  wrote:

> Two other things:
>
> - if you choose to change the priority of the delivery process to the same
> priority as the running test process (i.e., 40) you would still need to
> tell the scheduler to give some chance to run to the other one. You can do
> that by yielding
>
>  Processor yield
>
> - About timeouts: Denis implemented not so long ago an automatic timeout
> for tests. So if tests take more than a specified amount they are timed out
> and failed by default. Check
>
> TestCase >> defaultTimeLimit
> ^self class defaultTimeLimit
>
> TestCase class >> defaultTimeLimit
> ^DefaultTimeLimit ifNil: [DefaultTimeLimit := 1 minutes]
>
> So you may want to use that mechanism to timeout instead of hardcoding the
> timeouts of semaphores in each of the tests.
>
> Moreover, the mechanism created by Denis will automatically kill any
> processes created during a test run, to ensure you leave the system somehow
> "clean". So you may have that into account also.
>
> On Tue, Sep 12, 2017 at 9:46 AM, Guillermo Polito <
> guillermopol...@gmail.com> wrote:
>
>> But the thing is that those processes you are creating for delivery are
>> running in priority 30. This means that it may happen that they may not run
>> any time soon (even those 200ms) if there are processes scheduled with
>> higher priorities.
>>
>> So, the thing is that test is not a unit test at all. It depends a lot on
>> the running environment. Solutions for that:
>>  - you change the priority of the delivery process for test purposes
>>  - Or, for testing purposes you don't create a new process, you just
>> execute synchronously
>>
>> If you want really to test the fact that you are creating and running a
>> separate process, then you should also try to let explicit the processes
>> you created run. This means, if the active process that is running the
>> tests (usually priority 40) does not suspend itself, no processes of
>> priority 30 will be able to run. Ways to suspend the active process and let
>> lower priority ones run are:
>>  - calling suspend (Processor activeProcess suspend) but this is
>> dangerous because somebody should resume it afterwards from a separate
>> process
>>  - using a delay
>>  - some I/O like sockets or async files
>>
>> On Mon, Sep 11, 2017 at 7:40 PM, Juraj Kubelka 
>> wrote:
>>
>>> 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.testNotDeliv
eredDataShouldBeResent

 
- Kernel.Tests.Processes.MutexTest.testFailedCriticalSectionSh
ouldUnblockWaitingOne

 
- ReleaseTests.Categorization.ProperMethodCategorizationTest.t
estHashMethodNeedsToBeInComparingProtocol

 
>>

Re: [Pharo-dev] Tricky Metaclass>>binding

[Stephane Ducasse]

At the minimum having classBinding instead of GlobalBinding would be
already a good step.
Then since the metaclass and the class are a real couple could we not
have an object shared by both (but it would cost one indirection).

On Tue, Sep 12, 2017 at 5:33 PM, Guillermo Polito
 wrote:
> I don't know... I found the idea of having a Metaclass binding strange...
>
> I mean,
> - metaclasses are not stored in any name dictionary such as Smalltalk
> - nobody references them directly in source code but by their direct classes
>
> The metaclass binding is there just for one thing really: methods need an
> association to know their class in case they have to do a super send. And
> transitively this is a compiler problem also. But anybody else accesses
> metaclasses' bindings.