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

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

Re: [Pharo-dev] Responsible development

by Sean P. DeNigris

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. ----- 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 phil＠highoctane.be

Traits do work nicely. What's your pain with them? (apart from the fact that the categorization in 2.0 is somewhat buggy)... Phil On Mon, Dec 2, 2013 at 5:11 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > > Iâm not complaining that new tools are bad. Iâm gust telling that Iâd > prefer other ones in first place. E.i. old class browser running in a > separate thread instead of nautilus, > > But it was never like that. > The old browser is just worse code but the logic is the same. > > > tools for traits instead of slots > I do not understand what you mean because this is totally orthogonal. > > > etcâ¦ Iâm not saying that slots are bad, no they are amazing. But traits > are powerful to but not widely used because we lack tools. > > Yes but not only :) > You see in PHP and perl they use them too. > > > The same bothers me with slots. Because we will need a tools for that, > and example with traits shows that we are not that good in it. > > Why? because we lack a nice metamodel (and we started to build ring for > that and it needs another iterations) > and a flexible way to build tool and not spaghetti code, > this is why we invested in Spec. > So > > > Once again, this is just my vision, and it seems to me that we are > building skyscraper on soil instead of creating a concrete base for it. > > LOL > We are doing infrastructure work since years. Just open your eyes to > realise it. > > FileSystem, > OPAL (imagine a new compiler) > New DebuggerModel, > Announcement, > AtomicQueue, > Cleaning morphic, > Spec, > Zinc > Better handling of rectangle > Better handling of layoutFrame > Better > better > better > > Do you want more look at the list of things we did: it is MASSIVE > MASSIVE and nearly only targeted at building > a strong and robust infrastructure. We just spent some time on > look but nothing compared to the rest. > > > Although you have more experience so maybe itâs better the way it is. > > > > uko > > > >> > >> > >>>>> Yes, This is a nice idea, but I was telling about the other thing. > Itâs really simple to start a new process in Pharo. Maybe we should > introduce common practices in pharo? When I was following Obj-C course, one > of the fundamental thing that was taught: do time consuming tasks in the > other process. > >>>> > >>>> > >>>> forking processes is not a solution. because you can have shared > resources problems and updates and â¦. > >>> > >>> Yes, you risk races which could be tricky to find/debug. > >>> > >>> I'm **very** interested what's the solution you propose here? > >>> > >>> Jan > >>> > >>>> > >>>>> So I want to write a chapter on the concurrent programming in Pharo, > but is question is: am I missing something? Because this looks quite > trivial. > >>>>> > >>>>> Uko > >>>>> > >>>> > >>>> > >>>> > >>> > >>> > >> > >> > > > > > > >

Dec. 2, 2013

Re: [Pharo-dev] Responsible development

by Yuriy Tymchuk

On 02 Dec 2013, at 17:11, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Iâm not complaining that new tools are bad. Iâm gust telling that Iâd prefer other ones in first place. E.i. old class browser running in a separate thread instead of nautilus, > > But it was never like that. > The old browser is just worse code but the logic is the same. Yes, so time was spent to make Nautilus. It could be spent to work on concurrency. Now itâs useless to discuss whether itâs good or not to go one way or the other. We can always find good and always find bad. Sorry for disturbing, Iâm getting back to work to make Pharo better :) uko > >> tools for traits instead of slots > I do not understand what you mean because this is totally orthogonal. > >> etcâ¦ Iâm not saying that slots are bad, no they are amazing. But traits are powerful to but not widely used because we lack tools. > > Yes but not only :) > You see in PHP and perl they use them too. > >> The same bothers me with slots. Because we will need a tools for that, and example with traits shows that we are not that good in it. > > Why? because we lack a nice metamodel (and we started to build ring for that and it needs another iterations) > and a flexible way to build tool and not spaghetti code, this is why we invested in Spec. > So > >> Once again, this is just my vision, and it seems to me that we are building skyscraper on soil instead of creating a concrete base for it. > > LOL > We are doing infrastructure work since years. Just open your eyes to realise it. > > FileSystem, > OPAL (imagine a new compiler) > New DebuggerModel, > Announcement, > AtomicQueue, > Cleaning morphic, > Spec, > Zinc > Better handling of rectangle > Better handling of layoutFrame > Better > better > better > > Do you want more look at the list of things we did: it is MASSIVE MASSIVE and nearly only targeted at building > a strong and robust infrastructure. We just spent some time on look but nothing compared to the rest. > >> Although you have more experience so maybe itâs better the way it is. >> >> uko >> >>> >>> >>>>>> Yes, This is a nice idea, but I was telling about the other thing. Itâs really simple to start a new process in Pharo. Maybe we should introduce common practices in pharo? When I was following Obj-C course, one of the fundamental thing that was taught: do time consuming tasks in the other process. >>>>> >>>>> >>>>> forking processes is not a solution. because you can have shared resources problems and updates and â¦. >>>> >>>> Yes, you risk races which could be tricky to find/debug. >>>> >>>> I'm **very** interested what's the solution you propose here? >>>> >>>> Jan >>>> >>>>> >>>>>> So I want to write a chapter on the concurrent programming in Pharo, but is question is: am I missing something? Because this looks quite trivial. >>>>>> >>>>>> Uko >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >

Dec. 2, 2013

Roassal Bug related to Athens?

by Usman Bhatti

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. 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? regards, Usman

Dec. 2, 2013

Re: [Pharo-dev] Responsible development

by phil＠highoctane.be

Run 2 images and Monticello. --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller On Mon, Dec 2, 2013 at 4:35 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > On 02 Dec 2013, at 16:24, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > > Uko2 wrote > >> Shouldnât we develop our tools in a more friendly way? > > > > That would be fantastic. This thread is very interesting! > > > > And, I just want to remind everyone that Pharo 3.0 is unreleased... Do > not > > expect it to be stable, > > Itâs not about stability of pharo 3, it about concurrency. And itâs the > same problem in 1.2, 1.3, 1.4, 2.0. I can write ruby code while running > tests, but I cannot do that in Pharo. > This thread doesnât seem to have any reason, so I should just apologise > for creating it because of frustration and ask everyone to stop discussing > this :) > > > although it is remarkably so for the amount of deep > > changes that have been made. Maybe that has lulled us into a false sense > of > > security/expectation. Remember, caveat emptor until it is released, when > > there obviously shouldn't be any changes which might introduce this kind > of > > bug. > > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: > http://forum.world.st/Responsible-development-tp4726686p4726749.html > > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > >

Dec. 2, 2013

Re: [Pharo-dev] Responsible development

by StÃ©phane Ducasse

> Iâm not complaining that new tools are bad. Iâm gust telling that Iâd prefer other ones in first place. E.i. old class browser running in a separate thread instead of nautilus, But it was never like that. The old browser is just worse code but the logic is the same. > tools for traits instead of slots I do not understand what you mean because this is totally orthogonal. > etcâ¦ Iâm not saying that slots are bad, no they are amazing. But traits are powerful to but not widely used because we lack tools. Yes but not only :) You see in PHP and perl they use them too. > The same bothers me with slots. Because we will need a tools for that, and example with traits shows that we are not that good in it. Why? because we lack a nice metamodel (and we started to build ring for that and it needs another iterations) and a flexible way to build tool and not spaghetti code, this is why we invested in Spec. So > Once again, this is just my vision, and it seems to me that we are building skyscraper on soil instead of creating a concrete base for it. LOL We are doing infrastructure work since years. Just open your eyes to realise it. FileSystem, OPAL (imagine a new compiler) New DebuggerModel, Announcement, AtomicQueue, Cleaning morphic, Spec, Zinc Better handling of rectangle Better handling of layoutFrame Better better better Do you want more look at the list of things we did: it is MASSIVE MASSIVE and nearly only targeted at building a strong and robust infrastructure. We just spent some time on look but nothing compared to the rest. > Although you have more experience so maybe itâs better the way it is. > > uko > >> >> >>>>> Yes, This is a nice idea, but I was telling about the other thing. Itâs really simple to start a new process in Pharo. Maybe we should introduce common practices in pharo? When I was following Obj-C course, one of the fundamental thing that was taught: do time consuming tasks in the other process. >>>> >>>> >>>> forking processes is not a solution. because you can have shared resources problems and updates and â¦. >>> >>> Yes, you risk races which could be tricky to find/debug. >>> >>> I'm **very** interested what's the solution you propose here? >>> >>> Jan >>> >>>> >>>>> So I want to write a chapter on the concurrent programming in Pharo, but is question is: am I missing something? Because this looks quite trivial. >>>>> >>>>> Uko >>>>> >>>> >>>> >>>> >>> >>> >> >> > >

Dec. 2, 2013