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 | amiconn | 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 | natedev | 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 | kugel | amiconn: no |
00:50:21 | kugel | talk is very badly integrated in general |
00:55:43 | | Quit petur (Quit: Leaving) |
01:00 |
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 | amiconn | 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 | amiconn | Probably r30381 - will test |
01:26:44 | amiconn | Err, 30381 and 30382 don't build |
01:27:42 | amiconn | Okay, and 30379 hangs |
01:28:26 | amiconn | So r30380 fixes the hang (which hence doesn't need to be tracked down), and r30381 (+2+3) introduces the crash |
01:29:35 | amiconn | 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 | FlynDice | 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 | kugel | amiconn: when does it crash exactly? |
01:37:01 | amiconn | At boot, while the boot screen is displayed |
01:38:07 | kugel | so at init? |
01:38:35 | amiconn | Yes, precisely in tagtree_init() - but only if coice is enabled & matching voice file present |
01:38:45 | amiconn | s/coice/voice/ |
01:39:33 | kugel | oh I thought that was the hang, sorry |
01:39:42 | * | kugel confused the problems for a moment |
01:40:03 | kugel | right, get_tag() crashes because of bad pointer |
01:40:22 | amiconn | 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 | kugel | I suspect the memory gets overwritten |
01:40:35 | kugel | perhaps by talk buffer or so |
01:41:19 | amiconn | 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 | amiconn | 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 | kugel | talk.c should receive its buffer from mpeg.c |
01:43:01 | amiconn | memory guard *can* catch accesses to the rom area |
01:45:44 | amiconn | Hmm, unfortunately it won't tell us much because there is no backtrace |
01:45:58 | amiconn | It will probably crash in something like strcpy() |
01:46:13 | amiconn | 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 | kugel | amiconn: bt full shows a bit more (bad pointer for dest for strcpy) |
01:52:13 | amiconn | I already reported that earlier here too (by setting a breakpoint and printing the variable) |
01:53:46 | amiconn | 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 | amiconn | So something is going wrong within buflib, and it has been introduced when enabling compaction |
01:58:38 | kugel | printing the result of core_get_data() shows that it's chaning between invocations |
01:59:59 | kugel | hm, inspecting core_ctx (what core_* wraps around) gives strange results |
02:00 |
02:01:43 | kugel | err |
02:01:58 | kugel | the very first tagtree_alloc() call allocs 9MB |
02:02:47 | kugel | ah nvm |
02:02:49 | amiconn | How can it allocate more memory than there is? |
02:04:09 | kugel | voicebuf and p_thumbnail are still NULL, so I don't know |
02:06:04 | kugel | hmmm |
02:06:38 | | Nick scorche` is now known as scorche (~scorche@rockbox/administrator/scorche) |
02:07:02 | kugel | amiconn: the first tagtree_alloc0 call destroys buflibs handle table :\ |
02:08:17 | amiconn | 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 | kugel | core_alloc_maximum() returns 0 for tagtree_bufsize but still a valid handle??? |
02:09:10 | amiconn | 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 | amiconn | (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 | kugel | 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 | kugel | which calls core_alloc_maximum() |
02:15:27 | kugel | that's so early that further calls to that fail, like the one in tagtree |
02:21:32 | amiconn | 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 | kugel | audio_get_buffer() behave differently between sw and hwcodec |
02:26:33 | kugel | 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 | kugel | I can't remember if there was some reason to make audio_get_buffer behave that way on hwcodec |
02:31:06 | amiconn | Hmm, this fixes the crash in tagtree_init(), but not the second crash :/ |
02:31:23 | amiconn | Unfortunately I haven't been able to reproduce the second on in the sim |
02:31:39 | kugel | :( |
02:32:39 | kugel | where is that one? |
02:32:50 | amiconn | In font_unload() near the beginning |
02:34:08 | kugel | perhaps introduced with JdGordon's commit? |
02:36:01 | * | amiconn tries r30588 with kugel's fix |
02:36:14 | JdGordon | 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 | amiconn | Bleh, r30588 + fix hangs :( |
02:39:30 | kugel | just tried r30584 and it doesn't hang in the sim |
02:40:20 | amiconn | Yeah, sim didn't hang with r30312..r30379 which hung on target too |
02:40:31 | JdGordon | Lalufu: BUTTON_RC_PLAY is proobably mapped to ACTION_STD_OK in the keymap file |
02:42:47 | amiconn | I will try to track down where it hangs exactly, unless someone beats me to it |
02:43:13 | kugel | I need to go to bed |
02:43:42 | amiconn | 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:00 |
03:06:18 | | Join Topy [0] (~Topy44@f048133111.adsl.alicedsl.de) |
03:10:06 | | Quit T44 (Ping timeout: 248 seconds) |
03:10:21 | JdGordon | [saint] you kill me sometimes! :/ |
03:10:32 | JdGordon | touch tags arent rejected on non touch targets |
03:10:36 | JdGordon | they are *ignored* |
03:11:08 | JdGordon | recording tags are rejected, but if you use the recroding *feature* tag they wont get parsed so it will work |
03:13:46 | JdGordon | 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:00 |
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 | soap | how much pain will I feel migrating from Ubuntu 32 to Ubuntu 64? |
04:59:56 | soap | i want to give my VM more RAM. |
05:00 |
05:12:01 | Jak_o_Shadows1 | 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:00 |
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:00 |
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:00 |
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:00 |
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 | CIA-14 | New commit by jdgordon (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 | CIA-14 | 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:00 |
10:12:51 | ukleinek | moin, do you have a recommendation for tools/workflows to rip cds? |
10:13:18 | JdGordon | #rockbox-community for that ukleinek |
10:13:50 | ukleinek | 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 | JdGordon | the ilike theme allocates 40KB in strings, mostly 2 and 3 chars long! |
10:18:17 | JdGordon | 645 of them! |
10:18:27 | n1s | wow |
10:19:04 | JdGordon | it was also doing 20+KB in empty elements because of the comment lines which the above commit fixes |
10:36:38 | bertrik | 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:00 |
11:11:46 | jacekowski | 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 | ukleinek | hmm, I'm currently looking at the sansa Fuzev2 simulator and wonder about the .mpu view |
11:47:16 | ukleinek | my filenames are utf-8 encoded and they show up nicely in the directory view |
11:47:57 | ukleinek | but when looking at an .m3u (not t .mpu) the umlauts look strage |
11:48:01 | ukleinek | *strange |
11:48:26 | ukleinek | (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:00 |
12:13:22 | ukleinek | 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 | kugel | 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 | rasher | [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 | veve | hi |
12:37:44 | [Saint] | *figured, too. |
12:38:51 | veve | 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 | veve | this was an issue some time ago and it was reported and confirmed (let me search for that link) |
12:40:48 | veve | 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 | fs-bluebot | http://www.rockbox.org/tracker/task/11765 Improve Battery Life on AMSv1 Sansa players (patches, new) |
12:40:56 | veve | http://www.rockbox.org/wiki/SansaAMS#AMSv1_issues_40m200v4_44_c200v2_44_e200v2_44_Fuzev1_44_Clipv1_41 |
12:41:46 | veve | 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 | veve | boy* |
12:42:37 | veve | bot** |
12:42:40 | veve | :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 | veve | 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 | veve | for mp3 |
12:45:12 | veve | and with the original firmware is 15 |
12:45:14 | veve | BUT |
12:45:35 | veve | 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 | veve | oh, yeah, it's not :). it is 1.6x faster, for the code available in 2010 |
12:47:00 | veve | 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 | veve | 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 | veve | ;)) true true |
12:48:35 | bertrik | 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 | veve | [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 | bertrik | 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 | bertrik | 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 | veve | 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 | veve | I will post the results :) |
12:52:50 | veve | for now, thank you |
12:53:26 | fml | JdGordon: Hello. Have you seen the discussion yesterday re %Vf(xxx) not working (%Vs(color,xxx) still working)? |
12:53:59 | fml | 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 | rasher | fml: hover over the date |
12:56:02 | fml | 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 | rasher | 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:00 |
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 | rasher | 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 | rasher | Now it has both |
13:09:01 | Lalufu | 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 | pamaury | 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 | bertrik | This is approximately how the rockbox main menu will look on the Sansa Clip Zip: http://imagebin.org/173953 |
13:29:27 | bertrik | 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 | bertrik | 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 | JdGordon | 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 | JdGordon | [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 | JdGordon | yes, well they sort of do (did) |
13:50:21 | JdGordon | kugel: function points to do what? |
13:50:40 | kugel | 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 | JdGordon | kugel: err why? |
13:51:14 | JdGordon | [Saint]: its fixed now :) |
13:51:22 | [Saint] | JdGordon: Ah, awesome. |
13:51:27 | [Saint] | I missed that. |
13:51:53 | JdGordon | 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 | JdGordon | i.e all the image labels |
13:52:12 | [Saint] | "meh". |
13:52:16 | JdGordon | 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 | JdGordon | oh I know |
13:52:52 | JdGordon | just saying :) |
13:53:05 | | Quit Jak_o_Shadows1 (Ping timeout: 245 seconds) |
13:53:14 | JdGordon | 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 | JdGordon | I've got a list of 18 functions doing allocations in the order of count and accumulated cost of each |
13:54:05 | JdGordon | the second worst offender is %V |
13:54:13 | JdGordon | 3.6K |
13:54:32 | JdGordon | 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 | kugel | 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 | JdGordon | where outside of lists would the line height matter? |
13:55:36 | [Saint] | not forced for all lists. |
13:56:19 | kugel | I would hate if one list is different than the previous one |
13:56:47 | kugel | JdGordon: at no place, but lcd.c needs the line height but can't just access global_settings |
13:56:59 | kugel | 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 | kugel | 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 | JdGordon | yeah, no, i dont like it, skinned lists are the way to do that |
13:57:41 | * | [Saint] nods. |
13:57:47 | kugel | (a getter is needed in the first place to not cache font height/absolute height in case either changes) |
13:58:15 | n1s | kugel: can't you add a setter to lcd.c that is called when it changes? |
13:58:17 | kugel | why skinned lists? |
13:58:30 | kugel | not everyone is using them |
13:59:00 | kugel | list height is not about eye candy, it's about usability |
13:59:04 | kugel | line height* |
13:59:13 | JdGordon | *COUGH* I see no reason why it is needed outside of lists, therefore its wrong |
13:59:28 | kugel | 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 |
14:00:12 | | Quit lovasoa (Ping timeout: 240 seconds) |
14:00:14 | kugel | I want rockbox to be usable without special theme support |
14:00:30 | kugel | [Saint]: I'm doing the setting, as I just wrote |
14:00:30 | JdGordon | 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 | kugel | 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 | kugel | 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 | n1s | 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 | kugel | [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 | CIA-14 | New commit by jdgordon (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 | kugel | that doesn't mean anything |
14:05:29 | kugel | and I had complained if my list spacing patch wasn't already applied |
14:05:39 | JdGordon | a setting is the wrong place for this |
14:06:05 | kugel | well, *I* don't need a setting anyone |
14:06:15 | kugel | anyway |
14:06:21 | JdGordon | 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 | kugel | 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 | CIA-14 | 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 | kugel | 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 | JdGordon | [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 | kugel | well, we didn't even decide if we even want it, or in which form |
14:11:27 | JdGordon | 1KB in strings |
14:11:35 | kugel | 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 | kugel | 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 | kugel | I'm doing the setting didn't you hear? |
14:13:40 | [Saint] | which will turn it off *everywhere*. |
14:13:40 | kugel | 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 | kugel | so, what you actually want is faster scrolling, not smaller linesß |
14:14:48 | kugel | ? |
14:14:52 | [Saint] | slower. |
14:15:16 | kugel | slower? |
14:15:30 | kugel | with smaller lines it gets faster |
14:16:36 | kugel | does anyone else here think that lists looking differently (instead of uniform throughout rockbox) is a good ui design decision? |
14:17:05 | kugel | not only _looking_, the line height has a clear impact on the usability |
14:17:26 | kugel | I don't want this for the default theme |
14:17:38 | JdGordon | you're the only one bringing this up, and there is already a very workable solution |
14:18:07 | kugel | JdGordon: where? |
14:18:18 | kugel | a custom theme? |
14:18:38 | [Saint] | ...why not? |
14:18:41 | kugel | 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 | kugel | what. I should shut up because I'm the only one currently? |
14:19:34 | CIA-14 | New commit by bertrik (r30598): IAP: use a state machine for handling iap packets, based on FS #12135 |
14:19:56 | Lalufu | anyone around here using current release rockbox versions with an iPod, and using attached devices of any kind? |
14:20:24 | Lalufu | (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 | JdGordon | kugel: no you shdont' need to shutup, but you're in the minority, and yes this is entirely a theme issue |
14:20:48 | kugel | it isn't |
14:20:57 | JdGordon | you already said you cant tihnk of anywhere outside of a themeable screen this would be needed |
14:21:08 | kugel | 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 | CIA-14 | r30598 build result: All green |
14:22:22 | kugel | fwiw, I have support for the patch in its old form |
14:22:26 | JdGordon | does the packed sturct attribute make gcc reorder the items so individual items are type-aligned like they should be? |
14:22:37 | kugel | 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 | JdGordon | it isnt commitable |
14:23:42 | JdGordon | even with a settin g it isnt |
14:23:43 | kugel | AlexP and GodEater said it makes rockbox usable |
14:23:49 | kugel | (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 | bertrik | 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 | kugel | [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 | kugel | 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 | kugel | well, the test builds you provided also have a bunch of patches applied no? |
14:27:39 | JdGordon | 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 | bertrik | 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 | JdGordon | it would break horribly |
14:30:28 | [Saint] | fail silently? |
14:30:35 | JdGordon | it will also break every wps virewport |
14:30:39 | kugel | skinned list would probably override it |
14:30:41 | JdGordon | i.e its a really bad idea |
14:30:53 | kugel | why break horribly? |
14:32:05 | kugel | 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 | kugelp | 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 | JdGordon | 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 | JdGordon | if you're doing custom builds anyway why cant my buflib malloc patch go in? |
14:36:11 | rasher | Are you talking about list padding? |
14:36:21 | [Saint] | rasher: It seems that way. |
14:36:25 | kugelp | I don't do any builds |
14:36:52 | [Saint] | I believe he was referring to an ealier statement of yours. |
14:37:07 | rasher | 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 | rasher | [Saint]: huh? |
14:38:15 | JdGordon | 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 | rasher | [Saint]: What do you disagree with? |
14:39:05 | [Saint] | Ah...I missinterpreted that, nevermind. ...<skulks away>. |
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 | kugelp | JdGordon: buffer_alloc() is dead |
14:41:42 | [Saint] | (where "in harmony" == "skinned lists negate list padding if present) |
14:42:27 | rasher | [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 | JdGordon | kugelp: how do i stallocate a buffer which wont move? |
14:43:09 | JdGordon | or im forced to use buflib and make sure to be the first to do so |
14:43:09 | kugelp | you don't |
14:43:10 | rasher | [Saint]: you can do that with any number - just interpret it as padding on each side |
14:43:46 | kugelp | 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 | rasher | [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 | rasher | it just a number |
14:48:15 | rasher | 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 | kugelp | 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 | CIA-14 | New commit by jdgordon (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 | CIA-14 | New commit by jdgordon (r30600): fix warnings |
14:57:45 | CIA-14 | r30599 build result: 10 errors, 188 warnings (jdgordon committed) |
14:58:46 | | Quit Jak_o_Shadows (Remote host closed the connection) |
14:59:25 | CIA-14 | r30600 build result: 10 errors, 0 warnings (jdgordon committed) |
14:59:30 | JdGordon | grr android :/ |
15:00 |
15:01:53 | CIA-14 | New commit by jdgordon (r30601): fix APPLICATION build errors |
15:03:36 | kugelp | jd |
15:03:53 | CIA-14 | r30601 build result: All green |
15:04:17 | kugelp | JdGordon: ugh, I had that idea many month ago, you were against it |
15:04:49 | kugelp | why now, where the vast majority of the skin buffer is dynamic? |
15:05:27 | JdGordon | I have no recollection of that, and 2 the vast majorifty is not dynamic at all |
15:06:08 | kugelp | huh? |
15:06:36 | JdGordon | huh what? |
15:07:10 | kugelp | this is effectively a user setting for the buffer size, I thought that was a nodo |
15:07:46 | kugelp | backdrops & images are much bigger aren't they? |
15:08:02 | JdGordon | you thought wrong.... |
15:08:25 | kugelp | we had configurable skin buffer topic many times, and you now sneak it in |
15:08:28 | JdGordon | 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 | kugelp | you have any numbers? |
15:10:01 | JdGordon | as a matter of fact.. yes I do http://pastebin.com/0vP0zbDP <- ilike on the nano, cabbie shows a similar story |
15:11:13 | JdGordon | http://pastebin.com/AMUB7Spi <- cabbie |
15:12:09 | kugelp | 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 | kugelp | and I'm not sure you want me to look at the first paste |
15:13:00 | JdGordon | the first post is the raw data |
15:13:08 | JdGordon | the second one is actually usefu;l |
15:13:31 | kugelp | but it doesn't include images does it? |
15:13:35 | JdGordon | no |
15:13:51 | kugelp | so what should it tell me? |
15:13:51 | JdGordon | what it shows is that there is no more easy fixes for the skin buffer size problem |
15:14:49 | JdGordon | and I know for sure noone else is going to even attempt the hard solution, so this is the fix |
15:15:08 | kugelp | and for that you sneak in a patch for configurable buffer without any word about it? |
15:15:32 | JdGordon | why do you always think there is *evil* in my commits? |
15:15:39 | kugelp | I disagree with that commit in several ways |
15:17:36 | kugelp | why don't you discuss it before |
15:18:19 | kugelp | we were always against user configurable skin buffer |
15:18:42 | kugelp | this is even worse because its implemented in an awkward manner |
15:21:29 | *** | Saving seen data "./dancer.seen" |
15:47:09 | pamaury | 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 | pamaury | what are the steps to add a target to the simulator ? |
16:00 |
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 | bertrik | pamaury, add a .bmp in uisimulator/bitmaps/UI-<targetname>.bmp and edit firmware/target/hosted/sdl/sim-ui-defines.h to define how the framebuffer overlays the player image |
16:48:11 | bertrik | I just did that for the clip zip :) |
16:54:12 | bertrik | I guess we can't use a promotional picture from the manufacturer for the BMP? |
16:54:28 | pamaury | weird, I'm getting an error because of swap16_hw being redefined :( |
16:54:37 | pamaury | bertrik: I guess not, I took a picture of my fuze+ |
16:55:25 | pamaury | and HIGHEST_IRQ_LEVEL beging redefined too, strange |
16:55:28 | pamaury | *being |
16:55:31 | pamaury | *been |
16:55:50 | pamaury | all seem related to adc-target |
16:56:13 | bertrik | sounds nasty |
16:57:59 | pamaury | 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 | pamaury | ok, I found why |
17:00 |
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 | GodEater | what argument have I missed where I've been mentioned? |
17:18:49 | kugel | list item spacing |
17:19:08 | kugel | (on touchscreen that is) |
17:19:40 | GodEater | oh right |
17:19:54 | GodEater | yes - bigger spacing makes the menu much more usable |
17:20:17 | GodEater | the default theme using the original spacing is a complete pain in the ass |
17:21:15 | GodEater | whose patch to introduce it did I use originally? |
17:21:24 | kugel | mine |
17:21:33 | *** | Saving seen data "./dancer.seen" |
17:21:37 | kugel | I'm working on making it committable, but I'm faced some opposition |
17:22:31 | GodEater | oh? |
17:22:36 | kugel | facing* |
17:22:38 | GodEater | who says it's a bad idea? |
17:24:34 | kugel | 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 | kugel | the patch I work on works on all screens (or tries to...) without special theme support |
17:25:14 | GodEater | that seems a better idea to me |
17:25:41 | GodEater | having to theme a list for screensize seems a rather obtuse way of doing it |
17:25:58 | kugel | IMO it's not a theme issue at all |
17:26:07 | GodEater | no it isn't I don't think |
17:27:05 | kugel | GodEater: did you test saint's cabbiev2 version with or without this patch applied? |
17:27:41 | GodEater | I've not tested his theme for ages |
17:27:50 | GodEater | not since the first time I tried it and didn't like the WPS changes |
17:28:20 | GodEater | 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 | kugel | saint said you "reported no issue whatsoever" |
17:28:32 | GodEater | s/by/my/ |
17:28:53 | GodEater | kugel: well that's technically true - but only because I've barely used it ;) |
17:28:55 | kugel | for android you don't need the toolchain do you? |
17:29:10 | GodEater | need an arm compiler don't I? |
17:29:17 | kugel | that comes with the ndk |
17:29:40 | GodEater | ah cool |
17:29:42 | GodEater | will download then |
17:30:20 | kugel | plus, you can set other mirrors for rockboxdev.sh (or download manually), but I don't know any mirror :) |
17:30:28 | GodEater | nor me |
17:30:41 | GodEater | and I've not really been incentivised to look |
17:35:41 | CIA-14 | New commit by pamaury (r30602): imx233/fuze+: add fuze+ to the simulator framework |
17:37:24 | | Join Stummi [0] (~Stummi@rockbox/developer/Stummi) |
17:37:42 | CIA-14 | r30602 build result: All green |
17:45:03 | n1s | 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 | n1s | 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: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 | gevaerts | Someone broke album art! |
18:48:35 | funman | 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 | gevaerts | screndumps seem to be really unstable on my gigabeat F with a build from yesterday |
18:55:16 | bertrik | 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 | funman | bertrik: did it change since i looked? iirc it was super simple |
18:57:08 | bertrik | 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:00 |
19:02:05 | gevaerts | 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 | gevaerts | And album art doesn't seem to be loaded if it's one directory up |
19:05:38 | mc2739 | gevaerts: that is a symptom I noticed on e200v2 and reported in FS #11995 |
19:05:40 | fs-bluebot | http://www.rockbox.org/tracker/task/11995 screendump problems caused by r29445 (bugs, new) |
19:06:03 | | Join hilbert [0] (~hilbert@adsl-89-217-163-45.adslplus.ch) |
19:07:22 | gevaerts | mc2739: so it might be a stack issue? |
19:08:02 | mc2739 | 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 | Buschel | 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 | gevaerts | Is unsigned char always large enough? |
19:16:03 | Buschel | in fact I do not know. but I am pretty convinced we fo not need int. |
19:16:18 | gevaerts | short might be doable |
19:16:57 | Buschel | maybe some of our skin experts can evaluate this |
19:21:34 | *** | Saving seen data "./dancer.seen" |
19:28:05 | kugel | hm, might be possible |
19:29:26 | | Join Horschti [0] (~Horscht@xbmc/user/horscht) |
19:30:19 | kugel | param_count char and line, children_count short, plus reordering, could save 8 byte or so |
19:30:42 | kugel | since enum skin_element_type is char also (on arm eabi at least) |
19:32:13 | Buschel | which would equal 8 KB of skin buffer size |
19:32:51 | gevaerts | Well, yes and no |
19:33:08 | | Quit Horscht (Ping timeout: 256 seconds) |
19:33:43 | gevaerts | 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 | Buschel | wasn't this what I said? making the skin buffer smaller? |
19:35:32 | Buschel | 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 | kugel | 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 | kugel | GodEater: ^ |
19:55:38 | gevaerts | Unhelpful: I understand you understand AA? |
19:55:57 | gevaerts | Do you have any idea why parent directory AA doesn't work anymore for me? |
19:56:00 | Unhelpful | uhoh. what's the question? |
19:56:23 | Unhelpful | without looking at the code, no... gimme a bit. |
20:00 |
20:02:36 | Lalufu | bertrik: you deciced to drop the serbuf_lock? |
20:03:28 | bertrik | 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 | Lalufu | I think something of that kind is needed, to prevent buffer corruption |
20:21:03 | bertrik | yes I agree, but somehow IAP got stuck when looking at the IAP debug info |
20:21:44 | bertrik | I think IAP messages were probably being dropped somehow in the debug menus, causing the lock to never be released again |
20:24:11 | Lalufu | yes, that happens. |
20:24:32 | Lalufu | if you're in the debug menu receiving messages will f**k up the state machine |
20:24:48 | Lalufu | or better, f**k up the locking, as the queue is never run |
20:27:04 | Lalufu | But I think going to a local queue to handle messaging (which I've done in the meantime) fixes that |
20:29:08 | Lalufu | at least I can have the logf dump open and put messages through IAP and watch them in real time |
20:46:56 | GodEater | 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 | GodEater | kugel: looks great |
20:54:33 | pamaury | who can quickly explain to me the different items of the keymaps ? |
20:54:55 | pamaury | 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 |
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 | gevaerts | hm, my clip doesn't boot with a current build |
21:04:21 | ukleinek | how do I start playback with a playlist from the catalogue? |
21:04:53 | | Join Chat7180 [0] (pyzuks@app3.chatmosphere.org) |
21:05:45 | ukleinek | 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 | ukleinek | 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 | mc2739 | 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 | kugel | GodEater: cool |
21:13:24 | gevaerts | mc2739: yes, same here |
21:14:34 | | Quit bluefoxx (Ping timeout: 256 seconds) |
21:14:43 | bertrik | 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 | amiconn | 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 | amiconn | 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 | amiconn | Yesterday I updated to latest svn, and today it hung... |
21:19:33 | * | bertrik is getting scared of updating |
21:20:49 | saratoga | i just updated my Clip+ and its working perfectly |
21:21:05 | saratoga | r30602 |
21:21:38 | *** | Saving seen data "./dancer.seen" |
21:25:38 | amiconn | If you just updated you cannot be sure whether it's 100% stable |
21:26:00 | gevaerts | Ah, good news. A visible panic screen! |
21:26:40 | kugel | I don't suppose anyone cares about my mailing list post? |
21:27:13 | gevaerts | data abort in font_get |
21:27:29 | | Quit Buschel (Ping timeout: 255 seconds) |
21:27:57 | bertrik | kugel, I mostly agree with you |
21:28:55 | gevaerts | With an address that looks like ASCII |
21:29:30 | saratoga | ha fuzeV1 locked on rolo after updating |
21:30:05 | saratoga | yeah 3 locks in a row booting |
21:30:22 | saratoga | so amsv2 worked for me, but v1 did not |
21:36:44 | kugel | bertrik: an answer on the ml would be appreciated |
21:40:31 | ukleinek | 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 | kugel | did anyone notice 30600 built in 94s? |
21:53:41 | kugel | that's new record isnt it? |
21:54:03 | kugel | ah build error, so it probably doesnt count |
21:54:04 | gevaerts | It might be. We've had some fast builds when Zagor was testing |
21:54:21 | kugel | but r30587 was 100s |
21:54:44 | saratoga | is there any theory why the fonts on buflib broke some random AMS devices? |
21:55:15 | kugel | bad luck |
21:55:26 | gevaerts | saratoga: for me it seems to crash in get_font() in the "pf = &alloc->font" line |
21:55:39 | kugel | I don't believe it's specific to samsa in any way |
21:55:49 | gevaerts | The second one, that is |
21:56:05 | | Quit benedikt93 (Quit: Bye ;)) |
21:56:58 | kugel | probably data is being overwritten |
21:57:17 | kugel | amiconn reported another crash in font_unload() |
21:57:56 | gevaerts | I get a data abort with 0x65696266 as the illegal address, which looks suspiciously ASCII, so yes, overwritten data seems likely |
21:58:36 | kugel | &alloc->font shouldn't crash as it should evaluate to (type*)alloc (font is the first member) |
21:59:01 | kugel | missed optimization then |
21:59:20 | gevaerts | Maybe. Or maybe I'm wrong in locating the crash of course |
21:59:24 | kugel | gevaerts: did you check what string that is? |
21:59:39 | gevaerts | What I do is compile with -g and then arm-elf-eabi-objdump −−disassemble -S rockbox.elf |
21:59:46 | kugel | "fbie" |
22:00 |
22:01:00 | | Quit mystica555_ (Remote host closed the connection) |
22:02:01 | kugel | gevaerts: you don't need -g for that I think |
22:02:36 | * | kugel might be wrong |
22:02:50 | gevaerts | 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 | kugel | fwiw, lru isn't updated in the move callback |
22:16:33 | kugel | 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 | CIA-14 | New commit by kugel (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 | CIA-14 | r30603 build result: 376 errors, 0 warnings (kugel committed) |
22:19:55 | CIA-14 | New commit by kugel (r30604): Fix typos. Should have test compiled at least once :\ |
22:22:01 | CIA-14 | r30604 build result: All green |
22:24:37 | kugel | I don't suppose that fixed it for anyone? |
22:25:51 | gevaerts | it didn't, no |
22:26:34 | gevaerts | 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 | freddyb | 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 | saratoga | didn't make a difference on my fuze, haven't tried the sim |
22:32:34 | mc2739 | 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 | freddyb | should the "while(1)" in font.c:font_get() be "while ( buflib_allocations[font] != -1 )" ? |
22:48:40 | freddyb | scratch that |
22:54:17 | | Quit TheLemonMan (Quit: WeeChat 0.3.5) |
23:00 |
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 | amiconn | 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) |