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

Re: [Pharo-dev] Responsible development

by Yuriy Tymchuk

On 02 Dec 2013, at 17:42, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Uko2 wrote >> Itâs not about stability of pharo 3, it about concurrency... This thread >> doesnât seem to have any reason > > Nothing is wasted. I appreciate your ideas. I never thought of these > benefits; I always took it for granted to run in one thread. Even if everything runs in one thread it doesnât mean that you need to block something. And I know that example with Nautilus or even with test runner may be to hard. Letâs take moose for example. While it is importing a model everything freezes. Is there a reason for that? I donât see any. In my opinion the problem is that we are not used to run non-instant operations in a separate process, because I do a lot of mistakes like this too. uko > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Responsible-development-tp4726686p4726763.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Dec. 2, 2013

Re: [Pharo-dev] transcript is plain bad

by Esteban Lorenzano

yes, please :) On Mon, Dec 2, 2013 at 7:56 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > > > The return of the toothpick is near. o/ > > No I will finish my logger :) > > Stef > >

Dec. 2, 2013

Re: [Pharo-dev] transcript is plain bad

by StÃ©phane Ducasse

> The return of the toothpick is near. o/ No I will finish my logger :) Stef

Dec. 2, 2013

Re: [Pharo-dev] transcript is plain bad

by phil＠highoctane.be

The return of the toothpick is near. o/ On Mon, Dec 2, 2013 at 6:54 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > I can tell that it does not work when loading partial code because all the > compiler warnings make sure that you > cannot see anythingâ¦. > I should have pushed my logger more. :( >

Dec. 2, 2013

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

by ClÃ©ment Bera

Ok then the latest Pharo 3 that you can find here: https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-4-Publish/ is the best image for this fix. However being the bleeding edge this image is stable but might have some issues. 2013/12/2 Eliot Miranda <eliot.miranda(a)gmail.com> > > > > On Sun, Dec 1, 2013 at 11:44 AM, ClÃ©ment Bera <bera.clement(a)gmail.com>wrote: > >> One thing with Pharo 3.0 is that the debugger is quite different than it >> used to be. >> >> It is now split into a model (DebugSession + DebugContext) and the view, >> SpecDebugger. I don't know what Eliot does have to change but the new code >> may require some extra work due to the debugger being different. >> > > The code is all down at the level of ContextPart so I hope it won't affect > the debugger changes at all. > > >> >> Now the new debugger is so much easier to understand and to edit that it >> shouldn't be an issue... >> >> >> 2013/12/1 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> >>> >>> On Dec 1, 2013, at 6:11 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> >>> wrote: >>> >>> > 2013/12/1 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> >> Hi eliot >>> >> >>> >> why in pharo 2.0? >>> >> Do you have some specific scenario? Because it would be better to >>> have it in >>> >> Pharo 30 alpha. >>> > >>> > In ten days I'll put a system into production (cross your fingers). It >>> > is built with Pharo 2 (what else?). >>> >>> Excellent news! >>> Will you be able to tell us more because Pharo needs more visibility. >>> >>> > So having this... will certainly help those who, like me, don't live >>> > in the bleeding edge. And will need to support (hence debug) a running >>> > system. >>> >>> I tend not to rely on just introduced features even in 2.0 and also >>> introducing something new can always >>> have side effect. >>> >>> > >>> > Regards, >>> > >>> > Esteban A. Maringolo >>> > >>> >>> >>> >> > > > -- > best, > Eliot >

Dec. 2, 2013

transcript is plain bad

by StÃ©phane Ducasse

I can tell that it does not work when loading partial code because all the compiler warnings make sure that you cannot see anythingâ¦. I should have pushed my logger more. :(

Dec. 2, 2013

Re: [Pharo-dev] [Seaside] Re: Grease conflicts #packages with RPackage

by StÃ©phane Ducasse

Guys Do you think that if an external library redefines the semantics of #class, it will be a Pharo bug? The solution is ***REALLY*** simple, rename packages into grPackages and you are done. >From the Pharo core perspective we cannot do anything. We are sorry but yes we introduced packages, package because it was needed. Stef > Is there a pharo bug entry for this? > > It currently exists in Moose 5.0 (on Pharo 3.0) > https://code.google.com/p/moose-technology/issues/detail?id=1018 > > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >

Dec. 2, 2013

Re: [Pharo-dev] Grease conflicts #packages with RPackage

by Marcus Denker

On 02 Dec 2013, at 18:25, Stephan Eggermont <stephan(a)stack.nl> wrote: > Is there a pharo bug entry for this? > > It currently exists in Moose 5.0 (on Pharo 3.0) > https://code.google.com/p/moose-technology/issues/detail?id=1018 > > I have never seen this happening in Pharo. It seems it is more grease related. Marcus

Dec. 2, 2013

Re: [Pharo-dev] Grease conflicts #packages with RPackage

by Stephan Eggermont

Is there a pharo bug entry for this? It currently exists in Moose 5.0 (on Pharo 3.0) https://code.google.com/p/moose-technology/issues/detail?id=1018

Dec. 2, 2013

Unifying Testing Ideas

by Sean P. DeNigris

We have some cool matchers (Phexample, StateSpecs), some nice mocking libraries (Mocketry, BabyMock), and Phexample's acknowledgement that tests build on each other. The problem is, it's hard to cherry-pick and build one's perfect test enviroment. For example: - Phexample and Mocketry, whose matching frameworks break each other - Phexample and BabyMock both require subclassing from their own TestCase subclass, so they can't be used together. I wonder what the solution is? Maybe some registration scheme? It'd be nice to be more coordinated here. As a first step, I manually merged BabyMock and Phexample to produce the following (IMHO) gorgeous tests... testNew self library should receive: #FMOD_System_Create:; with: FMOD_SYSTEM new; does: [ :h | h handle: 20. 0 ]. self library should receive: #FMOD_System_Init:; with: [ :a | a handle = 30 ]; answers: 0. ^ FmodSystem new. testNewSound | soundFile system | system := self given: #testNew. soundFile := FileLocator vmBinary. self library should receive: #FMOD_System_CreateSound:to:with:; with: soundFile fullName and: FMOD_SOUND new and: [ :h | h = system handle ]; answers: 0. ^ system newSoundFromFile: soundFile. testPlaySound | sound | sound := self given: #testNewSound. self library should receive: #FMOD_System:PlaySound:on:; with: sound system handle and: sound handle and: FmodChannel new; answers: 0. ^ sound play. testChannelIsPlaying | channel | channel := self given: #testPlaySound. self library should receive: #FMOD_Channel_IsPlaying:storeIn:; with: channel and: NBExternalAddress new; does: [ :c :isPlaying | isPlaying value: 1 ]. ^ channel isPlaying. The tests... let's call them specifications... clearly state how the object should talk to the FMOD library. The neat part of Phexample is that even though each specification uses the result of the last, it's smart enough not to fail the dependent if the #given: fails. It moves it into "expected failures" this is important because otherwise a failure deep in the system would make it difficult to pinpoint since there could be many failing specifications. n.b. in this case, I'm not sure that mocking is the best strategy and I may end up using a hand-written stub, but I wanted to do a case study. One area where I've really found mocks to shine is internal to one's system. That is, I'm writing an object and discover that it must talk to another as-yet-unwritten object. So I mock it out and in so doing define its API, which I then go implement. Also, the mocks are using a custom extension to BabyMock that allows you to pass the arguments do #does:, so it will not run on vanilla BabyMock ----- Cheers, Sean -- View this message in context: http://forum.world.st/Unifying-Testing-Ideas-tp4726787.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 2, 2013