ShaunR

Timestamp is probably the "odd-one-out" since it can't be interpreted any other way apart from as a timestamp. All the numerics are currently coerced (and output default if coercion fails-NaN for doubles, 0 for others). If the input type is a String Array then the ouput is an array of one literal. Are you suggesting that if the JSON stream has a double and an Int is requested then it should throw an error? I'm not sure I'd find that very useful (probably more of a pain in the backside) and if I wanted a U8 from an U64 (say to get rid of a coercion dot) then I would have to convert it manually.

Not throwing an error makes it quite hard to find out what the problem is in even moderately sized streams. However. I'm of the opinion that it should at least try a best guess and raise a warning (preferably identifying where in the stream). Errors are a two edged sword since you can end up halting your program just because someone left off a quote (we are heavily reliant on quotes being in the right place). I'm just waiting for Ton to give me a login the the repo since I've implemented the decoding of escaped chars (not unicode I might add-we need to think about that). It doesn't work for your modified JSON_Double[array] though, since it is utilised in the Get Item By Name rather than Get Text. I have, however, made it a VI so you can put it where you think best.

Well. Tell us which licence IS acceptable then. Alternatively, NI could create a licence (LabVIEW Open Source Licence?) that doesn't require giving up IP then everyone will be happy.

As the NI run-time (for executables) or the development IDE must be distributed to use anything; from NI, that aspect is a bit moot. If it wasn't the case, and there weren't other examples that require attribution already shipped; then I would probably have agreed with you by now.

The reason is credit where credit is due. If someone wants to use some software and not even give the author credit for it (or even pretend they wrote it themselves). Then they really don't deserve to use the software. You are obviously trying very hard to find a way through, but the real question to ask is "what is it about the Apache licence that allows NI to use software under that licence?". The Apache licence has far more restrictions than BSD (including attribution). However, I think it is more a case of will than law or technicalities which is the stumbling block. And without a corporate lobotomy, that's gong to be hard to overcome.

I've already implemented the removal of quotes. The only escaped chars that I know "must" be escaped are unicode strings and I'm not sure what to do about that with LabVIEW not supporting Unicode without using OS dependent code.

Do you want to list out the tasks that need to be done so that we can apportion them between us?

Are you dynamically loading the addons using a path? If so. You should be aware that when compiled into the exe the path changes so c:\temp\myfile.vi becomes c:\temp\myexecutable.exe\myfile.vi

Yup. I think originally they were using it to invert (instead of using the primitive) and during debugging/mods changed the booleans around so it was completely redundant.

Problem solved. There is already a Json library on NI.com written by an NI employee that AQ can use and can be included in LabVIEW. So we can now broaden the discussion away from the Json library here to a more general Lavag CR to NI compatibility without getting bogged down on a specific piece of software.

In the same vein. Here's one I've seen before

Well. The latter would be true if we released the next version as "Public Domain" and the former would be true even if we posted it there under a BSD licence. So where's the problem?

I'm not sure that's true since rights assignment requires a real signature. What are you going to do about the OpenG toolkit stuff that the API uses? There is a solution I think, however. We release the next version as public domain (which OpenG allows us to do I think), then it can be posted on NI.com (as their EULA demands). Basically we give up our rights but to no-one.

Do you lose all the windows title-bar transparency? (i.e. it's dropping out of Aero)

Gives a whole new meaning to being "two faced"

The only solution that will satisfy NI is ownership and they seem completely intransigent on that point. It looks like*you* (meaning not NI) will have to jump through all the hoops just so they can use it and I'm getting to the point where I just think the risks and the hassle outweigh the benefits (not that I see much in the way of benefits to begin with ). There's too many unknowns at this point; all the risk is ours and NI are taking none . Everyone else is quite happy with the current state of the licencing, so I suggest we wait and see what happens with another piece of code (like you suggest-the trim whitespace or something similar) - find out exactly what the process is, what the Software Freedom Law Center advise and what the implications are. I'm in no rush to a) be a guinea pig and b) see it disappear until next august or even completely! (yes I know November is when the new features are defined but once again, that's NIs constraint not ours). NI have a whole department of lawyers on payroll, get them to show by example how to get around NIs own policies (they wrote them) without the community bending over forwards and dropping their knickers.

Especially the bald ones

Yup. The trick is to mount the camera above the door looking down. Then you don't suffer from occlusion,have fairly regular shapes and a constant, uniform background to contrast against. Once you get used to it, you can even start counting prams, pushchairs, wheelchairs, adults/children etc.

That's because it is PCRE (Perl Compatible Regular Expressions). How about this for graphical programming? http://www.ioccc.org...hamano/hamano.c

Yup. Any application I write after 6 months has elapsed

http://zone.ni.com/devzone/cda/epd/p/id/1505

Thats another can of worms. What about mine and Toms contributions in relation to NIs TOCs? I don't think just posting it there solves all NIs self inflicted problems.

Indeed. But as all LabVIEW software must be distributed with either the IDE (for source) or the run-time engine (executables) this doesn't seem prohibitive. In fact the shared directory contains a copyright.txt that lists all the attributions. In fact it states in the NI Forums TOCs that you must warrant So. Public domain stuff can be posted and, by implication, can be used by NI. Just having re-read the NI TOCs and saw the liabilities disclaimer for user contributions which only disclaims NIs liability. Does this extend to the uploader/author via the other disclaimers in different sections? . This would be reason enough for me not to post software on there at all. On Lavag we are covered by the Creative Commons disclaimer (apparently ). There are so many ambiguities or "open to (lawyer) interpretation" aspects to the NI site. Lavag is simple and straight forward. You are much less likely to have a hoard of lawyers bearing down on you (and we all know the deepest pockets win regardless of right/wrong). By posting code here on Lavag, the interests are more aligned with "community" than business.

Of course. Rather than in the best interests of the author or even it's users (although NI is arguably better that most companies in this respect). Rather than argue about "legal" implications (NI have a team of lawyers, where as we don't) I suggest the legal issue is passed to the Software Freedom Law Center and let them advise as to what it means if BSD software is posted on the NI site. The main issue for me, though, is that I don't believe NI cannot use software if it is under a licence (whatever it is), they just choose not to if they can get away with the author signing all their rights away to them (makes good business sense). Whether the NI site terms actually mean that or not, is a lawyers question. In my laymens reading it "looks" like it is just implicit distribution rights, so exactly the same problems as are being proffered here would apply even it it where posted there with or without a licence. Conversely, if it isn't an issue there, then it should also not be an issue on Lavag for the same reasons. (Most sites' TOCs are there just to protect the site owner from breach of copyrights should someone else upload copyrighted content and allow digital distribution). I'm reticent at that interpretation, however, since there is an obvious determination that software should be posted there instead of elsewhere and I can only think of one reason why that would be especially since other licenced software is distributed with LabVIEW under much more strict conditions than BSD..

Depending on the type of noise; a running average or median filter might suffice.