- Pharo-dev - lists.pharo.org

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

by Camillo Bruni

On 2014-02-26, at 17:47, btc(a)openinworld.com wrote: > Thanks for that info Max. I can see "Files to archive" in the PharoLauncher configuration that I have access to. I don't have access to the configuration of Pharo-3.0-Issue-Validator to check, but I guess it should have an entry... > **/*/*.fuel > to gather fuel files from the subdirectories of the workspace. > > I have observed from running Pharo-3.0-Issue-Tracker-Image locally that Fuel files are created, that on the build server would located as follows... > /builds/workspace/Pharo-3.0-Issue-Validator/3570607022163494/Pharo-3.-2.0.fuel sorry that I didn't answer earlier. We only generate the fuel files while running the tests on the command line. The CI/validation infrastructure doesn't do that yet, but it should be very easy to add. Additionally I haven't enabled the new stack frame output for the validation report for test cases.

Feb. 26, 2014

Re: [Pharo-dev] expected failures

by Camillo Bruni

On 2014-02-26, at 19:11, btc(a)openinworld.com wrote: > Camillo Bruni wrote: >> On 2014-02-25, 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. >>> >>> >> >> I prefer: >> >> self should: [ self operationThatShouldFail ] raise: ASpecificError >> >> Otherwise you can just run the code itself: >> >> self operationThatShouldFail >> >> the test framework will take care of it and mark the test correctly as a failure. >> >> > Camillo, I don't quite follow your second case. Do you refer to using <expectedFailure> ? Doing that might be community convention, but "expected failures" for this makes me uncomfortable. It is not specific about what the failure should be, so the occurrence of non-expected failures is masked. I really like #should:raise since it is specific. It would be nice if as many <expectedFailure>s as possible were converted to #should:raise, with <epxectedFailure> being used only for fubared tests being prioritised to deal with later on, with the ultimate goal of having no <expected Failure>s in the image. ah sorry, you are right, I didn't answer correctly. I don't use <expectedFailure> since I don't understand what it means :P I prefer #should:raise: too. And in the case to mark a test failing (aka skip) we can do the following: self skip: 'Because it does not work'

Feb. 26, 2014

Pharo-Business: a new mailing-list

by Pharo4Stef

Dear Pharoers and Smalltalkers from all over the world We would really like to push business in our community and we believe that it is important to create a community around business questions. We created a new mailing-list http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org The idea is to identify - potential market - missing technical solutions that we could build together - share technical assets from a business perspective (which frameworks for what). We hope that you will like the idea and that more business can emerge!

Feb. 26, 2014

Re: [Pharo-dev] Pharo 3.0 on Windows 8.1

by kilon alios

you can set the quality of the streaming clicking the gear button and also set it permanently for all videos in the youtube settings. On Wed, Feb 26, 2014 at 8:18 PM, <btc(a)openinworld.com> wrote: > Sven Van Caekenberghe wrote: > > On 26 Feb 2014, at 17:21, btc(a)openinworld.com wrote: > > > > Nice initiative - but up to about 50 seconds the image is so compressed it is unreadable. > cheers -ben > > > No, it's not. The movie is properly HD, 720p (1280 px Ã 720 px). YouTube automatically adapts the quality setting depending on the quality of your connection. It probably started with a lower quality settings and switched half way. > > > > Whoops sorry. Its a shame that YouTube does that, and unfortunate that > without end-to-end control of the quality you don't know how many people > will get a poor impression. I'd much rather a stream/download take longer > to complete and watching it without interruption after the download is > complete. > cheers -ben > > Sven Van Caekenberghe wrote: > > > Pharo 3.0 on Windows 8.1 > Installing and running Pharo 3.0 on a blank Windows 8.1 machine in under 1 minute. > http://www.youtube.com/watch?v=FKokxrQtrg0 > > With an extra minute to demo some elementary interactions. > > Sven > > -- > Sven Van Caekenberghe > Proudly supporting Pharohttp://pharo.orghttp://association.pharo.orghttp://consortium.pharo.org > > > > > > > > > > >

Feb. 26, 2014

Re: [Pharo-dev] Pharo is cool

by Norbert Hartl

Am 26.02.2014 um 14:38 schrieb Mariano Martinez Peck <marianopeck(a)gmail.com>: > Just be careful 2: "I switched one of my servers to dump to stack with fuel to disk if an exception occurs. " > Once it happened to me the stack I was taking for serializing an error was too big. Too big because it even reached the UI. The UI has lots of sensible objects that change quite frequently. So my graph to serialize was big and the graph changed quite frequently. Result: Fuel throwing error because the graph to serialize changed while being serialized. Oh...exception? Fuel out exception! exception. Oh exception? ... > Good point, thanks! > So yeah..the fact that Fuel was throwing an error causes a loop so be careful of that as well. > If the serialization fails I just consider it an unrecoverable error and proceed. I will add a logging message for that case so I can at least so when something does not working while fueling out the stack. thanks, Norbert > > > On Wed, Feb 26, 2014 at 10:28 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 26.02.2014 um 14:19 schrieb Max Leske <maxleske(a)gmail.com>: > > > Cool! :) > > > > Just be careful: if youâre using a large model the stack can blow up your image with a low space warning / make it inresponsive (because the stack referenes your model and boom, pretty much all of your instances will becom serialized). > > > Yes, I know. But that would be a problem anyway. I think I have time. In the fuel files are 8 (!) contexts. :) > > Norbert > > > FYI weâre actively working on pruning of the serialization graph to solve this. > > > > Max > > > > > > On 26.02.2014, at 14:01, Norbert Hartl <norbert(a)hartl.name> wrote: > > > >> The best smalltalk/pharo moments you get if you try things you want to have just in order to see they are already there. > >> > >> Today FileBrowser. > >> I switched one of my servers to dump to stack with fuel to disk if an exception occurs. Today I copied the files from the server to my local machine and opened a workspace starting to write an expression to open them. Then I thought it would be cool if I could use the file browser for it. So I opened it and navigated to the directory with the fuel filesâ¦et voilÃ â¦as soon as I clicked on a fuel file a button âmaterializeâ appeared which showed the stack from the server right away. > >> > >> Just brilliant! Well done! > >> > >> Norbert > > > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com

