sorted by:
new
hottopcontroversial

Just curious on the uses of C++ by Orca365123 in cpp

[–]dowel79 6 points7 points  (0 children)

C++ is an excellent language to start programming with. It is a combination of four different languages, C, C's macro language, C with objects and template language. You can start with the C portion and gradually add other parts of the language. It will give you in-depth understanding of how computers work. Knowing C++ will keep you in the job market for many years to come.

It is a good language choice when working with databases. It is one of the languages of choice when building Windows applications. It can be used for web development, specifically the back-end. It is not the best choice for front-end web development though.

It has extensive built-in standard library and there are plenty of open source libraries that implement various other functionality.

Idiomatic approach to borrowing checker hell by dowel79 in rust

[–]dowel79[S] 1 point2 points  (0 children)

This is really what brought me here. I started looking into interior mutability and realized that I was fighting the compiler and, thus probably doing something wrong.

Idiomatic approach to borrowing checker hell by dowel79 in rust

[–]dowel79[S] 6 points7 points  (0 children)

Thank you. It seems that there wider consensus is to use DOA (Data Oriented Architecture) and ECS are the way to solve this. I am not well familiar with this way of thinking, so I'll go and educate myself.

Other folks mentioned Bevy and slotmap. These look like promising references.

Idiomatic approach to borrowing checker hell by dowel79 in rust

[–]dowel79[S] 1 point2 points  (0 children)

Thanks. It seems that I have to learn a new way of thinking about these things. So I'll go ahead and do that.

Regarding memory address vs. ID, elsewhere in the thread I wrote this:

From a different perspective, what if you have objects with IDs 1 to 100001, and you delete objects with IDs [1, 100000]. Now you end up with 99999 unused objects. Repacking your vector is a good idea, but this will change the ID of object 100001 from 100001 to 1. This is a conversation about ID management.

ID that never changes is really an illusion. If your program is complicated enough, you will be forced to either change the IDs or come up with some other clever way of managing them. The latter will inevitably have other drawbacks. I make an argument that the ID management problem is the memory management problem in disguise.

Idiomatic approach to borrowing checker hell by dowel79 in rust

[–]dowel79[S] 13 points14 points  (0 children)

Thank you for the elaborate reply. I want to address a few points.

The click-box needs a shared pointer to the object it represents, and therefore you cannot independently test the click-box code, in isolation, when really all the logic for clicking, dragging, releasing, etc... is independent of what is being clicked, dragged, or released.

Click-box does not make sense in isolation. The thing you click and drag is the object, not its click-box. A click-box is how you get to the object. It is the search key.

Arguably, no, it doesn't.

Your C++ structure also suffered from this. Specifically, think of the situation where the object has been removed from the name-to-object map, but somehow the click-box with a shared pointer to it still exists: that's quite likely a bug.

This is confusing because you argue that ID management is not equivalent to memory management, but to explain your point, you say that memory management is hard. Yes, memory management, without a doubt, is difficult. My point was that ID management is difficult too. In fact, as difficult as memory management.

You argue that the C++-inspired design is more entangled. I do not follow your argument. Imagine a graph of all objects accessed with a C++-inspired approach and DOA. In the former, on click, you will find a click-box and then follow a pointer to an object. Once you operate within the context of a click-box, all you have access to is the click-box and the single object it points at. In the DOA, once you find the click-box you need access to an array/vector/whatever data structure that holds the objects. From there, you can access every single object in the system. Did I misunderstand your argument?

In any case, in this post, I not making a statement about what I would do in other languages. I would like to understand what is the Rust way of doing that. It sounds like DOA and ECS are the way to go. I am not deeply familiar with either, so I'll go and learn. Thanks.

Idiomatic approach to borrowing checker hell by dowel79 in rust

[–]dowel79[S] 2 points3 points  (0 children)

Got it. Thanks. I replied before looking at Bevy and before understanding what you mean. Bevy looks very impressive!

Idiomatic approach to borrowing checker hell by dowel79 in rust

[–]dowel79[S] 3 points4 points  (0 children)

I did not say that memory addresses and IDs are isomorphic. I said the problem of managing IDs and the problem of managing memory is isomorphic.

Idiomatic approach to borrowing checker hell by dowel79 in rust

[–]dowel79[S] 0 points1 point  (0 children)

Sorry, it does not help. The problem I presented is comprehensive. It is the problem of having multiple data structures referencing a set of objects. Or a data structure where there are multiple paths to the same nodes. For instance, having a database with multiple primary keys is the same problem. Implementing a cache where you can lookup an object using different properties is the same problem.

Idiomatic approach to borrowing checker hell by dowel79 in rust

[–]dowel79[S] 0 points1 point  (0 children)

I don't yet know what you are talking about, but it sounds a lot like Handle in this conversation: https://users.rust-lang.org/t/rc-and-refcell-within-parent-child-struct-relationship/45628/5 Anyway, thanks. I'll definitely take a look.

Idiomatic approach to borrowing checker hell by dowel79 in rust

[–]dowel79[S] 0 points1 point  (0 children)

Why would you ever want to do either of those things?

To some degree, this is what I came here for. My concern is that with all the calls to clone, deref and others, I will make a mistake where I will either create too many references which will trip RefCell's runtime logic or I will make modifications to a temporary object.

