I'm trying to use the Atom IDE to make some Haxe project on my new Mac (as a Windows user, I'm discovering this world), and I install the package "haxe" to do this. Until there, all is perfect (great jobs to them \o/), and I can compile an swf :).
But I have a little problem, even with the "-debug", all my traces are in the swf, not on the output console (terminal if I run from it, or output panel on Atom). Maybe I've forget to do/install/init something ?
Related
I can not run any program.
As per the instruction I went to vscode dev.
Open up my repository to run a test program.
However, unfortunately, I can not run any of my programs.
I have checked the doctrine which said that only chrome and edge are supported.
But I can not run my program on the terminal window because it tells the code can only run on environments such as codespaces, and local vs code.
What do I miss so that the problem is occurring?
As VSCode(.dev) issue 166506 illustrates, you cannot access terminal from your browser probably because that menu entry was hidden/removed on purpose.
With VSCode 1.75 (Jan. 2023), it will be restored with an explanation.
I'm guessing we intentionally suppressed it because terminals can't run in the web, but participants were simply confused that it wasn't there without connecting its absence to the fact that vscode.dev was a browser application.
Additionally, RemoteHub contributes a welcome view for the terminal which is one of the primary ways we explain that users must continue working elsewhere to run or debug code, and the fact that the terminal is completely suppressed means one less opportunity for users to organically learn the limitations of vscode.dev through our welcome views.
The message is the one you saw:
Terminal are not available in the web editor.
To use the terminal, you will need to continue in an environment that can run code, like a codespace or local VS Code.
You can develop remotely, but you need to execute locally.
I initially thought that there was some way to be able to run Swift on Windows using emulators, or some other program that allowed Windows to compile and run Swift, but after browsing here a few times I learned that there is no(legal) way to do it. So how is it possible that you can do this at SwiftStub thru your internet browser?
You can check it out here:http://swiftstub.com/
Easily! They compile and run code on a Macintosh Server on their end, and just feed you the result in a web-based app. You're not running the code, they are. You just get to see the end result.
A couple of users are reporting that sometimes when my app crashes, the receive a message box like this:
The lldb command requires the command line developer tools. Would you like to install the tools now?
The crash (SIGABRT) looks like a race condition somewhere in my code. But why is it seemingly trying to launch lldb when this happens? I've never seen anything like this, it seems fairly isolated to a couple of users, and I can't reproduce locally - although I do have the developer tools installed.
It's almost like JIT debugging in a .NET, but I've never heard of that in Cocoa and my Google searches on this are fruitless.
Edit:
If I run ps we can see both the Problem Reporter and Install Command Line Developer Tools:
19582 0.0 0.4 2568032 33224 ?? S 10:22AM 0:00.72 /System/Library/CoreServices/Problem Reporter.app/Contents/MacOS/Problem Reporter
19579 0.0 0.2 2531748 13276 ?? S 10:22AM 0:00.16 /System/Library/CoreServices/Install Command Line Developer Tools.app/Contents/MacOS/Install Command Line Developer Tools
There is nothing else suspicious in the list. If I run ps with the -f switch, I can see that the parent process for Install Command Line Developer Tools is launchd.
The CrashReporter tool that Apple ships does not try to connect a debugger to crashed programs. There used to be an option to do that in Leopard or thereabouts (not on by default), but that capability was turned off by Mountain Lion (maybe even SnowLeopard). I don't think it is possible to install any Xcode with lldb in it on Leopard, so it seems unlikely it is an old Apple CrashReporter that is trying to hook the debugger up to the app. OTOH, it is possible to replace the Apple's CrashReporter tool with another that could do this, and some third party vendors do do this. Maybe that is what is going on?
If you got the users who see this to send you the output of "ps auwwx" when the dialog box is present, you might be able to spot the culprit.
We've got a fairly mature cross-platform game engine which we've had running on OSX for several years now without a hitch; we recently upgraded the game from SDL 1.2.15 to 2.0, and at some point in the conversion, I goofed something up and now we have a bizarre problem where the app launches just fine from the terminal, but when you launch the app from a double-click in the Finder, it just bounces once in the dock and just goes away.
We're baffled because insofar as I can tell, there's only a one-liner being printed in Console.app: Exited with code: 255 (naturally running from the terminal doesn't help here because we can't reproduce the problem there; the app runs fine when launched in a terminal).
So the only thing we can figure is it's either something we're goofing up in our main.cpp, or something we've hosed in how I set up the dylibs/frameworks. It's also possible that it's something to do with the working directory not being set right, but to the best of my abilities, I believe we're doing it right (regardless of your current working directory; the app attempts to forcibly set said directory to be in the Resources folder - this was necessary to get the game to launch, but I don't know if we're doing it wrong). This feels like a somewhat awkward fit for stackoverflow, for which I apologize, since it's not a simple "paste this code and ask what's wrong" job. I have two ways for you to reproduce it; firstly we are an open-source project, and you can get our source code (complete with a mac project file and all dependencies included in the repo, set up and ready-to-go exactly as I've perhaps erroneously created them), at our github page. The one change you'll need to do is open a file at the root level, named master-config.cfg, and remove the // comments from it (so the engine knows you want to launch a simple demo game shipped with the engine).
Alternately, I have a stripped down (~15mb zipped) binary you can directly download and try to run, if that's sufficient to diagnose the problem.
As said before, we're open-source, so we welcome any pull-requests for fixes!
You need to write a minimal Cocoa wrapper so that OS X will not SIGKILL you for not launching properly. I will give you a pull request with that wrapper.
I ssh into a linux VM which is setup remotely. I use Vim to write my code. For debugging however, I use netbeans through X11 which can sometimes be painfully slow. I tried using gdb buts its an efficiency killer. I love to hover over my variable and get to now their value rather that doing p variable_name , plus I like see and navigate through the code. Is there something light simple gui based debugging tool I can use. I have tried to use clewn http://clewn.sourceforge.net/ , but that doesnt work because it has a missing netbeans_intg feature. Is there any other similar vim gui based debugging tool ?
You can try ddd
which is a gui for gdb, I think it's lighter than netbeans.
cgdb is an interface to gdb but it is not a graphical one. It does not offer the possibility of hovering over a variable, but it shows you a window with the source code.
Well, I was in sort of your situation sometime ago, and you can have a look at my question about using gdb with remote sources.
First of all, your problem with netbeans_intg feature is related to vim which has been compiled with no support for it. If you can rebuild vim yourself, you can then enable it. Otherwise, as you can see in the answer that I gave myself to my question, you can leverage clewn's remote-vim capabilities.
In a nutshell, you can have a "local" vim (i.e. on a desktop/laptop machine presumably), which must still be built with netbeans_intg support, but now it is a vim under your complete control (i.e. it's on "your" machine), while clewn will run on the linux host where gdb and your debuggee will run.
You can then keep the source files on your desktop/laptop and have the remote clewn sort of "drive" your local vim to the proper source files while debugging.
IOW: clewn will get information out of gdb to know exactly which file/line you're into and connect to remote vim and tell it: "hey, go grab this file and show it around this line", highlighting current line, breakpoints etc.
This is a great solution for when you have far-away deployed systems and you need to debug them with minimum impact on the host where they are running, and presumably no option to transfer there all of your source files.
I don't know if this fits in any way with what you're trying to do, but it did really change things for me.
Hth,
Andrea.
Check out GDB server. Theoretcially, you should be able to start gdb on your linux machine in server mode and connect via GUI of your choice. As long as that GUI supports remote gdb connections, which Netbeans does.