Mailinglist Archive: opensuse-factory (661 mails)

< Previous Next >
Re: [opensuse-factory] The Future of SaX2
  • From: "Carlos E. R." <robin.listas@xxxxxxxxxxxxxx>
  • Date: Mon, 7 Dec 2009 13:33:29 +0100 (CET)
  • Message-id: <alpine.LSU.2.00.0912071328080.4905@xxxxxxxxxxxxxxxx>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On Monday, 2009-12-07 at 11:48 +0100, Petr Baudis wrote:

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:

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

daunting...


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.

Certainly not! Do you compare vi with borland's class full IDE? X'-)


gdb, info, vi... those are the precise examples that send me running for my life :-)



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.

It is a big deal if a chap with no previous knowledge of that code is trying to lend a hand, understand how the program should work, and then find out why it doesn't.

- -- Cheers,
Carlos E. R.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAksc9hsACgkQtTMYHG2NR9WDzgCgjN97LgAlwb1qgyXsVmC7tyHl
XBcAniYK3ZVX0/MaAs15A/jkiA5pK+4G
=Gjym
-----END PGP SIGNATURE-----
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx

< Previous Next >
This Thread
Follow Ups