August 2019 - Pharo-dev - lists.pharo.org

[Pharo 8.0] Build #686: 4422-DNU-in-finder-searching-for-print-this-invalid-selector

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

There is a new Pharo build available! The status of the build #686 was: FAILURE. The Pull Request #4444 was integrated: "4422-DNU-in-finder-searching-for-print-this-invalid-selector" Pull request url: https://github.com/pharo-project/pharo/pull/4444 Issue Url: https://github.com/pharo-project/pharo/issues/4422 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 31, 2019

[Pharo 8.0] Build #685: Revert "4401-ZipArchive-should-not-convert-FileReference-to-paths"

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

There is a new Pharo build available! The status of the build #685 was: SUCCESS. The Pull Request #4449 was integrated: "Revert "4401-ZipArchive-should-not-convert-FileReference-to-paths"" Pull request url: https://github.com/pharo-project/pharo/pull/4449 Issue Url: https://github.com/pharo-project/pharo/issues/revert Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 31, 2019

[Pharo 8.0] Build #684: Add refactoring to remove method and the ones in subclasses

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

There is a new Pharo build available! The status of the build #684 was: FAILURE. The Pull Request #4427 was integrated: "Add refactoring to remove method and the ones in subclasses" Pull request url: https://github.com/pharo-project/pharo/pull/4427 Issue Url: https://github.com/pharo-project/pharo/issues/RemoveMethodsInHierarchy Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 30, 2019

[Pharo 8.0] Build #683: 4401-ZipArchive-should-not-convert-FileReference-to-paths

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

There is a new Pharo build available! The status of the build #683 was: FAILURE. The Pull Request #4402 was integrated: "4401-ZipArchive-should-not-convert-FileReference-to-paths" Pull request url: https://github.com/pharo-project/pharo/pull/4402 Issue Url: https://github.com/pharo-project/pharo/issues/4401 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 30, 2019

Re: [Pharo-dev] [Pharo-users] SequenceableCollection>>#allButFirst: inconsistence across subclasses

by Nicolas Cellier

