How to load ALL context files?

For a start, Save Defaults doesn't load all context files (the Save Defaults is related to .cdsenv files - and it doesn't trigger auto-loading of all the context files as a side effect). Secondly, using find will find all the 64 bit as well as 32-bit context files.

But most importantly, why on earth would you want to do this? What benefit would it have? For a start, there are some order dependencies between the contexts (such as those which require a parent class which is defined in another context) - so you'll get problems trying to load them in an arbitrary order - you're far better off leaving the auto-load to do its stuff.

Regards,

Andrew.

Andrew Beckett said:

why on earth would you want to do this?

Well in this case, I'm looking for an undocumented function that will recursively delete a directory. So far I've found artRemoveDirContents(), which very nearly does what I want...

My theory is that if I load all the functions, I may yet find one that does what I want, buried in a context somewhere. I know Cadence private functions are not intended to be used by customers, but it still saves me time—at least in the short run—to use QA'd Cadence code rather than trying to roll my own from scratch.

Of course it's not really that difficult to roll a procedure to recursively delete a directory, but I constantly find myself looking for low-level procedures that are not provided in the documented APIs. Sometimes I can find the functionality I want (or at least something closer to it) in the un-documented API....

Andrew Beckett said:

For a start, there are some order dependencies between the contexts (such as those which require a parent class which is defined in another context) - so you'll get problems trying to load them in an arbitrary order - you're far better off leaving the auto-load to do its stuff.

This sounds like a job for getDepends(). Using it, do you think I could reconstruct the context dependency graph, and then load all the (64-bit) contexts in the right sequence?

  --tom

Hi Tom,

Apologies for the delay in responding to this - I'm currently in the middle of 3 weeks of travel.

tweeks said:

Of course it's not really that difficult to roll a procedure to recursively delete a directory, but I constantly find myself looking for low-level procedures that are not provided in the documented APIs. Sometimes I can find the functionality I want (or at least something closer to it) in the un-documented API....

Just because they are in the release does not mean that they are QA'd to be used for external customers. They may be QA'd as part of our software, but there may be limitations within the context of how they are being used, which you might find show up in your application. For example, there are numerous APIs in the ADE code which require two different calls to complete a task - using just one of them gives the appearance of working but leaves the data in a half-done state such that some things will break. 

Secondly, we have complete freedom to remove such functions, change their behaviour, or alter the interface so that callers have to change their code. So whilst it might seem you are saving yourself time, in fact you are building a potential time bomb. I've seen too many cases where a well-meaning individual has used a private API and then either forget about it or (worse) leave the company and leave it to somebody else (quite possibly including us as AEs) to pick up the pieces when it breaks some time later. We've had customers screaming at us because of private APIs that got removed between two releases and insisting that we add them back (despite the tool for which they were really intended having been end of lifed).

tweeks said:

This sounds like a job for getDepends(). Using it, do you think I could reconstruct the context dependency graph, and then load all the (64-bit) contexts in the right sequence?

Maybe, although getDepends() is private too. However, more importantly, I don't see why you need to load the contexts to be able to look for functions. isCallable() tells you whether a function is callable without it having to actually be loaded. Not that I'm condoning hunting for private functions, as I explained earlier!

Kind Regards,

Andrew.

Hi Andrew, 

Thank you very much for taking the time during your extended travel to write such a thoughtful reply.

You have convinced me to do the right thing and avoid using the internal functions, though they are quicker, easier, and more seductive (the Dark Side of SKILL!).