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

Re: [Pharo-project] Issue 3397 in pharo: Behaviour>> #adoptInstance:

by pharo＠googlecode.com

Updates: Status: Fixed Comment #1 on issue 3397 by rydier: Behaviour>> #adoptInstance: http://code.google.com/p/pharo/issues/detail?id=3397 SLICE-Issue3397-Behavior-adoptInstance in inbox

Dec. 10, 2010

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

by tr.bourgois

Hi Martin, Looks very interesting. Reading the material you posted, the question that jumps out at me is this: from the benchmarks, it's clear that materializing is faster than serializing, but it's not clear why. How does separating the nodes from the edges of the object graph make materializing faster? Thanks, Colin Hi! Separate the nodes from the edges of the object permit during the serialization to pass only one time on the byte code. So first we pass on the node so we recreate the objects/nodes and second when we pass on the edges we recreate the links between the objects. I hope I answered your question :) Tristan Une messagerie gratuite, garantie Ã vie et des services en plus, Ã§a vous tente ? Je crÃ©e ma boÃ®te mail www.laposte.net

Dec. 10, 2010

[Pharo-project] Issue 3397 in pharo: Behaviour>> #adoptInstance:

by pharo＠googlecode.com

Status: Started Owner: rydier Labels: Milestone-1.2 New issue 3397 by rydier: Behaviour>> #adoptInstance: http://code.google.com/p/pharo/issues/detail?id=3397 This is a method originally found in VisualWorks, and offers a nicer interface to use than changeClassToThatOf: for switching the class of an instance. Cog has added primitive support for this, the fallback code uses the equivalent primitiveChangeClassTo: which works in non-Cog vms. (But takes an instance rather than a class, usually not very convenient when you want to use it)

Dec. 10, 2010

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

by Adrian Lienhard

>>> Even if Fuel can be 10x faster, it doesn't really make a difference IMHO. >> >> It would be interesting to thoroughly profile MC to figure where it spends all its time (with large projects it gets very very slow, like several minutes to just show the merge diffs between two branches). > > I guess those days are over when MC spends minutes doing this, it's at most a few seconds for large packages. The 1.5MB Morphic package of Squeak can be compared to another really old version (changes) in 3 seconds. According to MessageTally 50% of the time is spend in getting the timeStamp for the methods. Sure, that's for one package. But we don't just put everything in one package; we have like 20 packages for a large project. 20 x 3s is already a minute. Large ancestry and HTTP repository also has an influence. I've done several small optimizations (like adding caching) to speed things up. But still, MC speed in our case is rather measured in minutes than seconds :( Adrian

Dec. 10, 2010

Re: [Pharo-project] about cloud in pharo

by Geert Claes

I started following Squeak/Pharo "because" I can see potential for Smalltalk as a cloud platform. I did look at Heroku and I did like how easy they make it to build and deploy apps to the cloud. I reckon the solution needs to make it easy to manage versions, environments (dev/test/live) and deploy apps in the cloud. also needs some sort of pluggable component sharing. A browser based IDE would be great too so you can use a Chrome OS notebook from wherever you want :) -- View this message in context: http://forum.world.st/about-cloud-in-pharo-tp3080811p3081604.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 10, 2010

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

by Adrian Lienhard

On Dec 9, 2010, at 16:25 , Martin Dias wrote: > Hi all, > > Thank you for the discussion, is very interesting for me. > > Thanks Adrian, I don't have benchmarks with ImageSegment, so I like to > see the numbers, how could I reproduce that benchmarks? it would be > useful for me. This is the essential part of our code (in a subclass of ImageSegment) that writes out our model starting from the root anObject basicSave: anObject | stream temp symbolHolder | symbolHolder := Symbol allSymbols. self copyFromRoots: (Array with: anObject) sizeHint: self fileSize // 2 areUnique: true. state = #activeCopy ifFalse: [ ^ self logger error: 'wrong serializer state' ]. temp := endMarker. endMarker := nil. stream := FileStream forceNewFileNamed: fileName. [ stream fileOutClass: nil andObject: self ] ensure: [ stream close ]. endMarker := temp. Loading is done as follows: | stream streamContents mode object | stream := aDirectory oldFileOrNoneNamed: filename. streamContents := stream fileInObjectAndCode. ^ streamContents install I just timed how long it takes to run these method. HTH, Adrian

Dec. 10, 2010

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

by StÃ©phane Ducasse

Yes I think that this is the pattern that we are applying for packageInfo for example > I said it before: This doesn't solve anything at all. In fact it is > much easier to remove the variable and fork the code. Renaming causes > a ripple effect to lots of methods and makes it impossible to merge > the forks in the future. > > The style variable is just one example of the problem. I am suggesting > that the next time the editor framework is replaced the old code is > left untouched, then deprecated, and different class names are chosen > for the new implementation. Like this both frameworks can coexist for > a while making it much easier to migrate the code. > > The current situation comes from the fact that some existing classes > changed their class layout and API completely making migration really > difficult. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

Dec. 10, 2010

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

by StÃ©phane Ducasse

yes we should have done that On Dec 9, 2010, at 11:44 PM, Tudor Girba wrote: > 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. 10, 2010

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

by StÃ©phane Ducasse

thanks for the analysis so we will have to speed it up too. >>>>>> 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. >> > > I did a quick test where it took 4294ms to load RoelTyper + OCompletion from disk (no socket creation, no network latency, etc). These packages contain 790 methods. 5.1% of the total time was spent for compilation, that's 219ms. The rest is used by other stuff like: > - loading the files from disk > - writing the source code to disk (sources/changes files) > - evaluating class side #initialize methods > - processing system change notifications > > Another 51ms was spent in creating 63 classes and 107ms to install the CompiledMethods to the classes. So that's 219+51+107 = 377ms for creating all classes and their methods. The rest is administration which can not be avoided by binary loading. > > Even if binary loading is 10x faster than compiling the code (which I doubt), then you save 339ms. So it would take only 3917ms to load these packages. That would save you 7.9% of the total time. > > > Levente

Dec. 10, 2010

Re: [Pharo-project] about cloud in pharo

by StÃ©phane Ducasse

On Dec 10, 2010, at 12:35 AM, GermÃ¡n Arduino wrote: > When I read about the Heroku buy the first thing I remembered was > Morphle project because it's leader, Merik, all the time was focused > in a business model as Heroku had. well when I hear that name I just want to leave the room and run fast. > Myself worked a bit (on the side image) some time ago to help have > (not cloud still) but multiple seaside customers (as some others > experiments). > > Today I think that Morphle is already running such business and, may > be, doing things thinking in cloud. > > In summary, I'm sure that cloud is the way to go, and count me in to > any idea related with some sort of business/startup/entrepreneural > initiative around Pharo on the cloud. I would be interested to hear about simple solutions for hosting seaside and other apps > > Cheers. > GermÃ¡n. > > > > 2010/12/9 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >> >> 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. >> >>> >>> Today http://heroku.com/ were bought by Salesforce for over 200 million >>> (http://techcrunch.com/2010/12/08/breaking-salesforce-buys-heroku-for-212-mi…) >>> >>> Stef >> >> > > > > -- > ================================================= > GermÃ¡n S. Arduino <gsa @ arsol.net> Twitter: garduino > Arduino Software & Web Hosting http://www.arduinosoftware.com > PasswordsPro http://www.passwordspro.com > ================================================= >

Dec. 10, 2010