April 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Monticello/ftp stopped working for me

by Cameron Sanders

Maybe I'm just sleep deprived... but, the method isUnconnected looks odd. Perhaps it is correct, and there is a good reason for the implementation, but "socketHandle == nil ifTrue: [^false ]" seems counter-intuitive. If socketHandle is not defined, then, it seems, we probably not connected... and hence should answer true. My apologies if I am not thinking clearly... or if it is simply more complex handle management. Socket >> isUnconnected "Return true if this socket's state is Unconnected." socketHandle == nil ifTrue: [^ false]. ^ (self primSocketConnectionStatus: socketHandle) == Unconnected -Cam On Apr 29, 2009, at 5:00 PM, Alexandre Bergel wrote: > Does not work for me. The problem is probably different. I still get a > 'Socket status must Unconnected before opening a new connection' > Per

April 30, 2009

Re: [Pharo-project] run all tests from superClass

by Miguel Enrique CobÃ¡ MartÃnez

Hernan Wilkinson wrote: > I don't think it is a good idea to have hierarchies with test cases... > depending on how you are doing it, it could couple the test hierarchy > with the model hierarchy and I don't think that is a good idea... > It also introduces some complexity, for example the number of tests are > not only the test methods but for each concrete test class, the test > methods on it plus the test methods of the abstract superclasses... hmmm > I don't know, it is not natural at least for me too user inheritance > with tests... +1 Besides, one of the goals of the testing is to test "external behavior" of the classes. This means, to me, that the test cases must test the classes without knowing if B inherits from A o if both B and C are subclasses of A. This way, when you for some reason must refactor or reorganize your classes, the test will not break as long as the external behavior of them remains unchanged. Summary, the inheritance of the classes tested is just an implementation detail, not something the test cases must care of. Cheers, Miguel CobÃ¡ > > On Wed, Apr 29, 2009 at 4:46 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> wrote: > > HI guys > > I was coding this afternoon with Cyrille who is working a lot to > improve the test coverage of collections. > And we found a bit strange that when a testcase inherits from another > one the tests of the superclass are not run. > I checked a bit SUnit code and superclass testmethods are only run is > the superclass is abstract or if there are not testmethods. > Imagine > BagTest > IdentityBagTest > > > We could redefine buildSuite on BagTest to invoke allSelectors > but this means in essence that we could do it on a lot of potential > testcase classes that may be subclasses. > > Or we could redefine buildSuite on IdentyBagTest but this means that > the subclasses should specify it. > May be this solution is the best but I wanted to get your thoughts. > > Of course this idea of inheriting test case make sense when superclass > setup can be reused in subclasses one. > So the default behavior of buildSuite always invoking all testmethods > may not be so good but then > via subclassing from BagTest if this is not to reuse it. > > Stef > > > On Apr 29, 2009, at 6:04 PM, Cyrille Delaunay wrote: > > > A change have been saved in 'PharoInBox' for class TestCase in > > package SUnit > > so that suite are now built from allSelectors. > > This makes sense when you have testcase classes which inherits from > > each other and have parametrized (hook-based) setup. > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > <mailto:Pharo-project@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 > <mailto:Pharo-project@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

April 30, 2009

Re: [Pharo-project] run all tests from superClass

by Mariano Martinez Peck

