- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Monticello connecting to ftp repo on non-standard port

by Pat Maddox

actually scratch that, Pharo's monticello just isn't working on FTP for me, even if the server is on port 21 On Mon, Jun 15, 2009 at 6:04 AM, Pat Maddox<pat.maddox(a)gmail.com> wrote: > Hi, I set up a monticello repository on one of my FTP servers. Â The > FTP server does not run on port 21. Â I created a repo connection from > my Pharo 09.06.1 image, it looks like: > > MCFtpRepository > Â Â Â Â host: 'mysite.com:1234' > Â Â Â Â directory: 'mc' > Â Â Â Â user: 'smalltalk' > Â Â Â Â password: 'supersecret' > > When I click on "Open" I get the error: > MessageNotUnderstood: ByteArray>>port: > > Any ideas what's going on? Â These connection settings work fine on a > Squeak image that I downloaded a few weeks ago. > > I would post a more complete stack trace but I can't figure out how. > I can open the debugger, but not copy and paste any stack trace > output. > > Pat > -- (415) 297-8028 http://www.patmaddox.com Twitter: @patmaddox GitHub: http://github.com/pat-maddox

June 15, 2009

[Pharo-project] Monticello connecting to ftp repo on non-standard port

by Pat Maddox

Hi, I set up a monticello repository on one of my FTP servers. The FTP server does not run on port 21. I created a repo connection from my Pharo 09.06.1 image, it looks like: MCFtpRepository host: 'mysite.com:1234' directory: 'mc' user: 'smalltalk' password: 'supersecret' When I click on "Open" I get the error: MessageNotUnderstood: ByteArray>>port: Any ideas what's going on? These connection settings work fine on a Squeak image that I downloaded a few weeks ago. I would post a more complete stack trace but I can't figure out how. I can open the debugger, but not copy and paste any stack trace output. Pat

June 15, 2009

Re: [Pharo-project] Fwd: [Squeak-fr] durationToRun

by StÃ©phane Ducasse

Tx! Stef On Jun 15, 2009, at 10:43 AM, Nicolas Cellier wrote: > Sauf si la nouvelle version de Duration prend garde d'avoir nanos < > NanosInSecond > Ce qu'elle fait dans certains messages de crÃ©ation mais pas dans tous. > > Unless new version of Duration takes care to assert nanos < > NanosInSecond > Which is done in some instance creation messages but not all... > > I guess the reason of the changes were to avoid LargeInteger > operations and gain some efficiency. > It might not be the best idea to revert to a slow implementation. > We should better correct instance creation to always assert nanos < > NanosInSecond. > > Nicolas > > Le 15 juin 2009 10:06, StÃ©phane Ducasse<stephane.ducasse(a)inria.fr> a > Ã©crit : >> >> >> Begin forwarded message: >> >>> From: StÃ©phane Rollandin <hepta(a)zogotounga.net> >>> Date: June 15, 2009 9:32:54 AM CEDT >>> To: Squeak in french / Squeak en franÃ§ais <squeak-fr(a)lists.squeakfoundation.org >>>> >>> Subject: Re: [Squeak-fr] durationToRun >>> Reply-To: Squeak in french / Squeak en franÃ§ais <squeak-fr(a)lists.squeakfoundation.org >>>> >>> >>> [3500 milliSeconds asDelay wait] durationToRun >>> >>> donne 0:00:00:00.3501 sur Squeak3.10.2, mais donne le format correct >>> 0:00:00:03.5 sur Squeak3.8.2. >>> >>> le problÃ¨me vient de >>> >>> Duration class>> >>> days: days hours: hours minutes: minutes seconds: seconds >>> nanoSeconds: nanos >>> >>> ^ self seconds: ((days * SecondsInDay) >>> + (hours * SecondsInHour) >>> + (minutes * SecondsInMinute) >>> + seconds) >>> nanoSeconds: nanos >>> >>> >>> ... qui est faux, car les nanoseconds ne participent pas au calcul >>> des seconds. >>> >>> la version prÃ©cÃ©dente est: >>> >>> days: days hours: hours minutes: minutes seconds: seconds >>> nanoSeconds: nanos >>> >>> ^ self nanoSeconds: >>> ( ( (days * SecondsInDay) >>> + (hours * SecondsInHour) >>> + (minutes * SecondsInMinute) >>> + seconds ) * NanosInSecond ) >>> + nanos. >>> >>> >>> et lÃ Ã§a marche. >>> >>> Stef >>> >>> >>> _______________________________________________ >>> Squeak-fr mailing list >>> Squeak-fr(a)lists.squeakfoundation.org >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr >>> >> >> >> _______________________________________________ >> 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 >

June 15, 2009

Re: [Pharo-project] Fwd: [Squeak-fr] durationToRun

by Nicolas Cellier

Sauf si la nouvelle version de Duration prend garde d'avoir nanos < NanosInSecond Ce qu'elle fait dans certains messages de crÃ©ation mais pas dans tous. Unless new version of Duration takes care to assert nanos < NanosInSecond Which is done in some instance creation messages but not all... I guess the reason of the changes were to avoid LargeInteger operations and gain some efficiency. It might not be the best idea to revert to a slow implementation. We should better correct instance creation to always assert nanos < NanosInSecond. Nicolas Le 15 juin 2009 10:06, StÃ©phane Ducasse<stephane.ducasse(a)inria.fr> a Ã©crit : > > > Begin forwarded message: > >> From: StÃ©phane Rollandin <hepta(a)zogotounga.net> >> Date: June 15, 2009 9:32:54 AM CEDT >> To: Squeak in french / Squeak en franÃ§ais <squeak-fr(a)lists.squeakfoundation.org >> > >> Subject: Re: [Squeak-fr] durationToRun >> Reply-To: Squeak in french / Squeak en franÃ§ais <squeak-fr(a)lists.squeakfoundation.org >> > >> >> [3500 milliSeconds asDelay wait] durationToRun >> >> donne 0:00:00:00.3501 sur Squeak3.10.2, mais donne le format correct >> 0:00:00:03.5 sur Squeak3.8.2. >> >> le problÃ¨me vient de >> >> Duration class>> >> days: days hours: hours minutes: minutes seconds: seconds >> nanoSeconds: nanos >> >> Â Â Â ^ self seconds: ((days * SecondsInDay) >> Â Â Â + (hours * SecondsInHour) >> Â Â Â + (minutes * SecondsInMinute) >> Â Â Â + seconds) >> Â Â Â Â Â Â Â nanoSeconds: nanos >> >> >> ... qui est faux, car les nanoseconds ne participent pas au calcul >> des seconds. >> >> la version prÃ©cÃ©dente est: >> >> days: days hours: hours minutes: minutes seconds: seconds >> nanoSeconds: nanos >> >> Â Â Â ^ self nanoSeconds: >> Â Â Â ( ( (days * SecondsInDay) >> Â Â Â + (hours * SecondsInHour) >> Â Â Â + (minutes * SecondsInMinute) >> Â Â Â + seconds ) * NanosInSecond ) >> Â Â Â + nanos. >> >> >> et lÃ Ã§a marche. >> >> Stef >> >> >> _______________________________________________ >> Squeak-fr mailing list >> Squeak-fr(a)lists.squeakfoundation.org >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 15, 2009

[Pharo-project] Fwd: [Squeak-fr] durationToRun

by StÃ©phane Ducasse

Begin forwarded message: > From: StÃ©phane Rollandin <hepta(a)zogotounga.net> > Date: June 15, 2009 9:32:54 AM CEDT > To: Squeak in french / Squeak en franÃ§ais <squeak-fr(a)lists.squeakfoundation.org > > > Subject: Re: [Squeak-fr] durationToRun > Reply-To: Squeak in french / Squeak en franÃ§ais <squeak-fr(a)lists.squeakfoundation.org > > > > [3500 milliSeconds asDelay wait] durationToRun > > donne 0:00:00:00.3501 sur Squeak3.10.2, mais donne le format correct > 0:00:00:03.5 sur Squeak3.8.2. > > le problÃ¨me vient de > > Duration class>> > days: days hours: hours minutes: minutes seconds: seconds > nanoSeconds: nanos > > ^ self seconds: ((days * SecondsInDay) > + (hours * SecondsInHour) > + (minutes * SecondsInMinute) > + seconds) > nanoSeconds: nanos > > > ... qui est faux, car les nanoseconds ne participent pas au calcul > des seconds. > > la version prÃ©cÃ©dente est: > > days: days hours: hours minutes: minutes seconds: seconds > nanoSeconds: nanos > > ^ self nanoSeconds: > ( ( (days * SecondsInDay) > + (hours * SecondsInHour) > + (minutes * SecondsInMinute) > + seconds ) * NanosInSecond ) > + nanos. > > > et lÃ Ã§a marche. > > Stef > > > _______________________________________________ > Squeak-fr mailing list > Squeak-fr(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr >

June 15, 2009

[Pharo-project] Fwd: [ANN] 10340

by StÃ©phane Ducasse

Begin forwarded message: > From: pharo-project-owner(a)lists.gforge.inria.fr > Date: June 14, 2009 11:29:07 PM CEDT > To: stephane.ducasse(a)smalltalk.fr > Subject: [ANN] 10340 > > You are not allowed to post to this mailing list, and your message has > been automatically rejected. If you think that your messages are > being rejected in error, contact the mailing list owner at > pharo-project-owner(a)lists.gforge.inria.fr. > > > From: StÃ©phane Ducasse <stephane.ducasse(a)smalltalk.fr> > Date: June 14, 2009 11:28:52 PM CEDT > To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> > Subject: [ANN] 10340 > > > Hi > > issue 135: initialize calling super initialize partly integrated (A - > > Morph package) > Thanks alain for this job. > > Stef > > >

June 14, 2009

[Pharo-project] idea to have a better methodFinder :)

by StÃ©phane Ducasse

Hi the methodFInder hard codes the methods that should not be executed. Now with pragma we should be able to have a fully dynamic method finder where nothing is hardcoded. If somebody wants to give a try it would be great because MF is a cool tool. Now too static. Stef

June 14, 2009

[Pharo-project] [Off Topic] Looking for english "correspondants" for my boys

by StÃ©phane Ducasse

Hi guys I have two boys 11 and 8 years old which would like to talk english with some other boys. So I'm looking for kids that would like to exchange emails or visit (later) with mine :) Uk would be cool since we are at Lille. Stef

June 14, 2009

Re: [Pharo-project] [ANN] 10337

by StÃ©phane Ducasse

ok I will focus first on the initialize. Stef On Jun 14, 2009, at 10:21 PM, Alain Plantec wrote: > Alain Plantec a Ã©crit : >> StÃ©phane Ducasse a Ã©crit : >>> ok I prefer that than a merging bug. >>> >> the LongTestCase >>#DecompilerTests method is touched by the >> BookMorph >> removal. >> Unfortunately, the class LongTestCase is unpackaged. > oups, this is the class DecompilerTests that is unpackaged and the > method DecompilerTests>>decompilerDiscrepancies which is touched by > the > BookMorph removal. >> I guess that is is the reason why it was not in the slice. >> -> new issue http://code.google.com/p/pharo/issues/detail?id=888 >> Alain >> >> >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 14, 2009

Re: [Pharo-project] [ANN] 10337

by Alain Plantec

Alain Plantec a Ã©crit : > StÃ©phane Ducasse a Ã©crit : >> ok I prefer that than a merging bug. >> > the LongTestCase >>#DecompilerTests method is touched by the BookMorph > removal. > Unfortunately, the class LongTestCase is unpackaged. oups, this is the class DecompilerTests that is unpackaged and the method DecompilerTests>>decompilerDiscrepancies which is touched by the BookMorph removal. > I guess that is is the reason why it was not in the slice. > -> new issue http://code.google.com/p/pharo/issues/detail?id=888 > Alain > > >

June 14, 2009