[emboss-dev] Mapping EMBOSS to Ruby, Perl and Python
Pjotr Prins
pjotr.public78 at thebird.nl
Tue Dec 1 11:38:35 UTC 2009
Hello, anyone on this list?
Pj.
On Mon, Nov 30, 2009 at 12:57:17PM +0100, Pjotr Prins wrote:
> For your inspection, I have committed a patch for splitting out the
> logic of ./emboss/transeq.c. The patch is here:
>
> http://github.com/pjotrp/EMBOSS/commit/713800c4aa08ddf70b87f245a524c1a0b30c0942
>
> The simplified transeq.c is here:
>
> http://github.com/pjotrp/EMBOSS/blob/biolib/emboss/transeq.c
>
> The new interfaces are here:
>
> http://github.com/pjotrp/EMBOSS/blob/biolib/emboss/function/emboss_transeq.c
>
> Basically I have split out the ACD logic and programming logic and
> given them new names:
>
> int transeq_acd(int argc, char **argv)
>
> AjPSeqout transeq( AjPSeqall seqall, AjPStr *framelist, AjPStr tablename, AjPRange regions, AjBool trim, AjBool clean, AjBool alternate)
>
> so you can call either from an external program. The advantage being
> the call interface is exactly the same, whether from the command
> line, the web interface, or directly through a shared linked library.
>
> What do you think? I propose to (slowly) accept splitting out the
> other routines in this fashion. As it does not interfere with EMBOSS
> it can be done in small steps.
>
> The file emboss/function/emboss_transeq.c may get some extra
> interfaces - the idea is that is contains nicely named and direct
> methods (unlike the internal 'ajCamelCase' naming conventions). A
> useful one would be a simple one reading frame translation with
> pre-selected translation table (for speed). But more on that later -
> I can also weight-lift that in biolib itself.
>
> The reason I want to do this here is to prevent duplication of
> functionality at different levels.
>
> Pj.
> _______________________________________________
> emboss-dev mailing list
> emboss-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/emboss-dev
More information about the emboss-dev
mailing list