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

Zinc-FileSystem-SvenVanCaekenberghe.20.mcz Empty .st
by lpaniceres June 4, 2019

June 4, 2019

I'm experiencing a problem with tha package Zinc-FileSystem-SvenVanCaekenberghe, MOnticello downloas the file Zinc-FileSystem-SvenVanCaekenberghe.20.mcz with an empty source.st. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

3 2

[Pharo 8.0] Build #310: 3410-[Trait] Impossible to use from a classTrait a method that is also defined in a subclass of Behavior even when following the doc
by ci-pharo-ci-jenkins2＠inria.fr June 4, 2019

June 4, 2019

There is a new Pharo build available! The status of the build #310 was: FAILURE. The Pull Request #3426 was integrated: "3410-[Trait] Impossible to use from a classTrait a method that is also defined in a subclass of Behavior even when following the doc" Pull request url: https://github.com/pharo-project/pharo/pull/3426 Issue Url: https://github.com/pharo-project/pharo/issues/3410 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 8.0] Build #309: Adding the execution of the benchmark job.
by ci-pharo-ci-jenkins2＠inria.fr June 4, 2019

June 4, 2019

There is a new Pharo build available! The status of the build #309 was: SUCCESS. The Pull Request #3423 was integrated: "Adding the execution of the benchmark job." Pull request url: https://github.com/pharo-project/pharo/pull/3423 Issue Url: https://github.com/pharo-project/pharo/issues/automating Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Re: [Pharo-dev] Versioning with Iceberg
by Shaping June 3, 2019

June 3, 2019

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. Shaping

9 44

Default line endings while writing to a file stream
by Ben Coman June 3, 2019

June 3, 2019

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 :)

6 8

OSProcess and CommandShell available on GitHub for Pharo users
by David T. Lewis June 3, 2019

June 3, 2019

Alistair Grant and I, with the support of Feenk, have made GitHub repositories for OSProcess and CommandShell at: https://github.com/dtlewis290/OSProcess-Tonel https://github.com/dtlewis290/CommandShell-Tonel Alistair did the conversions using Peter Uhn??k's migration tool, and I set up the repositories so that they can now be loading in Pharo as follows: Metacello new repository: 'github://dtlewis290/OSProcess-Tonel/src'; baseline: 'OSProcess'; load. Metacello new repository: 'github://dtlewis290/CommandShell-Tonel/src'; baseline: 'CommandShell'; load. Note, the two respositories are named *-Tonel because I also maintain a GitHub repository for OSProcess on Cuis, and will probably do repositories in Squot format in the future. @Thierry Goubier - If you have an account on GitHub I will add you as a collaborator (but my own development work remains on squeaksource so I prefer contributions there anyway). Enjoy, Dave and Alistair

1 0

Ring renaming in P8, Manifests and deprecations
by Torsten Bergmann June 3, 2019

June 3, 2019

Hi, just to let you know: If one develops a project in Pharo 7 (or before) including a manifest with banned rules this may lead to trouble in upcoming Pharo 8. Within the manifest you will find methods referencing "RGPackage" class: "code-critics" ruleRBLiteralArrayContainsCommaRuleV1FalsePositive ^ #(#(#(#RGPackage #(#'Funny-App')) #'2019-06-02T17:05:15.359384+02:00') ) If you load the code into latest Pharo 8 it is not possible to browse the manifest class in Calypso without errors as RGPackage class is missing in Pharo 8. This goes back to a PR from Pavel: https://github.com/pharo-project/pharo/pull/3226 to consolidate and rename RGPackage into RGPackageDefinition. I support the PR - but not the way how it is done as it does not consider keeping and deprecating the old RGPackage class. For sure one can easily adopt the Manifest methods by replacing #RGPackage with #RGPackageDefinition - but be aware that accidentially or not we add more and more burden especially to new users and future migrators. IMHO we should "deprecate" and keep classes around at least one pharo version iteration whenever possible. (see also the deprecation guide http://forum.world.st/Deprecation-guide-for-methods-classes-and-packages-td…) We could have RGPackageDefinition as the new class, and keep the old class RGPackage as a subclass of RGPackageDefinition in a "Deprecated80" package so we can easily remove it with the start of the P9 iteration. I also wonder why we still have the "Deprecated70" package around in latest P8 image and why we do not remove it as usual and just start a fresh "Deprecated80" package. It was a simple scheme and worked in the past without much hazzle. Last time this was asked there was a discussions about a possible migration tool - but so far without any visible progress to my knowledge. Even if such a tool exists it could use the "Deprecated70" package even after removal by just loading it... Thanks T.

1 0

Re: [Pharo-dev] [Vm-dev] Image crashing on startup, apparently during GC
by Eliot Miranda June 3, 2019

June 3, 2019

Hi Damien, On Fri, Mar 23, 2018 at 12:38 PM, Damien Pollet <damien.pollet(a)gmail.com> wrote: > > Here are the files (image and various outputs). Running with --leakcheck > does mention a few object leaks (see output.txt); > Indeed the image is corrupt at start-up. See below. > I'm not sure where to get or how to build an assert VM. > When you build a phar. VM under build.macos64x64/pharo.cog.spur using the mvm script (mvm -A) you produce an assert VM in PharoAssert.app. > I also realized the VM I had was from this summer (the one that comes with > a 70 image with zeroconf). The output files I include were produced by the > VM at get.pharo.org/64/vmLatest70 > > https://www.dropbox.com/s/y8yqjuzd9nsvy1u/clap-broken.tar.gz?dl=0 > > On 20 March 2018 at 18:17, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > >> >> Hi Damien, >> >> On Tue, Mar 20, 2018 at 3:12 AM, Damien Pollet <damien.pollet(a)gmail.com> >> wrote: >> >>> >>> Hi, I have a Pharo image that crashes the VM on startup. The crash >>> report below seems to incriminate GC. Should I make it available somewhere >>> online? What's most convenient? >>> >> >> Don't care. Anywhere it can be downloaded from. Also, try running with >> -leakcheck 15, preferably in an assert VM and see if that gets you >> additional information. >> >> >>> >>> Process: Pharo [64892] >>> Path: /Users/USER/*/Pharo.app/Contents/MacOS/Pharo >>> Identifier: org.pharo.Pharo >>> Version: 5.0.201708271955 (5.0.201708271955) >>> >> Right. This VM is prior to the bug fixes in VMMaker.oscog-eem.2320: Spur: Fix a bad bug in SpurPlnningCompactor. unmarkObjectsFromFirstFreeObject, used when the compactor requires more than one pass due to insufficient savedFirstFieldsSpace, expects the corpse of a moved object to be unmarked, but copyAndUnmarkObject:to:bytes:firstField: only unmarked the target. Unmarking the corpse before the copy unmarks both. This fixes a crash with ReleaseBuilder class>>saveAsNewRelease when non-use of cacheDuring: creates lots of files, enough to push the system into the multi-pass regime. Pharo urgently needs to upgrade the VM to one more up to date than 2017 08 27 (in fact more up-to-date than opensmalltalk/vm commit 0fe1e1ea108e53501a0e728736048062c83a66ce, Fri Jan 19 13:17:57 2018 -0800). The bug that VMMaker.oscog-eem.2320 fixes can result in image corruption in large images, and can occur (as it has here) at start-up, causing one's work to be irretrievably lost. > Code Type: X86-64 (Native) >>> Parent Process: ??? [64888] >>> Responsible: Pharo [64892] >>> User ID: 501 >>> >>> Date/Time: 2018-03-19 20:27:03.906 +0100 >>> OS Version: Mac OS X 10.13.3 (17D102) >>> Report Version: 12 >>> Anonymous UUID: 6D022236-78DD-6676-117F-EADA56D5D1BE >>> >>> Sleep/Wake UUID: AC9E4E55-3CDB-4B4F-A6B4-51ACB1177154 >>> >>> Time Awake Since Boot: 28000 seconds >>> Time Since Wake: 6500 seconds >>> >>> System Integrity Protection: enabled >>> >>> Crashed Thread: 0 Dispatch queue: com.apple.main-thread >>> >>> Exception Type: EXC_BAD_ACCESS (SIGABRT) >>> Exception Codes: KERN_INVALID_ADDRESS at 0x000000012b67c0b0 >>> Exception Note: EXC_CORPSE_NOTIFY >>> >>> VM Regions Near 0x12b67c0b0: >>> VM_ALLOCATE 000000011adfc000-00000001259fc000 [172.0M] >>> rw-/rwx SM=PRV >>> --> >>> STACK GUARD 0000700005613000-0000700005614000 [ 4K] >>> ---/rwx SM=NUL stack guard for thread 1 >>> >>> Application Specific Information: >>> abort() called >>> >>> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread >>> 0 libsystem_kernel.dylib 0x00007fff53fbde3e __pthread_kill + 10 >>> 1 libsystem_pthread.dylib 0x00007fff540fc150 pthread_kill + 333 >>> 2 libsystem_c.dylib 0x00007fff53f1a312 abort + 127 >>> 3 org.pharo.Pharo 0x0000000104ed8997 sigsegv + 190 >>> 4 libsystem_platform.dylib 0x00007fff540eff5a _sigtramp + 26 >>> 5 ??? 000000000000000000 0 + 0 >>> 6 org.pharo.Pharo 0x0000000104e73558 markObjects + 464 >>> 7 org.pharo.Pharo 0x0000000104e72d40 fullGC + 72 >>> 8 org.pharo.Pharo 0x0000000104e92dea primitiveFullGC + >>> 45 >>> 9 org.pharo.Pharo 0x0000000104e52425 interpret + 26715 >>> 10 org.pharo.Pharo 0x0000000104e5c7f6 >>> enterSmalltalkExecutiveImplementation + 152 >>> 11 org.pharo.Pharo 0x0000000104e4be6c interpret + 674 >>> 12 org.pharo.Pharo 0x0000000104ed9cc1 >>> -[sqSqueakMainApplication runSqueak] + 394 >>> 13 com.apple.Foundation 0x00007fff2e6d696c >>> __NSFirePerformWithOrder + 360 >>> 14 com.apple.CoreFoundation 0x00007fff2c579127 >>> __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23 >>> 15 com.apple.CoreFoundation 0x00007fff2c57904f >>> __CFRunLoopDoObservers + 527 >>> 16 com.apple.CoreFoundation 0x00007fff2c55b6a8 __CFRunLoopRun + >>> 1240 >>> 17 com.apple.CoreFoundation 0x00007fff2c55af43 >>> CFRunLoopRunSpecific + 483 >>> 18 com.apple.HIToolbox 0x00007fff2b872e26 >>> RunCurrentEventLoopInMode + 286 >>> 19 com.apple.HIToolbox 0x00007fff2b872a9f >>> ReceiveNextEventCommon + 366 >>> 20 com.apple.HIToolbox 0x00007fff2b872914 >>> _BlockUntilNextEventMatchingListInModeWithFilter + 64 >>> 21 com.apple.AppKit 0x00007fff29b3df5f _DPSNextEvent + >>> 2085 >>> 22 com.apple.AppKit 0x00007fff2a2d3b4c >>> -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] >>> + 3044 >>> 23 com.apple.AppKit 0x00007fff29b32d6d -[NSApplication >>> run] + 764 >>> 24 com.apple.AppKit 0x00007fff29b01f1a NSApplicationMain >>> + 804 >>> >>> -- >>> Damien Pollet >>> type less, do more [ | ] http://people.untyped.org/damien.pollet >>> >>> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot >> >> > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > > -- _,,,^..^,,,_ best, Eliot

9 26

[Pharo 8.0] Build #308: 3447-hex-deserves-an-executable-comment
by ci-pharo-ci-jenkins2＠inria.fr June 2, 2019

June 2, 2019

There is a new Pharo build available! The status of the build #308 was: SUCCESS. The Pull Request #3448 was integrated: "3447-hex-deserves-an-executable-comment" Pull request url: https://github.com/pharo-project/pharo/pull/3448 Issue Url: https://github.com/pharo-project/pharo/issues/3447 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

SpecDemo open freezes the system ...
by ducasse June 2, 2019

June 2, 2019

In latest P8

1 0