I can't seem to find a solution to access a MySQL server from an Objective-C Mac OS project (which uses ARC).
I tried to use the MySQL framework that Sequel Pro provides, but that crashes (EXC_i386_GPFLT) my App whenever I just create a connection object:
SPMySQLConnection *conn = [[SPMySQLConnection alloc] init];
I don't know whether that is a bug in the framework or if I need to do something else in order to use it.
I tried a few other libraries (like MySqueakQl) but none of them are ARC compatible.
Also I tried to link to libmysqlclient.a directly, but if I copy that library into my project, I get a code signing error; if I just link to the .a in /usr/local/mysql/lib/, I get another error: dyld: Library not loaded: libmysqlclient.18.dylib ... Reason: image not found. I have to admit that I have zero experince with using third-party libraries (whether .a or .dylib) and probably didn't do it right.
I'm a bit surprised that there doesn't seem to be an up-to-date (read: working) solution out there. I know, consumer apps rather use Core Data, but I have to access out company database server.
Has anybody seen a solution (libary?) that works more or less "out of the box"? I'd be willing to pay for something that actually works.
A good tutorial on how to use .a libraries in Xcode projects that would also help me to understand where the dylib error comes from would also be very helpful.
Problem solved. I probably made some mistake when including the library.
The right steps to do this:
Drag the libmysqlclient.a library into your project window
Make sure you set Copy items if needed to Yes, and that it is added to your main target
Drag a folder containing the headers (found under /usr/local/mysql/include) into your project window
Again, make sure you set Copy items if needed to Yes and the correct target is checked.
Then:
#import "mysql.h"
- (BOOL) mySQLTest {
MYSQL connection;
mysql_init(&connection);
if(!mysql_real_connect(&connection,
[self.host UTF8String],
[self.user UTF8String],
[self.password UTF8String],
[self.database UTF8String],
self.port,
NULL,
0)) {
return NO;
}
// ... work with the DB
mysql_close(&connection);
return YES;
}
Works like a charm.
I have no idea why on my former attempts I got an error about the dylib; I never used it (only the static library).
The code signing issue may have been just a bug or one-time quirk in Xcode.
Related
Uncaught DOMException: Failed to execute 'define' on 'CustomElementRegistry': this name has already been used with this registry
at http://127.0.0.1:8000/components/#polymer/polymer/lib/elements/dom-module.js:175:16
Tried deleting node-modules and package-lock and reinstalling did not work.
this error is due to a custom element tag-name being registered which is already registered; to fix simply check that an element by this name hasn't already been registered. This example solution checks to see if something is already registered using the existing API and if not, registers the given Class (inheriting from/extending HTMLElement--at some point):
customElements.get('the-element') || customElements.define('the-element', HTMLTheElement);
For more on the API see https://developer.mozilla.org/docs/Web/API/CustomElementRegistry
most/mature libraries address this problem and those that don't, or are mangled by package and build process complexities can have it pop up; in most cases either updating to a current version, migrating to Lit (https://lit.dev) or patching the problem somehow provides a path to a solution; note the simpler solutions are far easier to maintain--as can be seen in the conflation of npm, polymer over the actual error in the original question; the Polymer project became lit-html and LitElement, and recently rebranded as "Lit" (and still includes these lit-things). Professionally I'm migrating away from npm and Nodejs to Deno with the aim of generally resolve the many problems related to npm and tooling insecurity and complexity, however this answer provides a more direct solution (understand the problem and fix directly, or update to the relevant latest solution which includes this somehow).
Well, this worked for me, with no Typescript warnings,
if (!customElements.get('the-element')) { customElements.define('the-element', HTMLTheElement); }
Hope someone will find this useful.
Cheers.
It is unwise to use the answers above. You want it to fail! The reason being is that your NPM should be deduping duplicate packages, so the fact that you see a certain component being defined on the custom elements registry more than once is a crucial error that you need to debug why the same component is registered more than once.
How to debug, in short, go to your browser, inspect element, network tab, refresh, figure out which files are both registering the same element. Then check in the initiator to see which files are loading those files. Then you get a way better idea of why your app is not resolving the same import to a single place (your deduped dependency).
One reason why you might face this problem is due to semver. If you have multiple different major versions of the same dependency, NPM cannot just dedupe all of the installations to your root node_modules. How you solve this is up to you. Some people use npm-aliases for their different majors of a dependency, some people implement a plugin in their build-tool to resolve paths to a single installation, etc.
For people that can't use #jimmonts answer because the issue is in one of their dependencies you can use the following snippet:
This happens for us, because a package we are using defines an element. But this package is used by multiple apps. And these apps, wouldn't you know it, interact. So customElements.define('x-tag', className) gets called multiple times. And the second time it does, it crashes the app.
function safeDecorator(fn) {
// eslint-disable-next-line func-names
return function(...args) {
try {
return fn.apply(this, args);
} catch (error) {
if (
error instanceof DOMException &&
error.message.includes('has already been used with this registry')
) {
return false;
}
throw error;
}
};
}
customElements.define = safeDecorator(customElements.define);
I was getting the same error. You may not have the same issue as me but I thought I would drop my solution here just incase someone runs into the same issue in the future.
I had two modules that both imported the same custom element module, one of the was importing Module.js and the other module.js. Now the browser saw this as two separate files because URLs can be case sensitive, except my server saw this as one file because it is not case sensitive (express.js) or at least it was able to resolve the path to the correct file even with the incorrect case. And so the browser saw two "different" modules both defining the same custom element, but when I searched my source code only one file was defining the custom element.
I had this problem and found out that I was calling on my boundle.js file twice. Since I was using Webpack and HtmlWebpackPlugin, HtmlWebpackPlugin added the reference to my boundled file to my index.html file where I had already referenced it by hand.
I developed a solution, thats overrite the define with a precheck before define. It works fine for me, just ad the 2 lines into your index.js
customElements.defineclone = Object.assign(Object.create(Object.getPrototypeOf(customElements)).define, customElements);
customElements.define = (name, element) => customElements.get(name) || customElements.defineclone(name, element);
While working through a tutorial to start learning Grails, I made a mistake and ran:
grails create-domain-class com.FooBar
instead of:
grails create-domain-class com.acme.FooBar
It was immediately obvious I had made an error so I tried the following:
Searched for a function that reverses the create-domain-class command, it seems there isn't one.
Searched for advice on the web and the consensus is that you can delete a domain class file, any associated views and tests, then to be safe run a text search for your class name in your project directory for any references you may have missed. I have done all this.
Then I ran the correct command to create com.acme.FooBar, which worked.
After this the app fails to run and reports the following error:
org.hibernate.DuplicateMappingException: duplicate import: FooBar refers to both com.acme.FooBar and com.FooBar (try using auto-import="false")
After adding the following code to com.acme.FooBar:
...
static mapping = {
autoImport false
}
...
The app now runs as expected.
However as an experienced Java developer who occasionally does refactor a package I would like to understand how to do that without causing a DuplicateMappingException or resorting to the "autoImport false" solution.
Thanks.
You shouldn't be doing
static mapping = {
autoImport false
}
As, by doing this you said that don't check for domain just by name and look up for package as well. Hence, once you do that you will have to use Fully qualified name of the class in your queries / hqls which may itch sometimes.
You should be removing the Domain completely i.e.
remove the Domain
remove the view folder creating by default with very same name and so do the controller
Now, do grails clean-all(Make it a thumb rule to use grails clean-all first for any issue unexpectedly occuring).
To be more accurate do remove target directory from your project and then do run grails run-app.
I had done very same thing many times and got it resolved by above steps.
Hope it helps.
I'm currently develop an Objective-C library that links to the MariaDB C connector. I believe there is a problem with the library, though.
Every time I execute my code I get very strange errors on the console. The -(id)init method of my library calls mysql_init(NULL) to initialise the library but as soon as I return from -(id)init I get the following errors in the console:
Object 0x10643df70 of class XXX autoreleased with no pool in place - just leaking - break on objc_autoreleaseNoPool() to debug
Thing is, there is no multithreaded code being executed and if I run the same - (id)init without the call to mysql_init(NULL) the errors disappear. I believe the libmariadb library is causing these errors to appear. I don't get why though.
Do I need to build it with any special command line switches? Am I calling the right methods? I obviously used the MySQL online documentation as a guide.
Make sure you add this anytime you have a new thread:
#autoreleasepool {
//enter code here
}
Have you tried latest revision from launchpad?
Also try to build libmariadb with -DUNDEF_THREADS_HACK and
CMAKE_USE_PTHREADS:BOOL=OFF)
I was busy with other stuff for a while. I've since updated MariaDB to the latest version and, as far as I can tell, it works fine.
I'm using the WkHtmlToXSharp wrapper library in my project to generate PDF file from HTML.
I was using this library a lot of times in different PCs and, suddenly, I came across the following problem:
System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
at WkHtmlToXSharp.WkHtmlToPdfConverter.wkhtmltopdf_convert(IntPtr converter)
at WkHtmlToXSharp.WkHtmlToPdfConverter.Convert(String inputHtml)
at WkHtmlToXSharp.WkHtmlToPdfConverter.Convert()
at WkHtmlToXSharp.MultiplexingConverter.b_8()
--- End of inner exception stack trace ---
at Sanford.Threading.DelegateQueue.EndInvoke(IAsyncResult result)
at Sanford.Threading.DelegateQueue.Invoke(Delegate method, Object[] args)
at WkHtmlToXSharp.MultiplexingConverter.Convert()
This seems to be a common problem with this library (I've found some feedback on the web about it - however no fix was provided). BTW, in my case it happens somewhat randomly. I was not experiencing this problem in other dev machines. I wonder if somebody has a fix for it. I also wonder if this is a problem with the wrapper library, if with the WkHtmlToPDF library itself.
Any suggestion? I'm also open to use another converter, as long as it is free and stable and, if possible, without spawning a new process. It must work properly and stable in all Windows versions and do a decent job converting (the HTML to be converted is fixed - contains a few pics and tables and basic CSS).
I would suggest an alternate route: simply use wkhtmltopdf.exe directly, building your own wrapper. They are not very complicated if you have control of the input and then you know exactly how to update it and how the options work. I've never encountered with that problem when using wkhtmltopdf directly (on Win7, Win server 2008 r2, Ubuntu and CentOS). They do spawn process for every conversion though.
For an example, check out the Derp class in another answer of mine regarding wkhtmltopdf. Or try something like the untested code below (your true code will be more complicated, this is just a demo/POC).
var pi = new ProcessStartInfo(#"c:\wkhtmltopdf\wkhtmltopdf.exe");
pi.CreateNoWindow = true;
pi.UseShellExecute = false;
pi.WorkingDirectory = #"c:\wkhtmltopdf\";
pi.Arguments = "http://www.google.com gogl.pdf";
using (var process = Process.Start(pi))
{
process.WaitForExit(99999);
Debug.WriteLine(process.ExitCode);
}
Scenario: I am using Managed Extensibility Framework to load plugins (exports) at runtime based on an interface contract defined in a separate dll. In my Visual Studio solution, I have 3 different projects: The host application, a class library (defining the interface - "IPlugin") and another class library implementing the interface (the export - "MyPlugin.dll").
The host looks for exports in its own root directory, so during testing, I build the whole solution and copy Plugin.dll from the Plugin class library bin/release folder to the host's debug directory so that the host's DirectoryCatalog will find it and be able to add it to the CompositionContainer. Plugin.dll is not automatically copied after each rebuild, so I do that manually each time I've made changes to the contract/implementation.
However, a couple of times I've run the host application without having copied (an updated) Plugin.dll first, and it has thrown an exception during composition:
Unable to load one or more of the requested types. Retrieve the LoaderExceptions for more information
This is of course due to the fact that the Plugin.dll it's trying to import from implements a different version of IPlugin, where the property/method signatures don't match. Although it's easy to avoid this in a controlled and monitored environment, by simply avoiding (duh) obsolete IPlugin implementations in the plugin folder, I cannot rely on such assumptions in the production environment, where legacy plugins could be encountered.
The problem is that this exception effectively botches the whole Compose action and no exports are imported. I would have preferred that the mismatching IPlugin implementations are simply ignored, so that other exports in the catalog(s), implementing the correct version of IPlugin, are still imported.
Is there a way to accomplish this? I'm thinking either of several potential options:
There is a flag to set on the CompositionContainer ("ignore failing imports") prior to or when calling Compose
There is a similar flag to specify on the <ImportMany()> attribute
There is a way to "hook" on to the iteration process underlying Compose(), and be able to deal with each (failed) import individually
Using strong name signing to somehow only look for imports implementing the current version of IPlugin
Ideas?
I have also run into a similar problem.
If you are sure that you want to ignore such "bad" assemblies, then the solution is to call AssemblyCatalog.Parts.ToArray() right after creating each assembly catalog. This will trigger the ReflectionTypeLoadException which you mention. You then have a chance to catch the exception and ignore the bad assembly.
When you have created AssemblyCatalog objects for all the "good" assemblies, you can aggregate them in an AggregateCatalog and pass that to the CompositionContainer constructor.
This issue can be caused by several factors (any exceptions on the loaded assemblies), like the exception says, look at the ExceptionLoader to (hopefully) get some idea
Another problem/solution that I found, is when using DirectoryCatalog, if you don't specify the second parameter "searchPattern", MEF will load ALL the dlls in that folder (including third party), and start looking for export types, that can also cause this issue, a solution is to have a convention name on all the assemblies that export types, and specify that in the DirectoryCatalog constructor, I use *_Plugin.dll, that way MEF will only load assemblies that contain exported types
In my case MEF was loading a NHibernate dll and throwing some assembly version error on the LoaderException (this error can happen with any of the dlls in the directory), this approach solved the problem
Here is an example of above mentioned methods:
var di = new DirectoryInfo(Server.MapPath("../../bin/"));
if (!di.Exists) throw new Exception("Folder not exists: " + di.FullName);
var dlls = di.GetFileSystemInfos("*.dll");
AggregateCatalog agc = new AggregateCatalog();
foreach (var fi in dlls)
{
try
{
var ac = new AssemblyCatalog(Assembly.LoadFile(fi.FullName));
var parts = ac.Parts.ToArray(); // throws ReflectionTypeLoadException
agc.Catalogs.Add(ac);
}
catch (ReflectionTypeLoadException ex)
{
Elmah.ErrorSignal.FromCurrentContext().Raise(ex);
}
}
CompositionContainer cc = new CompositionContainer(agc);
_providers = cc.GetExports<IDataExchangeProvider>();