Rolf Kalbermatter

The problems with the paths to the shared libraries should be fixed with version 5.0.3. It's a combination of using the <library_name>*.* format to let LabVIEW resolve to the right shared library with the first * being replaced with 32 or 64 and the second with the platform specific shared library file extension (dll and so). Also needed to fixup the linker info in the VIs after creating the renamed (with oglib postfix) VI hierarchy through the OpenG Builder functions. LabVIEW, after creating the renamed hierarchy, will store the fully resolved library name into all VIs, which of course is not very helpful as it pins the VIs then to only use the shared library that matches the LabVIEW platform used to create the package. Version 5.0.4 was adding a working low level API for supporting a progress interface to the storing of files into an archive. Version 5.0.5 was adding an extended interface to the Inflate and Deflate functions to compress and uncompress binary streams and control the header used (none, zlib or gzip). Previously only zlib was supported for Deflate and only zlib or none for Inflate. Version 5.0.6 fixes a bug when dealing with UNC names that contain numeric characters such as an IP address in the server name. https://www.vipm.io/package/oglib_lvzip/

It's not listed in https://www.ni.com/en/support/documentation/bugs/24/labview-2024-q3-bug-fixes.html As LabVIEW user I feel happy for their attention to this. As OpenG ZIP developer I feel a bit cheated. 😁

Unfortunately yes. First signed up 50 minutes ago and started spamming about 5 minutes later, then spamming about every 5 minutes. Second signed up 10 minutes ago and just started spamming. Definitely related as it is both about Norton spam. I'm very anti violence but these guys really get the worst in me out! 👿

Unfortunately it seems not. They said both (the two I checked) that they were created less than an hour ago, when I looked this morning (GMT+2).

What have you tried so far? https://docs.gitlab.com/ee/api/rest/ documents a REST API to gitlab servers. Did you look at that? Did you try anything? There is for instance the JKI REST API Toolkit that should let you talk to this.

That's normal for cRIOs. They don't usually go lower than a few MHz. I still use them whenever possible, except for loops that must contain nodes that can't be put into a single cycle loop at all. Quite often you do need pipelining anyhow at some point and then often need higher loop rates than your final desired rate and you can always implement your own internal counters that reduce the loop rate further and updates the outputs with the desired lower rate.

Seems to work fine from here today and is very snappy too. Wish the NI site was even remotely as fast. 😀

It seems to start to work! Unless of course you have hired some elves that keep checking the forum and deleting any account created with nefarious motives. 😀 But it is quite some time that I came in the office in the morning and didn't get greeted by a stream of products of humanities lowest when opening LavaG. In fact there seems none, and the latest new member is already 21 hours ago and still has 0 accounted posts for, so he may be actually genuine. Just hope that the moderators new message queue isn't overflowing with held back posts. Although you can always hope that it will die down once they realize that it has exactly 0.0% reach factor.

That was regularly true in the past, some of the callgirl spam so far was already NSFW.

They finally found out how to spam every single subforum at least once in a night.

Not yet. I'm actually working on it. Did read yesterday about the opkg package format needed and got some ideas about how to support that properly. Next step is to get the necessary gcc cross compile setup working again and create the relevant shared libraries and do some tests on several LabVIEW versions. Shouldn't be many months, but don't expect the according release next week. 😀

I put a prerelease package under https://kalbermatter.nl/downloads/oglib_lvzip-5.0.4beta-1.ogp The package is now officially released as version 5.0.4-1 under https://www.vipm.io/package/oglib_lvzip/

Most likely not! The directories and files during installation are done inside VIPM. In VIPM 2017 you have to start it up as sudo, so the owner will be root. The Post Install script is executed inside the LabVIEW environment through VI Server. That is not launched with sudo and therefore has no write access to the root owned directory.

Next step is trying to find out how OpenG ZIP Library fails on the lvappimg. My suspicion still is that it is an issue with the fact that the library is compiled for 64-bit. So am going to test it with 64-bit on Windows. Except that I'm using of course the most recent version 5.0 of the library which had quite a bit of changes in the C code to support 64-bit archives. So there is a very good chance that it simply will work. I can provide you with a prerelase of 5.0.4 that should install under Linux with both VIPM 2017 and 2022 if that helps. That would show if it is still a problem in the current code base. As it is I have not a working 64-bit version of LabVIEW for Linux at this point.