- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Metacello: Resolving Conflicting Attributes

by Nicolas Cellier

Hi Sean, I wish I had more time to dive into this. Before I do, where did you publish the corrections? Only in meta repo for Pharo4? I also maintain a copy at Xtreams http://www.squeaksource.com/Xtreams and another at http://www.squeaksource.com/MetacelloRepository. Sometimes, I also backport to meta repo for Pharo3... If you think your corrections are solid enough and backward compatible, maybe you could push them in these repos too. In all cases, thanks for your contribution. cheers Nicolas 2015-04-05 16:20 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Dale taught me something helpful (and maybe a little obscure) while fixing > ConfigurationOfXtreams... > > Problem: Say you have a platform attribute #pharo4.x, and a > #customProjectAttribute #FileSystem. The problem is that the > FileSystem-related packages required for #pharo4.x are different than those > for the default cases. > spec for: #'pharo4.x' do: [ > spec package: 'Xtreams-TerminalsFileSystem' with: > 'Xtreams-TerminalsFileSystem.pharo40-SeanDeNigris.4' ]. > ... > spec for: #FileSystem do: [ > spec package: 'Xtreams-TerminalsFileSystem' with: > 'Xtreams-TerminalsFileSystem-nice.1'. ] > > Solution: Nest a "spec for: #FileSystem do:" inside the "spec for: > #pharo4.x > do:" declaring the #pharo4.x-specifics > spec for: #'pharo4.x' do: [ > spec for: #'FileSystem' do: [ > spec > package: 'Xtreams-TerminalsFileSystem' > with: > 'Xtreams-TerminalsFileSystem.pharo40-SeanDeNigris.4' ]. > > Why it works: Per Dale, "The spec:for:do: blocks are evaluated in attribute > order (ConfigurationOfX project attributes) with top-level blocks evaluated > before nested blocks ... second level blocks are evaluated in top-level > block order after the first level block evaluation ... so having > #FileSystem > nested inside of #pharo4.x and given that #FileSystem follows #pharo4.x in > attribute order means that the nested #FileSystem block inside of #pharo4.x > is evaluated after to top-level #FileSystem block allowing you to do > #pharo4.x specific overrides" > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Metacello-Resolving-Conflicting-Attributes-tp4817683.… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

April 5, 2015

Re: [Pharo-dev] 14606 Really Important bug - Can't see some variables values while debugging closure

by Nicolas Cellier

