October 2016 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Is there any library to calculate the geographic distance between two points?

by Sven Van Caekenberghe

Hi Paul, This is what we use (given WGS84 coordinates) T3GeoTools class>>#distanceBetween: firstPosition and: secondPosition "T3GeoTools distanceBetween: 5.33732(a)50.926 and: 5.49705(a)50.82733" | c | c := (firstPosition y degreeSin * secondPosition y degreeSin) + (firstPosition y degreeCos * secondPosition y degreeCos * (secondPosition x degreesToRadians - firstPosition x degreesToRadians) cos). c := c >= 0 ifTrue: [ 1 min: c ] ifFalse: [ -1 max: c ]. ^ c arcCos * 6371000 Sven > On 05 Oct 2016, at 23:28, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > > umm ... here is a good place to start > > http://forum.world.st/Geo-coordinates-operations-td4732373.html#a4732441 > > > > Paul DeBruicker wrote >> I've got a few objects with latitude and longitude and want to be able to >> find the nearest from a collection >> >> >> Thanks >> >> Paul > > > > > > -- > View this message in context: http://forum.world.st/Is-there-any-library-to-calculate-the-geographic-dist… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Oct. 5, 2016

Is there any library to calculate the geographic distance between two points?

by PAUL DEBRUICKER

I've got a few objects with latitude and longitude and want to be able to find the nearest from a collection Thanks Paul

Oct. 5, 2016

Re: [Pharo-users] Is there any library to calculate the geographic distance between two points?

by Paul DeBruicker

umm ... here is a good place to start http://forum.world.st/Geo-coordinates-operations-td4732373.html#a4732441 Paul DeBruicker wrote > I've got a few objects with latitude and longitude and want to be able to > find the nearest from a collection > > > Thanks > > Paul -- View this message in context: http://forum.world.st/Is-there-any-library-to-calculate-the-geographic-dist… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Oct. 5, 2016

Re: [Pharo-users] GitFileTree-MergeDriver and using it with git mergetool

by Thierry Goubier

Hi Holger, all, just to add that I effectively integrated this into the GitFileTree-MergeDriver, including adding the "mcmerge" merge tool inside the git configuration (where it is only used if you run the command `git merge-tool --tool=mcmerge`). With this, you still keep the ability to interactively solve conflicts on smalltalk source code with another merge tool, such as meld. Thanks for finding a nice way of resolving metadata conflicts in `git cherry-pick` and `git rebase`! Regards, Thierry 2016-10-04 9:29 GMT+02:00 Holger Freyther <holger(a)freyther.de>: > Good Morning, > > Thierry Goubier has merged a change to use the Pharo "merge" as a tool for > "git mergetool" and in this mail I explain how to configure it, give a > small example and explain my usecases for it. I am not sure the merge is > fully working and would like people to test and review (code and merge > results). > > > Configuration: > > edit ~/.gitconfig and put something like: > > [mergetool "mcmerge"] > cmd = /path/to/GitFileTree-MergeDriver/merge --mergetool $BASE > $LOCAL $REMOTE $MERGED > > > > Usage: > > $ git mergetool --tool=mcmerge > > > > > Use case: > > When using git merge to merge n branches, the GitFileTree-MergeDriver will > be consulted to merge the configured files. The same tools are not used > when git cherry-pick and git rebase fail to merge. In these case a manual > call of "git mergetool" is required. > > The following cases might be something you encounter. > > If you maintain a stable branch but want to backport a specific bugfix > from a master branch you might use "git cherry-pick <FIX_FROM_MASTER>" and > end with a merge conflict on the metadata. Using git mergetool > --tool=mcmerge will help you to resolve it. > > You try to contribute to a project that is using git for hosting and have > either been asked to modify your commits or the master version has been > updated while your code was under review. In this case you would issue "git > rebase origin/master". Metadata merge conflicts can be resolved with git > mergetool. > > For work I was creating a bugfix but when thinking of deployment I noticed > that I need to deploy in two phases. Roll-out the initial part of the fix > and once it runs everywhere start rolling out the actual bugfix. What I did > was splitting my bugfix branch in two, merge the first part into > repository. After it has been merged other changes were made before the > update was deployed. To continue to work on the second part of the bugfix I > rebased it and have used git mergetool to merge the metadata. > > > cheers > holger >

Oct. 4, 2016

GitFileTree-MergeDriver and using it with git mergetool

by Holger Freyther

Good Morning, Thierry Goubier has merged a change to use the Pharo "merge" as a tool for "git mergetool" and in this mail I explain how to configure it, give a small example and explain my usecases for it. I am not sure the merge is fully working and would like people to test and review (code and merge results). Configuration: edit ~/.gitconfig and put something like: [mergetool "mcmerge"] cmd = /path/to/GitFileTree-MergeDriver/merge --mergetool $BASE $LOCAL $REMOTE $MERGED Usage: $ git mergetool --tool=mcmerge Use case: When using git merge to merge n branches, the GitFileTree-MergeDriver will be consulted to merge the configured files. The same tools are not used when git cherry-pick and git rebase fail to merge. In these case a manual call of "git mergetool" is required. The following cases might be something you encounter. If you maintain a stable branch but want to backport a specific bugfix from a master branch you might use "git cherry-pick <FIX_FROM_MASTER>" and end with a merge conflict on the metadata. Using git mergetool --tool=mcmerge will help you to resolve it. You try to contribute to a project that is using git for hosting and have either been asked to modify your commits or the master version has been updated while your code was under review. In this case you would issue "git rebase origin/master". Metadata merge conflicts can be resolved with git mergetool. For work I was creating a bugfix but when thinking of deployment I noticed that I need to deploy in two phases. Roll-out the initial part of the fix and once it runs everywhere start rolling out the actual bugfix. What I did was splitting my bugfix branch in two, merge the first part into repository. After it has been merged other changes were made before the update was deployed. To continue to work on the second part of the bugfix I rebased it and have used git mergetool to merge the metadata. cheers holger

Oct. 4, 2016

Re: [Pharo-users] Intro to Microsoft COM for Smalltalkers

by stepharo

ere is some interesting event loop stuff from Tcl. > > http://wiki.tcl.tk/2567 > > I wish we had some easy Tk UI building things in Pharo. Me too :) First I want Bloc to get out and be ready for integration to Pharo but it takes time. > > Spec is okay but not intuitive. As it is the only thing that exposes > the myriad of various Morphs we have and shields us (somewhat) from > the underlying details, we have to use it, but its explorability is > really detrimental to the livecoding side of Pharo. Spec is not to build fun morphic things :) > > Phil > > On Mon, Oct 3, 2016 at 12:25 PM, Ben Coman <btc(a)openinworld.com > <mailto:btc@openinworld.com>> wrote: > > On Mon, Oct 3, 2016 at 6:08 PM, Ben Coman <btc(a)openinworld.com > <mailto:btc@openinworld.com>> wrote: > > On Mon, Oct 3, 2016 at 3:49 PM, CodeDmitry > <dimamakhnin(a)gmail.com <mailto:dimamakhnin@gmail.com>> wrote: > >> a JavaScript timeout is a function that takes a block and a > period of time, > >> and after this period of time, puts the block at the end of > the event > >> queue, to be executed as soon as the runtime is done performing > the tasks in > >> front of it. > >> > >> I am not sure if Pharo has an event queue, so it's a bit harder > to do > >> it(since without one you can't ensure only one thing happens at > a time, and > >> strange things can happen). > >> > >> That said, in simplest terms, imagine writing a clock app for > Pharo, which > >> updates time every second, in JS this would be done by setting > an interval > >> that ticks every 1000ms, and each time places the callback > function(block) > >> at the end of the event queue. > >> > >> Related: > https://www.youtube.com/watch?time_continue=1&v=8aGhZQkoFbQ > <https://www.youtube.com/watch?time_continue=1&v=8aGhZQkoFbQ> > > > > Pharo has a single threaded VM, but multiple green threads can > run concurrently. > > The closest to the event loop you are thinking of most likely the > > Morphic UI Process > > which you can see using World > Tools > Process Browser. When > you execute code > > from Playground it runs in that Process (note what Smalltalk > > historically (circa 1970s?) has > > called a Process is today more commonly know as a Green Thread) > > > > If you select Morphic UI Process you will see its call stack on the > > right, where an interesting method is WorldState>>doOneCycleFor: > > You can gain some insight by turning on auto-update in the Process > > Browser, then open a Browser on WorldState>>doOneCycleFor: > > and put "self haltOnce" at the top, then enable it via... > > Pharo 5: World > System > Enable halt/inspect once. > > Pharo 6: World > Debugging > Enable all break/inspect once. > > > > You will see in the Process Browser that a new Morphic UI Process is > > spawned, and the original Morphic UI Process call stack now has > > #debugProcess at the top > > and a debug window appears that you can step through. Note, > since two > > UI loops are executing here, the image may lock up, but usually its > > fine so hey! live on the edge! > > > I meant to ask the list about a bug I hit doing this.... > > Putting a "self haltOnce" here... > > WorldState>>doOneCycleNowFor: aWorld > DisplayScreen checkForNewScreenSize. > self haltOnce. > "process user input events" > LastCycleTime := Time millisecondClockValue. > self handsDo: [:h | > self activeHand: h. > h processEvents. > self activeHand: nil. > ]. > self activeHand: self hands first. > aWorld runStepMethods. "there are currently some variations here" > self displayWorldSafely: aWorld. > > > When stepping over "self activeHand: nil." > another debugger appears MNU: receiver of "releaseKeyboardFocus:" > is nil > in GLMPagerPanePreviewMorph(Morph)>>delete > > self activeHand > releaseKeyboardFocus: self; > releaseMouseFocus: self. > > > This can obviously be fixed by wrapping "self activeHand" with an > #ifNil: > but alternatively I wonder if the "self activeHand: nil" is really > needed? > It seems redundant since activeHand is set at the top of the loop and > immediately after exiting the loop. > Eliminating it would reduce the propagation of #ifNil: anti-pattern. > > https://pharo.fogbugz.com/default.asp?19169 > <https://pharo.fogbugz.com/default.asp?19169> > > cheers -ben > > > > > In #runStepMethodsIn: you'll see "queue := self class > > deferredUIMessages" for which you enqueue items like this... > > > http://forum.world.st/Issue-3562-in-pharo-Deferred-UI-messages-executed-slo… > <http://forum.world.st/Issue-3562-in-pharo-Deferred-UI-messages-executed-slo…> > > > > After processing the deferred UI messages, each Morph's #step method > > is processed by #runLocalStepMethodsIn: > > refer... http://wiki.squeak.org/squeak/2096 > <http://wiki.squeak.org/squeak/2096> > > > > The display is then rendered by #displayWorldSafely: calling... > > --> #displayWorld > > --> #displayWorld:submorphs: > > which then is a lot to trace through, but depending on the graphics > > back end eventually ends up calling... > > Canvas>>fullDrawMorph: which ultimately invokes one of many > #drawOn: > > or... > > AthensCanvas>>fullDrawMorph: which ultimately invokes one of many > > #drawOnAthensCanvas: > > > > > > So, for a regular timed UI animation, you would define your custom > > morph's #step and #stepTime methods, > > and for lower level stuff you would fork like Dennis suggests. > > > > cheers -ben > > >

Oct. 3, 2016

Re: [Pharo-users] Intro to Microsoft COM for Smalltalkers

by stepharo

