Keithley 179 bench multimeter

[tggzzz]

My Datron calibrator is also 1kV; I've yet to pluck up courage to work on it, since no manuals are available.

Send it to Chris to fix it; he never reads manuals (deliberate out of context quote from Discord chat, that we're beating him over the head with)

Of course he wouldn't.

He's been conditioned by the recent (i.e. <25 years old) religion that all comments are out of date and don't correspond to what you find in front of you.

(Having said that, even with hardware there is a little truth there, e.g. there are at least 4 variants of the schematic for the tuner I'm repairing)

[Zenith]

He's been conditioned by the recent (i.e. <25 years old) religion that all comments are out of date and don't correspond to what you find in front of you.

(Having said that, even with hardware there is a little truth there, e.g. there are at least 4 variants of the schematic for the tuner I'm repairing)

Tek and HP were generally very good at documenting all hardware changes. HP issued updates for manuals. There are also good support communities on the WWW.

Some other makers, such as Hameg, weren't always fully up to speed, particularly with their higher end models. My early version of the HM1005 100MHz scope has Y pre amps and a final Y amp significantly different from those in later versions, which are what is covered in the commonly available version of the manual. The HM 605 60MHz scope is a very late model and has an EHT about 300V greater than in the manual and the high voltage for the final X and Y amps is also different. They moved to another slightly different CRT and had to make modifications.

I saw someone selling a late version of a Hameg 20MHz scope, an HM203/7. He was selling it for very little because it had a power supply fault. He couldn't fix it and was offering it at a low price, because towards the end, Hameg had swapped from the linear PSUs they'd been using for years, to an SMPS, but no documentation was available for it.

For some pieces of kit, user manuals can be hard to find, and circuit diagrams, leave alone a service manual with set up procedures, are not to be had, even if you are happy to pay for them.

A circuit diagram, even if it doesn't include the variations your specimen has, or even it it refers to a different model in the same series, is a lot better than nothing.

[tggzzz]

A circuit diagram, even if it doesn't include the variations your specimen has, or even it it refers to a different model in the same series, is a lot better than nothing.

Most definitely.

The religion bd has to contend with can go to the extremes that, since comments always become out of date, all comments should be removed. All that's necessary is to read the code.

As if.

While there's some validity to comments getting out of sync with the code, removing all comments on that principle is indistinguishable from religious dogma. I've seen that in action!

[Zenith]

Another article of religious faith was never to use GO TO.

I'm not suggesting that 1960s COBOL/FORTRAN impenetrable logical spaghetti is the way to go, but once in a while GOTO is useful, particularly to break out of a deeply nested loop. I've seen people bend over backwards writing all sorts of convoluted Boolean conditions to avoid that.

I once went for an interview where part of it was to turn a flow chart into C. It seemed straightforward enough. The interviewer looked at the C and said it was wrong, because there was no GOTO. I said it wasn't wrong and we could go through it together. He'd forgotten the continue verb. The point of the exercise was to force people to use GOTO. He said most applicants just couldn't bring themselves to use GOTO and took ages and ages before giving up.

[bd139]

That's not necessarily religious faith, but a misinterpretation of the problem. Goto is horrible because if you need it then you fucked up.

Typically it's used for

Code: Select all

	for (;;) {
		for (;;) {
			for (;;) {
				// urgh can't be bothered to work out how to signal out of this loop
				goto fuckthis;
			}
		}
	}
fuckthis:
	// phew

When the problem should be:

Code: Select all

	bool loop1() {
		for (;;) {
			if (loop2())
				break;
		}
	}
	
	inline bool loop2() {
		for (;;) {
			if (loop3())
				break;
		}
		return false;
	}
	
	// functional description of what loop3 is doing
	inline bool loop3() {
		for (;;) {
			// oh shit I need out
			return true;
		}
		return false;
	}

Goto is NOT a requirement of well designed control flow. In fact in C it is TERRIBLE if you have anything allocated on the heap because there is no GC so you have to reason about and free everything after the goto. Lazy people allocate pools for this (windows does that a lot hence the memory usage problems sometimes encountered) but it's a bad solution when some thinking can solve the problem cleanly (and only use stack!)

<< insert disclaimer about setjmp etc >>

[tggzzz]

I did "have" to use GOTO once at university, in a 10 line program. The (competent) professor's eyebrows went up, then he agreed that the code was clear and there wasn't a clear(er) alternative.

Apart from that, in C goto is most often seen

• where a decent exception handling mechanism isn't available
• products where it is required that source code be delivered - and they take an optimised binary and decompile it
• autogenerated code, e.g. from an FSM or another language such as (Kyoto Common) LISP

[25 CPS]

I did "have" to use GOTO once at university, in a 10 line program. The (competent) professor's eyebrows went up, then he agreed that the code was clear and there wasn't a clear(er) alternative.

Apart from that, in C goto is most often seen

• where a decent exception handling mechanism isn't available
• products where it is required that source code be delivered - and they take an optimised binary and decompile it
• autogenerated code, e.g. from an FSM or another language such as (Kyoto Common) LISP

The one and only time I used goto in a C program was during an exam in Grade 12 computer science way back when I was in high school. I was running out of time and broke down and used goto to get the program I wrote to answer one of the questions working before everything had to be handed in. I did get the program for that question working in time and handed it in. I was given the points for that question but the comments written on the exam made it clear that it was begrudgingly.

[Zenith]

I wrote a few thousand lines of Pascal and later a few thousand lines of C. I only used goto a handful of times. Mostly it wasn't necessary. I was surprised the effect it had on some people - worse than heresy, like being uncovered as a devil worshipper.

I thought the interview test was a strange one. The bloke who devised it was writing firmware in C full time. I could see what he was trying to get at, but I was amazed it caught so many out, including him, in a way.

https://www.kernel.org/doc/html/v4.19/p ... style.html

Item 7) Centralized exiting of functions

[bd139]

I did "have" to use GOTO once at university, in a 10 line program. The (competent) professor's eyebrows went up, then he agreed that the code was clear and there wasn't a clear(er) alternative.

Apart from that, in C goto is most often seen

• where a decent exception handling mechanism isn't available
• products where it is required that source code be delivered - and they take an optimised binary and decompile it
• autogenerated code, e.g. from an FSM or another language such as (Kyoto Common) LISP

exception handling ....

... handle the fucking errors and stop being lazy.

auto generated code...

... should be LLVM IR

state machine ...

Code: Select all

	state = STATE_INIT;
	while (state != STATE_EXIT) {
		switch(state) {
		case STATE_INIT:
			state = STATE_EXIT;
			break;
		case STATE_EXIT:
			break;
		}
	}

[bd139]

I wrote a few thousand lines of Pascal and later a few thousand lines of C. I only used goto a handful of times. Mostly it wasn't necessary. I was surprised the effect it had on some people - worse than heresy, like being uncovered as a devil worshipper.

I thought the interview test was a strange one. The bloke who devised it was writing firmware in C full time. I could see what he was trying to get at, but I was amazed it caught so many out, including him, in a way.

https://www.kernel.org/doc/html/v4.19/p ... style.html

Item 7) Centralized exiting of functions

There were a couple of double-free bugs in the kernel a number of years ago related to that particular bit of guidance. Avoid deep nesting, keep all functions as flat as possible with the same entry and exit allocations. Very simple. But difficult to refactor anything into that state if you're making it up as you go along. Have to think before you start pressing keys.