- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

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

Aug. 27, 2014

[pharo-project/pharo-core] 227f20: 40189

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 227f2067333516db6f8be7a7608380f4ceb89c61 https://github.com/pharo-project/pharo-core/commit/227f2067333516db6f8be7a7… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-08-27 (Wed, 27 Aug 2014) Changed paths: M AST-Core.package/RBMessageNode.class/instance/comparing/=.st M AST-Core.package/RBMessageNode.class/instance/comparing/equalTo_withMapping_.st M AST-Core.package/RBMessageNode.class/instance/matching/match_inContext_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script189.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40189.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40189 13918 RBMessageNode uses #to:do: instead of #with:do: (Coding Idiom Violation) https://pharo.fogbugz.com/f/cases/13918 http://files.pharo.org/image/40/40189.zip

Aug. 27, 2014

Re: [Pharo-dev] athens wrapper for (Form-)Canvas

by stepharo

Igor we should integrate TxText as soon as the new integration handle configurations (normally next week). So can you get prepared? Stef On 26/8/14 17:43, Igor Stasenko wrote: > > > > On 26 August 2014 00:24, Nicolai Hess <nicolaihess(a)web.de > <mailto:nicolaihess@web.de>> wrote: > > I tried an alternative approach for rendering Morphs on athens without > implementing drawOnAthensCanvas for every morph: > > 13866 <https://pharo.fogbugz.com/default.asp?13866> > AthensFormCanvasWrapper > > still struggling with the text rendering. Yet I am not sure what > is the > better approach. > > > A new text model, which i am working on :) > > > Nicolai > > > > > -- > Best regards, > Igor Stasenko.

Aug. 27, 2014

Re: [Pharo-dev] All-you-can-eat JSON

by stepharo

thanks > Sean P. DeNigris wrote >> 2. http://smalltalkhub.com/#!/~PharoExtras/JSON, and > Pharo 3.0: Loads via #stable and all tests pass; config copied to > MetaRepo...30 > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/All-you-can-eat-JSON-tp4774925p4774926.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Aug. 27, 2014

Re: [Pharo-dev] Failing make a slice

by Sven Van Caekenberghe

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

Re: [Pharo-dev] Failing make a slice

by Juraj Kubelka

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

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

by Sean P. DeNigris

The following are great starting points, but I would like to see something more actionable. For example an issue for each with enough info and clear goal for a community member to start coding straight away... stepharo wrote > Now there is a risk that alain does not deliver so we should > - look at what he is doing > - we try to document the classes > - I'm trying to move some cleans/ideas from bloc to Morphic > (introducing Margin, cleaning layoutFrame is a way to improve) > - Since bloc runs inside morphic, cleaning morphic reduces the > morphic behavior that creeps in Bloc > > Here are some ideas to help > - for example, if you want to make bloc use Athens transformation > - write more tests > - write stupid examples > > - I'm cleaning menumorph and rewriting a menuMorph for Morphic > with the hope that we can blocify the code > so that I can propose some simple MenuMorph to Bloc. > I'm busy with project proposal writing and other duties but if > you want you can join. > > - I'm doing the same with theme and basic widgets. > - Can we do a simple button in Bloc? > - clean the one we have in Morphic > > > Alain would like to use Athens for the rendering of Bloc elements .... > so this is another nice project to help. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-Development-Robustness-was-Why-Bloc-tp4774980p4… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 26, 2014

Pharo Development Robustness (was: Why Bloc?)

by Sean P. DeNigris

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. 26, 2014

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

by Esteban A. Maringolo

Nice. Could be named ZDateAndTime :P Esteban A. Maringolo 2014-08-26 20:10 GMT-03:00 Sean P. DeNigris <sean(a)clipperadams.com>: > 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. 26, 2014

Fwd: A UTC based implementation of DateAndTime

by Sean P. DeNigris

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. 26, 2014