- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] GPU accelerated GUI
by Stephan Eggermont June 3, 2014

June 3, 2014

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

1 0

WhatsUp from: 2014-06-02 until: 2014-06-15
by seaside＠rmod.lille.inria.fr June 3, 2014

June 3, 2014

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: - $HEROIC_ACHIEVEMENTS_OR_DISMAL_FAILURES_OR_SIMPLE_BORING_NECESSARY_TASKS ### What's next, until 2014-06-15 (*): - $NEXT_STEPS_TOWARDS_WORLD_DOMINATION (*) we'll be expecting results by then ;)

3 2

repackage morphic - introduction of morphic-widgets
by stepharo June 3, 2014

June 3, 2014

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

2 1

introducing displayString
by stepharo June 3, 2014

June 3, 2014

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,

2 1

Dangling process related with styling
by Esteban A. Maringolo June 3, 2014

June 3, 2014

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

2 1

[OT] Swift - Apple Developer
by Sven Van Caekenberghe June 3, 2014

June 3, 2014

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

2 1

Rebound Home and End keys are non-functional on Mac
by darrinm June 3, 2014

June 3, 2014

https://pharo.fogbugz.com/f/cases/13292/Rebound-Home-and-End-keys-non-funct… 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-t… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

3 2

[pharo-project/pharo-core]
by GitHub June 2, 2014

June 2, 2014

Branch: refs/tags/40012 Home: https://github.com/pharo-project/pharo-core

1 0

[pharo-project/pharo-core] 516c28: 40012
by GitHub June 2, 2014

June 2, 2014

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 516c28085be219cbf7ac535d92c49068e6e3e5fc https://github.com/pharo-project/pharo-core/commit/516c28085be219cbf7ac535d… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-06-02 (Mon, 02 Jun 2014) Changed paths: R Morphic-Core.package/Morph.class/instance/button/firedMouseUpCode.st R Morphic-Core.package/Morph.class/instance/debug and other/addMouseActionIndicatorsWidth_color_.st R Morphic-Core.package/Morph.class/instance/debug and other/addMouseUpAction.st R Morphic-Core.package/Morph.class/instance/debug and other/addMouseUpActionWith_.st R Morphic-Core.package/Morph.class/instance/debug and other/deleteAnyMouseActionIndicators.st R Morphic-Core.package/Morph.class/instance/debug and other/mouseUpCodeOrNil.st R Morphic-Core.package/Morph.class/instance/debug and other/programmedMouseDown_for_.st R Morphic-Core.package/Morph.class/instance/debug and other/programmedMouseEnter_for_.st R Morphic-Core.package/Morph.class/instance/debug and other/programmedMouseLeave_for_.st R Morphic-Core.package/Morph.class/instance/debug and other/programmedMouseUp_for_.st R Morphic-Core.package/Morph.class/instance/debug and other/removeMouseUpAction.st R Morphic-Core.package/Morph.class/instance/drawing/drawRolloverBorderOn_.st R Morphic-Core.package/Morph.class/instance/drop shadows/hasRolloverBorder.st R Morphic-Core.package/Morph.class/instance/drop shadows/hasRolloverBorder_.st M Morphic-Core.package/Morph.class/instance/menus/addMiscExtrasTo_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script12.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40012.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40012 12858 Remove hasRolloverBorder - Second part https://pharo.fogbugz.com/f/cases/12858 http://files.pharo.org/image/40/40012.zip

1 0

Re: [Pharo-dev] [Vm-dev] Rebound Home and End keys are non-functional on Mac
by Eliot Miranda June 2, 2014

June 2, 2014

Hi Darrin, thanks. On Sun, Jun 1, 2014 at 2:40 PM, Darrin Massena <darrin(a)massena.com> wrote: > > 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 > What's the easiest way to convert a pull request into either a) a diff which can be used with patch? b) a set of modified files? It would be great if there was a tool which avoided having to clone the repository, etc, etc, etc https://pharo.fogbugz.com/f/cases/13292/Rebound-Home-and-End-keys-non-funct… > -- best, Eliot

2 2