Uniface User Forum

 View Only
  • 1.  10.4.03 deprecated proc

    PARTNER
    Posted 13 days ago

    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
    ------------------------------


  • 2.  RE: 10.4.03 deprecated proc

    Posted 10 days ago

    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
    ------------------------------



  • 3.  RE: 10.4.03 deprecated proc

    PARTNER
    Posted 10 days ago

    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
    ------------------------------



  • 4.  RE: 10.4.03 deprecated proc

    Posted 10 days ago

    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
    ------------------------------



  • 5.  RE: 10.4.03 deprecated proc

    PARTNER
    Posted 10 days ago
    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




  • 6.  RE: 10.4.03 deprecated proc

    PARTNER
    Posted 9 days ago

    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
    ------------------------------



  • 7.  RE: 10.4.03 deprecated proc

    PARTNER
    Posted 9 days ago

    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=>$fieldvideouppercase=>$uppercaselowercase=>$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
    ------------------------------