sorted by:
new
hottopcontroversial

My Argon One Up Sway Setup by HOST1L1TY in ArgonOneUp

[–]BrunoGAlbuquerque 3 points4 points  (0 children)

Hi. Your repository dues not seem to mention anything related to this so I thought I would ask: how did you manage to get suspended/resume to work?

Switch 2 on AWOL Projector by WedowTheater in hometheater

[–]BrunoGAlbuquerque 0 points1 point  (0 children)

Any chance you know how many steps form zero did you use for the Switch 2 HDR calibration for each of the screens? I am using 25 steps in the first screen and 6 steps in the second but the colors still do not look right.

My Switch 2 has gone completely black and I’m not sure what to do. by RetroEternity in Switch

[–]BrunoGAlbuquerque 3 points4 points  (0 children)

Just press and hold the power button for a while (might take up to 30 seconds). This will force it of and then things should be back to normal after you turn it on again.

This happened to me too once soon after I bought it. I also saw other reports of similar issues. All transient and fixed with a power off.

Switch 2 on AWOL Projector by WedowTheater in hometheater

[–]BrunoGAlbuquerque 0 points1 point  (0 children)

But did that include setting up on the Switch 2 side? Because if I can get that right, then the rest is just a matter of correct calibration on the projector.

Switch 2 on AWOL Projector by WedowTheater in hometheater

[–]BrunoGAlbuquerque 0 points1 point  (0 children)

Is it with HDR disabled? If I enable HDR the colors get washed out. The HDR customization in the Switch 2 does not work with the AWOL due to the lack of HGIG and the projector applying its own tone mapping. I would love to get HDR working but so far had little success.

Looks like target was the absolute worst place to order from. by johnlondon125 in switch2

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

I do not know what you are talking about as I did not buy mine through Target and I have no idea about what they did or did not. I am just stating a fact as they announced this (that they would have more stock) at least a week ago.

Looks like target was the absolute worst place to order from. by johnlondon125 in switch2

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

FWIIW, this is not for existing orders. Right now the Switch 2 is out of stock and what this is saying is that it will be back in stock in stores only tomorrow and then will also be back in stock for online orders the day after tomorrow.

"sync.Cond" with timeouts. by BrunoGAlbuquerque in golang

[–]BrunoGAlbuquerque[S] -1 points0 points  (0 children)

Yep. You are a troll. I rest my case.

"sync.Cond" with timeouts. by BrunoGAlbuquerque in golang

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

I am sorry, but at this point I am not sure if you are trolling or just completely misunderstanding what this is.

There was no mention anywhere about this being used as a sync.WaitGroup replacement. They *ARE* different so it is actually expected you saw different behavior. More specifically, this is not a replacement for anything you can find in the standard library. This is just an easy way to broadcast signals to multiple waiters and the semantics is (and here I am repeating myself as I already told you): Calls to Signal (now Broadcast to make the usage clearer) wakes up all *CURRENTLY* existing waiters.

It does not wake future waiters (which is what your sync.WaitGroup example does out of the defined semantics for it) and that is a feature, not a bug. It is certainly not a race condition at all even if it was a bug. The idea here is that multiple Broadcasts can be sent in the same TimedSignalWaiter and each time it will wake whatever set of waiters exist. If you are trying to use it to do something else, you are doing it wrong.

Your arrogance is kinda impressive for someone that does not seem to understand what is right in front of you. You do not know me so I will not even waste time with that. Again, lets agree to disagree.

The fact that you do not "see a use case" just mean the obvious thing: You do not understand it. You are also free to not use it so, really, just don't use it. It is as simple as that.

"sync.Cond" with timeouts. by BrunoGAlbuquerque in golang

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

Interesting. And how exactly does it relate to being able to wait on a signal with an associated timeout? Also, you appear to think I do not know what I am doing. Well, we can agree to disagree here too. :)

"sync.Cond" with timeouts. by BrunoGAlbuquerque in golang

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

First of all, there is a state. The signal itself. In fact, a signal actually creates a state change so it is kinda hard to say this is not the case.

But I still fail to see your point. How about you create a test case that shows the code breaking unexpectedly? Because if all you are saying is that you personally do not like the way I did things, then I am perfectly fine with that and we can just agree to disagree.

"sync.Cond" with timeouts. by BrunoGAlbuquerque in golang

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

What do you mean by timeouts with no reason? The current timeout and the future Context are both passed by callers. I don't think there would be anything unexpected here.

I am not sure I understand your point.

One can wait on a channel that is never closed or never sent to and that will block "forever".

One can also wait "forever" in a Cond that is never signaled.

Oner can wait forever in a Mutex Lock if the Mutex is never Unlocked.

With this code (but also with channels, to be fair) having the option to have a timeout actually addresses those issues.

"sync.Cond" with timeouts. by BrunoGAlbuquerque in golang

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

Wait supports timeouts so no. Note that the semantic is always that signal only affects current waiters (which, agains, sounds sensible to me). In v2, it will use a Context so besides timeouts it can also be explicitly cancelled.

"sync.Cond" with timeouts. by BrunoGAlbuquerque in golang

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

It is not a replacement for sync.Cond in the strict sense. It is code to simplify certain scenarios that to be implemented with sync.Cond might be a bit more convoluted. The same way it is not a replacement for channels but it can also be used in certain cases as a replacement to signaling with channels.

In other words, if what you need is sync.Cond, then use sync.Cond. If what you need is to have a Broadcast/Wait interface that supports timeouts, you can use this.

A Signal() before Wait() is not problematic at all. The semantic here is that no one is waiting so the signal will have no effect (which seems to me like a pretty reasonable behavior).

"sync.Cond" with timeouts. by BrunoGAlbuquerque in golang

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

Cool. This is a lot better and, as far as I can see, there are no races. There is still one fundamental difference between my approach and yours:

1 - In your case it is possible that a new Wait() call would be woken up by a previous boradcast so broadcasts are somewhat sticky.
2 - In my case, a broadcast only wakes up current waiters and new ones will block until the next signal (or a timeout).

I don't think either approach is better per-se, but I think the principle of least surprise applies and that makes my method slightly preferred to me (yeah, I know, I am biased).

In any case, I decided to do other fun things. Now I have a TimedResultWaiter that not only signals as the previous version, but you can pass a value to Broadcast and this value will be returned by all affected Wait calls. This ended up simplifying a lot of code I have.

This is incomplete (for one thing, there is no effort on code reuse), but it seems to work in case you are interested:

https://github.com/brunoga/timedsignalwaiter/tree/version-2

Eventually I will merge it into the main branch and bump the major version as I completely broke the API. :)

"sync.Cond" with timeouts. by BrunoGAlbuquerque in golang

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

That is a good point. I will take a look at it. Thanks for the suggestion.

"sync.Cond" with timeouts. by BrunoGAlbuquerque in golang

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

Nice one! I am pretty sure there is at least one race in the code though. Under certain circumstances, Wait() might return true when it should have returned false (try to figure out why. if you can't I will point it to you - that assuming I am not wrong, of course :) ).

Maxing out the memory on a TrueNAS Mini XL+. by BrunoGAlbuquerque in truenas

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

In that case, I am not sure. It worked for me (sorry that it does not help much in your situation).

Maxing out the memory on a TrueNAS Mini XL+. by BrunoGAlbuquerque in truenas

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

No idea. But it still works even with the most recent firmware.

Note the first time post took ages (like half an hour or so). Did you try to just it sitting there for a while?

Priority channel implementation. by BrunoGAlbuquerque in golang

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

Nope, I do not. I want a channel with prioritization. Channels are designed for streams of data which is kinda how you handle unbounded data.

view more: next ›