Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2014-12-28

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.
01:20:05saratogathomasjfox: what are the limitations on the buflib for codecs?
01:20:11saratogacould we also use it for DSP effects?
01:21:27saratogasome 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:37fs-bluebot3Gerrit review #1084 at : 3XWorld: cleanup by Franklin Wei
02:47:42[Franklin]just a couple polishes on xworld
02:48:45fs-bluebotBuild 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] (
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] (
05:01:42 Join Provel [0] (
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 (
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] (
09:30:37 Join Scall [0] (~chat@unaffiliated/scall)
09:39:48 Quit lorenzo92 (Quit: ChatZilla [Firefox 30.0/20140608211457])
09:40:09 Join lorenzo92 [0] (
09:40:43 Quit JanC (Ping timeout: 265 seconds)
09:50:15lorenzo92i don't see logf working on ypr0 :/ how can it be?
09:52:17 Join ender` [0] (
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] (
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] (
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] (
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:29foolshlorenzo92: 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] (
15:01:37syon__Hi all. I have a quick question. My Clip+ has died and it looks to be a flash issue
15:01:58syon__The thing just became slow to react to user input and now does not want to power on anymore.
15:02:19syon__Plugging it into my Linux box, I just see the dreadful 4 MiB of flash partition.
15:02:46syon__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:11gevaertsI'd go for the warranty
15:07:10syon__ok, thanks, gevaerts
15:07:26syon__is that a usual known thing with these players? just thinking which one I should go for next
15:08:41gevaertsIt's been known to happen, but I'm not at all convinced that they brick more often than other players
15:09:12gevaertsThere's a lot of them around, so there are also more unlucky stories
15:09:42 Join Misanthropos [0] (
15:12:04syon__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] (
15:55:22 Quit lorenzo92 (Ping timeout: 240 seconds)
16:06:18 Quit bertrik (Quit: Lost terminal)
16:28:38 Join mwcampbell [0] (
16:31:57mwcampbellHas 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:26mwcampbellI 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] (
17:00:04 Quit Misanthropos (Ping timeout: 265 seconds)
17:00:50 Join lorenzo92 [0] (
17:00:56 Quit lorenzo92 (Client Quit)
17:03:11 Join lorenzo92 [0] (
17:20:55 Join Misanthropos [0] (
17:21:26mwcampbellHow much RAM does the Sansa Clip Zip have?
17:27:03gevaerts8MB, IIRC
17:37:23mwcampbellah yes, I see that now in my rockbox-info.txt
17:39:31 Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox)
17:39:49mwcampbellIs 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] (
18:12:02 Join Guest66888 [0] (Slayer@
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] (
18:29:27 Quit [Franklin] (Changing host)
18:29:28 Join [Franklin] [0] (~franklin@unaffiliated/franklin)
18:33:41 Join mirak [0] (
18:34:40mwcampbellCan 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:39mwcampbellWhy 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:01mwcampbellah, 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:29mwcampbellI'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:58mwcampbellespeak 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:21mwcampbelloh, you've already looked :)
18:39:58the-kyleI 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:35the-kyleIf 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:20the-kyleIt may possibly only be awaiting implementation.
18:42:30gevaertsThat bit is irrelevant
18:43:06gevaertsWe *do* have permission to use his code, rockbox is GPLv2+ and espeak is GPLv3
18:43:13[Franklin]so no legal issues?
18:43:24the-kyleNone. 2+ makes 3 possible.
18:43:27gevaertsThe thing is that we want to stay as GPLv2+ and not move to v3
18:43:40*[Franklin] gets it now
18:43:42gevaertsSo we need to be careful to mark files properly
18:44:07[Franklin]so they should all be marked v2+
18:44:09gevaertsThe end result would be that a build that includes espeak would be v3, but the sources would be mixed
18:44:45the-kyleSo the problem would be that there would need to be a separate build?
18:45:21the-kylea v2+ build without Espeak and a v3 build including Espeak?
18:45:50the-kyleIf the problem is in the build, it could be a config option.
18:46:00gevaertsNot really
18:46:06***Saving seen data "./dancer.seen"
18:46:28gevaertsThe 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:50:44mwcampbellPresumably 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:22gevaertsAgain, there is no conflict
18:51:28the-kyleI don't believe there is any GPL2 only code, at least not as far as I know.
18:51:45gevaertsIt's *just* a matter of keeping track of things properly
18:52:05the-kyleSo it would seem that the issue is just implementing it, with proper attribution and such.
18:52:47the-kyleSomething in the COPYING file that indicates that the Espeak source is GPL3 may be enough to at least partially satisfy that requirement.
18:54:17mwcampbellOf 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:27mwcampbell(The Sansa Clip Zip is the device I happen to have)
18:54:40the-kyleBut 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:08the-kyleI'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:39mwcampbellI'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:17the-kyleThe 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:00mwcampbellthe-kyle: Just curious, are you blind too?
18:58:07[Franklin]who can do it then?
18:58:50mwcampbellMaybe 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:58the-kylemwcampbell: Your screen name seems familiar.
18:59:08the-kyleNot here, but elsewhere.
18:59:20[Franklin]mwcampbell: I can give some guidance
18:59:53the-kyleThe question would be whether or not a plugin could run system-wide.
19:00:29[Franklin]that's a bit of an issue
19:00:30the-kyleI would think it may need to be implemented similar to the way codecs are implemented rather than plugins.
19:00:54mwcampbellRockbox would need to define a new "TTS engine" API, which the espeak plugin would implement
19:00:58[Franklin]gevaerts: enlightenment, please?
19:00:59mwcampbelljust as there's presumably a codec API
19:01:24the-kyleI think some basic work was done moving in this direction. Not sure of the status at this point.
19:01:32mwcampbellI'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:34the-kyleI 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:06mwcampbellIt 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:41the-kyleYeah, 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:26mwcampbellThe core doesn't need pthread
19:11:34the-kyleThat'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:00mwcampbellThe other TTS engine one might consider porting is flite
19:12:13the-kyleYay for Alan W. Black!
19:12:24mwcampbellparticularly, flite with hts-engine (, if that can fit within CPU and RAM constraints
19:12:31the-kyleThe perfect Scottish voice for my Clip Zip!
19:12:51mwcampbellregular Flite sucks IMO
19:13:00the-kyleI 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: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:12mwcampbellUnrealistic? Why?
19:14:19mwcampbellThe original DECtalk used a 386 processor, after all
19:14:22[Franklin]mwcampbell: integration with rockbox
19:14:27the-kyleOn some targets maybe, but it can work on most.
19:14:50the-kyleEspeak 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:41gevaertsBut no mmu
19:15:49the-kyleThe 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:39thomasjfoxwho needs malloc when you can have buflib :D
19:20:13mwcampbellWhat 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:22mwcampbellDoes rockbox not have malloc?
19:21:41[Franklin]mwcampbell: kind of
19:21:49thomasjfox[Franklin]: see firmware/buflib.c. It's a memory manager.
19:21:58[Franklin]thomasjfox: so it's malloc?
19:22:29thomasjfoxmore or less. Buflib moves your memory around if needed, so it's not a drop-in replacement
19:22:50[Saint]its a fair cry from real malloc.
19:23:23mwcampbellI 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:12thomasjfoxwell it's a pita to debug if someone keeps cached pointers and normally no compation is triggered
19:25:44thomasjfoxbesides that I really like the idea moving memory around to free up larger blocks
19:26:28mwcampbellSo then, any code that makes extensive use of malloc or calloc will be difficult to port?
19:27:00mwcampbellHow was Lua ported then?
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:31mwcampbellheh, wouldn't that be a little heavy for a device with only 8 MB of RAM?
19:29:55[Saint]mwcampbell: lowmem needs a reason to die anyway... ;P
19:30:08[Franklin]out goes the archos devices...
19:30:17the-kyleIt'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:33mwcampbellSeriously 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:55[Franklin]JVM sounds like a fun project
19:32:44mwcampbellSo 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:48mwcampbellOh, so then what mnakes a port of malloc-heavy code difficult?
19:33:56[Franklin]fragmentation in memory
19:34:05gevaertsmalloc() 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:52thomasjfox[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:49thomasjfoxcodec_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:03saratogamalloc assumes that if you're going to use free() that you have an MMU to defragment your address space
19:54:25saratogaif not, calling free will gradually fragment your memory, which in effect is a lot like a memory leak
19:54:48saratogaso you can malloc stuff, but not safely free it when done
19:55:19saratogathat means that you periodically have to release everything malloced and then reinit the allocator to defragment
19:55:55saratogayou 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:40saratogayou'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:31saratogaon 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:21saratogabigger problem would be to understand how the code actually works and what its doing
20:09:38saratogaa lot of codecs just malloc a bunch of stuff up front and then never free until they're done because its slow
20:09:41saratogathis may be similar
20:21:20 Join ZincAlloy [0] (
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: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: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:10saratogatemperature 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:39saratogawhereas 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:28saratogafor a plugin i think floating point is ok (i forget but i believe it works) although it will be extremely slow
21:02:45saratogasince 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:48thomasjfoxFP 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:32thomasjfoxpdbox 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:57thomasjfoxargh. Booting the PPC64 image of Fedora 20 is painfully slow. It took several minutes to show a non-responding mouse cursor
21:09:09thomasjfoxlet'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:33:18[Franklin]doesn't work
21:33:27funmanI think this refers to SSE and similar ?
21:33:29 Join rela [0] (~x@pdpc/supporter/active/rela)
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:56thomasjfoxdoes anyone know if rockbox's read() implementation might yield()?
21:47:32thomasjfoxso memory allocated by buflib would need special protection not to be moved in between
21:48:58gevaertsIO yields, yes
21:49:02 Quit y4n (Quit: PANTS OFF!)
21:49:23 Quit pamaury (Ping timeout: 245 seconds)
21:50:08thomasjfoxgevaerts: thanks. so one needs to set a special callback to avoid moving / shrinking of the underyling buffer
21:51:05thomasjfoxthe backdrop loader of the skin engine already does something like that IIRC
21:53:54thomasjfoxhmm, 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] (
22:15:08 Join lorenzo92 [0] (
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:11thomasjfox[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:20thomasjfoxthis must be something that hooks into buflib_init() and I see nothing like that in there
22:40:33thomasjfoxotherwise it would miss the creation of new memory pools
22:41:15thomasjfoxmay 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:43lebelliumI just noticed that latest builds here"> are dated August 2014. Does someone know why?
22:43:53*[Saint] wishes non-religiously-orientated $seasonal_greetings on all involved
22:44:35thomasjfoxmy 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:24gevaertsthomasjfox: 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:56thomasjfoxthere 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:25gevaertsI guess you basically want to check if the block has an associated callback or not
22:46:28lebellium[Saint]: and nobody (included me) noticed that before? That's sad :(
22:46:29[Saint]else it'd fall over entirely, no?
22:46:51thomasjfoxit will only fall over if compaction happens
22:47:02thomasjfoxthe 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:35lebelliumI'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] (
22:48:36lebelliumI met several theme designers who know nothing about the building system but just learnt the theme language like me
22:48:40thomasjfoxoh 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:07rasherBoth are built on his hardware
22:50:19[Saint]I've pinged enough people that someone will clarify eventually I'm sujre.
22:50:35rasherI certainly wouldn't be opposed to them being hosted elsewhere to wash my hands of them
22:50:39lebelliumI'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:24rasherI 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:30thomasjfoxok, 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:19thomasjfoxspeaking 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:50thomasjfoxlol, I suspected the same.
22:55:01gevaertsZagor and Torne, I think
22:55:23[Franklin]gevaerts knows all
22:56:32 Join RiD [0] (
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 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] (
23:36:10 Quit krabador (Quit: Take the time.)
23:38:00 Join krabador [0] (~krabador_@unaffiliated/krabador)
23:53:12 Join cmhobbs [0] (
23:53:13 Quit cmhobbs (Changing host)
23:53:13 Join cmhobbs [0] (~cmhobbs@fsf/member/cmhobbs)

Previous day | Next day