00:00:06 | [Saint] | I seem to recall that if it needs to the 9patch code will overlap slightly if its not a multiple of 3. |
00:00:07 | | Quit Rower (Quit: Hmmm...) |
00:00:53 | chrisjj | toehser1: Is there any difference of WPS theme from default, except font? |
00:00:57 | kugel | [Saint]: I'm not talking about skins |
00:01:33 | | Quit petur (Quit: Leaving) |
00:01:33 | [Saint] | I know, but as far as I'm aware the rules for draw order still apply. |
00:01:48 | [Saint] | "first called, first down, last called, last down" |
00:01:53 | toehser1 | Not that I can see - it seems to be stable with the sysfont, until I (a) power off, (b) change theme, (c) change font, (probably other things) |
00:02:05 | kugel | there is only one call involved |
00:02:12 | kugel | the one to lcd_nine_segment_bmp |
00:02:23 | kugel | not sure we're on the same page |
00:02:27 | chrisjj | "not that I can see. " You could diff the config file. |
00:02:58 | chrisjj | It would be handy to know if b) was necessary. |
00:03:35 | | Join Rower [0] (husvagn@90-230-142-55-no41.tbcn.telia.com) |
00:04:15 | [Saint] | Maybe it has changed somewhat since I looked at it but I was under the impression the 9patch stuff resized to as close as it could to a multiple of 3 and then drew the segments top-to-bottom left-to-right. |
00:04:22 | toehser1 | Oh - I thought you meant behavior - yes, the WPS and CFG have lots of differences from default... |
00:04:40 | [Saint] | SO any image overlapping should happen in that order. Even though the image is "flattended" by the time it is actually displayed. |
00:04:52 | chrisjj | Sorry to be unclear! Ah, then some pruning may be in order. |
00:05:00 | kugel | did you look at the code of the function? it's pretty straight forward |
00:05:19 | | Quit Rower (Client Quit) |
00:05:33 | toehser1 | This is with a theme I created, which works flawlessly for most files - only fails for certain playlists. |
00:05:33 | kugel | my issue isn't about overlapping at all |
00:06:02 | kugel | the resulting image is larger than the specified width/height |
00:06:06 | toehser1 | But I can certainly apply binary simplification to the theme & WPS to see if I can isolate 1 aspect - for example, I can try with a non AA font. |
00:06:09 | [Saint] | I thought you were asking "what happens when the segments need to overlap" |
00:06:11 | [Saint] | Sorry. |
00:06:40 | | Quit bertrik (Remote host closed the connection) |
00:07:24 | chrisjj | IIRC fail is only when there's long hence scrolling text. So perhaps disable scrolling to find out whether it is long or scrolling that's the cuase. |
00:07:26 | [Saint] | kugel might also be interested in this issue if you find a repeatable failure case. |
00:08:16 | [Saint] | Userfont suddenly unloading itself is indeed quite suspicious. |
00:08:24 | toehser1 | Since the font is only set in the CFG, it is trivial for me to try with no other difference than the font... and right now I've done that and can't make it fail with 12-Nimbus |
00:08:32 | toehser1 | Whoops ! |
00:08:54 | toehser1 | spoke too soon. Doesn't require Anti Alias to fail. Failed with 12-Nimbus too. Nice to rule out AA |
00:09:34 | | Join Rower [0] (husvagn@90-230-142-55-no41.tbcn.telia.com) |
00:10:06 | * | [Saint] wonders what happens if you use so much of the targets available buffer that it needs to start unloading things for playback |
00:10:13 | chrisjj | Have you tried the default WPS theme? |
00:11:34 | | Quit terrapin (Quit: Page closed) |
00:11:57 | | Quit Rower (Client Quit) |
00:12:08 | [Saint] | I used to have a fairly reasonable understanding of the buffering system prior to buflib, but, no longer. |
00:12:25 | toehser1 | I don't see it failing in cabbiev2 but that seems to use sysfont anyway so it might be hard to tell |
00:12:32 | kugel | [Saint]: non-multiple-of-3 images can be handled easily actually |
00:12:38 | [Saint] | And every time I look in that area it makes me want to break down in tears. |
00:12:51 | [Saint] | Its some fairly complex stuff. |
00:13:18 | [Saint] | toehser1: cabbiev2 _shouldn't_ be using sysfont |
00:13:30 | chrisjj | OK, then I suggest test cabbiev2 + 12-Nimbus. |
00:13:39 | [Saint] | I believe every cabbie loads a userfont. |
00:14:39 | toehser1 | I think probably it _is_ theme related, whatever is triggering it. I do NOT see it failing in other themes. |
00:15:09 | [Saint] | I can't really say much more at this point than "I don't believe anything should be asking userfont to give itself up, especially not when it is currently in use". |
00:15:59 | | Join Bluefoxicy [0] (~Bluefoxic@c-76-21-157-203.hsd1.md.comcast.net) |
00:17:41 | | Quit pamaury (Read error: Operation timed out) |
00:18:58 | chrisjj | I'd like to see the .wps . |
00:19:16 | toehser1 | The themes are ClipZip tomsway1 tomsway2 and tomsway3 |
00:19:48 | toehser1 | I can make all 3 fail... which might implicate something in the status, which they share. |
00:20:46 | [Saint] | It is certainly possible that the theme is coded less than perfectly. ~90% of user themes, in my experience, and nasty copy/paste kludges. |
00:21:02 | [Saint] | But even if the theme is broken. We should be failing gracefully. |
00:21:10 | [Saint] | And this is less than graceful. |
00:21:26 | [Saint] | s/and nasty/are nasty/ |
00:22:30 | [Saint] | And even if the theme is coded *very* nastily, it shouldn;t be possible for it to cause the system to give up the currently loaded userfont. |
00:24:43 | [Saint] | Its almost at a point where we'd need to say "Got a bug? Using a custom theme? Well...too bad, don't". |
00:26:34 | [Saint] | Themes have been managing to cause inexplicable, technically impossible issues for a few years now. So much so it is very common practice for one of my first questions when a bug is raised is "Can you repeat it with the default theme?". |
00:26:54 | chrisjj | So which fonr it required for those themes to fail? |
00:27:32 | chrisjj | Correction : So which font is required for those themes to fail? |
00:27:32 | | Join Rower [0] (husvagn@90-230-142-55-no41.tbcn.telia.com) |
00:28:16 | | Quit Rower (Client Quit) |
00:30:03 | JdGordon | [Saint]: we don't do any type of swapping, so there is no such thing as unloading things for playback |
00:31:36 | [Saint] | IS there always a set minimum amount for the playback buffer? Or is it possible to reduce it to such an extent it might fail for tracks with very large frames? |
00:32:24 | JdGordon | in theory it is possible |
00:32:32 | JdGordon | but thats 28Mb or so of bitmaps to load |
00:32:35 | JdGordon | good luck! |
00:33:29 | [Saint] | That sounds like a challenge. :) |
00:33:42 | JdGordon | kugel: do you have a link to the 9seg patch? |
00:34:33 | | Join Rower [0] (husvagn@90-230-142-55-no41.tbcn.telia.com) |
00:34:59 | * | [Saint] really should make an effort to properly understand the buffering system |
00:35:30 | [Saint] | At least once a week or so I get to looking at something that leads me there, and then I whimper and retreat with my tail between my legsa. |
00:35:38 | [Saint] | *legs |
00:36:19 | [Saint] | It pleases me somewhat that I am not the only one that gets mightily confused by it, though. |
00:38:30 | | Quit Rower (Client Quit) |
00:40:18 | chrisjj | What's the quickest quick way to get the simulator to reload tagnavi_custom.config? I know the slow way :) |
00:40:22 | | Join Rower [0] (husvagn@90-230-142-55-no41.tbcn.telia.com) |
00:41:07 | [Saint] | Its a config file. Load it just like any other. |
00:41:20 | [Saint] | Navigate to it and "run" it. Same as any other .cfg |
00:43:47 | chrisjj | Thanks, buts that's slower than my current slow way - restart. |
00:44:00 | fs-bluebot | Build Server message: New build round started. Revision fde92de, 243 builds, 32 clients. |
00:45:40 | kugel | JdGordon: what patch? |
00:46:17 | | Quit Rower (Quit: Hmmm...) |
00:46:47 | JdGordon | kugel: the one your playing with |
00:47:03 | fs-bluebot | Build Server message: Build round completed after 184 seconds. |
00:47:18 | kugel | JdGordon: the 9seg function is in git |
00:47:30 | JdGordon | oh cool :) :p |
00:47:39 | JdGordon | so its got a bug? |
00:47:43 | [Saint] | Did you forget committing that? :) |
00:47:48 | kugel | i just modified bmp2rb to support alpha bmps and compiled a splash background image |
00:47:58 | kugel | JdGordon: not anymore :) |
00:48:04 | kugel | i just committed a fix |
00:48:46 | JdGordon | greay |
00:49:01 | kugel | you clearly haven't tested non 3nx3n images :) |
00:49:02 | | Quit zoktar (Read error: Connection reset by peer) |
00:49:27 | JdGordon | you're supposed to use corectly sized images :) |
00:49:41 | | Join zoktar [0] (~zoktar@unaffiliated/zoktar) |
00:49:45 | kugel | supporting "odd" images is easy enough |
00:50:01 | [Saint] | I brought that up at the time and I was fairly sure you fixed it, but maybe it never made it in. |
00:50:13 | kugel | anyway, my main issue was when the resulting image (composed of many segments) wasnt a multiple of the segment size |
00:50:27 | kugel | the last segment was drawn over the rect boundaries |
00:51:13 | JdGordon | are you buiding the middle part as you draw the text? |
00:51:19 | *** | Saving seen data "./dancer.seen" |
00:51:23 | JdGordon | i.e not calcualting the neeeded size first? |
00:52:23 | kugel | ??? |
00:52:38 | kugel | no |
00:52:45 | JdGordon | but i vagually remember something along the lines that it didnt matter if the middle section wasnt an exact multiple |
00:52:58 | kugel | size is first calculated, then the 9segment is drawn, and at last the text |
00:52:58 | JdGordon | if it was bigger it would be overwritten by the edge peices |
00:54:25 | | Quit mt (Ping timeout: 260 seconds) |
00:55:57 | | Quit ender` (Quit: At least most of the dead had been cleared away now, though it took weeks. The Necropolis furnaces ran full-time, and a lot of restaurants boasted a Soylent Green special on their menus, for the more discerning palates. -- Simon R. Green: Hell to Pay) |
00:57:00 | [Saint] | that's part of what I was trying to say earlier regarding draw order before the image is flattened. |
00:57:37 | | Quit kugel (Ping timeout: 252 seconds) |
00:57:58 | [Saint] | As long as the edge pieces are aligned within the viewport bounds, it shouldn;t matter at all if they are even multiples of 3 or not. |
00:58:17 | [Saint] | As draw order and overlapping should make that invisible. |
00:58:57 | JdGordon | you might lose some pixels of the text thouhg - matbe |
00:59:00 | JdGordon | maybe* |
00:59:25 | [Saint] | Right. In this case I wouldn;t be drawing the text with the image, personally. |
00:59:36 | [Saint] | I would overlap a text viewport with userfont overtop. |
01:00 |
01:00:30 | [Saint] | Then as long as that is called after the 9seg backdrop it won;t matter. |
01:14:01 | | Join zaphee [0] (~user@213-245-219-176.rev.numericable.fr) |
01:14:06 | | Part zaphee |
01:31:06 | | Join Strife89 [0] (~Strife89@adsl-98-80-235-99.mcn.bellsouth.net) |
01:32:51 | toehser1 | The theme has less than 1K of bitmaps. So it isn't a memory-use by bitmaps thing, period. |
01:33:07 | toehser1 | All it uses bitmaps for is the status bar icons. |
01:33:21 | toehser1 | It seems to fail with whatever font. |
01:33:32 | toehser1 | I'm building git head now to try with that. |
01:36:45 | chrisjj | Whatever font including system font? |
01:48:04 | toehser1 | Git head fails worse. Crash with "prefetch abort at 72 / FSR 0x82 / (domain 8, fault 2) / pc:726F4C20 sp:300) very soon with that theme. |
01:50:09 | toehser1 | Doesn't fail with cabbiev2. |
01:50:28 | toehser1 | I'll try to bisect things about the theme... |
01:51:51 | [Saint] | toehser1: If it isn;t too much hassle for you, could you please pastebin the theme elements; .cfg/.fms/.wps/.sbs/etc (preferably in a single pastebin, visibly separated) for me so I can rule out the theme doing anything obvious crazy? |
01:52:34 | [Saint] | I'm on mobile presently, so its not that easy for me to do so myself. But I have about an hour to kill sitting at the Dr.'s office waiting so I'll be happy to review the theme code. |
01:53:38 | [Saint] | The theme technically shouldn't be able to cause this behavior, regardless how sane or insane it is, but that hasn't stopped theme authors from being able to craft themes that break core functionality before. |
01:53:46 | * | [Saint] glares at lebellium :P |
01:55:04 | [Saint] | Lebellium manages to pretty reliably break USB with ta theme, and a while ago another user managed to completely break shuffle with a theme playlist viewer. |
01:55:17 | [Saint] | s/ta/a/ |
01:55:54 | [Saint] | (and neither of those two things are technically possible) |
01:57:17 | [Saint] | But the Rockbox codebase is vast, and what one piece of code suggests is impossible doesn't necessarily align with reality. |
01:58:14 | [Saint] | (despite the continued best efforts of many very smart individuals to ensure this doesn't happen) |
02:00 |
02:01:09 | | Quit Strife89 (Ping timeout: 252 seconds) |
02:03:17 | | Nick SuperBrainAK is now known as DormantBrain (~andy@2001:470:8:a61::5f92:59a1) |
02:22:12 | | Join mt [0] (~MT@cpe-24-165-191-253.neo.res.rr.com) |
02:22:38 | toehser1 | The themes are on the themesite. |
02:23:03 | | Quit zoktar (Quit: -) |
02:23:06 | toehser1 | What is "pastebin"? |
02:23:51 | | Quit foolsh (Quit: foolsh) |
02:23:57 | toehser1 | Huh. Didn't know about that. Sure... |
02:26:59 | | Quit amayer (Quit: Leaving) |
02:32:44 | toehser1 | Ok, I pastebinned the cfg and the wps |
02:33:04 | toehser1 | tomsway2.cfg and tomsway2.wps |
02:34:02 | [Saint] | ...can I have a link? |
02:34:32 | toehser1 | http://pastebin.com/KJVmHWEy and http://pastebin.com/XiryrjBu (is there an easier way to refer to them?) |
02:34:47 | [Saint] | That's fine. Thanks. |
02:35:00 | toehser1 | I gave them names of "tomsway2.cfg" and "tomsway2.wps" but search doesn't seem to find them, maybe it lags. |
02:36:28 | * | [Saint] wonders what "FU" is supposed to be. |
02:36:37 | [Saint] | I can guess the intent. But it seems amusing to me. |
02:36:40 | toehser1 | "FULL" |
02:36:46 | [Saint] | (%ar%?if(%bl, =, 100)<FU|%bl>) |
02:37:31 | toehser1 | Yes... I thought of whether to use "OK" or something else... after all, I only wanted 2 digits of space for something that goes from 00-99... |
02:37:38 | toehser1 | And it wouldn't be right to call 100 99. |
02:38:01 | toehser1 | "FU" was both obvious, and amusing... |
02:39:01 | toehser1 | I figured that a user would figure it out pretty quickly. |
02:43:31 | [Saint] | What is going on with the progressbar and the skin engine drawn overlapping rectangles? |
02:43:44 | [Saint] | (it looks really screwed up in the screenshots) |
02:44:02 | toehser1 | they're not overlapping - it is scale markers under the progress bar. And the VU meter is under that. |
02:44:31 | toehser1 | If you see it work it makes sense - progress bar over vu meters, with some tick marks at 25% 50% 75% under the progress bar. |
02:44:45 | toehser1 | none of that overlaps, though I think |
02:45:34 | [Saint] | They are overlapped by the progressbar. Which is drawn first, then overlapped by the rectangles, which will then make things weird because dynamicly updating content should always be the last thing drawn if you really must overlap them. |
02:45:50 | toehser1 | Are they? Let me look at the view offsets |
02:46:29 | [Saint] | Oh. my mistake. Sorry. |
02:46:46 | toehser1 | You see it - the pb is 2 high, the dr starts after 2. |
02:46:55 | toehser1 | adjacent, not overlapped. |
02:46:56 | [Saint] | I suspect in this case it would be a lot more efficient to load a tiny bitmap to do this. |
02:47:11 | toehser1 | I was _just_ thinking that. |
02:47:16 | toehser1 | I'll do that. |
02:47:28 | toehser1 | But - I doubt the problem is related to that stuff at all. |
02:47:44 | [Saint] | Sorry about the overlap confusing. I was reading a value wrong, multiple times in a row, apparently. |
02:47:54 | toehser1 | I have life intruding my bandwidth for bisecting though. |
02:48:23 | [Saint] | And no. This theme isn't doing anything that raises any alarm bells. |
02:48:30 | toehser1 | No apology necessary, trying to layout coordinates mentally, with multiple 2-pixel rectangles, is inherently likely for transposition... |
02:49:14 | toehser1 | I'm rebuilding the simulator now from head. Last I checked, it works perfectly in sim, fails in clip zip only. |
02:49:29 | toehser1 | But I need to copy the playlist from the zip to the sim, test the same way on both sides. |
02:50:26 | [Saint] | The simulator doesn't have /exactly/ the same behavior as the physical device in many aspects. |
02:50:56 | [Saint] | Unfortunately that means that some things simply just won't work the same way on device as they will in the sim. |
02:51:21 | *** | Saving seen data "./dancer.seen" |
02:51:42 | [Saint] | It is more of a way for people to take Rockbox for a test drive than it is a complete HW-accurate emulation. |
02:53:29 | [Saint] | Yeah - in fact, I am rather happy to say that this is one of the sanest user-created theme I have ever had the pleasure of reviewing. |
02:53:41 | | Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs) |
02:54:12 | [Saint] | Absolutely nothing about it is suspicious at first glance, nor upon a slightly deeper inspection. |
02:55:40 | [Saint] | The only issues I have with it are non-essential syntactical things that don't change operation at all. |
02:56:00 | [Saint] | 1 - non-descriptive identifiers |
02:56:21 | [Saint] | 2 - blank flase cases in true/false conditions |
02:58:01 | [Saint] | So for example instead of "%xl(S,status.bmp,0,0,15)" I would do "%xl(status_indicator,status.bmp,0,0,15)" |
02:59:00 | [Saint] | And then later call "%?XX<%xd(status_indicator, 1)|%xd(status_indicator, 2)|%xd(status_indicator, 3)|....>" |
02:59:29 | toehser1 | For some reason I thought they were 1-char identifiers... |
03:00 |
03:00:03 | [Saint] | And for things like "%?XX<%xd(XX)|>" where you only care about the true case, changing it to ""%?XX<%xd(XX)>" |
03:00:26 | toehser1 | easy things to fix though. After I find the bug, I'll do all that. |
03:00:27 | [Saint] | And, they used to be this way, up until the massive skin engine reshuffle from 2 years or so ago. |
03:00:48 | [Saint] | But it imposed an arbitrary limit, and is hard to read. |
03:01:09 | | Join zoktar [0] (~zoktar@unaffiliated/zoktar) |
03:01:28 | [Saint] | It means you could only call identifiers from Aa to AZ. |
03:01:40 | [Saint] | Whereas now it is theoretically infinite. |
03:02:55 | [Saint] | And it also has the bonus, if the idents are descriptive, of making it much easier to understand at a glance what a particular function is doing. Even if you have only a very basic understanding of the skin engine syntax. |
03:03:48 | [Saint] | But as I said, neither of those two "issues" would cause the behavior you're experiencing, nor would it change functionality at all. It is purely syntactical and would just be for the benefit of those who may look at the code of your theme. |
03:11:16 | [Saint] | toehser1: One last issue. |
03:11:28 | [Saint] | Well..."issue". The clock is terribly inefficient. |
03:11:56 | [Saint] | It makes much more sense to draw it in a single viewport and use the loaded font to draw the ":" |
03:12:16 | [Saint] | Since that will be essentially free, as that glyph will almost certainly already be loaded. |
03:12:56 | toehser1 | The purpose is to squish the : into many fewer horizontal pixels than the font uses. But I may just get rid of the clock. |
03:13:21 | toehser1 | I'm not convinced that anyone uses their ClipZip instead of their watch or their cell phone for the wall clock time... |
03:13:40 | | Join derf_ [0] (~derf@fuzzyneural.net) |
03:13:55 | [Saint] | You could always alternate between the time and battery/volume/play status |
03:13:56 | toehser1 | I suppose, there, also, I could load a bitmap for the narrow colon image, instead of the"dr" commands. |
03:14:06 | * | [Saint] nods |
03:14:12 | | Join knitt1 [0] (~knittl@ssh.fumuga.com) |
03:14:12 | | Quit knitt1 (Changing host) |
03:14:12 | | Join knitt1 [0] (~knittl@unaffiliated/knittl) |
03:14:16 | | Join linuxguy4 [0] (~timj@24-148-61-208.c3-0.lem-ubr1.chi-lem.il.cable.rcn.com) |
03:14:30 | toehser1 | How does one measure the inefficiency? Are there metrics that would show % of time used on different theme elements? |
03:14:33 | [Saint] | But it would be ideal to just draw it with the font engine if it is at all possible. |
03:14:39 | [Saint] | Since its basically free. |
03:14:57 | | Quit linuxguy3 (Ping timeout: 272 seconds) |
03:14:57 | | Quit alexbobp (Ping timeout: 272 seconds) |
03:14:57 | | Quit Slasheri (Ping timeout: 272 seconds) |
03:14:57 | | Quit michaelni (Ping timeout: 272 seconds) |
03:14:57 | | Quit knittl (Ping timeout: 272 seconds) |
03:14:58 | | Quit derf (Ping timeout: 272 seconds) |
03:15:02 | | Nick derf_ is now known as derf (~derf@fuzzyneural.net) |
03:15:09 | toehser1 | I've come close to creating my own font for just such reasons - I only have 96 horizontal pixels, so 4 or 5 here and there really adds up. |
03:15:19 | | Quit dfkt (Remote host closed the connection) |
03:15:21 | [Saint] | This is true. |
03:15:42 | | Join alexbobp [0] (~alex@capitalthree.pwnz.org) |
03:15:44 | | Join Slasheri [0] (miipekk@xen.ihme.org) |
03:15:44 | | Quit Slasheri (Changing host) |
03:15:44 | | Join Slasheri [0] (miipekk@rockbox/developer/Slasheri) |
03:16:27 | toehser1 | I get this in the sim now: *** stack smashing detected *** ... so maybe I do have a problem reproduced there (albeit with some difference in failure mode) |
03:16:45 | [Saint] | As far as measuring inefficiency goes, I just use my eye and experience. CPU time isn't really the issue, its more the "issue" of wasting playback buffer. |
03:17:08 | [Saint] | How much RAM a particular skin is using with al loaded elements is visible via the debug screen. |
03:17:23 | toehser1 | Or, maybe I just needed to do a make clean, I'll try that before I worry. |
03:17:46 | | Join michaelni [0] (~michael@chello084114129144.4.15.vie.surfer.at) |
03:19:09 | [Saint] | In this case I'm sure it isn't /too/ much of an issue. But personally I like to try to reuse things where I can or try to get them for free. Ideally the theme should have the smallest footprint possible as more playback buffer directly equates to a longer runtime. |
03:20:37 | [Saint] | But in this instance we're probably only talking about a few kB, and its a flash target as well, so disk access isn't nearly as expensive. |
03:20:40 | | Join Strife89 [0] (~Strife89@adsl-98-80-235-99.mcn.bellsouth.net) |
03:20:45 | | Quit Strife89 (Remote host closed the connection) |
03:49:47 | | Join zaphee [0] (~user@ede67-2-82-232-36-5.fbx.proxad.net) |
03:49:51 | | Part zaphee |
04:00 |
04:12:21 | | Join Zarggg [0] (~zarggg@24.229.140.62.res-cmts.sm.ptd.net) |
04:25:27 | | Nick DormantBrain is now known as SuperBrainAK (~andy@2001:470:8:a61::5f92:59a1) |
04:36:40 | JdGordon | PurlingNayuki: ping? |
04:51:25 | *** | Saving seen data "./dancer.seen" |
04:58:03 | | Quit pixelma (Disconnected by services) |
04:58:04 | | Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) |
04:58:04 | | Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) |
04:58:04 | | Quit amiconn (Disconnected by services) |
04:58:06 | | Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) |
04:58:08 | | Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) |
05:00 |
05:03:21 | toehser1 | The (good?) news is, with the tips of git, it hasn't done the font loss thing. (It just crashes.) |
05:05:25 | toehser1 | If I take off the very last line of the WPS, it seems not to be crashing... |
05:05:28 | toehser1 | %V(0,85,96,11,1) |
05:05:28 | toehser1 | %s%ac%?Ia<%Ia >%?It<%It >%?Id<%Id >%?Fn<%Fn |no next file >%?Fp<%Fp> |
05:05:41 | | Quit [7] (Disconnected by services) |
05:05:54 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
05:06:18 | toehser1 | now, here is a question: the viewport is from 0 for 96, and from 85 for 11 - all fine. |
05:07:06 | toehser1 | The font, though, is more than an 11 point font - it is getting cut off at the bottom. |
05:07:26 | toehser1 | Is it possible that something is letting it corrupt memory past the edge of the viewport? |
05:07:32 | [Saint] | Nope. |
05:07:58 | [Saint] | It doesn't matter in the slightest if portions of content are out of bounds. |
05:08:19 | toehser1 | Acckh, it just crashed without that line, anyway... but it went for a long time without crashing, that time. |
05:09:08 | [Saint] | Yeah, that line isn't exactly pretty (especially as it is centered, on a 96px screen...but, it is syntactically valid. |
05:10:40 | toehser1 | When I take out that one and also the # Miscellaneous |
05:10:40 | toehser1 | %V(0,47,96,13,1) |
05:10:40 | toehser1 | %s%iy %fc %fb %fv %ff %fp |
05:10:40 | DBUG | Enqueued KICK toehser1 |
05:10:40 | toehser1 | it is running for a long time - if not causing the problem they are at least compounding it. |
05:12:10 | [Saint] | It certainly shouldn't be. |
05:12:21 | toehser1 | Of course, as with any intermittant failure, I may just be seeing patterns where there are none. |
05:12:28 | [Saint] | I have some metadata in some tracks that is a LOT longer than that field combined. |
05:13:05 | toehser1 | I'm running out of evening time, I'll go for the dump address approach tomorrow from the crash message and the cores from when the sim crashed. |
05:13:17 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
05:13:17 | * | [Saint] nods |
05:13:18 | toehser1 | So far I've been lazy, looking to bisect the theme and get lucky. |
05:13:45 | [Saint] | Well, even if the theme was "broken", the error still lies with the core. |
05:13:53 | [Saint] | So it would be avoiding an issue at best. |
05:15:30 | toehser1 | I'm not getting it to crash with those 2 lines commented. I'll try putting the bottom one back. |
05:17:47 | toehser1 | right away, crash. |
05:18:32 | [Saint] | Could you disable scrolling and check that, please? |
05:18:56 | toehser1 | Just by taking out the %s tags? |
05:18:56 | [Saint] | (remove %s from viewports(s) in question) |
05:19:00 | * | [Saint] nods |
05:19:27 | toehser1 | I think I tried that and still got it to fail. I'll take out all the %s in the theme... hang on. |
05:21:53 | PurlingNayuki | JdGordon: Sorry again I was at classes |
05:22:25 | JdGordon | PurlingNayuki: hey, what time zone are you in? i was heading to work already when you replied :p |
05:22:57 | toehser1 | Crashes right away even without any %s tags. |
05:22:57 | PurlingNayuki | Here in GMT+8 Hongkong timezone |
05:22:57 | JdGordon | i really want to finish off your patch and get it in :) |
05:23:47 | PurlingNayuki | I'd like to so I have already got all my spare time spent on it. |
05:24:34 | JdGordon | whats the default value it gets now? |
05:24:42 | JdGordon | am i right that it gets the volume default value? |
05:24:46 | JdGordon | so -25? |
05:25:09 | toehser1 | well... OK, ok, I'll try to look at the real problem. I'm lazy about that for many reasons - not the least of which, my job has been rotting by brain with Java for a while, I'll have to dredge myself back into C after avoiding any non-trivial real work for long enough to have grinding of my mental gears... But for now, in TZ UTC-5, I'm setting it aside for a bit. |
05:25:19 | PurlingNayuki | I've pushed an acceptable one and reworking it with CUSTOM_SETTING |
05:26:39 | PurlingNayuki | Yes sorry, it was first default to the maximum volume but it's not now |
05:27:04 | JdGordon | ah great |
05:27:07 | JdGordon | I'll have a look |
05:27:53 | PurlingNayuki | I'm a little busy with my exams but will finish it within days |
05:28:23 | JdGordon | #16 is using the SOUND_SETTING still? |
05:28:29 | JdGordon | you should get back to exams then! :) |
05:28:32 | PurlingNayuki | If everything is working as is expected |
05:28:41 | PurlingNayuki | Yes it is |
05:29:28 | | Nick SuperBrainAK is now known as DormantBrain (~andy@2001:470:8:a61::5f92:59a1) |
05:30:33 | | Nick DormantBrain is now known as SuperBrainAK (~andy@2001:470:8:a61::5f92:59a1) |
05:30:38 | PurlingNayuki | There are examples I can follow so I don't think it will be much too diffcult |
05:30:52 | JdGordon | great |
05:30:58 | JdGordon | ask if you get stuck :) |
05:31:18 | PurlingNayuki | Thanks, you really help a lot |
05:31:30 | JdGordon | I'm gmt+11 so pretty close |
05:31:40 | JdGordon | melbourne, .au |
05:32:29 | PurlingNayuki | I know there for I have classmates studying abroad there |
05:34:04 | JdGordon | you should also pop into #rockbox-community |
05:34:50 | PurlingNayuki | Yeah I got into it just now |
05:50:28 | | Join alexbobp_ [0] (~alex@capitalthree.pwnz.org) |
05:55:21 | | Quit alexbobp (*.net *.split) |
05:55:21 | | Quit fs-bluebot (*.net *.split) |
05:55:22 | | Quit MarcAndersen (*.net *.split) |
05:55:22 | | Quit shamus (*.net *.split) |
05:57:08 | | Join shamus [0] (~shmaus@ip-206-192-193-180.marylandheights.ip.cablemo.net) |
05:57:08 | | Join fs-bluebot [0] (~fs-bluebo@g226071219.adsl.alicedsl.de) |
06:00 |
06:08:56 | | Join Guest81512 [0] (Slayer@c-69-143-187-144.hsd1.va.comcast.net) |
06:11:42 | | Quit Guest80912 (Read error: Connection reset by peer) |
06:51:26 | *** | Saving seen data "./dancer.seen" |
06:56:15 | | Join mortalis [0] (~kvirc@213.33.220.118) |
07:00 |
07:23:14 | | Join Rower [0] (~husvagn@90-230-142-55-no41.tbcn.telia.com) |
07:37:16 | | Quit mt (Ping timeout: 265 seconds) |
07:38:16 | | Join LinusN [0] (linus@giant.haxx.se) |
07:44:34 | | Quit [Saint] (Remote host closed the connection) |
07:46:46 | | Join [Saint] [0] (~saint@rockbox/staff/saint) |
08:00 |
08:03:54 | | Join ender` [0] (krneki@foo.eternallybored.org) |
08:04:20 | | Join fragilematter [0] (~fragilema@unaffiliated/fragilematter) |
08:24:10 | | Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) |
08:24:35 | | Quit tchan (Quit: WeeChat 0.4.1) |
08:25:26 | | Join tchan [0] (~tchan@lunar-linux/developer/tchan) |
08:25:48 | wodz | Do we reclaim dram memory used for iram sections in main binary? I mean we copy the stuff to iram and then we could in theory reclaim are where we copied from. It will be like a few kB I think but still |
08:26:15 | wodz | s/are where/area where/ |
08:27:59 | | Quit tchan (Client Quit) |
08:30:42 | | Join Zaxon [0] (5bcdc204@gateway/web/freenode/ip.91.205.194.4) |
08:31:18 | | Part Zaxon |
08:31:55 | | Join tchan [0] (~tchan@lunar-linux/developer/tchan) |
08:34:35 | | Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) |
08:40:08 | PurlingNayuki | JdGordon: Would it be convenient for you to explain how menus are shown it Rockbox? |
08:40:16 | PurlingNayuki | briefly |
08:40:19 | | Nick knitt1 is now known as knittl (~knittl@unaffiliated/knittl) |
08:40:41 | | Join bertrik [0] (~quassel@ip117-49-211-87.adsl2.static.versatel.nl) |
08:40:41 | | Quit bertrik (Changing host) |
08:40:41 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
08:41:40 | JdGordon | PurlingNayuki: sure! menu.c :) |
08:42:06 | JdGordon | do_menu() |
08:42:14 | PurlingNayuki | Will read it carefully;-) |
08:42:30 | JdGordon | do you have any particualr questions? its very MAGIC |
08:44:41 | PurlingNayuki | Yes and no |
08:45:14 | PurlingNayuki | I've read apps/menus/ |
08:45:53 | PurlingNayuki | But didn't find EQ settings in sound_menu.c |
08:46:38 | JdGordon | they are in eq_menu.c |
08:46:41 | JdGordon | dinner time :) |
08:47:13 | PurlingNayuki | There is eq_menu.c but actually it's displayed in sound menu so I'm a little confused about how EQ menus are shown. |
08:47:51 | wodz | PurlingNayuki: hey, Is it you who have MIPS based onda handy? |
08:49:14 | PurlingNayuki | wodz: Yes I had but I just don't remember where I put it |
08:50:15 | PurlingNayuki | The only thing I cn confirm is that It's lying in my room |
08:51:28 | *** | Saving seen data "./dancer.seen" |
08:51:34 | PurlingNayuki | *can |
08:55:07 | | Join Zagor [0] (~bjst@80.239.169.202) |
08:55:08 | | Quit Zagor (Changing host) |
08:55:08 | | Join Zagor [242] (~bjst@rockbox/developer/Zagor) |
09:00 |
09:10:15 | | Quit bertrik (Read error: Operation timed out) |
09:18:37 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
09:26:46 | [Saint] | Do we have any idea who runs /r/rockbox ? |
09:27:01 | wodz | ? |
09:27:06 | | Nick SuperBrainAK is now known as DormantBrain (~andy@2001:470:8:a61::5f92:59a1) |
09:28:37 | [Saint] | http://www.reddit.com/r/rockbox |
09:31:59 | [Saint] | I find it interesting that for whatever reason people wind up there instead of the forum. |
09:32:58 | PurlingNayuki | Why? |
09:32:59 | wodz | who cares :-) |
09:37:00 | wodz | We do the magic for reclaiming space taken by .init section on some target (#HAVE_INIT_ATTR) so this should be fairly simple to reclaim iram part as well |
09:38:35 | | Join petur [0] (5bb7304d@rockbox/developer/petur) |
09:40:25 | | Quit yosafbridge (Ping timeout: 264 seconds) |
09:40:45 | JdGordon | PurlingNayuki: back |
09:42:24 | | Join yosafbridge [0] (~yosafbrid@li125-242.members.linode.com) |
09:44:37 | PurlingNayuki | and classes finished |
09:51:42 | | Quit fragilematter (Quit: Leaving.) |
09:54:00 | | Join fragilematter [0] (~fragilema@unaffiliated/fragilematter) |
10:00 |
10:02:36 | | Nick alexbobp_ is now known as alexbobp (~alex@capitalthree.pwnz.org) |
10:07:54 | | Quit pamaury (Ping timeout: 259 seconds) |
10:11:42 | | Quit Rower (Ping timeout: 260 seconds) |
10:17:50 | | Quit einhirn (Ping timeout: 272 seconds) |
10:26:11 | | Quit [Saint] (Remote host closed the connection) |
10:28:22 | | Join [Saint] [0] (~saint@rockbox/staff/saint) |
10:29:06 | | Quit Raptors (Quit: Leaving) |
10:34:15 | | Join Raptors [0] (~whoneedsa@198-200-68-213.cpe.distributel.net) |
10:46:08 | copper | pamaury (logs): problems with recent build of Rockbox for the Fuze+: http://www.anythingbutipod.com/forum/showthread.php?t=71807&page=6 |
10:46:33 | copper | dunno if it's related to the recent conversation(s) here |
10:47:11 | copper | this, too: http://www.anythingbutipod.com/forum/showpost.php?p=642911&postcount=96 |
10:51:32 | *** | Saving seen data "./dancer.seen" |
10:55:34 | wodz | There was usb buffer handling fix recently. It would be nice to know the exact version exhibiting odd behavior |
11:00 |
11:05:14 | copper | I can reproduce it in the sim |
11:06:23 | wodz | lovely |
11:06:53 | wodz | are you able to bisect? |
11:06:57 | copper | https://outpost.fr/tmp/lg9.png |
11:06:59 | copper | yes |
11:07:18 | copper | wodz: can you give me a range of revisions? |
11:07:47 | wodz | what is broken in this image? I can't see at first glance |
11:08:27 | copper | text is absent, except for the durations |
11:08:34 | wodz | ah right |
11:08:45 | copper | https://outpost.fr/rockbox/Googley-FuzePlus-Orange.png |
11:08:51 | copper | that's how it's supposed to look |
11:09:12 | copper | (don't mind the colors) |
11:09:51 | gevaerts | copper: I'd just test 3.13 and if that works, start from there |
11:10:17 | gevaerts | The nice thing about bisecting is that hugely overestimating the range you need only adds very few extra steps |
11:10:37 | copper | er, that's super old |
11:11:32 | copper | I can bisect starting from a15a15b which I know to be working perfectly |
11:11:48 | wodz | I would check 204668d first. Thats just before kugel's lcd rework but after usb buflib related changes |
11:12:42 | copper | that's even more recent |
11:13:04 | copper | git bisect start 204668d? |
11:13:32 | wodz | I always have to refer to UsingGit :-) |
11:13:57 | copper | I'm there |
11:14:07 | copper | but it doesn't say how to specify a starting point for bisecting |
11:14:20 | gevaerts | git bisect good <something> |
11:14:26 | copper | ah, ok |
11:14:27 | gevaerts | git bisect bad <something else> |
11:14:36 | copper | alright, doing it |
11:14:42 | gevaerts | And then just git bisect good/bad after every test |
11:15:40 | gevaerts | And possibly git bisect skip if you can't do the test (e.g. because you hit an unrelated bug first) |
11:29:26 | copper | 91ef65306bf4e459f430d6dc44e5923d6b9f8399 is the first bad commit |
11:29:32 | copper | skin_engine: Adapt put_line(). |
11:30:05 | copper | "This allows for code unification and removal of a workaround (STYLE_XY_PIXELS)." |
11:30:54 | gevaerts | OK, so probably the sort of not-entirely-unexpected fallout for the sort of large rework kugel has been doing |
11:33:21 | copper | same deal with the iPod Classic |
11:33:29 | copper | which makes sense, I guess |
11:51:30 | | Join petur_ [0] (5bb7304d@rockbox/developer/petur) |
11:53:17 | | Quit petur (Ping timeout: 272 seconds) |
12:00 |
12:01:16 | | Nick petur_ is now known as petur (5bb7304d@rockbox/developer/petur) |
12:04:57 | | Join einhirn [0] (~Miranda@2001:638:605:4:13d:be65:8e30:1c0e) |
12:05:00 | | Join kugel [0] (~kugel@193.174.67.16) |
12:05:00 | | Quit kugel (Changing host) |
12:05:00 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
12:14:21 | kugel | copper: works for me in the fuze+ sim |
12:17:59 | copper | with what theme? |
12:19:50 | kugel | copper: http://themes.rockbox.org/index.php?themeid=1923&target=sansafuzeplus |
12:20:08 | kugel | I can see the text |
12:20:15 | kugel | however, looking again, it's not colored |
12:21:42 | copper | indeed |
12:22:06 | copper | text is visible but not colored with the "official" Googley theme |
12:22:29 | copper | text is invisible with the stripped down variant available at https://outpost.fr/rockbox/ |
12:22:34 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
12:22:45 | copper | e.g. https://outpost.fr/rockbox/Googley-Classic-Orange-A14-2013-09-21.zip |
12:23:15 | | Join foolsh [0] (~foolsh@c-24-14-134-34.hsd1.in.comcast.net) |
12:23:42 | copper | the A14 / A19 / B14 / B19 variants have fixed text size and with conditionals removed |
12:24:52 | copper | I have to say, making a Rockbox theme that works (working around theme bugs) is quite difficult |
12:24:52 | | Quit kugel (Ping timeout: 252 seconds) |
12:26:13 | | Quit pamaury (Read error: Operation timed out) |
12:26:14 | copper | themes are very "fragile", in the sense that, so much as adding a new line can break them |
12:26:41 | copper | or removing a new line character |
12:28:09 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
12:32:38 | | Quit pamaury (Ping timeout: 260 seconds) |
12:32:39 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
12:36:07 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
12:46:21 | | Quit pamaury (Read error: Operation timed out) |
12:49:58 | | Join kugel [0] (~kugel@193.174.67.16) |
12:49:58 | | Quit kugel (Changing host) |
12:49:58 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
12:51:02 | kugel | copper: that one doesnt even load here |
12:51:36 | *** | Saving seen data "./dancer.seen" |
12:52:19 | | Join ikeboy [0] (~ikeboy@ool-435622d3.dyn.optonline.net) |
12:53:07 | copper | kugel: what do you mean, "doesn't load"? |
12:53:17 | copper | reboot the sim |
12:54:06 | kugel | did that |
12:54:17 | kugel | I get no backdrop and fallback wps |
12:54:44 | kugel | %Vx lines should be on their own |
12:54:52 | kugel | AFAIK |
12:55:42 | copper | a new line causes bugs |
12:55:49 | kugel | what bugs? |
12:56:12 | kugel | please report bugs to the tracker |
12:56:27 | copper | display bugs, can't remember which ones exactly, but stuff like gray bars across artwork |
12:56:27 | kugel | however I'm not aware of any issues that require stuff to be on the same line as %Vx |
12:57:38 | kugel | text (inline or via tags) is drawn line-by-line after the %Vx tags, the first line of text should also be the first line after %Vx in the .wps |
12:57:52 | kugel | I don't even know where text is supposed to land if it's on the same line as %Vx |
12:58:16 | copper | believe me, I have spent many hours working around many bugs |
12:58:19 | kugel | I'm not saying this causes your problems but it's certainly not right (not intended like this anyway) |
12:58:27 | copper | anyway, I linked to the iPod Classic theme by mistake |
12:58:36 | kugel | copper: please report these bugs |
12:58:44 | copper | https://outpost.fr/rockbox/Googley-FuzePlus-Orange-A14-2013-09-21.zip |
13:00 |
13:01:19 | kugel | we can't fix these bugs if you don't tell us and hide the workarounds |
13:01:25 | | Join mt [0] (~MT@cpe-24-165-191-253.neo.res.rr.com) |
13:01:41 | kugel | you see, cabbiev2 is doing fine without stuff on the same line as %Vx |
13:02:26 | copper | doesn't mean that cabbie is a "good" theme and all the other themes are bad |
13:02:54 | copper | it's just the theme that you guys use, so I assume you guys fix bugs that you encounter with it, before even committing your changes |
13:03:12 | kugel | copper: aha, if I put the track title line after %V then it shows up |
13:04:23 | copper | FS #12892 |
13:04:24 | fs-bluebot | http://www.rockbox.org/tracker/task/12892 backdrop doesn't load when selecting a new theme that was just copied via USB (bugs, unconfirmed) |
13:04:34 | copper | FS #12891 |
13:04:34 | fs-bluebot | http://www.rockbox.org/tracker/task/12891 %?if() evaluates enumeration indexes and arbitrary numbers to (number + 1) (bugs, unconfirmed) |
13:04:40 | copper | FS #12884 |
13:04:40 | fs-bluebot | http://www.rockbox.org/tracker/task/12884 Blinking metadata text on the iPod Video / Classic (bugs, unconfirmed) |
13:04:53 | copper | no-one ever looked into those |
13:04:55 | kugel | the color doesnt work still but the text shows up |
13:05:13 | copper | those are all mine |
13:05:25 | | Quit krabador (Ping timeout: 265 seconds) |
13:05:48 | kugel | copper: okay, thanks for these reports |
13:07:05 | copper | in fact I have reported 6 bugs, all of which are still open |
13:07:26 | copper | all "unconfirmed" |
13:07:36 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
13:07:43 | copper | that's not very motivating, to put it mildly |
13:08:25 | pixelma | I've seen different results depending on the placement of code snippets in the .wps file too, e.g. one with a drawn progressbar that looked partially "blanked" as if one empty line was dran overtop. Reordering the viewports in the code helped, an no there was no overlapping in the viewports I even tried with lots of empty space between viewports |
13:08:42 | copper | same ^^ |
13:08:43 | pixelma | s/dran/drawn |
13:08:49 | copper | about the empty space |
13:11:04 | copper | the theme thing is a lingering problem |
13:11:40 | copper | and it is my understanding that something, somewhere, is completely FUBAR, and no-one knows what it is, or how to fix it |
13:12:31 | copper | beyond the fact that the bugs I have already reported and have never been confirmed, I'm not sure that reporting every single theme bug would help |
13:12:52 | | Quit ikeboy (Quit: ikeboy) |
13:14:02 | copper | all I know is, I can't write proper theme markup without running into some glitch |
13:14:42 | kugel | copper: I located the bug for the text colors, but that the text lines are missing is your theme bug I'm afraid |
13:14:50 | copper | my themes are working as they are now, but if I change anything, something breaks |
13:16:20 | copper | kugel: if you're referring to the newline thing after a viewport, I get a bug either way, with different builds |
13:16:26 | pixelma | I haven't reported it yet (besides here) because I always want to give and find out more details (reliable recipe to replicate, some safe workarounds, some working revisions) but this one is hard - maybe even impossible - to track down |
13:18:43 | kugel | copper: it works for me with the text on the next line (not only in this theme) |
13:18:59 | kugel | I would really like to know what bug you hit there beause I haven't seen it |
13:20:33 | copper | I talked about it here while I was working on the theme |
13:20:57 | copper | and I can't identify bugs clearly if they change from build to build |
13:20:59 | kugel | you should remove these workarounds, it works better without them |
13:21:16 | kugel | perhaps the bug you hit was only temporary |
13:21:17 | copper | what does that mean, "it works better without them"? |
13:21:20 | copper | with what build? |
13:21:25 | kugel | latest |
13:21:28 | copper | there's a reason I used those workarounds |
13:21:43 | kugel | the reason doesnt seem to exist anymore |
13:21:56 | copper | or it's just hidden |
13:22:20 | copper | i.e. the bug doesn't show right now with this particular setup |
13:22:25 | kugel | the text shows up without this workaround, and it's certainly not the way we intended it to be |
13:22:27 | copper | with this particular build |
13:22:54 | copper | my themes have been working fine for months |
13:23:05 | kugel | I would suggest you remove the workaround and ping me if you hit the bug again that requires this |
13:23:26 | kugel | but seeing no text shows up with the workaround in place I can't see how it fixes anything |
13:24:25 | copper | I used the workaround to avoid a bug, and now you're asking me to remove the work around, to avoid another bug? |
13:24:39 | kugel | no, not to avoid another bug |
13:24:49 | kugel | it's not a bug if your workaround doesnt work |
13:25:07 | copper | what is illegal about placing code on the same line as the viewport definition? |
13:25:46 | kugel | the text is placed line by line, and the first line starts the line after the %Vx tag |
13:25:47 | pixelma | kugel: what's "Vx" in your example? |
13:25:59 | kugel | any viewport related tag |
13:26:42 | kugel | %V{,l,d,i,I,...} |
13:27:25 | kugel | copper: in fact, I believe only %Vf, %Vb and %Vg are legal on the same line |
13:27:43 | pixelma | I'd expect %Vf and %Vg (the colour tags) to be possible placing right after %V... aha |
13:28:54 | copper | kugel: if a new line character is required, please update the manual |
13:29:23 | kugel | copper: we're not going to change the code to make a workaround for an semi-related bug work again. Instead, we want to fix the original bug such that the workaround is not required |
13:29:25 | copper | also, am I supposed to force all my users to update to the latest dev build, after making those changes? |
13:30:00 | kugel | i don't think so |
13:30:21 | copper | well it won't work with some older builds |
13:30:29 | copper | also, apparently the theme thing isn't the only new bug |
13:30:53 | copper | "I updated mine to a current dev build and it seems something is broken. I had a reliable USB connection on the Fuze+ before and it crashes every time now unless everything is on the defaults. Anything change from one of the default Rockboxthemes causes a crash when I try to connect through USB." |
13:30:59 | kugel | CustomWPS says "and lines after a viewport declaration are drawn within that viewport". although it's not explicit it suggests that content comes into the lines after the declaration |
13:31:11 | copper | "I'm also seeing a few other things like themes not rendering the way they did before. They don't seem to be completely broken but some elements don't always load. Album art is also loading slower than what it once did." |
13:31:54 | copper | kugel: I don't know where I'm supposed to stand |
13:32:09 | copper | I reported bugs, never got any attention |
13:32:21 | copper | I worked around those bugs, and now I'm supposed to revert my changes |
13:32:41 | copper | not knowing what build will display my themes properly |
13:32:41 | kugel | fwiw, the fuze+ has no stable release so we kind of expect you to update to the current build |
13:34:32 | copper | and if I do revert those changes, and if I run into bugs again, and if I report them again, nothing will happen |
13:34:43 | copper | "use the default theme" |
13:34:49 | copper | "all other themes are not supported" |
13:35:01 | kugel | did anyone say that? |
13:35:13 | kugel | other themes are of course supported |
13:37:02 | copper | then someone please first address my 5 months old bug reports |
13:37:37 | copper | I'm not going to contribute more time and effort just to be ignored |
13:40:11 | copper | especially not knowing if those efforts are justified, and if they will remain pertinent in the foreseable future |
13:41:13 | kugel | I'll try to. I'm sorry that you feel put off, I understand that |
13:42:20 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
13:46:23 | | Quit chrisjj (Quit: Page closed) |
13:48:01 | | Join chrisjj [0] (561bb732@gateway/web/freenode/ip.86.27.183.50) |
13:50:53 | copper | kugel: also, if something is illegal in theme code, then it should be made clear in the documentation, and it should also be reported in the UI somehow |
13:51:11 | copper | an error message, or at least the theme should fail to load altogether |
13:51:53 | copper | without that, it's unclear what is a theme markup error and what is a Rockbox bug |
13:52:14 | kugel | the theme engine is very complex, it's not always easy to tell the root cause of a failure, even within the code |
13:52:36 | copper | I understand it's not an easy fix |
13:52:42 | kugel | and the language is ad-hoc and not at all specified |
13:53:02 | copper | but it needs to be addressed, if we want to stop wasting our time on both sides |
13:53:04 | chrisjj | "if something is illegal in theme code, then it should be made clear in the documentation" I think that's unworkable in practice. A clear spec defines what is legal, and anything else is illegal. |
13:53:30 | copper | chrisjj: that's a better way to put it, I agree |
13:53:59 | copper | something like: "a viewport declaration must be on its own line" |
13:54:15 | chrisjj | However if there is an illegal exception to a what's stated as legal, then I agree that should be stated as such - provided it is not possible to restate the legal to accomodate directly. |
13:54:24 | copper | because that didn't work before, that works now, I have no idea what is correct |
13:54:38 | copper | what if both problems are actual bugs? |
13:55:20 | copper | if there is a specific reason why new lines in theme markup are important, then it needs to be stated clearly |
13:55:21 | chrisjj | Sympathies. IME this looks like the kind of can of worms which cannot be solved except by going back to basics. |
13:55:37 | copper | and the new line thing is just one example |
13:56:18 | chrisjj | "Actual bugs?" Well, it depends on what you mean by a bug. There are differing understandings of the word around here. |
13:56:18 | copper | writing my Googley themes was a real pain |
13:56:50 | copper | and I'm not doing that again until I have precise answers |
13:57:18 | chrisjj | If "rockbox bug" means "not performing as programmer intended", then without an accurate statement of intent, it is impossible to identify anything as a bug. |
13:57:23 | toehser1 | Weird. When I take out those 2 lines, it doesn't crash. When I put in %Ia on the last line, it doesn't crash. When I put %Ia %Ia %Ia %Ia on the last line, it does crash. |
13:59:02 | copper | kugel: surely some markup sanitization (is that a word?) can be done |
13:59:34 | chrisjj | copper: It seesm your reported bugs are actuall bugs in the sense of 'behaviour not according with specification.' In which case perhaps the reports need to record both the behaviour and the specification, and precisely identify the difference. |
13:59:38 | copper | like, if your code expects a new line, it shouldn't be too hard to test for it and complain if the markup doesn't meet your expectations |
13:59:39 | kugel | yes, some is done, but not nearly enough |
14:00 |
14:00:34 | copper | my problem here is that I don't know for sure what is correct in my markup, and what isn't, and apparently we can't seem to agree on what is a bug |
14:00:52 | copper | is the old behavior a bug? Is the new behavior a bug? Are they both bugs? |
14:00:53 | toehser1 | My actual bug crashes rockbox with a dump, it isn't just behavior :) |
14:01:24 | toehser1 | With the tip of git, I don't get the font-change, it just crashes, and it crashes both the simulator and the real player. |
14:03:22 | kugel | toehser1: can you report this to flyspray? |
14:03:25 | toehser1 | The playlist that crashes with tomsway2.cfg/wps and works with other themes, has long-ish names/titles and characters that aren't in USASCII, so it could be related to the length of fields or the internationalized stuff. |
14:03:29 | toehser1 | Yes, I'll get to that... |
14:03:40 | toehser1 | It is more interesting to investigate... |
14:03:46 | toehser1 | I guess I should go ahead and do that. |
14:03:55 | kugel | feel free to investigate |
14:04:13 | kugel | the more you find the easier we can locate and fix the bug |
14:06:50 | kugel | toehser1: if i see this right lines can be 1024 bytes long. for UTF-8 strings this can be a lot less than 1024 characters |
14:06:58 | kugel | do you hit that limit by chance? |
14:10:53 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
14:12:53 | toehser1 | 12929 |
14:13:20 | toehser1 | I doubt I'm hitting that. |
14:13:44 | toehser1 | But, probably this is UTF-8. |
14:13:52 | toehser1 | 12928 is the FlySpray number I created. |
14:13:55 | JdGordon | PurlingNayuki: did you figure it out? |
14:14:00 | toehser1 | I mean 12929. |
14:15:33 | kugel | toehser1: can you compile from source? |
14:17:02 | PurlingNayuki | I haven't got time to write but I think I have a clear direction to the goal |
14:21:58 | chrisjj | "is the old behavior a bug? Is the new behavior a bug?" Or did the specification change, and neither is a bug. |
14:23:25 | chrisjj | This is one reason why it would be a good to have the specification release-managed along with the code. E.g. move the specification from the wiki to the manual. |
14:24:23 | copper | [Saint] wanted to do that a while ago |
14:24:52 | kugel | toehser1: it is difficult to reproduce the bug, can you at least provide an example song title |
14:25:14 | kugel | or better yet, a file |
14:25:35 | chrisjj | More power to you, Saint. |
14:27:54 | | Join pretty_function [0] (~sigBART@123.252.215.196) |
14:29:15 | chrisjj | Hmm... now I see a .wps spec is in both the wiki and the latest fuse+ manual. |
14:29:42 | chrisjj | I wonder if they accord. And I wonder how best to check :) |
14:30:42 | chrisjj | copper: Which spec are you using? |
14:30:51 | pamaury | iirc the manual spec was the actual one, if there ever was something close to a specification |
14:33:07 | chrisjj | May I ask what determines for you which is the "actual" one? |
14:33:56 | | Quit foolsh (Quit: foolsh) |
14:36:03 | toehser1 | yes with source from git head it crashes |
14:36:19 | toehser1 | with 3.13 it does the weird font-changes-randomly-to-sysfont, then crashes later |
14:36:46 | toehser1 | I'll upload a file that crashes it, yes. |
14:37:45 | toehser1 | Work and life will be interfering with my focus on this, so it may be hours. |
14:38:41 | | Join foolsh [0] (~foolsh@c-24-14-134-34.hsd1.in.comcast.net) |
14:39:53 | toehser1 | and I'll figure out what the hex / core means from the build I did |
14:39:55 | copper | chrisjj: at the time, I used the wiki |
14:40:04 | copper | and nothing indicated that I shouldn't use the wiki |
14:40:26 | copper | oh, and that irritating wiki redirection bug still isn't fixed |
14:40:42 | copper | how hard is it to remove the <base> tag in the HTML code |
14:41:05 | kugel | someone needs to do it |
14:41:07 | kugel | ping Zagor |
14:41:16 | kugel | I reported it a while back too |
14:42:56 | copper | http://www.rockbox.org/wiki/WikiIssues |
14:43:04 | copper | date reported: 2013-07-14 |
14:43:12 | copper | that was me, too |
14:45:36 | | Quit wodz (Quit: Leaving) |
14:45:43 | kugel | only few of us have the powers to change the wiki internals |
14:47:35 | copper | who? |
14:48:39 | kugel | Bagder, Zagor and I think LinusN |
14:49:06 | kugel | our grand elders :) |
14:49:27 | copper | pamaury: I think you can mark FS #12833 as fixed |
14:49:28 | fs-bluebot | http://www.rockbox.org/tracker/task/12833 Don't turn on the display when the keypad is locked (bugs, unconfirmed) |
14:49:50 | chrisjj | cupper: "nothing indicated that I shouldn't use the wiki" Understood. And I see you amended the wiki version. |
14:50:05 | copper | to warn against the %if bug |
14:50:15 | pamaury | copper: indeed, thanks |
14:50:20 | chrisjj | The wiki and manual versions now do not accord, descriptively. Whether they accord normatively, I cannot say. |
14:51:39 | *** | Saving seen data "./dancer.seen" |
14:51:59 | copper | there was a debate on whether documentation about theme markup should be removed entirely from the wiki, thus disabling users from contributing to it |
14:52:19 | chrisjj | Where, please? |
14:53:01 | copper | in here |
14:53:23 | copper | also, I see that the manual doesn't say anything about the %if bug ;-( |
14:54:22 | copper | even though I reported it and asked for a mention of it in the manual |
14:55:21 | pixelma | IMO we shouldn't document bugs in the manual, no-one will remember to remove the note once the bug is fixed |
14:56:07 | copper | better not fix it and let theme makers struggle with it on their own :-/ |
14:56:18 | pixelma | no, better fix it |
14:56:37 | copper | I reported it 5 months ago like the rest |
14:57:26 | copper | FS #12891 |
14:57:27 | fs-bluebot | http://www.rockbox.org/tracker/task/12891 %?if() evaluates enumeration indexes and arbitrary numbers to (number + 1) (bugs, unconfirmed) |
14:57:33 | pixelma | for what it's worth, I can at least confirm this one - although I don |
14:57:38 | copper | not even one comment |
14:57:52 | copper | also "unconfirmed" |
14:57:53 | pixelma | 't think a developer usually looks at that field |
14:57:55 | chrisjj | copper: Thanks - debate found at https://www.google.co.uk/search?q="WHY+would+it+be+an+issue+if+I+nuke+CustomWPS" |
14:58:14 | | Join amayer [0] (~amayer@mail.weberadvertising.com) |
15:00 |
15:01:16 | chrisjj | pixelma "we shouldn't document bugs in the manual" The things is that the spec needs supposed to describe behaviour, and avoiding documenting code flaws is allowing bugs in the docs. |
15:01:59 | chrisjj | I agree "better fix it", but meanwhile better document it! |
15:09:08 | chrisjj | copper: glad to see objection to the "fucking push to nuke CustomWPS in favor of the manual". However, that does leave open the question of how to solve what's described as the current clusterfuck. |
15:12:34 | copper | people need to care |
15:12:37 | copper | they currently don't |
15:13:22 | | Part LinusN |
15:18:22 | copper | chrisjj: eh, apparently I came across the manual problem and the %if problem around the same time |
15:18:42 | copper | well, I came across a whole bunch of problem while I was making my Googley themes |
15:18:56 | copper | took me like 2 weeks of full time work |
15:19:08 | copper | just to get around bugs |
15:21:52 | copper | uh |
15:22:00 | copper | where did the FM Radio go |
15:22:17 | | Quit dfkt (Remote host closed the connection) |
15:22:25 | | Join dfkt [0] (OxO29A@unaffiliated/dfkt) |
15:22:45 | copper | oh for crying out loud, not again |
15:24:11 | copper | pamaury: can't find the FM radio on the Fuze+ again, on either a15a15b or fde92de |
15:26:19 | pamaury | up to my knowledge, no one has touch the radio code for ages |
15:26:25 | pamaury | *touched |
15:26:47 | copper | you fixed it the last time |
15:27:03 | copper | something about waiting for the radio chip to wake up or whatever |
15:27:06 | pamaury | that was in early days of the port |
15:27:25 | pamaury | and with HEAD ? |
15:28:17 | copper | fde92de is HEAD |
15:28:38 | chrisjj | copper: Some people don't care, Some do. :) |
15:28:39 | copper | it doesn't even show in the sim |
15:29:32 | chrisjj | MAINTANERS was a good move to declare who cares about what. |
15:29:36 | pamaury | does the sim have radio ? |
15:29:51 | copper | pamaury: yes, that's how I was able to take screenshots of it |
15:30:01 | copper | how else would you develop an FMS |
15:30:21 | pamaury | no idea, I stay as far as I can from the apps/ code |
15:30:51 | pamaury | can you bisect to find when it broke in the sim ? |
15:31:11 | pamaury | I am sorry, I really have 0 free time until this week-end, too much work |
15:31:30 | copper | first things first |
15:31:57 | copper | kugel: should I file a bug report for the theme issue, and will someone actually look into it? |
15:32:16 | kugel | yes please |
15:32:46 | | Quit Zagor (Quit: Clint excited) |
15:33:07 | kugel | I can't make a promise about the latter (though I plan to look into it) but knowing about the bugs is a prerequisite for fixing |
15:33:18 | chrisjj | copper: Re http://www.rockbox.org/tracker/task/12891 , I wonder if this issue really is confined to if(). |
15:33:35 | pamaury | the last radio change was 446f352 (19 nov), but it was not supposed to changed anything, just refactor |
15:35:28 | copper | you know what |
15:35:52 | | Join Zagor [242] (~bjst@rockbox/developer/Zagor) |
15:36:27 | copper | I'm just going to stop bothering until the most straightforward bugs are fixed and my old bug reports get any kind of acknowledgment or feedback |
15:36:53 | copper | because until then, it just seems like a waste of time |
15:38:35 | copper | "confirming" the bugs would be a start |
15:38:51 | copper | why should I bother if my bug reports never even get confirmed |
15:39:26 | copper | a simple comment would do |
15:39:41 | copper | "we are aware of this bug, but fixing it won't be easy" |
15:39:51 | copper | or whatever |
15:39:52 | copper | anything |
15:39:55 | kugel | copper: see, we're only 3-4 active devs in this project |
15:40:08 | kugel | and none of them is particularly interested in the skin engine |
15:40:26 | kugel | it's all volunteer effort, we can't force anyone to look into theme related issues |
15:40:37 | copper | understood |
15:40:42 | copper | I'm a volunteer too |
15:41:02 | | Join maruk1 [0] (~papier@titanium.v6.sdv.fr) |
15:41:16 | copper | except I'm not particularly welcome here |
15:41:33 | foolsh | copper: pamaury: I just built HEAD for fuze+ radio is there for me, building the sim now Iet you know in a minute |
15:42:13 | kugel | copper: no, you are welcome. your support for the project thorugh bug reports is important for us (even if it might not be that obvious to you) |
15:42:39 | copper | I'm not |
15:42:46 | copper | I've been told, explicitely |
15:43:38 | foolsh | copper: pamaury: Radio is present in the sim build from HEAD for me atleast. |
15:44:19 | chrisjj | copper: I think you don't need to take it personally. AFAICS you're no less welcome that anyone else who reports serious bugs. |
15:44:42 | pamaury | hum, on device it could depend on the harware or be timing related but in the sim it is deterministic, so hopefully the issue was just temporary, I'll check with HEAD on device later |
15:45:09 | copper | chrisjj: I've been insulted and warned, several times |
15:45:14 | copper | I can only take it personally |
15:45:29 | copper | I decided to stay here and help those who cared, but I'm getting tired |
15:45:47 | chrisjj | copper: I too have been insulted and warned. So you don't need to think it is only you. |
15:46:03 | copper | foolsh: I just built HEAD and there is no FM radio menu item |
15:46:44 | copper | https://outpost.fr/tmp/TPU.png |
15:46:56 | copper | I'm not dreaming |
15:47:15 | foolsh | That's so odd |
15:47:26 | copper | https://outpost.fr/tmp/mCd.png |
15:47:30 | copper | proof that it's HEAD |
15:47:45 | funman | i dont remember ever seeing FM in the sim |
15:47:54 | kugel | copper: when, by whom? |
15:48:02 | chrisjj | copper: I added my preferred solution to http://www.rockbox.org/tracker/task/12891 . Tried and tested by many developers over the decades :) |
15:48:43 | foolsh | funman: It's there for me I'm looking right at it on the sim, weird |
15:49:25 | copper | funman: it's been there for a long time |
15:49:30 | copper | in the iPod Video sim too |
15:49:56 | kugel | funman: the sim has a radiom obivously without signal |
15:50:05 | copper | updating the iPod Video sim now |
15:50:22 | pamaury | I have the radio in the fuze+ sim here (quite recent build, one week ago) |
15:50:42 | kugel | copper: I ask again, when, and by whom, have you been told that? |
15:50:49 | funman | i can't be trusted on that one ^_^ |
15:50:55 | copper | kugel: scorche |
15:51:17 | kugel | that surprises me |
15:51:24 | copper | the FM radio is still there on the iPod Video sim |
15:51:55 | copper | ok it's a config file issue |
15:52:17 | copper | ah ffs |
15:52:56 | copper | my Fuze+ config had a "root menu order:" entry from an iPod Classic, which doesn't include the FM radio |
15:53:16 | copper | my bad |
15:53:30 | | Join Rower [0] (~husvagn@90-230-142-55-no41.tbcn.telia.com) |
15:54:39 | copper | that's nasty |
15:55:03 | pixelma | proof of why configurable menus can be bad!? ;) |
15:55:33 | chrisjj | Easy mistake ... given the option is named "root menu order" rather than "root menu". |
15:56:18 | chrisjj | More like Proof of why something called "order" should affect only the order. |
16:00 |
16:01:18 | | Quit Rower (Quit: Hmmm...) |
16:05:08 | | Join Rower [0] (~husvagn@90-230-142-55-no41.tbcn.telia.com) |
16:09:18 | chrisjj | kugel: OOI, who are the "only 3-4 active devs in this project" apart from yourself and pamaury? |
16:09:19 | | Quit Rower (Client Quit) |
16:13:46 | | Quit mortalis (Ping timeout: 272 seconds) |
16:14:46 | | Quit cmhobbs (Ping timeout: 260 seconds) |
16:15:32 | | Join wodz [0] (~wodz@87-207-223-0.dynamic.chello.pl) |
16:16:46 | wodz | chrisjj: It easy enough to check yourself - main page - code changes frame - All commits since last four weeks (or last release) |
16:18:13 | chrisjj | I've seen that thanks. |
16:21:48 | | Join Rower [0] (~husvagn@90-230-142-55-no41.tbcn.telia.com) |
16:23:27 | | Part foolsh |
16:25:07 | chrisjj | (qty: 14) |
16:31:12 | | Join foolsh [0] (~foolsh@c-24-14-134-34.hsd1.in.comcast.net) |
16:37:34 | | Join lebellium [0] (~chatzilla@80.215.8.86) |
16:38:14 | | Quit pretty_function (Remote host closed the connection) |
16:38:56 | copper | kugel: FS #12884 is one of the bugs that made me put everything on a single line |
16:38:58 | fs-bluebot | http://www.rockbox.org/tracker/task/12884 Blinking metadata text on the iPod Video / Classic (bugs, unconfirmed) |
16:39:30 | copper | "If the colors match those defined in the cfg file, or the user set ones, the bug doesn't occur (no blinking)." |
16:39:48 | copper | that kind of bug is so pervasive and so weird that it makes little sense reporting them all |
16:40:17 | copper | the sum of it just means that the whole thing is fucked up and needs a large overhaul, which isn't going to happen |
16:41:02 | copper | because few people are competent or motivated or available to fix it, and even those have no idea on how to fix it |
16:41:52 | copper | so, in my opinion, it's a waste of time to ask users to file further bug reports for a core problem that's been there for a _long_ time and for which there is no hope |
16:41:59 | toehser1 | Here's something interesting - when I load the problem theme in the simulator - areas of the image of the player (outside the screen) are overwritten with black. |
16:42:16 | copper | toehser1: yup I see that too with HEAD |
16:42:40 | toehser1 | Ah - yes I saw it with cabbiev2 also... can't be a good thing, but maybe unrelated. |
16:43:05 | copper | like I said, cabbie is no reference of a "good" theme |
16:43:19 | copper | it's just what everyone uses and never gets updated |
16:43:35 | chrisjj | Which theme is a reference? |
16:43:38 | copper | none |
16:44:03 | chrisjj | E.g. which one might use for spec validation? |
16:44:06 | copper | none! |
16:44:33 | chrisjj | Surely someone must have created theme(s) that cover the spec features. |
16:44:37 | copper | you can't validate a spec with a faulty implementation that produces a ton of really weird bugs |
16:45:01 | chrisjj | You can't claim they are bugs until the spec is validated :) |
16:45:06 | kugel | there is no spec |
16:45:14 | | Quit chrisjj (Quit: Page closed) |
16:45:24 | kugel | well, not one that I would personally consider a proper spec |
16:46:16 | | Join chrisjj [0] (561bb732@gateway/web/freenode/ip.86.27.183.50) |
16:46:29 | chrisjj | kugel: There is "Custom WPS Display - File Format Specifications" |
16:46:43 | copper | chrisjj: that's the wiki, which is not officially sanctionned |
16:46:46 | kugel | hence my correction |
16:46:56 | copper | there's the manual, but that is still incomplete |
16:47:06 | chrisjj | "not officially sanctionned" Um, is anything? |
16:47:17 | copper | the manual is |
16:47:27 | chrisjj | Really? |
16:47:28 | copper | cabbiev2 is |
16:48:29 | chrisjj | I think if there was an official sanction for the manual, it wouldn't be allowed out with false info and "tbd". |
16:51:12 | chrisjj | If there is no proper spec, it would be at least useful to get a consensus on which is the improper spec. Perhaps that can be ur, properised. |
16:51:29 | copper | uh? |
16:51:35 | | Join ikeboy [0] (~ikeboy@ool-435622d3.dyn.optonline.net) |
16:51:40 | copper | if there is no proper spec, all specs are improper |
16:51:44 | *** | Saving seen data "./dancer.seen" |
16:52:09 | chrisjj | OK, which spec is least improper? |
16:52:45 | copper | IMO? The Wiki, because I was able to document the bugs that I encountered. |
16:52:49 | | Quit Rower (Quit: Hmmm...) |
16:53:09 | copper | I also added a clarification or two |
16:53:11 | chrisjj | (Shame the two main specs are in formats that cannot be easily diffed.) |
16:53:25 | copper | but it doesn't matter |
16:53:33 | copper | there are too many bugs |
16:53:47 | copper | you can write perfect markup, you'll still run into problems at some point |
16:53:59 | chrisjj | It matters to me. And I think it matters to anyone else seeking to employ .WPS power. |
16:54:02 | copper | problems with some builds and not others |
16:54:55 | chrisjj | Perfect markup is a good place to start. |
16:55:32 | chrisjj | ... even if it can be perfect only on the current release. |
16:56:16 | copper | perfect markup would be useful if it was considered as such by Rockbox developers |
16:56:20 | chrisjj | It may be necessary to write off past builds for the sake of future. |
16:56:22 | copper | but they won't consider third party themes |
16:56:28 | copper | the answer is always "use cabbiev2" |
16:56:44 | | Join Rower [0] (~husvagn@90-230-142-55-no41.tbcn.telia.com) |
16:56:58 | chrisjj | I don't see that. The existence of themesite shows otherwise. |
16:57:00 | copper | which makes sense because they can't check every single theme |
16:57:22 | chrisjj | That does not make sense. |
16:57:34 | chrisjj | QA need not test every theme. |
16:57:40 | copper | but it leads to "cabbiev2 works for me" and thus theme bugs are largely ignored |
16:57:48 | chrisjj | It needs test only a validation set. |
16:58:02 | copper | a validation set that does not exist |
16:58:17 | chrisjj | "cabbiev2 works for me" is what should be ignored. |
16:58:30 | chrisjj | A validation set that could exist. |
16:58:43 | copper | you're welcome to write one |
16:58:58 | copper | hmm |
16:59:02 | copper | I shouldn't have said that |
16:59:06 | chrisjj | It needs to be part of collaborative effort. |
16:59:13 | copper | I don't know if it would actually be welcome |
16:59:22 | kugel | ideal would be a set of simple themes that can be checked in an automated way |
16:59:35 | kugel | by comparing screenshots or whatever |
16:59:43 | chrisjj | Collaborative esp. since it would indeed not be welcomed by some. |
17:00 |
17:00:02 | chrisjj | Absolutely. This is the way it is done elsewhere. |
17:00:27 | copper | theming is dead until the theme engine gets fixed (which it won't be) |
17:00:45 | | Quit krabador (Quit: Leaving) |
17:00:46 | chrisjj | Even semi-automatic compare with e.g. Beyond Compare would be good enough. |
17:01:31 | copper | HEAD suddenly breaking my themes is the manifestation of that |
17:01:36 | chrisjj | Theming has become no less a benefit of Rockbox since it first appeared, so I don't think one can say it will not get fixed. |
17:02:06 | chrisjj | That's not a manifestation of "won't be". Just of "is not yet". |
17:02:21 | copper | and my workarounds fixing older builds is the same manifestation of it |
17:02:39 | copper | basically there is no reliable way of making a proper theme |
17:02:48 | chrisjj | Currently, perhaps. |
17:03:05 | chrisjj | I am sure a reliable theme engine could be provided. |
17:03:21 | copper | apparently not |
17:03:33 | copper | it's apparently very difficult |
17:03:38 | | Quit fragilematter (Quit: Leaving.) |
17:03:58 | chrisjj | It is only very difficult if attempted without plan, spec or validation. |
17:04:18 | copper | I'm certainly not qualified to do anything about it |
17:04:19 | pamaury | the theme engine will eventually get fixed, no need to be so dramatic |
17:04:45 | chrisjj | .. and when hobbled by requirement of back-compatibility. |
17:05:23 | pamaury | memory corruption and the theme engine should be my next projects when I am done with the current targets, we have pretty obvious problems in those areas |
17:05:33 | chrisjj | Great news. |
17:05:47 | copper | coming from you, that's actually comforting |
17:05:53 | chrisjj | But I'd vote for memory corruption first :) |
17:06:11 | pamaury | but other devs are in the same situation: not much free time |
17:06:28 | copper | and no new blood, either |
17:06:47 | chrisjj | pamaury: do you have experience of grammar-driven machine-generated parsers? |
17:07:15 | pamaury | a bit |
17:07:18 | toehser1 | I attached a crash inducing file to the flyspray bug. |
17:07:56 | pamaury | chrisjj: what for ? |
17:08:07 | gevaerts | toehser1: so with that file, the tomsway2 theme, and the clip zip sim, you get crashes, right? |
17:08:26 | chrisjj | Good to hear. I'd be happy to help on a new format that was rigorously defined and validatible... |
17:08:27 | toehser1 | yes |
17:08:34 | gevaerts | hmmm |
17:08:36 | chrisjj | .. and necessarily incompatible with the current. |
17:08:39 | toehser1 | from git head |
17:08:50 | toehser1 | on the sim |
17:09:03 | pamaury | we already have a wps checker I think |
17:09:07 | toehser1 | hang on a min, I'll try with 3.13 on the real clip zip with that file |
17:09:08 | chrisjj | pamaury: for theme script. |
17:09:45 | gevaerts | toehser1: I prefer sim crashes. No real device here :) |
17:10:15 | gevaerts | toehser1: any other special settings? I don't seem to have issues... |
17:10:45 | | Quit Zagor (Quit: Clint excited) |
17:11:42 | pamaury | I'm not sure changing the theme engine format is the right way to go, fixing the engine is |
17:11:43 | toehser1 | No - I'm just launching the sim built from git head, selecting tomsway2 theme, and then playing that file, and it crashes. |
17:12:34 | gevaerts | Do you have other files on the device? |
17:12:51 | gevaerts | I only have the one, so I get the "no next file" case. Maybe that's involved? |
17:13:35 | toehser1 | This is a clean sim build / install + unzip the theme + copy just that file and play only that file. |
17:13:50 | toehser1 | Huh, so there is some other variable about the builds. |
17:14:19 | gevaerts | What I did was make, make install, unzip -d simdisk tomsway2.zip, unzip -d simdisk testfile.zip, start the sim, select the theme, and play |
17:14:20 | toehser1 | That file alone has _not_ yet crashed 3.13 on the real device or done the font weirdness. |
17:14:34 | toehser1 | that's what I did, I think, too... |
17:14:38 | gevaerts | weird |
17:14:46 | | Quit kugel (Ping timeout: 252 seconds) |
17:14:49 | toehser1 | and I get a core dump right away. |
17:15:28 | toehser1 | With the message "*** stack smashing detected ***: ./rockboxui terminated |
17:15:35 | gevaerts | Hmmm |
17:15:59 | gevaerts | OK, so probably different compiler settings? Let me try valgrind... |
17:16:21 | toehser1 | But in the real player with 3.13, I have that file playing now for a WHILE without problem... |
17:17:17 | toehser1 | It isn't impossible that I'm running into 2 issues, the original one that takes a while to fail, in 3.13, where the font changes magically to sysfont and then it crashes on power off, theme change, font change, or wps change; and the issues I'm seeing in git head I'm building myself. |
17:19:11 | chrisjj | pamaury: "we already have a wps checker I think" checkwps? AFAICS that simply calls the RB parser, bugs and all. |
17:20:01 | | Quit wodz (Ping timeout: 264 seconds) |
17:20:43 | chrisjj | Pamaruy: "I'm not sure changing the theme engine format is the right way to go, fixing the engine is" Well, I don't see how you can fix the engine without some format changes. E.g. consider copper's if() bug. |
17:21:15 | copper | those are two different problems |
17:21:37 | chrisjj | I see only one different problem :) |
17:21:38 | copper | the %?if bug is isolated |
17:21:45 | chrisjj | isolated to what? |
17:21:48 | gevaerts | toehser1: ok, with -fstack-protector, I can reproduce the crash |
17:21:57 | copper | chrisjj: it's not some "weird" glitch |
17:22:05 | copper | it's consistent |
17:22:16 | toehser1 | what is "-fstack-protector"? |
17:22:29 | toehser1 | a compile flag, or a sim runtime flag? |
17:22:39 | toehser1 | Is that looking for stack operations that shouldn't be happening? |
17:22:57 | gevaerts | A compile flag, which your gcc seems to have enabled by default |
17:23:00 | chrisjj | I agree it is different in the sense that it can be managed i.e. "fixed" in the documentation. |
17:23:30 | Mode | "#rockbox -o gevaerts" by ChanServ (ChanServ@services.) |
17:23:34 | toehser1 | Ah. I'm in an Ubuntu Raring environment I think, AMD64. |
17:23:55 | toehser1 | Maybe the gcc authors changed the defaults. |
17:24:10 | chrisjj | Perhaps your saying a first priority should be fixing only weird glitches? |
17:24:56 | pamaury | chrisjj: I know nothing about the theme engine but what from what I understand, the major issue is memory corruption which causes the theme engine to break everything else. That's unrelated to the langage itself |
17:25:35 | pamaury | The second problem is the specification: the theme doesn't behave as expected or as it should be, that's a bug and not a problem with the langage. |
17:25:36 | toehser1 | If I understand it, it is catching some mis begotten stray write to the wrong place, probably the same one that fails with the bizarre sysfont then crash in 3.13, but catching it earlier. |
17:26:34 | gevaerts | yes |
17:29:03 | chrisjj | pamaury: Thanks for the clarification. If the corruption can be fixed without sufficient engine work to justify a new parser and hence possible language change, that would be great. |
17:29:40 | pamaury | I can't know for sure, but except if people think the langage is really bad, that's not a problem with the langage |
17:29:57 | chrisjj | "the theme doesn't behave as expected" is not very useful since unfortunately expectations vary. |
17:30:32 | pamaury | that's why people write specification |
17:30:55 | pamaury | expectations have to be reasonable too |
17:31:26 | chrisjj | Then if you are happy to accept the existing specification, you can say the problem is when "engine does not perform to spec.". |
17:32:15 | chrisjj | I think this returns to the problem that there are two specs for one engine. |
17:32:53 | chrisjj | Apropos that, I have added a warning at I have added a warning at http://www.rockbox.org/wiki/bin/compare/Main/CustomWPS?rev1=242;rev2=243 . I guess some people here won't like that - of course they are free to revert it. |
17:33:04 | pamaury | tell me if I'm wrong but part of the problem is that the engine behaves different from both spec |
17:34:19 | chrisjj | No surprise. Perhaps different engine devs have followed different specs :) |
17:34:46 | pamaury | there was only one engine dev at this point, mostly |
17:35:07 | toehser1 | I thought the custom wps thing was the final arbiter and canonical doc - at least, it was able to be used ... the manual didn't seem to actually cover the behavior up to date? |
17:35:16 | pamaury | JdGordon did most of its written and maybe kugel did some bugfix, correctly me if I'm wrong |
17:35:20 | chrisjj | That's good. Perhaps he'll help in the extraction of the thrid spec in his head :) |
17:35:20 | pamaury | *writing |
17:35:22 | gevaerts | toehser1: ok, I see where it crashes |
17:36:07 | toehser1 | You're too fast. Did you analyze the core dump to get it? |
17:36:17 | gevaerts | Yes |
17:36:34 | gevaerts | Well, and I rebuilt it with -O0 to get better source/binary matching :) |
17:37:05 | | Join y4n [0] (~y4n@unaffiliated/y4ndexx) |
17:37:46 | gevaerts | the problem is that in apps/gui/line.c print_line() doesn't do proper string length checks |
17:38:42 | gevaerts | You're giving it "1999 MP3 165 (avg) 44100 /(08) Ceremonie Mandingue - Balan - Musiques Paysannes D'Haiti - Peasant music from Haiti - Ceremonie Mandingue - Balan.mp3", which is 148 bytes long, and it uses a 128 byte buffer |
17:38:50 | chrisjj | I recall JdGordon saying he hates documentation, so I wonder what can be done to get his help? :) |
17:39:39 | chrisjj | "I thought the custom wps thing was the final arbiter and canonical doc". Based on what, may I ask? |
17:40:07 | toehser1 | And beyond that buffer is, "something, anything, but no good can come of this...". |
17:40:15 | gevaerts | Yes |
17:40:17 | toehser1 | 128 seems awfully small, also. |
17:40:26 | gevaerts | Yes and no |
17:40:39 | gevaerts | It's quite large on the stack sizes we use :) |
17:41:26 | gevaerts | 128 is smallish for a string limit, yes, but in theory at least that buffer doesn't have to be as big as the strings you want to use |
17:41:40 | toehser1 | What line/function in line.c? |
17:42:06 | gevaerts | print_line(), line 150+ |
17:42:15 | toehser1 | So the code should be looping through if the buffer is too small, it can be made to handle the 148 byte string, without a larger buffer? |
17:42:52 | gevaerts | Maybe. I haven't really understood the code yet |
17:43:38 | chrisjj | Got to go now. |
17:43:51 | toehser1 | I see things like tempbuf[tempbuf_idx++] = ch without any check, that looks dangerous right there. |
17:44:06 | * | gevaerts nods |
17:46:18 | | Join n1s [0] (~n1s@nl118-168-30.student.uu.se) |
17:46:24 | toehser1 | Funny how my mind works, I suspected all manner of "fancy" things, like Anti-Aliased fonts, UTF-8, progress-bar-draw-rectangle-tick-marks - I didn't expect just "the file name is long and the buffer is short". Mental prejudice to look for "odd" bug causes. I need to drum into myself "don't assume the problem is crazy subtle". |
17:46:26 | | Quit n1s (Changing host) |
17:46:26 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
17:49:13 | | Quit petur (Ping timeout: 272 seconds) |
17:50:05 | gevaerts | OK, it won't be easy to fix nicely, due to the scrolling being handled further on, so if you e.g. cut it into chunks of 32 characters, you'll get individual 32 character scrolling areas |
17:56:53 | toehser1 | I would say take the easy ways out, double the buffer to 256 and truncate anything longer and document that in both the manual and the custom wps spec... |
17:57:42 | toehser1 | Makes sense that when it was seen before, it was anecdotally thought to involve scrolling, since long things are the ones that will scroll. |
17:59:20 | gevaerts | The 3.13 issue is bound to be different though, this is fairly new code |
17:59:50 | gevaerts | Could still be length-related of course |
18:00 |
18:01:26 | gevaerts | Hmmm, there might be a better solution. That function is designed to handle various formatting things, which I suspect are used in lists, but probably not in your case |
18:01:35 | | Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
18:01:47 | | Quit ikeboy (Quit: ikeboy) |
18:02:28 | gevaerts | If so, we could truncate if there are no more formatting things, but if the substring we're working with is the last one in the text, we could just pass it on to the drawing functions without actually needing to copy it |
18:02:44 | gevaerts | That might mean a second pass over the string which might slow things down though |
18:03:16 | * | gevaerts will wait for kugel's comments first |
18:12:45 | | Join wodz [0] (~wodz@87-207-223-0.dynamic.chello.pl) |
18:15:53 | | Quit wodz (Client Quit) |
18:19:46 | | Join pretty_function [0] (~sigBART@123.252.215.196) |
18:24:43 | | Join liar [0] (~liar@188-22-201-171.adsl.highway.telekom.at) |
18:28:42 | | Quit krnlyng (Ping timeout: 260 seconds) |
18:30:57 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
18:31:57 | | Quit maruk1 (Quit: Leaving.) |
18:35:05 | toehser1 | Ok... so... curious about my issue in 3.13... I downloaded the 3.13 source and built a sim from it... |
18:36:16 | toehser1 | I get a DIFFERENT *very weird* error... I created a playlist of 668 songs, and playing it, and only hitting "right"... _suddenly_ I was in a playlist with only 1 song! It auto-magically switched from something like 50/668 to 1/1. |
18:37:12 | toehser1 | No crash or stack error yet from 3.13 source, also no lost-font in the sim I built from 3.13 source. |
18:46:52 | | Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) |
18:51:18 | toehser1 | The 3.13 I built myself from source does fail with the weird sysfont bug - at least, I'm getting a consistent failure between my own build and the official build... :) |
18:51:46 | *** | Saving seen data "./dancer.seen" |
18:52:30 | toehser1 | That's on the real hardware, not the sim. |
18:58:37 | | Quit shai (Quit: Leaving) |
19:00 |
19:15:48 | | Join lorenzo92 [0] (~chatzilla@host22-109-dynamic.40-79-r.retail.telecomitalia.it) |
19:16:10 | | Quit pamaury (Ping timeout: 272 seconds) |
19:16:29 | toehser1 | In the sim, with 3.13, from source, I get "SDL_WaitEvent() error" but I'm suspecting that is because something crashed and then something tried to talk to it, secondary or tertiary. |
19:39:47 | | Join einhirn [0] (~Miranda@p4FC76B08.dip0.t-ipconnect.de) |
19:48:11 | | Quit zoktar (Quit: -) |
19:55:55 | | Join rela [0] (~x@pdpc/supporter/active/rela) |
20:00 |
20:03:43 | AlexP | chrisjj: Could you change the warning you added to the CustomWPS page into English please? |
20:03:49 | AlexP | Or remove it |
20:03:51 | AlexP | Either or |
20:04:32 | Mode | "#rockbox -o AlexP" by ChanServ (ChanServ@services.) |
20:04:55 | toehser1 | 3.13 in sim is getting sig 11 in buflib_get_data buflib.h 219 |
20:05:31 | | Quit Scromple (Ping timeout: 262 seconds) |
20:05:36 | AlexP | Sod it, I'll do it |
20:06:08 | toehser1 | return (void*)(context->handle_table[-handle].alloc) |
20:06:29 | toehser1 | when it crashes |
20:11:40 | toehser1 | called from core_get_data in core_alloc.c 39 |
20:11:53 | toehser1 | from lock_font_handle in font.c 129 |
20:12:03 | toehser1 | from font_lock in font.c 141 |
20:12:34 | toehser1 | from lcd_putsxyofs in lcd-bitmap-common.c 281 |
20:12:57 | gevaerts | OK, so buflib metadata corruption |
20:15:24 | toehser1 | Not an inference I'm able to make yet, I'm just in the first hour or so of either rockbox source _or_ gdb... |
20:16:19 | gevaerts | Well, if core_get_data() crashes, the data it's working with has to be bad |
20:17:09 | toehser1 | Meaning, whatever broke the structure in memory, is maybe completely unrelated to the code that crashed? |
20:17:13 | gevaerts | Yes |
20:17:20 | toehser1 | Yippee. |
20:17:23 | gevaerts | The best bugs :) |
20:18:14 | toehser1 | It happened on a long file name again, so I can start by looking at 3.13 buffers. |
20:18:35 | toehser1 | Or, I can fix git head to a longer buffer, and see if git head still gets THIS bug, too... |
20:18:48 | gevaerts | Or both :) |
20:19:11 | toehser1 | Where are our continuous integration test cases and server, so I can add a long file name case to the automatic regressions? |
20:19:44 | | Join meehoo [0] (5e4865e2@gateway/web/freenode/ip.94.72.101.226) |
20:19:49 | gevaerts | They were last seen running away at high speed |
20:23:17 | gevaerts | Hmmm |
20:23:29 | gevaerts | Is wodz' buflib checksum code available somewhere/ |
20:23:30 | gevaerts | ? |
20:24:37 | | Quit meehoo (Client Quit) |
20:29:03 | | Quit babylonlurker (Quit: No Ping reply in 180 seconds.) |
20:29:09 | | Join babylonlurker [0] (~quassel@veda.xs4all.nl) |
20:37:13 | | Quit rela (Read error: Connection reset by peer) |
20:51:47 | *** | Saving seen data "./dancer.seen" |
20:54:06 | | Quit pretty_function (Remote host closed the connection) |
20:56:01 | | Join zoktar [0] (~zoktar@unaffiliated/zoktar) |
20:58:40 | | Join ikeboy [0] (~ikeboy@ool-435622d3.dyn.optonline.net) |
21:00 |
21:03:10 | | Nick pookie is now known as olspookishmagus (~pookie@snf-137798.vm.okeanos.grnet.gr) |
21:13:54 | | Quit y4n (Quit: 6,000,000 ways to die — choose one.) |
21:14:28 | gevaerts | toehser1: how long do you typically have to wait for things to crash in the 3.13 sim? |
21:27:37 | | Join wodz [0] (~wodz@87-207-223-0.dynamic.chello.pl) |
21:28:30 | wodz | gevaerts: buflib checksum code is in rather hacky form in my local tree. I might try to clean it up a bit and push to gerrit right now as I have a few spare minutes |
21:29:34 | gevaerts | That could be useful to find toehser1's issue :) |
21:30:04 | toehser1 | Pretty quick. Let me check. |
21:30:53 | toehser1 | play song, hit right (next song) 3 -4 times, bam |
21:31:11 | toehser1 | (between 3:30:06 and 3:30:55...) |
21:31:19 | toehser1 | That is how long I have to wait... |
21:35:32 | toehser1 | If I just let it play, it might be 20 minutes, I think it is associated with what happens when it changes songs. |
21:35:52 | gevaerts | Maybe the font cache? |
21:36:16 | gevaerts | (as in, different characters are needed) |
21:36:17 | gevaerts | Hmm |
21:36:34 | toehser1 | Let me try with a different font- this is with an AA font... |
21:36:44 | * | gevaerts doesn't have a clue, really |
21:37:01 | toehser1 | crashes with 08-Rockfont, too. |
21:37:40 | toehser1 | same backtrace - always core_gest_data from lock_font_handle from font_lock from lcd_putsxyofs |
21:38:22 | gevaerts | I don't seem to be able to reproduce it, so I suspect either filenames or metadata are again involved |
21:38:55 | toehser1 | short file names seems to not fail |
21:39:17 | * | gevaerts renames files |
21:39:47 | toehser1 | I can try to make a set of not-huge files with very-weird names and see if I can get a case that fails it. |
21:40:12 | toehser1 | I am built with -O0 and -fstack-whatever right now. |
21:41:03 | gevaerts | oh, fun. These filenames are *too* long :) |
21:41:09 | gevaerts | (instant segfault) |
21:41:54 | gevaerts | Ah, good. in the right place :) |
21:42:16 | gevaerts | So yes, just long filenames |
21:42:44 | toehser1 | Wait - not sure I really have the same backtrace always - it wasn't creating new core files to overwrite my old one. |
21:42:57 | toehser1 | You've reproduced now, just by using long file names? |
21:43:20 | toehser1 | Fantastic - my long file names have exposed *2 completely different bugs*! |
21:43:29 | toehser1 | I'll try for 3 now, I guess? |
21:44:35 | toehser1 | Now I'm sure, I always get the same backtrace - doesn't that imply the corruption is fairly locally not too long before the effect hits? |
21:45:24 | toehser1 | Should I create a different flyspray for the 3.13 one, or just use the one we have for all "long file names break things"? |
21:49:01 | wodz | gevaerts: g#711 |
21:49:03 | fs-bluebot | Gerrit review #711 at http://gerrit.rockbox.org/r/711 : by Marcin Bukat (changes/11/711/1) |
21:49:18 | | Quit lorenzo92 (Quit: ChatZilla 0.9.90.1 [Firefox 26.0/20131206145143]) |
21:55:33 | gevaerts | buflib_allocations[] in font.c is clearly overwritten |
21:56:10 | gevaerts | So not the buflib metadata itself, just the handles. If you're going to ask buflib for handle 6815841, things will not work well :) |
22:00 |
22:07:26 | | Join sakax [0] (~sakax@d8D862C77.access.telenet.be) |
22:07:26 | | Quit sakax (Changing host) |
22:07:26 | | Join sakax [0] (~sakax@unaffiliated/sakax) |
22:07:49 | gevaerts | toehser1: this one seems to be bidi.c, in bidi_l2v() |
22:07:52 | | Join kugel [0] (~kugel@91-64-116-250-dynip.superkabel.de) |
22:07:52 | | Quit kugel (Changing host) |
22:07:52 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
22:08:21 | | Quit sakax (Client Quit) |
22:08:44 | | Join sakax [0] (~sakax@d8D862C77.access.telenet.be) |
22:08:45 | | Quit sakax (Changing host) |
22:08:45 | | Join sakax [0] (~sakax@unaffiliated/sakax) |
22:09:33 | kugel | gevaerts: nice find. I produced some buggy code there : |
22:09:34 | kugel | :( |
22:11:05 | kugel | gevaerts: the problem is scrolling |
22:11:30 | kugel | you need to print the string (including NUL) as a whole at once to have it scroll properly |
22:11:36 | gevaerts | Yes, I know |
22:12:51 | toehser1 | How did you find it? |
22:13:09 | kugel | the temp buffer is just for the NUL byte actually |
22:13:29 | gevaerts | Hmmm |
22:14:16 | gevaerts | kugel: could you (horrible, I know!) put a NUL in the string, remember what was there, and put it back after passing the line to the lcd code? |
22:14:38 | * | [Saint] directs a statement to no one in particular (but, you'll know who you are, I should imagine...): |
22:14:39 | [Saint] | "If you find documentation errors, and are impassioned enough to rant about it for over an hour, maybe you should consider submitting a patch instead of getting pissed off about nothing getting done about it" |
22:15:00 | kugel | gevaerts: yes, i guess |
22:15:06 | gevaerts | toehser1: I found that the values in buffer_allocations in font.c were wrong, so with gdb I set a watch on that :) |
22:15:08 | | Quit ikeboy (Ping timeout: 272 seconds) |
22:15:20 | gevaerts | Long filenames are really *bad*!! |
22:15:42 | gevaerts | Every time I increase a buffer, it crashes somewhere else |
22:16:22 | kugel | gevaerts: except it wouldnt work |
22:16:51 | kugel | inline strings are most probably literals |
22:17:00 | gevaerts | oh, right... |
22:17:34 | gevaerts | Well, you could probably make it even hackier by copying to tempbuf if the string is short |
22:17:44 | gevaerts | Which should catch all of the built-in ones |
22:17:49 | toehser1 | Spec says they can be up to 255 unicode chars long. |
22:18:15 | toehser1 | So just making the buffers from 128 to 256 should be more than sufficient... |
22:18:37 | toehser1 | Oh - it isn't long file names though - isn't it really "any long string in the viewport?" |
22:18:56 | kugel | gevaerts: and this is different from now in what way? |
22:19:10 | toehser1 | The one we looked at was a concatenation of the file name with other stuff... so it really needs to do something _sane_ when the input string is even longer... |
22:19:27 | gevaerts | kugel: then you'd handle the long strings in-place. I don't think that's a very nice solution though |
22:19:37 | gevaerts | At least we need to check the size |
22:19:50 | kugel | you mean assuming very long strings are not literals? |
22:20:14 | gevaerts | yes |
22:20:15 | toehser1 | I like "check the size and truncate to 256, document 256 as the limit, fix buffers that don't support 256". |
22:20:25 | kugel | gevaerts: haha, now this is really terrible :) |
22:20:51 | gevaerts | kugel: it *would* work :) |
22:22:36 | kugel | I suggest the following: a) bump tempbuf to MAX_PATH (+X) |
22:22:48 | toehser1 | bidi_l2v is confusing me. |
22:22:53 | kugel | b) never write past tempbuf |
22:23:57 | kugel | c) when the limit is hit (should be rare), see if this inline string is the last token (no more '$' in the remaing) |
22:24:32 | gevaerts | Yes, that seems sensible |
22:24:37 | kugel | if yes (the likely case), print the string as is (no length limitation); if no truncate and skip to the next token |
22:26:31 | kugel | most (if not all) inline strings are are either prefixes (likely short ones) or suffixes (might be long) |
22:27:18 | gevaerts | toehser1: you're not alone... |
22:27:19 | | Quit bluebrother (Disconnected by services) |
22:27:24 | | Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) |
22:28:33 | gevaerts | kugel: unless we go for horrible hacks, we need some sort of limit with possible truncation. I think what you described is the best way to achieve that |
22:28:54 | | Quit fs-bluebot (Ping timeout: 252 seconds) |
22:29:02 | kugel | toehser1: we generally truncate filenames (including path) at MAX_PATH (=260). this can be less than 256 chars for unicode |
22:29:47 | kugel | gevaerts: yes, it would truncate only in the least probable of the unlikely cases |
22:29:51 | toehser1 | Sounds fine to me. |
22:30:16 | | Join fs-bluebot [0] (~fs-bluebo@g225253160.adsl.alicedsl.de) |
22:30:44 | toehser1 | I'll take some characters truncated from a scrolling 250 character filename in a 96 pixel field over buffer corruption and segfaults by a large margin :) |
22:30:46 | gevaerts | kugel: I'd also make tempbuf static to avoid random stack issues |
22:31:17 | [Saint] | toehser1: Well...when you put it that way. ;) |
22:31:20 | kugel | and then we get other random issues? |
22:32:01 | gevaerts | Well, yes and no :) |
22:32:08 | toehser1 | There won't be any issues. You're going to catch all the cases. So it doesn't matter where it is. Right? |
22:32:13 | kugel | we are more likely to see stack overflows than static memory overflows |
22:32:23 | kugel | because we have a loosy check for that |
22:34:23 | kugel | making it static doesn't buy us anything, but comes at costs (non-reentrant, RAM usage). if the stack isn't large enough I would rather increases that instead of making X buffers static (which easily costs more RAM) |
22:35:17 | gevaerts | I don't feel very strongly about this, really |
22:35:37 | gevaerts | What I do feel strongly about is that gdb watch doesn't want to work any more here :( |
22:35:45 | kugel | toehser1: there is the possiblity that the stack memory is exhausted |
22:36:20 | kugel | unlike on a PC we actually have limits for that :) |
22:36:43 | kugel | gevaerts: what if you increase the main stack size? |
22:36:56 | kugel | most filename buffers are on stack iirc |
22:37:24 | gevaerts | kugel: I think I've done something wrong earlier. Still working on that bidi one |
22:37:42 | gevaerts | I can't confirm the other crash/issue I saw any more |
22:39:38 | kugel | ah man |
22:39:43 | kugel | my idea doesnt work |
22:39:54 | kugel | you need to copy for another reason |
22:40:20 | kugel | to escape '$' :/ |
22:40:31 | gevaerts | oh |
22:40:47 | gevaerts | Well, you could probably check if that's needed, but it's getting a bit involved then |
22:41:37 | kugel | alright, I guess we have to live with truncation then. at least there is a workaround: do not use inline text but pass the string via $t |
22:42:30 | kugel | (and mind you, inline text exceeding MAX_PATH shouldn't be a thing, because it looks really ugly in the code :p) |
22:43:01 | | Nick DormantBrain is now known as SuperBrainAK (~andy@2001:470:8:a61::5f92:59a1) |
22:45:13 | | Quit liar (Ping timeout: 264 seconds) |
22:48:17 | toehser1 | How would I judge if it is exhausting the stack memory? |
22:48:37 | gevaerts | You should get a panic for that |
22:48:52 | gevaerts | So if you don't know, it's not likely :) |
22:48:52 | toehser1 | Gevaerts: You mean, the one that hit after you increased buffers in bidi, isn't happening? |
22:49:07 | gevaerts | toehser1: yes, I think I did something wrong there |
22:49:20 | gevaerts | Right now I'm trying to figure out how to tell bidi to check sizes |
22:49:21 | toehser1 | I can live with only 2 bugs to fix rather than 3. |
22:50:25 | toehser1 | The line.c one was only on head, not 3.13 - but the bidi one I assume is still there on head, just never gets hit with the line.c one? |
22:50:55 | gevaerts | Correct |
22:51:01 | gevaerts | I checked. It's there |
22:51:49 | *** | Saving seen data "./dancer.seen" |
22:59:37 | fs-bluebot | Build Server message: New build round started. Revision 3be3a40, 249 builds, 35 clients. |
23:00 |
23:00:02 | | Join liar [0] (~liar@83.175.90.24) |
23:01:01 | kugel | gevaerts: hm, what call caused the tempbuf overflow? it should really happen only with inline strings |
23:02:32 | fs-bluebot | Build Server message: Build round completed after 176 seconds. |
23:02:39 | gevaerts | hmmm |
23:04:10 | gevaerts | bah, something is really wrong. I can't get anything useful out of gdb any more :( |
23:07:12 | wodz | pamaury: (log) app.lds for imx233 really misses the point of .init section. The whole hassle is to reclaim mem used by init functions called once at the very beginning and overlap .bss with this. Your linker script doesn't do that. |
23:11:01 | gevaerts | kugel: http://paste.debian.net/75317/ |
23:14:53 | | Quit sakax (Quit: Leaving) |
23:14:57 | | Join Scromple [0] (~Simon@161.43.73.67) |
23:17:44 | | Quit wodz (Quit: Leaving) |
23:18:07 | kugel | gevaerts: can you have a quick look at http://gerrit.rockbox.org/712? |
23:18:16 | | Join sakax [0] (~sakax@d8D862C77.access.telenet.be) |
23:18:17 | | Quit sakax (Changing host) |
23:18:17 | | Join sakax [0] (~sakax@unaffiliated/sakax) |
23:23:44 | gevaerts | kugel: looks ok to me |
23:24:10 | kugel | I'm also changing the skin engine to use the suggested workaround |
23:24:20 | kugel | it can pass up to 1024 byte strings |
23:26:13 | kugel | unfortunately you cannot easily see the string in the backtrace anymore but meh |
23:28:54 | fs-bluebot | Build Server message: New build round started. Revision 99f3f77, 249 builds, 35 clients. |
23:30:13 | | Quit n1s (Quit: Ex-Chat) |
23:32:14 | fs-bluebot | Build Server message: Build round completed after 199 seconds. |
23:32:31 | fs-bluebot | Build Server message: New build round started. Revision 837cad0, 249 builds, 35 clients. |
23:33:33 | gevaerts | toehser1: that should fix the bidi issue |
23:34:47 | kugel | hm, I can't get a file wiht long name to be shown in the browser |
23:35:14 | gevaerts | kugel: sim or target? |
23:35:29 | gevaerts | I can see my 200 character filenames fine on the sim |
23:35:36 | fs-bluebot | Build Server message: Build round completed after 186 seconds. |
23:35:44 | kugel | gevaerts: sim |
23:38:23 | kugel | it prints ".rockbox directory not found" at boot with this file in the root |
23:39:08 | gevaerts | How long is the filename? |
23:40:10 | kugel | 255 |
23:40:47 | gevaerts | The brilliant thing is that although it doesn't see .rockbox, it still loads the theme |
23:41:14 | kugel | works with 200 |
23:41:21 | kugel | yea, very weird |
23:42:36 | gevaerts | 252 works, 253 doesn't |
23:43:26 | gevaerts | I don't feel like figuring out why though |
23:49:46 | toehser1 | Fantastic. I haven't tried putting files in the root, I always have a subdirectory, but isn't the root "special" in FAT filesystems? |
23:50:09 | toehser1 | What about the line.c issue? Is that one still under analysis? |
23:50:43 | gevaerts | should be gone too |
23:51:04 | toehser1 | Is it ready to pull from git? |
23:51:13 | gevaerts | yes |
23:51:38 | toehser1 | k - I'll test it all out. Amazingly fast work there. |
23:52:04 | gevaerts | It's easy once you know what's wrong :) |
23:53:04 | | Nick GeekShad1w is now known as GeekShadow (~antoine@nzf.turmel.info) |
23:55:17 | | Quit Rower (Quit: Hmmm...) |