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

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

by Max Leske

Yes, Iâve experienced this (in older Pharo versions mind you). We explicitly donât use DateAndTime / Date / Timestamp in such cases but store an integer representation instead. We can always reify that if we need to and still have good comparison speeds. Cheers, Max On 26.03.2014, at 22:21, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > I'm grouping by date a resultset coming from the database, it > cointains around 2000 dated objects. > > It is: > myObject groupBy: #date. > > But turn's out that DateAndTime #= comparison is elegant object-wise > but not performance-wise. Because it instantiates several other > objects along the way. > > This is in the milliseconds range, but in the agregate of a couple of > thousand of objects, it creates a lot of not-simple-objects (it is, > not integers), and maybe because of that it isn't as fast as I'd > expect. > > Did somebody experienced this too? > > Regards, > > Esteban A. Maringolo >

March 26, 2014

Re: [Pharo-dev] Replacing SBCI buttons in Nautilus.

by Stephan Eggermont

https://pharo.fogbugz.com/default.asp?13137 Name: SLICE-Issue-13137-Replace-SBCI-buttons-StephanEggermont.1 Author: StephanEggermont Time: 26 March 2014, 10:30:33.195511 pm UUID: 39080266-ad51-43f9-8ab4-5afe636d7372 Ancestors: Dependencies: Nautilus-StephanEggermont.709 Replace the bitmap-backed buttons through simpler ones

March 26, 2014

DateAndTime>>#= slow?

by Esteban A. Maringolo

I'm grouping by date a resultset coming from the database, it cointains around 2000 dated objects. It is: myObject groupBy: #date. But turn's out that DateAndTime #= comparison is elegant object-wise but not performance-wise. Because it instantiates several other objects along the way. This is in the milliseconds range, but in the agregate of a couple of thousand of objects, it creates a lot of not-simple-objects (it is, not integers), and maybe because of that it isn't as fast as I'd expect. Did somebody experienced this too? Regards, Esteban A. Maringolo

March 26, 2014

Re: [Pharo-dev] Replacing SBCI buttons in Nautilus.

by Stephan Eggermont

Interesting enough, a PluggableButtonMorph does not center the label. I've improved the layout by adding a space, but for correct (optical) alignment, the I needs to move about half a space to the right, and the C needs to move a few pixels to the left. Even though a PluggableButtonMorph has lots of different ways to set colors, I've not found one that works. Themability is nice, but it should check for and respect overrides. In 30803, without Philippe's slices, with the three themes:

March 26, 2014

Replacing SBCI buttons in Nautilus

by Stephan Eggermont

Iâve been inspired by Philippeâs work on the UI and spend the afternoon replacing the SBCI bitmapped-backed buttons by normal ones. Stephan

March 26, 2014

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

by Tudor Girba

Thanks, indeed :) Please keep us informed. Doru On Wed, Mar 26, 2014 at 5:57 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > > I didn't tried to debug it, i can't bet it would be easy (need to build > a debug version of cairo first) > > but it worth trying. > > Meanwhile i will put workaround back. > > Thanks Igor. Let us know! > > Alexandre > > > > > > > Hi! > > > > > >> there's some kind of caching interference either in cairo or between > cairo and freetype, > > >> when using identity transformation matrix and integral (integer) font > sizes. > > >> and there is a simple workaround: > > >> > > >> canvas pathTransform restoreAfter: [ > > >> canvas pathTransform scaleBy: 1.00001. > > >> "draw text here" > > >> > > >> ] > > >> > > >> this workaround was in font-rendering code, but then i removed it, > because i thought problem was solved. > > > > > > Can we add this back please? > > > This font problem is quite serious. It makes people laugh at Pharo... > > > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- www.tudorgirba.com "Every thing has its own flow"

March 26, 2014

Redraw suggestion for Athens

by J.F. Rick

I've been using Athens to render my applications and I've thought a bit about how the #changed mechanism might change when BitBlt rendering is replaced by Athens rendering. First, you must realize that a lot of the rendering in Morphic is highly specialized to deal with the slowness of BitBlt rendering. So, a morph that has changed in appearance (by moving, etc.) calls the #changed message on itself. This tells morphic that it needs to get rerendered when the screen is next being updated. The full bounds of the morph are then added to the damage recorder. When the UI loop gets around to it, the damage areas are rerendered in a relatively smart fashion. For instance, if a morph is opaque, none of the morphs behind it get rendered. Only the damage rectangles are copied to the canvas, which is then updated. With Athens, this strategy is problematic. Because Athens allows for arbitrary rotation and scaling, it is much more difficult to determine the bounds of a specific morph. Athens also can use local positioning as opposed to the global positioning currently used in Morphic. Igor argues that it is best not to try to figure this out but just to render everything when anything has changed. In my experience, that is a reasonable proposition. Athens rendering is fast enough that even full animation could be done reasonably. That would also simplify the #changed code and could pretty much eliminate the damage recorder. OK. That's enough setup. Now for the suggestion. One problem I still have with Athens rendering is that there is still a visual artifact that has to do with the screen refresh not being in sync with the UI loop. Half the screen renders the previous frame and the other half renders the current frame. While it only is noticeable when moving something fast, it still isn't nice. So, here's the suggestion. Have two Athens surfaces in memory that switch between being the one next to be rendered and the active one. When the screen refresh comes along, send it to the last one rendered (i.e., the active one). When a change happens, render the surface on the inactive one. When that is done, make it the active one. Thus, the screen update always has an accurate form. It also would mean less copying around of forms (i.e., cacheing). I'm not sure if this implementation is viable, but it seems like a fairly efficient strategy that Athens could enable. Cheers, Jeff -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

March 26, 2014

Re: [Pharo-dev] When change on class with trait freeze

by Hilaire Fernandes

The problem did not show up with Pharo 1.4 with the same big trait. Hilaire Le 26/03/2014 17:26, Ben Coman a Ã©crit : > Hilaire Fernandes wrote: >> https://pharo.fogbugz.com/f/cases/13133/When-change-on-class-with-trait-fre… >> >> >> > I've somewhat isolated the problem, as reported on the case. Its > related to... > TEasilyThemed methods size "--> 164" > and the sources being updated individually for each method. That is as > far as I can take it on my own. > > cheers -ben > > > -- Dr. Geo http://drgeo.eu

March 26, 2014

Re: [Pharo-dev] Random refactoring on UITheme or what?

by Hilaire Fernandes

Ben, My personal opinion on that: - Pharo3Theme subclassing UIWatery was not necessary as these two themes have mostly nothing in common - Indeed if you want to only change a base color of watery theme, you have to subclass from it. - For DrGeo on tablet I needed a dedicated theme to remove the windows decoration, for positionning dialog centered on the top, etc., and with the look of watery; so I subclassed from watery. Thanks for the integration work Hilaire Le 26/03/2014 18:08, Ben Coman a Ã©crit : > Just curious to learn... I saw mentioned somewhere that it was bad to > subclass themes. What is inherently wrong with that? For example > Pharo3Theme was inheriting from UIWateryTheme ? > If I wanted my own theme, the same as UIThemeWatery but a different > baseColor, > should I do... > UITheme subclass: MyTheme > and copy all methods from UIThemeWatery > then modify MyTheme class >> baseColor > > or do... > UIThemeWatery subclass: MyTheme > and add MyTheme class >> baseColor > > cheers -ben -- Dr. Geo http://drgeo.eu

March 26, 2014

Re: [Pharo-dev] threading in Pharo

by Eliot Miranda

Hi Ben, On Wed, Mar 26, 2014 at 7:04 AM, Ben Coman <btc(a)openinworld.com> wrote: > Eliot Miranda wrote: > > > > > On Tue, Mar 25, 2014 at 10:21 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > >> Hi Igor, >> >> >> you have a point but I disagree. The scheduler is defined in the >> implementation section of the blue book. It could be more explicit, but >> the blue book scheduler is a known and simple system. In my threading work >> I've made sure to preserve its semantics (cooperative within priorities, >> preemptive across priorities, thread switch at activation of non-primitive >> sends and backward branches). The only serious bug I know of (that >> preempting sends a process to the back of its run-queue) was addressed in >> Cog and the VW VM. We can and should write up the semantics, but they're >> not undefined, they're simple and they do work. >> > > Oops. I lie. There is a serious bug with Semaphore>>critical: and the > like. There's a suspension point after signal and before block evaluation > that can result in deadlock if a higher priority process signals the > semaphore. Since the higher priority process is running the lower priority > process never makes progress to run the ensure block or cvlear the flag or > whatever it needs to do, and hence the system deadlocks. This requires > thought ;-) So I do know of one outstanding bug. > > My grasp of concurrency controls hasn't been tested in 20 years, so > naively I would say: If a lower priority process "L" holds** a semaphore > when the higher priority process "H" signals the semaphore, temporarily > raise the priority of the "L", or temporarily lower the priority of "H". > Is there something simple that I missing? > There are a couple of obvious solutions. One is to avoid the suspension point somehow, another is adding priority inversion. Adding priority inversion to the scheduler is a significant change which would increase complexity. You yourself have glossed over detail by saying "temporarily". I've glossed over a lot with "somehow". How would these "temporarily"s and "somehow"s be implemented? Your design sketches are appreciated. cc'ing vm-dev and squeak dev lists. this is an important discussion. > cheers -ben > > > > >> Eliot (phone) >> >> On Mar 25, 2014, at 10:11 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> >> >> >> On 25 March 2014 17:31, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >>> Hi Igor, >>> >>> >>> On Tue, Mar 25, 2014 at 5:05 AM, Igor Stasenko <siguctua(a)gmail.com>wrote: >>> >>>> >>>> >>>> >>>> On 24 March 2014 22:54, phil(a)highoctane.be <phil(a)highoctane.be> wrote: >>>> >>>>> On Mon, Mar 24, 2014 at 8:23 PM, Alexandre Bergel < >>>>> alexandre.bergel(a)me.com> wrote: >>>>> >>>>>> >> I am working on a memory model for expandable collection in Pharo. >>>>>> Currently, OrderedCollection, Dictionary and other expandable collections >>>>>> use a internal array to store their data. My new collection library recycle >>>>>> these array instead of letting the garbage collector dispose them. I simply >>>>>> insert the arrays in an ordered collection when an array is not necessary >>>>>> anymore. And I remove one when I need one. >>>>>> > >>>>>> > Hm, is that really going to be worth the trouble? >>>>>> >>>>>> This technique reduces the consumption of about 15% of memory. >>>>>> >>>>>> >> At the end, #add: and #remove: are performed on these polls of >>>>>> arrays. I haven't been able to spot any problem regarding concurrency and I >>>>>> made no effort in preventing them. I have a simple global collection and >>>>>> each call site of "OrderedCollection new" can pick an element of my global >>>>>> collection. >>>>>> >> >>>>>> >> I have the impression that I simply need to guard the access to >>>>>> the global poll, which is basically guarding #add: #remove: and #includes: >>>>>> > >>>>>> > One of the AtomicCollections might be the right things for you? >>>>>> >>>>>> I will have a look at it. >>>>>> >>>>>> >> What is funny, is that I did not care at all about multi-threading >>>>>> and concurrency, and I have not spotted any problem so far. >>>>>> > >>>>>> > There isn't any 'multi-threading' like in Java, you got a much more >>>>>> control version: cooperative on the same priority, preemptive between >>>>>> priorities. >>>>>> > So, I am not surprised. And well, these operations are likely not >>>>>> to be problematic when they are racy, except when the underling data >>>>>> structure could get into an inconsistent state itself. The overall >>>>>> operations (adding/removing/searing) are racy on the application level >>>>>> anyway. >>>>>> > >>>>>> > However, much more interesting would be to know what kind of >>>>>> benefit do you see for such reuse? >>>>>> > And especially, with Spur around the corner, will it still pay off >>>>>> then? Or is it an application-specific optimization? >>>>>> >>>>>> I am exploring a new design of the collection library of Pharo. Not >>>>>> all the (academic) ideas will be worth porting into the mainstream of >>>>>> Pharo. But some of them yes. >>>>>> >>>>>> Thanks for all your help guys! You're great! >>>>>> >>>>>> Cheers, >>>>>> Alexandre >>>>>> >>>>>> -- >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>> Alexandre Bergel http://www.bergel.eu >>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> An interesting method I stumbled upon which may help in >>>>> understanding how these things do work. >>>>> >>>>> BlockClosure>>valueUnpreemptively >>>>> "Evaluate the receiver (block), without the possibility of >>>>> preemption by higher priority processes. Use this facility VERY sparingly!" >>>>> "Think about using Block>>valueUninterruptably first, and think >>>>> about using Semaphore>>critical: before that, and think about redesigning >>>>> your application even before that! >>>>> After you've done all that thinking, go right ahead and use it..." >>>>> | activeProcess oldPriority result semaphore | >>>>> activeProcess := Processor activeProcess. >>>>> oldPriority := activeProcess priority. >>>>> activeProcess priority: Processor highestPriority. >>>>> result := self ensure: [activeProcess priority: oldPriority]. >>>>> >>>>> >>>> I would not recommend you to use this method for anything. >>>> This method heavily relies on how process scheduler works, and in >>>> case of any changes, it may break everything. >>>> For the sake of programming, one shall never assume there is a way to >>>> "stop the world while i busy doing something". >>>> >>> >>> Really? Surely any system as interactive as Smalltalk can benefit >>> from a stop-the-rest-of-the-world scheduling facility, and surely packaging >>> it as BlockClosure>>valueUnpreemptively would be a convenient way of doing >>> so. Surely the right attitude for an implementor of a threading system for >>> Smalltalk would be "Sure, I can implement that, even in a truly concurrent, >>> multi-processor environment". It may take some doing but it's an important >>> facility to have. It shouldn't be abused, but when you need it, you need >>> it. >>> >>> >> There should be hard guarantees from VM to do it. Right now there's none. >> That's my point. >> Like special primitive(s) for disabling interrupts/scheduling and >> enabling it back again. >> Let us be realistic: the above implementation is based on insider's >> knowledge how scheduling works, lacking any notion of contract between VM >> and image. >> Right now it just based on implementation detail rather than on >> guaranteed and well defined semantic. >> >> It is no doubt, sometimes you may need such hammer to stop the world. >> And it is no doubt (to me) that one should avoid using it unless it is >> impossible to do otherwise. >> >> >> >>> -- >>> best, >>> Eliot >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> > > > -- > best, > Eliot > > > -- best, Eliot

March 26, 2014