The hardest part is getting away without using google services. Tons of apps depend on it especially google maps. There are ways around this, but they don't always work.
Let me start by noticing, I am not interested in playing a game of Tic Tac Toe, nor programming any form of "AI". With that out of the way, let me give some background:
I have found Rust, with its ownership model, frequently nudges me to rethink whatever I am building. Usually it involves fixing some structs / enums, to avoid references. Correctly structuring an object can make me avoid lots of headaches later when I actually add functionality.
One thing I noticed that helps is understanding what kind of properties should the data have? Should it maintain a certain order, or can it be unordered? Are all of the values unique, or can it have duplicates? All of these details are very important. It is wrong to just shove everything into a Vec. A Vec implies ordering and duplicates, which could be a bad model. We need to choose something which most closely represents the data.
Ok, enough lecture. Onto the Tic Tac Toe grid. Observing this grid provides me with a few important properties:
A Tic Tac Toe grid can be rotated clockwise or counterclockwise, and the game is still the same. The grid can also be flipped over horizontally or vertically and the game will be the same. To decide if anyone won, we just need to see if any rows have 3 of the same value. The rest of the grid does not matter.
I am trying to figure out the best memory model would best represent this behavior. How to build a grid whose orientation does not matter?
Ideally, all of these values should be represented in memory exactly the same way:
X|O| X| | | | |O| = O|O| = O|O| | | | | X| |
But how to do this? One way I was thinking, is perhaps instead of saving a grid at all, we should just be keeping track of all of the rows.
- [X, O, E] (E = Empty)
- [O, O, E]
- etc for all the other rows..
However there are several problems with this model:
- The same cells are owned by multiple rows. This is not good. Perhaps the rows can hold a reference to the cells?
- The ordering of each row should not matter. So this shouldn't be an array. A better representation may be a Set or Bag/Multiset.
#1 continues to bug me. If we have rows holding references to all of the cells, then it will be hard to update any of them because of rust's restrictions on multiple mutable borrows. Or am I wrong here? How can I update a cell using a reference from a row? Where would the cell live anyway?
It doesn't seem to help to declare the rows inside of the cells, because that leads to cyclical references.
I continue to mull over this problem with not much success. I hope someone can help me discover a better path forward.
OMG, thank you! I have been using Iced. My simple application's RAM just went down from 80 MB to only 4 MB.
The executable size went down from about 8 MB to 2.5 MB
For some reason, it seems popular for GUI crates to use the GPU. I just want to make simple widgets, for like a calculator.
No fancy graphics. I want it quite lightweight.
For some reason, popular GUI crates love to do everything through a GPU, which bumps up the memory / cpu use significantly.
mmstick, it is always good to hear from you. You frequently provide a huge depth of knowledge in your comments.
I come from a windows background. If I want to make a memory efficient GUI, I always used native windows GUI libraries. All other frameworks have always seemed like they took up much more memory and CPU. This always annoyed me.
My little Minesweeper game is taking 78 MB of memory (with --release).
At the same time, Excel is only 2.5 MB, Notepad++ is only 1.9 MB.
Recently I found out that a lot of memory and CPU is used up simply to communicate with the GPU. I am confused about this.. Does Excel not use the GPU?
I am sorry, I feel like I am starting to rant here. This memory issue has been annoying me for a while, and I have not heard anyone provide a clear reason why these complicated apps seems to take up much less memory than any simple cross-compatible app I build.
Indeed, a lacking multiline text is what stopped me from trying to use it as well. But with the minesweeper example, I thought "it's just a bunch of buttons, surely this is simple enough for me to build?"
But no, the button widget doesn't support right clicks or double clicks, which limits the functionality I can build into minesweeper.
Overall, I love how simple Iced code ends up being, which makes me think about contributing to this project. Only issue I have with it is this seeming inefficiency.
I just attempted to write up a simple Minesweeper game with Iced. No bells or whistles, but it works:
https://github.com/veniamin-ilmer/minesweeper
On one hand, I find it pretty cool I built a clear cross platform GUI with actual functionality, within only 200 lines of code.
On the other hand, I can't help but see how inefficient it seems. If I ever need to modify any of the objects, I need to redraw all of them. The structure of the view
method makes me think it is very difficult for Iced to maintain a "virtual DOM" to only make delta changes.
Am I wrong? Is there a more efficient way to do this in Iced?
Edit: I just found this - https://github.com/iced-rs/iced/pull/1284
> As the library matures, the need for some kind of persistent widget data (see #553) between view calls becomes more apparent (e.g. incremental rendering, animations, accessibility, etc.).
> If we are going to end up having persistent widget data anyways... There is no reason to have impure, stateful widgets anymore!
So it seems like Iced plans to have an internal "persistent widget storage", which in abstracted away from the user. But it is quite unclear to me how they would accomplish this, considering the view
method doesn't provide an ID for any of its objects, so it would not be easy for Iced to determine the difference between updates.
I like this response. Indeed, if we don't have strong expectations from the devs to finish by a certain time, then we shouldn't have such expectations on QA.
The weird part is that whatever they think of dictators, they would know the model, and that gives me a bizarre amount of trust.
Can you explain this more?
I am happy there is no obvious "any" type in Rust.
It's not like they are programming communism into Lemmy.
I can't wait for the release. I wish I knew when it will be. That is when I plan to switch away from Windows.
It sprays into the toilet
I recently decided to think of an algorithm based on natural selection of DNA mutations. Being unclear about its speed complexity, I decided to write it up and test it out. The result was counter intuitive.
First, a simpler variant: Imagine the following sorting algorithm, given an array of numbers: Randomly shuffle the numbers until they are sorted.
What is the median amount of times you end up shuffling the array before it is sorted?
The answer is n! where n is length of the array. This is known as Bogosort.
Now, a slightly more advanced version:
Assume you can tell which numbers are already in their correctly sorted position, and which aren't. Only randomly shuffle the numbers which are not yet sorted. Keep all the others in place.
What is the median amount of times you end up doing this kind of shuffling before the whole array is sorted?
I'll be revealing the answer tomorrow.
Edit: The answer is that you end up shuffling only n times.
Addressing some concerns: this is not a real sorting algorithm, because it assumes you already know whether some of the records are sorted or not.
It shows me how "random chance" in DNA mutations can actually occur much faster than we expect. When a better gene allows an organism to survive better, it sticks around, while all of the other useless genes randomly shuffle around until they can become more useful too. This way organisms with a long DNA code can still evolve rather quickly even if it's by random chance.
Not only will a bidet save you on toilet paper, but you will actually feel like you have a clean butt after pooping. Initially it feels weird, but after you get used to it, you won't want to poop without it.
BTW in case you are wondering: yes, you still need toilet paper to wipe the water off. But it is a small amount.
It would be great if someone could build a Lemmy bot to do this for videos.
So which of these is the "sad truth" the title seemed to allude to?
Content producers try to make longer videos to maximize their ad revenue
That's interesting, where do you live?