- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Sockets in Pharo CollaborActive Book

by Schwab,Wilhelm K

Sean, IMHO, you are correct to be unhappy. In fairness, not only is half of the code "on the client" - half of it IS the client :) It's just that the example is not very practical; no data are sent for the client to read. The vast majority of (good) sockets programming is handling errors and non-responsive peers. The most consistent story I have gotten is that ConnectionQueue is the preferred way to create a server; last I looked, it was broken, at least in Pharo. It also offers no way, out of the box, to specify on which interface the server should be listening - that's kind of important. Sadly, it polls for connections rather than blocking (just one Process, of course) until an event is generated as a client tries to connect. It screams for some serious cleanup. I have yet to look at what happens when, whether by socket or socket stream (which was not in the stream hierarchy and hence missing important protocol), the other side is non-responsive. I doubt it will be ideal, which is to block only the Process attempting the connection. Ditto that for DNS activity; only the process attempting it should suffer if the server is slow or completely unresponsive. IMHO, sockets should not have timeouts; they should simply block only the thread that initiates activity so that everything else moves along as expected. On a server, a separate process can look for inactivity and terminate offending connections; on a client, either a similar watchdog or the user can make the call as to when to give up. An event/announcement should be triggered off of a socket when its peer closes to enable timely cleanup. Testing some of this stuff requires establishing lengthy I/O and powering off hubs at strategic times. Until a system can survive that without hanging more than a calling thread, it's not ready. Bill testLocalServerAndClientNoThread "11-09 - try a server and a client in the same image. Try without the separate read thread." | server port client serverSocket serverSocketStream text read | port := 4900. "11-09 - gag the prompter below" serverSocket := nil. server := ConnectionQueue portNumber:port queueLength:5. [ client := SocketStream openConnectionToHostNamed:'localhost' port:port. [ serverSocket isNil ] whileTrue:[ serverSocket := server getConnectionOrNil. ]. serverSocketStream := SocketStream on:serverSocket. text := 'Long live Tux!'. serverSocketStream nextPutAll:text; flush. read := client nextMany:text size. self should:[ read = text ]. Transcript nextPutAll:'Just to make the point, we read: '; nextPutAll:read; cr; flush. ] ensure:[ server destroy. serverSocketStream close. client close. ]. "11-09 - no prompts" serverSocket := serverSocket. client := client. serverSocketStream := serverSocketStream. " NetworkSmokeTestCase prod:#testLocalServerAndClientNoThread. " ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Sean P. DeNigris [sean(a)clipperadams.com] Sent: Sunday, August 29, 2010 5:05 PM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Sockets in Pharo CollaborActive Book The description of sockets at http://book.pharo-project.org/book/networking/Socket/ is: Socket is one of the main networking classes. You can create a new TCP socket with the message #newTCP. > > This example creates a TCP socket and puts it into listening mode. After a > client has connected, it reads data from the socket. > > | server client | > server := Socket newTCP. > server listenOn: 12345 backlogSize: 4. > server waitForConnectionFor: 600. > client := server accept. > client receiveData > Huh?! It looks like half the code in this snippet belongs on the server, and the other half on the client. I tried: Server doit: server := Socket newTCP. server listenOn: 12345 backlogSize: 4. server waitForConnectionFor: 600. Client doit: server := Socket newTCP. server listenOn: 12345 backlogSize: 4. server waitForConnectionFor: 600. client := server accept. client receiveData. but the server just hung forever. After flopping around for a while, and checking the swiki, it seemed to be listenOn:backlogSize: that was the problem. Everything went well with: Server DoIt: server := Socket newTCP. server listenOn: 8080. server waitForConnectionFor: 600. server sendData: 'Hello from the server' Client PrintIt: client := Socket newTCP. client connectTo: (NetNameResolver localHostAddress) port: 8080. client receiveData. Anyway, I'd like to have this be clearer, but my knowledge is very basic. Also, the class comment for socket reads "...Sockets are the lowest level of networking object in Squeak and are not normally used directly..." so is this where we want to direct people first? Thanks. Sean -- View this message in context: http://forum.world.st/Sockets-in-Pharo-CollaborActive-Book-tp2399361p239936… Sent from the Pharo Smalltalk mailing list archive at Nabble.com. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 29, 2010

