Re: [base] Re: Problem in generating GAL file

[Mark W. <mwi...@ge...>]

Hey Carl,

Can you discuss the consequenes of this bug, and how the behaviour will 
change when it is fixed, for those of us running BASE in a 
"production-environment"?  I want to know what hasn't been working 
(which I may have already worked-around in our pipeline...) so that when 
we upgrade I know what surrounding code will need to be changed.

thanks!

Mark


Carl Troein wrote:

> Minghua Yao writes:
>
>> In array_print.phtml, $bsizex was initialized to 0 at line 183. The 
>> only other occasion $bsizex was assigned a value is at line 257:
>>      if($lastblock == 0) $bsizex = (int)$arr[1];
>> $lastblock was initialized to -1 at line 180. The only other occasion 
>> $lastblock was assigned a value is at line 220:
>>      $lastblock = (int)substr($head, 5);
>> Since in BioRobotics 'TAM' format, "n" in [Blockn] starts from 1, 
>> $lastblock will never be 0. So, "$bsizex = (int)$arr[1];" will never 
>> be executed. That means $bsizex will always be 0. The analysis 
>> applies to $bsizey, too.
>
>
> Definitely a bug. I wonder how it has gone unnoticed for so long. :-/
> Changing $lastblock == 0 to $bsizex == 0 (or $bsizey == 0) should
> be enough to fix, I think.
>
>> On the "View array design" screen, Block rows and Block columns are 
>> both 0. Click on "Get GenePix ArrayList (GAL) file", I got only a GAL 
>> file header.
>
>
> I think it might be a consequence of an earlier problem. The array type
> is marked as printed, but there aren't any Elements added. It's what
> I'd expect to see if an empty print map was added or the error handling
> in array_print.phtml is broken. Unless the PHP script has had a
> fatal error, it should've set the array type back to not printed if
> the print map adding failed, but there's no check for 0-element
> print maps.
> I _so_ will revise this code for 1.2.
> //Carl