--- Log for 11.12.117 Server: orwell.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 2 months and 11 days ago 00.01.14 # This (old function selection code) actually makes it work again but doesn't seem like what you intend: https://pastebin.com/p3QzWJEQ 00.04.47 # are you sure? I'm pretty sure it still wouldn't be null?? 00.08.09 # what wouldn't be NULL? the function? 00.08.37 # get_context_map 00.08.53 # not following... 00.09.28 # ok so its looking for context & CONTEXT_PLUGIN && get_context_map != NULL 00.09.30 # the internal ones don't set CONTEXT_PLUGIN 00.09.40 # yeah, two things 00.10.00 # get context_map still isn't NULL 00.11.13 # the same thing happens when initializing cur_action.. at #862 00.11.18 # why would that matter? the flag is 0 00.13.17 # pictureflow passes back -> LAST_ITEM_IN_LIST__NEXTLIST(CONTEXT_PLUGIN|1) 00.15.38 # which sends it to pf_context_buttons[], right? 00.15.43 # <[Saint]> lol - I always get soo tense when I see you guys messing about with list handling. 00.15.53 # <[Saint]> you're upsetting my delicate ecosystem of bandaids and prayer! 00.16.19 # [Saint]: gotta mess up all the lists! 00.17.04 # yes which has no end of list marker 00.17.05 # Bilgus: then after it exhausts pf_context_buttons, it specifies CONTEXT_TREE, unless it's M3 of course 00.17.38 # and thats just an index that isn't in pf_context 00.17.42 # <[Saint]> The icon display choices for some(most?) of the lists are just so arbitrary sometimes I ended up just going "fuck it". 00.17.49 # Bilgus: why should it? as I read it that tells it to increment and try the next plugin context 00.18.07 # <[Saint]> In my icon set *everything* that's either a standalone setting or a setting with sublists just gets the same icon. 00.18.22 # <[Saint]> I couldn;t handle the inconsistency so I just nuked it from orbit with a coat of paint. 00.18.34 # it needs to be in action.c ~#604 context = get_next_context(cur->items, i); 00.18.34 # (+) cur->items = get_context_mapping(context); 00.19.10 # or something along those lines instructing it to go back to the internal mapping 00.19.58 # only reason the that context tree one is working is because its never falling through to it 00.20.33 # you only noticed the issue on your device because it has def USE_CORE_PREVNEXT 00.21.20 # it's not defined on my device 00.21.37 # it's a gigabeat S so has no scrollwheel 00.21.42 # same for the clip 00.24.37 # hmm 00.25.16 # the last item just links the structs together: "try plugin context index 1". 00.26.22 # I just added it and compiled and it still crashes 00.26.42 # added what? 00.27.03 # the diff you posted 00.27.30 # mine wasn't crashing 00.28.45 # O_o 00.29.31 # I'll try the clip now 00.31.09 # that's fine with the diff too 00.32.08 # pictureflow doesn't regulate its speed very well 00.32.41 # I think I have a better option worked out brb 00.32.58 Quit pamaury (Remote host closed the connection) 00.38.34 # ah ok if you were to pass back CONTEXT_PLUGIN like with USE_CORE_PREVNEXT it would be back to crashing the only reason what you posted works is because its switching to the internal functions again 00.39.35 # oh duh nevermind -- 00.39.39 # * Bilgus stupids 00.42.22 Quit petur (Remote host closed the connection) 00.47.51 Quit ender` (Quit: In a perfect world… spammers would get caught, go to jail, and share a cell with many men who have enlarged their penisses, taken Viagra and are looking for a new relationship.) 01.01.07 Quit krabador (Quit: Leaving) 01.09.16 # ok jhMikeS I got down to why I was so confused and what you changed does fix the issue you pointed out but not the issue I exposed that made the same issue happen but slightly different series of events ok so the reason your diff fixed the issue is that pictureflow passes in CTX_PLUGIN which allows it's button mapping to take the first table it encounters and use it and then switches to the internal mapping for any subsequent 01.10.43 # but if there were more than 1 table for it to look up like with USE_CORE_PREVNEXT then it still fails which is what I exposed 01.17.03 Quit michaelni (Ping timeout: 248 seconds) 01.17.34 # see: https://github.com/Rockbox/rockbox/blob/03dd4b92be7dcd5c8ab06da3810887060e06abd5/apps/plugins/lib/pluginlib_actions.c 01.18.02 *** Saving seen data "./dancer.seen" 01.27.22 # there were two tables to look at though (hence CONTEXT_PLUGIN|1 ) 01.30.41 Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) 01.31.15 # pictureflow doesn't use anything there 02.23.43 Quit Guest56968 (Ping timeout: 248 seconds) 02.24.02 # JhMikeS you were right I'm not sure why I was having such a hard time wrapping my head around it 02.28.25 Quit dys (Ping timeout: 240 seconds) 02.28.38 # g#1762 02.28.41 # 3Gerrit review #1762 at http://gerrit.rockbox.org/r/1762 : 3Fix error with action subsystem and custom context mapping by William Wilgus 03.04.13 Quit Moarc (Ping timeout: 248 seconds) 03.06.32 Join Moarc [0] (~chujko@a105.net128.okay.pl) 03.10.41 # Bilgus: I was thinking you could just embed a pointer to the next context map or something in the element 03.13.12 # then again that has its own nasty repercussions... 03.18.03 *** Saving seen data "./dancer.seen" 03.19.59 Quit this_is_a_nick (Remote host closed the connection) 03.29.00 Join Bilgus_ph [0] (4cf32773@gateway/web/freenode/ip.76.243.39.115) 03.29.57 Quit snw (Quit: User was destroyed by a weapon of mass destruction.) 03.30.37 Join snw [0] (~snow_bcks@ganon.dot-server.net) 03.34.32 # jhMikeS: I think the only safe option besides checking the context + map like it was before is what is in pluginlib_actions, pictureflow is the only thing using get_custom_action besides it though 03.41.20 Quit Bilgus_ph (Quit: Page closed) 03.53.44 # Bilgus: the callback is such a wart though 03.55.20 # One question I have is if hwcodec is supposed to forked, expunged or whatever, why is it still in the build rounds so that you still have to tiptoe around it? 03.56.31 Join this_is_a_nick [0] (~amofiuhr_@ip60-237-64-186.ct.co.cr) 04.07.23 # No one has moved towards removing it.. 04.10.09 # it's a lot of moving if mr. someone has to do all the work at once 04.11.35 # i think the better option is to fork it where it sits and then remove the targets 04.11.56 # and as we go through we can remove the remaining conditionals 04.13.08 # I did that latter by hand once. Didn't actually take very long. After that, I got distracted away from what I was doing there. 04.16.20 # well, no I suspect not its pretty nicely delineated.. 04.33.52 # <[Saint]> in some places. 04.34.25 # <[Saint]> jhMikeS: sounds like my push for main menu tidying 04.34.48 # <[Saint]> I got about 90% of the way there and went "what the fuck am I doing with my life?" and rage quit the git repo. 04.36.24 # main menu tidying? 04.37.07 # <[Saint]> Apparently I'm the only one that notices it or is bothered by it but the menus are a dumpster fire. 04.37.34 # <[Saint]> Things just seem haphazardly scattered all over the place. 04.37.51 # you mean the code or the UI? 04.38.23 # <[Saint]> A little A, a little B. 04.39.06 # <[Saint]> Mostly the end result. The UI. How it's organised in the source doesn't matter /too/ much. 04.39.34 # well....it does if you have to edit it :) 04.40.55 # I find it a bit more strewn about in the source. Most of the menu I never even look at. I think I opened the FF/RW playback menu for the first time about 2 weeks ago to see what it was. 04.42.50 # And "Skip Length" right after that. I just opened a few more I've never looked in. :) 04.47.18 # <[Saint]> Main menu: 04.47.18 # <[Saint]> ... 04.47.18 # <[Saint]> Settings - System 04.47.18 DBUG Enqueued KICK [Saint] 04.47.18 # <[Saint]> ... 04.47.18 # <[Saint]> System 04.47.31 # <[Saint]> That bothers me to an unreasonable extent. 04.49.58 # would renaming it to Debug help? :p 04.50.27 # I hate the menu system internally but its kinda the nature of the beast 04.51.43 # <[Saint]> I honestly think it would be more at home as something like "Settings - Info" 04.52.03 # The first three aren't really debug stuff 04.52.08 # <[Saint]> At the very least there's no logical reason why it needs to be a toplevel menu entry. 04.52.37 # <[Saint]> no one has ever needed toplevel menu access to this menu structure ever. 04.53.07 # I don't mind that it is though. It is frequently visited. But the more useful screens are in shortcuts anyway. 04.53.39 # <[Saint]> frequently visited by whom? 04.53.44 # me 04.53.52 # <[Saint]> the dozen developers or the thousands of users? 04.54.01 # <[Saint]> rhetorical question BTW 04.54.14 # Debug (You'll Be Here A Lot) 04.54.42 # <[Saint]> For the overwhelming majority that's literally never oging to be true though. 04.54.46 # <[Saint]> Kinda my point. 04.55.11 # <[Saint]> I don't even think it should exist in the menu structure without a magic token. 04.55.21 # developer mode? 04.55.43 # <[Saint]> We could easily make it a toplevel menu but hide it by default. Then jam the other three entires from System into Settings - Info 04.55.46 # just add a config entry for it by hand 04.55.57 # no menu item 04.56.00 # <[Saint]> We already have the mechanism to hide toplevel menu entires and reposition them through config.cfg 04.56.19 # never really looked into that 04.56.42 # <[Saint]> from memory it's the menu_order config param. 04.56.57 # <[Saint]> perhaps main_menu_order, we seem to like descriptive identifiers. 04.58.45 # <[Saint]> developers who _really_ wanted it there 24/7 could just add the change to the config in as fixed.cfg 04.59.06 # <[Saint]> I am still right that fixed.cfg is parsed last and overrides config.cfg am I not? 04.59.14 # <[Saint]> I haven't actually tested that in a while. 04.59.17 # General Settings should be largely flatted right into Settings 04.59.23 # *flattened 04.59.27 # <[Saint]> Yes! 04.59.35 # <[Saint]> A man after my own heart. 05.00.02 # <[Saint]> So far that's two changes I've proposed that you've come up with independently. 05.00.13 # <[Saint]> Makes me think I'm not entirely insane, or we both are. 05.00.16 # <[Saint]> Either works for me. 05.01.40 # it's too many clicks deep to get into some items. 05.02.25 # some clearly playback-related functionality is General Settings for some reason 05.02.36 # <[Saint]> Just changing repeat or shuffle is quite ridiculously complex if you're not aware of the Quickscreen. 05.02.46 # <[Saint]> Which in my experience seems to be about ~90% of users 05.02.57 # That's only two deep to see it 05.03.39 # wouldn't one think hmmm..."sounds like a playback thing?" 05.04.18 # though it has a certain urgency, almost as immediate as a volume control 05.05.54 # <[Saint]> It would be difficult to achieve and I'm aware it wouldn't be a popular opinion but I'm inclined to think Rockbox needs a "simple" menu setting. 05.06.30 # maybe unlock achievements? :) 05.06.40 # <[Saint]> The Sound Settings menu is....well, it's something. 05.07.51 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 05.07.51 # * [Saint] eye twitches 05.08.10 # <[Saint]> Some of the child menus have capital letters and others don't. 05.08.16 # <[Saint]> I can't unsee it. 05.09.12 # <[Saint]> Settings - Theme Settings - Browse Themes, and 05.09.12 # <[Saint]> Settings - Sound Settings - Equalizer are ones I've found just now poking around. 05.09.29 # <[Saint]> Once you enter them their list title is lower cased. 05.09.57 Join _jhMikeS_ [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 05.09.57 Quit jhMikeS (Disconnected by services) 05.09.58 Nick _jhMikeS_ is now known as jhMikeS (~jethead71@d192-24-173-177.try.wideopenwest.com) 05.14.35 # at least it just lists independent effects in a straight menu for the most part 05.15.59 # one thing that I didn't put together right away was the connection between Channel Configuration and Stereo Width 05.17.16 # <[Saint]> There aren't many "self cancelling" menu combinations, but, yes - that's one of them. 05.17.53 # <[Saint]> stero width, 200% 05.17.53 # <[Saint]> channel configuration, mono 05.17.59 # <[Saint]> checkmate athiests. 05.18.07 *** Saving seen data "./dancer.seen" 05.19.35 # <[Saint]> I mean...how do you even handle cases like that with the way we handle menus? 05.19.40 # Crossfeed is similar now 05.20.03 # <[Saint]> There's no way to effictively tell the user something is happening if we "hand hold" and do it for them. 05.20.32 # <[Saint]> Setting a stereo width other than 100% should probably set the channel configuration to custom. 05.20.44 # <[Saint]> But we can't tell the user we did it or that it happened in a meaningful way. 05.20.57 # <[Saint]> So we just let them apply settings that might do literally nothing. 05.22.46 # <[Saint]> Hmmmm, there's a thought. Do we break EU law by not enabling a safe listening volume target by default? 05.24.00 # you mean maximum volume setting achievable by default? 05.24.09 # <[Saint]> Yes. 05.24.48 # well, heck, I don't know the letter of that law 05.26.39 # <[Saint]> Hmmmm, like all things EU it seems complex. 05.26.43 # <[Saint]> "None of the standards currently prescribe any maximum pressure limit nor require any specific labelling in respect of noise emissions but require that a statement be put in the instruction manual to warn against adverse effects of exposure to excessive sound pressure.: 05.26.49 # ask the kind of Sweden if it's too loud 05.27.50 # <[Saint]> One thing I'm really not sure of but I /think/ I'm right about... 05.28.02 # <[Saint]> Our dB measure for volume is all just viscious lies, no? 05.28.55 # <[Saint]> It realy looks to me like it would be a shitload simpler to just scale everything to a nice clean positive percentile. 05.29.05 # no, it's dBFS, relative to the unity volume limit 05.32.26 # it's just that the 100% gain level corresponds to very different physical power levels depending on many things like the player and headphones 05.34.25 # <[Saint]> Maybe I get tripped up on the wording of it. Knowing it's dBFS makes a little more sense to me, but I don't really understand how we can then go into positive decibel ranges. 05.34.47 # <[Saint]> in dBFS (correct me if I'm wrong, please), isn't 0dB always going to be peak amplitude? 05.35.50 # +6 = amplify the signal by a factor of 2 (roughly). 20*log(2) ~= 6.0205999... 05.35.51 # <[Saint]> My understanding was that dBFS always had 0 or sub-zero values with 0 being peak amplitute. 05.37.19 Quit CR0W (Ping timeout: 248 seconds) 05.37.24 # -6 = amplify the signal by a factor of about 1/2. 20*log(0.5) ~= -6.0205999... 05.38.22 # so 0 means the amp puts out a full-scale signal at the limits of the amp. anything gain above that will cause clipping. 05.38.46 # <[Saint]> I need to redo my signal theorum modules again I guess. 05.38.47 # <[Saint]> I just seem to be categorically at odd with understanding this. 05.39.25 # <[Saint]> I don't even really understand the context of 'peak amplitude' here. Doesn't a properly dithered digitial signal havy infinite amplitude? 05.39.56 # <[Saint]> Errr, sorry for derailing - in University I just never had anyone who could put this to me in a way that I "got". 05.40.10 # <[Saint]> signal theory wasn't ever my bag. 05.42.41 Join CR0W [0] (narf@2001:0:53aa:64c:2cec:18dd:b306:4fe9) 05.42.41 Quit CR0W (Changing host) 05.42.41 Join CR0W [0] (narf@unaffiliated/em64t) 05.46.17 # ummm....no if it's dithered you can lower the quantization floor arbitrarily, but it's like say you can put a tiny white dot on an arbitarily large black canvas to get aribrary dark gray levels 05.49.54 Join saratoga [0] (12650869@gateway/web/freenode/ip.18.101.8.105) 05.50.03 # 0dBFS -> full scale wav file will play without clipping 05.50.46 # 6dBFS - > half amplitude (-0.5 to 0.5) wav file will just barely play without clipping 05.50.55 # <[Saint]> in a model system only, presumably? 05.51.07 # assuming we calibrated correctly, in rockbox 05.51.35 # i bet a few of the drivers are off by a dB or so though 05.51.52 # <[Saint]> in a log system that's a pretty wide berth. 05.52.47 # the definition of full scale often depends on the exact voltages you feed the amp anyway, so hardware tends to be conservative 05.53.02 # not a big deal if you waste a db of volume control, but it sounds bad if you clip 05.53.38 # saratoga: I think it was the chip designers that had to calibrate 05.54.00 # yeah if there is a datasheet 05.54.16 # AMS was literally just dfkt increasing the gain 1 dB at a time and measuring THD 05.54.24 # <[Saint]> I'm likely diving off the deep end of my understanding here but 0dBFS /can/ still clip, can it not? 05.54.30 # turns out we were off by quite a bit for a while 05.54.53 # the hardware won't clip it, but of course the audio file could have clipping already in it from bad mastering 05.55.15 # [Saint]: you can start to get distortion a bit before that even as the amp gets closer to its limts 05.56.47 # regardless of what the spec sheet says, I usually define 0dBFS as where ever the distortion starts to increase faster than amplitude 05.57.14 # since the exact value often depends on supply voltages, which in a DAP aren't always what the spec sheet says they should be anyway 05.58.13 # <[Saint]> right, that makes more sense to me. 05.58.25 # <[Saint]> the breakpoint between amplitude and distortion increases. 05.59.38 Join saratoga_ [0] (12650869@gateway/web/freenode/ip.18.101.8.105) 05.59.52 # <[Saint]> I think I've said it before but I really wish I had someone like you two who could actually use plain English to describe these principles instead of just waving at the math and hand-waving 'something something signal theory'. 06.00.49 # (reading the logs) dither in audio is the same idea as dithering in images (add random noise to cause the value to switch between levels), but in terms of what it actually accomplishes, dither in images is more like oversampling, while dithering in audio doesn't really have an analog 06.00.52 # in the end though, the math is where it's at 06.01.31 # what it really does is decorrelate the quantization error from the input, but what that actually means is just that noise gets both stronger and also much harder to hear (since it no longer tracks the input signal) 06.01.39 # <[Saint]> Its no use understanding the math, which I do, if you don't have some tangible concepts to align them with. 06.01.53 # <[Saint]> visual descriptors are pretty bloody important in education. 06.01.59 Quit saratoga (Ping timeout: 260 seconds) 06.02.19 # for signals you pretty much have to start with the math, and then do it enough that it starts to make intuitive sense 06.02.48 # <[Saint]> And presumably not have a professor with a giant stick up his arse. 06.03.06 # you'd have to be a genius to really grasp something like that intuitively without working it out a hundred times on pen and paper 06.03.48 # <[Saint]> Tenure is a bitch. Some educators just seem to check out. 06.04.16 # <[Saint]> I guess I was just unlucky and uninterested. Mostly the latter I suppose because no one bothered to make it interesting. 06.06.08 # i was fortunate enough that mp3 players were just coming out when i was in college, so i was pretty motivated to figure out how to program one 06.06.09 Quit TheSeven (Ping timeout: 246 seconds) 06.07.14 # to make something interesting, have an interest in it. the rest just sort of does itself. 06.14.33 Quit CR0W (Ping timeout: 246 seconds) 06.16.47 # <[Saint]> I think I fixate too much on semantics. 06.18.02 # <[Saint]> 0dB being "the point at which we won't clip" seems at odds with interpolation. 06.19.03 # <[Saint]> IIUC, it very well could clip even without a singlular sample at 0dB. 06.19.13 # indeed 06.19.32 # since it can overshoot the known sample values 06.19.47 # yeah, the intersample over problem 06.19.56 Join CR0W [0] (~narf@adsl-76-249-176-22.dsl.milwwi.sbcglobal.net) 06.19.56 Quit CR0W (Changing host) 06.19.56 Join CR0W [0] (~narf@unaffiliated/em64t) 06.20.04 # but again, if you define 0dB as the point where you don't have distortion, you automatically handle those correctly 06.20.13 # <[Saint]> I feel like I made a little breakthrough there. 06.20.13 # but the real value shouldn't be a massive outlier if there's band limiting 06.21.58 # needs moar jpeg 06.29.50 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 06.38.19 Quit saratoga_ (Quit: Page closed) 06.39.26 Quit TheSeven (Ping timeout: 255 seconds) 07.00.20 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 07.04.01 Quit CR0W (Ping timeout: 240 seconds) 07.10.07 Join CR0W [0] (~narf@adsl-76-249-176-22.dsl.milwwi.sbcglobal.net) 07.10.07 Quit CR0W (Changing host) 07.10.07 Join CR0W [0] (~narf@unaffiliated/em64t) 07.16.43 Quit PurlingNayuki (Ping timeout: 250 seconds) 07.18.08 *** Saving seen data "./dancer.seen" 07.23.53 Join PurlingNayuki [0] (~Thunderbi@2001:da8:215:6905:192:ac4a:f78a:121e) 07.47.08 Join advcomp2019_ [0] (~advcomp20@63-229-188-192.sxct.qwest.net) 07.47.08 Quit advcomp2019_ (Changing host) 07.47.08 Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019) 07.49.50 Quit advcomp2019 (Ping timeout: 268 seconds) 07.56.22 Join PimpiN8 [0] (~textual@2a02:a454:38ea:1:a44b:4e64:1e1d:5416) 08.10.59 Join deevious [0] (~Thunderbi@193.226.142.214) 08.12.06 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 08.16.31 Quit jhMikeS (Ping timeout: 240 seconds) 08.17.29 Join ender` [0] (krneki@foo.eternallybored.org) 08.27.03 Quit PurlingNayuki (Ping timeout: 258 seconds) 08.47.51 Quit PimpiN8 (Quit: My MacBook has gone to sleep. ZZZzzz…) 09.08.07 Join ernestask [0] (~ernestask@78-56-62-157.static.zebra.lt) 09.10.18 Join dys [0] (~dys@tmo-123-54.customers.d1-online.com) 09.10.54 Join JannF [0] (~jann@HSI-KBW-046-005-019-085.hsi8.kabel-badenwuerttemberg.de) 09.13.56 Join petur [0] (~petur@91.183.48.77) 09.13.56 Quit petur (Changing host) 09.13.56 Join petur [0] (~petur@rockbox/developer/petur) 09.18.11 *** Saving seen data "./dancer.seen" 09.21.26 Quit JannF (Ping timeout: 255 seconds) 09.57.50 Quit dys (Ping timeout: 246 seconds) 10.09.38 Join dys [0] (~dys@2003:5b:203b:100:6af7:28ff:fe06:801) 10.13.03 Quit _meg (Ping timeout: 248 seconds) 10.14.41 Join _meg [0] (~notsure@211.25.203.45) 10.14.55 Join JannF [0] (~jann@HSI-KBW-109-192-015-103.hsi6.kabel-badenwuerttemberg.de) 10.23.23 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 10.35.06 Join JannF1 [0] (~jann@HSI-KBW-109-192-015-103.hsi6.kabel-badenwuerttemberg.de) 10.39.04 Quit JannF (Ping timeout: 240 seconds) 10.40.42 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 10.45.02 Quit jhMikeS (Ping timeout: 248 seconds) 10.51.49 # [Saint]: needs moar NwAvGuy http://nwavguy.blogspot.com/2011/09/noise-dynamic-range.html 10.51.52 # remember him? 10.51.58 # https://spectrum.ieee.org/tech-history/silicon-revolution/nwavguy-the-audio-genius-who-vanished 10.53.04 Quit pamaury (Ping timeout: 248 seconds) 10.53.38 # I learned the basics from reading his blog 11.07.00 Join Guest56968 [0] (~ac@nat-eduroam-76-gw-01-lne.lille.inria.fr) 11.18.15 *** Saving seen data "./dancer.seen" 11.42.43 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 11.54.26 Quit Guest56968 (Quit: WeeChat 1.9.1) 12.06.42 # pamaury: Great discovery! MIPS compatibility Ingenic way :P 12.11.58 Quit paulk-gagarine (Quit: Leaving) 12.13.08 Join paulk-gagarine [0] (~paulk-gag@gagarine.paulk.fr) 12.43.40 Quit CommunistWitchDr (Ping timeout: 240 seconds) 12.59.02 # wodz: yeah, it's seriously fucked up but now it works 13.01.15 # by the way, when doing all this experimentation, I ended up building a mip "library" that uses as macros and tries to hides some MIPS details, I'll push it to gerrit tonight, feel free to have a look 13.01.34 # it would be good if we can avoid duplicating a lot of code in crt0 by having macros there 13.01.43 # pamaury: I am stack with atj as codec crashes early. It looks like something is overwriting codec buffer but I can't find out what. I am thinking of employing MMU to protect beginning of codec buffer just after codec load. This should allow to catch the offender. 13.01.53 # pamaury: This is however quite a bit of work 13.02.23 # pamaury: sure will look (but not today most probably) 13.04.13 Quit atsampson (Ping timeout: 276 seconds) 13.11.26 # wodz: yeah if you just want to protect a small part of the buffer, it's a bit tricky because the wired entries of the TLB might not be enough 13.13.18 # pamaury: Well I need to protect only .text and .rodata part. I wonder if dma overwriting could be catched as well 13.18.18 *** Saving seen data "./dancer.seen" 13.21.31 # dma will be more difficult, you could always have some wrapper around dma that checks the destination 13.29.56 # at some point I think thinking about implementing proper MMU protection for .text, .data and buflib (ie invalidating previous virtual addresses when a buffer moves), but it's a lot of work 13.30.02 # * was thinking 13.37.26 Quit petur (Quit: Connection reset by beer) 13.47.31 Quit MrBismuth (Read error: Connection reset by peer) 13.56.00 Quit robertd11 (Ping timeout: 248 seconds) 14.01.40 Join robertd1 [0] (~root@186-88-142-98.genericrev.cantv.net) 14.04.09 Quit robertd1 (Client Quit) 14.04.18 Join robertd11 [0] (~root@186-88-142-98.genericrev.cantv.net) 14.07.06 Quit robertd11 (Client Quit) 14.08.29 Quit this_is_a_nick (*.net *.split) 14.08.29 Quit ChanServ (*.net *.split) 14.11.10 Join this_is_a_nick [0] (~amofiuhr_@ip60-237-64-186.ct.co.cr) 14.16.10 Join ChanServ [0] (ChanServ@services.) 14.16.10 Mode "#rockbox +o ChanServ " by orwell.freenode.net 14.21.05 Join robertd1 [0] (~root@186-88-142-98.genericrev.cantv.net) 14.23.41 Quit robertd1 (Client Quit) 14.24.28 Join robertd11 [0] (~root@186-88-142-98.genericrev.cantv.net) 14.38.10 Join PimpiN8 [0] (~textual@2a02:a454:38ea:1:a44b:4e64:1e1d:5416) 14.46.32 Join amayer [0] (~amayer@107-1-97-172-ip-static.hfc.comcastbusiness.net) 15.10.48 Join LinusN [0] (~linus@giant.haxx.se) 15.18.21 *** Saving seen data "./dancer.seen" 15.23.04 Quit robertd11 (Ping timeout: 268 seconds) 15.26.38 Quit wodz (Ping timeout: 248 seconds) 15.38.30 Join storm_dragon [0] (~Storm@137.118.191.109) 15.38.56 Part LinusN 15.39.03 Part storm_dragon ("With a flash of lightning and a blast of air from massive wings, the storm dragon takes flight and vanishes into the fading twilight.") 15.55.52 Join Natter [0] (d15d1d67@gateway/web/freenode/ip.209.93.29.103) 15.56.53 Quit Natter (Client Quit) 16.17.25 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 16.34.19 Quit _meg (Ping timeout: 255 seconds) 16.35.22 Join _meg [0] (~notsure@211.25.203.45) 16.38.38 Quit this_is_a_nick (Read error: Connection reset by peer) 16.44.52 Join this_is_a_nick [0] (~amofiuhr_@ip60-237-64-186.ct.co.cr) 17.02.34 Join SovietShaman [0] (quasselcor@97-87-177-85.dhcp.stls.mo.charter.com) 17.02.43 Quit this_is_a_nick (Read error: Connection reset by peer) 17.17.00 Quit pamaury (Ping timeout: 240 seconds) 17.18.10 Join krabador [0] (~krabador@unaffiliated/krabador) 17.18.23 *** Saving seen data "./dancer.seen" 17.47.54 Join atsampson [0] (~ats@cartman.offog.org) 18.34.32 Join pratch [0] (d15d1d67@gateway/web/freenode/ip.209.93.29.103) 18.35.02 # Hi, I am unable to charge my ipod classic via a wall usb. 18.35.26 # Any advise to this? 18.48.18 Quit dys (Ping timeout: 250 seconds) 18.49.38 Quit pratch (Ping timeout: 260 seconds) 18.55.10 Quit maraz (Ping timeout: 248 seconds) 18.57.49 Join maraz [0] (maraz@kapsi.fi) 19.02.06 Quit JannF1 (Ping timeout: 248 seconds) 19.10.43 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 19.17.46 Quit advcomp2019_ (Ping timeout: 250 seconds) 19.18.14 Join advcomp2019 [0] (~advcomp20@65-131-145-69.sxct.qwest.net) 19.18.14 Quit advcomp2019 (Changing host) 19.18.14 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) 19.18.24 *** Saving seen data "./dancer.seen" 19.21.40 Join smoke_fumus [0] (~smoke_fum@188.35.176.90) 19.27.35 Join lebellium [0] (~hexchat@89-93-177-206.hfc.dyn.abo.bbox.fr) 19.51.20 Quit PimpiN8 (Quit: My MacBook has gone to sleep. ZZZzzz…) 19.52.59 Join this_is_a_nick [0] (~amofiuhr_@201.199.104.169) 19.53.58 Quit advcomp2019 (Read error: Connection reset by peer) 19.58.22 Join advcomp2019 [0] (~advcomp20@65-131-179-3.sxct.qwest.net) 19.58.22 Quit advcomp2019 (Changing host) 19.58.22 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) 20.29.50 Quit ernestask (Quit: ernestask) 20.30.54 Quit ender` (Read error: Connection reset by peer) 20.31.47 Join ender` [0] (krneki@foo.eternallybored.org) 20.43.21 Join JannF [0] (~jann@2a02:8071:198:9f00:5ee0:c5ff:febe:60e0) 20.54.50 Quit prg318 (Ping timeout: 250 seconds) 20.57.27 Join prg318 [0] (~prg@deadcodersociety/prg318) 20.57.56 Quit JannF (Ping timeout: 246 seconds) 21.06.38 Join amofiuhr_ [0] (~amofiuhr_@201.199.104.4) 21.07.09 Quit this_is_a_nick (Ping timeout: 272 seconds) 21.07.45 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:7d20:7795:1d8b:94f7) 21.14.33 Join dys [0] (~dys@tmo-098-204.customers.d1-online.com) 21.16.35 Join johnb2 [0] (~johnb2@p5B3AFF83.dip0.t-ipconnect.de) 21.18.20 Join PimpiN8 [0] (~textual@2a02:a454:38ea:1:a44b:4e64:1e1d:5416) 21.18.28 *** Saving seen data "./dancer.seen" 21.27.04 Quit duncan^ (Changing host) 21.27.04 Join duncan^ [0] (UNKNOWN@fez.tardis.ed.ac.uk) 21.27.43 Quit duncan^ (Quit: WeeChat 1.9.1) 21.29.30 Join duncan^ [0] (UNKNOWN@fez.tardis.ed.ac.uk) 21.58.05 Quit johnb2 (Ping timeout: 240 seconds) 22.07.05 Quit krabador (Remote host closed the connection) 22.08.39 Join krabador [0] (~krabador@unaffiliated/krabador) 22.11.32 Join JannF [0] (~jann@HSI-KBW-046-005-019-085.hsi8.kabel-badenwuerttemberg.de) 22.29.05 Quit JannF (Ping timeout: 240 seconds) 22.35.30 # GNU linker script never stop to amaze me: 22.35.30 # _relocstart = . ; // -> yields 0xf0000000 22.35.30 # _relocstart = (. & 0x3fffffff) | 0x80000000; // yields 0x700000 22.35.30 DBUG Enqueued KICK pamaury 22.35.30 # unless I got my math wrong, this is not what I expected! 22.39.04 # unless the gnu *dis*assembler produces the wrong output and the actual code is correct, damn something is very wrong 22.42.21 Quit amayer (Quit: Leaving) 22.46.59 Quit scorche (Disconnected by services) 22.47.02 Join scorche` [0] (~scorche@rockbox/administrator/scorche) 22.51.32 Join n17ikh_ [0] (~n17ikh@unaffiliated/n17ikh) 22.56.25 Quit shrizza (*.net *.split) 22.56.26 Quit n17ikh (*.net *.split) 22.56.43 Quit dan- (*.net *.split) 22.56.43 Quit rogeliodh (*.net *.split) 22.56.43 Join rogeliodh [0] (~rogeliodh@ec2-52-90-241-120.compute-1.amazonaws.com) 23.00.03 Join shrizza [0] (~shrizza@oki-dc-urasoe01-187.glbb.ne.jp) 23.02.03 Join dan- [0] (~d@101.165.131.18) 23.02.03 Quit dan- (Changing host) 23.02.03 Join dan- [0] (~d@freenode/corporate-sponsor/privateinternetaccess.com/doaks) 23.02.38 # dysassembler 23.09.41 Quit lebellium (Quit: Leaving) 23.10.01 Nick SovietShaman is now known as CommunistWitchDr (quasselcor@97-87-177-85.dhcp.stls.mo.charter.com) 23.14.56 # ok so linker is definitely doing broken math, although it's so poorly documented that I'm sure it's correct in some weird sense 23.15.39 # also what is section .MIPS.abiflags and why does it randomly pops up depending on somehow unrelated changes in the linker script ?! 23.18.32 *** Saving seen data "./dancer.seen" 23.31.03 Join petur [0] (~petur@rockbox/developer/petur) 23.32.49 Quit amofiuhr_ (Ping timeout: 272 seconds) 23.42.06 Quit ZincAlloy (Quit: Leaving.)