August 2014 - Pharo-dev - lists.pharo.org

Substitution of ' to " in TextEditor>>shiftEnclose

by Maximilian Bareis

Hi, I am wondering if the upper part of TextEditor>>shiftEnclose: aKeyboardEvent "Insert or remove bracket characters around the current selection." | char left right startIndex stopIndex oldSelection which text | char := aKeyboardEvent keyCharacter. char = $9 ifTrue: [ char := $( ]. char = $, ifTrue: [ char := $< ]. char = $[ ifTrue: [ char := ${ ]. char = $' ifTrue: [ char := $" ]. is a bug or a feature. For german keyboards it causes that pressing the single Apostroph (which is reached via shift-#) is substituted to ". So enclosing a textblock and pressing ' leads to comments around the block, which is really annoying. I am curious, because this substitution does not make any sense to me. The keyCharacter is always the "real" character ( $( instead of $9 ). Also it seems that this substitution reduces the keyboard to the en-Layout, therefore breaks the separation of concerns. Is there any reason, why this substitution takes place? Regards Max

Aug. 27, 2014

Re: [Pharo-dev] Fwd: A UTC based implementation of DateAndTime

by Pavel Krivanek

Yes, Cami made a lot of great work on making DateAndTime UTC based. Cheers, -- Pavel 2014-08-27 12:02 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Pharo's DateAndTime is not the same as Squeak's. > > We are properly UTC based/aware, see #secondsSinceMidnightUTC and #julianDayNumberUTC. > > It is indeed perfectly possible to represent time using one number, but it will not be a SmallInteger. And depending on precision is will be a very large number. The split julian day number - seconds since midnight feels quite logical and practical to me. > > But yes, the 'date' concept is often confusing and difficult to handle in the light of timezones. To me, an old school, abstract Date object year/month/day would make sense. But then again, there are so many calendar systems, chronology is quite complicated. > > BasicJulianDate ? > > On 27 Aug 2014, at 01:10, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > >> From >> http://forum.world.st/What-s-up-on-build-squeak-org-tp4760266p4760319.html : >> >> >> David T. Lewis wrote >>> I have been working on a variation of class DateAndTime that replaces its >>> instance variables (seconds offset jdn nanos) with two instance variables, >>> utcMicroseconds to represent microseconds elapsed since the Posix epoch, >>> and >>> localOffsetSeconds to represent the local time zone offset. When >>> instantiating >>> the time now, A single call primitiveUtcWithOffset is used to obtain these >>> two values atomically as reported by the underlying platform. >>> >>> There are several advantages to this representation of DateAndTime, the >>> most >>> important of which is that its magnitude is unambiguous regardless of >>> daylight >>> savings transitions in local time zones. >>> >>> This is my attempt to address some historical baggage in Squeak. The VM >>> reports time related to the local time zone, and the image attempts to >>> convert to UTC (sometimes incorrectly). A UTC based representation makes >>> the >>> implementation of time zone tables more straightforward (see for example >>> the Olson time zone tables in TimeZoneDatabase on SqueakMap). >>> >>> I am attaching the source code as a SAR file that can be loaded into a >>> fully >>> updated Squeak trunk image. The conversion process is slow, so be patient >>> if you load it. >>> >>> This can be run on either an intepreter VM or Cog, but if you use Cog, >>> please >>> use a version dated June 2013 or later (the VM in the Squeak 4.5 >>> all-in-one >>> is fine). >>> >>> I am also attaching a copy of LXTestDateAndTimePerformance, which can be >>> used to compare the performance of some basic DateAndTime functions. >>> >>> Performance of the UTC based DateAndTime is generally favorable compared >>> to >>> the original. Here is what I see on my system (smaller numbers are >>> better). >>> >>> LXTestDateAndTimePerformance test results using the original Squeak >>> DateAndTime >>> on an interpreter VM: >>> { >>> #testNow->10143 . >>> #testEquals->30986 . >>> #testGreaterThan->80199 . >>> #testLessThan->75912 . >>> #testPrintString->10429 . >>> #testStringAsDateAndTime->44657 >>> } >>> >>> LXTestDateAndTimePerformance test results using the new UTC based >>> DateAndTime >>> on an interpreter VM: >>> { >>> #testNow->6423 . >>> #testEquals->31625 . >>> #testGreaterThan->22999 . >>> #testLessThan->18514 . >>> #testPrintString->12502 . >>> #testStringAsDateAndTime->32912 >>> } >>> >>> (CC to Brent Pinkney, author of the excellent Squeak Chronology package) >>> >>> Dave >>> >>> >>> >>> >>> >>> UtcDateAndTime-dtl.sar (40K) >>> <http://forum.world.st/attachment/4760319/0/UtcDateAndTime-dtl.sar> >>> LXTestDateAndTimePerformance.st (2K) >>> <http://forum.world.st/attachment/4760319/1/LXTestDateAndTimePerformance.st> >> >> >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/Fwd-A-UTC-based-implementation-of-DateAndTime-tp47749… >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> > >

Aug. 27, 2014

Re: [Pharo-dev] Cyrillic handling

by Yuriy Tymchuk

Latest pharo vm. OS X Ukrainian keyboard layout. Uko On 27 Aug 2014, at 14:17, phil(a)highoctane.be wrote: > Which VM? > Which layout? > > Phil > > Le 27 aoÃ»t 2014 13:27, "Yuriy Tymchuk" <yuriy.tymchuk(a)me.com> a Ã©crit : > Hi guys. > > Sometimes I exigently type cyrillic characters (because I have 2 keyboard layouts). When I do this, besides of typing just the characters, some shortcuts re triggered. Is it easy to fixe that? Because sometimes I mess up my code like this :) > > Uko

Aug. 27, 2014

Re: [Pharo-dev] Cyrillic handling

by phil＠highoctane.be

Which VM? Which layout? Phil Le 27 aoÃ»t 2014 13:27, "Yuriy Tymchuk" <yuriy.tymchuk(a)me.com> a Ã©crit : > Hi guys. > > Sometimes I exigently type cyrillic characters (because I have 2 keyboard > layouts). When I do this, besides of typing just the characters, some > shortcuts re triggered. Is it easy to fixe that? Because sometimes I mess > up my code like this :) > > Uko >

Aug. 27, 2014

Re: [Pharo-dev] Failing make a slice

by Juraj Kubelka

Thanks :) -- Juraj Kubelka > El 27/08/2014, a las 02:50, Sven Van Caekenberghe <sven(a)stfx.eu> escribiÃ³: > > >> On 27 Aug 2014, at 04:19, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: >> >> Have you made the slice using Monticello or Komitter? It was a first time I have used Komitter and maybe I have used it wrong. > > Manually using the good old Monticello Browser. > >> Thanks for the help. It was useful. And when the slice will be integrated, I will continue the refactoring of the fonts. >> >> Juraj >> >>> El 26-08-2014, a las 16:37, Sven Van Caekenberghe <sven(a)stfx.eu> escribiÃ³: >>> >>> What I did was: >>> >>> - do a fresh image download and work with an empty local package-cache >>> - locate your dependent packages in the 40 inbox and merge each of them in >>> - create a slice based on the issue number >>> - include (check) the dirty packages, as well as one package that refused to get dirty >>> - verify that the slice package had the correct dependents >>> - save the slice with a version number higher than your latest one in the 40 inbox >>> >>> Since it verified correctly by the monkey, we're indeed ready to integrate. >>> >>> Thanks for your work ! >>> >>>> On 26 Aug 2014, at 21:49, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: >>>> >>>> Thank you a lot Sven, it works perfectly. Now it waits for the integration. >>>> >>>> Juraj >>>> >>>>> El 26-08-2014, a las 8:12, Sven Van Caekenberghe <sven(a)stfx.eu> escribiÃ³: >>>>> >>>>> I tried to make a new slice, can you see if it works for you (i.e. contains your changes) ? >>>>> >>>>>> On 25 Aug 2014, at 19:26, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I have failed to make new slice for this issue: https://pharo.fogbugz.com/f/cases/13185/Move-embedded-fonts-from-Freetype-p… >>>>>> >>>>>> The last slice I have made depends on packages which has the same name but different UUID. >>>>>> >>>>>> How can I fix this? The issue should depend on FreeType-JurajKubelka.677, EmbeddedFreeType-JurajKubelka.3, EmbeddedFreeTypeTests-JurajKubelka.2. >>>>>> >>>>>> Thanks, >>>>>> Juraj > >

Aug. 27, 2014

Cyrillic handling

by Yuriy Tymchuk

Hi guys. Sometimes I exigently type cyrillic characters (because I have 2 keyboard layouts). When I do this, besides of typing just the characters, some shortcuts re triggered. Is it easy to fixe that? Because sometimes I mess up my code like this :) Uko

