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

Re: [Pharo-dev] Environments

by Alexandre Bergel

Hi! Each class can answer to the message #environment. For example: Array environment => a SystemDictionary(lots of globals) The environment message returns the environment in which the class is visible. If you wish to build modules / namespaces, you probably want to benefit from this. Hope it helps. Cheers, Alexandre > On Jun 1, 2019, at 7:00 PM, Shaping <shaping(a)uurda.org> wrote: > > Does anyone have experience with Squeak Environments? This came up in the Cuis list. Environments are Squeakâs attempt at a module or namespace system. Does this exist for Pharo? Has anyone worked with it, and found it to be usable? > > Shaping

June 1, 2019

Environments

by Shaping

Does anyone have experience with Squeak Environments? This came up in the Cuis list. Environments are Squeakâs attempt at a module or namespace system. Does this exist for Pharo? Has anyone worked with it, and found it to be usable? Shaping

June 1, 2019

Re: [Pharo-dev] FW: Versioning with Iceberg

by Shaping

Iâm thinking every Smalltalk would have an Iceberg. It would be the go-to tool for versioning and conversion of Smalltalk code for any environ. Let it makes this clear. Iâm personally not interested in moving code from Pharo to VW. I gave its chance long time ago to VW and I only got bad feelings and frustration. Yes, the bad feelings mostly pass; it takes many years. But there are still those occasional, special moments of deep resentment. So do not expect me to push any action in this direction. The same applies to Squeak. If I would not have created Pharo I would work in Ruby or Python. People paid by VW should do their job not me. Or you can do it if this is in your roadmap. My goal is to have the best environment possible and Iâm working to make it. My goal is not to have a smalltalk system compatible with the rest of the universe. Now since people deploy on Gemstone we will pay attention to them and ideally I would love to have the ressources to make Pharo fully execute with compiler and other on top of GS VM. Now GS is not VW. :) Yes, GS is a very different system. For now, Iâll settle for getting Iceberg to work reliably in 7.0.3. Perfect. We all use it daily so let know. Are the best references on Iceberg the Pharo books or the Iceberg GitHub site? Check both you may find some little differences but in general this is stable. Which Iceberg material is most up-to-date for Pharo 7.0.3? I do not know. Nothing important changes between 7.0.3 and 8. Is anyone reporting stability/VM problems with Pharo installed to a non-default directory and/or when working with GitHub repos not kept in the default subfolder of the image folder? I do not know. Windows is often a pain (with file name encodings and others). Indeed, Windows is a pain. If you report situations that we can reproduce and that are not super super specific we will definitively have a look. My Pharo 3.0.7 install and all repos are in non-default directories, and Iâm wondering whether this is causing the crashes. I do not know what is a non-default repo. Iâm referring only to a non-default directory for the repo files, which you would think would not matter, or perhaps a file-not-found exception would be raised. But I donât see that. On Windows, the default folder is in an \images subfolder. I currently keep all my Git repos on a separate RAID drive. Now on windows the state of the libraries to run scripts is making us trouble Can you give more details on that? What are the problems? and we will have to fix it. Shaping

June 1, 2019

Re: [Pharo-dev] Versioning with Iceberg

by Shaping

Is your application making a lot of changes to existing Pharo code? Not yet, I just want to explore for a bit, and see what Pharo has to offer. But yes, there will be extensive changes to Pharo, eventually, after I get most of my stuff ported. I need to do some speed tests. Speed is one big issue. Others are: which way do I port code in the short-term and long-term, and can I move all to Pharo and stay there? More immediately, in preparation, I'm trying to get all the creature comforts working the way they do in VW. I prefer the more detailed syntax highlighting in VW. I forgot all the differences, but recall more levels of parentheses can be colored uniquely in VW and so can block-argument variables. That would be a first small project: make Pharo syntax highlight at least as good as VWâs. I need to do the same for formatting, which I've not checked out very thoroughly yet. The other thing that has been causing problems and about which I've written some examples in Fogbugz (which no one is using anymore for Paroâand I didnât know, lol) is that Pharo labels are truncated if you switch to a monospace font. I can't see what I'm doing some of the time because the labels are chopped, and there is no automatic formatting of the fields to accommodate the new font, which is not even very big--just normal-sized monospace. I suppose Spec takes care of this problem systematically and that this is why nothing else has been done to fix the problem. Are you aware of "extension methods" ? Where a method you add to a built-in Pharo class (Collection for example) is saved/loaded with your package. Then you only need to manage your package not Pharo built-in packages as well. Yes, I'm trying to get an Iceberg-on-Git groove going so that I can make my own packages for extensions/overrides. Thatâs currently where Iâm stuck, and I need to do some VW work this weekend, but I try to work with Pharo as often as I can. > > - if you pick Add, then choose GitHub, then enter the owner and project (e.g. for exercism - owner = exercism, project = pharo-smalltalk), this will get you the baseline (but wonât load any packages). > > After I do the above, Iceberg lists a repo called pharo-smalltalk. Was this intentional? Yes, this the the repo name assigned by the Exercism administrators. The Exercism project has 50 language tracks each with their own repo... <https://github.com/exercism> https://github.com/exercism The Pharo Track repo is <https://github.com/exercism/pharo-smalltalk> https://github.com/exercism/pharo-smalltalk > Above is the Exercism GitHub page. The URL and doc mention both Exercism and pharo-smalltalk, but the former is not found in the GUI anywhere to tell the user what he has (without additional digging). > I just cloned Exercism. I thought it would be identified somewhere besides in the Git commit comments. The Iceberg repo context menu item Repository (strange name given that we are already in an Iceberg repo) lists the repo as âRepository of pharo-smalltalkâ with a master node, origin node and several version tags. Cloning the Pharo Track repo from the command line is done like this... $ git clone <mailto:git@github.com:exercism/pharo-smalltalk.git> git@github.com:exercism/pharo-smalltalk.git Sure, but we can do this in Icebergâand it works. So why use the command line? which creates a folder with the same name as the repo (i.e. "pharo-smalltalk") As a git GUI, Iceberg does the same. Indeed, Iceberg uses libgit2 to do this, so the behaviour is standard git. I was commenting on the ergonomics, and yes this is very much a Git thing. > These canât be Pharo versions because the numbers are too small. They must be Exercism versions, yes. > but âexercismâ isnât mentioned anywhere, except in some of the Git commit comments, or I missed it. So there is some immediate disorientation on that account. If I choose Packages on the Iceberg repo context menu, I can see that this repo is all about Exercism. Would a hover tool tip showing "owner/repo" clear this up for you? You see the train of thought, broken down that way in steps to show the clumsiness. Hover help seems like an afterthought, but a good oneâmuch better than nothing. Presenting a Smalltalk project in Iceberg without a name when the name (and owner) is known is not âleast astonishingâ. Iâm wondering why someone thought this was okay. I guess we are just mirroring Git as a default. Iâm wondering why the name just isnât more prominent in the Git scheme of things and if this is @Tim, another way to mitigate such user confusion would be to separate the tools out from <https://github.com/exercism/pharo-smalltalk> https://github.com/exercism/pharo-smalltalk into <https://github.com/pharo-exercism/exercism-tools> https://github.com/pharo-exercism/exercism-tools. > Would the Iceberg GUI make more sense as a split pane arrangement where the stuff listed in the Repository window is shown in the right pain after selecting a well-named Iceberg repo in the left pane? We could have bubble-help on the listed repos and details in the right pane on repo selection. I can't parse that description. A graphical mockup would be more useful to discuss. Take the GUI you have already in the Repository window (now opened from the Repository context menu item), and instead make that GUI the right pane in a new GUI, with the current Iceberg repo list becoming the left pane of that new GUI. When using the new GUI, select a repo name in the left pane to see its details populate the right pane. Then go into the right pane, and select a version tag, for example, and do other things with the repo. >> Now you have to right click on the repository, and pick the Metacello menu item, and then you can load baseline (which gives you the default), or you can enter a group name (e.g. âdevâ for exercism). > > I loaded the default baseline and see 4 packages up to date and the rest unloaded. Thats right, the default-baseline is for students. The other packages are only required by mentors & maintainers. > When I tried âdevâ I got an assertion failure on the SSH creds. Did I miss a step concerning SSH creds on install? But the loading seemed to continue. Given that it already loaded the 4 packages, your SSH creds have already been proven working. Before considering this further, just need to ask how reliable your internet connection is? Very good: 60 Mbps at the low end. A poor connection might also explain some of your PharoLauncher "identifying VM version" issues. > I also got the error: > > LGit_GIT_EEXISTS: Failed to stat file ' > F:/_personal/Pharo/images/Shaping 7.0 - 64bit (stable)/pharo-local/iceberg/dionisiydk/Mocketry/Mocketry-Specs-Tests.package/SpecOfExpectedObjectSenderTests.class/instance/testFailedValidationWhenRequiredSenderReturnedAnotherObjectAndNobodyReturnedGivenObject.st' Those very long path names come from a repo in FileTree format. FileTree format was used by some people to fileout code to work with git from the command outside of Pharo. Okay. These long path names are fine on Linux, but on Windows libgit2 is constrained by 260 character paths. Okay. FileTree also had a file per method creating a massive number of small files, which was fine on Linux but a big performance problem on Windows. To address these issues Tonel format was created with a class per file. Okay. So this is an old repo that has not been updated to use Tonel, and all Windows machines will have the name-length limit. I suppose the problem is rare because everyone is converting to Tonel. I experienced the same error and fixed it by converting Mocketry to Tonel format here... github://pharo-exercism/Mocketry and updated the baseline here... <https://github.com/exercism/pharo-smalltalk/blob/master/dev/src/BaselineOfE…> https://github.com/exercism/pharo-smalltalk/blob/master/dev/src/BaselineOfE… Try pulling the `pharo-smalltalk` repo to update it and check it has that line updated. Will do. Thanks. Shaping

June 1, 2019

Re: [Pharo-dev] FW: Versioning with Iceberg

by Shaping

[...] Tonel (and FileTree) are representations and models of code. Okay. Is one preferred? > For now, Iâll settle for getting Iceberg to work reliably in 7.0.3. Are the best references on Iceberg the Pharo books or the Iceberg GitHub site? Which Iceberg material is most up-to-date for Pharo 7.0.3? > > Is anyone reporting stability/VM problems with Pharo installed to a non-default directory and/or when working with GitHub repos not kept in the default subfolder of the image folder? My Pharo 3.0.7 install and all repos are in non-default directories, and Iâm wondering whether this is causing the crashes. Iceberg works very well in 7.x and 8, it is the default after all. You are on Windows, other Windows users should answer. Yes, Windows 10 Pro and running 64-bit Pharo.

June 1, 2019

Re: [Pharo-dev] FW: Versioning with Iceberg

by Stephan Eggermont

Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > Configurations were managing project versionning and project > dependencies while baselines are only managing the dependencies since > the project versionning is done by git with it commit by project > opposed to the commit by package of Monticello. Ok, so that makes the handling of projects with lots of packages easier by eliminating the simple problem of having to write down the exact version number of these packages. That helps Stephan

June 1, 2019

Re: [Pharo-dev] FW: Versioning with Iceberg

by Stephan Eggermont

Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 1 Jun 2019, at 10:41, Stephan Eggermont <stephan(a)stack.nl> wrote: > >> Could you explain how configurations are simpler? >> >> Stephan > > Because BaselineOfs are simpler than ConfigurationOfs. > > Of course, they don't do the same thing, since tags/branches in git manage versions. That is not what I see actually happening with baselines. They are referring to branches and versions Stephan

June 1, 2019

Re: [Pharo-dev] FW: Versioning with Iceberg

by ducasse

> On 1 Jun 2019, at 11:08, Shaping <shaping(a)uurda.org> wrote: > > > Ok. > > So Iceberg will not try to wrap other modes of conversion and versioning like STON > > STON is not for versioning code. > But objects. > > Yes, I know. I was referring to its possible use in moving Smalltalk between environs. Itâs normally used for domain objects, but it could be used to serialize code itself (just another domain object), if we have no universal chunk format for Smalltalk. Seems that STON could be managed somehow from within Iceberg to move class/method definitions, but we also have the different package- and namespace- structures needing specialization for each environment. Similar comments apply to unique syntax specializations, like the period-delimited literal-array evaluables possible in Pharo, but not in VW, for example. see below. > STON under Iceberg might also let us add or strip class-name prefixes, automatically, when porting between Smalltalks with/without modules/namespaces, like VW and Pharo, for example. see below > Iâm thinking every Smalltalk would have an Iceberg. It would be the go-to tool for versioning and conversion of Smalltalk code for any environ. Let it makes this clear. Iâm personally not interested in moving code from Pharo to VW. I gave its chance long time ago to VW and I only got bad feelings and frustration. So do not expect me to push any action in this direction. The same applies to Squeak. If I would not have created Pharo I would work in Ruby or Python. People paid by VW should do their job not me. Or you can do it if this is in your roadmap. My goal is to have the best environment possible and Iâm working to make it. My goal is not to have a smalltalk system compatible with the rest of the universe. Now since people deploy on Gemstone we will pay attention to them and ideally I would love to have the ressources to make Pharo fully execute with compiler and other on top of GS VM. Now GS is not VW. :) > For now, Iâll settle for getting Iceberg to work reliably in 7.0.3. Perfect. We all use it daily so let know. > Are the best references on Iceberg the Pharo books or the Iceberg GitHub site? Check both you may find some little differences but in general this is stable. > Which Iceberg material is most up-to-date for Pharo 7.0.3? I do not know. Nothing important changes between 7.0.3 and 8. > Is anyone reporting stability/VM problems with Pharo installed to a non-default directory and/or when working with GitHub repos not kept in the default subfolder of the image folder? I do not know. Windows is often a pain (with file name encodings and others). If you report situations that we can reproduce and that are not super super specific we will definitively have a look. > My Pharo 3.0.7 install and all repos are in non-default directories, and Iâm wondering whether this is causing the crashes. I do not know what is a non-default repo. Now on windows the state of the libraries to run scripts is making us trouble and we will have to fix it. > > > >> and Monticello to provide a kind of seamless LCD approach and some backward compatibility with Monticello (without encouraging new use of Monticello)? > > No because the distance is too large. We cannot burn our two engineers on ânice to haveâ when the âmust haveâ is > not yet done. > Now migrating to iceberg is super easy and configurations are a lot simpler than with monticello. > > Stef > > > Shaping

June 1, 2019

Re: [Pharo-dev] FW: Versioning with Iceberg

by ducasse

Please cut your questions in different threads. > On 1 Jun 2019, at 11:08, Shaping <shaping(a)uurda.org> wrote: > > > Ok. > > So Iceberg will not try to wrap other modes of conversion and versioning like STON > > STON is not for versioning code. > But objects. > > Yes, I know. I was referring to its possible use in moving Smalltalk between environs. Itâs normally used for domain objects, but it could be used to serialize code itself (just another domain object), if we have no universal chunk format for Smalltalk. Seems that STON could be managed somehow from within Iceberg to move class/method definitions, but we also have the different package- and namespace- structures needing specialization for each environment. Similar comments apply to unique syntax specializations, like the period-delimited literal-array evaluables possible in Pharo, but not in VW, for example. STON under Iceberg might also let us add or strip class-name prefixes, automatically, when porting between Smalltalks with/without modules/namespaces, like VW and Pharo, for example. Iâm thinking every Smalltalk would have an Iceberg. It would be the go-to tool for versioning and conversion of Smalltalk code for any environ. > > For now, Iâll settle for getting Iceberg to work reliably in 7.0.3. Are the best references on Iceberg the Pharo books or the Iceberg GitHub site? Which Iceberg material is most up-to-date for Pharo 7.0.3? > > Is anyone reporting stability/VM problems with Pharo installed to a non-default directory and/or when working with GitHub repos not kept in the default subfolder of the image folder? My Pharo 3.0.7 install and all repos are in non-default directories, and Iâm wondering whether this is causing the crashes. > > > >> and Monticello to provide a kind of seamless LCD approach and some backward compatibility with Monticello (without encouraging new use of Monticello)? > > No because the distance is too large. We cannot burn our two engineers on ânice to haveâ when the âmust haveâ is > not yet done. > Now migrating to iceberg is super easy and configurations are a lot simpler than with monticello. > > Stef > > > Shaping

June 1, 2019

Re: [Pharo-dev] FW: Versioning with Iceberg

by Cyril Ferlicot

On Sat, Jun 1, 2019 at 10:42 AM Stephan Eggermont <stephan(a)stack.nl> wrote: > > ducasse <stepharo(a)netcourrier.com> wrote: > > Now migrating to iceberg is super easy and configurations are a lot > > simpler than with monticello. > > Could you explain how configurations are simpler? Configurations were managing project versionning and project dependencies while baselines are only managing the dependencies since the project versionning is done by git with it commit by project opposed to the commit by package of Monticello. This make configurations a lot simpler IMO. > > Stephan > > -- Cyril Ferlicot https://ferlicot.fr

June 1, 2019