Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
"Liam Gumley" <Liam.Gumley@ssec.wisc.edu> writes: > A particularly interesting feature of IDL 6.0 is the IDL Virtual Machine, > which will allow developers to distribute compiled cross-platform > applications that do not require IDL to run. Liam-- You're right this is an interesting development. This may help get more IDL applications distributed, which I'm sure is the goal of RSI. But the virtual machine is significantly less interesting to me on account of the fact that EXECUTE() is disabled: http://www.rsinc.com/idl/idlvm_faq.asp#runtime There are a couple of key places in my code where EXECUTE() is integral to the operation of the algorithm, and those would not transfer over to the IDL VM. Craig -- ------------------------------------------------------------ -------------- Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response ------------------------------------------------------------ --------------
"Liam Gumley" <Liam.Gumley@ssec.wisc.edu> wrote in message news:bdf0ei$oce$1@news.doit.wisc.edu... > A particularly interesting feature of IDL 6.0 is the IDL Virtual Machine, > which will allow developers to distribute compiled cross-platform > applications that do not require IDL to run. > > For more information: > > http://www.rsinc.com/idl/idlvm_faq.asp I just received the following clarification from someone in the know at RSI: "A better way to state this is that the applications do not require a runtime or full IDL *license* to run. IDL (in the form of the idlrt.exe and associated DLMs) is still required." So there you go. Cheers, Liam. Practical IDL Programming http://www.gumley.com/
"Craig Markwardt" <craigmnet@cow.physics.wisc.edu> wrote in message news:onptl0g9wi.fsf@cow.physics.wisc.edu... > > "Liam Gumley" <Liam.Gumley@ssec.wisc.edu> writes: >> A particularly interesting feature of IDL 6.0 is the IDL Virtual Machine, >> which will allow developers to distribute compiled cross-platform >> applications that do not require IDL to run. > > Liam-- > > You're right this is an interesting development. This may help get > more IDL applications distributed, which I'm sure is the goal of RSI. > But the virtual machine is significantly less interesting to me on > account of the fact that EXECUTE() is disabled: > > http://www.rsinc.com/idl/idlvm_faq.asp#runtime > > There are a couple of key places in my code where EXECUTE() is > integral to the operation of the algorithm, and those would not > transfer over to the IDL VM. I wonder why EXECUTE is not allowed? Cheers, Liam. Practical IDL Programming http://www.gumley.com/
Liam Gumley writes: > I wonder why EXECUTE is not allowed? Don't know. Maybe giving away the module that allows this would be giving away the store. But I was looking at some of the code that I think I could use with the VM and I was discouraged to see how much of it depends on EXECUTE. :-( Cheers, David -- David W. Fanning, Ph.D. Fanning Software Consulting, Inc. 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
Liam, I think they want to avoid people writing their own idlde. If you have execute, then you could theoretically read in from a commadn line, reform an IDL command an d use the execute function to get your results. All that for free. :-) No wonder, it is not available. But thats ok to me. I just have a few gui apps that I would like to use on my laptop when I cannot be connected to the license manager... Haje "Liam Gumley" <Liam.Gumley@ssec.wisc.edu> wrote in message news:bdf3fe$q2j$1@news.doit.wisc.edu... > "Craig Markwardt" <craigmnet@cow.physics.wisc.edu> wrote in message > news:onptl0g9wi.fsf@cow.physics.wisc.edu... >> >> "Liam Gumley" <Liam.Gumley@ssec.wisc.edu> writes: >>> A particularly interesting feature of IDL 6.0 is the IDL Virtual > Machine, >>> which will allow developers to distribute compiled cross-platform >>> applications that do not require IDL to run. >> >> Liam-- >> >> You're right this is an interesting development. This may help get >> more IDL applications distributed, which I'm sure is the goal of RSI. >> But the virtual machine is significantly less interesting to me on >> account of the fact that EXECUTE() is disabled: >> >> http://www.rsinc.com/idl/idlvm_faq.asp#runtime >> >> There are a couple of key places in my code where EXECUTE() is >> integral to the operation of the algorithm, and those would not >> transfer over to the IDL VM. > > I wonder why EXECUTE is not allowed? > > Cheers, > Liam. > Practical IDL Programming > http://www.gumley.com/ > >
Liam Gumley wrote: > "Craig Markwardt" <craigmnet@cow.physics.wisc.edu> wrote in message > news:onptl0g9wi.fsf@cow.physics.wisc.edu... >> >> "Liam Gumley" <Liam.Gumley@ssec.wisc.edu> writes: >>> A particularly interesting feature of IDL 6.0 is the IDL Virtual > Machine, >>> which will allow developers to distribute compiled cross-platform >>> applications that do not require IDL to run. >> >> Liam-- >> >> You're right this is an interesting development. This may help get >> more IDL applications distributed, which I'm sure is the goal of RSI. >> But the virtual machine is significantly less interesting to me on >> account of the fact that EXECUTE() is disabled: >> >> http://www.rsinc.com/idl/idlvm_faq.asp#runtime >> >> There are a couple of key places in my code where EXECUTE() is >> integral to the operation of the algorithm, and those would not >> transfer over to the IDL VM. > > I wonder why EXECUTE is not allowed? With execute you can easily build in the vm mode an idl development tool. We have only a small amount of routines which could not be used and one important of them is the time_series_sync. So if executable is important for us, we have to think on rewriting of this routine. But this was already known before because I have often used a runtime license. Reimar > > Cheers, > Liam. > Practical IDL Programming > http://www.gumley.com/ -- Forschungszentrum Juelich email: R.Bauer@fz-juelich.de http://www.fz-juelich.de/icg/icg-i/ ============================================================ ====== a IDL library at ForschungsZentrum Juelich http://www.fz-juelich.de/icg/icg-i/idl_icglib/idl_lib_intro. html
On Thu, 26 Jun 2003 08:28:47 -0700, Liam Gumley wrote: > "Craig Markwardt" <craigmnet@cow.physics.wisc.edu> wrote in message > news:onptl0g9wi.fsf@cow.physics.wisc.edu... >> >> "Liam Gumley" <Liam.Gumley@ssec.wisc.edu> writes: >>> A particularly interesting feature of IDL 6.0 is the IDL Virtual > Machine, >>> which will allow developers to distribute compiled cross-platform >>> applications that do not require IDL to run. >> >> Liam-- >> >> You're right this is an interesting development. This may help get >> more IDL applications distributed, which I'm sure is the goal of RSI. >> But the virtual machine is significantly less interesting to me on >> account of the fact that EXECUTE() is disabled: >> >> http://www.rsinc.com/idl/idlvm_faq.asp#runtime >> >> There are a couple of key places in my code where EXECUTE() is integral >> to the operation of the algorithm, and those would not transfer over to >> the IDL VM. > > I wonder why EXECUTE is not allowed? > Presumably for the same reason that uncompiled .pro routines can't be run with the VM: it doesn't include the byte-code compiler. I'd suspect that EXECUTE works by calling the very same compiler at run-time. If it did include the compiler, the VM could easily be turned into a full-fledged copy of IDL! The CALL_* routines still work because they are only allowed to call routines which are compiled (either natively in IDL, or in the .sav file itself). That said, there are lots of uses of EXECUTE which are no longer really necessary in IDL 6.0, e.g., building variable-length argument lists of dimensions for various routines (I've noticed Craig using that trick a lot). Since the VM will only run .sav files compiled with IDLv6.0, there's no need to hang onto these old constructions for compatibility's sake. Perhaps people could list their typical uses of EXECUTE and we could consider ways to eliminate them? JD
JD Smith writes: > That said, there are lots of uses of EXECUTE which are no longer > really necessary in IDL 6.0, e.g., building variable-length argument > lists of dimensions for various routines (I've noticed Craig using > that trick a lot). Since the VM will only run .sav files compiled > with IDLv6.0, there's no need to hang onto these old constructions for > compatibility's sake. What!? And get rid of that old IDL 4.0 license Craig has hanging around still. Say it ain't so, Craig! Don't do it! Cheers, David -- David W. Fanning, Ph.D. Fanning Software Consulting, Inc. 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
JD Smith wrote: > On Thu, 26 Jun 2003 08:28:47 -0700, Liam Gumley wrote: > >> "Craig Markwardt" <craigmnet@cow.physics.wisc.edu> wrote in message >> news:onptl0g9wi.fsf@cow.physics.wisc.edu... >>> >>> "Liam Gumley" <Liam.Gumley@ssec.wisc.edu> writes: >>>> A particularly interesting feature of IDL 6.0 is the IDL Virtual >> Machine, >>>> which will allow developers to distribute compiled cross-platform >>>> applications that do not require IDL to run. >>> >>> Liam-- >>> >>> You're right this is an interesting development. This may help get >>> more IDL applications distributed, which I'm sure is the goal of RSI. >>> But the virtual machine is significantly less interesting to me on >>> account of the fact that EXECUTE() is disabled: >>> >>> http://www.rsinc.com/idl/idlvm_faq.asp#runtime >>> >>> There are a couple of key places in my code where EXECUTE() is integral >>> to the operation of the algorithm, and those would not transfer over to >>> the IDL VM. >> >> I wonder why EXECUTE is not allowed? >> > > Presumably for the same reason that uncompiled .pro routines can't be > run with the VM: it doesn't include the byte-code compiler. I'd > suspect that EXECUTE works by calling the very same compiler at > run-time. If it did include the compiler, the VM could easily be > turned into a full-fledged copy of IDL! The CALL_* routines still > work because they are only allowed to call routines which are compiled > (either natively in IDL, or in the .sav file itself). > > That said, there are lots of uses of EXECUTE which are no longer > really necessary in IDL 6.0, e.g., building variable-length argument > lists of dimensions for various routines (I've noticed Craig using > that trick a lot). Since the VM will only run .sav files compiled > with IDLv6.0, there's no need to hang onto these old constructions for > compatibility's sake. Perhaps people could list their typical uses of > EXECUTE and we could consider ways to eliminate them? > > JD I did a few days ago a feature request to remove all EXECUTEs from die idl standard library. You can do a grep at rsi/idl/lib. There are some important routines too which you can't use if you plan to build a vm. Reimar -- Forschungszentrum Juelich email: R.Bauer@fz-juelich.de http://www.fz-juelich.de/icg/icg-i/ ============================================================ ====== a IDL library at ForschungsZentrum Juelich http://www.fz-juelich.de/icg/icg-i/idl_icglib/idl_lib_intro. html
JD Smith <jdsmith@as.arizona.edu> writes: > > That said, there are lots of uses of EXECUTE which are no longer > really necessary in IDL 6.0, e.g., building variable-length argument > lists of dimensions for various routines (I've noticed Craig using > that trick a lot). Since the VM will only run .sav files compiled > with IDLv6.0, there's no need to hang onto these old constructions for > compatibility's sake. Perhaps people could list their typical uses of > EXECUTE and we could consider ways to eliminate them? I generally try to avoid EXECUTE(), but end up using it in several different ways. One is to handle the stupid dimension-list behavior of REBIN, but that may be fixed in newer versions of IDL. Another is allowing users to enter expressions to be evaluated. This includes fitting routines like MPFIT (parameter constraints), MPFITEXPR and CHEBCOEF. I don't know a way of evaluating a user-function without EXECUTE. There is a more esoteric set of routines which uses EXECUTE() to extract a particular argument from an argument list. For example, if my routine is defined as: pro mypro, x1, x2, x3, x4, x5, x6, x7, x8, x9, x10, ... then one can use EXECUTE to pull out each of the x{i} arguments without writing testing each one manually (eg CMRESTORE, FXBREADM, PRINTLOG, TRANSREAD). A final way is to make complex expressions which I couldn't figure any other elegant way to do. For example, constructing a template structure in TRANSREAD. I fully admit that the IDL VM sounds like a really interesting way of getting more people to use IDL software, and I'm sure that's why RSI developed it. It will lower the barrier for distribution of IDL-related packages, which RSI probably hopes will drive more sales when package recipients realize how great IDL is. *BUT*, I think developers should consider the IDL VM as a separate platform to develop for. It requires more discipline to avoid EXECUTE(), more careful checking that supporting library routines (and as Reimar points out, event IDL standard library!) don't trespass either. It means that existing code can't be pressed immediately into service without vetting it, and some functionality that requires EXECUTE() may need to be stripped away. This may or may not have significant costs. For these reasons, I don't think the IDL VM will be a big hit. It will be nice, but not big. Craig -- ------------------------------------------------------------ -------------- Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response ------------------------------------------------------------ --------------
On Thu, 26 Jun 2003 14:19:53 -0700, Reimar Bauer wrote: > JD Smith wrote: > >> On Thu, 26 Jun 2003 08:28:47 -0700, Liam Gumley wrote: >> >>> "Craig Markwardt" <craigmnet@cow.physics.wisc.edu> wrote in message >>> news:onptl0g9wi.fsf@cow.physics.wisc.edu... >>>> >>>> "Liam Gumley" <Liam.Gumley@ssec.wisc.edu> writes: >>>> > A particularly interesting feature of IDL 6.0 is the IDL Virtual >>> Machine, >>>> > which will allow developers to distribute compiled cross-platform >>>> > applications that do not require IDL to run. >>>> >>>> Liam-- >>>> >>>> You're right this is an interesting development. This may help get >>>> more IDL applications distributed, which I'm sure is the goal of RSI. >>>> But the virtual machine is significantly less interesting to me on >>>> account of the fact that EXECUTE() is disabled: >>>> >>>> http://www.rsinc.com/idl/idlvm_faq.asp#runtime >>>> >>>> There are a couple of key places in my code where EXECUTE() is >>>> integral to the operation of the algorithm, and those would not >>>> transfer over to the IDL VM. >>> >>> I wonder why EXECUTE is not allowed? >>> >>> >> Presumably for the same reason that uncompiled .pro routines can't be >> run with the VM: it doesn't include the byte-code compiler. I'd >> suspect that EXECUTE works by calling the very same compiler at >> run-time. If it did include the compiler, the VM could easily be >> turned into a full-fledged copy of IDL! The CALL_* routines still work >> because they are only allowed to call routines which are compiled >> (either natively in IDL, or in the .sav file itself). >> >> That said, there are lots of uses of EXECUTE which are no longer really >> necessary in IDL 6.0, e.g., building variable-length argument lists of >> dimensions for various routines (I've noticed Craig using that trick a >> lot). Since the VM will only run .sav files compiled with IDLv6.0, >> there's no need to hang onto these old constructions for >> compatibility's sake. Perhaps people could list their typical uses of >> EXECUTE and we could consider ways to eliminate them? >> >> JD > > I did a few days ago a feature request to remove all EXECUTEs from die > idl standard library. > > You can do a grep at rsi/idl/lib. There are some important routines too > which you can't use if you plan to build a vm. I took a look in the IDL6.0 beta lib/, and found a couple which might cause trouble: CW_FORM and CW_PDMENU. Interestingly, in all cases I found, this aim is almost always building a list of arguments of unknown length. In the case of CW_PDMENU, you could easily modify it to use a custom-built _EXTRA structure or, even better, rely on the fact that well-designed routines will (should) accept some value for all keywords which is equivalent to never having used the keyword (e.g. "foo" and "foo,HELP=0" are equivalent -- neither should activate HELP). One interesting approach to this variable argument list length issue is seen in Perl: the argument list is always interpreted as a single list, and can always be passed in as a single list, as individual arguments, or as any combination. Obviously, IDL cannot be retro-fitted to use this type of syntax, but one possibility presents itself: for all IDL programs, if the keyword _ARGUMENT is passed a pointer array, the individual arguments will be mapped to pointer values of the slots in the pointer array (as many as there are). E.g. pro myroutine, a, b, c could be called as myroutine,_ARGUMENTS=[ptr_new(12),ptr_new(15),ptr_new([14,15 ])] equivalent to myroutine,12,15,[14,15] This would *only* be useful in the context of run-time determined arguments, but there it would be invaluable, for instance, neatly solving the macro-replay issue Ben raised last week, i.e. creating a standard mechanism for storing and re-using a variable number of routine arguments. It would also introduce a potential for memory-leak unless care was taken, but despite this, it seems useful. You'd have to use /NO_COPY judiciously for large arrays or data structures (which normally would be passed by reference), ensuring that you restore the data after the call if necessary. A set of helper routines could easily bundle all arguments as a pointer array, and unbundle them afterwards, freeing the pointers: big=lindgen(50000) args=bundle_arguments(12,15,big,/NO_COPY) myroutine,_ARGUMENTS=args unbundle_arguments,args,void,void,big The other use of EXECUTE I've seen is turning the name of a variable (a string) into that variable's values. There's already a way to do this (though it's technically off-limits): IDL> myvar=1 IDL> print,routine_names("myvar",/fetch) 1 Terrible things will happen to you when you use this forbidden function, such as (more) hair growing out of your ears, but nonetheless, it demonstrates that EXECUTE is not essential for this operation. Just my 2.e-2USD. JD
JD Smith writes: > In the case of CW_PDMENU, you could easily modify it > to use a custom-built _EXTRA structure or, even better, rely on the > fact that well-designed routines will (should) accept some value for > all keywords which is equivalent to never having used the keyword > (e.g. "foo" and "foo,HELP=0" are equivalent -- neither should activate > HELP). I knew there would be a silver lining here. Just think, if you want to use the IDL Virtual Machine you will *have* to know how to use KEYWORD_SET and N_ELEMENTS properly to check your keywords. It could revolutionize IDL programming!! Cheers, David -- David W. Fanning, Ph.D. Fanning Software Consulting, Inc. 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
"Liam Gumley" <Liam.Gumley@ssec.wisc.edu> wrote in message news:bdf0ei$oce$1@news.doit.wisc.edu... > A particularly interesting feature of IDL 6.0 is the IDL Virtual Machine, Hi, the VM indeed seems to be great. I recently inquired about the run-time license because I needed to develop something for a third party, but it just was too damn expensive. So we didn't use IDL for that project. Would RSI really give up their income on run-time licenses (they are obsolete if you use the VM) or is there a catch? But a problem I see is the use of DLM's that I often use. I need to rebuild them every time there is a IDL upgrade (and they are not backwards compatible). Anyone any thoughts how this would be with the VM? kind regards. Gert
On Fri, 27 Jun 2003, Gert Van de Wouwer wrote: > "Liam Gumley" <Liam.Gumley@ssec.wisc.edu> wrote in message > news:bdf0ei$oce$1@news.doit.wisc.edu... >> A particularly interesting feature of IDL 6.0 is the IDL Virtual Machine, > My basic understanding after talking to the local distributor was that DLM are not allowed for VM. Best regrads Stephan > But a problem I see is the use of DLM's that I often use. I need to rebuild > them every time there is a IDL upgrade (and they are not backwards > compatible). Anyone any thoughts how this would be with the VM? ------------------------------------------------------------ ------------------ Dr. Stephan Nekolla Telefon: (49) (0) 89 4140-2959 http://www.nuk.med.tu-muenchen.de Fax: (49) (0) 89 4140-4938 Klinik und Poliklinik fuer Nuklearmedizin E-Mail: s.nekolla@lrz.tu-muenchen.de Klinikum rechts der Isar der Technischen Universitaet Muenchen Ismaningerstr. 22 D-81675 Muenchen ------------------------------------------------------------ ------------------
tbb0301@mail.lrz-muenchen.de wrote: > On Fri, 27 Jun 2003, Gert Van de Wouwer wrote: > >> > "Liam Gumley" <Liam.Gumley@ssec.wisc.edu> wrote in message >> news:bdf0ei$oce$1@news.doit.wisc.edu... >>> A particularly interesting feature of IDL 6.0 is the IDL Virtual >>> Machine, >> > Stephan >> But a problem I see is the use of DLM's that I often use. I need to >> rebuild them every time there is a IDL upgrade (and they are not >> backwards compatible). Anyone any thoughts how this would be with the VM? > > My basic understanding after talking to the local distributor was that > DLM are not allowed for VM. > > Best regrads > But that would remove some of the core functionality of IDL which is implemented as DLMs. Surely this can't be the case. -- Nigel Wade, System Administrator, Space Plasma Physics Group, University of Leicester, Leicester, LE1 7RH, UK E-mail : nmw@ion.le.ac.uk Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555
At the presentation RSI gave by us, the five people from RSI was not aware of any DLM, call_external restrictions. I specifically asked for that. I think there are restrictions about callable IDL, but let this stand a s a rumor rather than a fact. The IDL 6.0 beta documentation does not mention these restrictions. The only serious restriction is the EXECUTE() command, which is not available in VM mode. This seems to be used by many people, even though I haven't discovered its usefulness. (Maybe someone could describe a scenario, where I really need this and cannot find a quick workaround. Maybe I have been missing out on something great here.) Greetings, Haje -- <tbb0301@mail.lrz-muenchen.de> wrote in message news:Pine.SOL.4.55.0306301004370.435@sun2.lrz-muenchen.de... > On Fri, 27 Jun 2003, Gert Van de Wouwer wrote: > >> > "Liam Gumley" <Liam.Gumley@ssec.wisc.edu> wrote in message >> news:bdf0ei$oce$1@news.doit.wisc.edu... >>> A particularly interesting feature of IDL 6.0 is the IDL Virtual Machine, >> > > My basic understanding after talking to the local distributor was that > DLM are not allowed for VM. > > Best regrads > > Stephan >> But a problem I see is the use of DLM's that I often use. I need to rebuild >> them every time there is a IDL upgrade (and they are not backwards >> compatible). Anyone any thoughts how this would be with the VM? > > ------------------------------------------------------------ -------------- ---- > Dr. Stephan Nekolla Telefon: (49) (0) 89 4140-2959 > http://www.nuk.med.tu-muenchen.de Fax: (49) (0) 89 4140-4938 > Klinik und Poliklinik fuer Nuklearmedizin E-Mail: s.nekolla@lrz.tu-muenchen.de > Klinikum rechts der Isar der Technischen Universitaet Muenchen > Ismaningerstr. 22 D-81675 Muenchen > ------------------------------------------------------------ -------------- ---- >
Ok, I just tried the DLM issue myself using the beta version. Result: DLMs DO work in VM mode! Haje -- <tbb0301@mail.lrz-muenchen.de> wrote in message news:Pine.SOL.4.55.0306301004370.435@sun2.lrz-muenchen.de... > On Fri, 27 Jun 2003, Gert Van de Wouwer wrote: > >> > "Liam Gumley" <Liam.Gumley@ssec.wisc.edu> wrote in message >> news:bdf0ei$oce$1@news.doit.wisc.edu... >>> A particularly interesting feature of IDL 6.0 is the IDL Virtual Machine, >> > > My basic understanding after talking to the local distributor was that > DLM are not allowed for VM. > > Best regrads > > Stephan >> But a problem I see is the use of DLM's that I often use. I need to rebuild >> them every time there is a IDL upgrade (and they are not backwards >> compatible). Anyone any thoughts how this would be with the VM? > > ------------------------------------------------------------ -------------- ---- > Dr. Stephan Nekolla Telefon: (49) (0) 89 4140-2959 > http://www.nuk.med.tu-muenchen.de Fax: (49) (0) 89 4140-4938 > Klinik und Poliklinik fuer Nuklearmedizin E-Mail: s.nekolla@lrz.tu-muenchen.de > Klinikum rechts der Isar der Technischen Universitaet Muenchen > Ismaningerstr. 22 D-81675 Muenchen > ------------------------------------------------------------ -------------- ---- >
Hello, Some programmers here use IDL to create dynamic plots on the web. The process is a bit slow as they must connect to a license manager in order to run the IDL application. Will IDL VM help in this regard? Namely, speed of plotting over the web? -- Andrew Loughe ===================================================== NOAA/OAR/FSL/AD R/FS5 | email: Andrew.Loughe@noaa.gov 325 Broadway | wwweb: www-ad.fsl.noaa.gov/users/loughe Boulder, CO 80305-3328 | phone: 303-497-6211 fax: 303-497-6301
In article <bdp94e$jfg$1@houston.jhuapl.edu>, Haje Korth <haje.korth@jhuapl.edu> wrote: > which is not available in VM mode. This seems to be used by many people, > even though I haven't discovered its usefulness. (Maybe someone could > describe a scenario, where I really need this and cannot find a quick > workaround. Maybe I have been missing out on something great here.) > > Greetings, > Haje Here is an example: http://hea-www.harvard.edu/PINTofALE/pro/fitting/adjustie.pr o (which is part of the PINTofALE suite, see http://hea-www.harvard.edu/PINTofALE/doc/FITLINES.howto ) We use EXECUTE() to define constraints among fit parameters. Given the large number of possible constraints, there is no other way to set up a flexible constraint at run time. For instance, one might come across a constraint such as "flux in line 2 is between 2 and 3 times the flux in line 1." Or, "line 2 is at a fixed distance from line 1, with some error." Or, "if line 1 has flux greater than some threshold then line 2 is located at this position, otherwise at this other, slightly different, position." Etc. Vinay -- ____________________________________________________________ __________________ kashyap@head-cfa.harvard.edu 617 495 7173 [CfA/P-143] 617 496 7173 [F] ------------ And now a word from our sponsor --------------------- For a secure high performance FTP using SSL/TLS encryption upgrade to SurgeFTP ---- See http://netwinsite.com/sponsor/sponsor_surgeftp.htm ----
Hi, just to be sure: did you use a RSI supplied DLM or an "external" one ? Thanks Stephan On Mon, 30 Jun 2003, Haje Korth wrote: > Ok, I just tried the DLM issue myself using the beta version. Result: DLMs > DO work in VM mode! > > Haje > > -- > > <tbb0301@mail.lrz-muenchen.de> wrote in message > news:Pine.SOL.4.55.0306301004370.435@sun2.lrz-muenchen.de... >> On Fri, 27 Jun 2003, Gert Van de Wouwer wrote: >> >>> >> "Liam Gumley" <Liam.Gumley@ssec.wisc.edu> wrote in message >>> news:bdf0ei$oce$1@news.doit.wisc.edu... >>>> A particularly interesting feature of IDL 6.0 is the IDL Virtual > Machine, >>> >> >> My basic understanding after talking to the local distributor was that >> DLM are not allowed for VM. >> >> Best regrads >> >> Stephan >>> But a problem I see is the use of DLM's that I often use. I need to > rebuild >>> them every time there is a IDL upgrade (and they are not backwards >>> compatible). Anyone any thoughts how this would be with the VM? >> >> ------------------------------------------------------------ -------------- > ---- >> Dr. Stephan Nekolla Telefon: (49) (0) 89 > 4140-2959 >> http://www.nuk.med.tu-muenchen.de Fax: (49) (0) 89 4140-4938 >> Klinik und Poliklinik fuer Nuklearmedizin E-Mail: > s.nekolla@lrz.tu-muenchen.de >> Klinikum rechts der Isar der Technischen Universitaet Muenchen >> Ismaningerstr. 22 D-81675 Muenchen >> ------------------------------------------------------------ -------------- > ---- >> > > > ------------------------------------------------------------ ------------------ Dr. Stephan Nekolla Telefon: (49) (0) 89 4140-2959 http://www.nuk.med.tu-muenchen.de Fax: (49) (0) 89 4140-4938 Klinik und Poliklinik fuer Nuklearmedizin E-Mail: s.nekolla@lrz.tu-muenchen.de Klinikum rechts der Isar der Technischen Universitaet Muenchen Ismaningerstr. 22 D-81675 Muenchen ------------------------------------------------------------ ------------------