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

Re: [Pharo-project] Socket accepts ipv6 addresses, but can not connect to them

by Schwab,Wilhelm K

FWIW, I am fairly certain the IPv6 changes are incomplete at best. Others have reported needing to override #useOldNetwork to always answer true, and I have noted things that are called "in the clear" when they should be hidden behind an old net test. So far, I have done what amounts to some glorified loopback tests and have watched MC download packages from IPv4 addresses. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Bart Gauquie Sent: Monday, November 16, 2009 4:26 PM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Socket accepts ipv6 addresses, but can not connect to them Dear all, I'm using Pharo1.0rc1 Latest update: #10493, on Windows Vista , runtime 3.11.4. Following test is going fine: SocketTest>>testConnectToLocalhostThroughNetNameResolverAddressForNameLocalhost |serverSocket clientSocket address| serverSocket := Socket newTCP. clientSocket := Socket newTCP. [ serverSocket listenOn: 6665. address := NetNameResolver addressForName: '127.0.0.1' timeout: 20. clientSocket connectTo: address port: 6665] ensure: [ clientSocket close. serverSocket close. ] (connect to a socket on localhost) however, following test: testConnectToLocalhostThroughNetNameResolverLocalHostAddress |serverSocket clientSocket address| serverSocket := Socket newTCP. clientSocket := Socket newTCP. [ serverSocket listenOn: 6665. address := NetNameResolver localHostAddress. clientSocket connectTo: address port: 6665] ensure: [ clientSocket close. serverSocket close. ] is failing with following error: ConnectionTimedOut: Cannot connect to: fe80::6dd3:7860:93c9:46a0%10(PC_xxx),6665(6665) [] in Socket>>connectTo:waitForConnectionFor: Socket>>waitForConnectionFor:ifTimedOut: Socket>>connectTo:waitForConnectionFor: Socket>>connectTo: Socket>>connectTo:port: [] in SocketTest>>testConnectToLocalhostThroughNetNameResolverLocalHostAddress BlockClosure>>ensure: SocketTest>>testConnectToLocalhostThroughNetNameResolverLocalHostAddress SocketTest(TestCase)>>performTest [] in [] in SocketTest(TestCase)>>runCase BlockClosure>>ensure: I understand that the above address is an ipv6 address. (the NetNameResolver localHostAddress lookup returns on my machine a ipv6 address) If i do ipconfig on my machine: Ethernet-adapter LAN-verbinding: Verbindingsspec. DNS-achtervoegsel: lan Link-local IPv6-adres . . . . . . : fe80::6dd3:7860:93c9:46a0%10 IPv4-adres. . . . . . . . . . . . : 10.0.0.39 Subnetmasker. . . . . . . . . . . : 255.255.255.0 Standaardgateway. . . . . . . . . : 10.0.0.138 its the same ipv6 address. Is it normal that the Socket class can not handle ipv6 addresses ? I get a timeoutexception on it (however this happens immediately). Is this the behaviour that i can expect ? The reason i noticed this is that I'm trying Magma, the server in a separate image but on the same machine, under ubuntu 9.10 everything worked fine, under Windows Vista it crashed, since internally it also uses NetNameResolver localHostAddress to connect to 'localhost', and i got the same connect timeout exception. In attachment, a fileout of the SocketTest (had to create a new testclass for this :-( ) Kind regards, Bart -- imagination is more important than knowledge - Albert Einstein Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein The true sign of intelligence is not knowledge but imagination. - Albert Einstein Gravitation is not responsible for people falling in love. - Albert Einstein

Nov. 16, 2009

[Pharo-project] Socket accepts ipv6 addresses, but can not connect to them

by Bart Gauquie

Dear all, I'm using Pharo1.0rc1 Latest update: #10493, on Windows Vista , runtime 3.11.4. Following test is going fine: SocketTest>>testConnectToLocalhostThroughNetNameResolverAddressForNameLocalhost |serverSocket clientSocket address| serverSocket := Socket newTCP. clientSocket := Socket newTCP. [ serverSocket listenOn: 6665. address := NetNameResolver addressForName: '127.0.0.1' timeout: 20. clientSocket connectTo: address port: 6665] ensure: [ clientSocket close. serverSocket close. ] (connect to a socket on localhost) however, following test: testConnectToLocalhostThroughNetNameResolverLocalHostAddress |serverSocket clientSocket address| serverSocket := Socket newTCP. clientSocket := Socket newTCP. [ serverSocket listenOn: 6665. address := NetNameResolver localHostAddress. clientSocket connectTo: address port: 6665] ensure: [ clientSocket close. serverSocket close. ] is failing with following error: ConnectionTimedOut: Cannot connect to: fe80::6dd3:7860:93c9:46a0%10(PC_xxx),6665(6665) [] in Socket>>connectTo:waitForConnectionFor: Socket>>waitForConnectionFor:ifTimedOut: Socket>>connectTo:waitForConnectionFor: Socket>>connectTo: Socket>>connectTo:port: [] in SocketTest>>testConnectToLocalhostThroughNetNameResolverLocalHostAddress BlockClosure>>ensure: SocketTest>>testConnectToLocalhostThroughNetNameResolverLocalHostAddress SocketTest(TestCase)>>performTest [] in [] in SocketTest(TestCase)>>runCase BlockClosure>>ensure: I understand that the above address is an ipv6 address. (the NetNameResolver localHostAddress lookup returns on my machine a ipv6 address) If i do ipconfig on my machine: Ethernet-adapter LAN-verbinding: Verbindingsspec. DNS-achtervoegsel: lan Link-local IPv6-adres . . . . . . : fe80::6dd3:7860:93c9:46a0%10 IPv4-adres. . . . . . . . . . . . : 10.0.0.39 Subnetmasker. . . . . . . . . . . : 255.255.255.0 Standaardgateway. . . . . . . . . : 10.0.0.138 its the same ipv6 address. Is it normal that the Socket class can not handle ipv6 addresses ? I get a timeoutexception on it (however this happens immediately). Is this the behaviour that i can expect ? The reason i noticed this is that I'm trying Magma, the server in a separate image but on the same machine, under ubuntu 9.10 everything worked fine, under Windows Vista it crashed, since internally it also uses NetNameResolver localHostAddress to connect to 'localhost', and i got the same connect timeout exception. In attachment, a fileout of the SocketTest (had to create a new testclass for this :-( ) Kind regards, Bart -- imagination is more important than knowledge - Albert Einstein Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein The true sign of intelligence is not knowledge but imagination. - Albert Einstein Gravitation is not responsible for people falling in love. - Albert Einstein

Nov. 16, 2009

[Pharo-project] ImageReadWriter class>>formFromStream:

by Schwab,Wilhelm K

Hello all, I have a crude example of something I want to do with gnuplot, and started looking at reading images from binary streams. Looking at ImageReadWriter class>>formFromStream:, I see things I do not like, but I am not sure how to fix them. First, on a failure to find a matching reader, it sends #close to the stream. I don't think that is its job, or if nothing else, there should be a #formFromStream:onError: block that would allow overrides of that behavior. Second, it uses #reset to go back up to allow the selected reader to have a fresh start after it assumes responsibility for reading the format. #position: would be a better choice, to return to the position at the start of the method (not necessarily the beginning of the stream). If a positionable stream is too much to ask, then the code should be changed to allow the read to pick up where the format test left off. Another option would be to use something that I built in Dolphin a while back: it puts a wrapper around a stream to absorb a #reset (I had the same problem) and then delegates to the "real" stream from the point it left off. In my current situation, I should be able to get away with hard-coding the reader class. Bill

Nov. 16, 2009

Re: [Pharo-project] Spreading the word about Pharo

by Oscar Nierstrasz

LOL! That web 1.0 page has not been modified since Oct 1999. - on On Nov 12, 2009, at 19:31, StÃ©phane Ducasse wrote: > yes > > On Nov 12, 2009, at 7:27 PM, csrabak(a)bol.com.br wrote: > >> Do you think it is time to ask maintainers of pages about Smalltalk, like http://www.engin.umd.umich.edu/CIS/course.des/cis400/smalltalk/smalltalk.ht… to include Pharo be it as an entry or at least a link? >> >> -- >> Cesar Rabak >> >> _______________________________________________ >> 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

Nov. 16, 2009

Re: [Pharo-project] MailMessage

by Marco Schmidt

My code is as follows: ==== BuildAndSendMail>>deliverMailFrom: fromAddress to: recipientList text: messageText SeasidePlatformSupport deliverMailFrom: fromAddress to: recipientList text: messageText BuildAndSendMail>>send: model | recipients messageText subjectText bodyText headerText | recipients := self recipents: model. headerText := 'Content-Type: text/plain; charset=\"utf-8\"', String crlf, 'Content-Transfer-Encoding: 8bit'. bodyText := (self messageTextForModel: model) convertToWithConverter: UTF8TextConverter new. subjectText := 'Subject: ' , 'Ihre Kartenreservierung (' , Date current asString , ')'. messageText := headerText, String crlf, subjectText , String crlf , bodyText. self deliverMailFrom: '<xxx(a)xxxx.xxx>' to: recipients text: messageText ==== For me the trick was "convertToWithConverter: UTF8TextConverter new." After adding this conversion my postfix server accepted the generated mails. My defect happens only connecting from a unix host. Connecting to the mail server from a windows host works fine. Marco Schmidt 2009/11/14 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Marco, > > Does that imply that you have had success otherwise? Â How did you send the mail? Â I _think_ it ultimately goes through SMTPClient, but it's a real rats' nest and I could be missing something. Â Also, how did you create the message? Â Most of the examples seem to have the headers created "in the text" as opposed to generating them from supplied aspects :( > > Interestingly, I am having trouble sending a plain-text message from Pharo. Â I _have_ had success sending an attachment. I have not bothered to see if I can read the result, but the server delivered it, and LookOut!! seems to think there is something attached to the message. > > The weird thing is that my attemps to send plain text resulted in (superficially at least) a reasonable conversation with the server (I added enough tracing to see the sends and the server's responses). Â The server reports accepting the message for delivery, but it never arrrives. Â I am **reasonbly** certain my email address is correct, but obviously that is something that needs to be re-re-re-checked. > > Something in Mantis made reference to <> around email addresses; I think it was only in the case of multiple recipients, but it is worth a look. Â The server reports itself as sendmail, but it would not surprise me if it another piece of Microsoft crap-ware that claims to be something it is not. > > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Schmidt, Marco > Sent: Friday, November 13, 2009 3:42 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] MailMessage > > I had a problem with Email and the character encoding. Sending mail with the character 'ÃÃÃ' inside the mail body killed the mail server. So - look at correct encoding of the message text. > > Marco Schmidt > > > > > -----UrsprÃ¼ngliche Nachricht----- > Von: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] Im Auftrag von Schwab,Wilhelm K > Gesendet: Freitag, 13. November 2009 01:29 > An: Pharo-project(a)lists.gforge.inria.fr > Betreff: [Pharo-project] MailMessage > > Hello all, > > I am looking for a way to format text in email. Â Html comes to mind (yes, I hate those emails too, but it would work and the recipients don't know any better<g>), as does attaching a file with the data. > > I recently had to switch smtp servers, and for whatever reason, can no longer send html email. Â The server says it accepted it, but the mail is never delivered; send plain text through it, and it works. > > It could simply be that the server wants no part of html email, but it would be nice to repeat the test with another client, and/or try attachments as a solution to my problem. Â I found MailMessage, and could not figure out how to set the recipient. > > After some searching, I found 151 on Mantis; it is a five year old fix from Frank Shearer for adding recipients. Â If I had to guess, things are still broken, but I will try it and see what happens. Â Sending this now while I'm thinking about it. > > If anybody knows a way around my current problems, please don't feel that you would be cheating me out of the fun of solving it myself :) > > Bill > > > > _______________________________________________ > 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 > >

Nov. 16, 2009

[Pharo-project] Soek - browse seaside/smalltalk docu

by Torsten Bergmann

A nice way to browse Seaside documentation: http://soek.goodies.st.s3.amazonaws.com/Seaside/3.0a3/index.html Maybe Lukas can add a link on seaside.st Read more here: http://philemonworks.wordpress.com/2009/11/13/soek-goodies-st-exploring-ope… Bye Torsten -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Nov. 16, 2009

Re: [Pharo-project] rb broken in dev 10495

by StÃ©phane Ducasse

On Nov 16, 2009, at 3:10 PM, Lukas Renggli wrote: >> may be we should avoid ## > > In Dolphin Smalltalk ## it is used as a prefix for compile time expressions. > > Putting spaces (or even comments) between the #-character and the > symbol/array/bytearray is accepted in some other Smalltalk dialects > too, but I still think it is bad style. yes I think that we should keep ## if one day we need something special. >> because I think that this is not smalltalk (did not check the standard) >> and I do not see an usage for now. > > The Smalltalk standard has a very restrictive syntax. The Pharo > compiler is very permissive. For example it allows an arbitrary number > of statement separators, something that no other Smalltalk allows. you mean . . . I would really make it less permissive because these are variations with no value. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 16, 2009

Re: [Pharo-project] rb broken in dev 10495

by Lukas Renggli

> Indeed, this was actually a mistake in the code. But either the parser > does not allow me to enter it, or the tools should not break. Yeah, it caused a bug in the parser, but that is fixed now. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 16, 2009

Re: [Pharo-project] rb broken in dev 10495

by Lukas Renggli

> may be we should avoid ## In Dolphin Smalltalk ## it is used as a prefix for compile time expressions. Putting spaces (or even comments) between the #-character and the symbol/array/bytearray is accepted in some other Smalltalk dialects too, but I still think it is bad style. > because I think that this is not smalltalk (did not check the standard). > and I do not see an usage for now. The Smalltalk standard has a very restrictive syntax. The Pharo compiler is very permissive. For example it allows an arbitrary number of statement separators, something that no other Smalltalk allows. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 16, 2009

Re: [Pharo-project] rb broken in dev 10495

by Tudor Girba

Hi, Indeed, this was actually a mistake in the code. But either the parser does not allow me to enter it, or the tools should not break. Cheers, Doru On 16 Nov 2009, at 13:57, StÃ©phane Ducasse wrote: > may be we should avoid ## > because I think that this is not smalltalk (did not check the > standard). > and I do not see an usage for now. > > Stef > > On Nov 16, 2009, at 1:34 PM, Lukas Renggli wrote: > >>> browser sendTo: ##navigation->#namespaceToSelect fromOutside: >>> #namespaceToSelect. >>> browser sendTo: ##navigation->#classToSelect fromOutside: >>> #classToSelect. >>> browser sendTo: ##navigation->#methodToSelect fromOutside: >>> #methodToSelect. >> >> ##navigation is not really valid Smalltalk. I don't know why the >> Pharo >> Compiler accepts that. I can change the refactoring browser to also >> accept that, but it looks strange to me. >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.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 -- www.tudorgirba.com "Not knowing how to do something is not an argument for how it cannot be done."

Nov. 16, 2009