If compiled languages bother you, then you’re gonna love assembly.

What do you mean “embedding lua into applications”?

I assume you mean you want an application extensible by user lua script?

You build an API that calls the lua interpreter and passes the script, and reads the output; same as you would for any other scripting language. You define what the inputs should be, create the interface for executing the user defined script through shell commands, and then retrieve the output.

For python you’re going to probably use this:

https://docs.python.org/3/library/subprocess.html#subprocess.check_output

For C# you’re going to use Process

https://stackoverflow.com/questions/4291912/process-start-how-to-get-the-output

The complexities arise in your implementation and there’s no single guide.

So many things unlabeled, I doubt I’ll ever fully grasp what this comic is trying to say.

It’s not and never claimed to be. Lemmy is a piece of software, the instance owners and community moderators choose what stays and what’s goes, every Lemmy instance is just a glorified forum of old internet. Federation means the post isn’t solely controlled by the instance owners, but deletion is federated so the instance deleting it sends notice to every other instance where it exists to delete it as well, and then it’s up to that instance to do it (tho Lemmy will do this automatically so it would require altering the server code to stop that)

Lazy devs would rather play video games than give me free shit?!

Where’s our roadmap?!! 😎

The search process basically works by looking for the “@” sign in the search term, if the name isn’t found locally, then it uses the apub process called “webfinger” to identify the instance and request the information from it. This process relies on the host server being online, correctly receiving the request, correctly responding, and then your server correctly ingesting that response before emitting the reply to you.

So if no one on your instance has already gone through this process, then there’s a couple chances for the chain of actions to fail, but once that community is “subscribed” and created locally, then your search without the “@” will fetch the “local copy”. Once that local copy exists, it “announces” itself to the home instance, this then tells the home instance to start emitting all the apub info to your local instance (new posts, comments, votes, etc).

So I believe what you’re seeing is first the get_communities takes a while to go through all of that. Because of that, while waiting the UI sets the results to “empty” until the actual return comes in, once the results come back and the UI updates the state, you see the community in the list. But until that community is “copied” locally, you can’t manually go that community from your local instance url simply because it doesn’t exist locally yet.

The issue also comes down to the fact that no instance needs to update. So if you’re requesting a v0.17.x instance community from a v0.18.x instance, the api’s changed and they may not communicate properly to your home instance. I’m sure there are other points of failure too.

But I believe the lingering “pending” state should be mostly fixed, if you’re using an instance that’s on 18.3 then I don’t think you should encounter that much…

EDIT: It should be noted, that once you search for the remote community, it will fetch the entire community, including all posts and comments, and populate the cache (which I believe lasts for 3 days as of 18.3 unless someone subscribes to it, at which point it’s effectively “saved” locally). This means big communities might be extremely slow to respond to the apub request

It would be better to replicate the db into a purpose built search engine like elasticsearch or TypeSense, and then modify the UI to use that. It’s dumb for lemmy to implement a search engine when there are better more supported systems out there. This isn’t really a lemmy feature, imo, outside of supporting deployments using those types of products.

I recently submitted a PR for stopping pictrs image federation. IMO the images themselves do not need to be downloaded when served by another pictrs instance. This would reduce the amount of diskspace and reduce the burden of hosting images that are unwanted by the instance owners.

What are your thoughts on this, and do you think this will be merged? https://github.com/LemmyNet/lemmy/pull/3799

Keep in mind that Christian zionists see Jewish settlement of Israel as part of the prophecy of revelations / second coming of Jesus.

That’s why they’re so supportive of this

The legend himself

I’m in my mid 30’s and I spent A LONG time working out, getting as fit as I could.

I still hated my body when I looked in the mirror, and I hated every second of the workout. “Post workout” I was so proud, but like, that’s equivalent to drinking so you could appreciate being sober.

I stopped a while ago and started just trying to eat healthy and focus on other sources of happiness. I’m much happier since!

I’m in my mid 30’s and I spent A LONG time working out, getting as fit as I could.

I still hated my body when I looked in the mirror, and I hated every second of the workout. “Post workout” I was so proud, but like, that’s equivalent to drinking so you could appreciate being sober.

I stopped a while ago and started just trying to eat healthy and focus on other sources of happiness. I’m much happier since!

Memmy has the feature and is very similar to Apollo (tho they don’t want to go for 1-1)

Should be in the App Store this week

Memmy has the feature and is very similar to Apollo (tho they don’t want to go for 1-1)

Should be in the App Store this week

Due to how federation works, the federated instance needs to accept and process the activity. Each application can define its own “optional” activity properties, but the activitypub specs define mandatory properties and some optional properties for coherence across the fediverse.

The way lemmy implements this is to use the activitypub-federation-rust library that the lemmy devs built. Through this, activities in Lemmy are sent using HTTP and have a failure retry:

It is possible that delivery fails because the target instance is temporarily unreachable. In this case the task is scheduled for retry after a certain waiting time. For each task delivery is retried up to 3 times after the initial attempt. The retry intervals are as follows:

one minute, in case of service restart
one hour, in case of instance maintenance
2.5 days, in case of major incident with rebuild from backup

In the case of votes, the activity is a “like” - some other federated applications understand this and will accept it, but others won’t. For example, peertube does not have a like activity, and I don’t believe they would handle it.

However votes are shared across instances. When a user “likes” something from another instance, Lemmy will notify that actor (the page) that the activity (a like) was emitted by another actor (you).

Hope that clarifies things. I’m still learning all this myself so if anyone can contribute or improve my answer, please do!

Doesn’t really make sense, if they’re federated then you wouldn’t need to pay them to access their content. If they’re not federated then what are you paying for?

I find most criticisms of OO to be disingenuous - this one in particular is a very simple situation that you reduce the line count by like 5 lines. I’m more interested in seeing cases where you can take a complex state management system and convert it to a functional paradigm that improves the readability and comprehension. Like rewrite the discord.py client using a bag of functions technique and tell me it’s just as readable.

edit: and I should say, I’m not necessary against what you say, but it’s not fair to do simple conversions and say “it’s better!” Maybe it is better but the proof is not in a 15 line example, imo