wiki:WeeklyMinutes20120201

BIND 10 Team call

2012-02-01

Attendees

Shane
Jinmei
Jelte
Kambe
Aharen
Larissa
Michal
Jelte
Jeremy
Haikuo

Next BIND 10 Face to Face meeting

Proposal: 2012-04-23 to 2012-04-27 in Reykjavík, Iceland
Pending team discussion, conversation with Men & Mice

Usage of exceptions for expected failures (Michal)

e.g. if I have loadAndParseDataFromFile, I'm pretty sure the user will type the filename wrong from time to time.

Michal: Easier to use exceptions because of code flow, also says "not the code path I want to take".

Jinmei: I don't think I said we SHOULD NOT use exceptions. It's kind of a preference. It's not new - we can find discussions about this on the web. My preference is that in C++ I'd rather use non-exceptions for expected errors. Partially because of performance implication. Also it can be ignored if we use exceptions, and this will hit the top-level catch-all exception and that will result in server failure. It's also debatable what kind of things are more common. I basically think it is a matter of preference, so unless it causes a very strong performance penalty it is not a strong opinion of mine.

Jelte: My summary would be "it depends".

Shane: There is a meta-issue. What happens in general when this comes up in a review?

Jinmei: I don't think we can have a general guideline. It is quite subtle.

Jelte: I tend to go for "apply or explain". So you say why you chose what you chose. But again, it depends!

Doxygen's auto-\brief or explicit one? (Michal)

Michal: If you don't use \brief as the first thing in your doxygen comment, then doxygen will turn the first paragraph into a \brief description anyway. We agreed that it is better to include it so that everybody understands that this is the \brief description. I propose we include this into the style guideline.

TODO: update style guideline

Jelte: That reminds me, we had a similar point about catch () and newlines.

Like this:

} catch {...

Or like this:

} catch {...

We do 90% on the same line, so this should be in our style guideline

TODO: update style guideline

Sharing magic-number constants between python and C++ (Michal)

Michal: Sometimes there are constants that should be shared between the two languages. Having a Python wrapper just to include a constant is overkill. I was thinking perhaps if we have some of these constants, if it would be better to have some kind of simple file that would list type/name/value and both Python and C++ code would be generated from that. Currently we usually code both by hand.

Jelte: We do that if we don't have a wrapper. If we already have a wrapper it is easier to use that. I see the reason but I don't know if I like having even more generated files.

Shane: I also don't like having generated code as it increases the learning curve for the project, but also nice to avoid having to update 2 places.

Jinmei: Also helpful for naming consistency. But I also see the concerns about overgeneralization, so I'm not sure!

Shane: How much of this do we have now?

Jinmei: In some cases we access the C++ via wrappers, so not so many. My gut feeling is maybe we have 5 or 6 cases probably.

Jelte: I know of at least 1 case, but 5 or 6 is probably okay. I am also working on a ticket to add to this case. msgq command constants are done twice (for instance).

Jinmei: If someone wants to try a specific action I don't object. And see what happens.

Shane: I think that makes sense. The next time someone is working in this area and wants to make a format that solves this problem then they can propose it.

trac spam (Jinmei)

Jinmei: We've seen trac spam relatively more often in the last 2 weeks. Not in the last few days, but... I thought it's good to do something against them.

Shane: We're not using any anti-spam plugins, are we?

Jeremy: I found like 5 plugins. 4 were for adding a captcha for ticket creation/modification. 1 was for adding new users but does not work on our version of track.

Shane: Do you know if the captcha ones can be disabled?

Jeremy: These get disabled once you login.

TODO: Shane & Jeremy to find a solution for this.

C++ header file inclusion order (Jinmei)

As usual(?) we have inconsistent styles in our code:
*include standard and external library headers first:

<string> <boost/shared_ptr.hpp> <dns/message.h>

*include standard and external library headers first:

<dns/message.h> <boost/shared_ptr.hpp> <string>

Note that in some cases we need to include specific header file very first. Python.h is one such example. (and I in fact had a trouble if I didn't put it first).

Mostly a bikeshed matter, but as a consistency lover I want to have consistent style if we can agree.

Shane: We have no guidelines at all now for this?

Jinmei: Right, as far as I know.

Jeremy: I have a minor patch over 10 or 15 files for OpenBSD about ordering of headers.

Michal: I propose putting our files first, so they don't depend on any header files included before that.

Shane: Are C++ headers and the like protected against multiple inclusion?

Michal: I think most are protected.

Jinmei: In some cases (Python.h) we have to do external includes first. I see listing standard header files first.

Shane: I've always done config.h, then system headers, then project headers, but not because it is logical but just because it is how it was done.

Jinmei: BIND 9 includes standard header files first, and I think it was intentional.

Michal: I think KDE or something like that includes project header files first.

Shane: I like header files that include their own prerequisites, so I kind of like Michal's suggestion.

Jelte: Except of course for config.h and required exceptions!

Jelte: A related question: should we change stuff or just update as we go along?

Jinmei: I don't have a strong opinion. It's easy to do, but not so important. If we have time I think it is probably a good idea to do it in a single unified task.

Shane: Put this on next sprint as a code cleanup task?

generic framework for query performance improvement (Jinmei)

See: http://bind10.isc.org/ticket/1431#comment:17 (but maybe it's too early to discuss this type of thing - I've not fully thought about it yet anyway)

Jinmei: Largely speaking, the topic is how we extend the data source interface and implementation so we can transparently include hints for optimizing the processing

Jinmei: If someone is interested in this kind of thing then maybe this link will be useful.

feedback on candidate new developers? (Jinmei)

as we seem to seek new developer(s)

(https://www.isc.org/about/jobs/BIND-Software-Engineer)

I wonder whether it makes sense for existing developers to provide feedback on candidates, especially exploiting the "openness" of BIND 10. For example, someone can pick up one open ticket from trac and show how he/she would solve this with actual code.

Jinmei: Any expectations for new developers from existing developers? Perhaps we can pick out a ticket and ask people to have a look and show how they would fix it.

versioned shared object python modules (jreed)

Jeremy: Right now we use libtool to create shared objects for Python modules. It creates a non-versioned library. AFAIK the Python import cannot be used with versioned numbers. On OpenBSD it doesn't create the symlink and breaks the import.

python3.1/site-packages/bind10-20120201/foo.so
instead of python3.1/site-packages/foo.so.3.2.1

Jeremy: A lot of projects have a subdirectory with the version of the software as a directory name.

Jinmei: I think the Python interpreter assumes specific versions so we can't do anything about that.

Shane: I see no problem with using named directories.

Jeremy: The named directories is an easy task, and I haven't figured out how to create the .so file itself without version.

gprof documentation ticket for profiling tool (haikuo)

http://bind10.isc.org/ticket/1565
haikuo: gprof could not work with python module

Shane: I think we just don't collect profiling data on the Python, at least not using gprof. There may be ways to do this, but I dont' think it's that important right now.

Jinmei: Yes, we need to do a lot of things for the C++ only part of code first.

To discuss over email, ticket or daily call.

[ran out of time]

Last modified 6 years ago Last modified on Feb 3, 2012, 12:14:35 PM