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

Re: [Pharo-dev] Bug in ZnUTF8Encoder

by Igor Stasenko

On 2 April 2014 14:19, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Igor, > > Great catch ! How did you stumble upon this one ? > > Just showing Max (my new room mate) to implement utf-8 encoding using Virtual CPU DSL, and using your code as an example. And ya, my sharp eye with perfect precision immediately detected the problem.... (hope it sounds arrogant enough) ;) Frankly, i don't know. What i think is, that i seen comparison with powers of two numbers in my life so many times, that i trained to automatically see if it correct or not. :) > Anyway, it shows that unless you really test all boundaries explicitly, > silly one-off errors like that manage to survive for quite some time. I > added a unit test doing just that. > > Fixed upstream: > > === > Name: Zinc-Character-Encoding-Core-SvenVanCaekenberghe.31 > Author: SvenVanCaekenberghe > Time: 2 April 2014, 2:14:36.890651 pm > UUID: 3f6ae285-2973-4451-833b-16afbd0658d3 > Ancestors: Zinc-Character-Encoding-Core-SvenVanCaekenberghe.30 > > Fixed a one-off error in ZnUTF8Encoder>>#nextPut:toStream (thanks Igor > Stasenko) > === > Name: Zinc-Character-Encoding-Tests-SvenVanCaekenberghe.18 > Author: SvenVanCaekenberghe > Time: 2 April 2014, 2:15:51.938152 pm > UUID: c7048056-52ae-484f-a466-7d537f66690a > Ancestors: Zinc-Character-Encoding-Tests-SvenVanCaekenberghe.17 > > Fixed a one-off error in ZnUTF8Encoder>>#nextPut:toStream (thanks Igor > Stasenko) > > Added ZnCharacterEncoderTests>>#testUTF8Boundaries > === > > Thanks again, > > Sven > > On 02 Apr 2014, at 13:18, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > nextPut: character toStream: stream > > ... > > code < 65535 ifTrue: [ > > ... > > > > should be > > > > code < 65536 ifTrue: [ > > > > because 3-byte encoding can fit 16 bits, which is range > > 0...65535 > > but not > > 0...65534 > > > > -- > > Best regards, > > Igor Stasenko. > > > -- Best regards, Igor Stasenko.

April 2, 2014

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

by Alexandre Bergel

I have followed the discussion from very far. But thank you guys for considering this important font problem. I will offer some beers at esug, I promise :-) Alexandre On Apr 2, 2014, at 7:09 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 2 April 2014 14:46, J.F. Rick <self(a)je77.com> wrote: > Is this supposed to fix the font rendering problem or some other font problem? I tried it and it doesn't seem to help the rendering problem. > > send me your image , pls. > (and provide doit to reproduce problem, i will try it on my linux box) > > Cheers, > > Jeff > > > -- > Best regards, > Igor Stasenko. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

April 2, 2014

Lock-free Atomic Counter ?

by Sven Van Caekenberghe

Hi, Is it possible to have a simple lock-free atomic counter in Pharo 3.0 ? nextId ^ idCounter := idCounter + 1 Or is it still possible that two process entering this code can mess things up ? I vaguely remember a discussion about that long ago... TIA, Sven

April 2, 2014

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

by Igor Stasenko

On 2 April 2014 14:46, J.F. Rick <self(a)je77.com> wrote: > Is this supposed to fix the font rendering problem or some other font > problem? I tried it and it doesn't seem to help the rendering problem. > > send me your image , pls. (and provide doit to reproduce problem, i will try it on my linux box) > Cheers, > > Jeff > > -- Best regards, Igor Stasenko.

April 2, 2014

Re: [Pharo-dev] Was TickingWindow integrated?

by Sven Van Caekenberghe

I added a comment to the issue tracker. On 02 Apr 2014, at 22:13, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > https://pharo.fogbugz.com/default.asp?12460 > > this is this issue and we should not let all these processes in the image. > > Stef > >> Hi guys >> >> Iâm in a train (no internet) and I see that the inspector does not refresh but in fact >> we introduced with clement a nice tickingWindow in spec and the goal is that the window >> refresh its contents. I have the impression it was not integrated. >> Note that this change is important because it removes a lot of processes hanging in the background. >> >> Stef > >

April 2, 2014

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

by Pharo4Stef

On 02 Apr 2014, at 14:46, J.F. Rick <self(a)je77.com> wrote: > Is this supposed to fix the font rendering problem or some other font problem? I tried it and it doesn't seem to help the rendering problem. normally it should fix the font PrObLem can you check that you loaded the latest NB? > > Cheers, > > Jeff > > > On Tue, Apr 1, 2014 at 6:27 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > okay i uploaded updated configs for NativeBoost and Athens into official repositories for these projects. > > Gofer new smalltalkhubUser: 'Pharo' project: 'NativeBoost'; > configuration; > load. > > ConfigurationOfNativeBoost loadDevelopment. > > > > Gofer new smalltalkhubUser: 'Pharo' project: 'Athens'; > configuration; > load. > > ConfigurationOfAthens loadDevelopment. > > > shall do the trick.. > > for more details see > https://pharo.fogbugz.com/f/cases/13150/Different-memory-alignment-on-diffe… > > > > On 28 March 2014 21:13, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > 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. > > > > > -- > Best regards, > Igor Stasenko. > > > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick

April 2, 2014

Re: [Pharo-dev] [Inspiration] Toward a better programming

by Pharo4Stef

On 02 Apr 2014, at 13:31, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 02/04/2014 08:12, Tudor Girba a Ã©crit : >> The language itself is less interesting for me, but what makes it stand >> out is that it has a coherent and robust philosophy behind and >> phenomenal goals to reach. In Pharo, we have the luxury of building on >> top of coherent and robust philosophy (even if different from the >> Wolfram one) and we should try as much as possible to keep our eyes on >> phenomenal goals that seem unreachable. > > I see two barriers in the current Pharo to be able to reach that: > > - Lack of clear documentation of the underlying code management structure and facilities. It takes ages to get into the gritty details of things like RPackage and the refactory framework, documentation is very often limited to "this is the way Nautilus does it", and "no worry about changing it, Nautilus developpers are the same guy" which ends up being very painful for someone outside that core group. I agree but who is writing doc beside me and sven? Do you think that this is easy to write doc on something that you did not write. For Rpackage this is not that complex and you do not want to document the part that glue inside announcement and other. > - GUI conservatism. The choice made in Pharo in the overall look is to be conservative and business-like, and so blame the too-advanced, too-fancy Morphic (and at the same time have Roassal pushing the enveloppe, but outside the normal toolkit :) which means someone would find it probably hard to do Roassal-based development tools). Glamour, Spec and GTToolkit are interesting to look at along that "conservatism" in GUI. You cannot clean Morphic without removing experimental stuff. Once we will have a better morphic then we can be more adventurous. You probably did not spend enough time in morphic if you do not think that Iâm right. :) Now this is clear that Roassal is a bit reinventing Morphic to some extend but this is like that. >> Another thing I like in Wolfram's work is attention to details: >> http://blog.wolfram.com/2008/01/10/ten-thousand-hours-of-design-reviews/ >> >> Details are crucial, and all the effort in Pharo around naming and >> redesigning what already exists is incredibly important. But, it is >> precisely at the moment when we are knee-deep in details that is crucial >> to keep our eyes on the phenomenal long term goals. > > I'm less convinced by that. Refining, trying, fiddling, spending hundreds of iterations on making drag and drop or scrolling perfect, yes. Redesigning whole chunks of the low-level facilities without really seeing where we will end up, at at the same time presenting a very conservative view on top of it, not much. > > For example, I know of a GTInspector use case which is entirely justified by deficiencies in the standard system browser ;) > >> There is so much to build. Let's be bold. > > +100 > > 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 >

April 2, 2014

Re: [Pharo-dev] [Spec] whenSelectedItemsChanged: on TreeModel

by Pharo4Stef

> I made a plugin to spy on the NaytimusAnnouncer and in fact there is a storm of announcements flying around all the time. > arghhhhhhhhhh Thanks for letting us knowing. > And they do not carry the expected payload ( nil instead of the method for example) > > The plugin is in Smalltallhub in philippeback , HOExtras > > I'll do a screencast to show you. > > Phil > > Le 2 avr. 2014 13:30, "Martin Dias" <tinchodias(a)gmail.com> a Ã©crit : > Hi, > > I still can reproduce this issue in Pharo 30807 (last image). I'm trying to workaround it with some problems. > > I ignore if this is already reported in fogbugs. Steps to reproduce: > > a) do it: > > TreeModel new > roots: (1 to: 2); > whenSelectedItemsChanged: [ :items | self logCr: items ]; > openWithSpec. > > > => in Transcript I see: > > b) during initial do it: > > #() > > c) after a click on 2: > > #() > an OrderedCollection(2) > > d) after a click on 1: > > an OrderedCollection(2) > an OrderedCollection(2) > an OrderedCollection(1) > > > Cheers, > MArtÃn > > > > On Wed, Dec 11, 2013 at 6:10 PM, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > As I said to Martin, I will investigate why, but itâs a bit tricky > Must be some issue in MorphTreeMorph I introduced recently > > Ben > > On 11 Dec 2013, at 16:46, Roberto Minelli <roberto.minelli(a)usi.ch> wrote: > >> Hi, >> >> I am experiencing problems with #whenSelectedItemsChanged: on a TreeModel. >> >> In particular, the block (i.e., argument of #whenSelectedItemsChanged: gets randomly executed a couple of times (3/4) the second time that the selection happens. The first time is fine. It looks like the registration of the âeventâ or âannouncementâ is done multiple times. >> >> Any hint? >> >> Cheers, >> R > >

April 2, 2014

Re: [Pharo-dev] Thanks to all of you who asked

by phil＠highoctane.be

Same here. For the record, Chile was on the top of Yahoo! mobile news. I happen to be at the Hadoop Summit in Amsterdam and that's where I saw the news. Phil On Wed, Apr 2, 2014 at 8:18 PM, Sergi Reyner <sergi.reyner(a)gmail.com> wrote: > 2014-04-02 16:17 GMT+01:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > >> As you may know, an earthquake occurred yesterday evening in the north of >> Chile. It was a strong one. >> > > First news I have. Probably because I donÂ´t actually watch or read the > news :D > > >> Many of us have asked how well we are. We are all good. >> > > Glad everyone is allright :) > > Cheers, > Sergi > >

April 2, 2014

Where are the monkey rules?

by Pharo4Stef

Hi this is really annoying not to be able to run the same rules than the ones in the monkey. Why? because the feedback loop is terrible. So where are defined the monkey rules? How can I load them and run them on a slice? Also this is annoying that a change get rejected because of problem in the package but not in the code published by the slice. Right now this leads to important fixes not been integrated because they were flagged automatically by the monkey and passed under the radar. So after a month going back again inside the changes is not fun. Luckily there were simple. Stef

April 2, 2014