Sorry for re-posting this on the newsgroup but I did not get 
any response to it. 

What about applying this trivial patch? 
I think there is no need to continue the for() loop once 
we set found=true. 

/* NK phmap */
/* this function checks if 'object' is equal to 'parent' or is a child
 * of 'parent'
 */
static int IsObjectInCSG(OBJECT *Object, OBJECT *parent)
{
  OBJECT *Sib;
  int found;

  if (Object == parent) return true;

  found = false;
  if(parent->Type & IS_COMPOUND_OBJECT)
  {
    for (Sib = ((CSG *)parent)->Children; Sib != NULL; Sib = Sib->Sibling)
    {
      if(IsObjectInCSG(Object, Sib))
-        found = true;
+        {  found = true;  break;  }
    }
  }
  return found;
}

BTW, I would appreciate if you could establish ordinary version 
numbers like everybody else does. I mean, the file povuni_s.tgz 
on the FTP should be a symlink to povuni_s-3.5c.tgz or whatever. 

Making available incremental paches would be helpful, too because 
that makes it easier to keep a modified version around (though this 
is not necessary because I can make the patch myself). 

Wolfgang

Post a reply to this message

In article <3e46c362@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

> What about applying this trivial patch?
> I think there is no need to continue the for() loop once
> we set found=true.

Yes, it has been noted.  It will be included sometime in the future.

> BTW, I would appreciate if you could establish ordinary version
> numbers like everybody else does. I mean, the file povuni_s.tgz
> on the FTP should be a symlink to povuni_s-3.5c.tgz or whatever.

The updates are platform specific.  Thus there is no new version, it is
still the same version of POV-Ray.

> Making available incremental paches would be helpful, too because
> that makes it easier to keep a modified version around (though this
> is not necessary because I can make the patch myself).

Due to the cross-platform nature of POV-Ray this is not feasible as it would
have to include platform specific as well as cross-platform changes.

    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:

> In article <3e46c362@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>
> wrote:
> 
>> BTW, I would appreciate if you could establish ordinary version
>> numbers like everybody else does. I mean, the file povuni_s.tgz
>> on the FTP should be a symlink to povuni_s-3.5c.tgz or whatever.
> 
> The updates are platform specific.  Thus there is no new version, it is
> still the same version of POV-Ray.

I'm sorry, but I have to agree with Wolfgang. A version number in the
file name would make sense. It's hard to guess, whether povuni_s.tgz
contains the sources for 3.1, 3.5, 3.5b, 3.6, or whatever. Of course,
if there is no difference in the source code between 3.5a and 3.5b,
it would be povuni_s-3.5.tgz. Different files should get different 
(recognizable) names. 

I am aware of the fact that there are still DOS users out there that
need a 8.3 filename. For the sake of the majority of the users however,
longer names would be preferable. If I remember correctly from the old
DOS days, ftp shortens the filename automatically. So, DOS users would 
not be harmed, but wouldn't benefit from version numbers.

Thomas

Post a reply to this message

Thorsten Froehlich wrote:
> In article <3e46c362@news.povray.org> , Wolfgang Wieser
> <wwi### [at] gmxde> wrote:
>
>> What about applying this trivial patch?
>> I think there is no need to continue the for() loop once
>> we set found=true.
>
> Yes, it has been noted.  It will be included sometime in the future.

How about keeping a running snapshot of the latest work in progress on the
FTP, no guarantees that it will actually compile, use at your own folly etc
etc


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

Post a reply to this message

In article <3e48f6f1@news.povray.org> , Thomas Willhalm 
<tho### [at] uni-konstanzde>  wrote:

> I'm sorry, but I have to agree with Wolfgang. A version number in the
> file name would make sense. It's hard to guess, whether povuni_s.tgz
> contains the sources for 3.1, 3.5, 3.5b, 3.6, or whatever. Of course,
> if there is no difference in the source code between 3.5a and 3.5b,
> it would be povuni_s-3.5.tgz. Different files should get different
> (recognizable) names.

There are no changes to the code that are not Unix specific.  Labeling the
code as you suggest would only cause confusion.

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3e492545$1@news.povray.org> , "Rick [Kitty5]" <ric### [at] kitty5com>
wrote:

> How about keeping a running snapshot of the latest work in progress on the
> FTP, no guarantees that it will actually compile, use at your own folly etc
> etc

No, that would expose changes that require platform specific changes to work
in the first place.  And we do not release such version for very good
reasons, which are obvious if you think about what would happen if we did
release such a source code version, and which in fact did happen in the
past...

    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:

> In article <3e48f6f1@news.povray.org> , Thomas Willhalm
> <tho### [at] uni-konstanzde>  wrote:
> 
>> I'm sorry, but I have to agree with Wolfgang. A version number in the
>> file name would make sense. It's hard to guess, whether povuni_s.tgz
>> contains the sources for 3.1, 3.5, 3.5b, 3.6, or whatever. Of course,
>> if there is no difference in the source code between 3.5a and 3.5b,
>> it would be povuni_s-3.5.tgz. Different files should get different
>> (recognizable) names.
> 
> There are no changes to the code that are not Unix specific.  Labeling the
> code as you suggest would only cause confusion.

Are you ignoring our point on purpose? We want _version_numbers_ in the
_filename_. The archive for 3.5 with source code for unix is called 
povuni_s.tgz, the archive for 3.1g with source code for unix is called 
povuni_s.tgz, and the archive for 3.0 with source code for unix is called 
povuni_s.tgz. If you don't believe me, check it yourself on ftp.povray.org.

I agree with you that one should use the same name if two archives contain 
the same code. However, I'm sure that this is not the case for the source
code of povray 3.0 and povray 3.5 (for any platform).

Thomas

Post a reply to this message

In article <3e4a0f09@news.povray.org> , Thomas Willhalm 
<tho### [at] uni-konstanzde>  wrote:

> Are you ignoring our point on purpose? We want _version_numbers_ in the
> _filename_. The archive for 3.5 with source code for unix is called
> povuni_s.tgz, the archive for 3.1g with source code for unix is called
> povuni_s.tgz, and the archive for 3.0 with source code for unix is called
> povuni_s.tgz. If you don't believe me, check it yourself on ftp.povray.org.

But what is the problem with that?  They are in two completely different
directories!!!  It doesn't cause any problems for the other platforms, and
didn't in the past ten years for Unix either, so why would it be a problem
for Unix archives today?  If someone does not even bother to check about the
directory they are in, well, sorry, a tiny bit of thinking is required when
downloading software.

    Thorsten

Post a reply to this message

Thorsten Froehlich wrote:

> In article <3e492545$1@news.povray.org> , "Rick [Kitty5]"
> <ric### [at] kitty5com> wrote:
> 
>> How about keeping a running snapshot of the latest work in progress on
>> the FTP, no guarantees that it will actually compile, use at your own
>> folly etc etc
> 
> No, that would expose changes that require platform specific changes to
> work
> in the first place.  And we do not release such version for very good
> reasons, which are obvious if you think about what would happen if we did
> release such a source code version, and which in fact did happen in the
> past...

Seems like I'm too stupid to see what's obvious to you. The following
open source projects have public developer version:

OpenOffice
http://www.openoffice.org/dev_docs/source/643c/source.html#getsource
GCC        http://gcc.gnu.org/cvs.html
KDE        http://developer.kde.org/build/compile_cvs.html
Gnome      http://developer.gnome.org/tools/cvs.html
FreeBSD    http://www.freebsd.org/support.html#cvs
Linux      http://www.kernel.org/pub/linux/kernel/v2.5/
Xfree      http://www.xfree86.org/cvs/
Mozilla    http://www.mozilla.org/cvs.html
Apache     http://www.apache.org/foundation/cvs.html
Darwin     http://developer.apple.com/darwin/tools/cvs/
Blender    http://projects.blender.org/cvsx/?group_id=9
Wings3d    http://sourceforge.net/cvs/?group_id=33028

Why does it work for them but not for you?

Thomas

Post a reply to this message

In article <3e4a1b89@news.povray.org> , Thomas Willhalm 
<tho### [at] uni-konstanzde>  wrote:

> Why does it work for them but not for you?

Because fools (aka people who don't read any manuals, readmes, etc) start
patching those versions and the distribute them.  Or people compile them and
never update and then come back three years later complaining that bugs
supposedly haven't been fixed.  Has happened in the past...

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message