Find Source code Line Numbers of Methods at Runtime 11:18 PM

Comparing a source file and a runtime equivalent object of the class, here is a ten liner groovy script that determines the line numbers of every method inside a class. A plausible approach to do this in java is is to throw a stacktrace explicitly wherever needed and examine it to determine the line number at the point of execution. This I find is too clumsy a way. One can also take an other approach by parsing the source code file, creating a tree node structure and manipulate it but then the problem with this approach is that one has to reinvent the whole wheel again.

Groovy's dynamism comes to rescue here exposing the runtime object to the programmer during execution. At runtime, one can inspect an object, study its methods and properties and manipulate them as per the need. This can also be done in java using the Reflection API but I find it too monstrous and verbose. I resort to groovy instead. Here's the ten liner script for the same.

//supply the source file path, the only input to the script
def sourceFilePath = 'C:\\Temp\\GroovyUtils\\Sample.groovy'

//a map that stores method names vs line numbers as key val pairs
def methodToLineMap = [:]

//find all the methods of the Sample class and assign default line number as 0 first.
def listOfMethods = new Sample().metaClass.methods*
listOfMethods .name.sort().unique().each{
    methodToLineMap.put(it,0)
}


//parse src file to find the line numbers of methods & store line number in the methodMap
def idx = 0
new File(sourceFilePath).eachLine{ line ->
    idx++
    methodToLineMap.keySet().each{method ->
        if(line.contains(method)){
            methodToLineMap[method] = idx
        }
    }
}

//print the elements of method vs line number map
methodToLineMap.each{
    if(it.value!=0)
        println it
}
PS : You can also supply a java source code file (in sourceFilePath) to find out the line numbers of the java class's methods but ensure that the .class file is on the classpath while running the script.

Tweet

Windows 8 - (Dev Build) Review So Far 9:45 AM

I just experienced Windows 8, a leaked version from the dev build beta archives, on my friend's laptop. If there is one adjective to describe it, I'd go for the word "different". I personally felt that the tablet-ish aspect of its UI certainly looks elegant with all the native MS-zune like Metro-style interface but I am afraid that it would certainly compromise the desktop experience. A scroll though between panels is obviously easier on a tablet because of the touch. On the contrary I find it a pain in the butt to move my mouse to the tiny scroll bar below to navigate between the home panels. The tablet targeted applications provided by default are brilliant, like the RSS/News feed reader, Picstream, Paintplay, etc.
Users are likely to face hassles until they get used to it. First and foremost of all, as you login to the system you are not directed to a desktop screen, instead you are directed onto a tablet like home screen. 

To see the Windows 7 like desktop, you need to select the desktop launcher from the home screen. When an application or external software is installed, instead of the shortcut being dropped onto the desktop, a similar such launch icon will be dropped onto the panels. Of course you can manually drop the shortcut onto the desktop too. Secondly, there is not even a slightest trace of the conventional "All Programs" type start menu within the desktop. So if you heavily rely on the Start menu - mouse click way of launching your applications, well, you might hate Windows 8. But good news for the keyboard freaks who rarely use the mouse to launch apps. Windows 7 start menu search is extended further to make it look the unity panel of Ubuntu 11.04 and above. So applications can be launched easily by hitting the windows key and typing in the name of the app to be launched.

Some other changes in the UI include addition of an abnormally huge toolbar (as in MS office apps) in the FIle Explorer. Windows task manager has changed, looks good but again, it is not too intuitive to a conventional Windows User in its first sight. Some other minor changes in alerts are also evident. 

As of now, I am ignorant of the intricacies of this version of Windows OS, but from an eagle eye's perspective, the speed and performance seem descent enough, just like its predecessor. Nevertheless, I wouldn't go too far exaggerating that Windows 8 is immaculate because it isn't. I am not as thrilled as I was when I experienced Windows 7 for the first time. It is too good in some aspects and atrocious in some other. I hope the annoying aspects of it are answered in the coming build versions. So to wrap it up, I stick to the word, different. Yes!, Windows 8 is different, a lot different and it has changed from its former versions. It depends on how the users tune themselves with this change. 

Tweet

Why Android Sucks? Why iOS is better? 4:55 AM

Prior to the reasons I depict to prove a point here, I would want to confess that neither do I blindly follow the cult of apple nor do I hate android based on sheer ignorance. The musings I share here are out of daily observances, experiences and a little bit of drilling into the technical aspects of Android as an OS and more.

I have been a heavy user of android on my HTC wildfire for a while. I find that Android does do what a smartphone ought to do but it doesn't do it with elegance. There are way too many shortcomings and glitches buried down deep into the sheath of the Android eco-system. On the contrary my experience with apple iOS has been limited only to iPod but I must admit the immense pleasure that it gives me and about how it provokes me to lay my hands on it again and again unlike my HTC Android that makes me moan about why I even considered buying it in the first place.

Initially, I was under the presumption that support for multiple hardware was cool but what I eventually realized after drilling in to details is that support for multi-hardware comes at a cost. If I were to design a gallery app for an android mobile or a tablet, I need to ponder over how to get the rendering right on different hardware at different resolutions. This is one reason why many apps on android are not compatible with all kinds of hardware. Take angry birds for instance, it doesn't run on all mobiles and tablets as it ought to. This is annoying both to the developer and to the user as well. On the contrary, within the apple world, all these complexities boil down to a simple fact that I am designing an app for a single target hardware that only runs at a given resolution(s). Because of this streamlined atmosphere to code, my psyche as a developer will subconsciously adhere to deliver THE BEST app for a single hardware rather than delivering a DECENT app that supports all hardware in the world.

Another interesting observation, Every new release of Android version makes me realize how crappy its predecessor is. On the other hand, every new release of iOS would make me realize how awesome the newer version is. There is a wide difference between the two in spite of seeming same. The focus on developing a newer version of Android is more towards rectifying the bad things in the current version and making it better in the newer version. In the iOS scenario, the focus of developing a newer version is to rope in newer features that never existed before. For example : It has been around eight months since I had bought a HTC wildfire running Froyo Android 2.2. Looking at the newer ice cream sandwich version, I whine about how atrocious Froyo is in its speed and performance compared to the latter and how good the newer version of HTC wildfire IS. Whereas if I had bought an iphone 4, probably the only thing that I would be whining about is that I do not get to use the SIRI but I would never be whining about its performance in what it delivers to me as a smartphone. So the key point that I would want to highlight here is that newer versions of Android or its supporting hardware would seem awesome only because the former versions were bad whereas newer versions of iOS and hardware would seem awesome because of their added innovation into every new release or update.

On an other note, the power of a smartphone would be realized to a maximum extent by the apps that run on it. As far as I know, Android is probably the first and foremost entity that can be credited for indirectly being responsible for the injection of infectious malware at a tangible level on a Linux based system. I mean, though not impossible to do it, a Linux core by default is highly resilient to such stuff and with all the malware and antivirus crap that are evidently used in the Android world could only mean one among these two things. Either Android could not exploit the strengths of a Linux core or the hacker/developer is way too smart, which I think the case is certainly the former.

Adding to that, it is way too easy to develop an app consisting of malware and releasing it into the Android market. Of course, Google continuously scrutinizes the apps submitted but that is not just good enough to prevent the damage. Forget malware, Nothing really stops me from writing an untested low quality lameass hello world android app and release it into the market whereas if I were to develop an app for iphone/ipad, I need to ensure that it is thoroughly tested and it literally takes 3 to 4 weeks for iStore to approve the app after submission. This is an example that depicts the spirit of apple, precisely the spirit of Steve Jobs to give the deepest attention to minutest of detail to develop something impeccably tangible.

A recent article on Google+ posted by Dianne Hackborne, an Android developer at Google, throws light, complaining the inefficiency relating to the Android's methodology of hardware acceleration to render graphics. Reading the article one would be convinced that Android fares well only under the availability of considerably high end hardware. One doesn't have to go all technical to comprehend the disabilities of Android. Pick up a HTC or Samsung smartphone, open up around 10 applications one after the other, the performance of the 11th or 12th application that you open up will certainly not be as smooth as the first few. Typically iOS does this task brilliantly. No matter what, most of the RAM will be used only by the opened/active process in the Apple tablet or mobile. Only one application can run at a time on the screen which gives a tremendous performance hit. Android does a similar job in a crooked way, somehow temporarily suspending the inactive process but that doesn't restrict an inactive app running in the background eating away my puny little RAM. For this reason, I even see task managers and process killing apps on Android. Geez! For Christ's sake, I am running a phone, not a super computer! Yet again, Apple proves its best in technical brilliance without compromising performance. With all the brouhaha that surrounds the Galaxy tab's 1 GB RAM and hardware excellence, I wonder if the users of the tab did ever make it a point to notice how iPad 2 does all this process magnificently better than the former within a bare minimum of 512 MB RAM.

From a techie's viewpoint, though the core of Android is written in C and C++, all the APIs and applications that surround it are built on java. There is all this dinosaur conversion of bytecode in dalvik's understandable dex format and other humongous stuff which certainly can never beat the iOS's simplistic approach of limiting all complexities to a mutually compatible C, C++ and Objective C. Anything that involves java usually sucks blood in performance. No matter how awesome the Samsung's hardware is, god knows how many hundreds and thousands of method calls are gone through in java to understand and process the multi-touch event. And again, one doesn't have to drill through all the technical crap to understand the complexities and disabilities of Android. Go ahead, Take a delicate bird feather and compare the touch sensitivity of an iPhone vs an Android phone or an iPad vs any other cog-in-the-wheel tablet you know of, You will get a hang of what I am trying to convey here.

In spite of all its internal flaws, more and more newer and better versions of Android may come up in the near future but it all accounts to mere band-aiding. What's the point? You got your basement built on wooden sticks and lay concrete pillars on your higher floors! Technically, an Android can never beat the brilliance of an iOS in its flawless design and architecture (both hardware and software). Who cares about the numbers in market? After all, it is okay for Galaxy tabs and the rest to be content about being second runners but in reality Apple is running a different race altogether.


EDIT: This post was written when Android devices were running 2.2/2.3. With the advent of ICS, things seem to have changed where in a lot of changes have been made to the Android code base (some portion completely re acrchitectured from scratch) to make it scalable on tablet devices. Also to admit, Off late Apple is just not able to pull out something innovative. Android is certainly moving up the ladder with almost 50% of tablet market conquered. Looking at the circumstances, Android is a clear winner especially when it comes to appealing to the eyes of a user.

PS: As I have quoted before, I am not an Apple fanboy. I am a technical person and I tried to throw some light on fineness of iOS as a whole when compared to Android. I never intended to compare the complete eco system of Android devices and Apple devices. In fact, to be honest, I'd never ever dream of buying an iPad over an Android tablet, for I know it is just a toy, completely ungeek and strict in user customization despite its flawless OS.

Tweet

Running Cobertura as Ant Script 7:18 AM

I posted about configuring eCobertura plugin for eclipse in the previous blog post. In this post, I will describe the bare minimum steps to run Cobertura as an ant build script from eclipse. Cobertura unlike eCobertura plugin, provides advanced code coverage reporting in xml and html formats. This is much more flexible for custom configuration as it can be controlled via the ant script. Replicate the steps below :

1) Download cobertura zip.

2) Create a java/groovy project named "Sample" in eclipse.

3) Create a simple java/groovy class and a corresponding unit testcase class to test it.. Place them in seperate or same packages as you wish.

4) Create a folder called lib under the Sample project folder (as Sample/lib).. Place junit.jar, apache ant.jar, and all the jars in the downloaded Cobertura zip (most importantly cobertura.jar) into the lib folder and include the jars in the project's classpath.

5) From the downloaded Cobertura zip, pick up the two files build.properties and build.xml and place them in your Sample project base. (as Sample/build.xml and Sample.build.properties)

6) The build.xml is the ant script to run Cobertura and it uses the configuration in build.properties file.

7) Change the contents of build.properties as shown below:

build.properties
---------------------------------------------------------------------------------------------------------------------

# The source code for the examples can be found in this directory
src.dir=src

# The path to cobertura.jar
cobertura.dir=cobertura/complete

# Classes generated by the javac compiler are deposited in this directory
classes.dir=cobertura/complete/classes  

# Instrumented classes are deposited into this directory
instrumented.dir=cobertura/complete/instrumented

# All reports go into this directory

reports.dir=cobertura/complete/reports    


# Unit test reports from JUnit are deposited into this directory                          
reports.xml.dir=${reports.dir}/junit-xml       
reports.html.dir=${reports.dir}/junit-html       

# Coverage reports are deposited into these directories
coverage.xml.dir=${reports.dir}/cobertura-xml 
coverage.summaryxml.dir=${reports.dir}/cobertura-summary-xml
coverage.html.dir=${reports.dir}/cobertura-html

---------------------------------------------------------------------------------------------------------------------


8) Now change the contents of build.xml as shown below:


build.xml 

---------------------------------------------------------------------------------------------------------------------

<?xml version="1.0" encoding="UTF-8"?>

<project name="Sample" default="coverage" basedir=".">

 <description>
    Cobertura - http://cobertura.sourceforge.net/
    Copyright (C) 2003 jcoverage ltd.
    Copyright (C) 2005 Mark Doliner &lt;thekingant@users.sourceforge.net&gt;
    Copyright (C) 2006 Dan Godfrey
    Cobertura is licensed under the GNU General Public License
    Cobertura comes with ABSOLUTELY NO WARRANTY
    </description>

 <property file="build.properties" />

 <path id="cobertura.classpath">
      <fileset dir="lib">
           <include name="*.jar"/>
       </fileset>
 </path>

 <taskdef classpathref="cobertura.classpath" resource="tasks.properties"/>
 <target name="init"> 
  <mkdir dir="${classes.dir}" />
  <mkdir dir="${instrumented.dir}" />
  <mkdir dir="${reports.xml.dir}" />
  <mkdir dir="${reports.html.dir}" />
  <mkdir dir="${coverage.xml.dir}" />
  <mkdir dir="${coverage.summaryxml.dir}" />
  <mkdir dir="${coverage.html.dir}" />
 </target>



 <target name="compile" depends="init">
  <javac srcdir="${src.dir}" destdir="${classes.dir}" debug="yes">
   <classpath refid="cobertura.classpath" />
  </javac>
 </target>

 <target name="instrument" depends="init,compile">
  <!--
   Remove the coverage data file and any old instrumentation.
  -->
  <delete file="cobertura.ser"/>
  <delete dir="${instrumented.dir}" />
  <!--
   Instrument the application classes, writing the
   instrumented classes into ${build.instrumented.dir}.
  -->
  <cobertura-instrument todir="${instrumented.dir}">
   <!--
    The following line causes instrument to ignore any
    source line containing a reference to log4j, for the
    purposes of coverage reporting.
   -->

   <ignore regex="org.apache.log4j.*" />
   <fileset dir="${classes.dir}">
    <!--
     Instrument all the application classes, but
     don't instrument the test classes.
    -->
    <include name="**/*.class" />
    <exclude name="**/*Test.class" />
   </fileset>
  </cobertura-instrument>
 </target>

 <target name="test" depends="init,compile">
  <junit fork="yes" dir="${basedir}" failureProperty="test.failed">
   <!--
    Note the classpath order: instrumented classes are before the
    original (uninstrumented) classes.  This is important.
   -->
   <classpath location="${instrumented.dir}" />
   <classpath location="${classes.dir}" />
   <!--
    The instrumented classes reference classes used by the
    Cobertura runtime, so Cobertura and its dependencies
    must be on your classpath.
   -->
   <classpath refid="cobertura.classpath" />
   <formatter type="xml" />
   <test name="${testcase}" todir="${reports.xml.dir}" if="testcase" />
   <batchtest todir="${reports.xml.dir}" unless="testcase">
    <fileset dir="${src.dir}">
     <include name="**/*Test.java" />
    </fileset>
   </batchtest>
  </junit>



  <junitreport todir="${reports.xml.dir}">

   <fileset dir="${reports.xml.dir}">

    <include name="TEST-*.xml" />

   </fileset>

   <report format="frames" todir="${reports.html.dir}" />

  </junitreport>

 </target>



 <target name="coverage-check">

  <cobertura-check branchrate="34" totallinerate="100" />

 </target>



 <target name="coverage-report">

  <!--

   Generate an XML file containing the coverage data using

   the "srcdir" attribute.

  -->

  <cobertura-report srcdir="${src.dir}" destdir="${coverage.xml.dir}" format="xml" />

 </target>



 <target name="summary-coverage-report">

  <!--

   Generate an summary XML file containing the coverage data using

   the "srcdir" attribute.

  -->

  <cobertura-report srcdir="${src.dir}" destdir="${coverage.summaryxml.dir}" format="summaryXml" />

 </target>



 <target name="alternate-coverage-report">

  <!--

   Generate a series of HTML files containing the coverage

   data in a user-readable form using nested source filesets.

  -->

  <cobertura-report destdir="${coverage.html.dir}">

   <fileset dir="${src.dir}">

    <include name="**/*.java"/>

    <include name="**/*.groovy"/>

   </fileset>

  </cobertura-report>

 </target>



 <target name="clean" description="Remove all files created by the build/test process.">

  <delete dir="${classes.dir}" />

  <delete dir="${instrumented.dir}" />

  <delete dir="${reports.dir}" />

  <delete file="cobertura.log" />

  <delete file="cobertura.ser" />

 </target>



 <target name="coverage" depends="compile,instrument,test,coverage-report,summary-coverage-report,alternate-coverage-report" description="Compile, instrument ourself, run the tests and generate JUnit and coverage reports."/>



</project>

---------------------------------------------------------------------------------------------------------------------

9) Running the above build.xml as an ant script in eclipse will create a folder hierarchy. The generated xml and html format reports can be found at Sample/cobertura/complete folder.

PS: Instead of running the script from eclipse you can also run the build.xml from a command line using the ant -[options] command.

Tweet

Eclipse : Configuring eCobetura for Code Coverage 11:11 PM

Recently, I stumbled across cobertura while searching for a decent code coverage utility for my java and groovy units. Major parts of Cobertura are under the GNU public license which I found would suffice my need for basic code coverage. You can read more about cobertura here at http://cobertura.sourceforge.net/

eCobetura is a comfy eclipse plugin that generates a code coverage report within the eclipse console itself..Here is how you can configure it.

Eclipse update site for eCobertura

http://ecobertura.johoop.de/update/

In eclipse, Under Help menu -> Install New software, add up the above (url) update site..

Check eCoberture code coverage option and proceed with Next until all the dependencies get installed..

Restart eclipse after installing the eCobertura plugin..

Sample unit test code coverage using eCobertura
Create a sample Java/Groovy project.

Create a java/groovy class PrintUtil

public class PrintUtil {                        
public String printHello(String msg){      
return "Hello "+msg;                    
}                                          

public String printGoodday(String msg){    
return "Good day "+msg;                 
}                                          
}                                               

Likewise create a JUnit/Gunit testcase class that will test the functionality of PrintUtil class.

import junit.framework.TestCase;                
public class PrintUtilTest extends TestCase {   
PrintUtil util = new PrintUtil();           
public void testPrintHello(){               
String out = util.printHello("World");  
assert(out=="Hello World");             
}                                           

public void testPrintGoodday(){             
String out = util.printGoodday("World");
assert(out=="Hello World");             
}                                           
}                                               

In eclipse, Under Window menu -> Show View -> Other, Select the Coverage Session View option to view the eclipse console for the code coverage results of the above unit test..

Select the PrintUtilTest testcase in the eclipse package explorer, Find the new shorcut for eCobertura in the eclipse toolbar (probably just best the debug menu icon).. Execute the PrintUtilTest as a junit under the Coverage As -> JUnit Test option.. The complete code coverage details will be shown in the Coverage Session View similar to the one shown below..

PS: This post focuses only about eCobertura, an eclipse plugin for Cobertura which can be used in tandom while running junits in eclipse.. However the original, Cobertura has more advanced features to generate a complete XML/ HTML reports on code coverage, etc..It can be run from command line or as an ant or Maven build.. You might want to exploit it for advanced reporting options.. 

Tweet

Pharo Beginner : My first Smalltalk Program 11:06 AM

