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

Re: [Pharo-dev] Esteban's ChangeLog week of 21 August 2017

by Tim Mackinnon

I also look forward each week to read your progress - far from boring, it's inspiring. I like the format too - it's like a modern diary ; My thanks added to the list! Tim Sent from my iPhone > On 29 Aug 2017, at 10:34, philippe.back(a)highoctane.be <philippe.back(a)gmail.com> wrote: > > > > On Aug 28, 2017 6:11 PM, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > EstebanLM wrote > > This is my weekly ChangeLog, from 21 August 2017 to 27 August 2017. > > Thank you for all the work you consistently do, especially the stuff deep > down in the system which brings no personal glory but provides the > foundation for the creations of our entire community! > > I beg to differ as what is done there is actually glorious and deeply appreciated from where I do stand. > > Esteban, Master of Code (level: 10K). > > Phil > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Esteban-s-ChangeLog-week-of-21-August-2017-tp4964905p… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Aug. 30, 2017

Github notifications for pharo-project redirected to pharo-dev

by Esteban Lorenzano

Hi, I added pharo-dev mail as my notification address on pharo-project so list is informed of what is happening. now, this can be a lot (because I receive a lot of mails). So weâll see (at least you will have a glimpse of a small part what I have to deal everyday ;) ) If this does not work I will create a fake user just to suscribe to the projects we want :) cheers, Esteban

Aug. 30, 2017

Re: [Pharo-dev] [GitHub] Please verify your email address.

by Esteban Lorenzano

do NOT answer this :) Iâm playing with notifications from github to pharo-dev :) Esteban > On 30 Aug 2017, at 09:43, GitHub <noreply(a)github.com> wrote: > > Hi @estebanlm! > > Help us secure your GitHub account by verifying your email address (pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org>). This will let you receive notifications and password resets from GitHub. > > Verify email address <https://github.com/users/estebanlm/emails/36063542/confirm_verification/3bb…> > Button not working? Paste the following link into your browser: > https://github.com/users/estebanlm/emails/36063542/confirm_verification/3bb… <https://github.com/users/estebanlm/emails/36063542/confirm_verification/3bb…> > Youâre receiving this email because you recently created a new GitHub account or added a new email address. If this wasnât you, please ignore this email. >

Aug. 30, 2017

[GitHub] Please verify your email address.

by GitHub

Hi @estebanlm! Help us secure your GitHub account by verifying your email address (pharo-dev(a)lists.pharo.org) This will let you receive notifications and password resets from GitHub. Click the link below to verify your email address: https://github.com/users/estebanlm/emails/36063542/confirm_verification/3bb… Youâre receiving this email because you recently created a new GitHub account or added a new email address. If this wasnât you, please ignore this email. --- Sent with <3 by GitHub. GitHub, Inc. 88 Colin P Kelly Jr Street San Francisco, CA 94107

Aug. 30, 2017

Re: [Pharo-dev] poor state of fuel

by Tim Mackinnon

Actually in my case they are similar but not identical images. The Lambda image is a minimal early 7.0 one - but it is beforecthe massive reworks that were announced. On top of this it has my project loaded. The OS X image is a fat 6.1 with the same project loaded. (So a superset). I am saving the walkback context. Fuel warns that images need to be similar for it to map objects - so my scenario fits that (the same image would be easier I assume). Tim Sent from my iPhone > On 29 Aug 2017, at 23:58, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > >> On 8/29/17, Tim Mackinnon <tim(a)testit.works> wrote: >> As a small data point, a fuel file written out on AWS Lambda Linux (not sure >> what version - I think it's an ubuntu, but they don't really say), is >> readable on OS X 64bit . > > By the same image or a different one? > > --Hannes > >> So it seems like you must have found something unusual. >> >> Tim >> >> Sent from my iPhone >> >>> On 29 Aug 2017, at 11:13, Max Leske <maxleske(a)gmail.com> wrote: >>> >>> Hi Norbert, >>> >>> We still maintain Fuel. >>> >>> I was not aware of the problem you describe. Could you open an issue on >>> github (https://github.com/theseion/Fuel/issues) with a detailed >>> explanation and, if possible, steps to reproduce the problem? >>> >>> Cheers, >>> Max >>> >>>> On 29 August 2017 at 11:04:34, Norbert Hartl (norbert(a)hartl.name) wrote: >>>> >>>> I'm migrating most of my projects to pharo 6.1 at the moment. I come from >>>> pharo 4, I skipped pharo 5. I use 64 bit which removes a lot of stuff >>>> that does not need to be installed and makes deployment better. That >>>> really feels much better. >>>> >>>> I use jenkins and there if a test fails a fuel dump is written to disk. >>>> The jenkins server is ubuntu linux with the vm of the opensuse build. My >>>> laptop has Mac OS and cannot read back those fuel dumps. I use the same >>>> image version on jenkins and my laptop. Both are 64bit. >>>> >>>> I asked that on discord and there was a mentioning that not only the 64 >>>> bit fuel has problems. So I wanted to ask what is the state of fuel right >>>> now. I consider fuel one of the core technologies in pharo and it is sad >>>> if it just stops working. >>>> >>>> Any feedback is highly appreciated, >>>> >>>> Norbert >>>> >> >

Aug. 30, 2017

Re: [Pharo-dev] poor state of fuel

by H. Hirzel

On 8/29/17, Tim Mackinnon <tim(a)testit.works> wrote: > As a small data point, a fuel file written out on AWS Lambda Linux (not sure > what version - I think it's an ubuntu, but they don't really say), is > readable on OS X 64bit . By the same image or a different one? --Hannes > So it seems like you must have found something unusual. > > Tim > > Sent from my iPhone > >> On 29 Aug 2017, at 11:13, Max Leske <maxleske(a)gmail.com> wrote: >> >> Hi Norbert, >> >> We still maintain Fuel. >> >> I was not aware of the problem you describe. Could you open an issue on >> github (https://github.com/theseion/Fuel/issues) with a detailed >> explanation and, if possible, steps to reproduce the problem? >> >> Cheers, >> Max >> >>> On 29 August 2017 at 11:04:34, Norbert Hartl (norbert(a)hartl.name) wrote: >>> >>> I'm migrating most of my projects to pharo 6.1 at the moment. I come from >>> pharo 4, I skipped pharo 5. I use 64 bit which removes a lot of stuff >>> that does not need to be installed and makes deployment better. That >>> really feels much better. >>> >>> I use jenkins and there if a test fails a fuel dump is written to disk. >>> The jenkins server is ubuntu linux with the vm of the opensuse build. My >>> laptop has Mac OS and cannot read back those fuel dumps. I use the same >>> image version on jenkins and my laptop. Both are 64bit. >>> >>> I asked that on discord and there was a mentioning that not only the 64 >>> bit fuel has problems. So I wanted to ask what is the state of fuel right >>> now. I consider fuel one of the core technologies in pharo and it is sad >>> if it just stops working. >>> >>> Any feedback is highly appreciated, >>> >>> Norbert >>> >

Aug. 29, 2017

Use less CPU (improve battery life or reduce cost in the cloud)

by Holger Freyther

Hi, I have done some early prototype for the Unix VM end of 2015(?) and I have improved and repeated these for MacOS now and the thread based heartbeat (now that it is the universal default). I won't make it to ESUG this year but this might be something to play with? The motivations is simple: Polling increases the CPU usage which will reduce your battery life, takes away resources from other processes (e.g. more Pharo images) or these days increases your cloud computing bill. On top of that it might increase network latency (time from socket becoming readable to the time the semaphore is signaled). To complete the work we have work inside the Image and the VM and some of it is on the way and others might need more discussion. The idle process: ProcessorScheduler>># idleProcess "A default background process which is invisible." [true] whileTrue: [self relinquishProcessorForMicroseconds: 1000] Let's please yield the CPU for more than a 1ms. Unless I am missing something an expired Delay or network IO would make us wake up earlier anyway? The delay scheduler: The VM supports that when the next wake-up time is set to 0, the VM can sleep indefinitely. There is a pending patch to sleep "0" in our Delay scheduler. Currently we force a wake-up earlier than that. I think we should trust the VM to do wake us up even if it is a second away. Morphic UI: I don't understand the WorldState>>#interCyclePause but then I never looked at Morphic. Do we really need to poll like that? Under which circumstances does the world update? We get an event (where we have the event semaphore), we get some I/O (where we have a semaphore) or we have a timeout (where we sleep on a semaphore). Did anyone ever look at removing the tick? VM I/O: Currently we receive a SIGIO but from what I can see (and I still need to write a benchmark) the processing might be delayed 20ms? My hack removes the usage of nextPollUsecs and instead checks a variable that is set by the SIGIO handler. Besides missing memory barriers this should work(tm). The biggest issue seems that for macos/ios the input is driven by polling. E.g. some wheel events seem to require to pump the event queue. Is this something we could trigger from the image in the future? I had hoped to get a fd to a machport we could get SIGIO for.. but that doesn't seem to exist. I have hacked out the honoring of the relinquish delay, added the polling into a iOS specific routine and thanks to the Morphic Delay we bump the event loop frequently enough. VM heartbeat thread: The process keeps ticking even if the VM doesn't run. E.g. sleeps and waits for an event. There is a cost in deciding when to halt the thread so there must be a cut-off for which delays we bother to disable the heartbeat thread. I think the current code would allow the hearbeat to drift so the new code might just make it a bit worse. Where are we now? I have pushed my changes to https://github.com/zecke/opensmalltalk-vm/tree/mac-use-less-cpu and would be happy to have people look at it, look at the memory synchronization, maybe run to see if they notice extra delays or such? I started the same image with the plain-vm and my hacked one and let it run for about 20min. The output is coming from top. COMMAND %CPU TIME Pharo 4.3 00:48.49 Pharo 0.8 00:10.20 Looking for comments and feedback. regards holger

Aug. 29, 2017

Re: [Pharo-dev] poor state of fuel

by Dimitris Chloupis

I am a big fan of Fuel myself. It looks very well designed and is easy to use :) On Tue, Aug 29, 2017 at 10:45 PM Max Leske <maxleske(a)gmail.com> wrote: > And hereâs the link to the issue, for completeness: > https://github.com/theseion/Fuel/issues/224 > > Max > > > > On 29 August 2017 at 16:09:06, Tim Mackinnon (tim(a)testit.works) wrote: > > As a small data point, a fuel file written out on AWS Lambda Linux (not > sure what version - I think it's an ubuntu, but they don't really say), is > readable on OS X 64bit . > > So it seems like you must have found something unusual. > > Tim > > Sent from my iPhone > > On 29 Aug 2017, at 11:13, Max Leske <maxleske(a)gmail.com> wrote: > > Hi Norbert, > > We still maintain Fuel. > > I was not aware of the problem you describe. Could you open an issue on > github (https://github.com/theseion/Fuel/issues) with a detailed > explanation and, if possible, steps to reproduce the problem? > > Cheers, > Max > > On 29 August 2017 at 11:04:34, Norbert Hartl (norbert(a)hartl.name) wrote: > > I'm migrating most of my projects to pharo 6.1 at the moment. I come from > pharo 4, I skipped pharo 5. I use 64 bit which removes a lot of stuff that > does not need to be installed and makes deployment better. That really > feels much better. > > I use jenkins and there if a test fails a fuel dump is written to disk. > The jenkins server is ubuntu linux with the vm of the opensuse build. My > laptop has Mac OS and cannot read back those fuel dumps. I use the same > image version on jenkins and my laptop. Both are 64bit. > > I asked that on discord and there was a mentioning that not only the 64 > bit fuel has problems. So I wanted to ask what is the state of fuel right > now. I consider fuel one of the core technologies in pharo and it is sad if > it just stops working. > > Any feedback is highly appreciated, > > Norbert > >

Aug. 29, 2017

Re: [Pharo-dev] poor state of fuel

by Max Leske

And hereâs the link to the issue, for completeness: https://github.com/theseion/Fuel/issues/224 Max On 29 August 2017 at 16:09:06, Tim Mackinnon (tim(a)testit.works) wrote: As a small data point, a fuel file written out on AWS Lambda Linux (not sure what version - I think it's an ubuntu, but they don't really say), is readable on OS X 64bit . So it seems like you must have found something unusual. Tim Sent from my iPhone On 29 Aug 2017, at 11:13, Max Leske <maxleske(a)gmail.com> wrote: Hi Norbert, We still maintain Fuel. I was not aware of the problem you describe. Could you open an issue on github (https://github.com/theseion/Fuel/issues) with a detailed explanation and, if possible, steps to reproduce the problem? Cheers, Max On 29 August 2017 at 11:04:34, Norbert Hartl (norbert(a)hartl.name) wrote: I'm migrating most of my projects to pharo 6.1 at the moment. I come from pharo 4, I skipped pharo 5. I use 64 bit which removes a lot of stuff that does not need to be installed and makes deployment better. That really feels much better. I use jenkins and there if a test fails a fuel dump is written to disk. The jenkins server is ubuntu linux with the vm of the opensuse build. My laptop has Mac OS and cannot read back those fuel dumps. I use the same image version on jenkins and my laptop. Both are 64bit. I asked that on discord and there was a mentioning that not only the 64 bit fuel has problems. So I wanted to ask what is the state of fuel right now. I consider fuel one of the core technologies in pharo and it is sad if it just stops working. Any feedback is highly appreciated, Norbert

Aug. 29, 2017

Re: [Pharo-dev] poor state of fuel

by Max Leske

Thanks Tim. Norbert, I just saw that I have already created an issue for the 64-bit problems. I donât know whether tackling that will help you though. In any case, Iâll see that we try to work on those problems. I canât give you an exact timeline because I will be on holiday but I guess I can make an integration by around mid September. Cheers, Max On 29 August 2017 at 16:09:06, Tim Mackinnon (tim(a)testit.works) wrote: As a small data point, a fuel file written out on AWS Lambda Linux (not sure what version - I think it's an ubuntu, but they don't really say), is readable on OS X 64bit . So it seems like you must have found something unusual. Tim Sent from my iPhone On 29 Aug 2017, at 11:13, Max Leske <maxleske(a)gmail.com> wrote: Hi Norbert, We still maintain Fuel. I was not aware of the problem you describe. Could you open an issue on github (https://github.com/theseion/Fuel/issues) with a detailed explanation and, if possible, steps to reproduce the problem? Cheers, Max On 29 August 2017 at 11:04:34, Norbert Hartl (norbert(a)hartl.name) wrote: I'm migrating most of my projects to pharo 6.1 at the moment. I come from pharo 4, I skipped pharo 5. I use 64 bit which removes a lot of stuff that does not need to be installed and makes deployment better. That really feels much better. I use jenkins and there if a test fails a fuel dump is written to disk. The jenkins server is ubuntu linux with the vm of the opensuse build. My laptop has Mac OS and cannot read back those fuel dumps. I use the same image version on jenkins and my laptop. Both are 64bit. I asked that on discord and there was a mentioning that not only the 64 bit fuel has problems. So I wanted to ask what is the state of fuel right now. I consider fuel one of the core technologies in pharo and it is sad if it just stops working. Any feedback is highly appreciated, Norbert

Aug. 29, 2017