I need to fix some string literals that are too long and I have done
some extra cleaning up. If there's something else I can take care of,
let me know. I plan on finishing up this weekend and I can give you a
signal (by pull request comment or email) to let you know I am done.
Some more responses below ...
Okay, let me know what you find. I did not yet create the pull request
for the source repo. That one's still to come.
Please do that at if you're ready for it. I want to build the IRC libs
myself before the binaries go into the trunk.
I have made an request to add the changes w.r.t. custom SSLContext to
upstream. I haven't heard from them yet. So up to now irc-api = latest
snapshot + modification for custom SSLContext.
Okay, let's see what comes out of this. If really necessary, we'll keep our
own branch for this modification.
Also, and related to my earlier question about the formatter, do you
allow string literals to be longer than 80 chars? Otherwise I have to
concatenate but given your earlier remark, that would also not be
As much as I personally dislike it: they need to be split up.
Okay, so I still need to change those literals.
It's probably weekend before I have a decent amount of time to do these
kinds of things.
I'm not sure if you read my previous messages as I didn't get a reply
(AFAIK) ... doesn't really matter though.
I think it simply got under the carpet, sorry!
Actually, I meant this for Emil
Small update: I cleaned up my personal fork which is also in an existing
pull request. Currently, the pull request should only contain
modifications in the following areas:
I'm confused now in which branch you're working: cobratbq/master or
cobratbq/ircpi? Should I only check the pull request 16 only?
Yes, I moved back to master once I started preparing for a possible
merge. So just ignore all other branches. They're either old or in
preparation for some larger change.
Pull Request #16 is still valid as it also includes new commits.
- config files (classpath, project, build file),
- IRC protocol implementation,
- IRC reggwiz gui code
There should not be any modification to generic Jitsi infrastructure
anymore, since almost everything was already provided in separate
patches and integrated some time ago and I cleaned up the one remaining
I am not keen on putting if-statements around logging method
calls, since that feels like a level of micro-optimization I am not yet
ready for. So, let me know if you guys want me to, but I prefer to keep
it simple for now.
That really depends on what you're logging. A simple log.error("room " +
roomname) is okay, but log.trace("bla " + o.toString()) where o.toString()
creates a StringBuilder and possibly calls toString() on child objects is
not. Especially not when the log statements is called often (i.e. in a
loop). While it is micro-optimization, it is a very common and well
Right, sure. I was actually referring specifically to still being
experimental. Anyways, I put in a FIXME so I won't forget when I am
So, how do you want to do the big blog-o-change? Are you going to use
the pull request, or do you want me to provide the changes in some other
If the pull request is up to date, I'm going for it.
This thing seems to grow with new commits, so yeah.
dev mailing list
Unsubscribe instructions and other list options:
On 03/04/2014 08:58 PM, Ingo Bauersachs wrote: