--- Log for 02.04.112 Server: gibson.freenode.net Channel: #rockbox --- Nick: logbot_ Version: Dancer V4.16 Started: 22 hours and 54 minutes ago 00.06.41 Quit crwl (Ping timeout: 264 seconds) 00.10.05 Quit lebellium (Quit: ChatZilla 0.9.88.1 [Firefox 12.0/20120328051619]) 00.14.37 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 00.19.16 Quit ender` (Quit: We live in an age when pizza gets to your home before the police. -- Jeff Marder) 00.31.33 Quit domonoky (Read error: Connection reset by peer) 00.38.37 Quit dfkt (Quit: -= SysReset 2.55=- Sic gorgiamus allos subjectatos nunc.) 00.39.52 Quit bertrik (Ping timeout: 260 seconds) 00.41.17 Join Scromple [0] (~Simon@119.225.209.134) 00.41.47 # rockbox logo on the creative zen x-fi3 \o/ 00.41.48 # http://amaury.pouly.free.fr/Images/SSL23185.JPG 00.46.54 # i came online to ask you if you were working on the XFI3 :) 00.47.40 # I'm working on both xfi2 and 3. I was bored by the xfi2 so I decided to re the lcd of the xfi3 ! 00.49.36 # bertrik: is this safe? http://forums.rockbox.org/index.php/topic,28062.msg196403.html#msg196403 00.49.57 # i thought the headphone on AMS wasn't directly coupled to ground 00.51.43 # when the driver turns on AUDIOSET3_HPCM_on, isn't it actually disconnecting the headphone ground from the power ground? 00.52.30 # the xfi3 OF is really strange: the screen is actually 176x220 (pretty standard) but the OF only uses 176x216 !! 01.01.55 Join saratoga__ [0] (980329c4@gateway/web/freenode/ip.152.3.41.196) 01.03.17 Join MCrase [0] (~mark@cpe-184-59-109-126.cinci.res.rr.com) 01.04.09 Quit saratoga_ (Ping timeout: 245 seconds) 01.07.25 # I registered to contribute to the wiki and was told I needed to ask for write permission here. I was thinking of working on some of the plugin pages to add info about the clip zip (controls and what not). Possibly doing some work on the user manual as well. 01.08.21 # MCrase: sure, whats your name 01.08.27 # MarkCrase 01.08.29 # also, you don't need wiki write access to work on the manual 01.09.13 # you can just post edits to it directly to gerrit (or flyspray, but we're phasing that out) 01.09.57 Quit nosa-j (Excess Flood) 01.10.05 # Ok. Sounds good. 01.10.52 # huh the new "add a user" button the wiki badly screws up on chrome 01.11.21 # the wiki becomes unresponsive then shows me blank pages 01.12.12 # Mcrase: try now, not sure if it took 01.12.22 # the wiki is glitching for me 01.12.53 *** Saving seen data "./dancer.seen" 01.13.09 # I think its working. It let me login when I tried to edit the page 01.14.04 Quit anewuser () 01.15.05 Quit z180 (Ping timeout: 252 seconds) 01.16.01 Join anewuser [0] (~anewuser@186.93.175.208) 01.16.01 Quit anewuser (Changing host) 01.16.01 Join anewuser [0] (~anewuser@unaffiliated/anewuser) 01.17.20 Join nosa-j [0] (~m00k@adsl-74-235-42-147.clt.bellsouth.net) 01.19.50 Quit CaptainKewl (Read error: Connection reset by peer) 01.21.49 Quit pamaury (Remote host closed the connection) 01.26.43 # <[Saint]> saratoga__: there's an "add a user" button? 01.27.29 # <[Saint]> oh, there we go. 01.28.59 Quit nosa-j (Read error: Connection reset by peer) 01.30.01 Join nosa-j [0] (~m00k@adsl-74-235-42-147.clt.bellsouth.net) 01.39.23 # doesn't sort hte list though 01.41.25 Join Keripo [0] (~Keripo@eng432.wireless-resnet.upenn.edu) 01.48.05 # yep its working. Added Sansa Clip Zip to the keys table on PluginRockblox. 01.48.08 Join curtism [0] (~curtis@bas11-montreal02-1128531224.dsl.bell.ca) 01.48.08 Quit curtism (Changing host) 01.48.08 Join curtism [0] (~curtis@unaffiliated/programble) 02.04.16 Join crwl [0] (~crwlll@dsl-jklbrasgw1-ffb9c300-103.dhcp.inet.fi) 02.25.29 # scorche: the forums software is eating my posts again, can you unban me? 02.28.57 # saratoga__: done 02.29.05 # why are you so lucky? :) 02.29.06 # thanks 02.29.22 # i assume it dislikes outside links 02.29.30 # and isn't smart enough to consider wikipedia different from spam 02.30.28 Join Shovelware [0] (~chatzilla@host-68-169-137-65.MIDOLT2.epbfi.com) 02.36.11 Quit anewuser (Ping timeout: 246 seconds) 02.44.34 Quit saratoga__ (Ping timeout: 245 seconds) 02.49.11 Join bitcraft [0] (~bitcraft@173-20-20-92.client.mchsi.com) 02.50.52 Join anewuser [0] (~anewuser@186.93.175.208) 02.50.52 Quit anewuser (Changing host) 02.50.52 Join anewuser [0] (~anewuser@unaffiliated/anewuser) 03.12.54 *** Saving seen data "./dancer.seen" 03.26.13 Join Lantizia [0] (~lantizia@erebus.seaquake.net) 03.27.52 Part Lantizia ("Leaving") 03.49.30 Quit perrikwp (Read error: Connection reset by peer) 03.49.46 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 03.55.55 Join linuxguy3 [0] (~timj@24-148-61-208.c3-0.lem-ubr1.chi-lem.il.cable.rcn.com) 04.13.24 # <[Saint]> JdGordon: please assure me that if you make the core handle LTR and RTL directly, that you'll still leave a way for skins to override this? 04.13.26 # <[Saint]> ;) 04.14.35 # <[Saint]> I've been thinking about it, and there may be cases where one might want to create a specific effect with their abuse. 04.15.46 # i dont tihnk so 04.16.25 # <[Saint]> I can think of some amusing effects one could do with it. 04.16.50 # why would the direction of the affect make any difference? 04.17.33 # <[Saint]> the scroll direction is flipped for RTL is it not? 04.18.12 # yes 04.20.36 # <[Saint]> Primarily, I was just looking at it earlier today and its a really easy fix to get all the cabbies (some already do) caring about lang direction and vp placement. 04.21.02 # <[Saint]> I mean, you're free to do it in the core, of course, but its a *really* small fix. 04.21.32 # <[Saint]> I was thinking of viewportifying the remaining cabbies at the same time. 04.26.59 Quit prof_wolfff (Ping timeout: 246 seconds) 04.27.01 Quit kadoban_ (Ping timeout: 252 seconds) 04.27.33 # <[Saint]> JdGordon: are you able to refresh my memory if I'm able to do %?xx, or would it need to be two separate viewports with a bar each switched by the condition. 04.28.20 # <[Saint]> I seem to have it in the back of my mind that's not supposed to work. 04.30.23 Join s85_alt [0] (~s85@183.174.206.61) 04.32.53 Part s85_alt 04.35.00 # [Saint]: try it, i tinhk it does actually work 04.44.39 Quit [7] (Disconnected by services) 04.44.45 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 04.48.06 # <[Saint]> as far as coding style, I assume the "approved" use for bar tags is "%XX(x,y,w,h,image,image_identifier,all,other,options)" as opposed to "%XX(x,y,w,h,filename,all,other,options) 04.48.08 # <[Saint]> " 04.48.34 # <[Saint]> JdGordon: ^ (since this should follow "correct" styling. 04.49.11 # <[Saint]> ) 04.50.28 Quit amiconn (Disconnected by services) 04.50.28 Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) 04.50.36 Quit pixelma (Disconnected by services) 04.50.38 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.50.41 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 04.50.50 Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) 04.52.44 Quit bitcraft (Remote host closed the connection) 04.56.12 Join Rower85 [0] (husvagn@v-413-alfarv-90.bitnet.nu) 04.58.38 Quit pystar90 (Ping timeout: 265 seconds) 04.58.58 Join enthdegree [0] (~BitchX@unaffiliated/enthdegree) 05.12.57 *** Saving seen data "./dancer.seen" 05.14.54 Join bitcraft [0] (~bitcraft@173-20-20-92.client.mchsi.com) 05.15.18 Quit bitcraft (Remote host closed the connection) 05.17.18 # * [Saint] wonders if its safe to assume RaaA won't need to handle FM or Recording any time in the near future (ever?) for the sake of a little code policing. 05.17.55 Quit Keripo (Read error: Connection reset by peer) 05.18.46 # <[Saint]> (difference between %?xx and %?if(foo)) 05.22.44 Join Keripo [0] (~Keripo@eng432.wireless-resnet.upenn.edu) 05.24.50 # probably 05.26.42 Join bitcraft [0] (~bitcraft@173-20-20-92.client.mchsi.com) 05.28.26 Quit bitcraft (Remote host closed the connection) 05.29.56 # <[Saint]> JdGordon: care to comment on the bar style above? (if you have an opinion) 05.31.09 # either are fine 05.32.16 # <[Saint]> when there's two ways to do things, and someone might potentially be learning from it, I often wonder what is "right" syntax. 05.32.30 # <[Saint]> (or more than two ways, as if often the case) 05.42.47 Join bitcraft [0] (~bitcraft@173-20-20-92.client.mchsi.com) 05.44.26 Quit bitcraft (Remote host closed the connection) 06.10.44 Quit anewuser (Read error: Connection reset by peer) 06.11.47 Join bitcraft [0] (~bitcraft@173-20-20-92.client.mchsi.com) 06.22.29 # <[Saint]> Hummm...interesting discovery. 06.22.56 # <[Saint]> The touch area "progressbar" doesn't seem to know about bar inversion. 06.23.02 # <[Saint]> JdGordon: ^ 06.24.08 # <[Saint]> perhaps its just being weird for me. I'll clean this up a bit and test on target. 06.29.59 Join enth [0] (~BitchX@unaffiliated/enthdegree) 06.32.50 Quit enthdegree (Ping timeout: 260 seconds) 06.34.51 Quit rasher (Read error: Connection reset by peer) 06.38.38 Quit petur (Ping timeout: 260 seconds) 06.39.42 Join rasher [0] (~rasher@rockbox/developer/rasher) 06.42.09 Join petur [0] (~petur@rockbox/developer/petur) 06.47.19 Part Shovelware 06.59.39 Quit enth (Read error: Connection reset by peer) 07.10.39 Quit XavierGr (Ping timeout: 252 seconds) 07.11.19 # <[Saint]> Hmmm....because of my identifier choices, my bars look very odd. 07.11.42 # <[Saint]> %pv(x,y,w,h,image,volumebar,backdrop,volumebar-backdrop,invert) 07.13.01 *** Saving seen data "./dancer.seen" 07.13.26 # <[Saint]> at least doing it this way means there's no "wait, where did this image come from?" for any new user trying to read the syntax. Every image called is %xl'd now. 07.16.20 Quit curtism (Quit: Live Long and Prosper) 07.19.26 Join kadoban_ [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 07.33.16 Join pystar90 [0] (~pystar90@frnk-590f5adc.pool.mediaWays.net) 07.34.36 # * Mir waves 07.38.18 Quit petur (Ping timeout: 250 seconds) 07.39.46 Quit Keripo (Read error: Connection reset by peer) 07.41.38 Join Keripo [0] (~Keripo@eng432.wireless-resnet.upenn.edu) 07.43.26 # does the rockbox installer have to have an internet connection or can it install from a downloaded zip while being offline 07.45.42 Quit Keripo (Read error: Connection reset by peer) 07.46.09 Join petur [0] (~petur@rockbox/developer/petur) 07.47.16 Join Keripo [0] (~Keripo@eng432.wireless-resnet.upenn.edu) 08.09.09 Join ender` [0] (~ender@foo.eternallybored.org) 08.24.43 # <[Saint]> Mir: It can install from a cache, yes. 08.31.01 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 08.44.24 Quit Keripo (Read error: Connection reset by peer) 08.46.14 Join wodz_ [0] (~wodz@89-76-160-35.dynamic.chello.pl) 08.46.41 Quit amiconn (Remote host closed the connection) 08.46.41 Quit pixelma (Read error: Connection reset by peer) 08.46.59 Join amiconn [0] (amiconn@rockbox/developer/amiconn) 08.47.01 Join pixelma [0] (pixelma@rockbox/staff/pixelma) 08.49.39 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 08.49.58 # amiconn: why test_disk calculates transfer rate as (25 * (filesize>>8) / time) ? time is in tick units 10^-2 s filesize is in bytes? I would expect something like ((100 * filesize)/1024)/time 08.50.45 # ...which is the same, just my solution is faster and less susceptible to overflows 08.50.56 # 100/1024 is the same as 25/256 08.51.04 # and /256 is the same as >>8 08.52.13 # Dividing first loses a bit of precision though 08.53.58 Quit bitcraft (Remote host closed the connection) 08.54.04 # But it avoids overflows 08.56.06 # http://git.rockbox.org/?p=rockbox.git;a=commit;h=3a74611a904fc817b71d7227f56e50258ea8b115 08.56.57 # amiconn: my point is that this is not time critical and makes it harder to read 08.57.20 # It's susceptible to overflows though 08.57.41 Join Keripo [0] (~Keripo@eng432.wireless-resnet.upenn.edu) 09.00.42 # wodz_, amiconn: simply add "100 * ( filesize / 1024 )" as a comment 09.01.12 # Is it really? The highest reported speeds are well below 10MB/s which in turn gives less than 100 MB in 10s testing period. This will not overflow with good margin of safety 09.02.00 # and btw. test_disk test only one type of unaligned access 09.02.24 Quit Keripo (Read error: Connection reset by peer) 09.04.52 Join Keripo [0] (~Keripo@eng432.wireless-resnet.upenn.edu) 09.09.47 # Well, there were oveflows, otherwise Buschel wouldn't have implemented the fix, see http://www.rockbox.org/tracker/task/8635 09.13.02 *** Saving seen data "./dancer.seen" 09.14.16 # hmm, signed makes a difference 09.14.55 # Signed exactly makes up for a factor of two. If unsigned, it would overflow at ~16.6 MB/s 09.15.12 # true 09.16.18 # The ipod video and gigabeat S can reach that if DMA is enabled 09.17.17 # 100 MB in 10 s means that if you multiply first, and use *100/1024 instead of the reduced fractio *25/256, the intermediate is 10,000,000,000 which obviously overflows even unsigned 32 bit 09.17.37 # anyway I think comment would be a good thing 09.17.39 # Even *25 overflows signed 32 bit then 09.18.27 # why it needs to be signed? 09.19.41 # Well, use unsigned and see it overflow at ~16 MB/s (and probably deal with gcc signed vs. unsigned warnings) 09.20.31 # it overflows in calc so proper casting should do the job. 09.20.45 # Dividing first avoids the overflow altogether, and since filesize is always a multiple of 256 it loses no precision. Using 1024 would 09.21.28 # Why use 64 bit if you can do it in 32? This is embedded programming. No need to waste resources, even if it's not time critical 09.21.52 # true. Still I'll vote for a comment 09.23.00 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 09.27.21 Quit bertrik (Ping timeout: 244 seconds) 09.40.31 # where is the code which triggers boost on storage access? 09.45.05 Quit Scromple (Quit: Leaving) 09.54.19 Join mortalis [0] (~mortalis@77.108.98.176) 09.54.38 # thats truly amazing - test_disk on rk27xx gives either ~13/13/600kB/s or ~2400/2400/2600 for aligned access. For the very same code. I can't spot the pattern 10.00.52 Quit mortalis (Ping timeout: 248 seconds) 10.00.57 Quit wodz_ (Quit: Leaving) 10.20.51 Join dfkt [0] (dfkt@unaffiliated/dfkt) 10.34.23 Quit [Saint] (Remote host closed the connection) 10.45.33 Join pamaury [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net) 10.45.33 Quit pamaury (Changing host) 10.45.33 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 10.51.17 Join pamaury_ [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net) 10.51.58 Quit pamaury (Ping timeout: 246 seconds) 10.52.23 Join LinusN [0] (~linus@giant.haxx.se) 10.52.50 Part MCrase 10.54.03 Join TomColler [0] (~thomas@net-93-144-129-173.cust.dsl.teletu.it) 10.57.51 Join wodz_ [0] (~wodz@iwl138.internetdsl.tpnet.pl) 11.04.21 Join evilnick [0] (d92ba8fc@rockbox/staff/evilnick) 11.05.31 Join MCrase [0] (~mark@cpe-184-59-109-126.cinci.res.rr.com) 11.06.21 # Commit 10c73cd in www by 03Björn Stenberg: Added missing robots.txt 11.13.04 *** Saving seen data "./dancer.seen" 11.17.22 # FYI: http://svn.rockbox.org is now closed 11.21.56 Quit kadoban_ (Ping timeout: 244 seconds) 11.24.23 Join [Saint] [0] (~Saint]@101.98.158.103) 11.24.23 Quit [Saint] (Changing host) 11.24.23 Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) 12.16.28 Join apc [0] (~apc@122-61-171-96.jetstream.xtra.co.nz) 12.17.01 # hey guys, I want to download the 3.11 source but http://download.rockbox.org/release/3.11/rockbox-3.11.7z is 404. Can someone help me out? 12.17.56 # doesn't look like anyone uploaded the source for this release 12.18.05 # you can get it from the git repo, the tag is "v3.11-final" 12.18.11 # oh, the hyperlink on the main page is wrong, it should be: http://download.rockbox.org/release/3.11/rockbox-v3.11.7z 12.18.14 # note the v 12.18.23 # hm 12.18.35 # dunno if that's manual or if the release script has changed. 12.18.47 # in any case, if you are downloading the source you almost certainly actually want a clone of our git repo :) 12.18.50 # it is a mystery 12.18.53 # the tarballs are of limited value 12.18.59 # The release script for the source has been rewritten 12.19.12 # Zagor, Bagder: can you fix the filename on the server? 12.19.34 # torne thank god it is a 7z then (; 12.19.37 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 12.20.05 # oh 12.20.27 # wouldn't cloning the git repo give some prerelease and unstable builds? 12.20.35 # it will give you *every* version :) 12.20.46 # releases, development builds, the whole lot. 12.21.25 # at once?! 12.21.30 # yes 12.21.36 # the entire history of rockbox is in there 12.21.40 # woah 12.21.42 # that's how version control works 12.21.47 # ah 12.21.49 # it's not even that big :) 12.21.50 # but the git command would change right? 12.22.01 # no, you just clone the entire repository 12.22.10 # like 12.22.12 # git clone git://git.rockbox.org/rockbox ? 12.22.15 # once you have a clone of it you can check out any release, branch or development build you want. 12.22.39 # oh, so a different command. i'm not that good at git 12.22.42 # no, just clone it like that. it will check out the current tip of the development branch by default. 12.22.48 # For 3.11, "git checout v3.11-final" after you've cloned 12.23.04 # <[Saint]> *checkout 12.23.11 # Ah, yes, sorry 12.23.27 # oh thanks 12.23.42 # cos i used to use git (well i think it was svn before?) and it was always the latest version 12.23.45 # but i'm not so edgy anymore 12.24.03 # yes, svn only checks out one branch at a time 12.24.04 # You can do the same thing in svn, but it's not as convenient 12.24.08 # * [Saint] recommends apc look at gitref.org 12.24.10 # git repositories contain everything 12.24.21 # I'm not sure if actually working on the 3.11 is very useful though, unless you want to prepare a fix in preparation for a 3.11.x bugfix release 12.24.36 # anyway, if you clone the repo once now, you can update it very quickly in future to get to any other build you want 12.24.45 # it will only have to download things that are actually new/changed 12.24.47 # not the whole lot again 12.24.55 # thats a good idea, especially since i will be writing some patches 12.25.17 # is this release pretty buggy? 12.25.17 # if you are going to write any patches, then 1) you need to be using git to upload them to our patch system and 2) you want to be developing on top of the master development branch, not 3.11 12.25.39 # as gevaerts said, there's no point writing patches for 3.11 unless they are specifically bugfixes for 3.11 that don't apply to master 12.25.43 # apc: We'd hope not :) 12.25.44 # these are just small, badly written patches for personal use :P 12.26.03 # have you considered writing them better and submitting them? :) 12.26.33 # apc: I wouldn't say it's buggier than usual, but fixes can always be needed. In this case we'd like e.g. to get the nano2g back 12.26.47 # yeah! i have used so many patches other people have made, like the context-sensitive backlight and some other things 12.27.36 # also the play-pause fade is waay too long by default (; 12.33.37 Join GodEater_ [0] (93722cd1@rockbox/staff/GodEater) 12.40.03 Quit Keripo (Quit: Leaving.) 12.40.57 Join XavierGr [0] (~xavier@rockbox/staff/XavierGr) 12.44.06 Nick pamaury_ is now known as pamaury (~quassel@vit94-1-82-67-248-70.fbx.proxad.net) 12.44.19 Quit pamaury (Changing host) 12.44.19 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 12.53.30 Quit XavierGr (Ping timeout: 244 seconds) 12.56.29 Quit apc (Quit: Leaving) 13.09.29 # pamaury: ping 13.13.08 *** Saving seen data "./dancer.seen" 13.13.12 # gevaerts: renamed 13.13.25 # Thanks 13.14.49 # wodz_: pong 13.15.16 # pamaury: are you going to commit safe_read* and friends? 13.16.14 # yeah, but I need to split out the patch in two: safe_read* + weak alias for interrupts and functions names (+configure which needs to be tweaked) 13.16.37 # hm, I could even do that right now in fact 13.19.38 # pamaury: I think bx lr is wrong in _get_sp() but I can't find the interworking funman's macro name to do it right 13.20.14 # I haven't looked at it but I'm pretty sure it exists too 13.25.08 Join anewuser [0] (~anewuser@186.93.175.208) 13.25.09 Quit anewuser (Changing host) 13.25.09 Join anewuser [0] (~anewuser@unaffiliated/anewuser) 13.25.51 Quit [Saint] (Quit: Quit) 13.28.57 # I thought it could be in lib/arm_support but I can't find it 13.29.44 # arm_support contains only optimized div/mul 13.30.05 # it was ldrpc or something 13.31.15 # there is some code in setjmp.S 13.31.17 # firmware/export/config.h 13.31.48 # hah ! in config.h 13.31.56 # damn, you were faster than me 13.33.30 Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) 13.33.43 # but is bx lr really wrong ? I thought the problem was when popping pc using ldm 13.34.10 # Torne: can you help on this matter ? 13.36.23 # doesn't bx clear T bit? 13.38.57 # it seems to me that bx is designed to work under all conditions: it sets T according to bit 0 of lr (if you do bx lr) 13.39.42 # it's available on armv5 and armv4t 13.42.52 # hmm, you are probably right 13.43.20 # ldrpc macro seems to confirm this 13.43.20 # I'm not an ARM expert so don't believe me ;) 13.53.17 # bx is the correct return on everyting except armv4 non-t 13.53.32 # on armv4 it doesn't exist and will die with undef 13.53.48 # (needs to be mov pc, lr instead) 13.54.24 # so unless we need to support, say, ARM710, we should be able to just write bx lr 13.55.03 # the interworking return that's a problem is as pamaury says, when popping pc with ldm 13.55.13 # which doesn't work on ARMv4T and you need to load it into a GPR and then bx to it 13.55.23 # which is a hug efucking pain in the ass :) 13.57.32 # hm, our macro is only for ARM, not thumb :/ 13.57.37 # so the painful case is missing :p 13.57.53 # (on thumb you *can't* pop into lr, so you have to pop into another register instead) 14.06.44 # pamaury: ok, so only linking error on arm RaaA is left 14.07.01 # what is linking error ? 14.08.57 # see the gerrit comment 14.10.03 # hmm, does the unwinder actually works on RaaA ? 14.10.21 # yes it does 14.10.37 # how are exceptions handled ? 14.11.10 # I guess process segfaults 14.11.36 # so it uses a signal to handle it then ? 14.11.58 # ah stupid of me, it's also used in panicf 14.12.28 # hmm, then it gets tricky because we need to have OS specific code to do this safe_read 14.13.20 # Yeah, on android you would have to trap SIGSEGV to do a safe read 14.13.47 # (you may also want to trap SIGSEGV anyway and treat it like a data abort, of course :) 14.14.03 # i'm not sure if debuggerd is very happy about these kinds of shenanigans, though 14.14.24 # debuggerd ptraces a bunch of signals and uses them to create tombstones and so on 14.14.40 # at least on userdebug/eng builds of android; not sure if it bothers on user 14.15.06 # for now we could just not do this on android 14.15.10 # just assume reads are safe. 14.15.25 Quit evilnick (Ping timeout: 245 seconds) 14.15.55 # yeah, I'll add safe_read* only on native targets 14.16.14 # bah, *I would 14.17.33 # (if you were feeling particularly optimistic about the future of android, there are much cleverer ways of handling crashes there, like using breakpad to produce minidumps that someone can look at with a debugger later) 14.17.41 # future of rockbox on android, i mean :) 14.19.05 # lets leave this for kugel ;-) 14.19.23 # yeah :) 14.19.43 # i just mean, on android we have the resources to actually save a real crash dump pretty easily, which can then be combined reliably with symbols off-device 14.19.59 # so while the unwinder is better than nothing, it's not as good as a "conventional" linux crash handler 14.20.41 # sure. unwinder on RaaA is a side effect 14.22.52 Join benedikt93 [0] (~benedikt9@p5B0C7CC1.dip.t-dialin.net) 14.22.55 Quit benedikt93 (Changing host) 14.22.55 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 14.31.59 Join Topy44 [0] (~Topy44@f049166236.adsl.alicedsl.de) 14.34.42 Quit T44 (Ping timeout: 276 seconds) 14.35.18 Quit jhMikeS () 14.50.10 Join jhMikeS [0] (~jethead71@c-68-61-166-99.hsd1.mi.comcast.net) 14.50.11 Quit jhMikeS (Changing host) 14.50.11 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 14.57.04 Quit remlap (Read error: Connection reset by peer) 14.59.40 Quit nosa-j (Excess Flood) 14.59.45 Join TheLemonMan [0] (~LemonBoy@adsl-ull-90-255.45-151.net24.it) 15.00.32 Join nosa-j [0] (~m00k@adsl-74-235-42-147.clt.bellsouth.net) 15.13.10 *** Saving seen data "./dancer.seen" 15.18.36 Join remlap [0] (~Patrick@190.28.169.217.in-addr.arpa) 15.19.53 Quit perrikwp (Read error: Connection reset by peer) 15.21.06 Join perrikwp [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 15.25.45 Quit wodz_ (Quit: Leaving) 15.30.44 # I have split the patches into 4 pieces, reviews are welcome 15.32.00 Quit TomColler (Ping timeout: 244 seconds) 15.43.24 Join WalkGood [0] (~4@unaffiliated/walkgood) 15.46.02 Quit jae (Disconnected by services) 15.46.18 Join perrikwp_ [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 15.48.42 Quit perrikwp (Ping timeout: 265 seconds) 16.04.46 Join enthdegree [0] (~BitchX@unaffiliated/enthdegree) 16.08.44 Join XavierGr [0] (~xavier@rockbox/staff/XavierGr) 16.14.11 Join n1s [0] (~n1s@nl118-175-223.student.uu.se) 16.14.11 Quit n1s (Changing host) 16.14.11 Join n1s [0] (~n1s@rockbox/developer/n1s) 16.14.54 Quit TheLemonMan (Quit: WeeChat 0.3.7) 16.21.37 Quit y4n (Quit: PÆNTS ØLF!) 16.32.19 Quit [Saint] (Remote host closed the connection) 16.33.28 Join [Saint] [0] (~Saint]@101.98.158.103) 16.33.28 Quit [Saint] (Changing host) 16.33.28 Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) 16.37.54 Quit n1s (Read error: Connection timed out) 16.44.14 Quit enthdegree (Ping timeout: 252 seconds) 16.45.59 Join enthdegree [0] (~BitchX@unaffiliated/enthdegree) 16.51.23 Join bitcraft [0] (~bitcraft@173-20-20-92.client.mchsi.com) 17.00.40 Part Zagor 17.02.49 Part LinusN 17.13.12 *** Saving seen data "./dancer.seen" 17.22.43 Quit bitcraft (Remote host closed the connection) 17.36.28 Quit WalkGood () 17.46.48 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 17.51.43 Join evilnick [0] (d92ba8fc@rockbox/staff/evilnick) 18.20.10 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 18.22.49 Quit evilnick (Quit: Page closed) 18.31.07 Join stoffel [0] (~quassel@pD9E42D90.dip.t-dialin.net) 18.36.30 Quit enthdegree (Ping timeout: 276 seconds) 18.40.16 Quit nosa-j (Read error: Connection reset by peer) 18.42.01 Join nosa-j [0] (~m00k@adsl-74-235-42-147.clt.bellsouth.net) 18.43.09 Quit anewuser (Ping timeout: 260 seconds) 18.44.48 Join bitcraft [0] (~bitcraft@173-20-20-92.client.mchsi.com) 18.53.19 Quit lembas (Quit: He's dead, Jim!) 18.53.31 Join lembas [0] (iam@lembas.ws) 19.01.28 Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) 19.06.53 Join enthdegree [0] (~BitchX@unaffiliated/enthdegree) 19.09.53 # \o/ bootloader running on the zen x-fi3 \o/ 19.13.15 *** Saving seen data "./dancer.seen" 19.18.40 Join kadoban_ [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 19.19.32 Join lebellium [0] (~chatzilla@f052240035.adsl.alicedsl.de) 19.25.29 Join riad [0] (~Adium@ns208895.ovh.net) 19.25.47 Join Horscht [0] (~Horscht@xbmc/user/horscht) 19.26.22 Join prof_wolfff [0] (~prof_wolf@81.61.201.173.dyn.user.ono.com) 19.34.49 Join TomColler [0] (~thomas@net-93-144-129-173.cust.dsl.teletu.it) 19.35.39 # I think my clip+ is bricked. Holding down the power button doesn't help. When I connect it to a computer the screen remains black but Win 7 Starter starts looking for drivers (and finds none) and OS X displays a 4.2 MB disk named "UNDEF storage Media" 19.36.35 # before this happened I had all the data corrupted on the player. I managed to reinstall the stock firmware but now that won't boot either. Any ideas? 19.41.29 Quit enthdegree (Ping timeout: 260 seconds) 19.44.11 Quit stoffel (Ping timeout: 245 seconds) 19.44.29 Quit bitcraft (Ping timeout: 264 seconds) 19.44.34 Quit benedikt93 (Quit: Bye ;)) 19.45.41 Quit Cthulhux (Ping timeout: 264 seconds) 19.47.42 Join Cthulhux [0] (cthulhux@rosaelefanten.org) 19.48.26 Quit Cthulhux (Changing host) 19.48.26 Join Cthulhux [0] (cthulhux@piratenpartei/ni/tux) 19.53.48 # well, showed up on OS X as UNDEF storage Media in Disk Utility at any rate. Finder just says it's unusable and needs to be initialized 19.54.27 Join saratoga_ [0] (980329c4@gateway/web/freenode/ip.152.3.41.196) 19.54.43 # bertrik: is it possible that the clip Zip has the battery reading off the wrong A/D channel? 19.55.01 # i've seen a lot of people say they get very different readings in rockbox then the sandisk software, even though the calibration looks ok 20.04.01 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 20.09.58 # Commit eb6c658 in rockbox by 03Dominik Riebeling: Remove espeak from TTS list on Windows. 20.16.53 Join TheLemonMan [0] (~LemonBoy@adsl-ull-90-255.45-151.net24.it) 20.17.14 Join bitcraft [0] (~bitcraft@173-20-20-92.client.mchsi.com) 20.18.06 # on OS X I get fdisk: illegal option -- l 20.18.30 # http://www.rockbox.org/wiki/SansaAMSUnbrick this tells me to use linux but I don't have that installed on anything I have access to at the moment 20.27.56 Quit thomasjfox (Quit: Konversation terminated!) 20.28.17 # eb6c658 build result: 1 errors, 0 warnings (Dominik Riebeling committed) 20.29.03 # has anyone tried to reproduce the e200 radio problem? 20.36.52 # can't find my e200, but my c200 radio does not work with 3.11 20.37.44 # oh, that's not good 20.38.16 # any idea what might have caused it? 20.38.39 # most recent change in the driver is the tuner_power() stuff 20.39.15 # Does anyhting else share the same tuner? 20.40.01 Quit nosa-j (Read error: Connection reset by peer) 20.40.03 Join nosa [0] (~m00k@adsl-74-235-42-147.clt.bellsouth.net) 20.40.28 Nick nosa is now known as nosa-j (~m00k@adsl-74-235-42-147.clt.bellsouth.net) 20.40.31 # meizu m6 (unusable), cowon iaudio 7, e200v1, c200v1, cowon d2 20.41.29 # I'll try reverting the last change to the driver and see if that makes a difference 20.42.09 Quit nosa-j (Read error: Connection reset by peer) 20.42.30 # meh, need more git skill 20.43.07 # I was hoping to do a revert with git revert lv24020lp.c 20.45.12 Join dhrasmus [0] (~dhrasmus@75-148-85-206-Oregon.hfc.comcastbusiness.net) 20.46.50 # Can't help there I'm afraid 20.47.41 Join enthdegree [0] (~BitchX@unaffiliated/enthdegree) 20.49.12 Join nosa-j [0] (~m00k@adsl-74-235-42-147.clt.bellsouth.net) 20.49.19 # hm, reverting the tuner_power stuff (on HEAD) does not fix it, so there must be something else going on 20.50.22 # at least when reverting the tuner_power stuff in just the lv24020lp.c fm tuner file 20.54.19 # * bertrik bisects 20.54.26 Join curtism [0] (~curtis@bas11-montreal02-1128531224.dsl.bell.ca) 20.54.26 Quit curtism (Changing host) 20.54.26 Join curtism [0] (~curtis@unaffiliated/programble) 20.55.45 # so… no help with the bricked clip+? I guess I'll just buy a new one, the case was broken too and the screen had dead lines 20.57.31 # riad: follow that wiki page you just mentioned, there's nothing else to do 20.59.58 # it's not working, I guess the player is dead for good. oh well 21.00.10 # I'll make do with the iPhone until I can get a real player again 21.03.07 Quit nosa-j (Ping timeout: 240 seconds) 21.06.59 Quit amiconn (Remote host closed the connection) 21.06.59 Quit pixelma (Read error: Connection reset by peer) 21.09.08 Join pixelma [0] (pixelma@rockbox/staff/pixelma) 21.09.09 Join amiconn [0] (amiconn@rockbox/developer/amiconn) 21.12.10 Join nosa-j [0] (~m00k@adsl-74-235-42-147.clt.bellsouth.net) 21.12.30 Quit saratoga_ (Ping timeout: 245 seconds) 21.13.16 *** Saving seen data "./dancer.seen" 21.17.14 Quit nosa-j (Ping timeout: 244 seconds) 21.22.15 # 906e90eb7b036214b2ee48ad2219e1ef679ee7d1 appears to be the culprit for the lv24020lp.c problem 21.24.19 Quit fs-bluebot (Remote host closed the connection) 21.26.37 Join fs-bluebot [0] (~fs-bluebo@g231123094.adsl.alicedsl.de) 21.26.44 Quit fs-bluebot (Remote host closed the connection) 21.29.31 # bertrik: maybe timing? 21.30.31 # I think some assumption about the radio already being on or off 21.30.40 # hmmm 21.30.48 # Oh 21.31.09 # Have a look at lv24020lp.c line 748 21.31.20 # Doesn't that one say "return if not powered"? 21.31.35 # i.e. isn't that tuner_power(true); 21.31.39 # too late? 21.32.50 Join fs-bluebot [0] (~fs-bluebo@g231123094.adsl.alicedsl.de) 21.33.12 Quit fs-bluebot (Client Quit) 21.34.12 # * bertrik struggles with git again 21.34.54 Join fs-bluebot [0] (~fs-bluebo@g231123094.adsl.alicedsl.de) 21.35.07 Quit fs-bluebot (Client Quit) 21.35.10 Quit Rower85 (Quit: Hmmm...) 21.35.55 # yes possibly 21.36.07 # I think http://paste.debian.net/161801/ makes it match more closely what was there before 21.36.37 Join fs-bluebot [0] (~fs-bluebo@g231123094.adsl.alicedsl.de) 21.37.16 # * bertrik tries that on target 21.39.01 # that works 21.39.45 Part riad 21.40.14 # * gevaerts looks through the diff for possible similar issues in other drivers 21.41.00 Join nosa-j [0] (~m00k@adsl-74-235-42-147.clt.bellsouth.net) 21.45.19 # bertrik: you're aware that you can .describe 906e90eb7b036214b2ee48ad2219e1ef679ee7d1 ? 21.45.19 # 3Move radio power handling from apps/ to drivers. by 3Amaury Pouly (from Sun, 5 Feb 2012 14:58:10 +0000) 21.45.19 # * bluebrother should cleanup the bot completely and then write a short overview in the wiki 21.45.20 # hmm 21.45.20 Quit factor (Remote host closed the connection) 21.45.21 # I'm not sure about si4700.c (the changes are a bit too big to understand immediately), and I'm a bit suspicious about tea5767.c. The others look ok at first sight 21.46.52 # I think the idea is that instead of the radio code directly calling tuner_power, it calls tuner_sleep in the tuner driver instead, which then does tuner_power (if proper for that tuner) 21.47.15 # Yes, that part is clear 21.48.12 # It's just that I'm not sure if tea5767.c isn't calling tuner_power(true) too late now 21.49.12 Quit petur (Quit: Bye) 21.49.37 Join petur [0] (~petur@rockbox/developer/petur) 21.51.06 # Does FM work on the AMS sansas? 21.51.09 Quit petur (Client Quit) 21.51.27 Join petur [0] (~petur@rockbox/developer/petur) 21.51.33 # * gevaerts grabs his h120 to see if tea5767.c works 21.51.51 # yes, it works on AMS sansa (like my clip zip) 21.52.05 Quit saratoga (Ping timeout: 245 seconds) 21.52.22 # ok, so si4700.c should be OK 21.52.53 # It's just that releasing a 3.11.1 with one tuner fixed and then having to follow up with 3.11.2 for another one would be rather silly 21.54.59 # agreed. I'll try AMS sansa HEAD just to be sure. 21.55.46 # yup, still works 21.56.07 # ok, h120 works, so tea5767.c seems fine 21.56.42 Quit martii (Ping timeout: 276 seconds) 21.57.04 # So if I didn't miss a mistake in one of the other drivers it's just lv24020lp.c 21.57.41 Join anewuser [0] (~anewuser@190.207.143.143) 21.57.42 Quit anewuser (Changing host) 21.57.42 Join anewuser [0] (~anewuser@unaffiliated/anewuser) 21.59.12 # bertrik: will you commit or shall I? 21.59.22 # If I could find my e200 I'd test that too 21.59.45 # I think mine is in the loft sadly 22.00.28 Quit fs-bluebot (Ping timeout: 246 seconds) 22.00.36 Quit bluebrother (Ping timeout: 240 seconds) 22.01.35 Join fs-bluebot [0] (~fs-bluebo@g231123120.adsl.alicedsl.de) 22.02.35 Join martii [0] (~martii@212.33.90.253) 22.02.36 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 22.02.37 # I think we should test e200, because that was the target the bug was reported against 22.02.59 # I found mine 22.03.19 # please tell us what rockbox version was on it :) 22.04.04 # r31467M-111230 22.04.25 # Quite recent I'd say :) 22.07.00 # AlexP: do we release 3.11.1 immediately (e.g. as soon as we can get it built and put in place by a Swede), or do we add this to the release notes and wait a few days to see what else turns up? 22.07.26 # (after I've tested on e200 of course) 22.07.36 # gevaerts: Well it is fairly major I think 22.10.05 # seems to work 22.10.07 # are there other tuners as well? I know of the older type some Archos have (a Samsung one, I believe) but I only know of LinusN owning one of those 22.11.04 # pixelma: there are a lot more, but all of the others were changed in a much more obviously correct way 22.12.04 # * bluebrother thinks that giving people a couple of days of finding other problems for a dot release is acceptable :) 22.12.18 Quit pamaury (Read error: Connection reset by peer) 22.12.20 # yeah, I agree with a day or two 22.12.40 # But not much more, we ought to get a fix out for this quite quickly 22.12.46 # Especially as it is now fixed :) 22.13.02 # people that do have a major problem with that can always use a current development build :) 22.13.32 # 1 or 2 days looks like the sweet spot for me too 22.13.39 Join pamaury [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net) 22.13.40 Quit pamaury (Changing host) 22.13.40 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 22.14.10 Quit TheLemonMan (Quit: WeeChat 0.3.7) 22.14.29 # Commit 416da22 in rockbox by 03Frank Gevaerts: Call tuner_power(true) from the correct place for lv24020lp. 22.14.41 # gevaerts, http://www.rockbox.org/wiki/FmTunerHardware has a list of tuner chips in use in rockbox targets 22.15.13 # Commit 107cfc2 in rockbox v3.11 by 03Frank Gevaerts: Call tuner_power(true) from the correct place for lv24020lp. 22.16.03 # Hm, do we close that bug report, or only after 3.11.1 is actually out? 22.16.43 # I fear that if we close it too soon, we'll get duplicates 22.17.58 Quit KiwiCam (Quit: Leaving) 22.18.04 # I checked this out because of a mail on the mailing list, don't know if there's a flyspray bug report for this yet 22.18.15 # There is 22.18.26 Quit The_prospector (Read error: Connection reset by peer) 22.18.35 # I'm replying to it now 22.18.41 # (the FS one) 22.19.34 Join The_prospector [0] (baconmaste@unaffiliated/cornman) 22.20.59 Join KiwiCam [0] (~KiwiCAM@101.98.171.48) 22.21.06 # hm, roolku's systems seem to have vanished 22.21.53 # And a few others 22.21.54 # hmmm 22.22.14 # * gevaerts found his client stuck earlier today 22.23.42 Join MCrase_ [0] (~mark@cpe-184-59-109-126.cinci.res.rr.com) 22.25.20 # Build client ML notified 22.25.39 # ouch, april 1st had a build with just 5 clients 22.27.38 Join GeekShad1w [0] (~antoine@50.104.75.86.rev.sfr.net) 22.28.08 Join n17ikh_ [0] (~peter@c-174-56-150-44.hsd1.sc.comcast.net) 22.28.17 Join ranmachan [0] (ranma@2a01:4f8:62:2262::2) 22.29.59 # bertrik: Yeah, that took ages :) 22.30.33 # If that is what we are reduced to I'll add my atom back in :) 22.30.56 Quit MCrase (Ping timeout: 260 seconds) 22.30.56 Quit lembas (Ping timeout: 260 seconds) 22.30.56 Quit crwl (Ping timeout: 260 seconds) 22.30.56 Quit GeekShadow (Ping timeout: 260 seconds) 22.30.56 Quit GodEater (Ping timeout: 260 seconds) 22.30.57 Quit n17ikh (Ping timeout: 260 seconds) 22.30.57 Quit ranma_ (Ping timeout: 260 seconds) 22.30.58 Quit pjm0616 (Ping timeout: 260 seconds) 22.30.58 Nick MCrase_ is now known as MCrase (~mark@cpe-184-59-109-126.cinci.res.rr.com) 22.30.58 Join notlembas [0] (iam@lembas.ws) 22.31.01 Join pjm0616 [0] (~user@175.209.206.227) 22.31.37 # gevaerts, the rda5802 tuner still works on my clip+ 22.31.39 # Does anyone remember at what time the server disappeared on Saturday? 22.32.50 Join crwl [0] (~crwlll@dsl-jklbrasgw1-ffb9c300-103.dhcp.inet.fi) 22.33.54 # 16:59 apparently, which seems to be an hour after my client got stuck 22.35.11 # 416da22 build result: 1 errors, 0 warnings (Frank Gevaerts committed) 22.35.38 # oh 22.35.54 # It seems we don't have any client with the ypr0 toolchain 22.36.03 # I have it, IIRC 22.36.35 # advertising it as arm-ypr0-gcc446 22.36.35 # gevaerts: my server got stuck around 15:57 22.37.14 # bertrik: you only joined later in the build, right? 22.37.23 # yes 22.38.11 # OK, maybe the server only looks at clients that are there from the start to determine which targets can be built. That would be a bug then I'd say 22.38.18 # ender`: ok, so fairly consistent 22.39.03 # So getting things going properly again is very probably just a matter of people kicking clients 22.40.56 Join GodEater [0] (~bibble@cl-711.lon-02.gb.sixxs.net) 22.40.56 Quit GodEater (Changing host) 22.40.56 Join GodEater [0] (~bibble@rockbox/staff/GodEater) 22.40.57 # i just hit Ctrl+C and it started working 22.41.19 # Yes, same here 23.13.19 *** Saving seen data "./dancer.seen" 23.31.34 Join lImbus [0] (~lImbus@p4FE05AD4.dip.t-dialin.net) 23.31.46 # hi all 23.41.05 Join saratoga [0] (980329c4@gateway/web/freenode/ip.152.3.41.196) 23.41.43 # bertrik: did you see my question about the clipzip battery channel before? 23.42.38 Nick n17ikh_ is now known as n17ikh (~peter@c-174-56-150-44.hsd1.sc.comcast.net) 23.42.42 Quit dfkt (Quit: -= SysReset 2.55=- Sic gorgiamus allos subjectatos nunc.) 23.50.14 Join The_prospector|2 [0] (baconmaste@unaffiliated/cornman) 23.50.16 Quit The_prospector (Read error: Connection reset by peer) 23.51.51 Join SeaWeed [0] (~SeaWeed@c-67-187-7-172.hsd1.va.comcast.net)