I have just started using the rhostudio plugin for eclipse 3.7.2 on Windows.
I have erroneous code but the console never seems to output error messages.
When I launch the simulator I do get some logs but as soon as it hits a bad line of code it stops logging and the simulator window goes blank.
Can anybody help?
You can increase the amount of log output by changing the log level in:
rhoconfig.txt
in your projects root folder and setting MinSeverity as follows:
# Rhodes log properties
# log level
# 0-trace, 1-info(app level), 3-warnings, 4-errors
# for production set to 3
MinSeverity = 0
# enable copy log messages to standard output, useful for debugging
LogToOutput = 1
Related
I apologize if I'm a bit low on details here, but the main issue is actually trying to find the problem with my code. I'm updating an older extension of my own that was based on the Language Server example (https://code.visualstudio.com/docs/extensions/example-language-server). I've run into an issue where when I run the client part of my code using F5, and the debug window fires, I get:
The CSSLint Language Client server crashed 5 times in the last 3 minutes. The server will not be restarted.
Ok... so... here's the thing. The problems view in my extension client code shows nothing. DevTools for that Code window shows nothing.
The problems view for my server code shows nothing. DevTools, ditto.
For the Extension Developer Host instance, DevTools does show this:
messageService.ts:126 The CSSLint Language Client server crashed 5 times in the last 3 minutes. The server will not be restarted.e.doShow # messageService.ts:126
But I can't dig into the details to find a bug. So the question is - assuming that my server code is failing, where exactly would the errors be available?
Here is what I usually do to track server crashes down (I assume your server is written in JavaScript / TypeScript).
Use the following server options:
let serverModule = "path to your server"
let debugOptions = { execArgv: ["--nolazy", "--debug=6009"] };
let serverOptions = {
run: { module: serverModule, transport: TransportKind.ipc },
debug: { module: serverModule, transport: TransportKind.ipc, options: debugOptions}
};
Key here is to use the TransportKind.ipc. Errors that happen in the server and printed to stdio will then show in the output channel associated to your server (the name of the output channel is the name passed to the LanguageClient)
If you want to debug the server startup / initialize sequence you can change the debugOptions to:
let debugOptions = { execArgv: ["--nolazy", "--debug-brk=6009"] };
If the extension is started in debug mode (e.g. for example launched from VS Code using F5) then the LanguageClient automatically starts the server in debug mode. If the extension is started normally (for example as a real extension in VS Code) then the server is started normally as well.
To make this all work you need a latest version of the LSP node npm module both for server can client (e.g. 2.6.x)
I am running a code in jupyter notebook (here is the code for reference):
import ROOT as root
f = root.TFile("160721_0828.root")
for event in f.tree.events:
print (1)
It should be a simple code, looping through a file. But when I run it, the kernel crushes and I have to restart everything. I also get in terminal many errors of this kind:
2016-08-08 18:25:20.439 atos[99872:272f] Metadata.framework [Error]: couldn't get the client port
0x0000000100000cc4 in start (in python) + 52
before the program crushes. I am using a Mac, version 10.9.5. What could be the cause?
Perhaps your Spotlight indexing is disabled and necessary metadata is inaccessible.
Try to turn Spotlight indexing On and the error message:
"Metadata.framework [Error]: couldn't get the client port"
disappears and kernel will be stable.
When I start my Jboss server (5.1), I have the following line in logs:
[LogNotificationListener] Adding notification listener for logging
mbean "jboss.system:service=Logging,type=Log4jService" to server
org.jboss.mx.server.MBeanServerImpl#1bfefb[ defaultDomain='jboss' ]
This line takes 30 seconds before to continue the startup.
I don't know what does this line (the code behind this line of course).
Why takes it a long time and what does it do ?
Thanks.
Enable DEBUG logging and you will see what's going on. Add to startup parameters
-Djboss.server.log.threshold=DEBUG
and you will see it in:
jboss-as/server/${profile}/log/server.log
Or change configuration to see it in console. Config file is here:
jboss-as/server/${profile}/conf/jboss-log4j.xml
I'm new to Android programming (and Eclipse IDE and Android emulator). I've got Hello World and some of Notepad working, but I'm still constantly getting quite a few DDMS console log messages (shown below) about not being able to bind locals for debugger.
[2010-05-29 21:03:16 - ddms] Can't bind to local 8601 for debugger
[2010-05-29 21:05:26 - Device] Failed to delete temporary package: device (emulator-5556) request rejected: device not found
[2010-05-29 21:06:47 - ddms] Can't bind to local 8600 for debugger
[2010-05-29 21:07:05 - ddms] Can't bind to local 8601 for debugger
[2010-05-29 21:07:05 - ddms] Can't bind to local 8602 for debugger
And so on. Is this a problem? Can I get rid of these messages somehow?
In Eclipse, goto
1) Windows->Preference
2) Expand Android menu in the side of the Preference Window.
3) Now select DDMS from it.
4) Then Set the Base local debugger port to "8601" and enable "Use ADBHOST" checkbox and the ABDHOST value should be "127.0.0.1".
5) Click apply and ok.
6) Now you have to restart your ADB, for this you have to login as root user(Assuming linux user) and navigate to Platfrom tools folder of your Android SDK. Then execute,
./adb kill-server
./adb start-server
You will be able to see the message "Daemon started Successfully" . If not repeat step 6 once again until you see the success message.
You can get rid of the the messages by adding following to your hosts file:
127.0.0.1 localhost
ps. hosts file can be found from c:\windows\system32\drivers\etc\hosts
or if you are on linux /etc/hosts
In my situation the problem has been solved by a uninstalling all Java 7. The debugger is now working again!
Sorry, not really programming question, but I am not sure where else I could find some help.
After a recent update (Xorg was updated among other things), GTK apps stopped running in my kde4. I have a Debian unstable, updated around 22 April. When I try to run them I get the following error:
ga#grzes:~$ iceweasel
The program 'firefox-bin' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadName (named color or font does not exist)'.
(Details: serial 888 error_code 15 request_code 45 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
ga#grzes:~$ gimp The program 'gimp' received an X Window
System error.
This probably reflects a bug in the program.
The error was 'BadName (named color or font does not exist)'.
(Details: serial 6955 error_code 15 request_code 45 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
(script-fu:4643): LibGimpBase-WARNING **: script-fu: gimp_wire_read():
error
I have to restart the font server manually to have it fixed:
ga#grzes:~$ su
Password:
grzes:/home/ga# /etc/init.d/xfs restart
Stopping X font server: xfs.
Setting up X font server socket directory /tmp/.font-unix...done.
Starting X font server: xfs.
Any ideas what could be wrong? Is it a configuration issue? My system has been updated for the last 7 years, so I can have some old settings.
Debian unstable is very... unstable now, since a release was made a short time ago. Major changes and packages migrations are happening. Xorg (and all X related stuff) being one of the critical packages in that process. My advice is to perform a new update/upgrade in order to catch a new version that may resolve this problem.
It's very frequent that after an update some thing will get broken in inexplicable ways, simply because the developers are uploading new, and not much tested, version of the applications
I finally figured this out: seems like xfs is not compatible with the other components currently and luckily removing it form the system completely solves the problem.