Welcome to Telelogic Product Support
  Home Downloads Knowledgebase Case Tracking Licensing Help Telelogic Passport
Telelogic DOORS (steve huntington)
Decrease font size
Increase font size
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
Search Topic Search Topic
Topic Tools Topic Tools
Quick Reply Quick Reply
Subscribe to this topic Subscribe to this topic
E-mail this topic to someone. E-mail this topic
Bookmark this topic Bookmark this topic
View similar topics View similar topics
View topic in raw text format. Print this topic.
 14-Nov-2007 13:56
User is offline View Users Profile Print this message


Bob Fabish

Posts: 3
Joined: 11-May-2007

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
Report this to a Moderator Report this to a Moderator
 14-Nov-2007 14:12
User is offline View Users Profile Print this message


David Pechacek

Posts: 674
Joined: 5-Dec-2006

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
Report this to a Moderator Report this to a Moderator
 14-Nov-2007 15:08
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

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
Report this to a Moderator Report this to a Moderator
 14-Nov-2007 17:16
User is offline View Users Profile Print this message


David Pechacek

Posts: 674
Joined: 5-Dec-2006

Originally posted 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
Report this to a Moderator Report this to a Moderator
 14-Nov-2007 17:43
User is offline View Users Profile Print this message


Graham Stradling

Posts: 67
Joined: 19-Sep-2002

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.
Report this to a Moderator Report this to a Moderator
 15-Nov-2007 12:20
User is offline View Users Profile Print this message


Bob Fabish

Posts: 3
Joined: 11-May-2007

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
Report this to a Moderator Report this to a Moderator
 15-Nov-2007 12:21
User is offline View Users Profile Print this message


Bob Fabish

Posts: 3
Joined: 11-May-2007

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
Report this to a Moderator Report this to a Moderator
 15-Nov-2007 13:46
User is offline View Users Profile Print this message


David Pechacek

Posts: 674
Joined: 5-Dec-2006

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
Report this to a Moderator Report this to a Moderator
 15-Nov-2007 15:18
User is offline View Users Profile Print this message


Reik Schroeder

Posts: 361
Joined: 28-Jul-2003

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
Report this to a Moderator Report this to a Moderator
 15-Nov-2007 15:40
User is offline View Users Profile Print this message


ron lewis

Posts: 650
Joined: 20-Sep-2004

Question?

What would be more persistant than an encrypted include file?
Report this to a Moderator Report this to a Moderator
 15-Nov-2007 16:10
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

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
Report this to a Moderator Report this to a Moderator
 15-Nov-2007 16:32
User is offline View Users Profile Print this message


Reik Schroeder

Posts: 361
Joined: 28-Jul-2003

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
Report this to a Moderator Report this to a Moderator
 15-Nov-2007 17:58
User is offline View Users Profile Print this message


David Pechacek

Posts: 674
Joined: 5-Dec-2006

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
Report this to a Moderator Report this to a Moderator
 16-Nov-2007 07:06
User is offline View Users Profile Print this message


Reik Schroeder

Posts: 361
Joined: 28-Jul-2003

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
Report this to a Moderator Report this to a Moderator
Statistics
20925 users are registered to the Telelogic DOORS forum.
There are currently 2 users logged in.
The most users ever online was 15 on 15-Jan-2009 at 16:36.
There are currently 0 guests browsing this forum, which makes a total of 2 users using this forum.
You have posted 0 messages to this forum. 0 overall.

FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.