I installed OpenSceneGraph 3.0.1using MacPorts.
I've tried osgversion -> OpenSceneGraph Library 3.0.1. I downloaded the OpenSceneGraph-Data.
Everything seems working well than osgviewer cow.osg takes hours without viewing anything !
please I need help ? is there a way to debug ?
Make sure you have defined the OSG_FILE_PATH environment variable and that it points to the data directory (the one with 'cow.osg').
You can then set OSG_NOTIFY_LEVEL to DEBUG_INFO to get extended information printed to the console. If for any reason the file could not be loaded correctly you will see where to start to troubleshoot.
You can also try to run
$ osgviewer --image /path/to/an/image.png
to test if the plugins work correctly.
Plugins are named e.g. osgdb_jpeg.dylib so you can look for these to make sure they have been built properly along with the core libraries and programs.
Try setting the notify level to DEBUG : Tips And Tricks
$ export OSG_NOTIFY_LEVEL=DEBUG
and run it and see if it says what's going on/going wrong.
Related
I encounter some errors when running a dpdk-based application. I find the error occurs when invoking rte_eth_dev_configure() function provided by dpdk library. The error code is -22. However, I want the application to show more debug information so that I can quickly focus on the error part.
I did RTFM and modified $RTE_SDK/build/.config. I turned RTE_LIBRTE_ETHDEV_DEBUG to be y. But It didn't work. Where does rte_vlog() function put log messages?
Would you like to help me? Any suggestion is appreciated!
You should also change the default log level, otherwise all the debug messages will be compiled out during the compilation, i.e.:
RTE_LOG_LEVEL=RTE_LOG_DEBUG
RTE_LIBRTE_ETHDEV_DEBUG=y
Please also have a look at EXTRA_CFLAGS. You might also want to add the debug symbols and disable optimizations, i.e.:
make EXTRA_CFLAGS="-O0 -g" ...
I add CONFIG_ RTE_LIBRTE_ETHDEV_DEBUG=y to the ${RTE_SDK}/config/defconfig_{RTE_TARGET} config file and rebuild the target. It works.
Hello :)
I am presently learning SDL2, and I made several programs with it.
With these programs, when I double-click on the executable, the program launches, and everything is okay.
On the last program I made, it doesn't work anymore. With this one, I can only launch from terminal.
The exe has the permissions, so theres no reason for this to happen...
The only thing I changed is that the old generic function file I used (for things like "loadTextureFromImage()"...) to a dynamic library I created. Here's a link to the entire project (just a white window for now) -> RightHere.
I'm currently running Ubuntu 14.04.
If you have any idea on why it doesn't work just for THIS project, tell me please!
Thank you in advance ;)
PS : Here's a project that actually works -> RightHere
PS2 : The projects are in c
Okay, so I did ldd ./myprog, and the libraries linked are where I put them, in "${HOME}/lib". If I understood well, you are telling me that because these libraries aren't in "/usr/lib and so on...", they won't be found, and I should write a script. There's a little thing I forgot to tell : I had to add an environment variable in my .bashrc -> export LD_LIBRARY_PATH=${HOME}/lib, so that the libraries are found at compile-time. Because of what you said, I think that this variable is only loaded in terminals, isn't it? So I tried two scripts :
#!/bin/bash
LD_LIBRARY_PATH=$PWD
./myprog
(like you told) and
#!/bin/bash
LD_LIBRARY_PATH=${HOME}/lib
./myprog
(like I made in my .bashrc).
When I run them by double-clicking on them, neither work.
But, when I run them from terminal, only the second one works.
Thank you for the answer, hope it'll help...
EDIT : I confirm that the variable set in .bashrc are only loaded in terminals : I tested this script ->
#!/bin/bash
echo $LD_LIBRARY_PATH > Run.log
LD_LIBRARY_PATH=${HOME}/lib
echo $LD_LIBRARY_PATH >> Run.log
./Pong
and, when I run it from terminal, Run.log contains this :
/home/yohan/lib
/home/yohan/lib,
but, when I run it from double-click, it only contains
*newline*
/home/yohan/lib
Add export before your variable setting. – keltar
Okay so thank you VERY much, it works now, with this script :
#!/bin/bash
export LD_LIBRARY_PATH=${HOME}/lib
./myprog
I'm trying to install clang complete to vim on my Mac, but when I open a .c file I get the following error:
Loading libclang failed, completion won't be available
Consider setting g:clang_library_path
Where do I set the g:clang_library_path? Is this something that goes in ~/.vimrc?
My understanding is that I need to point it to this path:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/
Yes, you will need to put this in ~/.vimrc.
I had a similar problem when I upgraded to Mavericks and added some extra logging to track it down at the time.
I put the following in $MYVIMRC:
let s:clang_library_path='/Library/Developer/CommandLineTools/usr/lib'
if isdirectory(s:clang_library_path)
let g:clang_library_path=s:clang_library_path
endif
This way $MYVIMRC works on non-Mavericks machines, too.
let g:clang_library_path='/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib'
you may try this if '/Library/Developer/CommandLineTools/usr/lib' is not exist
i'm trying to do some code in a keyboard driver, a 3rd party software that looks like this can run the command i'm trying to do in a plugin file that compiles alongside the daemon that the command needs to be sent to. the command looks like this.
g15_send_cmd (g15screen_fd,G15DAEMON_MKEYLEDS,mled_state);
here's the code i'm working with and trying to run the command in (it compiles as a plugin with the daemon. in the uncompiled source it's
"g15daemon/plugin/g15_plugin_uinput.c"
the file that defines the command is in
(link)
"g15daemon/libg15daemon_client/g15daemon_clinet.h"
whereas with the g15macro (3rd software) is run from outside the daemon for various reasons i don't want to (and pretty much can't) use it, one being speed of execution of commands when keys are pressed.
so the program compiles like this without error it seems. but if the code i specified above activates, the driver(daemon) crashes giving
g15daemon: symbol lookup error:
/usr/lib/g15daemon/1.9.5.3/plugins/g15plugin_uinput.so: undefined
symbol: g15_send_cmd
what did i do wrong or what am i missing here? (and i'm sorry if the code in the plugin file is ugly down by that switch command, but i didn't know how to do any better since i don't know C much at all, all i have behind me are Py and C#)
Edit: the solution was given
but i don't know how to add a linker flag, also since it links to a part of the program being compiled will it even work?
You forgot to link your plugin with g15daemon_client library. The simple way to fix it is to add -lg15daemon_client to the linker flags.
On OS X, I generated a set of ctags for the system includes using the following command:
ctags -f c -h ".h" -R --c-kinds=+p --fields=+iaS --extra=+q /usr/include
This was run inside of a ~/.vim/ctags/ directory, where I put all of the ctags I generate for system-wide header files (I also have stuff for ROS and CPP that I load conditionally, but that's neither here nor there).
Anyway. The ctags file is set correctly in my .vimrc, and vim can definitely see the ctags, but for some reason the autocomplete popup will only display results from #included header files if I write out the entire symbol and then start backspacing. As an example, if I #include <string.h> in a project, and then I want to call strlen(), and I start to type str in to the active vim buffer, I will only get results for symbols that are currently in the vim buffer. But, if I type out strlen and then start backspacing one or two characters and hit <C-n>, the popup menu will be populated with matches from any other included header files.
EDIT: Turns out, if I just hit "s" then <C-n>, it works as well. So the problem seems to be that it only works if the popup menu is launched manually. Which makes me think that it's a plugin problem (see below)
Additional information:
completeopt is set to completeopt=menuone,menu,preview,longest
I have OmniCppComplete, which I suppose could be interfering with the behavior. It is currently not being conditionally loaded for C++ files only. If you want me to edit and post my OmniCppComplete settings from my .vimrc, just ask.
I also have AutoComplPop installed, but I haven't done anything to configure it, so it's running with its default settings. Haven't really researched the plugin, so no idea if some of it's behavior could be interfering with the results.
I have AutoTag and TagBar installed, but those should only be fiddling with the current directory's local tagfile.
I'm honestly pretty new to Vim, and I just have no idea where to start debugging this issue, whether it be with a random plugin or with my .vimrc settings.
Vim has many specific completion mechanisms.
<C-n> and <C-p> use many sources defined by the complete option. By default, they will provide completion using the current and all loaded and unloaded buffers, tags and included files. While you can usually get quite useful suggestions with these, it is a bit of a "catch-all" solution: it is not reliable at all if you work on reasonably large projects.
<C-x><C-]> uses only tags so it may be a little more useful to you.
And there are many more, see :h ins-completion.
Omni completion is smarter: it typically runs a custom filetype-specific script that tries hard to provide meaningful completion. It is triggered by <C-x><C-o> and you can read about it in :h ft-c-omni. Omni completion is often a better choice when working with code.
Because you have two overlaping "auto"-completion plugins it's hard to say what completion mechanism is at work. You should disable those plugins and play around with the different completion mechanisms available to you.
I have not mastered this yet, but I do think the following observation may be of help.
Vim's default auto complete which can be quite noisy, often gets in the way of what you call with <C-x><C-o>. Specifically, I found myself calling up my tags based completions with <C-x><C-o> only to have them replaced with continued typing with Vim's default suggestions using my open buffers.
The suggestion of shutting off one of the plugins makes sense. In my case the key was how to shut down Vim's default behavior. I have seen several people (and to which I now include myself), set the length of the expression to a high number before triggering Vim's default. For me that is:
let g:deoplete#auto_complete_start_length = 99
... this way you eliminate the default layer of completions that comes and goes regardless of the commands you intended to inform your work.
This still feels like a hack but it helps keep my work focused on the tag-based completions.
FYI: I use NVIM on a Mac.