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

Re: [Pharo-project] about consistency between hex implementations

by StÃ©phane Ducasse

Hi eliot and squeakers here is a cs with all hex and printStringHex implementations for Squeak. Did not change the senders because no time for that. Stef $A hex '16r41' 20 hex '16r14' $A printStringHex '41' 20 printStringHex '14' Stef

Nov. 11, 2010

[Pharo-project] for the sprint at Buenos Ares

by StÃ©phane Ducasse

It would be good that you are available on chat or IRC so that before jumping into a fix you ask if it makes sense to work on it now. I will be online around 15h paris time. Stef

Nov. 11, 2010

Re: [Pharo-project] #& in Socket >> #waitForSendDoneFor:

by StÃ©phane Ducasse

so philippe let us know what we should integrate. On Nov 9, 2010, at 7:15 AM, Philippe Marschall wrote: > Hi > > I have a case where the #& in Socket >> #waitForSendDoneFor: shows up in > a tally (see attachment). I'm able to push about 1 Mbyte/s more when I > replace that with #and:. So my question is this really needed or should > I file a bug and send a patch? > > This is Pharo 1.1.1 BTW. > > Cheers > Philippe > <tally.txt>

Nov. 11, 2010

Re: [Pharo-project] About SourcedMethodReference

by Johan Brichau

On 10 Nov 2010, at 10:14, Benjamin wrote: > The last version is in !.2, and I'm still working on killing MethodReference references (I've done a ChangeSorter, I'm still playing with it, expecting for explosions ^^ If you want to play with it too, just say it to me) Ok Ben, consider this a yell ;-) I can spend some time on this over the long weekend in Belgium. I'll just work myself back in from the code I can find online Johan

Nov. 11, 2010

Re: [Pharo-project] #& in Socket >> #waitForSendDoneFor:

by Philippe Marschall

On 11.11.2010 00:39, Levente Uzonyi wrote: > On Thu, 11 Nov 2010, Levente Uzonyi wrote: > >> On Tue, 9 Nov 2010, Philippe Marschall wrote: >> >>> On 09.11.2010 07:58, Schwab,Wilhelm K wrote: >>>> What does your patch do? >>> >>> It replaces the #& with and #and: swaps receiver and argument to >>> preserve the same semantics. That saves a primitive call if the data is >>> already sent. It's basically the same as posted by Levente. >>> >>>> At a minimum, it deserves a little attention. Things that come to >>>> mind are that one version does less work due to some type of >>>> optimization (and runs faster as a result) or that one is too quick >>>> to detect a loss of connection and sends less data per opportunity, >>>> appearing to run slower as a result. >>>> >>>> Can you elaborate on "I'm able to push about 1 Mbyte/s more"? I >>>> guess I'm asking how that manifests itself? Are there a bunch of >>>> connections that form, send and fail? Do they each get a little >>>> farther or do they go faster? >>> >>> Throughput outgoing from the Pharo image was about 1 Mbyte/s higher. Now >> >> 1MB/s throughput sounds pretty low. On windows I could transfer >> 160MB/s using two processes in the same image by directly using the >> Socket primitives in 4k chunks. With high level methods (#sendData: >> #receiveData:) it went down to 110MB/s. With a two image setup >> (client-server) I got 66MB/s (one CPU/image). > > Looks like I missed the word "higher" in your mail. Anyway, I'm > interested in your absolute numbers too. See the attachment. Note that this benchmark is a lie, you're unlikely to see this performance in actual production code. It's a simple Seaside request handler that just writes a 16 Kbyte byte array to the response. In fact it's the source of www.seaside.st. No rendering, no encoding, no sessions, no backtracking, no continuations. You can find the code AJP-Tests-Core in the ajp project on SqueakSource. This is done on an old Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz, 64bit Linux 2.6.35, Cog r2316 and Pharo 1.1.1. Cheers Philippe

Nov. 11, 2010

Re: [Pharo-project] [Pharo-users] SocketStream persistence

by Mariano Martinez Peck

On Wed, Nov 10, 2010 at 3:09 PM, Daniel Klein <danielk(a)danielk.us> wrote: > I just discoverd the 'noTimeout' message in the 'configuration' protocol, > so that solves my persistence problem. > > But the question remains: When this process is running, it blocks until it > completes. How can I fire it up so that I can continue to interact with > Pharo while it is running? > > Dan > > ------------------------------ > *From:* pharo-users-bounces(a)lists.gforge.inria.fr [mailto: > pharo-users-bounces(a)lists.gforge.inria.fr] *On Behalf Of *Daniel Klein > *Sent:* Tuesday, November 09, 2010 22:41 > *To:* 'A friendly place where any question about pharo is welcome' > *Subject:* [Pharo-users] SocketStream persistence > > For my first real Pharo task I need to communicate with a server over > telnet. As a proof of concept I cobbled this code into a workspace without > regard for OO-anything (the hostname/login/password have been changed to > protect the innocent ;-) > > | wire answer | > [ > wire := SocketStream openConnectionToHostNamed: 'myhost' port: 23. > [ > wire upToAll: 'login: '. > wire nextPutAll: 'testlogin'; cr; flush. > wire upToAll: 'Password: '. > wire nextPutAll: 'dummypassword'; cr; flush. > wire upToAll: '>'. > wire nextPutAll: 'dbl'; cr; flush. > wire upToAll: '?'. > wire nextPutAll: '12'; cr; flush. > wire upTo: Character lf. > answer := Integer readFromString: (wire upTo: (Character value: 3)). > wire upToAll: 'C:\home>'. > wire nextPutAll: 'exit'. "close gracefully" > ] > ensure: [wire close]. > ^ answer > ] > on: ConnectionClosed > do: [:ex | Transcript show: ex asString;cr. ex resume]. > > The server process, dbl, is a simple C program that takes a number, n, as > input and returns n*2. I'm using character 3 to indicate the end of the > output sent back from the C program. > > This all works great and I get the expected answer of '24'. > > So, the next step was to simulate the server process taking a while to > complete and then send back some form of acknowledgement. So I put a 'sleep > 5 minutes' in the server process just prior to sending back the answer. The > problem is that I then get a 'ConnectionTimedOut' error after about 45-50 > seconds. If I change the 'on:' line to: > > on: ConnectionClosed, ConnectionTimedOut > > then this errors out with 'IllegalResumeAttempt'. > > How can I keep the connection alive while the server is 'busy'? > > As an aside, while Pharo is processing the above code, I can't do anything > else until it either completes or errors out. I thought Pharo used 'green > threads'? > > I'm using: > > Pharo-1.1.1-- > Latest update: #11414 > > on Windows XP Pro. > > Dan > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users > >

