- Pharo-dev - lists.pharo.org

[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