Re: [Pharo-dev] Binary selector and special characters

[stepharo]

This is a really nice and important question.
I would really have a clear answer because it will make the system more 
stable.


If you can build an analysis and let us know it would be really great.


Something related but not on the same topic is that I would love to have 
a syntax for nested comments.


This is really annoying to have to uncomment parts when we have to 
comment a large part. We discussed this back in 2007-2009 but we never 
did it.



Stef


Le 28/8/16 à 12:17, Nicolai Hess a écrit :

Hi,

where can I find a good reference about what characters are allowed as
binary selectors (from old syntax definition) and what is nowadays allowed
by the implementations.

And whether the current set of allowed binaries selector includes some 
additions on

purpose or if this is just a bug of the parser.

From what I found out,  (Blue book and some other smalltalk syntax 
definitions)

the current set of allowed characters includes the "special characters":
$! $% $& $* $+ $, $- $/ $< $= $> $? $@ $\ $| $~
(some implementation do not allow $@ and some calls $- not a special 
character

but allowed as binary selector character)

And this is what String>>#numArgs uses. Therefore

'-' numArgs "->1".
'!' numArgs "->1".
And for example:
'§' numArgs "-> -1 (the -1 is indicating "not even a valid selector")"

But I am interested in the characters not called "special characters and
not even in the range 0-126.

The scanner allowes much more characters to be used as a selector name
(From the scanners typeTable) :

