Swearing at java

I've got what I consider quite a ways to building a McWire RepStrap. I've got the steppers and the board to power them - scavanged from the dumpster at AE here in fort collins, co. Used to be part of a high power radio frequency power supply for etching microchips, but whatever. I've got a friend (a machinist, actually) helping me with construction of the McWire frame, and that's approaching completion. I've got the schematics for the power board (24volt, supplies +24, +15, and +5) and the arduino is hooked up to the right pins.

I tweaked the makefile (hardware/cores/arduino/Makefile) to get Zach Hoeken's arduino firmware to compile and load, because the "arduino" app wouldn't run. It's java and locks on my machine. I've got at least three different implementations of java, and all of them work to one extent or another. I know I'm not the only one fighting these java install/version/etc issues, somebody mentioned in his blog that he finally got it to work by searching the hard drive for "lib/ext" type subdirectories, and installing the j3d stuff into each and every one (found 16 or so) and still doesn't know which one he's running (see [ar5in.tumblr.com] )

I had the host software running at one point, but now it segfaults. Dies while trying to determine the number of processors, if I'm reading the "log" file that java-1.5.0-sun left behind correctly. I don't see a way to attach a file to this post, and don't want to clutter things, so I'll leave it at that.

I'd like to see if the modifications I made to Zach's firmware to handle "coil A state" and "coil B state" instead of "direction" and "step" work, but I can't test that without the host software, because nothing else speaks SNAP.

So two things are irritating me right now:

1. SNAP should be G-code - I could use minicom or such to talk to it with a keyboard and at least see if things are working. And then I could use a host of other software to talk to it too. It's unlikely that the first useful tool I'll mount on my McWire will be a extruder - I'll probably mount my rotozip and try carving some wood.

2. The host software should be written in something for which there aren't multiple conflicting (and variously broken and buggy) implementations. People have mentioned python, and that's got my vote. I've only got one implementation of python on my computer, at it works.

Probably the way to manage the transition (from SNAP and java to g-code and python/something else sensible) is to modify the current reprap host software to talk g-code, and the arduino firmware to talk g-code as well. My fellow java-swearer-at above mentions that he has a partial g-code interpreter for arduino, but doesn't supply a like where I could get to it. Maybe he'll read this and point me at the firmware? (sorry, I could search and figure out your name, but it's late and I'm lazy)

I've concluded from this experience that I hate java. And that I'm done swearing at this thing for the day. I'm really not this grumpy in person, I swear. I've spent about 6 hours just trying to get the reprap host software to run, and that'd be enough to make anybody grumpy, I'd think. This project is fascinating, just what I've been looking for, and I look forward to messing around with all sorts of modifications to it. Figuring out obscure errors isn't the fun part though.

jgilmore,

You fail to state which OS platform you are running on. I'm guessing Windows?? Please,
when posting about host issues, help us to help you by providing enough background info
so that others can assist you.

I'd suggest removing all copies of Java (use the Add/Remove Programs menu from the Control Panel to do this). Then install the current JRE (Sun Java 6 Update 3) from Sun, then the Reprap host code and its libraries.

We (Bruce Wattendorf and I) already have a working Windows installer (a single .exe file) under test that installs the JRE, the Reprap code and the libraries it needs, and the Reprap STLs -- it is looking good. It doesn't remove all your old Java JREs, of course -- that might break other Java apps on your system which need them -- but it seems to work well for fresh installs. If you want to be one if its first testers, let me know. It's not quite ready for public release yet, but it is probably close.

If you uninstall all of your JREs, and any JDKs you may have, and then follow the instructions for setting up the Reprap host code on Windows and still get stuck, please post details of your issue here, and we'll try to help. Running a machine with 16 JAVA_HOME dirs and adding libs under all of them sounds like a recipe for confusion and disaster -- you can be more systematic than that :-)

If you have the software development skills to port the current Java code to Python, that could be an interesting project. I'm not convinced it is worth the work, since Java will become fully open source soon (hopefully during 2008) -- but if someone outside the core team has the time, skill and enthusiasm to do it... go for it!

Meanwhile, do please try my suggestions above and post details of any issue(s) you have getting the host software to work; this is likely to be more effective than swearing at Java!

Jonathan

---

---

Jonathan

Sorry, I'm running debian linux. Actually, I removed sun-java5-* and reinstalled. Same error. Then I installed sun-java6-*, same error. Then I swore at it and gave up. I did manage to bork my install of gcj-java (I forget the package names) and had to remove (--force-all with dpkg) and reinstall to get my gcj jre back.

Personally, I only have three jre's - gcj, sun-java5, and sun-java6. Both of the second two where installed in an attempt to get the reprap host to work. And it did work last week. Maybe this is a bug in j3d?

Here's the section from the .log file that sounds most significant:

#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
# SIGSEGV (0xb) at pc=0x40b2c228, pid=9279, tid=2974305168
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_13-b05 mixed mode, sharing)
# Problematic frame:
# C 0x40b2c228
#




Stack: [0xb1405000,0xb1485000), sp=0xb1481524, free space=497k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C 0x40b2c228
C [libc.so.6+0x667d6] _IO_file_init+0x36
C [libc.so.6+0x5ad40]
C [libc.so.6+0x5adbc] fopen+0x2c
C [libc.so.6+0xd5ccf] get_nprocs+0x2f
C [libc.so.6+0x97e95] __sysconf+0x2c5
V [libjvm.so+0x28f55a]
V [libjvm.so+0x1d3c27]
C [libjava.so+0xc9c9] Java_java_lang_Runtime_availableProcessors+0x19
j java.lang.Runtime.availableProcessors()I+0
j javax.media.j3d.MasterControl.getNumberOfProcessors()I+3
j javax.media.j3d.MasterControl.()V+1010
j javax.media.j3d.VirtualUniverse.()V+216
v ~StubRoutines::call_stub

... i actuall have a similar "NoClassDefFoundError" in javax/vecmath/Tuple3D in Windows XP on a dual-core-Intel ...

At home with WinXP-home and the same install i finally managed to bring it to work after updating my OpenGL-drivers for the Ati-Radeon-Mobile9600 graphics card on my notebook ...

Viktor

Interesting. I have no dual CPU machines I can test on. If this *is* related to number of processors in some way, then booting a uniprocessor kernel might be worth trying as a test?

Alternatively, since it seems to be dying checking how many processors it has -- are you running anything that would prevent the Java VM from opening files under /proc ? Some sort of security hardening, or something?

Lastly: When it worked, which JRE were you using?

Basically, my machines are all so old and have such bad graphics cards that they work fine :-)

Jonathan

---

---

Jonathan

Jonathan,

FYI - I have had no problems with the 0.8.1 host software on a dual core machine (an AMD64 in my case) running Java 1.6 and Ubuntu 7.1. I'll try 0.8.3 tonight and let you know if that works as well.

Joost

Joost,

Thanks. The libraries are all the same, so I'd be surprised
if going from 0.8.1 to 0.8.3 breaks Java or causes new bugs
to appear in the libraries... but a test would be a lot better
than my guesses :-)

BTW, I think you meant Ubuntu 7.10, the "10" is the month of
the release, October.

Jonathan

---

---

Jonathan

Jonathan,

Yes, you're absolutely right - Ubuntu 7.10. I also tested version 0.8.3 and this works fine, it even kept my old properties ;-)

Joost

Joost wrote:

> Yes, you're absolutely right - Ubuntu 7.10. I also
> tested version 0.8.3 and this works fine, it even
> kept my old properties ;-)

Good! Did it add the new ones to your reprap.properties file, too?

One to look for would be:

BaudRate=19200

Jonathan

Jonathan,

Actually, it has not done that. It took the properties file in /home/joost/.reprap, and I can see the properties.dist in the jar file contains some new/additional props, which are thus not loaded nor saved (added) in the old props file. So this does not work.

It might be good to have (1) a version property in the props file that can be checked against the version in the dist file (fallbackPreferences versus mainPreferences), and (2) if there is a version difference (which I guess could be the release version) then the new props can be added from the fallbackPrefs to the mainPrefs via iteration and using the fallback values. This would avoid having to redo the prefs after an update or synch them manually. We could add an updatePreferenceList() method to the Preferences.java. I can give this a shot ...

Joost

Joost Wrote:

> Actually, it has not done that. It took the
> properties file in /home/joost/.reprap, and I can
> see the properties.dist in the jar file contains
> some new/additional props, which are thus not
> loaded nor saved (added) in the old props file.

OK. If you edit a property (maybe switch from cartesian to nullcartesian)
and save the change, does it then add the new ones to reprap.properties?

> It might be good to have (1) a version property in
> the props file that can be checked against the
> version in the dist file (fallbackPreferences
> versus mainPreferences), and (2) if there is a
> version difference (which I guess could be the
> release version) then the new props can be added
> from the fallbackPrefs to the mainPrefs via
> iteration and using the fallback values. This
> would avoid having to redo the prefs after an
> update or synch them manually. We could add an
> updatePreferenceList() method to the
> Preferences.java. I can give this a shot ...

The version check shouldn't be needed, it can *see*
the full set of properties... we just need to make it
write them all out to reprap.properties, if it isn't
doing that now.

