Hello,

I am looking for feedback:

This documents is to explain most issues regarding a proposal for new,
additional hooks to significantly better abstract the POV-Ray 4.0 core code
from outside, platform specific implementation details. The goal is a much
more powerful connection with Graphical User Interfaces. These hooks offer
an optional way to specify the render options without a command line and
control rendering as well as replacements and additions for the text stream
based input and output.

Up to version 3.5 POV-Ray only allowed text output and the main control
worked through the command line. Since version 3.0 two more powerful GUI
platforms - Windows and Mac OS - provide text editors but little abstraction
of the command line. However, both platforms surely present the main part of
the POV-Ray users today and a command line environment is no longer state of
the art. Especially Integrated Development Environment applications outline
a reasonable way to move traditionally command line driven programs like
compilers into the GUI age. However, providing IDE like features without
extensive support from the backend, the POV-Ray platform independent core
code, is very hard and resulted in errors and a (today) rather primitive
user interface designs. These new hooks will ease the creation of GUIs on
other platforms as well.

The hooks are designed to be very flexible and extensible. They will allow
future changes in the core code without breaking platform specific code or
forcing changes in it. It can simply ignore the additional information and
immediate changes in platform specific code of all platforms if some hooks
are changed can be avoided in these areas.

In addition, the information about the current hooks is very limited and
some documentation would be helpful for both sides, the GUI as well as the
core code developers, in order to prevent breaking old code by new changes.
So there needs to be a document which contains the details of the POVOC&SS
functions, changes required in each platform specific code and composition
of the messages. It could be used as base for some kind of introduction for
those willing to port POV-Ray to unsupported platforms. With the constantly
increasing complexity of the hooks and other interface functions this has
become a more and more difficult task.

The POV-Ray Output Control & Streaming System (POVOC&SS) is a solution to
the command line and text input and output limitations for GUI systems. It
offers a very easy to extend control mechanism for POV-Ray. Existing command
line driven POV-Ray versions will only need little adjustment while the GUI
platforms may need (more) extensive changes in order to make use of the
newly available features and options. However, nearly full backward
compatibility is provided so GUI platforms do not need to be adapted
immediately.

The current test implementation uses linked lists and some automatically
resized arrays. This is not fast, but speed is not a major design goal,
flexibility is. There is no point to increase speed in most parts, i.e. it
does not matter (much) if an error message output takes 0.1 millisecond or
10 milliseconds.

Comments?

    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

Thorsten Froehlich wrote:
> 
> [...] The goal is a much
> more powerful connection with Graphical User Interfaces. These hooks offer
> an optional way to specify the render options without a command line and
> control rendering as well as replacements and additions for the text stream
> based input and output.

Hmm, sounds interesting, could you give a few examples what would be
possible with this system that does not work with current POV?  Your text
contains quite some information about principal technical aspects but not
about what things will be actually controlled with that 'POVOC&SS'.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Mon, 14 Oct 2002 17:47:23 +0200, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> Comments?

Interesting reading. Nice opening for "more opened development" model. I have
to reread and reconsider carefully this whole statement. BTW: are there any
decision about GUI itself ? Similiar to those from 3.5 ?

ABX

Post a reply to this message

In article <qaqlqu0vj236nmug0tljdt7bhl3269fhst@4ax.com>,
 ABX <abx### [at] abxartpl> wrote:

> BTW: are there any decision about GUI itself ? Similiar to those from 
> 3.5 ?

I'm not sure what your question is. The GUI itself is very platform 
dependant, and will probably remain that way. There are cross-platform 
frameworks, but those are pretty much equally bad on all platforms. ;-)
There will probably be similarities because they are designed to do the 
same thing, and ideas will be shared, but I doubt there will be anything 
like a standardized interface...

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

On Mon, 14 Oct 2002 12:54:47 -0400, Christopher James Huff <chr### [at] maccom>
wrote:
> > BTW: are there any decision about GUI itself ? Similiar to those from 
> > 3.5 ?
>
> I'm not sure what your question is. The GUI itself is very platform 
> dependant, and will probably remain that way. There are cross-platform 
> frameworks, but those are pretty much equally bad on all platforms. ;-)
> There will probably be similarities because they are designed to do the 
> same thing, and ideas will be shared, but I doubt there will be anything 
> like a standardized interface...

I did not wrote "standarized" anywhere. I'm just wondering if codemax editor
would be continued in case of Win. But I understand my question is asked in
wrong time. There is no place for GUI decision right now. Anyway if you are
talking about "standardized interface" I'm thinking about making integrated
IDE for recently updated TVision (http://tvision.sf.net). Day after day it is
more portable and works with many compilers and could be nice optional layer
for many platforms. But I have not tested it yet. Just remember flexibility
from days of Borland ruling.

ABX

Post a reply to this message

Christopher James Huff wrote:

 > I'm not sure what your question is. The GUI itself is very platform
 > dependant, and will probably remain that way. There are
 > cross-platform frameworks, but those are pretty much equally bad on
 > all platforms. ;-) There will probably be similarities because they
 > are designed to do the same thing, and ideas will be shared, but I
 > doubt there will be anything like a standardized interface...
 >
Why not? Why not to implement cross-platform UI by using some 
(scriping??) language? I guess suppirting Windows/Linux/Unix/MacOS 
should be sufficient and there is quite a number of tools for such task: 
Tk/Tcl (or whatever it was called, never can't remember it :-), Python 
(Yea, I know, that some here
hate Python, but Pyvon seems to be nice step in direction of 
cross-platformness), Java with JNI for interface with POV-Ray core etc.

Performance of UI shouldn't be problem.

Post a reply to this message

In article <qaqlqu0vj236nmug0tljdt7bhl3269fhst@4ax.com> , ABX 
<abx### [at] abxartpl>  wrote:

> Interesting reading. Nice opening for "more opened development" model. I have
> to reread and reconsider carefully this whole statement. BTW: are there any
> decision about GUI itself ? Similiar to those from 3.5 ?

Well, for a GUI the stuff that is available as part of Mozilla looks very
interesting.  Maybe increasing the level of abstraction and then just
running POV-Ray as a backend to a webbrowser might be sufficient.  After
all, there are plenty of editors out there, so no need for a dedicated
GUI...

    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 <3DA### [at] starmanee> , Vahur Krouverk 
<vkr### [at] starmanee>  wrote:

> Why not? Why not to implement cross-platform UI by using some
> (scriping??) language? I guess suppirting Windows/Linux/Unix/MacOS
> should be sufficient and there is quite a number of tools for such task:
> Tk/Tcl (or whatever it was called, never can't remember it :-), Python
> (Yea, I know, that some here
> hate Python, but Pyvon seems to be nice step in direction of
> cross-platformness), Java with JNI for interface with POV-Ray core etc.

Well, as far as a scripting language for 4.0 we have been considering to
allow functions written in Perl or maybe Scheme would be a good idea.  That
would make all those people happy who don't like the current scripting
capabilities.  And users could extend the GUI this way from inside POV-Ray
scene files.


    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 <3DA### [at] starmanee>,
 Vahur Krouverk <vkr### [at] starmanee> wrote:

> Why not? Why not to implement cross-platform UI by using some 
> (scriping??) language? I guess suppirting Windows/Linux/Unix/MacOS 
> should be sufficient and there is quite a number of tools for such task: 
> Tk/Tcl (or whatever it was called, never can't remember it :-), Python 
> (Yea, I know, that some here hate Python, but Pyvon seems to be nice 
> step in direction of cross-platformness), Java with JNI for interface 
> with POV-Ray core etc.

I covered that...the results are usually just horrible. Tune things to 
look good on one platform, and it looks awful on all others...different 
interface conventions, different look and feel, etc...you end up having 
to make platform-specific versions anyway.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

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

> Hmm, sounds interesting, could you give a few examples what would be
> possible with this system that does not work with current POV?  Your text
> contains quite some information about principal technical aspects but not
> about what things will be actually controlled with that 'POVOC&SS'.

Well, assuming some classes like below, one could remove user interface
dependincies from the core code and just allow overloading of a few classes
to transmit data...

    Thorsten

*******************

class Container
{
 public:
  Container();
  virtual ~Container();
  DataType DataType();
  long Size();
};

class List : public Container, public list<Container>
{
 public:
  List();
  List(List source);
  virtual ~List();
  void Append(Container item);
  void GetNth(int index, Container item);
  void SetNth(int index, Container item);
  void RemoveNth(int index);
  void Clear();
};

class Object : public Container, public map<DataType,Container>
{
 public:
  Object(DataType objclass);
  Object(Object convert);
  Object(Object source);
  ~Object();
  void Get(Container attr, DataType key);
  void Set(Container attr, DataType key);
  void Remove(DataType key);
  void Exist(DataType key);
};

class Status : public Object
{
 public:
  Status(string statusmsg);
  ~Status();
};

class Statistics : public Object
{
 public:
  Status(string statusmsg);
  ~Status();
};

class Warning : public Object
{
 public:
  Status(string statusmsg);
  ~Status();
};

class Error : public Object
{
 public:
  Status(string statusmsg);
  ~Status();
};



____________________________________________________
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 <3dab1335@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> Well, as far as a scripting language for 4.0 we have been considering to
> allow functions written in Perl or maybe Scheme would be a good idea.  That
> would make all those people happy who don't like the current scripting
> capabilities.  And users could extend the GUI this way from inside POV-Ray
> scene files.

Perl? Yuck. ;-)

I don't really know if it is relevant to this, but would OSA be of any 
use? (OSA == Open Scripting Architecture)
I don't know the status of OSA on non-Mac platforms, but if it is useful 
for this it would allow any language with an OSA plugin to be 
used...AppleScript, Ruby, JavaScript, probably Python and Perl, and 
others. I don't really know anything about OSA though, just an 
association that popped up when I read this.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

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

> Well, for a GUI the stuff that is available as part of Mozilla looks very
> interesting.  Maybe increasing the level of abstraction and then just
> running POV-Ray as a backend to a webbrowser might be sufficient.  After
> all, there are plenty of editors out there, so no need for a dedicated
> GUI...

Maybe a plugin for jEdit...it seems to be a pretty good code editor, and 
it already has syntax coloring for POV. It'd just need to show rendering 
progress, error/status/info messages, and provide a render button/menu 
item. Making people download and install a separate Java program would 
be seen as pretty unfriendly, but I think jEdit would be better for this 
than Mozilla.

jEdit is a good example of what I was saying in the other messages 
though...it is a good program with a UI that will look familiar to 
someone on Windows, but it breaks a lot of Mac conventions. It even uses 
Aqua interface elements, but there is no way you could mistake it for a 
native Mac OS X program.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Thorsten Froehlich wrote:
> 
> Well, assuming some classes like below, one could remove user interface
> dependincies from the core code and just allow overloading of a few classes
> to transmit data...
> [...]

Actually my question was what in the end the user of POV-Ray will profit
from this.  So far i understand it will be a possibly larger variety of
frontends.  Are there other advantages?

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

Hello,

You know, I have to explain something.  My post was just a test.  In fact
what it describes already exists in POV-Ray 3.5 and is known under the name
POVMS and the document itself is rather old.  I just made this post in order
to get an idea what would happen should 4.0 design be discussed publicly at
all.  What I said has absolutely *no* relation to any team plans regarding
4.0.

I have to admit the results were rather surprising.  I had expected more
controversy or someone noticing immediately that it already exists.  What
happened is that there was little controversy (even when I started to make
really ridiculous suggestions such as using Mozilla as GUI, but maybe nobody
took that serious?) and nobody noticed that something like this already
exists.  Even those who have played with the source code very long.  And the
classes I posted later are almost an exact copy from povmscpp.h with all
reasonable or working features (such a arguments passed by reference)
removed.

In summary, I am not sure what to make out of the "result" I got with my
little experiment...

    Thorsten



The original document (actually only tiny little subset of its introduction)
as I had posted it back somewhere in the private POV-Team CompuServe GO
POVRAY forum back in 1999/2000:


This documents is to explain most issues regarding a proposal for new,
additional hooks to significantly better abstract the POV-Ray 3.5 core code
from outside, platform specific implementation details. The goal is a much
more powerful connection with Graphical User Interfaces. These hooks offer
an optional way to specify the render options without a command line and
control rendering as well as replacements and additions for the text stream
based input and output.

Up to version 3.1 POV-Ray only allowed text output and the main control
worked through the command line. Since version 3.0 two more powerful GUI
platforms - Windows and Mac OS - provide text editors but little abstraction
of the command line. However, both platforms surely present the main part of
the POV-Ray users today and a command line environment is no longer state of
the art. Especially Integrated Development Environment applications outline
a reasonable way to move traditionally command line driven programs like
compilers into the GUI age. However, providing IDE like features without
extensive support from the backend, the POV-Ray platform independent core
code, is very hard and resulted in errors and a (today) rather primitive
user interface designs. These new hooks will ease the creation of GUIs on
other platforms as well.

The hooks are designed to be very flexible and extensible. They will allow
future changes in the core code without breaking platform specific code or
forcing changes in it. It can simply ignore the additional information and
immediate changes in platform specific code of all platforms if some hooks
are changed can be avoided in these areas. Especially for a future C++
version of POV-Ray these hooks will be helpful and reduce or eliminate
changes to this crucial part of every platform specific user interface for
POV-Ray. Currently a set of C++ wrapper classes for the POVMS is
available.

In addition, the information about these hooks is very limited and some
documentation would be helpful for both sides, the GUI as well as the core
code developers, in order to prevent breaking old code by new changes. This
document contains the details of the POVMS functions, changes required in
each platform specific code and composition of the messages. It could be
used as base for some kind of introduction for those willing to port POV-Ray
to unsupported platforms. With the current and the constantly increasing
complexity of the hooks and other interface functions this has become a more
and more difficult task.

The POV-Ray Message System (POVMS) is a solution to the command line and
text input and output limitations for GUI systems. It offers a very easy to
extend control mechanism for POV-Ray. Existing command line driven POV-Ray
versions will only need little adjustment while the GUI platforms may need
(more) extensive changes in order to make use of the newly available
features and options. However, nearly full backward compatibility is
provided so GUI platforms do not need to be adapted immediately. A macro to
compile POV-Ray without POVMS is provided for platforms that do not use the
POVMS. This way no additional code is generated, and no time is wasted
creating messages that are not used.



____________________________________________________
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

Thorsten Froehlich wrote:
> 
> Hello,
> 
> You know, I have to explain something.  My post was just a test.  In fact
> what it describes already exists in POV-Ray 3.5 and is known under the name
> POVMS and the document itself is rather old.  I just made this post in order
> to get an idea what would happen should 4.0 design be discussed publicly at
> all.  What I said has absolutely *no* relation to any team plans regarding
> 4.0.

Well, that explains your quite strange answer to my question.

> I have to admit the results were rather surprising.  I had expected more
> controversy or someone noticing immediately that it already exists.  What
> happened is that there was little controversy (even when I started to make
> really ridiculous suggestions such as using Mozilla as GUI, but maybe nobody
> took that serious?) and nobody noticed that something like this already
> exists.  Even those who have played with the source code very long. [...]

I doubt there is much to conclude from this test.  First what it is about
is a part of POV-Ray not of much interest for someone starting to deal
with the POV-Ray source code.  The first time i stumbled across POVMS was
when i added some new element to the statistics and even that did not go
into depth.  And second you did not really start a discussion about
anything important.  As it seems you just described a few details about
something that already exists in POV-Ray.  Why should anyone have concerns
about that? ;-) 

If you really want to find out whether public discussion of things could
be useful for 4.0 development there is no other way but to try it.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

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

> I doubt there is much to conclude from this test.  First what it is about
> is a part of POV-Ray not of much interest for someone starting to deal
> with the POV-Ray source code.  The first time I stumbled across POVMS was
> when I added some new element to the statistics and even that did not go
> into depth.  And second you did not really start a discussion about
> anything important.  As it seems you just described a few details about
> something that already exists in POV-Ray.  Why should anyone have concerns
> about that? ;-)

Well, yes, a flame war or someone noticing that it already existed would
have been far more conclusive :-(

> If you really want to find out whether public discussion of things could
> be useful for 4.0 development there is no other way but to try it.

The problem is that if that would be done and we get burned, then we got
burned permanently.  I don't want to have to answer the (as I expect it)
resulting misunderstandings for the next half decade ... the problem is we
can't keep the usual group of general users from reading such public
discussions and getting completely misdirected :-(  No matter how big the
disclaimers ;-)

I am already expecting somebody tell me in a few weeks that I suggested Perl
or Scheme as scripting languages for 4.0 also that was just such a clear
joke...


    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 summary, I am not sure what to make out of the "result" I got with my
> little experiment...

It sounds like a case of "the emperor's new clothes" to me.  Perhaps 
those who did notice strange things about your post (like that there 
wasn't anything new in it, and that you were suggesting things totally 
out of character with POV development) just thought, "No one else seems 
to find it strange, so perhaps I'm imagining it."

Nice experiment though, if not particularly successful.

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3dac7374$1@news.povray.org...
> I am already expecting somebody tell me in a few weeks that I suggested
Perl
> or Scheme as scripting languages for 4.0 also that was just such a clear
> joke...
>
>
>     Thorsten
>

I did think that odd coming from you, however what it reminded me of was
this IRTC winner that was written with a perl script.

http://oz.irtc.org/ftp/pub/anims/1998-07-15/marble.txt

Post a reply to this message

On Tue, 15 Oct 2002 20:11:23 +0200, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> You know, I have to explain something.  My post was just a test.

In fact I think it was small success in the test for one reason. I somehow
felt there was always fear in Team about talking about internals (not just
answers to questions). But finally you wrote something and there was no
flaming in response, no critique. Nobody said "better optimize isosurfaces
speed", "work on bugs", "POV-Ray is outdated" or "The Team is lazy and rude". 

> In fact
> what it describes already exists in POV-Ray 3.5 and is known under the name
> POVMS and the document itself is rather old.

Don't you think that after two months of sources we are concerned on bugs, and
"todos" gathered during previous year of waiting for 3.5 ? There is over 90
files in package (not counting platform specific) and less then 80 days since
sources are available. How we could learn ideas so fast when you worked over
them two years?

And... I'm still thinking serious about your initial post. Not only becouse
real implementation but becouse of inspirations I get to extend knowledge. You
can say "we have to hold decisions in team becouse there is nobody brave to
discute or nobody with apropriate skills". But we learn all the time. I think
I'm not only person who started diging net for some references about design.
So please don't stop, just cheat less with every next post ;-)

ABX

Post a reply to this message

ABX wrote:
> 
> ..."better optimize isosurfaces speed", ...
> 

Actually that would be...

;-)

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

