- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Duration year

by Esteban A. Maringolo

I think we discussed this a few months ago. The problem is "unsolvable" as it is now, IMHO, because all the chronology objects are based on "offset" representations (since an epoch), instead of a "field based" representation. IMHO, the only way to have a proper "semantic" representation is to have field based date classes (like Java's Calendar object, not the best implementation though). Ej, which one of the followings is OK? '2012-02-29' asDate + 1 year "=> 2013-02-28" '2011-03-01' asDate + 1 year "=> 2012-02-29" '2011-03-01' asDate addMonths: 12 "=> 2012-03-01" Regards! El Mon Dec 01 2014 at 3:11:56 PM, Chris Cunningham <cunningham.cb(a)gmail.com> escribiÃ³: > Hi. > > I was working on a GenericYear that was intended to be used for > DateAndTime calculus - to be able to add and subtract an arbitrary number > of years. The class by itself would not know the days - it is an arbitrary > (generic) Year. > > It would only know the number of days when it is added (or subtracted) > from an actual date (or timespan). The idea was that it would have a very > specific and limited scope of responsibility. > > -cbc > > On Sat, Nov 22, 2014 at 3:03 AM, Hilaire <hilaire(a)drgeo.eu> wrote: > >> I saw some discussion about Duration and year calculus in the list >> >> Given that it is impossible to determine the number of days in a year >> without the calendar years, should not 365.25 be used in place of 365 to >> minimize the error ? >> >> So it could look like: >> >> Duration class >> years: aNumber >> ^ self days: (aNumber * 365.25) truncated seconds: 0 >> >> >> Hilaire >> >> -- >> Dr. Geo - http://drgeo.eu >> iStoa - http://istoa.drgeo.eu >> >> >> >

Dec. 1, 2014

Re: [Pharo-dev] WhatsUp from: 2014-12-01 until: 2014-12-14

by Mariano Martinez Peck

On Mon, Dec 1, 2014 at 2:00 AM, <seaside(a)rmod.lille.inria.fr> wrote: > Hi! We're sending this automatic email twice a month, to give the > community an opportunity to easily know what's happening and to coordinate > efforts. Just answer informally, and feel free to spawn discussions > thereafter! > > ### Here's what I've been up to since the last WhatsUp: > > > - I gave 3 Smalltalk/Pharo related presentations (Web Development with Smalltalk, Smalltalk and Business, and Marea) at http://ilas.memi.umss.edu.bo/ (sponsored by ESUG). Slides: http://www.slideshare.net/MarianoMartinezPeck/web-development-with-smalltalk http://www.slideshare.net/MarianoMartinezPeck/smalltalk-and-business http://www.slideshare.net/MarianoMartinezPeck/thesis-presentation-14987645 I hope at least to get some guys involved! > > ### What's next, until 2014-12-14 (*): > > > Back to work and update CV. > > (*) we'll be expecting results by then ;) > > -- Mariano http://marianopeck.wordpress.com

Dec. 1, 2014

Re: [Pharo-dev] Video Tutorial - Github for Pharo using Sourcetree

by Thierry Goubier

Le 01/12/2014 19:21, Esteban Lorenzano a Ã©crit : > >> On 01 Dec 2014, at 19:11, Eliot Miranda <eliot.miranda(a)gmail.com >> <mailto:eliot.miranda@gmail.com>> wrote: >> >> Hi Dale, >> >> On Sun, Nov 30, 2014 at 10:52 AM, Dale Henrichs >> <dale.henrichs(a)gemtalksystems.com >> <mailto:dale.henrichs@gemtalksystems.com>> wrote: >> >> Eliot, >> >> If we remove the meta data from the FileTree repo, then it will be >> necessary to use the `adopt` command to restore the proper version >> history before interchanging copying to an mcz repo or trying to >> merge with an mcz package ... >> >> `adopt` is not an ideal solution, which is exactly why I've >> (stubbornly) maintained the monticello meta data ... >> >> >> So *please* continue to be stubborn :-) > > but this is a limitation of gitfiletree. This is a limitation of FileTree, not GitFileTree. > real git integration (using libgit2) should be perfectly capable of > reconstruct history without any metadata. As GitFileTree has been doing without libgit2 for, how long already? > also, in a point (not now, but eventually)â¦ we will need to drop > something. The idea of keeping anything ad eternum just does not scales. But it's a good way of delaying git integration in the Pharo platform by having to redesign the file format as well. Thierry > Esteban > > >> >> My statement about "as the community begins to use git-based repos >> as their primary repository" includes a broad definition of >> community, in my mind:) >> >> >> +1 >> >> Cross-platform package portability has always been one of my >> primary concerns and I do share your concern that it's a big step >> to remove the monticello meta data from FileTree (again it's why I >> haven't done so yet) ... >> >> So far this is a bridge that doesn't need to be crossed, but when >> it becomes time to cross it, there might be other options that can >> be applied (perhaps an ancestry can be synthesized from the git >> meta data?) > > exactly. > >> >> Which would be reasonable, but it needs to be there. And thanks. >> >> Dale >> >> >> >> >> On Sun, Nov 30, 2014 at 9:31 AM, Eliot Miranda >> <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: >> >> Hi Dale, >> >> On Nov 30, 2014, at 8:14 AM, Dale Henrichs >> <dale.henrichs(a)gemtalksystems.com >> <mailto:dale.henrichs@gemtalksystems.com>> wrote: >> >>> >>> >>> On Sun, Nov 30, 2014 at 7:51 AM, kilon alios >>> <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: >>> >>> So far all I knew that using git for binary files was a >>> no go, doable but not recommended. Thus I found strange >>> that filetree uses binary files. >>> >>> >>> Well the files are text files, but because the text >>> represents structured data, the line-based auto-merge used by >>> git is not correct ... >>> >>> The monticello version files have been included in FileTree >>> to make it possible to move the packages seamlessly between >>> Filetree-based repositories and mcz based repositories ... >>> without that meta data, once you move a package to FileTree >>> it could not be moved back into an mcz repository without >>> losing all of the package history. >>> >>> When I was first introducing FileTree, I thought it was >>> important that folks be able to test out the git waters >>> without making an "irreversible commitment to git." Even >>> today I find myself needing to move packages back and forth >>> between git and mcz repositories, so Thierry's merge-tools >>> has made it possible for me to have my cake and eat it too. >>> >>> I have been threatening to remove the monticello meta data >>> from FileTree (or at least make it optional), but I just >>> haven't had the time or motivation to do so ... again >>> Thierry's merge-tool means that I never have to deal with a >>> manual merge of the version file, so for me I never have to >>> think about it ... >>> >>> As the tool sets for supporting git improve and as the >>> community begins to use git-based repos as their primary >>> repository, it will make sense to remove the monticello meta >>> data from FileTree ... >> >> Will that mean that packages will still be able to be >> interchanged with Monticello? If yes, will that mean that >> packages will still be able to be merged with Monticello? >> >>> Dale >> >> >> >> >> >> -- >> best, >> Eliot >

