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

Re: [Pharo-project] Issue 3220 in pharo: SystemNavigation: Better System
by pharo＠googlecode.com Nov. 11, 2010

Nov. 11, 2010

Updates: Status: Fixed Labels: Milestone-1.2 Comment #1 on issue 3220 by marcus.denker: SystemNavigation: Better System http://code.google.com/p/pharo/issues/detail?id=3220 (No comment was entered for this change.)

1 1

[Pharo-project] Issue 3223 in pharo: Replace all sends to compile: in SystemNavigationTest by compileSilently:
by pharo＠googlecode.com Nov. 11, 2010

Nov. 11, 2010

Status: Accepted Owner: luc.fabresse New issue 3223 by luc.fabresse: Replace all sends to compile: in SystemNavigationTest by compileSilently: http://code.google.com/p/pharo/issues/detail?id=3223 This make the tests faster and cleaner. In pharo task forces. Tests-LucFabresse.242

1 2

Re: [Pharo-project] About SourcedMethodReference
by StÃ©phane Ducasse Nov. 11, 2010

Nov. 11, 2010

On Nov 11, 2010, at 7:55 AM, Johan Brichau wrote: > > 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. Excellent. Ben sent me this code to try to fix all the reference to MethodSource but it should be tested because it can toast you :) http://code.google.com/p/pharo/issues/detail?id=3224 > I'll just work myself back in from the code I can find online > > Johan

1 0

Re: [Pharo-project] [Pharo-users] SocketStream persistence
by Mariano Martinez Peck Nov. 11, 2010

Nov. 11, 2010

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 > >

2 1

[Pharo-project] for the sprint at Buenos Ares
by StÃ©phane Ducasse Nov. 11, 2010

Nov. 11, 2010

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

2 1

Re: [Pharo-project] about consistency between hex implementations
by StÃ©phane Ducasse Nov. 11, 2010

Nov. 11, 2010

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

1 0

[Pharo-project] About SourcedMethodReference
by Luc Fabresse Nov. 11, 2010

Nov. 11, 2010

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

5 8

[Pharo-project] #& in Socket >> #waitForSendDoneFor:
by Philippe Marschall Nov. 11, 2010

Nov. 11, 2010

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

3 8

Nov. 11, 2010

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. > > 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. >

2 1

[Pharo-project] Weird OB accept behavior
by Schwab,Wilhelm K Nov. 11, 2010

Nov. 11, 2010

I am using a 1.1.1 image with SystemBrowser defaultOpenBrowser OBSystemBrowserAdaptor I am debugging some code that I have not used for a while, so a few growing pains would not be a surprise. What DOES surprise me is the following: (1) select #plotFrom:to:using:keepGoing:plots: and accept the code; no errors are reported; fair enough (or is it?). (2) edit the source (even just adding a harmless new line) and accept, and the compiler (correctly, it appears) complains that arguments are already defined. I suspect the arguments are indeed stomping on instance variables that I added during the past year, and that confusion is the source of some seriously strange looking behavior. The point is that accept is apparently doing nothing or failing silently until I actually edit the source. I greatly prefer the error messages to silence; I assume the silence is related to a desire to get code loaded intact rather than having MC bark mid-load?? Bill

2 3