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

Re: [Pharo-dev] bloc status update: june 2016

by Aliaksei Syrel

> > Can we change the fonts in Bloc ? Bloc is not new Pharo :) It is also not Morphic. Bloc is very low level engine that does not have theme and widgets. Morphic apps (like Nautilus) are just running in compatibility mode and are rendered on Athens canvas. Existing Pharo applications use fonts provided by StandardFonts that can be changed from Menu > Settings. Cheers, Alex On Tue, Jun 21, 2016 at 3:42 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > When (in Bloc) I go to World menu>>help>>Help browser>>Bloc>>Grid Layout, >> I find the following license: > > > It is important to mention that Grid is more general than Table layout. It > allows developers to create complex UI with less nested elements compared > to the case when Table layout would be used instead. Reducing amount of > nested/composed elements leads to performance boost (we have less elements > in the tree) and reduces overall complexity - no need to use "hack" > elements that have no intent and not part of real UI. > > Since Grid requires more complex (compared to table) computations we > should take care about performance. General complexity of algorithm to > compute distribution of cell sizes is O(n^2) - too much. Google already > invested time (money) in this problem and developed a special case > algorithm with linear complexity. It is used in Grid layout in bloc which > means that we have a derivative work and need to ship original licence. > > Here is google's documentation: > > >> Bellman-Ford variant - modified to reduce typical running time from >> O(N^2) to O(N) >> GridLayout converts its requirements into a system of linear constraints >> of the >> form: >> x[i] - x[j] < a[k] >> > > >> Where the x[i] are variables and the a[k] are constants. >> For example, if the variables were instead labeled x, y, z we might have: >> x - y < 17 >> y - z < 23 >> z - x < 42 >> > > >> This is a special case of the Linear Programming problem that is, in turn, >> equivalent to the single-source shortest paths problem on a digraph, for >> which the O(n^2) Bellman-Ford algorithm the most commonly used general >> solution. > > > Apache 2.0 is compatible/can be used with MIT - as far as I can tell > according to answers on Internet. Maybe a layer can answer more correctly. > > Cheers, > Alex > > > On Tue, Jun 21, 2016 at 3:06 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> > wrote: > > > > Hello Clement > > > > restoreAfter: is not only for transformation. It also restores clipping > - that is why we need restoreAfter. (uses push and pop state). Having that > clipping region is an arbitrary path there is no way to avoid pop and push > state - which costs a lot in Cairo. It is slow because Cairo and Athens are > statefull - which is bad for rendering a composition of arbitrary elements. > > > > Right now there is a huge work going on new Sparta - it will be almost > stateless and will support a wide variety of backends (Cairo, Skia, > CoreGraphics and so on). > > Current Sparta-Cairo is an experiment which goal was to support clipping > by arbitrary path. We learned that it is slow because of statefullness. > > > > In order to fill a square with color we have to perform the following > ffi native calls: > > - set color > > - set shape > > - fill > > > > Even in the most simple case we need 3 calls. When it gets more > complicated there are even more calls. Preparing drawing context with > multiple calls to perform an operation is a consequence of statefullness. > > > > Modern browsers use stateless canvases to render content. Idea is > simple: one call per drawing operation. Example above would look like: > > - fillPath(aPath, aPattern, drawOptions). > > That is it. > > Second benefit is that we don't need to care about shared state between > drawing operations, no more push/pop state and as result huge performance > boost. > > > > Cheers > > Alex > > > > On Jun 21, 2016 1:34 PM, "ClÃ©ment Bera" <bera.clement(a)gmail.com> wrote: > >> > >> Hi, > >> > >> Thanks Doru it now works for me ! Very exciting indeed. > >> > >> I have a few questions: > >> > >> 1. In Pharo the World menu is accessed through left-click and > right-click provides the world contents. In Bloc, right-click displays the > world menu and left-click does nothing. Is it expected / some design choice > or just convenience for debugging ? At first glance I thought Bloc didn't > work because I was left-clicking like in Pharo. > >> > >> 2. Can we change the fonts in Bloc ? > >> > >> 3. When (in Bloc) I go to World menu>>help>>Help browser>>Bloc>>Grid > Layout, I find the following license: > >> > >> Copyright (C) 2011 The Android Open Source Project > >> > >> Licensed under the Apache License, Version 2.0 (the "License"); > >> you may not use this file except in compliance with the License. > >> You may obtain a copy of the License at > >> > >> http://www.apache.org/licenses/LICENSE-2.0 > >> > >> Unless required by applicable law or agreed to in writing, software > >> distributed under the License is distributed on an "AS IS" BASIS, > >> WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. > >> See the License for the specific language governing permissions and > >> limitations under the License. > >> > >> Does it mean Bloc is not under MIT ? Or is it completely unrelated ? > >> > >> 4. What is Cairo-Sparta ? What is the difference with Athens ? > >> > >> 5. It seems that the normal Pharo image in idle spends between 4 and 5% > of execution time in the Morphic process, while in Bloc it seems that > between 17 and 23% of execution time is in the main bloc loop > (BlBoostedMainLoopManager). Isn't that a lot ? > >> - It's interesting to see that 28% of execution time spent in Bloc is > in BlSpartaCanvas>>#restoreAfter:. In the 2D video games I wrote (both > using Cairo and Javascript canvas) I avoided using #restoreAfter: and > instead in method such as BlSpartaCanvas >>#transform:during: I used a > reverse transformation to restore the state. I am wondering if that's > possible in large graphic framework like Bloc, that would save a quarter of > the time. Maybe it's possible only in simple 2D video games. > >> - Aside from restoreAfter, there is no obvious ways on how to save > time... > >> > >> Well keep up the good work. > >> > >> > >> > >> On Tue, Jun 21, 2016 at 11:36 AM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > >>> > >>> Hi, > >>> > >>> Thanks for looking at it. > >>> > >>> You have to first switch to the Bloc space: > >>> > >>> World Menu / Bloc / Switch to Bloc > >>> (I think there is a problem right now with OS-Window) > >>> > >>> Then, from Nautilus, you can pick an example and Inspect Return-Values > to get the object. > >>> > >>> Cheers, > >>> Doru > >>> > >>> > >>> > >>> On Jun 21, 2016, at 10:42 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> > wrote: > >>> > >>> Hi Doru, > >>> > >>> Ok I understand I have issues keeping comments updated in my projects > too :-). Do your best. > >>> > >>> I tried to run the examples from Bloc-Core-Examples but they didn't > work. I downloaded the latest Pharo-Spur32 VM from files.pharo.org and > retried and it still didn't work. > >>> > >>> How can I have the examples running ? > >>> > >>> Here is the errors I have for the first two examples of > BlExampleElementWithBorderAndFill. > >>> > >>> <Screen Shot 2016-06-21 at 10.40.39 AM.png> > >>> > >>> Here are the examples: > >>> > >>> <Screen Shot 2016-06-21 at 10.37.49 AM.png> > >>> > >>> > >>> Best, > >>> > >>> Clement > >>> > >>> On Tue, Jun 21, 2016 at 10:09 AM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > >>> Hi Clement, > >>> > >>> Thanks for looking at it. > >>> > >>> Indeed, there arenât many comments. A large part of the engine got > rewritten twice over the last months, and many of the previous comments > were no longer up to date. > >>> > >>> And no, the policy is not to not write comments :), but right now the > priority is on building examples. which you will find in the > Bloc-Core-Examples classes and their subclasses. > >>> > >>> Cheers, > >>> Doru > >>> > >>> > >>> > >>> > On Jun 21, 2016, at 9:39 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> > wrote: > >>> > > >>> > Hi Doru, > >>> > > >>> > I downloaded the image, opened Nautilus, clicked on the package > named 'Bloc-Core' and all the classes I can see have no class comments (See > screenshot below). Is there a 'No class comment' policy in Bloc ? Or maybe > the top classes shown are just non representative of the class comments of > the overall framework. > >>> > > >>> > <Screen Shot 2016-06-21 at 9.33.31 AM.png> > >>> > > >>> > On Tue, Jun 21, 2016 at 7:42 AM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > >>> > Hi, > >>> > > >>> > Here is a brief update on the status of Bloc. > >>> > > >>> > Several of us came together to form a team and work to see Bloc in > Pharo 6 at least as a preview. The team communication happens via Slack in > a dedicated team, and the goal is to have regular progress/feedback > communication on this mailing list. > >>> > > >>> > Just because we have a dedicated team does not mean that your > feedback is important. In fact, over the last months, Bloc was redesigned > again to include the feedback we got here. So, now we have: > >>> > - Element is responsible for drawing (no more shape) > >>> > - Interaction area and clipping area are now distinct > >>> > > >>> > You can find the current build on top of Pharo 6 here: > >>> > > https://ci.inria.fr/moose/job/bloc/PHARO=alpha,VERSION=development,VM=vmLat… > >>> > > >>> > The current team focus goes like this: > >>> > - Alain is looking at events, > >>> > - Glenn is playing with creating new elements in Bloc and > refactoring the way we can manage , > >>> > - Alex (Syrel) and Esteban are working on the backend to make > rendering faster, > >>> > - Doru is pretending to do something useful. > >>> > > >>> > Cheers, > >>> > Doru > >>> > > >>> > > >>> > -- > >>> > www.tudorgirba.com > >>> > www.feenk.com > >>> > > >>> > "What we can governs what we wish." > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > >>> -- > >>> www.tudorgirba.com > >>> www.feenk.com > >>> > >>> "Presenting is storytelling." > >>> > >>> > >>> > >>> > >>> -- > >>> www.tudorgirba.com > >>> www.feenk.com > >>> > >>> "Problem solving should be focused on describing > >>> the problem in a way that makes the solution obvious." > >>> > >>> > >>> > >>> > >>> > >> >

June 21, 2016

Re: [Pharo-dev] bloc status update: june 2016

by Aliaksei Syrel

> > When (in Bloc) I go to World menu>>help>>Help browser>>Bloc>>Grid Layout, > I find the following license: It is important to mention that Grid is more general than Table layout. It allows developers to create complex UI with less nested elements compared to the case when Table layout would be used instead. Reducing amount of nested/composed elements leads to performance boost (we have less elements in the tree) and reduces overall complexity - no need to use "hack" elements that have no intent and not part of real UI. Since Grid requires more complex (compared to table) computations we should take care about performance. General complexity of algorithm to compute distribution of cell sizes is O(n^2) - too much. Google already invested time (money) in this problem and developed a special case algorithm with linear complexity. It is used in Grid layout in bloc which means that we have a derivative work and need to ship original licence. Here is google's documentation: > Bellman-Ford variant - modified to reduce typical running time from O(N^2) > to O(N) > GridLayout converts its requirements into a system of linear constraints > of the > form: > x[i] - x[j] < a[k] > > Where the x[i] are variables and the a[k] are constants. > For example, if the variables were instead labeled x, y, z we might have: > x - y < 17 > y - z < 23 > z - x < 42 > > This is a special case of the Linear Programming problem that is, in turn, > equivalent to the single-source shortest paths problem on a digraph, for > which the O(n^2) Bellman-Ford algorithm the most commonly used general > solution. Apache 2.0 is compatible/can be used with MIT - as far as I can tell according to answers on Internet. Maybe a layer can answer more correctly. Cheers, Alex On Tue, Jun 21, 2016 at 3:06 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > Hello Clement > > restoreAfter: is not only for transformation. It also restores clipping - that is why we need restoreAfter. (uses push and pop state). Having that clipping region is an arbitrary path there is no way to avoid pop and push state - which costs a lot in Cairo. It is slow because Cairo and Athens are statefull - which is bad for rendering a composition of arbitrary elements. > > Right now there is a huge work going on new Sparta - it will be almost stateless and will support a wide variety of backends (Cairo, Skia, CoreGraphics and so on). > Current Sparta-Cairo is an experiment which goal was to support clipping by arbitrary path. We learned that it is slow because of statefullness. > > In order to fill a square with color we have to perform the following ffi native calls: > - set color > - set shape > - fill > > Even in the most simple case we need 3 calls. When it gets more complicated there are even more calls. Preparing drawing context with multiple calls to perform an operation is a consequence of statefullness. > > Modern browsers use stateless canvases to render content. Idea is simple: one call per drawing operation. Example above would look like: > - fillPath(aPath, aPattern, drawOptions). > That is it. > Second benefit is that we don't need to care about shared state between drawing operations, no more push/pop state and as result huge performance boost. > > Cheers > Alex > > On Jun 21, 2016 1:34 PM, "ClÃ©ment Bera" <bera.clement(a)gmail.com> wrote: >> >> Hi, >> >> Thanks Doru it now works for me ! Very exciting indeed. >> >> I have a few questions: >> >> 1. In Pharo the World menu is accessed through left-click and right-click provides the world contents. In Bloc, right-click displays the world menu and left-click does nothing. Is it expected / some design choice or just convenience for debugging ? At first glance I thought Bloc didn't work because I was left-clicking like in Pharo. >> >> 2. Can we change the fonts in Bloc ? >> >> 3. When (in Bloc) I go to World menu>>help>>Help browser>>Bloc>>Grid Layout, I find the following license: >> >> Copyright (C) 2011 The Android Open Source Project >> >> Licensed under the Apache License, Version 2.0 (the "License"); >> you may not use this file except in compliance with the License. >> You may obtain a copy of the License at >> >> http://www.apache.org/licenses/LICENSE-2.0 >> >> Unless required by applicable law or agreed to in writing, software >> distributed under the License is distributed on an "AS IS" BASIS, >> WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. >> See the License for the specific language governing permissions and >> limitations under the License. >> >> Does it mean Bloc is not under MIT ? Or is it completely unrelated ? >> >> 4. What is Cairo-Sparta ? What is the difference with Athens ? >> >> 5. It seems that the normal Pharo image in idle spends between 4 and 5% of execution time in the Morphic process, while in Bloc it seems that between 17 and 23% of execution time is in the main bloc loop (BlBoostedMainLoopManager). Isn't that a lot ? >> - It's interesting to see that 28% of execution time spent in Bloc is in BlSpartaCanvas>>#restoreAfter:. In the 2D video games I wrote (both using Cairo and Javascript canvas) I avoided using #restoreAfter: and instead in method such as BlSpartaCanvas >>#transform:during: I used a reverse transformation to restore the state. I am wondering if that's possible in large graphic framework like Bloc, that would save a quarter of the time. Maybe it's possible only in simple 2D video games. >> - Aside from restoreAfter, there is no obvious ways on how to save time... >> >> Well keep up the good work. >> >> >> >> On Tue, Jun 21, 2016 at 11:36 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>> Hi, >>> >>> Thanks for looking at it. >>> >>> You have to first switch to the Bloc space: >>> >>> World Menu / Bloc / Switch to Bloc >>> (I think there is a problem right now with OS-Window) >>> >>> Then, from Nautilus, you can pick an example and Inspect Return-Values to get the object. >>> >>> Cheers, >>> Doru >>> >>> >>> >>> On Jun 21, 2016, at 10:42 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >>> >>> Hi Doru, >>> >>> Ok I understand I have issues keeping comments updated in my projects too :-). Do your best. >>> >>> I tried to run the examples from Bloc-Core-Examples but they didn't work. I downloaded the latest Pharo-Spur32 VM from files.pharo.org and retried and it still didn't work. >>> >>> How can I have the examples running ? >>> >>> Here is the errors I have for the first two examples of BlExampleElementWithBorderAndFill. >>> >>> <Screen Shot 2016-06-21 at 10.40.39 AM.png> >>> >>> Here are the examples: >>> >>> <Screen Shot 2016-06-21 at 10.37.49 AM.png> >>> >>> >>> Best, >>> >>> Clement >>> >>> On Tue, Jun 21, 2016 at 10:09 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> Hi Clement, >>> >>> Thanks for looking at it. >>> >>> Indeed, there arenât many comments. A large part of the engine got rewritten twice over the last months, and many of the previous comments were no longer up to date. >>> >>> And no, the policy is not to not write comments :), but right now the priority is on building examples. which you will find in the Bloc-Core-Examples classes and their subclasses. >>> >>> Cheers, >>> Doru >>> >>> >>> >>> > On Jun 21, 2016, at 9:39 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >>> > >>> > Hi Doru, >>> > >>> > I downloaded the image, opened Nautilus, clicked on the package named 'Bloc-Core' and all the classes I can see have no class comments (See screenshot below). Is there a 'No class comment' policy in Bloc ? Or maybe the top classes shown are just non representative of the class comments of the overall framework. >>> > >>> > <Screen Shot 2016-06-21 at 9.33.31 AM.png> >>> > >>> > On Tue, Jun 21, 2016 at 7:42 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> > Hi, >>> > >>> > Here is a brief update on the status of Bloc. >>> > >>> > Several of us came together to form a team and work to see Bloc in Pharo 6 at least as a preview. The team communication happens via Slack in a dedicated team, and the goal is to have regular progress/feedback communication on this mailing list. >>> > >>> > Just because we have a dedicated team does not mean that your feedback is important. In fact, over the last months, Bloc was redesigned again to include the feedback we got here. So, now we have: >>> > - Element is responsible for drawing (no more shape) >>> > - Interaction area and clipping area are now distinct >>> > >>> > You can find the current build on top of Pharo 6 here: >>> > https://ci.inria.fr/moose/job/bloc/PHARO=alpha,VERSION=development,VM=vmLat… >>> > >>> > The current team focus goes like this: >>> > - Alain is looking at events, >>> > - Glenn is playing with creating new elements in Bloc and refactoring the way we can manage , >>> > - Alex (Syrel) and Esteban are working on the backend to make rendering faster, >>> > - Doru is pretending to do something useful. >>> > >>> > Cheers, >>> > Doru >>> > >>> > >>> > -- >>> > www.tudorgirba.com >>> > www.feenk.com >>> > >>> > "What we can governs what we wish." >>> > >>> > >>> > >>> > >>> > >>> > >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "Presenting is storytelling." >>> >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "Problem solving should be focused on describing >>> the problem in a way that makes the solution obvious." >>> >>> >>> >>> >>> >>

