|
|
| Re: Coyote Library Updates [message #77065 is a reply to message #62777] |
Tue, 02 August 2011 09:09   |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
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.")
|
|
|
|
| Re: Coyote Library Updates [message #77067 is a reply to message #62777] |
Tue, 02 August 2011 06:59 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
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.")
|
|
|
|
|
|
| Re: Coyote Library Updates [message #77145 is a reply to message #62777] |
Wed, 03 August 2011 09:38 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
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.")
|
|
|
|
| Re: Coyote Library Updates [message #77146 is a reply to message #62777] |
Wed, 03 August 2011 09:22 |
Michael Galloy
Messages: 1114
Registered: April 2006
|
Senior Member |
|
|
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
|
|
|
|
| Re: Coyote Library Updates [message #77147 is a reply to message #62777] |
Wed, 03 August 2011 09:12 |
Jeremy Bailin
Messages: 618
Registered: April 2008
|
Senior Member |
|
|
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.
|
|
|
|
| Re: Coyote Library Updates [message #77148 is a reply to message #62777] |
Wed, 03 August 2011 08:41 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
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.")
|
|
|
|
|
|
| Re: Coyote Library Updates [message #77152 is a reply to message #77065] |
Tue, 02 August 2011 16:08 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
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.")
|
|
|
|
|
|
|
|
| Re: Coyote Library Updates [message #77194 is a reply to message #62777] |
Wed, 10 August 2011 05:06 |
Paul Van Delst[1]
Messages: 1157
Registered: April 2002
|
Senior Member |
|
|
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.
|
|
|
|
| Re: Coyote Library Updates [message #77196 is a reply to message #62777] |
Wed, 10 August 2011 04:41 |
Paul Van Delst[1]
Messages: 1157
Registered: April 2002
|
Senior Member |
|
|
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
|
|
|
|
| Re: Coyote Library Updates [message #77199 is a reply to message #62777] |
Tue, 09 August 2011 15:15 |
Michael Galloy
Messages: 1114
Registered: April 2006
|
Senior Member |
|
|
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
|
|
|
|
| Re: Coyote Library Updates [message #77200 is a reply to message #62777] |
Tue, 09 August 2011 13:43 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
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.")
|
|
|
|
| Re: Coyote Library Updates [message #77202 is a reply to message #62777] |
Tue, 09 August 2011 12:47 |
Paul Van Delst[1]
Messages: 1157
Registered: April 2002
|
Senior Member |
|
|
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?
|
|
|
|
| Re: Coyote Library Updates [message #77204 is a reply to message #62777] |
Tue, 09 August 2011 10:27 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
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.")
|
|
|
|
| Re: Coyote Library Updates [message #77206 is a reply to message #77067] |
Tue, 09 August 2011 09:49 |
Paul Van Delst[1]
Messages: 1157
Registered: April 2002
|
Senior Member |
|
|
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
|
|
|
|
| Coyote Library Repository Changes [message #77353 is a reply to message #77200] |
Sat, 20 August 2011 08:37 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
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.")
|
|
|
|
| Re: Coyote Library Updates [message #81906 is a reply to message #62777] |
Fri, 09 November 2012 14:02 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Paul van Delst writes:
> The google repository browser. I just tried again and I see why I can
> only see bits and pieces of your tag directories. When I click on
> tags->coyote it lists a bunch of directories, but at the top it says
> "Sorry, truncated results. Use command line tools for complete view"
>
> On my screen, no 2.x or 3.x tagged version are visible if I use
> https://code.google.com/p/idl-coyote/source/browse/#svn%2Fta gs%2Fcoyote
>
> When I go directly to the repository URL I see everything,
> http://idl-coyote.googlecode.com/svn/tags/coyote/
>
> Phewph. I thought I was going nuts.
Well, heck. I always feel like I should delete all but the
last one anyway. I'm only keeping them around for you.
If you don't see 'em, let's get rid of 'em! ;-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thue. ("Perhaps thou speakest truth.")
|
|
|
|
| Re: Coyote Library Updates [message #81908 is a reply to message #62777] |
Fri, 09 November 2012 13:37 |
Paul Van Delst[1]
Messages: 1157
Registered: April 2002
|
Senior Member |
|
|
On 11/09/12 15:26, David Fanning wrote:
> Paul van Delst writes:
>
>> Oh. I guess what I meant to say is: where are the various v1.3.x -
>> v1.9.x tags?
>
> Still not sure what you mean. When I look at the repository
> with the repo-browser I find 69 tagged releases in the 1.x.x
> series, 16 in the 2.x.x series, and 4 in the 3.x.x series.
> That's a lot of releases, and I don't see any gaps between
> them.
>
>>> Anyway, the latest is 3.2.0, tagged today.
>>
>> Oh (again). No v2.x.x tags?
>
> ???? What software are you using to browse the repository?
The google repository browser. I just tried again and I see why I can
only see bits and pieces of your tag directories. When I click on
tags->coyote it lists a bunch of directories, but at the top it says
"Sorry, truncated results. Use command line tools for complete view"
On my screen, no 2.x or 3.x tagged version are visible if I use
https://code.google.com/p/idl-coyote/source/browse/#svn%2Fta gs%2Fcoyote
When I go directly to the repository URL I see everything,
http://idl-coyote.googlecode.com/svn/tags/coyote/
Phewph. I thought I was going nuts.
>
>> p.s. Thx for the tag creation. :o)
>
> You're welcome! :-)
>
> Cheers,
>
> David
>
>
>
|
|
|
|
| Re: Coyote Library Updates [message #81909 is a reply to message #62777] |
Fri, 09 November 2012 13:33 |
Michael Galloy
Messages: 1114
Registered: April 2006
|
Senior Member |
|
|
On 11/9/12 1:26 PM, David Fanning wrote:
> Paul van Delst writes:
>
>> Oh. I guess what I meant to say is: where are the various v1.3.x -
>> v1.9.x tags?
>
> Still not sure what you mean. When I look at the repository
> with the repo-browser I find 69 tagged releases in the 1.x.x
> series, 16 in the 2.x.x series, and 4 in the 3.x.x series.
> That's a lot of releases, and I don't see any gaps between
> them.
>
>>> Anyway, the latest is 3.2.0, tagged today.
>>
>> Oh (again). No v2.x.x tags?
>
> ???? What software are you using to browse the repository?
I see them all from the command line:
$ svn ls http://idl-coyote.googlecode.com/svn/tags/coyote
coyote_library_1.0.1/
coyote_library_1.0.10/
coyote_library_1.0.11/
coyote_library_1.0.2/
coyote_library_1.0.3/
coyote_library_1.0.4/
coyote_library_1.0.5/
coyote_library_1.0.6/
coyote_library_1.0.7/
coyote_library_1.0.8/
coyote_library_1.0.9/
coyote_library_1.1.0/
coyote_library_1.1.1/
coyote_library_1.1.2/
coyote_library_1.1.3/
coyote_library_1.1.4/
coyote_library_1.10.0/
coyote_library_1.10.1/
coyote_library_1.10.2/
coyote_library_1.10.3/
coyote_library_1.11.0/
coyote_library_1.11.1/
coyote_library_1.11.2/
coyote_library_1.11.3/
coyote_library_1.12.0/
coyote_library_1.12.2/
coyote_library_1.12.3/
coyote_library_1.12.4/
coyote_library_1.12.5/
coyote_library_1.12.6/
coyote_library_1.13.0/
coyote_library_1.13.1/
coyote_library_1.13.2/
coyote_library_1.14.0/
coyote_library_1.14.1/
coyote_library_1.2.0/
coyote_library_1.2.1/
coyote_library_1.2.2/
coyote_library_1.2.3/
coyote_library_1.2.5/
coyote_library_1.2.6/
coyote_library_1.2.7/
coyote_library_1.2.8/
coyote_library_1.2.9/
coyote_library_1.3.0/
coyote_library_1.3.1/
coyote_library_1.4/
coyote_library_1.4.1/
coyote_library_1.4.3/
coyote_library_1.4.4/
coyote_library_1.4.5/
coyote_library_1.4.6/
coyote_library_1.5/
coyote_library_1.5.1/
coyote_library_1.5.2/
coyote_library_1.6.0/
coyote_library_1.6.1/
coyote_library_1.6.2/
coyote_library_1.6.3/
coyote_library_1.6.4/
coyote_library_1.6.5/
coyote_library_1.6.6/
coyote_library_1.6.7/
coyote_library_1.7/
coyote_library_1.7.1/
coyote_library_1.8/
coyote_library_1.9/
coyote_library_1.9.1/
coyote_library_1.9.2/
coyote_library_2.0.0/
coyote_library_2.1.0/
coyote_library_2.1.1/
coyote_library_2.2.0/
coyote_library_2.3.0/
coyote_library_2.3.1/
coyote_library_2.4.0/
coyote_library_2.5.0/
coyote_library_2.5.1/
coyote_library_2.6.0/
coyote_library_2.6.1/
coyote_library_2.7.0/
coyote_library_2.7.1/
coyote_library_2.7.3/
coyote_library_2.7.4/
coyote_library_2.7.6/
coyote_library_2.8.0/
coyote_library_2.9.0/
coyote_library_3.0.0/
coyote_library_3.0.1/
coyote_library_3.1/
coyote_library_3.2.0/
Mike
--
Michael Galloy
www.michaelgalloy.com
Modern IDL: A Guide to IDL Programming (http://modernidl.idldev.com)
Research Mathematician
Tech-X Corporation
|
|
|
|
| Re: Coyote Library Updates [message #81910 is a reply to message #62777] |
Fri, 09 November 2012 12:26 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Paul van Delst writes:
> Oh. I guess what I meant to say is: where are the various v1.3.x -
> v1.9.x tags?
Still not sure what you mean. When I look at the repository
with the repo-browser I find 69 tagged releases in the 1.x.x
series, 16 in the 2.x.x series, and 4 in the 3.x.x series.
That's a lot of releases, and I don't see any gaps between
them.
>> Anyway, the latest is 3.2.0, tagged today.
>
> Oh (again). No v2.x.x tags?
???? What software are you using to browse the repository?
> p.s. Thx for the tag creation. :o)
You're welcome! :-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thue. ("Perhaps thou speakest truth.")
|
|
|
|
| Re: Coyote Library Updates [message #81911 is a reply to message #62777] |
Fri, 09 November 2012 12:08 |
Paul Van Delst[1]
Messages: 1157
Registered: April 2002
|
Senior Member |
|
|
Hello,
On 11/09/12 13:48, David Fanning wrote:
> Paul van Delst writes:
>
>> I went to
>> https://code.google.com/p/idl-coyote/source/browse/tags/coyo te/
>> but can't figure out what tag to export.
>>
>> Should I grab 1.14.1?
>>
>> I see 1.0.x and 1.1.x and 1.2.x tags, then it jumps to 1.10.x. The big
>> jump confuses me.... (sorry)
>
> Those big jumps are for you! I am following the
> advice you gave me about numbering conventions. :-)
Oh. I guess what I meant to say is: where are the various v1.3.x -
v1.9.x tags?
> Anyway, the latest is 3.2.0, tagged today.
Oh (again). No v2.x.x tags?
cheers,
paulv
p.s. Thx for the tag creation. :o)
|
|
|
|
|
|
| Re: Coyote Library Updates [message #81919 is a reply to message #62777] |
Fri, 09 November 2012 10:40 |
Paul Van Delst[1]
Messages: 1157
Registered: April 2002
|
Senior Member |
|
|
Hello,
I went to
https://code.google.com/p/idl-coyote/source/browse/tags/coyo te/
but can't figure out what tag to export.
Should I grab 1.14.1?
I see 1.0.x and 1.1.x and 1.2.x tags, then it jumps to 1.10.x. The big
jump confuses me.... (sorry)
cheers,
paulv
On 11/09/12 12:15, David Fanning wrote:
> Folks,
>
> A couple of changes to the Coyote Library that you may
> want to be aware of.
>
> The Number_Formatter program has been retired and is
> replaced by the cgNumber_Formatter program. This program
> has been updated to handle NaN and Inf values properly,
> and it now works MUCH better for numbers between 0.0001
> and 1.0. In this case, the number of decimals specified
> with the DECIMAL keyword is taken to mean the number of
> significant digits that should be displayed:
>
> IDL> a = [0.0123456, 0.000123456, !Values.F_NAN]
> IDL> Print, cgNumber_Formatter(a, Decimals=3)
> 0.0123 0.000123 NaN
>
> Also, the cgCheckForSymbols and the cgSymbol programs
> have been updated to handle superscripts and subscripts.
> The symbols \up and \down implement the !U and !D
> format codes, and reduce the size of the superscript or
> subscript by 0.62 percent. The symbols \exp and \sub
> implement !E and !I format codes and reduce the size
> of the superscript or subscript by 0.44 percent.
>
> IDL> cgPlot, cgDemoData(1), $
> XTitle='Distance ($\angstrom$$\up2$)', $
> YTitle='H$\subSubscript$ and B$\expSuperscript$', $
> Charsize=2.0
>
> Naturally, these work in PostScript files as well. :-)
>
> You can find these changes and others in the latest Coyote Library:
>
> http://www.idlcoyote.com/programs/zip_files/coyoteprograms.z ip
>
> Or, here:
>
> http://idl-coyote.googlecode.com/
>
> Cheers,
>
> David
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
