So I'm a complete fledgling when it comes to Smalltalk and right now I'm writing a very simple app with a GUI. All this app does is add two operands together from two input fields and displays the sum in a third, read-only input field.
I am having trouble with VisualWorks recognizing temporary variables that I have already declared.
I try to highlight any line with a declared temporary variable, and it will say such variable has not been declared; do I want to declare it as temp, instance, shared, etc... It's especially strange because the method can be accepted and even read through when I run it by the GUI,(although I am having a problem typecasting the variables as integers) but if I want to print or inspect any line with a declared temporary variable, it will say that it doesn't recognize it as such and do I want to declare it as this or that.
The Code:
add
"adds two input fields"
| op1 op2 result |
op1 := #InputOperand1 value asInteger.
op2 := #InputOperand2 value asInteger.
result := op1 + op2.
^result
Any ideas?
The problem is that only the text you've selected is compiled and evaluated. If you are only selecting a single line, then the variable declarations aren't included in the compiled code. If you select the whole method body for evaluation (not including the method signature), it should work fine. Another option is to just choose "create temp" when the compiler prompts, and then revert to the saved version of the method to get rid of the extra temp declaration.
Related
I'm having a problem running my script. I can't for the life of me figure out what the illegal character is.
I have tried putting the string concatenation on separate lines, and I get the same error. I have tried using OneDate and TwoDate instead of Date_1 and Date_2, also to no avail. I have updated AHK, which didn't solve it.
I should note that I am using both MonthCal and DateTime Gui control to get these dates, then formatting them with FormatTime. Another error I have noticed, which may provide a clue, is that no matter what dates I pick in the date controls, I get 2017-Sep-01 as the output. It's possible that no values are coming through from the controls, and the FormatTime function is using today's date because the variables it's attempting to work on are blank / don't exist.
Other than than, generally I like to be more descriptive in my questions, but in this case, I think all I can say is: "Help?"
When you use the expression assignment method := you shouldn't use %. Instead you should write Output := Output Date_1 "_to_" Date_2. When you do use % with expression assignment Autohotkey dereferences the variable and tries to treat OtherDescription--2017... as a variable name and - is not a legal character for an Autohotkey variable.
The following example will help make it more clear:
astring := "some text"
output = a
Output := %Output%STRING
MsgBox % Output
The MsgBox will show "some text". This happens because Autohotkey dereferences %Output% to "a" and then assigns to it the value of astring variable (it concatenates "a" and "STRING" and then looks for a variable called astring).
A feature of Stata that is sometimes inconvenient is that calling a non-defined macro returns the missing value . [edit: Stata actually returns a missing string "", not a numerical missing value], instead of throwing an error.
A piece of code, whose correct execution requires the definition of the macro, may just run giving incorrect results if the macro name is misspelled.
E.g.: having defined
global $options = , vce(robust), when
afterwards one writes reg y x $opt instead of reg y x $options the program runs anyway and it may be difficult to realise that the vce() option was not considered.
Is there any way to force Stata to issue an error in this case or is there some useful trick/best practice that can be used to reduce the risk of incurring this sort of mistake?
The feature is described incorrectly. A macro that is undefined is evaluated as an empty string, conventionally written "", i.e. the delimiters " " contain nothing, or -- if you prefer -- nothing is contained between them.
A macro that is undefined is not ever evaluated as numeric system missing, written as a period . (call it dot or stop if you want).
You would see system missing if the macro were set to contain something else that was system missing, which is entirely different. Saved results from programs, for example, might be system missing.
One way to understand this is that macros in Stata contain strings, not numeric values; the fact that some macros have a numeric interpretation is something else. So, an undefined macro is evaluated as an empty string.
Stata programmers learn to use this feature constructively as a way of allowing defaults when macros are undefined and other choices when they are defined.
You are correct that the feature is a source of bugs, as when a spelling mistake leads Stata to see a name that isn't defined and just ignores the reference. The bug is still the programmer's bug, not Stata's.
So, what can you do, apart from check your code as usual? You can always check whether a macro is defined, as in
if "$options" == "" {
* do something
}
else {
* do something else
}
Conversely,
if "$options" != ""
is a test for content.
Alternatively, you could use string scalars. Here is an experiment:
. sysuse auto, clear
(1978 Automobile Data)
. scalar foo = ", meanonly"
. summarize mpg `=scalar(foo)'
. ret li
scalars:
r(N) = 74
r(sum_w) = 74
r(sum) = 1576
r(mean) = 21.2972972972973
r(min) = 12
r(max) = 41
. summarize mpg `=scalar(bar)'
bar not found
Variable | Obs Mean Std. Dev. Min Max
-------------+---------------------------------------------------------
mpg | 74 21.2973 5.785503 12 41
In this case, there was an error message when an undefined scalar was referred to, but the command was executed any way.
Personally, as a long-term (1991- ) and high intensity Stata user, I just use macros routinely and regard being occasionally bitten by bugs of this kind as a very small price to pay for that. I have not ever used string scalars in this sense before trying to answer this question.
It's a different argument, but I regard using global macros in this way as poor programming style. There are general arguments across programming for minimizing the use of globally declared entities. Local macros are the beasts of choice.
Is there any way of programmatically getting the value of a Text Symbol at runtime?
The scenario is that I have a simple report that calls a function module. I receive an exported parameter in variable LV_MSG of type CHAR1. This indicates a certain status message created in the program, for instance F (Fail), X (Match) or E (Error). I currently use a CASE statement to switch on LV_MSG and fill another variable with a short description of the message. These descriptions are maintained as text symbols that I retrieve at compile time with text-MS# where # is the same as the possible returns of LV_MSG, for instance text-MSX has the value "Exact Match Found".
Now it seems to me that the entire CASE statement is unnecessary as I could just assign to my description variable the value of the text symbol with ID 'MS' + LV_MSG (pseudocode, would use CONCATENATE). Now my issue is how I can find a text symbol based on the String representation of its ID at runtime. Is this even possible?
If it is, my code would look cleaner and I wouldn't have to update my actual code when new messages are added in the function module, as I would simply have to add a new text symbol. But would this approach be any faster or would it in fact degrade the report's performance?
Personally, I would probably define a domain and use the fixed values of the domain to represent the values. This way, you would even get around the string concatenation. You can use the function module DD_DOMVALUE_TEXT_GET to easily access the language-dependent text of a domain value.
To access the text elements of a program, use a function module like READ_TEXT_ELEMENTS.
Be aware that generic programming like this will definitely slow down your program. Whether it would make your code look cleaner is in the eye of the beholder - if the values change rarely, I don't see why a simple CASE statement should be inferior to some generic text access.
Hope I understand you correctly but here goes. This is possible with a little trickery, all the text symbols in a report are defined as variables in the program (with the name text-abc where abc is the text ID). So you can use the following:
data: lt_all_text type standard table of textpool with default key,
lsr_text type ref to textpool.
"Load texts - you will only want to do this once
read textpool sy-repid into lt_all_text language sy-langu.
sort lt_all_Text by entry.
"Find a text, the field KEY is the text ID without TEXT-
read table lt_all_text with key entry = i_wanted_text
reference into lsr_text binary search.
If you want the address you can add:
field-symbols: <l_text> type any.
data l_name type string.
data lr_address type ref to data.
concatenate 'TEXT-' lsr_text->key into l_name.
assign (l_name) to <l_text>.
if sy-subrc = 0.
get reference of <l_text> into lr_address.
endif.
As vwegert pointed out this is probably not the best solution, for error handling rather use message classes or exception objects. This is useful in other cases though so now you know how.
If we compare ABAP field symbols and data references with the pointer in C, we observe :-
In C, say we declare a variable "var" type "integer" with default value "5".
The variable "var" will be stored some where in memory, and say the memory address which holds this variable is "1000".
Now we define a pointer "ptr" and this pointer is assigned to our variable.
So, "ptr" will be "1000" and " *ptr " will be 5.
Lets compare the above situation in ABAP.
Here we declare a Field symbol "FS" and assign that to the variable "var".
Now my question is what "FS" holds ? I have searched this rigorously in the internet but found out many ABAP consultants have the opinion that FS holds the address of the variable i.e. 1000. But that is wrong. While debugging i found out that fs holds only 5. So fs (in ABAP) is equivalent to *ptr (in C). Please correct me if my understanding is wrong.
Now lets declare a data reference "dref" and another filed symbol "fsym" and after creating the data reference we assign the same to field symbol . Now we can do operations on this field symbol. So the difference between data refernec and field symbol is :-
in case of field symbol first we will declare a variable and assign it to a field symbol.
in case of data reference first we craete a data reference and then assign that to field symbol.
Then what is the use of data reference? The same functionality we can achive through field symbol also.
The field-symbol is much like a pointer, but one that you can only access in a dereferenced form. In other words, it will hold, internally, the memory address of the variable that was assigned to it, but it will not allow you to see the memory address, only the data that is stored in the variable that it points to. This can be proved, because if you change the contents of a field-symbol that points to an internal table line, you'll see that the changes will be made directly in the line.
A data reference acts like a simple pointer, except that you can't increment or decrement the memory address like in C (ptr++, ptr-- and such). It differs from a field-symbol because you can compare two data references to check if they point to the exact same spot in the memory. Comparing two field-symbols will be a simple value comparison. Another difference is that you can allocate memory dynamically by creating data references, with the CREATE DATA command. A field-symbol can only be assigned to an already allocated variable.
Although data references and field symbols look very similar and are often used in a similar fashion (see the other answers), they are fundamentally different.
Data references are variables that store a value, just like a string or an integer. They have a fixed size in memory and a content. The only difference is that these references are pointers to other data objects, i. e. the content has a special meaning. They can point nowhere, they can be dereferenced, you can pass them along to other routines, you can manipulate either the pointer (GET REFERENCE) or the value it points to. Nothing special to it, really - just pointers as you know them from your favorite programming language.
Field Symbols are no "real" variables. The documentation states that
They do not physically reserve space for a field
Field Symbols are really only clever manipulations of the local symbol table of the ABAP VM. I'll try to illustrate this - note that this is a heavily simplified model. Let's say you declare three variables:
DATA: my_char TYPE c,
my_int TYPE i,
my_ref TYPE REF TO i.
Then the symbol table will contain - among others - entries that might look like this:
name type size addr
------------------------------
MY_CHAR c 1 0x123456
MY_INT i 4 0x123457
MY_REF r ? 0x123461
(I'm not sure about the actual size of a reference variable.)
These entries only point to an address that contains the values. Depending on the scope of these variables, they might reside in totally different memory areas, but that's not our concern at the moment. The important points are:
Memory has to be reserved for the variables (this is done automatically, even for references).
References work just like all the other variables.
Let's add a field symbol to this:
FIELD-SYMBOLS: <my_fs> TYPE any.
Then the symbol might look like this:
name type size addr target
--------------------------------------
MY_CHAR c 1 0x123456
MY_INT i 4 0x123457
MY_REF r ? 0x123461
<MY_FS> *
The field symbol is created in its initial state (unassigned). It doesn't point anywhere, and using it in this state will result in a short dump. The important point is: It is not backed by "heap" memory like the other variables. Let's
ASSIGN my_char TO <my_fs>.
Again the symbol might look like this:
name type size addr target
--------------------------------------
MY_CHAR c 1 0x123456
MY_INT i 4 0x123457
MY_REF r ? 0x123461
<MY_FS> * MY_CHAR
Now, when accessing <my_fs>, the runtime system will recognize it as a field symbol, lookup the current target in the symbol table and redirect all operations to the actual location of my_char. If, on the other hand, you'd issue the command
GET REFERENCE OF my_int INTO my_ref.
the symbol table would not change, but at the "heap address" 0x123461, you'd find the "address" 0x123457. Just a value assignment like my_char = 'X' or my_int = 42 * 2.
This is, in a very simplified version, the reason why you cannot pass field symbols as changing parameters and allow them to be reassigned inside the subroutine. They do not exist in the same way that other variables do, and they have no meaning outside of the scope of the symbol table they were added to.
A field symbol, which has been around in ABAP much longer, allows you to manipulate and pass values of fields at runtime, without knowing the name of the field beforehand. Consider this use case: You have a structure with 20 fields, you can reference each field by name and assign it to a field symbol, and then change the value of a particular field etc.
A data reference (TYPE REF TO DATA), which is a relatively newer addition to ABAP, allows you to instantiate data at runtime without knowing the type beforehand using the 'CREATE DATA' statement.
For an example of the use of CREATE DATA, see the following SAP Help page. It shows you how you can for example get a reference to a reference object (i.e. ABAP Objects reference) using CREATE DATA, which is something you could not do with a field symbol: http://help.sap.com/abapdocu_70/en/ABAPCREATE_DATA_REFERENCE.htm
When I´m using MATLAB, sometimes I feel the need to make comments on some variables. I would like to save these comments inside these variables. So when I have to work with many variables in the workspace, and I forget the context of some of these variables I could read the comments I put in every one of them. So I would like to comment variables and keep the comments inside of them.
While I'm of the opinion that the best (and easiest) approach would be to make your variables self-documenting by giving them descriptive names, there is actually a way for you to do what you want using the object-oriented aspects of MATLAB. Specifically, you can create a new class which subclasses a built-in class so that it has an additional property describing the variable.
In fact, there is an example in the documentation that does exactly what you want. It creates a new class ExtendDouble that behaves just like a double except that it has a DataString property attached to it which describes the data in the variable. Using this subclass, you can do things like the following:
N = ExtendDouble(10,'The number of data points')
N =
The number of data points
10
and N could be used in expressions just as any double value would. Using this example subclass as a template, you could create "commented" versions of other built-in numeric classes, with the exception of those you are not allowed to subclass (char, cell, struct, and function_handle).
Of course, it should be noted that instead of using the ExtendDouble class like I did in the above example, I could instead define my variable like so:
nDataPoints = 10;
which makes the variable self-documenting, albeit with a little more typing needed. ;)
How about declaring another variable for your comments?
example:
\>> num = 5;
\>> numc = 'This is a number that contains 5';
\>> whos
...
This is my first post in StackOverflow. Thanks.
A convenient way to solve this is to have a function that does the storing and displaying of comments for you, i.e. something like the function below that will pop open a dialog box if you call it with comments('myVar') to allow you to enter new (or read/update previous) comments to variable (or function, or co-worker) labeled myVar.
Note that the comments will not be available in your next Matlab session. To make this happen, you have to add save/load functionality to comments (i.e. every time you change anything, you write to a file, and any time you start the function and database is empty, you load the file if possible).
function comments(name)
%COMMENTS stores comments for a matlab session
%
% comments(name) adds or updates a comment stored with the label "name"
%
% comments prints all the current comments
%# database is a n-by-2 cell array with {label, comment}
persistent database
%# check input and decide what to do
if nargin < 1 || isempty(name)
printDatabase;
else
updateDatabase;
end
function printDatabase
%# prints the database
if isempty(database)
fprintf('no comments stored yet\n')
else
for i=1:size(database,1)
fprintf('%20s : %s\n',database{i,1},database{i,2});
end
end
end
function updateDatabase
%# updates the database
%# check whether there is already a comment
if size(database,1) > 0 && any(strcmp(name,database(:,1)))
idx = strcmp(name,database(:,1));
comment = database(idx,2);
else
idx = size(database,1)+1;
comment = {''};
end
%# ask for new/updated comment
comment = inputdlg(sprintf('please enter comment for %s',name),'add comment',...
5,comment);
if ~isempty(comment)
database{idx,1} = name;
database(idx,2) = comment;
end
end
end
Always always always keep the Matlab editor open with a script documenting what you do. That is, variable assignments and calculations.
Only exceptions are very short sessions where you want to experiment. Once you have something -- add it to the file (It's also easier to cut and paste when you can see your entire history).
This way you can always start over. Just clear all and rerun the script. You never have random temporaries floating around in your workspace.
Eventually, when you are finished, you will also have something that is close to 'deliverable'.
Have you thought of using structures (or cells, although structures would require extra memory use)?
'>> dataset1.numerical=5;
'>> dataset1.comment='This is the dataset that contains 5';
dataset1 =
numerical: 5
comment: 'This is the dataset that contains 5'