Mailing List Archive

On 18 Jan 2008, at 16:24, Michael G Schwern wrote:
> Suggestions?


I'd say the usual advice applies. Just write some XS (or standalone C)
that does something interesting and Google anything that doesn't make
sense.

--
Andy Armstrong, Hexten

On Friday 18 January 2008 17:24, Michael G Schwern wrote:
>
> So where's the "C for Perl Programmers" book/tutorial/etc...?
<snip>
> But where's the "explaining C insanity in terms of Perl insanity" book? Or
> even "C for Dynamic Programmers"?
>
Yeah - very good idea! It's probably never been proposed because people would
be too embarrased to say they don't already know how to program in C. I'm a
Perl programmer, and I don't program in C, or C++, or **** knows what -
there, said it!

> Suggestions?
>
Write one ?-)

Ok, you just knew some smart arse was going to say that, didn't you? And you
just said you aren't the one to do that, Michael, but maybe I mean you need
to get a couple of C people, and a couple of Perl people, together, and
thrash something out. It's a damn good idea, there's a distinct gap on the
bookshelf there, IMVHO.

--
Richard Foley
Ciao - shorter than aufwiedersehen

http://www.rfi.net/

Michael G Schwern <schwern@pobox.com> wrote:
> So where's the "C for Perl Programmers" book/tutorial/etc...? There's
> Simon Cozens' old "Embedding and Extending Perl" book, which is handy, and
> APP has a little bit of C in it, and perlguts. But where's the "explaining
> C insanity in terms of Perl insanity" book? Or even "C for Dynamic
> Programmers"?

I'm not sure these are of help, but nevertheless a few starting points:

http://perldoc.perl.org/index-internals.html
http://www.perl.org/tpc/1998/Perl_Language_and_Modules/Perl%20Illustrated/

Steven Schubiger

On Fri, 18 Jan 2008, Steven Schubiger wrote:
> Michael G Schwern <schwern@pobox.com> wrote:
> > So where's the "C for Perl Programmers" book/tutorial/etc...? There's
> > Simon Cozens' old "Embedding and Extending Perl" book, which is handy, and
> > APP has a little bit of C in it, and perlguts. But where's the "explaining
> > C insanity in terms of Perl insanity" book? Or even "C for Dynamic
> > Programmers"?
>
> I'm not sure these are of help, but nevertheless a few starting points:
>
> http://perldoc.perl.org/index-internals.html
> http://www.perl.org/tpc/1998/Perl_Language_and_Modules/Perl%20Illustrated/

You can find the latest version of the document on CPAN:

http://search.cpan.org/src/GAAS/illguts-0.09/index.html

It is still quite a bit out-of-date regarding 5.10 internals changes though,
but still the best illustration you can get.

Cheers,
-Jan

On Fri, 18 Jan 2008, Steven Schubiger wrote:

> Michael G Schwern <schwern@pobox.com> wrote:
>> So where's the "C for Perl Programmers" book/tutorial/etc...? There's
>> Simon Cozens' old "Embedding and Extending Perl" book, which is handy, and
>> APP has a little bit of C in it, and perlguts. But where's the "explaining
>> C insanity in terms of Perl insanity" book? Or even "C for Dynamic
>> Programmers"?
>
> I'm not sure these are of help, but nevertheless a few starting points:
>
> http://perldoc.perl.org/index-internals.html
> http://www.perl.org/tpc/1998/Perl_Language_and_Modules/Perl%20Illustrated/

This sort of stuff is useful, but it won't really teach you how to program
C. I know C syntax and its basic usage, enough to read the XS API docs and
do some simple stuff in XS, like write some of DateTime's math or examine
Perl data structures in Params::Validate.

However, I still don't really _know_ C. C the language is fairly simple
and small, but learning it doesn't really get you far. It seems that
"knowing C" is more a matter of knowing the practice of programming C,
which includes such things as ...

* How memory management should be done

* How and when to do funky things with pointers

* What is in the std library, how to use it portably, when not to use it
because it's insecure

