When someone queried Harley-Davidson bikers as to why they don't socialize with youngsters who are avid about the latest racing motorcycles, their response was, "Why should we bother? Every year, they have something new.
--
All jokes aside, check out these cool quotes about C++ from Linus Torvalds [0] and Ken Thompson [1] ;)
If I understand correctly, it's WebSocket on top of Embedded C/C++ web server (civetweb).
Also, the application must find and launch the installed browser. In my opinion, this part is very fragile. On my system, this function (webui/src/webui.c) :
Agree finding browsers can be tricky, but the node Chrome-launcher package has a fairly good approach that you can patch and extend to the other vendors.
In graderjs i solve this by searching for the installed browser, and then prompting the user to download it —obviously just the first time! — if we couldn’t find it. so the download and install happens as part of the application start up process and it’s baked into the framework. I think it’s a nice solution where the application installs any components that might need.
I think another nice solution would be to use playwright because that usually downloads all browsers that you might want and I’m sure that can be customized. playwright is a reliable source and it’ll put them in a location that easy to find.
Do you have "open URLs with a browswer" turned off in your OS? Because that's the universal way to open "whatever the user has set as their default browser".
> Do you have "open URLs with a browswer" turned off in your OS?
But the application works differently. It needs the browser in kiosk mode, which means it should be able to run the browser binary with specific arguments.
civetweb will run cross platform as a http server.
the issue is when you need write code on each OS, e.g. a cgi for windows/macos/linux/bsd, you will have to know the native API for each OS and use them, which could be hard to maintain if cross-platform is a must.
I wish there is something lower level that is truly cross platform, e.g. a C library runs on each OS and let me do filesystem/network/etc, it does not seem exist.
It's only "compressed" if it was made by compress(1) in France. Otherwise it's just sparkling entropy coding.
For reference:
1490 xmas-with-leading-comment.c
913 xmas-without-leading-comment.c
2357 xmas.out
1297 xmas.out.9.Z
1038 xmas.out.10.Z # actually better than with more bits!
1048 xmas.out.11.Z # compression with 11..16 bits have the same size
319 xmas.out.1.gz # compression levels 1..2 has same size
317 xmas.out.3.gz
307 xmas.out.4.gz # compression levels 4..9 have same size
Note that despite looking hard I haven't found a version of `compress` that supports `-H`, which is referenced and decompressable by gzip. I'm not sure how common it was in the wild.
% gcc xmas.c
xmas.c:2:1: warning: return type defaults to 'int' [-Wimplicit-int]
2 | main(t,_,a)
| ^~~~
xmas.c: In function 'main':
xmas.c:2:1: warning: type of 't' defaults to 'int' [-Wimplicit-int]
xmas.c:2:1: warning: type of '_' defaults to 'int' [-Wimplicit-int]
% wc -c <xmas.c
913
% ./a.out | wc -c
2359
% ./a.out | compress | wc -c
1048
zstd -19 compresses the text of the song to 309 bytes.
To be a fair comparison, though, you'd have to write zstd -d in 604 bytes. I suppose to be REALLY fair, though, you have to count the bytes of code in the compiler itself. A convenient enough implementation of compression could index into the C compiler binary to find the bytes it needs. (For example, my GCC contains "first", "second", and "third" in the binary, which a sufficiently clever implementation could make use of. "Exit on the first error occurred.", "Append a second underscore if the name already contains an underscore.", "Warn about suspicious calls to memset where the third argument is constant literal zero and the second is not.", etc. I didn't check but I doubt turtle doves or maids-a-milking come up that often in the description of warning flags.)
And that comment was clearly written in 1988. I fail to see what's so hard to understand about that and why people feel the need to "prove" it's "wrong".
I don't think people are trying to prove it's wrong. Most of the comments are saying that general purpose technology in 2023 doesn't reduce the file size by as much as the manual job in 1988 did.
This particular entry to the IOCCC was for 1988, those two algorithms didn’t come about for a few more years after that, gzip in the early nineties and 7z later that decade. The note is probably correct when comparing against the state of the art at the time.
The program that produces the song, without the introductory comment, is 913 bytes, as presented in the article. Removing whitespaces it uses just 800 bytes and produces the song which is 2359 chars here. The whole C is:
Since the word 'compressed' is in quotes they are probably suggesting that they mean when processed by the 'compress' command as available on UNIX at the time, as opposed to some other compression available at the time.
The program was written in 1988. I ran the text through LZSS which was published in 1982, so was available before 1988. I used a 1989 public domain version by Haruhiko Okumura, which is after 1988, but I don't believe it is optimized to improve upon the compression level of the 1982 algorithm.
It took it from 2357 bytes to 534 bytes, which is smaller than the Xmas.c program which I counted as 917 bytes, but another poster counted 913 bytes.
The only effective way to raise the confidence level of a program significantly is to give a convincing proof of its correctness. [0]
Edsger W. Dijkstra
CONTEXT:
Argument three is based on the constructive approach to the problem of program correctness. Today a usual technique is to make a program and then to test it. But: program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence. The only effective way to raise the confidence level of a program significantly is to give a convincing proof of its correctness. But one should not first make the program and then prove its correctness, because then the requirement of providing the proof would only increase the poor programmer’s burden. On the contrary: the programmer should let correctness proof and program grow hand in hand. Argument three is essentially based on the following observation. If one first asks oneself what the structure of a convincing proof would be and, having found this, then constructs a program satisfying this proof’s requirements, then these correctness concerns turn out to be a very effective heuristic guidance. By definition this approach is only applicable when we restrict ourselves to intellectually manageable programs, but it provides us with effective means for finding a satisfactory one among these.
[0] Edsger Dijkstra - Turing Award Lecture - The Humble Programmer - 1972
By the way you can run the games locally. Just download all files.
For the forest game you would have a local directory:
then just run the following in the directory [1] https://www.youtube.com/watch?v=a74KM792gbo