- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] TechTalk Feb18: Recording is online

by Stephane Ducasse

+1 On Tue, Feb 20, 2018 at 5:20 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Marcus Denker-4 wrote >> I added links to the video on all these pages: > > Thanks for your dedication to all these mostly-invisible, but essential > infrastructure tasks, Marcus!!!! > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Feb. 21, 2018

Re: [Pharo-dev] [ANN] Pharo Sprint Feb 23

by Stephane Ducasse

I would really like to see the debugger over problem to be fixed. This is super annoying. How to reproduce: it seems that do a step over and get something breaking inside. Stef On Wed, Feb 21, 2018 at 11:33 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > As a starting point, I put the sprint tag on some cases (which should be easy to do): > > https://pharo.fogbugz.com/f/filters/44/Sprint > > >> On 20 Feb 2018, at 08:44, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> Pharo Sprint Feb 23 >> https://association.pharo.org/event-2789568 >> >> >> For a list of all future Pharo Event, have a look at: https://association.pharo.org/events >> (you can get iCal entries and subsribe to an event specific mailinglist bu registering) >> >> Marcus > >

Feb. 21, 2018

Re: [Pharo-dev] CodeExporter doesn't

by Stephane Ducasse

Hi alistair So is this fixed? Because I got bitten by it but no time even to think about it. Stef On Wed, Feb 21, 2018 at 12:37 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > On 21 February 2018 at 11:43, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> Hi Everyone, >> >> Attempting to file out changes from the Change Sorter results in an >> 'Improper store into indexable object'. (To reproduce this, right click >> on any change set and choose "File out"). >> >> I believe the root cause of the problem is: >> >> CodeExporter class>>writeSourceCodeFrom: aStream toFileReference: aFileReference >> >> aFileReference writeStreamDo: [ :outputStream | >> (ZnCrPortableWriteStream on: (ZnCharacterWriteStream >> on: outputStream >> encoding: 'utf8')) nextPutAll: aStream contents. >> ]. >> >> self inform: 'Filed out to: ', String cr, aFileReference basename >> >> >> ZnCrPortableWriteStream expects a binary stream and is being given a >> multi-byte file stream. >> >> The obvious solution is to add FileReference>>binaryWriteStreamDo: and >> associated methods. >> >> Can someone who is more familiar with the Zinc package confirm that my >> understanding is correct? >> >> Fogbugz: https://pharo.fogbugz.com/f/cases/21381/CodeExporter-triggers-errorImproper… > > And if I'd bothered to read the class comments before posting, I > wouldn't have wasted everyone's time. > > Using a binary write stream is the answer, according to the class comments. > > > Sorry, > Alistair >

Feb. 21, 2018

[Pharo 7.0-dev] Build #590: 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 #590 was: SUCCESS. 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

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