ShaunR

You included icons Indeed. It is the getting the value back out that is the problem. Same as with variants/clusters. It's getting interesting now, however How about a slightly modified JSON of one of your examples? (Get the "NestArray" Values) {"T1":456.789 , "T2":"test2", "Nest":{"ZZ":123,"NestArray":[1.3,2.4,1.6] }} I don't think it is sufficient to simply have a look-up as you have here, but it is close.

Hmmm. Not sure where I got that from. Certainly in the LabVIEW Timestamp Whitepaper I just found it shows it is indeed 128 bit so I;m obviously wrong. But I have recollections of it being 12 bytes as it was one of the improvements (adding a timestamp) to the Transport.lib (which after some research I made 12 bytes). Since then it's just stuck as one of those anomalies to my expectations since 12 is a bizarre number.

Yup. Keep drinking the cool-ade It probably took me the same amount of time to write the concept as it did for you to read my posts...lol

Well. A simple way (but I can think of better, more complicated ones- linked, list, variant lookups et al) is to make the column in the 2D array significant and use a hierarchical tag e.g. "first:second:third". But this is inefficient (for lookups - although probably not prohibitively so) and requires a much more complex parser than I'm prepared to write at the moment (which is where JZollers stuff comes in ). I'm hoping someone has a "slick" aproach they've used in the past that we could perhaps just drop in The intermediary format is really a secondary consideration apart from it needs to be easily searchable, structure agnostic and not make the parser overly complicated just for account for "type". A 2D array of strings is just very good for this particularly as the input is a string and requires string manipulation to extract the data (regex gurus apply here...lol) Don't forget my comments aren't trying to address the existing code or how it's coded,per se. It's a limitation I perceive with using clusters and variants (or more specifically, variant clusters) as the interfaces.

Some things perhaps you didn't know about the timestamp that may shed some light. In 2009 it is also 1ms. The 14ms you are talking about is probably that you were using Windows XP where the timeslice was about 15 ms (windows 2000 was ~10ms). . LabVIEW timestamps are 12 byte (96 bit not 128). The upper 4 bytes are not used and are always zero.

This is exactly what my example is (analogously - Classic LV to LVPOOP). The 2D intermediate string array is Child2 with each row being Child1 and "lookup.vi" is the accessor (Child3). The parent is the DVR. Only we don't need all the extra "bloat" that classes demand. I expect if you were to lay down an example, the internal vis that do all the the real work in your classes (there are only two) would look remarkably similar. If you want a class implementation, then you might be better off by looking at AQs. (I could have also represented the nesting aspect by making the column of the 2D significant. But I think there may be a better way.).

This is what I've always wanted it to do.

OK. I thought I'd put some meat on my thoughts and try a proof of concept that people could play with, poke fingers at and demolish. I'm not in anyway trying to divert from the sterling work of Jzoller but I hope that perhaps some of the thoughts might light a bulb that can ease further development of his library. Don't get your hopes up that I will develop it further as JZollers library is the end-goal. Of course. It looks like crap, doesn't work properly (the parser is, how you say, "basic") and the "nesting" still needs to be addressed since it cannot cope with non-unique identifiers (I do have a solution, but would rather hear others first) So don't expect too much because, as I said, it only a "Proof of Concept".

Whilst the mechanics may be thought of in that way and indeed, both may be coerced to emulate the properties of the other, they are actually different topologies. Queues are "many-to-one" and events are "one-to-many". ....but with no type! Agreed I've been bitten by these sorts of things in the past too.....they are a real bugger to track down and the solution is invariably to use a queue instead.

Me too. I was hoping someone would come up with a generic solution before I had to, as my first encounter proved it was a "non-trivial" problem. These were my thoughts about Json and LabVIEW in general from the first skirmish........ The thing about using variants (the feature that never was ) and clusters is that it requires a detailed knowledge of the structure of the entire Json stream at design-time when reconstituting and getting back into LabVIEW (not an issue when converting "to" Json). We are back to the age-old problem of LabVIEW strict typing without run-time polymorphic variant conversion. To get around this so that it could be used in a run-time, on-the-fly sort of way, I eventually decided that maybe it was better to flatten the Json to key/value string pairs (here I go with my strings again...lol) that could then be used as a look-up table. Although this still requires prior knowledge of the value type if you then convert a value to, say, a double - it doesn't require the whole Json structure to be known in advance and instead converts it to a sort of intermediate ini file which simplifies the parser (don't need to account for every labview type in the parser). In this form, it is easier to digest in LabVIEW with a simple tag look-up which can be wrapped in a polymorphic VI if "adapt-to-type" is required. It also means, but perhaps a bit out of scope for consideration, that you can just swap the parser out to another (e.g. XML).

Forgot all about your little project until I read Reading Json Just had another look (no errors now). I know it's in it's infancy, but I wasn't really sure how to use it if I wasn't using classes. Is the intention to only support classes?

I don't use refs at all The main reason I use named queues is that it is part of the message "routing". This is why queues are (IMHO) preferable under these particular circumstances since you don't miss messages and race conditions are alleviated (although not necessarily eliminated depending on your macro view). With queues you also have asynchronicity but you can also guarantee the order which, for control, is highly desirable.. Or you could begin sub-paneling (not quite sure if I'm understanding what this is correctly), send the shutdown and the sub-panel would appear then disappear as each element was removed (or you could flush it on the off chance it hasn't been enacted yet). I just think for this particular scenario, queues have many advantages over events, not least that you don't "lose" messages just because someone isn't listening.

Named queues But in a less confrontational aspect. The issue I have is with the idea of "stuffing". That you create a registration, maintain it and generate events, whilst not consuming. At least with a queue you can monitor the elements and even restrict the size (for the scenarios where you want to "stuff")..

Been there, done that; thrown it in the bin

So how is that any different from anything else (e.g.QE Messaging) except you can create memory leaks?

On the surface, it looks to me like an anti-pattern (maybe in the minority.....again....lol). The beauty of events is that you can fire them and they don't use resources unless there is something listening for them. That is one of their main advantages over queues This just seems to be trying to circumvent that feature to find a use (a singular use from what I can gather) and it doesn't really add anything to mitigate the drawbacks of events or, indeed, offer anything that cannot be achieved in other ways with more transparent foot-shooting opportunities. Can you give a real-world example where you might use it?

Indeed. In fact, there are very few browsers now that do not support them. I've gone off Chrome at the moment though. Nothing to do with the features or the browser itself (which is arguably the best). More to do with it being so nosy and by default trying to track everything you do and put all your private info on their servers (as I found with my contacts list one day). Still. Not as bad as the iPhone.

Well. Consider you have a public function called "Calculate". This function ,amongst others, uses a "Check For Divide By Zero" private function. You can craft a test case that that can be applied to the public function that specifically supplies a calculation that will result (at some point) in a divide by zero. You are using your knowledge of the internal workings of the "Calculate" function to indirectly test the "Check For Divide By Zero" private function. This is "Grey-Box" testing. The major bonus to this approach is that your test case code can be generic (it only has to interface to the "Calculate" function) and just supply different calculations but test multiple paths through the private functions without having to create code for all-and-sundry. You can even do things like put thousands of your calculations in a file and just iterate through them, throwing them at the "Calculate" Function. The test code is not important, the tests data is what requires consideration and each piece of data can be crafted to test a path or target a specific private function within the public function. As an aside. The examples that ship with the SQLite API are, in fact, the test harnesses and provide 99% coverage of the API (not SQLite itself, by the way. that has it's own tests that the authors do). That is why the examples increase when there are new features

Sweet! Any Android smartphone/Tablet (Like your Galaxy Tab)you can use Firefox, Safari, Azura, Opera Mini, Opera Mobile etc They all work with Websockets (as long as it is over a network rather than 3G). There is limited support in the Ice Cream 4.0 native browser but before that (Gingerbread etc) .... nope. iPhone/iPad uses Safari so that's not a problem. I'd be interested to find out more about the Bravia (what OS/browser etc). Sometimes websockets are supported but need enabling as they are off by default (like Opera). I think the issue with TVs will be purely down to being able to install apps if the native browser doesn't support them. So it looks like it's only the Sony Bravia that is the odd-one-out. I wonder also about the LG since most smart TV's have gone for either Linux or Android. Well. A bit more digging and it looks like the Bravia Smart TVs may be using Opera BRAVIA TV, Opera So it looks like that may be a go if you can enable it! N:B: I was mistaken earlier. Opera Mini doesn't support them but Opera Mobile does).

Well. There is white-box, grey-box and black-box testing. Testing the public interfaces is generally black-box (test the exposed functions without knowledge of the internal workings against a spec). Testing individual methods is generally white-box (full factorial testing with detailed understanding of the internal workings of the function). Testing public methods with specially considered test cases, crafted to exercise internal paths within the functions is grey-box (and also requires detailed knowledge of the internal workings). Positive black-box (i.e. test for what it should do) and negative grey-box (i.e test for what it shouldn't do) together will always give you the best test-cases vs coverage than any amount of white-box testing. If you want to write 3 times as much code to test as the original code and have a 95% confidence. Then black+white is the way forward. If you want to write a fraction of the original code in test cases and have a 90% confidence, then black+grey is the way (and you won't need to solve the problem ).

Another thing you can do is set the subsystems execution system to something like "Other1" then dynamically launch it. This will force it into a different thread pool and the LV scheduler should do the rest. It will also give you better control over how much slice time it can consume by setting the different priorities (this assumes your DLL supports multi-threading and doesn't require the dreaded orange node).

Thanks Asbo. I just spat my coffee all over my keyboard

Actually. There are more like 5 in total. Saphirs is fully commercial, mine is free for non-commercial and the others are free but generally have limited features and support on the various platforms (LabVIEW x64 for example). But all that is really for another thread (even though it is YOUR thread....lol).

Because a fast, self contained database is a superb and robust solution to many of LabVIEWs applications.

The commercial licencing is changing (check the site next week ). That won't stop you downloading and playing though.