Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: Random numbers et al
From: Blue Chip (cs_bluechip_at_webtribe.net)
Date: 2003-04-08


> > My hope had been to offer something to Rockbox community.
>
>You appear to have much to offer. But rewriting existing code in assembler
>is not a top priority for the project. I'm sure you have read the
>docs/CONTRIBUTING file:
>
> Language
> --------
> Write all code in C. Sometimes assembly is faster, but C is always more
> readable and maintainable.

Yes, I DID read that, and depending on the level of the general contriuting
community, I agree.
It was this reason that I proposed only to ASM'ise code which would not be
edited any more.

>If you rewrote, say, sprintf in assembler we'd have a much harder time
>adding new formatting options to it, for example. Hence the doubt: "Is it
>a benefit?"

Yes, good point. Although, if written well, and well commented, it would
not be THAT difficult.
However, something like qsort, might benefit immensely. Maybe a more
selective approach would be appropriate?

> > There are zero docs on how the firmware works or how it "hangs together"
> > (its basic structure) and code comments are almost unheard of.
>
>No comments? We must be reading different sources. In fact, we have
>received much praise about how our code is simple and easy to follow.

By example: system.c is a true mystery to me.

>However, I admit we are severely lacking in the documentation department.
>This is a common problem in voluntary projects, since it's often more
>rewarding to write new code than to write documentation about the old.
>That, plus documentation quickly becomes outdated. This is one area where
>we need help.

I am not at all abject to writing docs and abusively commenting code, but I
would need to understand what was going on before I do it!

> > I thought that I would offer you the benefit of my skills
>[...]
> > I am _genuinely_ surprised at how much resistance I have come across!
>
>Your skills are most welcome. But you must expect people to question your
>assumptions, especially when you come out with all guns blazing ("a
>horribly complex and memory hungry block of code").

hmmm, okay, I can see how that could be misread. It was not meant to be
aggresive, it's just the way I talk. What it means is...

Given the application that your current random number generator is used
for, the code which you have, although an impressive generator, is (imho)
unnecessarily complex and memory hungry. Given that the play-list
randomisation routine is good, a far simpler and smaller algorithm would
produce equally good results and save a considerable amount of memory.

I then went on to say that if you would like to make this saving, I could
provide this code along with full documentation (including ISBN reference
numbers) as a C++ lib immediately, or change it to standard C in a few minutes.

...the reason for offering it as a C++ lib, was in case anybody was
interested in it for personal reasons. The reasons for mentioning the docs
and bibliography was to suggest that this algorithm was well researched and
understood, not just something I made up.

>This is a project with many highly skilled people, and hence many great
>egos. We should all strive to act and speak in a humble fashion, and the
>general discussion will be more pleasant.

It was never my intent to offend - I don't TRY to make enemies. I will
only defend myself when I am attacked.

> > You can imagine how I felt when it was suggested that my skills would
> > be best applied to "making the cursor flash" (see IRC logs.)
>
>I just checked the log. It looks like a simple misunderstanding. Nobody
>talked about flashing a cursor. adi|work mentioned a problem which might
>actually spark your interest:
>
>There is a general desire to change the current cursor into an inverted
>line, but the only attempt so far suffered from poor performance while
>scrolling through a file list, and thus was rejected. It's a tricky
>problem due to the lcd memory layout, our dynamic font system and the fact
>that lcd update is done over a rather slow serial link (written in
>assembler, by the way).

Yes, that makes sense of his suggestion - yes, a misunderstanding it would
seem.
Sounds far more interesting when put like that.
Is the last (rejected) solution available to look at?

>In closing, this is a voluntary project. Everyone does whatever tickles
>their fancy. Therefore, we don't assign tasks to people. We have a feature
>request tracker (http://rockbox.haxx.se/requests.shtml) and I keep a
>loosely written TODO (http://rockbox.haxx.se/TODO), but nobody decides who
>does what.

That's fair, very similar to my DVD work!

Btw. I hope my references to my previous work serve their purpose as "this
is who I am and what I do", they were NOT intended as "look how great I
am", clearly there are some other fantastic minds here or else this
firmware would not be as good as it is. I know -many- great programmers,
and, as you say, we all "know it." (I hope that translates okay.)

Regards,

Bc



Page was last modified "Jan 10 2012" The Rockbox Crew
aaa