You should not have to do that though. Someone should file an issue with Platformio. That is a bug.
1 Like
I was suspecting it 
Iām not sure I can fill a bug with enough information. Letās wait to see if itās something related to my own computer or if it happens to someone else.
(Edited from original context for migration purposes)
Agreed. So far we donāt have enough to go on to make a proper bug report.
Ideally weād at least want steps to reproduce the problem.
@HomineLudens
I recently encountered a similar issue after updating my nxplpc version and made an issue about it on the PlatformIO forums.
I mentioned it to @jonne and he said itās probably the same as this issue, and sure enough the fix that fixed this issue fixed my issue, so I think itās an issue with the particular nxplpc version.
I updated from (I think) v3.3.something to v3.4.1, so Iām guessing somewhere between those points the system broke.
I plan to follow it up assuming someone responds to my issue.
I may have to chase it on GitHub instead.
2 Likes
Good plan.
Iām changing my mind again. If you āInstallā a library through the manager in PIO, it gets copied to a .hidden directory.
Thereās no other way but to go seek that dir copy the files over to your project etc.
I fail to see this as easy for a beginner
Am I totally misunderstandin the lib manager because like this (libs essentially hidden) how am I going to explain copy-pasting the platform.ini etc? Help, any advice welcome.
I donāt think it was hidden on Windows, but I could be wrong.
(I have āshow hidden filesā turned on so I often donāt notice if somethingās supposed to be hidden.)
I can see that it would be hidden on Mac by default because of the leading dot (though Iād argue thatās a flaw in Macās file system design - making anything prefixed with a dot hidden by default instead of just using file attributes).
To copy which files?
platformio.ini isnāt hidden.
Though Iām guessing if Mac hides all folders begining with a dot then .pioenvs, .vscode, .travis.yml and .gitignore are probably all hidden on Mac?
Iām sure a script could get around that though.
E.g. maybe an āafter successful buildā script could copy the .bin file up to the project folder.
I think a lot of our problems with āhow to make this easy for beginnersā will be solvable by scripting.
Itās usually easier to explain āmove this file from this hidden folder into this other folderā to a computer than it is to a non-technical person.
Itās almost impossible to find something thatās easy for a beginner and still provides all the powertools that an advanced programmer would want/need.
Linking libraries in is difficult enough as it is even when you do know what youāre doing.
The Arduino IDE is easy for beginners to use, and we all know what most programmers think of the Arduino IDE - they bin it and use VSCode or Visual Studio instead.
Itās imperative that we have a cross-platform C++11-capable IDE available.
If we settle for something that isnāt cross platform, thatās a significant fraction of potential users gone.
If we settle for something that doesnāt have C++11 support then we have to be prepare to put up with all the people asking āwhy doesnāt this game compile? why does it say āerror: requires C++11ā?ā.
So far I think that even with these minor setbacks VSCode + PlatformIO is easier to use than a full scale IDE like EmBitz because you donāt have to worry about build targets,
you just have different projects instead of different build targets.
And often you can just copy a project and rename it without having to fiddle about with any IDE menus.
The only other alternative to VSCode at the moment is @FMangaās work on Code::Blocks.
We could perhaps look in to making some kind of makefile that will work with a larger IDE (e.g. Code::Blocks) or trying to get the custom GCC to work with something like VSCode,
but Iām expecting either of those will be more work than trying to improve what weāve already got.
(If EmBitz had been cross platform in the first place then we wouldnāt have to be worrying about any of this.)
Iāll look more into how PlatformIO works and how to script it if I get chance, but Iām trying to cut down on the number of projects I work on concurrently because I keep having to put things on hold.
I had stopped work on that since PlatformIO seamed to be the better solution. If itās insufficient for some reason, based on my brief experience rooting through the Code::Blocks source code, I think itād be easier to just make a VSCode plugin that includes GCC and the PokittoLib.
1 Like
I concur.
Lightweight editors like Atom and VSCode seem to be very popular with āhobbyistā programmers at the moment.
(I presume theyāre still mainly using heavyweight IDEs in business/āprofessionalā programing.)
I havenāt looked into how easy it is to make an extension for VSCode, but thatās a possibility if we canāt iron out the issues with PIO.
(Though so far apart from this issue thatās cropped up from updating the platform, I havenāt had any other problems with PlatformIO, so Iām not in a hurry to drop it.)
Making our own extension would still be a fair bit of extra work though. Weād have to decide if we were going to use just GCC for compiling or mix GCC and makefiles, and weād need to develop an easy to use project settings format so people could have custom compiler flags (because frankly neither bare compiler settings or makefiles are beginner friendly).
(Maybe we could even take a leaf out of PlatformIOās book and use SCons - programmatic Python scripts for build configuration.)
Iām not in a hurry either, but thatās because Iām happy using emacs+make. 
I did not mean to say we should be ditching PlatformIO. I only suggested making an extension as the alternative to Code::Blocks if itās ever decided that PlatformIO is a problem.
VSCode uses JSON files for configuration, that would be the more natural fit. Ideally, the extension would just handle the build process on its own and users wouldnāt have to mess with flags unless they really wanted to.
I didnāt take it that way.
I just wanted to clarify that my thoughts about making a VSCode extension shouldnāt imply that I want to get rid of PlatformIO.
I agree, itās probably one of the better alternatives.
Iām not a big fan of JSON because Iām always being bitten by missing commas or having too many commas,
but if an API for manipulating JSON is built-in and there arenāt built-in APIs for other options (e.g. XML, INI, YAML) then itāll probably have to be JSON.
But allowing Pokitto projects might need to include a config file (equivalent to the current platformio.ini) that specifies extra build flags, like -std=c++14 for people who want to go beyond C++11 and the dreaded -fpermissive to make Arduboy projects slightly easier to port.
Allowing such a file to be bundled with projects means that the experts can tweak the flags to their hearts content and the beginners wouldnāt have to worry - they can just rely on the config file that comes with the project they download to handle the flags for them.
(And of course, if the config doesnāt specify otherwise, default to -std=c++11.)
If thatās the case, how do you do source level debugging? Command-line gdb?
1 Like
Emacs has gdb support built in.
Edit: isnāt debugging a paid feature in platformio? I tested debugging in VSCode using the Cortex plugin, works OK.
1 Like
Ah? Sounds good. Sure you didnāt start the 30 day PIO pro trial by mistake?
I didnāt install PIO at all, yet. I keep meaning to do so, but I havenāt had much time lately.
1 Like
The documentation indicates that you need an account but doesnāt mention needing to pay to use the debugger.
The pricing page on their website on the other hand does seem to indicate that the debugger is a paid for feature.
Personally I donāt use a proper debugger very much because Iāve got used to not having one for AVR chips,
I tend to just print everything onto the screen when I run into a problem.
Even when writing C# I tend to print to the console for debugging more than I use the step feature.
This one? I would assume it could be used alongside PlatformIO.
I tend to rely on the debugger a lot. Partially because of habits from javascript, where you check for run-time errors instead of compile-time. Also, itās hard to use print to debug code that needs to run a few hundred thousand times per second (emulator cores).
Yup.
2 Likes
Usually I put a conditional statement in place that specifically looks for invalid values, even if I do use a proper debugger.
If I get the time Iāll look into whether it can be used alongside PlatformIO.
If I donāt get the time, maybe someone else reading this can check.