- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] VM crash in Pharo 8.0 during save

by ducasse

> > > I will try to get a specific scenario carefully recorded so that someone can try this. Thanks because we need reproducible cases to act. > > Bug tracking has moved to https://github.com/pharo-project/pharo/issues <https://github.com/pharo-project/pharo/issues> > > Thatâs good to know. I put lots of GUI-related stuff in Fogbugz. Does Fogbugz stuff get moved automatically to /pharo/issues, or is Fogbugz being ignored now? We decided not to migrate and we ask for people to check what are the problems that they want to migrate. Remember that there is a new version of Spec and new widgets on the table. So we are probably fixing some problems and creating new ones :) > > > Shaping

May 31, 2019

Re: [Pharo-dev] VM crash in Pharo 8.0 during save

by Shaping

From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Ben Coman Sent: Friday, May 31, 2019 04:39 To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] VM crash in Pharo 8.0 during save On Wed, 29 May 2019 at 21:21, Shaping <shaping(a)uurda.org <mailto:shaping@uurda.org> > wrote: I made a few cosmetic changes (labels in Calypso). They were working fine. But they were not showing up in Iceberg as changes at some point. Iâd done some earlier tests with Iceberg, and was able to make dummy-method changes, and commit to the local GitHub repo. Everything seemed to work. At some indeterminate point, the changes I made were no longer showing in Iceberg. Further, when I would save, the image would save and quit automatically without actually saving. Iâd relaunch, reapply the changes in the change set (Epicea), and re-save with the same results. When I tried Save Asâ¦ instead, I got the above crash. Looks like it crashed in a full garbage collection, which is something that is done when you are saving. Its been a while since I've seen one of those have been reported. Lately crashes have been more related to C libraries called by FFI. Yes, that is what I expect. Exception code: C0000005 = "access violation" Exception addr: 0000000000433CD2 Access violation (read access) at FFFFFFFFFFFFFFFF VM Version: Cog Spur VM 5.0 (release) from Jan 5 2019 Compiler: gcc 4.2.1 Compatible Clang 5.0.1 (tags/RELEASE_501/final) Interpreter Build: CoInterpreter VMMaker.oscog-eem.2504 uuid: a00b0fad-c04c-47a6-8a11-5dbff110ac11 Jan 5 2019 Cogit Build: StackToRegisterMappingCogit VMMaker.oscog-eem.2504 uuid: a00b0fad-c04c-47a6-8a11-5dbff110ac11 Jan 5 2019 Source Version: VM: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Sat Jan 5 20:00:11 2019 CommitHash: 7a3c6b6 Plugins: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Primitive trace: <snip> at: primitiveGarbageCollect **FullGC** Smalltalk stack dump: 0xb8a948 I SmalltalkImage>garbageCollect 0x5e0aa10: a(n) SmalltalkImage 0xb8a990 I Bitmap class(Behavior)>handleFailingBasicNew: 0x64294d0: a(n) Bitmap class 0xb8a9d0 M Bitmap class(Behavior)>basicNew: 0x64294d0: a(n) Bitmap class 0xb8aa08 M Bitmap class(Behavior)>new: 0x64294d0: a(n) Bitmap class 0xb8aa68 I Bitmap class>decompressFromByteArray: 0x64294d0: a(n) Bitmap class 0xb6f320 M Form>unhibernate 0x9366dc8: a(n) Form > Iâve managed to crash the VM twice Not a lot can be done by others until there is a reproducible case. You might run a debug-vm that would allow more analysis of a crash. Can you clarify you environment - OS Version, Pharo 32 or 64 bit ? Currently using an i7 laptop with 32 GB, running Windows 10 and Pharo 64-bit. Iâve a new tower that Iâm looking forward to move everything to, but thatâs a few days out. I will try to get a specific scenario carefully recorded so that someone can try this. Bug tracking has moved to https://github.com/pharo-project/pharo/issues Thatâs good to know. I put lots of GUI-related stuff in Fogbugz. Does Fogbugz stuff get moved automatically to /pharo/issues, or is Fogbugz being ignored now? Shaping

May 31, 2019

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

by Shaping

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... Just the fragmentation. Merely not falling apart is not what I would like to see happen. Broad adoption is better. There is only so much time to make the switch. Then you have to real work done again. 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? 3 ways to load code. 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. No, just Iceberg. Do we intend to have Iceberg replace Monticello and Metacello? Humans being what they are, don't respond well to that. Inertia, laziness, busy and tight schedules. If we donât have good reasons and tools to help us use the best of the tools, which I thought was Iceberg, will it ever happen? I recall similar discussions about source management in Squeak during 2002-2004 time-frame. Itâs an old problem. 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? Whatâs the plan to get everyone on Iceberg? Is there one? 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 <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. Are we using Monticello or STON to move between Smalltalks? I thought STON was the most basic way. 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. Right, thatâs not good. I believe Pharo has a great future with a preferred option going forward with Git and an option to access legacy code with Monticello. Is Metacello going away? Shaping From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org <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 <mailto:pharo-dev@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] Versioning with Iceberg

by Shaping

On 30 May 2019, at 11:55, Shaping <shaping(a)uurda.org <mailto:shaping@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. 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. 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. 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) That bit is golden, and worries me. Can we make Iceberg do what Metacello does (the thorough dependency structure) as well as it does, and phase-out Metacello? - 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? <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. These canât be Pharo versions because the numbers are too small. They must be Exercism versions, 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. Should we need to dig even one step into an Iceberg repo to remind ourselves of what we have? I would think that a clear identifier for the Repo would be created immediately after the initial connection using the project name and owner data. (BTW, is there a complete list of all pharo project repos showing the correct spellings of the project and owner names? That would be a great place to start.) Is there a more ergonomic way to present an Iceberg repo? 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. Checking out the latest tag didnât seem to do anything. The Iceberg repo show Detached HEAD? 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. 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. I also got the error: LGit_GIT_EEXISTS: Failed to stat file 'F:/_personal/Pharo/images/Shaping 7.0 - 64bit (stable)/pharo...derReturnedAnotherObjectAndNobodyReturnedGivenObject.st': The filename or extension is too long. Hereâs the file name that was too long: F:/_personal/Pharo/images/Shaping 7.0 - 64bit (stable)/pharo-local/iceberg/dionisiydk/Mocketry/Mocketry-Specs-Tests.package/SpecOfExpectedObjectSenderTests.class/instance/testFailedValidationWhenRequiredSenderReturnedAnotherObjectAndNobodyReturnedGivenObject.st' There seems to be a general problem with the context of a walkback when something goes wrong. In some, not all cases, I donât see the error window until long after the error has occurred. It does not pop up in view when the error happens. I find it later while poking around. Itâs probably in the tab list at the bottom, but I donât see it until the original context of the error is gone. This one probably happened when I tried to load the Exercism base line using âdevâ. 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. Yeah, doesnât work. Probably related to the detached HEAD. How can I fix this from inside Iceberg? You can also (although somewhat painfully), right click on all the packages in a repository and select âloadâ to do them one by one. Right. Hope this helps. It does. But this tool is painful to use, and my install or usage pattern is still broken. Not sure which yet. Shaping

May 31, 2019

Re: [Pharo-dev] VM crash in Pharo 8.0 during save

by Ben Coman

On Wed, 29 May 2019 at 21:21, Shaping <shaping(a)uurda.org> wrote: > > > I made a few cosmetic changes (labels in Calypso). They were working > fine. But they were not showing up in Iceberg as changes at some point. > > > > Iâd done some earlier tests with Iceberg, and was able to make > dummy-method changes, and commit to the local GitHub repo. Everything > seemed to work. At some indeterminate point, the changes I made were no > longer showing in Iceberg. Further, when I would save, the image would > save and quit automatically without actually saving. Iâd relaunch, reapply > the changes in the change set (Epicea), and re-save with the same results. > When I tried Save Asâ¦ instead, I got the above crash. > > > Looks like it crashed in a full garbage collection, which is something that is done when you are saving. Its been a while since I've seen one of those have been reported. Lately crashes have been more related to C libraries called by FFI. Exception code: C0000005 = "access violation" Exception addr: 0000000000433CD2 Access violation (read access) at FFFFFFFFFFFFFFFF VM Version: Cog Spur VM 5.0 (release) from Jan 5 2019 Compiler: gcc 4.2.1 Compatible Clang 5.0.1 (tags/RELEASE_501/final) Interpreter Build: CoInterpreter VMMaker.oscog-eem.2504 uuid: a00b0fad-c04c-47a6-8a11-5dbff110ac11 Jan 5 2019 Cogit Build: StackToRegisterMappingCogit VMMaker.oscog-eem.2504 uuid: a00b0fad-c04c-47a6-8a11-5dbff110ac11 Jan 5 2019 Source Version: VM: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Sat Jan 5 20:00:11 2019 CommitHash: 7a3c6b6 Plugins: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Primitive trace: <snip> at: primitiveGarbageCollect **FullGC** Smalltalk stack dump: 0xb8a948 I SmalltalkImage>garbageCollect 0x5e0aa10: a(n) SmalltalkImage 0xb8a990 I Bitmap class(Behavior)>handleFailingBasicNew: 0x64294d0: a(n) Bitmap class 0xb8a9d0 M Bitmap class(Behavior)>basicNew: 0x64294d0: a(n) Bitmap class 0xb8aa08 M Bitmap class(Behavior)>new: 0x64294d0: a(n) Bitmap class 0xb8aa68 I Bitmap class>decompressFromByteArray: 0x64294d0: a(n) Bitmap class 0xb6f320 M Form>unhibernate 0x9366dc8: a(n) Form > Iâve managed to crash the VM twice Not a lot can be done by others until there is a reproducible case. You might run a debug-vm that would allow more analysis of a crash. Can you clarify you environment - OS Version, Pharo 32 or 64 bit ? (I would like the installer to be more graceful about installing to any > folder on Windows. Can we make it so?) Canât run the .msi installer as > admin and actually install. It brings up the command line options instead. > As far as I can find, there are no Pharo-related files left in the user > account/Documents area. > You could have a go at adapting the installer to provide a concrete example of what you want. @all, where are the msi-installer sources? > > I would enter this bug at https://pharo.fogbugz.com/, but Iâm not sure it > would get quick attention there. > > > Bug tracking has moved to https://github.com/pharo-project/pharo/issues cheers -ben

May 31, 2019

[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