February 2018 - Pharo-dev - lists.pharo.org

Pharo 7 Repeatable crash: XIO: fatal IO error 14 (Bad address) on X server ":0"

by Martin McClure

On the current Linux32 Pharo 7.0, (https://get.pharo.org/70+vm as of 30 minutes ago) the VM crashes with the message XIO:Â fatal IO error 14 (Bad address) on X server ":0" whenever I try to enlarge the Pharo window by dragging the corner, and get to a size of about 2Mpixels. This is with a virgin image with no windows open inside the main window. A workaround seems to be to open a System Browser before resizing the main window. This does not reproduce on Pharo 6.1 (https://get.pharo.org/) This *does* reproduce when running the Pharo7 image on the Pharo 6.1 VM, so it may not be entirely a VM problem. Most times, no crash dump is created, and nothing is logged to PharoDebug.log. Occasionally, especially when rapidly changing the size of the window, it segfaults and logs a dump. This may or may not be the same problem.Â This is less annoying since I found the workaround, but still seems to be something that should be fixed. Does anyone want further information from me in order to fix it? Regards, -Martin

Feb. 21, 2018

[Pharo 7.0-dev] Build #589: 21385-The-dialog-for-Unknown-variable-should-allow-to-leave-the-variable-undefined

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

There is a new Pharo build available! The status of the build #589 was: FAILURE. The Pull Request #926 was integrated: "21385-The-dialog-for-Unknown-variable-should-allow-to-leave-the-variable-undefined" Pull request url: https://github.com/pharo-project/pharo/pull/926 Issue Url: https://pharo.fogbugz.com/f/cases/21385 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 21, 2018

Re: [Pharo-dev] Loading Zinc components in Pharo 7.0 breaks the image

by Juraj Kubelka

Thank you! I missed that part. Juraj > El 21-02-2018, a las 03:41, Sven Van Caekenberghe <sven(a)stfx.eu> escribiÃ³: > > > >> On 20 Feb 2018, at 17:32, Juraj Kubelka <juraj.kubelka(a)icloud.com> wrote: >> >> Hi Sven, >> >> it does not work for me: >> >> Smalltalk at: #ZnCrPortableWriteStream. âthe class exists" >> >> Gofer it >> smalltalkhubUser: 'SvenVanCaekenberghe' project: 'ZincHTTPComponents'; >> configurationOf: 'ZincHTTPComponents'; >> loadBleedingEdge. >> #ConfigurationOfZincHTTPComponents asClass project latestVersion load: 'WebSocket'. > > bleedingEdge not latestVersion ! > This change is not yet part of a #stable version. > >> Smalltalk at: #ZnCrPortableWriteStream. âthe class does not existsâ >> >> I see that it loads "Zinc-Character-Encoding-Core-SvenVanCaekenberghe.53â. >> >> Any idea why? >> Juraj >> >>> El 20-02-2018, a las 10:26, Sven Van Caekenberghe <sven(a)stfx.eu> escribiÃ³: >>> >>> Load #bleedingEdge I guess. >>> >>> === >>> Name: Zinc-Character-Encoding-Core-SvenVanCaekenberghe.56 >>> Author: SvenVanCaekenberghe >>> Time: 9 February 2018, 4:56:36.697761 pm >>> UUID: 9ef8664f-2b21-0d00-b982-e3af02ff0a5b >>> Ancestors: Zinc-Character-Encoding-Core-SvenVanCaekenberghe.55 >>> >>> Add ZnCharacterReadStream>>#upToAll: >>> Add ZnCrPortableWriteStream >>> === >>> >>>> On 20 Feb 2018, at 14:22, Juraj Kubelka <juraj.kubelka(a)icloud.com> wrote: >>>> >>>> Hi, >>>> >>>> the current Pharo 7.0 image includes ZnCrPortableWriteStream class. >>>> If I do: >>>> >>>> Gofer it >>>> smalltalkhubUser: 'SvenVanCaekenberghe' project: 'ZincHTTPComponents'; >>>> configurationOf: 'ZincHTTPComponents'; >>>> load. >>>> #ConfigurationOfZincHTTPComponents asClass project latestVersion load: 'WebSocket'. >>>> >>>> >>>> in order to load the WebSocket component. The ZnCrPortableWriteStream class disappears and breaks the image as it is referenced for example here: >>>> >>>> <Captura de pantalla 2018-02-20 a la(s) 10.21.07.png> >>>> >>>> How can I load the Zinc components without breaking the Pharo 7.0 image? >>>> >>>> Thanks! >>>> Juraj >>>> >>>> Image version: Pharo-7.0+alpha.build.579.sha.89898444a24ef4fa3ba389f4c9f7efe034012ffe >>> >>> >> >> > >

Feb. 21, 2018

Re: [Pharo-dev] OSSubprocess 0.2.5 fails in Pharo 6.1 64 bits (macOS)

by Eliot Miranda

Hi Alistair, On Wed, Feb 21, 2018 at 9:31 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Yep, OSSubprocess doesn't work on 64 bit VMs at the moment. > > Eliot, Mariano has indicated he's waiting on > https://github.com/pharo-project/pharo-vm/pull/142 > Do you know of a reason why it shouldn't be merged? > Well, the changes to FilePlugin.class belong in VMMaker.oscog. And cfileRecordSize doesn't make sense , since all pointers are of the same size in C: cfileRecordSize + "Return the size of a stdio FILE* handle" + <option: #PharoVM> + <static: false> + ^self sizeof: #'FILE*' I would simple use (self sizeof: #'void *') or (self sizeof: #'FILE *'). Other than that I can't see any problems. > Thanks, > Alistair > > > > On 21 February 2018 at 18:22, phideaux <jcasler(a)cdix.org> wrote: > > When trying the simple example (ls -la /Users) in Pharo 6.1 64bit you > get a > > talkback because > > ExternalAddress integerAt:put:size:signed: fails using > > 'primitiveFFIIntegerAtPut' in module 'SqueakFFIPrims' > > > > Something to do with OSSubprocess not accommodating 64 bit pointers > perhaps? > > > > Same code works fine on 32bit version. > > > > VM is CoInterpreter VMMaker.oscog-eem.2254 Jul 20 2017 for macOS > downloaded > > from pharo.org/downloaded page > > > > Regards, > > Jay+ > > > > > > > > -- > > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837. > html > > > > -- _,,,^..^,,,_ best, Eliot

Feb. 21, 2018

Re: [Pharo-dev] OSSubprocess 0.2.5 fails in Pharo 6.1 64 bits (macOS)

by Alistair Grant

Yep, OSSubprocess doesn't work on 64 bit VMs at the moment. Eliot, Mariano has indicated he's waiting on https://github.com/pharo-project/pharo-vm/pull/142 Do you know of a reason why it shouldn't be merged? Thanks, Alistair On 21 February 2018 at 18:22, phideaux <jcasler(a)cdix.org> wrote: > When trying the simple example (ls -la /Users) in Pharo 6.1 64bit you get a > talkback because > ExternalAddress integerAt:put:size:signed: fails using > 'primitiveFFIIntegerAtPut' in module 'SqueakFFIPrims' > > Something to do with OSSubprocess not accommodating 64 bit pointers perhaps? > > Same code works fine on 32bit version. > > VM is CoInterpreter VMMaker.oscog-eem.2254 Jul 20 2017 for macOS downloaded > from pharo.org/downloaded page > > Regards, > Jay+ > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Feb. 21, 2018

OSSubprocess 0.2.5 fails in Pharo 6.1 64 bits (macOS)

by phideaux

When trying the simple example (ls -la /Users) in Pharo 6.1 64bit you get a talkback because ExternalAddress integerAt:put:size:signed: fails using 'primitiveFFIIntegerAtPut' in module 'SqueakFFIPrims' Something to do with OSSubprocess not accommodating 64 bit pointers perhaps? Same code works fine on 32bit version. VM is CoInterpreter VMMaker.oscog-eem.2254 Jul 20 2017 for macOS downloaded from pharo.org/downloaded page Regards, Jay+ -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Feb. 21, 2018

[Pharo 7.0-dev] Build #588: 21386-Use-better-name-for-Literal-variable-binding-that-is-used-for-MetaLinks

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

There is a new Pharo build available! The status of the build #588 was: FAILURE. The Pull Request #927 was integrated: "21386-Use-better-name-for-Literal-variable-binding-that-is-used-for-MetaLinks" Pull request url: https://github.com/pharo-project/pharo/pull/927 Issue Url: https://pharo.fogbugz.com/f/cases/21386 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 21, 2018

Metacello/Iceberg Error: IceUndefinedRemote DNU #projectPath

by Sean P. DeNigris

I was loading a project via: Metacello new baseline: 'BabyPhexample'; repository: 'github://seandenigris/Baby-Phexample/repository'; onConflict: [ :ex | ex allow ]; load. into a Moose 6.1 image obtained from Launcher which already contained StateSpecs and got this: IceUndefinedRemote(Object)>>doesNotUnderstand: #projectPath IceMetacelloRepositoryAdapter>>projectPath IceMetacelloRepositoryAdapter>>hasNoLoadConflicts: MetacelloRepositorySpec>>hasNoLoadConflicts: MetacelloRepositoriesSpec>>hasNoLoadConflicts: MetacelloMCBaselineOfProjectSpec(MetacelloGenericProjectSpec)>>hasNoLoadConflicts: MetacelloMCBaselineOfProjectSpec(MetacelloMCProjectSpec)>>hasNoLoadConflicts: MetacelloMCBaselineOfProjectSpec(MetacelloProjectSpec)>>hasLoadConflicts: MetacelloMCBaselineOfProjectSpec(MetacelloMCProjectSpec)>>hasConflictWithBaselineSpec: MetacelloMCBaselineOfProjectSpec>>hasConflictWithProjectSpec: MetacelloProjectRegistration>>hasLoadConflicts: Ideas? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Feb. 21, 2018

[Pharo 7.0-dev] Build #587: 21384-Make-non-ensure-wrapped-after-the-default-for-message-sends

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

There is a new Pharo build available! The status of the build #587 was: SUCCESS. The Pull Request #925 was integrated: "21384-Make-non-ensure-wrapped-after-the-default-for-message-sends" Pull request url: https://github.com/pharo-project/pharo/pull/925 Issue Url: https://pharo.fogbugz.com/f/cases/21384 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 21, 2018

[Pharo 7.0-dev] Build #586: 21383-installed-metalinks-should-be-ordered

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

There is a new Pharo build available! The status of the build #586 was: SUCCESS. The Pull Request #924 was integrated: "21383-installed-metalinks-should-be-ordered" Pull request url: https://github.com/pharo-project/pharo/pull/924 Issue Url: https://pharo.fogbugz.com/f/cases/21383 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 21, 2018