September 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] git support

by Max Leske

Be sure to use the version from the experimental branch (FSGit-Experimental) and to use the gemstone repo (the github repo is up to date but you wouldn't be able to load the traits) Max On 07.09.2012, at 16:15, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Excellent...I'll take it for a spin soonly and let you know how it goes! > > Dale > > ----- Original Message ----- > | From: "Max Leske" <maxleske(a)gmail.com> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Friday, September 7, 2012 6:54:20 AM > | Subject: Re: [Pharo-project] git support > | > | Runs on 1.4 and 2.0 as long as you manually backport the newest > | filesystem packages (I've got both images on my machine and it works > | fine). > | > | > | On 07.09.2012, at 15:32, Camillo Bruni <camillobruni(a)gmail.com> > | wrote: > | > | > On 2012-09-07, at 15:29, Dale Henrichs <dhenrich(a)vmware.com> wrote: > | >> Does FsGit run in Pharo1.4 or is ti Pharo2.0 only ... if it ran in > | >> Pharo1.4 I would start using it in my daily work:) > | > > | > so that's a motivation to get it up and running in 1.4 :P > | > With FileSystem being backported I don't see any immediate problems > | > ahead... > | > > | >> ----- Original Message ----- > | >> | From: "Camillo Bruni" <camillobruni(a)gmail.com> > | >> | To: Pharo-project(a)lists.gforge.inria.fr > | >> | Sent: Friday, September 7, 2012 6:22:44 AM > | >> | Subject: Re: [Pharo-project] git support > | >> | > | >> | > | >> | On 2012-09-07, at 15:13, Dale Henrichs <dhenrich(a)vmware.com> > | >> | wrote: > | >> | > Cami, > | >> | > > | >> | > What kind of work needs to be done for the Cypress-compatible > | >> | > format? I've done a couple of different implementations > | >> | > already:) > | >> | > So I can definitely do one more ... If you give me the name of > | >> | > the > | >> | > class that is the entry point for read/write then I can take > | >> | > it > | >> | > from there ... > | >> | > | >> | Since you ported it to the new FileSystem I don't have to change > | >> | much > | >> | :) > | >> | The git stuff works on top of the new FileSystem, thus > | >> | completely > | >> | transparent to > | >> | whatever FileOperations you used. > | >> | > | >> | - load filetree > | >> | - use filetree instead of my own git exporter > | >> | - use filetree for recreating mc snapshots > | >> | > | >> | I will try to hook that up this weekend, then I need busy > | >> | testers :P > | >> | > | >> | > | >> | > Metacello integration is also among the "missing" from the > | >> | > perspective that I want some real users using the Metacello > | >> | > Preview[1] and giving me feedback[2] before I make a general > | >> | > release. > | >> | > | >> | I guess we could push some work to Versionner? That would then > | >> | have > | >> | to interact > | >> | with the low-level git filesystem to set the tags / commits > | >> | > | >> | > Also keep in mind that we will need to be inventing the > | >> | > Smalltalk > | >> | > workflow for git... > | >> | > | >> | yes :) I hope to get closer to that once I have a running > | >> | implementation in pharo.. > | >> | > | >> | > Dale > | >> | > > | >> | > [1] > | >> | > https://github.com/dalehenrich/metacello-work/blob/master/README.md > | >> | > [2] https://groups.google.com/group/metacello/ > | >> | > > | >> | > ----- Original Message ----- > | >> | > | From: "Camillo Bruni" <camillobruni(a)gmail.com> > | >> | > | To: "Pharo-project(a)lists.gforge.inria.fr Development" > | >> | > | <pharo-project(a)lists.gforge.inria.fr> > | >> | > | Sent: Friday, September 7, 2012 4:15:46 AM > | >> | > | Subject: [Pharo-project] git support > | >> | > | > | >> | > | who will help? > | >> | > | > | >> | > | max and I, stimulated by ESUG, worked on the latest version > | >> | > | of > | >> | > | FS-Git > | >> | > | to make it stable again. > | >> | > | we are very close to have a complete set of git tools > | >> | > | written in > | >> | > | pharo ready! > | >> | > | > | >> | > | missing > | >> | > | ======= > | >> | > | - a better mc integration > | >> | > | - a cypress compatible fileout format > | >> | > | - complete interaction with the git protocol > | >> | > | - a direct way to commit stuff > | >> | > | > | >> | > | as always my time is somewhat limited as well and we're the > | >> | > | only > | >> | > | two > | >> | > | developers working on it... > | >> | > | > | >> | > | The current work is available here: > | >> | > | http://ss3.gemstone.com/ss/FSGit-Experimental.html > | >> | > | https://github.com/dalehenrich/FSGit > | >> | > | > | >> | > | best > | >> | > | cami > | >> | > | > | >> | > > | >> | > | >> | > | >> | > | >> > | > > | > > | > | > | >

Sept. 7, 2012

[Pharo-project] RPackage, Monticello and the removal of PackageInfo

by Esteban Lorenzano

Hi, As you know, we want to replace the old PackageInfo structure with RPackage. Last weeks Pharo 2.0 has been really unstable because of this effort, and it will be unstable yet a few days more, so I want to review the actions we are taking, so you know why this happnes and the result we want to obtain. So... first: Why replace PackageInfo and PackageOrganizer? The short answer is: because they suck :) The more or less long answer is: because their existence introduces a lot of penalties in the system, and forces to a lot of workarounds to manage what should be a simple system categories manager... take for instance the match MCPackage-PackageInfo-Class categories. Each MCPackage maps to a unique PackageInfo, but package info contains string pattern matched class categories. Tools uses this and well... performance is frankly disappointing in many case. Like this, there are lots of other reasons. So... RPackage will solve this by keeping a view of the system, not having to calculate it everytime. RPackage will keep also the list of classes, extension, etc. so tools can operate with them in a better/faster way. Question is: How to migrate in the less painful way? Attempt 1) Let each RPackage be one PackageInfo. We first thought this was the best path so, we spend some time moving in that direction. The advantage is that migration from Monticello and PackageInfo is trivial, but then the problems started to happen: PackageInfo (and current RPackage) contains N class categories so, there is an impedance mismatch between what we was seeing and what users/tools expect (they work with class categories, not with RPackage or PackageInfo). To solve that, we added class categories as RPackage tags (yep RPackage allows you to tag classes). But then we need to update in ver annoying ways the tools. And we also has now the fact that class categories are now a tag into an RPackage. Something really obscure and that was causing a lot of pain... So, we rolled back... Attempt 2) Let each Class Category be one RPackage. Ok, this is very simple (and that's the beauty on it)... each tools and conventions will match perfectly. Only problem here is that now, Monticello is not compatible anymore. So, we worked on the concept of RPackageSet, to replace PackageInfo use into Monticelo packages (we need them to load/save packages and stay compatible). RPackageSet is exactly what its name says: a set of RPackage instances (created on the fly, by pattern matching, so, is still some kind of a hack), that is polymorphic with PackageInfo in the monticello context. Thus, everything in the system can remain unchanged (or almost no change, the refactoring engine needs some adjusts). One extra bonus with this approach is that it let us think on more cool refactors in the future: we can for instance replace class categories (now a symbol) with an RPackage... and continue simplifying the system in several ways. ...and that's where we are now. We are working hard on stabilizing the system, but that will take still some days more... after that, we will be really close to the PackageInfo removal. PLEASE: PackageInfo users, take this into account: PackageInfo will pass away... and is one of the parts of the system that cannot be deprecated, they has to be completely removed, prepare your tools for the rise of RPackage :) Cheers, Esteban

Sept. 7, 2012

[Pharo-project] pharo-2.0-tests Â» win - Build # 337 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Sept. 7, 2012

Re: [Pharo-project] Building a run loop that can continue after an unhanded exception

by Frank Shearar

On 7 September 2012 14:27, Joe Rickerby <joe.rickerby(a)square-i.net> wrote: > I'm actually doing forkAndWait on the timer actions to prevent any synchronisation problems, and to prevent me spawning too many processes and bringing down the system :/ Well, that would work. Have you thought of invoking each action in an [action value] on: Exception do: [:e | "see later"] ? That would prevent any exceptions/errors/notifications at all from breaking the run loop. In the "see later" part you could do tricky things like capture the stack for inspection, via #signalerContext, if I recall correctly. frank > On 7 Sep 2012, at 13:02, Frank Shearar <frank.shearar(a)gmail.com> wrote: > >> On 7 September 2012 12:29, Joe Rickerby <joe.rickerby(a)square-i.net> wrote: >>> I have a solution however! Each timer on the run loop runs its action in a fork. This way any exception raised cannot unroll the stack to outside my run loop code. >> >> Right. That's effectively identical to using a delimited continuation: >> that marks the stack such that when you cut the continuation you can't >> capture past the stack marker. [1] >> >> The problem you might have is that the actions, being forked, run in a >> separate Process. That means you have to worry about synchronising - >> accessing common state from two actions (that are, of course, now >> running in parallel). >> >> frank >> >> [1] http://okmij.org/ftp/continuations/green-fork.html >> >>> On 7 Sep 2012, at 12:24, Joe Rickerby <joe.rickerby(a)squaregroup.co.uk> >>> wrote: >>> >>>> Not really. Proceed would take me back to where the exception was signalled. I want to resume at the point of the catch of the exception, no matter what happens regarding the exception. >>>> >>>> On 7 Sep 2012, at 09:40, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: >>>> >>>>> On 07.09.2012 10:17, Joe Rickerby wrote: >>>>>> Hi all, >>>>>> >>>>>> I'm having a problem trying to build a run loop. If an exception is signalled within one of the run loop tasks, the exception escapes through the loop and terminates the process. >>>>>> >>>>>> I know I can catch the exception, and do something like print the message on the Transcript, but I was hoping to build something that was more helpful in development, allowing me to look through the stack, but if I press 'abandon' on that dialog, the run loop would continue from where I caught the exception. >>>>>> >>>>>> >>>>> Isn't that exactly what happens if you don't handle the error, and use the proceed button in (pre and normal) debugger windows? >>>>> >>>>> Cheers, >>>>> Henry >>>> >>> >>> >>> >> >> > > >

