- Pharo-dev - lists.pharo.org

[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

[Pharo 7.0-dev] Build #591: 21381 CodeExporter triggers errorImproperStore

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

There is a new Pharo build available! The status of the build #591 was: SUCCESS. The Pull Request #923 was integrated: "21381 CodeExporter triggers errorImproperStore" Pull request url: https://github.com/pharo-project/pharo/pull/923 Issue Url: https://pharo.fogbugz.com/f/cases/21381 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 Stephane Ducasse

Clement can you open a bug entry so that we clean this situation? 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

Feb. 22, 2018

Re: [Pharo-dev] CodeExporter doesn't

by Stephane Ducasse

Integrated! 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 #590: 21385-The-dialog-for-Unknown-variable-should-allow-to-leave-the-variable-undefined

by Marcus Denker

> On 21 Feb 2018, at 20:31, ci-pharo-ci-jenkins2(a)inria.fr wrote: > > 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… <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> This adds a new option to the âUnknown Variableâ Dialog for Globals: you can now just let the var be Undefined (so it will be in the Undeclareds dict).

Feb. 22, 2018

Re: [Pharo-dev] CodeExporter doesn't

by Stephane Ducasse

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] CodeExporter doesn't

by Alistair Grant

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. 21, 2018

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