If you want to take a look at what it is doing, that
would be fine with me :-)

Jonathan

---

---

Jonathan

Jonathan,

It does not save the correct properties after a change. I will look into the Preferences class and see where a synchronization & check can be inserted.

Joost

Actually, my machine is a single processor AMD athlon. I don't think it was a matter of j3d not knowing what to do with it, because it crashing in libc, before returning the the java enviroment with the number of processors. I can't find any documentation on __sysconf or get_nprocs, which is the functions that java says it was trying to call. The function names given in the stack track for libc may even be completely bogus, and based on erronous assumptions about the structure or placement of functions in libc.

There are no permission issues that I'm aware of, I haven't done anything special with /proc permissions. I also wouldn't expect a permissions issue to give a sigsegv, more likely a corruption issue of some sort.

Since both java5 and java6 give the same error, I'm inclined to think that upgrading some other library is to blame. (consults /var/log/dpkg.log) I did update libc on the 3rd, maybe I shouldn't have done that. I originally installed sun-java5 on the 14th of December, and that worked.

Maybe I'll downgrade libc - sounds like a nightmare - anybody know off the top of their head how to determine which version I was running prior to the 3rd? WAIT! I've got a backup! let me think about this...

jgilmore wrote:

> Since both java5 and java6 give the same error,
> I'm inclined to think that upgrading some other
> library is to blame. (consults /var/log/dpkg.log)
> I did update libc on the 3rd, maybe I shouldn't
> have done that. I originally installed sun-java5
> on the 14th of December, and that worked.

Hmmm. Well, yes, libc is pretty all-pervasive in the
Linux world, so any weirdness there might well affect
Java. I'd expect it to affect other things too, though.
And Debian is usually pretty conservative about updating
to new unproven things, compared to many distros.

> Maybe I'll downgrade libc - sounds like a
> nightmare - anybody know off the top of their head
> how to determine which version I was running prior
> to the 3rd? WAIT! I've got a backup! let me think
> about this...

If you have a spare PC, it might be worth installing
a fresh Debian (or Ubuntu) setup on it and verifying
that you can then install Sun Java, the Reprap host
code, needed libs, and get it to work. That would
give you a basis to compare with as you work to get
your main PC back to a "Java-compatible" state :-)

Jonathan

---

---

Jonathan

Jonathan,

Have you thought of including a JRE with Java3D and RXTX already installed in it with the RepRap-Host software?

I was having support issues with my Java3D application until I started using this technique and it solved most of the problems.

Here is a link to my software if you would like to see how it is packaged:

[sage.math.washington.edu]

If you want to see a Java3D application run in this environment, launch the application using the provided "run" script, switch to the GearBox tab in the application, and follow the instructions in the topmost comment.

If you like this approach, I have an Ant-based build environment you can use that automatically creates the distribution archives. It should be fairly easy to rework the environment to support RepRap-Host.

Ted Kosan

tkosan wrote:

> Have you thought of including a JRE with Java3D
> and RXTX already installed in it with the
> RepRap-Host software?

It's been talked about. It just feels somehow inefficient
and almost "dirty" to have to resort to that! Ubuntu has
existing DEB packages of both Sun Java and RXTX, for
instance... why do we need to be reinventing the packaging
wheel for them? It just doesn't "feel right" given my
many years doing Linux/Unix system admin stuff! Plus,
I have not seen any install issues myself, on multiple
(admittedly all old!) PCs, in either Linux or Windows. So
it is hard to estimate how many of the support issues others
see would be solved by this approach that simply an easier
install process of any kind would not take care of.

> [sage.math.washington.edu]

OK, thanks, I'll take a look. I can definitely learn
something about deeper use of Ant from your work!
Right now I'm side-tracked by creating slides etc for
a Reprap presentation I'm giving this weekend (!), but
once that is done, I expect to get back to packaging
issues pretty seriously.

Jonathan

---

---

Jonathan

fantastic!

for the record, i strongly support a fully integrated package like you suggest.

the entire world doesn't run ubuntu/debian, and having a single package that we can send out and have run on windows/unix/linux/osx that has all the same versions of the various libraries is a huge plus.

i'm definitely going to take a look at that ant script, as we currently use ant as our build platform. very cool.

The link I posted earlier was to the Windows and Linux distribution files. The complete build environment I am using can be download from here:

[206.21.94.60]

The md5 hash for this file is e333a7a2aa60d358a6a5238076a9cd1d

Just type "ant dist" and it should build both the Windows and Linux distribution files.

The ant script is somewhat messy because I have not cleaned it up for release yet, but people should be able to follow what it is doing.

Hope this helps :-)

Ted