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

Re: [Pharo-dev] Call for co-coders

by stepharo

I'm currently writing some roadmaps about each possible topics. I will send them when I'm done. Stef

May 21, 2014

Re: [Pharo-dev] Call for co-coders

by stepharo

On 19/5/14 14:56, kilon alios wrote: > a blog post could help a lot because I have no clue what systemLogger > suppose to do or the other things. there is a full chapter on it. https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/590/artifa… > > I was actually thinking enhancing Workspace. > > > On Mon, May 19, 2014 at 3:49 PM, Sven Van Caekenberghe <sven(a)stfx.eu > <mailto:sven@stfx.eu>> wrote: > > I am interested as well. > > I had some private discussions with Norbert and Doru, > and I used a different approach on one of my projects very recently > that I am quite happy with. > > BTW, I have long term plans to change ZnLogEvent... > > On 19 May 2014, at 14:31, Tudor Girba <tudor(a)tudorgirba.com > <mailto:tudor@tudorgirba.com>> wrote: > > > Me too. I already gave a first set of feedback. > > > > As a general matter, I would be interested in: > > - unifying with the ZnLogEvent > > - Split the Log class > > - Possibly support Fuel serialization for each log entry > > > > Doru > > > > > > On Mon, May 19, 2014 at 11:01 AM, phil(a)highoctane.be > <mailto:phil@highoctane.be> <phil(a)highoctane.be > <mailto:phil@highoctane.be>> wrote: > > SystemLogger interests me as well. > > > > Phil > > > > > > On Mon, May 19, 2014 at 10:17 AM, Norbert Hartl > <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: > > Hi Stef, > > > > Iâm definitely in for the SystemLogger. But as I am involved in > it anyway a fresh look from another person on that stuff could be > benefitial. > > > > Norbert > > > > Am 19.05.2014 um 09:10 schrieb stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > > > > Hi guys > > > > > > This is a call for some of you that committed code and would > like to do it with me :). > > > I have some projects that I would like to push further in 4.0 > and I'm thinking that > > > he could be much more fun to do it with other people. > > > > > > Here are some topics > > > - integrating the systemLogger > > > - integrating/improving the new method categorizer > > > - cleaning fonts > > > - ... > > > > > > How this could work? > > > We could have > > > - some discussions > > > - make a little roadmap > > > - then we could work on the same slice and do code review > > > > > > I think that it can be fun and motivating. So let me know > because I would like to have more social > > > coding. > > > > > > Stef > > > > > > > > > > > > > > > > > -- > > www.tudorgirba.com <http://www.tudorgirba.com> > > > > "Every thing has its own flow" > > >

May 21, 2014

Re: [Pharo-dev] Call for co-coders

by stepharo

On 19/5/14 14:31, Tudor Girba wrote: > Me too. I already gave a first set of feedback. > > As a general matter, I would be interested in: > - unifying with the ZnLogEvent first we should integrate it and make sure that all the Transcript show are funnelled to the Log frameworks. > - Split the Log class we will not split it because we iterated over the design since 8 months with norbert :) > - Possibly support Fuel serialization for each log entry Please go ahead. > > Doru > > > On Mon, May 19, 2014 at 11:01 AM, phil(a)highoctane.be > <mailto:phil@highoctane.be> <phil(a)highoctane.be > <mailto:phil@highoctane.be>> wrote: > > SystemLogger interests me as well. > > Phil > > > On Mon, May 19, 2014 at 10:17 AM, Norbert Hartl > <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: > > Hi Stef, > > Iâm definitely in for the SystemLogger. But as I am involved > in it anyway a fresh look from another person on that stuff > could be benefitial. > > Norbert > > Am 19.05.2014 um 09:10 schrieb stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > > Hi guys > > > > This is a call for some of you that committed code and would > like to do it with me :). > > I have some projects that I would like to push further in > 4.0 and I'm thinking that > > he could be much more fun to do it with other people. > > > > Here are some topics > > - integrating the systemLogger > > - integrating/improving the new method categorizer > > - cleaning fonts > > - ... > > > > How this could work? > > We could have > > - some discussions > > - make a little roadmap > > - then we could work on the same slice and do code review > > > > I think that it can be fun and motivating. So let me know > because I would like to have more social > > coding. > > > > Stef > > > > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

May 21, 2014

Re: [Pharo-dev] Advice for a newb

by Ron Teitelbaum

Hi Rick, Actually that makes sense. The change set dance and the changes file for recovering code after a crash are really about keeping your repo clean. Itâs helpful for larger groups of developers that donât want to have to track everything you do that doesnât work J. It also prevents people from loading code that breaks the system. For me I only post my final work to the repo. You can also do that with Monticello using the local cache. Then you only post to the main repo by merging your versions into the trunk and releasing those. It just takes longer than using a change set. Monticello also has a config map but still you have to version every package and then load all of your packages again at startup. With the change set itâs file out, restart, file in. Good luck with it! All the best, Ron Teitelbaum From: Rick Kitts [mailto:rkitts@loudhouse.org] Sent: Tuesday, May 20, 2014 11:45 PM To: Pharo Development List; Ron Teitelbaum Subject: Re: [Pharo-dev] Advice for a newb Thanks for the advice. I have spent some quality time with Monticello. In the end Iâve made a copy of Duration and DurationTest and Iâm working on that. Iâm not doing the image juggling you describe below however. I donât really understand why that workflow is worth the cost so Iâll just keep getting closer to the stove until I get burned. Iâll (probably) learn then. âRick On May 19, 2014 at 8:53:10 PM, Ron Teitelbaum (ron(a)usmedrec.com) wrote: Hi Rick, Change sets and changes file will save you no matter how you crash your image. Saving your image after development is dangerous, I donât recommend it. What I do is make a change set. Iâll develop and then when Iâm ready to start testing Iâll file it out. Iâll do some testing blow up develop more. If I forget to file out the change set the changes file is your friend. World menu -> changesâ¦ -> recently logged changes â¦ will give you a nice list of the last things you did. Itâs quite easy to filter out stuff and get a nice list of changes, and file them in. It is very hard to lose code. When you get to a good point and want to save your state always start from your last saved image. Load your change set, save your changes to Monticello, or your own favorite repo. Exit, load your changes from your repo, clean your image and save. Now your recently logged changes will have another nice clean entry. Rinse and repeat. Hope that helps. All the best, Ron Teitelbaum Head Of Engineering 3d Immersive Collaboration Consulting ron(a)3dicc.com Follow Me On Twitter: @RonTeitelbaum <https://twitter.com/RonTeitelbaum> www.3dicc.com <http://www.3dicc.com/> https://www.google.com/+3dicc From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Rick Kitts Sent: Monday, May 19, 2014 10:41 PM To: Pharo Development List Subject: [Pharo-dev] Advice for a newb Hello. I was wondering if anyone could point me to or otherwise suggest some best practices for working on Kernel code. Iâm futzing about with the Duration class (in the interest of fixing 13215) and have discovered that itâs really easy to crash Pharo if I break that class. I assume there are other classes that would exhibit the same behavior. I suppose I could just be really cautious and save my image after every change but that seems so error prone that Iâm hoping that there are idiomatic ways of working on kernel code (beyond just save ones image early and often) so I donât lose work. Iâm asking because the naive solution (copy the original class, modify it to suit, delete the original and rename the new class to the original) of course doesnât work. TIA for any suggestions or assistance and apologies in advance if this is RTFM, I didnât see anything (didnât look very hard either though). âRick

May 21, 2014

Re: [Pharo-dev] Advice for a newb

by Rick Kitts

Thanks for the advice. I have spent some quality time with Monticello. In the end Iâve made a copy of Duration and DurationTest and Iâm working on that. Iâm not doing the image juggling you describe below however. I donât really understand why that workflow is worth the cost so Iâll just keep getting closer to the stove until I get burned. Iâll (probably) learn then. âRick On May 19, 2014 at 8:53:10 PM, Ron Teitelbaum (ron(a)usmedrec.com) wrote: Hi Rick, Â Change sets and changes file will save you no matter how you crash your image.Â Saving your image after development is dangerous, I donât recommend it. Â What I do is make a change set.Â Iâll develop and then when Iâm ready to start testing Iâll file it out.Â Iâll do some testing blow up develop more.Â If I forget to file out the change set the changes file is your friend.Â Â Â World menu -> changesâ¦ -> recently logged changes â¦ will give you a nice list of the last things you did.Â Itâs quite easy to filter out stuff and get a nice list of changes, and file them in.Â It is very hard to lose code. Â When you get to a good point and want to save your state always start from your last saved image.Â Load your change set, save your changes to Monticello, or your own favorite repo.Â Exit, load your changes from your repo, clean your image and save.Â Now your recently logged changes will have another nice clean entry.Â Rinse and repeat.Â Â Hope that helps. Â All the best, Â Ron Teitelbaum Head Of Engineering 3d Immersive Collaboration Consulting ron(a)3dicc.com Follow Me On Twitter: @RonTeitelbaum www.3dicc.com https://www.google.com/+3dicc Â Â Â From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Rick Kitts Sent: Monday, May 19, 2014 10:41 PM To: Pharo Development List Subject: [Pharo-dev] Advice for a newb Â Hello. I was wondering if anyone could point me to or otherwise suggest some best practices for working on Kernel code. Iâm futzing about with the Duration class (in the interest of fixing 13215) and have discovered that itâs really easy to crash Pharo if I break that class. I assume there are other classes that would exhibit the same behavior. Â I suppose I could just be really cautious and save my image after every change but that seems so error prone that Iâm hoping that there are idiomatic ways of working on kernel code (beyond just save ones image early and often) so I donât lose work. Iâm asking because the naive solution (copy the original class, modify it to suit, delete the original and rename the new class to the original) of course doesnât work. Â TIA for any suggestions or assistance and apologies in advance if this is RTFM, I didnât see anything (didnât look very hard either though). Â âRick Â

