February 2019 - Pharo-users

Re: [Pharo-users] Iceberg working with forks - can it be easier?

by Guillermo Polito

On Mon, Feb 18, 2019 at 1:19 AM Tim Mackinnon <tim(a)testit.works> wrote: > Hey Ben - Iâm not sure that this actually does the same thing. I just > tried it now, and it resulted in an extra merge in my forked repo - as I > think this effectively pulls down from upstream into pharo and then if you > have any differences in your local image copy they might cause some changes > which then you would push back into your fork origin. > > If you just want a verbatim copy in your fork - you have to resort the > command line? > Ah! well merging may do two things: - create a merge commit (in case of diverging history) - do a fast forward (just update your branch) The thing is that you want to **undo** your changes before merging, otherwise you'll have a dangling commit there that you did not want :). You cannot do that from Iceberg's UI right now, you can do it from any expression evaluator: "Rough equivalent of reset --hard HEAD~1" repository branch commit: repository branch commit parent. But even then, Iceberg does not (yet) implement push --force, because we never found a useful use case (other than bad practices) to it. This is important: if you have made changes to your repository, then "making a verbatim copy" means to undo your changes. Even from the command line, what you may want to do is: move to another branch, remove your "to-sync" branch, fetch from origin, checkout origin/"to-sync", push force to your fork. But you may lose your changes... > Iâm still mulling this over - as would you then pull from your upstream > fork and still get the same differences that you would then apply? Iâm not > sure now - but if the idea was just to get yourself back into a consistent > state - Its not clear to me how you can get all 3 copies saying the same > thing in pharo? > > Tim > > On 16 Feb 2019, at 06:19, Ben Coman <btc(a)openInWorld.com> wrote: > > > > On Sat, 16 Feb 2019 at 02:06, Tim Mackinnon <tim(a)testit.works> wrote: > >> Hi guys - Iâve spent a few hours scratching my head trying to understand >> why some of my Pull Requests to a project I had forked kept showing my >> previous commits when I thought I was all caught up. >> >> It suddenly dawned on me, that when I had forked, and then done some work >> and then submitted a PR, and then applied it upstream that my fork is now >> no longer in sync with its upstream counterpart. >> >> Having not done this in ages, it took me a while to then realise I have >> to do some git stuff to get it back in sync e.g. (and I think Iâve got this >> right) >> >> git fetch upstream (or whatever name you gave it) >> Git checkout master >> Git merge upstream/master >> >> So I guess my question is - wouldnât it be helpful if this was a command >> in Iceberg? It seems quite common to fork a project (I think this is still >> recommended for pharo itself isnât it?) - and then at some point you need >> to catchup with that origin again? Or am I missing something? I guess lots >> of stuff can go wrong - but if it does - youâd still get the same problems >> on the command line. It just seems that for normal situations - it would be >> handy to run this straight in Pharo. >> > > I'm not fully-conversant with Iceberg, but if I guess right... > in Iceberg, right-click a repo and open its "Repository" window. > In the top-right click the "Add remote" button, to add the upstream repo. > That button is a bit hidden there. It might be nice to have it as a menu > item on "Remotes" in the first pane. > Then click the <Merge> button, then select the upstream master branch and > you should be up to date. > > cheers -ben > > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Feb. 18, 2019

Re: [Pharo-users] Iceberg working with forks - can it be easier?

by Guillermo Polito

Hi! On Fri, Feb 15, 2019 at 7:06 PM Tim Mackinnon <tim(a)testit.works> wrote: > Hi guys - Iâve spent a few hours scratching my head trying to understand > why some of my Pull Requests to a project I had forked kept showing my > previous commits when I thought I was all caught up. > > It suddenly dawned on me, that when I had forked, and then done some work > and then submitted a PR, and then applied it upstream that my fork is now > no longer in sync with its upstream counterpart. > > Having not done this in ages, it took me a while to then realise I have to > do some git stuff to get it back in sync e.g. (and I think Iâve got this > right) > > git fetch upstream (or whatever name you gave it) > Git checkout master > Git merge upstream/master > When you did your clone, did you clone the original repository or your fork's? One way to simplify this workflow is: - you clone always the original repository - you create a branch and work there - then you'll push your branch to your fork + fork That way your branch will be always up to date with the original repository, and no need to sync (actually the sync is done automatically when you push to your fork). Of course this assumes you're doing a new clone every time you work :). > > So I guess my question is - wouldnât it be helpful if this was a command > in Iceberg? It would, there are several places where we could simplify the workflow for common cases, I agree. > It seems quite common to fork a project (I think this is still recommended > for pharo itself isnât it?) I'd say its mandatory :). Otherwise you will not be able to push directly to it because of permission problems (actually all main dev branches are now blocked so **nobody**, not even admins, push to them directly). > - and then at some point you need to catchup with that origin again? Or am > I missing something? Well, it really depends on the workflow you use. Above I've explained a workflow that works when you clone every time. Git is so complex and so low level that you can do lots of different things with it. First thing is to understand what "catch up with origin" means. In my head it only means: - checkout your "to-catchup" branch - merge the remote "to-catchup" branch and merge it All the rest is workflow dependent. Even (!!) I would argue that merging is not, strictly speaking, a correct way to catch up: If you have made changes into "to-catchup", then merging will not make both branches the same, but your "to-catchup" branch may have extra commits that you did not want to introduce... And here I'm not saying you should not merge, actually I do it most of the times because I know that 90% of the times it will be ok, and I do rollback when I realize I was in the other 10%... > I guess lots of stuff can go wrong - but if it does - youâd still get the > same problems on the command line. Yes, and no. The "lots of stuff can go wrong" can be translated in most of the cases to "I had a merge conflict". But this is not git, this is git+pharo. The thing is that with Git, your code is dead in files. With Iceberg, your code is in the files but it also may be alive in your image too. So updating code for what you have existing instances, or announcement subscriptions or other could (and probably will) mess up with the running code... So to the typical merge conflict, you may add breaking your running system. It just seems that for normal situations - it would be handy to run this > straight in Pharo. > > Thoughts from the git experts? > For these cases, you can do exactly as the command line from Iceberg's UI - change your branch to your "to-catchup" master - fetch - now you can go to the merge option, and choose to merge your remote branch into your checked-out branch. - and push Of course, this simple workflow works most of the times, but you may find edge cases. For those edge cases (typically updating iceberg itself, or trying to update pharo itself), in the checkout preview you will have the combo with the checkout strategy: choose the expert mode "do not load the code". This option will change the branch on git's world, but it will not load the code in your image. That is useful if you have living instances for example. This option will though make a diff between the checked out version and your image code and show you differences. (think this as a git reset --soft) To me the fact that we are manipulating live code loaded in the image and not dead files makes a huge difference, and this makes that extrapolating git commands to iceberg is not so straight forward :). Also, understanding that git is stateful/context dependant, and applying an operation means changing your current state (modify your current branch, change your current branch) is useful to see the consequences. In any case, any more concrete suggestions for enhancing this workflow are welcome. I think that neither Esteban, Pablo, me nor other contributors are skilled UI designers, and thinking about the best way to present a usecase to a user is super super hard :). Guille, from his vacations

Feb. 18, 2019

Re: [Pharo-users] Stability of Pharo 7 vs 6?

by Hilaire

Le 18/02/2019 Ã 02:00, Tim Mackinnon a Ã©critÂ : > > Having said this - Iâm still not having the smooth ride others are > reporting - and 7 is still suspect to me. Indeed, the Pharo stability (or any other software) depends on several factors: in your case OSX, fullscreen, P7 image and VM, plugin. Also likely, not many of us are using Pharo fullscreen > > Iâm kind of suprised this isnât getting much traction from the core > team - and I wonder if I should post this on the dev list instead? > Reporting these kind of issues here seems to me as the right place. The dev list is dedicated to exchange related to the development of Pharo. As your issue is likely related to the VM, you could report it to the VM list, there http://forum.world.st/Squeak-VM-f104410.html? You may have some additional clues. While it is annoying to be under such circumstance when you just want to work on your project (been there many times), it could be a valuable contribution, eventually with self knowledge amplification outcome. Hilaire -- Dr. Geo http://drgeo.eu

