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

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

by StÃ©phane Ducasse

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 <mailto:julien.delplanque@inria.fr>> wrote: > Hello, > > I opened that issue: https://github.com/pharo-project/pharo/issues/4442 <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

Aug. 30, 2019

Pharo topics for internships in Canada [Deadline for submission mid sept]

by StÃ©phane Ducasse

Hello We would like to draw your attention that there are a couple of internships position for interns in Canada for May 2020. https://globalink.mitacs.ca/#/student/application/projects put Petrillo as Professor last name and Chicoumiti as University. Stef -------------------------------------------- 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

Aug. 30, 2019

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

by Ben Coman

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

Aug. 30, 2019

[Pharo 8.0] Build #680: 4435-Cannot-browse-trait-in-class-description

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

There is a new Pharo build available! The status of the build #680 was: FAILURE. The Pull Request #4438 was integrated: "4435-Cannot-browse-trait-in-class-description" Pull request url: https://github.com/pharo-project/pharo/pull/4438 Issue Url: https://github.com/pharo-project/pharo/issues/4435 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 30, 2019

SequenceableCollection>>#allButFirst: inconsistence across subclasses

by Julien

Hello, I opened that issue: https://github.com/pharo-project/pharo/issues/4442 <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 :-). Cheers. Julien --- Julien Delplanque Doctorant Ã lâUniversitÃ© de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria BÃ¢timent B 40, Avenue Halley 59650 Villeneuve d'Ascq NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40

Aug. 30, 2019

[Pharo 8.0] Build #679: 4439-Epicea-Should-FileOut-to-Image-Directory

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

There is a new Pharo build available! The status of the build #679 was: SUCCESS. The Pull Request #4440 was integrated: "4439-Epicea-Should-FileOut-to-Image-Directory" Pull request url: https://github.com/pharo-project/pharo/pull/4440 Issue Url: https://github.com/pharo-project/pharo/issues/4439 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 29, 2019

[Pharo 8.0] Build #678: 4258-AbsolutePath-withParents-on-root---on-linux---return-2-root-path

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

There is a new Pharo build available! The status of the build #678 was: FAILURE. The Pull Request #4408 was integrated: "4258-AbsolutePath-withParents-on-root---on-linux---return-2-root-path" Pull request url: https://github.com/pharo-project/pharo/pull/4408 Issue Url: https://github.com/pharo-project/pharo/issues/4258 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 29, 2019

Re: [Pharo-dev] possible Windows Update "1903" Iceberg problem

by ducasse

tx doru Stef > On 28 Aug 2019, at 16:01, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi > > I opened an issue: https://github.com/pharo-project/pharo/issues/4437 > > I believe this should be treated as critical given that we cannot load code in Pharo 7 (or 8) which makes it almost useless for users. > > Cheers, > Doru > > >> On Aug 27, 2019, at 10:54 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >> We just encountered this on two different machines. We got this after the update to Windows 1903. For us itâs a critical issue at this point. What can we do to help with this? >> >> Cheers, >> Doru >> >> >> >>> On Aug 17, 2019, at 12:50 PM, Ben Coman <btc(a)openInWorld.com> wrote: >>> >>> hi Stef, >>> I feel you missed my point. Probably I wasn't clear this has already been tested with latest Pharo 8 launched by PharoLauncher. >>> The problem occurs with Pharo 7.0.3(64 bit) and with Pharo8.0-SNAPSHOT-build.635(64 bit) >>> after Microsoft Windows Update 1903... >>> https://www.computerworld.com/article/3409621/microsoft-starts-windows-10s-… >>> >>> If indeed 1903 is the cause, with this update now being *forced* down on people, this will potentially soon impact more and more Windows users. >>> But my guess that 1903 is the culprit needs to be confirmed. >>> So I am requesting someone with access to multiple Windows machines directly compare a 1903 machine with a pre-1903 machine. >>> >>> cheers -ben >>> >>> On Sat, 17 Aug 2019 at 12:58, ducasse <stepharo(a)netcourrier.com> wrote: >>> Hi ben >>> >>> in the pharo launcher if you click on P8.0 (development version) you get access to all the builds. >>> >>> Stef >>> >>>> On 16 Aug 2019, at 16:02, Ben Coman <btc(a)openinworld.com> wrote: >>>> >>>> IThis morning the May 2019 Windows Update "1903" forced itself onto my computer and now 64-bits Pharo seems to have a problem with git_remote_fetch() FFI callout. I no longer have a non-1903 machine to directly compare behaviour before "1903". Can someone familiar with this area with both "pre-1903" and "1903" machines triage whether "1903" is indeed the cause? >>>> >>>> A few other recent reports are noted here... >>>> https://github.com/pharo-project/pharo/issues/3418 >>>> >>>> cheers -ben >>> >> >> -- >> feenk.com >> >> "Not knowing how to do something is not an argument for how it cannot be done." >> > > -- > feenk.com > > âLive like you mean it." > >

Aug. 28, 2019

Re: [Pharo-dev] possible Windows Update "1903" Iceberg problem

by Tudor Girba

Hi I opened an issue: https://github.com/pharo-project/pharo/issues/4437 I believe this should be treated as critical given that we cannot load code in Pharo 7 (or 8) which makes it almost useless for users. Cheers, Doru > On Aug 27, 2019, at 10:54 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > We just encountered this on two different machines. We got this after the update to Windows 1903. For us itâs a critical issue at this point. What can we do to help with this? > > Cheers, > Doru > > > >> On Aug 17, 2019, at 12:50 PM, Ben Coman <btc(a)openInWorld.com> wrote: >> >> hi Stef, >> I feel you missed my point. Probably I wasn't clear this has already been tested with latest Pharo 8 launched by PharoLauncher. >> The problem occurs with Pharo 7.0.3(64 bit) and with Pharo8.0-SNAPSHOT-build.635(64 bit) >> after Microsoft Windows Update 1903... >> https://www.computerworld.com/article/3409621/microsoft-starts-windows-10s-… >> >> If indeed 1903 is the cause, with this update now being *forced* down on people, this will potentially soon impact more and more Windows users. >> But my guess that 1903 is the culprit needs to be confirmed. >> So I am requesting someone with access to multiple Windows machines directly compare a 1903 machine with a pre-1903 machine. >> >> cheers -ben >> >> On Sat, 17 Aug 2019 at 12:58, ducasse <stepharo(a)netcourrier.com> wrote: >> Hi ben >> >> in the pharo launcher if you click on P8.0 (development version) you get access to all the builds. >> >> Stef >> >>> On 16 Aug 2019, at 16:02, Ben Coman <btc(a)openinworld.com> wrote: >>> >>> IThis morning the May 2019 Windows Update "1903" forced itself onto my computer and now 64-bits Pharo seems to have a problem with git_remote_fetch() FFI callout. I no longer have a non-1903 machine to directly compare behaviour before "1903". Can someone familiar with this area with both "pre-1903" and "1903" machines triage whether "1903" is indeed the cause? >>> >>> A few other recent reports are noted here... >>> https://github.com/pharo-project/pharo/issues/3418 >>> >>> cheers -ben >> > > -- > feenk.com > > "Not knowing how to do something is not an argument for how it cannot be done." > -- feenk.com âLive like you mean it."

Aug. 28, 2019

Debugging Pharo-Headless-Linux-VM using Visual Studio running on Windows

by Ben Coman

Guille's procrastination experiments inspired me to procrastination of my own, with an experiment around debugging Pharo-Headless-Linux-VM using Visual Studio running on Windows. I've refined the steps-from-scratch to reproduce down to the following... Overview... 1. Install Windows Subsystem from Linux 2. Install Visual Studio 2019 3. Build and run hello-world exercise inside WSL 4. Build and run Pharo-Headless-VM inside WSL Now lets get started... ############################### Install Windows Subsystem from Linux ############################### 1A. On a Windows 10 box, go to the Windows App Store and Ubuntu 18.04... Ref: https://docs.microsoft.com/en-us/windows/wsl/install-win10 1B. Ensure this configured as the default (otherwise later the $defaultWSLPath variable doesn't work and you may see a Visual Studio error "Could not open windows subsystem shell")... C:\Users\Ben>wslconfig /l Windows Subsystem for Linux Distributions: Legacy (Default) kali-linux Ubuntu-18.04 Ubuntu-16.04 C:\Users\Ben>wslconfig /setdefault Ubuntu-18.04 C:\Users\Ben>wslconfig /l Windows Subsystem for Linux Distributions: Ubuntu-18.04 (Default) Legacy kali-linux Ubuntu-16.04 Ref: https://www.howtogeek.com/344688/how-to-set-your-default-linux-distribution… btw, my Windows 10 box recently upgrade to latest version. C:\Users\Ben> ver Microsoft Windows [Version 10.0.18362.295] 1C. Start Ubuntu-18.04, then update/upgrade/install pre-requisites... ``` sudo apt-get update sudo apt-get upgrade sudo apt-get install clang gcc gdb make rsync zip # Visual Studio requirement sudo apt-get install uuid-dev # Pharo VM build requirement ``` While that is running... #################### Install Visual Studio 2019 #################### 2A. Download and run the installer for Visual Studio Community 2019 (not Visual Studio Code) Ref: https://visualstudio.microsoft.com/free-developer-offers/ 2B. When the "Visual Studio Installer" opens, under its "Workloads" tab, select "Linux development with C++" and click **Install**. Ref: https://docs.microsoft.com/en-us/cpp/linux/download-install-and-setup-the-l… ##################################### Build and run hello-world exercise inside WSL ##################################### 3A. Start Visual Studio 2019 and at its opening window, under "Get started" click "Create a new project". Then scroll down and choose "CMake Project" and <Next>. and configure... Project name: hello-world then click <Create>. Ref: https://docs.microsoft.com/en-us/cpp/linux/cmake-linux-project?view=vs-2019 Now it may immediately start the CMake build and get an error because its using the default "x64-Debug" configuration. Ignore that, we will create a new configuration to build on Windows Subsystem for Linux. 3B. From the "Configuration drop-down" (where you see "x64-Debug") select "Manage Configurations..." Delete "x64-Debug". Add... "WSL-Debug" and use all defaults then press <CTRL-S> to save. Inside WSL, Cmake will start generating the makefiles. At some point you might see "Supported CMake version is not present on WSL. Install CMake binaries built by Microsoft?" YES, do that. 3C. After "CMake generation finished", pull down "Select Startup Item" and select "hello-world" then press the green PLAY button. Inside WSL, the make build will start and after its done the pharo executable will run there. In the [Output] tab, it was successful if you see "The thread 'hello-world' (0x1f7a) has exited with code 0" . 3D. For proof that its running inside WSL, lets write a file! In the "Solution Explorer" tab, browse to "hello-world.cpp" and change its contents to... ``` #include <stdio.h> int main() { FILE* fp; int i; /* open the file for writing*/ fp = fopen("/tmp/built-by-visual-studio", "w"); fprintf(fp, "It worked.\n"); fclose(fp); return 0; } ``` then press the green PLAY button. After you see "thread 'hello-world' has exited with code 0" open a WSL shell and run... $ cat /tmp/built-by-visual-studio It worked 3E. To experience debugging Linux from Visual Studio, first remove the test file... $ rm /tmp/built-by-visual-studio then put a breakpoint on "fopen" and click the PLAY button. Check if the file is there... $ cat /tmp/built-by-visual-studio cat: /tmp/built-by-visual-studio: No such file or directory <STEP OVER> fopen $ cat /tmp/built-by-visual-studio <STEP OVER> fprintf $ cat /tmp/built-by-visual-studio <STEP OVER> fclose $ cat /tmp/built-by-visual-studio It worked 3F. All done... File > Close Folder ##################################### Build and run Pharo-Headless-VM inside WSL ##################################### 4A. From Visual Studio 2019 opening window, under "Get started" click "Clone or check out code" Repository location: https://github.com/bencoman/opensmalltalk-vm.git then click <Clone>. https://docs.microsoft.com/en-us/visualstudio/get-started/tutorial-open-pro… 4B. In the bottom-right status bar, click the "branching" icon and choose "Manage Branches". Expand "remotes/origin", then right-click "headless-WSL-VisualStudio" and "Checkout" A fixed "WSL-Debug" configuration is a part of this branch, so its CMake-build should auto-start and complete successfully. 4C. After "CMake generation finished", pull down "Select Startup Item" and select "pharo (build/vm/pharo)" then press the green PLAY button. Don't worry if it sits for a long time on "BalloonEnginePlugin>>primitiveAddRect" The [Error List] tab pops up with 116 Warnings. Switching back to the [Output] tab, you hopefully see "thread 'pharo' (0x4d0d) has exited with code 0" So the VM just built and ran headless under Windows Subsystem for Linux. Now lets debug that from Visual Studio. 4D. Browse to src/main.c and put a breakpoint in main() on the call to parseArguments() Then click the PLAY button. Once stopped at the breakpoint, <STEP INTO>. In the [Autos] tab, expand the "parameters" variable. Observe "imageFile" is empty. Notice "imageFile" becomes "Pharo.image" after <STEP OVER> splitVMAndImageParameters(). So now I leave you to play. I'd be interested in hearing about people's experiences. Placing the correct PharoHeadless.image in the right place to actually run the image is left as an exercise for the reader. cheers -ben

Aug. 28, 2019

[Pharo 8.0] Build #677: [CI CLEANING] Fixing current test failures

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

There is a new Pharo build available! The status of the build #677 was: SUCCESS. The Pull Request #4436 was integrated: "[CI CLEANING] Fixing current test failures" Pull request url: https://github.com/pharo-project/pharo/pull/4436 Issue Url: https://github.com/pharo-project/pharo/issues/fixingCurrentTestFailures Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 28, 2019

Re: [Pharo-dev] possible Windows Update "1903" Iceberg problem

by Tudor Girba

Hi, We just encountered this on two different machines. We got this after the update to Windows 1903. For us itâs a critical issue at this point. What can we do to help with this? Cheers, Doru > On Aug 17, 2019, at 12:50 PM, Ben Coman <btc(a)openInWorld.com> wrote: > > hi Stef, > I feel you missed my point. Probably I wasn't clear this has already been tested with latest Pharo 8 launched by PharoLauncher. > The problem occurs with Pharo 7.0.3(64 bit) and with Pharo8.0-SNAPSHOT-build.635(64 bit) > after Microsoft Windows Update 1903... > https://www.computerworld.com/article/3409621/microsoft-starts-windows-10s-… > > If indeed 1903 is the cause, with this update now being *forced* down on people, this will potentially soon impact more and more Windows users. > But my guess that 1903 is the culprit needs to be confirmed. > So I am requesting someone with access to multiple Windows machines directly compare a 1903 machine with a pre-1903 machine. > > cheers -ben > > On Sat, 17 Aug 2019 at 12:58, ducasse <stepharo(a)netcourrier.com> wrote: > Hi ben > > in the pharo launcher if you click on P8.0 (development version) you get access to all the builds. > > Stef > >> On 16 Aug 2019, at 16:02, Ben Coman <btc(a)openinworld.com> wrote: >> >> IThis morning the May 2019 Windows Update "1903" forced itself onto my computer and now 64-bits Pharo seems to have a problem with git_remote_fetch() FFI callout. I no longer have a non-1903 machine to directly compare behaviour before "1903". Can someone familiar with this area with both "pre-1903" and "1903" machines triage whether "1903" is indeed the cause? >> >> A few other recent reports are noted here... >> https://github.com/pharo-project/pharo/issues/3418 >> >> cheers -ben > -- feenk.com "Not knowing how to do something is not an argument for how it cannot be done."

