Christopher James Huff scribis news:chrishuff-
9F0### [at] netplexaussieorg:

> In article <3c4cb4df$1@news.povray.org>,
>  "autowitch" <aut### [at] autoSPAMwitchorg> wrote:
> 
>> It compiles fine in Cygwin - now to figure out how to use it :-)
> 
> Make sure the CSDL executable is in the same directory as the 
> Demo files and library folder. 

Can it be stored in a directory in the system path and run that way?
Or does it store all output files in the same dir that the binary is
stored in? Do you plan to use an *.ini file that lets it know where 
to find needed files?

> 
> BTW, I just got OpenGL display (using GLUT) working...and I almost have 
> function return values working.
> 

Please let us know when you have another release.


-- 
Gis poste, Arto.

Post a reply to this message

In article <Xns### [at] 204213191226>,
 Arthur Flint <mra### [at] chesapeakenet> wrote:

> Can it be stored in a directory in the system path and run that way?
> Or does it store all output files in the same dir that the binary is
> stored in? Do you plan to use an *.ini file that lets it know where 
> to find needed files?

I've already added a command-line option to specify an alternate place 
to look, that library path was just a quick fix to give me some way of 
keeping my files organized. An *.ini file method is certainly a 
possibility, as I add more options.


> Please let us know when you have another release.

I plan to do Alpha 2 this Saturday, it will be a lot more useable and 
useful, with things like a graph object and rewritten documentation.

-- 
 -- 
Christopher James Huff <chr### [at] maccom>

Post a reply to this message

Christopher James Huff wrote:
> 
> Here it is, first alpha release. If anyone wants to do a Windows/Linux
> port, just say so.
> 

Ok, i have finally found some time to have a look, as autowitch mentioned
it compiles with cygwin, even with -mno-cygwin/MinGW (in case you want to
use a non open source license) For future versions a makefile would of
course be useful.

The samples all worked, starting Povray of course not, but that's just a
small change in the 'povray.csdl' file.  The indention of the Povray
output could be improved, but you probably already noticed that.

The syntax is pretty self explanatory although learning everything will
probably take some time.  But it seems that writing malicious programs is
quite easy so you should consider some security mechanism like Povray's
IO-restrictions.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

In article <3C4EDD1C.848E9D11@gmx.de>,
 Christoph Hormann <chr### [at] gmxde> wrote:

> Ok, i have finally found some time to have a look, as autowitch mentioned
> it compiles with cygwin, even with -mno-cygwin/MinGW (in case you want to
> use a non open source license) For future versions a makefile would of
> course be useful.

Especially since it now uses GLUT...I'll get to work on one, but I have 
very little experience in such things, beyond modifying them to compile.


> The samples all worked, starting Povray of course not, but that's just a
> small change in the 'povray.csdl' file. 

Hmm? What changes were necessary? Is POV-Ray not named "povray" on your 
system?
I'll eventually have the engine name be a variable, it was mainly 
hard-coded because there are no string manipulation functions yet. The 
same goes for the source file name.


> The indention of the Povray output could be improved, but you 
> probably already noticed that.

In the current POV library, I've removed all indentation...it won't be 
too hard to implement though, I just haven't done it because I haven't 
decided on the best way to store the data.


> The syntax is pretty self explanatory although learning everything will
> probably take some time.  But it seems that writing malicious programs is
> quite easy so you should consider some security mechanism like Povray's
> IO-restrictions.

More dangerous is the system() function...I'll eventually add security 
features to limit file I/O and turn that function off, though they will 
probably be platform-specific extensions to the core code. I'm focusing 
on getting the thing fully operational first...

-- 
 -- 
Christopher James Huff <chr### [at] maccom>

Post a reply to this message

Christopher James Huff wrote:
> 
> Hmm? What changes were necessary? Is POV-Ray not named "povray" on your
> system?
> I'll eventually have the engine name be a variable, it was mainly
> hard-coded because there are no string manipulation functions yet. The
> same goes for the source file name.

It's 'pvengine.exe' but it's usually not in search path and the windows
version is not very suited for automatic starting anyway so most people
will either not use the render function or have a command line version.

