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

[Pharo-project] [update 2.0] #20504

by Marcus Denker

20504 ----- Issue 7385: FreeTypeFace not recreated from embedded cache upon image load http://code.google.com/p/pharo/issues/detail?id=7385 Issue 7383: TextModel>>setSelection: does not update the visual selection if the widget if not in focus http://code.google.com/p/pharo/issues/detail?id=7383 Diff information: http://ss3.gemstone.com/ss/Pharo20/Spec-Widgets-MarcusDenker.88.diff http://ss3.gemstone.com/ss/Pharo20/FreeType-MarcusDenker.611.diff

Feb. 1, 2013

Re: [Pharo-project] nativeboost google groups

by Igor Stasenko

On 1 February 2013 13:29, S Krish <krishnamachari.sudhakar(a)gmail.com> wrote: > I guess the primary code contributors should decide.. > i don't have strong opinion about this. For me it is not important where discussion takes place, but its participants. > > On Friday, February 1, 2013, Ciprian Teodorov wrote: >> >> Hi guys, >> >> I hate to revive this discussion, but I am confused... What has been >> decided about NB ? Are we supposed to continue using pharo list? Or the >> Google group started by Camillo? >> >> Cheers >> >> I agree. >> Especially for core elements. I do not fully understand nativeboost but I >> like to read the messages >> and question because I learn the domain >> like NBHandleâ¦. >> >> Stef >> >> > I dislike outsourcing it to a google group. NB is now part of the image >> > and the discussion should be here as well. >> > >> > Otherwise we end up with too many places nobody will be able >> > to follow or find... >> > >> > Please close the group since it adds more confusion. >> > >> > Bye >> > T. >> > >> > >> >> > -- Best regards, Igor Stasenko.

Feb. 1, 2013

Re: [Pharo-project] nativeboost google groups

by S Krish

I guess the primary code contributors should decide.. On Friday, February 1, 2013, Ciprian Teodorov wrote: > Hi guys, > > I hate to revive this discussion, but I am confused... What has been > decided about NB ? Are we supposed to continue using pharo list? Or the > Google group started by Camillo? > > Cheers > I agree. > Especially for core elements. I do not fully understand nativeboost but I > like to read the messages > and question because I learn the domain > like NBHandleâ¦. > > Stef > > > I dislike outsourcing it to a google group. NB is now part of the image > > and the discussion should be here as well. > > > > Otherwise we end up with too many places nobody will be able > > to follow or find... > > > > Please close the group since it adds more confusion. > > > > Bye > > T. > > > > > > >

Feb. 1, 2013

Re: [Pharo-project] [update 2.0] #20502

by StÃ©phane Ducasse

Esteban do you see a problem. Because I have problem to see why it would not work. I will check the because may be there is a filter to exclude refactoring* files. Stef > stephane ducasse wrote >> - Issue 7348: Enhancing SmallLintRules > > Were the correct packages integrated for this? > > Name: SLICE-Issue-7348-Enhancing-SmallLintRules--StephaneDucasse.2 > Dependencies: > - Refactoring-Critics-StephaneDucasse.30 > - Refactoring-Tests-Core-StephaneDucasse.61 > - Manifest-Core-StephaneDucasse.101 > > But 20502 (from the static file server) has: > - Refactoring-Critics-StephaneDucasse.28 > - Refactoring-Tests-Core-StephaneDucasse.63 > - Manifest-Core-StephaneDucasse.99 > > > > -- > View this message in context: http://forum.world.st/update-2-0-20502-tp4666904p4666969.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Feb. 1, 2013

[Pharo-project] [update 2.0] #20503

by Esteban Lorenzano

Feb. 1, 2013

Re: [Pharo-project] nativeboost google groups

by Ciprian Teodorov

Hi guys, I hate to revive this discussion, but I am confused... What has been decided about NB ? Are we supposed to continue using pharo list? Or the Google group started by Camillo? Cheers I agree. Especially for core elements. I do not fully understand nativeboost but I like to read the messages and question because I learn the domain like NBHandleâ¦. Stef > I dislike outsourcing it to a google group. NB is now part of the image > and the discussion should be here as well. > > Otherwise we end up with too many places nobody will be able > to follow or find... > > Please close the group since it adds more confusion. > > Bye > T. > >

Feb. 1, 2013

Re: [Pharo-project] daylight savings issues

by Sven Van Caekenberghe

On 01 Feb 2013, at 10:59, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 1 February 2013 09:39, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >> On 2013-02-01, at 10:33, Otto Behrens <otto(a)finworks.biz> wrote: >> >>>>> We're not on 2.0 yet and are running on GemStone. Our dates are in a >>>>> local time zone currently, how do we "work" with UTC dates and make >>>>> sure the outside world see the correct date / time? >>>> >>>> Most probably you will get away with it, by only displaying dates/times in >>>> local time zones, but make sure everything internally uses UTC (without daylight >>>> saving times). >>>> >>>> So you only have to be careful with when inputting data and when displaying. >>>> Everything that is relative (like your example) will work out of the box. >>> >>> This feels painful. I suppose we'll have to hunt for Dates in the >>> system and migrate them. And then change our subclass of >>> MADateDescription (we use a date picker) to convert to & from the >>> local time zone. And then we have a few timestamps, which is indeed >>> time zone sensitive. >> >> Basically everything will work fine until the point your image crosses time-zones. >> Just be careful ;) I burnt my fingers more than once while fixing this mess :P >> >> >>> I feel the need for a timezone agnostic Date. But I suppose working >>> with time and duration may complicate things. >> >> yeah, we reached that conclusion at the point we tried to fully grasp the scale >> of the problem. So now we have everything internally in UTC, which simplifies a lot. > > Sticking with UTC everywhere internally, converting local time -> UTC > on input, and only displaying local time, is the one true way. All > else is madness. Yes, indeed the best way. However, that still does not mean that daylight saving does not exist - when it goes in and out of effect, you will see strange things that might confuse or upset end users counting in their local time zone. BTW, there is ZTimestamp in http://mc.stfx.eu/Neo that is a UTC only, second precision DateAndTime/Timestamp that can represent itself in any TZ. > frank > >>> Thanks for the help. >>> >>>>> How do I write a test for this? >>>> >>>> I presume to properly reproduce the problem you would have to change the os system-timezone >>>> during a test. Which you could achieve with OSProcess :/ >>> >>> Eeeuw, ok >>> >> >> >

Feb. 1, 2013

Re: [Pharo-project] help needed

by Usman Bhatti

On Fri, Feb 1, 2013 at 12:52 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > On Jan 31, 2013, at 7:35 PM, Usman Bhatti wrote: > > > > > > > > > On Thu, Jan 31, 2013 at 10:09 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > Usman > > > > I also try just returning the container but do not know the expected > result. > > It "works" > > > > It kinda "works" because DNU has disappeared. > > > > Scenario > > I have a list, when I select an element from the list, its properties, > visu and metrics are shown by glamour. > > > > Ideal Situation: > > I trigger the selection of a random node (from another visu) and its not > part of the shown elements in the list (but is still part of model), it > should be selected/gets focus in the list. > > I do not understand how a container setSelectedMorph: nil can select a > node :) > Agreed :-). I was looking for the behavior which says, the node that you are trying to select is not shown, so create a morph of the node in the tree, select it and show it and I couldn't find this behavior, I doubt it exists. > > > > > > what this "Fix" does > > With the "fix", I can see the properties and visu of the selected node > in my browser and DNU is gone. But selection of the node does not happen. > For me, sufficient to show a problem-free UI but its not the ideal behavior. > > > > Should this "fix" be a part of pharo? But this code needs a thorough > inspection. > > > > usman > > > > > > > > Stef > > > > > > > > On Jan 31, 2013, at 12:48 PM, Usman Bhatti wrote: > > > > > > > > > > > > > > On Thu, Jan 31, 2013 at 1:20 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > > Usman did you check with 1.3 to know if the method was there? > > > > > > I looked in 1.3. The method is defined on MorphTreeMorph (see > sceenshot) but absent from this class in 1.4. Copying and pasting the > method from 1.3 to 1.4 in the class does not work, there are some missing > instance variables in the code. > > > The number of implementing classes for setSelectedMorph: does not > change between 1.3 and 1.4. To me it seems that the method was moved to > MorphTreeListManager in 1.4. It tried to change the receiver to invoke the > method on MorphTreeListManager but there are some other problems then. > > > > > > <image.png> > > > > > > > > > Stef > > > > > > On Jan 31, 2013, at 7:03 AM, Usman Bhatti wrote: > > > > > > > > > > > > > > > > > > > On Thu, Jan 31, 2013 at 2:30 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > > > Morbid fascination > > > > It is late so I may completely off but > > > > how many isKindOf: are executed in this method? > > > > > > > > > ((aSymbol isKindOf: Array) > > > > > and: [aSymbol size > 1 and: [aSymbol first == self > nodeListSelector and: [ > > > > > aSymbol second == > #openPath]]]) > > > > > > > > when [aSymbol second == #openPath] is not openPath > > > > then we go to the next (not mentioning duplicated code inside the > method ---- I will vomit) > > > > and we restart to execute isKindOf: > > > > > > > > ((aSymbol isKindOf: Array) > > > > and: [aSymbol size > 1 and: [aSymbol first == self > nodeListSelector and: [ > > > > aSymbol second == > #expandAllFromNode:]]]) > > > > > > > > Am'I right? > > > > It looks so terrible. > > > > > > > > Yes. And more so for someone not frequently working with Morphs. > > > > So, can someone at least see if the problem can be fixed without a > large refactoring that should surely happen, but the glamour bug needs a > quick fix. Or at least point to why the missing method on the receiver is > abundantly found in the code? > > > > > > > > usman > > > > > > > > > > > > Stef > > > > > > > > > > > > > > > > > update: aSymbol > > > > > aSymbol == #selection ifTrue: [^ self listManager > updateSelectionFromModel]. > > > > > ((aSymbol isKindOf: Array) and: [aSymbol size > 1 and: > [aSymbol first == #selectItems and: [aSymbol second isCollection]]]) > > > > > ifTrue: [^ self selectedItems: aSymbol second]. > > > > > aSymbol == self nodeListSelector ifTrue: [^ self updateList]. > > > > > aSymbol == #selectAll ifTrue: [^ self listManager selectAll]. > > > > > aSymbol == #deselectAll ifTrue: [^ self listManager > deselectAll]. > > > > > ((aSymbol isKindOf: Array) > > > > > and: [aSymbol size > 1 and: [aSymbol first == self > nodeListSelector and: [ > > > > > aSymbol second == > #openPath]]]) "allow directed path opening where multiple trees exist" > > > > > ifTrue: > > > > > [^(self allNodeMorphs at: 1 > ifAbsent: [^self]) > > > > > openPath: (aSymbol > allButFirst: 2)]. > > > > > ((aSymbol isKindOf: Array) > > > > > and: [aSymbol size > 1 and: [aSymbol first == self > nodeListSelector and: [ > > > > > aSymbol second == > #openItemPath]]]) "allow directed path opening where multiple trees exist" > > > > > ifTrue: > > > > > [^ (self allNodeMorphs at: 1 > ifAbsent: [^self]) > > > > > openItemPath: (aSymbol > allButFirst: 2)]. > > > > > ((aSymbol isKindOf: Array) > > > > > and: [aSymbol size > 1 and: [aSymbol first == self > nodeListSelector and: [ > > > > > aSymbol second == > #expandAllFromNode:]]]) > > > > > ifTrue: > > > > > [^ self expandAllFromNode: aSymbol > third]. > > > > > ((aSymbol isKindOf: Array) > > > > > and: [aSymbol size > 1 and: [aSymbol first == self > nodeListSelector and: [ > > > > > aSymbol second == > #closeItemPath]]]) "allow directed path closing where multiple trees exist" > > > > > ifTrue: > > > > > [^ (self allNodeMorphs at: 1 > ifAbsent: [^self]) > > > > > closeItemPath: (aSymbol > allButFirst: 2)]. > > > > > ((aSymbol isKindOf: Array) > > > > > and: [aSymbol notEmpty and: [aSymbol first == > #openPath]]) > > > > > ifTrue: > > > > > [^(self allNodeMorphs at: 1 > ifAbsent: [^self]) > > > > > openPath: aSymbol > allButFirst]. > > > > > ((aSymbol isKindOf: Array) > > > > > and: [aSymbol size = 2 and: [aSymbol first = self > nodeListSelector and: [ > > > > > aSymbol second == > #expandRoots]]]) > > > > > ifTrue: > > > > > [^self expandRoots]. > > > > > ((aSymbol isKindOf: Array) > > > > > and: [aSymbol size = 2 and: [aSymbol first = self > nodeListSelector]]) > > > > > ifTrue: [aSymbol second = #expandAll ifTrue: [^ self > expandAll]. > > > > > aSymbol second = #collapseAll ifTrue: [^ > self collapseAll]] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >

Feb. 1, 2013

Re: [Pharo-project] daylight savings issues

by Frank Shearar

On 1 February 2013 09:39, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > On 2013-02-01, at 10:33, Otto Behrens <otto(a)finworks.biz> wrote: > >>>> We're not on 2.0 yet and are running on GemStone. Our dates are in a >>>> local time zone currently, how do we "work" with UTC dates and make >>>> sure the outside world see the correct date / time? >>> >>> Most probably you will get away with it, by only displaying dates/times in >>> local time zones, but make sure everything internally uses UTC (without daylight >>> saving times). >>> >>> So you only have to be careful with when inputting data and when displaying. >>> Everything that is relative (like your example) will work out of the box. >> >> This feels painful. I suppose we'll have to hunt for Dates in the >> system and migrate them. And then change our subclass of >> MADateDescription (we use a date picker) to convert to & from the >> local time zone. And then we have a few timestamps, which is indeed >> time zone sensitive. > > Basically everything will work fine until the point your image crosses time-zones. > Just be careful ;) I burnt my fingers more than once while fixing this mess :P > > >> I feel the need for a timezone agnostic Date. But I suppose working >> with time and duration may complicate things. > > yeah, we reached that conclusion at the point we tried to fully grasp the scale > of the problem. So now we have everything internally in UTC, which simplifies a lot. Sticking with UTC everywhere internally, converting local time -> UTC on input, and only displaying local time, is the one true way. All else is madness. frank >> Thanks for the help. >> >>>> How do I write a test for this? >>> >>> I presume to properly reproduce the problem you would have to change the os system-timezone >>> during a test. Which you could achieve with OSProcess :/ >> >> Eeeuw, ok >> > >

Feb. 1, 2013

Re: [Pharo-project] daylight savings issues

by Camillo Bruni

On 2013-02-01, at 10:33, Otto Behrens <otto(a)finworks.biz> wrote: >>> We're not on 2.0 yet and are running on GemStone. Our dates are in a >>> local time zone currently, how do we "work" with UTC dates and make >>> sure the outside world see the correct date / time? >> >> Most probably you will get away with it, by only displaying dates/times in >> local time zones, but make sure everything internally uses UTC (without daylight >> saving times). >> >> So you only have to be careful with when inputting data and when displaying. >> Everything that is relative (like your example) will work out of the box. > > This feels painful. I suppose we'll have to hunt for Dates in the > system and migrate them. And then change our subclass of > MADateDescription (we use a date picker) to convert to & from the > local time zone. And then we have a few timestamps, which is indeed > time zone sensitive. Basically everything will work fine until the point your image crosses time-zones. Just be careful ;) I burnt my fingers more than once while fixing this mess :P > I feel the need for a timezone agnostic Date. But I suppose working > with time and duration may complicate things. yeah, we reached that conclusion at the point we tried to fully grasp the scale of the problem. So now we have everything internally in UTC, which simplifies a lot. > Thanks for the help. > >>> How do I write a test for this? >> >> I presume to properly reproduce the problem you would have to change the os system-timezone >> during a test. Which you could achieve with OSProcess :/ > > Eeeuw, ok >

Feb. 1, 2013