Sept. 7, 2012

Re: [Pharo-project] Rounding float question again

by Chris Cunningham

On Fri, Sep 7, 2012 at 7:41 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Thank's for your answer. > Only one of your solutions works: > (146.015 asMinimalDecimalFraction roundTo: 1/100) asFloat => 146.02 > > Others not works: > > (146.015 * 100.0) rounded / 100.0 => 146.01 > (146.015 asFraction roundTo: 1/100) asFloat => 146.01 > Another option it to load FixedDecimal, and use it for you fixed place work: ('146.015' asFixedDecimal: 3) roundTo: ('0.01' asFixedDecimal: 2) ==> 146.02 (Yes, Nicolas, I still haven't come up with a short way of specifying FixedDecimals, but it will still load into Pharo without an issue.) http://www.squeaksource.com/FixedDecimal.html -Chris

Sept. 7, 2012

Re: [Pharo-project] Rounding float question again

by Denis Kudriashov

Thank's for your answer. Only one of your solutions works: (146.015 asMinimalDecimalFraction roundTo: 1/100) asFloat => 146.02 Others not works: (146.015 * 100.0) rounded / 100.0 => 146.01 (146.015 asFraction roundTo: 1/100) asFloat => 146.01 2012/9/7 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > Hi Denis, > If you decompose the operation performed by round: > > (146.015 / 0.01) rounded * 0.01 > > '146.015' asFloat is inexact > '0.01' asFloat is inexact > / 0.01 operation is inexact > '0.01' asFloat is inexact (again) > * 0.01 operation is inexact > > That means cumulating 5 inexact operations, how do you say "jouer Ã la > roulette russe"? > > Pharo guys did propose a better scheme > > (146.015 * 100.0) rounded / 100.0 > > Since '100.0' asFloat is exact, that leave only 2 inexact operations > and works much better (and we know the last one rounds exactly). > > But if (146.015 asFraction < 146.015s3) then you still have a problem > with inexactness of original value. > > I see two solutions for this root problem: > - don't use Float, but Fraction or ScaledDecimals > - use a trick, asMinimalDecimalFraction which I proposed in > http://code.google.com/p/pharo/issues/detail?id=4957 that will convert > ('146.015' asFloat) to the exact fraction that is printed > 146015/1000... > > (x asMinimalDecimalFraction roundTo: 1/100) asFloat would thus be > close to your requirements... > > Nicolas > > 2012/9/7 Denis Kudriashov <dionisiydk(a)gmail.com>: > > Hello. > > > > I know there are many similar questions. > > > > Maybe somebody give me fast answer. > > > > 146.015 roundTo: 0.01 => 146.01 > > > > I guess internal representation of 146.015 is something like > > 146.014999999999... > > That's why rounding result is 146.01 > > > > But how I can round arbitrary float my math root? > > How to fix my example to get 146.02? > > > > Best regards, > > Denis > >

Sept. 7, 2012

Re: [Pharo-project] Advanced mocking or something like that

by Paul DeBruicker

http://www.squeaksource.com/Mocketry.html has a state specific dsl -- View this message in context: http://forum.world.st/Advanced-mocking-or-something-like-that-tp4646454p464… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Sept. 7, 2012

Re: [Pharo-project] git support

by Dale Henrichs

Excellent...I'll take it for a spin soonly and let you know how it goes! Dale ----- Original Message ----- | From: "Max Leske" <maxleske(a)gmail.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Friday, September 7, 2012 6:54:20 AM | Subject: Re: [Pharo-project] git support | | Runs on 1.4 and 2.0 as long as you manually backport the newest | filesystem packages (I've got both images on my machine and it works | fine). | | | On 07.09.2012, at 15:32, Camillo Bruni <camillobruni(a)gmail.com> | wrote: | | > On 2012-09-07, at 15:29, Dale Henrichs <dhenrich(a)vmware.com> wrote: | >> Does FsGit run in Pharo1.4 or is ti Pharo2.0 only ... if it ran in | >> Pharo1.4 I would start using it in my daily work:) | > | > so that's a motivation to get it up and running in 1.4 :P | > With FileSystem being backported I don't see any immediate problems | > ahead... | > | >> ----- Original Message ----- | >> | From: "Camillo Bruni" <camillobruni(a)gmail.com> | >> | To: Pharo-project(a)lists.gforge.inria.fr | >> | Sent: Friday, September 7, 2012 6:22:44 AM | >> | Subject: Re: [Pharo-project] git support | >> | | >> | | >> | On 2012-09-07, at 15:13, Dale Henrichs <dhenrich(a)vmware.com> | >> | wrote: | >> | > Cami, | >> | > | >> | > What kind of work needs to be done for the Cypress-compatible | >> | > format? I've done a couple of different implementations | >> | > already:) | >> | > So I can definitely do one more ... If you give me the name of | >> | > the | >> | > class that is the entry point for read/write then I can take | >> | > it | >> | > from there ... | >> | | >> | Since you ported it to the new FileSystem I don't have to change | >> | much | >> | :) | >> | The git stuff works on top of the new FileSystem, thus | >> | completely | >> | transparent to | >> | whatever FileOperations you used. | >> | | >> | - load filetree | >> | - use filetree instead of my own git exporter | >> | - use filetree for recreating mc snapshots | >> | | >> | I will try to hook that up this weekend, then I need busy | >> | testers :P | >> | | >> | | >> | > Metacello integration is also among the "missing" from the | >> | > perspective that I want some real users using the Metacello | >> | > Preview[1] and giving me feedback[2] before I make a general | >> | > release. | >> | | >> | I guess we could push some work to Versionner? That would then | >> | have | >> | to interact | >> | with the low-level git filesystem to set the tags / commits | >> | | >> | > Also keep in mind that we will need to be inventing the | >> | > Smalltalk | >> | > workflow for git... | >> | | >> | yes :) I hope to get closer to that once I have a running | >> | implementation in pharo.. | >> | | >> | > Dale | >> | > | >> | > [1] | >> | > https://github.com/dalehenrich/metacello-work/blob/master/README.md | >> | > [2] https://groups.google.com/group/metacello/ | >> | > | >> | > ----- Original Message ----- | >> | > | From: "Camillo Bruni" <camillobruni(a)gmail.com> | >> | > | To: "Pharo-project(a)lists.gforge.inria.fr Development" | >> | > | <pharo-project(a)lists.gforge.inria.fr> | >> | > | Sent: Friday, September 7, 2012 4:15:46 AM | >> | > | Subject: [Pharo-project] git support | >> | > | | >> | > | who will help? | >> | > | | >> | > | max and I, stimulated by ESUG, worked on the latest version | >> | > | of | >> | > | FS-Git | >> | > | to make it stable again. | >> | > | we are very close to have a complete set of git tools | >> | > | written in | >> | > | pharo ready! | >> | > | | >> | > | missing | >> | > | ======= | >> | > | - a better mc integration | >> | > | - a cypress compatible fileout format | >> | > | - complete interaction with the git protocol | >> | > | - a direct way to commit stuff | >> | > | | >> | > | as always my time is somewhat limited as well and we're the | >> | > | only | >> | > | two | >> | > | developers working on it... | >> | > | | >> | > | The current work is available here: | >> | > | http://ss3.gemstone.com/ss/FSGit-Experimental.html | >> | > | https://github.com/dalehenrich/FSGit | >> | > | | >> | > | best | >> | > | cami | >> | > | | >> | > | >> | | >> | | >> | | >> | > | > | | |

