[Pharo-dev] About removing class side initialization

[stephane ducasse]

Hi community

I would like to get use your ideas. 

Here is the case

Context: Class side initialize are not good.
We fixed a bug with guille today (should do a PR) this bug was breaking 
some projects by changing the superclass of classes to Object. Radical!

It was produced by the removal of DependentFields in Object and the 
removal of the class side Object initialize method
Needed to initialize DependentFields (RIP).

Doing so when a class was doing a super initialize it executes the 
Behavior>>#initialize  (which reinitialize the class and its superclass) and 
was not reachable before because blocked by Object class>>#initialize.

Two Situations. 

When we do a class super initialize there are two cases

Case 1. the super reaches Behavior>>#initialize and your class gets 
killed.
Solution 1. Easy we will define a class side initialize method to 
protect the execution of Behavior>>#initialize.
Ideally raising a warning so that people can find their problems.

Case 2. 
You have a little hierarchy Root and Subclass1 Subclass2 classes
Root class defines an initialize method. 

You should not redefine initialize in Subclass1 and do a super 
initialize
else we get a double initialize. Not easy to grasp so I guess 
that many people are making this mistake. 

Solution 2. 
Cyril added a rule in a ReleaseTest (yes this is cool and we 
should use more rules and not code by hand in the releaseTest)
that checks for no class side super initialize in Pharo.

Now long time ago I thought that this class initialize is not that good and 
that I would like to have 
a way that class state dependencies do not have to be resolved by the 
developers by initializing first A then B 
but that the system could do it automatically. In this case we would not need 
initialize by class construction. 

Do you have an idea how such design could be?

I’m too dead right now to think but to me it feels a bit similar to lazy 
initialization.
If all the shared variables would be only accessed by lazy accessors then we do 
not need to initialize them statically. 
Now this is a bit extreme but this is to illustrate my wish. 

So let us know :)
Stef

[Pharo-dev] About Undeclared

[Marcus Denker]

Hi,

You might have seen that we have done some work  related to Undeclared.

I did some slides to explain how it worked / how it works now / what remaining 
problems are / next step.




Undeclared.pdf
Description: Adobe PDF document

[Pharo-dev] About thisContext in the Debugger

[Marcus Denker]

# Improving thisContext in the Debugger using First Class Variables


Have you ever tried to inspect a thisContext variable in the debugger? 

Just interrupt Pharo by "CMD-.", the debugger appears with the main UI loop 
waiting on a Semaphore
""[delaySemaphore wait] in Delay>>wait".

So if I now write "thisContext" in that block (without saving, I just want to 
explore), I naively expect this to be the context we are in right now. The 
debugger even shows that below in the inspector (as "implicit thisContext").

But if I inspect it, I get something completely different (try it, here is a 
picture):




## So what happened?!

When you execute code in the debugger (via e.g. doIt, inspectIt or printIt), we 
give the code to the compiler to compile a DoIt method and then execute this 
DoIt method.

With thisContext being a very special PseudoVariable that always just leads to 
emitting the pushThisContext byte-code, hard-coded (thisContext, self and super 
are for are for this reason on the "Syntax" Postcard for ST80).

You can see that by inspecting a method of a DoIt that accesses "thisContext", 
just inspect "thisContext method" and look at the byte-code:


```
33 <52> pushThisContext
34 <80> send: method
35 <5C> returnTop
```

And as we execute the DoIt method, the pushThisContext byte-code pushes the 
context of the method we are executing, which is the DoIt method, not the 
method you are looking at in the debugger.

## Can we do better: First Class Variables to the rescue

In Pharo, all Variables are modelled via a subclass of Variable. This includes 
the Pseudo Variables, the Variable subclass for 'thisContext' is 
ThisContextVariable.
names are never hard-coded, instead name-analysis looks up the name in a scope 
(the block or method that the variable is accessed in) and lookup goes to the 
outerScope until it reaches
the global scope.

There is of course a reflective API, too. You can send #lookupVar: to any scope 
or the context, and the system will return the Variable of that name. For 
example

```
thisContext lookupVar: #self. 
SmalltalkImage lookupVar: #CompilerClass.
Smalltalk globals lookupVar: #Object.
```

These are meta-objects describing Variables. As such, the API contains methods 
to allow the variable to set or return it's value. Depending on the Variable, 
they need some object the read themselves from.
Globals of course can just answer to #read, Slots have #read: to read from an 
Object. But all can read from a context using #readInContext:. 

(Smalltalk globals lookupVar: #Object) readInContext: thisContext.

Of course, the readInContext: method just uses the other reflective read method 
after getting the value from the context if needed, e.g. Slots:

```
readInContext: aContext
^self read: aContext receiver
```

or ThisContextVariable:

```
readInContext: aContext
^aContext   
```

This idea to have meta-object for Variables that provide a reflective API is 
very powerful, we use it in all tools: The inspector reads the values
of the instance variables (and thus does not need to send a message like 
#instVarAt:, nice when you inspect proxies), the Debugger uses this to read 
temps, 
for example in DoIts. To read temps in the debugger that the programmer writes 
in the code, we have to support even the reading of temps that are actually not 
accessible in a block.

For this, when we compile code to be executed as a DoIt against a Context (like 
in the debugger), we use a special scope to lookup variables, the 
OCContextualDoItSemanticScope. It has
a special version of lookupVar:

```
OCContextualDoItSemanticScope>>#lookupVar: name

(targetContext lookupVar: name) ifNotNil: [ :v | ^self importVariable: 
v].

^super lookupVar: name

importVariable: aVariable

^importedVariables
at: aVariable name
ifAbsentPut: [ aVariable asDoItVariableFrom: targetContext ]
```

Thus, it will wrap all variables that you look up in DoItVariable using 
asDoItVariableFrom:, which for now is implemented for temps (the others just 
return self):

```
asDoItVariableFrom: aContext
^ DoItVariable fromContext: aContext variable: self
```


The DoItVariable is a decorator: it decorates the original temp with a context, 
and changes the method that generate code to force the reflective read
even at compile time, e.g for reading:

```
emitValue: aMethodBuilder
aMethodBuilder
pushLiteral: self;
send: #read
```

with #read just forwarding the the original Variable:

```
read
^actualVariable readInContext: doItContext
```

## Let's fix it

So... what if we would add #asDoItVariableFrom: to ThisContextVariable? It 
would then, when we compile the DoIt, call #lookupVar: for thisContext, which
would create the decorator and return it. From that point on, the DoItVariable 
named thisContext shadows the real thisContext, the compiler will ask it 
to generate code. That generated code 

[Pharo-dev] About Bag API

[stephane ducasse]

Hi 

I wonder why I cannot get values of a entry using at:

| aBag |
aBag := Bag new.
aBag addAll: ‘aabbbacaccca’.
aBag at: $a 
>>> 5

I have the impression that this is because Bag API never got the correct amount 
of love
but may be I’m wrong. 

What is your opinion?

S

[Pharo-dev] About Pull Request Reviews: Multiple Reviews are best!

[Marcus Denker]

Hi,

If you see that a PR that you wanted to review already has a positive review,
do not think “ah, nothing to be done for me”.

Because imagine if the PR would be bad: you would add a comment how to improve
in addition to the one already positive review.

You should do the same even if you just add another “Yes, looks good”. 

The reason is that *you* know that you looked at the PR and did not find a 
problem,
but nobody else has a way to see that.

Second (or even third, 4th…) positive reviews are very valuable, they validate
the first review *and* they are vote for getting that PR merged fast.

You can find the PRs in need of a review here:

https://github.com/pharo-project/pharo/pulls

Marcus

[Pharo-dev] About Image Size Pharo9->Pharo11

[Marcus Denker]

Pharo9: 65,8 MB
Pharo10: 57,4 MB
Pharo11: 56,5 MB

The space saving come from three things:

1) Code cleanup Pharo9-Pharo10
=

e.g. removal of support in Kernel and Compiler of old style blocks and 
bytecodes, 
to mention one smaller (in term of image size) but deep cleanup.

Of course, we can do more here. There is still a lot of dead code (and 
duplicated
things) in the image!


2) Global Literal Sharing
===

Literals are now, when the method is compiled, set to be read-only, recursively 
in the case of arrays.

This allows us to unify (share one instance) not only in the same method, but 
globally over all methods.

As the compiler can not do a global literal table when compiling a single 
method (too slow), this is implemented 
as an additional pass, called as part of the build process.

If you load a lot of code, it might be an idea to do that as part of your build 
again:

ImageCleaner shareLiterals


3) Improvement of code structure objects
===

e.g, in Pharo10 we found two empty OrderedCollections per class that where not 
needed. 

Further work on this idea is where the improvement in Pharo11 comes from, we 
merged these three changes:

- Class>>#classPool: empty dictionary for all classes, but not many define 
class vars #11172
https://github.com/pharo-project/pharo/issues/11172

- [Memory] sharedPools OrderedCollections waste memory #10957
https://github.com/pharo-project/pharo/issues/10957

- [Memory] AllProtocol uses a lot of memory #10963
https://github.com/pharo-project/pharo/issues/10963


The classPools/sharedPool improves the size of the bootstrapped image not to0 
much as the boostrap creates
classes with nil there, but for newly loaded code this will be more visible.

This direction has some more fairly simple next steps:

- [Memory] commentSourcePointer is not needed for MetaClasses
https://github.com/pharo-project/pharo/issues/10958

- [Memory] Every class and meta class has both a ProtocolOrganizer and a 
ClassOrganization #10959
https://github.com/pharo-project/pharo/issues/10959


... and of course there are many more things to find with just looking a bit. 

(And it is interesting starting point to think about better language support 
for making long living but rarely changed
 data structures more memory efficient)

If you want to get an impression of which classes use image space, "SpaceTally 
printSpaceAnalysis"
prints a per-class analysis.

Marcus

[Pharo-dev] About ReToDoRule

[Marcus Denker]

 I have never seen ReToDoRule to suggest a change that I wanted to do. 

I think it tries to detect if there is #at: send to the collection inside the 
block and suggests to use more high-level iterators.

But the suggestions are odd and it seems to be too naive with just detecting 
the #at: message send to the iterated value.

"Checks for use of to:do: when a do:, with:do: or timesRepeat: when should be 
used.”

• #timesRepeat: does not take an argument for the block with the 
running index, so it is not a replacement
• with:do: is not a replacement for to:do: ? it would mean creating 
first a collection and then iterating
• using do: on an interval is bad, we even have a rule against that: 
ReUnoptimizedToDoRule


Maybe I am missing something?


The rule ReToDoCollectRule seems to be working nicely, though. 

Issue tracker entry: https://github.com/pharo-project/pharo/issues/11162

[Pharo-dev] About / and ZnUrl

[stephane ducasse]

Hi sven

may be you know the answer :)


'http://www.pharo.org/figures/' asUrl / 'documentation/p.png'
 "http://www.pharo.org/figures/documentation/p.png”

so far so good.


'http://www.pharo.org/figures/' asUrl / '/documentation/p.png'
 "http://www.pharo.org/figures//documentation/p.png;

Why not having 

 "http://www.pharo.org/documentation/p.png”

Because /documentation is absolute so the resolution could take that into 
account.

S

[Pharo-dev] about URL isAbsolute

[stephane ducasse]

Hi 

I’m a bit confused. When I use isAbsolute I get 

'file:///toto.png' asUrl isAbsolute 
>>> false


'file://toto.png' asUrl isAbsolute 
>>> true


Now I confused because as Unix / is absolute so file://toto.png 
 would be relative.
and /foo is absolute. 

Are URLs so different than files?
Are the results I get correct?

I ask this question in the context of Microdown if people write 

![caption](file://toto.png).
![caption](figures/toto.png)
![caption](file:///toto.png).

S

[Pharo-dev] About Pharo X nickname: "Cut the fat"

[stephane ducasse]

Hi pharoers

just a little email to tell you that we are super happy because we are in the 
situation to remove old, unused or part in love for retirement from Pharo. 
And we are doing this at the level of the image but also the VM. 

So far we removed 
GT
Glamour
Alien (under way)
OldFFI (under way)
Old byte code (on the way)
Many Pharo 80 deprecated methods.

We plan to remove
Spec1 - finally
Commander
Refactorings in favor of Refactorings2

At the level of the VM
Yesterday pablo fixed 1000 warnings
We removed 
Newspeak support
MT, 
old bytecode
while fixing ephemerons, GC bugs, ...

This is super important to travel light because it will let us be agile and 
faster.
So if you see questionable code please let us know. 

We do not want to remove functionality but we want to make sure that we do not 
doublons.

S. 

Re: [Pharo-dev] About strange email related to smalltalkhub read-only on squeak-dev

[Mariano Martinez Peck]

On Tue, Jun 2, 2020 at 6:18 AM Norbert Hartl  wrote:

> Hi Paul,
>
> thanks for the info but I won't read it. I try to focus on things that
> matter. There are too many things that try to distract everyone from
> producing something helpful. Law suits are IMHO not of that kind.
>
> I would rather put some money on the table for someone building proper FFI
> to openssl. The Cryptography was a mess I cleaned a bit but I had also
> scenarios where the squeak code was not working properly. And there is no
> real reason to have a smalltalk implementation of crypto if we carry around
> openssl anyway (for iceberg and secure connects).
>
> PierceNg has an implementation that implements a subset of openssl. This
> implementation is modeled after the library so lots of class methods. I'd
> prefer to have something more object model like.
>
> So if you think you can implement this please contact me and tell me what
> you think how long it takes and how much it will cost to do at least the
> things we have now in Cryptography. I'm willing to collect money or pay it
> myself.
>
>

I second this. VA Smalltalk included a complete FFI wrapper of OpenSSL in
VAST 8.6.2 (2015) and it was one of the best decisions ever.


-- 
Mariano Martinez Peck
Email: marianop...@gmail.com
Twitter: @MartinezPeck
LinkedIn: www.linkedin.com/in/mariano-martinez-peck

Blog: https://marianopeck.wordpress.com/

Re: [Pharo-dev] About strange email related to smalltalkhub read-only on squeak-dev

[Norbert Hartl]

Hi Paul,

thanks for the info but I won't read it. I try to focus on things that matter. 
There are too many things that try to distract everyone from producing 
something helpful. Law suits are IMHO not of that kind. 

I would rather put some money on the table for someone building proper FFI to 
openssl. The Cryptography was a mess I cleaned a bit but I had also scenarios 
where the squeak code was not working properly. And there is no real reason to 
have a smalltalk implementation of crypto if we carry around openssl anyway 
(for iceberg and secure connects).

PierceNg has an implementation that implements a subset of openssl. This 
implementation is modeled after the library so lots of class methods. I'd 
prefer to have something more object model like. 

So if you think you can implement this please contact me and tell me what you 
think how long it takes and how much it will cost to do at least the things we 
have now in Cryptography. I'm willing to collect money or pay it myself.

Norbert

> Am 31.05.2020 um 16:04 schrieb Paul DeBruicker :
> 
> Hi Norbert,
> 
> The EFF gives a nice overview of the US situation:
> https://www.eff.org/deeplinks/2019/08/us-export-controls-and-published-encryption-source-code-explained
>  
> 
> 
> Although you are not a US citizen, and don't live here,  so I don't know how
> it could affect you.  
> 
> In the link above the EFF does say they provide free consultations about
> this topic so I'm sure someone there will clear things up for you.
> 
> Paul
> 
> 
> 
> 
> 
> 
> NorbertHartl wrote
>> Yes, let us coordinate what to respond. To me this doesn't even sound like
>> Ron. Usually he is a rather quite and reasonable guy. Seems to be a lot of
>> misunderstandings here (again).
>> As I was the one copying the Cryptography package to github it concerns me
>> a bit. I've been remembered now about yet another strange law suit in the
>> US and indeed we need to raise a bit of awareness for this. 
>> 
>> So let's figure out what has to be done. 
>> 
>> Norbert
>> 
>> 
>>> Am 30.05.2020 um 14:43 schrieb Stéphane Ducasse 
> 
>> stephane.ducasse@
> 
>> :
>>> 
>>> Hi all
>>> 
>>> This is the week-end and we worked super well yesterday during the
>>> sprint. Lot of good enhancements - Thanks a lot to all the participants. 
>>> I not really happy to be forced to do it on a sunny saturday but I’m
>>> doing it to clarify points.
>>> 
>>> Esteban sent me this text that was posted on Squeak-Dev (I personally do
>>> not read squeak related forums because 
>>> I have not the time and my focus is Pharo, its consortium, my team, my
>>> research and my family). 
>>> 
>>> We have to react because 
>>> - We do not really at ***all** understand this email
>>> - We did not kicked anybody from our mailing-list from ages - so ron is
>>> lying. In the past we even had discussion with ron - so we do not 
>>> really understand. May be we got problem to log on our mailing-lists. 
>>> We have no idea because we are working and not looking at such things.  
>>>  
>>> - When we migrated smalltalkhub to readonly we payed attention to make
>>> sure that private projects stay private.
>>> We did not migrated smalltalkhub for fun. We MUST do it or it will be
>>> done by our infrastructure!
>>> - Now the cryptography packages are MIT and they are public anyway. So
>>> again we do not understand anything. 
>>> 
>>> We do not get why Ron contacted us because we announced the migration
>>> publicly way in advance and we will keep 
>>> the Smalltalkhub frozen repo for at least next 5 years. 
>>> 
>>> I feel really sorry to hear such kind of email because we do not want to
>>> fight with anybody. 
>>> Our goal is to make sure that people can work with Pharo and expand their
>>> business and knowledge. 
>>> We are working hard to make sure that people can invent their future with
>>> Pharo and people that know us personally 
>>> know that we are not lying.
>>> 
>>> S
>>> 
>>> 
 Hi all,
 
 I've tried to work with the Pharo group but they keep kicking me out of
 their mailing list.  I've already mentioned this a number of times to
 the Pharo group but nobody seems to care.  
 
 BOLD BOLD BOLD PLEASE TAKE THIS SERIOUSLY  BOLD BOLD BOLD
 
 I am not a lawyer but we used very good lawyers to make the squeaksource
 repository a safe place to do cryptography work.  If you are working on
 cryptography DO NOT POST your code anywhere except squeaksource. 
 Especially if you are in the USA.  The ONLY repository that is approved
 to host our cryptography code in the USA and therefore not subject to
 criminal violations is squeaksource.  It is a CRIME in the USA to move
 code and make it available on the internet for everyone to download! It
 must be hosted on squeaksoruce.com  
 

Re: [Pharo-dev] About strange email related to smalltalkhub read-only on squeak-dev

[Paul DeBruicker]

Hi Norbert,

The EFF gives a nice overview of the US situation:
https://www.eff.org/deeplinks/2019/08/us-export-controls-and-published-encryption-source-code-explained

Although you are not a US citizen, and don't live here,  so I don't know how
it could affect you.  

In the link above the EFF does say they provide free consultations about
this topic so I'm sure someone there will clear things up for you.

Paul






NorbertHartl wrote
> Yes, let us coordinate what to respond. To me this doesn't even sound like
> Ron. Usually he is a rather quite and reasonable guy. Seems to be a lot of
> misunderstandings here (again).
> As I was the one copying the Cryptography package to github it concerns me
> a bit. I've been remembered now about yet another strange law suit in the
> US and indeed we need to raise a bit of awareness for this. 
> 
> So let's figure out what has to be done. 
> 
> Norbert
> 
> 
>> Am 30.05.2020 um 14:43 schrieb Stéphane Ducasse 

> stephane.ducasse@

> :
>> 
>> Hi all
>> 
>> This is the week-end and we worked super well yesterday during the
>> sprint. Lot of good enhancements - Thanks a lot to all the participants. 
>> I not really happy to be forced to do it on a sunny saturday but I’m
>> doing it to clarify points.
>> 
>> Esteban sent me this text that was posted on Squeak-Dev (I personally do
>> not read squeak related forums because 
>> I have not the time and my focus is Pharo, its consortium, my team, my
>> research and my family). 
>> 
>> We have to react because 
>>  - We do not really at ***all** understand this email
>>  - We did not kicked anybody from our mailing-list from ages - so ron is
>> lying. In the past we even had discussion with ron - so we do not 
>>  really understand. May be we got problem to log on our mailing-lists. 
>>  We have no idea because we are working and not looking at such things.  
>>  
>>  - When we migrated smalltalkhub to readonly we payed attention to make
>> sure that private projects stay private.
>>  We did not migrated smalltalkhub for fun. We MUST do it or it will be
>> done by our infrastructure!
>>  - Now the cryptography packages are MIT and they are public anyway. So
>> again we do not understand anything. 
>> 
>> We do not get why Ron contacted us because we announced the migration
>> publicly way in advance and we will keep 
>> the Smalltalkhub frozen repo for at least next 5 years. 
>> 
>> I feel really sorry to hear such kind of email because we do not want to
>> fight with anybody. 
>> Our goal is to make sure that people can work with Pharo and expand their
>> business and knowledge. 
>> We are working hard to make sure that people can invent their future with
>> Pharo and people that know us personally 
>> know that we are not lying.
>> 
>> S
>> 
>> 
>>> Hi all,
>>> 
>>> I've tried to work with the Pharo group but they keep kicking me out of
>>> their mailing list.  I've already mentioned this a number of times to
>>> the Pharo group but nobody seems to care.  
>>> 
>>> BOLD BOLD BOLD PLEASE TAKE THIS SERIOUSLY  BOLD BOLD BOLD
>>> 
>>> I am not a lawyer but we used very good lawyers to make the squeaksource
>>> repository a safe place to do cryptography work.  If you are working on
>>> cryptography DO NOT POST your code anywhere except squeaksource. 
>>> Especially if you are in the USA.  The ONLY repository that is approved
>>> to host our cryptography code in the USA and therefore not subject to
>>> criminal violations is squeaksource.  It is a CRIME in the USA to move
>>> code and make it available on the internet for everyone to download!  It
>>> must be hosted on squeaksoruce.com http://squeaksoruce.com/; or
>>> another location that is also properly registered. 
>>> 
>>> IF YOU COPIED CRYPTOGRAPHY CODE TO ANOTHER REPOSITORY THAT IS NOT
>>> REGISTERED I would recommend you delete it immediately.
>>> 
>>> END BOLD!  
>>> 
>>> Please feel free to post this to the Pharo mailing list because they
>>> apparently do not want to hear from me!
>>> 
>>> All the best,
>>> 
>>> Ron Teitelbaum
>> 
>> 
>> 
>> Stéphane Ducasse
>> http://stephane.ducasse.free.fr http://stephane.ducasse.free.fr/;
>> / http://www.pharo.org http://www.pharo.org/; 
>> 03 59 35 87 52
>> Assistant: Aurore Dalle 
>> FAX 03 59 57 78 50
>> TEL 03 59 35 86 16
>> S. Ducasse - Inria
>> 40, avenue Halley, 
>> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
>> Villeneuve d'Ascq 59650
>> France
>>





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

Re: [Pharo-dev] About strange email related to smalltalkhub read-only on squeak-dev

[Cédrick Béler]

He’s on discord on squeak server. Maybe chatting with him in private could help 
resolve the misunderstanding.

Cheers,
Cedrick

> Le 30 mai 2020 à 18:26, Norbert Hartl  a écrit :
> 
> Yes, let us coordinate what to respond. To me this doesn't even sound like 
> Ron. Usually he is a rather quite and reasonable guy. Seems to be a lot of 
> misunderstandings here (again).
> As I was the one copying the Cryptography package to github it concerns me a 
> bit. I've been remembered now about yet another strange law suit in the US 
> and indeed we need to raise a bit of awareness for this. 
> 
> So let's figure out what has to be done. 
> 
> Norbert
> 
> 
>> Am 30.05.2020 um 14:43 schrieb Stéphane Ducasse :
>> 
>> Hi all
>> 
>> This is the week-end and we worked super well yesterday during the sprint. 
>> Lot of good enhancements - Thanks a lot to all the participants. 
>> I not really happy to be forced to do it on a sunny saturday but I’m doing 
>> it to clarify points.
>> 
>> Esteban sent me this text that was posted on Squeak-Dev (I personally do not 
>> read squeak related forums because 
>> I have not the time and my focus is Pharo, its consortium, my team, my 
>> research and my family). 
>> 
>> We have to react because 
>>  - We do not really at ***all** understand this email
>>  - We did not kicked anybody from our mailing-list from ages - so ron is 
>> lying. In the past we even had discussion with ron - so we do not 
>>  really understand. May be we got problem to log on our mailing-lists. 
>>  We have no idea because we are working and not looking at such things.  
>>  
>>  - When we migrated smalltalkhub to readonly we payed attention to make 
>> sure that private projects stay private.
>>  We did not migrated smalltalkhub for fun. We MUST do it or it will be 
>> done by our infrastructure!
>>  - Now the cryptography packages are MIT and they are public anyway. So 
>> again we do not understand anything. 
>> 
>> We do not get why Ron contacted us because we announced the migration 
>> publicly way in advance and we will keep 
>> the Smalltalkhub frozen repo for at least next 5 years. 
>> 
>> I feel really sorry to hear such kind of email because we do not want to 
>> fight with anybody. 
>> Our goal is to make sure that people can work with Pharo and expand their 
>> business and knowledge. 
>> We are working hard to make sure that people can invent their future with 
>> Pharo and people that know us personally 
>> know that we are not lying.
>> 
>> S
>> 
>> 
>>> Hi all,
>>> 
>>> I've tried to work with the Pharo group but they keep kicking me out of 
>>> their mailing list.  I've already mentioned this a number of times to the 
>>> Pharo group but nobody seems to care.  
>>> 
>>> BOLD BOLD BOLD PLEASE TAKE THIS SERIOUSLY  BOLD BOLD BOLD
>>> 
>>> I am not a lawyer but we used very good lawyers to make the squeaksource 
>>> repository a safe place to do cryptography work.  If you are working on 
>>> cryptography DO NOT POST your code anywhere except squeaksource.  
>>> Especially if you are in the USA.  The ONLY repository that is approved to 
>>> host our cryptography code in the USA and therefore not subject to criminal 
>>> violations is squeaksource.  It is a CRIME in the USA to move code and make 
>>> it available on the internet for everyone to download!  It must be hosted 
>>> on squeaksoruce.com or another location that is also properly registered. 
>>> 
>>> IF YOU COPIED CRYPTOGRAPHY CODE TO ANOTHER REPOSITORY THAT IS NOT 
>>> REGISTERED I would recommend you delete it immediately.
>>> 
>>> END BOLD!  
>>> 
>>> Please feel free to post this to the Pharo mailing list because they 
>>> apparently do not want to hear from me!
>>> 
>>> All the best,
>>> 
>>> Ron Teitelbaum
>> 
>> 
>> 
>> Stéphane Ducasse
>> http://stephane.ducasse.free.fr / http://www.pharo.org 
>> 03 59 35 87 52
>> Assistant: Aurore Dalle 
>> FAX 03 59 57 78 50
>> TEL 03 59 35 86 16
>> S. Ducasse - Inria
>> 40, avenue Halley, 
>> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
>> Villeneuve d'Ascq 59650
>> France
>> 
> 

Re: [Pharo-dev] About strange email related to smalltalkhub read-only on squeak-dev

[Norbert Hartl]

Yes, let us coordinate what to respond. To me this doesn't even sound like Ron. 
Usually he is a rather quite and reasonable guy. Seems to be a lot of 
misunderstandings here (again).
As I was the one copying the Cryptography package to github it concerns me a 
bit. I've been remembered now about yet another strange law suit in the US and 
indeed we need to raise a bit of awareness for this. 

So let's figure out what has to be done. 

Norbert


> Am 30.05.2020 um 14:43 schrieb Stéphane Ducasse :
> 
> Hi all
> 
> This is the week-end and we worked super well yesterday during the sprint. 
> Lot of good enhancements - Thanks a lot to all the participants. 
> I not really happy to be forced to do it on a sunny saturday but I’m doing it 
> to clarify points.
> 
> Esteban sent me this text that was posted on Squeak-Dev (I personally do not 
> read squeak related forums because 
> I have not the time and my focus is Pharo, its consortium, my team, my 
> research and my family). 
> 
> We have to react because 
>   - We do not really at ***all** understand this email
>   - We did not kicked anybody from our mailing-list from ages - so ron is 
> lying. In the past we even had discussion with ron - so we do not 
>   really understand. May be we got problem to log on our mailing-lists. 
>   We have no idea because we are working and not looking at such things.  
>  
>   - When we migrated smalltalkhub to readonly we payed attention to make 
> sure that private projects stay private.
>   We did not migrated smalltalkhub for fun. We MUST do it or it will be 
> done by our infrastructure!
>   - Now the cryptography packages are MIT and they are public anyway. So 
> again we do not understand anything. 
> 
> We do not get why Ron contacted us because we announced the migration 
> publicly way in advance and we will keep 
> the Smalltalkhub frozen repo for at least next 5 years. 
> 
> I feel really sorry to hear such kind of email because we do not want to 
> fight with anybody. 
> Our goal is to make sure that people can work with Pharo and expand their 
> business and knowledge. 
> We are working hard to make sure that people can invent their future with 
> Pharo and people that know us personally 
> know that we are not lying.
> 
> S
> 
> 
>> Hi all,
>> 
>> I've tried to work with the Pharo group but they keep kicking me out of 
>> their mailing list.  I've already mentioned this a number of times to the 
>> Pharo group but nobody seems to care.  
>> 
>> BOLD BOLD BOLD PLEASE TAKE THIS SERIOUSLY  BOLD BOLD BOLD
>> 
>> I am not a lawyer but we used very good lawyers to make the squeaksource 
>> repository a safe place to do cryptography work.  If you are working on 
>> cryptography DO NOT POST your code anywhere except squeaksource.  Especially 
>> if you are in the USA.  The ONLY repository that is approved to host our 
>> cryptography code in the USA and therefore not subject to criminal 
>> violations is squeaksource.  It is a CRIME in the USA to move code and make 
>> it available on the internet for everyone to download!  It must be hosted on 
>> squeaksoruce.com  or another location that is also 
>> properly registered. 
>> 
>> IF YOU COPIED CRYPTOGRAPHY CODE TO ANOTHER REPOSITORY THAT IS NOT REGISTERED 
>> I would recommend you delete it immediately.
>> 
>> END BOLD!  
>> 
>> Please feel free to post this to the Pharo mailing list because they 
>> apparently do not want to hear from me!
>> 
>> All the best,
>> 
>> Ron Teitelbaum
> 
> 
> 
> Stéphane Ducasse
> http://stephane.ducasse.free.fr  / 
> http://www.pharo.org  
> 03 59 35 87 52
> Assistant: Aurore Dalle 
> FAX 03 59 57 78 50
> TEL 03 59 35 86 16
> S. Ducasse - Inria
> 40, avenue Halley, 
> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
> Villeneuve d'Ascq 59650
> France
> 

[Pharo-dev] About strange email related to smalltalkhub read-only on squeak-dev

[Stéphane Ducasse]

Hi all

This is the week-end and we worked super well yesterday during the sprint. Lot 
of good enhancements - Thanks a lot to all the participants. 
I not really happy to be forced to do it on a sunny saturday but I’m doing it 
to clarify points.

Esteban sent me this text that was posted on Squeak-Dev (I personally do not 
read squeak related forums because 
I have not the time and my focus is Pharo, its consortium, my team, my research 
and my family). 

We have to react because 
- We do not really at ***all** understand this email
- We did not kicked anybody from our mailing-list from ages - so ron is 
lying. In the past we even had discussion with ron - so we do not 
really understand. May be we got problem to log on our mailing-lists. 
We have no idea because we are working and not looking at such things.  
 
- When we migrated smalltalkhub to readonly we payed attention to make 
sure that private projects stay private.
We did not migrated smalltalkhub for fun. We MUST do it or it will be 
done by our infrastructure!
- Now the cryptography packages are MIT and they are public anyway. So 
again we do not understand anything. 

We do not get why Ron contacted us because we announced the migration publicly 
way in advance and we will keep 
the Smalltalkhub frozen repo for at least next 5 years. 

I feel really sorry to hear such kind of email because we do not want to fight 
with anybody. 
Our goal is to make sure that people can work with Pharo and expand their 
business and knowledge. 
We are working hard to make sure that people can invent their future with Pharo 
and people that know us personally 
know that we are not lying.

S


> Hi all,
> 
> I've tried to work with the Pharo group but they keep kicking me out of their 
> mailing list.  I've already mentioned this a number of times to the Pharo 
> group but nobody seems to care.  
> 
> BOLD BOLD BOLD PLEASE TAKE THIS SERIOUSLY  BOLD BOLD BOLD
> 
> I am not a lawyer but we used very good lawyers to make the squeaksource 
> repository a safe place to do cryptography work.  If you are working on 
> cryptography DO NOT POST your code anywhere except squeaksource.  Especially 
> if you are in the USA.  The ONLY repository that is approved to host our 
> cryptography code in the USA and therefore not subject to criminal violations 
> is squeaksource.  It is a CRIME in the USA to move code and make it available 
> on the internet for everyone to download!  It must be hosted on 
> squeaksoruce.com or another location that is also properly registered. 
> 
> IF YOU COPIED CRYPTOGRAPHY CODE TO ANOTHER REPOSITORY THAT IS NOT REGISTERED 
> I would recommend you delete it immediately.
> 
> END BOLD!  
> 
> Please feel free to post this to the Pharo mailing list because they 
> apparently do not want to hear from me!
> 
> All the best,
> 
> Ron Teitelbaum



Stéphane Ducasse
http://stephane.ducasse.free.fr / http://www.pharo.org 
03 59 35 87 52
Assistant: Aurore Dalle 
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley, 
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France

[Pharo-dev] about deprecation

[Stéphane Ducasse]

Hi 

do you think that 

nbCall: fnSpec
"You can override this method if you need to"

self deprecated: 'use ffiCall: instead'.
^ (self ffiCalloutIn: thisContext sender)
convention: self ffiCallingConvention;
function: fnSpec library: self ffiLibraryName

can take advantage of the transformWith: 

nbCall: fnSpec
"You can override this method if you need to"

self deprecated: 'use ffiCall: instead’ transformWith: ‘`@rec nbCall: 
`@arg’ ->  ‘`@rec ffiCall: `@arg’ 
^ (self ffiCalloutIn: thisContext sender)
convention: self ffiCallingConvention;
function: fnSpec library: self ffiLibraryName

Thanks 

Stef

Stéphane Ducasse
http://stephane.ducasse.free.fr / http://www.pharo.org 
03 59 35 87 52
Assistant: Aurore Dalle 
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley, 
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France

[Pharo-dev] About RBProgramNodeVisitor >> visitMethodNode: aMethodNode

[Stéphane Ducasse]

While I can understand that RBProgramNodeVisitor >> visitMethodNode: 
aMethodNode does not return a value. 
- because visiting a program does not mean automatically to interpret it. 

RBProgramNodeVisitor >> visitMethodNode: aMethodNode
self visitArgumentNodes: aMethodNode arguments.
aMethodNode pragmas do: [ :each | self visitNode: each ].
self visitNode: aMethodNode body

I was wondering if we could have visitBody

RBProgramNodeVisitor >> visitMethodNode: aMethodNode
self visitArgumentNodes: aMethodNode arguments.
aMethodNode pragmas do: [ :each | self visitNode: each ].
self visitBody: aMethodNode


RBProgramNodeVisitor >> visitBody: aMethodNode
self visitNode: aMethodNode body


So that subclasses can simply override it instead of being forced to override 
visitMethodNode: ?

https://github.com/pharo-project/pharo/issues/5521

S



Stéphane Ducasse
http://stephane.ducasse.free.fr / http://www.pharo.org 
03 59 35 87 52
Assistant: Julie Jonas 
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley, 
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France

Re: [Pharo-dev] about signal

[ducasse]

While working on the booklet this week-end I was wondering (now I’m too dead to 
think and going to sleep)
whether there is a semantics difference between resuming a suspended process 
using the message resume and
“resuming a process” as a side effect of a wait signalled. 

S. 

Re: [Pharo-dev] about signal

[ducasse]

> 
> If processPreemptionYields false the output should be:
> 
> ...
> p2
> p1
> p2
> p1
> p2
> p1
> ...
> 
> i.e. it is regular.  What we're actually seeing is:
> 
> ...
> 'p1'
> 'p2'
> 'p1'
> 'p2'
> 'p2'
> ...
> 
> Which showing that p2 might get to signal multiple times before p1
> gets to complete a single loop.

Yes this is why I prefer the new preemption semantics. 
The old semantics looks like bringing more “chaos”.
On one hand, it may give a chance to some processes to execute but
I wonder also if code did not get more complex to protect against extra race 
conditions
(since the old way could schedule more randomly). 

Now we were discussing some weeks ago about the risks to use the new semantics
and also if we can identify the processes that we will have to change to 
explicitly yield. 

S.
 

Re: [Pharo-dev] about signal

[Alistair Grant]

Hi Eliot,

On Sun, 12 Jan 2020 at 18:16, Eliot Miranda  wrote:
>
>> Hi Alastair,
>>
>> On Jan 12, 2020, at 12:34 AM, Alistair Grant  wrote:
>>
>> I agree with Eliot that changing #processPreemptionYields to true by
>> default would be an improvement in Pharo.  It would make it easier to
>> predict what is happening in a complex environment
>
>
> You mean to write that
>
> “I agree with Eliot that changing #processPreemptionYields to false by
> default would be an improvement in Pharo.  It would make it easier to
> predict what is happening in a complex environment.”
>
> Preemption by a higher priority process should not cause a yield.

Yes, sorry about that.

Cheers,
Alistair

Re: [Pharo-dev] about signal

[Eliot Miranda]

Hi Alastair,

>> On Jan 12, 2020, at 12:34 AM, Alistair Grant  wrote:
> On Thu, 9 Jan 2020 at 13:01, ducasse  wrote:
>> 
>> Hi
>> 
>> I wanted to explain
>> 
>> | semaphore p1 p2 |
>> semaphore := Semaphore new.
>> p1 := [ semaphore wait.
>>'p1' crTrace ] fork.
>> 
>> p2 := [semaphore signal.
>> 'p2' crTrace ] fork.
>> 
>> displays p2 and p1.
>> but I would like explain clearly but it depends on the semantics of signal.
> 
> The way this is phrased seems to imply that 'p2' will always be
> displayed before 'p1', however in Pharo this is not guaranteed (when
> the processes are at the same priority, as they are this example).
> 
> As Eliot implied in another reply, Pharo has #processPreemptionYields
> set to true, which means that any time a higher priority process
> preempts, the current process will be moved to the back of the queue.
> 
> So in the case above, after p2 signals the semaphore, if a timer was
> delivered or keystroke pressed, p2 would be suspended and moved to the
> back of the queue.  When the timer / keystroke / etc. had finished
> processing p1 would be at the front of the queue and would complete
> first.
> 
> Since time and input events are (for practical purposes) unpredictable
> it means that the execution order of processes at a given priority is
> also unpredictable.
> 
> While this isn't likely to happen in the example above, I have seen it
> regularly with TaskIt and multiple entries being run concurrently.
> 
> I agree with Eliot that changing #processPreemptionYields to true by
> default would be an improvement in Pharo.  It would make it easier to
> predict what is happening in a complex environment

You mean to write that 

“I agree with Eliot that changing #processPreemptionYields to false by
default would be an improvement in Pharo.  It would make it easier to
predict what is happening in a complex environment.”

Preemption by a higher priority process should not cause a yield.

> Running the following variant, and then typing in to another window,
> demonstrates the behaviour:
> 
> | semaphore p1 p2 |
> semaphore := Semaphore new.
> [ 100 timesRepeat: [
> p1 := [ | z |
> semaphore wait.
> z := SmallInteger maxVal.
>   1000 timesRepeat: [ z := z + 1 ].
> 'p1' crTrace ] fork.
> 
> p2 := [ | z | 1 second wait.
> semaphore signal.
> z := SmallInteger maxVal.
>   1000 timesRepeat: [ z := z + 1 ].
>   'p2' crTrace ] fork.
> 1 second wait.
> ] ] fork.
> 
> 
> The tail of transcript:
> 
> 'p2'
> 'p1'
> 'p1'
> 'p1'
> 'p1'
> 'p2'
> 'p2'
> 'p2'
> 'p1'
> 'p1'
> 'p2'
> 'p1'
> 'p2'
> 'p2'
> 'p1'
> 'p1'
> 'p2'
> 'p1'
> 
> 
> 
> Cheers,
> Alistair

Cheers, Alistair!
_,,,^..^,,,_ (phone)

Re: [Pharo-dev] about signal

[Alistair Grant]

Hi Ben,

On Sun, 12 Jan 2020 at 15:26, Ben Coman  wrote:
>
> Now a new consideration for whether Pharo might change the default 
> processPreemptionYields to false
> is ThreadedFFI.  Presumably it will be common for a callback to be defined at 
> same priority as an in-image process.
> I can't quite think through the implications myself.
> So a question... if a callback is a lower-priority than the current process, 
> does it wait before grabbing the VM lock (IIUC how that is meant to work)?

The version of Threaded FFI I'm using at the moment is about a month
old, but assuming nothing has changed...

The callback queue is currently run at priority 70 (vs the UI process
at 40).  The reasoning as explained by Esteban (from memory) is that
you may want callbacks to do some small amount of work and respond
quickly.


> P.S. Now I wonder about the impact of upcoming Idle-VM.  Currently 
> same-priority-processes are effectively round-robin scheduled
> because the high priority DelayScheduler triggers often, bumping the current 
> process to the back of its runQueue.
> When it triggers less often, anything relying on this implicit behaviour may 
> act differently.

Another reason to consider #processPreemptionYields set to false :-)

Cheers,
Alistair

Re: [Pharo-dev] about signal

[Ben Coman]

On Sun, 12 Jan 2020 at 20:00, Sven Van Caekenberghe  wrote:

> Hi Alistair,
>
> > On 12 Jan 2020, at 09:33, Alistair Grant  wrote:
> >
> > On Thu, 9 Jan 2020 at 13:01, ducasse  wrote:
> >>
> >> Hi
> >>
> >> I wanted to explain
> >>
> >> | semaphore p1 p2 |
> >> semaphore := Semaphore new.
> >> p1 := [ semaphore wait.
> >>'p1' crTrace ] fork.
> >>
> >> p2 := [semaphore signal.
> >> 'p2' crTrace ] fork.
> >>
> >> displays p2 and p1.
> >> but I would like explain clearly but it depends on the semantics of
> signal.
> >
> > The way this is phrased seems to imply that 'p2' will always be
> > displayed before 'p1', however in Pharo this is not guaranteed (when
> > the processes are at the same priority, as they are this example).
> >
> > As Eliot implied in another reply, Pharo has #processPreemptionYields
> > set to true, which means that any time a higher priority process
> > preempts, the current process will be moved to the back of the queue.
> >
> > So in the case above, after p2 signals the semaphore, if a timer was
> > delivered or keystroke pressed, p2 would be suspended and moved to the
> > back of the queue.  When the timer / keystroke / etc. had finished
> > processing p1 would be at the front of the queue and would complete
> > first.
> >
> > Since time and input events are (for practical purposes) unpredictable
> > it means that the execution order of processes at a given priority is
> > also unpredictable.
> >
> > While this isn't likely to happen in the example above, I have seen it
> > regularly with TaskIt and multiple entries being run concurrently.
> >
> > I agree with Eliot that changing #processPreemptionYields to true by
> > default would be an improvement in Pharo.  It would make it easier to
> > predict what is happening in a complex environment.
>
> I don't understand, in your second paragraph you say 'Pharo has
> #processPreemptionYields set to true' and now you say it should become the
> default. Is that already the case or not then ?


> > Running the following variant, and then typing in to another window,
> > demonstrates the behaviour:
>
> I am not sure what you want to demonstrate: that it is totally random
> depending on external factors ;-) ?
>
> Which is pretty bad: how should semaphores be used (safely) ? What are
> good examples of real world correct semaphore usage ?
>

Bad depends on the assumptions you are working with.
The issue is its generally promoted that our scheduling is
"preemptive-across-priorities, cooperative-within-priorities"
but thats not entirely true for Pharo, which is
"preemptive-across-priorities, mostly-cooperative-within-priorities".

The former is arguably a simpler model to reason about, and having
consistent implicit-behaviour between same-priority-processes lessens the
need for Semaphores between them.
However if you naively "assume" the former you may get burnt in Pharo since
behaviour between same-priority-processes is random
depending on "when" higher priority processes are scheduled.

But if you "assume" the latter (i.e. that your process can be preempted any
time) you'd use Semaphores as-needed and have no problems.
So to reply directly to your last line. Semaphores can always be used
safely.  Its poor assumptions about when Semaphores aren't required that is
bad.


Now a new consideration for whether Pharo might change the default
processPreemptionYields to false
is ThreadedFFI.  Presumably it will be common for a callback to be defined
at same priority as an in-image process.
I can't quite think through the implications myself.
So a question... if a callback is a lower-priority than the current
process, does it wait before grabbing the VM lock (IIUC how that is meant
to work)?



> Right now, all the explanations around scheduling of processes and their
> priorities make it seem as if the answer is 'it all depends' and 'there is
> no way to be 100% sure what will happen'.
>

Reasoning about processes at different-priorities its easy and explicit.
Between processes at the same-priority you are correct, currently 'there is
no way to be 100% sure what will happen' (without Semaphores).
Examples showing same-priority processes interacting like its cooperative
will lead to student confusion when their results differ from the book.
Currently Pharo must be taught with examples presuming a fully preemptive
system (at restricted locations like backward jumps).

cheers -ben

P.S. Now I wonder about the impact of upcoming Idle-VM.  Currently
same-priority-processes are effectively round-robin scheduled
because the high priority DelayScheduler triggers often, bumping the
current process to the back of its runQueue.
When it triggers less often, anything relying on this implicit behaviour
may act differently.

Re: [Pharo-dev] about signal

[ducasse]

> 
> I also wasn't implying that we just go ahead and change it.  But if it
> is a possibility then I'll try changing it in my image and see how it
> helps with tracking down inter-process interactions that we're
> currently experiencing, and if it does introduce any showstopper
> issues.

Yes this is clearly something that we should evaluate.
Now we have more urgent problems to fix :).
At least with the concurrent booklet we will set the stage and create material 
that everybody can read and understand. 

S. 

Re: [Pharo-dev] about signal

[Alistair Grant]

Hi Stef,

On Sun, 12 Jan 2020 at 11:28, ducasse  wrote:
>
> Hi alistair
>
>
> Hi
>
> I wanted to explain
>
> | semaphore p1 p2 |
> semaphore := Semaphore new.
> p1 := [ semaphore wait.
>'p1' crTrace ] fork.
>
> p2 := [semaphore signal.
> 'p2' crTrace ] fork.
>
> displays p2 and p1.
> but I would like explain clearly but it depends on the semantics of signal.
>
>
> The way this is phrased seems to imply that 'p2' will always be
> displayed before 'p1', however in Pharo this is not guaranteed (when
> the processes are at the same priority, as they are this example).
>
>
> No this is not what I implied.
> I will reread and rephrase the chapters.
>
> As Eliot implied in another reply, Pharo has #processPreemptionYields
> set to true, which means that any time a higher priority process
> preempts, the current process will be moved to the back of the queue.
>
>
> Yes this is explained in the next chapter.
> What you should see is that we cannot explain everything in a single chapter.
> At least I cannot.

Agreed.  Maybe just a footnote indicating that process scheduling will
be explained in later chapters.


> So in the case above, after p2 signals the semaphore, if a timer was
> delivered or keystroke pressed, p2 would be suspended and moved to the
> back of the queue.  When the timer / keystroke / etc. had finished
> processing p1 would be at the front of the queue and would complete
> first.
>
> Since time and input events are (for practical purposes) unpredictable
> it means that the execution order of processes at a given priority is
> also unpredictable.
>
> While this isn't likely to happen in the example above, I have seen it
> regularly with TaskIt and multiple entries being run concurrently.
>
> I agree with Eliot that changing #processPreemptionYields to true by
> default would be an improvement in Pharo.  It would make it easier to
> predict what is happening in a complex environment.

As Sven kindly pointed out, I meant to say set
#processPreemptionYields to false.


> If this would be that easy. :)
> Now what would be a consequence: we should revisit all the processes of the 
> system
> and understand if/where they should yield. Because now there is an implicit 
> yield.
> So in an ideal world the new semantics is probably better. Now are we ready 
> to get new bugs
> and chase them when an old logic like for example an hidden process in 
> calypso worked
> under the assumption that it was implicitly yielding after preemption?
> This is the question that we asked ourselves and we do not really know.
> So far Pharo worked this way during 12 years with this semantics (I does not 
> mean that we cannot
> change because of our Motto - but the point is to understand the impact and 
> control).
> Contrary to what people may think we are not changing without assessing 
> impact.
> So to us this is not an easy decision (while doing it take one single line of 
> one assignment).

I also wasn't implying that we just go ahead and change it.  But if it
is a possibility then I'll try changing it in my image and see how it
helps with tracking down inter-process interactions that we're
currently experiencing, and if it does introduce any showstopper
issues.

Cheers,
Alistair

Re: [Pharo-dev] about signal

[Alistair Grant]

Hi Sven,

In line below...

Cheers,
Alistair
(on phone)

On Sun., 12 Jan. 2020, 13:00 Sven Van Caekenberghe,  wrote:
>
> Hi Alistair,
>
> > On 12 Jan 2020, at 09:33, Alistair Grant  wrote:
> >
> >
> > I agree with Eliot that changing #processPreemptionYields to true by
> > default would be an improvement in Pharo.  It would make it easier to
> > predict what is happening in a complex environment.
>
> I don't understand, in your second paragraph you say 'Pharo has 
> #processPreemptionYields set to true' and now you say it should become the 
> default. Is that already the case or not then ?

Oops, typo, sorry.  I meant to say 'false'. (I shouldn't ever reply in a hurry).



>
> > Running the following variant, and then typing in to another window,
> > demonstrates the behaviour:
>
> I am not sure what you want to demonstrate: that it is totally random 
> depending on external factors ;-) ?

If processPreemptionYields false the output should be:

...
p2
p1
p2
p1
p2
p1
...

i.e. it is regular.  What we're actually seeing is:

...
'p1'
'p2'
'p1'
'p2'
'p2'
...

Which showing that p2 might get to signal multiple times before p1
gets to complete a single loop.


> Which is pretty bad: how should semaphores be used (safely) ? What are good 
> examples of real world correct semaphore usage ?

Given a set of processes at the same priority the amount of time
allocated to any one of the processes is unpredictable.

All the semaphore usage is working as described.  My point wasn't that
the semaphores are being used incorrectly, but that you can't make
assumptions about the order in which processes will complete if they
are CPU bound.


> Right now, all the explanations around scheduling of processes and their 
> priorities make it seem as if the answer is 'it all depends' and 'there is no 
> way to be 100% sure what will happen'.

The semaphore operations are clear, but which process, within a single
process priority, gets the most CPU time is less so.

 HTH,
Alistair

Re: [Pharo-dev] about signal

[Sven Van Caekenberghe]

Hi Alistair,

> On 12 Jan 2020, at 09:33, Alistair Grant  wrote:
> 
> On Thu, 9 Jan 2020 at 13:01, ducasse  wrote:
>> 
>> Hi
>> 
>> I wanted to explain
>> 
>> | semaphore p1 p2 |
>> semaphore := Semaphore new.
>> p1 := [ semaphore wait.
>>'p1' crTrace ] fork.
>> 
>> p2 := [semaphore signal.
>> 'p2' crTrace ] fork.
>> 
>> displays p2 and p1.
>> but I would like explain clearly but it depends on the semantics of signal.
> 
> The way this is phrased seems to imply that 'p2' will always be
> displayed before 'p1', however in Pharo this is not guaranteed (when
> the processes are at the same priority, as they are this example).
> 
> As Eliot implied in another reply, Pharo has #processPreemptionYields
> set to true, which means that any time a higher priority process
> preempts, the current process will be moved to the back of the queue.
> 
> So in the case above, after p2 signals the semaphore, if a timer was
> delivered or keystroke pressed, p2 would be suspended and moved to the
> back of the queue.  When the timer / keystroke / etc. had finished
> processing p1 would be at the front of the queue and would complete
> first.
> 
> Since time and input events are (for practical purposes) unpredictable
> it means that the execution order of processes at a given priority is
> also unpredictable.
> 
> While this isn't likely to happen in the example above, I have seen it
> regularly with TaskIt and multiple entries being run concurrently.
> 
> I agree with Eliot that changing #processPreemptionYields to true by
> default would be an improvement in Pharo.  It would make it easier to
> predict what is happening in a complex environment.

I don't understand, in your second paragraph you say 'Pharo has 
#processPreemptionYields set to true' and now you say it should become the 
default. Is that already the case or not then ?

> Running the following variant, and then typing in to another window,
> demonstrates the behaviour:

I am not sure what you want to demonstrate: that it is totally random depending 
on external factors ;-) ?

Which is pretty bad: how should semaphores be used (safely) ? What are good 
examples of real world correct semaphore usage ?

Right now, all the explanations around scheduling of processes and their 
priorities make it seem as if the answer is 'it all depends' and 'there is no 
way to be 100% sure what will happen'.

Sven

> | semaphore p1 p2 |
> semaphore := Semaphore new.
> [ 100 timesRepeat: [
> p1 := [ | z |
> semaphore wait.
> z := SmallInteger maxVal.
>   1000 timesRepeat: [ z := z + 1 ].
> 'p1' crTrace ] fork.
> 
> p2 := [ | z | 1 second wait.
> semaphore signal.
> z := SmallInteger maxVal.
>   1000 timesRepeat: [ z := z + 1 ].
>   'p2' crTrace ] fork.
> 1 second wait.
> ] ] fork.
> 
> 
> The tail of transcript:
> 
> 'p2'
> 'p1'
> 'p1'
> 'p1'
> 'p1'
> 'p2'
> 'p2'
> 'p2'
> 'p1'
> 'p1'
> 'p2'
> 'p1'
> 'p2'
> 'p2'
> 'p1'
> 'p1'
> 'p2'
> 'p1'
> 
> 
> 
> Cheers,
> Alistair

Re: [Pharo-dev] about signal

[Sven Van Caekenberghe]

Hi Ben,

> On 11 Jan 2020, at 10:50, Ben Coman  wrote:
> 
> 
> 
> On Sat, 11 Jan 2020 at 06:31, Sven Van Caekenberghe  wrote:
> Hi Ben,
> 
> Great approach, though I would make one change to make your example 
> completely copy/paste runnable.
> 
> Stef's original example:
> 
> | trace semaphore p1 p2 |
> 
> semaphore := Semaphore new.
> 
> trace := [ :message | 
> ('[{1}] {2}' format: { Processor activeProcess priority. message }) 
> crLog ].
> 
> p1 := [ 
> semaphore wait.
> trace value: 'Process 1' ] fork.
> 
> p2 := [
> semaphore signal.
> trace value: 'Process 2' ] fork.  
> 
> trace value: 'Original process pre-yield'.
> Processor yield.
> trace value: 'Original process post-yield'.  
> 
> Gives:
> 
> '[40] Original process pre-yield'
> '[40] Process 2'
> '[40] Original process post-yield'
> '[40] Process 1'
> 
> But not running the yield section gives: 
> 
> '[40] Process 2'
> '[40] Process 1'
> 
> which is an identical result if the 'Original process' traces are filtered 
> out.
> 
>  
> From this it would seem that the code in p2 continues after signal and only 
> later does p1 get past its wait.
> 
> Yes, a #signal does not transfer execution unless the waiting-process that 
> received the signal is a higher priority.
> Within the same priority, it just makes waiting-process runnable, and the 
> highest-priority-runnable-process is the one that is run. 

OK, I can understand that, the question remains what happens when the processes 
have equal priorities.

> Playing with the priorities we can change that order (apparently);
> 
> | trace semaphore p1 p2 |
> 
> semaphore := Semaphore new.
> 
> trace := [ :message | 
> ('[{1}] {2}' format: { Processor activeProcess priority. message }) 
> crLog ].
> 
> p1 := [ 
> semaphore wait.
> trace value: 'Process 1' ] forkAt: 30.
> 
> p2 := [
> semaphore signal.
> trace value: 'Process 2' ] forkAt: 20.  
> 
> Gives:
> 
> '[30] Process 1'
> '[20] Process 2'
> 
> Again, the yield section makes no difference. So something else happened.
> 
> The yield made no difference because it only facilitates other processes 
> at-the-SAME-priority getting a chance to run.
> Yield doesn't put the current-process to sleep, it just moves the process to 
> the back of its-priority-runQueue. It gets to run again before any lower 
> priority process gets a chance to run.
> 
> Yielding will never allow a lower-priority-process to run.  
> For a lower-priority process to run, the current-process needs to sleep 
> rather than yield.

These are clear statements.

> Compare...
> | trace semaphore p1 p2 |
> semaphore := Semaphore new.
> trace := [ :message | ('@{1} {2}' format: { Processor activePriority. message 
> }) crLog ].
> p1 := [
>trace value: 'Process 1a waits for signal on semaphore'. 
>semaphore wait.
>trace value: 'Process 1b received signal' ] forkAt: 30.
> p2 := [
>trace value: 'Process 2a signals semaphore'. 
>semaphore signal.
>trace value: 'Process 2b continues' ] forkAt: 20.
> trace value: 'Original process pre-yield'.
> Processor yield.
> trace value: 'Original process post-yield'. 
> 
> ==>
> '@40 Original process pre-yield'
> '@40 Original process post-yield'
> '@30 Process 1a waits for signal on semaphore'
> '@20 Process 2a signals semaphore'
> '@30 Process 1b received signal'
> '@20 Process 2b continues'
> 
> with...
> | trace semaphore p1 p2 |
> semaphore := Semaphore new.
> trace := [ :message | ('@{1} {2}' format: { Processor activePriority. message 
> }) crLog ].
> p1 := [
>trace value: 'Process 1a waits for signal on semaphore'. 
>semaphore wait.
>trace value: 'Process 1b received signal' ] forkAt: 30.
> p2 := [
>trace value: 'Process 2a signals semaphore'. 
>semaphore signal.
>trace value: 'Process 2b continues' ] forkAt: 20.
> trace value: 'Original process pre-delay'.
> 1 milliSecond wait.
> trace value: 'Original process post-delay'.   
> 
> ==>
> '@40 Original process pre-delay'
> '@30 Process 1a waits for signal on semaphore'
> '@20 Process 2a signals semaphore'
> '@30 Process 1b received signal'
> '@20 Process 2b continues'
> '@40 Original process post-delay'

OK, good example: I think/hope I understand.

Now, these further examples only strengthen my believe that it is simply 
impossible to talk about semaphores without talking about (the complexities) of 
process scheduling.

Semaphores exist as a means to coordinate processes, hence when using them you 
have to understand what (will) happen, and apparently that is quite complex.

In any case, thanks again for the explanations,

Sven

> Stef, on further consideration I think your first examples should not-have p1 
> and p2 the same priority.
> Scheduling of same-priority processes and how they interact with the UI 
> thread is an extra level of complexity that may be better done shortly after.
> Not needing to trace "Original process" in the first example gives less for 

Re: [Pharo-dev] about signal

[ducasse]

Hi alistair

>> 
>> Hi
>> 
>> I wanted to explain
>> 
>> | semaphore p1 p2 |
>> semaphore := Semaphore new.
>> p1 := [ semaphore wait.
>>'p1' crTrace ] fork.
>> 
>> p2 := [semaphore signal.
>> 'p2' crTrace ] fork.
>> 
>> displays p2 and p1.
>> but I would like explain clearly but it depends on the semantics of signal.
> 
> The way this is phrased seems to imply that 'p2' will always be
> displayed before 'p1', however in Pharo this is not guaranteed (when
> the processes are at the same priority, as they are this example).

No this is not what I implied. 
I will reread and rephrase the chapters. 

> As Eliot implied in another reply, Pharo has #processPreemptionYields
> set to true, which means that any time a higher priority process
> preempts, the current process will be moved to the back of the queue.

Yes this is explained in the next chapter. 
What you should see is that we cannot explain everything in a single chapter. 
At least I cannot. 
> 
> So in the case above, after p2 signals the semaphore, if a timer was
> delivered or keystroke pressed, p2 would be suspended and moved to the
> back of the queue.  When the timer / keystroke / etc. had finished
> processing p1 would be at the front of the queue and would complete
> first.
> 
> Since time and input events are (for practical purposes) unpredictable
> it means that the execution order of processes at a given priority is
> also unpredictable.
> 
> While this isn't likely to happen in the example above, I have seen it
> regularly with TaskIt and multiple entries being run concurrently.
> 
> I agree with Eliot that changing #processPreemptionYields to true by
> default would be an improvement in Pharo.  It would make it easier to
> predict what is happening in a complex environment.

If this would be that easy. :)
Now what would be a consequence: we should revisit all the processes of the 
system 
and understand if/where they should yield. Because now there is an implicit 
yield. 
So in an ideal world the new semantics is probably better. Now are we ready to 
get new bugs
and chase them when an old logic like for example an hidden process in calypso 
worked 
under the assumption that it was implicitly yielding after preemption? 
This is the question that we asked ourselves and we do not really know. 
So far Pharo worked this way during 12 years with this semantics (I does not 
mean that we cannot
change because of our Motto - but the point is to understand the impact and 
control). 
Contrary to what people may think we are not changing without assessing impact. 
So to us this is not an easy decision (while doing it take one single line of 
one assignment). 


> Running the following variant, and then typing in to another window,

I like the idea of the input to show the interaction between processes. 
I will investigate what I can do with it. 
> demonstrates the behaviour:
> 
> | semaphore p1 p2 |
> semaphore := Semaphore new.
> [ 100 timesRepeat: [
> p1 := [ | z |
> semaphore wait.
> z := SmallInteger maxVal.
>   1000 timesRepeat: [ z := z + 1 ].
> 'p1' crTrace ] fork.
> 
> p2 := [ | z | 1 second wait.
> semaphore signal.
> z := SmallInteger maxVal.
>   1000 timesRepeat: [ z := z + 1 ].
>   'p2' crTrace ] fork.
> 1 second wait.
> ] ] fork.
> 
> 
> The tail of transcript:
> 
> 'p2'
> 'p1'
> 'p1'
> 'p1'
> 'p1'
> 'p2'
> 'p2'
> 'p2'
> 'p1'
> 'p1'
> 'p2'
> 'p1'
> 'p2'
> 'p2'
> 'p1'
> 'p1'
> 'p2'
> 'p1'
> 
> 
> 
> Cheers,
> Alistair

Re: [Pharo-dev] about signal

[Alistair Grant]

On Thu, 9 Jan 2020 at 13:01, ducasse  wrote:
>
> Hi
>
> I wanted to explain
>
> | semaphore p1 p2 |
> semaphore := Semaphore new.
> p1 := [ semaphore wait.
> 'p1' crTrace ] fork.
>
> p2 := [semaphore signal.
>  'p2' crTrace ] fork.
>
> displays p2 and p1.
> but I would like explain clearly but it depends on the semantics of signal.

The way this is phrased seems to imply that 'p2' will always be
displayed before 'p1', however in Pharo this is not guaranteed (when
the processes are at the same priority, as they are this example).

As Eliot implied in another reply, Pharo has #processPreemptionYields
set to true, which means that any time a higher priority process
preempts, the current process will be moved to the back of the queue.

So in the case above, after p2 signals the semaphore, if a timer was
delivered or keystroke pressed, p2 would be suspended and moved to the
back of the queue.  When the timer / keystroke / etc. had finished
processing p1 would be at the front of the queue and would complete
first.

Since time and input events are (for practical purposes) unpredictable
it means that the execution order of processes at a given priority is
also unpredictable.

While this isn't likely to happen in the example above, I have seen it
regularly with TaskIt and multiple entries being run concurrently.

I agree with Eliot that changing #processPreemptionYields to true by
default would be an improvement in Pharo.  It would make it easier to
predict what is happening in a complex environment.

Running the following variant, and then typing in to another window,
demonstrates the behaviour:

| semaphore p1 p2 |
semaphore := Semaphore new.
[ 100 timesRepeat: [
p1 := [ | z |
semaphore wait.
z := SmallInteger maxVal.
   1000 timesRepeat: [ z := z + 1 ].
'p1' crTrace ] fork.

p2 := [ | z | 1 second wait.
semaphore signal.
z := SmallInteger maxVal.
   1000 timesRepeat: [ z := z + 1 ].
   'p2' crTrace ] fork.
1 second wait.
] ] fork.


The tail of transcript:

'p2'
'p1'
'p1'
'p1'
'p1'
'p2'
'p2'
'p2'
'p1'
'p1'
'p2'
'p1'
'p2'
'p2'
'p1'
'p1'
'p2'
'p1'



Cheers,
Alistair

Re: [Pharo-dev] about signal

[ducasse]

Yes this was really fun for me to discover that in newProcess

newProcess
"Answer a Process running the code in the receiver. The process is not 
scheduled.
IMPORTANT! Debug stepping this deep infrastructure may lock your Image
If you are not sure what you are doing, close the debugger now."
 "Simulation guard"
^Process
forContext: 
[self value.
Processor terminateActive] asContext
priority: Processor activePriority



> On 11 Jan 2020, at 11:06, Ben Coman  wrote:
> 
> 
> 
> On Sat, 11 Jan 2020 at 18:01, ducasse  > wrote:
> 
> 
>> On 11 Jan 2020, at 10:50, Ben Coman > > wrote:
>> 
>> 
>> 
>> On Sat, 11 Jan 2020 at 06:31, Sven Van Caekenberghe > > wrote:
>> Hi Ben,
>> 
>> Great approach, though I would make one change to make your example 
>> completely copy/paste runnable.
>> 
>> Stef's original example:
>> 
>> | trace semaphore p1 p2 |
>> 
>> semaphore := Semaphore new.
>> 
>> trace := [ :message | 
>> ('[{1}] {2}' format: { Processor activeProcess priority. message }) 
>> crLog ].
>> 
>> p1 := [ 
>> semaphore wait.
>> trace value: 'Process 1' ] fork.
>> 
>> p2 := [
>> semaphore signal.
>> trace value: 'Process 2' ] fork.  
>> 
>> trace value: 'Original process pre-yield'.
>> Processor yield.
>> trace value: 'Original process post-yield'.  
>> 
>> Gives:
>> 
>> '[40] Original process pre-yield'
>> '[40] Process 2'
>> '[40] Original process post-yield'
>> '[40] Process 1'
>> 
>> But not running the yield section gives: 
>> 
>> '[40] Process 2'
>> '[40] Process 1'
>> 
>> which is an identical result if the 'Original process' traces are filtered 
>> out.
>> 
>>  
>> From this it would seem that the code in p2 continues after signal and only 
>> later does p1 get past its wait.
>> 
>> Yes, a #signal does not transfer execution unless the waiting-process that 
>> received the signal is a higher priority.
>> Within the same priority, it just makes waiting-process runnable, and the 
>> highest-priority-runnable-process is the one that is run. 
>>  
>> 
>> Playing with the priorities we can change that order (apparently);
>> 
>> | trace semaphore p1 p2 |
>> 
>> semaphore := Semaphore new.
>> 
>> trace := [ :message | 
>> ('[{1}] {2}' format: { Processor activeProcess priority. message }) 
>> crLog ].
>> 
>> p1 := [ 
>> semaphore wait.
>> trace value: 'Process 1' ] forkAt: 30.
>> 
>> p2 := [
>> semaphore signal.
>> trace value: 'Process 2' ] forkAt: 20.  
>> 
>> Gives:
>> 
>> '[30] Process 1'
>> '[20] Process 2'
>> 
>> Again, the yield section makes no difference. So something else happened.
>> 
>> The yield made no difference because it only facilitates other processes 
>> at-the-SAME-priority getting a chance to run.
>> Yield doesn't put the current-process to sleep, it just moves the process to 
>> the back of its-priority-runQueue. It gets to run again before any lower 
>> priority process gets a chance to run.
>> 
>> Yielding will never allow a lower-priority-process to run.  
>> For a lower-priority process to run, the current-process needs to sleep 
>> rather than yield.
> 
> Indeed. I will add this note to my chapter. 
> 
>> 
>> Compare...
>> | trace semaphore p1 p2 |
>> semaphore := Semaphore new.
>> trace := [ :message | ('@{1} {2}' format: { Processor activePriority. 
>> message }) crLog ].
>> p1 := [
>>trace value: 'Process 1a waits for signal on semaphore'. 
>>semaphore wait.
>>trace value: 'Process 1b received signal' ] forkAt: 30.
>> p2 := [
>>trace value: 'Process 2a signals semaphore'. 
>>semaphore signal.
>>trace value: 'Process 2b continues' ] forkAt: 20.
>> trace value: 'Original process pre-yield'.
>> Processor yield.
>> trace value: 'Original process post-yield'. 
>> 
>> ==>
>> '@40 Original process pre-yield'
>> '@40 Original process post-yield'
>> '@30 Process 1a waits for signal on semaphore'
>> '@20 Process 2a signals semaphore'
>> '@30 Process 1b received signal'
>> '@20 Process 2b continues'
>> 
>> with...
>> | trace semaphore p1 p2 |
>> semaphore := Semaphore new.
>> trace := [ :message | ('@{1} {2}' format: { Processor activePriority. 
>> message }) crLog ].
>> p1 := [
>>trace value: 'Process 1a waits for signal on semaphore'. 
>>semaphore wait.
>>trace value: 'Process 1b received signal' ] forkAt: 30.
>> p2 := [
>>trace value: 'Process 2a signals semaphore'. 
>>semaphore signal.
>>trace value: 'Process 2b continues' ] forkAt: 20.
>> trace value: 'Original process pre-delay'.
>> 1 milliSecond wait.
>> trace value: 'Original process post-delay'.   
>> 
>> ==>
>> '@40 Original process pre-delay'
>> '@30 Process 1a waits for signal on semaphore'
>> '@20 Process 2a signals semaphore'
>> '@30 Process 1b received signal'
>> '@20 Process 2b continues'
>> 

Re: [Pharo-dev] about signal

[Ben Coman]

On Sat, 11 Jan 2020 at 18:01, ducasse  wrote:

>
>
> On 11 Jan 2020, at 10:50, Ben Coman  wrote:
>
>
>
> On Sat, 11 Jan 2020 at 06:31, Sven Van Caekenberghe  wrote:
>
>> Hi Ben,
>>
>> Great approach, though I would make one change to make your example
>> completely copy/paste runnable.
>>
>> Stef's original example:
>>
>> | trace semaphore p1 p2 |
>>
>> semaphore := Semaphore new.
>>
>> trace := [ :message |
>> ('[{1}] {2}' format: { Processor activeProcess priority. message
>> }) crLog ].
>>
>> p1 := [
>> semaphore wait.
>> trace value: 'Process 1' ] fork.
>>
>> p2 := [
>> semaphore signal.
>> trace value: 'Process 2' ] fork.
>>
>> trace value: 'Original process pre-yield'.
>> Processor yield.
>> trace value: 'Original process post-yield'.
>>
>> Gives:
>>
>> '[40] Original process pre-yield'
>> '[40] Process 2'
>> '[40] Original process post-yield'
>> '[40] Process 1'
>>
>> But not running the yield section gives:
>
>
>> '[40] Process 2'
>> '[40] Process 1'
>>
>
> which is an identical result if the 'Original process' traces are filtered
> out.
>
>
>
>> From this it would seem that the code in p2 continues after signal and
>> only later does p1 get past its wait.
>>
>
> Yes, a #signal does not transfer execution unless the waiting-process that
> received the signal is a higher priority.
> Within the same priority, it just makes waiting-process runnable, and the
> highest-priority-runnable-process is the one that is run.
>
>
>
> Playing with the priorities we can change that order (apparently);
>>
>> | trace semaphore p1 p2 |
>>
>> semaphore := Semaphore new.
>>
>> trace := [ :message |
>> ('[{1}] {2}' format: { Processor activeProcess priority. message
>> }) crLog ].
>>
>> p1 := [
>> semaphore wait.
>> trace value: 'Process 1' ] forkAt: 30.
>>
>> p2 := [
>> semaphore signal.
>> trace value: 'Process 2' ] forkAt: 20.
>>
>> Gives:
>>
>> '[30] Process 1'
>> '[20] Process 2'
>>
>> Again, the yield section makes no difference. So something else happened.
>>
>
> The yield made no difference because it only facilitates other processes
> at-the-SAME-priority getting a chance to run.
> Yield doesn't put the current-process to sleep, it just moves the process
> to the back of its-priority-runQueue. It gets to run again before any lower
> priority process gets a chance to run.
>
> Yielding will never allow a lower-priority-process to run.
> For a lower-priority process to run, the current-process needs to sleep
> rather than yield.
>
>
> Indeed. I will add this note to my chapter.
>
>
> Compare...
> | trace semaphore p1 p2 |
> semaphore := Semaphore new.
> trace := [ :message | ('@{1} {2}' format: { Processor activePriority.
> message }) crLog ].
> p1 := [
>trace value: 'Process 1a waits for signal on semaphore'.
>semaphore wait.
>trace value: 'Process 1b received signal' ] forkAt: 30.
> p2 := [
>trace value: 'Process 2a signals semaphore'.
>semaphore signal.
>trace value: 'Process 2b continues' ] forkAt: 20.
> trace value: 'Original process pre-yield'.
> Processor yield.
> trace value: 'Original process post-yield'.
>
> ==>
> '@40 Original process pre-yield'
> '@40 Original process post-yield'
> '@30 Process 1a waits for signal on semaphore'
> '@20 Process 2a signals semaphore'
> '@30 Process 1b received signal'
> '@20 Process 2b continues'
>
> with...
> | trace semaphore p1 p2 |
> semaphore := Semaphore new.
> trace := [ :message | ('@{1} {2}' format: { Processor activePriority.
> message }) crLog ].
> p1 := [
>trace value: 'Process 1a waits for signal on semaphore'.
>semaphore wait.
>trace value: 'Process 1b received signal' ] forkAt: 30.
> p2 := [
>trace value: 'Process 2a signals semaphore'.
>semaphore signal.
>trace value: 'Process 2b continues' ] forkAt: 20.
> trace value: 'Original process pre-delay'.
> 1 milliSecond wait.
> trace value: 'Original process post-delay'.
>
> ==>
> '@40 Original process pre-delay'
> '@30 Process 1a waits for signal on semaphore'
> '@20 Process 2a signals semaphore'
> '@30 Process 1b received signal'
> '@20 Process 2b continues'
> '@40 Original process post-delay'
>
>
>
> Stef, on further consideration I think your first examples should not-have
> p1 and p2 the same priority.
> Scheduling of same-priority processes and how they interact with the UI
> thread is an extra level of complexity that may be better done shortly
> after.
>
>
> Yes I realize it.
>
> Not needing to trace "Original process" in the first example gives less
> for the reader to digest
>
>
> Yes I thought the same.
> I thought that I could have the following strategy.
> Give a first simple version, them revisiting it after.
>

At first glance I thought using #fork would a simpler example than using
#forkAt:,
but the former interacts with the implicit priority of existing UI process,
while the latter is explicit and so actually makes a simpler example.

cheers -ben

Re: [Pharo-dev] about signal

[ducasse]

> On 11 Jan 2020, at 10:50, Ben Coman  wrote:
> 
> 
> 
> On Sat, 11 Jan 2020 at 06:31, Sven Van Caekenberghe  > wrote:
> Hi Ben,
> 
> Great approach, though I would make one change to make your example 
> completely copy/paste runnable.
> 
> Stef's original example:
> 
> | trace semaphore p1 p2 |
> 
> semaphore := Semaphore new.
> 
> trace := [ :message | 
> ('[{1}] {2}' format: { Processor activeProcess priority. message }) 
> crLog ].
> 
> p1 := [ 
> semaphore wait.
> trace value: 'Process 1' ] fork.
> 
> p2 := [
> semaphore signal.
> trace value: 'Process 2' ] fork.  
> 
> trace value: 'Original process pre-yield'.
> Processor yield.
> trace value: 'Original process post-yield'.  
> 
> Gives:
> 
> '[40] Original process pre-yield'
> '[40] Process 2'
> '[40] Original process post-yield'
> '[40] Process 1'
> 
> But not running the yield section gives: 
> 
> '[40] Process 2'
> '[40] Process 1'
> 
> which is an identical result if the 'Original process' traces are filtered 
> out.
> 
>  
> From this it would seem that the code in p2 continues after signal and only 
> later does p1 get past its wait.
> 
> Yes, a #signal does not transfer execution unless the waiting-process that 
> received the signal is a higher priority.
> Within the same priority, it just makes waiting-process runnable, and the 
> highest-priority-runnable-process is the one that is run. 
>  
> 
> Playing with the priorities we can change that order (apparently);
> 
> | trace semaphore p1 p2 |
> 
> semaphore := Semaphore new.
> 
> trace := [ :message | 
> ('[{1}] {2}' format: { Processor activeProcess priority. message }) 
> crLog ].
> 
> p1 := [ 
> semaphore wait.
> trace value: 'Process 1' ] forkAt: 30.
> 
> p2 := [
> semaphore signal.
> trace value: 'Process 2' ] forkAt: 20.  
> 
> Gives:
> 
> '[30] Process 1'
> '[20] Process 2'
> 
> Again, the yield section makes no difference. So something else happened.
> 
> The yield made no difference because it only facilitates other processes 
> at-the-SAME-priority getting a chance to run.
> Yield doesn't put the current-process to sleep, it just moves the process to 
> the back of its-priority-runQueue. It gets to run again before any lower 
> priority process gets a chance to run.
> 
> Yielding will never allow a lower-priority-process to run.  
> For a lower-priority process to run, the current-process needs to sleep 
> rather than yield.

Indeed. I will add this note to my chapter. 

> 
> Compare...
> | trace semaphore p1 p2 |
> semaphore := Semaphore new.
> trace := [ :message | ('@{1} {2}' format: { Processor activePriority. message 
> }) crLog ].
> p1 := [
>trace value: 'Process 1a waits for signal on semaphore'. 
>semaphore wait.
>trace value: 'Process 1b received signal' ] forkAt: 30.
> p2 := [
>trace value: 'Process 2a signals semaphore'. 
>semaphore signal.
>trace value: 'Process 2b continues' ] forkAt: 20.
> trace value: 'Original process pre-yield'.
> Processor yield.
> trace value: 'Original process post-yield'. 
> 
> ==>
> '@40 Original process pre-yield'
> '@40 Original process post-yield'
> '@30 Process 1a waits for signal on semaphore'
> '@20 Process 2a signals semaphore'
> '@30 Process 1b received signal'
> '@20 Process 2b continues'
> 
> with...
> | trace semaphore p1 p2 |
> semaphore := Semaphore new.
> trace := [ :message | ('@{1} {2}' format: { Processor activePriority. message 
> }) crLog ].
> p1 := [
>trace value: 'Process 1a waits for signal on semaphore'. 
>semaphore wait.
>trace value: 'Process 1b received signal' ] forkAt: 30.
> p2 := [
>trace value: 'Process 2a signals semaphore'. 
>semaphore signal.
>trace value: 'Process 2b continues' ] forkAt: 20.
> trace value: 'Original process pre-delay'.
> 1 milliSecond wait.
> trace value: 'Original process post-delay'.   
> 
> ==>
> '@40 Original process pre-delay'
> '@30 Process 1a waits for signal on semaphore'
> '@20 Process 2a signals semaphore'
> '@30 Process 1b received signal'
> '@20 Process 2b continues'
> '@40 Original process post-delay'
> 
> 
> 
> Stef, on further consideration I think your first examples should not-have p1 
> and p2 the same priority.
> Scheduling of same-priority processes and how they interact with the UI 
> thread is an extra level of complexity that may be better done shortly after.

Yes I realize it. 
> Not needing to trace "Original process" in the first example gives less for 
> the reader to digest  

Yes I thought the same. 
I thought that I could have the following strategy. 
Give a first simple version, them revisiting it after. 
With the idea that even if the reader meta model is a bit slanted after the 
first example but they get the result right
then after the full explanation they should get it right instead of overhelming 
them with the full details at first. 

So I need to concentrate to have the full outline clear. 

Any way 

Re: [Pharo-dev] about signal

[Ben Coman]

On Sat, 11 Jan 2020 at 06:31, Sven Van Caekenberghe  wrote:

> Hi Ben,
>
> Great approach, though I would make one change to make your example
> completely copy/paste runnable.
>
> Stef's original example:
>
> | trace semaphore p1 p2 |
>
> semaphore := Semaphore new.
>
> trace := [ :message |
> ('[{1}] {2}' format: { Processor activeProcess priority. message
> }) crLog ].
>
> p1 := [
> semaphore wait.
> trace value: 'Process 1' ] fork.
>
> p2 := [
> semaphore signal.
> trace value: 'Process 2' ] fork.
>
> trace value: 'Original process pre-yield'.
> Processor yield.
> trace value: 'Original process post-yield'.
>
> Gives:
>
> '[40] Original process pre-yield'
> '[40] Process 2'
> '[40] Original process post-yield'
> '[40] Process 1'
>
> But not running the yield section gives:


> '[40] Process 2'
> '[40] Process 1'
>

which is an identical result if the 'Original process' traces are filtered
out.



> From this it would seem that the code in p2 continues after signal and
> only later does p1 get past its wait.
>

Yes, a #signal does not transfer execution unless the waiting-process that
received the signal is a higher priority.
Within the same priority, it just makes waiting-process runnable, and the
highest-priority-runnable-process is the one that is run.


Playing with the priorities we can change that order (apparently);
>
> | trace semaphore p1 p2 |
>
> semaphore := Semaphore new.
>
> trace := [ :message |
> ('[{1}] {2}' format: { Processor activeProcess priority. message
> }) crLog ].
>
> p1 := [
> semaphore wait.
> trace value: 'Process 1' ] forkAt: 30.
>
> p2 := [
> semaphore signal.
> trace value: 'Process 2' ] forkAt: 20.
>
> Gives:
>
> '[30] Process 1'
> '[20] Process 2'
>
> Again, the yield section makes no difference. So something else happened.
>

The yield made no difference because it only facilitates other processes
at-the-SAME-priority getting a chance to run.
Yield doesn't put the current-process to sleep, it just moves the process
to the back of its-priority-runQueue. It gets to run again before any lower
priority process gets a chance to run.

Yielding will never allow a lower-priority-process to run.
For a lower-priority process to run, the current-process needs to sleep
rather than yield.

Compare...
| trace semaphore p1 p2 |
semaphore := Semaphore new.
trace := [ :message | ('@{1} {2}' format: { Processor activePriority.
message }) crLog ].
p1 := [
   trace value: 'Process 1a waits for signal on semaphore'.
   semaphore wait.
   trace value: 'Process 1b received signal' ] forkAt: 30.
p2 := [
   trace value: 'Process 2a signals semaphore'.
   semaphore signal.
   trace value: 'Process 2b continues' ] forkAt: 20.
trace value: 'Original process pre-yield'.
Processor yield.
trace value: 'Original process post-yield'.

==>
'@40 Original process pre-yield'
'@40 Original process post-yield'
'@30 Process 1a waits for signal on semaphore'
'@20 Process 2a signals semaphore'
'@30 Process 1b received signal'
'@20 Process 2b continues'

with...
| trace semaphore p1 p2 |
semaphore := Semaphore new.
trace := [ :message | ('@{1} {2}' format: { Processor activePriority.
message }) crLog ].
p1 := [
   trace value: 'Process 1a waits for signal on semaphore'.
   semaphore wait.
   trace value: 'Process 1b received signal' ] forkAt: 30.
p2 := [
   trace value: 'Process 2a signals semaphore'.
   semaphore signal.
   trace value: 'Process 2b continues' ] forkAt: 20.
trace value: 'Original process pre-delay'.
1 milliSecond wait.
trace value: 'Original process post-delay'.

==>
'@40 Original process pre-delay'
'@30 Process 1a waits for signal on semaphore'
'@20 Process 2a signals semaphore'
'@30 Process 1b received signal'
'@20 Process 2b continues'
'@40 Original process post-delay'



Stef, on further consideration I think your first examples should not-have
p1 and p2 the same priority.
Scheduling of same-priority processes and how they interact with the UI
thread is an extra level of complexity that may be better done shortly
after.
Not needing to trace "Original process" in the first example gives less for
the reader to digest

So your first example might compare...
| trace semaphore p1 p2 |
semaphore := Semaphore new.
trace := [ :message | ('@{1} {2}' format: { Processor activePriority.
message }) crLog ].
p1 := [
   trace value: 'Process 1a waits for signal on semaphore'.
   semaphore wait.
   trace value: 'Process 1b received signal' ] forkAt: 20.
p2 := [
   trace value: 'Process 2a signals semaphore'.
   semaphore signal.
   trace value: 'Process 2b continues' ] forkAt: 30.

==>
'@30 Process 1a waits for signal on semaphore'
'@20 Process 2a signals semaphore'
'@30 Process 1b received signal'
'@20 Process 2b continues'


with the priority order swapped...
| trace semaphore p1 p2 |
semaphore := Semaphore new.
trace := [ :message | ('@{1} {2}' format: { Processor activePriority.
message }) crLog ].
p1 := [
   trace value: 

Re: [Pharo-dev] about signal

[ducasse]

>>> 
>>> :)
>> :)
>> 
>> Sometimes I do not know if my humour is strange or not :)
> 
> It is! And you are the only one having that kind of humor ;)

Not sure that we are safe :

https://www.thefarside.com

Just arrived last month and it is super great

Re: [Pharo-dev] about signal

[Norbert Hartl]

> Am 10.01.2020 um 22:32 schrieb ducasse :
> 
> 
>> ducasse wrote
>>> It was so simple that I preferred to do it myself so like that I will look
>>> like a great Pharo contributor. 
>> 
>> :)
> :)
> 
> Sometimes I do not know if my humour is strange or not :)

It is! And you are the only one having that kind of humor ;)

Norbert
> But strange humour is better than no humour :)
> 
> Stef
> 
> PS: I read too many gary larson comics to be safe :)
> 
> 
> 

Re: [Pharo-dev] about signal

[ducasse]

Thanks Sven

I started to use the suggestions of Ben. 
And I’m thinking that I could show my version then step back and explain that 
indeed there is another process (the UI one). 
I will digest your example and produce a new version of the booklet and people 
can give feedback. 

S.

 

> On 10 Jan 2020, at 23:30, Sven Van Caekenberghe  wrote:
> 
> Hi Ben,
> 
> Great approach, though I would make one change to make your example 
> completely copy/paste runnable.
> 
> Stef's original example:
> 
> | trace semaphore p1 p2 |
> 
> semaphore := Semaphore new.
> 
> trace := [ :message | 
>   ('[{1}] {2}' format: { Processor activeProcess priority. message }) 
> crLog ].
> 
> p1 := [ 
>   semaphore wait.
>   trace value: 'Process 1' ] fork.
> 
> p2 := [
>   semaphore signal.
>   trace value: 'Process 2' ] fork.  
> 
> trace value: 'Original process pre-yield'.
> Processor yield.
> trace value: 'Original process post-yield'.  
> 
> Gives:
> 
> '[40] Original process pre-yield'
> '[40] Process 2'
> '[40] Original process post-yield'
> '[40] Process 1'
> 
> But not running the yield section gives:
> 
> '[40] Process 2'
> '[40] Process 1'
> 
> From this it would seem that the code in p2 continues after signal and only 
> later does p1 get past its wait.
> 
> Playing with the priorities we can change that order (apparently);
> 
> | trace semaphore p1 p2 |
> 
> semaphore := Semaphore new.
> 
> trace := [ :message | 
>   ('[{1}] {2}' format: { Processor activeProcess priority. message }) 
> crLog ].
> 
> p1 := [ 
>   semaphore wait.
>   trace value: 'Process 1' ] forkAt: 30.
> 
> p2 := [
>   semaphore signal.
>   trace value: 'Process 2' ] forkAt: 20.  
> 
> Gives:
> 
> '[30] Process 1'
> '[20] Process 2'
> 
> Again, the yield section makes no difference. So something else happened.
> 
> The other way around:
> 
> | trace semaphore p1 p2 |
> 
> semaphore := Semaphore new.
> 
> trace := [ :message | 
>   ('[{1}] {2}' format: { Processor activeProcess priority. message }) 
> crLog ].
> 
> p1 := [ 
>   semaphore wait.
>   trace value: 'Process 1' ] forkAt: 50.
> 
> p2 := [
>   semaphore signal.
>   trace value: 'Process 2' ] forkAt: 60.  
> 
> Gives:
> 
> '[60] Process 2'
> '[50] Process 1'
> 
> Obviously the details about scheduling, order and priorities are really 
> important to understanding this behaviour, and we should be able to explain 
> this is simple terms, so that normal people can use this correctly.
> 
> Sven
> 
>> On 10 Jan 2020, at 19:02, Ben Coman  wrote:
>> 
>> For greater visibility and comprehension, it might be useful to early in the 
>> manual define a utility method...
>> Object>>crTracePriority
>>  self crTrace: '[', Processor activePriority printString, ']', self 
>> printString  
>> 
>> On Fri, 10 Jan 2020 at 13:13, Eliot Miranda  wrote:
>> 
>> 
>> On Thu, Jan 9, 2020 at 5:03 AM ducasse  wrote:
>> Hi
>> 
>> I wanted to explain
>> 
>> | semaphore p1 p2 |
>> semaphore := Semaphore new.
>> p1 := [ semaphore wait.
>>'p1' crTrace ] fork.
>> 
>> p2 := [semaphore signal.
>> 'p2' crTrace ] fork.
>> 
>> displays p2 and p1. 
>> but I would like explain clearly but it depends on the semantics of signal. 
>> 
>> 
>> - ==p1== is scheduled and its execution starts to wait on the semaphore, so 
>> it is removed from the run queue of the scheduler and added to the waiting 
>> list of the semaphore.
>> - ==p2== is scheduled and it signals the semaphore. The semaphore takes the 
>> first waiting process (==p1==) and reschedule it by adding it to the end of 
>> the suspended lists.
>> 
>> Since Smalltalk does not have a preemptive scheduler, neither p1 nor p2 will 
>> start to run until something else happens after the execution of p1 := [...] 
>> fork. p2 := [...] fork. So for example, if there is Processor yield then p1 
>> can start to run.
>> 
>> So you need to add code to your example to be able to determine what will 
>> happen.  The easiest thing would be to delay long enough that both can run.  
>> 1 millisecond is more than enough.
>> 
>> This is a good point.  It may be useful for the example to be expanded to...
>> 
>>| semaphore p1 p2 |
>>semaphore := Semaphore new.
>>p1 := [ semaphore wait.
>>'Process 1' crTracePriority ] fork.
>> 
>>p2 := [semaphore signal.
>> 'Process 2' crTracePriority ] fork.  
>> 
>>'Original process pre-yield' crTracePriority .
>>1 milliSeconds wait.
>>'Original process post-yield' crTracePriority .  
>> 
>> which would produce==>
>> 
>> [40]'Original process pre-yield'
>> [40]'Process 2'
>> [40]'Process 1'
>> [40]'Original process post-yield'
>> 
>> with other examples producing...
>> 
>> [40]'Original process pre-yield'
>> [30]'Process 1'
>> [20]'Process 2'
>> [40]'Original process post-yield'
>> 
>> [60]'Process 2'
>> [50]'Process 1'
>> [40]'Original process pre-yield'
>> [40]'Original process post-yield'
>> 
>> 
>> 
>> Now this sentence "The semaphore 

Re: [Pharo-dev] about signal

[Sven Van Caekenberghe]

Hi Ben,

Great approach, though I would make one change to make your example completely 
copy/paste runnable.

Stef's original example:

| trace semaphore p1 p2 |

semaphore := Semaphore new.

trace := [ :message | 
('[{1}] {2}' format: { Processor activeProcess priority. message }) 
crLog ].

p1 := [ 
semaphore wait.
trace value: 'Process 1' ] fork.

p2 := [
semaphore signal.
trace value: 'Process 2' ] fork.  

trace value: 'Original process pre-yield'.
Processor yield.
trace value: 'Original process post-yield'.  

Gives:

'[40] Original process pre-yield'
'[40] Process 2'
'[40] Original process post-yield'
'[40] Process 1'

But not running the yield section gives:

'[40] Process 2'
'[40] Process 1'

From this it would seem that the code in p2 continues after signal and only 
later does p1 get past its wait.

Playing with the priorities we can change that order (apparently);

| trace semaphore p1 p2 |

semaphore := Semaphore new.

trace := [ :message | 
('[{1}] {2}' format: { Processor activeProcess priority. message }) 
crLog ].

p1 := [ 
semaphore wait.
trace value: 'Process 1' ] forkAt: 30.

p2 := [
semaphore signal.
trace value: 'Process 2' ] forkAt: 20.  

Gives:

'[30] Process 1'
'[20] Process 2'

Again, the yield section makes no difference. So something else happened.

The other way around:

| trace semaphore p1 p2 |

semaphore := Semaphore new.

trace := [ :message | 
('[{1}] {2}' format: { Processor activeProcess priority. message }) 
crLog ].

p1 := [ 
semaphore wait.
trace value: 'Process 1' ] forkAt: 50.

p2 := [
semaphore signal.
trace value: 'Process 2' ] forkAt: 60.  

Gives:

'[60] Process 2'
'[50] Process 1'

Obviously the details about scheduling, order and priorities are really 
important to understanding this behaviour, and we should be able to explain 
this is simple terms, so that normal people can use this correctly.

Sven

> On 10 Jan 2020, at 19:02, Ben Coman  wrote:
> 
> For greater visibility and comprehension, it might be useful to early in the 
> manual define a utility method...
> Object>>crTracePriority
>   self crTrace: '[', Processor activePriority printString, ']', self 
> printString  
> 
> On Fri, 10 Jan 2020 at 13:13, Eliot Miranda  wrote:
> 
> 
> On Thu, Jan 9, 2020 at 5:03 AM ducasse  wrote:
> Hi
> 
> I wanted to explain
> 
> | semaphore p1 p2 |
> semaphore := Semaphore new.
> p1 := [ semaphore wait.
> 'p1' crTrace ] fork.
> 
> p2 := [semaphore signal.
>  'p2' crTrace ] fork.
> 
> displays p2 and p1. 
> but I would like explain clearly but it depends on the semantics of signal. 
> 
> 
> - ==p1== is scheduled and its execution starts to wait on the semaphore, so 
> it is removed from the run queue of the scheduler and added to the waiting 
> list of the semaphore.
> - ==p2== is scheduled and it signals the semaphore. The semaphore takes the 
> first waiting process (==p1==) and reschedule it by adding it to the end of 
> the suspended lists.
> 
> Since Smalltalk does not have a preemptive scheduler, neither p1 nor p2 will 
> start to run until something else happens after the execution of p1 := [...] 
> fork. p2 := [...] fork. So for example, if there is Processor yield then p1 
> can start to run.
> 
> So you need to add code to your example to be able to determine what will 
> happen.  The easiest thing would be to delay long enough that both can run.  
> 1 millisecond is more than enough.
> 
> This is a good point.  It may be useful for the example to be expanded to...
> 
> | semaphore p1 p2 |
> semaphore := Semaphore new.
> p1 := [ semaphore wait.
> 'Process 1' crTracePriority ] fork.
> 
> p2 := [semaphore signal.
>  'Process 2' crTracePriority ] fork.  
>  
> 'Original process pre-yield' crTracePriority .
> 1 milliSeconds wait.
> 'Original process post-yield' crTracePriority .  
>  
> which would produce==>
> 
> [40]'Original process pre-yield'
> [40]'Process 2'
> [40]'Process 1'
> [40]'Original process post-yield'
> 
> with other examples producing...
> 
> [40]'Original process pre-yield'
> [30]'Process 1'
> [20]'Process 2'
> [40]'Original process post-yield'
> 
> [60]'Process 2'
> [50]'Process 1'
> [40]'Original process pre-yield'
> [40]'Original process post-yield'
> 
>  
>  
> Now this sentence "The semaphore takes the first waiting process (==p1==) and 
> reschedule it by adding it to the end of the suspended lists.” is super 
> naive. Is the semaphore signalling scheduled? or not?
> 
> I would say these three things, something like this:
> 
> "A semaphore is a queue (implemented as a linked list) and an excess signals 
> count, which is a non-negative integer.  On instance creation a new semaphore 
> is empty and has a zero excess signals count.  A semaphore created for mutual 
> exclusion is empty and has an excess signals count of one."
> 
> "When a process waits on a 

Re: [Pharo-dev] about signal

[Sven Van Caekenberghe]

Hi Nicolas,

Sure the implementation description is super important, and did not say that. 
All I said is that it is an implementation description and not a high level one.

I just checked the descriptions starting page 257 of the Smalltalk-80 The 
Language book, as well as VisualWorks's 1.0 Cookbook page 1029 - these are of a 
*totally* different, much higher level. That is what we need the most.

Sven

> On 10 Jan 2020, at 18:29, Nicolas Cellier 
>  wrote:
> 
> 
> For example, whether a Semaphore would queue waiting process by order of 
> registration (thru a linked list for example) or by order of priority (thru a 
> Heap for example), would completely change its behavior.
> So isn't that kind of implementation detail SUPER important, especially when 
> hidden in VM?
> 
> Also, describing HOW it works is very often used as a mean to explain (and 
> make understand) a higher level feature.
> IMO, understanding a feature from one implementation is as useful as 
> understanding a feature by examples of usage.
> Even when implementation is plain Smalltalk, it's already an added value to 
> give main guidelines to help reading code (see this particular class or 
> message for understanding the core...), so when it's in VM...
> 
> Le ven. 10 janv. 2020 à 12:59, Danil Osipchuk  a 
> écrit :
> I didn't claim expertise on the subject (although I use semaphores 
> extensively), nor its simplicity, nor that the implementation description 
> should be the only guide on its usage (hence 'to add..., how it works' 
> wording)
> Said that, to me it is the case, when a clear description of what is going on 
> aids a lot. Instead of trying to define some rules and scenarios abstractly - 
> to help a user to reason about the system behavior (isn't Stef was willing to 
> look into VM code for this reason?). 
> 
> To me both scenarios of Stef could be explained that in first case the 
> 'signal' process is not getting preempted by the 'wait' process of the same 
> priority, while in second the preemption happens upon return from primitive 
> (hopefully my memory serves me well and my understanding is correct).
> 
> A tangent note on comments in general -- I've noticed more than once, that 
> people tend to produce far  clearer descriptions in exchanges like this -- 
> when discussing matter with others. 
> When a person is in documentation/comment writing mode he/she is sort of 
> tenses up in a formal state and often produces something not very helpful. 
> Current class comment of Semaphore is a perfect example, if I were not 
> familiar with the concept from other sources, I would not be able to make any 
> sense of it. So, I would suggest to use opportunities like this to improve 
> comments/docs when a bit of knowledge shows up in a discussion.
> 
> 
> 
> regards,
>  Danil
> 
> пт, 10 янв. 2020 г. в 13:09, Sven Van Caekenberghe :
> Actually, it is just a, albeit concise, description of how Semaphores are 
> implemented.
> 
> It does not help much in understanding them, in learning how they can/should 
> be used, for what purposes and how code behaves.
> 
> Understanding of Process, priorities and Scheduling are also needed for a 
> more complete understanding.
> 
> This is not a simple subject.
> 
> Read https://en.wikipedia.org/wiki/Semaphore_(programming) and see how well 
> you understand the subject.
> 
> In short, it does not answer Stef's concrete question(s).
> 
> > On 10 Jan 2020, at 06:30, Danil Osipchuk  wrote:
> > 
> > Maybe to add this into the class comment, this is the most concise and 
> > clear description of how it works i've ever seen
> > 
> > пт, 10 янв. 2020 г., 8:13 Eliot Miranda :
> > 
> > 
> > On Thu, Jan 9, 2020 at 5:03 AM ducasse  wrote:
> > Hi
> > 
> > I wanted to explain
> > 
> > | semaphore p1 p2 |
> > semaphore := Semaphore new.
> > p1 := [ semaphore wait.
> > 'p1' crTrace ] fork.
> > 
> > p2 := [semaphore signal.
> >  'p2' crTrace ] fork.
> > 
> > displays p2 and p1. 
> > but I would like explain clearly but it depends on the semantics of signal. 
> > 
> > 
> > - ==p1== is scheduled and its execution starts to wait on the semaphore, so 
> > it is removed from the run queue of the scheduler and added to the waiting 
> > list of the semaphore.
> > - ==p2== is scheduled and it signals the semaphore. The semaphore takes the 
> > first waiting process (==p1==) and reschedule it by adding it to the end of 
> > the suspended lists.
> > 
> > Since Smalltalk does not have a preemptive scheduler, neither p1 nor p2 
> > will start to run until something else happens after the execution of p1 := 
> > [...] fork. p2 := [...] fork. So for example, if there is Processor yield 
> > then p1 can start to run.
> > 
> > So you need to add code to your example to be able to determine what will 
> > happen.  The easiest thing would be to delay long enough that both can run. 
> >  1 millisecond is more than enough.
> >  
> > Now this sentence "The semaphore takes the first waiting process 

Re: [Pharo-dev] about signal

[Eliot Miranda]

On Fri, Jan 10, 2020 at 2:01 PM Eliot Miranda 
wrote:

> Hi Steph,
>
>
> On Jan 10, 2020, at 12:42 PM, ducasse  wrote:
>
> Yes this is why in my chapter on Exception I show the VM code while some
> people told me that it was not interesting.
> And this is why in the current chapter on semaphore I have a section on
> the implementation.
> Now it does not mean that the we cannot have a higher view too :).
>
>
> Indeed.  Note that now we have two improvements supported by the VM over
> the blue book scheduler & synchronization primitives.
>
>
Oops!  I forgot to mention the other improvement.  That is the ability of
the scheduler to add a process to the front of a particular run queue when
a process is preempted, not to the back of its run queue as is specified
(erroneously) in the original Smalltalk-80 specification.  Why is this
erroneous?

Smalltalk has a real-time preemptive-across-priorities,
cooperative-within-priorities scheduling model.  No process at the same
priority as the active process can preempt the active process.  Instead it
must wait until the active process yields (which moves a process to the
back of its run queue, allowing all other runnable processes at its
priority a chance to run until it will run again), is suspended (on a
semaphore or mutex), or explicitly suspends (via the suspend primitive).
So when the original scheduler puts a process at the end of its run queue
when a higher priority process preempts it that introduces an implicit
yield, which violates the contract, a contract that can be used to
implement cheapjack-free mutual exclusion between processes of the same
priority.

So the improvement, selected by a vm flag, is to cause preemption to add a
process to the front of its run queue, maintaining the order and preserving
the contract.
_,,,^..^,,,_
best, Eliot

Re: [Pharo-dev] about signal

[ducasse]

Thanks ben, this is a nice idea to illustrate what is happening I will use it. 
Thanks for the VM code :). 
I like it too. 

I will add a note also mentioning that indeed there is a process to execute the 
snippets that the reader will write and execute :). 


Stef

PS: what makes me laugh a bit is that people talk about documentation when 
there are nearly none on the topics on which I write. 
I write to be able to fully forget everything and free my brain. I remember 
writing on bloc, exceptions, when there was only obscure  
texts or none as if mail discussions would make a book. At least this is not 
the level I want. 
To me I would like to have a book like Smalltalk and its implementation but 
about Pharo. 
This was a book! So I will write it piece by piece. 



> For greater visibility and comprehension, it might be useful to early in the 
> manual define a utility method...
> Object>>crTracePriority
>   self crTrace: '[', Processor activePriority printString, ']', self 
> printString  
> 
> On Fri, 10 Jan 2020 at 13:13, Eliot Miranda  > wrote:
> 
> 
> On Thu, Jan 9, 2020 at 5:03 AM ducasse  > wrote:
> Hi
> 
> I wanted to explain
> 
> | semaphore p1 p2 |
> semaphore := Semaphore new.
> p1 := [ semaphore wait.
> 'p1' crTrace ] fork.
> 
> p2 := [semaphore signal.
>  'p2' crTrace ] fork.
> 
> displays p2 and p1. 
> but I would like explain clearly but it depends on the semantics of signal. 
> 
> 
> - ==p1== is scheduled and its execution starts to wait on the semaphore, so 
> it is removed from the run queue of the scheduler and added to the waiting 
> list of the semaphore.
> - ==p2== is scheduled and it signals the semaphore. The semaphore takes the 
> first waiting process (==p1==) and reschedule it by adding it to the end of 
> the suspended lists.
> 
> Since Smalltalk does not have a preemptive scheduler, neither p1 nor p2 will 
> start to run until something else happens after the execution of p1 := [...] 
> fork. p2 := [...] fork. So for example, if there is Processor yield then p1 
> can start to run.
> 
> So you need to add code to your example to be able to determine what will 
> happen.  The easiest thing would be to delay long enough that both can run.  
> 1 millisecond is more than enough.
> 
> This is a good point.  It may be useful for the example to be expanded to...
> 
> | semaphore p1 p2 |
> semaphore := Semaphore new.
> p1 := [ semaphore wait.
> 'Process 1' crTracePriority ] fork.
> 
> p2 := [semaphore signal.
>  'Process 2' crTracePriority ] fork.  
>  
> 'Original process pre-yield' crTracePriority .
> 1 milliSeconds wait.
> 'Original process post-yield' crTracePriority .  
>  
> which would produce==>
> 
> [40]'Original process pre-yield'
> [40]'Process 2'
> [40]'Process 1'
> [40]'Original process post-yield'
> 
> with other examples producing...
> 
> [40]'Original process pre-yield'
> [30]'Process 1'
> [20]'Process 2'
> [40]'Original process post-yield'
> 
> [60]'Process 2'
> [50]'Process 1'
> [40]'Original process pre-yield'
> [40]'Original process post-yield'
> 
>  
>  
> Now this sentence "The semaphore takes the first waiting process (==p1==) and 
> reschedule it by adding it to the end of the suspended lists.” is super 
> naive. Is the semaphore signalling scheduled? or not?
> 
> I would say these three things, something like this:
> 
> "A semaphore is a queue (implemented as a linked list) and an excess signals 
> count, which is a non-negative integer.  On instance creation a new semaphore 
> is empty and has a zero excess signals count.  A semaphore created for mutual 
> exclusion is empty and has an excess signals count of one."
> 
> "When a process waits on a semaphore, if the semaphore's excess signals count 
> is non-zero, then the excess signal count is decremented, and the process 
> proceeds.  But if the semaphore has a zero excess signals count then the 
> process is unscheduled and added to the end of the semaphore, after any other 
> processes that are queued on the semaphore."
> 
> "When a semaphore is signaled, if it is not empty, the first process is 
> removed from it and added to the runnable processes in the scheduler. If the 
> semaphore is empty its excess signals count is incremented.
> 
> Given these three statements it is easy to see how they work, how to use them 
> for mutual exclusion, etc.
> 
> 
> 
> signal
> "Primitive. Send a signal through the receiver. If one or more 
> processes 
> have been suspended trying to receive a signal, allow the first one 
> to 
> proceed. If no process is waiting, remember the excess signal. 
> Essential. 
> See Object documentation whatIsAPrimitive."
> 
> 
> self primitiveFailed
> 
> "self isEmpty
> ifTrue: [excessSignals := excessSignals+1]
> ifFalse: [Processor resume: self removeFirstLink]"

Re: [Pharo-dev] about signal

[Eliot Miranda]

Hi Steph,


On Jan 10, 2020, at 12:42 PM, ducasse  wrote:

Yes this is why in my chapter on Exception I show the VM code while some
people told me that it was not interesting.
And this is why in the current chapter on semaphore I have a section on the
implementation.
Now it does not mean that the we cannot have a higher view too :).


Indeed.  Note that now we have two improvements supported by the VM over
the blue book scheduler & synchronization primitives.

First we have a native critical section which is not a queuing semaphore,
but a queueing lock, which is in one of three states. It is a replacement
for the old Mutex class.  It is not in Pharo yet but you can easily adapt
the Squeak implementation (see below). Let me give a similar definition.

A native critical section is a queue that can have an owner.  A new native
critical section is empty and unowned.

A process attempts to enter the native critical section via
primitiveEnterCriticalSection. This occurs in one of three ways.
- If the native critical section is unowned (which implies it is empty)
then the process becomes the owner of the native critical section, the
primitive answers false (meaning that it was previously unowned or owned by
some other process), and the process proceeds.
- if the native critical section is already owned by the process then the
process remains the owner, the primitive answers true (meaning that it is
already owned) and the process proceeds.
- if the native critical section is already owned by some other process
then the process is suspended and added to the end of the native critical
section‘s queue, where it will wait until a primitiveExitCriticalSection
resumes it and makes it owner.

A process leaves a native critical section via
primitiveExitCriticalSection.  It is the process's responsibility to use
primitiveExitCriticalSection only when it entered via a
primitiveEnterCriticalSection that answered false.  If the native critical
section is empty then on executing primitiveExitCriticalSection it becomes
unowned.  If the native critical section is not empty then on executing
primitiveExitCriticalSection it becomes owned by the first process in its
queue, the process is removed from the queue and is scheduled, proceeding
from the primitiveEnterCriticalSection which caused it to block with
primitiveEnterCriticalSection answering false.

In addition a process may test and set its ownership of a native critical
section without danger of blocking.  A process tests and sets its ownership
of a native critical section via
primitiveTestAndSetOwnershipOfCriticalSection.  On executing
primitiveTestAndSetOwnershipOfCriticalSection, if the native critical
section is unowned then the process becomes its owner and
primitiveTestAndSetOwnershipOfCriticalSection answers false.  If the native
critical section is owned  by the process
primitiveTestAndSetOwnershipOfCriticalSection answers true.  If the native
critical section is owned by some other process then
primitiveTestAndSetOwnershipOfCriticalSection answers nil.

Using primitiveExitCriticalSection and primitiveExitCriticalSection allows
for efficient implemntation of rentrant critical sections:

critical: aBlock
"Evaluate aBlock protected by the receiver."

^self primitiveEnterCriticalSection
ifTrue: [aBlock value]
ifFalse: [aBlock ensure: [self primitiveExitCriticalSection]]

Adding primitiveTestAndSetOwnershipOfCriticalSection makes it easy to
implement and understand the following:

critical: aBlock ifLocked: lockedBlock
"Answer the evaluation of aBlock protected by the receiver.  If it is
already in a critical
section on behalf of some other process answer the evaluation of
lockedBlock."

^self primitiveTestAndSetOwnershipOfCriticalSection
ifNil: [lockedBlock value]
ifNotNil:
[:alreadyOwner|
alreadyOwner
ifTrue: [aBlock value]
ifFalse: [aBlock ensure: [self primitiveExitCriticalSection]]]

Once a process owns a critical section it can enter the criutical section
as many times as it wants.  With the Semaphore it can only enter once per
signal.  Of course we have constructed the class Mutex to operate similarly
to a native critical section, but it is inefficient and not entirely safe
(because we rely on implementation-defined behaviour to be able to assign
the Mutex's owner without being preempted.

In Squeak we already replaced the old Mutex with a Mutex built using the
native crittical section reoresentation and primitives.  The file-in is
attached.  An implementation note is that semaphores and native crtitical
sections look very similar; they are both queues so their first and second
and  instance variables are firstLink & lastLink, inherited from
LinkedList.  A Semaphore's third inst var is excessSignals, its excess
signals count.  A Mutex's third inst var is is owner.

HTH

P.S.
This is an interesting exercise.  What we have done in specifying behavior
here is focus on processes.  The documentation on the primitive methods in
the system focus on the semaphore or 

Re: [Pharo-dev] about signal

[ducasse]

> ducasse wrote
>> It was so simple that I preferred to do it myself so like that I will look
>> like a great Pharo contributor. 
> 
> :)
:)

Sometimes I do not know if my humour is strange or not :)
But strange humour is better than no humour :)

Stef

PS: I read too many gary larson comics to be safe :)

Re: [Pharo-dev] about signal

[Sean P. DeNigris]

ducasse wrote
> It was so simple that I preferred to do it myself so like that I will look
> like a great Pharo contributor. 

:)



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

Re: [Pharo-dev] about signal

[ducasse]

Yes this is why in my chapter on Exception I show the VM code while some people 
told me that it was not interesting. 
And this is why in the current chapter on semaphore I have a section on the 
implementation. 
Now it does not mean that the we cannot have a higher view too :). 

> On 10 Jan 2020, at 18:29, Nicolas Cellier 
>  wrote:
> 
> 
> For example, whether a Semaphore would queue waiting process by order of 
> registration (thru a linked list for example) or by order of priority (thru a 
> Heap for example), would completely change its behavior.
> So isn't that kind of implementation detail SUPER important, especially when 
> hidden in VM?
> 
> Also, describing HOW it works is very often used as a mean to explain (and 
> make understand) a higher level feature.
> IMO, understanding a feature from one implementation is as useful as 
> understanding a feature by examples of usage.
> Even when implementation is plain Smalltalk, it's already an added value to 
> give main guidelines to help reading code (see this particular class or 
> message for understanding the core...), so when it's in VM...
> 
> Le ven. 10 janv. 2020 à 12:59, Danil Osipchuk  > a écrit :
> I didn't claim expertise on the subject (although I use semaphores 
> extensively), nor its simplicity, nor that the implementation description 
> should be the only guide on its usage (hence 'to add..., how it works' 
> wording)
> Said that, to me it is the case, when a clear description of what is going on 
> aids a lot. Instead of trying to define some rules and scenarios abstractly - 
> to help a user to reason about the system behavior (isn't Stef was willing to 
> look into VM code for this reason?). 
> 
> To me both scenarios of Stef could be explained that in first case the 
> 'signal' process is not getting preempted by the 'wait' process of the same 
> priority, while in second the preemption happens upon return from primitive 
> (hopefully my memory serves me well and my understanding is correct).
> 
> A tangent note on comments in general -- I've noticed more than once, that 
> people tend to produce far  clearer descriptions in exchanges like this -- 
> when discussing matter with others. 
> When a person is in documentation/comment writing mode he/she is sort of 
> tenses up in a formal state and often produces something not very helpful. 
> Current class comment of Semaphore is a perfect example, if I were not 
> familiar with the concept from other sources, I would not be able to make any 
> sense of it. So, I would suggest to use opportunities like this to improve 
> comments/docs when a bit of knowledge shows up in a discussion.
> 
> 
> 
> regards,
>  Danil
> 
> пт, 10 янв. 2020 г. в 13:09, Sven Van Caekenberghe  >:
> Actually, it is just a, albeit concise, description of how Semaphores are 
> implemented.
> 
> It does not help much in understanding them, in learning how they can/should 
> be used, for what purposes and how code behaves.
> 
> Understanding of Process, priorities and Scheduling are also needed for a 
> more complete understanding.
> 
> This is not a simple subject.
> 
> Read https://en.wikipedia.org/wiki/Semaphore_(programming) 
>  and see how well you 
> understand the subject.
> 
> In short, it does not answer Stef's concrete question(s).
> 
> > On 10 Jan 2020, at 06:30, Danil Osipchuk  > > wrote:
> > 
> > Maybe to add this into the class comment, this is the most concise and 
> > clear description of how it works i've ever seen
> > 
> > пт, 10 янв. 2020 г., 8:13 Eliot Miranda  > >:
> > 
> > 
> > On Thu, Jan 9, 2020 at 5:03 AM ducasse  > > wrote:
> > Hi
> > 
> > I wanted to explain
> > 
> > | semaphore p1 p2 |
> > semaphore := Semaphore new.
> > p1 := [ semaphore wait.
> > 'p1' crTrace ] fork.
> > 
> > p2 := [semaphore signal.
> >  'p2' crTrace ] fork.
> > 
> > displays p2 and p1. 
> > but I would like explain clearly but it depends on the semantics of signal. 
> > 
> > 
> > - ==p1== is scheduled and its execution starts to wait on the semaphore, so 
> > it is removed from the run queue of the scheduler and added to the waiting 
> > list of the semaphore.
> > - ==p2== is scheduled and it signals the semaphore. The semaphore takes the 
> > first waiting process (==p1==) and reschedule it by adding it to the end of 
> > the suspended lists.
> > 
> > Since Smalltalk does not have a preemptive scheduler, neither p1 nor p2 
> > will start to run until something else happens after the execution of p1 := 
> > [...] fork. p2 := [...] fork. So for example, if there is Processor yield 
> > then p1 can start to run.
> > 
> > So you need to add code to your example to be able to determine what will 
> > happen.  The easiest thing would be to delay long enough that both can run. 
> >  1 millisecond is 

Re: [Pharo-dev] about signal

[ducasse]

Done. 

https://github.com/pharo-project/pharo/issues/5466

It was so simple that I preferred to do it myself so like that I will look like 
a great Pharo contributor. 





> On 10 Jan 2020, at 06:30, Danil Osipchuk  wrote:
> 
> Maybe to add this into the class comment, this is the most concise and clear 
> description of how it works i've ever seen
> 
> пт, 10 янв. 2020 г., 8:13 Eliot Miranda  >:
> 
> 
> On Thu, Jan 9, 2020 at 5:03 AM ducasse  > wrote:
> Hi
> 
> I wanted to explain
> 
> | semaphore p1 p2 |
> semaphore := Semaphore new.
> p1 := [ semaphore wait.
> 'p1' crTrace ] fork.
> 
> p2 := [semaphore signal.
>  'p2' crTrace ] fork.
> 
> displays p2 and p1. 
> but I would like explain clearly but it depends on the semantics of signal. 
> 
> 
> - ==p1== is scheduled and its execution starts to wait on the semaphore, so 
> it is removed from the run queue of the scheduler and added to the waiting 
> list of the semaphore.
> - ==p2== is scheduled and it signals the semaphore. The semaphore takes the 
> first waiting process (==p1==) and reschedule it by adding it to the end of 
> the suspended lists.
> 
> Since Smalltalk does not have a preemptive scheduler, neither p1 nor p2 will 
> start to run until something else happens after the execution of p1 := [...] 
> fork. p2 := [...] fork. So for example, if there is Processor yield then p1 
> can start to run.
> 
> So you need to add code to your example to be able to determine what will 
> happen.  The easiest thing would be to delay long enough that both can run.  
> 1 millisecond is more than enough.
>  
> Now this sentence "The semaphore takes the first waiting process (==p1==) and 
> reschedule it by adding it to the end of the suspended lists.” is super 
> naive. Is the semaphore signalling scheduled? or not?
> 
> I would say these three things, something like this:
> 
> "A semaphore is a queue (implemented as a linked list) and an excess signals 
> count, which is a non-negative integer.  On instance creation a new semaphore 
> is empty and has a zero excess signals count.  A semaphore created for mutual 
> exclusion is empty and has an excess signals count of one."
> 
> "When a process waits on a semaphore, if the semaphore's excess signals count 
> is non-zero, then the excess signal count is decremented, and the process 
> proceeds.  But if the semaphore has a zero excess signals count then the 
> process is unscheduled and added to the end of the semaphore, after any other 
> processes that are queued on the semaphore."
> 
> "When a semaphore is signaled, if it is not empty, the first process is 
> removed from it and added to the runnable processes in the scheduler. If the 
> semaphore is empty its excess signals count is incremented.
> 
> Given these three statements it is easy to see how they work, how to use them 
> for mutual exclusion, etc.
> 
> 
> 
> signal
> "Primitive. Send a signal through the receiver. If one or more 
> processes 
> have been suspended trying to receive a signal, allow the first one 
> to 
> proceed. If no process is waiting, remember the excess signal. 
> Essential. 
> See Object documentation whatIsAPrimitive."
> 
> 
> self primitiveFailed
> 
> "self isEmpty
> ifTrue: [excessSignals := excessSignals+1]
> ifFalse: [Processor resume: self removeFirstLink]"
> 
> 
> I wanted to know what is really happening when a semaphore is signalled. 
> Now resume: does not exist on Processor. 
> 
> I will look in the VM code. 
> 
> 
> S
> 
> 
> 
> 
> 
> S.
> 
> 
> 
> -- 
> _,,,^..^,,,_
> best, Eliot

Re: [Pharo-dev] about signal

[Ben Coman]

For greater visibility and comprehension, it might be useful to early in
the manual define a utility method...
Object>>crTracePriority
  self crTrace: '[', Processor activePriority printString, ']', self
printString

On Fri, 10 Jan 2020 at 13:13, Eliot Miranda  wrote:

>
>
> On Thu, Jan 9, 2020 at 5:03 AM ducasse  wrote:
>
>> Hi
>>
>> I wanted to explain
>>
>> | semaphore p1 p2 |
>> semaphore := Semaphore new.
>> p1 := [ semaphore wait.
>> 'p1' crTrace ] fork.
>>
>> p2 := [semaphore signal.
>>  'p2' crTrace ] fork.
>>
>> displays p2 and p1.
>> but I would like explain clearly but it depends on the semantics of
>> signal.
>>
>>
>> - ==p1== is scheduled and its execution starts to wait on the semaphore,
>> so it is removed from the run queue of the scheduler and added to the
>> waiting list of the semaphore.
>> - ==p2== is scheduled and it signals the semaphore. The semaphore takes
>> the first waiting process (==p1==) and reschedule it by adding it to the
>> end of the suspended lists.
>>
>
> Since Smalltalk does not have a preemptive scheduler, neither p1 nor p2
> will start to run until something else happens after the execution of p1 :=
> [...] fork. p2 := [...] fork. So for example, if there is Processor yield
> then p1 can start to run.
>

> So you need to add code to your example to be able to determine what will
> happen.  The easiest thing would be to delay long enough that both can run.
>  1 millisecond is more than enough.
>

This is a good point.  It may be useful for the example to be expanded to...

| semaphore p1 p2 |
semaphore := Semaphore new.
p1 := [ semaphore wait.
'Process 1' crTracePriority ] fork.

p2 := [semaphore signal.
 'Process 2' crTracePriority ] fork.

'Original process pre-yield' crTracePriority .
1 milliSeconds wait.
'Original process post-yield' crTracePriority .

which would produce==>

[40]'Original process pre-yield'
[40]'Process 2'
[40]'Process 1'
[40]'Original process post-yield'

with other examples producing...

[40]'Original process pre-yield'
[30]'Process 1'
[20]'Process 2'
[40]'Original process post-yield'

[60]'Process 2'
[50]'Process 1'
[40]'Original process pre-yield'
[40]'Original process post-yield'



>
>
>> Now this sentence "The semaphore takes the first waiting process (==p1==)
>> and reschedule it by adding it to the end of the suspended lists.” is super
>> naive. Is the semaphore signalling scheduled? or not?
>>
>
> I would say these three things, something like this:
>
> "A semaphore is a queue (implemented as a linked list) and an excess
> signals count, which is a non-negative integer.  On instance creation a new
> semaphore is empty and has a zero excess signals count.  A semaphore
> created for mutual exclusion is empty and has an excess signals count of
> one."
>
> "When a process waits on a semaphore, if the semaphore's excess signals
> count is non-zero, then the excess signal count is decremented, and the
> process proceeds.  But if the semaphore has a zero excess signals count
> then the process is unscheduled and added to the end of the semaphore,
> after any other processes that are queued on the semaphore."
>
> "When a semaphore is signaled, if it is not empty, the first process is
> removed from it and added to the runnable processes in the scheduler. If
> the semaphore is empty its excess signals count is incremented.
>
> Given these three statements it is easy to see how they work, how to use
> them for mutual exclusion, etc.
>
>
>>
>> signal
>> "Primitive. Send a signal through the receiver. If one or more
>> processes
>> have been suspended trying to receive a signal, allow the first
>> one to
>> proceed. If no process is waiting, remember the excess signal.
>> Essential.
>> See Object documentation whatIsAPrimitive."
>>
>> 
>> self primitiveFailed
>>
>> "self isEmpty
>> ifTrue: [excessSignals := excessSignals+1]
>> ifFalse: [Processor resume: self removeFirstLink]"
>>
>>
>> I wanted to know what is really happening when a semaphore is signalled.
>> Now resume: does not exist on Processor.
>>
>> I will look in the VM code.
>>
>>
For quick reference, here is some relevant VM code (the StackInterpreter
code is a little simpler...)

https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/pharo/headless/smalltalksrc/VMMaker/StackInterpreter.class.st#L1422-L1432

StackInterpreter class >> initializePrimitiveTable [
...
"Control Primitives (80-89)"
(85 primitiveSignal)
(86 primitiveWait)
...
]

https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/pharo/headless/smalltalksrc/VMMaker/InterpreterPrimitives.class.st#L5385-L5396

InterpreterPrimitives >> primitiveWait [
| sema excessSignals activeProc |
sema := self stackTop.  "rcvr"
excessSignals := self fetchInteger: ExcessSignalsIndex ofObject: sema.
excessSignals > 0
ifTrue:
[self storeInteger: 

Re: [Pharo-dev] about signal

[Nicolas Cellier]

For example, whether a Semaphore would queue waiting process by order of
registration (thru a linked list for example) or by order of priority (thru
a Heap for example), would completely change its behavior.
So isn't that kind of implementation detail SUPER important, especially
when hidden in VM?

Also, describing HOW it works is very often used as a mean to explain (and
make understand) a higher level feature.
IMO, understanding a feature from one implementation is as useful as
understanding a feature by examples of usage.
Even when implementation is plain Smalltalk, it's already an added value to
give main guidelines to help reading code (see this particular class or
message for understanding the core...), so when it's in VM...

Le ven. 10 janv. 2020 à 12:59, Danil Osipchuk  a
écrit :

> I didn't claim expertise on the subject (although I use semaphores
> extensively), nor its simplicity, nor that the implementation description
> should be the only guide on its usage (hence 'to add..., how it works'
> wording)
> Said that, to me it is the case, when a clear description of what is going
> on aids a lot. Instead of trying to define some rules and scenarios
> abstractly - to help a user to reason about the system behavior (isn't Stef
> was willing to look into VM code for this reason?).
>
> To me both scenarios of Stef could be explained that in first case the
> 'signal' process is not getting preempted by the 'wait' process of the same
> priority, while in second the preemption happens upon return from primitive
> (hopefully my memory serves me well and my understanding is correct).
>
> A tangent note on comments in general -- I've noticed more than once, that
> people tend to produce far  clearer descriptions in exchanges like this --
> when discussing matter with others.
> When a person is in documentation/comment writing mode he/she is sort of
> tenses up in a formal state and often produces something not very helpful.
> Current class comment of Semaphore is a perfect example, if I were not
> familiar with the concept from other sources, I would not be able to make
> any sense of it. So, I would suggest to use opportunities like this to
> improve comments/docs when a bit of knowledge shows up in a discussion.
>
>
>
> regards,
>  Danil
>
> пт, 10 янв. 2020 г. в 13:09, Sven Van Caekenberghe :
>
>> Actually, it is just a, albeit concise, description of how Semaphores are
>> implemented.
>>
>> It does not help much in understanding them, in learning how they
>> can/should be used, for what purposes and how code behaves.
>>
>> Understanding of Process, priorities and Scheduling are also needed for a
>> more complete understanding.
>>
>> This is not a simple subject.
>>
>> Read https://en.wikipedia.org/wiki/Semaphore_(programming) and see how
>> well you understand the subject.
>>
>> In short, it does not answer Stef's concrete question(s).
>>
>> > On 10 Jan 2020, at 06:30, Danil Osipchuk 
>> wrote:
>> >
>> > Maybe to add this into the class comment, this is the most concise and
>> clear description of how it works i've ever seen
>> >
>> > пт, 10 янв. 2020 г., 8:13 Eliot Miranda :
>> >
>> >
>> > On Thu, Jan 9, 2020 at 5:03 AM ducasse 
>> wrote:
>> > Hi
>> >
>> > I wanted to explain
>> >
>> > | semaphore p1 p2 |
>> > semaphore := Semaphore new.
>> > p1 := [ semaphore wait.
>> > 'p1' crTrace ] fork.
>> >
>> > p2 := [semaphore signal.
>> >  'p2' crTrace ] fork.
>> >
>> > displays p2 and p1.
>> > but I would like explain clearly but it depends on the semantics of
>> signal.
>> >
>> >
>> > - ==p1== is scheduled and its execution starts to wait on the
>> semaphore, so it is removed from the run queue of the scheduler and added
>> to the waiting list of the semaphore.
>> > - ==p2== is scheduled and it signals the semaphore. The semaphore takes
>> the first waiting process (==p1==) and reschedule it by adding it to the
>> end of the suspended lists.
>> >
>> > Since Smalltalk does not have a preemptive scheduler, neither p1 nor p2
>> will start to run until something else happens after the execution of p1 :=
>> [...] fork. p2 := [...] fork. So for example, if there is Processor yield
>> then p1 can start to run.
>> >
>> > So you need to add code to your example to be able to determine what
>> will happen.  The easiest thing would be to delay long enough that both can
>> run.  1 millisecond is more than enough.
>> >
>> > Now this sentence "The semaphore takes the first waiting process
>> (==p1==) and reschedule it by adding it to the end of the suspended lists.”
>> is super naive. Is the semaphore signalling scheduled? or not?
>> >
>> > I would say these three things, something like this:
>> >
>> > "A semaphore is a queue (implemented as a linked list) and an excess
>> signals count, which is a non-negative integer.  On instance creation a new
>> semaphore is empty and has a zero excess signals count.  A semaphore
>> created for mutual exclusion is empty and has an excess signals count of
>> one."
>> 

Re: [Pharo-dev] about signal

[Danil Osipchuk]

I didn't claim expertise on the subject (although I use semaphores
extensively), nor its simplicity, nor that the implementation description
should be the only guide on its usage (hence 'to add..., how it works'
wording)
Said that, to me it is the case, when a clear description of what is going
on aids a lot. Instead of trying to define some rules and scenarios
abstractly - to help a user to reason about the system behavior (isn't Stef
was willing to look into VM code for this reason?).

To me both scenarios of Stef could be explained that in first case the
'signal' process is not getting preempted by the 'wait' process of the same
priority, while in second the preemption happens upon return from primitive
(hopefully my memory serves me well and my understanding is correct).

A tangent note on comments in general -- I've noticed more than once, that
people tend to produce far  clearer descriptions in exchanges like this --
when discussing matter with others.
When a person is in documentation/comment writing mode he/she is sort of
tenses up in a formal state and often produces something not very helpful.
Current class comment of Semaphore is a perfect example, if I were not
familiar with the concept from other sources, I would not be able to make
any sense of it. So, I would suggest to use opportunities like this to
improve comments/docs when a bit of knowledge shows up in a discussion.



regards,
 Danil

пт, 10 янв. 2020 г. в 13:09, Sven Van Caekenberghe :

> Actually, it is just a, albeit concise, description of how Semaphores are
> implemented.
>
> It does not help much in understanding them, in learning how they
> can/should be used, for what purposes and how code behaves.
>
> Understanding of Process, priorities and Scheduling are also needed for a
> more complete understanding.
>
> This is not a simple subject.
>
> Read https://en.wikipedia.org/wiki/Semaphore_(programming) and see how
> well you understand the subject.
>
> In short, it does not answer Stef's concrete question(s).
>
> > On 10 Jan 2020, at 06:30, Danil Osipchuk 
> wrote:
> >
> > Maybe to add this into the class comment, this is the most concise and
> clear description of how it works i've ever seen
> >
> > пт, 10 янв. 2020 г., 8:13 Eliot Miranda :
> >
> >
> > On Thu, Jan 9, 2020 at 5:03 AM ducasse  wrote:
> > Hi
> >
> > I wanted to explain
> >
> > | semaphore p1 p2 |
> > semaphore := Semaphore new.
> > p1 := [ semaphore wait.
> > 'p1' crTrace ] fork.
> >
> > p2 := [semaphore signal.
> >  'p2' crTrace ] fork.
> >
> > displays p2 and p1.
> > but I would like explain clearly but it depends on the semantics of
> signal.
> >
> >
> > - ==p1== is scheduled and its execution starts to wait on the semaphore,
> so it is removed from the run queue of the scheduler and added to the
> waiting list of the semaphore.
> > - ==p2== is scheduled and it signals the semaphore. The semaphore takes
> the first waiting process (==p1==) and reschedule it by adding it to the
> end of the suspended lists.
> >
> > Since Smalltalk does not have a preemptive scheduler, neither p1 nor p2
> will start to run until something else happens after the execution of p1 :=
> [...] fork. p2 := [...] fork. So for example, if there is Processor yield
> then p1 can start to run.
> >
> > So you need to add code to your example to be able to determine what
> will happen.  The easiest thing would be to delay long enough that both can
> run.  1 millisecond is more than enough.
> >
> > Now this sentence "The semaphore takes the first waiting process
> (==p1==) and reschedule it by adding it to the end of the suspended lists.”
> is super naive. Is the semaphore signalling scheduled? or not?
> >
> > I would say these three things, something like this:
> >
> > "A semaphore is a queue (implemented as a linked list) and an excess
> signals count, which is a non-negative integer.  On instance creation a new
> semaphore is empty and has a zero excess signals count.  A semaphore
> created for mutual exclusion is empty and has an excess signals count of
> one."
> >
> > "When a process waits on a semaphore, if the semaphore's excess signals
> count is non-zero, then the excess signal count is decremented, and the
> process proceeds.  But if the semaphore has a zero excess signals count
> then the process is unscheduled and added to the end of the semaphore,
> after any other processes that are queued on the semaphore."
> >
> > "When a semaphore is signaled, if it is not empty, the first process is
> removed from it and added to the runnable processes in the scheduler. If
> the semaphore is empty its excess signals count is incremented.
> >
> > Given these three statements it is easy to see how they work, how to use
> them for mutual exclusion, etc.
> >
> >
> >
> > signal
> > "Primitive. Send a signal through the receiver. If one or more
> processes
> > have been suspended trying to receive a signal, allow the first
> one to
> > proceed. If no process 

Re: [Pharo-dev] about signal

[Sven Van Caekenberghe]

Actually, it is just a, albeit concise, description of how Semaphores are 
implemented.

It does not help much in understanding them, in learning how they can/should be 
used, for what purposes and how code behaves.

Understanding of Process, priorities and Scheduling are also needed for a more 
complete understanding.

This is not a simple subject.

Read https://en.wikipedia.org/wiki/Semaphore_(programming) and see how well you 
understand the subject.

In short, it does not answer Stef's concrete question(s).

> On 10 Jan 2020, at 06:30, Danil Osipchuk  wrote:
> 
> Maybe to add this into the class comment, this is the most concise and clear 
> description of how it works i've ever seen
> 
> пт, 10 янв. 2020 г., 8:13 Eliot Miranda :
> 
> 
> On Thu, Jan 9, 2020 at 5:03 AM ducasse  wrote:
> Hi
> 
> I wanted to explain
> 
> | semaphore p1 p2 |
> semaphore := Semaphore new.
> p1 := [ semaphore wait.
> 'p1' crTrace ] fork.
> 
> p2 := [semaphore signal.
>  'p2' crTrace ] fork.
> 
> displays p2 and p1. 
> but I would like explain clearly but it depends on the semantics of signal. 
> 
> 
> - ==p1== is scheduled and its execution starts to wait on the semaphore, so 
> it is removed from the run queue of the scheduler and added to the waiting 
> list of the semaphore.
> - ==p2== is scheduled and it signals the semaphore. The semaphore takes the 
> first waiting process (==p1==) and reschedule it by adding it to the end of 
> the suspended lists.
> 
> Since Smalltalk does not have a preemptive scheduler, neither p1 nor p2 will 
> start to run until something else happens after the execution of p1 := [...] 
> fork. p2 := [...] fork. So for example, if there is Processor yield then p1 
> can start to run.
> 
> So you need to add code to your example to be able to determine what will 
> happen.  The easiest thing would be to delay long enough that both can run.  
> 1 millisecond is more than enough.
>  
> Now this sentence "The semaphore takes the first waiting process (==p1==) and 
> reschedule it by adding it to the end of the suspended lists.” is super 
> naive. Is the semaphore signalling scheduled? or not?
> 
> I would say these three things, something like this:
> 
> "A semaphore is a queue (implemented as a linked list) and an excess signals 
> count, which is a non-negative integer.  On instance creation a new semaphore 
> is empty and has a zero excess signals count.  A semaphore created for mutual 
> exclusion is empty and has an excess signals count of one."
> 
> "When a process waits on a semaphore, if the semaphore's excess signals count 
> is non-zero, then the excess signal count is decremented, and the process 
> proceeds.  But if the semaphore has a zero excess signals count then the 
> process is unscheduled and added to the end of the semaphore, after any other 
> processes that are queued on the semaphore."
> 
> "When a semaphore is signaled, if it is not empty, the first process is 
> removed from it and added to the runnable processes in the scheduler. If the 
> semaphore is empty its excess signals count is incremented.
> 
> Given these three statements it is easy to see how they work, how to use them 
> for mutual exclusion, etc.
> 
> 
> 
> signal
> "Primitive. Send a signal through the receiver. If one or more 
> processes 
> have been suspended trying to receive a signal, allow the first one 
> to 
> proceed. If no process is waiting, remember the excess signal. 
> Essential. 
> See Object documentation whatIsAPrimitive."
> 
> 
> self primitiveFailed
> 
> "self isEmpty
> ifTrue: [excessSignals := excessSignals+1]
> ifFalse: [Processor resume: self removeFirstLink]"
> 
> 
> I wanted to know what is really happening when a semaphore is signalled. 
> Now resume: does not exist on Processor. 
> 
> I will look in the VM code. 
> 
> 
> S
> 
> 
> 
> 
> 
> S.
> 
> 
> 
> -- 
> _,,,^..^,,,_
> best, Eliot

Re: [Pharo-dev] about signal

[Danil Osipchuk]

Maybe to add this into the class comment, this is the most concise and
clear description of how it works i've ever seen

пт, 10 янв. 2020 г., 8:13 Eliot Miranda :

>
>
> On Thu, Jan 9, 2020 at 5:03 AM ducasse  wrote:
>
>> Hi
>>
>> I wanted to explain
>>
>> | semaphore p1 p2 |
>> semaphore := Semaphore new.
>> p1 := [ semaphore wait.
>> 'p1' crTrace ] fork.
>>
>> p2 := [semaphore signal.
>>  'p2' crTrace ] fork.
>>
>> displays p2 and p1.
>> but I would like explain clearly but it depends on the semantics of
>> signal.
>>
>>
>> - ==p1== is scheduled and its execution starts to wait on the semaphore,
>> so it is removed from the run queue of the scheduler and added to the
>> waiting list of the semaphore.
>> - ==p2== is scheduled and it signals the semaphore. The semaphore takes
>> the first waiting process (==p1==) and reschedule it by adding it to the
>> end of the suspended lists.
>>
>
> Since Smalltalk does not have a preemptive scheduler, neither p1 nor p2
> will start to run until something else happens after the execution of p1 :=
> [...] fork. p2 := [...] fork. So for example, if there is Processor yield
> then p1 can start to run.
>
> So you need to add code to your example to be able to determine what will
> happen.  The easiest thing would be to delay long enough that both can run.
>  1 millisecond is more than enough.
>
>
>> Now this sentence "The semaphore takes the first waiting process (==p1==)
>> and reschedule it by adding it to the end of the suspended lists.” is super
>> naive. Is the semaphore signalling scheduled? or not?
>>
>
> I would say these three things, something like this:
>
> "A semaphore is a queue (implemented as a linked list) and an excess
> signals count, which is a non-negative integer.  On instance creation a new
> semaphore is empty and has a zero excess signals count.  A semaphore
> created for mutual exclusion is empty and has an excess signals count of
> one."
>
> "When a process waits on a semaphore, if the semaphore's excess signals
> count is non-zero, then the excess signal count is decremented, and the
> process proceeds.  But if the semaphore has a zero excess signals count
> then the process is unscheduled and added to the end of the semaphore,
> after any other processes that are queued on the semaphore."
>
> "When a semaphore is signaled, if it is not empty, the first process is
> removed from it and added to the runnable processes in the scheduler. If
> the semaphore is empty its excess signals count is incremented.
>
> Given these three statements it is easy to see how they work, how to use
> them for mutual exclusion, etc.
>
>
>>
>> signal
>> "Primitive. Send a signal through the receiver. If one or more
>> processes
>> have been suspended trying to receive a signal, allow the first
>> one to
>> proceed. If no process is waiting, remember the excess signal.
>> Essential.
>> See Object documentation whatIsAPrimitive."
>>
>> 
>> self primitiveFailed
>>
>> "self isEmpty
>> ifTrue: [excessSignals := excessSignals+1]
>> ifFalse: [Processor resume: self removeFirstLink]"
>>
>>
>> I wanted to know what is really happening when a semaphore is signalled.
>> Now resume: does not exist on Processor.
>>
>> I will look in the VM code.
>>
>>
>> S
>>
>>
>>
>>
>>
>> S.
>>
>>
>
> --
> _,,,^..^,,,_
> best, Eliot
>

Re: [Pharo-dev] about signal

[Eliot Miranda]

On Thu, Jan 9, 2020 at 5:03 AM ducasse  wrote:

> Hi
>
> I wanted to explain
>
> | semaphore p1 p2 |
> semaphore := Semaphore new.
> p1 := [ semaphore wait.
> 'p1' crTrace ] fork.
>
> p2 := [semaphore signal.
>  'p2' crTrace ] fork.
>
> displays p2 and p1.
> but I would like explain clearly but it depends on the semantics of
> signal.
>
>
> - ==p1== is scheduled and its execution starts to wait on the semaphore,
> so it is removed from the run queue of the scheduler and added to the
> waiting list of the semaphore.
> - ==p2== is scheduled and it signals the semaphore. The semaphore takes
> the first waiting process (==p1==) and reschedule it by adding it to the
> end of the suspended lists.
>

Since Smalltalk does not have a preemptive scheduler, neither p1 nor p2
will start to run until something else happens after the execution of p1 :=
[...] fork. p2 := [...] fork. So for example, if there is Processor yield
then p1 can start to run.

So you need to add code to your example to be able to determine what will
happen.  The easiest thing would be to delay long enough that both can run.
 1 millisecond is more than enough.


> Now this sentence "The semaphore takes the first waiting process (==p1==)
> and reschedule it by adding it to the end of the suspended lists.” is super
> naive. Is the semaphore signalling scheduled? or not?
>

I would say these three things, something like this:

"A semaphore is a queue (implemented as a linked list) and an excess
signals count, which is a non-negative integer.  On instance creation a new
semaphore is empty and has a zero excess signals count.  A semaphore
created for mutual exclusion is empty and has an excess signals count of
one."

"When a process waits on a semaphore, if the semaphore's excess signals
count is non-zero, then the excess signal count is decremented, and the
process proceeds.  But if the semaphore has a zero excess signals count
then the process is unscheduled and added to the end of the semaphore,
after any other processes that are queued on the semaphore."

"When a semaphore is signaled, if it is not empty, the first process is
removed from it and added to the runnable processes in the scheduler. If
the semaphore is empty its excess signals count is incremented.

Given these three statements it is easy to see how they work, how to use
them for mutual exclusion, etc.


>
> signal
> "Primitive. Send a signal through the receiver. If one or more
> processes
> have been suspended trying to receive a signal, allow the first
> one to
> proceed. If no process is waiting, remember the excess signal.
> Essential.
> See Object documentation whatIsAPrimitive."
>
> 
> self primitiveFailed
>
> "self isEmpty
> ifTrue: [excessSignals := excessSignals+1]
> ifFalse: [Processor resume: self removeFirstLink]"
>
>
> I wanted to know what is really happening when a semaphore is signalled.
> Now resume: does not exist on Processor.
>
> I will look in the VM code.
>
>
> S
>
>
>
>
>
> S.
>
>

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

Re: [Pharo-dev] about signal

[ducasse]

here is what I’m writing in the book.

Let us image that we have the following two processes and one semaphore. 

[[[
| semaphore p1 p2 |
semaphore := Semaphore new.
p1 := [ semaphore wait.
'p1' crTrace ] fork.

p2 := [ semaphore signal.
'p2' crTrace ] fork.
]]]

- The first process is waiting on the semaphore. As soon as the semaphore will 
be signalled, ==p1== is signal also the semaphore.
- The second process is just signalling the semaphore and printing. 

Now the question is to understand what is the generated trace which is ==p2== 
then ==p1==. 

Let us explain why.
- ==p1== is scheduled and its execution starts to wait on the semaphore, so it 
is removed from the run queue of the scheduler and added to the waiting list of 
the semaphore.
- ==p2== is scheduled and it signals the semaphore. The semaphore takes the 
first waiting process (==p1==) and reschedules it by adding it to the end of 
the suspended lists. ==p2== continues its execution.


Let us slightly change the example to show how priorities are involved during 
the signalling process.

[[[
| semaphore p1 p2 |
semaphore := Semaphore new.
p1 := [ semaphore wait.
'p1' crTrace ] forkAt: 30.

p2 := [semaphore signal.
'p2' crTrace ] forkAt: 20.
]]

As a conclusion when the semaphore is signalled, the first waiting process of 
the semaphore is removed from the semaphore list,
and resumed following the preemption rules of the scheduler.



> On 9 Jan 2020, at 13:01, ducasse  wrote:
> 
> Hi
> 
> I wanted to explain
> 
> | semaphore p1 p2 |
> semaphore := Semaphore new.
> p1 := [ semaphore wait.
>   'p1' crTrace ] fork.
>   
> p2 := [semaphore signal.
>'p2' crTrace ] fork.
> 
> displays p2 and p1. 
> but I would like explain clearly but it depends on the semantics of signal. 
> 
> 
> - ==p1== is scheduled and its execution starts to wait on the semaphore, so 
> it is removed from the run queue of the scheduler and added to the waiting 
> list of the semaphore.
> - ==p2== is scheduled and it signals the semaphore. The semaphore takes the 
> first waiting process (==p1==) and reschedule it by adding it to the end of 
> the suspended lists.
> 
> 
> Now this sentence "The semaphore takes the first waiting process (==p1==) and 
> reschedule it by adding it to the end of the suspended lists.” is super 
> naive. Is the semaphore signalling scheduled? or not?
> 
> 
> signal
>   "Primitive. Send a signal through the receiver. If one or more 
> processes 
>   have been suspended trying to receive a signal, allow the first one to 
>   proceed. If no process is waiting, remember the excess signal. 
> Essential. 
>   See Object documentation whatIsAPrimitive."
> 
>   
>   self primitiveFailed
> 
>   "self isEmpty
>   ifTrue: [excessSignals := excessSignals+1]
>   ifFalse: [Processor resume: self removeFirstLink]"
> 
> 
> I wanted to know what is really happening when a semaphore is signalled. 
> Now resume: does not exist on Processor. 
> 
> I will look in the VM code. 
> 
> 
> S
> 
> 
> 
> 
> 
> S.

[Pharo-dev] about signal

[ducasse]

Hi

I wanted to explain

| semaphore p1 p2 |
semaphore := Semaphore new.
p1 := [ semaphore wait.
'p1' crTrace ] fork.

p2 := [semaphore signal.
 'p2' crTrace ] fork.

displays p2 and p1. 
but I would like explain clearly but it depends on the semantics of signal. 


- ==p1== is scheduled and its execution starts to wait on the semaphore, so it 
is removed from the run queue of the scheduler and added to the waiting list of 
the semaphore.
- ==p2== is scheduled and it signals the semaphore. The semaphore takes the 
first waiting process (==p1==) and reschedule it by adding it to the end of the 
suspended lists.


Now this sentence "The semaphore takes the first waiting process (==p1==) and 
reschedule it by adding it to the end of the suspended lists.” is super naive. 
Is the semaphore signalling scheduled? or not?


signal
"Primitive. Send a signal through the receiver. If one or more 
processes 
have been suspended trying to receive a signal, allow the first one to 
proceed. If no process is waiting, remember the excess signal. 
Essential. 
See Object documentation whatIsAPrimitive."


self primitiveFailed

"self isEmpty
ifTrue: [excessSignals := excessSignals+1]
ifFalse: [Processor resume: self removeFirstLink]"


I wanted to know what is really happening when a semaphore is signalled. 
Now resume: does not exist on Processor. 

I will look in the VM code. 


S





S.

[Pharo-dev] About package deprecation

[Vincent Blondeau via Pharo-dev]

--- Begin Message ---
Hi all,

 

As everyone knows, the BlueInk and GTRecorder packages have been removed
from Pharo8.0 quite rapidly
https://github.com/pharo-project/pharo/issues/5217.

And it breaks the loading of other projects on Pharo8.0, like Roassal2.

 

Some claims that those packages will not be deprecated because they are
loadable as it from another repository. Why not? So, I tried.

 

For BlueInk, no repository containing the sources has been indicated. And
not repository exists on github.

 

For the GTRecorder, the sources are there:
https://github.com/pharo-contributions/EventRecorder, according to
https://github.com/pharo-project/pharo/issues/5232.

The problem is that the EventRecorder project does not contain exactly the
same classes, the prefix has been changed from GT to ER. So, any reference
to one of the classes of this project has to be changed… 

In particular, we had to make this change to make it load correctly:
https://github.com/lifeware-sa/Roassal2/commit/78ce17bba98b89cb21a996cf8acaf
4e053ae082b (and we just have tried to load it so far).

 

 

I think that not only Roassal is using those dependencies (see there
https://github.com/search?o=desc

=GTEventCollector=indexed=Code and they are just public repos) and
migrating them to the latest version of Pharo will be more painful since we
need to fix the issue it immediately, or, wait that the maintainer of each
project provide a fix to bypass the issues.

 

 

Therefore, as we have a nice deprecation mechanism in our system, I suggest
we use it so we can focus on stuff more important than writing tons of
emails. 

I am then pushing in favor of the integration of this PR:
https://github.com/pharo-project/pharo/pull/5257 so that we can have some
time to solve the bugs.

And I expect that those packages will be removed in Pharo 9.0.

 

 

Now that everything is exposed, could the maintainers of the Pharo project
take a clear decision concerning this topic? Also, we are expecting some
justification on the undertaken action.

 

 

Thanks,

Vincent

www.lifeware.ch  

 

 

<>--- End Message ---

[Pharo-dev] About dashed lines in Athens

[milton mamani]

Hi to all

I was playing with Athens and I found and error that you can reproduce with
the next script in Pharo8x64 macOs
```Smalltalk
AthensSurfaceExamples openViewOn: [ :can |
can pathTransform restoreAfter: [
can pathTransform translateX: 30 Y: 30.
can pathTransform rotateByDegrees: 35.
can setPaint: Color red.
can setStrokePaint: Color black.

can setShape: (-20@ -20 corner: 20@ 20).
can draw.
].
].
AthensSurfaceExamples openViewOn: [ :can |
can pathTransform restoreAfter: [
can pathTransform translateX: 30 Y: 30.
can pathTransform rotateByDegrees: 35.
can setPaint: Color red.
(can setStrokePaint: Color black)
width: 6;
dashes: #(4) offset: 0.

can setShape: (-20@ -20 corner: 20@ 20).
can draw.
].
].
AthensSurfaceExamples openViewOn: [ :can |
can pathTransform restoreAfter: [
can pathTransform translateX: 30 Y: 30.
can pathTransform rotateByDegrees: 35.
can setPaint: Color red.
can setStrokePaint: Color black.
can setShape: (-20@ -20 corner: 20@ 20).
can draw.
].
].
```

The previous examples opens 3 windows
The first the line is normal
The second the line is dashed
The third one should be normal, but it is dashed

Why because there is a cache for the color black in the methods
`setStrokePaint:`

I think that we need to fix this,

Cheers,
Milton

[Pharo-dev] about common command

[ducasse]

Hi 

I played a bit to turn smart suggestion actions into commander2 commands.
It works :). 
Now with CM2 we do not have to have a class per command. We can create an 
instance. Now I was wondering what we prefer

- using classes
+ we can dispatch later (for example suggestions dispatch on nodes 
message to register to specific AST node
and the new behavior can be plugged modularly using extension
+ free registration
- we create one class per command

- using instances
+ no need to create one class.
- we need to build a registration and query mechanism
- extension will require to change or annotate somehow the created 
instances .

So I have the impression that using classes is better.

Setf

Re: [Pharo-dev] about threeWayCompareTo:

[ducasse]

Thanks Nicolas.
We should check because cyril told me that the primitive was implemented but 
not published in the primitive table.
We will have a look. 

S.

> On 16 Sep 2019, at 19:42, Nicolas Cellier 
>  wrote:
> 
> This comparison was part of MiscPrimitivePlugin.
> MiscPrimitivePlugin is a false good idea:
> Smalltalk fallback code = VMMaker (slang) source
> 
> Unfortunately, this is an illusion because unlike the C source inclusions in 
> ST/X we don't have dynamic slang compilation!
> The consequence is that source code is not managed in VMMaker specific 
> package, but in a dialect specific/version specific package!
> Squeak/Pharo/Cuis/Newspeak may all have a different version of String at 
> image side.
> This is making VMMaker recipe for code generation more fragile than necessary 
> (and not easily portable to Pharo/Cuis/whatever...).
> 
> It seems to me that Clement did start a rewrite of essential primitives into 
> proper plugin...
> The plan was then to retract support of MiscPrimitivePlugin after a grace 
> period (after all, these are optional primitives).
> 
> 
> Le lun. 16 sept. 2019 à 13:39, Esteban Maringolo  > a écrit :
> I haven't followed nor maintained the SortFunctions library, but it
> relied heavily on the response of that method, by means of the
> "spaceship operator" ( #<=>), I think that Sven later changed such
> operator to "threeWayCompareTo:".
> 
> I don't know whether the primitive is available now, it wasn't back then.
> 
> Regards,
> 
> Esteban A. Maringolo
> 
> On Mon, Sep 16, 2019 at 3:52 AM ducasse  > wrote:
> >
> > I see
> >
> > threeWayCompareTo: aString
> > "Do a three-way comparison between the receiver and anotherObject, 
> > returning
> > -1 if self < anotherObject
> > 0 if self = anotherObject
> > 1 if self > anotherObject
> > This assumes a total order in accordance with the mathematical law 
> > of trichotomy.
> > See also:  http://en.wikipedia.org/wiki/Three-way_comparison 
> > "
> >
> >  ^ (self compare: self with: aString collated: AsciiOrder) - 2
> >
> > And I thought that we got a new primitive returning -101 directly
> > Is it not the case?
> >
> > Stef
> >
> >
> > String>>compare: string1 with: string2 collated: order
> >
> > "'abc' = 'abc' asWideString >>> true"
> > "'abc' asWideString = 'abc' >>> true"
> > "(ByteArray with: 97 with: 0 with: 0 with: 0) asString ~= 'a000' 
> > asWideString >>> true"
> > "('abc' sameAs: 'aBc' asWideString) >>> true"
> > "('aBc' asWideString sameAs: 'abc') >>> true"
> > "('a000' asWideString ~= (ByteArray with: 97 with: 0 with: 0 with: 
> > 0) asString) >>> true"
> > "((ByteArray with: 97 with: 0 with: 0 with: 0) asString sameAs: 
> > 'Abcd' asWideString) >>> false"
> > "('a000' asWideString sameAs: (ByteArray with: 97 with: 0 with: 0 
> > with: 0) asString) >>> false"
> >
> > (string1 isByteString and: [string2 isByteString]) ifTrue: [
> > ^ ByteString compare: string1 with: string2 collated: 
> > order].
> >  "Primitive does not fail properly right now"
> > ^ String compare: string1 with: string2 collated: order
> >
> >
> > ByteString>>compare: string1 with: string2 collated: order
> > "Return 1, 2 or 3, if string1 is <, =, or > string2, with the 
> > collating order of characters given by the order array."
> >
> > | len1 len2 c1 c2 |
> > 
> >
> > 
> > 
> > 
> >
> > len1 := string1 size.
> > len2 := string2 size.
> > 1 to: (len1 min: len2) do:
> > [:i |
> > c1 := order at: (string1 basicAt: i) + 1.
> > c2 := order at: (string2 basicAt: i) + 1.
> > c1 = c2 ifFalse:
> > [c1 < c2 ifTrue: [^ 1] ifFalse: [^ 3]]].
> > len1 = len2 ifTrue: [^ 2].
> > len1 < len2 ifTrue: [^ 1] ifFalse: [^ 3].
> >
> >
> >
> >
> 

Re: [Pharo-dev] about threeWayCompareTo:

[Nicolas Cellier]

This comparison was part of MiscPrimitivePlugin.
MiscPrimitivePlugin is a false good idea:
Smalltalk fallback code = VMMaker (slang) source

Unfortunately, this is an illusion because unlike the C source inclusions
in ST/X we don't have dynamic slang compilation!
The consequence is that source code is not managed in VMMaker specific
package, but in a dialect specific/version specific package!
Squeak/Pharo/Cuis/Newspeak may all have a different version of String at
image side.
This is making VMMaker recipe for code generation more fragile than
necessary (and not easily portable to Pharo/Cuis/whatever...).

It seems to me that Clement did start a rewrite of essential primitives
into proper plugin...
The plan was then to retract support of MiscPrimitivePlugin after a grace
period (after all, these are optional primitives).


Le lun. 16 sept. 2019 à 13:39, Esteban Maringolo  a
écrit :

> I haven't followed nor maintained the SortFunctions library, but it
> relied heavily on the response of that method, by means of the
> "spaceship operator" ( #<=>), I think that Sven later changed such
> operator to "threeWayCompareTo:".
>
> I don't know whether the primitive is available now, it wasn't back then.
>
> Regards,
>
> Esteban A. Maringolo
>
> On Mon, Sep 16, 2019 at 3:52 AM ducasse  wrote:
> >
> > I see
> >
> > threeWayCompareTo: aString
> > "Do a three-way comparison between the receiver and
> anotherObject, returning
> > -1 if self < anotherObject
> > 0 if self = anotherObject
> > 1 if self > anotherObject
> > This assumes a total order in accordance with the mathematical
> law of trichotomy.
> > See also:  http://en.wikipedia.org/wiki/Three-way_comparison;
> >
> >  ^ (self compare: self with: aString collated: AsciiOrder) - 2
> >
> > And I thought that we got a new primitive returning -101 directly
> > Is it not the case?
> >
> > Stef
> >
> >
> > String>>compare: string1 with: string2 collated: order
> >
> > "'abc' = 'abc' asWideString >>> true"
> > "'abc' asWideString = 'abc' >>> true"
> > "(ByteArray with: 97 with: 0 with: 0 with: 0) asString ~= 'a000'
> asWideString >>> true"
> > "('abc' sameAs: 'aBc' asWideString) >>> true"
> > "('aBc' asWideString sameAs: 'abc') >>> true"
> > "('a000' asWideString ~= (ByteArray with: 97 with: 0 with: 0
> with: 0) asString) >>> true"
> > "((ByteArray with: 97 with: 0 with: 0 with: 0) asString sameAs:
> 'Abcd' asWideString) >>> false"
> > "('a000' asWideString sameAs: (ByteArray with: 97 with: 0 with:
> 0 with: 0) asString) >>> false"
> >
> > (string1 isByteString and: [string2 isByteString]) ifTrue: [
> > ^ ByteString compare: string1 with: string2 collated:
> order].
> >  "Primitive does not fail properly right now"
> > ^ String compare: string1 with: string2 collated: order
> >
> >
> > ByteString>>compare: string1 with: string2 collated: order
> > "Return 1, 2 or 3, if string1 is <, =, or > string2, with the
> collating order of characters given by the order array."
> >
> > | len1 len2 c1 c2 |
> >  'MiscPrimitivePlugin'>
> >
> > 
> > 
> > 
> >
> > len1 := string1 size.
> > len2 := string2 size.
> > 1 to: (len1 min: len2) do:
> > [:i |
> > c1 := order at: (string1 basicAt: i) + 1.
> > c2 := order at: (string2 basicAt: i) + 1.
> > c1 = c2 ifFalse:
> > [c1 < c2 ifTrue: [^ 1] ifFalse: [^ 3]]].
> > len1 = len2 ifTrue: [^ 2].
> > len1 < len2 ifTrue: [^ 1] ifFalse: [^ 3].
> >
> >
> >
> >
>
>

Re: [Pharo-dev] about threeWayCompareTo:

[Esteban Maringolo]

I haven't followed nor maintained the SortFunctions library, but it
relied heavily on the response of that method, by means of the
"spaceship operator" ( #<=>), I think that Sven later changed such
operator to "threeWayCompareTo:".

I don't know whether the primitive is available now, it wasn't back then.

Regards,

Esteban A. Maringolo

On Mon, Sep 16, 2019 at 3:52 AM ducasse  wrote:
>
> I see
>
> threeWayCompareTo: aString
> "Do a three-way comparison between the receiver and anotherObject, 
> returning
> -1 if self < anotherObject
> 0 if self = anotherObject
> 1 if self > anotherObject
> This assumes a total order in accordance with the mathematical law of 
> trichotomy.
> See also:  http://en.wikipedia.org/wiki/Three-way_comparison;
>
>  ^ (self compare: self with: aString collated: AsciiOrder) - 2
>
> And I thought that we got a new primitive returning -101 directly
> Is it not the case?
>
> Stef
>
>
> String>>compare: string1 with: string2 collated: order
>
> "'abc' = 'abc' asWideString >>> true"
> "'abc' asWideString = 'abc' >>> true"
> "(ByteArray with: 97 with: 0 with: 0 with: 0) asString ~= 'a000' 
> asWideString >>> true"
> "('abc' sameAs: 'aBc' asWideString) >>> true"
> "('aBc' asWideString sameAs: 'abc') >>> true"
> "('a000' asWideString ~= (ByteArray with: 97 with: 0 with: 0 with: 0) 
> asString) >>> true"
> "((ByteArray with: 97 with: 0 with: 0 with: 0) asString sameAs: 
> 'Abcd' asWideString) >>> false"
> "('a000' asWideString sameAs: (ByteArray with: 97 with: 0 with: 0 
> with: 0) asString) >>> false"
>
> (string1 isByteString and: [string2 isByteString]) ifTrue: [
> ^ ByteString compare: string1 with: string2 collated: order].
>  "Primitive does not fail properly right now"
> ^ String compare: string1 with: string2 collated: order
>
>
> ByteString>>compare: string1 with: string2 collated: order
> "Return 1, 2 or 3, if string1 is <, =, or > string2, with the 
> collating order of characters given by the order array."
>
> | len1 len2 c1 c2 |
> 
>
> 
> 
> 
>
> len1 := string1 size.
> len2 := string2 size.
> 1 to: (len1 min: len2) do:
> [:i |
> c1 := order at: (string1 basicAt: i) + 1.
> c2 := order at: (string2 basicAt: i) + 1.
> c1 = c2 ifFalse:
> [c1 < c2 ifTrue: [^ 1] ifFalse: [^ 3]]].
> len1 = len2 ifTrue: [^ 2].
> len1 < len2 ifTrue: [^ 1] ifFalse: [^ 3].
>
>
>
>

Re: [Pharo-dev] about threeWayCompareTo:

[Nicolas Cellier]

This was WIP, don't know if it stalled...

Le lun. 16 sept. 2019 à 08:52, ducasse  a écrit :

> I see
>
> threeWayCompareTo: aString
> "Do a three-way comparison between the receiver and anotherObject,
> returning
> -1 if self < anotherObject
> 0 if self = anotherObject
> 1 if self > anotherObject
> This assumes a total order in accordance with the mathematical law
> of trichotomy.
> See also:  http://en.wikipedia.org/wiki/Three-way_comparison;
>
>  ^ (self compare: self with: aString collated: AsciiOrder) - 2
>
> And I thought that we got a new primitive returning -101 directly
> Is it not the case?
>
> Stef
>
>
> String>>compare: string1 with: string2 collated: order
>
> "'abc' = 'abc' asWideString >>> true"
> "'abc' asWideString = 'abc' >>> true"
> "(ByteArray with: 97 with: 0 with: 0 with: 0) asString ~= 'a000'
> asWideString >>> true"
> "('abc' sameAs: 'aBc' asWideString) >>> true"
> "('aBc' asWideString sameAs: 'abc') >>> true"
> "('a000' asWideString ~= (ByteArray with: 97 with: 0 with: 0 with:
> 0) asString) >>> true"
> "((ByteArray with: 97 with: 0 with: 0 with: 0) asString sameAs:
> 'Abcd' asWideString) >>> false"
> "('a000' asWideString sameAs: (ByteArray with: 97 with: 0 with: 0
> with: 0) asString) >>> false"
>
> (string1 isByteString and: [string2 isByteString]) ifTrue: [
> ^ ByteString compare: string1 with: string2 collated:
> order].
>  "Primitive does not fail properly right now"
> ^ String compare: string1 with: string2 collated: order
>
>
> ByteString>>compare: string1 with: string2 collated: order
> "Return 1, 2 or 3, if string1 is <, =, or > string2, with the
> collating order of characters given by the order array."
>
> | len1 len2 c1 c2 |
> 
>
> 
> 
> 
>
> len1 := string1 size.
> len2 := string2 size.
> 1 to: (len1 min: len2) do:
> [:i |
> c1 := order at: (string1 basicAt: i) + 1.
> c2 := order at: (string2 basicAt: i) + 1.
> c1 = c2 ifFalse:
> [c1 < c2 ifTrue: [^ 1] ifFalse: [^ 3]]].
> len1 = len2 ifTrue: [^ 2].
> len1 < len2 ifTrue: [^ 1] ifFalse: [^ 3].
>
>
>
>
>

[Pharo-dev] about threeWayCompareTo:

[ducasse]

I see

threeWayCompareTo: aString
"Do a three-way comparison between the receiver and anotherObject, 
returning
-1 if self < anotherObject
0 if self = anotherObject
1 if self > anotherObject
This assumes a total order in accordance with the mathematical law of 
trichotomy.
See also:  http://en.wikipedia.org/wiki/Three-way_comparison;

 ^ (self compare: self with: aString collated: AsciiOrder) - 2

And I thought that we got a new primitive returning -101 directly
Is it not the case?

Stef


String>>compare: string1 with: string2 collated: order

"'abc' = 'abc' asWideString >>> true"
"'abc' asWideString = 'abc' >>> true"
"(ByteArray with: 97 with: 0 with: 0 with: 0) asString ~= 'a000' 
asWideString >>> true"
"('abc' sameAs: 'aBc' asWideString) >>> true"
"('aBc' asWideString sameAs: 'abc') >>> true"
"('a000' asWideString ~= (ByteArray with: 97 with: 0 with: 0 with: 0) 
asString) >>> true"
"((ByteArray with: 97 with: 0 with: 0 with: 0) asString sameAs: 'Abcd' 
asWideString) >>> false"
"('a000' asWideString sameAs: (ByteArray with: 97 with: 0 with: 0 with: 
0) asString) >>> false"

(string1 isByteString and: [string2 isByteString]) ifTrue: [
^ ByteString compare: string1 with: string2 collated: order].
 "Primitive does not fail properly right now"
^ String compare: string1 with: string2 collated: order


ByteString>>compare: string1 with: string2 collated: order
"Return 1, 2 or 3, if string1 is <, =, or > string2, with the collating 
order of characters given by the order array."

| len1 len2 c1 c2 |






len1 := string1 size.
len2 := string2 size.
1 to: (len1 min: len2) do:
[:i |
c1 := order at: (string1 basicAt: i) + 1.
c2 := order at: (string2 basicAt: i) + 1.
c1 = c2 ifFalse: 
[c1 < c2 ifTrue: [^ 1] ifFalse: [^ 3]]].
len1 = len2 ifTrue: [^ 2].
len1 < len2 ifTrue: [^ 1] ifFalse: [^ 3].

Re: [Pharo-dev] About tweets

[ducasse]

t; 
>>> showed.
>>>  
>>> (http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/2019-September/044168.html)
>>> 
>>>  And maybe linking to these aggregators or promoting them is not a good 
>>> idea. If we take the discussion (over)serious we should then
>>>  really only link to official twitter account and official pharo blog that 
>>> the community can control.
>>> 
>>>  In such a case we need to remove my blog and your personal twitter account 
>>> from the community page as you sometimes tweet about
>>>  politics on your personal account too and I can potentially write on other 
>>> non-technical topics on my blog as well (which I do not plan).
>>> 
>>> 
>>> Basically we have four options:
>>> a) we only link to the official twitter account 
>>> (https://twitter.com/pharoproject) and blog 
>>> (https://pharoweekly.wordpress.com/)
>>> b) extend the list with personal twitter accounts as mentioned in issue 
>>> #4491 and blogs like mentioned in #4490
>>> c) Link and rely on external aggregators
>>> d) Setup an own aggregator on sources we trust
>>> 
>>> Maybe as a valid solution an official "disclaimer" could help - that 
>>> opinions shared on these PROMOTED sources are not controlled by
>>> us and do not necessarily reflect the opinion of the Pharo community
>>> 
>>> And yes - the board should discuss, check and decide what to put or link to 
>>> from the community page.
>>> 
>>> Thanks
>>> T.
>>> 
>>>> Gesendet: Donnerstag, 05. September 2019 um 08:03 Uhr
>>>> Von: "ducasse" 
>>>> An: "Pharo Development List" 
>>>> Cc: "The Pharo Project" 
>>>> Betreff: [Pharo-dev] About tweets
>>>> 
>>>> Hi guys
>>>> 
>>>> I encourage everybody to read this issue until the last conversation.
>>>>https://github.com/pharo-project/pharo/issues/4491
>>>> 
>>>> I have problem to promote an aggregator that can contain tweets containing 
>>>> #abortionismurder inside.!
>>>> And I have even more problem that this is in a tweet on Amber Weekly
>>>> 
>>>> I do not know who is behind AmberSmalltalk tweets but for me this is 
>>>> clearly impossible to read this
>>>> on a tweet that Pharo supports.
>>>> 
>>>> I also have a problem to promote an aggregator account
>>>> We can provide a list and people what they want.
>>>> I do not like the idea of aggregation. So I vote against and I will ask 
>>>> the board to decide.
>>>> 
>>>> Stef
>>>> 
>>>> 
>>> 
>> 
>> 
> 

Re: [Pharo-dev] About tweets

[Norbert Hartl]

>> 
>>   In such a case we need to remove my blog and your personal twitter account 
>> from the community page as you sometimes tweet about
>>   politics on your personal account too and I can potentially write on other 
>> non-technical topics on my blog as well (which I do not plan).
>> 
>> 
>> Basically we have four options:
>> a) we only link to the official twitter account 
>> (https://twitter.com/pharoproject) and blog 
>> (https://pharoweekly.wordpress.com/)
>> b) extend the list with personal twitter accounts as mentioned in issue 
>> #4491 and blogs like mentioned in #4490
>> c) Link and rely on external aggregators
>> d) Setup an own aggregator on sources we trust
>> 
>> Maybe as a valid solution an official "disclaimer" could help - that 
>> opinions shared on these PROMOTED sources are not controlled by
>> us and do not necessarily reflect the opinion of the Pharo community
>> 
>> And yes - the board should discuss, check and decide what to put or link to 
>> from the community page.
>> 
>> Thanks
>> T.
>> 
>>> Gesendet: Donnerstag, 05. September 2019 um 08:03 Uhr
>>> Von: "ducasse" 
>>> An: "Pharo Development List" 
>>> Cc: "The Pharo Project" 
>>> Betreff: [Pharo-dev] About tweets
>>> 
>>> Hi guys
>>> 
>>> I encourage everybody to read this issue until the last conversation.
>>> https://github.com/pharo-project/pharo/issues/4491
>>> 
>>> I have problem to promote an aggregator that can contain tweets containing 
>>> #abortionismurder inside.!
>>> And I have even more problem that this is in a tweet on Amber Weekly
>>> 
>>> I do not know who is behind AmberSmalltalk tweets but for me this is 
>>> clearly impossible to read this
>>> on a tweet that Pharo supports.
>>> 
>>> I also have a problem to promote an aggregator account
>>> We can provide a list and people what they want.
>>> I do not like the idea of aggregation. So I vote against and I will ask the 
>>> board to decide.
>>> 
>>> Stef
>>> 
>>> 
>> 
> 
> 

Re: [Pharo-dev] About tweets

[ducasse]

ith personal twitter accounts as mentioned in issue 
> #4491 and blogs like mentioned in #4490
>  c) Link and rely on external aggregators
>  d) Setup an own aggregator on sources we trust
> 
> Maybe as a valid solution an official "disclaimer" could help - that opinions 
> shared on these PROMOTED sources are not controlled by
> us and do not necessarily reflect the opinion of the Pharo community
> 
> And yes - the board should discuss, check and decide what to put or link to 
> from the community page.
> 
> Thanks
> T.
> 
>> Gesendet: Donnerstag, 05. September 2019 um 08:03 Uhr
>> Von: "ducasse" 
>> An: "Pharo Development List" 
>> Cc: "The Pharo Project" 
>> Betreff: [Pharo-dev] About tweets
>> 
>> Hi guys
>> 
>> I encourage everybody to read this issue until the last conversation.
>>  https://github.com/pharo-project/pharo/issues/4491
>> 
>> I have problem to promote an aggregator that can contain tweets containing 
>> #abortionismurder inside.!
>> And I have even more problem that this is in a tweet on Amber Weekly
>> 
>> I do not know who is behind AmberSmalltalk tweets but for me this is clearly 
>> impossible to read this
>> on a tweet that Pharo supports.
>> 
>> I also have a problem to promote an aggregator account
>> We can provide a list and people what they want.
>> I do not like the idea of aggregation. So I vote against and I will ask the 
>> board to decide.
>> 
>> Stef
>> 
>> 
> 

Re: [Pharo-dev] About tweets

[Torsten Bergmann]

Hi Stef,

I understand - but before we focus the discussion too much on the mentioned 
#abortionismurder let's bring #4491 into perspective:

 1. Important: I guess we all agree that we would like to tweet and inform as 
much on technical topics about Smalltalk in general and
Pharo in particular and not correlate our activities to single peoples 
personal habits, politics, religion or beliefs.

 2. The aggregator that I suggested in the issue 
(https://twitter.com/WorldDotSt) is related to the website world.st - which is
a really useful technical resource on Smalltalk, Pharo and ESUG infos 
already throughout the years:

 - The forum page http://forum.world.st is summarizing various ST 
Mailinglists including ESUG list
 - https://twitter.com/WorldDotSt aggregates most of the Pharo and 
Smalltalker Tweets in existence

 3. You are referring in this thread here to the following tweet: 
https://twitter.com/AmberSmalltalk/status/1169239145530761217
which is associating @esugsmalltalk @SergeStinckwich @stephaneducasse 
#smalltalk for whatever reason with the hash tag #abortionismurder

I understand your reaction and post - but this was done outside our 
boundaries by twitter user "AmberSmalltalk" - also not by the aggregator
itself. And yes - this "AmberSmalltalk" owner seems to mix sometimes 
personal beliefs into technical infos. I share your doubts and dislike
this as well.

It's a problem that existed before and is a problem of tweeting and social 
media in general. Something that is IMHO independent from described
issue #4491 - and you and Serge definitely need to sort out this 
#abortionismurder thing with the owner of this specific account.

 4. The issue #4491 mentions that currently the Pharo community page 
(http://www.pharo.org/community)

for Twitter ONLY PROMOTES
a) the offical tweet account @pharoproject
b) your personal @stephaneducasse account
as the ones to follow.

But we have many more interesting community members tweeting on Pharo as 
you see on the list in the referred issue. So we should either
extend the community page with either more personal accounts, just use the 
offical one or use an external or own aggregator
including hashtags like #pharo, #pharoproject, ...


 5. As you might have noticed I also opened a second issue #4490 
(https://github.com/pharo-project/pharo/issues/4490) as for the blogs mentioned
on the community page we have something similar:

For Blogs WE ONLY PROMOTE on that page:
a) the official pharo weekly
b) my personal astares blog
c) the personal blog of clement

But my blog is not special either - so an aggregator of the various 
Smalltalks blogs (as the one suggested from planet smalltalk)
made initially sense to me as it would include more blogs of members of the 
community and we would not have to adopt the community page all
the time a new blog appears.

There are nice Pharo blogs out there like https://www.samadhiweb.com/blog, 
http://humane-assessment.com/blog and many other.

Same applies here: either we just include the offical blog that we control, 
a list of more blogs of the various members or an aggregator

 6. Yes - the community is unable to control what people write on Twitter, 
Blogs or other social media. Even our mailinglist "pharo-users_lists"
is not free from personal habits as yesterdays disussion about "guns" 
showed.

(http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/2019-September/044168.html)

And maybe linking to these aggregators or promoting them is not a good 
idea. If we take the discussion (over)serious we should then
really only link to official twitter account and official pharo blog that 
the community can control.

In such a case we need to remove my blog and your personal twitter account 
from the community page as you sometimes tweet about
politics on your personal account too and I can potentially write on other 
non-technical topics on my blog as well (which I do not plan).


Basically we have four options:
  a) we only link to the official twitter account 
(https://twitter.com/pharoproject) and blog (https://pharoweekly.wordpress.com/)
  b) extend the list with personal twitter accounts as mentioned in issue #4491 
and blogs like mentioned in #4490
  c) Link and rely on external aggregators
  d) Setup an own aggregator on sources we trust

Maybe as a valid solution an official "disclaimer" could help - that opinions 
shared on these PROMOTED sources are not controlled by
us and do not necessarily reflect the opinion of the Pharo community

And yes - the board should discuss, check and decide what to put or link to 
from the community page.

Thanks
T.

> Gesendet: Donnerstag, 05. September 2019 um 08:03 Uhr
> Von: "ducasse" 
> An: "Pharo Development List" 
> Cc: "The Ph

Re: [Pharo-dev] About tweets

[Norbert Hartl]

Ok, there seems to be some agreeable sense. Dealing with accounts of people 
tends to collect opinions and things not related to pharo. We are not 
interested in these.
There are hashtags and mentions for things related to a topic. But a few (!) 
want to have more control. So using the @pharoproject account should be ok 
because we can like things to be includef from that account. Well at least the 
ones that have access to. 

Is this a proper summary?

Norbert

> Am 05.09.2019 um 08:48 schrieb Esteban Lorenzano :
> 
> Yes, I closed that issue. 
> 
> This is not going to happen, sorry :)
> 
> Esteban
> 
>> On 5 Sep 2019, at 08:03, ducasse  wrote:
>> 
>> Hi guys 
>> 
>> I encourage everybody to read this issue until the last conversation.
>>https://github.com/pharo-project/pharo/issues/4491
>> 
>> I have problem to promote an aggregator that can contain tweets containing 
>> #abortionismurder inside.!
>> And I have even more problem that this is in a tweet on Amber Weekly 
>> 
>> I do not know who is behind AmberSmalltalk tweets but for me this is clearly 
>> impossible to read this
>> on a tweet that Pharo supports. 
>> 
>> I also have a problem to promote an aggregator account
>> We can provide a list and people what they want. 
>> I do not like the idea of aggregation. So I vote against and I will ask the 
>> board to decide. 
>> 
>> Stef
> 
> 

Re: [Pharo-dev] About tweets

[Esteban Lorenzano]

Yes, I closed that issue. 

This is not going to happen, sorry :)

Esteban

> On 5 Sep 2019, at 08:03, ducasse  wrote:
> 
> Hi guys 
> 
> I encourage everybody to read this issue until the last conversation.
>   https://github.com/pharo-project/pharo/issues/4491
> 
> I have problem to promote an aggregator that can contain tweets containing 
> #abortionismurder inside.!
> And I have even more problem that this is in a tweet on Amber Weekly 
> 
> I do not know who is behind AmberSmalltalk tweets but for me this is clearly 
> impossible to read this
> on a tweet that Pharo supports. 
> 
> I also have a problem to promote an aggregator account
> We can provide a list and people what they want. 
> I do not like the idea of aggregation. So I vote against and I will ask the 
> board to decide. 
> 
> Stef

[Pharo-dev] About tweets

[ducasse]

Hi guys 

I encourage everybody to read this issue until the last conversation.
https://github.com/pharo-project/pharo/issues/4491

I have problem to promote an aggregator that can contain tweets containing 
#abortionismurder inside.!
And I have even more problem that this is in a tweet on Amber Weekly 

I do not know who is behind AmberSmalltalk tweets but for me this is clearly 
impossible to read this
on a tweet that Pharo supports. 

I also have a problem to promote an aggregator account
We can provide a list and people what they want. 
I do not like the idea of aggregation. So I vote against and I will ask the 
board to decide. 

Stef

Re: [Pharo-dev] About resurrecting the RE package and plugin

[Christopher Fuhrman]

I have a related solution that's coded at my level of Pharo skillz (aka
hacked). I used LibC and Perl to code a matches: method. It seems to work
well, but Perl has to be in the path.

The prototype with tests is at https://github.com/fuhrmanator/Keshi

self assert: ('a.*?com' asKSRegex matches: 'a is a test com blah blah').
self assert: ('^(?:\w+:)?\/\/([^\s\.]+\.\S{2}|localhost[\:?\d]*)\S*$'
asKSRegex matches: 'https://www.thisisatest.com/bhal').
self deny: ('^(?:\w+:)?\/\/([^\s\.]+\.\S{2}|localhost[\:?\d]*)\S*$'
asKSRegex matches: 'www.thisisatest.com/bhal').



On Tue, Jan 15, 2019, 00:14 ducasse via Pharo-dev 
wrote:

> Hi
>
> I would really like to resurrect the REPlugin and its image side
> abstraction because
> I think that this is important to support Perl level regex since it will
> help
> people to reuse their knowledge.
> If you are interested in helping let us know.
>
> Stef
>
>
>

Re: [Pharo-dev] About

[ducasse]

tx!

> On 11 Apr 2019, at 14:42, Sophie Kaleba  wrote:
> 
> HI,
> We actually talked about this very primitive with Cyril not that long ago. 
> I'll have a look at it with him this week so it can be used !
> 
> Sophie
> 
> Le mer. 10 avr. 2019 à 14:10, ducasse  > a écrit :
> Thanks I did not know it was on a mailing-list.
> 
> 
>> On 10 Apr 2019, at 14:02, Nicolas Cellier 
>> > > wrote:
>> 
>> Hi Stephane,
>> If you google 'vm-dev VMMaker.oscog-sk.2367'
>> and click one of the first hits 
>> https://marc.info/?l=squeak-vm-dev=152413936110744=2 
>> 
>> 
>> you'll see the changes from Sophie:
>> The new InterpreterPrimitives>>primitiveCompareWith should be linked to 
>> primitive 158.
>> (and only for ByteString comparison).
>> 
>> I did not try it, I have not much time to invest at the moment.
>> 
>> Le mer. 10 avr. 2019 à 13:52, ducasse > > a écrit :
>> Nicolas 
>> 
>> I tried to find the new primitive and I did not find it here
>> 
>> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/src/plugins/MiscPrimitivePlugin/MiscPrimitivePlugin.c
>>  
>> 
>> 
>> I found the old one. 
>> Did I look in the wrong place?
>> 
>> Stef
>> 
>>> On 10 Apr 2019, at 13:46, ducasse >> > wrote:
>>> 
>>> Thanks nicolas so we can use them then. 
>>> 
 On 10 Apr 2019, at 11:59, Nicolas Cellier 
 >>> > wrote:
 
 VMMaker.oscog-sk.2367
 Author: sk
 Time: 19 April 2018, 12:02:35.661622 pm
 UUID: 0c2401e3-1450-4f73-8e81-958f50171595
 Ancestors: VMMaker.oscog- nice.2366
 
 ** new primitive to compare strings (slang + JIT)
 answers negative smi, 0 or positive smi (instead of 1, 2 or 3 in the 
 MiscPlugin)
 
 * Slang (primitiveCompareWith)
 order is optionnal. 
 comparison loop performed in rawCompare: string1 length: strLength1 with: 
 string2 length: strLength2 accessBlock: accessBlock
 
 * JIT (genPrimitiveStringCompareWith)
 the JIT primitive does not take order as parameter (assumed asciiOrder)
 quick jump if one of the strings is empty
 
 Le mer. 10 avr. 2019 à 11:56, ducasse >>> > a écrit :
 
 
> On 10 Apr 2019, at 11:42, Cyril Ferlicot  > wrote:
> 
> On Wed, Apr 10, 2019 at 10:42 AM Stéphane Ducasse
> mailto:stephane.duca...@inria.fr>> wrote:
>> 
>> Hi
>> 
>> I recall that clement told me that returning 1,2 or 3 instead of 
>> negative, zero, positive was slow.
>> And I wonder if the primitive got change to the logic clement proposed?
>> 
>> Could we not introduce another primitive and use it from the image?
> 
> Hi,
> 
> I think Sophie already did most of the work to introduce a new
> primitive. The missing steps to use the new optimized way to compare
> strings are:
> - Add the primitive to the primitive table VM side for Pharo/Squeak and 
> Newspeak
 
 If you know that it is done from the VM side let us know. 
 
> - Use the new primitive in the image and call this one for string 
> comparison
> 
> With this new primitive performances on string comparison can be
> improved around x2.5 to x5 times faster.
> 
>> 
>> compare: string1 with: string2 collated: order
>> "Return 1, 2 or 3, if string1 is <, =, or > string2, with the collating 
>> order of characters given by the order array."
>> 
>> | len1 len2 c1 c2 |
>> 
>> 
>> 
>> 
>> 
>> len1 := string1 size.
>> len2 := string2 size.
>> 1 to: (len1 min: len2) do:
>> [:i |
>> c1 := order at: (string1 basicAt: i) + 1.
>> c2 := order at: (string2 basicAt: i) + 1.
>> c1 = c2 ifFalse:
>> [c1 < c2 ifTrue: [^ 1] ifFalse: [^ 3]]].
>> len1 = len2 ifTrue: [^ 2].
>> len1 < len2 ifTrue: [^ 1] ifFalse: [^ 3].
>> 
>> 
>> Stéphane Ducasse
>> http://stephane.ducasse.free.fr 
>> http://www.synectique.eu  / 
>> http://www.pharo.org 
>> 03 59 35 87 52
>> Assistant: Julie Jonas
>> FAX 03 59 57 78 50
>> TEL 03 59 35 86 16
>> S. Ducasse - Inria
>> 40, avenue Halley,
>> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
>> Villeneuve d'Ascq 59650
>> France
>> 
> 
> 
> -- 
> Cyril Ferlicot
> https://ferlicot.fr 
>>> 
>> 
> 

Re: [Pharo-dev] About

[Sophie Kaleba]

HI,
We actually talked about this very primitive with Cyril not that long ago.
I'll have a look at it with him this week so it can be used !

Sophie

Le mer. 10 avr. 2019 à 14:10, ducasse  a écrit :

> Thanks I did not know it was on a mailing-list.
>
>
> On 10 Apr 2019, at 14:02, Nicolas Cellier <
> nicolas.cellier.aka.n...@gmail.com> wrote:
>
> Hi Stephane,
> If you google 'vm-dev VMMaker.oscog-sk.2367'
> and click one of the first hits
> https://marc.info/?l=squeak-vm-dev=152413936110744=2
>
> you'll see the changes from Sophie:
> The new InterpreterPrimitives>>primitiveCompareWith should be linked to
> primitive 158.
> (and only for ByteString comparison).
>
> I did not try it, I have not much time to invest at the moment.
>
> Le mer. 10 avr. 2019 à 13:52, ducasse  a écrit :
>
>> Nicolas
>>
>> I tried to find the new primitive and I did not find it here
>>
>>
>> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/src/plugins/MiscPrimitivePlugin/MiscPrimitivePlugin.c
>>
>> I found the old one.
>> Did I look in the wrong place?
>>
>> Stef
>>
>> On 10 Apr 2019, at 13:46, ducasse  wrote:
>>
>> Thanks nicolas so we can use them then.
>>
>> On 10 Apr 2019, at 11:59, Nicolas Cellier <
>> nicolas.cellier.aka.n...@gmail.com> wrote:
>>
>> VMMaker.oscog-sk.2367
>> Author: sk
>> Time: 19 April 2018, 12:02:35.661622 pm
>> UUID: 0c2401e3-1450-4f73-8e81-958f50171595
>> Ancestors: VMMaker.oscog- nice.2366
>>
>> ** new primitive to compare strings (slang + JIT)
>> answers negative smi, 0 or positive smi (instead of 1, 2 or 3 in the
>> MiscPlugin)
>>
>> * Slang (primitiveCompareWith)
>> order is optionnal.
>> comparison loop performed in rawCompare: string1 length: strLength1 with:
>> string2 length: strLength2 accessBlock: accessBlock
>>
>> * JIT (genPrimitiveStringCompareWith)
>> the JIT primitive does not take order as parameter (assumed asciiOrder)
>> quick jump if one of the strings is empty
>>
>> Le mer. 10 avr. 2019 à 11:56, ducasse  a
>> écrit :
>>
>>>
>>>
>>> On 10 Apr 2019, at 11:42, Cyril Ferlicot 
>>> wrote:
>>>
>>> On Wed, Apr 10, 2019 at 10:42 AM Stéphane Ducasse
>>>  wrote:
>>>
>>>
>>> Hi
>>>
>>> I recall that clement told me that returning 1,2 or 3 instead of
>>> negative, zero, positive was slow.
>>> And I wonder if the primitive got change to the logic clement proposed?
>>>
>>> Could we not introduce another primitive and use it from the image?
>>>
>>>
>>> Hi,
>>>
>>> I think Sophie already did most of the work to introduce a new
>>> primitive. The missing steps to use the new optimized way to compare
>>> strings are:
>>> - Add the primitive to the primitive table VM side for Pharo/Squeak and
>>> Newspeak
>>>
>>>
>>> If you know that it is done from the VM side let us know.
>>>
>>> - Use the new primitive in the image and call this one for string
>>> comparison
>>>
>>> With this new primitive performances on string comparison can be
>>> improved around x2.5 to x5 times faster.
>>>
>>>
>>> compare: string1 with: string2 collated: order
>>> "Return 1, 2 or 3, if string1 is <, =, or > string2, with the collating
>>> order of characters given by the order array."
>>>
>>> | len1 len2 c1 c2 |
>>> 
>>> 
>>> 
>>> 
>>>
>>> len1 := string1 size.
>>> len2 := string2 size.
>>> 1 to: (len1 min: len2) do:
>>> [:i |
>>> c1 := order at: (string1 basicAt: i) + 1.
>>> c2 := order at: (string2 basicAt: i) + 1.
>>> c1 = c2 ifFalse:
>>> [c1 < c2 ifTrue: [^ 1] ifFalse: [^ 3]]].
>>> len1 = len2 ifTrue: [^ 2].
>>> len1 < len2 ifTrue: [^ 1] ifFalse: [^ 3].
>>>
>>> 
>>> Stéphane Ducasse
>>> http://stephane.ducasse.free.fr
>>> http://www.synectique.eu / http://www.pharo.org
>>> 03 59 35 87 52
>>> Assistant: Julie Jonas
>>> FAX 03 59 57 78 50
>>> TEL 03 59 35 86 16
>>> S. Ducasse - Inria
>>> 40, avenue Halley,
>>> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
>>> Villeneuve d'Ascq 59650
>>> France
>>>
>>>
>>>
>>> --
>>> Cyril Ferlicot
>>> https://ferlicot.fr
>>>
>>>
>>>
>>
>>
>

Re: [Pharo-dev] About

[ducasse]

Thanks I did not know it was on a mailing-list.


> On 10 Apr 2019, at 14:02, Nicolas Cellier 
>  wrote:
> 
> Hi Stephane,
> If you google 'vm-dev VMMaker.oscog-sk.2367'
> and click one of the first hits 
> https://marc.info/?l=squeak-vm-dev=152413936110744=2 
> 
> 
> you'll see the changes from Sophie:
> The new InterpreterPrimitives>>primitiveCompareWith should be linked to 
> primitive 158.
> (and only for ByteString comparison).
> 
> I did not try it, I have not much time to invest at the moment.
> 
> Le mer. 10 avr. 2019 à 13:52, ducasse  > a écrit :
> Nicolas 
> 
> I tried to find the new primitive and I did not find it here
> 
> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/src/plugins/MiscPrimitivePlugin/MiscPrimitivePlugin.c
>  
> 
> 
> I found the old one. 
> Did I look in the wrong place?
> 
> Stef
> 
>> On 10 Apr 2019, at 13:46, ducasse > > wrote:
>> 
>> Thanks nicolas so we can use them then. 
>> 
>>> On 10 Apr 2019, at 11:59, Nicolas Cellier 
>>> >> > wrote:
>>> 
>>> VMMaker.oscog-sk.2367
>>> Author: sk
>>> Time: 19 April 2018, 12:02:35.661622 pm
>>> UUID: 0c2401e3-1450-4f73-8e81-958f50171595
>>> Ancestors: VMMaker.oscog- nice.2366
>>> 
>>> ** new primitive to compare strings (slang + JIT)
>>> answers negative smi, 0 or positive smi (instead of 1, 2 or 3 in the 
>>> MiscPlugin)
>>> 
>>> * Slang (primitiveCompareWith)
>>> order is optionnal. 
>>> comparison loop performed in rawCompare: string1 length: strLength1 with: 
>>> string2 length: strLength2 accessBlock: accessBlock
>>> 
>>> * JIT (genPrimitiveStringCompareWith)
>>> the JIT primitive does not take order as parameter (assumed asciiOrder)
>>> quick jump if one of the strings is empty
>>> 
>>> Le mer. 10 avr. 2019 à 11:56, ducasse >> > a écrit :
>>> 
>>> 
 On 10 Apr 2019, at 11:42, Cyril Ferlicot >>> > wrote:
 
 On Wed, Apr 10, 2019 at 10:42 AM Stéphane Ducasse
 mailto:stephane.duca...@inria.fr>> wrote:
> 
> Hi
> 
> I recall that clement told me that returning 1,2 or 3 instead of 
> negative, zero, positive was slow.
> And I wonder if the primitive got change to the logic clement proposed?
> 
> Could we not introduce another primitive and use it from the image?
 
 Hi,
 
 I think Sophie already did most of the work to introduce a new
 primitive. The missing steps to use the new optimized way to compare
 strings are:
 - Add the primitive to the primitive table VM side for Pharo/Squeak and 
 Newspeak
>>> 
>>> If you know that it is done from the VM side let us know. 
>>> 
 - Use the new primitive in the image and call this one for string 
 comparison
 
 With this new primitive performances on string comparison can be
 improved around x2.5 to x5 times faster.
 
> 
> compare: string1 with: string2 collated: order
> "Return 1, 2 or 3, if string1 is <, =, or > string2, with the collating 
> order of characters given by the order array."
> 
> | len1 len2 c1 c2 |
> 
> 
> 
> 
> 
> len1 := string1 size.
> len2 := string2 size.
> 1 to: (len1 min: len2) do:
> [:i |
> c1 := order at: (string1 basicAt: i) + 1.
> c2 := order at: (string2 basicAt: i) + 1.
> c1 = c2 ifFalse:
> [c1 < c2 ifTrue: [^ 1] ifFalse: [^ 3]]].
> len1 = len2 ifTrue: [^ 2].
> len1 < len2 ifTrue: [^ 1] ifFalse: [^ 3].
> 
> 
> Stéphane Ducasse
> http://stephane.ducasse.free.fr 
> http://www.synectique.eu  / 
> http://www.pharo.org 
> 03 59 35 87 52
> Assistant: Julie Jonas
> FAX 03 59 57 78 50
> TEL 03 59 35 86 16
> S. Ducasse - Inria
> 40, avenue Halley,
> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
> Villeneuve d'Ascq 59650
> France
> 
 
 
 -- 
 Cyril Ferlicot
 https://ferlicot.fr 
>> 
> 

Re: [Pharo-dev] About

[ducasse]

> On 10 Apr 2019, at 14:01, Cyril Ferlicot  wrote:
> 
> On Wed, Apr 10, 2019 at 1:52 PM ducasse  wrote:
>> 
>> Nicolas
>> 
>> I tried to find the new primitive and I did not find it here
>> 
>> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/src/plugins/MiscPrimitivePlugin/MiscPrimitivePlugin.c
>> 
>> I found the old one.
>> Did I look in the wrong place?
>> 
> 
> If I am not wrong it is directly in Slang and will be a numbered primitive.

I do not know :)
Now the old one is there so…. I thought that the new one should be around. 

> The primitive was added in the commit Nicolas quoted but I'm not sure
> the registration of the primitive in the primitive table was done.
> 
>> Stef
>> 
>> 
>> 
> 
> 
> -- 
> Cyril Ferlicot
> https://ferlicot.fr
> 

Re: [Pharo-dev] About

[Nicolas Cellier]

Hi Stephane,
If you google 'vm-dev VMMaker.oscog-sk.2367'
and click one of the first hits
https://marc.info/?l=squeak-vm-dev=152413936110744=2

you'll see the changes from Sophie:
The new InterpreterPrimitives>>primitiveCompareWith should be linked to
primitive 158.
(and only for ByteString comparison).

I did not try it, I have not much time to invest at the moment.

Le mer. 10 avr. 2019 à 13:52, ducasse  a écrit :

> Nicolas
>
> I tried to find the new primitive and I did not find it here
>
>
> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/src/plugins/MiscPrimitivePlugin/MiscPrimitivePlugin.c
>
> I found the old one.
> Did I look in the wrong place?
>
> Stef
>
> On 10 Apr 2019, at 13:46, ducasse  wrote:
>
> Thanks nicolas so we can use them then.
>
> On 10 Apr 2019, at 11:59, Nicolas Cellier <
> nicolas.cellier.aka.n...@gmail.com> wrote:
>
> VMMaker.oscog-sk.2367
> Author: sk
> Time: 19 April 2018, 12:02:35.661622 pm
> UUID: 0c2401e3-1450-4f73-8e81-958f50171595
> Ancestors: VMMaker.oscog- nice.2366
>
> ** new primitive to compare strings (slang + JIT)
> answers negative smi, 0 or positive smi (instead of 1, 2 or 3 in the
> MiscPlugin)
>
> * Slang (primitiveCompareWith)
> order is optionnal.
> comparison loop performed in rawCompare: string1 length: strLength1 with:
> string2 length: strLength2 accessBlock: accessBlock
>
> * JIT (genPrimitiveStringCompareWith)
> the JIT primitive does not take order as parameter (assumed asciiOrder)
> quick jump if one of the strings is empty
>
> Le mer. 10 avr. 2019 à 11:56, ducasse  a écrit :
>
>>
>>
>> On 10 Apr 2019, at 11:42, Cyril Ferlicot 
>> wrote:
>>
>> On Wed, Apr 10, 2019 at 10:42 AM Stéphane Ducasse
>>  wrote:
>>
>>
>> Hi
>>
>> I recall that clement told me that returning 1,2 or 3 instead of
>> negative, zero, positive was slow.
>> And I wonder if the primitive got change to the logic clement proposed?
>>
>> Could we not introduce another primitive and use it from the image?
>>
>>
>> Hi,
>>
>> I think Sophie already did most of the work to introduce a new
>> primitive. The missing steps to use the new optimized way to compare
>> strings are:
>> - Add the primitive to the primitive table VM side for Pharo/Squeak and
>> Newspeak
>>
>>
>> If you know that it is done from the VM side let us know.
>>
>> - Use the new primitive in the image and call this one for string
>> comparison
>>
>> With this new primitive performances on string comparison can be
>> improved around x2.5 to x5 times faster.
>>
>>
>> compare: string1 with: string2 collated: order
>> "Return 1, 2 or 3, if string1 is <, =, or > string2, with the collating
>> order of characters given by the order array."
>>
>> | len1 len2 c1 c2 |
>> 
>> 
>> 
>> 
>>
>> len1 := string1 size.
>> len2 := string2 size.
>> 1 to: (len1 min: len2) do:
>> [:i |
>> c1 := order at: (string1 basicAt: i) + 1.
>> c2 := order at: (string2 basicAt: i) + 1.
>> c1 = c2 ifFalse:
>> [c1 < c2 ifTrue: [^ 1] ifFalse: [^ 3]]].
>> len1 = len2 ifTrue: [^ 2].
>> len1 < len2 ifTrue: [^ 1] ifFalse: [^ 3].
>>
>> 
>> Stéphane Ducasse
>> http://stephane.ducasse.free.fr
>> http://www.synectique.eu / http://www.pharo.org
>> 03 59 35 87 52
>> Assistant: Julie Jonas
>> FAX 03 59 57 78 50
>> TEL 03 59 35 86 16
>> S. Ducasse - Inria
>> 40, avenue Halley,
>> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
>> Villeneuve d'Ascq 59650
>> France
>>
>>
>>
>> --
>> Cyril Ferlicot
>> https://ferlicot.fr
>>
>>
>>
>
>

Re: [Pharo-dev] About

[Cyril Ferlicot]

On Wed, Apr 10, 2019 at 1:52 PM ducasse  wrote:
>
> Nicolas
>
> I tried to find the new primitive and I did not find it here
>
> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/src/plugins/MiscPrimitivePlugin/MiscPrimitivePlugin.c
>
> I found the old one.
> Did I look in the wrong place?
>

If I am not wrong it is directly in Slang and will be a numbered primitive.

The primitive was added in the commit Nicolas quoted but I'm not sure
the registration of the primitive in the primitive table was done.

> Stef
>
>
>


-- 
Cyril Ferlicot
https://ferlicot.fr

Re: [Pharo-dev] About

[ducasse]

Nicolas 

I tried to find the new primitive and I did not find it here

https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/src/plugins/MiscPrimitivePlugin/MiscPrimitivePlugin.c

I found the old one. 
Did I look in the wrong place?

Stef

> On 10 Apr 2019, at 13:46, ducasse  wrote:
> 
> Thanks nicolas so we can use them then. 
> 
>> On 10 Apr 2019, at 11:59, Nicolas Cellier 
>> > > wrote:
>> 
>> VMMaker.oscog-sk.2367
>> Author: sk
>> Time: 19 April 2018, 12:02:35.661622 pm
>> UUID: 0c2401e3-1450-4f73-8e81-958f50171595
>> Ancestors: VMMaker.oscog- nice.2366
>> 
>> ** new primitive to compare strings (slang + JIT)
>> answers negative smi, 0 or positive smi (instead of 1, 2 or 3 in the 
>> MiscPlugin)
>> 
>> * Slang (primitiveCompareWith)
>> order is optionnal. 
>> comparison loop performed in rawCompare: string1 length: strLength1 with: 
>> string2 length: strLength2 accessBlock: accessBlock
>> 
>> * JIT (genPrimitiveStringCompareWith)
>> the JIT primitive does not take order as parameter (assumed asciiOrder)
>> quick jump if one of the strings is empty
>> 
>> Le mer. 10 avr. 2019 à 11:56, ducasse > > a écrit :
>> 
>> 
>>> On 10 Apr 2019, at 11:42, Cyril Ferlicot >> > wrote:
>>> 
>>> On Wed, Apr 10, 2019 at 10:42 AM Stéphane Ducasse
>>> mailto:stephane.duca...@inria.fr>> wrote:
 
 Hi
 
 I recall that clement told me that returning 1,2 or 3 instead of negative, 
 zero, positive was slow.
 And I wonder if the primitive got change to the logic clement proposed?
 
 Could we not introduce another primitive and use it from the image?
>>> 
>>> Hi,
>>> 
>>> I think Sophie already did most of the work to introduce a new
>>> primitive. The missing steps to use the new optimized way to compare
>>> strings are:
>>> - Add the primitive to the primitive table VM side for Pharo/Squeak and 
>>> Newspeak
>> 
>> If you know that it is done from the VM side let us know. 
>> 
>>> - Use the new primitive in the image and call this one for string comparison
>>> 
>>> With this new primitive performances on string comparison can be
>>> improved around x2.5 to x5 times faster.
>>> 
 
 compare: string1 with: string2 collated: order
 "Return 1, 2 or 3, if string1 is <, =, or > string2, with the collating 
 order of characters given by the order array."
 
 | len1 len2 c1 c2 |
 
 
 
 
 
 len1 := string1 size.
 len2 := string2 size.
 1 to: (len1 min: len2) do:
 [:i |
 c1 := order at: (string1 basicAt: i) + 1.
 c2 := order at: (string2 basicAt: i) + 1.
 c1 = c2 ifFalse:
 [c1 < c2 ifTrue: [^ 1] ifFalse: [^ 3]]].
 len1 = len2 ifTrue: [^ 2].
 len1 < len2 ifTrue: [^ 1] ifFalse: [^ 3].
 
 
 Stéphane Ducasse
 http://stephane.ducasse.free.fr 
 http://www.synectique.eu  / 
 http://www.pharo.org 
 03 59 35 87 52
 Assistant: Julie Jonas
 FAX 03 59 57 78 50
 TEL 03 59 35 86 16
 S. Ducasse - Inria
 40, avenue Halley,
 Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
 Villeneuve d'Ascq 59650
 France
 
>>> 
>>> 
>>> -- 
>>> Cyril Ferlicot
>>> https://ferlicot.fr 
> 

Re: [Pharo-dev] About

[ducasse]

Thanks nicolas so we can use them then. 

> On 10 Apr 2019, at 11:59, Nicolas Cellier 
>  wrote:
> 
> VMMaker.oscog-sk.2367
> Author: sk
> Time: 19 April 2018, 12:02:35.661622 pm
> UUID: 0c2401e3-1450-4f73-8e81-958f50171595
> Ancestors: VMMaker.oscog- nice.2366
> 
> ** new primitive to compare strings (slang + JIT)
> answers negative smi, 0 or positive smi (instead of 1, 2 or 3 in the 
> MiscPlugin)
> 
> * Slang (primitiveCompareWith)
> order is optionnal. 
> comparison loop performed in rawCompare: string1 length: strLength1 with: 
> string2 length: strLength2 accessBlock: accessBlock
> 
> * JIT (genPrimitiveStringCompareWith)
> the JIT primitive does not take order as parameter (assumed asciiOrder)
> quick jump if one of the strings is empty
> 
> Le mer. 10 avr. 2019 à 11:56, ducasse  > a écrit :
> 
> 
>> On 10 Apr 2019, at 11:42, Cyril Ferlicot > > wrote:
>> 
>> On Wed, Apr 10, 2019 at 10:42 AM Stéphane Ducasse
>> mailto:stephane.duca...@inria.fr>> wrote:
>>> 
>>> Hi
>>> 
>>> I recall that clement told me that returning 1,2 or 3 instead of negative, 
>>> zero, positive was slow.
>>> And I wonder if the primitive got change to the logic clement proposed?
>>> 
>>> Could we not introduce another primitive and use it from the image?
>> 
>> Hi,
>> 
>> I think Sophie already did most of the work to introduce a new
>> primitive. The missing steps to use the new optimized way to compare
>> strings are:
>> - Add the primitive to the primitive table VM side for Pharo/Squeak and 
>> Newspeak
> 
> If you know that it is done from the VM side let us know. 
> 
>> - Use the new primitive in the image and call this one for string comparison
>> 
>> With this new primitive performances on string comparison can be
>> improved around x2.5 to x5 times faster.
>> 
>>> 
>>> compare: string1 with: string2 collated: order
>>> "Return 1, 2 or 3, if string1 is <, =, or > string2, with the collating 
>>> order of characters given by the order array."
>>> 
>>> | len1 len2 c1 c2 |
>>> 
>>> 
>>> 
>>> 
>>> 
>>> len1 := string1 size.
>>> len2 := string2 size.
>>> 1 to: (len1 min: len2) do:
>>> [:i |
>>> c1 := order at: (string1 basicAt: i) + 1.
>>> c2 := order at: (string2 basicAt: i) + 1.
>>> c1 = c2 ifFalse:
>>> [c1 < c2 ifTrue: [^ 1] ifFalse: [^ 3]]].
>>> len1 = len2 ifTrue: [^ 2].
>>> len1 < len2 ifTrue: [^ 1] ifFalse: [^ 3].
>>> 
>>> 
>>> Stéphane Ducasse
>>> http://stephane.ducasse.free.fr 
>>> http://www.synectique.eu  / http://www.pharo.org 
>>> 
>>> 03 59 35 87 52
>>> Assistant: Julie Jonas
>>> FAX 03 59 57 78 50
>>> TEL 03 59 35 86 16
>>> S. Ducasse - Inria
>>> 40, avenue Halley,
>>> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
>>> Villeneuve d'Ascq 59650
>>> France
>>> 
>> 
>> 
>> -- 
>> Cyril Ferlicot
>> https://ferlicot.fr 

Re: [Pharo-dev] About

[Nicolas Cellier]

VMMaker.oscog-sk.2367
Author: sk
Time: 19 April 2018, 12:02:35.661622 pm
UUID: 0c2401e3-1450-4f73-8e81-958f50171595
Ancestors: VMMaker.oscog- nice.2366

** new primitive to compare strings (slang + JIT)
answers negative smi, 0 or positive smi (instead of 1, 2 or 3 in the
MiscPlugin)

* Slang (primitiveCompareWith)
order is optionnal.
comparison loop performed in rawCompare: string1 length: strLength1 with:
string2 length: strLength2 accessBlock: accessBlock

* JIT (genPrimitiveStringCompareWith)
the JIT primitive does not take order as parameter (assumed asciiOrder)
quick jump if one of the strings is empty

Le mer. 10 avr. 2019 à 11:56, ducasse  a écrit :

>
>
> On 10 Apr 2019, at 11:42, Cyril Ferlicot  wrote:
>
> On Wed, Apr 10, 2019 at 10:42 AM Stéphane Ducasse
>  wrote:
>
>
> Hi
>
> I recall that clement told me that returning 1,2 or 3 instead of negative,
> zero, positive was slow.
> And I wonder if the primitive got change to the logic clement proposed?
>
> Could we not introduce another primitive and use it from the image?
>
>
> Hi,
>
> I think Sophie already did most of the work to introduce a new
> primitive. The missing steps to use the new optimized way to compare
> strings are:
> - Add the primitive to the primitive table VM side for Pharo/Squeak and
> Newspeak
>
>
> If you know that it is done from the VM side let us know.
>
> - Use the new primitive in the image and call this one for string
> comparison
>
> With this new primitive performances on string comparison can be
> improved around x2.5 to x5 times faster.
>
>
> compare: string1 with: string2 collated: order
> "Return 1, 2 or 3, if string1 is <, =, or > string2, with the collating
> order of characters given by the order array."
>
> | len1 len2 c1 c2 |
> 
> 
> 
> 
>
> len1 := string1 size.
> len2 := string2 size.
> 1 to: (len1 min: len2) do:
> [:i |
> c1 := order at: (string1 basicAt: i) + 1.
> c2 := order at: (string2 basicAt: i) + 1.
> c1 = c2 ifFalse:
> [c1 < c2 ifTrue: [^ 1] ifFalse: [^ 3]]].
> len1 = len2 ifTrue: [^ 2].
> len1 < len2 ifTrue: [^ 1] ifFalse: [^ 3].
>
> 
> Stéphane Ducasse
> http://stephane.ducasse.free.fr
> http://www.synectique.eu / http://www.pharo.org
> 03 59 35 87 52
> Assistant: Julie Jonas
> FAX 03 59 57 78 50
> TEL 03 59 35 86 16
> S. Ducasse - Inria
> 40, avenue Halley,
> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
> Villeneuve d'Ascq 59650
> France
>
>
>
> --
> Cyril Ferlicot
> https://ferlicot.fr
>
>
>

Re: [Pharo-dev] About

[ducasse]

> On 10 Apr 2019, at 11:42, Cyril Ferlicot  wrote:
> 
> On Wed, Apr 10, 2019 at 10:42 AM Stéphane Ducasse
> mailto:stephane.duca...@inria.fr>> wrote:
>> 
>> Hi
>> 
>> I recall that clement told me that returning 1,2 or 3 instead of negative, 
>> zero, positive was slow.
>> And I wonder if the primitive got change to the logic clement proposed?
>> 
>> Could we not introduce another primitive and use it from the image?
> 
> Hi,
> 
> I think Sophie already did most of the work to introduce a new
> primitive. The missing steps to use the new optimized way to compare
> strings are:
> - Add the primitive to the primitive table VM side for Pharo/Squeak and 
> Newspeak

If you know that it is done from the VM side let us know. 

> - Use the new primitive in the image and call this one for string comparison
> 
> With this new primitive performances on string comparison can be
> improved around x2.5 to x5 times faster.
> 
>> 
>> compare: string1 with: string2 collated: order
>> "Return 1, 2 or 3, if string1 is <, =, or > string2, with the collating 
>> order of characters given by the order array."
>> 
>> | len1 len2 c1 c2 |
>> 
>> 
>> 
>> 
>> 
>> len1 := string1 size.
>> len2 := string2 size.
>> 1 to: (len1 min: len2) do:
>> [:i |
>> c1 := order at: (string1 basicAt: i) + 1.
>> c2 := order at: (string2 basicAt: i) + 1.
>> c1 = c2 ifFalse:
>> [c1 < c2 ifTrue: [^ 1] ifFalse: [^ 3]]].
>> len1 = len2 ifTrue: [^ 2].
>> len1 < len2 ifTrue: [^ 1] ifFalse: [^ 3].
>> 
>> 
>> Stéphane Ducasse
>> http://stephane.ducasse.free.fr
>> http://www.synectique.eu / http://www.pharo.org
>> 03 59 35 87 52
>> Assistant: Julie Jonas
>> FAX 03 59 57 78 50
>> TEL 03 59 35 86 16
>> S. Ducasse - Inria
>> 40, avenue Halley,
>> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
>> Villeneuve d'Ascq 59650
>> France
>> 
> 
> 
> -- 
> Cyril Ferlicot
> https://ferlicot.fr 

Re: [Pharo-dev] About

[Cyril Ferlicot]

On Wed, Apr 10, 2019 at 10:42 AM Stéphane Ducasse
 wrote:
>
> Hi
>
> I recall that clement told me that returning 1,2 or 3 instead of negative, 
> zero, positive was slow.
> And I wonder if the primitive got change to the logic clement proposed?
>
> Could we not introduce another primitive and use it from the image?

Hi,

I think Sophie already did most of the work to introduce a new
primitive. The missing steps to use the new optimized way to compare
strings are:
- Add the primitive to the primitive table VM side for Pharo/Squeak and Newspeak
- Use the new primitive in the image and call this one for string comparison

With this new primitive performances on string comparison can be
improved around x2.5 to x5 times faster.

>
> compare: string1 with: string2 collated: order
> "Return 1, 2 or 3, if string1 is <, =, or > string2, with the collating order 
> of characters given by the order array."
>
> | len1 len2 c1 c2 |
> 
> 
> 
> 
>
> len1 := string1 size.
> len2 := string2 size.
> 1 to: (len1 min: len2) do:
> [:i |
> c1 := order at: (string1 basicAt: i) + 1.
> c2 := order at: (string2 basicAt: i) + 1.
> c1 = c2 ifFalse:
> [c1 < c2 ifTrue: [^ 1] ifFalse: [^ 3]]].
> len1 = len2 ifTrue: [^ 2].
> len1 < len2 ifTrue: [^ 1] ifFalse: [^ 3].
>
> 
> Stéphane Ducasse
> http://stephane.ducasse.free.fr
> http://www.synectique.eu / http://www.pharo.org
> 03 59 35 87 52
> Assistant: Julie Jonas
> FAX 03 59 57 78 50
> TEL 03 59 35 86 16
> S. Ducasse - Inria
> 40, avenue Halley,
> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
> Villeneuve d'Ascq 59650
> France
>


-- 
Cyril Ferlicot
https://ferlicot.fr

[Pharo-dev] About

[Stéphane Ducasse]

Hi 

I recall that clement told me that returning 1,2 or 3 instead of negative, 
zero, positive was slow.
And I wonder if the primitive got change to the logic clement proposed?

Could we not introduce another primitive and use it from the image?

compare: string1 with: string2 collated: order
"Return 1, 2 or 3, if string1 is <, =, or > string2, with the collating 
order of characters given by the order array."

| len1 len2 c1 c2 |






len1 := string1 size.
len2 := string2 size.
1 to: (len1 min: len2) do:
[:i |
c1 := order at: (string1 basicAt: i) + 1.
c2 := order at: (string2 basicAt: i) + 1.
c1 = c2 ifFalse: 
[c1 < c2 ifTrue: [^ 1] ifFalse: [^ 3]]].
len1 = len2 ifTrue: [^ 2].
len1 < len2 ifTrue: [^ 1] ifFalse: [^ 3].


Stéphane Ducasse
http://stephane.ducasse.free.fr
http://www.synectique.eu / http://www.pharo.org 
03 59 35 87 52
Assistant: Julie Jonas 
FAX 03 59 57 78 50
TEL 03 59 35 86 16
S. Ducasse - Inria
40, avenue Halley, 
Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
Villeneuve d'Ascq 59650
France

Re: [Pharo-dev] About a better filedialog

[ducasse]

> On 21 Mar 2019, at 10:14, Hilaire  wrote:
> 
> Peter's FileDialog looks so much better than FileList :)

:)

Stef
> 
> Le 20/03/2019 à 20:09, ducasse a écrit :
>> I was thinking the FileList.
>> Now I will look at the FileDialogWindow :)
>> 
>> Stef
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> 
> 
> 

Re: [Pharo-dev] About a better filedialog

[Hilaire]

Peter's FileDialog looks so much better than FileList :)

Le 20/03/2019 à 20:09, ducasse a écrit :
> I was thinking the FileList.
> Now I will look at the FileDialogWindow :)
>
> Stef

-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-dev] About a better filedialog

[Esteban Lorenzano]

Hi,

While a good FileDialog may have a preview… I think the best thing is that you 
can take the component and reuse it, adding the behaviour you want.
At least, that would be the purpose of Spec, isn’t?

So… you could not wait until someone add a preview and you could add the 
preview you like it :)

Esteban

Ps: Of course, I know that means time… and I know a new component has to 
provide the same functionalities as the older one at least. I was just pointing 
it :)


> On 20 Mar 2019, at 20:11, ducasse  wrote:
> 
> I checked and they are not related. 
> And we can keep for now the DileDialogWindow. 
> 
> Stef
> 
>> On 20 Mar 2019, at 20:09, ducasse  wrote:
>> 
>> 
>> 
>>> On 20 Mar 2019, at 19:29, Hilaire  wrote:
>>> 
>>> Ah, may be we are not talking about the same tool. I am talking about
>>> the FileDialogWindow, I think part of the Gary's Polymorph. And you
>>> about FileList according to your screenshot.
>>> 
>>> Is Peter's FileDialog intend is to replace FileList? Or FileDialogWindow?
>> 
>> I was thinking the FileList.
>> Now I will look at the FileDialogWindow :)
>> 
>> Stef
>>> 
>>> Hilaire
>>> 
>>> 
>>> Le 20/03/2019 à 19:13, ducasse a écrit :
 Ok I see and how the preview is done?
 You register some objects to the fileDialog?
 Because I get this one. 
 
 So may be we are talking about a different one.
 
>>> -- 
>>> Dr. Geo
>>> http://drgeo.eu
>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
> 
> 

Re: [Pharo-dev] About a better filedialog

[ducasse]

I checked and they are not related. 
And we can keep for now the DileDialogWindow. 

Stef

> On 20 Mar 2019, at 20:09, ducasse  wrote:
> 
> 
> 
>> On 20 Mar 2019, at 19:29, Hilaire  wrote:
>> 
>> Ah, may be we are not talking about the same tool. I am talking about
>> the FileDialogWindow, I think part of the Gary's Polymorph. And you
>> about FileList according to your screenshot.
>> 
>> Is Peter's FileDialog intend is to replace FileList? Or FileDialogWindow?
> 
> I was thinking the FileList.
> Now I will look at the FileDialogWindow :)
> 
> Stef
>> 
>> Hilaire
>> 
>> 
>> Le 20/03/2019 à 19:13, ducasse a écrit :
>>> Ok I see and how the preview is done?
>>> You register some objects to the fileDialog?
>>> Because I get this one. 
>>> 
>>> So may be we are talking about a different one.
>>> 
>> -- 
>> Dr. Geo
>> http://drgeo.eu
>> 
>> 
>> 
> 
> 
> 

Re: [Pharo-dev] About a better filedialog

[ducasse]

> On 20 Mar 2019, at 19:29, Hilaire  wrote:
> 
> Ah, may be we are not talking about the same tool. I am talking about
> the FileDialogWindow, I think part of the Gary's Polymorph. And you
> about FileList according to your screenshot.
> 
> Is Peter's FileDialog intend is to replace FileList? Or FileDialogWindow?

I was thinking the FileList.
Now I will look at the FileDialogWindow :)

Stef
> 
> Hilaire
> 
> 
> Le 20/03/2019 à 19:13, ducasse a écrit :
>> Ok I see and how the preview is done?
>> You register some objects to the fileDialog?
>> Because I get this one. 
>> 
>> So may be we are talking about a different one.
>> 
> -- 
> Dr. Geo
> http://drgeo.eu
> 
> 
> 

Re: [Pharo-dev] About a better filedialog

[Hilaire]

Ah, may be we are not talking about the same tool. I am talking about
the FileDialogWindow, I think part of the Gary's Polymorph. And you
about FileList according to your screenshot.

Is Peter's FileDialog intend is to replace FileList? Or FileDialogWindow?

Hilaire


Le 20/03/2019 à 19:13, ducasse a écrit :
> Ok I see and how the preview is done?
> You register some objects to the fileDialog?
> Because I get this one. 
>
> So may be we are talking about a different one.
>
-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-dev] About a better filedialog

[ducasse]

> On 19 Mar 2019, at 20:35, Hilaire  wrote:
> 
> For DrGeo, when loading a sketch from an arbitrary location,  I use the
> preview feature of the polymorph File Dialog. I don't see it in this
> simple replacement of File Dialog.


Can you send a snippet so that I can see what it means because I do not 
understand
exactly how this is related to the fileDialog. 

Stef

> 
> Hilaire
> 
> Le 18/03/2019 à 20:31, ducasse a écrit :
>> what do you think?
>> 
>>  https://github.com/Ducasse/file-dialog
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> 
> 
> 

Re: [Pharo-dev] About a better filedialog

[Hilaire]

Something as simple as in the current filedialog will be far than
enough: an option to toggle a preview display. It is then the
responsibility of the user to code the preview view.

I am afraid an inspector view will look too hackish for a user like a
teacher or a kid.

Hilaire

Le 19/03/2019 à 20:42, Peter Uhnak a écrit :
> Preview is indeed not supported. My original idea was to show a
> regular GTInspector view on the file, but I never got around to
> implementing it.

-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-dev] About a better filedialog

[Peter Uhnak]

Preview is indeed not supported. My original idea was to show a regular
GTInspector view on the file, but I never got around to implementing it.

On Tue, Mar 19, 2019 at 8:36 PM Hilaire  wrote:

> For DrGeo, when loading a sketch from an arbitrary location,  I use the
> preview feature of the polymorph File Dialog. I don't see it in this
> simple replacement of File Dialog.
>
> Hilaire
>
> Le 18/03/2019 à 20:31, ducasse a écrit :
> > what do you think?
> >
> >   https://github.com/Ducasse/file-dialog
>
> --
> Dr. Geo
> http://drgeo.eu
>
>
>
>

Re: [Pharo-dev] About a better filedialog

[Hilaire]

For DrGeo, when loading a sketch from an arbitrary location,  I use the
preview feature of the polymorph File Dialog. I don't see it in this
simple replacement of File Dialog.

Hilaire

Le 18/03/2019 à 20:31, ducasse a écrit :
> what do you think?
>
>   https://github.com/Ducasse/file-dialog

-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-dev] About a better filedialog

[ducasse]

and there are tests. 
We should check the UIManager dependency. 
For now I just make it works in P7

Stef

> On 19 Mar 2019, at 09:50, Guillermo Polito  wrote:
> 
> YES!
> 
> On Mon, Mar 18, 2019 at 11:13 PM ducasse  <mailto:steph...@netcourrier.com>> wrote:
> Yes I had to rename ComposableModel into ComposablePresenter so this is 
> probably that
> 
>> On 18 Mar 2019, at 23:09, Peter Uhnak > <mailto:i.uh...@gmail.com>> wrote:
>> 
>> Thanks Stef!
>> 
>> The build is failing for Pharo 6.1 for some reason (I can't reproduce it 
>> locally), but I can look at that during the weekend...
>> 
>> Peter
>> 
>> On Mon, Mar 18, 2019 at 9:23 PM ducasse > <mailto:steph...@netcourrier.com>> wrote:
>> Alex 
>> 
>> Have a look at the one I propose and play with it. 
>> Let me know what you think.
>> 
>> Stef
>> 
>>> On 18 Mar 2019, at 21:20, Alexandre Bergel >> <mailto:alexandre.ber...@me.com>> wrote:
>>> 
>>> 
>>> From: Alexandre Bergel >> <mailto:alexandre.ber...@me.com>>
>>> Subject: Re: [Pharo-dev] About a better filedialog
>>> Date: 18 March 2019 at 21:20:35 CET
>>> To: Pharo Development List >> <mailto:pharo-dev@lists.pharo.org>>
>>> 
>>> 
>>> I do not have time to personally work on this. But yes, having a better 
>>> file dialog would be fantastic
>>> 
>>> Alexandre
>>> 
>>>> On Mar 18, 2019, at 4:31 PM, ducasse >>> <mailto:steph...@netcourrier.com>> wrote:
>>>> 
>>>> Hi guys 
>>>> 
>>>> I did a pass (ported to P7, tonel, some little fixes) on the file-dialog 
>>>> developed by Peter Uhnak and I think that it would be good to propose it 
>>>> by default in the image. 
>>>> what do you think?
>>>> 
>>>>https://github.com/Ducasse/file-dialog 
>>>> <https://github.com/Ducasse/file-dialog>
>>>> 
>>>> I would also like that the filedialog remembers the last list of visited 
>>>> directory. (I will see if I can add this). 
>>>> When Spec2 is out I would like to port it to Spec2. 
>>>> 
>>>> Does anybody want to help? Because it would be super nice and I’m full 
>>>> with cleaning textEditor and pluggableTextMorph. 
>>>> 
>>>> Stef
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> 
>> 
> 
> 
> 
> -- 
>
> Guille Polito
> Research Engineer
> 
> Centre de Recherche en Informatique, Signal et Automatique de Lille
> CRIStAL - UMR 9189
> 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] About a better filedialog

[Peter Uhnak]

Ah, I probably need to add dependency on the Spec Compat library for P6.1

On Tue, Mar 19, 2019 at 9:50 AM Guillermo Polito 
wrote:

> YES!
>
> On Mon, Mar 18, 2019 at 11:13 PM ducasse  wrote:
>
>> Yes I had to rename ComposableModel into ComposablePresenter so this is
>> probably that
>>
>> On 18 Mar 2019, at 23:09, Peter Uhnak  wrote:
>>
>> Thanks Stef!
>>
>> The build is failing for Pharo 6.1 for some reason (I can't reproduce it
>> locally), but I can look at that during the weekend...
>>
>> Peter
>>
>> On Mon, Mar 18, 2019 at 9:23 PM ducasse  wrote:
>>
>>> Alex
>>>
>>> Have a look at the one I propose and play with it.
>>> Let me know what you think.
>>>
>>> Stef
>>>
>>> On 18 Mar 2019, at 21:20, Alexandre Bergel 
>>> wrote:
>>>
>>>
>>> *From: *Alexandre Bergel 
>>> *Subject: **Re: [Pharo-dev] About a better filedialog*
>>> *Date: *18 March 2019 at 21:20:35 CET
>>> *To: *Pharo Development List 
>>>
>>>
>>> I do not have time to personally work on this. But yes, having a better
>>> file dialog would be fantastic
>>>
>>> Alexandre
>>>
>>> On Mar 18, 2019, at 4:31 PM, ducasse  wrote:
>>>
>>> Hi guys
>>>
>>> I did a pass (ported to P7, tonel, some little fixes) on the file-dialog
>>> developed by Peter Uhnak and I think that it would be good to propose it by
>>> default in the image.
>>> what do you think?
>>>
>>> https://github.com/Ducasse/file-dialog
>>>
>>> I would also like that the filedialog remembers the last list of visited
>>> directory. (I will see if I can add this).
>>> When Spec2 is out I would like to port it to Spec2.
>>>
>>> Does anybody want to help? Because it would be super nice and I’m full
>>> with cleaning textEditor and pluggableTextMorph.
>>>
>>> Stef
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
> --
>
>
>
> Guille Polito
>
> Research Engineer
>
> Centre de Recherche en Informatique, Signal et Automatique de Lille
>
> CRIStAL - UMR 9189
>
> 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] About a better filedialog

[Guillermo Polito]

YES!

On Mon, Mar 18, 2019 at 11:13 PM ducasse  wrote:

> Yes I had to rename ComposableModel into ComposablePresenter so this is
> probably that
>
> On 18 Mar 2019, at 23:09, Peter Uhnak  wrote:
>
> Thanks Stef!
>
> The build is failing for Pharo 6.1 for some reason (I can't reproduce it
> locally), but I can look at that during the weekend...
>
> Peter
>
> On Mon, Mar 18, 2019 at 9:23 PM ducasse  wrote:
>
>> Alex
>>
>> Have a look at the one I propose and play with it.
>> Let me know what you think.
>>
>> Stef
>>
>> On 18 Mar 2019, at 21:20, Alexandre Bergel 
>> wrote:
>>
>>
>> *From: *Alexandre Bergel 
>> *Subject: **Re: [Pharo-dev] About a better filedialog*
>> *Date: *18 March 2019 at 21:20:35 CET
>> *To: *Pharo Development List 
>>
>>
>> I do not have time to personally work on this. But yes, having a better
>> file dialog would be fantastic
>>
>> Alexandre
>>
>> On Mar 18, 2019, at 4:31 PM, ducasse  wrote:
>>
>> Hi guys
>>
>> I did a pass (ported to P7, tonel, some little fixes) on the file-dialog
>> developed by Peter Uhnak and I think that it would be good to propose it by
>> default in the image.
>> what do you think?
>>
>> https://github.com/Ducasse/file-dialog
>>
>> I would also like that the filedialog remembers the last list of visited
>> directory. (I will see if I can add this).
>> When Spec2 is out I would like to port it to Spec2.
>>
>> Does anybody want to help? Because it would be super nice and I’m full
>> with cleaning textEditor and pluggableTextMorph.
>>
>> Stef
>>
>>
>>
>>
>>
>>
>>
>>
>>
>

-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

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] About a better filedialog

[ducasse]

Yes I had to rename ComposableModel into ComposablePresenter so this is 
probably that

> On 18 Mar 2019, at 23:09, Peter Uhnak  wrote:
> 
> Thanks Stef!
> 
> The build is failing for Pharo 6.1 for some reason (I can't reproduce it 
> locally), but I can look at that during the weekend...
> 
> Peter
> 
> On Mon, Mar 18, 2019 at 9:23 PM ducasse  <mailto:steph...@netcourrier.com>> wrote:
> Alex 
> 
> Have a look at the one I propose and play with it. 
> Let me know what you think.
> 
> Stef
> 
>> On 18 Mar 2019, at 21:20, Alexandre Bergel > <mailto:alexandre.ber...@me.com>> wrote:
>> 
>> 
>> From: Alexandre Bergel > <mailto:alexandre.ber...@me.com>>
>> Subject: Re: [Pharo-dev] About a better filedialog
>> Date: 18 March 2019 at 21:20:35 CET
>> To: Pharo Development List > <mailto:pharo-dev@lists.pharo.org>>
>> 
>> 
>> I do not have time to personally work on this. But yes, having a better file 
>> dialog would be fantastic
>> 
>> Alexandre
>> 
>>> On Mar 18, 2019, at 4:31 PM, ducasse >> <mailto:steph...@netcourrier.com>> wrote:
>>> 
>>> Hi guys 
>>> 
>>> I did a pass (ported to P7, tonel, some little fixes) on the file-dialog 
>>> developed by Peter Uhnak and I think that it would be good to propose it by 
>>> default in the image. 
>>> what do you think?
>>> 
>>> https://github.com/Ducasse/file-dialog 
>>> <https://github.com/Ducasse/file-dialog>
>>> 
>>> I would also like that the filedialog remembers the last list of visited 
>>> directory. (I will see if I can add this). 
>>> When Spec2 is out I would like to port it to Spec2. 
>>> 
>>> Does anybody want to help? Because it would be super nice and I’m full with 
>>> cleaning textEditor and pluggableTextMorph. 
>>> 
>>> Stef
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> 
> 

Re: [Pharo-dev] About a better filedialog

[Peter Uhnak]

Thanks Stef!

The build is failing for Pharo 6.1 for some reason (I can't reproduce it
locally), but I can look at that during the weekend...

Peter

On Mon, Mar 18, 2019 at 9:23 PM ducasse  wrote:

> Alex
>
> Have a look at the one I propose and play with it.
> Let me know what you think.
>
> Stef
>
> On 18 Mar 2019, at 21:20, Alexandre Bergel 
> wrote:
>
>
> *From: *Alexandre Bergel 
> *Subject: **Re: [Pharo-dev] About a better filedialog*
> *Date: *18 March 2019 at 21:20:35 CET
> *To: *Pharo Development List 
>
>
> I do not have time to personally work on this. But yes, having a better
> file dialog would be fantastic
>
> Alexandre
>
> On Mar 18, 2019, at 4:31 PM, ducasse  wrote:
>
> Hi guys
>
> I did a pass (ported to P7, tonel, some little fixes) on the file-dialog
> developed by Peter Uhnak and I think that it would be good to propose it by
> default in the image.
> what do you think?
>
> https://github.com/Ducasse/file-dialog
>
> I would also like that the filedialog remembers the last list of visited
> directory. (I will see if I can add this).
> When Spec2 is out I would like to port it to Spec2.
>
> Does anybody want to help? Because it would be super nice and I’m full
> with cleaning textEditor and pluggableTextMorph.
>
> Stef
>
>
>
>
>
>
>
>
>

Re: [Pharo-dev] About a better filedialog

[ducasse]

Alex 

Have a look at the one I propose and play with it. 
Let me know what you think.

Stef

> On 18 Mar 2019, at 21:20, Alexandre Bergel  wrote:
> 
> 
> From: Alexandre Bergel 
> Subject: Re: [Pharo-dev] About a better filedialog
> Date: 18 March 2019 at 21:20:35 CET
> To: Pharo Development List 
> 
> 
> I do not have time to personally work on this. But yes, having a better file 
> dialog would be fantastic
> 
> Alexandre
> 
>> On Mar 18, 2019, at 4:31 PM, ducasse  wrote:
>> 
>> Hi guys 
>> 
>> I did a pass (ported to P7, tonel, some little fixes) on the file-dialog 
>> developed by Peter Uhnak and I think that it would be good to propose it by 
>> default in the image. 
>> what do you think?
>> 
>>  https://github.com/Ducasse/file-dialog
>> 
>> I would also like that the filedialog remembers the last list of visited 
>> directory. (I will see if I can add this). 
>> When Spec2 is out I would like to port it to Spec2. 
>> 
>> Does anybody want to help? Because it would be super nice and I’m full with 
>> cleaning textEditor and pluggableTextMorph. 
>> 
>> Stef
>> 
>> 
>> 
> 
> 
> 
> 

Re: [Pharo-dev] About a better filedialog

[Alexandre Bergel via Pharo-dev]

--- Begin Message ---
I do not have time to personally work on this. But yes, having a better file 
dialog would be fantastic

Alexandre

> On Mar 18, 2019, at 4:31 PM, ducasse  wrote:
> 
> Hi guys 
> 
> I did a pass (ported to P7, tonel, some little fixes) on the file-dialog 
> developed by Peter Uhnak and I think that it would be good to propose it by 
> default in the image. 
> what do you think?
> 
>   https://github.com/Ducasse/file-dialog
> 
> I would also like that the filedialog remembers the last list of visited 
> directory. (I will see if I can add this). 
> When Spec2 is out I would like to port it to Spec2. 
> 
> Does anybody want to help? Because it would be super nice and I’m full with 
> cleaning textEditor and pluggableTextMorph. 
> 
> Stef
> 
> 
> 


--- End Message ---