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

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

Re: [Pharo-dev] Roadmap on tools?

by Alain Rastoul

I found Ben's dual licensing not clear at all (and explanations and comments even less). â¢GPL v3 license when shipped as part of a programming language, its core libraries and frameworks, or its Integrated Development Environment. â¢MIT license for other cases. As I finally understand it, Pharo would be GPL v3 in all cases. A killer change But as stated in the license agreement (the one found on the old pharo site): "... Supplier hereby grants Distributor a perpetual, irrevocable, non-exclusive, royalty-free, worldwide license to distribute the Software, and specifically the Supplierâs Code therein, to end users, subject to the license agreement commonly known as the âMIT Licenseâ " Ben can change the license of the code he writes to GPL and stop this agreement at that point, but the change in the license is not retroactive, the Pharo version will have to start before revision xxx where it changed and go on it's way. Still there will be a problem in the repository(ies).

Aug. 26, 2014

Re: [Pharo-dev] Athens WorldMorph

by Sven Van Caekenberghe

Yes, very good work. On 26 Aug 2014, at 22:32, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Wow! > > Doru > > > On Tue, Aug 26, 2014 at 10:28 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > here is another one ( attached at the fogbugz issue 13790 ) > It is a magnifier morph that renders all Morphs below the active hand on a athens wrap morph. > > > > > > 2014-08-07 15:35 GMT+02:00 stepharo <stepharo(a)free.fr>: > > Nicolai > > this is great! like that we can debug athensification of current morph :) > > Stef > > > On 7/8/14 12:14, Nicolai Hess wrote: > I created some fogbugz entries for morphs drawing with athens api. > > And a parent case 13790 "Port what is needed for Athens (drawing morphs)" > > We can test the Athens based drawing by putting the morphs into an > AthensWrapMorph. > But this is difficult for Morph like Dialog, Menus and SystemWindows. > > So for testing purpose I attached changeset to the > issue 13790 : > a small hack for making a second WorldMorph working in a Morph. > I omit all the small little details that are needed to make a > second WorldMorph fully working. I just wanted to make > sure the second WorldMorph doesn't constantly try to occupy > the whole display. > The real fun is to put this WorldMorph inside an AthensWrapMorph. > That way we can test Athens based drawing even for Morphs > like the WorldMenu or SystemWindows. > Just drag and drop a Morph or Window between > the Athens WorldMorph and the real WorldMorph. > > Open the AthensWrapWorldMorph with: > AthensWrapWorldMorph new openInWorld > > > nicolai > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Aug. 26, 2014

Re: [Pharo-dev] Failing make a slice

by Sven Van Caekenberghe

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

Re: [Pharo-dev] Athens WorldMorph

by Tudor Girba

Wow! Doru On Tue, Aug 26, 2014 at 10:28 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > here is another one ( attached at the fogbugz issue 13790 ) > <https://pharo.fogbugz.com/default.asp?13790> > It is a magnifier morph that renders all Morphs below the active hand on a > athens wrap morph. > > > > <https://pharo.fogbugz.com/default.asp?13790> > > > 2014-08-07 15:35 GMT+02:00 stepharo <stepharo(a)free.fr>: > > Nicolai >> >> this is great! like that we can debug athensification of current morph :) >> >> Stef >> >> >> On 7/8/14 12:14, Nicolai Hess wrote: >> >>> I created some fogbugz entries for morphs drawing with athens api. >>> >>> And a parent case 13790 "Port what is needed for Athens (drawing morphs)" >>> >>> We can test the Athens based drawing by putting the morphs into an >>> AthensWrapMorph. >>> But this is difficult for Morph like Dialog, Menus and SystemWindows. >>> >>> So for testing purpose I attached changeset to the >>> issue 13790 : >>> a small hack for making a second WorldMorph working in a Morph. >>> I omit all the small little details that are needed to make a >>> second WorldMorph fully working. I just wanted to make >>> sure the second WorldMorph doesn't constantly try to occupy >>> the whole display. >>> The real fun is to put this WorldMorph inside an AthensWrapMorph. >>> That way we can test Athens based drawing even for Morphs >>> like the WorldMenu or SystemWindows. >>> Just drag and drop a Morph or Window between >>> the Athens WorldMorph and the real WorldMorph. >>> >>> Open the AthensWrapWorldMorph with: >>> AthensWrapWorldMorph new openInWorld >>> >>> >>> nicolai >>> >> >> > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 26, 2014