I am recompiling a higher version of XE5 project to Delphi 5.
Please advise how to handle the following types in Delphi 5:
PInteger
PPAnsiChar
PPointerArray
I am getting an error when these datatypes are compiled.
The message:
"Undeclared identifier: 'PInteger'"
In your XE5, locate the type you're getting an "undeclared identifier" on, then Ctrl-Click with the mouse on the identifier. It should then take you to the location of the type definition so that you can see how it is defined. You then need to add that type definition to your D5 project.
Take PInteger, for instance. If you ctrl-click on it in XE5 you should get to a line like this:
PInteger = System.PInteger;
this is just an alias for another type definition, so you need to repeat the ctrl-click on the System.PInteger part to find the underlying type definition:
PInteger = ^Integer;
This is the line you need to include in your D5 project. Likewise you'll need these lines for the other types:
PPAnsiChar = ^PAnsiChar;
PPointerArray = ^PointerArray;
and if PAnsiChar / PointerArray aren't defined in D5, add these lines (before the above two ones):
PointerArray = array [0..512*1024*1024 - 2] of Pointer;
PAnsiChar = ^CHAR;
I recommend that you take all these type definitions and place them in a single UNIT containing only these type definitions and call it something like "UNIT XE5" which you can then include in the other UNITs that need these types. That way, you ensure that the new types are identical and not multiple new definitions that may be incompatible in VAR parameters.
Related
When I run a Xcos model containing a scifunc_block_m block like shown below
I get an error message relating to data dimensions inconsistency:
"Data dimensions are inconsistent:"
" Variable size=[1,1]"
"Block output size=[100,1]."
But when I double click in the block in order to see what can I change to make the dimensions correct I get a message in the console saying
Undefined variable: scifunc_block_m
What bugs me is that scifunc_block_m is not the name of any variable, but rather the name of the block itself like can be seen in the official docs.
Of course I double checked that nowhere in my function phase_shifter neither anywhere else I have any variable named like that.
I tried with Scilab 6.1.1 and 6.1.0 believing that it might be a bug from apparently not.
In your phase_shifter.sce file generating the input variable,
the signalIn variable does not comply with the From Workspace block requirements, whose documentation says that the input variable
must be a structure with time and values fields
.time must be a column vector, and in your case
.values must also be a column
So,
t = (0:1/fs:Npp/fs - 1/fs); // time vector
signalIn = A*%e^(%i*w*t);
should be replaced with
t = (0:1/fs:Npp/fs - 1/fs)'; // time column vector
signalIn = struct("time",t, "values",A*%e^(%i*w*t));
This fixes the inconsistent dimensions message.
In addition, i am not able to reproduce your issue about Undefined variable: scifunc_block_m. The parameters interface opens as expected.
You may get this kind of messages if you try to run some xcos parts out of xcos, without beforehand loading xcos-related libraries.
Then, we get an unclear "Output should be of complex type." message on the From workspace block.
By the way, you try to plot some complex values. Please have a look to the MATMAGPHI block before entering MUX: https://help.scilab.org/docs/6.1.1/en_US/MATMAGPHI.html
The source code of UNIX V6 is available and there is a book on it by J.Lions. From the book I know that " . " symbol means current location. I do not understand the next:
"*An assignment statement of the form
identifier = expression
associates a value and type with the identifier. In the example
. = 60^.
the operator ’^’ delivers the value of the first
operand and the type of the second operand
(in this case, “location”);*"
The statement can be found in file low.s (0526). What does it mean? Does it actually change PC register value and behaves as a jump instruction? I know it is old code, but I want to understand it. Thank you.
In the 6th edition assembler, . is the location counter, an offset from the beginning of a segment (text, data, or bss). When the assembler starts processing a file, . in each segment is 0, and is incremented either by assignment to . or by the presence of data or instruction statements.
The statement . = 60^. means to take the value 60 (in octal), cast it to the type of the location counter (in this case, type data), and assign it to the location counter. You'll see several statements like this in low.s in the area where interrupt vectors are set up.
When the link editor combines multiple object files together, their text, data, and bss sections are concatenated (except for COMMON data, which gets allocated just once) and any references (such as labels) to instructions or data will be relocated appropriately.
Building the Unix kernel requires an extra step to make sure data meant to be in low memory get loaded at the proper address. After low.s and the rest of the Unix kernel object files have been linked together, sysfix is run to make the data section have a load address of 0, and to relocate all data references appropriately. So that . = 60^. statement has effectively set the location counter to physical address 60.
We're using Boost-Build to build our software. To help facilitate this, we've written a library of rules and actions. Boost-Build allows passing in command line arguments and will pass along any argument prefixed with --. Currently, to get a hold of the arguments and check for flags we're doing something like:
import modules ;
local args = [ modules.peek : ARGV ] ;
# or like this
if "--my-flag" in [ modules.peek : ARGV ]
Which works to get and check values. However, developers that use Boost-Build and our jam libraries have no idea that these flags are available and would like to see some help on these flags whenever they run either bjam -h or bjam --help. I see that BB has a help module, but I don't see any way to register arguments with the help system.
Is there a way to register command line flags, complete with short documentation, that the help system will pick up?
In response to my own question, I have added the very feature that I was asking about: https://github.com/boostorg/build/pull/23
It uses the existing options plugin system. Whenever you want to create a new command-line option create a new module within the options directory. Within that new module, create a variable that holds a value or is empty. Above the variable create a comment. The comment is used as the command-line documentation and the value (if given) is used to describe the default value of that variable.
Create a process rule within the new module and register your option with the system. This allows importing the option module and getting the value from a single source. This requires that each variable name is prefixed with the name of the module.
Create a variable named .option-description. Its value is the section separator and its comment is the description of the section.
For example:
# within options/cool.jam
# These are the options for the Cool option plugin
.option-description = Cool Options
# This enables option1
.option.--cool-option1 ?= ;
# This enables something cool
.option.--cool-default-option ?= "my default value" ;
rule process (
command # The option.
: values * # The values, starting after the "=".
)
{
option.set $(command) : $(values) ;
}
When running bjam with the --help-options flag, it will output all modules that follow the above patterns within the options directory. It will have an output similar to the following:
Boost.Build Usage:
b2 [ options... ] targets...
* -a; Build all targets, even if they are current.
* -fx; Read 'x' as the Jamfile for building instead of searching for the
Boost.Build system.
* -jx; Run up to 'x' commands concurrently.
* -n; Do not execute build commands. Instead print out the commands as they
would be executed if building.
* -ox; Output the used build commands to file 'x'.
* -q; Quit as soon as a build failure is encountered. Without this option
Boost.Jam will continue building as many targets as it can.
* -sx=y; Sets a Jam variable 'x' to the value 'y', overriding any value that
variable would have from the environment.
* -tx; Rebuild the target 'x', even if it is up-to-date.
* -v; Display the version of b2.
* --x; Any option not explicitly handled by Boost.Build remains available to
build scripts using the 'ARGV' variable.
* --abbreviate-paths; Use abbreviated paths for targets.
* --hash; Shorten target paths by using an MD5 hash.
* -dn; Enables output of diagnostic messages. The debug level 'n' and all
below it are enabled by this option.
* -d+n; Enables output of diagnostic messages. Only the output for debug
level 'n' is enabled.
Debug Levels:
Each debug level shows a different set of information. Usually with higher
levels producing more verbose information. The following levels are supported:
* 0; Turn off all diagnostic output. Only errors are reported.
* 1; Show the actions taken for building targets, as they are executed.
* 2; Show quiet actions and display all action text, as they are executed.
* 3; Show dependency analysis, and target/source timestamps/paths.
* 4; Show arguments of shell invocations.
* 5; Show rule invocations and variable expansions.
* 6; Show directory/header file/archive scans, and attempts at binding to
targets.
* 7; Show variable settings.
* 8; Show variable fetches, variable expansions, and evaluation of 'if'
expressions.
* 9; Show variable manipulation, scanner tokens, and memory usage.
* 10; Show execution times for rules.
* 11; Show parsing progress of Jamfiles.
* 12; Show graph for target dependencies.
* 13; Show changes in target status (fate).
Cool Options:
These are the options for the Cool option plugin
* --cool-option1: This enables option1. Default is disabled.
* --cool-default-option: This enables something cool. "my default value".
Later on in your own Jam code, you can then get a hold of values from the registered options by doing:
import option ;
option1 = option.get '--cool-option1' ;
if $(option1) {
# do_something ;
}
There is no way to "register" individual options with the B2 help system. As generally that's just not how the help system works. The help system documents B2 modules (i.e. classes) and projects (i.e. jamfiles) only. What you see when you do "b2 --help" is a collection of the project help information and module information. All the data is extracted from the parse jamfiles.
For modules you add comments to classes and arguments and they get formatted for output. For example take a look at the "container.jam" source. In that the second comment on the file is a module help doc, the comment before "class node" is a class help doc, the comment before "rule set" is a method help doc, and the comment after the "value ?" argument is a help doc.
For projects the second comment in the project's jamfile is taken as the help doc. For example the Boost Jamroot has a large help doc comment for the usage information. This is printed out if you:
cd <boost-root>
b2 --help
If you such a comment to one of your project jamfiles (note: it assumes the first comment is a copyright notice and hence skips it and uses the second comment block for the help doc), and cd to that project directory and do b2 --help you should see it printed.
Which type of help doc you want is of course dependent on your project and your intentions.
I'm using OCMock to aid in Test Driven Development I am doing for an iPad application using Xcode. I have test code like this:
id mock = [OCMockObject mockForProtocol:#protocol(SomeProtocol)];
Vector direction = { 1.0f, 2.0f, 3.0f };
[[mock expect] setDirection:direction];
When I try to compile, I'm getting warnings and errors like this:
warning: multiple methods named 'setDirection:' found
error: sending'Vector' to parameter of incompatible type
'UISwipeGestureRecognizerDirection' (aka 'enum
UISwipeGestureRecognizerDirection')
Obviously the compiler is not able to determine what type of object the mock is supposed to be. I'm not sure how to specify that it should deal with the setDirection method from the SomeProtocol protocol instead of a setDirection method from another class.
What can be done to make a test case like this build successfully?
Qualifying the mock with a cast will eliminate the ambiguity:
[(id<SomeProtocol>)[mock expect] setDirection:direction];
For the OCMock 3 modern syntax:
id protocolMock = OCMProtocolMock(#protocol(MYProtocol));
OCMExpect([(id <MYProtocol>)protocolMock ambiguousMethod]);
The transaction AL11 returns a mapping of "directory parameters" to file paths on the application server AFAIK.
The trouble with transaction AL11 is that its program only calls c modules, there's almost no trace of select statements or function calls to analize there.
I want the ability to do this dynamically, in my code, like for instance a function module that took "DATA_DIR" as input and "E:\usr\sap\IDS\DVEBMGS00\data" as output.
This thread is about a similar topic, but it doesn't help.
Some other guy has the same problem, and he explains it quite well here.
I strongly suspect that the only way to get these values is through the kernel directly. some of them can vary depending on the application server, so you probably won't be able to find them in the database. You could try this:
TYPE-POOLS abap.
TYPES: BEGIN OF t_directory,
log_name TYPE dirprofilenames,
phys_path TYPE dirname_al11,
END OF t_directory.
DATA: lt_int_list TYPE TABLE OF abaplist,
lt_string_list TYPE list_string_table,
lt_directories TYPE TABLE OF t_directory,
ls_directory TYPE t_directory.
FIELD-SYMBOLS: <l_line> TYPE string.
START-OF-SELECTION-OR-FORM-OR-METHOD-OR-WHATEVER.
* get the output of the program as string table
SUBMIT rswatch0 EXPORTING LIST TO MEMORY AND RETURN.
CALL FUNCTION 'LIST_FROM_MEMORY'
TABLES
listobject = lt_int_list.
CALL FUNCTION 'LIST_TO_ASCI'
EXPORTING
with_line_break = abap_true
IMPORTING
list_string_ascii = lt_string_list
TABLES
listobject = lt_int_list.
* remove the separators and the two header lines
DELETE lt_string_list WHERE table_line CO '-'.
DELETE lt_string_list INDEX 1.
DELETE lt_string_list INDEX 1.
* parse the individual lines
LOOP AT lt_string_list ASSIGNING <l_line>.
* If you're on a newer system, you can do this in a more elegant way using regular expressions
CONDENSE <l_line>.
SHIFT <l_line> LEFT DELETING LEADING '|'.
SHIFT <l_line> RIGHT DELETING TRAILING '|'.
SPLIT <l_line>+1 AT '|' INTO ls_directory-log_name ls_directory-phys_path.
APPEND ls_directory TO lt_directories.
ENDLOOP.
Try the following
data : dirname type DIRNAME_AL11.
CALL 'C_SAPGPARAM' ID 'NAME' FIELD 'DIR_DATA'
ID 'VALUE' FIELD dirname.
Alternatively if you wanted to use your own parameters(AL11->configure) then read these out of table user_dir.