On Wed, Apr 29, 2009 at 7:09 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > There is already such a switch that can be overridden in TestCase > class>>#shouldInheritSelectors. > That's true. There was a discussion in squeak-dev. Here: http://thread.gmane.org/gmane.comp.lang.smalltalk.squeak.general/132946/foc… greetings mariano > > Lukas > > On Wed, Apr 29, 2009 at 10:03 PM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > Maybe add a switch > > runSuperTests > > "Tells whether test from superclass should be run. > > By default, this is true. > > If you don't want to run superclass tests, redefine this as false > > in your subclass." > > > > ^true > > > > 2009/4/29 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > >> HI guys > >> > >> I was coding this afternoon with Cyrille who is working a lot to > >> improve the test coverage of collections. > >> And we found a bit strange that when a testcase inherits from another > >> one the tests of the superclass are not run. > >> I checked a bit SUnit code and superclass testmethods are only run is > >> the superclass is abstract or if there are not testmethods. > >> Imagine > >> BagTest > >> IdentityBagTest > >> > >> > >> We could redefine buildSuite on BagTest to invoke allSelectors > >> but this means in essence that we could do it on a lot of potential > >> testcase classes that may be subclasses. > >> > >> Or we could redefine buildSuite on IdentyBagTest but this means that > >> the subclasses should specify it. > >> May be this solution is the best but I wanted to get your thoughts. > >> > >> Of course this idea of inheriting test case make sense when superclass > >> setup can be reused in subclasses one. > >> So the default behavior of buildSuite always invoking all testmethods > >> may not be so good but then > >> via subclassing from BagTest if this is not to reuse it. > >> > >> Stef > >> > >> > >> On Apr 29, 2009, at 6:04 PM, Cyrille Delaunay wrote: > >> > >>> A change have been saved in 'PharoInBox' for class TestCase in > >>> package SUnit > >>> so that suite are now built from allSelectors. > >>> This makes sense when you have testcase classes which inherits from > >>> each other and have parametrized (hook-based) setup. > >>> > >>> > >>> _______________________________________________ > >>> 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 > >> > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 29, 2009

Re: [Pharo-project] run all tests from superClass

by Lukas Renggli

There is already such a switch that can be overridden in TestCase class>>#shouldInheritSelectors. Lukas On Wed, Apr 29, 2009 at 10:03 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Maybe add a switch > runSuperTests > Â Â "Tells whether test from superclass should be run. > Â Â By default, this is true. > Â Â If you don't want to run superclass tests, redefine this as false > in your subclass." > > Â Â ^true > > 2009/4/29 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> HI guys >> >> I was coding this afternoon with Cyrille who is working a lot to >> improve the test coverage of collections. >> And we found a bit strange that when a testcase inherits from another >> one the tests of the superclass are not run. >> I checked a bit SUnit code and superclass testmethods are only run is >> the superclass is abstract or if there are not testmethods. >> Imagine >> Â Â Â Â BagTest >> Â Â Â Â Â Â Â Â IdentityBagTest >> >> >> We could redefine buildSuite on BagTest to invoke allSelectors >> but this means in essence that we could do it on a lot of potential >> testcase classes that may be subclasses. >> >> Or we could redefine buildSuite on IdentyBagTest but this means that >> the subclasses should specify it. >> May be this solution is the best but I wanted to get your thoughts. >> >> Of course this idea of inheriting test case make sense when superclass >> setup can be reused in subclasses one. >> So the default behavior of buildSuite always invoking all testmethods >> may not be so good but then >> via subclassing from BagTest if this is not to reuse it. >> >> Stef >> >> >> On Apr 29, 2009, at 6:04 PM, Cyrille Delaunay wrote: >> >>> A change have been saved in 'PharoInBox' for class TestCase in >>> package SUnit >>> so that suite are now built from allSelectors. >>> This makes sense when you have testcase classes which inherits from >>> each other and have parametrized (hook-based) setup. >>> >>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

April 29, 2009

Re: [Pharo-project] [FIX] Issue 782: OB is ambiguous when asking to Accept or Discard changes in the code panel

by Mariano Martinez Peck

2009/4/29 Hernan Wilkinson <hernan.wilkinson(a)gmail.com> > ups... another question then... where is a list of core pharo packages?I > saw there is a pharo-core image and a pharo (or pharo-dev) image. I could > not find the pharo-core image, the one in the download page is the pharo-dev > image. > In pharo webpage where it says "archive and more...". It is a link to this: http://gforge.inria.fr/frs/?group_id=1299 There are all the images. saludos mariano > > Thanks > Hernan. > > > On Wed, Apr 29, 2009 at 2:22 PM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> However, I see this is related to OB. >> It's not really a package of the core pharo, but rather an external >> one included in Damien development images. >> Such external package has its own maintainer and is not maintained by >> pharo team. >> You should post to the appropriate code repository and mailing list... >> (a good soul in this list will have to tell you which one, because I >> don't know it) >> >> Cheers >> >> 2009/4/29 Hernan Wilkinson <hernan.wilkinson(a)gmail.com>: >> > ok then, no problem. >> > BTW, I'd like somebody to look at the fix I made because I'm not sure >> that >> > is the right way to doit. I mean, it is rare how the exception is >> related to >> > the dialog box. I think it is done that way because the handler of the >> > notification could not show a dialog... but if that is the idea then I >> think >> > something is missing to relate the cancel option of the notification >> with >> > the cancel button of the dialog. >> > >> > On Wed, Apr 29, 2009 at 12:39 PM, Nicolas Cellier >> > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> >> >> Not annoying at all. Please do. >> >> >> >> 2009/4/29 Hernan Wilkinson <hernan.wilkinson(a)gmail.com>: >> >> > Another fix... >> >> > (Do I have to send a mail to the list per fix? the how to contribute >> >> > page >> >> > says so but it can be annoying...) >> >> > Hernan. >> >> > _______________________________________________ >> >> > 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 >> > >> > >> > _______________________________________________ >> > 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 >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 29, 2009

Re: [Pharo-project] run all tests from superClass

by Hernan Wilkinson

I don't think it is a good idea to have hierarchies with test cases... depending on how you are doing it, it could couple the test hierarchy with the model hierarchy and I don't think that is a good idea...It also introduces some complexity, for example the number of tests are not only the test methods but for each concrete test class, the test methods on it plus the test methods of the abstract superclasses... hmmm I don't know, it is not natural at least for me too user inheritance with tests... On Wed, Apr 29, 2009 at 4:46 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > HI guys > > I was coding this afternoon with Cyrille who is working a lot to > improve the test coverage of collections. > And we found a bit strange that when a testcase inherits from another > one the tests of the superclass are not run. > I checked a bit SUnit code and superclass testmethods are only run is > the superclass is abstract or if there are not testmethods. > Imagine > BagTest > IdentityBagTest > > > We could redefine buildSuite on BagTest to invoke allSelectors > but this means in essence that we could do it on a lot of potential > testcase classes that may be subclasses. > > Or we could redefine buildSuite on IdentyBagTest but this means that > the subclasses should specify it. > May be this solution is the best but I wanted to get your thoughts. > > Of course this idea of inheriting test case make sense when superclass > setup can be reused in subclasses one. > So the default behavior of buildSuite always invoking all testmethods > may not be so good but then > via subclassing from BagTest if this is not to reuse it. > > Stef > > > On Apr 29, 2009, at 6:04 PM, Cyrille Delaunay wrote: > > > A change have been saved in 'PharoInBox' for class TestCase in > > package SUnit > > so that suite are now built from allSelectors. > > This makes sense when you have testcase classes which inherits from > > each other and have parametrized (hook-based) setup. > > > > > > _______________________________________________ > > 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 >

April 29, 2009

Re: [Pharo-project] Socket problems

by John M McIntosh

Ok, let's see if we can get a grip on what is going on. what I did was in sqSocketCreateNetTypeSocketTypeRecvBytesSendBytesSemaIDReadSemaIDWriteSemaID after the socket() call and at the check for socket value = -1, I always fail the primitive call. This mimics what happens when you run out of socket handles. In this case since we never recover then it should result in a hard failure because the socket table is full. I put a break point in to understand where we are, and a breakpoint at the full GC. What I see is the first call, where we fail. current pharo, closure based, macintosh vm 4.1.1b2 Process 557974616 Socket>initialize:family: 557974524 >newTCP: 557974308 BlockClosure>repeatWithGCIf: 557974216 >newTCP: 557974124 >newTCP 557973968 >new 557652968 >sendTest 557652876 >? 557649476 Compiler>evaluate:in:to:notifying:ifFail:logged: 557649384 ParagraphEditor>evaluateSelection 557649228 BlockClosure>on:do: 557649136 ParagraphEditor>evaluateSelection 557649024 ParagraphEditor>doIt The second call I note the full GC hasn't happened yet, so the code is invoking create new socket again before the GC call, which *IS* rather pointless. I wonder why the second call happens before the GC? Process 557976760 Socket > primSocketCreateNetwork:type:receiveBufferSize:sendBufSize:semaIndex:readSemaIndex:writeSemaIndex : 557974616 Socket>initialize:family: 557974524 >newTCP: 557974308 BlockClosure>repeatWithGCIf: 557974216 >newTCP: 557974124 >newTCP 557973968 >new 557652968 >sendTest 557652876 >? 557649476 Compiler>evaluate:in:to:notifying:ifFail:logged: 557649384 ParagraphEditor>evaluateSelection 557649228 BlockClosure>on:do: 557649136 ParagraphEditor>evaluateSelection 557649024 ParagraphEditor>doIt then we see the full GC which has the intent of cleaning out zombies so that those sockets can be returned to the operating system. Process 557683240 SystemDictionary>garbageCollect 557683044 BlockClosure>repeatWithGCIf: 557682952 >newTCP: 557682860 >newTCP 557682768 >new 557652968 >sendTest 557652876 >? 557649476 Compiler>evaluate:in:to:notifying:ifFail:logged: 557649384 ParagraphEditor>evaluateSelection 557649228 BlockClosure>on:do: 557649136 ParagraphEditor>evaluateSelection 557649024 ParagraphEditor>doIt then again Process 556761248 Socket>initialize:family: 556719648 >newTCP: 556692112 BlockClosure>repeatWithGCIf: 556692020 >newTCP: 556691928 >newTCP 556691836 >new 556662076 >sendTest 556661984 >? 556658584 Compiler>evaluate:in:to:notifying:ifFail:logged: 556658492 ParagraphEditor>evaluateSelection 556658336 BlockClosure>on:do: 556658244 ParagraphEditor>evaluateSelection 556658132 ParagraphEditor>doIt and again, which seems rather pointless. Process 556763348 Socket > primSocketCreateNetwork:type:receiveBufferSize:sendBufSize:semaIndex:readSemaIndex:writeSemaIndex : 556761248 Socket>initialize:family: 556719648 >newTCP: 556692112 BlockClosure>repeatWithGCIf: 556692020 >newTCP: 556691928 >newTCP 556691836 >new 556662076 >sendTest 556661984 >? 556658584 Compiler>evaluate:in:to:notifying:ifFail:logged: 5566584\92 ParagraphEditor>evaluateSelection 556658336 BlockClosure>on:do: 556658244 ParagraphEditor>evaluateSelection 556658132 ParagraphEditor>doIt Then the walkback pops up. Obviously should the code try to make the socket 4 times? versus say twice? Socket>>connectNonBlockingTo: Receiver: a Socket[destroyed] Arguments and temporary variables: aSocketAddress: 128.111.221.123(pulse),9(discard) status: -1 Receiver's instance variables: semaphore: nil socketHandle: nil readSemaphore: nil writeSemaphore: nil primitiveOnlySupportsOneSemaphore: true Socket>>connectTo:waitForConnectionFor: Receiver: a Socket[destroyed] Arguments and temporary variables: aSocketAddress: 128.111.221.123(pulse),9(discard) timeout: 45 Receiver's instance variables: semaphore: nil socketHandle: nil readSemaphore: nil writeSemaphore: nil primitiveOnlySupportsOneSemaphore: true Socket>>connectTo: Receiver: a Socket[destroyed] Arguments and temporary variables: aSocketAddress: 128.111.221.123(pulse),9(discard) Receiver's instance variables: semaphore: nil socketHandle: nil readSemaphore: nil writeSemaphore: nil primitiveOnlySupportsOneSemaphore: true Socket>>connectTo:port: Receiver: a Socket[destroyed] Arguments and temporary variables: hostAddress: 128.111.221.123(pulse),9(discard) port: 9 Receiver's instance variables: semaphore: nil socketHandle: nil readSemaphore: nil writeSemaphore: nil primitiveOnlySupportsOneSemaphore: true Socket class>>sendTest Receiver: Socket Arguments and temporary variables: sock: a Socket[destroyed] bytesToSend: nil sendBuf: nil t: nil serverName: 'create.ucsb.edu' serverAddr: 128.111.221.123(pulse),9(discard) bytesSent: #(nil) Receiver's instance variables: superclass: Object methodDict: a MethodDictionary(size 137) format: 140 instanceVariables: #('semaphore' 'socketHandle' 'readSemaphore' 'writeSemaphore...etc... organization: ('accessing' address localAddress localPort peerName port primiti...etc... subclasses: {SocksSocket . HTTPSocket . RFBSocket} name: #Socket classPool: a Dictionary(#Connected->2 #DeadServer- >'update.squeakfoundation.org...etc... sharedPools: nil environment: Smalltalk category: #'Network-Kernel' traitComposition: {} localSelectors: nil Socket class>>DoIt Receiver: Socket Arguments and temporary variables: Receiver's instance variables: superclass: Object methodDict: a MethodDictionary(size 137) format: 140 instanceVariables: #('semaphore' 'socketHandle' 'readSemaphore' 'writeSemaphore...etc... organization: ('accessing' address localAddress localPort peerName port primiti...etc... subclasses: {SocksSocket . HTTPSocket . RFBSocket} name: #Socket classPool: a Dictionary(#Connected->2 #DeadServer- >'update.squeakfoundation.org...etc... sharedPools: nil environment: Smalltalk category: #'Network-Kernel' traitComposition: {} localSelectors: nil For cross check let's look at what happens before the closure code. pre closure work in a pharo0.1-10211dev09.01.3.image (gdb) call (int) printAllStacks() Process 545073376 Socket>initialize: 545073560 [] in >newTCP 545073284 BlockContext>repeatWithGCIf: 545072904 >newTCP 545072812 >new 544992420 >sendTest 544992328 >? 544989336 Compiler>evaluate:in:to:notifying:ifFail:logged: 544989004 [] in ParagraphEditor>evaluateSelection 544988912 BlockContext>on:do: 544988664 ParagraphEditor>evaluateSelection 544988572 ParagraphEditor>doIt again 545075672 Socket > primSocketCreateNetwork:type:receiveBufferSize:sendBufSize:semaIndex:readSemaIndex:writeSemaIndex : 545073376 Socket>initialize: 545073560 [] in >newTCP 545073284 BlockContext>repeatWithGCIf: 545072904 >newTCP 545072812 >new 544992420 >sendTest 544992328 >? 544989336 Compiler>evaluate:in:to:notifying:ifFail:logged: 544989004 [] in ParagraphEditor>evaluateSelection 544988912 BlockContext>on:do: 544988664 ParagraphEditor>evaluateSelection 544988572 ParagraphEditor>doIt fullGC happens. Process 545024744 SystemDictionary>garbageCollect 545024440 BlockContext>repeatWithGCIf: 545024336 >newTCP 545024244 >new 544992420 >sendTest 544992328 >? 544989336 Compiler>evaluate:in:to:notifying:ifFail:logged: 544989004 [] in ParagraphEditor>evaluateSelection 544988912 BlockContext>on:do: 544988664 ParagraphEditor>evaluateSelection 544988572 ParagraphEditor>doIt off we go again to create socket. Process 543469672 Socket>initialize: 543447120 [] in >newTCP 543447028 BlockContext>repeatWithGCIf: 543446924 >newTCP 543446832 >new 543438208 >sendTest 543438116 >? 543435124 Compiler>evaluate:in:to:notifying:ifFail:logged: 543434792 [] in ParagraphEditor>evaluateSelection 543434700 BlockContext>on:do: 543434452 ParagraphEditor>evaluateSelection 543434360 ParagraphEditor>doIt off we go again to create socket. Process 543471784 Socket > primSocketCreateNetwork:type:receiveBufferSize:sendBufSize:semaIndex:readSemaIndex:writeSemaIndex : 543469672 Socket>initialize: 543447120 [] in >newTCP 543447028 BlockContext>repeatWithGCIf: 543446924 >newTCP 543446832 >new 543438208 >sendTest 543438116 >? 543435124 Compiler>evaluate:in:to:notifying:ifFail:logged: 543434792 [] in ParagraphEditor>evaluateSelection 543434700 BlockContext>on:do: 543434452 ParagraphEditor>evaluateSelection 543434360 ParagraphEditor>doIt and end up with walkback at. Socket status must Unconnected before opening a new connection connectNonBlockingTo: hostAddress port: port "Initiate a connection to the given port at the given host address. This operation will return immediately; follow it with waitForConnectionUntil: to wait until the connection is established." | status | self initializeNetwork. status := self primSocketConnectionStatus: socketHandle. (status == Unconnected) ifFalse: [InvalidSocketStatusException signal: 'Socket status must Unconnected before opening a new connection']. = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

April 29, 2009

Re: [Pharo-project] [FIX] Issue 782: OB is ambiguous when asking to Accept or Discard changes in the code panel

by Hernan Wilkinson

ups... another question then... where is a list of core pharo packages?I saw there is a pharo-core image and a pharo (or pharo-dev) image. I could not find the pharo-core image, the one in the download page is the pharo-dev image. Thanks Hernan. On Wed, Apr 29, 2009 at 2:22 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > However, I see this is related to OB. > It's not really a package of the core pharo, but rather an external > one included in Damien development images. > Such external package has its own maintainer and is not maintained by > pharo team. > You should post to the appropriate code repository and mailing list... > (a good soul in this list will have to tell you which one, because I > don't know it) > > Cheers > > 2009/4/29 Hernan Wilkinson <hernan.wilkinson(a)gmail.com>: > > ok then, no problem. > > BTW, I'd like somebody to look at the fix I made because I'm not sure > that > > is the right way to doit. I mean, it is rare how the exception is related > to > > the dialog box. I think it is done that way because the handler of the > > notification could not show a dialog... but if that is the idea then I > think > > something is missing to relate the cancel option of the notification with > > the cancel button of the dialog. > > > > On Wed, Apr 29, 2009 at 12:39 PM, Nicolas Cellier > > <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> > >> Not annoying at all. Please do. > >> > >> 2009/4/29 Hernan Wilkinson <hernan.wilkinson(a)gmail.com>: > >> > Another fix... > >> > (Do I have to send a mail to the list per fix? the how to contribute > >> > page > >> > says so but it can be annoying...) > >> > Hernan. > >> > _______________________________________________ > >> > 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 > > > > > > _______________________________________________ > > 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 >

