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

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

by Marcus Denker

On Apr 28, 2013, at 4:54 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 28 April 2013 16:51, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> On Apr 28, 2013, at 4:44 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> Tried to load in >>> >>> Pharo3.0 >>> Latest update: #30068 >>> >>> Got MNU: Character>>asShortcut >>> >>> why it is not there? >>> :((( >>> >> >> Very strange. it seems this removed them: >> >> Name: Keymapping-Shortcuts-GuillermoPolito.67 >> Author: GuillermoPolito >> Time: 24 March 2013, 11:20:45.259 pm >> UUID: 4a3b850b-93ed-40d7-a1f8-75ca5d805af9 >> Ancestors: Keymapping-Shortcuts-EstebanLorenzano.65 >> >> from 3.0 >> > that's strange.. if i understand, it was introduced not that far ago, > and now removed again.. before even people get used to it :) > I think something got wrongly integrated. Marcus

April 28, 2013

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

by Igor Stasenko

On 28 April 2013 16:51, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Apr 28, 2013, at 4:44 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> Tried to load in >> >> Pharo3.0 >> Latest update: #30068 >> >> Got MNU: Character>>asShortcut >> >> why it is not there? >> :((( >> > > Very strange. it seems this removed them: > > Name: Keymapping-Shortcuts-GuillermoPolito.67 > Author: GuillermoPolito > Time: 24 March 2013, 11:20:45.259 pm > UUID: 4a3b850b-93ed-40d7-a1f8-75ca5d805af9 > Ancestors: Keymapping-Shortcuts-EstebanLorenzano.65 > > from 3.0 > that's strange.. if i understand, it was introduced not that far ago, and now removed again.. before even people get used to it :) -- Best regards, Igor Stasenko.

April 28, 2013

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

by Igor Stasenko

Okay.. got it in 2.0. WOW!!!! That's amazing!!!! A functional text editor... TxTextMorph exampleCenteredText I love you , Denis! :) (will leave hate for later, when i go & see how you implemented it ;) On 28 April 2013 16:44, Igor Stasenko <siguctua(a)gmail.com> wrote: > Tried to load in > > Pharo3.0 > Latest update: #30068 > > Got MNU: Character>>asShortcut > > why it is not there? > :((( > > > On 28 April 2013 16:37, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 27 April 2013 16:53, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >>> Denis Kudriashov wrote >>>> You can load configuration from >>>> http://www.smalltalkhub.com/#!/~sig/TxText. >>> >>> For the recreationally-inclined, like myself ;) >>> Gofer it >>> url: 'http://www.smalltalkhub.com/#!/~sig/TxText'; >>> package: 'ConfigurationOfTxText'; >>> load. >>> >> for recreationally-inclined like yourself, i would change the url in >> above code to: >> http://www.smalltalkhub.com/mc/sig/TxText/main >> >> :) >> >>> ((Smalltalk at: #ConfigurationOfTxText) project version: '0.6') load: >>> #('ALL'). >>> >>> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> View this message in context: http://forum.world.st/Ann-TxText-New-text-editor-done-tp4683876p4683987.html >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. > > > > -- > Best regards, > Igor Stasenko. -- Best regards, Igor Stasenko.

April 28, 2013

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

by Marcus Denker

On Apr 28, 2013, at 4:44 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Tried to load in > > Pharo3.0 > Latest update: #30068 > > Got MNU: Character>>asShortcut > > why it is not there? > :((( > Very strange. it seems this removed them: Name: Keymapping-Shortcuts-GuillermoPolito.67 Author: GuillermoPolito Time: 24 March 2013, 11:20:45.259 pm UUID: 4a3b850b-93ed-40d7-a1f8-75ca5d805af9 Ancestors: Keymapping-Shortcuts-EstebanLorenzano.65 from 3.0

April 28, 2013

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

by Igor Stasenko

Tried to load in Pharo3.0 Latest update: #30068 Got MNU: Character>>asShortcut why it is not there? :((( On 28 April 2013 16:37, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 27 April 2013 16:53, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> Denis Kudriashov wrote >>> You can load configuration from >>> http://www.smalltalkhub.com/#!/~sig/TxText. >> >> For the recreationally-inclined, like myself ;) >> Gofer it >> url: 'http://www.smalltalkhub.com/#!/~sig/TxText'; >> package: 'ConfigurationOfTxText'; >> load. >> > for recreationally-inclined like yourself, i would change the url in > above code to: > http://www.smalltalkhub.com/mc/sig/TxText/main > > :) > >> ((Smalltalk at: #ConfigurationOfTxText) project version: '0.6') load: >> #('ALL'). >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/Ann-TxText-New-text-editor-done-tp4683876p4683987.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > > > -- > Best regards, > Igor Stasenko. -- Best regards, Igor Stasenko.

April 28, 2013

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

by Igor Stasenko

On 27 April 2013 16:53, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Denis Kudriashov wrote >> You can load configuration from >> http://www.smalltalkhub.com/#!/~sig/TxText. > > For the recreationally-inclined, like myself ;) > Gofer it > url: 'http://www.smalltalkhub.com/#!/~sig/TxText'; > package: 'ConfigurationOfTxText'; > load. > for recreationally-inclined like yourself, i would change the url in above code to: http://www.smalltalkhub.com/mc/sig/TxText/main :) > ((Smalltalk at: #ConfigurationOfTxText) project version: '0.6') load: > #('ALL'). > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Ann-TxText-New-text-editor-done-tp4683876p4683987.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

April 28, 2013

Re: [Pharo-project] Trying to understand DateAndTime

by Igor Stasenko

On 28 April 2013 16:19, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Igor, do you mean everything related to millisecondClockValue (primitive > 135)? yes. > That would be very good to get rid of this useless complexity! > Of course it might cost some image freeze since used in Delay (I > accidentally caused a few, but then narrowed my changes to something > softer). > yes.. another reason why i want to get rid of that complicated code which involves Delays. > > 2013/4/28 Igor Stasenko <siguctua(a)gmail.com> >> >> 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. >> > -- Best regards, Igor Stasenko.

April 28, 2013

Re: [Pharo-project] Trying to understand DateAndTime

by Nicolas Cellier

Igor, do you mean everything related to millisecondClockValue (primitive 135)? That would be very good to get rid of this useless complexity! Of course it might cost some image freeze since used in Delay (I accidentally caused a few, but then narrowed my changes to something softer). 2013/4/28 Igor Stasenko <siguctua(a)gmail.com> > 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] Trying to understand DateAndTime

by Igor Stasenko

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] get.pharo.org missing .sources download

by Igor Stasenko

On 28 April 2013 15:27, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Apr 28, 2013, at 3:25 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 28 Apr 2013, at 15:13, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> On Apr 28, 2013, at 3:11 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>>> i'd like to be able to: >>>> >>>> get.pharo.org/20sources >>>> >>>> get.pharo.org/30sources >>>> >>> we should put the sources in the zip with the image >> >> I am not sure, they seldom change. >> >> In certain, 'give me everything' style downloads they should be included. >> >> On Ubuntu with the new ppa, they seem to be installed automatically. >> >> And we have a nice automatic source code download that is currently disabled ;-) >> > > The cognitive overhead that the .sources and .changes bring is *amazing*. > Everything is good in comparison.. Consider cognitive overhead of using java and eclipse .... :) > Marcus > > -- Best regards, Igor Stasenko.

April 28, 2013