Perhaps "namespace-qualified symbol" assuming that is defined in the section on Namespaces? Just a thought.
This was an interesting one to figure out! The problem (s) are: using at[3] instead of at(3) and deciding on the meaning of "a stem not having an item associated with a tail". Thanks to trace i, the evaluation starts with s.~at which yields 23 the same as s.~at(). Then 23 gets the message '[3]' - a 'shorthand 'for substr(3,1) - which is the null string. So that leaves the second question. If a stem has a default value then every possible tail has a value. Might be good to explicitly state that in...
I have always disliked the term "classic Rexx" as I believe it is ambiguous. There is the "version" that corresponds to the VM implementation, the TRL2 version, the ANSI standard version and perhaps others. The REXX language has evolved (thank goodness!) since its original implementation and that has necessitated changes which sometimes make programs that ran under an earlier version fail under a newer version. In most cases, small changes to those programs will get them running again. I think that...
I agree that the RXPIPE package is probably NOT 64 bit based on this new information but it IS apparently an OS/2 package! I have no experience in the compatibility of OS/2 packages, especially compiled ones (the files are an exe and 2 dll's), with 32 bit Windows so I cannot say if one should expect them to work in that environment. Perhaps someone else might know the answer to that question.
Before I post my thought on this problem, let me make sure I understand the environment where you experience the failure. You have a PC that is running 64 bit Windows and has ooRexx 5.0.0 installed and running correctly. You now try to run portable 32 bit ooRexx 5.0.0 on that system which is known to be a supported scenario. However, you experience a problem seemingly related to a private package named RXPIPE. My question is what bit-ness is the RXPIPE package that is being run? If you have it installed...
Update document copyright dates to 2025
Problem with SysCls on Windows
Marking this as Pending w/ no work items.
Crash while attempting to resolve a routine in a library package.
Having looked at the history now it appears the code was fixed by Rick on 8/11/22 but still needed a test. P.O. then changed the target to 5.1.0 on 5/12/23. Erich then added the missing test on 11/21/24 and marked the work items as none and changed the status to pending. Since no external changes - code or documentation - were made since 5.0.0, I believe this should be closed so it isn't listed again in the 5.1.0 CHANGES file. I will change the Group back to 5.0.0.
'rexxc' binary (compiled/tokenized) data: please encode as plain text (7-Bit-ASCII) to allow it to be read as a string (e.g. from Java java.io.Reader)
Add a GUARD ON/OFF capability to the MethodContext APIs.
Crash while attempting to resolve a routine in a library package.
NewRoutine() and LoadPackageFromData() raise error 13.1 on tokenized Rexx code
.Routine~newFile(rexxc-program) raises error 13.1
Saving lines of code to what benefit I'd ask? Performance is probably not a concern and program size/memory usage isn't either. So you have a less understandable and therefor more difficult to maintain/enhance program for your saved lines of code. Not a choice I would make.
I agree that the "proper" response to d = .Directory~of() should be the same as d = .Directory~new and not an error message.
I feel this is a bug; i.e. the ';' terminates the clause so the 'ignored' should be part of the resource. Other directives work this way, consider the following syntactically correct code fragment: ::class dummy public; ::method gil; return yikes! ::method foo; ::method bar ::attribute one; ::attribute two
I feel this is a bug; i.e. the ';' terminates the clause so the 'ignored' should be part of the resource. Other directives work this way, consider the following syntactically correct code fragment: ::class dummy public; ::method gil; return yikes! ::method foo; ::method bar ::attribute one; ::attribute two
"show a string of candidates able to obey this order." - close but not quite :-) It's more like "return the value of the class attribute named ...". They could have been named BigLetters and SmallLetters vs. upper and lower just as well; there isn't any correspondence between the "upper"/"lower" instance methods and the "upper"/"lower" class attributes other than they are spelled the same. HTH
OK, fair enough. But I still find it "surprising" that the determination of the routine and method objects to be traced under "::options trace" is made when the directive is processed and not at run time.
I found it interesting that you found that no code changes were required, just creating a new method object from the same source would do the trick. I'm guessing the processing of the ::options trace directive must build a "list" of method objects to be traced and when one replaces or adds one (or more) of them with new objects, they will not be on the already created "list" and therefore not get traced. Good to know!
Glad it was helpful!
Well, you have "discovered" the essence of what I did for that presentation 10 years ago. I am going to send you the PDF off-list so you can compare what I did with your proof of concept. While my program was concerned with adding trace statements to methods prior to their execution, the same approach could add a "call trace <whatever>" to suppress tracing in selective methods. I hope you can make use of the code in some form.</whatever>
At the 2014 Symposium I did a presentation that addressed this topic. René recently asked me to update the documentation for the purpose of publishing the RexxLA Symposium proceedings. Here is the opening section of that document. ooRexx Tracing through Metaprogramming A recent discussion on the RexxLA list regarding the lack of a "global trace" capability in ooRexx led to an analysis of tracing in an object oriented environment. Due to encapsulation, each method of a class begins execution with...
Yes, that too will work. I often put a line like the following in my code when I am developing so that I can see where I am in the code. say "Starting the initialization...";pull This will pause until I press Enter. Since I am discarding the user input, I don't care if it is upper cased (!) so I use 'pull' - less typing - rather than 'parse pull' or 'pause'.
Actually it's GUI_Template.rex and it's in the samples\oodialog directory. Thanks for the pointer Jon!
Actually it's GUI_Template.rex and it's in the samples directory. Thanks for the pointer Jon!
In addition to the initDialog method that Jeremy identified, you might want to have a look at the defineDialog method as well. One of my stumbling blocks in learning to use OODialog was the fact that there are different "stages" in the creation process and that you need to do things in the correct "stage" in order for it to work. This is due to the fact that you are working with Windows objects and they have their own rules that need to be followed.
Mod seems to be a "leftover". The original post contained "mod 10^15" as the last part of the calculation so one could code "// mod" to do that in Rexx. However, Erich has chosen to do "~right(15)" instead. HTH
I suggest the example be modified to: say .String~instanceMethods(.String)~allIndexes~sort~toString(,',') which gives (on my system): ALNUM,ALPHA,BLANK,CNTRL,CR,DIGIT,GRAPH,LOWER,NEW,NL,NULL,PRINT,PUNCT,SPACE,TAB,UPPER,XDIGIT
I don't think this is a "bug". Since rexxhide doesn't have a console window perhaps the Windows object that is returned from the ExecQuery message is telling the truth about its CommandLine. More research is needed on the properties of that Windows object.
Fixed a problem with copying old Common_Content data.
Modify copyright year.
Remove Jenkins specific code.
Fixes to run on Jenkins.
Fixes re. testing on Jenkins/Darwin.
Changes to allow using the ooRexx scripts to build the documents if all the necessary programs are available.
Changes for better MacOS support re. XMLCATALOG; automatically update SVN revision level and date.
I have a question re. the workaround. Is there a difference between .context~package~addPackage(.Package~new('oodialog')) and .context~package~loadPackage('oodialog.cls') ?
It appears that the sample programs are minimally documented in the Programmer Guide in Appendix B. We should probably add these new samples in there as well.
My bad for using the phrase "clear the screen attribute buffer". Filling the attribute buffer with the current attribute is the correct behavior to mimic CLS. If you starts with a "default" command prompt screen - "dark" white characters on a black background - and issues the command COLOR F0, the screen becomes black characters on a bright white background. Then if you issue CLS, the background remains bright white as you would expect I hope. Thanks for fixing this!
Problem with SysCls on Windows
I suspect the colon is a left-over from DOS and was retained for compatibility. But by including it, you are indicating that you are referring to the port and not a file. (Filenames cannot include a ":" except following a drive letter; e.g. c:\rexx\myfile). So "com3" is ambiguous as it could be either a file or the third com port. Not sure what happens if you have both.
Did you try it with the colon as shown in the example? And there are two documents for a reason. Not everything belongs in the Reference.
Check out the Programmer Guide -rexxpg.pdf - specfically section 7.14 for the correct syntax to specify a COMx port.
ooDialog reference 4.2.4 ComboBox class missing set/get/remove itemdata methods
Description of PARSE SOURCE is inaccurate
In rexxref, "8.2. List of Rexx Utility Functions", SysSetPriority is not marked as (Windows only)
Rexxref "1.10.4.6. Operator Characters" should mention that adjacent comments are allowed and ignored, like whitespace
Rexxref 7.4.71.2. "Global environment variables" example inaccurate
Rexxref 1.13.2. "Constant Symbols": Incorrect description of environment symbols
RexxRef 7.4.40 Description of LINEOUT BIF ambiguous
rexxref 2.10, "IF", note 2 inaccurate
Missing comma in RexxRef 1.31.3 "Extended Assignments"
Missing comma in RexxRef 1.31.3 "Extended Assignments"
The same error occurs in 1.12.5.1. Corrections committed with r12724
The same error occurs in 1.12.5.1. Corrections committed with 12724
Fix typos and boldface errors re. extended assignment.
I believe the correct section is 1.13.1 and I do NOT see the "can" highlighted. However, the "and" is (incorrectly) boldfaced.
Actually, after looking at the 4.2.0 version of Rexxtry, I think the original fix is correct. Note the comment on line 244: "What oper system ETC." (emphasis mine). It appears the intent is to display the full returned string from "parse source".
Line 83 correctly gets the first word of the string returned by parse source. A "more correct" fix is to change line 244 to: say " 'source' = '"sysrx"'" /* What oper system etc. */ This line is the only place the variable source is used so changing it to sysrx will make it consistent with the rest of the program.
Parameters missing if the first one is the empty string
Fix committed with r12708
Parameters missing if the first one is the empty string
Fix commited with r12708
SYSCARGS wrong in REXXHIDE
Fixes for missing parameters, bug 1912, and wrong SYSCARGS, bug 1916.
SYSCARGS wrong in REXXHIDE
Parameters missing if the first one is the empty string
I have created a 32-bit version of rexx.exe and placed it here. Let me know if this works any better for you. Please delete the previous version.
Ah, I have not experimented with the "portable" versions so I suspect that is the problem. Oh, I just realized that you are on a 32-bit system and I am running 64-bit so ignore the above comment. I will rebuild the rexx.exe for 32-bit later and replace the one in my Dropbox. Sorry for forgetting that detail. :-(
For some reason I haven't received your email address so I decided to make the module available here . Download the file and place it in the directory where you are going to run the tests. Then be sure to run your program by specifying "rexx <test program="" name="">" rather than just "<test program="" name="">" or else Windows will use the rexx.exe in %rexx_home%.</test></test>
Actually, the only module affected is rexx.exe so I can send that to you if you'd like to do some testing. The rexxhide.exe is also affected as it too uses ArgumentParser.h so let me know if you need that program as well. No schedule yet for 5.0.1 so this would be your best bet.
After further analysis and testing I have determined that the problem lies in the call to nextArgument after the program name has been found. By replacing that call with a loop to scan the remainder of the command line for a non-blank character (indicating that parameter(s) is/are present) I was able to fix the problem. If no one else comes up with a fix in a few days, I will commit my change.
The OP reported this on Windows 10 with ooRexx 5.0.0 32-bit but my tests were run on Windows 10 ooRexx 5.1.0 64-bit at r12694.
Well, I have narrowed down where the bug is but need someone with better C debugging skills than me to isolate it and fix the code. I opened a bug report (#1912) so hopefully it will get addressed soon.
Parameters missing if the first one is the empty string
It turns out that it does use GetCommandLine() but there appears to be a bug in how it processes the results. I'll have a look at it and report back.
Looks like we have one for Apple but not Darwin. Would that work?
+1 and thanx!
Problem with Do ... Over
Just to clarify that the queue referenced by queued() is an instance of .rexxqueue and not .queue. I know that this may be confusing since both refer to their instances as "queues".
While it does no harm to have a shebang line in a script that runs on Windows - it is ignored - it might be misleading to someone examining the code if the script ONLY runs on Windows. The last 3 files fall into that category. I would recommend NOT putting a shebang line in scripts that are only able to be run on Windows (e.g. ooDialog samples).
Without doing a lot of research, and I generally dislike comments/suggestions made without doing the appropriate "homework", let me offer my take on the situation. Lets assume there is a program, lets call it pgmA, that needs to run on multiple Rexx interpreter instances. pgmA needs another program, call it pgmB, and so pgmA ::REQUIRES pgmB. However, the prolog code of pgmB must run on every interpreter instance. From the above comments by Rick, this will NOT be the case. Assuming I have the situation...
Without doing a lot of research, and I generally dislike comments/suggestions made without doing the appropriate "homework", let me offer my take on the situation. Lets assume there is a program, lets call it pgmA, that needs to run on multiple Rexx interpreter instances. pgmA needs another program, call it pgmB, and so pgmA ::REQUIRES pgmB. However, the prolog code of pgmB must run on every interpreter instance. From the above comments by Rick, this will NOT be the case. Assuming I have the situation...
Fix problem where images and diagrams were not getting included.
Redesign to handle docpaths containing a drive letter which are therefore not valid URLs.
Determine the current download site for FOP before downloading it.
Determine the current download site for FOP before downloading it.
Here are the revised pages for Rexxref section 7.2.1.1
Probably should change the status to closed rather than pending as this package is in the incubator and not part of a release build.
As noted earlier in a different bug report, rexxutil.dll is no longer part of the distribution as of 5.0.0. All of the functions have been integrated into rexx.dll. I cannot offer any advice, however, on the issue with your unique ADDRESS environment.
Add comp.lang.rexx to the list of places for announcement.
Add ADDRESS WITH capability
Problems with ANSI Escape Sequences
Update the tool package used to build the ooRexx documentation on Windows
REXXSTART references in REXXREF wrong
Errors building Winextensions
Issues with CSS for HTML versions of documents