Atom Errors not working


I’m trying for the first time to use atom as a c++ compiler on windows, but when i try to F5 it gives me a glitchy error. it opens the red window with the little fire but it does it partially, its like a red line and i can only see the fire symbol and the x to close it.
And i just set up IMGW so it could be a problem related to it, i dont know.


A screenshot would be helpful.


Hi, I’m a friend of Sigmy, his account got “temporarely placed on hold” and so he can’t show you the screenshot, I’m here to do that.


The package @Sigmy is using is spawning the error message, and the fact that the error message doesn’t have any content indicates that the person who wrote the package forgot to fix it. Based on this flaw, I would recommend looking for a different package. I can help troubleshoot it if @Sigmy provides the name of the package. Regardless of which package it is, the first step will be the same: open the Windows command line and run the command g++ by itself. You should receive an error about not having an input file. If you receive an error about a command not being found, then something is missing from the installation of MinGW (either you didn’t install the compiler or you need to update your PATH).


His account it’s still placed on hold, I copied and pasted what he wrote me for you:
The package I’m using is gpp-compiler and the reaction to the g++ command in cmd is “fatal error: no input files”, Thank you for your dedication!


The next step of testing is to download the termination package (or any terminal package you prefer) and run the g++ command again from inside Atom. This is important because there are some circumstances where Atom’s local environment (remember that PATH is one of the variables that make up the program’s environment) is not the same as the system’s. This may be because Atom is running under a different user than MinGW was installed for (unlikely, especially on Windows, and you would know about it) or Atom has not picked up the new environment (you need to restart it) or you are starting Atom inside a virtual environment that has a different PATH (also unlikely, and might be incorrect if the devs thought about that and told Atom to pick up the canonical environment on open, but I think I’m right about how it works).

If g++ works inside Atom, then the issue is with the package and we can take a look at its code to see what it’s trying to do when you hit f5.

To soapbox a bit: this is a really common problem that affects mostly new Python, C++, and Java coders who might have seen an online tutorial that assumed they knew more about the operating system basics than they actually do, and don’t have (or don’t want to ask) a formal institution with industry professionals on staff. Self-teachers, mostly, of whom I am one. The principles involved in the troubleshooting process for this problem (and all of the identical threads on this forum) are useful things to know about every operating system and, barring some stylistic differences, are almost identical across all major OSes. Pay close attention and follow up by Googling things I mention because this process will teach you how the different programs on your computer speak to each other. It’s not at all mysterious, and once you know the language you have significantly greater power. For many open-source coding tools, this kind of knowledge is an absolute necessity because the people who wrote those tools grew up on it. In this case, it’s very useful for figuring out what’s going wrong with a piece of software that hasn’t been updated in two years and only gets installed because the Atom package interface doesn’t have good quality control and newbies think that its name sounds authoritative.

If I had my way, everyone would learn a tiny bit of info about how to use the command line and download process-palette, but it’s hard to motivate people to learn something that seems so arcane until they run into an issue like @Sigmy’s where a two-year-old abandonware black box is misbehaving and the exact same arcane knowledge used to set up batch scripts (of which process-palette is a super-modern and streamlined version, essentially) becomes the only way to figure out what’s going on. It’s most likely that the package used to work and doesn’t any more because Atom has changed too much. Getting a definitive answer on that would require digging into one person’s code (which, from looking at it, is fairly legible; so it wouldn’t be that hard) and figuring out exactly what conditions trigger the break. If you take things into your own hands with process-palette, you can take maybe twenty minutes to figure out everything that needs to happen (if you did it by yourself), then have an Atom command that compiles your active code file.

See? It’s that easy. And it took me less than 20 minutes because I knew what document to look for on Google. Out of all the time I’ve spent writing this post, 90% of it has been on ranting about the state of computer education in the 21st century. :smiley: