| 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:00 |
| 01:18:57 | | Join saratoga [0] (47e27552@gateway/web/freenode/ip.71.226.117.82) |
| 01:20:05 | saratoga | thomasjfox: what are the limitations on the buflib for codecs? |
| 01:20:11 | saratoga | could we also use it for DSP effects? |
| 01:21:27 | saratoga | 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:00 |
| 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 | fs-bluebot | Gerrit review #1084 at http://gerrit.rockbox.org/r/1084 : XWorld: cleanup by Franklin Wei |
| 02:47:42 | [Franklin] | just a couple polishes on xworld |
| 02:48:45 | fs-bluebot | Build Server message: New build round started. Revision 193c5df, 255 builds, 27 clients. |
| 02:49:31 | [Franklin] | man, it's nice having fs-bluebot around again :) |
| 03:00 |
| 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:00 |
| 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:00 |
| 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:00 |
| 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:00 |
| 07:43:37 | | Quit sakax (Ping timeout: 245 seconds) |
| 08:00 |
| 08:45:54 | *** | Saving seen data "./dancer.seen" |
| 09:00 |
| 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 | lorenzo92 | 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:00 |
| 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:00 |
| 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:00 |
| 12:11:15 | | Join rela [0] (~x@pdpc/supporter/active/rela) |
| 12:45:59 | *** | Saving seen data "./dancer.seen" |
| 13:00 |
| 13:17:21 | | Join y4n [0] (~y4n@unaffiliated/y4ndexx) |
| 13:57:41 | | Join Misanthropos [0] (~Misanthro@frnk-4d00d76d.pool.mediaways.net) |
| 14:00 |
| 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 | foolsh | 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 |
| 15:00:37 | | Join syon__ [0] (~quassel@cpc23-cmbg15-2-0-cust12.5-4.cable.virginm.net) |
| 15:01:37 | syon__ | Hi all. I have a quick question. My Clip+ has died and it looks to be a flash issue |
| 15:01:58 | syon__ | The thing just became slow to react to user input and now does not want to power on anymore. |
| 15:02:19 | syon__ | Plugging it into my Linux box, I just see the dreadful 4 MiB of flash partition. |
| 15:02:46 | syon__ | 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 | gevaerts | I'd go for the warranty |
| 15:07:10 | syon__ | ok, thanks, gevaerts |
| 15:07:26 | syon__ | is that a usual known thing with these players? just thinking which one I should go for next |
| 15:08:41 | gevaerts | It's been known to happen, but I'm not at all convinced that they brick more often than other players |
| 15:09:12 | gevaerts | 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 | syon__ | 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:00 |
| 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 | mwcampbell | 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 | mwcampbell | 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 |
| 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 | mwcampbell | How much RAM does the Sansa Clip Zip have? |
| 17:27:03 | gevaerts | 8MB, IIRC |
| 17:37:23 | mwcampbell | ah yes, I see that now in my rockbox-info.txt |
| 17:39:31 | | Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) |
| 17:39:49 | mwcampbell | 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:00 |
| 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 | mwcampbell | 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 | mwcampbell | 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 | mwcampbell | 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 | mwcampbell | 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 | mwcampbell | 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 | mwcampbell | 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 | the-kyle | 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 | the-kyle | 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 | the-kyle | It may possibly only be awaiting implementation. |
| 18:42:30 | gevaerts | That bit is irrelevant |
| 18:43:06 | gevaerts | 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 | the-kyle | None. 2+ makes 3 possible. |
| 18:43:27 | gevaerts | 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 | gevaerts | So we need to be careful to mark files properly |
| 18:44:07 | [Franklin] | so they should all be marked v2+ |
| 18:44:09 | gevaerts | 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 | the-kyle | So the problem would be that there would need to be a separate build? |
| 18:45:21 | the-kyle | a v2+ build without Espeak and a v3 build including Espeak? |
| 18:45:50 | the-kyle | If the problem is in the build, it could be a config option. |
| 18:46:00 | gevaerts | Not really |
| 18:46:06 | *** | Saving seen data "./dancer.seen" |
| 18:46:28 | gevaerts | 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 | mwcampbell | 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 | gevaerts | Again, there is no conflict |
| 18:51:28 | the-kyle | I don't believe there is any GPL2 only code, at least not as far as I know. |
| 18:51:45 | gevaerts | It's *just* a matter of keeping track of things properly |
| 18:52:05 | the-kyle | So it would seem that the issue is just implementing it, with proper attribution and such. |
| 18:52:47 | the-kyle | 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 | mwcampbell | 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 | mwcampbell | (The Sansa Clip Zip is the device I happen to have) |
| 18:54:40 | the-kyle | 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 | the-kyle | 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 | mwcampbell | 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-kyle | 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 | mwcampbell | the-kyle: Just curious, are you blind too? |
| 18:58:07 | [Franklin] | who can do it then? |
| 18:58:09 | the-kyle | Yes. |
| 18:58:50 | mwcampbell | 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 | the-kyle | mwcampbell: Your screen name seems familiar. |
| 18:59:08 | the-kyle | Not here, but elsewhere. |
| 18:59:20 | [Franklin] | mwcampbell: I can give some guidance |
| 18:59:53 | the-kyle | The question would be whether or not a plugin could run system-wide. |
| 19:00 |
| 19:00:18 | [Franklin] | ooh... |
| 19:00:29 | [Franklin] | that's a bit of an issue |
| 19:00:30 | the-kyle | I would think it may need to be implemented similar to the way codecs are implemented rather than plugins. |
| 19:00:54 | mwcampbell | 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 | mwcampbell | just as there's presumably a codec API |
| 19:01:24 | the-kyle | I think some basic work was done moving in this direction. Not sure of the status at this point. |
| 19:01:32 | mwcampbell | 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 | the-kyle | 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 | mwcampbell | 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 | the-kyle | 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 | mwcampbell | The core doesn't need pthread |
| 19:11:34 | the-kyle | 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 | mwcampbell | The other TTS engine one might consider porting is flite |
| 19:12:13 | the-kyle | Yay for Alan W. Black! |
| 19:12:24 | mwcampbell | particularly, flite with hts-engine (http://hts-engine.sf.net/), if that can fit within CPU and RAM constraints |
| 19:12:31 | the-kyle | The perfect Scottish voice for my Clip Zip! |
| 19:12:51 | mwcampbell | regular Flite sucks IMO |
| 19:13:00 | the-kyle | 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 | mwcampbell | Unrealistic? Why? |
| 19:14:19 | mwcampbell | The original DECtalk used a 386 processor, after all |
| 19:14:22 | [Franklin] | mwcampbell: integration with rockbox |
| 19:14:27 | the-kyle | On some targets maybe, but it can work on most. |
| 19:14:50 | the-kyle | 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 | gevaerts | But no mmu |
| 19:15:46 | [Saint] | ^ |
| 19:15:49 | the-kyle | 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 | thomasjfox | who needs malloc when you can have buflib :D |
| 19:20:13 | mwcampbell | 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 | mwcampbell | Does rockbox not have malloc? |
| 19:21:23 | [Saint] | I...what? |
| 19:21:41 | [Franklin] | mwcampbell: kind of |
| 19:21:49 | thomasjfox | [Franklin]: see firmware/buflib.c. It's a memory manager. |
| 19:21:58 | [Franklin] | thomasjfox: so it's malloc? |
| 19:22:29 | thomasjfox | 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 | mwcampbell | 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 | thomasjfox | well it's a pita to debug if someone keeps cached pointers and normally no compation is triggered |
| 19:25:44 | thomasjfox | besides that I really like the idea moving memory around to free up larger blocks |
| 19:26:28 | mwcampbell | 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 | mwcampbell | 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 | mwcampbell | 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 | mwcampbell | 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 | the-kyle | 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 | mwcampbell | 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 | mwcampbell | 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 | mwcampbell | Oh, so then what mnakes a port of malloc-heavy code difficult? |
| 19:33:56 | gevaerts | free() |
| 19:33:56 | [Franklin] | fragmentation in memory |
| 19:33:57 | mwcampbell | fragmentation? |
| 19:34:05 | gevaerts | 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 | thomasjfox | [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 | thomasjfox | 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 | saratoga | malloc assumes that if you're going to use free() that you have an MMU to defragment your address space |
| 19:54:25 | saratoga | if not, calling free will gradually fragment your memory, which in effect is a lot like a memory leak |
| 19:54:48 | saratoga | so you can malloc stuff, but not safely free it when done |
| 19:55:19 | saratoga | that means that you periodically have to release everything malloced and then reinit the allocator to defragment |
| 19:55:55 | saratoga | 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:00 |
| 20:01:40 | saratoga | 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 | saratoga | 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 | saratoga | bigger problem would be to understand how the code actually works and what its doing |
| 20:09:38 | saratoga | 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 | saratoga | 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 | saratoga | 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 | saratoga | 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 |
| 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 | saratoga | 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 | saratoga | 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 | thomasjfox | 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 | thomasjfox | 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 | thomasjfox | 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 | thomasjfox | 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 | funman | https://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html |
| 21:33:18 | [Franklin] | doesn't work |
| 21:33:27 | funman | 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 | thomasjfox | does anyone know if rockbox's read() implementation might yield()? |
| 21:47:32 | thomasjfox | so memory allocated by buflib would need special protection not to be moved in between |
| 21:48:58 | gevaerts | IO yields, yes |
| 21:49:02 | | Quit y4n (Quit: PANTS OFF!) |
| 21:49:23 | | Quit pamaury (Ping timeout: 245 seconds) |
| 21:50:08 | thomasjfox | gevaerts: thanks. so one needs to set a special callback to avoid moving / shrinking of the underyling buffer |
| 21:51:05 | thomasjfox | the backdrop loader of the skin engine already does something like that IIRC |
| 21:53:54 | thomasjfox | hmm, when I look at the pictureflow plugin, it just does a normal buflib_alloc() and then calls rb->read() |
| 22:00 |
| 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 | thomasjfox | [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 | thomasjfox | this must be something that hooks into buflib_init() and I see nothing like that in there |
| 22:40:33 | thomasjfox | otherwise it would miss the creation of new memory pools |
| 22:41:15 | thomasjfox | 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 | lebellium | 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 | thomasjfox | 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 | gevaerts | 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 | thomasjfox | 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 | gevaerts | I guess you basically want to check if the block has an associated callback or not |
| 22:46:28 | lebellium | [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 | thomasjfox | it will only fall over if compaction happens |
| 22:47:02 | thomasjfox | 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 | lebellium | 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 | lebellium | I met several theme designers who know nothing about the building system but just learnt the theme language like me |
| 22:48:40 | thomasjfox | 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 | rasher | 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 | rasher | I certainly wouldn't be opposed to them being hosted elsewhere to wash my hands of them |
| 22:50:39 | lebellium | 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 | rasher | 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 | thomasjfox | 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 | thomasjfox | 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 | thomasjfox | lol, I suspected the same. |
| 22:55:01 | gevaerts | 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:00 |
| 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) |
icon identifies that the person is a core developer (has commit access).