<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p dir="ltr">Hi Einar,</p>
<p dir="ltr">Thanks. In addition to this patch, the only other recent one is "Fix copy and paste error in cwindowgui.C". I am not aware of any other outstanding one.</p>
<p dir="ltr">I also submitted, not as an official patch just yet but only as a " release candidate" of the GreyCstoration plugin for people to test. It works very well on my tests, but given its complexity a little more user testing would help before I submit
 it as an official patch.</p>
<p dir="ltr">I am still working on the motionblur plugin (to prevent it from crashing). While I found where the problem is (see my previous note), I cannot find why that is crushing cinelerra...</p>
<p dir="ltr">Thanks,<br>
Nicola<br>
</p>
<div class="gmail_quote">On Apr 8, 2015 1:58 AM, Einar R√ľnkaru <einarry@smail.ee> wrote:<br type="attribution">
</div>
<div class="BodyFragment">
<div class="PlainText">Hi.<br>
<br>
On Tue, Apr 7, 2015 at 11:28 PM, Nicola Ferralis <feranick@hotmail.com> wrote:<br>
> It's a matter of consistency across similar calls. My bad that it should<br>
> have been the same since the beginning.<br>
><br>
> Nicola<br>
><br>
><br>
> On 4/7/15 4:25 PM, Johannes Sixt wrote:<br>
>><br>
>> Am 07.04.2015 um 22:00 schrieb Nicola Ferralis:<br>
>>><br>
>>> Hi, I was wondering if there are any comments on this patch.<br>
>>><br>
>>> Thanks.<br>
>>> Nicola<br>
>>><br>
>>> On 3/31/15 4:52 PM, Nicola Ferralis wrote:<br>
>>>><br>
>>>> The non-zero return value of close_all in audioesound and audioalsa<br>
>>>> is not consistent with similar calls in other audio*.C and video*.C<br>
>>>> files. close_all is called upon by parent functions that then return<br>
>>>> 0 themselves. If close_all returns non-zero, there may be issues<br>
>>>> where the event is consumed within close_all. This patch sets the<br>
>>>> returns to zero.<br>
>>>><br>
>>>> This was a mistake I introduced in commit b7e5b1ae3a, based on wrong<br>
>>>> consideration of the role of close_all as an event.<br>
>><br>
>><br>
>> I don't see where the return value of close_all() is relevant. Where<br>
>> exactly is it inspected?<br>
>><br>
>> At this point, it would be much better to convert all incarnations of<br>
>> the function to void rather than fixing a small consistency error that<br>
>> has no consequence.<br>
<br>
The problem of Cinelerra is that it has not error paths. The most it<br>
does - prints error message and continues like there is no error.<br>
These paths should be created.<br>
<br>
System close function returns zero if everything is ok and not zero<br>
when an error occures. IMHO we must follow the same rule especially<br>
with hardware devices. Today there is no error detection - it is the<br>
task of future to write it. Returning result is a part of error<br>
detection path and should be kept.<br>
<br>
The patch is fine.<br>
<br>
Nicola, you have sent more than one good patches that are not dropped<br>
or applied. Can you make some inventory and apply (or drop) them?<br>
<br>
Einar<br>
_______________________________________________<br>
Cinelerra mailing list<br>
Cinelerra@lists.cinelerra-cv.org<br>
<a href="http://lists.cinelerra-cv.org/cgi-bin/mailman/listinfo/cinelerra">http://lists.cinelerra-cv.org/cgi-bin/mailman/listinfo/cinelerra</a><br>
</div>
</div>
</body>
</html>