![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Persistent array? Topic Summary: How to keep a DXL array in a module? Created On: 14-Nov-2007 13:56 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
I need to keep data (in two 2-dimensional real arrays, each with about 1000 rows) so that it's accessible to several attribute-DXL-type attributes, all in one formal module.
Currently I'm loading/parsing a flat file every time one of the DXL-attributes fires, which is fast enough now that I only have 3 objects, but I'm afraid that the performance will be poor with many objects. I've considered moving the data into a (descriptive?) module and opening it invisibly until the formal module closes, in order to make the data persistent. However, I'd prefer to keep everything in one module so it's completely archiveable. I've also considered "creatively misusing" DXL by storing the data as enumerations in the formal module, but I don't know what the performance would be. Anyone have a fourth option? I can't find anything like a module-level attribute array, which is what I really need. Thanks, Bob |
|
![]() |
|
![]() |
|
Use a post open trigger to create the array and a pre-close trigger to delete it. Put them in a skip list that is database wide(created when DOORS opens and deleted when it closes) that is referenced by the full name of the module.
------------------------- David Pechacek AAI Services Textron dpechacek@sc-aaicorp.com David.Pechacek@gmail.com |
|
![]() |
|
![]() |
|
Better explain how to create a 'database wide' DXL array, without modifying everyone's DXL deployment. Use evalTop_?
Perhaps the following, please comment: [1] pre-module-open trigger. will evalTop_ a DXL that defines the array (using the full-name of the module in the name of the array), creates it, and reads the file and populates the array. Mmmmm. Can a pre-open trigger get the name of the module? Will a post-open trigger work; so long as it completes before ANY of the attr-dxl fire? [2] AttrDXL presumes the existence of the array and reads it. [3] pre-module-close trigger deletes the array. - Louie A completely different approach would be to abandon the attr-dxl. Instead have a post-open-module trigger that reads the file and calculates the values for each object, and creates a text attribute for each of attr-DXL above, and sets the values of these attributes. EDIT: guess that would work only when the module is open Edit... Edited: 14-Nov-2007 at 15:14 by Louie Landale |
|
![]() |
|
![]() |
|
module? Will a post-open trigger work; so long as it completes before ANY of the attr-dxl fire? Attribute DXL only appears to calculate if its in the view. So one way around this would be to not have the DXL attributes in the default view. He didn't really mention what data is in the array either. So I was being generic in my answer. And yes his users will have to add a dxl file to their startup files directory which creates the database wide skip list to hold each modules array. This is again assuming its more than one module that is going to have this module array. If its just one particular module, he doesn't need it. ------------------------- David Pechacek AAI Services Textron dpechacek@sc-aaicorp.com David.Pechacek@gmail.com Edited: 14-Nov-2007 at 17:18 by David Pechacek |
|
![]() |
|
![]() |
|
Bob,
Surely if you can move the data into an external flat file you could save the data in a module level text attribute in the same way? this should work except it leaves it at user abuse level, although if many of your users are like ours they tend not to look at module level attrs.. ------------------------- Graham Stradling, Alcatel-Lucent. |
|
![]() |
|
![]() |
|
Thanks for all the ideas!
Re. Graham's module-level text attribute: D'oh! I can't believe I missed that. Re. pre-or-post-open-module trigger: Good idea, but I'm misssing something: why would my users have to add a dxl file to their startup dir? Can't the trigger itself run the evalTop_ to create the arrays? Re. David's reply "...database wide skip list to hold each modules array." Again, I'm missing something. I want to create two 2-dimensional arrays of reals. Why do I need a skip list? BTW, this will be for only one module; when you say that with just one particular module, I won't need it, is "it" the dxl file in the users' startup dirs, the database-wide skip list, or both? Re. what the heck I'm really doing here: Sorry, I wanted to spare you the details, but that ended up being counterproductive. I'm emulating (simulating?) an Excel spreadsheet. DXL doesn't have the NORMSDIST & NORMSINV functions, so I'm rolling my own via table lookup and interpolation. So these functions will be run often: once for every update of, oh, say 10 DXL-attributes times the number of objects; that's why I'd rather not read the flat file every time, and also why I'm using attribute DXL instead of layout DXL. Thanks again, Bob |
|
![]() |
|
![]() |
|
Thanks for all the ideas!
Re. Graham's module-level text attribute: D'oh! I can't believe I missed that. Re. pre-or-post-open-module trigger: Good idea, but I'm misssing something: why would my users have to add a dxl file to their startup dir? Can't the trigger itself run the evalTop_ to create the arrays? Re. David's reply "...database wide skip list to hold each modules array." Again, I'm missing something. I want to create two 2-dimensional arrays of reals. Why do I need a skip list? BTW, this will be for only one module; when you say that with just one particular module, I won't need it, is "it" the dxl file in the users' startup dirs, the database-wide skip list, or both? Re. what the heck I'm really doing here: Sorry, I wanted to spare you the details, but that ended up being counterproductive. I'm emulating (simulating?) an Excel spreadsheet. DXL doesn't have the NORMSDIST & NORMSINV functions, so I'm rolling my own via table lookup and interpolation. So these functions will be run often: once for every update of, oh, say 10 DXL-attributes times the number of objects; that's why I'd rather not read the flat file every time, and also why I'm using attribute DXL instead of layout DXL. Thanks again, Bob |
|
![]() |
|
![]() |
|
Yes the "it" was the database wide skip which to create would require an added startup dxl file to create it(similarly you'd have to modify the finish.dxl file to delete it when DOORS closed). It was for if you wanted this module wide data for more than one module. If you did and you didn't have a way to get a handle to each module's data, you'd loose it (but it'd still be there sucking memory).
Graham's idea is probably a better way to go though. But that's going to be fun to write considering everything will be in a single text attribute. So you'll have to use commas or tabs and newlines to separate data. As far as a flat file, you don't have to constantly read it. You can load it on module open and save any changes back to the file on module close. Again would use triggers to accomplish these two actions. ------------------------- David Pechacek AAI Services Textron dpechacek@sc-aaicorp.com David.Pechacek@gmail.com |
|
![]() |
|
![]() |
|
Hi Bob, Hi Louie,
to create a global variable you may use a module open Trigger. The attached code shows an example how to create the global variable. It is the code runing in trigger. You will need a close trigger to free up the memory used by array. Another option is to calculate all values on first access to DXL attribute. Not sure, but I think within the attribute DXL code you will be able to the values of this attribute for all objects within Module. The code is then not evaluated again, because no value is empty?! Greetings Reik ------------------------- Evosoft GmbH for Siemens Industry Sector Berlin, Germany Edited: 15-Nov-2007 at 15:21 by Reik Schroeder |
|
![]() |
|
![]() |
|
Question?
What would be more persistant than an encrypted include file? |
|
![]() |
|
![]() |
|
Very interesting use of checkDXL. Since I'm not quite understanding it, let me babble and let you comment: [1] checkDXL doesn't execute the code it just 'interprets' it, and returns any intepret DXL errors found. That's basically the same as 'running' DXL that has 'halt' as the first command. In this case, if checkDXL returns an error its because the globabl variable hasn't been defined yet. [2] If not defined, the code defines it (evalTop_) [3] if Yes its already defined, then lets modify it with eval_.
What are the "\n" for in the evaluated code? Should not the evalTop_ code simply define the array and set it to null? If so, then your else clause should be promoted to always run? Should it not also delete the array if its non-null, before creating it? - Louie |
|
![]() |
|
![]() |
|
Hi Louie,
your interpretation of code is mostly correct. I use the checkDXL function because it will not display a runtime error of not defined variable when you run the code directly. The \n is not really needed, the ; too ... they are only "usual" for me ![]() No, the evalTop_ code is executed after the script has finished, so the eval_ to initialize the array wouldn't find the global variable. That is the really tricky thing on that. You need another context to define the global variable. I use this method to define a global variable for layout DXL, but it is not possible to include the code within the LDXL (all LDXL runs within the same context) so I needed to define an open trigger to create the needed variable(s). The deletion of array can be done on closing the module?! If you like to, can do it on creation too. Greetings Reik ------------------------- Evosoft GmbH for Siemens Industry Sector Berlin, Germany |
|
![]() |
|
![]() |
|
Can one of you quickly explain the difference of eval_ and evalTop_ to me?
------------------------- David Pechacek AAI Services Textron dpechacek@sc-aaicorp.com David.Pechacek@gmail.com |
|
![]() |
|
![]() |
|
Hi David,
the difference is just simple: eval_ will execute the code immediately in it's own context. It is able to return a string value with return_. evalTop_ will excute the code when the calling script is finished. The execution is done in global context, so all things provided by evalTop_ are useable later (not within the script calling evalTop_ !!) as global variables or functions. Both function will show a runtime error, if the code to evaluate isn't syntactically correct. I would suggest to use checkDXL before. Hope that helps you to understand these perms. A short description of the functions is also given in DOORS 8.3 API manual - All Platforms Greetings to SC Reik ------------------------- Evosoft GmbH for Siemens Industry Sector Berlin, Germany |
|
![]() |
Telelogic DOORS
» DXL Exchange
»
Persistent array?
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.