Breakpoints do not work in Thread

[ret80]

Breakpoints do not work in Thread!
Moreover if you are running a Thread that does not not work Breakpoints

[reduz]

debugging only works on the main thread, thread debugging will be
implemented soon

On Mon, Sep 7, 2015 at 10:30 AM, ret80 [email protected] wrote:

Breakpoints do not work in Thread!

—
Reply to this email directly or view it on GitHub
#2446.

[ret80]

as soon as it is when? and a version?

[reduz]

soon to me is 2.1 likely (it's on my list for that version), early next year

On Mon, Sep 7, 2015 at 12:29 PM, ret80 [email protected] wrote:

as soon as it is when? and a version?

—
Reply to this email directly or view it on GitHub
#2446 (comment).

[ret80]

This is a very long time, given that the possibility of debugging is the most important feature.
Maybe we should reconsider the priority of this task?

[reduz]

Generally, I manage feature priorities according to amount of users
requesting them. I try to not ignore anyone, but we are almost close to a
beta now and you are the first that asked for this. Can't you use prints
for now until this is available?

On Mon, Sep 7, 2015 at 12:41 PM, ret80 [email protected] wrote:

This is a very long time, given that the possibility of debugging is the
most important feature.
Maybe we should reconsider the priority of this task?

—
Reply to this email directly or view it on GitHub
#2446 (comment).

[ret80]

I was looking a bit that users ask for. They ask, "Unreal". But it already exists! Here is a link "https://www.unrealengine.com/blog". And to be honest, very surprised why no one is asking what really facilitate the work of programmers. I was just wondering how to "okamstudio" debug game? With prints ?! It's a nightmare. Today I was setting on all code print and watched what was going on there for me. And it's just hell.
By the way you have in this version there is a clause that says that debaging will be improved. I was hoping that it would improve not partially but completely.
As for the next release. What to do with this release, even if there is not a full debug ?! It would just be the next release which will make demos like my shooter. Because it is difficult to do something else. The more the more difficult to debug code. Godot is already quite suitable for creating 2D games. It remains only to fix bugs and debaging tie. You do not need the new features and new technologies. It's plenty of time.

[reduz]

Dude just be patient and wait a few months, Godot development is already
very fast and I really have a huge amount of work on my plate. Soon you
will be able to fund development so I can dedicate more time to it and get
things done faster, I hope you contribute :)

On Mon, Sep 7, 2015 at 5:09 PM, ret80 [email protected] wrote:

I was looking a bit that users ask for. They ask, "Unreal". But it already
exists! Here is a link "https://www.unrealengine.com/blog". And to be
honest, very surprised why no one is asking what really facilitate the work
of programmers. I was just wondering how to "okamstudio" debug game? With
prints ?! It's a nightmare. Today I was setting on all code print and
watched what was going on there for me. And it's just hell.
By the way you have in this version there is a clause that says that
debaging will be improved. I was hoping that it would improve not partially
but completely.
As for the next release. What to do with this release, even if there is
not a full debug ?! It would just be the next release which will make demos
like my shooter. Because it is difficult to do something else. The more the
more difficult to debug code. Godot is already quite suitable for creating
2D games. It remains only to fix bugs and debaging tie. You do not need the
new features and new technologies. It's plenty of time.

—
Reply to this email directly or view it on GitHub
#2446 (comment).

[ret80]

I can not say to people that make a project that you need to wait until next year. Most of all, I just have to change the engine. It takes less time. I will follow the developments.

[godotengine]

It's a shame that Godot does not currently provide a feature you need and
that there is no way for you to do a workaround.
I hope you understand that you are not the only Godot user and being that
every user has different needs, I have to attend the most requested ones
first. If you want to accelerate or prioritize some parts of the
development, you will soon be able to use funds for this :)

On Mon, Sep 7, 2015 at 5:49 PM, ret80 [email protected] wrote:

I can not say to people that make a project that you need to wait until
next year. Most of all, I just have to change the engine. It takes less
time. I will follow the developments.

—
Reply to this email directly or view it on GitHub
#2446 (comment).

OkamStudio

[punto-]

I think very few people use threads, that's why it's not a very requested
feature, and we have a habit of using prints to debug instead of
breakpoints, even on the main thread (I don't think I've ever used them,
although I rely on the debugger breaking when there's an error, and I miss
that when my threads need to break). On Android (and other closed
platforms) there's not even a good debugger for native code, and you have
to debug stupid dangerous shit like jni with prints. Which is not an excuse
to not have a better debugger, I'm just saying it's possible.

