Re: TestBed extensions
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
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
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