robustness

I am a complete noob when it comes to both Node.Js and Erlang. But wouldn't it be possible to build a Node.js app that emulates Erlang behavior? e.g. you pass json messages across an distributed node.js server park and even pass new code to those servers w/o going offline, just like erlang. If you have a message handler callback that is activated when a message is received, then this message handler could check if the message is a code update message and thus replace itself(the current handler) with the new code. So it should be possible to have Node.Js servers with no downtime for code

A common way for sampling/splitting data in R is using sample , e.g., on row numbers. For example: require(data.table) set.seed(1) population <- as.character(1e5:(1e6-1)) # some made up ID names N <- 1e4 # sample size sample1 <- data.table(id = sort(sample(population, N))) # randomly sample N ids test <- sample(N-1, N/2, replace = F) test1 <- sample1[test, .(id)] The problem is that this isn't very robust to changes in the data. For example if we drop just one observation: sample2 <- sample1[-sample(N, 1)] samples 1 and 2 are still all but identical: nrow(merge(sample1, sample2)) [1] 9999 Yet

Would using the pickle function be the fastest and most robust way to write an integer to a text file? Here is the syntax I have so far: import pickle pickle.dump(obj, file) If there is a more robust alternative, please feel free to tell me. My use case is writing an user input: n=int(input("Enter a number: ")) Yes, A human will need to read it and maybe edit it There will be 10 numbers in the file Python may need to read it back later. I think it's simpler doing: number = 1337 with open('filename.txt', 'w') as f: f.write('%d' % number) But it really depends on your use case. With python 2,

Question, topic of discussion I am very interested in generation of command line shell scripting source code from code written in a more robustness-promoting, well-performant and platform-independent compiled language (OCaml, for instance). Basically, you would program in a compiled language to perform any interactions with the OS that you want (I would propose: the more complex interactions or ones that are not easy to do in a platform-independent way), and finally you would compile it to a native binary executable (preferably), which would generate a shell script that effects in the shell

I have a following method that connects to an end point when my program starts ChannelSocket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp); var remoteIpAddress = IPAddress.Parse(ChannelIp); ChannelEndPoint = new IPEndPoint(remoteIpAddress, ChannelPort); ChannelSocket.Connect(ChannelEndPoint); I also have a timer that is set to trigger every 60 seconds to call CheckConnectivity , that attempts to send an arbitrary byte array to the end point to make sure that the connection is still alive, and if the send fails, it will attempt to reconnect. public bool

I'm starting a new project in plain C (c99) that is going to work primarily with text. Because of external project constraints, this code has to be extremely simple and compact, consisting of a single source-code file without external dependencies or libraries except for libc and similar ubiquitous system libraries. With that understanding, what are some best-practices, gotchas, tricks, or other techniques that can help make the string handling of the project more robust and secure? Without any additional information about what your code is doing, I would recommend designing all your

Is code that uses the static Object.Equals to check for null more robust than code that uses the == operator or regular Object.Equals ? Aren't the latter two vulnerable to being overridden in such a way that checking for null doesn't work as expected (e.g. returning false when the compared value is null)? In other words, is this: if (Equals(item, null)) { /* Do Something */ } more robust than this: if (item == null) { /* Do Something */ } I personally find the latter syntax easier to read. Should it be avoided when writing code that will handle objects outside the author's control (e.g.