 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Arttu Voutilainen" <bli### [at] removethis zbxtnetinvalid> wrote in message
news:47337108$1@news.povray.org...
> Eero Ahonen wrote:
>> Brian Elliott wrote:
>>> "Alain" <ele### [at] netscapenet> wrote in message
>>> news:4731f3f7$1@news.povray.org...
>>>> Once when playing with a small speaker, I pluged it in a transformer
>>>> and was prety unimpressed by the feeble low hum I got, so, I plugged
>>>> it directly into the wall socket, hoping for a loud hum. Use a regular
>>>> electrical plug, hook the speaker whires in to it, plug it in. Instant
>>>> POF, flash of light, small cloud of smoke, smell of ozone and burnt
>>>> metal, bursted speaker's dome. The coil's whires got vaporised.
>>>> At the time, I was about 10 or 11.
>>> I did the same to one of those tiny 3-volt DC motors, like the cog-ended
>>> ones that are in battery-powered toys. A friend bragged at school he'd
>>> plugged one into the mains, and it went really incredibly fast and was
>>> really hot afterwards.
>>>
>>
>> Every time I read these I feel more and more sorry for myself for NOT
>> doing something that stupid (and cool :p) as a kid.
>>
>
> Yeah, me too.
>
> Guess I have still some time left to do something cool with elec ;)
Something cool to do as a bigger kid.
Rat the Extra-High-Tension transformer out of an old junked CRT-type TV or
monitor. (That weird-looking gangly thing covered in large amounts of black
wax, with the *heavily" insulated wire from its top, that plugs into the
back of the Cathode Ray tube)
Using an ohmmeter, you can determine which wire is the other side of the HT
coil, and which wires are the low-voltage coil (they'll have less
resistance, and maybe even a centre-tap point)
Fashion up a convenient 555 timer circuit on a 12-volt plugpack. Tune it to
about 16 kHz. (or just go for "high squeal like a TV" set). Buffer its
output with either a single-ended, or for more efficiency, a push-pull power
transistor output stage. A naked 2N3055 will do fine, but you can use a
smaller power transistor if you bolt it onto a heatsink. Remember to put
reverse-biased power diodes across the output transistor to soak up the
back-EMF from the primary coil or you'll probably fritz your transistor
pretty quick.
Eg. Assuming you have an NPN power transistor with emitter to Ground, bung
its collector in series with the low-Volt primary winding to the 12 Volt
rail. Now, you need...
One clear 240-Volt tungsten incandescent bulb, but with a popped filament.
It needs to have enough filament intact that there isn't too big a gap.
Hook the bulb up to the HT side of the transformer, turn the whole kaboodle
on, and with a little luck, the bulb will display a lovely pinkish-violet
ionised argon "flame" between the filament ends. It'll should have enough
energy to make the filament red hot and the glass hot above the convective
"flame".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Brian Elliott wrote:
> Rat the Extra-High-Tension transformer out of an old junked CRT-type TV
> or monitor. (That weird-looking gangly thing covered in large amounts
> of black wax, with the *heavily" insulated wire from its top, that plugs
> into the back of the Cathode Ray tube)
>
> Using an ohmmeter, you can determine which wire is the other side of the
> HT coil, and which wires are the low-voltage coil (they'll have less
> resistance, and maybe even a centre-tap point)
Um... this sounds a little disturbing...
> Fashion up a convenient 555 timer circuit on a 12-volt plugpack. Tune
> it to about 16 kHz. (or just go for "high squeal like a TV" set).
> Buffer its output with either a single-ended, or for more efficiency, a
> push-pull power transistor output stage. A naked 2N3055 will do fine,
> but you can use a smaller power transistor if you bolt it onto a
> heatsink. Remember to put reverse-biased power diodes across the output
> transistor to soak up the back-EMF from the primary coil or you'll
> probably fritz your transistor pretty quick.
>
> Eg. Assuming you have an NPN power transistor with emitter to Ground,
> bung its collector in series with the low-Volt primary winding to the 12
> Volt rail. Now, you need...
...I have no idea what you just said...
> One clear 240-Volt tungsten incandescent bulb, but with a popped
> filament. It needs to have enough filament intact that there isn't too
> big a gap.
>
> Hook the bulb up to the HT side of the transformer, turn the whole
> kaboodle on, and with a little luck, the bulb will display a lovely
> pinkish-violet ionised argon "flame" between the filament ends. It'll
> should have enough energy to make the filament red hot and the glass hot
> above the convective "flame".
Erm... I think I'll just stick with my plasma ball at home. ;-)
[EDIT: Just as soon as I can find the damn power supply...!]
Did you know, if you balance a metal object on the glass, and hold your
finger just the right distance from it, it produces a continues bright
blue spark? However, be careful; I actually burnt my finger this way...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Paul Fuller" <pgf### [at] optusnetcomau> wrote in message
news:472c590d@news.povray.org...
> Orchid XP v7 wrote:
> > Are YOU man enough to turn up to the office on Monday sporting one of
> > these? 0;-)
> >
> > ------------------------------------------------------------------------
> >
> Let me know when you have a model that animates a fractal zoom. Or at
> least one that performs colour cycling ala FractInt when you press a
button.
>
> At work we used to occasionally have 'Horrible Tie and Ugly Sock Day' -
> with prizes for the worst in each category. While fractals can be
> beautiful I think any one of these would have won the tie category
> easily. :)
LOL. I want fractal socks now :)
honestly i think the ties are kinda cool. total nerd factor... WIN!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 09 Nov 2007 09:34:25 +0000, Invisible wrote:
> Jim Henderson wrote:
>> On Thu, 08 Nov 2007 18:20:39 +0000, Orchid XP v7 wrote:
>>
>>> Nicolas Alvarez wrote:
>>>> Invisible escribió:
>>>>> (I never really understood why programs produce core dumps. I mean,
>>>>> seriously. What chance is there of anybody *ever* deducing anything
>>>>> useful from this data? 10^-78?)
>>>> The original programmer with access to the sourcecode *can* deduce
>>>> data from it.
>>> I seriously doubt it...
>>
>> I've done it, several times, even with things I'm not the original
>> programmer for but have access to the source code.
>
> Really?
Yes, really. :-)
> Well, it still sounds absurdly improbable to me, but I'll take your word
> for it.
Part of the contents of a program in memory is a symbol table - which is
a table that basically tells you what data is stored where. After all,
the program has to know where the value for a variable called "a" is
stored, which means that can be figured out. You don't need a full
system core for this (which used to be the way it was done, in fact, with
my experience working with NetWare, that *was* the way it was done - the
entire contents of memory were dumped along with the current state of the
system). EIP tells you where the program is currently executing and the
various registers tell you the state of the machine - such as if there's
an overflow, PFPE, or some other sort of issue that caused the crash.
So what you do, working at a machine level, is start with where EIP is
and work backwards. You look at the stack backtrace to see what
functions called what functions, and you can figure out what code path
the program had taken.
It's a hell of a lot easier if you have symbolic debug information
available to you, but it's not impossible if you don't - just takes a bit
more time to diagnose. Sometimes a *lot* more time.
From a code standpoint, using Borland C++ (years ago), there was a source-
level debugger that you could single step through. IIRC, there was a way
to take data from a crashed program and use it as well, but it's been a
long time since I did that.
At the moment, the only core file on my system is from novfsd (the Novell
Client for Linux daemon), which I don't have symbol info for, but even
loading the core up in gdb, I can tell that it suffered a segmentation
fault. With a symbol table, it could pinpoint exactly where the daemon
crashed and from there the developers could code a fix for it. As it is,
the backtrace tells me what values are on the stack, but not the name of
the symbol at the address. But that's what the --symbols parameter is
for - to tell it to read in the symbol table.
> Now, how about that Windoze habit of saying "The program has experienced
> an error and will be shut down. Do you want to send debugging
> information?" What do you estimate the chances are that *anybody* will
> do anything at all with the data thus sent? ;-)
Knowing some of the people who do the analysis on that type of data, I'd
say fairly good, actually. It starts with statistical analysis of the
reports coming in, and the things that happen most frequently are likely
candidates for a fix to be written. Of course, different vendors do this
different ways.
I watched one engineer do live debugging of a client issue on a Windows
system; watching someone use a tool like that who knows what they're
doing is a very interesting thing, because they can pull information
about what's going on at any given point in the process. Doing it live
or doing it from a core file is pretty similar, except that with a core
file the system isn't changing; it's actually the *easier* way to debug,
because you're working from a snapshot of a program at a point in time
instead of watching things change.
It's not much different, procedurally, than what CSIs go through in
trying to reconstruct a crime scene. They arrive and things have already
happened, and they have to piece together what transpired ahead of time
in order to build a case. (Of course CSI is more difficult because
people don't act logically; computers do, and as such, they're quite a
bit more predictable).
Though arguably watching things change on a live system can provide more
insight into how you got to a point.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> Part of the contents of a program in memory is a symbol table - which is
> a table that basically tells you what data is stored where. After all,
> the program has to know where the value for a variable called "a" is
> stored, which means that can be figured out.
Now, see, I was told the purpose of a "linker" is to elide all such data
before building the final executable. ;-)
> So what you do, working at a machine level, is start with where EIP is
> and work backwards. You look at the stack backtrace to see what
> functions called what functions, and you can figure out what code path
> the program had taken.
Yeah, but let's be real here. The actual generated machine code is going
to bear *no relationship* to the original program source code. Only a
super-hyper-nerd is ever going to get anything useful out of it.
> From a code standpoint, using Borland C++ (years ago), there was a source-
> level debugger that you could single step through. IIRC, there was a way
> to take data from a crashed program and use it as well, but it's been a
> long time since I did that.
That's impressive. Usually these things work by inserting software
interrupts into the code. (Or just software enumation of machine state...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v7 escribió:
>> So what you do, working at a machine level, is start with where EIP is
>> and work backwards. You look at the stack backtrace to see what
>> functions called what functions, and you can figure out what code path
>> the program had taken.
>
> Yeah, but let's be real here. The actual generated machine code is going
> to bear *no relationship* to the original program source code. Only a
> super-hyper-nerd is ever going to get anything useful out of it.
>
That's what the debugging symbols can do too. Mapping between lines of
code and instruction addresses.
Note that it's usually a lot harder on optimized executables.
Single-stepping on a running program that has been optimized is almost
impossible. It appears to run instructions twice, run instructions in
strange order, etc. So disabling optimizations for stepping through a
program is highly recommended...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 09 Nov 2007 21:02:39 +0000, Orchid XP v7 wrote:
> Jim Henderson wrote:
>
>> Part of the contents of a program in memory is a symbol table - which
>> is a table that basically tells you what data is stored where. After
>> all, the program has to know where the value for a variable called "a"
>> is stored, which means that can be figured out.
>
> Now, see, I was told the purpose of a "linker" is to elide all such data
> before building the final executable. ;-)
No, the final executable *needs* to know this. You may lose the variable
name, but the pointer from the variable itself to a memory location is
something the program *must* know.
>> So what you do, working at a machine level, is start with where EIP is
>> and work backwards. You look at the stack backtrace to see what
>> functions called what functions, and you can figure out what code path
>> the program had taken.
>
> Yeah, but let's be real here. The actual generated machine code is going
> to bear *no relationship* to the original program source code. Only a
> super-hyper-nerd is ever going to get anything useful out of it.
Actually, I am being real - it doesn't take a super-hyper-nerd to do what
I'm describing. It requires a bit of a background in software
development and coding and knowledge of how the systems actually work.
Software engineers do this sort of thing every day - it's part of the job
description.
>> From a code standpoint, using Borland C++ (years ago), there was a
>> source- level debugger that you could single step through. IIRC, there
>> was a way to take data from a crashed program and use it as well, but
>> it's been a long time since I did that.
>
> That's impressive. Usually these things work by inserting software
> interrupts into the code. (Or just software enumation of machine
> state...)
Technically it is impressive to be able to do that (especially if you've
never seen it done before) - but the tools make it very very easy to do.
I've taken cores and pulled stack traces and variables data out of them
and compared to stacks in source code using tools like Source Navigator,
which can give you detailed information about various functions including
a way of looking at the call stacks so you can see what's going on as you
step through the program. Very easy to use, and very useful for this
type of debugging.
I took a crash file from a system and combined with the use of SN, I was
able to pinpoint *exactly* what changed in the code that caused the crash
(comparing old version to new version) and submitted a patch. Turned out
the engineer had fixed it the day prior to my analysis, but my proposed
fix was what he did to fix it. That I came to the same conclusion using
these tools as the guy who originally wrote the code should tell you
something about the feasibility of using tools like this to accomplish
this sort of task. It all started with a core file.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 09 Nov 2007 19:22:02 -0300, Nicolas Alvarez wrote:
> Note that it's usually a lot harder on optimized executables.
Depends on whether the debugger in use is aware of how the optimizations
work; but yes, I believe in Turbo C and BC++, using the inline debugger
did generate non-optimized code in order for the single-step operations
to work.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Stephen nous apporta ses lumieres en ce 2007/11/08 03:31:
> Alain <ele### [at] netscapenet> wrote:
>> Stephen nous apporta ses lumieres en ce 2007/11/07 03:00:
>
>>> You always could recharge non-rechargeable batteries. The manufacturers do
>>> notlike it though.
>>>
>>> Stephen
>>>
>>>
>>>
>> You can, but they don't keep the charge very well. The ones I did recharge
>> lasted less than half as long as rechargeable ones. They also got warmer during
>> the recharge.
>>
>
>
> They do get warm but I think that it depends on the charger and the current it
> uses for charging. Don’t say it! That was a stupid thing to say. Of course it
> depends on the current. I built mine myself and charged them at about 20 ma and
> IIRC discharge was between 7.5 and 10 ma.
> If your batteries are not holding their charge then the discharge cycle is
> probably too low.
> And that came from another life, one before Pov :)
> Also if you were old enough to wire up a mains plug you were old enough to die.
> Dear oh dear the things that didn’t kill us. :) I wouldn’t like to put in
> writing some of the things that I did.
>
>
> Stephen
>
>
Not a main plug. The whire of a lamp had to be replaced. My father kept the plug
and the intact part of the whire, about 1'. I found it. I hooked the speaker to
it, and wrapt with masking tape. Used that to plug the speaker in the wall. 120
volts for a speaker made for a small radio that used a 9V batery...
--
Alain
-------------------------------------------------
You know you've been raytracing too long when you look at waterfalls, dust,
rain, snow, etc, and think: "If only I had a fractalized, vector based
particle-system modeler with collision detection!"
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson nous apporta ses lumieres en ce 2007/11/09 15:50:
> On Fri, 09 Nov 2007 09:34:25 +0000, Invisible wrote:
>
>> Jim Henderson wrote:
>>> On Thu, 08 Nov 2007 18:20:39 +0000, Orchid XP v7 wrote:
>>>
>>>> Nicolas Alvarez wrote:
>>>>> Invisible escribió:
>>>>>> (I never really understood why programs produce core dumps. I mean,
>>>>>> seriously. What chance is there of anybody *ever* deducing anything
>>>>>> useful from this data? 10^-78?)
>>>>> The original programmer with access to the sourcecode *can* deduce
>>>>> data from it.
>>>> I seriously doubt it...
>>> I've done it, several times, even with things I'm not the original
>>> programmer for but have access to the source code.
>> Really?
>
> Yes, really. :-)
>
>> Well, it still sounds absurdly improbable to me, but I'll take your word
>> for it.
>
> Part of the contents of a program in memory is a symbol table - which is
> a table that basically tells you what data is stored where. After all,
> the program has to know where the value for a variable called "a" is
> stored, which means that can be figured out. You don't need a full
> system core for this (which used to be the way it was done, in fact, with
> my experience working with NetWare, that *was* the way it was done - the
> entire contents of memory were dumped along with the current state of the
> system). EIP tells you where the program is currently executing and the
> various registers tell you the state of the machine - such as if there's
> an overflow, PFPE, or some other sort of issue that caused the crash.
>
> So what you do, working at a machine level, is start with where EIP is
> and work backwards. You look at the stack backtrace to see what
> functions called what functions, and you can figure out what code path
> the program had taken.
There are times when you can't do a stack backtrace because the stack have been
corrupted. Something like a bad vector that send you to a bit of code that call
a subprocess, pushing the return address on the stack, and the code pointed to
ask tou to jump the another subprocess, whitch is itself. Infinite loop causing
a stack overflow, and in some cases, the stack cycling pointer cycling back to zero.
Or you enter a loop that pop data out of the stack until there is no more data
to retreive, and the stack pointer jump to the largest value it can contain.
There are times when the crash can cause corruption far outside the area that a
process is allowed to access.
>
> It's a hell of a lot easier if you have symbolic debug information
> available to you, but it's not impossible if you don't - just takes a bit
> more time to diagnose. Sometimes a *lot* more time.
True.
>
> From a code standpoint, using Borland C++ (years ago), there was a source-
> level debugger that you could single step through. IIRC, there was a way
> to take data from a crashed program and use it as well, but it's been a
> long time since I did that.
>
> At the moment, the only core file on my system is from novfsd (the Novell
> Client for Linux daemon), which I don't have symbol info for, but even
> loading the core up in gdb, I can tell that it suffered a segmentation
> fault. With a symbol table, it could pinpoint exactly where the daemon
> crashed and from there the developers could code a fix for it. As it is,
> the backtrace tells me what values are on the stack, but not the name of
> the symbol at the address. But that's what the --symbols parameter is
> for - to tell it to read in the symbol table.
>
>> Now, how about that Windoze habit of saying "The program has experienced
>> an error and will be shut down. Do you want to send debugging
>> information?" What do you estimate the chances are that *anybody* will
>> do anything at all with the data thus sent? ;-)
>
> Knowing some of the people who do the analysis on that type of data, I'd
> say fairly good, actually. It starts with statistical analysis of the
> reports coming in, and the things that happen most frequently are likely
> candidates for a fix to be written. Of course, different vendors do this
> different ways.
>
> I watched one engineer do live debugging of a client issue on a Windows
> system; watching someone use a tool like that who knows what they're
> doing is a very interesting thing, because they can pull information
> about what's going on at any given point in the process. Doing it live
> or doing it from a core file is pretty similar, except that with a core
> file the system isn't changing; it's actually the *easier* way to debug,
> because you're working from a snapshot of a program at a point in time
> instead of watching things change.
Easier to look at a snapshot than to the changes. The snapshot is frozen. If you
try to look as it changes, it's usualy to fast.
>
> It's not much different, procedurally, than what CSIs go through in
> trying to reconstruct a crime scene. They arrive and things have already
> happened, and they have to piece together what transpired ahead of time
> in order to build a case. (Of course CSI is more difficult because
> people don't act logically; computers do, and as such, they're quite a
> bit more predictable).
>
> Though arguably watching things change on a live system can provide more
> insight into how you got to a point.
>
> Jim
--
Alain
-------------------------------------------------
Lutheran: If shit happens, don't talk about it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
