Michael,

We have built a piece of basic which can fix most of the BBX-> Eloquence
code problems for UX , barring those where the context is ambiguous, at
least in isolation. It comments all the unavailable statements, changes
others, splits most multi statement lines etc. The Image subset stuff is
hard to fix automatically, and adding labels for Image statements we do in a
separate pass.
How much fixing does your Perl program do? Where can it run - mpe, Windoze,
UX?

thanks,
jp
----- Original Message -----
From: "Michael Marxmeier" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Friday, February 13, 2004 10:39 PM
Subject: Re: [HP3000-L] MPE (was foliies) - now image from ?? - eloquence


> To provide some background ...
>
> John is looking into porting Business Basic programs to Eloquence.
> The limitations that John mentions do not apply when using the
> image3k library (all languages besides bbasic).
>
> Let me provide some notes on porting bbasic language programs
> to the Eloquence language.
>
> Syntax
> ------
>
> The Eloquence syntax is slightly different from bbasic.
> However a conversion does not seem difficult. As a proof of
> concept i wrote a small perl program that takes care of most
> of the differences.
>
> Most visible differences:
>
> - Eloquence only supports a single statement per line
>    while bbasic allows to use a ';' to separate multiple
>    statements.
> - Multiple assignments like A,B,C=0 would become A=B=C=0
>
> Database
> --------
>
> The Eloquence language has its own image calls (it is not using
> the image3k library) and thus some problems are expected at this
> point.
>
> As John notes, the Eloquence language runtime does currently not
> support item lists. Traditionally, Eloquence programs use a language
> mechanism to "bind" program variables to database items (w/o the
> need to explicitly pack/unpack or item lists).
> However this looks to be a problem for MPE bbasic programs that
> depend on item lists and pack/unpack and we consider to item
> list support to the language runtime.
>
> Screen I/O
> ----------
>
> Eloquence is terminal independend. As a consequence, sending ESC
> sequences to the terminal has no effect. However Eloquence
> implements the equivalent of a HP like terminal as a virtual screen.
> Translating the ESC sequences to equivalent screen operations could
> likely be done mostly automatically (or we may consider to translate
> the ESC sequences dynamically in the screen manager).
>
> For example:
> PRINT '27"&dD";Underlined;'27"&d@"
>
> might be replaced by either:
> PRINT CHR$(132);Underlined;CHR$(128)
>
> or:
> CURSOR UL(10)
> PRINT "Underlined"
>
> As a quick solution you could possibly bypass the Eloquence screen
> manager (and do it all yourself) but this is not a recommended
> solution.
>
>
>  > Caveats so far----only @ list read/writes supported, no partial
>  > lists, and 64 bit libs not supported .
>
> This is a limitation of the Eloquence language. It currently does
> not support item lists.
> 64 bit mode is currently not supported when combining functions
> written in C with the Eloquence language runtime (Eloquence DLL).
>
>  > Query leaves something to be desired.
>
> Agreed :-)
> A QUERY/3000 compatible replacement is worked on.
>
>
> Hope this helps
> Michael
>
> John Pitman wrote:
> > Yes, the Image libs on ux seem pretty good....up to a point.
> > We have converted some block mode screen handling C code reading/writing
> > Image sets VERY quickly from MPE to UX.
> > Caveats so far----only @ list read/writes supported, no partial lists,
and
> > 64 bit libs not supported . We are using gcc 3.01. - seems the latest I
> > could see that had 32 bit libs. Once we went there, the links worked and
the
> > code goes. The DBEXPORT and Import stuff is also easy to use. Query
leaves
> > something to be desired. The Eloquence Basic also has quite a few
drawbacks
> > compared to HP MPE BBX, and we are just starting to evaluate the built
in
> > screen handler for how it compares to our traditional screen usage -
> > Block/Line/format one field at a time, and usage of multiple pages of
> > memory, push down scrolls etc.
> > We have used C code that either builds the screen layout from hard coded
> > data (literal "xyz" at row,col, unprotected field x long at row, col),
or a
> > screen stored in a file (1 variable asci record per screen line,
complete
> > with esc sequences), and they are quite portable - work on both systems
with
> > practically no changes.
> > Unfortunately, the bulk of our code is still Bas/V and BBX......anybody
got
> > a Bas/V to C converter???
> >
> > jp
>
> --
> Michael Marxmeier           Marxmeier Software AG
> E-Mail: [log in to unmask]  Besenbruchstrasse 9
> Phone : +49 202 2431440     42285 Wuppertal, Germany
> Fax   : +49 202 2431420     http://www.marxmeier.com/
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *