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

Re: [Pharo-project] ssl fails on build CI

by Camillo Bruni

fixed it: aptitude install libssl0.9.8:i386 On 2013-04-28, at 21:17, Max Leske <maxleske(a)gmail.com> wrote: > I just discovered that this only affects Pharo20 builds and older Pharo30 > > On 28.04.2013, at 21:07, Max Leske <maxleske(a)gmail.com> wrote: > >> The FileSystem-Git builds on CI generate many test failures because the SSL plugin is missing (apparently) here's the output: https://ci.inria.fr/pharo-contribution/job/FileSystem-Git/6/PHARO=20,VERSIO…. >> >> Is that to be expected? I gathered from a recent thread that at least libssl should be present on the CI servers. Or do I need to change something in the configuration? >> >> Max > >

April 28, 2013

Re: [Pharo-project] Why keymap modifiers change receiver instead of return new instance?

by Nicolas Cellier

Yes evil mutations! Let's ban these 2013/4/28 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Thanks for the explanation but I do not get it > > Because > > shortcut1 := $a ctrl. > shortcut2 := $a ctrl shift > > created different shortcuts. > > > I thought you wanted the inverse: > You wrote: > > Why modifiers change receiver state instead of create new instance? > > > > And it is fully unexpected that I can not refactor it to: > > shotcut2 := shortcut1 shift > > > ahhh I got it. > > > Because after that my shortcut1 become broken. > > It was happen in TxTextMorph where selection and movement shortcuts > created at same time > > TxTextMorph>>moveEditorOn: aShortcut by: aSelector > > self on: aShortcut do: [ > self moveEditorBy: aSelector withSelection: false ]. > self on: selectionModeModifier + aShortcut do: [ > self moveEditorBy: aSelector withSelection: true]. > > To fix it I add deep copy of given shortcut before modifier operation. > > > >> > There is another example: >> > >> > shortcut := $a ctrl. >> > self assert: shortcut == (KMModifier shift + shortcut) >> > >> > Yes. Such operation modified argument of message #+. What the crapp! >> Why it not returns new instance? >> > >> > I hope you agree to change this behaviour >> > >> > >> >> >> > >

April 28, 2013

Re: [Pharo-project] Trying to understand DateAndTime

by Nicolas Cellier

\\ returns a positive remainder. example: -1 \\ 86400 -> 86399 -1 // 86400 -> -1 So the jdn is decremented and seconds are correctly normalized. 2013/4/28 stephane ducasse <stephane.ducasse(a)free.fr> > Nicolas > > I read all the slice and I like it (even if they are place where I do not > get fully it :). > I'm dead. So may be this is obvious but I do not understand the or: logic > If the seconds is negative I do not understand what is happening. > > > normalizeSecondsAndNanos > (NanosInSecond <= nanos or: [ nanos < 0 ]) > ifTrue: [ > seconds := seconds + (nanos // NanosInSecond). > nanos := nanos \\ NanosInSecond]. > (SecondsInDay <= seconds or: [ seconds < 0 ]) > ifTrue: [ > julianDayNumber := julianDayNumber + (seconds // SecondsInDay). > seconds := seconds \\ SecondsInDay]. > > Stef > > > > On Apr 28, 2013, at 7:03 PM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > Yes, this was valid when jdn, seconds and nanos where maintained in local > time... > > > 2013/4/28 Paul DeBruicker <pdebruic(a)gmail.com> > >> Nicolas Cellier wrote >> > What I find strange: >> > - #hash uses the offset... Why ??? >> >> Maybe because of this: >> http://forum.world.st/true-hash-tp4621497p4624623.html >> >> which you fixed here: >> >> >> See http://forum.world.st/true-hash-tp4621497p4624706.html >> >> >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Trying-to-understand-DateAndTime-tp4683997p4684123.ht… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> > >

April 28, 2013

Re: [Pharo-project] Trying to understand DateAndTime

by stephane ducasse

Nicolas I read all the slice and I like it (even if they are place where I do not get fully it :). I'm dead. So may be this is obvious but I do not understand the or: logic If the seconds is negative I do not understand what is happening. normalizeSecondsAndNanos (NanosInSecond <= nanos or: [ nanos < 0 ]) ifTrue: [ seconds := seconds + (nanos // NanosInSecond). nanos := nanos \\ NanosInSecond]. (SecondsInDay <= seconds or: [ seconds < 0 ]) ifTrue: [ julianDayNumber := julianDayNumber + (seconds // SecondsInDay). seconds := seconds \\ SecondsInDay]. Stef On Apr 28, 2013, at 7:03 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Yes, this was valid when jdn, seconds and nanos where maintained in local time... > > > 2013/4/28 Paul DeBruicker <pdebruic(a)gmail.com> > Nicolas Cellier wrote > > What I find strange: > > - #hash uses the offset... Why ??? > > Maybe because of this: > http://forum.world.st/true-hash-tp4621497p4624623.html > > which you fixed here: > > > See http://forum.world.st/true-hash-tp4621497p4624706.html > > > > > > -- > View this message in context: http://forum.world.st/Trying-to-understand-DateAndTime-tp4683997p4684123.ht… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

April 28, 2013

Re: [Pharo-project] Why keymap modifiers change receiver instead of return new instance?

by StÃ©phane Ducasse

Thanks for the explanation but I do not get it > Because > > shortcut1 := $a ctrl. > shortcut2 := $a ctrl shift > > created different shortcuts. I thought you wanted the inverse: You wrote: > Why modifiers change receiver state instead of create new instance? > And it is fully unexpected that I can not refactor it to: > > shotcut2 := shortcut1 shift ahhh I got it. > Because after that my shortcut1 become broken. > > It was happen in TxTextMorph where selection and movement shortcuts created at same time > > TxTextMorph>>moveEditorOn: aShortcut by: aSelector > > self on: aShortcut do: [ > self moveEditorBy: aSelector withSelection: false ]. > self on: selectionModeModifier + aShortcut do: [ > self moveEditorBy: aSelector withSelection: true]. > > To fix it I add deep copy of given shortcut before modifier operation. > > > > > There is another example: > > > > shortcut := $a ctrl. > > self assert: shortcut == (KMModifier shift + shortcut) > > > > Yes. Such operation modified argument of message #+. What the crapp! Why it not returns new instance? > > > > I hope you agree to change this behaviour > > > > > > >

April 28, 2013

Re: [Pharo-project] Why keymap modifiers change receiver instead of return new instance?

by Denis Kudriashov

2013/4/28 stephane ducasse <stephane.ducasse(a)free.fr> > > Hello. > > > > I found this: > > > > shortcut := $a ctrl. > > self assert: shortcut == shortcut shift > > > > Why modifiers change receiver state instead of create new instance? > > I can understand since they modify the shortcut. > > > To me it is very bad unexpected behaviour. > > Why? > > Because shortcut1 := $a ctrl. shortcut2 := $a ctrl shift created different shortcuts. And it is fully unexpected that I can not refactor it to: shotcut2 := shortcut1 shift Because after that my shortcut1 become broken. It was happen in TxTextMorph where selection and movement shortcuts created at same time TxTextMorph>>moveEditorOn: aShortcut by: aSelector self on: aShortcut do: [ self moveEditorBy: aSelector withSelection: false ]. self on: selectionModeModifier + aShortcut do: [ self moveEditorBy: aSelector withSelection: true]. To fix it I add deep copy of given shortcut before modifier operation. > > > There is another example: > > > > shortcut := $a ctrl. > > self assert: shortcut == (KMModifier shift + shortcut) > > > > Yes. Such operation modified argument of message #+. What the crapp! Why > it not returns new instance? > > > > I hope you agree to change this behaviour > > > > > > >

April 28, 2013

Re: [Pharo-project] [Ann] TxText. New text editor done!

by stephane ducasse

On Apr 28, 2013, at 7:47 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > I upload new version 0.7: > - clipboard operations > - more navigation shortcuts > - fixed bugs when editing text from start or end text positions > - optimized text drawing to draw only visible lines > - optimized TxInterval>>contains:. So now #newTextContents: works on big strings > > With this version I again investigate beautiful morphic events code (you should install slice 10427). > I add shortcuts "Character end ctrl" and "Character home ctrl" to move cursor at text end and start. And it was not work. > I debug what happens and KeyboardEvent from "Character home ctrl" was printed as ctrl+d. What's the crap! > Ok I found this code: > > modifiedCharacter > self flag: #hack. > "Hack me. When Ctrl is pressed, the key ascii value is not right and we have to do something ugly" > ^(self controlKeyPressed and: [ (#(MacOSX Windows) includes: Smalltalk os current platformFamily) and: [ keyValue <= 26 ]]) > ifTrue: [ (self keyValue + $a asciiValue - 1) asCharacter ] > ifFalse: [ self keyCharacter ] horrible! As igor said this is not that we do not want but we have to pay attention to our ressources. > > I don't know why such complicated code needed but with only "^self keyCharacter" you will replace many standart shortcuts with some random behaviour. > So I just extract special logic to method and put here special checking for home and end characters: > > KeyboardEvent>>hasSpecialCTRLKeyValue > " > 4 - Character end > 1 - Character home > " > > ^ self controlKeyPressed and: [ keyValue <= 26 & (keyValue ~= 4) & (keyValue ~= 1) ] > > And I remove dublication in printing keyboard event. > > Slice with fix here https://pharo.fogbugz.com/default.asp?10427. Should I put it at configuration dependency? > > I read about new events system at pharo vision. Is new system will remove such hacks? > >

April 28, 2013

Re: [Pharo-project] [update 3.0] #30069

by stephane ducasse

April 28, 2013

Re: [Pharo-project] Trying to understand DateAndTime

by stephane ducasse

