--- Log for 19.02.111 Server: calvino.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 1 day and 20 hours ago 00.00.03 # yes, it definitely is on microblaze for sure. 00.00.06 # 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 # neither of which are relevant for us 00.00.24 # since we're single-process without mmap :) 00.00.41 # relocatable code is the opposite of PIC code in most ways :) 00.01.36 # 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 # 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 # 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 # New commit by 03kugel (r29328): Fix yellows and checkwps. 00.22.15 # r29328 build result: 905 errors, 124 warnings (kugel committed) 00.24.10 # strange 00.25.16 # firmware including apps header :\ 00.26.03 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 00.28.39 # where ? 00.29.15 # New commit by 03kugel (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 # 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 # r29329 build result: 656 errors, 0 warnings (kugel committed) 00.33.43 Join Jerom [0] (~jerome@79.132.59.245) 00.33.53 # getting better ;) 00.34.26 # meh, I checked checkwps 00.34.38 # Probably not high score material this time 00.34.42 # You hope. ;) 00.34.54 # ah, h300 checkwps is fine but others aren 00.34.56 # 't 00.35.00 Quit factor_ (Quit: Leaving) 00.35.17 Join factor [0] (~factor@75.108.68.114) 00.36.22 # 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 # Strife89: scores don't add up 00.38.32 # Ah. 00.40.05 # 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 # at least I keep introducing new reds instead of overlooking :) 00.49.58 # o noh, this was overlooking 00.50.21 # * TheSeven wants FS#11917 to be fixed, but can't make it work :/ 00.52.20 # Torne: regarding PIC vs. relocatable: you might want to have a look at how i implemented it in emCORE 00.52.42 # i hacked up elf2flt quite a bit and wrote a loader for that 00.52.57 # what did you need to hack it for? 00.53.00 # this error is strange 00.53.05 # TheSeven: i can provide more information on the issue i reported, if needed 00.53.35 Quit maxsin (Quit: Leaving.) 00.54.02 # 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 # 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 # i let the linker do the linking now, and elf2emcoreapp just generates the relocation data and header 00.55.39 # 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 # i now just pass --emit-relocs to ld, and transform the relocation information into the FLT format 00.56.12 # HAVE_CORELOCK_OBJECT is still defined but for some reason it's not seen in thread.h anymore 00.56.42 # (and commented out half of elf2flt, as it doesn't need to handle all that complex symbol resolving stuff) 00.57.03 # well, that sounds useful :) 00.58.00 # 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 # makefile.in and configure.in had some nice bugs 00.58.30 # ah, I see it now 00.58.49 # kugel: There's a #ifdef CPU_PP before it 00.59.05 # what i still don't fully understand is what the matter with that bfd.h file is 00.59.10 # the corelock definition is now within #ifdef ASSEMBLER_THREADS 00.59.28 # 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 # it's kinda nasty that rockboxdev.sh throws it away after compiling, while elf2flt needs it 01.00.37 # elf2flt is part fo the extended gcc suite, no? 01.00.46 # so the "natural" way is to unpack it into the same place 01.00.50 # and then everything is there :) 01.01.00 # libbfd isn't really meant to be used outside gcc 01.01.01 Quit maxsin (Ping timeout: 240 seconds) 01.01.12 # doing it that way has never ever worked for me though 01.01.15 # with anything :) 01.01.36 # doing it which way? 01.01.43 Part toffe82 01.01.56 # having binutils, gcc, libc, etc all sharing a single source dir 01.02.07 # so that a single configure/make/make install does the lot 01.02.08 # 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 # elf2flt is also derived from gcc and friends and thus is able to work the same way 01.02.52 # 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 # 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 # they stay as far away from libbfd as they possibly can, generally 01.03.51 # i can't think of an example of such a tool right now, but i found one some weeks ago 01.03.54 # becaue it's an insane nightmare world 01.04.11 # people tend to use elflib or whatver it's called 01.04.21 # because its API isn't so terrifyingly and unnecessarily generic 01.04.50 # it's slightly frightening that elf2flt uses bfd :) 01.05.21 # 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 # libbfd.a* 01.05.41 # right. i have no idea how the "right" way is 01.05.44 # perhaps elf2flt plan to work on something else than elf ;) 01.05.51 # other than to suspect that they might expect you to do it with a unified sourcetree 01.06.13 # the docs for all that are atrocious 01.06.13 # well, their configure wants a --with-binutils-build-dir=/whatever 01.06.28 # right, but toplevel configure will probably provide that if it's unified 01.06.45 # since with a unified build everything gets built without anything needing to be installed 01.06.53 # and so the components need to know where each other are 01.07.40 # 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 # since *all* these things have copies of all the toplevel stuff 01.08.05 # and it does seem you are expected to just let htem overwrite each other :)9 01.08.26 # hm 01.08.33 # is llvm better regarding that? 01.08.45 # never tried 01.09.02 # nobody actually seems to build toolchains this way 01.09.11 # New commit by 03kugel (r29330): Cleanup preprocessor around corelock usage and move its definition outside #ifdef ASSEMBLER_THREADS 01.09.11 # even though all the actual docs for the relevant packages tend to imply that's how it's done 01.09.25 # but gcc is getting on my nerves because of other things as well 01.09.27 # TheSeven: llvm is really nice to build 01.09.45 # (apart that it takes gigabytes of disk :-/) 01.09.51 # 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 # 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 # 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 # thomasjfox: sdl threads don't use DEFAULT_STACK_SIZE 01.11.59 # 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 # thomasjfox: it shouldn't need changes from maemo, sigaltstack uses bigger stacks (MINSIGSTKSZ+0x3000) 01.13.47 # kugel: I want to try ASSEMBLER_THREAD again ;) 01.13.50 # 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 # what is yagarto ? 01.14.16 # kugel: Maybe the crashes on database init were related to the recent uninitialized vars fixes on metadata parsing 01.14.25 # 0x1000 works for android but I don't know for maemo 01.14.29 # r29330 build result: All green 01.14.31 # pamaury: the new name of the gnuarm-win32 toolchain 01.14.44 # kugel: Congratulations! 01.14.51 # \o/ 01.14.59 # finally :) 01.15.00 # 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 # kugel: Database rebuilt worked with ASSEMBLER_THREADS 01.19.08 # interesting 01.19.16 # I suspected it was a compiler bug 01.19.28 # kugel: I have to do a full .deb package rebuild, it segfaults on playback (codec load) 01.19.52 # Though that segfault is probably just a mismatch of defines during compile time 01.21.52 # TheSeven: can yagarto build rockbox? 01.22.58 # fwiw, I don't think yagarto makes smaller code, but rather the newer gcc version 01.31.11 # kugel: SIGALTSTACK and SDL_THREADS are working here. Testing ASSEMBLER_THREADS with full rebuild next 01.32.09 # New commit by 03thomasjfox (r29331): N900: Prevent stuck up/down keys on systems with shared up/down cursor mapping 01.32.46 # kugel: no idea 01.33.27 # kugel: the yagarto version I use has gcc 4.5.0 01.33.52 # (we're using 4.4.4) 01.37.08 # 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 # New commit by 03thomasjfox (r29332): Use SIGALTSTACK in maemo build 01.51.37 # kugel: ASSEMBLER_THREADS still crashes on playback. Compiler bug ;) 01.52.07 # tried upping the stack size? 01.52.22 # 0x1000 like android 01.52.30 # ok, one more try with 0x10000 01.53.21 Quit mudd1 (Ping timeout: 250 seconds) 01.54.30 # r29332 build result: All green 01.55.05 Quit Jerom (Quit: Leaving.) 01.57.36 Quit sideral (Quit: Leaving.) 01.58.29 # 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 # alright, so stick with sigaltstack I'd say 02.01.06 # exactly :) 02.01.18 Quit liar (Quit: Leaving) 02.02.01 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 02.02.06 # 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 # kugel: Unfortunately it doesn't add this offset to the touchscreen surface, so the current cabbiev2 port is not usable 02.03.12 # kugel: What should we do here? Add a close/switch window button? Custom theme? 02.03.50 # perhaps you can modify the lcd driver to translate the offset so that it cuts off at the top? 02.05.45 # kugel: looks like I was wrong, "touching" the items in the main menu is exactly the touched position 02.06.08 # kugel: So it's just the WPS that sucks for now because all the playback controls are at the bottom 02.06.38 # can you hide the statusbar at runtime? 02.06.59 # i.e. show it in the main menu, hide in the wps? 02.07.18 # not that I know of 02.07.28 # That would be the difference between windowed/fullscreen mode 02.07.34 # I could make this switchable 02.08.34 # 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 # New commit by 03kugel (r29333): Android: Rewrite lcd subsystem to use the SurfaceView API. ... 02.18.01 # r29333 build result: All green 02.26.48 # New commit by 03kugel (r29334): Correct setServiceActivity implementation 02.30.54 # r29334 build result: All green 02.31.46 # New commit by 03kugel (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 # r29335 build result: 4 errors, 0 warnings (kugel committed) 02.37.44 # strange error 02.38.02 # Bagder: ^ ? 02.45.12 # New commit by 03thomasjfox (r29336): Add missing cabbiev2 800x480 backdrop 02.48.53 Quit MethoS- (Remote host closed the connection) 02.49.05 # r29336 build result: 4 errors, 0 warnings (thomasjfox committed) 02.50.13 # New commit by 03gevaerts (r29337): Add storebror-daniel to blockedclients 02.59.20 Join mystica555 [0] (~Mike@m3e2636d0.tmodns.net) 03.13.32 Join milk [0] (~milk@94-193-93-226.zone7.bethere.co.uk) 03.15.59 # gevaerts: aha, the error actually says what to do 03.19.10 # New commit by 03kugel (r29338): Explicitely add -lpthread to the linker command for the new sigaltstack threads. 03.19.30 # 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 # New commit by 03gevaerts (r29339): Remove storebror-daniel from blockedclients again 03.21.01 # 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 # kugel: I'm not actually sure if doing this sort of threading changes is a good idea during a freeze 03.21.19 # particularly, "stop". 03.21.47 # gevaerts: it doesn't affect any released target, so 03.22.02 # kugel: it seems to affect simulators of released targets 03.22.12 # 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 # r29338 build result: All green 03.25.57 # I don't mind if it's (temporarily) reverted if you feel unhappy with it 03.27.08 # How sure are you that this doesn't affect any of the simulator builds like e.g. cygwin? 03.27.47 # cygwin builds are alread broken afaik. 03.27.51 # (for sims) 03.28.10 # or mingw 03.28.10 # ah, no...wait...I'm thinking SDL. 03.28.13 # 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.06.25 # Do we build simulators of releases? 04.10.59 # seems so. 04.11.05 # http://rasher.dk/rockbox/simulator-release 04.11.34 # (linked from the daily sims page) 04.12.05 # 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 # 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.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.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.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.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.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.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 # [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 # 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 # Zagor: If you mst move it albumart.c is far better than the skin engine 10.36.27 # kugel: does RaaA now require 2.3? 10.36.42 # 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 # 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 # 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 # 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 # you can also supply --sdl-threads to configure to have the old behavoir 10.55.35 # 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 # as I said, I actually planned to wait but forgot about it. I 10.56.38 # I'm not opposed to reverting 10.57.21 # although it'd be a slight pita due to the post commits :) 10.57.36 # yes, I guessed that :) 10.59.34 Join jaykay1 [0] (~Jaykay@p5DC57B97.dip.t-dialin.net) 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 # AlexP: http://pastie.org/1581793 should revert it 11.10.41 # (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 # 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 # and then revert the revert after branching? :) 11.22.33 Join webguest74 [0] (www-data@giant.haxx.se) 11.23.10 # The new thread code is playing fine next to me ;) 11.23.39 # alright, I take it as that we officicially care about simulators for releases as well? 11.23.39 # kugel: Well as I say, I give way to you on whether it is necessary :) 11.23.44 # Maybe just default to SDL threads for compatibility reasons in 3.8? 11.23.45 Quit webguest74 (Client Quit) 11.24.01 # kugel: This is it, I'm not sure - we don't officially release any 11.24.19 # I don't think we've really thought about it before 11.24.51 # * AlexP is in two minds :) 11.24.53 # 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 # IIRC gevaerts said to wait for AlexP. Deadlock? 11.26.03 # he did, but I meant to discuss it :) 11.26.51 # kugel: What about sticking to SDL threads as default for the release? That shouldn't change behavior? 11.27.19 # what release? we don't release simulators :) 11.30.44 # kugel: I was just thinking how we can get back the old behavior without reverting your lovely new code 11.31.20 # I think in this case we can probably leave it 11.31.34 # We don't release sims, and there is the flag if needs be 11.31.43 # But I'll conflab with gevaerts 11.35.25 # 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 # kugel: Just ran the sigaltstack stuff in valgrind. Any idea about this? http://pastie.org/1581841 11.39.52 # kugel: Ah, forget it 11.40.05 # 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 # 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 # 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 # kugel: Do you know how valgrind works? 11.43.25 # no 11.44.06 # 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 # In fact, it checks all memory accesses 11.44.32 # It examines how a program behaves at runtime 11.44.57 # That's how I found out the uninitialized vars issue Buschel recently fixed 11.45.20 # 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 # thomasjfox: I get Thread creation failed. "Retryingmake_context(): Operation not permitted" in valgrind 11.53.32 # the first " should be before Thread 11.53.35 # kugel: Which valgrind version? 11.53.51 # valgrind-3.6.0.SVN-Debian 11.54.36 # should be fine 11.54.49 # let me take a close look at the output 11.55.30 Quit Kitr88 (Ping timeout: 260 seconds) 11.55.32 # works-for-me(mt) 11.55.50 # Still get the invalid write though as mentioned on pastie 11.55.57 # 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.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 # 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 # "Thread creation failed. Retrying" comes from valgrind, "make_context(): Operation not permitted" comes from rockbox 12.02.55 # so one of those library calls is not allowed within valgrind and valgrind detects that we try to make threads 12.03.21 # ah no wait, the "Thread creation failed. Retrying" also comes from rockbox 12.03.35 # I don't get any of those error messages, it just hangs 12.04.42 # kugel: ah, now I get it too with a sim build 12.04.49 # kugel: Doesn't happen with the SDL app build 12.05.51 # kugel: yea, the default app build stubs DEBUGF() 12.05.55 # thomasjfox: ^ 12.05.59 Join inox [0] (www-data@giant.haxx.se) 12.06.41 # hello 12.07.25 # thomasjfox: sigaltstack() fails within valgrind 12.08.24 # inox - hello 12.08.47 Quit inox (Client Quit) 12.08.54 # 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 # hello 12.10.48 # 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 # kugel: See http://www.rockbox.org/tracker/task/11952 ? :) 12.21.46 # kugel: do you have a standalone / development version of the ucontext stuff? 12.22.00 # yes, somewhere 12.22.03 # kugel: The example found here http://evanjones.ca/software/threading.html works fine in valgrind 12.22.24 # kugel: The example under "figure 3" 12.23.55 # kugel: oh, the example in "figure 4" doesn't. I'll ask the valgrind poeple about it 12.24.05 # thomasjfox: figure 4 uses makecontext, we don't 12.25.06 # 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 # kugel: my rpm spec file first does "make check" 12.27.28 # kugel: and then "make regtest" 12.27.47 # alright, trying that. it has a sigaltstack test 12.29.41 # stack_switch: valgrind -q ./stack_switch 12.29.41 # *** stack_switch failed (stderr) *** 12.31.12 # but the sigaltstack test run fine 12.31.30 # kugel: is stack_switch your implementation? 12.31.36 # no 12.33.42 Join esperegu_ [0] (~quassel@145.116.10.163) 12.34.30 # 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 # 64 12.34.44 Quit GeekShadow (Remote host closed the connection) 12.34.54 # me too. maybe that's the issue? 12.35.03 Quit esperegu (Ping timeout: 276 seconds) 12.35.38 # anyway, I didn't notice anything unusal with your sigaltstack code, playing for hours now. So it's fine :) 12.41.44 # 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 # kugel: Stupid question: Did you run "make install"? It looks for some components at runtime 12.43.37 # yea 12.43.47 # I installed into /bin 12.45.00 # aha, strace shows it looks in /usr/local/lib 12.45.00 # 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 # oha 12.45.30 # kugel: In fact, how does rockbox cope with 64bit?? 12.45.42 # kugel: Shouldn't we force gcc to 32bit? 12.45.53 # we have 64bit sims for years without problems 12.45.57 # ok 12.48.17 # thomasjfox: does the 32bit valgrind also work with a 32bit sim? 12.48.38 # is there an easy way to compile a 32bit sim? 12.49.17 # don't know 12.49.34 # I assume specifying the 32bit cross compiler gcc should work 12.50.24 # I added the -m32 and --target to simcc. Lets see how that goes 12.50.39 # configure sees $CROSS_COMPILE 12.53.28 # thomasjfox: valgrind's testcase is slightly different 12.54.02 Join MethoS- [0] (~clemens@134.102.106.250) 12.55.17 # thomasjfox: I sent you my standalone code 12.55.39 # kugel: checking 12.56.21 Quit casainho (Ping timeout: 246 seconds) 12.58.40 # modifying the test case to use a static stack, instead of a mmap'd one also works 13.00.24 Join maxsin [0] (~maxsin@188-115-150-221.broadband.tenet.odessa.UA) 13.02.43 # kugel: Sent you the output 13.03.14 # well, it's a different error 13.04.27 # the manpage says [EPERM] An attempt was made to modify an active stack. 13.06.56 # kugel: Sent you another output with "--track-origins=yes". 13.07.03 # kugel: Looks bogus to me 13.07.17 Join DerPapst [0] (~Alexander@p5DE5B48B.dip.t-dialin.net) 13.07.56 # I don't know what these messages mean 13.10.45 Quit maxsin (Ping timeout: 260 seconds) 13.12.29 # thomasjfox: can it possibly have something to do with the multithread environment? 13.14.32 # 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 # kugel: Let me try that with 64bit code again 13.22.18 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 13.24.59 # 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 # [Saint]: can you try building a sim on cygwin? 13.35.25 # kugel: I'd say valgrind is currently not compatible with sigaltstack 13.35.28 # (FS#11952) 13.35.35 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 13.35.42 # thomasjfox: this and 64bit :) 13.36.01 # I can get valgrind to segfault 13.36.19 # kugel: run valgrind on valgrind :o) 13.37.49 # 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 # soap, AlexP, scorche: please ban dfhjkh54 in the forums 13.52.09 Quit hebz0rl (Quit: Leaving) 13.53.44 # pixelma: done 13.54.00 # thanks 13.57.41 Join maxsin [0] (~maxsin@188-115-150-221.broadband.tenet.odessa.UA) 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.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 # AlexP, kugel: I don't really agree that we don't release simulators 15.14.26 # We don't release simulator *builds*, but we do release source that is expected to build working simulators 15.14.55 # true enough 15.15.01 # So if simulators have a serious bug, I'd definitely see that as a reason for a point release 15.15.41 # Anyway, seeing as cygwin simulators don't currently build with thread errors, I'd say revert it. 15.20.04 # AlexP: I'm quite certain Buschel just didn't make reconf 15.20.19 # ah, OK 15.20.28 # well, someone on cygwin needs to test :) 15.20.30 # 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 # someone on cygwin just needs to confirm 15.20.38 # pixelma: OK, thanks 15.20.40 # hehe :) 15.20.42 # *built 15.20.48 # score 1 for kugel's intuition :) 15.21.09 # thought he would get a notification mail... 15.26.54 # i just built a sim build on cygwin, seems to work fine. 15.27.17 # although I've not been following the convo so maybe something more subtle than 'it just works for me' ? 15.28.17 # 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 # 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 # jhMikeS: in tick_start 15.40.34 *** Saving seen data "./dancer.seen" 15.41.24 # wouldn't that be by the main thread? 15.41.49 # of course maybe this doesn't work like I remember :) 15.41.53 # yes, the same thread that calls wait_for_interrupt() 15.41.56 # 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 # My thoughts too 15.42.24 # tomorrow is probably cleaner if nothing else touches it before then 15.44.39 # kugel: wait, but what about around the SDL_CondSignal? 15.46.28 # jhMikeS: why should it grab the lock before signalling? 15.46.57 # I believe it's supposed to by design 15.47.45 # I understood it differently 15.48.00 # and it wouldn't work if nothing is waiting on the condition 15.49.22 # semaphore is probably a simpler solution 15.50.52 # 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 # jhMikeS: you can lock if you desperately want to avoid races, but it's not critical in this case 16.00.16 # so I rather chose to make wait_for_interrupt a bit cheaper 16.02.25 # 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 # do arm core have something like a performance counter or similar ? (arm 920t precisely) 16.04.03 # looks safe for the object anyway if not using it for data protection 16.04.52 # yea, we use it exclusively to not hog the cpuö 16.04.57 # cpu* 16.08.21 Join Buschel [0] (~chatzilla@p54A3A86B.dip.t-dialin.net) 16.09.15 # 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 # Buschel: what are your results? 16.31.10 # looks good, build finished in this very second 16.31.22 # so, my apologies. I will close the report 16.31.30 # no problem :) 16.36.24 # AlexP: RHCC wants banning 16.37.16 # done 16.41.59 # New commit by 03Buschel (r29340): FS#11950: Update czech language file. 16.46.01 # r29340 build result: All green 16.49.22 # 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.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 # New commit by 03kugel (r29341): Android: Fix some race conditions and crashes on startup. 17.44.38 # kugel: I was getting segfaults in mpegplayer but not before the change. Will that take care of that? 17.45.08 # jhMikeS: mpegplayer crashes? 17.46.32 # I reverted to r29326 and it played ok, r29340 was segfaulting when loading movie 17.47.11 # r29341 build result: All green 17.47.27 # sdl sim on debian btw 17.49.20 # jhMikeS: I'm assuming stack overflow 17.49.31 # they don't use DEFAULT_STACK_SIZE 17.49.54 # that always had phony stacks 17.50.11 # or is that different now? 17.51.29 # yes 17.51.52 # 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 # jhMikeS: http://pastie.org/1582725 helps 18.00.44 # 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 # but what if default stack size is negative? :) 18.08.31 # then we're indeed in trouble :) 18.10.12 # hmmm...not enough stack to even get past the splash in gdb for the fun of it 18.12.18 # New commit by 03kugel (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 # 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 # 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 # 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 # works fine on android 18.48.23 Quit esperegu_ (Read error: Operation timed out) 18.50.44 # 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.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 # 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 # \☺/ 19.59.53 # Now play music from it! 20.00.04 # well, it's not *that* far away 20.00.40 # but there seem to be some timing peculiarities :/ 20.02.12 # The MBR is in some odd meter like 7/8? 20.03.07 # :) 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 # there's exactly one upside of CE-ATA: everything is DMA LBA48 :) 20.09.05 # gevaerts seemed to be suggesting to play music from the MBR :P 20.09.55 # anyway, why's a build with thumb whining about intptr_t but a non-thumb build makes fine :\ 20.10.36 # sounds like yet another ifdef fuckup? 20.11.01 # question of the century, when there's no obvious #ifdef around 20.13.20 Quit stoffel (Ping timeout: 276 seconds) 20.17.02 # 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 # jhMikeS: like a factor of 1.5? 20.31.30 # 1.04 this time actually 20.33.44 # hm, integrating ce-ata support into the rockbox ata driver isn't going to be easy 20.33.53 # 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 # jhMikeS: does that patch you posted build for you? 20.47.47 # 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 # stupid question - how to simulate memcpy result in IDA? I mean copy some portion of memory into other address 20.54.41 # saratoga: what's the issue? there's also an update coming 20.55.00 # jhMikeS: it can't find intptr_t in codec_thread.h 20.55.06 # which header includes that? 20.55.38 # for a thumb build? I just added system.h to codec_thread.c and playback.c 20.56.11 # inttypes.h I think is the main one though 20.56.37 # i'll try including that and see if it builds 20.57.50 # I'll have a new patch in a few anyway since there was a codec change snafu 20.58.29 # ok cool 20.59.19 # i skimmed that patch, but really didn't understand how half that stuff worked to begin with 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 # the rest seems designed by some genetic algorithm 21.08.04 # are you trying to build in thumb? 21.12.15 # the clip does build in thumb 21.12.23 # it does? 21.12.33 # should i apply both those patches? 21.12.51 # yeah, for the full effect :) 21.13.18 # the two I *just* posted of course 21.15.25 # 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 # 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 # 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 # 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 # good job then 21.30.24 # i don't seem to be able to get it to mess up now on the clip+ 21.36.06 # woah just managed to get it to skip to a different folder 21.36.10 # thats a little weird 21.36.54 # what patch/FS# are you guys talking about? 21.37.10 # FS#11863 - Playback / buffer freezes 21.37.45 # is rockbox expect to skip folders if skip a few times, then hold the forward button down (as if to seek)? 21.37.53 # not sure if this is a bug or a feature 21.38.19 # saratoga: I've hit folder skip by accident too 21.38.29 # ah so its supposed to do that? 21.38.31 # short then long = folder skip 21.38.52 # yeah ok 21.38.55 # so no issues then 21.39.02 # wodz: there are multiple ways 21.39.32 # 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 # you can also rewrite memcpy using Dword() and PatchDword() in IDC 21.39.50 # 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 # 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.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 # 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 # damn, there doesn't seem to be a way to determine if the drive is safe to power off :/ 22.32.49 # 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 # and it asserts RDY all the time 22.35.48 # 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.05.32 # jhMikeS: no, it turned out I get an IRQ when it's ready (or actually about half a second after that) 23.07.00 # 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 # any ideas? 23.10.58 # if i try to integrate it straight forward, we'll end up with an ifdef hell in ata.c 23.11.39 # implementing it as a separate driver isn't really good either, as they're mutually exclusive 23.21.51 # no idea really since I'm rather clueless on the necessities atm (should probably see emcore one) 23.22.47 # jhMikeS: http://websvn.freemyipod.org/filedetails.php?repname=freemyipod&path=%2Femcore%2Ftrunk%2Ftarget%2Fipodclassic%2Fstorage_ata.c 23.23.11 # 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 # function pointer table concealed by the storage wrappers? 23.36.47 # 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)