[freenet-dev] Logging subsystem rewrite

[Marco Schulze]

Okay, some numbers (10min runs under NetBeans' profiler w/ logger 
classes as roots. Log.write() is sync and no lazy evaluation):

Logger and associated classes:
- Wall clock time: 726.77 ms
- CPU time: 156.35 ms

Log and associated classes:
- Wall clock time: 12550.04 ms
- CPU time: 8452.19 ms

Current branch HEAD was about 17 times (wall clock) and 54 times (CPU) 
slower in this comparison. Slowdown was not as much as I thought it 
would be, but certainly more than acceptable. I guess runtime can be 
lowered a bit with a few more tweaks (mostly by merging sequential calls 
and removing leftover isLoggable queries - quite a few of those, 
actually), but, unless someone wants to add a comment, it seems the case 
is settled.

On 25-03-2012 19:22, Marco Schulze wrote:
> Working (but incomplete) code is available @ 
> https://github.com/Heiral/fred-staging/tree/logger++

Re: [freenet-dev] Logging subsystem rewrite

[Marco Schulze]

Okay, some numbers (10min runs under NetBeans' profiler w/ logger 
classes as roots. Log.write() is sync and no lazy evaluation):


Logger and associated classes:
- Wall clock time: 726.77 ms
- CPU time: 156.35 ms

Log and associated classes:
- Wall clock time: 12550.04 ms
- CPU time: 8452.19 ms

Current branch HEAD was about 17 times (wall clock) and 54 times (CPU) 
slower in this comparison. Slowdown was not as much as I thought it 
would be, but certainly more than acceptable. I guess runtime can be 
lowered a bit with a few more tweaks (mostly by merging sequential calls 
and removing leftover isLoggable queries - quite a few of those, 
actually), but, unless someone wants to add a comment, it seems the case 
is settled.


On 25-03-2012 19:22, Marco Schulze wrote:
Working (but incomplete) code is available @ 
https://github.com/Heiral/fred-staging/tree/logger++

___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Logging subsystem rewrite

[Matthew Toseland]

On Thursday 05 Apr 2012 23:49:04 Zlatin Balevsky wrote:
> >  If your 'solution' is trading 'jar
> >  size' and 'readability' against run-time performance (for the common
> >  case assuming logNORMAL), we won't merge it. Freenet is slow enough
> >  as is.
> 
> Any patch with lazy evaluation will not cause problems in the "normal"
> case but will affect debugging Fred because turning on debug log level
> for a single class will cause all lazy parameters everywhere to be
> created.  Imagine you're trying to reproduce a rare bug and have
> turned on one or two debug statements - because of lazy evaluation
> your jvm will garbage collect much more often and you may never
> reproduce the bug.  This is valid for current generation jvms.
> 
> > Hint: your doing it wrong, the one way to make it faster and nicer is to
> >  use dependancy injection
> 
> DI is generally great but it doesn't solve the problem of "ugly
> predicate".  You're better off looking at some bytecode weaving
> techniques like aspects.  Combined with DI they can make the code very
> clean.

Whatever the interface is, the Right Way is to introduce the predicates at run 
time. (Assuming that doesn't affect debuggability and doesn't significantly 
slow loading). It may be possible to do this with the bytecode manipulation 
library provided by db4o, which it uses for optimising native queries (queries 
expressed as function(object) { return true if we want it }). On the other hand 
it's quite heavyweight, which is why we don't generally use native queries...
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Logging subsystem rewrite

[Zlatin Balevsky]

>>
>> Any patch with lazy evaluation will not cause problems in the "normal"
>> case but will affect debugging Fred because turning on debug log level
>> for a single class will cause all lazy parameters everywhere to be
>> created.

Before someone calls me out on this one I this is how you can use lazy
evaluation without garbage on hotspot jvms.  The statement becomes
getLog().log(  ) and the predicate goes in the getter.

= CallSiteJitting.java =
public class CallSiteJitting {

static interface Logger {
void log(Object ar1, Object ar2);
}

static class MuteLogger implements Logger {
public void log(Object ar1, Object ar2){}
}

static class RealLogger implements Logger {
static long sideEffect;
public void log(Object ar1, Object ar2) {
sideEffect += ar1.hashCode();
sideEffect += ar2.hashCode();
}
}

private static final Logger mute = new MuteLogger();
private static final Logger real = new RealLogger();

private static boolean once;
private static Logger getLog() {
if (!once) {
once = true;
System.out.println("real logging once");
// if you return real every time lots of
// garbage collections happen
return real;
}
return mute;
}

public static void main(String []ar) throws Exception {

for (long l = 0; l < Long.MAX_VALUE; l++) {
getLog().log(new Object(), new Object());
}

System.out.println(RealLogger.sideEffect);
}
}
= end CallSiteJitting.java

[freenet-dev] Logging subsystem rewrite

[Zlatin Balevsky]

> ?If your 'solution' is trading 'jar
> ?size' and 'readability' against run-time performance (for the common
> ?case assuming logNORMAL), we won't merge it. Freenet is slow enough
> ?as is.

Any patch with lazy evaluation will not cause problems in the "normal"
case but will affect debugging Fred because turning on debug log level
for a single class will cause all lazy parameters everywhere to be
created.  Imagine you're trying to reproduce a rare bug and have
turned on one or two debug statements - because of lazy evaluation
your jvm will garbage collect much more often and you may never
reproduce the bug.  This is valid for current generation jvms.

>
> Hint: your doing it wrong, the one way to make it faster and nicer is to
> ?use dependancy injection
>

DI is generally great but it doesn't solve the problem of "ugly
predicate".  You're better off looking at some bytecode weaving
techniques like aspects.  Combined with DI they can make the code very
clean.

Re: [freenet-dev] Logging subsystem rewrite

[Zlatin Balevsky]

>>
>> Any patch with lazy evaluation will not cause problems in the "normal"
>> case but will affect debugging Fred because turning on debug log level
>> for a single class will cause all lazy parameters everywhere to be
>> created.

Before someone calls me out on this one I this is how you can use lazy
evaluation without garbage on hotspot jvms.  The statement becomes
getLog().log(  ) and the predicate goes in the getter.

= CallSiteJitting.java =
public class CallSiteJitting {

static interface Logger {
void log(Object ar1, Object ar2);
}

static class MuteLogger implements Logger {
public void log(Object ar1, Object ar2){}
}

static class RealLogger implements Logger {
static long sideEffect;
public void log(Object ar1, Object ar2) {
sideEffect += ar1.hashCode();
sideEffect += ar2.hashCode();
}
}

private static final Logger mute = new MuteLogger();
private static final Logger real = new RealLogger();

private static boolean once;
private static Logger getLog() {
if (!once) {
once = true;
System.out.println("real logging once");
// if you return real every time lots of
// garbage collections happen
return real;
}
return mute;
}

public static void main(String []ar) throws Exception {

for (long l = 0; l < Long.MAX_VALUE; l++) {
getLog().log(new Object(), new Object());
}

System.out.println(RealLogger.sideEffect);
}
}
= end CallSiteJitting.java
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Logging subsystem rewrite

[Matthew Toseland]

On Thursday 05 Apr 2012 23:49:04 Zlatin Balevsky wrote:
> >  If your 'solution' is trading 'jar
> >  size' and 'readability' against run-time performance (for the common
> >  case assuming logNORMAL), we won't merge it. Freenet is slow enough
> >  as is.
> 
> Any patch with lazy evaluation will not cause problems in the "normal"
> case but will affect debugging Fred because turning on debug log level
> for a single class will cause all lazy parameters everywhere to be
> created.  Imagine you're trying to reproduce a rare bug and have
> turned on one or two debug statements - because of lazy evaluation
> your jvm will garbage collect much more often and you may never
> reproduce the bug.  This is valid for current generation jvms.
> 
> > Hint: your doing it wrong, the one way to make it faster and nicer is to
> >  use dependancy injection
> 
> DI is generally great but it doesn't solve the problem of "ugly
> predicate".  You're better off looking at some bytecode weaving
> techniques like aspects.  Combined with DI they can make the code very
> clean.

Whatever the interface is, the Right Way is to introduce the predicates at run 
time. (Assuming that doesn't affect debuggability and doesn't significantly 
slow loading). It may be possible to do this with the bytecode manipulation 
library provided by db4o, which it uses for optimising native queries (queries 
expressed as function(object) { return true if we want it }). On the other hand 
it's quite heavyweight, which is why we don't generally use native queries...


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Logging subsystem rewrite

[Zlatin Balevsky]

>  If your 'solution' is trading 'jar
>  size' and 'readability' against run-time performance (for the common
>  case assuming logNORMAL), we won't merge it. Freenet is slow enough
>  as is.

Any patch with lazy evaluation will not cause problems in the "normal"
case but will affect debugging Fred because turning on debug log level
for a single class will cause all lazy parameters everywhere to be
created.  Imagine you're trying to reproduce a rare bug and have
turned on one or two debug statements - because of lazy evaluation
your jvm will garbage collect much more often and you may never
reproduce the bug.  This is valid for current generation jvms.

>
> Hint: your doing it wrong, the one way to make it faster and nicer is to
>  use dependancy injection
>

DI is generally great but it doesn't solve the problem of "ugly
predicate".  You're better off looking at some bytecode weaving
techniques like aspects.  Combined with DI they can make the code very
clean.
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Logging subsystem rewrite

[Matthew Toseland]

On Wednesday 04 Apr 2012 22:39:21 Matthew Toseland wrote:
> On Wednesday 04 Apr 2012 20:31:42 Florent Daigniere wrote:
> > On Wed, Apr 04, 2012 at 12:58:55PM -0300, Marco Schulze wrote:
> > > On 04-04-2012 11:43, Zlatin Balevsky wrote:
> > >>
> > >> The problem of abusing the predicate by performing anything other than  
> > >> logging inside it.
> > >>
> > > I guess that that does improve readability a bit. However, less than 5%  
> > > of the ifs guards anything but Log.*() calls.
> > >
> > >> You cannot get rid of the predicate without introducing side effects  
> > >> as I've demonstrated throughout this thread.
> > >>
> > > By removing the predicate and delegating checks to the logging function,  
> > > a _lot_ of boilerplate code is removed. Ideally, as toad said, Java  
> > > would have some kind macro system enabling the best of both worlds.  
> > > Lacking that, the question becomes: 'is the overhead acceptable?'.
> > >
> > > There have been quite a lot of arguments thrown here. In the end,  
> > > though, as fred is big and complex, the only answer is to write some  
> > > code and actually run the thing. Are varargs bad? Sure. Is the slowdown  
> > > unacceptable? No idea. Just bear with my slowness (or do help), and  
> > > you'll at least have a convincing argument for the next fool in the line.
> > >
> > 
> > You're the one who should try to convince us to merge your jumbo patch...
> > 
> > If your proposed solution is not faster than the existing code, you'd
> >  better come up with a solid and representative benchmark showing that
> >  the difference is not significant. If your 'solution' is trading 'jar
> >  size' and 'readability' against run-time performance (for the common
> >  case assuming logNORMAL), we won't merge it. Freenet is slow enough
> >  as is.
> > 
> > Hint: your doing it wrong, the one way to make it faster and nicer is to
> >  use dependancy injection
> 
> You mean patching the bytecode at load time? That's an interesting idea, 
> what's the overhead likely to look like?
> 
I think db4o includes a library for doing such things ... so we may not even 
need any new dependancies for it.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Logging subsystem rewrite

[Matthew Toseland]

On Wednesday 04 Apr 2012 20:31:42 Florent Daigniere wrote:
> On Wed, Apr 04, 2012 at 12:58:55PM -0300, Marco Schulze wrote:
> > On 04-04-2012 11:43, Zlatin Balevsky wrote:
> >>
> >> The problem of abusing the predicate by performing anything other than  
> >> logging inside it.
> >>
> > I guess that that does improve readability a bit. However, less than 5%  
> > of the ifs guards anything but Log.*() calls.
> >
> >> You cannot get rid of the predicate without introducing side effects  
> >> as I've demonstrated throughout this thread.
> >>
> > By removing the predicate and delegating checks to the logging function,  
> > a _lot_ of boilerplate code is removed. Ideally, as toad said, Java  
> > would have some kind macro system enabling the best of both worlds.  
> > Lacking that, the question becomes: 'is the overhead acceptable?'.
> >
> > There have been quite a lot of arguments thrown here. In the end,  
> > though, as fred is big and complex, the only answer is to write some  
> > code and actually run the thing. Are varargs bad? Sure. Is the slowdown  
> > unacceptable? No idea. Just bear with my slowness (or do help), and  
> > you'll at least have a convincing argument for the next fool in the line.
> >
> 
> You're the one who should try to convince us to merge your jumbo patch...
> 
> If your proposed solution is not faster than the existing code, you'd
>  better come up with a solid and representative benchmark showing that
>  the difference is not significant. If your 'solution' is trading 'jar
>  size' and 'readability' against run-time performance (for the common
>  case assuming logNORMAL), we won't merge it. Freenet is slow enough
>  as is.
> 
> Hint: your doing it wrong, the one way to make it faster and nicer is to
>  use dependancy injection

You mean patching the bytecode at load time? That's an interesting idea, what's 
the overhead likely to look like?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Logging subsystem rewrite

[Florent Daigniere]

On Wed, Apr 04, 2012 at 12:58:55PM -0300, Marco Schulze wrote:
> On 04-04-2012 11:43, Zlatin Balevsky wrote:
>>
>> The problem of abusing the predicate by performing anything other than  
>> logging inside it.
>>
> I guess that that does improve readability a bit. However, less than 5%  
> of the ifs guards anything but Log.*() calls.
>
>> You cannot get rid of the predicate without introducing side effects  
>> as I've demonstrated throughout this thread.
>>
> By removing the predicate and delegating checks to the logging function,  
> a _lot_ of boilerplate code is removed. Ideally, as toad said, Java  
> would have some kind macro system enabling the best of both worlds.  
> Lacking that, the question becomes: 'is the overhead acceptable?'.
>
> There have been quite a lot of arguments thrown here. In the end,  
> though, as fred is big and complex, the only answer is to write some  
> code and actually run the thing. Are varargs bad? Sure. Is the slowdown  
> unacceptable? No idea. Just bear with my slowness (or do help), and  
> you'll at least have a convincing argument for the next fool in the line.
>

You're the one who should try to convince us to merge your jumbo patch...

If your proposed solution is not faster than the existing code, you'd
 better come up with a solid and representative benchmark showing that
 the difference is not significant. If your 'solution' is trading 'jar
 size' and 'readability' against run-time performance (for the common
 case assuming logNORMAL), we won't merge it. Freenet is slow enough
 as is.

Hint: your doing it wrong, the one way to make it faster and nicer is to
 use dependancy injection

Florent

[freenet-dev] Logging subsystem rewrite

[Marco Schulze]

My English must be failing me, but I've stressed quite a few times both 
possibilities (way slower vs. acceptably slower), and how far current 
changes are from a testable state. Merging is a very distant possibility.

Regarding dependency injection, I take you mean dynamically replacing 
the Logger, and associated classes? That wouldn't be a representative of 
the final benchmark since there's no lazy evaluation.

On 04-04-2012 16:31, Florent Daigniere wrote:
> On Wed, Apr 04, 2012 at 12:58:55PM -0300, Marco Schulze wrote:
>> On 04-04-2012 11:43, Zlatin Balevsky wrote:
>>> The problem of abusing the predicate by performing anything other than
>>> logging inside it.
>>>
>> I guess that that does improve readability a bit. However, less than 5%
>> of the ifs guards anything but Log.*() calls.
>>
>>> You cannot get rid of the predicate without introducing side effects
>>> as I've demonstrated throughout this thread.
>>>
>> By removing the predicate and delegating checks to the logging function,
>> a _lot_ of boilerplate code is removed. Ideally, as toad said, Java
>> would have some kind macro system enabling the best of both worlds.
>> Lacking that, the question becomes: 'is the overhead acceptable?'.
>>
>> There have been quite a lot of arguments thrown here. In the end,
>> though, as fred is big and complex, the only answer is to write some
>> code and actually run the thing. Are varargs bad? Sure. Is the slowdown
>> unacceptable? No idea. Just bear with my slowness (or do help), and
>> you'll at least have a convincing argument for the next fool in the line.
>>
> You're the one who should try to convince us to merge your jumbo patch...
>
> If your proposed solution is not faster than the existing code, you'd
>   better come up with a solid and representative benchmark showing that
>   the difference is not significant. If your 'solution' is trading 'jar
>   size' and 'readability' against run-time performance (for the common
>   case assuming logNORMAL), we won't merge it. Freenet is slow enough
>   as is.
>
> Hint: your doing it wrong, the one way to make it faster and nicer is to
>   use dependancy injection
>
> Florent
> ___
> Devl mailing list
> Devl at freenetproject.org
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Logging subsystem rewrite

[Matthew Toseland]

On Wednesday 04 Apr 2012 22:39:21 Matthew Toseland wrote:
> On Wednesday 04 Apr 2012 20:31:42 Florent Daigniere wrote:
> > On Wed, Apr 04, 2012 at 12:58:55PM -0300, Marco Schulze wrote:
> > > On 04-04-2012 11:43, Zlatin Balevsky wrote:
> > >>
> > >> The problem of abusing the predicate by performing anything other than  
> > >> logging inside it.
> > >>
> > > I guess that that does improve readability a bit. However, less than 5%  
> > > of the ifs guards anything but Log.*() calls.
> > >
> > >> You cannot get rid of the predicate without introducing side effects  
> > >> as I've demonstrated throughout this thread.
> > >>
> > > By removing the predicate and delegating checks to the logging function,  
> > > a _lot_ of boilerplate code is removed. Ideally, as toad said, Java  
> > > would have some kind macro system enabling the best of both worlds.  
> > > Lacking that, the question becomes: 'is the overhead acceptable?'.
> > >
> > > There have been quite a lot of arguments thrown here. In the end,  
> > > though, as fred is big and complex, the only answer is to write some  
> > > code and actually run the thing. Are varargs bad? Sure. Is the slowdown  
> > > unacceptable? No idea. Just bear with my slowness (or do help), and  
> > > you'll at least have a convincing argument for the next fool in the line.
> > >
> > 
> > You're the one who should try to convince us to merge your jumbo patch...
> > 
> > If your proposed solution is not faster than the existing code, you'd
> >  better come up with a solid and representative benchmark showing that
> >  the difference is not significant. If your 'solution' is trading 'jar
> >  size' and 'readability' against run-time performance (for the common
> >  case assuming logNORMAL), we won't merge it. Freenet is slow enough
> >  as is.
> > 
> > Hint: your doing it wrong, the one way to make it faster and nicer is to
> >  use dependancy injection
> 
> You mean patching the bytecode at load time? That's an interesting idea, 
> what's the overhead likely to look like?
> 
I think db4o includes a library for doing such things ... so we may not even 
need any new dependancies for it.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Logging subsystem rewrite

[Matthew Toseland]

On Wednesday 04 Apr 2012 20:31:42 Florent Daigniere wrote:
> On Wed, Apr 04, 2012 at 12:58:55PM -0300, Marco Schulze wrote:
> > On 04-04-2012 11:43, Zlatin Balevsky wrote:
> >>
> >> The problem of abusing the predicate by performing anything other than  
> >> logging inside it.
> >>
> > I guess that that does improve readability a bit. However, less than 5%  
> > of the ifs guards anything but Log.*() calls.
> >
> >> You cannot get rid of the predicate without introducing side effects  
> >> as I've demonstrated throughout this thread.
> >>
> > By removing the predicate and delegating checks to the logging function,  
> > a _lot_ of boilerplate code is removed. Ideally, as toad said, Java  
> > would have some kind macro system enabling the best of both worlds.  
> > Lacking that, the question becomes: 'is the overhead acceptable?'.
> >
> > There have been quite a lot of arguments thrown here. In the end,  
> > though, as fred is big and complex, the only answer is to write some  
> > code and actually run the thing. Are varargs bad? Sure. Is the slowdown  
> > unacceptable? No idea. Just bear with my slowness (or do help), and  
> > you'll at least have a convincing argument for the next fool in the line.
> >
> 
> You're the one who should try to convince us to merge your jumbo patch...
> 
> If your proposed solution is not faster than the existing code, you'd
>  better come up with a solid and representative benchmark showing that
>  the difference is not significant. If your 'solution' is trading 'jar
>  size' and 'readability' against run-time performance (for the common
>  case assuming logNORMAL), we won't merge it. Freenet is slow enough
>  as is.
> 
> Hint: your doing it wrong, the one way to make it faster and nicer is to
>  use dependancy injection

You mean patching the bytecode at load time? That's an interesting idea, what's 
the overhead likely to look like?


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Logging subsystem rewrite

[Marco Schulze]

My English must be failing me, but I've stressed quite a few times both 
possibilities (way slower vs. acceptably slower), and how far current 
changes are from a testable state. Merging is a very distant possibility.


Regarding dependency injection, I take you mean dynamically replacing 
the Logger, and associated classes? That wouldn't be a representative of 
the final benchmark since there's no lazy evaluation.


On 04-04-2012 16:31, Florent Daigniere wrote:

On Wed, Apr 04, 2012 at 12:58:55PM -0300, Marco Schulze wrote:

On 04-04-2012 11:43, Zlatin Balevsky wrote:

The problem of abusing the predicate by performing anything other than
logging inside it.


I guess that that does improve readability a bit. However, less than 5%
of the ifs guards anything but Log.*() calls.


You cannot get rid of the predicate without introducing side effects
as I've demonstrated throughout this thread.


By removing the predicate and delegating checks to the logging function,
a _lot_ of boilerplate code is removed. Ideally, as toad said, Java
would have some kind macro system enabling the best of both worlds.
Lacking that, the question becomes: 'is the overhead acceptable?'.

There have been quite a lot of arguments thrown here. In the end,
though, as fred is big and complex, the only answer is to write some
code and actually run the thing. Are varargs bad? Sure. Is the slowdown
unacceptable? No idea. Just bear with my slowness (or do help), and
you'll at least have a convincing argument for the next fool in the line.


You're the one who should try to convince us to merge your jumbo patch...

If your proposed solution is not faster than the existing code, you'd
  better come up with a solid and representative benchmark showing that
  the difference is not significant. If your 'solution' is trading 'jar
  size' and 'readability' against run-time performance (for the common
  case assuming logNORMAL), we won't merge it. Freenet is slow enough
  as is.

Hint: your doing it wrong, the one way to make it faster and nicer is to
  use dependancy injection

Florent
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Logging subsystem rewrite

[Marco Schulze]

On 04-04-2012 11:43, Zlatin Balevsky wrote:
>
> The problem of abusing the predicate by performing anything other than 
> logging inside it.
>
I guess that that does improve readability a bit. However, less than 5% 
of the ifs guards anything but Log.*() calls.

> You cannot get rid of the predicate without introducing side effects 
> as I've demonstrated throughout this thread.
>
By removing the predicate and delegating checks to the logging function, 
a _lot_ of boilerplate code is removed. Ideally, as toad said, Java 
would have some kind macro system enabling the best of both worlds. 
Lacking that, the question becomes: 'is the overhead acceptable?'.

There have been quite a lot of arguments thrown here. In the end, 
though, as fred is big and complex, the only answer is to write some 
code and actually run the thing. Are varargs bad? Sure. Is the slowdown 
unacceptable? No idea. Just bear with my slowness (or do help), and 
you'll at least have a convincing argument for the next fool in the line.

> On Apr 4, 2012 6:01 AM, "Marco Schulze"  > wrote:
>
> Which problem is solved? There's still a predicate there.
>
> On 03-04-2012 20:49, Zlatin Balevsky wrote:
>
> May I suggest a nice little script someone ( novice? ) could
> write,
> solve the logging problem and learning a thing or two about
> language
> theory in the process :
>
> Transform:
> 
> if (LOG.isLoggable(Level.DEBUG)) {
> 
> 
> }
> 
> Into
> 
> private static void logComplexComputation( .. arguments! .. ) {
> <  do the stuff above>
> }
>
> if (LOG.isLoggable(Level.DEBUG)) {
> logComplexComputation( .. arguments ..);
> }
> 
>
> This gets run as pre-commit hook and the problem is solved with
> positive run-time side effects.
>
>
> On Sun, Mar 25, 2012 at 6:22 PM, Marco Schulze
> mailto:marco.c.schulze at gmail.com>>
>  wrote:
>
> Working (but incomplete) code is available @
> https://github.com/Heiral/fred-staging/tree/logger++
> ___
> Devl mailing list
> Devl at freenetproject.org 
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>
> ___
> Devl mailing list
> Devl at freenetproject.org 
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>
> ___
> Devl mailing list
> Devl at freenetproject.org 
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>
>
>
> ___
> Devl mailing list
> Devl at freenetproject.org
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
-- next part --
An HTML attachment was scrubbed...
URL: 

Re: [freenet-dev] Logging subsystem rewrite

[Florent Daigniere]

On Wed, Apr 04, 2012 at 12:58:55PM -0300, Marco Schulze wrote:
> On 04-04-2012 11:43, Zlatin Balevsky wrote:
>>
>> The problem of abusing the predicate by performing anything other than  
>> logging inside it.
>>
> I guess that that does improve readability a bit. However, less than 5%  
> of the ifs guards anything but Log.*() calls.
>
>> You cannot get rid of the predicate without introducing side effects  
>> as I've demonstrated throughout this thread.
>>
> By removing the predicate and delegating checks to the logging function,  
> a _lot_ of boilerplate code is removed. Ideally, as toad said, Java  
> would have some kind macro system enabling the best of both worlds.  
> Lacking that, the question becomes: 'is the overhead acceptable?'.
>
> There have been quite a lot of arguments thrown here. In the end,  
> though, as fred is big and complex, the only answer is to write some  
> code and actually run the thing. Are varargs bad? Sure. Is the slowdown  
> unacceptable? No idea. Just bear with my slowness (or do help), and  
> you'll at least have a convincing argument for the next fool in the line.
>

You're the one who should try to convince us to merge your jumbo patch...

If your proposed solution is not faster than the existing code, you'd
 better come up with a solid and representative benchmark showing that
 the difference is not significant. If your 'solution' is trading 'jar
 size' and 'readability' against run-time performance (for the common
 case assuming logNORMAL), we won't merge it. Freenet is slow enough
 as is.

Hint: your doing it wrong, the one way to make it faster and nicer is to
 use dependancy injection

Florent
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Logging subsystem rewrite

[Zlatin Balevsky]

The problem of abusing the predicate by performing anything other than
logging inside it.

You cannot get rid of the predicate without introducing side effects as
I've demonstrated throughout this thread.
On Apr 4, 2012 6:01 AM, "Marco Schulze"  wrote:

> Which problem is solved? There's still a predicate there.
>
> On 03-04-2012 20:49, Zlatin Balevsky wrote:
>
>> May I suggest a nice little script someone ( novice? ) could write,
>> solve the logging problem and learning a thing or two about language
>> theory in the process :
>>
>> Transform:
>> 
>> if (LOG.isLoggable(Level.DEBUG)) {
>>   
>>   
>> }
>> 
>> Into
>> 
>> private static void logComplexComputation( .. arguments! .. ) {
>><  do the stuff above>
>> }
>>
>> if (LOG.isLoggable(Level.DEBUG)) {
>> logComplexComputation( .. arguments ..);
>> }
>> 
>>
>> This gets run as pre-commit hook and the problem is solved with
>> positive run-time side effects.
>>
>>
>> On Sun, Mar 25, 2012 at 6:22 PM, Marco Schulze
>>   wrote:
>>
>>> Working (but incomplete) code is available @
>>> https://github.com/Heiral/**fred-staging/tree/logger++
>>> __**_
>>> Devl mailing list
>>> Devl at freenetproject.org
>>> https://emu.freenetproject.**org/cgi-bin/mailman/listinfo/**devl
>>>
>> __**_
>> Devl mailing list
>> Devl at freenetproject.org
>> https://emu.freenetproject.**org/cgi-bin/mailman/listinfo/**devl
>>
> __**_
> Devl mailing list
> Devl at freenetproject.org
> https://emu.freenetproject.**org/cgi-bin/mailman/listinfo/**devl
>
-- next part --
An HTML attachment was scrubbed...
URL: 

Re: [freenet-dev] Logging subsystem rewrite

[Marco Schulze]

On 04-04-2012 11:43, Zlatin Balevsky wrote:


The problem of abusing the predicate by performing anything other than 
logging inside it.


I guess that that does improve readability a bit. However, less than 5% 
of the ifs guards anything but Log.*() calls.


You cannot get rid of the predicate without introducing side effects 
as I've demonstrated throughout this thread.


By removing the predicate and delegating checks to the logging function, 
a _lot_ of boilerplate code is removed. Ideally, as toad said, Java 
would have some kind macro system enabling the best of both worlds. 
Lacking that, the question becomes: 'is the overhead acceptable?'.


There have been quite a lot of arguments thrown here. In the end, 
though, as fred is big and complex, the only answer is to write some 
code and actually run the thing. Are varargs bad? Sure. Is the slowdown 
unacceptable? No idea. Just bear with my slowness (or do help), and 
you'll at least have a convincing argument for the next fool in the line.


On Apr 4, 2012 6:01 AM, "Marco Schulze" > wrote:


Which problem is solved? There's still a predicate there.

On 03-04-2012 20:49, Zlatin Balevsky wrote:

May I suggest a nice little script someone ( novice? ) could
write,
solve the logging problem and learning a thing or two about
language
theory in the process :

Transform:

if (LOG.isLoggable(Level.DEBUG)) {


}

Into

private static void logComplexComputation( .. arguments! .. ) {
<  do the stuff above>
}

if (LOG.isLoggable(Level.DEBUG)) {
logComplexComputation( .. arguments ..);
}


This gets run as pre-commit hook and the problem is solved with
positive run-time side effects.


On Sun, Mar 25, 2012 at 6:22 PM, Marco Schulze
mailto:marco.c.schu...@gmail.com>>
 wrote:

Working (but incomplete) code is available @
https://github.com/Heiral/fred-staging/tree/logger++
___
Devl mailing list
Devl@freenetproject.org 
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

___
Devl mailing list
Devl@freenetproject.org 
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

___
Devl mailing list
Devl@freenetproject.org 
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl



___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Logging subsystem rewrite

[Zlatin Balevsky]

The problem of abusing the predicate by performing anything other than
logging inside it.

You cannot get rid of the predicate without introducing side effects as
I've demonstrated throughout this thread.
On Apr 4, 2012 6:01 AM, "Marco Schulze"  wrote:

> Which problem is solved? There's still a predicate there.
>
> On 03-04-2012 20:49, Zlatin Balevsky wrote:
>
>> May I suggest a nice little script someone ( novice? ) could write,
>> solve the logging problem and learning a thing or two about language
>> theory in the process :
>>
>> Transform:
>> 
>> if (LOG.isLoggable(Level.DEBUG)) {
>>   
>>   
>> }
>> 
>> Into
>> 
>> private static void logComplexComputation( .. arguments! .. ) {
>><  do the stuff above>
>> }
>>
>> if (LOG.isLoggable(Level.DEBUG)) {
>> logComplexComputation( .. arguments ..);
>> }
>> 
>>
>> This gets run as pre-commit hook and the problem is solved with
>> positive run-time side effects.
>>
>>
>> On Sun, Mar 25, 2012 at 6:22 PM, Marco Schulze
>>   wrote:
>>
>>> Working (but incomplete) code is available @
>>> https://github.com/Heiral/**fred-staging/tree/logger++
>>> __**_
>>> Devl mailing list
>>> Devl@freenetproject.org
>>> https://emu.freenetproject.**org/cgi-bin/mailman/listinfo/**devl
>>>
>> __**_
>> Devl mailing list
>> Devl@freenetproject.org
>> https://emu.freenetproject.**org/cgi-bin/mailman/listinfo/**devl
>>
> __**_
> Devl mailing list
> Devl@freenetproject.org
> https://emu.freenetproject.**org/cgi-bin/mailman/listinfo/**devl
>
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Logging subsystem rewrite

[Marco Schulze]

Which problem is solved? There's still a predicate there.

On 03-04-2012 20:49, Zlatin Balevsky wrote:
> May I suggest a nice little script someone ( novice? ) could write,
> solve the logging problem and learning a thing or two about language
> theory in the process :
>
> Transform:
> 
> if (LOG.isLoggable(Level.DEBUG)) {
>
>
> }
> 
> Into
> 
> private static void logComplexComputation( .. arguments! .. ) {
> <  do the stuff above>
> }
>
> if (LOG.isLoggable(Level.DEBUG)) {
>  logComplexComputation( .. arguments ..);
> }
> 
>
> This gets run as pre-commit hook and the problem is solved with
> positive run-time side effects.
>
>
> On Sun, Mar 25, 2012 at 6:22 PM, Marco Schulze
>   wrote:
>> Working (but incomplete) code is available @
>> https://github.com/Heiral/fred-staging/tree/logger++
>> ___
>> Devl mailing list
>> Devl at freenetproject.org
>> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
> ___
> Devl mailing list
> Devl at freenetproject.org
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Logging subsystem rewrite

[Marco Schulze]

Which problem is solved? There's still a predicate there.

On 03-04-2012 20:49, Zlatin Balevsky wrote:

May I suggest a nice little script someone ( novice? ) could write,
solve the logging problem and learning a thing or two about language
theory in the process :

Transform:

if (LOG.isLoggable(Level.DEBUG)) {
   
   
}

Into

private static void logComplexComputation( .. arguments! .. ) {
<  do the stuff above>
}

if (LOG.isLoggable(Level.DEBUG)) {
 logComplexComputation( .. arguments ..);
}


This gets run as pre-commit hook and the problem is solved with
positive run-time side effects.


On Sun, Mar 25, 2012 at 6:22 PM, Marco Schulze
  wrote:

Working (but incomplete) code is available @
https://github.com/Heiral/fred-staging/tree/logger++
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Logging subsystem rewrite

[Zlatin Balevsky]

May I suggest a nice little script someone ( novice? ) could write,
solve the logging problem and learning a thing or two about language
theory in the process :

Transform:

if (LOG.isLoggable(Level.DEBUG)) {
  
  
}

Into

private static void logComplexComputation( .. arguments! .. ) {
   < do the stuff above>
}

if (LOG.isLoggable(Level.DEBUG)) {
logComplexComputation( .. arguments ..);
}


This gets run as pre-commit hook and the problem is solved with
positive run-time side effects.


On Sun, Mar 25, 2012 at 6:22 PM, Marco Schulze
 wrote:
> Working (but incomplete) code is available @
> https://github.com/Heiral/fred-staging/tree/logger++
> ___
> Devl mailing list
> Devl at freenetproject.org
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Logging subsystem rewrite

[Zlatin Balevsky]

May I suggest a nice little script someone ( novice? ) could write,
solve the logging problem and learning a thing or two about language
theory in the process :

Transform:

if (LOG.isLoggable(Level.DEBUG)) {
  
  
}

Into

private static void logComplexComputation( .. arguments! .. ) {
   < do the stuff above>
}

if (LOG.isLoggable(Level.DEBUG)) {
logComplexComputation( .. arguments ..);
}


This gets run as pre-commit hook and the problem is solved with
positive run-time side effects.


On Sun, Mar 25, 2012 at 6:22 PM, Marco Schulze
 wrote:
> Working (but incomplete) code is available @
> https://github.com/Heiral/fred-staging/tree/logger++
> ___
> Devl mailing list
> Devl@freenetproject.org
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Logging subsystem rewrite

[Matthew Toseland]

On Friday 30 Mar 2012 22:28:09 Marco Schulze wrote:
> On 30-03-2012 13:28, Matthew Toseland wrote:
> > On Sunday 25 Mar 2012 23:22:24 Marco Schulze wrote:
> >> Working (but incomplete) code is available @
> >> https://github.com/Heiral/fred-staging/tree/logger++
> > I'm keeping out of this for now, it should go in if it:
> > - Simplifies the code.
> Testing is centralized inside Log.isLoggable() and Log.write(). No 
> callbacks or registering is needed, and mistakes in current code is 
> mitigated (i.e. testing for one log level, and actually logging in 
> another). IMHO, cutting ~5000 lines from the code, and ~200k from the 
> jar speaks for itself.
> 
> > - Does not significantly reduce performance.
> Until fred actually uses lazy toString() in log calls, that'll be 
> unknown. Lazyness already works, though.
> 
> > - Does not significantly reduce debuggability (i.e. we need to be able to 
> > use wildcards).
> In to do list.
> 
> > - Reacts quickly enough (~1 second) to config changes.
> All but adding per-class filtering should be quick enough.
> 
> > - Does not create a locking hotspot.
> Only the OutputStream is locked. Mitigated by possible async option.

Async is essential, otherwise you have the mother of all lock contention 
problems: if you don't buffer it, a system call; if you do buffer it, best case 
is lock contention, worst case is a system call.

So AFAICS we need to keep most of the current FileLoggerHook. :|
> >
> > Haven't reviewed the code yet.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Logging subsystem rewrite

[Matthew Toseland]

On Saturday 31 Mar 2012 03:53:09 Zlatin Balevsky wrote:
> >
> > But we use a static logging API anyway, and this works adequately well. I 
> > have debugged stuff largely through logs in multi-node simulators, I 
> > generally rely on the thread name to identify the node (e.g. the UDP 
> > receive and send thread include the port number in the thread name).
> >
> 
> It could become an issue when trying to reproduce rare concurrency
> bugs that require running tests in a loop until they fail.  The
> smaller the synchronization overhead of the logging subsystem, the
> less noise you introduce in the simulation as you increase
> parallelism.  It also runs faster and you reproduce the bug sooner.

Yes, I have already pointed out why we log millisecond precision datestamps, 
and why it doesn't make sense to actually write to the log on the thread 
creating the log line.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

Re: [freenet-dev] Logging subsystem rewrite

[Matthew Toseland]

On Friday 30 Mar 2012 22:28:09 Marco Schulze wrote:
> On 30-03-2012 13:28, Matthew Toseland wrote:
> > On Sunday 25 Mar 2012 23:22:24 Marco Schulze wrote:
> >> Working (but incomplete) code is available @
> >> https://github.com/Heiral/fred-staging/tree/logger++
> > I'm keeping out of this for now, it should go in if it:
> > - Simplifies the code.
> Testing is centralized inside Log.isLoggable() and Log.write(). No 
> callbacks or registering is needed, and mistakes in current code is 
> mitigated (i.e. testing for one log level, and actually logging in 
> another). IMHO, cutting ~5000 lines from the code, and ~200k from the 
> jar speaks for itself.
> 
> > - Does not significantly reduce performance.
> Until fred actually uses lazy toString() in log calls, that'll be 
> unknown. Lazyness already works, though.
> 
> > - Does not significantly reduce debuggability (i.e. we need to be able to 
> > use wildcards).
> In to do list.
> 
> > - Reacts quickly enough (~1 second) to config changes.
> All but adding per-class filtering should be quick enough.
> 
> > - Does not create a locking hotspot.
> Only the OutputStream is locked. Mitigated by possible async option.

Async is essential, otherwise you have the mother of all lock contention 
problems: if you don't buffer it, a system call; if you do buffer it, best case 
is lock contention, worst case is a system call.

So AFAICS we need to keep most of the current FileLoggerHook. :|
> >
> > Haven't reviewed the code yet.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Logging subsystem rewrite

[Matthew Toseland]

On Saturday 31 Mar 2012 03:53:09 Zlatin Balevsky wrote:
> >
> > But we use a static logging API anyway, and this works adequately well. I 
> > have debugged stuff largely through logs in multi-node simulators, I 
> > generally rely on the thread name to identify the node (e.g. the UDP 
> > receive and send thread include the port number in the thread name).
> >
> 
> It could become an issue when trying to reproduce rare concurrency
> bugs that require running tests in a loop until they fail.  The
> smaller the synchronization overhead of the logging subsystem, the
> less noise you introduce in the simulation as you increase
> parallelism.  It also runs faster and you reproduce the bug sooner.

Yes, I have already pointed out why we log millisecond precision datestamps, 
and why it doesn't make sense to actually write to the log on the thread 
creating the log line.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Logging subsystem rewrite

[Zlatin Balevsky]

>
> But we use a static logging API anyway, and this works adequately well. I 
> have debugged stuff largely through logs in multi-node simulators, I 
> generally rely on the thread name to identify the node (e.g. the UDP receive 
> and send thread include the port number in the thread name).
>

It could become an issue when trying to reproduce rare concurrency
bugs that require running tests in a loop until they fail.  The
smaller the synchronization overhead of the logging subsystem, the
less noise you introduce in the simulation as you increase
parallelism.  It also runs faster and you reproduce the bug sooner.

Re: [freenet-dev] Logging subsystem rewrite

[Zlatin Balevsky]

>
> But we use a static logging API anyway, and this works adequately well. I 
> have debugged stuff largely through logs in multi-node simulators, I 
> generally rely on the thread name to identify the node (e.g. the UDP receive 
> and send thread include the port number in the thread name).
>

It could become an issue when trying to reproduce rare concurrency
bugs that require running tests in a loop until they fail.  The
smaller the synchronization overhead of the logging subsystem, the
less noise you introduce in the simulation as you increase
parallelism.  It also runs faster and you reproduce the bug sooner.
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Logging subsystem rewrite

[Marco Schulze]