On 7 September 2015 at 23:05, Okam Studio [email protected] wrote:

It's a shame that Godot does not currently provide a feature you need and
that there is no way for you to do a workaround.
I hope you understand that you are not the only Godot user and being that
every user has different needs, I have to attend the most requested ones
first. If you want to accelerate or prioritize some parts of the
development, you will soon be able to use funds for this :)

On Mon, Sep 7, 2015 at 5:49 PM, ret80 [email protected] wrote:

I can not say to people that make a project that you need to wait until
next year. Most of all, I just have to change the engine. It takes less
time. I will follow the developments.

—
Reply to this email directly or view it on GitHub
<#2446 (comment)
.

OkamStudio

—
Reply to this email directly or view it on GitHub
#2446 (comment).

[ret80]

Correct least #2418 && watch #2438
please!
very necessary

[godotengine]

sorry, you are pretty bad at reporting bugs. I really wish you added more
context, as I'm not a magician that can read your mind

On Tue, Sep 8, 2015 at 9:42 AM, ret80 [email protected] wrote:

Correct least #2418 #2418 &&
watch #2438 #2438
please!
very necessary

—
Reply to this email directly or view it on GitHub
#2446 (comment).

OkamStudio

[akien-mga]

Not critical for the upcoming 2.1, so moving to the next milestone.

[jahd2602]

Working with threads and TCP here, please bump this feature request. I can't program in C++ so I will not be able to contribute in this one.

[supercom32]

I never bothered to say anything, but after seeing how long this issue has been around, I decided to write in just to let developers know there are people who care about this issue greatly (But may not have been vocal about it).

I think we can all agree that multi-threading in applications is notoriously tricky, even in the best of times. Not having proper debug/breakpoints just makes it that much more difficult to work with. Sure you can add "print" statements everywhere, but it won't help you if you can't easily inspect variables at runtime, or if for some reason your "print" doesn't render because something else is causing a problem and blocking it.

Essentially the only workaround we have right now is to just add "prints", wait until it doesn't render anymore, and then try to look at the lines which are causing it to die. And if you want to inspect variables or objects, cram them all out to console before your code dies.

[reduz]

Should make the debugger multithreaded.. I guess it does need to be done.. will add to todo list for 3.1

…

On Apr 25, 2017 5:29 PM, "supercom32" ***@***.***> wrote: I never bothered to say anything, but after seeing how long this issue has been around, I decided to write in just to let developers know there are people who care about this issue greatly (But may not have been vocal about it). I think we can all agree that multi-threading in applications is notoriously tricky, even in the best of times. Not having proper debug/breakpoints just makes it that much more difficult to work with. Sure you can add "print" statements everywhere, but it won't help you if you can't easily inspect variables at runtime, or if for some reason your "print" doesn't render because something else is causing a problem and blocking it. Essentially the only workaround we have right now is to just add "prints", wait until it doesn't render anymore, and then try to look at the lines which are causing it to die. And if you want to inspect variables or objects, cram them all out to console before your code dies. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2446 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AF-Z21daddK2C6iP82fWckFpG4H6gZxHks5rzhFigaJpZM4F4-f3> .

[supercom32]

I dunno if this is the same issue or not, but I also noted that if your thread has an exception, such as you misspelt a method name, it just quietly does nothing and doesn't give you an error.

It took a lot of "prints" to find out where it was getting killed. :-)

[neikeq]

@supercom32 It's the same issue.

[Favorlock]

Is this going to be implemented anytime soon? This feature request has been open for 5 years now. I can't properly debug my scripts because we use multi-threading to avoid bogging up the main thread with http requests. Please do consider making this a priority feature considering multi-threading is supported by GDSCript.

[Calinou]

@Rriik This might be attempted for 4.0, but I can't make any guarantees about it.

[Favorlock]

It really would be nice to see. Debugging is such a critical feature for any programmer. Many times have I run into issues and only figured out the issue in a timely manner because of debugging. Multi-threading is becoming more and more common, especially for games that utilize web services and can't afford to allow the main thread to be blocked. Being unable to debug threads means that Godot isn't going to see as much growth in this regard.

[PerMalmberg]

I just wasted hours trying to debug my threaded code until I asked myself "is debugging threads even supported?" Well, now I know it isn't!

the ability to debug threaded code is super important, please ensure this is added to 4.0.

[Calinou]

@lord-tomorrow Please don't bump issues without contributing significant new information. Use the 👍 reaction button on the first post instead.