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

[Pharo 8.0] Build #305: 3442-Comment-and-example-in-the-RBParseTreeRewriter-should-be-improved

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #305 was: SUCCESS. The Pull Request #3443 was integrated: "3442-Comment-and-example-in-the-RBParseTreeRewriter-should-be-improved" Pull request url: https://github.com/pharo-project/pharo/pull/3443 Issue Url: https://github.com/pharo-project/pharo/issues/3442 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 31, 2019

Re: [Pharo-dev] Versioning with Iceberg

by Shaping

On Wed, 29 May 2019 at 23:08, Shaping <shaping(a)uurda.org <mailto:shaping@uurda.org> > wrote: Iâm finding 7.0.3 to be more stable. How do I load a specific baseline/version with Iceberg? Iâm getting 8.0 by default from the cloned local repo, and I prefer not to merge 7.0.3 with 8.0. There are many differences. I want to commit my image changes locally for now on a 7.0.3. Is this what you need... ? https://github.com/pharo-vcs/iceberg/issues/1246 Yes, this seems to describe my confusing scenario exactly. Thanks. The thought is: Pharo 3.0.7 knows that it is version 3.0.7. Why then is Iceberg fetching by default version 8.0 from the Git repo? This destroys your confidence in the versioning system or, in my case, in the Pharo install itself, because I chose non-default folders, and am still wondering whether this is an issue. Can the handler of the installer of Pharo Launcher perhaps do an install to non-default folders, and test this idea. Can we tweak the installer of Pharo Launcher so that it will allow installation outside the user-account folder, without having first to create a folder under Program Files (x86) and add permissions? Iâve managed to crash the VM twice, with both Pharo 8 and Pharo 3.0.7, just by cloning a Git repo via Iceberg, and then by using Iceberg to fetch a version. Sometime during those calculations/comparisons, the VM crashed. I also used Iceberg to delete the pharo repo at several points, in order to start the exercise over. It worked, but Pharo was un-responsive in a tight synchronous thread during this operation, and there was no indication that anything sane was happening, not even a wait cursor. Iâm wondering why we choose to leave the user wondering for long stretches (many minutes during the Iceberg/Git repo delete and 1 to 2 minutes during the earlier 20-odd-package delete) what is happening inside his Smalltalk image. Can someone explain the no-wait-cursor default in Pharo GUIs? Can someone look at the .dmp file I attached to the e-mail describing the first VM crash, and tell me what he thinks happened? I saw mentions of a stack overflow. I still have the .dmp file from the second VM crash with Pharo 3.0.7, if anyone wants to see it. Shaping

May 31, 2019

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

by Sven Van Caekenberghe

Ben, Inside the image, line endings are CR on all platforms (it would be a terrible mess if not). You want ZnNewlineWriterStream. It does the necessary translations, if you want that. HTH, Sven > On 31 May 2019, at 07: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

Default line endings while writing to a file stream

by Ben Coman

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] Smalltalk to Smalltalk interface

by askoh

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. 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. Thanks for replies, Aik-Siong Koh -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

May 31, 2019

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

by Ben Coman

On Fri, 31 May 2019 at 09:09, Shaping <shaping(a)uurda.org> wrote: > Thanks for the explanation, Ben. This isnât good for the future of > Pharo. > Could you expand your thoughts on that? I don't see why. Linux didn't fall apart with the introduction of... tar, rpm, yum, apt, dnf, etc... What a headache. > I don't find it so. What is the headache for you? is it confusion about the scope of each? Maybe we need to better communicate this? Has anyone investigated automatic scripted conversion of Monticello > formats to Iceberg with Git? > I believe there has been some work. If no better answers come, search http://forum.world.st/ I donât see how this will ever be done or finished manually, humans being > what they are. > What you a promoting is forcing a monoculture. Humans being what they are, don't respond well to that. The fragmented versioning-technologies will persist then indefinitely. > Iceberg/git in only been in broad use for one year since release of Pharo 7. How fast do you expect the world to change? The diffusion of innovation applies... https://en.wikipedia.org/wiki/Diffusion_of_innovations Some people work in multiple Smalltalk versions that continue to use Monticello (http://www.squeaksource.com) and want to maintain a cross-platform package. So even with the most perfect conversion script, Monticello will remain an option. The alternative scenario of having only one versioning system would have been to stick with Monticello and avoid using git. I don't consider that viable. I believe Pharo has a great future with a preferred option going forward with Git and an option to access legacy code with Monticello. cheers -ben > > > > > Shaping > > > > *From:* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] *On Behalf > Of *Ben Coman > *Sent:* Thursday, May 30, 2019 08:45 > *To:* Pharo Development List <pharo-dev(a)lists.pharo.org> > *Subject:* Re: [Pharo-dev] FW: Versioning with Iceberg > > > > On Thu, 30 May 2019 at 18:56, Shaping <shaping(a)uurda.org> wrote: > > > > I prefer to use one tool for versioning. Is that possible now in any > version of Pharo? Can I use only Iceberg for all fetches and all > commits? Or must I sometimes use evaluables like: > > > > Metacello new > > baseline: 'Exercism'; > > repository: 'github://exercism/pharo-smalltalk/releases/latest'; > > onConflict: [ :ex | ex allow ]; > > load. > > > > Metacello operates at a higher level than Iceberg. > > Iceberg (like Monticello) versions individual packages. > > Metacello defines the version dependencies between packages, including > different git repos and Monticello repos. > > The Metacello definition is versioned like any other code, using either > Iceberg or Monticello. > > > I'm not completely sure, but I think Metacello uses Iceberg to load from > github repos, > so what that last code snippet does is... > Metacello loads the given baseline from github using Iceberg and parses it, > > then loads all the dependent baselines from their respective repos using > Iceberg or Monticello per the format they are stored in, > > then loads all the specified code versions using Iceberg or Monticello as > appropriate. > > > > Also once you've loaded an Iceberg repo containing a Metacello baseline, > you can invoke that baseline from within Iceberg. > > [image: image.png] > > > > Essentially Iceberg replaces Monticello for git repos, > > but there is a wealth of historical packages in Monticello format, so its > not disappearing either. > > > > HTH, > > cheers -ben > > >