On 30-03-2012 13:28, Matthew Toseland wrote:
> On Sunday 25 Mar 2012 23:22:24 Marco Schulze wrote:
>> Working (but incomplete) code is available @
>> https://github.com/Heiral/fred-staging/tree/logger++
> I'm keeping out of this for now, it should go in if it:
> - Simplifies the code.
Testing is centralized inside Log.isLoggable() and Log.write(). No 
callbacks or registering is needed, and mistakes in current code is 
mitigated (i.e. testing for one log level, and actually logging in 
another). IMHO, cutting ~5000 lines from the code, and ~200k from the 
jar speaks for itself.

> - Does not significantly reduce performance.
Until fred actually uses lazy toString() in log calls, that'll be 
unknown. Lazyness already works, though.

> - Does not significantly reduce debuggability (i.e. we need to be able to use 
> wildcards).
In to do list.

> - Reacts quickly enough (~1 second) to config changes.
All but adding per-class filtering should be quick enough.

> - Does not create a locking hotspot.
Only the OutputStream is locked. Mitigated by possible async option.

>
> Haven't reviewed the code yet.
>
>
> ___
> Devl mailing list
> Devl at freenetproject.org
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
-- next part --
An HTML attachment was scrubbed...
URL: 

[freenet-dev] Logging subsystem rewrite

[Matthew Toseland]

On Sunday 25 Mar 2012 23:22:24 Marco Schulze wrote:
> Working (but incomplete) code is available @ 
> https://github.com/Heiral/fred-staging/tree/logger++

I'm keeping out of this for now, it should go in if it:
- Simplifies the code.
- Does not significantly reduce performance.
- Does not significantly reduce debuggability (i.e. we need to be able to use 
wildcards).
- Reacts quickly enough (~1 second) to config changes.
- Does not create a locking hotspot.

Haven't reviewed the code yet.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Logging subsystem rewrite

[Matthew Toseland]

On Wednesday 28 Mar 2012 01:04:14 Zlatin Balevsky wrote:
> There are many problems with
> https://github.com/Heiral/fred-staging/commit/b876f8c454cb269281ffcb18d14d25b22818d130#L0R49
> :
> 
> line 25: the static field log should be volatile.  It may work now and
> then but it's broken.  Google "double-checked locking" for more info.
> Either that or synchronize it properly everywhere
> 
> lines 49-60 - "out" will refer to the parameter, not the static field
> so you will end up closing the parameter.  Also what if Log.out is
> null?  Can't synchronize on null.
> 
> Line 61: bad synchronization again
> 
> lines 65-75 Level.ordinal() will compile to a vtable call if you have
> more than two levels in use across the jvm.
> 
> lines 100-101: again, if out is null you can't synchronize on it.
> 
> Besides all this, adding a static dependency will create problems
> if/when a multi-node simulator or multi-node black box unit tests are
> written.

Both exist today. See freenet/node/simulator/. RealNodeULPRTest is a black-box 
unit test, which is run regularly in a cron script on my system. The others are 
mostly run on an as-needed basis, but are useful for testing changes that might 
affect routing.

But we use a static logging API anyway, and this works adequately well. I have 
debugged stuff largely through logs in multi-node simulators, I generally rely 
on the thread name to identify the node (e.g. the UDP receive and send thread 
include the port number in the thread name).
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

Re: [freenet-dev] Logging subsystem rewrite

[Marco Schulze]

On 30-03-2012 13:28, Matthew Toseland wrote:

On Sunday 25 Mar 2012 23:22:24 Marco Schulze wrote:

Working (but incomplete) code is available @
https://github.com/Heiral/fred-staging/tree/logger++

I'm keeping out of this for now, it should go in if it:
- Simplifies the code.
Testing is centralized inside Log.isLoggable() and Log.write(). No 
callbacks or registering is needed, and mistakes in current code is 
mitigated (i.e. testing for one log level, and actually logging in 
another). IMHO, cutting ~5000 lines from the code, and ~200k from the 
jar speaks for itself.



- Does not significantly reduce performance.
Until fred actually uses lazy toString() in log calls, that'll be 
unknown. Lazyness already works, though.



- Does not significantly reduce debuggability (i.e. we need to be able to use 
wildcards).

In to do list.


- Reacts quickly enough (~1 second) to config changes.

All but adding per-class filtering should be quick enough.


- Does not create a locking hotspot.

Only the OutputStream is locked. Mitigated by possible async option.



Haven't reviewed the code yet.


___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Logging subsystem rewrite

[Matthew Toseland]

On Sunday 25 Mar 2012 23:22:24 Marco Schulze wrote:
> Working (but incomplete) code is available @ 
> https://github.com/Heiral/fred-staging/tree/logger++

I'm keeping out of this for now, it should go in if it:
- Simplifies the code.
- Does not significantly reduce performance.
- Does not significantly reduce debuggability (i.e. we need to be able to use 
wildcards).
- Reacts quickly enough (~1 second) to config changes.
- Does not create a locking hotspot.

Haven't reviewed the code yet.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Logging subsystem rewrite

[Matthew Toseland]

On Wednesday 28 Mar 2012 01:04:14 Zlatin Balevsky wrote:
> There are many problems with
> https://github.com/Heiral/fred-staging/commit/b876f8c454cb269281ffcb18d14d25b22818d130#L0R49
> :
> 
> line 25: the static field log should be volatile.  It may work now and
> then but it's broken.  Google "double-checked locking" for more info.
> Either that or synchronize it properly everywhere
> 
> lines 49-60 - "out" will refer to the parameter, not the static field
> so you will end up closing the parameter.  Also what if Log.out is
> null?  Can't synchronize on null.
> 
> Line 61: bad synchronization again
> 
> lines 65-75 Level.ordinal() will compile to a vtable call if you have
> more than two levels in use across the jvm.
> 
> lines 100-101: again, if out is null you can't synchronize on it.
> 
> Besides all this, adding a static dependency will create problems
> if/when a multi-node simulator or multi-node black box unit tests are
> written.

Both exist today. See freenet/node/simulator/. RealNodeULPRTest is a black-box 
unit test, which is run regularly in a cron script on my system. The others are 
mostly run on an as-needed basis, but are useful for testing changes that might 
affect routing.

But we use a static logging API anyway, and this works adequately well. I have 
debugged stuff largely through logs in multi-node simulators, I generally rely 
on the thread name to identify the node (e.g. the UDP receive and send thread 
include the port number in the thread name).


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Logging subsystem rewrite

[Marco Schulze]

Threading should be ok now.

On 29-03-2012 01:33, David 'Bombe' Roden wrote:
> On Wed, 2012-03-28 at 17:31 -0300, Marco Schulze wrote:
>
>> Hmm, I was under the assumption that synchronized blocks locked
>> variables, not objects. Seems I have to review a few things...
> Uhm... might I suggest that you step away from everything having to do
> with threads until you have at least basic knowledge of how it works in
> Java? I guess that would be better for all.
>
>
> Greetings,
>
>   Bombe
>
>
> ___
> Devl mailing list
> Devl at freenetproject.org
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
-- next part --
An HTML attachment was scrubbed...
URL: 

Re: [freenet-dev] Logging subsystem rewrite

[Marco Schulze]

Threading should be ok now.

On 29-03-2012 01:33, David 'Bombe' Roden wrote:

On Wed, 2012-03-28 at 17:31 -0300, Marco Schulze wrote:


Hmm, I was under the assumption that synchronized blocks locked
variables, not objects. Seems I have to review a few things...

Uhm... might I suggest that you step away from everything having to do
with threads until you have at least basic knowledge of how it works in
Java? I guess that would be better for all.


Greetings,

Bombe


___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Logging subsystem rewrite

[David ‘Bombe’ Roden]

On Wed, 2012-03-28 at 17:31 -0300, Marco Schulze wrote:

> Hmm, I was under the assumption that synchronized blocks locked 
> variables, not objects. Seems I have to review a few things...

Uhm? might I suggest that you step away from everything having to do
with threads until you have at least basic knowledge of how it works in
Java? I guess that would be better for all.


Greetings,

Bombe
-- 
David ?Bombe? Roden 
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 

Re: [freenet-dev] Logging subsystem rewrite

[David ‘Bombe’ Roden]

On Wed, 2012-03-28 at 17:31 -0300, Marco Schulze wrote:

> Hmm, I was under the assumption that synchronized blocks locked 
> variables, not objects. Seems I have to review a few things...

Uhm… might I suggest that you step away from everything having to do
with threads until you have at least basic knowledge of how it works in
Java? I guess that would be better for all.


