Jump to content

Recommended Posts

The Delphi IDE known as Galileo (.NET inspired) has 15+ years on its neck.

The tools to build and support the IDE is somewhat outdated and the Rio IDE is the first attempt in years to remove old dependencies.

  • Like 1

Share this post


Link to post
Posted (edited)
6 hours ago, Nasreddine said:

@Rudy Velthuis You are right the VS loading time is terribly slow. but I think If Embarcadero continues like this, we will not only have to deal with an IDE that lacks "good gimmicks" but also a very slow one too.

 

If they Continue down this road, they will make it easier to dump the IDE than trying to fix any thing anymore.  

This is the first incarnation of the new theming IDE. I'm sure they'll find ways to make it a lot snappier. They had problems with one of the earlier versions too (not sure which one) and it became much better in the next version.

 

And gimmicks can be implemented by 3rd parties too, if they can find out what people need or would like to have.

Edited by Rudy Velthuis

Share this post


Link to post
On 4/29/2019 at 4:55 PM, Jacek Laskowski said:

You can freeze all threads except the debug thread (in Threads window).

Since it often is the actual thread interaction in a multithreaded server that is the cause for debugging - freezing other threads would be undesirable.

I'd settle for a way to have breakpoints thread context aware so that I can choose to have breakpoints active in specific threads.  A way to easily enable/disable breakpoints per active thread context.

Share this post


Link to post
1 minute ago, Lars Fosdal said:

Since it often is the actual thread interaction in a multithreaded server that is the cause for debugging - freezing other threads would be undesirable.

I'd settle for a way to have breakpoints thread context aware so that I can choose to have breakpoints active in specific threads.  A way to easily enable/disable breakpoints per active thread context.

Stepping through execution in an interactive debugger is fine for some debugging tasks, but it's just one form of debugging. It's hopeless for debugging threading specific issues. It's the wrong tool. Lots more to debugging than interactive debugger step through. 

Share this post


Link to post
1 hour ago, David Heffernan said:

Stepping through execution in an interactive debugger is fine for some debugging tasks, but it's just one form of debugging. It's hopeless for debugging threading specific issues. It's the wrong tool. Lots more to debugging than interactive debugger step through. 

I use extensive logging, so that does clarify most of my threading issues - but sometimes, you simply need to get into the structures to understand where shit happens.  At that point, I'd like my debugger to be well behaved.  Unfortunately, it is not.

  • Like 1

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×