Thanks Ben. I can tell you that we want to remove all such activeHand. :) One day it will come. Stef Le 3/10/16 Ã 12:25, Ben Coman a Ã©crit : > On Mon, Oct 3, 2016 at 6:08 PM, Ben Coman <btc(a)openinworld.com> wrote: >> On Mon, Oct 3, 2016 at 3:49 PM, CodeDmitry <dimamakhnin(a)gmail.com> wrote: >>> a JavaScript timeout is a function that takes a block and a period of time, >>> and after this period of time, puts the block at the end of the event >>> queue, to be executed as soon as the runtime is done performing the tasks in >>> front of it. >>> >>> I am not sure if Pharo has an event queue, so it's a bit harder to do >>> it(since without one you can't ensure only one thing happens at a time, and >>> strange things can happen). >>> >>> That said, in simplest terms, imagine writing a clock app for Pharo, which >>> updates time every second, in JS this would be done by setting an interval >>> that ticks every 1000ms, and each time places the callback function(block) >>> at the end of the event queue. >>> >>> Related: https://www.youtube.com/watch?time_continue=1&v=8aGhZQkoFbQ >> Pharo has a single threaded VM, but multiple green threads can run concurrently. >> The closest to the event loop you are thinking of most likely the >> Morphic UI Process >> which you can see using World > Tools > Process Browser. When you execute code >> from Playground it runs in that Process (note what Smalltalk >> historically (circa 1970s?) has >> called a Process is today more commonly know as a Green Thread) >> >> If you select Morphic UI Process you will see its call stack on the >> right, where an interesting method is WorldState>>doOneCycleFor: >> You can gain some insight by turning on auto-update in the Process >> Browser, then open a Browser on WorldState>>doOneCycleFor: >> and put "self haltOnce" at the top, then enable it via... >> Pharo 5: World > System > Enable halt/inspect once. >> Pharo 6: World > Debugging > Enable all break/inspect once. >> >> You will see in the Process Browser that a new Morphic UI Process is >> spawned, and the original Morphic UI Process call stack now has >> #debugProcess at the top >> and a debug window appears that you can step through. Note, since two >> UI loops are executing here, the image may lock up, but usually its >> fine so hey! live on the edge! > > I meant to ask the list about a bug I hit doing this.... > > Putting a "self haltOnce" here... > > WorldState>>doOneCycleNowFor: aWorld > DisplayScreen checkForNewScreenSize. > self haltOnce. > "process user input events" > LastCycleTime := Time millisecondClockValue. > self handsDo: [:h | > self activeHand: h. > h processEvents. > self activeHand: nil. > ]. > self activeHand: self hands first. > aWorld runStepMethods. "there are currently some variations here" > self displayWorldSafely: aWorld. > > > When stepping over "self activeHand: nil." > another debugger appears MNU: receiver of "releaseKeyboardFocus:" is nil > in GLMPagerPanePreviewMorph(Morph)>>delete > > self activeHand > releaseKeyboardFocus: self; > releaseMouseFocus: self. > > > This can obviously be fixed by wrapping "self activeHand" with an #ifNil: > but alternatively I wonder if the "self activeHand: nil" is really needed? > It seems redundant since activeHand is set at the top of the loop and > immediately after exiting the loop. > Eliminating it would reduce the propagation of #ifNil: anti-pattern. > > https://pharo.fogbugz.com/default.asp?19169 > > cheers -ben > >> In #runStepMethodsIn: you'll see "queue := self class >> deferredUIMessages" for which you enqueue items like this... >> http://forum.world.st/Issue-3562-in-pharo-Deferred-UI-messages-executed-slo… >> >> After processing the deferred UI messages, each Morph's #step method >> is processed by #runLocalStepMethodsIn: >> refer... http://wiki.squeak.org/squeak/2096 >> >> The display is then rendered by #displayWorldSafely: calling... >> --> #displayWorld >> --> #displayWorld:submorphs: >> which then is a lot to trace through, but depending on the graphics >> back end eventually ends up calling... >> Canvas>>fullDrawMorph: which ultimately invokes one of many #drawOn: >> or... >> AthensCanvas>>fullDrawMorph: which ultimately invokes one of many >> #drawOnAthensCanvas: >> >> >> So, for a regular timed UI animation, you would define your custom >> morph's #step and #stepTime methods, >> and for lower level stuff you would fork like Dennis suggests. >> >> cheers -ben >

Oct. 3, 2016

Re: [Pharo-users] Intro to Microsoft COM for Smalltalkers

by stepharo

Le 3/10/16 Ã 17:25, phil(a)highoctane.be a Ã©crit : > Case in point, I am submitting a proposal here: > https://devfest.be/blog/posts/cfp/ > > That's Google tech event here. > > I proposed to showcase MDL in Pharo along with workshop. Let's see how > it goes... Nice :) Cyril will be happy :) Stef > > Phil > > On Mon, Oct 3, 2016 at 4:43 PM, Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>> wrote: > > Hi, > > > On 02/10/16 17:13, phil(a)highoctane.be <mailto:phil@highoctane.be> > wrote: > > [...] > > Use it whenever you can, it will force you to understand how > to do real stuff with it properly. > > I do hackathons with it. > https://hackernoon.com/hackapost-how-hackathons-can-be-the-best-learning-to… > <https://hackernoon.com/hackapost-how-hackathons-can-be-the-best-learning-to…> > > > As complementary to the infrastructure, code standards, libraries > and so on, a needed contribution, from the social dynamics > perspective, are hachathons and workshops. We're making them > regularly here (link at [1], in Spanish), with a critical > data/code literacy approach. Last week we have our 5th edition and > this week we're going to make an agile 6th edition. > > [1] http://mutabit.com/dataweek/ > > I found the Pharo community very open to contribution. The fast > feedback loop [2] is experienced here in a very visible way and > most of the time the community is welcoming (with notable few > exceptions, "ad hominen" attacks and poor argumentation, but also > with a good self-correcting feedback from the broader community). > > [2] > http://www.slideshare.net/MarcusDenker/perfection-feedback-loops-or-why-wor… > <http://www.slideshare.net/MarcusDenker/perfection-feedback-loops-or-why-wor…> > > So is not a perfect place, as any other, but you'll find a way of > contributing that is considered worthy and encouraged and even > supported with economical resources from Pharo Association / > Consorcium from time to time. > > Welcome here, you and your contribution ;-), > > Offray > > >

Oct. 3, 2016

Re: [Pharo-users] Intro to Microsoft COM for Smalltalkers

by phil＠highoctane.be

Cool. Now, I think we should do: WorldState MinCycleLapse: 16. So that we get a real 60FPS when moving windows around instead of the default 20 which is 50FPS, and not as smooth. Set it at 10 and it is too much, but hey, we have a lot of power these days. Try to set it to 200 and suffer :-p Phil On Mon, Oct 3, 2016 at 8:18 PM, CodeDmitry <dimamakhnin(a)gmail.com> wrote: > You seem to have answered my question as I was revising it D: > > > > -- > View this message in context: http://forum.world.st/Intro- > to-Microsoft-COM-for-Smalltalkers-tp4917738p4917916.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > >

Oct. 3, 2016

Re: [Pharo-users] Intro to Microsoft COM for Smalltalkers

by phil＠highoctane.be

Also, check MorphicUIManager>>#spawnNewProcess UIProcess := [ [World doOneCycle. Processor yield. false] whileFalse: []. ] newProcess priority: Processor userSchedulingPriority. UIProcess name: 'Morphic UI Process'. UIProcess resume digging into doOneCycle, you'll find: #doOneCycleFor: aWorld "Do one cycle of the interaction loop. This method is called *repeatedly *when the world is running. This is a moderately private method; a better alternative is usually either to wait for events or to check the state of things from #step methods." self interCyclePause: MinCycleLapse. self doOneCycleNowFor: aWorld. The interCyclePause is what make the UI timing alignment proper (notice serverMode) [and some Squeak remnant mention]: interCyclePause: milliSecs "delay enough that the previous cycle plus the amount of delay will equal milliSecs. If the cycle is already expensive, then no delay occurs. However, if the system is idly waiting for interaction from the user, the method will delay for a proportionally long time and cause the overall CPU usage of *Squeak* to be low. If self serverMode returns true then, always do a complete delay of 50ms, independant of my argument. This prevents the freezing problem described in Mantis #6581" | wait wait2 | "*a very long assignment*" wait := self serverMode ifTrue: [ 50 ] ifFalse: [ wait2 := (lastCycleTime notNil and: [CanSurrenderToOS ~~ false]) ifFalse: [ 0 ] ifTrue: [ lastCycleTime + milliSecs - Time millisecondClockValue ]. self flag: 'Issue 14754 - wait2>millisecs is only True for clock rollover. Remove it once DelayScheduler based on microsecondClock - Ben Coman 19.01.2015'. "*<---- maybe we want this #flag: not to be called all the time* " wait2 > milliSecs ifTrue: [ 0 ] ifFalse: [ wait2 ]. ]. wait > 0 ifTrue: [ (Delay forMilliseconds: wait) wait ]. "<------- wait is not #>>wait" lastCycleTime := Time millisecondClockValue. CanSurrenderToOS := true. Now, yeah, how do get stuff to be painted on the screen? Like this: displayWorld: aWorld submorphs: submorphs "Update this world's display." | deferredUpdateMode handsToDraw allDamage | submorphs do: [:m | m fullBounds]. "force re-layout if needed" self checkIfUpdateNeeded ifFalse: [^ self]. "display is already up-to-date" deferredUpdateMode := self doDeferredUpdatingFor: aWorld. deferredUpdateMode ifFalse: [self assuredCanvas]. canvas roundCornersOf: aWorld during:[ | worldDamageRects handDamageRects | worldDamageRects := self drawWorld: aWorld submorphs: submorphs invalidAreasOn: canvas. "repair world's damage on canvas" "self handsDo:[:h| h noticeDamageRects: worldDamageRects]." handsToDraw := self selectHandsToDrawForDamage: worldDamageRects. handDamageRects := handsToDraw collect: [:h | h savePatchFrom: canvas]. allDamage := worldDamageRects, handDamageRects. handsToDraw reverseDo: [:h | canvas fullDrawMorph: h]. "draw hands onto world canvas" ]. "*make this true to flash damaged areas for testing*" self class debugShowDamage ifTrue: [aWorld flashRects: allDamage color: Color black]. canvas finish. "quickly copy altered rects of canvas to Display:" deferredUpdateMode ifTrue: [self forceDamageToScreen: allDamage] ifFalse: [canvas showAt: aWorld viewBox origin invalidRects: allDamage]. handsToDraw do: [:h | h restoreSavedPatchOn: canvas]. "restore world canvas under hands" Display deferUpdates: false; forceDisplayUpdate. The VM will take care of throwing the bits to the display in various ways. Interesting to look how it is done for Windows, OSX, and Linux. So you have about a full view now. Timing wise, there is also some interaction with the VM occuring elsewhere. Pharo is still polling deep inside. epoll etc isn't there yet, hence the little idle CPU usage when doing nothing. Good luck doing this UI trip with other platforms, not to mention change or instrument it the way you like. Pharo is really cool for this as it helps in learning about a lot of things. Want to do sockets? Do the high level stuff in Pharo and dig in the VM to see how it is done down under for a set of platforms. Enjoy. Phil On Mon, Oct 3, 2016 at 8:02 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > > > On Mon, Oct 3, 2016 at 6:47 PM, CodeDmitry <dimamakhnin(a)gmail.com> wrote: > >> LOL (in GrowlMorph): >> is: rect saneWithRespectTo: morphs >> >> ^(morphs anySatisfy: [ :morph | morph owner isNotNil and: [morph >> bounds >> intersects: rect]]) not >> >> for some reason I find this method name quite amusing :3 >> > > There are interesting things in there indeed. "Intention revealing" > enough? > >> >> >> Let me guess; >> >> 1. "World defer: aBlock." defers the event to be called as soon as >> possible(not necessarily now). >> > > Actually this works for any Morph in 5.0 > > Morph>>#defer: aValuable > "aValuable will be executed in the next UI rendering cycle" > self owner > ifNotNil: [ self owner defer: aValuable] > ifNil: [ UIManager default defer: aValuable ] > > UIManager (MorphicUIManager) will do this at one point (track implementers > 'til class side in WorldState) > > defer: aValuable > "aValuable will be executed in the next UI rendering cycle" > self addDeferredUIMessage: aValuable. > > This will stick it in a queue: > > deferredUIMessages > > ^DeferredUIMessages ifNil: [DeferredUIMessages := WaitfreeQueue new]. > > and then, there is interesting black magic going on > > runStepMethodsIn: aWorld > "Perform periodic activity inbetween event cycles" > | queue nextInQueue| > "If available dispatch some deferred UI Message" > queue := self class deferredUIMessages. > > [(nextInQueue := queue nextOrNil) isNil] "<<---------------- > here all is happening -------" > whileFalse: [ nextInQueue value]. > > self runLocalStepMethodsIn: aWorld. "<<------------ step > methods -----------------" > > "The multi-threaded global Transcript needs to be updated periodically and > synchronously with the UI." > Transcript stepGlobal. > "<<------------ and *this* is some black magic for Transcript ----" > > > Fun thing: > > stepGlobal > " The superclass method Model>>step indicates a convention that might be > used to interoperate > synchronously with the UI-thread. However when multiple Transcript > windows are open, their > PluggableTextMorphs share a single instance, from the global Transcript. > To avoid potential trouble, > this method should not be named #step. > As well, we need this method to execute even when no Transcript windows > are open, so the stream > continues to be reset periodically, otherwise it would grow indefinitely. > So this method is invoked > from WorldState>>runStepMethodsIn:. > " > > "Next three lines required temporarily to initialize instance variables > added to existing instance" > deferredClear ifNil: [ deferredClear := false ]. > deferredEndEntry ifNil: [ deferredEndEntry := false ]. > stepContents ifNil: [ stepContents := '' ]. > deferredClear ifTrue: > [ deferredClear := false. > stepContents := ''. > self changed: #clearText. > ]. > deferredEndEntry ifTrue: > [ deferredEndEntry := false. > self critical: > [ stepContents := stream contents. > stream resetContents. > ]. > self changed: #appendEntry. > ]. > > Just in case one was wondering how Transcript clear actually works, check > this: > > clear > " Clear all characters by resetting the stream and voiding any previously > flagged deferredEndEntry. > Redisplays the view by signalling for #step to send #changed: . > " > self > critical: [ > deferredClear := true. "<------- magic! -------" > deferredEndEntry := false. "<------- more magic!--------" > stream reset ] > > > Good luck to infer that from scratch. > > > > > >> 2. "[Block] fork" is called immediatly, but on a new thread. >> > > Yeah, use forkNamed: aString if you actually want to track the thing > easily in the Process Browser. > > > >> 3. "<number> <time unit> wait" blocks the current thread for specific >> time >> before continuing. >> > > Right. > >> >> Now rearrange it into: >> >> [ >> 10 seconds wait. >> World defer: [ >> Transcript show: 'Hello, World!'. >> ]. >> ] fork. >> >> Into >> >> do: aBlock after: nanoTime >> [ >> 10 seconds wait. "<------- you need to say something like >> nanoTime asNanoSeconds wait. But careful as Delay works up to milliseconds >> I think, so 5 asNanoseconds asSeconds will just be zero" >> World defer: aBlock. "<-- OK, World is a WorldMorph, wich >> extends PasteUpMorph, the old World class in Pharo 3.x" >> ] fork. >> >> I guess that all of this shows that there is some flexibility in Pharo > async. > > Check the Generator class for some brain twisting with fork. > > Run > > Generator examplePrimes. > > for a start. > > Phil > >> >> >> -- >> View this message in context: http://forum.world.st/Intro-to >> -Microsoft-COM-for-Smalltalkers-tp4917738p4917913.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> >> >

Oct. 3, 2016