We Keep Coding

How to install apache mahout on mac?

I am new to Mahout. I want to install it and try it out. So far I have Maven3 and Java 1.6 installed and configured on my Mac. My question is:
Do I have to install Hadoop firstly before installing Mahout?
Some tutorials include installing Hadoop and some not which confuse me. I know Mahout is built on top of Hadoop. But not all of Mahout depends on Hadoop.
Can someone provide some useful detailed resources about installation?

http://chimpler.wordpress.com/2013/02/20/playing-with-the-mahout-recommendation-engine-on-a-hadoop-cluster/
http://chimpler.wordpress.com/2013/03/13/using-the-mahout-naive-bayes-classifier-to-automatically-classify-twitter-messages/
these 2 links helped me get up and running on OSX. It's not strictly necessary to use hadoop with mahout, however almost certainly it would be useful to gain experience with both as you go, if you are planning to use in a scalable system ...

Giving another answer to this question now that it's two years later and I finally got an itemsimilarity command to run on a mac after a lot of cursing and some blood spilled... Hope this saves someone some time and misery. Except my coworkers! Your weakness disgusts me! Anyway...
First for the "do I need $FINICKY_BIG_DATA_PLATFORM" question, see:
http://mahout.apache.org/users/basics/algorithms.html
Hadoop and/or spark are not hard requirements, some algorithms run on a single machine. But, the algorithm you may be interested in may only run on hadoop and/or spark. The docs on recommendations also steer you pretty strongly toward running the spark based algorithms. They also encourage you to use the black box command line commands, which can have different arguments between the single machine and spark versions (itemsimilarity, for example). So you don't NEED it, but you'll probably still need it.
I tried brew installs of hadoop, apache-spark and mahout. If you use the absolute latest versions (mahout 0.11.0, apache-spark 1.4.1, hadoop 2.7.1), you may have some of these problems:
" Got error Cannot find Spark class path. Is 'SPARK_HOME' set? " To fix this, not only do you need to have that environment variable set (mine is set to "/usr/local/Cellar/apache-spark/1.4.1/libexec"), you also need the apparently now deprecated compute-classpath.sh script in ${SPARK_HOME}/bin/ . I had a 1.2.0 spark installation handy, so I lifted one from there.
Bonus gotcha, in that 1.2.0 install there are two compute-classpath.sh scripts, one is just a one-liner invoking the other. You will probably be happier if you copy over the "real" one, so use less to check.
" java.lang.UnsatisfiedLinkError: no snappyjava in java.library.path " To fix this, the Internet will tell you to get a copy of libsnappyjava.jnilib , put it in /usr/lib/java and rename it libsnappyjava.dylib . I did "brew install snappy," which installed version 1.1.3 and included symlinks named libsnappy.dylib and libsnappy.jnilib. Note that these are just symlinks and that the names aren't quite right... So after copying and renaming the main lib file I at least got a new error, which brings us to...
" Exception in thread "main" java.lang.UnsatisfiedLinkError: org.xerial.snappy.SnappyNative.maxCompressedLength(I)I " The Internet was less forthcoming with suggestions. I did see one post saying that version 1.0.xxx didn't have whatever magic pony code but version 1.1.1.3 did. I went to http://central.maven.org/maven2/org/xerial/snappy/snappy-java/ , downloaded snappy-java-1.1.1.3.jar and dropped that as-is into /usr/lib/java , no name changes. This made the snappy errors go away and I could run a "mahout spark-itemsimilarity" command to completion, YMMV, this advice is provided as-is with no warranty.
Please note that snappy error induced despair may drive you to download the spark .tgz and build it from scratch. The build process will take up ~2 hours of your life that you will never get back and you will still get snappy errors at the end. Ultimately I could run the same command with this hand-built version as with the brew installed version, the snappy jar ended up being the main thing.