2015-04-05 17:38 GMT+02:00 Ben Coman <btc(a)openinworld.com>: > > > On Sun, Apr 5, 2015 at 8:59 PM, stepharo <stepharo(a)free.fr> wrote: > >> >> Thanks both of you for the energy you put into Pharo. >> The tam really appreciates. >> This is because there are guys like you that Pharo is worth being done. >> Thanks for the tests. >> Esteban has apparently found the bug on the VM. >> >> Stef >> >> > Energy breeds energy. For me it was an opportunity to learn more deep > stuff(tm) by digging with a goal. It remains a bit beyond me, but I'm > happy if I've been able to beat the high grass enough to flush the tiger > into the open where the marksman can take a shot at it. > > Nice to flush out a VM bug (can't be too many of those left ;). Let us > know when we can do testing on it. I guess I'll read more about it on > [vm-dev]. > > cheers -ben > If it's a VM bug, the VM folks would be really really interested by a bug report, especially if ever it may affect Eliot's branch. Even if it's a Pharo only bug, it is still very interesting to know, because there's allways something to learn from a bug. So I'm all ears... cheers Nicolas

April 5, 2015

Re: [Pharo-dev] Ways to do 32-bit arithmetics?

by Stefan Marr

Hi: > On 03 Apr 2015, at 17:44, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > seed := ((seed + 16r7ed55d16) + (seed << 12)) & 16rffffffff. > seed := ((seed ^ 16rc761c23c) ^ (seed as32BitSignedValue >>> 19)) & 16rffffffff. > seed := ((seed + 16r165667b1) + (seed << 5)) & 16rffffffff. > seed := ((seed + 16rd3a2646c) ^ (seed << 9)) & 16rffffffff. > seed := ((seed + 16rfd7046c5) + (seed << 3)) & 16rffffffff. > seed := ((seed ^ 16rb55a4f09) ^ (seed as32BitSignedValue >>> 16)) & 16rffffffff. > ^ seed as32BitSignedValue Ok, my implementation looks now like this: random "Robert Jenkins' 32 bit integer hash function." seed := ((seed + 16r7ed55d16) + (seed << 12)). seed := ((seed bitXor: 16rc761c23c) bitXor: ((seed bitAnd: 16rffffffff) >> 19)). seed := ((seed + 16r165667B1) + (seed << 5)). seed := ((seed + 16rd3a2646c) bitXor: (seed << 9)). seed := ((seed + 16rfd7046c5) + (seed << 3)). seed := self as32BitSigned: ((seed bitXor: 16rb55a4f09) bitXor: ((seed bitAnd: 16rffffffff) >> 16)). ^ seed as32BitSigned: val | r | r := val bitAnd: 16rffffffff. (r bitAnd: 16r80000000) = 0 ifTrue: [ ^ r ]. ^ (16r100000000 - r) * -1 The #as32BitSigned: looks a little naive, but didnât have any better idea. And Andres, the random number generator is a given, I canât just change it. Best regards Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/

April 5, 2015

Re: [Pharo-dev] New Pull Request for UpdatedPharoByExample

by kilon alios

Strangely enough it does not notify me, probably need to change something in my github settings. On Sun, Apr 5, 2015 at 6:39 PM, Dmitri Zagidulin <dmitri(a)zagidulin.net> wrote: > Thanks, Gaurav! It is now merged. > > I don't think one needs to send an email to the mailing list, though, for > PRs. Github usually notifies anybody who's watching the repository, when > new PRs are made. > > On Sun, Apr 5, 2015 at 9:28 AM, Gaurav Singh <grvanm.coder(a)gmail.com> > wrote: > >> I have made a few corrections in the chapter Syntax in a Nutshell. >> Link to the pull request: >> https://github.com/SquareBracketAssociates/UpdatedPharoByExample/pull/30 >> Kindly review the pull request. >> > >

April 5, 2015

Re: [Pharo-dev] Spotter

by kilon alios

The problem of people like a tool too much you get a ton of feature requests :D I don't envy those poor developers.

April 5, 2015

Re: [Pharo-dev] Spotter

by Norbert Hartl

> Am 05.04.2015 um 19:09 schrieb Ben Coman <btc(a)openinworld.com>: > > > > On Sun, Apr 5, 2015 at 11:37 PM, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: > aliaksei > > what would be nice is that each time we click on a button or press a command key > you emit a growl notification with the description. > > Stef > > > > For just a moment there, I thought you wanted Spotter to start making bear noises? *grin* > Me, too. But the moment didn't finish yet Norbert

April 5, 2015

Re: [Pharo-dev] Spotter

by Ben Coman

On Sun, Apr 5, 2015 at 11:37 PM, stepharo <stepharo(a)free.fr> wrote: > aliaksei > > what would be nice is that each time we click on a button or press a > command key > you emit a growl notification with the description. > > Stef > > > For just a moment there, I thought you wanted Spotter to start making bear noises? *grin*

April 5, 2015

Re: [Pharo-dev] New Pull Request for UpdatedPharoByExample

by Gaurav Singh

Thanks :) On Sun, Apr 5, 2015 at 9:09 PM, Dmitri Zagidulin <dmitri(a)zagidulin.net> wrote: > Thanks, Gaurav! It is now merged. > > I don't think one needs to send an email to the mailing list, though, for > PRs. Github usually notifies anybody who's watching the repository, when > new PRs are made. > > On Sun, Apr 5, 2015 at 9:28 AM, Gaurav Singh <grvanm.coder(a)gmail.com> > wrote: > >> I have made a few corrections in the chapter Syntax in a Nutshell. >> Link to the pull request: >> https://github.com/SquareBracketAssociates/UpdatedPharoByExample/pull/30 >> Kindly review the pull request. >> > >

April 5, 2015

Re: [Pharo-dev] New Pull Request for UpdatedPharoByExample

by Dmitri Zagidulin

Thanks, Gaurav! It is now merged. I don't think one needs to send an email to the mailing list, though, for PRs. Github usually notifies anybody who's watching the repository, when new PRs are made. On Sun, Apr 5, 2015 at 9:28 AM, Gaurav Singh <grvanm.coder(a)gmail.com> wrote: > I have made a few corrections in the chapter Syntax in a Nutshell. > Link to the pull request: > https://github.com/SquareBracketAssociates/UpdatedPharoByExample/pull/30 > Kindly review the pull request. >

April 5, 2015

Re: [Pharo-dev] 14606 Really Important bug - Can't see some variables values while debugging closure

by Ben Coman

On Sun, Apr 5, 2015 at 8:59 PM, stepharo <stepharo(a)free.fr> wrote: > > Thanks both of you for the energy you put into Pharo. > The tam really appreciates. > This is because there are guys like you that Pharo is worth being done. > Thanks for the tests. > Esteban has apparently found the bug on the VM. > > Stef > > Energy breeds energy. For me it was an opportunity to learn more deep stuff(tm) by digging with a goal. It remains a bit beyond me, but I'm happy if I've been able to beat the high grass enough to flush the tiger into the open where the marksman can take a shot at it. Nice to flush out a VM bug (can't be too many of those left ;). Let us know when we can do testing on it. I guess I'll read more about it on [vm-dev]. cheers -ben

April 5, 2015