--- Log for 06.10.115  Server: sinisalo.freenode.net  Channel: #rockbox
--- Nick: logbot-  Version: Dancer V4.16  Started: 19 days and 20 hours ago

00.37.12 ***     Saving seen data "./dancer.seen"
00.56.38 Quit    pamaury (Remote host closed the connection)
01.01.56 Quit    FSanches (Quit: Leaving.)
01.03.51 Quit    ender (Quit: Politicians are like sperm. One in a million turns out to be an actual human being.)
02.15.56 Join    chrisb [0] (~chrisb@pool-71-175-244-208.phlapa.east.verizon.net)
02.25.07 Quit    chrisb (Ping timeout: 256 seconds)
02.37.14 ***     Saving seen data "./dancer.seen"
02.40.02 Join    FSanches [0] (~felipe@2804:14c:37:268b:41af:6fd7:e9a1:15fc)
02.52.28 Join    chrisb [0] (~chrisb@pool-71-175-244-208.phlapa.east.verizon.net)
02.52.34 #       <jtdesigns01> hey guys, is there a way to turn down the time i have to hold the power button to force my fuze+ off?
03.00.38 Join    Strife89 [0] (~Strife89@adsl-98-80-221-246.mcn.bellsouth.net)
03.13.41 Quit    chrisb (Ping timeout: 246 seconds)
04.36.49 Join    cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs)
04.37.18 ***     Saving seen data "./dancer.seen"
05.09.59 Quit    cmhobbs (Ping timeout: 255 seconds)
05.25.56 Join    rela [0] (~x@pdpc/supporter/active/rela)
05.28.44 Quit    jtdesigns01 (Quit: Leaving)
05.37.53 Quit    [7] (Disconnected by services)
05.38.03 Join    TheSeven [0] (~quassel@rockbox/developer/TheSeven)
06.37.20 ***     Saving seen data "./dancer.seen"
06.47.03 Quit    Strife89 (Ping timeout: 244 seconds)
07.02.56 Quit    kugel (Ping timeout: 255 seconds)
07.02.57 Quit    nosa-j (Ping timeout: 246 seconds)
07.03.04 Join    kugel [0] (~kugel@ip5b42be9b.dynamic.kabel-deutschland.de)
07.03.08 Quit    kugel (Changing host)
07.03.08 Join    kugel [0] (~kugel@rockbox/developer/kugel)
07.03.10 Quit    derf (Ping timeout: 246 seconds)
07.03.18 Quit    Jinx (Ping timeout: 246 seconds)
07.03.37 Join    evilnick_ [0] (~evilnick@d54C3417E.access.telenet.be)
07.04.00 Quit    evilnick (Ping timeout: 265 seconds)
07.04.28 Quit    chardy (Ping timeout: 265 seconds)
07.04.33 Quit    shmibs (Read error: Connection reset by peer)
07.04.43 Join    shmibs [0] (~shmibs@shmibbles.me)
07.05.00 Join    derf [0] (~derf@static-108-18-126-14.washdc.fios.verizon.net)
07.05.26 Quit    user890104 (Ping timeout: 265 seconds)
07.06.17 Join    nosa-j [0] (~m00k@cpe-24-74-14-251.carolina.res.rr.com)
07.08.10 Join    user890104 [0] (Venci@unaffiliated/user890104)
07.09.38 Join    chardy [0] (chxr@procasur.inc.cl)
07.09.50 Join    Jinx [0] (Dojo@unaffiliated/jinx)
07.36.17 Join    CUP_GOD [0] (~clam@c-73-140-15-235.hsd1.wa.comcast.net)
07.36.29 #       <CUP_GOD> Question about conributing to the codebase
07.36.41 #       <CUP_GOD> I see you guys use mostly C, would C++ be acceptable?
08.13.09 Join    wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl)
08.26.03 Join    ender` [0] (krneki@foo.eternallybored.org)
08.33.34 Quit    FSanches (Quit: Leaving.)
08.37.25 ***     Saving seen data "./dancer.seen"
08.49.15 Join    petur [0] (~petur@rockbox/developer/petur)
09.14.48 #       <utrack> CUP_GOD: I'm not a rbdev, but I guess C++ won't work - it requires exceptions and vfuncs which would add overhead to the firmware size
09.15.36 #       <utrack> CUP_GOD: that is, if you're sure it's C only :) I'm just hacking around, didnt see the whole code
09.20.49 Quit    CUP_GOD (Ping timeout: 240 seconds)
09.34.29 Quit    JanC (Read error: Connection reset by peer)
09.50.40 Join    JanC [0] (~janc@lugwv/member/JanC)
10.00.38 #       <gevaerts> Correct. We don't have any C++ infrastructure in place
10.04.19 Quit    soap (Read error: Connection reset by peer)
10.04.49 Join    soap [0] (~soap@rockbox/staff/soap)
10.37.27 ***     Saving seen data "./dancer.seen"
10.41.18 Join    pamaury [0] (~quassel@rockbox/developer/pamaury)
10.48.40 Join    einhirn [0] (~Miranda@p4FC10A4E.dip0.t-ipconnect.de)
11.01.18 #       <pamaury> jtdesigns01bot: yes but you need to recompile rockbox. But the poweroff delay is already quite small in ymy opinion
11.02.30 Quit    Hadaka (Ping timeout: 256 seconds)
11.03.57 #       <gevaerts> Hmmm
11.04.12 #       <gevaerts> That's the normal poweroff, not the force thing
11.08.55 #       <pamaury> ah I misread
11.09.03 #       <pamaury> not it cannot be changed indeed
11.14.36 Quit    yuriks (Ping timeout: 246 seconds)
11.14.57 Join    Hadaka [0] (~naked@naked.iki.fi)
11.22.39 #       <wodz> pamaury: Where in qeditor is scanning for connected devices  implemented.
11.22.54 #       <pamaury> backend.cpp iirc why ?
11.23.53 #       <pamaury> in HWStubBackendHelper
11.26.35 #       <wodz> pamaury: I am thinking in moving this to hwstub_server and extend TCP protocol to return the list. So make hwstub_server true backend
11.26.35 Quit    pamaury (Remote host closed the connection)
11.27.28 Join    pamaury [0] (~quassel@rockbox/developer/pamaury)
11.29.03 #       <pamaury> wodz: sounds fine
11.31.13 #       <pamaury> I think you should build up on g#1217
11.31.25 #       <fs-bluebot> 3Gerrit review #1217 at http://gerrit.rockbox.org/r/1217 : 3hwstub: add JZ support, refactor code, fix related tools (qeditor, hwstub tools) by Amaury Pouly
11.32.51 #       <wodz> pamaury: sure
11.33.58 #       <pamaury> out of curiosity, do you plan to make it possible for hwstub_server to relay to another TCP server ? In other words, will your hwstub_server handle any kind of devices (usb, tcp and potentially mode in the future) ?
11.36.12 #       <wodz> pamaury: I don't think this is desirable. You can select remote hswtub_server instance in client, don't you?
11.37.40 #       <pamaury> but imagine the case where you want to do some work on both a remote device and a local device, then it's impossible
11.38.22 #       <pamaury> or you would need to add this to the library hum
11.39.51 #       <pamaury> anyway, this is probably another issue, just have a go at it, it can be improved later
11.43.08 #       <wodz> pamaury: Any particular example of such setup? You can always fire up two clients connected to two different backend servers
11.45.57 #       <pamaury> just to avoid having two qeditor instances and if you want to use it for a diff for example
11.46.29 #       <wodz> Diff is the only thing I can imagine this useful for.
11.46.41 #       <wodz> But is diff commited at all?
11.48.01 #       <pamaury> no, there is a patch on gerrit but not sure about the state
11.50.10 #       <wodz> Anyway in case of diff you still have to select two sources of information to compare. It can be made UI level setup to use local backend server for one and remote for the second.
11.52.17 #       <pamaury> ok do as you wish, that's clearly not the major point here :)
11.54.33 #       <pamaury> I need to go, be back later
11.55.54 Quit    greatwolf (Ping timeout: 246 seconds)
11.56.59 Join    greatwolf [0] (greatwolf@gateway/shell/panicbnc/x-qnknsycyrcfxxryw)
12.10.06 Join    yuriks [0] (~quassel@opentyrian/developer/yuriks)
12.13.02 Quit    einhirn (Read error: Connection reset by peer)
12.37.28 ***     Saving seen data "./dancer.seen"
12.37.59 Join    FSanches [0] (~felipe@2804:14c:37:268b:41af:6fd7:e9a1:15fc)
12.38.18 #       <utrack> could anyone look at g#1193? It's a simple workaround, but it's a pain to fix every time code is checked out ._.
12.38.29 #       <fs-bluebot> 3Gerrit review #1193 at http://gerrit.rockbox.org/r/1193 : 3Added fgnu89-inline flag for tool compilers; fixes embedded GCC build for host GCC... by Nick K
12.43.22 #       <pamaury> utrack: what does that do ?
12.43.53 #       <utrack> pamaury: it enables compilation on host systems with newer gcc :)
12.43.54 #       <pamaury> I'll be happy to commit it if necessary
12.44.14 #       <pamaury> ok, may it cause any issue with older gcc >
12.44.16 #       <pamaury> ?
12.45.05 #       <utrack> pamaury: it needs tests on gcc <= 4.3, but the gist of it is iso c99 inline externs were default with v<4.3, but on 4.3 and later some other syntax was chosen as default. So some parts of RB refuse to compile
12.45.18 #       <utrack> pamaury: not sure, but according to specs it shouldn't
12.46.24 #       <pamaury> I see, if you have a way to test it on gcc <= 4.3 that would be awesome
12.46.55 #       <utrack> pamaury: i'll try to check it out tomorrow. :)
12.47.03 #       <pamaury> ok thanks :)
14.37.30 ***     No seen item changed, no save performed.
14.49.00 Join    peeZ3 [0] (253aa42a@gateway/web/freenode/ip.37.58.164.42)
14.49.08 #       <peeZ3> hi
14.50.05 #       <peeZ3> a question: I wonder where I can submit bug reports for a particular theme? in flyspray? thx
14.52.13 #       <pamaury> flyspray
14.52.39 Join    amayer [0] (~amayer@mail.weberadvertising.com)
14.52.46 #       <pamaury> unfortunately, I don't think we look at bug reports very often because the few devs are very busy
14.54.38 #       <peeZ3> it's just a little think but a bit anoying: http://forums.rockbox.org/index.php/topic,51021.0.html
14.55.19 #       <wodz> pamaury: Looking at code you basically register callback which fires when new device enumerates (+ returns all already connected devices on registration). Now the server should have means to notify clients connected.
14.56.56 #       <pamaury> yeah it's very easy with libusb (assuming the library supports hot plug so you should also have a function to check if hotplug is supported)
14.57.21 #       <wodz> yes, there is one
14.57.46 #       <pamaury> the current code in qeditor is quite dumb at the moment though
14.58.09 #       <pamaury> I'd like the library to report when a device disappear/is disconnected
15.00.39 #       <pamaury> how do you plan to have the server notify device changes ?
15.01.19 #       <pamaury> also if hwstub_server supports several devices, it should probably have a notion of 'opening a device' right ?
15.02.03 #       <wodz> pamaury: Thats the question. The easiest approach is to poll the server for device list. Otherwise you should asynchronously listen for messages from server.
15.02.40 #       <wodz> pamaury: yes tcp protocol should be extended with device id
15.03.10 #       <pamaury> you can use out of band data
15.03.38 #       <pamaury> I suppose in any case, it means the hwstub library should have its own thread
15.05.29 #       <wodz> so you mean to spawn 'listening' thread in hwstub_open(), righ?
15.05.45 #       <pamaury> yes
15.06.44 #       <pamaury> that will make the whole library more complicated though because the handling of OOB data is not trivial
15.07.46 #       <pamaury> but polling is not trivial either because you don't want to send a poll request in the middle of a request, so you need a queuing mechnism
15.08.36 Quit    FSanches (Quit: Leaving.)
15.08.36 #       <wodz> There is simpler approach. backend can respond with disconnect error if you issue request to the device which got disconnected in the middle
15.09.05 #       <wodz> then you could poll infrequently about new entities
15.10.07 #       <pamaury> yes of course, I think the hwstub library should report disconnect error anyway, and those errors should also appear in the TCP protocol.
15.11.40 #       <wodz> So the simplest thing is to extend protocol so 1) it reports actual errors such as disconnects 2) add status query which will return the list of devices connected to the server
15.11.57 #       <wodz> 3) add device id field to the messages
15.12.00 Join    jtdesigns01 [0] (~jonathan@2601:400:8000:2669:a912:ad75:a3a8:b02b)
15.12.14 #       <pamaury> 4) add open/close requests
15.12.38 #       <wodz> pamaury: what good is it for?
15.12.55 #       <pamaury> you can't send arbitrary request to USB device without opening then before
15.13.22 #       <wodz> pamaury: or you mean that server should know what devices are connected but not open usb connection to them?
15.13.49 #       <pamaury> not on start no, because opening a device may prevent access for other programs
15.14.06 #       <pamaury> you should only open it when you actually use it
15.15.00 #       <pamaury> my suggestion is that server can 'open' a device, return a handle ID, then you can use the handle to send request and you can close it
15.15.15 #       <pamaury> otherwise you need to open/close it on each request
15.15.25 #       <pamaury> but that sounds wrong
15.16.37 #       <wodz> Why server shouldn't keep devices opened actually?
15.17.28 Join    stickyb1t [0] (~egon@msw13.pip.aber.ac.uk)
15.17.42 #       <wodz> each device will have separate handle so server is able to route requests appropriately
15.18.20 #       <pamaury> it feels kind of strange to greedily open all devices you can even if you don't use them
15.19.13 #       <wodz> explicit open/close may feel strange in multiclient scenario
15.20.03 #       <wodz> what if one client decides to  close and the second wishes to read something?
15.20.08 #       <pamaury> each client would have its own ID, the server would multiplex requests
15.20.19 #       <pamaury> open/close is relative to the client
15.20.27 #       <pamaury> the server counts references basically
15.20.30 #       <wodz> that sounds overly complicated from my point of view
15.21.26 #       <pamaury> but for example, what if hwstub_server grabs a JZ device and them you try to use jw tools to upload a binary ?
15.21.42 #       <pamaury> I guess you can't because hwstub already claimed the interface
15.22.27 #       <pamaury> (it's only a problem for device that could potentially be in use by other programs of course)
15.23.34 #       <wodz> So you expect additional button for connect/disconnect in qeditor for example? 
15.24.01 #       <wodz> or open/close() in hwstub_shell - thats sounds bogus to me
15.24.51 #       <pamaury> qeditor already does that internally, it open devices when you select them in the interface and leave the other ones alone
15.25.15 #       <pamaury> hzstub_shell would open the device you specified on start, since it only handle a single device at the moment
15.25.26 #       <pamaury> I mean the current library already has open/close
15.25.41 #       <wodz> I'll think about this some more. Gtg
15.25.44 Quit    wodz (Quit: Leaving)
15.27.51 Quit    stickyb1t (Ping timeout: 246 seconds)
15.34.19 Join    stickyb1t [0] (~egon@msw13.pip.aber.ac.uk)
15.36.37 Quit    peeZ3 (Quit: Page closed)
15.39.04 Quit    stickyb1t (Ping timeout: 240 seconds)
16.00.02 Join    stickyb1t [0] (~egon@msw13.pip.aber.ac.uk)
16.00.07 Join    FSanches [0] (~atomic@179.114.13.111)
16.07.36 Quit    stickyb1t (Ping timeout: 250 seconds)
16.09.47 #       <user890104> hello, does anyone know why when i set "backlight on hold" to off, it does not go off when locking the hold switch on my ipod classic? (build bc25437-150929)
16.11.34 #       <user890104> it used to turn off immediately when locking the switch, and that version was more than year old, but since i wiped the whole hdd i don't have it
16.12.07 #       <jtdesigns01> hmm, thats not the most recent version afaik
16.12.10 Join    stickyb1t [0] (~egon@msw13.pip.aber.ac.uk)
16.13.21 #       <jtdesigns01> but its close
16.14.02 #       <jtdesigns01> were you using the latest "stable" before you wiped?
16.17.28 Quit    stickyb1t (Read error: Connection reset by peer)
16.17.34 Join    st1ckyb1t [0] (~egon@msw13.pip.aber.ac.uk)
16.20.14 #       <pamaury> sounds like either the code to set backlight on off is broken, or hold detection notification on the ipod classic is broken
16.22.06 Quit    st1ckyb1t (Ping timeout: 256 seconds)
16.26.39 #       <pamaury> user890104: does hold work ? (I mean apart from the backlight not goes off immediately)
16.36.44 #       <user890104> pamaury: yes
16.37.10 #       <user890104> also the ipod doesn't wake up on unlock, it used to do so
16.37.24 #       <user890104> wake up = backlight on + screen on
16.37.34 ***     Saving seen data "./dancer.seen"
16.38.00 #       <user890104> looks like it blocks button inputs, but doesn't notify rockbox about its status changes
16.38.42 #       <user890104> TheSeven might have an idea what's going on
16.39.07 #       <user890104> the hold switch is not a GPIO IIRC
16.45.42 #       <pamaury> the button driver is supposed to notify rockbox on hold change. If the hold is a hardware switch, it could still block the input but the code to sense that is broken. But yeah TheSeven is probably the one who knows about that
16.48.50 Quit    munch (Ping timeout: 246 seconds)
16.50.20 #       <jtdesigns01> pamaury: implementing your suggested change, when is the interrupt called?
16.53.05 #       <pamaury> jtdesigns01: I would need to check the datasheet, you can probably select interrupt events but iirc, as long as the user is touching the pad, you get at least N reports per seconds. where is N is the report rate and can be adjusted
16.53.31 #       <jtdesigns01> i see
16.53.35 #       <pamaury> I think it's 50 interrupts per/sec, not sure
16.54.44 #       <pamaury> one thing to think about though is what happens if for example you get two reports between two calls to get relative data: should you report the sum of relative moves or only the most report ?
16.57.42 Join    TheLemonMan [0] (~lemonboy@unaffiliated/thelemonman)
17.12.58 Part    esko997 ("Leaving")
17.15.28 Join    nlogex [0] (~filip@dhcp-108-168-16-140.cable.user.start.ca)
17.21.42 Join    st1ckyb1t [0] (~egon@msw13.pip.aber.ac.uk)
17.31.46 #       <jtdesigns01> pamaury: could you look at my new patchset? I`m not sure what i did wrong, but using dragging in rockpaint now freezes instantly.
17.32.48 #       <pamaury> jtdesigns01: the button driver part looks ok
17.33.17 #       <pamaury> my guess is that x and/or y in rockpaint goes out of range
17.33.53 #       <pamaury> I'm not quite sure you want relative data by the way
17.33.58 Quit    petur (Quit: Leaving)
17.49.57 #       <jtdesigns01> i had forgotten about a little plugin i made while testing the first patchset that shows the current relative data.
17.50.16 #       <jtdesigns01> with my new implementation, its showing all zeroes
17.50.47 #       <pamaury> jtdesigns01: it is possibly the touchpad doesn't report relative data, let me check
17.51.07 #       <jtdesigns01> no, it did work before.
17.51.19 #       <jtdesigns01> same with my changes to rockpaint
17.53.00 #       <pamaury> are you sure it's not just a display problem ? Ie it reports one non-zero valye one time out of 50 
17.53.01 #       <pamaury> ?
18.12.21 #       <jtdesigns01> pamaury: what does the display have to do with it?
18.12.48 #       <pamaury> display is slow :)
18.13.13 #       <jtdesigns01> um.. ok?
18.13.21 #       <jtdesigns01> it worked before.
18.13.59 #       <pamaury> maybe do this: go to debug > target > interrupts
18.15.07 #       <pamaury> you will see a number of interrut sources, look for for gpio0 (I think), there should be number next to it, it's the number of interrupts per sec
18.15.20 #       <pamaury> start touching the pad, check that the number goes up
18.15.33 #       <pamaury> (I don't have the device at hand, so I can't check the details)
18.17.01 #       <pamaury> sorry it should debug > View HW info > icoll
18.18.25 #       <pamaury> you can reach icoll by pressing select multiple times I think
18.22.17 #       <jtdesigns01> yeah, it does go up. why?
18.22.31 #       <jtdesigns01> why is that important?
18.22.45 #       <jtdesigns01> is that to test if my device is working?
18.23.10 #       <pamaury> it means that interrupts are reported
18.23.18 #       <jtdesigns01> ok.
18.27.15 #       <jtdesigns01> hmm... so i guess the struct isnt getting filled at all OR the get_relative function isnt returning it correctly
18.27.24 Quit    FSanches (Ping timeout: 246 seconds)
18.28.36 Quit    jtdesigns01 (Remote host closed the connection)
18.31.26 Join    jtdesigns01 [0] (~Thunderbi@2601:400:8000:2669:c0bc:57d1:b403:264b)
18.31.53 Quit    st1ckyb1t (Ping timeout: 250 seconds)
18.35.47 Quit    nlogex (Quit: WeeChat 1.3)
18.37.35 ***     Saving seen data "./dancer.seen"
18.54.50 Quit    pamaury (Ping timeout: 255 seconds)
19.15.13 Join    lebellium [0] (~chatzilla@89-93-179-187.hfc.dyn.abo.bbox.fr)
19.16.53 Join    FSanches [0] (~atomic@179.114.13.111)
19.41.17 Join    pamaury [0] (~quassel@rockbox/developer/pamaury)
19.49.10 Join    st1ckyb1t [0] (~egon@avondaleaber.plus.com)
19.51.38 Quit    st1ckyb1t (Read error: Connection reset by peer)
19.52.04 Join    st1ckyb1t [0] (~egon@avondaleaber.plus.com)
20.14.57 Quit    st1ckyb1t (Quit: Konversation terminated!)
20.15.35 Join    st1ckyb1t [0] (~egon@avondaleaber.plus.com)
20.22.28 Quit    st1ckyb1t (Quit: Konversation terminated!)
20.23.26 Join    stickyb1t [0] (~egon@avondaleaber.plus.com)
20.36.41 Quit    stickyb1t (Ping timeout: 246 seconds)
20.37.36 ***     Saving seen data "./dancer.seen"
21.00.18 Quit    fs-bluebot (Read error: Connection reset by peer)
21.00.29 Quit    bluebrother (Read error: Connection reset by peer)
21.00.48 Quit    Bray90820 ()
21.10.20 Join    bluebrother [0] (~dom@rockbox/developer/bluebrother)
21.14.13 Join    petur [0] (~petur@rockbox/developer/petur)
21.17.56 Join    wodz [0] (~wodz@89-75-106-221.dynamic.chello.pl)
21.21.46 Join    bertrik [0] (~quassel@rockbox/developer/bertrik)
22.16.42 Join    stickyb1t [0] (~egon@avondaleaber.plus.com)
22.37.39 ***     Saving seen data "./dancer.seen"
22.39.17 Quit    kugel (Ping timeout: 240 seconds)
22.39.24 Join    kugel [0] (~kugel@ip5b42be9b.dynamic.kabel-deutschland.de)
22.39.24 Quit    kugel (Changing host)
22.39.24 Join    kugel [0] (~kugel@rockbox/developer/kugel)
22.39.29 Quit    yuriks (Read error: Connection reset by peer)
22.39.37 Quit    orly_owl (Ping timeout: 240 seconds)
22.40.30 Join    orly_owl [0] (~david@unaffiliated/orly-owl/x-3167833)
22.43.40 Quit    JanC (*.net *.split)
22.43.40 Quit    stickyb1t (*.net *.split)
22.43.40 Quit    jtdesigns01 (*.net *.split)
22.43.40 Quit    greatwolf (*.net *.split)
22.43.41 Quit    Jinx (*.net *.split)
22.43.41 Quit    ps-auxw (*.net *.split)
22.43.42 Quit    Jack87 (*.net *.split)
22.45.46 Join    JanC [0] (~janc@lugwv/member/JanC)
22.46.13 Join    stickyb1t [0] (~egon@avondaleaber.plus.com)
22.46.13 Join    jtdesigns01 [0] (~Thunderbi@2601:400:8000:2669:c0bc:57d1:b403:264b)
22.46.13 Join    greatwolf [0] (greatwolf@gateway/shell/panicbnc/x-qnknsycyrcfxxryw)
22.46.13 Join    Jinx [0] (Dojo@unaffiliated/jinx)
22.46.13 Join    ps-auxw [0] (~arneb@p50875EF1.dip0.t-ipconnect.de)
22.46.13 Join    Jack87 [0] (Jack87@nasadmin/admin/jack87)
22.47.43 Join    yuriks [0] (~quassel@opentyrian/developer/yuriks)
22.47.44 Quit    scorche|sh (Ping timeout: 240 seconds)
22.50.02 Quit    Jinx (Ping timeout: 246 seconds)
22.52.11 Quit    stickyb1t (Read error: Connection reset by peer)
22.52.31 Join    stickyb1t [0] (~egon@avondaleaber.plus.com)
22.52.54 Quit    stickyb1t (Client Quit)
22.55.18 Join    ZincAlloy [0] (~Adium@2a02:8108:8080:26f0:20bf:edb3:7bd0:3206)
22.55.51 Join    scorche|sh [0] (~scorche@rockbox/administrator/scorche)
23.00.07 Quit    Cinos (Remote host closed the connection)
23.00.18 Quit    wodz (Quit: Leaving)
23.08.51 Join    Cinos [0] (~Cinos@a.kittyboy.named.cinos.pw)
23.11.19 Join    Jinx [0] (Dojo@unaffiliated/jinx)
23.14.45 Quit    lebellium (Quit: ChatZilla 0.9.92 [Firefox 42.0/20151001142456])
23.15.59 Quit    bertrik (Remote host closed the connection)
23.19.55 Quit    petur (Quit: Leaving)
23.26.20 Join    Bray90820 [0] (~Bray90820@173-17-46-117.client.mchsi.com)
23.26.58 Quit    ender` (Quit: Any technology distinguishable from magic is insufficiently advanced.	-- Gehm's Corollary to Clarke's Third Law)
23.31.43 Quit    amayer (Quit: Leaving)
23.35.53 Join    FSanches1 [0] (~felipe@2804:14c:37:268b:4552:b544:575:c80d)
23.46.31 Quit    TheLemonMan (Quit: "It's now safe to turn off your computer.")