--- Log for 28.12.114 Server: tepper.freenode.net Channel: #rockbox --- Nick: logbot- Version: Dancer V4.16 Started: 7 days and 11 hours ago 00.06.08 Quit y4n (Quit: coob ov vood?) 00.38.17 Quit ender` (Quit: The sentence 'On the fish and chips-sign he wanted to have a hyphen between fish and and and and and chips.' would be a lot clearer if there was a quotation mark between 'between' and 'fish' and 'fish' and 'and' and 'and' and 'and' and 'and' and 'and' a) 00.45.48 *** Saving seen data "./dancer.seen" 00.58.13 Quit pamaury (Ping timeout: 244 seconds) 00.59.48 Join Jinx [0] (Dojo@unaffiliated/jinx) 01.18.57 Join saratoga [0] (47e27552@gateway/web/freenode/ip.71.226.117.82) 01.20.05 # thomasjfox: what are the limitations on the buflib for codecs? 01.20.11 # could we also use it for DSP effects? 01.21.27 # some of them use a fair amount of memory at the moment 01.22.02 Quit Strife89 (Quit: Leaving) 01.23.42 Quit xorly (Read error: No route to host) 01.43.34 Quit bertrik (Quit: Lost terminal) 02.45.49 *** Saving seen data "./dancer.seen" 02.47.32 # <[Franklin]> saratoga: could you commit G#1084 if you have the time? 02.47.37 # 3Gerrit review #1084 at http://gerrit.rockbox.org/r/1084 : 3XWorld: cleanup by Franklin Wei 02.47.42 # <[Franklin]> just a couple polishes on xworld 02.48.45 # Build Server message: 3New build round started. Revision 193c5df, 255 builds, 27 clients. 02.49.31 # <[Franklin]> man, it's nice having fs-bluebot around again :) 03.00.28 Quit Unhelpful (Remote host closed the connection) 03.04.01 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 03.46.08 Quit XavierGr (Ping timeout: 252 seconds) 04.22.28 Join JdGordon_ [0] (~jonno@rockbox/developer/JdGordon) 04.24.14 Quit JdGordon (Ping timeout: 258 seconds) 04.29.43 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 04.31.13 Quit JdGordon_ (Ping timeout: 272 seconds) 04.34.44 Join JdGordon_ [0] (~jonno@rockbox/developer/JdGordon) 04.35.32 Quit JdGordon (Ping timeout: 244 seconds) 04.44.25 Quit Provel (Quit: Provel) 04.45.51 *** Saving seen data "./dancer.seen" 04.50.38 Join JdGordon [0] (~jonno@ppp118-209-164-76.lns20.mel8.internode.on.net) 04.50.39 Quit JdGordon (Changing host) 04.50.39 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 04.52.07 Quit JdGordon_ (Ping timeout: 272 seconds) 04.55.54 Join Strife89 [0] (~Strife89@adsl-98-80-221-247.mcn.bellsouth.net) 05.01.42 Join Provel [0] (~Provel@75-132-21-111.dhcp.stls.mo.charter.com) 05.06.40 Quit [Franklin] (Ping timeout: 265 seconds) 05.18.14 Join JdGordon_ [0] (~jonno@rockbox/developer/JdGordon) 05.18.53 Nick Rondom_ is now known as Rondom (~rondom@nonmodosedetiam.net) 05.20.04 Quit JdGordon (Ping timeout: 256 seconds) 06.13.35 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 06.14.53 Quit JdGordon_ (Ping timeout: 250 seconds) 06.45.53 *** Saving seen data "./dancer.seen" 06.49.33 Quit Strife89 (Ping timeout: 250 seconds) 07.43.37 Quit sakax (Ping timeout: 245 seconds) 08.45.54 *** Saving seen data "./dancer.seen" 09.21.42 Quit Scall (Ping timeout: 258 seconds) 09.30.26 Join lorenzo92 [0] (~chatzilla@host24-106-dynamic.117-80-r.retail.telecomitalia.it) 09.30.37 Join Scall [0] (~chat@unaffiliated/scall) 09.39.48 Quit lorenzo92 (Quit: ChatZilla 0.9.91.1 [Firefox 30.0/20140608211457]) 09.40.09 Join lorenzo92 [0] (~chatzilla@host24-106-dynamic.117-80-r.retail.telecomitalia.it) 09.40.43 Quit JanC (Ping timeout: 265 seconds) 09.50.15 # i don't see logf working on ypr0 :/ how can it be? 09.52.17 Join ender` [0] (krneki@foo.eternallybored.org) 09.52.31 Join JanC [0] (~janc@lugwv/member/JanC) 10.07.00 Join rela [0] (~x@pdpc/supporter/active/rela) 10.41.34 Join bertrik [0] (~bertrik@dhcp-089-098-143-039.chello.nl) 10.41.34 Quit bertrik (Changing host) 10.41.34 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 10.45.57 *** Saving seen data "./dancer.seen" 10.46.28 Quit the-kyle1 (Ping timeout: 245 seconds) 10.49.08 Join the-kyle [0] (~kyle@kyle.tk) 11.03.51 Quit rela (Ping timeout: 265 seconds) 11.31.49 Join rela [0] (~x@pdpc/supporter/active/rela) 11.36.37 Quit rela (Ping timeout: 244 seconds) 11.41.21 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 12.11.15 Join rela [0] (~x@pdpc/supporter/active/rela) 12.45.59 *** Saving seen data "./dancer.seen" 13.17.21 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 13.57.41 Join Misanthropos [0] (~Misanthro@frnk-4d00d76d.pool.mediaways.net) 14.29.54 Quit ParkerR (Ping timeout: 244 seconds) 14.33.13 Join ParkerR [0] (ParkerR@unaffiliated/parkerr) 14.38.27 Quit pamaury (Ping timeout: 265 seconds) 14.42.19 Quit Misanthropos (Read error: Connection reset by peer) 14.46.00 *** Saving seen data "./dancer.seen" 14.54.29 # lorenzo92: logf over serial? I had that working on fuze+ not long ago debuging xworld on target for franklin, at first I thought it wasn't working, but then realized I had to start xworld to accually get some data in minicom 15.00.37 Join syon__ [0] (~quassel@cpc23-cmbg15-2-0-cust12.5-4.cable.virginm.net) 15.01.37 # Hi all. I have a quick question. My Clip+ has died and it looks to be a flash issue 15.01.58 # The thing just became slow to react to user input and now does not want to power on anymore. 15.02.19 # Plugging it into my Linux box, I just see the dreadful 4 MiB of flash partition. 15.02.46 # Any quick fixes? Still has half a month of warranty, but if there is a quick thing I can try locally before hand, that would be much appreciated! 15.04.11 # I'd go for the warranty 15.07.10 # ok, thanks, gevaerts 15.07.26 # is that a usual known thing with these players? just thinking which one I should go for next 15.08.41 # It's been known to happen, but I'm not at all convinced that they brick more often than other players 15.09.12 # There's a lot of them around, so there are also more unlucky stories 15.09.42 Join Misanthropos [0] (~Misanthro@frnk-4d00d17f.pool.mediaWays.net) 15.12.04 # Yeah, the situation for affordable players that take microSD cards and have decent features is rather small these days 15.33.47 Quit eternnoir (Remote host closed the connection) 15.47.29 Join krabador [0] (~krabador_@unaffiliated/krabador) 15.47.43 Join RiD [0] (~RiD@bl22-3-230.dsl.telepac.pt) 15.55.22 Quit lorenzo92 (Ping timeout: 240 seconds) 16.06.18 Quit bertrik (Quit: Lost terminal) 16.28.38 Join mwcampbell [0] (~Instantbi@ip68-102-60-136.ks.ok.cox.net) 16.31.57 # Has anyone worked on integrating an open-source text-to-speech engine, probably espeak, into Rockbox, so it can speak filenames without having to generate .talk files on a computer? 16.32.26 # I know not all supported devices could run espeak, but some of them, like the Sansa Clip line, probably could. 16.46.02 *** Saving seen data "./dancer.seen" 16.47.19 Quit RiD (Quit: A good plan today is better than a perfect plan tomorrow.) 16.51.05 Join RiD [0] (~RiD@bl22-3-230.dsl.telepac.pt) 17.00.04 Quit Misanthropos (Ping timeout: 265 seconds) 17.00.50 Join lorenzo92 [0] (~chatzilla@host24-106-dynamic.117-80-r.retail.telecomitalia.it) 17.00.56 Quit lorenzo92 (Client Quit) 17.03.11 Join lorenzo92 [0] (~chatzilla@host24-106-dynamic.117-80-r.retail.telecomitalia.it) 17.20.55 Join Misanthropos [0] (~Misanthro@frnk-4d010cab.pool.mediaWays.net) 17.21.26 # How much RAM does the Sansa Clip Zip have? 17.27.03 # 8MB, IIRC 17.37.23 # ah yes, I see that now in my rockbox-info.txt 17.39.31 Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) 17.39.49 # Is there any way I can use a higher Speex encoding quality for the voice file? 17.47.47 Quit Misanthropos (Ping timeout: 250 seconds) 17.56.21 Quit krabador (Quit: Take the time.) 17.59.50 Join krabador [0] (~krabador_@unaffiliated/krabador) 18.10.27 Join Misanthropos [0] (~Misanthro@frnk-5f746eeb.pool.mediaWays.net) 18.12.02 Join Guest66888 [0] (Slayer@69.143.14.62) 18.14.39 Quit Guest75680 (Ping timeout: 244 seconds) 18.16.14 Quit krabador (Ping timeout: 252 seconds) 18.26.06 Join krabador [0] (~krabador_@unaffiliated/krabador) 18.29.16 Join [Franklin] [0] (~franklin@cpe-071-071-039-006.triad.res.rr.com) 18.29.27 Quit [Franklin] (Changing host) 18.29.28 Join [Franklin] [0] (~franklin@unaffiliated/franklin) 18.33.41 Join mirak [0] (~mirak@5-49-106-229.hfc.dyn.abo.bbox.fr) 18.34.40 # Can code for the Rockbox firmware be written in C++ (even a subset thereof), or only C? 18.35.33 # <[Franklin]> mwcampbell: I've been wondering the same thing 18.35.38 # <[Franklin]> mwcampbell: in theory, yes 18.35.57 # <[Franklin]> you'd need a C++ to C frontend, much like cfront 18.36.33 # <[Franklin]> or you could convert it by hand :P 18.36.39 # Why don't the GCC cross toolchains include the C++ compiler? 18.37.01 # <[Franklin]> C++ is big and slow 18.37.30 # <[Franklin]> ... compared with C, that is 18.38.01 # ah, OK 18.38.15 # <[Franklin]> with resources as limited as they are, some of the targets couldn't even run a hello world 18.38.29 # I'm asking because I wonder if it would be feasible to run the espeak text-to-speech engine directly on the device, so voice files don't have to be pre-generated 18.38.58 # espeak is the most compact open-source TTS engine I'm aware of. But it's in C++ 18.39.00 # <[Franklin]> later releases of espeak are GPLv3, which is incompatible with GPLv2, which is used in rockbox 18.39.12 # <[Franklin]> an earlier release was ported to Rockbox, however 18.39.21 # oh, you've already looked :) 18.39.31 # <[Franklin]> http://www.rockbox.org/tracker/task/7660?string=espeak&project=1&type[0]=4&sev[0]=&pri[0]=&due[0]=&reported[0]=&cat[0]=&status[0]=open&percent[0]=&opened=&dev=&closed=&duedatefrom=&duedateto=&changedfrom=&changedto=&openedfrom=&openedto=&closedfrom=&closedto= 18.39.58 # I thought there was a special exemption for Rockbox where it could possibly run in spite of the incompatibility of the licenses. 18.40.29 # <[Franklin]> oh, yes :D 18.41.35 # If this is in writing, it can work. As I recall, it was a Rockbox dev who mentioned the permission directly from Espeak's developer to use its code. 18.42.20 # It may possibly only be awaiting implementation. 18.42.30 # That bit is irrelevant 18.43.06 # We *do* have permission to use his code, rockbox is GPLv2+ and espeak is GPLv3 18.43.13 # <[Franklin]> so no legal issues? 18.43.24 # None. 2+ makes 3 possible. 18.43.27 # The thing is that we want to stay as GPLv2+ and not move to v3 18.43.40 # * [Franklin] gets it now 18.43.42 # So we need to be careful to mark files properly 18.44.07 # <[Franklin]> so they should all be marked v2+ 18.44.09 # The end result would be that a build that includes espeak would be v3, but the sources would be mixed 18.44.10 # <[Franklin]> right? 18.44.45 # So the problem would be that there would need to be a separate build? 18.45.21 # a v2+ build without Espeak and a v3 build including Espeak? 18.45.50 # If the problem is in the build, it could be a config option. 18.46.00 # Not really 18.46.06 *** Saving seen data "./dancer.seen" 18.46.28 # The build being v3 isn't an actual issue 18.46.36 # <[Franklin]> what is? 18.47.13 Quit [Franklin] (Quit: Lost terminal) 18.47.47 Join [Franklin] [0] (~franklin@unaffiliated/franklin) 18.48.35 # <[Franklin]> from the wiki for DevConEuro2011: "The Rockbox Team hate you - You've fired up RockDoom" 18.48.46 # <[Franklin]> The Rockbox Team REALLY hate you - You've fired up RockBoy 18.49.06 # <[Franklin]> lol 18.50.44 # Presumably espeak would be a dynamically loaded module (what's the Rockbox term for these, like .codec and .rock files?), so the only conflict would be with any GPLv2-only code 18.51.09 # <[Franklin]> "plugin" 18.51.22 # Again, there is no conflict 18.51.28 # I don't believe there is any GPL2 only code, at least not as far as I know. 18.51.45 # It's *just* a matter of keeping track of things properly 18.52.05 # So it would seem that the issue is just implementing it, with proper attribution and such. 18.52.47 # Something in the COPYING file that indicates that the Espeak source is GPL3 may be enough to at least partially satisfy that requirement. 18.54.17 # Of course, CPU and RAM requirements may also be an issue. FOr example, would the Clip Zip be able to synthesize speech and decode the currently playing audio at the same time? 18.54.27 # (The Sansa Clip Zip is the device I happen to have) 18.54.40 # But then there is the consideration of the fact that Espeak's code is C++ whereas the rest of Rockbox is C, although GCC may be able to handle that without too much trouble. 18.55.08 # I'm not sure how much of an integration nightmare such a thing would be. 18.55.38 # <[Franklin]> mwcampbell: IIUC the zip is very powerful 18.55.39 # I'll find out how much of C++ espeak uses 18.56.44 # <[Franklin]> so to clarify, GPLv3 code can be used in rockbox, no? 18.57.17 # The ability to talk without the need to pregenerate voice clips is very important. If there is any way it can happen, I'll be one of the first to test its functionality. I'm just not that much of a coder, so I may not be able to do much with the coding aspects of the implementation. 18.58.00 # the-kyle: Just curious, are you blind too? 18.58.07 # <[Franklin]> who can do it then? 18.58.09 # Yes. 18.58.50 # Maybe I can. I've never worked on an embedded project like this before, but I think I'm fairly competent in C and C++. 18.58.58 # mwcampbell: Your screen name seems familiar. 18.59.08 # Not here, but elsewhere. 18.59.20 # <[Franklin]> mwcampbell: I can give some guidance 18.59.53 # The question would be whether or not a plugin could run system-wide. 19.00.18 # <[Franklin]> ooh... 19.00.29 # <[Franklin]> that's a bit of an issue 19.00.30 # I would think it may need to be implemented similar to the way codecs are implemented rather than plugins. 19.00.54 # Rockbox would need to define a new "TTS engine" API, which the espeak plugin would implement 19.00.58 # <[Franklin]> gevaerts: enlightenment, please? 19.00.59 # just as there's presumably a codec API 19.01.24 # I think some basic work was done moving in this direction. Not sure of the status at this point. 19.01.32 # I'm brand new to Rockbox; just got my player this morning. So I don't have a good grasp of the architecture yet. 19.01.34 # I saw something in the git log. 19.04.07 # <[Franklin]> the espeak SF page says that it's written in C 19.04.56 # <[Franklin]> but that's wrong, as I can see now 19.06.38 # * thomasjfox thinks about downloading Fedora for PowerPC to test a big endian rockbox simulator (running on qemu) 19.09.26 # <[Franklin]> mwcampbell: I just took a glance at some of the code for espeak 19.09.26 # <[Franklin]> mwcampbell: it doesn't seem to use OOP too much, but it /does/ rely on some POSIX functions 19.10.06 # It runs under Windows without Cygwin, so it doesn't rely on much of POSIX 19.10.40 # <[Franklin]> oh... FILE* isn't posix! 19.10.41 # Yeah, that was my thought. I had heard of it running on non-posix-compliant systems. 19.10.43 # <[Franklin]> silly me 19.11.09 # <[Franklin]> however, it does seem to use pthreads 19.11.26 # The core doesn't need pthread 19.11.34 # That's just a file descriptor as far as I know. I could be wrong though, as I'm not fully familiar with C++ and the like. 19.11.51 Quit Misanthropos (Ping timeout: 250 seconds) 19.11.54 # <[Franklin]> the-kyle: correct 19.12.00 # The other TTS engine one might consider porting is flite 19.12.13 # Yay for Alan W. Black! 19.12.24 # particularly, flite with hts-engine (http://hts-engine.sf.net/), if that can fit within CPU and RAM constraints 19.12.31 # The perfect Scottish voice for my Clip Zip! 19.12.51 # regular Flite sucks IMO 19.13.00 # I need to try to get those working together with speech-dispatcher. 19.13.24 # * the-kyle agrees. 19.13.25 # <[Saint]> I'm prett sure someone tried porting Flite and its just not happening. 19.13.29 # <[Saint]> *pretty 19.13.33 Join sakax [0] (~sakax@unaffiliated/sakax) 19.13.55 # <[Saint]> A native TTS engine is nice and all, but a somewhat unrealistic idea. 19.14.11 # <[Franklin]> it'd be nice to read ebooks and all 19.14.12 # Unrealistic? Why? 19.14.19 # The original DECtalk used a 386 processor, after all 19.14.22 # <[Franklin]> mwcampbell: integration with rockbox 19.14.27 # On some targets maybe, but it can work on most. 19.14.50 # Espeak is indeed known to work. 19.15.10 # <[Saint]> I seem to recal Flite being riddled with malloc. 19.15.18 # <[Franklin]> [Saint]: rockbox has tlsf 19.15.41 # But no mmu 19.15.46 # <[Saint]> ^ 19.15.49 # The main issue would be implementing a TTS API to either replace or supplement the voice API. 19.15.59 # <[Franklin]> gevaerts: so? 19.16.21 # * foolsh rolls eyes 19.17.39 # who needs malloc when you can have buflib :D 19.20.13 # What was the main blocker for a flite port? Too much RAM or CPU power required? 19.20.30 # <[Franklin]> apparently memory allocation 19.20.59 # <[Saint]> that, and, somewhat poor management on behalf of the student. 19.21.15 # <[Franklin]> thomasjfox: what is buflib? 19.21.22 # Does rockbox not have malloc? 19.21.23 # <[Saint]> I...what? 19.21.41 # <[Franklin]> mwcampbell: kind of 19.21.49 # [Franklin]: see firmware/buflib.c. It's a memory manager. 19.21.58 # <[Franklin]> thomasjfox: so it's malloc? 19.22.29 # more or less. Buflib moves your memory around if needed, so it's not a drop-in replacement 19.22.41 # <[Franklin]> aha 19.22.50 # <[Saint]> its a fair cry from real malloc. 19.23.23 # I guess a compacting memory allocator is helpful on a memory-constrained system with no MMU 19.23.31 # <[Saint]> (and it demonstrates from time to time that its or its implementation into the core is really unhealthy) 19.24.23 # <[Saint]> particularly with themes doing weird crazy technically impossible things. 19.25.12 # well it's a pita to debug if someone keeps cached pointers and normally no compation is triggered 19.25.44 # besides that I really like the idea moving memory around to free up larger blocks 19.26.28 # So then, any code that makes extensive use of malloc or calloc will be difficult to port? 19.26.39 # <[Saint]> rather. 19.27.00 # How was Lua ported then? 19.27.11 # <[Franklin]> TLSF 19.27.31 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 19.27.32 # <[Saint]> and, not in entirety, as I understand it. 19.27.42 Quit mirak (Quit: Ex-Chat) 19.27.49 # <[Saint]> its /most/ of LUA. 19.28.47 # <[Franklin]> someone ought to port python 19.29.17 # * [Saint] shudders 19.29.29 # <[Saint]> May as well do PHP too... 19.29.31 # heh, wouldn't that be a little heavy for a device with only 8 MB of RAM? 19.29.48 # <[Franklin]> javascript 19.29.54 # duktape.org 19.29.55 # <[Franklin]> gecko 19.29.55 # <[Saint]> mwcampbell: lowmem needs a reason to die anyway... ;P 19.30.08 # <[Franklin]> out goes the archos devices... 19.30.17 # It's an old version, but Python can run on a phone that I believe has less RAM than the Clip Zip. 19.30.38 # <[Franklin]> java :P 19.31.33 # Seriously though, an ahead-of-time compiler that translates a reasonable subset of Java to C for Rockbox might be doable 19.31.50 # <[Franklin]> meh... no fun 19.31.54 # <[Saint]> rb2ART 19.31.55 # <[Franklin]> JVM sounds like a fun project 19.32.44 # So how is tlsf different from a normal malloc? 19.32.56 # <[Saint]> If we moved everything over to Java we could use the new Jack and Jill precompiler and compiler from Android's ART toolbox! :p 19.33.10 # <[Saint]> So we "just" have to switch from C to Java. ;) 19.33.15 # <[Franklin]> mwcampbell: it is a "normal" malloc 19.33.32 # <[Saint]> ~ 19.33.48 # Oh, so then what mnakes a port of malloc-heavy code difficult? 19.33.56 # free() 19.33.56 # <[Franklin]> fragmentation in memory 19.33.57 # fragmentation? 19.34.05 # malloc() is easy 19.34.22 # <[Franklin]> heck, I could implement it with some pointer arithmetic :P 19.34.41 # <[Saint]> that would be..non-fun. 19.34.52 # [Franklin]: take a look at codec_alloc(), we do exactly that 19.35.21 # <[Franklin]> in theory, you can free() the last malloc() that was made with that function 19.35.49 # codec_malloc() to be precise 19.36.15 # <[Franklin]> yeah, I did something similar in xworld 19.38.21 # <[Franklin]> see sys_get_buffer() in plugins/xworld/sys.c 19.54.03 # malloc assumes that if you're going to use free() that you have an MMU to defragment your address space 19.54.25 # if not, calling free will gradually fragment your memory, which in effect is a lot like a memory leak 19.54.48 # so you can malloc stuff, but not safely free it when done 19.55.19 # that means that you periodically have to release everything malloced and then reinit the allocator to defragment 19.55.55 # you might be ok with this, perhaps by reiniting on track change or rebuffering 19.57.39 # <[Franklin]> should I use floating-point numbers in unitconv? 19.58.49 # <[Franklin]> the more I think about it, the more it makes sense 19.58.50 # <[Saint]> saratoga: if that happened, in the example of a speech engine, wouldn;t you be dropping and re-initing when you actually tried to speak? 20.01.40 # you'd try to do it when the engine wasn't speaking 20.01.52 # <[Saint]> oh, hmmm, no - I...hmmm. 20.02.11 # <[Saint]> It wouldn't /always/ be bad. But there's some situations I can imagine having to wait for a bit. 20.02.29 # <[Saint]> It probably wouldn;t happen terribly often though. 20.02.31 # on the other hand if the engine doesn't free anything except when it quits, this is unnecessary 20.02.42 # <[Saint]> Or, maybe it would. I dunno. I rarely use voice. 20.09.21 # bigger problem would be to understand how the code actually works and what its doing 20.09.38 # a lot of codecs just malloc a bunch of stuff up front and then never free until they're done because its slow 20.09.41 # this may be similar 20.21.20 Join ZincAlloy [0] (~Adium@pD9EEBD25.dip0.t-ipconnect.de) 20.26.07 # * [Franklin] wonders what temperature scales unitconv should support 20.26.35 # <[Franklin]> rankine, celsius, kelvin, fahrenheit, delisle, newton... 20.27.31 # <[Saint]> IGS, for when faced with USian ovens. 20.28.48 # <[Franklin]> wikipedia has a nice page listing all the formulas... 20.28.49 # <[Franklin]> :D 20.29.40 # <[Franklin]> problem is, some scales go _BACKWARDS_ 20.40.09 Quit lorenzo92 (Ping timeout: 244 seconds) 20.46.07 *** Saving seen data "./dancer.seen" 20.46.45 # <[Franklin]> this fixed-point arithmetic is driving me crazy 20.47.40 # <[Saint]> Does it go backwards? 20.49.26 # <[Franklin]> it does crazy stuff 20.49.46 # <[Franklin]> oh, and you can go below 0 K 20.51.47 # <[Saint]> that's like saying you can travel faster than light. 20.51.55 # <[Saint]> possible in theory, not in practice. 20.52.23 # <[Saint]> (current standings of human knowledge taken into account) 20.52.47 # <[Saint]> AFAIK the coldest measurable temperature is in the order of picoKelvins. 20.53.21 # <[Saint]> errr, I should say reproducible. 20.54.53 # <[Franklin]> ok, I guess I'll push now 20.54.57 # <[Franklin]> temperature mostly works 20.55.18 # <[Saint]> woo! 20.55.24 # <[Saint]> I wasn't wrong. :) 20.55.33 # * [Saint] had to immediately fact check himself 20.56.57 # <[Saint]> which is kinda nuts, as various bits of deep space are 'hot' compared to recorded temperatures produced in lab environments on Earth. 20.57.50 # <[Saint]> but we've not realistically come terrible close to 0K yet. Even 0.006K is leagues away. 20.58.06 # <[Saint]> and that's a spectacular feat. 20.58.09 # <[Saint]> ...anyhoo. 20.58.10 # temperature in space is just determined by the amount of EM radiation passing through it, which is not all that low unless you are very far away from everything 20.58.39 # whereas with laser cooling you're essentially just pulling energy out of something to cool it 20.58.58 # <[Saint]> the 'really cold' (or hot, from above) bits are around ~1K iirc. 20.59.17 # <[Saint]> its been a while since Uni though. 20.59.29 # <[Saint]> and, yes. 21.00.02 # <[Saint]> so in the realms of what humans consider to be possible, less than 0K isn't really a thing. 21.00.13 # <[Saint]> not that we can measure at least. 21.01.32 # <[Franklin]> so, should I use floating-point or fixed-point arithmetic? 21.02.28 # for a plugin i think floating point is ok (i forget but i believe it works) although it will be extremely slow 21.02.45 # since the operations will be emulated 21.02.56 # <[Franklin]> I'm doing that already 21.03.45 # <[Saint]> I doubt this is a time critical application. 21.04.48 # FP emulation on 8bit Arduinos works kind of ok, so I guess we can live with it, too :) 21.05.58 # <[Franklin]> I'll use fixed-point for now 21.06.10 Quit rasher (Changing host) 21.06.10 Join rasher [0] (~rasher@rockbox/developer/rasher) 21.06.10 Quit rela (Ping timeout: 272 seconds) 21.06.15 # <[Franklin]> but floating-point for operations in between 21.06.37 # <[Franklin]> last I tried, you can't output floats in rockbox 21.06.44 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 21.07.32 # pdbox and a few others use float 21.08.03 # <[Franklin]> alright, there's a tiny bit of round-off error with the newton scale 21.08.48 # <[Franklin]> also with feet, miles, and nautical miles 21.08.57 # argh. Booting the PPC64 image of Fedora 20 is painfully slow. It took several minutes to show a non-responding mouse cursor 21.09.09 # let's try again with a PPC32 image of Ubuntu 21.09.13 # <[Franklin]> ... and pounds :/ 21.09.20 # <[Franklin]> and tons... 21.09.44 # <[Franklin]> I guess I need more precise coefficients 21.15.46 # <[Franklin]> does rockbox have 128-bit integer types? 21.17.20 Join rela [0] (~x@pdpc/supporter/active/rela) 21.22.00 Quit rela (Ping timeout: 244 seconds) 21.32.16 # * funman guesses this is unlikely 21.32.51 # <[Franklin]> GMP support? :P 21.32.55 # https://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html 21.33.18 # <[Franklin]> doesn't work 21.33.27 # I think this refers to SSE and similar ? 21.33.29 Join rela [0] (~x@pdpc/supporter/active/rela) 21.34.23 # <[Franklin]> yeah 21.35.09 # <[Franklin]> I really should convert unitconv to floating-point I guess 21.38.27 Quit rela (Ping timeout: 265 seconds) 21.46.56 # does anyone know if rockbox's read() implementation might yield()? 21.47.32 # so memory allocated by buflib would need special protection not to be moved in between 21.48.58 # IO yields, yes 21.49.02 Quit y4n (Quit: PANTS OFF!) 21.49.23 Quit pamaury (Ping timeout: 245 seconds) 21.50.08 # gevaerts: thanks. so one needs to set a special callback to avoid moving / shrinking of the underyling buffer 21.51.05 # the backdrop loader of the skin engine already does something like that IIRC 21.53.54 # hmm, when I look at the pictureflow plugin, it just does a normal buflib_alloc() and then calls rb->read() 22.00.48 # * thomasjfox starts to think it's a good idea to write a buflib sanity checker in special debug builds... like checking the pointer passed in to read() and others if it's from a buflib mempool 22.05.58 Join rela [0] (~x@pdpc/supporter/active/rela) 22.10.46 Quit rela (Ping timeout: 272 seconds) 22.12.32 Join lebellium [0] (~chatzilla@i16-les01-ntr-212-194-176-149.sfr.lns.abo.bbox.fr) 22.15.08 Join lorenzo92 [0] (~chatzilla@host24-106-dynamic.117-80-r.retail.telecomitalia.it) 22.15.11 Quit RiD (Quit: A good plan today is better than a perfect plan tomorrow.) 22.19.23 Quit thomasjfox (Ping timeout: 245 seconds) 22.22.02 # <[Saint]> thomasjfox: (logs) IIRC, something to this effect already exists. 22.24.58 Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) 22.27.03 Quit saratoga (Ping timeout: 246 seconds) 22.35.42 # <[Saint]> thomasjfox: (logs) IIRC, something to this effect already exists. 22.35.55 # <[Saint]> huh, that was...interesting. 22.36.10 # <[Saint]> that message got stuck in the ether for several minutes. 22.38.11 # [Saint]: any vague idea how it's called? 22.39.37 # <[Saint]> Not just offhand, I seem to recall seeing something to this effect within buflib sources itself. 22.39.52 # <[Saint]> I /may/ be misremembering and/or remembering buflib in infancy. 22.40.20 # this must be something that hooks into buflib_init() and I see nothing like that in there 22.40.33 # otherwise it would miss the creation of new memory pools 22.41.15 # may be some macro magic in buflib.h, let me check 22.41.46 # <[Saint]> A reasonable place to start would likely be the debug menu viewer for buflib. 22.42.03 # <[Saint]> IIRC that has the capability to test allocs and/or drop them. 22.42.33 # <[Saint]> but you may well have more ambitious goals for all I know. 22.43.25 # <[Saint]> Oh - also: 22.43.43 # I just noticed that latest builds here http://rasher.dk/rockbox/simulator/ are dated August 2014. Does someone know why? 22.43.53 # * [Saint] wishes non-religiously-orientated $seasonal_greetings on all involved 22.44.35 # my first idea was to keep a global list of all memory areas managed by buflib and then instrument f.e. I/O functions to check the passed in pointer. This can be slow, but that's not the point here ;) 22.44.41 # <[Saint]> A very happy $date of $locale to you all 22.45.24 # thomasjfox: you know, I bet buflib already keeps just such a list :) 22.45.47 # <[Saint]> lebellium: dunno - [7]'s server possibly fell offline or is misconfigured. 22.45.56 # <[Saint]> gevaerts: heh :) 22.45.56 # there can be multiple pools, so we need at least keep a global list of registered buflib contexts 22.46.11 *** Saving seen data "./dancer.seen" 22.46.21 # <[Saint]> one posits buflib already does just such a thing. 22.46.25 # I guess you basically want to check if the block has an associated callback or not 22.46.28 # [Saint]: and nobody (included me) noticed that before? That's sad :( 22.46.29 # <[Saint]> else it'd fall over entirely, no? 22.46.51 # it will only fall over if compaction happens 22.47.02 # the pictureflow plugin is a good example of that 22.47.04 # <[Saint]> lebellium: honestly, I expect that most people that use the simulator are perfectly capable of building it themselves. 22.47.35 # I'm not sure you should expect that 22.47.46 # <[Saint]> and the page makes it pretty clear that its entirely disconnected from the rockbox project, so, maybe people /did/ notice but figured this legitemately was of little or no concern. 22.47.59 # * [Saint] shrugs 22.48.04 Join RiD [0] (~RiD@bl22-3-230.dsl.telepac.pt) 22.48.36 # I met several theme designers who know nothing about the building system but just learnt the theme language like me 22.48.40 # oh wait, let's see how buflib behaves when buflib_alloc() is called and therefore NULL is used for the callback structure 22.48.55 Quit RiD (Client Quit) 22.49.01 # <[Saint]> It should probably be 'TheSeven's Daily Builds' or so. ;) 22.49.10 # <[Saint]> He took over from rasher years ago. 22.49.47 # <[Saint]> oh - actually, maybe that's just the Android builds...hmmm. 22.50.07 # Both are built on his hardware 22.50.19 # <[Saint]> I've pinged enough people that someone will clarify eventually I'm sujre. 22.50.35 # I certainly wouldn't be opposed to them being hosted elsewhere to wash my hands of them 22.50.39 # I'm capable of building a UI sim but since I'm a bit out of the business now, that will take some time to get a clean and up to date linux environement in my Virtual Machine while I could have just pressed a downloading link :) 22.51.24 # I can't seem to access the machine, so I can't look into it 22.52.30 # <[Saint]> any idea what kind of throughput it does/did? 22.52.51 # <[Saint]> I could probably take over the task if need be. 22.53.30 # ok, if you call plain buflib_alloc(), it passes NULL as the callback structure. This will prevent a move in move_block(). Splendid. 22.53.46 # <[Saint]> but that's likely no use as I'd have about as much time to maintain it as anyone else with the core infrastructure around here. 22.53.53 # <[Saint]> ie. about zero. 22.54.19 # speaking about core infrastructure, is zagor the only one with admin access to gerrit? 22.54.35 # <[Saint]> no idea. 22.54.41 # <[Saint]> I suspect gevaerts may know. 22.54.50 # lol, I suspected the same. 22.55.01 # Zagor and Torne, I think 22.55.23 # <[Franklin]> gevaerts knows all 22.56.32 Join RiD [0] (~RiD@bl22-3-230.dsl.telepac.pt) 22.58.11 # * [Saint] needs to finish the 'compiling RaaAoA on debianesque hosts with modern toolsets' thingy but it walks across quite a lot of areas. 22.59.06 # <[Saint]> I'm really not fond of writing documentation at all. 22.59.54 # <[Franklin]> then why do it? :P 23.02.19 # <[Saint]> I should really update rockboxdev.sh to handle it. 23.02.37 # <[Saint]> but all the host/arch considerations are a pain in the ass. 23.03.35 # <[Saint]> unless you make a lot of assumptions about the host and just error out with 'nope, do this this and this first' or so if they're not true. 23.03.48 # <[Saint]> but that somewhat defeats the purpose. 23.04.32 # <[Saint]> ah - maybe not. nah, I guess not. 23.05.46 # <[Saint]> anyhoo - the host considerations aren't something I'm really willing to care too much about. 23.11.58 Quit bluebrother (Disconnected by services) 23.12.04 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) 23.12.59 Quit thomasjfox (Quit: Konversation terminated!) 23.13.57 Quit fs-bluebot (Ping timeout: 252 seconds) 23.14.46 Join fs-bluebot [0] (~fs-bluebo@g224236188.adsl.alicedsl.de) 23.36.10 Quit krabador (Quit: Take the time.) 23.38.00 Join krabador [0] (~krabador_@unaffiliated/krabador) 23.53.12 Join cmhobbs [0] (~cmhobbs@ip98-186-66-92.fv.ks.cox.net) 23.53.13 Quit cmhobbs (Changing host) 23.53.13 Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs)