- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Roassal Bug related to Athens?

by kilon alios

and how exactly you expect that people would know what a session is ? or why that would be an issue with nativeboost or Athens ? I did not even know that there was a tutorial included about it in the Athens tutorial which is package that existing in the smalltalkhub repo of Athens in smalltalkhub for some strange reason the tutorial is not included with the standard distribution of Pharo 3 even though Athens suppose to play a huge role for Pharo in the future replacing all drawings. I have even purchased both Pharo books and they don't mention this. You cant blame him for not knowing or not googling about it. You cant google what you are not aware of. And you cant be aware if you dont have some sort of documentation in front of you. And no a maiing is not documentation. The least you could do is at smalltalkhub description tell to people to go fetch the Athens-Tutorial package and learn from it. At least that would save you a substantial amount of replies in the near future. From the tutorial alone he would have learned about the session issue and he would not have to ask and that would save him time and you. I love your work and appreciate your effort but whether we like it or not, these things are very important. On Mon, Dec 2, 2013 at 11:02 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 2 December 2013 17:14, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: > >> Hello Igor, >> >> Moose 5.0 is using Athens as default canvas for Roassal and we have bug >> with Roassal that seems to be related to Athens. >> http://code.google.com/p/moose-technology/issues/detail?id=1019 >> >> I think it is related to the fact that we create a surface in the OS with >> Athens and once we quit the image, the surface is destroyed as well. So, >> when image is restarted with the visualization trying to use the surface, >> we get the error. >> >> right. > > >> Could you point to what possibly can be done to avoid this error? Merely >> checking the existence of an appropriate drawing surface in Athens every >> time visualization is drawn, would it suffice? >> >> yes.. i explained and given examples multiple times both for NB and > Athens (and last time it was like couple weeks ago). > > http://lmgtfy.com/?q=nativeboost+session+aware&l=1 > > regards, >> >> Usman >> > > > > -- > Best regards, > Igor Stasenko. >

Dec. 2, 2013

Re: [Pharo-dev] Roassal Bug related to Athens?

by Usman Bhatti

On Mon, Dec 2, 2013 at 10:12 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > http://code.google.com/p/nativeboost/wiki/SessionManagement > This one's much more helpful. > > > > On 2 December 2013 22:02, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> >> On 2 December 2013 17:14, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: >> >>> Hello Igor, >>> >>> Moose 5.0 is using Athens as default canvas for Roassal and we have bug >>> with Roassal that seems to be related to Athens. >>> http://code.google.com/p/moose-technology/issues/detail?id=1019 >>> >>> I think it is related to the fact that we create a surface in the OS >>> with Athens and once we quit the image, the surface is destroyed as well. >>> So, when image is restarted with the visualization trying to use the >>> surface, we get the error. >>> >>> right. >> >> >>> Could you point to what possibly can be done to avoid this error? Merely >>> checking the existence of an appropriate drawing surface in Athens every >>> time visualization is drawn, would it suffice? >>> >>> yes.. i explained and given examples multiple times both for NB and >> Athens (and last time it was like couple weeks ago). >> >> http://lmgtfy.com/?q=nativeboost+session+aware&l=1 >> >> regards, >>> >>> Usman >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > Best regards, > Igor Stasenko. >

Dec. 2, 2013

Re: [Pharo-dev] Unifying Testing Ideas

by Sean P. DeNigris

Attila Magyar wrote > The reason for having the base class is to verify the expectations at the > end of the tests automatically. Doing this manually is possible (context > assertSatisfied), but probably people would forget it without this > automatic mechanism. In Java for example, mock libraries use custom JUnit > runners to do this, but I haven't found something like this in SUnit. If > there is a better way to do this please let me know. I understand the motivation. My question is how do we create appropriate hooks so that we don't get into these conflicts? I made a few enhancements to BabyMock: - anyArgument now inst var of BabyMockTestCase, similar to BmAnyMessage - #does: now optionally takes arguments The second one turns: handle := FMOD_SYSTEM new. library should receive: #FMOD_System_Create:; with: [ :a | a = handle ifTrue: [ handle := a. handle handle: 20. true ] ifFalse: [ false ] ]; answer: 0. library should receive: #FMOD_System_Init:; with: [ :a | a = handle ]; answers: 0. ...into: library should receive: #FMOD_System_Create:; with: FMOD_SYSTEM new; does: [ :h | h handle: 20. 0 ]. library should receive: #FMOD_System_Init:; with: [ :a | a handle = 20 ]; answers: 0. ... eliminating the temporary, and the separate #with: and #answer: send in the first expectation. I pushed them to http://smalltalkhub.com/mc/SeanDeNigris/FMOD/main/ since that's where I was using them, but if you give me access to the BM repo and you like the changes, I will clean them up and push there. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Unifying-Testing-Ideas-tp4726787p4726855.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 2, 2013

Re: [Pharo-dev] Roassal Bug related to Athens?

by Igor Stasenko

http://code.google.com/p/nativeboost/wiki/SessionManagement On 2 December 2013 22:02, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 2 December 2013 17:14, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: > >> Hello Igor, >> >> Moose 5.0 is using Athens as default canvas for Roassal and we have bug >> with Roassal that seems to be related to Athens. >> http://code.google.com/p/moose-technology/issues/detail?id=1019 >> >> I think it is related to the fact that we create a surface in the OS with >> Athens and once we quit the image, the surface is destroyed as well. So, >> when image is restarted with the visualization trying to use the surface, >> we get the error. >> >> right. > > >> Could you point to what possibly can be done to avoid this error? Merely >> checking the existence of an appropriate drawing surface in Athens every >> time visualization is drawn, would it suffice? >> >> yes.. i explained and given examples multiple times both for NB and > Athens (and last time it was like couple weeks ago). > > http://lmgtfy.com/?q=nativeboost+session+aware&l=1 > > regards, >> >> Usman >> > > > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.

Dec. 2, 2013

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

by Mariano Martinez Peck

On Mon, Dec 2, 2013 at 6:03 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Stef wrote: > >Do you think that if an external library redefines the semantics of > #class, it will be a Pharo bug? > > I donât know. I know I have 35 implementers of #packages in my Moose > image, and 191 senders. > You will only have problems with class side #packages. Are all those 35 class side? Cheers, > And I know that in Magritte 3 we changed from using #description to > #magritteDescription to avoid > polluting the namespace with a word that is commonly used for other > things. At the same time > I donât exactly enjoy adding prefixes everywhere. DeprecationFinder tells > me there are 60 projects > on smalltalkhub using #packages. And I know I have to be careful about > where I use #name. > > And when taking a look at the problem, I immediately run into lots of > methods flagged #todo, a.o. > (CompiledMethod>packageFromOrganizer:) that seems to suggest a different > solution. > > I can imagine a more effective way of convincing Grease maintainers that > they should switch API :) > > Stephan > > > > > -- Mariano http://marianopeck.wordpress.com

Dec. 2, 2013

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

by Stephan Eggermont

Stef wrote: >Do you think that if an external library redefines the semantics of #class, it will be a Pharo bug? I donât know. I know I have 35 implementers of #packages in my Moose image, and 191 senders. And I know that in Magritte 3 we changed from using #description to #magritteDescription to avoid polluting the namespace with a word that is commonly used for other things. At the same time I donât exactly enjoy adding prefixes everywhere. DeprecationFinder tells me there are 60 projects on smalltalkhub using #packages. And I know I have to be careful about where I use #name. And when taking a look at the problem, I immediately run into lots of methods flagged #todo, a.o. (CompiledMethod>packageFromOrganizer:) that seems to suggest a different solution. I can imagine a more effective way of convincing Grease maintainers that they should switch API :) Stephan

Dec. 2, 2013

Re: [Pharo-dev] Roassal Bug related to Athens?

by Igor Stasenko

On 2 December 2013 17:14, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: > Hello Igor, > > Moose 5.0 is using Athens as default canvas for Roassal and we have bug > with Roassal that seems to be related to Athens. > http://code.google.com/p/moose-technology/issues/detail?id=1019 > > I think it is related to the fact that we create a surface in the OS with > Athens and once we quit the image, the surface is destroyed as well. So, > when image is restarted with the visualization trying to use the surface, > we get the error. > > right. > Could you point to what possibly can be done to avoid this error? Merely > checking the existence of an appropriate drawing surface in Athens every > time visualization is drawn, would it suffice? > > yes.. i explained and given examples multiple times both for NB and Athens (and last time it was like couple weeks ago). http://lmgtfy.com/?q=nativeboost+session+aware&l=1 regards, > > Usman > -- Best regards, Igor Stasenko.

Dec. 2, 2013

Re: [Pharo-dev] transcript is plain bad

by Sean P. DeNigris

EstebanLM wrote > yes, the transcript is ThreadSafeTranscript Does "ThreadSafe" mean I don't have to wrap all my debug logging in "WorldState addDeferredUIMessage: [ Transcript... ]? That would save a lot of time :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/transcript-is-plain-bad-tp4726795p4726848.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 2, 2013

Re: [Pharo-dev] Unifying Testing Ideas

by Sean P. DeNigris

Attila Magyar wrote > The reason for having the base class is to verify the expectations at the > end of the tests automatically. Doing this manually is possible (context > assertSatisfied), but probably people would forget it without this > automatic mechanism. In Java for example, mock libraries use custom JUnit > runners to do this, but I haven't found something like this in SUnit. If > there is a better way to do this please let me know. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Unifying-Testing-Ideas-tp4726787p4726845.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 2, 2013

Re: [Pharo-dev] Unifying Testing Ideas

by Attila Magyar

Sean P. DeNigris wrote > - Phexample and BabyMock both require subclassing from their own TestCase > subclass, so they can't be used together. The reason for having the base class is to verify the expectations at the end of the tests automatically. Doing this manually is possible (context assertSatisfied), but probably people would forget it without this automatic mechanism. In Java for example, mock libraries use custom JUnit runners to do this, but I haven't found something like this in SUnit. If there is a better way to do this please let me know. -- View this message in context: http://forum.world.st/Unifying-Testing-Ideas-tp4726787p4726837.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 2, 2013