Dec. 1, 2014

ubuntu vm build

by Norbert Hartl

Hi, I forgot who is maintaining the ubuntu launchpad ppa vm build. But whoever you are ( :) ) would it be possible to include a vm build for the actual ubuntu release utopic unicorn? thanks, Norbert

Dec. 1, 2014

Re: [Pharo-dev] Video Tutorial - Github for Pharo using Sourcetree

by Esteban Lorenzano

> On 01 Dec 2014, at 19:11, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Dale, > > On Sun, Nov 30, 2014 at 10:52 AM, Dale Henrichs <dale.henrichs(a)gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote: > Eliot, > > If we remove the meta data from the FileTree repo, then it will be necessary to use the `adopt` command to restore the proper version history before interchanging copying to an mcz repo or trying to merge with an mcz package ... > > `adopt` is not an ideal solution, which is exactly why I've (stubbornly) maintained the monticello meta data ... > > So *please* continue to be stubborn :-) but this is a limitation of gitfiletree. real git integration (using libgit2) should be perfectly capable of reconstruct history without any metadata. also, in a point (not now, but eventually)â¦ we will need to drop something. The idea of keeping anything ad eternum just does not scales. Esteban > > My statement about "as the community begins to use git-based repos as their primary repository" includes a broad definition of community, in my mind:) > > +1 > > Cross-platform package portability has always been one of my primary concerns and I do share your concern that it's a big step to remove the monticello meta data from FileTree (again it's why I haven't done so yet) ... > > So far this is a bridge that doesn't need to be crossed, but when it becomes time to cross it, there might be other options that can be applied (perhaps an ancestry can be synthesized from the git meta data?) exactly. > > Which would be reasonable, but it needs to be there. And thanks. > > Dale > > > > > On Sun, Nov 30, 2014 at 9:31 AM, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: > Hi Dale, > > On Nov 30, 2014, at 8:14 AM, Dale Henrichs <dale.henrichs(a)gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote: > >> >> >> On Sun, Nov 30, 2014 at 7:51 AM, kilon alios <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: >> So far all I knew that using git for binary files was a no go, doable but not recommended. Thus I found strange that filetree uses binary files. >> >> >> Well the files are text files, but because the text represents structured data, the line-based auto-merge used by git is not correct ... >> >> The monticello version files have been included in FileTree to make it possible to move the packages seamlessly between Filetree-based repositories and mcz based repositories ... without that meta data, once you move a package to FileTree it could not be moved back into an mcz repository without losing all of the package history. >> >> When I was first introducing FileTree, I thought it was important that folks be able to test out the git waters without making an "irreversible commitment to git." Even today I find myself needing to move packages back and forth between git and mcz repositories, so Thierry's merge-tools has made it possible for me to have my cake and eat it too. >> >> I have been threatening to remove the monticello meta data from FileTree (or at least make it optional), but I just haven't had the time or motivation to do so ... again Thierry's merge-tool means that I never have to deal with a manual merge of the version file, so for me I never have to think about it ... >> >> As the tool sets for supporting git improve and as the community begins to use git-based repos as their primary repository, it will make sense to remove the monticello meta data from FileTree ... > > Will that mean that packages will still be able to be interchanged with Monticello? If yes, will that mean that packages will still be able to be merged with Monticello? > >> Dale > > > > > -- > best, > Eliot

