@halirutan I'm here. You're right that this is not portable. It seemed better for my use case than setting DYLD_LIBRARY_PATH, but it definitely has the portability problem.
@Szabolcs OK, I was giving you bad advice because IMO we have to differentiate between two scenarios:
1. You are currently developing a package containing LibraryLink functions.
I assumed you do this.
When you are actively working on such a package, it is most likely not installed in your $UserAddonsDirectory but instead in your development path.
To test and debug your functions it is best when you set you DYLD_LD.. path because then you can simply load and test your functions inside Mathematica. No matter where your dev-path is.
@Szabolcs The 2nd scenario is when you have finished your package dev and it is ready to be installed. Here, there is a much easier way to solve the dependency problem.
The requirement is that your package structure looks like the following example:
and Mathematica provides a command to load dependent libraries upfront:
LibraryLoad["libtbb"]
If you check the doc for LibraryLoad you see:
> LibraryLoad is used to load dependent dynamic libraries needed for a Wolfram Library to operate. > Libraries loaded using LibraryLoad do not need to follow the Wolfram Library Link specification. > The order of multiple LibraryLoad calls is important and must follow the mutual dependency of the libraries. > LibraryLoad uses FindLibrary to locate libraries searching on $LibraryPath.
Therefore, the official way to make your LibraryLink package work through the systems is to 1. provide you lib and all deps in the appropriate folder 2. load all dependencies upfront using LibraryLoad and 3. Load your functions using LibraryFunctionLoad.
Unfortunately, this way does not work reliably through all systems, meaning I could only use it in Windoze.
@Szabolcs I'm in investigating this issue right now, but if you like I can add that answer to your question.
@Szabolcs Thanks so much for bringing this issue up. It indeed works even on Linux, testing now for OSX. I only made a simple error. Hell yeeeahh now my package distribution will be a looot easier ;-)
I have a list x and a list of lists ys, and I want to find all ways to cut x into three parts such that the middle one is in ys. What 's a fact way of doing that?
Is this cut just supposed to cut out the y part, and the stuff to the left is another part, and stuff to the right a third part? Or can you arbitrarily partition up the remainder (in which case there will usually be an absurd number of possibilities).
The world would be a very different place if more people chose Mathematica over alcohol. Keep practicing though. All of the good programmers I know eat whatever they want.
Hi all, how can i convert a list containing one element of concatenating expression into a list of expressions? Like a={A1&&B1&&C1&&D1} obtaining a={A1,B1,C1,D1}
@ssch It seems reasonable, it seems to work the way you want it to. I don't feel like I'm well-informed on these sorts of issues though. What do you expect from f[x]; x = 3; f[x]?
@halirutan Do you know what a LibraryLink function is supposed to return on abort (i.e. finding AbortQ() to be true)? Just a LIBRARY_SOMETHING_ERROR? or LIBRARY_NO_ERROR?
From the top of my head I would say that on Abort it is not a library function error, therefore, you should return LIBRARY_NO_ERROR.
What you have to ensure is that no further calculations are done. I remember a MathLink doc/thread/post/QA were this was discussed and the conclusion was to return Abort[] instead of $Abort to ensure everything that follows is aborted too.
@Szabolcs Ahh, I found it. It was mentioned in a pdf from Todd Gayley indeed for MathLink. Please read section 1.10.3 in this pdf.
I don't know whether this works at all, but what I would try to do is to return Abort[] from the library function (Callback Evaluations in Mathematica) and then return NO_ERROR
