[Clam-devel] some changes to CLAM's base repository

[Pau Arumi]

En/na Greg Kellum ha escrit:
> Hi all,
> 
> I'd like to check in some of the code that I've been working on, but 
> before I can do that, I need to check in some changes I made to the CLAM 
> code itself.  I've sent a patch containing the changes I've made.  It's 
> nothing drastic.  I modified the build scripts to take care of the 
> problem with PortMidi's PortTime library no longer existing.  I changed 
> the Thread class a bit by making some methods virtual and making some 
> members protected rather than private so that I could access them in a 
> subclass.  And I made some changes to the SDIF file reading code. 
> 
> Um...  I'd appreciate it if you'd let me check in this code myself after 
> you've had a chance to take a look at.  It's a pain in the ass to delete 
> all of one's local changes to get the latest repository version.

Why? Do you get conflicts? I think you should get clean
updates/merges. Maybe we have a problem with the file format. Any
clues?


Instead of this:

-		CLAM_ASSERT( res == 0 || res == ETIMEDOUT ,"SOmething strange 
has happened");
+		char errorMessage[100]; // Having to do things like this make 
you hate C.
+		sprintf(errorMessage, "Something strange has happened. PThread 
returned from timed wait with result code <%i>\n.", res);
+		CLAM_ASSERT( res == 0 || res == ETIMEDOUT , errorMessage );


Use a more C++ style like this: (I think it should go into a CLAM 
idioms wiki page)

if ( error condition )
{
   std::ostringstream os;
   os
     << "err message: "
     << "some var: " << var
     << std::flush;
   CLAM_ASSERT(false, os.str().c_str());
}




Most of the different lines in your patch seems to be related to a
different encoding of end-of-lines. This is pretty inconvenient for
working with patches. And probably related with your (I suppose)
conflicts when svn updating.
Maybe also related: I got rejections when applying your patch
against current svn.




-private:
+protected:
	virtual void SetupPriorityPolicy();

This change shouldn't be done if possible. Actually I remember
privatizing it because calling it when the thread was running
didn't work. The priority should be set up at construction time.
Are you sure you need it? (maybe sending the user code helps)




+
+	/** Copies all of the spectral peak data from the given objects
+		member arrays --
+		FreqBuffer, MagBuffer, PhaseBuffer, BinPosBuffer, BinWidthBuffer,
+		and IndexArray -- to the member arrays of this object.
+		Copies the properties Scale and MinimizeResizes too. */
+	void CopyMembers(SpectralPeakArray& sourceSpectralPeakArray);
+

Can you explain its motivation?



Ok to commit:

  SDIFFileReader
  clam_dependent_libs_checks.py
  Wav2SDIF


Cheers!
pau