Michael Aivaliotis

How do you login? Using built-in login or facebook? I'm thinking it's a caching issue maybe.

Wow, those LAVA cats really worked overtime. Looks like the site is back up and working. Let me know if you notice anything strange. Thanks for your patience! I just noticed we now hav a leaderboard. Cool.

If that's real, please add it to OpenGDS, like now!

Automatic error handling is for noobs.

I get that. But thinking about it even more. It seems you would want to have a feature to completely remove an installed Package ?. Otherwise you would have an ever-expanding database of files.

Hey LAVAmaniacs! It's been a while since I poked at the LAVA server. There seems to be a lot cobwebs and dust in the server room. The LAVA software hasn't been updated in a couple years. That's way too long. I'm going to jump in and see what I can do about upgrading the LAVA back-end to the latest and greatest. This will fix many issues. Last time I tried this, it failed and I had to revert back. I didn't plan on it failing and didn't allocate time for getting tech support from Invision. This time I'm planning for the upgrade to fail and then getting Invision support involved. This means the site might be offline for a few days beyond the weekend. Sorry, but it's a small pain we have to go through for long-term stability and security. Don't worry though. This time I have a crack team to help me out:

Well, the idea behind the original LabVIEW Wiki was to create a Wikipedia for LabVIEW. So linking to external content was welcome, using similar rules as Wikipedia uses. Mainly as cross-reference material or at the bottom of a page where further research could be done. Having said that. A page with all the LabVIEW blogs (which we had before) would definitely be ok. However, creating a dedicated sales page, for example, for your new Modbus toolkit would be forbidden. But a page dedicated to how Modbus works and used in LabVIEW is fine. Where then you could create a section on that page linking to all the Modbus toolkits and code available. There's a fine line that needs to be walked. The Wiki needs too have a definite purpose. It's ok if that purpose changes. But if it's just left wide open, then it will serve no purpose and be just another dumping ground on the web.

This is not GPL. JKI figured out a way with VIPM. So it can be done.

So if LabVIEW is not trying to manipulate the linked files (delete, rename, etc) and is just reading or saving them, then symbolic link should be enough. However if LabVIEW tries try to manage these files then it's better to go with hard links. In this context I mean the LabVIEW IDE, not the package manager written in LabVIEW. But I think the two link types might not matter to the package manager written in LabVIEW. Since it will always be working with the installed files in the Application Data folder. All of the "work" on the files would be done there and not under the LabVIEW IDE folders. Some work to unzip the files and some other work to create the links which would be a bunch of Admin-level command line calls. Am I understanding this right? @rolfk As far as the zip changes your making. Explain the use-case of supporting "hard" or "soft" links in the first place. How do you use this in the context of zip?

Using the concept of links. In Windows there are hard links and symbolic links. How does this difference affect the behavior of this proposed solution? Also, creating these links required Admin rights. Of course this seems somewhat expected in the world of installers.

That moderation extension seems like it might work.

