openFrameworks: Math killing debugger? - lldb

Using a lerping rectangle class in openFrameworks. I then tried to instantiate it as an array, but it crashed with error:
"warning: Could not find object file "/Users/mike/Projects/simbl/build/SIMBL.build/Deployment/SIMBL.build/Objects-normal/i386/SIMBLPlugin.o" - no debug information available for "/Users/mike/Projects/simbl/src/SIMBLPlugin.m".
The release build was slightly more stable than the debug.
When commenting out these two lines (within a function called continuously throughout the array of its class), it runs fine.
pos.x = catchUpSpeed * mouseX + (1-catchUpSpeed) * pos.x;
pos.y = catchUpSpeed * mouseY + (1-catchUpSpeed) * pos.y;
catchUpSpeed is .03f
Any thoughts on the error message? How did this error arise and how can it be avoided? I can't make heads or tails of it. Seems like simple enough math.
Thank you for reading!

You shouldn't see a crash if this happens, or rather, a crash shouldn't be caused by/related to this warning.
There are two ways to build your app with debug information on Mac OS X / iOS: "DWARF" and "DWARF with dSYM". (these are options in your Xcode project Build Settings)
"DWARF" means that the debug information exists in your .o (object) files. It is not copied into the final executable binary for your app. Your app binary has pointers back to the debug information in the object files. This helps to speed up the link & run cycle. But for it to work, your object files need to be located in the same place as when your built your app. Copying your app to another computer would likely break this. Removing your build intermediates would result in the same problem. The "DWARF" debug info scheme is designed for active development on your local desktop where the .o files will remain in place and not be removed while you're debugging your app.
"DWARF with dSYM" means that when your app binary is linked together, another command (dsymutil) is run to create a linked version of all of your debug information -- a .dSYM bundle. This collects all of the debug information from your object files into a single bundle, and it sits next to your binary. If you want to copy your binary to another system to run & debug it, bring the dSYM along and everything will work fine.
I'm not sure how you're using the build system so that this arrangement is failing for you at debug time, but if you're doing something behind the scenes so that your SIMBLPlugin.o object file does not exist wen you're debugging your app, try changing your project to DWARF with dSYM and you should be fine.
If Xcode is crashing, it's unlikely to be related to that warning message from the debugger. But it would be worth filing a bug report if you're seeing this with a current (Xcode 4.6, etc) version of the tools. http://bugreport.apple.com/ - include the crash reporter text from one of the instances and that'll be a place for them to start.

Related

WebkitGtk application is not loading file URL

I am building a kiosk application using webkitgtk on the raspberry pi 4.
This application will not be connected to the internet and all the html,css, javascript for the UI are all located on the local filesystem.
I am using buildroot to setup the Linux system, starting with the pi 4 defconfig provided in buildroot.
I have enabled all the packages needed to get webkitgtk running.
Also, the kiosk application has been tested on my desktop, using the same software stack and it works
However, when i try to launch the application on the raspberry pi, a blank page pops up. I have played around with the WebKitWebSettings object associated with my WebKitWebView by enabling local file access. It still shows up a blank screen.
Also included in my pi4 application bundle is a simple gtk3+ application. This launches successfully!
I will really appreciate some pointers as to why this is happening as i have sort of reached a dead end
UPDATE
I enabled the MiniBrowser app that comes with the Webkitgtk package.
Entering the local url, The page does not load. It only gives me a message at the top saying "Successfully downloaded".
It seems to be treating my input as a download
UPDATE 2
After some more experimenting, i was finally able to get webkitgtk working on the pi 4.
The problem seems to originate from using the webkit_web_view_load_uri() api.
It does not seem to recognize my html document as a web page.
I got around it using the webkit_web_view_load_html() call. This included some hacks by first reading in the contents of the html doc into a character buffer, and passing it to webkit_web_view_load_html().
You also have to provide a base path to this function call to be able to resolve all the urls (scripts, css, images etc) in your html document.
Another problem i haven't been able to work around is, SVG images are not loading in webkitgtk. I have used jpg formats and they work. I suspect this my be due to a configuration switch in building webkigtk
It's hard for me to figure out what might be happening without having access to your environment and settings. My gut feeling is that pages are showing blank because perhaps some shared libraries are missing. You can check that with:
$ ldd WebKitBuild/GTK/Release/bin/MiniBrowser
I am using buildroot to setup the Linux system, starting with the pi 4 defconfig provided in buildroot.
There's a buildroot repository for building WPE for RPi. WPE (WebPlatform for Embeded) is like WebKitGTK but doesn't depend on GTK toolkit. Another important difference is that WPE runs natively on Wayland.
If you're interested in having a webapp embedded in a browser running in a device with limited capabilities, WPE is a better choice than WebKitGTK. The buildroot repo for building WPE for RPi is here:
https://github.com/WebPlatformForEmbedded/buildroot
There's is also this very interesting step-by-step guide on how to build WPE for RPi3:
https://samdecrock.medium.com/building-wpe-webkit-for-raspberry-pi-3-cdbd7b5cb362
I'm not sure whether the buildroot recipe would work for RPi4. It seems to work for all previous versions, so you might be stepping in new land if you try to build WPE on RPi4.
If you have an RPi3 available I'd try to build WPE for RPi3 first, and make sure that works. Then try for RPi4.

VXWorks Simulation not re-building kernel source code

Working off of the sample ball Downloadable Kernel Module Project in VXWorks6.9.4.12 Workbench3.3 given in this guide (http://www.cs.utep.edu/isalamah/courses/5372/WR-WB-UserGuide.pdf) on a vxsimulator target with the full network stack setting.
Trying to change the kernel source code (trying the reset some network components or even just cause a syntax error in the file /vxworks/components/ip_net2-6.9/vxux/daemon/daemon.c), I've noticed that no changes/recompilation takes place even after rebuilding a project or launching a new workbench, and that all the includes for the Kernel Module Project are .h files (for which some depend on the changed deamon.c).
The changes saved from the workbench are showing when I access the files from the command line but the syntax errors added are not stopping TCP code from running properly--any guidance on how to either make these changes take effect or how to go about making changes for a simulator target.
What you are trying to do is to recompile the source of VxWorks itself. This has to be done thru a VxWorks Source Build Project. This is well documented on docs.windriver.com; for example: Configuring and Building the VxWorks Source Build Project.

PHP error: PHP Startup: Unable to load dynamic library 'php_grpc'

I have tried so many things. Literally taken me a week of trial and error. I managed to get the realtime firebase DB working but not the firestore as I can't call the command
composer require google/cloud-firestore
I have tried fresh installs 3 times for PHP and the other software. This really is not working. Why do I have to use this composer thing and them not just put a zip with all the relevant files inside?
With extension=php.dll in ini:
and changing to aboslute path surrounding extension, with and without .dll I have tried.
I've tried threadsafe and non threadsafe versions, and I also don't know what "1% is not a valid command" is. Also have tried x64 and x86 versions. The previous two images are x86 (which I assume to be 64 as my os is)
Here is an example of a x64 (I assume is 32bit) error. Procedure points cannot be found and it gives an error about entry points.
I have no idea what I did but I fixed it. To those reading this question just make sure in every place there is a php.ini they are the same directory!

How can I reproduce this DDD test?

I'm learning how to use Data Display Debugger (DDD) for my C/C++ programs. The Help reference for DDD shows some sample outputs, including the following graphic graph / charting example. I'm trying to reproduce the exercise, but I'm having difficulty. The way it should work is I would compile cxxtest.c with debugger options, and the DDD tool would actually graph the variable array of interest during a step debugging session, in both 2D and 3D. Wow, if it works.
The cxxtest.c program is included in the DDD repository, ddd-3.3.12.tar.gz. I'm trying to compile and run that program but I keep getting stuck. I can't figure out how to generate a config.h file, so I can link in necessary support files (e.g. bool.h) to compile cxxtest.c
Files I see in the DDD repository, relating to config include:
config-info
config.h.in
config.texi
configinfo.C
configinfo.h
configure
configure.in
None of them seem to offer much help on how to generate a config.h file.
Anybody know how to generate a config.h file ?
Update: As I continue to work this one, the whole thing seems odd. The program , cxxtest.C , has a .C suffix, but there are distinctly C++ elements in there, #include <iostream> If I block the config.h thing, change the suffix to .cpp and compile I get a whole bunch of different errors. Not sure what the intent was here.
As for README content, I do see some instructions on how to compile the entire DDD tool, and it's quite lengthy. It's not clear on if preparing / configuring and compiling the DDD tool will also compile this particular test file. I guess I can wade thru the make files and scripts and see if this file every gets mentioned. (sigh!)
Actually I'm considering converting the entire file over to pure .c via rewrite. Note, the original file is visible here...
Note: I'm working in Virtualbox Ubuntu desktop for now... Ultimately I'd like to use the DDD tool to analyze key arrays in some digital signal processing (DSP) programs I'm working on.
Update #2:
I tried two different things here. First I built a C version of a file with the plot routines copied from the original cxxtest.c program. I converted all the calls to pure C. I could easily see the data in the DDD data window in text format. When I select the data set and then choose plot, I get a popup "DDD: Starting Plot... Starting gnuplot..." The system just hangs there.
Second, I did a complete clean install of the ddd tool. I had to install a few dependencies, and correct a few known bugs (e.g. #include <cstdio> ) but was successful at both $ ./configure && make and $ make check . The make check command does correctly build and compile cxxtest.c . When I run the file and do the steps to plot the dr and ir array variables, I get the same failure as above.
System hang. A search of the failure indicates this has been reported for years, apparently without resolve. Not quite sure how to proceed. This appears to be a total fail. I cannot reproduce the DDD test to plot graphical output. Anybody else make progress on this one?
Note: with this edit, I'm also removing the How do I generate config.h? from the title. That's not really the key issue here.
Anybody know how to generate a config.h file ?
Yes: just run the configure script provided. A typical sequence for building open source software is:
./configure && make

C error parsing in Eclipe-Indigo is not functioning

I'm trying to migrate some C programs from Windows Server to Linux. To edit the code, I'm using Eclipse-Indigo. The machine on which I'm working has WinXP on it (not my choice, so no comments please). My eclipse workarea is on a samba shared drive which is in my home directory on the Linux server.
Each C program is in a separate makefile project. I have specified the cygwin gcc compiler/parser in the settings for new CDT Projects and selected all relevant error parsers in the makefile project settings.
There are no syntax errors showing and the errors that are listed seem somewhat bizarre. The first error states:
make: *** No rule to make target `../../../../../fiscus/vo/src/mk/e12_.mk'. Stop.
The make script at the end is wrong. There is a value in the name which comes from an environment variable. The path is correct exactly as shown but the script name has hte variable $(WA_PLATFORM) in it. This is not being resolved although I have specified the value in the build environment variables.
The subsequent errors are even weirder. For each subsequent project I get the message:
Program "make" is not found in PATH
This makes me wonder how the first message was generated. Besides, the path on my winXP environment, which I assume is the relevant one here, does indeed have the directory with the make program in it.
Where have I mucked it up? Any hints?
One last piece of information. When I shut down eclipse I get access violation errors for the following:
<workarea-path>\.metadata\plugins\org.eclipse.debug.ui\launchConfigurationHistory.xml
<workarea-path>\.metadata\plugins\org.eclipse.jdt.core\variablesAndContainers.dat
I find this to be suspicious...
The problem appears to lie in the fact that I was using the samba share as my workarea. Apparently the regular backups made on the server changed something (don't know exactly what, though). The projects were no longer being recognised as makefile projects and certain essential metadata files were not accessible. The permissions certainly were not the problem, since I checked those on the server (everything was set to rwxrwxrwx).
To solve the problem I copied the entire workarea to my local hard drive. I then pointed eclipse at this new workarea. The next step was a bit of a pain, because I had to delete each project (without deleting the source, of course) and then import "Existing code as Makefile Project". This can be done with "File->import..." or with a right-click in the package explorer and select "import...".
The last requirement is to specify the required "include" directories. This can be done with "Project-> Properties-> C/C++ General-> Paths and Symbols". Select the "Includes" tab, choose the language (in this case "GNU C") and add the directories where the headers are defined.
Now it works properly again.

Resources