Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
Folks, Sheesh! More problems today. With XCOLORS, of all things. :-( New version here that allows you to switch between IDL and BREWER color tables (but properly, now): http://www.dfanning.com/programs/xcolors.pro Cheers, David -- David Fanning, Ph.D. Fanning Software Consulting, Inc. Coyote's Guide to IDL Programming: http://www.dfanning.com/ Sepore ma de ni thui. ("Perhaps thou speakest truth.")
David Fanning writes: > cgWINDOW -- One of the limitations of the way cgWindow > stores commands is that keyword values are evaluated > at the time the graphics command is added to the window. > This precludes the use of expressions as keywords and prevents > you from doing things like using a different line thickness > in a PostScript file, or using the Greek function to > supply a Greek symbol for a graphics title. > > I have come up with a method for working around this limitation. > It involves a new keyword to the cgWindow command, named WKYEXPR. > With this keyword you list the command keywords that should be > "evaluated" at run-time. The actual keyword value will need to > be a string that can be "evaluated" with the IDL Execute command > to produce a "real" keyword value at the time the command is > executed. This allows you to set different values for the window > display and for the PostScript display, for example. The WKYEXPR > keyword can be used with any CGS routine that supports the current > WINDOW keyword. > > Here is how you might use it, for example, with the cgPlot command. > > cgPlot, cgDemoData(1), WKWEXPR=['TITLE', 'THICK'], /WINDOW, $ > TITLE='"Greek Psi Symbol (" + Greek("psi") + ")"', $ > THICK='(!D.Name EQ "PS") ? 3.5 : 1.0', $ > CHARSIZE=1.5, COLOR='NAVY' > > I've written an article to explain this in more detail: > > http://www.idlcoyote.com/cg_tips/kwexpressions.php > > The updated program is here: > > http://www.idlcoyote.com/programs/cgwindow.pro Yikes! I somehow copied the wrong program into the distribution! Not sure how that happened. Then, when I finally got the right program installed, I had a programming error that IDL 8.1 allowed to slide, but IDL 7.1 didn't. And, worse, IDL 7.1 was leaking memory that IDL 8.1 was cleaning up!! I guess I appreciate that IDL 8.1 allows sloppier programming, but I'm struggling with the implications. :-( Anyway, fixed now, I think. Sorry for the confusion. Cheers, David -- David Fanning, Ph.D. Fanning Software Consulting, Inc. Coyote's Guide to IDL Programming: http://www.idlcoyote.com/ Sepore ma de ni thui. ("Perhaps thou speakest truth.")
David Fanning writes: > cgWINDOW -- One of the limitations of the way cgWindow > stores commands is that keyword values are evaluated > at the time the graphics command is added to the window. > This precludes the use of expressions as keywords and prevents > you from doing things like using a different line thickness > in a PostScript file, or using the Greek function to > supply a Greek symbol for a graphics title. > > I have come up with a method for working around this limitation Oh, dear! What I first thought was "impossible" now appears to be do-able, but probably not as implemented in this version of the program. The problem now is that this works great for a single command in a resizeable window, but it doesn't work properly for multiple commands in the window. Plus, I need the ability to evaluate parameters as well as keywords. Oh, well. No one said life was easy. :-) Back to the drawing board. (But, with more optimism than I had when I started this project!) Cheers, David -- David Fanning, Ph.D. Fanning Software Consulting, Inc. Coyote's Guide to IDL Programming: http://www.idlcoyote.com/ Sepore ma de ni thui. ("Perhaps thou speakest truth.")
Jeremy Bailin writes: > Is it just my imagination, or has greek.pro gone missing? I hope not, I've been using it all day! Gone missing from where? Cheers, David P.S. I just about have my "evaluate at run-time" keyword and parameter problems solved. But, I have been seeing some real strange behavior, too. Programs that should be identical are not, etc. Is the moon full or something? :-( -- David Fanning, Ph.D. Fanning Software Consulting, Inc. Coyote's Guide to IDL Programming: http://www.idlcoyote.com/ Sepore ma de ni thui. ("Perhaps thou speakest truth.")
David Fanning writes: >> cgWINDOW -- One of the limitations of the way cgWindow >> stores commands is that keyword values are evaluated >> at the time the graphics command is added to the window. >> This precludes the use of expressions as keywords and prevents >> you from doing things like using a different line thickness >> in a PostScript file, or using the Greek function to >> supply a Greek symbol for a graphics title. >> >> I have come up with a method for working around this limitation > > Oh, dear! > > What I first thought was "impossible" now appears > to be do-able, but probably not as implemented > in this version of the program. The problem now > is that this works great for a single command in > a resizeable window, but it doesn't work properly > for multiple commands in the window. Plus, I need > the ability to evaluate parameters as well as keywords. > > Oh, well. No one said life was easy. :-) OK, I *think* I have this completely sorted out now. I can evaluate both keywords (with a EvalKeywords keyword that replaces the previous WKWEXPR keyword), and parameters with a EvalParams keyword. I have updated my web page article to show examples using TexToIDL, Greek, and other expressions that can be evaluated at run-time. http://www.idlcoyote.com/cg_tips/kwexpressions.php I'd be interested to know if anyone using, say, IDL 6.4 has any difficulty running the examples in the article. You will need an updated Coyote Library. http://www.idlcoyote.com/programs/coyoteprograms.zip Cheers, David -- David Fanning, Ph.D. Fanning Software Consulting, Inc. Coyote's Guide to IDL Programming: http://www.idlcoyote.com/ Sepore ma de ni thui. ("Perhaps thou speakest truth.")
On 8/2/11 5:04 PM, David Fanning wrote: > Jeremy Bailin writes: > >> Is it just my imagination, or has greek.pro gone missing? > > I hope not, I've been using it all day! > > Gone missing from where? > > Cheers, > > David > > P.S. I just about have my "evaluate at run-time" > keyword and parameter problems solved. But, I have > been seeing some real strange behavior, too. > Programs that should be identical are not, etc. > Is the moon full or something? :-( I just downloaded http://www.idlcoyote.com/programs/zip_files/coyoteprograms.z ip and it's not in there anywhere I can find. -Jeremy.
Jeremy Bailin writes: >>> Is it just my imagination, or has greek.pro gone missing? >> >> I hope not, I've been using it all day! >> >> Gone missing from where? >> >> Cheers, >> >> David >> >> P.S. I just about have my "evaluate at run-time" >> keyword and parameter problems solved. But, I have >> been seeing some real strange behavior, too. >> Programs that should be identical are not, etc. >> Is the moon full or something? :-( > > > I just downloaded > http://www.idlcoyote.com/programs/zip_files/coyoteprograms.z ip and it's > not in there anywhere I can find. I just clicked on this link, downloaded the zip file, opened it up, and there is greek.pro just as clear as day! What else could be going on that prevents you from seeing this!? Anyone else having trouble with zip files on a Mac? Cheers, David -- David Fanning, Ph.D. Fanning Software Consulting, Inc. Coyote's Guide to IDL Programming: http://www.idlcoyote.com/ Sepore ma de ni thui. ("Perhaps thou speakest truth.")
On 8/3/11 11:41 AM, David Fanning wrote: > Jeremy Bailin writes: > >>>> Is it just my imagination, or has greek.pro gone missing? >>> >>> I hope not, I've been using it all day! >>> >>> Gone missing from where? >>> >>> Cheers, >>> >>> David >>> >>> P.S. I just about have my "evaluate at run-time" >>> keyword and parameter problems solved. But, I have >>> been seeing some real strange behavior, too. >>> Programs that should be identical are not, etc. >>> Is the moon full or something? :-( >> >> >> I just downloaded >> http://www.idlcoyote.com/programs/zip_files/coyoteprograms.z ip and it's >> not in there anywhere I can find. > > I just clicked on this link, downloaded the zip file, > opened it up, and there is greek.pro just as clear > as day! > > What else could be going on that prevents you from seeing > this!? > > Anyone else having trouble with zip files on a Mac? So I just looked closely at the output when I ran "unzip coyoteprograms.zip" and noticed the following lines: skipping: cgimage.pro unsupported compression method 14 skipping: greek.pro unsupported compression method 14 skipping: cgwindow.pro unsupported compression method 14 which is clearly the problem! It looks like compression method 14 is LZMA, which is not defined in the Zip standard but is used by WinZip. Is there maybe a flag that tells it to only use compression methods 0 to 10? -Jeremy.
On 8/3/11 9:41 AM, David Fanning wrote: > Jeremy Bailin writes: > >>>> Is it just my imagination, or has greek.pro gone missing? >>> >>> I hope not, I've been using it all day! >>> >>> Gone missing from where? >>> >>> Cheers, >>> >>> David >>> >>> P.S. I just about have my "evaluate at run-time" >>> keyword and parameter problems solved. But, I have >>> been seeing some real strange behavior, too. >>> Programs that should be identical are not, etc. >>> Is the moon full or something? :-( >> >> >> I just downloaded >> http://www.idlcoyote.com/programs/zip_files/coyoteprograms.z ip and it's >> not in there anywhere I can find. > > I just clicked on this link, downloaded the zip file, > opened it up, and there is greek.pro just as clear > as day! > > What else could be going on that prevents you from seeing > this!? > > Anyone else having trouble with zip files on a Mac? I have a couple problems with the zip file on my Mac: 1. I can't double-click to unzip it, for some reason I had to use "unzip" on the command line 2. I don't see greek.pro in it 3. The files in the zip don't stay in a single directory when unzipped, so unzipping on my desktop filled my desktop with files Mike -- Michael Galloy www.michaelgalloy.com Modern IDL, A Guide to Learning IDL: http://modernidl.idldev.com Research Mathematician Tech-X Corporation
Michael Galloy writes: > I have a couple problems with the zip file on my Mac: > > 1. I can't double-click to unzip it, for some reason I had to use > "unzip" on the command line > 2. I don't see greek.pro in it > 3. The files in the zip don't stay in a single directory when > unzipped, so unzipping on my desktop filled my desktop with files Yeah, not sure what is happening here. I use PowerArchiver to zip files. Three of those files used a different compression scheme, and all of the files had lost their path information. PowerArchiver has been doing a LOT of updating lately, so I wonder if that has something to do with it. Anyway, I built a fresh version just now. All files are suppose to extract into a Coyote directory and I used the consensus largest common denominator compression method. Let me know if this solves the problems. http://www.idlcoyote.com/programs/zip_files/coyoteprograms.z ip Cheers, David -- David Fanning, Ph.D. Fanning Software Consulting, Inc. Coyote's Guide to IDL Programming: http://www.idlcoyote.com/ Sepore ma de ni thui. ("Perhaps thou speakest truth.")
> Yeah, not sure what is happening here. I use PowerArchiver > to zip files. Three of those files used a different compression > scheme, and all of the files had lost their path information. > PowerArchiver has been doing a LOT of updating lately, so > I wonder if that has something to do with it. > > Anyway, I built a fresh version just now. All files are > suppose to extract into a Coyote directory and I used > the consensus largest common denominator compression method. > > Let me know if this solves the problems. > > http://www.idlcoyote.com/programs/zip_files/coyoteprograms.z ip Yup, that looks like everything is back to normal! -Jeremy.
David Fanning wrote: > David Fanning writes: > [snip] >> The updated program is here: >> >> http://www.idlcoyote.com/programs/cgwindow.pro > > Yikes! I somehow copied the wrong program into the distribution! > Not sure how that happened. Are you planning on creating svn tags of these releases? And, with apologies for the preaching, but how come you don't create the zip files from said tagged release? That should avoid wrong files being copied. Additionally, that would allow outside users of your package to update their own source code histories with the tag name of your release. Or, in my case, export your tagged release into my own repo -- I'm not allowed to use svn:externals :o( Traceability and all that, you know? cheers, paulv > > Then, when I finally got the right program installed, > I had a programming error that IDL 8.1 allowed to slide, > but IDL 7.1 didn't. And, worse, IDL 7.1 was leaking > memory that IDL 8.1 was cleaning up!! > > I guess I appreciate that IDL 8.1 allows sloppier > programming, but I'm struggling with the implications. :-( > > Anyway, fixed now, I think. Sorry for the confusion. > > Cheers, > > David
Paul van Delst writes: > Are you planning on creating svn tags of these releases? And, with apologies for the preaching, but how come you don't > create the zip files from said tagged release? That should avoid wrong files being copied. I've experimented (because of your nagging!) with tagged releases. It's probably because I don't fully understand what I am doing, but I don't like tagged releases. Mostly because two minutes after I tag a release someone reports a bug, and then the tagged release is obsolete and SVN seems to not allow me to change it. I am embarrassed to create a NEW tagged release two minutes after the old one. It makes it seem (duh!) like I don't know what I am doing! > Additionally, that would allow outside users of your package to update their own source code histories with the tag name > of your release. Or, in my case, export your tagged release into my own repo -- I'm not allowed to use svn:externals :o( > > Traceability and all that, you know? OK, here is how I work. I have two folders, Coyote and Zip_Files, under my IDL directory. When I make a change to a file that I think is a "significant" change (meaning, in practice, any change at all, because I am so damn anal!) I add the change to the coyoteprograms.zip file and I commit both the zip file and the program files to the Goggle SVN repository. Then, I "update" the same two folders that exist in my copy of my web page on my computer. After the update, I copy the updated files from my local web page to my real web page. I update Coyote Library routines frequently, probably at least once a week, and occasionally (when I'm not completely on my game) several times a day. The SVN repository includes the latest files. My web page contains the latest files. I would think that would be enough, but... What exactly do you want me to do? I'm interested in doing whatever works for people. Tell me how you would use these tagged releases, given what you know about my complete inability to serve up files that I know are out of date. Is it permissible to create tagged releases several times a day, or would I run out of release numbers. :-) And, how would these tagged releases be any different from the files that are already in the SVN repository? I mean, isn't this just extra work? Cheers, David -- David Fanning, Ph.D. Fanning Software Consulting, Inc. Coyote's Guide to IDL Programming: http://www.idlcoyote.com/ Sepore ma de ni thui. ("Perhaps thou speakest truth.")
Hello, David Fanning wrote: > Paul van Delst writes: > >> Are you planning on creating svn tags of these releases? And, with apologies for the preaching, but how come you don't >> create the zip files from said tagged release? That should avoid wrong files being copied. > > I've experimented (because of your nagging!) with > tagged releases. It's probably because I don't fully > understand what I am doing, but I don't like tagged > releases. Mostly because two minutes after I tag > a release someone reports a bug, and then the tagged > release is obsolete Well, don't blame subversion tags for that. :o) > and SVN seems to not allow me to > change it. I am embarrassed to create a NEW tagged > release two minutes after the old one. It makes it > seem (duh!) like I don't know what I am doing! I don't think this applies to you, but I've found that to be a common feeling amongst people that resist using version control: it immortalises all their mistakes. My response to that is: meh. I tend to learn much more from my mistakes and use them as teaching moments (i.e. "What not to do" slides in seminar presentations). Anyway... > >> Additionally, that would allow outside users of your package to update their own source code histories with the tag name >> of your release. Or, in my case, export your tagged release into my own repo -- I'm not allowed to use svn:externals :o( >> >> Traceability and all that, you know? > > OK, here is how I work. I have two folders, Coyote and Zip_Files, under > my IDL directory. When I make a change to a file that I think is a > "significant" change (meaning, in practice, any change at all, > because I am so damn anal!) I add the change to the coyoteprograms.zip > file and I commit both the zip file and the program files to the Goggle > SVN repository. Then, I "update" the same two folders that exist > in my copy of my web page on my computer. After the update, I > copy the updated files from my local web page to my real web page. > > I update Coyote Library routines frequently, probably at least once > a week, and occasionally (when I'm not completely on my game) > several times a day. The SVN repository includes the latest > files. My web page contains the latest files. I would think that > would be enough, but... It is enough. But it really only makes sense to you because you use it all the time. Outside users just want a single, reliable place to go to to get updates. > > What exactly do you want me to do? I'm interested in doing > whatever works for people. Tell me how you would use these > tagged releases, given what you know about my complete > inability to serve up files that I know are out of date. > > Is it permissible to create tagged releases several times > a day, or would I run out of release numbers. :-) I guess it depends on your release, and numbering, strategy. I use 3 numbers: X.Y.Z From my Coding Review and Acceptance policy document (cribbed from the WRF UCAR document) for the CRTM package I work on: * A “major release” contains important new scientific and/or software engineering advancements that significantly alter the behavior and/or performance of the CRTM. Numbering for major releases increments the first element of the version number. Examples: “CRTM 2.0.0”, “CRTM 3.0.0”. Major releases will be synchronized across all development subgroups and scheduled well in advance. There will be no more than one major release per year. * A “minor release” contains minor feature additions and enhancements. Model behavior is not fundamentally altered. Numbering for minor releases increments the second element of the version number. Examples: “CRTM 2.1.0”, “CRTM 3.2.0”. Minor releases will be scheduled well in advance and will be coordinated across all developers. However it is not required that every subgroup schedule minor releases at the same time. This allows for quicker turnaround of minor feature enhancements by individual development subgroups. * A “patch release” contains bug fixes. No new features are added. Coordination and scheduling are identical to minor releases, except that less advance notice is required. This allows for quick turnaround of bug fixes by individual development subgroups. Numbering for patch releases increments the third element of the version number. Examples: “CRTM 2.1.1”, “CRTM 2.1.2” Some package also tack on a patch number to a release, e.g. the current ruby release version is 1.9.2-p290. Yeah, 290 patches to release 1.9.2. No one thinks those folks don't know what they're doing. Have a look at: http://www.ruby-lang.org/en/ > And, how would these tagged releases be any different from > the files that are already in the SVN repository? I mean, isn't > this just extra work? Yes. But a tag name (e.g. "release_2.1.6") tends to be easier to remember than a particular revision in the repository, and it (generally) has more meaning to a development team. Additionally, the tag itself contains all the history associated with the files. As for the tagged releases being the same as the files in the repository, you can create mixed revision tags (I never do, but some people like that feature) so even a fixed repository revision number might not be a good anchor for a release. An anonymous zipfile name has no traceability and, more importantly, no associated history. You don't know what version of your package users have when they ask about problems they're having. Even a date has no meaning if they downloaded the zipfile before you fixed it. Maybe you should look into using some sort of continuous integration tool to manage all that for you. There are plenty third party ones out there. I would assume the google thing you use has something available. (I think I can hear you groaning all the way across the country :o) If that's too much for you right now, you could try creating generic tags, e.g. "nightly", or "latest", etc, by hand (well, script) for potentially unstable code that you're not yet ready to release as a package. Basically you just recreate these as needed. People know that if they go to the "latest" tag in your repo they're going to get the latest release of code that you're mostly happy with. How to do it? Well, probably the simplest method is to simply recreate the tag each time, e.g. svn move http://svn.repo.com/tags/latest http://svn.repo.com/tags/latest_YYYY-MM-DD --message "Moving latest tag" svn copy http://svn.repo.com/trunk http://svn.repo.com/tags/latest --message "Creating latest tag" After a sufficient period of time (depending on your schedule for "latest" updates) you could delete the oldest "YYYY-MM-DD" tags (references to which still survive in your repo). Remember than a subversion move or copy doesn't replicate all your source code - it just creates a database reference (effectively) to a particular snapshot. Apologies for the monologue. And the nagging. cheers, paulv p.s. How do other IDLers out there handle their code updates?
Paul van Delst writes: > I don't think this applies to you, but I've found that to be a common feeling amongst people that resist using version > control: it immortalises all their mistakes. > > My response to that is: meh. I tend to learn much more from my mistakes and use them as teaching moments (i.e. "What not > to do" slides in seminar presentations). Anyway... Yes, I agree that the way most people *become* experts is by exploring the possibility space in the widest possible way. It's just a messy business, and observing it tends to diminish the awe and reverence most experts are held in, and gives people the idea that "I could do this, too", which is entirely the wrong idea to be giving out if you depend on your expertise for making a living. :-( > It is enough. But it really only makes sense to you > because you use it all the time. Outside users just > want a single, reliable place to go to to get updates. Really!? Then how come you are the only one I ever hear complaining about this. ;-) > From my Coding Review and Acceptance policy document (cribbed from the WRF UCAR document) for the CRTM package I work on: > > * A ?major release? contains important new scientific and/or software engineering advancements that significantly > alter the behavior and/or performance of the CRTM. Numbering for major releases increments > the first element of the version number. Examples: ?CRTM 2.0.0?, ?CRTM 3.0.0?. Major releases will be > synchronized across all development subgroups and scheduled well in advance. There will be no more than > one major release per year. > > * A ?minor release? contains minor feature additions and enhancements. Model behavior is not fundamentally > altered. Numbering for minor releases increments the second element of the version number. > Examples: ?CRTM 2.1.0?, ?CRTM 3.2.0?. Minor releases will be scheduled well in advance and will > be coordinated across all developers. However it is not required that every subgroup schedule minor releases > at the same time. This allows for quicker turnaround of minor feature enhancements by individual > development subgroups. > > * A ?patch release? contains bug fixes. No new features are added. Coordination and scheduling are identical > to minor releases, except that less advance notice is required. This allows for quick turnaround of bug fixes > by individual development subgroups. Numbering for patch releases increments the third element of the > version number. Examples: ?CRTM 2.1.1?, ?CRTM 2.1.2? > > Some package also tack on a patch number to a release, e.g. the current ruby release version is 1.9.2-p290. Yeah, 290 > patches to release 1.9.2. No one thinks those folks don't know what they're doing. Have a look at: > http://www.ruby-lang.org/en/ > >> And, how would these tagged releases be any different from >> the files that are already in the SVN repository? I mean, isn't >> this just extra work? > > Yes. But a tag name (e.g. "release_2.1.6") tends to be easier to remember than a particular revision in the repository, > and it (generally) has more meaning to a development team. Additionally, the tag itself contains all the history > associated with the files. Alright, I'll do a little more reading and give this another try. I'm in and out a little bit this week, taking advantage of the great weather to do a bit of backpacking and such, so it may be later in the week before I get to it. > An anonymous zipfile name has no traceability and, more importantly, no associated history. You don't know what version > of your package users have when they ask about problems they're having. Even a date has no meaning if they downloaded > the zipfile before you fixed it. I've often wondered why I have the zip file under version control at all. Do you think it is necessary? My problem is I need to make a zip file, and it has to have the same name all the time so my web pages can point to it. How would you handle this for people with no access to the SVN repository? > Maybe you should look into using some sort of continuous integration tool to manage all that for you. There are plenty > third party ones out there. I would assume the google thing you use has something available. (I think I can hear you > groaning all the way across the country :o) You know me WAY too well! ;-) If I get around to it later, I'll Google "continuous integration tool" and see if there is anything there I can understand. :-) > Apologies for the monologue. Always a pleasure to hear from you! > And the nagging. You are like my wife. Both of you always seem to be right. :-) Cheers, David -- David Fanning, Ph.D. Fanning Software Consulting, Inc. Coyote's Guide to IDL Programming: http://www.idlcoyote.com/ Sepore ma de ni thui. ("Perhaps thou speakest truth.")
On 8/9/11 2:43 PM, David Fanning wrote: > I've often wondered why I have the zip file under version > control at all. Do you think it is necessary? My problem is > I need to make a zip file, and it has to have the same name > all the time so my web pages can point to it. How would you > handle this for people with no access to the SVN repository? I don't think that the zip file should be under version control, BUT there should be a SCRIPT (or some other automated, repeatable, reliable method) for generating the zip file. For some of the things I distribute this way, the script generates the documentation, builds the zip file, and uploads it to the right location on my server. I can type one command to update the server to the current version. Mike -- Michael Galloy www.michaelgalloy.com Modern IDL, A Guide to Learning IDL: http://modernidl.idldev.com Research Mathematician Tech-X Corporation
Michael Galloy wrote: > On 8/9/11 2:43 PM, David Fanning wrote: >> I've often wondered why I have the zip file under version >> control at all. Do you think it is necessary? My problem is >> I need to make a zip file, and it has to have the same name >> all the time so my web pages can point to it. How would you >> handle this for people with no access to the SVN repository? > > I don't think that the zip file should be under version control, BUT > there should be a SCRIPT (or some other automated, repeatable, reliable > method) for generating the zip file. For some of the things I distribute > this way, the script generates the documentation, builds the zip file, > and uploads it to the right location on my server. I can type one > command to update the server to the current version. Seconded. We have a sort-of similar problem for versioning testcases of the various forecast systems. The input files are either ginormous, or there are lots and lots and lots of little ones (either case I have observed giving our version control setup slight indigestion...I think due to network latencies, made worse by IT security restrictions that keep the server response time cutoff very short). My proposed solution to users is to version the script that retrieves the necessary files from our tape backup system. I think it probably takes less time to retrieve large (or lots of) files from the tape silos, than it would to check them out from our VCS - network throughput being what it is. I use a script to generate the release tag that I distribute (our development directory structure is vertical, whereas our release directory structure is flat). My next addition to that script is to allow for that tag to be exported and a tarball built -- including a text file containing the "svn info" output for the belts-n-braces effect :o) cheers, paulv
Hello, David Fanning wrote: > Paul van Delst writes: > >> I don't think this applies to you, but I've found that to be a common > feeling amongst people that resist using version >> control: it immortalises all their mistakes. >> >> My response to that is: meh. I tend to learn much more from my mistakes and use them as teaching moments (i.e. "What not >> to do" slides in seminar presentations). Anyway... > > Yes, I agree that the way most people *become* experts > is by exploring the possibility space in the widest > possible way. It's just a messy business, and observing > it tends to diminish the awe and reverence most experts > are held in, and gives people the idea that "I could do > this, too", which is entirely the wrong idea to be giving > out if you depend on your expertise for making a living. :-( Fair enough. I'm not self-employed so my approach of making myself as dispensible as possible isn't as fraught with immediate fiscal distress. >> It is enough. But it really only makes sense to you >> because you use it all the time. Outside users just >> want a single, reliable place to go to to get updates. > > Really!? Then how come you are the only one I ever > hear complaining about this. ;-) Because living in DC has made me a right curmudgeonly old bugger? :o) > I've often wondered why I have the zip file under version > control at all. Do you think it is necessary? My problem is > I need to make a zip file, and it has to have the same name > all the time so my web pages can point to it. How would you > handle this for people with no access to the SVN repository? See Mike's reply. > You are like my wife. Both of you always seem to be right. :-) The most important words in your last sentence is "seem to be". There is an aphorism I have quoted since I gave a oral presentation on gravity wave detection in my undergraduate years: If you can't blind them with brilliance, baffle them with bull****. :oD Queue the Incredible Hulk theme music as I backpedal off into the distance.... cheers, paulv p.s. Also see: http://stevenmsmith.com/ar-satir-change-model/ The trick (I reckon) is to figure out how to minimise the length of stage 3. :o/ The last 7+ years have taught me that it is difficult. Trust is hard to earn.
Paul van Delst writes: > p.s. Also see: > http://stevenmsmith.com/ar-satir-change-model/ > The trick (I reckon) is to figure out how to minimise the length of stage 3. :o/ The last 7+ years have taught me that > it is difficult. Trust is hard to earn. That curve looks like a history of Coyote Graphics! :-) Cheers, David -- David Fanning, Ph.D. Fanning Software Consulting, Inc. Coyote's Guide to IDL Programming: http://www.idlcoyote.com/ Sepore ma de ni thui. ("Perhaps thou speakest truth.")
Folks, I'm tired of Paul yelping at me all the time, so I have modified the Coyote Library repository to support frequently updated tagged releases of both the Coyote and Catalyst Libraries. http://idl-coyote.googlecode.com/ To this end, I have created "coyote" and "catalyst" folders in the "tags" branch of the repository and I have renamed previously tagged releases to support the new naming convention for tagged releases. The "trunk" branch of the repository will still be used for current development work. As soon as I deem current work "stable," I will create a tagged release. I expect tagged releases to occur frequently. Users can update to the latest tagged release by issuing an SVN command like this: svn co http://idl-coyote.googlecode.com/svn/tags/coyote_library_1.0 .7 local_dir If you are interested in the very latest code development, or in older routines (say in the "retired" folder), you will find these in the "trunk" branch of the repository. For example: svn co http://idl-coyote.googlecode.com/svn/trunk/coyote/retired local_dir The tagged release naming convention will involve three numbers (e.g. 1.0.5). The first number will be a major release number. This number should change infrequently. The second number is a minor release number and will indicate new features in the library, such as programs with new keywords added, algorithm changes, etc. The third number is an update number and will indicate, primarily, bug fixes or documentation changes to current library programs. I think this is a much better system than I had, and I plan to do my best to keep up with it! Thanks, Paul, for suggesting it. :-) Cheers, David -- David Fanning, Ph.D. Fanning Software Consulting, Inc. Coyote's Guide to IDL Programming: http://www.idlcoyote.com/ Sepore ma de ni thui. ("Perhaps thou speakest truth.")