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

Re: [Pharo-dev] Need help for collecting tests usage data

by Stephane Ducasse

The idea is that benoit will then work on a nice autorun for Pharo. Stef On Thu, Jun 8, 2017 at 11:08 AM, Blondeau Vincent <vincent.blondeau(a)worldline.com> wrote: > Hi, > > > > An intern of the RMod research team needs your help: > > > > Cheers, > > Vincent > > > > De : Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] De la part de > Benoit Verhaeghe > EnvoyÃ© : mercredi 7 juin 2017 16:47 > Ã : pharo-users(a)lists.pharo.org > Objet : [Pharo-users] Need help for collecting tests usage data > > > > Hi everyone. > > > > I need your help. Iâm working on how pharo developers use the tests. And you > are pharo developers. > > So I developed a plugin and I would like you to download it. You just have > to execute this line in a playground > > > > Metacello new > > smalltalkhubUser: 'Pharo' project: 'MetaRepoForPharo60'; > > configuration: 'TestsUsageAnalyser'; > > version: #stable; > > get; > > load. > > > > You will have to do it only one time in one image. Then, if they are updates > itâll be done automatically and if you create a new image it will be > automatically installed. > > > > The plugin will collect data on which tests you run, when, and the > modifications you'll have done. > > Normally, it should be completely transparent for the users and the data are > anonymous. > > > > If you want more details about the project or how it works, you can answer > to this mail, or send me an email at benoit.verhaeghe(a)inria.fr or by using > discord. > > Thanks a lot. > > > > Benoit Verhaeghe > > > !!!************************************************************************************* > "Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage > exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret > professionnel. Si vous recevez ce message par erreur, merci d'en avertir > immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne > pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra > Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs > efforts soient faits pour maintenir cette transmission exempte de tout > virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa > responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un > virus transmis. > > This e-mail and the documents attached are confidential and intended solely > for the addressee; it may also be privileged. If you receive this e-mail in > error, please notify the sender immediately and destroy it. As its integrity > cannot be secured on the Internet, the Worldline liability cannot be > triggered for the message content. Although the sender endeavours to > maintain a computer virus-free network, the sender does not warrant that > this transmission is virus-free and will not be liable for any damages > resulting from any virus transmitted.!!!"

June 10, 2017

Re: [Pharo-dev] Parallel Port

by Stephane Ducasse

I have forwarded your email to olivier Auverlot because he was fighting to get Arduino working and I remember there were something related. On Sat, Jun 10, 2017 at 2:57 AM, Facundo Vozzi <facundov79(a)gmail.com> wrote: > Hi, > I need to access to the Parallel Port in order to use an old Analog/Digital > board to sense temperature in a micro brewery. Is anyone using any package > to do this? > > I'm using Pharo 6 on Windows. > > Thanks in advance, > Facundo

June 10, 2017

Re: [Pharo-dev] Pharo 7 and changes/sources files

by Stephane Ducasse

This is excellent to get the bootstrap in production.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! On Fri, Jun 9, 2017 at 10:01 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > because during the image bootstrapping all source code is reloaded, it is > all placed in the changes file and the sources file is useless. It would be > strange to deliver Pharo with empty sources file and big changes so we > decided to do sources compacting for every build. > > So Pharo 7 development versions will be delivered in an archive with three > files named like: > > Pharo7.0-117934d.image > Pharo7.0-117934d.changes > Pharo7.0-117934d.sources > > where "117934d" is an abbreviated hash of the Git commit from which the > Pharo image was bootstrapped. The sources file will be build-specific and of > course you will be able to share it between images based on the same build. > In changes file you will have only you own changes. > > You can test it here: > https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/lastSuccessfulBui… > > Cheers, > -- Pavel >

June 10, 2017

Re: [Pharo-dev] Pharo 7 and changes/sources files

by Stephane Ducasse

+ 1 :) It is just a file and this is only for the development of Pharo and for users of Pharo 70 it will be exactly the same. Let us focus on the place where we can get a good impact/ratio/plus for business/plus for innovation. I have a lot of dreams for Pharo: from the coffee machine to the big data servers and this story with source files is not interesting. We download thousands of files in any application. So let us focus our energy on something else. stef On Sat, Jun 10, 2017 at 6:13 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Yiury, > > On Fri, Jun 9, 2017 at 5:51 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> Why cannot we have the sources in the image? >> >> When I asked it 2 years ago people were like: "oh, but you can just >> download 1 sources file and use it by all the images". I donât care about >> that micro space savings, but fine, I said: have it your way. Now as we have >> to download sources all the time, why cannot we just have it IN the image? > > > It's not a "micro saving". A Pharo6 image is about 48Mb and a Pharo sources > file is about 32Mb. So you'd increase the size of the image by 75%. > Further, that space has to be dealt with by the GC. The compactor may have > to move this objects around; so it's certainly overhead. It might make > sense for development, especially if you use Igor's > include-source-in-the-method-trailer approach. But it doesn't make sense > for deployment where the application isn't going to look at the sources > anyway. So why put a heavy burden on deploying applications when the > current system works, and off loads a substantial amount of memory from the > system? > >> >> >> Uko >> >> >> On 9 Jun 2017, at 10:01, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >> >> Hi, >> >> because during the image bootstrapping all source code is reloaded, it is >> all placed in the changes file and the sources file is useless. It would be >> strange to deliver Pharo with empty sources file and big changes so we >> decided to do sources compacting for every build. >> >> So Pharo 7 development versions will be delivered in an archive with three >> files named like: >> >> Pharo7.0-117934d.image >> Pharo7.0-117934d.changes >> Pharo7.0-117934d.sources >> >> where "117934d" is an abbreviated hash of the Git commit from which the >> Pharo image was bootstrapped. The sources file will be build-specific and of >> course you will be able to share it between images based on the same build. >> In changes file you will have only you own changes. >> >> You can test it here: >> https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/lastSuccessfulBui… >> >> Cheers, >> -- Pavel >> >> > > > > -- > _,,,^..^,,,_ > best, Eliot

June 10, 2017

Re: [Pharo-dev] Pharo 7 and changes/sources files

by Eliot Miranda

Hi Yiury, On Fri, Jun 9, 2017 at 5:51 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Why cannot we have the sources in the image? > > When I asked it 2 years ago people were like: "oh, but you can just > download 1 sources file and use it by all the images". I donât care about > that micro space savings, but fine, I said: have it your way. Now as we > have to download sources all the time, why cannot we just have it IN the > image? > It's not a "micro saving". A Pharo6 image is about 48Mb and a Pharo sources file is about 32Mb. So you'd increase the size of the image by 75%. Further, that space has to be dealt with by the GC. The compactor may have to move this objects around; so it's certainly overhead. It might make sense for development, especially if you use Igor's include-source-in-the-method-trailer approach. But it doesn't make sense for deployment where the application isn't going to look at the sources anyway. So why put a heavy burden on deploying applications when the current system works, and off loads a substantial amount of memory from the system? > > Uko > > > On 9 Jun 2017, at 10:01, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > Hi, > > because during the image bootstrapping all source code is reloaded, it is > all placed in the changes file and the sources file is useless. It would be > strange to deliver Pharo with empty sources file and big changes so we > decided to do sources compacting for every build. > > So Pharo 7 development versions will be delivered in an archive with three > files named like: > > Pharo7.0-117934d.image > Pharo7.0-117934d.changes > Pharo7.0-117934d.sources > > where "117934d" is an abbreviated hash of the Git commit from which the > Pharo image was bootstrapped. The sources file will be build-specific and > of course you will be able to share it between images based on the same > build. In changes file you will have only you own changes. > > You can test it here: https://ci.inria.fr/pharo/view/7.0/job/70- > Bootstrap-32bit/lastSuccessfulBuild/artifact/bootstrap-cache/Pharo7.0- > 117934d.zip > > Cheers, > -- Pavel > > > -- _,,,^..^,,,_ best, Eliot

June 10, 2017

Re: [Pharo-dev] Parallel Port

by Ben Coman

The only two historical references I see on forum.world.st are from 2006 & 2010. http://forum.world.st/parallel-port-access-on-Linux-td46506.html http://forum.world.st/Physical-Etoys-released-td1574259.html and they have some link rot. I'd guess your best approach would be to get something working in pure C, and then provide functions that Pharo can call via FFI. Alternatively, from personal experience when I used to hoard such old parts, it may be economic use of your time to throw the old board away, and use a modern microcontroller. What you learn could facilitate more opportunities, and this stuff just keeps getting cheaper, while parallel ports get more expensive while knowledge of them keeps getting less relevant. Maybe a $20 ESP32 with 18 ADC channels + MQTT https://www.sparkfun.com/products/13907 http://wiki.jackslab.org/ESP32_Onchip_Sensor http://www.instructables.com/id/Power-and-Temperature-Data-Logger-With-ESP3… https://github.com/tuanpmt/esp32-mqtt http://forum.world.st/MQTT-for-Squeak-td4919880.html#a4920629 http://forum.world.st/MQTT-for-Pharo-td4927759.html#a4928045 https://developer.ibm.com/recipes/tutorials/connect-an-esp32-to-the-watson-… Or use a Raspberry Pi... https://core-electronics.com.au/tutorials/temperature-sensing-with-raspberr… that can run Pharo directly, but I'm not sure what access to pins is currently available. Again you could go the FFI route, or someone else might advise. cheers -ben On Sat, Jun 10, 2017 at 8:57 AM, Facundo Vozzi <facundov79(a)gmail.com> wrote: > Hi, > I need to access to the Parallel Port in order to use an old > Analog/Digital board to sense temperature in a micro brewery. Is anyone > using any package to do this? > > I'm using Pharo 6 on Windows. > > Thanks in advance, > Facundo >

June 10, 2017

Parallel Port

by Facundo Vozzi

Hi, I need to access to the Parallel Port in order to use an old Analog/Digital board to sense temperature in a micro brewery. Is anyone using any package to do this? I'm using Pharo 6 on Windows. Thanks in advance, Facundo

June 10, 2017

Re: [Pharo-dev] Pharo 7 and changes/sources files

by Ben Coman

On Fri, Jun 9, 2017 at 10:01 PM, K K Subbu <kksubbu.ml(a)gmail.com> wrote: > On Friday 09 June 2017 06:38 PM, Guillermo Polito wrote: > >> On Fri, Jun 9, 2017 at 2:51 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com >> When I asked it 2 years ago people were like: "oh, but you can just >> download 1 sources file and use it by all the images". I donât care >> about that micro space savings, but fine, I said: have it your way. >> Now as we have to download sources all the time, why cannot we just >> have it IN the image? >> >> We can, but that's something that requires changing lot's of things >> inside the image and it requires probably lot of testing. >> > > What if the sources is appended to the image file with a special header. > New code can relocate this pointer on the fly. The same technique can be > applied to changes file too. A small script can split files for older code > or combine them for new code. > > The resulting image file will be backward compatible. New code can > preserve these files across saves. > > Just a thought .. Subbu > > Or perhaps MemoryFileSystem could be effective? But no rush. cheers -ben

June 9, 2017

Re: [Pharo-dev] Pharo 7 and changes/sources files

by Yanni Chiu

On Fri, Jun 9, 2017 at 9:08 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > On Fri, Jun 9, 2017 at 2:51 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > wrote: > >> Why cannot we have the sources in the image? >> > >> We can, but that's something that requires changing lot's of things > inside the image and it requires probably lot of testing. > > So I'm not against it, but we cannot just make a change like this as we > are right now facing lots of key changes at the same time: > - migration to git, iceberg > - bootstrap based process > How about saving the sources in-memory via an instance of MemoryStore, so it should still look just like a file.

June 9, 2017

Re: [Pharo-dev] CPU and RAM usage of Pharo3 vs. Pharo6

by Holger Freyther

> On 9. Jun 2017, at 23:09, Holger Freyther <holger(a)freyther.de> wrote: > > related to Morphic polling? Right now the images still install RFB to help poking it at runtime (I should use the remote debugging for sure) so disabling morphic completely might not be an option yet? WorldState serverMode: true? And while looking at the usage it reminds me of some changes we should do for Pharo7. :) holger

June 9, 2017