i just started learning Haxe today and i got a couple of problems with my VSCode.
There are 3 "Errors" in total, to be exact 2 errors and 1 info, but the info seems kind of wrong and i would like to know how to get rid of it aswell.
Before i go into more detail, some info that might be relevant:
I created my project using the "Haxe: Initialize Project" from the Haxe VSCode extension
I changed nothing in the build.hxml file
If i run my code via VSCode (Ctrl-Shift-B) i get an error
If i run it on a normal CMD with "haxe build.hxml" it works totally fine, no errors at all
The Code:
class Main {
static function main() {
trace("Hello, World!");
var t:String = Sys.stdin().readLine().toString();
trace(t);
}
}
The build.hxml file:
-cp src
-D analyzer-optimize
-main Main
--interp
The first error i get:
It seems that this error is not even in my own file, how can this be?
The Sys.stdin().readLine() seems to have something to do with it, since this error came the moment i added this line.
Uncaught exception Not implemented in haxe.io.input.readByte at haxe/io/Input.hx tasks [180. 1]
Screenshot from VSCode
The second error i get:
Once again it seems to have something to do with Sys.stdin().readline() this time this exact part of my code is red underlined and the error message is pointing at this exact line.
Called from here tasks [4, 18]
Screenshot from VSCode (Error)
Screenshot from VSCode (red underline)
The (kind of) error / Info i get:
This is the most weird one imho..
Its a blue "~" i get at the beginning of my trace("Hello, World!"); line.
Screenshot from the weird Blue Symbol
Screenshot from the VSCode "Problem" regarding this line
Thanks in advance!
I looked through the internet the whole day hoping to find something to get this things solved on my own, but since its my first time ever using Haxe and i was not able to find something even similar to this i hope some of you 5heads out there can help me with this. :)
I'm unable to understand how the mock-debugger extension controls where the next step is.
For example what if I'd like to step 2 lines if I find the word "banana" in my text? Also, I'd like to do something, like "Step In", where I can walk word-by-word - is it possible?
I've seen the this._currentLine = ln; assign, which looks like it controls where the line is, but it's just a simple local variable. How could it ever control anything in the debugger? I can't find any other uses of the _currentLine varbiable where it passes to anything useful API (except for stack tracing, but I don't think it has any relation with the debugger line-control).
The stack trace is the only source for the debugger step visualization. When the debugger gets a notification to pause it requests the current stack trace. The TOS determines where the next execution point will be located. Hence the debug adapter is reponsible to determine this position precisely.
I am using the vscode-mock-debug git as the basis for my work.
Activation event is OnDebug, although same result
I implement provideDebugConfigurations in my DebugConfigurationProvider and its not getting called.
provideDebugConfigurations(folder: WorkspaceFolder | undefined, token?: CancellationToken): DebugConfiguration[] {
return [...my data in here];
}
the resolveDebugConfiguration (the original from mock-debug) is called, I can set a breakpoint. However the provideDebugConfigurations is never getting reached. build 1.36 of vsce. am I missing something obvious ?
this is the answer from the vscode team: https://github.com/microsoft/vscode/issues/78362
I have investigated this and it is expected behavior.
Namely, provideDebugConfigurations is only called then the debug configurations are needed to generate a launch.jsonfile. If you click on the configure command the provideDebugConfigurations will get nicely called.
However if you do not have a launch.json and you simply press Debug Start, vscode will try to start debugging without using debug configurations, but using one on the fly provided by the resolveDebugConfiguration call.
More about this can be found in our docs https://code.visualstudio.com/api/extension-guides/debugger-extension
Thus closing this as designed.
I have a Pd patch which calls in a second patch as an abstraction.
The second patch works fine by itself. But when I try to use it from inside the first, I'm seeing this
signal outlet connect to nonsignal inlet (ignored)
error. But I can't see WHERE it's happening.
Doing "Find last error" just gives me.
... sorry, I couldn't find the source of that error.
How can I find out which two objects Pd is referring to with that outlet / inlet?
(The outlets of the subpatches are being wired into [dac~] in the main patch)
These subpatches USED TO work, until I tried to add Open Sound Control to them with udpreceive. And, like I say, they still do work, accepting the OSC if I run them on their own.
actually, Pd (>=0.43) became quite good at locating the source of errors, but unfortunately this is little known (and less documented).
if you get a findable error (usually those in red; and the error you get is one of them!), you can click on the error-line and it will take you to the object that complained (and select it)
the actual click-sequence is OS-dependent:
linux: Ctrl+LeftMouseButton
w32 : Ctrl+LeftMouseButton
OSX : ⌘+LeftMouseButton
alternatively you can get to the error, by clicking on the error-message and then hitting
Return
(Enter should work as well).
For assert macros in my iPhone project, I'm looking for a way to programmatically break into the debugger. On Windows (MSVC++), I can use __debugbreak() for this purpose. Invoking this function will stop my program, launch the debugger, and display a callstack of the line that called __debugbreak().
Is there anything similar to __debugbreak() for the iPhone? I've tried Debugger(), but that gives me a linker error.
Thanks,
Claus
edit
Turns out this also works:
#define Debugger() { raise( SIGINT ) ; }
I think it's the same principle.
I use this:
#define Debugger() { kill( getpid(), SIGINT ) ; }
I think it works
in the simulator and on the device.. no assembly required!
A helpful person on Apple's developer forum gave me the tip to use asm("trap") when running on the device and asm("int3") when running on the simulator. This makes the program break into the debugger if you started your programm in debug mode (Option-Command-Y).
(__builtin_trap() also breaks into the debugger, but you can't continue afterwards. assert(false) terminates the program with a message, but doesn't break into the debugger.)
First Add -DDEBUG to OTHER_CFLAGS on your debug target; this will define the DEBUG symbol when building a debug build.
Then add a simple assert macro to your prefix header:
#ifdef DEBUG
#define MyAssert(val) _MyAssert(val)
#else
#define MyAssert(val) do { } while(0)
#endif
Next create a _MyAssert function in a module somewhere:
#ifdef DEBUG
void _MyAssert(int expression)
{
if (expression == 0) {
NSLog(#"Assertion failed!"); // Place breakpoint here
}
}
#endif
Finally create a breakpoint on the NSLog line.
I just set a breakpoint at the place I want to stop. Xcode remembers breakpoints persistently, so any time I run the app with gdb, it'll stop at that point.
If you want to break on assertion failures, a good place to set a breakpoint is on the function objc_exception_throw, in the Objective-C runtime, which is what actually throws an exception. Use the Run > Show > Breakpoints window and double-click the "Double-click for symbol" row, then type the name.
Is there something wrong with the simple assert() macro? Something like
assert(pointerToTest != nil);
will halt your process at that point if the condition is not true. If running under the debugger, you'll be presented with a stack trace of calls that led to the failed assertion. If you want to trigger it every time you hit a certain code path, you could do
assert(false);
I find these assertions extremely useful for verifying that all IBOutlets are non-nil when a window or view is brought up from a NIB.
If you run your program in debug, your app should launch the debugger when it reaches an invalid assertion.
For it to stop, as Jens Alfke tried to say, you need to enable "Stop on Objective-C Exceptions" (under the Run menu).
For more info about debugging vs. releasing and asserts, read http://myok12.wordpress.com/2010/10/10/to-use-or-not-to-use-assertions/
While an ancient thread, found this while researching same topic for Xcode 7. What solved this for me was a feature called "Create Exception Breakpoint..."
Debug > Breakpoints > Create Exception Breakpoint...
This puts a special breakpoint in the Breakpoint Navigator (under View > Navigators > Show Breakpoint Navigator).
This breaks on the actual throw of the exception:
[ exception raise ]
without terminating your code execution. You can just continue if that is how your code is structured.
Double-clicking the break point marker next to "All Exception" lets you adjust where and how the exception break point stops:
Check out conditional breakpoints:
http://www.cocoabuilder.com/archive/message/xcode/2008/10/22/25358