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

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

Re: [Pharo-dev] [OT] Swift - Apple Developer

by Yuriy Tymchuk

Maybe they donât have a standalone thing like âxâ : y, and so array-like definition with colons becomes a dict Uko On 03 Jun 2014, at 03:22, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > So Apple has a new language > > https://developer.apple.com/swift/ > > which is quite interesting since it works on top of their Objective-C runtime, which is pretty similar to what we are used to. There is of course lots of syntactic sugar to make things look easy, and more typing. > > I am still digesting it, but one thing that I wonder is how they implement the literal syntax for simple collections: > > [ 1, 2, 3 ] for an Array > > and > > [ "x" : 1, "y" : 2 ] for a Dictionary > > how do they differentiate between the two ? > > Maybe if we knew, it could be a solution to our 'missing' dictionary literals. > > Sven > > > >

June 3, 2014

Re: [Pharo-dev] Rebound Home and End keys are non-functional on Mac

by Darrin Massena

You're welcome. I'm new to Smalltalk so I'm glad it wasn't very difficult. On Mon, Jun 2, 2014 at 12:59 PM, stepharo <stepharo(a)free.fr> wrote: > Thanks a lot. > Esteban is travelling/on holiday so he will check that soon I imagine. > > Stef > > > On 1/6/14 23:38, darrinm wrote: > >> https://pharo.fogbugz.com/f/cases/13292/Rebound-Home-and- >> End-keys-non-functional-on-Mac >> >> Rebound Home and End keys don't work on Macs except when used in >> conjunction >> with the Command key. >> >> Fortunately the VM already has code to handle rebound keys and is just >> missing entries for moveToBeginningOfLine and moveToEndOfLine, which the >> Home/End keys are commonly rebound to. >> >> I've added those entries with this pull request: >> https://github.com/pharo-project/pharo-vm/pull/49 >> >> >> >> -- >> View this message in context: http://forum.world.st/Rebound- >> Home-and-End-keys-are-non-functional-on-Mac-tp4761220.html >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >> >> >> > >

June 3, 2014

Dangling process related with styling

by Esteban A. Maringolo

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

June 2, 2014