# HG changeset patch # User David Demelier # Date 1617909479 -7200 # Node ID 3aaac1af65d53981d37c77bb55b7281600ea66ea # Parent 4f601ea0b6cfeddfbba334bca0b1144f51df8526 lots of updates diff -r 4f601ea0b6cf -r 3aaac1af65d5 Makefile --- a/Makefile Wed Jan 20 14:14:38 2021 +0100 +++ b/Makefile Thu Apr 08 21:17:59 2021 +0200 @@ -56,7 +56,8 @@ faq.md \ index.md \ versioning.md \ - news/2020-01-13.diet.md + news/2021-01-13.diet.md \ + news/2021-02-16.irccd-4-try.md SITE_HTML= ${SITE_SRCS:.md=.html} .SUFFIXES: @@ -85,8 +86,8 @@ doxygen: ${WKRDIR} mkdir -p irccd-${VERSION}/build - cmake -S irccd-${VERSION} -B irccd-${VERSION}/build > /dev/null 2>&1 - cmake --build irccd-${VERSION}/build --target doxygen > /dev/null + cmake -S irccd-${VERSION} -B irccd-${VERSION}/build + cmake --build irccd-${VERSION}/build --target doxygen rsync -a --delete irccd-${VERSION}/build/doc/doxygen/html/ doxygen www: ${SITE_HTML} man doxygen diff -r 4f601ea0b6cf -r 3aaac1af65d5 faq.md --- a/faq.md Wed Jan 20 14:14:38 2021 +0100 +++ b/faq.md Thu Apr 08 21:17:59 2021 +0200 @@ -106,14 +106,29 @@ is still quite minimal. Because irccd offers a runtime controllable mechanism with lots of commands (30 -at this time of writing), it increases the total number of lines of code and -since it's written in C++, yes it requires some time to build. Please also note -that irccd is excessively tested. +at this time of writing), it increases the total number of lines of code. Please +also note that irccd is excessively tested. We could argue that a lots of these +command may be unneeded but I like that I can keep the daemon running for months +without having to shut it down and restart it to change its nickname. + +The Javascript glue code also requires more than the half of the code base to +bind the C code to the Javascript interpreter. Disabling Javascript reduces the +total code by more than 60%. -On the other hand, I must admit that I regret having used [boost][] for such a -small project which definitely increased its complexity in some parts. But given -its current stability and completeness, there are no plans to rewrite irccd in -C. +But in other hand, irccd still follows the UNIX philosophy of doing minimal +things and be extended by the user externally through plugins. It also tries to +stick to POSIX and use as much as possible simple and clean code. By itself, +irccd's responsability is to poll IRC events, call plugins and hooks and that's +it. + +Shouldn't irccdctl be named irccctl? +------------------------------------ + +Yes, technically speaking UNIX daemons may have a name `bard` and an optional +utility `barctl` without the trailing 'd' to control the daemon. But since irccd +has already two 'c' irccctl would be annoying to type especially since having +three identical consecutive letter is unusual. So as an exception, the utility +is named `irccdctl` rather than `irccctl`. What does irccd drink? ---------------------- diff -r 4f601ea0b6cf -r 3aaac1af65d5 index.md --- a/index.md Wed Jan 20 14:14:38 2021 +0100 +++ b/index.md Thu Apr 08 21:17:59 2021 +0200 @@ -24,7 +24,8 @@ News ---- -- (2021-01-13) Irccd is going on a diet. [More…](2020-01-13.diet.html) +- (2021-02-16) Irccd 4 is available for testing. [More…](2021-02-16.irccd-4-try.html) +- (2021-01-13) Irccd is going on a diet. [More…](2021-01-13.diet.html) - (2021-01-04) Bugfix release: irccd 3.1.1, - (2020-07-03) Minor release: irccd 3.1.0, - (2019-10-06) Bugfix release: irccd 3.0.3, diff -r 4f601ea0b6cf -r 3aaac1af65d5 news/2020-01-13.diet.md --- a/news/2020-01-13.diet.md Wed Jan 20 14:14:38 2021 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,187 +0,0 @@ -% Going on diet -% David Demelier -% 2020-01-13 - -Irccd is going on diet -====================== - -Since my original irccd implementation in mostly pure C++11 in 2013, I was -pretty happy with the result. It was small, lightweight with a clean code base. -At this time it was also using Lua instead of Javascript but after several -headaches maintaining support for every Lua version that break compatibility I -was suggested (by a Lua user!) to use Duktape if I like Javascript. - -Anyway, for the version 2.0.0 I've started adding more features and splitting -the code a lot. It was still fine but I faced several issues with my own code, -especially in the timer and portable sockets selector (epoll, kqueue, poll) and -so I decided to move to Boost for the 3.0.0 version. - -This was my main regret. - -Boost -===== - -Boost is a indeed quality framework that is stable and proven. But it's bloat -and terribly complex. The code base grown a lot to add generic support and -required to use templates all over the place. I was quite disappointed about the -status of the code no matter portable it was. The module [Program_Options][] is -also total nonsense of complexity to parse simple options. I finally ended up -writing my own portable [`getopt(3)`][options] in 69 lines of code. - -The build process also evolved in the wrong way, it now requires more than five -minutes to build the entire project even though it only consists of roughly -19000 lines of code (unicode support adds by itself 5000 lines of pure data). - -C++20 and beyond -================ - -When I first started learning C++11 I was really loving the new functionalities -and would honestly not switch to it (from C) if it wasn't there. It's safer, -more robust and cleaner in several aspects. - -But as a guy who needs to updates itself when there are new revisions, I've -upgraded irccd to newer C++ versions each time they were broadly supported. And -since C++20 I started scratching my head about the language complexity. -Concepts, modules, ranges. All syntax are weird and unwelcoming, I personally -think this language becomes more and more elitist. - -Future of irccd 4.0.0 -===================== - -Today I'm very glad announce that I'm rewriting irccd in pure POSIX/C for the -version 4.0.0. - -What's definitely better with C -------------------------------- - -- Compile time. -- Proper error messages. -- Less time spent on architecture (classes vs templates, polymorphism vs traits, - etc…). -- Simpler code in most cases. -- Less dynamic allocation. -- Faster in many places. - -Compatibility -------------- - -Since irccd is following the [semantic versioning][semver], the 4.0.0 branch is -allowed to do major breaking changes. But don't run away no many breaking -changes will happen. - -What will change ----------------- - -### irccd.conf and irccdctl.conf files - -Both tools were using a custom crafted .ini file format. In various places it -was quite unconvenient to use. For example configuring plugins require to write -different sections such as: - - [plugins] - hangman = - - [plugin.hangman] - collaborative = false - - [templates.hangman] - win = "congratulations!" - -Instead, the new files will be parsed using a custom DSL based on lex/yacc which -have the benefit of being part of POSIX. The format isn't finalized yet but I -can promise that it will look much better with some influences from the -venerable [pf.conf(5)][] file from OpenBSD. - -### Networking protocol - -To stay simpler, the network messages between `irccd` and `irccdctl` will come -back to a plain line based UTF-8 messages. - -Example: - - MESSAGE freenode #botwar oh hi! - TOPIC freenode #botwar this is my new topic. - -Error messages will be written in human format and no longer provide specific -error code either. - -### Windows support will be forwarded to second class citizen - -Windows isn't a platform I personally like because Microsoft is a company that -does not cooperate in portability. Writing POSIX software in Windows is a total -nightmare unless you run cygwin which is also annoying. - -Portability code will be added as much as possible as long as they don't pollute -the code. - -### Native API - -Obviously by switching from C++ to C, the C++ API becomes totally obsolescent. -The new exposed C API will be much simpler and less featureful than the previous -C++ one. This is because I think exposed API must only be related to irccd and -internal stuff must be kept as that. - -Also, the documentation of the exposed C API will be provided in manual pages -only as doxygen has a poor interface. As always, manual pages will be available -online as well too. - -### Unix transport only - -For simplicity reasons, the only transport supported will be based on UNIX -domain sockets without SSL, without password. Instead users are encouraged to -set permissions on the socket instead. - -This also reduce the code complexity a lot. - -What will be kept ------------------ - -### The Javascript API - -Now you can breathe. The Javascript for the most part will be kept untouched -with a few minor adjustments but your plugins should work without any -modifications. - -### All irccdctl commands - -All `irccdctl` commands will be kept as-is without any modification. - -Questions and answers -===================== - -Q: Why a bot in C? There are already ones! -A: Yes, but no one uses Javascript as extending language and no one supports - rules and templates like irccd. - -Q: Is it a rewrite from scratch? -A: No. Lot of code was simply converted from C++ to C by adapting some code - logic. The javascript being based on the C Duktape library did not need lots - of modifications. From scratch code is mostly: new transports, logs and irccd - main object. - -Q: Which C standard will it be written? -A: Mostly C99 with few bits from C11 like atomics and noreturn. - -Estimated time of arrival -========================= - -For now, the irccd 4 rewrite is on heavy progress and starts to be usable. It -will be probably released during fall 2021. - -Please come back to see the advancement on this page. - -- [x] Native plugins. -- [x] Javascript plugins. -- [x] Connect to IRC servers and dispatch messages to plugins. -- [x] Templates. -- [x] Logs (syslog, console, files). -- [x] Transport commands (almost complete). -- [ ] Configuration files. -- [x] Rules. -- [x] `irccd` frontend. -- [x] `irccdctl` frontend. - -[semver]: http://semver.org -[pf.conf(5)]: https://man.openbsd.org/pf.conf -[Program_Options]: https://www.boost.org/doc/libs/1_75_0/doc/html/program_options.html -[options]: http://hg.malikania.fr/code/file/tip/cpp/options/options.hpp diff -r 4f601ea0b6cf -r 3aaac1af65d5 news/2021-01-13.diet.md --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/news/2021-01-13.diet.md Thu Apr 08 21:17:59 2021 +0200 @@ -0,0 +1,192 @@ +% Going on diet +% David Demelier +% 2021-01-13 + +Irccd is going on diet +====================== + +Since my original irccd implementation in mostly pure C++11 in 2013, I was +pretty happy with the result. It was small, lightweight with a clean code base. +At this time it was also using Lua instead of Javascript but after several +headaches maintaining support for every Lua version that break compatibility I +was suggested (by a Lua user!) to use Duktape if I like Javascript. + +Anyway, for the version 2.0.0 I've started adding more features and splitting +the code a lot. It was still fine but I faced several issues with my own code, +especially in the timer and portable sockets selector (epoll, kqueue, poll) and +so I decided to move to Boost for the 3.0.0 version. + +This was my main regret. + +Boost +===== + +Boost is a indeed quality framework that is stable and proven. But it's bloat +and terribly complex. The code base grown a lot to add generic support and +required to use templates all over the place. I was quite disappointed about the +status of the code no matter portable it was. The module [Program_Options][] is +also total nonsense of complexity to parse simple options. I finally ended up +writing my own portable [`getopt(3)`][options] in 69 lines of code. + +The build process also evolved in the wrong way, it now requires more than five +minutes to build the entire project even though it only consists of roughly +19000 lines of code (unicode support adds by itself 5000 lines of pure data). + +C++20 and beyond +================ + +When I first started learning C++11 I was really loving the new functionalities +and would honestly not switch to it (from C) if it wasn't there. It's safer, +more robust and cleaner in several aspects. + +But as a guy who needs to updates itself when there are new revisions, I've +upgraded irccd to newer C++ versions each time they were broadly supported. And +since C++20 I started scratching my head about the language complexity. +Concepts, modules, ranges. All syntax are weird and unwelcoming, I personally +think this language becomes more and more elitist. + +Future of irccd 4.0.0 +===================== + +Today I'm very glad announce that I'm rewriting irccd in pure POSIX/C for the +version 4.0.0. + +What's definitely better with C +------------------------------- + +- Compile time. +- Proper error messages. +- Less time spent on architecture (classes vs templates, polymorphism vs traits, + etc…). +- Simpler code in most cases. +- Less dynamic allocation. +- Faster in many places. + +Compatibility +------------- + +Since irccd is following the [semantic versioning][semver], the 4.0.0 branch is +allowed to do major breaking changes. But don't run away no many breaking +changes will happen. + +What will change +---------------- + +### irccd.conf and irccdctl.conf files + +Both tools were using a custom crafted .ini file format. In various places it +was quite unconvenient to use. For example configuring plugins require to write +different sections such as: + + [plugins] + hangman = + + [plugin.hangman] + collaborative = false + + [templates.hangman] + win = "congratulations!" + +Instead, the new files will be parsed using a custom DSL based on lex/yacc which +have the benefit of being part of POSIX. The format isn't finalized yet but I +can promise that it will look much better with some influences from the +venerable [pf.conf(5)][] file from OpenBSD. + +### Networking protocol + +To stay simpler, the network messages between `irccd` and `irccdctl` will come +back to a plain line based UTF-8 messages. + +Example: + + MESSAGE freenode #botwar oh hi! + TOPIC freenode #botwar this is my new topic. + +Error messages will be written in human format and no longer provide specific +error code either. + +### Windows support will be forwarded to second class citizen + +Windows isn't a platform I personally like because Microsoft is a company that +does not cooperate in portability. Writing POSIX software in Windows is a total +nightmare unless you run cygwin which is also annoying. + +Portability code will be added as much as possible as long as they don't pollute +the code. + +### Native API + +Obviously by switching from C++ to C, the C++ API becomes totally obsolescent. +The new exposed C API will be much simpler and less featureful than the previous +C++ one. This is because I think exposed API must only be related to irccd and +internal stuff must be kept as that. + +Also, the documentation of the exposed C API will be provided in manual pages +only as doxygen has a poor interface. As always, manual pages will be available +online as well too. + +### Unix transport only + +For simplicity reasons, the only transport supported will be based on UNIX +domain sockets without SSL, without password. Instead users are encouraged to +set permissions on the socket instead. + +This also reduce the code complexity a lot. + +What will be kept +----------------- + +### The Javascript API + +Now you can breathe. The Javascript for the most part will be kept untouched +with a few minor adjustments but your plugins should work without any +modifications. + +### All irccdctl commands + +All `irccdctl` commands will be kept as-is without any modification. + +Questions and answers +===================== + +Q: Why a bot in C? There are already ones! +: Yes, but no one uses Javascript as extending language and no one supports + rules and templates like irccd. + +Q: Is it a rewrite from scratch? +: No. Lot of code was simply converted from C++ to C by adapting some code + logic. The javascript being based on the C Duktape library did not need lots + of modifications. From scratch code is mostly: new transports, logs and + irccd main object. + +Q: Which C standard will it be written? +: Mostly C99 with few bits from C11 like atomics and noreturn. + +Estimated time of arrival +========================= + +For now, the irccd 4 rewrite is on heavy progress and starts to be usable. It +will be probably released during fall 2021. + +Please come back to see the advancement on this page. + +- [x] Native plugins. +- [x] Javascript plugins. +- [x] Connect to IRC servers and dispatch messages to plugins. +- [x] Templates. +- [x] Logs (syslog, console, files). +- [x] Transport commands (almost complete). +- [x] Configuration files. +- [x] Rules. +- [x] `irccd` frontend. +- [x] `irccdctl` frontend. +- [ ] Excessive testing. +- [x] Plugin `links` rewrite (was a native C++ plugin). +- [x] New Irccd.Rule API. +- [x] New Irccd.Hook API. +- [x] Hooks. + +[semver]: http://semver.org +[pf.conf(5)]: https://man.openbsd.org/pf.conf +[Program_Options]: https://www.boost.org/doc/libs/1_75_0/doc/html/program_options.html +[options]: http://hg.malikania.fr/code/file/tip/cpp/options/options.hpp diff -r 4f601ea0b6cf -r 3aaac1af65d5 news/2021-02-16.irccd-4-try.md --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/news/2021-02-16.irccd-4-try.md Thu Apr 08 21:17:59 2021 +0200 @@ -0,0 +1,42 @@ +% Irccd 4 available for testing +% David Demelier +% 2021-02-16 + +Irccd 4 is available for testing +================================ + +For less than one month of work, irccd 4 is already available for extreme +testing. All features are implemented, only tests and miscellaneous fixes or +cleanup are still pending. + +There are some breaking changes but they are documented as usual as it is a +major change. See [MIGRATING.md][] file for steps required. + +How to try +========== + +There are no official releases for alpha software on Malikania, you will need to +use the [Mercurial][hg] to download irccd 4. The *default* branch at this time +of writing already contain irccd 4 code. + +Install prerequisites as detailed in the [INSTALL.md][] file and you can quickly +install irccd 4 as following: + + hg clone http://hg.malikania.fr/irccd + cd irccd + mkdir build + cd build + cmake .. -DCMAKE_BUILD_TYPE=Debug + make && sudo make install + (edit a irccd.conf) + irccd -c irccd.conf + +Please make sure to read the new `irccd.conf(5)` manual page, the syntax has +changed. + +Please report any bugs or error to the [dev mailing list][ml]. + +[INSTALL.md]: http://hg.malikania.fr/irccd/file/tip/INSTALL.md +[MIGRATING.md]: http://hg.malikania.fr/irccd/file/tip/MIGRATING.md +[hg]: http://mercurial-scm.org +[ml]: http://malikania.fr/mailing-lists.html