A funny thing happened at the Parallax Saloon today.......tutorials were on the menu.
mindrobots
Posts: 6,506
Three programmers walked into the bar for some drinks.
The Spin programmer had been to the bar a lot and decided to order the first round. The waitress took the order and went off to get the drinks.
They waited a long while and when no drinks showed up, the PropForth programmer flagged down a waitress and gave it a try. It took a while but that was OK since the drink descriptions were very elegant and they had fun interacting with the waitress.
The first two rounds showed up at the same time. They asked the first waitress what happened and she said she hadn't written anything down but she remembered a similar order a month or so ago, so she and the bartender searched through all the tickets until they found the order she remembered. After that it was real easy to make the drinks!! She wrote it down again on a new ticket.
After a while, it was time for the C programmer to order. Well, everybody heard him and surely understood him and rather quickly, the drinks showed up - 7 different drinks in 3 different orders from 3 different waitresses. The drinks were all a bit different since each of the waitresses had slightly different standards.
Which brings us to tutorials for PropGCC and SimpleIDE on the Propeller - hopefully, my tutorials are better than my jokes.
I'm not a C programmer (I don't particularly enjoy the language) and the last time I programmed for money I used OS1100 MASM and some new-fangled higher level language called PLUS (Sperry Univac's version of PL/1 for their system level programming) but for some reason, I stepped forward or everybody else stepped back. I'm language agnostic - I write bad code in multiple languages. I won't evangelize the one true language, so no need to fear enlightenment - you can't be dragged to enlightenment, Forth will be there when you find it and need it! So here we are. If at anytime, anyone wants to take over the tutorial writing task, just let me know, I'm thick skinned and will step down gladly.
Now, you folks out there are possibly new to C, maybe new to the Propeller, maybe experienced Propeller and Spin/PASM programmers and/or experienced C programmers. Quite an audience present two volatile topics to - programming languages and micro-controller details. It's like talking religion AND politics in a crowded room. I don't envy me!
As Bean' thread indicates, ask a C question to several experts and you get the correct answer, several opinions and some interesting related stories. Brian gave the correct answer and a solution - GCC defaults to ANSI-C89 standards - the construct Bean was trying was added in the ANSI-C99 standard so the -std=c99 flag needs to be used or the construct needs to be changed to fit the c89 standard.
In the tutorials, I will try to present the correct and hopefully best-practice way to do something. If you don't agree with the way I use braces, the number of characters I indent, the way I write variables names, etc.....well, too bad. If the code doesn't compile or doesn't accomplish the stated task, then it's an issue. If it doesn't look pretty or fit some expert's source code practices, too bad.
If you come away from the tutorial understanding the concepts it was meant to explain, then you're the winner!! You can take that knowledge and format it any way you want!
Because of the potential audience, things are going to start out slow and you guys are quickly going to get ahead of me. It's much easier to read these than it is to write these!
Feedback, feedback, feedback - PLEASE!!! If you do or don;t like the way I'm going about this, let me know. If it's constructive and can help improve the tutorials, I'm all for it - if you don't like the way I write code, well, we've already discussed that. If I'm technically incorrect, by all means, I'll change it. If there are several way to accomplish the same thing (yes, this IS programming, after all), then we may just agree to disagree and you can write your tutorial your way.
Suggestions and comments may not immediately help you and your learning but since this is for the community, your input will make the overall documentation better.
Until I get some feedback on what works for folks, the styles and presentations may wander around a bit. I can always go back and rewrite the misfits in the popular style.
Early on, I wrote a "test tutorial" - The Toggle Tutorials to provide a step by step tutorial for the various toggle programs in the propgcc demo package. Quite a bit of C, PropGCC and Propeller architecture can be learned from going through these demos. The intent is to go through each toggle demo and describe the details and concepts as they appear in the programs. By the end, you can pretty much make the Propellers do what you want with PropGCC.
As an experiment, I tried merging the code and tutorial together creating a heavily documented program without any accompanying text. Each program would build on the concepts from the previous program. This got mixed reviews. First Blinky Second Blinky Third Blinky (These are easier and faster to create!
)
Currently, I'm some place in the middle with a well documented program and some supporting text. (examples coming)
Thanks for putting up with me. Let me know if any of it fits your needs and I will continue on the journey. If it's of no interest, I'll go back to the monastery and work on PropForth..........ohhhhhhmmmmmmm.
The Spin programmer had been to the bar a lot and decided to order the first round. The waitress took the order and went off to get the drinks.
They waited a long while and when no drinks showed up, the PropForth programmer flagged down a waitress and gave it a try. It took a while but that was OK since the drink descriptions were very elegant and they had fun interacting with the waitress.
The first two rounds showed up at the same time. They asked the first waitress what happened and she said she hadn't written anything down but she remembered a similar order a month or so ago, so she and the bartender searched through all the tickets until they found the order she remembered. After that it was real easy to make the drinks!! She wrote it down again on a new ticket.
After a while, it was time for the C programmer to order. Well, everybody heard him and surely understood him and rather quickly, the drinks showed up - 7 different drinks in 3 different orders from 3 different waitresses. The drinks were all a bit different since each of the waitresses had slightly different standards.
Which brings us to tutorials for PropGCC and SimpleIDE on the Propeller - hopefully, my tutorials are better than my jokes.
I'm not a C programmer (I don't particularly enjoy the language) and the last time I programmed for money I used OS1100 MASM and some new-fangled higher level language called PLUS (Sperry Univac's version of PL/1 for their system level programming) but for some reason, I stepped forward or everybody else stepped back. I'm language agnostic - I write bad code in multiple languages. I won't evangelize the one true language, so no need to fear enlightenment - you can't be dragged to enlightenment, Forth will be there when you find it and need it! So here we are. If at anytime, anyone wants to take over the tutorial writing task, just let me know, I'm thick skinned and will step down gladly.
Now, you folks out there are possibly new to C, maybe new to the Propeller, maybe experienced Propeller and Spin/PASM programmers and/or experienced C programmers. Quite an audience present two volatile topics to - programming languages and micro-controller details. It's like talking religion AND politics in a crowded room. I don't envy me!
As Bean' thread indicates, ask a C question to several experts and you get the correct answer, several opinions and some interesting related stories. Brian gave the correct answer and a solution - GCC defaults to ANSI-C89 standards - the construct Bean was trying was added in the ANSI-C99 standard so the -std=c99 flag needs to be used or the construct needs to be changed to fit the c89 standard.
In the tutorials, I will try to present the correct and hopefully best-practice way to do something. If you don't agree with the way I use braces, the number of characters I indent, the way I write variables names, etc.....well, too bad. If the code doesn't compile or doesn't accomplish the stated task, then it's an issue. If it doesn't look pretty or fit some expert's source code practices, too bad.
If you come away from the tutorial understanding the concepts it was meant to explain, then you're the winner!! You can take that knowledge and format it any way you want!
Because of the potential audience, things are going to start out slow and you guys are quickly going to get ahead of me. It's much easier to read these than it is to write these!
Feedback, feedback, feedback - PLEASE!!! If you do or don;t like the way I'm going about this, let me know. If it's constructive and can help improve the tutorials, I'm all for it - if you don't like the way I write code, well, we've already discussed that. If I'm technically incorrect, by all means, I'll change it. If there are several way to accomplish the same thing (yes, this IS programming, after all), then we may just agree to disagree and you can write your tutorial your way.
Suggestions and comments may not immediately help you and your learning but since this is for the community, your input will make the overall documentation better.
Until I get some feedback on what works for folks, the styles and presentations may wander around a bit. I can always go back and rewrite the misfits in the popular style.
Early on, I wrote a "test tutorial" - The Toggle Tutorials to provide a step by step tutorial for the various toggle programs in the propgcc demo package. Quite a bit of C, PropGCC and Propeller architecture can be learned from going through these demos. The intent is to go through each toggle demo and describe the details and concepts as they appear in the programs. By the end, you can pretty much make the Propellers do what you want with PropGCC.
As an experiment, I tried merging the code and tutorial together creating a heavily documented program without any accompanying text. Each program would build on the concepts from the previous program. This got mixed reviews. First Blinky Second Blinky Third Blinky (These are easier and faster to create!
)Currently, I'm some place in the middle with a well documented program and some supporting text. (examples coming)
Thanks for putting up with me. Let me know if any of it fits your needs and I will continue on the journey. If it's of no interest, I'll go back to the monastery and work on PropForth..........ohhhhhhmmmmmmm.
Comments
...must...resist...urge...other...projects..need..to..be..finished.. (Free time currently being spent in BASIC) -- temped....
--Steve
char *strcpy(char *dst_orig, const char *src) { char *dst = dst_orig; while ((*dst++ = *src++) != 0) ; return dst_orig; }Why is the second parameter prefixed with "const" ?Bean
Type modifier "const" just says that src should be read-only. It is optional in this case.
Bean
The contents are const not the pointer (address). Const is probably a distraction in the tutorial.
Here's a nice desciption of it: http://duramecho.com/ComputerInformation/WhyHowCppConst.html
Note the middle of the page where it talks about the differences between const char *foo, and const * char foo.
The same function could be re-written with or without const as:
char *strcpy(char *dst, char *src) { int n = 0; do { dst[n] = src[n]; } while (src[n++] != 0); // n++ includes the 0, ++n does not. // we should include the 0 since that's in the definition of "C string" return dst; }BTW, strcpy is probably not a good name to use since that's defined in the standard C library.
Kicking and screaming, I WILL learn this damn C language...So help me I will.
Bean
Already said that, though maybe not quite as concisely.