jonesetc

Did fixing it from the inside work for any of those other issues?

No, it never does. Those people somehow delude themselves into thinking it might, but...it might just work for us.

The $9 toll made it worth your money to Uber instead? Seems like your suburb isn't very far. Maybe a train could help you out.

Guitar, make it sound more like someone else's hard work.

This is a very rich man, he is not being forced to do anything. What he does is what he believes and you don't need to spend time coming up with a complex explanation past that. He needs no one's charity.

It's not a python the language feature, it's for packaging. So no language version is relevant. It's just there for any tool that wants to use it. uv, an IDE, or anything else that manages virtual environments would be the ones who implement it independent of python versions.

Lorelei and the Laser eyes was one of my favorite games that I played this past year. I think it might be good for a non-gamer, but they had better absolutely love puzzles. Also some of the puzzles require playing videogames within the main game and I can't remember exactly, but they may not make much sense or be very fun if you don't have experience with like PS1 era horror games.

For The Witness, I would recommend tagging it as appropriately not accessible. There is a section that can't be completed at all without hearing, and large chunks of the game that I can't imagine are possible with color blindness. I don't have either of these issues, but running into those things really rubbed me the wrong way. It is a game that seems to value the creators vision above all else and isn't willing to make any sacrifices for the audience.

Edit: I realize I misread and thought you were saying you were going to add The Witness to the non-gamer list, which was why I was saying that a disclaimer would be extra useful. Left it anyway.

A lot of great stuff on there. Random game from last year that feels like it would fit well is Chants of Sennaar. Played though it with my non-gaming partner and we had a blast.

The biggest thing that wouldn't be available in Python would be the DSLs. Often they are not my favorite and overused, but they can be very expressive for things like their charting example https://kotlinlang.org/docs/data-analysis-overview.html#kand...

They clearly already had the features mostly done when they made the survey. I recall the questions being extremely leading to get people to say they would like to use a privacy first AI or whatever. After I took it I immediately told people it was clear they were about to announce some AI bloat.

The database of licenses is public through the the ULS [0], and ae7q [1] has a bunch of archives and information about how to use that and provides tools itself that I used when finding a vanity.

-K5ETC

[0] https://www.fcc.gov/wireless/universal-licensing-system

[1] https://www.ae7q.com/query/stat/DataBase.php?SCHEMA=Lic

My first thought is a java package or mobile app id that you don't want to tie to some real web resource.

The new thing is the specific CPU announcement. I'm pretty sure preorders have stayed open since the initial announcement a few weeks back.

Not sure if any of the existing ones matches what you're looking for, but my understanding is that they offer just what you're looking for: https://frame.work/marketplace/keyboards

Short answer: everything is encrypted. So they could forward it in theory, but it would be unusable downstream anyway. The way you'd have to do it is set up the decryption email bridge on a client and set up some manual forwarding after that on the client side.

Happy proton user that doesn't need this feature, but gets why it would be frustrating for others who want a clean way to move off if they decide to.

I believe this was docker's (the company) direction for a while, but it was spread across multiple tools. docker-machine does provisioning and docker-swarm runs the compose file on remote hosts.

You would still store both future times with offset. When calculating an offset for a future time you take the future time and the zone together to determine the exact time with offset. DST is predictable.

I was trying to step into the shoes of a less generous reader there, sorry if that wasn't clear. I think the post was clear and I agree. Mozilla is still a massive steward and this post was made to directly address that.

I'd wait a bit and see if this sentiment is common before worrying about it. I found the message clear and believe most others will as well.

While I don't share the sentiment of the OP, I would guess lines like this may be the key for them:

Mozilla and the Rust Core Team are happy to announce plans to create a Rust foundation. Our goal is to have the first iteration of the foundation up and running by the end of the year.

I read this as "Mozilla is currently still largely in control. This is the moment where they will cede to the new, more independent, foundation." But the fact that it follows "Mozilla and the Rust Core Team" with "our" may taint the rest of the use of "our" throughout the post for others.

probably just meant message queues in general.

I think that it's unfortunate they stuck with that example instead of the classic point class example for positional args. In general the positional destructuring is not great, but there are some cases where it is nice and readable. Because of that I'm glad it's not the default that all record classes get it.

    var (f, l) = person;

    var (x, y) = point;

It was broadcast on ABC nation wide instead of the typical contracted station for any given local market, right? Normally the tournaments are broadcast during normal time slots on the usual market station. Definitely makes sense that the mouse would have insisted on a bit of extra coverage for something I bet they paid a lot for, but I would be hesitant to give that much weight for determining the direction of the standard show.

The big thing I always see is that it has a few important limitations, and those limitations mean that extra optimizations can be used.

https://stackoverflow.com/a/146186

the internet archive has lots of dos games available to play in a ready to go emulator: https://archive.org/details/msdos_Leisure_Suit_Larry_1_-_Lan...

probably a bit of loose wording there. It's probably not what either of us would call objectively rare, but it is comparatively rare compared to many other runtimes. There's quite amount of this that can be avoided with some vertical or horizontal scaling depending on what you are doing with these events.

For instance you linked the spring application events integration with redis, while that is definitely an option it's not one you'd immediately reach for. Instead you'd more likely set up and use application events and/or domain events (if using spring data) handled locally with thread pool. The benefit here is that of course way less set up and complexity, but you can also handle these events sync or async.

I'm not preaching the elixir word here either. I've never used it for anything real and just dabbled a bit as a toy. I'm just trying to help get this conversation going because I'm also interested. My experience is in java, node, and python primarily which covers a good bit of ground as far as the different concurrency approaches.

Anyhow, your characterization there I don't think is quite right. For one Java does not typically use a background job set up, because it is a first-class multithreaded runtime so it seems more likely prepared to use a threadpool for some concurrent processing before it say tosses things out to a task queue. Similarly as most java web servers are on a thread pool model for concurrency as opposed to async IO, you'll also have true in request concurrency for things like making a few calls to the DB and then collecting them. This thread pool is not well abstracted typically, and the mutable object model leads you to writing classically tricky multithreaded code with data races and the like.

For something like node where you are not really likely to be using threads, you are pretty hard tied to async IO as your method of concurrency. So you have a really easy job if all you're doing is async calls to say a DB with no need for data processing. Here once you need real computation you will have essentially no option other than using a task queue.

Then when it comes to python you have essentially the worst of all worlds. it's not easy to do concurrent IO or computation without some form of background processing.

I believe that when it comes to the elixir runtime the idea is that they have removed async IO from the mix and instead put up a concurrency API that is as simple to manage as async IO in something like node. Under the covers is all delegating out simple blocking code to a thread/process pool, but the immutable data model and API makes it so that data is not shared across the pool, trying to keep the classic concurrent mistakes hard to make.

Nothing that can be done in elixir seem to be impossible or even astoundingly hard in some other technology, but the unified API for all forms of concurrency seem like a nice way to make it a runtime that can handle many different types of workloads in a simple and cohesive way. That simple way also seeming to not need you to bring in things like a redis task queue where you generally would need to use it or some other external solution.

considering their comment about it being difficult with rails, I think they are likely talking about concurrency within a single request as opposed to what I think you are talking about of concurrently handling requests.

Learning an actual machine language is definitely harder, all of these games use extremely limited instruction sets and/or simplified operating conditions.

As for more beneficial, I'm sure learning a real practical machine language is more beneficial. However you can definitely draw some of the same lessons out of these games and depending on you, might have a lot more fun and chances of actually going through with playing these games.

At my job we have what I'll call an approximation of one of these command based APIs, looks like a classic RPC API. We also have a set of internal user procedures that are basically those escape hatches you mentioned. They are the source of almost every odd and problematic behavior we encounter in our normal API.

I believe presenting slightly more open commands for internal use is the right idea, but sliding all the way to an arbitrary entity edit API is a quick way to break state expectations.

Yes this could also be solved by having perfectly crafted constraints in the business logic and/or DB, but what's more manageable? Managing a few extra specific APIs, or having every expectation perfectly defensively coded?

There was a library called the STL that is now, with modifications, a part of the std library. So in a sense you could say that the STL is a subset of the std library, or that it was an inspiration for part of it, but many people just use the terms interchangeably.

So, what that read me says is correct, it is also called the STL. If you want to be precise you should probably only call it the std library though. There are still implementations of the original STL around separate from the std library, so keeping the distinction is probably still wise.

Also to complicate things, some people use the term STL to refer to the specific parts of the std library that are from the original STL. Those pieces are containers, algorithms, functions, and iterators I think.

tl;dr it's all a mess and people say the two meaning different things all the time.