August 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] 1.0beta Chinese fonts and symbol bugs

by empty

Hi, I tried 1.0 beta on Windows XP to find Chinese Fonts having some problem. * each font can't display this much used common character æ and maybe more * now symbols are automaticallly turned from #ä¸å¥è©± into this:#'ä¸å¥è©±' and that is not needed since Chinese string doesn't contain any spaces * some fonts such as simsun-18030 will add space after each English letter and make things look like t h i s, that's incorrect In fact, as for Chinese fonts, the first test package of Unicode has been the best one. All later versions have problems. Sorry I know too little to contribute to code. Best Regards, Empt ----- åç¡ä½ åç¡æ³ åç¡å§ -- View this message in context: http://n2.nabble.com/1.0beta-Chinese-fonts-and-symbol-bugs-tp3370936p337093… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 1, 2009

Re: [Pharo-project] Custom user Interrupt handling

by Michael Rueger

Dale Henrichs wrote: > Michael, > > What's the approved method for unregistering the current user interrupt handler? > > InputEventFetcher default eventHandlers copy do: [:hndlr | > (hndlr isKindOf: UserInterruptHandler) ifTrue: [ hndlr unregister]]. > > Looks like it would work, but seems a bit fragile. Hmm, well, that part obviously wasn't thought out well... So your code above would do for now. A better way could be to have the UserInterruptHandler class remember the current registered handler. Michael

Aug. 1, 2009

Re: [Pharo-project] keyboard shortcut open a warning

by Mariano Martinez Peck

On Sat, Aug 1, 2009 at 10:28 AM, Marcus Denker <denker(a)acm.org> wrote: > On Friday, July 31, 2009, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > may be we should simply remove that item. > > menu > > system > > keyboard shortcuts > > yes > why? is there other way newbie and not so newbie people can see the list of shortcuts? Using the mouse is ugly for me and I try to use shortcut as much as possible. > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > -- > Marcus Denker -- denker(a)acm.org > http://www.marcusdenker.de > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 1, 2009

Re: [Pharo-project] Pharo name format

by Marcus Denker

On 01.08.2009, at 16:32, Michael Roberts wrote: > my preference would be everything you describe apart from the tag. I > am not a fan of encoding too much in the file name. I would prefer > some decent release notes contained within the zip. > Yes, we need to be better in changelog management. We need: -> A Blog on the pharo CMS for posting all the things there in addition to the [update] posts (beeing worked on, should be ready next week) -> A ChangeLog.txt with every zip. -> A changelog available on the downloads page. Marcus > thanks, > mike > > 2009/8/1 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com>: >> Now that the release date for pharo is close, I propose to use the >> following sintax for the pharo core products >> >> PharoCore-x.y-#####-TagName.zip >> >> where >> x.y >> is the version of pharo (0.1, 1.0, 1.1, 2.0, 2.1, etc) >> ##### >> is the number of image release in that version (10449, 10450, 10451, >> etc) >> TagName >> is a tag for better explain some specific feature of the image >> (closure, RELEASE, STABLE, beta, etc) >> >> e.g. >> >> For a normal daily release, say 10450, in the 0.1 branch: >> >> PharoCore-0.1-10450.zip >> >> For the image that has all tests in green: >> >> PharoCore-0.1-10456-AllTestGreen.zip >> >> For the image that it is the first stable 1.0: >> >> PharoCore-1.0-10478-RELEASE_1_0.zip >> >> For the next image with the NewCompiler code integrated, after the >> 1.0 >> release: >> >> PharoCore-1.0-10490-NewCompiler.zip >> >> For a subsecuent 1.1 release, that includes NewCompiler: >> >> PharoCore-1.1-10511-RELEASE_1_1.zip >> >> When, for example, 1.1 is the current branch, and 1.0 has fixes >> support >> and a new emergency release for the old 1.0 branch: >> >> PharoCore-1.0-10512-UPDATE_1.zip >> >> Release for pharo 2.0: >> >> PharoCore-2.0-10890-RELEASE_2_0.zip >> >> Other fix in the 1.1 branch (brach 1.0 is out of support): >> >> PharoCore-1.1-10915-UPDATE_1.zip >> >> Notes: We can also reset the number in each mayor release (0.1, 1.0, >> 1.1, etc) so that the updates to the old supportes branches can be a >> continuous. For example, the previous names would be (in the same >> order >> of release as the examples above): >> >> PharoCore-0.1-10450.zip >> >> PharoCore-0.1-10456-AllTestGreen.zip >> >> PharoCore-1.0-10001-RELEASE_1_0.zip >> >> PharoCore-1.0-10002-NewCompiler.zip >> >> PharoCore-1.1-10001-RELEASE_1_1.zip >> >> PharoCore-1.0-10003-UPDATE_1.zip >> >> PharoCore-2.0-10001-RELEASE_2_0.zip >> >> PharoCore-1.1-10002-UPDATE_1.zip >> >> etc >> >> Also, the PharoCore-1.0-10001-RELEASE_1_0.zip would be a copy of the >> last image of 0.1 branch (in this example >> PharoCore-0.1-10456-AllTestGreen.zip) >> >> But this is mostly estetic and can potentially confuse new users. >> >> What do you think? >> >> >> _______________________________________________ >> 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

Aug. 1, 2009

Re: [Pharo-project] Pharo name format

by Miguel Enrique CobÃ¡ Martinez

El sÃ¡b, 01-08-2009 a las 22:32 +0200, Michael Roberts escribiÃ³: > my preference would be everything you describe apart from the tag. I > am not a fan of encoding too much in the file name. I would prefer > some decent release notes contained within the zip. > Yes, I am the same opinion, but I saw that the names of the files in the inria page already have a tag for informational purpouses. We can use a ReleasNotes.txt file inside the zip that includes the info sent in the mail announce with the issues solved in it. Miguel CobÃ¡ > thanks, > mike > > 2009/8/1 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com>: > > Now that the release date for pharo is close, I propose to use the > > following sintax for the pharo core products > > > > PharoCore-x.y-#####-TagName.zip > > > > where > > x.y > > is the version of pharo (0.1, 1.0, 1.1, 2.0, 2.1, etc) > > ##### > > is the number of image release in that version (10449, 10450, 10451, > > etc) > > TagName > > is a tag for better explain some specific feature of the image > > (closure, RELEASE, STABLE, beta, etc) > > > > e.g. > > > > For a normal daily release, say 10450, in the 0.1 branch: > > > > PharoCore-0.1-10450.zip > > > > For the image that has all tests in green: > > > > PharoCore-0.1-10456-AllTestGreen.zip > > > > For the image that it is the first stable 1.0: > > > > PharoCore-1.0-10478-RELEASE_1_0.zip > > > > For the next image with the NewCompiler code integrated, after the 1.0 > > release: > > > > PharoCore-1.0-10490-NewCompiler.zip > > > > For a subsecuent 1.1 release, that includes NewCompiler: > > > > PharoCore-1.1-10511-RELEASE_1_1.zip > > > > When, for example, 1.1 is the current branch, and 1.0 has fixes support > > and a new emergency release for the old 1.0 branch: > > > > PharoCore-1.0-10512-UPDATE_1.zip > > > > Release for pharo 2.0: > > > > PharoCore-2.0-10890-RELEASE_2_0.zip > > > > Other fix in the 1.1 branch (brach 1.0 is out of support): > > > > PharoCore-1.1-10915-UPDATE_1.zip > > > > Notes: We can also reset the number in each mayor release (0.1, 1.0, > > 1.1, etc) so that the updates to the old supportes branches can be a > > continuous. For example, the previous names would be (in the same order > > of release as the examples above): > > > > PharoCore-0.1-10450.zip > > > > PharoCore-0.1-10456-AllTestGreen.zip > > > > PharoCore-1.0-10001-RELEASE_1_0.zip > > > > PharoCore-1.0-10002-NewCompiler.zip > > > > PharoCore-1.1-10001-RELEASE_1_1.zip > > > > PharoCore-1.0-10003-UPDATE_1.zip > > > > PharoCore-2.0-10001-RELEASE_2_0.zip > > > > PharoCore-1.1-10002-UPDATE_1.zip > > > > etc > > > > Also, the PharoCore-1.0-10001-RELEASE_1_0.zip would be a copy of the > > last image of 0.1 branch (in this example > > PharoCore-0.1-10456-AllTestGreen.zip) > > > > But this is mostly estetic and can potentially confuse new users. > > > > What do you think? > > > > > > _______________________________________________ > > 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

Aug. 1, 2009

Re: [Pharo-project] Pharo name format

by Michael Roberts

my preference would be everything you describe apart from the tag. I am not a fan of encoding too much in the file name. I would prefer some decent release notes contained within the zip. thanks, mike 2009/8/1 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com>: > Now that the release date for pharo is close, I propose to use the > following sintax for the pharo core products > > PharoCore-x.y-#####-TagName.zip > > where > x.y > Â is the version of pharo (0.1, 1.0, 1.1, 2.0, 2.1, etc) > ##### > Â is the number of image release in that version (10449, 10450, 10451, > etc) > TagName > Â is a tag for better explain some specific feature of the image > (closure, RELEASE, STABLE, beta, etc) > > e.g. > > For a normal daily release, say 10450, in the 0.1 branch: > > PharoCore-0.1-10450.zip > > For the image that has all tests in green: > > PharoCore-0.1-10456-AllTestGreen.zip > > For the image that it is the first stable 1.0: > > PharoCore-1.0-10478-RELEASE_1_0.zip > > For the next image with the NewCompiler code integrated, after the 1.0 > release: > > PharoCore-1.0-10490-NewCompiler.zip > > For a subsecuent 1.1 release, that includes NewCompiler: > > PharoCore-1.1-10511-RELEASE_1_1.zip > > When, for example, 1.1 is the current branch, and 1.0 has fixes support > and a new emergency release for the old 1.0 branch: > > PharoCore-1.0-10512-UPDATE_1.zip > > Release for pharo 2.0: > > PharoCore-2.0-10890-RELEASE_2_0.zip > > Other fix in the 1.1 branch (brach 1.0 is out of support): > > PharoCore-1.1-10915-UPDATE_1.zip > > Notes: We can also reset the number in each mayor release (0.1, 1.0, > 1.1, etc) so that the updates to the old supportes branches can be a > continuous. For example, the previous names would be (in the same order > of release as the examples above): > > PharoCore-0.1-10450.zip > > PharoCore-0.1-10456-AllTestGreen.zip > > PharoCore-1.0-10001-RELEASE_1_0.zip > > PharoCore-1.0-10002-NewCompiler.zip > > PharoCore-1.1-10001-RELEASE_1_1.zip > > PharoCore-1.0-10003-UPDATE_1.zip > > PharoCore-2.0-10001-RELEASE_2_0.zip > > PharoCore-1.1-10002-UPDATE_1.zip > > etc > > Also, the PharoCore-1.0-10001-RELEASE_1_0.zip would be a copy of the > last image of 0.1 branch (in this example > PharoCore-0.1-10456-AllTestGreen.zip) > > But this is mostly estetic and can potentially confuse new users. > > What do you think? > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 1, 2009

Re: [Pharo-project] #remoteHostAddress

by Schwab,Wilhelm K