Personnally I sometimes want to break the contracts because I know that I don't need them and can optimize some performance-critical operations. A good example is Fraction. The invariants are: numerator isInteger and: [denominator isInteger and: [ denominator strictlyPositive and: [numerator isZero not and: [(numerator gcd: denominator) = 1]]]] Remark: we can see that there is an order in the invariants, we would not want to test (numerator gcd: denominator) = 1 before knowing they are integer... Normal usage is (Fraction numerator: n denominator: d) reduced, unless sender has the last two invariants in preconditions, in which case it can omit sending reduced. But when parsing Float, we write (Fraction numerator: n denominator: d) asFloat, even if the last invariant does not apply, because asFloat will perform some form of reduction either directly in floating point arithmetic, or via a quo: operation to keep only significand part, and because the last but one invariant is already in pre condition of sender. So a correct specification would be to apply the last two invariant to every Fraction method, but two exceptions: reduced (obviously) and asFloat. That would be a great way to specify the subtle arrangement. Also I was thinking that reduced could be entirely omitted when the contract is known to be fullfilled... That's a great deal of the optimizations that we are performing manually (like Fraction>>#squared etc...) but if a system could find that by induction (given the declarative pre/post contracts) it could probably find many more (I imagine when having type information like in Sista inlining phase). Le ven. 30 aoÃ»t 2019 Ã 15:18, Christopher Fuhrman < christopher.fuhrman(a)etsmtl.ca> a Ã©crit : > Is this not the classic problem solved by design by contract (as in > Eiffel)? Deciding who must check for errors (sender or receiver) and > specifying it formally (the contract) is more important rather than who > SHOULD check. > > I found > http://forum.world.st/Run-time-checking-with-design-by-contract-assertions-… that > mentions a Pharo implementation of the principle. > > On Fri, 30 Aug 2019 at 07:19, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > >> over breakfast Santiago was suggesting that we have >> allButFirst:ifOutOfBounds: >> >> and he said that having an exception is important because you want to >> know if we get data data or not. >> And in that case the client will have to check all the time. >> >> Stef >> >> On 30 Aug 2019, at 11:56, Ben Coman <btc(a)openinworld.com> wrote: >> >> >> >> On Fri, 30 Aug 2019 at 15:34, Julien <julien.delplanque(a)inria.fr> wrote: >> >>> Hello, >>> >>> I opened that issue: https://github.com/pharo-project/pharo/issues/4442 >>> >>> And I think to fix it we need to actually discuss about what we want. >>> >>> #allButFirst: behaves differently depending on the actual type of >>> sequenceable collection when argument is greater than collection size. >>> >>> For instance: >>> >>> #(1 2) allButFirst: 3. "PrimitiveFailed signaled" >>> (LinkedList with: 1 with: 2) allButFirst: 3. "PrimitiveFailed signaled" >>> (OrderedCollection with: 1 with: 2) allButFirst: 3. "an >>> OrderedCollection() Â» >>> >>> The question is then, who is right? >>> >> >> Its worthwhile to at least survey other Smalltalks. >> For Visualworks... >> #(1 2) allButFirst: 3. "==> #()" >> (OrderedCollection with: 1 with: 2) allButFirst: 3. "==> >> OrderedCollection ()" >> (LinkedList with: Link new with: Link new ) allButFirst: 3. >> "raises an error Subscription out of bounds error" >> and also... >> (LinkedList with: Link new with: Link new ) allButFirst: 2. >> "raises an error Subscription out of bounds error" >> >> I feel that proceeding-without-iterating is nicer than >> showing-an-application-error. >> It provides the opportunity to not-check the number elements or wrapping >> error handling around it - i.e. less code if its not important. >> If its important not to exceed the number of elements, then that check >> can be explicitly coded. >> >> cheers -ben >> >> >> -------------------------------------------- >> StÃ©phane Ducasse >> http://stephane.ducasse.free.fr >> http://www.synectique.eu / http://www.pharo.org >> 03 59 35 87 52 >> Assistant: Julie Jonas >> FAX 03 59 57 78 50 >> TEL 03 59 35 86 16 >> S. Ducasse - Inria >> 40, avenue Halley, >> Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza >> Villeneuve d'Ascq 59650 >> France >> >> > > -- > Christopher Fuhrman, P.Eng., PhD > > *Professeur au DÃ©partement de gÃ©nie logiciel et des technologies de > l'informationÃTS (Ãcole de technologie supÃ©rieure)* > > http://profs.etsmtl.ca/cfuhrman > +1 514 396 8638 > *L'ÃTS est une constituante de l'UniversitÃ© du QuÃ©bec* >

Aug. 30, 2019

[Pharo 8.0] Build #682: WeakValueDictionary-return-association-with-collectionElements-instead-of-nil

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

There is a new Pharo build available! The status of the build #682 was: SUCCESS. The Pull Request #4400 was integrated: "WeakValueDictionary-return-association-with-collectionElements-instead-of-nil" Pull request url: https://github.com/pharo-project/pharo/pull/4400 Issue Url: https://github.com/pharo-project/pharo/issues/WeakValueDictionary Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 30, 2019

[Pharo 8.0] Build #681: 4433-Pragmakeyword-should-be-deprecated-via-deprecation-mechanism

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

There is a new Pharo build available! The status of the build #681 was: FAILURE. The Pull Request #4434 was integrated: "4433-Pragmakeyword-should-be-deprecated-via-deprecation-mechanism" Pull request url: https://github.com/pharo-project/pharo/pull/4434 Issue Url: https://github.com/pharo-project/pharo/issues/4433 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 30, 2019

Re: [Pharo-dev] [Pharo-users] SequenceableCollection>>#allButFirst: inconsistence across subclasses

by Christopher Fuhrman

Is this not the classic problem solved by design by contract (as in Eiffel)? Deciding who must check for errors (sender or receiver) and specifying it formally (the contract) is more important rather than who SHOULD check. I found http://forum.world.st/Run-time-checking-with-design-by-contract-assertions-… that mentions a Pharo implementation of the principle. On Fri, 30 Aug 2019 at 07:19, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > over breakfast Santiago was suggesting that we have > allButFirst:ifOutOfBounds: > > and he said that having an exception is important because you want to know > if we get data data or not. > And in that case the client will have to check all the time. > > Stef > > On 30 Aug 2019, at 11:56, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Fri, 30 Aug 2019 at 15:34, Julien <julien.delplanque(a)inria.fr> wrote: > >> Hello, >> >> I opened that issue: https://github.com/pharo-project/pharo/issues/4442 >> >> And I think to fix it we need to actually discuss about what we want. >> >> #allButFirst: behaves differently depending on the actual type of >> sequenceable collection when argument is greater than collection size. >> >> For instance: >> >> #(1 2) allButFirst: 3. "PrimitiveFailed signaled" >> (LinkedList with: 1 with: 2) allButFirst: 3. "PrimitiveFailed signaled" >> (OrderedCollection with: 1 with: 2) allButFirst: 3. "an >> OrderedCollection() Â» >> >> The question is then, who is right? >> > > Its worthwhile to at least survey other Smalltalks. > For Visualworks... > #(1 2) allButFirst: 3. "==> #()" > (OrderedCollection with: 1 with: 2) allButFirst: 3. "==> > OrderedCollection ()" > (LinkedList with: Link new with: Link new ) allButFirst: 3. "raises > an error Subscription out of bounds error" > and also... > (LinkedList with: Link new with: Link new ) allButFirst: 2. "raises > an error Subscription out of bounds error" > > I feel that proceeding-without-iterating is nicer than > showing-an-application-error. > It provides the opportunity to not-check the number elements or wrapping > error handling around it - i.e. less code if its not important. > If its important not to exceed the number of elements, then that check can > be explicitly coded. > > cheers -ben > > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr > http://www.synectique.eu / http://www.pharo.org > 03 59 35 87 52 > Assistant: Julie Jonas > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France > > -- Christopher Fuhrman, P.Eng., PhD *Professeur au DÃ©partement de gÃ©nie logiciel et des technologies de l'informationÃTS (Ãcole de technologie supÃ©rieure)* http://profs.etsmtl.ca/cfuhrman +1 514 396 8638 *L'ÃTS est une constituante de l'UniversitÃ© du QuÃ©bec*

Aug. 30, 2019

CMake StackInterpreter Headless build

by Ben Coman

How can I build the StackInterpreter with the Pharo Headless build? I tried... -DCOG_JIT:BOOL="False" but get the message... [CMake] CMake Warning: Manually-specified variables were not used by the project: COG_JIT The following with the new binary doesn't distinguish it for me... $ build/vm/pharo --version my.image Pharo 8.1.0 built on Aug 30 2019 18:06:20 Compiler: 7.4.0 Built from: acaeef692 - Commit: acaeef692 - Date: 2019-08-28 22:49:49 +0800 Is there anyway to check that a particular binary is a StackInterpreter? Can this be added to "--version" ? Here is the full log... Found cmake executable at /usr/bin/cmake. 1> /usr/bin/cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE="Debug" -DCOG_JIT:BOOL="False" -DCMAKE_INSTALL_PREFIX="/mnt/c/Users/Ben/Source/Repos/opensmalltalk-vm/out/install/WSL-Debug" "/mnt/c/Users/Ben/Source/Repos/opensmalltalk-vm/CMakeLists.txt"; 1> [CMake] -- acaeef692 - Commit: acaeef692 - Date: 2019-08-28 22:49:49 +0800 1> [CMake] -- int 4 1> [CMake] -- long 8 1> [CMake] -- long long 8 1> [CMake] -- void* 8 1> [CMake] -- C Compiler: /usr/bin/cc 1> [CMake] -- C++ Compiler: /usr/bin/c++ 1> [CMake] -- Resource Compiler: 1> [CMake] -- Adding plugin: SecurityPlugin 1> [CMake] -- Adding plugin: FilePlugin 1> [CMake] -- Adding plugin: FileAttributesPlugin 1> [CMake] -- Adding plugin: UUIDPlugin 1> [CMake] -- Adding plugin: SocketPlugin 1> [CMake] -- Adding plugin: SurfacePlugin 1> [CMake] -- Adding plugin: LargeIntegers 1> [CMake] -- Adding plugin: JPEGReaderPlugin 1> [CMake] -- Adding plugin: JPEGReadWriter2Plugin 1> [CMake] -- Adding plugin: MiscPrimitivePlugin 1> [CMake] -- Adding plugin: B2DPlugin 1> [CMake] -- Adding plugin: LocalePlugin 1> [CMake] -- Adding plugin: SqueakSSL 1> [CMake] -- Adding plugin: DSAPrims 1> [CMake] -- Adding plugin: UnixOSProcessPlugin 1> [CMake] Adding third-party libraries for linux: pthreadedPlugin-0.0.1 1> [CMake] Adding third-party libraries for linux: libffi-3.3-rc0 1> [CMake] Adding third-party libraries for linux: libgit2-0.25.1 1> [CMake] Adding third-party libraries for linux: libssh2-1.7.0 1> [CMake] Adding third-party libraries for linux: openssl-1.0.2q 1> [CMake] Adding third-party libraries for linux: SDL2-2.0.7 1> [CMake] -- Configuring done 1> [CMake] -- Generating done 1> [CMake] CMake Warning: 1> [CMake] Manually-specified variables were not used by the project: 1> [CMake] COG_JIT 1> [CMake] -- Build files have been written to: /mnt/c/Users/Ben/Source/Repos/opensmalltalk-vm/out/build/WSL-Debug 1> Starting CMake target info extraction ... 1> CMake server connection made. 1> Extracted includes paths. 1> Extracted CMake variables. 1> Extracted source files and headers. 1> Extracted global settings. 1> Extracted code model. 1> Collating data ... 1> Warning: CMake 3.11 or newer is required for install target integration 1> Target info extraction done. 1> CMake generation finished. cheers -ben P.S. btw, the -DCOG_JIT:BOOL="False" comes from first trying-the-simplest-thing of unticking "COG_JIT" in this Visual Studio configuration dialog... [image: image.png]

Aug. 30, 2019

Re: [Pharo-dev] [Pharo-users] SequenceableCollection>>#allButFirst: inconsistence across subclasses

by Cyril Ferlicot

On Fri 30 Aug 2019 at 09:34, Julien <julien.delplanque(a)inria.fr> wrote: > Hello, > > I opened that issue: https://github.com/pharo-project/pharo/issues/4442 > > And I think to fix it we need to actually discuss about what we want. > > #allButFirst: behaves differently depending on the actual type of > sequenceable collection when argument is greater than collection size. > > For instance: > > #(1 2) allButFirst: 3. "PrimitiveFailed signaled" > (LinkedList with: 1 with: 2) allButFirst: 3. "PrimitiveFailed signaled" > (OrderedCollection with: 1 with: 2) allButFirst: 3. "an > OrderedCollection() Â» > > The question is then, who is right? > > Should #allButFirst: with an argument greater than the collection size > raise an error > > Or > > Should #allButFirst: with an argument greater than the collection size > returns an empty collection ? > > I asked a few people about it @ ESUG and it appears that the expected > behaviour from #allButFirst: is not the same to all people. > > We need to decide so we improve consistence of collections. > > And then, we need to document that with a test :-). > Hi, I was one of the person who discussed this with Julien at ESUG and IMO it should launch an error. While working on complexe models, errors in such cases are really really really helpful to find bugs. Errors such as SubscriptOutOfBound or NotFound help me a lot to find bugs and sometimes without this kind of methods it could have take me days to find the problem (and itâs only in the case I know there is a bug). > Cheers. > > Julien > > --- > Julien Delplanque > Doctorant Ã lâUniversitÃ© de Lille > http://juliendelplanque.be/phd.html > Equipe Rmod, Inria > BÃ¢timent B 40, Avenue Halley 59650 > <https://www.google.com/maps/search/40,+Avenue+Halley+59650+Villeneuve+d'Ascq?entry=gmail&source=g> > Villeneuve > <https://www.google.com/maps/search/40,+Avenue+Halley+59650+Villeneuve+d'Ascq?entry=gmail&source=g> > d'Ascq > <https://www.google.com/maps/search/40,+Avenue+Halley+59650+Villeneuve+d'Ascq?entry=gmail&source=g> > NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 > > -- Cyril Ferlicot https://ferlicot.fr

Aug. 30, 2019