Igor could you review the changes of nicolas - I was planning to do it now but I'm dead so I will do it but with half of my mind. Because may be this is better to integrate his changes then do another pass friday. Stef On Apr 28, 2013, at 3:38 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 28 April 2013 08:41, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >> thanks a lot! >> Friday we have an official sprint so I'm sure that this issue will be >> addressed. >> > yes. and i hope i will put my changes into the soup as well. > (i did not published them, and some bits are unfinished). > >> Stef >> >> See https://pharo.fogbugz.com/default.asp?10425# and corresponding SLICE in >> 3.0 inbox >> Note: I don't know what is the policy with the labels/states of these bug >> tracker, and it rather bothers me, but the SLICE is ready for tests/reviews. >> >> >> 2013/4/27 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> >>> >>> There is more: >>> >>> 1) hasEqualTicks: use julianDayNumber instead of julianDayNumberUTC >>> 2) (Time dateAndTime now) interprets the (Time localSeconds) which are >>> from the wrong primitive (seconds ellapsed since squeak epoch translated to >>> local time) as seconds ellapsed since squeak Epoch (UTC time). >>> >>> We should really ban the old primitive 137 and only use the new one (240 >>> which works with UTC microseconds). >>> >>> I think Camillo did a good job, but he stopped cleaning too soon. >>> Ah, young guys are so impatient to invent the future ;) >>> >>> >>> 2013/4/27 stephane ducasse <stephane.ducasse(a)free.fr> >>>> >>>> >>>> On Apr 27, 2013, at 6:33 PM, Nicolas Cellier >>>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>> >>>>> Since DateAndTime comment is out of date (sic !) and current >>>>> implementation seems not free of bug, here is an effort to summarize and >>>>> understand the whole thing, let's call this a review. >>>> >>>> Thanks this is a great initiative! >>>> >>>> >>>>> Please tell me where my interpretations are wrong. >>>>> >>>>> 1) The DateAndTime is stored internally as >>>>> - a point in UTC time (julianDayNumber, seconds, nanos) >>>>> - an offset from UTC (a Duration) denoting the local time zone >>>>> >>>>> 2) The ticks method returns the UTC part {julianDayNumber. seconds. >>>>> nanos} >>>>> >>>>> 3) DateAndTime print themselves in local time using the offset >>>>> >>>>> 4) other methods (with some exceptions) return the local dateAndTime >>>>> parts (year month day hours minutes seconds) >>>>> >>>>> Exceptions are: >>>>> - secondsSinceMidnight (which should be renamed secondsSinceMidnightUTC >>>>> IMO, even if the method is classified private) >>>>> - julianDayNumberUTC as the name tells >>>>> >>>>> So far so good (but secondsSinceMidnight which is error prone) >>>>> >>>>> What I find strange: >>>>> - #hash uses the offset... Why ??? >>>>> >>>>> d1 := DateAndTime now. >>>>> d2 := d1 offset: d1 offset + 1 hours. >>>>> { >>>>> d1 = d2. >>>>> d1 hash = d2 hash. >>>>> } >>>>> gives #(true false), a clue? >>>>> >>>>> - #< compares julianDayNumber (the UTC inst. var.) with otherDate >>>>> julianDayNumber (with otherDate local offset) which seems wrong, it should >>>>> better use julianDayNumberUTC or (normalized) ticks. >>>>> >>>>> - #= could be simplified and accelerated if using #hasEqualTicks: (if >>>>> the ticks are correctly normalized though which would be the case since >>>>> #ticks:offset: does, unfortunately #setJdn:seconds:nanos:offset: does not). >>>>> >>>>> Some senders of #setJdn:seconds:nanos:offset: don't normalize the >>>>> day/seconds/nanos, though it should be their responsibility (DateAndTime >>>>> todayAtMilliSeconds: xxx) (DateAndTime todayAtNanoSeconds: xxx), not >>>>> counting year:month:day:hour:minute:second:nanoSecond:offset: which does not >>>>> either (many senders...). >>>>> Maybe we should better let the normalization responsibility to >>>>> #setJdn:seconds:nanos:offset:. >>>>> >>>>> It remain to analyze the conversion protocol (asYear etc...) which >>>>> seems to use the local time year, but I don't understand the whole Timespan >>>>> thing right now (why DateAndTime now asYear starts now, and not on january >>>>> 1st?). >>>>> >>>>> Nicolas >>>>> >>>>> >>>> >>>> >>> >> >> > > > > -- > Best regards, > Igor Stasenko. >

April 28, 2013

Re: [Pharo-project] Why keymap modifiers change receiver instead of return new instance?

by stephane ducasse

> Hello. > > I found this: > > shortcut := $a ctrl. > self assert: shortcut == shortcut shift > > Why modifiers change receiver state instead of create new instance? I can understand since they modify the shortcut. > To me it is very bad unexpected behaviour. Why? > > There is another example: > > shortcut := $a ctrl. > self assert: shortcut == (KMModifier shift + shortcut) > > Yes. Such operation modified argument of message #+. What the crapp! Why it not returns new instance? > > I hope you agree to change this behaviour > >

April 28, 2013