ShaunR

Many people use Rolfs oglib_pipe but the real solution is to come into the 21st century and stop writing CLIs.

Not really a LabVIEW thing. You can manage Windows devices using the SetupDI API and you would call them using the CLFN. If that didn't do it for you then you'd be back down in the IOCTL where there be monsters.

Pharlap is a walk in the park VxWorks was the one that made me age 100 years I actually have some source with the relevant changes but never had a device.

That's nothing to sniff at. At some point you just have to say "this is the wrong way to approach this problem". JSON isn't a high performance noSQL database - it's just a text format and one designed for a non-threaded, interpreted scripting language (so performance was never on the agenda . )

300MB/sec? If you want bigger JSON streams then the bitcoin order books are usually a few MB

I don't use any of them for this sort of thing. They introduced the JSON extension as a build option in SQLite so it just goes straight in (raw) to an SQLite database column and you can query the entries with SQL just as if it was a table. It's a far superior option (IMO) to anything in LabVIEW for retrieving including the native one. I did write a quick JSON exporter in my API to create JSON from a query as the corollary (along the lines of the existing export to CSV) but since no-one is investing in the deveopment anymore, I'm pretty "meh" about adding new features even though I have a truck-load of prototypes. (And yes. I figuratively wanted to kiss Ton when he wrote the pretty print )

I was initially manipulating the string but then you demonstrated the recursive approach with objects for encoding which was more elegant and removed all the dodgy string logic to handle the hierarchy. Once I found that classes just didn't cut it for performance (as per usual) I went back and solved the same problem with queues. The fundamental difference in my initial approach was that the retrieval type was chosen by the polymorphic instance that the developer chose (it ignored the implicit type in the JSON data). That was fast but getting a key/value table was ugly. Since all key/value pairs were strings internally the objects made it easier to get the key/value pairs into a lookup table. Pushing and popping queues were much faster and more efficient at that, though, and didn't require large amounts of contiguous memory.

Retiring? Promotion? Sabbatical? Management?(cringe)

Yes. I now use the SQLite JSON capabilities for in-application uses but I also have my own parser for Websockets and comms. The other JSON library was just too slow for streaming Websockets and the NI primitive is as much use as a chocolate fireguard because it crashes out if anything isn't quite right. (which I've raged about before). If you want to see this sort of use case then take a look at blockchain.info for the real-time transactions. I went back to my original ones that I showed in the original thread and developed those further by having a format case for each and every type and used queues for the nesting (kept the polymorphic reads the same as the original). It is acceptably slower than the native one and orders of magnitude faster than the other library on large data (much the same for small snippets) although it isn't as good with all the different encoding which it just hand-waves to a string.

Quite a few NAS boxes do this nowadays automatically with smart folders. As I prescribe to the "if it aint broke, don't fix it" school of laziness I would probably tell IT to get one or make them offer me the service and leave my software alone

Note: That is the BSD-2 Clause licence. There is also the BSD-3 Clause liicence which adds a clause disavowing the use of the providers' name for promotional and/or endorsement of derivative works.

Lots of caveats and manual optimisation (loop unrolling). Not all MS functions are suitable. Ability to meet RT deadlines you require is suspect. Risk analysis would probably yield "don't touch this with a barge pole". If push came to shove then maybe some things might be possible with the node but the heavy lifting would probably need to be offloaded to meet spec. You would probably find the program that was written for the node isn't compartmentable to be able to offload defined chunks without complete refactoring of the script code.

I used LabSQL when the DB toolkit was a paid addon. It was a lot faster.

Just be careful they don't label you a contractor then there are zero benefits to being a company apart from liability.

Yes. But what is the requirement that means it has to be under your company name? Is it that you fear if it is not then your argument to the tax office is diminished or is there a specific clause that states open source does not constitute a "product" that you own and therefore cannot be accepted? i.e. is this a speculative move or is there a definite clause that applies?

What is the criteria for the Tax exemption that requires this move? What makes this toolkit a good choice over, say, you messaging library which has little or no collaborative contributions so far?

I've no idea what you are talking about (R&D Tax credits?) so it's difficult to make a judgement but you appear to want to take sole ownership rather than be the caretaker of a community project. So I object on that basis. Am I able to claim these credits too? There is nothing in the BSD licence that says you cannot take the current software and create a derivative as long as the licence is followed.I would prefer you create a new product derived from the current.to mark a distinct change rather than an attempt a seamless absorption. In time, people will probably move to your new product in preference but I think a distinction should be made and the current project control handed over to LavaG admins. I'm not suggesting that you don;t deserve most of the credit for the library. only that a distinction is made that it is no longer the same community software in order for you to benefit..

I don't have much experience with IDL (like, none ) but IIRC the MIDL compiler can create C/C++ header files. You could try running the compiler with the /h switch then use the resulting header files with the LabVIEW DLL import wizard (Tools>Import>Shared Library) It's a long shot but may get you some of the way.

DOH! I forgot that an input to the conversion requires the codepage

That's a fair point but generally API developers don't (and I think shouldn't) offer multiple ways to do the same thing and where they do exist, it is usually due to legacy support. Saying that, though. For network sockets there are blocking and non-blocking calls that get wrapped by developers On the surface, these blocking calls seem far easier to use when viewed as linear steps since there is no need for synchronization in your program. However. I have always been forced to go for asynchronous since they cannot be aborted by the IDE. In all cases with communications. Asynchronous is always the final solution and blocking calls always fail to deliver. I'm pretty sure what we have today wasn't always the case. I have recollections of aborting DLLs that had frozen (and there were lot ) I also have recollections of sharing a global from multiple built executables . I also remember ridiculing the C programmers with their pitiful 16bit when LabVIEW was 32 so it was probably quite a while ago . If I could still crowbar a DLL with the abort button. I expect I would go for blocking calls every time and let LabVIEW clean up the mess

I think we are up to 4. There is also the btowc which I could do char by char and LabVIEW has a Text->UTF8 primitive (and the reciprocal, but I don't care). IIRC it is in Linux (not sure about Mac). Don't forget I don't care about the system encoding. Only from LabVIEW strings to UTF16 regardless of how the OS sees it. Oooh. That's a point. Free Pascal is cross platform an supports unicode. I can look to see what it maps the Windows conversions to.. I was actually referring to the "Third Party Licencing Toolkit" for applying my own licence. It only works on Windows so it is not possible to supply 30 day trials on other platforms.

OK. Thanks. Once I've managed to get NTLM working in Apache on a Centos VPS, I'll have a play (2 days and counting.... ) There are obviously some trivial commands that do what I need and that's the important bit.

Can you expand on the LabVIEW "run queues" and task scheduler WRT .NET and DLLs?

You don't need to threshold/ An inflection point is a change in sign of the d2y/d2t from positive to negative or negative to positive. Since you only need two points to draw a line, Just find the two points either side of the inflection (where they change sign) and draw your line through them.If you need a better estimate because your datapoints are a bit sparse then you can do a linear fit on a few points on either side of it. Lets see who can come up with a "cool" way of detecting sign changes and extracting the points to fit

The LabVIEw strings are ASCII byte arrays so that would mean converting them to mbstr first, yes? I was under the impression that btowc was byte to widechar which seems just what I'm after. Are you saying that I would use btowc to get the multi byte string then use mbstrtowc to get that into unicode UTF 16?