Leaderboard

I've been working some more on my LabVIEW object serialization library. I wanted to fix the problem of double precision numbers. The standard LabVIEW function for translating double to string does not produce numbers that are bitwise recoverable unless you specify a precision of 17 for all values, meaning a lot of junk in the file. LabVIEW uses the standard C printf function under the hood -- the problems LV has are the same problems most other languages have. I figured someone must have found a way to fix this. Oh, boy, did I stumble into gold. In 2010, a grad student, one Florian Loitsch, not only published an algorithm that does this, it is 5x faster for 99.5% of double values than the standard algorithm. It was the first improvement in the algorithm speed in over 20 years. And just last month, he published the code for a further speed improvement. Here's an article about the improvement. This author found a 10x speed improvement in his JSON library. That's exactly what I want to hear. It's hard to find, so here's the link to the actual C code source for this algorithm. I am going to investigate dropping this code into LabVIEW for 2015. I looked a long while at implementing the C code in G. It's doable, but it isn't small at all, so I'd rather just upgrade LV using his C code than try to recode it. Less error prone and it floats all boats, not just my library.

"Me, too", on this one. lvlib for namespacing and encapsulation. Short names for each class and method. One file-system folder per class and it's methods. Virtual folders for grouping by functionality within classes and libraries.

One major thing is simply to have a convention and write it down. I'm not aware of one convention to rule them all so to speak. I tend to name accessors Set and Get instead of Read and Write because Set and Get have the same Nr. of Characters. When listed in detailed view, they seem easier to read for me.

Howdy, I wrote OpenCLV (OpenCL for Labview) about a year ago and have decided to make it an Opensource project availible on GitHub. It contains all my C code to compile DLLs, all the Labview code, some pre-compiled x64 DLL code and a pre-built .vip project if you just want to download and install it. https://github.com/amcelroy/OpenCLV.git My email is in the GPL license header in the C code if you find any bugs or have any comments. Austin

There is a reason that the return value from the double to ascii function is a boolean. I dropped it into a while loop and get a success rate of 99.6-99.7% for random samples over different ranges. Running something which is roughly twice as fast 99.6% of the time and something which is 1.5 times slower (both in series) 0.4% of the time is still a net win. That is of course in C++, in LV the CLFN implementation of the fast method is roughly 1.5x slower than the primitive implementation of the slow method. I have not used this for speed, I use it to get the smallest representation. I have written custom graph and table views in C++ and needed to do the float to string conversion.

gmart, is there any documentation explaining each of the tags returned by "BuildSpec:GetTagNames"? Figuring each of these out on my own will be a real PITA.

Ideally, I would like to place the build in a folder that incorporates the version in the name. Check the LabVIEW 2013 Upgrade Notes: Creating Directory Versions in Build Specifications In LabVIEW 2012 and earlier, if you create a build specification, LabVIEW does not include the build version number in the directory path on disk. In LabVIEW 2013, you can use tags in the build destination path so LabVIEW automatically includes the build version in the directory path. You can include the [VersionNumber] tag in the Destination path field on the Destinations page or the Destination directory field on the Information page of the build specification properties dialog box. Installer builder has the same functionality but uses the tag [ProductVersion].

I finally completed version 1.0 of my messaging system (or messaging architecture if you prefer that nomenclature) and I figured I would post it here and see what mistakes other can find in my approach. My basic goal was to build something that could replace the old school messaging in my pre-LVOOP applications. So, I wanted something that allowed for flat messaging (all processes are peers and can direct message each other) and had some type checking on the messages (I replaced the old typedef'd enum and variant with a message class). I also wanted it to be easy to extend with additional features, such as a message log or the ability to send messages between application instances. Along the way, I added a way of building hierarchical message systems like Actor Framework. I also added subscriptions like JAMA. And I tried out dynamic processes and well as static ones. I am attaching a series of example projects, each one contains the core message architecture components so if you unzip them all, it will overwrite those parts each time. The basic concept of the architecture is comprised of four components: The system class defines the overall functionality of the message system The message class that all messages inherit from The transport class that defines the generic interface for sending and receiving messages The process class that creates the message handler. (This is roughly equivalent to an Actor in AF.) The examples demonstrate remote messaging, dynamic processes, hierarchies of processes and message subscriptions. Most basic example: Message System Basic Example.zip Examples for demonstrating client-server network messaging: Message System Client Example.zip Message System Server Example.zip Example of dynamically loaded processes: Message System Dynamic Process Example.zip Example of a hierarchy of message systems (like AF): Message System Isolation Example.zip Example of message subscriptions (like JAMA): Message System Subscription Example.zip Please comment (good or bad) on the system overall and how it is organized. I am sure there is lots of room for improvement. Thanks for the feedback! -John ps. If you have any ideas for what to name it, let me know, YAMS? (yet another message system) TUMS? (the ultimate message system ) Any other ideas?