ShaunR

Yup. Give 'em as many as you like. You only need one that says "I relinquish all my software rights to you" in lawyer speak and they can sue you for distribution and copyright infringement. Yup. So how would a piece of software "dual licensed" under "Public Domain" and "Non-Commercial" work?

I disagree. Licensing can be about relinquishing your rights (like Public Domain-Germany being an exception). That is why you have terms in many licenses like "transfer of rights" and "non-exclusive rights". Once you have relinquished them, there is no going back and saying "actually I'm now going to make it share-like" - it won't hold in a court of law (nothing to stop you trying, though). Since a license is linked to a product. You can create a new product, but the onus is then on you to prove that the new product under the different licence is dissimilar enough to warrant being termed a "different product" if it is ever contested. It is quite possible (and there have been cases) that you can write some software, transfer your rights via licencing or indeed grant rights to others that supersede yours so you (as the author) are no longer able to distribute, modify or even talk about the software. A simple case of this is the pre-emptive "work for hire" clause in most software developers contracts. If a developer never relinquished any of their rights to the software regardless of any licencing or contract, businesses would never be able to own anything.

That's not a problem since it just means no-one can use it without the authors permission You have to be careful with the Creative Commons ones though. Some of them are not compatible with either other CC or other licences. This may mean that it becomes impossible to post something in the forums and then move it to the CR under a different licence of the authors choosing.

Amen! Where does it state this (couldn't find it in the guidelines) and which type of CC (there are a few).

If you are looking to just zip strings, then the Transport.lvlib has both 32 and 64 bit zlib

It doesn't have to be that central. The only stipulation is that the clients need to be told, where servers are (or discover using network scanning). Say for example you have 10 identical machines (with identical producers) each with a dispatcher. You tell each machine where the other 9 servers are (or probe for discovery). Each machine also has a client that, when it wants a service, uses one of the 9 to interrogate the dispatcher for services on that machine (i've chosen identical to keep it simple but they don't have to be). If that fails, it then tries the second, third, 4th.....and so on until it finds one that is available. Once an operating machine is found, it can then connect to that service. For the identical machines scenario, the system is robust as long as there is one machine in the system. For multiple machines with different services; it is robust as long as there are as many machines in the system that provide at least one of the services that is required that, together, supply all the services. Additional machines in the latter case are then purely for redundancy. You can get around needing a central repository of IP addresses by pinging addresses in a known address range and issuing a services request if an echo is returned. You can then cache that address list.

Your absolutely right, but after that first time you can look at the Doc Open event

You're thinking like a linux user You don't really need to have an add_file program. When you double-click on the file you can pass the file path directly to the viewer as a command-line argument which can be read by LabViEW.

The Json spec (Section 2.4) specifically forbids it for numbers. However. It doesn't say anything about strings We can already cope with recovery of +inf, -inf and Nan (although we will have to add "Infinity") so it's really a decision for encoding (I would suggest string encoding and lose the type but a switch might be more appropriate as you suggest). PHP will throw an error if the type is a numeric, but will be quite happy if it is a string and, as PHP is untyped once parsed it really makes no difference.: Some Javascript engines allow it since it is valid Javascript but not valid Json however there is no concensus. cmj-JSON4Lua: raw tostring() output (invalid JSON). dkjson: 'null' (like in the original JSON-implementation). Fleece: NaN is 0.0000, freezes on +/-Inf. jf-JSON: NaN is 'null', Inf is 1e+9999 (the encode_pretty function still outputs raw tostring()). Lua-Yajl: NaN is -0, Inf is 1e+666. mp-CJSON: raises invalid JSON error by default, but runtime configurable ('null' or Nan/Inf). nm-luajsonlib: 'null' (like in the original JSON-implementation). sb-Json: raw tostring() output (invalid JSON). th-LuaJSON: JavaScript? constants: NaN is 'NaN', Inf is 'Infinity' (this is valid JavaScript?, but invalid JSON). (NB. Twitter allows it,but I have no idea what library they use. Lots of people complaining that they get errors from parsers when recovering feeds and the general mood is that parsers should just cope with it).

They didn't restrict it. It was a condition in the licencing.

This thread discusses a couple of techniques

He also has a website dedicated to this at http://blog.evexiallc.com/?p=37#comment-54. Might be worth asking the question there also.

I gave up with automatic merging a long time ago with any system. The fact that LabVIEW (especially 2009) re-compiles at the drop-of-a-hat makes most conventional source control systems impotent (and don't get me started on the LV Merge tool). I now only use them for micro-versioning. I rely on comments to identify and track changes and, although it requires an anal approach to commenting, works pretty well-at least for my workflow. You probably saw (simpler versions of) my comments in the code (added, modified etc). Just search for <SR>.

Yup. It used to be 50 about 15 years ago (we moaned like buggery!). There is no restriction now, however.

Yes. In fact, it can be and array of anything including other objects and/or arrays so even this is valid: "myarray":[[123,223,{value1:MyVal1}], value2:"wally"] This is why, for LabVIEW, it is much better for us to rely on the programmer to decide how to get the info out since with the polymorphic VIs we limit his options to valid LabVIEW types with a fall-back of the raw string. On a similar note: You don't have to have quotes around a string value value either (it's only required for labels). I have no position on this. I took the decision in the SQLite API to encode NaN as a string rather than NULL but that was so that extra detection wasn't needed when converting back to LabVIEW types (Search and Replace NULL for NAN). It was an issue of performance that we may not be so fastidious about here. Other languages may not have a representation for NaN, but LabVIEW doesn't have a concept of NULL either except perhaps "empty string" which converts to zero for numeric types. Off:Topic: Way to go to get the last word in (comment then get the mods to remove it all...lol)

Took Toms version (love the "prettyfying" btw ) and added support for escaped quotes in strings (\"). Escaped quotes are maintained in the variant table and only converted when read out via the polymorphic VIs. (back-saved in 2009)

BSD is hardly a walled garden. I was looking forward to your Json implementation (in fact I looked several times before this and tried several things to make it work for my use case-without success). However, it was/is doomed if it can't do normal LabVIEW stuff. I'm sure for object serialisation it is the bees knees, but it's not whats needed for us proles. This, however, is exactly what we need, it didn't take us months and, although my initial thoughts were not in favour of a class solution for the obvious reasons, Drjdpowell has demonstrated a splendid solution for the parser (although I'm not sure what he will do about the cluster order ). Between Drjdpowell, myself and Ton, It is a great example of the labview community pooling their efforts through discussion and providing an open source solution. It should be celebrated, not bogged down in a licencing diatribe. I can understand your frustration due to the time and energy put into your API. But don't go throwing your toys out of the pram because it can save you effort or you wish to participate but the hindrance is your own companies policies. The licensing isn't an issue except if NI want to take ownership and I expect this is a similar stance to what you alluded to in terms of previous discussions between Lavag and NI. There are lots of projects on Lavag that never get the participation or feedback that the author expects ("If you build it they might come"). That's no a sleight on their software, or indeed, their skills. It just means it's not that big a deal for others or it doesn't fulfill their requirements. Don't feel put-out that people didn't pick software "A" over software "B". It just means "A" didn't fit their requirements as well as the other.

Hardly "fundamental" to LabVIEW (mountainous mole-hills?). It's an addon library. Nothing more. 1/2 of it uses OpenG variant stuff so (much to my chagrin) that would be a far better place for it. So NI should pay for it then if it's that great and would enhance their business The only thing stopping NI from using it is NI

You mean that NI cannot take full and unconditional ownership and commercially exploit them if they so choose. It's under a BSD licence which is where it belongs and I can easily see it being included in the OpenG stuff.

As far as I was aware. VI scripting isn't available in the run-time engine. It is (was?) development only.

Middle Class Rapper

I think its extremely useful and well worth maintaining. I noticed that in the readme you have a list of things TODO that I might be able to help with (would need the source and a bit of guidance though). The later versions of LabVIEW have SSL DLLs that might make things easier (from multi-platform point of view) although they seem very inflexible. What is the licencing?

Just has a cursory glance. But it looks like you are calculating the coefficients and passing the XY parms for the linear fit twice with the same data (it's only the weightings that change from the first "fit" to the second) . You could pre-calculate them in a separate loop and just pass them into the other loops. Also, you might benefit from passing through the x array (through the coefficient vi).

A lot of stuff you need for the network "architecture" is probably contained in the Dispatcher in the CR. It can do the "clustering" by simply placing the dispatcher in the right place and pointing the publishers and subscribers to it (can be on the same machine or centralised and you can have multiple dispatchers spread out accross many machines). What you send and what you do with it is then up to your implementation. I wouldn't suggest UDP for this, however, unless you are going to write a robust protocol on top-which is a lot of work and mitigates a lot of the advantages.