Le_Forgeron <jgr### [at] freefr> wrote:
> Now, CLOCK_PROCESS_CPUTIME_ID is posix, so should we just hate freebsd 7.2 and lower
for
> not having it ? (no assertion about 8.0)

Sounds like a reasonable option :P (SCNR)

I'd say it depends on how complicated it would be to fix. At any rate, it's
worth entering into the bugtracker as a compatibility issue. As you seem to be
into details to some degree, would you mind...? kthxbye ;)

Post a reply to this message

clipka wrote:
> From the details I gather that you are trying to compile on some Unix/Linux
> machine;


Did anyone else see Clippy floating in the air there while reading this?

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Le 15/07/2009 19:40, clipka nous fit lire :
> Le_Forgeron <jgr### [at] freefr> wrote:
>> Now, CLOCK_PROCESS_CPUTIME_ID is posix, so should we just hate freebsd 7.2 and
lower for
>> not having it ? (no assertion about 8.0)
> 
> Sounds like a reasonable option :P (SCNR)
> 
> I'd say it depends on how complicated it would be to fix. At any rate, it's
> worth entering into the bugtracker as a compatibility issue. As you seem to be
> into details to some degree, would you mind...? kthxbye ;)
> 
> 
> 
Entry add in bugtracker, as per request.

Post a reply to this message

On Thu, 16 Jul 2009 10:11:54 +0200 Le_Forgeron wrote:

> Le 15/07/2009 19:40, clipka nous fit lire :
>> Le_Forgeron <jgr### [at] freefr> wrote:
>>> Now, CLOCK_PROCESS_CPUTIME_ID is posix, so should we just hate freebsd
>>> 7.2 and lower for not having it ? (no assertion about 8.0)
>> 
>> Sounds like a reasonable option :P (SCNR)
>> 
>> I'd say it depends on how complicated it would be to fix. At any rate,
>> it's worth entering into the bugtracker as a compatibility issue. As
>> you seem to be into details to some degree, would you mind...? kthxbye
>> ;)
>> 
>> 
>> 
> Entry add in bugtracker, as per request.

I thank you for it ;)

Post a reply to this message

On Thu, 16 Jul 2009 10:11:54 +0200 Le_Forgeron wrote:

> Le 15/07/2009 19:40, clipka nous fit lire :
>> Le_Forgeron <jgr### [at] freefr> wrote:
>>> Now, CLOCK_PROCESS_CPUTIME_ID is posix, so should we just hate freebsd
>>> 7.2 and lower for not having it ? (no assertion about 8.0)
>> 
>> Sounds like a reasonable option :P (SCNR)
>> 
>> I'd say it depends on how complicated it would be to fix. At any rate,
>> it's worth entering into the bugtracker as a compatibility issue. As
>> you seem to be into details to some degree, would you mind...? kthxbye
>> ;)
>> 
>> 
>> 
> Entry add in bugtracker, as per request.

Povray does compile now. The patch follows. But there is another problem 
which is ugly:
[..]
Making all in libraries
Making all in source
Making all in backend
Making all in base
Making all in frontend
Making all in vfe
Making all in unix
./unix/povray +i./scenes/advanced/biscuit.pov -f +d +p +v +w320 +h240 
+a0.3 +L./include
povray: this pre-release version of POV-Ray for Unix has expired
*** Error code 1

Stop in /usr/home/user/sources/povray-3.7.0.beta.32.

How can I circumvent it?
Another question:
If Povray executes, how can I check if my patch is successful? Would 
Povray start? Would it crash? Which checks have to be done?
Thank you in advance.

---------------------------------------------------------------
Patch:

--- vfe/unix/platformbase.cpp.old	2009-07-16 21:24:30.000000000 +0200
+++ vfe/unix/platformbase.cpp	2009-07-16 21:18:36.000000000 +0200
@@ -191,7 +191,11 @@ namespace pov_base
 	{
 #ifdef HAVE_CLOCK_GETTIME
 		struct timespec ts;
+#if defined (__FreeBSD__)
+		if (clock_gettime(m_ThreadTimeOnly ? CLOCK_THREAD_CPUTIME_ID : CLOCK_REALTIME, &ts)
== 0)
+#else
 		if (clock_gettime(m_ThreadTimeOnly ? CLOCK_THREAD_CPUTIME_ID :
CLOCK_PROCESS_CPUTIME_ID, &ts) == 0)
+#endif
 			return (unsigned POV_LONG) (1000)*ts.tv_sec + ts.tv_nsec/1000000;
 #endif
 #ifdef HAVE_GETRUSAGE

Post a reply to this message

marabou <not### [at] availableyet> wrote:
> On Thu, 16 Jul 2009 10:11:54 +0200 Le_Forgeron wrote:
>
> > Le 15/07/2009 19:40, clipka nous fit lire :
> >> Le_Forgeron <jgr### [at] freefr> wrote:
> >>> Now, CLOCK_PROCESS_CPUTIME_ID is posix, so should we just hate freebsd
> >>> 7.2 and lower for not having it ? (no assertion about 8.0)
> >>
> >> Sounds like a reasonable option :P (SCNR)
> >>
> >> I'd say it depends on how complicated it would be to fix. At any rate,
> >> it's worth entering into the bugtracker as a compatibility issue. As
> >> you seem to be into details to some degree, would you mind...? kthxbye
> >> ;)
> >>
> >>
> >>
> > Entry add in bugtracker, as per request.
>
> I thank you for it ;)

Looks like Le_Forgeron not only entered the issue, but already did a thorough
analysis; I can only agree with all his conclusions: It should be a matter of
../configure identifying that CLOCK_PROCESS_CPUTIME_ID isn't available, and in
that case not setting HAVE_CLOCK_GETTIME, but HAVE_GETRUSAGE instead; as the
code seems to be well prepared for dealing with clock_gettime() being
unavailable, issues worse than possibly misleading statistics are not to be
expected.

So no need to loathe freebsd for this :)

Post a reply to this message

On Thu, 16 Jul 2009 16:06:28 -0400 clipka wrote:

> 3.0.4506.2152; .NET CLR 3.5.30729)
> NNTP-Posting-Host: 203.29.75.35
> X-Trace: news.povray.org 1247775001 203.29.75.35 (16 Jul 2009 16:10:01
> -0400) Lines: 33
> X-No-Archive: Yes
> X-Copyright: This copyrighted article comes from a private news server
> and may NOT be distributed on USENET or other news servers.
> X-POV-Header: --- --- --- --- --- --- --- --- --- --- --- --- Path:
> news.povray.org!81.173.238.87
> Xref: news.povray.org povray.beta-test:10235
> 
> marabou <not### [at] availableyet> wrote:
>> On Thu, 16 Jul 2009 10:11:54 +0200 Le_Forgeron wrote:
>>
>> > Le 15/07/2009 19:40, clipka nous fit lire :
>> >> Le_Forgeron <jgr### [at] freefr> wrote:
>> >>> Now, CLOCK_PROCESS_CPUTIME_ID is posix, so should we just hate
>> >>> freebsd 7.2 and lower for not having it ? (no assertion about 8.0)
>> >>
>> >> Sounds like a reasonable option :P (SCNR)
>> >>
>> >> I'd say it depends on how complicated it would be to fix. At any
>> >> rate, it's worth entering into the bugtracker as a compatibility
>> >> issue. As you seem to be into details to some degree, would you
>> >> mind...? kthxbye ;)
>> >>
>> >>
>> >>
>> > Entry add in bugtracker, as per request.
>>
>> I thank you for it ;)
> 
> Looks like Le_Forgeron not only entered the issue, but already did a
> thorough analysis; I can only agree with all his conclusions: It should
> be a matter of ../configure identifying that CLOCK_PROCESS_CPUTIME_ID
> isn't available, and in that case not setting HAVE_CLOCK_GETTIME, but
> HAVE_GETRUSAGE instead; as the code seems to be well prepared for
> dealing with clock_gettime() being unavailable, issues worse than
> possibly misleading statistics are not to be expected.
> 
> So no need to loathe freebsd for this :)

sorry, did you read all new posts in this thread?

Post a reply to this message

On Thu, 16 Jul 2009 15:33:38 -0400 marabou wrote:

> On Thu, 16 Jul 2009 10:11:54 +0200 Le_Forgeron wrote:
> 
>> Le 15/07/2009 19:40, clipka nous fit lire :
>>> Le_Forgeron <jgr### [at] freefr> wrote:
>>>> Now, CLOCK_PROCESS_CPUTIME_ID is posix, so should we just hate
>>>> freebsd 7.2 and lower for not having it ? (no assertion about 8.0)
>>> 
>>> Sounds like a reasonable option :P (SCNR)
>>> 
>>> I'd say it depends on how complicated it would be to fix. At any rate,
>>> it's worth entering into the bugtracker as a compatibility issue. As
>>> you seem to be into details to some degree, would you mind...? kthxbye
>>> ;)
>>> 
>>> 
>>> 
>> Entry add in bugtracker, as per request.
> 
> Povray does compile now. The patch follows. But there is another problem
> which is ugly:
> [..]
> Making all in libraries
> Making all in source
> Making all in backend
> Making all in base
> Making all in frontend
> Making all in vfe
> Making all in unix
> ./unix/povray +i./scenes/advanced/biscuit.pov -f +d +p +v +w320 +h240
> +a0.3 +L./include
> povray: this pre-release version of POV-Ray for Unix has expired ***
> Error code 1
> 
> Stop in /usr/home/user/sources/povray-3.7.0.beta.32.
> 
> How can I circumvent it?
[..]
okay, fulfilled.
Sometimes Povray dumps core, sometimes it loops forever at this position:
Making all in libraries
Making all in source
Making all in backend
Making all in base
Making all in frontend
Making all in vfe
Making all in unix
./unix/povray +i./scenes/advanced/biscuit.pov -f +d +p +v +w320 +h240 
+a0.3 +L./include
povray: this pre-release version of POV-Ray for Unix expires in 3 day(s) 
and 1 hour(s)
PATHS
  HOME        = /home/xxx
  SYSCONF     = /usr/local/etc/povray/3.7/povray.conf
  USERCONF    = /home/user/.povray/3.7/povray.conf
  SYSINI      = /usr/local/etc/povray/3.7/povray.ini
  SYSINI_OLD  = /usr/local/etc/povray.ini
  USERINI     = /home/xxx/.povray/3.7/povray.ini
  USERINI_OLD = /home/xxx/.povrayrc
PARSE CONF '/usr/local/etc/povray/3.7/povray.conf'
[still running@100% CPU time...]

There seems to be another problem.

GDB says:
#13 0x0yyyyyyy in SignalHandler () at unix/unixconsole.cpp:146
Previous frame identical to this frame (corrupt stack?)
(gdb) list 146
141		int      signum;
142	
143		while(true)
144		{
145			sigfillset(&sigset);
146			sigwait(&sigset, &signum);  // wait till a signal 
is caught
147			boost::mutex::scoped_lock lock(gSignalMutex);
148			gSignalNumber = signum;
149		}
150	}
(gdb)

Post a reply to this message

marabou <not### [at] availableyet> wrote:
> povray: this pre-release version of POV-Ray for Unix has expired
> *** Error code 1
>
> Stop in /usr/home/user/sources/povray-3.7.0.beta.32.
>
> How can I circumvent it?

From an older post:
--------------------
1) run  ./povray --betacode  to obtain a time-limited code (integer value)
2) set the environment variable POVRAY_BETA with this code
3) repeat when the current code doesn't work anymore.
--------------------
Unfortunately this information seems nowhere to be found on the official POV-Ray
beta test web pages.


> Another question:
> If Povray executes, how can I check if my patch is successful? Would
> Povray start? Would it crash? Which checks have to be done?

Just check whether the timing statistics (render time and such) seem plausible;
that's all that should be affected.

Post a reply to this message

marabou <not### [at] availableyet> wrote:
> > So no need to loathe freebsd for this :)
>
> sorry, did you read all new posts in this thread?

No, sorry - you were typing too fast ;) (I'm using the message digest on
http://news.povray.org, not a news reader, usually reading the posts on a FIFO
basis ;))

But at first glance it looks to me like we need to loathe freebsd for something
else, not the time statistics stuff.

Post a reply to this message