- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] expected failures

by Pharo4Stef

ben camillo once wrote a nice mail about shouldnot: Error. If I remember correctly. Stef On 25 Feb 2014, at 17:04, btc(a)openinworld.com wrote: > I'd like to better understand the semantics of "expected failures" in TestRunner. It seems to me that if you want to ensure that a certain operation fails, in a test you'd wrap it as follows... > > shouldFailed=false. > [ self operationThatShouldFail ] on: Error do: [ shouldFailed := true ]. > self assert: shouldFailed. > > So is tagging methods with pragma <expectedFailure> or in method #expectedFailures a temporary measure used to bypass a failing test when the judgment is that it is not critical to fix immediately? What is the process for tacking and resolving expected failures. It would give a warm fuzzy feeling if no expected failures are reported in TestRunner. Otherwise it leaves some residual uncertainty that something is wrong, even though a failure is "expected". > > cheers -ben >

Feb. 25, 2014

Pharo 3.0 "Sorry that name is already in use"

by Martin McClure

This is a bug report of sorts. I had a Pharo 3.0 image that was last updated about a month ago. I started a Software Update, and it was pulling in updates, when I needed to sleep my (Linux) laptop. When I re-opened the laptop, there was a walkback there, which I didn't find surprising since I'd interrupted the update's network connection by sleeping the laptop. It was some kind of "can't load" error; I don't remember the details. Anyway, I abandoned that, and chose "Software update" again. Almost immediately I got a little info box in the lower left that said "Sorry that name is already in use". This box stayed there until the update was complete. There was no other context given, so I have no idea what it was complaining about. Regards, -Martin

Feb. 25, 2014

Re: [Pharo-dev] 3.0 image silently quits when opening the Transcript

by HernÃ¡n Morales Durand

A problem with the machine I was using, falsa alarm. Cheers, HernÃ¡n 2014-02-25 13:33 GMT-03:00 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > Since today the latest stable image hangs when opening the Transcript from > the world menu. Any known issue? > This is what I do from MinGW shell: > > $ wget -O- http://get.pharo.org/30+vm | bash > $ pharo Pharo.image --no-quit > > I am using WinXP SP3 here. > Cheers, > > HernÃ¡n > >

Feb. 25, 2014

Re: [Pharo-dev] access to CI debug info Re: test failures in downloaded image 30733

by Max Leske

