Leaderboard

A new IDE plugin aimed at helped debugging multithreaded apps! https://blogs.embarcadero.com/new-ide-plugin-parnassus-parallel-debugger/ The plugin: Displays all thread call stacks next to each other Lets you step over, run, etc a thread by itself, not the whole process Shows CPU usage by thread Editor integration to see where threads are executing, so you can easily see what other threads are in the same area of code and more... This has taken me five years to write! That said, most of that was downtime due to working too much time to spend time on this - this release is the result of working weekends since August. It's version 1, and I plan to add some more features over the next few months.

Do you prefer Access Violations or other random errors?

Looks good so far, sometimes a liitle bit slow with repainting the windows, but very usefull! That there are some issues matches the host application 🙂

More issues fixed, I would hope! We've actually found and already fixed or plan to fix several already, which were found by this plugin.

@Angus Robertson btw plz don't take my words as offense or something, I didn't mean anything of that sort... Still hard for me to keep emotional or politeness nuances in English. Yep, no problem while the integration isn't too deep. I'll try to keep closer with recent changes.

This is the kind of hint that must be prefixed with Use with care and only if you absolutely need this! warning. While this could add some speed, this also reduces encapsulation, making testing more hard. When local variables really kill performance, it's better to use var parameters. Would be nice indeed. It took plenty of time for me to discover that any string concatenation or a routine returning a temporary string causes compiler to generate hidden try-finally block. On the subject: my personal rule is to just keep in mind that local managed variables add overhead. If a routine contains a string operation just for rare error report, don't use concatenation or Format but Exception.CreateFmt instead, or a nested routine. All arguments of record or managed types must be used by reference (const/out/var). But don't bother any more if a routine requires several strings or something non-optimal etc until it causes noticeable slowdown. I really do string concats in a loop and other performance-wise awful things to keep code short and simple when a function is executed relatively rarely.

AFAIK, editing posts and comments doesn't trigger a notifications for others - so if the intent is to make the update visible, adding a new comment is probably the best approach. Those that have been active in the thread will then get notified.

SNAKE_CASE is good as well (moreover, it even has upppercase form - using a pretty big snake, maybe anaconda - and lowercase with some compact snake like viper). I wonder what "Snake kebab case" would look like 🙂

In the exactly same situation (using extra unit for just one 3-lined function annoys me like hell) I ended up with most trivial solution - I named my functions `IfTh`.

I agree - unless we are talking about old-ish replies? Personally, I am ok with a freeze after so many (days?) policy. Any correction after than can be done in a new comment? Edit: There have been episodes where members have modified their posts/comments a long time after they were written. Usually in the context of "leaving in anger".

No ! I'm sure you'll become a good developer and BTW I don't find your topics annoying. I just don't want you to spend your valuable time on something that doesn't really make difference. You said you're working alone ... so literally you can pick whatever naming you like. In other word, your topic is just a color and you know that there is no color better than other 🙂

Please when you have some spry time, take a look at this : Parkinson’s Law of Triviality "bike-shedding"

Anders, With Assert If In_The_Shit then Panic Without Assert If In_The_Shit then DoOurBestToCope else BizAsUsual;

T for types, I for Intfs, E for exceptions, F for fields, rarely A for arguments - when the name without prefix clashes with something but is too good to change. That's all. Other things seem to me just a useless visual noise requiring more time to type

Thank you for that link!

Maybe this helps: "Because they are not good at looking at things from the listener’s point of view and considering what type of information would help explain a point, their conversations often are disjointed and lack logical or meaningful connections. They tend to ramble on, go off on tangents, or not focus on any particular point. What drives the way they talk is what they are focused on, what they are interested in rather than what holds the attention of whoever they are conversing with. In one-on-one conversations and in groups, they stand out as disorganized, jumbled and confused due to the mismatch between what they want to say and the topic at hand. "A frequent reaction of someone conversing with an adult who has Asperger’s is to experience the person as thinking out loud to themselves, rather than trying to have a mutual conversation. Whatever comes to mind is said out loud." Roberson, Kenneth. Adult Asperger's Syndrome: The Essential Guide This is something I've been learning about myself over the past year. It explains a lot of ways people have regarded me since I was very young. This is just a small part of it. Thanks for noticing.

You should use the intrinsic GetTypeKind() function instead, eg: constructor TBSCatalogBuilder<T>.Create(ACatalogId: Integer; const AName: String); begin if GetTypeKind(T) <> tkEnumeration then begin raise Exception.Create('Passed type is not an enumeration.'); end else begin FTypeData := GetTypeData(TypeInfo(T)); ... end; end; This way, if T is an enumeration type, the compiler will omit the raise statement from the final executable, and if T is not an enumeration then it will omit the rest of the constructor code leaving just the raise, eg: constructor TBSCatalogBuilder<AnEnumType>.Create(ACatalogId: Integer; const AName: String); begin FTypeData := GetTypeData(TypeInfo(AnEnumType)); ... end; constructor TBSCatalogBuilder<ANonEnumType>.Create(ACatalogId: Integer; const AName: String); begin raise Exception.Create('Passed type is not an enumeration.'); end; The way you wrote the code originally using Assert() does not allow the compiler to make that same optimization.

At least a splash screen would be nice. You don't want to put your db connection into a thread. Nor many other things. It's so 90's. ctrl+shift+esc

Must be very unproductive and frustrating the way you handle things - it is known that humans are terrible at context switching.

Yes, IIRC you're correct. We had to (IIRC) use the .dproj file switch because for whatever reason (bug?) the compiler ignores the compiler directive but does respect the .dproj flag. (To add, in our case the "C++ output file generation" was also already off, however the compiler still emits/emitted this warning from one of the Synopse modules e.g. SynCommons.pas: "'ESynException.CreateLastOSError' with identical parameters will be inaccessible from C++" (and checking the module was being recompiled from scratch.) The only way that worked was the .dproj flag.

It may help to place that directive in the project file instead of the unit with the class declaration.