CSC/ECE 517 Fall 2010/ch1 S10 PH: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
 
(171 intermediate revisions by 2 users not shown)
Line 1: Line 1:
__TOC__
='''GUI Toolkits for Ruby'''=


=GUI Toolkits - Definition=
While starting to build a new desktop or commercial application, we all have to make a very important decision regarding which platform and [http://en.wikipedia.org/wiki/GUI_toolkit GUI toolkit] to use from a pool of so many available. In very simple words, a Graphical User Interface (GUI) toolkit is the set of [http://en.wikipedia.org/wiki/Application_programming_interface API's] (Application Programming Interface) that produces the graphical user interface your users will interact with. There are a number of factors to consider when choosing the toolkit which are discussed in the sections below. Different toolkit support different platforms (Linux, Windows, OSX) and have different features such as looks,accessibility and [http://en.wikipedia.org/wiki/Web_browser_engine layout engines](how it is rendered on a web browser).We will see all these considerations with respect to Ruby in more details in the sections below.


When starting to build a new desktop application, we all have to make a very important decision regarding which [http://en.wikipedia.org/wiki/GUI_toolkit GUI toolkit] to use from a pool of so many available. In very simple words, a Graphical User Interface (GUI) toolkit is the set of [http://en.wikipedia.org/wiki/Application_programming_interface API's] (Application Programming Interface) that produces the graphical user interface your users will interact with. There are a number of factors to consider when choosing the toolkit. Different toolkits support different platforms (Linux, Windows, OSX) and have different features such as accessibility, layout engines, and looks. We will see all these considerations with respect to Ruby in the sections below.
__TOC__


=Peek into the Ruby Language=


=GUI Toolkits for Ruby=
Ruby is an Object-Oriented Programming language. It serves as a very good platform to write low-level scripts for system administration tasks and for developing plain end-user applications rapidly. Using Ruby definitely avoids the time consuming 'code-compile-test' cycle which is normal in traditional programming.


Ruby is an Object-Oriented Programming language. Till very recently,its most usable implementation was an open source interpreter. The way Ruby was designed,Ruby did not have very interactive capability other than just accepting text inputs on a console. Basically any editor can be used to develop programs in Ruby. A thing to be noted is that the freshly installed Ruby interpreter is not integrated with any one development environment.
Despite all these characteristics, Ruby's most usable implementation was the open source interpreter till very recently. This was because the way Ruby was designed,Ruby did not have very interactive capability other than just accepting text inputs on a console. This would not have gone very far since it is very evident to everyone that  graphical user interfaces are a very important for modern end-user applications.As a result, at the onset of year 2009, Ruby was still not well known for being used for developing regular or commercial desktop applications. A possible reason was identified as a lack of good GUI-related libraries.
<br />
<br />


At the onset of year 2009, Ruby was not well known for being used for developing regular or commercial desktop applications. A possible reason was identified as a lack of good GUI-related libraries. Although, Tk, which is packaged in Ruby's standard library, can be used to develop desktop applications, it is considered disorganized and the API is considered to be from yesteryears.Things evolved and today we have the developments of number of third party libraries  like FxRuby,WxRuby,QtRuby,GTK-Ruby,Shoes and Swing which give Ruby graphical user interaction (GUI).These libraries give Ruby the user interface elements like text boxes to key in data, buttons to perform certain operation and window displays. More recent alternate implementations of Ruby have their own GUI facilities, such as Cocoa for MacRuby and Swing for JRuby. These toolkits are not really brand new but some like FxRuby, wxRuby, ruby-GNOME2 and RubyQt are simply wrappers for toolkits written in C or C++ .Shoes is a graphical library is implemented for Ruby alone.  
=Overview=
[http://www.ruby-lang.org/en/ Ruby] does have something that comes packaged with its standard library and enables users to develop GUI for desktop applications. This 'something' is called Tk. To use Tk for GUI development, you have to install Tk and its interface to connect with Ruby(Ruby binding). But the problem is that it is considered messy,ugly and the API is considered to be from yesteryears.With time,things evolved and today we have the developments of number of third party libraries  like FxRuby,WxRuby,QtRuby,GTK-Ruby,Shoes and Swing which give Ruby graphical user interaction (GUI).These libraries give Ruby the user interface elements like text boxes to key in data, buttons to perform certain operation and window displays. More recent alternate implementations of Ruby have their own GUI facilities, such as [http://en.wikipedia.org/wiki/JRuby Cocoa] for MacRuby and [http://en.wikipedia.org/wiki/Swing_(Java) Swing] for [http://en.wikipedia.org/wiki/JRuby JRuby]. These toolkits are not really brand new but some like FxRuby, wxRuby, ruby-GNOME2 and RubyQt are simply wrappers for toolkits written in [http://en.wikipedia.org/wiki/C_(programming_language) C] or [http://en.wikipedia.org/wiki/C%2B%2B C++]. Shoes is a graphical library is implemented for Ruby alone.


All the toolkits have some common features but they also differ in many aspects. There is no “best” toolkit in abstract terms.The usefulness of a library is only really tested by trying to use it to perform a specific task. Similarly, the toolkit shortcomings may only become apparent after a using it in substantial and a purposeful way.
All the toolkits have some common features but they also differ in many aspects. There is no “best” toolkit in abstract terms.The usefulness of a library is only really tested by trying to use it to perform a specific task. Similarly, the toolkit shortcomings may only become apparent after a using it in substantial and a purposeful way.


Developing a GUI library for Ruby is actually time-consuming. There are many reasons for this like, the large number of classes and methods often involved in the implementation; the need to employ lower-level compiled languages;cross-platform support;automated testing; highly variable paths through code; and the complexity of reconciling Ruby's GC-based memory management with that of the base language (often C or C++) in long-running applications.
Ruby's popularity has double folded in recent years.It remains a small language when compared to C, C++ and Java and hence it is an open question whether having a large number of libraries that more or less provide similar features is an optimal outcome.
<br />
<br />


Ruby's popularity has double folded in recent years.It remains a small language when compared to C, C++ and Java and hence tt is an open question whether having a large number of libraries that more or less provide similar features is an optimal outcome.
='''''Tk'''''=


= Selection Criteria of GUI toolkit=
The standard graphical user interface (GUI) for Ruby is Tk. It was initially developed for the Tcl scripting language by John Ousterhout. Tk is known for its [http://en.wikipedia.org/wiki/GUI_widget widgets] hierarchy. There's one root widget which can contain other widgets inside it.  Tk applications really do have a good look-and-feel.
* Ease of distributing applications
* Web-based documentation
Availability for relevant platforms
Maturity / stability
Appearance / aesthetics
Licence compatible with open source use
API programming style
Ease of installation
Range of features / widgets
Community support
Speed / performance
Internationalisation support
Licence compatible with commercial use
Accessibility features
Availability of extra tools
Familiarity of toolkit other languages
Paper-based documentation


=Survey of 2008 for best GUI Toolkit for Ruby=
To develop an app using Tk in Ruby, we first need to create widgets and then include them in our GUI. Events associated with these widgets are then bound to a method.
The summarised results are as below:
Tk is mostly used to create simple interfaces because of the nested hierarchy and sometimes trying to create complex interfaces can get troublesome. Tk is best used for smaller GUI needs.
The survey received a total of 399 responses; 80% of these completed the whole survey. Respondents were evenly split into those who'd never done GUI programming in Ruby, those who had in the past but weren't doing so now, and those who were currently doing so


==Installation & getting started==
Ruby installer comes with Tk associations but user needs to download and install [http://aspn.activestate.com/ASPN/Downloads/ActiveTcl/  ActiveTcl] in order to run a code written using Tk GUI Toolkit. If you have Ruby and ActiveTcl installed on your system then any editor can be used to write a code including a Tk Library


Most of those doing GUI development were working alone, either on "fun" projects or open-source software. One in three was using GUI libraries to develop in-house company tools; just under 10% were working on commercial GUI software.
==Running Sample Application==


The Ruby GUI "scene" remains fragmented: the survey found at least a dozen separate GUI libraries in current use. The most used toolkits were Shoes (21%), Ruby-GNOME2 (19%) and wxRuby (16%).
[[Image:tkruby.jpg]]


Of users naming a single preferred toolkit, Ruby-GNOME2 and Shoes were chosen by 26%, wxRuby by 17% and RubyCocoa 11%; no other toolkit received more than 10%.
To create the above shown GUI, open any basic editor ([http://notepad-plus-plus.org/ Notepad++] recommended) and type in the below code of lines. As mentioned above we first start the program by creating a root.


There are striking differences between Japanese and Euro-American Ruby users. Among Japanese Ruby developers, Ruby-GNOME2 is the preferred toolkit of a majority (56%), whereas among Euro-Americans, it lies third behind Shoes and wxRuby in popularity
require 'tk'                                            # include modules
root = TkRoot.new { title "Sample Application" }        # Title as root
TkButton.new(root) {                                    # create a button
  text  'Click this!'                                    # text on the button
  pack  { padx 35 ; pady 35; side 'left' }              # setting the properties
}
Tk.mainloop                                            # run the app's mainloop


Preference for one or other of the two leading comprehensive toolkits (GNOME2 and Wx) is not strongly predicted by the general importance attached to features of GUI libraries. This suggests their capabilities and range of potential applications largely overlap
The above written sample code is simple to understand. We first include the Tk module in Ruby. Then a root widget(a window in this case) is created and is given the title 'Sample Application'. A button is then created in the root widget and is given the title 'Click this'. Finally using pack the properties are set for defining size, alignment etc.


The emergence of new Ruby implementations and their associated GUI options has already had an effect on usage. MacRuby/Cocoa and, to a lesser degree, JRuby/Swing are well used and well regarded. MacRuby/Cocoa was the highest rated among all options for how well it met users' GUI  development requirements.
==Pros & Cons==
'''Pros''' -
* Cross platform
'''Cons''' -
* Badly documented
* Not elegant
* Widgets are non-native


Ruby-Tk received the worst rating for how well it meets users' GUI requirements, with a modal rating of 'poor'. It was the only library for which fewer respondents said they planned to use it in the future than are currently using it. It seems its continued inclusion in the standard library is unjustified.
==Projects developed in Tk==
* [http://sourceforge.net/projects/kvmail/ KvMail Client]
<br />


Among those with an opinion, there's a 60/40 split against including any GUI library in the Ruby standard distribution.
='''''FxRuby'''''=


The high degree of fragmentation has not served potential GUI developers well. Almost all see Ruby as a viable GUI programming language, but the immaturity of the toolkits is the commonest reason for not using Ruby for GUI work. The means of redistributing ruby GUI apps to end users is another obstacle.
FxRuby is a based on [http://www.fox-toolkit.org/ Fox toolkit] which is a GUI toolkit written in C++. Using FxRuby one can create powerful cross platform GUI interfaces for Ruby applications. Since Fox toolkit is known for its robust C++ implementation, applications develop in FxRuby are highly optimized and have very good performance.


The release of Ruby 1.9 addresses some perceived impediments to GUI development in Ruby, such as improved speed, and, more importantly, the availability of system-level threading. There is scope for the reference Ruby implementation to further improve Ruby as a platform for desktop applications, for example, by offering bytecode loading.
Look and feel of the window apps built with FxRuby stays native to the platform. FxRuby can also be used to create professional business apps.


==Installation & getting started==
FxRuby is very simple to install on any platform. Once you install Ruby with the Ruby installer, FxRuby can be downloaded and install using Ruby gems which comes along with the Ruby. Procedure to install FxRuby -
* Install Ruby from Ruby installer
* Open Command prompt
* Execute following command -


<center>[[Image:survey_results.jpg]]</center>
>>gems install rubygems


The numbers above clearly demonstrate that GUI library usage in Ruby remains highly fragmented. The most widely used library, Shoes, is currently being used by less than one in four GUI developers. They also suggest that this fragmentation is likely to persist. However, the strong showing of relatively new options, such as JRuby + Swing, MacRuby and Shoes, and the relatively low usage of long-established libraries such as FxRuby and Qt, are an indication that the situation is labile. It's a poor showing for the “standard” Ruby library, Tk, it being the only one where fewer users expect to use it in the future than are using it now.
Also to get the sample code and the documentation you can install the FxRuby Package from [http://rubyforge.org/projects/fxruby/ Rubyforge].


<center>[[Image:survey_results2.jpg]]</center>
==Running Sample Application==


Patterns of preference broadly follow patterns of usage, and most of the same comments apply. There was a very strong relationship between mother tongue and preferred toolkit. Among Japanese Ruby developers, Ruby-GNOME2 was the preferred toolkit of an absolute majority;
[[Image:fxruby.jpg]]
among speakers of European languages, the same toolkit was less popular than Shoes and wxRuby. This is almost certainly a reflection of the language of the lead developers of each of those toolkits: Japanese for GNOME2, English for Shoes and wxRuby. If the lead developers speak the developer's language, this is likely to furnish more documentation and timely community support in that language. This is a nice example of the significance of non-technical factors in toolkit selection.


To get started either you can open any editor and start writing the code or you can also use the integrated features of Eclipse IDE to build the app. Make sure that you load the 'rubygems' library in order to run apps make in FxRuby.


{| class="wikitable" border="1"
  require 'rubygems'                                   # call modules
|-
  require 'fox16'
| '''States'''
  include Fox
| '''Access Type'''
  app = FXApp.new                                      # Instantiate the app
| '''Invariant'''
  window = FXMainWindow.new(app, "Sample Application") # Create Window with title adding it as a child of app
|-
  FXButton.new(window, "Click this")                    # Creating Button and adding it as a child of window
| '''Modified'''
  app.create                                            # Create an app with the above controls
| read, write
  window.show                                          # render the app
| all other caches in I state
  app.run                                              # run the loop
|-
| '''Exclusive'''
|  read
|  all other caches in I state
|-
|  '''Owned'''
|  read
|  all other caches in I or S state
|-
|  '''Shared'''
| read
| no other cache in M or E state
|-
|  '''Invalid'''
|  -
|  -
|}
   


The first widely adopted approach to cache coherence is snooping on a bus. We will now discuss how some real time machines by '''Intel''' , '''AMD''' and other processors maintain cache coherence using '''''snooping based coherence protocols'''''.  For more information on snooping based protocols refer to Solihin text book Chapter 8.
The above code includes fox and rubygems modules required for fxruby widgets. An instance of FXApp is then created and a window and the button controls are added as its child. The widgets are then bound to the instance.Using the show method of window, the window is rendered and the instance is displayed.
<br />
<br />


=Cache Coherence in real machines=
==Pros & Cons==
'''Pros''' -
* Book available for reference


==SGI - Silicon Graphics, Inc==
'''Cons''' -
===MSI & SGI IRIS 4D Processors===
* Binary gems are available for Windows, OS X, and Ubuntu Linux but for other platforms,for  installing the gem  you need to compile native code.


'''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' is a three-state write-back '''invalidation protocol''' which is one of the earliest snooping-based cache coherence-protocols. It marks the cache line in '''Modified(M) ,Shared(S)''' and '''Invalid(I)''' state. '''Invalid''' means the cache line is either not present or is invalid state. If the cache line is clean and is shared by more than one processor , it is marked '''shared'''. If cache line is dirty and the processor has exclusive ownership of the cache line, it is present in '''Modified''' state. BusRdx causes others to invalidate (demote) to '''I''' state. If it is present in '''M''' state in another cache, it will flush. BusRdx even if hit in '''S''' state, it is promoted to '''M''' (upgrade) state.
==Projects developed in FxRuby==
* [http://www.attiksystem.ch/beerp/beerp-the-fxruby-erp/ BeERP ] -commercial ERP application
* [http://fxtwitter.rubyforge.org/ fxtwitter] -is a Twitter client
* [http://www.discretizer.org/ Discretizer] - for creating geometry and mesh for three dimensional objects.
* [http://freeride.rubyforge.org/wiki/wiki.pl FreeRIDE] -IDE for the Ruby programming language


The following state transition diagram for MSI protocol explains the working of the protocol:
<br />


<center>[[Image:MSI.jpg]]</center>
='''''WxRuby'''''=


'''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' protocol was first used in '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''' IRIS 4D series. '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''' produced a broad range of '''[http://en.wikipedia.org/wiki/MIPS_architecture MIPS]'''-based(Microprocessor without Interlocked Pipeline Stages) workstations and servers during the 1990s, running '''[http://en.wikipedia.org/wiki/Silicon_Graphics SGI]''''s version of UNIX System V, now called '''[http://en.wikipedia.org/wiki/IRIX IRIX]'''. The 4D-MP graphics superworkstation brought 40 mips(million instructions per second) of computing performance to a graphics superworkstation. The unprecedented level of computing and graphics processing in an office-environment workstation was made possible by the fastest available Risc microprocessors in a single shared memory multiprocessor design driving a tightly coupled, highly parallel graphics system. Aggregate sustained data rates of over one gigabyte per second were achieved by a hierarchy of buses in a balanced system designed to avoid bottlenecks.
WxRuby is yet another very stable GUI toolkit for Ruby. Like Tk , it also features native styling of the widgets across platforms and creates quite robust GUI apps. The wxRuby API is very much C++ oriented and the bindings which wxRuby provides doesn't exactly provide an environment of Ruby development. Hence it may get bit difficult for the Ruby developer to understand things in the beginning.


The Multiprocessor bus used in 4D-MP graphics superworkstation is a pipelined, block transfer bus that supports the cache coherence protocol as well as providing 64 megabytes of sustained data bandwidth between the processors, the memory and I/O system, and the graphics subsystem. Because the sync bus provides for efficient synchronization between processors, the cache coherence protocol was designed to support efficient data sharing between processors. If a cache coherence protocol has to support synchronization as well as sharing, a compromise in the efficiency of the data sharing protocol may be necessary to improve the efficiency of the synchronization operations. Hence it uses the simple cache coherence protocol which is the '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' protocol.
==Installation & getting started==
The installation of wxRuby is quite similar to that of FxRuby. You can install wxRuby using Ruby gems if the Ruby is already installed on the system. To get it via gems open a console window and type the following command -
>>gems install wxruby
Again like FxRuby you can install [http://rubyforge.org/frs/?group_id=35 wxRuby package from Rubyforge] to get the documentation, sample codes etc for wxRuby. The samples which comes with wxRuby are very interesting, you must try out few of them to know the power of wxRuby.


With the simple rules of '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' enforced by the hardware protocols of
==Running Sample Application==
the sync bus and the Multiprocessor bus, efficient synchronization and efficient data sharing are achieved in a simple shared memory model of parallel processing in the 4D-MP graphics superworkstation.


==SYNAPSE Multiprocessor==
[[Image:wxruby.jpg]]
===Synapse protocol and Synapse multiprocessor===
From the state transition diagram of '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''', we observe that for '''[http://en.wikipedia.org/wiki/MSI_protocol MSI]''' there is transition to state '''S''' from state '''M''' when a BusRd is observed for that block. The contents of the block is flushed to the bus before going to '''S''' state. It would look more appropriate to move to '''I''' state thus giving up the block entirely in certain cases. This choice of moving to '''S''' or '''I''' reflects the designer's assertion that the original processor is more likely to continue reading the block than the new processor to write to the block. In synapse protocol, used in the early Synapse multiprocessor, made this alternate choice of going directly from '''M''' state to '''I''' state on a BusRd, assuming the migratory pattern would be more frequent. More details about this protocol can be found in these papers published in late 1980's [http://portal.acm.org/citation.cfm?id=6514Cache Coherence protocols: evaluation using a multiprocessor simulation model] and [http://portal.acm.org/citation.cfm?id=1499317&dl=GUIDE&coll=GUIDE&CFID=83027384&CFTOKEN=95680533 Synapse tightly coupled multiprocessors: a new approach to solve old problems]


In Synapse protocol '''M''' state is called '''D''' (Dirty) state. The following is the state transition diagram for Synapse protocol which clearly shows its working.
require 'rubygems'                                           # call modules
require 'wx'
class MyApp < Wx::App                                        # Create a class derived by Wx::App
  def on_init
    @wxframe = Wx::Frame.new( nil, -1, "Sample Application" ) # Instantiate a Window frame
    @wxframe.show                                            # Display the above frame
  end
end
app = MyApp.new                                              # Instantiate the app
app.main_loop                                                # Run the program loop


<center>[[Image:Synapse1.jpg]]</center>
In the sample application above, rubygems and wx modules are included first. Then a class MyApp is declared which is inherited from base window class of wx module. In the constructor of MyApp a window frame is created and displayed. Now in the main program, instance of app is created and GUI loop is run.


==Intel==
==Pros & Cons==
===MESI & Intel Processors===
'''Pros''' -  
'''[http://en.wikipedia.org/wiki/MSI_protocol MSI]'''has a major drawback in that each read-write sequence incurs 2 bus transactions irrespective of whether the cache line is stored in only one cache or not. This is a huge setback for highly parallel programs that have little data sharing. '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol solves this problem by introducing the '''Exclusive''' state to distinguish between a cache line stored in multiple caches and a line stored in a single cache.
* Cross platform
Let us briefly see how the MESI protocol works. For a more detailed version refer Solihin textbook pg. 215.
* Larger support community
* Windows support
* Ease of installation
* Comprehensive widget set
* Internationalization
* Liberal licence


'''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' coherence protocol marks each cache line in of the Modified, Exclusive, Shared, or Invalid state.
'''Cons -'''
* '''Invalid''' : The cache line is either not present or is invalid
* Not enough documentation
* '''Exclusive''' : The cache line is clean and is owned by this core/processor only
* API is C++ Oriented
* '''Modified''' :  This implies that the cache line is dirty and the core/processor has  exclusive ownership of the cache line,exclusive of the memory also.
* Take time to develop apps
* '''Shared''' : The cache line is clean and is shared by more than one core/processor
* Does not install properly on latest Ubuntu


In a nutshell, the '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol works as follows:  
==Projects developed in wxRuby==
A line that is fetched, receives '''E''', or '''S''' state depending on whether it exists in other processors in the system. A cache line gets the '''M''' state when a processor writes to it; if the line is not in '''E''' or '''M'''-state prior to writing it, the cache sends a Bus Upgrade(BusUpgr) signal or as the Intel manuals term it, “Read-For-Ownership (RFO) request” that ensures that the line exists in the cache and is in the '''I''' state in all other processors on the bus (if any). A table is shown below to summarize '''[http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol'''.
* [http://www.empowermentzone.com/ TextPal] -is a text editor for blind and visually impaired people
* [http://jay.mcgavren.com/zyps/ Zyps]- animated game
* [http://wxsu.sourceforge.net/ wxRuby Plugin for Google Sketch-Up]- helps to create and share 3D models
* [http://rubyforge.org/projects/albuin/ Albuin]- music player
* [http://rubyforge.org/projects/wxride/ wxRIDE]- IDE for Ruby programming language
<br />


='''''QtRuby'''''=
Provides Ruby bindings to the Qt toolkit. This is used in the the KDE desktop system.


{| class="wikitable" border="1"
==Installation & getting started==
|-
To install QtRuby one need to install cross platform Qt framework available at [http://trolltech.com/products/qt/ Trolltech website]. If you have Ruby installed, you will only need [http://vision.eng.shu.ac.uk/jan/hornetseye-system/qtruby4installer.exe qtruby installer] if you want to install it in Windows.
|  '''Cache Line State:'''
|  '''Modified'''
|  '''Exclusive'''
|  '''Shared'''
|  '''Invalid'''
|-
|  '''This cache line is valid?'''
|  Yes
|  Yes
|  Yes
|  No
|-
|  '''The memory copy is…'''
|  out of date
|  valid
|  valid
|  -
|-
|  '''Copies exist in caches of other processors?'''|  No
|  No
|  Maybe
|  Maybe
|-
|  '''A write to this line'''|  does not go to bus
|  does not go to bus
|  goes to bus and updates cache
|  goes directly to bus
|}


Also you need to make sure that you have Ruby version 1.8.6-25 in order to install qtruby. Different versions of Ruby can be targeted from the same system without any problem.


==Running Sample Application==


The transition diagram from the lecture slides is given below for reference.
[[Image:qtruby.jpg]]


<center>[[Image:MESI.jpg]]</center> <br />
QtRuby is bit hard to learn but if you have been doing coding in c++ then you'll prefer QtRuby than any other GUI toolkits. To run a sample code you can use any editor or IDE.
require 'Qt'                                            # Call Qt module
app = Qt::Application.new(ARGV)                        # Instantiate the application
button=Qt::PushButton.new("Click this")                # Create button with title
button.resize(80,30)                                    # resize the button control
button.show                                            # Show the button on the app window
app.exec                                                # Execute the app (run the mainloop)


The '''Pentium Pro''' microprocessor, introduced in 1992 was the '''first''' Intel architecture microprocessor to support symmetric multiprocessing('''[http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP]''') in various multiprocessor configurations. '''[http://en.wikipedia.org/wiki/Symmetric_multiprocessing SMP]''' and '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol was the architecture used consistently until the introduction of the 45-nm Hi-k Core micro-architecture in '''Intel's (Nehalem-EP) quad-core x86-64'''. The 45-nm Hi-k Intel Core microarchitecture utilizes a new system of framework called the '''QuickPath Interconnect''' which uses point-to-point interconnection technology based on distributed shared memory architecture. It uses a modified version of '''[http://en.wikipedia.org/wiki/MESI_protocol MESI]''' protocol called '''MESIF''', by introducing an additional state, F, the forward state.  
In the above sample Qt module is included first. Then window instance of Qt application is created adding a button to it with changed size parameters. Window Qt app is then executed and displayed with above controls.


The '''Intel architecture''' uses the '''[http://en.wikipedia.org/wiki/MESI_protocol MESI'''] protocol  as the '''basis''' to ensure cache coherence, which is true whether you're on one of the older processors that use a '''common bus''' to communicate or using the new Intel '''QuickPath''' point-to-point interconnection technology.  
==Pros & Cons==
'''Pros''' -
* Book for reference available.
* Native looking desktop applications can be created
* Available as a Gem.


Let us now walk through a briefing on the '''MESIF protocl''':
'''Cons''' -
* Even though a gem is available for the Windows installation, for other platforms, only source code is available.
* Less easy to learn


The '''MESIF''' protocol, used in the latest Intel multi-core processors was introduced to '''accommodate the point-to-point''' links used in the QuickPath Interconnect. Using the '''MESI''' protocol in this architecture would send many redundant messages between different processors, often with unnecessarily high latency. For example, when a processor requests a cache line that is stored in multiple locations, every location might respond with the data. As the the requesting processor only needs a single copy of the data, the system would be '''wasting the bandwidth'''.
==Projects developed in Qt Ruby==
As a '''solution''' to this problem, an additional state, '''Forward state''', was added by slightly changing the role of the Shared state. Whenever there is a read request, only the cache line in the F state will respond to the request, while all the S state caches remain dormant. Hence, by designating a single cache line to '''respond to requests''', coherency traffic is substantially reduced when multiple copies of the data exist. Also, on a read request, the F state transitions from F to S state. That is, when a cache line in the '''F''' state is '''copied''', the F state '''migrates''' to the '''newer copy''', while the '''older''' one drops back to '''S'''. Moving the new copy to the F state '''exploits''' both '''temporal and spatial locality'''. Because the newest copy of the cache line is always in the F state, it is very unlikely that the line in the F state will be evicted from the caches. This takes advantage of the temporal locality of the request. The second advantage is that if a particular cache line is in high demand due to spatial locality, the bandwidth used to transmit that data will be spread across several nodes.
* [http://earth.google.com/ Google Earth]- Google Software to explore virtual world
All M to S state transition and E to S state transitions will now be from '''M to F''' and '''E to F'''. 
<br />
The '''F state''' is '''different''' from the '''Owned state''' of the MOESI protocol as it is '''not''' a '''unique''' copy because a valid copy is stored in memory. Thus, unlike the Owned state of the MOESI protocol, in which the data in the O state is the only valid copy of the data, the data in the F state can be evicted or converted to the S state, if desired.


More information on the QuickPath Interconnect and MESIF protocol can be found at
='''''Shoes'''''=
'''[http://www.intel.com/technology/quickpath/introduction.pdf Introduction to QuickPath Interconnect]'''


=== CMP Implementation in Intel Architecture ===
Shoes is a very recently introduced Ruby GUI toolkit. Shoes was designed specifically for Ruby unlike the other toolkits which were first developed for C/C++ developers (like QtRuby). Installing Shoes is very easy and it has packaged set-ups for every platform. Shoes is not really designed for serious,large-scale application but you can write small and useful programs using Shoes. The learning curve for Shoes is very small.


Let us now see how Intel architecture using the [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol progressed from a uniprocessor architecture to a Chip MultiProcessor(CMP) using the bus as the interconnect.  
Instead of using widgets like most of the other GUI toolkits, Shoes uses images and text layout. This tiny toolkit is written with the help of an art Engine called Cairo and has very limited native controls.


==Installation & getting started==
Shoes is probably the simplest and easiest GUI toolkit to install [http://www.rubyinside.com/ruby-gui-programming-survey-results-1552.html]. Once you install Ruby, just download the package from [http://github.com/shoes/shoes/downloads GitHub site] and install it on your Windows machine. Once you are done, the interface will give you few options to open the app, package the app or read the manual.


'''Uniprocessor Architecture'''
Surprising thing is that we don't even need Ruby or Winzip for running or packaging an app.


The diagram below shows the structure of the memory cluster in Intel Pentium M processor.
==Running Sample Application==
To run an app in Shoes, you first need to write it using any text editor and then open the app from the integrated app of Shoes. Scope of Shoes is very much limited though.  


<center>[[Image:intel_cache1.jpg]]</center> <br />
[[Image:shoes.jpg]]


  Shoes.app {
  @push = button "Click this"                  #  create a button
  @note = para "Nothing pushed so far"          #  text to display on the app
  @push.click {
    @note.replace "Okay you clicked"            # event handler message when button clicked.                                           
  }
}


In this structure we have,
In the above example, instance of Shoes app is created with a button and a text label. An event handler for button click event is defined. There is no need of run or execute methods which were seen in other sample programs.
* A unified on-chip '''L1 cache''' with the '''processor/core''',
* A '''Memory/L2 access control unit''', through which all the accesses to the L2 cache, main memory and IO space are made,
* The second level '''L2 cache''' along with the '''prefetch unit''' and
* '''Front side bus (FSB)''', a single shared bi-directional bus through which all the traffic is sent across.These wide buses bring in multiple data bytes at a time.  


As Intel explains it, using this structure, the processor requests were first sought in the '''L2 cache''' and only on a '''miss''', were they '''forwarded''' to the main '''memory''' via the front side bus ('''FSB'''). The '''Memory/L2 access control''' unit served as a central point for '''maintaining coherence''' within the core and with the external world. It '''contains''' a '''snoop control unit''' that receives snoop requests from the bus and performs the required operations on each cache (and internal buffers) in parallel. It also handles RFO requests (BusUpgr) and ensures the operation continues only after it guarantees that no other version on the cache line exists in any other cache in the system.
==Pros & Cons==
'''Pros''' -
* Good graphics
* Easy control at a lower level
* Simple interface with redistributables and examples


'''Cons''' -
* Considered rough around the edges since it attempts to support so many platforms
* Lacks many of the more robust widgets common in other toolkits


'''CMP Architecture'''
==Projects developed in Shoes==
* [http://the-shoebox.org/apps/157 Download Organizer] - Organize your downloads
* [http://the-shoebox.org/apps/162 xkcd Scraper] Must try app for xkcd lovers
* [http://the-shoebox.org/apps/150 World Clock] Show times for different timezones
<br />


For CMP implementation, Intel chose the bus-based architecture using snoopy protocols vs the '''directory protocol''' because though directory protocol reduces the active power due to reduced snoop activity, it '''increased''' the '''design complexity''' and the '''static power''' due to larger tag arrays. Since Intel has a large market for the processors in the mobility family, directory-based solution was less favorable since battery life mainly depends on static power consumption and less on dynamic power.
='''Comparison of various GUI toolkits for Ruby'''=
Let us examine how '''CMP''' was implemented in '''Intel Core Duo''', which was one of the first dual-core processor for the budget/entry-level market.
The general CMP implementation structure of the Intel Core Duo is shown below


<center>[[Image:intel_cache2.jpg]]</center> <br />
[[Image:Ruby toolkits.jpg]]


This structure has the following changes when compared to the uniprocessor memory cluster structure.
Above are the screen captures of the sample application we made using five GUI toolkits for Ruby. It was found that the QtRuby and Shoes almost imitate the native interface of Windows.
* '''L1 cache''' and the '''processor/core''' structure is '''duplicated''' to give 2 cores.
* The '''Memory/L2 access control''' unit is '''split''' into 2 logical units: '''L2 controller''' and '''bus controller'''. The L2 controller handles all '''requests to the L2''' cache from the core and the snoop requests from the FSB. The '''bus controller''' handles '''data and I/O requests''' to and from the FSB.
* The '''prefetching''' unit is extended to handle the hardware '''prefetches for each core separately'''.
* A '''new logical unit''' (represented by the hexagon) was added to maintain '''fairness between the requests''' coming from the different cores and hence balance the requests to L2 and memory.


This new '''partitioned structure''' for the  memory/L2 access control unit '''enhanced''' the '''performance''' while '''reducing power consumption'''.
==Cross platform comparison==
For more information on uniprocessor and multiprocessor implementation under the Intel architecture, refer to
{| class="wikitable sortable"  border="1" style="font-size: 100%; text-align: center; width: auto;"
[http://www.intel.com/technology/itj/2006/volume10issue02/art02_CMP_Implementation/p03_implementation.htm CMP Implementation in Intel Core Duo Processors]
|-
! '''GUI Toolkit'''
! '''Microsoft Windows|Windows'''
! '''Linux'''
! '''Mac OS X'''
|-
! '''Tk'''
| yes
| yes
| yes
|-
! '''FxRuby'''
| yes
| yes
| yes
|-
! '''WxRuby'''
| yes
| yes
| yes
|-
! '''QtRuby'''
| yes
| yes
| yes
|-
! '''Shoes'''
| yes
| yes
| yes
|-
! '''Swing'''
| yes
| yes
| yes
|-
! '''Monkeybars'''
| yes
| yes
| yes
|-
! '''Cocoa'''
| No
| No
| yes
|-
! '''GTK'''
| yes
| yes
| yes
|}


The '''Intel bus architecture''' has been '''evolving''' in order to accommodate the demands of scalability while using the '''same [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol'''; From using a '''single shared bus''' to '''dual independent buses (DIB)''' doubling the available bandwidth and to the logical conclusion of DIB with the introduction of '''dedicated high-speed interconnects (DHSI)'''. The DHSI-based platforms use four FSBs, one for each processor in the platform. In both DIB and DHSI, the snoop filter was used in the chipset to cache snoop information, thereby significantly reducing the broadcasting needed for the snoop traffic on the buses. With the production of processors based on next generation 45-nm Hi-k Intel Core microarchitecture, the [http://en.wikipedia.org/wiki/Xeon Intel Xeon] processor fabric will transition from a DHSI, with the memory controller in the chipset, to a distributed shared memory architecture using '''Intel QuickPath Interconnects using MESIF protocol'''.
<br />


==AMD - Advanced Micro Devices Processors==
==Rapid GUI development comparison ==
While installing the GUI toolkits for Ruby we did a research on the ease of use of above mentioned Toolkit. Some of the toolkit were very easy to install and use while others took so much time asking to install dependencies first. Also, while coding a sample application in these toolkit we compared the level of difficulty of using these toolkit and look and feel of the app which gets developed.


 
This may be helpful for people to choose the GUI toolkit for Ruby. We assume that Ruby is already installed on the system with ruby gems.
===MOESI & AMD Processors===
<br />
<br />
<br />
[http://en.wikipedia.org/wiki/Opteron AMD Opteron] was the AMD’s first-generation dual core which had 2 distinct [http://en.wikipedia.org/wiki/Athlon_64 K8 cores] together on a single die.  Cache coherence produces bigger problems on such multiprocessors. It was necessary to use an appropriate coherence protocol to address this problem. The [http://en.wikipedia.org/wiki/Xeon Intel Xeon], which was the competitive counterpart from Intel to AMD dual core Opteron , used the [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol to handle cache coherence.  [http://en.wikipedia.org/wiki/MESI_protocol MESI] came with the drawback of using much time and bandwidth in certain situations.
[http://en.wikipedia.org/wiki/MOESI_protocol MOESI] was the AMD’s answer to this problem . [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] added a fifth state to [http://en.wikipedia.org/wiki/MESI_protocol MESI] protocol called '''“Owned”''' . [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] addresses the bandwidth problem faced in MESI protocol when processor having invalid data in its cache wants to modify the data.  The processor seeking the data access will have to wait for the processor which modified this data to write back to the main memory, which takes time and bandwidth. This drawback is removed in MOESI by allowing dirty sharing.  When the data is held by a processor in the new state '''“Owned”''', it can provide other processors the modified data without or even before writing it to the main memory. This is called '''''dirty sharing'''''. The processor with the data in '''"Owned"''' stays responsible to update the main memory later when the cache line is evicted.
[http://en.wikipedia.org/wiki/MOESI_protocol MOESI]'  has become one of the most popular snoop-based protocols supported in the AMD64 architecture.  The AMD dual-core Opteron can maintain cache coherence in systems up to 8 processors using this protocol.
The five different states of [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol are:
* '''Modified (M)''' : The most recent copy of the data is present in the cache line. But it is not present in any other processor cache.
* '''Owned (O)'''  : The cache line has the most recent correct copy of the data . This can be shared by other processors. The processor in this state for this cache line is responsible to update the correct value in the main memory before it gets evicted. 
* '''Exclusive (E)''' : A cache line holds the most recent, correct copy of the data, which is exclusively present on this processor and a copy is present in the main memory. 
* '''Shared (S)''' : A cache line in the shared state holds the most recent, correct copy of the data, which may be shared by other processors.
* '''Invalid (I)''' : A cache line does not hold a valid copy of the data.
A detailed explanation of this protocol implementation on AMD processor can be found in the manual [http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html Architecture of the AMD 64-bit core]
The following table summarizes the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol:
{| class="wikitable" border="1"


{| class="wikitable sortable"  border="1" style="font-size: 100%; text-align: center; width: auto;"
|-
! '''GUI Toolkit'''
! '''Time taken to build first application'''
! '''Level of difficulty'''
! '''Look and feel of interface'''
|-
! '''Tk'''
| 18mins
| Medium
| Average
|-
! '''FxRuby'''
| 13 mins
| Medium
| Good
|-
|-
 
! '''WxRuby'''
|  '''Cache Line State:'''
| 11 mins
 
| Medium
'''Modified'''
| Average
 
|  '''Owner'''
 
| '''Exclusive'''
 
| '''Shared'''
 
| '''Invalid'''
 
|-
|-
 
! '''QtRuby'''
'''This cache line is valid?'''
| 22 mins
 
| Difficult
|  Yes
| Very Good
 
|  Yes
 
| Yes
 
| Yes
 
| No
 
|-
|-
! '''Shoes'''
| 8 mins
| Easy
| Good
|}
<br />


|  '''The memory copy is…'''
==Best GUI Toolkit for Ruby Survey 2008==


| out of date
Towards the end of year 2008, an interesting survey [http://www.rubyinside.com/ruby-gui-programming-survey-results-1552.html] of Ruby programmers was conducted.The set of respondents in the survey were those who had done GUI programming in Ruby, those who had done some Ruby GUI programming in the past but now were not doing so and those who are doing so presently. This survey aimed to find the use and their attitudes towards graphical user interface (GUI) libraries used for creating Ruby desktop applications.Given below are the summarized results as presented by the surveyors, which will help us to get an insight into what were the most important features programmers looked for:


|  out of date
* The most used toolkits were Shoes (21%), Ruby-GNOME2 (19%) and wxRuby (16%).


|  valid
* In response to a single preferred toolkit, Ruby-GNOME2 and Shoes were chosen by 26%, wxRuby by 17% and RubyCocoa 11%; no other toolkit received more than 10%.


|  valid
* Ruby-GNOME2 came as the most preferred toolkit by a clear majority (56%)of Japanese Ruby developers, whereas Euro-Americans preferred Shoes and WxRuby followed by Ruby-Gnome.


-
* Ruby-Tk received the most poor rating for how well it meets users' GUI requirements.


|-
* The majority saw Ruby as a viable GUI programming language, but the unsophistication of the toolkits is the most common reason for not using Ruby for GUI development.
<br />


|  '''Copies exist in caches of other processors?'''
<center>[[Image:survey_results1.jpg]]</center>


|  No
The numbers above clearly show that GUI library usage in Ruby remains very varied. This variation is likely to continue. The situation may turn any side since a lot of new options, such as JRuby + Swing, MacRuby and Shoes are in the competition.


|  No
<br />
|  Yes(out of date values)
<center>[[Image:survey_results21.jpg]]</center>
|  Maybe


|  Maybe
Patterns of preference broadly follow patterns of usage. A very strong relationship between mother tongue and preferred toolkit was observed. Among Japanese Ruby developers, Ruby-GNOME2 was a popular choice and among Europeans, Ruby-Gnome was less popular than Shoes and WxRuby. If the lead developers speak the developer's language, then it is more than likely to present more documentation and active community support in that language. This tells us that even non-technical factors in toolkit selection play an important role.


|-
<br />


|  '''A write to this line'''
==A guide to 'when to use what'==
If you just want to make a message box pop-up occasionally, or ask a user for some simple input, then any of the toolkits will work well.


| does not go to bus
You may decide to take into consideration characteristics like platform availability, a suitable range of widgets, and appropriate cost if your application requirements are really simple.
|  does not go to bus
|  does not go to bus


|  goes to bus and updates cache
For distributing your application, you will need to look into toolkit licensing issues. You will also have to take into consideration whether the user already has the required environment or you will have to create an installation package for all libraries and widgets needed.


|  goes directly to bus
For complex applications, which consist of more than a few simple forms, you will definitely require a form-designer tool. You would also need a rich and varied set of available widgets. Instead of re-inventing the wheel, it is better to use or rather re-use an existing component like a date picker or file browser rather than writing your own.
<br />
<br />


|}
= '''Selection Criteria of GUI toolkit'''=
 
* Ease of distributing applications
 
* Web-based/paper based documentation (“how-to-use-this” narrative))
 
* Availability on multiple platforms.(Great results on Windows, where most of the customers are)
State transition for [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]is as shown below :
* Maturity / stability (Robust, production-grade,No beta, no pre-1.0)
* Appearance / aesthetics (Looks like 2010 and not 1990)
* Nonrestrictive license (License compatible for commercial use)
* API programming style (Consistent and comprehensible API, with API reference)
* Ease of installation
* Rich set of widgets or components(Features beyond what is readily possible to perform in a web application)
* Community support (Whether or not it is actively maintained and updated)
* Speed / performance
* Internationalization support
* Accessibility features
* Affordable cost
* Existing frameworks and libraries to speed development
* Testing tools and frameworks
<br />


='''Conclusion'''=
Ruby has no real “Ruby-like” GUI system of itself.Tk is the default that comes with Ruby distribution. You can use it if you are fine with just basic functionality and do not care much about appearance. Incase you want something better, you have several choices that we saw. Developing a GUI library for Ruby is actually tedious. There are many reasons for this like, the large number of classes and methods often involved in the implementation; the need to employ lower-level compiled languages;cross-platform support;automated testing; highly variable paths through code; and the complexity of reconciling Ruby's GC-based memory management with that of the base language (often C or C++) in long-running applications.


<center>[[Image:MOESI_State_Transition_Diagram.jpg]]</center>
Just like a coin has two sides, each of them has its share of good qualities, but none of them emerged as a clear winner. There is no unanimous choice for general Ruby cross-platform desktop development. To varying degrees, they all have issues with installation, documentation, design tools, packaging, and deployment.


<center> [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]State transition Diagram</center>
<br />
<br />
<br />


===AMD Opteron memory Architecture===
='''References'''=
<br />
                                                   
<center>[[Image:Untitled.jpg]]</center>


[1] [http://ruby-doc.org/ Ruby language]


[2] Fowler, C., The Ruby FAQ, www.rubygarden.org/faq


The AMD processor’s high-performance cache architecture includes an integrated, 64-bit, dual-ported  128-Kbyte split-L1 cache with separate snoop port, multi-level translation lookaside buffers (TLBs), a scalable L2 cache controller with a 72-bit (64-bit data + 8-bit ECC) interface to as much as 8-Mbyte of industry-standard SDR or DDR SRAMs, and an integrated tag for the most cost-effective 512-Kbyte L2 configurations. The AMD Athlon processor’s integrated L1 cache comprises two separate 64-Kbyte, two-way set-associative data and instruction caches.
[3] [http://wiki.github.com/rdp/ruby_talk_faq/ruby-gui-toolkit-comparison/8 GUI toolkit comparison]


More information about this can be found in [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD 64 bit Architecture Programmers's Manual]
[4] Vinoski, S.; , "Ruby Extensions," Internet Computing, IEEE , vol.10, no.5, pp.85-87, Sept.-Oct. 2006


===Special Coherence Considerations in AMD64 architectures===
[5] [http://wonko.com/post/a_brief_comparison_of_cross-platform_gui_toolkits_from_rubys_per Cross platform GUI toolkits]
<br />
Instruction prefetching is a technique used to speedup the execution of the program. But in multiprocessors, prefetching comes at the cost of performance. Due to prefetching, the data can be modified in such a way that the memory coherence protocol will not be able to handle the effects. In such situations software must use serializing instructions or cache-invalidation instructions to guarantee subsequent data accesses are coherent.
<br />
An example of this type of a situation is a page-table update followed by accesses to the physical pages referenced by the updated page tables. The physical-memory references for the page tables are different than the physical-memory references for the data. Because of prefetching there maybe problem with correctness. The following sequence of events shows such a situation when software changes the translation of virtual-page A from physical-page M to physical-page N:
# The tables that translate virtual-page A to physical-page M are now held only in main memory. The copies in the cache ae invalidated.
# Page-table entry is changed by the software for virtual-page A in main memory to point to physical page N rather than physical-page M.
# Data in virtual-page A is accessed.


Software expects the processor to access the data from physical-page N after the update. However, it is possible for the processor to prefetch the data from physical-page M before the page table for virtual page A is updated. Because the physical-memory references are different, the processor does not recognize them as requiring coherence checking and believes it is safe to prefetch the data from virtual-page A, which is translated into a read from physical page M. Similar behavior can occur when instructions are prefetched from beyond the page table update instruction.
[6] [http://www.rubyinside.com/ruby-gui-programming-survey-results-1552.html 2008 GUI survey]


In order to prevent errors from occuring, there are special instructions provided by software like INVLPG or MOV CR3 instruction which is executed immediately after the page-table update to ensure that subsequent instruction fetches and data accesses use the correct virtual-page-to-physical-page translation. It is not necessary to perform a TLB invalidation operation preceding the table update.
[7] Dave Thomas , Chad Fowler , Andy Hunt, Programming Ruby 1.9: The Pragmatic Programmers' Guide, Pragmatic Bookshelf, 2009


More information can be found about this in [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD64 Architecture Programmer's manual]
[8] [http://www.pragmaticprogrammer.com/titles/ctrubyqt/ Rapid GUI Development with QtRuby]


===Optimization techniques on MOESI when implemented on AMD Phenom processors===
[9] Wikipedia, Ruby programming language, en.wikipedia.org/wiki/Ruby_programming_language
<br />


In real machines, using some optimization techniques on the standard cache coherence protocol used , improves the performance of the machine. For example [http://en.wikipedia.org/wiki/AMD_Phenom AMD Phenom] family of microprocessors (Family 0×10) which is AMD’s first generation to incorporate 4 distinct cores on a single die, and the first to have a cache that all the cores share, uses the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol with some optimization techniques incorporated.
[10] [http://wiki.rubygarden.org/Ruby/page/show/ComparingGuiToolkits/TakeTwo Comparing GUI toolkits]


It focuses on a small subset of compute problems which behave like Producer and Consumer programs. In such a computing problem, a thread of a program running on a single core produces data, which is consumed by a thread that is running on a separate core. With such programs, it is desirable to get the two distinct cores to communicate through the shared cache, to avoid round trips to/from main memory. The '''MOESI''' protocol that the [http://en.wikipedia.org/wiki/AMD_Phenom AMD Phenom] cache uses for cache coherence can also limit bandwidth. Hence by keeping the cache line in the '''‘M’''' state for such computing problems, we can achieve better performance.
[11] [http://www.tutorialspoint.com/ruby/ruby_tk_guide.htm Ruby TK Guide]


When the producer thread , writes a new entry, it allocates cache-lines in the '''modified (M)''' state. Eventually, these M-marked cache lines will start to fill the L3 cache. When the consumer reads the cache line, the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI] protocol changes the state of the cache line to '''owned (O)''' in the L3 cache and pulls down a '''shared (S)''' copy for its own use. Now, the producer thread circles the ring buffer to arrive back to the same cache line it had previously written. However, when the producer attempts to write new data to the owned (marked '''‘O’''') cache line, it finds that it cannot, since a cache line marked '''‘O’''' by the previous consumer read does not have sufficient permission for a write request (in the [http://en.wikipedia.org/wiki/MOESI_protocol MOESI]). To maintain coherence, the memory controller must initiate probes in the other caches (to handle any other S copies that may exist). This will slow down the process.
[12] [http://www.darshancomputing.com/qt4-qtruby-tutorial/ Qt4 tutorial for Ruby]


Thus, it is preferable to keep the cache line in the '''‘M’''' state in the L3 cache. In such a situation, when the producer comes back around the ring buffer, it finds the previously written cache line still marked '''‘M’''', to which it is safe to write without coherence concerns. Thus better performance can be achieved by such optimization techniques to standard protocols when implemented in real machines.
[13] [http://www.fxruby.org/doc/examples.html FxRuby sample applications]


You can find more information on how this is implemented and various other ways of optimizations in this manual [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf Software Optimization guide for AMD 10h Processors]
[14] [http://www.darshancomputing.com/qt4-qtruby-tutorial/chapter_01 QtRuby Hello world Application]


[15] [http://en.wikipedia.org/wiki/Shoes_%28GUI_toolkit%29 Ruby Shoes toolkit sample]


==Xerox Corporation==
<br />
===Dragon Protocol & Xerox Dragon Processors===
The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' is an update based coherence protocol which does not invalidate other cached copies like what we have seen in the coherence protocols so far. Write propagation is achieved by updating the cached copies instead of invalidating them.  But the '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' does not update memory on a cache to cache transfer and delays the memory and cache consistency until the data is evicted and written back, which saves time and lowers the memory access requirements. Moreover only the written '''byte''' or the '''word''' is '''communicated''' to the '''other caches''' instead of the whole block which further '''reduces''' the '''bandwidth''' usage. It has the ability to detect dynamically, the sharing status of a block and use a write through policy for shared blocks and write back for currently non-shared blocks. The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' employs the following four states for the cache blocks: '''Shared Clean''', '''Shared Modified''', '''Exclusive''' and  '''Modified'''.
* '''Modified(M)''' and '''Exclusive(E)''' - these states have the same meaning as explained in the protocols above.
* '''Shared Modified (Sm)''' - Only one cache line in the system can be in the Shared Modified state. Potentially two or more caches    have this block and memory may or may not be up to date and this processor's cache had modified the block.
* '''Shared Clean (Sc)''' -  Potentially two or more caches have this block and memory may or may not be up to date(if no other cache has it in Sm state, memory will be up to date else it is not).
When a Shared Modified line is evicted from the cache on a cache miss only then is the block written back to the main memory in order to keep memory consistent. For more information on Dragon protocol, refer to Solihin textbook, page number 229. The state transition diagram has been given below for reference.
 
<center>[[Image:Dragon.jpg]]]]</center>


The '''[http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]''' , was developed by Xerox Palo Alto Research Center('''[http://en.wikipedia.org/wiki/Xerox_PARC Xerox PARC]'''), a subsidiary of Xerox Corporation.  This protocol was used in the '''[http://en.wikipedia.org/w/index.php?title=Xerox_Dragon&redirect=no Xerox PARC Dragon]''' multiprocessor workstation, a VLSI research computer that could support multiple processors on a central high bandwidth memory bus. The Dragon design implemented snoopy caches that provided the appearance of a uniform memory space to multiple processors. Here, each cache listens to 2 buses: the processor bus and the memory bus. The caches are also responsible for address translation, so the processor bus carries virtual addresses and the memory bus carries physical addresses.  The Dragon system was designed to support 4 to 8 Dragon processors. The memory bus used in the Xeron Dragon evolved to become the '''[http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&arnumber=289691 XDBus]''' , a low-cost, synchronous, '''packet-switched VLSI bus''' designed for use in high-performance multiprocessors. This was used as the interconnect in many multiprocessor server systems like '''Cray Superserver 6400''', '''Sun Microsystems' SPARCcenter 2000''' and '''SPARCserver 1000'''  and '''Sun4d''' systems.
=='''External Links'''==


=References=
#[http://wxruby.rubyforge.org/wiki/wiki.pl WxRuby]
# [http://en.wikipedia.org/wiki/Cache_coherence Cache coherence]
#[http://ruby.about.com/od/shoes/ss/shoes1.htm Shoes]
# [http://www.intel.com/technology/quickpath/introduction.pdf Introduction to QuickPath Interconnect]
#[http://www.fxruby.org/ FxRuby]
# [http://www.intel.com/technology/itj/2006/volume10issue02/art02_CMP_Implementation/p03_implementation.htm CMP Implementation in Intel Core Duo Processors]
#[http://rubyforge.org/projects/korundum/ QtRuby]
# [http://en.wikipedia.org/wiki/Symmetric_multiprocessing Common System Interface in Intel Processors]
#[http://www.activestate.com/activetcl ActiveTcl for Windows]
# [http://www.zak.ict.pwr.wroc.pl/nikodem/ak_materialy/Cache%20consistency%20&%20MESI.pdf Cache consistency with MESI on Intel processor]
#[http://www.ibm.com/developerworks/java/library/j-monkeybars/ Monkeybars]
# [http://techreport.com/articles.x/8236/2 AMD dual core Architecture]
# [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24593.pdf AMD64 Architecture Programmer's manual]
# [http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40546.pdf Software Optimization guide for AMD 10h Processors]
# [http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html Architecture of AMD 64 bit core]
# [http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&arnumber=4913 Silicon Graphics Computer Systems]
# [http://books.google.com/books?id=g82fofiqa5IC&printsec=frontcover&dq=Parallel+computer+architecture:+a+hardware/software+approach+By+David+E.+Culler,+Jaswinder+Pal+Singh,+Anoop+Gupta&source=bl&ots=COrdamlfVn&sig=YcugVqbzTjHvlofvaFq6Ft_tjfY&hl=en&ei=0ZO6S4TJGcOclgejzI3BBw&sa=X&oi=book_result&ct=result&resnum=1&ved=0CAgQ6AEwAA#v=onepage&q=&f=false Parallel computer architecture: a hardware/software approach By David E. Culler, Jaswinder Pal Singh, Anoop Gupta]
# [http://www.freepatentsonline.com/5283886.html Three state invalidation protocols]
# [http://portal.acm.org/citation.cfm?id=1499317&dl=GUIDE&coll=GUIDE&CFID=83027384&CFTOKEN=95680533 Synapse tightly coupled multiprocessors: a new approach to solve old problems]
# [http://portal.acm.org/citation.cfm?id=6514Cache Coherence protocols: evaluation using a multiprocessor simulation model]
# [http://en.wikipedia.org/wiki/Dragon_protocol Dragon Protocol]
# [http://en.wikipedia.org/wiki/Xerox_Dragon Xerox Dragon]
# [http://thanaseto.110mb.com/courses/CSD-527-report-engl.pdf Coherence Protocols]
# [http://ieeexplore.ieee.org.www.lib.ncsu.edu:2048/stamp/stamp.jsp?tp=&arnumber=289691 XDBus]

Latest revision as of 01:24, 18 September 2010

GUI Toolkits for Ruby

While starting to build a new desktop or commercial application, we all have to make a very important decision regarding which platform and GUI toolkit to use from a pool of so many available. In very simple words, a Graphical User Interface (GUI) toolkit is the set of API's (Application Programming Interface) that produces the graphical user interface your users will interact with. There are a number of factors to consider when choosing the toolkit which are discussed in the sections below. Different toolkit support different platforms (Linux, Windows, OSX) and have different features such as looks,accessibility and layout engines(how it is rendered on a web browser).We will see all these considerations with respect to Ruby in more details in the sections below.

Peek into the Ruby Language

Ruby is an Object-Oriented Programming language. It serves as a very good platform to write low-level scripts for system administration tasks and for developing plain end-user applications rapidly. Using Ruby definitely avoids the time consuming 'code-compile-test' cycle which is normal in traditional programming.

Despite all these characteristics, Ruby's most usable implementation was the open source interpreter till very recently. This was because the way Ruby was designed,Ruby did not have very interactive capability other than just accepting text inputs on a console. This would not have gone very far since it is very evident to everyone that graphical user interfaces are a very important for modern end-user applications.As a result, at the onset of year 2009, Ruby was still not well known for being used for developing regular or commercial desktop applications. A possible reason was identified as a lack of good GUI-related libraries.

Overview

Ruby does have something that comes packaged with its standard library and enables users to develop GUI for desktop applications. This 'something' is called Tk. To use Tk for GUI development, you have to install Tk and its interface to connect with Ruby(Ruby binding). But the problem is that it is considered messy,ugly and the API is considered to be from yesteryears.With time,things evolved and today we have the developments of number of third party libraries like FxRuby,WxRuby,QtRuby,GTK-Ruby,Shoes and Swing which give Ruby graphical user interaction (GUI).These libraries give Ruby the user interface elements like text boxes to key in data, buttons to perform certain operation and window displays. More recent alternate implementations of Ruby have their own GUI facilities, such as Cocoa for MacRuby and Swing for JRuby. These toolkits are not really brand new but some like FxRuby, wxRuby, ruby-GNOME2 and RubyQt are simply wrappers for toolkits written in C or C++. Shoes is a graphical library is implemented for Ruby alone.

All the toolkits have some common features but they also differ in many aspects. There is no “best” toolkit in abstract terms.The usefulness of a library is only really tested by trying to use it to perform a specific task. Similarly, the toolkit shortcomings may only become apparent after a using it in substantial and a purposeful way.

Ruby's popularity has double folded in recent years.It remains a small language when compared to C, C++ and Java and hence it is an open question whether having a large number of libraries that more or less provide similar features is an optimal outcome.

Tk

The standard graphical user interface (GUI) for Ruby is Tk. It was initially developed for the Tcl scripting language by John Ousterhout. Tk is known for its widgets hierarchy. There's one root widget which can contain other widgets inside it. Tk applications really do have a good look-and-feel.

To develop an app using Tk in Ruby, we first need to create widgets and then include them in our GUI. Events associated with these widgets are then bound to a method. Tk is mostly used to create simple interfaces because of the nested hierarchy and sometimes trying to create complex interfaces can get troublesome. Tk is best used for smaller GUI needs.

Installation & getting started

Ruby installer comes with Tk associations but user needs to download and install ActiveTcl in order to run a code written using Tk GUI Toolkit. If you have Ruby and ActiveTcl installed on your system then any editor can be used to write a code including a Tk Library

Running Sample Application

To create the above shown GUI, open any basic editor (Notepad++ recommended) and type in the below code of lines. As mentioned above we first start the program by creating a root.

require 'tk'                                            # include modules
root = TkRoot.new { title "Sample Application" }        # Title as root
TkButton.new(root) {                                    # create a button
 text  'Click this!'                                    # text on the button
 pack  { padx 35 ; pady 35; side 'left' }               # setting the properties
}
Tk.mainloop                                             # run the app's mainloop

The above written sample code is simple to understand. We first include the Tk module in Ruby. Then a root widget(a window in this case) is created and is given the title 'Sample Application'. A button is then created in the root widget and is given the title 'Click this'. Finally using pack the properties are set for defining size, alignment etc.

Pros & Cons

Pros -

  • Cross platform

Cons -

  • Badly documented
  • Not elegant
  • Widgets are non-native

Projects developed in Tk


FxRuby

FxRuby is a based on Fox toolkit which is a GUI toolkit written in C++. Using FxRuby one can create powerful cross platform GUI interfaces for Ruby applications. Since Fox toolkit is known for its robust C++ implementation, applications develop in FxRuby are highly optimized and have very good performance.

Look and feel of the window apps built with FxRuby stays native to the platform. FxRuby can also be used to create professional business apps.

Installation & getting started

FxRuby is very simple to install on any platform. Once you install Ruby with the Ruby installer, FxRuby can be downloaded and install using Ruby gems which comes along with the Ruby. Procedure to install FxRuby -

  • Install Ruby from Ruby installer
  • Open Command prompt
  • Execute following command -
>>gems install rubygems

Also to get the sample code and the documentation you can install the FxRuby Package from Rubyforge.

Running Sample Application

To get started either you can open any editor and start writing the code or you can also use the integrated features of Eclipse IDE to build the app. Make sure that you load the 'rubygems' library in order to run apps make in FxRuby.

require 'rubygems'                                    # call modules
require 'fox16'
include Fox
app = FXApp.new                                       # Instantiate the app
window = FXMainWindow.new(app, "Sample Application")  # Create Window with title adding it as a child of app
FXButton.new(window, "Click this")                    # Creating Button and adding it as a child of window
app.create                                            # Create an app with the above controls
window.show                                           # render the app
app.run                                               # run the loop

The above code includes fox and rubygems modules required for fxruby widgets. An instance of FXApp is then created and a window and the button controls are added as its child. The widgets are then bound to the instance.Using the show method of window, the window is rendered and the instance is displayed.

Pros & Cons

Pros -

  • Book available for reference

Cons -

  • Binary gems are available for Windows, OS X, and Ubuntu Linux but for other platforms,for installing the gem you need to compile native code.

Projects developed in FxRuby

  • BeERP -commercial ERP application
  • fxtwitter -is a Twitter client
  • Discretizer - for creating geometry and mesh for three dimensional objects.
  • FreeRIDE -IDE for the Ruby programming language


WxRuby

WxRuby is yet another very stable GUI toolkit for Ruby. Like Tk , it also features native styling of the widgets across platforms and creates quite robust GUI apps. The wxRuby API is very much C++ oriented and the bindings which wxRuby provides doesn't exactly provide an environment of Ruby development. Hence it may get bit difficult for the Ruby developer to understand things in the beginning.

Installation & getting started

The installation of wxRuby is quite similar to that of FxRuby. You can install wxRuby using Ruby gems if the Ruby is already installed on the system. To get it via gems open a console window and type the following command -

>>gems install wxruby

Again like FxRuby you can install wxRuby package from Rubyforge to get the documentation, sample codes etc for wxRuby. The samples which comes with wxRuby are very interesting, you must try out few of them to know the power of wxRuby.

Running Sample Application

require 'rubygems'                                            # call modules
require 'wx'
class MyApp < Wx::App                                         # Create a class derived by Wx::App
  def on_init
    @wxframe = Wx::Frame.new( nil, -1, "Sample Application" ) # Instantiate a Window frame
    @wxframe.show                                             # Display the above frame
  end
end
app = MyApp.new                                               # Instantiate the app
app.main_loop                                                 # Run the program loop

In the sample application above, rubygems and wx modules are included first. Then a class MyApp is declared which is inherited from base window class of wx module. In the constructor of MyApp a window frame is created and displayed. Now in the main program, instance of app is created and GUI loop is run.

Pros & Cons

Pros -

  • Cross platform
  • Larger support community
  • Windows support
  • Ease of installation
  • Comprehensive widget set
  • Internationalization
  • Liberal licence

Cons -

  • Not enough documentation
  • API is C++ Oriented
  • Take time to develop apps
  • Does not install properly on latest Ubuntu

Projects developed in wxRuby


QtRuby

Provides Ruby bindings to the Qt toolkit. This is used in the the KDE desktop system.

Installation & getting started

To install QtRuby one need to install cross platform Qt framework available at Trolltech website. If you have Ruby installed, you will only need qtruby installer if you want to install it in Windows.

Also you need to make sure that you have Ruby version 1.8.6-25 in order to install qtruby. Different versions of Ruby can be targeted from the same system without any problem.

Running Sample Application

QtRuby is bit hard to learn but if you have been doing coding in c++ then you'll prefer QtRuby than any other GUI toolkits. To run a sample code you can use any editor or IDE.

require 'Qt'                                            # Call Qt module
app = Qt::Application.new(ARGV)                         # Instantiate the application
button=Qt::PushButton.new("Click this")                 # Create button with title
button.resize(80,30)                                    # resize the button control
button.show                                             # Show the button on the app window
app.exec                                                # Execute the app (run the mainloop)

In the above sample Qt module is included first. Then window instance of Qt application is created adding a button to it with changed size parameters. Window Qt app is then executed and displayed with above controls.

Pros & Cons

Pros -

  • Book for reference available.
  • Native looking desktop applications can be created
  • Available as a Gem.

Cons -

  • Even though a gem is available for the Windows installation, for other platforms, only source code is available.
  • Less easy to learn

Projects developed in Qt Ruby


Shoes

Shoes is a very recently introduced Ruby GUI toolkit. Shoes was designed specifically for Ruby unlike the other toolkits which were first developed for C/C++ developers (like QtRuby). Installing Shoes is very easy and it has packaged set-ups for every platform. Shoes is not really designed for serious,large-scale application but you can write small and useful programs using Shoes. The learning curve for Shoes is very small.

Instead of using widgets like most of the other GUI toolkits, Shoes uses images and text layout. This tiny toolkit is written with the help of an art Engine called Cairo and has very limited native controls.

Installation & getting started

Shoes is probably the simplest and easiest GUI toolkit to install [1]. Once you install Ruby, just download the package from GitHub site and install it on your Windows machine. Once you are done, the interface will give you few options to open the app, package the app or read the manual.

Surprising thing is that we don't even need Ruby or Winzip for running or packaging an app.

Running Sample Application

To run an app in Shoes, you first need to write it using any text editor and then open the app from the integrated app of Shoes. Scope of Shoes is very much limited though.

 Shoes.app {
 @push = button "Click this"                   #  create a button
 @note = para "Nothing pushed so far"          #  text to display on the app

 @push.click {
   @note.replace "Okay you clicked"            # event handler message when button clicked.                                            
 }
}

In the above example, instance of Shoes app is created with a button and a text label. An event handler for button click event is defined. There is no need of run or execute methods which were seen in other sample programs.

Pros & Cons

Pros -

  • Good graphics
  • Easy control at a lower level
  • Simple interface with redistributables and examples

Cons -

  • Considered rough around the edges since it attempts to support so many platforms
  • Lacks many of the more robust widgets common in other toolkits

Projects developed in Shoes


Comparison of various GUI toolkits for Ruby

Above are the screen captures of the sample application we made using five GUI toolkits for Ruby. It was found that the QtRuby and Shoes almost imitate the native interface of Windows.

Cross platform comparison

GUI Toolkit Windows Linux Mac OS X
Tk yes yes yes
FxRuby yes yes yes
WxRuby yes yes yes
QtRuby yes yes yes
Shoes yes yes yes
Swing yes yes yes
Monkeybars yes yes yes
Cocoa No No yes
GTK yes yes yes


Rapid GUI development comparison

While installing the GUI toolkits for Ruby we did a research on the ease of use of above mentioned Toolkit. Some of the toolkit were very easy to install and use while others took so much time asking to install dependencies first. Also, while coding a sample application in these toolkit we compared the level of difficulty of using these toolkit and look and feel of the app which gets developed.

This may be helpful for people to choose the GUI toolkit for Ruby. We assume that Ruby is already installed on the system with ruby gems.

GUI Toolkit Time taken to build first application Level of difficulty Look and feel of interface
Tk 18mins Medium Average
FxRuby 13 mins Medium Good
WxRuby 11 mins Medium Average
QtRuby 22 mins Difficult Very Good
Shoes 8 mins Easy Good


Best GUI Toolkit for Ruby Survey 2008

Towards the end of year 2008, an interesting survey [2] of Ruby programmers was conducted.The set of respondents in the survey were those who had done GUI programming in Ruby, those who had done some Ruby GUI programming in the past but now were not doing so and those who are doing so presently. This survey aimed to find the use and their attitudes towards graphical user interface (GUI) libraries used for creating Ruby desktop applications.Given below are the summarized results as presented by the surveyors, which will help us to get an insight into what were the most important features programmers looked for:

  • The most used toolkits were Shoes (21%), Ruby-GNOME2 (19%) and wxRuby (16%).
  • In response to a single preferred toolkit, Ruby-GNOME2 and Shoes were chosen by 26%, wxRuby by 17% and RubyCocoa 11%; no other toolkit received more than 10%.
  • Ruby-GNOME2 came as the most preferred toolkit by a clear majority (56%)of Japanese Ruby developers, whereas Euro-Americans preferred Shoes and WxRuby followed by Ruby-Gnome.
  • Ruby-Tk received the most poor rating for how well it meets users' GUI requirements.
  • The majority saw Ruby as a viable GUI programming language, but the unsophistication of the toolkits is the most common reason for not using Ruby for GUI development.


The numbers above clearly show that GUI library usage in Ruby remains very varied. This variation is likely to continue. The situation may turn any side since a lot of new options, such as JRuby + Swing, MacRuby and Shoes are in the competition.


Patterns of preference broadly follow patterns of usage. A very strong relationship between mother tongue and preferred toolkit was observed. Among Japanese Ruby developers, Ruby-GNOME2 was a popular choice and among Europeans, Ruby-Gnome was less popular than Shoes and WxRuby. If the lead developers speak the developer's language, then it is more than likely to present more documentation and active community support in that language. This tells us that even non-technical factors in toolkit selection play an important role.


A guide to 'when to use what'

If you just want to make a message box pop-up occasionally, or ask a user for some simple input, then any of the toolkits will work well.

You may decide to take into consideration characteristics like platform availability, a suitable range of widgets, and appropriate cost if your application requirements are really simple.

For distributing your application, you will need to look into toolkit licensing issues. You will also have to take into consideration whether the user already has the required environment or you will have to create an installation package for all libraries and widgets needed.

For complex applications, which consist of more than a few simple forms, you will definitely require a form-designer tool. You would also need a rich and varied set of available widgets. Instead of re-inventing the wheel, it is better to use or rather re-use an existing component like a date picker or file browser rather than writing your own.

Selection Criteria of GUI toolkit

  • Ease of distributing applications
  • Web-based/paper based documentation (“how-to-use-this” narrative))
  • Availability on multiple platforms.(Great results on Windows, where most of the customers are)
  • Maturity / stability (Robust, production-grade,No beta, no pre-1.0)
  • Appearance / aesthetics (Looks like 2010 and not 1990)
  • Nonrestrictive license (License compatible for commercial use)
  • API programming style (Consistent and comprehensible API, with API reference)
  • Ease of installation
  • Rich set of widgets or components(Features beyond what is readily possible to perform in a web application)
  • Community support (Whether or not it is actively maintained and updated)
  • Speed / performance
  • Internationalization support
  • Accessibility features
  • Affordable cost
  • Existing frameworks and libraries to speed development
  • Testing tools and frameworks


Conclusion

Ruby has no real “Ruby-like” GUI system of itself.Tk is the default that comes with Ruby distribution. You can use it if you are fine with just basic functionality and do not care much about appearance. Incase you want something better, you have several choices that we saw. Developing a GUI library for Ruby is actually tedious. There are many reasons for this like, the large number of classes and methods often involved in the implementation; the need to employ lower-level compiled languages;cross-platform support;automated testing; highly variable paths through code; and the complexity of reconciling Ruby's GC-based memory management with that of the base language (often C or C++) in long-running applications.

Just like a coin has two sides, each of them has its share of good qualities, but none of them emerged as a clear winner. There is no unanimous choice for general Ruby cross-platform desktop development. To varying degrees, they all have issues with installation, documentation, design tools, packaging, and deployment.


References

[1] Ruby language

[2] Fowler, C., The Ruby FAQ, www.rubygarden.org/faq

[3] GUI toolkit comparison

[4] Vinoski, S.; , "Ruby Extensions," Internet Computing, IEEE , vol.10, no.5, pp.85-87, Sept.-Oct. 2006

[5] Cross platform GUI toolkits

[6] 2008 GUI survey

[7] Dave Thomas , Chad Fowler , Andy Hunt, Programming Ruby 1.9: The Pragmatic Programmers' Guide, Pragmatic Bookshelf, 2009

[8] Rapid GUI Development with QtRuby

[9] Wikipedia, Ruby programming language, en.wikipedia.org/wiki/Ruby_programming_language

[10] Comparing GUI toolkits

[11] Ruby TK Guide

[12] Qt4 tutorial for Ruby

[13] FxRuby sample applications

[14] QtRuby Hello world Application

[15] Ruby Shoes toolkit sample


External Links

  1. WxRuby
  2. Shoes
  3. FxRuby
  4. QtRuby
  5. ActiveTcl for Windows
  6. Monkeybars