expected behavior:
Parse error msg “line XXX, OPEN_TYPE missing in #fopen directive”, then stop.

observed behavior:
crash - Segfault err (core dump) in Parsing stage

minimal working example attached

#declare pavement_object = array[2]
{

object {trash_can_macro()	scale 3/4			translate -x * 1/2},
object {potted_plant_macro(_CT_rand2)	scale 3/4	scale 3/2	translate -x * 1/2}

}

This does work:

#declare trash_can_object = object {trash_can_macro()};
#declare potted_plant_object = object {potted_plant_macro(_CT_rand2)};
#declare pavement_object = array[2]
{

object {trash_can_object	scale 3/4			translate -x * 1/2},
object {potted_plant_object	scale 3/4	scale 3/2	translate -x * 1/2}

}

Logically, I cannot see a reason for this to be so.

Currently, you can use a macor to convert individual colors. But this does not work in color_maps where you want smooth gradations/interpolations between two or several colors.

It would be nice to be able to select and copy this text using this mouse. Sometimes in the newsgroup I have to tell people what version of POVray I am using, and typing the version number can be a pain.

Here is an example of Chrome downloading something and showing the progress in the taskbar:

http://www.winbeta.org/sites/default/files/news/oldfashinoned.jpg

Here is an example with Paint.NET instead:

http://www.getpaint.net/images/pdn351_superbarProgress.png

I think this feature would use fewer CPU resources than a) minimizing/maximizing the whole application window each time you want to check progress, or b) hovering the mouse over the taskbar button to show the thumbnails.

intersection
{ quadric { <1, 0, 1>, <0, 0, 0>, <0, 1, 0>, -1 }
  cylinder { 0, y, 1 }
}

However, when I extend the clipping cylinder downward:

intersection
{ quadric { <1, 0, 1>, <0, 0, 0>, <0, 1, 0>, -1 }
  cylinder { -y, y, 1 }
}

the object disappears completely in POV-Ray 3.7 and 3.7.1. In POV-Ray
3.6.1, it renders as expected.

POV-Ray 3.7.0.unofficial (self-compiled with g++ 4.8, but completely unaltered)
POV-Ray 3.7.1-alpha.8150025.unofficial
openSUSE 13.2 GNU/Linux

This scene file illustrates the problem:

// +w480 +h240
#version 3.6; //[sic]

global_settings { assumed_gamma 1 }

camera
{ location <0, 1, -7.5958>
  look_at <0, 1, 0>
  right 2 * x
  up y
  angle 43.1038
}

#default { finish { diffuse 0.6 ambient rgb 0.15618 } }

light_source
{ <-4.3125, 9.6250, -7.4695>,
  rgb 6856.3
  fade_power 2 fade_distance 0.10417
  spotlight point_at <0, 1, 0> radius 45 falloff 90
}

box
{ -<9, 11, 9>, <9, 11, 9>
  pigment { rgb 1 }
}

plane
{ y, 0
  pigment { checker rgb 0.05 rgb 1 }
}

intersection
{ quadric { <1, 0, 1>, <0, 0, 0>, <0, 1, 0>, -1 }
  cylinder { 0, y, 1 }
  pigment { green 0.5 }
  translate <-1.25, 1, 0>
}

intersection
{ quadric { <1, 0, 1>, <0, 0, 0>, <0, 1, 0>, -1 }
  cylinder { -y, y, 1 }
  pigment { green 0.5 }
  translate <1.25, 1, 0>
}

On the right side, there should have been a cylinder capped with a paraboloid. A thread has been started in povray.bugreports. Jerome has started to look at it.

[640×360, AA 0.3]
Width=640
Height=36084
Antialias=On
Antialias_Threshold=0.3

should be:

[640×360, AA 0.3]
Width=640
Height=360
Antialias=On
Antialias_Threshold=0.3

The first line of the mesh output seems to be repeated resulting in incorrect light colour values.

If the first line of the texture is skipped then the values seem to be correct.

The following command succeeds:
povray +OqXfFbD0Vg5XjZgi5sOefkvdF_oCGrZ1ChVhrQw.png +IqXfFbD0Vg5XjZgi5sOefkvdF_oCGrZ1ChVhrQw.pov +W1000 +H1000

Any option that gets a filename as parameter will fail if it contains ‘=’.

It is a regression, as it worked fine with 3.6.