Uncomfirmed crash report (was Re: [OT] Computer news from Kassel)

[Wilhelm Sanke]

On Fri Jun 25, 2010, Ben Rubinstein benr_mc at cogapp.com wrote:


> On 25/06/2010 17:36, Wilhelm Sanke wrote:
>
> >  And, if someone finds out that "you can crash Rev with
> > only four lines of script" this should definitely arouse the attention
> > of the responsible members of the Rev team, irrespective whether the bug
> > report is multi-faceted or concentrated on one single sub-point. The Rev
> > team should be competent enough to deal with a number of related
> > troubles at the same time, or deal with them step by step. I believe
> > that they are basically capable to handle also complicated issues, they
> > are not first-graders in computer science.
>
> But they are busy people, who have to choose where to put their time.


So are we!. My time is equally valuable. I think the relationship 
between the Rev team and their customers, supporters, cooperators etc. 
is one of mutual acknowledgement and respect without any trace of a 
hierarchy.

I believe the unresponsiveness of the people from Rev in this case - an 
unresponsiveness which happily does not happen all the time, I indeed 
did have quite a number of normal and positive experiences - is mainly 
an organisational problem.
If you set up a bug database for Rev users, you have also to develop 
regular procedures to communicate with the sender of a bug report in a 
narrow time frame.  If there are open questions concerning a report - 
facts and arguments that may be totally clear in the mind of the sender, 
but actually need extra clarifications and additional information for 
the member of the Rev team that is assigned to the bug - then there is 
the need (and there should be the time) to contact the sender about it.
Just staying mute for 9 months, doing nothing, is not appropriate and 
helpful - and certainly counterproductive to the goals of further 
development and improvement of Revolution and establishing a good 
working relationship with its users.

>   I took
> some time to work through the bug, which is actually called "Groups: 
> Bugs and
> features ("last group" broken)?".  It refers to a way of crashing Rev, 
> but
> doesn't give enough information.  I tried, yesterday, to reproduce the 
> bug
> using the script fragment in the bug report, but without success.  
> However,
> that may be because I didn't know the definition of 'pre-PNG'. Perhaps 
> I would
> have discovered that by following the clue of "my recent post to this 
> list",
> but that was more time than I had.  I tried with a PNG, and it didn't 
> crash.


As I had stated in the bug report, the crash occurs with what I have 
called and defined as "Pre-PNGs", PNG images created inside Revolution, 
but apparently differing from PNGs created with other image tools. This 
in itself may be a bug.

I will quote here from the relevant links for the definition of Pre-PNGs 
which I had supplied in my bug report (My post to the use-revolution 
list "How to reliably crash Rev 3.5 and 4.0-dp3 with four script lines" 
of  August 26, 2009, and the introduction to stack "More about Masks"
<http://www.sanke.org/Software/MoreAboutMasksRev3.zip>):

> "Pre-PNG" images are basically those that are created or modified (as 
> to their imagedata) in Revolution and have not yet been saved as 
> external files and then been re-imported. Even if you export a 
> snapshot using "to image x as PNG" (image x being an image already 
> existing on the card), the resulting image will remain a Pre-PNG, also 
> copying and pasting the Pre-PNG to another card or stack preserves the 
> quality of the Pre-PNGs which behave differently in some respects. For 
> details see my comments in "More about Masks".
>
> From the introduction to stack "More about Masks":
>
> A final observation concerning the creation of masks inside Revolution 
> and using the "import snapshot" format:
>
> If the resulting mask image is not first saved as an external file and 
> then imported again, meaning if it remains as freshly created inside a 
> stack or was just copied from another mask-producing stack, then this 
> mask image will have a different quality, which we might call a "pre-PNG".
>
> Pre-PNGs behave somewhat differently than normal PNGs: You cannot 
> transfer its alphamask to the image-to-be-masked when the pre-PNG is 
> hidden, at least not several times with resizing. After you have 
> resized a pre-PNG during the masking process, you might find that it 
> is suddenly "empty", but it can be restored when you copy and paste it 
> (it then appears in its original size and shape).
> A workaround to overcome this problem is to store the mask in a custom 
> property of its own and then to "initialize" the mask each time before 
> it is used in the calling script:
>
> "put the CPimg of img "transition" into img "transition""
>
> But of course you can easily convert a pre-PNG to a full PNG by saving 
> the image as an external file.


There are more peculiarities of these Pre-PNGs than I have described here.


> Again, I share your frustration that reports can be left 'unconfirmed' 
> (and
> for much longer than a year - my oldest 'unconfirmed' bug report is 
> more than
> three years old, my oldest unconfirmed enhancement request more than 
> six years
> old! (and I still want it)).
>
>
> If you think that RR should be aware of this crashing bug, you would 
> do them a
> big favour by opening a report with the title you mention, with severity
> 'critical' or 'blocker' (if the latter can be justified), with the 
> version
> 4.5.0 dp3 (having verified that the bug is still reproducible in the 
> latest
> version), and with _all the information that RR need to reproduce the 
> bug in
> one place_ (and as little other information to obscure that as 
> possible).  If
> there's a particularly variety of PNG that is involved, please include 
> all the
> details needed to understand that in the bug report (as well as 
> attaching a
> sample image to the report).
>
> Ben
The crash occurs with version 4.5.0 dp3, too, like with the older versions.

I'll think about your proposal, although I believe all the information 
needed was supplied by me - maybe not in an optimal order or structure - 
but in a form sufficient to elicit at least a timely feedback.

Regards,

Wilhelm