- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Responsible development

by Yuriy Tymchuk

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. 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 On 02 Dec 2013, at 14:21, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Sidenote about this. > > I don't know about this particular problem you faced with Nautilus. > But the issue is "unfixable", IMHO, because everything runs in the > same process. > > So there is no way to stop the current active process if it is REALLY > stuck (100% CPU, 1 CORE). If it gets into an infinite unbreakable > loop, or indefinitely blocking on I/O, then the entire VM gets > unresponsive. > > For that reason I think that nothing should run in the UI Thread > (which in Pharo is the main thread), except for event handling and > rendering. Or... the VM should notice abnormal processes eating a lot > of resources and warn the user. > > That's one nice feature of Smalltalk/X, every windows runs its own > thread, with its own event queue, etc. You can kill it safely, without > trowing away the whole image. > > Regards! > > Esteban A. Maringolo > > > 2013/12/2 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: >> Hi guys, I have some thoughts about how we develop for Pharo. >> >> I was doing something in in Nautilus, and it started rising errors, which is ok (well, itâs not ok, but this happens during so rapid development). But then I clicked on something in Nautilus and ended up in the infinite loop. Shouldnât we develop our tools in a more friendly way? When my finder freezes I donât have to restart OS X, but when Nautilus freezes I have to restart Pharo. >> >> Uko >

Dec. 2, 2013

Re: [Pharo-dev] Responsible development

by Esteban Lorenzano

yes, tocayo, you are right... but there is a design problem since ever and fix that will not be easy. Also, there is the notion of "main thread" internal to pharo, and the "main thread" relative to the OS. And AFAIK, the vm runs in the main thread (in mac there is a line to uncomment for moving out main thread, but they were a problem with certain callbacks who prevent me to use it... but well, we should review that too). Esteban On Mon, Dec 2, 2013 at 2:21 PM, Esteban A. Maringolo <emaringolo(a)gmail.com>wrote: > Sidenote about this. > > I don't know about this particular problem you faced with Nautilus. > But the issue is "unfixable", IMHO, because everything runs in the > same process. > > So there is no way to stop the current active process if it is REALLY > stuck (100% CPU, 1 CORE). If it gets into an infinite unbreakable > loop, or indefinitely blocking on I/O, then the entire VM gets > unresponsive. > > For that reason I think that nothing should run in the UI Thread > (which in Pharo is the main thread), except for event handling and > rendering. Or... the VM should notice abnormal processes eating a lot > of resources and warn the user. > > That's one nice feature of Smalltalk/X, every windows runs its own > thread, with its own event queue, etc. You can kill it safely, without > trowing away the whole image. > > Regards! > > Esteban A. Maringolo > > > 2013/12/2 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > > Hi guys, I have some thoughts about how we develop for Pharo. > > > > I was doing something in in Nautilus, and it started rising errors, > which is ok (well, itâs not ok, but this happens during so rapid > development). But then I clicked on something in Nautilus and ended up in > the infinite loop. Shouldnât we develop our tools in a more friendly way? > When my finder freezes I donât have to restart OS X, but when Nautilus > freezes I have to restart Pharo. > > > > Uko > >

Dec. 2, 2013

Re: [Pharo-dev] Responsible development

by Esteban A. Maringolo

Sidenote about this. I don't know about this particular problem you faced with Nautilus. But the issue is "unfixable", IMHO, because everything runs in the same process. So there is no way to stop the current active process if it is REALLY stuck (100% CPU, 1 CORE). If it gets into an infinite unbreakable loop, or indefinitely blocking on I/O, then the entire VM gets unresponsive. For that reason I think that nothing should run in the UI Thread (which in Pharo is the main thread), except for event handling and rendering. Or... the VM should notice abnormal processes eating a lot of resources and warn the user. That's one nice feature of Smalltalk/X, every windows runs its own thread, with its own event queue, etc. You can kill it safely, without trowing away the whole image. Regards! Esteban A. Maringolo 2013/12/2 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > Hi guys, I have some thoughts about how we develop for Pharo. > > I was doing something in in Nautilus, and it started rising errors, which is ok (well, itâs not ok, but this happens during so rapid development). But then I clicked on something in Nautilus and ended up in the infinite loop. Shouldnât we develop our tools in a more friendly way? When my finder freezes I donât have to restart OS X, but when Nautilus freezes I have to restart Pharo. > > Uko

Dec. 2, 2013

Re: [Pharo-dev] Similarity Matrix

by Tudor Girba

Very cool! Doru On Fri, Nov 29, 2013 at 10:16 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > Hi! > > I know some of you are working on DSM-kind of matrix. Oscar has been > working on a similarity matrix for Roassal. I just want to share a > self-explanble screenshot with you guys. > > > On this example, the methods of the subclasses of Set are compared between > themselves. > Black dot is a couple (m1, m2) that are very similar > > More on > https://www.facebook.com/media/set/?set=a.550677725018829.1073741833.340543… > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 2, 2013

Re: [Pharo-dev] Responsible development

by Marcus Denker

On 02 Dec 2013, at 14:03, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi guys, I have some thoughts about how we develop for Pharo. > > I was doing something in in Nautilus, and it started rising errors, which is ok (well, itâs not ok, but this happens during so rapid development). But then I clicked on something in Nautilus and ended up in the infinite loop. Shouldnât we develop our tools in a more friendly way? When my finder freezes I donât have to restart OS X, but when Nautilus freezes I have to restart Pharo. > this is the same as saying âI have an idea for developing pharo: We should stop introducing bugsâ. So: yes. Please do. ;-) Marcus

Dec. 2, 2013

Re: [Pharo-dev] Some squeaksource.com updates

by David T. Lewis

On Sun, Dec 01, 2013 at 07:11:59PM -0800, Sean P. DeNigris wrote: > David T. Lewis wrote > > The welcome page for http://squeaksource.com has been updated... The > > policy of disabling new project creation remains in effect. > > Thanks! It is good that so much of our history will remain accessible... > > "create any number of projects to host on our server" should probably be > removed > Thanks Sean, I fixed it. Dave

Dec. 2, 2013

Re: [Pharo-dev] Responsible development

by Roberto Minelli

Well, +1 We should, in a way, form a sort of âPharo UI Teamâ that keeps pushing and fixing Nautilus & co. On Dec 2, 2013, at 2:02 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi guys, I have some thoughts about how we develop for Pharo. > > I was doing something in in Nautilus, and it started rising errors, which is ok (well, itâs not ok, but this happens during so rapid development). But then I clicked on something in Nautilus and ended up in the infinite loop. Shouldnât we develop our tools in a more friendly way? When my finder freezes I donât have to restart OS X, but when Nautilus freezes I have to restart Pharo. > > Uko

Dec. 2, 2013

Responsible development

by Yuriy Tymchuk

Hi guys, I have some thoughts about how we develop for Pharo. I was doing something in in Nautilus, and it started rising errors, which is ok (well, itâs not ok, but this happens during so rapid development). But then I clicked on something in Nautilus and ended up in the infinite loop. Shouldnât we develop our tools in a more friendly way? When my finder freezes I donât have to restart OS X, but when Nautilus freezes I have to restart Pharo. Uko

Dec. 2, 2013

Re: [Pharo-dev] [Moose-dev] Re: Similarity Matrix

by Alexandre Bergel

> Really nice. > In fact it would be ****great**** if we can plug the comparison between the x and y cells (which can be different). > Because like that we get a simple matrix based comparator similar to the one of early paper of prejinshight work. This is the case actually. Consider this rather simple and small example: SimilarityMatrix new on: #('hello world' 'welcome to our world' 'hello means bonjour' 'bye bye') by: [ :m1 : m2 | (m1 substrings intersection: m2 substrings) size / ((1 max: (m1 substrings union: m2 substrings) size) + 1) "NB penalty for small methods" ]; gridView The output is It visually says that âhello worldâ is close to âwelcome to out worldâ and to âhello means bonjourâ, because âhelloâ and âworldâ are in common. Alexandre

Dec. 2, 2013

Re: [Pharo-dev] How to update Deep into Pharo Chapter

by Damien Cassou

I can't compile anymore when I include your text: $ pdflatex Exceptions.tex ! Extra }, or forgotten $. <recently read> \egroup l.880 Transcript show: 'error 2'; cr. "does not display it" ? $ pdflatex -version pdfTeX 3.1415926-2.5-1.40.14 (TeX Live 2013) Please just include your text in Exceptions.tex. Thank you On Fri, Nov 29, 2013 at 8:01 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > thanks! > > On Nov 28, 2013, at 10:27 PM, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > > I commited a new file (GOC-ExceptionExclusions.tex) in the Exceptions folder > with a short subsection explaining the use. Feel free to review and improve > it before inclusion in the main file. Probably the better insertion point is > just after the ExceptionSet explanation. > > For testing the latex compilation I temporally put a "\input" in the main > file (this isn't commited). > > Regards, Gabriel > > On Wed, Nov 27, 2013 at 3:45 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> Yes >> It would be good that you put some comments so that I can read it fast. >> >> Stef >> On Nov 26, 2013, at 11:07 PM, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: >> >> Thanks Damien, >> What is the expected workflow? >> I checkout the latex code, made the changes and then commit? >> >> >> On Tue, Nov 26, 2013 at 4:30 PM, Damien Cassou <damien.cassou(a)gmail.com> >> wrote: >>> >>> On Tue, Nov 26, 2013 at 6:34 PM, Gabriel Cotelli <g.cotelli(a)gmail.com> >>> wrote: >>> > Done. Username: gcotelli >>> >>> >>> done >>> >>> -- >>> Damien Cassou >>> http://damiencassou.seasidehosting.st >>> >>> "Success is the ability to go from one failure to another without >>> losing enthusiasm." >>> Winston Churchill >>> >> >> > > -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Dec. 2, 2013