Aug. 27, 2019

Re: [Pharo-dev] [Weekend Procastination] what the new minheadless opens as posibilities :D

by Guillermo Polito

> El 26 ago 2019, a las 14:08, ducasse <stepharo(a)netcourrier.com> escribiÃ³: > > Hi guille > >> Procastination 1: Render the world fully in athens (instead of a middling bitmap) to have an idea of the effort to get fast to hdpi >> <PastedGraphic-5.png> >> What you see here is a world drawn completely in athens in minheadless, where in red are the invalidated rectangles in the screen (Iâm using to debug a bit). >> Icons are broken because I broke them while playing, not because they do not work in athens :P. >> There is still work to do if we want to explore this direction. Mainly performance issues to make it at least usable, so it can be iterated easily. >> We have seen with Pablo that a lot of time is taken in the transformation of morphic/pharo form/bitmaps to athens ones, since they do not have the same format and right now it is done with a bit-per-bit copy. > > I do not get it. You are saying that it is slow while I have the impression that if we remove the bit-per-bit copy we should get faster. There are two different things in here :). First, in morphic we have bitmaps and forms representing for example icons and images. Those forms/bitmaps are stored in a format that is not cairo compatible, so every time we need to render an icon a super expensive transformation takes place. The other day we worked with Pablo in some caching of those transformations and it improves indeed a lot. Still we have to see if it makes sense to add those caches (where to put them how to invalidate them, are they shared or notâ¦), or if we change the internal representation of forms, or what :). Second, right now minheadless is drawing the morphic world into a form and then the form is copied (literally blitted usin bitblt) into the cairo context/sdl texture. What this first experiment is about is to render directly on the sdl texture without the extra copy. I donât think is will be necessary faster as this is just avoiding a couple of copies (blits) but the athens morphic renderer is far less optimized than the historical oneâ¦ The question to me is: can this be **as fast as the bitblt one** yet render better in hdpi?

Aug. 26, 2019

[MorphicUIManager] strange method onEventSensorStartup:

by ClÃ©ment Dutriez

Hello, I working on the first step of the migration of the UIManager. ```Smalltalk onEventSensorStartup: anEventSensor anEventSensor flushAllButDandDEvents ``` the problem is that the only class defining 'flushAllButDandDEvents' method do nothing. It's normal? what is the responsibility of this method? Thanks -- Dutriez ClÃ©ment dutriezcle(a)gmail.com 0605199489 [image: www.linkedin.com/in/clÃ©ment-dutriez-407275173] <http://www.linkedin.com/in/clÃ©ment-dutriez-407275173>

Aug. 26, 2019

[Pharo 8.0] Build #676: Add missing find and replace refactoring

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

There is a new Pharo build available! The status of the build #676 was: FAILURE. The Pull Request #4430 was integrated: "Add missing find and replace refactoring" Pull request url: https://github.com/pharo-project/pharo/pull/4430 Issue Url: https://github.com/pharo-project/pharo/issues/FindAndReplace Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 26, 2019

[Pharo 8.0] Build #675: Add undo refactoring option

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

There is a new Pharo build available! The status of the build #675 was: SUCCESS. The Pull Request #4426 was integrated: "Add undo refactoring option" Pull request url: https://github.com/pharo-project/pharo/pull/4426 Issue Url: https://github.com/pharo-project/pharo/issues/UndoRefactoring Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 26, 2019

Re: [Pharo-dev] [Weekend Procastination] what the new minheadless opens as posibilities :D

by ducasse

