- Pharo-dev - lists.pharo.org

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

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

by ducasse

Hi Shape May I suggest that you ask clear questions if you want to engage nice people to help you. Now we as a community will not use Monticello/smalltalkhub anymore 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. 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. Now this is not Pharo fault if you load a project that did not create a stable version of Pharo7.0. If a baseline says âload latest versionâ then why iceberg would load only Pharo 70 version? 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/> Did you check the wiki and the documentation? Stef

May 31, 2019

Re: [Pharo-dev] Smalltalk to Smalltalk interface

by ducasse

Hi > What is the means of communication used between VW and Pharo to pass STON > files as objects? > I would like something where VW starts up Pharo and asks Pharo to do > something that is not available in VW and pass back the answers. So did you try to build it? > I think all the Smalltalk dialects should be able to call each other with > easy to attain the union of all the capabilities of Smalltalk dialects. No > need to port one dialect to another but to collaborate in execution. I think many things but what I do is to take the most important ones and work on them. You see the future is Pharo. Now what can you do to prepare your future. Do you have tests? Because the day where you will really want to migrate then they will be your best friends. I decided that I will never ever program and invest in a system that is not open-source. > Thanks for replies, > Aik-Siong Koh > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

May 31, 2019