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

Re: [Pharo-dev] Critical change to compiler, needs testing

by Marcus Denker

Hi, One thing we definitely need to do is to commit the Change first to the Opal repository. This will trigger a build and in a second step this: https://ci.inria.fr/rmod/job/OpalRegression/ <https://ci.inria.fr/rmod/job/OpalRegression/> This recompiled the whole image and then runs all tests. It is broken right now due to timeout, but that is from the >500 failing dictionary tests, I think. So the build now in progress should be green again (I hope). Marcus > On 18 Aug 2015, at 11:12, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi guys, > > In the quest to remove the old compiler from the map, we need to replace the references to ParseNode. Thing is that right now, the bytecode encoders opal compiler uses are subclasses of this ParseNode guy. > > To solve this, we are integrating this in several steps: > > - Integrate a copy of the encoders that are not subclass of ParseNode > Already integrated, with no real side effects on the system. > https://pharo.fogbugz.com/f/cases/16199/Introduce-OpalEncoders <https://pharo.fogbugz.com/f/cases/16199/Introduce-OpalEncoders> > > - Make the system use the new encoders > This change is critical as if the new encoders do not do the job, you may be unable to execute code again ^^. > We need help in testing this. > I ran the full tests of the image found some bugs but they do not look related. But, if you know some case, or you use the compiler in a special way, It would be good if you load the slice and test please :) > https://pharo.fogbugz.com/f/cases/16250/Activate-new-Encoders <https://pharo.fogbugz.com/f/cases/16250/Activate-new-Encoders> > > - A final step will be to rename the OpalEncoders* to Encoder* again (removing the Opal prefix) to be compatible with Squeak. But this one is rather easy and may have no risk. > > Guille

Aug. 18, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50243 Home: https://github.com/pharo-project/pharo-core

Aug. 18, 2015

[pharo-project/pharo-core] 7fdd46: 50243

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 7fdd4661c747e89a85a1137ee82ef71cf1edc1a0 https://github.com/pharo-project/pharo-core/commit/7fdd4661c747e89a85a1137e… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-08-18 (Tue, 18 Aug 2015) Changed paths: R Collections-Tests.package/CollectionRootTest.class/instance/accessing/collectionClass.st M Collections-Tests.package/DictionaryTest.class/instance/requirements/collectionClass.st A Collections-Tests.package/SetTest.class/instance/coverage/collectionClass.st R Refactoring-Tests-Critics.package/RBSmalllintTest.class/instance/tests/testMissingYourself.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50242.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50243.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50242.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50243.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A System-Changes.package/extension/TBehavior/instance/changeRecordsAt_.st R Traits.package/TBehavior.class/instance/accessing method dictionary/changeRecordsAt_.st Log Message: ----------- 50243 16253 Failing Test: RBSmalllintTest>>#testMissingYourself https://pharo.fogbugz.com/f/cases/16253 16251 Dictionary tests are failing https://pharo.fogbugz.com/f/cases/16251 16204 Traits package should not depend in System-Changes: fix two obvious causes https://pharo.fogbugz.com/f/cases/16204 http://files.pharo.org/image/50/50243.zip

Aug. 18, 2015

Re: [Pharo-dev] Monkey failures

by Marcus Denker

> On 18 Aug 2015, at 12:24, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Some monkey random questions: > > - I saw the monkey failing validations because of internal errors like timeouts while running the lint rules. That makes me think, when the monkey fails a validation because of a monkey failure, shouldn't it be better to mark the issue as "Resolved (Fix Review Needed)" again? Like that the monkey can re-pass if there was a timeout or whatever. > The danger is that we will then have lots of cases of jobs loopingâ¦ fail, rerun, fail, rerunâ¦. > Also, if we need to know that the monkey failed we can always add an extra tag on it. > > Another solution for this is to add the monkey a retry. > > - I saw several times that the monkey rechecks already validated issues. Is this a kind of race condition? Does anyone know the reason of this? Maybe we can add an extra check to avoid this. > The idea is that an issue is checked once for every released update. Because imagine it was green on Friday, we integrated stuff over the weekend that touched the same code, now we just integrate the friday change â> build wlll fail due to merge or tests will fail, huge mess. Marcus

Aug. 18, 2015

Re: [Pharo-dev] Mongo - find object by id

by Sabine Manaa

Hi Stephane, ok, I have put all my suggestions in a pull request. Please feel free to change, delete .... it is only a suggestion. I am interested in feedback! Regards Sabine 2015-08-17 14:53 GMT+02:00 Sabine Manaa <manaa.sabine(a)gmail.com>: > Hi Steph, > > thanks. I am editing my suggestions and tell you when finished. > > Regards > Sabine > > 2015-08-16 19:29 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> >> Hi Stephane, >> >> I have collected my points to add to the book. >> >> Can you give me an entry point how to do a pull request on the paper >> please? >> Pillar? Editor? Script? Sounds complicated for the first time. >> >> If you can use pillar this is better, else we will do a pass and convert >> it to pillar >> Since the chapter is for the book that should be out I'm not that editing >> it directly is a good. >> Now what we can do is to work on on a separate file that Johan or Esteban >> can merge to the chapter once >> it is finished. >> >> What I was thinking about is to have a series of extras section >> with for example some of the problems and solutions you encountered. >> >> >> How to handle loop within your domain? >> >> How to find an object by id? >> >> ... >> >> The original file is here: >> >> >> https://github.com/SquareBracketAssociates/EnterprisePharo/tree/master/Voya… >> >> >> I created a VoyageAdditionalText.pier that you can edit. >> >> And this is easy >> - you can go to the page >> - fork the folder >> - edit in the web the file and send a pull request. >> >> if this is not working, we will add you to the project and you can >> directly edit this file. >> >> Regards >> Sabine >> >> >> >> 2015-08-13 16:17 GMT+02:00 stepharo <stepharo(a)free.fr>: >> >>> >>> Hi Stephane, >>> >>> sure, I am happy to give something back to the community. I dont have so >>> much time because of my baby but I will try my best. >>> >>> Where shall I put it in? >>> >>> >>> You can do pull requests in the paper. This way they will be close to >>> the original version. >>> >>> >>> Sabina >>>> >>>> you know what I would really love from you .... >>>> this is that you reread the Voyage chapter and make a list of the >>>> problems you faced and that are not described in the chapter. >>>> You can write it in any bad ways and we can do a edit phase after, >>>> >>>> Why do I ask that? Because I'm stupid in Mongo and I would love to have >>>> a good doc. >>>> And only the people facing the problems can spot them nicely. >>>> I often write doc on things that I do not know but this is not working >>>> well because I'm slow in that case and .... I could be much better >>>> doing something else where I'm good at. >>>> >>>> Stef >>>> >>>> Le 12/8/15 09:40, Sabine Manaa a Ã©crit : >>>> >>>>> Hi, >>>>> >>>>> on mongo console, this brings me a persons information from mongo db >>>>> db.Persons.find({"_id" : ObjectId("75b900000000000000000000")}) >>>>> >>>>> I try to query the same person from pharo and I do not succeed. >>>>> >>>>> This makes my image hanging: >>>>> RKAPerson selectMany: {('_id' -> (OID >>>>> value:'75b900000000000000000000'))} >>>>> >>>>> also other variations e.g. >>>>> RKAPerson selectMany: {('_id' -> ('75b900000000000000000000')). } >>>>> asDictionary. >>>>> >>>>> do not work >>>>> >>>>> Other queries like >>>>> RKAPerson selectMany:{('lastName' -> ('Maier')).} asDictionary. >>>>> or >>>>> RKAPerson selectMany:{('nextTripNumber' -> (57)).} asDictionary. >>>>> >>>>> work fine. >>>>> >>>>> How can I query for an object with the object id? >>>>> >>>>> Regards >>>>> Sabine >>>>> >>>>> >>>>> >>>>> -- >>>>> View this message in context: >>>>> http://forum.world.st/Mongo-find-object-by-id-tp4842231.html >>>>> Sent from the Pharo Smalltalk Developers mailing list archive at >>>>> Nabble.com. >>>>> >>>>> >>>>> >>>> >>>> >>> >> >> >

