Re: [as-devel] I would like to help
sasha (sashav@sprintmail.com)
Thu, 8 Jun 2000 10:25:06 -0500
On Wed, 07 Jun 2000, Sean Dague wrote:
> Hey all,
Hiya
>
> I would like to volunteer what little time I have to whatever work needs
Oh that's verry good, welcome in :)
> to be done on AS at the moment. I have poked a little at the code over
> time (especially the WinList section as there seems to be concensus among
> the AS developers that it needs help) but I think I need a big picture
> explaination/architecture overview to see what is really going on with the
> way modules communication with AS and such.
Ok. I've added doc/Code/infrastructure and doc/Code/module_guide
files that should provide you with enough information. Any questions that you
may have - please feel free to ask.
>
> I am a moderate C programmer (with lots to learn), and I have only poked a
> little at X programming, but I would love to learn and help out in any way
> I can. (Most of my recent job work has been Perl and Java with a little
> bit of C mixed in)
The most important work right now is switching toi new config writer/reader
That is mostly C work with not much of a X involvement. You may consider doing
so. Basically You can check any module that is using its own ugly config reading
code, and try and convert it to unifyed config reader/writer. As an example of
using parser you can take Pager. This way will make you familiar with AfterStep
in the fastest fashion.
>
> If someone could point me to something useful that I could do, that would
> get me into the project, or just a good place to start reading code, that
> would be great.
also you can take an initiative and fix code anything I feel needs any work.
for example most of the modules, except for Wharf and Pager has not had any
maintainer for ages.
If you want to play with imaging - you can check out libasimage/asimage.c
for the work inprogress on new Afterstep imaging model.
There are few things I'd like to stress out :
1) Copy-And-Paste coding approach is a huge NONO. If you see a piece of code
from one module that you would like to use in another module - make it a
generic function and move it in appropriate lib. That was (and is in some
places ) the biggest problem with afterstep - same code existed in many
different places, making it huge and hard to maintain. Also if you spot
anything like that - take an effort and unite it. There are few exceptions from
that rule, mostly in imaging, as performance considerations prevail in those
cases.
2) any sort of parsing/imaging activity you may want to do - fisrt check the
libs, if it is already implemented. If it is so, or you can use something
similar if you'd make changes to it - then use it.
3) always perform memory audit at the end, prior to submitting your changes.
we don't want to see any memory leaks.
That should be it.
If you come up with any changes - please send me a patch, I'll go through it
and if it is good we'll add it to CVS and Ethan will add you as a developer to
CVS, so you can commit changes yourself.
Again - any questions - just ask them.
As charlie pointed out the best place to ask them is #afterstep on EFNet
I should be there most of the time.
Cheers
Sasha
>
> Hope to hear from you all.
>
> -Sean
>
> Sean Dague
> sean@dague.net
>
> There is no silver bullet. Plus, werewolves make better neighbors than
> zombies, and they tend to keep the vampire population down.