From ableasby at hgmp.mrc.ac.uk Wed Jan 10 08:37:07 2001 From: ableasby at hgmp.mrc.ac.uk (ableasby at hgmp.mrc.ac.uk) Date: Wed, 10 Jan 2001 13:37:07 GMT Subject: EMBOSS ACD and GUIs Message-ID: <200101101337.NAA29181@tin.hgmp.mrc.ac.uk> Dear EMBOSS developers, The new year has brought GUI fever. We're currently testing W2H for emboss, Peter Rice is planning extensions for SRS, James Bonfield is doing work on the Staden interface (SPIN) and Tim Littlejohn is doing bionavigator things. All these are directly concerned with ACD and what we don't want are multiple ACD dialects out there (at least I think it'd be a shame). I believe everyone involved in this projects is on this emboss-dev list so maybe we can thrash out an ACD consensus here so we can get on with implementing it asap. So, this is a warning of activity and maybe those involved can say either what they've done or what they want. Cheers Alan From jkb at mrc-lmb.cam.ac.uk Wed Jan 10 09:03:04 2001 From: jkb at mrc-lmb.cam.ac.uk (James Bonfield) Date: Wed, 10 Jan 2001 14:03:04 +0000 Subject: ACD and GUIs Message-ID: <20010110140304.B1867@arran.mrc-lmb.cam.ac.uk> I'm reposting a message here, as previously sent to Alan... ----------------------------------------------------------------------------- Hello Alan, I've hit another problem, which I think maybe is easier to solve in another way (than I'm currently trying). There's lots of default values for each acd type. Eg sequence has a default prompt of "Input sequence". The next sequence type then has a different default prompt ("Input second sequence"). And so on. Sometimes there is no prompt: line, but instead acd uses the info: line. All these rules seem dependent on the acd type, as coded into ajacd.c. Obviously I could code all of these into my acd parser, but it's a long-winded approach. I'd be interested to know how others solved this - it appears to acd2xml parser simply didn't bother and prompts people with ghastly things like "-bsequence (single sequence)". Some of these don't matter too much in a GUI as the user can already see that there's two "input sequence" prompts, but currently our GUI is rather less friendly. For example instead of prompting for "Output sequence" we just get "outfile (-outfile)", as that's all that the acd2xml parser managed to work out. Anyway I'm thinking that a sensible approach would be to use something like progname -acdpretty; perhaps progname -acdcomplete. This would then write out a new acd file will all of the default values explicitly expanded up. This then means that the code for these default values is in just one place (your code) and emboss GUIs will automatically keep in sync without the need to edit more than one acd parser (and it's also much easier to write parsers). Is it easy to construct such an option? Cheers, James -- James Bonfield (jkb at mrc-lmb.cam.ac.uk) Tel: 01223 402499 Fax: 01223 213556 Medical Research Council - Laboratory of Molecular Biology, Hills Road, Cambridge, CB2 2QH, England. Also see Staden Package WWW site at http://www.mrc-lmb.cam.ac.uk/pubseq/ From jkb at mrc-lmb.cam.ac.uk Wed Jan 10 09:18:28 2001 From: jkb at mrc-lmb.cam.ac.uk (James Bonfield) Date: Wed, 10 Jan 2001 14:18:28 +0000 Subject: More ACD GUI bits Message-ID: <20010110141828.C1867@arran.mrc-lmb.cam.ac.uk> In addition to the previous note, here's my proposed additions to the ACD syntax. Forgive the woolly use of terms - I'm new to emboss and so don't know the correct terms for acd components. New types "frame" and "page". These are useful for graphical environments that want to group questions together in logical blocks. The frame attribute could be added to any other type. An example shows this best: frame: seqs [ info: "Select sequences" ] sequence: sequencea [ param: y type: any frame: seqs ] sequence: sequenceb [ param: y type: "@($(sequencea.protein) ? protein : nucleotide)" frame: seqs ] here both sequencea and sequenceb would be wrapped up inside their own frame, with an associated border. This could be a real "frame" in the Tk sense, or a table cell in an HTML interface. The info line is just a title for the frame, should the GUI in question wish to present frames in that manner. page is much the same thing, except it would represent pages on a tabbed notebook. For ultimate flexibility we should not disallow hierarchial definitions, just as long as they're in the correct order. For example: page: sequences [ info: "Sequences" ] frame: seqs [ page: sequences info "Select sequences" ] and even frame: seq1 [ frame: seqs ] (Although I'm clutching at straws to get a good real-world example here.) Clearly the command line ACD parser can simply skip these.Does anyone have any more suggestions for GUI structuring? My plan, already partially implemented, is to have an acd to tcl code generator. Each primary acd type (seqall, int, etc) relates precisely to a portion of generated code based around a tk megawidget of the same type. This has already been implemented here by Kathryn Beal, but she worked from the xml definitions produce by PISE's acd2xml convertor. Unfortunately that's the cause of many of our problems at present, hence the decision to go directly from acd. (Kathryn's SPIN does work well however, so I'll be reusing everything except the emboss dialogue generation code.) It's also evident that some of the programs have so many options that the dialogues simply do not fit on the screen. In such cases it's also obvious that the reason is due to lots of tweaking parameters which the average user would rather not see, but which the power use may ultimately like to use. Hence the idea of using a tabbed notebook to separate these out. We could look at the "optional" ACD attribute and automatically split the questions into the appropriate tabs, but this doesn't give us as much flexibility. Any thoughts on this idea would be much appreciated. -- James Bonfield (jkb at mrc-lmb.cam.ac.uk) Tel: 01223 402499 Fax: 01223 213556 Medical Research Council - Laboratory of Molecular Biology, Hills Road, Cambridge, CB2 2QH, England. Also see Staden Package WWW site at http://www.mrc-lmb.cam.ac.uk/pubseq/ From letondal at pasteur.fr Wed Jan 10 09:39:41 2001 From: letondal at pasteur.fr (Catherine Letondal) Date: Wed, 10 Jan 2001 15:39:41 +0100 Subject: EMBOSS ACD and GUIs In-Reply-To: Your message of "Wed, 10 Jan 2001 13:37:07 GMT." <200101101337.NAA29181@tin.hgmp.mrc.ac.uk> Message-ID: <200101101439.f0AEdfl353046@electre.pasteur.fr> ableasby at hgmp.mrc.ac.uk wrote: > Dear EMBOSS developers, > > The new year has brought GUI fever. We're currently testing W2H for emboss, > Peter Rice is planning extensions for SRS, James Bonfield is doing work on > the Staden interface (SPIN) and Tim Littlejohn is doing bionavigator things. > > All these are directly concerned with ACD and what we don't want are > multiple ACD dialects out there (at least I think it'd be a shame). I believe > everyone involved in this projects is on this emboss-dev list so maybe we can > thrash out an ACD consensus here so we can get on with implementing it asap. > > So, this is a warning of activity and maybe those involved can say either > what they've done or what they want. > Maybe something like a 'pipe' attribute, at least for input/output files, would be useful to connect programs together. I agree with the suggestion about having default prompts expanded by an acdpretty or acdcomplete feature as well as a way to group parameters in a hierarchical way. I feel very sorry for the acd2xml not being perfect!! :-) It's purpose was only to adapt EMBOSS descriptions to Pise, not to convert ACD into XML. I keep on suggesting that native XML ACDs would be great. -- Catherine Letondal -- Pasteur Institute Computing Center From jkb at mrc-lmb.cam.ac.uk Wed Jan 10 10:16:48 2001 From: jkb at mrc-lmb.cam.ac.uk (James Bonfield) Date: Wed, 10 Jan 2001 15:16:48 +0000 Subject: EMBOSS ACD and GUIs In-Reply-To: <200101101439.f0AEdfl353046@electre.pasteur.fr>; from letondal@pasteur.fr on Wed, Jan 10, 2001 at 03:39:41PM +0100 References: <200101101337.NAA29181@tin.hgmp.mrc.ac.uk> <200101101439.f0AEdfl353046@electre.pasteur.fr> Message-ID: <20010110151648.D1867@arran.mrc-lmb.cam.ac.uk> On Wed, Jan 10, 2001 at 03:39:41PM +0100, Catherine Letondal wrote: > > Maybe something like a 'pipe' attribute, at least for input/output files, > would be useful to connect programs together. As I understand it there is a -filter option which reads from stdin and writes to stdout, although obviously it only works for programs that take exactly one sequence. Output could be tricky too. You'd also need a way to silence the rest of the output, or alternatively to output it to stderr instead. execl() inherits open file descriptors [1] (unless the close-on-exec flag is set) which means that a parent process could open file descriptor 3 and then call a command which writes to descriptor 3. So this way a master program could create a communication channel which the separate programs in the pipeline all communicate via. That's perhaps overkill though! We thought a bit about connecting multiple programs together to produce pipelines. However that's far off on our plan. You'd obviously need a way of linking arguments together so that the user cannot specify the output of program 1 as "xyzzy" and the input for program 2 as "plugh". > I agree with the suggestion about having default prompts expanded by an acdpretty or > acdcomplete feature as well as a way to group parameters in a hierarchical way. > > I feel very sorry for the acd2xml not being perfect!! :-) It's purpose was only > to adapt EMBOSS descriptions to Pise, not to convert ACD into XML. I keep on suggesting > that native XML ACDs would be great. The problems we have with acd2xml though are mainly that it doesn't always copy over everything in the acd files, and that it's clearly designed to be read by perl rather than tcl (as it includes embedded perl expressions). As you rightly point out, this is because it's designed for Pise so I don't feel that we have any right to complain about this! :) Actually one other key reason for reading acd directly was that the tcl xml parser we used had some rather weird licence restrictions which we weren't entirely happy about, and reading acd is easier than xml anyway. If the acd reading works well enough we may even use the same format for our own analysis functions in Spin as it will cut down on the rather repetitive nature of our tcl/tk code! James [1] Rather amusingly I once discovered that on many systems the unix "write" command had a problem with open file descriptors. A shell out would reset the uid and gid to revoke the gid tty permissions, but it forgot to close the fd to the terminal being written too. This in turn means that other programs can then use ioctl()s (eg TIOCSTI) on the terminal to do intriguing things, such as inserting real keypresses into the 'keyboard buffer' and hence allowed complete hijacking of the remote session. Of course that was back in my naughtier Unix days :) -- James Bonfield (jkb at mrc-lmb.cam.ac.uk) Tel: 01223 402499 Fax: 01223 213556 Medical Research Council - Laboratory of Molecular Biology, Hills Road, Cambridge, CB2 2QH, England. Also see Staden Package WWW site at http://www.mrc-lmb.cam.ac.uk/pubseq/ From letondal at pasteur.fr Wed Jan 10 10:28:34 2001 From: letondal at pasteur.fr (Catherine Letondal) Date: Wed, 10 Jan 2001 16:28:34 +0100 Subject: EMBOSS ACD and GUIs In-Reply-To: Your message of "Wed, 10 Jan 2001 15:16:48 GMT." <20010110151648.D1867@arran.mrc-lmb.cam.ac.uk> Message-ID: <200101101528.f0AFSYl372347@electre.pasteur.fr> James Bonfield wrote: > As I understand it there is a -filter option which reads from stdin and writes > to stdout, although obviously it only works for programs that take exactly one > sequence. Output could be tricky too. You'd also need a way to silence the > rest of the output, or alternatively to output it to stderr instead. > > execl() inherits open file descriptors [1] (unless the close-on-exec flag is > set) which means that a parent process could open file descriptor 3 and then > call a command which writes to descriptor 3. So this way a master program > could create a communication channel which the separate programs in the > pipeline all communicate via. That's perhaps overkill though! > > We thought a bit about connecting multiple programs together to produce > pipelines. However that's far off on our plan. You'd obviously need a way of > linking arguments together so that the user cannot specify the output > of program 1 as "xyzzy" and the input for program 2 as "plugh". In Pise, the interface developper (the one who writes an XML definition file) says: this output file of program p1 is of type A this input file of program p2 is of type A And it's the interface generator's job to make the connection by linking input/output files of the same type. The user (do you mean the so-called "end-user" ?) does not specify anything? I don't think this has anything to do either with stdin/stdout, which is just the Unix implementation of pipelines. Actually, Pise Web interfaces "pipelines" don't use Unix pipes :-) Just think how convenient pipelines can be for database searches / multiple alignment and phylogenetic analyses. -- Catherine Letondal -- Pasteur Institute Computing Center From Peter.Rice at uk.lionbioscience.com Wed Jan 10 11:19:36 2001 From: Peter.Rice at uk.lionbioscience.com (Peter Rice) Date: Wed, 10 Jan 2001 16:19:36 +0000 Subject: ACD and GUIs References: <20010110140304.B1867@arran.mrc-lmb.cam.ac.uk> Message-ID: <3A5C8B98.B578B7F2@lionbio.co.uk> James Bonfield writes: >There's lots of default values for each acd type. Eg sequence has a default >prompt of "Input sequence". The next sequence type then has a different >default prompt ("Input second sequence"). And so on. Sometimes there is no >prompt: line, but instead acd uses the info: line. All these rules seem >dependent on the acd type, as coded into ajacd.c. Some of the mysteries are covered by the 'entrails' utility program, which gives you the extra qualifiers for each data type. Others are covered by -help (and -help -verbose), for example the ranges of values for integers. So, it is relatively easy to construct something for you. > Sometimes there is no prompt: line, but instead acd uses the info: line. We cleaned most of those up for PISE. The original idea was that EMBOSS would use the 'prompt', GUIs would use 'info', and help would use 'help', but that they could use alternatives when undefined. For PISE, we simplified this to only defining 'info' (we never needed more than one anyway as it turned out) but some 'prompt's may have crept back in. Peter -- ------------------------------------------------ Peter Rice, LION Bioscience Ltd, Cambridge, UK peter.rice at uk.lionbioscience.com +44 1223 224723 From Peter.Rice at uk.lionbioscience.com Wed Jan 10 11:29:52 2001 From: Peter.Rice at uk.lionbioscience.com (Peter Rice) Date: Wed, 10 Jan 2001 16:29:52 +0000 Subject: More ACD GUI bits References: <20010110141828.C1867@arran.mrc-lmb.cam.ac.uk> Message-ID: <3A5C8E00.E5E36EB6@lionbio.co.uk> James Bonfield writes: >In addition to the previous note, here's my proposed additions to the ACD >syntax. Forgive the woolly use of terms - I'm new to emboss and so don't know >the correct terms for acd components. >New types "frame" and "page". These are useful for graphical environments that >want to group questions together in logical blocks. The frame attribute could >be added to any other type. An example shows this best: Something like this would be very useful for me too. I am looking into defining EMBOSS applications in SRS. >frame: seqs [ > info: "Select sequences" >] > >sequence: sequencea [ > param: y > type: any > frame: seqs >] This is similar to the way SRS handles options at present, so I could live with it. But there may be a simpler way, which was planned in the early days of EMBOSS but not yet implemented. group: seqs [ info: "Select sequences" ] sequence: sequencea [ ..... ] endgroup: seqs Like your 'frames', groups could be nested. >page is much the same thing, except it would represent pages on a tabbed >notebook. For ultimate flexibility we should not disallow hierarchial >definitions, just as long as they're in the correct order. For example: > >page: sequences [ > info: "Sequences" >] > >frame: seqs [ > page: sequences > info "Select sequences" >] This can be a simple extension: group: sequences [ info: "sequences" type: page ] group: seqs [ info: "Select sequences" ] sequence: sequencea [ ..... ] endgroup: seqs endgroup: sequences ACD should allow missing endgroups, but -acdpretty should put them in :-) All options within a group would be defined together in the ACD file, and prompted for together. This will keep dependencies in the right order to simplify GUIs. Also, when run from the command line and prompting the user the group "info" text can be used as an extra prompt. Peter -- ------------------------------------------------ Peter Rice, LION Bioscience Ltd, Cambridge, UK peter.rice at uk.lionbioscience.com +44 1223 224723 From jkb at mrc-lmb.cam.ac.uk Wed Jan 10 12:02:34 2001 From: jkb at mrc-lmb.cam.ac.uk (James Bonfield) Date: Wed, 10 Jan 2001 17:02:34 +0000 Subject: More ACD GUI bits In-Reply-To: <3A5C8E00.E5E36EB6@lionbio.co.uk>; from Peter.Rice@uk.lionbioscience.com on Wed, Jan 10, 2001 at 04:29:52PM +0000 References: <20010110141828.C1867@arran.mrc-lmb.cam.ac.uk> <3A5C8E00.E5E36EB6@lionbio.co.uk> Message-ID: <20010110170234.A2637@arran.mrc-lmb.cam.ac.uk> On Wed, Jan 10, 2001 at 04:29:52PM +0000, Peter Rice wrote: > group: seqs [ info: "Select sequences" ] > > sequence: sequencea [ ..... ] > > endgroup: seqs > > Like your 'frames', groups could be nested. That's acceptable to me too. Initially I had a hierarchical method: frame: seqs [ info: "Select sequences" sequence: sequencea [ ..... ] ] This was easy for me to parse, but I guess it completely breaks the normal ACD structure :-} Hence my other suggested change. > ACD should allow missing endgroups, but -acdpretty should put them in :-) Missing endgroups wouldn't make it hard to parse (for me). A new group just appends on to the existing 'path' and the endgroup pops it off. I guess you'd disallow the following case: group: g1 [...] group: g2 [...] endgroup: g1 endgroup: g2 If so, then we do not need to specify which group is being ended. > All options within a group would be defined together in the ACD file, and > prompted for together. This will keep dependencies in the right order to > simplify GUIs. For generating HTML this is probably important. For my own work it doesn't matter as the order of items in a dialogue does not need to be the same as the order of tcl code used to generate the items. James -- James Bonfield (jkb at mrc-lmb.cam.ac.uk) Tel: 01223 402499 Fax: 01223 213556 Medical Research Council - Laboratory of Molecular Biology, Hills Road, Cambridge, CB2 2QH, England. Also see Staden Package WWW site at http://www.mrc-lmb.cam.ac.uk/pubseq/ From Peter.Rice at uk.lionbioscience.com Wed Jan 10 12:09:42 2001 From: Peter.Rice at uk.lionbioscience.com (Peter Rice) Date: Wed, 10 Jan 2001 17:09:42 +0000 Subject: More ACD GUI bits References: <20010110141828.C1867@arran.mrc-lmb.cam.ac.uk> <3A5C8E00.E5E36EB6@lionbio.co.uk> <20010110170234.A2637@arran.mrc-lmb.cam.ac.uk> Message-ID: <3A5C9756.27B53669@lionbio.co.uk> James Bonfield writes: >Missing endgroups wouldn't make it hard to parse (for me). A new group just >appends on to the existing 'path' and the endgroup pops it off. I guess you'd >disallow the following case: > >group: g1 [...] >group: g2 [...] >endgroup: g1 >endgroup: g2 > >If so, then we do not need to specify which group is being ended. I would say the 'endgroup: g1' ends any nested group(s) (g2) and the second endgroup would be an error. If I feel pedantic, I would add a warning for the first endgroup, as it is just untidy. But I suspect nested groups will be rare anyway (except for your page/frame arrangement maybe?) Peter -- ------------------------------------------------ Peter Rice, LION Bioscience Ltd, Cambridge, UK peter.rice at uk.lionbioscience.com +44 1223 224723 From coss at cnb.uam.es Wed Jan 10 12:51:59 2001 From: coss at cnb.uam.es (=?ISO-8859-1?Q?Carlos_Oscar_S=E1nchez_Sorzano?=) Date: Wed, 10 Jan 2001 18:51:59 +0100 Subject: EMBOSS ACD and GUIs In-Reply-To: <200101101337.NAA29181@tin.hgmp.mrc.ac.uk> Message-ID: Dear Emboss developers, it's amazing the number of new GUIs for emboss, that is really a sign of something. I want to remind of another one, Colimate, which is intended to work as a X interface. I expect to finish it by the end of february. As for the syntax and extended functionalities, I'm not an emboss user then I don't have the feeling of the actual needs. So, I will adjust to the syntax you prefer. Best regards, Carlos Oscar. On Wed, 10 Jan 2001 ableasby at hgmp.mrc.ac.uk wrote: > Dear EMBOSS developers, > > The new year has brought GUI fever. We're currently testing W2H for emboss, > Peter Rice is planning extensions for SRS, James Bonfield is doing work on > the Staden interface (SPIN) and Tim Littlejohn is doing bionavigator things. > > All these are directly concerned with ACD and what we don't want are > multiple ACD dialects out there (at least I think it'd be a shame). I believe > everyone involved in this projects is on this emboss-dev list so maybe we can > thrash out an ACD consensus here so we can get on with implementing it asap. > > So, this is a warning of activity and maybe those involved can say either > what they've done or what they want. > > Cheers > Alan > > ----------------------------------------------------------------------------- Carlos Oscar S?nchez Sorzano e-mail: coss at cnb.uam.es Unidad de Bioinform?tica http://biocomp.cnb.uam.es Centro Nacional de Biotecnolog?a (CSIC) Campus Universidad Autonoma (Cantoblanco) Tlf: 34-91-585 4683 28049 MADRID (SPAIN) Fax: 34-91-585 4506 ----------------------------------------------------------------------------- From bauer at genprofile.com Tue Jan 16 02:52:56 2001 From: bauer at genprofile.com (David Bauer) Date: Tue, 16 Jan 2001 08:52:56 +0100 Subject: List Problem Message-ID: <3A63FDD8.5332008F@genprofile.com> Hi, the list manager software seems to have a problem. >From one email it creates a second copy which contains the first 5 lines of the complete message. David. From bauer at genprofile.com Tue Jan 16 02:52:56 2001 From: bauer at genprofile.com (David Bauer) Date: Tue, 16 Jan 2001 08:52:56 +0100 Subject: List Problem Message-ID: <3A63FDD8.5332008F@genprofile.com> Hi, the list manager software seems to have a problem. >From one email it creates a second copy which contains the first 5 lines of the complete message. From gwilliam at hgmp.mrc.ac.uk Tue Jan 23 06:22:33 2001 From: gwilliam at hgmp.mrc.ac.uk (gwilliam at hgmp.mrc.ac.uk) Date: Tue, 23 Jan 2001 11:22:33 GMT Subject: function ajSeqMakeUsa proposed change Message-ID: <200101231122.LAA01107@bromine.hgmp.mrc.ac.uk> Does anyone have any objection to a change in the behaviour of ajSeqMakeUsa()? At present if the application is reading in a file holding many sequences and this routine is called on one of these sequences, it creates a USA in the style: Format::Filename for every sequence in that file. This is useless for pulling out a particular sequence from the file. I want to change it to make the full USA in the style: Format::Filename:Entryname ajSeqMakeUsa is only used in ajSeqGetUsa() I appear to be the only one using ajSeqGetUsa() - apart from ajtest which I guess won't affect anyone. applications affected: infoseq textsearch ajtest Thanks, Gary From birney at ebi.ac.uk Wed Jan 24 13:00:46 2001 From: birney at ebi.ac.uk (Ewan Birney) Date: Wed, 24 Jan 2001 18:00:46 +0000 (GMT) Subject: BOSC 2001 [Bioinformatics Open Source Conference] Message-ID: [PLEASE do not reply to this mail as it is cross-posted to many lists. PLEASE reply to bosc at bubbles.sonsorol.org. I am assumming that people KNOW HOW TO DRIVE THEIR MAIL CLIENTS. Think before hitting reply! This is an experiment to see how smart the general bioinformatics hacker is] We will be attempting to run another Bioinformatics Open Source Conference just before ISMB 2001. We have recieved information that this is likely to be able to occur and will possibly have extensive computer support, therefore allowing development to occur as well as talks. At the moment we are gathering our thoughts and generally mapping out the form of the conference. We would like input from the wider open source bioinformatics community for ideas about the conference. The practical aims of this is to (a) come up with a format for the day(s) (b) appoint a committee to run the conference. It is likely that myself and Chris Dadigidan will be the core of the committee as we've done this before and we know what is going on. (Frankly if someone wants to take over my cheer-leading role, you are more than welcome! Endless patience and good email-discipline is a must...) I would suggest the following committee membership: Each of the major groups nominate one person on the committee. I would suggest: bioperl (possibly me or chris), biojava, biopython, emboss, acedb, ensembl (possibly me) each has one person assigned to be on the committee. Then I would like to see if we can reach out into the smaller projects, including ones I haven't listed here, such as the nascent bioLISPers, I believe there is an open source Bio PathWays group, the Apollo/Gadfly people might want to make sure they are represented. (biocorba and bioxml - you are smaller projects at the moment) Ideally one or two people can come from the smaller projects. Total committee should be 8 or less. [PS - if you know of people who "have a project" but they are in the primordial soup stage of the project, please forward this mail onto them] Comments should be addressed to bosc at bubbles.sonsorol.org - like I said, I expect the major projects to assign their own representitive or say they are not interested. Ewan Birney ----------------------------------------------------------------- Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420 . ----------------------------------------------------------------- From david.martin at biotek.uio.no Tue Jan 30 01:34:52 2001 From: david.martin at biotek.uio.no (David Martin) Date: Tue, 30 Jan 2001 07:34:52 +0100 Subject: Install woes Message-ID: When installing emboss recently I get a load of errors due to libraries not found. The main problem is that I have an old version of libz but no lib gd in my system libraries and EMBOSS looks there first to try to locate these libraries. I have the correct versions installed elsewhere. Deleting -lgd -lz -lpng from CFLAGS in the ajax directory Makefile works but is an ugly solution and not really ideal. Are there any suggestions for setting the library search path or am I missing something really obvious? ..d --------------------------------------------------------------------- * Dr. David Martin Biotechnology Centre of Oslo * * Node Manager Gaustadalleen 21 * * The Norwegian EMBNet Node P.O. box 1125 Blindern * * tel +47 22 84 05 35 N-0317 Oslo * * fax +47 22 84 05 01 Norway * --------------------------------------------------------------------- From david.martin at biotek.uio.no Wed Jan 31 07:32:19 2001 From: david.martin at biotek.uio.no (David Martin) Date: Wed, 31 Jan 2001 13:32:19 +0100 Subject: EMNU Message-ID: I have been slowly going through the painful process of trying to get EMNU running on the SGI. The curses requirement seems to be specifically gnu ncurses and not generic curses. Could gary elaborate on this? Also , as both form.h and menu.h (at least in RH6.2) call curses.h is it neccessary to include curses.h? I suppose I just have to find and install ncurses now instead of using curses. (somewhat freudian phrasing here methinks). Please in future could such development packages get a 0.x version rather than the 1.x currently given until they are stable and the installation is appropriately documented. ..d --------------------------------------------------------------------- * Dr. David Martin Biotechnology Centre of Oslo * * Node Manager Gaustadalleen 21 * * The Norwegian EMBNet Node P.O. box 1125 Blindern * * tel +47 22 84 05 35 N-0317 Oslo * * fax +47 22 84 05 01 Norway * --------------------------------------------------------------------- From ableasby at hgmp.mrc.ac.uk Wed Jan 10 13:37:07 2001 From: ableasby at hgmp.mrc.ac.uk (ableasby at hgmp.mrc.ac.uk) Date: Wed, 10 Jan 2001 13:37:07 GMT Subject: EMBOSS ACD and GUIs Message-ID: <200101101337.NAA29181@tin.hgmp.mrc.ac.uk> Dear EMBOSS developers, The new year has brought GUI fever. We're currently testing W2H for emboss, Peter Rice is planning extensions for SRS, James Bonfield is doing work on the Staden interface (SPIN) and Tim Littlejohn is doing bionavigator things. All these are directly concerned with ACD and what we don't want are multiple ACD dialects out there (at least I think it'd be a shame). I believe everyone involved in this projects is on this emboss-dev list so maybe we can thrash out an ACD consensus here so we can get on with implementing it asap. So, this is a warning of activity and maybe those involved can say either what they've done or what they want. Cheers Alan From jkb at mrc-lmb.cam.ac.uk Wed Jan 10 14:03:04 2001 From: jkb at mrc-lmb.cam.ac.uk (James Bonfield) Date: Wed, 10 Jan 2001 14:03:04 +0000 Subject: ACD and GUIs Message-ID: <20010110140304.B1867@arran.mrc-lmb.cam.ac.uk> I'm reposting a message here, as previously sent to Alan... ----------------------------------------------------------------------------- Hello Alan, I've hit another problem, which I think maybe is easier to solve in another way (than I'm currently trying). There's lots of default values for each acd type. Eg sequence has a default prompt of "Input sequence". The next sequence type then has a different default prompt ("Input second sequence"). And so on. Sometimes there is no prompt: line, but instead acd uses the info: line. All these rules seem dependent on the acd type, as coded into ajacd.c. Obviously I could code all of these into my acd parser, but it's a long-winded approach. I'd be interested to know how others solved this - it appears to acd2xml parser simply didn't bother and prompts people with ghastly things like "-bsequence (single sequence)". Some of these don't matter too much in a GUI as the user can already see that there's two "input sequence" prompts, but currently our GUI is rather less friendly. For example instead of prompting for "Output sequence" we just get "outfile (-outfile)", as that's all that the acd2xml parser managed to work out. Anyway I'm thinking that a sensible approach would be to use something like progname -acdpretty; perhaps progname -acdcomplete. This would then write out a new acd file will all of the default values explicitly expanded up. This then means that the code for these default values is in just one place (your code) and emboss GUIs will automatically keep in sync without the need to edit more than one acd parser (and it's also much easier to write parsers). Is it easy to construct such an option? Cheers, James -- James Bonfield (jkb at mrc-lmb.cam.ac.uk) Tel: 01223 402499 Fax: 01223 213556 Medical Research Council - Laboratory of Molecular Biology, Hills Road, Cambridge, CB2 2QH, England. Also see Staden Package WWW site at http://www.mrc-lmb.cam.ac.uk/pubseq/ From jkb at mrc-lmb.cam.ac.uk Wed Jan 10 14:18:28 2001 From: jkb at mrc-lmb.cam.ac.uk (James Bonfield) Date: Wed, 10 Jan 2001 14:18:28 +0000 Subject: More ACD GUI bits Message-ID: <20010110141828.C1867@arran.mrc-lmb.cam.ac.uk> In addition to the previous note, here's my proposed additions to the ACD syntax. Forgive the woolly use of terms - I'm new to emboss and so don't know the correct terms for acd components. New types "frame" and "page". These are useful for graphical environments that want to group questions together in logical blocks. The frame attribute could be added to any other type. An example shows this best: frame: seqs [ info: "Select sequences" ] sequence: sequencea [ param: y type: any frame: seqs ] sequence: sequenceb [ param: y type: "@($(sequencea.protein) ? protein : nucleotide)" frame: seqs ] here both sequencea and sequenceb would be wrapped up inside their own frame, with an associated border. This could be a real "frame" in the Tk sense, or a table cell in an HTML interface. The info line is just a title for the frame, should the GUI in question wish to present frames in that manner. page is much the same thing, except it would represent pages on a tabbed notebook. For ultimate flexibility we should not disallow hierarchial definitions, just as long as they're in the correct order. For example: page: sequences [ info: "Sequences" ] frame: seqs [ page: sequences info "Select sequences" ] and even frame: seq1 [ frame: seqs ] (Although I'm clutching at straws to get a good real-world example here.) Clearly the command line ACD parser can simply skip these.Does anyone have any more suggestions for GUI structuring? My plan, already partially implemented, is to have an acd to tcl code generator. Each primary acd type (seqall, int, etc) relates precisely to a portion of generated code based around a tk megawidget of the same type. This has already been implemented here by Kathryn Beal, but she worked from the xml definitions produce by PISE's acd2xml convertor. Unfortunately that's the cause of many of our problems at present, hence the decision to go directly from acd. (Kathryn's SPIN does work well however, so I'll be reusing everything except the emboss dialogue generation code.) It's also evident that some of the programs have so many options that the dialogues simply do not fit on the screen. In such cases it's also obvious that the reason is due to lots of tweaking parameters which the average user would rather not see, but which the power use may ultimately like to use. Hence the idea of using a tabbed notebook to separate these out. We could look at the "optional" ACD attribute and automatically split the questions into the appropriate tabs, but this doesn't give us as much flexibility. Any thoughts on this idea would be much appreciated. -- James Bonfield (jkb at mrc-lmb.cam.ac.uk) Tel: 01223 402499 Fax: 01223 213556 Medical Research Council - Laboratory of Molecular Biology, Hills Road, Cambridge, CB2 2QH, England. Also see Staden Package WWW site at http://www.mrc-lmb.cam.ac.uk/pubseq/ From letondal at pasteur.fr Wed Jan 10 14:39:41 2001 From: letondal at pasteur.fr (Catherine Letondal) Date: Wed, 10 Jan 2001 15:39:41 +0100 Subject: EMBOSS ACD and GUIs In-Reply-To: Your message of "Wed, 10 Jan 2001 13:37:07 GMT." <200101101337.NAA29181@tin.hgmp.mrc.ac.uk> Message-ID: <200101101439.f0AEdfl353046@electre.pasteur.fr> ableasby at hgmp.mrc.ac.uk wrote: > Dear EMBOSS developers, > > The new year has brought GUI fever. We're currently testing W2H for emboss, > Peter Rice is planning extensions for SRS, James Bonfield is doing work on > the Staden interface (SPIN) and Tim Littlejohn is doing bionavigator things. > > All these are directly concerned with ACD and what we don't want are > multiple ACD dialects out there (at least I think it'd be a shame). I believe > everyone involved in this projects is on this emboss-dev list so maybe we can > thrash out an ACD consensus here so we can get on with implementing it asap. > > So, this is a warning of activity and maybe those involved can say either > what they've done or what they want. > Maybe something like a 'pipe' attribute, at least for input/output files, would be useful to connect programs together. I agree with the suggestion about having default prompts expanded by an acdpretty or acdcomplete feature as well as a way to group parameters in a hierarchical way. I feel very sorry for the acd2xml not being perfect!! :-) It's purpose was only to adapt EMBOSS descriptions to Pise, not to convert ACD into XML. I keep on suggesting that native XML ACDs would be great. -- Catherine Letondal -- Pasteur Institute Computing Center From jkb at mrc-lmb.cam.ac.uk Wed Jan 10 15:16:48 2001 From: jkb at mrc-lmb.cam.ac.uk (James Bonfield) Date: Wed, 10 Jan 2001 15:16:48 +0000 Subject: EMBOSS ACD and GUIs In-Reply-To: <200101101439.f0AEdfl353046@electre.pasteur.fr>; from letondal@pasteur.fr on Wed, Jan 10, 2001 at 03:39:41PM +0100 References: <200101101337.NAA29181@tin.hgmp.mrc.ac.uk> <200101101439.f0AEdfl353046@electre.pasteur.fr> Message-ID: <20010110151648.D1867@arran.mrc-lmb.cam.ac.uk> On Wed, Jan 10, 2001 at 03:39:41PM +0100, Catherine Letondal wrote: > > Maybe something like a 'pipe' attribute, at least for input/output files, > would be useful to connect programs together. As I understand it there is a -filter option which reads from stdin and writes to stdout, although obviously it only works for programs that take exactly one sequence. Output could be tricky too. You'd also need a way to silence the rest of the output, or alternatively to output it to stderr instead. execl() inherits open file descriptors [1] (unless the close-on-exec flag is set) which means that a parent process could open file descriptor 3 and then call a command which writes to descriptor 3. So this way a master program could create a communication channel which the separate programs in the pipeline all communicate via. That's perhaps overkill though! We thought a bit about connecting multiple programs together to produce pipelines. However that's far off on our plan. You'd obviously need a way of linking arguments together so that the user cannot specify the output of program 1 as "xyzzy" and the input for program 2 as "plugh". > I agree with the suggestion about having default prompts expanded by an acdpretty or > acdcomplete feature as well as a way to group parameters in a hierarchical way. > > I feel very sorry for the acd2xml not being perfect!! :-) It's purpose was only > to adapt EMBOSS descriptions to Pise, not to convert ACD into XML. I keep on suggesting > that native XML ACDs would be great. The problems we have with acd2xml though are mainly that it doesn't always copy over everything in the acd files, and that it's clearly designed to be read by perl rather than tcl (as it includes embedded perl expressions). As you rightly point out, this is because it's designed for Pise so I don't feel that we have any right to complain about this! :) Actually one other key reason for reading acd directly was that the tcl xml parser we used had some rather weird licence restrictions which we weren't entirely happy about, and reading acd is easier than xml anyway. If the acd reading works well enough we may even use the same format for our own analysis functions in Spin as it will cut down on the rather repetitive nature of our tcl/tk code! James [1] Rather amusingly I once discovered that on many systems the unix "write" command had a problem with open file descriptors. A shell out would reset the uid and gid to revoke the gid tty permissions, but it forgot to close the fd to the terminal being written too. This in turn means that other programs can then use ioctl()s (eg TIOCSTI) on the terminal to do intriguing things, such as inserting real keypresses into the 'keyboard buffer' and hence allowed complete hijacking of the remote session. Of course that was back in my naughtier Unix days :) -- James Bonfield (jkb at mrc-lmb.cam.ac.uk) Tel: 01223 402499 Fax: 01223 213556 Medical Research Council - Laboratory of Molecular Biology, Hills Road, Cambridge, CB2 2QH, England. Also see Staden Package WWW site at http://www.mrc-lmb.cam.ac.uk/pubseq/ From letondal at pasteur.fr Wed Jan 10 15:28:34 2001 From: letondal at pasteur.fr (Catherine Letondal) Date: Wed, 10 Jan 2001 16:28:34 +0100 Subject: EMBOSS ACD and GUIs In-Reply-To: Your message of "Wed, 10 Jan 2001 15:16:48 GMT." <20010110151648.D1867@arran.mrc-lmb.cam.ac.uk> Message-ID: <200101101528.f0AFSYl372347@electre.pasteur.fr> James Bonfield wrote: > As I understand it there is a -filter option which reads from stdin and writes > to stdout, although obviously it only works for programs that take exactly one > sequence. Output could be tricky too. You'd also need a way to silence the > rest of the output, or alternatively to output it to stderr instead. > > execl() inherits open file descriptors [1] (unless the close-on-exec flag is > set) which means that a parent process could open file descriptor 3 and then > call a command which writes to descriptor 3. So this way a master program > could create a communication channel which the separate programs in the > pipeline all communicate via. That's perhaps overkill though! > > We thought a bit about connecting multiple programs together to produce > pipelines. However that's far off on our plan. You'd obviously need a way of > linking arguments together so that the user cannot specify the output > of program 1 as "xyzzy" and the input for program 2 as "plugh". In Pise, the interface developper (the one who writes an XML definition file) says: this output file of program p1 is of type A this input file of program p2 is of type A And it's the interface generator's job to make the connection by linking input/output files of the same type. The user (do you mean the so-called "end-user" ?) does not specify anything? I don't think this has anything to do either with stdin/stdout, which is just the Unix implementation of pipelines. Actually, Pise Web interfaces "pipelines" don't use Unix pipes :-) Just think how convenient pipelines can be for database searches / multiple alignment and phylogenetic analyses. -- Catherine Letondal -- Pasteur Institute Computing Center From Peter.Rice at uk.lionbioscience.com Wed Jan 10 16:19:36 2001 From: Peter.Rice at uk.lionbioscience.com (Peter Rice) Date: Wed, 10 Jan 2001 16:19:36 +0000 Subject: ACD and GUIs References: <20010110140304.B1867@arran.mrc-lmb.cam.ac.uk> Message-ID: <3A5C8B98.B578B7F2@lionbio.co.uk> James Bonfield writes: >There's lots of default values for each acd type. Eg sequence has a default >prompt of "Input sequence". The next sequence type then has a different >default prompt ("Input second sequence"). And so on. Sometimes there is no >prompt: line, but instead acd uses the info: line. All these rules seem >dependent on the acd type, as coded into ajacd.c. Some of the mysteries are covered by the 'entrails' utility program, which gives you the extra qualifiers for each data type. Others are covered by -help (and -help -verbose), for example the ranges of values for integers. So, it is relatively easy to construct something for you. > Sometimes there is no prompt: line, but instead acd uses the info: line. We cleaned most of those up for PISE. The original idea was that EMBOSS would use the 'prompt', GUIs would use 'info', and help would use 'help', but that they could use alternatives when undefined. For PISE, we simplified this to only defining 'info' (we never needed more than one anyway as it turned out) but some 'prompt's may have crept back in. Peter -- ------------------------------------------------ Peter Rice, LION Bioscience Ltd, Cambridge, UK peter.rice at uk.lionbioscience.com +44 1223 224723 From Peter.Rice at uk.lionbioscience.com Wed Jan 10 16:29:52 2001 From: Peter.Rice at uk.lionbioscience.com (Peter Rice) Date: Wed, 10 Jan 2001 16:29:52 +0000 Subject: More ACD GUI bits References: <20010110141828.C1867@arran.mrc-lmb.cam.ac.uk> Message-ID: <3A5C8E00.E5E36EB6@lionbio.co.uk> James Bonfield writes: >In addition to the previous note, here's my proposed additions to the ACD >syntax. Forgive the woolly use of terms - I'm new to emboss and so don't know >the correct terms for acd components. >New types "frame" and "page". These are useful for graphical environments that >want to group questions together in logical blocks. The frame attribute could >be added to any other type. An example shows this best: Something like this would be very useful for me too. I am looking into defining EMBOSS applications in SRS. >frame: seqs [ > info: "Select sequences" >] > >sequence: sequencea [ > param: y > type: any > frame: seqs >] This is similar to the way SRS handles options at present, so I could live with it. But there may be a simpler way, which was planned in the early days of EMBOSS but not yet implemented. group: seqs [ info: "Select sequences" ] sequence: sequencea [ ..... ] endgroup: seqs Like your 'frames', groups could be nested. >page is much the same thing, except it would represent pages on a tabbed >notebook. For ultimate flexibility we should not disallow hierarchial >definitions, just as long as they're in the correct order. For example: > >page: sequences [ > info: "Sequences" >] > >frame: seqs [ > page: sequences > info "Select sequences" >] This can be a simple extension: group: sequences [ info: "sequences" type: page ] group: seqs [ info: "Select sequences" ] sequence: sequencea [ ..... ] endgroup: seqs endgroup: sequences ACD should allow missing endgroups, but -acdpretty should put them in :-) All options within a group would be defined together in the ACD file, and prompted for together. This will keep dependencies in the right order to simplify GUIs. Also, when run from the command line and prompting the user the group "info" text can be used as an extra prompt. Peter -- ------------------------------------------------ Peter Rice, LION Bioscience Ltd, Cambridge, UK peter.rice at uk.lionbioscience.com +44 1223 224723 From jkb at mrc-lmb.cam.ac.uk Wed Jan 10 17:02:34 2001 From: jkb at mrc-lmb.cam.ac.uk (James Bonfield) Date: Wed, 10 Jan 2001 17:02:34 +0000 Subject: More ACD GUI bits In-Reply-To: <3A5C8E00.E5E36EB6@lionbio.co.uk>; from Peter.Rice@uk.lionbioscience.com on Wed, Jan 10, 2001 at 04:29:52PM +0000 References: <20010110141828.C1867@arran.mrc-lmb.cam.ac.uk> <3A5C8E00.E5E36EB6@lionbio.co.uk> Message-ID: <20010110170234.A2637@arran.mrc-lmb.cam.ac.uk> On Wed, Jan 10, 2001 at 04:29:52PM +0000, Peter Rice wrote: > group: seqs [ info: "Select sequences" ] > > sequence: sequencea [ ..... ] > > endgroup: seqs > > Like your 'frames', groups could be nested. That's acceptable to me too. Initially I had a hierarchical method: frame: seqs [ info: "Select sequences" sequence: sequencea [ ..... ] ] This was easy for me to parse, but I guess it completely breaks the normal ACD structure :-} Hence my other suggested change. > ACD should allow missing endgroups, but -acdpretty should put them in :-) Missing endgroups wouldn't make it hard to parse (for me). A new group just appends on to the existing 'path' and the endgroup pops it off. I guess you'd disallow the following case: group: g1 [...] group: g2 [...] endgroup: g1 endgroup: g2 If so, then we do not need to specify which group is being ended. > All options within a group would be defined together in the ACD file, and > prompted for together. This will keep dependencies in the right order to > simplify GUIs. For generating HTML this is probably important. For my own work it doesn't matter as the order of items in a dialogue does not need to be the same as the order of tcl code used to generate the items. James -- James Bonfield (jkb at mrc-lmb.cam.ac.uk) Tel: 01223 402499 Fax: 01223 213556 Medical Research Council - Laboratory of Molecular Biology, Hills Road, Cambridge, CB2 2QH, England. Also see Staden Package WWW site at http://www.mrc-lmb.cam.ac.uk/pubseq/ From Peter.Rice at uk.lionbioscience.com Wed Jan 10 17:09:42 2001 From: Peter.Rice at uk.lionbioscience.com (Peter Rice) Date: Wed, 10 Jan 2001 17:09:42 +0000 Subject: More ACD GUI bits References: <20010110141828.C1867@arran.mrc-lmb.cam.ac.uk> <3A5C8E00.E5E36EB6@lionbio.co.uk> <20010110170234.A2637@arran.mrc-lmb.cam.ac.uk> Message-ID: <3A5C9756.27B53669@lionbio.co.uk> James Bonfield writes: >Missing endgroups wouldn't make it hard to parse (for me). A new group just >appends on to the existing 'path' and the endgroup pops it off. I guess you'd >disallow the following case: > >group: g1 [...] >group: g2 [...] >endgroup: g1 >endgroup: g2 > >If so, then we do not need to specify which group is being ended. I would say the 'endgroup: g1' ends any nested group(s) (g2) and the second endgroup would be an error. If I feel pedantic, I would add a warning for the first endgroup, as it is just untidy. But I suspect nested groups will be rare anyway (except for your page/frame arrangement maybe?) Peter -- ------------------------------------------------ Peter Rice, LION Bioscience Ltd, Cambridge, UK peter.rice at uk.lionbioscience.com +44 1223 224723 From coss at cnb.uam.es Wed Jan 10 17:51:59 2001 From: coss at cnb.uam.es (=?ISO-8859-1?Q?Carlos_Oscar_S=E1nchez_Sorzano?=) Date: Wed, 10 Jan 2001 18:51:59 +0100 Subject: EMBOSS ACD and GUIs In-Reply-To: <200101101337.NAA29181@tin.hgmp.mrc.ac.uk> Message-ID: Dear Emboss developers, it's amazing the number of new GUIs for emboss, that is really a sign of something. I want to remind of another one, Colimate, which is intended to work as a X interface. I expect to finish it by the end of february. As for the syntax and extended functionalities, I'm not an emboss user then I don't have the feeling of the actual needs. So, I will adjust to the syntax you prefer. Best regards, Carlos Oscar. On Wed, 10 Jan 2001 ableasby at hgmp.mrc.ac.uk wrote: > Dear EMBOSS developers, > > The new year has brought GUI fever. We're currently testing W2H for emboss, > Peter Rice is planning extensions for SRS, James Bonfield is doing work on > the Staden interface (SPIN) and Tim Littlejohn is doing bionavigator things. > > All these are directly concerned with ACD and what we don't want are > multiple ACD dialects out there (at least I think it'd be a shame). I believe > everyone involved in this projects is on this emboss-dev list so maybe we can > thrash out an ACD consensus here so we can get on with implementing it asap. > > So, this is a warning of activity and maybe those involved can say either > what they've done or what they want. > > Cheers > Alan > > ----------------------------------------------------------------------------- Carlos Oscar S?nchez Sorzano e-mail: coss at cnb.uam.es Unidad de Bioinform?tica http://biocomp.cnb.uam.es Centro Nacional de Biotecnolog?a (CSIC) Campus Universidad Autonoma (Cantoblanco) Tlf: 34-91-585 4683 28049 MADRID (SPAIN) Fax: 34-91-585 4506 ----------------------------------------------------------------------------- From bauer at genprofile.com Tue Jan 16 07:52:56 2001 From: bauer at genprofile.com (David Bauer) Date: Tue, 16 Jan 2001 08:52:56 +0100 Subject: List Problem Message-ID: <3A63FDD8.5332008F@genprofile.com> Hi, the list manager software seems to have a problem. >From one email it creates a second copy which contains the first 5 lines of the complete message. David. From bauer at genprofile.com Tue Jan 16 07:52:56 2001 From: bauer at genprofile.com (David Bauer) Date: Tue, 16 Jan 2001 08:52:56 +0100 Subject: List Problem Message-ID: <3A63FDD8.5332008F@genprofile.com> Hi, the list manager software seems to have a problem. >From one email it creates a second copy which contains the first 5 lines of the complete message. From gwilliam at hgmp.mrc.ac.uk Tue Jan 23 11:22:33 2001 From: gwilliam at hgmp.mrc.ac.uk (gwilliam at hgmp.mrc.ac.uk) Date: Tue, 23 Jan 2001 11:22:33 GMT Subject: function ajSeqMakeUsa proposed change Message-ID: <200101231122.LAA01107@bromine.hgmp.mrc.ac.uk> Does anyone have any objection to a change in the behaviour of ajSeqMakeUsa()? At present if the application is reading in a file holding many sequences and this routine is called on one of these sequences, it creates a USA in the style: Format::Filename for every sequence in that file. This is useless for pulling out a particular sequence from the file. I want to change it to make the full USA in the style: Format::Filename:Entryname ajSeqMakeUsa is only used in ajSeqGetUsa() I appear to be the only one using ajSeqGetUsa() - apart from ajtest which I guess won't affect anyone. applications affected: infoseq textsearch ajtest Thanks, Gary From birney at ebi.ac.uk Wed Jan 24 18:00:46 2001 From: birney at ebi.ac.uk (Ewan Birney) Date: Wed, 24 Jan 2001 18:00:46 +0000 (GMT) Subject: BOSC 2001 [Bioinformatics Open Source Conference] Message-ID: [PLEASE do not reply to this mail as it is cross-posted to many lists. PLEASE reply to bosc at bubbles.sonsorol.org. I am assumming that people KNOW HOW TO DRIVE THEIR MAIL CLIENTS. Think before hitting reply! This is an experiment to see how smart the general bioinformatics hacker is] We will be attempting to run another Bioinformatics Open Source Conference just before ISMB 2001. We have recieved information that this is likely to be able to occur and will possibly have extensive computer support, therefore allowing development to occur as well as talks. At the moment we are gathering our thoughts and generally mapping out the form of the conference. We would like input from the wider open source bioinformatics community for ideas about the conference. The practical aims of this is to (a) come up with a format for the day(s) (b) appoint a committee to run the conference. It is likely that myself and Chris Dadigidan will be the core of the committee as we've done this before and we know what is going on. (Frankly if someone wants to take over my cheer-leading role, you are more than welcome! Endless patience and good email-discipline is a must...) I would suggest the following committee membership: Each of the major groups nominate one person on the committee. I would suggest: bioperl (possibly me or chris), biojava, biopython, emboss, acedb, ensembl (possibly me) each has one person assigned to be on the committee. Then I would like to see if we can reach out into the smaller projects, including ones I haven't listed here, such as the nascent bioLISPers, I believe there is an open source Bio PathWays group, the Apollo/Gadfly people might want to make sure they are represented. (biocorba and bioxml - you are smaller projects at the moment) Ideally one or two people can come from the smaller projects. Total committee should be 8 or less. [PS - if you know of people who "have a project" but they are in the primordial soup stage of the project, please forward this mail onto them] Comments should be addressed to bosc at bubbles.sonsorol.org - like I said, I expect the major projects to assign their own representitive or say they are not interested. Ewan Birney ----------------------------------------------------------------- Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420 . ----------------------------------------------------------------- From david.martin at biotek.uio.no Tue Jan 30 06:34:52 2001 From: david.martin at biotek.uio.no (David Martin) Date: Tue, 30 Jan 2001 07:34:52 +0100 Subject: Install woes Message-ID: When installing emboss recently I get a load of errors due to libraries not found. The main problem is that I have an old version of libz but no lib gd in my system libraries and EMBOSS looks there first to try to locate these libraries. I have the correct versions installed elsewhere. Deleting -lgd -lz -lpng from CFLAGS in the ajax directory Makefile works but is an ugly solution and not really ideal. Are there any suggestions for setting the library search path or am I missing something really obvious? ..d --------------------------------------------------------------------- * Dr. David Martin Biotechnology Centre of Oslo * * Node Manager Gaustadalleen 21 * * The Norwegian EMBNet Node P.O. box 1125 Blindern * * tel +47 22 84 05 35 N-0317 Oslo * * fax +47 22 84 05 01 Norway * --------------------------------------------------------------------- From david.martin at biotek.uio.no Wed Jan 31 12:32:19 2001 From: david.martin at biotek.uio.no (David Martin) Date: Wed, 31 Jan 2001 13:32:19 +0100 Subject: EMNU Message-ID: I have been slowly going through the painful process of trying to get EMNU running on the SGI. The curses requirement seems to be specifically gnu ncurses and not generic curses. Could gary elaborate on this? Also , as both form.h and menu.h (at least in RH6.2) call curses.h is it neccessary to include curses.h? I suppose I just have to find and install ncurses now instead of using curses. (somewhat freudian phrasing here methinks). Please in future could such development packages get a 0.x version rather than the 1.x currently given until they are stable and the installation is appropriately documented. ..d --------------------------------------------------------------------- * Dr. David Martin Biotechnology Centre of Oslo * * Node Manager Gaustadalleen 21 * * The Norwegian EMBNet Node P.O. box 1125 Blindern * * tel +47 22 84 05 35 N-0317 Oslo * * fax +47 22 84 05 01 Norway * ---------------------------------------------------------------------