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

Re: [Pharo-project] [update] #10514 Network fix

by Adrian Lienhard

Yes, pre-SocketAddress. We have left the class SocketAddress in the image but without the additional behavior. Adrian On Mar 13, 2010, at 20:06 , Chris Muller wrote: > One year ago? So pre-SocketAddress? > > On Sat, Mar 13, 2010 at 8:22 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >> NOTE: this update reverts NetNameResolver and code from other classes like Socket to the state we had about one year ago. Please let us know about any problems related to networking! >> >> 10514 >> ----- >> - Issue 1884: NetNameResolver doesn't work in PharoCore 10508 >> - Upadet VBRegex to version VB-Regex-lr.38 >> >> ___________________ >> http://www.adrian-lienhard.ch/ >> >> >> _______________________________________________ >> 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

March 14, 2010

Re: [Pharo-project] Collection

by Philippe Marschall

On 12.03.2010 14:05, Lukas Renggli wrote: >> What would be cool for Seaside IMHO: >> - Multi Value Dictionaries, e.g. for request parameters >> - Some kind of thread safe map with atomic operations [2], e.g. for >> session store > > Why would that be cool? We already have a WAMultiValueDictionary for > request parameters. Also we have some ad-hock solutions for the thread > safe dictionaries. > > I would be more interested to see ... > > - if it would be beneficial for a collection to be able to swap out > its internal representation automatically depending on its load and > use ... > > - what we can do by externalizing the enumeration protocol (no, this > is not the same as streams or the iterable refactoring that was > recently proposed) ... > > - how to make collections more composable, e.g. make them thread safe, > make them read-only, make them ordered (sets and dictionaries), ... > [1] goes a little bit in that direction, even if only from the user point of view. [1] http://google-collections.googlecode.com/svn/trunk/javadoc/index.html?com/g… Cheers Philippe

March 14, 2010

[Pharo-project] Mac carbon VM goes to 4.2.3beta1U

by John M McIntosh

In order to wrap up some VM fixes that should be pushed into the Squeak 4.x offering I've compiled up a 4.2.3beta1U VM This will be the last 4.x series of macintosh VMs as the 5.x series gains support. Someone should run the Sunit and smoke test to ensure the VM is sane. Follow the macintosh link from http://www.squeakvm.org/index.html 4.2.3b1 We update to VMMaker 160 Reference Mantis 7405: Array new: SmallInteger maxVal broken. Reference Mantis 7407: BitBlt. Incorrect alpha values for several rules. Reference Mantis 7421: Bug in Interpreter>>primitiveNextPut: (Various 64bit fixes which don't apply to this 32bit VM) Put ObjectiveCPlugin.bundle to 1.1.2 Removed SparklePlugin because of file copy issues on squeak 4.0 build process. bad sym links **** This VM includes some features not in VMMaker yet ***** (a) primitiveAsyncFileOpen: 64bit (b) explicit declare for primitiveShowHostWindow: (c) primitive for microsecond clock (f) statGCTime, statFullGCMSecs,statIGCDeltaTime,statIncrGCMSecs go to 64bit for microscecond clock (e) primitiveVMParameter changes to pull back 64bit values (f) JPEGReaderPlugin, work to make 64bit clean (g) primitiveMIDIGetPortName: 64bit fix NSCursorWrapper.m compiler warning cleanup sqMacMacmain.m compiler warning cleanup sqMacTime.c add microsecond clock sqmacWIndowUniversal.c compiler warning cleanup -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

March 14, 2010

Re: [Pharo-project] [squeak-dev] NetNameResolver/ifconfig/interfaces

by Schwab,Wilhelm K

John, Prompts are bad, at least if they are mandatory. There should be a way to provide a block that takes as argument a collection of the available interfaces; variatiants of the method could do first/last or (hopefully) guess the correct interface as a lot of software seems to do. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John M McIntosh Sent: Saturday, March 13, 2010 3:22 PM To: The general-purpose Squeak developers list Cc: Pharo Development Subject: Re: [Pharo-project] [squeak-dev] NetNameResolver/ifconfig/interfaces Ok, well I spent the evening looking into this. It's unclear if reverting the new/old socket stuff in Pharo is a good idea, or if we just adjust things a bit in the name lookup that would solve things. There are two questions to resolve (1) Do we want to return an IPV4 address from the network lookup? or an IPV6 address? (2) What do we do when we have 2 or more active IP interfaces on the machine, prompt for which one to use? Pick one at random, use the first or last one? If the community can decide what to do, then we can propose a solution. So how it works. NetNameResolver localHostAddress fe80::21c:42ff:fe00:9%en5(otter-2.local),0(0) Gah... what's that? Well the interface is: en5: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::21c:42ff:fe00:9%en5 prefixlen 64 scopeid 0x8 inet 10.37.129.2 netmask 0xffffff00 broadcast 10.37.129.255 ether 00:1c:42:00:00:09 media: autoselect status: active supported media: autoselect Thus it's giving me an IPV6 address. The chore is more complicated that one would care to see. I see Microsoft had a hand in defining the spec. So it first asks the gethostname for the name of the host. As an example my macbook pro has Otter-2.local which is what [otter-2:~] johnmci% hostname Otter-2.local That's a bonjour assigned name since if I do [otter-2:~] johnmci% nslookup Otter-2.local Server: 192.168.1.7 Address: 192.168.1.7#53 ** server can't find Otter-2.local: NXDOMAIN Then we are off to: getnameinfo which returns a chain of IPV4 and IPV6 address that Otter-2.local would resolve to. In this case there are six address, broken in to IPV6 and IPV4 fe80::21c:42ff:fe00:8%en4(otter-2.local),0(0)-inet6-stream-tcp fe80::21c:42ff:fe00:9%en5(otter-2.local),0(0)-inet6-stream-tcp fe80::21b:63ff:fe02:d2db%en1(otter-2.local),0(0)-inet6-stream-tcp 10.211.55.2(10.211.55.2),0(0)-inet4-stream-tcp 10.37.129.2(10.37.129.2),0(0)-inet4-stream-tcp 192.168.1.141(192.168.1.141),0(0)-inet4-stream-tcp So looks kinda random, but it's not. It's defined by Microsoft & committee etc. in http://www.faqs.org/rfcs/rfc3484.html The objective is to sort the list into some order. I must say you can't actually tell from reading the docs, and things over the past decade have changed. So I refer to some cheat sheets that *might* be correct. Now the macbook pro in this case uses 192.168.1.141 as the assigned tcp/ip address from our internal DHCP server. The 10.211.55.2 is a parallels shared network adaptor and 10.37.129.2 is the parallels host-only network adaptor. All three interfaces show as active, and if you consider the 'ifconfig -a' below you would be hard pressed to determine which interface is the one facing the company intranet. [otter-2:~] johnmci% ifconfig -a lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.1 netmask 0xff000000 gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 stf0: flags=0<> mtu 1280 en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 00:17:f2:d9:57:35 media: autoselect status: inactive supported media: autoselect 10baseT/UTP <half-duplex> 10baseT/UTP <full-duplex> 10baseT/UTP <full-duplex,hw-loopback> 10baseT/UTP <full-duplex,flow-control> 100baseTX <half-duplex> 100baseTX <full-duplex> 100baseTX <full-duplex,hw-loopback> 100baseTX <full-duplex,flow-control> 1000baseT <full-duplex> 1000baseT <full-duplex,hw-loopback> 1000baseT <full-duplex,flow-control> none fw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 2030 lladdr 00:19:e3:ff:fe:93:92:7c media: autoselect <full-duplex> status: inactive supported media: autoselect <full-duplex> en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::21b:63ff:fe02:d2db%en1 prefixlen 64 scopeid 0x6 inet 192.168.1.141 netmask 0xffffff00 broadcast 192.168.1.255 ether 00:1b:63:02:d2:db media: autoselect status: active supported media: autoselect en4: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::21c:42ff:fe00:8%en4 prefixlen 64 scopeid 0x7 inet 10.211.55.2 netmask 0xffffff00 broadcast 10.211.55.255 ether 00:1c:42:00:00:08 media: autoselect status: active supported media: autoselect en5: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::21c:42ff:fe00:9%en5 prefixlen 64 scopeid 0x8 inet 10.37.129.2 netmask 0xffffff00 broadcast 10.37.129.255 ether 00:1c:42:00:00:09 media: autoselect status: active supported media: autoselect Where en0 is ethernet jack, fw0 is firewire, en1 is wireless, en4 & en5 are virtual. Now the bias from the committee is precedence ::1/128 50 precedence ::/0 40 precedence 2002::/16 30 precedence ::/96 20 precedence ::ffff:0:0/96 10 scopev4 ::ffff:169.254.0.0/112 2 scopev4 ::ffff:127.0.0.0/104 2 scopev4 ::ffff:10.0.0.0/104 5 scopev4 ::ffff:172.16.0.0/108 5 scopev4 ::ffff:192.168.0.0/112 5 scopev4 ::ffff:0.0.0.0/96 14 This means of course the 10.0.0.0 address sorts before the 192.168.0.0 address. How helpful. So how do we know *which* is the proper address to use? Well no idea! However let's see what the API does. NetNameResolver class>> addressesForName: hostName | adresses | adresses := SocketAddressInformation forHost: hostName service: '' flags: 0 addressFamily: 0 socketType: SocketAddressInformation socketTypeStream protocol: SocketAddressInformation protocolTCP. ^adresses Now I can make it return just IPV4 address by doing: NetNameResolver class>> addressesForName: hostName | adresses | adresses := SocketAddressInformation forHost: hostName service: '' flags: 0 addressFamily: SocketAddressInformation addressFamilyINET4 socketType: SocketAddressInformation socketTypeStream protocol: SocketAddressInformation protocolTCP. ^adresses which then NetNameResolver localHostAddress gives: 10.37.129.2(10.37.129.2),0(0) I can also supply a service number string say SSH '22' that give back 10.37.129.2(10.37.129.2),22(ssh) since ssh is binding on all interfaces that's valid. Technically the getnameinfo gives back three address but again the code below grabs the first one which according to the rfc3484 is more likely to be the correct answer. addressForName: hostName "NetNameResolver addressForName: 'impara.de' " "NetNameResolver addressForName: 'localhost' " "NetNameResolver addressForName: '127.0.0.1' " | addresses | self useOldNetwork ifTrue: [^self oldAddressForName: hostName]. addresses := self addressesForName: hostName. ^addresses ifEmpty: [nil] ifNotEmpty: [addresses first socketAddress] But grabbing the first one doesn't meet people's expectations of correctness, however we just don't have enough information to decide *what* is correct. Now some people say OH let's return the en0 one because that is correct? Really how do you know? On my computer en0 is ethernet, but since I'm using wireless then en1 is the correct one. Obviously I could look in the list of IPV6 address find the LOWEST en# value, then grab the IPV4 entry. This would assume I check for the fact that the IPV6 interface has an IPV4 address and the sort order for the IPV6 is the same as for the IPV4. Gee that sounds ok? Well it's not, when for example I tether my MacBook Pro to my iPhone and abuse my privilege to move data over the cellular carrier, ah sorry you USA ATT folks, then the interface is: en6: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::226:8ff:fe72:5aa%en6 prefixlen 64 scopeid 0x9 inet 192.168.20.2 netmask 0xffffff00 broadcast 192.168.20.255 ether 00:26:08:72:05:aa media: 10baseT/UTP status: active supported media: 10baseT/UTP which fails the test that the lowest active en# is the one we want to use. 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.20.2(192.168.20.2),0(0)-inet4-stream-tcp) So the question is what would the community like to see happen. Well other than hide under a rock and see if the problem goes away... On 2010-03-12, at 8:41 AM, Chris Cunnington wrote: How is NetNameResolver choosing the interface to return an IP address from? In Cobalt this is a problem. You need the right address to connect to other spaces. Cobalt won't let you enter it by hand, so you are at the mercy of its guessing the correct interface. NetNameResolver localAddressString executed in Workspace produces the IP from my fw0 interface, which is useless. I need it to look at ppp0. Can it be told which interface to look at? How does it choose? Chris -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com<mailto:johnmci@smalltalkconsulting.com>> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

March 14, 2010

[Pharo-project] Use of #asMorph

by Igor Stasenko

Hello, lists i'd like to ask an intricate question. Suppose that your morph acts as a container, which needs to hold an items, retrieved from a model object. A model's elements could be any object, and may choose to represent them in a way they like it. So, for instance, if we taking a list, the list elements is represented by a morphs not simple strings. Now, a question: is it fine to use #asMorph as a message to 'convert' a model's item to a morph, which then can be used to reflect given item in list? I.e. something like: model itemsDo: [:item | self addMorph: item asMorph ] In this way, a list is built from morphs, and each list item choosing by itself, what morph should be used to represent itself in a list. But by saying A, we usually need to say B: an object could choose different representation depending on container's properties: model itemsDo: [:item | self addMorph: (item asMorphIn: self) ] So, for example, a compiled method, could choose to represent itself in a list as a simple string with own selector, while in text editor it could choose to display own source code. What you would do in such case? -- Best regards, Igor Stasenko AKA sig.

March 14, 2010

Re: [Pharo-project] [squeak-dev] NetNameResolver/ifconfig/interfaces

by Levente Uzonyi

On Sat, 13 Mar 2010, John M McIntosh wrote: > > On 2010-03-13, at 3:14 PM, Levente Uzonyi wrote: > >> On Sat, 13 Mar 2010, Alexander LazareviÄ wrote: >> >>> Isn't http://bugs.squeak.org/view.php?id=7392 just about this? >> >> It seems to be. There seem to be no way to get the list of interfaces or the interface of a local ip address. > > Yes, but that is not the question, the question is: To answer your question: #localHostAddress should always return 127.0.0.1 or ::1, that could be a preference or senders should expect a list of ip addresses. A method named localAddresses or similar could return local ip addresses. Levente > >>>> NetNameResolver localHostAddress > > > what does LOCAL HOST ADDRESS mean to you? > > for use in like > > sock2 connectTo: NetNameResolver localHostAddress port: 54321. > > or > > 'http://localhost:8080/seaside' asUrl retrieveContents. > > > Offering a "NetNameResolver networkInterfaceThings" has different meaning? > > >> 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 >

March 13, 2010

Re: [Pharo-project] [squeak-dev] NetNameResolver/ifconfig/interfaces

by John M McIntosh

On 2010-03-13, at 3:14 PM, Levente Uzonyi wrote: > On Sat, 13 Mar 2010, Alexander LazareviÄ wrote: > >> Isn't http://bugs.squeak.org/view.php?id=7392 just about this? > > It seems to be. There seem to be no way to get the list of interfaces or the interface of a local ip address. Yes, but that is not the question, the question is: >>> NetNameResolver localHostAddress what does LOCAL HOST ADDRESS mean to you? for use in like sock2 connectTo: NetNameResolver localHostAddress port: 54321. or 'http://localhost:8080/seaside' asUrl retrieveContents. Offering a "NetNameResolver networkInterfaceThings" has different meaning? > Levente -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

March 13, 2010

Re: [Pharo-project] Startup description of the problem

by Alexandre Bergel

Well caught! Alexandre On 13 Mar 2010, at 15:20, StÃ©phane Ducasse wrote: > Here is the reason why Clipboard was not well initialized and the > general problem with the startup list if we execute Smalltalk > initialize :) > > in the startup list not complete (and cannot really because other > classes may dynamically register themselves) > SmalltalkImage>>initializeStartUpList > "SmalltalkImage initializeStartUpList" > > | oldList | > oldList := StartUpList. > StartUpList := OrderedCollection new. > "These get processed from the top down..." > #( > Delay > DisplayScreen > Cursor > InputEventFetcher > ProcessorScheduler "Starts low space watcher and bkground." > LanguageEnvironment > FileDirectory "Enables file stack dump and opens sources." > NaturalLanguageTranslator > ShortIntegerArray > ShortRunArray > CrLfFileStream > ) do:[:clsName| > Smalltalk at: clsName ifPresent:[:cls| Smalltalk addToStartUpList: > cls]. > ]. > oldList ifNotNil: [oldList do: [:className | Smalltalk at: className > ifPresent: [:theClass | Smalltalk addToStartUpList: theClass]]]. > #( > PasteUpMorph > "ControlManager" > ) do:[:clsName| > Smalltalk at: clsName ifPresent:[:cls| Smalltalk addToStartUpList: > cls]. > ]. > > > Now if we check the classes that have a addToStartUpList: call and > that are not in the previous list. > We see that we missed a lot of them. > > classes := ((SystemNavigation default allCallsOn: #addToStartUpList:) > collect: [ :e | e methodClass ]), > ((SystemNavigation default allCallsOn: #addToStartUpList:after:) > collect: [ :e | e methodClass ]). > classNames := classes collect: [ :n | n instanceSide name ]. > (Smalltalk class classVarNamed: 'StartUpList') do: [ :s | > classNames remove: s ifAbsent: [] ]. > classNames asSortedCollection > > > a SortedCollection(#AutoStart #CPUWatcher #Clipboard #CommandHistory > #ExternalSettings #FreeTypeFontProvider #FreeTypeSettings > #HostSystemMenus #HostWindowProxy #InputEventSensor > #InternetConfiguration #Locale #MenuIcons #MultiByteFileStream > #OSPlatform #ProcessBrowser #SecurityManager #SmalltalkImage > #SmalltalkImage #SystemDictionary #SystemDictionary #UITheme > #UUIDGenerator #WeakArray). > > InputEventSensor has startup and shutdown but no initialize > > > > Stef > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 13, 2010

Re: [Pharo-project] [squeak-dev] NetNameResolver/ifconfig/interfaces

by Levente Uzonyi

On Sat, 13 Mar 2010, John M McIntosh wrote: > Ok, well I spent the evening looking into this. It's unclear if reverting the new/old socket stuff in Pharo is a good idea, > or if we just adjust things a bit in the name lookup that would solve things. There are two questions to resolve > > (1) Do we want to return an IPV4 address from the network lookup? or an IPV6 address? > (2) What do we do when we have 2 or more active IP interfaces on the machine, prompt for which one to use? Pick one at random, use the first or last one? What about creating a new primitive which would return a list with ip address - interface pairs. The list would contain all ip addresses so we can solve the problem in smalltalk. If we later find that the initial solution was wrong, we can change it without touching the vm code. Levente > > If the community can decide what to do, then we can propose a solution. > > So how it works. > > NetNameResolver localHostAddress > > fe80::21c:42ff:fe00:9%en5(otter-2.local),0(0) > > Gah... what's that? > > Well the interface is: > > en5: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 > inet6 fe80::21c:42ff:fe00:9%en5 prefixlen 64 scopeid 0x8 > inet 10.37.129.2 netmask 0xffffff00 broadcast 10.37.129.255 > ether 00:1c:42:00:00:09 > media: autoselect status: active > supported media: autoselect > > Thus it's giving me an IPV6 address. > > The chore is more complicated that one would care to see. I see Microsoft had a hand in defining the spec. > > So it first asks the gethostname for the name of the host. As an example my macbook pro has > Otter-2.local > > which is what > [otter-2:~] johnmci% hostname > Otter-2.local > > That's a bonjour assigned name since if I do > [otter-2:~] johnmci% nslookup Otter-2.local > Server: 192.168.1.7 > Address: 192.168.1.7#53 > > ** server can't find Otter-2.local: NXDOMAIN > > > Then we are off to: > > getnameinfo > > which returns a chain of IPV4 and IPV6 address that Otter-2.local would resolve to. > In this case there are six address, broken in to IPV6 and IPV4 > > fe80::21c:42ff:fe00:8%en4(otter-2.local),0(0)-inet6-stream-tcp > fe80::21c:42ff:fe00:9%en5(otter-2.local),0(0)-inet6-stream-tcp > fe80::21b:63ff:fe02:d2db%en1(otter-2.local),0(0)-inet6-stream-tcp > 10.211.55.2(10.211.55.2),0(0)-inet4-stream-tcp > 10.37.129.2(10.37.129.2),0(0)-inet4-stream-tcp > 192.168.1.141(192.168.1.141),0(0)-inet4-stream-tcp > > So looks kinda random, but it's not. It's defined by Microsoft & committee etc. in > http://www.faqs.org/rfcs/rfc3484.html > > The objective is to sort the list into some order. I must say you can't actually tell from reading the docs, and things over > the past decade have changed. So I refer to some cheat sheets that *might* be correct. > > Now the macbook pro in this case uses 192.168.1.141 as the assigned tcp/ip address from our internal DHCP server. > The 10.211.55.2 is a parallels shared network adaptor and > 10.37.129.2 is the parallels host-only network adaptor. > > All three interfaces show as active, and if you consider the 'ifconfig -a' below you would be hard pressed to determine which interface is the one facing the > company intranet. > > > [otter-2:~] johnmci% ifconfig -a > lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 > inet 127.0.0.1 netmask 0xff000000 > gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 > stf0: flags=0<> mtu 1280 > en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 > ether 00:17:f2:d9:57:35 > media: autoselect status: inactive > supported media: autoselect 10baseT/UTP <half-duplex> 10baseT/UTP <full-duplex> 10baseT/UTP <full-duplex,hw-loopback> 10baseT/UTP <full-duplex,flow-control> 100baseTX <half-duplex> 100baseTX <full-duplex> 100baseTX <full-duplex,hw-loopback> 100baseTX <full-duplex,flow-control> 1000baseT <full-duplex> 1000baseT <full-duplex,hw-loopback> 1000baseT <full-duplex,flow-control> none > fw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 2030 > lladdr 00:19:e3:ff:fe:93:92:7c > media: autoselect <full-duplex> status: inactive > supported media: autoselect <full-duplex> > en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 > inet6 fe80::21b:63ff:fe02:d2db%en1 prefixlen 64 scopeid 0x6 > inet 192.168.1.141 netmask 0xffffff00 broadcast 192.168.1.255 > ether 00:1b:63:02:d2:db > media: autoselect status: active > supported media: autoselect > en4: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 > inet6 fe80::21c:42ff:fe00:8%en4 prefixlen 64 scopeid 0x7 > inet 10.211.55.2 netmask 0xffffff00 broadcast 10.211.55.255 > ether 00:1c:42:00:00:08 > media: autoselect status: active > supported media: autoselect > en5: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 > inet6 fe80::21c:42ff:fe00:9%en5 prefixlen 64 scopeid 0x8 > inet 10.37.129.2 netmask 0xffffff00 broadcast 10.37.129.255 > ether 00:1c:42:00:00:09 > media: autoselect status: active > supported media: autoselect > > > Where en0 is ethernet jack, fw0 is firewire, en1 is wireless, en4 & en5 are virtual. > > Now the bias from the committee is > > precedence ::1/128 50 > precedence ::/0 40 > precedence 2002::/16 30 > precedence ::/96 20 > precedence ::ffff:0:0/96 10 > scopev4 ::ffff:169.254.0.0/112 2 > scopev4 ::ffff:127.0.0.0/104 2 > scopev4 ::ffff:10.0.0.0/104 5 > scopev4 ::ffff:172.16.0.0/108 5 > scopev4 ::ffff:192.168.0.0/112 5 > scopev4 ::ffff:0.0.0.0/96 14 > > This means of course the 10.0.0.0 address sorts before the 192.168.0.0 address. How helpful. > > So how do we know *which* is the proper address to use? Well no idea! > > However let's see what the API does. > > NetNameResolver class>> addressesForName: hostName > | adresses | > adresses := SocketAddressInformation > forHost: hostName > service: '' > flags: 0 > addressFamily: 0 > socketType: SocketAddressInformation socketTypeStream > protocol: SocketAddressInformation protocolTCP. > ^adresses > > > Now I can make it return just IPV4 address by doing: > > NetNameResolver class>> addressesForName: hostName > | adresses | > adresses := SocketAddressInformation > forHost: hostName > service: '' > flags: 0 > addressFamily: SocketAddressInformation addressFamilyINET4 > socketType: SocketAddressInformation socketTypeStream > protocol: SocketAddressInformation protocolTCP. > ^adresses > > which then NetNameResolver localHostAddress gives: > 10.37.129.2(10.37.129.2),0(0) > > I can also supply a service number string say SSH '22' > that give back > 10.37.129.2(10.37.129.2),22(ssh) > since ssh is binding on all interfaces that's valid. > > Technically the getnameinfo gives back three address but again the code below grabs the first one which according to the rfc3484 is more likely to be the correct answer. > > addressForName: hostName > "NetNameResolver addressForName: 'impara.de' " > "NetNameResolver addressForName: 'localhost' " > "NetNameResolver addressForName: '127.0.0.1' " > | addresses | > self useOldNetwork > ifTrue: [^self oldAddressForName: hostName]. > addresses := self addressesForName: hostName. > ^addresses > ifEmpty: [nil] > ifNotEmpty: [addresses first socketAddress] > > But grabbing the first one doesn't meet people's expectations of correctness, however we just don't have enough information to decide *what* is correct. > > Now some people say OH let's return the en0 one because that is correct? Really how do you know? > On my computer en0 is ethernet, but since I'm using wireless then en1 is the correct one. > > Obviously I could look in the list of IPV6 address find the LOWEST en# value, then grab the IPV4 entry. This would assume I check for the fact that the IPV6 > interface has an IPV4 address and the sort order for the IPV6 is the same as for the IPV4. > > Gee that sounds ok? > > Well it's not, when for example I tether my MacBook Pro to my iPhone and abuse my privilege to move data over the cellular carrier, ah sorry you USA ATT folks, > then the interface is: > > en6: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 > inet6 fe80::226:8ff:fe72:5aa%en6 prefixlen 64 scopeid 0x9 > inet 192.168.20.2 netmask 0xffffff00 broadcast 192.168.20.255 > ether 00:26:08:72:05:aa > media: 10baseT/UTP status: active > supported media: 10baseT/UTP > > > which fails the test that the lowest active en# is the one we want to use. > > 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.20.2(192.168.20.2),0(0)-inet4-stream-tcp) > > > So the question is what would the community like to see happen. Well other than hide under a rock and see if the problem goes away... > > > On 2010-03-12, at 8:41 AM, Chris Cunnington wrote: > >> How is NetNameResolver choosing the interface to return an IP address from? >> >> In Cobalt this is a problem. You need the right address to connect to other spaces. Cobalt won't let you enter it by hand, so you are at the mercy of its guessing the correct interface. >> >> NetNameResolver localAddressString >> >> executed in Workspace produces the IP from my fw0 interface, which is useless. I need it to look at ppp0. >> >> Can it be told which interface to look at? >> How does it choose? >> >> Chris >> > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > >

March 13, 2010

Re: [Pharo-project] Polymorph

by Gary Chambers

It inevitable that there will be more necessary overrides... not even close to getting Morphic totally hooked for all that will be needed... Regards, Gary On Sat, 2010-03-13 at 23:29 +0200, Igor Stasenko wrote: > I'd recommend to incorporate all Polymorph's overrides into Morphic. > Then you can still maintain Polymorph as separate package, > but don't fool yourself with a tons of overrides. > > On 13 March 2010 19:15, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > > On Mar 13, 2010, at 5:56 PM, Gary Chambers wrote: > > > >> All "fun" on squeak-dev... > >> > >> Getting close to abandoning support for Polymorph in Squeak at all now... > >> Only a few apps based on 3.9 left here. Not sure they need any of the ongoing improvements. > > > > I'm not sure that maintaining two version is an option for you. > > > >> So, the question is, how would we want future additions/changes/fixes to apply in Pharo. > > > > The way you were doing them is ok. > > You could also publish directly in Pharo > > But if you want to have you own package and control over it this is ok too. > > > >> Having Polymorph as an external (mergable, not loadable) package has worked well for us, as much as it can be well. > >> > >> Perhaps changesets are the way to go from here... opinions/advice welcome... > > > > Why MC is not good for you? > > > >> > >> Regards, Gary > >> _______________________________________________ > >> 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 > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 13, 2010