#rockbox 2011-02-19

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 2011-02-19

00:00:03	kkurbjun	yes, it definitely is on microblaze for sure.
00:00:06	Torne	the advantage of actual PIC code is you cna share pages of libraries between processes even if they're mapped at different addresses, and can mmap them directly from disk
00:00:18	Torne	neither of which are relevant for us
00:00:24	Torne	since we're single-process without mmap :)
00:00:41	Torne	relocatable code is the opposite of PIC code in most ways :)
00:01:36	Torne	since we need to load plugins in full from disk anyway, the effort to then relocate them once they're already fully in ram is comparitively tiny
00:01:51		Join hebz0rl [0] (~hebz0rl@dslb-188-105-228-206.pools.arcor-ip.net)
00:02:01	Torne	and then the resulting binaries will be exactly as efficient as if they were fully relocated by the linker, just slightly larger on disk for the relocation table (which can be discarded after load)
00:02:43		Quit hebz0rl (Read error: Connection reset by peer)
00:03:02	Torne	it would be kinda sucky if we had to build, say, mpegplayer as PIC and lose one or two registers there :)
00:15:02		Quit {-phoenix-} (Remote host closed the connection)
00:17:09	CIA-70	New commit by kugel (r29328): Fix yellows and checkwps.
00:22:15	CIA-70	r29328 build result: 905 errors, 124 warnings (kugel committed)
00:24:10	kugel	strange
00:25:16	kugel	firmware including apps header :\
00:26:03		Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com)
00:28:39	pamaury	where ?
00:29:15	CIA-70	New commit by kugel (r29329): Fix red caused by incorrect includes.
00:30:56		Join dfkt_ [0] (dfkt@unaffiliated/dfkt)
00:31:29		Join panni__ [0] (hannes@ip-178-203-73-7.unitymediagroup.de)
00:31:52		Quit casainho (.net .split)
00:31:52		Quit maxsin (.net .split)
00:31:53		Quit Jerom1 (.net .split)
00:31:53		Quit panni_ (.net .split)
00:31:53		Quit Kitar\|st (.net .split)
00:31:53		Quit dfkt (.net .split)
00:31:53		Quit mudd1 (.net .split)
00:31:53		Quit JdGordon\| (.net .split)
00:31:53		Quit Battousai (.net .split)
00:31:53		Quit TheSeven (.net .split)
00:32:07		Join Battousai [0] (~bryan@gentoo/developer/battousai)
00:32:13		Join mudd1 [0] (~cmertes@ip-78-94-203-49.unitymediagroup.de)
00:32:28	pamaury	kugel: native cooperative threading is really nice :)
00:32:32		Join casainho [0] (~chatzilla@2.81.146.26)
00:33:06		Join JdGordon\| [0] (~jonno@124-168-132-222.dyn.iinet.net.au)
00:33:07		Quit JdGordon\| (Changing host)
00:33:07		Join JdGordon\| [0] (~jonno@rockbox/developer/JdGordon)
00:33:19		Join maxsin [0] (~maxsin@188-115-150-221.broadband.tenet.odessa.ua)
00:33:25	CIA-70	r29329 build result: 656 errors, 0 warnings (kugel committed)
00:33:43		Join Jerom [0] (~jerome@79.132.59.245)
00:33:53	pamaury	getting better ;)
00:34:26	kugel	meh, I checked checkwps
00:34:38	Strife89	Probably not high score material this time
00:34:42	Strife89	You hope. ;)
00:34:54	kugel	ah, h300 checkwps is fine but others aren
00:34:56	kugel	't
00:35:00		Quit factor_ (Quit: Leaving)
00:35:17		Join factor [0] (~factor@75.108.68.114)
00:36:22	Strife89	Score is 25,725 right now. ;)
00:37:00		Quit casainho (Client Quit)
00:37:30		Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven)
00:38:14		Join Kitar\|st [0] (Kitarist@BSN-182-66-53.dial-up.dsl.siol.net)
00:38:18		Join vnl [0] (~slayer@cpc5-king10-2-0-cust73.perr.cable.virginmedia.com)
00:38:20	gevaerts	Strife89: scores don't add up
00:38:32	Strife89	Ah.
00:40:05	kugel	hmm, why does that error now? or rather how did it not error before?
00:41:26		Quit kevku (Quit: KVIrc 4.0.2 Insomnia http://www.kvirc.net/)
00:41:52		Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey)
00:43:15	kugel	at least I keep introducing new reds instead of overlooking :)
00:49:58	kugel	o noh, this was overlooking
00:50:21	*	TheSeven wants FS #11917 to be fixed, but can't make it work :/
00:52:20	TheSeven	Torne: regarding PIC vs. relocatable: you might want to have a look at how i implemented it in emCORE
00:52:42	TheSeven	i hacked up elf2flt quite a bit and wrote a loader for that
00:52:57	Torne	what did you need to hack it for?
00:53:00	kugel	this error is strange
00:53:05	user890104	TheSeven: i can provide more information on the issue i reported, if needed
00:53:35		Quit maxsin (Quit: Leaving.)
00:54:02	TheSeven	Torne: some different requirements I had, like UCL compression instead of gzip, .text/.data/.bss being contiguous, some more header fields/flags, ...
00:54:24	TheSeven	and most importantly a different kind of interaction with the linker, as the old one was cocking up with eabi objects
00:54:26		Join maxsin [0] (~maxsin@188-115-150-221.broadband.tenet.odessa.ua)
00:54:53	TheSeven	i let the linker do the linking now, and elf2emcoreapp just generates the relocation data and header
00:55:39	TheSeven	i didn't manage to make it relocate non-fully-linked eabi objects, and also unresolved relocations went unnoticed the way it was implemented... kinda strange
00:55:59	TheSeven	i now just pass −−emit-relocs to ld, and transform the relocation information into the FLT format
00:56:12	kugel	HAVE_CORELOCK_OBJECT is still defined but for some reason it's not seen in thread.h anymore
00:56:42	TheSeven	(and commented out half of elf2flt, as it doesn't need to handle all that complex symbol resolving stuff)
00:57:03	Torne	well, that sounds useful :)
00:58:00	TheSeven	also i reworked the build system, as it was a rather big mess to even compile that thing in its original state
00:58:23	TheSeven	makefile.in and configure.in had some nice bugs
00:58:30	kugel	ah, I see it now
00:58:49	thomasjfox	kugel: There's a #ifdef CPU_PP before it
00:59:05	TheSeven	what i still don't fully understand is what the matter with that bfd.h file is
00:59:10	kugel	the corelock definition is now within #ifdef ASSEMBLER_THREADS
00:59:28	TheSeven	do i really need to take that from the very same binutils build? and if so, why isn't it copied into some system include dir on installation?
00:59:48	TheSeven	it's kinda nasty that rockboxdev.sh throws it away after compiling, while elf2flt needs it
01:00
01:00:37	Torne	elf2flt is part fo the extended gcc suite, no?
01:00:46	Torne	so the "natural" way is to unpack it into the same place
01:00:50	Torne	and then everything is there :)
01:01:00	Torne	libbfd isn't really meant to be used outside gcc
01:01:01		Quit maxsin (Ping timeout: 240 seconds)
01:01:12	Torne	doing it that way has never ever worked for me though
01:01:15	Torne	with anything :)
01:01:36	TheSeven	doing it which way?
01:01:43		Part toffe82
01:01:56	Torne	having binutils, gcc, libc, etc all sharing a single source dir
01:02:07	Torne	so that a single configure/make/make install does the lot
01:02:08	TheSeven	user890104: I know what's going on and why it happens, but if I fix it, USB breaks completely for an unknown reason
01:02:34	Torne	elf2flt is also derived from gcc and friends and thus is able to work the same way
01:02:52	Torne	at which point it wouldn't need any of bfd's headers to be installed because it would get them from the source tree
01:03:34	TheSeven	how do other tools that need to access .elf/.o files without having access to the bfd headers during compilation do it?
01:03:50	Torne	they stay as far away from libbfd as they possibly can, generally
01:03:51	TheSeven	i can't think of an example of such a tool right now, but i found one some weeks ago
01:03:54	Torne	becaue it's an insane nightmare world
01:04:11	Torne	people tend to use elflib or whatver it's called
01:04:21	Torne	because its API isn't so terrifyingly and unnecessarily generic
01:04:50	Torne	it's slightly frightening that elf2flt uses bfd :)
01:05:21	TheSeven	well, at least I made it work if I manage to steal bfd.h and libbfd.h quick enough during binutils compilation
01:05:28	TheSeven	libbfd.a*
01:05:41	Torne	right. i have no idea how the "right" way is
01:05:44	pamaury	perhaps elf2flt plan to work on something else than elf ;)
01:05:51	Torne	other than to suspect that they might expect you to do it with a unified sourcetree
01:06:13	Torne	the docs for all that are atrocious
01:06:13	TheSeven	well, their configure wants a −−with-binutils-build-dir=/whatever
01:06:28	Torne	right, but toplevel configure will probably provide that if it's unified
01:06:45	Torne	since with a unified build everything gets built without anything needing to be installed
01:06:53	Torne	and so the components need to know where each other are
01:07:40	Torne	the instructions i found for this process involve steps like "untar x over the top of y, and, er, assume that whichever archive was released most recently is okay to overwrite files from the other one"
01:07:54	Torne	since all these things have copies of all the toplevel stuff
01:08:05	Torne	and it does seem you are expected to just let htem overwrite each other :)9
01:08:26	TheSeven	hm
01:08:33	TheSeven	is llvm better regarding that?
01:08:45	Torne	never tried
01:09:02	Torne	nobody actually seems to build toolchains this way
01:09:11	CIA-70	New commit by kugel (r29330): Cleanup preprocessor around corelock usage and move its definition outside #ifdef ASSEMBLER_THREADS
01:09:11	Torne	even though all the actual docs for the relevant packages tend to imply that's how it's done
01:09:25	TheSeven	but gcc is getting on my nerves because of other things as well
01:09:27	pamaury	TheSeven: llvm is really nice to build
01:09:45	pamaury	(apart that it takes gigabytes of disk :-/)
01:09:51	TheSeven	also, the rockbox toolchain produces way bigger code than for example yagarto. i have no explanation why, but it's a major problem for me
01:11:00	thomasjfox	kugel: Why does android use a stack size of 0x1000 again? Native/SDL threads use 0x400. I'm just wondering if I need to patch that up for maemo, too.
01:11:07	TheSeven	i have that note exploit thing, where i need to fit a NAND driver + FTL + FAT32 code into ~3.7KB of space
01:11:55	kugel	thomasjfox: sdl threads don't use DEFAULT_STACK_SIZE
01:11:59	TheSeven	this worked just fine with yagarto (yay, 3 bytes free, when using UCL-compressed thumb code), and with the toolchain compiled by rockboxdev.sh it's like 300 bytes too big
01:12:17		Nick panni__ is now known as panni_ (hannes@ip-178-203-73-7.unitymediagroup.de)
01:13:02		Quit MethoS- (Remote host closed the connection)
01:13:27	kugel	thomasjfox: it shouldn't need changes from maemo, sigaltstack uses bigger stacks (MINSIGSTKSZ+0x3000)
01:13:47	thomasjfox	kugel: I want to try ASSEMBLER_THREAD again ;)
01:13:50	TheSeven	and also i've seen gcc save registers on the stack that it doesn't even use (it seems to always save r4, even though it would only need to save lr in some trivial wrapper)
01:14:06	pamaury	what is yagarto ?
01:14:16	thomasjfox	kugel: Maybe the crashes on database init were related to the recent uninitialized vars fixes on metadata parsing
01:14:25	kugel	0x1000 works for android but I don't know for maemo
01:14:29	CIA-70	r29330 build result: All green
01:14:31	TheSeven	pamaury: the new name of the gnuarm-win32 toolchain
01:14:44	thomasjfox	kugel: Congratulations!
01:14:51	kugel	\o/
01:14:59	pamaury	finally :)
01:15:00	TheSeven	so basically also an eabi gcc, just a slightly different version, and probably different patches/compile-time options
01:15:03		Join t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201)
01:15:10		Join MethoS- [0] (~clemens@134.102.106.250)
01:16:40		Quit pamaury (Remote host closed the connection)
01:18:50	thomasjfox	kugel: Database rebuilt worked with ASSEMBLER_THREADS
01:19:08	kugel	interesting
01:19:16	kugel	I suspected it was a compiler bug
01:19:28	thomasjfox	kugel: I have to do a full .deb package rebuild, it segfaults on playback (codec load)
01:19:52	thomasjfox	Though that segfault is probably just a mismatch of defines during compile time
01:21:52	kugel	TheSeven: can yagarto build rockbox?
01:22:58	kugel	fwiw, I don't think yagarto makes smaller code, but rather the newer gcc version
01:31:11	thomasjfox	kugel: SIGALTSTACK and SDL_THREADS are working here. Testing ASSEMBLER_THREADS with full rebuild next
01:32:09	CIA-70	New commit by thomasjfox (r29331): N900: Prevent stuck up/down keys on systems with shared up/down cursor mapping
01:32:46	TheSeven	kugel: no idea
01:33:27	TheSeven	kugel: the yagarto version I use has gcc 4.5.0
01:33:52	TheSeven	(we're using 4.4.4)
01:37:08	CIA-70	r29331 build result: All green
01:40:09		Quit vnl (Ping timeout: 240 seconds)
01:40:17	***	Saving seen data "./dancer.seen"
01:41:15		Quit dfkt_ (Read error: Connection reset by peer)
01:42:35		Quit bertrik (Quit: :tiuQ)
01:48:45		Quit Judas_PhD (Ping timeout: 264 seconds)
01:50:18	CIA-70	New commit by thomasjfox (r29332): Use SIGALTSTACK in maemo build
01:51:37	thomasjfox	kugel: ASSEMBLER_THREADS still crashes on playback. Compiler bug ;)
01:52:07	kugel	tried upping the stack size?
01:52:22	thomasjfox	0x1000 like android
01:52:30	thomasjfox	ok, one more try with 0x10000
01:53:21		Quit mudd1 (Ping timeout: 250 seconds)
01:54:30	CIA-70	r29332 build result: All green
01:55:05		Quit Jerom (Quit: Leaving.)
01:57:36		Quit sideral (Quit: Leaving.)
01:58:29	thomasjfox	kugel: It crashes on various strange places. If I comment them out, it continues and crashes elsewhere. Atleast I can hear the playback :)
01:59:35	kugel	alright, so stick with sigaltstack I'd say
02:00
02:01:06	thomasjfox	exactly :)
02:01:18		Quit liar (Quit: Leaving)
02:02:01		Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com)
02:02:06	thomasjfox	kugel: I'm currently testing windowed mode again. The window manager cuts away ~20-30 pixel at the bottom by inserting a status bar at the top.
02:02:41	thomasjfox	kugel: Unfortunately it doesn't add this offset to the touchscreen surface, so the current cabbiev2 port is not usable
02:03:12	thomasjfox	kugel: What should we do here? Add a close/switch window button? Custom theme?
02:03:50	kugel	perhaps you can modify the lcd driver to translate the offset so that it cuts off at the top?
02:05:45	thomasjfox	kugel: looks like I was wrong, "touching" the items in the main menu is exactly the touched position
02:06:08	thomasjfox	kugel: So it's just the WPS that sucks for now because all the playback controls are at the bottom
02:06:38	kugel	can you hide the statusbar at runtime?
02:06:59	kugel	i.e. show it in the main menu, hide in the wps?
02:07:18	thomasjfox	not that I know of
02:07:28	thomasjfox	That would be the difference between windowed/fullscreen mode
02:07:34	thomasjfox	I could make this switchable
02:08:34	thomasjfox	Though the windowed mode would be preferred as the user is familiar with the controls already
02:12:36		Quit factor (Quit: Leaving)
02:13:43	CIA-70	New commit by kugel (r29333): Android: Rewrite lcd subsystem to use the SurfaceView API. ...
02:18:01	CIA-70	r29333 build result: All green
02:26:48	CIA-70	New commit by kugel (r29334): Correct setServiceActivity implementation
02:30:54	CIA-70	r29334 build result: All green
02:31:46	CIA-70	New commit by kugel (r29335): Android: Re-attach the media button receiver when entering Rockbox.
02:34:54		Quit ender` (Quit: I think I remember an episode of MacGyver where he overthrew a violent dictator with a rubber band, 2 bottle caps, and some navel lint.)
02:36:09	CIA-70	r29335 build result: 4 errors, 0 warnings (kugel committed)
02:37:44	kugel	strange error
02:38:02	kugel	Bagder: ^ ?
02:45:12	CIA-70	New commit by thomasjfox (r29336): Add missing cabbiev2 800x480 backdrop
02:48:53		Quit MethoS- (Remote host closed the connection)
02:49:05	CIA-70	r29336 build result: 4 errors, 0 warnings (thomasjfox committed)
02:50:13	CIA-70	New commit by gevaerts (r29337): Add storebror-daniel to blockedclients
02:59:20		Join mystica555 [0] (~Mike@m3e2636d0.tmodns.net)
03:00
03:13:32		Join milk [0] (~milk@94-193-93-226.zone7.bethere.co.uk)
03:15:59	kugel	gevaerts: aha, the error actually says what to do
03:19:10	CIA-70	New commit by kugel (r29338): Explicitely add -lpthread to the linker command for the new sigaltstack threads.
03:19:30	kugel	gevaerts: storebrow-daniel should work now
03:20:11	*	S_a_i_n_t wonders why the Android widgets seem to hate \|<< and >>\|, and why line and box type widgets give dissimilar results.
03:20:14	CIA-70	New commit by gevaerts (r29339): Remove storebror-daniel from blockedclients again
03:21:01	S_a_i_n_t	and also why the .wps/.sbs doesn't recognise the correct playback state when the state is changed by the widget and not the app.
03:21:17	gevaerts	kugel: I'm not actually sure if doing this sort of threading changes is a good idea during a freeze
03:21:19	S_a_i_n_t	particularly, "stop".
03:21:47	kugel	gevaerts: it doesn't affect any released target, so
03:22:02	gevaerts	kugel: it seems to affect simulators of released targets
03:22:12	kugel	but yea, I initially wanted to wait until the freeze is over, but for some reason I completely forgot about it now
03:23:24	CIA-70	r29338 build result: All green
03:25:57	kugel	I don't mind if it's (temporarily) reverted if you feel unhappy with it
03:27:08	gevaerts	How sure are you that this doesn't affect any of the simulator builds like e.g. cygwin?
03:27:47	S_a_i_n_t	cygwin builds are alread broken afaik.
03:27:51	S_a_i_n_t	(for sims)
03:28:10	gevaerts	or mingw
03:28:10	S_a_i_n_t	ah, no...wait...I'm thinking SDL.
03:28:13	kugel	gevaerts: I test compiled and run under mingw
03:29:01	*	gevaerts thinks AlexP should decide on this one
03:38:55	*	S_a_i_n_t also wonders if knowledgeable pople in the area of SDL have seen the SDL_WaitEvent error faults reported with disktidy lately.
03:40:18	***	Saving seen data "./dancer.seen"
03:43:58		Quit kugel (Quit: leaving)
04:00
04:06:25	Llorean	Do we build simulators of releases?
04:10:59	S_a_i_n_t	seems so.
04:11:05	S_a_i_n_t	rasher.dk/rockbox/simulator-release">http://rasher.dk/rockbox/simulator-release
04:11:34	S_a_i_n_t	(linked from the daily sims page)
04:12:05	Llorean	So how is this patch affecting simulator builds? Does it change their threading too?
04:14:37		Join L-Strife89 [0] (~Strife89@168.16.238.169)
04:18:16		Join maxsin [0] (~maxsin@188-115-150-221.broadband.tenet.odessa.ua)
04:22:53		Quit elcan (Ping timeout: 240 seconds)
04:24:08		Quit thomasjfox (Remote host closed the connection)
04:24:12		Join elcan [0] (user36@pr0.us)
04:24:34		Quit L-Strife89 (Ping timeout: 260 seconds)
04:32:43		Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox)
04:33:39	thomasjfox	S_a_i_n_t: valgrind output of disktidy crash using H320 sim / SDL threads: http://pastie.org/1581192
04:34:09		Quit Judas_PhD (Quit: This is a quitting message)
04:38:05		Join amiconn_ [0] (quassel@rockbox/developer/amiconn)
04:38:05		Quit amiconn (Disconnected by services)
04:38:12		Quit thomasjfox (Remote host closed the connection)
04:38:21		Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn)
04:38:37		Quit pixelma (Disconnected by services)
04:38:39		Join pixelma_ [0] (quassel@rockbox/staff/pixelma)
04:38:41		Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma)
04:47:19		Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com)
04:52:51		Join Horschti [0] (~Horscht@p5DD56DE5.dip.t-dialin.net)
04:53:04		Join Xerion_ [0] (~xerion@5419A4D7.cm-5-2c.dynamic.ziggo.nl)
04:55:37		Join Barahir_ [0] (~jonathan@frnk-590fcd66.pool.mediaWays.net)
04:57:45		Join kkit`sh [0] (~kkit@li135-248.members.linode.com)
04:58:59		Quit Barahir (Ping timeout: 260 seconds)
04:59:56		Join Kitr88 [0] (Kitarist@BSN-182-66-53.dial-up.dsl.siol.net)
05:00
05:00:38		Join T44 [0] (~Topy44@89.204.137.146)
05:00:38		Quit Kitar\|st (Ping timeout: 255 seconds)
05:00:39		Quit Xerion (Ping timeout: 255 seconds)
05:00:40		Quit Horscht (Ping timeout: 255 seconds)
05:00:40		Quit Topy44 (Ping timeout: 255 seconds)
05:00:40		Quit jfc (Ping timeout: 255 seconds)
05:00:40		Quit kkit\|sh (Ping timeout: 255 seconds)
05:00:41		Join jfc [0] (~john@pool-72-73-80-12.ptldme.east.myfairpoint.net)
05:00:41		Quit TheSeven (Ping timeout: 264 seconds)
05:00:42		Quit Horschti (Changing host)
05:00:42		Join Horschti [0] (~Horscht@xbmc/user/horscht)
05:00:44		Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven)
05:00:46		Nick Xerion_ is now known as Xerion (~xerion@5419A4D7.cm-5-2c.dynamic.ziggo.nl)
05:32:31		Quit Rob2222 (Ping timeout: 240 seconds)
05:34:08		Join Rob2223 [0] (~Miranda@p4FFF0632.dip.t-dialin.net)
05:34:11		Join Zarggg [0] (~zarggg@24.229.139.169.res-cmts.sm.ptd.net)
05:36:57		Quit Slasheri (Ping timeout: 276 seconds)
05:39:05		Join Slasheri_ [0] (miipekk@xen.ihme.org)
05:40:19	***	Saving seen data "./dancer.seen"
05:45:49		Join L-Strife89 [0] (~Strife89@168.16.238.237)
05:46:54		Quit maxsin (Quit: Leaving.)
05:59:19		Join Keripo [0] (~Keripo@eng396.wireless-resnet.upenn.edu)
06:00
06:00:27		Quit Keripo (Client Quit)
06:19:58		Join Horscht [0] (~Horscht@p5DD56C73.dip.t-dialin.net)
06:19:58		Quit Horscht (Changing host)
06:19:58		Join Horscht [0] (~Horscht@xbmc/user/horscht)
06:20:58		Quit BHSPitMonkey (Ping timeout: 240 seconds)
06:22:59		Quit Horschti (Ping timeout: 260 seconds)
06:34:12		Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey)
06:41:23		Quit Judas_PhD (Quit: This is a quitting message)
06:42:05		Quit L-Strife89 (Ping timeout: 276 seconds)
06:44:51		Nick S_a_i_n_t is now known as [Saint] (S_a_i_n_t@203.184.1.146)
06:45:39		Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com)
06:47:34		Quit Judas_PhD (Client Quit)
06:50:31		Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com)
07:00
07:09:24		Quit Zarggg (Read error: Connection reset by peer)
07:10:24		Join Zarggg [0] (~zarggg@24.229.139.169.res-cmts.sm.ptd.net)
07:37:29		Quit panni_ (Quit: ( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de ))
07:40:20	***	Saving seen data "./dancer.seen"
07:45:40		Quit Zarggg (Quit: Zarggg)
07:54:25		Quit t0rc (Remote host closed the connection)
07:59:07		Join mudd1 [0] (~cmertes@ip-78-94-203-49.unitymediagroup.de)
08:00
08:01:28		Quit [Saint] (Quit: I'm only going to Heaven if it feels like Hell, I'm only going to Heaven if it tastes like caramel...)
08:06:39		Join [Saint] [0] (S_a_i_n_t@203.184.3.43)
08:11:22		Join L-Strife89 [0] (~Strife89@168.16.238.169)
08:11:39		Join factor [0] (~factor@75.108.68.114)
08:34:15		Quit L-Strife89 (Ping timeout: 260 seconds)
08:45:05		Join esperegu [0] (~quassel@145.116.15.244)
09:00
09:07:09		Quit BHSPitMonkey (Quit: Ex-Chat)
09:36:28		Quit factor (Read error: Connection reset by peer)
09:38:59		Join fkhodkov [0] (~fedor76@ppp-188-65-11-112-bras1.istra.ru)
09:40:03		Join fkhodkov_ [0] (~fedor76@ppp-188-65-11-112-bras1.istra.ru)
09:40:11		Quit fkhodkov_ (Remote host closed the connection)
09:40:24	***	Saving seen data "./dancer.seen"
09:40:36		Quit fkhodkov (Client Quit)
09:41:10		Join fkhodkov [0] (~fedor76@ppp-188-65-11-112-bras1.istra.ru)
09:52:50	[Saint]	can anyone enlighten me as to what I'm doing wrong here?
09:52:50	[Saint]	http://pastebin.com/85VWd9Fa
09:53:36	[Saint]	afaik I'm setting the path correctly, but configure seems to disagree.
09:54:11		Join factor [0] (~factor@75.108.68.114)
09:59:03		Quit sasquatch (Quit: WeeChat 0.3.2)
09:59:28		Join sasquatch [0] (~username@p4FF2DA06.dip.t-dialin.net)
09:59:39		Join einhirn [0] (~Miranda@p548504F0.dip0.t-ipconnect.de)
10:00
10:05:39		Join kugel [0] (~kugel@rockbox/developer/kugel)
10:06:07		Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org)
10:07:12		Join kugel_ [0] (~kugel@rockbox/developer/kugel)
10:07:53		Quit kugel (Remote host closed the connection)
10:08:00		Nick kugel_ is now known as kugel (~kugel@rockbox/developer/kugel)
10:10:01		Join einhirn [0] (~Miranda@p548504F0.dip0.t-ipconnect.de)
10:14:15		Quit einhirn (Client Quit)
10:14:43	kugel	[Saint]: no idea...
10:18:20		Quit parafin (Ping timeout: 276 seconds)
10:18:50	[Saint]	gah....now my ubuntu VM has decided to not accept my password at boot.
10:19:04	[Saint]	this is fun.
10:22:12		Join kevku [0] (~kevku@2001:7d0:0:f9af:feed:feed:feed:feed)
10:33:28		Quit Unhelpful (Ping timeout: 250 seconds)
10:33:59		Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful)
10:34:41	JdGordon\|	Buschel: my mini is still going strong (album on repeat for the last 25 odd hours), if i remember i'll put svn without the fix on it tonight and see if it actually helped at all
10:35:56	JdGordon\|	Zagor: If you mst move it albumart.c is far better than the skin engine
10:36:27	JdGordon\|	kugel: does RaaA now require 2.3?
10:36:42	kugel	no
10:37:18		Join stoffel [0] (~quassel@p57B4A93F.dip.t-dialin.net)
10:45:43		Quit Dreamxtreme (Ping timeout: 276 seconds)
10:46:19		Join vnl [0] (~slayer@cpc5-king10-2-0-cust73.perr.cable.virginmedia.com)
10:48:46		Quit Judas_PhD (Quit: This is a quitting message)
10:49:21	AlexP	gevaerts, kugel: I have to be guided by you guys on technical aspects - things like cygwin sim builds are a bit of a difficult case as they get broken from time to time with nobody noticing anyway as so few people use them.
10:50:03	AlexP	gevaerts, kugel: We are due to branch tomorrow, maybe it would be best to revert the change in the branch if nobody has tested it? (To reduce noise in svn)
10:50:31		Join Dreamxtreme [0] (~Dre@92.29.1.2)
10:51:53	kugel	rasher has windows simulators on his site, but that doesn't count as release does it? anyway, I tested a mingw build and cygwin should also work
10:52:12	kugel	you can also supply −−sdl-threads to configure to have the old behavoir
10:55:35	AlexP	kugel: well, as I say I trust you guys - I would have preferred to not put it in, but seeing as it is I'll leave it to you to decide whether it is worth taking it out again
10:56:32	kugel	as I said, I actually planned to wait but forgot about it. I
10:56:38	kugel	I'm not opposed to reverting
10:57:21	kugel	although it'd be a slight pita due to the post commits :)
10:57:36	AlexP	yes, I guessed that :)
10:59:34		Join jaykay1 [0] (~Jaykay@p5DC57B97.dip.t-dialin.net)
11:00
11:00:19		Quit milk (Read error: Connection reset by peer)
11:02:20		Quit Unhelpful (Ping timeout: 250 seconds)
11:03:52		Join TheLemonMan [0] (~lem0n@151.62.128.108)
11:04:23		Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful)
11:10:09	kugel	AlexP: http://pastie.org/1581793 should revert it
11:10:41	kugel	(with git cherry-pick it was only a very minor pita :) )
11:12:09		Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox)
11:15:11		Join casainho [0] (~chatzilla@pal-213-228-181-14.netvisao.pt)
11:20:01		Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com)
11:20:53	AlexP	kugel: Well seeing as you have taken the time to find it, maybe for completeness it'd be nice to do that. The other option is to wait until branching and do it in the branch, but it could then be a bugger if anyone else touches the code before then
11:21:33	kugel	and then revert the revert after branching? :)
11:22:33		Join webguest74 [0] (www-data@giant.haxx.se)
11:23:10	thomasjfox	The new thread code is playing fine next to me ;)
11:23:39	kugel	alright, I take it as that we officicially care about simulators for releases as well?
11:23:39	AlexP	kugel: Well as I say, I give way to you on whether it is necessary :)
11:23:44	thomasjfox	Maybe just default to SDL threads for compatibility reasons in 3.8?
11:23:45		Quit webguest74 (Client Quit)
11:24:01	AlexP	kugel: This is it, I'm not sure - we don't officially release any
11:24:19	AlexP	I don't think we've really thought about it before
11:24:51	*	AlexP is in two minds :)
11:24:53	kugel	you and gevaerts decide I guess
11:25:04	*	AlexP waits for gevaerts :)
11:25:15		Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl)
11:25:15		Quit bertrik (Changing host)
11:25:15		Join bertrik [0] (~bertrik@rockbox/developer/bertrik)
11:25:42	thomasjfox	IIRC gevaerts said to wait for AlexP. Deadlock?
11:26:03	AlexP	he did, but I meant to discuss it :)
11:26:51	thomasjfox	kugel: What about sticking to SDL threads as default for the release? That shouldn't change behavior?
11:27:19	kugel	what release? we don't release simulators :)
11:30:44	thomasjfox	kugel: I was just thinking how we can get back the old behavior without reverting your lovely new code
11:31:20	AlexP	I think in this case we can probably leave it
11:31:34	AlexP	We don't release sims, and there is the flag if needs be
11:31:43	AlexP	But I'll conflab with gevaerts
11:35:25	thomasjfox	linuxstb: You were right about the play/pause button. The first thing my brother asked me when I showed him rockbox was "so, where is the pause button?"
11:36:59		Join ender` [0] (krneki@foo.eternallybored.org)
11:39:08	thomasjfox	kugel: Just ran the sigaltstack stuff in valgrind. Any idea about this? http://pastie.org/1581841
11:39:52	thomasjfox	kugel: Ah, forget it
11:40:05	thomasjfox	kugel: valgrind can't detect the stack change
11:40:15		Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk)
11:40:28	***	Saving seen data "./dancer.seen"
11:40:38		Join parafin [0] (parafin@2001:470:1f0b:81::1)
11:41:53	thomasjfox	kugel: Hmm, still unhappy with "−−max-stackframe=34334767696". I'll try a SDL threads build.
11:42:22		Quit stripwax (Client Quit)
11:42:44		Quit parafin (Client Quit)
11:42:50	kugel	thomasjfox: I never used valgrind, what does that mean?
11:42:51		Join parafin [0] (parafin@paraf.in)
11:43:05		Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk)
11:43:07	thomasjfox	kugel: Do you know how valgrind works?
11:43:25	kugel	no
11:44:06	thomasjfox	kugel: It intercepts OS calls like malloc() and others. So it can check for buffer overflows/underflows and use of uninitialized variables at runtime
11:44:13	thomasjfox	In fact, it checks all memory accesses
11:44:32	thomasjfox	It examines how a program behaves at runtime
11:44:57	thomasjfox	That's how I found out the uninitialized vars issue Buschel recently fixed
11:45:20	thomasjfox	It's easy as running "valgrind ./rockbox" with the SDL app build or a sim build
11:46:11		Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.3-3.cable.virginmedia.com)
11:51:08		Join pamaury [0] (~quassel@dhcp-128-95.residence.ens-lyon.fr)
11:51:09		Quit pamaury (Changing host)
11:51:09		Join pamaury [0] (~quassel@rockbox/developer/pamaury)
11:51:38		Join Kitar\|st [0] (~Kitarist@BSN-182-26-79.dial-up.dsl.siol.net)
11:53:16	kugel	thomasjfox: I get Thread creation failed. "Retryingmake_context(): Operation not permitted" in valgrind
11:53:32	kugel	the first " should be before Thread
11:53:35	thomasjfox	kugel: Which valgrind version?
11:53:51	kugel	valgrind-3.6.0.SVN-Debian
11:54:36	thomasjfox	should be fine
11:54:49	thomasjfox	let me take a close look at the output
11:55:30		Quit Kitr88 (Ping timeout: 260 seconds)
11:55:32	thomasjfox	works-for-me(mt)
11:55:50	thomasjfox	Still get the invalid write though as mentioned on pastie
11:55:57	thomasjfox	Could be a false positive
11:56:14		Quit Kitar\|st (Ping timeout: 250 seconds)
11:56:21		Join Stummi [0] (~Stummi@rockbox/developer/Stummi)
12:00
12:00:30		Quit TheLemonMan (Quit: free(me))
12:01:15		Join Kitar\|st [0] (~Kitarist@BSN-182-82-225.dial-up.dsl.siol.net)
12:01:27	thomasjfox	kugel: I don't think sigaltstack is compatible with valgrind at the moment, it doesn't get past the startup screen
12:02:25		Join Keripo [0] (~Keripo@eng327.wireless-resnet.upenn.edu)
12:02:29		Quit Keripo (Client Quit)
12:02:30	kugel	"Thread creation failed. Retrying" comes from valgrind, "make_context(): Operation not permitted" comes from rockbox
12:02:55	kugel	so one of those library calls is not allowed within valgrind and valgrind detects that we try to make threads
12:03:21	kugel	ah no wait, the "Thread creation failed. Retrying" also comes from rockbox
12:03:35	thomasjfox	I don't get any of those error messages, it just hangs
12:04:42	thomasjfox	kugel: ah, now I get it too with a sim build
12:04:49	thomasjfox	kugel: Doesn't happen with the SDL app build
12:05:51	kugel	kugel: yea, the default app build stubs DEBUGF()
12:05:55	kugel	thomasjfox: ^
12:05:59		Join inox [0] (www-data@giant.haxx.se)
12:06:41	inox	hello
12:07:25	kugel	thomasjfox: sigaltstack() fails within valgrind
12:08:24	stripwax	inox - hello
12:08:47		Quit inox (Client Quit)
12:08:54	stripwax	interesting
12:09:28		Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at)
12:10:03		Join webguest71 [0] (www-data@giant.haxx.se)
12:10:21	webguest71	hello
12:10:48	stripwax	webguest71 - hello
12:15:31		Quit webguest71 (Quit: CGI:IRC (Ping timeout))
12:15:42		Join webguest90 [0] (www-data@giant.haxx.se)
12:16:59		Quit webguest90 (Client Quit)
12:18:06	AlexP	kugel: See http://www.rockbox.org/tracker/task/11952 ? :)
12:21:46	thomasjfox	kugel: do you have a standalone / development version of the ucontext stuff?
12:22:00	kugel	yes, somewhere
12:22:03	thomasjfox	kugel: The example found here http://evanjones.ca/software/threading.html works fine in valgrind
12:22:24	thomasjfox	kugel: The example under "figure 3"
12:23:55	thomasjfox	kugel: oh, the example in "figure 4" doesn't. I'll ask the valgrind poeple about it
12:24:05	kugel	thomasjfox: figure 4 uses makecontext, we don't
12:25:06	kugel	I compiled valgrind, how do I execute the test suits?
12:25:14		Part jaykay1
12:26:50		Quit Judas_PhD (Quit: This is a quitting message)
12:27:09	thomasjfox	kugel: my rpm spec file first does "make check"
12:27:28	thomasjfox	kugel: and then "make regtest"
12:27:47	kugel	alright, trying that. it has a sigaltstack test
12:29:41	kugel	stack_switch: valgrind -q ./stack_switch
12:29:41	kugel	* stack_switch failed (stderr) *
12:31:12	kugel	but the sigaltstack test run fine
12:31:30	thomasjfox	kugel: is stack_switch your implementation?
12:31:36	kugel	no
12:33:42		Join esperegu_ [0] (~quassel@145.116.10.163)
12:34:30	thomasjfox	kugel: are you on a 64bit or 32bit system?
12:34:35		Join GeekShadow [0] (~Antoine@93.21.172.52)
12:34:36		Quit GeekShadow (Changing host)
12:34:36		Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow)
12:34:36	kugel	64
12:34:44		Quit GeekShadow (Remote host closed the connection)
12:34:54	thomasjfox	me too. maybe that's the issue?
12:35:03		Quit esperegu (Ping timeout: 276 seconds)
12:35:38	thomasjfox	anyway, I didn't notice anything unusal with your sigaltstack code, playing for hours now. So it's fine :)
12:41:44	kugel	hm, I can't run the compiled valgrind
12:41:54		Join dfkt [0] (dfkt@unaffiliated/dfkt)
12:41:57		Join TheLemonMan [0] (~lem0n@151.62.128.108)
12:43:30	thomasjfox	kugel: Stupid question: Did you run "make install"? It looks for some components at runtime
12:43:37	kugel	yea
12:43:47	kugel	I installed into <src-dir>/bin
12:45:00	kugel	aha, strace shows it looks in /usr/local/lib
12:45:00	thomasjfox	kugel: Running the 32bit version of valgrind against the 32bit version of "figure 4" works. So it's a 64bit system issue
12:45:25	kugel	oha
12:45:30	thomasjfox	kugel: In fact, how does rockbox cope with 64bit??
12:45:42	thomasjfox	kugel: Shouldn't we force gcc to 32bit?
12:45:53	kugel	we have 64bit sims for years without problems
12:45:57	thomasjfox	ok
12:48:17	kugel	thomasjfox: does the 32bit valgrind also work with a 32bit sim?
12:48:38	thomasjfox	is there an easy way to compile a 32bit sim?
12:49:17	kugel	don't know
12:49:34	kugel	I assume specifying the 32bit cross compiler gcc should work
12:50:24	thomasjfox	I added the -m32 and −−target to simcc. Lets see how that goes
12:50:39	kugel	configure sees $CROSS_COMPILE
12:53:28	kugel	thomasjfox: valgrind's testcase is slightly different
12:54:02		Join MethoS- [0] (~clemens@134.102.106.250)
12:55:17	kugel	thomasjfox: I sent you my standalone code
12:55:39	thomasjfox	kugel: checking
12:56:21		Quit casainho (Ping timeout: 246 seconds)
12:58:40	kugel	modifying the test case to use a static stack, instead of a mmap'd one also works
13:00
13:00:24		Join maxsin [0] (~maxsin@188-115-150-221.broadband.tenet.odessa.UA)
13:02:43	thomasjfox	kugel: Sent you the output
13:03:14	kugel	well, it's a different error
13:04:27	kugel	the manpage says [EPERM] An attempt was made to modify an active stack.
13:06:56	thomasjfox	kugel: Sent you another output with "−−track-origins=yes".
13:07:03	thomasjfox	kugel: Looks bogus to me
13:07:17		Join DerPapst [0] (~Alexander@p5DE5B48B.dip.t-dialin.net)
13:07:56	kugel	I don't know what these messages mean
13:10:45		Quit maxsin (Ping timeout: 260 seconds)
13:12:29	kugel	thomasjfox: can it possibly have something to do with the multithread environment?
13:14:32	thomasjfox	kugel: No idea. I just tried something "stupid": I did zero initialize all the structures in mk_ctx. Now valgrind is happy. huh?
13:14:58	thomasjfox	kugel: Let me try that with 64bit code again
13:22:18		Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93)
13:24:59	kugel	haha, "Memcheck: the 'impossible' happened:
13:30:55		Quit jfc (Ping timeout: 240 seconds)
13:33:17		Quit stripwax (Quit: http://miranda-im.org)
13:35:00		Join hebz0rl [0] (~hebz0rl@dslb-092-075-125-138.pools.arcor-ip.net)
13:35:19	kugel	[Saint]: can you try building a sim on cygwin?
13:35:25	thomasjfox	kugel: I'd say valgrind is currently not compatible with sigaltstack
13:35:28	kugel	(FS #11952)
13:35:35		Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk)
13:35:42	kugel	thomasjfox: this and 64bit :)
13:36:01	kugel	I can get valgrind to segfault
13:36:19	thomasjfox	kugel: run valgrind on valgrind :o)
13:37:49	kugel	that doesn't seem to work
13:40:30	***	Saving seen data "./dancer.seen"
13:42:28		Join halmi [0] (~netbook@194.48.133.8)
13:43:04		Join bluefoxx_ [0] (fuzzylomba@S0106485b3917092d.vs.shawcable.net)
13:45:26		Join halmi_ [0] (~netbook@194.48.133.8)
13:46:24		Quit bluefoxx (Ping timeout: 246 seconds)
13:47:29		Quit halmi (Ping timeout: 240 seconds)
13:50:59		Quit user890104 ()
13:51:43	pixelma	soap, AlexP, scorche: please ban dfhjkh54 in the forums
13:52:09		Quit hebz0rl (Quit: Leaving)
13:53:44	AlexP	pixelma: done
13:54:00	pixelma	thanks
13:57:41		Join maxsin [0] (~maxsin@188-115-150-221.broadband.tenet.odessa.UA)
14:00
14:07:49		Join DerPapst1 [0] (~Alexander@p5DE5B48B.dip.t-dialin.net)
14:08:32		Join simabeis_ [0] (~simabeis@lobmenschen.de)
14:08:39		Join alexbobP_ [0] (~alex@ppp-70-253-65-89.dsl.austtx.swbell.net)
14:08:41		Join tomj_ [0] (~thomasjfo@rockbox/developer/thomasjfox)
14:08:49		Join zu_ [0] (~zu@ks355000.kimsufi.com)
14:08:59		Quit [Saint] (Disconnected by services)
14:09:01		Join S_a_i_n_t [0] (S_a_i_n_t@203.184.3.43)
14:09:37		Join TheLemonMan_ [0] (~lem0n@151.62.128.108)
14:10:35		Join esperegu [0] (~quassel@145.116.10.163)
14:11:13		Join knitt1 [0] (~knittl@unaffiliated/knittl)
14:13:52		Quit DerPapst (Ping timeout: 246 seconds)
14:13:52		Quit zu (Ping timeout: 246 seconds)
14:13:52		Quit alexbobP (Ping timeout: 246 seconds)
14:13:52		Quit simabeis (Ping timeout: 246 seconds)
14:13:53		Quit TheLemonMan (Ping timeout: 246 seconds)
14:13:53		Quit esperegu_ (Ping timeout: 246 seconds)
14:13:53		Quit thomasjfox (Ping timeout: 246 seconds)
14:13:53		Quit ved (Ping timeout: 246 seconds)
14:13:53		Quit knittl (Ping timeout: 246 seconds)
14:14:16		Join ved [0] (ved@ddsbox.co.cc)
14:14:32		Quit halmi_ (Ping timeout: 240 seconds)
14:18:28		Join dfkt_ [0] (dfkt@unaffiliated/dfkt)
14:22:07		Quit dfkt (Ping timeout: 250 seconds)
14:23:33		Join halmi [0] (~netbook@194.48.133.8)
14:23:44		Quit tomj_ (Remote host closed the connection)
14:24:00		Join thomasjfox_ [0] (~thomasjfo@rockbox/developer/thomasjfox)
14:24:06		Nick thomasjfox_ is now known as thomasjfox (~thomasjfo@rockbox/developer/thomasjfox)
14:39:08		Quit thomasjfox (Remote host closed the connection)
14:54:31		Quit halmi (Quit: halmi)
14:55:29		Join greyback [0] (~gerry@78-80-200-213.tmcz.cz)
15:00
15:03:49		Join Topy44 [0] (~Topy44@89.204.137.243)
15:04:07		Join afk [0] (~Dre@92.28.11.11)
15:04:31		Quit T44 (Ping timeout: 240 seconds)
15:06:19		Quit Dreamxtreme (Ping timeout: 250 seconds)
15:11:33		Quit Kitar\|st ()
15:14:03	gevaerts	AlexP, kugel: I don't really agree that we don't release simulators
15:14:26	gevaerts	We don't release simulator builds, but we do release source that is expected to build working simulators
15:14:55	AlexP	true enough
15:15:01	gevaerts	So if simulators have a serious bug, I'd definitely see that as a reason for a point release
15:15:41	AlexP	Anyway, seeing as cygwin simulators don't currently build with thread errors, I'd say revert it.
15:20:04	kugel	AlexP: I'm quite certain Buschel just didn't make reconf
15:20:19	AlexP	ah, OK
15:20:28	AlexP	well, someone on cygwin needs to test :)
15:20:30	pixelma	errmm, just added a comment to the task that I successfully build an r29339 Gigabeat S sim with my cygwin 1.7 machine here
15:20:33	kugel	someone on cygwin just needs to confirm
15:20:38	AlexP	pixelma: OK, thanks
15:20:40	kugel	hehe :)
15:20:42	pixelma	*built
15:20:48	AlexP	score 1 for kugel's intuition :)
15:21:09	pixelma	thought he would get a notification mail...
15:26:54	stripwax	i just built a sim build on cygwin, seems to work fine.
15:27:17	stripwax	although I've not been following the convo so maybe something more subtle than 'it just works for me' ?
15:28:17	stripwax	also @ 29339
15:29:35		Quit afk (Quit: Ex-Chat)
15:30:03		Join Dreamxtreme [0] (~Dre@92.28.11.11)
15:38:32		Quit stripwax (Quit: http://miranda-im.org)
15:38:58		Quit dfkt_ (Read error: Connection reset by peer)
15:38:59		Join dfkt [0] (dfkt@unaffiliated/dfkt)
15:39:06	jhMikeS	kugel: the sim wait_for_interrupt is certainly curious. I see no mutex lock anywhere before waiting on the condition. ??
15:39:14		Join GeekShadow [0] (~Antoine@93.21.172.52)
15:39:14		Quit GeekShadow (Changing host)
15:39:14		Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow)
15:40:32	kugel	jhMikeS: in tick_start
15:40:34	***	Saving seen data "./dancer.seen"
15:41:24	jhMikeS	wouldn't that be by the main thread?
15:41:49	jhMikeS	of course maybe this doesn't work like I remember :)
15:41:53	kugel	yes, the same thread that calls wait_for_interrupt()
15:41:56	gevaerts	AlexP, kugel: I'm in favour of reverting, but I don't really care much if that's today in trunk or tomorrow in the branch
15:42:06	AlexP	My thoughts too
15:42:24	AlexP	tomorrow is probably cleaner if nothing else touches it before then
15:44:39	jhMikeS	kugel: wait, but what about around the SDL_CondSignal?
15:46:28	kugel	jhMikeS: why should it grab the lock before signalling?
15:46:57	jhMikeS	I believe it's supposed to by design
15:47:45	kugel	I understood it differently
15:48:00	kugel	and it wouldn't work if nothing is waiting on the condition
15:49:22	jhMikeS	semaphore is probably a simpler solution
15:50:52	kugel	I've done this with a sem for android and it's tricky
15:53:08		Join bluebrother [0] (~dom@g231123003.adsl.alicedsl.de)
15:53:09		Quit bluebrother (Changing host)
15:53:09		Join bluebrother [0] (~dom@rockbox/developer/bluebrother)
15:55:19		Quit bluebroth3r (Ping timeout: 264 seconds)
15:59:30	kugel	jhMikeS: you can lock if you desperately want to avoid races, but it's not critical in this case
16:00
16:00:16	kugel	so I rather chose to make wait_for_interrupt a bit cheaper
16:02:25	jhMikeS	I was looking at the SDL source code. It's really not a race any more than not disabling IRQ on a real device while executing WFI, actually quite the same thing.
16:04:02	pamaury	do arm core have something like a performance counter or similar ? (arm 920t precisely)
16:04:03	jhMikeS	looks safe for the object anyway if not using it for data protection
16:04:52	kugel	yea, we use it exclusively to not hog the cpuö
16:04:57	kugel	cpu*
16:08:21		Join Buschel [0] (~chatzilla@p54A3A86B.dip.t-dialin.net)
16:09:15	Buschel	fwiw, I did not do "make reconf" :/
16:09:19	*	Buschel does right now
16:20:37		Join Kitar\|st [0] (Kitarist@BSN-143-103-25.dial-up.dsl.siol.net)
16:20:37		Quit Kitar\|st (Client Quit)
16:23:04		Join Kitar\|st [0] (Kitarist@BSN-143-103-25.dial-up.dsl.siol.net)
16:23:04		Quit Kitar\|st (Client Quit)
16:23:19		Join Kitar\|st [0] (~Kitarist@BSN-143-103-25.dial-up.dsl.siol.net)
16:28:44		Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com)
16:30:43		Quit Judas_PhD (Client Quit)
16:30:43	kugel	Buschel: what are your results?
16:31:10	Buschel	looks good, build finished in this very second
16:31:22	Buschel	so, my apologies. I will close the report
16:31:30	kugel	no problem :)
16:36:24	gevaerts	AlexP: RHCC wants banning
16:37:16	AlexP	done
16:41:59	CIA-70	New commit by Buschel (r29340): FS #11950: Update czech language file.
16:46:01	CIA-70	r29340 build result: All green
16:49:22	jhMikeS	Buschel: I have a patch on your FS. I expect testing or I'm taking my chances with it (and interpreting lack of response as implicit trust in my abilities). :)
16:53:46		Quit Buschel (Ping timeout: 276 seconds)
16:56:35		Join casainho [0] (~chatzilla@bl20-146-26.dsl.telepac.pt)
17:00
17:20:23		Quit TheLemonMan_ (Quit: free(me))
17:39:29		Join esperegu_ [0] (~quassel@145.116.15.244)
17:40:12		Quit esperegu (Ping timeout: 240 seconds)
17:40:38	***	Saving seen data "./dancer.seen"
17:42:48	CIA-70	New commit by kugel (r29341): Android: Fix some race conditions and crashes on startup.
17:44:38	jhMikeS	kugel: I was getting segfaults in mpegplayer but not before the change. Will that take care of that?
17:45:08	kugel	jhMikeS: mpegplayer crashes?
17:46:32	jhMikeS	I reverted to r29326 and it played ok, r29340 was segfaulting when loading movie
17:47:11	CIA-70	r29341 build result: All green
17:47:27	jhMikeS	sdl sim on debian btw
17:49:20	kugel	jhMikeS: I'm assuming stack overflow
17:49:31	kugel	they don't use DEFAULT_STACK_SIZE
17:49:54	jhMikeS	that always had phony stacks
17:50:11	jhMikeS	or is that different now?
17:51:29	kugel	yes
17:51:52	kugel	the stack is used now, and on linux you need a minimum stack size (MINSTKSZ)
17:54:28	*	jhMikeS will gdb next to check it out then
17:54:37	kugel	jhMikeS: http://pastie.org/1582725 helps
18:00
18:00:44	jhMikeS	well, surely 4096+DEFAULT_STACK_SIZE is bigger than 4096 :)
18:03:19		Join Keripo [0] (~Keripo@eng066.wireless-resnet.upenn.edu)
18:04:29		Quit Keripo (Client Quit)
18:04:33	ender`	but what if default stack size is negative? :)
18:08:31	jhMikeS	then we're indeed in trouble :)
18:10:12	jhMikeS	hmmm...not enough stack to even get past the splash in gdb for the fun of it
18:12:18	CIA-70	New commit by kugel (r29342): Android: Fix compilation
18:12:23		Quit MethoS- (Remote host closed the connection)
18:13:28		Join MethoS- [0] (~clemens@134.102.106.250)
18:14:59		Join jfc [0] (~john@pool-72-73-80-12.ptldme.east.myfairpoint.net)
18:16:36	CIA-70	r29342 build result: All green
18:20:57		Join dfkt\|x [0] (~dfkt@chello062178002170.1.11.univie.teleweb.at)
18:20:58		Quit dfkt\|x (Changing host)
18:20:58		Join dfkt\|x [0] (~dfkt@unaffiliated/dfkt)
18:23:33		Nick alexbobP_ is now known as alexbobp (~alex@ppp-70-253-65-89.dsl.austtx.swbell.net)
18:24:03		Quit dfkt\|x (Remote host closed the connection)
18:37:24		Quit robin0800 (Quit: Leaving)
18:37:30		Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.3-3.cable.virginmedia.com)
18:38:19		Join robin0800_ [0] (~robin0800@cpc2-brig8-0-0-cust964.3-3.cable.virginmedia.com)
18:38:26		Quit robin0800 (Client Quit)
18:40:32		Quit literal (Read error: Connection reset by peer)
18:42:11		Join literal [0] (hinrik@w.nix.is)
18:45:23		Part vnl
18:47:00	pixelma	S_a_i_n_t: if I want the same touch "button" do different things on long and short presses - do I really need to define two touch areas in the same spot, one with the long press action and the other with the short press one?
18:47:58	pixelma	doesn't it clash somehow? I mean, e.g., play/pause on short press and stop on long, or seeking and skipping
18:48:16	kugel	works fine on android
18:48:23		Quit esperegu_ (Read error: Operation timed out)
18:50:44	pixelma	I find it a bit inconvenient and misleading. Couldn't it be an additional parameter in the touch area definition (coordinates, short press action, & long press action)?
18:50:52		Join esperegu [0] (~quassel@145.116.10.163)
18:59:00		Join leavittx [0] (~lev@89.221.199.187)
19:00
19:13:55		Quit leavittx (Ping timeout: 240 seconds)
19:16:46		Join Buschel [0] (~chatzilla@p54B669BD.dip.t-dialin.net)
19:18:15		Join leavittx [0] (~lev@89.221.199.187)
19:19:25	pixelma	for anyone involved in the "random skip to next song" discussion last weekend (I think it was) - I also get this sometimes on my c200 running 3.7 especially in playlists I created in small steps, inserting a few songs one by one or a small folder here and there), it sometimes skips to a next track in the middle of a song, if I then skip back everything is fine. Unfortunately I haven't found a way to reliably reproduce though
19:32:37		Nick knitt1 is now known as knittl (~knittl@unaffiliated/knittl)
19:33:15		Part greyback ("Ex-Chat")
19:40:41	***	Saving seen data "./dancer.seen"
19:43:39		Join panni_ [0] (hannes@ip-178-203-73-7.unitymediagroup.de)
19:47:00		Join Horschti [0] (~Horscht@xbmc/user/horscht)
19:50:19		Quit Horscht (Ping timeout: 240 seconds)
19:59:25	*	TheSeven just read the MBR of a CE-ATA ipod drive \o/
19:59:37	gevaerts	\☺/
19:59:53	gevaerts	Now play music from it!
20:00
20:00:04	TheSeven	well, it's not that far away
20:00:40	TheSeven	but there seem to be some timing peculiarities :/
20:02:12	jhMikeS	The MBR is in some odd meter like 7/8?
20:03:07	gevaerts	:)
20:03:18		Join einhirn [0] (~Miranda@p548504F0.dip0.t-ipconnect.de)
20:03:22		Quit einhirn (Client Quit)
20:06:54	*	TheSeven didn't get that joke
20:07:50	TheSeven	there's exactly one upside of CE-ATA: everything is DMA LBA48 :)
20:09:05	jhMikeS	gevaerts seemed to be suggesting to play music from the MBR :P
20:09:55	jhMikeS	anyway, why's a build with thumb whining about intptr_t but a non-thumb build makes fine :\
20:10:36	TheSeven	sounds like yet another ifdef fuckup?
20:11:01	jhMikeS	question of the century, when there's no obvious #ifdef around
20:13:20		Quit stoffel (Ping timeout: 276 seconds)
20:17:02	jhMikeS	seems to be cause by leaving out system.h in the includes in some files
20:23:38	*	jhMikeS wtf's over thumb binsize deltas
20:25:11		Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk)
20:27:09	TheSeven	jhMikeS: like a factor of 1.5?
20:31:30	jhMikeS	1.04 this time actually
20:33:44	TheSeven	hm, integrating ce-ata support into the rockbox ata driver isn't going to be easy
20:33:53	TheSeven	especially if we want it to be efficient
20:34:32	*	TheSeven ponders forking the driver
20:41:07		Quit GeekShadow (Ping timeout: 240 seconds)
20:41:18		Join mystica555_ [0] (~mike@m3e2636d0.tmodns.net)
20:47:11		Join saratoga_ [0] (9803c6dd@gateway/web/freenode/ip.152.3.198.221)
20:47:11		Quit saratoga_ (Client Quit)
20:47:25	saratoga	jhMikeS: does that patch you posted build for you?
20:47:47	saratoga	or do I need another patch first to use it?
20:48:16		Join TheLemonMan [0] (~lem0n@151.62.128.108)
20:48:56		Quit factor (Ping timeout: 240 seconds)
20:50:43		Quit stripwax (Quit: http://miranda-im.org)
20:52:57		Join wodz [0] (~wodz@87-206-240-131.dynamic.chello.pl)
20:53:46	wodz	stupid question - how to simulate memcpy result in IDA? I mean copy some portion of memory into other address
20:54:41	jhMikeS	saratoga: what's the issue? there's also an update coming
20:55:00	saratoga	jhMikeS: it can't find intptr_t in codec_thread.h
20:55:06	saratoga	which header includes that?
20:55:38	jhMikeS	for a thumb build? I just added system.h to codec_thread.c and playback.c
20:56:11	jhMikeS	inttypes.h I think is the main one though
20:56:37	saratoga	i'll try including that and see if it builds
20:57:50	jhMikeS	I'll have a new patch in a few anyway since there was a codec change snafu
20:58:29	saratoga	ok cool
20:59:19	saratoga	i skimmed that patch, but really didn't understand how half that stuff worked to begin with
21:00
21:01:13		Quit Buschel (Ping timeout: 240 seconds)
21:01:24		Join Jerom [0] (~jerome@79.132.59.245)
21:01:46	*	jhMikeS thinks he understands 1/3 to 1/2 of it−− whatever he rewrote himself :)
21:02:21	jhMikeS	the rest seems designed by some genetic algorithm
21:08:04	kugel	are you trying to build in thumb?
21:12:15	jhMikeS	the clip does build in thumb
21:12:23	saratoga	it does?
21:12:33	saratoga	should i apply both those patches?
21:12:51	jhMikeS	yeah, for the full effect :)
21:13:18	jhMikeS	the two I just posted of course
21:15:25	jhMikeS	without the metadata wait change, repeatedly seleting the track (so it sounds like a skipping cd) in the playlist viewer can lock.
21:18:17	saratoga	mashing the buttons on the wps screen as fast as I can doesn't dead lock, pretty sure that used to at some point
21:18:23		Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com)
21:19:37	saratoga	i also don't seem to be able to get teh WPS info and the currently decoding track to get out of sync
21:22:17	jhMikeS	that's that point, it locks the codec activity to the audio thread for changovers instead of it all racing around uncontrolled
21:25:13		Quit robin0800_ (Quit: Leaving)
21:29:51	saratoga	good job then
21:30:24	saratoga	i don't seem to be able to get it to mess up now on the clip+
21:36:06	saratoga	woah just managed to get it to skip to a different folder
21:36:10	saratoga	thats a little weird
21:36:54	kugel	what patch/FS# are you guys talking about?
21:37:10	saratoga	FS #11863 - Playback / buffer freezes
21:37:45	saratoga	is rockbox expect to skip folders if skip a few times, then hold the forward button down (as if to seek)?
21:37:53	saratoga	not sure if this is a bug or a feature
21:38:19	jhMikeS	saratoga: I've hit folder skip by accident too
21:38:29	saratoga	ah so its supposed to do that?
21:38:31	jhMikeS	short then long = folder skip
21:38:52	saratoga	yeah ok
21:38:55	saratoga	so no issues then
21:39:02	TheSeven	wodz: there are multiple ways
21:39:32	TheSeven	if you have the contents that you want to have in that memory area in an external file anyway, you may just use "load additional binary file"
21:39:47	TheSeven	you can also rewrite memcpy using Dword() and PatchDword() in IDC
21:39:50	jhMikeS	saratoga: great! now I need tracks that pass metadata muster but fail decoding since I'm not confident about the auto change on error part
21:39:57	TheSeven	neither of that will copy any markup though, just the plain data
21:40:42	***	Saving seen data "./dancer.seen"
21:54:41		Join FBI_Guy [0] (~fbiguy@pool-96-233-107-20.bstnma.fios.verizon.net)
22:00
22:04:28		Quit kugel (Quit: leaving)
22:07:17		Join GeekShadow [0] (~Antoine@93.21.167.102)
22:07:18		Quit GeekShadow (Changing host)
22:07:18		Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow)
22:11:07		Quit leavittx (Ping timeout: 240 seconds)
22:18:16		Quit benedikt93 (Quit: Bye ;))
22:26:08	TheSeven	that nasty hard drive doesn't even comply to the ce-ata standard!
22:28:03		Join kugel [0] (~kugel@109.250.215.127)
22:28:04		Quit kugel (Changing host)
22:28:05		Join kugel [0] (~kugel@rockbox/developer/kugel)
22:29:11		Quit saratoga (Quit: Page closed)
22:32:39	TheSeven	damn, there doesn't seem to be a way to determine if the drive is safe to power off :/
22:32:49	TheSeven	it keeps BSY asserted while it's spun down
22:33:06		Join factor [0] (~factor@75.108.68.114)
22:33:31		Quit Jerom (Quit: Leaving.)
22:35:13	TheSeven	and it asserts RDY all the time
22:35:48	jhMikeS	pin misconfig of some sort? (random guessing)
22:56:44		Quit wodz (Quit: Leaving)
22:57:09		Quit FBI_Guy (Read error: Connection reset by peer)
23:00
23:05:32	TheSeven	jhMikeS: no, it turned out I get an IRQ when it's ready (or actually about half a second after that)
23:07:00	TheSeven	ok, my emcore ce-ata driver seems to work. but integrating that into rockbox isn't going to be easy :/
23:07:31		Join milk [0] (~milk@94-193-93-226.zone7.bethere.co.uk)
23:08:15		Quit Judas_PhD (Quit: This is a quitting message)
23:10:42	TheSeven	any ideas?
23:10:58	TheSeven	if i try to integrate it straight forward, we'll end up with an ifdef hell in ata.c
23:11:39	TheSeven	implementing it as a separate driver isn't really good either, as they're mutually exclusive
23:21:51	jhMikeS	no idea really since I'm rather clueless on the necessities atm (should probably see emcore one)
23:22:47	TheSeven	jhMikeS: http://websvn.freemyipod.org/filedetails.php?repname=freemyipod&path=%2Femcore%2Ftrunk%2Ftarget%2Fipodclassic%2Fstorage_ata.c
23:23:11	TheSeven	search for "if (ceata)"
23:24:59		Join user890104 [0] (Venci@venci-notebook-lan.ipv6.6bez10.info)
23:27:40		Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com)
23:31:59		Quit mystica555_ (Read error: Connection reset by peer)
23:34:10		Quit Llorean (Read error: Connection reset by peer)
23:35:01	jhMikeS	function pointer table concealed by the storage wrappers?
23:36:47	jhMikeS	or some sort of thing to plug the other thing in on the fly if that's what you need shrugs
23:40:46	***	Saving seen data "./dancer.seen"
23:50:17		Join einhirn [0] (~Miranda@p548504F0.dip0.t-ipconnect.de)
23:52:09		Quit Stummi (Quit: Bye!)
23:52:10		Join einhirn_ [0] (~Miranda@p548504F0.dip0.t-ipconnect.de)
23:54:48		Quit einhirn (Ping timeout: 260 seconds)

Previous day | Next day