Make the FAHlog parsing smarter.

[GoogleCodeExporter]

More state oriented and less procedural.

One problem cropping up recently is with the SMP client log files...
sometimes due to its erratic log file writing the following line:

[16:16:26] *------------------------------*

...is not written correctly.  HFM currently keys off this line as the start
of each WU, when it is not present of corrupted the WU will fail parsing.

Original issue reported on code.google.com by harlam357 on 10 Jul 2009 at 2:57

[GoogleCodeExporter]

This also includes handling the situation better when the Project information 
is not
available.  See e-mail from ixor regarding Project 3770 that was not available 
in the
psummary.html page.

Original comment by harlam357 on 10 Jul 2009 at 3:03

[GoogleCodeExporter]

Try to capture the number of units in the upload queue... or just mark the 
clients 
as being in a "waiting to upload" state.  (Requested by weedacres)

Original comment by harlam357 on 10 Jul 2009 at 6:23

[GoogleCodeExporter]

Original comment by harlam357 on 8 Aug 2009 at 5:05

• Changed state: Started

[GoogleCodeExporter]

Significant changes in Revision 41 with the new LogLine and LogLineList classes
inside the LogReader class.  Would still like to get more of the Parsing out of 
the
LogParser class.  However, for v0.3.0 I think I'm going to let it go as is.  
Let this
version out in the wild and see how it does... plus more unit tests by me.

The start of work units is now being found by search for several key lines, 
including:

+ Processing work unit

+ Working ...

*------------------------------*

Unknown Projects should no longer be added to the benchmark collection.  The 
check
being made after each work unit parse in ClientInstance.ProcessExisting().

if (status.Equals(ClientStatus.Unknown) == false && 
parsedUnitInfo.ProjectIsUnknown
== false)

...is made before any calculations based on frame time & project (point value) 
are made.

As for the "waiting to upload" comment based on the request from weedacres, 
this is
going to wait and the request merged into the Issue regarding reading the 
queue.dat
file, as I believe it provides this information.

I'm not closing this Issue, but I am going to mark it down to Medium Priority.

Original comment by harlam357 on 26 Aug 2009 at 1:48

• Added labels: Priority-Medium
• Removed labels: Priority-High

[GoogleCodeExporter]

Marking this Fixed for Revision 61.  Much of the work parsing logs is now 
contained
within the LogReader Class and not the LogParser Class.  The LogParser Class is
responsible to taking data from the given LogLines (or unitinfo lines) and 
populate
the given UnitInfo object.

Things can still be improved, but I'll write new Issues to address these more
specific details as they arise.

Original comment by harlam357 on 14 Oct 2009 at 6:47

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by harlam357 on 19 Oct 2009 at 2:06

• Added labels: Milestone-Release0.4