- Pharo-dev - lists.pharo.org

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

by Stefan Marr

Hi Clement: Thanks for looking into this! > On 19 Feb 2018, at 11:43, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > they're both very old. My guess is that there are two for compatibility purpose Ok, good to know. Thanks. > 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. > [...] > 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. Ok, great. In the end, I only added #cullArguments: instead of the #valueWith* variants [1]. The naming seems to communicate more clearly the expected semantics, and itâs different from the previous ones. So, in case it turns out someone needs those with nil injecting semantics, they could be added later. Thanks Stefan [1] https://github.com/smarr/SOMns/pull/215/files#diff-8dd7efb0aab92cd4b39e0bf8… -- Stefan Marr School of Computing, University of Kent http://stefan-marr.de/research/

Feb. 19, 2018

[Pharo 7.0-dev] Build #577: 20481-all-methods-starting-with-example-should-also-have-a-sampleInstance-annotation

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

There is a new Pharo build available! The status of the build #577 was: SUCCESS. The Pull Request #747 was integrated: "20481-all-methods-starting-with-example-should-also-have-a-sampleInstance-annotation" Pull request url: https://github.com/pharo-project/pharo/pull/747 Issue Url: https://pharo.fogbugz.com/f/cases/20481 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 19, 2018

[Pharo 7.0-dev] Build #576: 21371-Monticello-Tests-is-not-loaded-in-the-bootstraped-image

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

There is a new Pharo build available! The status of the build #576 was: SUCCESS. The Pull Request #915 was integrated: "21371-Monticello-Tests-is-not-loaded-in-the-bootstraped-image" Pull request url: https://github.com/pharo-project/pharo/pull/915 Issue Url: https://pharo.fogbugz.com/f/cases/21371 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 19, 2018

Re: [Pharo-dev] [Pharo 7.0-dev] Build #574: 21226-GLMMorphicText-sents-unknown-secondClock

by Marcus Denker

> On 19 Feb 2018, at 12:23, ci-pharo-ci-jenkins2(a)inria.fr wrote: > > There is a new Pharo build available! > > The status of the build #574 was: FAILURE. > > The Pull Request #912 was integrated: "21226-GLMMorphicText-sents-unknown-secondClock" > Pull request url: https://github.com/pharo-project/pharo/pull/912 > > Issue Url: https://pharo.fogbugz.com/f/cases/21226 > Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… Downloading the latest pharoVM: http://files.pharo.org/get-files/70/pharo-linux-stable.zip mkdir: cannot create directory âpharo-vmâ: File exists I really wonder why it does that *sometimes*, but in most cases it works? => we should do the workaround: https://pharo.fogbugz.com/f/cases/21255/Zeroconf-script-should-re-use-exist… This will not fix the real reason, but I think is would be a good thing in general to make the zeroconf scripts just update existing downloads. Marcus

Feb. 19, 2018

[Pharo 7.0-dev] Build #575: 21292-Remove-unnecessary-self-run-in-RPackageWithDoTest

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

There is a new Pharo build available! The status of the build #575 was: SUCCESS. The Pull Request #911 was integrated: "21292-Remove-unnecessary-self-run-in-RPackageWithDoTest" Pull request url: https://github.com/pharo-project/pharo/pull/911 Issue Url: https://pharo.fogbugz.com/f/cases/21292 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 19, 2018

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

by ClÃ©ment Bera

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

[Pharo 7.0-dev] Build #574: 21226-GLMMorphicText-sents-unknown-secondClock

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

There is a new Pharo build available! The status of the build #574 was: FAILURE. The Pull Request #912 was integrated: "21226-GLMMorphicText-sents-unknown-secondClock" Pull request url: https://github.com/pharo-project/pharo/pull/912 Issue Url: https://pharo.fogbugz.com/f/cases/21226 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 19, 2018

[JOB][Research] 3 Year Advanced Research Position

by Marcus Denker

Inria opended a call for experienced researchers. This is a three year contract, with in total 8 research positions. REQUIREMENTS - Have a French doctorate or an equivalent international degree - Be able to prove at least eight years of research and/or post-doctoral academic or industrial experience; - No age or nationality conditions. - Deadline: April 3rd, 2018 Before writing their research program, the applicants are strongly encouraged to contact the teams or project(s)-teams leaders concerned by their applications. More information on the official website: https://www.inria.fr/en/institute/recruitment/offers/advanced-research-posi… MISSION Join one of our two lines of research: Tools for Software Maintenance or New Programming Language Constructs for Software Evolution. THE REGION Lille is strategically located in Northern Europe with train connections to Paris (1h), London (1h30) and Brussels (30 min.) The Nord Pas de Calais region is a dynamic area in both industry and research for computer science with companies that are european leaders in their branch. Lille, the capital of northern France is an attractive metropolis of over 1 million inhabitants. Cost of living in Lille is lower than that of very big cities such as Paris and London. THE TEAM RMoD is an Inria research project team. It consists of 5 permant researchers (Inria CR and DR, as well as University Assistant Professors) and Engineers, postdocs and students (Master and PhD). RMoD is an international team with more than 20 members from six countries. LINKS: RMoD: http://rmod.lille.inria.fr INRIA Lille: http://www.inria.fr/lille/ INRIA in General: http://www.inria.fr Lille: http://en.wikipedia.org/wiki/Lille http://wikitravel.org/en/Lille Please contact the head of the research team: Stephane.Ducasse(a)inria.fr or one of the following group members: Nicolas.Anquetil(a)inria.fr, Marcus.Denker(a)inria.fr Permanent Link: https://rmod.inria.fr/web/blog/2018-02-17

Feb. 19, 2018

Re: [Pharo-dev] Problem to save packages

by Roca Vincent

Thanks for your help, The problem was indeed I couldn't write in the package-cache. The owner of the folder was root. But I'm surprised because I have already managed to save some packages in it. Anyhow thank you very much. 2018-02-18 22:48 GMT+01:00 Stephan Eggermont <stephan(a)stack.nl>: > Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > These are my files, I want to be in control and manage them by myself. > > Eventually save them on another medium, and not mix them with thousands > of > > other files that generally populate a package-cache. > > Do you see what I mean? > > Two aspects: > 1 It sounds like you have a shared package cache for all your images? That > is somewhat incompatible with the current tooling, especially with regard > to reproducible loading of Metacello configurations. Having lots of > duplicated mcz's in each image's package cache is wasteful > 2 Yes, having much more control over the package cache makes sense, > especially with TelePharo. Different scenario's need different strategies. > Mixing new, own code with loaded frameworks is not very practical > > Stephan > > > > > >

Feb. 19, 2018

Re: [Pharo-dev] Problem to save packages

by VincentRoca

Thanks for your help, The problem was indeed the fact I couldn't write in the package-cache. The owner of the folder was root. But I'm surprised because I have already managed to save some packages in this folder. Anyhow thank you very much ! -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Feb. 19, 2018