Where to start. A wiki here a wiki there, everywhere a wiki. We used to have a section on LAVA which was like a Wiki many many years ago. However, I shut it down. Reasons: Users didn't know it was a Wiki and instead of posting questions to the forum, would create new Wiki pages with their questions. This was a nightmare to moderate. It was setup so that when you created a Wiki page, the discussions for that page, would be linked to dedicated forum threads. Again, more confusion, since it was not a model commonly used elsewhere on the web. The forum\wiki blend was not very intuitive and it made the site hard to "figure out". Nobody cared or understood the wiki. A handful of people used it and never really caught any steam. After that experiment was shut down, I decided to create a separate domain dedicated to the LabVIEW Wiki. It was labviewwiki.org. I still own this domain. I think this was 2009, I don't recall. But anyway, I used the same open-source software that powered wikipedia, mediawiki. Here's the wiki-index page: https://wikiindex.org/LabVIEW_Wiki. Seems like it had around 300 pages. MediaWiki is super powerful, but not intuitive for new editors. I spent most of the time creating templates and documentation describing how to edit pages. I created a lot of the content but there were some others who added unique content like all the LabVIEW ini keys. All the keyboard shortcuts. All the hidden scripting features (before it was mainstream), etc. It was pretty cool. And yes, we had awesome landing pages and getting started pages that I spend hours and hours crafting. I was young and motivated. The problem was that we got struck with a rash of spammers. More like bots. They would go through and create hundreds of pages overnight. In that environment, you need moderators and editors to delete the pages and watch for edits. I was the only moderator and admin. So my plate was full. I ended up locking it down and forced it so that you had to have a login account to edit pages. On top of that, the login's had to be manually approved by me to prevent bot accounts. Of course, a wiki cannot be maintained or augmented by one person. The whole point is to have a community edit the pages. Not sure if Wikia (or MediaWiki) has solved the spamming issue. @The Q, I noticed a lot of the content is scraped from ni.com. Have to be careful about this and copyright claims. One thing I was very careful about with the LabVIEW Wiki I worked on was to create original content as much as possible. Also, what's the point of just duplicating ni.com. That's pointless in my opinion. Google does an excellent job of getting the info you need from multiple sources. But that's my opinion and the community edits should drive that of course. Sounds like the community wants to reboot the Wiki idea like Hollywood reboots comic book heroes. Sure, let's see where this goes. @The Q seems to be enthusiastic about it. Are there others here willing to put the time and effort into building the content? Any volunteers? If there is some real interest, then I can try to resurrect the old Wiki content and domain (not sure if the content it's salvageable, but I can try). Then we can go from there. I don't have time to admin the site but I can hand over the keys to someone that has more time.

VI Shots LLC will be donating an Apple TV 4K 32Gb More info here: https://www.apple.com/apple-tv-4k/

I'll be there this year!! If you want to save money, you can share a room with me. Just ask. Also, come running with me in Austin.

Hey fellow LAVA people. I just turned 50 on April 2nd, and wanted to do something challenging for me, both mentally a physically. I'm running 10K every day for a year and raising money for cancer research. If you want to follow along on my journey, you can subscribe to the 10K365 youtube channel for the latest. Then go on over to 10K365.com and give whatever you can. Thanks, I consider all of you as friends and one of the reasons I love LabVIEW.

Well, I've found a workaround to the above problem in the meantime. But to your question, this cluster doesn't physically exist. This is dynamically generated from various sources. I then pass the variant data into another function that processes it into a specific file format. So it's a means to an end. The data size is simply a factor of a lot of configuration parameters. This is an old app. Probably, if i was to redo it, I would take different approach. But it is, what it is.

After I woke up this morning, and had a coffee, I did some probing and came to the same conclusion. We have a roll-over situation on the U16\I16 combo for the array length math. So digging into the type descriptors doc in the LabVIEW help (which I never thought I would have to do today), it seems that there are two formats (7.x and 8.0). OpenG uses the 7.x format I assume. So is this fixable by updating how OpenG handles type descriptors and making it use the 8.0 format? Or is it more than that?

At a high level, I'm taking an array of variant data and trying to convert it to a variant cluster using the openg variant tools. However, I'm getting a low level error, and not sure why. I'm using the "Array to VCluster__ogtk.vi". Now the variant array has 997 elements. Could this be the reason? Is there a limit? I've attached the LabVIEW 2014 VI with the data as a constant so you can run it yourself. You'll need the OpenG variant tools installed. Untitled 9.vi

There was a crashed cache table in the database which I repaired. I think this might have been the source of the problems. So perhaps it's fixed now. Not sure how this table always gets corrupt. Mysteries of MYSQL and the forums software.

I'm blind. Right. I guess I'm trying to figure out the advantage of this programing method vs just using the "set variant attribute" primitive. I just want to add or update an attribute value. Not necessarily read it or access it for any reason. The primitive adds the attribute if it's missing anyway.