Aug. 18, 2015

Monkey failures

by Guillermo Polito

Some monkey random questions: - I saw the monkey failing validations because of internal errors like timeouts while running the lint rules. That makes me think, when the monkey fails a validation because of a monkey failure, shouldn't it be better to mark the issue as "Resolved (Fix Review Needed)" again? Like that the monkey can re-pass if there was a timeout or whatever. Also, if we need to know that the monkey failed we can always add an extra tag on it. Another solution for this is to add the monkey a retry. - I saw several times that the monkey rechecks already validated issues. Is this a kind of race condition? Does anyone know the reason of this? Maybe we can add an extra check to avoid this. Guille

Aug. 18, 2015

Re: [Pharo-dev] Critical change to compiler, needs testing

by Blondeau Vincent

You right, I forget to load the first slice.. But I did not find errors by running some tests on the Moose Image. Cheers, Vincent De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de Guillermo Polito EnvoyÃ© : mardi 18 aoÃ»t 2015 11:49 Ã : Pharo Development List; ClÃ©ment Bera Objet : Re: [Pharo-dev] Critical change to compiler, needs testing That moose image is based on the latest Pharo??? :) Because to me it looks like you don't have the OpalEncoder classes from slice 16199. The order of loading is the following if on versions of pharo that are not latest 5.0: - load slice 16199 - load slice 16250 - execute postload: CompiledMethod initialize I tried that in moose 6.0, based on Pharo5.0 update: #50241 and It works fine. El mar., 18 de ago. de 2015 a la(s) 11:32 a. m., Blondeau Vincent <vincent.blondeau(a)worldline.com<mailto:vincent.blondeau@worldline.com>> escribiÃ³: Hi Guille, I loaded your slice in the last Moose image, and it not possible to browse any source code through nautilusâ¦ Maybe you should take a look? Cheers, Vincent De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org<mailto:pharo-dev-bounces@lists.pharo.org>] De la part de Guillermo Polito EnvoyÃ© : mardi 18 aoÃ»t 2015 11:13 Ã : Discusses Development of Pharo; ClÃ©ment Bera Objet : [Pharo-dev] Critical change to compiler, needs testing Hi guys, In the quest to remove the old compiler from the map, we need to replace the references to ParseNode. Thing is that right now, the bytecode encoders opal compiler uses are subclasses of this ParseNode guy. To solve this, we are integrating this in several steps: - Integrate a copy of the encoders that are not subclass of ParseNode Already integrated, with no real side effects on the system. https://pharo.fogbugz.com/f/cases/16199/Introduce-OpalEncoders - Make the system use the new encoders This change is critical as if the new encoders do not do the job, you may be unable to execute code again ^^. We need help in testing this. I ran the full tests of the image found some bugs but they do not look related. But, if you know some case, or you use the compiler in a special way, It would be good if you load the slice and test please :) https://pharo.fogbugz.com/f/cases/16250/Activate-new-Encoders - A final step will be to rename the OpalEncoders* to Encoder* again (removing the Opal prefix) to be compatible with Squeak. But this one is rather easy and may have no risk. Guille ________________________________ 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. ________________________________ 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.

Aug. 18, 2015

Re: [Pharo-dev] Critical change to compiler, needs testing

by Guillermo Polito

That moose image is based on the latest Pharo??? :) Because to me it looks like you don't have the OpalEncoder classes from slice 16199. The order of loading is the following if on versions of pharo that are not latest 5.0: - load slice 16199 - load slice 16250 - execute postload: CompiledMethod initialize I tried that in moose 6.0, based on Pharo5.0 update: #50241 and It works fine. El mar., 18 de ago. de 2015 a la(s) 11:32 a. m., Blondeau Vincent < vincent.blondeau(a)worldline.com> escribiÃ³: > Hi Guille, > > > > I loaded your slice in the last Moose image, and it not possible to browse > any source code through nautilusâ¦ > > > > Maybe you should take a look? > > > > Cheers, > > Vincent > > > > *De :* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] *De la part > de* Guillermo Polito > *EnvoyÃ© :* mardi 18 aoÃ»t 2015 11:13 > *Ã :* Discusses Development of Pharo; ClÃ©ment Bera > *Objet :* [Pharo-dev] Critical change to compiler, needs testing > > > > Hi guys, > > > > In the quest to remove the old compiler from the map, we need to replace > the references to ParseNode. Thing is that right now, the bytecode encoders > opal compiler uses are subclasses of this ParseNode guy. > > > > To solve this, we are integrating this in several steps: > > > > - Integrate a copy of the encoders that are not subclass of ParseNode > > Already integrated, with no real side effects on the system. > > https://pharo.fogbugz.com/f/cases/16199/Introduce-OpalEncoders > > > > - Make the system use the new encoders > > This change is critical as if the new encoders do not do the job, you > may be unable to execute code again ^^. > > *We need help in testing this.* > > I ran the full tests of the image found some bugs but they do not look > related. But, if you know some case, or you use the compiler in a special > way, It would be good if you load the slice and test please :) > > https://pharo.fogbugz.com/f/cases/16250/Activate-new-Encoders > > > > - A final step will be to rename the OpalEncoders* to Encoder* again > (removing the Opal prefix) to be compatible with Squeak. But this one is > rather easy and may have no risk. > > > > Guille > > ------------------------------ > > 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. >

Aug. 18, 2015

Re: [Pharo-dev] Critical change to compiler, needs testing

by Blondeau Vincent

Hi Guille, I loaded your slice in the last Moose image, and it not possible to browse any source code through nautilusâ¦ Maybe you should take a look? Cheers, Vincent De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de Guillermo Polito EnvoyÃ© : mardi 18 aoÃ»t 2015 11:13 Ã : Discusses Development of Pharo; ClÃ©ment Bera Objet : [Pharo-dev] Critical change to compiler, needs testing Hi guys, In the quest to remove the old compiler from the map, we need to replace the references to ParseNode. Thing is that right now, the bytecode encoders opal compiler uses are subclasses of this ParseNode guy. To solve this, we are integrating this in several steps: - Integrate a copy of the encoders that are not subclass of ParseNode Already integrated, with no real side effects on the system. https://pharo.fogbugz.com/f/cases/16199/Introduce-OpalEncoders - Make the system use the new encoders This change is critical as if the new encoders do not do the job, you may be unable to execute code again ^^. We need help in testing this. I ran the full tests of the image found some bugs but they do not look related. But, if you know some case, or you use the compiler in a special way, It would be good if you load the slice and test please :) https://pharo.fogbugz.com/f/cases/16250/Activate-new-Encoders - A final step will be to rename the OpalEncoders* to Encoder* again (removing the Opal prefix) to be compatible with Squeak. But this one is rather easy and may have no risk. Guille ________________________________ 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.

Aug. 18, 2015

Critical change to compiler, needs testing

by Guillermo Polito

Hi guys, In the quest to remove the old compiler from the map, we need to replace the references to ParseNode. Thing is that right now, the bytecode encoders opal compiler uses are subclasses of this ParseNode guy. To solve this, we are integrating this in several steps: - Integrate a copy of the encoders that are not subclass of ParseNode Already integrated, with no real side effects on the system. https://pharo.fogbugz.com/f/cases/16199/Introduce-OpalEncoders - Make the system use the new encoders This change is critical as if the new encoders do not do the job, you may be unable to execute code again ^^. *We need help in testing this.* I ran the full tests of the image found some bugs but they do not look related. But, if you know some case, or you use the compiler in a special way, It would be good if you load the slice and test please :) https://pharo.fogbugz.com/f/cases/16250/Activate-new-Encoders - A final step will be to rename the OpalEncoders* to Encoder* again (removing the Opal prefix) to be compatible with Squeak. But this one is rather easy and may have no risk. Guille

Aug. 18, 2015