February 2016 - Pharo-dev - lists.pharo.org

50603 highlighting broken

by Nicolai Hess

in pharo 50603, if you open a sendersOf MessageBrowser, the first selected methods code is not or wrongly highlightey (all red). You have to change the selected item to get the right result!

Feb. 23, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50603 Home: https://github.com/pharo-project/pharo-core

Feb. 23, 2016

[pharo-project/pharo-core] a8609c: 50603

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: a8609c784255b249c46006004e78a224022e4e8d https://github.com/pharo-project/pharo-core/commit/a8609c784255b249c4600600… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-02-23 (Tue, 23 Feb 2016) Changed paths: R Deprecated50.package/extension/SmalltalkImage/instance/addToShutDownList_.st R Deprecated50.package/extension/SmalltalkImage/instance/addToStartUpList_.st M SUnit-UITesting.package/SimulateKeystrokesSpecification.class/instance/tests/testSimulateCmdKeystroke.st M SUnit-UITesting.package/SimulateMouseSpecification.class/instance/tests/testSimulateRightClick.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50602.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50603.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50602.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50603.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A System-Support.package/SmalltalkImage.class/instance/startup - shutdown/addToShutDownList_.st A System-Support.package/SmalltalkImage.class/instance/startup - shutdown/addToStartUpList_.st Log Message: ----------- 50603 17676 Building Pharo-5.0-Issue-Tracker-Image fails!! https://pharo.fogbugz.com/f/cases/17676 16534 SimulateMouseSpecification broken https://pharo.fogbugz.com/f/cases/16534 http://files.pharo.org/image/50/50603.zip

Feb. 23, 2016

Re: [Pharo-dev] [Bloc] Do we want <return: #Point> or <return: Point>

by Esteban Lorenzano

> On 23 Feb 2016, at 13:57, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 23 Feb 2016, at 13:43, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >>> On Feb 23, 2016, at 1:24 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> >>>> On 23 Feb 2016, at 13:20, Alain Plantec via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: >>>> >>>> >>>> From: Alain Plantec <alain.plantec(a)yahoo.com> >>>> Subject: Re: [Pharo-dev] [Bloc] Do we want <return: #Point> or <return: Point> >>>> Date: 23 February 2016 at 13:19:34 GMT+1 >>>> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >>>> >>>> >>>> Hello Doru, >>>> >>>>> On 23 Feb 2016, at 10:33, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>>> >>>>> Hi, >>>>> >>>>> At the moment, it is used for documentation purposes in Bloc. It is part of the effort of Alex to document Bloc thoroughly. I think it is an interesting idea, in that we would have a significant case study for that can be used later as optional types information to improve static tool support. And it does not hurt at the moment. >>>>> >>>>> What do you think? >>>> >>>> Experimenting optional types is a good idea. We could have Tools to dynamically check them. >>>> What about a separate typing model that could be used to add/remove the types annotations ? >>>> Also, I wonder if Bloc is the good package to experiment optional types. Maybe it is not stable enough. >>>> Cheers >>>> Alain >>> >>> please, please, please keep the scope of those experiments aside the main effort who is to have Block/Brick running as soon as possible. >>> >>> Esteban >>> >>> ps: â¦ optional typesâ¦ at the end, we will realise Gilad was right all this time :) >> >> I think there is a misunderstanding. >> >> The current annotations are there for documentation purposes. Given that Alex did an extensive pass to document Bloc, they should remain in place as they document the contracts. Documentation like this is something we should embrace for such a central piece. >> >> That this also provides the information for a potential optional types experiment itâs a different issue, and it would not affect at all the implementation of Bloc. > > I understand why it is done in the context of documentation, and I am all for good documentation. > > But it really is a dangerous road to start on. It sends a weird signal, as if it is better to start adding static typing information. > > The next step will be that someone suggests to start adding the same kind of annotation typing information to all arguments, next all instance variable, it can't hurt right ? Then we write tools to use that information, then we start requiring it, next we have Java with tons of boiler plate code for nothing. +1 > >> Cheers, >> Doru >> >>>> >>>> >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>>> On Feb 23, 2016, at 10:25 AM, Alain Plantec via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: >>>>>> >>>>>> >>>>>> From: Alain Plantec <alain.plantec(a)yahoo.com> >>>>>> Subject: Re: [Pharo-dev] [Bloc] Do we want <return: #Point> or <return: Point> >>>>>> Date: February 23, 2016 at 10:23:33 AM GMT+1 >>>>>> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >>>>>> >>>>>> >>>>>> I donât like it too. >>>>>> Alain >>>>>> >>>>>>> Le 23 fÃ©vr. 2016 Ã 09:50, Nicolai Hess <nicolaihess(a)gmail.com> a Ã©crit : >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2016-02-23 9:47 GMT+01:00 stepharo <stepharo(a)free.fr>: >>>>>>> Hi >>>>>>> >>>>>>> I saw that something <return: #Point> or <return: Point> >>>>>>> I do not know why but I have the impression that <return: #Point> is better. >>>>>>> Because we may have code not present and still want to load the code. >>>>>>> >>>>>>> I would like to know for what this is used. >>>>>>> I don't like it. >>>>>>> >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> www.feenk.com >>>>> >>>>> "We are all great at making mistakes." >>>> >>>> >>>> >>> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "If you interrupt the barber while he is cutting your hair, >> you will end up with a messy haircut."

