- Pharo-dev - lists.pharo.org

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

by Michael Roberts

if you could select different rendering of that area that would be nice (e.g on context menu). i would add an option to display it in a table widget. it could allow simple filtering & sorting etc, assuming we had such a widget (essential really) . that would allow compact but powerful slicing of the data presented... cheers, Mike On Wed, Sep 7, 2011 at 7:30 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Looks good! > Now that you're into it, maybe coloring the frames that are not "interesting" would be a valuable addition. For example, putting in light gray all the frame that belong to Kernel and Collection, since it is unlikely that one will ever be interested in those. > > Cheers, > Alexandre > > > On 7 Sep 2011, at 13:09, 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 >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel Â http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > >

Sept. 7, 2011

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

by laurent laffont

On Wed, Sep 7, 2011 at 9:45 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > > On Sep 7, 2011, at 9:32 PM, laurent laffont wrote: > > > On Wed, Sep 7, 2011 at 9:04 PM, Sven Van Caekenberghe <sven(a)beta9.be> > wrote: > > Hi Laurent, > > > > On 07 Sep 2011, at 20:24, laurent.laffont(a)gmail.com wrote: > > > > > here insert explanation of what you were doing, suspect changes you've > > > made and so forth. > > > > > > Haha I haven't seen the mail will go the list :) First time I use the > mail out function. > > > > Anyway some explanations because this has corrupted my image. > > > > On SmallHarbour we use a modified VM (only SecurityPlugin - > https://gitorious.org/~laurentlaffont/cogvm/smallharbour ) so an image > can open only a given set of ports. Each image / account has an allocated > port number, so when an image starts a .st file is given as argument which > stop all seaside adaptors and then start Zinc Seaside adaptor on a given > port. > > > > The problem is: if I have saved a image with a socket opened on port XX, > then try to start it on SmallHarbour on port YY - given that XX is forbidden > - image crashes. > > It would be good that it does not crash :) > do not mean crash or shutdown nicely. > I mean if you are not in headless does it crash? > Yes it crashes only in headless mode - the (not so?) funny thing is that daemontools restart it immediately, then crash, restart, crash, restart .... huge PharoDebug.log :) With display the debugger pops up with the stack trace that was sent. Laurent > > > > > > > What were you doing ? > > Is this something reproduceable ? > > > > Yes. > > > > > > Is this in a standard 1.3 or did you somehow upgrade Zn to the latest > version ? > > > > It's a 3 weeks old Pier 2 image from Lukas Jenkins server so I first want > to get latest one and check if the problem is still here. > > > > > > Doing so might help (the primitive failed on close, flush is now > swallowed). > > > > > > OK thanks. > > > > Laurent. > > > > > > Sven > > > > > > > > > > >

Sept. 7, 2011

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

by StÃ©phane Ducasse

On Sep 7, 2011, at 9:32 PM, laurent laffont wrote: > On Wed, Sep 7, 2011 at 9:04 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > Hi Laurent, > > On 07 Sep 2011, at 20:24, laurent.laffont(a)gmail.com wrote: > > > here insert explanation of what you were doing, suspect changes you've > > made and so forth. > > > Haha I haven't seen the mail will go the list :) First time I use the mail out function. > > Anyway some explanations because this has corrupted my image. > > On SmallHarbour we use a modified VM (only SecurityPlugin - https://gitorious.org/~laurentlaffont/cogvm/smallharbour ) so an image can open only a given set of ports. Each image / account has an allocated port number, so when an image starts a .st file is given as argument which stop all seaside adaptors and then start Zinc Seaside adaptor on a given port. > > The problem is: if I have saved a image with a socket opened on port XX, then try to start it on SmallHarbour on port YY - given that XX is forbidden - image crashes. It would be good that it does not crash :) do not mean crash or shutdown nicely. I mean if you are not in headless does it crash? > > > What were you doing ? > Is this something reproduceable ? > > Yes. > > > Is this in a standard 1.3 or did you somehow upgrade Zn to the latest version ? > > It's a 3 weeks old Pier 2 image from Lukas Jenkins server so I first want to get latest one and check if the problem is still here. > > > Doing so might help (the primitive failed on close, flush is now swallowed). > > > OK thanks. > > Laurent. > > > Sven > > > >

Sept. 7, 2011

Re: [Pharo-project] [COTDC] 80#3 - TestRunnerBrowser

by laurent laffont

Today: TestRunnerBrowser Laurent On Tue, Sep 6, 2011 at 7:59 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > > Today: RBSubclassOfClassToRename > > Laurent > > > On Mon, Sep 5, 2011 at 9:55 PM, laurent laffont <laurent.laffont(a)gmail.com > > wrote: > >> Today: CategoryEnvironment >> >> >> Comment Of The Day Contest - One Day One Comment >> Rules: >> #1: Each day a not commented class is elected. Each day the best comment >> will be integrated with name of the author(s). >> #2: If you cannot comment it, deprecate it. >> Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest >> >> Laurent >> > > >

Sept. 7, 2011

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

by laurent laffont

On Wed, Sep 7, 2011 at 9:04 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > Hi Laurent, > > On 07 Sep 2011, at 20:24, laurent.laffont(a)gmail.com wrote: > > > here insert explanation of what you were doing, suspect changes you've > > made and so forth. > > Haha I haven't seen the mail will go the list :) First time I use the mail out function. Anyway some explanations because this has corrupted my image. On SmallHarbour we use a modified VM (only SecurityPlugin - https://gitorious.org/~laurentlaffont/cogvm/smallharbour ) so an image can open only a given set of ports. Each image / account has an allocated port number, so when an image starts a .st file is given as argument which stop all seaside adaptors and then start Zinc Seaside adaptor on a given port. The problem is: if I have saved a image with a socket opened on port XX, then try to start it on SmallHarbour on port YY - given that XX is forbidden - image crashes. What were you doing ? > Is this something reproduceable ? > Yes. > > Is this in a standard 1.3 or did you somehow upgrade Zn to the latest > version ? > It's a 3 weeks old Pier 2 image from Lukas Jenkins server so I first want to get latest one and check if the problem is still here. Doing so might help (the primitive failed on close, flush is now swallowed). > > OK thanks. Laurent. > Sven > > > >

Sept. 7, 2011

[Pharo-project] About at: in diplayProgress bar and multiLineRequest: queryString centerAt: aPoint initialAnswer: defaultAnswer answerHeight: answerHeight

by StÃ©phane Ducasse

Hi guys we will deprecate the usage of a location in progress bar and multiLineRequest: queryString centerAt: aPoint initialAnswer: defaultAnswer answerHeight: answerHeight because: - it is not really good that tools have to make reference to Sensor (which we should avoid and we will chase reference to Sensor) or to World activeHand cursorPosition and let the UIManager decides where to place the widgets - apparently multiLineRequest: queryString centerAt: aPoint initialAnswer: defaultAnswer answerHeight: answerHeight does not use the argument of centerAt: Let me know what you think. Such change will help clarifying layers. Stef

Sept. 7, 2011

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

by Sven Van Caekenberghe

Hi Laurent, On 07 Sep 2011, at 20:24, laurent.laffont(a)gmail.com wrote: > here insert explanation of what you were doing, suspect changes you've > made and so forth. What were you doing ? Is this something reproduceable ? Is this in a standard 1.3 or did you somehow upgrade Zn to the latest version ? Doing so might help (the primitive failed on close, flush is now swallowed). Sven

Sept. 7, 2011

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

by Alexandre Bergel

Looks good! Now that you're into it, maybe coloring the frames that are not "interesting" would be a valuable addition. For example, putting in light gray all the frame that belong to Kernel and Collection, since it is unlikely that one will ever be interested in those. Cheers, Alexandre On 7 Sep 2011, at 13:09, 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 7, 2011

[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