On Wed, May 13, 2015 at 12:44 AM, Anil Madhavapeddy wrote:
> On 12 May 2015, at 17:58, Rudi Grinberg wrote:
>
>
>
>> I like your "only one function" idea.
>> The alternative of passing around the unique function is to have a global
>> reference containing the dispatcher function. It's the solutio
On 12 May 2015, at 17:58, Rudi Grinberg wrote:
>
>>
>> > I like your "only one function" idea.
>> > The alternative of passing around the unique function is to have a global
>> > reference containing the dispatcher function. It's the solution used by
>> > Lwt_log. It's mostly equivalent (and
> I like your "only one function" idea.
> The alternative of passing around the unique function is to have a global
> reference containing the dispatcher function. It's the solution used by
> Lwt_log. It's mostly equivalent (and it works ok in practice) but I think
> it's indeed better to pass
On 12 May 2015, at 17:04, Richard Mortier wrote:
>
>>>
>>> + within each component branch, there is a hierarchy of subordinate
>>> branches, branching each time a message appears at a lower (finer
>>> grained) debug level
>>
>> And this doesn't :)
>
> I was trying to capture the sequencing in
> On 12 May 2015, at 16:48, Drup wrote:
>
>> Agreed. I had in mind a branching structure that would include a branch per
>> component, followed by the debug levels. Other listeners could then do
>> aggregation into different views, including operations such as time-based
>> rotation and aggr
On 12 May 2015 at 17:59, Anil Madhavapeddy wrote:
>
>> On 12 May 2015, at 16:46, Richard Mortier wrote:
>>
>> + one Irmin log ("repo"?)
>> + each component has its own branch within that log
>>
>> then either
>>
>> + within each component branch, there is a linear sequence of messages
>> at diffe
> On 12 May 2015, at 16:46, Richard Mortier wrote:
>
> On 12 May 2015 at 17:30, Anil Madhavapeddy wrote:
>>> If I understand this correctly, this means that there is one branch for
>>> errors, one for warnings etc. I have some doubts about this since messages
>>> occuring in a given level may
On 12 May 2015, at 16:47, Richard Mortier wrote:
>
> On 12 May 2015 at 16:56, Anil Madhavapeddy wrote:
>> - Ban all uses of console logging from all of our protocol libraries. We
>> should *never* be logging directly to the console, as this is both a
>> denial-of-service opportunity and somet
Agreed. I had in mind a branching structure that would include a branch per
component, followed by the debug levels. Other listeners could then do
aggregation into different views, including operations such as time-based
rotation and aggregation across components. For an Irmin backend, such
On 12 May 2015 at 17:30, Anil Madhavapeddy wrote:
>> If I understand this correctly, this means that there is one branch for
>> errors, one for warnings etc. I have some doubts about this since messages
>> occuring in a given level may be due to a message occuring in another level
>> (you get a
On 12 May 2015 at 16:56, Anil Madhavapeddy wrote:
> - Ban all uses of console logging from all of our protocol libraries. We
> should *never* be logging directly to the console, as this is both a
> denial-of-service opportunity and something that is very difficult to
> aggregate and track.
>
On 12 May 2015, at 16:26, Daniel Bünzli wrote:
>
> Le mardi, 12 mai 2015 à 16:56, Anil Madhavapeddy a écrit :
>
>> - Build more complex backends over this basis. For instance, the
>> conventional "info/error/debug" one would be a layer that does the branches
>> appropriately for each type.
>
Le mardi, 12 mai 2015 à 16:56, Anil Madhavapeddy a écrit :
> - Build more complex backends over this basis. For instance, the conventional
> "info/error/debug" one would be a layer that does the branches appropriately
> for each type.
If I understand this correctly, this means that there is
> On 12 May 2015, at 10:27, Matthew Gray wrote:
>
> On Wed, May 6, 2015 at 1:58 PM, Thomas Gazagnaire
> wrote:
>
> An other point which is cruelly missing is a proper logging system - which is
> central when debugging runtime errors.
>
> Thomas, do you have any thoughts about what a proper
14 matches
Mail list logo
