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

[Pharo 7.0-dev] Build #595: 19456-after-link-Stack-underflow-with-meta-links-on-message-nodes

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

There is a new Pharo build available! The status of the build #595 was: SUCCESS. The Pull Request #933 was integrated: "19456-after-link-Stack-underflow-with-meta-links-on-message-nodes" Pull request url: https://github.com/pharo-project/pharo/pull/933 Issue Url: https://pharo.fogbugz.com/f/cases/19456 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 22, 2018

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

by Alistair Grant

Hi Eliot, On 21 February 2018 at 18:56, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > 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. Good point. I'm embarrassed to say I didn't look at the code, just the comments. > 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 *'). Yep - although this could use <inline: #always>. > Other than that I can't see any problems. I've sent Mariano a message asking him to clarify what he needs from this PR. I'll follow up again after he replies (I'm keen to see OSSubprocess on the 64 bit VM). Thanks! Alistair >> >> 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. 22, 2018

Re: [Pharo-dev] [Pharo 7.0-dev] Build #594: 21387-Fixing-some-tests-when-turning-on-Read-only-literals

by Marcus Denker

> On 22 Feb 2018, at 14:55, ci-pharo-ci-jenkins2(a)inria.fr wrote: > > There is a new Pharo build available! > > The status of the build #594 was: FAILURE. > > The Pull Request #928 was integrated: "21387-Fixing-some-tests-when-turning-on-Read-only-literals" > Pull request url: https://github.com/pharo-project/pharo/pull/928 > > Issue Url: https://pharo.fogbugz.com/f/cases/21387 > Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… this is the case where we used to get the error that the vm directory already exists. Now it look like this: Downloading the latest pharoVM: http://files.pharo.org/get-files/70/pharo-linux-stable.zip replace pharo-vm/lib/pharo/5.0-201708271955/libssh2.so.1.0.1? [y]es, [n]o, [A]ll, [N]one, [r]ename: new name: replace pharo-vm/M_DIR/vm.zip? [y]es, [n]o, [A]ll, [N]one, [r]ename: error: invalid response [{ENTER}] replace pharo-vm/M_DIR/vm.zip? [y]es, [n]o, [A]ll, [N]one, [r]ename: error: invalid response [if [ "$OS] replace pharo-vm/M_DIR/vm.zip? [y]es, [n]o, [A]ll, [N]one, [r]ename: error: invalid response [" == "win] replace pharo-vm/M_DIR/vm.zip? [y]es, [n]o, [A]ll, [N]one, [r]ename: error: invalid response [" ]; then] replace pharo-vm/M_DIR/vm.zip? [y]es, [n]o, [A]ll, [N]one, [r]ename: error: invalid response [{ENTER}] replace pharo-vm/M_DIR/vm.zip? [y]es, [n]o, [A]ll, [N]one, [r]ename: error: invalid response [ PHARO] replace pharo-vm/M_DIR/vm.zip? [y]es, [n]o, [A]ll, [N]one, [r]ename: error: invalid response [_VM=`find] replace pharo-vm/M_DIR/vm.zip? [y]es, [n]o, [A]ll, [N]one, [r]ename: error: invalid response [ $VM_DIR ] replace pharo-vm/M_DIR/vm.zip? [y]es, [n]o, [A]ll, [N]one, [r]ename: error: invalid response [-name ${V] replace pharo-vm/M_DIR/vm.zip? [y]es, [n]o, [A]ll, [N]one, [r]ename: error: invalid response [M_BINARY_] replace pharo-vm/M_DIR/vm.zip? [y]es, [n]o, [A]ll, [N]one, [r]ename: ++ find bootstrap-cache -name 'Pharo7.0-bootstrap-32bit-*.zip' + IMAGE_ARCHIVE=bootstrap-cache/Pharo7.0-bootstrap-32bit-62fe456.zip + unzip bootstrap-cache/Pharo7.0-bootstrap-32bit-62fe456.zip Archive: bootstrap-cache/Pharo7.0-bootstrap-32bit-62fe456.zip inflating: Pharo7.0-bootstrap-32bit-62fe456.image ++ find . -name Pharo7.0-bootstrap-32bit-62fe456.image + IMAGE_FILE=./Pharo7.0-bootstrap-32bit-62fe456.image ++ find bootstrap-cache -name 'Pharo7.0-hermesPackages-32bit-*.zip' + HERMES_ARCHIVE=bootstrap-cache/Pharo7.0-hermesPackages-32bit-62fe456.zip + unzip bootstrap-cache/Pharo7.0-hermesPackages-32bit-62fe456.zip Archive: bootstrap-cache/Pharo7.0-hermesPackages-32bit-62fe456.zip inflating: OpalCompiler-Core.hermes inflating: CodeExport.hermes inflating: CodeImport.hermes inflating: CodeImportCommandLineHandlers.hermes inflating: SUnit-Core.hermes inflating: JenkinsTools-Core.hermes inflating: SUnit-Tests.hermes inflating: Hermes-Extensions.hermes ++ find bootstrap-cache -name 'Pharo7.0-rpackage-32bit-*.zip' + RPACKAGE_ARCHIVE=bootstrap-cache/Pharo7.0-rpackage-32bit-62fe456.zip + unzip bootstrap-cache/Pharo7.0-rpackage-32bit-62fe456.zip Archive: bootstrap-cache/Pharo7.0-rpackage-32bit-62fe456.zip inflating: protocolsKernel.txt inflating: packagesKernel.txt + mv ./Pharo7.0-bootstrap-32bit-62fe456.image bootstrap.image + export PHARO_CI_TESTING_ENVIRONMENT=1 + PHARO_CI_TESTING_ENVIRONMENT=1 + ./pharo bootstrap.image bootstrap/scripts/runKernelTests.sh: line 34: ./pharo: No such file or directory

Feb. 22, 2018

[Pharo 7.0-dev] Build #594: 21387-Fixing-some-tests-when-turning-on-Read-only-literals

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

There is a new Pharo build available! The status of the build #594 was: FAILURE. The Pull Request #928 was integrated: "21387-Fixing-some-tests-when-turning-on-Read-only-literals" Pull request url: https://github.com/pharo-project/pharo/pull/928 Issue Url: https://pharo.fogbugz.com/f/cases/21387 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 22, 2018

Re: [Pharo-dev] CodeExporter doesn't

by Alistair Grant

On 22 February 2018 at 07:50, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Integrated! Thanks! > On Thu, Feb 22, 2018 at 7:20 AM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: >> Thanks ***a lot*** >> >> On Wed, Feb 21, 2018 at 9:48 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>> Hi Stef, >>> >>> On 21 February 2018 at 21:35, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>>> Hi alistair >>>> >>>> So is this fixed? Because I got bitten by it but no time even to think about it. >>> >>> - PR submitted: https://github.com/pharo-project/pharo/pull/923 >>> - Fogbugz resolved, review needed: >>> https://pharo.fogbugz.com/f/cases/21381/CodeExporter-triggers-errorImproper… >>> - CI passed all tests: >>> https://ci.inria.fr/pharo-ci-jenkins2/blue/organizations/jenkins/Test%20pen… >>> >>> Hopefully someone agrees to merge it in. :-) >>> >>> Cheers, >>> Alistair >>> >>> >>> >>> >>>> 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. 22, 2018

Re: [Pharo-dev] [Pharo 7.0-dev] Build #593: 21390-Do-not-store-any-non-literals-in-the-literal-array

by Marcus Denker

This fixes the Reflectivity compiler to not store normal objects in the literalArrayâ¦ so instead of âpushLiteral:â is now uses âpushLiteralVariable:â. This is needed as we do now have a compiler option to compile methods with read-only literals. Marcus > On 22 Feb 2018, at 11:45, ci-pharo-ci-jenkins2(a)inria.fr wrote: > > There is a new Pharo build available! > > The status of the build #593 was: SUCCESS. > > The Pull Request #932 was integrated: "21390-Do-not-store-any-non-literals-in-the-literal-array" > Pull request url: https://github.com/pharo-project/pharo/pull/932 > > Issue Url: https://pharo.fogbugz.com/f/cases/21390 > Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 22, 2018

Re: [Pharo-dev] #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

by Sven Van Caekenberghe

> On 22 Feb 2018, at 10:41, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > > On Thu, Feb 22, 2018 at 7:52 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Clement > > can you open a bug entry so that we clean this situation? > > > What is the bug? Having two selectors doing the same thing is bad and confuses everybody. So that is a 'bug'. > You want to merge the two selectors and break compatibility with frameworks using the removed one? Either we keep on adding cruft (or leaving cruft in place) in the sake of backwards compatibility or be do something about it. It is not hard to fix a couple of senders. It could be done more softly with a deprecation. Cleanups at the level of Object are particularly valuable. > Stef > > On Mon, Feb 19, 2018 at 12:43 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Hi, > > > > It seems the two methods have exactly the same behavior indeed. > > valueWithPossibleArgs: anArray > > valueWithEnoughArguments: anArray > > > > One was edited recently but I think it's only to change the comment, they're > > both very old. My guess is that there are two for compatibility purpose (One > > is the selector that is considered as the most relevant that should be used, > > the other one is the one also present in other Smalltalks so we have it for > > cross-Smalltalk librairies or something like that), but only one is really > > needed. If you need only the concept for SOM-NS you can just implement one, > > if you want to be compatible with different Smalltalk lib implement both. > > > > All use-cases of these methods I have found do not inject nils, they expect > > the block to have a number of arguments of the block less or equal to the > > number of parameters in the argument array. I would say they're used as > > #cullWithArguments: but for some reason other selector names were preferred. > > > > Now, as you mentioned, these two methods are more than just > > cullWithArguments: since they inject nils if there are not enough > > parameters. To me it looks incorrect to do so because then while debugging > > your code you will get issues due to those injected nils and it will be > > tedious for the application programmer to track the problem down to these > > two methods. > > > > There a few use-cases for nil injection though. Typically when changing > > existing frameworks in multiple repositories, it may be that during the > > update process the change to the caller is installed before the change of > > the callee, and if the code is actually used (code in UI for instance), > > injecting nils might avoid system break-down. Another use-case is for > > compatibility with frameworks using the nil injection, but I can't find a > > framework doing that right now. > > > > Honestly, I would not implement the nil injection, but maybe some one else > > has a different point of view. > > > > On Fri, Feb 16, 2018 at 6:25 PM, Stefan Marr <smalltalk(a)stefan-marr.de> > > wrote: > >> > >> Hi: > >> > >> I am trying to understand the different between and perhaps origin of > >> BlockClosure>>#valueWithPossibleArgs: and > >> BlockClosure>>#valueWithEnoughArguments: > >> > >> I am trying to decide which of the two I need for SOMns. > >> > >> The first one has seen more recent changes, when looking at the Pharo 6.1 > >> download: > >> > >> valueWithPossibleArgs: anArray â> 2/12/2017 StephaneDucasse > >> valueWithEnoughArguments: anArray â> 3/11/2001 nk > >> > >> While they have rather different implementations, they seem to behave > >> identically, as far as I could tell using the following example: > >> > >> blocks := { > >> [ { } ]. > >> [:a | { a } ]. > >> [:a :b | { a. b } ]. > >> [:a :b :c | { a. b. c } ] > >> }. > >> > >> blocks collect: [:b | b valueWithPossibleArgs: {1}]. > >> blocks collect: [:b | b valueWithPossibleArgs: {1. 2. 3}]. > >> blocks collect: [:b | b valueWithEnoughArguments: {1}]. > >> blocks collect: [:b | b valueWithEnoughArguments: {1. 2. 3}]. > >> > >> I was also wondering how they relate to #cull:* > >> > >> One of the major differences seems to be that valueWithP* and valueWithE* > >> are both injecting nil for absent arguments, while normal #value* and #cull* > >> methods signal an error. > >> Is there a specific use case why one wouldnât want to be strict here as > >> well, but instead inject nils? > >> > >> Any comments or pointer appreciated. > >> > >> Thanks > >> Stefan > >> > >> > >> -- > >> Stefan Marr > >> School of Computing, University of Kent > >> http://stefan-marr.de/research/ > >> > >> > >> > > > > > > > > -- > > ClÃ©ment BÃ©ra > > Pharo consortium engineer > > https://clementbera.wordpress.com/ > > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq > > > > > -- > ClÃ©ment BÃ©ra > Pharo consortium engineer > https://clementbera.wordpress.com/ > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq

Feb. 22, 2018

[Pharo 7.0-dev] Build #593: 21390-Do-not-store-any-non-literals-in-the-literal-array

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

There is a new Pharo build available! The status of the build #593 was: SUCCESS. The Pull Request #932 was integrated: "21390-Do-not-store-any-non-literals-in-the-literal-array" Pull request url: https://github.com/pharo-project/pharo/pull/932 Issue Url: https://pharo.fogbugz.com/f/cases/21390 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 22, 2018

[Pharo 7.0-dev] Build #592: 20904-Color--shortPrintString-should-not-use-printString-but-printOn-

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

There is a new Pharo build available! The status of the build #592 was: SUCCESS. The Pull Request #929 was integrated: "20904-Color--shortPrintString-should-not-use-printString-but-printOn-" Pull request url: https://github.com/pharo-project/pharo/pull/929 Issue Url: https://pharo.fogbugz.com/f/cases/20904 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 22, 2018

Re: [Pharo-dev] #valueWithPossibleArgs:, #valueWithEnoughArguments:, and #cull:

by ClÃ©ment Bera

On Thu, Feb 22, 2018 at 7:52 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Clement > > can you open a bug entry so that we clean this situation? > > What is the bug? You want to merge the two selectors and break compatibility with frameworks using the removed one? > Stef > > On Mon, Feb 19, 2018 at 12:43 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> > wrote: > > Hi, > > > > It seems the two methods have exactly the same behavior indeed. > > valueWithPossibleArgs: anArray > > valueWithEnoughArguments: anArray > > > > One was edited recently but I think it's only to change the comment, > they're > > both very old. My guess is that there are two for compatibility purpose > (One > > is the selector that is considered as the most relevant that should be > used, > > the other one is the one also present in other Smalltalks so we have it > for > > cross-Smalltalk librairies or something like that), but only one is > really > > needed. If you need only the concept for SOM-NS you can just implement > one, > > if you want to be compatible with different Smalltalk lib implement both. > > > > All use-cases of these methods I have found do not inject nils, they > expect > > the block to have a number of arguments of the block less or equal to the > > number of parameters in the argument array. I would say they're used as > > #cullWithArguments: but for some reason other selector names were > preferred. > > > > Now, as you mentioned, these two methods are more than just > > cullWithArguments: since they inject nils if there are not enough > > parameters. To me it looks incorrect to do so because then while > debugging > > your code you will get issues due to those injected nils and it will be > > tedious for the application programmer to track the problem down to these > > two methods. > > > > There a few use-cases for nil injection though. Typically when changing > > existing frameworks in multiple repositories, it may be that during the > > update process the change to the caller is installed before the change of > > the callee, and if the code is actually used (code in UI for instance), > > injecting nils might avoid system break-down. Another use-case is for > > compatibility with frameworks using the nil injection, but I can't find a > > framework doing that right now. > > > > Honestly, I would not implement the nil injection, but maybe some one > else > > has a different point of view. > > > > On Fri, Feb 16, 2018 at 6:25 PM, Stefan Marr <smalltalk(a)stefan-marr.de> > > wrote: > >> > >> Hi: > >> > >> I am trying to understand the different between and perhaps origin of > >> BlockClosure>>#valueWithPossibleArgs: and > >> BlockClosure>>#valueWithEnoughArguments: > >> > >> I am trying to decide which of the two I need for SOMns. > >> > >> The first one has seen more recent changes, when looking at the Pharo > 6.1 > >> download: > >> > >> valueWithPossibleArgs: anArray â> 2/12/2017 StephaneDucasse > >> valueWithEnoughArguments: anArray â> 3/11/2001 nk > >> > >> While they have rather different implementations, they seem to behave > >> identically, as far as I could tell using the following example: > >> > >> blocks := { > >> [ { } ]. > >> [:a | { a } ]. > >> [:a :b | { a. b } ]. > >> [:a :b :c | { a. b. c } ] > >> }. > >> > >> blocks collect: [:b | b valueWithPossibleArgs: {1}]. > >> blocks collect: [:b | b valueWithPossibleArgs: {1. 2. 3}]. > >> blocks collect: [:b | b valueWithEnoughArguments: {1}]. > >> blocks collect: [:b | b valueWithEnoughArguments: {1. 2. 3}]. > >> > >> I was also wondering how they relate to #cull:* > >> > >> One of the major differences seems to be that valueWithP* and > valueWithE* > >> are both injecting nil for absent arguments, while normal #value* and > #cull* > >> methods signal an error. > >> Is there a specific use case why one wouldnât want to be strict here as > >> well, but instead inject nils? > >> > >> Any comments or pointer appreciated. > >> > >> Thanks > >> Stefan > >> > >> > >> -- > >> Stefan Marr > >> School of Computing, University of Kent > >> http://stefan-marr.de/research/ > >> > >> > >> > > > > > > > > -- > > ClÃ©ment BÃ©ra > > Pharo consortium engineer > > https://clementbera.wordpress.com/ > > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq > > -- ClÃ©ment BÃ©ra Pharo consortium engineer https://clementbera.wordpress.com/ BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq

Feb. 22, 2018