On 07/22/09 05:21, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> IME, programs written in C are almost always unreadable. But I'm biased. ;-)
>
>    Your problem is that you refuse to aknowledge readability even for examples
> which clearly are, probably because of some principle.

	Well, just because C is more readable than Haskell doesn't mean it's 
readable.<G>

	If David is still reading, I can sympathize with him being scared of 
OOP if he was introduced to it via C++ or Java. Constructors can be a 
pain in C++, along with other problems. I'd suggest some "simple" 
language like Python where the syntax won't get in the way of 
understanding the OO principles.

-- 
When the lion was given his courage, he promptly ate up the Wizard, 
Dorothy, the scarecrow and the tinman.

Post a reply to this message

On 07/22/09 04:13, David H. Burns wrote:
> I was told I was off topic in the programming group -- or maybe it's

	There's a newsgroup for discussing ideas about POV-Ray 4:

povray.pov4.discussion.general

-- 
When the lion was given his courage, he promptly ate up the Wizard, 
Dorothy, the scarecrow and the tinman.


                     /\  /\               /\  /
                    /  \/  \ u e e n     /  \/  a w a z
                        >>>>>>mue### [at] nawazorg<<<<<<
                                    anl

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> >> I see. So you still have to manually define what needs to be linked somehow?
> > 
> >   How else is the compiler going to know which files are your source files?
> > By reading your mind?

> Well, that's what I was puzzled by, yes. You guys seemed to be 
> suggesting that you just give VS a bunch of files and it somehow "knows" 
> how to produce a runnable executable out of them.

  Well, that is how an IDE works. You give it a bunch of source files and
it knows how to create a runnable executable out of them.

> >   That's what dynamic linking is all about. That's why they are called
> > "dynamically linked libraries". The OS performs runtime linking when the
> > program is launched: It goes through the program and sets jump addresses
> > to their proper values.

> This implies that an executable file contains some metadata in addition 
> to the executable machine code itself.

  That's correct.

-- 
                                                          - Warp

Post a reply to this message

>>>> I see. So you still have to manually define what needs to be linked somehow?
>>>   How else is the compiler going to know which files are your source files?
>>> By reading your mind?
> 
>> Well, that's what I was puzzled by, yes. You guys seemed to be 
>> suggesting that you just give VS a bunch of files and it somehow "knows" 
>> how to produce a runnable executable out of them.
> 
>   Well, that is how an IDE works. You give it a bunch of source files and
> it knows how to create a runnable executable out of them.

Well, certainly you give it a bunch of files and it knows how to compile 
them. But do you want it to link them all into a single executable? Or 
maybe two seperate executables? Or perhaps you're trying to produce a 
DLL? Presumably you have to configure this somewhere...

>> This implies that an executable file contains some metadata in addition 
>> to the executable machine code itself.
> 
>   That's correct.

Interesting. I thought it was only object files that contain linker 
tables...

Mind you, having just said that... various programs have custom icons 
and so forth. That's definitely not executable code. Hmm...

[Now the old MS-DOS *.com files really *are* just bare machine code, 
always loaded at a specific machine address...]

Post a reply to this message

Invisible wrote:
> 1. How does it know which files depend on which other files?

Trivially, it compiles the file and sees which other files it opens during 
the compilation. With GCC, you can even give a command-line parameter to 
generate a makefile from the compilation. (-M or some such)

> 2. A header file is what defines what can be accessed from outside a 
> given source file. Without a header file, how do you determine what's 
> supposed to be public and what isn't?

No. You're thinking that header files are part of the language or something. 
It's just a convention.  If you're accessing something outside of the file 
you're compiling, you declare it "extern". It's convenient to put the 
"externs" in a separate files, but it isn't necessary.

> (C is a lot simpler, it's 
> just astonishingly easy to shoot yourself in the foot with it.)

Yes. Maybe you should try something intermediary first, like C# or Java or 
Pascal or some such.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

>> 2. A header file is what defines what can be accessed from outside a 
>> given source file. Without a header file, how do you determine what's 
>> supposed to be public and what isn't?
> 
> No. You're thinking that header files are part of the language or 
> something. It's just a convention.  If you're accessing something 
> outside of the file you're compiling, you declare it "extern". It's 
> convenient to put the "externs" in a separate files, but it isn't 
> necessary.

I see...

I know a header file can theoretically contain anything. But I always 
thought that the idea was to put only public things in a header file, 
because if it's not in the header file, other files can't know it exists 
so it can't be accessed.

>> (C is a lot simpler, it's just astonishingly easy to shoot yourself in 
>> the foot with it.)
> 
> Yes. Maybe you should try something intermediary first, like C# or Java 
> or Pascal or some such.

Java and Pascal I already have quite extensive experience with. 
(Although I imagine since the last time I touched Java the APIs have 
been changed *again*. Oh, and I hear they kludged in generics?) Both of 
these languages know the difference between a pointer and an array, however.

Post a reply to this message

Invisible wrote:
> True. But presumably if you #include a file that defines a function 
> prototype, you also need to compile and link whatever file it is that 
> contains the source code for that function?

Nope. Only if you actually call the function.  Don't confuse dependencies on 
source files with dependencies on library files.

> (Except for the OS header 
> files; I have literally *no clue* how that works...)

Exactly the same way, except the compiler by default knows where to look for 
those libraries.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Well, certainly you give it a bunch of files and it knows how to compile 
> them. But do you want it to link them all into a single executable? Or 
> maybe two seperate executables?

  If you want two separate executables, you create two separate projects.
(In most IDEs you can create multiple projects inside one single "solution",
as Visual Studio calls it.)

  If you want to build a DLL, you tell it that in the project settings.

-- 
                                                          - Warp

Post a reply to this message

Neeum Zawan wrote:

I am still reading and enjoying.

David

>     If David is still reading, I can sympathize with him being scared of 
> OOP if he was introduced to it via C++ or Java. Constructors can be a 
> pain in C++, along with other problems. I'd suggest some "simple" 
> language like Python where the syntax won't get in the way of 
> understanding the OO principles.
>

Post a reply to this message

Invisible wrote:
> I see. So you still have to manually define what needs to be linked 
> somehow?

Lets just say I'm working with source files right now where the line used to 
compile the file takes up more than one screen of text in the editor.

> - You write foo.c that contains a function called foo().

OK. A function *definition*.

> - You write foo.h which simply states that a function called foo() 
> exists somewhere.

A function *declaration*.

> - main.c does a #include "foo.h"

Which is exactly the same as if you had copied the text of foo.h into main.c.

> - When main.c is compiled, it produces main.o, which contains several 
> references to a foo() that should exist somewhere, but we don't know 
> where yet.

No. Only if main() actually calls foo().

> - The linker takes main.o and foo.o, and replaces every jump to foo() 
> with a jump to an actual machine address. The resulting program is 
> actually runnable.

Sort of. That's called "linking." Then there's "loading", which is when you 
put it into memory and *again* adjust a bunch of addresses.

> What I can't figure out is what happens if foo() is actually a function 
> somewhere in the OS kernel. 

It isn't. The read() function in C, for example, is in the C runtime library 
(glibc or uclibc on Linux).  The linker always searches that library as part 
of the linking process (unless you're doing something funky like compiling 
the kernel). The read() function in that library is written in assembler 
(because C is really not very useful for this sort of work) and that 
assembler code copies items off the stack into machine registers and then 
invokes an assembler instruction that causes the CPU to set certain flags in 
the CPU registers that control permissions, change memory maps, and 
eventually winds up branching to a particular address in memory which the 
kernel has previously set to be a branch instruction to the code to handle 
read().  So read() is normal, except it's in a library the compiler always 
searches and contains assembly language.

> Presumably in each version of the kernel, 
> the base address of this function is going to be different... so how the 
> hell does the linker know what it is?

It doesn't. It executes a machine-code instruction that's essentially a 
software interrupt. (That's why you see things like DOS functions being 
described as "Int 21h" functions.)

It's an instruction that invokes an indirect branch.

> The way this works on the Amiga is that you can't just *call* an OS 
> function.

There's no memory protection or kernel mode on AmigaOS. It can't be multiuser.

> Like, if aux.c contains foo(), bar() and baz(), which of these should be 
> available from elsewhere? Normally if you only wanted foo() to be 
> public, you'd only put foo() in the header file.

Header files are 100% orthogonal to visibility. You're being confused by 
convention.

If your program defines foo(), it's visible. I.e., if you write
int foo() { ... }
then foo is visible in any source file holding that text.

If you write
extern int foo();
then foo is visible in any source file holding that text, but if you invoke 
it, you need to define it (see above) somewhere at link time.

That's your two choices.

When you actually call foo() from inside some other function, it has to be 
visible. (Actually, the C standard says it gets a default declaration, but 
nobody relies on that, because it was such a bad idea.)

> (And for God's sake 
> remember to update the header file when foo() changes its type signature!)

And for God's sake, remember to include the header file where you invoke it.

It hasn't anything to do with header files. You could build a whole OS with 
no header files. But if you changed the defintion of foo(), you'd have to 
find every file with an "extern int foo()" and change it to "extern long 
foo()", which is why people put them in include files.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Chambers wrote:
> This is similar to Java, although it is 
> not platform independent (there is a platform independent open source 
> version, called Mono, which is able to execute many .Net applications).

Actually, the CIL is indeed platform independent. What isn't is a large 
number of windowing libraries and a few others that are per-OS, primarily 
because you *can* get to some low-level stuff. There's virtually nothing in 
the definition of the libraries or language that would be difficult (as 
opposed to tedious) to implement on other OSes.  Of course, if you do things 
like inspect the Windows message pump, or you query the X server's WM 
properties, you're going to have unportable code. A Windows service is going 
to have different wrappers than a Linux service, because the two have 
fundamentally different operational mechanisms. *That* is where the 
non-portability bits come from.  Well, that and that it hasn't been ported 
too much yet.

> There are other technologies and features, of course, mostly aimed at 
> interoperability of various system components (for instance, LINQ, which 
> allows SQL-type queries from languages such as C# and VB).

There's also a tremendous focus on being able to use different parts of the 
systems from different vendors. The whole bit of managing "components" is 
that. So if you don't want to write it and it doesn't come with, chances are 
good you can buy it already built for you.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Invisible wrote:
> Well, certainly you give it a bunch of files and it knows how to compile 
> them. But do you want it to link them all into a single executable? Or 
> maybe two seperate executables?

Yes. That's what the separate "projects" in one "solution" are, in VS.

> Or perhaps you're trying to produce a 
> DLL? Presumably you have to configure this somewhere...

Sure. You set flags on the project properties pages.

> Interesting. I thought it was only object files that contain linker 
> tables...

Depends on the OS and CPU. For example, on CP/M, you're right. The binary 
.COM file is just bytes of machine code that load at 0x100, and the OS jumps 
to 0x100 when it starts. That's responsible for setting up the stack (based 
on an address left in global memory) and parsing the command line (at 0x80).

On even simple UNIXes, you have things in the headers to set up how big the 
stack is, how big the "zero out this memory space" area is, and which 
addresses have to have the start address where you loaded the executable 
added. Any OS taking advantage of memory protection is going to have 
metadata in the executable format.

> Mind you, having just said that... various programs have custom icons 
> and so forth. That's definitely not executable code. Hmm...

Yep, that too.

> [Now the old MS-DOS *.com files really *are* just bare machine code, 
> always loaded at a specific machine address...]

Yes, left over from CP/M.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Invisible wrote:
> I know a header file can theoretically contain anything. But I always 
> thought that the idea was to put only public things in a header file, 
> because if it's not in the header file, other files can't know it exists 
> so it can't be accessed.

No, it's so that there's only one place to change it when you change it. The 
same reason you'd use an "include" in any other language or document or 
whatever.

If it's not declared, you can't easily use it from outside where it's 
defined. One declares it in a header file so one doesn't have to type it out 
all the time or risk getting the declaration wrong.

However, sometimes when I'm debugging stuff that's just breaking deep in the 
bowels of someone else's program, I'll do something like
   { extern int write(int,char*,int); write(1,"#1\n",3); }
just to put in a debugging line to tell me whether it crashed before
or after that point, which prevents me from having to #include the
right pile of header files to declare write() properly.

> Java and Pascal I already have quite extensive experience with. 
> (Although I imagine since the last time I touched Java the APIs have 
> been changed *again*. Oh, and I hear they kludged in generics?) Both of 
> these languages know the difference between a pointer and an array, 
> however.

True. C doesn't have arrays, really. At least, none with actual names.

So you have a lot of experience with Java, and you find *C's* syntax unwieldy?

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> True. C doesn't have arrays, really. At least, none with actual names.

  Actually C *does* have arrays. For example, this is an array:

int table[10];

  Here 'table' is *not* a pointer to a memory location containing space
