[freenet-dev] Freenet has been accepted in Google Summer of Code 2012!

[Ximin Luo]

Hi guys, I've added some of my ideas to the GSoC page.

I think someone should take some time to add more information to the other
ideas. ATM they are walls of text that don't have much structure, which new
students will probably have trouble parsing into a project plan.

I suggest each "project idea" be laid out similarly to what I've done, namely:


Mentors: 
Depends: 
Labels: 






You can use Template:GSoC_project_metadata to add the project metadata in a
concise way.

X

On 18/03/12 00:14, Florent Daigniere wrote:
> Hi!
> 
> Freenet has been accepted as a mentoring organization in Google Summer of 
> Code 2012!
> 
> Mentors and students can apply at
>   https://www.google-melange.com/gsoc/org/google/gsoc2012/freenet
> 
> 
> Our ideas page is at:
>   http://new-wiki.freenetproject.org/Google_Summer_of_Code/2012
> 
> Don't hesitate to contribute!
> 
> Florent
> ___
> Devl mailing list
> Devl at freenetproject.org
> http://freenetproject.org/cgi-bin/mailman/listinfo/devl


-- 
GPG: 4096R/5FBBDBCE
https://github.com/infinity0
https://bitbucket.org/infinity0
https://launchpad.net/~infinity0

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120319/75bd590f/attachment.pgp>

[freenet-dev] Website Redesign?

[Matthew Toseland]

On Monday 19 Mar 2012 09:20:06 Nicolas Hernandez wrote:
> Sometimes, the 2.7% of users could represents 80% of Freenet users :-)
> 
> Imagine that in some countries (*stan and lots of arabish/farsi langages
> countries) they are using the defaut OS and Browser (XP+IE7). This is not
> lots of people, but they needs help.

Is IE7 the last version available on XP? I thought that was IE8?
-- 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: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120319/f141c441/attachment.pgp>

[freenet-dev] Coding standards

[Matthew Toseland]

On Monday 19 Mar 2012 07:42:00 David ?Bombe? Roden wrote:
> On 18.03.2012, at 19:37, Steve Dougherty wrote:
> 
> > Is this what you're looking for?
> > 
> > http://new-wiki.freenetproject.org/Coding_standards
> 
> In light of 3ef15c7701d666f7661cd9b58b41ae525ef32569, does toad know about 
> these?

Fair point. :|

if(blah)
do_blah();

Is too easy to screw up. I guess we should standardise on always using {} if 
it's multi-line.
They're not necessary if it's single line though.
-- 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: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120319/62d67e7f/attachment.pgp>

[freenet-dev] Logging in Fred

[Marco Schulze]

How often does what happen?

On 19-03-2012 20:21, Martin Nyhus wrote:
> On Monday 19. March 2012 22:56:42 Marco Schulze wrote:
>> Synchronization is the reason every thread should wait. If the log is
>> always flushed and fred crashes, you know exactly where the last good
>> checkpoint was before the crash. If the log is buffered (or
>> asynchronous), the thread may be miles ahead from the last message
>> written to disk, and suddenly you have no idea where to look for the
>> bug. Shotgun debugging indeed.
> How often does this actually happen? Considering the performance penalty it
> has to fix a very real problem IMHO, especially since having logging change
> how the code behaves in such a dramatic way will make debugging anything that
> depends on timing that much harder.
> ___
> Devl mailing list
> Devl at freenetproject.org
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Logging in Fred

[Marco Schulze]

Never worked with aspects. Could you provide some snippets?

On 19-03-2012 09:52, Nicolas Hernandez wrote:
> Hello,
>
> It is really difficult to have a complete log system working. One 
> solution is to use aspects.
>
> Is this a good idea ?
>
> - Nicolas Hernandez
> a-n - aleph-networks
> /associ?/
> http://www.aleph-networks.com
>
>
>
>
> On Mon, Mar 19, 2012 at 12:40 AM, Marco Schulze 
> mailto:marco.c.schulze at gmail.com>> wrote:
>
> One thing has been bothering me: those 'if (logMINOR)
> Logger.minor(...', and the mess that logging is inside fred. I've
> written a very simple replacement for Logger + associated classes
> with the following changes:
>
> - Log level (renamed to severity) filtering is done by Logging.log();
> - Specific writer classes are replaced by a simple OutputStream,
> which defaults to System.err. Formatting is also unified;
> - Severity cases are broadened (FATAL, ERROR, WARNING, INFO, DEBUG
> and TRACE), MINOR is mapped to DEBUG, and NORMAL is mapped to INFO;
> - No logging method accepts an Object parameter - hashCode() is
> not exactly useful.
>
> Additionally, log rotation will be moved outside (possibly inside
> Node).
>
> Currently, the log format is '\t'.
> ___
> Devl mailing list
> Devl at freenetproject.org <mailto: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: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120319/c848b968/attachment.html>

[freenet-dev] Logging in Fred

[Matthew Toseland]

UG and
> >> TRACE), MINOR is mapped to DEBUG, and NORMAL is mapped to INFO;
> > Using the standard classes is fine by me.
> The biggest problem is that MINOR and NORMAL aren't being used the same 
> way by all classes, and their use isn't exactly clear.

Would that be solved by renaming?
> 
> >> - No logging method accepts an Object parameter - hashCode() is not
> >> exactly useful.
> > We're not after the hashcode, we're after the class name. We need to be 
> > able to filter by it, and that is essential.
> The problem is disambiguation, or per-object log threshold?

Both. When doing shotgun debugging a dev needs to be able to search by class 
name, this is why we log(this, ...), and even more importantly they need to be 
able to identify which classes to log properly.
> 
> >> Additionally, log rotation will be moved outside (possibly inside Node).
> > Not a good idea, for reasons of locking, file handle handling, the fact 
> > that you can't rename a file that is open on Windows ...
> I see. A LogRotator would solve it then.

Currently this is handled in FileLoggerHook like everything else. Whatever 
happens will need to be closely linked to the code that actually does the 
writing for several reasons:
1. We need to do size-based rotation sometimes, especially with heavy log 
settings.
2. On Windows, we cannot rename a file until we have closed it.
3. It's easier to ensure that everything goes to one log or another if we just 
have the thread doing the writing close it and then open another one.
> 
> > There are GOOD REASONS for all the complexity, but feel free to tinker with 
> > the API, or give specific arguments other than "this is all so complicated 
> > it *ought to* be possible to do something radically simpler".
> Not that it *ought to be* simpler, I just think current requirements are 
> a bit exaggerated.

Unfortunately this is not the case. Arguably I use too much shotgun debugging 
(debugging through heavy logging), but sometimes it's the only way to deal with 
a problem, due to there being lots of threads and stuff happening over seconds.
> 
> >> Currently, the log format is '\t'.
> > We need the timestamp, in a great many cases.
> In my todo list. Which object keeps track of uptime?

You can get it from Node IIRC? Not sure offhand. But have a look at the current 
code, in FileLoggerHook.java. No doubt it can be tidied up but it does at least 
meet all our requirements.
-- 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: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120319/fdbe4962/attachment.pgp>

[freenet-dev] Logging in Fred

[Marco Schulze]

On 19-03-2012 18:56, Marco Schulze wrote:
> On 19-03-2012 16:42, Matthew Toseland wrote:
>> PrintWriter (System.err) busy-loops. :( It is probably possible to 
>> get the underlying OutputStream though.
> Will take a look at it.
 From what I found after a quick googling, full disk errors do throw an 
IOException, but is silently ignored by various OutputStream subclasses 
(except for write(byte[])). No mention of any busy-loop, however.

[freenet-dev] Coding standards

[Evan Daniel]

Exactly. We already had this discussion and came to an agreement. New
code should follow it. Patches to fix old code would be welcome :)

Evan

On Mon, Mar 19, 2012 at 7:12 PM, Steve Dougherty  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I'm all for it. The coding standard is rather clear on indenting with
> tabs, so I guess all that would be required is a run with a
> re-indenting/code style conformance tool. That's something for a
> janitor tree, and would ideally be timed between releases and when all
> known pull requests have been merged or rejected to minimize
> whitespace-related disruption to existing work.
>
> On 03/19/2012 06:13 PM, Marco Schulze wrote:
>> May I add a vote to standardise indentation? This mess of spaces
>> with tabs really bugs me.
>>
>> On 19-03-2012 19:06, Matthew Toseland wrote:
>>> On Monday 19 Mar 2012 07:42:00 David 'Bombe' Roden wrote:
 On 18.03.2012, at 19:37, Steve Dougherty wrote:

> Is this what you're looking for?
>
> http://new-wiki.freenetproject.org/Coding_standards
 In light of 3ef15c7701d666f7661cd9b58b41ae525ef32569, does toad
 know about these?
>>> Fair point. :|
>>>
>>> if(blah) do_blah();
>>>
>>> Is too easy to screw up. I guess we should standardise on always
>>> using {} if it's multi-line. They're not necessary if it's single
>>> line though.
>>>
>>>
>>> ___ 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
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iQIcBAEBAgAGBQJPZ71EAAoJECLJP19KqmFuzIAP/R6yi7JPO8nqhbor1Yu6jwg2
> shB0jhIJ2o1d3+SPcU9cRHqgEeDwVTa7dkPAiin85n9fUPqBjoCuaejJskrjxm4u
> 63bUCKZzrMAggWwt9zNaoKxb/qIcCTCK3uC+3+jFDKAbNeNhjOSoh4cm6a54MlGf
> aHQ585A7iGZxeTzMDHmHUc0gFRSo83Y9XEacgg94ZdMpDd0Ff9GJAos+7swgZ+gT
> 4fXkO7vkvJGfHy+gskZC6Dnj0r0vHXJy2yJ8CifgozXIIkWeTWlZcBVaZ1emJ74J
> /vBtZYhmI2sHdQkVnz/IhdkfK3aEqiQSixvc6aYW9Uk5/eerZil4xRIpqQrR2PC+
> zoe988E7awVDQFRoBprHtcPqW0Q7i9fZmQawfnOMjDyJ57hbl27w7kaKi/J50GiP
> 0NMA4bKv43O20RvlonVVIo5EK1uOjzJGcRnsTsyoVjXmLiVrM3lCPzjK0X5aoy26
> 8Tjh3CZZe9oNGkXPS+z1zG9Jg8sk9apy0Q+zGrGEf7H8PBe6tYK9MTRIWxSP/rlw
> zwyjnj2kKIGWUIJ8iMuBQbXzqvRk80Zup5DZFfziEzz6F2PRwpkBsxg87jY5f7js
> 2EsvKEWIsJ19L7XsHhjRZQ2UMEKEPGTjmUUeBOpwJa6h/bWKaHaTuLFI680sed0G
> oTJlm2CiTlabZoE+8Uvs
> =ikVA
> -END PGP SIGNATURE-
> ___
> Devl mailing list
> Devl at freenetproject.org
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Coding standards

[Marco Schulze]

May I add a vote to standardise indentation? This mess of spaces with 
tabs really bugs me.

On 19-03-2012 19:06, Matthew Toseland wrote:
> On Monday 19 Mar 2012 07:42:00 David 'Bombe' Roden wrote:
>> On 18.03.2012, at 19:37, Steve Dougherty wrote:
>>
>>> Is this what you're looking for?
>>>
>>> http://new-wiki.freenetproject.org/Coding_standards
>> In light of 3ef15c7701d666f7661cd9b58b41ae525ef32569, does toad know about 
>> these?
> Fair point. :|
>
> if(blah)
>   do_blah();
>
> Is too easy to screw up. I guess we should standardise on always using {} if 
> it's multi-line.
> They're not necessary if it's single line though.
>
>
> ___
> Devl mailing list
> Devl at freenetproject.org
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120319/1a9b87ab/attachment.html>

[freenet-dev] Coding standards

[Steve Dougherty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I'm all for it. The coding standard is rather clear on indenting with
tabs, so I guess all that would be required is a run with a
re-indenting/code style conformance tool. That's something for a
janitor tree, and would ideally be timed between releases and when all
known pull requests have been merged or rejected to minimize
whitespace-related disruption to existing work.

On 03/19/2012 06:13 PM, Marco Schulze wrote:
> May I add a vote to standardise indentation? This mess of spaces
> with tabs really bugs me.
> 
> On 19-03-2012 19:06, Matthew Toseland wrote:
>> On Monday 19 Mar 2012 07:42:00 David 'Bombe' Roden wrote:
>>> On 18.03.2012, at 19:37, Steve Dougherty wrote:
>>> 
 Is this what you're looking for?
 
 http://new-wiki.freenetproject.org/Coding_standards
>>> In light of 3ef15c7701d666f7661cd9b58b41ae525ef32569, does toad
>>> know about these?
>> Fair point. :|
>> 
>> if(blah) do_blah();
>> 
>> Is too easy to screw up. I guess we should standardise on always
>> using {} if it's multi-line. They're not necessary if it's single
>> line though.
>> 
>> 
>> ___ 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
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJPZ71EAAoJECLJP19KqmFuzIAP/R6yi7JPO8nqhbor1Yu6jwg2
shB0jhIJ2o1d3+SPcU9cRHqgEeDwVTa7dkPAiin85n9fUPqBjoCuaejJskrjxm4u
63bUCKZzrMAggWwt9zNaoKxb/qIcCTCK3uC+3+jFDKAbNeNhjOSoh4cm6a54MlGf
aHQ585A7iGZxeTzMDHmHUc0gFRSo83Y9XEacgg94ZdMpDd0Ff9GJAos+7swgZ+gT
4fXkO7vkvJGfHy+gskZC6Dnj0r0vHXJy2yJ8CifgozXIIkWeTWlZcBVaZ1emJ74J
/vBtZYhmI2sHdQkVnz/IhdkfK3aEqiQSixvc6aYW9Uk5/eerZil4xRIpqQrR2PC+
zoe988E7awVDQFRoBprHtcPqW0Q7i9fZmQawfnOMjDyJ57hbl27w7kaKi/J50GiP
0NMA4bKv43O20RvlonVVIo5EK1uOjzJGcRnsTsyoVjXmLiVrM3lCPzjK0X5aoy26
8Tjh3CZZe9oNGkXPS+z1zG9Jg8sk9apy0Q+zGrGEf7H8PBe6tYK9MTRIWxSP/rlw
zwyjnj2kKIGWUIJ8iMuBQbXzqvRk80Zup5DZFfziEzz6F2PRwpkBsxg87jY5f7js
2EsvKEWIsJ19L7XsHhjRZQ2UMEKEPGTjmUUeBOpwJa6h/bWKaHaTuLFI680sed0G
oTJlm2CiTlabZoE+8Uvs
=ikVA
-END PGP SIGNATURE-

[freenet-dev] Logging in Fred

[Marco Schulze]

On 19-03-2012 16:42, Matthew Toseland wrote:
> No it doesn't. We need to be able to filter *by class name*, not just 
> globally. I agree that in theory the if(logMINOR) is optional if the message 
> is static though; I guess the JVM is fast enough that this won't cost us any 
> cycles?
>
> However, the minimum form of the boilerplate code is only:
>
> static {
>   volatile boolean logMINOR;
>   volatile boolean logDEBUG;
>   Logger.registerClass(Blah.class);
> }
Fred source tree (@master) contains 1012 *.java files. Even if 
conservatively assuming  that only 50% of those classes contain this 
snippet, and that they all use this minimal form, we have 2530 LoC for 
boilerplate code alone. Plus, 3379 hits to either logMINOR or logDEBUG.

That's a lot of code and memory use just to decide if a message is to be 
logged or not. (Yes, speed. See below)

> Hmm, maybe. Something like s[n]printf even - log("request %u rejected by %o", 
> requestID, peer) ??? Might be clearer code? Lot of work to change it though - 
> and fractionally lower runtime performance than the if(). Unfortunately java 
> doesn't have macros - but even if it did we'd like to be able to turn it on 
> at runtime.
I was thinking in something along the lines of Python's print() - if the 
message is to be logged:

Logger.info("This: ", this, ", and that: ", this.that)

is completely equivalent to:

Logger.info("This: " + this + ", and that: " + this.that)

If the message is discarded, the overhead is a function call + cost of 
filtering (most likely a simple table lookup and two int comparisons in 
the worst case).

If you'd like a strict comparison between the overhead of using an if, 
against the overhead of a function call, I ran three simple test cases:

- Call an empty function;
- Test a boolean and then call an empty function, with the boolean set 
to either true or false.

The test case was inside a for loop, repeating for about 2 billion 
times. The test was run thrice, with only milliseconds of difference 
between runs. More importantly, JIT was disabled through -Xint.

Function call: ~31 seconds
Test + call: ~33 seconds
Failed test: ~23 seconds

So yes, in my machine, using an if saves 7 seconds over 2 billion best 
case tests. That's ~3,26 nanoseconds saved per test - an insignificant 
microptimization.

If JIT is enabled, it could be argued that it's easier for the JVM to 
perform optimizations based on a single boolean, than on multiple 
volatile booleans.

> PrintWriter (System.err) busy-loops. :( It is probably possible to get the 
> underlying OutputStream though.
Will take a look at it.

> Yes. There is no reason to have each and every thread wait on disk I/O 
> (whether this is cached or not), and furthermore this will lead to 
> locking/concurrency problems. We get best performance by writing off thread, 
> and we can then have that thread dump excess log messages if it can't keep 
> up, avoiding blocking; or if something has to block, it's that thread and no 
> other; and it can also handle log rotation cleanly. And even more 
> importantly, we can keep lock contention to an absolute minimum, so other 
> threads logging data create a byte[] and then lock only to add it to a queue 
> (and delete surplus from the other end if necessary), which takes 
> insignificant time.
>
> All of this stuff is in FileLoggerHook.java.
Synchronization is the reason every thread should wait. If the log is 
always flushed and fred crashes, you know exactly where the last good 
checkpoint was before the crash. If the log is buffered (or 
asynchronous), the thread may be miles ahead from the last message 
written to disk, and suddenly you have no idea where to look for the 
bug. Shotgun debugging indeed.

Granted, if you want to generate lots of traces and debug data, it is 
desirable to churn out data at the highest rate possible. Possibly a 
configuration variable? Something like 'logger.mode = safe' (sync + 
flush) and 'logger.mode = unsafe' (async + buffered)?

Now, I'd wager the cost of maintaining a cache of log messages far 
surpass the cost of generating them in the first place except for very 
costly messages regenerated sparingly (or not at all). I haven't seen 
the current implementation, so there might exist some trick I'm failing 
to grasp.

> I beg to differ. This shouldn't happen in normal use anyway. It's a message 
> to devs doing shotgun debugging that they need a narrower filter (or faster 
> disks!). We do indicate when stuff has been dropped.
Indication is no substitute for missing data. Speed doesn't really 
matter if you lose that critical message.

> Would that be solved by renaming?
Since most people are used to DEBUG and INFO levels, their use becomes 
apparent.

> Both. When doing shotgun debugging a dev needs to be able to search by class 
> name, this is why we log(this, ...), and even more importantly they need to 
> be able to identify which classes to log properly.
Right, but wouldn't the use of call sta

[freenet-dev] Website Redesign?

[Leah Hicks]

For Windows XP IE 8 is the latest version. Windows 2000 can go up to IE 7.

On Mon, Mar 19, 2012 at 5:12 PM, Matthew Toseland  wrote:

> On Monday 19 Mar 2012 09:20:06 Nicolas Hernandez wrote:
> > Sometimes, the 2.7% of users could represents 80% of Freenet users :-)
> >
> > Imagine that in some countries (*stan and lots of arabish/farsi langages
> > countries) they are using the defaut OS and Browser (XP+IE7). This is not
> > lots of people, but they needs help.
>
> Is IE7 the last version available on XP? I thought that was IE8?
>
> ___
> Devl mailing list
> Devl at freenetproject.org
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>



-- 
-- *Leah Hicks*
*
*
http://kori-designs.com
*http://kanjidaisuki.com*
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120319/a4d7e3a7/attachment.html>

Re: [freenet-dev] Freenet has been accepted in Google Summer of Code 2012!

[Ximin Luo]

Hi guys, I've added some of my ideas to the GSoC page.

I think someone should take some time to add more information to the other
ideas. ATM they are walls of text that don't have much structure, which new
students will probably have trouble parsing into a project plan.

I suggest each "project idea" be laid out similarly to what I've done, namely:


Mentors: 
Depends: 
Labels: 






You can use Template:GSoC_project_metadata to add the project metadata in a
concise way.

X

On 18/03/12 00:14, Florent Daigniere wrote:
> Hi!
> 
> Freenet has been accepted as a mentoring organization in Google Summer of 
> Code 2012!
> 
> Mentors and students can apply at
>   https://www.google-melange.com/gsoc/org/google/gsoc2012/freenet
> 
> 
> Our ideas page is at:
>   http://new-wiki.freenetproject.org/Google_Summer_of_Code/2012
> 
> Don't hesitate to contribute!
> 
> Florent
> ___
> Devl mailing list
> Devl@freenetproject.org
> http://freenetproject.org/cgi-bin/mailman/listinfo/devl


-- 
GPG: 4096R/5FBBDBCE
https://github.com/infinity0
https://bitbucket.org/infinity0
https://launchpad.net/~infinity0



signature.asc
Description: OpenPGP digital signature
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Logging in Fred

[Marco Schulze]

How often does what happen?

On 19-03-2012 20:21, Martin Nyhus wrote:

On Monday 19. March 2012 22:56:42 Marco Schulze wrote:

Synchronization is the reason every thread should wait. If the log is
always flushed and fred crashes, you know exactly where the last good
checkpoint was before the crash. If the log is buffered (or
asynchronous), the thread may be miles ahead from the last message
written to disk, and suddenly you have no idea where to look for the
bug. Shotgun debugging indeed.

How often does this actually happen? Considering the performance penalty it
has to fix a very real problem IMHO, especially since having logging change
how the code behaves in such a dramatic way will make debugging anything that
depends on timing that much harder.
___
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 in Fred

[Martin Nyhus]

On Monday 19. March 2012 22:56:42 Marco Schulze wrote:
> Synchronization is the reason every thread should wait. If the log is
> always flushed and fred crashes, you know exactly where the last good
> checkpoint was before the crash. If the log is buffered (or
> asynchronous), the thread may be miles ahead from the last message
> written to disk, and suddenly you have no idea where to look for the
> bug. Shotgun debugging indeed.

How often does this actually happen? Considering the performance penalty it 
has to fix a very real problem IMHO, especially since having logging change 
how the code behaves in such a dramatic way will make debugging anything that 
depends on timing that much harder.
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Logging in Fred

[Marco Schulze]

Never worked with aspects. Could you provide some snippets?

On 19-03-2012 09:52, Nicolas Hernandez wrote:

Hello,

It is really difficult to have a complete log system working. One 
solution is to use aspects.


Is this a good idea ?

- Nicolas Hernandez
a-n - aleph-networks
/associé/
http://www.aleph-networks.com




On Mon, Mar 19, 2012 at 12:40 AM, Marco Schulze 
mailto:marco.c.schu...@gmail.com>> wrote:


One thing has been bothering me: those 'if (logMINOR)
Logger.minor(...', and the mess that logging is inside fred. I've
written a very simple replacement for Logger + associated classes
with the following changes:

- Log level (renamed to severity) filtering is done by Logging.log();
- Specific writer classes are replaced by a simple OutputStream,
which defaults to System.err. Formatting is also unified;
- Severity cases are broadened (FATAL, ERROR, WARNING, INFO, DEBUG
and TRACE), MINOR is mapped to DEBUG, and NORMAL is mapped to INFO;
- No logging method accepts an Object parameter - hashCode() is
not exactly useful.

Additionally, log rotation will be moved outside (possibly inside
Node).

Currently, the log format is '\t'.
___
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] Coding standards

[Evan Daniel]

Exactly. We already had this discussion and came to an agreement. New
code should follow it. Patches to fix old code would be welcome :)

Evan

On Mon, Mar 19, 2012 at 7:12 PM, Steve Dougherty  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I'm all for it. The coding standard is rather clear on indenting with
> tabs, so I guess all that would be required is a run with a
> re-indenting/code style conformance tool. That's something for a
> janitor tree, and would ideally be timed between releases and when all
> known pull requests have been merged or rejected to minimize
> whitespace-related disruption to existing work.
>
> On 03/19/2012 06:13 PM, Marco Schulze wrote:
>> May I add a vote to standardise indentation? This mess of spaces
>> with tabs really bugs me.
>>
>> On 19-03-2012 19:06, Matthew Toseland wrote:
>>> On Monday 19 Mar 2012 07:42:00 David 'Bombe' Roden wrote:
 On 18.03.2012, at 19:37, Steve Dougherty wrote:

> Is this what you're looking for?
>
> http://new-wiki.freenetproject.org/Coding_standards
 In light of 3ef15c7701d666f7661cd9b58b41ae525ef32569, does toad
 know about these?
>>> Fair point. :|
>>>
>>> if(blah) do_blah();
>>>
>>> Is too easy to screw up. I guess we should standardise on always
>>> using {} if it's multi-line. They're not necessary if it's single
>>> line though.
>>>
>>>
>>> ___ 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
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iQIcBAEBAgAGBQJPZ71EAAoJECLJP19KqmFuzIAP/R6yi7JPO8nqhbor1Yu6jwg2
> shB0jhIJ2o1d3+SPcU9cRHqgEeDwVTa7dkPAiin85n9fUPqBjoCuaejJskrjxm4u
> 63bUCKZzrMAggWwt9zNaoKxb/qIcCTCK3uC+3+jFDKAbNeNhjOSoh4cm6a54MlGf
> aHQ585A7iGZxeTzMDHmHUc0gFRSo83Y9XEacgg94ZdMpDd0Ff9GJAos+7swgZ+gT
> 4fXkO7vkvJGfHy+gskZC6Dnj0r0vHXJy2yJ8CifgozXIIkWeTWlZcBVaZ1emJ74J
> /vBtZYhmI2sHdQkVnz/IhdkfK3aEqiQSixvc6aYW9Uk5/eerZil4xRIpqQrR2PC+
> zoe988E7awVDQFRoBprHtcPqW0Q7i9fZmQawfnOMjDyJ57hbl27w7kaKi/J50GiP
> 0NMA4bKv43O20RvlonVVIo5EK1uOjzJGcRnsTsyoVjXmLiVrM3lCPzjK0X5aoy26
> 8Tjh3CZZe9oNGkXPS+z1zG9Jg8sk9apy0Q+zGrGEf7H8PBe6tYK9MTRIWxSP/rlw
> zwyjnj2kKIGWUIJ8iMuBQbXzqvRk80Zup5DZFfziEzz6F2PRwpkBsxg87jY5f7js
> 2EsvKEWIsJ19L7XsHhjRZQ2UMEKEPGTjmUUeBOpwJa6h/bWKaHaTuLFI680sed0G
> oTJlm2CiTlabZoE+8Uvs
> =ikVA
> -END PGP SIGNATURE-
> ___
> 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] Coding standards

[Steve Dougherty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I'm all for it. The coding standard is rather clear on indenting with
tabs, so I guess all that would be required is a run with a
re-indenting/code style conformance tool. That's something for a
janitor tree, and would ideally be timed between releases and when all
known pull requests have been merged or rejected to minimize
whitespace-related disruption to existing work.

On 03/19/2012 06:13 PM, Marco Schulze wrote:
> May I add a vote to standardise indentation? This mess of spaces
> with tabs really bugs me.
> 
> On 19-03-2012 19:06, Matthew Toseland wrote:
>> On Monday 19 Mar 2012 07:42:00 David 'Bombe' Roden wrote:
>>> On 18.03.2012, at 19:37, Steve Dougherty wrote:
>>> 
 Is this what you're looking for?
 
 http://new-wiki.freenetproject.org/Coding_standards
>>> In light of 3ef15c7701d666f7661cd9b58b41ae525ef32569, does toad
>>> know about these?
>> Fair point. :|
>> 
>> if(blah) do_blah();
>> 
>> Is too easy to screw up. I guess we should standardise on always
>> using {} if it's multi-line. They're not necessary if it's single
>> line though.
>> 
>> 
>> ___ 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
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJPZ71EAAoJECLJP19KqmFuzIAP/R6yi7JPO8nqhbor1Yu6jwg2
shB0jhIJ2o1d3+SPcU9cRHqgEeDwVTa7dkPAiin85n9fUPqBjoCuaejJskrjxm4u
63bUCKZzrMAggWwt9zNaoKxb/qIcCTCK3uC+3+jFDKAbNeNhjOSoh4cm6a54MlGf
aHQ585A7iGZxeTzMDHmHUc0gFRSo83Y9XEacgg94ZdMpDd0Ff9GJAos+7swgZ+gT
4fXkO7vkvJGfHy+gskZC6Dnj0r0vHXJy2yJ8CifgozXIIkWeTWlZcBVaZ1emJ74J
/vBtZYhmI2sHdQkVnz/IhdkfK3aEqiQSixvc6aYW9Uk5/eerZil4xRIpqQrR2PC+
zoe988E7awVDQFRoBprHtcPqW0Q7i9fZmQawfnOMjDyJ57hbl27w7kaKi/J50GiP
0NMA4bKv43O20RvlonVVIo5EK1uOjzJGcRnsTsyoVjXmLiVrM3lCPzjK0X5aoy26
8Tjh3CZZe9oNGkXPS+z1zG9Jg8sk9apy0Q+zGrGEf7H8PBe6tYK9MTRIWxSP/rlw
zwyjnj2kKIGWUIJ8iMuBQbXzqvRk80Zup5DZFfziEzz6F2PRwpkBsxg87jY5f7js
2EsvKEWIsJ19L7XsHhjRZQ2UMEKEPGTjmUUeBOpwJa6h/bWKaHaTuLFI680sed0G
oTJlm2CiTlabZoE+8Uvs
=ikVA
-END PGP SIGNATURE-
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Logging in Fred

[Marco Schulze]

On 19-03-2012 18:56, Marco Schulze wrote:

On 19-03-2012 16:42, Matthew Toseland wrote:
PrintWriter (System.err) busy-loops. :( It is probably possible to 
get the underlying OutputStream though.

Will take a look at it.
From what I found after a quick googling, full disk errors do throw an 
IOException, but is silently ignored by various OutputStream subclasses 
(except for write(byte[])). No mention of any busy-loop, however.

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

Re: [freenet-dev] Website Redesign?

[Leah Hicks]

For Windows XP IE 8 is the latest version. Windows 2000 can go up to IE 7.

On Mon, Mar 19, 2012 at 5:12 PM, Matthew Toseland  wrote:

> On Monday 19 Mar 2012 09:20:06 Nicolas Hernandez wrote:
> > Sometimes, the 2.7% of users could represents 80% of Freenet users :-)
> >
> > Imagine that in some countries (*stan and lots of arabish/farsi langages
> > countries) they are using the defaut OS and Browser (XP+IE7). This is not
> > lots of people, but they needs help.
>
> Is IE7 the last version available on XP? I thought that was IE8?
>
> ___
> Devl mailing list
> Devl@freenetproject.org
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>



-- 
-- *Leah Hicks*
*
*
http://kori-designs.com
*http://kanjidaisuki.com*
___
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Coding standards

[Marco Schulze]

May I add a vote to standardise indentation? This mess of spaces with 
tabs really bugs me.


On 19-03-2012 19:06, Matthew Toseland wrote:

On Monday 19 Mar 2012 07:42:00 David 'Bombe' Roden wrote:

On 18.03.2012, at 19:37, Steve Dougherty wrote:


Is this what you're looking for?

http://new-wiki.freenetproject.org/Coding_standards

In light of 3ef15c7701d666f7661cd9b58b41ae525ef32569, does toad know about 
these?

Fair point. :|

if(blah)
do_blah();

Is too easy to screw up. I guess we should standardise on always using {} if 
it's multi-line.
They're not necessary if it's single line though.


___
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] Website Redesign?

[Matthew Toseland]

On Monday 19 Mar 2012 09:20:06 Nicolas Hernandez wrote:
> Sometimes, the 2.7% of users could represents 80% of Freenet users :-)
> 
> Imagine that in some countries (*stan and lots of arabish/farsi langages
> countries) they are using the defaut OS and Browser (XP+IE7). This is not
> lots of people, but they needs help.

Is IE7 the last version available on XP? I thought that was IE8?


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] Coding standards

[Matthew Toseland]

On Monday 19 Mar 2012 07:42:00 David ‘Bombe’ Roden wrote:
> On 18.03.2012, at 19:37, Steve Dougherty wrote:
> 
> > Is this what you're looking for?
> > 
> > http://new-wiki.freenetproject.org/Coding_standards
> 
> In light of 3ef15c7701d666f7661cd9b58b41ae525ef32569, does toad know about 
> these?

Fair point. :|

if(blah)
do_blah();

Is too easy to screw up. I guess we should standardise on always using {} if 
it's multi-line.
They're not necessary if it's single line though.


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 in Fred

[Marco Schulze]

On 19-03-2012 16:42, Matthew Toseland wrote:

No it doesn't. We need to be able to filter *by class name*, not just globally. 
I agree that in theory the if(logMINOR) is optional if the message is static 
though; I guess the JVM is fast enough that this won't cost us any cycles?

However, the minimum form of the boilerplate code is only:

static {
volatile boolean logMINOR;
volatile boolean logDEBUG;
Logger.registerClass(Blah.class);
}
Fred source tree (@master) contains 1012 *.java files. Even if 
conservatively assuming  that only 50% of those classes contain this 
snippet, and that they all use this minimal form, we have 2530 LoC for 
boilerplate code alone. Plus, 3379 hits to either logMINOR or logDEBUG.


That's a lot of code and memory use just to decide if a message is to be 
logged or not. (Yes, speed. See below)



Hmm, maybe. Something like s[n]printf even - log("request %u rejected by %o", 
requestID, peer) ??? Might be clearer code? Lot of work to change it though - and 
fractionally lower runtime performance than the if(). Unfortunately java doesn't have 
macros - but even if it did we'd like to be able to turn it on at runtime.
I was thinking in something along the lines of Python's print() - if the 
message is to be logged:


Logger.info("This: ", this, ", and that: ", this.that)

is completely equivalent to:

Logger.info("This: " + this + ", and that: " + this.that)

If the message is discarded, the overhead is a function call + cost of 
filtering (most likely a simple table lookup and two int comparisons in 
the worst case).


If you'd like a strict comparison between the overhead of using an if, 
against the overhead of a function call, I ran three simple test cases:


- Call an empty function;
- Test a boolean and then call an empty function, with the boolean set 
to either true or false.


The test case was inside a for loop, repeating for about 2 billion 
times. The test was run thrice, with only milliseconds of difference 
between runs. More importantly, JIT was disabled through -Xint.


Function call: ~31 seconds
Test + call: ~33 seconds
Failed test: ~23 seconds

So yes, in my machine, using an if saves 7 seconds over 2 billion best 
case tests. That's ~3,26 nanoseconds saved per test - an insignificant 
microptimization.


If JIT is enabled, it could be argued that it's easier for the JVM to 
perform optimizations based on a single boolean, than on multiple 
volatile booleans.



