February 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] UDP Listener example?

by Norbert Hartl

Am 06.02.2012 um 23:13 schrieb Eagle Offshore: > Thanks, I found this but it pretty well ignores UDP other than mentioning it exists. > I think you might confuse the host and port portions of it. If you use socket receiveDataInto:fromHost:port: then the host and the port are the ones of the sending side. You need to specify your own side as well | localPort sourceAddress sourcePort buffer receivedBytes socket delay | localPort := 5000. sourceAddress := NetNameResolver addressFromString: '255.255.255.255'. sourcePort := 4848. buffer := ByteArray new: 1000. delay := Delay forMilliseconds: 50. socket := Socket newUDP setPort: localPort. [[ receivedBytes := socket receiveDataInto: buffer fromHost: sourceAddress port: sourcePort. receivedBytes isZero ] whileTrue: [ delay wait ]] ensure: [ socket closeAndDestroy]. Or you are better off testing it by using #receiveDataInto: instead of #receiveDataInto:fromHost:port: Norbert > > On Feb 6, 2012, at 1:38 PM, jannik.laval wrote: > >> Hi Todd, >> >> The socket chapter in writing progress could help you: https://gforge.inria.fr/scm/viewvc.php/*checkout*/PharoByExampleTwo-Eng/Soc… >> I do not remember if the receiveData method is blocking. If not, you should wait til data arrives. >> >> Cheers, >> Jannik >> >> On Feb 6, 2012, at 22:22 , Eagle Offshore wrote: >> >>> I'm trying to build a display for some instruments that multicast readings using UDP. I started out using CocoaAsyncSocket on Mac (https://github.com/robbiehanson/CocoaAsyncSocket) and I have to say it has a really wonderful api - would be worth cloning it. >>> >>> However, want to do the same thing in Pharo so I have typed this little snippet into the workspace: >>> >>> [| socket | >>> socket := Socket newUDP. >>> 10 timesRepeat: [| s | >>> s := String new. >>> socket receiveDataInto: s fromHost: (NetNameResolver addressFromString:'255.255.255.255' ) port: 4848. >>> Transcript show: s.]] fork >>> >>> and it doesn't seem to do anything. >>> >>> What have I missed? Pharo 1.3 stable on SnowLeopard BTW. >>> >>> Thanks, >>> -Todd Blanchard >>> >> >> --- >> Jannik Laval >> >> > >

Feb. 6, 2012

Re: [Pharo-project] UDP Listener example?

by Eagle Offshore

Thanks, I found this but it pretty well ignores UDP other than mentioning it exists. On Feb 6, 2012, at 1:38 PM, jannik.laval wrote: > Hi Todd, > > The socket chapter in writing progress could help you: https://gforge.inria.fr/scm/viewvc.php/*checkout*/PharoByExampleTwo-Eng/Soc… > I do not remember if the receiveData method is blocking. If not, you should wait til data arrives. > > Cheers, > Jannik > > On Feb 6, 2012, at 22:22 , Eagle Offshore wrote: > >> I'm trying to build a display for some instruments that multicast readings using UDP. I started out using CocoaAsyncSocket on Mac (https://github.com/robbiehanson/CocoaAsyncSocket) and I have to say it has a really wonderful api - would be worth cloning it. >> >> However, want to do the same thing in Pharo so I have typed this little snippet into the workspace: >> >> [| socket | >> socket := Socket newUDP. >> 10 timesRepeat: [| s | >> s := String new. >> socket receiveDataInto: s fromHost: (NetNameResolver addressFromString:'255.255.255.255' ) port: 4848. >> Transcript show: s.]] fork >> >> and it doesn't seem to do anything. >> >> What have I missed? Pharo 1.3 stable on SnowLeopard BTW. >> >> Thanks, >> -Todd Blanchard >> > > --- > Jannik Laval > >

Feb. 6, 2012

Re: [Pharo-project] UDP Listener example?

by Sven Van Caekenberghe

Todd, On 06 Feb 2012, at 22:22, Eagle Offshore wrote: > [| socket | > socket := Socket newUDP. > 10 timesRepeat: [| s | > s := String new. > socket receiveDataInto: s fromHost: (NetNameResolver addressFromString:'255.255.255.255' ) port: 4848. > Transcript show: s.]] fork > > and it doesn't seem to do anything. > > What have I missed? It is a non-blocking API, so you have to write some code to keep on listening until some timeout, in a loop with small delays, like 50ms. Also, you have to preallocate a non-empty buffer. I have some working code for this, but it is not clean/standalone enough to show here ;-) If you can't figure it out yourself, just ask and I will mail some of it to you off list. Regards, Sven

Feb. 6, 2012

Re: [Pharo-project] UDP Listener example?

by jannik.laval

Hi Todd, The socket chapter in writing progress could help you: https://gforge.inria.fr/scm/viewvc.php/*checkout*/PharoByExampleTwo-Eng/Soc… I do not remember if the receiveData method is blocking. If not, you should wait til data arrives. Cheers, Jannik On Feb 6, 2012, at 22:22 , Eagle Offshore wrote: > I'm trying to build a display for some instruments that multicast readings using UDP. I started out using CocoaAsyncSocket on Mac (https://github.com/robbiehanson/CocoaAsyncSocket) and I have to say it has a really wonderful api - would be worth cloning it. > > However, want to do the same thing in Pharo so I have typed this little snippet into the workspace: > > [| socket | > socket := Socket newUDP. > 10 timesRepeat: [| s | > s := String new. > socket receiveDataInto: s fromHost: (NetNameResolver addressFromString:'255.255.255.255' ) port: 4848. > Transcript show: s.]] fork > > and it doesn't seem to do anything. > > What have I missed? Pharo 1.3 stable on SnowLeopard BTW. > > Thanks, > -Todd Blanchard > --- Jannik Laval

Feb. 6, 2012

Re: [Pharo-project] Snapshot question

by Mariano Martinez Peck

On Sun, Feb 5, 2012 at 6:49 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > I am getting some stalled installations, and hope to be able to snapshot > my building image after each successful step (not going so well). > > With the 1.3 one-click, I can't break (control or alt . ???) something > that's gone bad - is there a secret to getting that back? > > you are missing the '-', aren't you? it is cmd/ctrl . - > Re snapshotting the image, I tried #saveSession, but that seems to > capturing a bit too much; if it was doing something stupid, it re-opens > trying (unsuccessfully as before) to do the same thing, and I can't break > out > > Is there a better way to save incremental progress? > > Bill > > > > > -- Mariano http://marianopeck.wordpress.com

Feb. 6, 2012

Re: [Pharo-project] better Behavior>>methodDict

by Mariano Martinez Peck

On Mon, Feb 6, 2012 at 10:17 PM, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr > wrote: > Hi mariano > > I have the impression that methodDict should be redefined as you propose > it because else it does not work well with the cannotInterpret hook. I > suggest to redefine methodDict as follow. notice the cool comment!!! > If this is ok -> open a bug entry. > > > Behavior >> methodDict > "The method dictionary of a class can be nil when we want to use > the cannotInterpret: hook. Indeed when a class dictionary is nil, the VM > sends the message cannotInterpret: to the receiver but starting the look up > in the superclass. Now the system relies that when the message methodDict > is sent to a class a method dictionary is returned. The implementation > below makes sure that a method dictionary can be nilled but does not > confuse the system." > > methodDict == nil ifTrue: [^ MethodDictionary new ]. > ^ methodDict > > For me that's perfect and avoids an override in my code :) Maybe we can do: Behavior >> methodDict "The method dictionary of a class can be nil when we want to use the cannotInterpret: hook. Indeed when a class dictionary is nil, the VM sends the message cannotInterpret: to the receiver but starting the look up in the superclass. Now the system relies that when the message methodDict is sent to a class a method dictionary is returned. The implementation below makes sure that a method dictionary can be nilled but does not confuse the system." methodDict == nil ifTrue: [^ self manageMDFault ]. ^ methodDict Behavior >> manageMDFault ^ MethodDictionary new That way subclasses can change it without needing an override. but both solutions are fine with me. Other opinions? -- Mariano http://marianopeck.wordpress.com

Feb. 6, 2012

[Pharo-project] UDP Listener example?

by Eagle Offshore

I'm trying to build a display for some instruments that multicast readings using UDP. I started out using CocoaAsyncSocket on Mac (https://github.com/robbiehanson/CocoaAsyncSocket) and I have to say it has a really wonderful api - would be worth cloning it. However, want to do the same thing in Pharo so I have typed this little snippet into the workspace: [| socket | socket := Socket newUDP. 10 timesRepeat: [| s | s := String new. socket receiveDataInto: s fromHost: (NetNameResolver addressFromString:'255.255.255.255' ) port: 4848. Transcript show: s.]] fork and it doesn't seem to do anything. What have I missed? Pharo 1.3 stable on SnowLeopard BTW. Thanks, -Todd Blanchard

Feb. 6, 2012

[Pharo-project] better Behavior>>methodDict

by StÃ©phane Ducasse

Hi mariano I have the impression that methodDict should be redefined as you propose it because else it does not work well with the cannotInterpret hook. I suggest to redefine methodDict as follow. notice the cool comment!!! If this is ok -> open a bug entry. Behavior >> methodDict "The method dictionary of a class can be nil when we want to use the cannotInterpret: hook. Indeed when a class dictionary is nil, the VM sends the message cannotInterpret: to the receiver but starting the look up in the superclass. Now the system relies that when the message methodDict is sent to a class a method dictionary is returned. The implementation below makes sure that a method dictionary can be nilled but does not confuse the system." methodDict == nil ifTrue: [^ MethodDictionary new ]. ^ methodDict Stef

Feb. 6, 2012

[Pharo-project] NBOpenGL error every third execution of example

by Lawson English

When I do the following with the latest version of NBOpenGL, I get an error: FrameBuffer status: unk error on the third (4th?) evaluation of GLTTRenderingDemo new openInWorld. This happens whether or not another OpenGL example is open. The pattern repeats: 2-3 evaluations work and then the 3rd or 4th has an error. I have seen this error before but didn't realize how easy it was to replicate. Lawson

Feb. 6, 2012

[Pharo-project] [update 1.4] #14317

by Marcus Denker

14317 ----- Issue 5248: Undeclared refs in 14315 http://code.google.com/p/pharo/issues/detail?id=5248 Issue 5167: Fix weak finalization thrashing - another fix http://code.google.com/p/pharo/issues/detail?id=5167 -- Marcus Denker -- http://marcusdenker.de

Feb. 6, 2012