Uniface User Forum

So, we are trying to get on 10.4.3 so we can play with the new toys we saw in Amsterdam. 
Installed it, imported an XML of out code and compiled everything. 
Wham! An output file with thousands of "Warning....deprecated...". 
I've altered our output file filter program to remove these warnings from the final output we see, so it's okay for the moment, but I'd obviously like to deal with the underlying issue(s) before the warnings become errors. 
So, does anyone have any technique which could help here? A source scanner with intelligent replace? Some trick to help with amending an export file? 
I'm particularly worried about the ones like scan and length where the old code uses $result further down, and the new code needs to populate a variable or use the function inside the if/while statements. 

Not holding out a lot of hope, but this is going to be a big nasty job without something. 

Regards, 
Iain

Hi Iain

Nope, there is no tool to do so.
A long time ago we had the challenge of replacing RUN with a global routine (this was before ACTIVATE existed). I wrote a program that searched for RUN, analyzed the switches and turned the whole thing into a call for the global routine. It worked reasonably well, it was just stupid that a colleague had named a label  "RUNDEN:", which was also tried to be converted :-)

The advantage of the "RUN" case is that only one line of code needs to be considered.
But with SCAN and LENGTH, there are at least two lines involved. And who guarantees that they are directly behind each other? 
Example

putmess "Hello World, I'm about to scan $1 for hello"
scan $1,"hello"
putmess "Just scanned $1 and found hello at pos %%$result%%%"
$2 = $result
putmess "Today is a sunny day, so I also store the postion time 4 in $3"
$3 = $result*4

What may be possible is this.

scan $1,"hello"

convert to

$result = $scan($1,"hello")

So search for "scan"  at the begin of a line (skip whitspaces)(e.g.  can be done with the new RegExpression in UnifAce)
Insure that "scan" is an isolated word (see the problem with run.)
'Extract' the parameter for scan (i.e. start the line at pos+4)
Replace the line with v_LINE = $concat( "$result = $scan(" , v_LINE[v_POS_SCAN+4] , ")" )

This is just a simple example, maybe there is a whitespace after the scan statement that you don't want to copy etc.
For LENGTH->$LENGTH the idea is the same
After this replacement, you do use the new UnifAce verbs, but still have $result as a temporary storage.
But this can't be done without the knowledge of the old programm code

 

So, we are trying to get on 10.4.3 so we can play with the new toys we saw in Amsterdam. 
Installed it, imported an XML of out code and compiled everything. 
Wham! An output file with thousands of "Warning....deprecated...". 
I've altered our output file filter program to remove these warnings from the final output we see, so it's okay for the moment, but I'd obviously like to deal with the underlying issue(s) before the warnings become errors. 
So, does anyone have any technique which could help here? A source scanner with intelligent replace? Some trick to help with amending an export file? 
I'm particularly worried about the ones like scan and length where the old code uses $result further down, and the new code needs to populate a variable or use the function inside the if/while statements. 

Not holding out a lot of hope, but this is going to be a big nasty job without something. 

Regards, 
Iain

Yeah, that's mostly what I was afraid of. 
A small glimmer of silver in the cloud is that I think a reasonable amount of the repeated warnings comes from one or two bits of #include code, so changing them will drastically cut the job down, but it will still be quite some task. 

Hi Iain

Nope, there is no tool to do so.
A long time ago we had the challenge of replacing RUN with a global routine (this was before ACTIVATE existed). I wrote a program that searched for RUN, analyzed the switches and turned the whole thing into a call for the global routine. It worked reasonably well, it was just stupid that a colleague had named a label  "RUNDEN:", which was also tried to be converted :-)

The advantage of the "RUN" case is that only one line of code needs to be considered.
But with SCAN and LENGTH, there are at least two lines involved. And who guarantees that they are directly behind each other? 
Example

putmess "Hello World, I'm about to scan $1 for hello"
scan $1,"hello"
putmess "Just scanned $1 and found hello at pos %%$result%%%"
$2 = $result
putmess "Today is a sunny day, so I also store the postion time 4 in $3"
$3 = $result*4

What may be possible is this.

scan $1,"hello"

convert to

$result = $scan($1,"hello")

So search for "scan"  at the begin of a line (skip whitspaces)(e.g.  can be done with the new RegExpression in UnifAce)
Insure that "scan" is an isolated word (see the problem with run.)
'Extract' the parameter for scan (i.e. start the line at pos+4)
Replace the line with v_LINE = $concat( "$result = $scan(" , v_LINE[v_POS_SCAN+4] , ")" )

This is just a simple example, maybe there is a whitespace after the scan statement that you don't want to copy etc.
For LENGTH->$LENGTH the idea is the same
After this replacement, you do use the new UnifAce verbs, but still have $result as a temporary storage.
But this can't be done without the knowledge of the old programm code

 

So, we are trying to get on 10.4.3 so we can play with the new toys we saw in Amsterdam. 
Installed it, imported an XML of out code and compiled everything. 
Wham! An output file with thousands of "Warning....deprecated...". 
I've altered our output file filter program to remove these warnings from the final output we see, so it's okay for the moment, but I'd obviously like to deal with the underlying issue(s) before the warnings become errors. 
So, does anyone have any technique which could help here? A source scanner with intelligent replace? Some trick to help with amending an export file? 
I'm particularly worried about the ones like scan and length where the old code uses $result further down, and the new code needs to populate a variable or use the function inside the if/while statements. 

Not holding out a lot of hope, but this is going to be a big nasty job without something. 

Regards, 
Iain

Oh yeh, the #includes

Took me quite a bit of time to suppress all the warnings.
Especially since I have includes on almost all levels*) and the order in which UnifAce loads the includes is also not deterministic :-)

*) Component, entity collection, entity occurence. And higly configurable by #define

Yeah, that's mostly what I was afraid of. 
A small glimmer of silver in the cloud is that I think a reasonable amount of the repeated warnings comes from one or two bits of #include code, so changing them will drastically cut the job down, but it will still be quite some task. 

Hi Iain

Nope, there is no tool to do so.
A long time ago we had the challenge of replacing RUN with a global routine (this was before ACTIVATE existed). I wrote a program that searched for RUN, analyzed the switches and turned the whole thing into a call for the global routine. It worked reasonably well, it was just stupid that a colleague had named a label  "RUNDEN:", which was also tried to be converted :-)

The advantage of the "RUN" case is that only one line of code needs to be considered.
But with SCAN and LENGTH, there are at least two lines involved. And who guarantees that they are directly behind each other? 
Example

putmess "Hello World, I'm about to scan $1 for hello"
scan $1,"hello"
putmess "Just scanned $1 and found hello at pos %%$result%%%"
$2 = $result
putmess "Today is a sunny day, so I also store the postion time 4 in $3"
$3 = $result*4

What may be possible is this.

scan $1,"hello"

convert to

$result = $scan($1,"hello")

So search for "scan"  at the begin of a line (skip whitspaces)(e.g.  can be done with the new RegExpression in UnifAce)
Insure that "scan" is an isolated word (see the problem with run.)
'Extract' the parameter for scan (i.e. start the line at pos+4)
Replace the line with v_LINE = $concat( "$result = $scan(" , v_LINE[v_POS_SCAN+4] , ")" )

This is just a simple example, maybe there is a whitespace after the scan statement that you don't want to copy etc.
For LENGTH->$LENGTH the idea is the same
After this replacement, you do use the new UnifAce verbs, but still have $result as a temporary storage.
But this can't be done without the knowledge of the old programm code

 

So, we are trying to get on 10.4.3 so we can play with the new toys we saw in Amsterdam. 
Installed it, imported an XML of out code and compiled everything. 
Wham! An output file with thousands of "Warning....deprecated...". 
I've altered our output file filter program to remove these warnings from the final output we see, so it's okay for the moment, but I'd obviously like to deal with the underlying issue(s) before the warnings become errors. 
So, does anyone have any technique which could help here? A source scanner with intelligent replace? Some trick to help with amending an export file? 
I'm particularly worried about the ones like scan and length where the old code uses $result further down, and the new code needs to populate a variable or use the function inside the if/while statements. 

Not holding out a lot of hope, but this is going to be a big nasty job without something. 

Regards, 
Iain

Oh yeh, the #includes

Took me quite a bit of time to suppress all the warnings.
Especially since I have includes on almost all levels*) and the order in which UnifAce loads the includes is also not deterministic :-)

*) Component, entity collection, entity occurence. And higly configurable by #define

Yeah, that's mostly what I was afraid of. 
A small glimmer of silver in the cloud is that I think a reasonable amount of the repeated warnings comes from one or two bits of #include code, so changing them will drastically cut the job down, but it will still be quite some task. 

Hi Iain

Nope, there is no tool to do so.
A long time ago we had the challenge of replacing RUN with a global routine (this was before ACTIVATE existed). I wrote a program that searched for RUN, analyzed the switches and turned the whole thing into a call for the global routine. It worked reasonably well, it was just stupid that a colleague had named a label  "RUNDEN:", which was also tried to be converted :-)

The advantage of the "RUN" case is that only one line of code needs to be considered.
But with SCAN and LENGTH, there are at least two lines involved. And who guarantees that they are directly behind each other? 
Example

