Re: [Chicken-hackers] CHICKEN in production

[Oleg Kolosov]

On Oct 2, 2014, at 8:21 PM, Stephen Eilert <address@hidden> wrote:

> On Mon, Sep 29, 2014 at 6:07 PM, r <address@hidden> wrote:
>> Hello
>> 
>> happy to announce that we are in production with CHICKEN!
>> 
>> Professional karaoke system AST-50 with CHICKEN driven firmware.
>> 
>> http://www.art-system.ru/professionalnoe-karaoke/ast-50.html
>> 
>> Feel free to ask Oleg Kolosov, Yaroslav Tsarko and me about wonderful and 
>> dangerous trip to the parentheses land.
> 
> Wow, that's even cooler than what I was expecting when I saw the email. Not 
> only it is 'in production', but it is a firmware too, not the average 
> website. Congrats :)

Thanks!

> Now, could you pretty please with cherry on top share some details? For 
> instance, I saw some of the GUI in the advertisement. Is that  done in 
> Chicken too? Is Chicken just used as a 'glue' between modules written in 
> (insert whatever language here) or does it drive the whole system with 
> occasional C libs thrown in? How did you manage to convince management to use 
> Chicken? :D

Application logic, GUI and a few helper utilities are written Scheme. The GUI 
is rendered in immediate mode (whole scene redraw on every frame): layout 
computations are done on the Scheme side with FFI bindings for hardware 
accelerated alpha blending and blitting. The fonts are scalable, drawn on the 
fly to an offscreen buffers using FreeType, with some effects added for super 
smooth color fill effect - very important for karaoke. There are elaborate 
caching scheme for glyphs. We manage to get decent (40-50) FPS on 450MHz MIPS 
CPU most of the time.

We are trying to avoid using Chicken as a ‘glue’ because we figured that FFI 
transitions can be major bottleneck (especially strings). And adding Chicken to 
a C program makes normal analysis and debugging tools pretty much useless (for 
finding memory leaks and such), so hardware interfacing layer is pure C with 
separate high level FFI bindings on top.

We also struggled with posix and process control functions a lot (long story), 
trying to be functional here backfires badly, so we ended up with 
straightforward and ugly code (looking like verbose C with parentheses), 
replacing some functions from standard library (namely process-run) and 
customized error handling.

There was a few problems (I don’t remember clearly) with preemptive scheduling, 
so we are using strategically placed carefully adjusted sleeps with manual 
yields. I’ve borrowed a few ideas from Chicken implementation and made a video 
player (used for background: pure C, no FFI, no GUI) abusing libuv event loop 
for CPS trampoline. The code looks strange for casual observer but performs 
surprisingly well. I’ve not yet figured out how to wrap this for an egg 
(managing C callbacks is hard).

So, in the end, there are some great things (see video in this thread) to 
showcase, but for me (low-level and performance stuff mostly) it was more pain 
than joy. There are hot internal discussions currently about migrating to 
something more widely supported (with proper debugger, profiler, and other 
useful tools) for our next big project, because a new hardware is more powerful 
and there are fewer restrictions.

— 
Regards, Oleg
Art-System

signature.asc
Description: Message signed with OpenPGP using GPGMail