October 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Let's prepare for Google Code-In 2017 with Pharo Consortium

by Jigyasa Grover

Hello Pharo-ers ! On behalf of the community, I would like to thank each one of you for their significant contribution in the recently concluded *Google Summer of Code 2017* with *Pharo Consortium*. We aspire to take-off on a long flight after this successful stint. In this spirit, I proposed at ESUG 2017 that we take part in the upcoming *Google Code-In 2017*. GCI is a contest to introduce pre-university students (ages 13-17) to open source software development. Because Google Code-in is often the first experience many students have with open source, the contest is designed to make it easy for students to jump right in with /bite-sized tasks/ (3 to 5 days) having categorised as: Code, Documentation/Training, Outreach/Research, Quality Assurance, or User Interface. Students search for a task from the list created by us that interests them and claim it. They have at least three days to complete it. The student works on the task, getting guidance from mentors, if needed. Once the student is ready, they submit their work for review through the contest website. Mentors from the organisation evaluate the work, provide feedback, and if it's complete, accept it so that student can claim a new task. Otherwise, specific feedback is provided, and the student goes back to improving it. Participants who complete at least 1 task get a digital certificate. Participants who complete 3 or more tasks receive a t-shirt too. At the end of the contest, each organisation chooses five finalists to receive limited edition Google Code-in hoodies. Two finalists from each organisation get to be the grand prize winners and go on a trip to Google Headquarters in California ! The contest begins for students on November 28, 2017 at 09:00 (PST). *With organisation applications closing on October 24, 2017*, we need to be well prepared for this seasonâs application with a hope to get selected. As an open source evangelist and a Pharo developer, I would like to invite all the experienced members to be a part of the "GCI with Pharo Consortium" Team and mentor students. To get added to the âprivate repositoryâ (we need to keep prospective students away from the task list before the program begins ð ) where you can put in your tasks/suggestions kindly EMail me or any of the previously added mentor. Looking forward to an appreciable representation from the Pharo community. Best regards Jigyasa Grover Pharo Consortium Org Admin, Google Summer of Code 2017 [hidden email] Link to know more about GCI: https://codein.withgoogle.com/archive/ <https://codein.withgoogle.com/archive/ > Link to sample tasks: https://developers.google.com/open-source/gci/resources/example-tasks <https://developers.google.com/open-source/gci/resources/example-tasks> Link to FAQs: https://developers.google.com/open-source/gci/faq <https://developers.google.com/open-source/gci/faq > Link to contest rules: https://developers.google.com/open-source/gci/resources/contest-rules <https://developers.google.com/open-source/gci/resources/contest-rules> Link to GCI presentation for outreach: https://developers.google.com/open-source/gci/resources/downloads/Google-Co… <https://developers.google.com/open-source/gci/resources/downloads/Google-Co…> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 12, 2017

Re: [Pharo-dev] Let's prepare for Google Code-In 2017 with Pharo Consortium

by Jigyasa Grover

Hello Pharo-ers ! On behalf of the community, I would like to thank each one of you for their significant contribution in the recently concluded *Google Summer of Code 2017* with *Pharo Consortium*. We aspire to take-off on a long flight after this successful stint. In this spirit, I proposed at ESUG 2017 that we take part in the upcoming *Google Code-In 2017*. GCI is a contest to introduce pre-university students (ages 13-17) to open source software development. Because Google Code-in is often the first experience many students have with open source, the contest is designed to make it easy for students to jump right in with /bite-sized tasks/ (3 to 5 days) having categorised as: Code, Documentation/Training, Outreach/Research, Quality Assurance, or User Interface. Students search for a task from the list created by us that interests them and claim it. They have at least three days to complete it. The student works on the task, getting guidance from mentors, if needed. Once the student is ready, they submit their work for review through the contest website. Mentors from the organisation evaluate the work, provide feedback, and if it's complete, accept it so that student can claim a new task. Otherwise, specific feedback is provided, and the student goes back to improving it. Participants who complete at least 1 task get a digital certificate. Participants who complete 3 or more tasks receive a t-shirt too. At the end of the contest, each organisation chooses five finalists to receive limited edition Google Code-in hoodies. Two finalists from each organisation get to be the grand prize winners and go on a trip to Google Headquarters in California ! The contest begins for students on November 28, 2017 at 09:00 (PST). With organisation applications closing on October 24, 2017, we need to be well prepared for this seasonâs application with a hope to get selected. As an open source evangelist and a Pharo developer, I would like to invite all the experienced members to be a part of the "GCI with Pharo Consortium" Team and mentor students. To get added to the âprivate repositoryâ (we need to keep prospective students away from the task list before the program begins ð ) where you can put in your tasks/suggestions kindly EMail me or any of the previously added mentor. Looking forward to an appreciable representation from the Pharo community. Best regards Jigyasa Grover Pharo Consortium Org Admin, Google Summer of Code 2017 [hidden email] Link to know more about GCI: https://codein.withgoogle.com/archive/ <https://codein.withgoogle.com/archive/ > Link to sample tasks: https://developers.google.com/open-source/gci/resources/example-tasks <https://developers.google.com/open-source/gci/resources/example-tasks> Link to FAQs: https://developers.google.com/open-source/gci/faq <https://developers.google.com/open-source/gci/faq > Link to contest rules: https://developers.google.com/open-source/gci/resources/contest-rules <https://developers.google.com/open-source/gci/resources/contest-rules> Link to GCI presentation for outreach: https://developers.google.com/open-source/gci/resources/downloads/Google-Co… <https://developers.google.com/open-source/gci/resources/downloads/Google-Co…> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 12, 2017

Re: [Pharo-dev] [Spec] ComposableModel renamed to ComposablePresenter

by Stephane Ducasse

Yes me too and listModel model value killed me On Thu, Oct 12, 2017 at 2:57 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Pavel Krivanek-3 wrote >> To be sure that most of the current code which uses the old name will >> work, >> we created for every renamed class a subclass with the old name. These >> subclasses are moved (mostly) into Spec-Deprecated package. > > Ah, nice trick. Thanks for easing the transition. > > > Pavel Krivanek-3 wrote >> it is necessary to make the Spec code less confusing. > > Sounds good. I often needed a mental pause to translate "model" from "domain > model" to "something modelling a UI on the domain model". > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Oct. 12, 2017

Re: [Pharo-dev] XPath chapter...

by Stephane Ducasse

On Wed, Oct 11, 2017 at 10:43 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > Dont worry Stef you are not alone, I may no longer use Pharo as much I used > to but I will keep stalking you :D > So I have not quit from adding to the pharo documentation. You can at least > expect some video tutorials, minor updated to PBE and minor updates to Pharo > Wiki. thanks this is great > Of course I agree we need more people on this, if every pharo users jusr > dedicated 10 minutes per day on documentations we would have a mind blowing > documentation in quality and quanity. exactly. > 10 minutes is all it takes to update a page of documentation , 100 people, > 100 pages per day. 36.500 pages per year and our documentation needing > updating is not nowhere near this number > > OR > > 10 minutes to write 100 words of documentation (average writting speed is 40 > WPM but I dropped this down to 10 WPM to include research, testing, taking > pictures , general foramt etc) , thats about 1/3rd of a page . 100 people. > 30 pages per day. 10.950 pages per year. so that means with just 100 people > contributing 10 minutes of their time per day we could release around 20 > NEW books per year !!!! > > I am sure Pharo has more than 100 users ;) :) > > On Wed, Oct 11, 2017 at 9:13 AM monty <monty2(a)programmer.net> wrote: >> >> Great effort. The guide is concise and beginner friendly. I emailed you a >> git commit patch you can apply with `git am` (I don't use github) that fixes >> some things and expands on others. >> >> And for the record, I'm not "Monty Kamath" and I don't know him. >> >> > Sent: Sunday, September 24, 2017 at 1:03 PM >> > From: "Stephane Ducasse" <stepharo.self(a)gmail.com> >> > To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> > Subject: [Pharo-dev] XPath chapter... >> > >> > Hi >> > >> > I'm fully convinced that we can have the best language if we do not >> > let people find their way super easily to do what they want to do we >> > will fail. >> > Documentation is KEY and I feel a bit alone. >> > >> > Since I always wanted to learn XPath I started to write a chapter on >> > XPath. I hope that I did not write too many mistakes. >> > >> > Pull requests are welcome here >> > https://github.com/SquareBracketAssociates/Booklet-Scraping >> > >> > I would love to have one booklet on SAX and DOM handling. >> > >> > >> > Stef >> > >> >

Oct. 12, 2017

Re: [Pharo-dev] XPath chapter...

by Stephane Ducasse

Thanks. I do not know which email address you sent you patch because I did not receive it. I do not read emails sent to my gmail account. I do not know how to use git am so I will see because I'm quite terribly busy in this moment. You can also edit directly the file if you can. Stef On Wed, Oct 11, 2017 at 8:13 AM, monty <monty2(a)programmer.net> wrote: > Great effort. The guide is concise and beginner friendly. I emailed you a git commit patch you can apply with `git am` (I don't use github) that fixes some things and expands on others. > > And for the record, I'm not "Monty Kamath" and I don't know him. > >> Sent: Sunday, September 24, 2017 at 1:03 PM >> From: "Stephane Ducasse" <stepharo.self(a)gmail.com> >> To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> Subject: [Pharo-dev] XPath chapter... >> >> Hi >> >> I'm fully convinced that we can have the best language if we do not >> let people find their way super easily to do what they want to do we >> will fail. >> Documentation is KEY and I feel a bit alone. >> >> Since I always wanted to learn XPath I started to write a chapter on >> XPath. I hope that I did not write too many mistakes. >> >> Pull requests are welcome here >> https://github.com/SquareBracketAssociates/Booklet-Scraping >> >> I would love to have one booklet on SAX and DOM handling. >> >> >> Stef >> >

Oct. 12, 2017

Re: [Pharo-dev] CI Build order and strange "latest" Pharo 7 effect

by Torsten Bergmann

Hi Guille, I understand that we want run the pull requests for contributions in parallel. But do we want to run alsoÂ the main build for the daily official relase in parallel to have such side effects? I doubt that. As I wrote it is not only an issue of the file server. The zero conf does not give you the latest although available (which is bad if you want to do the next contribution) and we inform about later build earlier than previous builds, etc. Sure it would be "nice" if our future Pharo 12 would already be available before we release Pharo 7 - but it still is not correct and confuses people ;) So is there anything that can be done to improve/solve this? Thanks T. Am 12.10.2017 um 16:12 schrieb Guillermo Polito: > > > On Thu, Oct 12, 2017 at 4:01 PM, Norbert Hartl <norbert(a)hartl.name > <mailto:norbert@hartl.name>> wrote: > > > > Am 12.10.2017 um 14:23 schrieb Torsten Bergmann <astares(a)gmx.de > <mailto:astares@gmx.de>>: > > > > Hi, > > > > today there was an interesting effect visible for the Pharo > build on CI for Pharo 7: > > > > Esteban merged three contributions for Pharo 7 into #development > (see [1]). All three merges on git triggered the CI. > > For each a separate build for Pharo 7 started on CI independently. > > > > While usually one would expect the builds in regular build order > 183, 184, 185 the CI job for building 185 job was faster > > (as you can see on the attached screenshot). > > > > So the 185 series of images was copied first to the file server > [3] because the job was already finished. > > Afterwards 183 build completed on CI and these images were > copied to the file server with a newer timestamp. > > > > So you have the order 185, 183 with 183 having the files with > the newest timestamp (but not being the most recent state of Pharo). > > > > This leads to several unfortunate effects: > >Â 1. When you sort on file server [3] descending by date the > build 183 images are newer than the build 185 images > >Â 2. When you use PharoLauncher to download "latest-32" you get > an 183 image instead of the "real latest" 185 image > >Â 3. When you ask Zeroconf to download the latest using > http://get.pharo.org/70+vm you also get 183 instead of the already > >Â Â Â available 185 > > > > So as the CI build of an older "update" (here 183) finished > later than the most recent version (here 185) > > you get 183 as "latest" instead of 185. > > > > Any ideas how we could avoid such a side effect? Maybe a chain > on the builds so 183 has to finished before 184 and 185 could be > > built? > > > I don't understand why it is working like this. Usually only build > for a job is active, others will be queued. So the problem here is > that > the jenkins spawns more builds in parallel for the same job. > > > Yes, the thing is that the same job is being used to build the > development branch and the pull requests. > If you think about it, this is the same setup as in travis. > > The thing is that this does not bother me too much, considering the > tradeoffs. > > - I want pull request to run in parallel. > - I want to have less things to maintain :) > > Now, > Â - we could split the job in two (integration vs pr validation). But > this requires setting up a separate jenkins because otherwise they > share the same slave configuration :/. And there is no way in the > actual state of the plugins we use to limit the number of parallel > builds... > Â - we could try to make a build wait until a build with lower build > number is building... > Â - we could also forbid Esteban to push on the merge button while a > build is running > But doing any of those is a lot of work... > > - Moreover, I think the problem is that we are using the file server > as something it is not. The file server is... a file server. > Ideally, I'd like to attach meta-data to a release/build artifact, and > be able to browse/search/sort using that metadata. Something alike > artifactory or bintray. > > - Also, I don't know how the pharo launcher is getting the latest > image, but if instead of using the file timestamp it uses the build > number, then this may be fixed, isn't it? > > > Norbert > > > Thx > > T. > > > > > > > > [1] https://github.com/pharo-project/pharo/commits/development > <https://github.com/pharo-project/pharo/commits/development> > > [2] > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> > > [3] http://files.pharo.org/image/70/ > <http://files.pharo.org/image/70/> > > <buildOrder.png> > > > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - _http://www.cnrs.fr_ > > > *Web:* _http://guillep.github.io_ > > *Phone: *+33 06 52 70 66 13 >

Oct. 12, 2017

[Pharo 7.0-dev] Build #187: 20524-ExecuteTree-method-comment

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

There is a new Pharo build available! The status of the build #187 was: SUCCESS. The Pull Request #349 was integrated: "20524-ExecuteTree-method-comment" Pull request url: https://github.com/pharo-project/pharo/pull/349 Issue Url: https://pharo.fogbugz.com/f/cases/20524 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 12, 2017

[Pharo 7.0-dev] Build #186: 20509 MD5Test, SHA1Test, SHA256Test should be moved to a new package "System-Hashing-Tests"

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

There is a new Pharo build available! The status of the build #186 was: SUCCESS. The Pull Request #345 was integrated: "20509 MD5Test, SHA1Test, SHA256Test should be moved to a new package "System-Hashing-Tests"" Pull request url: https://github.com/pharo-project/pharo/pull/345 Issue Url: https://pharo.fogbugz.com/f/cases/20509 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 12, 2017

Re: [Pharo-dev] CI Build order and strange "latest" Pharo 7 effect

by Guillermo Polito