> 
> More dangerous is the system() function...I'll eventually add security
> features to limit file I/O and turn that function off, though they will
> probably be platform-specific extensions to the core code. I'm focusing
> on getting the thing fully operational first...

I mostly meant 'system()', i think it would be good if you could have a
confirmation before executing a program.

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

In article <3C4EED6E.32F4EB5E@gmx.de>,
 Christoph Hormann <chr### [at] gmxde> wrote:

> I mostly meant 'system()', i think it would be good if you could have a
> confirmation before executing a program.

That would be a possibility...it would have three settings: always 
execute, ask, and never execute. The code would be conditionally 
compiled, so it could be specialized for specific platforms.

-- 
 -- 
Christopher James Huff <chr### [at] maccom>

Post a reply to this message

In article <chr### [at] netplexaussieorg> , 
Christopher James Huff <chr### [at] maccom>  wrote:

> Here it is, first alpha release.

I didn't run or compile it, I just looked at the code.  I have to say it is
nicely formatted and good to read.  Of course some comments would help
others to understand, but nevertheless, your code is still fairly clear and
in parts seems like "Java style" to me (I don't know why, and it is meant
positive).

However, there is one thing you should really start adding soon:
try-catch blocks.  As it stands your program will just terminate if it runs
out of memory...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3c4f050d@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> I didn't run or compile it, I just looked at the code.  I have to say it is
> nicely formatted and good to read.  Of course some comments would help
> others to understand, but nevertheless, your code is still fairly clear and
> in parts seems like "Java style" to me (I don't know why, and it is meant
> positive).

Good to hear...I was afraid it would be an unreadable mess to anyone 
else. ;-)
Java style? Hmm...I have "learned" the Java language, but never bothered 
to learn the API, and I haven't done anything in it. Maybe it comes from 
my working with Objective C...I've heard both were inspired partly by 
Smalltalk. Or do you mean all the inline functions in the headers? That 
was just lazyness.
BTW, now that I've done some stuff in Objective C and am back working in 
C++, I'm beginning to see why people complain about the way C++ does OOP.
I'm constantly wrestling with it, trying to get it to do things that 
should be very simple with OOP, but have to be worked around because C++ 
isn't dynamic enough. Still better than raw C, though...
Probably too soon to ask, but what do you think of the CSDL language 
itself? Do you know of any other languages that use this concept of OOP?


> However, there is one thing you should really start adding soon:
> try-catch blocks.  As it stands your program will just terminate if it runs
> out of memory...

Error handling is definitely something I need to work on...I've never 
used exceptions before, and I've been putting it off. Right now I'm 
mainly working on plugging memory leaks...there's a lot of them, mainly 
due to a lot of the code being stubbed out or simply not implemented.

-- 
 -- 
Christopher James Huff <chr### [at] maccom>

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote:
: BTW, now that I've done some stuff in Objective C and am back working in 
: C++, I'm beginning to see why people complain about the way C++ does OOP.
: I'm constantly wrestling with it, trying to get it to do things that 
: should be very simple with OOP, but have to be worked around because C++ 
: isn't dynamic enough.

  Could you give some examples?

  (Funnily enough, I seldom have any problems with C++, but the rare cases
where I have to code something with Java, I have to "constantly wrestle" with
it because it has so many braindead limitations which force you to make
non-modular code.)

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

In article <3c4f248e@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   (Funnily enough, I seldom have any problems with C++, but the rare cases
> where I have to code something with Java, I have to "constantly wrestle" with
> it because it has so many braindead limitations which force you to make
> non-modular code.)

Having to duplicate essentially the same code for every subclass (for a 
Copy() function) just so I can make a copy of an object from a 
base-class pointer. Having to return void pointers and cast them to the 
correct types. Mostly having what I can do with an object being 
determined by the type of pointer to it I have, instead of what the 
object can do. Templates.

I haven't done anything in Java though, I don't really know what 
limitations it has. It might be worse.

-- 
 -- 
Christopher James Huff <chr### [at] maccom>

Post a reply to this message