short stuff

Why I failed to prepare for those exams are beacuse of distractions. I often get distracted by questions popped out of my mind. And I wrongly think that I have to solve them at once.

---

Don't need to care about design patterns and whether your implementation is the best. If it works, it's the best. Reading those stuff is time wasting and you end up finding the exactly same solution as yours.

Patterns (solutions) are thought up by people, instead of something you have to learn from others.

---

I am uncertain about how to implement a design like this https://bpa.st/QOEQ . I don't want to use multi-threading IPC stuff like socket, pipe, shared memory, then is longjmp() my only choice?

Module A:
 
 
send some data to B
 
loop
   receive something from B
   if stop sign received, stop.
   otherwise return the stuff B wants
 
 
 
Module B:
 
waken up by A with some data
loop
   send something to A, get the response
   parse the response, either stop loop or continue loop to ask and process something else from A

模块 A:
 
发送一些数据给B
循环
   从B获取数据
   如果获取到了停止信号，就停止循环
   else: 返回B要的东西
 
模块 B:
（A发了一些数据过来）
循环
   把想要的东西名称发到A那里，A返回
   解析数据，根据情况停止循环或者继续循环

---

Why C? It's low-level. You are really using the computer instead of the software written by others. You can longjmp!!!!

---

IPC design w/ file system? shared data

File system is the most easily found IPC. Network can not be found on a machine. So does pipe, which has never got into Windows users' mind - it doesn't exist, haha!

However we must have file. Otherwise we have to read everything from tapes into our memory to handle. Even so, we can still happily get a 'filesystem' in memory if we have the basic manners to name data to different names. You can even use some pointers.

The most essence operations of files is only read and write. stat() is optional.

No, I am wrong. The easiest one is through shared memory. You can even have no filesystem but only memory (though very rare, I must say). Since to execute a program you must have a memory.

Ok. Let's design our bot protocal w/ shared memory.

However, I must say those bot guys won't care about this since they don't care about using other people's libraries like I do. They are welcome to more and more layers of abstraction.

It is even more low-level than kernel message queue - you can have no kernel.

Q: C has fs support, but why no shared memory?
A: It exists as pointers. But unfortunately your kernel failed to support it. 😃 You are in the protected mode.

Ok, so it seems that the smartest approach is fork() and share variables? Oh no, fork() doesn't share variables, but just copy. So we need multi-thread.

Wait - why don't we just call the response function manually at the lines we invoke sleep() and wait for updates? Yes. This should be the one.

(parse HTTP response)
Got groupno. Ask: process? (Y/N)
Ask: what else do you want? 0 for message content, 1 for sender qq, 2 for sender name, ..., -1 for stop. Response: ...

But if so the logic part of code needs to maintain its state. Ok, longjmp. I should have thought of it.

---

C or sh

What to use for bot & other projects, like spiders
Java, Erlang, Ruby, Python, Go, Rust, Perl, Lua etc.: irreliable. Candidates narrow down to C & sh.

C
Pro: Low dependency, great support, portable ... and everything else. But actually nonsense for now.
Con: Exceptions, SPOF. Careless segmantation fault halts the whole system. It CAN be tested out, but testing requires efforts. Maybe more suitable for serious software that will be released, which naturally needs lots of testing, instead of utilities I write for myself, my family and small communities.

Portable - where to port? You can literally run a unix VM (w/o GUI, of course, since I never need that for doing stuff) in any computer we can possibly find, even the pre-2010 notebooks we found from our relatives.

Think sh as yourself operating the computer. That makes sense. You use that environment everyday so you can absolutely obtain that environment.

So C is more suitable for writing Vim? Oh, no. It is also OK for an editor to be in sh. Imagine that.

sh
Pro: No worries of SPOF. Great.
I am more familiar with. I live in the shell. I use shell for everyday works instead of C.
Con: No statical check, e.g. whether functions (commands) exist, and everything else. Doesn't matter.

With shell we have much easier modular programming because we can much more easily test stuff. Modules are themselves a 'main' and we don't need to write main() for tests.

If to write in sh there is no need to test carefully at all. User will test. If some module fails, it's nothing, since SPOF in sh won't halt the main loop, and you can fix that tomorrow or next week. Bugs doesn't harm.

So sh. Anyway time will tell. Currently plan to write the lottery analysis system too in sh. Cool dialog(1). Buy a new old laptop for server. FTP/HTTP/whatever to retrieve Excel reports.

Time will tell.

---

Still C.

Don't you feel insecure writing sh?
You don't know whether those commands will change.
Essentially, there are more layers of abstraction.

Those layers are unnecessary.
Segmantation fails? Be cautious! It doesn't require soooo much cautious.
Test modules? Also easy! Just some more several lines.