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

Re: [Pharo-project] A dog-slow browser

by Levente Uzonyi

On Wed, 20 Jan 2010, Igor Stasenko wrote: >> 2010/1/20 Levente Uzonyi <leves(a)elte.hu>: >> >> I guess that vm is not gnuified. >> > >I installed one that was avail for linux, latest one. Didn't built it myself. I just checked on a "not-that-fast" machine with the binary versions from squeakvm.org: 3.11-3.2135 -> #( '204309656 bytecodes/sec; 7660022 sends/sec' '202852614 bytecodes/sec; 7722256 sends/sec' '205457463 bytecodes/sec; 7785510 sends/sec') 3.10.6 -> #( '380386329 bytecodes/sec; 9512738 sends/sec' '377025036 bytecodes/sec; 10174641 sends/sec' '378978534 bytecodes/sec; 10183725 sends/sec') The 3.11-3.2135 is not gnuified and I couldn't force cmake to gnuify it (though I didn't try really hard). I think this is an issue that should be solved. Levente > >> >> Levente >>

Jan. 20, 2010

Re: [Pharo-project] A dog-slow browser

by Gary Chambers

3.11.4 Windows Pharo VM on Vista, Q9550 standard clocks (2.83GHz). Slightly better scores after a garbageCollect ;-) Regards, Gary On Wed, 2010-01-20 at 11:22 -0800, John M McIntosh wrote: > You have to adjust the gnufied interp.c and the compiler options based on your compiler version to > generate the most optimum code for bytecode execution and the common send block. > > I'm guessing Marcus is using a V5 VM? '419328419 bytecodes/sec; 11484087 sends/sec' > > Would like to know what machine Gary Chambers is using? > (1 tinyBenchmarks '566998892 bytecodes/sec; 16433596 sends/sec') here. > > > On 2010-01-20, at 11:07 AM, Levente Uzonyi wrote: > > What's tuned? > > > > > > Levente > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 20, 2010

Re: [Pharo-project] New profiler for Pharo: tester wanted!

by Levente Uzonyi

On Wed, 20 Jan 2010, Alexandre Bergel wrote: > The millisecond grain information is obtained from MessageTally. How > do I access this microsecond clock? Something like "Time > class>>#microsecondClock" ? You have to create that method since it doesn't exist. Something like: Time class >> microsecondClock <primitive: 'primitiveMicrosecondClock'> self primitiveFailed shoud do it. Levente > > Cheers, > Alexandre > > > On 20 Jan 2010, at 16:24, John M McIntosh wrote: > >> You know I"m trying to integrate a microsecond clock into the VM. It >> might be interesting if you >> run on a macintosh to try a test V5 VM I can supply to see what >> happens if you change your >> time collecting from the millisecond clock to the microsecond clock. >> >> >> On 2010-01-20, at 11:20 AM, Alexandre Bergel wrote: >> >>> Each implementor of #ensureMetacello is different. Even the one of >>> ConfigurationOfMetacello is different from the one of the website :-) >>> >>> I update ConfigurationOfSpy. It loads now without any problem. >>> >>> Cheers, >>> Alexandre >> >> -- >> = >> = >> = >> = >> = >> ====================================================================== >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: >> squeaker68882 >> Corporate Smalltalk Consulting Ltd. http:// >> www.smalltalkconsulting.com >> = >> = >> = >> = >> = >> ====================================================================== >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 20, 2010

Re: [Pharo-project] about fast lineDo and...

by Levente Uzonyi

On Wed, 20 Jan 2010, StÃ©phane Ducasse wrote: >> >>> Yes but I do not work on >>> - new first class instance variable >>> - byecode loader >>> - new package to speed up everything >>> - scripting syntax >>> >> >> Never mind, when I said "you", it was not specifically you, but anyone >> else prefering to wait because of no free time. >> >>> so at the end I'm not sure what we lose but they are >>> simple actions that other people can do too to distribute the load. >>> So may be I will stop looking at squeak log. >>> >> >> Sure, the danger is to become a follower of random activity driven by others. >> If time is sparse, you might prefer to keep control. >> But some changes like file buffering really makes a difference. > > Yes but tracking changes you do not know is also taking time. > I started but so far failed two times because you have to go slowly not to break too much the system. > Tomorrow I will follow the advice of levente and check. > The problem also is that the level of the tools is not really good. That shouldn't be hard: in a updated Trunk image, file out MultiByteFileStream and StandardFileStream. Open a File Browser in your Pharo image select one of the files, right click and select "code-file browser". This will show you all the methods in the file and will diff it with the current versions (if it exists). The annotation pane shows the timestamp and information about the method (new, identical, modified, etc). Levente > Some behavior of the history browser add to changeset other not. > > We will have to improve that. > > >>> Stef >>> >>>> 2010/1/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>> ok I understand. I will keep your energy for the important one. >>>> >>>> http://code.google.com/p/pharo/issues/detail?id=1856 >>>> >>>>> but since I'm nearly the only that have a look at fixes in squeak >>>>> may be I will simply just stop to look at them because the community >>>>> does not seem to interested in getting them or producing them for pharo. >>>>> >>>> >>>> Sure some people are interested as much as you are. >>>> But waiting for someone to do the job for you, or wasting your own >>>> time is rarely a dilemna except for the happy few owners of "own time" >>>> ;) >>>> >>>> It's important to keep up with what's going on in other branches : >>>> kind of technology forecasting :) >>>> Just lurking the daily commit logs, and registering interesting stuff >>>> as pharo issue is already valuable. >>>> >>>> Nicolas >>>> >>>>> Stef >>>>> >>>>> >>>>> On Jan 20, 2010, at 8:27 AM, Nicolas Cellier wrote: >>>>> >>>>>> Don't know if I'll have time, but changes are fairly easy to grab >>>>>> (independent of each other). >>>>> >>>>> Ok >>>>>> >>>>>> Nicolas >>>>>> >>>>>> 2010/1/19 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>>>> Hi nicolas >>>>>>> >>>>>>> I saw that you commit some speed up for lineending to the squeaktrunk and I would love to have them >>>>>>> since in moose we are computing a lot LOC :) >>>>>>> By any chance could we get the same in pharo? >>>>>>> Else I will harvest them. >>>>>>> >>>>>>> Stef >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 20, 2010

Re: [Pharo-project] about fast lineDo and...

by StÃ©phane Ducasse

> >> Yes but I do not work on >> - new first class instance variable >> - byecode loader >> - new package to speed up everything >> - scripting syntax >> > > Never mind, when I said "you", it was not specifically you, but anyone > else prefering to wait because of no free time. > >> so at the end I'm not sure what we lose but they are >> simple actions that other people can do too to distribute the load. >> So may be I will stop looking at squeak log. >> > > Sure, the danger is to become a follower of random activity driven by others. > If time is sparse, you might prefer to keep control. > But some changes like file buffering really makes a difference. Yes but tracking changes you do not know is also taking time. I started but so far failed two times because you have to go slowly not to break too much the system. Tomorrow I will follow the advice of levente and check. The problem also is that the level of the tools is not really good. Some behavior of the history browser add to changeset other not. We will have to improve that. >> Stef >> >>> 2010/1/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> ok I understand. I will keep your energy for the important one. >>> >>> http://code.google.com/p/pharo/issues/detail?id=1856 >>> >>>> but since I'm nearly the only that have a look at fixes in squeak >>>> may be I will simply just stop to look at them because the community >>>> does not seem to interested in getting them or producing them for pharo. >>>> >>> >>> Sure some people are interested as much as you are. >>> But waiting for someone to do the job for you, or wasting your own >>> time is rarely a dilemna except for the happy few owners of "own time" >>> ;) >>> >>> It's important to keep up with what's going on in other branches : >>> kind of technology forecasting :) >>> Just lurking the daily commit logs, and registering interesting stuff >>> as pharo issue is already valuable. >>> >>> Nicolas >>> >>>> Stef >>>> >>>> >>>> On Jan 20, 2010, at 8:27 AM, Nicolas Cellier wrote: >>>> >>>>> Don't know if I'll have time, but changes are fairly easy to grab >>>>> (independent of each other). >>>> >>>> Ok >>>>> >>>>> Nicolas >>>>> >>>>> 2010/1/19 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>>> Hi nicolas >>>>>> >>>>>> I saw that you commit some speed up for lineending to the squeaktrunk and I would love to have them >>>>>> since in moose we are computing a lot LOC :) >>>>>> By any chance could we get the same in pharo? >>>>>> Else I will harvest them. >>>>>> >>>>>> Stef >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 20, 2010

Re: [Pharo-project] about fast lineDo and...

by Nicolas Cellier

2010/1/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Yes but I do not work on > Â Â Â Â - new first class instance variable > Â Â Â Â - byecode loader > Â Â Â Â - new package to speed up everything > Â Â Â Â - scripting syntax > Never mind, when I said "you", it was not specifically you, but anyone else prefering to wait because of no free time. > so at the end I'm not sure what we lose but they are > simple actions that other people can do too to distribute the load. > So may be I will stop looking at squeak log. > Sure, the danger is to become a follower of random activity driven by others. If time is sparse, you might prefer to keep control. But some changes like file buffering really makes a difference. > Stef > >> 2010/1/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> ok I understand. I will keep your energy for the important one. >> >> http://code.google.com/p/pharo/issues/detail?id=1856 >> >>> but since I'm nearly the only that have a look at fixes in squeak >>> may be I will simply just stop to look at them because the community >>> does not seem to interested in getting them or producing them for pharo. >>> >> >> Sure some people are interested as much as you are. >> But waiting for someone to do the job for you, or wasting your own >> time is rarely a dilemna except for the happy few owners of "own time" >> ;) >> >> It's important to keep up with what's going on in other branches : >> kind of technology forecasting :) >> Just lurking the daily commit logs, and registering interesting stuff >> as pharo issue is already valuable. >> >> Nicolas >> >>> Stef >>> >>> >>> On Jan 20, 2010, at 8:27 AM, Nicolas Cellier wrote: >>> >>>> Don't know if I'll have time, but changes are fairly easy to grab >>>> (independent of each other). >>> >>> Ok >>>> >>>> Nicolas >>>> >>>> 2010/1/19 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>> Hi nicolas >>>>> >>>>> I saw that you commit some speed up for lineending to the squeaktrunk and I would love to have them >>>>> since in moose we are computing a lot LOC :) >>>>> By any chance could we get the same in pharo? >>>>> Else I will harvest them. >>>>> >>>>> Stef >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 20, 2010

Re: [Pharo-project] O2: tester wanted!

by Alexandre Bergel

Well spotted. David? Alexandre On 20 Jan 2010, at 18:44, Henrik Sperre Johansen wrote: > On 19.01.2010 23:03, Alexandre Bergel wrote: >> Dear All, >> >> For people who do not know, O2 is the browser David has implemented >> in >> the last few years. It replaces class-categories on the left-hand >> side >> pane with a list of packages. We are still away from having packages >> as real first class entities, but this is a good step toward. Note >> that some people find O2 a bit slower than other available code >> browsers. >> >> David and I spent some time on fixing O2. O2 has now no dependencies >> to OB anymore. >> We would like that people try it and submit bug reports on the google >> bug tracker. In a fresh 10505, you can load O2 by evaluating: >> >> Gofer new squeaksource: 'MetacelloRepository'; package: >> 'ConfigurationOfO2'; load. (Smalltalk at: #ConfigurationOfO2) >> perform: >> #loadDefault >> >> O2 does not need OB whatsoever. O2 loads in a Core (I tried in a >> 11165). Before and after loading O2, running OB tests give "548 run, >> 547 passes, 1 failures" [*]. >> >> Cheers, >> Alexandre >> >> [*] the test have been loaded using (ConfigurationOfOmniBrowser >> project version: '1.1') load: 'Dev Tests' >> > > OR2PackageBrowser does not open, it lacks a defaultRootNode method > returning other than nil. > Is the focus mainly on the O2* browsers, or should OR2* also work? > > Cheers, > Henry > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 20, 2010

Re: [Pharo-project] What we should do with the Dev image? Re: question about O2 vs OB

by StÃ©phane Ducasse

This is the plan. Using Metacello will enable that. > Today on the squeak-dev list this link was posted, which I hadn't seen. http://builder.seaside.st/ It lets you choose from the web page all the options that you want, then it lets you download a build script or monticello configuration to load all the parts. It seems like building one of these for Pharo dev (or core) might be awesome. Just click the things you want, if some are mutually exclusive the website can show that (radio button rather than checkbox). Then download the base image, and drag your script onto it. Everyone can get what they want, and nobody has to fight about which browser is best. Yes :) Just a meta remark I can tell you that we do not lack vision: - I want to mini kernel bootable without compiler only bytecode and socket - I want a cool mop with first class instance variables - I want to have a cool catalog to build app with - I want more Now this is a question of time and energy and you can all help! Think about closing some issue, sending code with problems... Stef

Jan. 20, 2010

Re: [Pharo-project] What we should do with the Dev image? Re: question about O2 vs OB

by StÃ©phane Ducasse

yes this is the future. Now this is just about shipping the right 1.0 and passing to 1.1 and 1.2 Stef On Jan 20, 2010, at 8:58 PM, laurent laffont wrote: > May be this is off topic, but when I was working in embedded linux development I have used a cool tool to customize its own linux image before downloading it. It's narcissus from angstrom distribution: http://www.angstrom-distribution.org/narcissus/ > > For me, a Pharo image and a linux distribution are quite similar when talking about packages. With Metacello, Loader and Seaside, may be such a tool to configure your image to download is not a big deal ? So everybody can easily choose between OB, O2 or both, WorkingSet / Algernon, AidaWeb / Seaside, .... > > Laurent > > > On Wed, Jan 20, 2010 at 8:19 PM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > I agree with this solution. > > As much as it pains me to work with OB (and I forced myself to do it > for 2 weeks :)), it is stable and this issue prevails at this moment > for 1.0. > > Cheers, > Doru > > > On 20 Jan 2010, at 19:10, Mariano Martinez Peck wrote: > > > > > > > On Wed, Jan 20, 2010 at 3:03 PM, Adrian Lienhard <adi(a)netstyle.ch> > > wrote: > > Hi Mariano, > > > > > 2) Install only OB > > > > is a reasonable choice. We are very close to a 1.0 release and > > including OB again at this point does not make sense. The risk for > > unknown bugs that we needed to fix in maintenance releases of 1.0 is > > too high in my opinion. > > > > > > > > Thanks Adrian. I didn't want to say it, but yes. I think like you. > > WE NEED TO RELEASE 1.0 NOW!!!! and as much as stable possible. > > > > For new comers, I think it is even easier to have only one browser. > > Having two, bring to confussion, insecurity, etc. Once the newcomer > > stop to be newcomer, he will be able to install O2 by himself and > > take his own opinion on both browsers. > > > > And come on...that's the idea of Metacello!! that each people can > > load whatever they want. > > > > so.... +1 (ouch...I have already voted!) > > > > However, when we start building images for 1.1 we should consider to > > add it again. > > > > Cheers, > > Adrian > > > > On Jan 20, 2010, at 17:44 , Mariano Martinez Peck wrote: > > > > >> That's the reason of having OB and O2. While both now work > > together in the > > >> same image > > >> without inferring each other, this indeed increases the number of > > classes > > >> in the image > > >> quite a lot as they duplicate a whole bunch of code. So I > > strongly suggest > > >> to either use > > >> OB or O2, even though you can have both. But I do not see a > > reason why > > >> people want to > > >> switch between the two dynamically in the same image. > > >> > > >> > > > > > > We have two things to choose: which browser is default and which > > ones are > > > installed. Both ? only one ? The solution I like most, is in > > these options: > > > > > > 1) Install both: OB and O2. Let OB as default. > > > > > > 2) Install only OB, of course, as default, and those who wants can > > install > > > O2 in that dev image. They way to install O2 now is very easy. > > > > > > 3) Install only OB, of course, as default, but create a group in > > > ConfigurationOfPharo like "StandardDevImageWithO2" so that those > > people who > > > want a dev image with O2 can just evaluate that in a core image > > and wala! > > > > > > With 1 the image will be smaller but won't have O2 preinstalled. > > With 2) and > > > 3) you will have also O2 but bigger image. > > > > > > I think I will coose 2) AND 3). Those who want to install O2 > > directly in a > > > dev image, use the ConfigurationOfO2 and those who wants to create > > a dev > > > image over the core, they use ConfigurationOfPharo with the new > > group I can > > > create. > > > > > > What do you think ? > > > > > > Mariano > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "Reasonable is what we are accustomed with." > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 20, 2010

Re: [Pharo-project] about fast lineDo and...

by StÃ©phane Ducasse

Yes but I do not work on - new first class instance variable - byecode loader - new package to speed up everything - scripting syntax so at the end I'm not sure what we lose but they are simple actions that other people can do too to distribute the load. So may be I will stop looking at squeak log. Stef > 2010/1/20 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> ok I understand. I will keep your energy for the important one. > > http://code.google.com/p/pharo/issues/detail?id=1856 > >> but since I'm nearly the only that have a look at fixes in squeak >> may be I will simply just stop to look at them because the community >> does not seem to interested in getting them or producing them for pharo. >> > > Sure some people are interested as much as you are. > But waiting for someone to do the job for you, or wasting your own > time is rarely a dilemna except for the happy few owners of "own time" > ;) > > It's important to keep up with what's going on in other branches : > kind of technology forecasting :) > Just lurking the daily commit logs, and registering interesting stuff > as pharo issue is already valuable. > > Nicolas > >> Stef >> >> >> On Jan 20, 2010, at 8:27 AM, Nicolas Cellier wrote: >> >>> Don't know if I'll have time, but changes are fairly easy to grab >>> (independent of each other). >> >> Ok >>> >>> Nicolas >>> >>> 2010/1/19 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> Hi nicolas >>>> >>>> I saw that you commit some speed up for lineending to the squeaktrunk and I would love to have them >>>> since in moose we are computing a lot LOC :) >>>> By any chance could we get the same in pharo? >>>> Else I will harvest them. >>>> >>>> Stef >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 20, 2010