Take a look at the Fuel job. Just put the file into the working directory (same directory as the image is in) and add a rule to archive Fuel files: **/*.fuel On 25.02.2014, at 17:35, btc(a)openInWorld.com wrote: > btc(a)openinworld.com wrote: >> >> btc(a)openinworld.com wrote: >>> >>> Marcus Denker wrote: >>>> >>>> >>>> On the ci server this is already done: failing tests are serialise with Fuel for debugging. In addition, the image is save and can be downloaded (in the state after the test run). >>> >> How do I find the fuel files and saved image for this validation report? >> https://ci.inria.fr/pharo/job/Pharo-3.0-Issue-Validator/11185//artifact/val… > > Hi Camillo, > > I am interested by your comment on Case 12957 that "I think we can/should add this code to the standard CI project" > regarding my ImageWorker hack to try getting hold of the test failure fuel file. What was it you liked? > > Its not suitable for integration in its current form since its a very specific hack hardcoding the target folder, that would leave rubbish on the CI server if I didn't pay attention to manually clean up afterward. Also getting the fuel file back to my local machine is awkward using scp to bounce a copy through the inria ssh gateway. Ideally the fuel file would just end up as an artifact of the Jenkins job. What needs doing? I'd be interested in helping out - though I wouldn't want to risk breaking anything prior to Pharo 3 release. > > cheers -ben

Feb. 25, 2014

Re: [Pharo-dev] image traffic

by Christophe Demarey

Le 25 fÃ©vr. 2014 Ã 17:37, Norbert Hartl a Ã©crit : > If you look at the hosts list than you can see that 75% of the overall traffic is generated by cloud-gw.inria.fr. The CI jobs download the vm with curl. > > What brings me to the next point. The âHostsâ section in those states might break a data protection law. I donât know how they are in france but in germany this would be illegal. We are not allowed to store IP addresses for a longer period. And making them public is really asking for trouble. I think we have some equivalent laws. For another project, we had to anonymize awstats results. Maybe raw statistics should be kept private and only use numbers for marketing. Christophe.

Feb. 25, 2014

Re: [Pharo-dev] image traffic

by Norbert Hartl

If you look at the hosts list than you can see that 75% of the overall traffic is generated by cloud-gw.inria.fr. The CI jobs download the vm with curl. What brings me to the next point. The âHostsâ section in those states might break a data protection law. I donât know how they are in france but in germany this would be illegal. We are not allowed to store IP addresses for a longer period. And making them public is really asking for trouble. Why? Because now I know that Sebastian Sastre might be responsible for 2,5% of the overall traffic on that site. I find that funny but most people donât. Especially Iâm asking myself why his server is in germany close to my own server maybe in the same roomâ¦. :) Anyway, an advize would be to check the law situation or just to switch off the Hosts section in the stats. Norbert Am 25.02.2014 um 16:54 schrieb Esteban A. Maringolo <emaringolo(a)gmail.com>: > Great stats. > > AFAIK, approximately two thirds of the downloads are performed by curl UA. Which means many people, including me, must be using the convenient (but unsafe) http://get.pharo.org shell script. > > Considering a CI environment or scripted automated build, many people is accountable for more than one download per day (I'm for two the last days). > > Anyhow, it is good to have some raw metrics to analyze on. > > Regards! > > > > Esteban A. Maringolo > > > 2014-02-25 11:07 GMT-03:00 Camillo Bruni <camillobruni(a)gmail.com>: > We finally have our stats for files.pharo.org online again: > > http://files.pharo.org/teststats/2014/02/awstats.awstats.en.html > > We're approaching around 300GB downloads per month, not bad I'd say :) >

Feb. 25, 2014

access to CI debug info Re: test failures in downloaded image 30733

by btc＠openinworld.com

Feb. 25, 2014

3.0 image silently quits when opening the Transcript

by HernÃ¡n Morales Durand

Since today the latest stable image hangs when opening the Transcript from the world menu. Any known issue? This is what I do from MinGW shell: $ wget -O- http://get.pharo.org/30+vm | bash $ pharo Pharo.image --no-quit I am using WinXP SP3 here. Cheers, HernÃ¡n

Feb. 25, 2014

Re: [Pharo-dev] Adding an iVar to class "Class" still gives error

by Camille Teruel

I found a way to fix it. For certain classes and metaclasses, the slotScope is not correct. That is "aClass superclass layout slotScope == aClass layout slotScope parentScope" responds false!! Here is a dirty fix to find and rebuild these classes and metaclasses. But I would like to have a better way to rebuild a class than adding then removing an inst var. After executing this, you can add an iv to class (beware it takes several minutes). ivName := 'anIVNameImPrettySureNobodyUses'. all := Smalltalk allClasses flatCollect: [ :e | { e . e class } ]. candidates := all reject: [ :e | e superclass isNil or: [e layout slotScope isKindOf: LayoutEmptyScope ] ]. toRebuild := candidates reject: [ :e | e superclass layout slotScope == e layout slotScope parentScope ]. toRebuild do: [ :e | e addInstVarNamed: ivName ]. toRebuild do: [ :e | (e isClassSide ifTrue: [ (Smalltalk at: e instanceSide name) classSide ] ifFalse: [ Smalltalk at: e name ]) removeInstVarNamed: ivName ] On 25 fÃ©vr. 2014, at 09:09, Torsten Bergmann <astares(a)gmx.de> wrote: > Unfortunately it is not fixed, anyone with knowledge > of the new class builder able to fix it: > > https://pharo.fogbugz.com/f/cases/11596 > >

Feb. 25, 2014

expected failures

by btc＠openinworld.com

I'd like to better understand the semantics of "expected failures" in TestRunner. It seems to me that if you want to ensure that a certain operation fails, in a test you'd wrap it as follows... shouldFailed=false. [ self operationThatShouldFail ] on: Error do: [ shouldFailed := true ]. self assert: shouldFailed. So is tagging methods with pragma <expectedFailure> or in method #expectedFailures a temporary measure used to bypass a failing test when the judgment is that it is not critical to fix immediately? What is the process for tacking and resolving expected failures. It would give a warm fuzzy feeling if no expected failures are reported in TestRunner. Otherwise it leaves some residual uncertainty that something is wrong, even though a failure is "expected". cheers -ben

Feb. 25, 2014