for 10 ints. 'table' is an array of 10 ints. While it behaves a lot like
a pointer (and is implicitly cast to an int* when necessary), there are
significant differences compared to a pointer. For instance, sizeof(table)
is not the same as sizeof(int*). Also, you can't make 'table' "point" to
somewhere else (because it's not a pointer).

  These are stack-allocated arrays. It is also possible to create
heap-allocated arrays, although not directly. You have to enclose it
inside a struct, like this:

struct ArrayContainer
{
    int table[10];
};

  Here 'table' is also *not* a pointer, it's an array. Now you can allocate
instances of that struct with malloc() and you will effectively have a
heap-allocated array.

  (Granted, C arrays are a bit rigid and non-dynamic, but they are still
arrays by any definition.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> For instance, sizeof(table) is not the same as sizeof(int*). 

Yes, OK.

> Also, you can't make 'table' "point" to
> somewhere else (because it's not a pointer).

I thought "table" was essentially a constant pointer to the first element. I 
forgot about the sizeof() bit.  I.e., that "int table[10]" made table be a 
constant pointer to the first element of an anonymous block ten integers in 
size.

>   Here 'table' is also *not* a pointer, it's an array. Now you can allocate
> instances of that struct with malloc() and you will effectively have a
> heap-allocated array.

int* table = malloc(10*sizeof(int));
creates an anonymous array, then sets "table" as a pointer to the start of 
it. So you can have heap-allocated arrays, you just can't give them names. :-)

Now we're picking nits, tho.  You're right, C does have arrays.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> int* table = malloc(10*sizeof(int));
> creates an anonymous array, then sets "table" as a pointer to the start of 
> it. So you can have heap-allocated arrays, you just can't give them names. :-)

  The other difference is that there's no way of retrieving the size of that
"array".

-- 
                                                          - Warp

Post a reply to this message

On 22-7-2009 10:39, Invisible wrote:
> clipka wrote:
> 
>> Once you've embraced the OO paradigms, you'll no longer wonder whether 
>> it's a
>> step back or sideways - you'll know that it's a step forward.
> 
> This is where I mutter something about functional programming being the 
> future, and everybody agrees with me...

Nah, it was a long tome ago when these were the future (roughly between 
'54 and '58).

Post a reply to this message

On 22-7-2009 1:26, David H. Burns wrote:
> andrel wrote:
> 
>> That you see your smiley does not mean everybody else will.
> 
> Thanks. Did you see it? I did when I read my own post. I don't think it 
> shows up in the text in
> my "sent" file. These matters get complicated.
> :) (smiley ?)
> 

I do. In your post, not when replying :) , neither yours nor mine.
The point I tried to make earlier is that it depends on the mail reader 
of the person *reading*. You don't have an influence on it. You type a 
colon followed by a bracket, that is what you sent and what is supported 
by NNTP. After that somebody is trying to cleverly replace them by 
rotated smileys, which is OK as long as they get it right :/
IIRC they have problems with exotic ones like \o/ perhaps because they 
can conceivably be in a real post or in /ASCII art/.

In short, there is a big chance that what you will see is not what I 
wrote. Perhaps it is what I intended.

Post a reply to this message

On 22-7-2009 11:13, David H. Burns wrote:
> Eero Ahonen wrote:
>> David H. Burns wrote:
>>> (Laugh) I love it! What can be off-topic to off-topic?  What you mean, I
>>> think, is that
>>> this topic is forbidden! Or maybe simply unwanted.
>>>
>>
>> On-topic. Your conversation is clearly about Pov-RAY, so it would
>> naturally fit onto the on-topic groups better than to shit-chatting
>> off-topic group :-).
>>
>> -Aero
> I was told I was off topic in the programming group -- or maybe it's 
> just what
> I say, or how I say it, not the subject that's off-topic. But my critics 
> are right;
> I don't know enough detail to really discuss OOP. 

That did not stop other people here to start a lot of threads. ;) So, 
welcome. Take a seat, relax and try to find a role in this bunch of 
looneys. AFAIK we don't have an on-topic poster here yet, so if that is 
what you like...

> I just voice my objections which apparently aren't shared.

They are to a certain extendthey are. The main problem though, apart 
from this being the wrong group is that you restarted a useless 
discussion for the 42nd time.

>:)

Post a reply to this message

"David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> > Yes, I personally do advocate going for strong OOP-support with POV-Ray 4 SDL. I
> > do so as a POV-Ray user, and I do so as a contributing developer.
> >
> > Yes, I did present a serious proposal for a new, OOP-enabled SDL in the povray 4
> > newsgroup some months ago.
> >
> > Yes, being active in the development of POV-Ray 3.7 I *may* happen to personally
> > get my hands dirty on the code of POV-Ray 4's SDL engine.
>
> So it is so after all
> :(

So it is *what* after all? Me single-handedly going to take over the world or
what??

Mwahahaha - Yeeees - I've always wanted to do that...

Ah, BTW & FYI: Me being a contributing developer to POV-Ray doesn't mean that
I'm member of the official dev team. I do contribute code now and then, but as
for making decisions about which direction to go, the buck does *not* stop
here.

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> > Once you've embraced the OO paradigms, you'll no longer wonder whether it's a
> > step back or sideways - you'll know that it's a step forward.
>
> This is where I mutter something about functional programming being the
> future, and everybody agrees with me...

I have the uncanny feeling that in some years from now I might even agree with
you... >_<

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> The question is... are any POV-Ray "programs" large enough to benefit
> from the extra structuring? I believe the answer is yes, but it's
> somewhat debatable.

I'm quite sure they are - provided we count in a nice set of standard data
containers (variable-size arrays, stacks, queues, lookup lists aka associative
arrays, and maybe some more geometry-oriented like BSP trees, octrees or the
like), and don't want to code them all "hard" into the language or want to stay
flexible for users adding their own (graphs as you might need for physics
simulations, just to give one example of where one could go).

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> [Now the old MS-DOS *.com files really *are* just bare machine code,
> always loaded at a specific machine address...]

Not quite true: They could be loaded at any segment address... OS calls would be
done via invoking INT 21h with particular register values though, if that's what
you mean.

Post a reply to this message

On Wed, 22 Jul 2009 04:05:45 -0500, David H. Burns wrote:

> but it
> apparently allows,
> maybe encourages, writing code so complex as to be almost
> undecipherable.

Google "IOCCC" for some wonderful examples of this. ;-)

Jim

Post a reply to this message

On Tue, 21 Jul 2009 16:37:28 -0500, David H. Burns wrote:

> What can be off-topic to off-topic?

Why, anything that's on-topic, of course. ;-)

Jim

Post a reply to this message

On Wed, 22 Jul 2009 07:00:37 +0300, Eero Ahonen wrote:

> shit-chatting

Wonderful faux pas. ;-)

Jim

Post a reply to this message

andrel wrote:
> On 22-7-2009 1:26, David H. Burns wrote:
>> andrel wrote:
>>
>>> That you see your smiley does not mean everybody else will.
>>
>> Thanks. Did you see it? I did when I read my own post. I don't think 
>> it shows up in the text in
>> my "sent" file. These matters get complicated.
>> :) (smiley ?)
>>
> 
> I do. In your post, not when replying :) , neither yours nor mine.
> The point I tried to make earlier is that it depends on the mail reader 
> of the person *reading*. You don't have an influence on it. You type a 
> colon followed by a bracket, that is what you sent and what is supported 
> by NNTP. After that somebody is trying to cleverly replace them by 
> rotated smileys, which is OK as long as they get it right :/
> IIRC they have problems with exotic ones like \o/ perhaps because they 
> can conceivably be in a real post or in /ASCII art/.
> 
> In short, there is a big chance that what you will see is not what I 
> wrote. Perhaps it is what I intended.

Thanks, again, Andrel. The smileys work, :/ and \o/ came through as the 
Ascii characters.
I'm using Thunderbird.

David

Post a reply to this message

Jim Henderson wrote:
> On Tue, 21 Jul 2009 16:37:28 -0500, David H. Burns wrote:
> 
>> What can be off-topic to off-topic?
> 
> Why, anything that's on-topic, of course. ;-)
> 
> Jim

Obviously, but I hadn't thought of it that way.

David

Post a reply to this message

Invisible wrote:
> clipka wrote:
> 
>> Once you've embraced the OO paradigms, you'll no longer wonder whether 
>> it's a
>> step back or sideways - you'll know that it's a step forward.
> 
> This is where I mutter something about functional programming being the 
> future, and everybody agrees with me...

There is still some debate about that, of course :)

For one, OOP more closely models how many people think of problems, 
while functional programming more closely models how mathematicians 
think of problems.  It is not yet clear which one is better for managing 
large, complex programs in general (especially since there are many 
things a computer does that are still more closely aligned with 
imperative programming.  These things are easier to wrap in OOP, which 
has concepts for both data and actions).

-- 
Chambers

Post a reply to this message

clipka wrote:
> the buck does *not* stop here.

Shouldn't that be "the Buck"? ;)

-- 
Chambers

Post a reply to this message

andrel wrote:

Unfortunately, it seems to be in the nature of things that useless 
discussion drag
on and recur while the useful ones appear only once for a moment. But 
this one hasn't
been entirely useless to me. :)

The main problem though, apart
> from this being the wrong group is that you restarted a useless 
> discussion for the 42nd time.
> 
>> :)

Post a reply to this message

scott wrote:
> A lot of people just find it makes more sense to 
> have one file that neatly shows the interfaces and another to actually 
> contain the implementation code.

In fact, one of my biggest complaints with C# is the lack of class 
prototypes.  I miss having a public interface which fits entirely on one 
(maybe two) screen(s).  Somehow, it seems to make things easier for me.

-- 
Chambers

Post a reply to this message

On Wed, 22 Jul 2009 20:00:21 -0500, David H. Burns wrote:

> Jim Henderson wrote:
>> On Tue, 21 Jul 2009 16:37:28 -0500, David H. Burns wrote:
>> 
>>> What can be off-topic to off-topic?
>> 
>> Why, anything that's on-topic, of course. ;-)
>> 
>> Jim
> 
> Obviously, but I hadn't thought of it that way.

That's perfectly OK - I was just kidding around, had hoped the smiley 
would tip that off. ;-)

Jim

Post a reply to this message

> The way this works on the Amiga is that you can't just *call* an OS 
> function. First you have to look up its base address in a table. 
> Basically, memory address 0x00000004 contains a pointer to a table. Every 
> OS function has a unique ID which is an offset into this table, which 
> enables you to lookup the function's base pointer. And then you can jump 
> to it. All of which takes about two-dozen assembly instructions...

On the Acorn there was an instruction called SWI (software interrupt) for 
calling OS and other module functions.  In the assembler it took a number or 
a string as a parameter (the assembler converted the string to the correct 
number), which defined the specific function you wanted to call.  I assume 
when the CPU got to the SWI instruction it jumped to a few lines of OS code 
which figured out where to actually jump to execute the instruction.

When you loaded "modules" to the OS (they were like services under windows) 
each module could register some functions with the OS.  Then you could call 
them with the SWI instruction.  It was pretty easy to use.

You could easily hack the system though by redirecting the interrupt handler 
to your code, calling the real OS handler, then passing control back to the 
calling program.  Of course in your code you could then check for certain 
functions (like reading the contents of a folder) and modify the results :-)

Post a reply to this message

Chambers <Ben### [at] gmailcom_no_underscores> wrote:
> > the buck does *not* stop here.
>
> Shouldn't that be "the Buck"? ;)

??

Post a reply to this message

>> > the buck does *not* stop here.
>>
>> Shouldn't that be "the Buck"? ;)
>
> ??

I know in German you use a capital letter for every noun, but in English 
it's usually just for names.

Post a reply to this message

>> I see. So you still have to manually define what needs to be linked 
>> somehow?
> 
> Lets just say I'm working with source files right now where the line 
> used to compile the file takes up more than one screen of text in the 
> editor.

Yes. For some reason, this seems to be mandatory in all Linux 
development. I'm not sure why...

>> - When main.c is compiled, it produces main.o, which contains several 
>> references to a foo() that should exist somewhere, but we don't know 
>> where yet.
> 
> No. Only if main() actually calls foo().

One assumes that if you don't need foo(), you wouldn't bother including 
the header file. But sure, if the header declares a few dozen functions; 
you might not call every single one of them.

>> - The linker takes main.o and foo.o, and replaces every jump to foo() 
>> with a jump to an actual machine address. The resulting program is 
>> actually runnable.
> 
> Sort of. That's called "linking." Then there's "loading", which is when 
> you put it into memory and *again* adjust a bunch of addresses.

Right. So what you're saying is that there's actually a second linking 
stage each time final executable is run?

>> What I can't figure out is what happens if foo() is actually a 
>> function somewhere in the OS kernel. 
> 
> It isn't. The read() function in C, for example, is in the C runtime 
> library (glibc or uclibc on Linux).  The linker always searches that 
> library as part of the linking process (unless you're doing something 
> funky like compiling the kernel). The read() function in that library is 
> written in assembler (because C is really not very useful for this sort 
> of work) and that assembler code copies items off the stack into machine 
> registers and then invokes an assembler instruction that causes the CPU 
> to set certain flags in the CPU registers that control permissions, 
> change memory maps, and eventually winds up branching to a particular 
> address in memory which the kernel has previously set to be a branch 
> instruction to the code to handle read().  So read() is normal, except 
> it's in a library the compiler always searches and contains assembly 
> language.

In summary... you can't call the OS from C. You can only write C wrapper 
functions around the assembly code that calls the OS. (And the wrapper 
then of course looks like a normal C function...)

>> Presumably in each version of the kernel, the base address of this 
>> function is going to be different... so how the hell does the linker 
>> know what it is?
> 
> It doesn't. It executes a machine-code instruction that's essentially a 
> software interrupt. (That's why you see things like DOS functions being 
> described as "Int 21h" functions.)
> 
> It's an instruction that invokes an indirect branch.

I see. So that's the mechanism on the IA32 platform, is it? (I thought 
only the BIOS uses this method...)

>> The way this works on the Amiga is that you can't just *call* an OS 
>> function.
> 
> There's no memory protection or kernel mode on AmigaOS. It can't be 
> multiuser.

Interestingly enough, the Motorola 68000 does in fact have two modes of 
operation: "user mode" and "supervisor mode". I have no idea what the 
distinction is.

Additionally, the factory-standard Amigas had the "EC" version of the 
Motorola 68000 CPUs which lack an MMU. You can, however, replace this 
with a version of the CPU that possesses an MMU. Indeed, several 
companies offered the add-on boards, together with the necessary 
software to extend AmigaOS to support virtual memory. This suggests that 
the MMU-enabled variant of the CPU could support memory protection if 
you wanted.

And finally, it's perfectly possible to make a multiuser OS without 
memory protection. It just won't have any memory protection. (Meaning 
one rogue program can crash the whole system.) Arguably not very useful, 
but completely doable.

Post a reply to this message

clipka wrote:
> "David H. Burns" <dhb### [at] cherokeetelnet> wrote:

>>> Yes, being active in the development of POV-Ray 3.7 I *may* happen to personally
>>> get my hands dirty on the code of POV-Ray 4's SDL engine.
>> So it is so after all
>> :(

> 
> So it is *what* after all? Me single-handedly going to take over the world or
> what??

That's what it sounds like, the Pov-Ray world anyway. You've greatly 
increased my paranoia.
Any day now I expect the carpenter's union to redesign and rebuild my 
house not for
convenience or comfort but to teach me the current accepted practice in 
carpentry.
> 
> Mwahahaha - Yeeees - I've always wanted to do that...
> 
> Ah, BTW & FYI: Me being a contributing developer to POV-Ray doesn't mean that
> I'm member of the official dev team. I do contribute code now and then, but as
> for making decisions about which direction to go, the buck does *not* stop
> here.

Despite my concerns, I do appreciate all the work that the official and 
unofficial
of Pov-Ray have done over the year --excellent work for my part.

David :)

Post a reply to this message

Chambers wrote:

> For one, OOP more closely models how many people think of problems, 
> while functional programming more closely models how mathematicians 
> think of problems.  

??!! Though the second clause of this sentence seems true  to me, nothing
  that I have read or heard in a long time seems so obviously false! It 
makes
me wonder if I'm communicating with an entity of a different a species 
or even
a different genus! (Is there an exclamation or ??!! icon?)

David

Post a reply to this message

>> This is where I mutter something about functional programming being 
>> the future, and everybody agrees with me...
> 
> There is still some debate about that, of course :)

That was actually sarcasm. ;-)

> For one, OOP more closely models how many people think of problems, 
> while functional programming more closely models how mathematicians 
> think of problems.

Depends who you think you're aiming your programming language at.

> It is not yet clear which one is better for managing 
> large, complex programs in general.

People who use Haskell casually build interpretters, compilers, logic 
simulation systems, and other things usually thought of as "hard" in 
normal programming languages. Whether this is to do with Haskell or the 
sort of people who use Haskell remains to be seen of course... ;-)

> (especially since there are many 
> things a computer does that are still more closely aligned with 
> imperative programming.  These things are easier to wrap in OOP, which 
> has concepts for both data and actions).

One might ask when computers will start to be designed to operate in a 
more functional way...

Post a reply to this message

> That's what it sounds like, the Pov-Ray world anyway. You've greatly 
> increased my paranoia.
> Any day now I expect the carpenter's union to redesign and rebuild my 
> house not for
> convenience or comfort but to teach me the current accepted practice in 
> carpentry.

Even if POV4 does change to an OOP model that you don't like, a) that is not 
going to be released for decades, and b) you are free to still use the 
latest stable 3.x release.  I wouldn't worry about it.

Post a reply to this message

David H. Burns <dhb### [at] cherokeetelnet> wrote:
> Chambers wrote:

> > For one, OOP more closely models how many people think of problems, 
> > while functional programming more closely models how mathematicians 
> > think of problems.  

> ??!! Though the second clause of this sentence seems true  to me, nothing
>   that I have read or heard in a long time seems so obviously false!

  And exactly what is it that makes it false?

  Object-oriented programming closely matches the thought process of people.
OOP can be deconstructed into to most basic elements: Concepts and algorithms.

  People think about things conceptually. For example, you can have one pen,
one car, one dog, and so on.

  Moreover, people use hierarchies of concepts. Some concepts are more
abstract while other concepts are more concrete. For example, the concept
of "animal" is more abstract than the concept of "dog" or "cat", which are
more concrete. Moreover, there's a hierarchical relationship between these
concepts: A dog is an animal, and a cat is an animal (but a dog is not a cat).

  Concepts can have properties to them. For example a dog has color, weight,
gender, race, etc. These properties can be different for different dogs.
Likewise the concept of "book" can have many properties, including its title,
author, date of publication, cover picture, table of contents, and so on
(all of which in themselves are also concepts).

  The other basic element of OOP is algorithms. These can be thought in the
same way as food recipes. Food recipes use some concepts (ingredients, cooking
utensils, etc) and a list of instructions on how to prepare the meal.

  This is the way people think naturally, and object-oriented programming
simulates this kind of design: It defines concepts (which may be hierarchical)
and algorithms on what to do with those concepts.

  Now please explain to me exactly what here is "so obviously false"?

-- 
                                                          - Warp

Post a reply to this message

Chambers <Ben### [at] gmailcom_no_underscores> wrote:
> It is not yet clear which one is better for managing 
> large, complex programs in general

  I have hard time believing that large programs written in a functional
language like Haskell don't use one of the basic features of OOP: Modularity.

  Modularity (and the abstraction related to it) is one of the most essential
properties of a large project, if you want it to be manageable.

  Functional programming sounds to me more like just a way of expressing
what you want to do (ie. algorithms), not how you should distribute your
code among modules. Modularity transcends things like imperative or
functional programming paradigms. You could say it's a metaparadigm used
in many if not most large projects, regardless of the language used.

-- 
                                                          - Warp

Post a reply to this message

On 07/23/09 08:07, David H. Burns wrote:
> ??!! Though the second clause of this sentence seems true to me, nothing
> that I have read or heard in a long time seems so obviously false! It makes

	Perhaps it's because you tried learning OOP from C++/Java?

	I'm sure you think in OOP all the time with POV-Ray. You create a 
sphere. It's an object with certain properties (texture, location, etc). 
Now let's say you want to rotate the sphere, does it hurt so much to do 
something like:

mysphere.rotate(45)

	Let's say you want to have lots of balls in your scene. You want some 
to be red, some blue, and some green. And some of _those_ you want to be 
translucent.

	So you create your "basic" ball as a sphere with little texture. You 
subclass it to create two kinds of balls: "solid" and "translucent". In 
terms of actual code, you just create a new object that is the subclass 
of your "basic", and you merely add to it the texture that makes it 
translucent.

	Then you can subclass each to get the red, blue and green balls.

-- 
No, Taco Bell is NOT the Mexican Phone Company!

Post a reply to this message

On 07/23/09 07:55, David H. Burns wrote:
> That's what it sounds like, the Pov-Ray world anyway. You've greatly
> increased my paranoia.
> Any day now I expect the carpenter's union to redesign and rebuild my
> house not for
> convenience or comfort but to teach me the current accepted practice in
> carpentry.

	Try lying in front of the house when the bulldozers come. And if you 
see someone coming along hugging a towel, become friends with him. 
Otherwise your life will be in danger.

	And not because of the bulldozers.

-- 
No, Taco Bell is NOT the Mexican Phone Company!

Post a reply to this message

Warp wrote:

>   This is the way people think naturally, and object-oriented programming
> simulates this kind of design: It defines concepts (which may be hierarchical)
> and algorithms on what to do with those concepts.
> 
>   Now please explain to me exactly what here is "so obviously false"?
> 

*I* don't think, naturally or otherwise, like any OOP programming I have 
seen!! You may be trying to
read your on programming philosophy onto the world, or we may be of 
different genera. :)

David

Post a reply to this message

Neeum Zawan wrote:

>     I'm sure you think in OOP all the time with POV-Ray. You create a 
> sphere. It's an object with certain properties (texture, location, etc). 
> Now let's say you want to rotate the sphere, does it hurt so much to do 
> something like:
> 
> mysphere.rotate(45)
> 

No! I think in terms of objects, not of OOP. The concept of an "object" 
as used
in Pov-Ray in a valuable tool for thinking and programming -and used 
well there.
What I have seen of OOP programming is something else. :)

David

Post a reply to this message

David H. Burns <dhb### [at] cherokeetelnet> wrote:
> *I* don't think, naturally or otherwise, like any OOP programming I have 
> seen!! You may be trying to
> read your on programming philosophy onto the world, or we may be of 
> different genera. :)

  You clearly don't understand what "object-oriented programming" means.
Then you come here to tell us that you don't want it, whatever it might be.

-- 
                                                          - Warp

Post a reply to this message

David H. Burns <dhb### [at] cherokeetelnet> wrote:
> What I have seen of OOP

  Clearly you haven't. You don't even understand what "object-oriented
programming" means.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   Object-oriented programming closely matches the thought process of people.

I think it's more like how people categorize real-world stuff. Since a lot 
of programming is essentially simulating the real world, OO makes sense.

There's a bunch of things that go on in the real world that don't make sense 
to do with OO: expert systems, board game AIs, financial analysis, 
accounting, etc.

There's a bunch of things that make sense with OO: Windowing system, 
interactions between businesses and customers, etc.

To say "people think in OO" is to miss that in many situations people don't 
think in OO.

>   This is the way people think naturally,

I would say this is *A* way people think naturally.  Something as simple as 
a decision table or decision tree is another way people think naturally.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message