putmess "Hello World, I'm about to scan $1 for hello"
scan $1,"hello"
putmess "Just scanned $1 and found hello at pos %%$result%%%"
$2 = $result
putmess "Today is a sunny day, so I also store the postion time 4 in $3"
$3 = $result*4

What may be possible is this.

scan $1,"hello"

convert to

$result = $scan($1,"hello")

So search for "scan"  at the begin of a line (skip whitspaces)(e.g.  can be done with the new RegExpression in UnifAce)
Insure that "scan" is an isolated word (see the problem with run.)
'Extract' the parameter for scan (i.e. start the line at pos+4)
Replace the line with v_LINE = $concat( "$result = $scan(" , v_LINE[v_POS_SCAN+4] , ")" )

This is just a simple example, maybe there is a whitespace after the scan statement that you don't want to copy etc.
For LENGTH->$LENGTH the idea is the same
After this replacement, you do use the new UnifAce verbs, but still have $result as a temporary storage.
But this can't be done without the knowledge of the old programm code

 

So, we are trying to get on 10.4.3 so we can play with the new toys we saw in Amsterdam. 
Installed it, imported an XML of out code and compiled everything. 
Wham! An output file with thousands of "Warning....deprecated...". 
I've altered our output file filter program to remove these warnings from the final output we see, so it's okay for the moment, but I'd obviously like to deal with the underlying issue(s) before the warnings become errors. 
So, does anyone have any technique which could help here? A source scanner with intelligent replace? Some trick to help with amending an export file? 
I'm particularly worried about the ones like scan and length where the old code uses $result further down, and the new code needs to populate a variable or use the function inside the if/while statements. 

Not holding out a lot of hope, but this is going to be a big nasty job without something. 

Regards, 
Iain

Hi,
I'm curious, has there been added a lot of "deprecated proc" in Uniface 10.4.03, compared to 10.4.02, or is this just a general fact for all Uniface 10 versions?
 

Oh yeh, the #includes

Took me quite a bit of time to suppress all the warnings.
Especially since I have includes on almost all levels*) and the order in which UnifAce loads the includes is also not deterministic :-)

*) Component, entity collection, entity occurence. And higly configurable by #define

Yeah, that's mostly what I was afraid of. 
A small glimmer of silver in the cloud is that I think a reasonable amount of the repeated warnings comes from one or two bits of #include code, so changing them will drastically cut the job down, but it will still be quite some task. 

Hi Iain

Nope, there is no tool to do so.
A long time ago we had the challenge of replacing RUN with a global routine (this was before ACTIVATE existed). I wrote a program that searched for RUN, analyzed the switches and turned the whole thing into a call for the global routine. It worked reasonably well, it was just stupid that a colleague had named a label  "RUNDEN:", which was also tried to be converted :-)

The advantage of the "RUN" case is that only one line of code needs to be considered.
But with SCAN and LENGTH, there are at least two lines involved. And who guarantees that they are directly behind each other? 
Example

putmess "Hello World, I'm about to scan $1 for hello"
scan $1,"hello"
putmess "Just scanned $1 and found hello at pos %%$result%%%"
$2 = $result
putmess "Today is a sunny day, so I also store the postion time 4 in $3"
$3 = $result*4

What may be possible is this.

scan $1,"hello"

convert to

$result = $scan($1,"hello")

So search for "scan"  at the begin of a line (skip whitspaces)(e.g.  can be done with the new RegExpression in UnifAce)
Insure that "scan" is an isolated word (see the problem with run.)
'Extract' the parameter for scan (i.e. start the line at pos+4)
Replace the line with v_LINE = $concat( "$result = $scan(" , v_LINE[v_POS_SCAN+4] , ")" )

This is just a simple example, maybe there is a whitespace after the scan statement that you don't want to copy etc.
For LENGTH->$LENGTH the idea is the same
After this replacement, you do use the new UnifAce verbs, but still have $result as a temporary storage.
But this can't be done without the knowledge of the old programm code

 

So, we are trying to get on 10.4.3 so we can play with the new toys we saw in Amsterdam. 
Installed it, imported an XML of out code and compiled everything. 
Wham! An output file with thousands of "Warning....deprecated...". 
I've altered our output file filter program to remove these warnings from the final output we see, so it's okay for the moment, but I'd obviously like to deal with the underlying issue(s) before the warnings become errors. 
So, does anyone have any technique which could help here? A source scanner with intelligent replace? Some trick to help with amending an export file? 
I'm particularly worried about the ones like scan and length where the old code uses $result further down, and the new code needs to populate a variable or use the function inside the if/while statements. 

Not holding out a lot of hope, but this is going to be a big nasty job without something. 

Regards, 
Iain

We had one deprecated proc in our change from 10.3 to 10.4 (sort/e deprecated in favour of just sort). This one was a simple search and replace through an XML dump of the system. 

10.4.03 has introduced 7 deprecated statements, of which we regularly use 6, 4 of which may just be a search and replace (fieldvideo=>$fieldvideo, uppercase=>$uppercase, lowercase=>$lowercase, fieldsyntax=>$fieldsyntax), but the others (length, scan, displaylength) change from being statements with the answer in $result, to functions which require a holder for the answer, thus three or four lines of code can be simplified, but as shown above, they may not be sensible for automatic replacement. 

We have been on Uniface for 15 years, from 8 through to 10.4, (We actually started on 7, but moved to 8 before we'd written much), and this is the most deprecated statements I think I've seen in one go. 
Also, Uniface have given no timeline for the existing statements to be removed, except that it's not liable to be as a result of a patch, so it wont be before (at least) 10.5, giving us time to pick at the problem piecemeal, now I've fixed our full compile filter to remove the warnings so as not to flood our emails. 

Regards, 

Iain

Hi,
I'm curious, has there been added a lot of "deprecated proc" in Uniface 10.4.03, compared to 10.4.02, or is this just a general fact for all Uniface 10 versions?
 

Oh yeh, the #includes

Took me quite a bit of time to suppress all the warnings.
Especially since I have includes on almost all levels*) and the order in which UnifAce loads the includes is also not deterministic :-)

*) Component, entity collection, entity occurence. And higly configurable by #define

Yeah, that's mostly what I was afraid of. 
A small glimmer of silver in the cloud is that I think a reasonable amount of the repeated warnings comes from one or two bits of #include code, so changing them will drastically cut the job down, but it will still be quite some task. 

Hi Iain

Nope, there is no tool to do so.
A long time ago we had the challenge of replacing RUN with a global routine (this was before ACTIVATE existed). I wrote a program that searched for RUN, analyzed the switches and turned the whole thing into a call for the global routine. It worked reasonably well, it was just stupid that a colleague had named a label  "RUNDEN:", which was also tried to be converted :-)

The advantage of the "RUN" case is that only one line of code needs to be considered.
But with SCAN and LENGTH, there are at least two lines involved. And who guarantees that they are directly behind each other? 
Example

putmess "Hello World, I'm about to scan $1 for hello"
scan $1,"hello"
putmess "Just scanned $1 and found hello at pos %%$result%%%"
$2 = $result
putmess "Today is a sunny day, so I also store the postion time 4 in $3"
$3 = $result*4

What may be possible is this.

scan $1,"hello"

convert to

$result = $scan($1,"hello")

So search for "scan"  at the begin of a line (skip whitspaces)(e.g.  can be done with the new RegExpression in UnifAce)
Insure that "scan" is an isolated word (see the problem with run.)
'Extract' the parameter for scan (i.e. start the line at pos+4)
Replace the line with v_LINE = $concat( "$result = $scan(" , v_LINE[v_POS_SCAN+4] , ")" )

This is just a simple example, maybe there is a whitespace after the scan statement that you don't want to copy etc.
For LENGTH->$LENGTH the idea is the same
After this replacement, you do use the new UnifAce verbs, but still have $result as a temporary storage.
But this can't be done without the knowledge of the old programm code

 

So, we are trying to get on 10.4.3 so we can play with the new toys we saw in Amsterdam. 
Installed it, imported an XML of out code and compiled everything. 
Wham! An output file with thousands of "Warning....deprecated...". 
I've altered our output file filter program to remove these warnings from the final output we see, so it's okay for the moment, but I'd obviously like to deal with the underlying issue(s) before the warnings become errors. 
So, does anyone have any technique which could help here? A source scanner with intelligent replace? Some trick to help with amending an export file? 
I'm particularly worried about the ones like scan and length where the old code uses $result further down, and the new code needs to populate a variable or use the function inside the if/while statements. 

Not holding out a lot of hope, but this is going to be a big nasty job without something. 

Regards, 
Iain

Hi

What I do in every migration from version 9 to 10 is pass the XML exports through various scripts to correct these deprecated statements/functions. Scripts are based on regular expressions and correct the original code. In many cases is not so easy as it seems. Specially with "uppercase something SOMETHING" to "SOMETHING = $uppercase(something)"... because "something" could be a lot of things. I always wonder why the compiler do not transform all of them, hoping it will do someday. Nevertheless, I make these corrections to avoid my customers thousands of warnings because they are already reluctant to move to version 10 and I don't want to give them excuses to stay on version 9.

I also take this opportunity to remove COL=0/COL=9 from FORMPIC and ending spaces in code as they gave me problems in some migration.

All is done directly in the v9 XML using regular expression with sed command.

Regards

We had one deprecated proc in our change from 10.3 to 10.4 (sort/e deprecated in favour of just sort). This one was a simple search and replace through an XML dump of the system. 

10.4.03 has introduced 7 deprecated statements, of which we regularly use 6, 4 of which may just be a search and replace (fieldvideo=>$fieldvideo, uppercase=>$uppercase, lowercase=>$lowercase, fieldsyntax=>$fieldsyntax), but the others (length, scan, displaylength) change from being statements with the answer in $result, to functions which require a holder for the answer, thus three or four lines of code can be simplified, but as shown above, they may not be sensible for automatic replacement. 

We have been on Uniface for 15 years, from 8 through to 10.4, (We actually started on 7, but moved to 8 before we'd written much), and this is the most deprecated statements I think I've seen in one go. 
Also, Uniface have given no timeline for the existing statements to be removed, except that it's not liable to be as a result of a patch, so it wont be before (at least) 10.5, giving us time to pick at the problem piecemeal, now I've fixed our full compile filter to remove the warnings so as not to flood our emails. 

Regards, 

Iain

Hi,
I'm curious, has there been added a lot of "deprecated proc" in Uniface 10.4.03, compared to 10.4.02, or is this just a general fact for all Uniface 10 versions?
 

Oh yeh, the #includes

Took me quite a bit of time to suppress all the warnings.
Especially since I have includes on almost all levels*) and the order in which UnifAce loads the includes is also not deterministic :-)

*) Component, entity collection, entity occurence. And higly configurable by #define

Yeah, that's mostly what I was afraid of. 
A small glimmer of silver in the cloud is that I think a reasonable amount of the repeated warnings comes from one or two bits of #include code, so changing them will drastically cut the job down, but it will still be quite some task. 

Hi Iain

Nope, there is no tool to do so.
A long time ago we had the challenge of replacing RUN with a global routine (this was before ACTIVATE existed). I wrote a program that searched for RUN, analyzed the switches and turned the whole thing into a call for the global routine. It worked reasonably well, it was just stupid that a colleague had named a label  "RUNDEN:", which was also tried to be converted :-)

The advantage of the "RUN" case is that only one line of code needs to be considered.
But with SCAN and LENGTH, there are at least two lines involved. And who guarantees that they are directly behind each other? 
Example

putmess "Hello World, I'm about to scan $1 for hello"
scan $1,"hello"
putmess "Just scanned $1 and found hello at pos %%$result%%%"
$2 = $result
putmess "Today is a sunny day, so I also store the postion time 4 in $3"
$3 = $result*4

What may be possible is this.

scan $1,"hello"

convert to

$result = $scan($1,"hello")

So search for "scan"  at the begin of a line (skip whitspaces)(e.g.  can be done with the new RegExpression in UnifAce)
Insure that "scan" is an isolated word (see the problem with run.)
'Extract' the parameter for scan (i.e. start the line at pos+4)
Replace the line with v_LINE = $concat( "$result = $scan(" , v_LINE[v_POS_SCAN+4] , ")" )

This is just a simple example, maybe there is a whitespace after the scan statement that you don't want to copy etc.
For LENGTH->$LENGTH the idea is the same
After this replacement, you do use the new UnifAce verbs, but still have $result as a temporary storage.
But this can't be done without the knowledge of the old programm code

 

So, we are trying to get on 10.4.3 so we can play with the new toys we saw in Amsterdam. 
Installed it, imported an XML of out code and compiled everything. 
Wham! An output file with thousands of "Warning....deprecated...". 
I've altered our output file filter program to remove these warnings from the final output we see, so it's okay for the moment, but I'd obviously like to deal with the underlying issue(s) before the warnings become errors. 
So, does anyone have any technique which could help here? A source scanner with intelligent replace? Some trick to help with amending an export file? 
I'm particularly worried about the ones like scan and length where the old code uses $result further down, and the new code needs to populate a variable or use the function inside the if/while statements. 

Not holding out a lot of hope, but this is going to be a big nasty job without something. 

Regards, 
Iain

That is a good idea... I do the same myself using notepad++...

Can you copy here any expressions 

------------------------------
Osman Shariff

Original Message:
Sent: 11-12-2024 03:11
From: Luis Vila
Subject: 10.4.03 deprecated proc

Hi

What I do in every migration from version 9 to 10 is pass the XML exports through various scripts to correct these deprecated statements/functions. Scripts are based on regular expressions and correct the original code. In many cases is not so easy as it seems. Specially with "uppercase something SOMETHING" to "SOMETHING = $uppercase(something)"... because "something" could be a lot of things. I always wonder why the compiler do not transform all of them, hoping it will do someday. Nevertheless, I make these corrections to avoid my customers thousands of warnings because they are already reluctant to move to version 10 and I don't want to give them excuses to stay on version 9.

I also take this opportunity to remove COL=0/COL=9 from FORMPIC and ending spaces in code as they gave me problems in some migration.

All is done directly in the v9 XML using regular expression with sed command.

Regards

------------------------------
Luis Vila
luis.vila@uniface.es
Spain

Original Message:
Sent: 10-29-2024 05:26
From: Iain Sharp
Subject: 10.4.03 deprecated proc

We had one deprecated proc in our change from 10.3 to 10.4 (sort/e deprecated in favour of just sort). This one was a simple search and replace through an XML dump of the system. 

10.4.03 has introduced 7 deprecated statements, of which we regularly use 6, 4 of which may just be a search and replace (fieldvideo=>$fieldvideo, uppercase=>$uppercase, lowercase=>$lowercase, fieldsyntax=>$fieldsyntax), but the others (length, scan, displaylength) change from being statements with the answer in $result, to functions which require a holder for the answer, thus three or four lines of code can be simplified, but as shown above, they may not be sensible for automatic replacement. 

We have been on Uniface for 15 years, from 8 through to 10.4, (We actually started on 7, but moved to 8 before we'd written much), and this is the most deprecated statements I think I've seen in one go. 
Also, Uniface have given no timeline for the existing statements to be removed, except that it's not liable to be as a result of a patch, so it wont be before (at least) 10.5, giving us time to pick at the problem piecemeal, now I've fixed our full compile filter to remove the warnings so as not to flood our emails. 

Regards, 

Iain

------------------------------
Iain Sharp
Head of Technical Services
Pci Systems Ltd
Sheffield GB

Original Message:
Sent: 10-29-2024 02:45
From: Roger Wallin
Subject: 10.4.03 deprecated proc

Hi,
I'm curious, has there been added a lot of "deprecated proc" in Uniface 10.4.03, compared to 10.4.02, or is this just a general fact for all Uniface 10 versions?
 

------------------------------
Roger Wallin
Abilita Oy

Original Message:
Sent: 10-28-2024 06:15
From: Iain Sharp
Subject: 10.4.03 deprecated proc

I have a program with a BIG list of "I don't care"/"I can't do anything about this" filters to remove warnings from the compiler output, otherwise I'd never spot new issues. So, for the moment, I've added these deprecations to that. I'll need to take them out one at a time and fix the underlying stuff, but I haven't the man-days at the moment.

Iain








Iain Sharp | Head of Technical Services
Jonas Metals Software
iains@jonasmetals.com
tel +44 (0) 114 201 2200
<http: www.jonasmetals.com> www.jonasmetals.com <https: outlook.office.com bookwithme user 997d39a6e5de467e8d015be1a0380183@pcisystems.co.uk?anonymous&ep=pcard> Book Time With Me


Original Message:
Sent: 10/28/2024 6:08:00 AM
From: Ingo Stiller
Subject: RE: 10.4.03 deprecated proc

Oh yeh, the #includes

Took me quite a bit of time to suppress all the warnings.
Especially since I have includes on almost all levels*) and the order in which UnifAce loads the includes is also not deterministic :-)

*) Component, entity collection, entity occurence. And higly configurable by #define

------------------------------
Ingo Stiller
Aareon Deutschland GmbH

Original Message:
Sent: 10-28-2024 05:54
From: Iain Sharp
Subject: 10.4.03 deprecated proc

Yeah, that's mostly what I was afraid of. 
A small glimmer of silver in the cloud is that I think a reasonable amount of the repeated warnings comes from one or two bits of #include code, so changing them will drastically cut the job down, but it will still be quite some task. 

------------------------------
Iain Sharp
Head of Technical Services
Pci Systems Ltd
Sheffield GB

Original Message:
Sent: 10-28-2024 04:45
From: Ingo Stiller
Subject: 10.4.03 deprecated proc

Hi Iain

Nope, there is no tool to do so.
A long time ago we had the challenge of replacing RUN with a global routine (this was before ACTIVATE existed). I wrote a program that searched for RUN, analyzed the switches and turned the whole thing into a call for the global routine. It worked reasonably well, it was just stupid that a colleague had named a label  "RUNDEN:", which was also tried to be converted :-)

The advantage of the "RUN" case is that only one line of code needs to be considered.
But with SCAN and LENGTH, there are at least two lines involved. And who guarantees that they are directly behind each other? 
Example

putmess "Hello World, I'm about to scan $1 for hello"
scan $1,"hello"
putmess "Just scanned $1 and found hello at pos %%$result%%%"
$2 = $result
putmess "Today is a sunny day, so I also store the postion time 4 in $3"
$3 = $result*4

What may be possible is this.

scan $1,"hello"

convert to

$result = $scan($1,"hello")

So search for "scan"  at the begin of a line (skip whitspaces)(e.g.  can be done with the new RegExpression in UnifAce)
Insure that "scan" is an isolated word (see the problem with run.)
'Extract' the parameter for scan (i.e. start the line at pos+4)
Replace the line with v_LINE = $concat( "$result = $scan(" , v_LINE[v_POS_SCAN+4] , ")" )

This is just a simple example, maybe there is a whitespace after the scan statement that you don't want to copy etc.
For LENGTH->$LENGTH the idea is the same
After this replacement, you do use the new UnifAce verbs, but still have $result as a temporary storage.
But this can't be done without the knowledge of the old programm code

 

------------------------------
Ingo Stiller
Aareon Deutschland GmbH

Original Message:
Sent: 10-25-2024 11:38
From: Iain Sharp
Subject: 10.4.03 deprecated proc

So, we are trying to get on 10.4.3 so we can play with the new toys we saw in Amsterdam. 
Installed it, imported an XML of out code and compiled everything. 
Wham! An output file with thousands of "Warning....deprecated...". 
I've altered our output file filter program to remove these warnings from the final output we see, so it's okay for the moment, but I'd obviously like to deal with the underlying issue(s) before the warnings become errors. 
So, does anyone have any technique which could help here? A source scanner with intelligent replace? Some trick to help with amending an export file? 
I'm particularly worried about the ones like scan and length where the old code uses $result further down, and the new code needs to populate a variable or use the function inside the if/while statements. 

Not holding out a lot of hope, but this is going to be a big nasty job without something. 

Regards, 
Iain

------------------------------
Iain Sharp
Head of Technical Services
Pci Systems Ltd
Sheffield GB
------------------------------
</https:></http:>

Hi

For instance, 

------------------------------
Luis Vila (freelance)
luis.vila@uniface.es
Spain

Original Message:
Sent: 11-12-2024 05:02
From: Osman Shariff
Subject: 10.4.03 deprecated proc

That is a good idea... I do the same myself using notepad++...

Can you copy here any expressions 

------------------------------
Osman Shariff

Original Message:
Sent: 11-12-2024 03:11
From: Luis Vila
Subject: 10.4.03 deprecated proc

Hi

What I do in every migration from version 9 to 10 is pass the XML exports through various scripts to correct these deprecated statements/functions. Scripts are based on regular expressions and correct the original code. In many cases is not so easy as it seems. Specially with "uppercase something SOMETHING" to "SOMETHING = $uppercase(something)"... because "something" could be a lot of things. I always wonder why the compiler do not transform all of them, hoping it will do someday. Nevertheless, I make these corrections to avoid my customers thousands of warnings because they are already reluctant to move to version 10 and I don't want to give them excuses to stay on version 9.

I also take this opportunity to remove COL=0/COL=9 from FORMPIC and ending spaces in code as they gave me problems in some migration.

All is done directly in the v9 XML using regular expression with sed command.

Regards

------------------------------
Luis Vila
luis.vila@uniface.es
Spain

Original Message:
Sent: 10-29-2024 05:26
From: Iain Sharp
Subject: 10.4.03 deprecated proc

We had one deprecated proc in our change from 10.3 to 10.4 (sort/e deprecated in favour of just sort). This one was a simple search and replace through an XML dump of the system. 

10.4.03 has introduced 7 deprecated statements, of which we regularly use 6, 4 of which may just be a search and replace (fieldvideo=>$fieldvideo, uppercase=>$uppercase, lowercase=>$lowercase, fieldsyntax=>$fieldsyntax), but the others (length, scan, displaylength) change from being statements with the answer in $result, to functions which require a holder for the answer, thus three or four lines of code can be simplified, but as shown above, they may not be sensible for automatic replacement. 

