Warp wrote:
>   "I used this solution and it proved to be very fast" is not a proof
> of anything relevant. It only proves that that specific solution is fast.
> It doesn't prove that other more flexible solutions are not equally fast.

If you think scalability is not a sign of quality, I can't help you.

	Thorsten

Post a reply to this message

Darren New wrote:
> You *can* make it work, mind, but it
> can be harder than if you're using a less-data-driven type of parser.

Exactly my point.

	Thorsten

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Or not even that, if you're using a language with reflection. ;-) It's 
> exactly the kind of extensibility that Warp is talking about that 
> frustrates me so much trying to do big programs in C or C++, with no 
> programmatic access to the code I wrote myself. Why should I have to 
> tell the compiler *and* the application what the name of the class I 
> just added is? :-)

  It's not like you couldn't "plug in" new modules at runtime.
I was simply thinking about compile-time efficiency. But if you
really *want* to, you can make the generic parser in such way
that you don't have to modify anything at all in its source code
in order to add new modules to it (just register some base class
type pointers at runtime).
  I believe some libraries actually work like that.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> in order to add new modules to it (just register some base class
> type pointers at runtime).

Right. And using reflection, you wind up using the symbol table the 
compiler generated to do that registration, the mapping of the string 
"sphere" to the function create_Sphere(). Adding the "register a pointer 
at runtime" is overhead that's unnecessary in many languages that have 
reflection. And it becomes even more important when you start working 
with things like libraries to serialize arbitrary structures, rather 
than just invoking a function with a known signature. I wrote a 
transaction processing system once where adding a new transaction 
consisted of putting the file with the implementation of the transaction 
in the executing directory. Didn't even need to restart the server, nor 
did I actually write any extra code to manage that.

(Since this is now nothing to do with POV-Ray, I've set the followup.)

-- 
   Darren New / San Diego, CA, USA (PST)
     New horror show, now only in Las Vegas:
        HANNIBAL LUXOR!

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> Warp wrote:
> >   "I used this solution and it proved to be very fast" is not a proof
> > of anything relevant. It only proves that that specific solution is fast.
> > It doesn't prove that other more flexible solutions are not equally fast.

> If you think scalability is not a sign of quality, I can't help you.

  I was not asking for help. And nowhere did I claim that.

  What I objected was that you said that since you used a certain solution,
and that solution proved to be fast, that must be the *only* possible
solution to the problem and all other solutions are worse.

  You say that in your experience a modular solution is hard to maintain
and inefficient. My own experience says otherwise.

-- 
                                                          - Warp

Post a reply to this message

"Marc" <jac### [at] wanadoofr> wrote in message 
news:45c23bfb$1@news.povray.org...
>

> web.45c1d8014a1d3fd8f1cb1e660@news.povray.org...
>
>> PS The fish were our pleasure :-)
> I vote for a fishbowl with these words engraved  "So long and thanks 
> for...."

... all the Eels.


The Moray Eel:
  http://www.amonline.net.au/FISHES/students/focus/gymno.htm

Post a reply to this message

"Brian Elliott" <NotForSpam@AskIfUWant> wrote:
> "Marc" <jac### [at] wanadoofr> wrote in message
> news:45c23bfb$1@news.povray.org...
> >

> > web.45c1d8014a1d3fd8f1cb1e660@news.povray.org...
> >
> >> PS The fish were our pleasure :-)
> > I vote for a fishbowl with these words engraved  "So long and thanks
> > for...."
>
> ... all the Eels.
>
>
> The Moray Eel:
>   http://www.amonline.net.au/FISHES/students/focus/gymno.htm

LOL

Oh! I know that one. It lives in the Moray Firth :-)


Stephen

Post a reply to this message

Chris Cason wrote:
> [Followups set to povray.general]
> 
> 1 February 2007
> ---------------
> 
> The following is a joint announcement from Persistence of Vision Raytracer
> Pty. Ltd. ('POV'), Lutz Kretzschmar (Lutz) and Markus Lutz (Markus).
> 
> Persistence of Vision Raytracer Pty. Ltd. is pleased to advise that it has
> acquired the rights to the 3d modeller 'Moray' from Lutz and Markus. Moray is
> a Windows program specifically designed to create 3d models and scenes to be
> used with the POV-Ray raytracer, and was originally sold as trialware.
> 
> POV will, in due course, re-issue Moray under a new name and new license. The
> license has not been decided on with finality, but will be OSI-approved. [POV
> is planning to release it under the GPLv3 but this decision is subject of
> course to review of the final version of that license.]
> 
> The POV-Team is continuing development on version 3.7, which is the last
> planned major release of the current POV-Ray codebase prior to version 4.0.
> 
> Version 4.0 will be released under an OSI-approved license. POV has not
> decided on which license will be chosen at this stage. Those portions of the
> codebase that are not already re-releasable under an OSI license will, prior
> to the release of 4.0, be re-written so as to permit them to be released
> under one. Some of the 'new to version 3.7' codebase is already able to be
> released under both the old and newly-chosen license.
> 
> The current version 3.7 development codebase will be made publicly available
> at around the same time as the Moray codebase. This will allow the public to
> assist, if they wish, in completing version 3.7 of POV-Ray and will also
> assist in the transition to 4.0. POV hopes to be able to announce the final
> 4.0 license choice at this time.
> 
> There is no schedule for the release of 4.0. It will primarily depend on the
> amount of public assistance that is received in re-writing non-OSI-licensable
> code.
> 
> Lutz and Markus have their own announcement available on their news page,
> which can be found at http://www.stmuc.com/moray/menews.html.
> 
> The text of this announcement itself can be found on the POV-Ray site at
> http://www.povray.org/news/moray-announcement.php.
> 
> 

Has there been any further action taken on this?

Post a reply to this message

Have a look at the beginning of the Thread:

http://news.povray.org/povray.general/thread/%3C46de836a%241%40news.povray.org%3E/

Regards
Arne
> 
> Has there been any further action taken on this?

Post a reply to this message

Arne Kleinophorst wrote:
> Have a look at the beginning of the Thread:
> 
> http://news.povray.org/povray.general/thread/%3C46de836a%241%40news.povray.org%3E/ 
> 
> 
> Regards
> Arne
>>
>> Has there been any further action taken on this?

 From the thread:

"...that more work on Moray would be post-3.7..."

Hmmm, if that's the case, then it could be a LONG time... Well, ok... 
that's how it is. Thx.

Post a reply to this message