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

Re: [Pharo-project] this style looks cool

by ja＠anymorphic.com

Tudor Girba <tudor.girba@...> writes: > Is this Theme available? I can push the change monday morning. ja

Aug. 29, 2010

Re: [Pharo-project] [Pharo-users] MethodName

by Mariano Martinez Peck

On Wed, Aug 25, 2010 at 1:25 AM, Benjamin Van Ryseghem < benjamin.vanryseghem(a)gmail.com> wrote: > Hi everybody > > I came back with a new version of Method Name with a better Package Chooser > and more choices about the search :) > > > I hope it's useful but if there is some behaviour you would like the Method > Name implements, just let me know > > > Gofer new > squeaksource: 'PharoTaskForces'; > package: 'MethodName'; > load. > > Hi Ben. This is muuuch cooler :) There are 2 things I suggest you: 1) Whenever you send something in order to let people to test is, send in which Pharo version should we load it. It is not enough saying Pharo 1.2 for example. Maybe you need to say 12XXX because in THAT version NullStyler was integrated. 2) You should send this kind of mails to pharo-project(a)lists.gforge.inria.fr instead of pharo-users(a)lists.gforge.inria.fr Bugs I found: - Search a "class name" and put "ImageSeg*". You will see a list of results. Selet ImageSegment for example. Then, select again "selector" instead of "Class names" If you then click again in of the resulted classes, there is a DNU UndefinedObject doesNotUnderstand: #methodClass. In MethodNameUI >> sourceCode where it does: self selectedClass value methodClass I attach PharoDebug.log > > Thank you > > > Ben > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > >

Aug. 29, 2010

Re: [Pharo-project] New bytecodes not in blue book ... (Eliot Miranda)

by James Ladd

Thanks Eliot. Your linked article clears it up: http://www.mirandabanda.org/cogblog/2008/07/22/closures-part-ii-the-bytecod… 140 10001100 kkkkkkkk jjjjjjjj Push Temp At kkkkkkkk In Temp Vector At: jjjjjjjj This fetches the local at offset j..j on the stack and push the k..kâth element in it. The next two store into the k..kâth element of the local at j..j, one version popping the result off the stack. This is a general convention in the Smalltalk-80 compiler. These are store and store-pop forms of almost every store opcode. The store form is used in the stores into vat and vax in things like var := vat := vax := expr whereas the pop form gets used in the store into var. 141 10001101 kkkkkkkk jjjjjjjj Store Temp At kkkkkkkk In Temp Vector At: jjjjjjjj 142 10001110 kkkkkkkk jjjjjjjj Pop and Store Temp At kkkkkkkk In Temp Vector At: jjjjjjjj The final bytecode is more interesting. The wording is unclear to me: "This fetches the local at offset j..j on the stack and push the k..kâth element in it." Does it mean, get local at index j..j and push onto the stack the k..k'th element in it? So 109 <8C 00 01> pushTemp: 0 inVectorAt: 1 Get temp at 1 (j..j) and push element at 0 (k..k) ?? 97 <8E 00 01> popIntoTemp: 0 inVectorAt: 1 get vector at temp index 1 (j..j) and pop and store stack value into element 0 (k..k) ?? 116 <8D 00 01> storeIntoTemp: 0 inVectorAt: 1 I dont understand this one, store what? into element 0 of vector at 1 ?? In the pop variation I can understand where the value is coming from, but not the above form. Please can you clarify? Rgs, James.

Aug. 29, 2010

Re: [Pharo-project] this style looks cool

by Schwab,Wilhelm K

Doru, That gets me a step closer to understanding them, but all I see so far are symbols. #browserIcon:selector: is getting complicated. Dolphin's sending #icon to classes being displayed a lot more clear, although I suspect some of the complexity in OB is to allow things like the success/failure icons in test cases - I'm not sure whether Dolphin has an answer to that?? What are the icon choices, and how would I add to them? Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Tudor Girba [tudor.girba(a)gmail.com] Sent: Sunday, August 29, 2010 2:48 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] this style looks cool 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] 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