* C differences across platforms

* Data structures, particularly how to make a "proper" struct

* How to use the preprocessor sanely

And that's not even getting into things like support tools (make) or
configuration probing, which seems to be an integral part of any FS/OSS
work in C.

Personally I would _love_ to find a book to teach me this stuff. It seems
like it'd open up a whole interesting range of projects, including the
Perl core, Parrot, etc.


-dave

/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/

On Jan 18, 2008, at 6:50 AM, Richard Foley wrote:

> On Friday 18 January 2008 17:24, Michael G Schwern wrote:
>>
>> So where's the "C for Perl Programmers" book/tutorial/etc...?
> <snip>
>> But where's the "explaining C insanity in terms of Perl insanity"
>> book? Or
>> even "C for Dynamic Programmers"?
>>
> Yeah - very good idea! It's probably never been proposed because
> people would
> be too embarrased to say they don't already know how to program in
> C. I'm a
> Perl programmer, and I don't program in C, or C++, or **** knows
> what -
> there, said it!
>

When I wrote the "how to use C" chapter of "Extending and Embedding
Perl" I was astonished by the number of reviewers who said it was a
waste of time and that we should not be teaching C to perl programmers
and anybody who wants to use XS should already know C. Happily, most
people I've met who weren't C programmers welcomed the introductory
chapters.

--
Tim Jenness
Joint Astronomy Centre

On Fri, Jan 18, 2008 at 08:24:37AM -0800, Michael G Schwern wrote:

> I realize I wind up saying "someone who knows C should..." a lot and "I'm
> not a C programmer". I'd like to fix that, if nothing else then to not
> distract real C programmers from doing real work on perl with my silly
> ideas.
>
> So where's the "C for Perl Programmers" book/tutorial/etc...? There's
> Simon Cozens' old "Embedding and Extending Perl" book, which is handy, and
> APP has a little bit of C in it, and perlguts. But where's the "explaining
> C insanity in terms of Perl insanity" book? Or even "C for Dynamic
> Programmers"?
>
> Suggestions?

I suspect that you still can't go wrong with K&R. It's been a while
since I've learnt C and it's possible there are other well recommended
books now. But I don't know about ones targeted at Perl or dynamic
language programmers.

The basics shouldn't be at all tough for a proficient Perl programmer to
pick up. Aspects that probably need special attention include:

- types
- pointers and arrays
- memory management and layout
- headers
- the preprocessor
- library functions
- linking
- debuggers / valgrind etc
- anger management

That's off the top of my head. There's probably a few important things
I've completely forgotten.

--
Paul Johnson - paul@pjcj.net
http://www.pjcj.net

On 18 Jan 2008, at 20:00, Paul Johnson wrote:
> - anger management


Heh. C is lovely - but Perl certainly makes you intolerant to the
hoops you must jump through. Describing C as "high level assembler"
isn't just an amusing quip - it's practical advice on how to approach
it that will make it more bearable. If you remember how close the
metal[1] you are you might be more tolerant to its foibles.

[1] For practical purposes closer than assembler these days -
efficient instruction scheduling has become a black art for all but
the most determined - or a compiler.

--
Andy Armstrong, Hexten

Paul Johnson <paul@pjcj.net> wrote:
:I suspect that you still can't go wrong with K&R.

Seconded.

<http://en.wikipedia.org/wiki/The_C_Programming_Language_%28book%29>
for those that don't recognise the abbreviation.

Hugo

> * What is in the std library, how to use it portably, when not to use
> it because it's insecure
I find http://ccs.ucsd.edu/c/ to be pretty useful as a standard reference.

>
> * How memory management should be done
>
> * How and when to do funky things with pointers
>
> * C differences across platforms
>
> * Data structures, particularly how to make a "proper" struct
>
> * How to use the preprocessor sanely
Those are pretty much answered by "stick to the standard".

Vincent.

