The AST nodes of the Scala compiler (2.8.0) are usually imported from an instance of scala.tools.nsc.Global, e.g.
but they are actually defined in scala.reflect.generic in the trait Trees.
Archive for the Programming Category
In order to see Unicode characters when running a Scala project using SBT inside a Windows console (cmd) you have to perform the following steps:
-
Fire up
regeditand navigate toHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ Console\TrueTypeFont. There should be an entry with key-value pair (“0″, “Lucida Console”). Add new pairs with a sequence of zeros as the key and a font as the value, e.g. (“00″, “DejaVu Sans”), (“000″, “Lucida Sans Typewriter”) etc. -
Edit your SBT launcher-script – the one that runs SBT e.g. as
java %SBT_OPTS% -Xmx256M -jar "tools/sbt-launch-0.7.4.jar" %*and add the Java option-Dfile.encoding=UTF-8. -
Open a Windows command box and run
chcp 65001to set the code page to UTF-8.
That’s it. You should now be able to see Unicode output of your Scala project when run from inside the SBT shell.
If you want to change the code page permanently, run regedit, go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage and change the “OEMCP” value to “65001″.
From the JPDA FAQ:
Why do debugger applications run in a separate VM from the debuggee?
Any Java programming language code run for the purpose of analyzing the behavior of a program (in the same Java virtual machine) interferes with the behavior being analyzed. Some of this interference is subtle, for example: the order that classes are loaded; and the scheduling of threads. More severe however, is competition for resources, for example, if the program being analyzed is holding a lock needed by the analyzing code, deadlock can occur. Finally, many operations can only be reliably performed in a suspended virtual machine; if the virtual machine is suspended the analysis code can not run. At the core of the reliability problems of the old sun.tools.debug interface is that part of its implementation ran as Java programming language code in the debuggee virtual machine. For this reason, the JPDA back-end implementation goes to great pains to avoid the execution of any code in the debuggee virtual machine.
In my last post I came up with the question, whether it is a good idea to have the data provider (in my case a SortableDataProvider) hold references to queried entities in order to avoid frequently queries to the database, or if it is OK to rely on my persistence provider to take care of caching.
According to this post, the JPA specs define a caching concept called Persistence Context, which caches all managed entities until the persistence context is cleared explicitly (by calling em.clear()) or implicitly (e.g. when using a container-managed transaction-scoped entity manager and completing a transaction). This JPA caching concept is often referred to as first-level (L1) caching.
Further more, persistence providers (like TopLink) introduce second-level (L2) caching, that caches entities in a bigger scope then the L1 cache, for example server-wide.
Anyway, according to this blog entry from Wonseok Kim, EntityManager.find() checks session cache first before it goes to the database, while a
SELECT query doesn’t check cache first and always goes right through to the database.
Thus, because
SELECTqueries always hit the database anyway- and I want to rely as little as possible on the underlying persistence provider
I’m going to keep having my data providers have references to their entities.
But, keep in mind, that I’m new to this whole JPA topic and that I might have missed an essential point or that I misunderstood something important… So don’t hesitate to leave your 2 cents or to correct me!
Today I’ll “release” the first build of my auction web application which uses Apache Wicket and Google Guice.
The application currently has close to no features and merely shows some basic architectural decisions and how I use Wicket and Guice to realize them.
The application is divided into 3 tiers: presentation, business logic and persistence tier – nothing spectacular so far. The JPA (Toplink in this case) is handling persistent objects, I only implemented a ShopDAO that hides the underlying EntityManager.
In this post I’ll describe, how to get the Wicket Guice example up and running.
According to the projects homepage, Guice is a lightweight dependency injection framework for Java 5 which wholly embraces annotations and generics, thereby enabling you to wire together and test objects with less effort than ever before. Annotations finally free you from error-prone, refactoring-adverse string identifiers.
My second post about Apache Wicket actually is not about Wicket, but about the project I’d like to realize with Wicket.
It’s a small auction application, that allows the users to purchase bundles that contain different product, e.g. 2 pencils, 5 toy cars and 1,5kg cabbage. Each bundle is offered for a certain price that drops every n minutes and is sold to the first user who hit’s the red button for the currently displayed price.
The user then gets a unique id which allows him or her to fetch the bundle at the factories outlet store in a period of time after the purchase.
Users do not have to register in order to buy bundles at the auction, they only need to know the unique id when they fetch the bundle. Application administrators in contrast have to login to perform tasks like adding/modifying products and bundles.
The presentation tier of the application will be realized with Wicket while the persistence tier will be realized using the JPA.
I originally planed to use the EJB 3.0 dependency injection features to allow the classes to be as loosely coupled as possible, but then I thought, that using EJB (and thus needing an application server with an EJB container) just for dependency injection would be like breaking a fly on the wheel. So I decided to give Google Guice a try, which will be the topic of the next post.
This entry is the first in a (planed) series of entries about me realizing a small web project with Apache Wicket. The tagline of this one could be An explanation why I want to realize a small web project with Apache Wicket.
I recently attended two courses at university which included laboratory tasks dealing with several aspects of J2EE. This opened a whole new world to me, as I formerly only did J2SE.
The concepts and ideas that manifest in products like EJB (3.0), JPA (not J2EE, ok) and JSP fascinated me the most. I have off course once in a while read something about EJB, overheard a talk about Hibernate, stumbled upon a reference to Struts, …, but I never devoted time to any of them, nor did I see the need to do so.
While still in my training to be a digital media designer (“Ausbildung zum Mediengestalter” in German), I realized several web projects with PHP. As soon as the projects became bigger, I had the feeling that something is wrong with the solutions I came up with, that there must be a better way to do things. Not on the implementation-level, but on the architectural side of (software) live… and when I started with the J2EE laboratories, I considered myself to be in (software) heaven.
