[codeface] Re: [PATCH 3/5] Allow mailing list analysis to run even if no vcs analysis

  • From: Wolfgang Mauerer <wolfgang.mauerer@xxxxxxxxxxxxxxxxx>
  • To: Andreas Ringlstetter <andreas.ringlstetter@xxxxxxxxxxxxxxxxxxxx>, <codeface@xxxxxxxxxxxxx>
  • Date: Fri, 6 Nov 2015 22:40:16 +0100

Am 06/11/15 um 18:20 schrieb Andreas Ringlstetter:

Removing the stop was somewhat correct, but a lot of call sites
are now
lacking defensive checks. Would all the sites calling this
function still working properly? It's not just the widgets,
but also every location accessing conf$boundaries.

And is it really a good idea, trying to fix this with a
default parameter bandaid?

For now (as no one wants to add the defensive checks), I
would actually
suggest not changing the get.cycles at all for now.

Instead just add a new predicate, checking whether there are
any ranges
at all, and make the call to get.cycles dependent as well,
still assuming non-empty result set. The predicate is pretty
sure going to be
useful in other locations as well.

hm, are you suggesting something like the following?

if (there_are_cycles()) { return(get.cycles()) } else {
what.to.do.here()? }
I was referring to the change in analysis.r where the conditional
execution was introduced by this patch. It's already quite unique in
that it expects get.cycles() to return an empty result set (and not
to fail - silently or verbose).

if (there.are.cycles()) { cycles = get.cycles(); optional = ... # Do
all the optional stuff } else { optional = none; }

For the generic case (no empty result expected, so the behavior of
get.cycles() may be undefined):

assert.true(there.are.cycles()); cycles = get.cycles();

Or just the first line standalone, when accessing some function
deriving from get.cycles() internally.

Same predicate, easy to reuse, doubles as documentation of
prerequisites.

we can either modify 25 caller sites (7 of which are reactive and
not so easy to handle) and repeat the same check for a _bug_
25 times, or introduce an optional parameter to disable the check for
1 (new) out of 25+1 cases. I strongly prefer the latter variant.

the data we store in the FS are costly to compute, and it helps
with development if we can re-use the results during debugging
sessions without having to recompute after each small change.
With the exception of a few saves bytes in the file system, what
are the advantages of removing/no creating these files?
Whats the advantage of storing this data in files and not in the
database? Respectively, what was the motivation for that, except for
"It was a standalone component once"?

until now, we didn't need the data to persist after storing the
inferred information in the database. There's no point in making the DB
more complicated than necessary for information we don't need.

I fully agree that it is expensive to compute, so it should be
stored. But what I'm wondering, is why it didn't go into the
database.

Similar for the forest generated by snatm, even though that is
already improving with the patch from
[codeface] [PATCH 3/3] Add global email analysis to database
which means less data is discarded.

When we need data, we're happy to incorporate them into the database.

Best regards, Wolfgang Mauerer

Other related posts: