Re: alternatives to gnuplot ?
Thanks to Stuart's through work and expert opinion I tried out PyX today and was producing perfect graphs within a few hours for a paper I am writing in LaTeX. This included installing python, eclipse, pydev, compiling the pyx module and getting them all to work together -- as a python newbie. Considering that I am a beginner it must be due to the excellent and up to date documentation available. This is also true of PyX. Since Stuart started using PyX six months ago I suspect that since then the documentation has improved dramatically as the examples given on the pyx website include some pretty fancy stuff -- check it out. The bonus is that I now have an incentive to finally learn python. No luck needed! DavidOn 06/04/06, Stuart Prescott <[EMAIL PROTECTED]> wrote: > Hi! i read your thread, it is not a good thead and possible was write by> someone who don't have patience to learn something new.As the OP on that thread, I'll jump to my own defence here... I was more than willing to learn something new -- that's why I was asking for advice on whatwas available. Partly, it was a question of finding out what plottingprograms/packages people were using and partly looking at what other workflows people were using for data management and plotting.The problem I had was that none of the plotting utilities I had tried werecompatible with my existing workflow (which I had adopted through the use of tools such as excel and origin) and most were incompatible with the dataformats that I have the datasets in. (these formats weren't that exotic...csv or tab delimited with a header row, multiple X columns per file etc) My unwillingness was not to learn, I was just unwilling to reprocessmulti-gigabyte datasets accumulated over some years of research and rewriteall my dataprocessing scriptss so that the utilities that I had tried out could even read in the data to begin with. Then there were just he plain bugsin the packages which stopped you from even changing the window size in whichyou were looking at a plotFor the record, I have been using PyX for the six months since that discussion and I am quite happy with it. It's a steep learning curve (partly due to thedocumentation being pretty patchy when it comes to customising symbols andlines etc and partly through having python as a pre-req) but I'm liking the results. I've changed my typical workflow to be .dat + .py = .eps and that isagreeing with me quite well. Importantly, I haven't had to rewrite severaldozen data processing scripts and reformat my data archive to use PyX. Thanks to those who suggested PyX to me both on- and off-list and providedsome useful resources for learning a little python to get it all happening.I'm sure the little python scripts I've got to assemble the plots look like a perl person writing python and would make python aficionados cringe, but theywork for me (TM) :)Thanks also to those who suggested other tools that I didn't end up runningwith... it's all good for the melting pot. > Xmgrace is a respectable plot application in scientic comunit and you can> do all that origin makes and even more ! i recommend !!Read my original post. Many years ago I used xmgr for plotting data during a summer project and quite liked it, but the versions I had used could not copewith my data sets without a lot of faffing with either pipes or preprocessingdata into temp files. Not going to happen for me until I change research directions sufficiently fast as to discard all current datasets and dataprocessing tools.> Labpot is a excelente progam to!I've not been back to look at labplot and qtiplot since my original investigation of them and there have been several new releases of them sinceI did. Hopefully some of the limitations have been removed since then (StefanGerlach, the developer of labplot tells me that they are fixed in versions newer than the one that I tested). Given that, they are probably worthlooking at again. (Although now I've settled on PyX, I'm unlikely to changeagain for a few years... one can't afford the time to learn a new graphing tool every few months; at some stage one actually needs to get some work donerather than adapting to the new graphing package du jour.)best of luck with it!cheersStuart--To UNSUBSCRIBE, email to [EMAIL PROTECTED]with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: alternatives to gnuplot ?
so you got python + eclipse + pyx as shipped with Debian and only what you had to install is pydev, is that correct? Almost. Pydev can be installed directly from eclipse using its add-in manager, check out: http://www.fabioz.com/pydev/manual_101_root.html In addition, I had to install pyx in a "Non Debian way" because it defaults to having TeTeX as a dependency and I use texlive which is a more complete and flexible TeX installation. You can retrieve the .deb for texlive directly from CTAN: deb http://www.tug.org/texlive/Debian/ pool/deb-src http://www.tug.org/texlive/Debian/ pool/ >From my experience texlive is better for a single user install and others have said that TeTeX is better for a multi-user server, but that might change in the future as texlive is more modular so can be installed as a working TeX installation with custom abilities and a smaller footprint. did anyone track down why really pydev is not in Debian yet? I aman emacs guy but I might consider proper IDE... There is#316731: ITP: pydev -- eclipse plugin for python developmentPackage: wnpp; Severity: wishlist; Reported by: Matthias Klose <[EMAIL PROTECTED]>; 278 days old. If you are seriously interested in getting away from emacs, try out Leo (also hard to google). It is a very very useful program that I use for EVERYTHING. It literally changed the way I compute. You can download it from: (also not in Debian) http://sourceforge.net/projects/leo/ Or check out its homepage: http://webpages.charter.net/edreamleo/front.html. Which includes testimonials such as: "I think you're really showing what open source can do and your current trajectory puts you on track to kick Emacs into the dustbin of computing history." -- Dan Winkler As a Debian USER (read weak programmer), I am not trying to advertise this program, only share what really works.
Re: alternatives to gnuplot ?
Programmers often forget how much work it takes to learn how to use their programs. Both need to be praised. One thing that I found with PyX (and is true of many graphing packages) is that the size (bounding box in EPS speak) of the final graph is always different even if you give the graph the same dimensions when you create it. Your solution of wrapping it in a box is a standard solution that works in many programs and in LaTeX itself. I read that a future release of PyX will include SVG capabilities so that we can include inkscape drawings in our graphs. I see very powerful technologies converging here, and this was one of the main reasons for choosing to learn PyX.(Given the number of number of posts to this list about preparing graphs, both 2D and 3D, this is obviously a pretty difficult issue for GNU/Linux users still... but it also seems that things are progressing rapidly. Let the discussion and development continue!) I have been searching for good graphics solutions on Debian for YEARS and am now fully and completely satisfied with the programs available. Cheers, David
Re: eclipse.. and C++ IDE [was Re: alternatives to gnuplot ?]
Eclipse is found in regular Debian unstable apt repositories at: http://packages.debian.org/unstable/devel/eclipse There is another Debian package that aids C and C++ development, but I have no experiance with it: http://packages.debian.org/unstable/devel/eclipse-cdt I am not a C++ developer so I won't give you my opinion on which IDE to use, but Debian is stocked full of tools to help you. You just might have to check the unstable branch every now and then. Good luck, David On 08/04/06, Marc Baaden <[EMAIL PROTECTED]> wrote: >>> "david schryer" said: >> > so you got python + eclipse + pyx as shipped with Debian and only what >> > you had to install is pydev, is that correct? [..]Hi, talking about eclipse, two questions.a) you say it is in Debian.. I couldn't find it. Is there a specific apt repository? (I installed it from eclipse.org)b) is there a native gjc-compiled version for Debian, or is it easy to compile with gjc?Thanks in advance.Also suggestions for good C++ IDEs on Debian/Linux are welcome (I currentlyfocus on eclipse or KDevelop; I don't like anjuta; but I am ideally lookingfor a tool with Refactoring support, UML reverse engineering of C++ code and all those useful things etc.)Marc Baaden-- Dr. Marc Baaden - Institut de Biologie Physico-Chimique, Paris mailto:[EMAIL PROTECTED] - http://www.baaden.ibpc.fr FAX: +33 15841 5026 - Tel: +33 15841 5176 ou +33 609 843217--To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#361418: Debian menu and the Apps/Science section
I agree with the following two points and would like to expand on them, answer the third and make another suggestion as to how we should be thinking about the problem.I think the real point of this discussion is how should a menu be organized to facilitate easy and logical navigation to an app.I think we should not overly subdivide. How many of us actually have more than 5-10 apps installed for a given field? The first point is true, but should be stressed as to WHO uses this menu for easy and logical navigation. The people who regularly use a particular application rarely use the menu system to access it, and instead simply type in the appropriate command. This means that logical navigation is a bit more important that easy navigation. We are designing this menu for NEW users, who have no idea what programs are available to them and do not know any other way of finding them. Naturally, they will want to browse what is available in their particular speciality, but when they begin to get to work, they may also want to browse by the functionality of the program, not which discipline tends to use it. The second point is very important, but only to a limit. Browse the Apps>>Tools on the debian menu, and you will find WAY too many programs, thus making the entire menu system useless. I suggest that each end category contain a maximum of ten programs. If more are written we can further subdivide that particular branch (science or tools) Using this rule of thumb, I suggest the following menu changes: 1) XShells goes to Shells>>XShells, and the contents of Apps>>Shells (thus reducing the number of selections in Apps) 2) Apps>>Tools>> Add a list of tasks in the tools menu and subdivide by which program performs that particular task making sure that only 10 or less programs appear in each item on the list. Scientists are free to use the tools menu item too. Unfortunately, this list is not up for discussion on this forum, but I will add in my suggestion: Plotting Simulation Conversion Organization and a few others. 3) Apps>>Science>> This is where we can provide ONE list of GENERAL science topics. I suggest using names of departments in a large university. I used life sciences and social sciences to minimize on the number of menu items, while maintaining clarity. I suggest: Engineering Chemistry Physics Medicine Geography Computer Science Statistics Life Sciences Social Sciences As an engineer, who is also a scientist (and many are not), I will defend the need for a separate menu item. In the future, when more academics learn how to program, we will have many more science programs to use, and at that point we can add subdivisions to these categories. Any comments?
Re: Bug#361418: Debian menu and the Apps/Science section
My preference would be for an upper limit of more like 15-20 items perlist, but I like the idea. 15-20 would be ok if the names of the programs are more informative (not that it matters once you know what they do). Logically, I tend to think of Medicine as a category under LifeSciences, but perhaps the disproportionate number of potential entries under Med warrant it's separation. Medicine is applied life science much like Engineering is applied science in general (including many medical topics). It might be better to place various disciplines under life science such as: Biology Zoology Medicine Pharmacy ect (which could be triggered using the above suggestion if the amount of applications exceed a threshold value between 15 and 20 lets say) Also, Statistics seems out of place under science. I would suggestputting it in the tools section you mentioned before or under a broader section such as "math tools" under science. Yes, I agree as they tend to use other peoples data, but they do create their own data and make many models which they test against to find better ways of dealing with uncertainty. Besides, they create a prodigious amount of interesting computer programs specific to their discipline, and not all of them are tools. Some of these programs belong in tools as well, but is there any harm in some poly functional program being in two (or more) different menus? > As an engineer, who is also a scientist (and many are not), I will defend > the need for a separate menu item. In the future, when more academics learn> how to program, we will have many more science programs to use, and at that> point we can add subdivisions to these categories. I'll agree that a separate menu item is warranted (especially forthings like CADand design programs), but does it belong under science? I do see the point, but the solution lies in cleaning up our definition of the tools menu. We could put engineering design tools into Apps>>Tools>>Design and Apps>>Tools>>Simulation or Apps>>Engineering>>Design and Apps>>Engineering>>Simulation. There are far too few open source design tools currently, but I expect the number to grow very rapidly so a separate menu item may be needed for engineering apart from science. We could even call it applied science. In general I agree with your points. Cheers, David
Re: Bug#361418: Debian menu and the Apps/Science section
The cool thing about this is that nothing would ever get moved to adifferent branch of the menus, so as the menu changed, it would still be easy to find the app one is searching for. The length/depth of thebranch would just change to keep the aspect ratio reasonable.Maybe this is just crazy, but what does everyone think? If it is well thought out and not buggy, then it would be a very cool menu indeed. One problem that might arise is if a program, for instance, is classified as physics by the menu, but the user has classified the program in their head as chemistry before the menu subdivides and thus has trouble finding it. Of course, if they use the program frequently they would not be using the menu at all, so this is a small point.
Re: Bibliography and File Management
Give Zotero a try. It has adequate (but not perfect) BibTeX output which can be cleaned up in jabref easily. Collecting, annotating, and organizing the database is made easy with tags and associations, and it captures the pdf directly from the host site and includes DOI, ISSN, ISBN, and loads of other info. You can also associate any arbitrary file, note, link, to all records, so it is easy to include many layers of info in one database. The new collaborative features seem to work, but I have yet to test them in a serious multi-user environment yet. Even though this sounds like advertising, I am just a user who has tried loads of other tools over many years and like this one. The only slight downside is it slows down firefox on some sites, so I only use it when I am collecting references. Happy reading, David On Sun, Mar 15, 2009 at 10:42 AM, Alastair McKinstry < alastair.mckins...@sceal.ie> wrote: > > On 14 Mar 2009, at 23:28, Bryan Bishop wrote: > > On Sat, Mar 14, 2009 at 6:23 PM, Benda Xu wrote: >> >>> I have downloaded a lot of papers from the journals for reading and >>> reference. Although I tried to develop a naming scheme to organize the >>> file (mostly PDF format), I run into chaos these days: I forget which is >>> which before actually open the files one by one. >>> >> >> Yes, I run in to this problem as well. I go on reading sprees of >> hundreds of papers. Recently it was something like 200 papers and 150 >> MB re: microfluidics. BibTeX is nice, but not always a given. Google >> Scholar allows you to export citations as you find paper search >> results- perhaps it would be possible to write a userscript/javascript >> hack that would automatically download the BibTeX citation as you >> download a file? This way, you always keep track of information per >> download. This is a hack, not a real solution, of course. >> >> > Another program to include (is it in squeeze?) is calibre. I use an ebook > reader to read many papers and books; > it keeps its own metadata and book / paper sets: the pdfs are kept in a > filestystem (fine); some synchronisation of > the metadata and papers with a bibtex, etc. citation list would be good. > > Another point: DOIs. Most (?) papers these days are labelled with a unique > DOI (see dx.doi.org) . This could be used > as a pointer to the paper(s) and for labelling caches. > > - Bryan >> http://heybryan.org/ >> 1 512 203 0507 >> >> >> -- >> To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org >> with a subject of "unsubscribe". Trouble? Contact >> listmas...@lists.debian.org >> >> > Regards, > Alastair > > -- > Alastair McKinstry , http://blog.sceal.ie > > Anyone who believes exponential growth can go on forever in a finite world > is either a madman or an economist - Kenneth Boulter, Economist. > > > > > > -- > To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > >
