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

Re: [Pharo-project] about cloud in pharo

by Eliot Miranda

On Thu, Dec 9, 2010 at 12:16 PM, Sven Van Caekenberghe <sven(a)beta9.be>wrote: > > On 09 Dec 2010, at 20:39, Eliot Miranda wrote: > > > On Thu, Dec 9, 2010 at 11:14 AM, stephane ducasse < > stephane.ducasse(a)free.fr> wrote: > > Hi guys > > > > When I see that. I would really like to see how we can create something > around the cloud. We have a lot of assets. > > Does anybody have some interest bootstrapping a business around that? > > > > _very_ I'd love to do high-quality VM work funded in this kind of > context. > > Isn't / shouldn't Cog already (be) a high quality VM then ? > Its code generator is naive, the object representation is over-complex, the GC is poor (no incremental mark-sweep), the FFI is weak (no threading), there is no multi-core solution available as yet, there is no 64-bit solution, there is no adaptive optimizer. While I'm making progress on some of these I certainly don't have enough time to focus on them and would love the chance to do just that, working with people like Igor and Marcus. > I don't think (I am actually pretty sure) that Ruby has a good VM, > Smalltalk's is way better (many more decades of experience, from the times > when hardware mattered). Up until very recently (and even after the RoR hype > started) they had no unicode support and no multithreading. Even now, they > always (have to) deploy clusters of multiple VMs to scale. [On the other > hand, this makes every deploy better scaleable because they have to do it > from day one]. > > Seaside can do all that too (the scaling/clustering), it is sometimes > little things that cause problems. For example, many people have tried but > very little have succeeding in building a VM themselves that is as fast as > the 'official' ones. Headless support is another one. Better sockets and > streaming would also help. > > Cloud support is actually lot's of Unix/Linux level work combined with > automation. Smalltalk, Ruby, Lisp, Python, Java, .Net or even C, it doesn't > matter much. > I fear you're right. But I'm told that being able to scale is key, and that is in part a VM performance and tuning issue, not just a deployment configuration issue. > > But don't get me wrong, I do think Smalltalk has an interesting future. It > is still one of the nicest languages/environments/IDE's/communities to work > in. And Pharo has been a great step in modernizing Smalltalk. And Cog just > made everything incredibly much faster. > Somewhat faster :) There's potentially much more to come. best Eliot > > Sven > > > > >

Dec. 9, 2010

Re: [Pharo-project] Why was the old Editor Functionality Removed?

by Levente Uzonyi

On Thu, 9 Dec 2010, Lukas Renggli wrote: >> I guess I'm the one who made all this bad changes. >> So sorry, sorry sorry. > > I don't think so. > >> Maybe we can come back to the "old" one. >> No problem for me. > > I think the main problem is that the new editor model (which I really > like) was merged directly into the existing editor morphs, so > everything that uses more than just the morphs breaks. > >> I can make a slice in that direction. > > I am not sure if this is possible anymore, because now we have > dependencies on PluggableTextMorph and friends with the old API and > dependencies on PluggableTextMorph and friends with the new API. > >> But frankly, what a catastrophic mail for people who are trying >> to make the system cleaner. >> do you know how much of my free time I've spent to make the undo/redo work again? >> Maybe one can just simply ask for help instead of blaming. > > I am *not criticizing* the system cleanup. I am criticizing the > changes that didn't go through a deprecation phase. It started with > the introduction of the 'style' variable in a commonly used > superclass. The problem was discussed a long time ago and I was shut > up; today the problem turns out to be way worse. > >> OCompletion works and it includes ECompletion. Since I added a setting >> for using ECompletion instead of OCompletion (and not just as a fallback >> mechanism), ECompletion is also working with the new editors. > > I looked at the OCompletion changes and tried to merge them into > eCompletion, but as Francisco says it is only kinda working. He said that shout is what kinda working. If you've found a problem with OCompletion, let me know. Levente > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > >

Dec. 9, 2010

Re: [Pharo-project] Why was the old Editor Functionality Removed?

by Tudor Girba

I said it before: just give the variable a different name. For example, textStyle. That would solve all loading problems. Doru On 9 Dec 2010, at 22:49, StÃ©phane Ducasse wrote: > Thanks all for your time. > We should try to do it better in the future. > We should also change and improve our tools for helping us being better. > > Now something important is how can we move this style variable in a way that we can move it and also avoid to break. > this is just an example: let us do an analysis of the problems and learn for the next cycle. > > Stef > > >>> I guess I'm the one who made all this bad changes. >>> So sorry, sorry sorry. >> >> I don't think so. >> >>> Maybe we can come back to the "old" one. >>> No problem for me. >> >> I think the main problem is that the new editor model (which I really >> like) was merged directly into the existing editor morphs, so >> everything that uses more than just the morphs breaks. >> >>> I can make a slice in that direction. >> >> I am not sure if this is possible anymore, because now we have >> dependencies on PluggableTextMorph and friends with the old API and >> dependencies on PluggableTextMorph and friends with the new API. >> >>> But frankly, what a catastrophic mail for people who are trying >>> to make the system cleaner. >>> do you know how much of my free time I've spent to make the undo/redo work again? >>> Maybe one can just simply ask for help instead of blaming. >> >> I am *not criticizing* the system cleanup. I am criticizing the >> changes that didn't go through a deprecation phase. It started with >> the introduction of the 'style' variable in a commonly used >> superclass. The problem was discussed a long time ago and I was shut >> up; today the problem turns out to be way worse. >> >>> OCompletion works and it includes ECompletion. Since I added a setting >>> for using ECompletion instead of OCompletion (and not just as a fallback >>> mechanism), ECompletion is also working with the new editors. >> >> I looked at the OCompletion changes and tried to merge them into >> eCompletion, but as Francisco says it is only kinda working. >> >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > -- www.tudorgirba.com "Every thing has its own flow."

Dec. 9, 2010

Re: [Pharo-project] Why was the old Editor Functionality Removed?

by Schwab,Wilhelm K

Stef, One approach might be to remove all direct accesses to the variable, and then arrange a (probably sub-optimal) temporary way to access through the existing receivers but with it in its new home. Then arrange to send the messages to the new intended recipient. Easier said than done, but it might fix Lukas' hassles with fixing things in both images - I've encountered similar problems, and they can be a huge pain. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Thursday, December 09, 2010 4:49 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Why was the old Editor Functionality Removed? Thanks all for your time. We should try to do it better in the future. We should also change and improve our tools for helping us being better. Now something important is how can we move this style variable in a way that we can move it and also avoid to break. this is just an example: let us do an analysis of the problems and learn for the next cycle. Stef

Dec. 9, 2010

Re: [Pharo-project] Issue 3395 in pharo: Capitalization of Author

by pharo＠googlecode.com

Comment #2 on issue 3395 by stephane.ducasse: Capitalization of Author http://code.google.com/p/pharo/issues/detail?id=3395 Yes it was breaking some MC tests I just fixed and I want hudson with green tests and after I do not want to see red tests popping up and not getting removed or fixed :)

Dec. 9, 2010

Re: [Pharo-project] Where does Regex-Core and friends live

by StÃ©phane Ducasse

cool! On Dec 9, 2010, at 10:41 PM, Dale Henrichs wrote: > On 12/09/2010 10:39 AM, StÃ©phane Ducasse wrote: >>>> >>> I'm interested in terms of maintaining Pharo compatibility ... many of the GLASS developers develop in Pharo and deploy in GemStone and I am trying to get in the habit of using the same packages that are loaded into Pharo (where possible/practical) so that the bugfixes and updates can be shared without too much trouble ... >> >> Dale >> >> we are interested in making sure that the package loads well in Glass. >> I hope that we will simplify clean the system another couple of times to arrive to a nicer version. >> Adding tests is also a good way to support such effort. >> >> Stef > > Stef, > > The packages loaded (except for the two compile errors .. I'll check a fix in for those) and all tests ran clean ... I will probably spend some time with regex and streams to validate GemStone's Ansi streams and will add tests if the coverage is lacking in that area ... > > Dale

Dec. 9, 2010

Re: [Pharo-project] Why was the old Editor Functionality Removed?

by StÃ©phane Ducasse

Thanks all for your time. We should try to do it better in the future. We should also change and improve our tools for helping us being better. Now something important is how can we move this style variable in a way that we can move it and also avoid to break. this is just an example: let us do an analysis of the problems and learn for the next cycle. Stef >> I guess I'm the one who made all this bad changes. >> So sorry, sorry sorry. > > I don't think so. > >> Maybe we can come back to the "old" one. >> No problem for me. > > I think the main problem is that the new editor model (which I really > like) was merged directly into the existing editor morphs, so > everything that uses more than just the morphs breaks. > >> I can make a slice in that direction. > > I am not sure if this is possible anymore, because now we have > dependencies on PluggableTextMorph and friends with the old API and > dependencies on PluggableTextMorph and friends with the new API. > >> But frankly, what a catastrophic mail for people who are trying >> to make the system cleaner. >> do you know how much of my free time I've spent to make the undo/redo work again? >> Maybe one can just simply ask for help instead of blaming. > > I am *not criticizing* the system cleanup. I am criticizing the > changes that didn't go through a deprecation phase. It started with > the introduction of the 'style' variable in a commonly used > superclass. The problem was discussed a long time ago and I was shut > up; today the problem turns out to be way worse. > >> OCompletion works and it includes ECompletion. Since I added a setting >> for using ECompletion instead of OCompletion (and not just as a fallback >> mechanism), ECompletion is also working with the new editors. > > I looked at the OCompletion changes and tried to merge them into > eCompletion, but as Francisco says it is only kinda working. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

Dec. 9, 2010

Re: [Pharo-project] Where does Regex-Core and friends live

by Dale Henrichs

On 12/09/2010 10:39 AM, StÃ©phane Ducasse wrote: >>> >> I'm interested in terms of maintaining Pharo compatibility ... many of the GLASS developers develop in Pharo and deploy in GemStone and I am trying to get in the habit of using the same packages that are loaded into Pharo (where possible/practical) so that the bugfixes and updates can be shared without too much trouble ... > > Dale > > we are interested in making sure that the package loads well in Glass. > I hope that we will simplify clean the system another couple of times to arrive to a nicer version. > Adding tests is also a good way to support such effort. > > Stef Stef, The packages loaded (except for the two compile errors .. I'll check a fix in for those) and all tests ran clean ... I will probably spend some time with regex and streams to validate GemStone's Ansi streams and will add tests if the coverage is lacking in that area ... Dale

Dec. 9, 2010

Re: [Pharo-project] Why was the old Editor Functionality Removed?

by Lukas Renggli

> I guess I'm the one who made all this bad changes. > So sorry, sorry sorry. I don't think so. > Maybe we can come back to the "old" one. > No problem for me. I think the main problem is that the new editor model (which I really like) was merged directly into the existing editor morphs, so everything that uses more than just the morphs breaks. > I can make a slice in that direction. I am not sure if this is possible anymore, because now we have dependencies on PluggableTextMorph and friends with the old API and dependencies on PluggableTextMorph and friends with the new API. > But frankly, what a catastrophic mail for people who are trying > to make the system cleaner. > do you know how much of my free time I've spent to make the undo/redo work again? > Maybe one can just simply ask for help instead of blaming. I am *not criticizing* the system cleanup. I am criticizing the changes that didn't go through a deprecation phase. It started with the introduction of the 'style' variable in a commonly used superclass. The problem was discussed a long time ago and I was shut up; today the problem turns out to be way worse. > OCompletion works and it includes ECompletion. Since I added a setting > for using ECompletion instead of OCompletion (and not just as a fallback > mechanism), ECompletion is also working with the new editors. I looked at the OCompletion changes and tried to merge them into eCompletion, but as Francisco says it is only kinda working. Lukas -- Lukas Renggli www.lukas-renggli.ch

Dec. 9, 2010

Re: [Pharo-project] Fuel - a fast object deployment tool

by StÃ©phane Ducasse

>>>> It does! >>>> It seems that you did not work in VW2.5 and 3.0 and when parcels arrived loading was realllllly a big difference >>>> I do not see why this would not the same with Fuel. >>> >>> No I didn't, but the version number of VW is around 7.x now, so I guess the CPUs and VMs are now several times faster. Does it really matter if it takes 200ms or 20ms to load a package? >> >> When I load a package with MC so far I still notice it and I would not even think about it. >> It should load in a unnoticeable amount of time. > > Do you think MC is "slow" because the Compiler is "slow"? not totally but I do not understand why this is obligatory to compile everything all the time. Then Opal will be slower than the old comcrapiler.

Dec. 9, 2010