Feb. 23, 2016

fork during debugging to auto spawn new debugger

by Ben Coman

Just a quick random thought before it gets away... It would be *nice* if when debugging and I step over a fork, the new process automatically halts at the start and spawns a new debugger. If its it was spawned at a higher priority, I could immediately move to the new debugger and step through before returning the original debugger. This would help a lot when stepping through unit tests that to test exotic corner cases are sometimes needfully convoluted about which order the processes run. Maybe if somehow a Process new it was being debugged and the new process inherited that state. cheers -ben

Feb. 23, 2016

Re: [Pharo-dev] fully self-contained Linux VM

by Stephan Eggermont

On 23-02-16 13:35, Peter UhnÃ¡k wrote: > Could something like that be done also for the remaining lib32 libraries > required to run the VM? Sure. And then you need to release updates whenever one of the underlying lib32 libraries changes. OpenSSL comes to mind. Stephan

Feb. 23, 2016

Re: [Pharo-dev] [Bloc] Do we want <return: #Point> or <return: Point>

by Sven Van Caekenberghe

> On 23 Feb 2016, at 13:43, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > >> On Feb 23, 2016, at 1:24 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> >>> On 23 Feb 2016, at 13:20, Alain Plantec via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: >>> >>> >>> From: Alain Plantec <alain.plantec(a)yahoo.com> >>> Subject: Re: [Pharo-dev] [Bloc] Do we want <return: #Point> or <return: Point> >>> Date: 23 February 2016 at 13:19:34 GMT+1 >>> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >>> >>> >>> Hello Doru, >>> >>>> On 23 Feb 2016, at 10:33, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>> >>>> Hi, >>>> >>>> At the moment, it is used for documentation purposes in Bloc. It is part of the effort of Alex to document Bloc thoroughly. I think it is an interesting idea, in that we would have a significant case study for that can be used later as optional types information to improve static tool support. And it does not hurt at the moment. >>>> >>>> What do you think? >>> >>> Experimenting optional types is a good idea. We could have Tools to dynamically check them. >>> What about a separate typing model that could be used to add/remove the types annotations ? >>> Also, I wonder if Bloc is the good package to experiment optional types. Maybe it is not stable enough. >>> Cheers >>> Alain >> >> please, please, please keep the scope of those experiments aside the main effort who is to have Block/Brick running as soon as possible. >> >> Esteban >> >> ps: â¦ optional typesâ¦ at the end, we will realise Gilad was right all this time :) > > I think there is a misunderstanding. > > The current annotations are there for documentation purposes. Given that Alex did an extensive pass to document Bloc, they should remain in place as they document the contracts. Documentation like this is something we should embrace for such a central piece. > > That this also provides the information for a potential optional types experiment itâs a different issue, and it would not affect at all the implementation of Bloc. I understand why it is done in the context of documentation, and I am all for good documentation. But it really is a dangerous road to start on. It sends a weird signal, as if it is better to start adding static typing information. The next step will be that someone suggests to start adding the same kind of annotation typing information to all arguments, next all instance variable, it can't hurt right ? Then we write tools to use that information, then we start requiring it, next we have Java with tons of boiler plate code for nothing. > Cheers, > Doru > >>> >>> >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>>> On Feb 23, 2016, at 10:25 AM, Alain Plantec via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: >>>>> >>>>> >>>>> From: Alain Plantec <alain.plantec(a)yahoo.com> >>>>> Subject: Re: [Pharo-dev] [Bloc] Do we want <return: #Point> or <return: Point> >>>>> Date: February 23, 2016 at 10:23:33 AM GMT+1 >>>>> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >>>>> >>>>> >>>>> I donât like it too. >>>>> Alain >>>>> >>>>>> Le 23 fÃ©vr. 2016 Ã 09:50, Nicolai Hess <nicolaihess(a)gmail.com> a Ã©crit : >>>>>> >>>>>> >>>>>> >>>>>> 2016-02-23 9:47 GMT+01:00 stepharo <stepharo(a)free.fr>: >>>>>> Hi >>>>>> >>>>>> I saw that something <return: #Point> or <return: Point> >>>>>> I do not know why but I have the impression that <return: #Point> is better. >>>>>> Because we may have code not present and still want to load the code. >>>>>> >>>>>> I would like to know for what this is used. >>>>>> I don't like it. >>>>>> >>>>>> >>>>>> Stef >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> www.feenk.com >>>> >>>> "We are all great at making mistakes." >>> >>> >>> >> > > -- > www.tudorgirba.com > www.feenk.com > > "If you interrupt the barber while he is cutting your hair, > you will end up with a messy haircut."

Feb. 23, 2016

[pharo-project/pharo-core] d37c12: 50602

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: d37c124b9367ad904de724a5db0f27ca34be93fa https://github.com/pharo-project/pharo-core/commit/d37c124b9367ad904de724a5… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-02-23 (Tue, 23 Feb 2016) Changed paths: M ConfigurationOfSessionManager.package/ConfigurationOfSessionManager.class/instance/symbolic versions/stable_.st A ConfigurationOfSessionManager.package/ConfigurationOfSessionManager.class/instance/versions/version13_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50601.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50602.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50601.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50602.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A System-SessionManager-Tests.package/SessionManagerRegistrationTest.class/instance/tests/testGivenARegisteredClassHandlerShouldHasRegisteredReturnsTrue.st A System-SessionManager-Tests.package/SessionManagerRegistrationTest.class/instance/tests/testGivenUnknonwnHandledIdShouldHasRegisteredReturnsFalse.st A System-SessionManager.package/SessionManager.class/instance/registration/hasRegistered_.st A System-SessionManager.package/SessionManager.class/instance/registration/registerUserClassNamed_.st A System-SessionManager.package/SessionManager.class/instance/registration/registerUserClassNamed_atPriority_.st Log Message: ----------- 50602 17680 SessionManager 1.3 https://pharo.fogbugz.com/f/cases/17680 http://files.pharo.org/image/50/50602.zip

Feb. 23, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50602 Home: https://github.com/pharo-project/pharo-core

Feb. 23, 2016

Re: [Pharo-dev] [Bloc] Do we want <return: #Point> or <return: Point>

by Tudor Girba

Hi, > On Feb 23, 2016, at 1:24 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > >> On 23 Feb 2016, at 13:20, Alain Plantec via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: >> >> >> From: Alain Plantec <alain.plantec(a)yahoo.com> >> Subject: Re: [Pharo-dev] [Bloc] Do we want <return: #Point> or <return: Point> >> Date: 23 February 2016 at 13:19:34 GMT+1 >> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >> >> >> Hello Doru, >> >>> On 23 Feb 2016, at 10:33, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>> Hi, >>> >>> At the moment, it is used for documentation purposes in Bloc. It is part of the effort of Alex to document Bloc thoroughly. I think it is an interesting idea, in that we would have a significant case study for that can be used later as optional types information to improve static tool support. And it does not hurt at the moment. >>> >>> What do you think? >> >> Experimenting optional types is a good idea. We could have Tools to dynamically check them. >> What about a separate typing model that could be used to add/remove the types annotations ? >> Also, I wonder if Bloc is the good package to experiment optional types. Maybe it is not stable enough. >> Cheers >> Alain > > please, please, please keep the scope of those experiments aside the main effort who is to have Block/Brick running as soon as possible. > > Esteban > > ps: â¦ optional typesâ¦ at the end, we will realise Gilad was right all this time :) I think there is a misunderstanding. The current annotations are there for documentation purposes. Given that Alex did an extensive pass to document Bloc, they should remain in place as they document the contracts. Documentation like this is something we should embrace for such a central piece. That this also provides the information for a potential optional types experiment itâs a different issue, and it would not affect at all the implementation of Bloc. Cheers, Doru >> >> >>> >>> Cheers, >>> Doru >>> >>> >>>> On Feb 23, 2016, at 10:25 AM, Alain Plantec via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: >>>> >>>> >>>> From: Alain Plantec <alain.plantec(a)yahoo.com> >>>> Subject: Re: [Pharo-dev] [Bloc] Do we want <return: #Point> or <return: Point> >>>> Date: February 23, 2016 at 10:23:33 AM GMT+1 >>>> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >>>> >>>> >>>> I donât like it too. >>>> Alain >>>> >>>>> Le 23 fÃ©vr. 2016 Ã 09:50, Nicolai Hess <nicolaihess(a)gmail.com> a Ã©crit : >>>>> >>>>> >>>>> >>>>> 2016-02-23 9:47 GMT+01:00 stepharo <stepharo(a)free.fr>: >>>>> Hi >>>>> >>>>> I saw that something <return: #Point> or <return: Point> >>>>> I do not know why but I have the impression that <return: #Point> is better. >>>>> Because we may have code not present and still want to load the code. >>>>> >>>>> I would like to know for what this is used. >>>>> I don't like it. >>>>> >>>>> >>>>> Stef >>>>> >>>>> >>>> >>>> >>>> >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "We are all great at making mistakes." >> >> >> > -- www.tudorgirba.com www.feenk.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."

Feb. 23, 2016