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

Re: [Pharo-dev] Release Mode

by Norbert Hartl

Am 28.03.2014 um 16:17 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > On 28 Mar 2014, at 16:00, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On 28 Mar 2014, at 15:52, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >>> While I was on holiday, it seems my dear friends have gone feature crazy... >>> almost as bad as me in the run up to the 2.0 release, ha ha. >>> >>> As cool as they are, are: >>> - changing the look of Nautilus buttons >>> - evaluate arbitrary expressions in Spotlight >>> - etc, etc >>> showstopping bugs?! >>> >>> This beta time is reserved specifically for finding the bugs that may >>> inevitably be introduced with these enhancements. We really may be creating >>> a mess, as end users find them in our "stable" release instead. >>> >> >> >> Yes, it was wrongâ¦ maybe we should revert. >> >> Marcus > > Yes, maybe ;-) > > I don't like the red (ish) / orange rectangle around dirty text areas (instead of the orange thing in the corner) - Where did that come from ? Did we discuss about that ? > > <Screen Shot 2014-03-28 at 16.14.56.png> > > PS: I marked the 'evaluate arbitrary expressions in Spotlight' not as a bug, but an enhancement, with would be nice priority, but indeed for 3.0 - but I certainly cannot blame Markus either - and BTW, there was a discussion about it, people tested it and nobody said no - and it is a perfectly safe change ;-) > There is no perfectly safe change. > PS2: I do have a bit of a problem with people being so vocally against changes, unless they are fixing the hard bugs themselves instead. If we all do nothing, the release won't get better, right ? > A release does not get better if you change non-bug related stuff while being in freeze. The only thing that happens is that you will postpone the release indefinite. This is such a basic thing that makes me wonder people are questioning at all. If you change the code the odds are high you break something. Doing that without taking the time to think about will make it worse. If a release is in sight there is emotionally not much time left so no time to think. The result: you break stuff. Just like that. You might then discuss (again) the rules for success or what is important or even more important or most important or more most important. That is subject for discussion and highly subjective. On the other hand there is a hard fact: you break things! Period. Norbert

March 28, 2014

Re: [Pharo-dev] Release Mode

by Benjamin

On 28 Mar 2014, at 17:30, Stephan Eggermont <stephan(a)stack.nl> wrote: > Philippe wrote >> The look of nautilus button isn't "ok to integrate" since there is much more work needed to get this working properly. > > Thatâs two different issues. One is integrated, the other not. > 13137 The SBIC buttons change is ok, afaik. No itâs not ok. It looks really bad, and really far from anything else Ben > 13135 exposes lotâs of issues in the tools. All kinds of off-by-ones in sizes. > > I also prefer the scrollbar fixes (13136) > > Stephan

March 28, 2014

Re: [Pharo-dev] Release Mode

by Stephan Eggermont

Philippe wrote >The look of nautilus button isn't "ok to integrate" since there is much more work needed to get this working properly. Thatâs two different issues. One is integrated, the other not. 13137 The SBIC buttons change is ok, afaik. 13135 exposes lotâs of issues in the tools. All kinds of off-by-ones in sizes. I also prefer the scrollbar fixes (13136) Stephan

March 28, 2014

Re: [Pharo-dev] [Moose-dev] Re: Re: Re: Fwd: Font problem is still there

by Igor Stasenko

https://pharo.fogbugz.com/f/cases/13150/Different-memory-alignment-on-diffe… On 28 March 2014 16:42, Igor Stasenko <siguctua(a)gmail.com> wrote: > so, the quick and dirty fix is to put: > > CairoGlyph class>>byteAlignment > > NativeBoost platformId = NativeBoostConstants win32PlatformId ifTrue: > [ ^ 8 ]. > ^ super byteAlignment > > and then: > > CairoGlyph rebuildFieldAccessors > CairoGlyphsArray initialize > > (note you must run this snippet each time your image changes platform).. > > and i need more time to fix it for real, because it is NB issue, to > automatically recalculate the structs size > if it changes platform.. (which also means you cannot store instances of > struct in image which survive the session) > ... damn.. that's going to be complicated. > > --- > > > > On 28 March 2014 16:27, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> >> >> On 28 March 2014 16:01, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> >>> Ookkayy.. >>> so, current status: >>> >>> - finally we got an agreement that big red square because of font >>> loading issues and font rendering artifacts is two separate issues. >>> Thanks! >>> - i am not going to address font-loading issue here and now.. (because >>> we spent time on it earlier today with Stef already and you should have the >>> report on it in separate mail). >>> >>> - we seem to be agreed that it is best to use same (up-to-date version) >>> of software when reporting issues to work on them. Thanks again. :) >>> >>> - while on linux and mac things seem to be working fine, i can confirm >>> that there is rendering artifacts (same as reported by Vincent) on Windows. >>> >>> so i going to explore what causing this problem.. >>> >>> ... and found the cause: >> >> On windows, for unknown reason, the structure (cairo_glyph_t) uses >> different memory space alignment than on mac and linux >> >> fieldsDesc >> ^ #( >> ulong index; >> double x; >> double y; >> ) >> >> on mac and linux , the size of this structure in memory = 4 + 8 + 8 = 20 >> bytes, >> on windows, however, due to 8-byte alignment, it is 4 + 8 + 8 + (4 >> alignment) bytes... >> >> this causing the effect that if you copy array of glyphs in memory, >> it does not copying whole array by slightly less (because it uses wrong >> struct size which is smaller than it is).. >> and because of that, you got weird artefacts at the tail of string, >> replaced by misplaced/invalid characters etc.. >> because it is basically read from uninitialized part of memory with >> random data. >> >> i going to fix structure alignment for windows from default 4 bytes to 8 >> bytes.. >> but this is not very good news.. because this affecting many things... >> (as you can imagine, not only cairo/athens working with external >> structures, which need to be properly aligned). >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.

March 28, 2014

Re: [Pharo-dev] Release Mode

by Stephan Eggermont

Sean wrote: >As cool as they are, are: >- changing the look of Nautilus buttons >showstopping bugs?! Yes. Or at least they should be. Releases are for new users. There the first impression is crucial. We are all used to these ugly buttons and know that the functionality is the same. New users donât know that and expect things that look different to behave differently. They are also important for people following new technologies trying to decide which ones to adopt. Not fixing these things essentially says our community is so resource-starved we cannot afford to spend time fixing such obvious mistakes. That is not the message I want to send with a new release. Stephan

March 28, 2014

Re: [Pharo-dev] New website about Spec - http://spec.st

by Benjamin

On 28 Mar 2014, at 16:57, phil(a)highoctane.be wrote: > Sorry about that. It wasn't intentional. No problem :P It motivated me to finish fast :P > Superb work. And I want that dark theme :-) Me too :P Ben

March 28, 2014

Re: [Pharo-dev] Release Mode

by Marcus Denker

On 28 Mar 2014, at 16:53, phil(a)highoctane.be wrote: > The look of nautilus button isn't "ok to integrate" since there is much more work needed to get this working properly. > > Now, the scrollbars in 2.0 really suck if you ask me. So, I'd vote for that one. > > Welcome back to the fray. > So lets revert all the updates of this week, from the problematic ones onwards. But I can only work on that next week. Marcus

March 28, 2014

Re: [Pharo-dev] New website about Spec - http://spec.st

by phil＠highoctane.be

Sorry about that. It wasn't intentional. Superb work. And I want that dark theme :-) Phil On Fri, Mar 28, 2014 at 4:03 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Super nice, very professional, congratulations to everybody who working on > this! > > On 28 Mar 2014, at 14:18, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> > wrote: > > > Hi guys :) > > > > I am glad to announce (even if Philippe already let the cat out :P) a > website dedicated to Spec: http://spec.st. > > You can find a quick introduction, documentation (mainly what is now in > the Pharo For The Enterprise book), and > > a news feed where I will explain the API changes, the news widgets > introduce etc. > > > > The website contents can be found here ( > https://github.com/spec-framework/website) so if you want to contribute > > you are welcome :) > > > > Ben > > > > PS: I would like to thank Johan Fabry who helped me a lot writing the > documentation, > > Sean P. DeNigris who fixed my english a couple of times and Nicolas > Petton who > > helped me on the website look and feel > > >

March 28, 2014

Re: [Pharo-dev] DateAndTime>>#= slow?

by phil＠highoctane.be

Looks like a lot of people are going to be running patched versions if the release goes without some enhancements. What about a ConfigurationOfPharo30EnhancementsPackThatWereNotIntegratedForSomeSurelyVeryValidReason ? (Let's make the name shorter but you get the idea). Phil On Fri, Mar 28, 2014 at 4:02 PM, Johan Brichau <johan(a)inceptive.be> wrote: > Hi all, > > With Sven's fixes loaded, our model unit tests are all running fine. The > benchmarks indicate the same speed as in 1.4. This is really great! > I'm still running the entire suite of tests but that will take a while to > complete. But essential datetime bugs should have been spotted already. > > Great work Sven! > I think it's worth integrating. If not, we will definitely work with this > patched version. > > Johan > > On 28 Mar 2014, at 13:36, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > > > Hi johan > > > > Please let us know because I would be in favor of integrating such speed > up if your system fully work. > > > > stef > > > > > > On 28 Mar 2014, at 09:17, Johan Brichau <johan(a)inceptive.be> wrote: > > > >> > >> On 28 Mar 2014, at 06:24, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> > >>> Bugs are errors that prevents the system to run. > >> > >> <nagging> > >> Some performance problems make the system impossible to work with > >> </nagging> > >> > >> Anyway, going to check in Sven's changes today. > >> > >> cheers > >> Johan > >> > > > > > > >

March 28, 2014

Re: [Pharo-dev] Release Mode

by phil＠highoctane.be

The look of nautilus button isn't "ok to integrate" since there is much more work needed to get this working properly. Now, the scrollbars in 2.0 really suck if you ask me. So, I'd vote for that one. Welcome back to the fray. Phil On Fri, Mar 28, 2014 at 3:52 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > While I was on holiday, it seems my dear friends have gone feature crazy... > almost as bad as me in the run up to the 2.0 release, ha ha. > > As cool as they are, are: > - changing the look of Nautilus buttons > - evaluate arbitrary expressions in Spotlight > - etc, etc > showstopping bugs?! > > This beta time is reserved specifically for finding the bugs that may > inevitably be introduced with these enhancements. We really may be creating > a mess, as end users find them in our "stable" release instead. > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Release-Mode-tp4751408.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

March 28, 2014