Rick McGuire

The nsis installer build requires that the DOC_SOURCE_DIR be set to the location of the doc artifacts that are included in the installer. Have you done that? Rick On Fri, Apr 24, 2026 at 11:03 AM Graham Norris norrisg@users.sourceforge.net wrote: I am following that readme. The CMakeLists.txt file is being built, and it does have nsis_template_installer in it. It just does not appear to get used when I run: nmake nsis_template_installer from the build directory. [bugs:#2059] Can't build installer...

On Tue, Apr 21, 2026 at 1:37 PM Jeremy Nicoll jeremynicoll@users.sourceforge.net wrote: On Mon, 20 Apr 2026, at 23:53, Rick McGuire wrote: Each loaded package ... Thank-you for the detailed reply. What I don't understand is why, in 1) Each ::REQUIRES is processed. //If the package has not already been loaded, the file is loaded// when it seems to me that if the //..// part was replaced with //If the package has not been seen on an earlier ::REQUIRES, the file is loaded// Well, that IS what happens....

Each loaded package needs to resolve its operating environment before it can begin its loading process. This means obtaining all of the public routines and classes defined in the packages referenced via ::REQUIRES. Once that is done, then the process of actually creating the classes defined in the packager can proceed and all of the code that needs to run when the package is loaded can run because the references have been obtained in a clean state. So for a simple case of file A requiring file B...

On Sun, Apr 19, 2026 at 2:47 PM Jeremy Nicoll jeremynicoll@users.sourceforge.net wrote: On Sun, 19 Apr 2026, at 18:26, Rony G. Flatscher wrote: Hi Graham, here Rick's answer: It only seemed to be working on 4.2.0, but there were all sorts of underlying problems. When the second package loaded, all of the initializations from the first file were not yet complete, because the first step of loading is to resolve the ::REQUIRES. Maybe that means ooRexx should first JUST follow/resolve the ::REQUIRES...

This sort of begs the question as to whether thies new methods should return self to make message chaining easier. On Fri, Apr 10, 2026 at 10:49 AM Gil Barmwater orange-e@users.sourceforge.net wrote: status: accepted --> pending [documentation:#361] RexxRef example 5.249 wrong Status: pending Group: 5.2.0 Created: Thu Apr 09, 2026 07:00 PM UTC by Gil Barmwater Last Updated: Fri Apr 10, 2026 02:48 PM UTC Owner: Gil Barmwater The example shows the use of the new writeLines class method of the File...

On Thu, Apr 2, 2026 at 2:41 PM noreply@sourceforge.net wrote: On 4/2/2026 8:14 AM, Jon Wolfers wrote: Hi Rony, I think so - others may know better. I'm not exactly sure how DO OVER works, but I think that would mean executing an unnecessary array~makearray method (you are in effect iterating over .file~readlines(myFile)~makearray) but I'm not sure (and don't currently have time to experiment) what sort of performance hit if any is caused by the array class makearray when the array is already non...

One thing I don't like about the BIF approach is that adding BIFs is an automatic incompatibility because there's just a single namespace available for functions/subroutines. There's always a danger of a conflict with existing programs when BIFs are added. Adding methods to class is shielded from that danger. Rick On Tue, Mar 31, 2026 at 5:46 PM Gil Barmwater orange-e@users.sourceforge.net wrote: For those who would like to try the BIF approach, here is public function named Arrayin that you can...

Another possibility to consider is to add instance methods to the .File class rather than class methods to the .Stream class. Rick On Mon, Mar 30, 2026 at 5:55 AM Rony G. Flatscher orexx@users.sourceforge.net wrote: It is about simplifying access to this important functionality, as it is something that more and more often gets exercised. Following the Rexx philosophy to make it easy for humans, programmers, the RFE tries to minimize the coding needs for the ooRexx programmers, when a need exists...