Re: [Pharo-project] WebClient-Core port to Pharo 1.1 final

by Andreas Raab

Hi Sven, [cc: pharo list since I think there are some larger issues to discuss] First of all thank you for your continued interest in WebClient. It is nice to see that people like to use it. However, I'm more than a bit surprised about what you are saying below about having WebClient in Pharo 1.2. Honestly, I was dumbfounded when I went to read some of the discussions on the Pharo list. May I ask what the due diligence process is for including packages in Pharo? I would have expected that the process includes 1) checking the project page on SS for the license and 2) sending the author a courtesy note along the lines of "hey we want to include your code, are you okay with that?" (in particular if the author of the package isn't on the Pharo list and consequently has no clue about what you're doing). 1. Regarding WebClient's license, please have a look at any of the following repositories, all of which are under MIT: http://www.squeaksource.com/Balloon3D.html http://www.squeaksource.com/CroquetGL.html http://www.squeaksource.com/ToolBuilder.html http://www.squeaksource.com/TweakCore.html ... etc ... As you can see, when I mean to put code under the MIT license, I try to state that by including a copy of the license on the front page of the repository as well as setting the license field. Contrary to, for example, the following repositories: http://www.squeaksource.com/ar.html http://www.squeaksource.com/SqueakSSL.html http://www.squeaksource.com/WebClient.html which are not (or not yet) under MIT. Obviously, I'm trying to be as clear as possible on these matters, which is why I was pointing out that your repository incorrectly claims that the version of WebClient in it is LGPLv2. I'm surprised (and shocked) that apparently nobody in Pharo even tries to find out what the license status for WebClient is. 2. Regarding my intentions / position you'll have to keep in mind that I don't read the Pharo list. I tried to follow it in the past only to be faced with several vicious attacks against Squeak and myself and as a consequence I stopped reading it. Consequently, this is the first time anyone has ever mentioned the inclusion of WebClient in Pharo to me. In short, my position is that we need more shared libraries, not more forks. You will probably see the irony that I specifically didn't set a license on WebClient to prevent such forks without any prior discussion (under the hopelessly naive assumption that there would be some sort of due diligence process) only to find out that you've forked WebClient already. How very ironic indeed. Because of my position above, I think WebClient should be an external package, loaded for example via Metacello configuration. In fact, that's exactly why I provided a Metacello configuration to begin with. Can someone perhaps explain where the urge to include (and consequently fork) WebClient comes from? WebClient is a perfectly good external package and for the time being I prefer it should stay that way. If you want to replace HTTPSocket, then have a look at Squeak 4.2 which contains a very simple HTTPSocket implementation that has hooks so that WebClient will be used if it's loaded. Regarding fixes for Pharo, as far as I know the only changes that I haven't included was a bunch of #asString sprinkled all over the places, and the abominations of replacing #squeakToUtf8 and #utf8ToSqueak with "convert[From|To]WithConverter: UTF8TextConverter new". On both of these issues I feel very strongly; I will not make the code substantially worse only to deal with shortcomings of Pharo. So if you cannot come to a reasonable resolution for these, you'll need the extension methods. Outside of that, I believe that not only have I integrated all the fixes that have been sent to me, I have also added several patches to WebClient-Pharo that provide important fixes for (in Pharo broken) network operations without which WebClient would not work in any released Pharo versions. Summary: * I'm surprised and I'm shocked to see that there is apparently no due diligence regarding new packages in Pharo. I find this in particular shocking giving the wild claims on the Pharo web site that "From the beginning of Pharo we have maintained a strict rule that every contributor has to sign our license agreement." I haven't. (and geez, when did Michael got dropped from the Pharo board?) * I don't want WebClient to be included in Pharo since this means you will be producing a Pharo-only fork of WebClient which is counter-productive from my perspective. I want WebClient to remain a shared loadable package with a canonical source repository available to all forks of Squeak, including Pharo. * I have, and will continue to do so, integrate fixes for Pharo as long as I consider them reasonable. If there is interest, I can also provide an updated Metacello configuration; although that really just boils down to updating it to the latest package versions. Cheers, - Andreas On 8/29/2010 4:43 AM, Sven Van Caekenberghe wrote: > Andreas, > > The lastest fiddling that I did is now in PharoInBox: > > Name: WebClient-Core-SvenVanCaekenberghe.74 > Author: SvenVanCaekenberghe > Time: 27 August 2010, 1:59:46 pm > UUID: d97ff218-9bde-4259-bf8a-f9d0fe116138 > Ancestors: WebClient-Core-StephaneDucasse.73, WebClient-Core-pmm.73 > > merged in pharo-core 1.2 > > We're down to 2 unit test failures/errors againt your latest tests. > > A number of people including myself are interested, enthousiastic and willing to help bring WebClient to Pharo (1.1 and 1.2), and by using it, help it improve its core functionality. However, the current process, whereby you mostly ignore Pharo related fixes, makes that very difficult (we basically almost have to start over again with each commit you do, comparing changes becomes harder and harder). You can check the Pharo mailing lists. > > As I said before, it is your code and your decision what your standpoint is regarding portability (to Squeak derivatives and even other Smalltalks). I can understand it if you find it too much work. But I do think you should make it clear what your standpoint is. > > Regards, > > Sven > > On 29 Aug 2010, at 04:30, Andreas Raab wrote: > >> You're probably busy, so just a little "ping" :-) >> >> Cheers, >> - Andreas >> >> -------- Original Message -------- >> Subject: Re: WebClient-Core port to Pharo 1.1 final >> Date: Wed, 25 Aug 2010 22:40:07 -0700 >> From: Andreas Raab<andreas.raab(a)gmx.de> >> To: Sven Van Caekenberghe<sven(a)beta9.be> >> >> Hi Sven, >> >> Sorry for the belated reply I think something is wrong with Thunderbird >> 3's spam filter; it appears that messages with attachments get routinely >> marked as spam or something. In any case a message on Squeak-dev just >> got me to look for lost email and yours was among them :-) >> >> Do you know if these changes are still applicable? There have been >> numerous changes in the meantime in WebClient and haven't been paying >> much attention. >> >> Oh, and one more thing. When I went to the project page at >> http://www.squeaksource.com/ADayAtTheBeach.html it claims that "Code >> commited to this repository will be automatically under LGPLv2 license." >> >> Obviously, this is not true for WebClient; could I ask you to change the >> declaration on your repository or move your versions to some other >> repository? The way it is right now people might rightfully assume that >> the WebClient versions in your repository are under LGPLv2 which is >> simply incorrect. >> >> Thanks, >> - Andreas >> >> On 8/12/2010 1:59 AM, Sven Van Caekenberghe wrote: >>> Hi Andreas, >>> >>> I made some changes to the latest WebClient-Core in order to run it on Pharo 1.1: >>> >>> Sven Van Caekenberghe uploaded a new version of WebClient-Core to project A Day At The Beach: >>> http://www.squeaksource.com/ADayAtTheBeach/WebClient-Core-SvenVanCaekenberg… >>> >>> ==================== Summary ==================== >>> >>> Name: WebClient-Core-SvenVanCaekenberghe.63 >>> Author: SvenVanCaekenberghe >>> Time: 12 August 2010, 10:46:11 am >>> UUID: 149d44b2-138b-4d63-a158-f587b2bd391d >>> Ancestors: WebClient-Core-ar.62 >>> >>> added some more #asString's where needed to deal with the different semantics of #, in Squeak vs Pharo; removed usage of #and:and:and:and: with a composition of #and: in WebClient>>connect >>> >>> ================================================ >>> >>> I still have some tests that fail, but I can't find the problem: >>> >>> >>> >>> >>> >>> >>> 39 run, 34 passes, 0 expected failures, 0 failures, 5 errors, 0 unexpected passes >>> Failures: >>> >>> Errors: >>> WebClientServerTest>>#testMultipartFiles >>> WebClientServerTest>>#testMultipartFiles2 >>> WebClientServerTest>>#testServerError >>> WebClientServerTest>>#testWebSockets >>> WebClientServerTest>>#testWebSocketsFraming >>> >>> The #testServerError bothers me most. >>> >>> I am posting this to a Pharo list as well so that maybe others can help. >>> Maybe I'll find the problems myself later on. >>> >>> Sven >>> >>> >>> > >

Aug. 29, 2010

Re: [Pharo-project] [squeak-dev] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b4.

by John M McIntosh

Ok, you are mixing two issues here (a) I need to make the 5.8 behaviour the same as the 4.2.x VM behaviour. (b) Once we have the same behaviour then you are welcome to propose changing the smalltalk text editor code to make the cursor and word selection dance however you or the community would like it to... On 2010-08-29, at 11:55 AM, Tudor Girba wrote: > Ahh, I see. > > I expect it to jump between words. On regular Mac applications, you get this behavior by pressing alt-arrow. > > And when I press shift-ctrl-arrow, I expect it to select up to the end of the word. On regular Mac applications, you get this behavior by pressing alt-shift-arrow. > > Of course, I would not mind if instead of ctrl we would have alt :). > > Cheers, > Doru > -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Aug. 29, 2010

Re: [Pharo-project] this style looks cool

by Mariano Martinez Peck

On Sun, Aug 29, 2010 at 11:06 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > contact the guy of anymorphic :) > > and that guy is...... ? > Stef > > On Aug 29, 2010, at 10:54 PM, Mariano Martinez Peck wrote: > > > I like this style also. Would love to have such theme available in Pharo > :) > > > > On Sun, Aug 29, 2010 at 8:48 PM, Tudor Girba <tudor.girba(a)gmail.com> > wrote: > > Hi Bill, > > > > The icons are available the OB browser by overriding #browserIcon. > > > > Some of the icons that you see are shipped with Seaside. The blueish > bubble denotes an announcement and is already present in Pharo. > > > > Cheers, > > Doru > > > > > > > > On 29 Aug 2010, at 20:43, Schwab,Wilhelm K wrote: > > > > Stef, > > > > The first thing I notice in it is background colors, or is it just > variation in backlighting on my monitor? Have we evolved to the point that > background colors can be readily set? Last I looked into it, there was > mention of a background style that I could never find. > > > > Another thing is that a large fraction of the classes have icons > associated with them. Dolphin makes that easy to do: just implement a > class-side #icon, which I always did in terms of a rich set of class icons > present in the base system, so I never had to mess with the details. It > would be nice if it were that easy in Pharo; when well designed, such icons > can aid perception. Since I constantly praise Dolphin, I will point out > that D6's use of apples for most classes was not the best choice. It was > visually grating and lead to a rather unprofessional look in a deployed > executable where I had previously never given a second thought when the > default icon was a dot. A rich (and expendable) set of clean icons for > collections/composites, views, plugs/sockets, various metaphors that are > easy to associate with one's own classes would be helpful. > > > > This might be similar to Dolphin's ability to apply multiple categories > to a method: you won't miss it if you have never had access to it, but it is > a *good* thing to have. > > > > Bill > > > > > > > > ________________________________________ > > From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of stephane ducasse > [stephane.ducasse(a)free.fr] > > Sent: Sunday, August 29, 2010 2:17 PM > > To: Pharo Development > > Subject: [Pharo-project] this style looks cool > > > > http://www.anymorphic.com/softwareentwicklung.html > > > > Stef > > > > _______________________________________________ > > 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 > > > > "From an abstract enough point of view, any two things are similar." > > > > > > > > > > > > _______________________________________________ > > 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 >

