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.


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.internal.org.objectweb.asm.MethodWriter.getSize(MethodWriter.java:2065)

           at jdk.internal.org.objectweb.asm.ClassWriter.toByteArray(ClassWriter.java:837)

           at jdk.nashorn.internal.runtime.linker.JavaAdapterBytecodeGenerator.createAdapterClassLoader(JavaAdapterBytecodeGenerator.java:264)

*******  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 asm.xxx.jar  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

* http://cacm.acm.org/blogs/blog-cacm/109710-new-sql-an-alternative-to-nosql-and-old-sql-for-new-oltp-apps/fulltext

including the comments


good start to concurrency is here:

* http://www.agiledata.org/essays/concurrencyControl.html

* http://en.wikipedia.org/wiki/Concurrency_control

* http://en.wikipedia.org/wiki/Multiversion_concurrency_control

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:

* http://www.oracle.com/technetwork/java/javase/8-whats-new-2157071.html

Compatability Issues for Java 7 to Java 8 migration:

* http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html#A999387


TDD And Unit Tests:

* http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html

* http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf

specially the summary resonates

* http://blog.shinetech.com/2012/06/23/unit-testing-with-groovy/

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 <marcus.denker@inria.fr> wrote:

We are proud to announce the release of Pharo 2.0!

You can find information about Pharo at: http://www.pharo-project.org

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 https://developers.google.com/chart/interactive/docs/gallery 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..!






Pharo 2.0 Morphic View and TabbedPane IDE

February 26, 2013

Its been  a year since I have talked of this..

With Pharo 2.0 in imminent release status, I think its best to refactor the packages and make them available for all to try and use.

Just load two packages from : http://ss3.gemstone.com/ss/PharoInbox

* PharoMorphicView-Core

* PharoMorphicView-TabbedPane

On a workspace execute:

  PharoTabbedPaneIDE reinitializeAndOpen

For Pharo Morphic View: Ref



Also the PharoMorphicView-Core-Examples and Tests package to see all variations of the MorphicView framework.


Pharo TabbedPane IDE

Pharo TabbedPane IDE

Pharo Morphic View Example

Pharo Morphic View Example


Get every new post delivered to your Inbox.