May 31, 2019

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

by Shaping

Thanks for the explanation, Ben. This isnât good for the future of Pharo. What a headache. Has anyone investigated automatic scripted conversion of Monticello formats to Iceberg with Git? I donât see how this will ever be done or finished manually, humans being what they are. The fragmented versioning-technologies will persist then indefinitely. Shaping From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Ben Coman Sent: Thursday, May 30, 2019 08:45 To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] FW: Versioning with Iceberg On Thu, 30 May 2019 at 18:56, Shaping <shaping(a)uurda.org <mailto:shaping@uurda.org> > wrote: I prefer to use one tool for versioning. Is that possible now in any version of Pharo? Can I use only Iceberg for all fetches and all commits? Or must I sometimes use evaluables like: Metacello new baseline: 'Exercism'; repository: 'github://exercism/pharo-smalltalk/releases/latest'; onConflict: [ :ex | ex allow ]; load. Metacello operates at a higher level than Iceberg. Iceberg (like Monticello) versions individual packages. Metacello defines the version dependencies between packages, including different git repos and Monticello repos. The Metacello definition is versioned like any other code, using either Iceberg or Monticello. I'm not completely sure, but I think Metacello uses Iceberg to load from github repos, so what that last code snippet does is... Metacello loads the given baseline from github using Iceberg and parses it, then loads all the dependent baselines from their respective repos using Iceberg or Monticello per the format they are stored in, then loads all the specified code versions using Iceberg or Monticello as appropriate. Also once you've loaded an Iceberg repo containing a Metacello baseline, you can invoke that baseline from within Iceberg. Essentially Iceberg replaces Monticello for git repos, but there is a wealth of historical packages in Monticello format, so its not disappearing either. HTH, cheers -ben

May 31, 2019

Re: [Pharo-dev] Crashing in Windows 10... libssh2-1.dll

by Ben Coman

Looks like you have the tools to isolate the problem. Would you like to be coached through building your own debug-vm to help track down whats happening? cheers -ben On Fri, 31 May 2019 at 02:04, casimiro barreto <casimiro.barreto(a)gmail.com> wrote: > Happens in Cog never mind image. During load of Seaside3 (never mind) > [image: image.png] >

May 30, 2019

Re: [Pharo-dev] Versioning with Iceberg

by Tim Mackinnon

> On 30 May 2019, at 11:55, Shaping <shaping(a)uurda.org> wrote: > > 7.0.3. It loaded after a fresh clone of pharo, but with a detached head. 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). I think ben has raised a bug for you for that. However, back to your other question - I had misunderstood - actually you can load specific project (like exercism) via Iceberg (although a metacello script is often more convenient - and sometimes more precise) - 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). 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). If you want a different version than master, then have to open the repository view (cmd-r), there you can select a tag to load, and then you can use the metecallo menu. You can also (although somewhat painfully), right click on all the packages in a repository and select âloadâ to do them one by one. Hope this helps. Tim

May 30, 2019

Crashing in Windows 10... libssh2-1.dll

by casimiro barreto

Happens in Cog never mind image. During load of Seaside3 (never mind) [image: image.png] -- The information contained in this message is confidential and intended to the recipients specified in the headers. If you received this message by error, notify the sender immediately. The unauthorized use, disclosure, copy or alteration of this message are strictly forbidden and subjected to civil and criminal sanctions.

May 30, 2019