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

Re: [Pharo-dev] [pharo-project/pharo-core] 82ed3f: 60058

by stepharo

Hi Denis I would really like that we get a public discussion about such addition > 18392 Announcer should allow to subscribe on specific instances of events > https://pharo.fogbugz.com/f/cases/18392 AnnouncementDeliveryCondition introduced. It can be used in place of Announcement class in all subscription methods: announcer when: (ValueChanged where: [:change | change oldValue = #expected]) do: [:ann | ] So since there was no real discussion I check the class comments: Good class comment! Thanks. Now I still would like to understand: AnnouncementDeliveryCondition is a wrapper on a Announcement? I imagine yes. Probably we should add that in the class comment. Now I do not get why this filtering should be in the delivery because the risk is that we will get even more announcements in announcements queue. Of course it will probably reduce the number of announcement emitted. So I would like to know more. Stef

June 4, 2016

Re: [Pharo-dev] endless loop again

by stepharo

Le 3/6/16 Ã 19:16, Esteban A. Maringolo a Ã©crit : > Regarding the first part of your email, about UI lockups, it is almost > unavoidable, because in Pharo almost everything happens in the main > thread, as you pointed out. Yes. This is all my point. > When only UI events should happen there, > and have background processes/async tasks for computation and I/O that > updates the UI by means of some sort of message channel between the > process and the UI. > > This isn't a "feature" of Pharo only, other Smalltalks[1] have the > same "design" (or lack thereof) regarding what it is done in the main/UI thread. :) > > I can't imagine a plan for changing that in the current tools, I think > it would require a major overhaul. I would like to see this point addressed. It would be good to have less addition in Pharo before such point gets addressed. > OTOH newer tools like Spotter seems to use background threads to do > its stuff, so the shift might have already begun. > > Regards, > > Esteban A. Maringolo > > [1] VisualAge came with an separate OS process that could halt the vm > at a very low level when it was stuck in a tight loop. ST/X has a > process/message queue per os window, which allows you to kill one > window without taking down the whole image/vm. Yes in VW it is the same. > > 2016-06-03 2:56 GMT-03:00 stepharo <stepharo(a)free.fr>: >> the mooc is a mine for Pharo bugs... >> >> >> In the video at 6:12, we have a new method sending the new message. I've >> made similar mistakes and Pharo does lock up, but then the operating system >> (Windows 10) kills the Pharo VM. (Or perhaps there's a bug in Pharo itself >> which just crashes the whole VM. I can't tell the difference.) >> Is that because it's a memory leak? Does the VM have a fixed amount of >> memory available, or can it request more from the OS? >> Is there a way to recover from this error without killing the whole VM? >> Most GUI systems I've used have at least two threads so that pushing a >> button doesn't lock up the whole UI if the task takes a while. Does Pharo >> always lock up for long-running tasks, or does it have some kind of >> threading ability too? If a background thread gets in an infinite loop, how >> do you kill it without killing the whole VM? >> >> >> here was my answer >> >> The real answer is a bit more complex so I may write some approximations: - >> what you did a really tight loops that fills up the memory really fast. - >> depending on the OS the VM can or not (in its current state) allocate more. >> In some versions it has to preallocate. >> "Most GUI systems I've used have at least two threads so that pushing a >> button doesn't lock up the whole UI if the task takes a while. Does Pharo >> always lock up for long-running tasks, or does it have some kind of >> threading ability too? If a background thread gets in an infinite loop, how >> do you kill it without killing the whole VM?" >> Pharo has a full model for concurrent programming. Check the class Process, >> Semaphore. We have some stress tests that create thousands of threads >> without problems. You have also package such TaskIt to schedule tasks >> Now the actual problem that you see and that I would love to see fix in the >> future is that the code you execute is run in the UI thread (arghhhhh) It is >> still like that for historical reason. We should do one pass on that but >> this is not that simple because it will raise a couple of bugs. >> >> >> Now I think that it would be great if people from the pharo core would >> browse in diagonal the problems that students >> >> encounter because there are our real customers and they show many problems >> of the system. Especially the ones we do not see anymore. >> >> >

June 4, 2016

Re: [Pharo-dev] Debugger is not stable

by stepharo

Hi andrei ThibaultDucasse/Wallet And remove the roundTo: 0.1 in the coinFor:into2: method. The while loop will iterate forever and pressing on into nearly kill you else you get killed by DNU from the debugger. Stef PS: Yes I know I'm the stupider guy in the world because I criticise the wonderful GT tools and I should not because it is not acceptable :) Le 3/6/16 Ã 22:01, Andrei Chis a Ã©crit : > Hi Stef, > > Can you provide a way to load or access the entire code of your example? > > Cheers, > Andrei > > On Fri, Jun 3, 2016 at 9:43 PM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Hi > > I'm debugging a simple algo for a first exercises in Pharo future > book and I get stepToSendOrReturn > > DNU when using the debugger. :(((((((((((((((((((((((((((((((((((( > > You see I would really like in Pharo that we get new tools only > when there are better than the old > > ones. I still could not see how GTDebugger helps me debugging > faster my programs. > > Personally the fact that GT debugger can show bytecodes or can be > extended is not in the critical path. > > My critical path is that I can debug Pharo programs and now I cannot. > > I also did not see any comments on the multiple complaints about > the funky place for the buttons. > > So to me GTDebugger is a disappointement. > > Here is the kind of code I'm debugging so this is not that complex > nor implying concurrency or whatever complex. > > > coinsFor: aValue into2: accuWallet > > | accu | > self halt. > [ > accu := accuWallet money. > accu < aValue ] > whileTrue: [ > | big | > big := self biggest. > [ big > (aValue - accu) ] whileTrue: [ > big := self biggestBelow: big ]. > self removeCoin: big. > accuWallet addCoin: big ]. > ^ accuWallet > > > Stef > > > >

June 4, 2016

Re: [Pharo-dev] Debugger is not stable

by Andrei Chis

Hi Stef, Can you provide a way to load or access the entire code of your example? Cheers, Andrei On Fri, Jun 3, 2016 at 9:43 PM, stepharo <stepharo(a)free.fr> wrote: > Hi > > I'm debugging a simple algo for a first exercises in Pharo future book and > I get stepToSendOrReturn > > DNU when using the debugger. :(((((((((((((((((((((((((((((((((((( > > You see I would really like in Pharo that we get new tools only when there > are better than the old > > ones. I still could not see how GTDebugger helps me debugging faster my > programs. > > Personally the fact that GT debugger can show bytecodes or can be extended > is not in the critical path. > > My critical path is that I can debug Pharo programs and now I cannot. > > I also did not see any comments on the multiple complaints about the funky > place for the buttons. > > So to me GTDebugger is a disappointement. > > Here is the kind of code I'm debugging so this is not that complex nor > implying concurrency or whatever complex. > > > coinsFor: aValue into2: accuWallet > > | accu | > self halt. > [ > accu := accuWallet money. > accu < aValue ] > whileTrue: [ > | big | > big := self biggest. > [ big > (aValue - accu) ] whileTrue: [ > big := self biggestBelow: big ]. > self removeCoin: big. > accuWallet addCoin: big ]. > ^ accuWallet > > > Stef > > > >

June 3, 2016

Debugger is not stable

by stepharo

Hi I'm debugging a simple algo for a first exercises in Pharo future book and I get stepToSendOrReturn DNU when using the debugger. :(((((((((((((((((((((((((((((((((((( You see I would really like in Pharo that we get new tools only when there are better than the old ones. I still could not see how GTDebugger helps me debugging faster my programs. Personally the fact that GT debugger can show bytecodes or can be extended is not in the critical path. My critical path is that I can debug Pharo programs and now I cannot. I also did not see any comments on the multiple complaints about the funky place for the buttons. So to me GTDebugger is a disappointement. Here is the kind of code I'm debugging so this is not that complex nor implying concurrency or whatever complex. coinsFor: aValue into2: accuWallet | accu | self halt. [ accu := accuWallet money. accu < aValue ] whileTrue: [ | big | big := self biggest. [ big > (aValue - accu) ] whileTrue: [ big := self biggestBelow: big ]. self removeCoin: big. accuWallet addCoin: big ]. ^ accuWallet Stef

June 3, 2016

Re: [Pharo-dev] endless loop again

by Esteban A. Maringolo

Regarding the first part of your email, about UI lockups, it is almost unavoidable, because in Pharo almost everything happens in the main thread, as you pointed out. When only UI events should happen there, and have background processes/async tasks for computation and I/O that updates the UI by means of some sort of message channel between the process and the UI. This isn't a "feature" of Pharo only, other Smalltalks[1] have the same "design" (or lack thereof) regarding what it is done in the main/UI thread. I can't imagine a plan for changing that in the current tools, I think it would require a major overhaul. OTOH newer tools like Spotter seems to use background threads to do its stuff, so the shift might have already begun. Regards, Esteban A. Maringolo [1] VisualAge came with an separate OS process that could halt the vm at a very low level when it was stuck in a tight loop. ST/X has a process/message queue per os window, which allows you to kill one window without taking down the whole image/vm. 2016-06-03 2:56 GMT-03:00 stepharo <stepharo(a)free.fr>: > the mooc is a mine for Pharo bugs... > > > In the video at 6:12, we have a new method sending the new message. I've > made similar mistakes and Pharo does lock up, but then the operating system > (Windows 10) kills the Pharo VM. (Or perhaps there's a bug in Pharo itself > which just crashes the whole VM. I can't tell the difference.) > Is that because it's a memory leak? Does the VM have a fixed amount of > memory available, or can it request more from the OS? > Is there a way to recover from this error without killing the whole VM? > Most GUI systems I've used have at least two threads so that pushing a > button doesn't lock up the whole UI if the task takes a while. Does Pharo > always lock up for long-running tasks, or does it have some kind of > threading ability too? If a background thread gets in an infinite loop, how > do you kill it without killing the whole VM? > > > here was my answer > > The real answer is a bit more complex so I may write some approximations: - > what you did a really tight loops that fills up the memory really fast. - > depending on the OS the VM can or not (in its current state) allocate more. > In some versions it has to preallocate. > "Most GUI systems I've used have at least two threads so that pushing a > button doesn't lock up the whole UI if the task takes a while. Does Pharo > always lock up for long-running tasks, or does it have some kind of > threading ability too? If a background thread gets in an infinite loop, how > do you kill it without killing the whole VM?" > Pharo has a full model for concurrent programming. Check the class Process, > Semaphore. We have some stress tests that create thousands of threads > without problems. You have also package such TaskIt to schedule tasks > Now the actual problem that you see and that I would love to see fix in the > future is that the code you execute is run in the UI thread (arghhhhh) It is > still like that for historical reason. We should do one pass on that but > this is not that simple because it will raise a couple of bugs. > > > Now I think that it would be great if people from the pharo core would > browse in diagonal the problems that students > > encounter because there are our real customers and they show many problems > of the system. Especially the ones we do not see anymore. > >

June 3, 2016

Re: [Pharo-dev] install GitFileTree from catalog --> missing class

by Esteban Lorenzano

not for now > On 03 Jun 2016, at 16:03, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Thanks. > > 2016-06-03 15:32 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > https://pharo.fogbugz.com/f/cases/resolve/18400 <https://pharo.fogbugz.com/f/cases/resolve/18400> > > Would that impact configurations which have only a #pharo5.x or lower version? > > Thierry > > > :) > >> On 03 Jun 2016, at 15:18, Dale Henrichs <dale.henrichs(a)gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote: >> >> Take a look at SmalltalkImage>metacelloPlatformAttributes ... that's where Metacello picks up the platform attributes. >> Dale >> On 6/3/16 5:28 AM, Thierry Goubier wrote: >>> Done, but now I have a problem. >>> >>> Pharo6 is not identified as #pharo6 in the platform, so I can't trigger loading a dedicated version of GitFileTree for Pharo 6. >>> >>> In short, I have a GitFileTree for Pharo 6, but then you'll have to write: >>> >>> Metacello new >>> baseline: 'FileTree'; >>> repository: 'github://dalehenrich/filetree:pharo6.0_dev/repository' <>; >>> load: 'Git'. >>> >>> Could someone ensure that Pharo 6 identifies as #pharo6 at one point? For now, MetacelloToolBox>>#platformAttributes answer this: >>> >>> <Mail Attachment.png> >>> >>> Regards, >>> >>> Thierry >>> >>> >>> 2016-06-03 13:50 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>>: >>> >>> >>> 2016-06-03 13:38 GMT+02:00 Esteban Lorenzano < <mailto:estebanlm@gmail.com>estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: >>> yes, but then GitFileTree from catalog is downloading a wrong version :) >>> >>> I'll update and see if this change was pushed upstream (in the FileTree repository). >>> >>> Thierry >>> >>> >>> > On 03 Jun 2016, at 13:28, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: >>> > >>> > STON is now (in 6.0) used as JSON parser. >>> > >>> >> On 03 Jun 2016, at 13:24, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >>> >> >>> >> this class is not there anymore : >>> >> >>> >> MCFileTreeJsonParser >>> >> >>> >> (Pharo 6.0 version) >>> > >>> > >>> >>> >>> >>> >> > >

June 3, 2016

Re: [Pharo-dev] install GitFileTree from catalog --> missing class

by Thierry Goubier

Thanks. 2016-06-03 15:32 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > https://pharo.fogbugz.com/f/cases/resolve/18400 > Would that impact configurations which have only a #pharo5.x or lower version? Thierry > > :) > > On 03 Jun 2016, at 15:18, Dale Henrichs <dale.henrichs(a)gemtalksystems.com> > wrote: > > Take a look at SmalltalkImage>metacelloPlatformAttributes ... that's where > Metacello picks up the platform attributes. > > Dale > On 6/3/16 5:28 AM, Thierry Goubier wrote: > > Done, but now I have a problem. > > Pharo6 is not identified as #pharo6 in the platform, so I can't trigger > loading a dedicated version of GitFileTree for Pharo 6. > > In short, I have a GitFileTree for Pharo 6, but then you'll have to write: > > Metacello new > baseline: 'FileTree'; > repository: 'github://dalehenrich/filetree:pharo6.0_dev/repository'; > load: 'Git'. > > Could someone ensure that Pharo 6 identifies as #pharo6 at one point? For > now, MetacelloToolBox>>#platformAttributes answer this: > > <Mail Attachment.png> > > Regards, > > Thierry > > > 2016-06-03 13:50 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> >> >> 2016-06-03 13:38 GMT+02:00 Esteban Lorenzano < <estebanlm(a)gmail.com> >> estebanlm(a)gmail.com>: >> >>> yes, but then GitFileTree from catalog is downloading a wrong version :) >>> >> >> I'll update and see if this change was pushed upstream (in the FileTree >> repository). >> >> Thierry >> >> >>> >>> > On 03 Jun 2016, at 13:28, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> > >>> > STON is now (in 6.0) used as JSON parser. >>> > >>> >> On 03 Jun 2016, at 13:24, Esteban Lorenzano <estebanlm(a)gmail.com> >>> wrote: >>> >> >>> >> this class is not there anymore : >>> >> >>> >> MCFileTreeJsonParser >>> >> >>> >> (Pharo 6.0 version) >>> > >>> > >>> >>> >>> >> > > >

June 3, 2016

[pharo-project/pharo-core]

by GitHub

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

June 3, 2016

[pharo-project/pharo-core] 75684e: 50760

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 75684e7cffc7b676c19dc69cf78b6fb7174805ad https://github.com/pharo-project/pharo-core/commit/75684e7cffc7b676c19dc69c… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-06-03 (Fri, 03 Jun 2016) Changed paths: M Collections-Sequenceable.package/OrderedCollection.class/README.md M Kernel.package/Number.class/instance/mathematical functions/squared.st M Pharo-Help.package/WelcomeHelp.class/class/pages/welcome.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50759.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50760.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50759.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50760.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-MorphicAdapters.package/WorldModel.class/README.md Log Message: ----------- 50760 18324 Spelling mistakes in Pharo https://pharo.fogbugz.com/f/cases/18324 http://files.pharo.org/image/50/50760.zip

June 3, 2016