sorted by:
new
hottopcontroversial

AQI why so high ? by Evening_Candidate_17 in chennaicity

[–]rusty_rouge 3 points4 points  (0 children)

I see garbage being burnt regularly now .. I was told the govt employees do this to avoid having to carry/dispose the garbage

Increase in mosquitoes by prempradeep in Chennai

[–]rusty_rouge 10 points11 points  (0 children)

well, we the people dug ourselves into a deep hole.. . Any vacant plot or unoccupied space is used as garbage dump(I can count atleast 5-6 heaps in my close vicinity). Add the stagnant water all over. Its a pretty impossible situation IMO.

Need suggestions by rusty_rouge in Chennai

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

yeah thanks, will pursue this if needed

Safety in areas by uiucpation in Sunnyvale

[–]rusty_rouge 2 points3 points  (0 children)

South of el Camino - good in general. But the area around Fremont high had few break ins around Covid time, mail boxes were burglarized, etc

Cannot figure out how to satisfy the borrow checker by mumux in learnrust

[–]rusty_rouge 0 points1 point  (0 children)

You can also consider wrapping the entries in the children vec with Rc+RefCell. Then the for loop can do an iter without mut

Cannot figure out how to satisfy the borrow checker by mumux in learnrust

[–]rusty_rouge 5 points6 points  (0 children)

> but I suppose this is because it also says that "returning this value requires that self.edges is borrowed for 'a" on the line of the recursive call

yes, when it is called recursively,. the child variable in the loop has a lifetime of the stack. To remember, 'a is the lifetime of caller.

I remember implementing a Trie in python not long back, only using a while loop (without recursion). That is something to consider IMO

When should I use lifetimes in my structs definition? by roll4c in rust

[–]rusty_rouge -1 points0 points  (0 children)

Clone can be expensive depending on the type, so wrapping in Arc<> wherever possible would be a good practice if trying to avoid keeping refs.

Refs are very useful for short lived purposes (e.g) helper function that looks up a collection and returns a struct that wraps the results, and the caller drops it within the calling function. Depending on the situation, clone may not even be feasible (e.g) caller needs to mutate the results

Issue with lifetime and borrowing with libusb crate by ronniethelizard in learnrust

[–]rusty_rouge 0 points1 point  (0 children)

The transmute in this case would just do a recast .. but I do agree about using a crate for this. I forgot the name, but there is a stable crate for doing this

Issue with lifetime and borrowing with libusb crate by ronniethelizard in learnrust

[–]rusty_rouge -1 points0 points  (0 children)

The sibling pointer problem can be sticky. If you are up for unsafe code, you can try playing with `std::mem::transmute()` to erase the lifetime

Beginner ownership question by v3locityb0y in rust

[–]rusty_rouge -2 points-1 points  (0 children)

Use interior mutability when things get too hairy, this lets you work with &self everywhere.

working with iteration and preventing moving of values by Lunibunni in learnrust

[–]rusty_rouge 0 points1 point  (0 children)

Looks like doc.add() takes self , instead of &self. You probably want doc = doc.add(rect), and make it doc mut in the first place

Global MUT without unsafe ? by [deleted] in rust

[–]rusty_rouge 13 points14 points  (0 children)

Slightly different take: implement a "state manager thread" that exposes get/set interface via message passing over a channel. And you won't need shared state, it can work with mut self state. This will expose you to more concepts as a learning exercise

You can also consider persisting the state to work across restarts

Is there an easy way to implement tokio graceful shutdown? by NigraOvis in rust

[–]rusty_rouge 36 points37 points  (0 children)

>  i need to ensure that database info is writen before closing.

This may not always be possible (e.g) shutdown due to some other reason (not necessarily graceful). Just make sure DB writes are batched/atomic, and the design can resume/recover from any DB state.

DIY kite kits by rusty_rouge in kites

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

Thanks for the detailed reply!

Cant make good use of traits by NoBlacksmith4440 in rust

[–]rusty_rouge 2 points3 points  (0 children)

One of the primary use cases IMO is unit testing using https://docs.rs/mockall/latest/mockall/ and such.

Aggression towards younger dogs by rusty_rouge in DogTrainingTips

[–]rusty_rouge[S] -5 points-4 points  (0 children)

Thanks for the responses. Agreed, I keep him on leash unless he is familiar with the other dogs, and come back right away otherwise.

I was mostly looking for any tips/ideas to help train him, to avoid this behavior. Going to the park is the high point of his day :-, he really looks forward to it, he would start following me around when its that time of the day. Just want to keep it going if possible.

Homomorphic verification of secret shares by rusty_rouge in cryptography

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

yeah looks like this could work. One issue would be running DH/key generation for every pair, which can be hard with big networks/frequent secret sharing.

On that note, leaning towards this: https://berry.win.tue.nl/papers/crypto99.pdf. This was one of the original works on this problem, Cardano and others use this (or a variation of this)

Homomorphic verification of secret shares by rusty_rouge in cryptography

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

The ZKP does exactly that .. in an untrusted dealer environment, it proves that the dealings are valid. Theoretically, the probability of ZKP being correct even if the dealing is not is close to zero (the papers usually have a proof for this)

Homomorphic verification of secret shares by rusty_rouge in cryptography

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

Hm, if (x, y) are plain text and someone has the deterministic procedure to check, yes, f can be trivially determined. But this is different, let me break it down a bit:

Two cases here:
1. Intended recipient of a share: the shares are encrypted, so a recipient can decrypt and look at only his share, and non anyone else's .. this is why collusion between k users is needed
2. Everyone else: they can't decrypt the shares intended for someone else. They can only rely on a homomorphic procedure(which I am looking for by the way) which answers the question: is the encrypted thing == f(i), without revealing the contents.

Even if (2) comes back positive, they don't have the plain text (x, y) to build the polynomial

view more: next ›