DockingBarMorph new
  position: 0@225;

        addMorph: (SimpleButtonMorph new
                          label: 'Close';
                          target: [DockingBarMorph allInstances last delete];
     height: 55;
                          actionSelector: #value);

        addMorph: (SimpleButtonMorph new
            label: 'Open Transcript';
                          target: [Transcript open.
                                        Transcript show: '*** Default text in Transcript ***'
                                        ];
                          actionSelector: #value);

addMorph: (SimpleButtonMorph new
                        label: 'Open Browser';
     target: [Browser open.];
                        actionSelector:#value);

       addMorph: (SimpleButtonMorph new
                            label: 'New Workspace ';
                            target: [Workspace new open.];
                            actionSelector:#value);

addMorph: (SimpleButtonMorph new
                          label: 'Dock';
                          target: [UIManager inform: 'Hello world.. This is a sample Dock..'];
                         height: 55;
                          actionSelector: #value);
  openInWorld.

*************************
Tried to add up custom launchers for pharo development utilities. Currently implemented new Workspace open, System Browser, Transcript, etc.. Will have to make it complete so that the dock should be able to launch every component under the conventional right click popup in the pharo environment..

A simple pharo starter program which you can fiddle and extend, after a thorough understanding on ProfStef go.

Tweet

Tutorial : List Operations in Python 11:10 AM

#!usr/bin/python
""" All text within triple quotes is treated as comments in python """
""" This tutorial explains lists in python with the simplest operations as examples"""
""" Standard string concatenation using + operator """
""" Prints the message in a new line """
def printMessage(str):
print ">>>>> "+str
return


""" For loop : A similiar equivalent of each closure in groovy """
""" Note that indents are the only way to tell the interpreter about the blocks """
"""Also note that the below print it, prints elements in same line with space separated i.e a typical equivalent of System.out.print in java"""
def printList(aList):
for it in aList :
print it,
print
return



""" ********************** Start scripting : list operations ********************** """
list = [10, 1, 2, 3, 4, 5, 6]

"""*** Print the elements of the list *** """
list.append(9)
printMessage("Initial elements in the list : ")
printList(list)

"""*** add an element to the end of the list *** """
lastVal = 9
list.append(lastVal)
printMessage("Elements after appending a new element "+str(lastVal)+" at the end of the list : ")
printList(list)

"""*** insert element at index i *** """
insertVal = 8
indice = 7
list.insert(indice, insertVal)
printMessage("Elements after inserting : "+str(insertVal)+" at index : "+str(indice))
printList(list)

"""*** sort the elements ascending order by default *** """
list.sort()
printMessage("Elements after sort : ")
printList(list)

"""*** Reverse the elements : same as groovy *** """
list.reverse()
printMessage("Elements after reversal : ")
printList(list)

"""*** Removes the last element *** """
list.pop()
printMessage("Elements after removing last element : ")
printList(list)

"""*** Removes element at specified index *** """
index=3
list.pop(index)
"""Note the string cast below..A typical toString() equivalent in java"""
printMessage("Elements after removing element of index at : "+str(index))
printList(list)

"""*** Removes element with the value specified *** """
value=9
list.remove(value)
printMessage("Elements after removing the value : "+str(value))
printList(list)

""" *** number of times the element 1 occurs in a *** """
countFor = 1
printMessage("The number of times element : "+str(countFor)+" occurs in the list")
print list.count(countFor)

""" ****************** Some more looping and branch conditions ****************** """

""" *** Find the smallest element in the list using a typical for equivalent of eachWIthIndex groovy closure*** """
small = list[0]
smallestElementIndex = 0
for index, item in enumerate(list):
if item < small :
small = item
smallestElementIndex = index
print  "The smallest element of the list is "+str(small)+" at index "+str(smallestElementIndex)


""" *** While loop implementation *** """
printMessage("A simple while loop in python to convey : ")
sizeOfList = len(list)
i=0
while i<sizeOfList:
print "Python is fun \m/"
i = i + 1

--------------------------------------------------------------------------------------------------------------

Output for the above list operations performed :


>python -u "PythonBasicListOps.py"
>>>>> Initial elements in the list : 
10 1 2 3 4 5 6 9
>>>>> Elements after appending a new element 9 at the end of the list : 
10 1 2 3 4 5 6 9 9
>>>>> Elements after inserting : 8 at index : 7
10 1 2 3 4 5 6 8 9 9
>>>>> Elements after sort : 
1 2 3 4 5 6 8 9 9 10
>>>>> Elements after reversal : 
10 9 9 8 6 5 4 3 2 1
>>>>> Elements after removing last element : 
10 9 9 8 6 5 4 3 2
>>>>> Elements after removing element of index at : 3
10 9 9 6 5 4 3 2
>>>>> Elements after removing the value : 9
10 9 6 5 4 3 2
>>>>> The number of times element : 1 occurs in the list
0
The smallest element of the list is 2 at index 6
>>>>> A simple while loop in python to convey : 
Python is fun \m/
Python is fun \m/
Python is fun \m/
Python is fun \m/
Python is fun \m/
Python is fun \m/
Python is fun \m/
>Exit code: 0

Tweet