#Haskell testing question:
What's the usual way of setting up a cabal project for testing? Do I add another executable in the cabal file that depends on the library I'm testing?
I'm not asking how to write tests or which framework to use, but how to run the tests without having to manually invoke ghc (I saw one example on the internet that did that). Basically, what's the equivalent of a "cabal test" command.
I'm working on a game server in #Go. I need to send the game state to every client that is connected. The game state is stored as a map from *Client to *ClientState. I could send the state object to each client's send channel, but I think that since it contains pointers to state that's constantly being updated, the state object would be changing from under each client's feet. I am surprised I haven't found any documentation or anything on the internet warning about this. Am I thinking correctly?
I don't understand why technologies need to distinguish between synchronous (chat) and asynchronous (email) communication. There is certainly a difference in UI, but couldn't the supporting technology be the same? Couldn't we build an email app on top of a chat server? Or a chat app on top of email (DeltaChat does this). Would it make sense for a company to pick one chat/email platform and use it for both sync and async communication? (assuming the platform has both sync and async applications)
The Alot is an amazing creature. Just discovered this article during my roaming through terminal email clients.
I'm trying to wrap my mind around how to make mbsync work well with gmail.
It seems that mbsync creates a "Starred" folder, but it also attaches the important modifier onto them. Locally, it seems to make sense to not have the Starred folder and just filter to important emails.
Also, on gmail, I see the same email in my inbox and in the starred view. This means the email is duplicated by mbsync, right? Seems bad.
Does anybody have ideas for how to use mutt and gmail effectively together?
I wrote this explanation of #Federation for the non-technical user. It's not very in-depth, nor very long. I'm not totally satisfied with how I wrote it, so I may rework it in the future when I have more motivation.
Let me know of any problems or issues you find.
I'd like to know why so many people have gravitated towards Matrix, but not many towards XMPP. Also, why do Matrix detractors not advocate XMPP?
In particular, I'm concerned with the experience for non-technical users as well.
@sir, I'd appreciate your input, since I know you advocate IRC; is there anything specifically wrong with XMPP?
I've been using #Matrix for getting to about a year now. It's been a good experience, since I've stuck with using Synapse and Riot (the reference server and client), but everything else is incomplete. In addition, Synapse is a memory hog.
I've also become aware of #XMPP, which seems to be a much simpler protocol. As I'm googling around, I've seen articles debunking XMPP myths, but then I also see a bunch of articles of companies moving away from #XMPP, because it's "outdated".
Maybe I should know this by now, but there is one thing I don't understand about the #Fediverse:
What is the difference between all the services (e.g. between #Mastodon and #PixelFed). Obviously PixelFed is for images and thus has an accordingly catered UI, but does the server also need to give special consideration to images? Isn't everything #ActivityPub? Does each service have to extend AP to support its type of content?