Neil Pate

OpenSSH is a different toolkit and, although it does use OpenSSL, the vulnerability only affects TLS (which OpenSSH doesn't use)

 I was being a bit facetious, but I did not know about it only being TLS, so I forgive you.

I have a ten week old at home, I didn't get to sleep with anybody last night 

Just tried out something that I would have expected should work, but doesn't.

As a Web Service is identified by a name I would have expected I could run several of them on the same system with the same port. This does not work, whichever service is started first works, the other does not. Moving the second Web Service to a different port works properly.

Am I being unreasonable with my expectations here? I know enough about ports to be dangerous but that is about all, is there some underlying restriction of the OS (Windows in this instance) that only allows one application to bind onto a port?

The reason I am doing this is to try and create a test environment so that I do not affect my production Web Service application.

Very seriously 

 

It is the only time I've ever heard that using encryption is worse than not using it.

 

Luckily, the binaries shipped with LabVIEW are not susceptible-they're too old

It's a good thing NI never got around to making an SSH toolkit 

So, most of you here are probably aware of the Heartbleed bug in OpenSSL.

How seriously is everybody taking this? Seems like a good time to change my password; "12345" was probably due for an extra digit on the end by now ;-)

Neat! It sure beats the stuff I did in university...

I recently took a peek at some C++ I did in post-grad. Ouch! "Clever" variable names, swearing in comments, massive functions...

The things you do when you are young 

Thanks guys.

The code in question was written by myself some time ago (circa 2007).  I was creating a NaN by dividing by zero, I suppose at the time I did not even bother to consider the "correctness" of the conversion, it worked and I just accepted it and moved on to the next thing.

I find it really educational to look back at my old code and see how my style has changed. Coercion dots all over the place, no defensive programming techniques etc etc.

Hi All,

I am in the process of porting a LV8.5 application to LV2013. One thing I have noticed is that there is a difference in behaviour when converting a NaN (DBL) to U32 using the To Unsigned Long Integer primitive.

In LV8.5 NaN is converted to 0

In LV2013 NaN is converted to 4294967295 (the maximum a U32 can hold).

Does anybody known when this changed, and does this seem like a reasonable change? This could lead to some very strange bugs!

 Either way, the picture is the better approach and allows the loop to do other things.

Absolutely!

A picture says a thousand words , but yes I included both parts to demonstrate a good way to check if the elements exist before attempting to read them.  Regarding your last point, I would suggest at least employing a timeout if someone isn't going to do the initial check.  The host loop should be structured in such that it doesn't need data every iteration (if you are looking for a chunk of buffered data), or manually provide your own polling by placing something like what I have in the picture in a loop with a timing element. 

The point I was trying to get across (unsuccessfully it seems!) is that even with a timeout a lot of CPU is used up waiting for the DMA buffer to have enough elements. This is probably contrary to what most people would expect.

You can request 0 elements from the DMA to obtain the number of elements waiting.

Yes, I did mention something like that in the line before.

Just to add to Jordan's post for those that don't know.

His picture shows an efficient way of reading from the DMA FIFO, first check to see if there are enough elements by requesting zero with a zero timeout, this will return the number elements remaining. Then only perform the actual read if the number of available elements is equal to (or more than) what you want.

My understanding of this necessity is that although the transfer occurs via DMA, if there are not enough elements yet then the CPU actually polls (using a lot of resource) until the number of elements is achieved, and this can really kill performance.

"Fastest" being a relative term, but a couple weeks recoding is apparently faster than getting LabVIEW to resolve what should be a totally elementary organizational operation. This would be one of the "troughs" in our love/hate relationship with LabVIEW.

I feel your pain Mike,

This advice will probably come across as totally patronising (it really is not meant to be), but I really recommend nightly builds of all executables, committed into your VCS. Doing this generally saves a whole bunch of time when LabVIEW throws its toys out the cot.

For those who do not know me in person, Neil Pate is my real-world alias.

If you are as impressed with Inno Setup as I am (couldn't live without it). you might consider a donation.

Indeed, a worthy cause. I was browsing the donation page earlier today and spotted a few familiar names there

If you're distributing a Web Service, ship the entire, Full RTE. LV2013 Web service run-time dependencies reticulate throughout a wide smattering of RTE packages, and I've been as-yet unsuccessful to pare to a reasonable subset. (Reference: experience gained through significant efforts over the past year to do this, and far more time in front of ProcMon consoles than what's healthy)

This is what I ended up doing. I spent days trying to figure out which dependencies were required, and gave up in the end after trying many different "sensible" permutations.

I have gained a whole heap of Inno Setup knowldege and random installer stuff now though, so I suppose it is time well spent.

Although this process is painful I am learning a tonne of new things about VirtualBox and InnoSetup.

VirtualBox is a mighty impressive piece of software, I cannot believe I have not been making more use of it (especially snapshotting).

Thanks for the tips guys,

I am getting there, slowly! This is my current [Run] section

[Run];Filename: "{tmp}InstallDotNET4dotNetFx40_Full_x86_x64.exe"; Parameters: "/q"; WorkingDir: "{tmp}InstallDotNET4"Filename: "{tmp}LVRTE_Extractedsetup.exe"; Parameters: "/q /AcceptLicenses yes /log /r /disableNotificationCheck"; WorkingDir: "{tmp}LVRTE_extracted"; Flags: waituntilterminated

Yeah I have that feeling too, it just feels so unnecessary to package the whole RTE with my application. Also, it makes the install process a bit weird as the user has to click through the LV RTE install dialogs. If I could find a way to supress those I would settle for that. This should be possible, I just have no idea how

Hi All,

So I have spent a large portion of my weekend either changing nappies or trying to get a LabVIEW application running on a fresh PC (in a VM). Basically I am trying to streamline the RTE (using a technique similar to Jack's described here). I will admit I have not made very much progress, I can run a very simple app, but have not yet found the magic sauce for making .NET4 DLLs work, or WebServices.

I have two simple builds that I am trying to run. One is a simple .NET DLL test, the other a WebService test. The first fails to run properly with a broken run arrow, the second runs, but I get a LabVIEW error the same at the original post in this thread.

Any tips here on which parts of the RTE I should be using? Note I tried the components described in this document to try and make the WebServices work, no luck.

Edit: ok figured out the .NET portion (maybe) needed to include VC2010MSMs.

Help!

Neil

 By the way, is there a more efficient way to delete class mutation histories?

take a look at the VIs in vi.libutilityeditlvlibslvclass

I believe that renaming the class also resets the mutation history.

Thanks guys, I have done a bit of tinkering with InnoSetup (and the Script generation GUI) and really like it.

Now I just have to figure out how to include the various bits and pieces of the runtime engine, webservices and .NET client.

We abandoned the NI built installers with the 2011 release over similar issues, the 64-bit IDE was failing to package up the entire RTE even when asked. You're not alone.

"Glad" to hear I am not alone in my frustrations here. If you don't mind me asking which 3rd party setup generation tool did you settle on? From speaking with a few others it seems that Inno Setup is quite a good option.

More info on this error in case anybody else stumbles upon it.

I still do not know what causes this problem, and the only reliable solution I have found so far is to install the LV runtime engine manually before proceeding with the application installer. This is not a very satisfying fix for the problem, and am not devoting some time to looking into alternate install creators as I do not think the one built into LabVIEW is doing a very good job.