gg582

It's like reviving Xiangshu school in 21st century..

I did this for fun, and it is definitely not a good portfolio to get a job as a C programmer.

I was a bit tired of reading some toys made with NextJS+Tailwind CSS+Ugly Glossy Theme+Redis docker image, so I just thought that I can write something else for my toy projects like my dev blog.

Anyway, now let's see "why it's simple?"

It's an example from CWIST's readme:

  #include <cwist/app.h>

  static void hello(cwist_http_request *req, cwist_http_response *res) {
      (void)req;
      cwist_sstring_assign(res->body, "Hello from CWIST!");
  }

  int main(void) {
      cwist_app *app = cwist_app_create();
      cwist_app_get(app, "/", hello);
      cwist_app_listen(app, 8080);
      cwist_app_destroy(app);
      return 0;
  }

Some would say it's not that simple. They may say this:

  #include <cwist.h>

  static void hello(cwist_http_app *app) {
      cwist_sstring_assign(app->res->body, "Hello from CWIST!");
  }

  static void setApp(cwist_http_app *app) {
      CWIST_APP_CREATE(app);
      app->get.append(app->get, "/", hello);
      app->ipv4.port = 8080;
  }

  int main(void) {
      CWIST_APP_LISTEN(app);
      CWIST_APP_DESTROY(app);
  }

Yeah, it looks reasonable at a glance. And this definitely has its own strength. But, some parts are set up by struct members. some are not. some are in ALL CAPS, and some are not. Also, header amalgamation can be easily done by some scripts.

Well, in my opinion unifying 'conventions' as many as I can would be a good solution for simplifying code.

When somebody vibe-codes an application without looking at their code (although it's a really bad habit but I've seen somebody who does it) hallucinations are more frequently happened from struct members. However public functions seems quite good to be probabilistically inferenced.

Also, the second one needs more "helper codes". Formally, yep, CWIST's main is kinda bloated, but each step specified in the main function is executed by an explicit wrapper function. It's just like making a lego building.

I know it's not like Drogon. There are really many "mature" C/C++ web frameworks like Drogon, and when you are doing things for production, you cannot use this framework since it's not measured and monitored by security professionals.

Each change should pass sanitizers, cppcheck, http soak test, https c100k test, wasm/wasi smoke test, http/2 test, and so on. Actually I thought that I should do something for http/3, but it's just borrowing many things from lsquic so I just didn't do it.

It's in this external benchmark:

https://web-frameworks-benchmark.netlify.app/

Although it's not "blazingly fast C web framework other than CGI", its performance is fair for developing some small websites. And I am pretty sure it will give you a new perspective to see your code as a "well-structured building".

C4Punks is an organization with many people but some members are quite busy to co-maintain this, so currently I am mainly checking its status. But it's quite hard to read all those modules and refactor, sometimes I couldn't sleep before releasing a new tag.

Any pull requests (including documentations) are welcomed:

https://github.com/c4punks/CWIST/issues

Thanks for reading.

I did this for fun, and it is definitely not a good portfolio to get a job as a C programmer.

I was a bit tired of reading some toys made with NextJS+Tailwind CSS+Ugly Glossy Theme+Redis docker image, so I just thought that I can write something else for my toy projects like my dev blog.

Anyway, now let's see "why it's simple?"

It's an example from CWIST's readme:

  #include <cwist/app.h>

  static void hello(cwist_http_request *req, cwist_http_response *res) {
      (void)req;
      cwist_sstring_assign(res->body, "Hello from CWIST!");
  }

  int main(void) {
      cwist_app *app = cwist_app_create();
      cwist_app_get(app, "/", hello);
      cwist_app_listen(app, 8080);
      cwist_app_destroy(app);
      return 0;
  }

Some would say it's not that simple. They may say this:

  #include <cwist.h>

  static void hello(cwist_http_app *app) {
      cwist_sstring_assign(app->res->body, "Hello from CWIST!");
  }

  static void setApp(cwist_http_app *app) {
      CWIST_APP_CREATE(app);
      app->get.append(app->get, "/", hello);
      app->ipv4.port = 8080;
  }

  int main(void) {
      CWIST_APP_LISTEN(app);
      CWIST_APP_DESTROY(app);
  }

Yeah, it looks reasonable at a glance. And this definitely has its own strength. But, some parts are set up by struct members. some are not. some are in ALL CAPS, and some are not. Also, header amalgamation can be easily done by some scripts.

Well, in my opinion unifying 'conventions' as many as I can would be a good solution for simplifying code.

When somebody vibe-codes an application without looking at their code (although it's a really bad habit but I've seen somebody who does it) hallucinations are more frequently happened from struct members. However public functions seems quite good to be probabilistically inferenced.

Also, the second one needs more "helper codes". Formally, yep, CWIST's main is kinda bloated, but each step specified in the main function is executed by an explicit wrapper function. It's just like making a lego building.

I know it's not like Drogon. There are really many "mature" C/C++ web frameworks like Drogon, and when you are doing things for production, you cannot use this framework since it's not measured and monitored by security professionals.

Each change should pass sanitizers, cppcheck, http soak test, https c100k test, wasm/wasi smoke test, http/2 test, and so on. Actually I thought that I should do something for http/3, but it's just borrowing many things from lsquic so I just didn't do it.

It's in this external benchmark:

https://web-frameworks-benchmark.netlify.app/

Although it's not "blazingly fast C web framework other than CGI", its performance is fair for developing some small websites. And I am pretty sure it will give you a new perspective to see your code as a "well-structured building".

C4Punks is an organization with many people but some members are quite busy to co-maintain this, so currently I am mainly checking its status. But it's quite hard to read all those modules and refactor, sometimes I couldn't sleep before releasing a new tag.

Any pull requests (including documentations) are welcomed:

https://github.com/c4punks/CWIST/issues

Thanks for reading yall.

This was somehow flagged as a spam post.

I hope you enjoyed this.

Nice, what's your example website? I'd like to check if it really seems better

Features

CWIST GC for fast prototyping. It's closer to a garbage sweeper than a traditional GC, and lighter.

Dev blog engine

HTML Template Engine

WASM

..well

Hacker News doesn't support bullet style with -

..I didn't expect this. I guess it's not md4c based one

It is a long way but I shall continue..

I guess there are cultural biases here, I hope to study together with somebody who knows Latin or Greek :)

Yep that's right. Using #if/#endif excludes whole lines(so compiler won't see any lines). And this difference can prevent when struggling with nested comments :)

Honestly I don't pretty sure if this post will impress somebody or not. But after a long period of vibe-coding I think I'm trying to do these methods..

some logics were reorganized. 感->減(sensing->reduction)

Some conventions are socially made... In C, some uses

#if 0

    these_lines_are();
    not_executed();

#endif

but most of the cases people just use

/* comments

* these_lines_are();

* not_executed();

*

* end comment */

Then, why?

#if 0

#endif

looks clear and it definitely says how a computer skips many lines.

But we just don't use it because it implies low-level knowledge "that every C developers have"

yep. There was a maintenance. :)

That's cool. Using a same logic, we can say 'Undefined behaviors are not behaviors.'

tried a silly crossover mapping memory reclamation invariants (visibility, UAF, CAS) to old trigram structures in c11. surprisingly mapped 1:1 pretty well. put the puzzle and code snippets here

That is a valid point. When you are developing an application for an STM32, allocating memory on the heap is a bad idea. But if a programmer wants to make a high-performance back-end server in C, they should allocate unpredictable amounts of memory depending on a user's input(in many cases). This is not for Embedded/Hardware control; it aims for 'C Revival for High-level Development'. For a good example, many modern Rust applications do not statically fix memory areas; that is why Rust had to develop such a complex memory ownership system. In my personal opinion, with a bag of potato chips, you can do it better in C. Honestly, this does not have a proper memory tracker, so- yes. This does not have any advantages for now. However, I am planning to develop a memory lifetime tracker that can catch issues even before we run Valgrind or GDB. You can try to develop your own memory manager. This helped me to make my C-based web development framework safer through refactoring.

:)

Yes. But in my opinion, this is more than a problem of communication. Many open source projects fail to retain their management cycle, or ecosystem even they have their Discord, or IRC to communicate. Many open source projects are having trouble retaining themselves and the core problem of them are 'they are just thriving in their cultural boundaries'. For example, in our country, South Korea, many open source projects are born and just die within a few years. And their core problem was 'only Korean developers can understand what is actually happening in that open source group'. I think that Debian volunteers communicate quite well, but the way how they communicate is immature. And, at least, they should let people know how they try hard to keep them alive. Debian is famous, and many developers in here think that it is 'a standard one for the normal office'. That means, no matter how Debian volunteers trying so hard, many people would perceive it as a 'untouchable' realm. Then it is important to re-think how to get people to continue on some positions. Debian still has translated documentations, even in a niche language. Like that, Debian should make more ways to 'encourage' developers to cooperate, in many languages. In 21th century, there's a great translator, so allowing people who don't speak English well, may not be a problem. Something like..yep, better than disappearing.

I guess my comment is kinda messy, hm..Anyway, thanks for the reminder. Have a good day!

:)

I believe the problem with Debian and many open source projects is that communities outside the US, Greater China, India, and some advanced European countries are relatively weak, making it difficult for project leader-level figures to emerge. I was born and raised in South Korea, a virtual open-source wasteland. Listening to testimonies from developers working here, many say, “I was captivated by the GNU spirit and wanted to contribute, but the Korean community's operations were poor, and clique-based territorialism was severe.” Ultimately, many open-source projects paradoxically miss out precisely because of their idealism and open management culture. I'd like to summarize it this way:

- Combining open source developers outside the core development regions and major cultural spheres could potentially secure roughly as many contributors as the entire US. - Funding shortages for non-profit foundations are deeply entrenched. Denying or attempting to fix this immediately becomes greed. - It is possible to manage language barriers, cultural barriers, and guidelines for distant countries without becoming a greedy for-profit entity. - This does not mean holding DebConf in every country. However, if the awareness is simply that ‘there used to be no borders, but now it's different from the 90s’ regarding the shortage of personnel, then improvements should be more proactive. - The 2020s are no longer an era of romanticism where one flies from Angola to Germany just for the sake of romance. - Especially as Debian has established itself as an invisible system, becoming the backbone of countless cloud services, there is less room for romanticism to intervene.

I've used Debian since 2015 and have had no complaints during that time. Korea also had ‘administrators’ who spared no expense on plane tickets for GNU since the 90s, but most have now stepped down due to age, or, exhausted from trying to salvage communities torn apart by toxic members, have turned around and declared ‘BSD was right’. However, the project's sustainability deteriorating due to a ‘lack of administrators’ is definitely something that needs to be considered. If sufficient people cannot be recruited, and given that we cannot extend the freeze cycle like Slackware at present, communication between upstream and downstream and the active recruitment of multinational developers are important to resolve the complaints of ‘dependent families’ like Ubuntu.

Visualizing medical records that are difficult for the general public to understand is an excellent idea. The thorough explanations and diagrams make it an excellent educational resource. If its UX was designed with an educational website in mind, it's honestly a huge success. However, the lack of a light mode and the absence of search functionality for specific cases are a bit disappointing. If it's meant to function well as supplementary material for students, having those features would be great. But the decision is yours, and I also respect the choice to maintain the current style while considering other directions.