Feb. 26, 2014

Re: [Pharo-dev] Pharo 3.0 on Windows 8.1

by btc＠openinworld.com

Feb. 26, 2014

Re: [Pharo-dev] expected failures

by btc＠openinworld.com

Feb. 26, 2014

Re: [Pharo-dev] Pharo is cool

by Sebastian Sastre

interesting So far Iâm using the sringify-ed walkbacks in emails, but (if the materializable dump isnât too big) it would definitively be cool to have it. Made me think, thanks for sharing Norbert & friends On Feb 26, 2014, at 11:31 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > Here the code operates on a shared queue > > EventDispatcher>>#consumeQueue > | block | > [ true ] whileTrue: [ > block := queue next. > [ block value ] > on: Error > do: [ :err | > self serializeStackFor: err. > Log error: 'block execution failed. stack saved' ] ] > > EventDispatcher>>#serializeStackFor: anError > [ FuelOutStackDebugAction > serializeTestFailureContext: anError signalerContext > toFileNamed: 'Stack-', (DateAndTime now printString),'.fuel' ] > on: Error > do: [:err| "simply continue...â ] > > Norbert > > > Am 26.02.2014 um 14:40 schrieb Esteban A. Maringolo <emaringolo(a)gmail.com>: > >> Pharo is Cool. Definitely. >> >> How do you set up the "fuel dump"? >> >> This morning I woke up with a "out of memory" crash (the first crash >> in two months), and going through the .log file didn't help much. >> >> Regards! >> >> >> Esteban A. Maringolo >> >> >> 2014-02-26 10:01 GMT-03:00 Norbert Hartl <norbert(a)hartl.name>: >>> The best smalltalk/pharo moments you get if you try things you want to have just in order to see they are already there. >>> >>> Today FileBrowser. >>> I switched one of my servers to dump to stack with fuel to disk if an exception occurs. Today I copied the files from the server to my local machine and opened a workspace starting to write an expression to open them. Then I thought it would be cool if I could use the file browser for it. So I opened it and navigated to the directory with the fuel files...et voilÃ ...as soon as I clicked on a fuel file a button "materialize" appeared which showed the stack from the server right away. >>> >>> Just brilliant! Well done! >>> >>> Norbert >> > >

Feb. 26, 2014

Re: [Pharo-dev] Stepping through with GLORP Proxies

by Eliot Miranda

Hi Esteban, find attached. Let me know of any problems. On Wed, Feb 26, 2014 at 8:32 AM, Esteban A. Maringolo <emaringolo(a)gmail.com>wrote: > Hi Eliot, > > > 2013-11-30 18:30 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > On Fri, Nov 29, 2013 at 2:22 PM, Esteban A. Maringolo < > emaringolo(a)gmail.com> > > wrote: > >> 2013/11/29 Eliot Miranda <eliot.miranda(a)gmail.com>: > > >> > I'll either prepare a change set or submit. It'll get done. > > >> I can continue stepping into until the change is ready. > > >> Please make it compatible with Pharo 2 (whatever that means in term of > >> code) :) > > > > > > OK, the code is now in Squeak trunk. What image should I use to > integrate > > into Pharo 2? A url please... > > I'm coming back late to this. Because the change wasn't integrated in > Pharo 2. > > Do you have the changeset applied to Squeak Trunk? I'd like to reapply > it in my Pharo 2 image (at my own risk). > Can you send it to may email address? > > Thank you! > > Esteban A. Maringolo > > -- best, Eliot

Feb. 26, 2014

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

by Max Leske

On 26.02.2014, at 17:47, btc(a)openInWorld.com wrote: > Thanks for that info Max. I can see "Files to archive" in the PharoLauncher configuration that I have access to. I don't have access to the configuration of Pharo-3.0-Issue-Validator to check, but I guess it should have an entry... > **/*/*.fuel > to gather fuel files from the subdirectories of the workspace. Thatâs right. Althoug I think that one â/*â is enough (the double asterisk should take care of subdirectories. see http://ant.apache.org/manual/Types/fileset.html) > > I have observed from running Pharo-3.0-Issue-Tracker-Image locally that Fuel files are created, that on the build server would located as follows... > /builds/workspace/Pharo-3.0-Issue-Validator/3570607022163494/Pharo-3.-2.0.fuel Cool that they are being generated, not so cool that nobody knew :) > > cheers -ben > > Max Leske wrote: >> >> 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. 26, 2014