LinuxQuestions.org
Support LQ: Use code LQ3 and save $3 on Domain Registration
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > General
User Name
Password
General This forum is for non-technical general discussion which can include both Linux and non-Linux topics. Have fun!

Notices

Reply
 
Search this Thread
Old 05-08-2006, 09:25 PM   #61
jonaskoelker
Senior Member
 
Registered: Jul 2004
Location: Denmark
Distribution: Ubuntu, Debian
Posts: 1,524

Original Poster
Rep: Reputation: 46

Quote:
Originally Posted by tuxdev
jonaskoelker: Your code isn't legal C code. My code is how to do multiple inheritance in C, similar to when C++ was CFront.
Oh, okay. You're right about that, but I still claim it's not proper inheritance in terms of C++ (for instance, baz doesn't automatically get all the methods of foo and bar), which was the point I wanted to bring forward. I take it on trust that you're right about CFront, but... isn't that frozen in time inside a blob of amber or something like it?
 
Old 05-08-2006, 09:54 PM   #62
tuxdev
Senior Member
 
Registered: Jul 2005
Distribution: Slackware
Posts: 2,014

Rep: Reputation: 115Reputation: 115
You're right that it isn't automatic. OOP isn't automatic either. You still have to pass in the context object to any "member" functions. Let's add a member function that is like the C++ example.
Code:
void f(struct foo *foo)
{
   ++foo->qux;
}
When baz #includes foo.h, it gets member function f. It can be called by doing "f(baz.foo)".
All not-so-recent features of C++ had to have been implemented somehow in C when it was only a preprocessor.
 
Old 05-08-2006, 11:49 PM   #63
NetRAVEN5000
Member
 
Registered: May 2005
Distribution: Ubuntu 9.04
Posts: 320

Rep: Reputation: 30
Quote:
Originally Posted by jonaskoelker
Hah. Funny how your examples are not free (libre) software (firefox itself is, but firefox with the bug thingy is, AIUI, not--at least the debian firefox doesn't seem to have it). Not that it makes the examples any less valid in and of itself, I just can't comment on them.
Yes they are. I'm using Firefox from a package on the Slackware install CDs, not from the FF website. And LimeWire has many "branch-offs" (such as AquaLime and FreeWire) of its code, probably created by Windows users who didn't like it being bundled with adware and/or wanted their "pro" features but didn't want to pay money.

In any case, I'm pretty sure both are free/libre.
Quote:
Originally Posted by tuxdev
NetRAVEN5000: The best way for users to help with dev is to submit bugs through bugzilla. A stack trace really doesn't help anybody but the developer who is working on the bug. The developer surely knows how to use gdb, and the bug must be consistently reproducible to have any chance to be fixed.
1. What good is bugzilla if it doesn't give the developer a trace, or at least some sort of log of what went wrong to go by?
2. Who do you want to help other than the developer fixing the bug? If they're not fixing the bug, what good does the bugzilla info do them anyways?

No doubt bugzilla can help, but if I don't put some sort of backtrace in my program then it'll be that much harder to diagnose my users' problems. In Java it's already there; in C++ you have to go build it yourself. Of course, you might want to take that a step further in whichever language you choose, but at least in Java you start with something already there.

Last edited by NetRAVEN5000; 05-08-2006 at 11:56 PM.
 
Old 05-09-2006, 04:16 AM   #64
jonaskoelker
Senior Member
 
Registered: Jul 2004
Location: Denmark
Distribution: Ubuntu, Debian
Posts: 1,524

Original Poster
Rep: Reputation: 46
Meh... you're right about limewire being free (it's even GPL, kudos to them). I was fooled by their website, which in my eyes very much looks like LimeWire is proprietary. Anyways, I still haven' tried it, so I can't comment.
 
Old 05-09-2006, 02:36 PM   #65
tuxdev
Senior Member
 
Registered: Jul 2005
Distribution: Slackware
Posts: 2,014

Rep: Reputation: 115Reputation: 115
Bugzilla is to post steps to reproduce, which are indirectly way more valuable to developers than a trace. The trace is generated by reproducing the bug, so it is not needed in the bug report. The only person who is interested in the trace wants to generate it himself. If a bug is not consistently reproducible, it is unfixable.
 
Old 05-09-2006, 03:49 PM   #66
Vagrant
Member
 
Registered: Nov 2001
Posts: 75

Rep: Reputation: 15
Quote:
Originally Posted by tuxdev
Bugzilla is to post steps to reproduce, which are indirectly way more valuable to developers than a trace. The trace is generated by reproducing the bug, so it is not needed in the bug report. The only person who is interested in the trace wants to generate it himself. If a bug is not consistently reproducible, it is unfixable.

I don't agree. There may be other mitigating factors, such as the environment, which may have caused the bug. The bug reporter may be unaware of this fact and a trace would potentially help resolve this issue.
 
Old 05-09-2006, 04:46 PM   #67
NetRAVEN5000
Member
 
Registered: May 2005
Distribution: Ubuntu 9.04
Posts: 320

Rep: Reputation: 30
Quote:
Originally Posted by jonaskoelker
Meh... you're right about limewire being free (it's even GPL, kudos to them). I was fooled by their website, which in my eyes very much looks like LimeWire is proprietary. Anyways, I still haven' tried it, so I can't comment.
I know - they really push their "LimeWire Pro" so it might appear to be closed-source. But it's not - I started using it before they had "LimeWire Pro".
Quote:
Bugzilla is to post steps to reproduce, which are indirectly way more valuable to developers than a trace. The trace is generated by reproducing the bug, so it is not needed in the bug report. The only person who is interested in the trace wants to generate it himself. If a bug is not consistently reproducible, it is unfixable.
A trace works backwards from the error. It catches an error and works backward to find out what line and in which class. It may not tell the direct cause of the error, but it will tell what line of code caused the error.

If you're suggesting keeping a log of the program's every action. . . that could potentially slow things down quite a bit. And, from your description, it sounds like that's what bugzilla is doing.

Unless you're expecting the user to post their steps to reproduce the error, which, as I said before, is only helpful if the user both knows how to do this, and decides to do it. With an automatic trace, you already eliminate one of those prerequisites - now all the user has to do is tell you what error it spit out.

Or you might be able to make your program so that it'll automatically notify you of errors by sending you these bugtraces. That might sound hard to do, but I don't think it'd be too difficult - Java does have methods to catch at least certain types of errors, and I bet if you had one class (the "safety net") launch the other (the actual program), when the actual program crashes the "safety net" could retrieve the bugtraces it spits out, and then it could send them to you.
 
Old 05-09-2006, 08:54 PM   #68
tuxdev
Senior Member
 
Registered: Jul 2005
Distribution: Slackware
Posts: 2,014

Rep: Reputation: 115Reputation: 115
If a bug cannot be reproduced by a developer, it cannot be fixed. The *only* information a developer needs are consistent steps to reproduce. Think about it in terms of "Give a man a fish and he eats for a day. Teach a man to fish and he eats for a lifetime." Anything a program sends back would ultimately be not very useful. I also consider any program that calls home to be spyware.
 
Old 05-10-2006, 02:28 AM   #69
NetRAVEN5000
Member
 
Registered: May 2005
Distribution: Ubuntu 9.04
Posts: 320

Rep: Reputation: 30
Quote:
Originally Posted by tuxdev
I also consider any program that calls home to be spyware.
Unless it asks you whether or not to let it call home. That's what LimeWire does when it has an error - it comes up with a dialog with the error and asks you whether or not to let it phone home and tell the developers.
 
Old 05-10-2006, 02:59 AM   #70
jonaskoelker
Senior Member
 
Registered: Jul 2004
Location: Denmark
Distribution: Ubuntu, Debian
Posts: 1,524

Original Poster
Rep: Reputation: 46
Quote:
Originally Posted by NetRAVEN5000
Unless you're expecting the user to post their steps to reproduce the error, which, as I said before, is only helpful if the user both knows how to do this, and decides to do it. With an automatic trace, you already eliminate one of those prerequisites - now all the user has to do is tell you what error it spit out.
I would like to stress very stongly that a backtrace is emphatically NOT the same as "step to reproduce", which is what you seem to be saying here.

Consider the following code:

Code:
method a() { foo = null; /* produce bug */ }
method b() { foo = null; /* produce bug */ }
method c() { foo.frob(); /* exhibit bug */ }
method d() { if (n >= 7) a(); else b(); }
Now, if some method e calls d then c and you can't determine the value of (n >= 7) from the calling context, the backtrace gives you no clue why the bug is produced.

If on the other hand, the user had said "I click on `increase n' seven times, then click `exhibit bug', then your program crashes. It also consistenly crashes if I click on it eight, nine or ten times, but not for four, five and six times. Here's a backtrace: (in c, called by e, called by ...)" you would have something to work with.
 
Old 05-10-2006, 10:39 AM   #71
Michael_S
Member
 
Registered: Oct 2004
Location: Pennsylvania, USA
Distribution: Debian
Posts: 78

Rep: Reputation: 23
Quote:
Originally Posted by tuxdev
If a bug cannot be reproduced by a developer, it cannot be fixed. The *only* information a developer needs are consistent steps to reproduce. Think about it in terms of "Give a man a fish and he eats for a day. Teach a man to fish and he eats for a lifetime." Anything a program sends back would ultimately be not very useful. I also consider any program that calls home to be spyware.
Quote:
Originally Posted by Vagrant
I don't agree. There may be other mitigating factors, such as the environment, which may have caused the bug. The bug reporter may be unaware of this fact and a trace would potentially help resolve this issue.
I'm with Vagrant on this. If you have a stand alone application that doesn't rely on any external software or environmental conditions to operate, steps to reproduce can be straightforward.

But in many cases, steps to reproduce are "Set up an office environment. Put together 3 servers with NT, XP, and 2003 server. Install Citrix Metaframe XP with the following service packs: ..... Use the following print applications. Buy and set up the following printers: .... Install an SAP application on the XP server. Use Cisco 910 switches for the entire office. Set up your Windows Domain with Active Directory and the following settings.... Okay, now when you use print program X through an RDP connection from machine Y to server Z, and run such and such batch file in the background, the HP Printer works fine but the Canon printer gets black lines on every page past the fifth."

I had problems like that at my last job, and until you've experienced it you can't imagine all the weird ways that software apps unintentionally interact with each other. That's true for a complex Unix/Linux environment as much as it is for Windows. Every single day we would have customers calling in with bugs that we could not reproduce in our home office. 75% of the time it was user error, but the other 25% of the time one of our developers would travel to their site and see the problem.

I'm not saying all of the features of the office environment contributed to the problem. It's likely that 99% are unrelated. But in many cases, you won't know which pieces are causing the problem and which are unrelated.

Last edited by Michael_S; 05-10-2006 at 10:42 AM.
 
Old 05-10-2006, 11:58 AM   #72
Vagrant
Member
 
Registered: Nov 2001
Posts: 75

Rep: Reputation: 15
Quote:
Originally Posted by tuxdev
If a bug cannot be reproduced by a developer, it cannot be fixed. The *only* information a developer needs are consistent steps to reproduce. Think about it in terms of "Give a man a fish and he eats for a day. Teach a man to fish and he eats for a lifetime." .
That's probably the most irrelevant analogy one could think of. It is not a necessity for the developer, herself, to reproduce the error. If one can look at a trace and discover the problem, especially if it is obviously an environmental issue. I agree that reproducibility has its place but you seem to be in some sort of strange idealist land. Its like developer Twilight Zone in which the only possible bugs to fix are ones which have detailed steps to reproduce.
 
Old 05-10-2006, 01:37 PM   #73
tuxdev
Senior Member
 
Registered: Jul 2005
Distribution: Slackware
Posts: 2,014

Rep: Reputation: 115Reputation: 115
I have to reproduce a bug in order to know whether or not I've fixed it. I have to reproduce it once as a control to know *exactly* what happened. The backtrace is not useful because it will be generated when I reproduce the bug. Analogy translated: "Give me a backtrace and I can know where it crashed. Give me steps to reproduce and I can know anything."
 
Old 05-10-2006, 03:58 PM   #74
NetRAVEN5000
Member
 
Registered: May 2005
Distribution: Ubuntu 9.04
Posts: 320

Rep: Reputation: 30
Quote:
Originally Posted by jonaskoelker
I would like to stress very stongly that a backtrace is emphatically NOT the same as "step to reproduce", which is what you seem to be saying here.
That wasn't what I meant.

What I meant is that the user has to write down the "steps to reproduce" if they want to tell you the steps they took to reproduce the error. But with a backtrace - even though it doesn't tell you how to reproduce the error - all the user has to do is send you the results and that'll at least tell you something. It might not be as good as the user telling you the steps to reproduce the error, but it's much easier for the user to do.
Quote:
Originally Posted by tuxdev
I have to reproduce a bug in order to know whether or not I've fixed it. I have to reproduce it once as a control to know *exactly* what happened. The backtrace is not useful because it will be generated when I reproduce the bug. Analogy translated: "Give me a backtrace and I can know where it crashed. Give me steps to reproduce and I can know anything."
If you're the programmer, you should know how to test whether or not you fixed the bug. . .

In fact, a lot of times developers come up with "test data" they can enter. They run the program a few times, each time with different test data, knowing what the outcome of the program should be, and then if the test data doesn't produce the correct outcome, they can figure out what went wrong.

Are you suggesting that you don't understand your own code?

Last edited by NetRAVEN5000; 05-10-2006 at 04:11 PM.
 
Old 05-10-2006, 04:28 PM   #75
tuxdev
Senior Member
 
Registered: Jul 2005
Distribution: Slackware
Posts: 2,014

Rep: Reputation: 115Reputation: 115
Quote:
If you're the programmer, you should know how to test whether or not you fixed the bug. . .
by reproducing it or not.

Quote:
In fact, a lot of times developers come up with "test data" they can enter. They run the program a few times, each time with different test data, knowing what the outcome of the program should be, and then if the test data doesn't produce the correct outcome, they can figure out what went wrong.
Test data and bugs are not the same. Test data are initial attempts to see whether it mostly works. Bugs are errata that you may or may not have caught in your initial testing. Clear box testing vs. Black box testing. In the former case, I have steps to reproduce cause I generate them myself. In the later, somebody else needs to provide them.

Quote:
Are you suggesting that you don't understand your own code?
A lot of times, it isn't my code.
 
  


Reply

Tags
article, java


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Hate it....... sgrayban Conectiva 9 04-30-2005 06:24 PM
I hate it when... Tarts General 27 10-20-2003 05:32 PM
I hate to ask this but... TippyToes General 16 08-24-2003 08:23 PM
I hate it linuxdoesntwork Linux - Newbie 3 06-29-2003 05:05 PM
i hate this!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Jeffrey General 5 04-06-2001 02:04 AM


All times are GMT -5. The time now is 02:51 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration