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

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

Re: [Pharo-dev] Responsible development

by Nicolas Cellier

Of course, and obviously in Squeak/Pharo, code itself is kind of mutable state... (you modify some methodDictionary, subclasses etc...). So applying concurrency to tools handling that shared mutable state is... HARD. 2013/12/2 Frank Shearar <frank.shearar(a)gmail.com> > On 02 Dec 2013, at 19:30, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > In clojure they have STM so they can somehow control concurrent effect > with readonly structure (I forgot). > I thought that it would be interesting to see what would be an STM for > Pharo but this is a real phdsssss topic. > > On Dec 2, 2013, at 8:25 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > > there is also performance concerns. I remember once there was that code > for a fractal or something that let you define how many threads it would > use. 1 thread was very slow , 5-6 threads very fast but more threads > actually made code slower and slower the more threads I was adding. And > those were REAL threads (meaning the could take advantage of multiple cores > = real concurency) , not greenlets as the ones used by pharo and python. > > So there is always a catch. Concurrency is known to cause headache with > the exception of Clojure and Erlang both seem to make their users very > happy with their concurrency features. But both of these languages were > based on concurrency and not added it in as another feature to have. These > things are not easy to implement. > > > Both clojure and erlang have immutable state as the default. It is not > concurrency that is hard. It is shared mutable state that kills you. > > frank > > I come from python , super popular language, tons of developer and loads > of people complaining how concurrency is done. > > > On Mon, Dec 2, 2013 at 9:14 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> >> We try now to have responsive UIs in the sense the tools like Nautilus >> try to >> run things in a separate thread. >> >> I will do an experiment and fork each Nautilus opening to see if it can >> save my ass :P >> >> :) >> >> personnally I would be really against because just forking is just a way >> to have a lot more mess in the future. >> >> >> >> Ben >> >> On 02 Dec 2013, at 19:59, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> >> 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 <http://nabble.com/>. >> >> >> >> >> >> > >

Dec. 2, 2013

Re: [Pharo-dev] Responsible development

by phil＠highoctane.be

Hey, nice. I'll try that. On Mon, Dec 2, 2013 at 8:25 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > > On Mon, Dec 2, 2013 at 6:47 AM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > >> As Clement explained to be, the Cmd + . combo is only tested on VM >> bytecode "backjumps". >> > > It is also tested on every non-primitive send. > > >> >> So, if the bytecode is stuck with no backjumps, it is definitely stuck. >> >> I'd like to see where this occurs in the VM (maybe in the hope I could >> have a slow, but interruptible VM at all times) - this could take the form >> of a setting that gets turned on. >> > > You can always send SIGUSR1 to the VM on linux and Mac OS. You'll need to > open the console to see the output unless you run the VM from a terminal. > But you can find out what it's doing. > > >> >> Phil >> >> >> >> >> >> On Mon, Dec 2, 2013 at 3:30 PM, Esteban A. Maringolo < >> emaringolo(a)gmail.com> wrote: >> >>> 2013/12/2 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >>> > User interrupt (cmd + .) was not working? >>> >>> Most of the times for simple things it does, but sometimes it doesn't. >>> >>> Regards, >>> >>> Esteban A. Maringolo >>> >>> >> > > > -- > best, > Eliot >

Dec. 2, 2013

Re: [Pharo-dev] transcript is plain bad

by phil＠highoctane.be

And missing a ton of methods. Teh StackInterpreterSimulator is agreeing with this statement. On Mon, Dec 2, 2013 at 8:05 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > yes, the transcript is ThreadSafeTranscript > > > On Mon, Dec 2, 2013 at 8:00 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com>wrote: > >> Buy the way, is absence of Transcript class - ok? >> >> I know how it all works now, but is it ok? :) >> >> uko >> >> >> On 02 Dec 2013, at 19:58, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> 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] Responsible development

by Frank Shearar

On 02 Dec 2013, at 19:30, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > In clojure they have STM so they can somehow control concurrent effect with readonly structure (I forgot). > I thought that it would be interesting to see what would be an STM for Pharo but this is a real phdsssss topic. > > On Dec 2, 2013, at 8:25 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > >> there is also performance concerns. I remember once there was that code for a fractal or something that let you define how many threads it would use. 1 thread was very slow , 5-6 threads very fast but more threads actually made code slower and slower the more threads I was adding. And those were REAL threads (meaning the could take advantage of multiple cores = real concurency) , not greenlets as the ones used by pharo and python. >> >> So there is always a catch. Concurrency is known to cause headache with the exception of Clojure and Erlang both seem to make their users very happy with their concurrency features. But both of these languages were based on concurrency and not added it in as another feature to have. These things are not easy to implement. Both clojure and erlang have immutable state as the default. It is not concurrency that is hard. It is shared mutable state that kills you. frank >> I come from python , super popular language, tons of developer and loads of people complaining how concurrency is done. >> >> >> On Mon, Dec 2, 2013 at 9:14 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> We try now to have responsive UIs in the sense the tools like Nautilus try to >>> run things in a separate thread. >>> >>> I will do an experiment and fork each Nautilus opening to see if it can save my ass :P >> :) >> >> personnally I would be really against because just forking is just a way to have a lot more mess in the future. >> >> >>> >>> Ben >>> >>> On 02 Dec 2013, at 19:59, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>> >>>> >>>> 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] Responsible development

by Benjamin

On 02 Dec 2013, at 20:27, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> We try now to have responsive UIs in the sense the tools like Nautilus try to >>>> run things in a separate thread. >>>> >>>> I will do an experiment and fork each Nautilus opening to see if it can save my ass :P >>> :) >>> >>> personnally I would be really against because just forking is just a way to have a lot more mess in the future. >> >> Why ? > > Because you do not know when you invariants should hold. Normally you expect them to hold once the system is loaded. > Because loading for example act as an atomic action when you modify the system. Now if your thread can see and modify > different versions of the state be prepared to have really strange and difficult bugs to find. > > I prefer to have cache than to have forked processes around. Cache will not help you killing Nautilus when it freezes your image (why cache by the way ?) Ben > > Stef

Dec. 2, 2013

Re: [Pharo-dev] Responsible development

by StÃ©phane Ducasse

In clojure they have STM so they can somehow control concurrent effect with readonly structure (I forgot). I thought that it would be interesting to see what would be an STM for Pharo but this is a real phdsssss topic. On Dec 2, 2013, at 8:25 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > there is also performance concerns. I remember once there was that code for a fractal or something that let you define how many threads it would use. 1 thread was very slow , 5-6 threads very fast but more threads actually made code slower and slower the more threads I was adding. And those were REAL threads (meaning the could take advantage of multiple cores = real concurency) , not greenlets as the ones used by pharo and python. > > So there is always a catch. Concurrency is known to cause headache with the exception of Clojure and Erlang both seem to make their users very happy with their concurrency features. But both of these languages were based on concurrency and not added it in as another feature to have. These things are not easy to implement. > > I come from python , super popular language, tons of developer and loads of people complaining how concurrency is done. > > > On Mon, Dec 2, 2013 at 9:14 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> We try now to have responsive UIs in the sense the tools like Nautilus try to >> run things in a separate thread. >> >> I will do an experiment and fork each Nautilus opening to see if it can save my ass :P > :) > > personnally I would be really against because just forking is just a way to have a lot more mess in the future. > > >> >> Ben >> >> On 02 Dec 2013, at 19:59, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >>> >>> 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