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

[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

Re: [Pharo-dev] VirtualMachine vs. Platform and Bootstrap

by Ben Coman

On 19 February 2018 at 17:35, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > On Fri, Feb 16, 2018 at 10:18 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > >> Hi, >> >> 1. We can query for the VIRTUAL MACHINE and ask if it is 32 or 64 bit >> (internally depending on wordSize): >> >> Smalltalk vm is32Bit >> >> Anything OK on that side. >> >> 2. We can also query for the OPERATING SYSTEM we are running on using: >> >> Smalltalk os >> >> and there are subclasses for OSPlatform like Win32Platform, >> Win64Platform as well as Unix32Platform, >> unix64Platform, ... >> >> But when I evaluate "Smalltalk os" in Pharo 7 Build #70552 >> >> 2a) I receive a Win32Platform instance which means 32 bit although >> I'm running on a Win 64 system >> 2b) I receive a Unix32Platform instance which means 32 bit although >> I'm running on a Ubuntu 64 system >> >> I see this as a clear bug and very confusing >> > > Yup. > > >> >> The reason for this behavior is simple: because I run with the 32 bit >> VM/image on these two 64 bit operating >> systems and in Pharo: >> >> for 2a) the#isActivePlatform method ask the VM (???)for the platform >> name (which is Win32 then) >> >> for 2b) the#isActivePlatform method also considers the word size from >> the VM (???) >> >> But to me the "os" should give me infos about the underlying operating >> system and is currently >> returning a wrong instance (because it falls back to querying about the >> running VM, not the real platform) >> > Good point, but to be pedantic I'd say "not the real OS" rather than "not the real platform". Would it be correct to distinguish between OS and Platform? where Platform is your compile target, and OS is where you run the exe ?? Thus the fix would not be just for "Smalltalk os" ==> Win64Platform but to introduce "Smalltalk platform" ==> Win64Platform for 64 bit VM and ==> Win32Platform for 32 bit VM. and "Smalltalk os" ==> something else entirely. or maybe I'm completely off base. cheers -ben > >> This would be easy to fix with some UFFI calls (for instance piping from >> "uname -i" on Unix or "ver" on Windows). >> With UFFI I would also be able to give more and better infos in the >> platform hierarchy about the underlying OS. >> >> But doing this would introduce a dependency from the "Systems-Platforms" >> package to "UFFI" (and currently my >> understanding is that UFFI comes later) >> >> From what I understood from the comment in getPwdViaFFI:with we also >> would like to focus on a minimal dependency >> for bootstrap ... and only depend on FFI and not UFFI. >> > > Well, but that's because the working directory is needed at bootstrap > time. Take into account that the packages that belong to the bootstrap are > those listed in > > BaselineOfPharoBootstrap > > System-Platforms is listed there, but maybe it is not so necessary? We > should check what are the usages of it. > In any case, what I'd say is that "stuff" that is not really needed at > bootstrap time should be loaded afterwards, maybe as a separate package > with extension methods? > And in that case you're free to go and use uFFI, that should be no problem. > > Just take into account that uFFI is loaded by BaselineOfMorphicCore > nowadays. > > >> >> Any comments how we could deal with that best? >> >> Thx >> T. >> >> >> >> >> >> >> > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >

Feb. 19, 2018

Re: [Pharo-dev] VirtualMachine vs. Platform and Bootstrap

by Guillermo Polito

On Fri, Feb 16, 2018 at 10:18 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > 1. We can query for the VIRTUAL MACHINE and ask if it is 32 or 64 bit > (internally depending on wordSize): > > Smalltalk vm is32Bit > > Anything OK on that side. > > 2. We can also query for the OPERATING SYSTEM we are running on using: > > Smalltalk os > > and there are subclasses for OSPlatform like Win32Platform, > Win64Platform as well as Unix32Platform, > unix64Platform, ... > > But when I evaluate "Smalltalk os" in Pharo 7 Build #70552 > > 2a) I receive a Win32Platform instance which means 32 bit although > I'm running on a Win 64 system > 2b) I receive a Unix32Platform instance which means 32 bit although > I'm running on a Ubuntu 64 system > > I see this as a clear bug and very confusing > Yup. > > The reason for this behavior is simple: because I run with the 32 bit > VM/image on these two 64 bit operating > systems and in Pharo: > > for 2a) the#isActivePlatform method ask the VM (???)for the platform > name (which is Win32 then) > > for 2b) the#isActivePlatform method also considers the word size from > the VM (???) > > But to me the "os" should give me infos about the underlying operating > system and is currently > returning a wrong instance (because it falls back to querying about the > running VM, not the real platform) > > This would be easy to fix with some UFFI calls (for instance piping from > "uname -i" on Unix or "ver" on Windows). > With UFFI I would also be able to give more and better infos in the > platform hierarchy about the underlying OS. > > But doing this would introduce a dependency from the "Systems-Platforms" > package to "UFFI" (and currently my > understanding is that UFFI comes later) > > From what I understood from the comment in getPwdViaFFI:with we also would > like to focus on a minimal dependency > for bootstrap ... and only depend on FFI and not UFFI. > Well, but that's because the working directory is needed at bootstrap time. Take into account that the packages that belong to the bootstrap are those listed in BaselineOfPharoBootstrap System-Platforms is listed there, but maybe it is not so necessary? We should check what are the usages of it. In any case, what I'd say is that "stuff" that is not really needed at bootstrap time should be loaded afterwards, maybe as a separate package with extension methods? And in that case you're free to go and use uFFI, that should be no problem. Just take into account that uFFI is loaded by BaselineOfMorphicCore nowadays. > > Any comments how we could deal with that best? > > Thx > T. > > > > > > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Feb. 19, 2018

Re: [Pharo-dev] NeoCSV nil-Handling

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > What do you think ? Could #emptyFieldValue: accept a block instead of the actual value? Or be per-field? Or both? Then the default could still be set via the current mechanism, keeping the usual API simple, but the user would have a bit more control. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Feb. 19, 2018

Re: [Pharo-dev] Problem to save packages

by Stephan Eggermont

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