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

Re: [Pharo-dev] missing updates: 30503 30504

by Marcus Denker

On Oct 22, 2013, at 12:01 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Oct 21, 2013, at 9:24 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >> >> Indeed but instead of getting on your favorite topic, tell me where is the update.list? > > on the server files.pharo.org > >> I do not understand why it is not in the pharo-update folder >> > because it is generated on the server and to have it in git would mean to have git installed on the server > and check it in. > > We found that too complex and instead treat the updates.list as a cache that is just generated on the server > > The thing is that this is all crappy stuff, the next step is to remove the updates.list and just rely on files in a directory. > > So and *accessing* files.pharo.org to edit the file is sadly compacted, complicated (how does one turn off this thing that makes perfectly parsable typos into completely wrong words making people look like idiots?)

Oct. 21, 2013

Re: [Pharo-dev] missing updates: 30503 30504

by Marcus Denker

On Oct 21, 2013, at 9:24 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> > > Indeed but instead of getting on your favorite topic, tell me where is the update.list? on the server files.pharo.org > I do not understand why it is not in the pharo-update folder > because it is generated on the server and to have it in git would mean to have git installed on the server and check it in. We found that too complex and instead treat the updates.list as a cache that is just generated on the server The thing is that this is all crappy stuff, the next step is to remove the updates.list and just rely on files in a directory. So and *accessing* files.pharo.org to edit the file is sadly compacted, but that is because Inria admins can't give us anything else. ssh file-pharo.inria.fr sudo su - filepharosync cd /appli/files.pharo.org/updates/pharo3.0/ vi updates30.list (yes, and then this is not in unix line endingsâ¦ so editing is a pain) yes, this all sucks. But what are the options? Doing nothing until it is beautiful and perfect? Marcus

Oct. 21, 2013

Use #shouldnt:raise: only with specific errors, or evaluate the given expression directly

by Alexandre Bergel