Carlos, What if one cannot (admin rights) or simply does not wish to be bothered tweaking configurations? I found a goofy sequence of operations that correctly resolved local names, at least on Windows, and will eventually replicate that in Pharo. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Carlos Crosetti Sent: Saturday, August 01, 2009 12:40 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] #remoteHostAddress I agree. localhost bound to the loop address is the ip atandard, and based on the stack implementation you run on, you may wish to define localhost to resolve different, you haev the configuration files to change that -----Mensaje original----- De: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr]En nombre de Schwab,Wilhelm K Enviado el: SÃ¡bado, 01 de Agosto de 2009 02:13 p.m. Para: Pharo-project(a)lists.gforge.inria.fr Asunto: Re: [Pharo-project] #remoteHostAddress For 'localhost', sure, 127.0.0.1 is probably the correct response. However, one can also run into situations of needing to find "the" current IP number/name. There are also servers with multiple addresses, and numbers with multiple names. ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Ramiro Diaz Trepat Sent: Saturday, August 01, 2009 9:00 AM To: Pharo-project(a)lists.gforge.inria.fr; johnmci(a)smalltalkconsulting.com Subject: Re: [Pharo-project] #remoteHostAddress Yes, wouldn't you expect 127.0.0.1 as the response from: NetNameResolver addressForName: 'localhost' ? On Fri, Jul 31, 2009 at 3:52 AM, John M McIntosh <johnmci(a)smalltalkconsulting.com<mailto:johnmci@smalltalkconsulting.com>> wrote: Well that does ^NetNameResolver addressForName: self localHostName where self localHostName on my machine returns 'Otter-2.local' where it really does addressesForName: and then if there is more than one then addresses first socketAddress So for my mac it's fe80::21c:42ff:fe00:9%en5(Otter-2), 0(0)-inet6-stream-tcp fe80::21c:42ff:fe00:8%en5(fe80::21c: 42ff:fe00:8%en5), 0(0)-inet6-stream-tcp fe80::21b:63ff:fe02:d2db%en5(fe80::21b: 63ff:fe02:d2db%en5), 0(0)-inet6-stream-tcp 10.37.129.2(10.37.129.2), 0(0)-inet4-stream-tcp 10.211.55.2(10.211.55.2), 0(0)-inet4-stream-tcp 192.168.1.139(192.168.1.139), 0(0)-inet4-stream-tcp where it has 4 ipv 6 address and 3 ipv 4 addresses. and doing NetNameResolver localHostAddress then gives: fe80::21c:42ff:fe00:9%en5(Otter-2),0(0) The problem then is figuring out what you want, versus grabbing the first element in the list of IP address serviced by the machine. Perhaps in this case you thought you should get 192.168.1.139? Now if I ask for ^NetNameResolver addressForName: 'localhost' then I get back ::1(localhost),0(0) On 30-Jul-09, at 2:07 PM, Ramiro Diaz Trepat wrote: > Sorry, this mail came out too quick. How to report the error is a > secondary matter. > I believe the issue is about localhost name resolution. I think > this was discussed around the Windows VM platform, but I am on a Mac. > > > NetNameResolver addressForName: 'localhost' > > does not return 127.0.0.1 > > And, > > NetNameResolver localHostAddress > > returns the address on the network leg (192.168.....) instead of > 127.0.0.1 > > Is the convention that localhost is always 127.0.0.1 ? > > > Cheers > > > r. > > > On Thu, Jul 30, 2009 at 9:20 PM, Ramiro Diaz Trepat <ramiro(a)diaztrepat.name<mailto:ramiro@diaztrepat.name> > > wrote: > I am trying to port Magma to Pharo, and I have run across the > following issue. > > Ini Pharo, the method: > > Socket>>connectTo: hostAddress port: port waitForConnectionFor: > timeout > (mir 6/17/2007 20:10) > > "Initiate a connection to the given port at the given host > address. Waits until the connection is established or time outs." > self connectNonBlockingTo: hostAddress port: port. > self > waitForConnectionFor: timeout > ifTimedOut: [ConnectionTimedOut signal: 'Cannot connect to ' > , self remoteHostAddress hostNumber , ':' , port asString] > > > #remoteHostAddress has no implementors in Pharo. > > The implementation of this method in Squeak uses NetNameResolver > > Socket>>connectTo: hostAddress port: port waitForConnectionFor: > timeout > (mu 8/14/2003 15:15) > "Initiate a connection to the given port at the given host > address. Waits until the connection is established or time outs." > self connectNonBlockingTo: hostAddress port: port. > self > waitForConnectionFor: timeout > ifTimedOut: [ConnectionTimedOut signal: 'Cannot connect to ' > , (NetNameResolver stringFromAddress: hostAddress) , ':' , port > asString] > > Who is maintaining Socket now in Pharo? > Has anyone got some advice on how to solve this? > Cheers > > r. > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com<mailto:johnmci@smalltalkconsulting.com>> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 1, 2009

[Pharo-project] Error logging - was Custom user Interrupt handling

by Schwab,Wilhelm K

Hello all, This reminds me of some things that evolved in Dolphin, at least some of which Pharo has already. Logging of unhandled exceptions is important, and Pharo does it. However, it appears to replace debug.log with every error. There should be an easy way to get it to accumulate errors. Imagine monitoring the performance of a server or embedded system; one cares not only that a backup or update failed, but that it fails often, etc. The log needs to be thread safe. Much of the content of debug.log looks like it overlaps with what Dolphin puts in a "crash dump." IIRC, it was my idealism combined with Blair McGlashan's deep understanding of VMs that lead to the latter. I noted that unhandled Smalltalk exceptions were logged, but the more rare crash that made it all the way to the OS was completely silent in the logs. Blair created the dump and added an interesting twist, which was to allow a crash dump to be fired off without actually needing the crash. That meant that the detailed (and verbose) stack dump with data was created on a crash, and could be triggered as needed. The error log did not carry the additional data, and was therefore small enough to accumulate. Chris Uppal created a wonderful tool called Ghoul to display crash dumps in a debugger-like view. It shows code from the current image (which might differ from the code that created the dump - but that's life), and inspects data from the dump. Highly recommended! There were some snags with format changes over time. Some of it involved decimal/hex confusion over offsets written by the VM, and possibly spotting the beginning and end of individual dump records. BTW, the latter problem might be something that I am recalling from my own logging adventures; certainly I had that problem at times, but Ghoul might have too. I'm not sure, but will mention it to be one the safe side. Finally, I noted that while there was a way to break out of a hang in the IDE, there was no way to get information from a deployed executable that managed to hang. I modified my runtime session managers [*]to hook into control-break, and logged text-only stack traces on all non-dead processes. That allowed me to see deadlocks that showed up rarely. I have not looked in a while, but the pieces of doing the same thing in Squeak/Pharo exist, perhaps with some cosmetic defects in the spacing between callstacks. The default "show me the callstack" should dump all stacks, not just the active process. FWIW. Bill [*] session managers are those wonderful Dolphin concepts that allow a Smalltalk image to know when it's been loaded, letting it (among other things) initialize sockets on its own, etc. Lesser artist borrow, great artists steal - sorry, I'll try to stop nagging :) -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Michael Rueger Sent: Saturday, August 01, 2009 8:37 AM To: Pharo-project(a)lists.gforge.inria.fr; dale.henrichs(a)gemstone.com Subject: Re: [Pharo-project] Custom user Interrupt handling Dale Henrichs wrote: > The class UserInterruptHandler is tantalizingly close, however, there > is no obvious way to insinuate myself as an interested party....It's > pretty much hard-wired to open a debugger on the interrupted > process.... Just write your own class (e.g. subclass UserInterruptHandler) and replace the handler (unregister the current one and register your own). That's why I designed it the way it is :-) michael _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 1, 2009

[Pharo-project] [update] #10403

by Marcus Denker

10403 ----- Issue 1023: Menu System>Keyboard shortcuts calls deprecated method Issue 1022: Mac Menus: merge File and System menu into the App menu Issue 1025: Menu System->Preferences->set author initials calls deprecated method -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

Aug. 1, 2009

Re: [Pharo-project] #remoteHostAddress

by Carlos Crosetti

I agree. localhost bound to the loop address is the ip atandard, and based on the stack implementation you run on, you may wish to define localhost to resolve different, you haev the configuration files to change that -----Mensaje original----- De: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr]En nombre de Schwab,Wilhelm K Enviado el: Sabado, 01 de Agosto de 2009 02:13 p.m. Para: Pharo-project(a)lists.gforge.inria.fr Asunto: Re: [Pharo-project] #remoteHostAddress For 'localhost', sure, 127.0.0.1 is probably the correct response. However, one can also run into situations of needing to find "the" current IP number/name. There are also servers with multiple addresses, and numbers with multiple names. ---------------------------------------------------------------------------- -- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Ramiro Diaz Trepat Sent: Saturday, August 01, 2009 9:00 AM To: Pharo-project(a)lists.gforge.inria.fr; johnmci(a)smalltalkconsulting.com Subject: Re: [Pharo-project] #remoteHostAddress Yes, wouldn't you expect 127.0.0.1 as the response from: NetNameResolver addressForName: 'localhost' ? On Fri, Jul 31, 2009 at 3:52 AM, John M McIntosh <johnmci(a)smalltalkconsulting.com> wrote: Well that does ^NetNameResolver addressForName: self localHostName where self localHostName on my machine returns 'Otter-2.local' where it really does addressesForName: and then if there is more than one then addresses first socketAddress So for my mac it's fe80::21c:42ff:fe00:9%en5(Otter-2), 0(0)-inet6-stream-tcp fe80::21c:42ff:fe00:8%en5(fe80::21c: 42ff:fe00:8%en5), 0(0)-inet6-stream-tcp fe80::21b:63ff:fe02:d2db%en5(fe80::21b: 63ff:fe02:d2db%en5), 0(0)-inet6-stream-tcp 10.37.129.2(10.37.129.2), 0(0)-inet4-stream-tcp 10.211.55.2(10.211.55.2), 0(0)-inet4-stream-tcp 192.168.1.139(192.168.1.139), 0(0)-inet4-stream-tcp where it has 4 ipv 6 address and 3 ipv 4 addresses. and doing NetNameResolver localHostAddress then gives: fe80::21c:42ff:fe00:9%en5(Otter-2),0(0) The problem then is figuring out what you want, versus grabbing the first element in the list of IP address serviced by the machine. Perhaps in this case you thought you should get 192.168.1.139? Now if I ask for ^NetNameResolver addressForName: 'localhost' then I get back ::1(localhost),0(0) On 30-Jul-09, at 2:07 PM, Ramiro Diaz Trepat wrote: > Sorry, this mail came out too quick. How to report the error is a > secondary matter. > I believe the issue is about localhost name resolution. I think > this was discussed around the Windows VM platform, but I am on a Mac. > > > NetNameResolver addressForName: 'localhost' > > does not return 127.0.0.1 > > And, > > NetNameResolver localHostAddress > > returns the address on the network leg (192.168.....) instead of > 127.0.0.1 > > Is the convention that localhost is always 127.0.0.1 ? > > > Cheers > > > r. > > > On Thu, Jul 30, 2009 at 9:20 PM, Ramiro Diaz Trepat <ramiro(a)diaztrepat.name > > wrote: > I am trying to port Magma to Pharo, and I have run across the > following issue. > > Ini Pharo, the method: > > Socket>>connectTo: hostAddress port: port waitForConnectionFor: > timeout > (mir 6/17/2007 20:10) > > "Initiate a connection to the given port at the given host > address. Waits until the connection is established or time outs." > self connectNonBlockingTo: hostAddress port: port. > self > waitForConnectionFor: timeout > ifTimedOut: [ConnectionTimedOut signal: 'Cannot connect to ' > , self remoteHostAddress hostNumber , ':' , port asString] > > > #remoteHostAddress has no implementors in Pharo. > > The implementation of this method in Squeak uses NetNameResolver > > Socket>>connectTo: hostAddress port: port waitForConnectionFor: > timeout > (mu 8/14/2003 15:15) > "Initiate a connection to the given port at the given host > address. Waits until the connection is established or time outs." > self connectNonBlockingTo: hostAddress port: port. > self > waitForConnectionFor: timeout > ifTimedOut: [ConnectionTimedOut signal: 'Cannot connect to ' > , (NetNameResolver stringFromAddress: hostAddress) , ':' , port > asString] > > Who is maintaining Socket now in Pharo? > Has anyone got some advice on how to solve this? > Cheers > > r. > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- = = = ======================================================================== 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

Aug. 1, 2009