Re: meetup occuring in London
On Wed, 2008-02-13 at 15:52 +1100, Robert Collins wrote: On Wed, 2008-02-13 at 12:53 +0900, Adrian Chadd wrote: I'd like to try. I think its a bit silly to hold a design and brainstorming without the squid core members able to have some sort of presence. Speaking purely for myself, I've spent the last couple of years fiddling with this stuff, researching how other applications are written and getting my head around all the various issues preventing Squid from being fast; it'd be a bit silly for us not to include that. I presume you mean 'without all the' :). This isn't intended as some sort of major design jag; it started with my saying 'another trip in March' and kinkie saying, 'lets have a meetup'. Its pretty common in other projects to have little meet ups of the folk that *can* get together as time permits. If this was a 'lets make a 1 year plan to make squid fast' big strategy meeting; then it would be silly to do it without you; and even more silly to do it without you in person. Its not, and I don't think anyone has represented as being that. It would also be silly to just sit in a room, working on bugs. Attendees can do that without meeting each-other face-to-face. If folks get together, I think they should talk about the Big Picture. They just should not make any final decisions. I agree that Adrian's couple of years of fiddling with stuff should be included via conferencing and/or some kind of summary document. The latter would be very useful at any rate, but I doubt Adrian has time to prepare a nice summary. Cheers, Alex.
Re: squid3 future directory structure
Hello, I have created the following wiki page to see if we can agree on how to define future subdirectories and what to move there. This can be a Squid 3.2 feature, I think. http://wiki.squid-cache.org/Features/SourceLayout Amos, do you want to lead this activity? I have already covered about 75 files out of 284 in src/ (not counting the differences in extensions) to bootstrap the process? Thank you, Alex.
Re: a simple formatter
On Wed, 2008-02-13 at 20:35 +0200, Tsantilas Christos wrote: Alex Rousskov wrote: On Wed, 2008-02-13 at 13:52 +1300, Amos Jeffries wrote: Or is it possible to omit the src/tools.cc src/stat.cc files from astyle until they can be cleaned manually to work better. I bet there are other files with problems. I doubt Christos verified each and every source file. I was not found other problematic files but yes it is possible that there are other problematic files too. It is very difficult to examine all the code. Looking the diffs it is possible I am loosing thinks... Did you do the whitespace-free-MD5 test we talked about before? Thank you, Alex.
Re: a simple formatter
Alex Rousskov wrote: On Wed, 2008-02-13 at 20:35 +0200, Tsantilas Christos wrote: Alex Rousskov wrote: On Wed, 2008-02-13 at 13:52 +1300, Amos Jeffries wrote: Or is it possible to omit the src/tools.cc src/stat.cc files from astyle until they can be cleaned manually to work better. I bet there are other files with problems. I doubt Christos verified each and every source file. I was not found other problematic files but yes it is possible that there are other problematic files too. It is very difficult to examine all the code. Looking the diffs it is possible I am loosing thinks... Did you do the whitespace-free-MD5 test we talked about before? No I did not. This test can not detect most of the errors astyle does. Do you think will help?
Re: meetup occuring in London
Canonical has confirmed - they are happy to host 4-5 people at the office on the 1st and 2nd. The only caveat is the air conditioning is off in the weekend. On Wed, 2008-02-13 at 09:27 -0700, Alex Rousskov wrote: On Wed, 2008-02-13 at 15:52 +1100, Robert Collins wrote: If this was a 'lets make a 1 year plan to make squid fast' big strategy meeting; then it would be silly to do it without you; and even more silly to do it without you in person. Its not, and I don't think anyone has represented as being that. It would also be silly to just sit in a room, working on bugs. Attendees can do that without meeting each-other face-to-face. If folks get together, I think they should talk about the Big Picture. They just should not make any final decisions. There are many sorts of productive activities. Large scale triage is often easier in person; pair programming can get a lot done that would take many round trips not face to face; design discussions can be made - totally true. I agree that Adrian's couple of years of fiddling with stuff should be included via conferencing and/or some kind of summary document. The latter would be very useful at any rate, but I doubt Adrian has time to prepare a nice summary. Adrian - this is a good idea, can you do some sort of summary document - basically what you'd say the biggest issues are ? :) -Rob signature.asc Description: This is a digitally signed message part
Re: squid3 future directory structure
On Thu, 2008-02-14 at 11:45 +1300, Amos Jeffries wrote: I'd prefer the filenames matching the (single!) class defined inside. Standard C++ practice for some. Sure. That means some need a Foo/FooX others just Foo/XYZ. But we can use namespaces and rename classes as needed to avoid long class names in a local context. Thanks, Alex.
Re: squid3 future directory structure
Hello, I have created the following wiki page to see if we can agree on how to define future subdirectories and what to move there. This can be a Squid 3.2 feature, I think. http://wiki.squid-cache.org/Features/SourceLayout Amos, do you want to lead this activity? I have already covered about 75 files out of 284 in src/ (not counting the differences in extensions) to bootstrap the process? Thank you, Alex. Added ICMP to your list of components. It's a clear-cut one now. As to your questions. I think: 1) Should we use squid/src/squid/ root for most sources to include header files as squid/group/file.h? This may be required for installed headers and 3rd party code using those headers. I'm undecided on this one. Lack of info to base the decision on. It will really depend on the descision of whether or not to publish the headers for external use. I am inclined towards the publishing, but not towards the squid/src/squid hack we need to do. 2) Where to put OS-compatabilities wrappers that are currently located in squid/lib and squid/include? I like them where they are. It's the extras that have been added there (guilty!) and the mixed styles of compatibility coding that are confusing things. The schema I have been working to for these is that if a system library function has been replaced or added for compat. It has a name starting with 'x' (extended!) for use in the general squid code and a header file that has: #if its-not-needed #define xFoo Foo #else // its needed! void xFoo(...); #endif That makes for slightly smaller code and clearly just an alternate version of the library call. Developers can use the xFoo knowing it has the same behaviour and pre/post-conditions as can be found anywhere online. BUT, an implementation that works better in squid. I'm sorry Duane, but the use you seem to like of adding Squid_ brings to mind more of 'completely re-written for squid, with different behaviour or usage' function. 3) Where to put 3rd party libraries that are currently located in squid/lib and squid/include? ./src/dependancies/ ?? ./dependancies/ ?? Definately split from the compat files though. 4) Can we remove Foo prefix from FOO/FooSomething.h file names? The prefix carries no additional information and is probably not required for modern compilers, especially in C++ world. I'd prefer the filenames matching the (single!) class defined inside. Standard C++ practice for some. That means some need a Foo/FooX others just Foo/XYZ. 5) Should client- and server- side files be separated? I think so. The combination is whats most confusing to me in squid at present. Identifying what file changes impact what side of the transaction. 6) Should directory names use just_small, CamelCase, or CAPS letters? I Think CamelCase like we do for files and classes, with acroynms being upper case is working. When we can make the converted and re-used legacy files from lower-only to CamelCase it will sit better than now. That said, this may impact the /usr/local/include descision. I think there is some tradition of lower-case with underscores on most OS. Amos
3.1 steps forward
I'm just checking 3.1 progress maps now that the current big patches are in. Adrian: http://wiki.squid-cache.org/Features/LogDaemon Can we add a timeline on this now please? If it requires a push THN will provide a little funding to get it for our use in 3.1. Amos
Re: squid3 future directory structure
On Thu, 2008-02-14 at 11:45 +1300, Amos Jeffries wrote: I'd prefer the filenames matching the (single!) class defined inside. Standard C++ practice for some. Sure. That means some need a Foo/FooX others just Foo/XYZ. But we can use namespaces and rename classes as needed to avoid long class names in a local context. Those would be the few that need Foo/XYZ files to match their short names then. Amos
