- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Switching DNS server for pharo.org

by Marcus Denker

On Apr 28, 2013, at 9:35 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > We will change the DNS Server of pharo.org > > The forwards > > ci.pharo.org --> https://ci.inria.fr/pharo/ > issues.pharo.org --> http://bugs.pharo.org > > will not work for a while (till tomorrow latest) > > Everything else will be not affected. > DNS server entry has been changed. Now this takes up to 24 hours until all DNS caches are invalidated. The CDN functionality can now be turned on and off with a click (the result then is that the IP the DNS gives will be different and pointing to the caching servers). I think we should start to test it with get.pharo.org first. Marcus

April 28, 2013

Re: [Pharo-project] Pharo 3.0 TestRunner results

by Marcus Denker

On Apr 28, 2013, at 12:41 AM, Benoit St-Jean <bstjean(a)yahoo.com> wrote: > Here are the results with Pharo 3.0, update 30068). > > See attached file. > ClassDescriptionTest>>#testUnCategorizedMethods > ReleaseTest>>#testSystemAnnouncerIsUnique These two are failing on the build server, too. > SimulateMouseSpecification>>#testSimulateClick > DateTest>>#testNew > TimeStampTest>>#testMinusSecondsOverMidnight those are interesting. Marcus

April 28, 2013

[Pharo-project] Switching DNS server for pharo.org

by Marcus Denker

Hi, We will change the DNS Server of pharo.org The forwards ci.pharo.org --> https://ci.inria.fr/pharo/ issues.pharo.org --> http://bugs.pharo.org will not work for a while (till tomorrow latest) Everything else will be not affected. Marcus

April 28, 2013

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

by Denis Kudriashov

2013/4/28 stephane ducasse <stephane.ducasse(a)free.fr> > Hi denis > > Alain is gone on vacation but it told me that if you code scale he will > throw away what he did :) > May be the decorators that alain wrote can be merged. > In any case this is excellent to get a better system. > Yes. This is why I work on this project. But my first proposals was not make editor for large text. I actually not think about it at all. My main idea is make clean and extendible text editor. So anybody can understand how layout built, where text insertion happens, how it processed, how cursor wors and etc. I want text editor which is not required hacks to simple tasks like allow only numbers, hide cursor, disable text selection, make masked input, make smart completions and etc. > Stef > > > On Apr 27, 2013, at 5:17 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > > I should say it is not difficult to do with current design. I were > > think about it and current layout building logic requires little > > changes, maybe just one spesific method. > > > > But there is cases where any text change required rebuilding full > > layout. Fo example, single line text with wrapping mode. > > > > > > 2013/4/27, Igor Stasenko <siguctua(a)gmail.com>: > >> Very impressive progress, Denis! :) > >> > >> I going to finish low-level stuff in Athens (path approximation / > >> point location) > >> and then go straight to text rendering with existing Text. > >> Next stage will be to take TxText model and provide rendering for it > >> with Athens, > >> as well as review the code. > >> > >> About text editing and re-layout. > >> It should be possible that any local update (which affecting only > >> single character span or multiple adjusted character spans will > >> require only local recalculations of text layout). Otherwise there is > >> no reason why in our model we don't keep whole text in single big > >> buffer (like Text does). > >> Splitting text on multiple spans was the reason to make local layout > >> updates possible. > >> But i know it is not that easy to do :) > >> > >> > >> -- > >> Best regards, > >> Igor Stasenko. > >> > >> > > > > >

April 28, 2013

Re: [Pharo-project] Trying to understand DateAndTime

by stephane ducasse

thanks a lot! Friday we have an official sprint so I'm sure that this issue will be addressed. 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 > > > > > > > >

April 28, 2013

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

by Denis Kudriashov

Hi 2013/4/27 Sean P. DeNigris <sean(a)clipperadams.com> > Sean P. DeNigris wrote > > You're my new best friend :) > > The cursor is an actual Morph (TxCursorMorph) instead of magic conjured up > my Paragraph!!! All my other friends are fired, they've never given me a > present this nice :) > :) > > Also, please add me to the repo. I have a small fix (TxCursorMorph should > show cursorColor instead of defaultColor) > > I not have permissions for that. Igor can you add Sean as contributor? I were make another fixes and I added your find too. > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Ann-TxText-New-text-editor-done-tp4683876p4683990.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

April 28, 2013

Re: [Pharo-project] Trying to understand DateAndTime

by Sean P. DeNigris

Nicolas Cellier wrote > 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. I was a bit confused at first too. You have to click "Resolved" and then you get a whole other set of states, including "fix review needed". I've done it for this issue... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Trying-to-understand-DateAndTime-tp4683997p4684063.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 28, 2013

Re: [Pharo-project] Trying to understand DateAndTime

by Nicolas Cellier

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 >> > >> > >> >> >> >

April 28, 2013

Re: [Pharo-project] Pharo 3.0 TestRunner results

by Benoit St-Jean

Here are the results with Pharo 3.0, update 30068). See attached file. I'm on Windows XP SP3. Â ----------------- Benoit St-Jean Yahoo! Messenger: bstjean Blogue: endormitoire.wordpress.com A standpoint is an intellectual horizon of radius zero. (Albert Einstein)

April 27, 2013

Re: [Pharo-project] Trying to understand DateAndTime

by Nicolas Cellier

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 > > > > > > >

April 27, 2013