Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
Examine "Saved" IDL procedures now too!
Greetings! As a few people have been posting about, I have a library that allows you to manipulate IDL SAVE files. Up until now, this capacity has been limited to reading and writing IDL *variables* (data only). Allow me to announce the first major upgrade to my library, which allows you to read and translate saved IDL *procedures*. As of 2002 Mar 22, four new routines are included which can translate compiled procedures from SAVE files, back into human readable form. Now if you have lost the source code to a compiled save file, or if you just want to see how things work, you can translate the save file back to a format familiar to you! The main routine of interest is the simple driver routine called PROTRANS, which will translate compiled code from IDL SAVE files into and IDL-like format. As usual all files contain full documentation in their program headers. I have anticipated a few frequently asked questions too, so go ahead and read those. :-) As far as I am aware, PROTRANS (and underlying library routines PRODIS and PROREND) is capable of translating *any* saved procedure or function created by IDL 4, and IDL 5.0 through IDL 5.5, *except* that it does not handle compressed files. [ Although this is easily remedied by restoring and resaving in non-compressed form. ] *** In a separate development, I have also posted extensive documentation of the format of IDL save files (variables only). While I anticipate that the interest in this document will be essentially zero, I felt it was important to document the knowledge. This may especially help users from other languages to read and write IDL save files. Enjoy! Craig http://cow.physics.wisc.edu/~craigm/idl/idl.html (under Save Files) -- ------------------------------------------------------------ -------------- Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response ------------------------------------------------------------ --------------
Re: Examine "Saved" IDL procedures now too!
Craig Markwardt wrote: > > Greetings! As a few people have been posting about, I have a library > that allows you to manipulate IDL SAVE files. Up until now, this > capacity has been limited to reading and writing IDL *variables* (data > only). > > Allow me to announce the first major upgrade to my library, which > allows you to read and translate saved IDL *procedures*. > > As of 2002 Mar 22, four new routines are included which can translate > compiled procedures from SAVE files, back into human readable form. > Now if you have lost the source code to a compiled save file, or if > you just want to see how things work, you can translate the save file > back to a format familiar to you! > > The main routine of interest is the simple driver routine called > PROTRANS, which will translate compiled code from IDL SAVE files into > and IDL-like format. As usual all files contain full documentation in > their program headers. I have anticipated a few frequently asked > questions too, so go ahead and read those. :-) > > As far as I am aware, PROTRANS (and underlying library routines PRODIS > and PROREND) is capable of translating *any* saved procedure or > function created by IDL 4, and IDL 5.0 through IDL 5.5, *except* that > it does not handle compressed files. [ Although this is easily > remedied by restoring and resaving in non-compressed form. ] > > *** > > In a separate development, I have also posted extensive documentation > of the format of IDL save files (variables only). While I anticipate > that the interest in this document will be essentially zero, I felt it > was important to document the knowledge. This may especially help > users from other languages to read and write IDL save files. > > Enjoy! > > Craig > > http://cow.physics.wisc.edu/~craigm/idl/idl.html (under Save Files) GREAT !!! i will enjoy later best regards Reimar > > -- > ------------------------------------------------------------ -------------- > Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu > Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response > ------------------------------------------------------------ -------------- -- Reimar Bauer Institut fuer Stratosphaerische Chemie (ICG-I) Forschungszentrum Juelich email: R.Bauer@fz-juelich.de ------------------------------------------------------------ ------- a IDL library at ForschungsZentrum Juelich http://www.fz-juelich.de/icg/icg1/idl_icglib/idl_lib_intro.h tml ============================================================ =======
We are all eagerly waiting to see how this will develop. With all these rival products, like Matlab, giving out freely their file format.. and also the ability to create stand-alone executables, maybe this library will be the one which will give IDL a boost. I hope people will realize this opportunity and not get blinded by short- sighted thinking. It is after all: how many steps further can one think? One, two, ten? good job Craig!
To follow up on what GB implied, the saved-procedure part of the library is currently disabled, but the rest of the library is still fully functional. This is after a polite suggestion from a person at RSI. The essay on the save-file format is still on line too. I spent enough time on it, I want the information to be free! Yours, Craig gogosgogos@usa.net (GB Smith) writes: > We are all eagerly waiting to see how > this will develop. With all these rival > products, like Matlab, giving out freely > their file format.. and also the ability > to create stand-alone executables, maybe > this library will be the one which will > give IDL a boost. I hope people will realize > this opportunity and not get blinded by short- > sighted thinking. It is after all: how many > steps further can one think? One, two, ten? > > good job Craig! -- ------------------------------------------------------------ -------------- Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response ------------------------------------------------------------ --------------
Given that quite a few people invest time and effort into writing code for others for living, I don't feel good about this. Although I appreciate technical challenge, I have asked Craig before not to release his library. But I guess the urge for fame got the best of him :-( I am sure many people would love to be able to decompile commercial products into source code. Also known as hacking. This is what I think we are seeing here. I am sure it is far from impossible to, say, fish out IDL's license code from its binary and post the hack all over the internet, but I doubt it would be the right thing to do. I indeed agree that ability to make executables is what we all want but I don't think that this way we are any closer to that. And a lot of code that developers might not want to disclose is wide open now. Sorry, Pavel P.S. I do not make money writing IDL programs. "Craig Markwardt" <craigmnet@cow.physics.wisc.edu> wrote in message news:ony9gkeffb.fsf@cow.physics.wisc.edu... > > Greetings! As a few people have been posting about, I have a library > that allows you to manipulate IDL SAVE files. Up until now, this > capacity has been limited to reading and writing IDL *variables* (data > only). > > Allow me to announce the first major upgrade to my library, which > allows you to read and translate saved IDL *procedures*. > > As of 2002 Mar 22, four new routines are included which can translate > compiled procedures from SAVE files, back into human readable form. > Now if you have lost the source code to a compiled save file, or if > you just want to see how things work, you can translate the save file > back to a format familiar to you! > > The main routine of interest is the simple driver routine called > PROTRANS, which will translate compiled code from IDL SAVE files into > and IDL-like format. As usual all files contain full documentation in > their program headers. I have anticipated a few frequently asked > questions too, so go ahead and read those. :-) > > As far as I am aware, PROTRANS (and underlying library routines PRODIS > and PROREND) is capable of translating *any* saved procedure or > function created by IDL 4, and IDL 5.0 through IDL 5.5, *except* that > it does not handle compressed files. [ Although this is easily > remedied by restoring and resaving in non-compressed form. ] > > *** > > In a separate development, I have also posted extensive documentation > of the format of IDL save files (variables only). While I anticipate > that the interest in this document will be essentially zero, I felt it > was important to document the knowledge. This may especially help > users from other languages to read and write IDL save files. > > > Enjoy! > > Craig > > http://cow.physics.wisc.edu/~craigm/idl/idl.html (under Save Files) > > -- > ------------------------------------------------------------ -------------- > Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu > Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response > ------------------------------------------------------------ --------------
Pavel Romashkin wrote: > > Given that quite a few people invest time and effort into writing code for > others for living, I don't feel good about this. Although I appreciate > technical challenge, I have asked Craig before not to release his library. > But I guess the urge for fame got the best of him :-( > I am sure many people would love to be able to decompile commercial products > into source code. Also known as hacking. This is what I think we are seeing > here. > I indeed agree that ability to make executables is what we all want but I > don't think that this way we are any closer to that. And a lot of code that > developers might not want to disclose is wide open now. > Sorry, > Pavel > P.S. I do not make money writing IDL programs. I'm surprised that so few have responded to this momentous thread - it must truly be a Hot Potato! I disagree with Pavel. I can see a good use within my work area of being able to check just what code went into locally produced SAVE files. We have a terribly convoluted Configuration Management system forced upon us by civilian contractors, and IDL does not sit happily in it, what with it's propensity to pick up the first file matching a routine. Yes, there are nice Config man systems out there, but we don't have the choice in using them. I've debated Craig's work with Richard Cooke, President of RSI, today, but we ended up agreeing to disagree. Surely it's better for RSI to walk hand in hand with Craig now, rather than slap his wrist, as now that the IDL community knows that it is feasible to decode SAVE files of routines, some nefarious character is sure to emulate Craig's effort on the sly, and start a blackmarket that RSI has little control over. For all the Americans, I guess it's a bit like COLT - no one sues them because some idiot did the wrong thing with their product. There's honest folk, and there's not. Now that orta stir something... NB : I work for the Government, meaning I do not make money writing IDL programs either :-( Andrew Cool DSTO, Adelaide, Australia andrew.cool@dsto.defence.gov.au
On Mon, 25 Mar 2002, Pavel Romashkin wrote: > I am sure many people would love to be able to decompile commercial products > into source code. Also known as hacking. This is what I think we are seeing > here. Decompilers and other such tools have existed and been used for years. I think you are confusing the difference between the existence of a tool and the malicious use of a tool. Software licenses are what should prevent a user from maliciously hacking code. For those 'programmers-for-hire' that are annoyed by Craig's library, I suggest that you contact RSI. However, I doubt that RSI ever claimed the IDL sav file format was a secure way to distribute source code as they knew the source code was relatively easy to recover. > I am sure it is far from impossible to, say, fish out IDL's license code > from its binary and post the hack all over the internet, but I doubt it > would be the right thing to do. I agree it is wrong. Moreover, it would violate the IDL license agreement and therefore give RSI the opportunity to take legal action. > I indeed agree that ability to make executables is what we all want but I > don't think that this way we are any closer to that. And a lot of code that > developers might not want to disclose is wide open now. I honestly hope this isn't the case. Nevertheless, most developers should be distributing license agreements or have contracts with customers that clearly state the software terms of use. Cheers, Randall
Good Morning All, As someone who does try to make money writing IDL code, here is my opinion. First, I think this is just a variation of the old "open source"/"closed source" debate. Second, shouldn't the question really be "Where do we want IDL to go and does this hurt?". I have been writing for a long time that everyone (RSI included) would benefit from a large third party IDL code community. As long as we rely only on RSI and a few developers (like Craig Markwardt who has some fantastic curve fitting routines) the capabilities of IDL will only expand slowly. Like it or not, the major motivator of the world is making money. Therefore, if we want more capability from IDL, then people (other than RSI) need to be able to make money from it. Being able to decompile save files really hurts this since it exposes all your techniques to the world. Wasn't it Sun-Tsu that said "If someone shows you your weakness, thank them?". What this is going to do is force RSI to write some obfuscator for the save files just like Java. So in the long run, this is a necessary development. -Ronn -- Ronn Kling KRS, inc. email: ronn@rlkling.com "Application Development with IDL"ï¿½ programming book updated for IDL5.5! "Calling C from IDL, Using DLM's to extend your IDL code. http://www.rlkling.com/
ronn kling wrote: > > Good Morning All, > > As someone who does try to make money writing IDL code, here is my opinion. > > First, I think this is just a variation of the old "open source"/"closed > source" debate. Yes you are right and IDL is a commercial product (not open source). Some of us produces open source with IDL but some others are not. I am most interested into the data interface to the sav files. 1) I'll like to write this binary by some of my instruments and if so I don't need any reading routines written for those files. This was for me a reason to look at these files too but Craig was much faster. 2) Sometimes it makes working with sav files much easier to know before reading what is saved there. 3) During writing you could select what is written, why not for reading too? Ok now we are at this point that it seems to be illegal to get these information. To solve this problem I'll suggest that's Craigs sav handling routines should build into the RSI IDL with his Copyright notice. (About payment they should discuss) regards Reimar -- Reimar Bauer Institut fuer Stratosphaerische Chemie (ICG-I) Forschungszentrum Juelich email: R.Bauer@fz-juelich.de ------------------------------------------------------------ ------- a IDL library at ForschungsZentrum Juelich http://www.fz-juelich.de/icg/icg1/idl_icglib/idl_lib_intro.h tml ============================================================ =======
Randall Skelton wrote: > I honestly hope this isn't the case. Nevertheless, most developers should > be distributing license agreements or have contracts with customers that > clearly state the software terms of use. This is got to be a sad joke. After frequenting MS Access newsgroup I know exactly what developers think about others seeing their code that they did not want available to the entire world. They get not just mad, but MAD! And I have yet to see an end user license agreement that is not being violated every single day, OSs being the prime example. Like Ronn said, this had to happen. Anyone who ever opened a SAV file in an editor saw that it can be hacked. Let's see what is going to come out of this. Maybe RSI will now offer Craig a job and we'll get one of us among them? Or would it be losing one of us to them? Pavel
"Pavel A. Romashkin" wrote: > > Randall Skelton wrote: > >> I honestly hope this isn't the case. Nevertheless, most developers should >> be distributing license agreements or have contracts with customers that >> clearly state the software terms of use. > > This is got to be a sad joke. After frequenting MS Access newsgroup I > know exactly what developers think about others seeing their code that > they did not want available to the entire world. They get not just mad, > but MAD! And I have yet to see an end user license agreement that is not > being violated every single day, OSs being the prime example. > Like Ronn said, this had to happen. Anyone who ever opened a SAV file in > an editor saw that it can be hacked. Let's see what is going to come out > of this. Maybe RSI will now offer Craig a job and we'll get one of us > among them? Or would it be losing one of us to them? > Pavel Since I'm not at all familiar with the methods one uses to distribute proprietary IDL code, can I ask how is it done? If SAV files are the popular choice, why? Particularly if they're so easy to hack (and, as another poster pointed out, it doesn't look like RSI made any statements about SAV file security, or lack thereof, for distributing code.) As for the sad folk that have a predisposition to ignore software license agreements, it seems to me they are always going to be around - both the sophisticated and the brain-dead. If a software developer makes it easy for people to hack code, then of course more people will do it. If one is really serious about distributing and protecting proprietary code, I would think a not insignificant amount of time and resources would need to be dedicated to this end - and that would more than likely involve legal resources. Anything less would seem to be the equivalent of finger-crossing and hoping for the best. All the above is purely my badly informed personal opinion. :o) paulv -- Paul van Delst Religious and cultural CIMSS @ NOAA/NCEP purity is a fundamentalist Ph: (301)763-8000 x7274 fantasy Fax:(301)763-8545 V.S.Naipaul
On Tue, 26 Mar 2002, Paul van Delst wrote: [snip] > As for the sad folk that have a predisposition to ignore software license agreements, it seems > to me they are always going to be around - both the sophisticated and the brain-dead. If a > software developer makes it easy for people to hack code, then of course more people will do > it. If one is really serious about distributing and protecting proprietary code, I would think > a not insignificant amount of time and resources would need to be dedicated to this end - and > that would more than likely involve legal resources. Anything less would seem to be the > equivalent of finger-crossing and hoping for the best. > > All the above is purely my badly informed personal opinion. :o) I agree. The only way for this to be resolved is for RSI to step up and define a system whereby IDL code can be massaged into a somewhat tamper-resistant form. What about using some sort of key-generated encryption scheme that developers need to buy into? This way, every registered 'IDL developer' would get a a strong encryption tool and a set of keys to encrypt their source. RSI would be responsible for the maintenance and security of both the encryption tool and keys. When a user gets one of these encrypted files from a developer, they simply place it in the IDL path like any other .pro file and when needed IDL would auto-magically decrypt the code into a compiled procedure, function or object set. Assuming that RSI uses a modern, strong encryption scheme, the chances of the source file being decoded would be small. Alas, depending on how RSI represents the compiled functions, procedures and objects in IDL's working memory, it may still be possible to recover the the source... Comments? Randall
Paul van Delst (paul.vandelst@noaa.gov) writes: > All the above is purely my badly informed personal opinion. :o) I haven't weighted in on this yet because--Lord knows--I keep a high enough profile around here and I've learned that it almost never does me any good to take a stand on a controversial issue. But I've been getting some private e-mail wondering what I think about all of this, so I thought I should come public. I've known that Craig has had the ability to re-constitute IDL save files into procedures and functions for some time now. But I'm sorry he made the news public. I've known Craig for a long time through this newsgroup and via e-mail. He has always been the most ethical and positive person with respect to RSI. (His only quirk, as far as I know, is holding on to a copy of IDL 4.0.) I'm certain he has his reasons for making this announcement and releasing information regarding IDL save files. I haven't talked to him about this, nor do I know what his reasons are. I am not one of those IDL consultants who is affected by this decision. I was a long and early advocate of open software, primarily because I first saw it (when I worked for RSI) as an opportunity to sell more software, and later because it enabled me to sell more books and consulting, which is where the real money comes from, such as it is. I've never sold a single IDL save file in the 10+ years I've been doing this kind of work. But I have to admit when I read the announcement the other day I was awfully conflicted. One the one hand I can see the value of being able to open up IDL save files. On the other hand, those folks who wrote ENVI have done some amazing work. I think they deserve to have that work proprietary, if that is what they want. I know I'm always annoyed to learn that someone is photocopying my book. It happens, I know. But it is stealing--if that is not too harsh a word--someone's intellectual toil, too. (I seem to have a similar conversation every month or so with my children with regard to music available on the Internet. Yes, someone always seems to get obscenely rich when they only know three chords, but it is intellectual property all the same.) So, when the announcement was made I felt so badly I didn't even go download the darn thing. It took me three days to get over my ethical qualms about really wanting to have a peak at a couple of things in ENVI. By then, of course, the critical piece of software had been removed. I've made several discrete inquiries about whether someone or other had it, but honestly, I can't find anyone who has downloaded it. I'm not sure what that has to say about our little community, but it cheers me up nonetheless. No one, as far as I know, thought the IDL save file format was the 128-bit encryption method to beat all others. It was just a convenient way to keep a couple of things to yourself. I'm sorry to see it compromised. Cheers, David -- David W. Fanning, Ph.D. Fanning Software Consulting Phone: 970-221-0438, E-mail: david@dfanning.com Coyote's Guide to IDL Programming: http://www.dfanning.com/ Toll-Free IDL Book Orders: 1-888-461-0155
David Fanning wrote: > > Paul van Delst (paul.vandelst@noaa.gov) writes: > >> All the above is purely my badly informed personal opinion. :o) > > I haven't weighted in on this yet because--Lord knows--I > keep a high enough profile around here and I've learned that > it almost never does me any good to take a stand on a > controversial issue. But I've been getting some private > e-mail wondering what I think about all of this, so I thought > I should come public. > > I've known that Craig has had the ability to re-constitute > IDL save files into procedures and functions for some > time now. But I'm sorry he made the news public. I've > known Craig for a long time through this newsgroup and > via e-mail. He has always been the most ethical and > positive person with respect to RSI. (His only quirk, as > far as I know, is holding on to a copy of IDL 4.0.) I'm > certain he has his reasons for making this announcement > and releasing information regarding IDL save files. I > haven't talked to him about this, nor do I know what > his reasons are. > > I am not one of those IDL consultants who is affected > by this decision. I was a long and early advocate of > open software, primarily because I first saw it (when > I worked for RSI) as an opportunity to sell more software, > and later because it enabled me to sell more books and > consulting, which is where the real money comes from, > such as it is. I've never sold a single IDL save file > in the 10+ years I've been doing this kind of work. > > But I have to admit when I read the announcement the > other day I was awfully conflicted. One the one hand > I can see the value of being able to open up IDL save > files. On the other hand, those folks who wrote ENVI > have done some amazing work. I think they deserve to > have that work proprietary, if that is what they want. > I know I'm always annoyed to learn that someone is > photocopying my book. It happens, I know. But it is > stealing--if that is not too harsh a word--someone's > intellectual toil, too. (I seem to have a similar > conversation every month or so with my children with > regard to music available on the Internet. Yes, someone > always seems to get obscenely rich when they only know > three chords, but it is intellectual property all the > same.) > > So, when the announcement was made I felt so badly > I didn't even go download the darn thing. It took > me three days to get over my ethical qualms about > really wanting to have a peak at a couple of things > in ENVI. By then, of course, the critical piece of > software had been removed. I've made several discrete > inquiries about whether someone or other had it, but > honestly, I can't find anyone who has downloaded it. > I'm not sure what that has to say about our little > community, but it cheers me up nonetheless. > > No one, as far as I know, thought the IDL save file > format was the 128-bit encryption method to beat all > others. It was just a convenient way to keep a couple > of things to yourself. I'm sorry to see it compromised. > > Cheers, > > David Dear David, we all do like or love IDL very much and I think we always like to pay money for it. If you spent lot's of time solving problems by programming in IDL you will become closer and closer to internals. Some of us in this group may be more experts as some people which sells the software. A lot of our input is recognized as feature request and are included in newer versions. This all is good for us and for the products of idl. But where are the limits?! A well written routine needs no comments it tells all itself and in some cases the names of the routines and the parameter list tells enough about what it is doing and how it is to use. (I won't tell here more about official routines which reads out all this information from a sav routine without source) Should all of this be terrible coded? Before the posting of Craig I was never thinking about that's the procedure SAV file Format and the data SAV File format are the same family. This is a good understandable reason why the data format was not described. I don't have this critical code and I am not interested in getting it and I don't spend time to program such a thing. Reimar -- Reimar Bauer Institut fuer Stratosphaerische Chemie (ICG-I) Forschungszentrum Juelich email: R.Bauer@fz-juelich.de ------------------------------------------------------------ ------- a IDL library at ForschungsZentrum Juelich http://www.fz-juelich.de/icg/icg1/idl_icglib/idl_lib_intro.h tml ============================================================ =======
David Fanning wrote: > > Paul van Delst (paul.vandelst@noaa.gov) writes: > >> All the above is purely my badly informed personal opinion. :o) > > I haven't weighted in on this yet because--Lord knows--I > keep a high enough profile around here and I've learned that > it almost never does me any good to take a stand on a > controversial issue. But I've been getting some private > e-mail wondering what I think about all of this, so I thought > I should come public. > > I've known that Craig has had the ability to re-constitute > IDL save files into procedures and functions for some > time now. But I'm sorry he made the news public. I've > known Craig for a long time through this newsgroup and > via e-mail. He has always been the most ethical and > positive person with respect to RSI. (His only quirk, as > far as I know, is holding on to a copy of IDL 4.0.) I'm > certain he has his reasons for making this announcement > and releasing information regarding IDL save files. I > haven't talked to him about this, nor do I know what > his reasons are. > > I am not one of those IDL consultants who is affected > by this decision. I was a long and early advocate of > open software, primarily because I first saw it (when > I worked for RSI) as an opportunity to sell more software, > and later because it enabled me to sell more books and > consulting, which is where the real money comes from, > such as it is. I've never sold a single IDL save file > in the 10+ years I've been doing this kind of work. > > But I have to admit when I read the announcement the > other day I was awfully conflicted. One the one hand > I can see the value of being able to open up IDL save > files. On the other hand, those folks who wrote ENVI > have done some amazing work. I think they deserve to > have that work proprietary, if that is what they want. > I know I'm always annoyed to learn that someone is > photocopying my book. It happens, I know. But it is > stealing--if that is not too harsh a word--someone's > intellectual toil, too. (I seem to have a similar > conversation every month or so with my children with > regard to music available on the Internet. Yes, someone > always seems to get obscenely rich when they only know > three chords, but it is intellectual property all the > same.) > > So, when the announcement was made I felt so badly > I didn't even go download the darn thing. It took > me three days to get over my ethical qualms about > really wanting to have a peak at a couple of things > in ENVI. By then, of course, the critical piece of > software had been removed. I've made several discrete > inquiries about whether someone or other had it, but > honestly, I can't find anyone who has downloaded it. > I'm not sure what that has to say about our little > community, but it cheers me up nonetheless. > > No one, as far as I know, thought the IDL save file > format was the 128-bit encryption method to beat all > others. It was just a convenient way to keep a couple > of things to yourself. I'm sorry to see it compromised. > > Cheers, > > David > > -- > David W. Fanning, Ph.D. > Fanning Software Consulting > Phone: 970-221-0438, E-mail: david@dfanning.com > Coyote's Guide to IDL Programming: http://www.dfanning.com/ > Toll-Free IDL Book Orders: 1-888-461-0155 Dear David, we all do like or love IDL very much and I think we always like to pay money for it. If you spent lot's of time solving problems by programming in IDL you will become closer and closer to internals. Some of us in this group may be more experts as some people which sells the software. A lot of our input is recognized as feature request and are included in newer versions. This all is good for us and for the products of idl. But where are the limits?! A well written routine needs no comments it tells all itself and in some cases the names of the routines and the parameter list tells enough about what it is doing and how it is to use. (I won't tell here more about official routines which reads out all this information from a sav routine without source) Should all of this be terrible coded? Before the posting of Craig I was never thinking about that's the procedure SAV file Format and the data SAV File format are the same family. This is a good understandable reason why the data format was not described. I don't have this critical code and I am not interested in getting it and I don't spend time to program such a thing. But I believe no one could prohibite someone to do it for himself. The publishing of this could be a problem. Reimar -- Reimar Bauer Institut fuer Stratosphaerische Chemie (ICG-I) Forschungszentrum Juelich email: R.Bauer@fz-juelich.de ------------------------------------------------------------ ------- a IDL library at ForschungsZentrum Juelich http://www.fz-juelich.de/icg/icg1/idl_icglib/idl_lib_intro.h tml ============================================================ =======
David Fanning <david@dfanning.com> wrote in message news:<MPG.170af3c1b3928797989852@news.frii.com>... > Paul van Delst (paul.vandelst@noaa.gov) writes: > >> All the above is purely my badly informed personal opinion. :o) > > I haven't weighted in on this yet because--Lord knows--I > keep a high enough profile around here and I've learned that > it almost never does me any good to take a stand on a > controversial issue. But I've been getting some private > e-mail wondering what I think about all of this, so I thought > I should come public. Hi David and the rest of the newsgroup. Thanks for your viewpoint. Allow me to weigh in, and also to say where things stand now. The files which allow to translate IDL code in the save format to a human readable form have been removed, and won't be returned. [ The crucial file was removed on Friday after a polite request from one employee at RSI. ] For the handful of people that did download it, none of them received a fully functional version as downloaded. I have to say that if RSI really believes that it can rely on its "save" format to hide code, then it is probably mistaken. In particular, the requirement to store both commercial products, and users' original code, in the same format means that they worked a compromise. A compromise that makes it difficult for users to get at their own data, but also leaves the security of commercial code questionable. My guess is that this will change in the future. [ I have no inside information on this. ] This whole issue is aggravated by the stratified price points at which the IDL and associated products sell. I am not convinced at the moral level of the argument that we should be "protected" from the algorithms in the software that we purchase. Algorithms are one thing that cannot be copyrighted. As David said in his own email, he ended up being curious about a few things in ENVI. :-) I figured that there would be some controversy over the issue, but I had not anticipated the level of "polarization" that occurred on the newsgroup. Let me apologize to people who felt their livelihood threatened. I also did not anticipate the swiftness of RSI/Kodak's response, nor the level to which it escalated. The amount of payoff for this one little program is small compared to the burden that was ultimately thrust at me, so I capitulated. I know a few people have tried to support me in emails to Richard Cooke, the CEO of RSI. Thanks, but it's time to move on to other things. Let me say that overall Mr. Cooke has been appreciative and understanding of the other work I, and others in the community, have done with IDL, and wanted to encourage it (with more than just words). There may be some dialog there to explore. To the everyday user, the IDL save format has gotten no more or less useful, or secure. Save files are still a convenient and fast way to save data and procedures, and for the foreseeable future the CMSVLIB library for "save" formatted *data* remains online. Yours, Craig [ Posting from Google at the moment. Not sure if the "cow" news connection has been shut down because of this or not. ]
I for one would have been glad to have such a tool. Many of the most useful programs I have developed started with a section, or more, of RSI's supplied ".pro" code. Increasingly, it seems, RSI is distributing functions and procedures as .sav files, and of course envi is distributed this way too. The takes away much of the utility of these programs for me. I pay for the programs, and associated fees, and gladly, because they allow me to do my work. But now this functionality is being reduced, via these .sav files. Seems to me that if things continue in this direction, languages like Python will become a more desirable alternative. Michael
Michael Lefsky (lefsky@fsl.orst.edu) writes: > I for one would have been glad to have such a tool. Many of the most > useful programs I have developed started with a section, or more, of > RSI's supplied ".pro" code. Increasingly, it seems, RSI is > distributing functions and procedures as .sav files, and of course > envi is distributed this way too. The takes away much of the utility > of these programs for me. I pay for the programs, and associated > fees, and gladly, because they allow me to do my work. But now this > functionality is being reduced, via these .sav files. Seems to me that > if things continue in this direction, languages like Python will > become a more desirable alternative. Off the top of my head the only thing I can think of (besides ENVI, which is in another category altogether) that RSI ships as save files are those damn Live Tools. I'm pretty sure no one in his right mind wants to look at that code. :-) Cheers, David -- David W. Fanning, Ph.D. Fanning Software Consulting Phone: 970-221-0438, E-mail: david@dfanning.com Coyote's Guide to IDL Programming: http://www.dfanning.com/ Toll-Free IDL Book Orders: 1-888-461-0155
See below for small correction ... David Fanning <david@dfanning.com> wrote in message news:<MPG.171ec2cfec4185b3989882@news.frii.com>... > Michael Lefsky (lefsky@fsl.orst.edu) writes: > >> I for one would have been glad to have such a tool. Many of the most >> useful programs I have developed started with a section, or more, of >> RSI's supplied ".pro" code. Increasingly, it seems, RSI is >> distributing functions and procedures as .sav files, and of course >> envi is distributed this way too. The takes away much of the utility >> of these programs for me. I pay for the programs, and associated >> fees, and gladly, because they allow me to do my work. But now this >> functionality is being reduced, via these .sav files. Seems to me that >> if things continue in this direction, languages like Python will >> become a more desirable alternative. > > Off the top of my head the only thing I can think of > (besides ENVI, which is in another category altogether) > that RSI ships as save files are those damn Live Tools. > I'm pretty sure no one in his ... or her ... > right mind wants to look > at that code. :-) > > Cheers, > > David ... which we attribute to Monty Python -- Life of Brian :-)
How cruel. Oh David. Don't you use Live Tools? Pavel P.S. I am expecting an angry phone call within the next 10 minutes :-) David Fanning wrote: > > Off the top of my head the only thing I can think of > (besides ENVI, which is in another category altogether) > that RSI ships as save files are those damn Live Tools. > I'm pretty sure no one in his right mind wants to look > at that code. :-) > > Cheers, > > David