On Thu, Oct 12, 2017 at 4:01 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > > > Am 12.10.2017 um 14:23 schrieb Torsten Bergmann <astares(a)gmx.de>: > > > > Hi, > > > > today there was an interesting effect visible for the Pharo build on CI > for Pharo 7: > > > > Esteban merged three contributions for Pharo 7 into #development (see > [1]). All three merges on git triggered the CI. > > For each a separate build for Pharo 7 started on CI independently. > > > > While usually one would expect the builds in regular build order 183, > 184, 185 the CI job for building 185 job was faster > > (as you can see on the attached screenshot). > > > > So the 185 series of images was copied first to the file server [3] > because the job was already finished. > > Afterwards 183 build completed on CI and these images were copied to the > file server with a newer timestamp. > > > > So you have the order 185, 183 with 183 having the files with the newest > timestamp (but not being the most recent state of Pharo). > > > > This leads to several unfortunate effects: > > 1. When you sort on file server [3] descending by date the build 183 > images are newer than the build 185 images > > 2. When you use PharoLauncher to download "latest-32" you get an 183 > image instead of the "real latest" 185 image > > 3. When you ask Zeroconf to download the latest using > http://get.pharo.org/70+vm you also get 183 instead of the already > > available 185 > > > > So as the CI build of an older "update" (here 183) finished later than > the most recent version (here 185) > > you get 183 as "latest" instead of 185. > > > > Any ideas how we could avoid such a side effect? Maybe a chain on the > builds so 183 has to finished before 184 and 185 could be > > built? > > > I don't understand why it is working like this. Usually only build for a > job is active, others will be queued. So the problem here is that > the jenkins spawns more builds in parallel for the same job. > Yes, the thing is that the same job is being used to build the development branch and the pull requests. If you think about it, this is the same setup as in travis. The thing is that this does not bother me too much, considering the tradeoffs. - I want pull request to run in parallel. - I want to have less things to maintain :) Now, - we could split the job in two (integration vs pr validation). But this requires setting up a separate jenkins because otherwise they share the same slave configuration :/. And there is no way in the actual state of the plugins we use to limit the number of parallel builds... - we could try to make a build wait until a build with lower build number is building... - we could also forbid Esteban to push on the merge button while a build is running But doing any of those is a lot of work... - Moreover, I think the problem is that we are using the file server as something it is not. The file server is... a file server. Ideally, I'd like to attach meta-data to a release/build artifact, and be able to browse/search/sort using that metadata. Something alike artifactory or bintray. - Also, I don't know how the pharo launcher is getting the latest image, but if instead of using the file timestamp it uses the build number, then this may be fixed, isn't it? > > Norbert > > > Thx > > T. > > > > > > > > [1] https://github.com/pharo-project/pharo/commits/development > > [2] https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending% > 20pull%20request%20and%20branch%20Pipeline/job/development > > [3] http://files.pharo.org/image/70/ > > <buildOrder.png> > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Oct. 12, 2017

Re: [Pharo-dev] CI Build order and strange "latest" Pharo 7 effect

by Norbert Hartl

> Am 12.10.2017 um 14:23 schrieb Torsten Bergmann <astares(a)gmx.de>: > > Hi, > > today there was an interesting effect visible for the Pharo build on CI for Pharo 7: > > Esteban merged three contributions for Pharo 7 into #development (see [1]). All three merges on git triggered the CI. > For each a separate build for Pharo 7 started on CI independently. > > While usually one would expect the builds in regular build order 183, 184, 185 the CI job for building 185 job was faster > (as you can see on the attached screenshot). > > So the 185 series of images was copied first to the file server [3] because the job was already finished. > Afterwards 183 build completed on CI and these images were copied to the file server with a newer timestamp. > > So you have the order 185, 183 with 183 having the files with the newest timestamp (but not being the most recent state of Pharo). > > This leads to several unfortunate effects: > 1. When you sort on file server [3] descending by date the build 183 images are newer than the build 185 images > 2. When you use PharoLauncher to download "latest-32" you get an 183 image instead of the "real latest" 185 image > 3. When you ask Zeroconf to download the latest using http://get.pharo.org/70+vm you also get 183 instead of the already > available 185 > > So as the CI build of an older "update" (here 183) finished later than the most recent version (here 185) > you get 183 as "latest" instead of 185. > > Any ideas how we could avoid such a side effect? Maybe a chain on the builds so 183 has to finished before 184 and 185 could be > built? > I don't understand why it is working like this. Usually only build for a job is active, others will be queued. So the problem here is that the jenkins spawns more builds in parallel for the same job. Norbert > Thx > T. > > > > [1] https://github.com/pharo-project/pharo/commits/development > [2] https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > [3] http://files.pharo.org/image/70/ > <buildOrder.png>

Oct. 12, 2017