We have been on Uniface for 15 years, from 8 through to 10.4, (We actually started on 7, but moved to 8 before we'd written much), and this is the most deprecated statements I think I've seen in one go. 
Also, Uniface have given no timeline for the existing statements to be removed, except that it's not liable to be as a result of a patch, so it wont be before (at least) 10.5, giving us time to pick at the problem piecemeal, now I've fixed our full compile filter to remove the warnings so as not to flood our emails. 

Regards, 

Iain

------------------------------
Iain Sharp
Head of Technical Services
Pci Systems Ltd
Sheffield GB

Original Message:
Sent: 10-29-2024 02:45
From: Roger Wallin
Subject: 10.4.03 deprecated proc

Hi,
I'm curious, has there been added a lot of "deprecated proc" in Uniface 10.4.03, compared to 10.4.02, or is this just a general fact for all Uniface 10 versions?
 

------------------------------
Roger Wallin
Abilita Oy

Original Message:
Sent: 10-28-2024 06:15
From: Iain Sharp
Subject: 10.4.03 deprecated proc

I have a program with a BIG list of "I don't care"/"I can't do anything about this" filters to remove warnings from the compiler output, otherwise I'd never spot new issues. So, for the moment, I've added these deprecations to that. I'll need to take them out one at a time and fix the underlying stuff, but I haven't the man-days at the moment.

Iain








Iain Sharp | Head of Technical Services
Jonas Metals Software
iains@jonasmetals.com
tel +44 (0) 114 201 2200
<http: www.jonasmetals.com> www.jonasmetals.com <https: outlook.office.com bookwithme user 997d39a6e5de467e8d015be1a0380183@pcisystems.co.uk?anonymous&ep=pcard> Book Time With Me


Original Message:
Sent: 10/28/2024 6:08:00 AM
From: Ingo Stiller
Subject: RE: 10.4.03 deprecated proc

Oh yeh, the #includes

Took me quite a bit of time to suppress all the warnings.
Especially since I have includes on almost all levels*) and the order in which UnifAce loads the includes is also not deterministic :-)

*) Component, entity collection, entity occurence. And higly configurable by #define

------------------------------
Ingo Stiller
Aareon Deutschland GmbH

Original Message:
Sent: 10-28-2024 05:54
From: Iain Sharp
Subject: 10.4.03 deprecated proc

Yeah, that's mostly what I was afraid of. 
A small glimmer of silver in the cloud is that I think a reasonable amount of the repeated warnings comes from one or two bits of #include code, so changing them will drastically cut the job down, but it will still be quite some task. 

------------------------------
Iain Sharp
Head of Technical Services
Pci Systems Ltd
Sheffield GB

Original Message:
Sent: 10-28-2024 04:45
From: Ingo Stiller
Subject: 10.4.03 deprecated proc

Hi Iain

Nope, there is no tool to do so.
A long time ago we had the challenge of replacing RUN with a global routine (this was before ACTIVATE existed). I wrote a program that searched for RUN, analyzed the switches and turned the whole thing into a call for the global routine. It worked reasonably well, it was just stupid that a colleague had named a label  "RUNDEN:", which was also tried to be converted :-)

The advantage of the "RUN" case is that only one line of code needs to be considered.
But with SCAN and LENGTH, there are at least two lines involved. And who guarantees that they are directly behind each other? 
Example

putmess "Hello World, I'm about to scan $1 for hello"
scan $1,"hello"
putmess "Just scanned $1 and found hello at pos %%$result%%%"
$2 = $result
putmess "Today is a sunny day, so I also store the postion time 4 in $3"
$3 = $result*4

What may be possible is this.

scan $1,"hello"

convert to

$result = $scan($1,"hello")

So search for "scan"  at the begin of a line (skip whitspaces)(e.g.  can be done with the new RegExpression in UnifAce)
Insure that "scan" is an isolated word (see the problem with run.)
'Extract' the parameter for scan (i.e. start the line at pos+4)
Replace the line with v_LINE = $concat( "$result = $scan(" , v_LINE[v_POS_SCAN+4] , ")" )

This is just a simple example, maybe there is a whitespace after the scan statement that you don't want to copy etc.
For LENGTH->$LENGTH the idea is the same
After this replacement, you do use the new UnifAce verbs, but still have $result as a temporary storage.
But this can't be done without the knowledge of the old programm code

 

------------------------------
Ingo Stiller
Aareon Deutschland GmbH

Original Message:
Sent: 10-25-2024 11:38
From: Iain Sharp
Subject: 10.4.03 deprecated proc

So, we are trying to get on 10.4.3 so we can play with the new toys we saw in Amsterdam. 
Installed it, imported an XML of out code and compiled everything. 
Wham! An output file with thousands of "Warning....deprecated...". 
I've altered our output file filter program to remove these warnings from the final output we see, so it's okay for the moment, but I'd obviously like to deal with the underlying issue(s) before the warnings become errors. 
So, does anyone have any technique which could help here? A source scanner with intelligent replace? Some trick to help with amending an export file? 
I'm particularly worried about the ones like scan and length where the old code uses $result further down, and the new code needs to populate a variable or use the function inside the if/while statements. 

Not holding out a lot of hope, but this is going to be a big nasty job without something. 

Regards, 
Iain

------------------------------
Iain Sharp
Head of Technical Services
Pci Systems Ltd
Sheffield GB
------------------------------
</https:></http:>