Aug. 29, 2010

Re: [Pharo-project] this style looks cool

by StÃ©phane Ducasse

contact the guy of anymorphic :) Stef On Aug 29, 2010, at 10:54 PM, Mariano Martinez Peck wrote: > I like this style also. Would love to have such theme available in Pharo :) > > On Sun, Aug 29, 2010 at 8:48 PM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi Bill, > > The icons are available the OB browser by overriding #browserIcon. > > Some of the icons that you see are shipped with Seaside. The blueish bubble denotes an announcement and is already present in Pharo. > > Cheers, > Doru > > > > On 29 Aug 2010, at 20:43, Schwab,Wilhelm K wrote: > > Stef, > > The first thing I notice in it is background colors, or is it just variation in backlighting on my monitor? Have we evolved to the point that background colors can be readily set? Last I looked into it, there was mention of a background style that I could never find. > > Another thing is that a large fraction of the classes have icons associated with them. Dolphin makes that easy to do: just implement a class-side #icon, which I always did in terms of a rich set of class icons present in the base system, so I never had to mess with the details. It would be nice if it were that easy in Pharo; when well designed, such icons can aid perception. Since I constantly praise Dolphin, I will point out that D6's use of apples for most classes was not the best choice. It was visually grating and lead to a rather unprofessional look in a deployed executable where I had previously never given a second thought when the default icon was a dot. A rich (and expendable) set of clean icons for collections/composites, views, plugs/sockets, various metaphors that are easy to associate with one's own classes would be helpful. > > This might be similar to Dolphin's ability to apply multiple categories to a method: you won't miss it if you have never had access to it, but it is a *good* thing to have. > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of stephane ducasse [stephane.ducasse(a)free.fr] > Sent: Sunday, August 29, 2010 2:17 PM > To: Pharo Development > Subject: [Pharo-project] this style looks cool > > http://www.anymorphic.com/softwareentwicklung.html > > Stef > > _______________________________________________ > 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 > > "From an abstract enough point of view, any two things are similar." > > > > > > _______________________________________________ > 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. 29, 2010

