cv-pls c# Pseudocode: C# - whether Abstract class implementation is correct

@200_success Real code added.

[cv-pls] question about design codereview.stackexchange.com/questions/209042/…

cv-pls c Code not implemented or not working as intended: Application of correct order of operations in C - Δημήτρης Σπανάκης‎ - 2018-12-05 08:52:32Z

cv-pls python Lacks concrete context (stub code): Catch and Raise exceptions at all layers? - Lokesh Agrawal‎ - 2018-12-05 09:17:47Z

cv-pls performance Lacks sufficient context: C - Make function as efficient as possible due to many calls - Abbi Ab‎ - 2018-12-05 13:24:21Z

cv-pls python Unclear result = myQ(2.0, 1.0, neg = True) * myQ(2.0, 1.0, rec = True) - Christopher Mitchell‎ - 2018-12-05 17:40:35Z

@TobySpeight I've worked out what this does, and edited it to be clearer - no need now to close it, ta!

^ @Makyen What do we have to do again exactly to move the linked request to the "graveyard"/"/dev/null"?

@πάνταῥεῖ The basic SE interface for moving messages is "room" (in sidebar, just below the room blurb)➞"move messages" you can then click on messages to select them. After you've selected the ones you want, then click "relocate" in the popup that opened. I'll try to get an update for the Archiver out today which makes it a bit easier, and allows message selection from the transcript, search, and user pages.

I'm not sure yet if it will have the full archiver interface working here in this next update.

→ 1 message moved to CRCQR Request Graveyard

@Makyen Ty.

np.

I'll further have to update the FAQ as soon I find time to do so. :P @Makyen

@Makyen One more question pls: Should such go rather to the CRCQR Request Graveyard or to the CRCQR /dev/null? As that doesn't look like "trash", i decided to move it to the former.

@TobySpeight Please ping a RO in future if you want a request deleted from this room.

@πάνταῥεῖ Thanks!

@TobySpeight np (besides I still need to learn how to do my job here ;-) )

@πάνταῥεῖ That's really up to you. In SOCVR, we move them to /dev/null, keeping the Graveyard as requests that are "complete" (i.e. that have either had the requested action performed, or the request expired). This has the advantage that everything in the Graveyard is something that was intended to be acted upon. It allows someone to scan through the Graveyard for older requests that were not fulfilled.

If you move requests to the Graveyard which are no longer intended to be acted on, then you have to be concerned about the possibility that some requests shouldn't be acted upon when looking through the Graveyard. This also makes some sense in that you know everything in /dev/null should not be acted upon. Note that looking through the Graveyard isn't a "normal" thing, but is helpful to see success rate, or to check, from time-to-time, for things that might be slipping through the cracks.

OTOH, the idea of keeping /dev/null only for actually bad things has some appeal too. I'd suggest picking one way to do it and sticking with it.

room topic changed to SE Code Review Close Questions room: We should discuss close worthy / off-topic questions at the SE Code Review site here. Here's an adapted (not yet complete) version of the current SOCVR FAQ: SECRCVR FAQ (no tags)

room topic changed to SE Code Review Close Questions room: We should discuss close worthy / off-topic questions at the SE Code Review site here. Here's an adapted (not yet complete) version of the current SOCVR FAQ: "SECRCVR FAQ" github.com/CodeReviewCommunity/SECRCVR/blob/master/FAQ.md (no tags)

@ThomasWard No more weird gloomig eyes? ;)

nah the lasers in my eyes were redeployed on the orbital weapons platforms. MUCH more fun to watch things burn due to lasers from space than lasers from my eyes evil laughter

@ThomasWard LOL, you looked like satan personally before the change ;)