Book Review: Design Recipes for FPGAs

Design Recipes for FPGAs is a sort of "something about everything" book. The book just lists the FPGA-related issues and doesn't cover any of those in detail. Even if there are some kind of examples - I wouldn't recommend this book to anyone. Istead, The Design Warrior's Guide to FPGAs is a much better alternative.

Book Review: The Design Warrior's Guide to FPGAs

The Design Warrior's Guide to FPGAs is a must-read book! Written in an entertaining style, the books is very interesting to read. The book provides an insightful overview of the FPGA technology, design tools and flows. This is a great book for someone that is getting started in FPGAs. After reading this book one will have the basic knowledge about FPGA technology.

Book Review: Mastering Enterprise JavaBeans 3.0

Another book about EJB 3.0 is Mastering Enterprise JavaBeans 3.0. The book focuses on the changes made since EJB 2.1. Here are some week aspects of this book:

• it is not that smoothly readable as the previous EJB book


• the book spends too much on high-level introduction of EJB 3.0 specification while it could dive into more practical details ASAP


• JPA is poorly covered

But nevertheless, the book is somewhat a good complementary material for learning EJB 3.0.

Book Review: EJB 3 in Action

EJB 3 in Action was really enjoyable to read. This is a well-structured book and covers just what is really required for Java 5 EE application development. In my opinion it is not the best suited for a beginner: it is easier to understand the text if one already has some experience with EJB 2.0. The book provides practical code examples, best practices, design patterns, and performance tuning tips.
I would strongly recommend this book to anyone who would like to get familiar with EJB 3.0.

P.S. The relevance to the JEE development is out of the scope here :) Personally, I would rather go Spring/Hibernate than JSR220 and JSR291 rather than JSR277.

P.S.2 Why not to assume that Hibernate and Spring are the de jure standards for JEE middleware development, instead of creating EJB 3.0? Political reasons? I think that Sun is still reinventing the wheel with its own "standards" and not making use of the community process.

My Ubuntu

After years being a windows user, eventually I decided to join Linux community. The main reason is that this platform is more attractive from the open-source software point of view. After reading some forums and newsgroups I decided to try Ubuntu for my Fujitsu-Siemens laptop. Although I have a 64 bit system I have chosen not to ask for problems and picked the 32-bit distro.


The only thing that was keeping me from moving to Linux is M$ Excel, which is used is our university at the informatics lessons for VBA programming, and the last 5 years I had some friends asking for help with that. Now I think I have had enough of that and next time I would be asked for VBA help I'll say I know nothing about it :)

The first impression from using Ubuntu is very positive! Installation of the system was so rapid that I even thought that there's an error and something didn't work :) Very cool! First I tried to install only the KDE version but eclipse refused to work with that one. With Gnome everything is working, here's the check list:

- eclipse (ok)
- firefox, with flash player (ok)
- USB memory stick (ok)
- SD card reader (ok)
- external USB hard-drive (ok)
- playing wmv/avi/mpeg/flv (ok)
- playing mp3 (ok)
- burning CD/DVD (ok)
- viewing graphics/pdf/chm/djvu (ok)
- Skype/Gtalk/Yahoo!Messenger/MSN/ICQ (ok)
- Xilinx WebPACK/ModelSim - (haven't tried yet)

I haven't tried to connect a webcam so far. And one thing I have problem with is running Picasa on wine - it just hangs at the splash screen and does nothing.

Now I've got to find a file manager a-la Windows Commander, coz I'm not impressed with Nautilus file manager.

I have to say that I'm not a Windows-hater. I think that most of the "linuxoids" words that "Windows must die" or "Windows is a crap", are meaningless. I had no problems using Windows besides keeping the anti-virus database up to date, which is not that hard. It is just the nature of my hobby (read oss programming) that requires something else than a proprietary Windows system.

A Case for Groovy Singleton

In my last post I've written about the new feature in Groovy API, the GroovySystem class. Now I would like to give it a try for the singleton pattern implementation inside the plug-in extension.

Why would I ever want to do that? The singleton class could be used for persisting the state between the same action calls. I wanted to try this solution just because it must be possible to implement the same thing in the different ways. Nothing else.

Here's an example:

def expando = new groovy.util.Expando()

class MySingleton {
  String toString() { 'MySingleton: ' + hashCode()}
}

class MySingletonMetaClass extends MetaClassImpl {
  private final static INSTANCE = new MySingleton()
  MySingletonMetaClass() { super(MySingleton) }
  def invokeConstructor(Object[] arguments) { return INSTANCE }
}

def registry = GroovySystem.metaClassRegistry
registry.setMetaClass(MySingleton, new MySingletonMetaClass())

expando.run = {action ->
   expando.workbenchWindow.getActivePage().
     showView("org.eclipse.soc.yummy.views.ScriptView")
 println "hello groovy action: ${action}"
 def single = new MySingleton()
 println "${single}"
}

I just create a singleton using the GroovySystem and MetaClassImpl, so that when an action delegate gets called, I will have always the same instance of the singleton class.

Unfortunately, I didn't find a way to implement the same in case of different scripts, e.g. if I have two different scripting extensions. Perhaps I will have to provide a single class to the plug-in which could be used just for this purpose.

JSR 223 and Groovy 1.1 Beta 2

In Groovy version 1.1-beta-2 a new class groovy.lang.GroovySystem provides some nice features that I would like to use in my Google Summer of Code project. Namely, this is one way to implement a bundle activator for an eclipse plug-in. Not really an activator, actually, but sort of.

In a scripted bundle, the activator can be just a singleton class, and GroovySystem can be used to create a fancy singleton pattern in Groovy, like it is described at Groovy's homepage.

The problem I faced when I tried to initialize the scripting engine using javax.sript API, was that the engine implementation still thinks that groovy.lang.MetaClass is a class, but it is an interface in the latest version of Groovy.

So the stack trace of this exception was:

Exception in thread "main" 
java.lang.IncompatibleClassChangeError: 
at com.sun.script.groovy.GroovyScriptEngine
  .(GroovyScriptEngine.java:63)
at com.sun.script.groovy.GroovyScriptEngineFactory
  .getScriptEngine(GroovyScriptEngineFactory.java:87)
at javax.script.ScriptEngineManager
  .getEngineByName(ScriptEngineManager.java:225)

The quickest fix I could do, is to download the scripting engine sources from the website, and comment out the line in GroovyScriptEngine's static initializer. After the recompilation I didn't get the stack trace any more, but I think I have to investigate a bit more, what could be affected by this change.

The ViewPart Should Be Equal

I was preparing an example of a groovy view extension for my GSoC project tonight. First, I created a groovy class that extends org.eclipse.ui.part.ViewPart and added the required methods to that class:

class MyView extends ViewPart {
  public void createPartControl(Composite composite) {
  }
  public void setFocus(){
  }
}

def view = new MyView();
view

The first disappointment was that I couldn't write the method declarations in a groovy way, using def, because it was yelling that the abstract methods should be implemented. Thus I conclude that I cannot implement the abstract methods using def.

So far, so good... OK, when I executed the above script I got a nice stack trace, saying that "A part must be equal to itself", and/or "A part must have a meaningful equals method". This was a message from org.eclipse.ui.internal.PartTester#testWorkbenchPart(), that checks the brand new part for some strange things, like part.equals(new Integer(32)). Why 32, can anyone tell!?

So I implemented a goofy equals() for my script object, just to make it work. Here's the example code: view.groovy.

GSoC 2007: Equator Reached!

The midterm evaluation is complete and just over a month is left to do the project, and the deadline is approaching fast.

The last post about the facade implementation for each extension was just a concept showing what could be done for mapping the extension method calls to the script. But implementing a dedicated facade for each extension is not feasible just because there is an unlimited number of the extension types available.

As the previous post said, a proxy class solution could solve the problem so that I shouldn't write a dedicated facade for each extension. That said, we have a brand new solution in place: the ScriptExtensionProxy class, which implements the following interfaces:

1. IExecutableExtension required for extension initial setup in ConfigurationElement#createExecutableExtension() calling IExecutableExtension#setInitializationData()


2. IExecutableExtensionFactory required for proxy class construction using IExecutableExtensionFactory#create() call in ConfigurationElement#createExecutableExtension()


3. InvocationHandler required to delegate the extension method calls to the script in InvocationHandler#invoke() method.

The example script still works the same way as previously, but no facade class required any more.

The declaration of an extension is changed a little bit, as I have to define a proxy class, an extension interface class and a script file in the class attribute in plugin.xml:

<action class="org.eclipse.soc.yummy.core.ScriptExtensionProxy: \
   org.eclipse.ui.IWorkbenchWindowActionDelegate/action.groovy"
               icon="icons/sample.gif"
               id="ScriptAction"
               label="&Sample Action"
               menubarPath="sampleMenu/sampleGroup"
               toolbarPath="sampleGroup"
               tooltip="Hello, Eclipse world">
         </action>

It looks a little messy though...

Overall, providing the scripting support for developing plug-ins in Groovy requires only three classes at the moment: a proxy, a script execution engine, and a helper class for initialization code that is actually used in the proxy class only. LOC = 355.


Next, I will have to make many examples to see what is missing in ScriptExecutor and to find out which workbench objects should I expose to the script. I still need to refer to Dash for this purpose.

Eclipse plug-ins and JSR-223

Recently I was trying to bind the eclipse plug-in world with JSR-223 and Groovy via javax.script API for my GSoC project. Here's how it turned out.

First I need to have a class that deals with all that javax.script stuff: let there be ScriptingExecutor. Its functionality isn't very advanced - it just delegates the calls to the scripting API and maintains several fields for holding the state of the script. STOP! Why would I need to keep track of the state at all? The problem is that not all the scripting languages with the same semantics/features.

Let's see the example: an action facade and a script that implements this action. I'm using the Expando object to create a class with the same methods as for the action: run(IAction action), selectionChanged(IAction action, ISelection selection), dispose(). The reason why i would like to pass the new object back to the plug-in is that when a selection is changes I would like to save the reference for further processing in the run(IAction) method. The script below has a visibility problem and cannot use def selection to save the state.

 def selection

 def run(action){
    println "selection = ${selection}" // this won't work!!!
 }

 def selection(action, selection){
   this.selection = selection
 }

The Groovy User Manual says:

Executing this code you get an exception talking about a missing property or field.
The only things the method has access to are:
* the binding,
* attributes defined by the base class, and
* the dynamic properties defined by the MetaClass (explanations for these will follow).

So I decided to use Expando as a base class for saving the state. Simple.

Next, there are 2 options of delegating the plug-in extension to the script object:

1. Using the invokeMethod/invokeFunction methods of the javax.script.Invocable interfaces. These can be used just for simply calling the functions from the evaluated script. or...


2. Using getInterface(Class clazz) to create an object that would implement the required interface, of instance IActionDelegate.

I'm not sure which option is really better so I'm using the first one for now.

Next, I should try to implement several facades and scripts for the extensions, so that I could see the common parts and unify them in one. Implementing a facade for every single extension does not seem to be very relevant, perhaps the getInterface(Class clazz) method will help to skip that... Or I will need some sort of Proxy solution to skip all the facades.

Also I'm referencing Eclipse Monkey project as an inspiration. The reason is that for smoothing the script development a set of predefined variables could be very handy, so the user could use them out of the box. And that is what Eclipse Monkey does: it exposes some internal object into the script context so that a script contributor could use them.