--- Log for 25.09.111 Server: asimov.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 18 hours and 39 minutes ago 00.00.14 Join Rob2223 [0] (~Miranda@p5DE4BFA3.dip.t-dialin.net) 00.00.53 Quit pamaury (Remote host closed the connection) 00.02.26 Quit Keripo (Ping timeout: 256 seconds) 00.02.29 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 00.03.45 # kugel: Do you have an idea what might be going wrong there? 00.03.46 # * amiconn is lost in the talk/ buflib/ tagtree init maze 00.03.54 Quit Rob2222 (Ping timeout: 245 seconds) 00.06.16 Quit bertrik (Quit: And That, My Liege, Is How We Know the Earth to Be Banana Shaped) 00.09.23 Join Topy44 [0] (~Topy44@f049198255.adsl.alicedsl.de) 00.10.22 Quit T44 (Ping timeout: 256 seconds) 00.20.43 Join natedev [0] (~18f619de@www.haxx.se) 00.22.15 # hey is there any infrastructure for doing kernal prints or application prints and storing them to a log file? How about sending them over USB to a tool to display them in realtime? 00.26.12 Quit gbl08ma__ (Quit: Saindo) 00.27.48 Join T44 [0] (~Topy44@f049010140.adsl.alicedsl.de) 00.31.42 Quit Topy44 (Ping timeout: 248 seconds) 00.33.53 Quit n1s (Remote host closed the connection) 00.40.33 Quit pamaury (Read error: Connection reset by peer) 00.47.34 # amiconn: no 00.50.21 # talk is very badly integrated in general 00.55.43 Quit petur (Quit: Leaving) 01.06.18 Join Topy [0] (~Topy44@f048004114.adsl.alicedsl.de) 01.06.52 Quit natedev (Quit: CGI:IRC (EOF)) 01.09.34 Quit T44 (Ping timeout: 248 seconds) 01.14.30 Quit scorche (Disconnected by services) 01.14.44 Join scorche` [0] (~scorche@rockbox/administrator/scorche) 01.16.18 Join freddyb [0] (~freddybbb@rrcs-24-123-73-214.central.biz.rr.com) 01.16.35 Quit freddyb (Client Quit) 01.20.57 # * amiconn is even more puzzled 01.21.08 *** Saving seen data "./dancer.seen" 01.22.14 # kugel: Apparently the hang on target since r30312 which doesn't affect the sim has been fixed in r30380. The crash problem which also affects the sim if voice is enabled & present appears somewhere between r30380 and r30386 01.22.24 # Probably r30381 - will test 01.26.44 # Err, 30381 and 30382 don't build 01.27.42 # Okay, and 30379 hangs 01.28.26 # So r30380 fixes the hang (which hence doesn't need to be tracked down), and r30381 (+2+3) introduces the crash 01.29.35 # The sim only crashes when voice is enabled and a matching voice file is present. Target also crashes if either doesn't apply, but then it crashes at another address. It's probably still related 01.30.20 Join FlynDice [0] (~FlynDice@107.63.246.240) 01.35.59 # Hello old friends... r30595 is crashing on the clip+ The bootloader flashes Rockbox and then I get a dark screen and have to reset with a long power press. Don't have time to pinpoint a revision now but didn't see a report yet. I've installed it 2 times with same result. 01.36.32 Quit FlynDice (Quit: Gotta go fly!) 01.36.46 # amiconn: when does it crash exactly? 01.37.01 # At boot, while the boot screen is displayed 01.38.07 # so at init? 01.38.35 # Yes, precisely in tagtree_init() - but only if coice is enabled & matching voice file present 01.38.45 # s/coice/voice/ 01.39.33 # oh I thought that was the hang, sorry 01.39.42 # * kugel confused the problems for a moment 01.40.03 # right, get_tag() crashes because of bad pointer 01.40.22 # No. I don't know where the hang happened exactly, as it didn't happen in the sim and it doesn't give an address on target 01.40.29 # I suspect the memory gets overwritten 01.40.35 # perhaps by talk buffer or so 01.41.19 # Yes. I bet it will crash a little earlier on target as well (same place as in the sim) if I enable memory guard 01.42.41 # Problem is that target won't catch out-of-bounds accesses because there's no mmu. Address space 0x0000nnnn can normally be accessed without destroying anything, as it is rom space, but of course without the desired end result 01.42.57 # talk.c should receive its buffer from mpeg.c 01.43.01 # memory guard *can* catch accesses to the rom area 01.45.44 # Hmm, unfortunately it won't tell us much because there is no backtrace 01.45.58 # It will probably crash in something like strcpy() 01.46.13 # So the sim is a better choice 01.48.46 Quit [Saint] (Quit: Imagination is for turbo-nerds who can't handle how kick-butt reality is. I'm a kick-butt reality master! I would rather die, than be imaginative. I mean that.) 01.50.03 Join AlexP [0] (~alex@rockbox/staff/AlexP) 01.51.36 # amiconn: bt full shows a bit more (bad pointer for dest for strcpy) 01.52.13 # I already reported that earlier here too (by setting a breakpoint and printing the variable) 01.53.46 # tagtree gets its memory block from buflib iiuc, and talk.c does too (shared with mpeg.c for hwcodec) 01.53.50 Quit Topy (Ping timeout: 248 seconds) 01.55.33 Join Topy44 [0] (~Topy44@g228232240.adsl.alicedsl.de) 01.56.34 # So something is going wrong within buflib, and it has been introduced when enabling compaction 01.58.38 # printing the result of core_get_data() shows that it's chaning between invocations 01.59.59 # hm, inspecting core_ctx (what core_* wraps around) gives strange results 02.01.43 # err 02.01.58 # the very first tagtree_alloc() call allocs 9MB 02.02.47 # ah nvm 02.02.49 # How can it allocate more memory than there is? 02.04.09 # voicebuf and p_thumbnail are still NULL, so I don't know 02.06.04 # hmmm 02.06.38 Nick scorche` is now known as scorche (~scorche@rockbox/administrator/scorche) 02.07.02 # amiconn: the first tagtree_alloc0 call destroys buflibs handle table :\ 02.08.17 # The question is why it only does that when voice is present. talk_init() is called from settings_apply() uuic, and that's called before tagtree_init() 02.09.01 # core_alloc_maximum() returns 0 for tagtree_bufsize but still a valid handle??? 02.09.10 # Hmm, or perhaps it also does that when voice is not present, just the effect is slightly different. Might explain the other crash I saw on target with voice disabled 02.09.31 # (somewhere in font code) 02.09.54 Quit hilbert (Quit: Textual IRC Client: http://www.textualapp.com/) 02.11.33 Join T44 [0] (~Topy44@f049108086.adsl.alicedsl.de) 02.14.22 # amiconn: because talk_init() calls audio_get_buffer() if a voicefile is present 02.14.38 Quit Topy44 (Ping timeout: 248 seconds) 02.15.15 # which calls core_alloc_maximum() 02.15.27 # that's so early that further calls to that fail, like the one in tagtree 02.21.32 # Voice on hwcodec is special in that it can (should) be thrown out of ram if something else (like playback) needs the buffer 02.22.19 # audio_get_buffer() behave differently between sw and hwcodec 02.26.33 # amiconn: this should fix it http://pastie.org/2586810 02.27.44 Quit dfkt|n () 02.28.03 Quit bieber (Ping timeout: 256 seconds) 02.28.42 # I can't remember if there was some reason to make audio_get_buffer behave that way on hwcodec 02.31.06 # Hmm, this fixes the crash in tagtree_init(), but not the second crash :/ 02.31.23 # Unfortunately I haven't been able to reproduce the second on in the sim 02.31.39 # :( 02.32.39 # where is that one? 02.32.50 # In font_unload() near the beginning 02.34.08 # perhaps introduced with JdGordon's commit? 02.36.01 # * amiconn tries r30588 with kugel's fix 02.36.14 # gevaerts: %xd(label, %LI, 1) will fix your off by one issue 02.36.33 Join Jak_o_Shadows [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au) 02.37.13 Join bieber [0] (~quassel@162-78.97-97.tampabay.res.rr.com) 02.37.19 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 02.37.38 # Bleh, r30588 + fix hangs :( 02.39.30 # just tried r30584 and it doesn't hang in the sim 02.40.20 # Yeah, sim didn't hang with r30312..r30379 which hung on target too 02.40.31 # Lalufu: BUTTON_RC_PLAY is proobably mapped to ACTION_STD_OK in the keymap file 02.42.47 # I will try to track down where it hangs exactly, unless someone beats me to it 02.43.13 # I need to go to bed 02.43.42 # JdGordon: font in buflib crashes on hwcodec (unaligned access in font_unload() during boot). Currently covered by another (earlier) crash which kugel just pasted the fix for 02.49.25 Nick soap_ is now known as soap (~soap@rockbox/staff/soap) 02.56.41 Quit liar (Remote host closed the connection) 03.06.18 Join Topy [0] (~Topy44@f048133111.adsl.alicedsl.de) 03.10.06 Quit T44 (Ping timeout: 248 seconds) 03.10.21 # [saint] you kill me sometimes! :/ 03.10.32 # touch tags arent rejected on non touch targets 03.10.36 # they are *ignored* 03.11.08 # recording tags are rejected, but if you use the recroding *feature* tag they wont get parsed so it will work 03.13.46 # as for comments allocing buffer.. yeah, thats a bug, though i havnt looked into it very much, it absolutly shouldnt be as the code for that is #ifdefed out on ROCKBOX builds 03.18.25 Quit MethoS- (Read error: Connection reset by peer) 03.21.11 *** Saving seen data "./dancer.seen" 03.23.51 Quit mystica555 (Ping timeout: 276 seconds) 03.28.12 Join mystica555 [0] (~mike@71-211-199-174.hlrn.qwest.net) 03.35.14 Join T44 [0] (~Topy44@f049235155.adsl.alicedsl.de) 03.38.54 Quit Topy (Ping timeout: 248 seconds) 03.47.52 Join Jak_o_Shadows1 [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au) 03.50.09 Quit Jak_o_Shadows (Ping timeout: 245 seconds) 04.40.40 Quit amiconn (Disconnected by services) 04.40.40 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.40.40 Quit pixelma (Disconnected by services) 04.40.42 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.40.44 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.41.02 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.43.42 Quit simonlnu (Quit: bbl) 04.45.35 Quit [7] (Disconnected by services) 04.45.46 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 04.46.27 Quit mamarley (Remote host closed the connection) 04.55.52 Join mamarley [0] (~quassel@2001:470:5:84d:221:6aff:fe19:4d0c) 04.59.45 # how much pain will I feel migrating from Ubuntu 32 to Ubuntu 64? 04.59.56 # i want to give my VM more RAM. 05.12.01 # I guess the first step in making a port is to figure out what cpu, rom, ram, file-system structure the device has? 05.21.15 *** Saving seen data "./dancer.seen" 05.38.27 Quit T44 (Read error: Connection reset by peer) 05.39.07 Join Topy44 [0] (~Topy44@f049235155.adsl.alicedsl.de) 05.56.23 Join Rob2222 [0] (~Miranda@p5DE4B69B.dip.t-dialin.net) 06.01.10 Quit Rob2223 (Ping timeout: 276 seconds) 06.48.42 Join Jak_o_Shadows [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au) 06.51.18 Quit Jak_o_Shadows1 (Ping timeout: 260 seconds) 07.06.34 Join simonlnu [0] (~simon@unaffiliated/simonrvn) 07.21.19 *** Saving seen data "./dancer.seen" 07.48.55 Join Jak_o_Shadows1 [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au) 07.51.04 Quit Jak_o_Shadows (Ping timeout: 256 seconds) 08.10.05 Quit powell14ski (Quit: powell14ski) 08.49.35 Join Jak_o_Shadows [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au) 08.51.00 Quit Jak_o_Shadows1 (Ping timeout: 245 seconds) 09.02.37 Join y4n [0] (y4n@unaffiliated/y4ndexx) 09.17.34 Join kadoban [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 09.21.24 *** Saving seen data "./dancer.seen" 09.43.38 # New commit by 03jdgordon (r30596): Partial fix for FS#12289 - comment lines would waste lots of buffer space. Still not perfect but should get 90+% of comments completly ignored now. 09.45.43 # r30596 build result: All green 09.50.16 Join Jak_o_Shadows1 [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au) 09.52.43 Quit Jak_o_Shadows (Ping timeout: 260 seconds) 09.53.46 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 09.56.00 Join stooo [0] (~sto@g226141003.adsl.alicedsl.de) 09.56.06 Quit stooo (Client Quit) 09.56.46 Join n1s [0] (~quassel@rockbox/developer/n1s) 10.12.51 # moin, do you have a recommendation for tools/workflows to rip cds? 10.13.18 # #rockbox-community for that ukleinek 10.13.50 # JdGordon: sorry, wondered about being off-topic after pressing enter 10.16.14 Quit kadoban (Ping timeout: 248 seconds) 10.17.50 # * JdGordon has a script to debug skin allocations 10.17.56 Quit AlexP (Remote host closed the connection) 10.18.08 # the ilike theme allocates 40KB in strings, mostly 2 and 3 chars long! 10.18.17 # 645 of them! 10.18.27 # wow 10.19.04 # it was also doing 20+KB in empty elements because of the comment lines which the above commit fixes 10.36.38 # Lalufu, the state machine approach to iap worked for you, right? I'm thinking of committing at least that part. 10.50.36 Join Jak_o_Shadows [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au) 10.52.30 Quit Jak_o_Shadows1 (Ping timeout: 248 seconds) 11.11.46 # soap: just change kernel to 64bit 11.18.21 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 11.19.58 Join TheLemonMan [0] (~LemonBoy@ppp-158-36.26-151.libero.it) 11.21.25 *** Saving seen data "./dancer.seen" 11.46.48 # hmm, I'm currently looking at the sansa Fuzev2 simulator and wonder about the .mpu view 11.47.16 # my filenames are utf-8 encoded and they show up nicely in the directory view 11.47.57 # but when looking at an .m3u (not t .mpu) the umlauts look strage 11.48.01 # *strange 11.48.26 # (sorry for the typos, I'm on a slow connection here) 11.51.33 Join Jak_o_Shadows1 [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au) 11.54.46 Quit Jak_o_Shadows (Ping timeout: 276 seconds) 11.56.47 Join [Saint] [0] (~st.lasciv@203.184.50.187) 12.13.22 # also when selecting the .m3u files with umlauts don't get properly added 12.15.07 Join lovasoa [0] (~lovasoa@2a01:e35:8a2e:8080:e2b9:a5ff:fe5b:ca7b) 12.18.27 Join MethoS- [0] (~clemens@134.102.106.250) 12.26.24 # <[Saint]> ukleinek: That's your font, or codepage setting's problem. 12.26.34 # how do people think about function pointers in the viewport struct? 12.35.13 Quit factor (Read error: Connection reset by peer) 12.36.38 # [Saint]: it wouldn't be the font 12.37.17 Join veve [0] (~veverone@79.112.116.235) 12.37.33 # <[Saint]> rasher: Yeah, I thought of that after I pressed enter, but I'd mentioned the codepage also...so, I fugured I was covered ;) 12.37.43 # hi 12.37.44 # <[Saint]> *figured, too. 12.38.51 # does anybody know if the latest version of Rockbox 3.9.1 on Sansa Clip v1 will cause the battery to drain 2x faster than with the original firmware? 12.39.10 # <[Saint]> veve: Why would you think it would? 12.39.55 # this was an issue some time ago and it was reported and confirmed (let me search for that link) 12.40.48 # quote: "Clipv1/c200v2/m200v4/e200v2/Fuzev1*: Battery life is quite shorter than when using the original firmware (OF). See SansaRuntime also FS#11765. Some (unknown) hardware is likely misconfigured leading to higher power consumption. " 12.40.50 # http://www.rockbox.org/tracker/task/11765 3Improve Battery Life on AMSv1 Sansa players (patches, new) 12.40.56 # http://www.rockbox.org/wiki/SansaAMS#AMSv1_issues_40m200v4_44_c200v2_44_e200v2_44_Fuzev1_44_Clipv1_41 12.41.46 # fs-bluebot: you are a boot or a real person :)) ? (I need to know if I have to thank you or not) 12.42.12 # <[Saint]> "he" is neither a boot, nor a person ;) 12.42.35 # boy* 12.42.37 # bot** 12.42.40 # :P 12.43.28 # <[Saint]> where are you getting the "2X faster" values from? 12.43.40 # <[Saint]> Battery life *is* poorer than the OF, but, not be that much. 12.43.59 # <[Saint]> the author of the patch saw a 27% increase. 12.44.38 # <[Saint]> and ClipV1 runtime was ~10 hours in ~2010 12.44.56 # well... if you look here >> http://www.rockbox.org/wiki/SansaRuntime#Results you can see that the average time with Rockbox is 9 hours 12.45.03 # for mp3 12.45.12 # and with the original firmware is 15 12.45.14 # BUT 12.45.35 # this information is very old and I've searched the internet for information 12.45.40 # <[Saint]> right, that's not "2X faster", though. 12.45.47 # <[Saint]> even if it were current data. 12.46.38 # oh, yeah, it's not :). it is 1.6x faster, for the code available in 2010 12.47.00 # I don't want to be disrespectful 12.47.17 # <[Saint]> For some reason, the V2 and the + do *way* better than the V1...I don't think the reason for this is understood at all. 12.47.39 # it's just a question, if somebody knows that this is fixed or improved (because I already searched the net and i didn't found anything relevant) 12.47.48 # <[Saint]> If it were, it wouldn;t be an issue, as it'd be fixed ;) 12.48.07 # ;)) true true 12.48.35 # Where can I find the offset used to display the LCD contents as an overlay on the player image in the simulator? 12.49.53 # [Saint]: do you think that I have to apply that patch to the latest version of rockbox? it seems that this ticket was opened and not updated for some time 12.50.04 # <[Saint]> If I remember correctly, the patch you linked provided good battery savings, at the expense of erratic uSD behaviour. 12.50.11 # <[Saint]> (for some players) 12.50.32 # uSD on AMS/AMSv2 has seen some fixes in the meantime 12.50.47 Join factor [0] (~factor@74.197.205.204) 12.50.48 # <[Saint]> veve: It may, or may not, apply to current svn. I couldn't say. 12.51.09 # Which reminds me that we are currently not using 4-bit mode but 1-bit mode for AMS targets 12.51.17 # <[Saint]> The fixes to get it to apply should be trivial, however. 12.51.39 # <[Saint]> (disclaimer: may not be the case, its an old patch ;)) 12.52.25 # I will give this version a try. I never did a battery test, so I'll have to do some preparations if I decide to do it (I feel inspired by some stuff regarding battery tests, stuff that I read in the last hours) 12.52.27 Join fml [0] (~chatzilla@manz-590f3bf8.pool.mediaWays.net) 12.52.47 # I will post the results :) 12.52.50 # for now, thank you 12.53.26 # JdGordon: Hello. Have you seen the discussion yesterday re %Vf(xxx) not working (%Vs(color,xxx) still working)? 12.53.59 # rasher: It would be nice if the SVN version number would be displayed on the sim download page, not just the date. 12.54.42 # fml: hover over the date 12.56.02 # rasher: Ah! But it's hard to know that this exists. Why not write in out? 12.56.30 Quit veve (Quit: KVIrc 4.0.2 Insomnia http://www.kvirc.net/) 12.57.09 # fml: No particular reason - I had the date there first and just added the revision like that because I felt it'd look a bit cluttered and most people probably don't care (plus you can see the revision once you run it) 13.01.16 Quit fml (Quit: ChatZilla 0.9.87 [Firefox 6.0.2/20110902133214]) 13.01.56 # <[Saint]> In hindsight, the reverse would probably be of more use. Maybe. The revision changes several times a day, where the date doesn't. 13.02.26 # On the other hand it's hard to know at a glance if r30457 is up to date 13.02.39 # <[Saint]> that's true. 13.04.42 # Now it has both 13.09.01 # bertrik: works fine so far for me. I made a few additions, but all of those should be in FS12135 13.15.44 Join hilbert [0] (~hilbert@adsl-89-217-163-45.adslplus.ch) 13.21.28 *** Saving seen data "./dancer.seen" 13.22.46 # what is the cleanest option with respect to our buildchain if I want to compile *one* c file to elf and then objcopy it just like for the bootloader or the main firmware ? I need it to dual-boot 13.24.43 # This is approximately how the rockbox main menu will look on the Sansa Clip Zip: http://imagebin.org/173953 13.29.27 # Lalufu, ok, I'll commit that part then 13.31.31 Join fyre^OS [0] (~nnscript@cpe-24-90-84-81.nyc.res.rr.com) 13.33.53 # At least the main menu items still fit horizontally on the sansa clip zip screen 13.34.58 Quit fyrestorm (Ping timeout: 260 seconds) 13.43.15 Quit MethoS- (Remote host closed the connection) 13.47.38 # fml: yes, but i've no plans to fix it any time soon so if someone wants to have a go they are free to 13.48.59 # [Saint]: your ilike theme does some really bad stuff regarding skin buffer usage 13.49.28 # <[Saint]> "really bad stuff"...that worked fine until you messed it up :) 13.49.46 # <[Saint]> comments are supposed to not count towards the skin RAm usage, I thought. 13.50.13 # yes, well they sort of do (did) 13.50.21 # kugel: function points to do what? 13.50.40 # line height getter 13.50.57 # <[Saint]> ...which is why I never gave a flying f**k about them, but, now the Ilike Nano theme needs comments stripped or max_tokens upped just to laod. 13.51.10 # kugel: err why? 13.51.14 # [Saint]: its fixed now :) 13.51.22 # <[Saint]> JdGordon: Ah, awesome. 13.51.27 # <[Saint]> I missed that. 13.51.53 # but i spent some time today looking into other issues and your ilike nano theme allocates 41KB *KILOBYTES* for static strings 13.51.54 Join Jak_o_Shadows [0] (~hayden@CPE-144-136-211-121.sa.bigpond.net.au) 13.52.03 # i.e all the image labels 13.52.12 # <[Saint]> "meh". 13.52.16 # 645 allocs totally 41KB 13.52.25 # <[Saint]> It wasn't possible to reduce that when that theme was made. 13.52.32 # <[Saint]> and, I've not touched in in months. 13.52.41 # oh I know 13.52.52 # just saying :) 13.53.05 Quit Jak_o_Shadows1 (Ping timeout: 245 seconds) 13.53.14 # its probably a good usecase to figure out other wastage though 13.53.27 # <[Saint]> %?XX(identifier,tag) wasn't possible at that stage. 13.53.45 # I've got a list of 18 functions doing allocations in the order of count and accumulated cost of each 13.54.05 # the second worst offender is %V 13.54.13 # 3.6K 13.54.32 # i.e I know i need to look into why the fist case is so terrible 13.54.50 # <[Saint]> On the topic of line height, kugel, why? 13.54.58 # * [Saint] is genuinely curious. 13.55.17 # have functions to select the line height based on user setting 13.55.23 # <[Saint]> I think the theme should handle the line height, personally. 13.55.31 # <[Saint]> then its a per screen setting. 13.55.31 # where outside of lists would the line height matter? 13.55.36 # <[Saint]> not forced for all lists. 13.56.19 # I would hate if one list is different than the previous one 13.56.47 # JdGordon: at no place, but lcd.c needs the line height but can't just access global_settings 13.56.59 # so I set the getter in apps/ and lcd.c just calls this 13.57.03 # <[Saint]> Well, I personally *might* want a bit of spacing in the main menu, but *not* for long scrolling lists. If the line isn't selectable, its the themes fault. It should be usable without spacing. 13.57.09 # but it's sure doable in another way if it's hated 13.57.22 # <[Saint]> long srolling lists with lots os spacing makes them....longer. 13.57.33 # yeah, no, i dont like it, skinned lists are the way to do that 13.57.41 # * [Saint] nods. 13.57.47 # (a getter is needed in the first place to not cache font height/absolute height in case either changes) 13.58.15 # kugel: can't you add a setter to lcd.c that is called when it changes? 13.58.17 # why skinned lists? 13.58.30 # not everyone is using them 13.59.00 # list height is not about eye candy, it's about usability 13.59.04 # line height* 13.59.13 # *COUGH* I see no reason why it is needed outside of lists, therefore its wrong 13.59.28 # so? 13.59.31 # <[Saint]> I'd *hate* this to be forced. Make a setting for it, and I'd consider considering it. But, skinned lists are far more versatile. 14.00.12 Quit lovasoa (Ping timeout: 240 seconds) 14.00.14 # I want rockbox to be usable without special theme support 14.00.30 # [Saint]: I'm doing the setting, as I just wrote 14.00.30 # so? thats the same argument you give me often enough 14.00.51 # <[Saint]> I find 28px completely usable...you get 10 px higer and can't use it? 14.01.00 # <[Saint]> on a larger screen, too. 14.01.27 # <[Saint]> If the lists aren't usable, that's my fault, apparently...or your screen is weird. 14.02.08 # or we have different opinions about usability 14.02.24 Quit antil33t (Read error: Connection reset by peer) 14.02.29 # <[Saint]> How is that possibly? How many definitions are there? 14.02.44 # I find getting sufficiently large lines (for my thumbg) only via huge fonts not usable 14.02.48 Join antil33t [0] (~antil33t@203-100-223-143.callplus.net.nz) 14.03.07 # <[Saint]> "I can use the lists with perfect accuracy", is my definition in this case. 14.03.22 # perhaps you use them differently 14.03.27 # <[Saint]> and by percentile of total screen hieght, my lists are a lot smaller. 14.03.44 # <[Saint]> s/,y/240/320/ 14.03.47 # <[Saint]> *my 14.04.41 # <[Saint]> I think even the 480x800 port has "smaller" lists compared to the 320x480 port. 14.04.48 # [Saint]: that you can use them with perfect accuracy doesnt mean anyone else does 14.05.02 # <[Saint]> I haven't had any complaints... 14.05.05 # New commit by 03jdgordon (r30597): Add a simple perl script to display info about what is allocating skin buffer. ... 14.05.14 # <[Saint]> And there's a few hundred people using it. 14.05.15 # that doesn't mean anything 14.05.29 # and I had complained if my list spacing patch wasn't already applied 14.05.39 # a setting is the wrong place for this 14.06.05 # well, *I* don't need a setting anyone 14.06.15 # anyway 14.06.21 # especially when if anyone uses skinned lists anyway the setting will be ignored 14.06.49 # <[Saint]> when you brought it up the last time, I believe I wasn't the only one that said it was terrible on 240x320, how does it cope with this now? 14.07.01 # I want it to be based on the screen lcd. I don't care what skinned lists do to it if I don't use a theme with them 14.07.19 # r30597 build result: All green 14.07.52 # <[Saint]> Well, shouldn't we only care about the default theme? Which is still under development, so there's nothing saying it *won't* use them. 14.08.06 # <[Saint]> Or...that it will, to be honest. 14.08.57 # I thought you're done on development and in the bug fix phase? 14.10.10 # <[Saint]> Not exactly, no. Its been constantly changing for a long time. I have no reason to believe it won't continue to either, as things like this happen. 14.10.36 # <[Saint]> Your port was the last completed, so now I have to deal with your issues. 14.10.41 # <[Saint]> I knew it was coming. 14.10.47 # [Saint]: err oops, the 41KB is on the skin_element items, so not much you can do about it.. every tag creates 1, and every sub/line and every conditionalal etc 14.10.49 # well, we didn't even decide if we even want it, or in which form 14.11.27 # 1KB in strings 14.11.35 # what do you want to use skinned lists for? 14.12.18 # <[Saint]> To space the lists, conditionally. By screen. *maybe*, if in fact more poeple than just yourself think its even necessary. 14.12.37 # <[Saint]> I've no indication that's the case presently. 14.12.51 # that sounds horrible, imo 14.13.08 # <[Saint]> As horrible as forcing spacing in all lists sounds to me. 14.13.19 # <[Saint]> its hard enough to scroll long lists without making them longer. 14.13.22 # I'm doing the setting didn't you hear? 14.13.40 # <[Saint]> which will turn it off *everywhere*. 14.13.40 # have you used the scrollbar? 14.14.07 # <[Saint]> the scrollbar scrolls way too fast to be useful really. Unless its an alphabetical list. 14.14.34 # <[Saint]> if the list isn;t ordered, and you want to review it, its terrible if the list is sufficiently long. 14.14.41 # so, what you actually want is faster scrolling, not smaller linesß 14.14.48 # ? 14.14.52 # <[Saint]> slower. 14.15.16 # slower? 14.15.30 # with smaller lines it gets faster 14.16.36 # does anyone else here think that lists looking differently (instead of uniform throughout rockbox) is a good ui design decision? 14.17.05 # not only _looking_, the line height has a clear impact on the usability 14.17.26 # I don't want this for the default theme 14.17.38 # you're the only one bringing this up, and there is already a very workable solution 14.18.07 # JdGordon: where? 14.18.18 # a custom theme? 14.18.38 # <[Saint]> ...why not? 14.18.41 # I find this is only remotely related to theming 14.18.47 # <[Saint]> So far, you're the only one bringing this up. 14.19.29 # what. I should shut up because I'm the only one currently? 14.19.34 # New commit by 03bertrik (r30598): IAP: use a state machine for handling iap packets, based on FS#12135 14.19.56 # anyone around here using current release rockbox versions with an iPod, and using attached devices of any kind? 14.20.24 # (headphones do not count as "attached devices" here :) 14.20.31 # <[Saint]> No, I'm not saying that. Just that maybe you have a different idea than the rest about whats usable, so maybe a custom theme is a more workable solution than adding yet another setting for something that has a solution already. 14.20.38 # kugel: no you shdont' need to shutup, but you're in the minority, and yes this is entirely a theme issue 14.20.48 # it isn't 14.20.57 # you already said you cant tihnk of anywhere outside of a themeable screen this would be needed 14.21.08 # whether I can use my thumb to select items or not is *not* a theme issue 14.21.15 # <[Saint]> I could even easily add a toggle, on a per screen basis, to expand and contract lists. 14.21.42 # r30598 build result: All green 14.22.22 # fwiw, I have support for the patch in its old form 14.22.26 # does the packed sturct attribute make gcc reorder the items so individual items are type-aligned like they should be? 14.22.37 # just making it commitable with a setting to make you happy 14.23.01 # <[Saint]> "have support"? 14.23.09 # * [Saint] doesn't follow. 14.23.24 # <[Saint]> At the end of the day, I really don't care...so long as its not forced. 14.23.34 # <[Saint]> but I do think its a theme issue. 14.23.41 # it isnt commitable 14.23.42 # even with a settin g it isnt 14.23.43 # AlexP and GodEater said it makes rockbox usable 14.23.49 # (while svn isn't) 14.24.25 Join lovasoa [0] (~lovasoa@2a01:e35:8a2e:8080:e2b9:a5ff:fe5b:ca7b) 14.24.30 # <[Saint]> kugel: the same Alexp and GodEater that have reported no issues whatsoever with my theme? 14.24.40 # JdGordon, no I don't think they are reordered 14.24.44 # <[Saint]> I wasn't aware they were running custom builds, that's annoying. 14.24.56 # [Saint]: yes. perhaps they had my patch applied when trying 14.25.09 # <[Saint]> usability testing means nothing, in that case,. fuck it. 14.25.30 # * [Saint] grumbles now about being misslead ;) 14.26.13 # also, it might be that with a sufficiently large font it becomes usable, but very ugly at the same time 14.26.25 # <[Saint]> (and, fwiw, they *have* reported multiple issues with my theme...I worded that incorrectly. They've both been a great help. I've had no complaints about the lists though) 14.26.29 # <[Saint]> ...this may be why. 14.26.30 # <[Saint]> dammit. 14.27.24 # well, the test builds you provided also have a bunch of patches applied no? 14.27.39 # bertrik: hmm, ok, . it appears saving 4 bytes per item I could save quite a bit of waste :/ but i tihnk i wont bother 14.28.12 # <[Saint]> I stopped providing builds a long time ago. the first run of the theme needed a few changes not currently in svn, so I distributed my private build as it was easier. 14.28.14 # it might even result in items getting unaligned and lot of extra code generated to access the items 14.28.25 # <[Saint]> Now there's no need for non-svn, I don't supply builds. 14.28.34 # <[Saint]> (there was nothing list related, either) 14.30.17 # <[Saint]> How would this setting (lets say it does get committed) cope if it encountered skinned lists? 14.30.27 # it would break horribly 14.30.28 # <[Saint]> fail silently? 14.30.35 # it will also break every wps virewport 14.30.39 # skinned list would probably override it 14.30.41 # i.e its a really bad idea 14.30.53 # why break horribly? 14.32.05 # wps viewports have nothing to do with it 14.32.20 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) 14.34.33 # <[Saint]> I know it adds another layer of complexity, and another setting. But I'd prefer (were this to be committed) that there was an on/off setting, as well as a value setting, instead of trying to guess the height to expand the lists based on font and/or screen height. 14.34.43 # fwiw, skinned lists only work for a single resolution. I aim to just work for all screens 14.34.50 # <[Saint]> then it's truly be a user's preference as to what they thought was usable. 14.35.14 # <[Saint]> on/off, and a value divisable by two to expand the lists by in pixels. 14.35.33 # I'm very against this setting, and as I'm really the only one active in this i tihnk that should mean something 14.35.44 # <[Saint]> or even just 0 == off, 2,4,6,8etc. 14.35.56 # * JdGordon thought you were doing *svn* builds kugelp ? 14.36.10 # if you're doing custom builds anyway why cant my buflib malloc patch go in? 14.36.11 # Are you talking about list padding? 14.36.21 # <[Saint]> rasher: It seems that way. 14.36.25 # I don't do any builds 14.36.52 # <[Saint]> I believe he was referring to an ealier statement of yours. 14.37.07 # That sounds like something that should prooobably be a setting. No need for multiple ones though, just an int defining how many pixels to add on each side? 14.37.54 # <[Saint]> rasher: I disagree. There's a lot of difference in touchscreens apparently. 14.38.06 # [Saint]: huh? 14.38.15 # what is the last point anything can call buffer_alloc() before buflib takes over? 14.38.16 # <[Saint]> a user should be able to specify the inscrease in padding, not have a forced value that may be too much/little 14.38.21 # [Saint]: What do you disagree with? 14.39.05 # <[Saint]> Ah...I missinterpreted that, nevermind. .... 14.39.24 # <[Saint]> I just re-read it and realised you said exactly what I did, only in a different way. 14.41.16 # <[Saint]> But, yeah..."Settings - LCD Settings - Pad Lists - 0,2,4,6,8,etc." I wouldn't mind. If it worked in harmony with skinned lists. 14.41.20 # JdGordon: buffer_alloc() is dead 14.41.42 # <[Saint]> (where "in harmony" == "skinned lists negate list padding if present) 14.42.27 # [Saint]: Why only even numbers? That just looks silly 14.42.43 # <[Saint]> rasher, to senter the lists inside the padding. 14.42.48 # <[Saint]> *center too 14.42.53 # kugelp: how do i stallocate a buffer which wont move? 14.43.09 # or im forced to use buflib and make sure to be the first to do so 14.43.09 # you don't 14.43.10 # [Saint]: you can do that with any number - just interpret it as padding on each side 14.43.46 # what do you want to do? 14.43.53 # <[Saint]> How could you then, add 1px paddign top/bottom (say you wanted to) 14.44.02 # [Saint]: set padding to 1 14.44.20 # <[Saint]> Ah, right. *derp*. 14.45.47 # <[Saint]> I'd prefer it to be divisable by two and reflect the total amount of padding applied, but, I guess that's entirely personal. 14.46.24 # <[Saint]> It wouldn't be immediately obvious to me that padding == 1 applied 2px of padding. 14.47.52 # * rasher shrugs 14.47.54 # it just a number 14.48.15 # No one cares about pixels, just the end result! 14.49.19 # <[Saint]> right, volume should be : silent, quiet, louder, a bit louder still, loud, really loud...then :) 14.49.23 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 14.49.56 # the number could translate to different pixels on different displays :-) 14.54.58 Quit [Saint] (Quit: Imagination is for turbo-nerds who can't handle how kick-butt reality is. I'm a kick-butt reality master! I would rather die, than be imaginative. I mean that.) 14.55.42 # New commit by 03jdgordon (r30599): Check for the magic file "/.rockbox/skin_buffer_size.txt" on bootup which can have a number which is the amount of kilobytes to allocate for the skin ... 14.57.01 # New commit by 03jdgordon (r30600): fix warnings 14.57.45 # r30599 build result: 10 errors, 188 warnings (jdgordon committed) 14.58.46 Quit Jak_o_Shadows (Remote host closed the connection) 14.59.25 # r30600 build result: 10 errors, 0 warnings (jdgordon committed) 14.59.30 # grr android :/ 15.01.53 # New commit by 03jdgordon (r30601): fix APPLICATION build errors 15.03.36 # jd 15.03.53 # r30601 build result: All green 15.04.17 # JdGordon: ugh, I had that idea many month ago, you were against it 15.04.49 # why now, where the vast majority of the skin buffer is dynamic? 15.05.27 # I have no recollection of that, and 2 the vast majorifty is not dynamic at all 15.06.08 # huh? 15.06.36 # huh what? 15.07.10 # this is effectively a user setting for the buffer size, I thought that was a nodo 15.07.46 # backdrops & images are much bigger aren't they? 15.08.02 # you thought wrong.... 15.08.25 # we had configurable skin buffer topic many times, and you now sneak it in 15.08.28 # and i've spent all day looking into skin buffer usage, it cant get any smaller with massive rework to use buflib which isnt going to happen 15.08.43 # you have any numbers? 15.10.01 # as a matter of fact.. yes I do http://pastebin.com/0vP0zbDP <- ilike on the nano, cabbie shows a similar story 15.11.13 # http://pastebin.com/AMUB7Spi <- cabbie 15.12.09 # and what does that show? 15.12.26 Quit ReimuHakurei_ (Quit: And therefore, dye this sky red. The time has come again for my body to only go forward / Even the 'people' who pass by and the 'things' which become lost in confusion / Will one day be like vanished memories) 15.12.37 # and I'm not sure you want me to look at the first paste 15.13.00 # the first post is the raw data 15.13.08 # the second one is actually usefu;l 15.13.31 # but it doesn't include images does it? 15.13.35 # no 15.13.51 # so what should it tell me? 15.13.51 # what it shows is that there is no more easy fixes for the skin buffer size problem 15.14.49 # and I know for sure noone else is going to even attempt the hard solution, so this is the fix 15.15.08 # and for that you sneak in a patch for configurable buffer without any word about it? 15.15.32 # why do you always think there is *evil* in my commits? 15.15.39 # I disagree with that commit in several ways 15.17.36 # why don't you discuss it before 15.18.19 # we were always against user configurable skin buffer 15.18.42 # this is even worse because its implemented in an awkward manner 15.21.29 *** Saving seen data "./dancer.seen" 15.47.09 # r30599 seems strange to me, it's kind of setting but done in a unusual way 15.48.34 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) 15.54.06 # what are the steps to add a target to the simulator ? 16.07.29 Quit user829385 (Quit: Leaving.) 16.22.15 Quit lovasoa (Quit: lovasoa) 16.44.52 # * bertrik ordered a Sansa Clip Zip, to be used for rockbox development 16.47.39 # pamaury, add a .bmp in uisimulator/bitmaps/UI-.bmp and edit firmware/target/hosted/sdl/sim-ui-defines.h to define how the framebuffer overlays the player image 16.48.11 # I just did that for the clip zip :) 16.54.12 # I guess we can't use a promotional picture from the manufacturer for the BMP? 16.54.28 # weird, I'm getting an error because of swap16_hw being redefined :( 16.54.37 # bertrik: I guess not, I took a picture of my fuze+ 16.55.25 # and HIGHEST_IRQ_LEVEL beging redefined too, strange 16.55.28 # *being 16.55.31 # *been 16.55.50 # all seem related to adc-target 16.56.13 # sounds nasty 16.57.59 # just tried a e200 sim and it builds, so it might be related to my code but I don't see how 16.59.10 Join ender` [0] (~ender@foo.eternallybored.org) 16.59.40 # ok, I found why 17.12.05 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) 17.12.55 Nick kugelp is now known as kugel (~kugel@rockbox/developer/kugel) 17.16.44 # what argument have I missed where I've been mentioned? 17.18.49 # list item spacing 17.19.08 # (on touchscreen that is) 17.19.40 # oh right 17.19.54 # yes - bigger spacing makes the menu much more usable 17.20.17 # the default theme using the original spacing is a complete pain in the ass 17.21.15 # whose patch to introduce it did I use originally? 17.21.24 # mine 17.21.33 *** Saving seen data "./dancer.seen" 17.21.37 # I'm working on making it committable, but I'm faced some opposition 17.22.31 # oh? 17.22.36 # facing* 17.22.38 # who says it's a bad idea? 17.24.34 # well, nobody. but JdGordon says it can be done be done in themes with skinned lists, so any other way is wrong 17.25.02 # the patch I work on works on all screens (or tries to...) without special theme support 17.25.14 # that seems a better idea to me 17.25.41 # having to theme a list for screensize seems a rather obtuse way of doing it 17.25.58 # IMO it's not a theme issue at all 17.26.07 # no it isn't I don't think 17.27.05 # GodEater: did you test saint's cabbiev2 version with or without this patch applied? 17.27.41 # I've not tested his theme for ages 17.27.50 # not since the first time I tried it and didn't like the WPS changes 17.28.20 # at the moment I can't do much testing, as I have no build env. until kernel.org is fixed and I can rebuild by toolchain 17.28.30 # saint said you "reported no issue whatsoever" 17.28.32 # s/by/my/ 17.28.53 # kugel: well that's technically true - but only because I've barely used it ;) 17.28.55 # for android you don't need the toolchain do you? 17.29.10 # need an arm compiler don't I? 17.29.17 # that comes with the ndk 17.29.40 # ah cool 17.29.42 # will download then 17.30.20 # plus, you can set other mirrors for rockboxdev.sh (or download manually), but I don't know any mirror :) 17.30.28 # nor me 17.30.41 # and I've not really been incentivised to look 17.35.41 # New commit by 03pamaury (r30602): imx233/fuze+: add fuze+ to the simulator framework 17.37.24 Join Stummi [0] (~Stummi@rockbox/developer/Stummi) 17.37.42 # r30602 build result: All green 17.45.03 # JdGordon: gcc never reorders struct members (it would be dangerous unless it kknew where all the usres were and altered them too) and the packed attribute tells it to not use any padding between members so members are no longer aligned unless by coincidence so on targets that require alignment, such as arm i will generate byte-by-byte accesses which are slower and makes the code bigger 17.45.46 # s/ i / it / 17.49.49 Quit pamaury (Remote host closed the connection) 17.55.32 Quit hilbert (Quit: Textual IRC Client: http://www.textualapp.com/) 17.56.49 Quit Xerion (Ping timeout: 256 seconds) 18.00.18 Join Xerion [0] (~xerion@5419A766.cm-5-2c.dynamic.ziggo.nl) 18.01.49 Quit bluefoxx_ (Ping timeout: 255 seconds) 18.02.20 Join Keripo [0] (~Keripo@dhcp0751.kin.resnet.group.UPENN.EDU) 18.04.19 Quit Keripo (Client Quit) 18.04.33 Quit simonlnu (Quit: bbl) 18.07.59 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 18.12.25 Quit fyre^OS (Ping timeout: 276 seconds) 18.23.54 Join funman [0] (~fun@rockbox/developer/funman) 18.27.03 Join soap_ [0] (~soap@94.75.232.194) 18.27.03 Quit soap_ (Changing host) 18.27.03 Join soap_ [0] (~soap@rockbox/staff/soap) 18.44.52 Join benedikt93 [0] (~benedikt9@p5B0C6A2E.dip.t-dialin.net) 18.44.57 Quit benedikt93 (Changing host) 18.44.57 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 18.47.46 # Someone broke album art! 18.48.35 # you mean MrSomeone? :) 18.49.10 Quit ej0rge (Remote host closed the connection) 18.49.21 Join ej0rge [0] (~alhaz@207.135.137.71) 18.51.52 # screndumps seem to be really unstable on my gigabeat F with a build from yesterday 18.55.16 # funman, perhaps you can have an extra look at my code/binary just before the first attempt of flashing the clip zip 18.56.05 # bertrik: did it change since i looked? iirc it was super simple 18.57.08 # no, the first try is to just make it boot the OF, then to introduce a button-dependent delay, then to make it boot rockbox bootloader depending on the button state 18.59.00 Join simonlnu [0] (~simon@unaffiliated/simonrvn) 19.02.05 # It looks like connecting USB when screendumps are enabled (at least on gigabeat f) now starts making screendumps continuously 19.05.10 Quit mystica555 (Ping timeout: 245 seconds) 19.05.10 # And album art doesn't seem to be loaded if it's one directory up 19.05.38 # gevaerts: that is a symptom I noticed on e200v2 and reported in FS#11995 19.05.40 # http://www.rockbox.org/tracker/task/11995 3screendump problems caused by r29445 (bugs, new) 19.06.03 Join hilbert [0] (~hilbert@adsl-89-217-163-45.adslplus.ch) 19.07.22 # mc2739: so it might be a stack issue? 19.08.02 # gevaerts: that is what it looked like 19.13.01 Join Buschel [0] (~chatzilla@p54B67F1B.dip.t-dialin.net) 19.13.41 Join bluefoxx [0] (fuzzylomba@S0106e0cb4e0a6d8a.vs.shawcable.net) 19.14.11 # why do we use "int" for "line", "params_count" and "children_count" in the "skin_element" type? is this really required? we might save several KB when using unsigned char instead... 19.15.21 # Is unsigned char always large enough? 19.16.03 # in fact I do not know. but I am pretty convinced we fo not need int. 19.16.18 # short might be doable 19.16.57 # maybe some of our skin experts can evaluate this 19.21.34 *** Saving seen data "./dancer.seen" 19.28.05 # hm, might be possible 19.29.26 Join Horschti [0] (~Horscht@xbmc/user/horscht) 19.30.19 # param_count char and line, children_count short, plus reordering, could save 8 byte or so 19.30.42 # since enum skin_element_type is char also (on arm eabi at least) 19.32.13 # which would equal 8 KB of skin buffer size 19.32.51 # Well, yes and no 19.33.08 Quit Horscht (Ping timeout: 256 seconds) 19.33.43 # It would make the skin buffer 8KB smaller, but whether that translates to actually *needing* 8KB less depends on how the skin uses this space 19.34.22 # wasn't this what I said? making the skin buffer smaller? 19.35.32 # and if I understant this stuff right the skin buffer is always allocated. but maybe not fully used by the skin 19.35.52 # * gevaerts nods 19.38.27 # here's a new version of the list item patch, with now with setting and some bugs fixed: http://pastie.org/2590041 19.38.30 # GodEater: ^ 19.55.38 # Unhelpful: I understand you understand AA? 19.55.57 # Do you have any idea why parent directory AA doesn't work anymore for me? 19.56.00 # uhoh. what's the question? 19.56.23 # without looking at the code, no... gimme a bit. 20.02.36 # bertrik: you deciced to drop the serbuf_lock? 20.03.28 # yes, the approach I took was not water-proof I think 20.04.13 Quit Bagder (Ping timeout: 276 seconds) 20.04.38 Join dfkt|n [0] (dfktn@chello062178002170.1.11.univie.teleweb.at) 20.04.38 Quit dfkt|n (Changing host) 20.04.38 Join dfkt|n [0] (dfktn@unaffiliated/dfkt) 20.08.45 Join Bagder [0] (~daniel@1-1-5-26a.hud.sth.bostream.se) 20.08.45 Quit Bagder (Changing host) 20.08.45 Join Bagder [241] (~daniel@rockbox/developer/bagder) 20.10.22 Quit bluebrother (Disconnected by services) 20.10.23 Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) 20.13.14 Quit fs-bluebot (Ping timeout: 255 seconds) 20.14.26 Join fs-bluebot [0] (~fs-bluebo@g231123130.adsl.alicedsl.de) 20.18.54 # I think something of that kind is needed, to prevent buffer corruption 20.21.03 # yes I agree, but somehow IAP got stuck when looking at the IAP debug info 20.21.44 # I think IAP messages were probably being dropped somehow in the debug menus, causing the lock to never be released again 20.24.11 # yes, that happens. 20.24.32 # if you're in the debug menu receiving messages will f**k up the state machine 20.24.48 # or better, f**k up the locking, as the queue is never run 20.27.04 # But I think going to a local queue to handle messaging (which I've done in the meantime) fixes that 20.29.08 # at least I can have the logf dump open and put messages through IAP and watch them in real time 20.46.56 # kugel: doing a build with that patch now 20.48.59 Quit hilbert (Quit: Textual IRC Client: http://www.textualapp.com/) 20.49.13 Join hilbert [0] (~hilbert@adsl-89-217-163-45.adslplus.ch) 20.51.52 # kugel: looks great 20.54.33 # who can quickly explain to me the different items of the keymaps ? 20.54.55 # what does ACTION_STD_MENU and ACTION_STD_CONTEXT do ? 20.56.11 Join MethoS- [0] (~clemens@134.102.106.250) 20.59.33 Quit Lalufu (Read error: Connection reset by peer) 20.59.47 Join Lalufu [0] (~sun@ryoko.camperquake.de) 21.00.01 Quit Lalufu (Changing host) 21.00.01 Join Lalufu [0] (~sun@unaffiliated/lalufu) 21.02.42 Quit dfkt|n () 21.03.55 # hm, my clip doesn't boot with a current build 21.04.21 # how do I start playback with a playlist from the catalogue? 21.04.53 Join Chat7180 [0] (pyzuks@app3.chatmosphere.org) 21.05.45 # I would expect selecting an entry in the Catalogue and pressing 9 in the Sansa Fuzev2 Simulator would do, but it doesn't 21.06.11 Quit parafin (Ping timeout: 240 seconds) 21.06.38 Quit Chat7180 (Client Quit) 21.07.02 # also selecting an entry of the playlist and pressing >|| (9) doesn't work 21.07.40 Join parafin [0] (parafin@paraf.in) 21.11.48 # gevaerts: my e200v2 is having problems, too. It hangs with a white screen after the bootloader logo displays. It looks like r30589 is the problem build. 21.11.55 # GodEater: cool 21.13.24 # mc2739: yes, same here 21.14.34 Quit bluefoxx (Ping timeout: 256 seconds) 21.14.43 # amiconn looked at it a bit closer at this, but I don't know the final verdict 21.15.32 Join freddyb [0] (~freddybbb@216.8.239.112.etczone.com) 21.16.17 # r30589 causes 100% reproducable crash *on hwcodec* (after applying a fix for an earlier crash) 21.16.24 Join bluefoxx [0] (fuzzylomba@S0106e0cb4e0a6d8a.vs.shawcable.net) 21.17.21 # That said current seems to be somewhat unstable on swcodec as well. Today, my H180 hung at shutdown. CF targets used to hang occasionally some time ago, but I didn't observe that anymore for many months 21.17.34 # Yesterday I updated to latest svn, and today it hung... 21.19.33 # * bertrik is getting scared of updating 21.20.49 # i just updated my Clip+ and its working perfectly 21.21.05 # r30602 21.21.38 *** Saving seen data "./dancer.seen" 21.25.38 # If you just updated you cannot be sure whether it's 100% stable 21.26.00 # Ah, good news. A visible panic screen! 21.26.40 # I don't suppose anyone cares about my mailing list post? 21.27.13 # data abort in font_get 21.27.29 Quit Buschel (Ping timeout: 255 seconds) 21.27.57 # kugel, I mostly agree with you 21.28.55 # With an address that looks like ASCII 21.29.30 # ha fuzeV1 locked on rolo after updating 21.30.05 # yeah 3 locks in a row booting 21.30.22 # so amsv2 worked for me, but v1 did not 21.36.44 # bertrik: an answer on the ml would be appreciated 21.40.31 # huh, a segfault 21.41.30 Quit TheLemonMan (Quit: WeeChat 0.3.5) 21.41.44 Join TheLemonMan [0] (~LemonBoy@ppp-158-36.26-151.libero.it) 21.51.32 Quit Stummi (Quit: Bye!) 21.53.22 # did anyone notice 30600 built in 94s? 21.53.41 # that's new record isnt it? 21.54.03 # ah build error, so it probably doesnt count 21.54.04 # It might be. We've had some fast builds when Zagor was testing 21.54.21 # but r30587 was 100s 21.54.44 # is there any theory why the fonts on buflib broke some random AMS devices? 21.55.15 # bad luck 21.55.26 # saratoga: for me it seems to crash in get_font() in the "pf = &alloc->font" line 21.55.39 # I don't believe it's specific to samsa in any way 21.55.49 # The second one, that is 21.56.05 Quit benedikt93 (Quit: Bye ;)) 21.56.58 # probably data is being overwritten 21.57.17 # amiconn reported another crash in font_unload() 21.57.56 # I get a data abort with 0x65696266 as the illegal address, which looks suspiciously ASCII, so yes, overwritten data seems likely 21.58.36 # &alloc->font shouldn't crash as it should evaluate to (type*)alloc (font is the first member) 21.59.01 # missed optimization then 21.59.20 # Maybe. Or maybe I'm wrong in locating the crash of course 21.59.24 # gevaerts: did you check what string that is? 21.59.39 # What I do is compile with -g and then arm-elf-eabi-objdump --disassemble -S rockbox.elf 21.59.46 # "fbie" 22.01.00 Quit mystica555_ (Remote host closed the connection) 22.02.01 # gevaerts: you don't need -g for that I think 22.02.36 # * kugel might be wrong 22.02.50 # Ah, I see what I did wrong. It's the line after that, i.e. "if (pf && pf->height)" 22.06.32 Quit evilnick (Ping timeout: 260 seconds) 22.15.22 # fwiw, lru isn't updated in the move callback 22.16.33 # I'm not sure it matters for this crash 22.18.46 Quit y4n (Quit: 6,000,000 ways to die — choose one.) 22.18.47 # New commit by 03kugel (r30603): Fonts/buflib: The lru cache base poitner needs to be updated as well in the move callback. 22.19.29 # * kugel slaps forehead 22.19.36 # r30603 build result: 376 errors, 0 warnings (kugel committed) 22.19.55 # New commit by 03kugel (r30604): Fix typos. Should have test compiled at least once :\ 22.22.01 # r30604 build result: All green 22.24.37 # I don't suppose that fixed it for anyone? 22.25.51 # it didn't, no 22.26.34 # Well, it still crashes at least. No guarantees that it's the same crash, I haven't managed to get the visible panic again yet 22.26.54 # Are you guys crashing on the sim, too? 22.28.55 Join mystica555 [0] (~Mike@71-211-199-174.hlrn.qwest.net) 22.29.57 # didn't make a difference on my fuze, haven't tried the sim 22.32.34 # the sim does not crash for me 22.33.02 Join petur [0] (~petur@rockbox/developer/petur) 22.34.13 Quit funman (Quit: leaving) 22.45.24 # should the "while(1)" in font.c:font_get() be "while ( buflib_allocations[font] != -1 )" ? 22.48.40 # scratch that 22.54.17 Quit TheLemonMan (Quit: WeeChat 0.3.5) 23.06.56 Quit ej0rge (Ping timeout: 255 seconds) 23.07.10 Join ej0rge [0] (~alhaz@207.135.137.71) 23.11.35 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 23.12.20 Quit mamarley (Remote host closed the connection) 23.21.41 *** Saving seen data "./dancer.seen" 23.31.27 Quit liar (Quit: hallowed are the ori!) 23.32.14 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 23.34.36 Quit liar (Client Quit) 23.39.59 Join Strife89 [0] (~Strife89@207.144.201.128) 23.44.08 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 23.51.15 Join funman [0] (~fun@rockbox/developer/funman) 23.51.49 # kugel: Will you commit the crash fix for r30383? 23.54.34 Quit ender` (Quit: When one person suffers from a delusion it is called insanity. When many people suffer from a delusion it is called religion. -- Robert Pirsig)