Mailinglist Archive: opensuse-factory (661 mails)

< Previous Next >
Re: [opensuse-factory] The Future of SaX2
  • From: Petr Baudis <pasky@xxxxxxx>
  • Date: Mon, 7 Dec 2009 11:48:42 +0100
  • Message-id: <20091207104842.GK31833@xxxxxxxxxxxxx>
Hi!

Maybe I'm just touching the concrete examples, I just try to show that
things aren't that bad.

On Mon, Dec 07, 2009 at 01:56:15AM +0100, Carlos E. R. wrote:
On Sunday, 2009-12-06 at 17:22 -0600, Rajko M. wrote:

On Sunday 06 December 2009 12:12:10 Egbert Eich wrote:

However for contributing small things, look
at the code to track down a bug doesn't require very good probramming
skills.

It often requires just ability to set break point with a message, to locate
code that makes trouble. No much need to understand the code.

It is not only code, it is tools. I used turbodebugger (Borland), locally
or over a serial port. I can't use the linux debugger, I have no idea how.

Perhaps this two-page intro might be useful?

http://linux.bytesex.org/gdb.html

For my taste, for a basic intro it is missing just two things, 'next'
for step without recursion and 'info threads' for examining other
threads.

To program in C I used borland C IDE. You press ctrl-F1 over a function
and you get help on that particular function. Or you you browse the help
index to find a function to do something... AFAIK that is not possible
here. Plus, I got a set of books, in paper, explaining the set of
libraries I got. Explaining how to do things... Yes, here there is
documentation, but you have to find it. Dispersed.

If you use vi, move over the function with cursor and press 'K' (if a
shell command documentation pops up instead, try '3K' or '2K'). I'm sure
other editors have similar gadgets.

When I was taught C they "forced" me to write a small preamble on each
file explaining what this file of source code this. To document each and
every function on what input to receive, what output it produced, what
variables it changed, and what it did. To write a document on how the
program worked; not a user documentation, but a developer documentation.
Both, actually.

I don't see that kind of effort here.

That is true, some may see it as bigger problem, others as smaller. If
you are debugging the net stack code, that's quite troublesome, if you
are debugging crash in some simple tool, I don't think that's that a big
deal. Also, individual software packages differ a lot.

--
Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx

< Previous Next >
This Thread
Follow Ups