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

Re: [Pharo-users] Bloc Tutorial

by Andrei Chis

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(a)gmail.com> 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 > >

Feb. 17, 2019

Re: [Pharo-users] Bloc Tutorial

by horrido

??? 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

Feb. 17, 2019

Re: [Pharo-users] [TelePharo] Error in remote playground..

by Denis Kudriashov

Hi Sergio. I released new version of TelePharo adopted for Pharo 7. So now it should work out of the box Ð²Ñ, 12 ÑÐµÐ²Ñ. 2019 Ð³. Ð² 21:24, Denis Kudriashov <dionisiydk(a)gmail.com>: > I think it would be enough to do on client side > > 12 ÑÐµÐ²Ñ. 2019 Ð³. 21:23 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ "Denis Kudriashov" < > dionisiydk(a)gmail.com> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: > > Checkout dev branch using iceberg > > 12 ÑÐµÐ²Ñ. 2019 Ð³. 21:10 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ "sergio ruiz" <sergio.rrd(a)gmail.com> > Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: > > I am not sure I follow.. > > Do you mean grab the source from github using Iceberg? > > Thanks! > > On February 12, 2019 at 4:03:25 PM, Denis Kudriashov (dionisiydk(a)gmail.com) > wrote: > > Ah, it needs new release. > Try load dev versions of telepharo and seamless from Iceberg > > ---- > > peace, > sergio > photographer, journalist, visionary > > Public Key: http://bit.ly/29z9fG0 > #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV > http://www.codeandmusic.com > http://www.twitter.com/sergio_101 > http://www.facebook.com/sergio101 > > > >

Feb. 17, 2019

Re: [Pharo-users] Bloc Tutorial

by Andrei Chis

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(a)gmail.com> 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 > >

Feb. 17, 2019

Re: [Pharo-users] Bloc Tutorial

by horrido

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

Feb. 17, 2019

Re: [Pharo-users] Bloc Tutorial

by Andrei Chis

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(a)gmail.com> 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? >

Feb. 17, 2019

Re: [Pharo-users] Pharo 7.0 image size

by Sven Van Caekenberghe

Sure that exists: SpaceTally printSpaceAnalysis will generate a file with all the data. But it probably won't be that easy to interpret. > On 17 Feb 2019, at 18:38, Trussardi Dario Romano <dario.trussardi(a)tiscali.it> wrote: > > Ciao, > > thanks Hilaire. > >> May be you have a lot of still open Seaside session, which if I remember >> correctly are automatically shutdown after 10 min when not active. >> >> Looking at Seaside session instances may give clue. > > OK, > > but it is possible to have a report on the state of employment related to each class? > > className Instances Memory > > ClassA 222 1MB > ClassB 11 128Byte > ecc..... > > Thanks, > > Dario >> >> Hilaire >> >> >> Le 16/02/2019 Ã 13:18, Trussardi Dario Romano a Ã©crit : >>> Starting from 94 MB, now after rebooting and save the image the relative size is 252 MB. >>> >>> How can I understand what is happening? >> >> -- >> Dr. Geo >> http://drgeo.eu >> >> >> > >

Feb. 17, 2019

Bloc Tutorial

by Richard Kenneth Eng

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?

Feb. 17, 2019

Re: [Pharo-users] Pharo 7.0 image size

by Trussardi Dario Romano

Ciao, thanks Hilaire. > May be you have a lot of still open Seaside session, which if I remember > correctly are automatically shutdown after 10 min when not active. > > Looking at Seaside session instances may give clue. OK, but it is possible to have a report on the state of employment related to each class? className Instances Memory ClassA 222 1MB ClassB 11 128Byte ecc..... Thanks, Dario > > Hilaire > > > Le 16/02/2019 Ã 13:18, Trussardi Dario Romano a Ã©crit : >> Starting from 94 MB, now after rebooting and save the image the relative size is 252 MB. >> >> How can I understand what is happening? > > -- > Dr. Geo > http://drgeo.eu > > >

Feb. 17, 2019

Re: [Pharo-users] Working VM for OS X for Pharo 7

by Alistair Grant

Hi Hilaire, On Thu, 14 Feb 2019 at 11:54, Hilaire <hilaire(a)drgeo.eu> wrote: > > I know what you are describing, for example cairo can be impacted. > > My self questioning was: Does the VM rely on the host git library or is > the one shipped with the vm sufficient? I don't know the reasoning for including libgit2. For libssh2 I believe it was to ensure that certain options had been compiled in, maybe this is the same? Cheers, Alistair > Best, > > Hilaire > > Le 14/02/2019 Ã 10:33, Alistair Grant a Ã©crit : > > On Linux it is almost always: > > > > - A library isn't found because the search path is wrong, i.e. > > LD_LIBRARY_PATH needs to be set, and/or > > - there's a missing dependency. > > > > The ldd command helps track these down by showing which dependencies > > are missing. > > > > On Linux you need to be careful because the pharo script sets > > up LD_LIBRARY_PATH, so ldd may show something as missing which will be > > found when pharo is actually run, e.g libssh. > > > > Cheers, > > Alistair > > (on phone) > > -- > Dr. Geo > http://drgeo.eu > > >

Feb. 17, 2019

Re: [Pharo-users] Pharo 7.0 image size

by Hilaire

May be you have a lot of still open Seaside session, which if I remember correctly are automatically shutdown after 10 min when not active. Looking at Seaside session instances may give clue. Hilaire Le 16/02/2019 Ã 13:18, Trussardi Dario Romano a Ã©critÂ : > Starting from 94 MB, now after rebooting and save the image the relative size is 252 MB. > > How can I understand what is happening? -- Dr. Geo http://drgeo.eu

Feb. 17, 2019

Pragma "only for place of definition", is there one?

by Herby VojÄÃk

Hi! I'd just like to know if there is some pragma (eg. <onlyForMe>) which would say to a (class-level) method only to use the code in the case self is method definition class, otherwise just delegate to super. I only see it useful in class-side `initialize` method, as in: Foo class >> initialize self == Foo ifTrue: [ registry := Dictionary new ]. ^ super initialize would be Foo class >> initialize <onlyForMe> registry := Dictionary new Asking because I look for a way to easily subclass JS classes in Amber and such pragma would be useful in such cases, and since Amber treats Pharo as a reference, asking for the name of the pragma if there is one. Thanks, Herby

Feb. 16, 2019

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

by peter yoo

maybe my linux env is fail now. because xterm cannot use korean input. more check after report this thread. thanks for all. :D

Feb. 16, 2019

Re: [Pharo-users] Streams for FileReference in Pharo 7

by Alistair Grant

On Sat, 16 Feb 2019 at 15:49, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 16 Feb 2019, at 14:35, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > Hi Sven & Jan, > > > > On Fri, 15 Feb 2019 at 10:25, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> > >> Hi Jan, > >> > >> I like #<< too, but I think your assumption that it can print anything on a stream is generally wrong, dangerous and unreliable. > >> > >> IMHO, you better stick to #print: in that case. > >> > >> Consider the follow, that all fail: > >> > >> String streamContents: [ :s | s << 'hello' << 42.5 << $! ]. > >> > >> String streamContents: [ :s | s << 'hello' << (1@2) << $! ]. > >> > >> In other words: #<< works in bizar ways (check the implementors of #putOn:). > >> > >> I would be inclined to change > >> > >> ZnEncodedStream>>#<< collection > >> ^ self nextPutAll: collection > >> > >> to > >> > >> ZnEncodedStream>>#<< collection > >> ^ self nextPutAll: collection asString > >> > >> but it would technically not be the same as the original #<< for in-memory streams. > >> > >> Opinions ? > > > > I've often thought that this change would be nice to have. #putOn: > > doesn't really fit in with writing to text streams (text in the loose > > sense of "something that will be read"). > > > > I think an argument could be made that #printString or #displayString > > should be used, but they both have their own issues in practice. > > So... > > > > +1 to "collection asString". > > > > Cheers, > > Alistair > > I have been thinking a bit more about this, and I have a lot of problems with > > Integer>>#putOn: aStream > aStream isBinary > ifTrue: [ self asByteArray do: [ :each | aStream nextPut: each ] ] > ifFalse: [ self asString putOn: aStream ] > > I think we should simply remove this method. It is ugly and wrong. > > #<< should simply be a shortcut for either #nextPut: and #nextPutAll: and nothing more. > > The following two are OK for me: > > String streamContents: [ :out | out << 'Hello' << $! ]. > ByteArray streamContents: [ :out | out << #[ 1 2 3 ] << 4 ]. > > But the following most definitively not: > > (ByteArray streamContents: [ :out | out << 16rFF << 16rFF11 << 16rFFFF22 << 16rFFFFFF33 ]) hex. > > When you write out an integer, you have to decide its size, that can never depend on the magnitude (because there is no way to read this back unless there is additional bracketing). > > Also, printing to a stream should be (very) efficient. Making copies of objects just for conversion purposes should be avoided. > > I think that if we remove Integer>>#putOn: I could live with > > ZnEncodedStream>>#<< anObject > anObject putOn: self > > The other solution is to define #<< as strictly the same as #nextPutAll: and remove all #putOn: implementors. My thoughts aren't fully formed on this, but: I think we can break the streams up in to three categories: - Streams of arbitrary objects, i.e. streams writing to Arrays, OrderedCollections, etc. - Streams that serialise the objects, e.g. JSON, STON, ASN.1, etc. - Streams that write to some form of text output intended for human reading. We can then group the messages used by each category: - Arbitrary object: nextPut:, nextPutAll:, putOn:, etc. - Serialising: stonOn:, etc. - Text: <<, cr, lf, etc. Following these guidelines: - I'd remove the Integer>>putOn: as you suggest. - Add the #asString to ZnEncodedStream>><< as suggested earlier. Cheers, Alistair

Feb. 16, 2019

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

by Ben Coman

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… 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. 16, 2019