PrintWriter (System.err) busy-loops. :( It is probably possible to get the 
underlying OutputStream though.

Will take a look at it.


Yes. There is no reason to have each and every thread wait on disk I/O (whether 
this is cached or not), and furthermore this will lead to locking/concurrency 
problems. We get best performance by writing off thread, and we can then have 
that thread dump excess log messages if it can't keep up, avoiding blocking; or 
if something has to block, it's that thread and no other; and it can also 
handle log rotation cleanly. And even more importantly, we can keep lock 
contention to an absolute minimum, so other threads logging data create a 
byte[] and then lock only to add it to a queue (and delete surplus from the 
other end if necessary), which takes insignificant time.

All of this stuff is in FileLoggerHook.java.
Synchronization is the reason every thread should wait. If the log is 
always flushed and fred crashes, you know exactly where the last good 
checkpoint was before the crash. If the log is buffered (or 
asynchronous), the thread may be miles ahead from the last message 
written to disk, and suddenly you have no idea where to look for the 
bug. Shotgun debugging indeed.


Granted, if you want to generate lots of traces and debug data, it is 
desirable to churn out data at the highest rate possible. Possibly a 
configuration variable? Something like 'logger.mode = safe' (sync + 
flush) and 'logger.mode = unsafe' (async + buffered)?


Now, I'd wager the cost of maintaining a cache of log messages far 
surpass the cost of generating them in the first place except for very 
costly messages regenerated sparingly (or not at all). I haven't seen 
the current implementation, so there might exist some trick I'm failing 
to grasp.



I beg to differ. This shouldn't happen in normal use anyway. It's a message to 
devs doing shotgun debugging that they need a narrower filter (or faster 
disks!). We do indicate when stuff has been dropped.
Indication is no substitute for missing data. Speed doesn't really 
matter if you lose that critical message.



Would that be solved by renaming?
Since most people are used to DEBUG and INFO levels, their use becomes 
apparent.



Both. When doing shotgun debugging a dev needs to be able to search by class 
name, this is why we log(this, ...), and even more importantly they need to be 
able to identify which classes to log properly.
Right, but wouldn't the use of call stack + reflection be cleaner for 
the caller? Yes

[freenet-dev] Logging in Fred

[Nicolas Hernandez]

Hello,

It is really difficult to have a complete log system working. One solution
is to use aspects.

Is this a good idea ?

- Nicolas Hernandez
a-n - aleph-networks
*associ?*
http://www.aleph-networks.com




On Mon, Mar 19, 2012 at 12:40 AM, Marco Schulze
wrote:

> One thing has been bothering me: those 'if (logMINOR) Logger.minor(...',
> and the mess that logging is inside fred. I've written a very simple
> replacement for Logger + associated classes with the following changes:
>
> - Log level (renamed to severity) filtering is done by Logging.log();
> - Specific writer classes are replaced by a simple OutputStream, which
> defaults to System.err. Formatting is also unified;
> - Severity cases are broadened (FATAL, ERROR, WARNING, INFO, DEBUG and
> TRACE), MINOR is mapped to DEBUG, and NORMAL is mapped to INFO;
> - No logging method accepts an Object parameter - hashCode() is not
> exactly useful.
>
> Additionally, log rotation will be moved outside (possibly inside Node).
>
> Currently, the log format is '\t'.
> __**_
> Devl mailing list
> Devl at freenetproject.org
> https://emu.freenetproject.**org/cgi-bin/mailman/listinfo/**devl<https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120319/d4c3be46/attachment.html>

Re: [freenet-dev] Logging in Fred

[Matthew Toseland]

On Monday 19 Mar 2012 12:17:51 Marco Schulze wrote:
> On 18-03-2012 21:50, Matthew Toseland wrote:
> > On Sunday 18 Mar 2012 23:40:44 Marco Schulze wrote:
> >> One thing has been bothering me: those 'if (logMINOR) Logger.minor(...',
> >> and the mess that logging is inside fred. I've written a very simple
> >> replacement for Logger + associated classes with the following changes:
> > You're not using the java logging API?
> First thing I thought, but the Java logging mechanisms are complex (more 
> LoC), at least compared to what I have now. It also lacks those cute 
> error()/debug() methods, so a wrapper would be needed anyway.
> 
> > The if(logMINOR) is *ABSOLUTELY VITAL* for performance. You simply cannot 
> > get rid of it. Generating the strings costs significantly more CPU than the 
> > rest of what Freenet does put together.
> In most cases I've seen so far, either the message is constant, or is 
> interpolated with one or two variables. In those cases where building a 
> message to be logged is actually expensive, directly checking the logger 
> state (Logger.min_severity) saves that contrived prolog used to setup 
> logMINOR and logDEBUG.

No it doesn't. We need to be able to filter *by class name*, not just globally. 
I agree that in theory the if(logMINOR) is optional if the message is static 
though; I guess the JVM is fast enough that this won't cost us any cycles?

However, the minimum form of the boilerplate code is only:

static {
volatile boolean logMINOR;
volatile boolean logDEBUG;
Logger.registerClass(Blah.class);
}
> 
> If string building is really slow (possibly because some object's 
> toString() is going wild), logging methods can be changed to something 
> like: public void Logger.info(Object... objs), and the final string 
> would only be built by the logger if it would actually use it.

Hmm, maybe. Something like s[n]printf even - log("request %u rejected by %o", 
requestID, peer) ??? Might be clearer code? Lot of work to change it though - 
and fractionally lower runtime performance than the if(). Unfortunately java 
doesn't have macros - but even if it did we'd like to be able to turn it on at 
runtime.
> 
> >> - Log level (renamed to severity) filtering is done by Logging.log();
> > Feel free to rename it. I don't see much point though unless you are trying 
> > to use a standard API, which *may* be a good idea.
> No special reason for the change, I just though Logger.Severity sounded 
> better than Logger.LogLevel.
> 
> >> - Specific writer classes are replaced by a simple OutputStream, which
> >> defaults to System.err. Formatting is also unified;
> > Very bad idea. There are many excellent reasons for the complexity that is 
> > FileLoggerHook. One is that if System.err is blocked (e.g. a full disk), 
> > everything grinds to a halt.
> Doesn't write() throw an IOException when the disk is full?

PrintWriter (System.err) busy-loops. :( It is probably possible to get the 
underlying OutputStream though.
> 
> > Adequate caching is also essential, and I'm not certain whether there are 
> > locking issues;
> You mean, caching of log messages? Could you elaborate?

Yes. There is no reason to have each and every thread wait on disk I/O (whether 
this is cached or not), and furthermore this will lead to locking/concurrency 
problems. We get best performance by writing off thread, and we can then have 
that thread dump excess log messages if it can't keep up, avoiding blocking; or 
if something has to block, it's that thread and no other; and it can also 
handle log rotation cleanly. And even more importantly, we can keep lock 
contention to an absolute minimum, so other threads logging data create a 
byte[] and then lock only to add it to a queue (and delete surplus from the 
other end if necessary), which takes insignificant time.

All of this stuff is in FileLoggerHook.java.
> 
> > and dropping log lines when we can't keep up rather than just slowing down 
> > the rest of the node is a good thing.
> Sorry, but I heavily disagree with you here. Not only dropping messages 
> makes logs misleading, the output stream should either be unbuffered or 
> flushed after every message. If everything is slowing down because of 
> this, it is either expected (DEBUG or TRACE messages are written), or 
> fred is logging too much above the default INFO threshold.

I beg to differ. This shouldn't happen in normal use anyway. It's a message to 
devs doing shotgun debugging that they need a narrower filter (or faster 
disks!). We do indicate when stuff has been dropped.
> 
> >> - Severity cases are broadened (FATAL, ERROR, WARNING, INFO, DEBUG and
> >> TRACE), MINOR is mapped to DEBUG, and NORMAL is mapped to INFO;
> > Using the standard classes is fine by me.
> The biggest problem is that MINOR and NORMAL aren't being used the same 
> way by all classes, and their use isn't exactly clear.

Would that be solved by renaming?
> 
> >> - No logging method accepts an Object para

[freenet-dev] (no subject)

[Florent Daigniere]

It can be done differently but not using cookies :)

Anyways, that's only required if you want to change from the language you 
configured
your browser to use... not a big deal imo.

Florent

On Mon, Mar 19, 2012 at 02:33:02AM +, Ximin Luo wrote:
> Oh, right. Well if all it does is set cookies that can probably be done some
> other way. TBH I'm still in favour of having /%lang%/ in the path.
> 
> On 19/03/12 02:13, Steve Dougherty wrote:
> > Leah is correct - Florent added Javascript to set cookies for
> > determining the language served by Apache.
> > 
> > On 03/18/2012 10:04 PM, Ximin Luo wrote:
> >> I wasn't aware any previous method used javascript, but we
> >> implemented a non-javascript method quite recently that checks the
> >> client browser's Accept-Language HTTP headers. Have a look at
> >> Steve's thread (in this same mailing list) titled "Spanish
> >> Translation Deployment Complete".
> > 
> >> There is JS on the site currently but (I believe) that has nothing
> >> to do with translations.
> > 
> >> On 19/03/12 01:04, Leah Hicks wrote:
> >>> I have done my research, although I have to admit wordpress is
> >>> not perfect. If it is /really/ that big of an issue then we will
> >>> simply not use it. And yes I'm aware of the current
> >>> implementation however it uses javascript which will not run if
> >>> users have javascript disabled. If someone can find a workaround
> >>> for that I'm golden.
> >>>
> >>>
> >>> ___ 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
> 
> -- 
> GPG: 4096R/5FBBDBCE
> https://github.com/infinity0
> https://bitbucket.org/infinity0
> https://launchpad.net/~infinity0
> 



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

[freenet-dev] Website Redesign?

[Nicolas Hernandez]

Sometimes, the 2.7% of users could represents 80% of Freenet users :-)

Imagine that in some countries (*stan and lots of arabish/farsi langages
countries) they are using the defaut OS and Browser (XP+IE7). This is not
lots of people, but they needs help.

For information


Rgds
- Nicolas Hernandez
a-n - aleph-networks
*associ?*
http://www.aleph-networks.com




On Mon, Mar 19, 2012 at 2:35 AM, Leah Hicks  wrote:

> It would seem that, according to the W3schools browser stats page, 2.7% of
> all users (in february) used IE7. So I think we're good on that part. Even
> if people do use that browser I highly doubt these are going to be people
> visiting freenet :p
>
> On Sun, Mar 18, 2012 at 8:04 PM, Matthew Toseland <
> toad at amphibian.dyndns.org> wrote:
>
>> On Sunday 18 Mar 2012 14:37:14 Ian Clarke wrote:
>> > Leah,
>> >
>> > That sounds great, our last redesign was indeed several years ago, and I
>> > agree that the site is probably overdue for a facelift.
>> >
>> > One thing though, I think we will need to support Internet Explorer 7,
>> > which I believe doesn't support some of the newer web standards you
>> > mention.  It's ok if the site doesn't look quite as good in IE7, but it
>> > should at least work.  (The good news is that the upcoming IE10 does
>> > support these things, so hopefully we won't have to worry about it for
>> too
>> > much longer).
>>
>> Why do we need IE7 support? Does anyone still use it? Even on Windows XP?
>>
>> ___
>> Devl mailing list
>> Devl at freenetproject.org
>> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>>
>
>
>
> --
> -- *Leah Hicks*
> *
> *
> http://kori-designs.com
> *http://kanjidaisuki.com*
>
>
> ___
> Devl mailing list
> Devl at freenetproject.org
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120319/10b2b338/attachment.html>

[freenet-dev] Refactoring Freenet and Library was Re: Gun.IO and Freenet

[Marco Schulze]

 download location (if system-wide daemon, ~/Downloads
>>>>> otherwise).
>>>>> /var/cache/fred: datastore and other miscellaneous persistent files.
>>>>> /var/cache/fred/plugins: plugins directory trees.
>>>>> /var/log: logs.
>>>>> /var/log/old/fred: compressed old logs (do you really need those?).
>>>>>
>>>>> Plus, distribution specific scripts to control the daemon (run.sh-ish).
>>>>> ___
>>>>> Devl mailing list
>>>>> Devl at freenetproject.org
>>>>> http://freenetproject.org/cgi-bin/mailman/listinfo/devl
>>>>
>>>>
>>>> ___
>>>> Devl mailing list
>>>> Devl at freenetproject.org
>>>> http://freenetproject.org/cgi-bin/mailman/listinfo/devl
>>>
>>> ___
>>> Devl mailing list
>>> Devl at freenetproject.org
>>> http://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: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120319/ea15d6b6/attachment.html>

[freenet-dev] Refactoring Freenet and Library was Re: Gun.IO and Freenet

[Marco Schulze]

On 18-03-2012 21:57, Matthew Toseland wrote:
> On Friday 16 Mar 2012 20:38:46 Marco Schulze wrote:
>> On 16-03-2012 15:13, Matthew Toseland wrote:
>>> Updating its own binaries is incompatible with the standard unix way
>>> of doing things, isn't it? Even if it's not technically a violation of
>>> FHS?
>> I'd just like to point out that this is not the case at all, specially
>> because flexibility is a major characteristic in this Unix Way of Doing
>> Stuff. Where it might be problematic, if at all, is on the package
>> management level:
>>
>> - The ugly custom installer would have to be replaced by a
>> distribution-specific package;
>> - Some distributions have special rules regarding Java packages. You'd
>> have to check those;
>>
>> You _can_ conform to the FHS without any change by being installed under
>> /opt. This will make fred accessible system-wide, so you might want to
>> check if it's ok to let multiple users delve inside the Freenet
>> directory tree. However, AFAIR, install scripts can do almost anything,
>> including creating a fred-specific user and group, and allowing
>> freenet{,-ext}.jar to be updated by that user without root privileges.
>>
>> The new directory layout might look like this:
>>
>> /etc: freenet.ini.
>> /usr/bin: shell scripts to launch and update freenet.
> This is the wrong place for a global daemon. Is apache in /usr/bin? Freenet 
> does not, and should not, run once per user with globally shared binaries. 
> And if it did, **it wouldn't be able to update them**, for security reasons - 
> you can't have multiple users running the same binary and all having write 
> access to it!
>
>> /usr/lib: native libraries.
>> /usr/lib/fred: jars. This might be dependent on the distribution.
> See above.
That's mainly a permission problem, but yes, /usr/bin is wrong.

>> /srv/fred: default download location (if system-wide daemon, ~/Downloads
>> otherwise).
>> /var/cache/fred: datastore and other miscellaneous persistent files.
>> /var/cache/fred/plugins: plugins directory trees.
>> /var/log: logs.
>> /var/log/old/fred: compressed old logs (do you really need those?).
> Yes, in many cases. Although mainly it's because with higher log levels (or 
> when unlucky), logs tend to get very big if they are not rotated and 
> compressed regularly.
>> Plus, distribution specific scripts to control the daemon (run.sh-ish).
> IMHO Freenet itself (the GUI installer jar) should install to the installing 
> user's home directory. Freenet should provide whatever is reasonably needed 
> for packages, but it's not really "our" (fred's) problem.

[freenet-dev] Logging in Fred

[Marco Schulze]

On 18-03-2012 21:50, Matthew Toseland wrote:
> On Sunday 18 Mar 2012 23:40:44 Marco Schulze wrote:
>> One thing has been bothering me: those 'if (logMINOR) Logger.minor(...',
>> and the mess that logging is inside fred. I've written a very simple
>> replacement for Logger + associated classes with the following changes:
> You're not using the java logging API?
First thing I thought, but the Java logging mechanisms are complex (more 
LoC), at least compared to what I have now. It also lacks those cute 
error()/debug() methods, so a wrapper would be needed anyway.

> The if(logMINOR) is *ABSOLUTELY VITAL* for performance. You simply cannot get 
> rid of it. Generating the strings costs significantly more CPU than the rest 
> of what Freenet does put together.
In most cases I've seen so far, either the message is constant, or is 
interpolated with one or two variables. In those cases where building a 
message to be logged is actually expensive, directly checking the logger 
state (Logger.min_severity) saves that contrived prolog used to setup 
logMINOR and logDEBUG.

If string building is really slow (possibly because some object's 
toString() is going wild), logging methods can be changed to something 
like: public void Logger.info(Object... objs), and the final string 
would only be built by the logger if it would actually use it.

>> - Log level (renamed to severity) filtering is done by Logging.log();
> Feel free to rename it. I don't see much point though unless you are trying 
> to use a standard API, which *may* be a good idea.
No special reason for the change, I just though Logger.Severity sounded 
better than Logger.LogLevel.

>> - Specific writer classes are replaced by a simple OutputStream, which
>> defaults to System.err. Formatting is also unified;
> Very bad idea. There are many excellent reasons for the complexity that is 
> FileLoggerHook. One is that if System.err is blocked (e.g. a full disk), 
> everything grinds to a halt.
Doesn't write() throw an IOException when the disk is full?

> Adequate caching is also essential, and I'm not certain whether there are 
> locking issues;
You mean, caching of log messages? Could you elaborate?

> and dropping log lines when we can't keep up rather than just slowing down 
> the rest of the node is a good thing.
Sorry, but I heavily disagree with you here. Not only dropping messages 
makes logs misleading, the output stream should either be unbuffered or 
flushed after every message. If everything is slowing down because of 
this, it is either expected (DEBUG or TRACE messages are written), or 
fred is logging too much above the default INFO threshold.

>> - Severity cases are broadened (FATAL, ERROR, WARNING, INFO, DEBUG and
>> TRACE), MINOR is mapped to DEBUG, and NORMAL is mapped to INFO;
> Using the standard classes is fine by me.
The biggest problem is that MINOR and NORMAL aren't being used the same 
way by all classes, and their use isn't exactly clear.

>> - No logging method accepts an Object parameter - hashCode() is not
>> exactly useful.
> We're not after the hashcode, we're after the class name. We need to be able 
> to filter by it, and that is essential.
The problem is disambiguation, or per-object log threshold?

>> Additionally, log rotation will be moved outside (possibly inside Node).
> Not a good idea, for reasons of locking, file handle handling, the fact that 
> you can't rename a file that is open on Windows ...
I see. A LogRotator would solve it then.

> There are GOOD REASONS for all the complexity, but feel free to tinker with 
> the API, or give specific arguments other than "this is all so complicated it 
> *ought to* be possible to do something radically simpler".
Not that it *ought to be* simpler, I just think current requirements are 
a bit exaggerated.

>> Currently, the log format is '\t'.
> We need the timestamp, in a great many cases.
In my todo list. Which object keeps track of uptime?

>
>
> ___
> Devl mailing list
> Devl at freenetproject.org
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120319/2d9ab660/attachment.html>

[freenet-dev] Coding standards

[David ‘Bombe’ Roden]

On 18.03.2012, at 19:37, Steve Dougherty wrote:

> Is this what you're looking for?
> 
> http://new-wiki.freenetproject.org/Coding_standards

In light of 3ef15c7701d666f7661cd9b58b41ae525ef32569, does toad know about 
these?


Greetings,

David

Re: [freenet-dev] Refactoring Freenet and Library was Re: Gun.IO and Freenet

[Marco Schulze]

On 18-03-2012 22:11, Ximin Luo wrote:

On 19/03/12 01:09, Ximin Luo wrote:

On 16/03/12 23:09, Marco Schulze wrote:

Well, the obvious question is 'why?'. Using /opt + /usr/bin scripts + service
scripts seems to be good enough. Either way, fred .jar paths are configurable,
the jars themselves should have 6** permissions and be owned by the fred user.
Why shouldn't autoupdate work?


/opt is not FHS.
I guess using /opt is not strict FHS, but it's commonly used for 
packages that, for some reason, can't be spread out in the filesystem.



/usr/bin is not FHS in the way that you're proposing. It should be used for us


Forgot to finish this sentence. I meant to say, /usr/bin is used for user-run
programs only. Maintenance scripts go in /usr/lib/freenet or
/usr/share/freenet, and the daemon script should be /etc/init.d/freenet.

True.


debian-staging follows FHS to as much of an extent as possible, although there
was one minor issue possibly with its use of /var/run/freenet.

"Why shouldn't autoupdate work" - if you look through how the current updater
works, it's fairly self-evident why it won't work for the package built by
debian-staging.
The question was more general: why shouldn't autoupdate work using an 
FHS layout?





An unrelated question: it seems debian-staging not only builds slightly
different jars, but are locked on specific build numbers. Why?


I haven't had time to update the submodule pointers to the latest commits and
verify that the package still works. Does this answer your question?


On 16-03-2012 17:51, Ximin Luo wrote:

We already have a layout that adheres to the FHS, see debian-staging for 
details :)

But this is only for run-time data, NOT the binaries themselves. That part is
rigid and would require much more work, because (to implement it properly)
would need to integrate well with all the various existing installers, as well
as the built-in updater.

I'll respond to the other points some other time, need to be off somewhere now.

(Theoretically it would be possible for fproxy to expose an APT repo under e.g.
localhost:/debian/ that actually gets its data from freenet, but this is
again extra work.)

X

On 16/03/12 20:38, Marco Schulze wrote:

On 16-03-2012 15:13, Matthew Toseland wrote:

Updating its own binaries is incompatible with the standard unix way of doing
things, isn't it? Even if it's not technically a violation of FHS?

I'd just like to point out that this is not the case at all, specially because
flexibility is a major characteristic in this Unix Way of Doing Stuff. Where it
might be problematic, if at all, is on the package management level:

- The ugly custom installer would have to be replaced by a
distribution-specific package;
- Some distributions have special rules regarding Java packages. You'd have to
check those;

You _can_ conform to the FHS without any change by being installed under /opt.
This will make fred accessible system-wide, so you might want to check if it's
ok to let multiple users delve inside the Freenet directory tree. However,
AFAIR, install scripts can do almost anything, including creating a
fred-specific user and group, and allowing freenet{,-ext}.jar to be updated by
that user without root privileges.

The new directory layout might look like this:

/etc: freenet.ini.
/usr/bin: shell scripts to launch and update freenet.
/usr/lib: native libraries.
/usr/lib/fred: jars. This might be dependent on the distribution.
/srv/fred: default download location (if system-wide daemon, ~/Downloads
otherwise).
/var/cache/fred: datastore and other miscellaneous persistent files.
/var/cache/fred/plugins: plugins directory trees.
/var/log: logs.
/var/log/old/fred: compressed old logs (do you really need those?).

Plus, distribution specific scripts to control the daemon (run.sh-ish).
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl



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


___
Devl mailing list
Devl@freenetproject.org
http://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 in Fred

[Nicolas Hernandez]

Hello,

It is really difficult to have a complete log system working. One solution
is to use aspects.

Is this a good idea ?

- Nicolas Hernandez
a-n - aleph-networks
*associé*
http://www.aleph-networks.com




On Mon, Mar 19, 2012 at 12:40 AM, Marco Schulze
wrote:

> One thing has been bothering me: those 'if (logMINOR) Logger.minor(...',
> and the mess that logging is inside fred. I've written a very simple
> replacement for Logger + associated classes with the following changes:
>
> - Log level (renamed to severity) filtering is done by Logging.log();
> - Specific writer classes are replaced by a simple OutputStream, which
> defaults to System.err. Formatting is also unified;
> - Severity cases are broadened (FATAL, ERROR, WARNING, INFO, DEBUG and
> TRACE), MINOR is mapped to DEBUG, and NORMAL is mapped to INFO;
> - No logging method accepts an Object parameter - hashCode() is not
> exactly useful.
>
> Additionally, log rotation will be moved outside (possibly inside Node).
>
> Currently, the log format is '\t'.
> __**_
> 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] Refactoring Freenet and Library was Re: Gun.IO and Freenet

[Marco Schulze]

On 18-03-2012 21:57, Matthew Toseland wrote:

On Friday 16 Mar 2012 20:38:46 Marco Schulze wrote:

On 16-03-2012 15:13, Matthew Toseland wrote:

Updating its own binaries is incompatible with the standard unix way
of doing things, isn't it? Even if it's not technically a violation of
FHS?

I'd just like to point out that this is not the case at all, specially
because flexibility is a major characteristic in this Unix Way of Doing
Stuff. Where it might be problematic, if at all, is on the package
management level:

- The ugly custom installer would have to be replaced by a
distribution-specific package;
- Some distributions have special rules regarding Java packages. You'd
have to check those;

You _can_ conform to the FHS without any change by being installed under
/opt. This will make fred accessible system-wide, so you might want to
check if it's ok to let multiple users delve inside the Freenet
directory tree. However, AFAIR, install scripts can do almost anything,
including creating a fred-specific user and group, and allowing
freenet{,-ext}.jar to be updated by that user without root privileges.

The new directory layout might look like this:

/etc: freenet.ini.
/usr/bin: shell scripts to launch and update freenet.

This is the wrong place for a global daemon. Is apache in /usr/bin? Freenet 
does not, and should not, run once per user with globally shared binaries. And 
if it did, **it wouldn't be able to update them**, for security reasons - you 
can't have multiple users running the same binary and all having write access 
to it!


/usr/lib: native libraries.
/usr/lib/fred: jars. This might be dependent on the distribution.

See above.

That's mainly a permission problem, but yes, /usr/bin is wrong.


/srv/fred: default download location (if system-wide daemon, ~/Downloads
otherwise).
/var/cache/fred: datastore and other miscellaneous persistent files.
/var/cache/fred/plugins: plugins directory trees.
/var/log: logs.
/var/log/old/fred: compressed old logs (do you really need those?).

Yes, in many cases. Although mainly it's because with higher log levels (or 
when unlucky), logs tend to get very big if they are not rotated and compressed 
regularly.

Plus, distribution specific scripts to control the daemon (run.sh-ish).

IMHO Freenet itself (the GUI installer jar) should install to the installing user's home 
directory. Freenet should provide whatever is reasonably needed for packages, but it's 
not really "our" (fred's) problem.

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

Re: [freenet-dev] Logging in Fred

[Marco Schulze]

On 18-03-2012 21:50, Matthew Toseland wrote:

On Sunday 18 Mar 2012 23:40:44 Marco Schulze wrote:

One thing has been bothering me: those 'if (logMINOR) Logger.minor(...',
and the mess that logging is inside fred. I've written a very simple
replacement for Logger + associated classes with the following changes:

You're not using the java logging API?
First thing I thought, but the Java logging mechanisms are complex (more 
LoC), at least compared to what I have now. It also lacks those cute 
error()/debug() methods, so a wrapper would be needed anyway.



The if(logMINOR) is *ABSOLUTELY VITAL* for performance. You simply cannot get 
rid of it. Generating the strings costs significantly more CPU than the rest of 
what Freenet does put together.
In most cases I've seen so far, either the message is constant, or is 
interpolated with one or two variables. In those cases where building a 
message to be logged is actually expensive, directly checking the logger 
state (Logger.min_severity) saves that contrived prolog used to setup 
logMINOR and logDEBUG.


If string building is really slow (possibly because some object's 
toString() is going wild), logging methods can be changed to something 
like: public void Logger.info(Object... objs), and the final string 
would only be built by the logger if it would actually use it.



- Log level (renamed to severity) filtering is done by Logging.log();

Feel free to rename it. I don't see much point though unless you are trying to 
use a standard API, which *may* be a good idea.
No special reason for the change, I just though Logger.Severity sounded 
better than Logger.LogLevel.



- Specific writer classes are replaced by a simple OutputStream, which
defaults to System.err. Formatting is also unified;

Very bad idea. There are many excellent reasons for the complexity that is 
FileLoggerHook. One is that if System.err is blocked (e.g. a full disk), 
everything grinds to a halt.

Doesn't write() throw an IOException when the disk is full?


Adequate caching is also essential, and I'm not certain whether there are 
locking issues;

You mean, caching of log messages? Could you elaborate?


and dropping log lines when we can't keep up rather than just slowing down the 
rest of the node is a good thing.
Sorry, but I heavily disagree with you here. Not only dropping messages 
makes logs misleading, the output stream should either be unbuffered or 
flushed after every message. If everything is slowing down because of 
this, it is either expected (DEBUG or TRACE messages are written), or 
fred is logging too much above the default INFO threshold.



- Severity cases are broadened (FATAL, ERROR, WARNING, INFO, DEBUG and
TRACE), MINOR is mapped to DEBUG, and NORMAL is mapped to INFO;

Using the standard classes is fine by me.
The biggest problem is that MINOR and NORMAL aren't being used the same 
way by all classes, and their use isn't exactly clear.



- No logging method accepts an Object parameter - hashCode() is not
exactly useful.

We're not after the hashcode, we're after the class name. We need to be able to 
filter by it, and that is essential.

The problem is disambiguation, or per-object log threshold?


Additionally, log rotation will be moved outside (possibly inside Node).

Not a good idea, for reasons of locking, file handle handling, the fact that 
you can't rename a file that is open on Windows ...

I see. A LogRotator would solve it then.


There are GOOD REASONS for all the complexity, but feel free to tinker with the API, or 
give specific arguments other than "this is all so complicated it *ought to* be 
possible to do something radically simpler".
Not that it *ought to be* simpler, I just think current requirements are 
a bit exaggerated.



Currently, the log format is '\t'.

We need the timestamp, in a great many cases.

In my todo list. Which object keeps track of uptime?




___
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] (no subject)

[Florent Daigniere]

It can be done differently but not using cookies :)

Anyways, that's only required if you want to change from the language you 
configured
your browser to use... not a big deal imo.

Florent

On Mon, Mar 19, 2012 at 02:33:02AM +, Ximin Luo wrote:
> Oh, right. Well if all it does is set cookies that can probably be done some
> other way. TBH I'm still in favour of having /%lang%/ in the path.
> 
> On 19/03/12 02:13, Steve Dougherty wrote:
> > Leah is correct - Florent added Javascript to set cookies for
> > determining the language served by Apache.
> > 
> > On 03/18/2012 10:04 PM, Ximin Luo wrote:
> >> I wasn't aware any previous method used javascript, but we
> >> implemented a non-javascript method quite recently that checks the
> >> client browser's Accept-Language HTTP headers. Have a look at
> >> Steve's thread (in this same mailing list) titled "Spanish
> >> Translation Deployment Complete".
> > 
> >> There is JS on the site currently but (I believe) that has nothing
> >> to do with translations.
> > 
> >> On 19/03/12 01:04, Leah Hicks wrote:
> >>> I have done my research, although I have to admit wordpress is
> >>> not perfect. If it is /really/ that big of an issue then we will
> >>> simply not use it. And yes I'm aware of the current
> >>> implementation however it uses javascript which will not run if
> >>> users have javascript disabled. If someone can find a workaround
> >>> for that I'm golden.
> >>>
> >>>
> >>> ___ 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
> 
> -- 
> GPG: 4096R/5FBBDBCE
> https://github.com/infinity0
> https://bitbucket.org/infinity0
> https://launchpad.net/~infinity0
> 



> ___
> 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] (no subject)

[Ximin Luo]

Oh, right. Well if all it does is set cookies that can probably be done some
other way. TBH I'm still in favour of having /%lang%/ in the path.

On 19/03/12 02:13, Steve Dougherty wrote:
> Leah is correct - Florent added Javascript to set cookies for
> determining the language served by Apache.
> 
> On 03/18/2012 10:04 PM, Ximin Luo wrote:
>> I wasn't aware any previous method used javascript, but we
>> implemented a non-javascript method quite recently that checks the
>> client browser's Accept-Language HTTP headers. Have a look at
>> Steve's thread (in this same mailing list) titled "Spanish
>> Translation Deployment Complete".
> 
>> There is JS on the site currently but (I believe) that has nothing
>> to do with translations.
> 
>> On 19/03/12 01:04, Leah Hicks wrote:
>>> I have done my research, although I have to admit wordpress is
>>> not perfect. If it is /really/ that big of an issue then we will
>>> simply not use it. And yes I'm aware of the current
>>> implementation however it uses javascript which will not run if
>>> users have javascript disabled. If someone can find a workaround
>>> for that I'm golden.
>>>
>>>
>>> ___ 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

-- 
GPG: 4096R/5FBBDBCE
https://github.com/infinity0
https://bitbucket.org/infinity0
https://launchpad.net/~infinity0

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120319/b147626d/attachment.pgp>

Re: [freenet-dev] Website Redesign?

[Nicolas Hernandez]

Sometimes, the 2.7% of users could represents 80% of Freenet users :-)

Imagine that in some countries (*stan and lots of arabish/farsi langages
countries) they are using the defaut OS and Browser (XP+IE7). This is not
lots of people, but they needs help.

For information


Rgds
- Nicolas Hernandez
a-n - aleph-networks
*associé*
http://www.aleph-networks.com




On Mon, Mar 19, 2012 at 2:35 AM, Leah Hicks  wrote:

> It would seem that, according to the W3schools browser stats page, 2.7% of
> all users (in february) used IE7. So I think we're good on that part. Even
> if people do use that browser I highly doubt these are going to be people
> visiting freenet :p
>
> On Sun, Mar 18, 2012 at 8:04 PM, Matthew Toseland <
> t...@amphibian.dyndns.org> wrote:
>
>> On Sunday 18 Mar 2012 14:37:14 Ian Clarke wrote:
>> > Leah,
>> >
>> > That sounds great, our last redesign was indeed several years ago, and I
>> > agree that the site is probably overdue for a facelift.
>> >
>> > One thing though, I think we will need to support Internet Explorer 7,
>> > which I believe doesn't support some of the newer web standards you
>> > mention.  It's ok if the site doesn't look quite as good in IE7, but it
>> > should at least work.  (The good news is that the upcoming IE10 does
>> > support these things, so hopefully we won't have to worry about it for
>> too
>> > much longer).
>>
>> Why do we need IE7 support? Does anyone still use it? Even on Windows XP?
>>
>> ___
>> Devl mailing list
>> Devl@freenetproject.org
>> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
>>
>
>
>
> --
> -- *Leah Hicks*
> *
> *
> http://kori-designs.com
> *http://kanjidaisuki.com*
>
>
> ___
> 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] (no subject)

[Ximin Luo]

I wasn't aware any previous method used javascript, but we implemented a
non-javascript method quite recently that checks the client browser's
Accept-Language HTTP headers. Have a look at Steve's thread (in this same
mailing list) titled "Spanish Translation Deployment Complete".

There is JS on the site currently but (I believe) that has nothing to do with
translations.

On 19/03/12 01:04, Leah Hicks wrote:
> I have done my research, although I have to admit wordpress is not perfect. If
> it is /really/ that big of an issue then we will simply not use it. And yes 
> I'm
> aware of the current implementation however it uses javascript which will not
> run if users have javascript disabled. If someone can find a workaround for
> that I'm golden.
> 
> 
> ___
> Devl mailing list
> Devl at freenetproject.org
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl


-- 
GPG: 4096R/5FBBDBCE
https://github.com/infinity0
https://bitbucket.org/infinity0
https://launchpad.net/~infinity0

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120319/8189e481/attachment.pgp>

[freenet-dev] Refactoring Freenet and Library was Re: Gun.IO and Freenet

[Ximin Luo]

ould make Library's code a lot simpler. (The
dependency management that is, not necessarily the cancellation.) We talked
about it a while back but I never really sat down to solve the issue.

>> - group tasks into related categories so one group doesn't affect the other.
>> (e.g. tasks for the group "Library/b-tree-write/index-" won't starve the
>> resources of group "WoT/background-trust-calculation")
> 
> If you are scheduling tasks in a limited pool this makes sense. Freenet 
> generally doesn't do this because most tasks are either CPU intensive and 
> complete quickly, or are blocking / I/O intensive and take ages but don't use 
> much resources. Also many tasks are latency sensitive. And on modern JVMs, 
> lots of threads are cheap, although memory is an issue, we do need to keep it 
> down if possible ...

There is a thread limit. You don't want plugin A to hog 90% threads and leave
the other 10% to everything else.

>>
>> ## Library algorithm
>>
>> You keep talking about specific things like "only fetching a single block in
>> the common case". Nobody else knows what this means, even I don't (off the 
>> top
>> of my head) because I haven't looked at the code in several years.
> 
> I quoted a bug explaining this.
> 
>>
>> On 15/03/12 13:03, Matthew Toseland wrote:
>>>
>>> https://bugs.freenetproject.org/view.php?id=4066
>>> And categories: 
>>> library
>>> b-tree-index
>>>
> 
> Back to your mail:
>>
>> Having a proper specification that separates different concerns out into 
>> layers
>> (e.g. logical structure; on-freenet structure; data format; network
>> performance) helps greatly to make the algorithm understandable to other
>> people, and yourself if you don't work on it for ages.
>>
>> If, instead of saying "only fetch a single block" you say "the on-freenet
>> structure format has persistence issues, and here's a potential solution", 
>> it's
>> easier for other people to understand what you mean.
> 
> "only fetching a single block in the common case" is a specific mechanism 
> (relying on significant format changes) for achieving the goal "radical 
> performance optimisation for the average case for library searches". And I 
> have explained it on the bug I quoted.
> 
> However I agree documentation is a good idea especially in Library. I agree 
> that layering is good. The disagreement comes when the layering is impeding 
> major performance optimisations - then it needs to be altered.
>>
>> ## config management
>>
>> Code for read/writing the config in embedded inside the classes they control,
>> which clutters up the code and makes it confusing. Config code should be
>> separated from the actual application. It would also be nice if this was
>> exposed to plugins.
> 
> Separated how exactly? You want to call getters via reflection, like java 
> beans? It is always going to be the case that changing some settings on the 
> fly will be somewhat involved and require methods for it; the classes are 
> only one way to write such an interface, I'm open to other mechanisms given 
> that config happens very infrequently.
>>
>> Being a daemon is why the current config system is NOT SUFFICIENT. I need to 
>> be
>> able to lock certain config settings, such as where to keep the datastore /
>> run-time files themselves, to conform to the FHS. It's best that such 
>> settings
>> are kept in a separate read-only file. The current system only reads one 
>> file,
>> freenet.ini.
> 
> Sounds to me like that could be achieved with some fairly small changes; I 
> still don't see what the problem is.

Adding an "#include" mechanism for config files whilst supporting "write" at
the same time is not a "small change". Think about it.

(This is why .gitconfig doesn't have #include whereas .hgrc does.)

>>
>> Updating its own binaries is not a problem if freenet knows where the 
>> binaries
>> are. The current installer puts them in a rigid place, however this is
>> incompatible with FHS.
> 
> A rigid place? I don't follow. If you are doing FHS you are using a package; 
> the installer is never going to comply with FHS as, apart from anything else, 
> it shouldn't be run as root!
> 

The updater (UpdateDeployContext) makes some very specific assumptions as to
the locations of the jars, and this method doesn't generalise to non-jar files.
It also assumes wrapper.conf is in the current directory.

> Updating its own binaries is incompatible with the standard unix way of doing 
> things, isn't it? Even if it's not technically a violation of FHS?
> 
> 
> 
> ___
> Devl mailing list
> Devl at freenetproject.org
> http://freenetproject.org/cgi-bin/mailman/listinfo/devl


-- 
GPG: 4096R/5FBBDBCE
https://github.com/infinity0
https://bitbucket.org/infinity0
https://launchpad.net/~infinity0

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120319/2cfc71e5/attachment.pgp>

[freenet-dev] Logging in Fred

[Matthew Toseland]

On Monday 19 Mar 2012 00:50:33 Matthew Toseland wrote:
> On Sunday 18 Mar 2012 23:40:44 Marco Schulze wrote:
...
> > - No logging method accepts an Object parameter - hashCode() is not 
> > exactly useful.
> 
> We're not after the hashcode, we're after the class name. We need to be able 
> to filter by it, and that is essential.

Oh, now I see what you mean. Including the object in the generated string is 
quite often important when you are tracing a sequence of events when something 
strange has happened. For the same reason that, at the lowest level of 
debugging logging, it is often necessary to include request UID's.
-- 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: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120319/648f2a7d/attachment.pgp>

[freenet-dev] Spanish Translation Deployment Complete

[Matthew Toseland]

On Sunday 18 Mar 2012 02:10:09 Steve Dougherty wrote:
> Hi all,
> 
> infinity0, nextgens and I completed some work on the
> freenetproject.org webserver today. We made progress on a more robust
> backup system, set up separation between the vhosts, and deployed the
> updated Spanish translation with Apache's mod_negotiate handling
> preferred language detection and links at the top of all pages to
> switch between them at will. This deploy reflects an update to the
> website deploy system which hopefully makes it much more
> straightforward to use. It is documented here:
> https://github.com/freenet/website-official/blob/master/README.md

It should be made clearer that you shouldn't push anything to git from osprey. 
For security reasons, osprey should only pull and deploy.
-- 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: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120319/2a7521c5/attachment.pgp>

[freenet-dev] Refactoring Freenet and Library was Re: Gun.IO and Freenet

[Ximin Luo]

On 19/03/12 01:09, Ximin Luo wrote:
> On 16/03/12 23:09, Marco Schulze wrote:
>> Well, the obvious question is 'why?'. Using /opt + /usr/bin scripts + service
>> scripts seems to be good enough. Either way, fred .jar paths are 
>> configurable,
>> the jars themselves should have 6** permissions and be owned by the fred 
>> user.
>> Why shouldn't autoupdate work?
>>
> 
> /opt is not FHS.
> /usr/bin is not FHS in the way that you're proposing. It should be used for us
> 

Forgot to finish this sentence. I meant to say, /usr/bin is used for user-run
programs only. Maintenance scripts go in /usr/lib/freenet or
/usr/share/freenet, and the daemon script should be /etc/init.d/freenet.

> debian-staging follows FHS to as much of an extent as possible, although there
> was one minor issue possibly with its use of /var/run/freenet.
> 
> "Why shouldn't autoupdate work" - if you look through how the current updater
> works, it's fairly self-evident why it won't work for the package built by
> debian-staging.
> 
>> An unrelated question: it seems debian-staging not only builds slightly
>> different jars, but are locked on specific build numbers. Why?
>>
> 
> I haven't had time to update the submodule pointers to the latest commits and
> verify that the package still works. Does this answer your question?
> 
>> On 16-03-2012 17:51, Ximin Luo wrote:
>>> We already have a layout that adheres to the FHS, see debian-staging for 
>>> details :)
>>>
>>> But this is only for run-time data, NOT the binaries themselves. That part 
>>> is
>>> rigid and would require much more work, because (to implement it properly)
>>> would need to integrate well with all the various existing installers, as 
>>> well
>>> as the built-in updater.
>>>
>>> I'll respond to the other points some other time, need to be off somewhere 
>>> now.
>>>
>>> (Theoretically it would be possible for fproxy to expose an APT repo under 
>>> e.g.
>>> localhost:/debian/ that actually gets its data from freenet, but this is
>>> again extra work.)
>>>
>>> X
>>>
>>> On 16/03/12 20:38, Marco Schulze wrote:
>>>> On 16-03-2012 15:13, Matthew Toseland wrote:
>>>>> Updating its own binaries is incompatible with the standard unix way of 
>>>>> doing
>>>>> things, isn't it? Even if it's not technically a violation of FHS?
>>>> I'd just like to point out that this is not the case at all, specially 
>>>> because
>>>> flexibility is a major characteristic in this Unix Way of Doing Stuff. 
>>>> Where it
>>>> might be problematic, if at all, is on the package management level:
>>>>
>>>> - The ugly custom installer would have to be replaced by a
>>>> distribution-specific package;
>>>> - Some distributions have special rules regarding Java packages. You'd 
>>>> have to
>>>> check those;
>>>>
>>>> You _can_ conform to the FHS without any change by being installed under 
>>>> /opt.
>>>> This will make fred accessible system-wide, so you might want to check if 
>>>> it's
>>>> ok to let multiple users delve inside the Freenet directory tree. However,
>>>> AFAIR, install scripts can do almost anything, including creating a
>>>> fred-specific user and group, and allowing freenet{,-ext}.jar to be 
>>>> updated by
>>>> that user without root privileges.
>>>>
>>>> The new directory layout might look like this:
>>>>
>>>> /etc: freenet.ini.
>>>> /usr/bin: shell scripts to launch and update freenet.
>>>> /usr/lib: native libraries.
>>>> /usr/lib/fred: jars. This might be dependent on the distribution.
>>>> /srv/fred: default download location (if system-wide daemon, ~/Downloads
>>>> otherwise).
>>>> /var/cache/fred: datastore and other miscellaneous persistent files.
>>>> /var/cache/fred/plugins: plugins directory trees.
>>>> /var/log: logs.
>>>> /var/log/old/fred: compressed old logs (do you really need those?).
>>>>
>>>> Plus, distribution specific scripts to control the daemon (run.sh-ish).
>>>> ___
>>>> Devl mailing list
>>>> Devl at freenetproject.org
>>>> http://freenetproject.org/cgi-bin/mailman/listinfo/devl
>>>
>>>
>>>
>>> ___
>>> Devl mailing list
>>> Devl at freenetproject.org
>>> http://freenetproject.org/cgi-bin/mailman/listinfo/devl
>>
>>
>> ___
>> Devl mailing list
>> Devl at freenetproject.org
>> http://freenetproject.org/cgi-bin/mailman/listinfo/devl
> 
> 
> 
> 
> ___
> Devl mailing list
> Devl at freenetproject.org
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl


-- 
GPG: 4096R/5FBBDBCE
https://github.com/infinity0
https://bitbucket.org/infinity0
https://launchpad.net/~infinity0

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120319/fc7bd95e/attachment.pgp>

[freenet-dev] Refactoring Freenet and Library was Re: Gun.IO and Freenet

[Ximin Luo]

On 16/03/12 23:09, Marco Schulze wrote:
> Well, the obvious question is 'why?'. Using /opt + /usr/bin scripts + service
> scripts seems to be good enough. Either way, fred .jar paths are configurable,
> the jars themselves should have 6** permissions and be owned by the fred user.
> Why shouldn't autoupdate work?
> 

/opt is not FHS.
/usr/bin is not FHS in the way that you're proposing. It should be used for us

debian-staging follows FHS to as much of an extent as possible, although there
was one minor issue possibly with its use of /var/run/freenet.

"Why shouldn't autoupdate work" - if you look through how the current updater
works, it's fairly self-evident why it won't work for the package built by
debian-staging.

> An unrelated question: it seems debian-staging not only builds slightly
> different jars, but are locked on specific build numbers. Why?
> 

I haven't had time to update the submodule pointers to the latest commits and
verify that the package still works. Does this answer your question?

> On 16-03-2012 17:51, Ximin Luo wrote:
>> We already have a layout that adheres to the FHS, see debian-staging for 
>> details :)
>>
>> But this is only for run-time data, NOT the binaries themselves. That part is
>> rigid and would require much more work, because (to implement it properly)
>> would need to integrate well with all the various existing installers, as 
>> well
>> as the built-in updater.
>>
>> I'll respond to the other points some other time, need to be off somewhere 
>> now.
>>
>> (Theoretically it would be possible for fproxy to expose an APT repo under 
>> e.g.
>> localhost:/debian/ that actually gets its data from freenet, but this is
>> again extra work.)
>>
>> X
>>
>> On 16/03/12 20:38, Marco Schulze wrote:
>>> On 16-03-2012 15:13, Matthew Toseland wrote:
>>>> Updating its own binaries is incompatible with the standard unix way of 
>>>> doing
>>>> things, isn't it? Even if it's not technically a violation of FHS?
>>> I'd just like to point out that this is not the case at all, specially 
>>> because
>>> flexibility is a major characteristic in this Unix Way of Doing Stuff. 
>>> Where it
>>> might be problematic, if at all, is on the package management level:
>>>
>>> - The ugly custom installer would have to be replaced by a
>>> distribution-specific package;
>>> - Some distributions have special rules regarding Java packages. You'd have 
>>> to
>>> check those;
>>>
>>> You _can_ conform to the FHS without any change by being installed under 
>>> /opt.
>>> This will make fred accessible system-wide, so you might want to check if 
>>> it's
>>> ok to let multiple users delve inside the Freenet directory tree. However,
>>> AFAIR, install scripts can do almost anything, including creating a
>>> fred-specific user and group, and allowing freenet{,-ext}.jar to be updated 
>>> by
>>> that user without root privileges.
>>>
>>> The new directory layout might look like this:
>>>
>>> /etc: freenet.ini.
>>> /usr/bin: shell scripts to launch and update freenet.
>>> /usr/lib: native libraries.
>>> /usr/lib/fred: jars. This might be dependent on the distribution.
>>> /srv/fred: default download location (if system-wide daemon, ~/Downloads
>>> otherwise).
>>> /var/cache/fred: datastore and other miscellaneous persistent files.
>>> /var/cache/fred/plugins: plugins directory trees.
>>> /var/log: logs.
>>> /var/log/old/fred: compressed old logs (do you really need those?).
>>>
>>> Plus, distribution specific scripts to control the daemon (run.sh-ish).
>>> ___
>>> Devl mailing list
>>> Devl at freenetproject.org
>>> http://freenetproject.org/cgi-bin/mailman/listinfo/devl
>>
>>
>>
>> ___
>> Devl mailing list
>> Devl at freenetproject.org
>> http://freenetproject.org/cgi-bin/mailman/listinfo/devl
> 
> 
> ___
> Devl mailing list
> Devl at freenetproject.org
> http://freenetproject.org/cgi-bin/mailman/listinfo/devl


-- 
GPG: 4096R/5FBBDBCE
https://github.com/infinity0
https://bitbucket.org/infinity0
https://launchpad.net/~infinity0

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120319/da883b28/attachment.pgp>

[freenet-dev] Website Redesign?

[Matthew Toseland]

On Sunday 18 Mar 2012 14:37:14 Ian Clarke wrote:
> Leah,
> 
> That sounds great, our last redesign was indeed several years ago, and I
> agree that the site is probably overdue for a facelift.
> 
> One thing though, I think we will need to support Internet Explorer 7,
> which I believe doesn't support some of the newer web standards you
> mention.  It's ok if the site doesn't look quite as good in IE7, but it
> should at least work.  (The good news is that the upcoming IE10 does
> support these things, so hopefully we won't have to worry about it for too
> much longer).

Why do we need IE7 support? Does anyone still use it? Even on Windows XP?
-- 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: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120319/a7540ebb/attachment.pgp>

[freenet-dev] (no subject)

[Ximin Luo]

On 19/03/12 00:41, Leah Hicks wrote:
> As far as I'm aware wordpress is the most secure content management system
> there is, ie there's no way really for anybody to successfully use an SQL
> injection. There are vulnerabilities in certain plugins, but as far as I know
> not wordpress itself. I was hoping though it would spare the trouble of
> updating the news, the translations and what not. There is also a plugin for
> making wordpress display static html / php pages.
> 

You should do some research before making statements like this.

We have an existing method for deploying different translations without having
to duplicate the entire site. It's not perfect, but much safer than running a
live installation of wordpress. Other people (Steve?) can fill in the details
as I don't remember right off the top of my head.

> I'm not overly familiar with generation from templates, but I can make the 
> base
> template and you (X) or somebody else can possibly cover the generation end of
> it or possibly use existing code with slight modifications.
> 
> It's just the issue at hand is deploying the different translations without
> having to duplicate the entire site or using javascript. The language plugin
> delivers the content via PHP which all browsers have support for.
> 
> 
> ___
> Devl mailing list
> Devl at freenetproject.org
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl


-- 
GPG: 4096R/5FBBDBCE
https://github.com/infinity0
https://bitbucket.org/infinity0
https://launchpad.net/~infinity0

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120319/4b28f683/attachment.pgp>

[freenet-dev] Refactoring Freenet and Library was Re: Gun.IO and Freenet

[Matthew Toseland]

On Friday 16 Mar 2012 20:38:46 Marco Schulze wrote:
> On 16-03-2012 15:13, Matthew Toseland wrote:
> > Updating its own binaries is incompatible with the standard unix way 
> > of doing things, isn't it? Even if it's not technically a violation of 
> > FHS?
> 
> I'd just like to point out that this is not the case at all, specially 
> because flexibility is a major characteristic in this Unix Way of Doing 
> Stuff. Where it might be problematic, if at all, is on the package 
> management level:
> 
> - The ugly custom installer would have to be replaced by a 
> distribution-specific package;
> - Some distributions have special rules regarding Java packages. You'd 
> have to check those;
> 
> You _can_ conform to the FHS without any change by being installed under 
> /opt. This will make fred accessible system-wide, so you might want to 
> check if it's ok to let multiple users delve inside the Freenet 
> directory tree. However, AFAIR, install scripts can do almost anything, 
> including creating a fred-specific user and group, and allowing 
> freenet{,-ext}.jar to be updated by that user without root privileges.
> 
> The new directory layout might look like this:
> 
> /etc: freenet.ini.
> /usr/bin: shell scripts to launch and update freenet.

This is the wrong place for a global daemon. Is apache in /usr/bin? Freenet 
does not, and should not, run once per user with globally shared binaries. And 
if it did, **it wouldn't be able to update them**, for security reasons - you 
can't have multiple users running the same binary and all having write access 
to it!

> /usr/lib: native libraries.
> /usr/lib/fred: jars. This might be dependent on the distribution.

See above.

> /srv/fred: default download location (if system-wide daemon, ~/Downloads 
> otherwise).
> /var/cache/fred: datastore and other miscellaneous persistent files.
> /var/cache/fred/plugins: plugins directory trees.
> /var/log: logs.
> /var/log/old/fred: compressed old logs (do you really need those?).

Yes, in many cases. Although mainly it's because with higher log levels (or 
when unlucky), logs tend to get very big if they are not rotated and compressed 
regularly.
> 
> Plus, distribution specific scripts to control the daemon (run.sh-ish).

IMHO Freenet itself (the GUI installer jar) should install to the installing 
user's home directory. Freenet should provide whatever is reasonably needed for 
packages, but it's not really "our" (fred's) problem.
-- 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: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120319/a9b0d0f2/attachment.pgp>

[freenet-dev] OSGi

[Matthew Toseland]

On Sunday 18 Mar 2012 17:53:29 Marco Schulze wrote:
> So, it's ok to remove all references to it (a variable and two methods) 
> from master? Right now it's cruft.

Ask saces.
> 
> On 18-03-2012 14:43, Nicolas Hernandez wrote:
> > not 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: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120319/d178a716/attachment.pgp>

[freenet-dev] Logging in Fred

[Matthew Toseland]

On Sunday 18 Mar 2012 23:40:44 Marco Schulze wrote:
> One thing has been bothering me: those 'if (logMINOR) Logger.minor(...', 
> and the mess that logging is inside fred. I've written a very simple 
> replacement for Logger + associated classes with the following changes:

You're not using the java logging API?

The if(logMINOR) is *ABSOLUTELY VITAL* for performance. You simply cannot get 
rid of it. Generating the strings costs significantly more CPU than the rest of 
what Freenet does put together.
> 
> - Log level (renamed to severity) filtering is done by Logging.log();

Feel free to rename it. I don't see much point though unless you are trying to 
use a standard API, which *may* be a good idea.

> - Specific writer classes are replaced by a simple OutputStream, which 
> defaults to System.err. Formatting is also unified;

Very bad idea. There are many excellent reasons for the complexity that is 
FileLoggerHook. One is that if System.err is blocked (e.g. a full disk), 
everything grinds to a halt. Adequate caching is also essential, and I'm not 
certain whether there are locking issues; and dropping log lines when we can't 
keep up rather than just slowing down the rest of the node is a good thing.

> - Severity cases are broadened (FATAL, ERROR, WARNING, INFO, DEBUG and 
> TRACE), MINOR is mapped to DEBUG, and NORMAL is mapped to INFO;

Using the standard classes is fine by me.

> - No logging method accepts an Object parameter - hashCode() is not 
> exactly useful.

We're not after the hashcode, we're after the class name. We need to be able to 
filter by it, and that is essential.
> 
> Additionally, log rotation will be moved outside (possibly inside Node).

Not a good idea, for reasons of locking, file handle handling, the fact that 
you can't rename a file that is open on Windows ... There are GOOD REASONS for 
all the complexity, but feel free to tinker with the API, or give specific 
arguments other than "this is all so complicated it *ought to* be possible to 
do something radically simpler".
> 
> Currently, the log format is '\t'.

We need the timestamp, in a great many cases.
-- 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: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120319/b20b27e0/attachment.pgp>

Re: [freenet-dev] Coding standards

[David ‘Bombe’ Roden]

On 18.03.2012, at 19:37, Steve Dougherty wrote:

> Is this what you're looking for?
> 
> http://new-wiki.freenetproject.org/Coding_standards

In light of 3ef15c7701d666f7661cd9b58b41ae525ef32569, does toad know about 
these?


Greetings,

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

[freenet-dev] (no subject)

[Ximin Luo]

We are unlikely to deploy wordpress on the main website, for security reasons.
Sorry :(

The main website is not going to be that big anyways, so I don't think we
really need a content management system. The vast majority of content should go
on the wiki (new-wiki.freenetproject.org).

Our current approach (for the main website) is to pre-generate static HTML
pages from various templates. If wordpress has some sort of templating language
that you're familiar with, we could look into switching to that. I've done
something similar based on the django templating language before.

X

On 18/03/12 23:37, Leah Hicks wrote:
> I've attached a photo of a rough draft of the site drawn out on paper. The
> position of the elements doesn't have to be where I've placed them, but it
> tends to look best in that order. It's called an "F" layout - people, when,
> browsing a website, tend to read left to right, top to bottom (looks like an
> F), so it's important to get the message out / bragging points out at the top
> of the layout because they will obviously read that first. This is the biggest
> aesthetic change to the layout. As for colors and what not I'm undecided. 
> 
> At the top is a nivoSlider. I love nivoSliders (I have one on my own site near
> the bottom). It's pretty easy to link external buttons to the slider, which is
> the point of the buttons below the slider in the picture, although I might
> change that around to not use the buttons at all. Nivoslider works flawlessly
> in standards compliant browsers, however it doesn't exactly gracefully degrade
> in IE and so forth. I'll make a point to use IE conditional tags to hide the
> slider and change the layout to look more suitable for its poor rendering
> capabilities.
> 
> I'm also suggesting to use wordpress as a content management system for the
> site - it's rather easy to install, easy to update, is FREE, and I there are a
> separate language plugins, likethis one
> <http://wordpress.org/extend/plugins/xlanguage/>. I also have experience in
> designing wordpress sites so that's a big plus for me ;)
> 
> Here's the image: [link]
> <http://img845.imageshack.us/img845/3003/freenetidea0001.jpg>
> 
> 
> ___
> Devl mailing list
> Devl at freenetproject.org
> https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl


-- 
GPG: 4096R/5FBBDBCE
https://github.com/infinity0
https://bitbucket.org/infinity0
https://launchpad.net/~infinity0

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20120319/068fc286/attachment.pgp>