Jump to content

ChS

Members
  • Posts

    9
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by ChS

  1. There are many ways. The Apple event way, the PSN way and the System Exec way.

    The latest one it probably the simplest and faster:

     

    to get all your processes in the format PID TTY  TIME CMD

     

       ps -xc

     

     
    Get the PID of your process (first number in the line)
     
    Then do a
     
         kill -9 PID
     
    This will terminate your application abruptly!
     
    ----
     
    You can also send a quit event to the selected application, do it using "vi.lib:Platform:AppleEvents.llb:AESend Quit Application"
    You'll need the application ID using "vi.lib:Platform:Targeting.llb:Get Target ID"

     

  2. After updating from OSX 10.6.4 to 10.6.5, every time I open a VI or try to create a VISA resource name control , LabVIEW crashes. Both LV 2009 and 2010 exhibit the same behavior.

    By looking at the crash log, it seems that nipal has some problems when loading libSystem.B.dylib.

    I'll try to reinstall VISA and be back to you about the result.

    Ch

    (BTW, look at the funny way the editor interprets the crash log by replacing ": D" with smiley)

    Thread 0 Crashed: Dispatch queue: com.apple.main-thread

    0 libSystem.B.dylib 0x91362176 __kill + 10

    1 libSystem.B.dylib 0x91362168 kill$UNIX2003 + 32

    2 libSystem.B.dylib 0x913f489d raise + 26

    3 libSystem.B.dylib 0x9140a9bc abort + 93

    4 com.ni.framework.nipalu 0x2679d7df _palPrintToLog + 1547

    5 com.ni.framework.nipalu 0x267a8fc3 0x2671f000 + 565187

    6 dyld 0x8fe0ed6d ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 235

    7 dyld 0x8fe0d31e ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int) + 246

    8 dyld 0x8fe0d2c2 ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int) + 154

    9 dyld 0x8fe0d3d1 ImageLoader::runInitializers(ImageLoader::LinkContext const&) + 61

    10 dyld 0x8fe0200b dyld::runInitializers(ImageLoader*) + 34

    11 dyld 0x8fe0b299 dlopen + 558

    12 libSystem.B.dylib 0x913078a8 dlopen + 66

    13 com.apple.CoreFoundation 0x96f8413a _CFBundleDlfcnLoadFramework + 218

    14 com.apple.CoreFoundation 0x96f49b13 _CFBundleLoadExecutableAndReturnError + 1523

    15 com.apple.CoreFoundation 0x96f49511 CFBundleLoadExecutable + 33

    16 com.apple.CoreFoundation 0x96f4a189 CFBundleGetFunctionPointerForName + 57

    17 com.ni.framework.VISA 0x2409cf9c visaLibSymbol + 68

    18 com.ni.framework.VISA 0x2409d4a9 visaLibFree + 1267

    19 com.ni.framework.VISA 0x240a1247 viFlush + 2194

    20 com.ni.framework.VISA 0x240b484e viOpenDefaultRM + 1262

    21 com.ni.framework.VisaCtrl 0x1cff5080 GetIOControlNames + 2570

    22 com.ni.framework.VisaCtrl 0x1cff46f8 GetIOControlNames + 130

    23 com.ni.labview 0x0086267e TagDriverNameProvider::GetIOControlNames(unsigned long, unsigned char const*, _LStrArray***, LvVariantArray***, LvVariant const*, long, void*) + 98

    ch

  3. Fantastic.

    Many, Many thanks. I really appreciate it.worshippy.gif

    You examples didn't work straight out of the box. But I re-compiled the framework with i386 rather than x64 and labVew now accepts it and I can run your dll verson vi.

    I guess it depends on the XCode and OS version you are using. There is an option to tell XCode to build for all format (i386,x64 and PPC)

    You may also links against various OS version. I usually do build for 10.5 SDK.

    I found another framework that Labview could load in the /development/frameworks. There are 3 examples located in there. 1 I can load. the others I cannot. After getting yours to work it it must be due to the bitness (although I'm not sure how to check).

    Bitness? unless you have installed the SDK for 10.4 you should not have a bitness issue.

    Thanks to your example, I've compiled a framework with sqlite 3.7.3 successfully (lots of warnings though) and your re-hashes of my low-level VIs seem fine. I have a rough idea how things fit together now and I think I should be able to compile a framework without the intermediary LV_SQlite wrapper.

    The wrapper was needed since I (ok the OS) dynamically call the built in OSX version of sqlite using the -lsqlite3 in the linker flag. I had to rename calls to avoid conflict.

    This limit will go away if you compile the source for sqlite3.

    Looks like I'm going to be very unsociable tomorrow whilst I play with the Xcode settings rolleyes.gif

    There are many to play with. I'm far for mastering all of them....

    I'll let you know how I get on later in the week. Muchos Grassy Arse biggrin.gif

    I'm looking forward to see it

    Chris

  4. OK. So I think you are saying that frameworks are the key and there's no such thing as a dylib in isolation (at least as far as Labview is concerned).

    You are correct LV CLN only recognized "framework"

    The problem I've come up against now is that I haven't been able to load ANY frameworks with Labview. Even those already installed with the Mac.

    I managed to find the SQLite framework (its under TCL). Couldn't load that, maybe because its is compiled with the TCL interface (usual "not a valid library" error). I'm not familiar with TCL so don't know if that's the issue or just the fact that I cannot load frameworks full stop.

    This is strange, there are plenty of frameworks that you can link to, try carbon framework. Anyway LV VIs are often calling frameworks. To see an example check /vi.lib/Platform/Miscellaneous.llb/TickCount.vi

    Bit of a newbies question. But.........

    I can create a bare-bones framework structure using Xcode. And I can create a dylib with Codeblocks. I can also get it to copy the dylib to the framework. But under what do I add it to? Resources? Target? The framework seems geared towards distribution of applications and any tutorials I am able to find all talk about how to link the executable to the framework All I need is a wrapper for the dylib to get Labview to load it.

    Like most things new to me. I tend to ask a lot of "silly" questions until I arrive at a "Eureka" moment when I am am able to visualise how everything fits together. At the moment I can see what I want. Have a some of the pieces needed to get to what I want, But don't know if I have all the pieces. Have the wrong pieces or Labvew is just being obstinate. Do you have an Xcode example of one that you made yourself using a dylib that Labview likes?

    See the attached file. I've made a basic wrapper that call sqlite3 functions. It links against the OSX version of SQlite 3 using the OTHER_LDFLAGS = -lsqlite3 in the linker options for the selected target.

    I have also modified the low level vis to include the OSX calls. See the provided All_OSX.vi to have a direct link to the modified VIs.

    I DID NOT DO CHECK SQLite PARAMETERS, you should not use the VIs as is, but carefully check that the c and LV code are in adequacy!

    I've attached the dylib I've created. Perhaps you could wrap it so I can see how it all fits together?

    In the terminal doing a > nm SQLite3x32_dylib show that you did not export the sqlite3 symbols!

    Note that LV does not unload a framework, you have to quit LV to reload the framework, this is quite painful if you don't have an SSD.

    Hope this help

    ChS

    LV_SQLite_v001.zip

    • Like 1
  5. > I too thought about using the pre-installed SQLite. But I'm not sure that I can guarantee that it will be 32 bit if the Mac starts in 64 bit mode. A wrapper is not a useful way forward as it requires upkeep of other code than Labview and > would require a lot of work re-implementing an interface which is already there. A windows wrapper went this route and its limited because of this.

    > From my limited reading of the "framework" implementation its a bit like a fat arch. So does that mean I can compile a 32 bit and 64 bit and include both in the framework? Does the pre-installed SQLite have both 32 bit and 64 bit

    > and switch transparently? Do I really have to type in each and every function rather than select it from the LV combo-box?

    XCode will generate 32/64bit framework. I did not check it but I'm pretty sure the dylib is 32/64 bit. Anyway LV on the Mac is still 32 bit.....

    And yes you will have to reselect the correct the lib and function name in you CLN. You could specify the lib name as a parameter of the CLN instead.

    > (And does that mean I select the ". framework" instead of the dylib?) There seems to be little information on > the net for Mac developers.

    Yes select "YourSQLite3.framework" in the CLN. Be carefull since LV does not unload it, you have to quit LV to load a new version!

    > I will have a play with Xcode. I know its installed but not sure where to find it (doesn't show up under applications).

    Its in /Developer/ or you may need to download the latest version from Apple.

    > I've only just learnt to use CodeBlocks so naively though it would just be a case of re-compiling for the Mac (its also > available for the Mac)

    It should work as long as it is able to generate frameworks.

    ChS

  6. On OSX, LV expects to interface a ".framework" file. It has to be 32 bits as LV on OSX is still 32 bits.

    The easiest way to produce a framework is to use XCode and select new project / carbon or cocoa framework.

    XCode will prepare a skeleton ready to be used.

    As SQLite is built-in OSX, you should use the provided implementation and just write a wrapper around it.

    It is located in /usr/lib/sqlite3. This wrapper is only a few lines of code I've done similar wrappers for other libs.

    Let me know if you'd like to have a copy of the XCode project and files.

    Note that LV does not unload DLL/framework from memory. You have to quit LV. If anyone found an alternative I'm very much interested!

    Chris

    • Like 1
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.