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

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