I'm with Heater and SRLM on the issue of warnings: every warning is there for a reason. It's the compiler saying "There's that word again, I don't think it means what you think it means".
Perhaps in situations where you're just starting to learn about C they can get annoying (and if the native language of the student is something other than English, it's an extra complication). But if students are serious about programming and they are planning to do it in a professional setting, they should be prepared to fix all warning by changing their programming, not by turning the warning off. Every single environment where I worked with C/C++ professionally required that code could be compiled with 0 warnings.
Learning to fix warnings such as type mismatches, absent function prototypes and assignments in if/while expressions is a required skill and in the end, will give you fewer frustration than a program that doesn't work and you don't know why.
I have mixed feelings about turning on all warnings when teaching C to someone with no knowledge of C. There are good reasons to ignore some warnings early on.
According to the gcc man page, there are over 100 warnings that can be enabled. -Wall only turns on 28 warnings for common coding errors. I think it's precisely what is needed when learning C. It will help the novice programmer debug his program when it doesn't work the way it should be working.
I definitely think it's important to have most warnings on, but GCC is a bit pedantic in some cases, so there are a few that could be left off.
You can adjust which warnings will be active on the command line or with #pragma's in a header someplace, and I would suggest at least going through and enabling ones that are common beginner mistakes, like using = instead of == in the comparison on if's.
In general, it's better for a C/C++ programmer to be aware of and able to fix warnings from early on.
According to the gcc man page, there are over 100 warnings that can be enabled. -Wall only turns on 28 warnings for common coding errors. I think it's precisely what is needed when learning C. It will help the novice programmer debug his program when it doesn't work the way it should be working.
The number of available warning that gcc can generate is truly impressive. While I don't think it's a good thing to set gcc to "-Wall" when a person is writing the first programs I do agree that warnings should be "turned on" and acted on fairly soon. Let the beginner to C compile and run the "hello world" program without having to learn about return, etc first. After the first couple 3-4 intro type programs then warnings can and should be enabled.
I just took a look at the simple start program that Andy included as part of his tutorial on C and it omits the return instruction as well and should generate a warning!! A quick scan shows a number of programs that should generate warnings.
In the old days you could throw any old line noise at a C compiler and it would faithfully compile it for you. Program might not run at all but at least it compiled. For that reason they invented the "lint" program to pick up common mistakes in your source.
Modern standards and compilers are far more picky about errors and warnings and we don't need lint program any more.
No, if you want to try and run line noise now a days you have to use JavaScript. JS will faithfully run whatever you throw at it, no type checking or other such sissy stuff.
Of course your JS may not do what you expect so they invented the jslint program to pick up common mistakes in your source.
I just took a look at the simple start program that Andy included as part of his tutorial on C and it omits the return instruction as well and should generate a warning!!
As predicted Bill Robinson ....
If you specify -std=c99 and -Wall there is no warning.
Look folks. Parallax has gone to great lengths to provide a solution. I'm pretty sure that they have gotten the message about warnings already. There are valid reasons for not thinking about warnings in an introductory class, and there are valid reasons for turning on all warnings. Anyone with any experience as is the case with most posters here will understand why it's important to have 0 warnings in the code. People with 0 experience and desire just want to get started.
The professors can choose what they think is important. Having to tell the class to enable warnings may actually have benefits.
Look folks. Parallax has gone to great lengths to provide a solution. I'm pretty sure that they have gotten the message about warnings already. There are valid reasons for not thinking about warnings in an introductory class, and there are valid reasons for turning on all warnings. Anyone with any experience as is the case with most posters here will understand why it's important to have 0 warnings in the code. People with 0 experience and desire just want to get started.
I'm not trying to second guess anybody here. Rather, as part of the volunteer support network, I want to make sure that as much as possible is given to the beginner before they try posting on the forums. It's less work for all of us that way, IMHO.
ps: I'm also not trying to be antagonistic, just pointing out a contrasting view with, hopefully, some thought provoking arguments. Sorry if it came off as aggressive.
If you specify -std=c99 and -Wall there is no warning.
Look folks. Parallax has gone to great lengths to provide a solution. I'm pretty sure that they have gotten the message about warnings already. There are valid reasons for not thinking about warnings in an introductory class, and there are valid reasons for turning on all warnings. Anyone with any experience as is the case with most posters here will understand why it's important to have 0 warnings in the code. People with 0 experience and desire just want to get started.
The professors can choose what they think is important. Having to tell the class to enable warnings may actually have benefits.
I think the two of us agree on suppressing warnings for a little while for someone being exposed to C for the first time. In my case (I'm not speaking for anyone else) I've found that warnings are indicative of a logic bug and should be eliminated. To that end I've set "-Wall" to be my standard when compiling any code. Every time I choose to ignore a warning in other than the most trivial of programs I've lived to regret it!!
In case my comments have been misunderstood none of my comments were intended as a dig on parallax or any of the people working on the gcc port or simple-IDE. That also includes Andy and the work he's been doing on the Learning C project he's taken on.
4x5n and SRLM, I think we're all good. You folks are used to me by now.
I just don't want Andy to become unnecessarily stressed. I'm amazed by Andy, and am proud of his work so far.
I consider most warnings to be very valuable and use -Wall in my own work (that's why All Warnings that Stephanie mentioned is an option in SimpleIDE). Unused variable warnings really irk me though if i get a failure (-Werror) after 23 minutes into a full build where I'm debugging a run-time error in a function in my day job (can you imagine my laptop crashing through the third floor window? I visualize it often!) I just ignore some warnings when I know they aren't hurting anything and there is no reason or no reasonable way to deal with them. Ya, I can dig deeper.
What I really want for Christmas is to learn how to build a very simple library... did I miss it?
Andy will be preparing a tutorial later. For now you can dig into one of the libraries for an example. The most important factors are that a library should be in a folder called libprojectname (replace projectname with your project name), and the project should be libprojectname.side. Within libprojectname will be a libprojectname.c file. The Project Manager -> Library tab should also have "Create Project Library" checked. It would be good to keep all library .c files as small as possible as a general practice. The P2 branch will trim dead code thanks to work done by (Cody) SRLM.
What I most enjoy about the Propeller is the feeling that I am actually talking to the machine. This happens most
in PASM... but Spin gets me there with waitcnt etc.
Propeller GCC has all those propellery things like waitcnt and cognew. They are just hidden and maintained on some shelves for your benefit. A good librarian can be a treasure.
Andy will be preparing a tutorial later. For now you can dig into one of the libraries for an example. The most important factors are that a library should be in a folder called libprojectname (replace projectname with your project name), and the project should be libprojectname.side. Within libprojectname will be a libprojectname.c file. The Project Manager -> Library tab should also have "Create Project Library" checked. It would be good to keep all library .c files as small as possible as a general practice.
In the mean time until Andy makes a more comprehensive tutorial, there is a terse section with screen captures named "How to Create a Simple Library" on page 27 of the SimpleIDE User Guide v0.9.26. The next revision will slightly expand on this to mention that Steps 1-7 create a library archive folder for a single memory model, and to repeat from Step 4 for additional memory models. Furthermore, the Board Type setting does not affect the library created.
In the mean time until Andy makes a more comprehensive tutorial, there is a terse section with screen captures named "How to Create a Simple Library" on page 27 of the SimpleIDE User Guide v0.9.26. The next revision will slightly expand on this to mention that Steps 1-7 create a library archive folder for a single memory model, and to repeat from Step 4 for additional memory models. Furthermore, the Board Type setting does not affect the library created.
I know I'm going off on a tangent here...
I don't know how difficult this would be, but I wonder if there should be a feature so that libraries CAN be board-related. For my own "Propeddle" project, I'm writing a library so that users can build an application that uses the hardware on my board. There's no reason to use the library on any other board (you really need all the hardware that my board provides), and there's no reason to use my hardware with any other libraries unless someone writes a replacement for what I'm writing.
I can easily imagine a system of libraries that provide APIs for hardware that's on specific boards, by associating a board.cfg file with a template for a project file, with libraries (and C source files with #include directives) that correspond to the hardware for that board.
When the user creates a new project, SimpleIDE can give a choice of either a blank project, or a list of project templates that are suggested by the installed board.cfg files. Switch your board to the Activity Board and the suggestions would be all about SD cards, XBees, A/D / D/A conversion, playing and recording sounds, etc. Switch your board to the PropBOE, and you get project templates that include robots and video.
Basically, that way, SimpleIDE would "know what you have" and "suggests something you can make" with it. I think that would be really valuable.
When the user creates a new project, SimpleIDE can give a choice of either a blank project, or a list of project templates that are suggested by the installed board.cfg files. Switch your board to the Activity Board and the suggestions would be all about SD cards, XBees, A/D / D/A conversion, playing and recording sounds, etc. Switch your board to the PropBOE, and you get project templates that include robots and video.
Basically, that way, SimpleIDE would "know what you have" and "suggests something you can make" with it. I think that would be really valuable.
===Jac
Jac,
I've talked with Ken about doing something similar to this for over a year now. While this is not a usage *exactly* like you mention, it is with a very similar spirit. The idea is to drag/drop devices from a "library panel" to a "project panel" ... the existing board.cfg mechanism can support that. I.e. a board.cfg editor .... What do you think?
I've talked with Ken about doing something similar to this for over a year now. While this is not a usage *exactly* like you mention, it is with a very similar spirit. The idea is to drag/drop devices from a "library panel" to a "project panel" ... the existing board.cfg mechanism can support that. I.e. a board.cfg editor .... What do you think?
It looks like the newest version of SimpleIDE has -wall by default:
SimpleIDE spinside branch changes:
* Better Zip and USB SDCard target support for projects with libraries using temporary filesystem. * Enable 32bit doubles and all warnings by default for new Project View projects.
* Project View new project main.c starts with 2 space indents.
* Enable programming with OpenSpin removes need for BSTC.
* Global SimpleIDE settings are cleared on install and uninstall.
PropellerGCC release_1_0 branch changes:
* Use OpenSpin during build process instead of BSTC.
* Include fix for EEPROM boot with pruning enabled.
* Changed optimization that caused the pow() function to misbehave.
The Mac installer leaves the SimpleIDE preferences so that BSTC is still the compiler. If you change "bstc.osx" to "openspin" in the Spin files preferences, everything seems to work fine.
The Mac installer leaves the SimpleIDE preferences so that BSTC is still the compiler. If you change "bstc.osx" to "openspin" in the Spin files preferences, everything seems to work fine.
I'm guessing at this point that the properties are not being cleared on install the way they should be. Did you get an "About" window on first startup after install?
Comments
Perhaps in situations where you're just starting to learn about C they can get annoying (and if the native language of the student is something other than English, it's an extra complication). But if students are serious about programming and they are planning to do it in a professional setting, they should be prepared to fix all warning by changing their programming, not by turning the warning off. Every single environment where I worked with C/C++ professionally required that code could be compiled with 0 warnings.
Learning to fix warnings such as type mismatches, absent function prototypes and assignments in if/while expressions is a required skill and in the end, will give you fewer frustration than a program that doesn't work and you don't know why.
===Jac
You can adjust which warnings will be active on the command line or with #pragma's in a header someplace, and I would suggest at least going through and enabling ones that are common beginner mistakes, like using = instead of == in the comparison on if's.
In general, it's better for a C/C++ programmer to be aware of and able to fix warnings from early on.
The number of available warning that gcc can generate is truly impressive. While I don't think it's a good thing to set gcc to "-Wall" when a person is writing the first programs I do agree that warnings should be "turned on" and acted on fairly soon. Let the beginner to C compile and run the "hello world" program without having to learn about return, etc first. After the first couple 3-4 intro type programs then warnings can and should be enabled.
I just took a look at the simple start program that Andy included as part of his tutorial on C and it omits the return instruction as well and should generate a warning!! A quick scan shows a number of programs that should generate warnings.
Modern standards and compilers are far more picky about errors and warnings and we don't need lint program any more.
No, if you want to try and run line noise now a days you have to use JavaScript. JS will faithfully run whatever you throw at it, no type checking or other such sissy stuff.
Of course your JS may not do what you expect so they invented the jslint program to pick up common mistakes in your source.
I get deja vu sometimes....
As predicted Bill Robinson ....
If you specify -std=c99 and -Wall there is no warning.
Look folks. Parallax has gone to great lengths to provide a solution. I'm pretty sure that they have gotten the message about warnings already. There are valid reasons for not thinking about warnings in an introductory class, and there are valid reasons for turning on all warnings. Anyone with any experience as is the case with most posters here will understand why it's important to have 0 warnings in the code. People with 0 experience and desire just want to get started.
The professors can choose what they think is important. Having to tell the class to enable warnings may actually have benefits.
I'm not trying to second guess anybody here. Rather, as part of the volunteer support network, I want to make sure that as much as possible is given to the beginner before they try posting on the forums. It's less work for all of us that way, IMHO.
ps: I'm also not trying to be antagonistic, just pointing out a contrasting view with, hopefully, some thought provoking arguments. Sorry if it came off as aggressive.
I think the two of us agree on suppressing warnings for a little while for someone being exposed to C for the first time. In my case (I'm not speaking for anyone else) I've found that warnings are indicative of a logic bug and should be eliminated. To that end I've set "-Wall" to be my standard when compiling any code. Every time I choose to ignore a warning in other than the most trivial of programs I've lived to regret it!!
In case my comments have been misunderstood none of my comments were intended as a dig on parallax or any of the people working on the gcc port or simple-IDE. That also includes Andy and the work he's been doing on the Learning C project he's taken on.
I just don't want Andy to become unnecessarily stressed. I'm amazed by Andy, and am proud of his work so far.
I consider most warnings to be very valuable and use -Wall in my own work (that's why All Warnings that Stephanie mentioned is an option in SimpleIDE). Unused variable warnings really irk me though if i get a failure (-Werror) after 23 minutes into a full build where I'm debugging a run-time error in a function in my day job (can you imagine my laptop crashing through the third floor window? I visualize it often!) I just ignore some warnings when I know they aren't hurting anything and there is no reason or no reasonable way to deal with them. Ya, I can dig deeper.
Andy will be preparing a tutorial later. For now you can dig into one of the libraries for an example. The most important factors are that a library should be in a folder called libprojectname (replace projectname with your project name), and the project should be libprojectname.side. Within libprojectname will be a libprojectname.c file. The Project Manager -> Library tab should also have "Create Project Library" checked. It would be good to keep all library .c files as small as possible as a general practice. The P2 branch will trim dead code thanks to work done by (Cody) SRLM.
Propeller GCC has all those propellery things like waitcnt and cognew. They are just hidden and maintained on some shelves for your benefit. A good librarian can be a treasure.
In the mean time until Andy makes a more comprehensive tutorial, there is a terse section with screen captures named "How to Create a Simple Library" on page 27 of the SimpleIDE User Guide v0.9.26. The next revision will slightly expand on this to mention that Steps 1-7 create a library archive folder for a single memory model, and to repeat from Step 4 for additional memory models. Furthermore, the Board Type setting does not affect the library created.
I know I'm going off on a tangent here...
I don't know how difficult this would be, but I wonder if there should be a feature so that libraries CAN be board-related. For my own "Propeddle" project, I'm writing a library so that users can build an application that uses the hardware on my board. There's no reason to use the library on any other board (you really need all the hardware that my board provides), and there's no reason to use my hardware with any other libraries unless someone writes a replacement for what I'm writing.
I can easily imagine a system of libraries that provide APIs for hardware that's on specific boards, by associating a board.cfg file with a template for a project file, with libraries (and C source files with #include directives) that correspond to the hardware for that board.
When the user creates a new project, SimpleIDE can give a choice of either a blank project, or a list of project templates that are suggested by the installed board.cfg files. Switch your board to the Activity Board and the suggestions would be all about SD cards, XBees, A/D / D/A conversion, playing and recording sounds, etc. Switch your board to the PropBOE, and you get project templates that include robots and video.
Basically, that way, SimpleIDE would "know what you have" and "suggests something you can make" with it. I think that would be really valuable.
===Jac
Jac,
I've talked with Ken about doing something similar to this for over a year now. While this is not a usage *exactly* like you mention, it is with a very similar spirit. The idea is to drag/drop devices from a "library panel" to a "project panel" ... the existing board.cfg mechanism can support that. I.e. a board.cfg editor .... What do you think?
Let's start a new thread about this: http://forums.parallax.com/showthread.php/148080
===Jac
But I start to worry. rjo__ has been napping for five days now.
BTW, if you downloaded the Windows version 0-9-45 before today, you got an older package than was intended (0-9-44).
Please get the latest Windows SimpleIDE 0-9-45-1 here. The Mac version was posted correctly.