ShaunR

1 hour ago, Rolf Kalbermatter said:

This assumes that all the library paths are properly wildcard formatted prior to starting the build process as it will maintain the original library name in the source VIs.

That may be a problem and I don't really see why it needs to be so. Is this just to resolve files that are named like user32.dll?

The entry point for what you suggest seems to be here:

On 12/2/2024 at 4:04 PM, hooovahh said:

VIPM has the linking to a full path to the DLL, so renaming that linked path on install seemed like an easy way to make it work the way I wanted. 

Yes. This is why we have the post install VI's. There are other edge-case issues too, that cannot be resolved just by renaming.

On 12/2/2024 at 4:04 PM, hooovahh said:

A post install fixing the paths work as well, and in fact Jim posted a VI that can fix the paths on post install. 

Yes. That is not a viable solution.

However, what we are talking about is modifying the og libraries that VIPM uses to build (they are distributed as source), and fixing the paths BEFORE VIPM adds it to the the install so we don't need the Post Install at all.

On 11/28/2024 at 7:59 AM, Stinus Olsen said:

As an experiment, this would be pretty cool - but quite an undertaking I think.
Personally though, I think I'll stick with using ComfyUI/A1111 and Kohya - they don't require me to install anything other than what I need for the task 😆

ComfyUIs nodes are a bit more versatile than you would think at first glance.
I personally like to convert a lot of the frequent parameters I use into inputs and then minimize the remaining workflow nodes to not clutter up the interface.
Inputs to the left, output to the right 😉

A fun fact is that if you save the generated images using the Image Save node instead of the Image Preview one, the workflow is stored alongside the image data stream inside the resulting PNG file.
This allows you to load anyone of your previously generated images and immediately retrieve your workflow from that image - not much unlike how VI snippets in LabVIEW works

Comfy UI is a mess and I never seem to have the GB of models, extensions, clips or whatever other voodoo a workflow demands . I actually use Forge UI. That's much more manageable.

Then you can add to that that the issue that all Stable Diffusion UI's have - 50 different people created their own flavour of a plugin on Github and half of them don't bother updating it anymore because they got a real job.

More seriously though...

With ComfyUI  it is that you need to know a huge number of API's and, for want of a better description, the micro-workflows to use them. Those micro-workflows can be encapsulated just as we do a sub VI.

The main criticism I have with the ComfUI is its goups.

Why can't a group be represented as a control node? The groups are unrealised analogies to subVI's.

Where is my "Create Node" option? 

On 11/27/2024 at 2:36 PM, hooovahh said:

I'm also in Windows only land, and renaming the DLLs in a Post Install has worked well enough so far.  If we in a 64 bit LabVIEW for instance the post install looks for if there are DLLs named [X].dll but there exists an [X]64.dll.  If so it will delete the [X].dll and rename [X]64.dll to [X].dll.  This renaming bit also works in reverse looking for [X]32.dll if we are on a 32 bit version of LabVIEW.  Development then is done in one bitness statically picking the correct DLL. I have no clue how difficult or complicated this gets supporting Linux.

I think we are talking past each other.

I don't have a problem with naming. That is just what the *.* stuff does. I'm interested in what Rolf is doing to put the *.* into the node paths. I have a problem with linking-the VI search popping up during installation, VIPM not compiling everything and asking the user to save after use. This is caused by VIPM setting in concrete, the full DLL path in the nodes when it builds and not compiling certain VI's after installation.

On 11/27/2024 at 3:16 PM, Rolf Kalbermatter said:

I'm not really sure anymore what made me decide to go with the 32/64 bit naming

1. Both binaries can be in the same directory.
2. No need for a Post Install or Post Uninstall.
3. No code required to choose a 32 bit or 64 bit binary in the the different LabVIEW bitnesses.

There are excellent reasons to use this nomenclature but they are thwarted by VIPM.

18 minutes ago, Rolf Kalbermatter said:

You look for a way to hack VIPM to do something specific for your own shared libs and leave anything else to its own trouble.

Not quite. I asked about your code to solve my issue. I offered what I thought was an improvement based on my requirements and, as I don't support Linux or Mac anymore, you could migrate it to the other systems if it was viable.

You don't like it. Fine. It works great for me but for one edge case that you have pointed out that doesn't affect me. Assuming I cannot solve that one edge case, then I have a general Windows solution with one caveat that can go in the documentation. I'd call that progress 

17 hours ago, Rolf Kalbermatter said:

But the main problem is that I do not see how that could work properly when trying to build on 32-bit LabVIEW for DLL files that should remain with 32 in their name.

It's not a problem I have. I name them x32 and x64, if necessary, so there is no issue with the likes of user32.dll.

What I do have a problem with is binaries which can be 32 or 64 bit but there is no indication in the name and the path gets "fixed" by VIPM (similar problem with TPLAT). In that scenario I want the ".*" on the end only. That is the problem it is solving and why I said I wasn't sure about the full path (I think I want just the filename). Until now I have had a similar solution to you (force changes in Post_Install and make LabVIEW search for the binaries so linking them on first load). The main difference in my solution is, perhaps, that Post_Install has the binaries in arrays on the BD and the correct bitness is saved out when installed by the user. I wanted something where I didn't update the Post_Install every time binaries changed.

Perhaps we are solving different issues due to different workflows.

3 hours ago, Rolf Kalbermatter said:

Also don't try to read the file for the non-Windows cases as you don't do anything with that anyhow!

Feel free to add them in.

1 hour ago, codcoder said:

Doesn't sound too hard?

The comfyUI nodes are described by JSON in files called "Workflows" so we could import them and use scripting to create nodes. That's if we want parity. But we could support nesting which ComfUI wouldn't understand.

The WebUI's are just interfaces to create REST requests which we can easily do already. I'm just trying to find a proper API specification or something that enables me to know the JSON format for the various requests. Like most of these things, there are just thousands of Github "apps" all doing something different because they use different plugins. Modern programmers can do wonderful things but it's all built on tribal knowledge which you are expected to reverse engineer. The only proper API documentation I have found so far is for the Web Services which isn't what I want - I'm running it locally.

I've been playing around with an A.I. Imaging software called Stable Diffusion. It's written in Python but that's not the part that interests me...

There are a number of web browser user Interfaces for the Stable diffusion back-end. Forge, Automatic 1111, Comfy UI - to  name a couple - but the last one, comfy UI, is graphical UI.

The ComfyUI block diagram can be saved as JSON or within a PNG image. That's great. The problem is you cannot nest block diagrams. Therefore you end up with a complete spaghetti diagram and a level of complexity that is difficult to resolve. You end up with the ComfyUI equivalent of:

The way we resolve the spaghetti problem is by encapsulating nodes in sub VI's to hide the complexity (composition).

So. I was thinking that LabVIEW would be a better interface where VI's would be the equivalent of the ComfyUI nodes and the LabVIEW nodes would generate the JSON. Where LabVIEW would be an improvement, however, would be that we can create sub VI's and nest nodes whereas ComfyUI cannot! Further more, perhaps we may have a proper use case for express VI's instead of just being "noob nodes".

Might be an interesting avenue to explore to bring LabVIEW to a wider audience and a new technology.

On 11/19/2024 at 11:48 AM, Rolf Kalbermatter said:

It just occurred to me that there is a potential problem. If your DLLs are always containing 32 in their name, independent of the actual bitness, as for instance many Windows DLLs do, this will corrupt the name for 64-bit LabVIEW installations.

I haven't checked if paths to DLL names in the System Directory are added to the Linker Info. If they are, and I would think they are, one would have to skip file paths that are only a library name (indicating to LabVIEW to let the OS try to find them through the standard search mechanism).

This of course still isn't fail proof:

