3.2.11 is considerably slower again than 3.2.10. Not as much as with the OpenGL problems before, but too slow to use. Drag box for selection, selecting pieces, dragging pieces, drawing large background images, is all visibly and noticeably too slow.
As an added oddity, the prompt dialogs (do you want to save, enter a label value, etc) used to show the VASSAL icon on the left, but now show an OS X folder icon.
Using Memoir '44 Module on OS X 10.9.1, 2.93 GHz Core i7 iMac 27", 8GB RAM (1333 Mhz DDR3), ATI Radeon HD 5750 1024 MB.
3.2.11 is considerably slower again than 3.2.10. Not as much as with the
OpenGL problems before, but too slow to use. Drag box for selection,
selecting pieces, dragging pieces, drawing large background images, is
all visibly and noticeably too slow.
As an added oddity, the prompt dialogs (do you want to save, enter a
label value, etc) used to show the VASSAL icon on the left, but now show
an OS X folder icon.
Using Memoir '44 Module on OS X 10.9.1, 2.93 GHz Core i7 iMac 27", 8GB
RAM (1333 Mhz DDR3), ATI Radeon HD 5750 1024 MB.
Please check in the errorLog what version of Java VASSAL 3.2.11 is
actually using, and also tell us what version you expect it to be
using.
This is exactly what I expected had happend. We made a small change
to the launch script to accomodate old Macs which have only Java 5;
apparently this caused a problem for Macs which have both Java 6 and
Java 7.
Please post the output of the following:
ls -l /System/Library/Frameworks/JavaVM.framework/Versions/
Java 7 is at:
JAVA=“/System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java”
So it will take the current (7) version and launch that before trying JDK 6.
I can’t remember now if this is a normal setup or if I changed this manually for some reason to get something else to work (or attempt to work). Java is a pile of steaming manure . If it’s just me then I’ll change the launch script myself to get it to work.
Edit: I checked on my other Mac with 3.2.12-9013 and it launches with Java 6. So I think it’s just what I did to my iMac that is causing this.
I can’t remember now if this is a normal setup or if I changed this
manually for some reason to get something else to work (or attempt to
work). Java is a pile of steaming manure :(.
Concur. I’ll be so happy to see the back of it. It’s the height of
irony that the time I spend dealing with platform-specific issues these
days is mostly involves a language and libraries which are supposedly
platform-independent.
Edit: I checked on my other Mac with 3.2.12-9013 and it launches with
Java 6. So I think it’s just what I did to my iMac that is causing this.
Yes, I suspect that you adjusted the links yourself. I would argue that
Oracle’s Java 7 ought to do that when it’s installed, but as it
doesn’t, we have to assume that no one will have these.
Anyway, I’m happy to know about the CurrentJDK links—we now check
there as well, so we shouldn’t get any complaints about VASASL not
starting for people with a JDK but no JRE.
Even with that version I get the error message with suggestion I should I install Java SE 6 in spite of having Java 7 already installed.
Vassal 3.2.10 is the latest version working for me at the moment (albeit with terribly laggy scrolling).
Even with that version I get the error message with suggestion I should
I install Java SE 6 in spite of having Java 7 already installed.
Please tell me what all of the symbolic links in your
/System/Library/Frameworks/JavaVM.framework/Versions/ point to. I
can’t make any progress without knowing that.
Vassal 3.2.10 is the latest version working for me at the moment (albeit
with terribly laggy scrolling).
Poor graphics performance with Java 7 happens only on some Macs and
isn’t our bug, so far as I can see. It’s also unlikely to be the kind
of thing we can work around. I think it’s likely that it’s Oracle’s
problem, which doesn’t make me optimistic that it will be fixed. The
solution I see for this is to use Java 6 until VASSAL 4.
[computer]$ l /System/Library/Frameworks/JavaVM.framework/Versions/
total 4
0 drwxr-xr-x 8 root wheel 272 10 Nov 19:57 A/
4 lrwxr-xr-x 1 root wheel 1 10 Nov 19:57 Current@ → A
[computer]$ l /System/Library/Frameworks/JavaVM.framework/Versions/A
total 36
0 drwxr-xr-x 44 root wheel 1496 25 Aug 2013 Commands/
0 drwxr-xr-x 4 root wheel 136 10 Nov 13:45 Frameworks/
0 drwxr-xr-x 3 root wheel 102 25 Aug 2013
JavaPluginCocoa.bundle/
36 -rwxr-xr-x 1 root wheel 99792 10 Nov 19:57 JavaVM*
0 drwxr-xr-x 44 root wheel 1496 10 Nov 19:57 Resources/
0 drwxr-xr-x 3 root wheel 102 25 Aug 2013 _CodeSignature/
[computer]$
This is with 10.9 fresh installation and just Oracle’s Java 7 JRE
installed.
Oh, that’s neat. They have Current/Commands/java pointing to something
which tells you that you don’t have Java. So NOW YOU CAN’T CHECK THAT
TO TELL WHETHER YOU DO! ARGH!
It takes some effort to make it this difficult to determine whether a
program is installed. Apple and Oracle can both go DIAF.
Probably not possible I guess… Signing on Linux I mean… No chance of
access to a Mac or even a Hackintosh? =)
People have figured out some of the Mac tools. E.g., we’re able to build
a compressed DMG on Linux. I’m still rather shocked that nobody’s looked
at what exactly codesign is doing and produced something which does the
equivalent.
We don’t happen to have access to a Mac at present, but even if we did,
I wouldn’t use it for codesigning. I’m not interested in having a build
process which can’t all be done in one place.
Just out of curiosity, what will Vassal 4 be based on instead of Java?
On a standard, so that clients can be written in anything. The reference
implementation that I’m planning will be in C++.
. If it’s just me then I’ll change the launch script myself to get it to work.