ShaunR

Sure. Sometimes.Although unless you have programed in C you might think y -= m < 3 is rather obtuse. I'd defy anyone to say that string formatting in C is "more readable" though.

...... and here's the Sakamoto method.

Well. The Bitcoin system has had its first very public robustness test in terms of the protocol/system. Good community response (developers and traders) to the issue which was resolved quickly.

oops. Deleted 'cos stupid

Something similar was discussed here: Get HTTP vi not Reentrant? (surprised you are not using websockets for this)

Something like this?

You might want to take a look at the Transport.lib as well. It has an example of UDP Multicast and some nice features such as encryption, compression, timestamps and payload size (you can use more than 1500 byte payloads on windows and linux).

Do you have an example (picture) of what you are trying to achieve?

Yes. You can export a complete hierarchy to a couple of formats (including HTML) from within the IDE Look in the help under "Print Dialog Box"

Why not just have a "Shut-down" actor which knows what order to shut things down?

Perhaps it is because I also maintain the binaries (generally). These are usually under a separate repository and pulled in when needed (not as easy in Git as SVN) so that up issuing them doesn't require up issuing of the labview source (separate tree). Probably more my workflow so perhaps not a good idea as a generic.

If you have a sequence engine. Then it becomes fairly straight forward to dictate what should happen when. This is one of the reasons why I use messaging with a queue for commands and events for response. Most of my apps are present in the real world where you need to do things like set a slide to the home position before then turning the power off. It's an extension of your error handling problem and is one of sequencing. The standard architecture that I have adopted is that only the sequence engine is allowed to issue commands and all other modules can only be listeners to other modules but not interact or act on them. An example of this would be a UI which can listen to the slide controller and show the position, but when the move button is pressed, the command must be sent to the Sequence Engine which will then tell the slide to move (and probably a load of other things too). This topology does not have inherent broadcast capabilities since each message must be placed on the appropriate modules queue and has to be considered and programmed by the designer. This is, however, trivial and the pro's far outweigh the cons since you dictate the order of commands and precisely target the processes. It is very rare that a broadcast control message can be acted upon without consideration to other processes.

This is my fundamental objection to the Actor Framework. It blurs the line between messages and processes. It sort of funnels your application architecture to be the Actor Framework itself.

Not necessarily. MJE just posted a classic example of exactly what I am trying to get accross.

I don''t use the Actor Framework (or probably ever will) but are you talking abut your Message Pump library?

You can create your own "self, signed" certs or you can use a free service. However. If you are going "public" and it will be used for commerce you really, really (can't enphasis enough.......REALLY) should buy one from a trusted CA

*/build/* .DS_Store Thumbs.db .dll .so .out

Deprecation as opposed to deletion. If you just delete it you will break any existing code anyway. It's nice to give developers a heads up before just crashing their software What have binaries got to do with anything? That's just saying use it or use something else.

Of course you can change or delete them. You just need to "deprecate" them first (which to me you should always do anyway). If I have defined them as protected it's not my problem if their code breaks child classes. They have made a conscious decision to override my bullet proof one for whatever reason sounds sane in their mind, so they should be aware of the consequences. You haven't changed anything (and don't try to bring public in as an equivalent - it's not). Similarly to my previous paragraph, they should understand what the consequences are since they understand why they are doing it. By making it private you are denying them the opportunity to add, in your example, logging to that accessor. So. What will they do? Hack your code! When it finally all falls to pieces three weeks later after they have forgotten about the hack and they have put in a bug report for your class (which you won't be able to replicate) you will eventually find that out if/when they send the code. You don't stop them from doing anything by making it private. What you do is force them to modify your code to make it fit their use case. Bear in mind also. It is only rare occasions when it is required, but the argument is that if they wish to do so, however unsavory it may be, then they should be able to without modifying the original, tested code. Then it's their problem not yours.

Personally? More the latter (but I have heard reasonable arguments for the former). For example. In languages where you declare the scope of variables, then it's imperative to define variables that maintain state as private (this restricts creating debugging classes). Methods, on the other hand, should generally be protected so that the you don't restrict the ability to affect behaviour and I have never seen *(or can think of any) reason why any should be private. Even those that the developer sees as private "may" be of use to a downstream developer. I think that here we fundamentally disagree. There is only "re-use"; one "instance", if you like. Can it be re-used without modification. Re-purposing without modification goes a long way towards that and the more restrictions, the less it can be re-purposed. One is aimed at the user, the other at downstream developers but they are not in opposition (we are not looking at Public Vs Private). When re-purposed, you (as the designer) have no idea of the use-case regardless of what you "intended". Suffice to say a developer has seen a use case where your class "sort of" does what he needs, but not quite. Placing lots of restrictions just forces down-stream developers to make copies with slight modifications and that is an anathema to re-use.As for "ease of use". Well. That is subjective. What is easy for you may not be easy for me especially if it is a use-case that was conceived when your crystal ball was at the cleaners

This is also the crux of the Private Vs Protected debate. What is it better to do? Put so many restrictions that they have to edit your code for their use case (and you will get all the flack for their crap code), or make it easy to override/inherit so they can add their own crap code without touching your "tested to oblivion" spaghetti - regardless of what you think they should or shouldn't do.

If you want to test to see what the interface can handle. You can benchmark (and open lots of connections) with Dispatcher.

Nowadays I use a DB file for settings which means you can mutate from version to version with a single, non application specific, query and do other stuff like revert to defaults without having to write application specific code. I'm also leaning further towards having a single "config" DB file for all applications which works great especially if you have multiple applications (it's like using the windows registry, but works on all platforms and you can copy it!). You can do something similar with INI files and have global INI directory somewhere outside your applications (as bmoyer is suggesting) which has a sub-directory structure with the app name and version. Loading and saving is just a matter of building a path using the App name and version (i.e. non-application specific). This doesn't get around mutation, but it means that if you un-install or re-install you can always get to the same point as you, in effect, build up a history even if they delete the entire application directory.

I'd have a look at the icon editor. It can overlay the connector so it must get it somehow.