Forked VSCode for Delphi

[Leif Uneus 43]

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.

[Rudy Velthuis 91]

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 May 6, 2019 by Rudy Velthuis

[Lars Fosdal 1791]

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.

[David Heffernan 2345]

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. 

[Lars Fosdal 1791]

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.