ICA/Farce

DJ Lucas dj at linuxfromscratch.org
Sun Oct 26 18:45:40 PDT 2008


Greg Schafer wrote:
> DJ Lucas wrote:
>
>   
>> Hey guys.  Is there any recent documentation on the expectations of 
>> farce or ICA?
>>     
>
> Docs? What docs :-)
>
>   
>> Doing only 2 passes of chapter6 
>> with both comparison methods checked.  What are the advantages of 3 or 
>> more passes?
>>     
>
> Huh? ICA by definition is 3 passes. No ifs, buts or maybes. Any other
> number is meaningless and exposes a lack of understanding of what is being
> tested.
>   
I've never used it.  My question was based only on the options provided 
in jhalfs, which probably means that they are intended specifically for 
Farce.

Anyway, I killed the build I was working on.  Given the Ken's 
description of current Farce, I'm not sure that both can run on the same 
system and have meaningful results.  I'd really like to do a sanity 
check on the development LFS.  A positive ICA run would do us very well 
to prove that the old build method is at least still working, even 
though it is dated. 

After I take care of these last two bugs, I'll take a look at your 
current gsbuild and see if I can make it make sense to me since I 
haven't used it.  Maybe even get jhalfs updated to your current tests.  
IIRC there were also some good notes when ICA was developed in the LFS 
archives, but they are probably way outdated.  I will take the time to 
search them myself, but if you happen to run across any interesting 
threads in the DIY archives before I get to it, would you mind posting a 
link?

> I've never looked at jhalfs but I understand it implements my ICA
> algorithms. My own scripts have been getting exceptionally clean
> results lately now that the randomness in GCC builds has apparently gone
> as of GCC 4.3. I'll happily check any results you can post up.
>   
After I get a basic understanding, I'll probably take you up on that.

Thanks a million Greg.

-- DJ Lucas


-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.




More information about the lfs-dev mailing list