ShaunR

I am downloading multiple files at a time, where each file is made of multiple segments or parts to be downloaded.

That's the key, right there. You're only lacking encapsulation depth at the moment. The thing to remember about queues is that they are a "Many-To-One" paradigm. So you have Many segments to One file and Many Files to One Batch.

I would tackle it this way.........

Create a "Download File" VI (launched re-entrantly) which you pass all the segments (a list?) that are required for that file to. It, in turn, then launches the individual segment downloads (again re-entrantly) by iterating through the list. The last thing a segment download VI does just before it exits is to post the segment to the Download File vis queue (Which will be named something like Download File.vi:3 i.e the clone name). The "download File" vi receives all the segments (for that one file) and, when it has all of them, reports back to your main app. The main app just sits and waits for completed files to come in.

In terms of queues, you only really need the return queues. So the Download File vi creates a queue to receive the segments (using it's clone name) and also has a queue named, say, "~download_files~" that is used to send back to the main app. All the download VI clones share the latter queue. The Download Files VI passes it's clone named queue to each of the segment queues (or you could get fancy and calculate it from the caller) so that they can use it to report back the individual segments to it's parent (the Download VI clone that launched them).

Theoretically, the not-on-the-pallet VIs in vi.lib\Utility\VariantDataType should blow the OpenG stuff out of the water, as OpenG has to flatten the data to access it (expensive), but my only experience with the VariantDataType Vis is that they are glacially slow.

In theory. Practice and theory are the same. In practice, they are not

Historically the openG stuff is generally more performant since a lot of them perform the same functions as are available in LV, just optimised. Of course with the NI grown ones they can have C functions in the exe to do the heavy lifting, but usually they use nodes that run the the UI thread which mitigates any performance gained

Saying that. I use the vi.lib getTypeInfo,GetCluster/numeric etc but I haven't bench-marked them since they are "Hobsons Choice" for me.

OK, but to me it seems silly for anyone to avoid OpenG yet use this (far, far less tested through experience) third-party open-source software. I’d rather offer the whole package to OpenG.

I'm not opposed to that either but I thought Ton was talking about it going into the Lavag Tools Network..

Now, do it with higher performance and you’ll get me interested.

Yeah. Well its got LVPOOP in it so that's not an option.

Shaun,

I am looking at the VIPM package that Ton and I have put together. Shall we divide into two packages, one not dependent on OpenG and one that contains all the Variant stuff? So people who can’t use OpenG can still use the core functions or your extended API? I can do that just be replacing one OpenG function, Trim Whitespace, in the core (can we use your “Fast Trim” instead).

Ton,

You currently have the package installing under LAVA; don’t we need a LAVA tools approved package before doing that?

If you can wait until next weekend, I'll replace all the openG stuff so it's a self contained lib. Just a bit busy at the moment finalising the websocket demo, but that will be finished this week.

Get your IT department to handle all the internet stuff and inserted in a DB. Then just query the DB using the Database Toolkit. You won't have to worry about security, webservers and firewalls or have to maintain webpages, log-ins, registrations etc It will also be fully integrated with your corporate website. Your labview stuff will be safely isolated behind the corporate firewall.

Well. this is how it works at present.

— the string “Hello” as a DBL? Is this NaN, zero, or an error?

NaN (after all NAN= Not A Number)

What about as an Int32?

0

A timestamp?

Like I said. Odd one out since all the other LabVIEW "from Strings" have a default behavior defined (they don't return errors)

— for that matter, what about a boolean? Should anything other than ‘true’/‘false' be an error? Any non-‘null'/non-‘false' be true (including the JSON strings “null” and false”)? Or any non ‘true' be false (even the JSON string “true”)?

True/False, Yes/No, On/Off 0/>0 are catered for. anything else equates to False.,

— “1.2Hello” as a DBL? Is this 1.2 or an error?

NAN

— or just “1.2”, a JSON string, not a JSON numeric? Should we (as we are doing) allow this to be converted to 1.2?

1.2

These

— a JSON Object as an Array of DBL? A “Not an array” error, or an array of all the Objects items converted to DBL?

— a JSON Scalar as an Array of DBL? Error or a single element array?

— a JSON Object as a DBL? Could return the first item, but Objects are unordered, so “first” is a bit problematic.

These I see as purely internal representations (lazy typing-only define type when recovered)

And what if the User asks for an item by name from:

— an Object that doesn’t have that named item? Currently this is no error, but we have a “found” boolean output that is false.

— an Array or Scalar? Could be an Error, or just return false for “found”.

The default value and a warning?

Then for the JSON to Variant function there is:

— cluster item name not present in the JSON Object: an error or return the default value

The default value and a warning?

Personally, I think we should give as much “loose-typing” as possible, but I’m not sure where the line should be drawn for returning errors.

I don't think any typing should be contained in the objects at all. Only interpreted when recovered to the best of our ability (as it does at present). Why enforce typing internally when there is none in the Json objects. Type is purely a convenience for wiring up to indicators/controls

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.

Actually, another possible error choice is to basically never throw an error on “Get”; just return a “null” (or zero, NaN, empty string, etc.) if there is no way to convert the input JSON to a meaningful value of that type (this follows the practice of SQLite, which always provides value regardless of a mismatch between requested and stored data type). Then perhaps all “Get” instances should have a “found” boolean output.

Ton, Shaun, what do you think?

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.

There's no VI that falls into that category. There's no DLL that isn't core to LV itself that falls into that category. In short, everything that currently ships with LV that falls in that category is installed by LV and thus requires no secondary notation from a user. A VI in vi.lib is not part of the runtime engine and so would require separate acknowledgement by any EXE that used that VI.

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.

For goodness sake, Shaun, have you listened at all to my explanation for why the attribution requirement is a problem? It has *nothing* to do with NI and everything to do with the next user downstream. It's an impossible tracking problem.

“You seldom listen to me, and when you do you don't hear, and when you do hear you hear wrong, and even when you hear right you change it so fast that it's never the same.”

Marjorie Kellogg

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.

I was digging into the BSD license and exploring the reason for the attribution requirement.

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.

First thing we could use are functions to convert between JSON-format strings and regular LabVIEW Text (escaped characters, encoding, add/remove the quotes). I’m weak on regex.

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.

I’ve added a new version to the CR (sorry Ton, I will need to learn how to use Github).

I added a JSON to Variant function. Note that I’m trying to introduce as much loose-typing as possible (very natural when going through a string intermediate), so the below example shows conversion between clusters who have many mismatched types, as well as different orders of elements. It would be nice to think about what type conversion should be allowed without throwing an error.

And I’ve started on a low-level set of Get/Set polymathic VIs for managing the conversion from JSON Scalers/Arrays to LabVIEW types (very similar to Shaun’s set but without the access by name array). I’ve reformatted two of Shaun’s VIs to be based of the new lower-level ones. The idea is to restrict the conversion logic (which at some point will have to deal with escaped characters, special logic for null (==NaN), Inf, UTF-8 conversion, allowed Timestamp formats, etc.) to be in only one clearly defined place. At some point, I will redo the Variant stuff to work off of these functions rather than relying on the OpenG String Palette as they do now).

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

No way!

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.

How about this gem?

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

The EULA does not require it to be public domain. It requires that you own the copyright or it is in the public domain I.e. you are not breaching copyright by posting it.

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?

You can be sued for anything you post to LAVA also if you didn't have the legal right to post it.

That's what the law requires... you're the copyright owner. You have to do something to allow NI to use it. There's nothing NI can do on its own to appropriate the rights -- and you wouldn't want there to be a way to do that.

We've made it as easy as possible to transfer those rights through the ni.com EULA. I'm still arguing for changes to that EULA that would clarify some aspects, but it's the only mechanism I have ever heard of for you to easily state unambiguously, "I don't mind if NI unconditionally uses this, sells this, and redistributes this." If you know of another mechanism, I'd love to hear it.

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)

http://forums.anandt...72&postcount=15

Gives a whole new meaning to being "two faced"

Uh, wait, what? Can I be sued for stuff I post on NI.com? Sounds like an argument to not post anything on NI.com. Ties back to my previous point about the NI.com Terms of Use containing disclaimers to protect NI but not posters; do I need to add a legal disclaimer to every post and uploaded sample VI?

And if something is adopted into LabVIEW, it becomes NI’s responsibility, surely?

That’s why I like the “1 clause BSD”, dropping the binary requirement. The source code requirement is trivially satisfied by placing the license in the FP or BD or hidden away in the documentation.

BTW to OpenG developers (JG if he’s reading): does OpenG not have some transfer of copyright to OpenG itself? It will be impossible to change licensing terms on OpenG once some of the authors die. I’d like to propose dropping the binary clause.

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.

And as an added bonus, people think it's way creepier when cameras are looking down at them!

Especially the bald ones

Hello,

I'm not familiar with the Vision package and I would make you a question.

Does you know if it should be possible to use it to count people entering or exiting a door?

Thanks

Max

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.

Reminds me of perl code.

That's because it is PCRE (Perl Compatible Regular Expressions).

How about this for graphical programming?

http://www.ioccc.org...hamano/hamano.c