May 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] about logCr: vs. log: vs. trace:/traceCr:

by stephane ducasse

On May 6, 2013, at 7:16 AM, S Krish <krishnamachari.sudhakar(a)gmail.com> wrote: > I mentioned in another thread. #crLog, #logCr are intuitive and perfectly fine. > > Also hook Loggers first class into the system ( Toothpick ) and make it default to Transcript with these messages routed to the Logger. > > Transcript cr / current #crLog is akin to cout / System.out.println .. mostly deprecated in enterprise coding practices. I want to kill all the Transcript show: as well as as the logCr: I started to work on that and when it will be ready for feedback I will announce it. > > > > > On Mon, May 6, 2013 at 3:04 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 05 May 2013, at 21:42, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > Hi guys > > > > Stupidly I introduced log: a while ago to replace Transcript show:. Now is the current situation. > > > > I still want to remove all the use of Transcript show: > > > > Now since I thought I did a mistake with log: because it overload Integer>>log: I introduced trace: and traceCr: > > > > Now I do not like traceCr: because it is not a cool message. > > > > So what do we do: > > > > 1) we use crLog:, logCr: > > and deprecated log: > > > > > > 2) we use crTrace:, trace: and traceCr: > > > > I really prefer solution 1 but I would like to hear from you. > > > > Stef > > I am for 1 as well, but I find #crLog: or #logCr: confusing - there should only be one system wide approach. > Also, whether or not to add a Cr to a log message (or before or after it) is not a decision a client/user should have to make. > Maybe Cr makes no sense, for example when log messages are added to a collection. > > So I am for #log: as a simple and clear message. > > The conflict with Number>>#log: is less important than that IMHO. > Either we live with the conflict or we rename Number>>#log: to Number>>#logBase: or something like that. > > I also like the convention of #value being sent by #log: to its argument. > That allows for blocks that are not evaluated when logging is disabled. > > My 2c. > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > >

May 6, 2013

Re: [Pharo-project] about logCr: vs. log: vs. trace:/traceCr:

by stephane ducasse

I think that Cr is useless because they are to separate line in text and I want to kill text and just get objects (that can produce text but from a list of objects I easily can add a cr between their printstring :) Stef On May 5, 2013, at 11:34 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 05 May 2013, at 21:42, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Hi guys >> >> Stupidly I introduced log: a while ago to replace Transcript show:. Now is the current situation. >> >> I still want to remove all the use of Transcript show: >> >> Now since I thought I did a mistake with log: because it overload Integer>>log: I introduced trace: and traceCr: >> >> Now I do not like traceCr: because it is not a cool message. >> >> So what do we do: >> >> 1) we use crLog:, logCr: >> and deprecated log: >> >> >> 2) we use crTrace:, trace: and traceCr: >> >> I really prefer solution 1 but I would like to hear from you. >> >> Stef > > I am for 1 as well, but I find #crLog: or #logCr: confusing - there should only be one system wide approach. > Also, whether or not to add a Cr to a log message (or before or after it) is not a decision a client/user should have to make. > Maybe Cr makes no sense, for example when log messages are added to a collection. > > So I am for #log: as a simple and clear message. > > The conflict with Number>>#log: is less important than that IMHO. > Either we live with the conflict or we rename Number>>#log: to Number>>#logBase: or something like that. > > I also like the convention of #value being sent by #log: to its argument. > That allows for blocks that are not evaluated when logging is disabled. > > My 2c. > > Sven > > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > >

May 6, 2013

Re: [Pharo-project] RFB in 2.0

by Damien Cassou

On Mon, May 6, 2013 at 6:23 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > Would someone add me please? done -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

May 6, 2013

Re: [Pharo-project] Programming interactions with State Machines

by stephane ducasse

On May 6, 2013, at 2:31 AM, Carla F. Griggio <carla.griggio(a)gmail.com> wrote: > Hello everyone! > I'm here to tell you that I started experimenting with a Pharo implementation of this idea: http://swingstates.sourceforge.net/. For those into UI programming I really recommend reading the first paper cited in that page. It's for programming user interface interactions with state machines, an approach to avoid the classical "callback spaghetti" that sometimes we get with event handlers everywhere. This is looking interesting. Now we should check how it works with inheritance. Keep us posted about your progress. Stef > I have a tiny first step that shows an example for changing the color of a button on mouse over and changing it back to the original color on mouse out. > > You can download the code from: http://smalltalkhub.com/mc/CarlaGriggio/StateMachines/main > > Evaluate this for executing the example: > > SMButton openWithStateMachineInteraction > > And here is the code of the state machine for that example: > > SMButton class >> openWithStateMachineInteraction > |button stateMachine iddle hover | > button := self new. > stateMachine := SMStateMachine newForWidget: button. > iddle := (SMState newWithName:'iddle') > enter:[:stMachine | stMachine widget color: Color yellow ]; > addTransition: ((SMTransition forEvent: 'mouse enter' withOutputState: 'hover') > transitionAction: [:stMachine | stMachine widget color: Color red ]). > hover := (SMState newWithName:'hover') > addTransition: (SMTransition forEvent: 'mouse out' withOutputState: 'iddle'); > addTransition: (SMTransition forEvent: 'mouse enter' withOutputState: 'hover'). > stateMachine addState: iddle; addState: hover. > stateMachine attachTo: button. > ^button openInWorld > > That code corresponds to the following states diagram: > > <Screen Shot 2013-05-06 at 2.27.20 AM.png> > > I will keep experimenting with this during the next weeks, and specially try to compare the pros and cons with regular event handling. > > Something cool about this approach is that the same widget could change its interactive behaviour on the fly by just attaching a different interaction state machine to it :) > > Also, I'm doing this for programming user interface interactions, but it could be useful for anything that can be modelled with a state pattern. > > Is there something similar out there already working? I was so eager to try this that I didn't look for related existing projects. > > Cheers! > Carla.

May 6, 2013

Re: [Pharo-project] RFB in 2.0

by Norbert Hartl

thanks, I knew the next question upfront but was reluctant to ask in the last mail for access to PharoExtras. Would someone add me please? Norbert Am 06.05.2013 um 18:20 schrieb stephane ducasse <stephane.ducasse(a)free.fr>: > this is called PharoExtras. > > Stef > > On May 6, 2013, at 6:16 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> >> Am 03.05.2013 um 20:09 schrieb Mariano Martinez Peck <marianopeck(a)gmail.com>: >> >>> >>> >>> >>> On Fri, May 3, 2013 at 3:05 PM, Norbert Hartl <norbert(a)hartl.name> wrote: >>> >>> Am 03.05.2013 um 20:00 schrieb Mariano Martinez Peck <marianopeck(a)gmail.com>: >>> >>>> Hi Norbert, >>>> >>>> I would move it to its own new repo in SmalltalkHub. >>>> >>> Ok, but then it goes under my private section, right? >>> >>> you can put it under PharoContributions team. >>> >> How can I do that? I don't find anything like PharoContributions on smalltalkhub. >> >> Norbert >> >>> >>>> Also, I had another problem with RFB and the UIManager. The solution I found was this one: http://samadhiweb.com/blog/2012.11.04.headless.rfb.html >>>> I don't like it because I need to change Pharo's base source, but I didn't spend time finding a better solution...I guess there is, though. >>>> >>> The first line of code all my images (deployed on server using RFB) see is >>> >>> UIManager default: MorphicUIManager new. >>> >>> >>> I was going to do that as well. But it is not clear to me WHERE you write that line of code. Because even if you save the image with that, doesn't the image set its own UI manager when booting? So I guess you need to pass around a script when running the image or something? >>> What about adding RFB at startup list and implement #startUp doing "UIManager default: MorphicUIManager new." ? >>> >>> Best, >>> >>> >>> With that I don't have problems at all. >>> >>> thanks, >>> >>> Norbert >>> >>>> Best, >>>> >>>> >>>> >>>> >>>> On Fri, May 3, 2013 at 2:56 PM, Norbert Hartl <norbert(a)hartl.name> wrote: >>>> I've found the problem. There is a FileDirectory access in RFBSession>>#desktopName. Removing it makes RFB work. >>>> >>>> The current RFB sources are on Lukas' server. What do we do with that stuff? Move to smalltalkhub? If not I can ask Lukas to give me write permission. Just wanted to ask what kind of behaviour is en vogue this days. >>>> >>>> Norbert >>>> >>>> Am 03.05.2013 um 19:31 schrieb Norbert Hartl <norbert(a)hartl.name>: >>>> >>>> > Esteban, >>>> > >>>> > now I can tell that it isn't working for me either. Socket is open and server is running. But there are immediate disconnects when trying to connect to a pharo2.0 image. >>>> > >>>> > Did you figure it out? >>>> > >>>> > Norbert >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >> >

May 6, 2013

Re: [Pharo-project] RFB in 2.0

by stephane ducasse

this is called PharoExtras. Stef On May 6, 2013, at 6:16 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 03.05.2013 um 20:09 schrieb Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> >> >> >> On Fri, May 3, 2013 at 3:05 PM, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> Am 03.05.2013 um 20:00 schrieb Mariano Martinez Peck <marianopeck(a)gmail.com>: >> >>> Hi Norbert, >>> >>> I would move it to its own new repo in SmalltalkHub. >>> >> Ok, but then it goes under my private section, right? >> >> you can put it under PharoContributions team. >> > How can I do that? I don't find anything like PharoContributions on smalltalkhub. > > Norbert > >> >>> Also, I had another problem with RFB and the UIManager. The solution I found was this one: http://samadhiweb.com/blog/2012.11.04.headless.rfb.html >>> I don't like it because I need to change Pharo's base source, but I didn't spend time finding a better solution...I guess there is, though. >>> >> The first line of code all my images (deployed on server using RFB) see is >> >> UIManager default: MorphicUIManager new. >> >> >> I was going to do that as well. But it is not clear to me WHERE you write that line of code. Because even if you save the image with that, doesn't the image set its own UI manager when booting? So I guess you need to pass around a script when running the image or something? >> What about adding RFB at startup list and implement #startUp doing "UIManager default: MorphicUIManager new." ? >> >> Best, >> >> >> With that I don't have problems at all. >> >> thanks, >> >> Norbert >> >>> Best, >>> >>> >>> >>> >>> On Fri, May 3, 2013 at 2:56 PM, Norbert Hartl <norbert(a)hartl.name> wrote: >>> I've found the problem. There is a FileDirectory access in RFBSession>>#desktopName. Removing it makes RFB work. >>> >>> The current RFB sources are on Lukas' server. What do we do with that stuff? Move to smalltalkhub? If not I can ask Lukas to give me write permission. Just wanted to ask what kind of behaviour is en vogue this days. >>> >>> Norbert >>> >>> Am 03.05.2013 um 19:31 schrieb Norbert Hartl <norbert(a)hartl.name>: >>> >>> > Esteban, >>> > >>> > now I can tell that it isn't working for me either. Socket is open and server is running. But there are immediate disconnects when trying to connect to a pharo2.0 image. >>> > >>> > Did you figure it out? >>> > >>> > Norbert >>> >>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >

May 6, 2013

Re: [Pharo-project] RFB in 2.0

by Norbert Hartl

Am 03.05.2013 um 20:09 schrieb Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > > On Fri, May 3, 2013 at 3:05 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 03.05.2013 um 20:00 schrieb Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> Hi Norbert, >> >> I would move it to its own new repo in SmalltalkHub. >> > Ok, but then it goes under my private section, right? > > you can put it under PharoContributions team. > How can I do that? I don't find anything like PharoContributions on smalltalkhub. Norbert > >> Also, I had another problem with RFB and the UIManager. The solution I found was this one: http://samadhiweb.com/blog/2012.11.04.headless.rfb.html >> I don't like it because I need to change Pharo's base source, but I didn't spend time finding a better solution...I guess there is, though. >> > The first line of code all my images (deployed on server using RFB) see is > > UIManager default: MorphicUIManager new. > > > I was going to do that as well. But it is not clear to me WHERE you write that line of code. Because even if you save the image with that, doesn't the image set its own UI manager when booting? So I guess you need to pass around a script when running the image or something? > What about adding RFB at startup list and implement #startUp doing "UIManager default: MorphicUIManager new." ? > > Best, > > > With that I don't have problems at all. > > thanks, > > Norbert > >> Best, >> >> >> >> >> On Fri, May 3, 2013 at 2:56 PM, Norbert Hartl <norbert(a)hartl.name> wrote: >> I've found the problem. There is a FileDirectory access in RFBSession>>#desktopName. Removing it makes RFB work. >> >> The current RFB sources are on Lukas' server. What do we do with that stuff? Move to smalltalkhub? If not I can ask Lukas to give me write permission. Just wanted to ask what kind of behaviour is en vogue this days. >> >> Norbert >> >> Am 03.05.2013 um 19:31 schrieb Norbert Hartl <norbert(a)hartl.name>: >> >> > Esteban, >> > >> > now I can tell that it isn't working for me either. Socket is open and server is running. But there are immediate disconnects when trying to connect to a pharo2.0 image. >> > >> > Did you figure it out? >> > >> > Norbert >> >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com > > > > > -- > Mariano > http://marianopeck.wordpress.com

May 6, 2013

[Pharo-project] [update 3.0] #30108

by Marcus Denker

30108 ----- 10541 Fix fileOut broken by update 30107 https://pharo.fogbugz.com/f/cases/10541 10539 Small cleanup related to #methods in Kernel https://pharo.fogbugz.com/f/cases/10539 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Traits-MarcusDenker.501.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/NautilusCommon-MarcusDenker.1… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Ring-Core-Kernel-MarcusDenker…

May 6, 2013

[Pharo-project] [regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=wi… 2 regressions found. KernelTests.Classes.ClassDescriptionTest.testUnCategorizedMethods Tests.System.OSEnvironmentTest.testAtPut

May 6, 2013

[Pharo-project] [regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=li… 1 regressions found. KernelTests.Classes.ClassDescriptionTest.testUnCategorizedMethods

May 6, 2013