ABX wrote:
> 
> Two solutions. First, I can remove my modifications and turn off warnings -
> but then incorporating new patches can have some warnings I could not catch.
> Second, I can remove old behaviours and stay with new syntax when it not
> changes features. Personally I prefer second solution but temporary I stayed
> with #ifdefs to highlight all places modified by me.

The description of your second solution seems confusing to me.  You mean
you change the code but don't mark it with ifdef's? That would be a bad
idea for a general patch collection. As several people pointed out the
basis should always be the current official version.  

IMO it would be good if every patch had a clear description of it's
purpose and a list of modified places in the source in addition to the
user documentation.  Something like:

F_TRIANGLE_PATCH

introduces a new internal function 'f_triangle'.

Modified source files:

- 'fnintern.cpp'
    * several helper macros at the beginning of the file
    * f_triangle() function declaration and implementation
    * added entry to 'POVFPU_TrapTable'
    * changed 'POVFPU_TrapTableSize'

I think this is something easy to write for the author of the patch and it
would help maintaining patch collections.

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

ABX wrote:
> 
> > You should really release
> > the source code,
> 
> surprise at www.abx.art.pl/pov/popov :-)

Another thing about the source: Your unofficial version handling is
somewhat different from what i know from MLPov and Ryoichi Suzuki's df3
patch.  I think there should be a 'opts.Unofficial_Version' with a
seperate unofficial version number.  Your method of adding it to the main
version will at least lead to problems if there is official POV-Ray
3.51/3.6/...

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 Tue, 22 Oct 2002 19:14:48 +0200, Christoph Hormann <chr### [at] gmxde>
wrote:
> Another thing about the source: Your unofficial version handling is
> somewhat different from what i know from MLPov and Ryoichi Suzuki's df3
> patch.  I think there should be a 'opts.Unofficial_Version' with a
> seperate unofficial version number.  Your method of adding it to the main
> version will at least lead to problems if there is official POV-Ray
> 3.51/3.6/...

I think you missed flag UnofficialVersion.
I did not compared any other unofficial pack about handling it yet becouse
could not find any suggested way of making it. I have checked MegaPOV for it
but that implementation seemed overcomplicated for me.

ABX

Post a reply to this message

On Mon, 21 Oct 2002 21:30:14 +0200, Christoph Hormann <chr### [at] gmxde>
wrote:
> i somehow find it a bad habit
> to offer binaries a lot earlier than the source.

Now I have comparison. Binaries are downloaded twice more than sources.

ABX

Post a reply to this message

On Tue, 22 Oct 2002 18:48:12 +0200, Christoph Hormann <chr### [at] gmxde>
wrote:
> > Two solutions. First, I can remove my modifications and turn off warnings -
> > but then incorporating new patches can have some warnings I could not catch.
> > Second, I can remove old behaviours and stay with new syntax when it not
> > changes features. Personally I prefer second solution but temporary I stayed
> > with #ifdefs to highlight all places modified by me.
>
> The description of your second solution seems confusing to me.  You mean
> you change the code but don't mark it with ifdef's? That would be a bad
> idea for a general patch collection.

If there could be general agreement and knowledge what is changed then I don't
think so.

> As several people pointed out the
> basis should always be the current official version.  

Then I prefer it as is.

> - 'fnintern.cpp'
>     * several helper macros at the beginning of the file
>     * f_triangle() function declaration and implementation
>     * added entry to 'POVFPU_TrapTable'
>     * changed 'POVFPU_TrapTableSize'

Seems logical.

ABX

Post a reply to this message

ABX wrote:
> 
> I think you missed flag UnofficialVersion.

A search for 'UnofficialVersion' in your source code did not find
anything.

> I did not compared any other unofficial pack about handling it yet becouse
> could not find any suggested way of making it. I have checked MegaPOV for it
> but that implementation seemed overcomplicated for me.

Here is the relevant part from MLPov:

      /*ML: version_patch*/
     #ifdef MLUNOFFICIAL
     /* parse unofficial version */
     Get_Token();
     if (pov_stricmp(Token.Token_String,"mlpov") != 0)
     {
       Error("This version only recognizes #version unofficial mlpov\n"); 
     }
     opts.Unofficial_Version = (int)(Parse_Float() * 100 + 0.5);;
     Parse_Semi_Colon(false);
     if (opts.Unofficial_Version > UNOFFICIAL_VERSION_NUMBER)
     {
        Error("Your scene file requires MLPOV version %g or later!\n",
(DBL)(opts.Unofficial_Version / 100.0));
     }

     [...]

I think this is fairly simple (compared to megapov) and you can also quite
easily add support for multiple unofficial version strings (in case
several patches are merged and old scene files should render without
changes).

The 'Unofficial_Version_Blocking()' function seems a good idea though.

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 Wed, 23 Oct 2002 09:57:56 +0200, Christoph Hormann <chr### [at] gmxde>
wrote:
> A search for 'UnofficialVersion' in your source code did not find
> anything.


Sorry, I have wronly reported from my broken memory.
It is 'int Unofficial;' in povray.h.

> Here is the relevant part from MLPov:

I was not concerned on MLPOV becouse Mael refused :-( to participate patches
repository earlier. Perhaps he changed his opinion after current shape of
repository and PoPOV.

> I think this is fairly simple (compared to megapov) and you can also quite
> easily add support for multiple unofficial version strings (in case
> several patches are merged and old scene files should render without
> changes).

I will check and reconsider it.

> The 'Unofficial_Version_Blocking()' function seems a good idea though.

Thanks.

ABX

Post a reply to this message

ABX wrote:
> 
> Sorry, I have wronly reported from my broken memory.
> It is 'int Unofficial;' in povray.h.

Well, that's just a boolean value right now.

> 
> I was not concerned on MLPOV becouse Mael refused :-( to participate patches
> repository earlier. Perhaps he changed his opinion after current shape of
> repository and PoPOV.

As discussed in the 'United POV-Ray'-thread there is probably still some
way to go until there is a user friendly and well working patch
collection.  And Mael often stated his patches are strongly WIP.

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 Wed, 23 Oct 2002 10:47:32 +0200, Christoph Hormann <chr### [at] gmxde>
wrote:
> As discussed in the 'United POV-Ray'-thread there is probably still some
> way to go until there is a user friendly and well working patch
> collection.  And Mael often stated his patches are strongly WIP.

Patching seems to be always WIP :-)

ABX

Post a reply to this message

I was wandering through your website and found out that
http://abx.art.pl/pov/ contains an error: it links to
http://abx.art.pl/pov/bonus\pack.php instead of
http://abx.art.pl/pov/bonus/pack.php (the last slash is wrong)

regards,
apache


ABX wrote:
>Hi!
>
>New version of PoPOV is available at http://abx.art.pl/pov/popov/
>
>This release contains next set of patches I gathered in repository at
>http://abx.art.pl/pov/patches/ and introduce windows port. Sorry for lack of
>sources and documentation. I have to make some work on them. I hope it can be
>already usefull for community.
>
>Thanks to all contributors (they are listed in banners).
>
>Request:
>please, help me create better examples for features, in particular for normals
>in smooth heighfield. Thanks.
>
>ABX
>

Post a reply to this message