Re: [RFC] New task: science-dataacquisition
Andreas Tille til...@rki.de writes: [Move this thread to debian-custom list because it belongs here instead of debian-science list.] On Thu, 11 Dec 2008, Chris Walker wrote: The fact that until now nobody has sended me a patch to blends-dev in my eyes is a prove that there is nobody out there who regards a deeper structure in metapackages as important enough to spend some time on it. I've not yes found the time to do this - but one of these days... Sounds like a new years intention. ;-) :-). We'll see what I get around to. [short versions] Done. Excellent. If you did that, and also provided a means of having subsections - by not sorting the packages at all (currently they are alphabetical), and having the ability to put in subheadings - not sure of an appropriate syntax, but something along the lines of: [snip] ... If you ... provided a means Well, IMHO we are stretching the debian-science list to far for this topic. It is not me - it is a Debian Pure Blends effort. We should move the discussion to this place. The current state is: The tasks files contain per definition an _unordered_ _list_ of dependencies. (OK, med-bio has some *unmaintained* structure hidden in Why:-tagged comments.) Having an _unordered_ _list_ published on the web pages just sucks - so the only automatic means for an ordering is alphabethical. What you want is: Proposing a Section marker field that enables a parsing program to detect sections (or even subsections). Document the field in the Blends documentation. BTW, RFC822 format actually does not really support this sectioning. It is a flat file format with paragraphs. Each paragraph ends with a blank line. A section field which should be valid for more than one paragraph entry is in principle a hackish solution. I do not say that this is a real problem - but I would like you to be aware about this. (I wonder whether I should tell that XML would be the proper solution for your suggestion because there were enough XML versus RFC822 flame wars - at least you will have a hard time to convince me to change a running system. I guess working patches would be convincing but probably no e-mails without patches.) One alternative that comes to mind (and I don't know if it is better or not) is to put the structure in subdirectories (and perhaps that is what you are telling me by suggesting a physics blend). Once you have ironed out your proposal on the mailing list and in the documentation start inserting these section fields in at least 50% of the existing tasks files. Once this work is done I see that there is at least one person who regards the problem as important enough to push me for an implementation of this feature. Please don't get me wrong: I do not say that your suggestion is bad. In principle I like it. It has the side effect that the web pages become even more important than metapackages (because they will not reflect this new feature). This is OK, because the web pages are even visible for the whole non-Debian world. Indeed. I think that debtags are probably the ultimate solution for the Debian world - but haven't worked out quite how to apply them. One flaw with the metapackages approach is that they you end up installing several packages to do the same thing. I don't think you really want this - why install 3 packages to grab data from scanned graphs - after some initial testing, you'll only ever use one. It might be possible to use ORed packages, though this perhaps makes it more difficult to say to your sysadmin install the physics task and I'll have everything I need. But you are simply competing with for instance a lot of GNUmed users who desperately are waiting for a GNUmed server package, other Debian Med users are waiting for updated packages in the field of imaging (BioImageSuite is not even tackled by a Debian maintainer). So you have to compete with the wishlist bugs of other users and convince me that your wishlist is more important than theirs. Indeed. Maintaining a competing Wiki page is doing manual work for less information with the constant danger of beeing outdated for the small advantage of slightly more flexibility in the content and having the chance (but not the real effect) to involce more people. It is the extra structure that I think is useful. I've been organising the wiki as a prototype structure useful until someone gets around to adding this facility to the tasks files. As I said this was well done and the job you did was really important. What I further said is: The time is ripe for this someone to start with the tasks files *now*. For physics, in the immediate future, I plan to stop explicitly listing packages in the data acquisition and numerical computation tasks, and replace them with a link to the task. I shall probably do
Re: [RFC] New task: science-dataacquisition
On Thu, 11 Dec 2008, Jordan Mantha wrote: ... I think that is largely the state of afairs. Morten has done excellent work and I've shifted essentially all my scientific packaging pursuits to Debian Science and Debchem. I even became a DM to help do as much work as I'm able to in Debian with the limited time I have. Part of the issue has been, I think, that Ubuntu is primarily IRC-driven and Debian is much more mailing list-driven so there sort of a communication mismatch there. I don't think it's an unsurmountable hurdle or anything, it just needs to be taken into account. Ahh, OK. Thanks for your work and this explanation. I certainly wouldn't put you in that corner :-) Ubuntu needs to be able to take constructive criticism, just like everybody else. For my part, as the guy that started the MOTU Science team and then had to let it go as my dissertation got started, I think there is distinct room for improvement in Ubuntu's handling of science packages that I just haven't been able to address. For that I do feel bad. If Debian Science has some suggestions and/or tips that might help things go better I think Ubuntu would like to know. As I suggested I think it would make sense to join here on the Debian mailing list. IMHO it is the vital interest of Ubuntu science team to have Debian science packages in good shape because it costs less work in the end. We use a Debian/Ubuntu version tracker [0] to give us information on how we're doing. We are tracking 696 total packages. IMHO it would make perfectly sense to compare your list with our tasks files [2] and see what might be missing (on both sides). The problem I have with the list [0] is that just from having the names listed without any descrioption I fail to see the relevance for which specific science. IMHO it would be a very reasonable thing to do to work down the list[0] and do something like this: for pkg in Packages from Debian ; do if ! grep $pkg science/trunk/debian-science/tasks/* ; then apt-cache show $pkg echo Depends: $pkg tasks file which fits fi done With this simple algorithm we would make sure that Debian is making profit from the work of the Ubuntu science people who did obviosely some research on the package pool. BTW, what do you think about our metapackage technique and the web pages we are rendering out of the tasks files? IMHO it might make sense to have a look at the bugs pages [3] as well - if the quality of the Debian package is good you will not have to deal with much bugs in Ubuntu. Of those only 5 packages ( 0.7%) are not in Sid. Those 5 are old packages we've imported from elsewhere and frankly aren't worth Debian's time. So you are talking about the Not in Sid : 5 packages of [0]? I think Morten is working on some of them and for some purpose they might be worth the work. We have 4 packages that have a newer version in Ubuntu than what's in Sid. We should certainly be getting those back to Debian where possible. The Outdated in Sid packages of [0]? Did you filed any New version available bugs? I hope that the situation becomes better once I managed to build watch pages (like I did for the bug pages[3]). Right around 90% of the packages are taken from Debian without any modification. Only 1.5 % are out of date in Jaunty (current devel release) with respect to Sid. Overall I think we're doing a pretty good job of sticking close to Debian where we can and not lagging. Could you please give some insight about this build process? It is done somehow automatically or it is just like Ubuntu maintainer downloads Debian source package, modifies changelog, builds and uploads? The biggest problem I think Ubuntu is having is getting overloaded with bugs. We have 365 science bugs open currently [1] and that's just too much for a handful of people to try to get all triaged and forwarded quickly. How are these bugs related to the Debian BTS status? Are there a lot of bugs concerning the same issues? Are the bugs forewarded to Debian BTS if it is unknown here? No flamewars needed :-) I think Debian and Ubuntu have a lot more in common than not. Thanks. I would really love if discussion culture on debian-science list is better than on debian-devel ... Kind regards Andreas. [0] http://qa.ubuntuwire.com/multidistrotools/science.html [1] https://bugs.launchpad.net/~motuscience/+packagebugs [2] http://svn.debian.org/wsvn/cdd/projects/science/trunk/debian-science/tasks/?rev=0sc=0 [3] http://cdd.alioth.debian.org/science/bugs/index.html -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] New task: science-dataacquisition
On Fri, 12 Dec 2008, Charles Plessy wrote: I do not know if it has been well advertised, but we also can have links to Ubuntu bugs from Debian: http://qa.debian.org/developer.php?login=debian-science-maintain...@lists.alioth.debian.orgubuntu=1ordering=3 It is in fact not that well advertised and I have to admit that while I can perfectly see the version information of the Ubuntu package I have not found information about bugs reported in Ubuntu. And we can close Launchpd bugs by LP:#123456 numbers in our changelogs, just as we do for our own bugs (this of course takes effects when Ubuntu syncs the packge). That's also new to me - I should remember this ... I have found Ubuntu bugs valuable information for my packaging, and for the Debian Med package try to close and merge them when I can in order to get a better signal/noise ratio. Sure. I agree in principle but I admit I'm lacking the knowledge about the techniques which are helpful to do so. If someone with knowledge how to query bugs in Ubuntu automatically I'd be in favour to list these bugs on our bugs page as well (provided that there is a good chance to get rid of duplicates). Any Ubuntu volunteer to join the Debian Pure Blends effort to accomplish this? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] New task: science-dataacquisition
On Thu, 2008-12-11 at 00:20 +, Chris Walker wrote: Andreas Tille [EMAIL PROTECTED] writes: On Tue, 9 Dec 2008, Chris Walker wrote: Libcv1 - a computer vision library What do you want to tell me by this? This is for image analysis - and so should probably go alongside Gpiv - in an image acquisition/analysis metapackage. OK, one dependency for imageanalysis. Any more? # Particle image velocitometry (move these from data acquisition) gpiv, gpiv-tools I agree, it does not belong here as it does many other things. Only packages that are purely for data-acquisition do belong here. Gerber Add # Scanning Probe Microscopy (SPM) data visualization and analysis. gwyddion There is also a strong argument for # Graph Digitization (extracting data from published graphs available as bitmaps) engauge-digitizer g3data Chris Nb all of these are based on package descriptions, not personal knowledge. -- Gerber van der Graaf http://gpiv.sourceforge.net GnuPG key fingerprint: BF0A BBFE 5623 9761 C9E1 7C82 8B08 F586 D39A 2B64 signature.asc Description: This is a digitally signed message part
Re: [RFC] New task: science-dataacquisition
On Tue, 9 Dec 2008, Chris Walker wrote: Indeed. The big advantage of the wiki is the ease with which anyone can edit it and categorise things themselves Could you please have a look at the WIki Changelog who actually did the last ten edits. (No, I did not checked, but I wild guess there are at best 2 out of ten if the page is older than 6 monthes.) (my initial categorisations of the chemistry packages were rapidly improved by a real chemist for example). Sure. I think the Wiki is a perfect tool for the *initial* work to find a reasonable set - especially if you are no specialist. That's why I'm in favour of starting with a Wiki and move this work to tasks files after a two to three monthes period. After this time the interest of people vanishes in practice anyway and it becomes a single persons playground - at least this is my observation for lesser popular Wikis than for instance WikiPedia and the hype about Wikis in general which was triggered by WikiPedia is not really justified if you look at the state of several Wikis thoroughly. The possibility that everybody can work on a piece of text does not mean automatically that everybody really does so. Regarding the time saving aspect: The dataacquisition page took me about 15 minutes (the green entries only one minute, the othes costs some research on upstream websites). Do you think the Wiki can compete with this? No it can't. I really like the fact that the tasks pages can generate things like version information and homepage automatically. ... and bugs pages which are an important QA tool. As I promised there are more such tools to come - und you get all of them for free. You also seem to underestimate the profit we gain by having always the full package description on the tasks pages - and we do provide even up to date translations. It is not only the versioning information and homepage. What the wiki can do, and the tasks can't do (at least not yet) is have sections and subsubsections and potentially some explanatory text. This allows you to group packages that perform similar tasks near each other - which makes it easier to ignore packages you aren't interested in. If you use metapackages, you end up having information spread across several pages - which just makes it harder to find. To take a recent example, if you knew engauge-digitizer could extract numbers from bitmap graphs, but it didn't do quite what you want, how do you find g3data? With the current implementation of tasks, you would have to look through a dozen or more other packages in the dataacquisition task to find it[1,3]. With subsubsections, the packages would be next to each other in the list. I agree that categorising (=subsections) is a good thing in principle - but you always have to keep in mind what purpose or categorisation should serve: We want to give our users quick access to the packages that might be interesting for them. We will fail to do so if we a) Force the user to understand a complicated categorisation system (chances are really high that a random user will have a different categorisation in mind than we have). b) Hide programs in a deep categorisation tree. This is not better than the flat non-categorised package pool. That's why I'm not in favour of layers of metapackages but have only a single layer. The fact that until now nobody has sended me a patch to blends-dev in my eyes is a prove that there is nobody out there who regards a deeper structure in metapackages as important enough to spend some time on it. Before we had metapackages and tasks pages people were forced to browse the whole package pool for descriptions - and they probably failed to do so (6 monthes ago I was seeking for a digitiser like engauge-digitizer and g3data - but failed to find it). Now we have metapackages and you have to browse a list of order 10 (compared to a list of order 1 in the flat package pool). That's an enhancement of three orders of magnitude. Now you are asking to stretch the concept farther? I'd call this overkill. If people are not willing to read the really shortened list (while perhaps learning about some other packages they might be interested in) IMHO they do not deserve our work. And so they do not really deserve your manual Wiki editing. In an ideal world, I think we should be able to generate something like https://help.ubuntu.com/community/UbuntuScience#Physics automatically - with an option of long description or short description (to make it easier to scan down the entire list)[4]. Well, I admit I'm not really impressed by the URL above. IMHO what we provide on the tasks pages is better. If you want to generate a shortened List with only short descriptions - well, that's cheap. Could be a simple wishlist bug (the webtools are not (yet) in BTS, but I can put this on my todo list). It would be simple to create a page per Blend which lists all the short descriptions with homepage links and #task
Re: [RFC] New task: science-dataacquisition
On Tue, 9 Dec 2008, Chris Walker wrote: There might be some merit in an ImageAnalysis task as well (or perhaps instead). Yes. Just provide perhaps three package dependencies for this task and I will create the according tasks file - or just create it yourself according to the given template (... once svn.debian.org is working properly again). Yes. We should probably put some barrier here to suggest only those packages that are really useful for scientific research. Completely agree. Groups other than scientists will have these problems too - in fact surely there must be some other group in Debian dealing with video cameras/webcams? A Debian Multimedia Blend comes into mind ... The DeMuDi project was a start, but they rather branched from Debian than working inside (even if there were some efforts to join in the past). Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] New task: science-dataacquisition
On Tue, 9 Dec 2008, Chris Walker wrote: Libcv1 - a computer vision library What do you want to tell me by this? This is for image analysis - and so should probably go alongside Gpiv - in an image acquisition/analysis metapackage. OK, one dependency for imageanalysis. Any more? gpsd - GPS (Global Positioning System) daemon Added as Suggests. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] New task: science-dataacquisition
On Tue, 9 Dec 2008, Carlo Segre wrote: So why do you hesitate to upload? Primarily because the documentation is not complete and there are a couple of final issues in the packaging that need to straightened out. The documentation will take a long time so it should probably not be a stumbling block but I do want to fix the final packaging issues. OK, I agree that good documentation is an important thing and I apreciate that you care for the quality of the package that way. On the other hand I really believe that if we make projects popular via official Debian packages you get more people involved - and perhaps you find some people who volunteer to help with the documentation by publishing it this way. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] New task: science-dataacquisition
On Wed, 10 Dec 2008, Stuart Prescott wrote: I'll put you on Responsible for this project in the tasks page ... Sure. (Gee, I walked right in to that one, didn't I!?) Fine. Any hint how to link to the Ububtu package? There's no ubuntu package (there may be unofficial ones floating around but they are extremely unlikely to be acceptable to debian due to the problems I previously described). The program is just mentioned on the Ubuntu wiki as being a useful program. So this list on the Ubuntu website is just another list of scientific software without any substancial profit for the user? Hmmm, didn't I expressed my feeling that this page is not impressing me much? Google will uncover lots of such kind of lists and you will run crazy if you try to compare these whether they are up to date or not. Our tasks list is related to ready to install software with a single click or at least gives some status what has to be done to move a project to this status. IMHO that's at least two degrees better, sorry. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] New task: science-dataacquisition
Andreas Tille [EMAIL PROTECTED] writes: On Tue, 9 Dec 2008, Chris Walker wrote: Libcv1 - a computer vision library What do you want to tell me by this? This is for image analysis - and so should probably go alongside Gpiv - in an image acquisition/analysis metapackage. OK, one dependency for imageanalysis. Any more? # Particle image velocitometry (move these from data acquisition) gpiv, gpiv-tools Add # Scanning Probe Microscopy (SPM) data visualization and analysis. gwyddion There is also a strong argument for # Graph Digitization (extracting data from published graphs available as bitmaps) engauge-digitizer g3data Chris Nb all of these are based on package descriptions, not personal knowledge. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] New task: science-dataacquisition
Le Wed, Dec 10, 2008 at 01:50:13PM -0800, Jordan Mantha a écrit : [1] https://help.ubuntu.com/community/UbuntuScience Hi Jordan, the list is actually quite outdated: for instance EMBOSS is distributed in Ubuntu :) It seems that we all face the same problem of not having enough manpower. Another example is the MOTU Science mailing list that is not very active and worse, does not moderate messages from outside people (me for instance). https://lists.ubuntu.com/archives/ubuntu-motu-science/ How can we get a better yield for our efforts? I agree with Andreas that multiple similar wiki lists can sink a lot of time. I actually talk with experience: wiki.debian.org also contains long lists of prospective packages that I do not update anymore. http://wiki.debian.org/DebianScience/Biology Do you think that we can find synergies on common goals? Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] New task: science-dataacquisition
Andreas Tille [EMAIL PROTECTED] writes: On Tue, 9 Dec 2008, Chris Walker wrote: [snip] Sure. I think the Wiki is a perfect tool for the *initial* work to find a reasonable set - especially if you are no specialist. That's why I'm in favour of starting with a Wiki and move this work to tasks files after a two to three monthes period. Agreed completely - and that's roughly what I was hoping - initial categorisation is done on the wiki then it transfers to the tasks. [snip lots of stuff I agree with] You also seem to underestimate the profit we gain by having always the full package description on the tasks pages - and we do provide even up to date translations. It is not only the versioning information and homepage. I particularly agree with this. What the wiki can do, and the tasks can't do (at least not yet) is have sections and subsubsections and potentially some explanatory text. This allows you to group packages that perform similar tasks near each other - which makes it easier to ignore packages you aren't interested in. If you use metapackages, you end up having information spread across several pages - which just makes it harder to find. [snip] I agree that categorising (=subsections) is a good thing in principle - but you always have to keep in mind what purpose or categorisation should serve: We want to give our users quick access to the packages that might be interesting for them. We will fail to do so if we a) Force the user to understand a complicated categorisation system (chances are really high that a random user will have a different categorisation in mind than we have). b) Hide programs in a deep categorisation tree. This is not better than the flat non-categorised package pool. That's why I'm not in favour of layers of metapackages but have only a single layer. Absolutely, I couldn't agree more. The fact that until now nobody has sended me a patch to blends-dev in my eyes is a prove that there is nobody out there who regards a deeper structure in metapackages as important enough to spend some time on it. I've not yes found the time to do this - but one of these days... Before we had metapackages and tasks pages people were forced to browse the whole package pool for descriptions - and they probably failed to do so (6 monthes ago I was seeking for a digitiser like engauge-digitizer and g3data - but failed to find it). AOL (well actually 12 months in my case, but...) Now we have metapackages and you have to browse a list of order 10 (compared to a list of order 1 in the flat package pool). That's an enhancement of three orders of magnitude. Now you are asking to stretch the concept farther? I'd call this overkill. If people are not willing to read the really shortened list (while perhaps learning about some other packages they might be interested in) IMHO they do not deserve our work. And so they do not really deserve your manual Wiki editing. In an ideal world, I think we should be able to generate something like https://help.ubuntu.com/community/UbuntuScience#Physics automatically - with an option of long description or short description (to make it easier to scan down the entire list)[4]. Well, I admit I'm not really impressed by the URL above. IMHO what we provide on the tasks pages is better. If you want to generate a shortened List with only short descriptions - well, that's cheap. Could be a simple wishlist bug (the webtools are not (yet) in BTS, but I can put this on my todo list). Pretty please. It would be simple to create a page per Blend which lists all the short descriptions with homepage links and #task anchors. If it is this what you want to convince you to start on working on physics tasks files - it would not cost me much work to convince you. ;-)) That is halfway towards convincing me. If you did that, and also provided a means of having subsections - by not sorting the packages at all (currently they are alphabetical), and having the ability to put in subheadings - not sure of an appropriate syntax, but something along the lines of: #heading Condensed matter # subheading Diffraction # Comment Analysis and model fitting of X-ray diffraction data. Synchrotron users please note that ... I'd definitely be convinced[1]. [snip] And now back to the statement: Keeping the Wiki up to date is so easys. Please do not tell me that working on the dataacquisition tasks page was not easy. People have thrown in mails with suggestions and the things have shown up. Well - it was some work for me but not much and user input was possible as well. We have also a certain amount of people who have access to the tasks files in svn - so the barrier is not very high. Maintaining the tasks files is keeping the minimum information on one central place to gain as much profit from it automatically. Indeed. As a prototype, the
Re: [RFC] New task: science-dataacquisition
Charles Plessy wrote: Le Wed, Dec 10, 2008 at 01:50:13PM -0800, Jordan Mantha a écrit : [1] https://help.ubuntu.com/community/UbuntuScience Hi Jordan, the list is actually quite outdated: for instance EMBOSS is distributed in Ubuntu :) It seems that we all face the same problem of not having enough manpower. Another example is the MOTU Science mailing list that is not very active and worse, does not moderate messages from outside people (me for instance). https://lists.ubuntu.com/archives/ubuntu-motu-science/ Agreed, I find that in particular very irritating. How are we to communicate information about our packages to Ubuntu science folk? It's not at all clear where to email such info other than said mailing list, but I also have never been able to get my emails to the list. Could they at least whitelist the emails of maintainers of the relevant Debian packages? -- Kevin B. McCarty [EMAIL PROTECTED] WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] New task: science-dataacquisition
On Wed, 10 Dec 2008, Kevin B. McCarty wrote: Agreed, I find that in particular very irritating. How are we to communicate information about our packages to Ubuntu science folk? It's not at all clear where to email such info other than said mailing list, but I also have never been able to get my emails to the list. Could they at least whitelist the emails of maintainers of the relevant Debian packages? If you ask me the situation would be very simple: If Ubuntu derives from Debian I would care for pushing all interesting software straight to Debian and later derive with (hopefully) automatical tools. (I do not know Ubuntu enough whether this is really done (semi)automatically.) There is at least one positive example (namely Morten Kjeldgaard) who is actually following this principle. The logical consequence in my opinion would be to have this debian-science list as common discussion list for packaging scientific software. Well, I'm aware that statements like this might push me into the Ubuntu unfriendly Debian maintainer corner. I can stand with this because I know this is not the case. I just prefer to tackle problems at the source which in this case is Debian. IMHO it would save a lot of time if we would join forces here. So please save your time and do not tell me what a great job Ubuntu Science people are doing. I do not doubt this - I just say it can be done more efficiently together. Kind regards Andreas. PS: Please note that I do not answer any mail that tries to turn this into a Debian Ububtu flamewar. My intent is the contrary of a flamewar and thus I will not stupidly heat the flames. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] New task: science-dataacquisition
On Tue, 8 Dec 2008, Chris Walker wrote: Depends: g3data Done in SVN. Other packages - yes, Steffen Moeller's suggestion of qtdmm sounds appropriate. Done in SVN. On the physics wiki page, I list libgpib (boris) Suggests: libgpib-bin libcomedi (boris) Depends: ktimetrace and link to G. Varoquaux has written an interesting article describing the use of python and pyvisa for experimental control. Agile computer control of a complex experiment. Computing in Science and Engineering 10(2), 55 (2008). and Writing a graphical application for scientific programming using TraitsUI pyvisa isn't a debian package. Done as prospective package. There are also unofficial debs of TANGO - again linked to from the physics wiki. Unfortunately, there is an ITP for another completely unrelated package called tango recently announced on debian-devel. Done as prospective package. Any volunteer to sponsor this package? And yes, I have seen the tango ITP - but I do not really remember whether somebody stepped in here and discussed the possible name clash. Please anybody interested in tango should do so ... http://mx.iit.edu/ MX - A Data Acquisition and Control System. Is not packaged. Done as prospective package. http://www.aps.anl.gov/epics/ Experimental Physics and Industrial Control System is used in some particle accelerators, telescopes and other large scientific experments. Done as prospective package. Depends: gnudatalanguage It isn't clear to me why you think this should be under data acquisition - any more than octave,matplotlib,pdl,scilab,freemat - listed in the Numerical Computation (MATLAB/IDL like) section of the physics wiki page[1]. Well, there is no really strong opinion on my side. I turned the Depends into Suggests. Feel free to either remove it completely or add the other ones as well - depending what you feel reasonable for people who want to prepare a computer for data acquisition tasks. You might make an argument that * gpiv gpivtools A collection of programs for images that are generated during a Particle Image Velocimetry (PIV) experiment. This is a technique to obtain the velocity field of a fluid flow quantitatively and is performed by tracking tracer particles that have been seeded to a fluid. would be a good candidate - I'm not sure. I added this as Suggests. If the task gets big enough, then I think that this along with g3data and engauge-digitizer should be split into an Extracting data from images task. I'm no fan of to many tasks. The robotics task has Libcv1 - a computer vision library What do you want to tell me by this? The result can be viewed at http://cdd.alioth.debian.org/science/tasks/dataacquisition.html [1] http://wiki.debian.org/DebianScience/Physics Interesting page. Do you want to save some time while generating nicer and more feature rich output? If yes you should tell me that you volunteer to maintain svn://svn.debian.org/svn/cdd/projects/physics/trunk/debian-physics after I gave you a kick-start by turning the entries from your wiki into tasks files (which I could probably do until Sunday). The immediate effect would be to have finer grained tasks pages for physics packages (including translations for those packages where DDTP has translations), bugs pages and hopefully soon an overview about watch status. The long term effect would be that there might evolved a grown up Debian Physics Blend. Your Wiki can be considered as the first step - IMHO it is time to do the next. Regarding the time saving aspect: The dataacquisition page took me about 15 minutes (the green entries only one minute, the othes costs some research on upstream websites). Do you think the Wiki can compete with this? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] New task: science-dataacquisition
On Tue, 9 Dec 2008, Gerber van der Graaf wrote: A whole area of science that depend on image analyses (from microscopic to astronomics) might like to include different programs to control cameras. Some ideas: In general I like the idea to give the whole bunch of image acquistion programs some structure and give some guidelines which might be relevant for scientific purposes. But IMHO this would stretch the scope of dataacquisition to large and I would prefer a separate imageacqusition task. Well, I know images are data as well, but I think a split between numeric data and image data makes perfectly sense from a user point of view. So I'm open for suggestions if anybody wants to provide reasonable dependencies for a potential imageacqusition task. Firewire/IEEE1394 kernel modules, libraries and the coriander program. Though I have the impression that this interface is currently under transition and not working properly with the Linux kernel currently included in Debian/Unstable: http://ieee1394.wiki.kernel.org/index.php/Juju_Migration Anyhow the Firewire interface (and coriander) support many cameras. Video4Linux: an apt-get search gave me a whole bunch of libraries and applications, partly overlapping Firewire. Maybe only a part of it will be sufficient. Yes. We should probably put some barrier here to suggest only those packages that are really useful for scientific research. Probably there is more for acquiring images from cameras available on GNU/Debian, but I think this will cover the most important ones. That's the whole point of the Blends effort: Detect and suggest reasonable packages out of the flat and unstructured pool for a certain user group. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] New task: science-dataacquisition
Andreas Tille [EMAIL PROTECTED] writes: On Tue, 8 Dec 2008, Chris Walker wrote: There are also unofficial debs of TANGO - again linked to from the physics wiki. Unfortunately, there is an ITP for another completely unrelated package called tango recently announced on debian-devel. Done as prospective package. Any volunteer to sponsor this package? And yes, I have seen the tango ITP - but I do not really remember whether somebody stepped in here and discussed the possible name clash. Please anybody interested in tango should do so ... I have mentioned the name clash on debian-devel, but perhaps not forcefully enough. http://mx.iit.edu/ MX - A Data Acquisition and Control System. Is not packaged. Done as prospective package. http://www.aps.anl.gov/epics/ Experimental Physics and Industrial Control System is used in some particle accelerators, telescopes and other large scientific experments. Done as prospective package. Depends: gnudatalanguage It isn't clear to me why you think this should be under data acquisition - any more than octave,matplotlib,pdl,scilab,freemat - listed in the Numerical Computation (MATLAB/IDL like) section of the physics wiki page[1]. I am, I think, changing my view on this towards include them all. I do know that Matlab includes a data acquisition toolkit for example. The scilab web page mentions a scilab-labview gateway - and GPIB toolbox amongst others. Well, there is no really strong opinion on my side. I turned the Depends into Suggests. Feel free to either remove it completely or add the other ones as well - depending what you feel reasonable for people who want to prepare a computer for data acquisition tasks. The fundamental question is, would you use it for writing a data acquisition system, or is it just for analysing data offline (this is a question, I really don't know). If the former, it should be included, if the latter, it should not. Given what I've written above, I suspect it would be useful and therefore should be included. Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] New task: science-dataacquisition
A whole area of science that depend on image analyses (from microscopic to astronomics) might like to include different programs to control cameras. Some ideas: Firewire/IEEE1394 kernel modules, libraries and the coriander program. Though I have the impression that this interface is currently under transition and not working properly with the Linux kernel currently included in Debian/Unstable: http://ieee1394.wiki.kernel.org/index.php/Juju_Migration Anyhow the Firewire interface (and coriander) support many cameras. Video4Linux: an apt-get search gave me a whole bunch of libraries and applications, partly overlapping Firewire. Maybe only a part of it will be sufficient. Probably there is more for acquiring images from cameras available on GNU/Debian, but I think this will cover the most important ones. Gerber On Tue, 2008-12-09 at 09:51 +0100, Andreas Tille wrote: On Tue, 9 Dec 2008, Gerber van der Graaf wrote: I think the comedi-source package will fit nicely here as well. Another idea is to include librtai-dev librtai1, rtai, rtai-doc and rtai-sourc. I used them for sending trigger signals to a laser and camera in my software. $ svn diff Index: dataacquisition === --- dataacquisition (Revision 1273) +++ dataacquisition (Arbeitskopie) @@ -18,6 +18,10 @@ Suggests: gpivtools, gpiv +Suggests: comedi-source + +Suggests: rtai + Depends: python-visa Homepage: http://pyvisa.sourceforge.net/ License: MIT Feel free to suggest higher dependency level or adding more binary packages (I just decided for the rtai metapackage). Thanks for the hint Andreas. PS: Tasks pages (as well as bugs pages) will be auto-generated later to reflect these changes. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] New task: science-dataacquisition
Andreas Tille [EMAIL PROTECTED] writes: On Tue, 9 Dec 2008, Gerber van der Graaf wrote: A whole area of science that depend on image analyses (from microscopic to astronomics) might like to include different programs to control cameras. Some ideas: In general I like the idea to give the whole bunch of image acquistion programs some structure and give some guidelines which might be relevant for scientific purposes. But IMHO this would stretch the scope of dataacquisition to large and I would prefer a separate imageacqusition task. Well, I know images are data as well, but I think a split between numeric data and image data makes perfectly sense from a user point of view. There might be some merit in an ImageAnalysis task as well (or perhaps instead). So I'm open for suggestions if anybody wants to provide reasonable dependencies for a potential imageacqusition task. Firewire/IEEE1394 kernel modules, libraries and the coriander program. Though I have the impression that this interface is currently under transition and not working properly with the Linux kernel currently included in Debian/Unstable: http://ieee1394.wiki.kernel.org/index.php/Juju_Migration Anyhow the Firewire interface (and coriander) support many cameras. Video4Linux: an apt-get search gave me a whole bunch of libraries and applications, partly overlapping Firewire. Maybe only a part of it will be sufficient. Yes, I've recently tried and failed to get a webcam working. Yes. We should probably put some barrier here to suggest only those packages that are really useful for scientific research. Completely agree. Groups other than scientists will have these problems too - in fact surely there must be some other group in Debian dealing with video cameras/webcams? Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] New task: science-dataacquisition
Andreas Tille [EMAIL PROTECTED] writes: On Tue, 8 Dec 2008, Chris Walker wrote: The robotics task has Libcv1 - a computer vision library What do you want to tell me by this? This is for image analysis - and so should probably go alongside Gpiv - in an image acquisition/analysis metapackage. gpsd - GPS (Global Positioning System) daemon might be a candidate for the data acquisition metapackage. Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] New task: science-dataacquisition
Hi all, Re: https://help.ubuntu.com/community/UbuntuScience [3] The Ubuntu list also mentions a third package in that category - Plot Digitizer - A Java program used to digitize scanned plots of functional data. I don't think it is packaged for Debian, and don't know how it compares with the other two. I use PlotDigitizer whenever I need such a tool and find it to be really good. The point and click axis alignment and plot selection is easy to use and on plots with lots of data, the autotrace facility works nicely (you just draw a broad line over where the data is approximately found and the autotrace library does the rest). I talked to the upstream of PlotDigitizer some time ago about integrating it better on linux machines (I vaguely recall that the upstream developer is a MacOS X user). He was very responsive in dealing with problems that I found and liked the idea of being packaged and used more widely. The last time I looked at it, however, it had all the usual problems of the java ecosystem (e.g. internal copies of libraries in the source download) and the prospect of packaging that was a little daunting. There were also problems with libraries that had been relicenced from GPL to GPL-incompatible and PlotDigitizer upstream wasn't sure what to do about that. Given that there have been no releases in 3 years, I think that probably tells us what he decided. Packaging PlotDigitizer has stayed on my todo list, however, and I may yet have a look at it. That said, there may be less fraught alternatives already in the archive. cheers Stuart -- Stuart Prescott www.nanoNANOnano.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] New task: science-dataacquisition
Hi Andreas: On Tue, 9 Dec 2008, Andreas Tille wrote: On Mon, 8 Dec 2008, Carlo Segre wrote: I can put this on the wiki if people think it is a good idea. I'd rather regard it as a good idea to turn it into an official package. I sneeked through the diff.gz and have just detected you as Uploader. So why do you hesitate to upload? Primarily because the documentation is not complete and there are a couple of final issues in the packaging that need to straightened out. The documentation will take a long time so it should probably not be a stumbling block but I do want to fix the final packaging issues. Carlo -- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498Fax: 312.567.3494 [EMAIL PROTECTED] http://www.iit.edu/~segre [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] New task: science-dataacquisition
Andreas Tille wrote: Any comments? Any suggestion for further dependencies? qtdmm would be a nice fit. Best, Steffen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] New task: science-dataacquisition
On Mon, 8 Dec 2008, Chris Walker wrote: http://www.aps.anl.gov/epics/ Experimental Physics and Industrial Control System is used in some particle accelerators, telescopes and other large scientific experments. We also have an unofficial package of the EPICS client libraries (not the servers, sorry) at http://debian-xray.iit.edu carlo -- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498Fax: 312.567.3494 [EMAIL PROTECTED] http://www.iit.edu/~segre [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