June 21, 2016

Re: [Pharo-dev] System and user processe

by Max Leske

>> On 06/19/2016 05:03 AM, Max Leske wrote: >> Hi, >> >> In Pharo and Squeak we have no separation between processes that >> belong to the IDE, tools etc. and processes that are spawned as part >> of an application. Iâd like to know your opinion on the following >> (rough) idea: >> >> 1. We introduce two subclasses of Process: SystemProcess and >> UserProcess 2. We define #isSystemProcess and #isUserProcess 3. We >> introduce #newSystemProcess and #newUserProcess 4. We deprecate >> #newProcess and delegate to #newUserProcess (thereby modifying all >> users of #forkXXX to yield instances of UserProcess) >> >> Of the following Iâm less sure: 5. We introduce #forkSystemProcess >> et. al >> >> Iâve tried this out in Pharo 6 and there seem to be no problems with >> the VM. The benefit would be improved separation between system and >> user space. It would allow us to implement stuff for processes in >> general (e.g. for the debugger) which we do not want to affect system >> processes like the UI process or the background process. One concrete >> example: the process browser could hide all system processes and make >> them visible on demand (that would greatly improve the view because >> you can now better find your own processes). >> >> >> Iâm looking forward to your comments. >> >> Cheers, Max >> >> >> >> On Tue, Jun 21, 2016 at 3:32 AM, Tony Garnock-Jones <tonyg(a)ccs.neu.edu> wrote: >> Hi Max, >> >> Perhaps a notion of process grouping might make sense? Following the >> zero-one-infinity principle, having exactly two kinds of process seems a >> bit odd. >> >> Having process grouping would lead to a tree of processes. >> >> For example, the outermost level could be "system" processes, of which >> one was a group containing all "user" processes. >> >> Or, the outermost level could have two children, one group of "system" >> procs, one of "user" procs; or, ... >> >> The "current process group" would be a kind of dynamic parameter, and >> newly-forked processes would by default become siblings of the forker in >> the current group. >> >> Regards, >> Tony > > This sounds like a good idea. It would make it easier for a user of > multiple applications in one image to properly kill one. For this > reason, perhaps there should be some impediment on apps adding > processes adding the System Process group(??) > > cheers -ben Yes. Thatâs why in my proposal the default is to create a user process. Cheers, Max

