Re: Quick Poll: Debian to better support hardware acceleration?
Hi, "M. Zhou" writes: > Q: How far should Debian go along the way for supporting hardware > acceleration solutions like CUDA? I think Debian is already doing a good job with CUDA, at least as it pertains to my work with Python+GPU. My thanks and please keep it up! One recent example for me is installing "cupy" from PyPI via pip. On Debian testing/sid it Just Works(tm)! On Ubuntu 18.04 it caused me to enter "CUDA install hell". The CUDA version provided by the OS is apparently not supported by "cupy" on PyPI. My attempts to build cupy from source against Ubuntu CUDA or to install more recent CUDA from non-Ubuntu to satisfy PyPI's cupy both were utter failures. For this and other reasons, my solution is actually to migrate my Ubuntu 18.04 systems to Debian. BTW, there is a HN thread formed this morning on Python/GPU things that may be usefully related here: https://news.ycombinator.com/item?id=27205586 https://discuss.python.org/t/what-to-do-about-gpus-and-the-built-distributions-that-support-them/7125 -Brett. signature.asc Description: PGP signature
Re: future of root-system: removal?
Mattia Rizzolo writes: > I haven't. Please (feel free to) do it, keeping in mind that I still > plan to remove it before the end of the month. I sent a message[1] to roottalk. -Brett. [1] https://groups.cern.ch/group/roottalk/Lists/Archive/Flat.aspx?RootFolder=%2Fgroup%2Froottalk%2FLists%2FArchive%2FROOT%20packages%20in%20Debian%20need%20a%20maintainer&FolderCTID=0x01200200A201AF59FD011C4E9284C43BF0CDA2A4 signature.asc Description: PGP signature
Re: root-system update
Hi Mattia, Mattia Rizzolo writes: > I noticed that root-system is keeping a lot of other packages out of > testing because it's currently broken. > > That's bad! :) I give you huge encouragements to tackle this! > I want to have a stab updating it, but before I'd like to know whether > somebody knows something I should know before proceeding, peculiarities > I should be aware of, etc. Here are a few things maybe worth considering: As you may know, ROOT has had a major version update from 5 to 6. Various versions in 5.xx are still used a lot in the community but upstream development of 5, other than bug fixes, has stopped. Version 6 is largely backwards compatible with 5 and brings many nice new features. Experiments/users that rely on having some specific version already build their own copy from source so I think the target audience for Debian packages would benefit from having ROOT6 packages more than ROOT5 ones. So, I guess the first big decision is to package just v5, just v6 or both. Maybe getting v5 "unstuck" would be a first step, but I suspect v5 will become less and less desired by users compared to v6. One new thing that may affect packaging v6 is the replacement of CINT with Cling for the ROOT C++ interpreter. This brings a new dependency on LLVM. Like many major dependencies of ROOT, ROOT provides a copy of the source for LLVM in case it is not provided by the system. I think Debian packages for ROOT6 should ignore this and build against Debian's LLVM packages. So far I have just stuck to plain CMake builds of ROOT6 but I see that the Debian (and rpm) package building scripts originally from Christian are still in place in the upstream source. > Then, it's kinda of big package, and if somebody want to join the effort > (by, e.g. reviewing/fixing what I did) I'd glad to have it :) My Debian packaging skills are rusty to the point of being nonexistent but I can test package builds, binaries or maybe in some other way help out with this effort. -Brett. signature.asc Description: PGP signature
Re: Proposal: Debian Science mailing lists
Andreas Tille writes: > While I *personally* do not have a problem with the current situation I > agree with Sylvestre that currently debian-science@l.d.o is not kind of > missing link between developers and users. Because I think we should > establish such a place and this list seems to be a good candidate it > might be reasonable to move pure packaging related questions to the > Alioth list. > > However, I do not see a practical way to force this policy on list members. > So writing it explicitely down in the Debian Science policy document and > kindly directing people to the other list might be a good idea but there > is no way to forbid packaging questions here. Hopefully not muddying the waters, but a new "debian-science-users" list could be created and "debian-science" left for package concerns (or package/user overlap?). The new list would have the advantage of being explicitly user-centric in name. It would also be a fresh place to intice back any users that may have left this list due to the increased focus on packaging. The downsides are having yet-another-list, and that purely user-oriented folks that are still here would need to move. 2c, -Brett. pgpIsCzDj2rhD.pgp Description: PGP signature
Re: Proposal: Debian Science mailing lists
Sylvestre Ledru writes: > == Proposal == > > I would like to propose the following: > * move all packaging related discussions to > debian-science-maintain...@lists.alioth.debian.org > * use debian-science@lists.debian.org only for user oriented discussions > * make sure that all the commit mails are sent on > debian-science-maintainers-comm...@lists.alioth.debian.org > > Any comments / opinions ? FWIW, your proposal is more in line with what I thought debian-science was about when I joined. I haven't, personally, minded seeing packaging related discussions go by but I do think the two types of discussions would benefit from having their own venues. -Brett. pgptaV6Gp52gS.pgp Description: PGP signature
Re: Scientific software packaging
Lifeng Sun writes: > I am packaging LHAPDF and ROOT, and would try to upload them in three > or four weeks. Gürkan, fyi, you can also see recent postings on the root-talk mailing list for some unofficial ROOT packages. And, ROOT comes with Debian build files so you can make your own. -Brett. pgpZi0LAgigru.pgp Description: PGP signature
Re: Removal of QCAD
Thomas Weber writes: > Speaking as an occasional user: please provide a transitional package. FWIW, I echo this desire. I've transitioned from qcad to librecad and confirm it is an improvement as well as a successor. The change in name may fool someone into passing over librecad so having the transitional package would be useful. Thanks, -Brett. PS: is it just me who always reads it as "lib-recad" rather than "libre-cad"? pgpjmTLO4wjFC.pgp Description: PGP signature
Re: Debian and Scientific Linux
Stephen Liu writes: > I ran Debian, RH, Fedora, CenOS, Ubuntu, FreeBSD, etc. before and am > still running some of them. What is the major difference of SL from > other Linux distro? Thanks In your list, SL is closest to CentOS. SL is a rebuild from RHEL sources with RH branding taken out. Nothing more nor less. As an example, in recent discussion it came up that SL will be left unaffected by RH's recent decision to obfusticate Linux source code as they do no kernel patching. There is also SLF (FNAL) and SLC (CERN) where each lab adds some packages on top of the base SL for internal consumption. From what I have seen these add-ons are largely configuration and Kerberos related. -Brett. pgpJ0Dw4NFI3T.pgp Description: PGP signature
Re: Reproducibility
Teemu Ikonen writes: > Does anyone here have good ideas on how to ensure reproducibility in > the long term? Regression testing, as mentioned, or running some fixed analysis and statistically comparing the results to past runs. We worry about reproducibility in my field of particle physics. We run on many different Linux and Mac platforms and strive for statistical consistency (see below) not identical consistency. I don't recall there ever being an issue with different versions of, say, Debian system libraries. Any inconsistencies we have found have been due to version shear in different copies of our own codes. [Aside: I have seen gross differences between Debian and RH-derived platforms. In a past experiment I was the only collaborator working on Debian and almost everyone else was using Scientific Linux (RHEL derivative). I kept getting bit by our code crashing on me. It seems, for some reason, my compilations tended to put garbage in uninitialized pointers where on SL they tended to get NULL. So, I was the lucky one to find and fix a lot of programming mistakes. This could have just been a fluke, I have no explanation for it.] > The only thing that comes to my mind is to run all > important calculations in a virtual machine image which is then signed > and stored in case the results need verification. But, maybe there are > other options? We have found that running the exact same code and same Debian OS on differing CPUs will lead to differing results. They differ because IEEE FP "standard" isn't implemented exactly the same on all CPUs. The results will differ in only the least significant digits. But, if you use simulations that consume random numbers and compare them against FP values this can lead to more gross divergences. However, with a large enough sample the results are all statistically consistent. I don't know how that translates when using virtual machines on different host CPUs, but if you care about bit-for-bit identically, this FP "standard" may percolate up through the VM and ruin that. Anyways, in the end, all CPUs give the "wrong" results since FP calculations are not infinitely precise, so striving for bit-for-bit consistency is kind of a pipe dream. -Brett. smime.p7s Description: S/MIME cryptographic signature
Re: Retiring from Debian
"Kevin B. McCarty" writes: > With best wishes to the project, My thanks go out for your good work. Having Geant4 in Debian packages is very useful. -Brett. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Why I'm here (Was: Debian Science Policy)
Manuel Prinz writes: > Debian-science@ has mainly been a user list and there was discussion > about moving maintaining-related issues to a different list to not > bother users on debian-science. Most of the subscribers there seem to > have no or very few interest in packaging. (Unfortunately, I do not have > numbers on that. But take Paul's reply as an example.) To give a second data point, besides sharing Paul's motivation, I'm here to try to help Debian's standing[1] in the world of Science, and in particular, Particle Physics. I can't offer enough time to become a DD so I try help in whatever other small ways I can. Cheers, -Brett. [1] A purely selfish motivation! -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: What would you like to see in a book about Matplotlib?
Chris Walker writes: > Does > > ipython -pylab > > do what you want? Yes! Thanks. -Brett. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: What would you like to see in a book about Matplotlib?
Sandro Tosi writes: > I received the interesting proposal to author a book on Matplotlib, > the powerful 2D plotting library for Python. Cool. > While preparing the arguments list, I'd like to hear even your > opinion, because different points-of-view will lead to a better > product. > > Some basic question I'd like to ask are: I've just started using it this past week so I can't give you much useful input. So far, I've only used is through the pyplot module so my few comments are on that part. > - what are you using matplotlib for? Currently, debugging simple numerical models of beta decay spectra. > - what are the things you like the most of matplotlib, that you want > to give emphasis to? And why? I've used it only to make very simple plots, but I appreciate that doing simple things is incredibly simple. > - what are the (basic) things that, when you were beginning to use > matplotlib, you wanted to see grouped up but couldn't find? One feature that I would appreciate knowing about, if it is supported, is how to show() a plot but not loose the ipython prompt. This is something that ROOT (and PyROOT) supports and it makes it much easier to play with plots interactively. > - what would you like to see in a book about matplotlib? Lots of examples. What I found it useful with matplotlib.sf.net's pyplot tutorial is I can scan it for a plot that looks close to what I want and then see the code I need to use. Having a full "index" that maps a plot features to the required code would be useful way to present things. > :) And wish me good luck! Good luck! -Brett. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Yet another list statistics for debian-science
Andreas Tille writes: > I did some investigation on who is frequently posting > on our mailing lists. Here are we: http://people.debian.org/~tille/liststats/authorstat_science.pdf It is interesting work. If you want suggestions, it would be nice to know the total number of posts per year (excluding spam, if possible). As is, an apparent "slow year" is ambiguous. It may be due to actually more conversation by more diverse contributors taking the load off the primaries. Or, due to simply less conversation across the board. Although, one thing is clear, 2008 was the "Year Of Andreas" in this group! Cheers, -Brett. -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Reading "ArcGrid" formated geological data on Debian? Alternatives?
Hi Nik and Stuart. Thanks, these are both great pointers! -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Reading "ArcGrid" formated geological data on Debian? Alternatives?
Any geographers in the house? I need an elevation map for a particular region (China mainland near Hong Kong) and I found that the US Geological Survey supplies some data from the "Shuttle Radar Topography Mission". However, for the region of interest it is only available in a proprietary format called "ArcGrid" aka "ESRI Shapefile". I'm pretty ignorant of this field and am hoping there are experts here that can suggest any Free Software and/or Debian packages I'm missing that will allow unpacking this format into an accessible form I can use in my own software. I found the Debian package "gdal-bin" but the best I can figure out is it only allows unpacking summary information (via gdalinfo). So, any suggestions on software? Or, maybe there is another source of high resolution (100m or better) topographic data I should look at? Thanks! -Brett. PS: If it helps, the data pack I downloaded from USGS is here: http://www.phy.bnl.gov/~bviren/dayabay/elevation/84605319.zip -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Whither CERNLIB (, Paw, Geant3.21) in Debian? RFA / future plans
Hi Kevin, "Kevin B. McCarty" <[EMAIL PROTECTED]> writes: > I'm seeking one or more people to take over maintenance of the following > FORTRAN- and physics-related source packages. > > cfortran > cernlib > paw > geant321 > mclibs Definitely not me, but I do want to thank you for providing the Debian HEP community (or at least, me) with these packages all these years. Best regards, -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Optical Ray-tracing software - not like povray!
Hi Niel, Neil Pilgrim <[EMAIL PROTECTED]> writes: > David Fokkema wrote: > >> So, basically, he's teaching ray tracing in the sense of: >> http://en.wikipedia.org/wiki/Lens_%28optics%29 > > Yes, this is what I was meaning - and yes, you can see how its > difficult to explain what we need! You might consider looking at xeukleides (Debian package of the same name). It is a simple, general 2D geometry program. While not designed for it, you can use it for playing with optics. However, you will have to put in the correct optical formulae into the scripts by hand as it doesn't inherently "know" about refraction and reflection. I've attached 4 examples I made some time ago. They all play with reflection, not refraction, but maybe they will give you some idea of what is possible. To run each, do: 1) run: xeukleides file.euk 2) hit ESC to go from edit to display 3) use arrow keys to change input parameters HTH, -Brett. focus.euk.tgz Description: Some xeukleides examples.
Re: Simple graphical software for manually plotting fractals?
"Jordi Gutiérrez Hermoso" <[EMAIL PROTECTED]> writes: > On 15/10/2007, Brett Viren <[EMAIL PROTECTED]> wrote: >> "Jordi Gutiérrez Hermoso" <[EMAIL PROTECTED]> writes: >> >> > Suggestions? >> >> "NETPBM" (libnetpbm10-dev). This is C library which povides a very >> simple interface for manipulating bitmapped images at the pixel level. >> It treats the bitmaps as 2d arrays in memory and will let you output >> to many file formats including PNG. > > And for plotting to an X window? Yes, netbpm will be "batch mode" only, afaik. Your students would have to rely on an external image viewer. It has been too long but I think plotutils can write live to an X-window. I used it for doing vector based drawing so don't know how well, or even if, it supports bitmapped work. Maybe someone else can comment. Beyond that, I can only suggest low level toolkit stuff (eg, gtk+/gtkmm) but this gets your students too far away from doing the fun stuff, I guess. -Brett.
Re: Simple graphical software for manually plotting fractals?
"Jordi Gutiérrez Hermoso" <[EMAIL PROTECTED]> writes: > Suggestions? "NETPBM" (libnetpbm10-dev). This is C library which povides a very simple interface for manipulating bitmapped images at the pixel level. It treats the bitmaps as 2d arrays in memory and will let you output to many file formats including PNG. You might also look into "plotutils" (libplot-dev). -Brett.
Re: ROOT in Debian "experimental"
Christian Holm Christensen <[EMAIL PROTECTED]> writes: > This makes ROOT the first major Linux distribution that ships ROOT as > part of it's package list - beating even Scientific Linux. "This makes *DEBIAN* the first major Linux distribution that ships ROOT as part of it's package list - beating even Scientific Linux." Sorry, I couldn't let that important typo slide! Christian, I hope I speak for all Debian and ROOT users in saying thanks for your efforts in getting here. I also want thank the entire ROOT team for formally relicensing ROOT as Free Software. With out that effort, there would not have been any hope to get these packages accepted into Debian. Cheers, -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
eukleides orphaned
I just saw on Debian Weekly News eukleides has been orphaned: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419083 This is a great little 2D geometry calculator. If anyone is looking to pick up a package, I encourage them to consider this one. Cheers, -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Distributed filesystems in Debian
A short report since some expressed interest in getting any updates: I checked into the docs for Oracle's OCSF2 starting here http://oss.oracle.com/projects/ocfs2/ Its userland is included in recent Debian and kernel modules in recent versions of Linux. It looks fairly straight-forward to set up but a few things make me shy: - I seems geared to low numbers of clients (<10). The number must be preset (although can be increased later). - It does not seem to allow for a single image to span multiple servers or even multiple partitions (yes, LVM solves that second one). - Although it isn't high on my list, it also seem to provide no redundancy. Except for what is probably better handling of downed servers, I don't see much benefit beyond just using NFS. So, I'm still shopping. -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Distributed filesystems in Debian
Hi Sylvestre, Sylvestre Ledru <[EMAIL PROTECTED]> writes: > It won't probably answer to all your requirements but I heard good > experience about DRBD : > http://www.drbd.org/ Thanks. This was suggested to me by another person and it does look like a useful tool for a high avilability filesystems. But, for my own application we can accept the risk of loosing a part of our data in order to enjoy access to all (or close to all) possible disk space. Cheers, -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Distributed filesystems in Debian
Alastair McKinstry <[EMAIL PROTECTED]> writes: > As for making the coffee, patches are welcome :-) I have some, but they are written in Java. Groan, sorry, couldn't resist Thanks for the info. -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Distributed filesystems in Debian
About a month ago the issue of distributed filesystems in Debian was raised here. Since then, has anyone had any experiences, good or bad? Personally, I am looking for a good way to serve 16 disks (8TB), split into two nodes to a cluster of 18 nodes. My requirements (or maybe better "desires") are: - present a single, monolithic as possible large filesystem - enough redundancy so one dead disk doesn't kill the whole filesystem's files - RAID0 like parallelism to avoid bottlenecks - Free Software (Debian packages best), simple install and maintenance. - Good match to my cluster size (10s of nodes), additional hardware not required. - Makes my morning coffee for me. Currently I'm leaning towards using Lustre, but I worry it may not be a good fit to the small size of my cluster. I'd also enjoy hearing about the applicability of PVFS2 and Red Hat's GFS. -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: alternatives to openmosix on amd64
Egon Willighagen <[EMAIL PROTECTED]> writes: > On Wednesday 07 March 2007 19:12:09 Sylvestre Ledru wrote: >> Kerrighed might be an answer : >> http://www.kerrighed.org/ > > Very interesting... Indeed, however: Current Status The actual implementation of Kerrighed is based on Linux 2.4.29 kernel. A port to kernel 2.6.11 is ongoing. Kerrighed functionalities have been added to the Linux kernel through modules and some minor kernel modifications. So, similar boat as openmosix for working with 2.6. Googling turned up this: http://www.irisa.fr/paris/Biblio/Papers/Lottiaux/LotBoiGalValMor05CCGrid.pdf Which lead to a 3rd option: http://openssi.org/ It would be nice to hear of any experience with these. -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: science soft mirror
slimane ben miled <[EMAIL PROTECTED]> writes: > I am using ubuntu 6.06, I would like to know if there is a mirror for > scientific (maths +biology+bioinformatics) softs There are many scientific software packages in Debian, proper. http://packages.debian.org/stable/math/ http://packages.debian.org/stable/science/ But, being this is Debian and not Ubuntu, I do not know how well they will work on your system. -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: drawing of network: in search of a tool
Dirk Van Hertem <[EMAIL PROTECTED]> writes: > * nodes on specific coordinates > * make connections between them according to the connections in my network > * put a number and arrow next to the connections indicating the power flow > * put a number next to every node (for voltages) > * preferably a vector format output for I don't know what control it gives you to specify explicit coordinates but GraphViz (available as a Debian package) is a venerable and useful graph visualizer which will satisfy your other requirements. You may have to put in some effort to massage your data into a proper input format. Luck, -Brett. apt-cache search graphviz libgraphviz-perl - Perl interface to the GraphViz graphing tool deps-tools-cli - DEPS command-line tools libdeps-renderer-dot-perl - DEPS renderer plugin using GraphViz/dot monotone-viz - visualize a monotone repository python-pydot - Python interface to Graphviz's dot sig2dot - converts a list of GPG signatures to a .dot file springgraph - creates a graph from a .dot file (neato alternative) visitors - A fast web server log analyzer dot2tex - Graphviz to LaTeX converter graphviz - rich set of graph drawing tools graphviz-dev - graphviz libs and headers against which to build applications graphviz-doc - additional documentation for graphviz libsql-translator-perl - SQL translation library ncc - C source code analyzer python-pygraphviz - Python interface to the Graphviz graph layout and visualization package sqlfairy - SQL translation utilities -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 7 new messages from ladies for you
marina <[EMAIL PROTECTED]> writes: > I am looking for man for long-term relations Install the "man-db" package. And, please note, this question isn't debian-science related (what scientist has long term relations, except with their work?) so please direct further questions on this matter to debian-user. Thanks, -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Re: java
Francesco Pietra <[EMAIL PROTECTED]> writes:
> jmol-11.0.RC4-binary.tar.gz
> decompressed, gives
> jmol.jar
> as executable.
> Could you please direct me where to learn how to run
> jar with either java or classmath installed from
I'm no Java expert, but I have one Java application I use (GraXML)
that is in a jar file. Below is the wrapper script I use, maybe it
helps.
#!/bin/sh
script=$1
export GRAXML_HOME=/home/bviren/work/dayabay/GraXML-3.1.8
JAVA_HOME=/usr/lib/jvm/java-1.5.0-sun-1.5.0.08
export
LD_LIBRARY_PATH=${GRAXML_HOME}/lib:${JAVA_HOME}/jre/lib/i386/xawt:${LD_LIBRARY_PATH}
java -Xmx512M -jar ${GRAXML_HOME}/lib/GraXMLDisplay.exe.jar $script
#
-Brett.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Couple of naive questions
Luca Ingianni <[EMAIL PROTECTED]> writes: > Am Freitag, 5. Januar 2007 22:35 schrieb Francesco Pietra: > >> pdpdff > >> bibionmedicalublication > >> prpracticedrostitution >> accept epepsdid not accept ododtonly doc for text and > >> If you are curious about the fate of my paper, I'll >> tell about that. > > I'm also rather curious about the fate of your keyboard :) > But please tell us the rest of the story as it unfolds, this could be fun. I just assumed it is a study of Tourette Syndrome Pdpdff, -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Couple of naive questions
Francesco Pietra <[EMAIL PROTECTED]> writes: > There is another gap (from the same point of view) on > unix systems: lack of a powerful free-form database. > Relational, structures packages are too slow to use, I > can't spend so much time in filling data. That is > matter for an organization, even free like PubChem. > What I need, is to fill words, paragraphs, even an > entire paper, into a record, having a powerful boolean > search to retrieve in seconds through thousands of > records. I can even quickly set fields on the flight. > I could write books useful for the amount of data > through my extensive databases, constructed day by day > with minimum effort. Though, I have to use it through > wine. I hope one day someone will start such a project > for unix-type systems. Maybe I'm showing ignorance but what you describe sounds more like an indexing search engine rather than a database. If so, maybe the "htdig" package would be useful. With some helpers you can index DOC and PDF as well as text-based formats. It then provides a web based search front-end. -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Couple of naive questions
Egon Willighagen <[EMAIL PROTECTED]> writes:
> That is certainly possible. Check this PDF [1], which uses a LaTeX package
> with source code like this:
>
> \put(-250,-450){\pyridinevi{3==OH}}
>
> for a pyridine derivative. It's using these packages:
>
> \usepackage{chemist}
> \usepackage{echem}
Checking my Latex Graphics Companion book I see two potentially
interesting chem related packages, xymtex and ppchtex. They both let
you draw chemical bond diagrams.
> Not sure if they are in Debian, though.
The texlive-chemistry package might be useful. But, it doesn't appear
to have any of the packages mentioned above. Here is the description:
This package includes the following CTAN packages:
bpchem -- Typeset chemical names, formulae, and numbering of chemical
compounds.
chemarrow -- Arrows for use in chemistry
chemcompounds -- Simple consecutive numbering of chemical compounds.
chemcono -- Support for compound numbers in chemistry documents.
chemsym -- Macros for typing chemical symbols.
mhchem -- Typeset chemical formulae/equations and Risk and Safety phrases
-Brett.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Couple of naive questions
Francesco Pietra <[EMAIL PROTECTED]> writes: > My first (naive) question is: am I too much ahead (in > publishing tools) or are the editors in organic > chemistry so much behind (in publishing tools)? Their use of DOC and yours of OpenOffice are certainly ahead time-wise but are both far behind tech- and ease-of-use-wise (imo). > At any event, my second (naive) question is: what > about editors in other areas? In High Energy Physics, LaTeX for the document and EPS (which provides for bitmapped and JPEG images as well) for figures is, thankfully, the standard. At least for scientific publications and preprints. Brushing up with the Gov't or the admin side of the house typically involves de-evolving to DOCs. The best laugh I get is receiving an email attachement of a multi MByte screen shot of a Word window in BMP format showing a paragraph of plain text. Back to work, -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Geant4 unofficial Debian package repository rearranged
"Kevin B. McCarty" <[EMAIL PROTECTED]> writes: > Brett Viren wrote: >> Also, how difficult would it be to allow multiple versions to be >> installed, including the -dev and -header packages? [ ... big snip ... ] Okay, wow. So, I guess to summarize the answer is "very". It certainly sounds like way more effort that it is worth. > Hope this is somewhat helpful. It was, thanks. Another option I suppose would be to maintain a chroot'ed installation to test out new versions. Thanks, -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Geant4 unofficial Debian package repository rearranged
"Kevin B. McCarty" <[EMAIL PROTECTED]> writes: > Sorry, Geant4 release 8.2 has not yet been packaged. Not to give you pressure, but do you have an estimate when you might package it? Also, how difficult would it be to allow multiple versions to be installed, including the -dev and -header packages? For example, you could install headers and libraries in versioned directories and use the /etc/alternatives mechanism to point to the default? The reason I ask is that when a new version comes out we want to validate that it hasn't changed in an unknown way. This typically means compiling simulations code against both versions and running them side-by-side. Thanks for you work, -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How much interest in a "debian-science.org" repository?
"Kevin B. McCarty" <[EMAIL PROTECTED]> writes: > I personally don't have anywhere to host such a repository. (My > post-doc is up in April so I will probably lose the use of the machine > currently hosting my Geant4 .debs.) Not to put words in his mouth, but > I understand that Brett Viren has space, but (as a national lab > employee) is highly sensitive to the need for legal vetting of > everything distributed from his web space. Yes, I'm still up for this, although I've been too busy of late to push forward. I especially (selfishly) would like to make sure your current, and hopefully future, Geant4 packages have a home. I think we can work something out to allow you secure uploads. But, growing beyond that I need to find some time to look into the repo tools that came up last time we discussed this. -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ROOT even free'er
I see in ROOT's v5-14/00 release notes: http://root.cern.ch/root/Version514.news.html Core: - Cleanup of many ambiguous license statements, ROOT should now be in such a state that is passes the stringent Debian legal tests for OS software. -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: exceptions in gnu c++
Paul, Run "top -d 1" from another terminial before starting your program. It should show clearly the memory usage climbing if your code has a leak. Hit shift-M to sort by memory usage. If this is indeed the case I suggest that you recompile with "-g" and then run your program under "valgrind" to find the source of your memory leak. Luck, -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GEANT4 *binary* .debs now available
Hi Kevin, Would it make sense to put in this symlink to future packages: /usr/lib/geant4/include -> /usr/include/geant4 The reason being is that some 3rd party packages that build against G4 don't use $G4INCLUDE but rather assume that includes are kept in $G4INSTALL/include/ BTW, these G4 packages are very much appreciated! -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cern software
Christian Holm Christensen <[EMAIL PROTECTED]> writes: > Scientific Linux comes it to variants - the FermiLab variant and the > CERN variant. One can install vanilla SL which is just RHEL. But, that doesn't negate all the other problems with SL that were brought up. Besides them, SL doesn't support upgrading in place between major releases. > ROOT was close to hitting `main' for etch, but some unfortunate license > problems prevented that. The upload to Debian is postponed till that > situation is remedied (upstream and I are working on it :) I thought this was a solved problem as of 5.04/00. >> It uses its own package >> manager, CMT (www.cmtsite.org) > > CMT is an unfortunate mix of a build system and a package manager - very > much geared to SL. I don't think it is SL or any OS specific. One of its features is to be cross platform. CMT is actually pretty nice for what it does. We use it on another experiement (Daya Bay reactor neutrinos) to build our code so I can attest that it works fine on Debian. My only gripe is its documentation. It has a detailed manual but it is very hard, for me at least, to find solutions to problems with it. > Hopefully that's true. However, be aware of RPM hooks in CMT, and other > ill-conceived hacks that could distribut the system. I don't know of any RPM related anything in CMT. > I'd suggest setting up a test machine before you plunge into the big > install. If you package CMT for Debian, perhaps that would minimise > your problem. Probably it's easiest to install CMT from source and share the installation disk throughout the cluster. Likewise with CMT built packages. CMT allows the concept of a base software release and additionally one or more user-modified packages overriding base ones. > Sounds good. Don't you start up PROOF servers too? No, I haven't ever looked in to PROOF. -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cern software
Hi Matt, Matt Zagrabelny <[EMAIL PROTECTED]> writes: > My name is Matt Zagrabelny, I work as a Debian sysadmin for the > University of Minnesota Duluth. We are looking at setting up a Beowulf > Cluster for our Physics Department. They are advocating Scientific Linux > (RedHat derivative), I am advocating Debian. > > They need certain CERN software. They have pointed me to the following > website: > > http://lhcb-comp.web.cern.ch/lhcb-comp/Frameworks/ Geant4 and ROOT are (currently unofficially) packaged for Debian. > They need things like GAUDI. I am wondering if anyone has any experience > with installing this software (on Debian), if anyone could give any hints, or > any > general advice regarding CERN packages/frameworks/software. I don't think Gaudi is packaged for Debian. It uses its own package manager, CMT (www.cmtsite.org) that builds Gaudi and other LHC packages and provides environment variable setup. Given that, there isn't much difference in building CMT controlled packages on Debian than on SL or other GNU/Linux distributions. Some packages that I find useful for my Debian cluster: diskless (Debian specific, manage config on worker nodes) usepackage (Manage environment for non-Debian packages) cexec (exec commands on worker nodes in parallel) distcc (distributed compilation) I boot my nodes from the network and their root FS are all NFS mounted. Local disk is currently only used for swap space. This, plus diskless, makes adding new nodes and upgrading software extremely easy. I use torque/maui for the batch system. These are unfortunately not available as a Debian package to my knowledge. Cheers, -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How much interest in a "debian-science.org" repository?
"Alexander L. Belikoff" <[EMAIL PROTECTED]> writes: > I am a lurker on this list, so please don't hit on me too hard for a > possibly naiive question. I assume, this standalone repository is > supposed to be a stopgap for packages before entering Debian official > repository (and ultimately becoming part of future Debian stable), right? For some of the package, yes. Other's may not be licensed in a manner acceptable to Debian (but are still legal for us to distribute). Or, they may simply not have an official Debian developer to support them. -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How much interest in a "debian-science.org" repository?
So, it seems there is much call for a debian-science unofficial repository. Great! A few things in response: 1) Distribution types. I think it is best to keep the standard main/non-free/contrib splitting. This splitting was invented to make clear the free-ness of the code and not the types of packages. We may be asking for a lot of extra effort if we break that model. We might consider other types such as "no licence but the author says it's okay" (not sure how legal that is). Also, this is something I need to take very seriously as it would be a huge problem if I serve copy-write infringing files. 2) Upload privileges. I can't subject BNL to a potential embarrassment due to serving packages with malicious code so unauthenticated uploads can't be supported. At the very least I think we must take the same precautions as Debian does with their PGP keys. This means face to face signing parties. This is probably easier for us w/in a particular scientific comunity that Debian as a whole since we tend to naturally mingle more. Maybe someone can look into other distributed authentication mechanism that would be equivalent (eg grid certs). 3) I'll check into the repository management tools mentioned. However, as Kevin said this may take some time, so stay interested but patient. Regards, -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: root on ppc: 403 forbiden
Hi Yannick, Yannick patois <[EMAIL PROTECTED]> writes: > Err http://mirror.phy.bnl.gov unstable/root root-common 5.09.01-7 > 403 Forbidden In the unstable/root/binary-powerpc area these "packages" are all actually broken symlinks to the pool area. science/root-common_5.09.01-7_all.deb science/root-doc_5.09.01-7_all.deb science/root_5.09.01-7_all.deb contrib/x11/ttf-root-installer_5.09.01-7_all.deb I've just removed them. The older version "-6" ones are linked okay so please try again. Christian, did anything break in your repository scripts? -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ROOT/gnuplot
Ricky Egeland <[EMAIL PROTECTED]> writes: > FYI, my motivation for doing this is to interface with a PHP web app. > I want to open a named pipe to the gnuplot-like program and write > data to it from PHP. The output will be a plot (PNG format) and ROOT > file which is cached and displayed on the web site. There is a ROOT module called "Carrot" that lets you interace ROOT with apache. Maybe it would be useful. I've never used it myself so can't say anything more. -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: IDL 6.2 under Debian sarge amd64
Mauricio Ortiz Calvao <[EMAIL PROTECTED]> writes: > Internal error: attempt to pop too many output funct > % X windows protocol error: BadAlloc (insufficient resources for operat > % X windows protocol error: BadDrawable (invalid Pixmap or Window param > % X windows protocol error: BadDrawable (invalid Pixmap or Window param > % X windows protocol error: BadDrawable (invalid Pixmap or Window param A guess: try logging in via ssh -X -Y server-name Recent SSH's distinguish "safe" and "unsafe" X11 functions. -Y allows "unsafe". -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: scripts that relies on $ROOTSYS
muzzle <[EMAIL PROTECTED]> writes: > I'm a user of the ROOT packages available at > http://mirror.phy.bnl.gov/debian-root/ (btw thanks to the > maintainers). I recently had to work with a lot of scripts and > makefiles that relied heavily on ROOTSYS being set. > > Fortunately I could edit those scripts and hardcode the right > directories (/usr/bin /usr/include/root etc.) but I wonder if there > is a sane way to cope with this scripts, short of creating a directory > with symlinks to all the relevant files (argh!) and point ROOTSYS > there. What about using the "root-config" script to locate chunks of ROOT instead of ROOTSYS? -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What is "disclaiming" a copyright ?
Charles Plessy <[EMAIL PROTECTED]> writes: > What is the meaning of the following ? > > " Burkhard Morgenstern hereby disclaims all copyright interest in > DIALIGN, written by Burkhard Morgenstern and Said Abdeddaim." > > > I suspect that one of the copyright owners gives its rights to the other > one, but which one ? I think you are correct. I have seen in several copyright discussions that if there is no explicit copyright statement the default is that there are no rights to distribute (of course, this may just be perpetuating a myth). Is there any similar statement from the second author? In any case it is probably best to post this question on debian-legal. -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New source and binary Debian packages for ROOT.
(debian specific response, roottalk dropped) Hi Chris, Chris Roat <[EMAIL PROTECTED]> writes: > I am using something between sarge and etch, but sarge enough to > default g++ to 3.3. Hence the confusion. What /etc/apt/sources.list line are you using to access the repository? If you want to have your development packages at "stable", then you should use the "stable" root packages. Christian, should you have the -dev packages depend on the correct version of g++? I don't know Debian policy well enough > FYI, the stable repository > seems to hold a mixture of 5.09.01-2 packages, while the unstable > respository seems to hold 5.09.01-3 packages. (In both cases, there > is a mixture of older versions of deprecated packages). There isn't anything bad per se with this (other than wasting my mirror's disk space!). What packages you actually get are determined by the Packages file. In principle a package can be in both sarge and etch, eg -doc or non-binary ones. > IMHO, dependencies of the ROOT packages should be kept to sarge, > unless there is some code-critical reason to do otherwise - even if > the packages are kept in unstable repositories. I don't understand. Both sarge and etch are supported. I'm guessing the root problem (no pun intended) is that you are using the "unstable" sources.list line on a system that has its compiler related packages at "stable". Adding a dependency on a version of g++ would catch this, but again, I don't know what Debian policy is here. > This way, there is > the greatest chance of getting the broadest user base. Heh, that is making a huge assumption. All software devel platforms around here are etch, if not sid. But, anyways, since both are provided, it's moot. Cheers, -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New source and binary Debian packages for ROOT.
"Kevin B McCarty ([EMAIL PROTECTED])" <[EMAIL PROTECTED]> writes: > Well, if you are using Sid or Etch, g++-4.0 (which is compatible with > 3.4) is the default C++ compiler. If you are using Sarge, then I don't > know why the ROOT packages for it were compiled with g++ 3.4 -- > you would have to ask someone else. Christian or Ricardo? He referenced Christian's announcement of the unstable packages in the initial query. -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pdfscreen -- latex presentation viewer
Tim Connors <[EMAIL PROTECTED]> writes: > > Haven't used latex-beamer. Give it a try. Beamer + PGF for images and line art is a pretty powerful combination. There is a great example presentaion by Ki-Joo Kim that runs 200+ pages and shows many of the features. http://faq.ktug.or.kr/wiki/uploads/beamer_guide.pdf > pdfscreen has nice navigation controls on the side of the pdf -- dunno > whether latex-beamer can do that. Adding navigation and launch buttons, > colours, on the fly colour themes (works well when you discover that the > projector you are going to be displaying on has a dying faded tube), works > well with ppower4 post processor No on-the-fly color scheme changes but the rest can be done with beamer. You can change color schemes with a quick edit and re-compile. > Personally, pdfscreen is better then latex-beamer because my presentations > have been customised to work with pdfscreen :) Well, that is certanily a hard point to argue! I've never done more than look into pdfscreen so I can't say much about it. Except for one experiment with a groff based presentation maker, a few excruciatingly painful GUIs (OpenOffice and PowerPoint, I'm looking at you!) and an occasional skribe compilation I've always used latex. I went from "slides" to "seminar" to "prosper" and now use "beamer" exclusively. To me each was an exponential improvement on the previous. -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FORTRAN common blocks
Eric S Fraga <[EMAIL PROTECTED]> writes:
>
> All arguments are passed by reference in Fortran.
To be pedantic, only *explicit*, non-array arguments are passed by
reference.
For example, when passing a character string, the pointer is passed by
value and there is an implicit string length which is also passed by
value.
This is shown in this C wrapper for the CERNLIB subroutine HBOOK1:
void hbook1(int id, char *title, int nbins, float min, float max)
{
void hbook1_(int*,char*,int*,float*,float*,float*,int) ;
float vmx = 0.0;
hbook1_(&id, title, &nbins, &min, &max, &vmx, strlen(title));
}
Here, "hbook1_" is the mangled symbol name of the actual FORTRAN
subroutine HBOOK1. BTW, this mangling depends on the FORTRAN compiler
and what options were given but trailing underscore is common for g77.
-Brett.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New Debian ROOT (5.09/01) packages for i386 unstable
Hi Ricardo, "Ricardo Yanez" <[EMAIL PROTECTED]> writes: > There are some unmet dependencies if installing the meta package, As Chistian noted, those packages are meant for the "unstable" version of Debian. It's not surprising they fail to build-dep or install on your "stable" Debian. So, either move to "unstable" (although "testing" may be enough) or use ROOT 5.03/01 for "stable" via: deb http://mirror.phy.bnl.gov/debian-root stable root deb-src http://mirror.phy.bnl.gov/debian-root stable root -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Environment variable management with usepackage (Was: Any interest in Debian packages of Geant 4?)
Christian Holm Christensen <[EMAIL PROTECTED]> writes: > In my humble opinion, wrapper scripts are ugly. That said, I could > imagine that it would be the best solution (for now) to package GEANT 4 > - it's a mess when it comes to environment variables. I agree. For non-Debian packages I use something called "usepackage" (it's in Debian). This lets me write a single config file that can be used to for both bash and tcsh users (why oh why is tcsh still so popular!?). It can handle multiple installed versions. Also the configuration can be spread among multiple config files so as to allow different groups to keep group-specific environment configurations separate. -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Any interest in Debian packages of Geant 4?
Hi Kevin, "Kevin B. McCarty" <[EMAIL PROTECTED]> writes: > Needing to do some Monte Carlo simulations for the last bit of work on > my thesis, I was once again reminded how much of a pain compiling Geant4 > from source is. Personally, I would use them. I also always have difficulties building Geant4 from source. Have you contacted Geant4 folks to see if they would distribute your debian/ source directory? > If there isn't enough desire for Geant 4 in Debian's > official archive, I might be able to keep unofficial .debs around in a > separate repository when they are more polished. Just distributing your debian/ source directory would make me happy! Also, if you need/want a distribution repository I can offer space on the one that currently distributes the ROOT debs. -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian's PAW should now work on AMD64 (also: OpenPAW)
"Kevin B. McCarty" <[EMAIL PROTECTED]> writes: > In case it slipped past people's notice, I just wanted to mention that > Cernlib's PAW data analysis program http://packages.debian.org/paw> > should work OK on Debian/AMD64 Nice. One less reason to keep my cluster at 32 bits. > On another note, I've found an interesting set of applications called > "OpenScientist" on the web: http://openscientist.lal.in2p3.fr/>. > It is GPL and apparently aims to be a competitor to ROOT (about which > the main OpenScientist author seems to have a bit of a chip on his > shoulder). Heh, ya' think? "OpenScientist is definitely NOT one million lines of intricated and unnecessary complicated home made code reinventing everything." "And we must point out that writing in C++, java or C# does NOT consist to put a ';' at the end of lines of a FORTRAN program." There are some other gems in there. They are funny because they are true! Anyways, this project looks quite interesting, thanks for pointing it out. -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xml as a scientific data format
Michael Gilbert <[EMAIL PROTECTED]> writes: > Does anyone have any good references that make clear and good > arguments for representing long sets of scientific (floating point) I think you need to give more description of what type and amount of data for people to give suggestions. - How much data will you produce and at what rate? - Do you require compression and/or fast I/O? - How is the data to be structured? - Do you want on-file and in-memory structures to be similar? - Will the structure likely evolve over time? - What applications need to access it (eg, custom, proprietary)? Depending on the answers, certainly, ROOT's file format and libraries provide many useful I/O features. http://root.cern.ch/ for more info. Debian packages are available. -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Random numbers generation
Thomas Walter <[EMAIL PROTECTED]> writes:
> Just for completeness to the random generators mentioned above.
> If your system has '/dev/random'
Before investing in using /dev/random note it can "run out" of
numbers. When generating, one will have to do things like move the
mouse or type.
You can see this yourself by doing:
cat /dev/random | od
("od" is used so you don't corrupt your terminal with all the 8 bit
chars that will be generated).
-Brett.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Debian mailing list conventions. (Was: Debian based live chemoinformatics CD?)
Dirk Eddelbuettel <[EMAIL PROTECTED]> writes: > (and CCs to those who contributed to the thread already, as well as to Klaus > and Ian re the LCC aspects below) The convention on Debian lists is to not CC people unless they explicitly ask for it. http://www.debian.org/MailingLists/#codeofconduct -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian based live chemoinformatics CD?
Egon Willighagen <[EMAIL PROTECTED]> writes: > I've been thinking about live linux CDs to demo and easily setup a developers > environment for... I've done similar for our collaboration using Debian based Morphix (www.morphix.org). It is designed explicitly to be used to build custom live CDs. > Java based chemoinformatics software. So I want to make a > custom CD with openbabel, CDK, JChemPaint, Jmol, pyMOL, xdrawchem, > kfile_chemical, etc, and as developers tools C++, eclipse, Blackdown Java (or > something like that). > > I have no preference for Kubuntu/Knoppix or whatever, but do require KDE as > desktop (for kfile_chemical). Just FYI, you don't need a full KDE desktop just to run KDE clients. -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python plotting with greek symbols within labels recommendations?
Michael Gilbert <[EMAIL PROTECTED]> writes: > > any thoughts on plotting libraries would be much appreciated. Root has a "tex inspired" language, actually very close to tex, that can be used to put Greek, equations and other tex-y things on Root plots. It is done through the TLatex class: http://root.cern.ch/root/html/TLatex.html#TLatex:description Root is primarily used via C++ (compiled or interpreted) but comes also with Python bindings: http://wlav.home.cern.ch/wlav/pyroot/ Here is an example plot that shows some Greek and an arrow symbol: http://nwg.phy.bnl.gov/~bviren/talks/nufact05/nodes.eps Not quite as pretty as real tex, but not bad. -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ROOT as A replacement for gnuplot
Hi Kevin, "Kevin B. McCarty" <[EMAIL PROTECTED]> writes: > Out of curiosity (sorry for the sidetrack), why do you say > "unfortunately"? You just don't like C++ being used as a scripting > language, or some other reason? Yes, my snarky comment was mostly based on the design decision of using C++ as both the scripting and interactive command line language. It's something that is often debated in ROOT circles and I can see the pros and cons but personally feel the latter strongly outweigh the former. As Christian mentions, the implementation of CINT is also not the nicest (although it is clear that Masa has worked very hard on this very hard problem, so I don't mean any disrespect). Having found myself there a couple of times I pitty anyone that discovers a SegV buried inside CINT's library and must track it through all the twisty passages. There is also the stange idiom of doing version control in the code itself. It is littered with CPP macros like "#ifdef G__OLDIMPLEMENTATION1616". That is the source code, but there is also the problem of CINT not being a true C++ implementation. For example, one doesn't need to declare variables, stack based objects don't always destruct correctly and scope is not always handled correctly. ROOT adds another quirk with a behind-the scenes object namespace that "leaks" out into interpreted code. Eg, if one creates a histogram with a ROOT name "h1", it is available in interpreted code as a pointer-to-hist-object variable named h1. These end up being "gotchyas" and lead new C++ programmers (which make up a large number of ROOT's users) into bad programming habbits. On the bright side, it would be a fairly easy project to come up with a nicer interactive/scripting language on top of CINT. Even if this took the form of a set of C++ based functions that hide away a lot of the complexity of managinng all the ROOT objects. Thus the suggestion for writing a gnuplot-like interface on top of ROOT. There is also a Python interface that is quite promising and already very useable. It is essentially a transliteration of ROOT C++ objects into Python ones so it inherits many of the design "issues" (good and bad) but does remove the need to worry about memory management and CINT language problems. >> CINT (C/C++ INTerpreter) provides the interactive shell, scripting >> language as well as the means to introduce reflection to C++ (although >> this last job will be done by another tool in the near future). > > This sounds interesting. Are you willing to give a sneak preview? :-) Besides the files for the ROOT implementation that Christian pointed to, you might be interested in an unrelated project that I once tried to push on the ROOT team: http://opencxx.sourceforge.net/ It's even in Debian: http://packages.debian.org/stable/devel/openc++ -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ROOT as A replacement for gnuplot
"Kevin B. McCarty" <[EMAIL PROTECTED]> writes: > IMO it would be ideal for Root to use an existing version of Cint but it > will be faster to upload Root source that builds its own Cint binary (in > the "root-cint" binary package). Also I don't know if Root is > compatible with "pure" Cint. ROOT uses Cint through its library interface and via a "rootcint" executable. The "cint" executable isn't used, afaik, so if a pure Cint package is ever resurrected, it shouldn't conflict. I doubt that ROOT can work with anything other than its own Cint. -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ROOT as A replacement for gnuplot
Thomas Walter <[EMAIL PROTECTED]> writes: > I had a quick look at the sources. Really large. Indeed. > From my point of view, it would profit if the build system will be > converted to use > autoheader, autoconf,automake,configure, libtool This might happen if someone contributes it, but best check if upstream is accepting first before doing a lot of work. I doubt upstream will do this work themselves since the existing "configure" script mostly works. > Do I understand the source correct, > ROOT comes with a copy of 'cint'. > Is this necessary or can it use an existing 'cint'? Yes, it is absolutely (and unfortunately) central. CINT (C/C++ INTerpreter) provides the interactive shell, scripting language as well as the means to introduce reflection to C++ (although this last job will be done by another tool in the near future). -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ROOT as A replacement for gnuplot
Andre Lehovich <[EMAIL PROTECTED]> writes: > ROOT's license is *far* worse than Gnuplot's. If one is going to rewrite > Gnuplot for licensing reasons (as Damián suggested) then basing the work on > ROOT is going in the wrong direction. What, you don't like the LGPL? http://root.cern.ch/viewcvs/LICENSE Note the last commit and rejoice. -Brett.
ROOT as A replacement for gnuplot
Hi Damián, Lisandro Damián Nicanor Pérez Meyer <[EMAIL PROTECTED]> writes: > Hi everyone! Yesterday, the guys at the local LUG and I were wondering > in which project we could possibly offer some help / create. > In the first moment, I thought about a 100% GPL replacement for gnuplot > (I mean, without things like the statement in gnuplot's licence about > ¿binaries? distribution). But then I remembered that someone here wrote > that she/he already begun a project like this. > As we are evaluating which way we are going to take, if there's a > possibility that we would be able to help, just e-mail me. In my opinion, ROOT (http://root.cern.ch/) already provides a superset of gnuplot features. It is true that it is more sophisticated and so it does take additional effort to become proficient as compared to gnuplot. So, I would suggest if people are interested in replicating gnuplot that they instead consider writing a gnuplot-like interface to ROOT. -Brett.
Re: Bibliography-Software recommendation
Filippo Rusconi <[EMAIL PROTECTED]> writes: > If so, pybliographic and LaTeX and emacs have done wonders for me... I've recently enjoyed using "skribe". It has built in support for bibs and can output latex, html/css, text and xml. If you like scheme or lisp and need to write documents, you'll love it. http://www-sop.inria.fr/mimosa/fp/Skribe/ Also available as a Debian package. -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Root license (Was: Hello)
Thomas Weber <[EMAIL PROTECTED]> writes: > > Sorry, lost attribution: >> >> In the discussion someone notices that beeing linked to (and beeing >> distributed inside) cernlib (covered by the GPL) ROOT >> must be released under the GPL and the sentence you quote is >> in violation of the licence. If someone is really interested in >> packaging ROOT, (s)he should probably politely mail the upstream >> author and make them aware of the problem, they could possibly just >> release ROOT under the GPL making it perfectly suitable for main (a >> great coup!) > > Well, as you seem to be interested, I suggest that you contact the ROOT > authors. I've asked recently. Of course the main developers and likely all contributors are very aware of the issue. ROOT has always been an all-but-that-one-clause Free Software project. At the risk of spoiling any surprises, a fix to the technicality can be expected. BTW, anyone going to: http://indico.cern.ch/conferenceDisplay.py?confId=a0522 If you use ROOT much, these workshops are always very interesting and educational. -Brett. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
