ShaunR

Hmmmm. This got me thinking (always a problematic occurrence) If we combined your scripting stuff with the ideas of OMeta we could create a Requirements Spec Translator and convert specs directly to LabVIEW like they do in the CLA exams - make all the CLAs redundant

Except I already stated that "From the initial cursory reading (which may change as I re-read another 20 times)" and "Still getting my head around it though" so it wasn't an authoritative stance-you just chose to jump on a specific tangential comment that you thought you might score points on You can bet it has been refined and re-imagined. I even said I was looking for the superseding research in the original post. I also asked for any examples so you know there are none, so far. It is clear that you require to be spoon-fed solutions with concrete implementations. Drive by the fill-up station of knowledge and stick the nozzle in your ear. It is the programmers equivalent of the "pictures or it's not true" that is in some online cultures. I will let you know if and when I have such a solution, an example of it working, a published paper for you to annotate and a licence for you to use it. In the mean-time you will just have to watch to me brainstorm as to possible uses and applications as I piece together the timeline after a serendipitous stumbling over of an ancient text that was written a long time ago by one of the founders of TCP and UDP.

Leaving aside your beliefs and the strange disclaimer.... It's not new because it is over 30 years old but I have never heard anyone talking of Pseudo Time until Alan Kay mentioned it and I have a feeling, neither have you. I'm surprised you didn't point to page 72 to challenge my assertion about consistency where he states You are reading it now, . I need to read it at least twice more and then I will have a full understanding and will address your points but rather than think of Pseudo Time as a kind of subversion-like database for values, I think it would be better to think of it more as a mechanism within a subversion-like database that has similarities to a hard, real-time system - atomic execution slots where batches of operations can be executed under a single label. As I said before He is still a professor at MIT, so I might email him and ask about his thoughts about it after 30 years and if there are implementation examples. I have a feeling it was the basis for the TeaTime synchronization architecture in Croquet.

I get rather tired of this type of cop-out. It is basically saying "I won't engage your arguments because I don't want to - I will talk about this!". So I will throw back to you that CAP is not a central idea to pseudo-time or the paper so please stay on topic.

Maybe the blind leading the blind at this point but are you saying that you accept that with this approach availability and partition tolerance are satisfied? Assuming the affirmative the issue then is consistency (as defined as "atomic consistency" - a property of a single request/response operation sequence) which is not itself absolutely time constrained and a constraint that data must be seen at the same time. Whos time? EST? GMT? System Time?. How about clock ticks? Is that excluded from being time? So what is the reasoning for a "Translation between pesudo-time and absolute"? In LabVIEW we have "execute when all inputs have been satisfied" (dataflow). Does that violate the first rule?

I just reread what you said here and it seems there is a paper written 30 years ago by David P. Reed that debunks that theory if you consider consistency to be able see data at the same pseudo time rather than absolute time. Still getting my head around it though.

Won't work on Windows. Only works on Windows Lets see who cares about what

LabVIEW is a Dataflow language rather than Functional Programming. State is implicit rather than explicit and execution is inherently parallel - it is quite a different beast to Functional Programming.That's not to say you don't need a state-machine at some level to control execution. In the LabVIEW world it is usually a sequence engine which is a lot simpler since LabVIEW execution can be represented as a directed graph and that is basically your block diagram.

Because state-machines are hard and have to be debugged with witchcraft. So just avoiding the problem means you don't need tools for that problem.

Are you sure it's not a sequencing issue? ...... ..... because you need.

I think it applies to all projects that have asynchronous processes which is why I'm interested. I don't know how all that works internally. From the initial cursory reading (which may change as I re-read another 20 times ) ) he is generally talking about a journaling system for messages (I think) and using this pseudo time mechanism to resolve contention by what seems to be a slot-scheduling method. Indeed. He has given me the prism and terminology to [succinctly] describe why I am so unhappy with all the frameworks and architectures I see being produced in LabVIEW. However, I'm hoping that this paper, or one of its later incarnations, results in an elegant solution to remote messaging that I have been unhappy about for quite some time.

Nice work. Don't over-reach for a first release. Named pipes for progress bars are a stateful digression from just showing a dialogue. Maybe take stock and put a stake in the ground of where you are - package and clean. Then look at that for version 2. Productionise. Then you can incrementally add features under version control. Just a thought

I am constantly amazed that some ideas were prescient in hindsight but rejected in their time for more mainstream alternatives. The sands of time covering their bones for an archeologist to piece together later. Luckily, the internet is an excavator I was watching a video called "Is it really "Complex"? Or did we just make it "Complicated" because I've felt for a number of years that the whole idea about using frameworks is really a dead horse flogging exercise because we can't innovate out of a rut. Anyway. During the video there is a throwaway comment that semaphores had a superior alternative called Pseudo Time. Wait. What? Non deadlocking semaphores? Well. Perhaps, perhaps not. The only reference I could find was a paper written in 1978 called Naming and Synchronization in a Decentralized Computer System by David P. Reed. In there he talks about an alternative (NAMOS) to mutual exclusion A.K.A. critical sections around shared resources, rather than semaphores specifically, but the real gold is his definition of the reliable and self recovering synchronisation of unreliable shared resources. In a nutshell, he's talking about synchronising across cloud servers and blockchain forks and any other distributed computational system you care to design - in 1978! This is a bit more than non-deadlocking semaphores, I think. So why am I posting. Well. a) Has anyone ever heard of this or any superseding research (links would be great) and b) Has anyone got any LabVIEW examples?

I think quite often new guys/gals don't really know the difference between LabVIEW source code and an image; especially if it is their first foray into programming at all. LabVIEW is just programming with pictures, right? Posting a screenshot is posting code, isn't it? I see all the time old timers posting screenshots. OK, they call them snippets, but they are screenshots and they say it is code, right? edited to add emoticons for Rolf

Are you sure? From you image, it looks to me that the first text selection node can operate before, during or after the "add symbol" sub VI as LabVIEW decides.

If you like wmic you'll love the wmi-delphi-code-creator

Oooh. An ion gauge? Is that part of a plasma rifle or a quantum defibrillator? Please post the code

Block diagrams don't scale (no zoom etc). I would check your fonts. Fonts do make a difference to the BD and cause things like unbundle by name to resize to accommodate. Perhaps a font that was used on the original machine is not available and the surface is picking a slightly different one that it thinks is close enough.

Thats not weird; thats a lemon. Send it back and get a new one. I had a couple of strange corruptions recently. Couldn't open VIs in LV2009 64 bit. Could load the project but when I tried to open this one particular VI; LV would just disappear. Opened it up in LV2009 32 bit and it was fine. Saved it back down (in 32 bit) then reopened in 64 bit and problem solved. Thanked every god I could think of and moved on

You have already answered your question. You know that it doesn't fit the task but perhaps not why. Look at what will be needed for system wide state control, sequencing and subsystem interaction. If they are required and must be deterministic; there are better, less painful solutions.

Have you turned off auto-scaling?

All my distributions have a licence, changelog and a readme (and/or HTML help). For remote systems they usually also have a method in the TCPIP interface where you can query the version (which is just TCPIP forwarding of a BD constant or, more commonly nowadays, read and send the changelog) so the client end knows without special connections or tools.

You've nothing to apologise for. Linux fan-boys are 10x worse than Mac fan-bloys 100x worse than Windows fan-boys , of which I am one (well, I was until I looked at Windows 10). I think we would all jump to the fileversioninfo library if it worked on Linux and Mac too (which isn't impossible, by the way). The point I'm making is that it is only a a semi-standard way on windows and when you factor in other OSs it isn't standard at all Most x-platform libs, for example, have a function to retrieve version info so the BD constant is arguably the standard. Lets get this in perspective, though. No one is saying never version control or even never link your source version to your executable version. Only that writing complex build tools that are purely for documentation purposes and work on only one of a number of OSs isn't a high priority to x-platform developers. Nice to have but meh.

I give up It's kind of like the Linux fan-boys that answer "install Linux" to every Windows programmers' questions about compiling.

I think you miss the point. The filversioninfo is windows only so it won't work with things like CRIOs running NI Linux Real-Time or VxWorks. How do you version control your FPGA code, for instance? I'm not even sure if it would work with NI ETS but it might-I'm sure someone will clarify that. Your customers' preferences are only one aspect to x-platform.