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

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

by Igor Stasenko

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.

March 28, 2014

Re: [Pharo-dev] Capturing stdout

by Emilio Oca

Hi I managed to do that in Windows using ProcessWrapper new useStdout; startWithShellCommand: aCommand ; upToEnd. where aCommand is something like: "someApp.exe -p params moreParams > G:\other\place\stdou.log" This is what Hernan Morales offered > Gofer it > url: 'http://www.smalltalkhub.com/mc/hernan/ProcessWrapper/main'; > package: 'ProcessWrapper-Core'; > package: 'ProcessWrapper-Plugin'; > package: 'ProcessWrapper-Tests'; > load. > > ProcessWrapper new > useStdout; > startWithShellCommand: 'dir | sort'; > upToEnd Best Emilio > -----Mensaje original----- > De: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] En nombre de > Sean P. DeNigris > Enviado el: Viernes, 28 de Marzo de 2014 08:58 > Para: pharo-dev(a)lists.pharo.org > Asunto: [Pharo-dev] Capturing stdout > > I want to write a test for an NB Mac system call example (Issue 13147). > I can > check the exit code easily, the output goes to stdout of the image. Can > I > capture it somehow? thx :) > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Capturing-stdout- > tp4751320.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com.

March 28, 2014

Re: [Pharo-dev] Release Mode

by Marcus Denker

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

March 28, 2014

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

by Igor Stasenko

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.

March 28, 2014

Re: [Pharo-dev] Release Mode

by Sven Van Caekenberghe

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 ? 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 ?

March 28, 2014

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

by Sven Van Caekenberghe

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 Johan Brichau

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] [Moose-dev] Re: Re: Re: Fwd: Font problem is still there

by Igor Stasenko

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.. -- Best regards, Igor Stasenko.

March 28, 2014

Re: [Pharo-dev] Capturing stdout

by Max Leske

On 28.03.2014, at 15:55, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Max Leske wrote >> Forget what I saidâ¦ Just ramblingâ¦ > > Ha ha, I was doing the confused-puppy-head-tilt (see > http://da0cb6511396a92928c7-488d28a6573db6ac4a247063b638fcb9.r77.cf2.rackcd…) :p > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Capturing-stdout-tp4751320p4751409.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

March 28, 2014

Re: [Pharo-dev] Release Mode

by Marcus Denker

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

March 28, 2014