September 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] [BUG]Socket(Object)>>primitiveFailed:

by laurent.laffont＠gmail.com

here insert explanation of what you were doing, suspect changes you've made and so forth. 7 September 2011 8:24:30 pm VM: unix - i686 - linux-gnu - Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.112] Image: Pharo1.3 [Latest update: #13298] Socket(Object)>>primitiveFailed: Receiver: a Socket[invalidSocketHandle] Arguments and temporary variables: selector: #primSocketSendDone: Receiver's instance variables: semaphore: a Semaphore() socketHandle: #[210 150 108 78 0 0 0 0 24 235 24 8] readSemaphore: a Semaphore() writeSemaphore: a Semaphore() Socket(Object)>>primitiveFailed Receiver: a Socket[invalidSocketHandle] Arguments and temporary variables: Receiver's instance variables: semaphore: a Semaphore() socketHandle: #[210 150 108 78 0 0 0 0 24 235 24 8] readSemaphore: a Semaphore() writeSemaphore: a Semaphore() Socket>>primSocketSendDone: Receiver: a Socket[invalidSocketHandle] Arguments and temporary variables: socketID: #[210 150 108 78 0 0 0 0 24 235 24 8] Receiver's instance variables: semaphore: a Semaphore() socketHandle: #[210 150 108 78 0 0 0 0 24 235 24 8] readSemaphore: a Semaphore() writeSemaphore: a Semaphore() Socket>>waitForSendDoneFor: Receiver: a Socket[invalidSocketHandle] Arguments and temporary variables: timeout: 45 startTime: 16100 msecsDelta: 45000 msecsEllapsed: nil sendDone: nil Receiver's instance variables: semaphore: a Semaphore() socketHandle: #[210 150 108 78 0 0 0 0 24 235 24 8] readSemaphore: a Semaphore() writeSemaphore: a Semaphore() Socket>>sendSomeData:startIndex:count:for: Receiver: a Socket[invalidSocketHandle] Arguments and temporary variables: aStringOrByteArray: #[72 84 84 80 47 49 46 49 32 51 48 50 32 70 111 117 110 100...etc... startIndex: 1 count: 211 aTimeoutInSeconds: 45 bytesSent: nil Receiver's instance variables: semaphore: a Semaphore() socketHandle: #[210 150 108 78 0 0 0 0 24 235 24 8] readSemaphore: a Semaphore() writeSemaphore: a Semaphore() Socket>>sendSomeData:startIndex:count: Receiver: a Socket[invalidSocketHandle] Arguments and temporary variables: aStringOrByteArray: #[72 84 84 80 47 49 46 49 32 51 48 50 32 70 111 117 110 100...etc... startIndex: 1 count: 211 Receiver's instance variables: semaphore: a Semaphore() socketHandle: #[210 150 108 78 0 0 0 0 24 235 24 8] readSemaphore: a Semaphore() writeSemaphore: a Semaphore() Socket>>sendData:count: Receiver: a Socket[invalidSocketHandle] Arguments and temporary variables: buffer: #[72 84 84 80 47 49 46 49 32 51 48 50 32 70 111 117 110 100 13 10 68 97...etc... n: 211 sent: 0 Receiver's instance variables: semaphore: a Semaphore() socketHandle: #[210 150 108 78 0 0 0 0 24 235 24 8] readSemaphore: a Semaphore() writeSemaphore: a Semaphore() [socket sendData: outBuffer count: outNextToWrite - 1] in SocketStream>>flush Receiver: SocketStream[inbuf:4kb/outbuf:4kb] Arguments and temporary variables: Receiver's instance variables: recentlyRead: 798 socket: a Socket[invalidSocketHandle] inBuffer: #[71 69 84 32 47 115 116 97 116 117 115 47 87 65 73 109 97 103 101 83...etc... outBuffer: #[72 84 84 80 47 49 46 49 32 51 48 50 32 70 111 117 110 100 13 10 68...etc... inNextToWrite: 799 outNextToWrite: 212 lastRead: 798 timeout: 30 autoFlush: false bufferSize: 4096 binary: true shouldSignal: true BlockClosure>>on:do: Receiver: [socket sendData: outBuffer count: outNextToWrite - 1] Arguments and temporary variables: exception: ConnectionTimedOut handlerAction: [:ex | shouldSignal ifTrue: []] handlerActive: true Receiver's instance variables: outerContext: SocketStream>>flush startpc: 60 numArgs: 0 SocketStream>>flush Receiver: SocketStream[inbuf:4kb/outbuf:4kb] Arguments and temporary variables: Receiver's instance variables: recentlyRead: 798 socket: a Socket[invalidSocketHandle] inBuffer: #[71 69 84 32 47 115 116 97 116 117 115 47 87 65 73 109 97 103 101 83...etc... outBuffer: #[72 84 84 80 47 49 46 49 32 51 48 50 32 70 111 117 110 100 13 10 68...etc... inNextToWrite: 799 outNextToWrite: 212 lastRead: 798 timeout: 30 autoFlush: false bufferSize: 4096 binary: true shouldSignal: true SocketStream>>close Receiver: SocketStream[inbuf:4kb/outbuf:4kb] Arguments and temporary variables: Receiver's instance variables: recentlyRead: 798 socket: a Socket[invalidSocketHandle] inBuffer: #[71 69 84 32 47 115 116 97 116 117 115 47 87 65 73 109 97 103 101 83...etc... outBuffer: #[72 84 84 80 47 49 46 49 32 51 48 50 32 70 111 117 110 100 13 10 68...etc... inNextToWrite: 799 outNextToWrite: 212 lastRead: 798 timeout: 30 autoFlush: false bufferSize: 4096 binary: true shouldSignal: true [self log debug: 'Closing stream'. stream close] in [[self executeRequestResponseLoopOn: stream] ensure: [self log debug: 'Closing stream'. stream close]] in [[[self executeRequestResponseLoopOn: stream] ensure: [self log debug: 'Closing stream'. stream close]] ifCurtailed: [self log debug: 'Destroying socket'. socket destroy]] in ZnMultiThreadedServer>>serveConnectionsOn: Receiver: a ZnMultiThreadedServer(running 16624) Arguments and temporary variables: stream: SocketStream[inbuf:4kb/outbuf:4kb] Receiver's instance variables: port: 16624 process: a Process in [self schedule. beingWaitedOn ifTrue: [delaySemaphore ...etc... serverSocket: a Socket[waitingForConnection] delegate: a ZnSeasideServerAdaptorDelegate authenticator: nil log: a ZnLogSupport lastRequest: nil lastResponse: nil MethodContext(ContextPart)>>resume: Receiver: BlockClosure>>on:do: Arguments and temporary variables: value: a ZnMultiThreadedServer(running 16624) ctxt: BlockClosure>>ensure: unwindBlock: [self log debug: 'Closing stream'. stream close] Receiver's instance variables: sender: nil pc: nil stackp: 3 method: (BlockClosure>>#on:do: "a CompiledMethod(137625600)") closureOrNil: nil receiver: [chain := thisContext sender cut: ctxt. ctxt jump] BlockClosure>>ensure: Receiver: [self executeRequestResponseLoopOn: stream] Arguments and temporary variables: aBlock: [self log debug: 'Closing stream'. stream close] complete: true returnValue: nil Receiver's instance variables: outerContext: [[self executeRequestResponseLoopOn: stream] ensure: [self log ...etc... startpc: 122 numArgs: 0 [[self executeRequestResponseLoopOn: stream] ensure: [self log debug: 'Closing stream'. stream close]] in [[[self executeRequestResponseLoopOn: stream] ensure: [self log debug: 'Closing stream'. stream close]] ifCurtailed: [self log debug: 'Destroying socket'. socket destroy]] in ZnMultiThreadedServer>>serveConnectionsOn: Receiver: a ZnMultiThreadedServer(running 16624) Arguments and temporary variables: stream: SocketStream[inbuf:4kb/outbuf:4kb] Receiver's instance variables: port: 16624 process: a Process in [self schedule. beingWaitedOn ifTrue: [delaySemaphore ...etc... serverSocket: a Socket[waitingForConnection] delegate: a ZnSeasideServerAdaptorDelegate authenticator: nil log: a ZnLogSupport lastRequest: nil lastResponse: nil BlockClosure>>ifCurtailed: Receiver: [[self executeRequestResponseLoopOn: stream] ensure: [self log debug: 'Closing stream'. ...etc... Arguments and temporary variables: aBlock: [self log debug: 'Destroying socket'. socket destroy] complete: nil result: nil Receiver's instance variables: outerContext: [[[self executeRequestResponseLoopOn: stream] ensure: [self log...etc... startpc: 117 numArgs: 0 [[[self executeRequestResponseLoopOn: stream] ensure: [self log debug: 'Closing stream'. stream close]] ifCurtailed: [self log debug: 'Destroying socket'. socket destroy]] in ZnMultiThreadedServer>>serveConnectionsOn: Receiver: a ZnMultiThreadedServer(running 16624) Arguments and temporary variables: stream: SocketStream[inbuf:4kb/outbuf:4kb] socket: a Socket[invalidSocketHandle] Receiver's instance variables: port: 16624 process: a Process in [self schedule. beingWaitedOn ifTrue: [delaySemaphore ...etc... serverSocket: a Socket[waitingForConnection] delegate: a ZnSeasideServerAdaptorDelegate authenticator: nil log: a ZnLogSupport lastRequest: nil lastResponse: nil [self value. Processor terminateActive] in BlockClosure>>newProcess Receiver: [[[self executeRequestResponseLoopOn: stream] ensure: [self log debug: 'Closing stream'....etc... Arguments and temporary variables: Receiver's instance variables: outerContext: ZnMultiThreadedServer>>serveConnectionsOn: startpc: 112 numArgs: 0 --- The full stack --- Socket(Object)>>primitiveFailed: Socket(Object)>>primitiveFailed Socket>>primSocketSendDone: Socket>>waitForSendDoneFor: Socket>>sendSomeData:startIndex:count:for: Socket>>sendSomeData:startIndex:count: Socket>>sendData:count: [socket sendData: outBuffer count: outNextToWrite - 1] in SocketStream>>flush BlockClosure>>on:do: SocketStream>>flush SocketStream>>close [self log debug: 'Closing stream'. stream close] in [[self executeRequestResponseLoopOn: stream] ensure: [self log debug: 'Closing stream'. stream close]] in [[[self executeRequestResponseLoopOn: stream] ensure: [self log debug: 'Closing stream'. stream close]] ifCurtailed: [self log debug: 'Destroying socket'. socket destroy]] in ZnMultiThreadedServer>>serveConnectionsOn: MethodContext(ContextPart)>>resume: BlockClosure>>ensure: [[self executeRequestResponseLoopOn: stream] ensure: [self log debug: 'Closing stream'. stream close]] in [[[self executeRequestResponseLoopOn: stream] ensure: [self log debug: 'Closing stream'. stream close]] ifCurtailed: [self log debug: 'Destroying socket'. socket destroy]] in ZnMultiThreadedServer>>serveConnectionsOn: BlockClosure>>ifCurtailed: [[[self executeRequestResponseLoopOn: stream] ensure: [self log debug: 'Closing stream'. stream close]] ifCurtailed: [self log debug: 'Destroying socket'. socket destroy]] in ZnMultiThreadedServer>>serveConnectionsOn: [self value. Processor terminateActive] in BlockClosure>>newProcess

Sept. 7, 2011

Re: [Pharo-project] Fwd: A new way to render the debugger

by Benjamin

On Sep 7, 2011, at 7:52 PM, StÃ©phane Ducasse wrote: > I like the fact that the method symbols are aligned > If the class name is too long (is it cut) so that we can still see the selector without horizontally scrolling? When the name is too long (it should never happened in a perfect world ;)) the "middle" is moved :) So you do not have to scroll, but as in the previous debugger, the selector can be hidden I just notice that no scrollbar appears, I will fix that ;) Ben > > On Sep 7, 2011, at 6:09 PM, Benjamin wrote: > >> Hello guys, >> >> Camillo and I were looking for a way to improve the way the debugger show the stack, so we worked on a tabbed version of the list. Here is a screenshot: >> >> <Screen shot 2011-09-07 at 4.56.06 PM.png> >> >> >> And so we implement the same on senders/implementors :) >> >> Do you like it ? (Should it be integrated ?) >> >> Thanks in advance for your feedback, >> >> >> Ben >> > >

Sept. 7, 2011

Re: [Pharo-project] Fwd: A new way to render the debugger

by StÃ©phane Ducasse

I like the fact that the method symbols are aligned If the class name is too long (is it cut) so that we can still see the selector without horizontally scrolling? On Sep 7, 2011, at 6:09 PM, Benjamin wrote: > Hello guys, > > Camillo and I were looking for a way to improve the way the debugger show the stack, so we worked on a tabbed version of the list. Here is a screenshot: > > <Screen shot 2011-09-07 at 4.56.06 PM.png> > > > And so we implement the same on senders/implementors :) > > Do you like it ? (Should it be integrated ?) > > Thanks in advance for your feedback, > > > Ben >

Sept. 7, 2011

Re: [Pharo-project] How to convert Sensor polling left over

by StÃ©phane Ducasse

:) you see you found my mail Tx for the record of our discussions. On Sep 7, 2011, at 5:03 PM, Igor Stasenko wrote: > On 7 September 2011 10:53, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: >> Hi igor >> >> how should I convert code like that >> >> [ Sensor anyButtonPressed ] whileFalse: >> [ aBitBlt destOrigin: Sensor cursorPoint. >> aBitBlt copyBits ]. >> >> So that it avoid polling? >> >> Should we change >> >> contents := (Sensor shiftPressed not) >> ifTrue: [currentCompiledMethod decompileWithTemps] >> ifFalse: [currentCompiledMethod decompile]. >> contents := contents decompileString asText makeSelector >> > > For examples which using some drawing on screen, i think best would be > to implement a custom morph, which > accepts a block for drawing stuff in it. > Then example code could draw there, and open it in morph. Then once > used no longer amused, he can just close morph/window > instead of waiting for mouse clicks etc etc. > > For things like shift-key pressed, a code should use events /hand to > extract the key statuses, but not sensor. > One of reasons for that, if we could have an event recorder & event > player, all tests/examples could use them. > But if you refer directly to Sensor, such scenarios are not possible, > since sensor provides an actual status of keyboard/events whatever. > >> >> or >> [(nextEvent := Sensor peekEvent) isNil] whileFalse: >> [nextEvent first = currentBuf first >> ifFalse: [^trail contents "different event type"]. >> nextEvent fifth = currentBuf fifth >> ifFalse: [^trail contents "buttons changed"]. >> nextEvent sixth = currentBuf sixth >> ifFalse: [^trail contents "modifiers changed"]. >> "nextEvent is similar. Remove it from the queue, and check the next." >> nextEvent := Sensor nextEvent. >> nextEvent >> ifNotNil: [ trail nextPut: nextEvent third @ nextEvent fourth ]]. >> >> Then when I install the nonpolling behavior >> InputEventSensor installPollingEventSensorFramework >> the menu of the world gets sluggish (may be I do not use the right VM BTW). > > yes, you using old VM, which for some reason not awaking the fetcher > process immediately once new events > arrived from OS. > >> >> Stef >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. >

Sept. 7, 2011

[Pharo-project] Fwd: A new way to render the debugger

by Benjamin

Hello guys, Camillo and I were looking for a way to improve the way the debugger show the stack, so we worked on a tabbed version of the list. Here is a screenshot: And so we implement the same on senders/implementors :) Do you like it ? (Should it be integrated ?) Thanks in advance for your feedback, Ben

Sept. 7, 2011

[Pharo-project] [update 1.4] #14124

by Marcus Denker

14124 ----- Issue 4613: metacello default platform http://code.google.com/p/pharo/issues/detail?id=4613 Issue 4712: move some Collections package to Kernel http://code.google.com/p/pharo/issues/detail?id=4712 -- Marcus Denker -- http://marcusdenker.de

Sept. 7, 2011

Re: [Pharo-project] How to convert Sensor polling left over

by Igor Stasenko

On 7 September 2011 10:53, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > Hi igor > > how should I convert code like that > > [ Sensor anyButtonPressed ] whileFalse: > Â Â Â Â Â Â Â Â [ aBitBlt destOrigin: Sensor cursorPoint. > Â Â Â Â Â Â Â Â aBitBlt copyBits ]. > > So that it avoid polling? > > Should we change > > contents := (Sensor shiftPressed not) > Â Â Â Â Â Â Â Â ifTrue: [currentCompiledMethod decompileWithTemps] > Â Â Â Â Â Â Â Â ifFalse: [currentCompiledMethod decompile]. > Â Â Â Â contents := contents decompileString asText makeSelector > For examples which using some drawing on screen, i think best would be to implement a custom morph, which accepts a block for drawing stuff in it. Then example code could draw there, and open it in morph. Then once used no longer amused, he can just close morph/window instead of waiting for mouse clicks etc etc. For things like shift-key pressed, a code should use events /hand to extract the key statuses, but not sensor. One of reasons for that, if we could have an event recorder & event player, all tests/examples could use them. But if you refer directly to Sensor, such scenarios are not possible, since sensor provides an actual status of keyboard/events whatever. > > or > [(nextEvent := Sensor peekEvent) isNil] whileFalse: > Â Â [nextEvent first = currentBuf first > Â Â Â ifFalse: [^trail contents "different event type"]. > Â Â nextEvent fifth = currentBuf fifth > Â Â Â ifFalse: [^trail contents "buttons changed"]. > Â Â nextEvent sixth = currentBuf sixth > Â Â Â ifFalse: [^trail contents "modifiers changed"]. > Â Â "nextEvent is similar. Â Remove it from the queue, and check the next." > Â Â nextEvent := Sensor nextEvent. > Â Â nextEvent > Â Â Â ifNotNil: [ trail nextPut: nextEvent third @ nextEvent fourth ]]. > > Then when I install the nonpolling behavior > Â Â Â Â InputEventSensor installPollingEventSensorFramework > the menu of the world gets sluggish (may be I do not use the right VM BTW). yes, you using old VM, which for some reason not awaking the fetcher process immediately once new events arrived from OS. > > Stef > > -- Best regards, Igor Stasenko AKA sig.

Sept. 7, 2011

Re: [Pharo-project] how to capture pasting in a textmorph

by Tudor Girba

How do I find the changes? Doru On 7 Sep 2011, at 14:56, Camillo Bruni wrote: > It has been integrated in 1.4 but I guess you can copy out the changes and merge them in 1.3 (though no guarantee that this works)â¦ > > cami > > On 2011-09-07, at 10:22, Tudor Girba wrote: >> Is this available only in 1.4? >> >> Cheers, >> Doru >> >> >> On 7 Sep 2011, at 10:05, Camillo Bruni wrote: >> >>> I added a PluggableTextMorph >> #changedAction: which should do exactly that. It's currently used for the new ClassSerach widget which as a live-filtered list. >>> >>> cami >>> >>> On 2011-09-07, at 09:57, Tudor Girba wrote: >>> >>>> Hi, >>>> >>>> I have a PluggableTextMorph, and I would like to get notified every time the text contents change. >>>> >>>> Currently, I intercept keystroke:from:, but the problem is that this does not capture pasting of text. Is there a better hook? >>>> >>>> Cheers, >>>> Doru >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Value is always contextual." >>>> >>>> >>>> >>>> >>> >>> >> >> -- >> www.tudorgirba.com >> >> "It's not how it is, it is how we see it." >> >> > > -- www.tudorgirba.com "Be rather willing to give than demanding to get."

Sept. 7, 2011

Re: [Pharo-project] how to capture pasting in a textmorph

by Camillo Bruni

It has been integrated in 1.4 but I guess you can copy out the changes and merge them in 1.3 (though no guarantee that this works)â¦ cami On 2011-09-07, at 10:22, Tudor Girba wrote: > Is this available only in 1.4? > > Cheers, > Doru > > > On 7 Sep 2011, at 10:05, Camillo Bruni wrote: > >> I added a PluggableTextMorph >> #changedAction: which should do exactly that. It's currently used for the new ClassSerach widget which as a live-filtered list. >> >> cami >> >> On 2011-09-07, at 09:57, Tudor Girba wrote: >> >>> Hi, >>> >>> I have a PluggableTextMorph, and I would like to get notified every time the text contents change. >>> >>> Currently, I intercept keystroke:from:, but the problem is that this does not capture pasting of text. Is there a better hook? >>> >>> Cheers, >>> Doru >>> >>> -- >>> www.tudorgirba.com >>> >>> "Value is always contextual." >>> >>> >>> >>> >> >> > > -- > www.tudorgirba.com > > "It's not how it is, it is how we see it." > >

Sept. 7, 2011

[Pharo-project] 64 bit

by Milan Mimica

Hello list! I was wondering, are you going to provide a 64-bit OneClick package any time soon? When and what does that depend on? If not, how do I go about building my own 64-bit image on linux? -- Milan Mimica http://sparklet.sf.net

Sept. 7, 2011