Recent Posts
11
iNomads / Re: Apache 32/64
« Last post by Mike King on March 13, 2023, 03:52:25 PM »That note applies to the fact that on Windows we ONLY compile and provide a 32 Bit mod_inomads.so for Apache 2.2 and 2.4. You can safely recompile the mod_inomads module yourself as we provide the source however you will require a 'C' compiler and to download the Apache development source headers for Windows.
For Linux, Aix, Unix, and MacOS you would compile the source based on the OS and hardware you are running on using the OS supplied 'C' compilers using the apxs command that comes with Apache.
Note you can mix 32 and 64 bit Apache and PxPlus (i.e. You can use the 32 bit Apache with either the 32 or 64 bit PxPlus on Windows).
For Linux, Aix, Unix, and MacOS you would compile the source based on the OS and hardware you are running on using the OS supplied 'C' compilers using the apxs command that comes with Apache.
Note you can mix 32 and 64 bit Apache and PxPlus (i.e. You can use the 32 bit Apache with either the 32 or 64 bit PxPlus on Windows).
12
iNomads / Apache 32/64
« Last post by ChrisKCAi on March 13, 2023, 01:14:38 PM »There is a note in the iNomads setup documentation re: Apache that states "Only the 32-bit version of Apache is supported."
Is that still the case?
Is that still the case?
13
Programming / Re: Syntax error in IF with string expressions
« Last post by Stéphane Devouard on March 13, 2023, 12:26:07 PM »I usually use nul(string$) or not(nul(string$))
I usually avoid complex conditions with nested IF ELSE and { }
Even in languages that have fancy IDEs with indentation and code folding, developers recommend using "guards"
ie simple IFs to prematurely exit from a given process or function
I often use
Or if there are more conditions to test
Anyway, thanks guys for your input
I usually avoid complex conditions with nested IF ELSE and { }
Even in languages that have fancy IDEs with indentation and code folding, developers recommend using "guards"
ie simple IFs to prematurely exit from a given process or function
I often use
Code: [Select]
for (some condition)
! // do the work
nextOr if there are more conditions to test
Code: [Select]
for (1)
if (some condition) then break
if (some other condition) then break
! // lets do the work
nextAnyway, thanks guys for your input
14
Programming / Re: Syntax error in IF with string expressions
« Last post by Ken Sproul on March 13, 2023, 08:47:49 AM »Should have included these in my previous reply.
To do "a$ or b$":
if a$+b$ then ...
To do "a$ and b$":
if a$ then if b$ then ...
Hi James,
The "test" I'm referring to is with a "let" statement, I just omitted the "let":
let x$=a$ and 1
etc.
To do "a$ or b$":
if a$+b$ then ...
To do "a$ and b$":
if a$ then if b$ then ...
Hi James,
The "test" I'm referring to is with a "let" statement, I just omitted the "let":
let x$=a$ and 1
etc.
15
Programming / Re: Syntax error in IF with string expressions
« Last post by James Zukowski on March 13, 2023, 08:44:14 AM »Like with Ken, I've found that most mixing of a simple string$ with anything in a boolean-type test will generate an Error 20. What I've done is to essentially transform it all to numeric/boolean testing, like not(nul(X$)), which would work in all boolean cases.
BTW, Ken, "if X$=A$ and 1" is a viable test, as the X$=A$ yields a boolean result.
BTW, Ken, "if X$=A$ and 1" is a viable test, as the X$=A$ yields a boolean result.
16
Programming / Re: Syntax error in IF with string expressions
« Last post by Ken Sproul on March 13, 2023, 08:32:56 AM »Hi Stephane,
I found that the "if string$ " syntax only works when the result of the expression is a string. The manual could be clearer with examples, but it says the if statement can have either numeric or string expressions. It doesn't say that it cannot have both, but that is implied. We have to think of and's and or's as part of a numeric expression because they result in a Boolean value, which ultimately is numeric.
The way to test this is whether the expression can be used in a let statement with either a string or numeric variable.
These don't work because they mix strings and numerics:
x$=a$ and 1
x=a$ and 1
These work because they don't mix variable types:
x$=a$
x=not(nul(a$)) and 1
x=not(nul(a$)) and not(nul(b$))
Hope it makes more sense now.
I found that the "if string$ " syntax only works when the result of the expression is a string. The manual could be clearer with examples, but it says the if statement can have either numeric or string expressions. It doesn't say that it cannot have both, but that is implied. We have to think of and's and or's as part of a numeric expression because they result in a Boolean value, which ultimately is numeric.
The way to test this is whether the expression can be used in a let statement with either a string or numeric variable.
These don't work because they mix strings and numerics:
x$=a$ and 1
x=a$ and 1
These work because they don't mix variable types:
x$=a$
x=not(nul(a$)) and 1
x=not(nul(a$)) and not(nul(b$))
Hope it makes more sense now.
17
Programming / Syntax error in IF with string expressions
« Last post by Stéphane Devouard on March 13, 2023, 04:28:01 AM »Hi
My boss found the issues in the attached image while doing some code
I've tried some variations with parentheses to transform variables into values but still getting the error 20
My boss found the issues in the attached image while doing some code
I've tried some variations with parentheses to transform variables into values but still getting the error 20
18
Programming / Re: Strange if then else behavior
« Last post by Mike King on March 09, 2023, 09:48:20 AM »Mike,
Yes the line numbers are assigned so you can edit at command mode if needed when running in text mode. Mind you with PxPlus 2023 due in May you should be able to run EZWeb on a Linux/MacOS/AIX box then use ED+ to edit your programs graphically from any browser.
Thomas,
When looking for the closing bracket the system has to scan ahead through the code, this is due to the interpretative nature of the language and that you can alter code at run time. Given this, from a performance perspective it is better to keep the directives on one line as scanning will be faster.
Also, as mentioned earlier, I generally prefer moving multiple lines to smaller subroutines. A GOSUB takes very little time and will often run faster than scanning looking for brackets. I also find it has the advantage that if I need to insert additional lines into an IF condition having them in a subroutine makes that easier especially when they are sub-ordinate IF directives. I find it also helpful if the subroutine name provides a 'clue' as to what the logic is doing.
For Example:
IF QtyOnHand <= 0
GOSUB BackOrder
ELSE
GOSUB CommitInventory
I have seen far too many programs not work because someone inserted or changed a few lines of code in between curly brackets that they didn't realize were present. By avoiding curly brackets and using *IT or ED+ to format your code I find it makes it more readable and supportable. I almost never use curly brackets (but maybe I'm just a bit weird in that respect).
Yes the line numbers are assigned so you can edit at command mode if needed when running in text mode. Mind you with PxPlus 2023 due in May you should be able to run EZWeb on a Linux/MacOS/AIX box then use ED+ to edit your programs graphically from any browser.
Thomas,
When looking for the closing bracket the system has to scan ahead through the code, this is due to the interpretative nature of the language and that you can alter code at run time. Given this, from a performance perspective it is better to keep the directives on one line as scanning will be faster.
Also, as mentioned earlier, I generally prefer moving multiple lines to smaller subroutines. A GOSUB takes very little time and will often run faster than scanning looking for brackets. I also find it has the advantage that if I need to insert additional lines into an IF condition having them in a subroutine makes that easier especially when they are sub-ordinate IF directives. I find it also helpful if the subroutine name provides a 'clue' as to what the logic is doing.
For Example:
IF QtyOnHand <= 0
GOSUB BackOrder
ELSE
GOSUB CommitInventory
I have seen far too many programs not work because someone inserted or changed a few lines of code in between curly brackets that they didn't realize were present. By avoiding curly brackets and using *IT or ED+ to format your code I find it makes it more readable and supportable. I almost never use curly brackets (but maybe I'm just a bit weird in that respect).
19
Programming / Re: Strange if then else behavior
« Last post by Thomas Bock on March 09, 2023, 05:28:39 AM »Mike
You wrote
This rises the question how does PxPlus find the closing curly braket? Are there any performance aspects?
As I don't like premature RETURNs or EXITs my coding style looks like this.
You wrote
Quote
The issue is a result of the line oriented nature of the language. IF ... THEN ... ELSE ... will basically process what is on the line.
This rises the question how does PxPlus find the closing curly braket? Are there any performance aspects?
As I don't like premature RETURNs or EXITs my coding style looks like this.
Code: [Select]
SUB_ROUTINE:
if condition {
txt$ = "Are "
txt$ += "these "
txt$ += "lines "
txt$ += "processed "
txt$ += "in "
txt$ += "some "
txt$ += "way "
txt$ += "during "
txt$ += "execution "
txt$ += "in "
txt$ += "order "
txt$ += "to "
txt$ += "find "
txt$ += "the "
txt$ += "closing "
txt$ += "curly "
txt$ += "bracket?"
print txt$
}
returnWould that routine be faster using a premature RETURN?20
Programming / Re: Strange if then else behavior
« Last post by Mike Hatfield on March 09, 2023, 12:29:54 AM »Ok, got it.
Is this what I should see? The listing includes the internal generated line numbers so that you can edit at the command prompt ?
:
-}list edit set_userid,
0071 Set_userid:
:
0072 IF NOT(%inomads'ForceLogon) AND %inomads'LogonReqd$<>"Y
: THEN LET %inomads'Userid$=NID;
: RETURN
0075 !
0076 DEF UID="*Void*" LOCAL
0077 CALL "*secure","F:LOGIN"
0078 DEF UID="*"
0079 !
0080 IF %inomads'Userid$=""
: THEN EXITTO SKIP_TX
0082 !
0083 IF %inomads'use_signon_uid
: THEN GOSUB Linux_signon WITH reqd_uid$=%inomads'Userid
0085 !
0086 RETURN
0087 !
0088 start_trace:
:
0089 LET x$=PTH("*plus/inomads/tracefiles",ERR=*RETURN)
0090 !
Press <ENTER> to continue or <F4> to exit:
Is this what I should see? The listing includes the internal generated line numbers so that you can edit at the command prompt ?
:
-}list edit set_userid,
0071 Set_userid:
:
0072 IF NOT(%inomads'ForceLogon) AND %inomads'LogonReqd$<>"Y
: THEN LET %inomads'Userid$=NID;
: RETURN
0075 !
0076 DEF UID="*Void*" LOCAL
0077 CALL "*secure","F:LOGIN"
0078 DEF UID="*"
0079 !
0080 IF %inomads'Userid$=""
: THEN EXITTO SKIP_TX
0082 !
0083 IF %inomads'use_signon_uid
: THEN GOSUB Linux_signon WITH reqd_uid$=%inomads'Userid
0085 !
0086 RETURN
0087 !
0088 start_trace:
:
0089 LET x$=PTH("*plus/inomads/tracefiles",ERR=*RETURN)
0090 !
Press <ENTER> to continue or <F4> to exit: