Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Type check not working in conditional breakpoints #17

Closed
sano98 opened this issue Feb 7, 2019 · 15 comments
Closed

Type check not working in conditional breakpoints #17

sano98 opened this issue Feb 7, 2019 · 15 comments

Comments

@sano98
Copy link

sano98 commented Feb 7, 2019

I wanted to use a conditional breakpoint that should trigger when a general function (like a superclass constructor or a function that checks all onscreen objects for mouseover) is dealing with a object of a certain type.

For my breakpoint expression, I used:

Std.is (this, ObjectType)

where all instances of this are childclasses of FlxSprite.
However, that expression never triggers. It even does not when I set ObjectType to FlxSprite.

The breakpoint does trigger for simple numerical conditions, like:

this.x < 25

@sano98
Copy link
Author

sano98 commented Feb 7, 2019

Used versions:

hxcpp: 4.0.8
hxcpp-debug-server: 1.1.1
lime: 7.2.1
openfl: 8.8.0
hscript: 2.3.0
haxe: 4.0.0-rc.1

@nulld
Copy link
Member

nulld commented Feb 7, 2019

For now, iterpreter, which executes expressions for conditional breakpoints has access only to properties of object, where breakpoint was hit, and know nothing about Std.is, for example.

Maybe, some kind of custom initialization of interpreter will be usefull, how do you think?

For e.g. api can looks like:

DebugServer.interp_expose("Std", Std);

@Gama11
Copy link
Member

Gama11 commented Feb 7, 2019

Shouldn't we just expose top-level types such as Std, Math, etc by default?

@nulld
Copy link
Member

nulld commented Feb 7, 2019

Hm.. Sounds more user friendly than my solution - I like it :) But how many of top-level types average project use? It can significantly slowdown everything, if someone sets conditional breakpoint in game loop for e.g. ( For now, iterpreter initializes each time conditional breakpoint met )

@Gama11
Copy link
Member

Gama11 commented Feb 7, 2019

For now, iterpreter initializes each time conditional breakpoint met

Why?

@sano98
Copy link
Author

sano98 commented Feb 7, 2019

Just from a user perspective: When I run the debugger to identify a nasty problem, I generally don't care very much about slowdowns.

Once the problem is found, I can remove the breakpoint and everything should be back to full speed, right?

@nulld
Copy link
Member

nulld commented Feb 7, 2019

Why?

Because, all varialbles with thier values, available in the line of breakpoint, need to be exposed to iterpreter.

@nulld
Copy link
Member

nulld commented Feb 7, 2019

I just thought, that we can hold all top-level types in static member of interpreter, and expose it once on debug session start - it must work pretty fast. Will try.

Can I rename an issue?

@nulld
Copy link
Member

nulld commented Feb 8, 2019

please test it with last commit, and reopen if it doesn't work for you for some reason

@nulld nulld closed this as completed Feb 8, 2019
@Gama11
Copy link
Member

Gama11 commented Feb 20, 2019

Seems to basically work. :) But I guess right now stuff you want to use still needs to be exposed manually?

@Gama11
Copy link
Member

Gama11 commented Feb 20, 2019

I guess cpp.vm.Debugger.getClasses() must return an empty list in my case?

Anyway, I'll rename staticVariables to globals for now (since the classes you're adding to it aren't static vars) and make it read-only, and release a 1.2.0.

@Gama11 Gama11 reopened this Feb 20, 2019
Gama11 added a commit that referenced this issue Feb 20, 2019
@nulld
Copy link
Member

nulld commented Feb 21, 2019

Found, that top-level types, declared inside hxcpp library, not presented in result of cpp.vm.Debugger.getClasses() call, so have add it manually (Math, String).

By the way, I have exposed other types too in order to use them in expressions, for e.g. flixel.FlxSprite.

@nulld nulld closed this as completed in afd7a9d Feb 21, 2019
@Gama11
Copy link
Member

Gama11 commented Feb 21, 2019

Seems to work great now. 👍

@sano98
Copy link
Author

sano98 commented Jun 28, 2019

grafik
When trying to use the condition with a classtype of my project, it does not trigger.
Am I missing something?
Does this not work, as my own classes are not exposed?
Is this a resolution thing - would I have to write the absolute file path of the Apple class?
Or is it generally not possible to do what I'm trying? Thx!

@nulld
Copy link
Member

nulld commented Jun 28, 2019 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants