When I try to use the AudioSink component design by Axios which can be downloaded from: https://github.com/Axios-Engineering/audio-components
and used as a component is not working outside of the sandbox chalkboard.
I created a SCA Waveform Project with the AudioSink as a component and when I try to launch it with the Device Manager it doesn't launch it because it can't initiate an instance of the AudioSink component.
You can create a simple waveform using 2 components: AudioTestSource and connect this one to the AudioSink and it will not let the Device manager launch the component.
Some help please.
I have tested the components running within the DomainManager in the manner you suggested and they work for me. It will be difficult to isolate the problem without some additional information about your system and the errors you are experiencing.
Here are a few things to check first.
Have you installed the components into the SDRROOT? This can be done by either dragging
the component project in the IDE over to the Target SDR or by running "make install" in
the components folder. You can confirm that they have been installed to doing ls
$SDRROOT\dom\components. In that folder you should see AudioTestSource and AudioSink.
When you attempt to launch the waveform; can you provide the error printout that the
DomainMananger and DeviceManager produced?
Related
I can't get debugging to work.
I'm using the 2.1.0 version of REDHAWK and I'm trying to create custom components.
I can get release version to run and to work.
Here's what I do, I have created a very basic custom component that takes input, multiplies it by two and pushes it to the output stream, super simple. Now I try to run this component in debug mode in sandbox, instant crash. The only this I can see is the last entry of the callstack, which is
boost::shared_ptr<rh_logger::Logger>::operator->() at shared_ptr.hpp:653
If I choose to run my component without debugging, everything works. It even does the multiplication.
I have no idea what goes on, apparently this smart pointer class does a assert check to validate the pointer that it returns and ends up crashing because it's zero. Being the -> operator, this seems quite dangerous. SIGSEGV is the error being throw, I wonder if BOOST_ASSERT causes that on failure?
Operating system is CentOS 7 64 bit and it's running on regular desktop intel processor, can't remember which.
I installed REDHAWK by downloading the repository as instructed in 2.2 part of the REDHAWK manual.
The new component was created with the REDHAWK IDE (eclipse based), I selected C++ as the Program language. It seems to be a shared library and when I run it, a process called ComponentHost is started.
I'm trying to start the component in the sandbox via right-clicking the component in the Project menu and selecting Debug as - Component in the Sandbox. Running the component in the Release mode this way works.
I'm able to debug a component via the Python sandbox, so just a couple of variables to help narrow it down, with my test system in []:
Which operating system? [CentOS 7]
REDHAWK installed from source or RPM? [RPM]
Is this a new C++ shared library-based component (entry point type is "SharedLibrary") or executable ("Executable")? [both]
How are you launching the component? Via the Python sandbox, with with "debugger='gdb'" as an argument to launch? Any other launch arguments?
Another possible debugging approach is to launch the component normally, then attach GDB from another terminal window.
First, find the component process:
If it's a shared library:
ps -o pid,comm -C ComponentHost
If it's an executable (where "" is the component executable's name):
ps -o pid,cmd -C <name>
Hopefully, it's clear which process is your target component. If you're running multiple shared library components from the same sandbox, they will all be part of the same ComponentHost instance.
Then, attach to the process with GDB:
gdb -p <pid>
This is essentially how the sandbox attaches GDB; however, running it independently allows you to set the flow up to your liking first before attaching the debugger.
After getting out of a mode of procastinating, I've finally gotten to the item on the projects todo-list that says "Run on virtual device to see why it crashes".
My project is a libgdx application that I plan on porting to various platforms, the two most important ones being desktop and android.
During development I've exclusively used the desktop launcher, as it's a lot easier to fire up when just checking minor things.
I did build an .apk at one point just to see if it'd run out of the box, but it didn't. Now that I've tried via the virtual device, this is what the log says:
com.badlogic.gdx.utils.GdxRuntimeException: Couldn't load file: rifleman.png
The same goes for any other assets that my game uses. The files are all placed in projectname/android/assets, as I remember learning way back that this was the way to go.
The virtual device I tried with is the stock Nexus 5, but I tried running the .apk by uploading it to my actual phone with a crash right after start, and I assume the problem is the same and is therefore unrelated to the test-platform.
I am currently not using an assetmanager, as implementing this is scheduled for after getting the basic core mechanics up and running. In the mean time I'm loading them as such: new Pixmap(new FileHandle("rifleman.png"));
Using android-studio 2.2 on Linux Mint 17 Cinnamon.
Please comment if more info is needed.
Use Gdx.files.internal() instead of FileHandle().
From filehandle(string) method info
Creates a new absolute FileHandle for the file name. Use this for
tools on the desktop that don't need any of the backends.
Do not use this constructor in case you write something cross-platform.
The default for Eclipse EE seems to be to build java code in build/classes not in WEB-INF/classes or WEB-INF/lib/my.jar. I can create a .war file which has the entire project, but then every time I build, I have to manually generate the war file. My current setup which has the WebContents directory symbolic linked to /var/lib/tomcat7/webapps/ROOT, in which case all the web pages are by definition in the right place, but the code is not there.
I'm willing to take a suggestion on how to get this to happen automatically, but I would like to know WHY there should be the need in the first place? Why would I want to have my build directory for a web application anywhere other than the directory where it should be executed? Is there any way to get eclipse to build the !%*#% class files in a sane place, or is there in fact a reason why an EE app would have code that does not go on the server? Is there something simple that I can add to trigger a rule in ant or mvn to move the code to the right place?
Compounding this problem, I am switching over to Ubuntu (Not that this works under windows at the moment either).
I was getting weird errors, and it turns out I didn't have jdk7 installed.
So I installed it, but how do I even know what java is being used to run tomcat and eclipse? How do I know it will use jdk7 and not the one that was used before? On windows, when I tried to run Eclipse, it gave a straightforward error when Java wasn't installed so this never happened.
I type javac -version and get the correct one, but this does not guarantee that some service like tomcat7 will use the same one.
The error (same on Windows)
An error occurred at line: 3 in the jsp file: /demos/post.jsp
ReadBody cannot be resolved to a type
1: <%# page import="org.adastraeducation.liquiz.servlet.*" %>
2: <%
3: ReadBody b;
4: %>
5: <html>
6: <body>
The current (ridiculous) way to stop this error is:
cd build/classes
jar -cf my.jar org
sudo mv my.jar /var/lib/tomcat7/webapps/ROOT/WEB-INF/lib
sudo service tomcat7 restart
Eclipse Web Tools can manage building and packaging a web-app (WAR) and automatically running it on a local server of your choice. This includes re-deployment when changes are made, debugging, etc. But you have to create or configure your project as a Dynamic Web project for Eclipse to know to do that for you.
For starters, you'll need to either download the Eclipse IDE for Java EE Developers package or use the Eclipse Installer to get it. Then you can peruse the Web Tools help (for example, start here).
I recently started using LWUIT. Great job and great program. I'm using Netbeans 6.9.1, S60 SDK and the webstart version of LCWUIT.
The first problem I faced was that I couldn't preverify Transitions3D.java file , however that was not an issue. I just removed that part of the code and recompiled the library from scratch. So I created a simple form with a "Hello World" Label and tried the "Create Netbeans Project" option of the resource editor. I did a Clean Build at the test_MIDP (where test is the name of my project) and tried to run it on the emulator. However I'm receiving this error message:
TRACE: <at java.lang.RuntimeException: You must include the platform port before the LWUIT in the classpath>, startApp threw an Exception
java.lang.RuntimeException: **You must include the platform port before the LWUIT in the classpath**
at com.sun.lwuit.impl.ImplementationFactory.createImplementation(ImplementationFactory.java:67)
at com.sun.lwuit.Display.init(Display.java:400)
at userclasses.MainMIDlet.startApp(MainMIDlet.java:15)
at javax.microedition.midlet.MIDletTunnelImpl.callStartApp(), bci=1
at com.sun.midp.midlet.MIDletPeer.startApp(), bci=7
at com.sun.midp.midlet.MIDletStateHandler.startSuite(), bci=269
at com.sun.midp.main.AbstractMIDletSuiteLoader.startSuite(), bci=52
at com.sun.midp.main.CldcMIDletSuiteLoader.startSuite(), bci=8
at com.sun.midp.main.AbstractMIDletSuiteLoader.runMIDletSuite(), bci=161
at com.sun.midp.main.AppIsolateMIDletSuiteLoader.main(), bci=26
java.lang.RuntimeException: You must include the platform port before the LWUIT in the classpath
at com.sun.lwuit.impl.ImplementationFactory.createImplementation(ImplementationFactory.java:67)
at com.sun.lwuit.Display.init(Display.java:400)
at userclasses.MainMIDlet.startApp(MainMIDlet.java:15)
at javax.microedition.midlet.MIDletTunnelImpl.callStartApp(), bci=1
at com.sun.midp.midlet.MIDletPeer.startApp(), bci=7
at com.sun.midp.midlet.MIDletStateHandler.startSuite(), bci=269
at com.sun.midp.main.AbstractMIDletSuiteLoader.startSuite(), bci=52
at com.sun.midp.main.CldcMIDletSuiteLoader.startSuite(), bci=8
at com.sun.midp.main.AbstractMIDletSuiteLoader.runMIDletSuite(), bci=161
at com.sun.midp.main.AppIsolateMIDletSuiteLoader.main(), bci=26
"You must include the platform port before the LWUIT in the classpath"
Any ideas on how to fix this error? I tried to run the MIDlet with both S60 and JavaME SDK 3.0 emulator and I received the same error.
StackOverflow warned me that there are similar questions however I couldn't find anything about related to my issue. If not please inform me.
I shall answer my own post:
The problem was that in the UI jar I was including. LWUIT comes with 2 "sets" of UI.jar. The generic one which is in LWUIT\UI folder and the platform specific ones which are in the LWUIT\Ports folder.The generic one is being used as "parent" project containing all the common code,however if you MUST import the .jar file which is for your platform. As readme file says:
While these projects will compile easily they will be useless for any purpose since they don't include the binding glue for the platform, to use the platform one needs to use the appropriate projects underneath the specific ports directory to a given platform.
While I was recompiling the library in order to remove Transitions3D.java file, I recompiled (and then imported ) the generic UI.jar. The correct thing to do is compile, the parent project (the generic UI.jar) THEN compile the port specific library (in my case the LWUIT\ports\MIDP\UI.jar) and then import it in your project and you are done.
I have developed a Java ME application for CLDC platform. It works fine when executed in an emulator. But when i deploy it to my N70 phone the application doesn't start at all in the phone. In my application there are some 14 classes and am creating an instance of each and putting them in the vector on application start. The classes just have one variable and 2 methods. Can this creating of lot of instances be the reason for its crashing?
Is there any way I can find out the reason why the application is not able to start in the phone?
Update:
Its running fine on emulator. And one more thing I would like to mention is that- The code stops executing only at the point where am creating those 14 instances and adding them to the vector. Till that point the code executes fine.
It might depend on where in the code you are creating those instances. If you are creating them in your MIDlet constructor or the startApp method try moving the initialization into the run method of your application.
One way of debugging J2ME applications that don't start on the phone is by adding "printf" style debug messages in your code to be written in the record store system and adding another MIDlet to your application to read from RMS and display those messages.
Or you could just comment bits of code and see if it works.
You can debug on device. If the emulator you are using is part of the Nokia SDK then there should be facilities elsewhere to carry out on-device testing and debugging. (I'd post more detail on this but I've only done this with Sony Ericsson phones recently.)
Another option is to use the Nokia tools that allow you to view the standard output and error for your application when it is running on your device (via Bluetooth for example).
The probability that your application is actually crashing the Java Virtual Machine bytecode interpreter thread and terminating the whole native process is very small.
It has happened before but you need to eliminate several other potential issues before being convinced of an actual crash.
It is more likely that either:
Your MIDlet is not created or not started because the MIDP runtime decides it is not correct.
or
Your MIDlet simply throws an exception that you don't catch, which can make it look like it was brutally terminated.
Since the MIDlet installer is supposed to prevent you from installing a bad MIDlet, the uncaught exception issue is more likely.
How to find an uncaught exception:
Start with the simplest HelloWorld MIDlet, using a Form so you can easily insert more StringItems at the top of the screen.
Create and start a new Thread in MIDlet.startApp()
In your override of Thread.run(), add a try{}catch(Throwable){} block.
Inside that block, do whatever your original MIDlet did.
Use the form as your standard output for debugging.
You can use Form logging to make sure you don't enter an infinite loop, to display exception classes and messages, to flag logical milestones, to display variable values...
That's the first step to figuring out what is going on.
I also faced a similar problem and when I recompiled my MIDLET as Midlet 1.0 then it worked fine. It seems like N70 is not able to run the new version of MIDLET. I think you downgrade and re-test your midlet.
Regards
Junaid