Thorsten Froehlich wrote:
> Well, as far as a scripting language for 4.0 we have been considering
> to allow functions written in Perl or maybe Scheme would be a good
> idea.  That would make all those people happy who don't like the
> current scripting capabilities.  And users could extend the GUI this
> way from inside POV-Ray scene files.

we want VB dammit :)

--
Rick

Kitty5 NewMedia http://Kitty5.co.uk
POV-Ray News & Resources http://Povray.co.uk
TEL : +44 (01270) 501101 - FAX : +44 (01270) 251105 - ICQ : 15776037

PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA



---

Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.401 / Virus Database: 226 - Release Date: 09/10/2002

Post a reply to this message

"Rick [Kitty5]" <ric### [at] kitty5com> wrote in news:3dad2f47@news.povray.org:

> Thorsten Froehlich wrote:
>> Well, as far as a scripting language for 4.0 we have been considering
>> to allow functions written in Perl or maybe Scheme would be a good
>> idea.  That would make all those people happy who don't like the
>> current scripting capabilities.  And users could extend the GUI this
>> way from inside POV-Ray scene files.
> 
> we want VB dammit :)

No, VB support of vectors is awful! Better use APL. The version which 
needs special fonts and little stickers on the keyboard...

-- 
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/

Post a reply to this message

On Tue, 15 Oct 2002 21:58:39 +0200, Thorsten Froehlich wrote:
> I am already expecting somebody tell me in a few weeks that I suggested Perl
> or Scheme as scripting languages for 4.0 also that was just such a clear
> joke...

Aw, man, and I was looking forward to implementing that.  :)

-- 
#macro R(P)z+_(P)_(P)_(P+1)_(P+1)+z#end#macro Q(C,T)bicubic_patch{type 1u_steps
6v_steps 6R(1)R(3)R(5)R(7)pigment{rgb z}}#end#macro _(Y)#local X=asc(substr(C,Y
,1))-65;<T+mod(X,4)div(X,4)9>-2#end#macro O(T)Q("ABEFUQWS",T)Q("WSXTLOJN",T)#
end O(0)O(3)Q("JNKLCGCD",0)light_source{x 1}// ron### [at] povrayorg

Post a reply to this message

In article <Xns### [at] 204213191226>,
 Philippe Lhoste <Phi### [at] GMXnet> wrote:

> No, VB support of vectors is awful! Better use APL. The version which 
> needs special fonts and little stickers on the keyboard...

Heh...I've heard that APL is an awful language. Any examples?

I'm working on a little language (called "G" for the moment) which is 
designed for 3D graphics (basically a shader language), I'm trying to 
make it do numeric stuff as fast as possible for an interpreted 
language. It'll be nothing like Sapphire, it will be as static as 
possible and won't be OO, but the syntax will probably be fairly 
similar. I don't know any of the shading languages, but the interpreter 
will hopefully be flexible enough to handle them if a compiler is 
written.
Some assembly knowledge would probably help a lot...stack machines are 
easy, but I don't know how to write a compiler for a register based 
machine.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

The fact that you even started a thread of that nature seemed a bit like a
tip-off ;-).

H²

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote in news:chrishuff-
0A9### [at] netplexaussieorg:

> In article <Xns### [at] 204213191226>,
>  Philippe Lhoste <Phi### [at] GMXnet> wrote:
> 
>> No, VB support of vectors is awful! Better use APL. The version which 
>> needs special fonts and little stickers on the keyboard...
> 
> Heh...I've heard that APL is an awful language. Any examples?

A Google search on APL language sample gave me a number of links, but no 
graphical example of what the original language was.
I have a book on the language, though I have not programmed it... It was 
fun, using a number of special symbols, some greek, some others produced, 
at the time, by surperposing two symbols on the CRT...
Not very readable, but fun and very terse...

It seems that modern compilers replaced these symbols by keywords...
See a page of codes to solve a "real" problem at 
<http://www.chilton.com/~jimw/ballclk.html> for example.

> I'm working on a little language (called "G" for the moment) which is 
> designed for 3D graphics (basically a shader language), I'm trying to 

What is exactly a shader language. I see this a lot with Renderman and 
compatibles, but I am not sure of what it is and how it is used... 
Something like procedural textures?

> make it do numeric stuff as fast as possible for an interpreted 
> language. It'll be nothing like Sapphire, it will be as static as 
> possible and won't be OO, but the syntax will probably be fairly 
> similar. I don't know any of the shading languages, but the interpreter 
> will hopefully be flexible enough to handle them if a compiler is 
> written.
> Some assembly knowledge would probably help a lot...stack machines are 
> easy, but I don't know how to write a compiler for a register based 
> machine.

Good luck (even if luck isn't the right word :-).

-- 
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/

Post a reply to this message

In article <Xns### [at] 204213191226>,
 Philippe Lhoste <Phi### [at] GMXnet> wrote:

> It seems that modern compilers replaced these symbols by keywords...
> See a page of codes to solve a "real" problem at 
> <http://www.chilton.com/~jimw/ballclk.html> for example.

Gah! And this language *wasn't* designed to be obfuscated?


> What is exactly a shader language. I see this a lot with Renderman and 
> compatibles, but I am not sure of what it is and how it is used... 
> Something like procedural textures?

It means a language that you write shaders in. ;-)
A shader is just a piece of code that computes the color of an object. 
They are usually used for procedural textures.
POV-Ray functions could be considered a very primitive shader language, 
the texture language is nearly as flexible as a more "traditional" 
language, though it is harder to accomplish some of the same things and 
some things aren't possible.

G will have a fairly C-like syntax:
scalar myScalar = 3.14159;
vector y = < 0, 1, 0>;

function scalar VNormalize(vector vec);

function scalar VNormalize(vector vec) {
    return sqrt(vec.x*vec.x + vec.y*vec.y + vec.z*vec.z);
};

The loops and conditionals will have the same syntax they do in 
Sapphire, it will be very C-like.
That's pretty much it...scalars, vectors, and functions. Maybe arrays 
will be added. While Sapphire is extremely dynamic and flexible, this 
will be as simple and static as possible.
I'll probably make an attempt to add it to POV, the syntax will be 
something like:
g {
    //G declarations and statements
    function vector Foo(vector pt) {...};
}

G functions will be called through POV functions:
#declare Foo = function (n) {g {return Foo(n);}}
Or maybe something like this:
#declare Foo = g_function Foo(n);

You would also be able to use Foo in a pigment:
pigment {g_function Foo}

I haven't decided how to pass POV variables through to G functions yet. 
Maybe by calling a G function to set a G variable, maybe by adding some 
"import" directive to grab a variable from the POV namespace.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Philippe Lhoste wrote:
>> we want VB dammit :)
>
> No, VB support of vectors is awful! Better use APL. The version which
> needs special fonts and little stickers on the keyboard...

Now that will really turn people off POV
--
Rick

Kitty5 NewMedia http://Kitty5.co.uk
POV-Ray News & Resources http://Povray.co.uk
TEL : +44 (01270) 501101 - FAX : +44 (01270) 251105 - ICQ : 15776037

PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA



---

Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.401 / Virus Database: 226 - Release Date: 09/10/2002

Post a reply to this message

Christopher James Huff wrote:

> G will have a fairly C-like syntax:

[Snip]
Why G? Why not Cg or RenderMan SL? They have also C-like syntax and do 
same thing basically. And then you can use existing shaders without 
conversion.

Post a reply to this message

In article <3DB### [at] starmanee>,
 Vahur Krouverk <vkr### [at] starmanee> wrote:

> Why G? Why not Cg or RenderMan SL? They have also C-like syntax and do 
> same thing basically. And then you can use existing shaders without 
> conversion.

Because:
1: I don't know them.
2: I'm doing this largely as an experiment in designing this kind of 
language and interpreter, duplicating others would be useless.
3: Others have already done interpreters for those.
4: I can make whatever changes I want and try out new ideas.

Once I have it up and running (which will happen much sooner than for 
Sapphire, it is a very simple language), I'll look at making compilers 
for other languages that use the same VM (I'm especially interested in 
Cg), but I'll have to learn them first.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message