- Pharo-dev - lists.pharo.org

[Pharo-project] Slow image

by Alexandre Bergel

Dear All, I recently experienced a slowing down when using pharo. E.g., I type faster than it prints. Am I the only one to experience this? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 24, 2009

Re: [Pharo-project] bug in FTPClient?

by Cameron Sanders

I have been using the FTP connection in Monticello on both a Windows machine and Mac with no problems. I have not explored that code enough to offer any insight. Good luck. -Cam On Apr 24, 2009, at 11:15 AM, Joseph T. Bore wrote: > Im trying to use monticello to connect to an FTP based monticello > server. > > but when i try to connect i get a message not understood error. It > seems > that Socket>>connectTo:port: is sending #port: to a ByteArray. the > bytearray is the ip address octets, but it clearly doesnt understand > #port: > > this works fine for http based servers, but for an ftp server it > gets this > exception, is anyone else seeing this?

April 24, 2009

[Pharo-project] bug in FTPClient?

by Joseph T. Bore

Im trying to use monticello to connect to an FTP based monticello server. but when i try to connect i get a message not understood error. It seems that Socket>>connectTo:port: is sending #port: to a ByteArray. the bytearray is the ip address octets, but it clearly doesnt understand #port: this works fine for http based servers, but for an ftp server it gets this exception, is anyone else seeing this? -- jbore(a)tjtech.com

April 24, 2009

Re: [Pharo-project] New Pharo-dev based on 10289

by Damien Cassou

Hi, On Fri, Apr 24, 2009 at 12:21 PM, Dennis Schetinin <chaetal(a)gmail.com> wrote: > 2009/4/21 Damien Cassou <damien.cassou(a)gmail.com> : >> http://pharo-project.org/download > > I see only Pharo 09.04.1 (with Seaside and Pier)... Is anywhere a newer one? no, I will only build a new one with web tools in May. Bye -- Damien Cassou http://damiencassou.seasidehosting.st

April 24, 2009

Re: [Pharo-project] linux version download problem

by Michael Rueger

Bryce Kampjes wrote: > It's true that the packaging procedure could do with some more work. > When I originally started producing pre-packaged VMs for Exupery this is > what people wanted. so is this an exupery VM or a "normal" one? I just wrote a similar email like Nicolas, but then remembered this thread :-) Michael

April 24, 2009

Re: [Pharo-project] Backporting function in MC

by Lukas Renggli

> I am glad you found this description useful. I am authoring a chapter > on Monticello for PharoByExample, and there is a section dedicated on > this functionality. However, I haven't been convinced this is a > feature really useful since I know no-one who used it. Avi wrote that feature at ESUG in the car somewhere between Hannover and KÃ¶ethen. We were discussing the implementation several times during that 8 hour drive. I used it a couple of times. What I find easier (because I don't have to load the other version) is to open a merge dialog with the other version and selectively pick some changes and click on 'Install' in the context menu. Then close/cancel the merge dialog and click on 'Adapt' and select the just merged version. I don't exactly know about the semantic differences between the two approaches, could well be that my approach ends up with a nightmare later on but so far it worked well for me. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

April 24, 2009

Re: [Pharo-project] Backporting function in MC

by Alexandre Bergel

Hi Nicolas and others, I am glad you found this description useful. I am authoring a chapter on Monticello for PharoByExample, and there is a section dedicated on this functionality. However, I haven't been convinced this is a feature really useful since I know no-one who used it. If you used it, just even once, please let me know. Cheers, Alexandre On 24 Apr 2009, at 13:57, Nicolas Cellier wrote: > Thank you for this useful link. So the procedure described by Avi is > > "At various points there have been requests that when merging > versions, > you be able to select only some of the changes to merge. You can use > the Backport facility to do this as follows: > > - load the version you want to merge some of the changes from > - backport those changes to the common ancestor with the version you > want to merge into > - save this backported version > - load your version, and merge in the backport > > Eventually, it would of course be nice to have a more automated UI for > doing that..." > > This is a feature I asked very recently: > http://article.gmane.org/gmane.comp.lang.smalltalk.sapphire.devel/7440/matc… > > So I feel free to give my feeling: > 1) The whole procedure seems overkill to me versus implementing same > functionality in merge tool > 2) There are cases when I do not want to load the other version > because I know it would break my image > 3) in some cases the common ancestor is far away or out of reach > (imagine I want to compare two squeak forks) > > Nicolas > > 2009/4/24 Damien Cassou <damien.cassou(a)gmail.com>: >> On Thu, Apr 23, 2009 at 9:49 PM, Alexandre Bergel >> <Alexandre.Bergel(a)inria.fr> wrote: >>> Dear All, >>> >>> Are there any of you who already used the backporting function of >>> Monticello? It has been there for several years already. Enough time >>> to prove its usefulness. >> >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-September/08209… >> >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> _______________________________________________ >> 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 24, 2009

Re: [Pharo-project] Backporting function in MC

by Nicolas Cellier

Thank you for this useful link. So the procedure described by Avi is "At various points there have been requests that when merging versions, you be able to select only some of the changes to merge. You can use the Backport facility to do this as follows: - load the version you want to merge some of the changes from - backport those changes to the common ancestor with the version you want to merge into - save this backported version - load your version, and merge in the backport Eventually, it would of course be nice to have a more automated UI for doing that..." This is a feature I asked very recently: http://article.gmane.org/gmane.comp.lang.smalltalk.sapphire.devel/7440/matc… So I feel free to give my feeling: 1) The whole procedure seems overkill to me versus implementing same functionality in merge tool 2) There are cases when I do not want to load the other version because I know it would break my image 3) in some cases the common ancestor is far away or out of reach (imagine I want to compare two squeak forks) Nicolas 2009/4/24 Damien Cassou <damien.cassou(a)gmail.com>: > On Thu, Apr 23, 2009 at 9:49 PM, Alexandre Bergel > <Alexandre.Bergel(a)inria.fr> wrote: >> Dear All, >> >> Are there any of you who already used the backporting function of >> Monticello? It has been there for several years already. Enough time >> to prove its usefulness. > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-September/08209… > > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 24, 2009

Re: [Pharo-project] New Pharo-dev based on 10292

by StÃ©phane Ducasse

Thanks. we are trying to minimize bugs :) On Apr 24, 2009, at 2:54 AM, Cameron Sanders wrote: > As a consumer of Pharo, let me too say: nice work, it is a great > product. Thank you all! > > -Cam > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 24, 2009

Re: [Pharo-project] Going Alpha

by StÃ©phane Ducasse

sure no problem I was just explaining :) On Apr 23, 2009, at 11:44 PM, Michael Roberts wrote: > for sure don't get me wrong ;-) i'm all for change and we're making > great progress. it was just in comment to alpha->beta style > discussion. I'm looking forward to us discussing release candidates. > that will be cool indeed. > > mike > > On Thu, Apr 23, 2009 at 9:32 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> I agree. >> But we took the decision to harvest the fix of events because they >> could rot >> dramatically. >> Then removing bad code is also important for the relicensing. >> The less etoy bookmoprh the less relicensing we have. >> >>> I have been running the sunits recently for each update or published >>> build. It would be great if more people could do this so that we can >>> seriously get the error list down. Also we should try not to push >>> out >>> updates if they increase the error number. To make comparison >>> easier I >>> was going to publish the baseline results on the wiki to make it >>> easy >>> to see progress. I got stuck when recently the tests did not >>> complete >>> :-) but I think this is a good example of why we should focus in >>> this >>> area. >>> Thanks mike >> >> _______________________________________________ >> 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 >

April 24, 2009