Thread: [OpenSTA-devel] [ opensta-Bugs-1199460 ] Updating FVR from Modeler doesn't work
Brought to you by:
dansut
Menu
▾
▴
opensta-devel
|
From: SourceForge.net <no...@so...> - 2005-05-10 22:52:43
|
Bugs item #1199460, was opened at 2005-05-10 18:52 Message generated for change (Settings changed) made by dansut You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199460&group_id=10857 Category: GUI Issue Group: Behavioral Status: Open >Resolution: Accepted Priority: 5 Submitted By: Daniel Sutcliffe (dansut) >Assigned to: Daniel Sutcliffe (dansut) Summary: Updating FVR from Modeler doesn't work Initial Comment: The symptom here is that when you intitally create an file variable file (FVR) it is editable and saves correctly, but thereafter it appears to revert to its original contents sometime after you try to update it. Here's what happens: When you open a script in the Commander for the Modeler to edit, a temp dir is created in Repository\.TMP\ called CYR???.tmp\ . Into this dir are copied; the scripts .ALL file from Repository\Captures, the actual SCL script (.HTP) from Repository\Scriptsand any referenced .FVR files from Repository\Data\ . While you are editing your script, if you compile and/or run it then this temp copy is updated. When you run the script from the Modeler it uses the files in this temp dir - except the .FVR files which are used from the Repository\Data\ directory. Any edits you perform to the .FVR using the GUI are also performed on the copies in Repository\Data\ . So if you edit an FVR then run your script you won't see an issue... Here's the crunch though - when you save your SCL script in the Modeler the files from the Repository\.TMP\CYR???.tmp\ are copied into their normal places in the Repository! And yes, this includes the .FVR files that have been saved from when you first opened the script... :-) I guess that GUI editing and running were supposed action on the Repository\.TMP\CYR???.tmp\ copies of the .FVRs. The fix could make this happen, or simply get rid of the .FVRs in this temp dir... I'd like to hear opinions on which of these is preferable from the user point of view? Workarounds: - edit .FVRs by hand with Modeler closed - delete .FVRs in Repository\.TMP\CYR???.tmp\ after starting Modeler ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199460&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2005-05-10 22:52:03
|
Bugs item #1199460, was opened at 2005-05-10 18:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199460&group_id=10857 Category: GUI Issue Group: Behavioral Status: Open Resolution: None Priority: 5 Submitted By: Daniel Sutcliffe (dansut) Assigned to: Nobody/Anonymous (nobody) Summary: Updating FVR from Modeler doesn't work Initial Comment: The symptom here is that when you intitally create an file variable file (FVR) it is editable and saves correctly, but thereafter it appears to revert to its original contents sometime after you try to update it. Here's what happens: When you open a script in the Commander for the Modeler to edit, a temp dir is created in Repository\.TMP\ called CYR???.tmp\ . Into this dir are copied; the scripts .ALL file from Repository\Captures, the actual SCL script (.HTP) from Repository\Scriptsand any referenced .FVR files from Repository\Data\ . While you are editing your script, if you compile and/or run it then this temp copy is updated. When you run the script from the Modeler it uses the files in this temp dir - except the .FVR files which are used from the Repository\Data\ directory. Any edits you perform to the .FVR using the GUI are also performed on the copies in Repository\Data\ . So if you edit an FVR then run your script you won't see an issue... Here's the crunch though - when you save your SCL script in the Modeler the files from the Repository\.TMP\CYR???.tmp\ are copied into their normal places in the Repository! And yes, this includes the .FVR files that have been saved from when you first opened the script... :-) I guess that GUI editing and running were supposed action on the Repository\.TMP\CYR???.tmp\ copies of the .FVRs. The fix could make this happen, or simply get rid of the .FVRs in this temp dir... I'd like to hear opinions on which of these is preferable from the user point of view? Workarounds: - edit .FVRs by hand with Modeler closed - delete .FVRs in Repository\.TMP\CYR???.tmp\ after starting Modeler ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199460&group_id=10857 |
|
From: SourceForge.net <no...@so...> - 2006-05-01 22:54:24
|
Bugs item #1199460, was opened at 2005-05-10 17:52 Message generated for change (Comment added) made by faught You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199460&group_id=10857 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GUI Issue Group: Behavioral Status: Open Resolution: Accepted Priority: 5 Submitted By: Daniel Sutcliffe (dansut) Assigned to: Daniel Sutcliffe (dansut) Summary: Updating FVR from Modeler doesn't work Initial Comment: The symptom here is that when you intitally create an file variable file (FVR) it is editable and saves correctly, but thereafter it appears to revert to its original contents sometime after you try to update it. Here's what happens: When you open a script in the Commander for the Modeler to edit, a temp dir is created in Repository\.TMP\ called CYR???.tmp\ . Into this dir are copied; the scripts .ALL file from Repository\Captures\ , the actual SCL script (.HTP) from Repository\Scripts\ and any referenced .FVR files from Repository\Data\ . While you are editing your script, if you compile and/or run it then this temp copy is updated. When you run the script from the Modeler it uses the files in this temp dir - except the .FVR files which are used from the Repository\Data\ directory. Any edits you perform to the .FVR using the GUI are also performed on the copies in Repository\Data\ . So if you edit an FVR then run your script you won't see an issue... Here's the crunch though - when you save your SCL script in the Modeler the files from the Repository\.TMP\CYR???.tmp\ are copied into their normal places in the Repository! And yes, this includes the .FVR files that have been saved from when you first opened the script... :-) I guess that GUI editing and running were supposed action on the Repository\.TMP\CYR???.tmp\ copies of the .FVRs. The fix could make this happen, or simply get rid of the .FVRs in this temp dir... I'd like to hear opinions on which of these is preferable from the user point of view? Workarounds: - edit .FVRs by hand with Modeler closed - delete .FVRs in Repository\.TMP\CYR???.tmp\ after starting Modeler ---------------------------------------------------------------------- Comment By: Danny Faught (faught) Date: 2006-05-01 17:54 Message: Logged In: YES user_id=576825 I'm reproducing similar problem2 with OpenSTA 1.4.3.20 on Windows XP Home SP2, but the workarounds mentioned here aren't helping much. Usually I simply attempt to edit the .FVR files using the vim editor, independent of the Modeler. Shutting down Commander and the Modeler and deleting files under .TMP is not sufficient to get the Commander to find the new data. The Modeler seems to be much quicker at finding the updated data. The best workaround I've found is to shut down the NameServer and restart it. I can't find any place in .TMP or anywhere else on the disk where the old contents of the file are cached, so I think it's the NameServer that's keeping the old data in my case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110857&aid=1199460&group_id=10857 |
Thanks for helping keep SourceForge clean.
X