- Pharo-dev - lists.pharo.org

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

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

by Eliot Miranda

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

Re: [Pharo-dev] Responsible development

by Yuriy Tymchuk

Amen On 02 Dec 2013, at 18:06, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: > And we should all work to *make it better*, in one way or another! In the end we will be satisfied with what we have! ;-) > > Keep up the good work! > > Cheers, > R > > On Dec 2, 2013, at 5:47 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> I'm not satisfied to what we have but we have it. > >

Dec. 2, 2013

Re: [Pharo-dev] Responsible development

by Roberto Minelli

And we should all work to *make it better*, in one way or another! In the end we will be satisfied with what we have! ;-) Keep up the good work! Cheers, R On Dec 2, 2013, at 5:47 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I'm not satisfied to what we have but we have it.

Dec. 2, 2013

Re: [Pharo-dev] Responsible development

by StÃ©phane Ducasse

>> > > Yes, so time was spent to make Nautilus. It could be spent to work on concurrency. Concurrency is not magic. You have a strange belief. Pharo has nearly the same model than Java or any language with semaphore, and others basic concurrency constructs. Concurrency is not the panacea. It implies duplication or synchronisation points. What you are calling concurrency is robust and isolated execution. This is not the same and it is difficult to achieve especially with an open-source written in itself and reflective. > Now itâs useless to discuss whether itâs good or not to go one way or the other. No I give you chance to educate you and learn. I'm not spending time for the sake of arguing but I invest in you :) Else I would not even reply. > We can always find good and always find bad. Sorry for disturbing, Iâm getting back to work to make Pharo better :) Yes. I'm not satisfied to what we have but we have it.

Dec. 2, 2013