Jump to content

drjdpowell

Members
 View Profile  See their activity

  • Posts

    1,982

  • Joined

  • Last visited

  • Days Won

    183

 Content Type 

Everything posted by drjdpowell

  1. drjdpowell
    How would you do it? (Though you can explain what you mean be the Inverted dependency thing also.)
  2. drjdpowell
    Well, the methods that send messages meant for the “TCP Client Actor” are dynamic-dispatch overrides of “Create” and “Destroy”. The only extra API method that RemoteTCPMesenger adds to the standard Messenger API is “Remote Service”, which is called first to define the IP address and service name to connect to. But I’ve lost the chain of thought. Remember, I need RemoteTCPMessenger to work in an extensive body of code that works with the generic “Send” and “Messenger” classes, thus I need to have it work through a predefined simple API (Create, Send, etc.), not some new TCP-specific API. Large parts of the codebase must be blind to the fact that it is using TCP. If the internals of RemoteTCPMessenger need to be slightly unclear to achieve this, that is no big problem, as the user of the messaging package doesn’t need to know this internal detail. Could you expand further? I send messages to an address, after someone has created the address; which I think is the same as how Lapdog does it. Here, BTW, is an example I’m going to add to the next version: A TCP client that communicates by request-reply with a server, and receives the messages back (for demonstration) in three different ways (by queue, User Event, or Notifier). The only TCP-specific API method is the “Remote Service” VI called first.
  3. drjdpowell
    If I recall the quote right, it’s the singletons you think you made thread safe that particularly inspire God’s wrath. Presumably because you actually didn’t.
  4. drjdpowell
    Shaun, I think Daklu is referring to the need to register on your site in order to download the example. I just tried a test of attaching a VIPM package to this post and “This upload failed”, so perhaps the issue is with LAVA. BTW, here is the presentation slides Daklu is referring to (it’s on the CLA group at NI.com, but that group is restricted): CLA Summit 2013 Final.pptx In hindsight, I think it was too technical; I should have focused more on the “what” then the “how”.
  5. drjdpowell
    It would be Address.Send if I were doing it today. “Send” is anything to which I can send a message. It’s a bit confusing because it is more general than a communication method like a queue (such methods are under the subclass “Messenger”). No, I’m actually going for 100% transparent TCP communication. Having message-sending code by able to work with any transport method was the original motivation of my messaging system. Whether that is really achievable with the intricacies of TCP I’m not sure, as I have not had a TCP project to work on in years. But there is no “SendButDontForward” message. Well, part of my philosophy is to have simple subcomponents whose messaging interaction is configured by higher-level components. So the subcomponent still needs to be provided a simple “address” to “send” to, even if the higher-level component knows that “address” as a more complex object with extra methods. Edit: Forgot to add: RemoteTCPMessenger is intended to either BE a network proxy, or be the Messenger inside a network proxy.
  6. drjdpowell
    The technique of overriding a “Send” method can be used in multiple different ways. PrefixQueue might not be the most closely-related example. Well, as an example, here is the “Send” override method of my “RemoteTCPMessenger” class: As you can see, RemoteTCPMessenger wraps and sends messages to a TCP Client Actor. Other methods of RemoteTCPMessenger can send alternate messages to TCP Client to control it. Could I send the TCP messages directly and skip the actor? Well, in this case I have to route message replies and published event messages back through the TCP connection and thus need some process listening on that. Once I have to have the client actor anyway, it is cleaner and simpler to let it handle all aspects of the TCP connection. A TCP connection is too complex a thing to be left to a passive object.
  7. drjdpowell
    It WAS POOPy! I was protecting you.
  8. drjdpowell
    Opps. Sorry, I missed that. Not if you have a dynamic-dispatched “Send” method, in which case the wrapping of the original message in the SendViaTCP message can be inside the Send method. It’s the same technique you’re using in your LapDog PrefixQueue, where the sending process is unaware that the messages it is sending are having a prefix added. Similarly, a process doesn’t have to know it is sending messages via TCP. This isn’t really what I’m thinking of. “Outer Envelope” suggests a message holding another message. I don’t see why the inner message need be empty (an unfilled “inner envelope”). — James
  9. drjdpowell
    He’s actually using what I call “Outer Envelopes”. You didn’t like them when I suggested them before. In fact, I use a “Send Via TCP” outer envelope in my TCP message system.
  10. drjdpowell
    But would it not be easier to refactor in TCP communication if the extra added processes of TCP send/receive don’t have to be custom created to handle specific messages. And if my end processes are “X” and “UI for X”, how useful is it to have three intermediate message-handling stages? Surely at least one of that long message chain doesn’t need to know what an “Enable Motor” message means?
  11. drjdpowell
    How do you distinguish language from meta-language if both are text?
  12. drjdpowell
    If it’s in a standard LabVIEW install then you can use it. I used the QMH template, if I recall.
  13. drjdpowell
    JamesMc86 is suggesting the possibility of writing a by-val class and allowing the application level to decide on DVR use (or not). The other options are writing a class API that takes DVRs as you’re doing, or use DVRs internal to the class (as todd mentions). If one is doing a class API that takes DVRs, then I agree you probably want to restrict use of the IPE to within that API.
  14. drjdpowell
    Some random thoughts: 1) I tend not to have an actual “UI actor”; instead I have each actor have it’s own UI on its front panel, and have the main actor present the subactors in one or more subpanels (or just open their windows. This involves less messages to pass around. 2) One can also deal with needing lots of messages for lots of UI controls by treating the controls generically using techniques illustrated below. This is a “Control Server” example that I don’t think is in the version of “Messenging” in the code repository, but will be in the next version. Changing any control in Pane 2 of the “Control Client” sends a Variant Message that then fires a Value Change event in the Control Server. You can do the same thing with “Notify”, and you can also write generic code for setting cluster items using OpenG functions. Would this kind of stuff help reduce the programming burden? 3) The above technique in (2) is event driven (User pushes button —> sends message —> fires Value Changed event). In contrast, using a DVR requires the receiver to poll for changes to the UI settings it cares about. It also works remotely (the example above works over TCP), though that is often not needed.
  15. drjdpowell
    You mention “actors”, but one of the main points of the Actor Model is to use message passing instead of sharing by-reference data. So why not just send update messages when the User changes something?
  16. drjdpowell
    Unfortunately it’s on the restricted CLA group, but here is a very interesting presentation on XControls: Round Table Discussion - XControls
  17. drjdpowell
    It’s supposed to work with enums, and my test case seems to work. "Variant to JSON" delegates enums to OpenG’s “Scan from String” which calls OpenG “Set Enum String Value”, so it should work. What error did you get and what enum string did it have?
  18. drjdpowell
    Have you tried recreating the parent “Execute” message from scratch?
  19. drjdpowell
    Yes. It shouldn’t matter how deep in the call chain the reference is created. BTW, what is the semaphore for?
  20. drjdpowell
    I’m sort of A, but the large amount of C involved makes me consider B. Thus: D.
  21. drjdpowell
    XControls? A) Yes B) No C) <Head banging against wall> Thump…Thump…Thump... D) All of the above
  22. drjdpowell
    Would it be better to have a “ConfigGUI” object that was recursive (contained an optional subConfigGUI)? Have a “Get ConfigGUI” method that has a “subConfigGUI” input. The parent implementation would initialize the generic GUI and add the inputted subConfig GUI. Child implementations could override the method to initialize a specific GUI and pass this in to the parent method. The “display” (or whatever) method of the ConfigGUI object would enable the button if a non-default subConfigGUI was present. That avoids any class introspection. It would also work at any depth (so your more specific GUIs could themselves have even more specific sub-GUIs).
  23. drjdpowell
    In any “command pattern”-style process the messages are part of the process, so if one can write or load new messages then one is modifying the process.
  24. drjdpowell
    More information about "Cyth SQLite Logger"

    Version 1.8.6

    1,837 downloads

    A logger and log viewer using an SQLite database. The logger is a background process that logs at about once per second. A simple API allows log entries to be added from anywhere in a program. A Log Viewer is available under the Tools menu (Tools>>Cyth Log Viewer); this can alternately be built into a stand-alone executable. Requires SQLite Library (Tools Network). Notes: Version 1.4.0 is the last available for LabVIEW 2011. New development in LabVIEW 2013. Latest versions available directly through VIPM.io servers.
  25. drjdpowell
    View File Cyth SQLite Logger A logger and log viewer using an SQLite database. The logger is a background process that logs at about once per second. A simple API allows log entries to be added from anywhere in a program. A Log Viewer is available under the Tools menu (Tools>>Cyth Log Viewer); this can alternately be built into a stand-alone executable. Requires SQLite Library (Tools Network). Notes: Version 1.4.0 is the last available for LabVIEW 2011. New development in LabVIEW 2013. Latest versions available directly through VIPM.io servers. Submitter drjdpowell Submitted 03/08/2013 Category Database & File IO License Type BSD (Most common)  
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.

  I accept