- Pharo-dev - lists.pharo.org

[Pharo-project] [ANN] Pomodoro for Pharo 2.0

by Torsten Bergmann

MartinW wrote: >- When you drag and drop a finished (red) Pomodoro Morph the whenFinishedDo: >block is executed every time on dropping the morph. Ahh ... I see. I fixed that. >- The clock starts with 4 seconds and displays the 'Pomodoro finished' >notification 1 second after the progress bar and the clock show zero. Reason is that the stopwatch is more precise (nanoseconds) and the pomodoro is only down to "seconds precision" Usually you have a pomodoro in minute precision (25 minutes), such short pomodoros of 5 seconds make no sense and the example with 5 seconds was only to demonstrate the features without waiting too long for the demo result. But I fixed this as well so it is clean. Just load the new one from the config browser (available in 2.0 and 3.0). Bye T.

March 27, 2013

Re: [Pharo-project] Fwd: Some question and request for Athens

by Tristan Bourgois

2013/3/26 Igor Stasenko <siguctua(a)gmail.com>: > On 26 March 2013 11:29, Tristan Bourgois <tristan.bourgois(a)gmail.com> wrote: >> 2013/3/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> >>> >>> Begin forwarded message: >>> >>> From: Igor Stasenko <siguctua(a)gmail.com> >>> Subject: Re: Some question and request for Athens >>> Date: March 25, 2013 2:57:33 PM GMT+01:00 >>> To: Tristan Bourgois <tristan.bourgois(a)gmail.com> >>> Cc: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>, LE PORS Eric >>> <eric.lepors(a)fr.thalesgroup.com> >>> >>> On 25 March 2013 11:45, Tristan Bourgois <tristan.bourgois(a)gmail.com> wrote: >>> >>> Hi Igor! >>> >>> I have some questions and request for Athens :) >>> >>> 1 Do exist a possibility in Athens to draw a Surface on a Surface? >>> For example : >>> aSurf drawSurface: anOtherSurface at: aPosition >>> (I need it for draw image on a surface) >>> >>> >>> yes. You can use Forms or surfaces as paints so they act like 2D textures: >>> >>> canvas setPaint: someSurface. >>> canvas drawShape: myRect. >> >> Thanks that's works fine :) >> >>> >>> 2 About my first question, I try to draw a png image on a Surface and >>> I get some strange behavior. When nothing is applied on my first >>> surface and draw the image in a rectangle path I crash the VM! >>> This an example I tried and crash my VM: >>> >>> |surf pharoLogo ref path patternPaint| >>> surf := AthensCairoSurface extent: 600@600. >>> >>> ref := 'pharo.png' asFileReference. >>> pharoLogo := AthensCairoSurface createFromFile: ref fullName ifFailed:[nil]. >>> >>> surf drawDuring: [:can| >>> surf clear. >>> patternPaint := can setPaint: pharoLogo. >>> patternPaint setExtend: #None. >>> can drawShape: (0@0 extent: pharoLogo extent). >>> ]. >>> Display getCanvas drawImage: surf asForm at: 0@0. Did this code work fine on your image or other machine? (I'm working on a Windows XP pro) >>> If you need more information about the crash and my environment ask it :) >>> >>> weird... it should be working fine. >> >> I try it on a new clean image and again get a VM crash. > > okay, then i need more information :) I send the report of the crash in the mail. Tristan > -- > Best regards, > Igor Stasenko. >

March 27, 2013

Re: [Pharo-project] More GSoC ideas wanted, 3 days left ....

by Yuriy Tymchuk

You are welcome, and thank you. One more question: why SciSmalltalk isn't present among the ideas? Yuiry On 27 Ð±ÐµÑ. 2013, at 13:56, Janko MivÅ¡ek <janko.mivsek(a)eranova.si> wrote: > Yuriy, thanks for your explanation, I now understand the intent of your > idea better. Good luck with it! > > Janko > > Dne 26. 03. 2013 20:24, piÅ¡e Yuriy Tymchuk: >> Hi Janko, >> >> To be honest, you are touching Java only by parsing it's code. Yes, it's shifted towards Java because there is a lot of Java code that is ready to be analyzed, but all work is done in Smalltalk. Moreover you have to keep model generic, and this means that you have to work also with a Smalltalk model and probably tweak it. This is a great opportunity for student to compare languages and indeed see how much simpler Smalltalk is. That's how I see it. >> >> Regards >> Yuriy >> >> >> On 26 Ð±ÐµÑ. 2013, at 19:56, Janko MivÅ¡ek <janko.mivsek(a)eranova.si> wrote: >> >>> Privet Yuriy, >>> >>> Idea included, just that I'm wondering a bit if this one is a bit too >>> Java and not much Smalltalk specific. Would you explain a bit more? >>> Also, what others think? >>> >>> Best regards >>> Janko >>> >>> >>> Dne 26. 03. 2013 15:56, piÅ¡e Yuriy Tymchuk: >>>> Title: FAST Java Model >>>> >>>> Level: intermediate >>>> >>>> Possible mentor: Nikolas Anquetil >>>> >>>> Possible second mentor: Yuriy Tymchuk >>>> >>>> Description: For in depth source code analysis a support of abstract >>>> syntax trees is required. FAST is an abstract syntax tree extension for >>>> FAMIX meta-model that is used by Moose technology. The goal of this >>>> project is to create a Java version of FAST. >>>> >>>> Technical Details: As programming languages are different, their AST >>>> representations are different too. FAST model aims for creation of as >>>> generic as possible core that can be extended for different languages. >>>> Also the structure of a model allows creation of generic algorithms like >>>> symbol resolution, metrics calculation and rule checking that will work >>>> for any language. A prototype of FAST for Smalltalk is already >>>> implemented by Yuriy Tymchuk as well as couple of nodes for Java. During >>>> the project a student will implement the rest of the Java model, and >>>> improve some parts of PetitJava parser that is used by FAST. >>>> >>>> Benefits to the Student: The student will gain a deep understanding of >>>> a Java syntax and abstract syntax tree model. He will also learn about >>>> PetitParser framework, and gain knowledge about software modeling and >>>> analysis. >>>> >>>> Benefits to the Community: Community will get a FAST model for Java >>>> that can be used for software assessment with Moose. Also this model can >>>> be used later in PhD projects such as automation of source code >>>> translation form C++ to Java. >>>> >>>> On 26 Ð±ÐµÑ. 2013, at 12:36, Janko MivÅ¡ek <janko.mivsek(a)eranova.si >>>> <mailto:janko.mivsek@eranova.si>> wrote: >>>> >>>>> Dear Pharoers, >>>>> >>>>> Ideas are slowly coming, 14 so far, but this is way below the 30+ in >>>>> previous years. So, stretch your brain, come with some more ideas, which >>>>> will be interesting for potential students and of course useful for our >>>>> community. Students you are again welcome to propose such idea by your >>>>> own. One student idea for now! >>>>> >>>>> Ideas so far: http://gsoc2013.esug.org/ideas >>>>> >>>>> To propose an idea just respond to this post by fulfilling this idea >>>>> template: >>>>> >>>>> Title: >>>>> >>>>> Level: (beginner, intermediate, advanced) >>>>> >>>>> Possible mentor: (if already known) >>>>> >>>>> Possible second mentor: (if already known) >>>>> >>>>> Description >>>>> >>>>> Technical Details >>>>> >>>>> Benefits to the Student >>>>> >>>>> Benefits to the Community >>>>> >>>>> Best regards >>>>> Serge and Janko, >>>>> your this year GSoC admins > > -- > Janko MivÅ¡ek > Smalltalk GSoC Admin Team > http://gsoc2013.esug.org >

March 27, 2013

Re: [Pharo-project] [Help to review/test] Crash when downloading FFI

by Luc Fabresse

2013/3/27 Guillermo Polito <guillermopolito(a)gmail.com> > > > On Wed, Mar 27, 2013 at 9:46 AM, Luc Fabresse <luc.fabresse(a)gmail.com>wrote: > >> Hi all, >> >> 2013/3/26 Guillermo Polito <guillermopolito(a)gmail.com> >> >>> Hi! >>> >>> I've given a shot trying to get a fix for this case. Thanks to Eliot, I >>> think I reached a solution, but since I had some random results at first, >>> I'd like if someone else can take 5 minutes and validate. >>> >>> >>> https://pharo.fogbugz.com/f/cases/10134/SpecialObjectsArray-should-not-chan… >>> >> >> I still cannot create an account there. >> >> >>> >>> To test, the following snippet does not have to crash: >>> >>> Gofer it >>> smalltalkhubUser: 'DBXTalk' project: 'DBXTalkDriver'; >>> configurationOf: 'OpenDBXDriver'; >>> loadStable. >>> >> >> it failed 3 times. >> > > Just in case: I assume you loaded the slice with the "presumed fix", > didn't you? > no ;-) because I cannot see it. Luc > > >> two times woth a VM crash and one time with an unresponsive VM. >> I used: >> >> VM : 'NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: >> a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 >> NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: >> a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 >> git://gitorious.org/cogvm/blessed.git Commit: >> 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 >> By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14535 >> ' >> image : #20593 >> >> Thanks Guillermo to take a look at that. >> >> Cheers, >> >> Luc >> >> >>> Thanks very much! >>> Guille >>> >> >> >

March 27, 2013

Re: [Pharo-project] More GSoC ideas wanted, 3 days left ....

by Janko MivÅ¡ek

Yuriy, thanks for your explanation, I now understand the intent of your idea better. Good luck with it! Janko Dne 26. 03. 2013 20:24, piÅ¡e Yuriy Tymchuk: > Hi Janko, > > To be honest, you are touching Java only by parsing it's code. Yes, it's shifted towards Java because there is a lot of Java code that is ready to be analyzed, but all work is done in Smalltalk. Moreover you have to keep model generic, and this means that you have to work also with a Smalltalk model and probably tweak it. This is a great opportunity for student to compare languages and indeed see how much simpler Smalltalk is. That's how I see it. > > Regards > Yuriy > > > On 26 Ð±ÐµÑ. 2013, at 19:56, Janko MivÅ¡ek <janko.mivsek(a)eranova.si> wrote: > >> Privet Yuriy, >> >> Idea included, just that I'm wondering a bit if this one is a bit too >> Java and not much Smalltalk specific. Would you explain a bit more? >> Also, what others think? >> >> Best regards >> Janko >> >> >> Dne 26. 03. 2013 15:56, piÅ¡e Yuriy Tymchuk: >>> Title: FAST Java Model >>> >>> Level: intermediate >>> >>> Possible mentor: Nikolas Anquetil >>> >>> Possible second mentor: Yuriy Tymchuk >>> >>> Description: For in depth source code analysis a support of abstract >>> syntax trees is required. FAST is an abstract syntax tree extension for >>> FAMIX meta-model that is used by Moose technology. The goal of this >>> project is to create a Java version of FAST. >>> >>> Technical Details: As programming languages are different, their AST >>> representations are different too. FAST model aims for creation of as >>> generic as possible core that can be extended for different languages. >>> Also the structure of a model allows creation of generic algorithms like >>> symbol resolution, metrics calculation and rule checking that will work >>> for any language. A prototype of FAST for Smalltalk is already >>> implemented by Yuriy Tymchuk as well as couple of nodes for Java. During >>> the project a student will implement the rest of the Java model, and >>> improve some parts of PetitJava parser that is used by FAST. >>> >>> Benefits to the Student: The student will gain a deep understanding of >>> a Java syntax and abstract syntax tree model. He will also learn about >>> PetitParser framework, and gain knowledge about software modeling and >>> analysis. >>> >>> Benefits to the Community: Community will get a FAST model for Java >>> that can be used for software assessment with Moose. Also this model can >>> be used later in PhD projects such as automation of source code >>> translation form C++ to Java. >>> >>> On 26 Ð±ÐµÑ. 2013, at 12:36, Janko MivÅ¡ek <janko.mivsek(a)eranova.si >>> <mailto:janko.mivsek@eranova.si>> wrote: >>> >>>> Dear Pharoers, >>>> >>>> Ideas are slowly coming, 14 so far, but this is way below the 30+ in >>>> previous years. So, stretch your brain, come with some more ideas, which >>>> will be interesting for potential students and of course useful for our >>>> community. Students you are again welcome to propose such idea by your >>>> own. One student idea for now! >>>> >>>> Ideas so far: http://gsoc2013.esug.org/ideas >>>> >>>> To propose an idea just respond to this post by fulfilling this idea >>>> template: >>>> >>>> Title: >>>> >>>> Level: (beginner, intermediate, advanced) >>>> >>>> Possible mentor: (if already known) >>>> >>>> Possible second mentor: (if already known) >>>> >>>> Description >>>> >>>> Technical Details >>>> >>>> Benefits to the Student >>>> >>>> Benefits to the Community >>>> >>>> Best regards >>>> Serge and Janko, >>>> your this year GSoC admins -- Janko MivÅ¡ek Smalltalk GSoC Admin Team http://gsoc2013.esug.org

March 27, 2013

Re: [Pharo-project] [Help to review/test] Crash when downloading FFI

by Guillermo Polito