You don't need hadoop at all to try out mahout. Below is a sample code which take model as input from a file and will print recommendations.
package com.ml.recommend;
import java.io.File;
import java.io.IOException;
import java.util.List;
import org.apache.mahout.cf.taste.common.TasteException;
import org.apache.mahout.cf.taste.impl.model.file.FileDataModel;
import org.apache.mahout.cf.taste.impl.neighborhood.NearestNUserNeighborhood;
import org.apache.mahout.cf.taste.impl.recommender.CachingRecommender;
import org.apache.mahout.cf.taste.impl.recommender.GenericUserBasedRecommender;
import org.apache.mahout.cf.taste.impl.similarity.PearsonCorrelationSimilarity;
import org.apache.mahout.cf.taste.model.DataModel;
import org.apache.mahout.cf.taste.neighborhood.UserNeighborhood;
import org.apache.mahout.cf.taste.recommender.RecommendedItem;
import org.apache.mahout.cf.taste.recommender.Recommender;
import org.apache.mahout.cf.taste.similarity.UserSimilarity;
public class App {
public static void main(String[] args) throws IOException, TasteException {
DataModel model = new FileDataModel(new File("data.txt"));
UserSimilarity userSimilarity = new PearsonCorrelationSimilarity(model);
UserNeighborhood neighborhood = new NearestNUserNeighborhood(3,
userSimilarity, model);
Recommender recommender = new GenericUserBasedRecommender(model,
neighborhood, userSimilarity);
Recommender cachingRecommender = new CachingRecommender(recommender);
List<RecommendedItem> recommendations = cachingRecommender.recommend(
1000000000000006075L, 10);
System.out.println(recommendations);
}
}

JNA Capturing every window : java.lang.AbstractMethodError

