An issue that crops up in systems based on virtual machine is: what are the primitives provided by the VM and how are they represented?

In my previous post about Meta-Programming with Scala I suspected that there was no way to express partial function application in Scala’s type system. However Matt Hellige proofed me wrong in his comment. His solution uses a trait for partially applying a function to some of its arguments. An abstract type exposed by the trait represents the resulting function which takes the remaining arguments.

Nimbus is completely configured by properties in the UIManager defaults table. In my last blog I showed a simple example of how to skin a single component. This gave you a sneak peek into the power of these properties. Lots of people have asked for a complete list of properties that can be set, well its simple just grab UIManager.getLookAndFeelDefaults() and iterate over the contents of the map and print the keys and values and there you go. Well I am not that cruel so I did the work for you and will include a link to a complete table of them at the end. But before I get to that let me explain how they work.

So I was taking a look at the Scala Array source code, as part of research for a forthcoming blog post (coming soon to a drmaciver.com near you) when I suddenly realised something. Then I suddenly had a WTF moment.

So time for a example of how to skin a Swing JSlider using the Nimbus Look and Feel and some simple painting code. So this is what we get with the standard Nimbus look slider on a dark grey background.

Google avoids it by sticking to a limited set of languages. I don't work at Google, so I can't claim to know what their architecture looks like in terms of blending languages within applications. But the act of limiting languages does not in itself preclude polyglot programming. Choosing to limit yourself to one language, or one language per application, would do so. Likewise, choosing C# and Java as your languages would probably nullify most of the benefits. But the point is, just because you allow or encourage polyglot programming does not mean you let everyone choose whatever language suits them and then throw it all together in a melting pot, praying that everything works well together. You can have a method to sort out the madness.

This is the third part in a series of articles on formal language processing in Scala, focusing on parser combinators and language interpretation. In this part I will add a nice operator syntax and support for recursive grammars to the simple parser combinators introduced in part 2 and then move on to the parser combinators from Scala’s core library.

This is the second part in a series of articles about parser combinators and implementing an interpreter in Scala. In this part I will focus on the development from simple hand-written parsers to parser combinators so that you can see how a combinator-based parser really works and utilize parser combinators to their full potential instead of treating them as merely a DSL for EBNF grammars.

There’s a dangerous trap to fall into: The belief that functional code is automatically good code. Hopefully not too many people would come out and actually claim this, but it seems to be an unstated common belief.

Recently I read this rather fascinating post about a Type-safe Builder Pattern in Scala. When Heinz Kabutz mentioned the builder pattern in his latest issues of the The Java Specialists’ Newsletter I decided to try to come up with a type safe version for Java.

The following post is the result of my latest JavaFx Script experiments mixed with Stu's Java.Next series (1,2). Alright, so Stu decides to showcase how the Java.next languages interop with Java the language, and to do so he chose a Swing based example. Though he did a great job covering each transformation from the original Java example to each of the Java.next candidates, the original example has a slight flaw: it doesn't honor Sun's guidelines for building Swing apps, mainly when creating components and/or changing a component's UI state you must do it inside the Event Dispatch Thread.

This post presents a little unfinished experiment for creating an XSD Xml Schema definition from classes based on some of the rules to map XAML documents to objects. The program is written in IronRuby and it uses reflection to inspect classes and generate the schema definition.

Once upon a time there was a graphical programming princess named Processing. She conjured the most beautiful animations and interactive art in all the world! Every artist wanted to work with her. But the princess’s castle lay within a vast colony of millworkers that, excepting her own court, had little appreciation for her talents.

Some solutions which I found, suggest to add a combobox item "Separator", and the renderer finds it and renders it as JSeparator. But as per my opinion Polluting model data in order to get separators in UI is bad approach. It also has a drawback. because model contains a specific list item for separator, it can be selectable by user.

Java (and consequently Scala) lack unsigned integer types. Most of the time this isn’t an issue - the majority of the operations you’re likely to care about (addition, subtraction, bitwise operations) work the same regardless of whether you treat the integer as unsigned. There are a few cases where it is a pain though.

It'd be good for a garbage collector to have low space overhead, good cache behavior and low fragmentation. Low space overhead is useful wherever there's a limited amount of RAM. Eliminating fragmentation is important, since fragmentation reduces the usable amount of memory and can make allocation slower. Improving cache behavior of ordinary programs is always good for performance, and surprisingly a garbage collector can help. These three goals point to mark-compact garbage collection as a good way to go.

Thanks to Jeremy Wood’s comment on my Sexy Swing App - Unified Toolbar, I’ve gone back and removed the extension of JPanel I was using in order to paint a focus-state-based-border, and replaced it with a client property listener. I really favor this technique over extension, as it reduces coupling and dependencies, namely on JPanel.

In my last post I showed how to encode the Church numerals and addition on them with Scala’s type system. I mentioned that this approach does not seem to scale. In this post I show the problems I faced while I tried to extend the approach to multiplication. This particular example shows that Scala’s type system does not seem to support partial function application which in general is crucial for defining more complex functions base on simpler ones. But before delving into Scala, let’s review the church numerals in lambda calculus.

This post presents a little Silverlight program written using IronRuby that exercises features such as graphics, dynamic language interaction and style separation. This is the second of series of posts that explore features across different platforms such as JavaFX Script or Flex. The first post can be found here.

Given that the formalization of Scala Classic has ground to a halt, for reasons I may go into later, I spent part of today hacking on the Scala compiler itself to add support for singleton literals. Currently, Scala allows singleton types for stable identifiers. My modification allows literals to be used in singleton types. I can't promise that it will be in the forthcoming Scala 2.7.2 release, but I would like it to be.

If you've ever used any profiling tools but have never used Shark on OSX, find a Mac and play with it for a while. In fact, if you can't find a mac, go to an Apple Store and find a Mac with the SDK installed and play with Shark. I'll warn you though; it'll spoil you. You will have a hard time using any other profiling tools.

Help the Apache Wicket team to determine the future of your Wicket based web application development. We have released our third and hopefully final milestone release of our Java 5 based web framework and are anxious to receive feedback on our use of generics.

Placard style button’s are a nice way to add JComboBox-like widgets to your application, but with less of the visual baggage that comes with a standard combo box. Apple briefly talks about placard style components here.

ach step so far has included minor bits and pieces to test specific features. But it's hard to get an idea for how complete a language is becoming without writing something a little bit more substantial. In this case I've chosen to write a "text-mangler" that will "parse" an s-expression like (Lisp like) syntax and turn it into a Ruby script that will run the compiler with the equivalent program.

One of the strengths of the Wicket framework is that while it enables sky-high feats of abstraction on the trapeze of application state, a tire swing is available when you need a state closer to the ground. For stateless resources, on the other hand, all you’ll ever need is a caching safety net.