- Pharo-dev - lists.pharo.org

[Pharo-project] [update 2.0] #20272

by Esteban Lorenzano

20272 ----- Issue 6607: DNU on method category change in Pharo 20269 http://code.google.com/p/pharo/issues/detail?can=2&q=6607 Issue 6613: RPackageOrganizer error on MethodRemoved announcement http://code.google.com/p/pharo/issues/detail?id=6613 Issue 6614: Changing PluggableTextMorphWithLimits (un)lock icons http://code.google.com/p/pharo/issues/detail?can=2&q=6614 Issue 6615: Fix Nautilus according to RPackage tags introduction http://code.google.com/p/pharo/issues/detail?can=2&q=6615

Aug. 30, 2012

Re: [Pharo-project] Why it takes much more time to load stuff in 2.0 comparing to 1.4?

by Mariano Martinez Peck

you found the cause? On Tue, Aug 28, 2012 at 10:22 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 28 August 2012 14:55, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > run it in the profiler and compare the results. > > I am very interested int he results :P > > we can try it tomorrow, if you will be there :) > > > > > On 2012-08-28, at 04:06, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > >> I was checking how ConfigurationOfNativeBoost behaves on 1.4 > >> and i noticed that it loads like 3-5 times faster comparing to 2.0.. > >> > >> and i refusing to believe this is because of different network latency, > >> because most time which it spends during loading in 2.0 is showing > >> "compiling / installing" > >> progress but not "downloading". > >> > >> -- > >> Best regards, > >> Igor Stasenko. > >> > > > > > > > > -- > Best regards, > Igor Stasenko. > > -- Mariano http://marianopeck.wordpress.com

Aug. 30, 2012

Re: [Pharo-project] The MC diff tool highligting is broken

by Mariano Martinez Peck

On Wed, Aug 29, 2012 at 11:31 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Do you have an idea when it happens? > Not at all :( > > Stef > > On Aug 29, 2012, at 9:13 AM, Mariano Martinez Peck wrote: > > > yes this is terrible broken since a long time. For me this is a really > stop-the-world. I cannot commit because I cannot be sure what I am > committing (since I cannot see the changes), you cannot merge safely. > > > > cheers, > > > > On Wed, Aug 29, 2012 at 7:35 AM, Camillo Bruni <camillobruni(a)gmail.com> > wrote: > > add a bug report :) > > > > On 2012-08-28, at 22:21, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > > in 2.0 it highlights random portions of text, completely out of sync > > > with real difference. > > > > > > and if you resize the window, it doesn't changes, it doesn't follows > > > the text.. (i think this can be a good hint to look for a place to > > > fix) > > > > > > -- > > > Best regards, > > > Igor Stasenko. > > > > > > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > -- Mariano http://marianopeck.wordpress.com

Aug. 30, 2012

Re: [Pharo-project] Pharo Integration Process

by Esteban Lorenzano

+1 but as you can see (the monkey is not completely functional), having the tools and actually modify the process to use them, are not completely the same :) anyway, yes, we should sit and prepare everything... maybe next week? On Aug 30, 2012, at 12:22 AM, Bernardo Ezequiel Contreras <vonbecmann(a)gmail.com> wrote: > +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. 30, 2012

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