Hi! Just to share some thought. I am now playing with Pharo 3. I have seen TestCase has some additional checks for assertion with exception. I perfectly understand the idea behind this, however, on the other hand, I see nothing suspect with the following assertion (which Roassal's tests are full of): self shouldnt: [ view raw drawOn: tracingCanvas ] raise: Error I have to shut down the method #validateShouldntException: Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 21, 2013

Re: [Pharo-dev] [regression reporter]regression occurred

by Sven Van Caekenberghe

Tests that fail indicate that something is broken. They are like a kind of todo. But sometimes they are hard to fix and remain open for a long time. I understand that that conflicts with the notion of being 'all green all the time'. Maybe we should classify them somehow ? On 21 Oct 2013, at 23:08, Camillo Bruni <camillobruni(a)gmail.com> wrote: > sad but true :( > > On 2013-10-21, at 08:37, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> I have turned off these emails for now, they are too many and thus get ignored >> (I have never seen anyone but me filing an issue tracker entry for a newly failing testâ¦) >> >> Marcus >> >> On Oct 21, 2013, at 8:32 AM, no-reply(a)ci.inria.fr wrote: >> >>> https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation-M-Z/labe… >>> >>> 2 regressions found. >>> Tests.Release.ReleaseTest.testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits >>> Zinc.Tests.ZnServerTests.testEntityTooLarge >>> >> >

Oct. 21, 2013

Re: [Pharo-dev] Character>>#leadingChar

by Sven Van Caekenberghe

On 21 Oct 2013, at 21:33, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > What would be the possible steps? There are 23 implementors and 56 senders of #leadingChar ;-) > Stef > > On Oct 21, 2013, at 9:26 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Phil, >> >> On 21 Oct 2013, at 21:09, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >> >>> Well, for one, removing leadingChar will make the urlEncode/urlDecode work properly for the test, as now, the leadingChar thing prevents it. >> >> Read my last comment in https://pharo.fogbugz.com/f/cases/6368/deprecate-unescapePercents-and-encod… >> >> I rewrote the test without the language environment stuff, it should pass. >> >>> As it is now, leadingChar generates a code point outside of the unicode range, making leadingChar a non supportable element. >>> >>> Let's get that out. >> >> Yes, longer term I think we should indeed remove it. >> >>> Phil >> >> Sven >> >> > >

Oct. 21, 2013

Re: [Pharo-dev] [regression reporter]regression occurred

by Camillo Bruni

sad but true :( On 2013-10-21, at 08:37, Marcus Denker <marcus.denker(a)inria.fr> wrote: > I have turned off these emails for now, they are too many and thus get ignored > (I have never seen anyone but me filing an issue tracker entry for a newly failing testâ¦) > > Marcus > > On Oct 21, 2013, at 8:32 AM, no-reply(a)ci.inria.fr wrote: > >> https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation-M-Z/labe… >> >> 2 regressions found. >> Tests.Release.ReleaseTest.testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits >> Zinc.Tests.ZnServerTests.testEntityTooLarge >> >

Oct. 21, 2013

Re: [Pharo-dev] missing updates: 30503 30504

by Camillo Bruni

On 2013-10-21, at 22:30, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> It is fundamentally wrong to rely on written description of processes (not to be confused with documentation). We script, we >>>> write code, we do not read prose. >>> >>> Sorry but the integration requires human intervention at least to make sure we do not merge bullshits or checking conflicts just before. >>> Right now this is like that. Then even a script should be commented and documented. When I read you, you give the impression to >>> the rest of the world that we are idiots doing everything manually. But this is not the case. We are doing only 2%: checking conflicts, >>> writing the log and closing the bugs. Of course we should continue and make it fully automate. >> >> Which is something we solved with Ben 2 years ago. It did not do everything automatically, but as much as you can: >> - it list the issues that can be integrated >> - it lets you select the issues to be integrated >> - it shows the diff of the integrated changes >> - it triggers a new update cycle > > I'm favor of that. Now why neither marcus me or esteban do not use it? > May be because we are afraid that if something break we are at loss. At least this is a stress to integrate a fix (even fullllllllly automated - the prove is that > our wonderful staged process lets me publish cs while it should not else you would not complain that the system produced new items without corresponding images) I still didn't get what went exactly wrong with the updates. Maybe you can explain the steps you did, so we can prevent such kind of faulty updates in the future. For retracting files you need access to files.pharo.org.

Oct. 21, 2013

Re: [Pharo-dev] [update 3.0] #30510

by StÃ©phane Ducasse

>> >> On Oct 21, 2013, at 5:42 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >>> humm strange I see only one change for this update? >>> >>> https://github.com/pharo-project/pharo-core/commit/cf142b12a098df4f650c4c9a… >>> >>> any clue what the other change was? most probably there is a bug in my git export script. >>> >> Yes: method #minExtent in TabGroupMorph, just that (and the change is in, I checked the latest image) > > seems like extension methods are not properly handled :( > strange that TabGroupMorph has an extension category form its own package: *Polymorph-Widgets ;) probably a but in move to package :)

Oct. 21, 2013

Re: [Pharo-dev] missing updates: 30503 30504

by StÃ©phane Ducasse

>>> It is fundamentally wrong to rely on written description of processes (not to be confused with documentation). We script, we >>> write code, we do not read prose. >> >> Sorry but the integration requires human intervention at least to make sure we do not merge bullshits or checking conflicts just before. >> Right now this is like that. Then even a script should be commented and documented. When I read you, you give the impression to >> the rest of the world that we are idiots doing everything manually. But this is not the case. We are doing only 2%: checking conflicts, >> writing the log and closing the bugs. Of course we should continue and make it fully automate. > > Which is something we solved with Ben 2 years ago. It did not do everything automatically, but as much as you can: > - it list the issues that can be integrated > - it lets you select the issues to be integrated > - it shows the diff of the integrated changes > - it triggers a new update cycle I'm favor of that. Now why neither marcus me or esteban do not use it? May be because we are afraid that if something break we are at loss. At least this is a stress to integrate a fix (even fullllllllly automated - the prove is that our wonderful staged process lets me publish cs while it should not else you would not complain that the system produced new items without corresponding images) In which languages are the scripts and logic written? What I like with ScriptLoader is that I can debug and change the process. And I will not use bash or ruby to do boring things - I do not want to invest in any thing that does not have a decent debugger. I'm sorry I do not have the time for that. > That means, not more manually copying over issue descriptions, no more manually closing issues. > I guess it doesn't work anymore since nobody used it since then, but that is definitely something > that should be taken care of. Yes! >> To me the bottleneck is that the process is not concurrent and that conflicts are not automatically detected once we qualify a fix >> as ready to include. Since another changes can be made in parallel we can have conflict and it means that the automated approach >> should recheck all the pending fixes to make sure that none of them got into conflict since the last integration. > > This is exactly how the monkey works. it checks for each release again if all the pending fixes integrate cleanly. > For each check it will add a tag, [validated in 30xxx]. in which the SmalltalkHub project is the monkey hosted? I would like to read the code (if this is in ruby no need to send me the info I will not look at it - my plate is full not time. I'm learning Ada parsing, Python semantics and JS security and this is enough for me right now). >>> And the scriptloader comment is, and never was complete either, since it excluded the >>> interaction on the bug tracker. Issues have to be closed after integrating them, well >>> marcus did that job yesterday, but this has to be done automatically in the integration process. >> >> Indeed but instead of getting on your favorite topic, tell me where is the update.list? >> So that I can edit it. > > => see further down, it is here: http://files.pharo.org/updates/pharo3.0/ I do not understand why it is not in the Pharo-update git repository. Because I do not know how to access the file server and the file server has protectionâ¦. >> I do not understand why it is not in the pharo-update folder > > Because it is generated, you do not touch it. Look at it some sort of code duplication. > And furthermore it is separated into two parts, staged updates (which are not public) and > the public updates (updates.list). If the staged updates fail, the updates.list never even > gets modified, hence you do not have to manually edit it. I know that! I know the staged process. Now in that case we should have a way to remove entries in the updates.list. This is exactly because we cannot remove entries that you get the extra images that are not found and that you complain about. If the process is automated it should also handle the failure well. Else we are at loss and you need to know that yes modifying this file on the serverâ¦â¦ balblbalbalbalbalb And now 1/3 of the integrators does not know how to do it! But I can also not integrate fixes and enjoy looking smart building great new things. It is also better for the ego. > This is far less error prone than the previous update process and requires almost never a > manual retraction of an update, since it never even gets released when the update doesn't > work. So all in all less work. Camillo please stop to brainwash me. Please I *****KNOW******* all the good arguments. I like them. I'm in favor of them but please give me a break. This is me that is losing time when I integrate a change that does not work (and that the wonderful process should not let in (which surprisingly it did) --- so I have to handle the consequences of something that I do not fully have access to - really frustrating. >> Because any scripted actions should also support full rollback and so far I cannot rollback >> a change even manually because I do not know where this file is and how I can edit it. >> >> This comment does not help. > > - it tells you exactly where the file is(answering your above question): http://files.pharo.org/updates/pharo3.0/ > - again forwarding to the proper jenkins jobs from files.pharo.org > - it also tells you where the file is generated: https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-3-Release/ cool that this is in Pharo ./pharo Pharo.image eval " updates := (ZnEasy get: 'http://files.pharo.org/updates/pharo3.0/updates30.list') contents lines. updates := updates reject: [ :each | each beginsWith: '#' ]. staged := 'updates30.staged' asFileReference readStream contents asString lines. staged := staged reject: [ :each | each beginsWith: '#' ]. updates := (updates, staged) asSet asArray sorted. 'updates30.list' asFileReference ensureDeleted writeStreamDo: [ :output | output nextPutAll: '#Pharo3.0'; cr. updates do: [ :each | output nextPutAll: each; cr ]]. Smalltalk snapshot: false andQuit: true." So how can I publish on files.pharo.org SSH: Connecting from host [pharo-linux64] SSH: Connecting with configuration [files.pharo.org] ... SSH: EXEC: STDOUT/STDERR from command [rm /appli/files.pharo.org/updates/pharo3.0/updates30.staged || echo "NO updates30.staged FOUND"] ... SSH: EXEC: completed after 201 ms SSH: Disconnecting configuration [files.pharo.org] ... SSH: Transferred 1 file(s) is not meaningful to me. I thought that I could learn in the copied jenkins job but this is not the case. set -e wget updates.pharo.org/pharo3.0/updates30.staged wget -O- get.pharo.org/30+vm | bash ./pharo Pharo.image update --from-file=updates30.staged ./pharo Pharo.image printVersion > So the next step is to read the description of the jenkins jobs: > > https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-0-Prepare/ > https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-1-Tracker/ > ... and so forth, > > Unlike what you say, it is properly documented, not centralized, but in all places where > the things happen. I really wonder what is missing. > Yes, there are some dangling links on > jenkins since the update process go recently modified, but these are things that happen. HOW TO REMOVE AN ENTRY IN THE UPDATE LIST!!!! Now with my fix to the scriptLoader (less than 1 min) we will not have problem with popup on load on the server but still. I still do not understand why the staged development let me create new update. -- I do not fully understand why the check to verify the sync between the update and the image did not catch the problem and proposed me a new update. Probably because silently loading the latest image and loading empty updates and checking the last item (which was correct) => the check make sure that the updateXXX corresponds to the latest one in the update30 but nothing else. I got the problem some how. In addition I do not understand why the jenkins job were not red and let the update continue Stef

Oct. 21, 2013

Re: [Pharo-dev] [update 3.0] #30510

by Camillo Bruni

On 2013-10-21, at 18:08, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Oct 21, 2013, at 5:42 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> humm strange I see only one change for this update? >> >> https://github.com/pharo-project/pharo-core/commit/cf142b12a098df4f650c4c9a… >> >> any clue what the other change was? most probably there is a bug in my git export script. >> > Yes: method #minExtent in TabGroupMorph, just that (and the change is in, I checked the latest image) seems like extension methods are not properly handled :( strange that TabGroupMorph has an extension category form its own package: *Polymorph-Widgets ;)

Oct. 21, 2013