I have a method called setSound() which is setting up a queue and adding a track to it and then playing it. I call the method in simpleInitGame(). However no sound plays and the console in eclipse says:
Mar 13, 2012 10:15:55 PM com.jmex.audio.openal.OpenALSystem setupSourcePool
INFO: max source channels: 32
Mar 13, 2012 10:15:55 PM com.jme.util.resource.ResourceLocatorTool locateResource
WARNING: Unable to locate: src/com/preston/sounds/background.ogg
Mar 13, 2012 10:15:55 PM com.jmex.audio.openal.OpenALSystem createAudioTrack
WARNING: Could not locate audio file: src/com/preston/sounds/background.ogg
Here is the method:
protected void setSound()
{
audio = AudioSystem.getSystem();
sound1 = audio.createAudioTrack("src/com/preston/sounds/background.ogg", false);
queue = AudioSystem.getSystem().getMusicQueue();
queue.setCrossfadeinTime(0);
queue.setRepeatType(RepeatType.ONE);
queue.addTrack(sound1);
queue.play();
}
I don't think it's the directory as my textures are in the same directory (except instead of preston/sounds its preston/textures).
this is most probably a problem with your relative path. The default directory of the ResourceLocatorTool in jMonkeyEngine is not the root of your project. Try to open it with an absolute path and see if it works.
Also, the location of your file is not a wise choice. The src folder is intended for java source files, not resources. You should put them in assets/Sounds. See jME best practices
Most likely you can omit the "src/" prefix. The Eclipse compiler will compile all java files into class files and in addition copy the resources from your sources to "bin/".
I think JME then uses ClassLoader.getResourceAsStream(...) to load assets from the classpath. So, try removing "src/".
Related
I installed and registered Sencha Architect 4.3.2.19. However, after I created a new classic ExtJs 7.6.0 project, it doesn't initialize Cmd properly, and in the command output I see:
Exception in thread "Thread-15"
com.sencha.exceptions.BasicException: com.sencha.exceptions.ExState: Directory C:\Users\costa\Documents\Architect\frameworks/ext76/7.6.0.41/commercial does not contain a valid framework.
at com.sencha.tools.server.service.tasks.DispatchTask.execute(DispatchTask.java:55)
at com.sencha.tools.server.service.tasks.BaseServiceTask$1.run(BaseServiceTask.java:42)
at com.sencha.util.ThreadUtil$1.run(ThreadUtil.java:65)
at com.sencha.util.ThreadUtil$2.run(ThreadUtil.java:162)
at java.base/java.lang.Thread.run(Thread.java:1589)
Caused by: com.sencha.exceptions.ExState: Directory C:\Users\costa\Documents\Architect\frameworks/ext76/7.6.0.41/commercial does not contain a valid framework.
at com.sencha.command.app.AppCommands$InitCommand.validateEnvironment(AppCommands.java:1874)
at com.sencha.command.app.AppCommands$InitCommand.execute(AppCommands.java:1750)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
at java.base/java.lang.reflect.Method.invoke(Method.java:578)
at com.sencha.util.MethodInvoker$Arguments.invoke(MethodInvoker.java:175)
at com.sencha.cli.Command.dispatch(Command.java:43)
at com.sencha.command.BasePluginCommands$BasePluginCommand.dispatch(BasePluginCommands.java:289)
at com.sencha.cli.Commands.dispatch(Commands.java:64)
at com.sencha.cli.Commands.dispatch(Commands.java:64)
at com.sencha.command.Sencha.dispatch(Sencha.java:80)
at com.sencha.cli.AbstractCommand.dispatch(AbstractCommand.java:124)
at com.sencha.tools.server.service.tasks.DispatchTask.execute(DispatchTask.java:52)
... 4 more
The Cmd base directory is set to: C:\Users\costa\bin\Sencha\Cmd which contains the subdirectory 7.6.0.87.
Any idea on how to fix the exception? Time to open a ticket?
Edit: I've got the previous error on Windows 2016. I just gave SA 4.3.2.19 for macosx a try. It has a different problem. I created a blank ExtJs 7.6.0 Modern project. When I save the project in the folder I get (I set the app name to App) :
/Users/costa/bin/Sencha/Cmd/7.6.0.87/extensions/sencha-service/shell-wrapper.sh: line 41: cordova: command not found
/Users/costa/bin/Sencha/Cmd/7.6.0.87/extensions/sencha-service/shell-wrapper.sh: line 41: phonegap: command not found
[INF] Initializing empty workspace at /Users/costa/Documents/development/javascript/TestAppModern01
[INF] Copying framework to /Users/costa/Documents/development/javascript/TestAppModern01/ext
[INF] Added framework ext to workspace.json
[ERR] The specified string cannot be converted into a valid namespace identifier
Exception in thread "Thread-61" com.sencha.exceptions.BasicException: com.sencha.exceptions.ExState: Invalid namespace : App
at com.sencha.tools.server.service.tasks.DispatchTask.execute(DispatchTask.java:55)
at com.sencha.tools.server.service.tasks.BaseServiceTask$1.run(BaseServiceTask.java:42)
at com.sencha.util.ThreadUtil$1.run(ThreadUtil.java:65)
at com.sencha.util.ThreadUtil$2.run(ThreadUtil.java:162)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: com.sencha.exceptions.ExState: Invalid namespace : App
at com.sencha.util.NameUtil.stringToNamespace(NameUtil.java:76)
at com.sencha.command.generator.GeneratorCommands$AppCommand.validateAppName(GeneratorCommands.java:680)
at com.sencha.command.generator.GeneratorCommands$AppCommand.execute(GeneratorCommands.java:420)
at com.sencha.command.app.AppCommands$InitCommand.execute(AppCommands.java:1819)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at com.sencha.util.MethodInvoker$Arguments.invoke(MethodInvoker.java:175)
at com.sencha.cli.Command.dispatch(Command.java:43)
at com.sencha.command.BasePluginCommands$BasePluginCommand.dispatch(BasePluginCommands.java:289)
at com.sencha.cli.Commands.dispatch(Commands.java:64)
at com.sencha.cli.Commands.dispatch(Commands.java:64)
at com.sencha.command.Sencha.dispatch(Sencha.java:80)
at com.sencha.cli.AbstractCommand.dispatch(AbstractCommand.java:124)
at com.sencha.tools.server.service.tasks.DispatchTask.execute(DispatchTask.java:52)
... 4 more
An identical error occurs when I save a classic project.
What am I missing? There seems to be something wrong overall with SA 4.3.2, or maybe it's missing something.
Both versions, windows & macosx, don't allow me to set Build Tools to Enabled. I click Save, I come back to the dialog and Build Tools is set to Disabled.
More than that, I downloaded ExtJs 7.6.0 and unzipped in a local folder, then in the above dialog I chose Complete or Custom Path, I entered the folder where I unzipped ExtJs, clicked Save, came back to the dialog and Build Tools is Disabled again.
Thank you
ok, I found a workaround for the first problem I had on windows. I installed Sencha Cmd from the installer - I don't know if that made a difference or not.
After creating the classic app, and saving it in SA, I went to the command line and I ran inside the project folder: C:\Users\costa\bin\Sencha\Cmd\7.6.0.87\sencha.exe app init -n App -e ..\..\ext760 --classic
You'd have to adjust the parameters according to your needs. I re-opened the project in SA, and it got its brains back. In my case I used a workspace, and the folder for the workspace was 2 levels up from the project folder. I placed the 7.6.0 ExtJs files in the ext760 directory.
Update: I created a ticket with Sencha and they came back with the fix.
The framework code has been incorrectly installed by SA 4.3.2 in this folder: C:\Users\<UserName>\Documents\Architect\frameworks\ext76\7.6.0.41\commercial\ext-7.6.0. The solution is to copy the files in this folder one level up, i.e. in C:\Users\<UserName>\Documents\Architect\frameworks\ext76\7.6.0.41\commercial, and then it's going to work.
We have an application that makes a backup of a configuration file by copying it to a sub-folder (see log file entry below) using the following command:-
BOOL b = MoveFileEx(ExistingFileSpec, NewFileSpec, MOVEFILE_REPLACE_EXISTING | MOVEFILE_WRITE_THROUGH | MOVEFILE_COPY_ALLOWED);
This appears to work as expected on most systems but on two we get the following warning in our log file:-
11 Jun 2018 10:58:05.437 W. COMMON WARNING MoveFile failed on C:\Program Files\Configuration\Stores.xml to C:\Program Files\Configuration\Backup\Stores.xml LastError=183
Lasterror =183 means "ERROR_ALREADY_EXISTS"
This is odd since MOVEFILE_REPLACE_EXISTING is specifically meant to enable this command to work when the target file exists.
This is happening on Win7 x86 machines.
In a previous version of the code MoveFile was used but with a DeleteFile call immediately prior to ensure the target file did not exist. When the code was rolled back to this version it works.
Any suggestions?
here is the command I use on WIndows 10 command shell :
java
-cp .\soot-2.5.0.jar soot.Main
-cp ".;R:\...\OCLRuler\lib;C:\...\jdk1.8.0_144\bin"
-pp -process-dir R:\...\OCLRuler\src\
-src-prec java
-d R:\...\test\soot
-allow-phantom-refs
-main-class OCLRuler
When I execute it, I get the following output:
Soot started on Tue Sep 26 13:28:32 EDT 2017
Warning: java.dyn.InvokeDynamic is a phantom class!
Warning: Main is a phantom class!
Warning: MainMulti is a phantom class!
Warning: oclruler.a_test.MainRawTesting is a phantom class!
... all of them (100+ lines)...
Warning: oclruler.utils.ToolBox is a phantom class!
OCLRuler.java: Class "oclruler.genetics.EvaluatorOCL" not found.
OCLRuler.java: Class "oclruler.genetics.EvaluatorOCL" not found.
Exception in thread "main" soot.CompilationDeathException: Could not compile
at soot.javaToJimple.JavaToJimple.compile(JavaToJimple.java:104)
at soot.javaToJimple.InitialResolver.formAst(InitialResolver.java:117)
at soot.JavaClassSource.resolve(JavaClassSource.java:54)
at soot.SootResolver.bringToHierarchy(SootResolver.java:215)
at soot.SootResolver.bringToSignatures(SootResolver.java:239)
at soot.SootResolver.processResolveWorklist(SootResolver.java:154)
at soot.SootResolver.resolveClass(SootResolver.java:124)
at soot.Scene.loadClass(Scene.java:448)
at soot.Scene.loadClassAndSupport(Scene.java:433)
at soot.Scene.loadNecessaryClasses(Scene.java:1076)
at soot.Main.run(Main.java:167)
at soot.Main.main(Main.java:141)
All libs used in the OCLRUler project are included in OCLRUler/lib and all sources in OCLRuler/src. The output directory is not included in the soot directory. Also, the project does compile (I'm working on and with it). The . directory contains all soot/jasmin/heros jars.
Still, all classes are considered phantoms, and Soot compilation abords because (I guess) it lacks bodies from these classes. I mean that "EvaluatorOCL" (i.e., still guessing, the source of the CompilationDeathException) is a "Phantom class".
What's wrong ?
SHould I add all and every packages in Soot's classpath ?
I've tried all sorts of command line expressions - until I got profundly lost. Anybody has a clue on the matter ?
Thanks a lot.
Edouard
Changed the -pp -process-dir R:\...\OCLRuler\src\ argument for -pp -process-dir R:\...\OCLRuler\
and it seems to work fine... The phantoms are still strolling around, but there are result files in the output folder!
[edit:]
Oups, this is gona become a new question... The ouput files are... EMPTY !!!
As I said, there are still warnings about phantoms and outputs are generated for all files (java and class alike)
Why are they empty ??
[/edit]
This might well be a problem with Soot's source-code frontend, which is heavily outdated by now. I would recommend compiling the .java files to .class and then giving those to Soot.
I am trying to work around the problem described in GRADLE-2293 where generated files are always updated because a timestamp is written to the Eclipse files located in directory .settings by the Gradle plugin which generates the Eclipse project files.
The files contain a header like this which I would like to remove
#
#Fri Mar 27 10:26:55 CET 2015
Currently I am using an Exec task to use the external application sed to cut out lines starting with '#':
task adjustEclipseSettingsFile(type: Exec) {
executable 'sed'
args '-i','-e','s/^#.*//g','.settings/org.eclipse.jdt.core.prefs'
}
eclipseJdt.finalizedBy adjustEclipseSettingsFile
however this adds a dependency on operating system binaries that I would like to avoid.
How can I do this simple removal of lines starting with '#' in a Gradle task without calling external tools?
There are really many ways of doing it, the one with ant is probably most reliable:
task removeLines << {
ant.replaceregexp(match:'^#.*', replace:'', flags:'g', byline:true) {
fileset(dir: project.projectDir, includes: 'lol')
}
}
I have some code that tries to load a C library as follows :-
public ThreadAffinity() {
ctest = (CTest) Native.loadLibrary("ctest", CTest.class);
}
However I get the following error when trying to build the project; The error I get is as follows :-
UnsatisfiedLinkError: Unable to load library 'libctest': liblibctest.so: cannot open shared object file: No such file or directory
at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:166)
at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:239)
at com.sun.jna.Library$Handler.<init>(Library.java:140)
at com.sun.jna.Native.loadLibrary(Native.java:393)
at com.sun.jna.Native.loadLibrary(Native.java:378)
at com.threads.ThreadAffinity.<init>(ThreadAffinity.java:11)
at com.threads.ThreadAffinity.main(ThreadAffinity.java:45)
The current working directory is the root of the project and thats where the so file is located. I also tried modifying the LD_PRELOAD variable to point to my so file; however the error persists.
It works just fine on my OSX where the dylib is located exactly where the so file is currently(project root).
What am I doing wrong?
From the exception:
UnsatisfiedLinkError: Unable to load library 'libctest': liblibctest.so: cannot open shared object file: No such file or directory
It implies you used something like:
public ThreadAffinity() {
ctest = (CTest) Native.loadLibrary("libctest", CTest.class);
}
and not:
public ThreadAffinity() {
ctest = (CTest) Native.loadLibrary("ctest", CTest.class);
}
hence you see the JNA added prefix of lib and postfix of .so added to libctest (liblibctest.so)
LD_PRELOAD is used when you want to prefer one particular version of the same shared library over another, which doesn't apply here.
Define jna.library.path to point to your project root, and JNA should be able to find it.
Also make sure your library has been built as libctest.so and wasn't inadvertently named libctest.dylib.