Unfortunately, I don't think I have any use for a time-boxing app. Nice work though.
Is there a reason you went with localStorage rather than indexedDB?
One useful thing is supporting 3rd party sync services. One of the apps I built allowed syncing data across devices via Dropbox. I never got Google Drive working, though, their API was horrible to work with in comparison. Is sync support something you've considered?
Even desktop environment is not solved. I'm typing this from a relatively new metod of displaying windows - a scrolling window manager (e.g. Karousel [1] for KDE). It just piles new windows to the right and it infinitely scrolls horizontally. This seems like a minor feature but changes how you use the desktop entirely and required a lot of new features at operating system level to enable this. I wouldn't go back to a desktop without this.
The immutable systems like NixOS [2] have been an absolute game changer as well. Some parts are harder but having an ability to always roll back and the safety of immutability really make your professional environment so much easier to maintain and understand. No more secrets, not more "I set something for one project at system level and now years later I forgot and now something doesn't work".
I've been on linux desktop exclusively for almost 15 years now and it has never been as much fun as it is today!
I've long wanted a scrollable/zoomable desktop, with a minimap that shows the overall layout. Think the UI of an RTS game, where instead of units you move around and resize windows. This seems like something in that direction, at least.
How does Karousel work with full screen applications, e.g., games?
set_href('/foo');
let future = doSomethingElse()
block_on(future)
if (some_condition) {
set_href('/bar');
}
This code makes the bug clearer. doSomethingElse is effectively allowing the page to exit. this would be no different in many apps, even in rust.The browser does not start a process when you set `window.location.href`. It starts a process after your code exits and lets the event loop run other tasks. The `await` in the example code is what allow other tasks to run, including the task to load a new page, (or quit an app, etc..) That task that was added when you set `window.location.href`
If that's not clear
// task 1
window.location.href = '/foo' // task2 (queues task2 to load the page)
let content = await response.json(); // adds task3 to load json
// which will add task4
// to continue when finished
// task4
if (content.onboardingDone) {
window.location.href = "/dashboard";
} else {
window.location.href = "/onboarding";
}
task2 runs after task1. task1 exits at the `await`. task2, clears out all the tasks. task3 and task4 never run.The the author expects the side-effect -- navigation to a new page -- of the window.location.href setter to abort the code running below it. This obviously won't happen because there is no return in the first if-statement.
Neither Ukraine nor Israel is part of EU or NATO.
Ukraine is most definitely a part of Europe.
When were UK citizens polled on these policies before politicians started enforcing them? And I think after Brexit, the UK government learned never to ask the opinions of their citizens again, because they will vote in direct opposition of the political status quo out of sheer spite of their politicians.
There are huge flaws with our current democratic systems: like sure we can vote, but after the people we vote for get into power, we have no control over what they do until next election cycle. So you can be a democracy on paper while your government is doing things you don't approve of.
Most people I talk to in the west, both here in Europe and in North America, don't seem to approve of what their government is doing on important topics, and at the same time they feel hopeless in being able to change that because either the issues are never on the table, or if they are, the politicians do a 180 once they get voted to power or forget about them because political promises are worthless and non-binding, meaning they lied themselves into power.
So given these issues ask yourself, is that really a true democracy, or just an illusion of choice of direction while you're actually riding a trolly track?
Why is this allowed? Why aren't there laws in place to hold politicians accountable for the promises they make to get elected?
Yeah, and I don't buy that for a microsecond.
A leading dot is not "strange" syntax: it mirrors relative imports. There's no workaround because it lets you use variables the same way you use them in any other part of the language. Having to distort your program by adding namespaces that exist only to work around an artificial pattern matching limitation is a bug, not a feature.
Also, it takes a lot of chutzpah for this PEP author to call a leading dot strange when his match/case introduces something that looks lexically like constructor invocation but is anything but.
The "as" thing works with primitive too, so why do we need int(m)? Either get rid of the syntax or make it general. Don't hard-code support for half a dozen stdlib types for some reason and make it impossible for user code to do the equivalent.
The Python pattern matching API is full of most stdlib antipatterns:
* It's irregular: matching prohibits things that the shape of the feature would suggest are possible because the PEP authors couldn't personally see a specific use case for those things. (What's the deal with prohibiting multiple _ but allowing as many __ as you want?)
* It privileges stdlib, as I mentioned above. Language features should not grant the standard library powers it doesn't extend to user code.
* The syntax feels bolted on. I get trying to reduce parser complexity and tool breakage by making pattern matching look like object construction, but it isn't, and the false cognate thing confuses every single person who tries to read a Python program. They could have used := or some other new syntax, but didn't, probably because of the need to build "consensus"
* The whole damn thing should have been an expression, like the if/then/else ternary, not a statement useless outside many lexical contexts in which one might want to make a decision. Why is it a statement? Probably because the PEP author didn't _personally_ have a need to pattern match in expression context.
And look: you can justify any of these technical decisions. You can a way to justify anything you might want to do. The end result, however, is a language facility that feels more cumbersome than it should and is applicable to fewer places than one might think.
Here's how to do it right: https://www.gnu.org/software/emacs/manual/html_node/elisp/pc...
> If needed, the leading-dot rule (or a similar variant) could be added back later with no backward-compatibility issues.
So what, after another decade of debate, consensus, and compromise, we'll end up with a .-prefix-rule but one that works only if the character after the dot is a lowercase letter that isn't a vowel.
PEP: "We decided not to do this because inspection of real-life potential use cases showed that in vast majority of cases destructuring is related to an if condition. Also many of those are grouped in a series of exclusive choices."
I find this philosophical stance off-putting. It's a good thing when users find ways to use your tools in ways you didn't imagine.
PEP: In most other languages pattern matching is represented by an expression, not statement. But making it an expression would be inconsistent with other syntactic choices in Python. All decision making logic is expressed almost exclusively in statements, so we decided to not deviate from this.
We've had conditional expressions for a long time.
After starting my new job and coming back to Python after many years I was happy to see that they had added `match` to the language. Then I was immediately disappointed as soon as I started using it as I ran into its weird limitations and quirks.
Why did they design it so poorly? The language would be better off without it in its current hamstrung form, as it only adds to the already complex syntax of the language.
> PEP: In most other languages pattern matching is represented by an expression, not statement. But making it an expression would be inconsistent with other syntactic choices in Python. All decision making logic is expressed almost exclusively in statements, so we decided to not deviate from this.
> We've had conditional expressions for a long time.
Also, maybe most other languages represent it as an expression because it's the sane thing to do? Python doing its own thing here isn't the win they think it is.
The support in this space from Valve has been amazing, I can almost forgive them for not releasing Half Life 3. Almost.