[Virgil] virgil installation on Ubuntu 6.06 desktop - not without trouble

Wed Jun 20 19:41:46 PDT 2007

Hi Bill,

Thanks for taking the time to detail your issues. I think most of the 
problem seems to stem from GCJ behaving slightly differently than Sun's 
javac compiler. I didn't test on GCJ, but maybe I should. Overall, I 
recommend using Sun's free JRE system; they have RPMs and binary packages 
that work with no problem on nearly all Linux distros.

On Sat, 16 Jun 2007, Bill Maas wrote:

> 
Hi,

I discovered Virgil just yesterday, and I have high hopes for using it
to replace the AVR-libc/Linux and BASCOM/Windows duo that I've been
involved with for the last 1 1/2 year or so. While I'd personally go for
the AVR-libc, I have to work 15-to-18 year old Windows users who I just
can't bother with C's intricacies. And having to start WXP everytime I
want to do someting with BASCOM has proven to be quite annoying (BASCOM
is the only reason why I have a Windows installation at home). So I hope
that in Virgil I've found a platform-independent language, which suits
me, that is no more difficult to use than BASCOM, which will suit the
user base.

However, even installing Virgil onto my Ubuntu/Linux desktop has proven
to be quite a pain. Admitted, Java on Linux has always required "special
attention". I have zero knowledge of Java, and I don't think I should
need that knowledge: I've compiled many a C program without the
slightest insight in the workings of a C compiler. But I do expect some
elaboration on behalf of a program's makers whenever something special
needs to be done. In that respect, the otherwise excellent Virgil
documentation is, to say the most, terse.

So I decided to put my experiences onto virtual paper. I don't mean to
criticize anyone here, just see it as a collection of hints towards
enhanced user-friendliness.

The docs state that:

"Java uses an environment variable called $CLASSPATH to search for the
classes of an application. In order to run the Virgil compiler, you will
need to set this environment variable to point to the compiler/bin
directory under the virgil directory."

As it turns out, compiling Virgil also requires the CLASSPATH env. var.
to be set:

Without CLASSPATH set:

--------------------------------------------------------------------------
exocat at aurora:~/virgil-03/compiler$ make
javac -source 1.5 -d bin `find src/vpc src/cck -name '*.java'`
src/vpc/Compiler.java:36: error: Can't find default package ‘cck.util’.
Check the CLASSPATH environment variable and the access to the archives
src/vpc/Compiler.java:41: error: Package ‘vpc.sched’ not found in
import.
...
--------------------------------------------------------------------------

I am not sure which javac is being used here, but I am able to execute 
make successfully in the compiler/ directory with an empty $CLASSPATH 
variable. Maybe to be safe I should state in the documentation to set it 
before compilation.

With CLASSPATH set:

--------------------------------------------------------------------------
exocat at aurora:~/virgil-03/compiler$ export
CLASSPATH="/home/exocat/virgil-03/compiler/src"
exocat at aurora:~/virgil-03/compiler$ make
javac -source 1.5 -d bin `find src/vpc src/cck -name '*.java'`
src/vpc/Compiler.java:152: error: Invalid declaration.
         for (String f: files) c.addFile(f);
...
--------------------------------------------------------------------------

> Looks better, but still produces errors. Unsettling detail: "javac
-source 1.5 .." vs. the actual jvm dir used: 
/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0

It seems that error is due to the foreach syntax, which means that the 
java 1.5 features need to be enabled with a command line flag. I.e. an
old javac that expects java 1.4 code.

> Let's not dwell on GNU/Debian version numbering..;). But I clearly have
[an equivalent of] Java 1.5 installed. GNU people hate man pages because
they think that info(1) is better, so the javac(1) manpage refers to the
javac(1) manpage (unbelievable). There's also a reference to gcj-4.1(1),
which reveals that gcj(1) does not understand a "-source" option. And as
javac(1) explains: "Options different for javac(1) and gcj(1) are
translated". It doesn't mention those options however, let alone what
they are translated to. So the 1.4 vs. 1.5 hypothesis must remain
unconfirmed, at least from the part of the available documentation.

Anyway, let's just see if there is a Jave 1.5 .deb available. Just
trying it out won't hurt (hopefully). Thank heavens for those unpaid
souls who care to share their experiences and write instructions, like
http://www.crazysquirrel.com/computing/debian/java.jspx.

Alarming sidenote: "Installing Java on Debian is not the simplest thing
in the world [...]". Sounds promising. Getting the right Sun package
proves to be rocket science in its own right - just don't use Sun's
front door. Finally, after following these instructions and some
additional cramps, 1.5 is installed:

--------------------------------------------------------------------------
exocat at aurora:~/virgil-03/compiler$ make
javac -source 1.5 -d bin `find src/vpc src/cck -name '*.java'`
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
--------------------------------------------------------------------------

That seems to work. Changing the CLASSPATH line in ~/.bashrc:

export CLASSPATH="/home/exocat/virgil-03/compiler/bin:$CLASSPATH"

Now using the command from the docs:

--------------------------------------------------------------------------
exocat at aurora:~/virgil-03/compiler$ java vpc.Compiler
Virgil Prototype Compiler [Release B-03]
Copyright (c) 2004-2007, Regents of the University of California
All rights reserved.

Usage: vpc [options] <files>
Usage: vpc -help [category]

Unexpected exception: class java.lang.NoClassDefFoundError
java.lang.NoClassDefFoundError: vpc.sched.AutoScheduler
    at java.lang.Class.initializeClass(libgcj.so.7)
    at java.lang.Class.isAssignableFrom(libgcj.so.7)
    at vpc.Help.addSubCategories(Help.java:260)
    at vpc.Help.buildCategories(Help.java:117)
    at vpc.Help.printHelp(Help.java:73)
    at vpc.Compiler.main(Compiler.java:105)
Caused by: java.lang.ClassNotFoundException: java.util.Queue not found
in
gnu.gcj.runtime.SystemClassLoader{urls=[file:/home/exocat/virgil-03/compiler/bin/,file:/home/exocat/virgil-03/compiler/src/,file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
    at java.net.URLClassLoader.findClass(libgcj.so.7)
    at java.lang.ClassLoader.loadClass(libgcj.so.7)
    at java.lang.ClassLoader.loadClass(libgcj.so.7)
    at java.lang.Class.forName(libgcj.so.7)
    at java.lang.Class.initializeClass(libgcj.so.7)
    ...5 more
--------------------------------------------------------------------------

> When will this end? Will it??

I think you will be better off if you stay away from gcj in all of its 
incarnations. Use the Sun JDK. From the stacktrace, it is clear that the 
exception you are getting is inside of gcj's class loading mechanism. It 
most likely is not able to resolve pre-compiled classes correctly.

> I do intend to be sarcastic or otherwise negative here, and a lot of the
quirks described above have nothing to d with Virgil itself. I'm also
not going to question the choice for writing Virgil in Java, of all
languages. I write software myself from time to time, mostly in the for
of shell scripts, and I've more than once experienced the "pleasure" of
being told that "you MUST use XML!!" and stuff like that. I just don't
get the impression that the writers of Virgil realize what they're
expecting from their users. From the docs it all seems pretty obvious,
in reality it definitely isn't.

It's unfortunate that the java installation process didn't go so well. I'm 
not sure what the problem is. For my other projects, it mostly "just 
works" (then again, this is the first project I've released that relies on 
Java 5--perhaps that is the issue).

>From what I've seen, I believe that Virgil is an excellent programming
language with great internal features that I haven't even heard of. But
setting it up is another story. What lacks in the first place is a
comprehensive guide to installing Virgil onto various platforms. I'd be
happy to add my part and share my experiences, as I'm already doing
right now.

Yes, it looks like there need to be more clear instructions on how exactly 
to get Java up and running, if it is not already.

> I really need something that can bridge the AVR-libc/BASCOM gap, and it
does look like I've found something that does. I just don't see myself
"selling" Virgil to my Windows-oriented peers, at least not this way
(and from what I've seen about how gcc is run on Windows, I fear the
worst..). On the other hand, some of these kiddos will soon be learning
languages like C++ and (yes!) Java, some already have, and Virgil
obviously does comply better with these languages than QBASIC-based
BASCOM does. From a language point of view, it just seems the obvious
choice.

> Any suggestions on how to make an anything-to-Virgil transition happen
more smoothly? As said, I'm willing to put my share of energy into
writing documentation, install scripts, installation packages (not my
favorite pastime, but nonetheless..), whatever. And, of course: why am I
still getting errors?

Try to get the Sun JDK 5 working on your machine; forget about gcj, it's 
crap. If the Sun JDK doesn't work, try the IBM Java 5 JDK for linux. I 
have tested the compiler with that one and it does work.

As for helping others install, if you were to write a webpage, I could 
link to it from the Virgil site.

For the Virgil documentation, I should have a page that simply notes the 
syntactic differences between Virgil and C, and Virgil and Java. That can 
be a bit of a hangup for beginning programmers, but after some 
familiarity, the Virgil syntax makes more sense (and straightens code out 
a bit).

Also, Virgil doesn't really force you to go object-oriented right away. 
Because there aren't a pile of built-in classes you use, you can make your 
own. You can stick to components with global fields and methods as needed. 
That should make the transition from procedural to object oriented easier 
for C people.

For AVR people, the drivers that are already built should be documented 
better so that people can get up and running right away, too.

> Looking forward to making Virgil installation and usage a bit more
poetic,

It's going to be a rough two months for me, so don't get discouraged if I 
can't get to these things right away. Feel free to email me with more 
questions.

Hope this helps,
-B