#rockbox 2014-01-09

Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

#rockbox log for 2014-01-09

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...)

Previous day | Next day