Aug. 27, 2014

Re: [Pharo-dev] Fwd: A UTC based implementation of DateAndTime

by Sven Van Caekenberghe

Pharo's DateAndTime is not the same as Squeak's. We are properly UTC based/aware, see #secondsSinceMidnightUTC and #julianDayNumberUTC. It is indeed perfectly possible to represent time using one number, but it will not be a SmallInteger. And depending on precision is will be a very large number. The split julian day number - seconds since midnight feels quite logical and practical to me. But yes, the 'date' concept is often confusing and difficult to handle in the light of timezones. To me, an old school, abstract Date object year/month/day would make sense. But then again, there are so many calendar systems, chronology is quite complicated. BasicJulianDate ? On 27 Aug 2014, at 01:10, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > From > http://forum.world.st/What-s-up-on-build-squeak-org-tp4760266p4760319.html : > > > David T. Lewis wrote >> I have been working on a variation of class DateAndTime that replaces its >> instance variables (seconds offset jdn nanos) with two instance variables, >> utcMicroseconds to represent microseconds elapsed since the Posix epoch, >> and >> localOffsetSeconds to represent the local time zone offset. When >> instantiating >> the time now, A single call primitiveUtcWithOffset is used to obtain these >> two values atomically as reported by the underlying platform. >> >> There are several advantages to this representation of DateAndTime, the >> most >> important of which is that its magnitude is unambiguous regardless of >> daylight >> savings transitions in local time zones. >> >> This is my attempt to address some historical baggage in Squeak. The VM >> reports time related to the local time zone, and the image attempts to >> convert to UTC (sometimes incorrectly). A UTC based representation makes >> the >> implementation of time zone tables more straightforward (see for example >> the Olson time zone tables in TimeZoneDatabase on SqueakMap). >> >> I am attaching the source code as a SAR file that can be loaded into a >> fully >> updated Squeak trunk image. The conversion process is slow, so be patient >> if you load it. >> >> This can be run on either an intepreter VM or Cog, but if you use Cog, >> please >> use a version dated June 2013 or later (the VM in the Squeak 4.5 >> all-in-one >> is fine). >> >> I am also attaching a copy of LXTestDateAndTimePerformance, which can be >> used to compare the performance of some basic DateAndTime functions. >> >> Performance of the UTC based DateAndTime is generally favorable compared >> to >> the original. Here is what I see on my system (smaller numbers are >> better). >> >> LXTestDateAndTimePerformance test results using the original Squeak >> DateAndTime >> on an interpreter VM: >> { >> #testNow->10143 . >> #testEquals->30986 . >> #testGreaterThan->80199 . >> #testLessThan->75912 . >> #testPrintString->10429 . >> #testStringAsDateAndTime->44657 >> } >> >> LXTestDateAndTimePerformance test results using the new UTC based >> DateAndTime >> on an interpreter VM: >> { >> #testNow->6423 . >> #testEquals->31625 . >> #testGreaterThan->22999 . >> #testLessThan->18514 . >> #testPrintString->12502 . >> #testStringAsDateAndTime->32912 >> } >> >> (CC to Brent Pinkney, author of the excellent Squeak Chronology package) >> >> Dave >> >> >> >> >> >> UtcDateAndTime-dtl.sar (40K) >> <http://forum.world.st/attachment/4760319/0/UtcDateAndTime-dtl.sar> >> LXTestDateAndTimePerformance.st (2K) >> <http://forum.world.st/attachment/4760319/1/LXTestDateAndTimePerformance.st> > > > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Fwd-A-UTC-based-implementation-of-DateAndTime-tp47749… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Aug. 27, 2014

Re: [Pharo-dev] Pharo Development Robustness (was: Why Bloc?)

by stepharo

Hi sean Thanks for this mail!!!! About bloc --------- I discussed with alain about this point at ESUG. Alain would like to finish the handlers and a couple of other points, clean everything and release a first version. The problem is that alain is often doing trial and changes. Here is where I think you can help: - turn some of the example for the layouts into tests - start to clean/revisit some basic morphs so that we can turn them into bloc counterparts easily. - I started to look at buttonMorph* - I started to rewrite MenuMorph because it is full of old code. I would like to remove the direct manipulation because it adds a lot of problems. If you want to join let me know. About TxText ------------ - Igor added morphs in text at ESUG and he was revisiting it yesterday. - we should make sure that the configuration is loading in 40 -now mocketry is loading in 40 so the configuration of TxText should be working. - we should check the current use of TextMorph and friends and use TxText Stef On 27/8/14 01:48, Sean P. DeNigris wrote: > The most important items on our IU Experience agenda - Tx and Bloc - are > totally reliant on two (brilliant, talented...) programmers while the rest > of the community hopes and waits. In no way to I lack appreciation for Alain > and Igor's efforts, but this does not seem like a robust or efficient use of > our manpower... So, I guess what I'm really asking for both projects is - > how can we help? > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Pharo-Development-Robustness-was-Why-Bloc-tp4774980.h… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Aug. 27, 2014

Sprint 29/8 still planned?

by phil＠highoctane.be

Is there a sprint in Lille as announced a while ago? I'd be delighted to join :-) Phil

Aug. 27, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40191 Home: https://github.com/pharo-project/pharo-core

Aug. 27, 2014