--- Log for 07.05.110 Server: jordan.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 12 hours and 16 minutes ago 00.02.15 # including it in file.h gives sim_sleep() problems :\ 00.03.06 Quit CGL (Remote host closed the connection) 00.04.59 # what do I need to link for filesize()? 00.05.55 # uisimulator/common/io.c has sim_filesize() 00.06.06 # hm, I see 00.06.39 # kugel: heh, what's going on? I can't seem to build anything after updating. :D 00.06.56 # downgrade :P 00.07.22 # * jhMikeS turns upside-down (to keep it "up") 00.07.36 # jhMikeS: *anything* is a bit of an overstatement. Just about everything except gigabeat S builds aghain! 00.08.15 # r25854 was bad for the database 00.08.26 # that's exaggerating too 00.08.42 # gevaerts: of course, that's what I'm building. I think kugel had it out for beast enthusiast from the start. 00.10.38 Quit ender` (Quit: The sum of intelligence on the planet is a constant; the population is growing.) 00.12.05 Join Farthen [0] (~Farthen@static.225.178.40.188.clients.your-server.de) 00.13.56 # New commit by 03gevaerts (r25855): Fix gigabeat S includes so it builds again 00.13.59 # jhMikeS: have fun 00.14.29 Join JohannesSM64 [0] (~johannes@cm-84.215.75.42.getinternet.no) 00.14.38 # * gevaerts claims that gigabeat S only built by accident previously 00.14.48 # kugel: thank you :) 00.15.05 # * jhMikeS is also having fun 00.15.52 # I'm confused about tools/database/Makefile 00.16.23 # gevaerts: checkwps 00.17.05 # jhMikeS: doesn't that build? 00.17.37 # New commit by 03kugel (r25856): Revert r25854 which was bad for the database tool (I forgot it still needs the wrappers from uisimulator/common/io.c). Fix it so it works for both. 00.17.53 # gevaerts: gbs checkwps is what built (or /me thinks it's a little sarcasm about the port :D) 00.18.45 # eh, what a bad c&p error 00.18.50 # jhMikeS: by previously I meant before kugel got busy today :) 00.19.35 # this variety of errors is somewhat exciting to fix but it also makes me nervous :P 00.21.04 # * jhMikeS recalls hitting some very high scores after doing recording updates 00.21.19 # kugel: I think the remaining ones are trivial 00.22.50 # New commit by 03kugel (r25857): Fix c&p error from r25853 that should've fixed some snprintf warnings. 00.24.56 # gevaerts: those can just stay, it spices up the garish greenness 00.25.42 # * gevaerts still wants to write some text on the build table using a carefullt crafter series of commits 00.27.14 Quit grndslm (Quit: Leaving) 00.29.54 # funny how this c&p tradition leads to every lcd driver having a variable of the type off_t :) 00.31.19 Quit joeyg (Quit: work-->home) 00.31.35 # Yes, and all without the proper matching include :) 00.32.37 # it makes no sense to use off_t but hey the others do it too :P 00.32.56 # hopefully it will annoy kugel in the future ;) 00.33.17 # gevaerts: in fact, I replaced the correct define by the wrong one for half of them 00.33.37 # I switched it back, but I overlooked some when looking through this *huge* diff 00.33.44 # s/define/include/ 00.34.00 # New commit by 03kugel (r25858): Fix the remaining reds. 00.34.49 # so, I have no idea about the strict-aliasing warnings 00.35.03 # I thought we had turned those off in the main build & plugins 00.38.40 # still some snprintf and friends left 00.40.01 # one, yes 00.40.22 Quit dfkt (Ping timeout: 240 seconds) 00.40.36 # kugel: ah, type-punning? 00.40.56 # kugel: player also has some 00.41.13 Join dfkt [0] (~dfkt@unaffiliated/dfkt) 00.41.48 # gevaerts: refresh? :) 00.42.38 # ah, right 00.43.06 # jhMikeS: do you have an idea? 00.43.26 # huh, weird 00.43.36 Quit robin0800 (Remote host closed the connection) 00.45.11 # tools/configure clearly deactivates this warning for gcc 4.0.1 or newer 00.45.33 Quit dfkt (Ping timeout: 240 seconds) 00.45.34 # no, 4.1.0 or newer 00.46.14 # kugel: idea how? 00.46.59 # gevaerts: oh 00.47.12 # jhMikeS: the type-punning warnings 00.47.35 # I know the technicality, not why they'd show up if it's disabled :\ 00.48.21 # hm, I guess because somehow our size_t handling changed? like how it now created warnings with snprintf 00.48.43 # jhMikeS: it appears I was wrong and they're only disabled for 4.1.x 00.49.11 # How did size_t change? 00.50.13 # buffer_size is ssize_t, not size_t. it doesn't like the conversion of the address-of to another type of addres-of 00.50.15 # no idea, I only moved it to string.h 00.50.55 # and changed the defines that guard against redefining a bit 00.51.14 # * jhMikeS made a PUN_PTR macro which convers it to uintptr_t first when he got too annoyed 00.51.20 Join dfkt [0] (~dfkt@unaffiliated/dfkt) 00.52.40 # Where was it before? 00.52.50 # sys/types.h 00.53.27 # (which was wrong) 00.53.57 Join loveless [0] (~loveless@188-195-101-189-dynip.superkabel.de) 00.54.42 # New commit by 03kugel (r25859): Fix last sprintf warning. 00.54.53 # right 00.55.18 # The compiler defines it in stddef.h 00.55.58 # or at least it might 00.57.10 # it seems iso c defines it in both 00.57.16 # according to wikipedia 00.59.15 # ok, if I change string.h to only include stddef.h *after* defining size_t, it works 00.59.39 # a bit too magical for my tastes though 01.00.22 Quit Luca_S (Quit: CGI:IRC (EOF)) 01.00.52 # err, really? 01.01.49 # yes, at least for the player 01.02.05 # my stddef only contains the NULL definition 01.02.23 # (my /usr/include/linux/stddef.h) 01.02.55 # sh-elf/lib/gcc/sh-elf/4.0.3/include/stddef.h 01.04.06 Nick Unhelpful_ is now known as Unhelpful (~quassel@rockbox/developer/Unhelpful) 01.05.52 # sh-elf/lib/gcc/sh-elf/4.0.3/include/stddef.h 01.05.54 # oops 01.07.27 # kugel: actually, why does string.h include stddef.h? 01.07.50 # dunno, that was there before. probably because the guy who did it knew that size_t is there 01.08.38 # Possibly 01.08.50 # "This is my initial attempt to get rid of the newlib headers requirement, for gcc built without newlib." 01.09.40 Join grndslm [0] (~grndslm@174-126-14-4.cpe.cableone.net) 01.09.46 # New commit by 03gevaerts (r25860): string.h shouldn't include stddef.h 01.11.00 # maybe he needed size_t for the string and mem functions and didn't know that size_t actually needs to be defined here too 01.11.16 # does that fix the problem? 01.11.36 # for the player, yes 01.12.12 Quit dfkt (Read error: Connection reset by peer) 01.12.56 # ok, some new yellow 01.13.01 # it's also strange it hit only sh 01.14.22 # err 01.14.44 # that are the ones I changed to %zu a few commits back 01.14.47 # yes, it's another fun one 01.14.49 # you toggled some compiler magic 01.14.55 # * gevaerts has a suspicion 01.15.36 Join ishottuify [0] (~4c422e86@giant.haxx.se) 01.16.35 # can someone help me figure out the different parts on a pcb...? 01.16.53 Join apoelstra [0] (~apoelstra@S010600236999fec1.vs.shawcable.net) 01.17.40 # the pcb for philips gogear sa52xx >> http://www.rockbox.org/wiki/GoGearSA5245_SA5285 01.20.27 # gevaerts: ah, #define size_t size_t is the culprit how I think 01.21.28 # kugel: yes, you'd think so :) 01.21.49 # but it isn't :/ 01.22.19 # #include fixes it 01.22.26 # * gevaerts doesn't understand this! 01.23.24 # not for me 01.23.26 # I have this suspicion that the %z thing cheats by knowing which particular typedef was used 01.23.46 # Even if you have another one that's *identical*, it doesn't see that as size_t I think 01.23.49 # I think so too 01.24.05 # I already tried to define _SIZE_TYPE_ but I got lots of redefined errors 01.25.04 # it doesn't kill the warnings too 01.31.04 # yea, only including stddef.h fixes it 01.31.14 # maybe that's the way to go? 01.32.10 # ah no of course not, it bringes the strict-antialiasing thing back 01.32.47 Quit DerPapst (Quit: Leaving.) 01.32.52 # there are tricks I think 01.34.03 Part toffe82 01.36.04 # alternatively we could lower the -fno-strict-aliasing rule in configure so that it applies for 4.0.3 as well 01.36.31 Quit JohannesSM64 (Quit: WeeChat 0.3.3-dev) 01.36.40 # I don't understand this at all, and also not why it only applies for sh, but maybe the reason for deactivating existed in 4.0.x already but was just better hidden? 01.42.24 # kugel: I think I'm starting to understand this 01.43.02 # linux string.h gets size_t from stddef.h using some tricks to *only* get size_t and not the rest. That bit is easy to do 01.43.32 # However, if you do that, suddenly you're drowned in dereferencing type-punned pointer will break strict-aliasing rules warnings 01.43.57 # I do think that most of those are real though 01.44.32 Nick apoelstra is now known as joeyg (~apoelstra@S010600236999fec1.vs.shawcable.net) 01.45.11 # the commit message and comment for the existing rule to disable this warnings suggest it would've been preferred to fix the code instead so maybe we're doing it wrong 01.45.27 # but still, why is this only for sh 01.46.03 # Most of those warnings ara about having a variable of type ssize_t, and putting a size_t in it 01.46.08 # gevaerts: there must be further magic, copying all the size_t related defines to string.h doesn't help 01.46.16 *** Saving seen data "./dancer.seen" 01.46.49 # kugel: well yes, that's clear. You need the real size_t from stddef.h, which you can get by defining __need_size_t and then including stddef.g 01.47.03 # I think jhMikeS changed it to accept ssize_t, I wonder what the reason for that was? 01.47.25 # If stddef.h had already been included you get nothing new, if it hadn't, you get *only* size_t 01.49.45 Quit MethoS- (Remote host closed the connection) 01.50.03 Join Strife89 [0] (~Strife89@adsl-80-144-24.mcn.bellsouth.net) 01.50.29 # err, it accepts size_t 01.50.39 # (plugin_get_buffer() that is) 01.52.35 # New commit by 03gevaerts (r25861): Use -fno-strict-aliasing on 4.0 as well 01.53.03 # New commit by 03gevaerts (r25862): Define size_t the way the gcc/glibc people intended 01.53.55 # There will be a few more yellows, but those are easy 01.54.00 # gevaerts: I think r25861 isn't needed with r25862 01.54.19 # it is 01.54.43 # ah, so it was the makefile generated by my temporary configure change 01.55.02 # well, it was here unless I'm really too tired 01.55.03 # I think fixing the code might be worthwhile, it's not that much warnings afterall 01.55.38 # Yes, but it requires serious thinking 01.55.53 # and passing ssize_t is clearly wrong.. 01.55.59 # Some are trivial and don't need the signed thing in the first place, but not all 01.57.13 # thanks for your help 01.57.13 Quit antil33t (Read error: Connection reset by peer) 01.57.25 # We're not *entirely* done yet :) 01.58.23 Quit Strife89 (Quit: Rebooting, something's wrong ....) 01.58.35 # New commit by 03gevaerts (r25863): Fix last two yellows 01.59.05 # that was a messy commit :\ 01.59.13 # I mean my c-lib one 01.59.44 # The good news is that we managed to paint the Manhattan skyline 02.00.00 # haha, indeed 02.01.21 Join mikroflops_ [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) 02.01.40 # All green again \☺/ 02.02.00 Join Strife89 [0] (~Strife89@adsl-80-144-24.mcn.bellsouth.net) 02.02.04 # Getting rid of -fno-strict-aliasing again would definitely be good, but not today... 02.02.53 # * kugel needs some sleep as well 02.04.09 Quit krazykit (Read error: Connection reset by peer) 02.04.13 Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) 02.04.43 Quit kugel (Remote host closed the connection) 02.05.21 Quit mikroflops (Ping timeout: 246 seconds) 02.07.27 Quit evilnick_B (Quit: Page closed) 02.09.22 Quit M3DLG (Quit: RAGE QUIT) 02.11.34 Join krazykit [0] (~kkit@adsl-76-251-232-26.dsl.ipltin.sbcglobal.net) 02.22.17 Quit krazykit (Quit: Connection reset by beer) 02.23.11 Join Blue_Dude [0] (~chatzilla@rockbox/developer/Blue-Dude) 02.23.17 Join Buschel [0] (~ab@p54A3F283.dip.t-dialin.net) 02.23.22 # kugel: Found some files you missed that still have #include 02.24.02 Join krazykit [0] (~kkit@adsl-76-251-232-26.dsl.ipltin.sbcglobal.net) 02.24.36 # I'll try to patch it later tonight. 02.25.37 Join aberet [0] (~tty0@70-56-217-228.albq.qwest.net) 02.27.57 # is it normal at this point for the unsupported Clipv2 port to have audible SD read activity and background static? 02.28.40 Join Rob2223 [0] (~Miranda@p4FDC9FB9.dip.t-dialin.net) 02.30.48 Join Strife1989 [0] (~Strife89@adsl-80-144-24.mcn.bellsouth.net) 02.31.34 Quit Rob2222 (Ping timeout: 248 seconds) 02.32.34 Quit Strife89 (Ping timeout: 276 seconds) 02.32.41 Nick Strife1989 is now known as Strife89 (~Strife89@adsl-80-144-24.mcn.bellsouth.net) 02.38.25 Quit panni_ (Read error: Connection reset by peer) 02.43.11 # can someone help me figure out the different parts on the pcb for philips gogear sa52xx >> http://www.rockbox.org/wiki/GoGearSA5245_SA5285 02.48.23 Quit Buschel (Ping timeout: 240 seconds) 02.52.24 Quit loveless (Quit: loveless) 02.54.41 Quit S_a_i_n_t (Ping timeout: 246 seconds) 02.59.04 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.1.8) 03.09.22 Quit ishottuify (Quit: CGI:IRC) 03.18.11 Join hd [0] (~jd@rocket.vel.lv) 03.18.11 Quit hd (Changing host) 03.18.12 Join hd [0] (~jd@Wikipedia/HellDragon) 03.18.17 Quit jd (Read error: No route to host) 03.20.32 Nick hd is now known as jd (~jd@Wikipedia/HellDragon) 03.22.58 Join fdinel [0] (~Miranda@modemcable235.127-131-66.mc.videotron.ca) 03.24.52 Join kadoban [0] (~mud@cpe-67-247-80-129.rochester.res.rr.com) 03.34.12 Quit linuxguy3 (Ping timeout: 252 seconds) 03.35.53 Join linuxguy3 [0] (~timj@adsl-75-57-191-181.dsl.emhril.sbcglobal.net) 03.36.01 Join CGL [0] (~CGL@190.79.147.252) 03.38.55 Join Boldfilter [0] (~Boldfilte@adsl-178-248-46.jax.bellsouth.net) 03.41.09 # ishottuify, the proc is a Telechips TCC8300 which probably includes two arm cores and audio/video decoders 03.42.15 # the big toshiba chip is a nandflash 03.42.21 # and the samsung is dram 03.46.18 *** Saving seen data "./dancer.seen" 03.48.54 Quit hebz0rl (Ping timeout: 246 seconds) 03.50.02 Join hebz0rl [0] (~hebz0rl@dslb-088-067-206-152.pools.arcor-ip.net) 04.03.36 Quit hebz0rl (Ping timeout: 264 seconds) 04.04.06 Join Barahir_ [0] (~jonathan@frnk-590fe003.pool.mediaWays.net) 04.07.15 Quit Boldfilter (Quit: Boldfilter) 04.07.56 Quit Barahir (Ping timeout: 276 seconds) 04.08.23 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.08.23 Quit pixelma (Disconnected by services) 04.08.30 Quit amiconn (Disconnected by services) 04.08.32 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.08.36 Quit nima (Read error: Operation timed out) 04.08.42 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.08.54 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.10.04 Join nima [0] (~nima@adsl-75-45-237-191.dsl.sfldmi.sbcglobal.net) 04.13.50 # New commit by 03Blue_Dude (r25864): Remove last traces of sprintf.h 04.24.40 Quit Rondom (Disconnected by services) 04.24.57 Join Rondom_ [0] (~quassel@dslb-084-057-184-207.pools.arcor-ip.net) 04.25.04 # gevaerts: I get a compile warning in a sim build in uisimulator/common/io.c line 347 04.25.39 # warning: mode_t is promoted to int when passed through (...) 04.26.22 # warning: (so you should pass 'int' not 'mode_t' to 'va_arg') 04.26.41 # note: if this code is reached, the program will abort 04.27.27 # It doesn't show in the build server, so it might be something local. I'll try with (yet another) clean build. 04.29.19 # New commit by 03jethead71 (r25865): i.MX31: Make some style changes to some driver code so that hardware vs. variable access is more obvious to the eye. Change a few data types and ... 04.35.04 # gevaerts: Yep, still there after a clean build. Ideas appreciated. 04.57.36 Join dys` [0] (~andreas@krlh-5f72cab6.pool.mediaWays.net) 04.59.55 Quit dys (Ping timeout: 276 seconds) 05.04.50 Join fleebailey33 [0] (~fleebaile@unaffiliated/fleebailey33) 05.07.48 # jhMikeS: hey, you round? 05.11.14 Join fyre^OS [0] (~nnscript@cpe-68-173-235-128.nyc.res.rr.com) 05.14.19 Quit fyrestorm (Read error: Operation timed out) 05.15.30 # jhMikeS: at what point does the calling thread become unblocked after queue_send()? or it just puts the event on the queue and yields? 05.15.37 # * JdGordon has a suspissoin why his code isnt working 05.20.40 # VICTORY IS MINE! 05.21.14 # New commit by 03Blue_Dude (r25866): Hotkey menu items have their own icon 05.22.15 Quit fdinel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 05.28.30 # Whoa! Look at that delta. That doesn't make a bit of sense. I added maybe one line of code. WTF? 05.29.58 # JdGordon: the thread is unblocked when the receiver replies 05.30.28 # JdGordon: this happens with a queue_reply call or when the next message is dequeued by the thread that owns the queue 05.31.04 # Aw, WTFO? That doesn't make any sense! 05.32.02 # the new icon gets but into the binary 05.32.29 # JdGordon: btw, if you meant the other way, the sender always blocks and a new thread is selected to run via switch_thread. 05.32.39 # jhMikeS: yeah thanks, as soon as the button loop yielded the thread uncblocked :) 05.32.55 # JdGordon: Yeah, but it's a 6x8 bitmap... 05.33.01 # so I just added some trickery and its all good again 05.33.29 # Blue_Dude: 6x8x16... 05.33.48 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 05.34.05 # That's still only 96 bytes. 05.34.08 # yeah :p 05.34.12 # something is not right :) 05.35.23 # Thanks, Capt. Obvious. :) 05.37.32 Quit anewuser (Quit: for SELL 2 by the price of 1 now!) 05.38.49 # Oh, no. The picture edit software I used to update the bitmaps defaults to 24 bit color. 05.38.52 # Oops. 05.39.23 Quit Horscht (Quit: Verlassend) 05.46.22 *** Saving seen data "./dancer.seen" 05.48.03 # New commit by 03Blue_Dude (r25867): Correct bitmap color depth 05.51.46 # Uh, what? 05.51.52 # Grrr 05.53.33 # it only added the huge delta to color targets if I read that correctly 05.58.35 # I'm still confused. Color depth wasn't the issue. The last commit did nothing. 05.59.37 # 432 bytes for the color bitmap. 06.02.43 # One target had a 5000 byte delta. Is there something magical about the bitmap size? 06.03.20 # * Blue_Dude will sleep on it. Tapped out. 06.03.28 Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 06.04.43 Join einhirn [0] (~Miranda@p548512B6.dip0.t-ipconnect.de) 06.14.36 Quit einhirn (Read error: Connection reset by peer) 06.15.00 # New commit by 03jethead71 (r25868): Remove stray function prototype used only for long-ago-removed codec swapping. Function definition was removed when adding internal voice codec. 06.24.58 Nick dys` is now known as dys (~andreas@krlh-5f72cab6.pool.mediaWays.net) 06.50.52 Join bug2000 [0] (~bug@unaffiliated/bug2000) 06.53.23 Quit CGL (Quit: Soy spammero http://wiki.n00b2hack.com.ve ---- \m/ d(>.<)b \m/) 06.57.49 Join Boldfilter [0] (~Boldfilte@adsl-178-248-46.jax.bellsouth.net) 07.00.16 Join Hillshum [0] (~hillshum@75-165-235-147.slkc.qwest.net) 07.04.52 Part Boldfilter 07.30.29 # Shouldn't changes to the default theme at least be discussed before committing? 07.32.19 # they were brought up a few days ago 07.33.31 # That's funny, the patch was posted less than a day ago. 07.33.44 # It has zero comments on it, before committing. 07.34.36 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 07.35.01 # JdGordon: Can you reference me to where in the logs it is? 07.36.19 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 07.42.50 # There were changes to the default theme? 07.43.03 # S_a_i_n_t: The addition of a new icon for hotkeyable items. 07.43.10 # With a considerable binsize increase to boot. 07.43.22 # oh, yeah...yesterday or so. 07.43.36 # yes, I believe it was yesterday. 07.43.39 # That's hardly "a few days ago" then. 07.44.30 # I don't think the icon itself it to blame for the binsize increase...it'll be what 12x12x16? 07.44.46 # a few bytes of .bmp? 07.45.19 # will the icon take priority over the item's other icon - and only if set as hotkey function or also as a marker that this item is hotkeyable (so always)? 07.45.43 # pixelma: Don't know. It sounds like it replaces the icon for all hotkeyable items. 07.45.59 # pixelma: I think any context item that can be hotkeyyed gets it. 07.46.26 *** Saving seen data "./dancer.seen" 07.46.28 # It seems like we should've had some discussion for the look of the new icon (and whether it should even be displayed by default, or be a theme option that doesn't get used in the default theme) 07.46.31 # I'd like something *in addition to* the regular icon myself, not replacing it. 07.46.42 # As well, it surely needs a manual description telling people why a whole bunch of items now have a different icone. 07.46.48 # it will affect the info regarding .icons files in the wiki also 07.46.58 # now we have 32 icons all of a sudden. 07.47.08 # And if the big binsize increase isn't intentional/expected (as per the author's own comment in channel earlier) shouldn't it be reverted for the moment? 07.47.41 # I'm not sure we need a visual indicator whether something can be hotkeyed 07.47.47 # We don't have one for whether things can be used in the quickscreen. 07.47.56 # yeah 07.48.11 # I'd like to be able to perhaps "switch it on/off" to be able to reference hotkeyable items *if I want to* 07.48.16 # It just seems like bloat. People can figure it out very quickly, and they should be able to remember the 3 or 4 they regularly set to it 07.48.19 # perhaps a theme option? 07.48.28 # But it's certainly not worth the size increase currently shown. 07.49.05 # I can't explain the increase...it doesn't seen like a rational increrase for the function 07.49.15 # as I said, the .bmp itself will be tiny. 07.50.14 # Yes, which suggests something may be wrong with the patch. 07.50.40 # The binsize increase is reasonable relative to the image size. 07.50.46 # Most of the increase is in RAM usage 07.52.35 # I think I still would prefer a different more standard ui for it (a list of the hotkey functions inside a "what should the hotkey do" menu). This could only be a problem when the list becomes to long but from the few comments I read yesterday it doesn't seem many things suitable on the hotkey. I didn't like the completely different way to set it from the start (and said so here) 07.52.58 # -typos 07.53.02 # pixelma: I agree. 07.53.21 # Not to mention, you could even add things to the list that might not make sense as menu entries in the future (if such things ever exist) 07.54.35 # I wanted a menu also, but it was idscussed at length...and it was decided (I thought at least) that a menu inside the context menu was a definite NODO 07.54.50 # *discussed 07.55.09 # S_a_i_n_t: Why would it be inside the context menu? 07.55.12 # a context menu in the context menu was a nodo 07.55.21 # You could have the setting anywhere. 07.55.28 # "Hotkey" and then when selected, a list of options. 07.55.32 # Llorean: good point. 07.55.48 Join B4gder [0] (~daniel@rockbox/developer/bagder) 07.55.50 Join Buschel [0] (~ab@p54A3A797.dip.t-dialin.net) 07.57.27 # it being inside the appropriate context menu seemed to make sense to me though, as you have two different context menus to deal with (filetree/wps) so cludging them all together could be weird unless once you selected what you wanted from the list you could pick "set as filetree hotkey" or "set as WPS hotkey" 07.57.33 # (or something similar) 07.58.16 # Hotkey -> list containing different screens for which the hotkey can be defined (WPS, List, WRS, FM, for example) 07.58.19 # S_a_i_n_t: you can have different things on the hotkey in the WPS and in lists? 07.58.21 # And then under those the lists of options. 07.58.30 # * Llorean would hope that it's not one function for all screens. 07.58.47 # pixelma: yeah... 07.59.28 # the wps/filetree hotkeys are totally seperate. 08.00.14 # so you have the combo go to the playlist in the WPS and do something else in the tree? Provided the target has free keys in both... 08.00.37 # yes 08.00.54 # I'm kinda surprised you didn;t know that to be honest 08.01.01 # have you used the hotkey at all? 08.01.23 # there is though, a bit of a lack in documentation...I'll admit. 08.01.44 # no - and two of my three targets don't have the hotkey at all - the other I don't know 08.02.38 # ok, the c200 had the playlist viewer shortcut before so at least hotkey in WPS 08.03.47 # that's the one I use least currently 08.04.06 # the WPS hotkey is set to "Playlist Viewer" by default (not sure why exactly actually...) and the Filetree hotkey remains unset by default. 08.05.31 # the why is in my statement before - the WPS key combo that was used as a playlist viewer shortcut before was made the hotkey combo 08.06.23 # Basically, it's set to that so that people use to the old behaviour don't have something new happen when they press the button 08.07.01 # gevaerts: I don't like 25861 at all. The type-punnedness warnings are there for a reason 08.07.27 Join esperegu [0] (~quassel@145.116.15.244) 08.08.24 # They were disabled for gcc 4.1.x because it seemed to have a bug that caused them to appear without cause. gcc 4.0.x does not have that problem 08.08.45 # Llorean: I dont exactly have time for an argument, but I will say that discussion is pointless.. I'm pretty sure i have proven that the ml is a waste of time, eeither noone replies or it turns into a flame fest 08.08.48 # ditto here 08.09.42 # S_a_i_n_t: If you hover over the delta, you see that most of it is ram usage increase. Binsize change is in the expected range 08.10.02 # JdGordon: So basically, there's no point in ever talking about anything, and everyone should just do what they like? 08.10.31 # The icon is (for colour targets) 6x8x16 *bits*, i.e. 6*8*16/8 = 96 bytes 08.10.35 # * Llorean takes that as an invitation to revert commits that annoy him rather than attempting to discuss it first, if JdGordon's so sure discussion can't happen. 08.10.38 Join kugel [0] (~kugel@rockbox/developer/kugel) 08.11.02 # amiconn: the comment suggests something else 08.11.57 # the commit message too 08.12.10 # Referring to what? :confused: 08.13.43 # the type-pundness warning issue 08.14.28 # I fail to see a comment, and the commit msg is just "Use -fno-strict-aliasing on 4.0 as well 08.14.34 # ...without reasoning 08.16.14 # JdGordon: I love your attempt at civility and reasoned discussion on the mailing list. 08.16.36 # I'm glad :) 08.17.02 # JdGordon: Maybe you should consider not responding if you don't have anything useful to add. 08.17.05 # amiconn: you can see the comment in the commit diff (of gevaerts commit) 08.17.08 # Since you're the one complaining about the lack of reasonable discussion. 08.17.09 # SNAP! 08.17.34 Join LinusN [0] (~linus@rockbox/developer/LinusN) 08.18.00 # kugel: There is no comment ?! He just changed the if condition in configure 08.18.13 # and I meant the commit message of the commit which originally added -fno-strict-aliasing there (r10609) 08.18.20 # amiconn: there's an existing commit 08.18.26 # Yeah 08.18.49 # JdGordon: I think your action and response to the mailing lists are totally not cool 08.18.50 # JdGordon: No, but seriously, what was the point of that? Why even get involved with it if you really don't care to take it at all seriously? 08.18.59 # But this comment refers doesn't explain why - it just says what it does 08.19.05 # you said "They were disabled for gcc 4.1.x because it seemed to have a bug that caused them to appear without cause. gcc 4.0.x does not have that problem" which doesn't seem true considering the comment and r10609 08.20.05 # That's exactly what I mean 08.20.31 # Llorean: put it this way... if you seriosuly didnt have a whinge after every single commit then things would be alot more reaosnable 08.20.37 # r10609 disabled it for gcc 4.1.x (because there obviously are problems with it) but *not* for 4.0.x 08.20.59 # and suggesting that you have any right to revert my shit, well that caused my reply 08.21.16 # right, but not because of a gcc bug 08.21.18 # And until r25850 there were no such warnings from gcc 4.0.x targets (arm and sh) 08.21.26 # JdGordon: I didn't suggest I had a right to. You said reasoned discussion couldn't happen, I suggested that if you can't discuss things then the only response left is to revert things you don't like. 08.21.27 # anyone has the "right" to revert anyone's "shit" 08.21.37 # Now there are - and this tells me the warnings should be fixed, not suppressed 08.21.48 # JdGordon: But you can't blame your behaviour on me. I didn't make you act like that. 08.22.12 # you said they are disabled for 4.1 due to a gcc bug 08.22.52 Join bieber_ [0] (~quassel@162-78.97-97.tampabay.res.rr.com) 08.23.24 # Yeah, perhaps it wasn't a bug, but more strict aliasing tests 08.23.36 Quit bieber (Ping timeout: 260 seconds) 08.23.43 # I didn't change the code where the warnings, nor the used gcc version. hence ignoring the warning is safe if it was before 08.23.46 Join BHSPitMini [0] (~BHSPitMon@pool-71-170-176-30.dllstx.fios.verizon.net) 08.24.29 # You certainly did (indirectly) 08.24.29 # and I and gevaerts already concluded that fixing the code is a good idea but it requires thinking about each case 08.24.47 # in the meantime the table can be kept green 08.25.32 # Llorean: you could have of course started the whole thing with "Blue_Dude: I didnt see any discussion re your last commit, I wonder if I missed it?" instead of straight away being a prick? 08.25.47 # Yeah, and then forgotten about the problem :\ 08.26.16 # JdGordon: I asked you where the discussion was. As well, presence of the discussion or not doesn't change the fact that the patch seems to have some significant flaws at the moment and could've just as easily been reverted until he could look at it again, rather than left overnight. 08.26.21 # JdGordon: Llorean just said that he didn't see a discussion here? 08.26.23 # it's not a problem if the code worked well before 08.26.23 # As well, the issue of yet another lacking manual entry is still valid. 08.26.59 # JdGordon: Like it or not, all of my questions are valid ones. You could've simply answered them or ignored them. 08.27.03 # * amiconn wonders whether kugel misses his point 08.27.16 # we didn't change the code, but only triggered some change gcc magic relating to stddef.h to make it even see a problem there 08.27.26 # how could a manual entyr be added for an icon? 08.27.28 # The warnings are there to show potential problems, possibly leading to instability 08.27.41 # in fact the warning was hidden before too, but unintentionally 08.27.42 # And the problem *did* get worse than it was pre-r25850 08.27.58 # JdGordon: Easy. Under the hotkey manual section add a note "Hotkeyable menu entries will be displayed with an alternate red icon in the default theme" 08.27.59 # Done 08.28.00 # huh? 08.28.23 # the menual shouldnt discuss the default theme at all 08.28.32 # It certainly wasn't hidden for gcc 4.0.x (and 3.4.x) 08.28.32 # woops, someone changes the default and then its out of date 08.28.36 # Then you fix it 08.28.46 # Just like "whoops, someone changes where an item is in the menus then its out of date" 08.29.00 # If you have an icon that is specifically there to tell a user something about an item, you need to tell the user *what* it tells them 08.29.07 # someone might also think a different theme is the default 08.29.14 # its just stupid putting that in the manual 08.29.14 # Especially if without a description it appears completely random. 08.29.15 # amiconn: it was 08.29.22 # how? 08.29.28 # gcc has special handling for size_t apparently which wasn't enabled before 08.29.31 # JdGordon: So basically we can't describe any of the UI at all as it may change in appearance later? 08.29.46 # yes, of course, take it tot he extreme :/ 08.30.02 # But you're using the "it may change" as your only argument 08.30.03 # now it warns if you use %lu in printf when the var is size_t, and it sees possible aliasing rule breakage 08.30.05 # Clearly the icon may change 08.30.12 # But it's currently this, and we *can* describe it 08.30.19 # *both* didn't happen before 08.30.25 # We can't help it if someone isn't using the default theme, just like we can't help it if someone is using a modified build. 08.30.32 Quit Buschel () 08.30.40 # and what benefit does putting that line in the manual add? 08.30.52 # The benefit of actually telling users what that icon means? 08.30.59 # the icons dont mean anything 08.31.02 # Rather than them booting their player, finding half the icons are now red, and not knowing what it means 08.31.06 # Usually red is a *warning* 08.31.13 # If they don't mean anything, why did we add one that *does* mean something? 08.31.41 Join ender` [0] (krneki@foo.eternallybored.org) 08.31.54 # it didn't happen before because we had the size_t definition in sys/types.h and not in string.h where it should be and where stddef.h is included (which triggers the special handling) 08.32.03 # kugel: Actually it seems that r25861 is unnecessary, and can be reverted without warnings reappearing 08.32.34 # did you re-run tools/configure? 08.32.54 # I didn't re-run anything 08.33.14 # I just looked at the build table and related commit diffs 08.33.36 # * kugel wonders if amiconn has read the relating irc logs 08.33.50 Join flydutch [0] (~flydutch@host36-202-dynamic.15-87-r.retail.telecomitalia.it) 08.34.03 # http://www.rockbox.org/irc/log-20100507#01:54:00 08.34.46 # kugel: r25861 suppressed the "type punned pointer..." warning, but there was no such warning in the r25860 round 08.35.47 # as I said, it's triggered by including stddef.h, which was restored in r24862 08.36.57 # we were really confused about this issue, reading the logs helps understanding it 08.37.38 # r25862 does more than just restore the #include 08.39.25 # You're right about this size_t handling uncovered a bug though 08.39.51 # Did you *actually* look at the code that triggered the type-punnedness warnings? The bug is obvious 08.40.51 # * JdGordon hopes noone does an update of only the rockbox binary.... that could cause funny icons :) 08.40.55 # ssize_t vs. size_t 08.41.49 # JdGordon: So again, if they're not supposed to mean anything, why'd we add ones that do? I mean, I thought they were supposed to mean things such as "this file is a music file" (the one with music notes) or so on. 08.41.56 # If they aren't, we probably need to strongly reconsider the iconset. 08.42.31 # I'm not saying I agree with the change, I honestly coudlny care less. 08.42.38 # adding the note in the manual is silly though 08.42.41 # That doesn't answer my question. 08.42.51 # You said icons don't mean anything. 08.43.00 # Is this the intended use of icons, or is their current use the intended one? 08.43.48 # the intended use is always was to make the list slightly prettier 08.44.13 # Then we shouldn't be wasting binsize on adding ones that are supposed to be meaningful. 08.44.23 # amiconn: yes, we did 08.44.27 # They make the list look pretty ugly, blaring and red 08.45.27 # amiconn: it does not more, you need the two defines above to get the definitions, but including it alone also triggers the warnings 08.45.33 Quit JdGordon (Quit: fuck i really couldnt give a shit) 08.46.30 # * Llorean thinks at the very least, we should consider a different color for the icons 08.47.22 # amiconn: but we don't know whether the code there relies on using ssize_t or not, you'd need to look closer at the code 08.49.54 Quit kugel (Remote host closed the connection) 08.55.27 Quit bmbl (Ping timeout: 252 seconds) 08.57.56 # I find it supprising that Rockbox has recording support for Clip v2 before Clip v1. But who am I to complain. I didn't help coding it. 09.01.54 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 09.09.00 Quit BHSPitMini (Ping timeout: 265 seconds) 09.09.56 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 09.11.29 Quit JdGordon (Client Quit) 09.14.56 Join loveless [0] (~loveless@2a01:198:26e:0:216:cbff:feb9:8c8d) 09.15.20 Quit esperegu (Remote host closed the connection) 09.16.21 Join esperegu [0] (~quassel@145.116.15.244) 09.16.58 Quit esperegu (Remote host closed the connection) 09.17.27 Join esperegu [0] (~quassel@145.116.15.244) 09.24.15 Join petur [0] (~petur@rockbox/developer/petur) 09.26.36 Join funman [0] (~fun@rockbox/developer/funman) 09.29.02 Join M3DLG [0] (~M3DLG@bb-87-81-252-83.ukonline.co.uk) 09.30.46 Quit M3DLG (Client Quit) 09.31.19 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 09.33.16 # I don't think the documentation would be about the icon itself (so not really theme dependent). It's about its use in principle, as a marker for hotkeyable items if it stays this way (I don't like the idea though) 09.34.08 # and the sentence Llorean has given can be true even if the actual look might change 09.36.15 Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 09.38.55 Join solexx [0] (~jrschulz@e176123140.adsl.alicedsl.de) 09.40.06 # pixelma: Yes, it could be written as "in the quickscreen, functions that can be set as a hotkey will receive a different icon than other functions" or similar. 09.40.55 # where, what, quickscreen? 09.41.49 # Er, context menu 09.41.50 # Sorry 09.42.02 # It was just an approximation anyway, to indicate it doesn't need to describe what the icon looks like 09.42.19 Quit solexx_ (Ping timeout: 264 seconds) 09.46.08 # New commit by 03funman (r25869): Fuzev2: calibrated discharge curve 09.46.29 *** Saving seen data "./dancer.seen" 10.01.13 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 10.10.48 Join DerPapst [0] (~Alexander@dslb-088-069-132-230.pools.arcor-ip.net) 10.12.48 Quit bmbl (Quit: Bye!) 10.16.58 # amiconn: the size_t vs ssize_t thing is indeed obvious, but while some code does indeed never do anything special with the value (and so should be safe to just change), some places do some arithmetic on the resulting value, possibly making it negative. I was too tired last night to reliably handle them 10.17.39 # I'm willing to just revert the configure change, but then we'll have lots of yellow until someone gets to it (I plan to have a look tonight). Can we live with that? 10.19.43 # we can live with the change not reverted 10.19.47 # just do it all at once 10.24.03 Quit Kitar|st (Ping timeout: 240 seconds) 10.25.30 Join robin0800 [0] (~quassel@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) 10.30.02 Join Kitar|st [0] (~Kitar_st@89.142.58.68) 10.30.45 # Bagder: i have some AMS firmwares which aren't on your website, how can I send them to you ? (there's a couple dozens of megabyes) 10.34.09 # mail them, but probably not all of it in a single mail 10.34.39 # hm could I just give you a ftp link? 10.34.55 # that works even better ;-) 10.45.07 Quit BHSPitMonkey (Remote host closed the connection) 10.45.25 # saratoga: can you wait for FS#11246 before releasing the fuzev2 bootloader? 10.55.14 Join n1s [0] (~n1s@rockbox/developer/n1s) 10.58.16 Join lpereira [0] (~lucien@did75-8-82-226-27-213.fbx.proxad.net) 11.01.28 Quit DerPapst (Ping timeout: 248 seconds) 11.01.31 Join DerPapst [0] (~Alexander@p5099d40e.dip0.t-ipconnect.de) 11.09.00 Quit loveless (Quit: loveless) 11.10.29 Quit linuxstb (Read error: Operation timed out) 11.20.26 # * S_a_i_n_t is getting more than a little tired of the petty bickering about things of late, and even more tired of the way the escalte so dramatically. Even if the points being made are totally valid, they way they're being put across by some people totally sucks... 11.26.03 Quit mc2739 (Ping timeout: 240 seconds) 11.28.04 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 11.28.34 Quit robin0800 (Remote host closed the connection) 11.33.45 Join dfkt [0] (dfkt@unaffiliated/dfkt) 11.44.15 Join kenguest_ [0] (~radagast@lir.talideon.com) 11.44.37 Quit kenguest (Read error: Connection reset by peer) 11.46.32 *** Saving seen data "./dancer.seen" 11.53.53 Join DerPapst1 [0] (~Alexander@dslb-088-069-132-230.pools.arcor-ip.net) 11.56.22 Quit DerPapst (Ping timeout: 264 seconds) 12.00.32 Join Filburt [0] (blah@ip72-200-105-9.tc.ph.cox.net) 12.26.22 Quit mc2739 (Ping timeout: 240 seconds) 12.26.31 # Torne: The person with battery problems in his iPod - wouldn't having a charger plugged in bypass those problems? Or does it just charge the battery, and pass through the battery to power the player (which seems silly, but I know at least one other player had that IIRC) 12.27.01 # Llorean: the disk pulls more than 500mA to spin up 12.27.02 # iirc. 12.28.22 # Ah 12.28.32 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 12.29.47 # the Beast has the same problem, it can't power up from usb when the battery is flat 12.29.58 # and the beast has no protection from this, so it just reboots in a loop and never charges 12.30.03 Quit esperegu (Remote host closed the connection) 12.30.14 # the ipod bootrom in theory shuts itself off once this happens, to give hte battery a chance to charge 12.30.25 # but if it's in the emergency disk mode tha tlogic might not work 12.30.30 # (it should ,if you just let it boot the OF) 12.30.51 # well, assuming the battery is ever going to recover :) 12.31.04 # speaking of charging, any idea why the AMSv2 would only charge up to 67% ? 12.31.32 Join wodz [0] (~wodz@skatol.ch.pw.edu.pl) 12.31.33 # Torne: I'd noticed that with the beast. *very* frustrating that you can't use USB to recover a dead battery (since you could on the F and I'd gotten used to it) 12.32.07 # yeah. the ipod writes magic strings to iram to detect whether booting succeeded (since iram is preserved across resets) 12.32.15 # the beast doesn't appear to have any such mechanism 12.33.28 # The F just doesn't visibly boot on USB insertion at all 12.34.58 # the beast can at least charge with the charger so it isn't *that* bad 12.35.16 # yeah, but that's because the beast has a real AC charger that delivers lots of power 12.35.35 # as best as i've been able to determine so far, the ipods don't pull more than 500mA from the USB connector even if that's an Apple AC charger rated for 1A 12.35.46 # n1s: The F could charge with either the charger or USB no matter how low the battery got, even if it couldn't boot, which was really nice. 12.35.56 # Llorean: yah, but that's just a software/hardware charging thing, no? 12.35.58 # You could just leave it powered off sitting on a spare USB port for a while, and eventually it could be turned on. 12.36.05 # Torne: Probably. 12.36.14 # Llorean: ah 12.36.19 # the ipod has hardware charging, but autopowers on 12.36.32 # so they have the logic to notice they are rebooting and shut the power off 12.36.36 # so that it can charge instead. 12.36.36 # Is the beast supposed to power on on headphone insert? 12.37.03 # ..headphone? 12.37.16 # Yes 12.37.28 # Mine does. 12.37.33 # any dev but mcuelenaere got a Creative Zen Vision? 12.37.37 # not that i know of, but i doubt i've tried 12.37.41 # But I didn't remember whether it always did or not. 12.37.44 # i've very rarely used the beast for music :) 12.37.52 # and would be willing to lend it to me 12.38.09 # funman: That reminds me. 12.38.18 # Llorean: it has been doing it for some time, dunno if it was intentional 12.38.39 # Might it make sense to acquire official "Rockbox" players for most/all types? So that we have one of each around for testing when something important comes up (or mailing, when something *doesn't* work somewhere it really should)? 12.39.06 # Torne: If battery is really low, the ipod rom refuses to boot from disk, and just charges for a while, showing a big charging icon 12.39.19 # Right now we have some players where only one or two devs have it, and if they leave, we don't have a way for things to be tested on them in the future. There's probably a player or two there's none of (iPod 3G / 2G? ) 12.39.21 # amiconn: yah, but it can't always tell that in advance 12.39.30 # Llorean: i think informally sending players ourselves is alright 12.39.32 # At least my mini does that - and in theory a microdrive could be powered from usb 12.39.44 # amiconn: it's possible that unloaded the battery voltage looks just barely ok 12.39.51 # funman: Yes, but it'd be nice to have one around explicitly *for* sending. :) 12.39.51 # but the load of spinup pulls it too low to run the device 12.40.04 # they write a string to iram that basically imparts "shit we reset during boot" 12.40.11 # and the OF clears that if it starts successfully, i assume 12.40.16 # Llorean: I have an 1G and a 2G, and iirc jhMikeS has a 3G 12.40.43 # amiconn: ah, can you test my bootloaders? :) 12.41.02 # myself I have already 3 'property of rockbox' Sansas 12.42.00 # amiconn: at some point. no great hurry. 12.42.03 # Not now, at least 12.42.45 # also, do you have an opinion on what we should do about contrast? obviously it would be *nice* to fix it properly, but equally i'd quite like to get a bootloader release out in the near-ish future 12.42.47 # i think buying targets with already working rb for devs would be nice 12.43.06 # to increase the number of devs with the rarer targets 12.43.20 # 1 dev = 1 archos player :) 12.43.33 # n1s: And just to help assure that some of the rarer targets will be around in the future. 12.43.33 # ondios to everyone! 12.43.42 # * B4gder ducks 12.43.56 # heh 12.44.05 # Some of the targets are already becoming quite hard to buy, and if the last dev with one of those leaves it'd be nice to have an official Rockbox one around to lend if a new interested dev showed up. 12.44.16 # Or to test similar optimizations or whatnot 12.44.48 # i think an official one is a bit overkill 12.51.04 # * amiconn would actually like an archos fm recorder 12.53.21 # New commit by 03jethead71 (r25870): i.MX31/Gigabeat S minor cleaning: Make HW access more obvious in places I forgot to do earlier. Reduce the number of structs that need to be ... 12.54.34 Quit n1s (Ping timeout: 264 seconds) 12.56.42 # amiconn: could You remind me how to procceed with test_grey plugin and how to adjust grey shades? 13.03.00 # amiconn: indeed, I have a 3g but also and an archos player. I suppose a mips target would be nice to have just to have all major archetectures covered. 13.03.10 # the Ondio is really nice 13.03.24 # but hard to get these days 13.04.15 # * S_a_i_n_t needs a giga-beast to er......theme on, yeah, that's the one. ;) 13.04.32 # not enough themes for the beast already... :P 13.05.29 # S_a_i_n_t: just to theme? an F would theme the same. can you handle the beast? :P 13.06.44 # Pffffft! Sure I can, the beast can't handle *me* ;) 13.07.41 # :) 13.08.58 # I've only ever seen one Beast for sale in NZ so far, and only a handful of F's...the beast was so banged up also, obviously a very well loved/used player. 13.09.34 Quit funman (Quit: free(random());) 13.09.58 # anyway, I did some checks but haven't done a full battery bench. it seems that constant interrupt problem was hitting the battery life pretty hard. if anyone benched before r25837, I'd recommend rechecking. 13.10.45 # jhMikeS: I was gonna ask about that actually (didn't do a bench, but when I saw mention of the constant interrupts I was going to ask if better battery life was now to be expected) 13.11.07 # S_a_i_n_t: I got mine from toffee82 so I really didn't need to look much. He practically threw it at me. 13.11.20 # lucky boy ;) 13.11.45 # I think it's a dog-ass ugly player, but, it has grunt...sheer grunt. 13.12.34 # Llorean: compared to before that committ, after doing a two-hour comparison from at same voltage levels from the more recent longer bench I did, it seems it might be a little ahead of that even. 13.13.28 # If grunt like that could be squished into that form factor of a Nano...S_a_i_n_t would be a /very/ happy boy... 13.13.30 # S_a_i_n_t: style-wise it reminds me of my Rickenbacker bass guitar (that I had). No way it's ugly. 13.13.37 Join komputes [0] (~komputes@ubuntu/member/komputes) 13.13.49 Join bilditup1 [0] (~4fb2868f@giant.haxx.se) 13.14.01 Join watto [0] (~watto@193.203.81.165) 13.14.07 # * S_a_i_n_t is a Nano man, 10 and counting now :D 13.14.15 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 13.14.33 # * Llorean still needs to go through some day and update plugins to support the side control buttons. 13.14.47 # Many of the games could have full playback control without interfering with game controls 13.14.47 Quit bilditup1 (Client Quit) 13.17.57 # * jhMikeS checks mpegplayer and seen that |<< and >>| have been overlooked but not |> || or +/- 13.20.46 # Llorean: that might be nice to have thought 13.20.49 # *though 13.21.18 # jhMikeS: I find myself habitually trying to tweak volume while in jewels or something. 13.21.55 # Interestingly you can do it from the list in jewels (though prev/next still don't work, since they don't do anything in the normal list context yet either) 13.30.46 Join bilditup1 [0] (~bilditup1@bzq-79-178-134-143.red.bezeqint.net) 13.33.16 # * jhMikeS suggests page up/dn instead of the down/up + back that is rather awkward 13.34.09 # That'd work too. 13.34.24 # Safer too - accidentally skipping tracks when you can't even see the WPS would be annoying 13.36.09 Quit bilditup1 (Quit: Leaving) 13.37.41 Quit Filburt (Quit: Goodbye! :)) 13.39.12 # * amiconn would also like a mips target - if only there was one without touchscreen :\\ 13.39.18 # pixelma: are You 100% sure that there is no difference between boosted/unboosted in test_mem ? 13.39.48 # amiconn: do You have CF target at hand? 13.40.15 # there are MIPS targets without touch, they just don't run rockbox ;-) 13.40.34 Join esperegu [0] (~quassel@145.116.15.244) 13.40.39 # amiconn: playstation portable? :) 13.40.58 # wodz: I'm quite sure because it also made me wonder, if you want to I can try again 13.42.23 Quit watto (Read error: Connection reset by peer) 13.42.31 Join ucchan [0] (~ucchan@softbank126102048034.bbtec.net) 13.42.40 # pixelma: I am asking because 1) I have results which are in simple proportion to frequency on MPIO 2) because unboosted results on MPIO are probably responsible for high cpu frequency 13.45.35 # At last, I can return to the work of Rockbox because my work ended. (very very hard...) 13.46.36 *** Saving seen data "./dancer.seen" 13.47.05 # It is possible to comment on the embedded albumart (FS#11216) finally. 13.47.56 # New commit by 03jethead71 (r25871): Add support for the next/prev side buttons to mpegplayer on the Gigabeat S to control seeking. 13.49.06 Join watto [0] (~watto@193.203.81.165) 13.49.18 Quit einhirn (Ping timeout: 265 seconds) 13.53.48 # I plan to do work to support TTA codec. 13.54.02 # Does the person who has already started it have someone? 13.57.56 # It might be complete by the end of May if I am not busy... 14.03.58 Join Blue_Dude [0] (~chatzilla@rockbox/developer/Blue-Dude) 14.10.51 # Llorean: the back button doesn't do anything in video context either. personally, I've wanted a button to show the osd without having other effects. 14.11.34 Join Zagor [0] (~bjst@rockbox/developer/Zagor) 14.14.19 Join mikroflops [0] (~yogurt@90-227-45-110-no112.tbcn.telia.com) 14.14.39 # What's the svn command to cleanly revert the the repository copy of certain files to their prior versions? 14.15.22 # I've copied the old versions locally and can recommit them as though they were new, but didn't know if that would mess up versioning. 14.18.26 Quit ucchan (Quit: Leaving...) 14.18.29 Quit mikroflops_ (Ping timeout: 276 seconds) 14.19.23 Join freddy_ [0] (~freddy@p3E9E1F4B.dip0.t-ipconnect.de) 14.20.09 # I'm trying to fix the problem without messing up the repository. Some help would be appreciated. 14.23.46 # I am looking for some coldfire guru 14.24.22 # I can't realy understand sdram configuration bits 14.25.09 Quit Hillshum (Ping timeout: 264 seconds) 14.25.41 # Blue_Dude: svn update -r file 14.25.58 # possibly svn revert first 14.26.50 # gevaerts: That's kinda the problem. Is there a difference to svn between recommitting to an older version or reverting to it? 14.27.15 # Blue_Dude: what do you mean by "recommitting to an older version"? 14.27.44 # I mean reverting the local copy, then checking it in as though it was a new update. 14.28.34 # I will partially revert r25866, but with a couple of changes. 14.35.06 Join Schmogel [0] (~Miranda@p3EE22A83.dip0.t-ipconnect.de) 14.37.00 # which changes? 14.38.02 # I'll keep the internal menu designation "HOTKEYABLE" and the code that assigns them to a new icon. I'm trying to decide on the icon right now. There's not much in the say of choice. 14.38.08 # *way 14.39.02 Part watto 14.40.06 Join mt [0] (~mtee@rockbox/developer/mt) 14.40.14 # * Torne doesn't see the need to display that information 14.40.40 # the lack of a splash on trying to hotkey a non-hotkeyable thing was spectacularly confusing when i was testing this the other day, though 14.41.07 # Oh.. yeah. that reminds me what i was doing the other day. Need to see if I can fix the action code to ignore releases on context change properly :) 14.41.21 # Blue_Dude: dunno if you saw the discussion i had with S_a_i_n_t about that 14.42.07 # No, didn't see that. 14.42.35 # the action code already tries to filter out release events after a change of context 14.42.44 # so, it should already be discarding the extra releases. 14.42.56 # and it does, on my ipodvideo, if i let go of the buttons at the exact same time ;) 14.43.16 # however, the code doesn't allow for multi-button combinations - if you let go of one button, then the other, the first one will get discarded byt the second one still counts 14.43.18 # Torne: There were some objections to the use of splash for something like that. Even the "no hotkey set" brought a comment. 14.43.45 # S_a_i_n_t found that he had to be *much* more precise with timing both to press and release the buttons 14.43.49 # The yesno ought to be redesigned. 14.43.54 # *Then 14.44.03 # No, it's not a bug in yesno 14.44.05 # it's the core action code 14.44.23 # No, but it's in yesno that it matters. 14.44.25 # yesno automatically benefits from this because CONTEXT_YESNO is different to whatever context you invoked the yesno from 14.44.36 Quit FlynDice (Remote host closed the connection) 14.44.51 # yeah. so i was gonna look and see about fixing this in action.c, because this will solve other potential cases also 14.45.07 # the difference in timing requirement between me and S_a_i_n_t is bizarre though 14.45.12 # especially since our ipods use the same button driver :) 14.45.17 # Probably. It's probably been lurking there for ages. 14.45.35 # i can press either button first, and as long as i press the other button in less time than it takes to register the first as a long press it invokes the hotkey stuff 14.45.44 # S_a_i_n_t has to be really, really exact and press them perfectly at once 14.45.45 # That is strange. Are you a gamer? :) 14.45.52 # yes :) 14.45.56 # but seriously, i estimate maybe 200ms is okay 14.45.58 # Well there you go. 14.46.18 # the difference seems profound enough that it can't be explained away as reaction times.. 14.46.25 # Anything less than "long press" should be OK. 14.46.28 # Indeed 14.46.43 # it is, for me 14.46.48 # just not him 14.46.54 # Hm. 14.46.54 # It's why he can't ever say yes to the yesno, though 14.46.59 Join watto [0] (~watto@193.203.81.165) 14.47.00 # the same timing applies on release, i assume 14.47.15 # so he would also hav eto release them exactly simultaneously for it to be just one event and correctly get deleted by action.c 14.47.29 # That's what the key patch was supposed to work around. 14.47.29 # If I let go of them "at once" i get the yesno prompt and i can say yes 14.47.41 # if I let go of them one at a time then it autocancels the yesno prompt, as he was seeing 14.47.44 # It's not a general fix though. 14.47.51 # Yah, i'm just saying; logically there should be absolutely no need to change the keymap here 14.47.57 # Agree. 14.48.03 # fixing the action.c issue should stop the spurious dismissals 14.48.13 # but i am still puzzled about the separate issue of timing S_a_i_n_t is seeing 14.49.00 Join Farthen_ [0] (~Farthen@g224150124.adsl.alicedsl.de) 14.49.26 Nick Farthen_ is now known as Guest534 (~Farthen@g224150124.adsl.alicedsl.de) 14.51.20 # is the ipod the only platform in common use where the hotkey is a combination? 14.51.30 # i would've assumed this issue was generic 14.59.02 Join Hillshum [0] (~hillshum@75-165-235-147.slkc.qwest.net) 15.01.14 Join Jaqo [0] (~MaGix@41.206.154.178) 15.01.19 # hi 15.01.33 # hi Jaqo 15.01.42 # how r u 15.02.46 # I'm fine, but this channel is actually only for talking about rockbox. 15.03.26 # whats this ? 15.03.39 # http://www.rockbox.org/ 15.03.43 Quit antil33t (Read error: Connection reset by peer) 15.03.49 Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) 15.03.49 # ty 15.04.04 Part Jaqo 15.04.37 # OK, I've got the partial revert set up. Behavior will be the same, but without the new icon. Instead, another will take its place, one that isn't currently used in the menus. 15.06.30 # If I had to pick one, I'm thinking the walking feet, Icon_Preset. It's barely used, and then only for .fmr files in the file view. It doesn't say "hotkey" to me, but maybe the feet = quick access association is there. 15.06.45 # New commit by 03jethead71 (r25872): mpegplayer: make button timeout half the OSD update interval so that it updates the indicators properly when not holding a key. Add capability to show ... 15.07.55 Quit Guest534 (Ping timeout: 246 seconds) 15.08.25 # Blue_Dude: I'm not sure I like another icon replace the usual one because an item is hotkeyable. Imagine everything would be hotkeyable then you only get one icon 15.08.48 # If everything was hotkeyable, you wouldn't *need* an icon. 15.09.15 # If you object to a particular use, it's easy enough to mark which you don't want replaced. 15.11.34 # Another good possibility is the right pointing green arrow, Icon_Moving. It's only used in the playlist viewer. 15.12.03 # Blue_Dude: i think you are not helping people's objectinos here 15.12.13 # Having some icons different is going to mamke people wonder why they are different 15.12.22 # and most people don't read the manual, as we know ;) 15.12.28 # every one. And the argument brought up before is true. We don't mark items which can be placed in the quickscreen either. Despite the fact that I still don't like the new and different ui for seting hotkey too 15.12.42 # i don't think hotkeying stuff is an important enough use case that it needs to be marked 15.12.53 Join Guest534 [0] (~Farthen@g224098228.adsl.alicedsl.de) 15.13.15 # it doesn't matter how the icon looks 15.13.51 # Well there was already some complaining that you have to go to the manual to find out which was which. And you said yourself that it was confusing that some gave feedback and others were silently ignored. 15.15.07 # yes, but I specifically expected (without having read any of the docs, just being aware that the hotkey thing existed) that i would get feedback *when i tried to hotkey something not hotkeyable) 15.15.13 # This gets back to the old debate: is Rockbox going to be made so that you never have to reference the manual, or not? If so, then there are already way too many features. 15.15.36 # is it supposed to actually throw you out of the context menu when you do that, btw? 15.15.42 # or is that more issues with ipod keys? :) 15.16.29 Join dfkt_ [0] (~dfkt@unaffiliated/dfkt) 15.16.34 # No, it behaves as though you'd hit any other invalid key. 15.16.43 # Same as before. 15.17.12 # ok, that's slihglty better then 15.17.34 # (on ipod it throws you out of the context menu, though, at least at the moment when i tried it) 15.17.41 # (which makes no sense since neither select nor play do that) 15.18.24 # It did the same before IIRC. I can't remember. 15.18.50 # i have no idea 15.18.55 # i never pressed select+play before :) 15.20.09 Quit dfkt (Ping timeout: 265 seconds) 15.21.28 # What happens if you put in any other invalid keypres in the context menu? Nothing? 15.21.56 # Nothing... 15.22.06 # Let me take a look. 15.22.38 # well, i think pondering the ipod behaviour too much without fixing what i'm pretty sure is a bug in action.c is probably a waste of time 15.23.07 # It's not just the ipod. It throws you out of the context menu elsewhere too. 15.23.36 # Ignoring the keypress is OK. Throwing you out of the menu entirely isn't. 15.23.51 # Hm 15.24.01 # I guess that's because it's generating something other than ACTION_NONE 15.24.08 # and then not eating it? 15.24.19 # what about a simple setting "hotkey function" and then you get a usual list containing the possible options (if there aren't too many), and this menu devided into WPS hotkey and list hotkey? 15.24.19 # whereas actually unmapped stuff is just ACTION_NONE 15.25.28 Quit freddy_ (Ping timeout: 265 seconds) 15.25.47 # pixelma: The idea was a context menu mod. You're expanding it somewhere else. I don't see why it wouldn't work. 15.26.23 # Torne; I can fix the "throw out" behavior in menu.c. Don't worry about it. 15.26.34 # ah ok 15.30.55 # Blue_Dude: sorry, can you rephrase "you're expanding it somewhere else" 15.30.57 # ? 15.31.57 # Means you're potentially expanding functionality beyond the confines of the context menu itself. Duplicating effort. 15.32.32 # But as I said, I don't why it wouldn't work. 15.32.46 # huh, I still don't understand 15.33.47 # New commit by 03jethead71 (r25873): mpegplayer: One last dealie-O for now: Change all "WVS" usage in the code for identifiers to "OSD". 15.36.17 Join bilditup1 [0] (~bilditup1@bzq-79-178-134-143.red.bezeqint.net) 15.36.21 # hey all. 15.37.37 # Blue_Dude: I thought of this usual menu style replacing the unique thing that's there now 15.38.39 Join freddy_ [0] (~freddy@p3E9E261C.dip0.t-ipconnect.de) 15.39.15 # I also don't like the icons changing for hot-keyable icons 15.40.10 # At least not by default. If people want to do it themselves, then fine 15.41.38 Quit Guest534 () 15.45.41 Part LinusN 15.46.40 *** Saving seen data "./dancer.seen" 15.47.42 Quit freddy_ (Ping timeout: 265 seconds) 15.50.16 # Fixed. New on/off menu item for that. 15.50.29 # Defaults to off. 15.51.08 # :\ 15.51.31 # IOW, no change to current behavior. 15.51.43 # What's wrong with that? 15.51.51 # Should this not just be a themeing option? 15.52.09 # i.e. theme authors decide whether to use a different icon? 15.52.10 # I put it in the hotkey menu. 15.52.21 # more complication when I think it could be more simple in general 15.52.49 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 15.55.39 # Blue_Dude: I don't mind too much, as long as it is off by default as it is :) 15.56.34 Join n1s [0] (~n1s@rockbox/developer/n1s) 15.57.58 Quit wodz (Quit: Leaving) 15.59.08 Nick dfkt_ is now known as dfkt (~dfkt@unaffiliated/dfkt) 15.59.43 Join freddy_ [0] (~freddy@p3E9E15EB.dip0.t-ipconnect.de) 16.02.52 Quit Strife89 (Quit: Reboot.) 16.02.54 Part bilditup1 ("Leaving") 16.03.15 Join M3DLG [0] (~M3DLG@212.183.140.35) 16.04.47 Join evilnick_B [0] (~0c140464@rockbox/staff/evilnick) 16.05.25 # Blue_Dude: The icon for *all* context menu items is the "yellow diamond thing" is it not? 16.05.46 # why not use the "blue plus sign" for hotkayable" items? 16.06.09 # S_a_i_n_t: not all of them. Submenus use the cross thing. There are other custom icons. 16.06.10 Join Strife89 [0] (~Strife89@adsl-80-144-24.mcn.bellsouth.net) 16.06.47 # Hmmm..ok, um... 16.06.48 # That's why I was trying to pick something you won't otherwise see in a menu. 16.08.20 # by "walking feet thing", do you mean icon No.11? (assuming the first icon is icon 0)? 16.08.48 # I always thought that was 2 exclamation marks side by side 16.09.05 # *assuming you do mean that icon... 16.10.52 Quit antil33t (Read error: Connection reset by peer) 16.10.58 Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) 16.11.35 # Blue_Dude: What about icon No.9 [weird pointy-circle-orange-sun thing] (again, assuming the first icon is No.0) for hotkeyable items...I've been playing around just quickly now and can't see that icon appear in the default context menu. 16.12.22 # It's for plugins. I considered that one. I'm using the right green arrow at the moment. 16.12.57 # isn't that the one used for the pointer selector? 16.13.10 # No that's a different one. 16.13.15 # I thought about the arrow...but to me that signified the cursor for the line selector 16.13.29 # ahh..like pixelma just said. 16.13.41 # There's a right pointing triangle and a right pointing arrow. 16.13.56 # I've got the arrow right now. 16.15.04 # The "pointy sun thing" (even if it is for plugins) is what /I/ would use personally...but, this projest is hardly to please my sole aesthetic taste ;P 16.15.20 # Hey, aren't settings changed in the MENUITEM_SETTING menus supposed to save their state? 16.15.24 # *project even. 16.17.07 # what about the built-in (compiled in) icons btw.? 16.17.38 # Which? They're indexed the same way. That's a theme option. 16.17.42 # ...what of them? 16.18.23 # well, some targets use those instead of the tango icons (all smaller screen targets), what icon will they show? 16.18.43 # they would show the same I assume...but in mono/whatever 16.19.03 # The same icon. You don't get to pick the "color" version, just whichever one is loaded by the theme. 16.19.04 # s/the same/the same as the other targets/ 16.19.07 # besides I'm still not convinced about this marker thing at all 16.19.25 # even when disabled 16.19.28 # lucky it's not a democracy then ;) 16.19.30 # Default is off, pixelma. What else do you want? 16.19.58 # a more simple ui for this, as I said. Less complication 16.20.17 # I like it. It doesn't hurt anything. A few other folks asked for it. Don't turn it on if you don't want it. 16.20.21 # making a menu option for this even adds to the complication 16.20.44 # ram usage and bin size increase sure hurts 16.21.14 # and code complexity for those who code there 16.21.21 # I'm reverting the bin and RAM problem. All that will be left is a menu item and about two lines of code. 16.22.26 # didn't sound like it from your description because you want to keep the marker thing (in general) 16.22.49 # The marker thing will be off by default. You won't even know it's there. 16.23.33 # but the code is still there 16.24.33 Quit wincent (Ping timeout: 264 seconds) 16.24.52 # you never answered the argument about the quickscreen and the ui for setting the hotkey 16.24.53 # Yes, about two lines of it, a menu item, and a new variable in global_settings. 16.25.30 # No I didn't. If he wants a new icon for quickscreenable items he can do that. 16.25.46 Join kugel [0] (~kugel@rockbox/developer/kugel) 16.26.08 # Blue_Dude: a setting to toggle showing the hotkey icon? 16.26.09 # well, what made the solution now in SVN so complicated? 16.26.10 Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 16.26.18 # please no... 16.26.21 Join watto1 [0] (~watto@193.203.81.165) 16.26.35 # What? 16.26.43 Quit TheSeven (Remote host closed the connection) 16.27.35 # pixelma: I don't know why it bloated so badly. The only actual code change was two lines of code in menu.c. I can only assume the bitmap change drove the bloat. 16.27.45 # "Fixed. New on/off menu item for that." 16.28.03 Quit watto (Ping timeout: 252 seconds) 16.28.41 # Oh, there's a new menu item in settings. Not in the context menu. 16.28.53 # Yeesh, no. 16.29.18 # what setting? 16.29.27 # what does it toggle? 16.29.58 # Toggles icons on or off. Defaults to off. On if you want special icons. 16.30.10 # please no... 16.30.53 # Sigh. 16.31.02 # kugel: can you be abit more descriptive? It's hard to tell what you actually want or not want. Would help the discussion I think 16.31.17 # I don't want such a setting 16.31.25 # I also would prefer not to have the option or the icons, but if it is a choice between having special icons for hotkeyable things and a menu option, then I'll chose icons off and an option. 16.31.31 # kugel: btw, I'm getting a compile warning on the sim. In io.c. And now it won't save settings between sessions. 16.31.37 # it's like letting the user decide what color the bikeshed should have 16.31.47 Join toffe82 [0] (~chatzilla@12.169.218.14) 16.32.00 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 16.32.53 # I like my bikeshed to be green. 16.32.58 # But that's just me. 16.33.05 # kugel: eh, then you can drop all the theme stuff. But do you want a marker for hotkeyable items at all or not? 16.33.33 # I couldn't care less about whether there's an icon or not 16.33.47 # New commit by 03funman (r25874): Fuzev1: calibrated discharge curve 16.34.06 # I kinda care about the compile warning and no disk writes. 16.34.21 Quit M3DLG (Ping timeout: 246 seconds) 16.34.29 # kugel: well, that may be the case...but the 'average user' needs to be able to define what can/can't be set as a hotkey at a glance 16.34.36 # Blue_Dude: you're on cygwin right? 16.34.37 # why? 16.34.42 # Yeah. 16.34.47 # if you can think of a better way to do that than an icon...I'm all ears. 16.35.01 # Yeah to Cygwin. 16.35.06 # S_a_i_n_t: I think it is much more confusing to see some items with a random different icon and have no idea why 16.35.08 # I don't see why that's useful or interesting 16.35.10 # But it wasn't there before. 16.35.13 # S_a_i_n_t: And I don't think it needs doing at all 16.35.22 # S_a_i_n_t: again, do you know which items you can set for use in the quickscreen? 16.35.24 # I think it's better without 16.35.29 # Torne: I agree 16.35.30 # why would you not know why though? 16.35.40 # S_a_i_n_t: I don't know why 16.35.40 # there is a setting to turn this on/off 16.35.46 # Which is not needed 16.35.52 # You set the hotkeys once 16.35.54 # Blue_Dude: I have no access to cygwin atm :( 16.35.55 # so, if you see different icons...you've turned that feature on yourself 16.36.02 # You don't need to see it all the time 16.36.21 # S_a_i_n_t: And the argument is that the setting is unecessary too 16.36.42 Join CGL [0] (~CGL@190.207.236.211) 16.36.53 # and you would see it easily if it all was an a setting itself. No messing around with icons and a weird UI to set the hotkey 16.37.04 # kugel: OK. I posted the exact warning last night. Here: http://www.rockbox.org/irc/log-20100507#04:25:39 16.37.04 # s/an/in 16.37.31 # S_a_i_n_t: *Why* do users need to be able to see what's hotkeyable at a glance? 16.37.41 # It's "the logical things". 16.37.48 # It's also "the things that work if you try and hotkey them" 16.38.02 # same as the quickscreen 16.38.09 # exactly 16.38.20 # pixelma: wasn't the idea of it being a list type setting rejected *loooong* ago though? leading to the way it is implemented now? I wouldn't blame Blue_Dude for wanting to pull his hair out over this... 16.38.25 # yea, we should also have an icon for quickscreen'able stuff, and an option to toggle the icon! 16.38.33 # kugel: well, both or neither, yes 16.38.38 # it's totally illogical to have it for one and not the other 16.38.44 # S_a_i_n_t: And would you not blame every that doesn't want it for not pulling their hair out... 16.38.45 # i vote for neither, but both is less dumb than one ;) 16.39.03 # really, nobody ever raised that demand for the quickscreen, why does this seem to be so critical for the hotkey? 16.39.22 # kugel: It isn't, most people seem against it 16.39.27 # There should actually be more icons, one for hotkeyable, one for quickscreenable, one for hotkeyable AND quickscreenable etc. 16.40.20 # Torne: I find the setting most dumb, IMO the whole icon is too minor to be worth a single byte on binsize, and the added menu structure complexity 16.40.57 # S_a_i_n_t: as far as I remember, Blue_Dude implemented the UI as it is now from the start (as far as it was open). It's been discussed here before and a context menu like setting was rejected because you would have a context menu in a context menu. I can't remember a discussion about a usual list style menu 16.41.04 # evilnick_B: ah, you got a point 16.41.46 # the only drawback I see it could have is if the list becomes too long but from what I read here I gathered that there aren't that many things suitable for hotkey 16.42.40 # pixelma: I suggested ages ago using long-select on a context item should bring up a simple splash "set as hotkey? yes/no" but that got thrown back at me *pretty damn quickly*...now it seems people want to go back there? 16.42.48 # ... S_a_i_n_t shrugs 16.43.31 # and to me, that seemed to be the least complicated way of doing it. 16.44.18 Quit esperegu (Remote host closed the connection) 16.44.24 # no, as I said that would be a context menu potentially in the context menu. I'm not talking about that and already said that I remember it being rejected 16.45.10 # how would it be a context menu in a context menu? 16.45.15 # why not have a context-context menu? :) 16.45.22 # setting yes/no is hardly a 'context menu' 16.45.45 # it's not a menu at all... 16.46.29 # anyway, that's not the issue we're discussing 16.46.44 # New commit by 03Blue_Dude (r25875): Revert hotkey bitmaps 16.47.24 # All I'm thinking about is long-select on a context item, if it can be set as a hotkey then simply splash "set as hotkey? yes/no". that seems nothing like a context menu inside a context menu to me...and also seems like it would be pretty damn easy to understand.use. 16.47.37 # S_a_i_n_t: that's irrelevant to the current discussion, though :) 16.47.48 # S_a_i_n_t: it is a context menu (long Select on an item and the chose yes or no in this menu) 16.47.53 # well...kinda 16.48.00 # Stuck on "transmitting file data..." Help! 16.48.04 # how you set something as a hotkey is orthogonal to how you tell that something is hotkey-suitable 16.48.06 # if that was implemented...we wouldn;t be having the discussion ;) 16.48.11 # S_a_i_n_t: er, why wouldn't we? 16.48.16 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 16.48.25 # the icon thing is equally useful (or useless) whatever the method to set something as a hotkey 16.48.32 # i don't see the relevance 16.48.53 # yeah...I guess. 16.49.10 # Torne: not completely. As I said if you have every possible in a neat list you don't need other means to represent which is hotkeyable or not 16.49.18 # pixelma: well, ok, yes. 16.49.19 Join esperegu [0] (~quassel@145.116.15.244) 16.49.36 # pixelma: but that's a different thing that would tkae time to implement 16.49.44 # isn't the topic "should the icon thing be reverted"? 16.49.56 # yes, and yes, and done by the looks of it 16.50.12 Join S_a_i_n_t_ [0] (S_a_i_n_t@203.184.1.8) 16.51.43 # AlexP: no.. 16.52.25 # my understanding is that this change would make everything easier (icon thing isn't needed, so no setting for it) and setting the hotkey wouldn't have a unique way anymore 16.53.01 # Torne: Oh, just going by the commit message I thought that was what r25875 did 16.53.08 # New commit by 03Blue_Dude (r25876): Fix red 16.53.13 # Torne: I meant my suggestion with the above 16.53.35 # ah, right. that is what he meant it to do :) 16.53.41 Quit S_a_i_n_t (Ping timeout: 264 seconds) 16.53.42 # there we go 16.54.08 # pixelma: I tend to agree - what are the arguments against have list a list setting for the hotkey stuff? 16.55.07 Quit adnyxo (Ping timeout: 276 seconds) 16.55.08 # haven't seen any besides my own "might beecome too long" 16.55.22 Join jgarvey [0] (~jgarvey@cpe-065-190-066-089.nc.res.rr.com) 16.55.44 Join Schmo [0] (~Miranda@p3EE21842.dip0.t-ipconnect.de) 16.56.49 Quit Schmogel (Ping timeout: 265 seconds) 16.57.01 # All better now? 16.58.32 # Blue_Dude: What about a list setting for hotkey stuff? 16.58.45 # and personally, yes - thanks 16.59.56 # I don't have any objections to someone taking the changes to menu.c out and replacing them with a nested menu in settings. 17.00.14 # But it won't be me. I'm not interested in making those changes. 17.02.45 Quit n1s (Ping timeout: 246 seconds) 17.03.45 # New commit by 03Blue_Dude (r25877): Fix hotkey select behavior, ignore selection if menu item is not hotkeyable. Will not exit the context menu now 17.09.57 # Torne: that one was for you. 17.12.47 Part Zagor 17.13.10 Quit bgs000 (Read error: Operation timed out) 17.14.18 Quit petur (Quit: connection reset by beer!) 17.15.22 # Blue_Dude: thanks :0 17.15.28 # Blue_Dude: i'll see if i can sort the action.c issue at some point 17.15.35 # which will hopefully fix the problems for ipod 17.15.45 # (or in general targets where hotkey is a combination) 17.15.58 Quit kugel (Remote host closed the connection) 17.16.10 Join kugel [0] (~kugel@rockbox/developer/kugel) 17.16.35 Join n1s [0] (~n1s@rockbox/developer/n1s) 17.16.38 # Or we could go with "long select" to set a hotkey in the menu. }:-) 17.18.28 Join funman [0] (~fun@rockbox/developer/funman) 17.19.38 Quit B4gder (Quit: It is time to say moo) 17.20.22 # according to http://forums.rockbox.org/index.php?action=dlattach;topic=14064.0;attach=4211;image , r25845 needs 37mA for the Fuze, while last time I measured it needed 65mA 17.21.09 Join Schmogel [0] (~Miranda@p3EE21842.dip0.t-ipconnect.de) 17.21.17 # v1? 17.21.43 Join dfkt_ [0] (dfkt@unaffiliated/dfkt) 17.22.46 Quit FOAD (Quit: I'll be back) 17.23.18 # yes 17.23.20 Quit dfkt (Disconnected by services) 17.23.24 Nick dfkt_ is now known as dfkt (dfkt@unaffiliated/dfkt) 17.23.57 # no improvement from the dram patch? 17.24.25 # all i have is this graphic 17.24.42 # and I can't really tell a difference between red and blue curves 17.24.53 Quit Schmogel (Read error: Connection reset by peer) 17.25.05 # ah, the patch was applied to an older svn, so it should be compared to the green line 17.25.20 Quit Schmo (Ping timeout: 265 seconds) 17.25.35 # Something weird is going on in the sim since the file system changes were committed. All disk writes set the file to read only, and you obviously can't save changes again afterward. 17.25.42 Join dfkt_ [0] (dfkt@unaffiliated/dfkt) 17.25.57 Quit dfkt (Disconnected by services) 17.26.00 Nick dfkt_ is now known as dfkt (dfkt@unaffiliated/dfkt) 17.26.27 # kugel: but green is not the most recent too 17.26.42 Join Horscht [0] (~Horscht2@xbmc/user/horscht) 17.26.42 Quit bluebrother (Read error: Connection reset by peer) 17.27.08 Join bluebrother [0] (~dom@g226069230.adsl.alicedsl.de) 17.27.08 Quit bluebrother (Changing host) 17.27.08 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 17.27.47 # Sets config.cfg to read only after a write. 17.30.12 # For what it's worth, long select within the context menu works well to select a hotkey. The code has changed enough in the last few weeks to make that no longer a problem. 17.30.52 # So we could go with that and fix the yesno and action.c problems later. 17.33.37 # Blue_Dude: something is wrong here too 17.34.23 Quit lpereira (Quit: Leaving.) 17.34.24 # kugel: You mean with readonly? 17.34.44 # well, worse 17.35.31 # "Worse"? That covers a lot of ground. 17.35.50 Join fyrestorm [0] (~nnscript@static-71-249-251-152.nycmny.east.verizon.net) 17.37.08 Join FOAD [0] (~dok@83.160.60.104) 17.37.29 Join Schmogel [0] (~Miranda@p3EE21842.dip0.t-ipconnect.de) 17.38.01 # editing a text file in the text editor and saving it makes it 0 bytes 17.38.23 Join Boldfilter [0] (~Boldfilte@adsl-178-248-46.jax.bellsouth.net) 17.39.36 # That might be the case if you create a file as readonly then try to save to it. 17.40.08 # perhaps strace can help? 17.40.18 # that's a file with 0644 17.40.27 # http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-May/088151.html "is there someone who wants 17.40.31 # to work on merging the rockbox fixed point decoders back into ffmpeg?" 17.46.42 *** Saving seen data "./dancer.seen" 17.52.24 # Blue_Dude: hm, it also doesn't work after reverting the io.c changes 17.53.01 Quit esperegu (Remote host closed the connection) 17.53.10 # kugel: Yeah, I don't think it's in io.c. I tried changing the va cast in line 347 to avoid the warning and it is still a problem. 17.53.20 Quit freddy_ (Ping timeout: 240 seconds) 17.53.45 # kugel: with the posix change, did you change the way files are opened? 17.54.41 # well, a bit 17.54.55 # but in a way that should be more correct 17.56.43 # Hm. Are you really *sure* it isn't setting the readonly attribute anywhere when it writes to a file? 17.56.47 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 18.00.11 # kugel: BTW, I changed io.c, line 347 to this: 18.00.14 # yea, pretty 18.00.17 # - ret = OPEN(get_sim_pathname(name), opts, va_arg(ap, mode_t)); 18.00.19 # + ret = OPEN(get_sim_pathname(name), opts, va_arg(ap, unsigned int)); 18.00.43 # It gets rid of the warning but it's not "pretty" 18.00.50 # open() is always called with 0666 18.01.02 Join dfkt| [0] (~dfkt@chello062178002170.1.11.univie.teleweb.at) 18.01.05 # I don't know what 0666 is, but it sounds bad. :) 18.01.44 Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 18.02.14 Quit dfkt| (Remote host closed the connection) 18.03.04 # For some reason, the compiler doesn't like the mode_t type in the va_arg cast. 18.05.06 # not all types can be used with va_arg, presumably it's one of the incompatible ones on cygwin 18.06.43 Join freddy_ [0] (~freddy@p3E9E1925.dip0.t-ipconnect.de) 18.08.14 # adding a printf() shows that open (the system's one) is called with 0666 18.08.56 # domonoky: I'm planning to change RbUtilQt to keep track of the windows it spawns. This will also make it easier for the UI rework I'm planning to do eventually. Any arguments against this? 18.09.23 # how do you want to track that ß 18.09.50 # well, just track the pointers to the objects created with new() :) 18.10.49 # like, when creating a bootloader install object have a class pointer instead of a local one, and thus being able to delete the object when it's finished 18.11.15 # ah, yes that sounds fine. 18.13.08 # * domonoky thinks the bootloader switch case which creates the bootloader objects, should move into bootloaderinstallbase.cpp like its done for TTS objects. 18.13.43 Join M3DLG [0] (~M3DLG@212.183.140.35) 18.15.36 Join loveless [0] (~loveless@2a01:198:3a5:0:216:cbff:feb9:8c8d) 18.15.57 # domonoky: as in "return me the correct object"? 18.16.00 Join domonoky1 [0] (~Domonoky@g229099148.adsl.alicedsl.de) 18.16.11 # but that switch is getting longish indeed. 18.16.19 # yes.. 18.16.42 # getBootloaderInstaller(qstring name); 18.17.02 Join DerPapst [0] (~Alexander@p5099d40e.dip0.t-ipconnect.de) 18.17.16 Join raphi_ [0] (~raphi@pub082136118205.dh-hfc.datazug.ch) 18.17.22 Quit pamaury (Quit: Quitte) 18.17.30 Quit domonoky (Ping timeout: 252 seconds) 18.18.16 # I wouldn't call it get*, we don't have any get* methods (following the Qt style) 18.18.27 # but sounds fine otherwise 18.18.47 # New commit by 03bluebrother (r25878): Add repeat counting to system trace. ... 18.19.29 Quit DerPapst1 (Ping timeout: 264 seconds) 18.20.54 Join esperegu [0] (~quassel@145.116.15.244) 18.21.03 # bluebrother: any idea for a good name ? 18.21.26 # kugel: Have any problems with my changing the cast in io.c and committing it? Cygwin has a cow. 18.21.42 # does that fix anything for you? 18.22.36 Join DerPapst1 [0] (~Alexander@dslb-088-069-132-230.pools.arcor-ip.net) 18.23.18 # It avoids the compile warning and mode_t is typedef'ed to unsigned int. 18.23.19 Quit freddy_ (Ping timeout: 265 seconds) 18.23.23 # So no change there. 18.23.35 Quit adnyxo (Read error: Operation timed out) 18.24.28 Quit DerPapst (Ping timeout: 268 seconds) 18.28.25 Join Guest88847 [0] (dfkt@chello062178002170.1.11.univie.teleweb.at) 18.28.50 # domonoky1: maybe createMethodInstaller(QObject* parent, QString method)? 18.29.19 # "target" would be a bit ambiguous here even though I'm not too happy with "method" 18.29.57 # just use createBootloaderInstaller(QObject* parent, QString type) ? 18.30.11 # Blue_Dude: err, I found some bug :\ 18.30.27 # Uh oh. What was it? 18.30.30 Quit dfkt (Ping timeout: 260 seconds) 18.31.06 # Blue_Dude: casting to int is fine actually. it's passed as a variable parameter (i.e. unspecified type) and IIRC the default type is int 18.31.25 # the default type for integer literals I mean 18.31.45 # shadowing fd in open_wrapper() in plugin.c \ 18.32.13 # domonoky1: that's also an option. 18.32.19 # kugel: Since mode_t is an unsigned int, I'll change the cast to that. I don't want to change something inadvertently. 18.32.45 # I'll commit the fix (and the cast), don't worry 18.32.57 Join MethoS- [0] (~clemens@134.102.106.250) 18.34.35 # k, thanks! 18.34.55 # I didn't know if anyone was seeing it but me. 18.35.12 # Cygwin sim builds don't come up all that often. 18.35.17 Join freddy_ [0] (~freddy@p3E9E2AA3.dip0.t-ipconnect.de) 18.35.42 # New commit by 03pondlife (r25879): Minor const police raid. 18.36.51 # Blue_Dude: what you cast it to doesn't matter really, as the caller needs to re-cast it. 18.37.40 # OK. Just didn't want avoidable issues later with code I don't understand all that well. :) 18.37.41 # hmm, the front page not reflowing commit messages can produce quite interesting looking output :o 18.37.58 # Blue_Dude: does that work http://pastie.org/950314 ? 18.38.02 # callee* 18.38.27 Join pondlife [0] (~Steve@rockbox/developer/pondlife) 18.38.43 # Sorry - yellow fixage coming up.. 18.39.30 Nick Guest88847 is now known as dfkt (dfkt@chello062178002170.1.11.univie.teleweb.at) 18.39.46 Quit M3DLG (Ping timeout: 276 seconds) 18.40.00 Nick dfkt is now known as Guest18255 (dfkt@chello062178002170.1.11.univie.teleweb.at) 18.40.20 Nick Guest18255 is now known as dfkt|wtf (dfkt@chello062178002170.1.11.univie.teleweb.at) 18.41.05 # kugel: Gak. How do you use patch with that? 18.41.16 # New commit by 03pondlife (r25880): Fix yellow. 18.41.19 # I don't understand 18.41.33 # ah, I think you want -p1 18.41.40 # I use diff and patch. How do I feed that to patch it... 18.41.54 Quit MethoS- (Remote host closed the connection) 18.42.17 # OK, -p1 worked. 18.42.29 Quit dfkt|wtf (Changing host) 18.42.29 Join dfkt|wtf [0] (dfkt@unaffiliated/dfkt) 18.43.14 Join hebz0rl [0] (~hebz0rl@dslb-088-067-206-152.pools.arcor-ip.net) 18.45.18 # kugel: io.c line 348 conflicting types for 'mode'. 346 previous declaration was here. 346 unused variable 'mode'. 18.46.14 # oops, try this one 18.46.15 # http://pastie.org/950330 18.46.36 Quit esperegu (Remote host closed the connection) 18.47.43 # Getting rid of line 346 makes it behave. 18.47.56 Join esperegu [0] (~quassel@145.116.15.244) 18.48.21 Quit loveless (Quit: loveless) 18.49.20 Part pondlife 18.50.20 # Yeah, that last looks OK. I didn't repatch with it, only changed io.c manually to match. 18.53.17 Quit freddy_ (Ping timeout: 265 seconds) 18.54.27 Join pamaury [0] (~c2c7a50a@rockbox/developer/pamaury) 18.54.35 # kugel: pastie 950330 compiles OK. 18.56.34 # cool 18.56.44 # New commit by 03kugel (r25881): Fix disastrous variable shadowing, change casts to unsigned in (cygwin doesn't like mode_t there, and unsigned int should be equally correct) and ... 18.58.02 Join robin0800 [0] (~quassel@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) 19.00.39 Join Guest88847 [0] (dfkt@chello062178002170.1.11.univie.teleweb.at) 19.01.33 Quit antil33t (Read error: Connection reset by peer) 19.01.39 Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) 19.02.49 Join w1ll14m [0] (~w1ll14m@84-104-80-54.cable.quicknet.nl) 19.03.27 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 19.04.13 Quit dfkt|wtf (Ping timeout: 276 seconds) 19.04.58 Quit flydutch (Quit: /* empty */) 19.04.59 # kugel: have you opened fuzev2 already? 19.05.35 Join adb [0] (~4e565eaa@giant.haxx.se) 19.05.49 Join freddy_ [0] (~freddy@p3E9E050D.dip0.t-ipconnect.de) 19.06.04 # hey, is there a current SVN source archive available to download anywhere? 19.06.08 Join halmi [0] (~netbook@80-123-34-207.adsl.highway.telekom.at) 19.06.35 # adb: get it from svn ... 19.06.52 # funman: no 19.07.13 # kugel: \o/ 19.07.26 # krazykit: do you have pics of the fuzev2 battery? 19.07.34 # no access to svn right now, there used to be an archive on the build page, just wondering if it's been *moved* or *removed* 19.07.42 # we don't build it any more 19.07.46 # it's very big 19.07.48 # it's been removed 19.07.48 Quit Battousai (Remote host closed the connection) 19.07.52 # okies, thanks 19.08.00 # is svn over http possible? 19.08.09 # it isn't useful at all, if you want svn code get it from svn. Makes it much easier to update anyway 19.08.11 # funman: yes. svn over http is usual, in fact 19.08.17 # funman: yes, but that needs to get setup :) 19.08.19 # the native svn protocol is recommended not to be used 19.08.22 # because it sucks 19.08.25 # i mean possible for rockbox source 19.08.29 # oh. no. 19.08.34 # * bluebrother doesn't consider svn via http as usual 19.08.52 # bluebrother: well, the svn developers recommend you use it, and say that hte native protocol sucks :) 19.08.58 # kugel: Sim readonly is fixed. Compiles clean. Thanks. 19.09.04 # and every other svn repo i have access to other than rockbox is http 19.09.07 # Torne: interesting, haven't heard about that. 19.09.08 Join Battousai [0] (~bryan@gentoo/developer/battousai) 19.09.27 # bluebrother: the native protocol has only ever existed because CVS had one 19.09.38 # at no stage was it considered preferable by the devs 19.10.10 # they expect you to use http or svn+ssh 19.10.54 # I've seen quite a few servers using svn://. That might have been changed, though. Never paid too much attention to that. 19.11.40 # heh 19.11.48 # the manual claims differently, so maybe i am wrong 19.12.01 # but i have been told in the past when asking for help with it to give up and use http :) 19.14.05 # setting up svn:// is definitely much easier than http:// 19.14.14 # setting it up *trivially* yes 19.14.21 # setting up with proper encryption/authenticatoin/etc no 19.14.55 # who want to steal rockbox svn passwords anyway 19.15.32 # well, svn:// can't do encryption at all :) 19.16.09 # the "normal" config i've seen is http for read only access, and svn+ssh for writes 19.16.29 # but that requires local accounts for committers 19.16.44 # and if you want to do more sophisticated authentication svnserve is too limited (if suitable at all) 19.17.06 # though having http:// for read access for the Rockbox svn repo would be nice. 19.17.11 # I seems to me that the usual svn config is http for read and svn+ssh access, ssh doing basically all the encryption/auth work 19.17.25 # http for read is very easy as long as you control the machine that hosts it 19.17.34 # you just shove the modules into apache and add about three lines 19.18.06 Quit n1s (Quit: Lämnar) 19.20.02 # i dunno who hosts it and where, but if that's a feasible thing to do then it would probably be good ot do it 19.22.19 Quit freddy_ (Ping timeout: 240 seconds) 19.24.01 # FS#11247 is reopened for comments. The icon patch is there. If you want hotkey icons, that's the place to look. 19.25.56 Join Xerion [0] (~xerion@82-170-197-160.ip.telfort.nl) 19.26.53 # I also want to propose changing the "hotkey set" key in the context menu to long select. It works better than using the hotkey keypress itself in that role, especially when it's a combo. 19.31.32 Quit raphi_ (Quit: leaving...) 19.32.12 Quit adb (Quit: CGI:IRC (EOF)) 19.33.45 # You know you're just going to complain if I go ahead and commit it anyway, so you might as well get it off your chest now. :) 19.34.15 Quit Guest88847 (Changing host) 19.34.15 Join Guest88847 [0] (dfkt@unaffiliated/dfkt) 19.35.50 Join freddy_ [0] (~freddy@p3E9E1712.dip0.t-ipconnect.de) 19.38.13 Nick Guest88847 is now known as dfkt (dfkt@unaffiliated/dfkt) 19.39.01 Quit Xerion (Quit: ) 19.39.49 Quit esperegu (Read error: Connection reset by peer) 19.39.50 Join Blue_Dude_ [0] (~chatzilla@rockbox/developer/Blue-Dude) 19.40.50 Quit robin0800 (Remote host closed the connection) 19.42.19 Join DataGhost [0] (~dataghost@192-18-ftth.onsnetstudenten.nl) 19.42.20 Quit DataGhost (Changing host) 19.42.20 Join DataGhost [0] (~dataghost@unaffiliated/dataghost) 19.46.44 *** Saving seen data "./dancer.seen" 19.47.11 Quit kugel (Remote host closed the connection) 19.47.15 Quit Blue_Dude (*.net *.split) 19.48.30 Quit Blue_Dude_ (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 19.50.50 Quit freddy_ (Ping timeout: 245 seconds) 19.51.37 Join krabador [0] (~darkham@host155-182-dynamic.47-79-r.retail.telecomitalia.it) 19.53.29 Quit Hillshum (Ping timeout: 246 seconds) 19.54.30 # Torne: The Swedes on a machine they control 19.56.49 Part fleebailey33 20.02.18 Nick kenguest_ is now known as kenguest (~radagast@lir.talideon.com) 20.02.25 Quit arbingordon (Ping timeout: 260 seconds) 20.09.02 Quit funman (Quit: free(random());) 20.11.36 Join esperegu [0] (~quassel@145.116.15.244) 20.12.11 Join petur [0] (~petur@rockbox/developer/petur) 20.18.45 # New commit by 03Domonoky (r25882): rbutil: move bootloaderInstall object creation switches to bootloaderInstallBase . 20.22.12 Join freddy_ [0] (~freddy@p3E9E1712.dip0.t-ipconnect.de) 20.24.33 Quit TheSeven (Ping timeout: 260 seconds) 20.24.34 Quit krabador (Quit: Sto andando via) 20.25.18 Join halmi_ [0] (~netbook@80-123-46-81.adsl.highway.telekom.at) 20.27.29 Quit halmi (Ping timeout: 246 seconds) 20.28.28 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 20.28.53 Part watto1 20.30.20 Quit halmi_ (Quit: halmi_) 20.38.58 Join krabador [0] (~ubuntu@host155-182-dynamic.47-79-r.retail.telecomitalia.it) 20.39.47 Join Xerion [0] (~xerion@82-170-197-160.ip.telfort.nl) 20.39.53 Quit DerPapst1 (Quit: Leaving.) 20.44.21 Quit komputes (Ping timeout: 248 seconds) 20.57.14 Join kaniini_ [0] (~quassel@dyn75-70.yok.fi) 21.06.44 Join Buschel [0] (~ab@p54A3D5B3.dip.t-dialin.net) 21.21.02 Join dfkt|wtf [0] (~dfkt@d86-33-57-47.cust.tele2.at) 21.24.21 Quit dfkt (Ping timeout: 248 seconds) 21.24.36 Nick dfkt|wtf is now known as dfkt (~dfkt@d86-33-57-47.cust.tele2.at) 21.24.40 # New commit by 03gevaerts (r25883): Revert r25861, to avoid hiding real errors 21.24.56 Nick dfkt is now known as dfkt_ (~dfkt@d86-33-57-47.cust.tele2.at) 21.25.10 Nick dfkt_ is now known as dfkt (~dfkt@d86-33-57-47.cust.tele2.at) 21.25.40 # * gevaerts expects yellow 21.25.40 Nick dfkt is now known as Guest22225 (~dfkt@d86-33-57-47.cust.tele2.at) 21.26.31 Nick Guest22225 is now known as dfkt (~dfkt@d86-33-57-47.cust.tele2.at) 21.26.33 Quit dfkt (Changing host) 21.26.33 Join dfkt [0] (~dfkt@unaffiliated/dfkt) 21.27.43 # New commit by 03gevaerts (r25884): Fix size_t handling in plugin_get_buffer() 21.35.10 # New commit by 03gevaerts (r25885): fix one more size_t/ssize_t misuse 21.36.57 # New commit by 03gevaerts (r25886): Fix possible buffer overflow 21.37.47 Quit esperegu (Read error: Connection reset by peer) 21.38.19 Join esperegu [0] (~quassel@145.116.15.244) 21.41.05 Join ishottuify [0] (~4c422e86@giant.haxx.se) 21.41.15 Quit w1ll14m (Ping timeout: 245 seconds) 21.42.19 Join w1ll14m [0] (~w1ll14m@84-104-80-54.cable.quicknet.nl) 21.43.58 Join kugel [0] (~kugel@rockbox/developer/kugel) 21.46.47 *** Saving seen data "./dancer.seen" 21.50.10 # * gevaerts shouts at doom 21.51.18 Quit hebz0rl (Quit: Ex-Chat) 21.52.29 Quit w1ll14m (Ping timeout: 246 seconds) 21.54.25 Join DerPapst [0] (~Alexander@p5797C93A.dip.t-dialin.net) 21.54.46 # gevaerts: what's up with doom? 21.55.34 # it aliases 21.56.04 Quit ishottuify (Quit: CGI:IRC) 21.56.35 # It has two struct types that start with the same few members, and it casts between pointers to them 21.56.45 Quit esperegu (Read error: No route to host) 21.57.18 Join esperegu [0] (~quassel@145.116.15.244) 21.57.36 Join ishottuify [0] (~4c422e86@giant.haxx.se) 21.58.09 # can someone help me identify the parts on this pcb > http://www.rockbox.org/wiki/GoGearSA5245_SA5285 21.58.19 # gevaerts: it does a lot other bad stuff too 21.58.29 # doom is the reason we don't do eabi yet 21.58.33 # kugel: it probably counts as ancient code by now :) 21.58.35 # New commit by 03Buschel (r25887): Refactor mpc's requantization to use identical macros for each subframe. 21.59.22 # gevaerts: what are you trying do? (the build table shows no warnings in doom) 22.00.52 # I'd like to get rid of -fno-strict-aliasing everywhere 22.00.57 # ishottuify: telechip soc (tcc8300). presumably samsung ram 22.01.39 # gevaerts: you could add -fno-strict aliasing for doom only if it's unsolvable 22.01.53 # just to warn you, the ams dbop driver also aliases ;) 22.04.46 # ishottuify: the cirrus chip is probably the rtc 22.05.23 # I guess the toshiba one is the nand, I cannot identify the other chips 22.06.00 Quit esperegu (Remote host closed the connection) 22.06.20 # New commit by 03gevaerts (r25888): Remove -fno-strict-aliasing for everyone 22.06.37 # * gevaerts expects yellow for doom and midiutil 22.06.52 # kugel: thanks for your help 22.09.19 # ishottuify: we have some telechip code in svn (cowond2 most priminently) although no tcc830x specific code. you might also want to look at the tccboot utility (or whatever it's called) 22.09.52 # gevaerts: I thought that only applied for gcc 4.1.x? 22.10.25 # kugel: and higher 22.10.26 # RED 22.11.04 # right, but only mips uses higher something higher than 4.0.x? 22.11.17 # New commit by 03gevaerts (r25889): Fix (hopefully) last aliasing bug (midiutil), and enable -fno-strict-aliasing again for zxbox and doom (no easy fix there) 22.11.22 # kugel: also eabi :) 22.11.41 # ah yes, but that's not on the build table 22.11.54 # no, but I've done some local tests 22.12.32 # Also, that red is false! 22.12.39 # I wonder why there are reds for builds that are done with 4.0.3 22.12.41 # "note: initialized from here" is not an error 22.12.54 # kugel: there aren't 22.13.10 # ah, sim :/ 22.13.16 # * kugel hides 22.15.03 Join esperegu [0] (~quassel@145.116.15.244) 22.15.42 # kugel:by tccboot utility do you mean tcctool...? 22.17.22 # seems it's time to call for removing doom once more :) 22.17.52 # ishottuify: yea I think so 22.22.15 # So, patches on the mailing lists? IMHO, we need to keep everything in one place and that's what's Flyspray is for 22.22.46 # I don't think we *need* 22.23.34 # Fragmenting from one central place to more than one would lead to people being unsure where to post patches 22.23.40 # I can understand that people prefer on everything in wrong place but I don't care much. but most, if not all, other foss projects accept both and some even prefer the ml so I don't see why we should act so weird 22.23.48 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 22.24.55 # but I don't understand the argument that we cannot track ml patches 22.25.46 # evilnick_B: where's the problem in having a short look at the patch, and if it looks good asking the poster to put it on flyspray? 22.26.35 # why go through fs and not commit it straight away? 22.27.08 Quit Xerion (Ping timeout: 240 seconds) 22.27.33 # bluebrother: I've got no personal objection to that whatsoever (not being a dev) but I thought that the general consensus would be to have just one place 22.27.48 # kugel: where in the repository is the telechip code you mentioned above 22.28.24 # if you can judge the patch because you are familiar with the affected code base and are willing to do it. But a patch sent to the ML might be non-trivial 22.28.37 # ishottuify: the tcctool should be in tools/, the code for older telechips firmware/target/tcc* 22.28.45 # firmware/target/arm/tcc* 22.29.23 # I think it's pretty reasonable to ask, nicely, that patches posted to the ML be reposted to the tracker and that discussion happen there. 22.29.25 # bluebrother: and flyspray helps there? 22.29.37 # The tracker can be sorted and searched nicely in ways that the ML cannot. 22.29.55 # The ML doesn't have categories, you can't filter "patches only" or see closed patches or so on. 22.30.00 # post on ml, dicuss on ml - post on fs, discuss on fs. seems pretty interchangeable for me 22.30.36 # kugel: yes, of course. Because a non-trivial patch is likely to require a couple of rounds going through it (in FS terms: comments and updated patches), and given that the ML is extremely low traffic I don't see this working on the ML 22.30.40 # kugel: assuming a few days from post to commit, it's interchangeable. We don't have that though 22.30.47 # kugel: Tell me how to search the ML for only patches that claim to affect "playlist" and I'll buy that they're interchangeable. 22.31.06 # gevaerts: Even then, sometimes the history of a discussion of a patch is helpful. A commit with a FS# points you immediately at the discussion. 22.31.47 # In a very simplified "post, comment, commit" round they're interchangeable. But from a record keeping standpoint, FS is vastly superior for patches. 22.32.15 # *if* there is a common style how to send patches to the ML (f.e. with subject lines always starting with "PATCH: ") then this can work easily. But it also requires that developers use the ML for shuffling around patches. Which isn't done on that list. 22.32.34 Join lpereira [0] (~lucien@112.46.70-86.rev.gaoland.net) 22.32.48 Quit esperegu (Remote host closed the connection) 22.32.53 # bluebrother: And we'd still need a standardized list of category names (and probably a way of referencing a specific mail when they get committed) 22.33.22 Join esperegu [0] (~quassel@145.116.15.244) 22.34.08 # Llorean: yes. We need at least some "general sense" how to handle those. Which we don't have as patches are usually not handled on the ML. 22.34.11 # ok, I can see that fs is preferred, but do we really need to force people to use it if it's already posted on the ml? I can also imagine people being hesitent about registrating there 22.34.31 # kugel: what do you mean my cowond2 22.34.44 # ishottuify: that's a dap that has a tccip 22.34.45 # kugel: Come up with a way to address the searching and record keeping issue yet, or just ignoring that? 22.35.28 # for trivial patches that can go in almost immediately I don't see a reason to "force" people to use FS. For everything else, we do. Time is limited, and we can't afford to establish yet another partly working process just for people sending in patches rarely 22.36.13 Quit esperegu (Remote host closed the connection) 22.36.29 # * kugel finds discussing on mls much more convinient that on fs 22.36.44 Join esperegu [0] (~quassel@145.116.15.244) 22.36.56 # kugel: How so? Both is "type text, click send" 22.37.21 # * bluebrother whispers "proper threading" 22.37.27 # with mail, you can pick your own client of choice 22.37.28 # and quoting 22.37.35 # and what Bagder said 22.37.38 # * gevaerts whispets "who clicks anyway?" 22.38.20 # Bagder: To an extent, there shouldn't be too many long term branches in the discussion of a patch, but that is a fair point. 22.38.30 # Er, that was to bluebrother 22.38.37 # :-) 22.38.58 # Bagder: do you have opinions on http://pastebin.com/Zwmf4HHw ? 22.39.00 # But I'd still like to know how we'd track ML submissions like we do FS. 22.39.05 # anyway, as the current status quo is to use FS for patches there's no point in using yet-something-else. If we feel that we need a better solution than FS we can always debate that and try to find something better. 22.39.21 # IMO FS is quite a good tracker. I've seen much worse. 22.39.22 # gevaerts: no ;-) 22.39.54 # doing on the ML instead of FS takes a switch in mindset 22.39.58 # I don't want to replace FS, but adding alternatives ways 22.39.58 # Right now FS allows categorical searches, something we can't really do on the ML except if you get people to agree to standardized subjects, and they'd become quite bulky to include all the information you can sort FS by 22.40.12 # debbugs! 22.40.19 # Bagder: indeed. Something like switching vom VCS to DVCS :) 22.40.28 # Bagder: ok, I'll ask Zagor when he appears 22.40.33 # kugel: Do you have a proposal for how to make ML patches searchable then? 22.40.56 # I can search my emails just fine in my client 22.40.59 Quit esperegu (Read error: Connection reset by peer) 22.41.09 # well, one thing would be an email interface to FS. You get a notification from FS, reply to it and it becomes a new comment in FS 22.41.11 # lots of even higher patch-volume projects than Rockbox deal with patches on the ML only, so it clearly can be done 22.41.15 # kugel: Yes, which doesn't help people who weren't previously subscribed to the list. 22.41.28 # and there's software to search in mail archives. that's no rocket science 22.41.29 Join esperegu [0] (~quassel@145.116.15.244) 22.41.33 # bluebrother: yes, that's what debbugs does. You can even download a bug in mbox format 22.41.35 Quit fyrestorm (Read error: Connection reset by peer) 22.41.36 # Bagder: Which is why I'm asking for a solution for how to make it as effective as FS, rather than just saying "we shouldn't do it" 22.41.38 # Bagder: maybe that's because those *are* higher volume? 22.42.05 # Llorean: well, you then focus on the pros with FS, there are also several cons that the ML satifies 22.42.14 # kugel: I'm asking for a way to allow people not previous on the -dev list to search through patches on -dev relating to a specific subject. 22.42.30 # I'm not really taking a position here btw, I'm just talking 22.42.52 # Bagder: Yes, so the question becomes deciding listing the pros and cons of each, and deciding how much each matters to us. But you have to determine them first, and see which ones can be overcome or easily worked around. 22.43.03 # Llorean: typically on those projects, people repost their patch after a while if it wasn't dealt with 22.43.05 # Llorean: search in mail archives as I said 22.43.06 # http://bugs.flyspray.org/task/961 22.43.32 # kugel: If I search in the mail archives for "patch" and "playlist" I'll probably not actually find any messages that includes a patch for playlisting behaviour. 22.43.47 # * bluebrother would start with deciding if we feel a need to change anything :) 22.44.07 # searching in the mail archives is a real pain since Outlook and fullquotes 22.44.11 # Llorean: the flyspray search is largely useless as well 22.44.23 # the FS search works fine for me ... 22.44.27 # if you couldn't select categories you'd hardly find what you want 22.44.34 # I've used the flyspray search a few times with very useful results 22.44.36 # kugel: I disagree. Constraining it to "patches" vs "bugs" is a huge benefit right there. 22.44.41 # the FS does have the downside that people submit something, and then it sits there and rots 22.44.42 # bluebrother: it's too greedy imo 22.45.24 # kugel: "if you couldn't select categories?" What's the point of saying "the search would be terrible if you disabled some of its features?" 22.45.27 # a big problem with searching is always how the users enter the text. If one mistypes "playlist" as, maybe "paylist" then a search for playlist won't find it. 22.45.47 # that problem remains regardless of the tool used 22.46.20 Quit esperegu (Remote host closed the connection) 22.46.38 # Bagder: I'm not sure how much the ML could improve that though. That requires proactiveness on the part of the author, mainly 22.46.53 Join esperegu [0] (~quassel@145.116.15.244) 22.47.05 # Typos are why there are specific categories 22.47.09 # Llorean: it makes it more clear that unless you stick around and keep nudging, your work gets left behind 22.47.09 # Llorean: it changes how ignoring a patch is perceived 22.47.32 # its both good and bad 22.47.42 Mode "#rockbox +o logbot" by ChanServ (ChanServ@services.) 22.47.44 Quit esperegu (Remote host closed the connection) 22.47.51 Join intrados [0] (~intrados@adsl-99-66-45-47.dsl.wotnoh.sbcglobal.net) 22.47.52 # having a set of categories you can pick the one that's matching best is definitely helpful for users. That's at least my experience. 22.48.11 # topics on the ml are seen by everyone so there are much more people notified, no matter if one has knowledge about it or cares, I believe reduces the chances for rotting 22.48.14 # bluebrother: I agree 22.48.16 Join esperegu [0] (~quassel@145.116.15.244) 22.48.39 # kugel: just subscribe to rockbox-sf ... 22.48.46 # kugel: Only for people subscribed to the ML. It's just as easy to subscribe to tracker notifications. 22.48.52 # People simply choose not to. 22.49.17 # bluebrother: The categories also help a lot for someone like you, I imagine, who can search for things pertaining to rbutil or what not? 22.49.22 Quit esperegu (Remote host closed the connection) 22.49.32 # kugel: So what about automatically adding an email to the ML each time a FS patch is added? But then that would have the disadvantage of some replying to the ML post, and some on FS 22.49.32 # Llorean: that requires an explicit action for each task, on the ml it's subscribing once 22.50.02 # Llorean: definitely. I have a permanent search stored that shows me everything related to rbutil -- and manual (as I'm still following that loosely) 22.50.04 # evilnick_B: we have a mailing list with that already 22.50.26 # evilnick_B: I think that's a good idea, but I don't what you fear would happen (or only a few times if people are getting told for doing that) 22.50.57 # * kugel always forgets about rockbox-sf 22.51.06 # kugel: wrong. There's already a mailing list, and that also requires subscribing once only. 22.54.23 Join MethoS- [0] (~clemens@134.102.106.250) 22.54.27 Quit dfkt (Read error: Connection reset by peer) 22.54.36 # kugel: Flyspray can be subscribed to via a ML or via RSS feed, making it actually pretty easy to hear about new tasks. 22.57.14 # * Llorean wonders why the ML is expected to get more attention anyway. 22.57.27 # Don't authors asking for comments on their patch on the ML often complain that even that doesn't work to get people to speak about it? 22.58.46 # New commit by 03funman (r25890): as3525v2: make sure volume is normal by writing Audioset2 register ... 22.59.27 # Either way, there was no need at all for the needlessly rude reply the patch e-mail got 22.59.56 Quit TheSeven (Ping timeout: 260 seconds) 22.59.57 # AlexP: right 23.00.05 # the other project I'm involved in allows patches send via both ways, and it works pretty well. and I definitely am more notified by the ml way and also tend to post a comment on the ml (because I find it more convinient) 23.00.29 # the large majority of the project I'm in do everything on the ML 23.00.33 # projects 23.00.52 # did anyone say that patches on the ML are *disallowed*? 23.00.55 # I don't object/prefer either in principle, but given our already poor record on patch reviewing I think we ought to pick one and stick to iy 23.01.23 # * bluebrother agrees with AlexP 23.01.33 # I think we've already pretty much picked our way, it's not that easy to shift without a big intervention 23.01.35 Quit domonoky1 (Read error: Connection reset by peer) 23.02.12 # Bagder: I was sort of edging towards that :) 23.02.15 # Bagder: but maybe that shift is also not easy for contributors that are used to the ml procedure 23.02.34 # where fs *might* scare them off 23.02.40 # I doubt that 23.02.54 # monitoring two channels takes up more time and effort. If people are willing to do that I won't intervene. However, I do have a full time job and do have neither time nor interest in doing that. 23.03.31 # maybe you could quit your job and just do rockbox support for free? :-P 23.03.33 # (and I guess a noticable amount of devs has the real world job issue) 23.03.37 # * AlexP will ask him politely to post to flyspray 23.04.15 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 23.06.37 Quit TheSeven (Read error: Connection reset by peer) 23.06.41 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 23.06.44 # gevaerts: I tried to bring up a sdl-target-tree discussion a few times now, nobody answered. I would like to proceed with that 23.07.18 # Can the tracker be configured to automatically close tasks if they aren't commented on / updated within a certain amount of time? 23.09.01 Quit intrados (Quit: WeeChat 0.3.1.1) 23.09.21 # kugel: I'd say "nobody answered" is a bit strong. We're just all digging our trenches to be ready for the *real* discussion :) 23.10.30 Join wodz [0] (~wodz@chello087206240004.chello.pl) 23.10.52 # kugel: Seriously though, maybe a detailed proposal on the wiki might help? 23.10.57 # Llorean: I don't think it can 23.11.16 # you can always write a script that does ;-) 23.11.36 Quit freddy_ (Ping timeout: 260 seconds) 23.11.37 # that you can 23.11.55 # gevaerts: how detailed? the more detail is wanted the more I'd actually do part of the work already I think 23.12.50 # I moved the audio bits to the target tree as an example (I linked it at some time here) which shows pretty much how it'll look like 23.14.48 # kugel: a description of maybe a few paragraphs of what moves where and how the sim is impacted. Wiki or ML I'd say 23.18.02 # Bagder: IIRC FS has support for dokuwiki wiki syntax. Is there a reason this doesn't work in our installation? 23.18.12 # I have no idea 23.19.19 # would be nice to have. Like for marking quotations :) 23.25.21 Join freddy_ [0] (~freddy@p3E9E1CA5.dip0.t-ipconnect.de) 23.30.48 Quit evilnick_B (Quit: Page closed) 23.31.01 Quit MethoS- (Remote host closed the connection) 23.32.40 Quit ishottuify (Quit: CGI:IRC) 23.34.36 Quit petur (Quit: Leaving) 23.36.56 # New commit by 03Buschel (r25891): Unroll mpc's requantization loops for some (minor) speed up. 23.37.56 Quit wodz (Ping timeout: 265 seconds) 23.40.23 Quit TheSeven (Remote host closed the connection) 23.41.22 Join petur [0] (~petur@rockbox/developer/petur) 23.41.47 Join M3DLG [0] (~M3DLG@bb-87-81-252-83.ukonline.co.uk) 23.41.51 Quit ender` (Quit: If you're going to do something tonight that you'll be sorry for tomorrow morning, sleep late.) 23.42.27 # New commit by 03Buschel (r25892): Changes in test_mem plugin: Use correct formula to calculate KB/s, reasonable unrolling of read/write loops to better match memory bandwidth. 23.46.25 Join fdinel [0] (~Miranda@modemcable235.127-131-66.mc.videotron.ca) 23.46.49 *** Saving seen data "./dancer.seen" 23.47.07 Quit CGL (Quit: Soy spammero http://wiki.n00b2hack.com.ve ---- \m/ d(>.<)b \m/) 23.47.18 # Buschel: we have "HZ" for that :) 23.48.18 # Buschel: x was not volatile for a reason 23.48.23 # hmm, you're right... :/ at least the results are correct now :) 23.49.11 # buf is already volatile, so the read is not optimized. with x volatile as well you have both reads and writes in the read test 23.50.15 Join Xerion [0] (~xerion@82-170-197-160.ip.telfort.nl) 23.50.16 # since x is on the stack it's even worse 23.50.23 Quit Llorean (Quit: Leaving.) 23.51.09 # kugel: wouldn't the compiler reduce the 4 buf-reads to just the final one? 23.52.26 # no 23.52.26 Quit lpereira (Quit: Leaving.) 23.52.26 # I checked the disassembly. I also experimented with unrolling and it was still correct 23.53.40 # interesting. this change was indeed several weeks old. I just submitted this because of the incorrect caluclation of the result. 23.53.40 # maybe I'll roll back the "volatile" and use "HZ" after the next clean build has finished 23.53.40 # sounds good 23.56.14 # * Buschel opens another beer