I tried to reproduce the attempt to make a capture of a window following :
Java - Window Image
(2 years old post)
I'm using JNA 3.5.0 and tested the unmodified code under XP and 7 with jre 7, and both failed with the same trace :
Exception in thread "main" java.lang.AbstractMethodError:
com.sun.jna.Structure.getFieldOrder()Ljava/util/List;
at com.sun.jna.Structure.fieldOrder(Structure.java:831)
at com.sun.jna.Structure.getFields(Structure.java:857)
at com.sun.jna.Structure.deriveLayout(Structure.java:983)
at com.sun.jna.Structure.calculateSize(Structure.java:908)
at com.sun.jna.Structure.calculateSize(Structure.java:896)
at com.sun.jna.Structure.allocateMemory(Structure.java:357)
at com.sun.jna.Structure.<init>(Structure.java:191)
at com.sun.jna.Structure.<init>(Structure.java:180)
at com.sun.jna.Structure.<init>(Structure.java:167)
at com.sun.jna.Structure.<init>(Structure.java:159)
at com.sun.jna.platform.win32.WinDef$RECT.<init>(WinDef.java:320)
at Paint.capture(Paint.java:24)
at Paint.<init>(Paint.java:71)
at Paint.main(Paint.java:64)
To reproduce it simply just run :
import com.sun.jna.platform.win32.WinDef.RECT;
public class Test {
public static void main(String[] args) {
RECT rect = new RECT();
}
}
If I understand JNA correctly, com.sun.jna.platform.win32.WinDef should be mapped to a system DLL by default.
It seems that the mapping is not correctly done.
I tried to figure out how to map WinDef to needed dll but couldn't find out how to do this with com.sun.jna.Native.loadLibrary method.
I don't understand why a AbstractMethodError is thrown instead of an UnsatisfiedLinkError, so I'm not sure the library loading is really the problem.
Instanciating com.sun.jna.Structure causes the exception, bug I didn't find any information on wether it could be fixed by a native library loading or it is a bug that has another cause.
I thought it could be Windows rights (admin) that my application doesn't acquire.
Or maybe I have to explicitely precise some pathes to jna so that he can find the dlls (but as I said before, it is no UnsatisfiedLinkError so it shouldn't be that).
If you have any experience with JNA and can give me some advice, please answer me.
Given the stacktrace, the understanding of JNA libraries I acquired so far, hours of searches and javadoc exploring, I obviously missed something that a JNA average user could probably find it (the original post is qualified of "Working example").
By the way, if you have any links or resources about jna (didn't find many), please post them :)
Thanks in advance !

I don't know why but it works for me with JNA 3.4.0.
You can find it on MavenRepository http://mvnrepository.com/artifact/net.java.dev.jna
Thanks for your attention

The first line of the error
Exception in thread "main" java.lang.AbstractMethodError:
nearly always indicates a linkage error, that you're using incompatible versions of something.
In this specific case, it appears that platform.jar file released in JNA 3.5.0 was not properly updated.

new Rengine(...); fails without error

I'm trying to set up JRI with Eclipse on a Windows 7 x64 system. I tried it once on my Laptop and it worked. Now on my Desktop it fails although everything of the R, rJava and JRI installation is exactly the same.
I set the JRI and R Paths correctly to:
C:\Program Files\R\R-2.15.1\library\rJava\jri;C:\Program Files\R\R-2.15.1\bin\x64
Also I set R_DOC_DIR etc in Eclipse.
Every time I try to run new Rengine(...); it fails without any error or exception. Debugging revealed an: <terminated, exit value: 10>C:\Program Files\Java\jre6\bin\javaw.exe (01.10.2012 18:00:31)
Is there anything I can try? It really bothers me that it works an my Laptop but not on my Workstation despite the same settings everywhere.
Edit: The code that is used to get the Rengine object.
public static Rengine getRengine(){
if (re == null) createRengine();
return re;
}
public static void createRengine(){
if (re!=null) return;
try{
if (!Rengine.versionCheck()) {
System.err.println("** Version mismatch **");
System.exit(1);
}
String[] arguments = {"--save"};
re=new Rengine(arguments, false, null);
if (!re.waitForR()) {
System.out.println("Cannot load R");
return;
}
}
catch (Exception e){
e.printStackTrace();
}
}
Edit: The last time i tried it i got an errormessage (creating of the REngine worked, this happened never before), R was missing a registryentry. After installing R 2.15.1 again it suddenly worked. Now after a restart it's the same like before. The program crashes at the creation of the REngine.

I was having the exact same problem. It turns out I had unchecked the box that asks to make a registry entry with the R version number. Once I let the installer run with that box checked, it seemed to work.
I would make sure your regedit looks like this:
Next up: getting this working in a portable way...

I am using R 3.2.2 and eclipse Mars on Windows 10 x64.
I faced the described issue today and tried around a bit. Finally, I found the root cause in the build path. Please check whether the following conditions are fulfilled:
1.) The following Java libraries from the JIRI folder on your hard disk shall be included as (user) libraries:
JIRI.jar
REngine.jar
JRIEngine.jar
2.) The native library jiri.dll is located in the subfolder "i386" for x86, whereas for x64 it is available in the subfolder "x64". The relevant one shall be added as separate native library location to the Java Build Path of the eclipse project. Otherwise, the file may not be considered as it is not located in the main JIRI folder.
Best regards
Philipp

How to run a Mac application From Java?

I tried the code below to run a stand-alone utility app I created from Apple script but, I get a No File or Directory Exists error.
I put identical copies (for testing) in the project, dist, parent directories but, it didn't help.
So, my questions are:
Is my call to run the app bad (perhaps because it's not a Windows exe)?
How to run a mac app from java?
Thanks
private void jButton1ActionPerformed(java.awt.event.ActionEvent evt) {
// TODO add your handling code here:
Runtime r=Runtime.getRuntime();
Process p=null;
String s="MyLineInInput.app";
try {
p = r.exec(s);
} catch (IOException ex) {
Logger.getLogger(AudioSwitcherView.class.getName()).log(Level.SEVERE, null, ex);
}
}

A Mac App Bunde is not an executable file, it's a folder with a special structure. It can be opened using the open command, passing the App Bundle path as an argument: open MyLineInInput.app.
EDIT:
Even better would be using Desktop.getDesktop().open(new File("MyLineInInput.app"));

I used the Runtime.getRuntime().exec() method with the open command mentioned in the selected answer. I didn't use Desktop.getDesktop().open() since it unwantedly opened a terminal in my case and I didn't want to create an extra File object.
Process process = Runtime.getRuntime().exec("open /System/Applications/Books.app");
Reason for adding '/System':
It seems we need to use the /System prefix for System apps. For user-installed apps, that's not required, and it can be like /Applications/Appium.app.
To answer #Pantelis Sopasakis' issue that I also faced initially -
I get the error message: java.lang.IllegalArgumentException: The file: >/Applications/Microsoft Office 2011/Microsoft\ Excel.app doesn't exist.
In this case, it could be simply due to not escaping the space characters in the path.
Environment: JDK 11 Zulu - macOS Monterey 12.2.1 - M1 Silicon

MidiUnavailableException in Java?

I'm having some trouble playing MIDI files in Java. What I get is a MidiUnavailableException (MIDI OUT transmitter not available) when I try to play it. My code is standard:
try {
midiseq = MidiSystem.getSequencer();
midiseq.open();
midiseq.setSequence(MidiSystem.getSequence(sound1));
midiseq.setLoopCount(Sequencer.LOOP_CONTINUOUSLY);
midiseq.start();
} catch (Exception e) {e.printStackTrace();}
midiseq is a Sequencer; sound1 is an InputStream.
This code works on several other computers, and even works in Eclipse and when used in a JAR file, just not when I launch it from the command prompt. I've downloaded a more stable Java midi application, and it threw the same exception.
It can't be a hardware problem because Eclipse can run it without problems, neither can it be a coding problem because this runs correctly on other computers. Even this one line of code throws this exception:
javax.sound.midi.MidiSystem.getSequencer();
Thanks in advance.
edit: My operating system is Windows Vista. Before I asked this question I've downloaded the latest JRE and JDK (1.6.0_13 I think).
edit: The code:
ClassLoader.getSystemClassLoader().loadClass("com.sun.media.sound.RealTimeSequencer");
System.out.println( "Sequencer class loaded" );// Otherwise ClassNotFoundException
prints "Sequencer class loaded."
But this code:
try{
System.out.println(javax.sound.midi.MidiSystem.getSequencer());
System.exit(0);
} catch(Exception e) {
throw new RuntimeException(e);
}
System.exit(1);
throws the MidiUnavailableException.
Also, this code:
MidiDevice.Info[] devices = MidiSystem.getMidiDeviceInfo();
if (devices.length == 0) {
System.out.println("No MIDI devices found");
} else {
for (MidiDevice.Info dev : devices) {
System.out.println(dev);
}
}
gives me this:
Microsoft MIDI Mapper
Microsoft GS Wavetable Synth
Real Time Sequencer
Java Sound Synthesizer

First have a look at the capabilities of your system:
MidiDevice.Info[] devices = MidiSystem.getMidiDeviceInfo();
if (devices.length == 0) {
System.out.println("No MIDI devices found");
} else {
for (MidiDevice.Info dev : devices) {
System.out.println(dev);
}
}
If there is nothing there, you might need to install soundbanks to enable the
jvm to create a software sequencer.
Also check the output of MidiSystem.getReceiver() as the dreaded MidiUnavailableException will also occur if a receiver can not be created (MidiSystem javadoc).
I expect that installing the soundbank file will give the jvm the opportunity to fall back on a synthesizer receiver, and not require hardware access anymore (which seems to fail:)

Is it possible that it has something to do with permissions? If you're running the JAR file as a different (more privileged) user than the plain command-line program, that might explain the difference. If it's not that, maybe some Java system property... I can't think of anything else that would make a difference between running the same code as a JAR file or as individual .class files.
It might help if you edit the question to provide more details about the different ways you've been running the program.

WHen launching from the command prompt makes it fail, but launching from a JAR works, I'd check if you really use the same Java version for both cases. For the Jar, check file associations in Windows Explorer, and for the commandline, check whether java -version outputs the expected version (if not, dig through your PATH variable).

Also (another shot in the dark), can you try and do a hard-shutdown on any other application that may be using sound and specifically Midi devices? I know that people get this problem on some Linuxes when another application uses Midi and doesn't release it.

When you have JMF2.1.1e installed, remove all sound.jar files which are not only installed in the JMF directory but also in the jre and jdk directories.
http://www.coderanch.com/t/274513/java/java/javax-sound-midi-compatibility-JMF says:
The problem is the file sound.jar Find it in 3 places and delete it.
C:\Program Files\JMF2.1.1e\lib\sound.jar
C:\Program Files\Java\jdk1.6.0_07\jre\lib\ext\sound.jar
C:\Program Files\Java\jre1.6.0_07\lib\ext\sound.jar
Also, remove sound.jar reference from PATH and CLASSPATH
This is an old sound.jar that messes up the new sound API in the new versions of Java.

Could you add your operating system and java version?
And post the exception; Java generally does a fair job saying whats wrong. It's just not always easy to understand :)
On my mac with java 1.5.0_16 I don't get an exception (on the command line).
The following program
public class MidiTester {
public static void main(String[] args) {
try{
System.out.println(javax.sound.midi.MidiSystem.getSequencer());
System.exit(0);
} catch(Exception e) {
throw new RuntimeException(e);
}
System.exit(1);
}
}
prints
com.sun.media.sound.RealTimeSequencer#d08633
You could check whether you have the sequencer class on the classpath:
ClassLoader.getSystemClassLoader().loadClass("com.sun.media.sound.RealTimeSequencer");
System.out.println( "Sequencer class loaded" );// Otherwise ClassNotFoundException
This would at least make it clear whether you do not have the classes (in the java accessed via the PATH), or whether it's something different like a permission problem.

Point explorer to your JRE folder (the one above the bin folder on the $PATH you are using to run the program) e.g. "C:\Program Files\Java\jre1.6.0"
Go into the \lib folder. Do you see a folder called "audio"? Does it have anything in?
If not, go to http://java.sun.com/products/java-media/sound/soundbanks.html
download any of the MIDI banks as described, and copy it into the said folder.
let us know if it works!

I've found the same problem: unable to play MIDI. But I've noticed that the problem had started when I upgrade the JDK from 1.6.0_10 to 1.6.0_13.
I tested both JDKs with the simple program:
public class MidiTester {
public static void main(String[] args) {
try{
System.out.println(javax.sound.midi.MidiSystem.getSequencer());
System.exit(0);
} catch(Exception e) {
throw new RuntimeException(e);
}
System.exit(1);
}
}
JDK 1.6.0_10 gave the result:
com.sun.media.sound.RealTimeSequencer#1bd747
JDK 1.6.0_13 gave the result:
Exception in thread "main" java.lang.RuntimeException: javax.sound.midi.MidiUnavailableException: MIDI OUT transmitter not available
at ivan.seaquest.MidiTester.main(MidiTester.java:10)
Caused by: javax.sound.midi.MidiUnavailableException: MIDI OUT transmitter not available
at com.sun.media.sound.AbstractMidiDevice.createTransmitter(AbstractMidiDevice.java:444)
at com.sun.media.sound.AbstractMidiDevice.getTransmitter(AbstractMidiDevice.java:299)
at javax.sound.midi.MidiSystem.getSequencer(MidiSystem.java:451)
at javax.sound.midi.MidiSystem.getSequencer(MidiSystem.java:348)
at ivan.seaquest.MidiTester.main(MidiTester.java:7)
I'm going to create a bug at Sun. I hope it helps...

I have had the same problem. The error was caused by JMF included in the classpath.