Kenneth <kdw### [at] gmailcom> wrote:
> The root of my *long-term* basic misconception (of not realizing that source
> code is a simple text file, AND WRITTEN in a text editor) is this: I thought it
> needed to be written in some kind of special 'source-code' program or
> environment--and linked in some way with C/C++ code libraries or some such, to
> make even the writing process work. Admittedly a funny/goofy concept, now that I
> understand what the truth is. (I'm leaving out the compiling or interpreting
> process, that's a different thing.)

There are, in fact, many types of programming languages in this respect.

The two oldest, and most common ones, are compiled languages and interpreted
languages.

A compiled language is (usually) written in ASCII text with a well-defined
syntax, and then a compiler program is used to (basically) convert those
instructions into equivalent machine code, which are bytes that the CPU
directly runs. (The nitty gritty details are actually much more complicated
than this, especially because of how operating systems work, but those are
not very relevant for the purpose of understanding what a compiled language
is.)

An interpreted language is not compiled into anything. Instead, the
"compiler" (which in this case would be called an interpreter) instead
just executes the commands as it parses the source file. (Again, the nitty
gritty details are much more complicated than this, but irrelevant at this
conceptual level.) So-called scripting languages are almost always
interpreted.

Then there's a kind of third category, where a language is actually
compiled, but not to native machine code, but to a more hardware-independent
"byte code", which is then "interpreted" by a runtime environment. (This
is kind of a mix of both techniques. The source code is compiled into
"machine code", but not the machine code of the CPU, but a more abstract
one. This custom "machine code" is then interpreted by a program which,
technically speaking, is an "interpreter". It kind of acts like a CPU,
but rather than being a physical CPU it's a program that "emulates" one.)

Of course it can get even more complicated than this. The most advanced
runtime environments will compile the "custom machine code" into actual
machine code of the CPU on the fly, for speed.

(Why not compile from the source code directly to the target CPU, you
might ask? The advantage of using "custom" machine code is that the exact
same program can be run on any computer that has the proper runtime
environment. Interpreting the custom machine code is much faster than
interpreting the original source code directly.)

-- 
                                                          - Warp

Post a reply to this message

BTW, my 'computing' and basic code-writing experience goes way back--first in
college, in a single introductory course, writing 'batch process' programs for
an IBM mainframe using punch cards(!) and Fortran IV; then with a Commodore VIC
20, then a Commodore 64, probably using BASIC.

Yet in ALL that time, I don't think I ever heard or knew of the concept of
'source code.' Or even heard the phrase! (If I did, it was just one more
*arcane* computing term that made no sense at the time, as that 'introductory'
college course was WAY over the heads of most of the students, almost like a
philosophy course taught in a foreign language. Yet the programming itself was
easy.)

Actually, it has only been while using POV-Ray (and visiting the newsgroups)
that I've been made aware of what source code even *is*.

Post a reply to this message

On Wed, 06 Feb 2013 14:30:25 -0500, Kenneth wrote:

> What I would basically like to do is see the code the way the original
> developer saw it, while writing it (in whatever programming language
> that happened to be.)
> I might even learn a few things!

You have to be given the source code to see it this way - and that would 
be in text format.

There /are/ decompilers available, but they won't tend to include 
comments or even necessarily variable names the way the developer wrote 
the code.

If you have code from a complex program, I have found Source Navigator NG 
to be useful in dissecting the code to read and understand it - it's an 
open source tool (don't know if there's a Windows or Mac version, but it 
probably can be built for those platforms as it is open source itself).

Jim

Post a reply to this message

>
> Kind of like using Moray or Blender to generate POV-Ray SDL.
>

Of course I must disagree, have you actually tried Blender's POV-Ray exporter,
it has options to choose whether to insert line breaks or not for meshes
readability, it inserts comment sections to clarify which does what, you can
specify it where to put your files, and pass  command line arguments along to
it.

And if you find anything not clean, just tell me what, I'll correct it,  or help
you do it  yourself if you want (the exporter's Python code is GPL licenced so
it's free for any use)

If you think it's "not clean" because you just want to see primitives instead of
mesh2, it's not hard to implement, just that nobody requested it yet, as opposed
to other features like hair export that I added right away.

To get back on topic, I don't think of visual 3D editors as generating dirty POV
code, I see them more like tools to generate a draft to be improved by little
tweaking(or left as is when you are satisfied with the result or in a hurry).

Post a reply to this message

"Mr" <nomail@nomail> wrote:
> >
> > Kind of like using Moray or Blender to generate POV-Ray SDL.
> >
>
> Of course I must disagree, have you actually tried Blender's POV-Ray exporter,
> it has options to choose whether to insert line breaks or not for meshes
> readability, it inserts comment sections to clarify which does what, you can
> specify it where to put your files, and pass  command line arguments along to
> it.
>
> And if you find anything not clean, just tell me what, I'll correct it,  or help
> you do it  yourself if you want (the exporter's Python code is GPL licenced so
> it's free for any use)
>
> If you think it's "not clean" because you just want to see primitives instead of
> mesh2, it's not hard to implement, just that nobody requested it yet, as opposed
> to other features like hair export that I added right away.
>
> To get back on topic, I don't think of visual 3D editors as generating dirty POV
> code, I see them more like tools to generate a draft to be improved by little
> tweaking(or left as is when you are satisfied with the result or in a hurry).

Actually I forgot about that, but there is even a feature to replace stuff with
custom POV code, making stand in primitive objects unneccessary IMHO, yet again,
I'm open to suggestions .

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:

>
> Then there's a kind of third category, where a language is actually
> compiled, but not to native machine code, but to a more hardware-independent
> "byte code", which is then "interpreted" by a runtime environment...[clip]
>
> Of course it can get even more complicated than this. The most advanced
> runtime environments will compile the "custom machine code" into actual
> machine code of the CPU on the fly, for speed.

This is what I understand Java to be (at least, the Windows Java Runtime
Environment.)

BTW, your entire post is a very informative summary of these topics; I haven't
seen it described so clearly and succinctly before. Much appreciated!

Post a reply to this message

"Mr" <nomail@nomail> wrote:
> >
> > Kind of like using Moray or Blender to generate POV-Ray SDL.
> >
>
> Of course I must disagree, have you actually tried Blender's POV-Ray exporter,
> it has options to choose whether to insert line breaks or not for meshes
> readability, it inserts comment sections to clarify which does what, you can
> specify it where to put your files, and pass  command line arguments along to
> it.

;-)

I have to admit that I haven't yet tried Blender--but that's definitely on my
future to-do list. Seems to have LOTS of features--and the interface reminds me
somewhat of Lightwave. (That's a compliment, BTW... :-) ... as I really liked
playing around with an older version, one that came installed on a used PC I
bought; alas, it had a major bug there, so I stopped using it.)

Post a reply to this message

On 2/9/2013 1:21 PM, Kenneth wrote:
> "Mr" <nomail@nomail> wrote:
>>>
>>> Kind of like using Moray or Blender to generate POV-Ray SDL.
>>>
>>
>> Of course I must disagree, have you actually tried Blender's POV-Ray exporter,
>> it has options to choose whether to insert line breaks or not for meshes
>> readability, it inserts comment sections to clarify which does what, you can
>> specify it where to put your files, and pass  command line arguments along to
>> it.
>
> ;-)
>
> I have to admit that I haven't yet tried Blender--but that's definitely on my
> future to-do list. Seems to have LOTS of features--and the interface reminds me
> somewhat of Lightwave. (That's a compliment, BTW... :-) ... as I really liked
> playing around with an older version, one that came installed on a used PC I
> bought; alas, it had a major bug there, so I stopped using it.)
>
Its improved.. The older version, at least for me, being used to drop 
down menus, and not needing to use a mess of keypresses I had to 
remember, etc., was like the "Wordstar" of 3D applications.

Post a reply to this message

>
>>
>> Kind of like using Moray or Blender to generate POV-Ray SDL.
>>
>
> Of course I must disagree, have you actually tried Blender's POV-Ray exporter,

I admit it's been a while.

> it has options to choose whether to insert line breaks or not for meshes
> readability, it inserts comment sections to clarify which does what, you can
> specify it where to put your files, and pass  command line arguments along to
> it.

I didn't mean to single out Blender, nor Moray.  It was just a general 
statement that exporting from a WYSIWIG format into a text-based format 
will usually lead to either (a) missing stuff, (b) extraneous stuff, or 
(c) stuff that could have been done more clearly in the native language.

(The absolute worst example I can think of would be MS-Office's "save as 
HTML")

> To get back on topic, I don't think of visual 3D editors as generating dirty POV
> code, I see them more like tools to generate a draft to be improved by little
> tweaking(or left as is when you are satisfied with the result or in a hurry).

This is exactly what I'm saying too.  "jumbled mess" may have been a 
slight exageration.

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

On 6-2-2013 20:30, Kenneth wrote:
> Not how to 'understand' source code ;-)
>
> Just wondering what kind of little Windows app I could download to actually
> *see* (take a look at) the source code for a program (well, one that has
> publicly-available source code, anyway--like POV-Ray.) I've never thought of
> doing so before now, and don't know what's involved. Not to EDIT the stuff, or
> compile/recompile it; that's way beyond me.
>
>  From what I've read, some 'text' editors can do this. Or would it require a 'hex
> editor'?  Or perhaps something like Notepad++, which apparently can open and
> display programs written in C, C++ etc?
>
> What I would basically like to do is see the code the way the original developer
> saw it, while writing it (in whatever programming language that happened to be.)
> I might even learn a few things!
>

An interesting read might also be 
http://www.amazon.com/Computers-Typesetting-Volume-TeX-Program/dp/0201134373/
That is the complete Source code of TeX, fully documented and typeset 
in... TeX and published as a book.

But perhaps first look it up in your local university library.

    Andrel

-- 
Women are the canaries of science. When they are underrepresented
it is a strong indication that non-scientific factors play a role
and the concentration of incorruptible scientists is also too low

Post a reply to this message