Sept. 7, 2012

Re: [Pharo-project] Rounding float question again

by Nicolas Cellier

Hi Denis, If you decompose the operation performed by round: (146.015 / 0.01) rounded * 0.01 '146.015' asFloat is inexact '0.01' asFloat is inexact / 0.01 operation is inexact '0.01' asFloat is inexact (again) * 0.01 operation is inexact That means cumulating 5 inexact operations, how do you say "jouer Ã la roulette russe"? Pharo guys did propose a better scheme (146.015 * 100.0) rounded / 100.0 Since '100.0' asFloat is exact, that leave only 2 inexact operations and works much better (and we know the last one rounds exactly). But if (146.015 asFraction < 146.015s3) then you still have a problem with inexactness of original value. I see two solutions for this root problem: - don't use Float, but Fraction or ScaledDecimals - use a trick, asMinimalDecimalFraction which I proposed in http://code.google.com/p/pharo/issues/detail?id=4957 that will convert ('146.015' asFloat) to the exact fraction that is printed 146015/1000... (x asMinimalDecimalFraction roundTo: 1/100) asFloat would thus be close to your requirements... Nicolas 2012/9/7 Denis Kudriashov <dionisiydk(a)gmail.com>: > Hello. > > I know there are many similar questions. > > Maybe somebody give me fast answer. > > 146.015 roundTo: 0.01 => 146.01 > > I guess internal representation of 146.015 is something like > 146.014999999999... > That's why rounding result is 146.01 > > But how I can round arbitrary float my math root? > How to fix my example to get 146.02? > > Best regards, > Denis

Sept. 7, 2012

[Pharo-project] pharo-2.0-tests Â» win - Build # 336 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

Sept. 7, 2012