"Everything we do to make it harder to create a website or edit a web page, and harder to learn to code by viewing source, promotes that consumerist vision of the web.
Pretending that one needs a team of professionals to put simple articles online will become a self-fulfilling prophecy. Overcomplicating the web means lifting up the ladder that used to make it possible for people to teach themselves and surprise everyone with unexpected new ideas."
C++ template progamming Show more
Today I learned what probably is the most bizarre usage of the C++ “template” keyword: when you need to put it in front of a template method invoked in an object which itself is a template, because apparently the compiler cannot figure out that by itself.
On a completely different note, I am starting to learn to make #pixelart with #aseprite focusing on very low-resolution images. The idea is to have technical limitations like the developers and graphics artists had in the times of 8-bit games.
This is a small text-in-a-plate which could have been a company logo for a #gameboy game. Well, technically it has more than 4 colours, but you get the idea 😜
Please bear with me while I #practice 🙏
It was cute for a while to be using a desktop environment which takes the baton of the GNOME 2.x user experience and keeps it alive in 2018. If works fine if you don't have a HiDPI monitor. The #Mate team is doing an interesting job, but for a similar UX that does work better (with its own set of HiDPI glitches) I would rather use the Budgie desktop + modern GNOME applications.
Well.. There is HiDPI support indeed in #mate 1.20, but it's a bit hit and miss: many of the applets in the panel come with their host of glitches, and the window-manager decorations remain conspicuously unscaled. The systray in particular jitters in-place by itself and has good chances of producing seizures.
Well, MATE 1.20 (derived from GNOME 2.x, but now using GTK+3) is out and finally it supports HiDPI, so let's give it a try… Mid ‘2000s nostalgia rush incooooming!
boost to pet
| _ _ l
/ ヽ ﾉ
│ | | |
／￣| | | |
After two days banging my head with this, now I had a moment of enlightenment: the data remains in limbo, but it does not trigger the GSource because the GSocket/GSource has been created in the child process *after* the data has been already accepted by the kernel, and therefore the “data available” event never gets triggered.
What the child process can do is use g_socket_get_available_bytes() as the first thing right after creating the GSocket, and manually invoke the “data ready” callback.
Of course, writing the data is successful and produces no errors. Theoretically the data should be buffered somewhere by the kernel, as the socket pair is expected to behave like a FIFO pipe. Any ideas?
I would really like to send an initial message over the socketpair which the spawned process would read right away on startup.
1. Create a GMainLoop.
2. Use socketpair(), wrap “server” side descriptor into a GSocket. Write some data.
4. Spawn a new process, passing the “client” side descriptor. This process also creates a GMainLoop and wraps the descriptor into a GSocket.
3. Server runs the main loop.
5. Client create sa GSource for the socket, to get async notifications on “data ready”, and starts its main loop.
The data written by the server process never triggers “data ready”. Where's my data?