I'm working on modernizing Rosetta Code's infrastructure. Starting with communications. Please accept this time-limited open invite to RC's Slack.. --Michael Mol (talk) 20:59, 30 May 2020 (UTC)

User talk:Short Circuit/LabVIEW

From Rosetta Code


So, for LabVIEW, the optimal solution is to actually upload the vi containing the solution code rather than upload an image of the code. Would that be OK, or would that consume too much storage space? LabVIEW vi's can be anywhere from 7KB to several megs. --Chris Ferri

Hm. That's actually a very, very interesting problem. First, MediaWiki (what this site runs on) limits allowed upload file types. I can modify that, but that wouldn't be a good policy habit to get into. Additionally, a 7KB block of source code would be a rather large segment to inline into a page--and MW can OOM on multi-megabyte pages. (That's assuming the .vi files were human-readable.) So while uploading the .vi files is the optimal solution from a code execution standpoint, it's not practically workable. That leaves screenshots, assuming there's enough information in the screen shot for the user to build the solution.
Now you've got me seriously pondering something like mercurial as a back-end for holding the source code--that would efficiently handle the scenario. It would also require a massive redesign of how the site software works.
Can screen shots work? (I think you're replying to something, but I don't know off-hand where the other part of this conversation took place.) --Michael Mol 14:56, 14 July 2010 (UTC) 11:17, 14 July 2010 (UTC)
If I could chime in on the subject, I think it would be a good idea to have both the image and the vi file itself. The image would give a general idea of what the program looks like to someone who's not familiar with or does not own LabVIEW. But that alone could potentially make it very tedious to try. Some LabVIEW programs can grow to be quite large and could be time-consuming to re-write. A downloadable version could be a huge time saver for those who own a version of it. So I would recommend having an image and a download link, if possible. --Tyrok1 16:14, 14 July 2010 (UTC)
Really, I agree. The problem, though, is a technical one; I don't have an effective means of allowing the upload and storing of .vi files. --Michael Mol 16:18, 14 July 2010 (UTC)
Ok well below are the front panel and block diagram for heap sort implemented in LabVIEW. This vi in my opinion represents the average labVIEW vi. My problem with this is the only way to see the other cases and nested functions etc would be to upload an image of them as well. This could lead to potentially many dozens of images needed to show all the cases in a case structure etc. And, anybody wanting to use this code won't have the ability to run the code without all of these images from which to recreate these functions. I have no idea how your file hierarchy is setup, but one solution to the storage problem would be to create a "labVIEW" folder in which you can place all files with a .vi file extension that are uploaded.--Chris Ferri

Heap sort front panel Heap sort block diagram

The least tractible problem stems from implementation limitations: MediaWiki file uploads are limited by PHP settings on the server, which are in term adjusted with an eye towards resource usage (most notably memory, but disk usage is something I'd be worried about as well.). The best practicable solution I could provide would be a sideband upload mechanism such as a source code repository that used MediaWiki credentials for authentication. Doable, and has interesting and useful side effects wrt the rest of the site, but that'd take planning. I actually had a face-to-face conversation with Tyrok1 today, where he explained to me some of the limitations of the screenshot approach, so I understand your problem. I just don't have the time to implement it right now. --Michael Mol 22:39, 14 July 2010 (UTC)
No probs. It's not a huge issue for me to be unable to upload the LabVIEW solutions. I'm more interested in staying in practice and solving the tasks on this site give me a good way to do that. But, when or if this site is ever capable of handling LabVIEW solutions to programming tasks, I'd happily take the time to upload all of them. Until then, I see no point in uploading screen shots of the code without the source to go along with it (for people who use labVIEW). As you can see, even trivial algorithms are difficult to decipher without labVIEW's profile and debug tools.--Chris Ferri

Has anyone asked the company that creates LabVIEW if they have a way to textually dump its programs for use on sites such as this? I can see that a non-graphical, but still 'meaningful' textual form might be useful to others.(They could output a version in graphviz dot format for example). --Paddy3118 05:06, 15 July 2010 (UTC)

Not AFAIK, but I did learn that the .vi file contains positional data for blocks and connections, that the blocks are generally very simple, that most meaningful programs wind up constituted of a huge number of blocks, and that all that data for all those very simple blocks adds up. I don't know how much it supports by way of linked-in libraries and code-reuse. If there were a textual format, I'd be surprised if some third-party tools for library processing and such didn't crop up. --Michael Mol 14:36, 15 July 2010 (UTC)
There is no way to textually represent the G source code. It would be pointless, because the source for a labVIEW vi not only contains the positioning info for the visual programming elements, but also hidden labVIEW processes running in other threads. It would be harder to decipher than a picture of the block diagram. So, I do have the option of uploading the vi's to the LabVIEW Developer Zone, and then link to them from there. But, I am hesitant to do so because I don't know what license user created programs are licensed under. --Chris Ferri