April 2020 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] FW: [Pharo-users] Label truncation in new Pharo 8.0 64-bit (stable)

by shaping＠uurda.org

On 2020-04-19 03:01, Sven Van Caekenberghe wrote: > Works for me (this font is larger than the default one). macOS, Pharo > 9 64bit > The screenshot below is taken on Windows 10 Pro. This time I did not change the theme. I did also update the fonts listed in the dialog before choosing FiraCode. The labels are still truncated. This is another new Pharo 8 64-bit (stable) with only the font changed. Why would formatting not work on Windows 10? > Can any Windows 10 Pharo users verify this problem? > >> On 19 Apr 2020, at 06:05, Shaping <shaping(a)uurda.org> wrote: >> >> Can anyone suggest a fix for the truncated labels shown below in the >> screenshot of the Setting window? This happens in the Git client >> too. >> >> Will Pharo tools be rewritten in Spec2, and does its formatting >> scheme solve generally the text-formatting problem, as font size is >> changed? >> >> Why don't we opt for easy elastic rendering of GUIs by >> implementing Pharo as a web app? Has this been discussed? Willow >> is looking very good. >> >> Shaping >> From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On >> Behalf Of Shaping >> Sent: Saturday, 18 April, 2020 04:16 >> To: 'Any question about pharo is welcome' >> <pharo-users(a)lists.pharo.org>; 'Pharo Development List' >> <pharo-dev(a)lists.pharo.org> >> Subject: [Pharo-users] Label truncation in new Pharo 8.0 64-bit >> (stable) >> >> Hi everyone. >> >> Below is a Pharo 8.0 64-bit (stable) image (installed with the new >> Launcher 2.0) with two changes: >> >> -Light theme selected. >> -FiraCode 11 chosen as the default font. >> >> <image001.png> >> >> Truncated labels in the GUI on font change has always been a >> problem. Am I the only one experiencing this? >> >> Shaping >> From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On >> Behalf Of Sanjay Minni >> Sent: Friday, 17 April, 2020 11:05 >> To: Any question about pharo is welcome >> <pharo-users(a)lists.pharo.org> >> Subject: Re: [Pharo-users] issues in setting up a new project on >> Github/Iceberg >> >> Thanks tried just https and this worked too >> I suppose once cloned it does not really matter whether it was done >> using "clone from github.com" or "clone remote repository" >> --- >> Sanjay Minni >> +91-9900-902902 >> >> On Fri, 17 Apr 2020 at 19:43, Guillermo Polito >> <guillermopolito(a)gmail.com> wrote: >> Hi, >> >> El 17 abr 2020, a las 15:30, Sanjay Minni <sm(a)planage.com> >> escribiÃ³: >> >> Hi Guillermo, >> >> Ok then given your comments - right now got it working as such >> - initially created as private in Github >> - changed to public >> - created clone from github >> - (did a repair repository (dont know why) and created "src" and >> designated it as source folder) >> - did a commit and push >> - changed repository back to private >> seems to work >> >> can you give an example on how the "Remote URL" field is to be >> filled up - note its not taking HTTP as i am not sure about the >> syntax, assume SSH, Github, MyName, MyRepository, >> will try that as well >> >> you should be able to use the URLs provided by the clone buttons in >> Github/gitlab/bitbucket, both https and ssh. >> >> <image004.png> >> >> note Just for Info to other users: >> I am using Windows 10, it seems to have SSH tools inbuilt and was >> able to use ssh (with passphrase) without hiccup, by putting my key >> files path in pharo setting-> ...-> use custom SSH keys, and >> uploading the .pub key in Github >> >> :) >> >> Thanks >> >> --- >> Sanjay Minni >> +91-9900-902902 >> >> On Fri, 17 Apr 2020 at 18:36, Guillermo Polito >> <guillermopolito(a)gmail.com> wrote: >> Hi Sanjay, >> >> This is a bug in Iceberg github integration that tries to access the >> repository to get metadata using Github REST API using anonymous >> access apparently. >> And since your project is private, this fails. >> >> As a workaroung, I suggest you to clone using the last option that >> requires an url only: >> >> <PastedGraphic-3.png> >> >> This option will not use the Github API, so you should find no >> problems. >> >> I'm planning doing an Iceberg sprint and fix many issues in the >> coming weeks. >> (Also if somebody wants to join, this is an open call :)) >> Guille >> >> El 17 abr 2020, a las 12:49, Sanjay Minni <sm(a)planage.com> >> escribiÃ³: >> >> Using Pharo 8 64 bit on Windows 10 >> >> I am trying to setup a new project on Github using Iceberg following >> the >> document "Manage your code with Iceberg dtd 25 March 2019) >> >> After creating the project in github when I try to clone from Github >> as (I >> am at doc item1.4) The system throws an error and the project does >> not >> appear in iceberg although the files are downloaded. This happen in >> both >> cases whether I use HTTP or SSH >> >> What is going wrong ? >> >> also: assuming the clone is made, as per next item in doc 1.5, the >> directory >> "src" is created after the clone is made. is that correct ?... then >> how will >> the packages sources be mapped to ..\src > <http://forum.world.st/file/t368721/1-GettingFirstEmptyProjFromGit.jpg> > >> <http://forum.world.st/file/t368721/0-GithubProjectCreation.jpg> >> >> ----- >> cheers, >> Sanjay >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 19, 2020

Re: [Pharo-dev] FW: [Pharo-users] Label truncation in new Pharo 8.0 64-bit (stable)

by Sven Van Caekenberghe

