- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [squeak-dev] Xtreams : first embryonary port on Squeak

by Schwab,Wilhelm K

Nicolas, #fork in a test? Do you mean like the code below? The thread running the test waits on something signaled toward the end of the forked thread. If you want a watchdog timer, you could fork another thread that waits on a delay, sets an error flag (best to use a shared queue or a mutex to avoid weirdness) and then signals the test semaphore. You might also want to use #ifCurtailed: to set an error flag and wrap that with #ensure: to signal the semaphore. You don't necessarily need to be perfect about signaling the semaphore because failure to do so is not much different from your test going into an infinite loop (actually more benign because the stack isn't growing); you'll realize it, break, and figure out what didn't happen or at least "that it didn't" and try again forewarned. Does that help? Bill testLocalServerAndClient "11-09 - try a server and a client in the same image." | server port client serverSocket serverSocketStream text thread done read | port := 4900. done := Semaphore new. "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. "11-09 - this hung up w/o the thread. 11-09 - as you were; the problem was a lack of #flush on the send side, so there was nothing for the client side to read." thread := [ read := client nextMany:text size. done signal. ] forkAt:Processor userBackgroundPriority. thread name:'READ'. done wait. 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. thread := thread. " NetworkSmokeTestCase prod:#testLocalServerAndClient. " ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Nicolas Cellier [nicolas.cellier.aka.nice(a)gmail.com] Sent: Sunday, October 10, 2010 7:05 AM To: The general-purpose Squeak developers list Cc: Pharo Development Subject: Re: [Pharo-project] [squeak-dev] Xtreams : first embryonary port on Squeak 2010/10/10 Levente Uzonyi <leves(a)elte.hu>: > On Sun, 10 Oct 2010, Nicolas Cellier wrote: > >> >> THE STATUS OF TESTS: >> >> Tests do not all pass. There seems to be a bug in Squeak >> #replace:from:to:with: when the replacement is the collection itself, >> moved to the right (this is with a COG VM). > > #replace:from:to:with: is not supposed to work for moves. IIRC the primitive > version uses memcpy (or strncpy), so moving to the left works just because > the undelying C function supports it. I used to (ab)use this feature though. > > > Levente > OK, since we use memcpy rather than memmove in Squeak VM, I implemented the trivial work around - move through a motionBuffer temporary copy. I now have a single test failing, XTCollectionWriteStream>>#testReadWriteLargeAmount and this must be due to my #after:do: simplistic implementation. Messing with #fork in SUnit TestCase is tricky, and I need help on this point. Nicolas _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 10, 2010

Re: [Pharo-project] [squeak-dev] Compiler pedantic about ifNotNil: argument

by merlyn＠stonehenge.com

>>>>> "Igor" == Igor Stasenko <siguctua(a)gmail.com> writes: Igor> i am also missing: Igor> someThing ifTrue: 1 ifFalse: 0 Down that path lies ambiguity though. If you had actionSymbol := aBoolean ifTrue: #doThis else: #doThat. do you want the symbol assigned, or performed? Please don't add so much dwimmery here. I like it that Smalltalk is fairly strict with these basic forms. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion

Oct. 10, 2010

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

by Nicolas Cellier

2010/10/10 Igor Stasenko <siguctua(a)gmail.com>: > On 10 October 2010 16:13, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> personnally I do not like this form >> What does it do? >> >>> Â Â process ifNotNil: #terminate. >> > > here the test case for it: > > | process answer | > > process := Object new. > > answer := process ifNotNil: #terminate. > > self assert: answer == #terminate. > Ah, yes, I did not interpret it the same... I asked my son, which is not a Smalltalker, what he understood, and it was (process terminate) not (^#terminate). Nicolas > >> >> for me it means passes the symbol #terminate as argument to the method ifNotNil: >> If it has a more magical behavior then I do not know it. >> >> Stef >> >> >>> The compiler uselessly insist on #ifNotNil: argument being a zero/one arg block. >>> Thus we cannot write this xtream sentence >>> >>> Â Â process ifNotNil: #terminate. >>> >>> When the argument is not a block, Compiler should avoid inlining and >>> just send a normal message. >>> >>> cheers >>> >>> Nicolas >>> >>> _______________________________________________ >>> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 10, 2010

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

by StÃ©phane Ducasse

On Oct 10, 2010, at 3:17 PM, Igor Stasenko wrote: > On 10 October 2010 16:13, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> personnally I do not like this form >> What does it do? >> >>> process ifNotNil: #terminate. >> > > here the test case for it: > > | process answer | > > process := Object new. > > answer := process ifNotNil: #terminate. > > self assert: answer == #terminate. all that to avoid to have ifNotNil: [#terminate] I would not change the ifNotNil: for that. But make the compiler smarter Stef > > >> >> for me it means passes the symbol #terminate as argument to the method ifNotNil: >> If it has a more magical behavior then I do not know it. >> >> Stef >> >> >>> The compiler uselessly insist on #ifNotNil: argument being a zero/one arg block. >>> Thus we cannot write this xtream sentence >>> >>> process ifNotNil: #terminate. >>> >>> When the argument is not a block, Compiler should avoid inlining and >>> just send a normal message. >>> >>> cheers >>> >>> Nicolas >>> >>> _______________________________________________ >>> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 10, 2010

Re: [Pharo-project] WeakRegistry>>remove: - when you'll be in trouble

by Igor Stasenko

Moreover, i personally don't understand, why WeakRegistry have to be a subclass of Collection. What registry copy reject, select etc means to weak registry? My gut feeling that this is conceptually wrong. One should not use any kind of copying on weak registry. I think, that more intention revealing , one should send: registry discardFinalization: anObject instead of: registry remove: anObject On 10 October 2010 15:59, Igor Stasenko <siguctua(a)gmail.com> wrote: > A current implementation of this method > > remove: oldObject ifAbsent: exceptionBlock > Â Â Â Â "Remove oldObject as one of the receiver's elements." > > Â Â Â Â oldObject ifNil: [ ^nil ]. > Â Â Â Â ^(self protected: [ valueDictionary removeKey: oldObject ifAbsent: nil ]) > Â Â Â Â Â Â Â Â ifNil: [ exceptionBlock value ] > > simply removes a previously registered object from registry and voila. > > Now lets get back to our discussion about multiple finalizers per > object and using them in weak subscriptions etc. > > Suppose i am added a socket to weak registry, > and suppose i am added a weak subscription to it. > > Now, if i do 'socket close' , it tells weak registry to remove it from list. > And what we'll have: > Â - socket handle is closed > Â - socket is wiped from weak registry > Â - but weak subscription still listed somewhere in a list of subscriptions > > > My suggestion is, that upon #remove:, > a weak registry should notify all executors that object of interest > are no longer takes part in finalization scheme, > so they should not count on receiving #finalize eventually. > > In other words: > > remove: oldObject ifAbsent: exceptionBlock > Â Â Â Â "Remove oldObject as one of the receiver's elements." > > Â Â Â Â oldObject ifNil: [ ^nil ]. > Â Â Â Â ^(self protected: [ | executor | > Â Â Â Â Â Â executor := valueDictionary removeKey: oldObject ifAbsent: nil. > Â Â Â Â Â Â executor discardFinalization. > Â Â Â Â ]) > Â Â Â Â ifNil: [ exceptionBlock value ] > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Oct. 10, 2010

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

by Nicolas Cellier

Yes, this can be surprising at first. But I think this is because you read it with a preformated Smalltalk mind, rather than just english. it's just like: (1 to: 10) select: #even. Nicolas 2010/10/10 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > personnally I do not like this form > What does it do? > >> Â Â process ifNotNil: #terminate. > > > for me it means passes the symbol #terminate as argument to the method ifNotNil: > If it has a more magical behavior then I do not know it. > > Stef > > >> The compiler uselessly insist on #ifNotNil: argument being a zero/one arg block. >> Thus we cannot write this xtream sentence >> >> Â Â process ifNotNil: #terminate. >> >> When the argument is not a block, Compiler should avoid inlining and >> just send a normal message. >> >> cheers >> >> Nicolas >> >> _______________________________________________ >> 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 >

Oct. 10, 2010

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

by Igor Stasenko

On 10 October 2010 16:13, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > personnally I do not like this form > What does it do? > >> Â Â process ifNotNil: #terminate. > here the test case for it: | process answer | process := Object new. answer := process ifNotNil: #terminate. self assert: answer == #terminate. > > for me it means passes the symbol #terminate as argument to the method ifNotNil: > If it has a more magical behavior then I do not know it. > > Stef > > >> The compiler uselessly insist on #ifNotNil: argument being a zero/one arg block. >> Thus we cannot write this xtream sentence >> >> Â Â process ifNotNil: #terminate. >> >> When the argument is not a block, Compiler should avoid inlining and >> just send a normal message. >> >> cheers >> >> Nicolas >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

Oct. 10, 2010

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

by StÃ©phane Ducasse

personnally I do not like this form What does it do? > process ifNotNil: #terminate. for me it means passes the symbol #terminate as argument to the method ifNotNil: If it has a more magical behavior then I do not know it. Stef > The compiler uselessly insist on #ifNotNil: argument being a zero/one arg block. > Thus we cannot write this xtream sentence > > process ifNotNil: #terminate. > > When the argument is not a block, Compiler should avoid inlining and > just send a normal message. > > cheers > > Nicolas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 10, 2010

[Pharo-project] Symbol>>cull:

by Nicolas Cellier

We recently added #value: to Symbol to be able to use it in place of a one arg block. (1 to: 10) select: #even. It would be logical to add #cull: too, xtreams tests use this for example: output write: #[ 1 2 3 4 5 6 7 8 9 ]. self assert: ((input rejecting: #even) read: 5) = #[ 1 3 5 7 9 ] Any objection to add it in core ? (otherwise i will add it to Xtreams-VWCompatible) Nicolas

Oct. 10, 2010

Re: [Pharo-project] Glamour breaks settings browser on Pharo 1.1.1

by Tudor Girba

Hi, I am glad it works :). If you have further problems or questions about Glamour, it is better to address them on the moose-dev mailing list: https://www.iam.unibe.ch/mailman/listinfo/moose-dev moose-dev(a)iam.unibe.ch Cheers, Doru On 10 Oct 2010, at 14:56, Esteban Lorenzano wrote: > Oh, damn... it was 2.0-beta.4 the problem, I'm sorry, it is working ok with beta 7 > > > On 2010-10-10 09:07:16 -0300, Tudor Girba <tudor.girba(a)gmail.com> said: > >> Hi, >> I cannot reproduce this. I took a PharoDev 1.1.1 and executed: >> Gofer new >> squeaksource: 'Glamour'; >> package: 'ConfigurationOfGlamour'; >> load. >> ((Smalltalk at: #ConfigurationOfGlamour) project version: '2.0-beta.7') load. >> Opening the System Settings browser works just fine. >> Cheers, >> Doru >> On 10 Oct 2010, at 13:28, Esteban Lorenzano wrote: >>> Hi, >>> I'm loading Glamour into a PharoDev 1.1.1 >>> Gofer project repository: 'http://www.squeaksource.com/Glamour'; >>> load: 'Glamour' version: '2.0-beta.7'. >>> and then try to open the settings browser... it raises a DNU >>> Cheers, >>> Esteban >>> _______________________________________________ >>> 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 "What is more important: To be happy, or to make happy?"

Oct. 10, 2010