d_laub

Well it's my pet and I'm keeping it :-P

My pet theory about the asynchronous wires is that they're a necessary feature for something big that hasn't been released yet. The Channel webpage mentions they'll expand them to "cross-target" communication in the future. I think that's the "killer app". If you combine cross-target async wires with the Java-based runtime engine they alluded to at Wednesday's keynote, that might point to a big change in the portability of LV code. My wild speculation is they might be working on the ability to transparently virtualize VIs across multiple targets. Like, you make a simple producer-consumer VI using a channel, and the VI Server can split the producer and consumer and run them on separate targets (or even spawn thousands in the cloud for massively parallel computing) just as easily as running the VI locally. It could run your data acquisition code on multiple PXIs, PCs, cRIOs, and cDAQs sprinkled all over as if they were all in the same chassis, and could dynamically shift the processing load around as needed. Java runs on tons of platforms, which could allow them to run LabVIEW in even more places, and there are lots of great tools already for virtualizing Java applications, so they wouldn't even need to do the most difficult parts.

Great BBQ. It was good meeting everybody. Thanks to all the organizers.

I just posted this topic: 16552-variant-config-format-timestamps-in-human-readable-form, and wanted to record it here. Saving timestamps to a human-readable format would be useful.

Currently, saving a date/timestamp to a config file saves it like this: Time Stamp = "00000000ÍAm#ß~p0000000000" I'd much prefer they be formatted like: Time Stamp = "2013-02-13T16:17:39.873Z" I realize this may run into some localization issues, but I'm fine with defaulting to the ISO 8601 format (or, you could change the "float number format" terminal to a generic "format string" input, and have float/time format strings line-delimited). The code to do so already exists in "Format Variant Into String", it checks if a waveform is a datestamp type before writing. This just needs to be ported over to the "Write key (variant)" VI (and correspondingly, to the read VI as well).

For naming, I think that it'll be important to companies to maintain their brand through their package name. "JKI Right-Click Framework" or "GOOP Develoment Suite" should be the names, since the packages are not just components in a library (where such a naming convention is sensible), but an actual product name which the developer has an interest in branding and marketing. I don't imagine picking up a shiny product brochure titled " Speed Development With jgcode_rpk_ni_system_style_daqmx_controls-1.0-1". There still needs to be a way to quickly and easily find relevant packages as the number of packages grows (as discussed above), for which I think a combination of text search and a tag cloud would work well.

Hmm... So I spoke with my employer and he seemed a little less thrilled about contributing to an open source project than I anticipated. I think that having other contributors would accelerate the development, and our company has no interest in marketing this kind of thing, so I'll keep at it. -Dan

Hi all! I met a number of you at NI Week, and I'm looking forward to getting more involved with LAVA. I've been working on an Object-Relational-Mapping (ORM) system for LabVIEW objects. I want to gauge the interest in developing this into an open-source package. The jist of it is a 'presistable object' class that can be inherited. The child class overrides a VI to provide the necessary SQL schema information and the object's internal data (can be as simple as passing the child's private data as a cluster variant, plus a few constants) and a VI for the parent to set data with. The parent class then provides the Load, Insert, Update, and Delete functionality by dynamically building and executing the queries, and acting on the child. I've gotten this far, but there's a huge list of features I haven't gotten to implement yet, though I think many will be easy once a versatile enough architecture is built. Things like: - Connection pooling - Atomic transactions with roll-back - Aggregation: . - Proper handling of object relationships and heirarchy . - Allow for collections of objects, and optimize the SQL queries to batch operations together . - Allow selective child loading (i.e. a 'car' class contains a collection of 4 'tyre' classes, they may (or may not) be loaded at the same time as 'car') (and many more) Current status: still contains some proprietary code, I'd have to remove this first before I could share it, and it's not well documented yet. It's on its 3rd iteration and at the point where I've learned enough that I'd want to start again fresh to improve the architecture, but I think I want to attempt to implement aggregation first, since I'm sure many new architectural issues will surface. I could really use input on the architecture of the design, especially from people familiar with LVOOP or ORM's. There's also a lot of good old-fashioned work to fill out all the features and test everything. If you're familiar with some of the ORM's out there, this is nontrivial, but useful and challenging. There will also be some good spin-offs. I've already built a great library that simplifies and extends the LV db toolkit (like load/save cluster with strict late-bound typing, NULL representation for native LV types, etc.). Let me know if you're interested in this kind of project (to use or contribute to). Cheers! - Dan Lauber