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

easier start with Phobos

by Pavel Krivanek

If you want do develop applications in Pharo with native user interface, you can use Phobos framework based on Mozilla XULRunner client. However to start with it required to download a bundle for your platform and make some modifications in configuration files. To make the entry point easier I created a configuration of Phobos that you can download directly in the Configuration Browser in Pharo 3.0. During the download it will ask you whether you want to run PhobosDemo application. Answer yes and it will download required files for you including XULRunnerfor your platform into the working directory (on Linux it expects xulrunner is already preinstalled). Mainly on Windows make sure that Pharois enabled on your firewall because it needs to start a server (default port is 46528). Then it should show a window with rich demo of Phobos capabilities. You can play with sources of the PhobosDemo package. To start to write your own application firstly stop the demo: PhobosDemo allInstancesDo: #stop. Then make own subclass of PhobosApplication, create own subclass of PhobosComponent and specify it in your application class as mainClass. Star the server. app := MyPhobosApp new. app start. ..and restart the client. It is useful to run the client with the argument -jsconsole to show errors on the JavaScript side. On MacOS you need to modify the file PhobosDemo.app/Contents/MacOS/start.sh Please let me know if something will went wrong. Cheers, -- Pavel

Feb. 25, 2014

Re: [Pharo-dev] Pharo 3.0 "Sorry that name is already in use"

by Martin McClure

On 02/25/2014 12:27 PM, Pharo4Stef wrote: > probably that a changeset was created and it tried to reload a cs with the same name. Ah, so probably the changeset that had been created but not completed when the first update was interrupted, I'm guessing? That makes sense. Not crucial, of course, but it would be nice to avoid presenting the user with such vague errors -- either suppress the error or present enough information to understand it. Regards, -Martin > > On 25 Feb 2014, at 20:39, Martin McClure <martin(a)hand2mouse.com> wrote: > >> 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. >>

Feb. 25, 2014

Re: [Pharo-dev] Pharo contribution CI: Email on failed build

by Norbert Hartl

Am 25.02.2014 um 21:19 schrieb Esteban A. Maringolo <emaringolo(a)gmail.com>: > 2014-02-25 12:53 GMT-03:00 Norbert Hartl <norbert(a)hartl.name>: >> I was logged in but as this is a foreign service I forgot that I can configure it myself and assumed the opposite :) Just another embarrassing moment. > > Embarrasing for you or not, it helped me to learn about such feature > in Jenkins. ;) > The embarrassing moment wasnât about the knowledge of that feature because I use it on my own jenkins server. It was about not seeing that configure link :) Anyway, Iâm glad someone learned something. Norbert

Feb. 25, 2014

Re: [Pharo-dev] Pharo 3.0 "Sorry that name is already in use"

by Pharo4Stef

probably that a changeset was created and it tried to reload a cs with the same name. On 25 Feb 2014, at 20:39, Martin McClure <martin(a)hand2mouse.com> wrote: > 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] Pharo contribution CI: Email on failed build

by Esteban A. Maringolo

2014-02-25 12:53 GMT-03:00 Norbert Hartl <norbert(a)hartl.name>: > I was logged in but as this is a foreign service I forgot that I can configure it myself and assumed the opposite :) Just another embarrassing moment. Embarrasing for you or not, it helped me to learn about such feature in Jenkins. ;) Thanks! Esteban A. Maringolo

Feb. 25, 2014

Re: [Pharo-dev] image traffic

by Pharo4Stef

On 25 Feb 2014, at 17:48, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > > 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. +1 > > Christophe. >

Feb. 25, 2014

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