Version-conflicts in SALTed UCMDs
3 posts
• Page 1 of 1
Version-conflicts in SALTed UCMDs
when editing UCMDs, I usually ]load cmd the namespace and edit it. I then execute the thing, often with ]udebug ON, and edit the function there. It gets saved, version-nr. is incremented, all is well. But when I go back into the 'source'-ns after that (w/o reloading), that causes a version-conflict, because that ns still has the old version before the error came up.4
I understand that the actual cmd does not run in the source-ns, but as it stands, this is a trap has caught me a few times now. Maybe there is at least a chance to do some event-driven checking BEFORE editing and tell the user that he's about to edit an outdated version? (and ideally bring it in - after confirmation - before continuing to edit...)
I understand that the actual cmd does not run in the source-ns, but as it stands, this is a trap has caught me a few times now. Maybe there is at least a chance to do some event-driven checking BEFORE editing and tell the user that he's about to edit an outdated version? (and ideally bring it in - after confirmation - before continuing to edit...)
-
MBaas - Posts: 156
- Joined: Thu Oct 16, 2008 1:17 am
- Location: Gründau / Germany
Re: Version-conflicts in SALTed UCMDs
You should be able to edit UCMDs even while testing them.
Normally the script is loaded within the framework and if an error occurs and DEBUG is ON (as per ]udebug ON) then APL stops and you can have a look at the problem, fix it and resume. When you exit the editor after fixing the code SALT kicks in, asks you if you want to save the change on file and save it if so desired.
If the script was already in the ws when the UCMD was called (and DEBUG was ON) the framework does NOT reload the script but instead uses the one in the ws.
This avoids having to reload the script in order to be synched with the file.
This should work even if the script is versionned.
If that is not the case then there is a problem.
I will have a look.
Normally the script is loaded within the framework and if an error occurs and DEBUG is ON (as per ]udebug ON) then APL stops and you can have a look at the problem, fix it and resume. When you exit the editor after fixing the code SALT kicks in, asks you if you want to save the change on file and save it if so desired.
If the script was already in the ws when the UCMD was called (and DEBUG was ON) the framework does NOT reload the script but instead uses the one in the ws.
This avoids having to reload the script in order to be synched with the file.
This should work even if the script is versionned.
If that is not the case then there is a problem.
I will have a look.
- DanB|Dyalog
Re: Version-conflicts in SALTed UCMDs
Thanks Dan. It worked like that most of the time, but until now I had possibly 4-5 occurences of this problem where old versions were saved...during a period in which I created around 80 versions...
-
MBaas - Posts: 156
- Joined: Thu Oct 16, 2008 1:17 am
- Location: Gründau / Germany
3 posts
• Page 1 of 1
Return to Source Code Management
Who is online
Users browsing this forum: No registered users and 0 guests
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group