Personal Rexx (Quercus) or what?
LurfysMa
new computers and upgrade to Win XP. Is there a better version of Rexx
for Windows that I might want to consider getting?
I would like something that is supported. I am not looking for
something for free.
I would like something that supports at least a few of the Windows UI
features lile combo boxes and pop-up windows.
Is there a version that support even some primitive database
functions?
I found a few searching:
http://www.borg.com/~jglatt/rexx/win32/rxusrw32.htm
Reginald Rexx. Appears to be free. How well is it supported?
http://www-306.ibm.com/software/awdtools/obj-rexx/windows/index.html
IBM offers Object Rexx for Windows. I couldn't find a price.
http://www.kilowattsoftware.com/r4Page.htm
Rexx 4.00. Appears to be free.
Any others?
--
Using Personal Rexx for Windows 3.50 from Quercus
OS: Win 2K
Michael Lueck
> http://www-306.ibm.com/software/awdtools/obj-rexx/windows/index.html
>
> IBM offers Object Rexx for Windows. I couldn't find a price.
Maybe due to that product being open sourced. Try looking over at: http://www.oorexx.org/
ooRexx, as did its predecessor Object Rexx, has GUI capabilities in the Windows version. It is called OODialog.
For connections to databases, I use Mark Hessling's RexxSQL, found here: http://rexxsql.sourceforge.net/index.html
I use RexxSQL only via the ORexxSQL class library. Second to the last line on that page (above) has a link to the ORexxSQL class library.
--
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/
LurfysMa
<mlu...@lueckdatasystems.com> wrote:
>LurfysMa wrote:
>
>> http://www-306.ibm.com/software/awdtools/obj-rexx/windows/index.html
>>
>> IBM offers Object Rexx for Windows. I couldn't find a price.
>
>Maybe due to that product being open sourced. Try looking over at: http://www.oorexx.org/
>
>ooRexx, as did its predecessor Object Rexx, has GUI capabilities in the Windows version. It is called OODialog.
>
>For connections to databases, I use Mark Hessling's RexxSQL, found here: http://rexxsql.sourceforge.net/index.html
>
>I use RexxSQL only via the ORexxSQL class library. Second to the last line on that page (above) has a link to the ORexxSQL class library.
Is ooRexx now the foremost Rexx offering?
How does it compare to Regina Rexx and Reginald Rexx?
After reading through the information on the various websites, it
appears that ooRexx is a much more active development effort.
Mark Miesfeld
> Is ooRexx now the foremost Rexx offering?
I don't know about foremost, but I think at this point it is a top
choice.
> How does it compare to Regina Rexx and Reginald Rexx?
Regina Rexx is rock solid of course, but I think for a GUI interface
ooRexx's OODialog is better. I haven't used Reginald.
> After reading through the information on the various websites, it
> appears that ooRexx is a much more active development effort.
ooRexx is being actively developed and I think the prospects look good
down the road. I also think the support for ooRexx has been improving
quite a bit for the last year and is pretty good right now.
--
Mark Miesfeld
LurfysMa
wrote:
>On Apr 30, 6:49 pm, LurfysMa <inva...@invalid.invalid> wrote:
>
>> Is ooRexx now the foremost Rexx offering?
>
>I don't know about foremost, but I think at this point it is a top
>choice.
>
>> How does it compare to Regina Rexx and Reginald Rexx?
>
>Regina Rexx is rock solid of course, but I think for a GUI interface
>ooRexx's OODialog is better. I haven't used Reginald.
What about the editor / developer environment? I see that Regina uses
THE, which is based on XEDIT, the VM/CMS editor I used so many years
ago. I still think it's the best editor I've ever used.
What about the debugging tools? Reginald claims a GUI debugger a la
VB. It looked to me like ooRexx just has the Trace command from
classic Rexx.
>> After reading through the information on the various websites, it
>> appears that ooRexx is a much more active development effort.
>
>ooRexx is being actively developed and I think the prospects look good
>down the road. I also think the support for ooRexx has been improving
>quite a bit for the last year and is pretty good right now.
I don't suppose there's a website that compares the leading
offerings...
LurfysMa
<jgl...@spamgone-borg.com> wrote:
>>LurfysMa
>> How does Object Rexx compare to Reginald Rexx?
>
>>What about the editor / developer environment?
>
>>What about the debugging tools?
>
>As the developer/maintainer of Reginald and all its tools, I can assure you
>that its development is very active. Right now, I'm working on multi-threaded
>support (ie, a REXX script will be able to run multiple "REXX threads". This
>will be very useful on multi-core processors).
>
>Reginald has a full-fledged IDE called "REXX Programmer Center" (ie, RPC). This
>is more than just an editor. Of course, it does offer a fully customizable
>editor. (ie, You can change key assignments for all its commands, reconfigure
>the icons in the toolbar, edit multiple source files in tabbed windows, edit
>text via the mouse, dock/undock windows, etc).
>
>RPC also has a built-in debugger. You can set breakpoints by clicking on your
>source lines, step through the code, and see the results displayed in the
>debugger "results window", watch variables (mark certain variables so that the
>debugger breaks when the value changes), examine the "memory" of various REXX
>variables in the "variables window" (which automatically updates when the
>values of any of those variables change), etc.
>
>But that's not all. Reginald is geared for programmers who wish to make
>software that has a modern windows UI. Because of that, RPC has a fully
>featured dialog editor built into it. You can create your windows/dialogs just
>by dragging/dropping the desired controls onto your own "window template",
>positioning/sizing them with the mouse. Reginald supports all of the Windows
>controls from push buttons to listviews to calendars, etc. And RPC creates a
>skeleton REXX script for you containing all the code to create/display/operate
>that window and its controls. Just run the script, and your user interface will
>pop up.
>
>But the real time saver is how RPC assists you in easily adding REXX
>instructions to handle any event for any control. For example, let's say you
>want to handle the "CLICK" event for one of the push buttons in your window.
>(This event happens when the user clicks on the button). Just click on that
>push button control in your window template to bring up the Properties dialog
>for that control. In the "Events" listbox, you'll see all the events you can
>handle for a push button. Double-click on the "CLICK" event, and RPC will add a
>function in your REXX script that is automatically called whenever the user
>clicks on that push button. You simply add your own instructions (to that new
>function) to handle that event. This is how you add instructions to any event
>for any control. It's similiar to how you work with adding code to handle
>control events in Microsoft IDEs from Visual C++ to VB NET.
>
>You may also need to make menus, so of course, RPC has a built-in graphical
>menu editor. Build up your menu by clicking on an actual menubar template to
>add new items to it. And attach your menu to your window just by bringing up
>the Properties dialog for your window, and picking out the desired menu in the
>dropdown list. Adding your own instructions to handle the user selecting a menu
>item is just as easy as with a control. Just click on the desired menu item to
>bring up its Properties dialog. Again, it's all meant to mimic the easy
>GUI-building capabilities of MS IDEs.
>
>You sometimes may want your own custom icons/bitmaps for controls. So, RPC has
>a built-in icon/bitmap editor to graphically create your own images. And you
>can easily assign those images to be displayed by controls. For example, click
>on a particular button to bring up its Properties dialog. Pick out the desired
>image from the dropdown list. RPC will modify your script so that image is
>displayed in the button when you run the script.
>
>In other words, RPC has all of the built-in tools to graphically create your
>UI, and RPC has the smarts to write out a REXX script to create/display/operate
>that UI, and assist you in adding your own code to handle control/menu events.
>
>But that's not all. I'm a stickler for good documentation. RPC has a "help
>window" that lists all of the online help books. There over a dozen help books
>that cover the REXX language itself, how RPC's builtin dialog/menu/image
>editors work, details on all of the properties for each control and their
>events, and books for all of the various add-on DLLs available for Reginald.
>You can browse the tree listing of books, reading the various pages of each one
>in RPC's help window. You can even add your own books to this help window.
>
>And all of this online help is fully integrated. For example, let's say you're
>coding a REXX line as so:
>
>data = LINEIN(...
>
>You forgot the details of the LINEIN function. Just highlight the word LINEIN
>in the text editor and press the F1 key. RPC will present all the information
>about the LINEIN builtin function, in its help window.
>
>What Reginald and its tools seek to provide, is a real IDE comparable to the
>quality of MS dev tools.
>
>======================================
>
>Now as for a comparison to Object REXX. IBM's version of Object REXX did have a
>built-in dialog editor. But, it didn't support many of the newer windows
>controls, such as listviews, calendars, etc. And it didn't support many of the
>new features MS subsequently added to older controls, such as drag list boxes,
>and lots of the newer properties of controls. Unlike RPC, the dialog editor did
>not assist you in adding REXX instructions to handle any of the events for that
>control, nor initializing the state of those controls. You had to do that by
>hand. Object REXX had no menu/image editors.
>
>When IBM open-sourced Object REXX, it had a licensing problem with its IDE. So
>you no longer get that dialog editor with ooREXX. You can still run scripts
>that contain instructions to create a UI, and they will create that UI. (This
>is what is meant when someone says it still supports ooDialog). But if you want
>to create your own UI, you don't do it from a dialog editor. You have to
>manually write those REXX instructions to create the UI yourself.
>
>As far as the debugger, ooREXX is pretty much the standard trace output. Its
>IDE allowed you to set breakpoints though, unlike with just a standalone REXX
>interpreter. And it allowed you to enter variable names whose values would be
>displayed. But again, I'm not sure if there's an editor for ooREXX that
>supports this any more.
>
>It didn't have the online help that RPC has. Nor did its IDE have as much
>configuration options.
>
>Both interpreters support COM. (But in different ways. Reginald deliberately
>chooses a method that is very similiar to Visual BASIC so that you can more
>easily apply any VB example code to Reginald). Both interpreters support
>calling functions in DLL's not designed specifically for REXX. (But I think
>Reginald's FUNCDEF feature is a lot more streamlined and easier than the method
>ooREXX uses).
>
>Reginald supports some of the non-standard features of ooREXX such as the USE
>ARG, RAISE, and DO OVER statements, and "tail expressions". Reginald also
>offers some Net REXX features that ooREXX doesn't such as the CATCH and FINALLY
>statements (ie, real, structured exception handling) and the SELECT shortcut.
>Reginald supports its own version of "REXX objects". (They are simpler than
>ooREXX, and don't support some things like multiple inheritance. But they are
>also a bit easier to create. There are no special instructions/definitions for
>objects. In Reginald, you simply put each object into its own script). Reginald
>has a whole bunch of other, proprietary features, such as a SORT instruction. a
>plethora of built-in functions to list/move/delete files/directories, the
>option to make comparisons case-insensitive, macro DLLs (ie, pack up a group of
>scripts into a DLL), an advanced INTERPRET instruction, etc. This is all
>documented in the online help.
>
>Since all of this stuff is freely available, the best thing to do is just try
>it out for yourself to see if it suits your needs. You have nothing to lose.
>Get downloads from:
>
>http://users.adelphia.net/~jgglatt/rexx/rexxuser.htm
>
>And for more information, visit the Reginald forum at:
>
>http://nnnn.3322.org/?a=f&b=1
>
>In particular, read my message "For the Reginald newbie".
Wow. That is impressive.
And all this is free? I didn't a price anywhere, but I also didn't see
anything saying that it is free.
Alessandro Brezzi
On May 1, 6:01 am, LurfysMa <inva...@invalid.invalid> wrote:
> On 30 Apr 2007 20:04:59 -0700, Mark Miesfeld <miesf...@gmail.com>
I want to add some point:
1. ooRexx is multithread from long ago (almost IBM oRexx 3.0)
2. ooRexx support Windows Scripting, so you can find many example at
MicroSoft site
3. ooRexx script, object and classic, run on Windows and Linux - AIX
(I've done many cross platform projects)
4. IBM oRexx (Windows only) contain a WorkPlace, IDE for developping /
debugging, also the GUI part
5. ooRexx in Windows can manipulate OLE object; I've used it to create
and format EXCEL objects
After some initial effort, I've loved the object part of oRexx, and I
stay with ooRexx for my projects.
HTH
Alessandro
LurfysMa
<jgl...@spamgone-borg.com> wrote:
>>LurfysMa
>>And all this is free?
>
>All free.
How is this possible? Are you the heir to some oil fortune or the
crown jewels? Did you win the lottery? This has to have been more than
a full time job.
Shmuel (Seymour J.) Metz
at 02:09 PM, LurfysMa <inv...@invalid.invalid> said:
>I would like something that is supported. I am not looking for
>something for free.
Sometimes free software has excellent support. It's worth looking at
Opensource Object REXX (OOREXX) and at Regina. OTOH, if you insist on
a chargeable product my experience with Personal REXX, way back when,
was good.
>Reginald Rexx.
I wouldn't touch it due to compatibility issues; YMMV.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org
LurfysMa
<spam...@library.lspace.org.invalid> wrote:
>In <hslc33lu116ntvlm2...@4ax.com>, on 04/30/2007
> at 02:09 PM, LurfysMa <inv...@invalid.invalid> said:
>
>>I would like something that is supported. I am not looking for
>>something for free.
>
>Sometimes free software has excellent support. It's worth looking at
>Opensource Object REXX (OOREXX) and at Regina. OTOH, if you insist on
>a chargeable product my experience with Personal REXX, way back when,
>was good.
I don't *insist* on paying ;-) I was just trying to make clear that I
was *willing* to pay.
>>Reginald Rexx.
>
>I wouldn't touch it due to compatibility issues; YMMV.
What type of compatibility and with what?
If the IDE is as good as it claims to be, that is a huge development
advantage. I love Rexx because of the ease of knocking out a quick
little routine without much overhead, but the development tools have
been meager. Once you get past a few hundred lines of code, better
development tools are a real plus.
I'd pay for Reginald just for the context-sensitive help and dynamic
syntax help. Just being able to see the syntax for POS() would
probably save me one day a year. I can never remember if it's
pos(needle,haystack) or pos(haystack,needle). ;-)
Mark Miesfeld
>
>
> ======================================
>
> Now as for a comparison to Object REXX. IBM's version of Object REXX did have a
> When IBM open-sourced Object REXX, it had a licensing problem with its IDE. So
> you no longer get that dialog editor with ooREXX. You can still run scripts
> that contain instructions to create a UI, and they will create that UI. (This
> is what is meant when someone says it still supports ooDialog). But if you want
> to create your own UI, you don't do it from a dialog editor. You have to
> manually write those REXX instructions to create the UI yourself.
This seems to be a prevalent myth.
While it is true the IBM Object REXX IDE was not open sourced, it is
untrue that you have to manually write REXX instructions to create the
UI when using ooDialog.
ooDialog supports using a resource script file (*.rc), using a
compiled resource in a DLL, or dynamically coding the instructions for
the UI. That hasn't changed.
You can use *any* available Windows resource editor and / or resource
compiler to create a resource script or a DLL to use with ooDialog.
There are a number of good, free resource editors available. And,
there are a number of very good, inexpensive resource editors
available.
Coding a UI by hand is tedious, I would always use a resource editor.
There is no reason to code an ooDialog UI by hand, unless you simply
want to.
--
Mark Miesfeld
Shmuel (Seymour J.) Metz
at 08:07 AM, LurfysMa <inv...@invalid.invalid> said:
>What type of compatibility and with what?
There have been discussions here in the past where the author made
clear that he is not concerned with compatibility. Since my interest
in REXX as a cross-platform tool, that was a red flag.
>If the IDE is as good as it claims to be, that is a huge development
>advantage.
Try it and see. If you don't need to move your code to other platforms
then it might be a viable option.
>Once you get past a few hundred lines of code, better
>development tools are a real plus.
Yeah, I have that problem with Perl.
>dynamic syntax help.
I find viewing the manual to be all that I need for that. Doesn't
windoze have a facility comparable to the OS/2 HELP and VIEW commands?
LurfysMa
<spam...@library.lspace.org.invalid> wrote:
>In <iale33d9a9amft6he...@4ax.com>, on 05/01/2007
> at 08:07 AM, LurfysMa <inv...@invalid.invalid> said:
>
>>What type of compatibility and with what?
>
>There have been discussions here in the past where the author made
>clear that he is not concerned with compatibility. Since my interest
>in REXX as a cross-platform tool, that was a red flag.
>
>>If the IDE is as good as it claims to be, that is a huge development
>>advantage.
>
>Try it and see. If you don't need to move your code to other platforms
>then it might be a viable option.
My use of Rexx would be Windows only and mostly for personal use.
Unlikely that anyone else would ever use any of my execs and highl;y
unlikely that I would need to run them on another platform.
>>Once you get past a few hundred lines of code, better
>>development tools are a real plus.
>
>Yeah, I have that problem with Perl.
>
>>dynamic syntax help.
>
>I find viewing the manual to be all that I need for that. Doesn't
>windoze have a facility comparable to the OS/2 HELP and VIEW commands?
Why view the manual when the syntax pops up as I write the code? I am
always looking up the options for even the most common functions.
Gary Scott
>>LurfysMa
>>And all this is free?
>
>
> Well, Reginald and all its support wasn't done overnight. I've been working on
> this for numerous years now. When I first started, all I had was the Reginald
> interpreter. I was using Notepad to write scripts. And the "debugger" for
> Reginald was a rather simple graphical window that didn't have nearly the
> features that the current IDE has.
>
> Then I worked on the IDE, with an integrated debugger, and released that. Some
> of the documentation was actually written way back when I was using OS/2, and
> was fleshed out, reformatted, and integrated into the IDE.
>
> Then I added the UI-builder, and a new gui add-on.
>
> And there have been lots of other add-ons that were released over the course of
> time.
>
> There is more support that is being worked on, but hasn't been finished yet,
> such as the mult-threaded support. (I'm also toying with the idea of making a
> real REXX compiler -- to turn a REXX script into a real executable. Currently,
> Reginald's method of packing REXX scripts into EXE or DLL is not a real
> compilation).
Java byte code?
>
> So, given the long time frame in which this has been accomplished, it may not
> be as daunting a task as it appears to be for someone just looking at Reginald
> today.
>
>
>>This has to have been more than a full time job.
>
>
> I'm a workaholic. I also happen to be a pretty fast coder. Those two things
> help make things happen at a good pace.
>
> Yes, Reginald represents a significant investment of programming time. As
> you'll learn from the Reginald forum, no current user of Reginald in any way
> feels as if they've chosen a tool that limits them, or is less actively
> developed, than any other REXX choice out there.
--
Gary Scott
mailto:garylscott@sbcglobal dot net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
Przemysław Pawełczyk
Jeff Glatt <jgl...@spamgone-borg.com> wrote:
> Nevertheless, Reginald is being ported to Ubuntu (Linux).
Hi,
OT. I'd love it to be ported to *BSD (NetBSD). If Reginald IDE is close
to EPM/2 editor from OS/2 I'd love it square! :-)
For a long time, too long, Rexx versions for GNU/Linux and *BSD were
without GUI functions. So I used to run Xdialog (gtk+1.2). Now we have
rexx/DW (which was too cumbersome to me - I used to program in
DrDialog/DrRexx - and without good documentation) and gtkrxdlg
(gtk+2.xx; similar to Xdialog without loopback functions). From What you
said Reginald for *NIX would be excellent choice.
Regards,
--
Przemysław Pawełczyk <pp...@o2.pl>
The LearN@BSD Project - http://pp.kv.net.pl
Gary Scott
>>Gary Scott
>>I'm also toying with the idea of making a
>>real REXX compiler -- to turn a REXX script into a real executable. Currently,
>>Reginald's method of packing REXX scripts into EXE or DLL is not a real
>>compilation).
>
>
>>Java byte code?
>
>
> Nope. I don't see that as an executable. What I foresee is translating REXX
> instructions to assembly instructions, and then just invoking an
> assembler/linker to create the executable. So, since there are already
> assemblers/linkers out there, the hardest part is to translate REXX to assembly
> instructions.
Well yes, I was recommending a version that produces byte code (may
already exist, I'm not aware). Seems more portable to me. Perhaps MSIL.
Gary Scott
> On Tue, 01 May 2007 19:57:12 -0400
> Jeff Glatt <jgl...@spamgone-borg.com> wrote:
>
>
>>Nevertheless, Reginald is being ported to Ubuntu (Linux).
>
> Hi,
>
> OT. I'd love it to be ported to *BSD (NetBSD). If Reginald IDE is close
> to EPM/2 editor from OS/2 I'd love it square! :-)
>
> For a long time, too long, Rexx versions for GNU/Linux and *BSD were
> without GUI functions. So I used to run Xdialog (gtk+1.2). Now we have
> rexx/DW (which was too cumbersome to me - I used to program in
> DrDialog/DrRexx - and without good documentation) and gtkrxdlg
> (gtk+2.xx; similar to Xdialog without loopback functions). From What you
> said Reginald for *NIX would be excellent choice.
> Regards,
It would. It is amazing to me that anyone would pick Perl, but almost
everyone does.
Phil Hobbs
> On Tue, 01 May 2007 19:57:12 -0400
> Jeff Glatt <jgl...@spamgone-borg.com> wrote:
>
>> Nevertheless, Reginald is being ported to Ubuntu (Linux).
> Hi,
>
> OT. I'd love it to be ported to *BSD (NetBSD). If Reginald IDE is close
> to EPM/2 editor from OS/2 I'd love it square! :-)
>
> For a long time, too long, Rexx versions for GNU/Linux and *BSD were
> without GUI functions. So I used to run Xdialog (gtk+1.2). Now we have
> rexx/DW (which was too cumbersome to me - I used to program in
> DrDialog/DrRexx - and without good documentation) and gtkrxdlg
> (gtk+2.xx; similar to Xdialog without loopback functions). From What you
> said Reginald for *NIX would be excellent choice.
> Regards,
The X2 series of editors by Blair Thompson are direct descendants of the
E family (at least in philosophy and user interface, not in code).
What's more, they use REXX as their macro language! The 32-bit versions
also have a macro recorder, which produces REXX code from keyboard
macros--very useful for hacking text files into some preferred format.
I use them constantly, on DOS, OS/2, Win32, and Linux. The Linux
version is a GUI app like EPM, but the others are all console-mode,
which is perfect. Look for them at www.tangbu.com.
Cheers,
Phil Hobbs
Mark Miesfeld
> >Mark Miesfeld
> >ooDialog supports using a resource script file (*.rc), using a
>
> Interesting. Do you have an example of using Microsoft's Visual C++ dialog
> editor?
These are all good questions. In general, ooDialog hasn't been
updated for quite some time, so it doesn't support all the new
controls, styles, and messages. It is starting to be updated now, but
how much is done will depend on available time.
> What happens if the dialog template contains something like a listview? Or,
> contains a newer property for a standard control, such as a push button's
> BS_PUSHLIKE style?
ooDialog itself doesn't support all the new styles.
> How does it allow handling newer events from controls, and newer messages, such
> as a combobox's CB_SETCUEBANNER?
ooDialog itself doesn't support the newer events, messages, etc..
> What about all of the #defines and #includes that are typically found in an .rc
> file? Does it ignore those? (Or do you really mean that ooRexx uses a .res
> format -- ie, the compiled version of a .rc file? I'm thinking that it would
> have to be the latter, because an .RC file too much mimics a C header file).
No, I do mean a .rc file. ooDialog handles either a .rc file or a .rc
file compiled into .res format. The compiled resource then needs to
be linked into a DLL.
The current implementation handles #defines, only if they are in the
same file. It doesn't handle #includes, but I think that will be
fixed shortly.
I use ResourceBuilder and ooDialog handles the .rc files that
ResourceBuilder generates. I hadn't tried with Microsoft's Visual
Studio 2005 dialog editor until last night. And, you're implication
is correct, ooDialog chokes on the .rc file produced. However, it
took less than a minute to pull the dialog definition out into another
file. Then ooDialog used that .rc file fine. I wouldn't be suprised
if some of the current limitations were fixed in the next couple of
months.
--
Mark Miesfeld
Przemysław Pawełczyk
Phil Hobbs <pc...@SpamMeSenseless.pergamos.net> wrote:
> > OT. I'd love it to be ported to *BSD (NetBSD). If Reginald IDE is
> > close to EPM/2 editor from OS/2 I'd love it square! :-)
>
> The X2 series of editors by Blair Thompson are direct descendants of
> the E family (at least in philosophy and user interface, not in
> code). What's more, they use REXX as their macro language! The
>
> I use them constantly, on DOS, OS/2, Win32, and Linux. The Linux
> version is a GUI app like EPM, but the others are all console-mode,
> which is perfect. Look for them at www.tangbu.com.
Thanks very much. I'll check it with Linux and Win98. I used THE for
several months with a lot of my and others' rexx scripts making it
resembling EPM/2. It's a pity I can not download sources to compile it
under NetBSD. :(
BTW. Excellent GUI editor for Windows is MED.
http://www.utopia-planitia.de/indexus.html
It can be programmed with Rexx what I checked myself several years ago.
As for GUI version it's real fast.
Przemysław Pawełczyk
Przemysław Pawełczyk <pp...@o2.pl> wrote:
> Thanks very much. I'll check it with Linux and Win98. I used THE for
> several months with a lot of my and others' rexx scripts making it
> resembling EPM/2. It's a pity I can not download sources to compile it
> under NetBSD. :(
But of course the last remark concerns X2 not THE! ;)
Cheers,
Gerard Schildberger
|> LurfysMa wrote:
|> Is ooRexx now the foremost Rexx offering?
| I don't know about foremost, but I think at this point it is a top
| choice.
|> How does it compare to Regina Rexx and Reginald Rexx?
| Regina Rexx is rock solid of course, but I think for a GUI interface
| ooRexx's OODialog is better. I haven't used Reginald.
I can't see where you say that REGINA is rock solid. I can't tell
you the number of problems I've found (most problems I've sent in a
bug report), and some of them haven't been worked on, let alone
fixed. It doesn't seem that anyone seems to be working on REGINA
to get the open problems fixed. When was the last time you saw an
updated REGINA?
/*___________________________________Gerard S.*/ say 12345678912//2
Shmuel (Seymour J.) Metz
at 12:41 PM, Gary Scott <garyl...@sbcglobal.net> said:
>It would. It is amazing to me that anyone would pick Perl, but
>almost everyone does.
There are two main reasons for picking Perl; CPAN and regular
expressions. Yes, the syntax is ugly. Yes, the regex syntax is too
terse. But it is too powerful to ignore.
Now, REXX has it's strengths. When exploited, the concept of
registered environments is exteremly powerful for scripting
applications. But in order to get more applications to support it
You're going to have to convince the *ix world to incorporate some of
the plumbing, a difficult political task.
Steve Swift
> There is no reason to code an ooDialog UI by hand, unless you simply
> want to.
Are there any guides to the overall process of writing ooDialog programs
from scratch? I was an ardent fan of VisProRexx (OS/2 only) but have
totally failed to cross the hurdle to UI programming in ooRexx.
--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk
Sahananda
Hi Steve,
Included with the latest releases of ooRexx is a Gui template. I
demonstrated creating a dialog from it in front of a live audience at
last years symposium in about 15 minutes. The process mainly consists
of deleting extraneous code and cutting and pasting sample code.
There are also helper classes called DlgArea & DlgAreaU which help
with design and alignment. Not quite as easy as it used to be with
the resource thingy that IBM used to provide, but not onerous. My
presentation is available at http://www.rexxla.org/Symposium/2006/abstracts.html#jonw1
I think that now that a year is up you don't even have to join the
rexxla to see it (although I would encourage people to join - I have
found it fantastic value).
hth
Jon
Sahananda
> My presentation is available at
http://www.rexxla.org/Symposium/2006/abstracts.html#jonw1
> I think that now that a year is up you don't even have to join the
> rexxla to see it (although I would encourage people to join - I have
> found it fantastic value).
I just checked, and you still need a password to access the
material.
I assume that once this years symposium is finished (later today) and
folks have got back home, someone will get around to unlocking that
stuff in the next couple of weeks.
Jon
Steve Swift
> http://www.rexxla.org/Symposium/2006/abstracts.html#jonw1
I'll take a look - thanks.
Most of my GUI requirements are for personal items, and my day job
doesn't leave a lot of time for that, so it may be some time before I
get around to this.
Mark Miesfeld
> >> My presentation is available at
> >http://www.rexxla.org/Symposium/2006/abstracts.html#jonw1
>
> I'll take a look - thanks.
>
> Most of my GUI requirements are for personal items, and my day job
> doesn't leave a lot of time for that, so it may be some time before I
> get around to this.
Steve,
Jon's work is very cool, and, for people that like to code the dialog
template by hand, a great help.
I've found that it is easier to use a resource editor when I don't
have a lot of time. ooDialog still supports the use of resource
scripts (.rc files) generated by a resource or dialog editor. And,
ooDialog also supports using a dialog template from a compiled
resource script. The only thing missing from the original IBM
ooDialog is the resource editor (and linker) that shipped with the
"Developer" edition of Open Object REXX. However, there are a number
of free and / or open source resource editors. Plus, people that
still have the IBM Developer edition, still have the resource editor
and linker that came with that version. These tools work with ooRexx.
Although - Jeff Glatt has forced me to look a little closer at the
support, and I found it is not as robust as I thought. Nevertheless,
it still works well and I am in the middle of fixing some of the
quirks I've found. So, with ooDialog, using a resource editor is a
very viable method. I also intend to add some documentation on using
ooDialog with some of the common resource editors and links to where
to get the editors. For instance there is the open source OpenWatcom
which contains good resource editors, compilers, and linkers. The
OpenWatcom tools work with ooDialog. I created a test dialog with
those tools yesterday in a few minutes.
--
Mark Miesfeld
Steve Swift
Of course, I'm on the right side of IBM to be able to get hold of the
Developer Edition. :-) I just never got to grips with it, unlike
VisProRexx, which was as easy as falling off a log.
Marten Kemp
>> Gary Scott
>> real REXX compiler -- to turn a REXX script into a real executable. Currently,
>> Reginald's method of packing REXX scripts into EXE or DLL is not a real
>> compilation).
>
>> Java byte code?
>
> instructions to assembly instructions, and then just invoking an
> assembler/linker to create the executable. So, since there are already
> assemblers/linkers out there, the hardest part is to translate REXX to assembly
> instructions.
I'm coming to the thread a bit late, but have you considered
generating C source code instead of assembler? It would probably
be simpler to implement and make ports to other platforms (OS
and/or machine architecture) easier.
Just my two Zorkmids' worth.
--
-- Marten Kemp
(Fix name and ISP to reply)
-=-=-
... All methods should be used roughly. Most methods should be shoved
up against a wall and used unmercifully.
-- John Barnes on sff.writing.craft
* TagZilla 0.066 * http://tagzilla.mozdev.org
Gary Scott
> Jeff Glatt wrote:
>
>>> Gary Scott
>>> I'm also toying with the idea of making a
>>> real REXX compiler -- to turn a REXX script into a real executable.
>>> Currently,
>>> Reginald's method of packing REXX scripts into EXE or DLL is not a real
>>> compilation).
>>
>>
>>> Java byte code?
>>
>>
>> Nope. I don't see that as an executable. What I foresee is translating
>> REXX
>> instructions to assembly instructions, and then just invoking an
>> assembler/linker to create the executable. So, since there are already
>> assemblers/linkers out there, the hardest part is to translate REXX to
>> assembly
>> instructions.
>
>
> I'm coming to the thread a bit late, but have you considered
> generating C source code instead of assembler? It would probably
> be simpler to implement and make ports to other platforms (OS
> and/or machine architecture) easier.
>
> Just my two Zorkmids' worth.
>
There are some other choices for intermediate form such as whatever the
GCC backend expects. There are also some semi-standard ones (i've
forgotten names at the moment).
Gerard Schildberger
|>Marten Kemp
|>have you consideredgenerating C source code instead of assembler?
|
| I think that would be even harder. I can see how a REXX instruction can be
| broken down into assembly instructions. An assembly instruction is a rather
| compact, simple step that correlates fairly directly to what the CPU needs to
| do. And, an interpreter just breaks down a REXX instruction into a series of
| smaller steps too.
Consider the following code:
/**/ parse arg n .
if n==1 then a=copies(1,random(1,1e4)
if n==2 then do
a=3
exit
end
if n==3 then drop n
if n==4 then a=n
... what does the a=3 expand into
(as far as assembly instructions) ?
You just can't assign a character string to some
variable, as you don't even know it it exists,
and if it does, you have to allocate new memory
for A, do memory reclaimation for the "old"
memory of the REXX variable A.
I would think that almost all REXX statements
would translate into a bunch of BALR
instructions (to various subroutines).
If A doesn't exist, you have to allocate
memory for it, worry about running out of
memory, ...
How about the a=n statement? And these
are the simple REXX statements. ________Gerard S.
| But going from REXX to C is going from an abstract higher language to another
| abstract higher language. I don't see as direct a correlation.
Marten Kemp
>> Marten Kemp
>> have you consideredgenerating C source code instead of assembler?
>
> I think that would be even harder. I can see how a REXX instruction can be
> broken down into assembly instructions. An assembly instruction is a rather
> compact, simple step that correlates fairly directly to what the CPU needs to
> do. And, an interpreter just breaks down a REXX instruction into a series of
> smaller steps too.
>
> abstract higher language. I don't see as direct a correlation.
I just thought of REXX-to-C in terms of 'port'-ability <grin>.
You're right, going from a logically-arranged high level
language to a logically-challenged one would be difficult.
C isn't bad, for something that was thought up on the fly
at 3:00am after a lot of coffee <grin>.
--
-- Marten Kemp
(Fix name and ISP to reply)
-=-=-
... "tcsh isn't a shell. It's the noise you make when you find out
somebody's writing scripts with it."
-- somewhere in the Monash local fortune file,
I can't remember who said it originally.
ML
> I just thought of REXX-to-C in terms of 'port'-ability <grin>.
> C isn't bad
At least the main part of the generated code should be portable somehow.
Optimizing it is more difficult, you may want some RXSTRING's (" 1")
to be C's int's instead, in order to gain speed. Translating LineIn() to
another programming language probably won't make your apps fly w.r.t.
file-I/O, unless you also change other components.
The language doesn't matter that much, Rexx adds no features to your
computer, so indeed C isn't bad. The developer may prefer other
programming languages, but it can/will limit the number of users
dramatically. I don't think MS sells Visual Basic for *ix-systems, and
a *ix-*.[COM|EXE] could fail on a pc running Windows.
---
ML
> Consider the following code:
> /**/ parse arg n .
> if n==2 then a=3
Or what about "a.=3"?
If I'ld complete a translator (instead of a directly compiled result,
which adds less control to the result), I'ld give you a choice between
the Rexx "memory management system" or delivering an optimizable input
file (e.g. making the author to include some define like "INTEGER a=0;"
or by assuming every unknown variable is an int). By default I'll perhaps
translate this, but I'ld let the compile fail due to an undefined variable,
preferring to add gained speed to just a stand-alone *.EXE (and making the
translation easier at the same time, but that's not a goal on its own).
---
Gary Scott
> > I just thought of REXX-to-C in terms of 'port'-ability <grin>.
>
> FWIW, http://hobbes.nmsu.edu/pub/os2/dev/rexx/rexxtacy.zip
>
> > C isn't bad
>
> At least the main part of the generated code should be portable somehow.
That's why generating the intermediate form that the GCC backend needs
would make it the most portable outside of C. It is low-enough level
(not that I consider C to be high-level), but too low level.
> Optimizing it is more difficult, you may want some RXSTRING's (" 1")
> to be C's int's instead, in order to gain speed. Translating LineIn() to
> another programming language probably won't make your apps fly w.r.t.
> file-I/O, unless you also change other components.
>
> The language doesn't matter that much, Rexx adds no features to your
> computer, so indeed C isn't bad. The developer may prefer other
> programming languages, but it can/will limit the number of users
> dramatically. I don't think MS sells Visual Basic for *ix-systems, and
> a *ix-*.[COM|EXE] could fail on a pc running Windows.
>
>
>
> ---
Gerard Schildberger
-------a lot of snippage from the writings of Gerard S.-------
|> Consider the following code:
|
|> /**/ parse arg n .
|> if n==2 then a=3
| Or what about "a.=3"?
|
| If I'ld complete a translator (instead of a directly compiled result,
| which adds less control to the result), I'ld give you a choice between
| the Rexx "memory management system" or delivering an optimizable input
| file (e.g. making the author to include some define like "INTEGER a=0;"
That would be re-defining what REXX is, there are no definitions of
that sort in the REXX language. It would make it much easier on the
compiler writer, but a real inconvience for the REXX coder, and how
would testing be done? The REXX coder would have to put in/take out
all those INTEGER statements for interactive development and then put
them back in for the compile.
| or by assuming every unknown variable is an int).
That would break almost all of my code, fur shure. What happens if
I start with a integer, and later it becomes a "floating point"
number, or even, a hexadecimal string, ... or other?
| ... By default I'll perhaps
| translate this, but I'ld let the compile fail due to an undefined variable,
Again, that's redefining the language, there are no undefined variables,
unless you have the SIGNAL ON NOVALUE in effect (with special
homage to the DROP statement). ___________________________Gerard S.
ML
>> I'ld give you a choice between the Rexx "memory management system"
>> or delivering an optimizable input file (e.g. making the author to
>> include some define like "INTEGER a=0;"
> That would be re-defining what REXX is
No. If you want the better part of the speed gain, you cannot expect a
translator/compiler to do all the work. You're able to use (ANSI?) Rexx
as-is, but then DO i=1 TO 1000000 will cost a lot of avoidable opcodes
if you, the developer, knows you only used "i" as an integer.
And yes, sloppy programmers still can choose RXSTRING's because they
don't know the app, or they aren't consistent w.r.t. variable names. It
still is possible to use i=1+1;i="Sloppy", but I don't want to deny the
users the major speed gain because somebody wrote code that cannot be
optimized.
> there are no definitions of that sort in the REXX language.
I prefer to mention solutions, not problems. And if you don't want to
"redefine" Rexx, what about adding in comments, add a "controle file"
for the translator/compiler, and/or just ask it during the translation
of the Rexx code. How's your interpreter interpreting "OPTIONS ANSI",
or "OPTIONS TYPEDEF=C:\MyApp.DEF"?
> It would make it much easier
And, more important, faster. Translate the (rather slow) LineIn() BIF
to C, work with the Rexx variable pool, and you'll probably notice you
didn't improve the execution speed like a optimized solution would.
The implied order of priorities is speed gains, reducing size and/or
memory usuage, and finally a real, stand-alone *.EXE. Without any kind
of optimization, what you're describing, you still can end up with the
*.EXE. It may be executing slow, it may use memory like it's free, but
it still be an *.EXE without any "uncontrolled" results.
> The REXX coder would have to put in/take out all those INTEGER
> statements for interactive development and then put them back
> in for the compile.
Not with a control file, not with optimization instructions in comments,
and also not when you ask it during translation (check "not sure" if you
don't know, or don't really want that part to be optimized).
> What happens if I start with a integer, and later it becomes a
> "floating point" number, or even, a hexadecimal string, ... or
> other?
Then define it as a RXSTRING structure. Or don't pick the wrong type,
in a way just like "/**/;SAY a+1" can be called a "bug", or don't care
about major speed gains and make anything a RXSTRING. Please note that
checking the type each time still is expensive, even if conversion is
possible. You have to optimize something, or the result isn't as good
as it could be.
> or by assuming every unknown variable is an int).
I'ld prefer RXSTRING as the default, there's no need to get rid of the
existing structure. But then don't expect the possible speed gain with
a DO <unknown>=1 TO 1000000.
Nevertheless, in the default situation I mentoined earlier I'ld let the
unknown variable cause the compilation to fail.
>> By default I'll perhaps translate this, but I'ld let the compile fail
>> due to an undefined variable,
> Again, that's redefining the language
No, it isn't. The compiler fails to create an *.EXE, assuming by default
you also want to improve the speed (compared to interpreting), but the
*.REX is untouched. The choice isn't what you suggest it is, the choice
is that I want the compiler to tell me I forgot to optimize variables.
If I don't want that optimized, then I'ld have to use a translation
switch to pick the (slow) alternative of unititialized variables and/or
RXSTRING's.
I cannot recall anybody complaining about the way Regina is controlled
sometimes, and there's hardly a difference with anything I mentioned.
Did Regina "redefine" Rexx, or is it even the most ANSI-compliant Rexx
interpreter available?
Speaking of ANSI, why don't you mention that your Rexx code may also
fail to work when the translator assumes another interpreter? FWIW,
I'ld use ANSI Rexx as a starting point instead of popular interpreters
or the interpreters I use. And I wouldn't care about OO programming at
all, at least as long as there's no common translator/compiler working.
---
ML
>>> C isn't bad
>> At least the main part of the generated code should be portable somehow.
> That's why generating the intermediate form that the GCC backend needs
> would make it the most portable outside of C. It is low-enough level
> (not that I consider C to be high-level), but too low level.
I assume you mean _not_ too low level? People may use Rexx because of
limited programming skills and/or programming needs, but the advanced
user may want to squeeze in Rexx DLL source code, so it's distributable
as a single file instead of "a package" with a few embedded ::REQUIRES.
BTW I'ld settle for any compilable, portable programming language, and
I'ld add features like disallowing some external commands, even if that
would "redefine Rexx". Format(): yes, FORMAT C: < ANSWERS.RSP: no,
DEL RxOutput.New: yes, DEL CONFIG.NT: no
And, if needed, skip INTERPRET for a while. Using INTERPRET is always
avoidable, and it may save a few headaches including it from scratch.
---
ML
> The implied order of priorities is speed gains, reducing size and/or
> memory usuage, and finally a real, stand-alone *.EXE.
Add, FWIW, "Java-like safety" before the stand-alone *.EXE, and IMHO
one could add "Make all output always look like my Rexx interpreter
shows it", e.g. error messages w.r.t. "SAY 1/0", after the stand-alone
*.EXE. Sloppy programming shouldn't stop developments, and even they
still will obtain a (buggy) *.EXE as their final result.
---
Bob Martin
>And, if needed, skip INTERPRET for a while. Using INTERPRET is always
>avoidable, and it may save a few headaches including it from scratch.
The VM/CMS Rexx compiler did not support INTERPRET, so most
programmers learned to live without it.
Steve Swift
> programmers learned to live without it.
It's been a long time since I last used the VM Rexx compiler but I seem
to recall that even INTERPRET was added in a subsequent release.
I only recall using INTERPRET once (in my "say" program that allows me
to do simply maths/programs from the command line) so I'm not likely to
have a clear memory of using it.
During the compiler's development period I won two Sachertortes from the
development team for finding the most bugs in two separate months. I
still use the wooden boxes they came packed in, and I'm sure the cakes
themselves account for a couple of millimetres of my waistline!
To this day, I maintain the ethos of rewarding people who find bugs in
my code, handing out a £5 voucher each month to the person who finds the
most bugs (restricted to my professional efforts, not the stuff at
http://www.swiftys.org.uk where all the CGI scripting is Rexx).
Don Hills
Steve Swift <Steve....@gmail.com> wrote:
>It's been a long time since I last used the VM Rexx compiler but I seem
>to recall that even INTERPRET was added in a subsequent release.
It was added sometime before VM/SP Release 6. It's in the manual for that
release, and it's not mentioned in the Summary of Changes.
--
Don Hills (dmhills at attglobaldotnet) Wellington, New Zealand
"New interface closely resembles Presentation Manager,
preparing you for the wonders of OS/2!"
-- Advertisement on the box for Microsoft Windows 2.11 for 286
Gerard Schildberger
|> ML wrote:
|> And, if needed, skip INTERPRET for a while. Using INTERPRET is always
|> avoidable, and it may save a few headaches including it from scratch.
| The VM/CMS Rexx compiler did not support INTERPRET, so most
| programmers learned to live without it.
It didn't support it at first, but the INTERPRET feature was
later supported in a later release.
I recall vaguely the SOURCELINE(nnn) wasn't supported
either in the early release (it just returned a null
string, as I recall). SOURCELINE was also supported
in a later release. I don't remember if the source was
in plain text or if it was encrypted (mabye had its bits
inverted). Part of the reason that some people used
the compiler was to hide the source code from prying
eyes. ______________________________________________Gerard S.
Gerard Schildberger
-----a bunch of stuff snipped----
| And, if needed, skip INTERPRET for a while. Using INTERPRET is always
| avoidable, and it may save a few headaches including it from scratch.
No, INTERPRET isn't always avoidable, particularily when used
in home-grown calculators. ___________________________Gerard S.
Steve Swift
> either in the early release (it just returned a null
> string, as I recall). SOURCELINE was also supported
> in a later release. I don't remember if the source was
> in plain text or if it was encrypted (mabye had its bits
> inverted). Part of the reason that some people used
> the compiler was to hide the source code from prying
> eyes.
Yes, I have vague memories of the Sourceline() issue. I seem to recall
an option to suppress the source, in later releases of the compiler.
ML
>> Using INTERPRET is always avoidable
> No, INTERPRET isn't always avoidable, particularily when used
> in home-grown calculators.
That remark makes no sense at all, it is always avoidable. INTERPRET
adds nothing new to interpreted Rexx. You still can process "1+2*3",
conforming an earlier article written by Ian, IIRC without such a
reply from you?
If you disagree, then I'ld like to see your meaningfull example of an
unreplacable and thus unavoidable INTERPRET, without made-up demands
like the app has to be a <80 bytes one-liner please.
---
Walter u. Christel Pachl
"Bob Martin" <bob.m...@excite.com> schrieb im Newsbeitrag
news:i1g%h.6492$8E....@newsfe5-win.ntli.net...
ML
> I seem to recall an option to suppress the source, in later releases
> of the compiler.
to hide the source code. And if a goal of showing it is related to some
kind of debugging, there's a difference between a translator/compiler
and just a compiler. By default, I wouldn't include it with translators,
again because of gaining execution speed instead of making it look like
Rexx. Well, maybe this great example would stop working then:
/**/
INTERPRET Sourceline(4)
EXIT
SAY 'Hello'
And again, I'ld prefer having a somehow working translator/compiler
instead of digging up old issues which don't apply to any existing
generic translator/compiler. Because there's no such beast, AFAIK.
Besides that, bugs in "/**/;INTERPRET Sourceline(4);EXIT;SAY 'Hello'"
almost scream for yet another speed-reducing SourcelinePart() BIF! ;-)
---
ML
>> it may save a few headaches including it from scratch.
> Id did (and does) in the second Release!!!
I rest my case, not being sure if this history lesson also could learn
us that a working v1.0 back then had a higher priority than releasing
an all-including v1.0. The underlying reason may be another, but the
use of INTERPRET always remains avoidable, not being worth causing
fatal headaches or even stopping an initial v1.0 release. I'ld put
INTERPRET on a list of wishes, but not on the list of demands.
---
Gerard Schildberger
| Id did (and does) in the second Release!!!
|> Bob Martin wrote:
|>> ML wrote:
|>>And, if needed, skip INTERPRET for a while. Using INTERPRET is always
|>>avoidable, and it may save a few headaches including it from scratch.
|> The VM/CMS Rexx compiler did not support INTERPRET, so most
|> programmers learned to live without it.
No, if someone used INTERPRET in a REXX program to be compiled,
and if the compiler didn't support it, then those people just
didn't use the compiler. Besides, even when it did support
INTERPRET (later, in the 2nd release), it didn't speed up the
program that much anyway. ____________________________________Gerard S.
Gerard Schildberger
( ---- waaaaaaaaaaaay to much snipping ---- )
What I understand (and observed) from this short history lesson is:
IBM didn't make version 1 of the REXX compiler fully complient to the
REXX language. Version 2 took care of that omission. That's the
history lesson. IBM may have intended to support INTERPRET all
along, but did want to wait to release the product, so it did what
it could, released the compiler, and fixed it in the 2nd release.
_____________________________________________________________Gerard S.
Gerard Schildberger
|> I seem to recall an option to suppress the source, in later releases
|> of the compiler.
| I'ld rank it a safety(-related) issue, for one because the author wants
| to hide the source code.
I don't see how you can make that assumption that the author wants to
hide the source code. Not all REXX programmers use the compiler (or
that option) for that reason.
| ........................ And if a goal of showing it is related to some
| kind of debugging, there's a difference between a translator/compiler
| and just a compiler. By default, I wouldn't include it with translators,
| again because of gaining execution speed instead of making it look like
| Rexx.
That's one critera for the REXX compiler..... to make it look EXACTLY
like REXX. Once you start saying that I won't put that into the
compiler, and I won't support that feature, and that other one...
just to gain speed or easy of implementation, people will stay away
from it in droves.
| ................ Well, maybe this great example would stop working then:
|
| /**/
| INTERPRET Sourceline(4)
| EXIT
| SAY 'Hello'
|
| And again, I'ld prefer having a somehow working translator/compiler
| instead of digging up old issues which don't apply to any existing
| generic translator/compiler. Because there's no such beast, AFAIK.
|
| Besides that, bugs in "/**/;INTERPRET Sourceline(4);EXIT;SAY 'Hello'"
| almost scream for yet another speed-reducing SourcelinePart() BIF! ;-)
I don't see a bug in that program. SOURCELINE can only show
text for what's available. (In the above case) SOURCELINE will
raise the SYNTAX condition when the number (in this case 4) is
greater than the number of lines in the program (in the above case 1).
But you said bugS. What are the other "bugs" ? ____________Gerard S.
Gerard Schildberger
|>> Using INTERPRET is always avoidable
|> No, INTERPRET isn't always avoidable, particularily when used
|> in home-grown calculators.
| That remark makes no sense at all, it is always avoidable. INTERPRET
| adds nothing new to interpreted Rexx. You still can process "1+2*3",
| conforming an earlier article written by Ian, IIRC without such a
| reply from you?
If INTERPRET adds nothing new to interpreted REXX, I doubt that
Mike C. would have included it the language.
I don't disagree that "1+2*3" needs the INTERPRET statement.
| If you disagree, then I'ld like to see your meaningfull example of an
| unreplacable and thus unavoidable INTERPRET, without made-up demands
| like the app has to be a <80 bytes one-liner please.
Yes, I disagree. I have a calculator ($CALC) that needs the
interpret statement. I can't include the program here, it is way too
large to do that. If you want to have a copy, I'll send the REXX
code and/or the (voluminous?) documentation, it's about 10K lines
for the general documentation, and 1.5K for the sample useage doc
(some examples on how to use $CALC).
In essence (as with most calculators written in REXX), the format is:
$CALC your_expressions_here
---or depending on your operating system and how you have it set up:
some_rexx_interpretor $CALC your_expressions_here
The expression(s) may or may not include user written routines (sub-
routines), and the number of (internal) functions supported are
over a thousand.
There are ways to add options like changing the number of digits used
or shown, various plotting options, numerous options on how to show
(present) or restrict the answers (results), writting the output to
a file, and other such thingys. If using Personal REXX or PC/REXX,
you can display the results in various colors, including highlighting.
I would ask how any REXX coder would avoid the use of INTERPRET
when coding a (generic) calculator.
Or, for that matter, how a coder could avoid it in the ubiquitous
REXXTRY programs. ________________________________________Gerard S.
Sahananda
> | ML wrote:
>
> |>> Using INTERPRET is always avoidable
>
Here is a little bit of fun in ooRexx.
It generates random 4-variable karnaugh maps
http://www.ee.surrey.ac.uk/Projects/Labview/minimisation/karnaugh.html
and allows you to guess at simplifications.
It is just over 80 lines of code.
Unlike the traditional Karnaugh maps that electronic engineers (and
computer programmers) use it also allows for exclusive-or gates which
I think makes it more exciting.
Whilst the first interpret statement could be replaced by a huge
select clause,
I'd be interested to see how it could be written without the second
interpret statement.
enjoy,
Jon
/* Karnaugh Map - just for fun - Sahananda - Jan2007 */
MyDialog=.KarnaughMap~new
MyDialog~~Execute('ShowTop')~~DeInstall
exit
/*
=========================================================================
*/
::requires 'oodialog.cls'
/*
=========================================================================
*/
::class KarnaughMap subclass userdialog
/*
-------------------------------------------------------------------------
*/
::method Init
/*
-------------------------------------------------------------------------
*/
self~Init:super
rc=self~CreateCenter(140,85,'Solve this Karnaugh map',,,'MS Sans
Serif',8)
self~InitCode=(rc=0)
/*
-------------------------------------------------------------------------
*/
::method DefineDialog
/*
-------------------------------------------------------------------------
*/
threshold = random(2,19)
do x = 1 to 4
do y = 1 to 4
id = 10 + (x*4) + y
if random(1,20) > threshold
then self~addentryline(id,'box'||id,(12*x),(12*y),
10,10,'readonly center')
else self~addentryline(id,'box'||id,(12*x),(12*y),
10,10,'readonly center noborder')
end /* DO */
end /* DO */
self~addWhiteRect(10,10,50,50)
self~addText(12, 0,22,8,'< A >','center')
self~addText(24,60,22,8,'< D >','center')
self~addText( 2,12, 5,8,'^','center')
self~addText( 2,18, 5,8,'B','center')
self~addText( 2,26, 5,8,'v','center')
self~addText(62,24, 5,8,'^','center')
self~addText(62,30, 5,8,'C','center')
self~addText(62,38, 5,8,'v','center')
self~addWhiteRect(80,10,50,50)
self~addText(85,15,40,8,' . - And')
self~addText(85,25,40,8,'+ - Or')
self~addText(85,35,40,8,'@ - excl-or')
self~addText(85,45,40,8,' \ - not')
self~addEntryLine(10,'guess',5,70,130,11,'autoscrollh')
/*
-------------------------------------------------------------------------
*/
::method Ok
/*
-------------------------------------------------------------------------
*/
self~OK:super /* call Self~Validate, set
self~InitCode to 1 */
self~finished = 0 /* we never leave from here -only from
cancel */
self~getData
guess = self~guess~changeStr('@','&&')~translate('&|&||\','.
+^Uu¬')
signal on syntax
do x = 1 to 4
do y = 1 to 4
id = 10 + (x*4) + y
a = (x < 3)
b = (y < 3)
c = ((y > 1) & (y < 4))
d = ((x > 1) & (x < 4))
interpret 'self~box'||id||'=""'
interpret 'if' guess 'then self~box'||id '= "X"'
end /* DO */
end /* DO */
self~setData
return self~finished
/* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - */
syntax:
signal off syntax
lpar = self~guess~countStr('(')
rpar = self~guess~countStr(')')
if lpar <> rpar
then call errormessage self~guess 'has' lpar 'left parenthesis &' rpar
'right parenthesis - try again'
else call errorMessage self~guess 'is not a valid logical expression -
try again'
return
/*
-------------------------------------------------------------------------
*/
::method Run
/*
-------------------------------------------------------------------------
*/
self~FocusItem(10)
self~run:super /* this handles message calls/key
presses etc */
Sahananda
RexxLa symposium.
I should have said about the Karnaugh.rex code
1) Watch out for line wraps
2) ooRexx for Windows only in this case
Jon
Bob Martin
I did say "did not" as opposed to "does not". Perhaps I should have said
"the original VM/CMS Rexx compiler". ;-)
Bob Martin
That's a tad arrogant, if I may say so. Was I supposed to tell my manager that
"I'm not going to to compile the code as you requested because the compiler doesn't
support INTERPRET and I'll have to do a little extra work"?!
Also, I disagree with your last point - compiled code was considerably faster.
Steve Swift
> unreplacable and thus unavoidable INTERPRET, without made-up demands
> like the app has to be a <80 bytes one-liner please.
I'd like to see how anyone could come up with an INTERPRET free version
of my "Say" program below. I use say all the time to see the result of
Rexx statements, such as: Say date(b)//7
For extra bonus points, why did I "expose A" in val()
/* Say */
Numeric digits 16
Signal on syntax
Parse arg cmd
If cmd <> '' then do
say val(cmd)
Exit
End
Retry:
Do until cmd = ''
Call charout ,'Enter expression: '
Parse pull cmd
If cmd <> '' then do
A = val(cmd)
Say 'A='a
End
End
Exit
Syntax:
Say 'That did not compute:' errortext(rc)
Signal retry
Val: Procedure expose A
Interpret 'A='Arg(1)
Return A
Gerard Schildberger
Whether it's arrogant or not, I'll let you do the name
calling. If your manager is telling you HOW to do your
job and what tools to use, that's another problem.
If you're using an INTERPRET statement in your REXX
code (or inherited the code), and the compiler doesn't
support it, then you have a couple of choices. I
wouldn't waste the time re-writing code so that it
conforms to the compiler's restrictions, there's better
use of one's time. If you could do the "little extra
work", as you say, then do it. I have yet to see anyone
NOT use an INTERPRET statement in writing a general-
purpose calculator.
As to my last point, compiled code for the INTERPRET
statement wasn't that much faster, if at all. Note
that my last statement wasn't a general statement, but
was referring to compiling code that had the INTERPRET
statement in it. _____________________________Gerard S.
Steve Swift
> the code as you requested because the compiler doesn't support
> INTERPRET and I'll have to do a little extra work"?!
That's precisely what I had to do. I had an 11,000 line Rexx program
that contained one INTERPRET instruction. It had to wait until release 2
of IBM's compiler before I could compile it, achieving about a 5-fold
increase in performance.
Gerard Schildberger
For an improvement in recovering from multiple
errors, the
Retry:
statement should be replaced with
Retry: signal on syntax
[Try to compute 77/0 twice with the original
code, and again, with the modified code.]
__________________________________________Gerard S.
Gerard Schildberger
|> Was I supposed to tell my manager that "I'm not going to to compile
|> the code as you requested because the compiler doesn't support
|> INTERPRET and I'll have to do a little extra work"?!
| That's precisely what I had to do. I had an 11,000 line Rexx program
| that contained one INTERPRET instruction. It had to wait until release 2
| of IBM's compiler before I could compile it, achieving about a 5-fold
| increase in performance.
Fortunately for me, the IBM REXX compiler was still in test for
some time, so it was never allowed to be used by the general
users until Release 2.0 was available. The 3rd program I ever
(tried) to run on Release 2.0 cause the compiler to crash.
I couldn't figure out why. Later, I learned that if the
program length (source) was exactly 17 bytes or some such,
the compiler blew up. I just scratched my head and waited
for the fix to be applied. For me, it wasn't a viable
option as the compiler was only available on one of our
VM systems, and the other 5 VM systems or so didn't have
the compiler avaiable to the general users. One of the VM
systems on was the same CPU that had the VM that DID
support the compiler. Don't ask. It's a long story.
One of the drawbacks of the compiler (at that time) was
that if you compiled the code, it produced a MODULE, and
that module required a support library, and if that
library wasn't there, your compiled program just ended
with some sort of error message. I'm not sure, but later,
if the library wasn't available, the compiled REXX program
just used the REXX interpretor (without blowing up, of
course). _________________________________________Gerard S.
Steve Swift
>
> statement should be replaced with
>
> Retry: signal on syntax
I can see exactly what you are saying, and why you say that, but with my
IBM Object Rexx it makes no difference:
C:\$user\tools>say
Enter expression: 77/0
That did not compute: Arithmetic overflow/underflow
Enter expression: 77/0
That did not compute: Arithmetic overflow/underflow
Enter expression:
Anyway, what's so special about 77? :-)
This must be an example of Darwinian programming - it has evolved to fit
its environment.
Shmuel (Seymour J.) Metz
at 07:00 AM, Bob Martin <bob.m...@excite.com> said:
>That's a tad arrogant, if I may say so.
You may say so, but that doesn't make it true.
>Was I supposed to tell my manager that
>"I'm not going to to compile the code as you requested because the
>compiler doesn't support INTERPRET and I'll have to do a little
>extra work"?!
Are you still beating your wife? What you are supposed to tell your
manager is the truth; after that he will decide what route he wants
you to take.
>Also, I disagree with your last point
The *YOU* are the one that is arrogant, because you haven't seen his
data.
>compiled code was considerably faster.
Some was, some wasn't.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org
Gerard Schildberger
|> Retry:
| >
| > statement should be replaced with
| >
| > Retry: signal on syntax
|
| I can see exactly what you are saying, and why you say that, but with my
| IBM Object Rexx it makes no difference:
On all of the three REXXes I have, without re-issuing the SIGNAL ON SYNTAX,
the program exits after the 2nd SYNTAX error. ______________Gerard S.
Gerard Schildberger
|> Retry:
| >
| > statement should be replaced with
| >
| > Retry: signal on syntax
|
| I can see exactly what you are saying, and why you say that, but with my
| IBM Object Rexx it makes no difference:
|
| C:\$user\tools>say
| Enter expression: 77/0
| That did not compute: Arithmetic overflow/underflow
| Enter expression: 77/0
| That did not compute: Arithmetic overflow/underflow
| Enter expression:
|
| Anyway, what's so special about 77? :-)
|
| This must be an example of Darwinian programming - it has evolved to fit
| its environment.
Maybe so, but if it doesn't work (as intended) on the
"classic" REXX interpretors, I usually code to the
REXX interpretors that I use.
OOREXX isn't one of them. _______________________Gerard S.
Bob Martin
>In <r8A%h.6682$8E....@newsfe5-win.ntli.net>, on 05/07/2007
>at 07:00 AM, Bob Martin <bob.m...@excite.com> said:
>
>>That's a tad arrogant, if I may say so.
>
>You may say so, but that doesn't make it true.
>
>>Was I supposed to tell my manager that
>>"I'm not going to to compile the code as you requested because the
>>compiler doesn't support INTERPRET and I'll have to do a little
>>extra work"?!
>
>Are you still beating your wife? What you are supposed to tell your
>manager is the truth; after that he will decide what route he wants
>you to take.
What a strange post. What has my wife to do with anything?
My manager was fully aware of the facts and knew that INTERPRET was not
indispensable. We didn't come across a single instance that we couldn't
replace with better code.
We compiled over 200 execs and every one showed speed improvements.
>
>>Also, I disagree with your last point
>
>The *YOU* are the one that is arrogant, because you haven't seen his
>data.
What data? OP said people didn't use release 1 of the compiler because
it didn't support INTERPRET. That was blatantly false.
Shmuel (Seymour J.) Metz
at 07:33 AM, Bob Martin <bob.m...@excite.com> said:
>What a strange post. What has my wife to do with anything?
Whoosh! The point is that you made an assertion in the form of a
question. You attributed to the OP a position that he never took.
>What data?
The data from his shop, of course. Those were the data that were
relevant to the programmers at his shop.
>OP said people didn't use release 1 of the compiler because it
>didn't support INTERPRET. That was blatantly false.
So what are the programmers at his shop, chopped liver? Are you saying
that they are not people, or claiming that you know better than the OP
what his people are using. As I said, *you* are the arrogant one, not
him.
Bob Martin
>In <UIV%h.2052$nN5...@newsfe1-win.ntli.net>, on 05/08/2007
>at 07:33 AM, Bob Martin <bob.m...@excite.com> said:
>
>>What a strange post. What has my wife to do with anything?
>
>Whoosh! The point is that you made an assertion in the form of a
>question. You attributed to the OP a position that he never took.
>
>>What data?
>
>The data from his shop, of course. Those were the data that were
>relevant to the programmers at his shop.
>
>>OP said people didn't use release 1 of the compiler because it
>>didn't support INTERPRET. That was blatantly false.
>
>So what are the programmers at his shop, chopped liver? Are you saying
>that they are not people, or claiming that you know better than the OP
>what his people are using. As I said, *you* are the arrogant one, not
>him.
You have contributed nothing to this thread except insults and I expected
better of you.
I said :
|> The VM/CMS Rexx compiler did not support INTERPRET, so most
|> programmers learned to live without it.
To which Herr Schildberger replied
>> No, if someone used INTERPRET in a REXX program to be compiled,
>> and if the compiler didn't support it, then those people just
>> didn't use the compiler.
See that first word - "No"? He then made an assertion that was untrue.
Ian Collier
>I would ask how any REXX coder would avoid the use of INTERPRET
>when coding a (generic) calculator.
Well... by writing the whole expression parser in Rexx, of course. :-)
>Or, for that matter, how a coder could avoid it in the ubiquitous
>REXXTRY programs. ________________________________________Gerard S.
Rexxtry is a special case, I think.
--
---- Ian Collier : i...@comlab.ox.ac.uk : WWW page (including REXX section):
------ http://users.comlab.ox.ac.uk/ian.collier/imc.shtml
New to this group? Answers to frequently-asked questions can be had from
http://www.rexxla.org/faq.html .
Ian Collier
>> Retry:
>>
>> statement should be replaced with
>>
>> Retry: signal on syntax
>I can see exactly what you are saying, and why you say that, but with my
>IBM Object Rexx it makes no difference:
>C:\$user\tools>say
>Enter expression: 77/0
>That did not compute: Arithmetic overflow/underflow
>Enter expression: 77/0
>That did not compute: Arithmetic overflow/underflow
>Enter expression:
Now do it a third time...
This harks back to another recent thread; I still believe ooRexx is doing
the wrong thing (and Gerald's experience seems to confirm it's the only one
that does it). See:
http://groups.google.com/group/comp.lang.rexx/browse_thread/thread/db0b7935979edfdd/#9507d7861942f228
Essentially, what we've got is this:
signal on syntax
restart:
call test
exit
syntax: say "Syntax error on line" sigl":" errortext(rc)
signal restart
test: return 77/0
I believe an ANSI interpreter would say this:
Syntax error on line 7: Arithmetic overflow or underflow
Then raises a divide-by-zero error on line 7
ooRexx says this:
Syntax error on line 7: Arithmetic overflow/underflow
Syntax error on line 3: Arithmetic overflow/underflow
Then raises a divide-by-zero error on line 7
Why? Because when you break out of the "test" subroutine with an error,
strictly speaking you are still within the subroutine when you signal
back to the main program. Now when a "signal on syntax" occurs, the
handler for that level is turned off. ANSI says that once a signal
is turned off it's off - for the whole program. Any further syntax
error will halt the program. However, ooRexx allows each calling
level to have its own setting, so although the handler is turned off
within the "test" subroutine it's still on within the main program.
Therefore, when a second error occurs it still gets trapped. Because
it's trapped in the main program instead of within the subroutine,
the error is raised on line 3. And now the signal handler is turned
off within the main program, and the next error does indeed halt the
program.
Gerard Schildberger
|> Gerard Schildberger wrote:
|> I would ask how any REXX coder would avoid the use of INTERPRET
|> when coding a (generic) calculator.
| Well... by writing the whole expression parser in Rexx, of course. :-)
That's like asking me to build a watch if I want to know what
time it is.
Writing an expression parser is way too complicated for me to
just avoid using INTERPRET. My calculator program is much too
evolved to take that giant step backwards, and it wouldn't
buy me anything... even if I could compile the resultant REXX
code. I already "compile" the REXX code for all my PC/REXX
(Personnel REXX). That version of compiling (as far as I can
tell), pre-parses the REXX code and makes it about twice as
fast for the large (many statements) general program. _________Gerard S.
|> Or, for that matter, how a coder could avoid it in the ubiquitous
|> REXXTRY programs. ________________________________________Gerard S.
| Rexxtry is a special case, I think.
So are all the calculators written in REXX, I would think. ____Gerard S.
Rick McGuire
condition is only turned off for the current call level. See the
definition on page 96.
This also matches the definition that's in Cowlishaw's The Rexx Language.
Rick
Steve Swift
Which just shows that under the right circumstances, no amount of
testing is sufficient. At least, no amount that I'd consider enough.
Ian Collier
>For extra bonus points, why did I "expose A" in val()
I expect that's so that you can use "a" to refer to the last value
computed when you type in the next expression.
Steve Swift
> computed when you type in the next expression.
Right first time! :-)
ML
>> I would ask how any REXX coder would avoid the use of INTERPRET
>> when coding a (generic) calculator.
> Well... by writing the whole expression parser in Rexx, of course. :-)
Spot on. Just like I wrote earlier, any meaningfull use of INTERPRET
is always avoidable. Command-line calculators already exist, but Rexx
can be used too. There's no need to include INTERPRET in a v1.0 of a
translator/compiler. I didn't mention that the Rexx app can be small,
nor the compiled result is faster, nor INTERPRET shouldn't be added.
I'ld like to save the developing volunteer from INTERPRET headaches,
and AFAIK there's no competition which offers it at the moment. It's
nice to have a compilable INTERPRET, but it isn't a generic must-have,
unlike e.g. a CharOut() in: "CALL CharOut '','How are you? ';PULL a"
> Rexxtry is a special case, I think.
Hence me asking for a meaningfull app. Developers already should be
able to translate and compile the ARG's, if needed. And just because
INTERPRET adds no features to Rexx, it may theoretically be easier to
process the ARG's with Rexx than including some compiled INTERPRET.
There's more than one special case which I wouldn't address with v1.0
but other people may use as a stick to throw. Maintaining sourcelines
when Sourceline() doesn't occur in the app may slow the result down,
and do you want to see the Rexx one, the C one or the compiled one?
When a buggy app, originally written in C, crashes, is it common and
important to display the C culprit, albeit we may be used to it? I
don't think so, but YMMV. I'ld give CharOut() a higher priority than
any of the special cases, which have little to do with the main goals
of compiled, meaningfull Rexx apps. Besides that, I've more Rexx apps
with a file-I/O-related lack of speed than command-line calculators
having to be written in Rexx, using an avoidable INTERPRET. And if I
really needed that personally, I'ld rather see an ANSI Rexx compiler
without INTERPRET-support than yet another unfinished project with
an attempt to support INTERPRET. Besides that, if one is very happy
with an existing Rexx calculator, then one may assume it fulfills all
needs of the user, which wouldn't be true for a bugfree Rexx app which
file-I/O takes a few hours/days to complete. And my main goal wouldn't
be to basicly please current power-users (and related users) already
visiting comp.lang.rexx. That may be a small audience, which is able
to help themselves (and is already doing so, e.g. with ooRexx).
Anyway, INTERPRET is always avoidable. I never said one would like the
looks of it, nor that the compiled, long version is faster or slower.
INTERPRET is avoidable, so there's no need to make it stop the show.
A translator/compiler without INTERPRET may not please one, but that
also goes for using ANSI Rexx (my own compiler isn't ANSI-compliant,
but I'm not that selfish to assume the use of the Rexx interpreter I
happen to use most often).
---
ML
> I'd like to see how anyone could come up with an INTERPRET free
> version of my "Say" program below.
to do so, it's sufficient to recognize that INTERPRET adds no features
to Rexx, no matter how handy or smart the use of INTERPRET is. It may
be powerfull, but in the end it's always avoidable/replacable with an
identical result, because it adds no features to Rexx. There's no need
to write 10,000+ lines of Rexx to proove that.
The opposite is easier to proove. An unique feature of CharOut() is not
adding some kind of <CR><LF>, unlike LineOut() or SAY. This means that
in "CALL CharOut '','How are you? ';PULL a", CharOut() isn't avoidable
nor replacable, using 100% Rexx. Unlike INTERPRET, CharOut() adds such
an unavoidable/unreplacable feature to Rexx.
And again, perhaps your "SAY Date()//7" isn't a meaningfull app like I
asked for. It sounds like the work of a developer to me, who should be
able to write it to a file and translate/compile that file, assuming a
compiled result is a real requirement (for reasons unknown to me). If
not, feel free to write the possible 10,000+ lines of code yourself or
just proove using INTERPRET isn't avoidable (your example doesn't).
And again, I'ld rather have some v1.0 of a translator/compiler without
INTERPRET-support than some delayed/unfinished project with INTERPRET-
support. INTERPRET is always avoidable, but I'm not going to write the
zillion lines of code to throw all possible, unprooved sticks back to
you! :-)
---
Gary Scott
> > I'd like to see how anyone could come up with an INTERPRET free
> > version of my "Say" program below.
>
> There's no need to actually produce the perhaps 10,000+ lines of Rexx
> to do so, it's sufficient to recognize that INTERPRET adds no features
> to Rexx, no matter how handy or smart the use of INTERPRET is. It may
> be powerfull, but in the end it's always avoidable/replacable with an
> identical result, because it adds no features to Rexx. There's no need
> to write 10,000+ lines of Rexx to proove that.
Given that it might take 10000 lines of rexx to duplicate the
functionality of INTERPRET, in some sense, the practicality of doing so
makes it "indespensible" and "essential".
>
> The opposite is easier to proove. An unique feature of CharOut() is not
> adding some kind of <CR><LF>, unlike LineOut() or SAY. This means that
> in "CALL CharOut '','How are you? ';PULL a", CharOut() isn't avoidable
> nor replacable, using 100% Rexx. Unlike INTERPRET, CharOut() adds such
> an unavoidable/unreplacable feature to Rexx.
>
> And again, perhaps your "SAY Date()//7" isn't a meaningfull app like I
> asked for. It sounds like the work of a developer to me, who should be
> able to write it to a file and translate/compile that file, assuming a
> compiled result is a real requirement (for reasons unknown to me). If
> not, feel free to write the possible 10,000+ lines of code yourself or
> just proove using INTERPRET isn't avoidable (your example doesn't).
>
> And again, I'ld rather have some v1.0 of a translator/compiler without
> INTERPRET-support than some delayed/unfinished project with INTERPRET-
> support. INTERPRET is always avoidable, but I'm not going to write the
> zillion lines of code to throw all possible, unprooved sticks back to
> you! :-)
>
>
>
> ---
--
Gary Scott
mailto:garylscott@sbcglobal dot net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
Gerard Schildberger
|> ML wrote:
|>> I'd like to see how anyone could come up with an INTERPRET free
|>> version of my "Say" program below.
|> There's no need to actually produce the perhaps 10,000+ lines of Rexx
|> to do so, it's sufficient to recognize that INTERPRET adds no features
|> to Rexx, no matter how handy or smart the use of INTERPRET is. It may
|> be powerfull, but in the end it's always avoidable/replacable with an
|> identical result, because it adds no features to Rexx. There's no need
|> to write 10,000+ lines of Rexx to proove that.
| Given that it might take 10000 lines of rexx to duplicate the
| functionality of INTERPRET, in some sense, the practicality of doing so
| makes it "indespensible" and "essential".
To further that argument, the TRANSLATE function with just one argument
doesn't add anything to REXX, and a case could be made also that there
is no need for the SELECT feature, those features are always avoildable/
replacable. Same for the DO statement. One could always do that
"that kind of stuff" in other code. I guess we could eliminate about
half of REXX functions. LEFT and RIGHT BIFs, they could always be
replaced with SUBSTR.
Ditto concerning ABS, SIGN, MAX, MIN, COPIES, REVERSE, ABBREV,
WORDS, WORDLENGTH, STRIP, etc. Of course, all of these could be
replaced with (other REXX) code, but it sure would make programming
in REXX cumblersome.
I shudder when someone tries to write code (or portends to) such as
a REXX compiler and state that only certain features will be
supported, and the features not supported are because they add no
features to the Rexx language.
I wonder if Ian Collier (who, as far as I know, has written a REXX
interpreter) even thought of NOT supporting any feature of REXX because
it was too hard to do, or inconvient to do so. Same for Jeff Glatt,
Kieth Watts, and others. I suspect that maybe some of that written
code isn't fully REXX compliant, but I'd wager that they tried their
best. I doubt any of them looked at the REXX language and decided to
"cut out" parts of the REXX language (in the versions of the their
interpretors). And I certainly think that none of them would look
at a statement of my code
x=n//1
and call it "not a meaningfull app". (Or any other REXX code, for
that matter). I don't think it's in your perview to say what is or
isn't a meaningfull app.
INTERPRET isn't avoidable. I sure am not going to write 10k of code
to prove it is. That would be a serious, serous waste of my time.
You could, of course, prove me wrong by writting that 10k or REXX
code to replace INTERPRET. A REXX parser written in REXX would
certainly slow things down a bit for, say, my REXX calculator. Just
have 10k of code in a REXX program would really, really cause any
REXX interpretor pause when parsing the program. ___________Gerard S.
|> The opposite is easier to proove. An unique feature of CharOut() is not
|> adding some kind of <CR><LF>, unlike LineOut() or SAY. This means that
|> in "CALL CharOut '','How are you? ';PULL a", CharOut() isn't avoidable
|> nor replacable, using 100% Rexx. Unlike INTERPRET, CharOut() adds such
|> an unavoidable/unreplacable feature to Rexx.
|>
|> And again, perhaps your "SAY Date()//7" isn't a meaningfull app like I
|> asked for. It sounds like the work of a developer to me, who should be
|> able to write it to a file and translate/compile that file, assuming a
|> compiled result is a real requirement (for reasons unknown to me). If
|> not, feel free to write the possible 10,000+ lines of code yourself or
|> just proove using INTERPRET isn't avoidable (your example doesn't).
|>
|> And again, I'ld rather have some v1.0 of a translator/compiler without
|> INTERPRET-support than some delayed/unfinished project with INTERPRET-
|> support. INTERPRET is always avoidable, but I'm not going to write the
|> zillion lines of code to throw all possible, unprooved sticks back to
|> you! :-)
----snipped----
Ian Collier
and hastily scribbled some words to post to comp.lang.rexx:
>I just checked the ANSI spec, and it is quite clear that the SIGNAL
>condition is only turned off for the current call level. See the
>definition on page 96.
The definition on page 96 says that if #Enabling.#Condition.#Level == 'OFF'
then SYNTAX and HALT conditions terminate the program. It doesn't say
anything about checking the earlier levels.
It's done in levels so that when the current procedure ends the traps
will be restored to their previous states. However, it's only the
current level that has any effect on what happens when a signal is
trapped.
>This also matches the definition that's in Cowlishaw's The Rexx Language.
The definition on page 146 of TRL2 says that
Any ON or OFF reference to a condition trap will replace the previous state
(ON, OFF or DELAY, and any trap name) of that condition trap.
and
When a condition trap is currently disabled (OFF) and the specified
condition occurs, then the default action taken depends on the condition:
* For HALT and SYNTAX, the execution of the program is ended, and the
condition is usually indicated by a message describing the nature of
the event that occurred (see page 157).
Rick McGuire
> On Wed, 09 May 2007 12:40:27 -0400, Rick McGuire got out a palm pilot
> and hastily scribbled some words to post to comp.lang.rexx:
>> I just checked the ANSI spec, and it is quite clear that the SIGNAL
>> condition is only turned off for the current call level. See the
>> definition on page 96.
>
> The definition on page 96 says that if #Enabling.#Condition.#Level == 'OFF'
> then SYNTAX and HALT conditions terminate the program. It doesn't say
> anything about checking the earlier levels.
>
> It's done in levels so that when the current procedure ends the traps
> will be restored to their previous states. However, it's only the
> current level that has any effect on what happens when a signal is
> trapped.
And that's exactly what the ooRexx code is doing. It's turned off at
the current level when the trap is first raised. A new syntax error
happens, the call stack is unwound with the error (restoring the state
of the caller's traps), and when it gets to a level where the traps are
still enabled, the signal trap happens from the location of the call.
Rick
Ian Collier
>Ian Collier wrote:
>> The definition on page 96 says that if #Enabling.#Condition.#Level == 'OFF'
>> then SYNTAX and HALT conditions terminate the program. It doesn't say
>> anything about checking the earlier levels.
>> It's done in levels so that when the current procedure ends the traps
>> will be restored to their previous states. However, it's only the
>> current level that has any effect on what happens when a signal is
>> trapped.
>And that's exactly what the ooRexx code is doing. It's turned off at
>the current level when the trap is first raised. A new syntax error
>happens, the call stack is unwound with the error (restoring the state
>of the caller's traps)
[snip]
The standard says that an untrapped condition terminates the *program*,
not that it terminates the current routine. There is no unwinding - the
program just exits, with the "exit" instruction that's right there on
page 96.
gary.l...@lmco.com
> A short while ago I became aware that Rick McGuire had written:
>
> >Ian Collier wrote:
> >> The definition on page 96 says that if #Enabling.#Condition.#Level == 'OFF'
> >> then SYNTAX and HALT conditions terminate the program. It doesn't say
> >> anything about checking the earlier levels.
> >> It's done in levels so that when the current procedure ends the traps
> >> will be restored to their previous states. However, it's only the
> >> current level that has any effect on what happens when a signal is
> >> trapped.
> >And that's exactly what the ooRexx code is doing. It's turned off at
> >the current level when the trap is first raised. A new syntax error
> >happens, the call stack is unwound with the error (restoring the state
> >of the caller's traps)
>
> [snip]
>
> The standard says that an untrapped condition terminates the *program*,
> not that it terminates the current routine. There is no unwinding - the
> program just exits, with the "exit" instruction that's right there on
> page 96.
It's quite clear that some here don't give a flip about standards.
They're out to satisfy themselves and a small band that think like
themselves.
>
> --
> ---- Ian Collier : i...@comlab.ox.ac.uk : WWW page (including REXX section):
> ------http://users.comlab.ox.ac.uk/ian.collier/imc.shtml
ML
>> Given that it might take 10000 lines of rexx to duplicate the
>> functionality of INTERPRET, in some sense, the practicality of
>> doing so makes it "indespensible" and "essential".
that a replacement for your INTERPRET-calculator isn't a one-liner.
> I guess we could eliminate about half of REXX functions.
What has eliminating to do with supporting, and what has Rexx to do
with a *.EXE (if a developer just supports translation of comments,
in what way does that "eliminate" any Rexx function)?
> LEFT and RIGHT BIFs
Who, but you, mentioned not translating/compiling those no-brainers?
How would you embed INTERPRET? How would you include Sourceline(),
while hiding the original Rexx source?
> I wonder if Ian Collier (who, as far as I know, has written a REXX
> interpreter) even thought of NOT supporting any feature of REXX
> because it was too hard to do, or inconvient to do so.
What has having written a Rexx interpreter, other than trying to DROP
names, to do with the discussed translator/compiler?
> Same for Jeff Glatt, Kieth Watts, and others.
Which of those on this impresive list has written a Rexx compiler? Do
you know you're complaining about an app that doesn't exist (yet)? And
what about IBM not including INTERPRET-support in their v1.0 of their
Rexx compiler mentioned earlier?
> I don't think it's in your perview to say what is or isn't a
> meaningfull app.
So far you're the only one who came up with some meaningfull app, not
one showing off skills, and something an user may use. It met almost
all demands, except the one stating that the replacement could become
larger than a one-liner. You complained about that later. And I'm not
sure you'ld like the size of any translated/compiled Rexx app with the
support for INTERPRET, so that may become your next problem. And what
would be your solution for security issues, e.g. warning for a "FORMAT
C:" but not for a "x='FORMAT C:';INTERPRET x"?
> INTERPRET isn't avoidable. I sure am not going to write 10k of code
> to prove it is.
I'm sorry, nobody can, despite of you suggesting you really, really
could.
> A REXX parser written in REXX
We're talking about a Rexx translator/compiler. If you'ld kept that in
mind, you'ld compare the INTERPRET-one with a compiled version of the
PARSE-one, instead of making up another problem.
And no, a command-line calculator isn't the huge monster you're trying
to make it look like. I've got a CC.EXE here, size 12,599 bytes, it can
perform more trics than just the basic */+- math, and the matching
CC.DOC (plain text) is more than twice that size.
> would certainly slow things down a bit for, say, my REXX calculator.
Are you the same person who hadn't speed on his mind before w.r.t. to
optimizing (for speed, for one) and talked about "redefining Rexx" as
a related problem to that issue?
And since you always seem to be willing to show real test results, why
are you know using the phrase "would certainly slow down things"? I'm
not saying it wouldn't, nor it would, because this is just another
suggested, unprooved problem by you, all I notice it that suddenly
your usual evidence for such claims is missing here.
> Just have 10k of code in a REXX program would really, really cause
> any REXX interpretor pause when parsing the program.
Again, I don't think compiled Rexx code is a "Rexx interpreter". What
you wrote before basicly would come down to a "Rexx interpreter", and
we already have that, including e.g. the limited execution speed. You
may also notice that with your compiled CC.REX because of having to
use RXSTRINGS's to maintain accuracy compared to C's printf().
Anyway, the only thing you came up with so far (twice) is a calculator
using INTERPRET, a meaningfull app indeed, and so far that wasn't the
best attempt to illustrate that INTERPRET isn't avoidable/replacable.
All one would have left to complain about now is your size growth of
at least (your) 10 Kb, ignoring existing CC.EXE's of 12Kb bytes. But I
don't think mentioning "Rexx interpreters", DROP'ping names, mixing
interpreted code up with compiled code, and being able to mention
Substr() w.r.t. avoiding Left() has anything to do with the claim that
INTERPRET is always avoidable/replacable. You may not like that, you
may mention more problems, you may dislike IBM for submitting a v1.0
compiler without support for INTERPRET, and you may ignore that it's
a wishlist-item instead of a requirement. At least there's no problem
with the quantity of problems you're able to mention, I'ld say!
---