Monthly Archives: December 2011

ExperimentalBit

Last days I needed to migrate some old code I used to have in the VM for tracing objects usage. Luc Fabresse also wanted to be able to set and get the value of a bit in the object header to do some experiments. So…we thought it was a good idea to make it abstract and public. So….the following is only one morning work we did together with Luc, so don’t expect that much. What we did is to do a very small change in the VM to use one free bit in the object header, and then we coded 3 primitives: one to get the value, one to set it and one to unmark all objects. The idea is that you can use this code and give semantics to the bit. This is just for experimenting and prototypes, not for production code since such bit in the object header may not be available.
To download:

Gofer it
url: 'http://ss3.gemstone.com/ss/ExperimentalBit';
package: 'ConfigurationOfExperimentalBit';
load.
Now…. you can read ConfigurationOfExperimentalBit class comment:
———————

ExperimentalBit is a small facade for setting and getting the value of a bit in the Object Header. It requires a special VM which supports the primitives to set and get the value of such bit. You can get an already compiled MacOSX VM from: https://gforge.inria.fr/frs/download.php/30042/CogMTVM-ExperimentalBit.zip. For more details read class comment of ExperimentalBitHandler.

If you already have a compiled VM with the required primitives, then you can just load the image side part evaluating:

((Smalltalk at: #ConfigurationOfExperimentalBit) project version: ‘1.0’) load.

If you want to build a VM with the primitives we need, you need to download:

((Smalltalk at: #ConfigurationOfExperimentalBit) project version: ‘1.0’) load: ‘VMMakerGroup’.

And then follow the steps to build the VM:

http://code.google.com/p/cog/
http://code.google.com/p/cog/wiki/Guide

———————-

And here ExperimentalBitHandler class comment:

———————-

ExperimentalBitHandler is a small facade for setting and getting the value of a bit in the Object Header. It requires a special VM which supports the primitives to set and get the value of such bit. You can get an already compiled MacOSX VM from: https://gforge.inria.fr/frs/download.php/30042/CogMTVM-ExperimentalBit.zip.

To know which version of the VM you have to use to compile, check the dependencies in ConfigurationOfExperimentalBit and also the ‘description’ of it. For example, if version 1.0 it depends on ‘CogVM’ version ‘3.7’. In the description of version 1.0 you can also read that the used Git version of the platform code was 4a65655f0e419248d09a2502ea13b6e787992691 from the blessed repo.

Basically, there are 3 operations: set the bit to a specific, get the value of the bit and turn off the bit of all objects. Examples:

‘aString’ experimentalBit: true.
‘astring ‘ experimentalBit.
Date today experimentalBit: false.
Date today experimentalBit.
ExperimentalBitHandler turnOffExperimentalBitOfAllObjects.

For more details see ExperimentalBitTest.

——————–

Happy New Year to all Smalltalk hackers!!!


Pharo By Example in Spanish and PBE2 new chapters!

Hi. This is a short post in case someone has missed the info. The Pharo By Example’s spanish translation was finally done. Each of the 14 chapters were translated. Notice that even that, the translation is not 100% ready. It is a draft version and it still needs some passes along the whole book.  Anyway, the link is this: https://gforge.inria.fr/frs/download.php/28829/PBE1-Spanish-FullDraft-2011-08-01.zip

So, please distribute along spanish speaking smaltalkers.

For the translation, there are a lot of people to thank, there were like 15 translators. Special thanks to Gabriala Arevalo who start leading it, and then to Nicolas Paez that continues it.

Besides the translation, Pharo By Example 2 is in the way and there are drafts for already a lot of chapters:

That’s all, I hope you enjoy them.


Why Keymapping rocks?

Smalltalkers always claim that Smalltalk has invented the mouse and the User Interface. Even if that can be discussed, I have to say it: I HATE THE MOUSE. The less I can use it, the best. The more I can stay with the keyboard, the best. Besides I am Smalltalk lover, I always try to admit when Smalltalk is not the best in certain aspect. And at least in Pharo, the need of the mouse is too much.

I have worked in industry with Eclipse for 3 years. And I am a geek who stays hours in front of the PC and when I was in Linux/Windows I was using all the time Total Commander or something similar. I used to know all possible shortcuts of all the software I was using in my machine. When I then started to program in Squeak it has like if I come back 20 years in time. I was not able to use the keyboard as I was doing it in the rest of my machine (and Eclipse included). It felt really frustrating. But ok…Smalltalk showed me so many cool stuff that I could live with the lack of proper shortcuts.

Keymapping

Today, I can say Pharo has improved a little in the direction of improving the user experience with the keyboard.  This is thanks to Guillermo Pollito who has been developing Keymapping for a while. And now Débora Fortini has joined. Keymapping is a really small tool that let you define keyboard shortcuts per morph. So you can take any subclass of Morph and define your OWN shortcuts to do what you want. Of course, it may happen that there are conflicts with shortcuts of other morphs or even with global shortcuts of your Operating System. Nevertheless, the framework is there and working.

So….why keymapping rocks?  Well, during Smalltalks I say to Guillermo “If you give me shortcuts to step into, step over, restart, proceed, and go up and down in the Debugger, I pay you several beers”. After 5 minutes, they were already working perfectly. What was needed?  First just create the class:

Object subclass: #KMDebuggerShortcuts
instanceVariableNames: ''
classVariableNames: ''
poolDictionaries: ''
category: 'Keymapping-Debugger'

And then put a class side method :

buildDebuggerShortcutsOn: aBuilder
<keymap>
(aBuilder shortcut: #stackDown)
category: #DebuggerShortcuts
default: $d command shift, Character arrowDown
do: [ :target | target down ].
(aBuilder shortcut: #stackUp)
category: #DebuggerShortcuts
default: $d command shift, Character arrowUp
do: [ :target | target up ].
(aBuilder shortcut: #proceedDebugger)
category: #DebuggerShortcuts
default: $d command shift, $p
do: [ :target | target  proceed ].
(aBuilder shortcut: #restartDebugger)
category: #DebuggerShortcuts
default: $d command shift, $r
do: [ :target | target  restart ].
(aBuilder shortcut: #stepIntoDebugger)
category: #DebuggerShortcuts
default: $d command shift, $i
do: [ :target | target  send ].
(aBuilder shortcut: #stepOverDebugger)
category: #DebuggerShortcuts
default: $d command shift, $o
do: [ :target | target  doStep ].
(aBuilder shortcut: #stepIntoBlockDebugger)
category: #DebuggerShortcuts
default: $d command shift, $t
do: [ :target | target  stepIntoBlock ].
(aBuilder shortcut: #SeeFullStackDebugger)
category: #DebuggerShortcuts
default: $d command shift, $f
do: [ :target | target  fullStack ].
(aBuilder shortcut: #runHereDebugger)
category: #DebuggerShortcuts
default: $d command shift, $h
do: [ :target | target  runToSelection ].

All shortcuts are defined in the same way: you create a method which receives a builder. The method #shortcut receives a shortcut name and creates an instance of KMKeymapBuilder. Then, sending the message #category:default:do: to the created KMKeymapBuilder, you can define all shortcuts. The first parameter is a category. The second is the combination of keys for the shortcut and the last parameter is the block to evaluate when such shortcut is pressed. Notice that the block receives at least the target object. In this case the target is the debugger.

Now, the last part is to tell the Debugger that it should attach those shortcuts. To do that, we had to overwrite (for example) the method Debugger >> #openFullMorphicLabel:

openFullMorphicLabel: aLabelString
"Open a full morphic debugger with the given label"

| window |
window := UIManager default openDebugger: self fullMorphicLabel: aLabelString.
window attachKeymapCategory: #DebuggerShortcuts targetting: self.
^window

Notice in this method the line number 6. So…after 5 minutes that took Guille to code that, I had the shortcuts I ever wanted.

Available shortcuts

What is important of Keymapping is the infrastructure since it give us the tool to create our own shortcuts. Or even better, integrate in Pharo new shortcuts. Just to give you an idea, KMMonticelloShortcuts has shortcuts for committing, open repository, view changes, etc. KMGlobalShortcuts has shortcuts for saving the image, to open the world menu, to open a workspace, to open a transcript, to open Monticello, to open a class browser, etc… So…come on!!  what are you waiting to give it a try?

How to install it?  As easy as always:

Gofer new
squeaksource: 'ShortWays';
package: 'ConfigurationOfKeymapping';
load.

(ConfigurationOfKeymapping project version: #bleedingEdge) load

Notice that Keymapping has an integration with the Settings framework. So if you open the Setting Browser and go to the category “Keymapping” you will see some of the shortcuts and of course you will be able to modify them. Note that not all shortcuts are yet integrated to the Settings framework since Keymapping is still in development 🙂

What I would like in the future

  • The VM so far cannot handle some key events of certain keys like functions. Moreover, it seems (but I am not sure) that different VMs (the Windows VM, Linux, Mac OSX) do not handle all the key events the same way. It would be nice if they can be uniform.
  • In Pharo, when you do right-click or whatever menu that show you options like “do-it”, “print it”, etc., they all show the shortcut for them. However, if you do change them with KeyMappings, then such menu is not updated. It would be nice if the menu is auto-generated depending on the current configured shortcut.
  • It would be nice to have a way of tracking conflicts between shortcuts.