Re: TestBed extensions

2008-11-06 Thread Alex Rousskov
On Sun, 2008-11-02 at 16:39 +1300, Amos Jeffries wrote:
 I'm contemplating a piece of automation to help manage the more complex 
 testbed layers.
 
 A piece of code to recursively scan the code files and pull out the 
 unique dependency chains of nested #if...#endif.
 Reducing the entire codebase to its preprocessor code and performing 
 some of the minor actions as it goes.
 
  From the chain output its relatively easy to manually or otherwise 
 construct the minimal graphs of tests needed to cover all compile paths.
 
 To work cleanly it would require a standardization of the .h safety 
 wrapper defines used in squid sources. This only applies to headers 
 bundled with squid and does not affect anything else operationally.
 
 
  Proposed wrapper define format 
 
 #ifndef SQUID_PATH_FILENAME_H
 #define SQUID_PATH_FILENAME_H
...
 #endif /* SQUID_PATH_FILENAME_H */
 
 so that each .h file was wrapped with a define indicating its current 
 location in the sources.
 
 Not new, most files do this already with much variation on exact texts, 
 some do not. Just proposing it be formally adopted.

Do we want SRC in PATH? If we are moving every source file to src/ then
probably not, right?

Do we want underscores between path components? For example, 
ADAPTATIONICAP or ADAPTATION_ICAP for src/adaptation/icap/
FSDISKD or FS_DISKD for src/fs/diskd/

Adding underscores is more readable but I do not have a strong
preference so just pick whatever you think works best. 

I will dig out a script that fixes file preamble for all source files.
We can apply that once the layout has been fixed.

Thank you,

Alex.




Re: Introducing myself

2008-11-06 Thread Alex Rousskov
On Fri, 2008-10-31 at 16:05 +0100, Roland Wolters wrote:

 http://sites.inka.de/~bigred/devel/squid-filter.html
 
 The development of the filter was funded by my company. I know that today, in 
 squid 3, there are other ways to realize such a filter, but we started with 
 the 
 filter in the pre 3 times, and sticked to it.

Hi Roland,

Do you plan on migrating to the eCAP interface? It would help you to
avoid maintaining a parallel and duplicate code infrastructure for your
filters. In fact, your generally useful adaptation modules can be
distributed with Squid if they conform to the supported interfaces. This
will further decrease your maintenance overheads and increase your
company exposure.

Thank you,

Alex.
P.S. Please do not forget to send a list subscription request if you
have not already.



Re: TestBed extensions

2008-11-06 Thread Amos Jeffries
 On Sun, 2008-11-02 at 16:39 +1300, Amos Jeffries wrote:
 I'm contemplating a piece of automation to help manage the more complex
 testbed layers.

 A piece of code to recursively scan the code files and pull out the
 unique dependency chains of nested #if...#endif.
 Reducing the entire codebase to its preprocessor code and performing
 some of the minor actions as it goes.

  From the chain output its relatively easy to manually or otherwise
 construct the minimal graphs of tests needed to cover all compile paths.

 To work cleanly it would require a standardization of the .h safety
 wrapper defines used in squid sources. This only applies to headers
 bundled with squid and does not affect anything else operationally.


  Proposed wrapper define format 

 #ifndef SQUID_PATH_FILENAME_H
 #define SQUID_PATH_FILENAME_H
...
 #endif /* SQUID_PATH_FILENAME_H */

 so that each .h file was wrapped with a define indicating its current
 location in the sources.

 Not new, most files do this already with much variation on exact texts,
 some do not. Just proposing it be formally adopted.

 Do we want SRC in PATH? If we are moving every source file to src/ then
 probably not, right?

I'm undecided, but leaning toward eliding it.


 Do we want underscores between path components? For example,
   ADAPTATIONICAP or ADAPTATION_ICAP for src/adaptation/icap/
   FSDISKD or FS_DISKD for src/fs/diskd/

 Adding underscores is more readable but I do not have a strong
 preference so just pick whatever you think works best.

I'm preferring the underscores.


 I will dig out a script that fixes file preamble for all source files.
 We can apply that once the layout has been fixed.

Ah excellent. I was contemplating a long manual sweep. But scripts may be
better. If you can send it my way I'll see about integrating it after the
next SourceFormat. If its a clean conversion I don't think it matters when
its run.

Amos