May 21, 2014

Re: [Pharo-dev] Aconcagua Hashing Bug?

by Sean P. DeNigris

Eliot Miranda-2 wrote > You can't divide floats by 3 and get an exact answer: > 0.5 / 3 = 0.16666666666666666 Duh :) Thank you. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Aconcagua-Hashing-Bug-tp4759622p4759779.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 21, 2014

Re: [Pharo-dev] Aconcagua Hashing Bug?

by Maximiliano Taborda

If you see the code at #hash method for class Measure, your realize that this class converts the amount of the measure to its base unit and then sends hash to this converted value. So, for the case where you have 1/2 teaspoon the #hash method, after some conversions, this does: (1/2) * (1/3) = (1/6) then, obtain the hash of the fraction 1/6 => 7. The same goes for your 0.5 teaspoon. But, because floats are bad guys, this is what happens: 0.5 * (1/3) = 0.16666666666666666 (like Eliot shows) then, obtain the hash for this ugly float => 72362. Its ok or not, well, thats depends. If you need a more precise number, use fractions or scaled decimals. 2014-05-20 21:07 GMT-03:00 Maximiliano Taborda <mtaborda(a)gmail.com>: > Or just use ScaledDecimal instead of Float > > 0.5 asScaledDecimal * 0.5 asScaledDecimal = (1/2 * (1/2)) true > 0.5 asScaledDecimal / 3 = (1/2 * (1/3)) true > > > 2014-05-20 19:21 GMT-03:00 Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com>: > > >> 2014-05-21 0:16 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >> >>> >>> >>> On Tue, May 20, 2014 at 1:45 PM, Sean P. DeNigris <sean(a)clipperadams.com >>> > wrote: >>> >>>> Maximiliano Taborda wrote >>>> > Seeing the same with aconcagua >>>> > ... >>>> > teaspoons := BaseUnit named: 'teaspoons'. >>>> > aHalfTeaspoon := Measure amount: 1/2 unit: teaspoons. >>>> > anotherHalfTeaspoon := Measure amount: 0.5 unit: teaspoons. >>>> > >>>> > "#hash" >>>> > aHalfTeaspoon hash = anotherHalfTeaspoon hash "this evaluate to true" >>>> > >>>> > So, I don't see where is the bug. >>>> >>>> It seems to only appear when comparing measures with derived units... >>>> >>>> baseUnit := BaseUnit named: 'tablespoon'. >>>> unit := ProportionalDerivedUnit baseUnit: baseUnit conversionFactor: 1/3 >>>> named: 'teaspoon'. >>>> m1 := Measure amount: 1/2 unit: unit. >>>> m2 := Measure amount: 0.5 unit: unit. >>>> m1 hash = m2 hash. "this evaluate to false" >>>> >>> >>> >>> are you surprised? >>> >>> 0.5 * 0.5 = (1/2 * (1/2)) true >>> 0.5 / 3 = (1/2 * (1/3)) false >>> >>> You can't divide floats by 3 and get an exact answer: >>> >>> 0.5 / 3 = 0.16666666666666666 >>> >>> (1/2)/3 = (1/6) >>> >> >> Good find! >> Use a smaller spoon, like 1/4 ;) >> >> >>> >>> >>>> >>>> >>>> ----- >>>> Cheers, >>>> Sean >>>> -- >>>> View this message in context: >>>> http://forum.world.st/Aconcagua-Hashing-Bug-tp4759622p4759745.html >>>> Sent from the Pharo Smalltalk Developers mailing list archive at >>>> Nabble.com. >>>> >>>> >>> >>> >>> -- >>> best, >>> Eliot >>> >> >> >

May 21, 2014

Re: [Pharo-dev] Aconcagua Hashing Bug?

by Maximiliano Taborda

Or just use ScaledDecimal instead of Float 0.5 asScaledDecimal * 0.5 asScaledDecimal = (1/2 * (1/2)) true 0.5 asScaledDecimal / 3 = (1/2 * (1/3)) true 2014-05-20 19:21 GMT-03:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > > 2014-05-21 0:16 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > >> >> >> On Tue, May 20, 2014 at 1:45 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: >> >>> Maximiliano Taborda wrote >>> > Seeing the same with aconcagua >>> > ... >>> > teaspoons := BaseUnit named: 'teaspoons'. >>> > aHalfTeaspoon := Measure amount: 1/2 unit: teaspoons. >>> > anotherHalfTeaspoon := Measure amount: 0.5 unit: teaspoons. >>> > >>> > "#hash" >>> > aHalfTeaspoon hash = anotherHalfTeaspoon hash "this evaluate to true" >>> > >>> > So, I don't see where is the bug. >>> >>> It seems to only appear when comparing measures with derived units... >>> >>> baseUnit := BaseUnit named: 'tablespoon'. >>> unit := ProportionalDerivedUnit baseUnit: baseUnit conversionFactor: 1/3 >>> named: 'teaspoon'. >>> m1 := Measure amount: 1/2 unit: unit. >>> m2 := Measure amount: 0.5 unit: unit. >>> m1 hash = m2 hash. "this evaluate to false" >>> >> >> >> are you surprised? >> >> 0.5 * 0.5 = (1/2 * (1/2)) true >> 0.5 / 3 = (1/2 * (1/3)) false >> >> You can't divide floats by 3 and get an exact answer: >> >> 0.5 / 3 = 0.16666666666666666 >> >> (1/2)/3 = (1/6) >> > > Good find! > Use a smaller spoon, like 1/4 ;) > > >> >> >>> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> View this message in context: >>> http://forum.world.st/Aconcagua-Hashing-Bug-tp4759622p4759745.html >>> Sent from the Pharo Smalltalk Developers mailing list archive at >>> Nabble.com. >>> >>> >> >> >> -- >> best, >> Eliot >> > >

May 21, 2014

Re: [Pharo-dev] Aconcagua Hashing Bug?

by Nicolas Cellier

2014-05-21 0:16 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > On Tue, May 20, 2014 at 1:45 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > >> Maximiliano Taborda wrote >> > Seeing the same with aconcagua >> > ... >> > teaspoons := BaseUnit named: 'teaspoons'. >> > aHalfTeaspoon := Measure amount: 1/2 unit: teaspoons. >> > anotherHalfTeaspoon := Measure amount: 0.5 unit: teaspoons. >> > >> > "#hash" >> > aHalfTeaspoon hash = anotherHalfTeaspoon hash "this evaluate to true" >> > >> > So, I don't see where is the bug. >> >> It seems to only appear when comparing measures with derived units... >> >> baseUnit := BaseUnit named: 'tablespoon'. >> unit := ProportionalDerivedUnit baseUnit: baseUnit conversionFactor: 1/3 >> named: 'teaspoon'. >> m1 := Measure amount: 1/2 unit: unit. >> m2 := Measure amount: 0.5 unit: unit. >> m1 hash = m2 hash. "this evaluate to false" >> > > > are you surprised? > > 0.5 * 0.5 = (1/2 * (1/2)) true > 0.5 / 3 = (1/2 * (1/3)) false > > You can't divide floats by 3 and get an exact answer: > > 0.5 / 3 = 0.16666666666666666 > > (1/2)/3 = (1/6) > Good find! Use a smaller spoon, like 1/4 ;) > > >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: >> http://forum.world.st/Aconcagua-Hashing-Bug-tp4759622p4759745.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> > > > -- > best, > Eliot >

May 20, 2014

Re: [Pharo-dev] Aconcagua Hashing Bug?

by Eliot Miranda

On Tue, May 20, 2014 at 1:45 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > Maximiliano Taborda wrote > > Seeing the same with aconcagua > > ... > > teaspoons := BaseUnit named: 'teaspoons'. > > aHalfTeaspoon := Measure amount: 1/2 unit: teaspoons. > > anotherHalfTeaspoon := Measure amount: 0.5 unit: teaspoons. > > > > "#hash" > > aHalfTeaspoon hash = anotherHalfTeaspoon hash "this evaluate to true" > > > > So, I don't see where is the bug. > > It seems to only appear when comparing measures with derived units... > > baseUnit := BaseUnit named: 'tablespoon'. > unit := ProportionalDerivedUnit baseUnit: baseUnit conversionFactor: 1/3 > named: 'teaspoon'. > m1 := Measure amount: 1/2 unit: unit. > m2 := Measure amount: 0.5 unit: unit. > m1 hash = m2 hash. "this evaluate to false" > are you surprised? 0.5 * 0.5 = (1/2 * (1/2)) true 0.5 / 3 = (1/2 * (1/3)) false You can't divide floats by 3 and get an exact answer: 0.5 / 3 = 0.16666666666666666 (1/2)/3 = (1/6) > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Aconcagua-Hashing-Bug-tp4759622p4759745.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- best, Eliot

May 20, 2014