Nov. 11, 2010

Re: [Pharo-project] About SourcedMethodReference

by Luc Fabresse

2010/11/10 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > On Nov 9, 2010, at 10:57 PM, Igor Stasenko wrote: > > > I think identity is better. It forcing more strict rules: no more than > > one method reference > > in system necessary for representing same method. > > I'm not sure I understand exactly what you mean. > In the recent message or in the versions, you get mulitple version of the > "same" methods but different methodreference. > That was my point. And I think that equality of SourcedMethodReference should not be based on identity but a modified version of the MethodReference implementation integrating the version. #Luc > > > > On 9 November 2010 23:48, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > >> Hi all, > >> When SourcedMethodReference have been introduced, some tests in > >> SystemNavigationTest turned yellow. > >> The tests are currently expecting a MethodReference. > >> If I modify the tests to exepect a SourcedMethodReference, the problem > is > >> now on: > >> SourcedMethodReference>>= > >> ^self == aMethodReference. > >> Why this has been redefined in SourcedMethodReference? > >> I think that the super class (MethodReference) implementation is > >> semantically better. No? > >> > >> MethodReference>>= anotherMethodReference > >> "Answer whether the receiver and the argument represent the > >> same object." > >> ^ self species == anotherMethodReference species > >> and: [(self classSymbol = anotherMethodReference classSymbol) > >> and: [(self classIsMeta = anotherMethodReference classIsMeta) > >> and: [self methodSymbol = anotherMethodReference methodSymbol]]] > >> #Luc > >> > > > > > > > > -- > > Best regards, > > Igor Stasenko AKA sig. > > > > >

Nov. 11, 2010

Re: [Pharo-project] VM Plugins that are important for performance?

by David T. Lewis

On Thu, Nov 11, 2010 at 12:34:44AM +0100, Levente Uzonyi wrote: > On Wed, 10 Nov 2010, Stefan Marr wrote: > > >Hi all: > > > >From your experience, what are the important VM plugins to gain a snappy > >and responsive Pharo image. > > > >Stef mentioned the Font plugin, but will this improve the user experience > >or is it just nice to have to support different kinds of fonts? > > > >The reason for my question is the 'performance hit' I have to take with > >the RoarVM for the moment. > > I doubt any plugin changes the performance of #tinyBenchmarks. But the > following plugins make a huge difference in other benchmarks and GUI > performance: > - MiscPrimitivePlugin > - LargeIntegers > - FloatMathPlugin > - FloatArrayPlugin > - Matrix2x3Plugin > - B2DPlugin DeflatePlugin is also important. It has a large impact on performance when using Monticello. Dave

Nov. 11, 2010

Re: [Pharo-project] Weird OB accept behavior

by Lukas Renggli

As I wrote, this is not an OB issue. Propose a change to Morphic. Lukas On 10 November 2010 22:39, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Lukas, > > That explains it, but the very fact that I ran across this suggests that there is a reason to compile code as-is, so perhaps the check should be removed. > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Lukas Renggli [renggli(a)gmail.com] > Sent: Wednesday, November 10, 2010 1:51 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Weird OB accept behavior > >> (1) select #plotFrom:to:using:keepGoing:plots: and accept the code; no errors are reported; fair enough (or is it?). > > The editor does not trigger the accept event if the text is not dirty. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > > -- Lukas Renggli www.lukas-renggli.ch

Nov. 11, 2010

Re: [Pharo-project] Finding Family-tree of images

by Igor Stasenko

On 11 November 2010 02:01, HwaJong Oh <daliot.oh(a)gmail.com> wrote: > > I have a hibbit of saving new version of images when i feed unsecure about > something. So i end up a lot of disk space taken by them. I felt it is time > for me to clean up the redundance in my disk. I wanted to have a sense of > family tree of the images. > > l := (FileStream fileNamed:'Squeak4.0-basic-pocketcube-morphic.changes') > contents lines. > > s := l select: [:each| each beginsWith: '----SNAPSHOT----']. > > i := OrderedCollection new. > (s collect: [:ea| ea substrings at: 7 ]) do: [:e| > Â Â Â Â (i includes: e) ifFalse: [i addLast: e.]. > Â Â Â Â ]. > i > > Now i have images names in time order. But still i need to run this code on > every images not listed in evaluated result. > > How do you handle this problem? > you could use a file directory to find all .changes files and then simply scan them like above. > Best regards > HwaJong Oh > -- > View this message in context: http://forum.world.st/Finding-Family-tree-of-images-tp3037106p3037106.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Best regards, Igor Stasenko AKA sig.

Nov. 11, 2010