ensegre

Here they come for 2019. For the little these require sets, i.e. only to find the common elements among two character arrays, I think that it would be pretty easy to reimplement them without, for earlier versions. StrikeAMatch.vi StringDigrams.vi

Thanks, I'll check your one too. I've seen out on the internet that the most popular method suggested is the Dice (strike a match) metric, followed by the Levenshtein, beyond that it looks as it is mostly for theoreticians. Since the metrics have different merits, I have yet to figure out which may be better for what I have in mind. In the meantime, however, here is my quick implementation of Dice. LV2021, based on sets, hence not so backportable (down to 2019, perhaps). StringDigrams.vi StrikeAMatch.vi

I see. So your one seems pretty similar to the Strike a Match, IIUC, with the differences that 1) it strips away from the strings all chars not in [0-9,a-z] (what, no uppercase?) (good for literal strings, but otherwise not always) (could be probably done more synthetically with a regexp), and that it uses the arithmetic sum of two ascii codes instead of a true digram, which can create more false matches. A starting point anyway, thanks.

Out of curiosity, does anyone know of an available labview implementation of a string similarity algorithm? I might have a use case for it in a coming project. I've seen that out there there is a lot, so at worst I might end up toying with reimplementing one. e.g. https://stackoverflow.com/questions/653157/a-better-similarity-ranking-algorithm-for-variable-length-strings?noredirect=1&lq=1 https://en.wikibooks.org/wiki/Algorithm_Implementation/Strings/Dice's_coefficient

of course, this I've done by the book as many other times.

Thanks, good to see them. I hadn't done that much, the dependencies I had already picked up probably from whichever other installation, and yet vipm works fine for me with LV2019. In particular these links and +x seems unnecessary for me: (anyway I tried it and does not magically allow connection to 21)

one issue which I had but overcame, about listing, was that the binary of 20 and 21 is /usr/local/natinst/LabVIEW-xx/labviewprofull instead of just labview. A symlink made them appear in the list. Connection to them still fails though.

Is anyone anyway able to use this vipm with LV>2019? I've just checked two installation which connect fine to LV2019, but not to 2020 nor 2021. Standard settings of vi server port & authorization checked by the book. Or are recent versions of LV simply not supposed to be supported by that old release of vipm?

Zyga posted a solution for the linux font problem (probably not the CAR referred to, as Manudelavega wrote):

At last! Good catch!

that is, $ /bin/bash -c 'cd /usr/local/natinst/nifpgacompileworker/ && /usr/local/natinst/nifpgacompileworker/cw_wrapper.sh mono /usr/local/natinst/nifpgacompileworker/CompileWorker.exe' Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for System.Drawing.GDIPlus ---> System.DllNotFoundException: libgdiplus.so at (wrapper managed-to-native) System.Drawing.GDIPlus:GdiplusStartup (ulong&,System.Drawing.GdiplusStartupInput&,System.Drawing.GdiplusStartupOutput&) at System.Drawing.GDIPlus..cctor () [0x00000] in <filename unknown>:0 --- End of inner exception stack trace --- at System.Drawing.Graphics.FromHdcInternal (IntPtr hdc) [0x00000] in <filename unknown>:0 at System.Windows.Forms.XplatUIX11.SetDisplay (IntPtr display_handle) [0x00000] in <filename unknown>:0 at System.Windows.Forms.XplatUIX11..ctor () [0x00000] in <filename unknown>:0 at System.Windows.Forms.XplatUIX11.GetInstance () [0x00000] in <filename unknown>:0 at System.Windows.Forms.XplatUI..cctor () [0x00000] in <filename unknown>:0 $ locate libgdiplus.so /usr/local/natinst/mono/lib64/libgdiplus.so /usr/local/natinst/mono/lib64/libgdiplus.so.0 /usr/local/natinst/mono/lib64/libgdiplus.so.0.0.0

Thanks Rolf. So far what I understood, after some search on NI site and getting more familiar with the terminology ("compilation worker", "target support driver", etc.), is that NI decided not to include the PCIe-7852R target support in versions of the Windows LV FPGA module past 2014, even though with LV up to 2021 it installs ISE 14.7 as part of the toolchain which, as for Xilinx is concerned, might support it. So even if I was able to set a linux compile worker and point it to an appropriate machine (and in fact I can - to the NI FPGA cloud), I'm still stuck with LV 2014 for development. For this particular project, I think I'll split it to a FPGA backend built with 2014, whereas the fancy UI and business logic could be in 2021, with some intercommunication between the two - udp, datasocket, VI server, something. The academic question about whether it is possible to install the compile worker on ubuntu still stands though... I remember that, digging into, the compile worker would have been launched with mono, and launching complained about a missing dll. Tomorrow I might be more precise about the error I got.

Has anyone succeeded in some way to get it functional? I'm trying to set up a modern development environment for a project using a legacy PCIe-7852R. That demands ISE 14.7; On windows 10 that in turn is recognized by the FPGA installation of LV2014, but not supported on more recent versions of LV. The solution hinted by NI is to move to a win7 platform, but I haven't found one available at the moment. What I did is, as I usually do, grab all the rpms from the content of the iso I downloaded from https://www.ni.com/en-il/support/downloads/software-products/download.labview-fpga-compilation-tool.html#346211, move them to a /tmp directory and run on them alien --install --scripts *.rpm (and solving some small conflicts on the way). I chose the 2019 version for installing on a machine with LV2019 and 2021 already installed in the same way. At the end of the process I'm left with respectable directories /usr/local/natinst/nifpgacompileworker (15MB), /usr/local/natinst/NIFPGA/ (9.4GB) and /usr/local/natinst/mono (94MB), but neither LV2019 seems to be aware of a FPGA module (would it?), nor I know how otherwise run the compilation tool (e.g. for example to convince the win10 machine that the linux one could act as compilation server). Any idea? How is the FPGA module really working on a supported linux target, rpm based, where it is installed using the proper INSTALL script provided by NI?

No hang seen in my LV2020 linux, only (after some manipulation) an X scale and label in a wrong place above the graph. But anyhow, I've seen across the years individual controls occasionally becoming corrupted and behaving foul. The easiest solution then is just to recreate the control anew. My impression is that control themselves include their own callback code, to be responsive e.g. to appearance change, even at edit time. On occasions, this result in some insanity, like infinite loops.

Something fishy is going on here though. Is it me, or some spammer is managing to inject spam links in jrpowell quotes? Hmm, last four messages, single posters to a dead thread.

you mean create a LV library? Which kind of?

So far the need occurred to me only in an application whose only undoable part was the assisted filling of a big table. Not being particularly sophisticated, I created a finite depth queue, which stored the last N states of that table. Each value change of that control - enqueue at opposite end a new state. Each call of the user menu 'Undo' - dequeue one value and Property/write Value it back to the table. The table itself was not so big that keeping a few historical copies of it in memory was tallying. As simple as that, but certainly not too representative of an application with a more complex state to be rolled back.

Cross post (OP is wasting readers time) and answered by Rolf:

You can do something along these lines trapping mouse events. The quick example is all but polished, but should give you the general idea. clickbutton.vi

VIPM 2017 on Ubuntu 18. Don't know if related to that CAR, but jibberish chinese anyway + very ugly fonts. Edit: quick search, I found this: https://forums.ni.com/t5/LabVIEW/Why-does-my-LabVIEW-occasionally-display-in-Chinese/m-p/1545242#M571786. Now my VIPM 2017 appears to be based on rte2015, and the closest to what suggested in that post is /usr/local/lib/LabVIEW-2015/English/lvapp.rsc - which in my case is present, no *.tmp in that directory instead.

Ok. For most of the points, I'm feeling a bit dumb now that I searched for it..... https://www.upvi.net/main/index.php/products/lvhdf5/lvhdf5-forum/11-standalone-exe-doesn-t-work#18 Write 100 times: Thou shall not use "Use Default If Unwired" for references Thou shall not use "Use Default If Unwired" for references Thou shall not use "Use Default If Unwired" for references ....... https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019L75SAE My coding mistake, I thought I was calling HF5Close when I wasn't. And closing the containing project was sufficient to remove the lock anyway. Sorry for the noise, I hope it may help someone else in future.

The LV error of point 2. above, BTW. on the second HD5write (create) of the chain, the first succeeds, apparently. Error 402760 occurred at Check Object Existence.vi Possible reason(s): An HDF5 Error Occurred Major: H5E_ARGS (Invalid arguments to routine) Minor: H5E_BADTYPE (Inappropriate type) invalid location identifier Complete Call Chain: Check Object Existence.vi OpenCreateReplace Dataset.vi Simple OpenCreateReplace Dataset (Variant).vi Simple H5Dwrite (Variant).vi

A project benefiting from HD5 data saving came up to me, so I'm looking at your package. For now nothing beyond just dumping some heterogeneous datasets into a single file, but I'm already having a few issues. All together your package looks so well invested into, so I think there is point in reporting them, and ask for assistance. I've been trying 1.1.1.86 (offered by VIPM) and 1.2.2.5 (your link). Single dev machine for now. LV20.01 32bit, Up/Downgrading between the two is not completely flawless, sometimes VIPM fails, but nothing that can't be solved with restarting LV a few times and clearing the compile cache. My issues: I have something working in the IDE, I can build it into an exe, but the exe is broken-arrowed. Pressing the arrow I get a dialog with a long list of "missing external function h5helper.dll". hdf5.dll and hd5helper.dll get copied into the built application data/ directory though. What am I missing? I made a minimal snippet and a more real VI using v1.1.1.86, both work (modulo some lack of understanding on my part about why certain datasets need to be declared as Unlimited etc., but whatever for now). However: the "real" VI (having some event structure, shift registers and a bit of other code) is very sluggish when being edited. I would tend to blame the fact that so many calls (essentially Simple HD5write) are Xnodes. If I upgrade to v1.2.2.5 and open the "real", in the IDE, I get Error 1055 complaining about invalid references. The thing goes on compiling and opens as white-arrowed, but if run, it fails in writing one of the datasets (not the first, by chance). I'm afraid I'd have to unwire and rewire it all again in order to convince shift registers to update stale references or something the like, Xnode weirdnesses.... If I end up with an opened hd5 file (e.g. because my writing chain errored somewhere), it stays locked till I quit LV. It seems that Close HDF5 File (HF5Close.vi) even with Force close=true cannot against it (modulo that I understood something wrong...). I can't either replace the file with LV, or delete it from OS. Open/Create/Replace HDF5 File, with argument "create or replace", when called on an existing filename still offers an "open" button in the dialog, which is wrong logic, imho. That in both package versions, though. Your comments highly appreciated!