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

Re: [Pharo-users] Iceberg and git workflow

by Vitor Medina Cruz

I think it is pretty much what stash does, but it creates a named shelved change set that stays locally and that can be viewd from a list. You can create as many as you need and you can unshelve the entire change set, destroying it or not, or only part of it, even only one change from a method. https://www.jetbrains.com/help/idea/2016.2/shelving-changes.html https://www.jetbrains.com/help/idea/2016.2/unshelving-changes.html This video shows how version control works on Intellij all around, the specific part on a very simple usage of the shelve feature can be seen at 8:00. https://www.youtube.com/watch?v=_YW8-9oLgO0 On Mon, Oct 3, 2016 at 10:51 AM, Nicolas Passerini <npasserini(a)gmail.com> wrote: > No I do not know it, how does it work? > > On Mon, Oct 3, 2016 at 3:43 PM, Vitor Medina Cruz <vitormcruz(a)gmail.com> > wrote: > >> Yes, I agree on the case of fake commit, I prefer your usage of git. In >> the case of stash, I prefer Intellij shelve feature, do you know it? I >> think it helps me organize better than the stash, I use it all the time. >> >> On Mon, Oct 3, 2016 at 10:35 AM, Nicolas Passerini <npasserini(a)gmail.com> >> wrote: >> >>> >>> >>> On Mon, Oct 3, 2016 at 2:19 PM, Vitor Medina Cruz <vitormcruz(a)gmail.com> >>> wrote: >>> >>>> My two cents: having different images for branches is a good >>>> workaround, but I will have to manually control those images, while git >>>> abstracts this a little since I have a way to tell it to stash and bring >>>> back work in progress. Depending on the project, I think loading a new >>>> image with a fresh HEAD would require a lot of time to bring all >>>> dependencies and compile, while just getting changes made at certain point >>>> from an image and stash them would be much faster, am I wrong? >>>> >>>> >>> Just one comment: the proposal is not to have an image for each branch, >>> you can switch branches using Iceberg. What Iceberg does support not >>> currently is just the "stash" command. >>> >>> Yet it could be slower to create a clean image with your changes, there >>> are ways to make it faster. Also git stash has its own problems, personally >>> I am not a fun of that feature, and I've seen lots of time people messing >>> with it and loosing changes. Moreover, I do not see that saving a "fake" >>> commit to later delete it as a "best practice", but more as a workaround >>> because you do not have a better tool. >>> >>> For all this grounds is that we do not see it as a priority, because we >>> think that there are other tools that can replace it (yet we would like to >>> listen to other opinions) . >>> >> >> >

Oct. 3, 2016

Re: [Pharo-users] Iceberg and git workflow

by Nicolas Passerini

No I do not know it, how does it work? On Mon, Oct 3, 2016 at 3:43 PM, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: > Yes, I agree on the case of fake commit, I prefer your usage of git. In > the case of stash, I prefer Intellij shelve feature, do you know it? I > think it helps me organize better than the stash, I use it all the time. > > On Mon, Oct 3, 2016 at 10:35 AM, Nicolas Passerini <npasserini(a)gmail.com> > wrote: > >> >> >> On Mon, Oct 3, 2016 at 2:19 PM, Vitor Medina Cruz <vitormcruz(a)gmail.com> >> wrote: >> >>> My two cents: having different images for branches is a good workaround, >>> but I will have to manually control those images, while git abstracts this >>> a little since I have a way to tell it to stash and bring back work in >>> progress. Depending on the project, I think loading a new image with a >>> fresh HEAD would require a lot of time to bring all dependencies and >>> compile, while just getting changes made at certain point from an image and >>> stash them would be much faster, am I wrong? >>> >>> >> Just one comment: the proposal is not to have an image for each branch, >> you can switch branches using Iceberg. What Iceberg does support not >> currently is just the "stash" command. >> >> Yet it could be slower to create a clean image with your changes, there >> are ways to make it faster. Also git stash has its own problems, personally >> I am not a fun of that feature, and I've seen lots of time people messing >> with it and loosing changes. Moreover, I do not see that saving a "fake" >> commit to later delete it as a "best practice", but more as a workaround >> because you do not have a better tool. >> >> For all this grounds is that we do not see it as a priority, because we >> think that there are other tools that can replace it (yet we would like to >> listen to other opinions) . >> > >

Oct. 3, 2016

Re: [Pharo-users] Iceberg and git workflow

by Vitor Medina Cruz

Yes, I agree on the case of fake commit, I prefer your usage of git. In the case of stash, I prefer Intellij shelve feature, do you know it? I think it helps me organize better than the stash, I use it all the time. On Mon, Oct 3, 2016 at 10:35 AM, Nicolas Passerini <npasserini(a)gmail.com> wrote: > > > On Mon, Oct 3, 2016 at 2:19 PM, Vitor Medina Cruz <vitormcruz(a)gmail.com> > wrote: > >> My two cents: having different images for branches is a good workaround, >> but I will have to manually control those images, while git abstracts this >> a little since I have a way to tell it to stash and bring back work in >> progress. Depending on the project, I think loading a new image with a >> fresh HEAD would require a lot of time to bring all dependencies and >> compile, while just getting changes made at certain point from an image and >> stash them would be much faster, am I wrong? >> >> > Just one comment: the proposal is not to have an image for each branch, > you can switch branches using Iceberg. What Iceberg does support not > currently is just the "stash" command. > > Yet it could be slower to create a clean image with your changes, there > are ways to make it faster. Also git stash has its own problems, personally > I am not a fun of that feature, and I've seen lots of time people messing > with it and loosing changes. Moreover, I do not see that saving a "fake" > commit to later delete it as a "best practice", but more as a workaround > because you do not have a better tool. > > For all this grounds is that we do not see it as a priority, because we > think that there are other tools that can replace it (yet we would like to > listen to other opinions) . >

Oct. 3, 2016

Re: [Pharo-users] Iceberg and git workflow

by Nicolas Passerini

On Mon, Oct 3, 2016 at 2:19 PM, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: > My two cents: having different images for branches is a good workaround, > but I will have to manually control those images, while git abstracts this > a little since I have a way to tell it to stash and bring back work in > progress. Depending on the project, I think loading a new image with a > fresh HEAD would require a lot of time to bring all dependencies and > compile, while just getting changes made at certain point from an image and > stash them would be much faster, am I wrong? > > Just one comment: the proposal is not to have an image for each branch, you can switch branches using Iceberg. What Iceberg does support not currently is just the "stash" command. Yet it could be slower to create a clean image with your changes, there are ways to make it faster. Also git stash has its own problems, personally I am not a fun of that feature, and I've seen lots of time people messing with it and loosing changes. Moreover, I do not see that saving a "fake" commit to later delete it as a "best practice", but more as a workaround because you do not have a better tool. For all this grounds is that we do not see it as a priority, because we think that there are other tools that can replace it (yet we would like to listen to other opinions) .

Oct. 3, 2016

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

by Thibault Raffaillac

I am not very fond of event loops in general, because they imply "many inputs, one output" (process all pending events, then update screen). For Morphic this is fine, because it displays on one screen, refreshing at/around its frequency. But there might be other screens, or network-output, file-output, which have different refresh frequencies. Then you would want to process input events as they trigger rather than storing them in a queue, such that whichever output destination sees the most up-to-date state of the program. Javascript has this cool function, requestAnimationFrame, which sets a one-time callback right before the next redraw. In essence it is an output event, allowing some form of reactive programming (no loop, only callbacks on input and output). In Pharo we have InputEventFetcher>>registerHandler: which is great for getting input callbacks, but nothing for output :/ WorldState>>addDeferredUIMessage: is probably a closest match, yet it is bound to Morphic, preventing experiments on UI/video games. Any alternatives? Thibault > Here 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. > > 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. > > Phil

Oct. 3, 2016

Re: [Pharo-users] Iceberg and git workflow

by Vitor Medina Cruz

My two cents: having different images for branches is a good workaround, but I will have to manually control those images, while git abstracts this a little since I have a way to tell it to stash and bring back work in progress. Depending on the project, I think loading a new image with a fresh HEAD would require a lot of time to bring all dependencies and compile, while just getting changes made at certain point from an image and stash them would be much faster, am I wrong? On Tue, Sep 13, 2016 at 6:20 AM, Nicolas Passerini <npasserini(a)gmail.com> wrote: > Hi Holger, I think that both patterns are currently supported (in beta > version), but maybe we do not use exactly the same tools. > > First, Iceberg does not use the concept of "stash". The git stash changes > the file in your git working copy (on your file system), while your > (modified) code is not there, is in the Pharo image. > > Going deeper into it, we understand git is very powerful but we do not > believe that git is the ultimate perfect code versioning tool. We think > that there are some git usage patterns that tend to be difficult to > understand so we are trying to create a better abstraction on top of that. > Also we would like to come up with an abstraction that works not only for > git but for other repositories. > > So, we try to support the kind of requirements you are worried about, but > maybe not in the same way that the command line tools you are used to. I > also have been working with git in languages like Scala, Javascript, Xtend, > etc and I was used to the command line tools... so now the task for me is > to try to understand: which of all those things I was used to do were > really necessary and which of them are just boilerplate I need to do > because of my tools are too low level? > > Maybe your experience can help us answer that question. > > >> a.) If current HEAD is same as origin/master >> >> $ git stash (stash away my not finished changes) >> $ vi code.c fix.. >> $ git commit -a -c "subject >> >> long explanation of fix >> reference to bug" >> $ git stash apply (and go back to working on my feature) >> >> > So, why is this better than having a new image with a clean version of > HEAD? > > >> b.) E.g. if I finished n-commits but I am not fully done >> > > For this I would propose a slightly different pattern: > >> >> # store my work >> $ git commit -a -m "Work In Progress hack.." >> > > You can commit, ok... but also you could just save the image with your > work in progress, no need to create a hacky commit. > > >> $ git checkout -b new-feature-branch >> >> # go back to master >> $ git checkout master >> $ git reset --hard origin/master (to restore) >> > > To avoid reset, I would propose to leave master like that and put the new > work in a clean branch, starting on origin/master. > > In git-command-line language it would be: > git checkout -b fix origin/master > > So you create a new branch for your fix out of origin/master, leaving the > original branch untouched. > > >> >> # work on the fix >> $ vi code.c fix.. >> $ git commit -a -c "fix..." >> >> No problems here... just we do not use vi for editing code :) > > >> # go back and continue on my fix >> $ git checkout new-feature-branch >> > $ git rebase origin/master >> $ git reset HEAD^1 >> .. continue to work >> >> Several things here. First, I think that everything is simpler if you > just leave your original branch untouched, so you could re-checkout that > branch without the need for reset and removing hacky commits. But even more > interesting if you agree to have two images one for each task, you just go > back to your first image and everything is just like you left it, including > open windows and whatever task you were doing. I think that is a beautiful > value of Pharo I would not like to loose. > > The only thing left would be to incorporate the fix into this image, right > now we do not support rebase, you would need to merge... but I understand > why one would prefer rebase in this scenario, at some point we will support > both options. > > > So, to sum up. I am not trying to replicate in Pharo the way I used to > work in Javascript... I think that would be silly. Instead, we are trying > to take the good stuff of git into Pharo, but without loosing all the good > stuff of Pharo. >

Oct. 3, 2016

Re: [Pharo-users] 19169 Debugging World>>doOneCycleNowFor: induces debugger MNU (was Re: Intro to Microsoft COM for Smalltalkers)

by Denis Kudriashov

So it is not related to Ronie changes which is good because they are main step for multi windows support 2016-10-03 13:44 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > On Mon, Oct 3, 2016 at 7:08 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > Hi Ben. > > > > 2016-10-03 12:37 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > >> > >> A further curiousity occurs to me. With this being executed 20 times > >> a second or more, how can the active hand ever be anything other than > >> the primary hand? > >> Why isn't the active hand stored, all hands cycled through processing > >> events, then the active hand restored?? > > > > > > Previous version of method was also with nil at the end: > > > > self handsDo: [:h | > > ActiveHand := h. > > h processEvents. > > ActiveHand := nil > > ]. > > > > Could you try your test on previous version of Pharo? > > > > It happens in... > * 60246 - MNU #releaseKeyboardFocus: in GLMPagerPanePreviewMorph( > Morph)>>delete > up stack from GTGenericStackDebugger>>updateBrowser > * 50760 - MNU #releaseKeyboardFocus: in GLMPagerPanePreviewMorph( > Morph)>>delete > up stack from GTGenericStackDebugger>>updateBrowser > * 40626 - MNU #newKeyboardFocus: in NewList(Morph)>>takeKEyboardFocus > up stack from SpecDebugger>> updateReceiverInspectorFromCon > text: > > Must just be a rarely-debugged corner of the system. > > cheers -ben > >

Oct. 3, 2016

Re: [Pharo-users] Pharo Association

by Marcus Denker

> On 3 Oct 2016, at 08:59, John Pfersich <jpfersich(a)gmail.com> wrote: > > I went to the Pharo Association web site (http://association.pharo.org <http://association.pharo.org/web/members>) to change my profile, but I didn't find any way to alter it. Am I missing something? > There seems to beb a problem with refresh. After logging in, go to http://association.pharo.org/web/members <http://association.pharo.org/web/members> and there should be menu entries for editing. Marcus

Oct. 3, 2016

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

by phil＠highoctane.be

Here 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. 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. Phil On Mon, Oct 3, 2016 at 12:25 PM, Ben Coman <btc(a)openinworld.com> wrote: > 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-slowly-td3228060.html > > > > 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

19169 Debugging World>>doOneCycleNowFor: induces debugger MNU (was Re: Intro to Microsoft COM for Smalltalkers)

by Ben Coman

On Mon, Oct 3, 2016 at 7:08 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi Ben. > > 2016-10-03 12:37 GMT+02:00 Ben Coman <btc(a)openinworld.com>: >> >> A further curiousity occurs to me. With this being executed 20 times >> a second or more, how can the active hand ever be anything other than >> the primary hand? >> Why isn't the active hand stored, all hands cycled through processing >> events, then the active hand restored?? > > > Previous version of method was also with nil at the end: > > self handsDo: [:h | > ActiveHand := h. > h processEvents. > ActiveHand := nil > ]. > > Could you try your test on previous version of Pharo? > It happens in... * 60246 - MNU #releaseKeyboardFocus: in GLMPagerPanePreviewMorph(Morph)>>delete up stack from GTGenericStackDebugger>>updateBrowser * 50760 - MNU #releaseKeyboardFocus: in GLMPagerPanePreviewMorph(Morph)>>delete up stack from GTGenericStackDebugger>>updateBrowser * 40626 - MNU #newKeyboardFocus: in NewList(Morph)>>takeKEyboardFocus up stack from SpecDebugger>> updateReceiverInspectorFromContext: Must just be a rarely-debugged corner of the system. cheers -ben

Oct. 3, 2016