It does indeed read the tape and print it up on the paper. The paper scrolls, and over-printing works properly. It also takes keyboard input and prints it on the paper and punches it on the attached perforator.
The hardest bit has been getting the keyboard to work properly. You have to select "letters" or "figures" using the two Ctrl keys and ignore key presses from characters of the wrong shift.

PeterO

Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

PeterO wrote:Adding a totally pointless prototype just before the actual function stops the warning message!
From gcc manual:

gcc manual wrote:
-Wmissing-prototypes (C and Objective-C only)

Warn if a global function is defined without a previous prototype declaration. This warning is issued even if the definition itself provides a prototype. Use this option to detect global functions that do not have a matching prototype declaration in a header file.

I think that the compiler is correct in complaining. What if you were to call this function from another file? Then you would need the prototype (in a header file #Included by both). The real issue here is that you are writing global functions. If you really are taking care to define the function before using it in the same file, then presumably the function is only intended to be used in that file, and should be declared static. What the compiler is really complaining about, and rightly so, is that, "this function could be used globally, but there's no prototype allowing that to be done safely".

PeterO wrote:Adding a totally pointless prototype just before the actual function stops the warning message!
From gcc manual:

gcc manual wrote:
-Wmissing-prototypes (C and Objective-C only)

Warn if a global function is defined without a previous prototype declaration. This warning is issued even if the definition itself provides a prototype. Use this option to detect global functions that do not have a matching prototype declaration in a header file.

I think that the compiler is correct in complaining. What if you were to call this function from another file? Then you would need the prototype (in a header file #Included by both). The real issue here is that you are writing global functions. If you really are taking care to define the function before using it in the same file, then presumably the function is only intended to be used in that file, and should be declared static. What the compiler is really complaining about, and rightly so, is that, "this function could be used globally, but there's no prototype allowing that to be done safely".

Stefan
(programming in C since '86)

I take your point about making functions static if they aren't used globally, but I still prefer the compiler not to complain about things that could be a problem until it actually finds some code where they are an problem. It should not be trying to second guess about code it hasn't seen ! It is essentially saying "You've defined this function as a global, but I've not seen it used that way yet but I'm still going to complain about it even if you don't ever use it that way".

PeterO

Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

jahboater wrote:
I too think you should declare everything static, unless it isn't.

MY current project opens multiple windows , and each window's code is in a separate source file, so I've already been getting into the habit of declaring things like widget event handlers as statics because each window has some handlers with common names (but which do different things in different windows).

PeterO

Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

It looks useful, but I found some TL:DR threads about problems with using it. Does anyone have real experience (good or bad) with using it to replace traditional "#ifndef X/#define X/ #endif X" guards ?
PeterO

Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

Cool - impressive. Its hard sorting out a big chunk of code for the first time, but easy afterwards.

Your code is probably too good to have much global data, but any thats not declared static gets treated as volatile which is horrendously inefficient, it keeps loading and saving it to and from memory - in case its modified outside the TU.

jahboater wrote:Your code is probably too good to have much global data, but any thats not declared static gets treated as volatile which is horrendously inefficient, it keeps loading and saving it to and from memory - in case its modified outside the TU.

I would reserve any comments like that until you've seen some of my code I don't really do "OO" so quite a lot of state information gets held as globals, though now many of these have at least become static and scoped to the appropriate source file.

PeterO

Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

jahboater wrote:Your code is probably too good to have much global data, but any thats not declared static gets treated as volatile which is horrendously inefficient, it keeps loading and saving it to and from memory - in case its modified outside the TU.

Not quite. Global variables not declared static are not treated as volatile in any way.

Global variables are still externally visible (unless declared static) so require saving to memory (and loading from memory) because another function can read/write them. Depending on optimisation levels and complexity of code the compiler can avoid re-reading from memory if it believes nothing can have changed a cached version held in a register, likewise it can coalesce multiple writes into one if it is sure no other function can alter it inbetween. This is totally different from volatile which states that the variable could change at any time outside of the current code so the compiler cannot optimise access at all hence it always needs to read and write the values to memory. Even a back-to-back var++;var++ cannot be coalesced on a volatile variable but more than likely will on normal global variables (static or not) unless you have optimisations off.

I wasn't going to comment on your use of "volatile" because I don't know enough about ARM assembler to be able to look at the compiler output to know if what you said was correct or not. I could have done it on this AMD64 desktop but again I didn't know if the results would have been valid on an ARM.

BTW, "volatile" was originally intended for use with memory mapped IO device registers which obviously could change in value at any time.

PeterO

Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

PeterO wrote:I wasn't going to comment on your use of "volatile" because I don't know enough about ARM assembler to be able to look at the compiler output to know if what you said was correct or not. I could have done it on this AMD64 desktop but again I didn't know if the results would have been valid on an ARM.

You can of course also just do a wc -l on the assembler output from the compiler which should show a "change" in the total number of instructions, although obviously extremely crude and otherwise meaningless.

PeterO wrote:BTW, "volatile" was originally intended for use with memory mapped IO device registers which obviously could change in value at any time.

Yes indeed.
I actually used the word volatile because I once saw it in the GCC doct referring to global variables - but I agree its wrong.

None the less, this still applies:

Paeryn wrote:Global variables are still externally visible (unless declared static) so require saving to memory (and loading from memory) because another function can read/write them.

Its just not as bad as "volatile", as some optimization may take place.

Is any one else thinking its's quite ironic that this thread is entitled "Writing clean code isn't hard" when clearly this thread shows that it really is hard to write REALLY clean code?

Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

jamesh wrote:Is any one else thinking its's quite ironic that this thread is entitled "Writing clean code isn't hard" when clearly this thread shows that it really is hard to write REALLY clean code?

Actually I'm not sure it is that hard. For me it's about practice, self discipline and pride. If you put the effort in to learn how to do it right then it will become business as usual. As we've seen in another thread if you aren't prepared to put in the effort to learn about the tools (C language and C compilers in this case and libraries in the other thread) then you won't get anywhere beyond a clean "Hello World". I must admit that until this thread started I was quite happy to write "clean" code (clean with -Wall), now six weeks later I've upped my standards, something I should have probably done years ago. Maybe you can teach an old dog new tricks.

jahboater wrote:
Yes! see this post from earlier in the thread:-

PeterO wrote:

jahboater wrote:and who said "Writing clean code isn't hard"

I'm well aware of the irony ! But there is "clean" and then there's "all shiny and clean". People that post code that isn't even clean with just "-Wall -Wextra" were the real target of this thread

We have perhaps strayed off topic, but its been educational for me anyway.

It's certainly been educational and useful for me
PeterO

PS: I've added this to my .bashrc so I have the full list available easily:

Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

1dot0 wrote:having now a topic with eventually 4 pages and 91 replies about "Writing clean code isn't hard!" I come into temptation to assume that that attempt is anything else but "isn't hard"...

If you had taken the time to read the thread you would have seen we've discussed that very point only a few posts ago.
PeterO

Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

There are two ways of constructing a software design: One way is to make it so
simple that there are obviously no deficiencies and the other way is to make it
so complicated that there are no obvious deficiencies. The first method is far
more difficult.
-- C.A.R. Hoare

Perfection is reached, not when there is no longer anything to add, but when
there is no longer anything to take away.
-- Antoine de Saint-Exupery

jamesh wrote:Is any one else thinking its's quite ironic that this thread is entitled "Writing clean code isn't hard" when clearly this thread shows that it really is hard to write REALLY clean code?

I totally agree with you. [Mod deleted insult] Of course people need to have disipline and they do need to write code clean, but they don't need to go that crazy with trying with all the esosteric compiler "warning provider". At some point it doesn't make sense.

For a good example I'll show you this thread : viewtopic.php?f=33&t=175585&p=1144332#p1144332 where the author is full of kindness and want to make people learn some basic fundamental C stuff, and he just gets bad faith. I can't stand with that behavior, it's really sad that people goes that way.

Of course C learning is hard and takes time and it require to be precise, but those kind of C-maniacs can't stop throwing doors at people who wanna learn, and that's a shame, because a big part of the C dev community are like that.
When a beginner show you some stuff he doesn't need for an answer all the complexity linked problem of C programming that he doesn't even heard of yet and can't understand btw, and that indeed are not a problem for him yet.

YCN-

Last edited by YCN- on Tue Jun 06, 2017 9:11 am, edited 2 times in total.

For a good example I'll show you this thread : viewtopic.php?f=33&t=175585&p=1144332#p1144332 where the author is full of kindness and want to make people learn some basic fundamental C stuff, and he just gets bad faith. I can't stand with that behavior, it's really sad that people goes that way.

He got what he deserved ! If you read the whole of that thread and the whole of this one you will understand why !

Of course C learning is hard and takes time and it require to be precise, but those kind of C-maniacs can't stop throwing doors at people who wanna learn, and that's a shame, because a big part of the C dev community are like that.
When a beginner show you some stuff he doesn't need for an answer all the complexity linked problem of C programming that he doesn't even heard of yet and can't understand btw, and that indeed are not a problem for him yet.

Is that a question or a statement because it makes no sense !
I suppose of you don't look upon coding as something to take pried in then you can ignore the advice given to you by experienced C coders, but if you want to progress then you need to learn to do it properly, that's what this is all about.

PeterO

Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

PeterO wrote:I suppose of you don't look upon coding as something to take pried in then you can ignore the advice given to you by experienced C coders, but if you want to progress then you need to learn to do it properly, that's what this is all about.

Agreed, but the keyword here is not pain but pedagogy, and that's something a lot of C developers lack of.

Making stuff understandable even if you omit (and even hide) some part is needed because newbies can't understand all the problematics linked to programming, and furthermore C-programming.

PeterO wrote:I suppose of you don't look upon coding as something to take pried in then you can ignore the advice given to you by experienced C coders, but if you want to progress then you need to learn to do it properly, that's what this is all about.

Agreed, but the keyword here is not pain but pedagogy, and that's something a lot of C developers lack of.

You seem to be confused ! The example you quoted earlier was a clear example of bad pedagogy, posting incomplete examples including syntax problems is not the way to teach ANY programming language.

Making stuff understandable even if you omit (and even hide) some part is needed because newbies can't understand all the problematics linked to programming, and furthermore C-programming.

I take the position that people here asking about learning C are going to have learned some other language first (typically Python), so they don't need treating with "kid gloves", and don't need any "unpalatable bits" of the language hiding from them. It's best to learn how to do things correctly right from the start, bad habits are notoriously hard to unlearn !

PeterO

Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson