Reviving Pharo Morphic View

September 1, 2014

I repost, the updated core package for Pharo Morphic View. From the early Feb 2012 now refactored a bit for Pharo 3.0

Simple framework primarily hooked on with 3 classes and some minimal support classes. ( Most support classes are add ons for more complex capabilities )

To get started:

Browse to:  AbstractSimpleImplicitMorphicView  >> #test .

Run this in workspace:

| aView  informDialogBlock |
aView := AbstractSimpleImplicitMorphicView new windowTitle: ‘Test Morphic View’ ;  windowType: #Dialog . “Try also:  #Window and #Morph”

   “Map widgetName to its morphClass”
aView createMorphsSpecs: {
‘label1′ -> #LabelMorph.
‘text1′ -> #PluggableTextMorph.
‘button1′ -> #PluggableButtonMorph.

informDialogBlock := [ UIManager default inform: ‘Welcome to MorphicView Framework’ ].

“Map widgetName to creation method for model / handler etc..”
aView morphsPrimaryPropertiesSpecs: {
‘button1′ -> ( #on:getState:action:label:menu: -> { informDialogBlock . nil . #value . nil. nil } ).

“Map widgetName to other properties / method to arguments”
aView morphsSecondaryPropertiesSpecs: {
‘label1′ -> { #contents: -> { ‘Have Fun With Morphs:’ }. #vResizing: -> { #rigid }. #extent: -> { 400@30}.   }.
‘button1′ -> { #hResizing: -> { #rigid }. #vResizing: -> { #rigid }. #extent: -> { 400@30}.  #label: -> { ‘Button B’ } }.
‘text1′ -> {  #setText: -> {  ‘\\    Write out a short essay below:..! ‘ withCRs } }.
aView open.


Now browse through the Tests / Examples for Specs based construction with subclassing either:

* AbstractMorphicView( abstract class for view composition. )


* AbstractSimpleMorphicView  ( simplified api  to provide for TableLayout aka a flow layout…)

implement the above message calls as unary methods in the subclass, with the argument from above as the return values..

#createMorphsSpecs          #morphsPrimaryPropertiesSpec            #morphsSecondaryPropertiesSpec

There are additional API/ initialize routines to leverage in the subclassed construction to make it lot more flexible and scalable.

Potentially there is no limits in components based construction of the UI, with all smaller UIs composing any nth level of complex UI


Lot more details are available with pdf / other information posted in early 2012 when this was developed and remained in hibernation.

A full scale MVC mode application can be developed with this framework. The advanced part is to follow through with refactoring for Pharo 3.0 due..


PS: Tests works fine except for LanguageTranslator.. which needs a minor refactoring, I will work through on shortly.

Will rethink on the framework though a fresh pair of eyes to make it easier, capable, scalable and easily debuggable as well as make it amenable for a simple drag n drop UI builder. The other target is if we can do a web app UI construction with the same spec..? Seems unlikely in short time but need to think.





Teapot: Pharo web REST framework, it ain’t micro

August 28, 2014

Diving mostly into Java these days, it was just sheer bliss to attempt to cook up a sample app with a new framework in Pharo: Teapot. Extend it do a flexible simple app workout.!/~zeroflag/Teapot

It is really elegant, what REST does and what Pharo can do with REST, that Teapot amplifies. Really elegant in its code too, the framework brings forth all that is cool about dynamic programming in Smalltalk

The link above  leads one through a 5 min intro / dive into a working set of examples of the framework. I delved for a couple of hours to create a more dynamic example classes that leads me through:

The MCZ:  Teapot-Examples

* Just subclass TeapotRequestHandler and you have now a GET/ PUT/DELETE default for the new class with its appName as the URL path viz:


     ( The ‘NewSubClassAppName’ is default if it is the sub class name given..else assign a name to #appName in the initialize method )

* Override the #forwardTokenA: request method and you are quickly off the block to custom respond to the request. There on, you can follow the example in TeapotLibrary to forward additional tokens of the url to make it return data as reqd.

* The beauty is that in Pharo, now you can change anything, the appName / the response data / any or all of  the URL paths et al in the methods of the new subclass.

* The tests from the browser or using ZnEasy ( as in #sampleGetRequest: ) is instantaneous. None of the edit, compile, restart webserver stuff here..

* This also provides flexibility in scaling dynamically to as many landing URL paths as needed with just a simple discovery of subclasses runtime

From the drudgery of eclipse and its stack to Pharo and its frameworks, Zn / Teapot et als, its sheer bliss.

To try out the examples:

* Load the mcz  and  in a workspace execute:

Teapot stopAll .
teapot := Teapot configure: {
                                     #defaultOutput -> #json. #port -> 8080. #debugMode -> true }.
teapotEx2 := TeapotRequestHandler new initialize.
teapotEx2 runApp: teapot.

*  For quick test run the samples in TeapotLibrary and TeapotSync >> #sampleGetRequest:   highlight and execute the comment lines

*  The inspector that pops up, shows the various test urls configured, and its 200 success code  return object. The urls can be tried out in the web browser  viz:

http://localhost:8080/Library/books/1  http://localhost:8080/Library/search/author/skr  ; http://localhost/SyndLoans/FAC/12HJ3456 etc..


The cool dark theme in Pharo is nice on the eye with its contrast too: bit of Indian Flag look with text in white, orange and green along with the soft grey-blue.. nice on the eye.. yellow highlight on the edge.. !


PS: The Debugger though is cause for concern, it does not align at all with the line highlighted, in Pharo3.0

Nashorn Bug..

June 18, 2014


Excited as anyone would be of a newer, performant, cleaner engine Nashorn was something to look forward. Nice to play with moving on from Rhino. But one bug that is annoying and would love to get a fix for fast is its handling of large hierarchy of classes / or large number of methods in the Java class a script calls into. A hack works.. but need better way forward / affirmation on this..

“Step two translates the AST/IR into byte code via the ASM library. ASM emits the actual byte codes to form a script class”



          new MyClass().invokeAnyMethod()  // method on its super class

In this the MySuperClass has invokeAnyMethod() defined viz: MySuperClass should be having a hierarchy of classes that put together have say 6000+ methods.  (The #invokeAnyMethod() then has statements that invokes a method(s) on its super classes, a simple method that returns “hello world” or simple calc on its immediate attributes does not suffice )

In the

JavaAdapterBytecodeGenerator.<init> ( constructor ) .. it does the following:

     gatherMethods(superClass); // this reaps all the methods of the super class MySuperClass of 6000+ methods..



     generateConstructors(); which in turn invokes the following:


private void generateOverridingConstructor(final Constructor<?> ctor, final boolean fromFunction) {

… //this has a loop through all the methods gathered..

for (final MethodInfo mi : methodInfos) {

… which goes on to emit the code bytecodes for the firstMethod of the ClassWriter ( cw ) property

with iteration over 6000+ methods it easily exceeds the 64K bytecode limit of JDK VM method byte code size..

which then gloriously fails as:


java.lang.RuntimeException: Method code too large!



           at jdk.nashorn.internal.runtime.linker.JavaAdapterBytecodeGenerator.createAdapterClassLoader(

*******  Hack in at :

public static TypeBasedGuardingDynamicLinker getLinkerForClass(Class<?> clazz) {

   return linkers.get(clazz); // need to check on why NashornBeansLinker for specific cases..


// If it returns a NashornBeansLinker that then goes through the chain to dump the ClassWrter creates an issue, for simple methods it returns a BeanLinker and runs fine..  maybe nice to get a hang of it here..

private static GuardedInvocation getSamTypeConverter(final Class<?> sourceType, final Class<?> targetType) throws Exception {

// If source type is more generic than ScriptFunction class, we’ll need to use a guard

final boolean isSourceTypeGeneric = sourceType.isAssignableFrom(ScriptFunction.class); // make this false for such cases… and it works fine.. for the basic tests..


 * I have not as yet plumbed as much of the Nashorn logic in this.. why dig through and create a ClassWriter byte code cache (NashornAdaptor to the super class ) when it can probably make a proxy for the Java object and simply let the message be invoked as normal Java method and marshal the result back as per Nashorn semantics.. I am sure there are good reasons, need to plumb it thoroughly before I comprehend it..

*  Now the other concern is org.objectweb.asm.** is used in other packages viz: Groovy / Spring.. et als as  now will this create a conflict is also to be plumbed and ensure classpath loaders honor the segregation properly Groovy still uses a very old asm 4.0 jar.




Pharo is a Smalltalk dialect

April 29, 2014


“Invent the future” a resonating statement that we can only be inspired by. There are thousands of more ideas, works that continually inspires us all. Inspiration drives the creation of something new.  Pharo Smalltalk begins with something that existed, but is a new avatar and will probably head to be the best dialect of Smalltalk.

Pharo Smalltalk has begun to establish roots in the minds of so many more engineers/ developers and become more relevant for its use in enterprise application space. The inspiration for its changes from the base of Smalltalk emanate and will continue to be influenced from various sources. Smalltalk is not defined rigorously to be the one published and controlled by one corporation but by the tenets that have held sway and inspired a Java, Ruby and others in their development.

* Image based environment

* IDE, inspectors, debuggers and many other tools as part of its development environment

* Dynamic typed, garbage controlled

* Primarily single inheritance structure

* VM that is rooted in the Blue book, but evolved over time and will continue to evolve even further

* Meta programming capabilities

Many other features add unto the perception of Smalltalk in our mind, not the differences in:

* Morphic UI vs MVC UI or any others

* Platform independent or only single OS focussed ( viz: Dolphin / Smalltalk MT et als.. )

* Ideas and concepts viz: spoon, traits, scratch et als

* Git / SVN filtree rather than MC backed SCM

…… or any other minor changes…

Each dialect will spawn a host of new ideas and will enrich the Smalltalk community. Pharo Smalltalk does currently give a great thrust in that direction and it will be for the greater good to continue to do so say for next few years more before there is a feel that it has diverged far out of its Smalltalk origins to be labelled anything but Smalltalk in its heart and soul, wrapped as it may be that differently

The end goal should not drive an image campaign, the product should be built and shaped to be perfect and the ultimate tool for its use. People as they adopt will shape its image and perception to their benefit and its growth.

Like Steve Jobs,  focus in doing the best with the platform, contributing the best to the platform in whatever way it enables enterprise to adopt and use it forever with guarantees of:

* VM being absolutely rock stable, perfect in its execution of all operations

* Growing body of tools, capabilities, libraries et als

* Interoperability with what exists in simple and fail safe manner.

* Newer exciting projects that it spawns inspires others to try their works on it..

Much more that is already been done over the past 4 years and is expected ahead…

Relabelling Pharo Smalltalk to anything but as a dialect of Smalltalk, I believe is nothing short of denying its own origins for now. Let it mature and diverge enough to be relabelled.



Inspired by a blog from a much admirable Smalltalker:




Interesting Tech Reading List

April 25, 2014

Databases: NewSQL vs NoSQL vs OldSQL


including the comments

good start to concurrency is here:




Typically I would read through Caching and Transactions in conjunction with concurrency control to relook at an architecture / design of a system.

 Java EE 7 :

DZone RefCardz:

❱❱ API for WebSocket
❱❱ Batch Applications
❱❱ API for JSON Processing
❱❱ Concurrency Utilities
❱❱ JMS 2.0
❱❱ JSF 2.2…

Java 8:


Compatability Issues for Java 7 to Java 8 migration:



TDD And Unit Tests:



specially the summary resonates


specially MockFor and “as Class” class instance generation…





Pharo 2.0 Released

March 18, 2013

Post your comments…


On Mon, Mar 18, 2013 at 3:42 PM, Marcus Denker <> wrote:

We are proud to announce the release of Pharo 2.0!

You can find information about Pharo at:

About this release
All in all, there were over 1600 issues treated in the issue tracker
and 1350 improvements integrated into 2.0.

Major framework changes too:

- Spec
– Widget enhancements
– Layout improvements/cleanups
– Keybindings
– New icons (famfam)
– Growl style notifications
– Revamp progress bar

Developer tools

- Nautilus browser
– Critics browser
– Improved version diff browsing
– Spotlight
– Revamp Code Completion and smart chars
– Interactive navigation using ctrl/cmd+click over classes/methods
– Shout themes
– Andreas profiler


- Update Zinc
– Zodiac (SSL)


- System Announcer
– RPackage replacing PackageInfo
– Command line tools / Headless mode
– Native boost
– Update Ring metamodel
– Fuel serializer
– Freetype fonts


- DateAndTime refactoring
– Updated FileSystem and replaced FileDirectory


- Latests cog builds
– SSLPlugin
– FilePlugin enhancements
– SocketPlugin fixes
– Included libraries: freetype2, cairo


- FileDirectory removed (replaced by FileSystem)
– SmartRefStream and ReferenceStream removed (replaced by Fuel)
– PackageInfo deprecated (replaced by RPackage)


- Zeroconf scripts
– Continuous Integration for every aspect of our release process.


2013 – 2014 Smalltalk Looks up..

March 14, 2013

I guess through 2013 – 2014 we should have a cleaner, resurgent Smalltalk looking at through the clouds into many enterprise desks.

This is cool: bit heretic for the usual client side developer

Great Potential to on the client side.. Will try to have an internal server with some tangible utility stuff in it.

You can try out the browser built in. .. and the code for from Amber is also available as contributed package elsewhere..

Slow progress, but hopefully when it gets done..for v1.0 , probably mid of next year, it will be one great tool for Smalltalk on JVM


Lastly the creaking out of old and bring in the new:

The 2.0 breaks new grounds in a new , cleaner , freeware Smalltalk almost perfect for enterprise works. Guess 3.0 by next year will lop off the remaining rough edges too.


I will try and come out with in-works multi-world tablet IDE beta on top of 2.0 free time permitting…


This is close to what I will have, but cool in aesthetics and nice stuff built out of Pharo by I would say a non-core developer but a biologist..!






Get every new post delivered to your Inbox.