- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] ConfigurationOfMorphicCore

by Pavel Krivanek

Thank you, Doru, the initial redrawing problems are quite common and I have no clue how to avoid them. Keyboard should do nothing. Cheers, -- Pavel 2014-06-03 12:34 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Very cool. I just tested it on Mac OS X 10.9.3 and I get a little blue box > that I can drag around. The background is at the beginning white and there > are blue artifacts leftover, but after I resize the window the background > gets green and there is no more blue artifacts left around. > > I did not manage to produce any effect with the keyboard. > > Cheers, > Doru > > > On Jun 3, 2014, at 12:07 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > > > Hi, > > > > I created a job that bootstraps MorphicCore - an image that contains > runable subset of Morphic that is able only to display a simple morph and > handle mouse and keyboard events on it. Please, try to test the image on > Mac. > > > > > https://ci.inria.fr/pharo/view/4.0-Bootstrap/job/Pharo-4.0-Bootstrap-Step-3… > > > > Cheers, > > -- Pavel > > -- > www.tudorgirba.com > > "Speaking louder won't make the point worthier." > > >

June 3, 2014

Re: [Pharo-dev] ConfigurationOfMorphicCore

by Tudor Girba

Very cool. I just tested it on Mac OS X 10.9.3 and I get a little blue box that I can drag around. The background is at the beginning white and there are blue artifacts leftover, but after I resize the window the background gets green and there is no more blue artifacts left around. I did not manage to produce any effect with the keyboard. Cheers, Doru On Jun 3, 2014, at 12:07 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > I created a job that bootstraps MorphicCore - an image that contains runable subset of Morphic that is able only to display a simple morph and handle mouse and keyboard events on it. Please, try to test the image on Mac. > > https://ci.inria.fr/pharo/view/4.0-Bootstrap/job/Pharo-4.0-Bootstrap-Step-3… > > Cheers, > -- Pavel -- www.tudorgirba.com "Speaking louder won't make the point worthier."

June 3, 2014

ConfigurationOfMorphicCore

by Pavel Krivanek

Hi, I created a job that bootstraps MorphicCore - an image that contains runable subset of Morphic that is able only to display a simple morph and handle mouse and keyboard events on it. Please, try to test the image on Mac. https://ci.inria.fr/pharo/view/4.0-Bootstrap/job/Pharo -4.0-Bootstrap-Step-3.0-ConfigurationOfMorphicCore/ Cheers, -- Pavel

June 3, 2014

Re: [Pharo-dev] GPU accelerated GUI

by Stephan Eggermont

On a late 2009 27" iMac (2.66 GHz i5), 10.9.3 Make the window full screen: 100.15 Full screen, no menu bar, dock: 71.27 While running a hangout session, and having about half a dozen other applications open. Is there buffering below this? Is there a difference when doing Display forceToScreen: rect; forceDisplayUpdate. Stephan

June 3, 2014

Re: [Pharo-dev] WhatsUp from: 2014-06-02 until: 2014-06-15

by stepharo

On 2/6/14 07:00, seaside(a)rmod.lille.inria.fr wrote: > Hi! We're sending this automatic email twice a month, to give the community an opportunity to easily know what's happening and to coordinate efforts. Just answer informally, and feel free to spawn discussions thereafter! > > ### Here's what I've been up to since the last WhatsUp: - Dropping my duties as number two of our research center :) - Negotiating to have esteban prolonged - Thinking about PharoPro - Working on laserGame book and other chapters for the next book > > ### What's next, until 2014-06-15 (*): > > - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION - working on String API analysis for ESUG paper - roadmaps about font cleaning - starting to integrate changes again (it feels good).

June 3, 2014

Re: [Pharo-dev] repackage morphic - introduction of morphic-widgets

by Pavel Krivanek

What about to have Morphic-Widgets-LazyLists for MulticolumnLazyListMorph and LazyListMorph? It looks more fitting than "Basic". Morphic-Widgets-Calendar would be better too because CalendarDayMorph and ChoseDate should be in the same package as CalendarMorph. Cheers, -- Pavel 2014-06-02 19:33 GMT+02:00 stepharo <stepharo(a)free.fr>: > Hi Pavel > > I'm about to perform the following > https://pharo.fogbugz.com/default.asp?11825 > > This is what we brainstormed when I visited you but I prefer to double > check. > > Morphic-Widgets-Basic > SimpleSwitchMorph > MulticolumnLazyListMorph > SimpleButtonMorph > LazyListMorph > IconicButton > ThreePhaseButtonMorph > CalendarMorph > Morphic-Widgets-Pluggable > PluggableTabButtonMorph > PluggableButtonMorph > PluggableTextMorph > PluggableMultiColumnListMorph > PluggableTextMorphWithLimits > PluggableTabBarMorph > PluggableListMorph > Morphic-Widgets-NewList > NewList > NewListRenderer > NewListAdapter > Morphic-Widgets-Tab > > Morphic-Widget-MorphTreeWidget > Morphic-Widget-MorphTreeWidget-Pagination > > I would promote Morphic-Base-ProgressBar -> Morphic-ProgressBar > >

June 3, 2014

Re: [Pharo-dev] introducing displayString

by Philippe Marschall

On 03.06.14 08:03, stepharo wrote: > hi guys > > I was reading a proposal that was sent to the list and I like it. > What do you think? > > Stef > > > > Hi Otto, > > Well, you asked for comments. This is my personal opinion, which varies > quite a bit from most implementations, since it's a bit 'old-school > Smalltalk'. But I think the scheme below does fairly neatly distinguish > the purposes of the various messages, which have gotten muddied over the > years as new developers use the language somewhat differently. But maybe > it was never the way I think I remember it being. :-) > > > #printString and #printOn: > These should answer a human-readable description of the receiver. The > description does not need to include the class name, though it can. All > objects should respond to these messages. Generally, #printString should > be implemented in terms of #printOn: -- if you're writing to a stream > you may not want to pay the cost of creating an extra string. > #printString is the equivalent of other languages' toString(). > > #asString > There should not be an Object>>asString. This message is *only* for > converting string-like things to actual strings. So it would be > implemented in String (to return self) and in Symbol, and *maybe* in > things like ByteArray (where it does not *describe* the byte array, but > answers a string whose characters have the values of the bytes). > > #storeString > Produces legal Smalltalk source code that when executed will produce an > equivalent object to the receiver. Needs to be implemented only for > objects that can be specified as literals in Smalltalk syntax, but could > probably be implemented for a few other simple objects. > > #displayString and so on. > UI frameworks and applications will need to have their own ways of > textually representing objects, so will add their own messages such as > #displayString. The *only* messages that any application or framework > can depend on *all* objects responding to are those that it defines > itself, and #printString and #printOn:. Sounds a lot like VW. I still remember the very complex rules we had in Seaside 2.x for when you should send #displayString, when #printString and when #asString. In the end we built #greaseString (#seasideString once) and everything became much simpler. Cheers Philippe

June 3, 2014

introducing displayString

by stepharo

hi guys I was reading a proposal that was sent to the list and I like it. What do you think? Stef Hi Otto, Well, you asked for comments. This is my personal opinion, which varies quite a bit from most implementations, since it's a bit 'old-school Smalltalk'. But I think the scheme below does fairly neatly distinguish the purposes of the various messages, which have gotten muddied over the years as new developers use the language somewhat differently. But maybe it was never the way I think I remember it being. :-) #printString and #printOn: These should answer a human-readable description of the receiver. The description does not need to include the class name, though it can. All objects should respond to these messages. Generally, #printString should be implemented in terms of #printOn: -- if you're writing to a stream you may not want to pay the cost of creating an extra string. #printString is the equivalent of other languages' toString(). #asString There should not be an Object>>asString. This message is *only* for converting string-like things to actual strings. So it would be implemented in String (to return self) and in Symbol, and *maybe* in things like ByteArray (where it does not *describe* the byte array, but answers a string whose characters have the values of the bytes). #storeString Produces legal Smalltalk source code that when executed will produce an equivalent object to the receiver. Needs to be implemented only for objects that can be specified as literals in Smalltalk syntax, but could probably be implemented for a few other simple objects. #displayString and so on. UI frameworks and applications will need to have their own ways of textually representing objects, so will add their own messages such as #displayString. The *only* messages that any application or framework can depend on *all* objects responding to are those that it defines itself, and #printString and #printOn:. Regards,

June 3, 2014

Re: [Pharo-dev] Dangling process related with styling

by Sven Van Caekenberghe

Yeah, I see them regularly as well, it has been like that for quite some time... On 03 Jun 2014, at 01:19, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > While looking at the Process Monitor, from time to time I find > processes, apparently waiting on a Semaphore, related with the syling > of the Pharo UI (see attached picture). > > I'm killing those as I spot them, but I guess they shouldn't be there > in the first place. > > Is it a bug? > > Esteban A. Maringolo > <pharo-procs.png>

June 3, 2014

Re: [Pharo-dev] GPU accelerated GUI

by Darrin Massena

I'm learning and would love to hear ideas about how best to benchmark Smalltalk rendering. I tried this very crude test in a Workspace: loops := 100. rect := Display boundingBox. a := Time millisecondsToRun: [ loops timesRepeat: [ Display forceToScreen: rect. ]. ]. Transcript show: a / loops asFloat; cr. With a full-screen window on a current model Mac Pro with stock Pharo 3 image and VM it reports 47 ms/update. On my Surface Pro 2 (Windows 8) it is takes only 1.1 ms. I'm kind of shocked by that number in comparison. It's a lower resolution screen but still. I know full screen updates are not the norm for many applications but they're still very important. Also keep in mind this is just the low level screen update, no Morphic overhead. Ideally the display update takes less than a millisecond to leave time for all the higher level rendering. For performance assessment I'd like to have a nice Frames Per Second graph running in the corner as well as repeatable test cases matching common uses (scrolling, full updates, partial updates, empty window, densely packed grid, text editor, etc) that could be run across platforms. After that I wonder about profiling. Can accurate timed traces be done from top to bottom? I imagine it would at least get murky at the VM boundary. I also noticed logic to limit display updates to 50 times a second, presumably to minimize CPU usage. CPU usage would also be reduced by optimizing rendering but in any case I'd like to see an update rate synchronized with the video rate or faster (60 or more). That would minimize tearing and allow for no perceivable UI lag. On Mon, Jun 2, 2014 at 3:48 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2014-06-02 16:51 GMT-03:00 stepharo <stepharo(a)free.fr>: > > It depends what you measure. > > If you measure classBrowser opening then nautilus is slower because it is > > doing more stuff. > > If adding more features degrades performance in a human perceivable > way then it's slowing down. (I mean, if slowdown is linear as extra > features are added). The trade-offs might be worth it (as indeed they > are). > > > So if you really want to help > > make a benchmark showing the difference between 1.4 and 3.0 on a > > **concrete** case. Without that we cannot make progress. > > Fair enough. I'll do so :) > Next time I won't say it feels slower (but not slow) until I get an > appropriate benchmark. > > Regards, > > -- > Esteban. > >

June 3, 2014