Searching yarn

Twts matching #cycling
Sort by: Newest, Oldest, Most Relevant
In-reply-to » Dang it! I ran into import cycles with shared test utilities again. :-( Either I have to copy this function to set up an in-memory test storage across packages or I have to put it in the storage package itself and guard it with a build tag that is only used in tests (otherwise I end up with this function in my production binary as well). I don't like any of the alternatives. :-(

@xuu@txt.sour.is My layout looks like this:

  • storage/
    • storage.go: defines a Storage interface
    • sqlite.go: implements the Storage interface
    • sqlite_test.go: originally had a function to set up a test storage to test the SQLite storage implementation itself: newRAMStorage(testing.T, $initialData) *Storage
  • controller/
    • feeds.go: uses a Storage
    • feeds_test.go: here I wanted to reuse the newRAMStorage(…) function

I then tried to relocate the newRAMStorage(…) into a

  • teststorage/
    • storage.go: moved here as NewRAMStorage(…)

so that I could just reuse it from both

  • storage/
    • sqlite_test.go: uses testutils.NewRAMStorage(…)
  • controller/
    • feeds_test.go: uses testutils.NewRamStorage(…)

But that results into an import cycle, because the teststorage package imports storage for storage.Storage and the storage package imports testutils for testutils.NewRAMStorage(…) in its test. I’m just screwed. For now, I duplicated it as newRAMStorage(…) in controller/feeds_test.go.

I could put NewRAMStorage(…) in storage/testutils.go, which could be guarded with //go:build testutils. With go test -tags testutils …, in storage/sqlite_test.go could just use NewRAMStorage(…) directly and similarly in controller/feeds_test.go I could call storage.NewRamStorage(…). But I don’t know if I would consider this really elegant.

The more I think about it, the more appealing it sounds. Because I could then also use other test-related stuff across packages without introducing other dedicated test packages. Build some assertions, converters, types etc. directly into the same package, maybe even make them methods of types.

If I went that route, I might do the opposite with the build tag and make it something like !prod instead of testing. Only when building the final binary, I would have to specify the tag to exclude all the non-prod stuff. Hmmm.

⤋ Read More

Dang it! I ran into import cycles with shared test utilities again. :-( Either I have to copy this function to set up an in-memory test storage across packages or I have to put it in the storage package itself and guard it with a build tag that is only used in tests (otherwise I end up with this function in my production binary as well). I don’t like any of the alternatives. :-(

⤋ Read More

The editor can launch a new shell now:

https://movq.de/v/6ec68b50dd/los86-edit-shell.mp4

Trivial to implement but super useful. It allows for simple but meaningful dev cycles: Edit source code, run/test it, back to editor. That’s what I do in the video.

(The Brainfuck program is silly, but I got nothing else at the moment.)

The I/O cache is also getting better. All that back and forth doesn’t hit the disk at all, once cached.

This whole thing is much more fun and interesting when you run it from a real floppy disk. It’s a 5.25” floppy in the video (so it’s actually floppy 😅). Disk seek times can be catastrophic and you don’t notice any of this on modern disks.

⤋ Read More
In-reply-to » There’s a lot more activity in Geminispace than I realized: gemini://warmedal.se/~antenna/

gemini calls the request-response cycle a transaction in the spec. since trasactions are not cached, we have this problem where we can’t tell if anything was updated without fetching it and we can’t indicate how often a client should expect the content to be valid. the most common solution right now to just to keep requesting the resource until it changes or stops existing, which isn’t ideal. this sort of update notification model is interesting because it re-frames your thinking into something more like event sourcing. you end up needing to add an event queue and dispatch to the server, which is a bit more complex on the server side than plain static files, but the client stays the same. i’m curious to see what kind of systems could be built on this gemini message queue concept.

⤋ Read More
In-reply-to » Russia blowing up the Nova Kakhovka dam is an incomprehensible war crime. Among other things, it drains water from the Zaporizhzhia nuclear power plant, water that is needed for cooling. They are trying to generate a widespread disaster.

@prologic@twtxt.net I don’t agree. I think he’s a thug who benefits a lot if everybody thinks he’s a madman.

All through this war, there has been a repeated cycle:

  • We can’t give Ukraine weapon X; that will provoke Putin and he’ll drop a nuke!
  • Russian propagandists threaten they’re about to drop nukes
  • After lots of hand wringing, some country gives weapon X to Ukraine
  • No nukes are dropped

We’re on like the 5th iteration of this. Now it’s about F-16 fighter jets. In the meantime, a lot of Ukrainians AND Russians are dying en masse.

⤋ Read More
In-reply-to » DEEPL now has a Writer https://www.deepl.com/write - very nice, fast and available in multiple languages. Write better texts, instantly.

@prologic@twtxt.net @carsten@yarn.zn80.net

There is (I assure you there will be, don’t know what it is yet…) a price to be paid for this convenience.

Exactly prologic, and that’s why I’m negative about these sorts of things. I’m almost 50, I’ve been around this tech hype cycle a bunch of times. Look at what happened with Facebook. When it first appeared, people loved it and signed up and shared incredibly detailed information about themselves on it. Facebook made it very easy and convenient for almost anyone, even people who had limited understanding of the internet or computers, to get connected with their friends and family. And now here we are today, where 80% of people in surveys say they don’t trust Facebook with their private data, where they think Facebook commits crimes and should be broken up or at least taken to task in a big way, etc etc etc. Facebook has been fined many billions of dollars and faces endless federal lawsuits in the US alone for its horrible practices. Yet Facebook is still exploitative. It’s a societal cancer.

All signs suggest this generative AI stuff is going to go exactly the same way. That is the inevitable course of these things in the present climate, because the tech sector is largely run by sociopathic billionaires, because the tech sector is not regulated in any meaningful way, and because the tech press / tech media has no scruples. Some new tech thing generates hype, people get excited and sign up to use it, then when the people who own the tech think they have a critical mass of users, they clamp everything down and start doing whatever it is they wanted to do from the start. They’ll break laws, steal your shit, cause mass suffering, who knows what. They won’t stop until they are stopped by mass protest from us, and the government action that follows.

That’s a huge price to pay for a little bit of convenience, a price we pay and continue to pay for decades. We all know better by now. Why do we keep doing this to ourselves? It doesn’t make sense. It’s insane.

⤋ Read More