{Character value: 1 . Character value: 2 . Character value: 3 . 
Character value: 4 . Character value: 5 . Character value: 6 . 
Character value: 7 . Character backspace . Character value: 11 . 
Character value: 14 . Character value: 15 . Character value: 16 . 
Character value: 17 . Character value: 18 . Character value: 19 . 
Character value: 20 . Character value: 21 . Character value: 22 . 
Character value: 23 . Character value: 24 . Character value: 25 . 
Character value: 26 . Character escape . Character value: 28 . 
Character value: 29 . Character value: 30 . Character value: 31 . $! . 
$% . $& . $* . $+ . $, . $- . $/ . $< . $= . $> . $? . $@ . $\ . $` . 
$~ . Character delete . $€ . $ . $‚ . $ƒ . $„ . $… . $† . $‡ . $ˆ . $‰ 
. $Š . $‹ . $Œ . $ . $Ž . $ . $ . $‘ . $’ . $“ . $” . $• . $– . $— . 
$˜ . $™ . $š . $› . $œ . $ . $ž . $Ÿ . $  . $¡ . $¢ . $£ . $¤ . $¥ . 
$¦ . $§ . $¨ . $© . $« . $¬ . $­ . $® . $¯ . $° . $± . $² . $³ . $´ . 
$¶ . $· . $¸ . $¹ . $» . $¼ . $½ . $¾ . $¿ . $× . $÷}


This means you can define a method with for example the name "÷".

So , the question I want to ask. What do we want to allow as a binary 
selector (character).
All that is nowadays "parseable" as binary selector, or only the set 
of "special characters"
or something between both, and where to put this information, the 
"this is an allowed binary

selector character" information?

Thanks
Nicolai

Re: [Pharo-dev] About the non-use of Announcer in Bloc

[Tudor Girba]

Hi Glenn,

Thanks a lot for this experiment. Could you send us the code snippet so people 
can play with it?

The question is if perhaps we can identify a slimmer announcement support so 
that people can choose depending on requirements (e.g. parallelism or not).

Cheers,
Doru

--
www.tudorgirba.com

"Every thing has its own flow"

> On 28 Aug 2016, at 21:11, Glenn Cavarlé  wrote:
> 
> Hi all,
> Doru, Stephan, Norbert, Denis and me spoke at ESUG about the non-use of
> Announcer in Bloc. 
> I made some test cases in Bloc-Tests to compare performances between
> Announcer and BlEventRegistry.
> The result is that Announcer is at least 5x slower in all tested cases.
> Bloc has only specific needs about event dispatching,  the first one is the
> efficiency during event propagation.
> It may be interesting to investigate why Announcer is slower and also what
> are the uncovered cases in BlEventRegistry.
> So, i'm interested in continuing our discussion about that.
> 
> Regards,
> Glenn.
> 
> 
> 
> -
> Glenn Cavarlé
> --
> View this message in context: 
> http://forum.world.st/About-the-non-use-of-Announcer-in-Bloc-tp4913008.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
> 

Re: [Pharo-dev] About the non-use of Announcer in Bloc

[Henrik Nergaard]

Probably from the use of critical (mutex), the way #subscriptionsHandling: is 
done, and that Announcer is built for X number of announcers and Y number of 
subscribers, which means that each announcement the announcer has to filter and 
find the correct subscribers.


| ann a |

ann := Announcer new.

ann when: Announcement do: [ :e ].
a := Announcement new.
[[ ann announce: a ] bench ] timeProfile

-

Other drawbacks to consider when using announcements:
Memory overhead from the Announcer object and each subscription.
Memory ownership, the announcement subscriptions will strongly reference the 
announcement target unless the announcement is weakly, which can lead to memory 
leakage especially if strong and weak subscriptions are mixed in certain 
situations (see the mailing list from around the release of Pharo 6). This also 
leads to code where the announcer is the one who owns the target (multiple 
times if there are different announcements),  which makes understanding who 
references what etc.. much harder to understand.
In many places the control/message flow, and the relationship between the 
different parts of a bigger object tends to become much more difficult to 
understand (For example Rubric).

Announcer usage shines when there is a need for a common place that X objects 
can communicate  Y messages to Z recipients without needing to know who sends 
what, or who wants to receive what (For example System Announcements).

Communication when only one Object "A" announces to another Object(s) "B", is 
better implemented as A referencing B, then B implements the necessary methods 
needed for this communication. 

Best regards,
Henrik



-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Glenn 
Cavarlé
Sent: Sunday, August 28, 2016 9:11 PM
To: pharo-dev@lists.pharo.org
Subject: [Pharo-dev] About the non-use of Announcer in Bloc

Hi all,
Doru, Stephan, Norbert, Denis and me spoke at ESUG about the non-use of 
Announcer in Bloc. 
I made some test cases in Bloc-Tests to compare performances between Announcer 
and BlEventRegistry.
The result is that Announcer is at least 5x slower in all tested cases.
Bloc has only specific needs about event dispatching,  the first one is the 
efficiency during event propagation.
It may be interesting to investigate why Announcer is slower and also what are 
the uncovered cases in BlEventRegistry.
So, i'm interested in continuing our discussion about that.

Regards,
Glenn.



-
Glenn Cavarlé
--
View this message in context: 
http://forum.world.st/About-the-non-use-of-Announcer-in-Bloc-tp4913008.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] About the non-use of Announcer in Bloc

[Glenn Cavarlé]

Hi all,
Doru, Stephan, Norbert, Denis and me spoke at ESUG about the non-use of
Announcer in Bloc. 
I made some test cases in Bloc-Tests to compare performances between
Announcer and BlEventRegistry.
The result is that Announcer is at least 5x slower in all tested cases.
Bloc has only specific needs about event dispatching,  the first one is the
efficiency during event propagation.
It may be interesting to investigate why Announcer is slower and also what
are the uncovered cases in BlEventRegistry.
So, i'm interested in continuing our discussion about that.

Regards,
Glenn.



-
Glenn Cavarlé
--
View this message in context: 
http://forum.world.st/About-the-non-use-of-Announcer-in-Bloc-tp4913008.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Iceberg: success and fail

[Serge Stinckwich]

I wrote an issue here:

https://github.com/npasserini/iceberg/issues/124

There are several PRs apparently than you can push Nicolas I guess:
https://github.com/npasserini/iceberg/pulls

Thank you for the good job.


On Sat, Aug 27, 2016 at 12:06 AM, Nicolas Passerini
 wrote:
> Thank you Serge, I will pay a look at it.
>
> On Fri, Aug 26, 2016 at 11:43 PM,  wrote:
>>
>>
>>
>> Envoyé de mon iPhone
>>
>> Le 26 août 2016 à 23:34, Nicolas Passerini  a écrit
>> :
>>
>> Sorry, I didn't understand how to reproduce the problem. I understand you
>> tried to save a package to the Iceberg repository, is that right?
>> How did you create your local repository? Did you already have a git
>> repository in the same directory?
>>
>>
>> This was an existing git repo on github but without any Pharo packages. I
>> load my project from Smalltalk and try to add the packages with the Iceberg
>> tool.
>>
>>
>> (Yes, an error in the issue tracker will be appreciated, thanks!)
>>
>>
>> I will do it later.
>>
>>
>> On Fri, Aug 26, 2016 at 7:25 PM, Serge Stinckwich
>>  wrote:
>>>
>>> Hi all,
>>>
>>> I was able to do my first commit with Iceberg on github !
>>> So this is great.
>>>
>>> I'm trying now to move an existing project on SmalltalkHub on github.
>>> I made a local repository and when I try a package in this repo, I
>>> have the following error.
>>> I can put the error report on Iceberg issue tracker if needed.
>>>
>>> --
>>> Serge Stinckwich
>>> UCBN & UMI UMMISCO 209 (IRD/UPMC)
>>> Every DSL ends up being Smalltalk
>>> http://www.doesnotunderstand.org/
>>
>>
>



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

Re: [Pharo-dev] looking into Pharo VM

[Esteban Lorenzano]

> On 28 Aug 2016, at 15:38, Ben Coman  wrote:
> 
> Peter, The plan seems to be [1] to make the OpenSmalltalkVM a submodule under 
> the pharo-vm.
> 
> Esteban, Is this still the current plan, and when will this be done? I can't 
> see an osvm folder at [2] yet.  Are the build instructions there still valid? 
>   Is there anything I can do to help?

Yes, this is the plan.
Transition will be done soon (™) A couple of weeks according to my plans, let's 
see how it goes :)
Current work is in my fork, under "merge-with-osvm" branch :)

Esteban

> 
> cheers -ben
> 
> [1] 
> http://forum.world.st/The-code-in-the-src-folders-in-the-repository-td4902188.html#a4902635
> [2] https://github.com/pharo-project/pharo-vm
> 
>> On Sun, Aug 28, 2016 at 9:12 PM, Peter Uhnák  wrote:
>> > Why you say so? It is maintained, and still the official pharo 
>> > distribution.
>> 
>> Because of this:
>> 
>> which coincided with the announcement of OpenSmalltalkVM... that's why I 
>> wasn't sure what is the mainline. (Or maybe you took a vacation, which is 
>> also an explanation :)... which reminds me that I should take a vacation. :/ 
>> )
>> 
>> > Now, thinking that "looking at it" and "fixing" will be a nice and easy 
>> > (and quick) fix... Good luck with that :)
>> 
>> Well considering I spent many-o-hours just trying to figure out why copy 
>> pasting wasn't working from Chrome, I make no illusions this will be quick 
>> or easy... but at least I will feel like I am trying to end my suffering... 
>> :)
>> 
>>> On Sun, Aug 28, 2016 at 2:53 PM, Esteban Lorenzano  
>>> wrote:
>> 
>>> By the way first thing I would do is to remove FT2 plugin and see how it 
>>> works
>> 
>> I'll start with this, although there's the GrafPort (Cairo?) related crash 
>> too.
>> 
>> Plus I want to figure out how I can get crash dump on Windows...
>> 
>> Thanks!
>> Peter
> 

Re: [Pharo-dev] looking into Pharo VM

[Ben Coman]

Peter, The plan seems to be [1] to make the OpenSmalltalkVM a submodule
under the pharo-vm.

Esteban, Is this still the current plan, and when will this be done? I
can't see an osvm folder at [2] yet.  Are the build instructions there
still valid?   Is there anything I can do to help?

cheers -ben

[1]
http://forum.world.st/The-code-in-the-src-folders-in-the-repository-td4902188.html#a4902635
[2] https://github.com/pharo-project/pharo-vm

On Sun, Aug 28, 2016 at 9:12 PM, Peter Uhnák  wrote:

> > Why you say so? It is maintained, and still the official pharo
> distribution.
>
> Because of this:
> 
> which coincided with the announcement of OpenSmalltalkVM... that's why I
> wasn't sure what is the mainline. (Or maybe you took a vacation, which is
> also an explanation :)... which reminds me that I should take a vacation.
> :/ )
>
> > Now, thinking that "looking at it" and "fixing" will be a nice and easy
> (and quick) fix... Good luck with that :)
>
> Well considering I spent many-o-hours just trying to figure out why copy
> pasting wasn't working from Chrome, I make no illusions this will be quick
> or easy... but at least I will feel like I am trying to end my suffering...
> :)
>
> On Sun, Aug 28, 2016 at 2:53 PM, Esteban Lorenzano 
> wrote:
>
>> By the way first thing I would do is to remove FT2 plugin and see how it
>> works
>>
>
> I'll start with this, although there's the GrafPort (Cairo?) related crash
> too.
>
> Plus I want to figure out how I can get crash dump on Windows...
>
> Thanks!
> Peter
>

Re: [Pharo-dev] About Pharo 60

[Torsten Bergmann]

> what are the points you are working on and that would deserve more focus and 
> help from the community?

I once started with a refactored version of GetText, covered with tests and 
tools. 
Code status I reached so far is here:

  http://www.smalltalkhub.com/#!/~TorstenBergmann/Gettext

Idea was to be lean, no dependency on Seaside or others and get a well 
documented easy to use I18N solution. 
This would open up the possibility for more internationalized Pharo image and 
Pharo based apps. Would be nice
if this could be completed and become part of our infrastructure to get a wider 
audience and globally usable
applications.

Additionally I would like to see:

 - investigation in the Win Pharo VM for being able to run again as a Windows 
Service 
   (as it was possible for Squeak) to be able to easily provide, deploy and 
administrate a web 
   app on Windows

 - image size management under control (as Philip already suggested)

 - better support for REST based systems (as Philip already suggested)

 - modern "Material style" UI (as Philip already suggested) but additionally 
with
   better out of the box Spec support and examples for regular widgets 
   (Accordion, draggable Toolbars, calendar widget, date/time picker, ...)

 - clear rules to not accept undocumented classes/packages in the image
   And a clear separation in packages between CORE/BASE stuff and TESTS on top.
   Because TEST are usually only for development and for production/deployment 
of an app
   TESTS usually should be thrown out.

Christmas list would include:
 - 64 Bit support
 - an out of the box Pharo Pi VM + image on the website

Bye
T.

Re: [Pharo-dev] broken GitFileTree/IceBerg on Windows because of ProcessWrapper

[Peter Uhnak]

On Sat, Aug 27, 2016 at 08:24:32AM -0300, Hernán Morales Durand wrote:
> Just checked and the download URL is working.
> If you send me mirror URLs then I can update the configuration to support
> multiple download locations.

The University's whole website was down when I was trying to access it, now 
it's back online.
Maybe it would be good to have it on GitHub? (which would also automatically 
provide https).

Thanks,
Peter

Re: [Pharo-dev] looking into Pharo VM

[Peter Uhnák]

> Why you say so? It is maintained, and still the official pharo
distribution.

Because of this:


​
which coincided with the announcement of OpenSmalltalkVM... that's why I
wasn't sure what is the mainline. (Or maybe you took a vacation, which is
also an explanation :)... which reminds me that I should take a vacation.
:/ )

> Now, thinking that "looking at it" and "fixing" will be a nice and easy
(and quick) fix... Good luck with that :)

Well considering I spent many-o-hours just trying to figure out why copy
pasting wasn't working from Chrome, I make no illusions this will be quick
or easy... but at least I will feel like I am trying to end my suffering...
:)

On Sun, Aug 28, 2016 at 2:53 PM, Esteban Lorenzano 
wrote:

> By the way first thing I would do is to remove FT2 plugin and see how it
> works
>

I'll start with this, although there's the GrafPort (Cairo?) related crash
too.

Plus I want to figure out how I can get crash dump on Windows...

Thanks!
Peter

Re: [Pharo-dev] looking into Pharo VM

[Esteban Lorenzano]

By the way first thing I would do is to remove FT2 plugin and see how it works 

> On 28 Aug 2016, at 14:38, Peter Uhnak  wrote:
> 
> Hi,
> 
> I wanted to start looking into VMs a bit (because crashing several times a 
> day for months now is really pushing my temper), but now I am not sure what 
> is actually the VM.
> 
> This is what it used to be https://github.com/pharo-project/pharo-vm, but 
> it's maintained anymore.
> 
> So there's this https://github.com/OpenSmalltalk/opensmalltalk-vm, but there 
> are no builds available for linux/windows, so I guess it's not used for Pharo 
> yet.
> 
> My understanding is that there is no work done on the VM currently used by 
> Pharo, and all effort goes into the OpenSmalltalk one (to which Pharo hasn't 
> switched yet).
> 
> Thanks,
> Peter
> 

Re: [Pharo-dev] looking into Pharo VM

[Esteban Lorenzano]

Hi,

> On 28 Aug 2016, at 14:38, Peter Uhnak  wrote:
> 
> Hi,
> 
> I wanted to start looking into VMs a bit (because crashing several times a 
> day for months now is really pushing my temper), but now I am not sure what 
> is actually the VM.
> 
> This is what it used to be https://github.com/pharo-project/pharo-vm, but 
> it's maintained anymore.

Why you say so? It is maintained, and still the official pharo distribution.
Now, thinking that "looking at it" and "fixing" will be a nice and easy (and 
quick) fix... Good luck with that :)

Anyway current problem is in FT2Plugin (I'm playing with the idea of replace it 
completely)... If you want to take a look :)

Esteban

> 
> So there's this https://github.com/OpenSmalltalk/opensmalltalk-vm, but there 
> are no builds available for linux/windows, so I guess it's not used for Pharo 
> yet.
> 
> My understanding is that there is no work done on the VM currently used by 
> Pharo, and all effort goes into the OpenSmalltalk one (to which Pharo hasn't 
> switched yet).
> 
> Thanks,
> Peter
> 

[Pharo-dev] looking into Pharo VM

[Peter Uhnak]

Hi,

I wanted to start looking into VMs a bit (because crashing several times a day 
for months now is really pushing my temper), but now I am not sure what is 
actually the VM.

This is what it used to be https://github.com/pharo-project/pharo-vm, but it's 
maintained anymore.

So there's this https://github.com/OpenSmalltalk/opensmalltalk-vm, but there 
are no builds available for linux/windows, so I guess it's not used for Pharo 
yet.

My understanding is that there is no work done on the VM currently used by 
Pharo, and all effort goes into the OpenSmalltalk one (to which Pharo hasn't 
switched yet).

Thanks,
Peter

Re: [Pharo-dev] Binary selector and special characters

[monty]

See RBParserTest>>#testBinarySelectors

It's based on the draft ANSI Smalltalk-80 standard. You integrated it. It tests 
the RBParser's parsing of binary method definitions and message sends of all 
binary selectors from 1 char upto 3 chars. (The Blue Book is more restrictive 
than ANSI, limiting them to 2 chars max IIRC.)

I wrote the test because of issues I had with the OldCompiler's handling of 
selectors containing "|" and issues on other platforms like GemStone, so the 
behavior I need and think is correct won't get broken without warning.

Re: [Pharo-dev] About Pharo 60

[Tudor Girba]

Hi,

The answer was that Spotter is not different in any way than any other global 
shortcut. This means that if we want to have an interactive solution, we should 
do it at the level of the Keymapping framework not at the level of individual 
tools.

In the meantime, how do we manage this? Inspect:
KMRepository default




If you want to remove all of them you can do:
KMRepository default globalCategories removeAll

Given that producing an end-user image should rely on a script, I think this 
solution pragmatic enough. 

Or do I miss something?

Cheers,
Doru


> On Aug 27, 2016, at 2:32 PM, Esteban Lorenzano  wrote:
> 
> yes, some years ago I made a package for this. 
> later Ben tried something similar with the user manager.
> none of those approaches worked as general approach because you need to 
> “close” a lot of things…  (not just the spotter… which by the way, NEEDS to 
> have a setting, no idea who answered you that but he is wrong), and image is 
> not prepared for that.
> 
> of course is still possible :)
> 
> anyway, today I would tackle a solution in a different way: I would open my 
> app morph on an SDL2 window and not touch the word at all (opening a headless 
> image). This is not possible in windows because when you do “headless” it 
> just laugh at you, but is doable in the not-so-long term.
> 
> Esteban
> 
>> On 27 Aug 2016, at 13:39, Cyril Ferlicot D.  wrote:
>> 
>> Le 27/08/2016 à 13:18, stepharo a écrit :
>>> 
>>> 
>>> YES!!!
>>> 
>>> Do you know how Settings works?
>>> We can adapt it this way.
>> 
>> When I improved the deployment of Synectique Tools I asked to get a
>> simple way to disable Spotter via a setting but I got as answer "No
>> because you can do it by removing a global shortcut so it is not needed.".
>> 
>> People in companies don't have the time to learn how shortcuts work and
>> how to remove one without impacting something else. And they don't have
>> the time to check Spotter code to know how it is call.
>> 
>> If the image is able to have a deployment mode then I don't care how
>> Spotter is disabled (setting or removing a shortcut). But for now we
>> don't have it. :)
>> 
>>> I mean the User approach that Benjmain proposed and was pushed in Pharo
>>> was not good because it was not modular. Now each part of the system
>>> should be
>>> defined in way that it can be set just as a setting.
>>> We should not have
>>> 
>>> World
>>>   User current = ifTrue
>>> 
>>> But
>>> 
>>> World use: userSetting
>>> 
>>> and World should handle it.
>>> There is way more to do :)
>>> When you deploy on linux you should be able to say beSilent to the
>>> system (do not write on places that you cannot).
>>> Valentin works on it and we should continue
>>> 
>>> Stef
>>> 
>> 
>> The fact that there is much more to do is the main reason for Pharo to
>> do it and not the developer. The developer cannot know all the system
>> and will not be able to protect the code of his company well because he
>> will forget something as to disable ctrl+o+p (or he is a god developer!
>> But everyone is not).
>> 
>> This is a large thing to do, so it would be cool that everyone keep that
>> in mind to allow it little by little (as with the work of Valentin).
>> 
>> -- 
>> Cyril Ferlicot
>> 
>> http://www.synectique.eu
>> 
>> 165 Avenue Bretagne
>> Lille 59000 France
>> 
> 
> 

--
www.tudorgirba.com
www.feenk.com

"Sometimes the best solution is not the best solution."

Re: [Pharo-dev] Layout in bloc

[Alexandre Bergel]

Other questions, where are the layout you have showed me at ESUG? 
Is there a tree layout? If no, then I can port the one of Roassal.

Alexandre


> On Aug 28, 2016, at 5:18 AM, Aliaksei Syrel  wrote:
> 
> Hi
> 
> Thanks for the example. Exactly, ability to have elements that are visible 
> but not participate in layout is very important. But first I would like to 
> describe bloc layout a bit more.
> 
> -
> If you think for a second about the meaning of "layout" you would realize 
> that layout is just "the way in which the parts of something are arranged or 
> laid out". So, actually, layout is all about determining the positions of 
> elements within the parent (origin of bounds). However, real world is a bit 
> more complicated, especially when it comes to visual elements. In our world 
> we must also compute size (extent) of every element before actually laying it 
> out. Bad news is that size depends on layout type and layout constraints 
> (match parent, fit content, take exact size) that may depend rather on 
> children or parent.
> 
> In Bloc the whole process is divided in two parts: measurement and layout. 
> They are completely separated and do not overlap.
> 
> During measurement step we iterate over the whole tree and depending on 
> layout and constraints only compute extent of every element. For optimisation 
> purposes layout caches previous extent and if during new measurement step it 
> does not change, we stop, skipping children. There is a rule: if child's 
> constraints didn't change and if child's measurement bit is not dirty and if 
> parent's extent is the same child will have the same extent.
> 
> Than comes layout step. Because we already measured all extents we can easily 
> determine positions within the parent, and logic is very simple.
> -
> 
> Now let's think about visibility and visible: setter. What argument should it 
> be? How do we encode visibility. In Morphic it is a Boolean. However, in real 
> world it is a bit more complicated.
> 
> Sometimes we want an element to be completely gone, it is not visible and 
> does not take any space within the parent and does not participate in layout.
> Sometimes we want an element to be hidden, it is not visible but it still 
> occupies space within the parent (it is just empty) and do participate in 
> layout.
> Sometimes we want an element to be floating, it is visible but does not 
> occupy any space and does not participate in layout. However, a floating 
> element must be measured (extent computed), we just do not want to compute 
> its position and simply let user set it manually. 
> 
> To conclude, instead of Boolean in Bloc visibility is defined by BlVisibility 
> object.
> 
> 
> Floating mode is exactly what you want, Alex. It can be set easily:
> txt constraints beFloating.
> 
> However, I just checked and it does not work. Looks like this feature was 
> removed during last iteration. I find this feature is a huge step forward, 
> but now we are many steps back :(
> 
> 
> Cheers,
> Alex
> 
> On 28 August 2016 at 02:24, Alexandre Bergel  wrote:
> Hi!
> 
> I am working on a popup support in Bloc and I am facing a problem. Consider 
> the following code:
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> space := BlSpace new.
> space root layout: BlLinearLayout horizontal.
> 10
> timesRepeat: [ | e |
> e := (BlRectangle new extent: 20 @ 20) asElement.
> e background: Color random.
> space root addChild: e ].
> space root children withIndexDo: [ :e :index | e translateBy: (index 
> * 30) @ 10 ].
> 
> space root children do: [ :e |
> e
> addEventHandler:
> (BlEventHandler
> on: BlMouseEnterEvent
> do: [ :evt |
> | txt |
> txt := BlText new
> position: evt 
> position;
> fill: Color red;
> text: 'Hello World'.
> 
> e parent addChild: txt ]).
> 
>  ].
> space show
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 
> If you uncomment the second line (“space root layout:…”), then the string 
> hello world is added text to the element in which the mouse enter. With the 
> layout, the string is added at the end of the line.
> 
> I like very much the idea of having the layout applied when elements are 
> added (even I suspect we may have scalability issues very soon), but in that 
> situation, this is not wished.
> 
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:

Re: [Pharo-dev] Layout in bloc

[Alexandre Bergel]

Thanks Alex!

Cheers,
Alexandre


> On Aug 28, 2016, at 5:18 AM, Aliaksei Syrel  wrote:
> 
> Hi
> 
> Thanks for the example. Exactly, ability to have elements that are visible 
> but not participate in layout is very important. But first I would like to 
> describe bloc layout a bit more.
> 
> -
> If you think for a second about the meaning of "layout" you would realize 
> that layout is just "the way in which the parts of something are arranged or 
> laid out". So, actually, layout is all about determining the positions of 
> elements within the parent (origin of bounds). However, real world is a bit 
> more complicated, especially when it comes to visual elements. In our world 
> we must also compute size (extent) of every element before actually laying it 
> out. Bad news is that size depends on layout type and layout constraints 
> (match parent, fit content, take exact size) that may depend rather on 
> children or parent.
> 
> In Bloc the whole process is divided in two parts: measurement and layout. 
> They are completely separated and do not overlap.
> 
> During measurement step we iterate over the whole tree and depending on 
> layout and constraints only compute extent of every element. For optimisation 
> purposes layout caches previous extent and if during new measurement step it 
> does not change, we stop, skipping children. There is a rule: if child's 
> constraints didn't change and if child's measurement bit is not dirty and if 
> parent's extent is the same child will have the same extent.
> 
> Than comes layout step. Because we already measured all extents we can easily 
> determine positions within the parent, and logic is very simple.
> -
> 
> Now let's think about visibility and visible: setter. What argument should it 
> be? How do we encode visibility. In Morphic it is a Boolean. However, in real 
> world it is a bit more complicated.
> 
> Sometimes we want an element to be completely gone, it is not visible and 
> does not take any space within the parent and does not participate in layout.
> Sometimes we want an element to be hidden, it is not visible but it still 
> occupies space within the parent (it is just empty) and do participate in 
> layout.
> Sometimes we want an element to be floating, it is visible but does not 
> occupy any space and does not participate in layout. However, a floating 
> element must be measured (extent computed), we just do not want to compute 
> its position and simply let user set it manually. 
> 
> To conclude, instead of Boolean in Bloc visibility is defined by BlVisibility 
> object.
> 
> 
> Floating mode is exactly what you want, Alex. It can be set easily:
> txt constraints beFloating.
> 
> However, I just checked and it does not work. Looks like this feature was 
> removed during last iteration. I find this feature is a huge step forward, 
> but now we are many steps back :(
> 
> 
> Cheers,
> Alex
> 
> On 28 August 2016 at 02:24, Alexandre Bergel  wrote:
> Hi!
> 
> I am working on a popup support in Bloc and I am facing a problem. Consider 
> the following code:
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> space := BlSpace new.
> space root layout: BlLinearLayout horizontal.
> 10
> timesRepeat: [ | e |
> e := (BlRectangle new extent: 20 @ 20) asElement.
> e background: Color random.
> space root addChild: e ].
> space root children withIndexDo: [ :e :index | e translateBy: (index 
> * 30) @ 10 ].
> 
> space root children do: [ :e |
> e
> addEventHandler:
> (BlEventHandler
> on: BlMouseEnterEvent
> do: [ :evt |
> | txt |
> txt := BlText new
> position: evt 
> position;
> fill: Color red;
> text: 'Hello World'.
> 
> e parent addChild: txt ]).
> 
>  ].
> space show
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 
> If you uncomment the second line (“space root layout:…”), then the string 
> hello world is added text to the element in which the mouse enter. With the 
> layout, the string is added at the end of the line.
> 
> I like very much the idea of having the layout applied when elements are 
> added (even I suspect we may have scalability issues very soon), but in that 
> situation, this is not wished.
> 
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> 
> 
> 
> 

Re: [Pharo-dev] Layout in bloc

[Aliaksei Syrel]

Hi

Thanks for the example. Exactly, ability to have elements that are visible
but not participate in layout is very important. But first I would like to
describe bloc layout a bit more.

-
If you think for a second about the meaning of "layout" you would realize
that layout is just "the way in which the parts of something are arranged
or laid out". So, actually, layout is all about determining the positions
of elements within the parent (origin of bounds). However, real world is a
bit more complicated, especially when it comes to visual elements. In our
world we must also compute size (extent) of every element before actually
laying it out. Bad news is that size depends on layout type and layout
constraints (match parent, fit content, take exact size) that may depend
rather on children or parent.

In Bloc the whole process is divided in two parts: measurement and layout.
They are completely separated and do not overlap.

During measurement step we iterate over the whole tree and depending on
layout and constraints only compute extent of every element. For
optimisation purposes layout caches previous extent and if during new
measurement step it does not change, we stop, skipping children. There is a
rule: if child's constraints didn't change and if child's measurement bit
is not dirty and if parent's extent is the same child will have the same
extent.

Than comes layout step. Because we already measured all extents we can
easily determine positions within the parent, and logic is very simple.
-

Now let's think about visibility and visible: setter. What argument should
it be? How do we encode visibility. In Morphic it is a Boolean. However, in
real world it is a bit more complicated.

Sometimes we want an element to be completely gone, it is not visible and
does not take any space within the parent and does not participate in
layout.
Sometimes we want an element to be hidden, it is not visible but it still
occupies space within the parent (it is just empty) and do participate in
layout.
Sometimes we want an element to be floating, it is visible but does not
occupy any space and does not participate in layout. However, a floating
element must be measured (extent computed), we just do not want to compute
its position and simply let user set it manually.

To conclude, instead of Boolean in Bloc visibility is defined
by BlVisibility object.


Floating mode is exactly what you want, Alex. It can be set easily:

> txt constraints beFloating.


However, I just checked and it does not work. Looks like this feature was
removed during last iteration. I find this feature is a huge step forward,
but now we are many steps back :(


Cheers,
Alex

On 28 August 2016 at 02:24, Alexandre Bergel 
wrote:

> Hi!
>
> I am working on a popup support in Bloc and I am facing a problem.
> Consider the following code:
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> space := BlSpace new.
> space root layout: BlLinearLayout horizontal.
> 10
> timesRepeat: [ | e |
> e := (BlRectangle new extent: 20 @ 20) asElement.
> e background: Color random.
> space root addChild: e ].
> space root children withIndexDo: [ :e :index | e translateBy:
> (index * 30) @ 10 ].
>
> space root children do: [ :e |
> e
> addEventHandler:
> (BlEventHandler
> on: BlMouseEnterEvent
> do: [ :evt |
> | txt |
> txt := BlText new
> position: evt
> position;
> fill: Color red;
> text: 'Hello
> World'.
>
> e parent addChild: txt ]).
>
>  ].
> space show
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> If you uncomment the second line (“space root layout:…”), then the string
> hello world is added text to the element in which the mouse enter. With the
> layout, the string is added at the end of the line.
>
> I like very much the idea of having the layout applied when elements are
> added (even I suspect we may have scalability issues very soon), but in
> that situation, this is not wished.
>
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

Re: [Pharo-dev] About Pharo 60

[Esteban Lorenzano]

> On 28 Aug 2016, at 00:55, Cyril Ferlicot D.  wrote:
> 
> Le 27/08/2016 à 14:32, Esteban Lorenzano a écrit :
>> yes, some years ago I made a package for this. 
>> later Ben tried something similar with the user manager.
>> none of those approaches worked as general approach because you need to 
>> “close” a lot of things…  (not just the spotter… which by the way, NEEDS to 
>> have a setting, no idea who answered you that but he is wrong), and image is 
>> not prepared for that.
>> 
> 
> I checked the issue tracker and it was closed because people though that
> we need a better way to disable shortcuts in general and that it is not
> specific to Spotter.
> 
> https://pharo.fogbugz.com/f/cases/17041/We-should-be-able-to-disable-GTSpotter
> 
> But we still cannot disable/enable Spotter without hacking into KM :(
> I think that sometimes it is good to think about a generic solution, but
> we still can get a temporary one because everyone cannot wait 3 years
> that the good one works. We can still let a flag "Remove this temporary
> solution after we finish ”.

ok, I will re-open it because this is not about shourtcuts, is about enabling 
or disabling a tool. The fact that this tool is called with a shortcut is just 
a detail… and also is incomplete: a good setting should also remove spotter 
from world menu, for example.

Esteban

> 
> 
>> of course is still possible :)
>> 
>> anyway, today I would tackle a solution in a different way: I would open my 
>> app morph on an SDL2 window and not touch the word at all (opening a 
>> headless image). This is not possible in windows because when you do 
>> “headless” it just laugh at you, but is doable in the not-so-long term.
>> 
>> Esteban
>> 
> 
> -- 
> Cyril Ferlicot
> 
> http://www.synectique.eu
> 
> 165 Avenue Bretagne
> Lille 59000 France
> 

Re: [Pharo-dev] ensure blocks in TestCase>>tearDown are not run if an error occurs inside ensured block when test itself was halted ...

[stepharo]

Hi dale



Le 8/8/16 à 15:00, Dale Henrichs a écrit :


Max,

Thanks for looking into this.

Do you think that this bug will be fixed in Pharo5.0? When I'm 
debugging the tests with this fatal pattern, my only recourse is to 
start and stop images between test runs ...


Definitively. We do regular backport of fixes when they are important 
and this one looks important.


The side effect of not running ensure blocks in tests is that a 
SharedQueue gets stuck waiting on an empty queue and when I interrupt 
that process (and get another debugger that is closed) I end up with 
the Empty Debugger problem where the debuggers have decide to stop 
working ... I saw that there was logic in Process>>terminate involved 
in dealing with processes running in critical blocks and that logic 
might be faulty as well ...


Dale

On 8/8/16 12:11 AM, Max Leske wrote:

Thanks Nicolai.

I’ve opened an issue on phogbugz: 
https://pharo.fogbugz.com/f/cases/18885/Ensure-blocks-in-test-tear-down-not-always-executed.



On 8 Aug 2016, at 09:03, Nicolai Hess > wrote:




2016-08-08 8:52 GMT+02:00 Max Leske >:


Wow, that’s pretty bad. The process termination logic should be
taking care of the ensure blocks. Unfortunately I can’t run any
Pharo images at the moment but if there’s something wrong with
process termination then it’s likely that me or Ben made some
mistake. Could someone please rerun Dale’s test scenario with
the original process termination code (e.g. from Pharo 3) and
report the results?


Yes, test runs fine in pharo 30864 (halts in the ensure block)


Cheers,
Max


> On 8 Aug 2016, at 03:25, Dale Henrichs
mailto:dale.henri...@gemtalksystems.com>> wrote:
>
> While attempting to characterize the "Empty Debugger" problem
that I've recently reported[1], I found that ensure blocks in
TestCase>>teardown methods are not run if an Error is signaled
while executing the code protected by the ensure block ... when
the test itself brings up a debugger --- now that is a mouthful
:) ... but a situation that commonly occurs ...
>
> I've attached a fileIn with a very simple reproduction of this
problem. After filing in the code, execute the following:
>
>  BugTestCase debug: #test.
>
> Abandon the first halt -- this is the halt in the test. Next a
debugger is brought up on the error from inside the ensure block
in the tearDown method:
>
>  tearDown
>[ self error: 'teardown' ]
>ensure: [
>"Imagine that something important NEEDED to be done
here"
>self halt ].
>super tearDown.
>
> Abandon the error and the `self halt` in the ensure block is
not run ...
>
> If you take the `self halt` out of the test method itself, the
`self halt` in the ensure block _is_ run ...
>
> This does not directly lead to the Empty Debugger, but when
the ensure blocks called during teardown are not run, a resource
is not cleaned up properly and that leads to SharedQueue hanging
... when I interrupt the SharedQueue, I believe that this leads
to the "Empty Debugger" a separate, but more nasty problem ...
>
> Dale
>
> [1]
http://forum.world.st/Re-Empty-debugger-Pharo-5-0-td4909911.html

>
> http://BugTestCase.st>>

Re: [Pharo-dev] ensure blocks in TestCase>>tearDown are not run if an error occurs inside ensured block when test itself was halted ...

[stepharo]

Thank you all for taking care and feeling like Pharo is your baby :).

Stef


Le 8/8/16 à 09:11, Max Leske a écrit :

Thanks Nicolai.

I’ve opened an issue on phogbugz: 
https://pharo.fogbugz.com/f/cases/18885/Ensure-blocks-in-test-tear-down-not-always-executed.



On 8 Aug 2016, at 09:03, Nicolai Hess > wrote:




2016-08-08 8:52 GMT+02:00 Max Leske >:


Wow, that’s pretty bad. The process termination logic should be
taking care of the ensure blocks. Unfortunately I can’t run any
Pharo images at the moment but if there’s something wrong with
process termination then it’s likely that me or Ben made some
mistake. Could someone please rerun Dale’s test scenario with the
original process termination code (e.g. from Pharo 3) and report
the results?


Yes, test runs fine in pharo 30864 (halts in the ensure block)


Cheers,
Max


> On 8 Aug 2016, at 03:25, Dale Henrichs
mailto:dale.henri...@gemtalksystems.com>> wrote:
>
> While attempting to characterize the "Empty Debugger" problem
that I've recently reported[1], I found that ensure blocks in
TestCase>>teardown methods are not run if an Error is signaled
while executing the code protected by the ensure block ... when
the test itself brings up a debugger --- now that is a mouthful
:) ... but a situation that commonly occurs ...
>
> I've attached a fileIn with a very simple reproduction of this
problem. After filing in the code, execute the following:
>
>  BugTestCase debug: #test.
>
> Abandon the first halt -- this is the halt in the test. Next a
debugger is brought up on the error from inside the ensure block
in the tearDown method:
>
>  tearDown
>[ self error: 'teardown' ]
>ensure: [
>"Imagine that something important NEEDED to be done
here"
>self halt ].
>super tearDown.
>
> Abandon the error and the `self halt` in the ensure block is
not run ...
>
> If you take the `self halt` out of the test method itself, the
`self halt` in the ensure block _is_ run ...
>
> This does not directly lead to the Empty Debugger, but when the
ensure blocks called during teardown are not run, a resource is
not cleaned up properly and that leads to SharedQueue hanging ...
when I interrupt the SharedQueue, I believe that this leads to
the "Empty Debugger" a separate, but more nasty problem ...
>
> Dale
>
> [1]
http://forum.world.st/Re-Empty-debugger-Pharo-5-0-td4909911.html

>
> http://BugTestCase.st>>

Re: [Pharo-dev] [Pharo-users] [ann] GTExamples alpha

[Tudor Girba]

Hi,


> On Aug 26, 2016, at 10:01 PM, Nicolai Hess  wrote:
> 
> 
> 
> 2016-08-26 0:51 GMT+02:00 Tudor Girba :
> Hi,
> 
> I just tried again, and the latest GToolkit image does contain FileSystem 
> class >> gtExampleZip:
> 
> Yes, it is there, but not listed under the FileSystem class package.
> If you open Nautilus for all gt examples (world menu -> GT Examples -> Browse 
> all examples)
> A Nautilus browser opens, but it shows mostly GT-Packages.
> And if you just open a new Nautilus window, select the FileSystem-Core 
> package and choose "Browse All Examples of Package FileSystem-Core from the 
> GT-Examples menu.
> you won't see any example. 
> It is "impractical", that you need to select the GT-Examples-Examples package 
> to actuall find the FileSystem-Core examples (and others).
> 
> Or in short
> The FileSystem examples are not in the FileSystem *package*
> And the same for other examples, you can not find all "Collections"-Examples 
> by selecting the Collection package and choose "Browse All Examples”

Indeed. Good catch. This should be rethought.

Cheers,
Doru


> Inspect this:
> Smalltalk gtExamplesContained select: [ :each |
> each method methodClass instanceSide = FileSystem ]
> 
> This is the image:
> https://ci.inria.fr/moose/job/gtoolkit/5595/artifact/gtoolkit.zip
> 
> Cheers,
> Doru
> 
> 
> > On Aug 25, 2016, at 11:40 PM, Tudor Girba  wrote:
> >
> > Hi Nicolai,
> >
> > Thanks a lot for the feedback. Please let’s continue. See more inline.
> >
> >> On Aug 25, 2016, at 6:34 PM, Nicolai Hess  wrote:
> >>
> >>
> >>
> >> 2016-08-25 8:47 GMT+02:00 Tudor Girba :
> >> Hi,
> >>
> >> Hi Doru,
> >> some questions and feedback ( I am sorry for my tone or if this sounds 
> >> negative, it isn't meant to be)
> >>
> >> Over the last coupe of years Stefan Reichhart and the rest of the GT team 
> >> worked on an implementation of examples. The work is inspired from 
> >> previous work done by Markus Gaelli and Adrian Kuhn.
> >>
> >> As one of the goals of GT is to offer a live programming environment,
> >>
> >> Isn't this what we already have, a live programming environment, I think 
> >> for newcomers (and maybe others) this needs to make be more clear, how is 
> >> different, what gap are you trying to fill.
> >>
> >> one important issue is how to move from the static code to live objects as 
> >> fast as possible.
> >>
> >> Isn't code always "static" and aren't objects always "live", how do play 
> >> gtExamples any role in this?
> >
> > What I meant is that I want to be as little as possible in the static code 
> > browser. Instead I want to write code in the presence of a bounded “self” 
> > which happens either in a debugger or in an inspector.
> >
> > The gap that examples fill is that when I look at a static code and I have 
> > examples about it, I can possibly jump to those examples and code against 
> > their result. So, instead of coding a method about a FileReference in the 
> > code browser, I will code it against an instance of a FileReference. Hence, 
> > we make live programming easier to achieve.
> >
> >
> >> That is why we worked on this library as a solution to provide a link 
> >> between the static code and live objects.
> >>
> >> From my understanding, I think this "link" between code an objects is the 
> >> real valuable new point. This is the great thing about gtExamples. link 
> >> from code (the example methods itself or methods refering a class
> >> to an example object/instance that can be inspected (the raw  object or an 
> >> object specific inspector pane).
> >> This is what I would consider the real step forward. You see a method 
> >> refering to class TextModel and Nautilus or any other tool not only offers 
> >> a method to browse all Users of this class, but too, a dedicated
> >> list of "example methods" where every example has a view for this example 
> >> instance that let the user show and interact (even for non-visual objects 
> >> through the "evaluater pane", or just see the code creating this
> >> example.
> >
> > Exactly.
> >
> >> We really miss examples, I often see questions on the mailing list 
> >> (especially about spect) that can be explained easily with an example. And 
> >> even worse, often the examples already exists, they just aren't as visible.
> >
> > Exactly. These examples are particularly amplified by the fact that we have 
> > an inspector that can provide a reacher experience through different views.
> >
> >
> >> Furthermore, this examples library also enables the definition of 
> >> assertions on the examples, and this provides the possibility of 
> >> rethinking the way we construct tests throughout our system. Tests are 
> >> great as they help us create live objects and then to assert live 
> >> properties.
> >>
> >> This whole thing sounds as if Unit-Test were a good idea but not the way 
> >> that they are used today, I strongly disagree. I don't see this as a 
> >> "rethinking the way we construct tests

Re: [Pharo-dev] [ann] GTExamples alpha

[Tudor Girba]

Hi Nicolai,

> On Aug 26, 2016, at 10:08 PM, Nicolai Hess  wrote:
[…]
> > And the menu entries are ... unfortunate (see screenshot), what you put in, 
> > the whole source as menu label?
> 
> Hmm. Something is strange there. I get the name of a method, not the source 
> code. What image are you in?
> 
> Ah, it always uses the "selected text" for building the menu label, in this 
> example screenshot, I 've selected the whole
> method.
> Hm. But I don't know how it would find the selected method anyway.
> If I selecte the method #append: and select 
> Browse examples with subject #append:
> or
> Browse examples with literal: #append:
> it opens a browser on class Text ander there is a Text 
> class>>#gtExampleSimple,
> but it does not contain #append: not as a literal or as a message send.
> 
> I did another test: select the message "asText" and choose
> Browse Examples with literal #asText
> It opens a browse with some more classes/example methods but
> I can not see *any* relation between this example methods and the text I 
> selected.

An example can have all sorts of objects as subjects such as class, method or 
package. But, it can also have more arbitrary objects such as text and this is 
what you see in the text pane. I agree that right now this is more experimental 
from a usage point of view and we likely should remove it from now to make the 
default behavior focus on code entities.

Doru


--
www.tudorgirba.com
www.feenk.com

"To utilize feedback, you first have to acquire it."