Subject: Re: [geometry] Run-Time specified geometries
From: Samuel Debionne (samuel.debionne_at_[hidden])
Date: 2014-05-12 11:57:24
> As discussed with Adam, this needs to be fixed, and the policy needs to
> be more closely followed. It's not important only for what you're trying
> to do: the support status is wrong if this rule is broken. This would be
> the first thing to do.
OK, so we should assume that a dispatching based on not_implemented_tag
is reliable to implement the runtime layer and/or fix it if necessary.
How shall we handle the cases when strategies or sub-algorithms called
from a main algorithm are more restrictive than the main algorithm ? In
this case not_implemented_tag should match the intersection of the
implemented strategies or sub-algorithms...
> 3. The filtering should happend after the variant resolution that means
> rewriting all the variant code in the runtime extension. Unless a hook
> is implemented to augment this code with "runtime filtering".
> That would be another stage in the multistage dispatching I've put in
> place, or maybe directly done within the variant resolution stage.
I have chosen the second solution so far.
> 4. Maybe an extension is not a good idea and runtime support should be a
> core functionality of the library. I think so because it seems to
> require an extra requirements : the algorithms must report compile time
> errors in a specified way when invoked with not supported types not just
> rise an MPL assertion.
> To me it's completely obvious that this cannot be an extension (and
> shouldn't, conceptually). It's probably impossible to implement it in a
> non-intrusive way. It has to be implemented as a core feature.
GIL has a runtime layer on top of the core library. But maybe they don't
have to manage the extra complexity of algorithms that are not
implementable for some combination of images (color depth/channel
> Unfortunately I'm busy finishing variants work, only 1 or 2 algos left
> but I really don't have much spare time for doing any work currently.
I have just send a PR for the distance algorithm. Do you have some tests
that cover the variant part for other algorithms that I could use as an
Geometry list run by mateusz at loskot.net