On 18 Jan 2008, at 20:20, Vincent Pit wrote:
>
>> * What is in the std library, how to use it portably, when not to
>> use it because it's insecure
> I find http://ccs.ucsd.edu/c/ to be pretty useful as a standard
> reference.
>
>>
>> * How memory management should be done
>>
>> * How and when to do funky things with pointers
>>
>> * C differences across platforms
>>
>> * Data structures, particularly how to make a "proper" struct
>>
>> * How to use the preprocessor sanely
> Those are pretty much answered by "stick to the standard".


No, no - things like creating memory pools - which are important
techniques - are not any part of the standard. You probably can't
guess all the useful preprocessor idioms just by learning the standard
either. And what about an opaque pointer to a private structure? Sure
it's /within/ the standard - but the standard doesn't explain the idiom.

--
Andy Armstrong, Hexten

Dave Rolsky <autarch@urth.org> wrote:
> This sort of stuff is useful, but it won't really teach you how to program
> C. I know C syntax and its basic usage, enough to read the XS API docs and
> do some simple stuff in XS, like write some of DateTime's math or examine
> Perl data structures in Params::Validate.
>
> However, I still don't really _know_ C. C the language is fairly simple
> and small, but learning it doesn't really get you far. It seems that
> "knowing C" is more a matter of knowing the practice of programming C,
> which includes such things as ...

[...]

> Personally I would _love_ to find a book to teach me this stuff. It seems
> like it'd open up a whole interesting range of projects, including the
> Perl core, Parrot, etc.

Two related (basic to advanced) C books I enjoyed:

http://en.wikipedia.org/wiki/K&R (as mentioned by Paul Johnson)
http://en.wikipedia.org/wiki/The_Practice_of_Programming

The K&R is worth its price, but perhaps you might be more interested
in latter one which is IMHO more practical oriented and strives to
teach programming "principles" that apply to C (among other languages,
albeit the majority pertain to C).

Steven Schubiger

> No, no - things like creating memory pools - which are important
> techniques - are not any part of the standard.
Fair enough. But if you have a good understanding of the standard, they
aren't much difficult to implement.

> You probably can't guess all the useful preprocessor idioms just by
> learning the standard either.
Granted.

> And what about an opaque pointer to a private structure? Sure it's
> /within/ the standard - but the standard doesn't explain the idiom.
I never found that to be really useful. It really feels like trying to
hide by putting your head under the sand.

On 18 Jan 2008, at 20:42, Vincent Pit wrote:
>> And what about an opaque pointer to a private structure? Sure it's /
>> within/ the standard - but the standard doesn't explain the idiom.
> I never found that to be really useful. It really feels like trying
> to hide by putting your head under the sand.

Maybe so - but it's still useful to be able to understand the intent
if you read someone else's code.

(and personally I use 'em all the time - but that's not germane)

--
Andy Armstrong, Hexten

On Fri, 18 Jan 2008, Steven Schubiger wrote:

>> Personally I would _love_ to find a book to teach me this stuff. It seems
>> like it'd open up a whole interesting range of projects, including the
>> Perl core, Parrot, etc.
>
> Two related (basic to advanced) C books I enjoyed:
>
> http://en.wikipedia.org/wiki/K&R (as mentioned by Paul Johnson)

I've read K&R. It doesn't really cover _any_ of the things I mentioned. It
mostly teaches you the syntax, and it covers only a very small part of the
standard library.

> http://en.wikipedia.org/wiki/The_Practice_of_Programming

I _thought_ I read this, but I can't find it on my bookshelf. Weird. If
it's the one I remember it's more about programming principles than
idiomatic C.


-dave

/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/

On Fri, Jan 18, 2008 at 09:00:13PM +0100, Paul Johnson wrote:

> Aspects that probably need special attention include:
>
> - types
> - pointers and arrays
> - memory management and layout
> - headers
> - the preprocessor
> - library functions
> - linking
> - debuggers / valgrind etc
> - anger management
>
> That's off the top of my head. There's probably a few important things
> I've completely forgotten.

One important chapter I'd like to see in a hypothetical "C for people
who can already program in another language" book is how to use all the
various bits of the C toolchain (cc, cpp, as, ld, nm, ranlib, even a make
primer) together and what they do. You can be a very good *perl*
programmer (or python, java, ruby or lots of other languages) without
having much exposure to any of those and certainly without ever invoking
any of them yourself except to type 'make && make test && make install'.

--
David Cantrell | Godless Liberal Elitist

Did you know that shotguns taste like candy canes? Put the barrel in
your mouth and pull the trigger for an extra blast of minty goodness!

Steven Schubiger wrote:
> Dave Rolsky <autarch@urth.org> wrote:
>> This sort of stuff is useful, but it won't really teach you how to program
>> C. I know C syntax and its basic usage, enough to read the XS API docs and
>> do some simple stuff in XS, like write some of DateTime's math or examine
>> Perl data structures in Params::Validate.
>>
>> However, I still don't really _know_ C. C the language is fairly simple
>> and small, but learning it doesn't really get you far. It seems that
>> "knowing C" is more a matter of knowing the practice of programming C,
>> which includes such things as ...
>
> [...]
>
>> Personally I would _love_ to find a book to teach me this stuff. It seems
>> like it'd open up a whole interesting range of projects, including the
>> Perl core, Parrot, etc.
>
> Two related (basic to advanced) C books I enjoyed:
>
> http://en.wikipedia.org/wiki/K&R (as mentioned by Paul Johnson)
> http://en.wikipedia.org/wiki/The_Practice_of_Programming
>
> The K&R is worth its price, but perhaps you might be more interested
> in latter one which is IMHO more practical oriented and strives to
> teach programming "principles" that apply to C (among other languages,
> albeit the majority pertain to C).

This one is also very good (published in 1994)

Title: Expert C Programming
Author: Peter van der Linden
URL: http://www.informit.com/store/product.aspx?isbn=0131774298


jpo
--
José Pedro Oliveira
* mailto:jpo@di.uminho.pt *

Jose Pedro Oliveira schrieb:
> Steven Schubiger wrote:
>> Two related (basic to advanced) C books I enjoyed:
>>
>> http://en.wikipedia.org/wiki/K&R (as mentioned by Paul Johnson)
>> http://en.wikipedia.org/wiki/The_Practice_of_Programming
>>
>> The K&R is worth its price, but perhaps you might be more interested
>> in latter one which is IMHO more practical oriented and strives to
>> teach programming "principles" that apply to C (among other languages,
>> albeit the majority pertain to C).
>
> This one is also very good (published in 1994)
>
> Title: Expert C Programming
> Author: Peter van der Linden
> URL: http://www.informit.com/store/product.aspx?isbn=0131774298

If you want to explore the darker and thus more interesting sides of C
in a very entertaining way, I can recommend

Obfuscated C and Other Mysteries
by Don Libes
ISBN 0471578053

One half of the book presents and analyses winning entries in the
international obfuscated C contest (Larry Wall has won it twice and at
least one of his entries is presented), the other half covers some very
useful programming techniques. It's not a first read, but even beginners
will profit from it (and have fun too).

Roland

On Jan 18, 2008, at 8:24 AM, Michael G Schwern wrote:

> But where's the "explaining C insanity in terms of Perl insanity"
> book? Or even "C for Dynamic Programmers"?

FWIW, I taught myself C via Perl -> Inline::C -> XS -- so people like
you and Rolsky ought to be able to pull the same stunt. And maybe my
mistakes and learning trajectory will presage your own.

The first thing I'd mention is that you will want to learn how to use
valgrind sooner rather than later. The earliest advice we give to
novice Perl programmers is to turn on strict and warnings. Well,
running C programs under valgrind is like turning on 'warnings'.
Hunting down segfaults without it is maddening and occasionally
impossible. Plus it will alert you about all kinds of other
problems, e.g. certain memory leaks.

The second thing I'd mention is to use GCC and compile everything
using "gcc -ansi -pedantic -Wall -Wextra". Add -DPERL_GCC_PEDANTIC
when compiling XS. Same rationale -- give yourself maximum
strictness and maximum warnings.

As far as books, well, there wasn't any one book that really fit the
bill. My education actually started off with the first few chapters
of Stephen Prata's book on C++ many moons ago, which was enough to
teach types and IO fundamentals. But any basic book on C would have
substituted; K&R would have been fine. And yet no book on pure C
would have been that great. There's a lot of stuff in the standard
library that's worthless or worse, particularly with regards to C's
abysmal string handling. Learning the idiomatic way to write a text-
processing app in C doesn't help much.

I did pick up Extending and Embedding Perl and I like it. But what
was really useful was having concrete goals that could only be
realized by programming C, and having forums where I could ask
questions when I got stuck. The perl-xs and Inline C mailing lists
were very helpful. So was Perlmonks.

HTH,

Marvin Humphrey
Rectangular Research
http://www.rectangular.com/

On Jan 18, 2008, at 11:56 AM, Dave Rolsky wrote:

> * How memory management should be done

Mastering the stack and the heap isn't too tough. Refcounting and
garbage collection are difficult topics -- but for XS at least, you
don't have to worry about designing the algo, just managing your SV
refcounts correctly.

> * How and when to do funky things with pointers

Pointers are so closely analogous to Perl references, I think you'll
find this to be easier than it seems.

> * What is in the std library, how to use it portably, when not to
> use it because it's insecure

Security is a huge, important issue. IMO, if you are writing public
C code, particularly for an environment as hostile as the web, you
need to understand the material this book covers:

Secure Coding in C and C++
Robert C. Secord
http://www.cert.org/books/secure-coding/

It's not a beginner book, but it's very, very good.

> * C differences across platforms

The thing that spurred me to learn this was having my XS distros fail
on Windows. To solve the problem, I donned the hair shirt: I
installed the free version of MSVC on a Windows box, compiled Perl,
and kept plugging away until everything worked.

The experience was painful and time-consuming. It would be less so
now, since 5.10 compiles with minimal fuss under MSVC 8 (Thank you
Steve Hay!) but ExtUtils::CBuilder still has some frustrating
limitations.

I don't think there's a good answer for this besides actually going
out and doing the hard work of compiling within unfamiliar
environments yourself. C90 is highly portable, but limiting yourself
to C90 isn't realistic.

> * Data structures, particularly how to make a "proper" struct

Not sure what you mean by that.

> * How to use the preprocessor sanely

Heh.

> And that's not even getting into things like support tools (make)
> or configuration probing, which seems to be an integral part of any
> FS/OSS work in C.

As for configuration programming, take a look a ./Configure.

The main thing that configuration probers do is compile lots of tiny
test programs and see what happens. Do they build successfully?
What do they print? Etc. That's how ./Configure works. It's also
how Autoconf works.

When writing stuff purely for extending Perl, you can pretty much
take advantage of the symbols that ./Configure generates and which
are part of the perlapi.

For other FS/OSS work, most people use Autoconf. However, I didn't
really cotton to Autoconf, so I decided to reinvent that wheel and
wrote a tool called Charmonizer that basically uses C to probe and
configure C. In the process, I learned the wisdom of the Larry Wall
quote "It is easier to port a shell than a shell script" but I also
learned a lot about C. :)

I'm not sure writing my own probing tool was the right way to go, but
it seems to work and maybe someday it will escape into an independent
release. Here's the repository URL if you'd like to browse:

http://www.rectangular.com/svn/kinosearch/trunk/charmonizer/

HTH,

Marvin Humphrey
Rectangular Research
http://www.rectangular.com/

On Jan 18, 2008, at 1:27 PM, David Cantrell wrote:

> as, ld,

Here's a good paper on linking and ld by Ulrich Drepper:

http://people.redhat.com/drepper/dsohowto.pdf

And there's an excellent introductory book on Gas, the Gnu assembler,
available both on paper and as a PDF under the GNU Free Documentation
License: "Programming from the Ground Up", by Jonathan Bartlett.

http://xrl.us/6t7x (Link to search.barnesandnoble.com)
http://savannah.nongnu.org/projects/pgubook/
http://download.savannah.gnu.org/releases/pgubook/

Marvin Humphrey
Rectangular Research
http://www.rectangular.com/

Michael G Schwern wrote:
> I realize I wind up saying "someone who knows C should..." a lot and
> "I'm not a C programmer". I'd like to fix that, if nothing else then to
> not distract real C programmers from doing real work on perl with my
> silly ideas.
>
> So where's the "C for Perl Programmers" book/tutorial/etc...? There's
> Simon Cozens' old "Embedding and Extending Perl" book, which is handy,
> and APP has a little bit of C in it, and perlguts. But where's the
> "explaining C insanity in terms of Perl insanity" book? Or even "C for
> Dynamic Programmers"?
>
> Suggestions?

First off, I'd like to thank everyone that responded with resources and
specific desires. Seems I'm not the only one who needs this. I'll organize
what we've got on the wiki eventually (or someone will please beat me to the
punch).

But there's something key missing. I'm not just looking for information on
learning C, I'm looking on information to /translate/ ideas from Perl to C.
At least mentally. I think in scalars, hashes and arrays. What's the C
equivalent? Perl handles array/number issues for me, how do I do it in C?
Sure, pointers are like references... but they're not. What are the traps I'm
going to fall into thinking like a Perl programmer? Like, "you need parens
around functions!" Getting the analogies right for your audience can greatly
speed up learning.

More importantly, I want something for an experienced programmer. Not "and
this is called a loop. Can you say 'loop'?"

mjd had a great article years ago about teaching Perl to COBOL mainframe
programmers. He was completely floored by what they didn't know, like just
opening a file was a completely foreign idea. But I/O buffering? No problem.
They didn't know what "filehandles" were but they did know how to "establish
the addressability of a file". Getting the jargon right was very important.
http://www.perl.com/pub/a/2000/05/cobol.html


--
164. There is no such thing as a were-virgin.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
http://skippyslist.com/?page_id=3

On Jan 18, 2008, at 2:11 PM, hv@crypt.org wrote:

> <http://en.wikipedia.org/wiki/The_C_Programming_Language_%28book%29>
> for those that don't recognise the abbreviation.


I'm just surprised that nobody mentioned Harbison & Steele.

C: A Reference Manual, (Prentice-Hall, 1984; ISBN 0-13-110016-5)

As to the idioms, thinking of hashes in C, and so on: You can't.
There aren't any. That's why those of us who started using C saw Awk
and Perl as such a godsend.

xoxo,
Andy

--
Andy Lester => andy@petdance.com => www.petdance.com => AIM:petdance

On Fri, 18 Jan 2008, Marvin Humphrey wrote:

> On Jan 18, 2008, at 11:56 AM, Dave Rolsky wrote:
>
>> * How memory management should be done
>
> Mastering the stack and the heap isn't too tough. Refcounting and garbage
> collection are difficult topics -- but for XS at least, you don't have to
> worry about designing the algo, just managing your SV refcounts correctly.

Yes, I know how to manage SVs in XS (more or less). But the thread started
in the context of hacking the Perl core, not XS. XS is actually
significantly easier than "plain C" because the Perl XS API actually gives
a lot of stuff for free, like useful data structures and
reference-counted memory management.

>> * How and when to do funky things with pointers
>
> Pointers are so closely analogous to Perl references, I think you'll find
> this to be easier than it seems.

I know the relationship, but it seems that the motivation for using
pointers is often different than that for using references.

>> * Data structures, particularly how to make a "proper" struct
>
> Not sure what you mean by that.

People always talk about boundary alignments, and other gibberish. I also
didn't mention things like unions (why use them?) and other weirdness. I
guess I've seen a lot of C, and didn't understand it.


Really what I want is 'Effective Perl Programming' =~ s/Perl/C/;


-dave

/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/