I have created some new computed variables in SPSS. I would like to be able to view the definitions (to check for errors) and possibly edit them after the fact. I cannot find a way to do this or find any advice on the internet.
I can see the definitions in the saved syntax file but there does not seem to be a way to pull the definitions up and view them from the SAV file itself.
Note that this is NOT the same thing as recoding a variable - I want to be able to bring up something like the new variable dialog box for an existing computed variable, view the definition and, if necessary, edit it.
Double-click on the relevant output in your .SAV file.
Select, copy, and paste the COMPUTE statement to a Syntax file.
Edit the COMPUTE statement as desired.
Add the command EXECUTE. after the COMPUTE statement.
Select this block of code.
Click on the 'play' button in the ribbon (or, select Run > Run Selected).
This will recompute the variable.
CAUTION: When you run COMPUTE from syntax, you don't get the warning asking if you want to replace the existing variable.
Related
I have been given the task of creating a DXL script. First problem is that I have never used DXL before, even though I have many years experience with DOORS itself. I have been surfing the Net to seek guidance on my particular problem. I also have a few specimen DXL scripts for reference.
My new client requires that for each View of a given Module, of which there are many Views, new "reduced" Modules are to be produced reflecting each View.
By "reduced", I mean that these new Modules are to contain nothing that isn't actually needed for that View., i.e. Columns, Attributes etc. These new Modules will only have the single View.
So, the way forward as I see it, is to take copies of the single master Module, one for each View, rename those copies to reflect a given Master Module/Required View, select that required View in the given copy Module and then delete everything that is not needed by that View, i.e. available Columns, Attributes etc.
This would be simple if I had the required DXL knowledge, which I am endeavouring to pick up as fast as I can.
If at all possible, this script has to be generic and be able to work upon any of the master Module copies to produce the associated "reduced" Module reflecting a particular View.
The client aims to use the script periodically for View archiving (I know, that's the way they want it).
Clarification
Some clarification of what I believe is required, given the following text from my original question:
If at all possible, this script has to be generic and be able to work upon any of the master Module copies to produce the associated "reduced" Module reflecting a particular View.
So, say there are ten views of the master Module, outside of the DXL script, I would copy the master Module ten times, renaming each copy to reflect each of the ten views. Unless you know different, each of those ten copies will reflect the same “Absolute Number”s as are in the master Module, so no problem there?
So, starting with the first of the copied Modules, each named to reflect the View it will eventually represent, its View would be set from the ten Views available to it, that which matches its title.
The single generic DXL script would then be run against that first copy Module, the aim being to delete everything not actually needed for that view, i.e. Attributes, Columns etc. Would some kind of purging command be required in the script for any aforementioned deleted items?
The single generic DXL script would then delete ALL views from that copy Module. The log that is produced when running the script also needs capturing, but I’m not sure whether this should be done from within the script, if possible or as a separate manual task outside of the script.
The aforementioned (indented) process would then be repeated, using the same generic script, against the remaining nine copied Modules. The intension is to leave us with ten copy Modules, each one reflecting one of the ten possible Views, with each one containing only the Attributes, Columns etc. required for that View.
Creating a mirror of a module with this approach is not so easy IMO. Think e.g. about "Absolute Number". If the original module contains the numbers 15 (level 1), 2000 (level 2), 1 (level 1), you will have to create 2000 objects, purge 1997 of them and move them to the correct place.
There is a "duplicate" tool at https://www.ibm.com/developerworks/community/forums/html/topic?id=43862118-113d-4eac-b3f1-21d3b73959d1 which tries to do this, but as stated there, this script is said not to work correctly in all situations.
So, I would rather use the approach "string clipCopy (Item i); string clipPaste(Folder folderRef)". Should be faster and less error prone. But: all Out-Links will also be copied with this method, you will probably have to delete these after the copy or else the link target module(s) will have lots of In-Links.
The problem is still not so easy to solve, as every view might have DXL columns that rely on some or other attribute, and it might contain DXL attributes which again might rely on sth else. I doubt that there is a way to analyze DXL code "on the fly" and find out which columns may be deleted.
Perhaps a totally different approach would be feasible: open each view and create an export to Excel, this way you will get rid of any dynamic dependencies. Then re-import the excel sheet to a new DOORS module. You will still have the "Absolute Number" problem, but perhaps you can make a deal that you will have a pseudo attribute "Original Absolute Number" and disregard the "new" "Absolute Number"'
Quite a big task for a DXL beginner....
Update: On second thought, perhaps you might want to combine these approaches
agree with your employer that you will use an alternative attribute for Absolute Number
use a loop like Russel suggested, when creating objects remember that objects might have to be created "below" or "after" its predecessor or sibling
for DXL attributes do not copy the DXL code but the actual current value of the object
for DXL columns create pseudo attributes _ and create a new view that uses these pseudo attributes instead of the original value
Copying the entire module, then deleting everything not in that view, seems worse than just copying the things you need from each particular view.
I would take the following as the outline of your program:
for view in main module do {
for column in view do {
Find attribute for each column and store (possibly in a skip list?)
Store name of column
}
create new module
create needed types / attributes in new module
create new view in new module
for object in main module {
create object in new module
for attribute in main module {
check if attribute is in new module {
copy info from old object to new
}
}
}
}
Each of these for X in y loops should be in the DXL reference manual in some for or another.
If you need more help, let me know!
I'm trying to make a mod for the game Don't Starve Together, which makes use of Lua. For this reason, I can't modify their source variables/files.
In order to try to modify the world generation, I need to access a local table that was instantiated in another file (the file is called "levels.lua"). The variable name is "levellist". Is there a way to access the variable so that I can add certain elements to the table?
Namely, I want to add {"task_set", "cave_custom"} to levellist[DST_CAVE].overrides.
If someone could help or even just tell me if this is possible or not, that would be great. Thanks!
What you are trying to do simply doesn't make sense. Local variables are accessible only from the scope it was defined in, and it's nested scopes. There is no, normal, way to change it from different scopes, let alone an entirely different script.
If you want variables that all your scripts use, use globals.
Of course you can't get to local variables (i.e. "pointers") used by another function, save for obscure debug methods that are rarely exposed to user sandbox, but you don't need to. Because you do not want to modify some local variable (i.e. make it point to another table for example), but get to some table and modify value inside it. So you just need to find any place where it is exposed to you in any way.
You should somehow edit in relevant content in your question because it is PITA to Alt-Tab back and forth to your files. According to structure from comments/chat AddLevel(LEVELTYPE.SURVIVAL, ...) inserts an entry into levellist[LEVELTYPE.SURVIVAL] table. If you check levels.lua you can also see that it returns table with sandbox_levels assigned exactly to this.
So:
local levels = require "levels"
print(levels.sandbox_levels)
-- Will print "table: SOMENUMBERS" - i.e. address of levellist[LEVELTYPE.SURVIVAL]
You now can iterate it with for idx = 1, #levels.sandbox_levels or ipairs and find entry belonging to "DST_CAVE". I can't tell how field with ID will be called or how it will be structured because data is preprocessed with function Level before inserting that you did not include in the files you posted.
As others have suggested, this may not be your best strategy.
But depending on your environment, it may be possible to abuse some more esoteric features of the runtime to let you indirectly modify values that aren't "yours". Have a look at debug.sethook and setfenv.
When I add a new parameter in the Process Parameter Metadata Editor, checkin my changes, and go back to edit the definition or queue a build from it, the parameter is not showing. Here is the parameter in the editor:
Other custom parameters I added in the past show up fine. For example, this one shows up fine:
So..I would expect my new parameter to show up the same way this one works.
I tried closing and re-opening VS2013 (I have update 4) and changing to another build controller, but get same behavior. How do I fix this?
A parameter must be defined at the Build Arguments level (the place you found the Build Parameters Metadata).
Afterwards, the Metadata defines how it shows up, which editors it uses, and what description should be shown on it.
That's about the metadata, but you need to add your parameter in the Arguments tab.
You will find it in the XAML Workflow editor at the bottom three buttons/tabs: Variables, Arguments and Imports.
My Delphi 2006 TADOCommand has it's
CommandText (including parameters),
Prepared (True),
ParamCheck (True)
properties all set at design time.
Is there a way for me to go about deleting some of it's Parameters at run time, without having to change the CommandText to accomodate these changes. This is desireable in the case that some of the table columns that the parameters reference do not need updating/inserting.
I'm thinking of something along the lines of
TADOCommand.Parameters.ParamByName('MyParam').SafelyRemove;
Many Thanks,
Duncan
Each item in Parameters collection corresponds to parameter marker in the command text. It is like API to this marker. Removing items from Parameters will not remove the corresponding marker. If you does not need to touch some field in your command text, then you have to modify command text and remove corresponding parameter marker.
When command text is prepared, the DBMS has built command execution plan and allocated some resources, required for command execution. If you will change the command text, then DBMS has to build new command execution plan.
Kind of that ...
Because parameters placeholders (:PARAMn) are embedded in the SQL text, I don't see how you can add or remove parameters without changing CommandText. You would have a mismatch.
In case when the command text is dynamic-updateble i usually working with params like this: *Parameters.Clear; Parameters.ParseSQL(ADOCommand.CommandText, true); * it will automatically create parameter list with correct parameters names.
I want to use a latex editor that has auto completion feature for existing references in a latex file. Do you know any good ones? I am trying to find this feature in texniccenter, but I guess it doesn't exist or I could't find it yet.
Update:
Ok, I found how to enable auto completion in Texniccenter. I needed first create a project. Then open the file in this project (or copy its text). Now Ctrl-Space inside a \ref{} tag completes the reference automatically.
Texlipse does this, also with Ctrl+Space.
Inlage includes such a function, too. New commands and new environments will also appear in the auto completion list. If you use extern BibTex files the \cite{} command will open a list with your articles and books from you .bib file.
Ok, I found it. I needed first create a project. Then open the file in this project (or copy its text). Now Ctrl-Space inside a \ref{} tag completes the reference automatically.
Kile has reference completion. If you type Ctrl+Space inside of a \ref{}, you get a list of all the references (that existed last time you compiled, of course).
LEd presents a click list of them when in a \ref{}
The RefTeX mode for Emacs will do what you're asking for: the shortcut C-c ) activates the "insert a \ref" mode (of course, you can customize which type of reference: fancyref, hyperref, etc) and pressing TAB will allow you to start typing and autocomplete by tabbing again after typing some characters.
It also figures out (or asks if it can't) what sort of ref you're inserting and shows a list of all the defined \labels in your document, selectable with the arrow keys or C-n / C-p.
Now we just need a Vi user to come along and tell us how to do it there...
Now texmaker does, not need any special key.