[Pharo-project] Sockets in Pharo CollaborActive Book

by Sean P. DeNigris

The description of sockets at http://book.pharo-project.org/book/networking/Socket/ is: Socket is one of the main networking classes. You can create a new TCP socket with the message #newTCP. > > This example creates a TCP socket and puts it into listening mode. After a > client has connected, it reads data from the socket. > > | server client | > server := Socket newTCP. > server listenOn: 12345 backlogSize: 4. > server waitForConnectionFor: 600. > client := server accept. > client receiveData > Huh?! It looks like half the code in this snippet belongs on the server, and the other half on the client. I tried: Server doit: server := Socket newTCP. server listenOn: 12345 backlogSize: 4. server waitForConnectionFor: 600. Client doit: server := Socket newTCP. server listenOn: 12345 backlogSize: 4. server waitForConnectionFor: 600. client := server accept. client receiveData. but the server just hung forever. After flopping around for a while, and checking the swiki, it seemed to be listenOn:backlogSize: that was the problem. Everything went well with: Server DoIt: server := Socket newTCP. server listenOn: 8080. server waitForConnectionFor: 600. server sendData: 'Hello from the server' Client PrintIt: client := Socket newTCP. client connectTo: (NetNameResolver localHostAddress) port: 8080. client receiveData. Anyway, I'd like to have this be clearer, but my knowledge is very basic. Also, the class comment for socket reads "...Sockets are the lowest level of networking object in Squeak and are not normally used directly..." so is this where we want to direct people first? Thanks. Sean -- View this message in context: http://forum.world.st/Sockets-in-Pharo-CollaborActive-Book-tp2399361p239936… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 29, 2010

Re: [Pharo-project] this style looks cool

by Mariano Martinez Peck

I like this style also. Would love to have such theme available in Pharo :) On Sun, Aug 29, 2010 at 8:48 PM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi Bill, > > The icons are available the OB browser by overriding #browserIcon. > > Some of the icons that you see are shipped with Seaside. The blueish bubble > denotes an announcement and is already present in Pharo. > > Cheers, > Doru > > > > On 29 Aug 2010, at 20:43, Schwab,Wilhelm K wrote: > > Stef, >> >> The first thing I notice in it is background colors, or is it just >> variation in backlighting on my monitor? Have we evolved to the point that >> background colors can be readily set? Last I looked into it, there was >> mention of a background style that I could never find. >> >> Another thing is that a large fraction of the classes have icons >> associated with them. Dolphin makes that easy to do: just implement a >> class-side #icon, which I always did in terms of a rich set of class icons >> present in the base system, so I never had to mess with the details. It >> would be nice if it were that easy in Pharo; when well designed, such icons >> can aid perception. Since I constantly praise Dolphin, I will point out >> that D6's use of apples for most classes was not the best choice. It was >> visually grating and lead to a rather unprofessional look in a deployed >> executable where I had previously never given a second thought when the >> default icon was a dot. A rich (and expendable) set of clean icons for >> collections/composites, views, plugs/sockets, various metaphors that are >> easy to associate with one's own classes would be helpful. >> >> This might be similar to Dolphin's ability to apply multiple categories to >> a method: you won't miss it if you have never had access to it, but it is a >> *good* thing to have. >> >> Bill >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [ >> pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of stephane >> ducasse [stephane.ducasse(a)free.fr] >> Sent: Sunday, August 29, 2010 2:17 PM >> To: Pharo Development >> Subject: [Pharo-project] this style looks cool >> >> http://www.anymorphic.com/softwareentwicklung.html >> >> Stef >> >> _______________________________________________ >> 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 > > "From an abstract enough point of view, any two things are similar." > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 29, 2010

Re: [Pharo-project] OSProcess - can it pipe 1 MB?

by Schwab,Wilhelm K

Dave, Why does primWrite: id from: stringOrByteArray startingAt: startIndex count: count "Write count bytes onto this file from the given string or byte array starting at the given index. Answer the number of bytes written." raise an error? Perhaps it or a related method should answer the number of bytes written. There should be a compromise between locking up the VM and having no idea how quickly the other side can accept data. Given a count of what was written (as suggested in the comment, and perhaps zero bytes if the other side is struggling), then one could design a reasonable loop with a delay to provide the needed flow control. Otherwise, it's just guesswork. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of David T. Lewis [lewis(a)mail.msen.com] Sent: Sunday, August 29, 2010 3:05 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] OSProcess - can it pipe 1 MB? It does not belong in OSProcess unless it's something that the underlying operating system actually supports, which is not the case here. As far as I know, there is no Unix system call for determining how much data a pipe is ready to accept. You'll need to manage your flow control yourself. You may also need to call #setNonBlocking on the pipe writer, otherwise you can block on write and lock up the virtual machine(I think you know that already but just in case). If the process at the other end of your pipe is keeping up with the data, it won't be a problem, but if you try to write to a full pipe without pulling something out of the other end, you will lock up your VM completely unless the stream has been set to non-blocking mode. Dave On Sun, Aug 29, 2010 at 02:28:50PM -0400, Schwab,Wilhelm K wrote: > Dave, > > Sure, but then the command shell must then be doing something that OSProcess should do: transfer "large" (1MB isn't much these days) blobs in pieces that are manageable. The questions are where does it belong, and what if anything is necessary to ensure the pipe is ready for the next piece? > > One thought would be > > AttachableFileStream>>nextPutAll:blob > | in | > in := ReadStream on:blob. > [ in atEnd ] whileFalse:[ > self nextPutAll:( in next:32000). > ]. > > but it should run into the same problem after a few times through the loop. It needs some "flow control" and could easily belong elsewhere in the hierarch?? The above assumes the (should be changed) silent truncation of #next:. > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of David T. Lewis [lewis(a)mail.msen.com] > Sent: Sunday, August 29, 2010 12:37 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] OSProcess - can it pipe 1 MB? > > On Sun, Aug 29, 2010 at 11:36:02AM -0400, Schwab,Wilhelm K wrote: > > I am trying to pipe roughly 1 MB of data into a program on Linux; I know it can handle the load, because I have tested it with by cat-ing a script and the data. I do not yet promise that my Pharo code is correct; if the program did not respond or returned junk, I would look to myself. But I am getting errors suggesting that AttachableFileStream is failing on writing to the pipe, and it's very suspicious that it simply can't handle the size of the string. Any ideas? > > > > Bill > > Try googling "maximum size of write to linux pipe". Unix pipes > have a capacity limit, and the write will fail if you try to write > too large a chunk all at once. > > Dave > > > _______________________________________________ > 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

Aug. 29, 2010

Re: [Pharo-project] OSProcess - can it pipe 1 MB?

by David T. Lewis

It does not belong in OSProcess unless it's something that the underlying operating system actually supports, which is not the case here. As far as I know, there is no Unix system call for determining how much data a pipe is ready to accept. You'll need to manage your flow control yourself. You may also need to call #setNonBlocking on the pipe writer, otherwise you can block on write and lock up the virtual machine(I think you know that already but just in case). If the process at the other end of your pipe is keeping up with the data, it won't be a problem, but if you try to write to a full pipe without pulling something out of the other end, you will lock up your VM completely unless the stream has been set to non-blocking mode. Dave On Sun, Aug 29, 2010 at 02:28:50PM -0400, Schwab,Wilhelm K wrote: > Dave, > > Sure, but then the command shell must then be doing something that OSProcess should do: transfer "large" (1MB isn't much these days) blobs in pieces that are manageable. The questions are where does it belong, and what if anything is necessary to ensure the pipe is ready for the next piece? > > One thought would be > > AttachableFileStream>>nextPutAll:blob > | in | > in := ReadStream on:blob. > [ in atEnd ] whileFalse:[ > self nextPutAll:( in next:32000). > ]. > > but it should run into the same problem after a few times through the loop. It needs some "flow control" and could easily belong elsewhere in the hierarch?? The above assumes the (should be changed) silent truncation of #next:. > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of David T. Lewis [lewis(a)mail.msen.com] > Sent: Sunday, August 29, 2010 12:37 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] OSProcess - can it pipe 1 MB? > > On Sun, Aug 29, 2010 at 11:36:02AM -0400, Schwab,Wilhelm K wrote: > > I am trying to pipe roughly 1 MB of data into a program on Linux; I know it can handle the load, because I have tested it with by cat-ing a script and the data. I do not yet promise that my Pharo code is correct; if the program did not respond or returned junk, I would look to myself. But I am getting errors suggesting that AttachableFileStream is failing on writing to the pipe, and it's very suspicious that it simply can't handle the size of the string. Any ideas? > > > > Bill > > Try googling "maximum size of write to linux pipe". Unix pipes > have a capacity limit, and the write will fail if you try to write > too large a chunk all at once. > > Dave > > > _______________________________________________ > 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. 29, 2010

Re: [Pharo-project] [squeak-dev] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b4.

by Mariano Martinez Peck

On Sun, Aug 29, 2010 at 7:37 PM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > On 4.2.2beta1 these keys work as expected. > > I have to mention that I am still on Mac OS X 10.5.8. Perhaps the others > are on Snow Leopard. Could that be a difference? > > I am in 10.6.4 > Cheers, > Doru > > > > On 29 Aug 2010, at 19:27, John M McIntosh wrote: > > Ok, so I have Ken Brown & Mariano Martinez Peck saying the cntl-arrow >> keys work, and Tudor Girba saying they don't work. >> Obviously I need someone to document the behaviour in a 4.x VM and then in >> 5.8b4 so we understand what happens or doesn't happen. >> >> >> On 2010-08-29, at 7:45 AM, Ken G. Brown wrote: >> >> ... >>> When Squeak has focus, cntl-arrow keys change Spaces as is normal on >>> MacPro 10.6.4 >>> >>> Ken G. Brown >>> >>> >> -- >> >> =========================================================================== >> 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 >> > > -- > www.tudorgirba.com > > "Be rather willing to give than demanding to get." > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 29, 2010