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

Re: [Pharo-dev] funny TIOBE

by Pharo4Stef

On 28 Mar 2014, at 22:00, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Pavel Krivanek-3 wrote >> after a very long time I checked the TIOBE index and Smalltalk is not >> listed there at all... :-) > > Maybe we died and don't know it... must be heaven, not hot enough for the > other place ;) :) > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/funny-TIOBE-tp4751510p4751522.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

March 28, 2014

Re: [Pharo-dev] funny TIOBE

by Sean P. DeNigris

Pavel Krivanek-3 wrote > after a very long time I checked the TIOBE index and Smalltalk is not > listed there at all... :-) Maybe we died and don't know it... must be heaven, not hot enough for the other place ;) ----- Cheers, Sean -- View this message in context: http://forum.world.st/funny-TIOBE-tp4751510p4751522.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 28, 2014

Re: [Pharo-dev] Capturing stdout

by Sean P. DeNigris

Emilio Oca-3 wrote > I managed to do that in Windows using... ProcessWrapper... As it's for a core test, I need to find a way to do it without loading additional libraries. I could pipe the output to a tmp file if there's nothing... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Capturing-stdout-tp4751320p4751521.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 28, 2014

Every class should redefine printOn:

by Pharo4Stef

Hi guys Iâm trying to understand freeType and when I debug I get aBlah aFoo and this is frankly annoying because Iâm trying to learn the implementation and it does not help me at all. I hate the classes that only their implementors understand. In Pharo 4.0 I will put a strict rule: - no class will be integrated if they do not redefine printOn: - I will set a general rules to check printOn: methods. printOn: methods are the first debugging information. Stef

March 28, 2014

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

by Pharo4Stef

thanks Igor. Iâm trying to look at the font reloading bug. On 28 Mar 2014, at 17:19, Igor Stasenko <siguctua(a)gmail.com> wrote: > 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] DateAndTime>>#= slow?

by Pharo4Stef

> It is easy. It is called pharo 3.1 or pharo 4.0. The rule is: Donât change the current release being in freeze. Release it, change then everything you wanted in the next step and make sure you can release the next version pretty soon. IMHO the best solution to this kind of problems is to have small iterations. Yes I like your idea. We can do a 3.1. May be this is an indication that we should start a 4.0alpha? Stef

March 28, 2014

Re: [Pharo-dev] New Nautilus side bar buttons

by Pharo4Stef

On 28 Mar 2014, at 17:57, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > Hello guys, > > since I do not really like the new buttons introduced in Nautilus, > and since the previous one were broken, I propose this new set > of buttons based on the eclipse theme. > > <Nautilus new buttons.png> > <closeup.png> > > Tell me what you think about it :) much nicer! Tx > Ben >

March 28, 2014

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

by phil＠highoctane.be

On Fri, Mar 28, 2014 at 8:17 PM, Ben Coman <btc(a)openinworld.com> wrote: > phil(a)highoctane.be wrote: > > 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 > > > I wonder if it would be more or less effort to operate a "hot fix" > facility between releases. By this I mean, after Pharo 3 release all slices > fixing Pharo 3 bugs are based off the static release. This might have the > advantages that: > * Users get to select the bug fixes important to them > * Ergo, users can can avoid bug fixes not relevant to them that might have > unintended consequences in production. > * Bug fixes don't go stale when fixed in the released Pharo 3 but the > Pharo 3 builds have progressed a lot. > * Users don't have to decide between waiting for a the next Pharo 3 > minor-release, or tracking a moving target with continued evolution of > "latest" Pharo 3 after release. > * The part of the community that wants longer term support for systems in > production could take a greater role in maintaining Pharo 3, while the core > focus moves on to Pharo 4. > > A simple process might be tagging such resolved issues in Fogbugz as as > 3.0-hotfix. Alternatively a tool like the Configuration Browser might list > them in image. That tool could be installed from the Configuration Browser > as ConfigurationOfHotfix. > > The downside would be more difficulty in packaging hotfixes together for a > minor-release. However over time hotfixes might be consolidated into other > hotfixes, and the greatest of these becomes the basis for the minor-release. > > Just a passing thought. > cheers, Ben > > > A hotfix tool would be the other side of the Kommiter coin. So, Hotfixer? With a UI showing slices for which the status in FogBugz would be "hotfix30" Or a list of HOTFIX- in Pharo/Pharo30Hotfix/ in Smalltalkhub. Ah, let's make something for getting the ball rolling: http://www.smalltalkhub.com/#!/~Pharo/Pharo3Hotfix So,a HOTFIX shall possibly combine SLICEs or packages in a proper loading order and postscripts (like the one of Ben). I am currently writing some package loading code for my own use, this would be a nice opportunity for me to do a Spec based tool. Wanna join forces, people? 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

> > > On 28 Mar 2014, at 16:17, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > 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 ? > > > I thought that the refactoring of the themes was just a refactoring (not > changing anything). > > <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 ;-) > > 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 ? > > > > I know that I will not integrate anything anymore.... I wait till people > send mails to the list to ask to integrate something, and at least 3 people > vote positive. > > Marcus > > My fault. The submitted slice had some legitimate Theme bug fixes but > mixed in was flattening of the Theme hierarchy by moving Pharo3Theme to > subclass from UITheme rather than UIThemeWatery. That part was "cleanup" > rather than "bug fix" and I had some concerns which I failed to voice. To > revert that part I've uploaded > SLICE-Issue-13114-Broken-PharoTheme-BenComan.3. Hilaire, Could you review > this to check it looks okay. For overall effect this slice should be > reviewed against build 30802. > http://files.pharo.org/image/30/30802.zip > > -ben > I'l try that last one as the previous one brings weird effects on Nautilus navigation. I was loading a 30802 and applied several UI-related slices to it and the results weren't pretty. I have done a set of Gofer loads that I'll post later for interested people to test. Phil

March 28, 2014

Re: [Pharo-dev] New Nautilus side bar buttons

by Stephan Eggermont

Benjamin wrote >since I do not really like the new buttons introduced in Nautilus, >and since the previous one were broken, I propose this new set >of buttons based on the eclipse theme. Would you be so kind to explain what you do not like about them, and compare to both the earlier ones and this proposal? - I donât like that they donât adapt good enough to the chosen theme, they only fit with the Pharo3Theme; - I donât like that they do not show well that S and B provide two mutually exclusive views while I and C provide direct actions; - I donât like that they donât show well when they can be used; - I donât iike that S and B donât show the current state well - I donât like that you need the help text on hover to understand what they are for. - I donât like the alignment. This browser I look at so much, it deserves to have the letters aligned vertically correctly (visually, so C a few pixels to the left, I to the right); The main advantages they have in my opinion are: - They fit the theme; - They take much less attention away from the contents. Stephan

March 28, 2014