- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Moose-dev] Problem with fonts
by Pharo4Stef March 28, 2014

March 28, 2014

On 28 Mar 2014, at 12:38, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: Hi We found with igor the problems that produced red cross in Moose. The problem is that the system is looking Source Sans Pro and does not find it. The logic in findBestFont: does not find it because there is no such font registered in font manager and the default logic is to return TextStyle defaultFont which is a bitmpa one. So question: - may be we should have a FT font default loaded in the system? - Doru we remember that you loaded font in the system? May be you do not register well the fonts. Could you let us know what you did? can you execute the following -0 (LogicalFont familyName: 'Source Sans Pro' pointSize: 12) realFont you should get a freetype font - 1 Disable the freetrype in the setting - 2 Enable again freetype in the setting - 3 (LogicalFont familyName: 'Source Sans Pro' pointSize: 12) realFont because you should get a strikeFont and this is the bug So it looks like the image level fonts are lost. Stef and Igor. _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

2 3

Re: [Pharo-dev] [Moose-dev] Problem with fonts
by Esteban Lorenzano March 28, 2014

March 28, 2014

Hi, well.. source sans pro should be loaded (along with source code pro), but: 1) I loaded the wrong font. 2) for some reason, the build fails to use it by default (you need to update âuse freetypeâ in settings, then re-choose). I did not spend too much time on trying to fix that bug (others were more urgent), but for those who want to spend a bit on it (cough, cough, Doru, cough, cough), half of the work is already done :) Esteban On 28 Mar 2014, at 08:38, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi > > We found with igor the problems that produced red cross in Moose. > The problem is that the system is looking Source Sans Pro and does not find it. > > The logic in findBestFont: does not find it because there is no such font registered in font manager > and the default logic is to return TextStyle defaultFont which is a bitmpa one. > > So question: > - may be we should have a FT font default loaded in the system? > > - Doru we remember that you loaded font in the system? May be you do not register well the fonts. > Could you let us know what you did? > > Stef and Igor. > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

1 0

Re: [Pharo-dev] SmalltalkHub update
by Stephan Eggermont March 28, 2014

March 28, 2014

Do you test with Safari? I get lots of restarts.10.9.2 Stephan

3 2

Fwd: Feedback for Pharo 3
by Pharo4Stef March 28, 2014

March 28, 2014

Begin forwarded message: > From: Richard Sargent <richard.sargent(a)gemtalksystems.com> > Subject: Feedback for Pharo 3 > Date: 27 Mar 2014 18:46:11 GMT+1 > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > Hi StÃ©phane, > > Benjamin Pollack @bitquabit just tweeted the features list for 3.0. I have to say that you folks have some really exciting things happening there. > > However, the naming of the methods for the "Simple Delayed Execution for Blocks" needs work. The #value* methods are so named because they return the value from the Block's execution. Neither #valueWithInterval: nor #valueAfterWaiting: answers the result of the Block's evaluation. > > The naming of the arguments is questionable, too. The name "aDelay" suggests an instance of a given class, but the comment suggests the argument is an integer (milliseconds). I can see argument for a Duration as the argument, in the expression [...something...] evaluateEvery: 100 ms. I don't think it can get clearer than that. But for performance, one might want an integer argument. Here the naming gets challenging. #evaluateEveryMilliseconds: is as close as I can come to readable, but I don't really like it either. > > > Thanks for all your hard work (and good work!). > Richard Sargent >

2 1

Re: [Pharo-dev] Smalltalkhub & API
by Stephan Eggermont March 27, 2014

March 27, 2014

Hi Phil, Did you take a look at a smalltalkhub image https://ci.inria.fr/pharo-contribution/job/SmalltalkHub/ The Hub package provides a starting point. Stephan

4 3

Re: [Pharo-dev] DateAndTime>>#= slow?
by Stephan Eggermont March 27, 2014

March 27, 2014

Esteban wrote >How do I test it? >Do I have to download a whole new 3.0 image? Normal way to test is to download latest 3.0 image and run it (on latest vm). Open monticello, open Pharo30Inbox, Type the issue number to find the slice and merge it to see changes. Stephan

2 1

Re: [Pharo-dev] DateAndTime>>#= slow?
by Stephan Eggermont March 27, 2014

March 27, 2014

Sven wrote: >PS2: I am not sure I am allowed to fix this so close to release, is it a feature or a bug fix ? ;-) Donât worry, if you look at the slope of our issue burndown chart you might notice that we need to change directions to get closer to releaseâ¦ Stephan

1 0

Redraw suggestion for Athens
by J.F. Rick March 27, 2014

March 27, 2014

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

2 2

Streaming problem in case of errors
by Damien Cassou March 27, 2014

March 27, 2014

P Hi guys, when PharoDebug.log can't be created (e.g., when the image is in a non writeable directory like /usr/share), the errors are sent to the Transcript in the hope that they will be redirected to stdout or stderr. However, ContextPart>>errorReportOn: is called when an exception is signaled and this method assumes that the stream is positionable (which is not the case for transscript, stdin and stderr). I was planing on rewriting ContextPart>>errorReportOn: to make it independent of #position. What do you think? -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

2 5

Re: [Pharo-dev] DateAndTime>>#= slow?
by Esteban A. Maringolo March 27, 2014

March 27, 2014

2014-03-27 12:21 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > On 27 Mar 2014, at 12:14, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> On 27 Mar 2014, at 15:46, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>> Will the fix be available for Pharo 2 builds as well? >> >> I knew you were going to ask that, but I don't know. The whole Chronology package was changed quite a lot going from 2.0 -> 3.0 >> >> On the other hand, my changes are pretty comprehensible (a couple of methods), somebody could certainly try to backport them - but no guarantees they will work though. > > pharo3 is at the corner to be out. > we are not integrating/backporting changes to pharo2 since... well, like 6 months. > so no, it will not be there and it will not be integrated. What is the support strategy for stable versions? Pharo 3 is still beta/release-candidate, so... strictly speaking Pharo 2 is the official stable version. Shouldn't it get support as such? If resource scarcity rules here, I'll understand. > said so... anyone can do their own backport and put it for others in a meta repo :) It will be so. :) Esteban A. Maringolo

1 0