Dec. 1, 2014

Re: [Pharo-dev] SmalltalkHub bugs & hangs :-(

by Esteban A. Maringolo

El Mon Dec 01 2014 at 12:19:53 PM, Andreas Wacknitz <A.Wacknitz(a)gmx.de> escribiÃ³: > > Am 01.12.14 12:34, schrieb kilon alios: > > No of course not. That would have been a deal braker. > > Personally I prefer using Sourcetree to browser history of commits than > using the pharo on board tools. Pharo is good on that respect, but > sourcetree is better > > Alas Sourcetree is only available for Windows and Mac OSX. > Non-portable programs die with their system. > Closed source programs die with their company. > It's not a matter of SourceTree or other program, it's about your git GUI app of preference. You can use plain git from the command line if you prefer. The git repo is portable, the client is up to you.

Dec. 1, 2014

Re: [Pharo-dev] Video Tutorial - Github for Pharo using Sourcetree

by Eliot Miranda

Hi Dale, On Sun, Nov 30, 2014 at 10:52 AM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > Eliot, > > If we remove the meta data from the FileTree repo, then it will be > necessary to use the `adopt` command to restore the proper version history > before interchanging copying to an mcz repo or trying to merge with an mcz > package ... > > `adopt` is not an ideal solution, which is exactly why I've (stubbornly) > maintained the monticello meta data ... > So *please* continue to be stubborn :-) My statement about "as the community begins to use git-based repos as their > primary repository" includes a broad definition of community, in my mind:) > +1 Cross-platform package portability has always been one of my primary > concerns and I do share your concern that it's a big step to remove the > monticello meta data from FileTree (again it's why I haven't done so yet) > ... > > So far this is a bridge that doesn't need to be crossed, but when it > becomes time to cross it, there might be other options that can be applied > (perhaps an ancestry can be synthesized from the git meta data?) > Which would be reasonable, but it needs to be there. And thanks. Dale > > > > > On Sun, Nov 30, 2014 at 9:31 AM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> Hi Dale, >> >> On Nov 30, 2014, at 8:14 AM, Dale Henrichs < >> dale.henrichs(a)gemtalksystems.com> wrote: >> >> >> >> On Sun, Nov 30, 2014 at 7:51 AM, kilon alios <kilon.alios(a)gmail.com> >> wrote: >> >>> So far all I knew that using git for binary files was a no go, doable >>> but not recommended. Thus I found strange that filetree uses binary files. >>> >>> >> Well the files are text files, but because the text represents structured >> data, the line-based auto-merge used by git is not correct ... >> >> The monticello version files have been included in FileTree to make it >> possible to move the packages seamlessly between Filetree-based >> repositories and mcz based repositories ... without that meta data, once >> you move a package to FileTree it could not be moved back into an mcz >> repository without losing all of the package history. >> >> When I was first introducing FileTree, I thought it was important that >> folks be able to test out the git waters without making an "irreversible >> commitment to git." Even today I find myself needing to move packages back >> and forth between git and mcz repositories, so Thierry's merge-tools has >> made it possible for me to have my cake and eat it too. >> >> I have been threatening to remove the monticello meta data from FileTree >> (or at least make it optional), but I just haven't had the time or >> motivation to do so ... again Thierry's merge-tool means that I never have >> to deal with a manual merge of the version file, so for me I never have to >> think about it ... >> >> As the tool sets for supporting git improve and as the community begins >> to use git-based repos as their primary repository, it will make sense to >> remove the monticello meta data from FileTree ... >> >> >> Will that mean that packages will still be able to be interchanged with >> Monticello? If yes, will that mean that packages will still be able to >> be merged with Monticello? >> >> Dale >> >> > -- best, Eliot

Dec. 1, 2014

Re: [Pharo-dev] Duration year

by Chris Cunningham

Hi. I was working on a GenericYear that was intended to be used for DateAndTime calculus - to be able to add and subtract an arbitrary number of years. The class by itself would not know the days - it is an arbitrary (generic) Year. It would only know the number of days when it is added (or subtracted) from an actual date (or timespan). The idea was that it would have a very specific and limited scope of responsibility. -cbc On Sat, Nov 22, 2014 at 3:03 AM, Hilaire <hilaire(a)drgeo.eu> wrote: > I saw some discussion about Duration and year calculus in the list > > Given that it is impossible to determine the number of days in a year > without the calendar years, should not 365.25 be used in place of 365 to > minimize the error ? > > So it could look like: > > Duration class >> years: aNumber > ^ self days: (aNumber * 365.25) truncated seconds: 0 > > > Hilaire > > -- > Dr. Geo - http://drgeo.eu > iStoa - http://istoa.drgeo.eu > > >

Dec. 1, 2014

Re: [Pharo-dev] WhatsUp from: 2014-12-01 until: 2014-12-14

by Tudor Girba

On Mon, Dec 1, 2014 at 5:51 PM, Ben Coman <btc(a)openinworld.com> wrote: > seaside(a)rmod.lille.inria.fr wrote: > >> Hi! We're sending this automatic email twice a month, to give the >> community an opportunity to easily know what's happening and to coordinate >> efforts. Just answer informally, and feel free to spawn discussions >> thereafter! >> >> ### Here's what I've been up to since the last WhatsUp: >> >> > * Made my first contribution to the VM, adding <modifier> keypress events > for OSX. > Thanks a lot for that! :) Doru -- www.tudorgirba.com "Every thing has its own flow"

Dec. 1, 2014

Re: [Pharo-dev] [pharo-project/pharo-core]

by Esteban Lorenzano

but it didnât work so we will need to insist :( Esteban > On 01 Dec 2014, at 18:13, GitHub <noreply(a)github.com> wrote: > > Branch: refs/heads/4.0 > Home: https://github.com/pharo-project/pharo-core > Commit: 6f6c06023fa6406371a1e66a33159f03ea6427a2 > https://github.com/pharo-project/pharo-core/commit/6f6c06023fa6406371a1e66a… > Author: Jenkins Build Server <board(a)pharo-project.org> > Date: 2014-12-01 (Mon, 01 Dec 2014) > > Changed paths: > M EmbeddedFreeType.package/EmbeddedFreeTypeFontFontDescription.class/class/accessing/fontContents.st > M EmbeddedFreeType.package/EmbeddedFreeTypeFontFontDescription.class/class/accessing/installAllFontsIn_.st > M EmbeddedFreeType.package/EmbeddedFreeTypeFontFontDescription.class/class/accessing/installFontsIn_.st > M EmbeddedFreeType.package/EmbeddedFreeTypeFontFontDescription.class/class/accessing/originalFileName.st > M EmbeddedFreeType.package/EmbeddedFreeTypeFontInstaller.class/class/accessing/current.st > M EmbeddedFreeType.package/EmbeddedFreeTypeFontInstaller.class/class/extra fonts registration/registerFont_.st > R EmbeddedFreeType.package/OpenSansRegular.class/README.md > R EmbeddedFreeType.package/OpenSansRegular.class/class/accessing/fontContents.st > R EmbeddedFreeType.package/OpenSansRegular.class/class/accessing/originalFileName.st > R EmbeddedFreeType.package/OpenSansRegular.class/class/class initialization/initialize.st > R EmbeddedFreeType.package/OpenSansRegular.class/definition.st > M EmbeddedFreeType.package/SourceCodeFonts.class/class/accessing/defaultFontName.st > A EmbeddedFreeType.package/SourceCodeFonts.class/class/accessing/setSourceCodeFontsDefault.st > M EmbeddedFreeType.package/SourceCodeFonts.class/class/font registration/registerFonts_.st > A EmbeddedFreeType.package/SourceSansProRegular.class/README.md > A EmbeddedFreeType.package/SourceSansProRegular.class/class/accessing/fontContents.st > A EmbeddedFreeType.package/SourceSansProRegular.class/class/accessing/originalFileName.st > A EmbeddedFreeType.package/SourceSansProRegular.class/class/class initialization/initialize.st > A EmbeddedFreeType.package/SourceSansProRegular.class/definition.st > M FreeType.package/FreeTypeFontProvider.class/instance/loading and updating/updateEmbeddedFreeTypeFonts.st > M FreeType.package/FreeTypeFontProvider.class/instance/loading and updating/updateFromSystem.st > M FreeType.package/FreeTypeSettings.class/class/startup/startUp_.st > A FreeType.package/FreeTypeSettings.class/class/startup/updateFreeType.st > A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script393.st > A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40393.st > M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st > > Log Message: > ----------- > 40393 > 14553 FreeType default fonts not correctly loaded when image initializes > https://pharo.fogbugz.com/f/cases/14553 > > http://files.pharo.org/image/40/40393.zip > >

Dec. 1, 2014