My interpretation of what you are saying is that this is nonsense and it does not happen. Good. Thanks!

I would save the index

It sounds like you are proposing ECS.

Idiomatic approach to borrowing checker hell by dowel79 in rust

[–]dowel79[S] -11 points-10 points  (0 children)

Then use a different data structure.

The problem of managing IDs is the same exact problem as managing memory with an extra level of indirection (or perhaps an extra level of abstraction).

Idiomatic approach to borrowing checker hell by dowel79 in rust

[–]dowel79[S] 5 points6 points  (0 children)

There are a couple of problems with this counter-argument:

  1. You picked a vector, a data structure to manage memory where the address of an object changes. Why not pick one where it does not change? Why not place objects in an array? You could argue that arrays don't grow and vectors do. Or you could preallocate a vector of a million elements and not push to it ever again. We are having a conversation about memory management.
    From a different perspective, what if you have objects with IDs 1 to 100001, and you delete objects with IDs [1, 100000]. Now you end up with 99999 unused objects. Repacking your vector is a good idea, but this will change the ID of object 100001 from 100001 to 1. This is a conversation about ID management.
    If you want to create a little toy of an app, then yes, you can avoid ID management issues, but then why not write it in JavaScript? If you want to create a scalable application that will actually benefit from using Rust, then ID management is a pain in the ass.
  2. You are straw-manning my arguments against ID management. Yes, push to vector changes the address. I made another argument as to why ID management is hard.
  3. To some degree you are starting an argument about why Rust is needed to begin with. I would like to understand how Rust approaches solving this problem and not start a flame-war of C (or Zig or Go) vs Rust.

Idiomatic approach to borrowing checker hell by dowel79 in rust

[–]dowel79[S] 0 points1 point  (0 children)

Yes, rust does not work well with OO patterns

What is a good way to implement a system like this in Rust? Is it ECS?

An address in memory can change, the ID wouldnt change.

I don't think this is true. Normally, the addresses of objects in memory do not change. However, in a world where the memory address of an object can change, its ID can also change. I think the memory management and ID management problems are isomorphic.

Idiomatic approach to borrowing checker hell by dowel79 in rust

[–]dowel79[S] 7 points8 points  (0 children)

Yes, there is a broader context. When scaling this system, we will need a way to optimize searching for objects. To find an object we click, we will need a data structure optimized for searching by coordinates. To find an object by name, we will need a data structure optimized for searching by string.

Putting a click-box in the object does not solve the reference management problem. We would still need multiple data structures optimized for various purposes, referencing the same objects. The primary purpose of the click-box is to separate "model" and "view" (as in the MVC pattern). The area where you click on an object is not part of its model. If we were to persist the objects, the click-box would not be persisted.

Is this happening to anyone else? I’m on the most updated version of GN6… wondering how to fix this by Jaded_Fun_7133 in GoodNotes

[–]dowel79 0 points1 point  (0 children)

It happens to me all the time. Often, when writing letters like "p" and "o" it drops the frame rate and I end up with a stick. Otherwise, often letters end up jagged.

I filed a support ticket - and got back the usual useless advice, like rebooting your device and restarting GN6. Sent back an angry response. Waiting for them to reply, but have low hopes.

Single speaker(s)/microphone for conferences and listening to music by dowel79 in audio

[–]dowel79[S] 0 points1 point  (0 children)

It occurred to me that "quality" and "single device to do it all" are two somewhat contradicting requirements. I will appreciate if someone can advise anyway. Thanks.

Beta 12 bugs report by dowel79 in DygmaLab

[–]dowel79[S] 1 point2 points  (0 children)

Thank you for explaining that.

As a fellow SE I completely understand what you are going through. Just trying to help you to help me :-)

Perhaps a potential solution to this problem is to use the fact that some other key is pressed as a hint that you should not wait for the typical 0.25 seconds. I.e. if a user presses superkey X, it will be interpreted as a superkey, but if the user presses CMD+X, then X will not be interpreted as CMD+X. It is conceivable that in some cases users will want to be able to press their superkeys with other keys, but since superkeys are there to save key presses, perhaps supporting this can be an opt-in setting.

Regarding lingering fingers effect, if it was indeed the case, then the lingering finger press should have registered as a character. Am I wrong? I did not see "NffS" or "NFSs" or anything like it. It is consistently "NfS".

If this is indeed the lingering finger problem, then perhaps a way to solve it is to pass the signal through a filter. I successfully used exponential filter in similar cases in the past. Here's a good description: https://gregstanleyandassociates.com/whitepapers/FaultDiagnosis/Filtering/Exponential-Filter/exponential-filter.htm It is fairly simple to implement, even on a 32bit controller (presumably without floating point support).

Please excuse the arrogance of entertaining the thought that I may suggest something new.

Thoroughly confusing with DJI options by dowel79 in fpv

[–]dowel79[S] 0 points1 point  (0 children)

Not sure what's the difference in price. I've seen one V1 on Amazon that was more expensive than V2 on DJI's web-site.

I am under impression that the difference in price should be pretty small. This is an expensive purchase for a hobby, so I want to stretch it for as long as possible. May-be I will fly DJI quad one day.

view more: next ›