April 29, 2009

Re: [Pharo-project] First contribution...

by Hernan Wilkinson

ups!, I did not know it was a monticello repository... :-) On Wed, Apr 29, 2009 at 6:05 PM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > In a Monticello browser, if you select OB-Standard on the left hand > side pane, you should see the wiresong repository on the right hand > side. Just select it and press 'save'. > > Alexandre > > > On 29 Apr 2009, at 22:55, Hernan Wilkinson wrote: > > > Thanks Alex. > > How do I save it on source.wiresong.ca/ob ? > > > > On Wed, Apr 29, 2009 at 2:52 PM, Alexandre Bergel > > <alexandre(a)bergel.eu> wrote: > > Hi Hernan, > > > > I read your change and it makes fully sense. However, I suggest you to > > save it on source.wiresong.ca/ob. > > I think it was agreed that only core packages must be committed in > > PharoInbox. > > > > Probably the test on the website should be adjusted. Shall I do it? > > > > Cheers, > > Alexandre > > > > On 29 Apr 2009, at 15:58, Hernan Wilkinson wrote: > > > > > Hi, > > > I just made my first contribution!! (not a big deal, just a small > > > fix anyway...), but I feel kind of stupid because I can not change > > > the issues's status from new to fixed... (as the "how to contribute > > > page" says). Could somebody tell me how? The issue is the 781 > > > > > > Thanks, > > > Hernan. > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > _______________________________________________ > > 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 > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 29, 2009

Re: [Pharo-project] First contribution...

by Hernan Wilkinson

oh, ok. I'll doit. Thanks. On Wed, Apr 29, 2009 at 5:59 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Hi Hernan, > > On Apr 29, 2009, at 22:53 , Hernan Wilkinson wrote: > > > On Wed, Apr 29, 2009 at 4:49 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr > >> wrote: > > > >> Welcome hernan :) > >> if you plan (which I hope) to contribute to pharo please sign the > >> license agreement available on the wiki. > > > > > > I tried but I did not know how to do it... do I just post my name in > > "Comments"? > > not really ;) > > You can find the document here: > http://pharo.gforge.inria.fr/licenseDocuments/ > The idea is to print it, sign it, and then mail it to Stef. > > Adrian > > > > > > >> > >> > >> > >>> Hi, > >>> I just made my first contribution!! (not a big deal, just a small > >>> fix anyway...), but I feel kind of stupid because I can not change > >>> the issues's status from new to fixed... (as the "how to contribute > >>> page" says). Could somebody tell me how? The issue is the 781 > >>> > >>> Thanks, > >>> Hernan. > >>> _______________________________________________ > >>> 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 > >> > > _______________________________________________ > > 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 >

April 29, 2009