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

Re: [Pharo-dev] State of files.pharo.org

by Gabriel Cotelli

I've added my testing info in the shared notepad. The download of Pharo6.0-linux.zip took 11m 33s on a 30Mbps connection (I've looked while it was downloading and for the first half it was downloading at 40/50 Kbs), so I think it's representative of the slowness we get. As I previously said it's not always slow, sometimes I works fine. Regards, Gabriel On Fri, Oct 6, 2017 at 11:07 AM, Christophe Demarey < christophe.demarey(a)inria.fr> wrote: > Hello, > > I just finished the meeting with a guy from Inria datacenter. > From Inria, we do not see any problem with files.pharo.org. We do not > have tools ready to simulate poor networks nor remote network sensors > available :( > Thatâs why if some of you could help to collect some data to guess what is > the problem, it would be great: If you can run the commands listed there: > https://pad.inria.fr/p/IvdGLh650VN8lkoN and also put the results at the > bottom of the page, it would be very helpful. > In the same time, I created a project on github to run these command on > travis CI: https://travis-ci.org/demarey/test-files-pharo-org. > With all this data, I hope they can spot the problem quickly. > > Thanks, > Christophe >

Oct. 6, 2017

Re: [Pharo-dev] Never-ending computations and cmd-dot

by Guillermo Polito

On Fri, Oct 6, 2017 at 4:52 PM, HernÃ¡n Morales Durand < hernan.morales(a)gmail.com> wrote: > Hi Guille > > 2017-10-03 9:15 GMT-03:00 Guillermo Polito <guillermopolito(a)gmail.com>: > >> I've been bitten by this dozens of times. >> >> The problem seems to be that a second UI process is created and thus the >> DNU exception is automatically resumed (indefinitely). Executing the >> following expression seems to remove the problem: >> >> UIManager default spawnNewProcess >> >> > Thanks. > > That expression prevents the recursive exception windows from opening? Or > it is a post-mortem measure? > It's for once "you have the problem". As you may notice, usually when you have an exception you'll be given a debugger. This infinite debugger bug happens really occasionally. I use that expression to fix my system, but still don't know what makes it go nuts :( > So it should be executed at image startup? > > I will check. > > > > >> Still, I do not know the cause of it. >> >> On Wed, Sep 27, 2017 at 4:28 AM, Stephane Ducasse < >> stepharo.self(a)gmail.com> wrote: >> >>> Hi hernan >>> >>> Indeed it would be nice to have a solution for such case. Now we did >>> not look at it. >>> >>> Stef >>> >>> On Tue, Sep 26, 2017 at 5:58 AM, HernÃ¡n Morales Durand >>> <hernan.morales(a)gmail.com> wrote: >>> > Hi Tim, >>> > >>> > Yes, I am aware of such menu item. However I would like to know if >>> > someone is working in a more architectural solution. >>> > Because I guess this would imply to hook message sends into the main >>> > feedback loop. >>> > >>> > Cheers, >>> > >>> > HernÃ¡n >>> > >>> > >>> > 2017-09-25 20:08 GMT-03:00 Tim Mackinnon <tim(a)testit.works>: >>> >> Its not quite what you are asking for, but if you right click on one >>> of those windows, someone has helpfully added a âclose all windows to >>> rightâ option, which does let you rapidly get rid of them. >>> >> >>> >> Tim >>> >> >>> >>> On 25 Sep 2017, at 23:16, HernÃ¡n Morales Durand < >>> hernan.morales(a)gmail.com> wrote: >>> >>> >>> >>> Hi, >>> >>> >>> >>> Guys I have the situation you will recognize in the attached picture: >>> >>> A never-ending recursive computation which generate zillions of >>> >>> pre-debug windows when cmd-dot key is pressed. >>> >>> >>> >>> Is there any setting, or any way to put a monitor to detect that >>> >>> cmd-dot is creating too many windows so will pop-up just one or two? >>> >>> Maybe someone researched this issue, does it makes sense? >>> >>> >>> >>> Cheers, >>> >>> >>> >>> HernÃ¡n >>> >>> <rw.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 <+33%206%2052%2070%2066%2013> >> > > -- 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. 6, 2017

Re: [Pharo-dev] Never-ending computations and cmd-dot

by HernÃ¡n Morales Durand

Hi Guille 2017-10-03 9:15 GMT-03:00 Guillermo Polito <guillermopolito(a)gmail.com>: > I've been bitten by this dozens of times. > > The problem seems to be that a second UI process is created and thus the > DNU exception is automatically resumed (indefinitely). Executing the > following expression seems to remove the problem: > > UIManager default spawnNewProcess > > Thanks. That expression prevents the recursive exception windows from opening? Or it is a post-mortem measure? So it should be executed at image startup? I will check. > Still, I do not know the cause of it. > > On Wed, Sep 27, 2017 at 4:28 AM, Stephane Ducasse <stepharo.self(a)gmail.com > > wrote: > >> Hi hernan >> >> Indeed it would be nice to have a solution for such case. Now we did >> not look at it. >> >> Stef >> >> On Tue, Sep 26, 2017 at 5:58 AM, HernÃ¡n Morales Durand >> <hernan.morales(a)gmail.com> wrote: >> > Hi Tim, >> > >> > Yes, I am aware of such menu item. However I would like to know if >> > someone is working in a more architectural solution. >> > Because I guess this would imply to hook message sends into the main >> > feedback loop. >> > >> > Cheers, >> > >> > HernÃ¡n >> > >> > >> > 2017-09-25 20:08 GMT-03:00 Tim Mackinnon <tim(a)testit.works>: >> >> Its not quite what you are asking for, but if you right click on one >> of those windows, someone has helpfully added a âclose all windows to >> rightâ option, which does let you rapidly get rid of them. >> >> >> >> Tim >> >> >> >>> On 25 Sep 2017, at 23:16, HernÃ¡n Morales Durand < >> hernan.morales(a)gmail.com> wrote: >> >>> >> >>> Hi, >> >>> >> >>> Guys I have the situation you will recognize in the attached picture: >> >>> A never-ending recursive computation which generate zillions of >> >>> pre-debug windows when cmd-dot key is pressed. >> >>> >> >>> Is there any setting, or any way to put a monitor to detect that >> >>> cmd-dot is creating too many windows so will pop-up just one or two? >> >>> Maybe someone researched this issue, does it makes sense? >> >>> >> >>> Cheers, >> >>> >> >>> HernÃ¡n >> >>> <rw.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. 6, 2017

[Pharo 7.0-dev] Build #172: 20494-update-Epicea-to-version-8-2-5

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

There is a new Pharo build available! The status of the build #172 was: SUCCESS. The Pull Request #332 was integrated: "20494-update-Epicea-to-version-8-2-5" Pull request url: https://github.com/pharo-project/pharo/pull/332 Issue Url: https://pharo.fogbugz.com/f/cases/20494 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 6, 2017

[Pharo 7.0-dev] Build #171: 20309 - Startup should run always in a fresh process

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

There is a new Pharo build available! The status of the build #171 was: SUCCESS. The Pull Request #198 was integrated: "20309 - Startup should run always in a fresh process" Pull request url: https://github.com/pharo-project/pharo/pull/198 Issue Url: https://pharo.fogbugz.com/f/cases/20309 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 6, 2017

Re: [Pharo-dev] State of files.pharo.org

by Christophe Demarey

Hello, I just finished the meeting with a guy from Inria datacenter. >From Inria, we do not see any problem with files.pharo.org. We do not have tools ready to simulate poor networks nor remote network sensors available :( Thatâs why if some of you could help to collect some data to guess what is the problem, it would be great: If you can run the commands listed there: https://pad.inria.fr/p/IvdGLh650VN8lkoN and also put the results at the bottom of the page, it would be very helpful. In the same time, I created a project on github to run these command on travis CI: https://travis-ci.org/demarey/test-files-pharo-org. With all this data, I hope they can spot the problem quickly. Thanks, Christophe

Oct. 6, 2017

Re: [Pharo-dev] State of files.pharo.org

by Ben Coman

Often the problem is not that they cannot find a reason why, but before that, they cannot even see it, i.e. they can't put the hands around it. Its human nature that we deal with the world through our own experiences. If a problem can't be seen, how can it be solved. Without know what actions they may have tries, I'd generally say it seems that it can't be solved with local testing since that is a different environment. Ideally your DevOps guys could get on a machine in a remote corner of the world exhibiting the problem, to help them "see" the problem. That said, right now for me from different location its not too bad. Perhaps it only get in a twist with lagged/dropped packets on poor networks. Do they test using tools to simulate poor networks? * https://stackoverflow.com/questions/130354/how-do-i-simulate-a-low-bandwidt… * https://www.hanselman.com/blog/HowToSimulateALowBandwidthConnectionForTesti… cheers -ben On Fri, Oct 6, 2017 at 4:12 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > We have to circumvent the DevOp mental model :) From their point of view > it goes like this > > "I cannot find a reason why it shouldn't workâ¦.so it should. Ticket > closed!" > > Just ignoring the little effect THAT.IT.DOES.NOT.WORK > > Same story everywhere :) > > Norbert > > > Am 06.10.2017 um 10:01 schrieb Stephane Ducasse <stepharo.self(a)gmail.com > >: > > > > Thanks Christophe because Peter reported the same when I visiting him > > and this is slowly killing us. > > > > On Thu, Oct 5, 2017 at 2:18 PM, Christophe Demarey > > <christophe.demarey(a)inria.fr> wrote: > >> > >> Le 5 oct. 2017 Ã 13:50, Marcus Denker <marcus.denker(a)inria.fr> a Ã©crit > : > >> > >> > >> > >> On 5 Oct 2017, at 13:35, Norbert Hartl <norbert(a)hartl.name> wrote: > >> > >> I'm trying to download images from files.pharo.org. Either it takes a > lot of > >> time or get something like > >> > >> Downloading the latest 70 Image: > >> http://files.pharo.org/get-files/70/pharo.zip > >> error: invalid compressed data to inflate > >> image.7vLfZK/Pharo7.0-32bit-6bff78c.image > >> image.7vLfZK/Pharo7.0-32bit-6bff78c.sources bad CRC 724d27ab (should > be > >> f4d1baa8) > >> > >> That is really sad. What use is this wonderful environment if nobody can > >> download it? We need to sort that out. > >> > >> So is this hosted in Inria data center? > >> > >> > >> Yes, and the admins can not find any problem. They closed the ticket I > >> opened, but there is a new > >> ticket open since last weekâ¦ not a good situation. > >> > >> > >> Yes, it is hosted at Inria datacenter. > >> They are investigating the problem. I have an audio conf with them > tomorrow > >> on this pb. I will give a feedback after this meeting. > >> > >> Christophe > >> > >> > >

Oct. 6, 2017

[Ann] PharoLauncher v1.0.1 released!

by Christophe Demarey

Hi all, I just released a new version of the PharoLauncher 1.0.1. Here are major improvements since last version: Pharo launcher is now distributed with a Pharo 60 image with a 32-bits threaded VM (to avoid hangs when using OSProcess). Add a VM management utility able to find (and download) the appropriate VM for a given image. So, the launcher is NOT shipped anymore with an extra VM. It will fetch required VM when needed. Pharo Launcher files (images, VMs) are now considered as user Documents (easier to find). Consequently, they are now stored in the standard documents folder, i.e. $HOME/Documents/Pharo on OS X, $HOME/My Documents/Pharo on windows, $HOME/Pharo on Linux (some linux distributions provide a document folder but some others not, so we put it in the HOME directory in all cases). In this folder, you will find your images and virtual machines needed to run images. Use of ProcessWrapper to run images on Windows. Adds download of sources file for Pharo images > 60. Left panel is now used for official images and Jenkins jobs templates and right panel is used for local images. New mooc entry with the image ready to start the Pharo Mooc. New deprecated category to find old official Pharo images. Use system unzip when possible (Pharo unzip does not manage file permissions nor symbolic links). You can get platform bundles from files.pharo.org: Os X: http://files.pharo.org/platform/launcher/Pharo_1.0.1.dmg Windows: http://files.pharo.org/platform/launcher/pharo_installer-1.0.1.exe Linux: http://files.pharo.org/platform/launcher/Pharo-linux-1.0.1.zip Enjoy, Christophe. For those wanted more info on how the adequate VM is computed, here is the process: determine the image format version find (and optionnaly fetch) a compatible VM (a VM able to run this image format) and run the image to get its Pharo version number find (and optionnaly fetch) the appropriate VM for this specific Pharo image version. Sources files are also downloaded with the VM when applicable. run the image with the appropriate VM

Oct. 6, 2017

[Pharo 7.0-dev] Build #169: 20491-Epica-recovery-dialog-always-on-the-image-start-up

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

There is a new Pharo build available! The status of the build #169 was: SUCCESS. The Pull Request #331 was integrated: "20491-Epica-recovery-dialog-always-on-the-image-start-up" Pull request url: https://github.com/pharo-project/pharo/pull/331 Issue Url: https://pharo.fogbugz.com/f/cases/20491 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 6, 2017

[Pharo 7.0-dev] Build #170: 20480-Runable-Example-label-is-mis-spelled

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

There is a new Pharo build available! The status of the build #170 was: SUCCESS. The Pull Request #333 was integrated: "20480-Runable-Example-label-is-mis-spelled" Pull request url: https://github.com/pharo-project/pharo/pull/333 Issue Url: https://pharo.fogbugz.com/f/cases/20480 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 6, 2017