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

Re: [Pharo-project] integrate

by Alexandre Bergel

+1 On Aug 29, 2012, at 11:20 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > now if any of our core team plans to do some programming > tomorrow at esug, I'd be super happy if you could integrate the latest > RPackage fixes and load Metacello... currently there it is not possible > to work in Pharo 2.0!!!! > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 30, 2012

Re: [Pharo-project] integrate

by Esteban Lorenzano

Yes, we need to integrate metacello into pharo... But it also can be loaded smooth now, I fixee it , unless it is broken again :( I will take some time tomorrow to integrate, if there is something that I can integrate :) On 29/08/2012, at 23:20, Camillo Bruni <camillobruni(a)gmail.com> wrote: > now if any of our core team plans to do some programming > tomorrow at esug, I'd be super happy if you could integrate the latest > RPackage fixes and load Metacello... currently there it is not possible > to work in Pharo 2.0!!!! > > >

Aug. 29, 2012

Re: [Pharo-project] Pharo Integration Process

by Bernardo Ezequiel Contreras

+1 On Wed, Aug 29, 2012 at 6:28 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > After a discussion with Ben this week I think I start my smear campaign :P > > Ben and I wrote almost 1 year ago an almost complete tool to maximize > automatization > of the integration process, yet it is still not in use. > > now this is very strange to me, since > - you can win a lot of time by using that tool > - you can reduce the errors made when publishing > - with some effort you could make rollbacks of new versions as easy as one > click > > so here mare my detailed thoughts about how the integration process should > work: > > https://github.com/dh83/pharo-dev-text/blob/master/integration.md > > Since I don't have time to program on these things I concentrate myself > now on the > talking :P > > PS: My main motivation of course is to get my fixes faster integrated > > best > cami > -- Bernardo E.C.

Aug. 29, 2012

[Pharo-project] Pharo Integration Process

by Camillo Bruni

After a discussion with Ben this week I think I start my smear campaign :P Ben and I wrote almost 1 year ago an almost complete tool to maximize automatization of the integration process, yet it is still not in use. now this is very strange to me, since - you can win a lot of time by using that tool - you can reduce the errors made when publishing - with some effort you could make rollbacks of new versions as easy as one click so here mare my detailed thoughts about how the integration process should work: https://github.com/dh83/pharo-dev-text/blob/master/integration.md Since I don't have time to program on these things I concentrate myself now on the talking :P PS: My main motivation of course is to get my fixes faster integrated best cami

Aug. 29, 2012

[Pharo-project] integrate

by Camillo Bruni

now if any of our core team plans to do some programming tomorrow at esug, I'd be super happy if you could integrate the latest RPackage fixes and load Metacello... currently there it is not possible to work in Pharo 2.0!!!!

Aug. 29, 2012

[Pharo-project] Fwd: [Vm-dev] 3 Bugs in LargeInteger primitives

by StÃ©phane Ducasse

Begin forwarded message: > From: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > Subject: [Vm-dev] 3 Bugs in LargeInteger primitives > Date: August 29, 2012 12:18:28 PM GMT+02:00 > To: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> > Reply-To: Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> > > > As posted on squeak-dev > http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-August/165608.h… > I found 3 bugs in LargeInteger primitives > > (1<<63) negated quo: -1. > (1<<63) negated / -1. > (1<<63) negated * -1. > > They are all related to the impossible task of taking absolute value > of INT_MIN (or more exactly it's 64 bits equivalent). > Currently, it takes the form (0 - INT_MIN) whose behaviour is > undefined according to C standards but generally answer INT_MIN. > See for example > http://stackoverflow.com/questions/2539178/why-is-abs0x80000000-0x80000000 > > Surprisingly this one works: > (1<<63) negated // -1. > > Most probably because gcc has a license to ignore undefined behaviour > and perform some optimizations that don't take overflow side effects > into account. > For example 0 - (0 - a)/b can be simplified into a/b, UB case of > INT_MIN apart... > > --------------------------------- > > Beside these bugs, when I read the code, I'm quite sure it's a nest of > future bugs because there are many other attempts to catch overflow in > post-condition (like testing that addition of two positive is negative > when an underflow occurs) that technically rely on explicitely > Undefined Behaviour (UB). > OK, by now many Arithmetic Units do behave like exploited in these > post-conditions, though it's not strictly future-proof. > But we unfortunately rely on optimizing C compilers, and its behaviour > is much more fragile than hardware... > > I invite every VM hacker to read > http://stackoverflow.com/questions/199333/best-way-to-detect-integer-overfl… > And various links like > https://www.securecoding.cert.org/confluence/display/seccode/INT32-C.+Ensur… > > For example, in large integer subtract, we have a protection against > (0 - INT_MIN) like: > y = 0 - x; > if ( y==x ) { primitiveFail(); } > an optimizing compiler having a licence to ignore INT_MIN Undefined > Behaviour case could mathematically solve the equation as x==0, y==0 > and transform code into > if( ! (y=0-x) ) { primitiveFail(); } > (directly use a jz and save a comparison) > > or if we have such branch > c = a + b; > if( a >0) { > if(b > 0) { > if (c < 0 ) { primitiveFail(); } > } > } > Again, a good compiler could remove the if( c < 0) test, since it does > not have to care about UB... > > OK, pragmatically, most of these post-condition hacks are fast and > work with some version of gcc, but think about portability (llvm ?) > and future pain (you can debug such code only at asembler level). > > Do it right > do it fast. > > Nicolas

Aug. 29, 2012

Re: [Pharo-project] Stability of RPackage

by Camillo Bruni

yes there is currently a problem with multiple instances of RPackageOrganizer running... You can try and load my slice attached to http://code.google.com/p/pharo/issues/detail?id=6613 best cami On 2012-08-29, at 23:07, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Yes we saw the same today. > Now I have no idea why but the invariant test is red so it reveals that. > > Stef > On Aug 29, 2012, at 2:21 PM, Goubier Thierry wrote: > >> Hi, >> >> what is your level of confidence in RPackage / Monticello at the moment in Pharo 2.0 ? >> >> I issued a few bugs on RPackage/Nautilus and I'm now starting to understand they may have been caused by the existence of two instances of RPackageOrganizer in my image, one being clearly out of sync with my code. Has anybody noticed the same problem ? I'm now planning to rebuild an image from scratch. >> >> Issues related are 6613, 6611 and 6610. >> >> Thierry >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> > >

Aug. 29, 2012

Re: [Pharo-project] Xtreams in Pharo 2.0

by Camillo Bruni

no different branch is needed so far. the only change requires a new version of FS in 1.4: http://code.google.com/p/pharo/issues/detail?id=6553 and we're free to go On 2012-08-29, at 23:08, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > cool! > I thought you were doing it after the beer :) but it was before :) > Stef > > > On Aug 29, 2012, at 2:20 PM, Sven Van Caekenberghe wrote: > >> Hi, >> >> Xtreams (the port from VW done by Nicolas Celier) works out of the box with Pharo 1.4. >> >> To get it working on Pharo 2.0, just do the same load (ignoring the warning about FileDirectory being gone). >> Next load the following changeset: >> >> --- >> >> 'From Pharo2.0a of ''18 April 2012'' [Latest update: #20245] on 29 August 2012 at 2:08:32 pm'! >> >> >> !AbstractFileReference methodsFor: '*xtreams-terminals-converting' stamp: 'SvenVanCaekenberghe 8/29/2012 10:22'! >> appending >> | handle | >> handle := XTIOHandle forFiles open: self resolve fullName forWrite: true. >> ^ handle writing >> position: handle fileSize; >> isPositionable: false; >> yourself! ! >> >> !AbstractFileReference methodsFor: '*xtreams-terminals-converting' stamp: 'SvenVanCaekenberghe 8/29/2012 10:22'! >> reading >> ^ (XTIOHandle forFiles new open: self resolve fullName forWrite: false) reading! ! >> >> !AbstractFileReference methodsFor: '*xtreams-terminals-converting' stamp: 'SvenVanCaekenberghe 8/29/2012 10:24'! >> writing >> ^ (XTIOHandle forFiles new open: self resolve fullName forWrite: true) writing! ! >> >> --- >> >> Next, change the following test setup method: >> >> --- >> >> XTFileReadingWritingTest>>#setUp >> >> file := (self class name , '-' , testSelector) asFileReference. >> output := file writing. >> input := nil >> >> --- >> >> Now all tests are green ! >> >> Thanks, Camillo and Martin. >> >> From ESUG, >> >> Sven > >

Aug. 29, 2012

Re: [Pharo-project] Xtreams in Pharo 2.0

by StÃ©phane Ducasse

cool! I thought you were doing it after the beer :) but it was before :) Stef On Aug 29, 2012, at 2:20 PM, Sven Van Caekenberghe wrote: > Hi, > > Xtreams (the port from VW done by Nicolas Celier) works out of the box with Pharo 1.4. > > To get it working on Pharo 2.0, just do the same load (ignoring the warning about FileDirectory being gone). > Next load the following changeset: > > --- > > 'From Pharo2.0a of ''18 April 2012'' [Latest update: #20245] on 29 August 2012 at 2:08:32 pm'! > > > !AbstractFileReference methodsFor: '*xtreams-terminals-converting' stamp: 'SvenVanCaekenberghe 8/29/2012 10:22'! > appending > | handle | > handle := XTIOHandle forFiles open: self resolve fullName forWrite: true. > ^ handle writing > position: handle fileSize; > isPositionable: false; > yourself! ! > > !AbstractFileReference methodsFor: '*xtreams-terminals-converting' stamp: 'SvenVanCaekenberghe 8/29/2012 10:22'! > reading > ^ (XTIOHandle forFiles new open: self resolve fullName forWrite: false) reading! ! > > !AbstractFileReference methodsFor: '*xtreams-terminals-converting' stamp: 'SvenVanCaekenberghe 8/29/2012 10:24'! > writing > ^ (XTIOHandle forFiles new open: self resolve fullName forWrite: true) writing! ! > > --- > > Next, change the following test setup method: > > --- > > XTFileReadingWritingTest>>#setUp > > file := (self class name , '-' , testSelector) asFileReference. > output := file writing. > input := nil > > --- > > Now all tests are green ! > > Thanks, Camillo and Martin. > > From ESUG, > > Sven

Aug. 29, 2012

Re: [Pharo-project] Stability of RPackage

by StÃ©phane Ducasse

Yes we saw the same today. Now I have no idea why but the invariant test is red so it reveals that. Stef On Aug 29, 2012, at 2:21 PM, Goubier Thierry wrote: > Hi, > > what is your level of confidence in RPackage / Monticello at the moment in Pharo 2.0 ? > > I issued a few bugs on RPackage/Nautilus and I'm now starting to understand they may have been caused by the existence of two instances of RPackageOrganizer in my image, one being clearly out of sync with my code. Has anybody noticed the same problem ? I'm now planning to rebuild an image from scratch. > > Issues related are 6613, 6611 and 6610. > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

Aug. 29, 2012