February 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo is cool

by Norbert Hartl

Am 26.02.2014 um 21:21 schrieb Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > > On Wed, Feb 26, 2014 at 3:53 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > > 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. > > > Forgot... "just be careful 3": it may happen that you cannot correctly materialize (not serialization) the graph: a method has changed, a class is missing..whatever... So what I did in the fuel out of failure tests is to add to the serializer header all the info (as plain strings) that we normally have in the PharoDebug.log. This "header" will always be able to be materialized.... this way, I don't have the risk of not being able to materialize and hence loose info, and yet I don't need PharoDebug.log as well. If you don't do what I did, then you likely need also pharoDebug.log just in case... > That is unlikely to happen. My workflow is that every deployed image goes through the CI server. If a problem arises I download that same image from the CI server and load the stacks back into this. Everything is else is IMHO asking for trouble because contexts wonât map properly. > I recommend everyone interested in this topic to take a look to: #serializeTestFailureContext:toFileNamed: > That is what I am using because it does what I want to happen. It is only the selector that doesnât fit that well :) thanks a lot for this information Mariano. This is highly appreciated to get infos from someone that knows the stuff. Norbert > Cheers, > > > 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 > > > > > -- > Mariano > http://marianopeck.wordpress.com

Feb. 26, 2014

about dateAndTime and TimeStamp

by Pharo4Stef

one of these days we will have to remove TimeStamp because it just adds noise to the system (in fact I would not have any problem to see DateAndTime renamed as timestamp - but having the two for nothing looks useless to me). Stef

Feb. 26, 2014

Re: [Pharo-dev] Pharo-Business: a new mailing-list

by Esteban A. Maringolo

Hi Stef, Can you explain what's the purpose of this list? I don't fully get it. What is to be discussed there? Market for Pharo? Derived businesses from pharo? (like pharocloud?). Thank you! Regards! Esteban A. Maringolo 2014-02-26 16:05 GMT-03:00 Pharo4Stef <pharo4Stef(a)free.fr>: > 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 is cool

by Mariano Martinez Peck

On Wed, Feb 26, 2014 at 3:53 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > > 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. > > Forgot... "just be careful 3": it may happen that you cannot correctly *materialize (not serialization)* the graph: a method has changed, a class is missing..whatever... So what I did in the fuel out of failure tests is to add to the serializer header all the info (as plain strings) that we normally have in the PharoDebug.log. This "header" will always be able to be materialized.... this way, I don't have the risk of not being able to materialize and hence loose info, and yet I don't need PharoDebug.log as well. If you don't do what I did, then you likely need also pharoDebug.log just in case... I recommend everyone interested in this topic to take a look to: #serializeTestFailureContext:toFileNamed: Cheers, > 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 > > > -- Mariano http://marianopeck.wordpress.com

Feb. 26, 2014

Re: [Pharo-dev] Pharo-Business: a new mailing-list

by Santiago Bragagnolo

I'm in :) 2014-02-26 20:05 GMT+01:00 Pharo4Stef <pharo4Stef(a)free.fr>: > 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] iPad version does not work ?

by Alexandre Bergel

So, can we have Pharo on the iphone and ipad? Alexandre On Feb 26, 2014, at 7:33 AM, jannik laval <jannik.laval(a)gmail.com> wrote: > Thank you Esteban, > It works. I failed probably because I did not remove the app in the simulator. > > Thank you again. > > Jannik > > > 2014-02-25 13:26 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > btw what can be happening is that xcode fails to build freetype2. > the way to workaround this problem is: > > first, build a makefile version of the app: > > sh build.sh > > then, re-prepare for xcode: > > rm CMakeCache.txt > cmake -G Xcode . > > > (that will build freetype2 first, and when xcode tries to get it, it will be already there, so it will ski the build part, who often and mysteriously fails) > > Esteban > > > On 25 Feb 2014, at 13:22, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> that works for me. >> what is the problem you are having? >> >> >> On 25 Feb 2014, at 12:10, jannik laval <jannik.laval(a)gmail.com> wrote: >> >>> It seems to not work :( >>> Here is the process I follow: >>> >>> === >>> git clone https://github.com/pharo-project/pharo-vm.git >>> cd pharo-vm/image/ >>> ./newImage.sh ==> it load a pharo20 >>> >>> ./pharo generator.image eval --save PharoIPhoneBuilder buildIPhoneSimulator >>> >>> cd ../iosbuild/resources/ >>> >>> ./generate.sh ==> it is a pharo1.4 image. >>> >>> sudo ../scripts/extract-commit-info.sh >>> sudo cmake -G Xcode . >>> >>> open iPharoSimulator.xcodeproj/ >>> >>> In the list "ALL_BUILD", go to edit scheme, and change the Executable field to the iPharo. >>> Select your iOS version and compile it. >>> === >>> >>> Jannik >>> >>> >>> 2014-02-25 9:23 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>> >>> On 25 Feb 2014, at 08:04, Pharo4Stef <pharo4Stef(a)free.fr> wrote: >>> >>>> >>>> On 25 Feb 2014, at 01:31, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> >>>>> it *should* be working now. >>>>> >>>>> cheers >>>>> Esteban (who needs to write more documentation, but he does what he can :) ) >>>> >>>> No need lentghly sentences just some nice bulleted lists of actions >>>> and we can do something with that. >>> >>> yes, I willâ¦ but as I always say: time is a tyrant. And writing documentation is boring :) >>> Anyway most of the process is already covered with current documentation, I just need to add a few points. >>> >>> (no one reads documentation either, is a bit annoyingâ¦ every time is like starting from scratchâ¦ But donât take me into appoint, Iâm having a cynical morning :P) >>> >>> Esteban >>> >>>> >>>> >>>> >>>>> >>>>> On 24 Feb 2014, at 08:58, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>> >>>>>> not yetâ¦ so far I restored the build capability, not the image event handling :( >>>>>> (nevertheless, Iâm on it :) ) >>>>>> >>>>>> Esteban >>>>>> >>>>>> On 24 Feb 2014, at 08:00, jannik laval <jannik.laval(a)gmail.com> wrote: >>>>>> >>>>>>> Hi Esteban, >>>>>>> >>>>>>> Did you already try ? >>>>>>> I saw a message on the VM repo related to iOS, not sure it is for my problem. >>>>>>> >>>>>>> Cheers, >>>>>>> Jannik >>>>>>> >>>>>>> >>>>>>> 2014-01-29 17:32 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>>>>>> oksâ¦ I will take a lookâ¦ as soon as I can :S >>>>>>> >>>>>>> (damnâ¦ I need to learn how to do a mitosisâ¦) >>>>>>> >>>>>>> On 29 Jan 2014, at 17:28, jannik laval <jannik.laval(a)gmail.com> wrote: >>>>>>> >>>>>>>> I confirm that it does not work: the simulator compile (but not the non-simulator). >>>>>>>> Then the image cannot be open: I have a white screen. >>>>>>>> Here is my process: >>>>>>>> >>>>>>>> === >>>>>>>> 1) git clone https://github.com/pharo-project/pharo-vm.git >>>>>>>> 2) in ./image dir prepare a VMMaker image (including download of a pharo 2.0): >>>>>>>> ./newImage.sh >>>>>>>> >>>>>>>> 3)open the generated.image and execute: >>>>>>>> === >>>>>>>> PharoIPhoneBuilder buildIPhone. >>>>>>>> â or â >>>>>>>> PharoIPhoneBuilder buildIPhoneSimulator. >>>>>>>> >>>>>>>> 4) Generate your iPhone image in iosbuild/resources/ >>>>>>>> ./generate.sh >>>>>>>> >>>>>>>> 5) In dir ./build: >>>>>>>> sh build.sh >>>>>>>> === >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Jannik >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2014-01-29 Esteban Lorenzano <estebanlm(a)gmail.com> >>>>>>>> and btwâ¦ >>>>>>>> >>>>>>>> iosbuild/resource$ ./generate.sh >>>>>>>> >>>>>>>> should generate a 1.4 image that *should* work in ipad (no idea if that will be the case, its been more than 6months since I do not test it and vm changed since then). >>>>>>>> >>>>>>>> Esteban >>>>>>>> >>>>>>>> >>>>>>>> On 29 Jan 2014, at 10:23, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>>>>> >>>>>>>>> PharoIPhoneBuilder buildIPhone. >>>>>>>>> >>>>>>>>> it should generate all sources and a âbuild.shâ >>>>>>>>> >>>>>>>>> then >>>>>>>>> >>>>>>>>> build$ sh build.sh >>>>>>>>> >>>>>>>>> will generate an xcode project. >>>>>>>>> >>>>>>>>> and let me rememberâ¦ mmmâ¦ yeah, that was all :) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 29 Jan 2014, at 08:10, jannik laval <jannik.laval(a)gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Hi Esteban, >>>>>>>>>> >>>>>>>>>> Hum, this means that my instructions are outdated. >>>>>>>>>> Where are the right instructions ? The ones on Github do not mention IOS. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Jannik >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2014-01-29 Esteban Lorenzano <estebanlm(a)gmail.com> >>>>>>>>>> >>>>>>>>>> On 29 Jan 2014, at 00:18, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, Jan 28, 2014 at 2:46 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>>>>>>>> because you are not following the instructions ;) >>>>>>>>>>> >>>>>>>>>>> basicallyâ¦ you can generate them by: >>>>>>>>>>> >>>>>>>>>>> build$ ../scripts/extract-commit-info.sh >>>>>>>>>>> >>>>>>>>>>> I asked for this info last week ;-). Thanks! >>>>>>>>>> >>>>>>>>>> hey! I answered you! :P >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> But this is alarming: >>>>>>>>>>> >>>>>>>>>>> McStalker.pharovm$ ./scripts/extract-commit-info.sh >>>>>>>>>>> readlink: ./scripts/extract-commit-info.sh Invalid argument >>>>>>>>>>> >>>>>>>>>>> I suggest changing >>>>>>>>>>> SCRIPT_DIR=`readlink "$0"` || SCRIPT_DIR="$0"; >>>>>>>>>>> to read >>>>>>>>>>> SCRIPT_DIR=`readlink "$0" >/dev/null` || SCRIPT_DIR="$0"; >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Esteban >>>>>>>>>>> >>>>>>>>>>> On 28 Jan 2014, at 23:15, jannik.laval <jannik.laval(a)gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Thank you, I am trying the latest one. >>>>>>>>>>>> >>>>>>>>>>>> When compiling for IOS, I have an error in sqSCCSVersion.h >>>>>>>>>>>> >>>>>>>>>>>> #include "vmVersionInfo.h" // defines REVISION_STRING >>>>>>>>>>>> the file is not found. >>>>>>>>>>>> >>>>>>>>>>>> Anyone knows where is this file ? >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Jannik >>>>>>>>>>>> >>>>>>>>>>>> On Jan 28, 2014, at 8:58 PM, Pharo4Stef <pharo4Stef(a)free.fr> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> jannik the latest vm is not on gitoruous anymore but git >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 27 Jan 2014, at 22:03, jannik laval <jannik.laval(a)gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hum, have I the correct repository ? >>>>>>>>>>>>>> I used this one: https://git.gitorious.org/cogvm/cog-osx.git >>>>>>>>>>>>>> >>>>>>>>>>>>>> But, I just saw that this one exists: https://github.com/pharo-project/pharo-vm >>>>>>>>>>>>>> I should use it no? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Jannik >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2014-01-27 Esteban Lorenzano <estebanlm(a)gmail.com> >>>>>>>>>>>>>> 1.4 and 2.0 worked out of the boxâ¦ and after my latest integration, 3.0 should work too. >>>>>>>>>>>>>> I will take a look as soon as I have half and hour to spare. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Esteban >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 27 Jan 2014, at 14:27, jannik laval <jannik.laval(a)gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi list, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Does anyone try to load Pharoon iPad ? >>>>>>>>>>>>>>> In the past, the version 1.4 worked with XCode 4.4. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I just tried to recompile it with the new XCode (5.0.2). >>>>>>>>>>>>>>> The VM seems to work, but the pharo 1.4 image freezes. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Any idea ? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> ~~Jannik Laval~~ >>>>>>>>>>>>>>> Ãcole des Mines de Douai >>>>>>>>>>>>>>> Enseignant-chercheur >>>>>>>>>>>>>>> http://www.jannik-laval.eu >>>>>>>>>>>>>>> http://car.mines-douai.fr/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> ~~Jannik Laval~~ >>>>>>>>>>>>>> Ãcole des Mines de Douai >>>>>>>>>>>>>> Enseignant-chercheur >>>>>>>>>>>>>> http://www.jannik-laval.eu >>>>>>>>>>>>>> http://car.mines-douai.fr/ >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> best, >>>>>>>>>>> Eliot >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> ~~Jannik Laval~~ >>>>>>>>>> Ãcole des Mines de Douai >>>>>>>>>> Enseignant-chercheur >>>>>>>>>> http://www.jannik-laval.eu >>>>>>>>>> http://car.mines-douai.fr/ >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> ~~Jannik Laval~~ >>>>>>>> Ãcole des Mines de Douai >>>>>>>> Enseignant-chercheur >>>>>>>> http://www.jannik-laval.eu >>>>>>>> http://car.mines-douai.fr/ >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> ~~Jannik Laval~~ >>>>>>> Ãcole des Mines de Douai >>>>>>> Enseignant-chercheur >>>>>>> http://www.jannik-laval.eu >>>>>>> http://car.mines-douai.fr/ >>>>>>> >>>>>> >>>>> >>>> >>> >>> >>> >>> >>> -- >>> ~~Jannik Laval~~ >>> Ãcole des Mines de Douai >>> Enseignant-chercheur >>> http://www.jannik-laval.eu >>> http://car.mines-douai.fr/ >>> >> > > > > > -- > ~~Jannik Laval~~ > Ãcole des Mines de Douai > Enseignant-chercheur > http://www.jannik-laval.eu > http://car.mines-douai.fr/ > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 26, 2014

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