- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Versioning with Iceberg

by Ben Coman

HI Shaping, Its interesting getting your fresh eyes perspective on this. Often I become so fluent in working around it blunts my awareness of how it comes across to newcomers. On Fri, 31 May 2019 at 18:45, Shaping <shaping(a)uurda.org> wrote: > > > > So are you trying to actually contribute to Pharo? You donât normally need to reload pharo (if Iâve understood what you are doing). > > Yes, generally to start, I need to track my changes on 7.0.3, save them down to a local repo, and have a way to use that local repo (Iceberg-on-Git repo) to regenerate an image that is 7.0.3 plus my stuff or 8.0 plus my stuff when 8.0 is in better shape. Is your application making a lot of changes to existing Pharo code? 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. > This is a really important loop for anyone trying to switch environs, and it should get lots of attention and TLC from Pharo veterans wanting Smalltalkers to migrate to Pharo. If the new guy can do that loop reliably and repeatedly, the probability that he sticks around and pushes on with Pharo, instead of running back home to VW (done this a lot), increases greatly. And along the way, there should be no VM crashes. I still need to determine what caused those. > > - 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 The Pharo Track repo is 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. How much have you used git? Cloning the Pharo Track repo from the command line is done like this... $ git clone git@github.com:exercism/pharo-smalltalk.git 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. > 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? @Tim, another way to mitigate such user confusion would be to separate the tools out from https://github.com/exercism/pharo-smalltalk into 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. >> 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? 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. These long path names are fine on Linux, but on Windows libgit2 is constrained by 260 character paths. 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. 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… Try pulling the `pharo-smalltalk` repo to update it and check it has that line updated. cheers -ben

June 1, 2019

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

by Sven Van Caekenberghe

> On 1 Jun 2019, at 10:41, 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? > > Stephan Because BaselineOfs are simpler than ConfigurationOfs. Of course, they don't do the same thing, since tags/branches in git manage versions.

June 1, 2019

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

by Sven Van Caekenberghe

> 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. Tonel (and FileTree) are representations and models of code. > 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. >> 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 Shaping

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 Stephan Eggermont

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

June 1, 2019

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

by ducasse

> > Ok. > > So Iceberg will not try to wrap other modes of conversion and versioning like STON STON is not for versioning code. But objects. > 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 Shaping

We will try to make sure that we can still load MC package but since MC package are merely zipped files you will be able to load them by loading the st file. Or should we just organize MC/zipping/unzipping abilities under Iceberg, and call it the one-stop source management tool for Pharo and all Smalltalks that want to interact with it? Is that the slow drift? No. Use iceberg and tonel format. Ok. So Iceberg will not try to wrap other modes of conversion and versioning like STON and Monticello to provide a kind of seamless LCD approach and some backward compatibility with Monticello (without encouraging new use of Monticello)? Shaping

June 1, 2019

Re: [Pharo-dev] Default line endings while writing to a file stream

by Tim Mackinnon

