Just downloaded the Xcode 7 GM build and my project is seeing the following runtime error:
NSArray element failed to match the Swift Array Element type
We see this in a number of places, probably the simples example is this:
var cacheDirectory = NSSearchPathForDirectoriesInDomains(NSSearchPathDirectory.CachesDirectory, NSSearchPathDomainMask.UserDomainMask, true)
However it happens in other places where Array casts had previously succeeded.
This code runs fine using Xcode7-beta6.
This code also runs fine when starting a fresh project with Xcode.
This code also runs fine when the debugger is not attached...
Any ideas?
Stack Trace below:
Well, we never were able to get to the bottom of this. It seemed as though there was some build setting in our project at was causing all kinds of strange errors similar to the one above when using the Xcode7 GM build. We ultimately had to copy all our files into a new project to work around it.
Related
When we try to compile our C++ iOS game app with these two profilers in Xcode, we're getting the following linker error.
Ditto /Users/Max/Library/Developer/Xcode/DerivedData/TowerDuel-dsejjkbvgengpngaqrfokeoaquvx/Build/Products/Debug-iphoneos/TowerDuel-mobile.app/Frameworks/libclang_rt.asan_ios_dynamic.dylib /Users/Max/Documents/XcodeWorkspace/TowerDuelWorkspace/TowerDuel/lib/clang/8.1.0/lib/darwin/libclang_rt.asan_ios_dynamic.dylib
cd /Users/Max/Documents/XcodeWorkspace/TowerDuelWorkspace/TowerDuel/proj.ios_mac
export PATH="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
/usr/bin/ditto -rsrc /Users/Max/Documents/XcodeWorkspace/TowerDuelWorkspace/TowerDuel/lib/clang/8.1.0/lib/darwin/libclang_rt.asan_ios_dynamic.dylib /Users/Max/Library/Developer/Xcode/DerivedData/TowerDuel-dsejjkbvgengpngaqrfokeoaquvx/Build/Products/Debug-iphoneos/TowerDuel-mobile.app/Frameworks/libclang_rt.asan_ios_dynamic.dylib
ditto: can't get real path for source '/Users/Max/Documents/XcodeWorkspace/TowerDuelWorkspace/TowerDuel/lib/clang/8.1.0/lib/darwin/libclang_rt.asan_ios_dynamic.dylib'
Command /usr/bin/ditto failed with exit code 1
It seems like it's trying to use some iOS 8.1 library, even though our deployment target is iOS 9.
How can we fix this?
EDIT: Just to clarify, the issue also happens when only using ONE of these at the same time.
I have been using dlib object detection successfully on mac. Now I want to use it in an iOS app. However, after spending countless hours, dlib object detector always returns zero rectangles.
ifstream fin(dataDir + "/object_detector.svm", ios::binary);
typedef dlib::scan_fhog_pyramid<dlib::pyramid_down<6> > image_scanner_type;
dlib::object_detector<image_scanner_type> detector;
dlib::deserialize(detector, fin);
vector<dlib::rectangle> dets = detector(dlibImage);
To make sure it’s not due to a different image, I am using exact same image for which detector returns 1 hit on mac. I have also printed uchar from part of the image in both mac and iOS, and it’s returning same values. So image data is exactly the same.
Probably dlib library is not built correctly for iOS. I have tried multiple approaches for this. From /example/build dir, below command was invoked.
cmake -G Xcode ..
cmake --build . --config Release
It generated dlib.xcodeproj project in dlib_build dir. I opened the project in xcode, changed architecture to iOS (armv7, arm64) and rebuild the library. This library was linked to my project. I got zero results with this approach. dlib was built in debug mode; I did not get any assertion errors.
Second approach tried was to use dlib/all/source.app in my project. I used all the proprocessing flags that are used by cmake or dlib.xcodeproj project. No errors, but still no matches.
I have compared build settings of my xcode project with examples.xcodeproj generated by cmake and it’s same. Also checked the xcode project from https://github.com/zweigraf/face-landmarking-ios, but no help.
Strange thing is detector takes couple of seconds to process and comes back with zero matches. So it’s doing something. I wish there was a debug logging that I can turn on for the detector.
I am out of ideas. Will appreciate if anyone can help. dlib is a wonderful library, I just wish it would have been easier to work with on iOS.
dlib is working fine on iOS too. Kicking myself for it, but I mixed up the detector instances. The detector on which I called below line was not used for object detection.
dlib::deserialize(detector, fin);
I was just using an empty detector instance, and it was returning 0 detections. By empty detector, I mean it was defined but deserialize method was not invoked. It would have been nice if dlib returned an error or warning, if a detector not loaded with object_detector.svm file is used for detection.
I have observed the same behavior with shape detector too. If sp.dat is not loaded, it silently reports 0 parts detected. Posting this as answer, in case someone else also makes such a silly mistake.
TL;DR: I want to change the version of LLDB that CLion (v2016.3.5) uses to LLDB v3.8.1. Can I do this? If so, how?
Longer explanation of the question:
CLion is a C++ IDE that I've been using for a few years now. Recently, they released version 2016.3.X. When they went from 2016.2 to 2016.3, they changed the "built in lldb" version from v3.8.1 to v3.9.0. This has caused a problem for me as v3.9.0 doesn't seem to want to work correctly.
When I, say, "print some_var_name" (while at a break point) I get an error (below):
Assertion failed: (D->getCachedLinkage() == LV.getLinkage()), function
getLVForDecl, file
/Applications/buildAgent/work/92515a49514b3993/lldb/llvm/tools/clang/lib/AST/Decl.cpp,
line 1360.
The source of this file can be found here: https://clang.llvm.org/doxygen/Decl_8cpp_source.html
My options are
(1) Figure out why that error is happening. Creating a simple "hello world"program and debugging seems to work. This tells me that it has something to do with my code base, I suppose. But I have over 20,000 lines of code. So figuring out what's doing it would be extremely time consuming. LLDB version 3.8.1 seems like a faster/easier fix since it was doing me just fine in the past.
(2) Use an old version of CLion (which, by default, utilizes LLDB version 3.8.1)
(3) Get the new(er) version(s) of CLion to use LLDB version 3.8.1.
Thanks for any help/guidance.
I assumed you could just enter the path in this preferences page:
My goal is to create a package in R with C++ code: So my questions is how?
I am following the tutorial http://www.stat.columbia.edu/~gelman/stuff_for_blog/AlanRPackageTutorial.pdf on creating an R package containing C++ code. The specific code Im trying to compile and package is exactly as described in the tutorial.
R CMD SHLIB seems to be working creating .dll file.
I can load in R using dyn.load() and test it on simulated data (as described in tutorial)
R CMD INSTALL is where the problem begins. I have done two things encountering two different errors supposedly related:
1) The tutorial says the NAMESPACE file is supposed to contain the code:
useDynLib(XDemo)
export(XDemoAutoC)
When it does R CMD INSTALL fail resulting in error:
Error in inDL(x,as.logical(local), as.logical(now),...): unable to
load shared object 'C:/.../libs/i386/XDemo.dll': Loadlibrary failure:
1% is not a valid Win32-program
2) Removing the above mentioned lines in NAMESPACE file will result in installation of package. I can succesfully load it in R but when I try to use the R function that makes a .C() call to the C++ written function I another error:
library(newpackage)
ls(package:newpackage)
[[1]] "XDemoAutoC"
Warning message:
In ls(package:newpackage) :
‘package:newpackage’ converted to character string
XDemoAutoC(c(1,2,3,4))
Error in .C("DemoAutoCor", OutVec = as.double(vector("numeric", OutLength)), :
C symbol name "DemoAutoCor" not in load table
Im running version R2.15.2 on windows 64-bit and using R64 bit.
I read the following post with a similar problem:
http://r.789695.n4.nabble.com/Include-C-DLL-error-in-C-symbol-name-not-in-load-table-td3464021.html
Except they mention nothing about the NAMESPACE-matter.
Also I read this post:
Problem with loading compiled c code in R x64 using dyn.load
So I am thinking: that based on the fact that I am able to use dyn.load() in Rx64 means that I have succesfully created x64 .dll. Assuming that the NAMESPACE file is supposed to be left as in the tutorial - hopefully fixing the >>not in load table<< error - this would mean I should focus on fixing problem one. This problem seems to be caused by something related to 32-bit. I have used Dependency Walker on the .dll file but I am not sure how to interpret the results
I really don't have any ideas on how to fix this problem so any suggestion on what to do would be welcome?
I think you are doing it wrong. Two quick suggestions:
Read the Writing R Extensions manual written to explain just this: writing R extensions including those with compiled code
Have a look at Rcpp which makes R and C++ extensions, including package building so much easier. Or so we think. Writing a package is as easy as calling Rcpp.package.skeleton(). The documentation in 1) still help.
That said, if R CMD INSTALL fails you may have some mixup in your $PATH. Never ever mix MinGW and Cygwin. Make sure no Cygwin DLLs are found when you build or call R. Path order matters greatly. See the manual for details.
I am busy converting by existing firebreath plugin here to use gpgme instead of making calls via the OS and the gpg binary.
I have managed to get the code to compile in windows using VS 2010 on a x32 system but after loading the plugin into chrome I can not access the npapi code at all. Even simple version calls fails.
When loading the plugin I get no visible errors but when using sawbuck log viewer for chrome I get the erorr messages below.
.\renderer\webplugin_delegate_proxy.cc 347 PluginMsg_Init returned false
..\plugins\npapi\webplugin_impl.cc 271 Couldn't initialize plug-in
I have tried to use my code with both firebreath 1.4 and 1.6 and neither versions work. After some simple debugging it seems that using any code provided by gpgme (whether its called or not) causes the plugin to break.
I came to this conclusion by doing the following.
Created a new project with firebreath (versions 1.4 and 1.6)
Add the gpgme.h headers to gmailGPGAPI.cpp and changed nothing else aside from adding the required reference paths to the project.
Build the project to create the dll (this generates the dll fine).
Replace the existing ddl in my project with the dll in step 2 and test it with the following piece of code
plugin = document.createElement('object'); plugin.id = 'plugin';
plugin.type = 'application/x-gmailtest';
document.body.appendChild(plugin);
console.log("my plugin returned: "+ plugin.valid);
console.log("my plugin returned: " + plugin.version);
This returns valid = true and the version returns what ever i set it to.
I then modified gmailGPGAPI.cpp to now return the gpg version by calling gpgme_check_version(NULL) in the version method. I used that method because its probably the simplest returning function that I could test with.
Build the plugin and copy dll to chrome extension as in step 3-4. The plugin builds fine again as expected.
Load the plugin and try to execute the code in step 4 at which point it now just returns undefined for any property or method i try to access on the plugin. No errors are printed to the console or anywhere else in chrome except for the error logged to sawbuck.
I have got no idea where to look or what to try since I cant seem to get an actionable error to work against. I have also reduced by test code to the point where its just a new project with a one line change to make it easier to find the problem.
I should note the code in the repo builds fine in linux/OSX and loads into chrome correctly so I know at some level my code does work.
Two possible paths:
You may have a DLL dependency that isn't available which keeps the plugin from loading; if you run regsvr32 on it in the state where it doesn't work on chrome, does it work?
Your plugin may be loading and then crashing. Start chrome with --plugin-startup-dialog and then when it pops up a dialog warning you that a plugin is about to be loaded attach to that process and see if the process crashes. At this point you can also set breakpoints to try to figure out how far it gets.
Double check your metadata in PluginConfig.cmake as well; sometimes unusual characters in some fields can cause issues like this.