June 21, 2016

Re: [Pharo-dev] System and user processe

by Max Leske

> Hi Max, > > Perhaps a notion of process grouping might make sense? Following the > zero-one-infinity principle, having exactly two kinds of process seems a > bit odd. I agree. I just wanted to get the idea out there without proposing a complete POSIX process model. And I found it interesting that we actually could use subclasses without needing special support from the VM. > > Having process grouping would lead to a tree of processes. > > For example, the outermost level could be "system" processes, of which > one was a group containing all "user" processes. > > Or, the outermost level could have two children, one group of "system" > procs, one of "user" procs; or, ... > > The "current process group" would be a kind of dynamic parameter, and > newly-forked processes would by default become siblings of the forker in > the current group. > > Regards, > Tony I think that grouping makes a lot of sense. However, the current model has also served us well, maybe exactly because it is simple. Adding a lot of complexity will not necessarily make things better (especially for newcomers). Maybe thereâs a middle ground where high level processes maintain a very simple API (like Chris proposed) and where you donât have to know about process groups (those processes might just go into a default group, essentially what you describe with âcurrent process group"). Really not sureâ¦ Cheers, Max > > > > On 06/19/2016 05:03 AM, Max Leske wrote: > Hi, > > In Pharo and Squeak we have no separation between processes that > belong to the IDE, tools etc. and processes that are spawned as part > of an application. Iâd like to know your opinion on the following > (rough) idea: > > 1. We introduce two subclasses of Process: SystemProcess and > UserProcess 2. We define #isSystemProcess and #isUserProcess 3. We > introduce #newSystemProcess and #newUserProcess 4. We deprecate > #newProcess and delegate to #newUserProcess (thereby modifying all > users of #forkXXX to yield instances of UserProcess) > > Of the following Iâm less sure: 5. We introduce #forkSystemProcess > et. al > > Iâve tried this out in Pharo 6 and there seem to be no problems with > the VM. The benefit would be improved separation between system and > user space. It would allow us to implement stuff for processes in > general (e.g. for the debugger) which we do not want to affect system > processes like the UI process or the background process. One concrete > example: the process browser could hide all system processes and make > them visible on demand (that would greatly improve the view because > you can now better find your own processes). > > > Iâm looking forward to your comments. > > Cheers, Max

June 21, 2016

Re: [Pharo-dev] System and user processe

by Max Leske

> Max Leske wrote >> Hi, >> >> In Pharo and Squeak we have no separation between processes that belong to >> the IDE, tools etc. and processes that are spawned as part of an >> application. Iâd like to know your opinion on the following (rough) idea: >> >> 1. We introduce two subclasses of Process: SystemProcess and UserProcess >> 2. We define #isSystemProcess and #isUserProcess >> 3. We introduce #newSystemProcess and #newUserProcess >> 4. We deprecate #newProcess and delegate to #newUserProcess (thereby >> modifying all users of #forkXXX to yield instances of UserProcess) >> >> Of the following Iâm less sure: >> 5. We introduce #forkSystemProcess et. al >> >> Iâve tried this out in Pharo 6 and there seem to be no problems with the >> VM. The benefit would be improved separation between system and user >> space. It would allow us to implement stuff for processes in general (e.g. >> for the debugger) which we do not want to affect system processes like the >> UI process or the background process. One concrete example: the process >> browser could hide all system processes and make them visible on demand >> (that would greatly improve the view because you can now better find your >> own processes). >> >> >> Iâm looking forward to your comments. >> >> Cheers, >> Max > > Hi Max, > > I like the idea. Let's see... > > System processes in Squeak could be: > - the timer interrupt watcher > - the event tickler > - the low space watcher > - the user interrupt watcher > - the idle process > > I am not so sure about: > - the WeakArray finalization process (still needed for Ephemerons?) > > Then we have the UI framework(s). The frameworks' processes could be user > processes or system processes, too? Hmm... for Morphic, there is only one. > Stepping is implemented with the same UI process. Applications that spawn > other (user) processes work around Morphic anyway. > > Tweak uses (or used) many processes to execute scripts. So, the Tweak UI has > a set of related processes, not just a single UI process. > > MVC has only one process running but creates/terminates processes when > switching controllers. > > If you play a MIDI or a Sound, should that process also be a system process, > right? Hmm... > > Interactive debugging is tricky only with respect to the current UI > framework because you want to be able to also debug that frameworks code and > its applications. While writing the debugger in that framework, too. So, it > is above the level of processes but at the level of the UI framework (resp. > projects). At least in Squeak. > > Hmm... for a filter in the process browser, a simple flag would be enough. > No need to add subclasses. So, whout be the benefits of distinguishing > between UserProcess and SystemProcess at process creation time? How to > decide? Might it be related to additional warnings? Calling "Smalltalk > snapshot: true andQuit: true" from a process in an endless loop might be > detected if you do that from within a UserProcess. :-D > > Maybe introduce restrictions/warnings at the level of message dispatch for > UserProcesses? Hmmâ¦ You essentially get my point. For the process browser a flag would be enough, yes, but thatâs not really OO, is itâ¦ :) Anyway, I see a couple of âdirectâ benefits: - better implementation of user interrupt handling (user processes can always be interrupted) - kill all user processes (system will keep running) - different low space settings for system and user processes (yes, that would probably require a VM change, but stillâ¦) - system processes could be prevented from starving (e.g. a user process must yield at least every n milliseconds) ... > > Best, > Marcel > >

June 21, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60102 Home: https://github.com/pharo-project/pharo-core

June 21, 2016

[pharo-project/pharo-core] 77d8c9: 60102

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 77d8c9c50617f8a7a1778ea13a62b5ce41b49f31 https://github.com/pharo-project/pharo-core/commit/77d8c9c50617f8a7a1778ea1… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-06-21 (Tue, 21 Jun 2016) Changed paths: M FileSystem-Disk.package/FilePluginPrims.class/instance/encoding primitives/decode_.st M FileSystem-Disk.package/FilePluginPrims.class/instance/encoding primitives/encode_.st M FileSystem-Disk.package/ManifestFileSystemDisk.class/class/meta-data - dependency analyser/manuallyResolvedDependencies.st M Kernel.package/InstructionStream.class/instance/private/nextPc_.st M Kernel.package/InstructionStream.class/instance/scanning/scanFor_.st M Reflectivity-Tools.package/HaltOnceIconStyler.class/instance/defaults/iconBlock_.st M Reflectivity-Tools.package/HaltOnceIconStyler.class/instance/defaults/iconLabelBlock_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60101.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60102.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60101.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60102.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60102 18544 Replace Old encoders by new Zn encoders in FileSystem-Disk https://pharo.fogbugz.com/f/cases/18544 18549 Halt Icon Styler doesnt allow disabling the haltonce https://pharo.fogbugz.com/f/cases/18549 18547 EncoderForSistaV1 bug fix https://pharo.fogbugz.com/f/cases/18547 http://files.pharo.org/image/60/60102.zip

June 21, 2016

Re: [Pharo-dev] Pharo vs. Squeak performance

by Sven Van Caekenberghe

> On 21 Jun 2016, at 11:58, Ben Coman <btc(a)openinworld.com> wrote: > > On Tue, Jun 21, 2016 at 3:29 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> Hello John. >> >> I'm just guessing here. Lacking information. It could be: >> >> Guess 3) the UI is known to be much slower in Pharo. Can you try headless or >> after ticking "Server mode" In the Pharo settings in System. > > Or try something like... > [ Transcript cr; show: (Time millisecondsToRun: [1 to: 100000000 do: > [:i | Object new]] ) ] forkAt: 75. BTW, this is essentially a garbage collection benchmark: you create 100,000,000 empty objects. It stresses the GC, especially the ephemeral phase of it. Since the GC is part of the VM, you are testing the VM more than any image code. > cheers -ben > >> >> >> >> >> >> On Tue, Jun 21, 2016 at 1:28 AM, John Brant <brant(a)refactoryworkers.com> >> wrote: >>> >>> I have some code that creates a several hundred MB model. When I run the >>> code under Pharo it takes ~2.5 minutes to run. However, if I run the same >>> code in Squeak, it takes ~2 minutes. Since my code just uses base >>> collections and streams, I thought the times should be very similar between >>> the two. After a little investigation, I noticed that even simple things >>> like âObject newâ can take much more time in Pharo. Hereâs an example that I >>> executed in Squeak and Pharo: >>> >>> Time millisecondsToRun: [1 to: 100000000 do: [:i | Object new]] >>> >>> Squeak times: >>> 1255 1257 1261 1265 1280 1294 1314 1337 1350 1360 >>> >>> Pharo times: >>> 1815 1818 1870 1879 1900 1922 1944 1952 1958 2170 >>> >>> The results are the first 10 executions sorted by time after opening an >>> image. Pharo doesnât always give these poor results. Occasionally I can get >>> times as good a Squeak. For example, I was able to get these times in Pharo: >>> 1253, 1284, 1297, 1314, 1317. However, it generally takes ~1.8 seconds in >>> Pharo vs. the ~1.3 seconds for Squeak. The worst time I got for Squeak was >>> in the 1.6 second range. The worst for Pharo was in the 4.3 second range. >>> >>> Does anyone know why Pharo is slower? Is there some memory setting that I >>> need to change? >>> >>> >>> John Brant >> >> >

June 21, 2016

Re: [Pharo-dev] bloc status update: june 2016

by Aliaksei Syrel

Hello Clement restoreAfter: is not only for transformation. It also restores clipping - that is why we need restoreAfter. (uses push and pop state). Having that clipping region is an arbitrary path there is no way to avoid pop and push state - which costs a lot in Cairo. It is slow because Cairo and Athens are statefull - which is bad for rendering a composition of arbitrary elements. Right now there is a huge work going on new Sparta - it will be almost stateless and will support a wide variety of backends (Cairo, Skia, CoreGraphics and so on). Current Sparta-Cairo is an experiment which goal was to support clipping by arbitrary path. We learned that it is slow because of statefullness. In order to fill a square with color we have to perform the following ffi native calls: - set color - set shape - fill Even in the most simple case we need 3 calls. When it gets more complicated there are even more calls. Preparing drawing context with multiple calls to perform an operation is a consequence of statefullness. Modern browsers use stateless canvases to render content. Idea is simple: one call per drawing operation. Example above would look like: - fillPath(aPath, aPattern, drawOptions). That is it. Second benefit is that we don't need to care about shared state between drawing operations, no more push/pop state and as result huge performance boost. Cheers Alex On Jun 21, 2016 1:34 PM, "ClÃ©ment Bera" <bera.clement(a)gmail.com> wrote: > Hi, > > Thanks Doru it now works for me ! Very exciting indeed. > > I have a few questions: > > 1. In Pharo the World menu is accessed through left-click and right-click > provides the world contents. In Bloc, right-click displays the world menu > and left-click does nothing. Is it expected / some design choice or just > convenience for debugging ? At first glance I thought Bloc didn't work > because I was left-clicking like in Pharo. > > 2. Can we change the fonts in Bloc ? > > 3. When (in Bloc) I go to World menu>>help>>Help browser>>Bloc>>Grid > Layout, I find the following license: > > Copyright (C) 2011 The Android Open Source Project > > Licensed under the Apache License, Version 2.0 (the "License"); > you may not use this file except in compliance with the License. > You may obtain a copy of the License at > > http://www.apache.org/licenses/LICENSE-2.0 > > Unless required by applicable law or agreed to in writing, software > distributed under the License is distributed on an "AS IS" BASIS, > WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. > See the License for the specific language governing permissions and > limitations under the License. > > Does it mean Bloc is not under MIT ? Or is it completely unrelated ? > > 4. What is Cairo-Sparta ? What is the difference with Athens ? > > 5. It seems that the normal Pharo image in idle spends between 4 and 5% of > execution time in the Morphic process, while in Bloc it seems that between > 17 and 23% of execution time is in the main bloc loop > (BlBoostedMainLoopManager). Isn't that a lot ? > - It's interesting to see that 28% of execution time spent in Bloc is in > BlSpartaCanvas>>#restoreAfter:. In the 2D video games I wrote (both using > Cairo and Javascript canvas) I avoided using #restoreAfter: and instead in > method such as BlSpartaCanvas >>#transform:during: I used a reverse > transformation to restore the state. I am wondering if that's possible in > large graphic framework like Bloc, that would save a quarter of the time. > Maybe it's possible only in simple 2D video games. > - Aside from restoreAfter, there is no obvious ways on how to save time... > > Well keep up the good work. > > > > On Tue, Jun 21, 2016 at 11:36 AM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > >> Hi, >> >> Thanks for looking at it. >> >> You have to first switch to the Bloc space: >> >> World Menu / Bloc / Switch to Bloc >> (I think there is a problem right now with OS-Window) >> >> Then, from Nautilus, you can pick an example and Inspect Return-Values to >> get the object. >> >> Cheers, >> Doru >> >> >> >> On Jun 21, 2016, at 10:42 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> >> wrote: >> >> Hi Doru, >> >> Ok I understand I have issues keeping comments updated in my projects too >> :-). Do your best. >> >> I tried to run the examples from Bloc-Core-Examples but they didn't work. >> I downloaded the latest Pharo-Spur32 VM from files.pharo.org and retried >> and it still didn't work. >> >> How can I have the examples running ? >> >> Here is the errors I have for the first two examples of >> BlExampleElementWithBorderAndFill. >> >> <Screen Shot 2016-06-21 at 10.40.39 AM.png> >> >> Here are the examples: >> >> <Screen Shot 2016-06-21 at 10.37.49 AM.png> >> >> >> Best, >> >> Clement >> >> On Tue, Jun 21, 2016 at 10:09 AM, Tudor Girba <tudor(a)tudorgirba.com >> > wrote: >> Hi Clement, >> >> Thanks for looking at it. >> >> Indeed, there arenât many comments. A large part of the engine got >> rewritten twice over the last months, and many of the previous comments >> were no longer up to date. >> >> And no, the policy is not to not write comments :), but right now the >> priority is on building examples. which you will find in the >> Bloc-Core-Examples classes and their subclasses. >> >> Cheers, >> Doru >> >> >> >> > On Jun 21, 2016, at 9:39 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> >> wrote: >> > >> > Hi Doru, >> > >> > I downloaded the image, opened Nautilus, clicked on the package named >> 'Bloc-Core' and all the classes I can see have no class comments (See >> screenshot below). Is there a 'No class comment' policy in Bloc ? Or maybe >> the top classes shown are just non representative of the class comments of >> the overall framework. >> > >> > <Screen Shot 2016-06-21 at 9.33.31 AM.png> >> > >> > On Tue, Jun 21, 2016 at 7:42 AM, Tudor Girba <tudor(a)tudorgirba.com> >> wrote: >> > Hi, >> > >> > Here is a brief update on the status of Bloc. >> > >> > Several of us came together to form a team and work to see Bloc in >> Pharo 6 at least as a preview. The team communication happens via Slack in >> a dedicated team, and the goal is to have regular progress/feedback >> communication on this mailing list. >> > >> > Just because we have a dedicated team does not mean that your feedback >> is important. In fact, over the last months, Bloc was redesigned again to >> include the feedback we got here. So, now we have: >> > - Element is responsible for drawing (no more shape) >> > - Interaction area and clipping area are now distinct >> > >> > You can find the current build on top of Pharo 6 here: >> > >> https://ci.inria.fr/moose/job/bloc/PHARO=alpha,VERSION=development,VM=vmLat… >> > >> > The current team focus goes like this: >> > - Alain is looking at events, >> > - Glenn is playing with creating new elements in Bloc and refactoring >> the way we can manage , >> > - Alex (Syrel) and Esteban are working on the backend to make rendering >> faster, >> > - Doru is pretending to do something useful. >> > >> > Cheers, >> > Doru >> > >> > >> > -- >> > www.tudorgirba.com >> > www.feenk.com >> > >> > "What we can governs what we wish." >> > >> > >> > >> > >> > >> > >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Presenting is storytelling." >> >> >> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Problem solving should be focused on describing >> the problem in a way that makes the solution obvious." >> >> >> >> >> >> >

June 21, 2016

Re: [Pharo-dev] catalog will be down 1hr

by Sven Van Caekenberghe

Thanks for taking care ! Any change you thought about this one: https://pharo.fogbugz.com/f/cases/17927/Pharo-Project-Catalog-should-be-ser… ? > On 21 Jun 2016, at 14:53, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > ok, is up again :) > >> On 21 Jun 2016, at 14:11, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> Hi, >> >> I will apply some updates to catalog (backend, they will not be visible) >> >> cheers, >> Esteban >> > >

June 21, 2016