- Pharo-dev - lists.pharo.org

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

by Dimitris Chloupis

One day I will find out why developers hate documentation so much , or at least why they think features and code is more important than its documentation. In the mean time, personally I wont give feedback to something that I have to waste my time reading code because spending 10 seconds per class is a second or third priority for you. No examples are not enough, actually I take class comments over examples any day. Wish you good luck in your effort and thank you for trying to make Pharo better , I may be annoyed with the Pharo documentation problem, but that does not mean I dont appreciate the efforts to improve Pharo. On Tue, Jun 21, 2016 at 11:11 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." > > >

June 21, 2016

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

by Tudor Girba

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

June 21, 2016

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

by ClÃ©ment Bera

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. [image: Inline image 1] 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." > > > > > >

June 21, 2016

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

by ClÃ©ment Bera

Hello John. I'm just guessing here. Lacking information. It could be: Guess 1) the vm versions are different. What version of Pharo do you use ? (world menu>System>About) Something like: Pharo6.0 Latest update: #60030 What version of Squeak do you use ? (world menu>Help>About this system) Something like: Squeak5.0 latest update: #15792 What vm do you use in both cases ? What does answer ? In Pharo: Smalltalk vm version In Squeak: Smalltalk vmVersion Guess 2) the machine code zone size are different Can you try in Squeak: Smalltalk vmParameterAt: 46 and in Pharo: Smalltalk vm parameterAt: 46. Is it the same ? It's the number of bytes of the machine code zone. If you need performance and you can afford wasting an extra Mb, you can speed it up by doing: Smalltalk vm parameterAt: 47 put: ((Smalltalk vm parameterAt: 46) * 2) And then restarting the image. Don't grow over 2Mb. 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. 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 Nicolai Hess

2016-06-21 7:42 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > 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, > As you are on it, there changed somthing in UFFI between pharo 60059/60060 ( 18361 <https://pharo.fogbugz.com/f/cases/18361/Update-UFFI-version-to-0-20-2> Update UFFI version to 0.20.2) see attached screenshot > - Doru is pretending to do something useful. > > Cheers, > Doru > > > -- > www.tudorgirba.com > www.feenk.com > > "What we can governs what we wish." > > > > > >

June 21, 2016

Re: [Pharo-dev] [Vm-dev] System and user processes

by Max Leske

> On 20 Jun 2016, at 19:48, Chris Muller <asqueaker(a)gmail.com> wrote: > > Hi Max, I had a similar idea, and made a ClientProcess class. Its > primary purpose is to provide a nice wrapping API for *users* to > manage their "background running tasks" (i.e., #start, #stop, #pause, > #resume, #progress, #priority adjustment), as well as a nice API for > *developers* to report its progress via a simple signaling mechanism, > which also gives the user all the performance stats for "free" too > like #unitsCompleted, #runningTime, #ratePerSecond, #remainingTime, > etc. Very nice! So I donât seem to be the only one to think there may be room for improvement :) Your idea focuses on a different aspect of course but both ideas would go well together I think. Is your code public somewhere? Just in case this gains some traction. Cheers, Max > > On Sun, Jun 19, 2016 at 4:03 AM, Max Leske <maxleske(a)gmail.com> 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

[pharo-project/pharo-core]

by GitHub

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

June 21, 2016

[pharo-project/pharo-core] 6b13f1: 60100

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 6b13f1fe9dd663ed03f8875f7fe047665ed62f1e https://github.com/pharo-project/pharo-core/commit/6b13f1fe9dd663ed03f8875f… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-06-21 (Tue, 21 Jun 2016) Changed paths: A ConfigurationOfFuel.package/ConfigurationOfFuel.class/instance/versions-2/version216_.st M Fuel.package/FLHookPrimitiveCluster.class/instance/serialize%2Fmaterialize/clusterSerializeStepWith_.st M FuelPlatform.package/FLPharo11Platform.class/class/private-extensions-methodcontext/tempNamed_.st A FuelTests.package/FLPluggableSubstitutionTest.class/instance/running/testSubstituteCharacterInPresenceOfSomeCharacter.st A FuelTests.package/FLPluggableSubstitutionTest.class/instance/running/testSubstituteTrueInPresenceOfTheTrueInstance.st A FuelTests.package/FLPluggableSubstitutionTest.class/instance/running/testSubstituteUndefinedObjectInPresenceOfNil.st A FuelTests.package/FLPluggableSubstitutionTest.class/instance/running/testSubstitute_inPresenceOf_.st M Nautilus.package/AbstractNautilusUI.class/definition.st R Nautilus.package/AbstractNautilusUI.class/instance/accessing/classifier.st M Nautilus.package/AbstractNautilusUI.class/instance/menus behavior/categorizeAllUncategorizedMethods.st A Nautilus.package/Nautilus.class/class/accessing/methodClassifierClass.st A Nautilus.package/Nautilus.class/class/accessing/methodClassifierClass_.st M Nautilus.package/Nautilus.class/definition.st A Nautilus.package/Nautilus.class/instance/accessing/classifier.st A Nautilus.package/Nautilus.class/instance/accessing/classifier_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60099.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60100.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60099.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60100.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60100 18545 Update Fuel https://pharo.fogbugz.com/f/cases/18545 18535 Nautilus should be open to support different method categorizer https://pharo.fogbugz.com/f/cases/18535 http://files.pharo.org/image/60/60100.zip

June 21, 2016

bloc status update: june 2016

by Tudor Girba

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

June 21, 2016

Pharo vs. Squeak performance

by John Brant

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 20, 2016