I've created a Julia interface for Apple Accelerate's libSparse, via calling the library functions as if they were C (@ccall). I'm interested in using this in the context of power systems, where the sparse matrix is the Jacobian or the ABA matrix from a sparse grid network. However, I'm puzzled by the performance. I ran a sampling profiler on repeated in-place solves of Ax = b for a large sparse matrix A and random dense vectors b. (A is size 30k, positive definite so Cholesky factorization.) The 2 functions with the largest impact are _SparseConvertFromCoordinate_Double from libSparse.dylib, and BLASStateRelease from libBLAS.dylib. That strikes me as bizarre. This is an in-place solve: there should be minimal overheard from allocating/deallocating memory. Also, it seems strange that the library would repeatedly convert from coordinate form. Is this expected behavior? Thinking it might be an artifact of the Julia-C interface, I wrote up a similar program in C/Objective-C. I didn't profile it, but timing the same operation (repeated in-place solves of Ax = b for random vectors b, with the same matrix A as in the Julia) gave the same duration. I've attached the C/Objective-C below.profiling-comparison.m.txt If you're familiar with Julia, the following will give you the matrix I was working with: using PowerSystems, PowerNetworkMatrices sys = System("pglib_opf_case30000_goc.m") A = PowerNetworkMatrices.ABA_Matrix(sys).data where you can find the .m file here. (As a crude way to transfer A from Julia to C, I wrote the 3 arrays A.nzval, A.colptr, and A.rowval to .txt files as space-separated lists of numbers: the above C/objective-C reads in those files.) To duplicate my Julia profiling, do pkg> add AppleAccelerate#libSparse Profile--note the #libSparse part, these features aren't on the main branch--then run using AppleAccelerate, Profile # run previous code snippet to define A M, N = 10000, size(A)[1] bs = [rand(N) for _ in 1:M] aa_fact = AAFactorization(A) factor!(aa_fact) solve!(aa_fact, bs[1]) # pre-compile before we profile. Profile.init(n = 10^6, delay = 0.0003) @profile (for i in 1:M; solve!(aa_fact, bs[i]); end;) Profile.print(C = true, format = :flat, sortedby = :count)

Hello Apple Team, I'm trying to import the Audodesk FBX SDK to my Objective-C iOS Project. The SDK is written in C++, but has support for iOS and the iOS simulator architectures. I've added the path to the include folder in the Header Search Path I've also added the paths to libfbxsdk.a in the Library Search Paths Finally, I've added the libfbxsdk.a file to the Link Binary with Libraries. However, when I build the project, I get the following error: building for 'iOS', but linking in object file (/Users/Lond/Documents/v2/Autodesk/iOS/2020.3.7/lib/ios/debug/libfbxsdk.a[28](fbxalloc.cxx.o)) built for 'macOS' In the terminal, if I type the command: 
lipo -info libfbxsdk.a I get the message Non-fat file: libfbxsdk.a is architecture: arm64 confirming that I'm using the library for the correct architecture.   Do I need to add any other confifuration option? (Like the other linker flag or something else) I'm quite new to C++, and integrating a C++ SDK into iOS is not easy.   I'm using Mac Os Sonoma 14.6.1 Tested on Xcode 15.4 and 16.2 Target Device: iPhone 13 Pro (iOS 17.6.1) iOS FBX SDK version: 2020.3.7 Link to the SDK if needed: https://aps.autodesk.com/developer/overview/fbx-sdk   Any help would be greatly appreciated Thank you

Hi! We are seeing a bit surprising behavior of dispatch_main on macOS where it seems to spawn a different thread instead of preserving the one it gets called from. Managed to reproduce it in a completely empty command-line tool project in Xcode int main(int argc, const char * argv[]) { @autoreleasepool { dispatch_main(); return 0; } } I put a breakpoint on the line with dispatch_main and see that I am on Thread 1 and inside main function. That makes sense. I resume execution and pause again. Looking at Thread output in Xcode, I can only see Thread 2. Thread 1 is gone and the executable keeps on running. So dispatch_main did what was expected (prevented the process from termination) but throws out the thread it was called from and creates a new one? Is that behavior expected or am I missing something? Just a brain teaser at this point. But we could not make sense out of it. :)

I have a simple shell script as follows: #!/bin/bash OUTPUT="network.$(date +'%d-%m-%y').info.txt" SUPPORT_ID="email" echo "---------------------------------------------------" > $OUTPUT echo "Run date and time: $(date)" >> $OUTPUT echo "---------------------------------------------------" >> $OUTPUT ifconfig >> $OUTPUT echo "---------------------------------------------------" >> $OUTPUT echo "Network info written to file: $OUTPUT." echo "Please email this file to: $SUPPORT_ID." It just dumps the network config into a file. At some point I will have the file emailed out, but right now I'm just trying to figure out why the output looks like the following? bash ./test.sh .etwork info written to file: network.26-01-25.info.txt .lease email this file to: email Why in the world does the initial character of the last couple of "echo" commands get clipped and turned into periods? The echos for the output of the commands piped into the output file are fine. Strange... Any ideas?

I have a simple shell script as follows: #!/bin/bash OUTPUT="network.$(date +'%d-%m-%y').info.txt" SUPPORT_ID="emailaddress" echo "---------------------------------------------------" > $OUTPUT echo "Run date and time: $(date)" >> $OUTPUT echo "---------------------------------------------------" >> $OUTPUT ifconfig >> $OUTPUT echo "---------------------------------------------------" >> $OUTPUT echo "Network info written to file: $OUTPUT." echo "Please email this file to: $SUPPORT_ID." It just dumps the network config into a file. At some point I will have the file emailed out, but right now I'm just trying to figure out why the output looks like the following? bash ./test.sh .etwork info written to file: network.26-01-25.info.txt .lease email this file to: emailaddress Why in the world does the initial character of the last couple of "echo" commands get clipped and turned into periods? The echos for the output of the commands piped into the output file are fine. Strange... Any ideas?

Will Apple continue to support it, or will we wake up one day to find that Swift is the only viable language?It's a serious question. Careers depend on it. I don't accept the "No comment" approach that Apple usually takes. It's cruel.I'm willing to put the time into learning Swift if I have to. I'm not going to do it if I don't. I want to know.Frank