August 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] looking into Pharo VM

by 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 <estebanlm(a)gmail.com> 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

Aug. 28, 2016

Re: [Pharo-dev] looking into Pharo VM

by 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 <i.uhnak(a)gmail.com> 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 >

Aug. 28, 2016

Re: [Pharo-dev] looking into Pharo VM

by Esteban Lorenzano

Hi, > On 28 Aug 2016, at 14:38, Peter Uhnak <i.uhnak(a)gmail.com> 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 >

Aug. 28, 2016

looking into Pharo VM

by 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

Aug. 28, 2016

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

by 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.

Aug. 28, 2016

Re: [Pharo-dev] About Pharo 60

by 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 <estebanlm(a)gmail.com> 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. <cyril.ferlicot(a)gmail.com> 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."

Aug. 28, 2016

Re: [Pharo-dev] Layout in bloc

by 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 <alex.syrel(a)gmail.com> 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 <alexandre.bergel(a)me.com> 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 28, 2016

Binary selector and special characters

by Nicolai Hess

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

Aug. 28, 2016

Re: [Pharo-dev] Layout in bloc

by Alexandre Bergel

Thanks Alex! Cheers, Alexandre > On Aug 28, 2016, at 5:18 AM, Aliaksei Syrel <alex.syrel(a)gmail.com> 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 <alexandre.bergel(a)me.com> 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 28, 2016

Re: [Pharo-dev] Layout in bloc

by 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 <alexandre.bergel(a)me.com> 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

Aug. 28, 2016