|
Hammerite posted:Despite working with async code in the past, I often find it difficult to wrap my head around it and I'm sure others do too. Could you help spread the knowledge by explaining why this code fails to do what the author intended it to do, and how you would go about fixing it (if you had to content yourself with just putting a bandaid on it?) As the comment implies, the method is supposed to delay disposal until the background stuff is finished, with a maximum wait of 10 seconds, checking every 1 second. There are many ways to achieve this, with plenty that could be described as horrible and plenty that would be fine. But his code doesn't even achieve the stated goal - Task.Run just fires off an async task, it doesn't wait for it to finish, so that code will just flow on straight out of the DoDispose method, return to the Dispose method, and then flow on out of that, meaning the disposal has not been deferred at all. It's not clear from the code, admittedly, but the Entity Framework context is involved here and is being disposed while still in use because of this code. The lifetime of the context is tied to the lifetime of the class that owns this code. (The real coding horror to be honest is how overly complex this code is for what its doing, but I can't post the whole source code here). putin is a cunt fucked around with this message at 01:24 on Jan 22, 2020 |
#
?
Jan 22, 2020 01:22
|
|
|
|
| # ? May 17, 2024 00:29 |
|
|
a hot gujju bhabhi posted:As the comment implies, the method is supposed to delay disposal until the background stuff is finished, with a maximum wait of 10 seconds, checking every 1 second. There are many ways to achieve this, with plenty that could be described as horrible and plenty that would be fine. But his code doesn't even achieve the stated goal - Task.Run just fires off an async task, it doesn't wait for it to finish, so that code will just flow on straight out of the DoDispose method, return to the Dispose method, and then flow on out of that, meaning the disposal has not been deferred at all. It looks like they thought async would create some sort of yielding coroutine, to return to some other context while waiting
|
|
#
?
Jan 22, 2020 01:55
|
|
|
Kilson posted:It looks like they thought async would create some sort of yielding coroutine, to return to some other context while waiting That's what I think too. They've done it in a few other places as well that I've had to fix, but this one was in a very critical part of the code.
|
|
#
?
Jan 22, 2020 02:20
|
|
|
Volmarias posted:I'm not a c# dev, but seems like If #3 is expected behavior then the developer also misunderstood the IDisposable API, as it's explicitly a synchronous interface and everything must be cleaned up before returning from the Dispose() method. There's a slightly different IAsyncDisposable interface for async cleanup.
|
|
#
?
Jan 22, 2020 07:41
|
|
|
a hot gujju bhabhi posted:As the comment implies, the method is supposed to delay disposal until the background stuff is finished, with a maximum wait of 10 seconds, checking every 1 second. There are many ways to achieve this, with plenty that could be described as horrible and plenty that would be fine. But his code doesn't even achieve the stated goal - Task.Run just fires off an async task, it doesn't wait for it to finish, so that code will just flow on straight out of the DoDispose method, return to the Dispose method, and then flow on out of that, meaning the disposal has not been deferred at all. I must be misreading something. How can flow go from running Task.Run to going "out" into running Scope.Dispose, when one is in an if and the other is in an else, and the only recursion occurs from the if block? When I first read it, the horror I saw was that it should only need to spawn the one thread which could just be iterative. And from what Plorkyeran said, it should implement IAsyncDisposable and have the method be DisposeAsync. Is it supposed to Dispose when 10 seconds have elapsed regardless of the refresh's progress? If not, then I think Volmarias nailed it especially with the if at the end. Ruzihm fucked around with this message at 16:04 on Jan 22, 2020 |
|
#
?
Jan 22, 2020 15:55
|
|
|
Ruzihm posted:I must be misreading something. How can flow go from running Task.Run to going "out" into running Scope.Dispose, when one is in an if and the other is in an else, and the only recursion occurs from the if block? I think the problem is that the code that calls dispose doesn’t know to wait for the task to complete. Once dispose is called the runtime is free to garbage collect the object as well as anything it references. So you end up with a race condition.
|
|
#
?
Jan 22, 2020 18:13
|
|
|
Jen heir rick posted:I think the problem is that the code that calls dispose doesn’t know to wait for the task to complete. Once dispose is called the runtime is free to garbage collect the object as well as anything it references. So you end up with a race condition. Ooh, ok. Gotcha.
|
|
#
?
Jan 22, 2020 19:10
|
|
|
Volmarias posted:- CacheService should have an async function that completes when the background refresh is no longer in progress That's how it's implemented internally - that bool property is just an accessor that checks the IsCompleted flag on a private Task inside the CacheService.
|
|
#
?
Jan 22, 2020 22:06
|
|
|
Jen heir rick posted:I think the problem is that the code that calls dispose doesn’t know to wait for the task to complete. Once dispose is called the runtime is free to garbage collect the object as well as anything it references. So you end up with a race condition. This was my interpretation - but some of the replies in the .NET thread are making me think I might actually be the coding horror 
|
|
#
?
Jan 22, 2020 22:07
|
|
|
Would this qualify as a horror? I was looking at a company's careers page and noticed an ad for a front-end developer. The main language requirement was C++ which seemed strange. Investigating further, it looks like their entire front-end is built in JUCE. Given my (very limited) exposure to C++, trying to write a front-end in C++ sounds like all kinds of horrible unpleasantness.
|
|
#
?
Jan 22, 2020 22:29
|
|
|
The Dark Wind posted:Would this qualify as a horror? I was looking at a company's careers page and noticed an ad for a front-end developer. The main language requirement was C++ which seemed strange. Investigating further, it looks like their entire front-end is built in JUCE. Given my (very limited) exposure to C++, trying to write a front-end in C++ sounds like all kinds of horrible unpleasantness. Why do you think that? C++ would provide a native, efficient desktop application (coding horrors notwithstanding). In what language/platform do you think a front-end should be written in?
|
|
#
?
Jan 22, 2020 22:44
|
|
|
I guess everything is "web" nowadays and because of that, to make a normal desktop app they just wrap a shitload of css and javascript in electron and call it a day. Traditional desktop GUI applications seem... well, not rarer, but I don't see nearly as much job vacancies looking for people with knowledge of how to make those. But perhaps that's just my bubble, I'm not sure.
|
|
#
?
Jan 22, 2020 22:52
|
|
|
repiv posted:The developer of classic indie game VVVVVV just released its source code to celebrate its 10 year anniversary how can you do this and not put half of that in a function or a separate file, if only where for the convenience.. and harggggg.. using numers instead of giving a name, even if is INTERMISION_8A
|
|
#
?
Jan 22, 2020 23:13
|
|
|
The Dark Wind posted:Would this qualify as a horror? I was looking at a company's careers page and noticed an ad for a front-end developer. The main language requirement was C++ which seemed strange. Investigating further, it looks like their entire front-end is built in JUCE. Given my (very limited) exposure to C++, trying to write a front-end in C++ sounds like all kinds of horrible unpleasantness. my, what have the kids come to these days
|
|
#
?
Jan 23, 2020 00:12
|
|
|
Hammerite posted:Despite working with async code in the past, I often find it difficult to wrap my head around it and I'm sure others do too. Could you help spread the knowledge by explaining why this code fails to do what the author intended it to do, and how you would go about fixing it (if you had to content yourself with just putting a bandaid on it?) A bit late, but if I understand async properly, DoDispose() will return immediately after creating a new thread that will call DoDispose with retryCount + 1 after 1 second (I assume Delay is in ms). The process of waiting 1 second and calling DoDispose continues recursively until retryCount == 10 or BackgroundRefreshInProgress == false. I don't actually know .NET at all, but I'm just going to assume that chain-spawning 10 threads is the dumbest possible way to do this, and something like Volmarias' solution is much better, although their's appears to just give up after 10 seconds, while the original looks like it just calls Scope.Dispose() whether the background refresh is done or not. I may have messed up my reasoning somewhere because the original bug was an early dispose, or maybe 10 seconds sometimes isn't long enough.
|
|
#
?
Jan 23, 2020 01:54
|
|
|
Volguus posted:Why do you think that? C++ would provide a native, efficient desktop application (coding horrors notwithstanding). In what language/platform do you think a front-end should be written in? Yeah, the mere fact of using C++ isn't enough to assume it's a horror. I don't know much about JUCE, but what little I know doesn't make me automatically assume it's a horror either.
|
|
#
?
Jan 23, 2020 05:25
|
|
|
The Dark Wind posted:Would this qualify as a horror? I was looking at a company's careers page and noticed an ad for a front-end developer. The main language requirement was C++ which seemed strange. Investigating further, it looks like their entire front-end is built in JUCE. Given my (very limited) exposure to C++, trying to write a front-end in C++ sounds like all kinds of horrible unpleasantness. Between college and grad school I spent some time doing what would now be considered front-end development in C++. It was fine for what it was. A lot of the complexity in front-end is just inherent to making UIs, and honestly having a statically type-checked language cuts down on the number of bugs you can have. I can definitely see some issues for someone whose only programming experience is in JavaScript, but otherwise this doesn't seem that bad unless JUCE is inherently horrible.
|
|
#
?
Jan 23, 2020 05:38
|
|
|
ultrafilter posted:Between college and grad school I spent some time doing what would now be considered front-end development in C++. It was fine for what it was. A lot of the complexity in front-end is just inherent to making UIs, and honestly having a statically type-checked language cuts down on the number of bugs you can have. I can definitely see some issues for someone whose only programming experience is in JavaScript, but otherwise this doesn't seem that bad unless JUCE is inherently horrible. Well it's not just a choice between C++ and JavaScript though. There's a middle ground of other more "friendly" statically typed languages that you can use. But yeah, C++ is still totally fine for a front-end and not a horror.
|
|
#
?
Jan 23, 2020 05:40
|
|
|
If your computation core is C++ and want to provide native app, there is no reason to use any of the "in-between" languages. Either bolt on more C++ or go hard for typescript and ""modern"" ui frameworks (lol)
|
|
#
?
Jan 23, 2020 07:46
|
|
|
I don't know anything about this JUCE, but my experience of frontends in C++ is MFC, so I'm extremely suspicious of it. My inclination is that C++ is for when you have to write stuff that uses the computer's resources very efficiently, which is why it's good for writing number-crunching routines that run a million times a second. However front-end stuff tends to be wiring up routines that run whenever e.g. the user clicks a button, which does not happen a million times a second and it really does not matter whether it uses the computer's resources at all efficiently. And doing things in C++ is cumbersome because you don't have a lot of time-saving conveniences built in to the language. As someone else said, your choices are not limited to the two extremes of "type-safe but cumbersome" C++ or "anything goes" HTML+JavaScript. e: For clarity, the prototype I have in mind for a framework that does have "time-saving conveniences built in" is WPF. Hammerite fucked around with this message at 11:22 on Jan 23, 2020 |
|
#
?
Jan 23, 2020 11:20
|
|
|
C++ is awesome Boomers - desktop apps GenerationX and millenials - web apps
|
|
#
?
Jan 23, 2020 12:05
|
|
|
JUCE is geared towards audio applications, so it’s a strange choice if they aren’t doing anything audio-related, but there’s probably nothing wrong with using just the UI bits.
|
|
#
?
Jan 23, 2020 12:41
|
|
|
Hammerite posted:it really does not matter whether it uses the computer's resources at all efficiently That attitude is why applications from 20 years ago feel more responsive than todays "we need to peg a core for 500ms to open a context menu" applications. 
|
|
#
?
Jan 23, 2020 12:55
|
|
|
Also with C++ for web applications, you can have lightning fast HTML templates. And if you want to be hip, you could implement your data validation rules as a library that can compile to WASM and include that straight in the browser.
|
|
#
?
Jan 23, 2020 13:06
|
|
|
I am newbie here in SA so I had not idea about this https://www.youtube.com/watch?v=UCgoxQCf5Jg I am speechless and a bit scared now Tei fucked around with this message at 13:47 on Jan 23, 2020 |
|
#
?
Jan 23, 2020 13:31
|
|
|
Hammerite posted:I don't know anything about this JUCE, but my experience of frontends in C++ is MFC, so I'm extremely suspicious of it. C++ has plenty of its own problems (*cough* memory safety *cough), but IIRC MFC is just an awful library.
|
|
#
?
Jan 23, 2020 14:12
|
|
|
Antigravitas posted:That attitude is why applications from 20 years ago feel more responsive than todays "we need to peg a core for 500ms to open a context menu" applications. It is possible to take any sensible maxim to ridiculous extremes. It is not necessary to worry about efficiency to the nth degree for an operation like "open a context menu" that occurs, from the computer's perspective, once in an ice age. That does not mean you should be content if your application is so ridiculously inefficient as in your example. Basically, there are 3 qualitative levels of speed. Super-fast, fast-enough, and not-fast-enough. It is worth hitting the "fast-enough" target. It is not worth stretching to hit "super-fast" - not for UI code. Using a relatively low-level language like C++ is worthwhile to make number-crunching code super-fast, but is not necessary to make UI code fast-enough. You can achieve that with other technologies with less effort. I am sure that the MFC code I maintain written in C++ is orders of magnitude faster than the UI code in the newer WPF apps I write and maintain. I am equally certain that the grotty MFC code is not worth that speed-up, which is not noticeable to a user.
|
|
#
?
Jan 23, 2020 14:48
|
|
|
OddObserver posted:C++ has plenty of its own problems (*cough* memory safety *cough), but IIRC MFC is just an awful library. Just lol if you manage your own memory in C++ ITYOOL 2020.
|
|
#
?
Jan 23, 2020 14:57
|
|
|
ratbert90 posted:Just lol if you manage your own memory in C++ ITYOOL 2020. Yeah, they're called std::unique_ptr and std::shared_ptr, learn them! Also there are a lot of GUI frameworks for C++, including the one we use at work, Dear ImGui, which is actually pretty straightforward and I can't recommend it enough. It does require you to run your own UI loop instead of relying on callbacks, but that surprisingly just streamlines everything.
|
|
#
?
Jan 23, 2020 15:07
|
|
|
Thanks goons, I'm still a dumb newbie who looks at C++ and gets very intimidated, so the thought of trying to do front-end web development work (which is already a pain) in C++ sounded like an extra-challenge. I guess if you're already comfortable with C++, it's a much different story.
|
|
#
?
Jan 23, 2020 16:07
|
|
|
The Dark Wind posted:Thanks goons, I'm still a dumb newbie who looks at C++ and gets very intimidated, so the thought of trying to do front-end web development work (which is already a pain) in C++ sounded like an extra-challenge. I guess if you're already comfortable with C++, it's a much different swetory. Nobody wants to do front-end work in C++ unless it's webkit or QT. I think Springboot is what most companies use if they're Java based, and Django/Flask if their Python based.
|
|
#
?
Jan 23, 2020 16:16
|
|
|
OddObserver posted:C++ has plenty of its own problems (*cough* memory safety *cough), but IIRC MFC is just an awful library. This. Its ancient and was basically designed by 90s Microsoft interns who had just read C++ For Dummies. It was bad even 20 years ago. Qt is C++ and is used for all sorts of stuff, though.
|
|
#
?
Jan 23, 2020 16:21
|
|
|
I have really good memories of C++ reading about it make me feel like returning to it It was a fun programming language but memory related bugs where nasty
|
|
#
?
Jan 23, 2020 16:28
|
|
|
Tei posted:I have really good memories of C++ Except in some very rare cases, with C++ >= 14 you shouldn't manage memory.
|
|
#
?
Jan 23, 2020 16:31
|
|
|
The Dark Wind posted:Thanks goons, I'm still a dumb newbie who looks at C++ and gets very intimidated, so the thought of trying to do front-end web development work (which is already a pain) in C++ sounded like an extra-challenge. I guess if you're already comfortable with C++, it's a much different story. Are you sure it's web development?
|
|
#
?
Jan 23, 2020 16:51
|
|
|
Yeah, I have no idea if this is accurate, but my gut tells me that doing frontend native UI in C++ is a completely different beast from doing frontend web UI in C++.
|
|
#
?
Jan 23, 2020 17:09
|
|
|
I like to describe the layout of a UI using HTML and CSS, but only browsers, with all their attendant overhead, have this capability.
|
|
#
?
Jan 23, 2020 17:12
|
|
|
My team lead just tried to tell me that you shouldn't have the expectation of who get's what tickets beforehand before they get assigned a point value. 
|
|
#
?
Jan 23, 2020 17:24
|
|
|
I mean, for a certain value of "shouldn't," that's kind of true. On an ideal team, everybody should be able to handle every ticket and everybody should come to similar values when estimating their points. In the real world, yeah, you're pretty sure the team member who implemented Feature X is going to have a couple of sprints where they get assigned all the Feature X bugs.
|
|
#
?
Jan 23, 2020 17:27
|
|
|
|
| # ? May 17, 2024 00:29 |
|
|
ratbert90 posted:My team lead just tried to tell me that you shouldn't have the expectation of who get's what tickets beforehand before they get assigned a point value. I don't know what is this point value system for? care to elaborate or point me somewhere?
|
|
#
?
Jan 23, 2020 17:34
|
|