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

timothyhobbs at seznam.cz timothyhobbs at seznam.cz
Thu Oct 18 14:37:04 EDT 2012


Things are going pretty well in the development.  I can now send and receive
frames and process them correctly.  One question.  I have to figure out if 
the user is left handed or right handed.  This is not yet defined by the 
standard that I wrote.  There are several options:  brltty could provide 
this information, and this information could be global to brltty.  My driver
could take a special parameter or save a special settings file to the users 
home directory.  This information could be stored on the device.  What do 
you recommend?

Tim


---------- Původní zpráva ----------
Od: Dave Mielke <dave at mielke.cc>
Datum: 16. 10. 2012
Předmět: Re: [BRLTTY] Getting my braille driver for the FCHAD working.
"[quoted lines by timothyhobbs at seznam.cz on 2012/10/15 at 23:36 +0200]

>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 didn't belittle or attack you in any way. You asked questions, and I gave 
you 
detailed answers. In my answers, of course, I endeavoured to ensure that 
there 
were certain things which I felt you needed to understand.

I speak very directly, and I make no apologies for this. It's the way I am. 
I 
don't beat around bushes and play endless games of tact, as, in my opinion, 
those kinds of discussions go nowhere, with no one, in the end, 
understanding 
what the others have said.

One thing I won';t do is give a partial answer. If you're going to challenge

the way that brltty is maintained, developed, etc, I'm going to give you a 
real 
answer. Would you expect any less? If not, don't complain if you don't 
happen 
to like the full answer.

>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.

And none of that has changed. I won't comment on my own friendliness (or 
lack 
thereof), though, since that's for others to judge. If you feel that I'm not

friendly enough for you, though, then please let me know and I'll let others

answer all of your questions. Don't worry - I won't take it hard at all. I 
know 
that I can't please everyone, and I don't try to, either.

>I have no idea what has gone wrong.  

Nothing has gone wrong. But, to put everything out on the table, these are 
the 
two points of controversy which have occurred:

First: You apparently would like your code to be accepted into brltty, but I

don't think it currently meets an acceptable standard for that. Would you 
prefer that I just quietly let you code away, and then, when you're all 
done, 
refuse it? Wouldn't you rather be set on the right path as early as 
possible?

Second: You challenged the way that brltty has been implemented and is being

maintained in a way which assumes that you have all the right reasons and we

are too dumb to see them and/or have made a lot of poor decisions along the 
way. That, really, wasn't a very nice thing to have done. You really ought 
to 
show others the same degree of respect that you demand for yourself. Oops! I

guess that wasn't a very friendly thing to say, right?

On the second point: I'm quite familiar with how educational institutions 
have 
a way of convincing their attendees that they know everything, and that we 
"old-fashioned" people know next to nothing. The reality, though, is that it

only takes a little bit of time out in the business world for students to 
finally learn just how little they actually know about how things need to be

done in the real world. Oops! There I go again, not being friendly enough 
and 
all.

>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.  

Good intentions don't always generate high quality. Let me give you an 
example. 
Let's say that I'm the only adult at home, along with a bunch of very hungry

little children. I could have the best intentions in the world regarding 
cooking them a quality meal. The fact that I haven't got a clue how to 
actually 
cook a decent meal shouldn't matter, should it? Isn't my good intention to 
cook 
them a good meal good enough? Of course not! If I were to carry through with
my 
good intentions, I'd likely end up with a bunch of dead little children.

>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.

I don't believe you really believe that. What do you think would happen if I

were to grant full public write capability to brltty's source repository, 
and 
to never inspect any code that is ever put into it. I just let anyone in the

whole world write any kind of code they want, make any kinds of changes they

want, etc, and then, on some particular date, I just take whatever has been 
done and release it.

This is what you're saying, but I know it's not what you mean because I 
trust 
you readily acknowledge that that kind of approach would yield nothing less 
than sheer chaos. While good intentions, sharing, and all that are great 
things, there also needs to be some form of quality control. There's no way 
that anyone, no matter how good his intentions, should be freely permitted 
to 
simply do as he pleases in any project, especially if that project has a 
large 
user base which is relying on it as a critical resource.

>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.

Did you really think I meant that seriously? I can assure you that I was 
using 
humour to make a point. Yes, it really was intended as humour. I do have a 
sense of that, too, you know.

>I am now seeing my logMessages.  So I can now happily inform you that no
>more printf statements will appear in my code!  

Yay!!! :-)

>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. 

Again, yay!!! And not even the need for a void* either. All properly type 
checked and clean. Progress!

>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.  

I think you'll find that brltty's code is, for the most part, quite clean 
and 
also quite efficient. That being said, as I said earlier, performance isn't 
the 
primary issue. I myself much prefer clean and easy-to-understand code over 
efficiency.

>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.

And a seasoned programmer learns to not let that happen, and takes the time 
to 
try to teach less seasoned programmers to not let that happen.

>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?

-lingio

-l accepts a comma-delimited list of keywrods which can include one log 
level 
and any number of log categories. So, for example, what you probably really 
want to specify is this:

-ldebug,ingio

See logCategoryTable[] in log.c at line 54.

-- 
Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God.
Phone: 1-613-726-0014 | Ottawa, Ontario | 2011 May 21 is the End of 
Salvation.
EMail: dave at mielke.cc | Canada K2A 1H7 | http://Mielke.cc/now.html
(http://Mielke.cc/now.html)
http://FamilyRadio.com/(http://FamilyRadio.com/) | http://Mielke.cc/bible/
(http://Mielke.cc/bible/)
_______________________________________________
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/20121018/ff1de785/attachment.html>


More information about the BRLTTY mailing list