Greetings,

Bombe
-- 
David ‘Bombe’ Roden 


signature.asc
Description: This is a digitally signed message part
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Logging subsystem rewrite

[Marco Schulze]

Hmm, I was under the assumption that synchronized blocks locked 
variables, not objects. Seems I have to review a few things...

Regarding making Log instantiable, is that really necessary? IMHO, TID 
filtering is a better way to handle multi-node simulations when, and if 
that becomes necessary. There's also the fact that all classes using 
logging facilities would need to be _manually_ tweaked. The prime reason 
the change between old and proposed APIs is feasible is due to the fact 
that most of the work can be done almost automatically (~8000 lines 
touched by a sed script + ~100 manually tweaked lines), and, because the 
sed script is short, it can easily be verified, and its results replicated.

On 27-03-2012 21:04, Zlatin Balevsky wrote:
> There are many problems with
> https://github.com/Heiral/fred-staging/commit/b876f8c454cb269281ffcb18d14d25b22818d130#L0R49
> :
>
>
> line 25: the static field log should be volatile.  It may work now and
> then but it's broken.  Google "double-checked locking" for more info.
> Either that or synchronize it properly everywhere
>
> lines 49-60 - "out" will refer to the parameter, not the static field
> so you will end up closing the parameter.  Also what if Log.out is
> null?  Can't synchronize on null.
>
> Line 61: bad synchronization again
>
> lines 65-75 Level.ordinal() will compile to a vtable call if you have
> more than two levels in use across the jvm.
>
> lines 100-101: again, if out is null you can't synchronize on it.
>
>
> Besides all this, adding a static dependency will create problems
> if/when a multi-node simulator or multi-node black box unit tests are
> written.
>
> On Tue, Mar 27, 2012 at 2:35 PM, Marco Schulze
>   wrote:
>> On 27-03-2012 12:51, Martin Nyhus wrote:
>>> On Monday 26. March 2012 00:22:24 Marco Schulze wrote:
 Working (but incomplete) code is available @
 https://github.com/Heiral/fred-staging/tree/logger++
>>> Please keep in mind that simply deleting Logger will break pretty much
>>> every
>>> single plugin out there, so you really should rewrite Logger to call the
>>> new
>>> methods in your new logger class.
>> Will do.
>>
>>
>>> I won't say much about the code since you say you aren't finished, but
>>> please
>>> follow the code style of the rest of the code base.
>> Apart from the lack of braces, what violates the coding standards? I mean,
>> compared to the rest of fred code, I use too many blank lines, 80 character
>> lines, variables are declared at the top of the function and other minor
>> details. I hope that that isn't a problem.
>>
>>
>>> Also, I'm pretty sure you don't want to close the new stream here[0].
>> Fixed.
>>
>>
>>> And the
>>> locking when you update out isn't sufficient for visibility (either that
>>> or it
>>> isn't clear enough why it works IMHO).
>> You mean, things like if(out == null) without locking (inside isLoggable())?
>> In this case, it doesn't really matter as it is meant to be a very quick
>> check and getting the wrong values don't matter much.
>>
>>
>>> [0] https://github.com/Heiral/fred-
>>> staging/commit/b876f8c454cb269281ffcb18d14d25b22818d130#L0R49
>>> ___
>>> Devl mailing list
>>> Devl at freenetproject.org
>>> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>> ___
>> Devl mailing list
>> Devl at freenetproject.org
>> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
> ___
> Devl mailing list
> Devl at freenetproject.org
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Logging subsystem rewrite

[Marco Schulze]

Hmm, I was under the assumption that synchronized blocks locked 
variables, not objects. Seems I have to review a few things...


Regarding making Log instantiable, is that really necessary? IMHO, TID 
filtering is a better way to handle multi-node simulations when, and if 
that becomes necessary. There's also the fact that all classes using 
logging facilities would need to be _manually_ tweaked. The prime reason 
the change between old and proposed APIs is feasible is due to the fact 
that most of the work can be done almost automatically (~8000 lines 
touched by a sed script + ~100 manually tweaked lines), and, because the 
sed script is short, it can easily be verified, and its results replicated.


On 27-03-2012 21:04, Zlatin Balevsky wrote:

There are many problems with
https://github.com/Heiral/fred-staging/commit/b876f8c454cb269281ffcb18d14d25b22818d130#L0R49
:


line 25: the static field log should be volatile.  It may work now and
then but it's broken.  Google "double-checked locking" for more info.
Either that or synchronize it properly everywhere

lines 49-60 - "out" will refer to the parameter, not the static field
so you will end up closing the parameter.  Also what if Log.out is
null?  Can't synchronize on null.

Line 61: bad synchronization again

lines 65-75 Level.ordinal() will compile to a vtable call if you have
more than two levels in use across the jvm.

lines 100-101: again, if out is null you can't synchronize on it.


Besides all this, adding a static dependency will create problems
if/when a multi-node simulator or multi-node black box unit tests are
written.

On Tue, Mar 27, 2012 at 2:35 PM, Marco Schulze
  wrote:

On 27-03-2012 12:51, Martin Nyhus wrote:

On Monday 26. March 2012 00:22:24 Marco Schulze wrote:

Working (but incomplete) code is available @
https://github.com/Heiral/fred-staging/tree/logger++

Please keep in mind that simply deleting Logger will break pretty much
every
single plugin out there, so you really should rewrite Logger to call the
new
methods in your new logger class.

Will do.



I won't say much about the code since you say you aren't finished, but
please
follow the code style of the rest of the code base.

Apart from the lack of braces, what violates the coding standards? I mean,
compared to the rest of fred code, I use too many blank lines, 80 character
lines, variables are declared at the top of the function and other minor
details. I hope that that isn't a problem.



Also, I'm pretty sure you don't want to close the new stream here[0].

Fixed.



And the
locking when you update out isn't sufficient for visibility (either that
or it
isn't clear enough why it works IMHO).

You mean, things like if(out == null) without locking (inside isLoggable())?
In this case, it doesn't really matter as it is meant to be a very quick
check and getting the wrong values don't matter much.



[0] https://github.com/Heiral/fred-
staging/commit/b876f8c454cb269281ffcb18d14d25b22818d130#L0R49
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Logging subsystem rewrite

[Evan Daniel]

On Tue, Mar 27, 2012 at 2:35 PM, Marco Schulze
 wrote:
> On 27-03-2012 12:51, Martin Nyhus wrote:
>> I won't say much about the code since you say you aren't finished, but
>> please
>> follow the code style of the rest of the code base.
>
> Apart from the lack of braces, what violates the coding standards? I mean,
> compared to the rest of fred code, I use too many blank lines, 80 character
> lines, variables are declared at the top of the function and other minor
> details. I hope that that isn't a problem.

http://new-wiki.freenetproject.org/Coding_standards is what we would
like to have for new code.

Evan Daniel

Re: [freenet-dev] Logging subsystem rewrite

[Evan Daniel]

On Tue, Mar 27, 2012 at 2:35 PM, Marco Schulze
 wrote:
> On 27-03-2012 12:51, Martin Nyhus wrote:
>> I won't say much about the code since you say you aren't finished, but
>> please
>> follow the code style of the rest of the code base.
>
> Apart from the lack of braces, what violates the coding standards? I mean,
> compared to the rest of fred code, I use too many blank lines, 80 character
> lines, variables are declared at the top of the function and other minor
> details. I hope that that isn't a problem.

http://new-wiki.freenetproject.org/Coding_standards is what we would
like to have for new code.

Evan Daniel
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Logging subsystem rewrite

[Zlatin Balevsky]

There are many problems with
https://github.com/Heiral/fred-staging/commit/b876f8c454cb269281ffcb18d14d25b22818d130#L0R49
:


line 25: the static field log should be volatile.  It may work now and
then but it's broken.  Google "double-checked locking" for more info.
Either that or synchronize it properly everywhere

lines 49-60 - "out" will refer to the parameter, not the static field
so you will end up closing the parameter.  Also what if Log.out is
null?  Can't synchronize on null.

Line 61: bad synchronization again

lines 65-75 Level.ordinal() will compile to a vtable call if you have
more than two levels in use across the jvm.

lines 100-101: again, if out is null you can't synchronize on it.


Besides all this, adding a static dependency will create problems
if/when a multi-node simulator or multi-node black box unit tests are
written.

On Tue, Mar 27, 2012 at 2:35 PM, Marco Schulze
 wrote:
> On 27-03-2012 12:51, Martin Nyhus wrote:
>>
>> On Monday 26. March 2012 00:22:24 Marco Schulze wrote:
>>>
>>> Working (but incomplete) code is available @
>>> https://github.com/Heiral/fred-staging/tree/logger++
>>
>> Please keep in mind that simply deleting Logger will break pretty much
>> every
>> single plugin out there, so you really should rewrite Logger to call the
>> new
>> methods in your new logger class.
>
> Will do.
>
>
>>
>> I won't say much about the code since you say you aren't finished, but
>> please
>> follow the code style of the rest of the code base.
>
> Apart from the lack of braces, what violates the coding standards? I mean,
> compared to the rest of fred code, I use too many blank lines, 80 character
> lines, variables are declared at the top of the function and other minor
> details. I hope that that isn't a problem.
>
>
>>
>> Also, I'm pretty sure you don't want to close the new stream here[0].
>
> Fixed.
>
>
>> And the
>> locking when you update out isn't sufficient for visibility (either that
>> or it
>> isn't clear enough why it works IMHO).
>
> You mean, things like if(out == null) without locking (inside isLoggable())?
> In this case, it doesn't really matter as it is meant to be a very quick
> check and getting the wrong values don't matter much.
>
>
>>
>> [0] https://github.com/Heiral/fred-
>> staging/commit/b876f8c454cb269281ffcb18d14d25b22818d130#L0R49
>> ___
>> Devl mailing list
>> Devl at freenetproject.org
>> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>
> ___
> Devl mailing list
> Devl at freenetproject.org
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Logging subsystem rewrite

[Martin Nyhus]

On Monday 26. March 2012 00:22:24 Marco Schulze wrote:
> Working (but incomplete) code is available @
> https://github.com/Heiral/fred-staging/tree/logger++

Please keep in mind that simply deleting Logger will break pretty much every 
single plugin out there, so you really should rewrite Logger to call the new 
methods in your new logger class.

I won't say much about the code since you say you aren't finished, but please 
follow the code style of the rest of the code base.

Also, I'm pretty sure you don't want to close the new stream here[0]. And the 
locking when you update out isn't sufficient for visibility (either that or it 
isn't clear enough why it works IMHO).

[0] https://github.com/Heiral/fred-
staging/commit/b876f8c454cb269281ffcb18d14d25b22818d130#L0R49

Re: [freenet-dev] Logging subsystem rewrite

[Zlatin Balevsky]

There are many problems with
https://github.com/Heiral/fred-staging/commit/b876f8c454cb269281ffcb18d14d25b22818d130#L0R49
:


line 25: the static field log should be volatile.  It may work now and
then but it's broken.  Google "double-checked locking" for more info.
Either that or synchronize it properly everywhere

lines 49-60 - "out" will refer to the parameter, not the static field
so you will end up closing the parameter.  Also what if Log.out is
null?  Can't synchronize on null.

Line 61: bad synchronization again

lines 65-75 Level.ordinal() will compile to a vtable call if you have
more than two levels in use across the jvm.

lines 100-101: again, if out is null you can't synchronize on it.


Besides all this, adding a static dependency will create problems
if/when a multi-node simulator or multi-node black box unit tests are
written.

On Tue, Mar 27, 2012 at 2:35 PM, Marco Schulze
 wrote:
> On 27-03-2012 12:51, Martin Nyhus wrote:
>>
>> On Monday 26. March 2012 00:22:24 Marco Schulze wrote:
>>>
>>> Working (but incomplete) code is available @
>>> https://github.com/Heiral/fred-staging/tree/logger++
>>
>> Please keep in mind that simply deleting Logger will break pretty much
>> every
>> single plugin out there, so you really should rewrite Logger to call the
>> new
>> methods in your new logger class.
>
> Will do.
>
>
>>
>> I won't say much about the code since you say you aren't finished, but
>> please
>> follow the code style of the rest of the code base.
>
> Apart from the lack of braces, what violates the coding standards? I mean,
> compared to the rest of fred code, I use too many blank lines, 80 character
> lines, variables are declared at the top of the function and other minor
> details. I hope that that isn't a problem.
>
>
>>
>> Also, I'm pretty sure you don't want to close the new stream here[0].
>
> Fixed.
>
>
>> And the
>> locking when you update out isn't sufficient for visibility (either that
>> or it
>> isn't clear enough why it works IMHO).
>
> You mean, things like if(out == null) without locking (inside isLoggable())?
> In this case, it doesn't really matter as it is meant to be a very quick
> check and getting the wrong values don't matter much.
>
>
>>
>> [0] https://github.com/Heiral/fred-
>> staging/commit/b876f8c454cb269281ffcb18d14d25b22818d130#L0R49
>> ___
>> Devl mailing list
>> Devl@freenetproject.org
>> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>
> ___
> Devl mailing list
> Devl@freenetproject.org
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Logging subsystem rewrite

[Marco Schulze]

On 27-03-2012 12:51, Martin Nyhus wrote:
> On Monday 26. March 2012 00:22:24 Marco Schulze wrote:
>> Working (but incomplete) code is available @
>> https://github.com/Heiral/fred-staging/tree/logger++
> Please keep in mind that simply deleting Logger will break pretty much every
> single plugin out there, so you really should rewrite Logger to call the new
> methods in your new logger class.
Will do.

>
> I won't say much about the code since you say you aren't finished, but please
> follow the code style of the rest of the code base.
Apart from the lack of braces, what violates the coding standards? I 
mean, compared to the rest of fred code, I use too many blank lines, 80 
character lines, variables are declared at the top of the function and 
other minor details. I hope that that isn't a problem.

>
> Also, I'm pretty sure you don't want to close the new stream here[0].
Fixed.

> And the
> locking when you update out isn't sufficient for visibility (either that or it
> isn't clear enough why it works IMHO).
You mean, things like if(out == null) without locking (inside 
isLoggable())? In this case, it doesn't really matter as it is meant to 
be a very quick check and getting the wrong values don't matter much.

>
> [0] https://github.com/Heiral/fred-
> staging/commit/b876f8c454cb269281ffcb18d14d25b22818d130#L0R49
> ___
> Devl mailing list
> Devl at freenetproject.org
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Logging subsystem rewrite

[Marco Schulze]

On 27-03-2012 12:51, Martin Nyhus wrote:

On Monday 26. March 2012 00:22:24 Marco Schulze wrote:

Working (but incomplete) code is available @
https://github.com/Heiral/fred-staging/tree/logger++

Please keep in mind that simply deleting Logger will break pretty much every
single plugin out there, so you really should rewrite Logger to call the new
methods in your new logger class.

Will do.



I won't say much about the code since you say you aren't finished, but please
follow the code style of the rest of the code base.
Apart from the lack of braces, what violates the coding standards? I 
mean, compared to the rest of fred code, I use too many blank lines, 80 
character lines, variables are declared at the top of the function and 
other minor details. I hope that that isn't a problem.




Also, I'm pretty sure you don't want to close the new stream here[0].

Fixed.


And the
locking when you update out isn't sufficient for visibility (either that or it
isn't clear enough why it works IMHO).
You mean, things like if(out == null) without locking (inside 
isLoggable())? In this case, it doesn't really matter as it is meant to 
be a very quick check and getting the wrong values don't matter much.




[0] https://github.com/Heiral/fred-
staging/commit/b876f8c454cb269281ffcb18d14d25b22818d130#L0R49
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Logging subsystem rewrite

[Martin Nyhus]

On Monday 26. March 2012 00:22:24 Marco Schulze wrote:
> Working (but incomplete) code is available @
> https://github.com/Heiral/fred-staging/tree/logger++

Please keep in mind that simply deleting Logger will break pretty much every 
single plugin out there, so you really should rewrite Logger to call the new 
methods in your new logger class.

I won't say much about the code since you say you aren't finished, but please 
follow the code style of the rest of the code base.

Also, I'm pretty sure you don't want to close the new stream here[0]. And the 
locking when you update out isn't sufficient for visibility (either that or it 
isn't clear enough why it works IMHO).

[0] https://github.com/Heiral/fred-
staging/commit/b876f8c454cb269281ffcb18d14d25b22818d130#L0R49
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Logging subsystem rewrite

[Marco Schulze]

Working (but incomplete) code is available @ 
https://github.com/Heiral/fred-staging/tree/logger++

[freenet-dev] Logging subsystem rewrite

[Marco Schulze]

Working (but incomplete) code is available @ 
https://github.com/Heiral/fred-staging/tree/logger++

___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl