Am 07.02.2013 00:19, schrieb Kenneth:

> Hey, there are LOTS of separate source code files for POV-Ray! Where to begin...
>   I naively thought that *whatever makes POV run* would be just one big file. Am
> I correct in thinking that the program's source code is actually split up into
> lots of little (therefore manageable) chunks?

Absolutely.

> One other thing: Does POV-Ray (or any of the other text reader apps I mentioned)
> need ...uh... built-in 'code libraries' or something, to show *correct*
> C/C++/whatever syntax? In other words, does a particular app 'substitute' its
> own syntax for the correct one, if it doesn't have certain code libraries? (I
> hope I'm asking this in a meaningful way.) Am I *seeing* the code correctly?

Yes, you are. /All/ text editors show the code correctly. Some editors 
can automatically identify certain syntactical elements to show them in 
different colors (syntax highlighting), or provide you with ways of 
hiding code sections (code folding), but that's just sugar, and as a 
matter of fact it is /not/ part of the real .cpp and .h source code 
files. They just contain the raw uncolored text.

> Off-off-topic: While I was doing my research into this stuff, I read about 'hex
> editors.' Apparently they can open an executable (.exe) file for editing?? (Not
> in a higher-level language, of course.)

Uh... yes, but such procedure is /not/ recommended in the least. With a 
hex editor, you can visualize (and manipulate) the /true/ content of 
/any/ file, byte by byte.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

>
> > Off-off-topic: While I was doing my research into this stuff, I read about
> > 'hex editors.' Apparently they can open an executable (.exe) file for
> > editing?? (Not in a higher-level language, of course.)
>
> Uh... yes, but such procedure is /not/ recommended in the least. With a
> hex editor, you can visualize (and manipulate) the /true/ content of
> /any/ file, byte by byte.

Sounds dangerous (in MANY ways)...especially in my neophyte hands! ;-)

Post a reply to this message

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

>
> I'm not sure you understand what program source code is. It's just ascii
> text, like this very text I'm writing and posting here.

Yeah, *that* very thing was an unknown/mysterious concept to me, before now. I
had no idea it would turn out to be so. Kind of magical, actually. (I always
thought POV-Ray's SDL--and its built-in text editor--was a 'special case'!)

Duh!!

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> ...and as a
> matter of fact it is /not/ part of the real .cpp and .h source code
> files. They just contain the raw uncolored text.
>

Ah, so that's why the code looks somewhat 'different' in, say, POV-Ray vs.
Windows' basic Notepad.

Post a reply to this message

On 2/6/2013 1:09 PM, Le_Forgeron wrote:
> Le 06/02/2013 20:30, Kenneth nous fit lire :
>> 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?
>>
>
> Any text editor (not wordprocessor) should do.
> You might enjoy an easy to use search function (just to spot all the
> occurrence of a variable, or finding a function)
> An optional line numbering might help too.
>
>> 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!
>
> <start holy war>
> * PFE (programmer's File Editor)
> * use eclipse with C/C++ or Java setting
> * use Microsoft Visual Studio (or whatever its name), if available as
> free edition on your OS (IIRC, MSVC 2012 need something like Vista or 7
> and won't install on XP)
>
Scite/WScite

Its got something for nearly every bloody language possible, and now 
supports its own scripting using Lua, for which someone else made.. 
scintalua, or something like that. Basically, a "prebuilt" dll, which 
extends Scite, so that you can slap together a simple lexer, to color 
code, and such (documentation could use some work, and a few things I 
never did work out while trying to create something for use with LSL 
(Linden Scripting Language), so, if there is something it doesn't 
support, its fairly easy to patch so it can.

Post a reply to this message

On 2/6/2013 4:19 PM, Kenneth wrote:
> Off-off-topic: While I was doing my research into this stuff, I read about 'hex
> editors.' Apparently they can open an executable (.exe) file for editing?? (Not
> in a higher-level language, of course.)
>
Well, yeah, and no. Its not going to be "readable" in any real sense. 
Way back, like the 80s, you could find some "decompilers". The concept 
meant one of two things. Some fairly good ones could "guess" at whether 
your program, based on clearly known factors, like how branching was 
done in certain compilers, and internal naming conventions (if you 
looked at an EXE in an hex editor, or even something else that could 
read it in well enough, you would find a mess of words, names, etc. in 
many of them, that you where using say Borland C, and then "rebuild" the 
source code, minus the original names for variables, and such. In many 
cases, a final compile, with all the "debug" data removed is/was never 
done, so "some" labels, variable, etc. might still be in those things, 
even in modern applications.

This is especially true with certain dlls, since they expose "entry 
points", which, in principle, you can look up by asking the dll, and 
some applications include entry points as well. Explorer, for example, 
functions both as a "stand alone", as part of the OS, and as something 
you can "attach" to your own program, ask for entry points, and then use 
those to talk to its own code, when loaded.

Less sophisticated ones, and even DOS' own little machine language 
utility could "sort of" do this, for very small programs, would just 
generate a machine code version, with what ever data you could get out 
of it.

I am sure there is, out there some place, applications that could pick 
apart an EXE and come up with something "close" to the original, 
possibly even in the same language it came from. But.. there are obvious 
legal issues with such tools, so finding one, at all, never mind a 
really good one, might be really hard today.

Post a reply to this message

> Hey, this is really fantastic! So I downloaded POV-Ray's 3.62 source code, and
> it shows up in Windows Notepad, EditPadLite--even in POV-Ray itself! (I think
> the latter is my favorite 'reading platform' so far.)
>
> Thanks to everyone who posted about this. I didn't know it was so easy.
>
> Hey, there are LOTS of separate source code files for POV-Ray! Where to begin...
>   I naively thought that *whatever makes POV run* would be just one big file. Am
> I correct in thinking that the program's source code is actually split up into
> lots of little (therefore manageable) chunks?

Watch out - soon you will want to just change something and then 
recompile to get your own custom povray.exe :-)

> One other thing: Does POV-Ray (or any of the other text reader apps I mentioned)
> need ...uh... built-in 'code libraries' or something, to show *correct*
> C/C++/whatever syntax?

They need a list of words that are specific to that language, and some 
"rules" about the syntax of the language. If you open the file in 
notepad you'll see it's just plain text, something like povray or 
notepad++ interprets this plain text and makes it more human readable.

Some of the more advanced editors (eg the one in MS VisualStudio) help 
you even further when editing by figuring out what valid text you could 
possibly type next and give you that list to choose from, underlining 
errors in real-time and giving pop-ups with required parameters for 
functions etc.

> Off-off-topic: While I was doing my research into this stuff, I read about 'hex
> editors.' Apparently they can open an executable (.exe) file for editing?? (Not
> in a higher-level language, of course.)

Of course (*any* file is just an array of bytes), but what do those 
bytes mean? In the case of a .exe file there will likely be data 
portions in a non-human-readable format and code which will be in the 
form of byte-code for the CPU - it's not recommended to edit or even 
view this byte-by-byte.

The best you can really do is to use a "disassembler" that will take the 
code in the .exe and convert it to human-readable instructions for the 
CPU (eg things like "load variable X from address Y", or "add X to Y"). 
This is still very low level (no useful variable names or function 
names) and will take an order of magnitude more time to figure out 
what's going on compared to the source code.

Post a reply to this message

It has been a long time since I've made so fundamental(!) and exciting a
discovery as this. Those who already know what source code is may not truly
understand my elation. I feel like I've suddenly climbed to the top of a very
tall mountain--and can finally see the wondrous and vast mountain range
stretching before me, just waiting to be discovered.

The POV-Ray newsgroups are great!

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.)

In going back over the info in some of the web resources that I looked at prior
to my post, I see that 'source code as text' *is* mentioned, fairly often. I
probably did understand that part of things, if only in a vague way. But
apparently it wasn't enough to *trigger* an ultimate understanding. Funny thing
is, I never came across anything that said, "...and you can read and write it in
a simple text editor. It's just text, dummy!"  ;-)

Oh, and I'm now making other conceptual connections: I recently bought an
Arduino Uno board. Haven't done much with it yet--but coding for it IS just a
simple matter of writing text, in any old text editor (in a subset of C, which
is then compiled.) But *again* I thought the Arduino code-writing environment
was a 'special case'--purposely made easy for end users, to 'hide the ugly
details.' NOW, I realize that what I'm doing is writing...source code! I don't
think this is actually mentioned in the (one) Arduino book I have.

Post a reply to this message

Am 07.02.2013 20:35, schrieb Kenneth:

> 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.)

While being funny & goofy, the concept isn't /too/ far-fetched. For 
instance, Visual Basic for Applications has some traits that go in that 
direction.

Real programmers have always scorned the idea though.

Post a reply to this message

> It has been a long time since I've made so fundamental(!) and exciting a
> discovery as this. Those who already know what source code is may not truly
> understand my elation. I feel like I've suddenly climbed to the top of a very
> tall mountain--and can finally see the wondrous and vast mountain range
> stretching before me, just waiting to be discovered.
>
> The POV-Ray newsgroups are great!
>
> 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* tools that work this way.  They are often called RAD (Rapid 
Application Design) tools and will allow you to drag and drop Windows, 
buttons and list boxes, and auto-generate code in the background.  By 
right-clicking on each of those, you can modify some or all of the 
underlying code.  This is usually used to create front-end apps for 
entreprise databases, but the underlying code will tend to be a jumbled 
mess.

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



-- 
/*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