DLLs installed in the System directory (not from Microsoft though) could still use the 32-bit/64-bit naming scheme, and DLLs not from there could use the fixed 32 naming scheme (or 64 fixed name when building with VIPM build as 64-bit executable, I'm not sure if the latest version is still build in 32-bit).

I've modified your sub vi to check the actual file bitness (I think). If you target user32.dll, for example, the filename out is user32.* - which is what's expected. I need to think a bit more about what I want from the function (I may not want the full path) but it should fix the problem you highlighted (only in Windows ).

Fixup Shared Library Name.vi

11 minutes ago, Rolf Kalbermatter said:

I checked on a system where I had VIPM 2013 installed and looked in the support/ogb_2009.llb. Maybe your newer VIPM has an improved ogb_2009.llb. Also check out the actual post I updated the image.

Yes. The path isn't passed through but I figured out what it was supposed to be.

this is the one in my installation:

It's a trivial change though. The important part is the adding the extra case and your new VI. I was about to go all Neanderthal on the "Write Linker Info" before you posted the proper solution.

25 minutes ago, Rolf Kalbermatter said:

Not quite! It's better to actually modify the Copy Resource Files and Relink.vi. Just add an additional case structure to handle shared libraries.

The VI in question is this one:

This will unconditionally change the linking name of all shared libraries in your build. There is a possibility that that is not desired although I can't think of a reason why that could be a problem right now.

 

Fixup Shared Library Name.vi 31.87 kB · 0 downloads

Sweet. It's not quite the same but I'll figure the rest out. You've done the hard part  Thanks.

3 hours ago, Rolf Kalbermatter said:

I changed deep in the belly of the OpenG Builder in OpenG\build\ogb.llb\Copy Resource Files and Relink VIs__ogb.vi, that for shared library names the file name is changed back to the previous <file name>*.* with some magic to detect the 32 or 64 in the file name if present. It's not fail safe and for that not a fix that I would propose for inclusion in a public tool, but it does the job for me. What basically goes wrong is that when LabVIEW loads the VIs, it replaces to magic place holders with the real values in the paths in the VIs in memory and when you then Read the Linker Info to massage that for renaming VIs, you receive these new fully resolved paths and when you then write back the modified linker info you cement the not-platform neutral naming into the VIs and save it to disk.

The OpenG Package Builder modifications mainly have to do with a more detailed selection of package content and special settings to more easily allow multi-platform support for shared library and other binary compiled content. In terms of user experience it is the total opposite of VIPM. It would overwhelm the typical user with way to many options and details that it could be useful for most. I had hoped to integrate the hierarchy renaming into the Package Builder too, since the information in the Package Builder would be basically enough to do that, but looking at the core of the OpenG Builder in Build Applciation__ogb.vi will for sure make you get the shivers to try to reimplement that in any useful way. 😁

There is a "Copy Resource Files and Relink" in "<program files>\JKI\VI Package Manager\support\ogb_2009.llb" and  "<program files>\JKI\VI Package Manager\support\ogb_2017.llb".

Is it "Write Linker Info from File__ogb.vi" that you have modified?

I'll have to have a closer look.

On 11/11/2024 at 10:06 AM, Rolf Kalbermatter said:

Also needed to fixup the linker info in the VIs after creating the renamed (with oglib postfix) VI hierarchy through the OpenG Builder functions.

Can the JKI builder be modified to do this? I've already hacked some of their VI's in ogb_2009.llb so it didn't take 6 hrs to build. It's a huge problem for me when building. I have a solution that sort of works, sometimes,  but not a full proper solution.

Can you detail your process?

14 hours ago, Cat said:

Hellooo?  Anybody home?

For those of you who don't remember (or weren't even born yet when I started posting here 😄), I work for the US Navy and use a whole bunch of LabVIEW code.  We're being forced to "upgrade" to Windows 11, so figured we might as well bite the bullet and upgrade from LV2019 to LV2024 at the same time.  And then the licensing debacle began...

Due to our operating paradigm, we currently use a LV2019 permanent disconnected license for our software development. This was very straightforward back then.  But not so much with LV2024 and the SaaS situation. Add to this the fact that I can't talk to NI directly and have to go thru our govt rep for any answers.  And he and I are not communicating very well.

I'm hoping someone here has an answer to what I think should be a really simple question:  If I have a "perpetual" license with 1 year service duration for LabVIEW, at the end of that year, if I don't renew the service, can I still use LabVIEW like always, as if I still had my old permanent license?  I realize I would not have any more support or upgrades, but that's fine.

I've read thru the threads here and in the NI forum about this, but they mostly ended back when no one really knew how it was all going to shake out.  So are we locked into either our ancient LV versions forever, or are we going to be paying Emerson/NI every year for something we don't really need?

Cat

Welcome back. Retirement not all it was cracked up to be? 

My only comment about this (because I still use LV 2009-best version ever) is that generally:

1. Never do it in the middle of a project. Upgrading LabVIEW is a huge project risk.
2. Don't upgrade if the software already works and you are adding to it (only use it on new projects).
3. Only upgrade if everyone else in your team upgrades at the same time.
4. Upgrade if there are specific features you cannot do without.
5. Upgrade  if it will greatly reduce the time to delivery (unlikely but it has been known).
6. Upgrade if there is a project stopping bug that is addressed in the upgrade you are considering.
7. Remember that you can have multiple versions on the same machine. You don't need (and should never) go and recompile all your old projects.
8. 

20 hours ago, crossrulz said:

Is ShaunR actually a robot?

https://www.youtube.com/watch?v=UymlSE7ax1o

Nobody has met me, right? I might be A.I. without the I

2 hours ago, jcarmody said:

Jake isn't self-aware, yet...

Ask it how I can get past the sign-up CAPTCHA to use it?

22 hours ago, Bruniii said:

Now I'm looking for a way to read it using the public key in LabVIEW.

You want EVP_PKEY_verify. 

4 hours ago, Rolf Kalbermatter said:

It's doable with a Post Install VI in the package that renames the shared libraries after installation, except with VIPM 2017 and maybe others, which needs to run with root privileges to do anything useful.

I have the binaries as arrays of bytes in the Post Install. I convince VIPM to not include the binary dependency and then write out the binary from the Post Install. You can check in the Post install which bitness has invoked it to write out the correct bitness binary. Not sure if that would work on Linux though.

39 minutes ago, Rolf Kalbermatter said:

I just can install the shared library with the 32 and 64 bit postfix alongside each other and be done, without having to abandon support for 8.6!!

Installing both binaries huh? Don't blame you. It takes me forever to get VIPM to not include a binary dependency so I can place the correct bitness at install time with the Post Install (64bit and 32bit have the same name. lol)

2 hours ago, hooovahh said:

I do occasionally have correspondence with him. He is aware of the spam issue and we've talked about turning on content approval. He seems to want to update the forums and just has limited bandwidth to do so. Until that happens I'll just keep cleaning up the spam that gets through.

The longer it is unresolved, the less likely users will bother to return. I used to check the forums every day. Now it is every couple of weeks. Soon it will be never.

Some might see that as a bonus 

18 hours ago, Rolf Kalbermatter said:

It's a valid objection. But in this case with the full consent of the website operator. Even more than that, NI pays them for doing that.

The objection is that I (as a user) do not have end-to-end encryption (as advertised by the "https" prefix) and there is no guarantee that all encryption is not stripped, logged and analysed before going on to the final server. But that's not just a single server, it's all servers behind Cloudlfare, so it would make data mining correlation particularly useful to adversaries.

Therefore I refuse to use any site that sits behind Cloudflare and my Browsers are configured in such a way that makes it very hard to access them so that I know when a site uses it. If I need the NI site (to download the latest LabVIEW version for example) then I have to boot up a VM configured with a proxy to do so. I refuse to use the NI site and the sole reason is Cloudflare.

So now you know how you can get rid of me from Lavag.org - put it behind Cloudlfare 

On 8/14/2024 at 10:37 AM, Rolf Kalbermatter said:

Now, spending substantial time on their forum is another topic that could spark a lot of discussion

Any site that uses Cloudflare is completely safe from me using it. As far as I'm concerned it is a MitM attack.

1 hour ago, Rolf Kalbermatter said:

Maybe there is an option in the forum software to add some extra users with limited moderation capabilities. Since I was promoted on the NI forums to be a shiny knight, I have one extra super power in that forum and that is to not just report messages to a moderator but to actually simply mark them as spam. As I understand it, it hides the message from the forum and reports it to the moderators who then have the final say if the message is really bad. Something like this could help to at least make the forum usable for the rest of the honorable forum users, while moderation can take a well deserved night of sleep and start in the morning with fresh energy. 🤗 It only would take a few trusted users around the globe to actually keep the forum fairly neat (unless of course a bot starts to massively target the forum. Then having to mark one message a time is a pretty badly scaling solution). 

Not exactly a software solution though. I wrote a plugin for my CMS that uses Project Honeypot so it's not that difficult and this is supposed to be a software forum, right?

The problem in this case, however, seems to be that it's an exploit-it needs a patch. Demoting highly qualified (and expensive) software engineers to data entry clerks sounds to me like an accountants argument (leverage free resource). I'd rather the free resource was leveraged to fix the software or we (the forum users) pay for the fix.

The sheer hutzpah of NI to make you a no-cost employee to clear up their spam is, to me, astounding. What's even more incomprehensible is that they have also convinced you it's a privilege