Re: [phact0rial@xxxxxxx: Re: Arabization]

["Chahine M. Hamila" <mch at chaham dot com>]

Hi,

Mohammed Elzubeir a *crit :

> I received thie email and thought I might fwd it to the 'developer' list.
> All comments welcome.
>
> ----- Forwarded message from Phactorial - <phact0rial at xxxxxx> -----
>
> X-Originating-IP: [212.138.47.13]
> From: "Phactorial -" <phact0rial at xxxxxxxx>
> To: elzubeir at xxxxxxxxxx
> Subject: Re: Arabization
> X-OriginalArrivalTime: 08 Jun 2002 20:24:58.0229 (UTC) FILETIME=[8F04BA50:01C20F2A]
>
> Well, I just looked at Akka, and porting should hopefully be a very trivial
> proposition.

Just out of curiosity, porting to what? FreeBSD?

> The time this will take is currently not known as I am
> reorginizing some of the code base.

In which sense?

>  I am
> also interested in joining the ArabEyes project and should've hopefully sent
> a request by the time this e-mail has arrived.
>
> I just need your (and the other developer's) consent on the following:
>
>  - I have switched the "CHANGES" style into a more unified and detailed
> format. This will allow us to work (or atleast allow me) much more
> efficiently. Could the developers adopt this as their format as well?
>
>      Format:
>        ----------------------------------------------------
>         <DATE>
>        ----------------------------------------------------
>         <file relative to current directory>
>            <developer name>: <changes>

okay

>
>
>  - I would like to ask all the Akka developers to heavily comment system
> architecture specific conventions, especially ioctl's. I will be doing this
> for all the calls in the 1.0 release, this is just a (very good) suggestion
> for future development.
>
>      Example:
>        ioctl(i,TIOCSCTTY,&tty);    /* FreeBSD: become controlling tty */
>
>    This should really ease the job of porting Akka to yet other system
> architectures (and will even attract other programmers who see this as a
> perfect oppertunity to recieve good criticism for a very straight forward
> job)

Anyone learning about Akka is welcome to do it. Commenting is in fact an excellent way
to understand others' code. But when you're coding, you won't take the trouble in
general to code every line, including what is trivial. For example, everyone (I
suppose at least everyone who's playing with Akka's code) knows what an ioctl is. Now
if we don't know what ioctl call it is, and a simple man gives you the answer, it's
clear the one who wrote the line won't necessarily see it as a must. I mean, your
suggestion is good, but that's more the job of those who are new to the code than the
ones who are actually making it. Note that I am not talking about the tricky parts and
the algorithms which should definitely be commented.

>
>
>  - All error checking for system calls should print out the representation
> of the errno value. I will be changing all error checking messages for the
> 1.0 release to perror(). Can you warn the other developers to do this as
> well (in future development)?

That's a matter of coding style and context. Depends which messages. In general errors
should be sent to STDERR, you're right on that point, but use whatever suits you when
you're the one who writes the code.

> This allows for much more verbose messaging
> for potentially confused end-users. Can I also take out some generally
> trivial function calls to reduce the number of library dependencies (the
> amount of library dependencies was made very obvious during compilation)?

Which ones? Two things here: reinventing the wheel is a Bad Thing. If a library does
what you need, then use the lib. Library dependencies are not an evil, very much the
opposite, they avoid unnecessarily bloating the soft. So if removing trivial call
means removing some features or writing more code, then it's a Bad Thing.
On the other hand, what you can do is make some features optional. Say, if you don't
want the libfribidi dep, you can make the bidi dependent features optional at compile
time.

> Do
> you really need those glib routines, libc provides sufficient alternatives.

The glib routines were re-introduced for fribidi's sake. If I understand things right,
the latest version of fribidi doesn't need them anymore, so feel free to see if you
can do that cleanly. Do not use the libc alternatives if it means writing more.
Libraries are there to help us, for reuse, not for ornament.

>  - Use unified coding styles as to make the Akka code look perty (ex: your
> FreeBSD code compared to Chahine's. I will be switching your coding style to
>     blend with Chahine's, is that alright with you? Not that his coding
> style is     very legible :P).

Haha:) legibility is in the eyes of the beholder;)

> I will also be changing the commenting style
> for full ANSI     compatibility.

Please don't. ANSI style isn't necessary the most practical around and nobody should
be bound by them.
Also note that most comments were put in doc++ format. Don't break the doc++ style,
you should in fact follow it, the existing comments might be outdated but they might
still be useful.

>
>
>  - The FreeBSD port will take some more time due to my efforts in the
> above. I will be making the above changes to the 1.0 codebase and foward
> copies to the    developers so they will integrate any of their new code
> into a hopefully much more efficient floor to stand on. You should recieve
> the new beautified copy soon.
>
>  - Can we work out a time where I can speak to the developers and (or)
> yourself through IRC? I will try to hang around #arabeyes at opennetworks
> when possible. There are some very integral questions I would like answered
> regarding Akka...

I am *extremely* busy, to an insane point really. So I can maybe manage half an hour
during a European very late night. If that suits you tell me when and I'll be there.

Yalla, good to see some developers around;)
Salaam,
Chahine