[BRLTTY] Getting my braille driver for the FCHAD working.

Mon Oct 15 17:36:46 EDT 2012

I must admit, that after reading your message I began to cry.  Human to 
human interactions have never been my strong point, but my own emotion right
now is that of being belittled, attacked, and most of all surprised.  I have
spent almost two years now on this project.  Last summer met Samuel and Jean
-Philippe at RMLL.  They seemed friendly and nice.  When I joined this list 
over a year ago, I was pleased by the quick and helpful responses I 
received.

I have no idea what has gone wrong.  I am only trying to help blind people
(and myself) by creating a cheep open source hardware alternative to the 
expensive brailled displays on the market today.  Let us remember the 
optimism and good faith upon which open source is founded.  The entire idea
(to me at least) is that by being generous, by sharing, and working 
together, we can achieve things that we wouldn't have achieved through a 
greed driven model.  To me, the entirety of open source is about freedom and
human goodness.  I trust code because it's open source.  Not only because I 
know I can look inside it, but because I believe that the person who wrote 
it wrote it, and made it open source, in a good faith effort to better 
humanity.

The fact that we have managed to go from a single global variable 
declaration to accusations of rebellion is, at the face of it, actually 
rather funny ;) It's the kind of thing that one should only see in black 
comedy.

I am now seeing my logMessages.  So I can now happily inform you that no 
more printf statements will appear in my code!  I have also gotten rid of 
the use of thisBrl as a global variable.  I now pass it along through the 
even handling system bundled in a struct as I had described.  

The event handler itself is not very complicated. It is just 17 lines of 
code!  I get away with so little code, because my event handlers are stored 
in a static array.  Any truly generic, general purpose, full blown, event 
handler could not get away with this.  I can make assumptions, like that 
there will never be more than a certain constant number of handlers for each
event, that simply wouldn't fly with the more complex event systems like the
one in glib.

I didn't mean to attack your use of C.  I was just trying to point out that 
there is often such a trade off between cleanness of the code and 
performance.  In a inconsiderably small degree, the code I had before the 
change I just made was more preformant than it is now, both in terms of time
and memory usage.  I know thinking about the individual bytes is rather 
silly at this level, but given that I'm simultaneously writing firmware for 
the device which must run on the atmega, I have those bytes in my mind a bit
more than is typical.

Looking at the code for io_generic.c , I see that as you said: 

if(LOG_CATEGORY_FLAG(GENERIC_INPUT)) {
            logBytes(categoryLogLevel, "generic input", &endpoint->input.
buffer[endpoint->input.to], result);
}

How do I set the LOG_CATEGORY_FLAG to include GENERIC_INPUT?

Thank you,

Timothy

---------- Původní zpráva ----------
Od: S. Massy <lists at wolfdream.ca>
Datum: 15. 10. 2012
Předmět: Re: [BRLTTY] Getting my braille driver for the FCHAD working.
"On Mon, Oct 15, 2012 at 04:22:28AM -0400, Dave Mielke wrote:
> [quoted lines by timothyhobbs at seznam.cz on 2012/10/14 at 16:32 +0200]
> 
> >But at this point, why are we using C at all?  If we want good design and

> >maintainability at the price of performance then we should use a higher 
level 
> >language.  Once you start repacking values into structs to make scoping 
more 
> >obvious you lose the performance advantages of using a low level 
language.  
> >And you still haven't gained the clean clarity of a high level one.  
> 
> I don't disagree with you in principle, but I do disagree with you in 
> perspective.
> 
> First of all, whoever said that performance is the issue? Would it shock 
you to 
> hear me say that performance isn't the issue? Well ... it isn't.
> 
> Do you think that brltty is just a fun toy which runs on high-level 
operating 
> systems like Linux and Windows? Are you aware that it also runs on DOS, 
and 
> that work is underway to enable it to run within the Grub bootr loader? 
There's 
> no way that necessarily limited environments such as those would be able 
to 
> adequately support the kinds of high-level languages which you have in 
mind.
> 
> Are you aware that brltty isn't a university project? All of us who work 
on it 
> do this as a strictly volunteer effort, and most of us have families, 
jobs, 
> etc. Why would we waste our precious time rewriting something that works, 
just 
> ecaause it's a theoretically good idea?
> 
> Aside from being a pointless way to be spending our time, that kind of 
work 
> would also come with the need for a great deal of retesting of code which 
is 
> known to be reliable, as well as the need to retest with all of the 
various 
> models of braille devices, each of which is extremely expensive and/or 
> extremely difficult to gain free access to. Additionally, we'd no longer 
have 
> any time to devote to useful work such as supporting more types of braille

> devices, more host platforms, etc.
Dave is 250% right. You can think of brltty as "production" software, in
its way as crucial to its community as the Linux kernel; people are
highly unlikely to rewrite or reinvent it for mere philosophical or
aesthetic reasons, nor even for a possible slight performance increase.
Not that my opinion matters in any respect on this discussion, but a
better understanding of this project and community probably would help
you gain insight for your project, as it seems to focus on human-machine
relationships, and all of us on this list very much rely on such a
relationship to lead more productive lives. :)

Just my penny's worth...

Cheers,
S.M.
_______________________________________________
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY at mielke.cc
For general information, go to: http://mielke.cc/mailman/listinfo/brltty
(http://mielke.cc/mailman/listinfo/brltty)"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mielke.cc/pipermail/brltty/attachments/20121015/8e95d5f3/attachment.html>