> On 26 Aug 2019, at 13:16, Ben Coman <btc(a)openinworld.com> wrote: > > Thanks for sharing Guille. > > Now what I was wondering is what possibilities minheadless opens up for running on IOS and Android tablets and phones. > IIUC one of the impediments was not being native-event-driven. Is the VM event handling now factored out to the degree necessary > to drive it from native-events, Not yet from pablo and esteban told me. > or what more work is required there? I do not know but I know that some work is needed. But this is in our roadmap. > On Mon, 26 Aug 2019 at 16:43, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: > Hi all, > > Over the weekend, instead of working on my ESUG presentations I procastinated a bit with some experiments that I would like to share ^^. > > Procastination 1: Render the world fully in athens (instead of a middling bitmap) to have an idea of the effort to get fast to hdpi > > What you see here is a world drawn completely in athens in minheadless, where in red are the invalidated rectangles in the screen (Iâm using to debug a bit). > Icons are broken because I broke them while playing, not because they do not work in athens :P. > There is still work to do if we want to explore this direction. Mainly performance issues to make it at least usable, so it can be iterated easily. > We have seen with Pablo that a lot of time is taken in the transformation of morphic/pharo form/bitmaps to athens ones, since they do not have the same format and right now it is done with a bit-per-bit copy. > > > Procastination 2: poping out morphs out of the world > > What you see here is that I can have different os windows with different worlds, giving a multi-window experience :). > There is also work to do in this direction if we want to push it: > - morphic support for multiple worlds/windows is not so good... > - the usage of the current world needs to be reviewed. The world has two distinct responsibilities right now > 1) it is the manager of the hands (required for drag n drop) > 2) it is the main container/pasteup for other morphs > > Imagine in the short term a Morphic Spec app can use a âexternal window rendering on athensâ strategy that mixes the two things above and each new window is popped up as a new window. :D > > For those @ESUG, Iâll be arriving this evening, Iâm going to show this in the show us your projects, and if you want to help, please contact me, you can learn a lot and its super fun :) > > cheers -ben > <PastedGraphic-4.png><PastedGraphic-5.png>

Aug. 26, 2019

Re: [Pharo-dev] [Weekend Procastination] what the new minheadless opens as posibilities :D

by Esteban Lorenzano

> On 26 Aug 2019, at 13:16, Ben Coman <btc(a)openinworld.com> wrote: > > Thanks for sharing Guille. > > Now what I was wondering is what possibilities minheadless opens up for running on IOS and Android tablets and phones. > IIUC one of the impediments was not being native-event-driven. Is the VM event handling now factored out to the degree necessary > to drive it from native-events, or what more work is required there? To be competitive in the mobile world, we need an idle vm. While moving the responsibility of showing the world to the image (and with that, removing the need of a UI cycle) is something needed, we still need to eliminate the heartbeat. And that is an effort of proportions. Esteban > > > On Mon, 26 Aug 2019 at 16:43, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: > Hi all, > > Over the weekend, instead of working on my ESUG presentations I procastinated a bit with some experiments that I would like to share ^^. > > Procastination 1: Render the world fully in athens (instead of a middling bitmap) to have an idea of the effort to get fast to hdpi > > What you see here is a world drawn completely in athens in minheadless, where in red are the invalidated rectangles in the screen (Iâm using to debug a bit). > Icons are broken because I broke them while playing, not because they do not work in athens :P. > There is still work to do if we want to explore this direction. Mainly performance issues to make it at least usable, so it can be iterated easily. > We have seen with Pablo that a lot of time is taken in the transformation of morphic/pharo form/bitmaps to athens ones, since they do not have the same format and right now it is done with a bit-per-bit copy. > > > Procastination 2: poping out morphs out of the world > > What you see here is that I can have different os windows with different worlds, giving a multi-window experience :). > There is also work to do in this direction if we want to push it: > - morphic support for multiple worlds/windows is not so good... > - the usage of the current world needs to be reviewed. The world has two distinct responsibilities right now > 1) it is the manager of the hands (required for drag n drop) > 2) it is the main container/pasteup for other morphs > > Imagine in the short term a Morphic Spec app can use a âexternal window rendering on athensâ strategy that mixes the two things above and each new window is popped up as a new window. :D > > For those @ESUG, Iâll be arriving this evening, Iâm going to show this in the show us your projects, and if you want to help, please contact me, you can learn a lot and its super fun :) > > cheers -ben > <PastedGraphic-4.png><PastedGraphic-5.png>

Aug. 26, 2019

Re: [Pharo-dev] [Weekend Procastination] what the new minheadless opens as posibilities :D

by ducasse

Hi guille > Procastination 1: Render the world fully in athens (instead of a middling bitmap) to have an idea of the effort to get fast to hdpi > <PastedGraphic-5.png> > What you see here is a world drawn completely in athens in minheadless, where in red are the invalidated rectangles in the screen (Iâm using to debug a bit). > Icons are broken because I broke them while playing, not because they do not work in athens :P. > There is still work to do if we want to explore this direction. Mainly performance issues to make it at least usable, so it can be iterated easily. > We have seen with Pablo that a lot of time is taken in the transformation of morphic/pharo form/bitmaps to athens ones, since they do not have the same format and right now it is done with a bit-per-bit copy. I do not get it. You are saying that it is slow while I have the impression that if we remove the bit-per-bit copy we should get faster. > > > Procastination 2: poping out morphs out of the world > > <PastedGraphic-4.png> > > What you see here is that I can have different os windows with different worlds, giving a multi-window experience :). > There is also work to do in this direction if we want to push it: > - morphic support for multiple worlds/windows is not so good... > - the usage of the current world needs to be reviewed. The world has two distinct responsibilities right now > 1) it is the manager of the hands (required for drag n drop) > 2) it is the main container/pasteup for other morphs > > Imagine in the short term a Morphic Spec app can use a âexternal window rendering on athensâ strategy that mixes the two things above and each new window is popped up as a new window. :D > > For those @ESUG, Iâll be arriving this evening, Iâm going to show this in the show us your projects, and if you want to help, please contact me, you can learn a lot and its super fun :)

Aug. 26, 2019

Re: [Pharo-dev] [Weekend Procastination] what the new minheadless opens as posibilities :D

by Ben Coman

Thanks for sharing Guille. Now what I was wondering is what possibilities minheadless opens up for running on IOS and Android tablets and phones. IIUC one of the impediments was not being native-event-driven. Is the VM event handling now factored out to the degree necessary to drive it from native-events, or what more work is required there? On Mon, 26 Aug 2019 at 16:43, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi all, > > Over the weekend, instead of working on my ESUG presentations I > procastinated a bit with some experiments that I would like to share ^^. > > *Procastination 1:* Render the world fully in athens (instead of a > middling bitmap) to have an idea of the effort to get fast to hdpi > > What you see here is a world drawn completely in athens in minheadless, > where in red are the invalidated rectangles in the screen (Iâm using to > debug a bit). > Icons are broken because I broke them while playing, not because they do > not work in athens :P. > There is still work to do if we want to explore this direction. Mainly > performance issues to make it at least usable, so it can be iterated easily. > We have seen with Pablo that a lot of time is taken in the > transformation of morphic/pharo form/bitmaps to athens ones, since they do > not have the same format and right now it is done with a bit-per-bit copy. > > > *Procastination 2*: poping out morphs out of the world > > What you see here is that I can have different os windows with different > worlds, giving a multi-window experience :). > There is also work to do in this direction if we want to push it: > - morphic support for multiple worlds/windows is not so good... > - the usage of the current world needs to be reviewed. The world has two > distinct responsibilities right now > 1) it is the manager of the hands (required for drag n drop) > 2) it is the main container/pasteup for other morphs > > Imagine in the short term a Morphic Spec app can use a âexternal window > rendering on athensâ strategy that mixes the two things above and each new > window is popped up as a new window. :D > > For those @ESUG, Iâll be arriving this evening, Iâm going to show this in > the show us your projects, and if you want to help, please contact me, you > can learn a lot and its super fun :) > cheers -ben

Aug. 26, 2019

[Weekend Procastination] what the new minheadless opens as posibilities :D

by Guillermo Polito

Hi all, Over the weekend, instead of working on my ESUG presentations I procastinated a bit with some experiments that I would like to share ^^. Procastination 1: Render the world fully in athens (instead of a middling bitmap) to have an idea of the effort to get fast to hdpi What you see here is a world drawn completely in athens in minheadless, where in red are the invalidated rectangles in the screen (Iâm using to debug a bit). Icons are broken because I broke them while playing, not because they do not work in athens :P. There is still work to do if we want to explore this direction. Mainly performance issues to make it at least usable, so it can be iterated easily. We have seen with Pablo that a lot of time is taken in the transformation of morphic/pharo form/bitmaps to athens ones, since they do not have the same format and right now it is done with a bit-per-bit copy. Procastination 2: poping out morphs out of the world What you see here is that I can have different os windows with different worlds, giving a multi-window experience :). There is also work to do in this direction if we want to push it: - morphic support for multiple worlds/windows is not so good... - the usage of the current world needs to be reviewed. The world has two distinct responsibilities right now 1) it is the manager of the hands (required for drag n drop) 2) it is the main container/pasteup for other morphs Imagine in the short term a Morphic Spec app can use a âexternal window rendering on athensâ strategy that mixes the two things above and each new window is popped up as a new window. :D For those @ESUG, Iâll be arriving this evening, Iâm going to show this in the show us your projects, and if you want to help, please contact me, you can learn a lot and its super fun :)

Aug. 26, 2019

[Pharo 8.0] Build #674: Pre-load MCWorkingCopy cache

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

There is a new Pharo build available! The status of the build #674 was: FAILURE. The Pull Request #4254 was integrated: "Pre-load MCWorkingCopy cache " Pull request url: https://github.com/pharo-project/pharo/pull/4254 Issue Url: https://github.com/pharo-project/pharo/issues/ancestorsFromArray_cache_ Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 25, 2019

[Pharo 8.0] Build #673: Simplify Variables with default blocks

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

There is a new Pharo build available! The status of the build #673 was: FAILURE. The Pull Request #4420 was integrated: "Simplify Variables with default blocks" Pull request url: https://github.com/pharo-project/pharo/pull/4420 Issue Url: https://github.com/pharo-project/pharo/issues/backstop Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 25, 2019

Re: [Pharo-dev] Zamaahh

by Marcus Denker

It is on my TODO to think if we should not send all these automated mails to a dedicated mailinglist. Marcus > On 25 Aug 2019, at 12:10, Laszlo Zsolt Kiss <lzskiss(a)gmail.com> wrote: > > > 2019.08.24., Szo 16:18 dÃ¡tummal <ci-pharo-ci-jenkins2(a)inria.fr <mailto:ci-pharo-ci-jenkins2@inria.fr>> ezt Ãrta: > There is a new Pharo build available! > > The status of the build #671 was: FAILURE. > > The Pull Request #4418 was integrated: "4414-slot-class-defintion-Class-Variables-with-parameters-are-not-printed-correctly" > Pull request url: https://github.com/pharo-project/pharo/pull/4418 <https://github.com/pharo-project/pharo/pull/4418> > > Issue Url: https://github.com/pharo-project/pharo/issues/4414 <https://github.com/pharo-project/pharo/issues/4414> > 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…>

Aug. 25, 2019

Zamaahh

by Laszlo Zsolt Kiss

2019.08.24., Szo 16:18 dÃ¡tummal <ci-pharo-ci-jenkins2(a)inria.fr> ezt Ãrta: > There is a new Pharo build available! > > The status of the build #671 was: FAILURE. > > The Pull Request #4418 was integrated: > "4414-slot-class-defintion-Class-Variables-with-parameters-are-not-printed-correctly" > Pull request url: https://github.com/pharo-project/pharo/pull/4418 > > Issue Url: https://github.com/pharo-project/pharo/issues/4414 > Build Url: > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… >

Aug. 25, 2019

[Pharo 8.0] Build #672: 4149-instVarNames-is-not-including-instance-variables-coming-from-Stateful-traits

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

There is a new Pharo build available! The status of the build #672 was: FAILURE. The Pull Request #4367 was integrated: "4149-instVarNames-is-not-including-instance-variables-coming-from-Stateful-traits" Pull request url: https://github.com/pharo-project/pharo/pull/4367 Issue Url: https://github.com/pharo-project/pharo/issues/4149 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 24, 2019

[Pharo 8.0] Build #671: 4414-slot-class-defintion-Class-Variables-with-parameters-are-not-printed-correctly

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

There is a new Pharo build available! The status of the build #671 was: FAILURE. The Pull Request #4418 was integrated: "4414-slot-class-defintion-Class-Variables-with-parameters-are-not-printed-correctly" Pull request url: https://github.com/pharo-project/pharo/pull/4418 Issue Url: https://github.com/pharo-project/pharo/issues/4414 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 24, 2019

[Pharo 8.0] Build #670: Roassal3Extentions

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

There is a new Pharo build available! The status of the build #670 was: FAILURE. The Pull Request #4405 was integrated: "Roassal3Extentions" Pull request url: https://github.com/pharo-project/pharo/pull/4405 Issue Url: https://github.com/pharo-project/pharo/issues/Roassal3Extentions Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 24, 2019

[Pharo 8.0] Build #669: Class Variables with Default value

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

There is a new Pharo build available! The status of the build #669 was: FAILURE. The Pull Request #4413 was integrated: "Class Variables with Default value" Pull request url: https://github.com/pharo-project/pharo/pull/4413 Issue Url: https://github.com/pharo-project/pharo/issues/ClassVarWithDefault Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 24, 2019

[Pharo 8.0] Build #668: 4403-cannot-change-position-in-a-memory-write-stream

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

There is a new Pharo build available! The status of the build #668 was: SUCCESS. The Pull Request #4404 was integrated: "4403-cannot-change-position-in-a-memory-write-stream" Pull request url: https://github.com/pharo-project/pharo/pull/4404 Issue Url: https://github.com/pharo-project/pharo/issues/4403 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 23, 2019

[Pharo 8.0] Build #667: 4406-fix-class-def-parser-for-simple-definitions

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

There is a new Pharo build available! The status of the build #667 was: FAILURE. The Pull Request #4409 was integrated: "4406-fix-class-def-parser-for-simple-definitions" Pull request url: https://github.com/pharo-project/pharo/pull/4409 Issue Url: https://github.com/pharo-project/pharo/issues/4406 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 23, 2019

Re: [Pharo-dev] Class definition with slot template is broken

by Marcus Denker

> On 23 Aug 2019, at 12:43, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > >> On 23 Aug 2019, at 12:13, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >> >> Hi >> >> Ð¿Ñ, 23 Ð°Ð²Ð³. 2019 Ð³., 11:06 Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: >> >> >> > On 23 Aug 2019, at 11:49, Cyril Ferlicot <cyril.ferlicot(a)gmail.com <mailto:cyril.ferlicot@gmail.com>> wrote: >> > >> > Hi, >> > >> > Since yesterday I get a lot of bugs when I try to edit class >> > definitions while having the slot template in class definition >> > enabled. (See comment: >> > https://github.com/pharo-project/pharo/pull/4391 <https://github.com/pharo-project/pharo/pull/4391>) >> > This make it a little hard to develop :( >> > >> > Is there an easy fix? Else maybe we should revert the change until we >> > have the fix? >> > >> >> I have a fix, I will commit when the internet connection is good enough >> >> That's good. > > https://github.com/pharo-project/pharo/pull/4409 <https://github.com/pharo-project/pharo/pull/4409> > > >> >> I guess it was a class parser bug? I only tested browser with classic definition. > > yes, even with this fix I need to do some (larger) change to support Slots with parameters, e.g. > > {#lazy => LazySlot default: 5 . > #computed => ComputedSlot with: [:object | object calculateSomething] } > > I updated the fix: now it should work, there will be just no menu shown for these kinds of slots for now (to be fixed in a second step, we should add tests, too) Marcus

Aug. 23, 2019

Re: [Pharo-dev] Class definition with slot template is broken

by Marcus Denker

> On 23 Aug 2019, at 12:13, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi > > Ð¿Ñ, 23 Ð°Ð²Ð³. 2019 Ð³., 11:06 Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: > > > > On 23 Aug 2019, at 11:49, Cyril Ferlicot <cyril.ferlicot(a)gmail.com <mailto:cyril.ferlicot@gmail.com>> wrote: > > > > Hi, > > > > Since yesterday I get a lot of bugs when I try to edit class > > definitions while having the slot template in class definition > > enabled. (See comment: > > https://github.com/pharo-project/pharo/pull/4391 <https://github.com/pharo-project/pharo/pull/4391>) > > This make it a little hard to develop :( > > > > Is there an easy fix? Else maybe we should revert the change until we > > have the fix? > > > > I have a fix, I will commit when the internet connection is good enough > > That's good. https://github.com/pharo-project/pharo/pull/4409 <https://github.com/pharo-project/pharo/pull/4409> > > I guess it was a class parser bug? I only tested browser with classic definition. yes, even with this fix I need to do some (larger) change to support Slots with parameters, e.g. {#lazy => LazySlot default: 5 . #computed => ComputedSlot with: [:object | object calculateSomething] } This need some change in how the class parser models slots, thoughâ¦ CDSlotNode is just modelling a name and the class of the slot, but not the fact that slot definitions can contain parameters which can contain even blocksâ¦ and with composition (not yet in Pharo8), we need to support things like #lazyAndObservable => SpObservableSlot + LazySlot default: 5 . but I think it is not hard to do. Marcus

Aug. 23, 2019

Re: [Pharo-dev] Class definition with slot template is broken

by Denis Kudriashov

Hi Ð¿Ñ, 23 Ð°Ð²Ð³. 2019 Ð³., 11:06 Marcus Denker <marcus.denker(a)inria.fr>: > > > > On 23 Aug 2019, at 11:49, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> > wrote: > > > > Hi, > > > > Since yesterday I get a lot of bugs when I try to edit class > > definitions while having the slot template in class definition > > enabled. (See comment: > > https://github.com/pharo-project/pharo/pull/4391) > > This make it a little hard to develop :( > > > > Is there an easy fix? Else maybe we should revert the change until we > > have the fix? > > > > I have a fix, I will commit when the internet connection is good enough > That's good. I guess it was a class parser bug? I only tested browser with classic definition. > Marcus > > >

Aug. 23, 2019

Re: [Pharo-dev] Class definition with slot template is broken

by Marcus Denker

> On 23 Aug 2019, at 11:49, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > Hi, > > Since yesterday I get a lot of bugs when I try to edit class > definitions while having the slot template in class definition > enabled. (See comment: > https://github.com/pharo-project/pharo/pull/4391) > This make it a little hard to develop :( > > Is there an easy fix? Else maybe we should revert the change until we > have the fix? > I have a fix, I will commit when the internet connection is good enough Marcus

Aug. 23, 2019

Re: [Pharo-dev] Class definition with slot template is broken

by ducasse

Argh this is probably the changes using the class definition. Denis can you check? Else I will check how to revert it and wait that it becoming more ready. Stef > On 23 Aug 2019, at 11:49, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > Hi, > > Since yesterday I get a lot of bugs when I try to edit class > definitions while having the slot template in class definition > enabled. (See comment: > https://github.com/pharo-project/pharo/pull/4391) > This make it a little hard to develop :( > > Is there an easy fix? Else maybe we should revert the change until we > have the fix? > > Have a nice day! > > -- > Cyril Ferlicot > https://ferlicot.fr >

Aug. 23, 2019

Class definition with slot template is broken

by Cyril Ferlicot

Hi, Since yesterday I get a lot of bugs when I try to edit class definitions while having the slot template in class definition enabled. (See comment: https://github.com/pharo-project/pharo/pull/4391) This make it a little hard to develop :( Is there an easy fix? Else maybe we should revert the change until we have the fix? Have a nice day! -- Cyril Ferlicot https://ferlicot.fr

Aug. 23, 2019

[Pharo 8.0] Build #666: LazySlotPrinting

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

There is a new Pharo build available! The status of the build #666 was: SUCCESS. The Pull Request #4399 was integrated: "LazySlotPrinting" Pull request url: https://github.com/pharo-project/pharo/pull/4399 Issue Url: https://github.com/pharo-project/pharo/issues/LazySlotPrinting Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 22, 2019

[Pharo 8.0] Build #665: Improve-WeakValueDictionary

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

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

Aug. 22, 2019

[Pharo 8.0] Build #664: Monticello-tests-should-not-depend-on-deprecated-streams

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

There is a new Pharo build available! The status of the build #664 was: FAILURE. The Pull Request #4347 was integrated: "Monticello-tests-should-not-depend-on-deprecated-streams" Pull request url: https://github.com/pharo-project/pharo/pull/4347 Issue Url: https://github.com/pharo-project/pharo/issues/Monticello Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 22, 2019