Even the current form of the DMCA has a provision allowing reverse engineering for compatibility purposes.
Judge Kaplan, who presided over 2600's DeCSS case, seemed not to care about that provision, so I guess Lexmark wants to see if they can wage a lawsuit where the judge presiding over thier case will ignore the reverse-engineering for compatibility issue.
It's just another case of, "Ask not, and you shall not recieve"
I don't know about you, but lumping the rest of us who use debugger in with the heap of "cherry picking" amateurs, sounds REALLY arrogant.
Firstly, I'm like you, in that usually I know where my problems are, and I don't need to do a step-by-step trace to find my problems. BUT sometimes I do, because sometimes we ALL overlook something. Secondly, I work with a lot of other people's code. I don't have the luxury knowing exactly what's going on in the code, and debuggers help me fix other people's bugs a lot faster than speculating.
I'm just sick of these one-size-fits all opinions. Just because some people use these features as a crutch, doesn't mean the rest of us having found real value. More features do not cause undiciplined programmers. They were undiciplined before the features got to them. There will always be undiciplined programmers.
You're not going to change them by taking away thier features.
NOTE: The bold is used to highlight points, it's not for yelling.
I can understand where you're coming from if you're talking about debugging non-VM and non-interpretive code. Even then, a lot of newer debuggers use methods which could handle most of these issues.
2) Where would this stack of previous values go? What if it's the control for a loop? A buffer variable that updates every second?
Your compiler could compile in code save values as they are being changed, in an array of stacks somewhere. You could probably limit the stacks to only the last 10 values.
3) Same point, just makes the stack bigger. Should it cross reference all variables so you can see what that all were at that point?
Pretty much...
6) So the debugger should be able to wrestle a process away from the processor without previously having linked into it, and then map memory locations to variables and procedures? That would be impressive.
Impressive if your code was compiled to machine code. If it's been compile to bytecode and being JITed, then it shouldn't be so hard. The future is going towards JITing.
MS VC++ 6.0 supports this with thier dynamic linking. However, I'm not sure what you mean by stepping backwards.
In VC++, you could set the next instruction to a previous instruction, but it wouldn't save the variable states for the last 100 instructions (if that's what you're talking about).
I'm always a little peaved when I hear people trying to show off thier slick lines they use on telemarketers, just before hanging up.
Telemarketers aren't stupid...
One of my more effective methods is simply acting like someone who can't assert themselves and are somewhat susceptible to thier sales pitches.
What really makes it work is projecting a very convincing helpless frustration. The more you can keep a telemarketer on the phone while making them feel bad about what they're doing, the better.
It's not as fun as acting retarded, or telling the newspaper lady you can't read (I had one lady who had a counter-reason for buying the paper, for every crazy reason for not buying the paper). She obviously knew I was joking, but she was really good.
Sometimes I've found them receptive, and I've had at length conversations about where they live, what they've done in the past, politics, etc.
Yet other times, I would tell them to hold, put the phone down for 5 minutes so I could watch TV. When I picked it up, they would still be on the phone. I put one person on hold 3 times (same call) before they hung up...
The point: Keep them on and demoralize them, or talk about personal issues and get them in trouble.
Slashdot Mirror
Even the current form of the DMCA has a provision allowing reverse engineering for compatibility purposes.
Judge Kaplan, who presided over 2600's DeCSS case, seemed not to care about that provision, so I guess Lexmark wants to see if they can wage a lawsuit where the judge presiding over thier case will ignore the reverse-engineering for compatibility issue.
It's just another case of, "Ask not, and you shall not recieve"
That's right. It does...
I don't know about you, but lumping the rest of us who use debugger in with the heap of "cherry picking" amateurs, sounds REALLY arrogant.
Firstly, I'm like you, in that usually I know where my problems are, and I don't need to do a step-by-step trace to find my problems. BUT sometimes I do, because sometimes we ALL overlook something. Secondly, I work with a lot of other people's code. I don't have the luxury knowing exactly what's going on in the code, and debuggers help me fix other people's bugs a lot faster than speculating.
I'm just sick of these one-size-fits all opinions. Just because some people use these features as a crutch, doesn't mean the rest of us having found real value. More features do not cause undiciplined programmers. They were undiciplined before the features got to them. There will always be undiciplined programmers.
You're not going to change them by taking away thier features.
NOTE: The bold is used to highlight points, it's not for yelling.
I can understand where you're coming from if you're talking about debugging non-VM and non-interpretive code. Even then, a lot of newer debuggers use methods which could handle most of these issues. 2) Where would this stack of previous values go? What if it's the control for a loop? A buffer variable that updates every second? Your compiler could compile in code save values as they are being changed, in an array of stacks somewhere. You could probably limit the stacks to only the last 10 values. 3) Same point, just makes the stack bigger. Should it cross reference all variables so you can see what that all were at that point? Pretty much... 6) So the debugger should be able to wrestle a process away from the processor without previously having linked into it, and then map memory locations to variables and procedures? That would be impressive. Impressive if your code was compiled to machine code. If it's been compile to bytecode and being JITed, then it shouldn't be so hard. The future is going towards JITing.
MS VC++ 6.0 supports this with thier dynamic linking. However, I'm not sure what you mean by stepping backwards. In VC++, you could set the next instruction to a previous instruction, but it wouldn't save the variable states for the last 100 instructions (if that's what you're talking about).
I'm always a little peaved when I hear people trying to show off thier slick lines they use on telemarketers, just before hanging up.
Telemarketers aren't stupid...
One of my more effective methods is simply acting like someone who can't assert themselves and are somewhat susceptible to thier sales pitches.
What really makes it work is projecting a very convincing helpless frustration. The more you can keep a telemarketer on the phone while making them feel bad about what they're doing, the better.
It's not as fun as acting retarded, or telling the newspaper lady you can't read (I had one lady who had a counter-reason for buying the paper, for every crazy reason for not buying the paper). She obviously knew I was joking, but she was really good.
Sometimes I've found them receptive, and I've had at length conversations about where they live, what they've done in the past, politics, etc.
Yet other times, I would tell them to hold, put the phone down for 5 minutes so I could watch TV. When I picked it up, they would still be on the phone. I put one person on hold 3 times (same call) before they hung up...
The point: Keep them on and demoralize them, or talk about personal issues and get them in trouble.
Save the slick lines and dumb jokes for pranks.