On Wed, Mar 27, 2013 at 9:46 AM, Luc Fabresse <luc.fabresse(a)gmail.com>wrote: > Hi all, > > 2013/3/26 Guillermo Polito <guillermopolito(a)gmail.com> > >> Hi! >> >> I've given a shot trying to get a fix for this case. Thanks to Eliot, I >> think I reached a solution, but since I had some random results at first, >> I'd like if someone else can take 5 minutes and validate. >> >> >> https://pharo.fogbugz.com/f/cases/10134/SpecialObjectsArray-should-not-chan… >> > > I still cannot create an account there. > > >> >> To test, the following snippet does not have to crash: >> >> Gofer it >> smalltalkhubUser: 'DBXTalk' project: 'DBXTalkDriver'; >> configurationOf: 'OpenDBXDriver'; >> loadStable. >> > > it failed 3 times. > Just in case: I assume you loaded the slice with the "presumed fix", didn't you? > two times woth a VM crash and one time with an unresponsive VM. > I used: > > VM : 'NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: > a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 > NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: > a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 > git://gitorious.org/cogvm/blessed.git Commit: > 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 > By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14535 > ' > image : #20593 > > Thanks Guillermo to take a look at that. > > Cheers, > > Luc > > >> Thanks very much! >> Guille >> > >

March 27, 2013

Re: [Pharo-project] [Pharo-users] More GSoC ideas wanted, 3 days left ....

by Janko MivÅ¡ek

Clement, your interesting idea was just added to the Ideas page. http://gsoc2013.esug.org/ideas#h-5. I shortened the title to just Pharo Image running on top of VirtualBox, will be ok? Dne 27. 03. 2013 10:30, piÅ¡e ï¿½: > Title: A Pharo Image running on top of VirtualBox with the help of a > Linux micro kernel > > Level: intermediate > > Possible mentor: Clement Bera > > Possible second mentor: Marcus Denker, Camillo Bruni > > Description > Archiving Pharo / Squeak Image is not easy : it depends on a VM, that > depends on a processor and an OS. Sometimes, we find old Pharo / Squeak > Image that we cannot run because we have lost the appropriate VM. This > is even more relevant when the project rely on a specifically built VM. > Moreover, sometimes we have also lost the Pharo / Squeak Image sources > from that image and we cannot read easily the code. I propose then to > save the working image with its sources, changes file and VM into a > virtual box image in order to have it working on top of virtual box > easily forever. This way the archived image will only depends on the > computer processor, and not on VM, OS, computer processor, source file, > change file > > Technical Details > The student would have to identify a minimum linux kernel in order to > run Pharo. Then, he would have to implement some Pharo code so that by > entering 'Smalltalk saveAsVirtualBoxImage' in workspace it would create > a virtual box image in the same folder, with the current VM, source > file, change file, image and the minimum linux kernel. This command will > probably go get some part of the virtual box image (for instance the > linux micro kernel) or some external tool as Vagrant > (http://www.vagrantup.com) somewhere on the internet. Running the > virtual box image would directly run the Pharo image on the Pharo VM > through a start-up process. Lastly, the student would have to set up a > Jenkins job on the Pharo-contribution continuous integration server that > create a Pharo virtual box image. If some time is remaining, the student > would have to find a solution to manage the Pharo image crashes in > virtual box. > > Benefits to the Student > The student will learn some smalltalk (networking, commandLineHandler), > how to set up a build in a Jenkins continuous integration server and > some linux command line. He will also have a nice impressive open source > tool to show. > > Benefits to the Community > The community will benefit from the archiving tool. The Pharo virtual > box image could also be interesting for some experiments. > > 2013/3/26 stephane ducasse <stephane.ducasse(a)free.fr > <mailto:stephane.ducasse@free.fr>> > > > On Mar 26, 2013, at 2:36 PM, Janko MivÅ¡ek <janko.mivsek(a)eranova.si > <mailto:janko.mivsek@eranova.si>> wrote: > > > Hi Stef, > > > > Dne 26. 03. 2013 13 <tel:26.%2003.%202013%2013>:35, piÅ¡e stephane > ducasse: > >> Janko > >> > >> Can you put andrei chis and nicolas passerini for Debugger > improvment projects. > > > > Put where? As mentors? > > Yes they are more into it. > > > > >> I know that alexandre should propose a couple of topics around > roassal. > >> > >> I could come up with a couple of other topics. > >> Here is one: > > > > Added > > > > Best regards > > Janko > >> > >> > >>> Ideas so far: http://gsoc2013.esug.org/ideas > >>> > >>> To propose an idea just respond to this post by fulfilling this idea > >>> template: > >>> > >>> Title: > >> Better rewriting rule tool > >> > >> > >>> Level: (beginner, intermediate, advanced) > >> Intermediate > >> > >>> Possible mentor: (if already known) > >> Stephane Ducasse > >> > >>> Possible second mentor: (if already known) > >> Andre Hora > >>> > >>> Description > >> The refactoring browser is based on a powerful rewrite > engine which transforms AST. > >> However it is quite cumbersome to write rewrite rules. There > is a need to build a tool to help > >> programmers defining their own transformation. > >> > >>> Technical Details > >>> > >>> Benefits to the Student > >> learning AST > >> learning AST transofrmation > >> learning AST pattern matching > >> User interface definition > >> > >>> Benefits to the Community > >> A tool that is cruelly missing. > >> > >> > >>> > >>> Best regards > >>> Serge and Janko, > >>> your this year GSoC admins > >>> > >>> > >>> -- > >>> Janko MivÅ¡ek > >>> Aida/Web > >>> Smalltalk Web Application Server > >>> http://www.aidaweb.si > >>> > >> > >> > >> > > > > -- > > Janko MivÅ¡ek > > Aida/Web > > Smalltalk Web Application Server > > http://www.aidaweb.si > > > > > -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

March 27, 2013

Re: [Pharo-project] [ANN] Pomodoro for Pharo 2.0

by MartinW

Torsten Bergmann wrote > "Provide an action when pomodoro is finished" > Pomodoro timerFor: 5 seconds > whenFinishedDo: [ self inform: 'Pomodoro finished'] Hi, i like the Pomodoro App. Two things i noticed when i tried the above example: - When you drag and drop a finished (red) Pomodoro Morph the whenFinishedDo: block is executed every time on dropping the morph. - The clock starts with 4 seconds and displays the 'Pomodoro finished' notification 1 second after the progress bar and the clock show zero. -- View this message in context: http://forum.world.st/ANN-Pomodoro-for-Pharo-2-0-tp4678427p4678538.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 27, 2013

Re: [Pharo-project] Some issues with UDP sockets in Pharo 1.4/Pharo 2.0

by Norbert Hartl

Am 27.03.2013 um 11:31 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > Semantically, datagrams can get lost or arrive out of order. A or B will never know as there are no guarantees. To add reliability, you need acknowledgements, retries, numbering, and so on. If you do all that with a stream interface, you are building your own TCP layer. Yes, but using a stream does not necessarily mean that the transport is reliable. It can still be a stream of (modern speak) "eventually consistent" transport :) I think we discussed it thoroughly and didn't want to hijack the original post. Norbert

March 27, 2013

Re: [Pharo-project] Some issues with UDP sockets in Pharo 1.4/Pharo 2.0

by Sven Van Caekenberghe

On 27 Mar 2013, at 10:55, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 27.03.2013 um 00:25 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > >> >> On 26 Mar 2013, at 23:46, Norbert Hartl <norbert(a)hartl.name> wrote: >> >>> Am 26.03.2013 um 21:08 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>> >>>> Hi Holger, >>>> >>>> On 26 Mar 2013, at 12:12, Holger Hans Peter Freyther <holger(a)freyther.de> wrote: >>>> >>>>> Hi, >>>>> >>>>> I am porting a tooling class that I wrote on GST for my SIP and MGCP code >>>>> to Pharo. This class will create a socket and then fork a RX and TX process. >>>>> I have some issues with 'stopping' the socket. I have created an example >>>>> that shows the issue in Pharo 2.0 and Pharo 1.4 with the pharovm (and to >>>>> have more debug output with a re-compiled one). >>>>> >>>>> >>>>> | s rx | >>>>> s := Socket newUDP. >>>>> rx := [ >>>>> [s waitForData. s halt] >>>>> on: ConnectionClosed do: [ s halt] >>>>> ] fork. >>>>> "Wait for the process to hit the readSemaphore" >>>>> (Delay forSeconds: 3) wait. >>>>> s close. >>>>> >>>>> >>>>> My expectation is that I will get the ConnectionClosed signal or at least >>>>> that >>#waitForData will return once the socket is closed. This is based >>>>> on reading the comment of >>#waitForData. >>>>> >>>>> >>>>> The Socket>>#waitForData documentation reads like this: >>>>> "Wait for data to arrive. This method will block until >>>>> data is available or the socket is closed. If the socket is closed >>>>> a ConnectionClosed exception will be signaled." >>>>> >>>>> >>>>> I had a look at the socket plugin and the following is happening. First >>>>> aio is disabled, the state set to ThisEndClosed, then ::close is called >>>>> and in the above case the result is '0' and the following code will be >>>>> executed: >>>>> >>>>> else if (0 == result) >>>>> { >>>>> /* close completed synchronously */ >>>>> SOCKETSTATE(s)= Unconnected; >>>>> FPRINTF((stderr, "closeConnection: disconnected\n")); >>>>> SOCKET(s)= -1; >>>>> } >>>>> >>>>> >>>>> this means that my 'rx' process will happily wait on the readSemaphore >>>>> of the Socket and will never be woken up. >>>>> >>>>> >>>>> My question are probably: >>>>> >>>>> 1.) Is this the intended behavior for Socket>>#close and Socket>>#waitForData? >>>>> 2.) How should I terminate my RX process? >>>>> >>>>> kind regards >>>>> holger >>>>> >>>>> PS: The issue is probably socket specific and not related to UDP. >>>> >>>> Maybe I am telling you things you already know, but TCP and UDP are fundamentally different. UDP is really one-shot, try-and-hope, completely asynchronous. In networking you generally only get a ConnectionClosed when you actually read or write (and even then ;-). >>>> >>> That's not really true. It is implementation specific. IMHO you can open a UDP socket in send and receive mode where the communication is synchronous. So your socket blocks until a datagram socket is received. This has to advantage that the underlying OS registers local and remote port and automatically and accepts only datagrams for the right ports match. As it is in a lot of use cases not preferrable to have blocking sockets while using UDP you use two sockets instead, one for sending and one for receiving. For this you need to register the listening socket for listening to everything. >>> Disclaimer: I took this from the back of my head and this might by outdated/inproper information. I just wanted to say that you shouldn't mix asynchronous with unidirectional :) >>> >>> Norbert >> >> I politely disagree ;-) >> >> But I am willing to learn: so please provide some references of such UDP usage. >> >> http://en.wikipedia.org/wiki/Datagram >> > If I find the time I dig out some things from the past. I just can't follow your reasoning that the way UDP is defined means unidirectional. TCP defines a connection, UDP does not. Connections are not required to have end-to-end communication. A remote port is a service identifier and local port is a client identifier. A port pair defines a communication channel. TCP just adds roles to both ends and defines stream sequences and transmission windows. > Maybe I misunderstood you then I take everything back :) It is probably about terms and how we each interpret them. I was not trying to be very formal, maybe that was confusing. Some of the terms you are using are not my standard vocabulary. But I don't think I said 'unidirectional' in any sentence. Here is my non-formal high-level description: A datagram (UDP packet) is a (small) collection of bytes being sent from A to B. Either A or B can be client/server, or sender/receiver. To receive or to be server, you have to be bound to a port (or you listen on the default port assigned to you when sending). Datagrams know their length and sender/destination host:port - but that is mostly implementation. Semantically, datagrams can get lost or arrive out of order. A or B will never know as there are no guarantees. To add reliability, you need acknowledgements, retries, numbering, and so on. If you do all that with a stream interface, you are building your own TCP layer. As a (Smalltalk) user, that means that #sendUDPData:toHost:port: will not tell you if anything is wrong, for example Socket newUDP sendUDPData: #[ 1 2 3 ] toHost: #[ 217 11 221 200 ] port: 12345 sending 3 bytes to pharo.st:12345 will give no error at all #receiveUDPDataInto: will either return a datagram or not, but does not signal any error it will also return immediately, so you have to loop BTW, these are not necessarily disadvantages, but advantages to build specific, efficient, low-level protocols. Sven > Norbert > >>>> The Socket API has many strange methods, most of which you should not touch. You should use SocketStream. Looking in the VM code is also misleading because the 3 platforms (Mac, Win, *nix) are different. In Socket[Stream] there is lots of historic baggage. >>>> >>>> I would suggest you look at Smalltalk code that actually works (for TCP, Zinc Client and Server code would do, for UDP, ZTimestampSNTPClient for example). >>>> >>>> For your concrete question (2): just start a reading process, wrap it in a handler and clean up. For UDP this will never happen: you will keep on reading nothing. For TCP reading will eventually fail if the other end disappears. >>>> >>>> HTH, >>>> >>>> Sven >>>> >>>> -- >>>> Sven Van Caekenberghe >>>> http://stfx.eu >>>> Smalltalk is the Red Pill >>>> >>>> >>> >>> >> >> > >

March 27, 2013