There's an interesting blog post by Dennis Vorst gone up on the Uniface.info blog, titled Where to put your code. As the title suggests, it's about which places are best for different types of code, based on their content.
There are a number of options; conceptual at the entity or field level, locally at the entity or field level, within the component, a local procedure or a global procedure. All of these have their merits.
I've posted my response, defending the mighty global procedure, but why don't you have a read and add your opinion in the comments?
Summary: Check out this blog post... http://unifaceinfo.com/where-to-put-your-code
Showing posts with label global. Show all posts
Showing posts with label global. Show all posts
Friday, 24 July 2015
Monday, 30 March 2015
Indirection with dollar registers
Indirection in Uniface is a wonderful thing. You can populate a local/component/global variable with a field name, and then use indirection to get the field value of the field that the variable references. You can also use it to set the referenced field to a value, like this...
fld1 = "fld2"
In this example, using the "@" character to indicate indirection, it's the field which is referenced by "fld1" and not "fld1" itself which is updated.
You can even do recursive indirection, which is very cool! Not something I've had a need for myself, but very clever all the same.
However, today I was trying to populate a register the same way, using code something like this...
reg50 = "$50"
In this example, the register was still blank (or whatever the register was before hitting this code).
To be fair, this is clearly stated in the Uniface manuals...
But I still wanted to be able to set registers in an indirect way, so I came up with this alternative...
putitem/id list,"$50","Test"
This works by populating a list with the register and the value, and then uses getlistitems to populate them. The "/id" mode copies items from the associative list into one or more fields, or registers in this case.
For example, you could use a simple for loop to clear out all of the dollar registers...
for count = 1 to 99
This would set each of the 99 dollar registers to blank.
Summary: Indirection works great for fields, but not for registers - however, you can use getlistitems to achieve the same outcome.
fld1 = "fld2"
@fld1 = "Test"
if ( fld2 = "Test" )
;this will be true
endif
In this example, using the "@" character to indicate indirection, it's the field which is referenced by "fld1" and not "fld1" itself which is updated.
You can even do recursive indirection, which is very cool! Not something I've had a need for myself, but very clever all the same.
However, today I was trying to populate a register the same way, using code something like this...
reg50 = "$50"
@reg50 = "Test"
if ( $50 = "Test" )
;this will be false!
endif
In this example, the register was still blank (or whatever the register was before hitting this code).
To be fair, this is clearly stated in the Uniface manuals...
Only fields can be referenced indirectly; the name reached by the indirect reference cannot be a variable. The following example is incorrect because the indirection refers to a general variable rather than to a field:
$1 = "$99"
@$1 = "This string does not go to $99."
But I still wanted to be able to set registers in an indirect way, so I came up with this alternative...
putitem/id list,"$50","Test"
getlistitems/id list
if ( $50 = "Test" )
;this will be true
endif
This works by populating a list with the register and the value, and then uses getlistitems to populate them. The "/id" mode copies items from the associative list into one or more fields, or registers in this case.
For example, you could use a simple for loop to clear out all of the dollar registers...
for count = 1 to 99
putitem/id list,"$%%count%%%",""
endfor
getlistitems/id list
This would set each of the 99 dollar registers to blank.
Summary: Indirection works great for fields, but not for registers - however, you can use getlistitems to achieve the same outcome.
Tuesday, 31 July 2012
Generating random numbers
One thing that is always difficult in a system is generating a truly random number. Computers aren't random, they're very logical, therefore this is inherently difficult. Having said that, there's always a way to calculate a number which is "random enough". There is no function for this in Uniface, so I'm going to look at a few different ways to achieve this.
1) perform - the only way we could find to do this originally was to build a random number function in C++ and then call out to it from our Uniface program. Something like this...
perform "GetRandomNumber" ;call 3gl function which returns 0-32767
rand = $1 / 32767
2) $uuid - since the Uniface Unique Identifer function was added, this has given an alternative method. This is largely based on the current timestamp and either includes the processor ID or the ethernet address, depending on the operating system you are using. The value returned is a 32 character hexadecimal string, so we need to remove the non-numeric characters.
We actually found that this was not random enough on non-Windows systems, as the last part of the identifier is the same throughout each transaction, so we have used characters from 3 identifiers.
3) DIY - you could also create your own random number generator, after all, these are just mathematical formulas. The C++ "rand" function that we utilise in method (1) is a simple Linear Congruential Generator. This takes an initial seed value and then uses it to create the next number in the sequence, which is then used as the seed for the next number. The key is finding a combination of values that gives an evenly distributed spread of numbers, to ensure that the numbers appear suitably random.
$$rand = ((214013 * $$rand) + 2531011) % 4294967296
rand = $$rand / 4294967296
As you can see, this relies on the seed value already being populated, which I've stored in a global register in this example. This could be set in the application shell execute trigger, maybe using $uuid or a time based numeric.
Often these algorithms return a subset of the bits in order to improve the spread, but it is not possible to do extraction at the bit level in Uniface, as far as I'm aware. Another algorithm that is popular (and generally considered better) is a Mersenne Twister, but this uses bit-shifting techniques that I don't think are possible in Uniface either.
So let's test the performance of these different methods of 2,000,000 iterations...
1) perform = 00:10.00, 00:10.00, 00:10.01 (10 seconds)
2) $uuid = 00:32.31, 00:32.44, 00:32.39 (over 32 seconds)
3) DIY = 00:34.75, 00:34.72, 00:34.72 (under 35 seconds)
As you can see, the original perform is the quickest method (although we've found that generally using a 3GL function does not hold up very well under load and these tests are only as a single user). It can be hard to support a 3GL function across multiple platforms, but this solution is mathematically the most random method. Out of the alternatives, $$uuid is quite simple but does not give a good spread of random numbers, not compared with the DIY method.
It should be emphasised that none of these methods are truly random, and therefore should not be used for cryptographic purposes. They should be suitable for simple things though, like simulating a dice throw.
Hopefully one day Uniface will provide it's own $rand or $random function - a native function should perform the best and would hopefully be implemented in a way that was suitably random with a decent spread.
Summary: If it's feasible to use a perform then this is the best way to go, both for speed and randomness. However, you may wish to consider building your own random number generator, possibly using a Linear Congruential algorithm.
1) perform - the only way we could find to do this originally was to build a random number function in C++ and then call out to it from our Uniface program. Something like this...
perform "GetRandomNumber" ;call 3gl function which returns 0-32767
rand = $1 / 32767
2) $uuid - since the Uniface Unique Identifer function was added, this has given an alternative method. This is largely based on the current timestamp and either includes the processor ID or the ethernet address, depending on the operating system you are using. The value returned is a 32 character hexadecimal string, so we need to remove the non-numeric characters.
rand = "0.%%$replace($replace($uuid,1,'&',"",-1),1,"-","",-1)%%%" * 1
We actually found that this was not random enough on non-Windows systems, as the last part of the identifier is the same throughout each transaction, so we have used characters from 3 identifiers.
3) DIY - you could also create your own random number generator, after all, these are just mathematical formulas. The C++ "rand" function that we utilise in method (1) is a simple Linear Congruential Generator. This takes an initial seed value and then uses it to create the next number in the sequence, which is then used as the seed for the next number. The key is finding a combination of values that gives an evenly distributed spread of numbers, to ensure that the numbers appear suitably random.
$$rand = ((214013 * $$rand) + 2531011) % 4294967296
rand = $$rand / 4294967296
As you can see, this relies on the seed value already being populated, which I've stored in a global register in this example. This could be set in the application shell execute trigger, maybe using $uuid or a time based numeric.
Often these algorithms return a subset of the bits in order to improve the spread, but it is not possible to do extraction at the bit level in Uniface, as far as I'm aware. Another algorithm that is popular (and generally considered better) is a Mersenne Twister, but this uses bit-shifting techniques that I don't think are possible in Uniface either.
So let's test the performance of these different methods of 2,000,000 iterations...
1) perform = 00:10.00, 00:10.00, 00:10.01 (10 seconds)
2) $uuid = 00:32.31, 00:32.44, 00:32.39 (over 32 seconds)
3) DIY = 00:34.75, 00:34.72, 00:34.72 (under 35 seconds)
As you can see, the original perform is the quickest method (although we've found that generally using a 3GL function does not hold up very well under load and these tests are only as a single user). It can be hard to support a 3GL function across multiple platforms, but this solution is mathematically the most random method. Out of the alternatives, $$uuid is quite simple but does not give a good spread of random numbers, not compared with the DIY method.
It should be emphasised that none of these methods are truly random, and therefore should not be used for cryptographic purposes. They should be suitable for simple things though, like simulating a dice throw.
Hopefully one day Uniface will provide it's own $rand or $random function - a native function should perform the best and would hopefully be implemented in a way that was suitably random with a decent spread.
Summary: If it's feasible to use a perform then this is the best way to go, both for speed and randomness. However, you may wish to consider building your own random number generator, possibly using a Linear Congruential algorithm.
Wednesday, 25 July 2012
User-defined functions
One of the things which I initially found a little odd, although very simple to grasp, was the way that Uniface allows you to create modules of code as an entry, not a function. This entry has any number of parameters (well, there probably is a limit) which can be defined as "in", "out", or "inout". The only thing that is returned from this entry is a numeric status, which you return and this sets $status accordingly. I think it's fairly common that developers use a status of "0" to indicate successful and positive for additional successful status, then a negative status for errors. Any other type of value could be returned in an "out" or "inout" parameter.
This is a very simple mechanism and it works nicely. However, sometimes it can lead to some rather verbose code, as you have to put the call to the entry on a separate line, you can't nest the call within an if or while statement as part of the condition, for example. Here's a simple entry which converts kilometres into miles...
entry kms_to_mls_entr
params
numeric kms : in
numeric mls : out
endparams
mls = kms*5/8
return 0
end
A bit of a side note; I thought you always had to specify a datatype when defining a parameter, and that this was always a local variable. I discovered recently that you can also use a component variable or a painted field name, in which case you don't specify the datatype. For example...
entry kms_to_mls_entr
params
numeric kms : in
$miles$ : out
endparams
$miles$ = kms*5/8
return 0
end
This is a very simple mechanism and it works nicely. However, sometimes it can lead to some rather verbose code, as you have to put the call to the entry on a separate line, you can't nest the call within an if or while statement as part of the condition, for example. Here's a simple entry which converts kilometres into miles...
entry kms_to_mls_entr
params
numeric kms : in
numeric mls : out
endparams
mls = kms*5/8
return 0
end
To convert two values using the entry and then add them, it takes 3 lines, like this...
call kms_to_mls_entr(kms1,mls1)
call kms_to_mls_entr(kms2,mls2)
total = mls1 + mls2
From version 9 onwards (sorry, I can't remember the minor version number) you have another option. It took me a while to find any information in the manuals, but it's there; they're called "User-Defined Functions". Here's an example...
entry kms_to_mls_func
returns numeric
params
numeric kms : in
endparams
return kms*5/8
end
Notice that there is a returns statement before the params, which determines what datatype should be returned. In this case it is numeric, but it doesn't need to be. In this case, to convert the two values using this function, it takes a single line...
total = kms_to_mls_func(kms1) + kms_to_mls_func(kms2)
This can make the code a bit neater. But of course I'm obsessed with performance, so my next step is the test these two methods over 2,000,000 iterations...
- entry = 00:17.74, 00:17.69, 00:17.60 (under 18 seconds)
- function = 00:13.64, 00:13.64, 0:13.67 (under 14 seconds)
So as you can see, the code is more concise and it performs better. It also relies on less variables defined, so it's a win-win all round really. You can even do this with a global procedure.
A bit of a side note; I thought you always had to specify a datatype when defining a parameter, and that this was always a local variable. I discovered recently that you can also use a component variable or a painted field name, in which case you don't specify the datatype. For example...
entry kms_to_mls_entr
params
numeric kms : in
$miles$ : out
endparams
$miles$ = kms*5/8
return 0
end
Summary: It is possible to create a "user-defined function", which is an entry that returns a specific datatype, allowing you to create more concise code, that also performs better.
Wednesday, 16 May 2012
Performance of string manipulation - part one
One thing that every developer fights with (or should!!) is performance. It's ok writing an application that works well for one developer sat messing about on a development server that only he is using, but it is very different when it's thousands of users all hitting the same server, under realistic but heavy load.
One particularly costly task is string manipulation. Building up a string can use a relatively large chunk of memory and take a surprising amount of processor power. So I decided to perform some performance tests to see how this could be improved.
The first test I did was comparing the use of a local variable against a non-database field. I did this test by taking the following string...
" ABCDEFGHIJKLMNOPQRSTUVWXYZ 01234567890 abcdefghijklmnopqrstuvwxyz 01234567890"
...and then using putitem/id with a counter to add this 20,000 times, with the following results...
As you can see, when manipulating a string you should never use a field to hold the string. Having said that, it doesn't seem to make any difference which type of variable you use. I continued testing the different types of variables with 200,000 and 2,000,000 iterations, without seeing the times deviate from each other.
One particularly costly task is string manipulation. Building up a string can use a relatively large chunk of memory and take a surprising amount of processor power. So I decided to perform some performance tests to see how this could be improved.
The first test I did was comparing the use of a local variable against a non-database field. I did this test by taking the following string...
" ABCDEFGHIJKLMNOPQRSTUVWXYZ 01234567890 abcdefghijklmnopqrstuvwxyz 01234567890"
...and then using putitem/id with a counter to add this 20,000 times, with the following results...
- Non-database field = 02:42.14, 02:44.64, 02:43.44 (almost 3 minutes).
- Local variable = 00:00.22, 00:00.23, 00:00.22 (less than 1 second).
- Component variable = 00:00.22, 00:00.22, 00:00.22 (less than 1 second).
- Global variable = 00:00.22, 00:00.22, 00:00.23 (less than 1 second.
As you can see, when manipulating a string you should never use a field to hold the string. Having said that, it doesn't seem to make any difference which type of variable you use. I continued testing the different types of variables with 200,000 and 2,000,000 iterations, without seeing the times deviate from each other.
Summary: Use a variable (any kind of variable) but not a field.
Subscribe to:
Posts (Atom)