Feb. 18, 2019

Re: [Pharo-users] Iceberg working with forks - can it be easier?

by Konrad Hinsen

Am 18.02.19 um 01:19 schrieb Tim Mackinnon: > Hey Ben - Iâm not sure that this actually does the same thing. I just > tried it now, and it resulted in an extra merge in my forked repo - as I > think this effectively pulls down from upstream into pharo and then if > you have any differences in your local image copy they might cause some > changes which then you would push back into your fork origin. > > If you just want a verbatim copy in your fork - you have to resort the > command line? That's at least what I do: git pull upstream master git push origin master I am pretty sure these basic operations are somewhere accessible in the Iceberg code, but I have no idea how. Iceberg would definitely gain from having a documented programmer's interface. Git is way too complicated for a point-and-click interface to be sufficient. I'd even say that "scriptable git" could become a Pharo killer feature if done well. Konrad.

Feb. 18, 2019

Re: [Pharo-users] Bloc Tutorial

by Tudor Girba

Hi, The simplest thing is to take a fresh image, in a fresh directory and rerun the Metacello script. Let us know how it works. Cheers, Doru > On Feb 18, 2019, at 12:28 AM, horrido <horrido.hobbies(a)gmail.com> wrote: > > So how do I force Iceberg to reload? > > > Andrei Chis wrote >> If you use repositories that start with `github://` in Metacello you are >> using Iceberg. Iceberg is used to clone and load the code. Metacello is >> just the interface through which that is done. >> >> Running the loading instruction does not pull new changes from remote >> repositories. >> >> On Sun, Feb 17, 2019 at 10:11 PM horrido < > >> horrido.hobbies@ > >> > wrote: >> >>> ??? >>> >>> I'm not using a cloned repository. I'm using Metacello just like in the >>> snippet I showed you. Shouldn't it pull in the latest repo? >>> >>> I've never used Iceberg; I don't know how to use it. I don't really want >>> to >>> fuck around with GitHub. I don't want to be pulled into a rabbit hole. >>> >>> >>> >>> Andrei Chis wrote >>>> If you already have the repository cloned, running the code that you >>>> mentioned does not update the content of the repository. >>>> Hence, the existing version will be loaded again. >>>> >>>> Instead you need to do a pull using Iceberg to update the content of >>> the >>>> repository and the code. >>>> >>>> Cheers, >>>> Andrei >>>> >>>> On Sun, Feb 17, 2019 at 8:06 PM horrido < >>> >>>> horrido.hobbies@ >>> >>>> > wrote: >>>> >>>>> If you're referring to this: >>>>> >>>>> Metacello new >>>>> baseline: 'BlocTutorials'; >>>>> repository: 'github://pharo-graphics/Tutorials/src'; >>>>> load >>>>> >>>>> It made no difference. Same error message. >>>>> >>>>> >>>>> >>>>> Andrei Chis wrote >>>>>> Hi, >>>>>> >>>>>> Thanks for the bug report. >>>>>> Can you try loading the latest version for the code of the tutorial. >>> I >>>>>> fixed the deprecation warning. >>>>>> >>>>>> Let us know if you encounter any other issues. >>>>>> >>>>>> Cheers, >>>>>> Andrei >>>>>> >>>>>> On Sun, Feb 17, 2019 at 6:49 PM Richard Kenneth Eng < >>>>> >>>>>> horrido.hobbies@ >>>>> >>>>>>> wrote: >>>>>> >>>>>>> I'm following the tutorial in the MemoryGame booklet. When I run >>> the >>>>> game >>>>>>> and click on any square, I get: >>>>>>> >>>>>>> The method BlBaseAnimation>>#startOn: called from >>>>>>> MgCardElement>>#onFlippedFace has been deprecated. >>>>>>> Use BlElement>>#addAnimation: >>>>>>> >>>>>>> The tutorial is out of sync. How can I proceed? >>>>>>> >>>>>>> Is there another way to learn how to use Bloc? >>>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>>>> >>>>> >>> >>> >>> >>> >>> >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>> >>> > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html -- www.feenk.com "We are all great at making mistakes."

Feb. 18, 2019

Re: [Pharo-users] Iceberg working with forks - can it be easier?

by Sean P. DeNigris

Tim Mackinnon wrote > wouldnât it be helpful if this was a command in Iceberg? Yes! This is a super common task and for easy cases would be great to automate https://help.github.com/articles/syncing-a-fork/ ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 18, 2019

Re: [Pharo-users] im using pharo 7 with linux env. but cannot input korean.

by Sean P. DeNigris

HilaireFernandes wrote > In your trad. chinese app were you able to key in chinese? I didn't try because the characters were pulled in from an external data source. I only needed to display them. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 18, 2019

Re: [Pharo-users] Stability of Pharo 7 vs 6?

by Tim Mackinnon

Hmmm Ben - its interesting that other languages/environments show that same stack error - and they seem to hint at memory issues- although in our case Iâm working with a simple Pharo image that has very little in it (Iâve had much larger ones in Pharo 6.x without issue). Interestingly - since launching a zeroconf image and not going full screen - its been running now for 1.5 days without a crash (whereas previously around 24 hours or less it would crash). Having said this - Iâve just started another clean zeroconf image (not full screen) and during the initial metecallo (iceberg) load - its seg faulted again - but this one I think is iceberg related as the crash.dmp looks a bit different, and I did notice that it was loading my baseline a bit slowly (and stifling with some of the dependencies, making me think that something timing related might be at issue). Having said this - Iâm still not having the smooth ride others are reporting - and 7 is still suspect to me. Iâm kind of suprised this isnât getting much traction from the core team - and I wonder if I should post this on the dev list instead? Tim > On 16 Feb 2019, at 16:27, Ben Coman <btc(a)openInWorld.com> wrote: > > I'm not on a Mac to test, but it might be worth browsing the top few of these.. > https://github.com/search?o=desc&q=can%27t+allocate+region+securely&s=creat… <https://github.com/search?o=desc&q=can%27t+allocate+region+securely&s=creat…> > > cheers -ben > > On Sat, 16 Feb 2019 at 20:10, Tim Mackinnon <tim(a)testit.works> wrote: > Iâve actually being using both - but 32bit has generally been considered the older more stable cousin (until Pharo 6 - where it was felt that 64bit was now just as stable). > > I only mentioned it - because the zeroconf example that has crashed a few of my several times - was 32 bit (but I have also had 64 bit crash too. Probably a good experiment to try zeroconf with the 64bit variation and load my baseline as well). > > I just think we might have an easily reproducable (and small) example that shows this issue that many have experienced a bit more randomly. >

Feb. 18, 2019

Re: [Pharo-users] Iceberg working with forks - can it be easier?

by Tim Mackinnon

Hey Ben - Iâm not sure that this actually does the same thing. I just tried it now, and it resulted in an extra merge in my forked repo - as I think this effectively pulls down from upstream into pharo and then if you have any differences in your local image copy they might cause some changes which then you would push back into your fork origin. If you just want a verbatim copy in your fork - you have to resort the command line? Iâm still mulling this over - as would you then pull from your upstream fork and still get the same differences that you would then apply? Iâm not sure now - but if the idea was just to get yourself back into a consistent state - Its not clear to me how you can get all 3 copies saying the same thing in pharo? Tim > On 16 Feb 2019, at 06:19, Ben Coman <btc(a)openInWorld.com> wrote: > > > > On Sat, 16 Feb 2019 at 02:06, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: > Hi guys - Iâve spent a few hours scratching my head trying to understand why some of my Pull Requests to a project I had forked kept showing my previous commits when I thought I was all caught up. > > It suddenly dawned on me, that when I had forked, and then done some work and then submitted a PR, and then applied it upstream that my fork is now no longer in sync with its upstream counterpart. > > Having not done this in ages, it took me a while to then realise I have to do some git stuff to get it back in sync e.g. (and I think Iâve got this right) > > git fetch upstream (or whatever name you gave it) > Git checkout master > Git merge upstream/master > > So I guess my question is - wouldnât it be helpful if this was a command in Iceberg? It seems quite common to fork a project (I think this is still recommended for pharo itself isnât it?) - and then at some point you need to catchup with that origin again? Or am I missing something? I guess lots of stuff can go wrong - but if it does - youâd still get the same problems on the command line. It just seems that for normal situations - it would be handy to run this straight in Pharo. > > I'm not fully-conversant with Iceberg, but if I guess right... > in Iceberg, right-click a repo and open its "Repository" window. > In the top-right click the "Add remote" button, to add the upstream repo. > That button is a bit hidden there. It might be nice to have it as a menu item on "Remotes" in the first pane. > Then click the <Merge> button, then select the upstream master branch and you should be up to date. > > cheers -ben

Feb. 18, 2019

Re: [Pharo-users] Bloc Tutorial

by horrido

So how do I force Iceberg to reload? Andrei Chis wrote > If you use repositories that start with `github://` in Metacello you are > using Iceberg. Iceberg is used to clone and load the code. Metacello is > just the interface through which that is done. > > Running the loading instruction does not pull new changes from remote > repositories. > > On Sun, Feb 17, 2019 at 10:11 PM horrido < > horrido.hobbies@ > > wrote: > >> ??? >> >> I'm not using a cloned repository. I'm using Metacello just like in the >> snippet I showed you. Shouldn't it pull in the latest repo? >> >> I've never used Iceberg; I don't know how to use it. I don't really want >> to >> fuck around with GitHub. I don't want to be pulled into a rabbit hole. >> >> >> >> Andrei Chis wrote >> > If you already have the repository cloned, running the code that you >> > mentioned does not update the content of the repository. >> > Hence, the existing version will be loaded again. >> > >> > Instead you need to do a pull using Iceberg to update the content of >> the >> > repository and the code. >> > >> > Cheers, >> > Andrei >> > >> > On Sun, Feb 17, 2019 at 8:06 PM horrido < >> >> > horrido.hobbies@ >> >> > > wrote: >> > >> >> If you're referring to this: >> >> >> >> Metacello new >> >> baseline: 'BlocTutorials'; >> >> repository: 'github://pharo-graphics/Tutorials/src'; >> >> load >> >> >> >> It made no difference. Same error message. >> >> >> >> >> >> >> >> Andrei Chis wrote >> >> > Hi, >> >> > >> >> > Thanks for the bug report. >> >> > Can you try loading the latest version for the code of the tutorial. >> I >> >> > fixed the deprecation warning. >> >> > >> >> > Let us know if you encounter any other issues. >> >> > >> >> > Cheers, >> >> > Andrei >> >> > >> >> > On Sun, Feb 17, 2019 at 6:49 PM Richard Kenneth Eng < >> >> >> >> > horrido.hobbies@ >> >> >> >> >> wrote: >> >> > >> >> >> I'm following the tutorial in the MemoryGame booklet. When I run >> the >> >> game >> >> >> and click on any square, I get: >> >> >> >> >> >> The method BlBaseAnimation>>#startOn: called from >> >> >> MgCardElement>>#onFlippedFace has been deprecated. >> >> >> Use BlElement>>#addAnimation: >> >> >> >> >> >> The tutorial is out of sync. How can I proceed? >> >> >> >> >> >> Is there another way to learn how to use Bloc? >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> >> >> >> >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 17, 2019