Works for me (this font is larger than the default one). macOS, Pharo 9 64bit > On 19 Apr 2020, at 06:05, Shaping <shaping(a)uurda.org> wrote: > > Can anyone suggest a fix for the truncated labels shown below in the screenshot of the Setting window? This happens in the Git client too. > > Will Pharo tools be rewritten in Spec2, and does its formatting scheme solve generally the text-formatting problem, as font size is changed? > > Why donât we opt for easy elastic rendering of GUIs by implementing Pharo as a web app? Has this been discussed? Willow is looking very good. > > > Shaping > From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Shaping > Sent: Saturday, 18 April, 2020 04:16 > To: 'Any question about pharo is welcome' <pharo-users(a)lists.pharo.org>; 'Pharo Development List' <pharo-dev(a)lists.pharo.org> > Subject: [Pharo-users] Label truncation in new Pharo 8.0 64-bit (stable) > > Hi everyone. > > Below is a Pharo 8.0 64-bit (stable) image (installed with the new Launcher 2.0) with two changes: > > -Light theme selected. > -FiraCode 11 chosen as the default font. > > > <image001.png> > > Truncated labels in the GUI on font change has always been a problem. Am I the only one experiencing this? > > > Shaping > From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Sanjay Minni > Sent: Friday, 17 April, 2020 11:05 > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > Subject: Re: [Pharo-users] issues in setting up a new project on Github/Iceberg > > Thanks tried just https and this worked too > I suppose once cloned it does not really matter whether it was done using "clone from github.com" or "clone remote repository" > --- > Sanjay Minni > +91-9900-902902 > > > On Fri, 17 Apr 2020 at 19:43, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> Hi, >> >> >>> El 17 abr 2020, a las 15:30, Sanjay Minni <sm(a)planage.com> escribiÃ³: >>> >>> Hi Guillermo, >>> >>> Ok then given your comments - right now got it working as such >>> - initially created as private in Github >>> - changed to public >>> - created clone from github >>> - (did a repair repository (dont know why) and created "src" and designated it as source folder) >>> - did a commit and push >>> - changed repository back to private >>> seems to work >>> >>> can you give an example on how the "Remote URL" field is to be filled up - note its not taking HTTP as i am not sure about the syntax, assume SSH, Github, MyName, MyRepository, >>> will try that as well >> >> you should be able to use the URLs provided by the clone buttons in Github/gitlab/bitbucket, both https and ssh. >> >> <image004.png> >> >> >>> >>> note Just for Info to other users: >>> I am using Windows 10, it seems to have SSH tools inbuilt and was able to use ssh (with passphrase) without hiccup, by putting my key files path in pharo setting-> ...-> use custom SSH keys, and uploading the .pub key in Github >> >> :) >> >> Thanks >> >> >>> --- >>> Sanjay Minni >>> +91-9900-902902 >>> >>> >>> On Fri, 17 Apr 2020 at 18:36, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >>>> Hi Sanjay, >>>> >>>> This is a bug in Iceberg github integration that tries to access the repository to get metadata using Github REST API using anonymous access apparently. >>>> And since your project is private, this fails. >>>> >>>> As a workaroung, I suggest you to clone using the last option that requires an url only: >>>> >>>> <PastedGraphic-3.png> >>>> >>>> This option will not use the Github API, so you should find no problems. >>>> >>>> Iâm planning doing an Iceberg sprint and fix many issues in the coming weeks. >>>> (Also if somebody wants to join, this is an open call :)) >>>> Guille >>>> >>>> >>>>> El 17 abr 2020, a las 12:49, Sanjay Minni <sm(a)planage.com> escribiÃ³: >>>>> >>>>> Using Pharo 8 64 bit on Windows 10 >>>>> >>>>> I am trying to setup a new project on Github using Iceberg following the >>>>> document "Manage your code with Iceberg dtd 25 March 2019) >>>>> >>>>> After creating the project in github when I try to clone from Github as (I >>>>> am at doc item1.4) The system throws an error and the project does not >>>>> appear in iceberg although the files are downloaded. This happen in both >>>>> cases whether I use HTTP or SSH >>>>> >>>>> What is going wrong ? >>>>> >>>>> also: assuming the clone is made, as per next item in doc 1.5, the directory >>>>> "src" is created after the clone is made. is that correct ?... then how will >>>>> the packages sources be mapped to ..\src >>>>> >>>>> >>>>> <http://forum.world.st/file/t368721/1-GettingFirstEmptyProjFromGit.jpg> >>>>> >>>>> <http://forum.world.st/file/t368721/0-GithubProjectCreation.jpg> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ----- >>>>> cheers, >>>>> Sanjay >>>>> -- >>>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>>>>

April 19, 2020

FW: [Pharo-users] Label truncation in new Pharo 8.0 64-bit (stable)

by Shaping

Can anyone suggest a fix for the truncated labels shown below in the screenshot of the Setting window? This happens in the Git client too. Will Pharo tools be rewritten in Spec2, and does its formatting scheme solve generally the text-formatting problem, as font size is changed? Why donât we opt for easy elastic rendering of GUIs by implementing Pharo as a web app? Has this been discussed? Willow is looking very good. Shaping From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Shaping Sent: Saturday, 18 April, 2020 04:16 To: 'Any question about pharo is welcome' <pharo-users(a)lists.pharo.org>; 'Pharo Development List' <pharo-dev(a)lists.pharo.org> Subject: [Pharo-users] Label truncation in new Pharo 8.0 64-bit (stable) Hi everyone. Below is a Pharo 8.0 64-bit (stable) image (installed with the new Launcher 2.0) with two changes: -Light theme selected. -FiraCode 11 chosen as the default font. Truncated labels in the GUI on font change has always been a problem. Am I the only one experiencing this? Shaping From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Sanjay Minni Sent: Friday, 17 April, 2020 11:05 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org> > Subject: Re: [Pharo-users] issues in setting up a new project on Github/Iceberg Thanks tried just https and this worked too I suppose once cloned it does not really matter whether it was done using "clone from github.com <http://github.com> " or "clone remote repository" --- Sanjay Minni +91-9900-902902 On Fri, 17 Apr 2020 at 19:43, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com> > wrote: Hi, El 17 abr 2020, a las 15:30, Sanjay Minni <sm(a)planage.com <mailto:sm@planage.com> > escribiÃ³: Hi Guillermo, Ok then given your comments - right now got it working as such - initially created as private in Github - changed to public - created clone from github - (did a repair repository (dont know why) and created "src" and designated it as source folder) - did a commit and push - changed repository back to private seems to work can you give an example on how the "Remote URL" field is to be filled up - note its not taking HTTP as i am not sure about the syntax, assume SSH, Github, MyName, MyRepository, will try that as well you should be able to use the URLs provided by the clone buttons in Github/gitlab/bitbucket, both https and ssh. note Just for Info to other users: I am using Windows 10, it seems to have SSH tools inbuilt and was able to use ssh (with passphrase) without hiccup, by putting my key files path in pharo setting-> ...-> use custom SSH keys, and uploading the .pub key in Github :) Thanks --- Sanjay Minni +91-9900-902902 On Fri, 17 Apr 2020 at 18:36, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com> > wrote: Hi Sanjay, This is a bug in Iceberg github integration that tries to access the repository to get metadata using Github REST API using anonymous access apparently. And since your project is private, this fails. As a workaroung, I suggest you to clone using the last option that requires an url only: <PastedGraphic-3.png> This option will not use the Github API, so you should find no problems. Iâm planning doing an Iceberg sprint and fix many issues in the coming weeks. (Also if somebody wants to join, this is an open call :)) Guille El 17 abr 2020, a las 12:49, Sanjay Minni <sm(a)planage.com <mailto:sm@planage.com> > escribiÃ³: Using Pharo 8 64 bit on Windows 10 I am trying to setup a new project on Github using Iceberg following the document "Manage your code with Iceberg dtd 25 March 2019) After creating the project in github when I try to clone from Github as (I am at doc item1.4) The system throws an error and the project does not appear in iceberg although the files are downloaded. This happen in both cases whether I use HTTP or SSH What is going wrong ? also: assuming the clone is made, as per next item in doc 1.5, the directory "src" is created after the clone is made. is that correct ?... then how will the packages sources be mapped to ..\src <http://forum.world.st/file/t368721/1-GettingFirstEmptyProjFromGit.jpg> <http://forum.world.st/file/t368721/0-GithubProjectCreation.jpg> ----- cheers, Sanjay -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 19, 2020

Re: [Pharo-dev] [SPAM] Re: [Pharo-users] [ANN] Pharo Launcher 2.0 released!

by Esteban Maringolo

Thanks, I will check it as soon as Pharo.org gets back online! [1] https://downforeveryoneorjustme.com/pharo.org Esteban A. Maringolo On Sat, Apr 18, 2020 at 10:48 AM Christophe Demarey <christophe.demarey(a)inria.fr> wrote: > > Hi Graham, > > > Le 18 avr. 2020 Ã 11:30, Graham McLeod <graham(a)inspired.org> a Ã©crit : > > Hi > > This looks like a major update with some very welcome features and improved UI. > Very welcome and thanks for the work! > > One item I would like to see is a mention in the help on implications of upgrading from the existing > Pharo launcher. Bit nervous to install when I don't know what will become of existing configurations in the old one. > I am assuming that the new one is independent and will simply start off blank. It would be nice to have this tackled in the > documentation. Maybe a short section on "Moving your configurations / images from the old Launcher Â». > > > Yes, youâre right! > Pharo Launcher is mostly compatible with the previous one. > When using Pharo Launcher 2.0, image metadata will be converted from the old format to the new one. > I added an upgrade section on Pharo Launcher documentation: https://pharo-project.github.io/pharo-launcher/installation/#upgrade-notes > > Tell me if this is enough. > Regards, > Christophe

April 18, 2020

Re: [Pharo-dev] [SPAM] Re: [Pharo-users] [ANN] Pharo Launcher 2.0 released!

by Christophe Demarey

Hi Graham, > Le 18 avr. 2020 Ã 11:30, Graham McLeod <graham(a)inspired.org> a Ã©crit : > > Hi > > This looks like a major update with some very welcome features and improved UI. > Very welcome and thanks for the work! > > One item I would like to see is a mention in the help on implications of upgrading from the existing > Pharo launcher. Bit nervous to install when I don't know what will become of existing configurations in the old one. > I am assuming that the new one is independent and will simply start off blank. It would be nice to have this tackled in the > documentation. Maybe a short section on "Moving your configurations / images from the old Launcher Â». Yes, youâre right! Pharo Launcher is mostly compatible with the previous one. When using Pharo Launcher 2.0, image metadata will be converted from the old format to the new one. I added an upgrade section on Pharo Launcher documentation: https://pharo-project.github.io/pharo-launcher/installation/#upgrade-notes Tell me if this is enough. Regards, Christophe

April 18, 2020

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Launcher 2.0 released!

by Sven Van Caekenberghe

> On 18 Apr 2020, at 10:40, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > Super cool > Thanks a lot christophe for your effort. > PharoLauncher changes our life. +10 > S. > >> On 17 Apr 2020, at 18:08, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: >> >> Hi all, >> >> Pharo Launcher 2.0 has just been released! It is available from http://pharo.org/download. >> >> This new version introduces major changes: >> â¢ The UI has been fully rewritten using the new Spec2 framework and the Commander2 library. UI has been revamped to increase usability, especially for newcomers. The main window is now composed of a toolbar and the list of images. The template list is now available when clicking on the new image button. >> â¢ Documentation web site : All Pharo Launcher features are now explained in the new documentation available at https://pharo-project.github.io/pharo-launcher. You can contribute easily by clicking the *edit on GitHub* button. >> â¢ You can now have many launch configurations for an image (VM to use, vm and image arguments). It means you can use headless Pharo VM from Pharo Launcher. >> â¢ When creating a new image, you can specify an initialisation script that will be run once at the first image launch. It is useful to load your project code in a stock Pharo image for example. See https://pharo-project.github.io/pharo-launcher/create-images/#image-initial… >> â¢ You can now define your own template sources in addition to official sources (see https://pharo-project.github.io/pharo-launcher/templates/#create-your-own-l…) including authenticated sources. >> â¢ Improved image metadata. Pharo Launcher now manages all image metadata in a single STON file (including description, Pharo version). >> >> Big thanks to all contributors, including issue reports. It is also the opportunity to thanks Damien Cassou, the original author of Pharo Launcher. >> >> Here is the changelog: >> Pharo Launcher v2.0 >> >> The list of closed issue is too long (68) to be listed but you can browse it here: https://github.com/pharo-project/pharo-launcher/issues?q=is%3Aissue+is%3Acl… >> Here are some highlights: >> New features: >> >> â¢ Documentation web site >> â¢ Image initialisation script >> â¢ Launch configurations, headless VM support >> â¢ User template file in addition to the official template file >> â¢ Jenkins server template now support pipeline projects >> â¢ Support of private Jenkins server >> â¢ Support of authenticated HTTP server >> Improvements: >> >> â¢ Monitoring of image launch failures to give back the error message (if any) >> â¢ Newly created image is automatically selected in the image list >> â¢ Allow to set image description at creation time >> â¢ Better error management (you will have the choice to ignore them or debug them) >> â¢ Add a poor version column in image list >> â¢ Speedup (especially when image repository has a lot of images) >> >> Bug fixes: >> >> â¢ Fix use of system unzip on Windows >> >> Regards, >> The Pharo team. > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr / 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 >

April 18, 2020

Re: [Pharo-dev] [SPAM] Re: [Pharo-users] [ANN] Pharo Launcher 2.0 released!

by Graham McLeod

Hi This looks like a major update with some very welcome features and improved UI. Very welcome and thanks for the work! One item I would like to see is a mention in the help on implications of upgrading from the existing Pharo launcher. Bit nervous to install when I don't know what will become of existing configurations in the old one. I am assuming that the new one is independent and will simply start off blank. It would be nice to have this tackled in the documentation. Maybe a short section on "Moving your configurations / images from the old Launcher". Great job! Thanks Graham > CÃ©drick BÃ©ler <mailto:cdrick65@gmail.com> > 18 April 2020 at 10:09 > Great Job. It looks indeed nicer. > > I found the docs great too > (https://pharo-project.github.io/pharo-launcher) > > One suggestion would be to add the helpÂ contextually. IÂ tried to look > at. There is description of commands and SpLinkPresenter but donât > think itâs easy to add. I wanted to add the ling in the helpÂ description. > > For instance, the one to create an image for template: > WebBrowser openOn: > 'https://pharo-project.github.io/pharo-launcher/create-images/â > <https://pharo-project.github.io/pharo-launcher/create-images/%E2%80%98> > > Any way of doing that ? > > > Cheers, > > CÃ©drick > > > > > Christophe Demarey <mailto:christophe.demarey@inria.fr> > 17 April 2020 at 18:08 > Hi all, > > Pharo Launcher 2.0 has just been released! It is available from > http://pharo.org/download. > > This new version introduces major changes: > > * The UI has been fully rewritten using the new Spec2 framework > <https://github.com/pharo-spec/Spec>Â and the Commander2 library > <https://github.com/pharo-spec/Commander2>. UI has been revamped > to increase usability, especially for newcomers. The main window > is now composed of a toolbar and the list of images. The template > list is now available when clicking on the new image button. > * Documentation web site : All Pharo Launcher features are now > explained in the new documentation available at > https://pharo-project.github.io/pharo-launcher. You can contribute > easily by clicking the *edit on GitHub* button. > * You can now have many launch configurations for an image (VM to > use, vm and image arguments). It means you can use headless Pharo > VM from Pharo Launcher. > * When creating a new image, you can specify an initialisation > script that will be run once at the first image launch. It is > useful to load your project code in a stock Pharo image for > example. See > https://pharo-project.github.io/pharo-launcher/create-images/#image-initial… > * You can now define your own template sources in addition to > official sources (see > https://pharo-project.github.io/pharo-launcher/templates/#create-your-own-l…) > including authenticated sources. > * Improved image metadata. Pharo Launcher now manages all image > metadata in a single STON file (including description, Pharo version). > > > Big thanks to all contributors, including issue reports. It is also > the opportunity to thanks Damien Cassou, the original author of Pharo > Launcher. > > Here is the changelog: > Pharo Launcher v2.0 > <https://github.com/pharo-project/pharo-launcher/releases/tag/2.0> > > The list of closed issue is too long (68) to be listed but you can > browse it here: > https://github.com/pharo-project/pharo-launcher/issues?q=is%3Aissue+is%3Acl… > Here are some highlights: > > New features: > > * Documentation web site > * Image initialisation script > * Launch configurations, headless VM support > * User template file in addition to the official template file > * Jenkins server template now support pipeline projects > * Support of private Jenkins server > * Support of authenticated HTTP server > > Improvements: > > * Monitoring of image launch failures to give back the error message > (if any) > * Newly created image is automatically selected in the image list > * Allow to set image description at creation time > * Better error management (you will have the choice to ignore them > or debug them) > * Add a poor version column in image list > * Speedup (especially when image repository has a lot of images) > > Bug fixes: > > * Fix use of system unzip on Windows > > > Regards, > The Pharo team.

April 18, 2020

Label truncation in new Pharo 8.0 64-bit (stable)

by Shaping

Hi everyone. Below is a Pharo 8.0 64-bit (stable) image (installed with the new Launcher 2.0) with two changes: -Light theme selected. -FiraCode 11 chosen as the default font. Truncated labels in the GUI on font change has always been a problem. Am I the only one experiencing this? Shaping From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Sanjay Minni Sent: Friday, 17 April, 2020 11:05 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Subject: Re: [Pharo-users] issues in setting up a new project on Github/Iceberg Thanks tried just https and this worked too I suppose once cloned it does not really matter whether it was done using "clone from github.com <http://github.com> " or "clone remote repository" --- Sanjay Minni +91-9900-902902 On Fri, 17 Apr 2020 at 19:43, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com> > wrote: Hi, El 17 abr 2020, a las 15:30, Sanjay Minni <sm(a)planage.com <mailto:sm@planage.com> > escribiÃ³: Hi Guillermo, Ok then given your comments - right now got it working as such - initially created as private in Github - changed to public - created clone from github - (did a repair repository (dont know why) and created "src" and designated it as source folder) - did a commit and push - changed repository back to private seems to work can you give an example on how the "Remote URL" field is to be filled up - note its not taking HTTP as i am not sure about the syntax, assume SSH, Github, MyName, MyRepository, will try that as well you should be able to use the URLs provided by the clone buttons in Github/gitlab/bitbucket, both https and ssh. note Just for Info to other users: I am using Windows 10, it seems to have SSH tools inbuilt and was able to use ssh (with passphrase) without hiccup, by putting my key files path in pharo setting-> ...-> use custom SSH keys, and uploading the .pub key in Github :) Thanks --- Sanjay Minni +91-9900-902902 On Fri, 17 Apr 2020 at 18:36, Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com> > wrote: Hi Sanjay, This is a bug in Iceberg github integration that tries to access the repository to get metadata using Github REST API using anonymous access apparently. And since your project is private, this fails. As a workaroung, I suggest you to clone using the last option that requires an url only: <PastedGraphic-3.png> This option will not use the Github API, so you should find no problems. Iâm planning doing an Iceberg sprint and fix many issues in the coming weeks. (Also if somebody wants to join, this is an open call :)) Guille El 17 abr 2020, a las 12:49, Sanjay Minni <sm(a)planage.com <mailto:sm@planage.com> > escribiÃ³: Using Pharo 8 64 bit on Windows 10 I am trying to setup a new project on Github using Iceberg following the document "Manage your code with Iceberg dtd 25 March 2019) After creating the project in github when I try to clone from Github as (I am at doc item1.4) The system throws an error and the project does not appear in iceberg although the files are downloaded. This happen in both cases whether I use HTTP or SSH What is going wrong ? also: assuming the clone is made, as per next item in doc 1.5, the directory "src" is created after the clone is made. is that correct ?... then how will the packages sources be mapped to ..\src <http://forum.world.st/file/t368721/1-GettingFirstEmptyProjFromGit.jpg> <http://forum.world.st/file/t368721/0-GithubProjectCreation.jpg> ----- cheers, Sanjay -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

April 18, 2020

Re: [Pharo-dev] [Vm-dev] Pony for Pharo VM

by Shaping

Just to get in the right frame of mind, consider that because of the Blub Paradox (http://www.paulgraham.com/avg.html) you are going to have a hard time convincing people to "change to this language because of Feature X" just by saying so. You need to dig deeper. The Pony compiler and runtime need to be studied. What better way than to bring the Pony compiler into Squeak? Build a Pony runtime inside Squeak, with the vm simulator. Build a VM. Then people will learn Pony and it would be great! Yes, that is one way. Then we can simulate the new collector with Smalltalk in the usual way, whilst also integrating ref-caps and dynamic types (the main challenge). We already know that Orca works in Pony (in high-performance productionânot an experiment or toy). Still there will be bugs and perhaps room for improvements. Smalltalk simulation would help greatly there. The simulated Pony-Orca (the term used in the Orca paper) or simulated Smalltalk-Orca, if we can tag classes with ref-caps and keep Orca working, will run even more slowly in simulation-mode with all that message-passing added to the mix. Iâm starting to study the Pharo VM. Can someone suggest what to read. I see what appears to be outdated VM-related material. Iâm not sure what to study (besides the source code) and what to ignore. Iâm especially interested to know what not to read. Iâm not trying to convince; Iâm presenting facts, observations, and resources for study of the problem and its solution. Hardware constraints now are intensely multicore, and everyone knows this. The changing programming paradigm in apparent. Hardware structure is forcing that change. Convincing yourself will not be difficult when you have the facts. You likely do already, at least on the problem-side. The solution is easy. The problem is easy to understand. It reduces to StW GCing in a large heap and how to make instead may small, well-managed heaps, one per actor. Orca does that already and demonstrates very high performance. Thatâs what the Orca paper is about. The solution for Smalltalk is more complicated, and will involve a concurrent collector. The best one I can find now is Orca. If you know a better one, please share your facts. As different event loops on different cores will use the same externalizing remote interface This idea is not clear. Is there a description of it? to reach other event loops, we do not need a runtime that can run on all of those cores. We just need to start the minimal image on the CogVM with remote capabilities Pony doesnât yet have machine-node remoteness. The networked version is being planned, but is a ways off still. By remote, do you mean: another machine or another OS/CogVM process on the same machine? I think the Pony runtime is still creating by default just one OS process per app and as many threads as needed, with each actor having only one thread of execution by definition of what an actor is (single-threaded, very simple, very small). A scheduler keeps all cores busy, running and interleaving all the current actor threads. Message tracing maintains ref counts. A cycle-detector keep things tidy. Do Squeak and Pharo have those abilities? to share workload. With Pony-Orca, sharing of the workload doesnât need to be managed by the programmer. Thatâs one of basic reasons for the existence of Pony-Orca. The Pony-Orca dev writes his actors, and they run automatically in load-balance, via the actor-thread scheduler and work-stealing, when possible, on all the cores. Making Smalltalk work with Orca is, at this early stage, about understanding how Orca works (study the C++ and program in Pony) and how to implement it, if possible, in a Smalltalk simulator. Concerning Orca in particular, if you notice at end of the paper, they tested Orca against Erlang VM, C4, and G1, and it performed much better than all. The biggest challenge, I think you would agree is the system/application design that provides the opportunities to take advantage of parallelism. It kinda fits the microservices arch. So, we would run 64 instances of squeak to take the multicore to town. No, thatâs much slower. Squeak/Pharo still has the basic threading handicap: a single large heap. Hereâs the gist of the problem again: the big heap will not work and must go away, if we are to have extreme speed and a generalized multithreading programming solution. My current understanding is that Pony-Orca (or Smalltalk-Orca) starts one OS process, and then spawns threads, as new actors begin working. You donât need to do anything special as a programmer to make that happen. You just write the actors, keep them small, use the ref-caps correctly so that the program compiles (the ref-caps must also be applied to Smalltalk classes), and organize your synchronous code into classes, as usual. Functions run synchronous code. Behaviours run asynchronous code. The issue is not whether to use Pony. I donât like Pony, the language; itâs okay, even very good, but itâs not Smalltalk. I like Smalltalk, who concurrency model is painfully lame. Squeak concurrency model. Installer ss project: 'Cryptography'; install: 'CapabilitiesLocal' What abilities does the above install give Squeak? I like Orca because it works on many cores (as many as 64, currently) without a synchronization step for GC, and has wonderful concurrency abilities. Pony and Orca were co-designed. The deferred reference counts managed by Orca run on the messages between the actors (send/receive tracing). GCs happen in Pony/Orca when each actor finishes its response to the last received message, and goes idle. The actor then GCs all objects no longer referenced by other actors. The runtime scheduler takes this time needed for each actorâs GCing into account. No actor waits to GC objects. An actorâs allocated objectsâ ref counts are checked at idle-time, and unreferenced objects are GCed in an ongoing, fluid way, in small, high-frequency bursts, with very small, predictable tail latencies, as a result. Thatâs very interesting if you need smoothly running apps (graphics), design/program real-time control systems, or process data at high rates, as in financial applications at banks and exchanges. So your use of Pony is purely to access the Orca vm? Orca is not a VM; itâs a garbage collection protocol for actor-based systems. I suggest using Pony-Orca to learn how Orca works, and then replace the Pony part of Pony-Orca with Smalltalk (dynamic typing), keeping the ref-caps (because they provide the guarantees). I realize that this is a big undertaking. Or: write a new implementation of Orca in Smalltalk for the VM. This is currently second choice, but that could change. I think you will find the CogVM quite interesting and performant. --Not with its current architecture. If the CogVM is not able to: 1) dynamically schedule unlimited actor-threads on all cores 2) automatically load-balance 3) support actor-based programs innately 4) guarantee no data-races then, no, it is definitely not as interesting as the best concurrent collectors, like Orca, with an integrated type system and language. Orca has been applied successfully to Pony. Orca was also applied to the language Encore. If CogVM can be changed to implement a concurrent collector, then CogVM is interesting. Thatâs a big change. The main value of CogVM now seems to be as a possible building/rebuilding tool for the VM itself. Did you study the Wallaroo leaning experience concerning performance? Iâve no interest in coding custom, one-off, multi-core apps (or settling for a much slower general solution, as in the Erlang-like concurrency model in Squeak). Custom-coded multithreading is too costly and too error-prone. Itâs not fun, productive, or even needed, unless you really do need an extremely optimized concurrent solution for a specific domain. I donât want inter-process communication before inter-thread communication (much faster) has been exhausted. The concurrent collector, Orca in this case, in conjunction with the ref-caps generalize the multicore solution, efficiently (thatâs the point of it) for any actor-based program, and the zero-copy message passing gives much more speed than IPC. The tiny heaps cause tiny pauses on async collection. Runtime message tracing costs decrease as use of mutable types does. Message tracing happens only because there are mutable types to track and eventually collect; none of that applies to immutable types. See the test results in the paper for details. The issue is how most efficiently to use Orca, which happens to be working in Pony. Pony is in production in two internal, speed-demanding, banking apps and in Wallaroo Labsâ high-rate streaming product. Pony is a convenient way to study and use a working implementation of Orca. Ergo, use Pony, even if we only study it as a good example of how to use Orca. Some tweaks (probably a lot of them) could allow use of dynamic types. We could roll our own implementation of Orca for the current Pharo VM, but that seems like more work than tweaking a working Pony compiler and runtime. Iâm not sure about that. You know the VM better than I. (I was beginning my study of the Pharo/OpenSmalltalkVM when I found Pony.) Sounds like you might regret your choice and took the wrong path. I donât see how you form that conclusion. Iâve not chosen yet. I seek the easiest integration/mutation path for a concurrent collector and ref-cap system. I can start with Pony or a Smalltalk VM simulator. Either direction may be chosen. Squeak/Pharoâs current architecture (it has one big heap) is not suitable for general, automatic, fast multithreading. If all the VM C code can be simulated in Smalltalk before compiling it to an exe, then simulation may be the better path. Come back to Squeak! ^,^ I see the Actors for Squeak page. That is not a suitable implementation. Iâve not used Squeak since 2004, and donât know its current state. I assume that it does not have the four concurrency-related abilities listed above. Does it? If you know, please share the current facts about Squeakâs concurrency abilities. I prefer to skip the work needed to adapt Smalltalk to a concurrent collector like Orca, if those abilities already exist in Squeak /Pharo. If most of what Squeak/Pharo offers is pleasant/productive VM simulation, much work still remains to achieve even a basic actor system and collector, but the writing of VM code in Smalltalk and compiling it to C may be much more productive than writing C++. The C++ for the Pony compiler and runtime, however, already compiles and works well. Thus, starting the work in C++ is somewhat tempting. Can someone explain the limits of how the VM simulator can be used? How much VM core C is not a part of what can be compiled from Smalltalk? Can all VM C code be compiled from Smalltalk? Shaping

April 18, 2020

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Launcher 2.0 released!

by StÃ©phane Ducasse

Super cool Thanks a lot christophe for your effort. PharoLauncher changes our life. S. > On 17 Apr 2020, at 18:08, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > > Hi all, > > Pharo Launcher 2.0 has just been released! It is available from http://pharo.org/download <http://pharo.org/download>. > > This new version introduces major changes: > The UI has been fully rewritten using the new Spec2 framework <https://github.com/pharo-spec/Spec> and the Commander2 library <https://github.com/pharo-spec/Commander2>. UI has been revamped to increase usability, especially for newcomers. The main window is now composed of a toolbar and the list of images. The template list is now available when clicking on the new image button. > Documentation web site : All Pharo Launcher features are now explained in the new documentation available at https://pharo-project.github.io/pharo-launcher <https://pharo-project.github.io/pharo-launcher>. You can contribute easily by clicking the *edit on GitHub* button. > You can now have many launch configurations for an image (VM to use, vm and image arguments). It means you can use headless Pharo VM from Pharo Launcher. > When creating a new image, you can specify an initialisation script that will be run once at the first image launch. It is useful to load your project code in a stock Pharo image for example. See https://pharo-project.github.io/pharo-launcher/create-images/#image-initial… <https://pharo-project.github.io/pharo-launcher/create-images/#image-initial…> > You can now define your own template sources in addition to official sources (see https://pharo-project.github.io/pharo-launcher/templates/#create-your-own-l… <https://pharo-project.github.io/pharo-launcher/templates/#create-your-own-l…>), including authenticated sources. > Improved image metadata. Pharo Launcher now manages all image metadata in a single STON file (including description, Pharo version). > > Big thanks to all contributors, including issue reports. It is also the opportunity to thanks Damien Cassou, the original author of Pharo Launcher. > > Here is the changelog: > Pharo Launcher v2.0 <https://github.com/pharo-project/pharo-launcher/releases/tag/2.0> > > The list of closed issue is too long (68) to be listed but you can browse it here: https://github.com/pharo-project/pharo-launcher/issues?q=is%3Aissue+is%3Acl… <https://github.com/pharo-project/pharo-launcher/issues?q=is%3Aissue+is%3Acl…> > Here are some highlights: > New features: > > Documentation web site > Image initialisation script > Launch configurations, headless VM support > User template file in addition to the official template file > Jenkins server template now support pipeline projects > Support of private Jenkins server > Support of authenticated HTTP server > Improvements: > > Monitoring of image launch failures to give back the error message (if any) > Newly created image is automatically selected in the image list > Allow to set image description at creation time > Better error management (you will have the choice to ignore them or debug them) > Add a poor version column in image list > Speedup (especially when image repository has a lot of images) > > Bug fixes: > > Fix use of system unzip on Windows > > Regards, > The Pharo team. -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / 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

April 18, 2020

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Launcher 2.0 released!

by CÃ©drick BÃ©ler

Great Job. It looks indeed nicer. I found the docs great too (https://pharo-project.github.io/pharo-launcher <https://pharo-project.github.io/pharo-launcher>). One suggestion would be to add the help contextually. I tried to look at. There is description of commands and SpLinkPresenter but donât think itâs easy to add. I wanted to add the ling in the help description. For instance, the one to create an image for template: WebBrowser openOn: 'https://pharo-project.github.io/pharo-launcher/create-images/â Any way of doing that ? Cheers, CÃ©drick > Le 17 avr. 2020 Ã 18:08, Christophe Demarey <christophe.demarey(a)inria.fr> a Ã©crit : > > Hi all, > > Pharo Launcher 2.0 has just been released! It is available from http://pharo.org/download <http://pharo.org/download>. > > This new version introduces major changes: > The UI has been fully rewritten using the new Spec2 framework <https://github.com/pharo-spec/Spec> and the Commander2 library <https://github.com/pharo-spec/Commander2>. UI has been revamped to increase usability, especially for newcomers. The main window is now composed of a toolbar and the list of images. The template list is now available when clicking on the new image button. > Documentation web site : All Pharo Launcher features are now explained in the new documentation available at https://pharo-project.github.io/pharo-launcher <https://pharo-project.github.io/pharo-launcher>. You can contribute easily by clicking the *edit on GitHub* button. > You can now have many launch configurations for an image (VM to use, vm and image arguments). It means you can use headless Pharo VM from Pharo Launcher. > When creating a new image, you can specify an initialisation script that will be run once at the first image launch. It is useful to load your project code in a stock Pharo image for example. See https://pharo-project.github.io/pharo-launcher/create-images/#image-initial… <https://pharo-project.github.io/pharo-launcher/create-images/#image-initial…> > You can now define your own template sources in addition to official sources (see https://pharo-project.github.io/pharo-launcher/templates/#create-your-own-l… <https://pharo-project.github.io/pharo-launcher/templates/#create-your-own-l…>), including authenticated sources. > Improved image metadata. Pharo Launcher now manages all image metadata in a single STON file (including description, Pharo version). > > Big thanks to all contributors, including issue reports. It is also the opportunity to thanks Damien Cassou, the original author of Pharo Launcher. > > Here is the changelog: > Pharo Launcher v2.0 <https://github.com/pharo-project/pharo-launcher/releases/tag/2.0> > > The list of closed issue is too long (68) to be listed but you can browse it here: https://github.com/pharo-project/pharo-launcher/issues?q=is%3Aissue+is%3Acl… <https://github.com/pharo-project/pharo-launcher/issues?q=is%3Aissue+is%3Acl…> > Here are some highlights: > New features: > > Documentation web site > Image initialisation script > Launch configurations, headless VM support > User template file in addition to the official template file > Jenkins server template now support pipeline projects > Support of private Jenkins server > Support of authenticated HTTP server > Improvements: > > Monitoring of image launch failures to give back the error message (if any) > Newly created image is automatically selected in the image list > Allow to set image description at creation time > Better error management (you will have the choice to ignore them or debug them) > Add a poor version column in image list > Speedup (especially when image repository has a lot of images) > > Bug fixes: > > Fix use of system unzip on Windows > > Regards, > The Pharo team.

April 18, 2020

[ANN] Pharo Launcher 2.0 released!

by Christophe Demarey

Hi all, Pharo Launcher 2.0 has just been released! It is available from http://pharo.org/download <http://pharo.org/download>. This new version introduces major changes: The UI has been fully rewritten using the new Spec2 framework <https://github.com/pharo-spec/Spec> and the Commander2 library <https://github.com/pharo-spec/Commander2>. UI has been revamped to increase usability, especially for newcomers. The main window is now composed of a toolbar and the list of images. The template list is now available when clicking on the new image button. Documentation web site : All Pharo Launcher features are now explained in the new documentation available at https://pharo-project.github.io/pharo-launcher. You can contribute easily by clicking the *edit on GitHub* button. You can now have many launch configurations for an image (VM to use, vm and image arguments). It means you can use headless Pharo VM from Pharo Launcher. When creating a new image, you can specify an initialisation script that will be run once at the first image launch. It is useful to load your project code in a stock Pharo image for example. See https://pharo-project.github.io/pharo-launcher/create-images/#image-initial… You can now define your own template sources in addition to official sources (see https://pharo-project.github.io/pharo-launcher/templates/#create-your-own-l…) including authenticated sources. Improved image metadata. Pharo Launcher now manages all image metadata in a single STON file (including description, Pharo version). Big thanks to all contributors, including issue reports. It is also the opportunity to thanks Damien Cassou, the original author of Pharo Launcher. Here is the changelog: Pharo Launcher v2.0 <https://github.com/pharo-project/pharo-launcher/releases/tag/2.0> The list of closed issue is too long (68) to be listed but you can browse it here: https://github.com/pharo-project/pharo-launcher/issues?q=is%3Aissue+is%3Acl… Here are some highlights: New features: Documentation web site Image initialisation script Launch configurations, headless VM support User template file in addition to the official template file Jenkins server template now support pipeline projects Support of private Jenkins server Support of authenticated HTTP server Improvements: Monitoring of image launch failures to give back the error message (if any) Newly created image is automatically selected in the image list Allow to set image description at creation time Better error management (you will have the choice to ignore them or debug them) Add a poor version column in image list Speedup (especially when image repository has a lot of images) Bug fixes: Fix use of system unzip on Windows Regards, The Pharo team.

April 17, 2020

[Pharo 9.0] Build #245: 6188-add unit test for announcemen covering issuance from exception handler block

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

There is a new Pharo build available! The status of the build #245 was: FAILURE. The Pull Request #6189 was integrated: "6188-add unit test for announcemen covering issuance from exception handler block" Pull request url: https://github.com/pharo-project/pharo/pull/6189 Issue Url: https://github.com/pharo-project/pharo/issues/6188 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 17, 2020

[Pharo 9.0] Build #244: packagesInDebuggerStackList

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

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

April 17, 2020

[Pharo 9.0] Build #243: morphicCoreDependencies

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

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

April 16, 2020

[Pharo 9.0] Build #242: Integrate Heuristic Completion v3.0.2

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

There is a new Pharo build available! The status of the build #242 was: SUCCESS. The Pull Request #6187 was integrated: "Integrate Heuristic Completion v3.0.2" Pull request url: https://github.com/pharo-project/pharo/pull/6187 Issue Url: https://github.com/pharo-project/pharo/issues/fix/integratecompletion301 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 16, 2020

[Pharo 9.0] Build #241: Try fix #6021

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

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

April 16, 2020

[Pharo 9.0] Build #240: Fix Warning defaultAction

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

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

April 16, 2020

Re: [Pharo-dev] [Esug-list] looking for input for a lecture on TDD and XtremeTDD

by StÃ©phane Ducasse

tx! > On 15 Apr 2020, at 09:44, Stephan Eggermont <stephan(a)stack.nl> wrote: > > Hi Stef, > > Iâve done some workshops and screencasts. In the workshops (oops, already a few years ago) I used a morph that was moving on the screen to emphasize the liveness. The BabyMock2 work by Attila Magyar is also great for that. It also is good to show the difference between Chicago and London style TDD, and connect to BDD. In Smalltalk, that is more represented by the exploratory modeling I was introduced to by Rob Vens. > > https://www.reflektis.nl/blog/exploratory-modelling-explained/ <https://www.reflektis.nl/blog/exploratory-modelling-explained/> > > For a lecture TDD as if you meant is is a good starting point: > > https://cumulative-hypotheses.org/2011/08/30/tdd-as-if-you-meant-it/ <https://cumulative-hypotheses.org/2011/08/30/tdd-as-if-you-meant-it/> > > GToolkit of course provides some nice example-driven development, that combines well with literate programming > > In my latest screencasts I ran into the following issues: > - restarting a test does not make it green after going through it if it needed a fix > - canât step into simple accessors (and other optimized code?) > - in addition to create, need to be able to create/change setUp/initialize/shutDown > - a refactoring âturn fake into classâ is missing where instVar := self and there are methods categorized as âfaking instVarâ > > https://vimeo.com/329317634 <https://vimeo.com/329317634> > > https://vimeo.com/329368348 <https://vimeo.com/329368348> > > Stephan > > Verstuurd vanaf mijn iPhone > >> Op 14 apr. 2020 om 14:36 heeft StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> het volgende geschreven: >> >> ï»¿Hello >> >> I would like to build a lecture around TDD and XtremeTDD (coding in the debugger). >> Iâm looking around to see if someone already did such a lecture. >> >> S. >> -------------------------------------------- >> StÃ©phane Ducasse >> http://stephane.ducasse.free.fr <http://stephane.ducasse.free.fr/> / http://www.pharo.org <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 >> >> _______________________________________________ >> Esug-list mailing list >> Esug-list(a)lists.esug.org >> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / 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

April 15, 2020

[Pharo 9.0] Build #239: CompilerCleanup-hasIncompleteIdentifier

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

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

April 15, 2020

[Pharo 9.0] Build #238: Improve Spacetally perfs and clean code

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

There is a new Pharo build available! The status of the build #238 was: FAILURE. The Pull Request #6177 was integrated: "Improve Spacetally perfs and clean code" Pull request url: https://github.com/pharo-project/pharo/pull/6177 Issue Url: https://github.com/pharo-project/pharo/issues/improveSpaceTallyPerfs Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

April 15, 2020

[Pharo 9.0] Build #237: Pharo project is not the Pharo Launcher project

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

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

April 15, 2020

Re: [Pharo-dev] [Vm-dev] Pony for Pharo VM

by Shaping

Just to get in the right frame of mind, consider that because of the Blub Paradox (http://www.paulgraham.com/avg.html) you are going to have a hard time convincing people to "change to this language because of Feature X" just by saying so. You need to dig deeper. The Pony compiler and runtime need to be studied. Iâm not trying to convince; Iâm presenting facts, observations, and resources for study of the problem and its solution. Hardware constraints now are intensely multicore, and everyone knows this. The changing programming paradigm in apparent. Hardware structure is forcing that change. Convincing yourself will not be difficult when you have the facts. You likely do already, at least on the problem-side. The issue is not whether to use Pony. I donât like Pony, the language; itâs okay, even very good, but itâs not Smalltalk. I like Smalltalk, who concurrency model is painfully lame. I like Orca because it works on many cores (as many as 64, currently) without a synchronization step for GC, and has wonderful concurrency abilities. Pony and Orca were co-designed. The deferred reference counts managed by Orca run on the messages between the actors (send/receive tracing). GCs happen in Pony/Orca when each actor finishes its response to the last received message, and goes idle. The actor then GCs all objects no longer referenced by other actors. The runtime scheduler takes this time needed for each actorâs GCing into account. No actor waits to GC objects. An actorâs allocated objectsâ ref counts are checked at idle-time, and unreferenced objects are GCed in an ongoing, fluid way, in small, high-frequency bursts, with very small, predictable tail latencies, as a result. Thatâs very interesting if you need smoothly running apps (graphics), design/program real-time control systems, or process data at high rates, as in financial applications at banks and exchanges. The issue is how most efficiently to use Orca, which happens to be working in Pony. Pony is in production in two internal, speed-demanding, banking apps and in Wallaroo Labsâ high-rate streaming product. Pony is a convenient way to study and use a working implementation of Orca. Ergo, use Pony, even if we only study it as a good example of how to use Orca. Some tweaks (probably a lot of them) could allow use of dynamic types. We could roll our own implementation of Orca for the current Pharo VM, but that seems like more work than tweaking a working Pony compiler and runtime. Iâm not sure about that. You know the VM better than I. (I was beginning my study of the Pharo/OpenSmalltalkVM when I found Pony.) Now I I took a quick look to see what I could learn about Pony and the main interesting thing is its "Reference Capabilities". Indeed, it seems Pony's purpose is the POC for that research. I watched two videos... [1] Ãredev 2017 - Joe McIlvain - Pony - A Language for Provably Safe Lockless Concurrency https://www.youtube.com/watch?v=9NH4bVfbvYI [2] Sophia Drossopoulou - Pony for Safe, Fast, concurrent programs - Codemesh 2017 https://www.youtube.com/watch?v=e_bES30tFqI So my "quick" assessment is to consider Reference Capabilities not a Type System but a Meta-type System. Yes, ref-caps control sharing of both mutable and immutable objects. [2] says "They are not a property of an object, but define how I can look at an object." To summarize the videos... [1]@29:15... [2]@13:40... [2]@24:40... [2]@28:30... So you say... > I want to use the Pony concurrency model at the Smalltalk level. Thatâs the gist of it. > Otherwise, I want a Smalltalk, not a statically compiled language. I believe you have the wrong end of the the stick promoting that the VM needs to be redeveloped using Pony to get the Reference Capabilities at the Smalltalk level. See my recent response to Ken in vm-dev. After you Ahead-Of-Time compile the VM, the compiler is left behind. The features of the compiler don't automatically flow through to Smalltalk level. Yes. JIT and AOT are needed. Adjustments need to be made for dynamic typing, but such adjustments need not violate invariants needed to provide the ref-cap concurrency guarantees. A third option could be to extend to the existing "Immutability capability" of the VM. Ref-caps control access to both immutable and mutable objects. Pony ascertains at compile time that only one actor at a time can hold a reference to a mutable object at runtime. The six Reference Capabilities might be stored in the Spur Object Header using a re-purposed Immutability bit plus the two free "green" bits. https://clementbera.wordpress.com/2014/01/16/spurs-new-object-format/ We canât use a single big system heap, and also use the actor model and many cores productively. The big heap must go. Thatâs the crux of what we need to learn at this juncture. Iâm not sure everyone is getting this. I donât need to convince you; you can do that for yourself. We donât currently have a better choice of programming model or memory management, if we want maximum speed, and are paying attention to hard constraints. Multicore hardware is here to stay. If you know a way to use your multicore CPUs more efficiently than by use of actor-based programming and Orca memory management, please share your facts. Everyone needs to understand the big-heap problem in order to commit to fine-grain, actor-based (and therefore state-machine-based) programming. We wonât realize productive multicore programming without an actor model. We still need new tools to help, as mentioned, lest our state-machine programming be tedious and painful, causing us to default to old coding habits, and not make the needed state-machines. Iâm working on one of those tools. Orca manages memory as fast as possible in an actor-based program/runtime, without any synchronization. The big-heap problem has been solved for the statically typed case in Pony. The lack of discipline/tools for building state-machines remains a broad problem. Such new tools are therefore essential during the change of programming model. I suggest studying the current Pony/Orca solution (see the Orca paper linked below), to see how it can be tweaked to accommodate dynamic types. Iâve not studied the Pony compiler and runtime enough to be certain, but they may be closer to what we need, even if the first rough implementation of a Smalltalk-with-Orca must be AOT, instead of JIT. We want both ultimately. We should do first whichever is easiest to implement and test in small steps. "Reference Capabilities for Dynamic Languages" could be a strong PhD project. Itâs a good idea. Is this needed to make a Smalltalk that works with Orca? I donât think so. Orca matters more than Pony. But both can be useful to us. Studying the Orca paper and its implementation in the Pony compiler and runtime is the easiest way to understand the constraints imposed by the current static type system in Ponyâand how to change them to accommodate dynamic types. Everyone, please read and study https://www.ponylang.io/media/papers/orca_gc_and_type_system_co-design_for_… if you are interested in building a VM/runtime that guarantees no data-races, and fully uses all your machineâs cores, with the least programming effort. Then study Pony: https://www.ponylang.io/ And ask questions on Pony Zulip: https://ponylang.zulipchat.com/ (BTW, Zulip seems easier to use than Discord and e-mail. Has anyone considered using it for the Pharo/Squeak lists?) Shaping On Fri, 10 Apr 2020 at 17:56, Shaping <shaping(a)uurda.org <mailto:shaping@uurda.org> > wrote: > > Hi Ken. > > Not to discourage people, but I have not seen cases where a "strong > type system would be able to scale for _real_ Smalltalk applications. > > Youâre right. It doesn't. I'm not suggesting that. > > The type safety is not for app-level Smalltalk development. It's for building the VM only. > > The six ref-cap ideas for sharing data reliably between actors are not hard to grasp, but they take some getting used to, and involve some mental load. I don't want that much (concurrency-related or any other) implementation detail in the domain layer, much in the same vein as: I donât use Forth because I donât want to see stack acrobatics (ROTs and DUPs, etc.) amidst domain-level state-changes (FirePhotonTorpedo). Itâs distracting. It dilutes focus on the domain work/layer, and tends to cause mistakes there. > > > > The programmerâs domain logic and the concurrency-integrity provided by the ref-caps are different layers of thought and structure. The ref-caps are, however, mixed freely with domain logic in current Pony code. I think thatâs a mistake. But thatâs how it is now. I think of this layer mixing as an intermediate design stage of Pony. I want to abstract-out some or all ref-caps as the VM is built. > > Pony language is not the remarkable thing here. I see it as a better C or better Rust. Itâs very good (as Algol-60-ish-looking crap-syntaxes go), but thatâs not what this is about. Itâs about the actor programming, the concurrency model, and the guarantees given by use of the ref-caps. We would still obviously need to respect the Pony compilerâs determination of where ref-cap use is correct or not. Your Pony program wonât compile if you donât use the ref-caps correctly, and you donât get the guarantees or a running program without the compile. Much easier, therefore, might be to go the other way by changing Pony to support dynamic types without violating the invariants that allow the ref-caps (under the hood, abstracted out) to make the concurrency guarantees. Work Smalltalk dynamism into Pony, instead of building a Smalltalk VM with Pony.

April 15, 2020

Re: [Pharo-dev] looking for input for a lecture on TDD and XtremeTDD

by Boris Shingarov

April 15, 2020

Re: [Pharo-dev] [Esug-list] looking for input for a lecture on TDD and XtremeTDD

by Stephan Eggermont

Hi Stef, Iâve done some workshops and screencasts. In the workshops (oops, already a few years ago) I used a morph that was moving on the screen to emphasize the liveness. The BabyMock2 work by Attila Magyar is also great for that. It also is good to show the difference between Chicago and London style TDD, and connect to BDD. In Smalltalk, that is more represented by the exploratory modeling I was introduced to by Rob Vens. https://www.reflektis.nl/blog/exploratory-modelling-explained/ For a lecture TDD as if you meant is is a good starting point: https://cumulative-hypotheses.org/2011/08/30/tdd-as-if-you-meant-it/ GToolkit of course provides some nice example-driven development, that combines well with literate programming In my latest screencasts I ran into the following issues: - restarting a test does not make it green after going through it if it needed a fix - canât step into simple accessors (and other optimized code?) - in addition to create, need to be able to create/change setUp/initialize/shutDown - a refactoring âturn fake into classâ is missing where instVar := self and there are methods categorized as âfaking instVarâ https://vimeo.com/329317634 https://vimeo.com/329368348 Stephan Verstuurd vanaf mijn iPhone > Op 14 apr. 2020 om 14:36 heeft StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> het volgende geschreven: > > ï»¿Hello > > I would like to build a lecture around TDD and XtremeTDD (coding in the debugger). > Iâm looking around to see if someone already did such a lecture. > > S. > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr / 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 > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

April 15, 2020