[9fans] OT: programming style under Plan9??

[9fans] OT: programming style under Plan9??

[I RATTAN]

I have observed that that the Plan9 C-code generally
consists fo ALL modules of a program are in the same file.
Is it deliberate or a matter of style? It does make life
easier in terms of include files but seems a bit little off
key in context that C supports separate compilation of modules
and hence, each module could be in a file of its own! I was accused
of being University type in comp.lang.python for asking how
keep each modules in a separate file  and make the program
work correctly.

Thanks in advance.
-ishwar

Re: [9fans] OT: programming style under Plan9??

[Ronald G. Minnich]

I don't know, all I know is that when I moved Xen over I put all the files 
in two places:
xen.h (arch-independent)
xenpc.h (arch-dependent)

wow, was life easier. I think the linux side of the house over-does the 
seperation of things into different files.

ron

Re: [9fans] OT: programming style under Plan9??

[Brantley Coile]

Speaking as a semi old fart, some of the early structure of
programs into separate files was just to keep the file
small enough to compile quickly.  Dennis' pdp11 compiler
was a number of files that all essentially got cat'ed together.
Back when a MIP was a real MIP and you had only one,
having the source in small files really sped up compilation.
You could get a lot more work done in a given amount of time.
The first thing I noticed when I first saw the Plan 9 code in 1990
was how header definitions were combined into the same file.
This turned out to be a great win.

Of course, a more constructive answer would be to get a copy
of ``The Practice of Programming'' by Kerninghan and Pike.

I would make the remark that C doesn't have modules.  After
compiling the code type information is lost and you can link
to anything that will resolve a name.  For example I can treat
the name qsort(3) as an array of integers.  The loader will resolve
the name qsort and the code in main will just do what I told it to.
This in in contrast to Wirth's Oberon that does type checking
at compile, link and runtimes.


#include <stdio.h>

extern int qsort[10];

void
main(void)
{
         int i;

         for (i = 0; i < 10; i++)
                 printf("%08x\n", qsort[i]);
         exit(0);
}
   Brantley


On Apr 1, 2005, at 8:34 PM, I RATTAN wrote:

> I have observed that that the Plan9 C-code generally
> consists fo ALL modules of a program are in the same file.
> Is it deliberate or a matter of style? It does make life
> easier in terms of include files but seems a bit little off
> key in context that C supports separate compilation of modules
> and hence, each module could be in a file of its own! I was accused
> of being University type in comp.lang.python for asking how
> keep each modules in a separate file  and make the program
> work correctly.
>
> Thanks in advance.
> -ishwar
>

Re: [9fans] OT: programming style under Plan9??

[Russ Cox]

> I would make the remark that C doesn't have modules.  After
> compiling the code type information is lost and you can link
> to anything that will resolve a name.  For example I can treat
> the name qsort(3) as an array of integers.  The loader will resolve
> the name qsort and the code in main will just do what I told it to.

now fixed on plan 9:

% cat x.c
#pragma lib "libc.a"

extern int qsort[];
extern int print(char*, ...);

void
main(void)
{
	int i;

	for(i=0; i<10; i++)
		print("%08ux\n", qsort[i]);
}
% 8c -T x.c
% 8l x.8
qsorts: incompatible type signatures b3a1d3d5(x.8) and
c7dcac09(/386/lib/libc.a(qsort)) for qsort
%

Re: [9fans] OT: programming style under Plan9??

[Gorka Guardiola]

> % 8c -T x.c
> % 8l x.8
> qsorts: incompatible type signatures b3a1d3d5(x.8) and
> c7dcac09(/386/lib/libc.a(qsort)) for qsort
> %

Wouldn't be interesting to have -T added to CFLAGS on the mkfile.proto?.

										G.

Re: [9fans] OT: programming style under Plan9??

[jmk]

On Mon Apr  4 05:57:16 EDT 2005, paurea@lsub.org wrote:
> 
> > % 8c -T x.c
> > % 8l x.8
> > qsorts: incompatible type signatures b3a1d3d5(x.8) and
> > c7dcac09(/386/lib/libc.a(qsort)) for qsort
> > %
> 
> Wouldn't be interesting to have -T added to CFLAGS on the mkfile.proto?.
> 
> 										G.

we do that here. the reason it was not pushed to sources is that
you must be careful about how you recompile and install all your
libraries and binaries when you turn it on.

all of /src has been made with -T, as forsyth mentioned, it found
a few small problems.

Re: [9fans] OT: programming style under Plan9??

[Charles Forsyth]

>>all of /src has been made with -T, as forsyth mentioned, it found
>>a few small problems.

it found a few big ones in some things not on sources, which in a sense
helped to justify it even for statically-linked programs.
to be fair to C, they all required some violation of the `.h' declaration
discipline, but they happened.

on the other hand, some other -T diagnostics turn up (even with things
in /src) when a .h changes but this or that .$O or .a has not been
recompiled, to discover a ulong -> uvlong change for instance.

of course, that's a violation of mkfile discipline, but
it's comforting to know that such oversights
are detected mechanically at ?l time.

Re: [9fans] OT: programming style under Plan9??

[Charles Forsyth]

>>This in in contrast to Wirth's Oberon that does type checking
>>at compile, link and runtimes.

the -T option to the compilers causes them to produce extra
data for type checking at link and dynamic load time.
this has found bugs.  not many, but a few.

Re: [9fans] OT: programming style under Plan9??

[noselasd]

>>>This in in contrast to Wirth's Oberon that does type checking
>>>at compile, link and runtimes.
> 
> the -T option to the compilers causes them to produce extra
> data for type checking at link and dynamic load time.
> this has found bugs.  not many, but a few.

.. "See dynld(2)."
Well, there is no dynld :-) Beeing a curious person, what is/was
dynld ?

Re: [9fans] OT: programming style under Plan9??

[jmk]

On Sat Apr  2 04:57:40 EST 2005, noselasd@asgaard.homelinux.org wrote:
> ...
> .. "See dynld(2)."
> Well, there is no dynld :-) Beeing a curious person, what is/was
> dynld ?

     DESCRIPTION
          These functions allow a process to load further code and
          data into the currently executing image.  A dynamically-
          loadable file, called a module here, is a variant of the
          a.out(6) executable format with some extra components.  The
          loader for the architecture (see 2l(1)) creates a module
          file from component object file(s) when given the -u option.
          A module contains text and data sections, an import table,
          an export table, and relocation data.  The import table
          lists the symbols the module needs from the loading program;
          the export table lists symbols the module provides when
          loaded.  A program that loads a module provides a table of
          its own symbols to match the symbols in the module's import
          table.

Last summer I did a kernel module driver but a better management scheme
was suggested and I ripped it out and started again. But never finished.

--jim

Re: [9fans] OT: programming style under Plan9??

[Devon H. O'Dell]

[-- Attachment #1: Type: text/plain, Size: 1463 bytes --]

On Sat, Apr 02, 2005 at 02:31:43PM -0500, jmk@plan9.bell-labs.com wrote:
> On Sat Apr  2 04:57:40 EST 2005, noselasd@asgaard.homelinux.org wrote:
> > ...
> > .. "See dynld(2)."
> > Well, there is no dynld :-) Beeing a curious person, what is/was
> > dynld ?
> 
>      DESCRIPTION
>           These functions allow a process to load further code and
>           data into the currently executing image.  A dynamically-
>           loadable file, called a module here, is a variant of the
>           a.out(6) executable format with some extra components.  The
>           loader for the architecture (see 2l(1)) creates a module
>           file from component object file(s) when given the -u option.
>           A module contains text and data sections, an import table,
>           an export table, and relocation data.  The import table
>           lists the symbols the module needs from the loading program;
>           the export table lists symbols the module provides when
>           loaded.  A program that loads a module provides a table of
>           its own symbols to match the symbols in the module's import
>           table.
> 
> Last summer I did a kernel module driver but a better management scheme
> was suggested and I ripped it out and started again. But never finished.
> 
> --jim

Need someone to finish this? I would really like it for the
filters I'm writing for nfil (/n/sources/dodell/nfil)

--Devon


[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: [9fans] OT: programming style under Plan9??

[jmk]

On Sat Apr  2 15:59:38 EST 2005, dodell@offmyserver.com wrote:
> ...
> Need someone to finish this? I would really like it for the
> filters I'm writing for nfil (/n/sources/dodell/nfil)
> 
> --Devon
> 

Thanks. But not right now. Maybe later.

Re: [9fans] OT: programming style under Plan9??

[Brantley Coile]

[-- Attachment #1: Type: text/plain, Size: 34 bytes --]

I gotta do another sources pull!

[-- Attachment #2: Type: message/rfc822, Size: 2396 bytes --]

From: Charles Forsyth <forsyth@terzarima.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] OT: programming style under Plan9??
Date: Sat, 2 Apr 2005 10:31:38 +0100
Message-ID: <cd8072d5d351e0a92cd500bb508e0075@terzarima.net>

>>This in in contrast to Wirth's Oberon that does type checking
>>at compile, link and runtimes.

the -T option to the compilers causes them to produce extra
data for type checking at link and dynamic load time.
this has found bugs.  not many, but a few.

Re: [9fans] OT: programming style under Plan9??

[Russ Cox]

> I have observed that that the Plan9 C-code generally
> consists fo ALL modules of a program are in the same file.

I don't think this is true at all.
Sure it's true of /sys/src/cmd/*.c, but that's
the directory that contains all the one-file programs,
and most of them are tiny enough that splitting them
up would just be annoying (there are exceptions).

But there are plenty of programs that are split into
separately compiled pieces, both in the sense of
libraries and just multiple files for different pieces
(look in /sys/src/cmd/acme for example).

I split my programs into pieces that make it easier
for me to think about.  If that happens to coincide
with what some people call modules, great, and
if it doesn't, well too bad for them.

Russ

Re: [9fans] OT: programming style under Plan9??

[I RATTAN]

On Fri, 1 Apr 2005, Russ Cox wrote:

> I split my programs into pieces that make it easier

Does a piece imply that it is/has to be in a file of it's own or
in the same file with all the other pieces? So, it feels like a
style of writing code.

-ishwar

Re: [9fans] OT: programming style under Plan9??

[Ronald G. Minnich]

On Sat, 2 Apr 2005, I RATTAN wrote:

> Does a piece imply that it is/has to be in a file of it's own or in the
> same file with all the other pieces? So, it feels like a style of
> writing code.

I don't know but I think you're splitting hairs. The kernel, last time I 
looked, was in more than one file. I really don't see your point at all. 


ron