Itâs a great question with a few follow onâs... In github I think we can set it to ignore line endings for certain files (Iâm assuming this is Exercism), although Iâve noticed it doesnât seem to always work very well (could be the wrong settings thought. We should check we have .st set to text in that file. Similarly however, why is there a critic for line endings in methods? Anyone know what the big deal is? I world have thought we donât care? Tim Sent from my iPhone > On 31 May 2019, at 06:06, Ben Coman <btc(a)openinworld.com> wrote: > > > I'm on Windows wanting to write a text file with LF endings. > The code developed on Linux is thus... > (destinationDirectory / 'README.md') ensureCreateFile > writeStreamDo: [ :stream | stream nextPutAll: class comment ] > > and I am stuck with CR line endings. > The specific symptom is that it screws `git diff` > Here is a simple experiment... > testfile := 'README.md' asFileReference. > testfile ensureCreateFile writeStreamDo: [ :stream | > stream nextPutAll: 'aa > bb' ]. > testfile binaryReadStream contents at: 3 "==> Character cr " > > I think its safe to assume on Linux that will result in "==> Character lf " > but can someone please confirm? > > So my issue is that I've got > #ensureCreateFile - returns a FileReference > and > :stream - is a ZnCharacterWriteStream wrapping a ZnBufferedWriteStream wrapping BinaryFileStream. > > and neither seem to have an easily accessible defaultLineEnding setting. > Indeed, line endings are not a property of FileReference > and Binary & Characters have nothing to do with line endings, > and questionable if Buffering is related. > > Its more a property of a File, but IIUC that is being deprecated (??) > > MultiByteFileStream has #lineEndConvention: > but IIUC that also is being deprecated. > > So what is the proper way to force default line endings? > > > ------ > Now while composing this email I discovered String>>withUnixLineEndings. > So I have a solution... > testfile := 'README.md' asFileReference. > testfile ensureCreateFile writeStreamDo: [ :stream | > stream nextPutAll: 'aa > bb' withUnixLineEndings ]. > (testfile binaryReadStream contents at: 3) asCharacter "==> Character lf " > > but that seems to imply that on Windows... > 'aa > bb' at: 3 "==> Character cr " > > and on Linux (someone please confirm)... > 'aa > bb' at: 3 "==> Character lf " > > and that is *very* curious. Strange that I never noticed it before and obviously that hasn't hurt me, > but considering the Principal Of Least Surprise it leaves me feeling somewhat violated :)

May 31, 2019

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

by ducasse

> On 31 May 2019, at 08:18, Shaping <shaping(a)uurda.org> wrote: > > May I suggest that you ask clear questions if you want to engage nice people to help you. > > That sounds reasonable. Which questions werenât clear? The first one where you were reported something I still cannot understand. > > Now we as a community will not use Monticello/smalltalkhub anymore > > Then officially Monticello is deprecated? Yes > We are all moving to git and iceberg is really nicely working. Iceberg will get a bit more love in the future in Pharo 80. > > Iâm looking forward to it. > > Now we spent around 1.5 years to build it and the 450 pharo packages are managed with Iceberg > and many other projects so it works. We will probably improve iceberg again. > > > We will try to make sure that we can still load MC package but since MC package are merely > zipped files you will be able to load them by loading the st file. > > Or should we just organize MC/zipping/unzipping abilities under Iceberg, and call it the one-stop source management tool for Pharo and all Smalltalks that want to interact with it? Is that the slow drift? No. Use iceberg and tonel format. > > Now this is not Pharo fault if you load a project that did not create a stable version of Pharo7.0. > > Sure, but Iâm crashing the VM, not hurting any projectâs code in the image. This is another problem and we really to understand and see how we can fix it. > > If a baseline says âload latest versionâ then why iceberg would load only Pharo 70 version? > > I donât recall the âload latest versionâ qualifier. There is none this is the default in git. > So now you can get frustrated and confused. > But did you read the booklet on how to manage code in Pharo70? books.pharo.org <http://books.pharo.org/> > > Which book are you referring to here? I will let you guess. :) > > > Did you check the wiki and the documentation? > > Yes, some. Iâm thinking itâs Smalltalk and shouldnât be that hard in any case. But there is a lot of Git here, and that is complicating things somewhat. sure it is but it also give us visibility scalability branch less foreign from other dev and monticello was a good soldier but it should rest now. > > > Shaping

May 31, 2019

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

by Shaping

May I suggest that you ask clear questions if you want to engage nice people to help you. That sounds reasonable. Which questions werenât clear? Now we as a community will not use Monticello/smalltalkhub anymore Then officially Monticello is deprecated? We are all moving to git and iceberg is really nicely working. Iceberg will get a bit more love in the future in Pharo 80. Iâm looking forward to it. Now we spent around 1.5 years to build it and the 450 pharo packages are managed with Iceberg and many other projects so it works. We will probably improve iceberg again. We will try to make sure that we can still load MC package but since MC package are merely zipped files you will be able to load them by loading the st file. Or should we just organize MC/zipping/unzipping abilities under Iceberg, and call it the one-stop source management tool for Pharo and all Smalltalks that want to interact with it? Is that the slow drift? Now this is not Pharo fault if you load a project that did not create a stable version of Pharo7.0. Sure, but Iâm crashing the VM, not hurting any projectâs code in the image. If a baseline says âload latest versionâ then why iceberg would load only Pharo 70 version? I donât recall the âload latest versionâ qualifier. So now you can get frustrated and confused. But did you read the booklet on how to manage code in Pharo70? <http://books.pharo.org> books.pharo.org Which book are you referring to here? Did you check the wiki and the documentation? Yes, some. Iâm thinking itâs Smalltalk and shouldnât be that hard in any case. But there is a lot of Git here, and that is complicating things somewhat. Shaping

May 31, 2019