You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
|
Feb
|
Mar
(2) |
Apr
(4) |
May
(35) |
Jun
(6) |
Jul
(23) |
Aug
(25) |
Sep
|
Oct
(72) |
Nov
(25) |
Dec
(13) |
2006 |
Jan
(104) |
Feb
(19) |
Mar
(43) |
Apr
(19) |
May
(62) |
Jun
(133) |
Jul
(44) |
Aug
(46) |
Sep
(68) |
Oct
(45) |
Nov
(97) |
Dec
(19) |
2007 |
Jan
(75) |
Feb
(232) |
Mar
(116) |
Apr
(368) |
May
(111) |
Jun
(134) |
Jul
(97) |
Aug
(107) |
Sep
(173) |
Oct
(579) |
Nov
(256) |
Dec
(213) |
2008 |
Jan
(242) |
Feb
(73) |
Mar
(26) |
Apr
(13) |
May
(10) |
Jun
(201) |
Jul
(367) |
Aug
(341) |
Sep
(246) |
Oct
(304) |
Nov
(104) |
Dec
(103) |
2009 |
Jan
(80) |
Feb
(183) |
Mar
(165) |
Apr
(302) |
May
(255) |
Jun
(136) |
Jul
(189) |
Aug
(107) |
Sep
(179) |
Oct
(94) |
Nov
(47) |
Dec
(86) |
2010 |
Jan
(102) |
Feb
(142) |
Mar
(86) |
Apr
(182) |
May
(77) |
Jun
(56) |
Jul
(14) |
Aug
(182) |
Sep
(117) |
Oct
(87) |
Nov
(76) |
Dec
(76) |
2011 |
Jan
(27) |
Feb
(196) |
Mar
(69) |
Apr
(26) |
May
(9) |
Jun
(54) |
Jul
(60) |
Aug
(49) |
Sep
(11) |
Oct
(38) |
Nov
(49) |
Dec
(32) |
2012 |
Jan
(61) |
Feb
(166) |
Mar
(72) |
Apr
(66) |
May
(33) |
Jun
(138) |
Jul
(89) |
Aug
(354) |
Sep
(61) |
Oct
(69) |
Nov
(60) |
Dec
(45) |
2013 |
Jan
(14) |
Feb
(13) |
Mar
(29) |
Apr
(52) |
May
(63) |
Jun
(68) |
Jul
(32) |
Aug
(13) |
Sep
(34) |
Oct
(49) |
Nov
(86) |
Dec
(219) |
2014 |
Jan
(101) |
Feb
(72) |
Mar
(50) |
Apr
(32) |
May
(99) |
Jun
(141) |
Jul
(89) |
Aug
(14) |
Sep
(137) |
Oct
(221) |
Nov
(18) |
Dec
(10) |
2015 |
Jan
(50) |
Feb
(12) |
Mar
(33) |
Apr
(86) |
May
(72) |
Jun
(90) |
Jul
(33) |
Aug
(9) |
Sep
(9) |
Oct
(27) |
Nov
(25) |
Dec
(9) |
2016 |
Jan
(16) |
Feb
(27) |
Mar
(16) |
Apr
(12) |
May
(23) |
Jun
(80) |
Jul
(127) |
Aug
(39) |
Sep
(12) |
Oct
(32) |
Nov
(20) |
Dec
(29) |
2017 |
Jan
(46) |
Feb
(77) |
Mar
(19) |
Apr
(36) |
May
(99) |
Jun
(45) |
Jul
(75) |
Aug
(53) |
Sep
(26) |
Oct
(57) |
Nov
(22) |
Dec
(4) |
2018 |
Jan
(11) |
Feb
(48) |
Mar
(80) |
Apr
(159) |
May
(41) |
Jun
(10) |
Jul
(36) |
Aug
(84) |
Sep
(76) |
Oct
(38) |
Nov
(177) |
Dec
(319) |
2019 |
Jan
(213) |
Feb
(244) |
Mar
(95) |
Apr
(48) |
May
(19) |
Jun
(3) |
Jul
(2) |
Aug
(17) |
Sep
(16) |
Oct
(35) |
Nov
(68) |
Dec
(20) |
2020 |
Jan
(16) |
Feb
(91) |
Mar
(244) |
Apr
(139) |
May
(13) |
Jun
(42) |
Jul
(29) |
Aug
(60) |
Sep
(53) |
Oct
(19) |
Nov
(63) |
Dec
(3) |
2021 |
Jan
(51) |
Feb
(72) |
Mar
(87) |
Apr
(31) |
May
(19) |
Jun
(73) |
Jul
(93) |
Aug
(31) |
Sep
(24) |
Oct
(79) |
Nov
(60) |
Dec
(24) |
2022 |
Jan
(49) |
Feb
(33) |
Mar
(13) |
Apr
(29) |
May
(92) |
Jun
(66) |
Jul
(64) |
Aug
(54) |
Sep
(22) |
Oct
(2) |
Nov
(23) |
Dec
(252) |
2023 |
Jan
(100) |
Feb
(121) |
Mar
(13) |
Apr
(43) |
May
(46) |
Jun
(24) |
Jul
(19) |
Aug
(8) |
Sep
(17) |
Oct
(15) |
Nov
(25) |
Dec
(24) |
2024 |
Jan
(43) |
Feb
(14) |
Mar
(40) |
Apr
(59) |
May
(37) |
Jun
(36) |
Jul
(41) |
Aug
(20) |
Sep
(43) |
Oct
|
Nov
|
Dec
|
Hi Jeff, On 18.09.2024 18:02, Jeff Hennick wrote: > Thank you for your considered reply. > > The "Need extended ooRexx" was while following > > Jean Louis Faucher'sasciinema demos, at the top the demos forooRexxShell: > <https://jlfaucher.github.io/executor.master/demos/index.html>. > > You did note > > Please note that these demos may use experimental extensions of Jean Louis > executor (a special version based on ooRexx 4.2) which are not present > in the regular versions of ooRexx. > > and I just bypassed those examples. > Ah, I see. > But the *run nrc -exec which_rexx.rex* was from your email > Yes. Please note the command, it is not from within the oorexxshell but from the bare terminal/command line window. >> ---> use the generated 'setenv.cmd/setenv' script If you issue the above script in a shell/terminal/command line window then the changes to the environment stick in that particular shell/terminal/command which alleviates one to prepend the commands with "run" (respectively "./run" on Unix or powershell). All the following commands then work within that shell/terminal /command without using "run" ("./run"). Please note that these are not supplied via the oorexxshell but directly into the operating system's shell/terminal/command line window. >> >> Windows Unix Comment >> ------- ---- +------ >> setenv.cmd source ./setenv | sets the environment in the Terminal to net-oo-rexx >> >> the following commands will work on Windows as well as on Unix: >> >> oorexxshell | runs oorexxshell >> >> rexx testoorexx.rex | use ooRexx to run testoorexx.rex >> rexx which_rexx.rex | use ooRexx to run which_rexx.rex >> >> rexxdebugger packages/rexxdebugger/tutorial.rex | use ooRexx to run the rexxdebugger with its tutorial.rex >> >> nrc -exec which_rexx.rex | use NetRexx to run which_rexx.rex >> >> nrc which_rexx.rex | use NetRexx to compile which_rexx.rex to which_rexx.class >> java which_rexx | use Java to run which_rexx.class (note: no ".class" extension!) > > The *run rexx which_rexx.rex* works fine. But *run nrc -exec which_rexx.rex* fails. > What does the command on a bare (operating system) terminal/command line (not from oorexxshell which would need that command to be placed under quotes in order to be passed on to the operating system from ooRexx) nrc -exec which_rexx.rex yield? ---rony |
From: Rony G. F. <Ron...@wu...> - 2024-09-18 15:23:54
|
Hi Jeff, On 18.09.2024 01:17, Jeffrey Hennick wrote: > > I have run into a problem trying NetRexx under the newest oorexxshell. This is on a Windows 11 / > WSL Ubuntu laptop. I have been following the sequence listed below. It all works (except where > it says "Need extended ooRexx") > When does "Need extended ooRexx" appear, how do you get it? > until I get to the NetRexx command *run nrc -exec which_rexx.rex*. It looks like it does not know > about nrc. > It will. > > Then I tried it as a direct command. > ... cut ... > > While I don't know enough of what is going on, it looks like the *setup* routine kept the existing > path to NetRexx and added its own, so somehow the wrong NetRexxF.jar gets called, it apparently > has problems. -?- > > Any help would be very welcome. > The portable net-oo-rexx package is meant to not change an installation. Rather its "setup" will create a "run" and a "setenv" command that will prepend the paths to the net-oo-rexx packages to PATH and CLASSPATH leaving it otherwise intact. In a session you can use then to run the oorexxshell from Jean Louis, which is part of the net-oo-rexx package like this: run oorexxshell This command does the following: * the "run" script changes the environment variables PATH and CLASSPATH to have the net-oo-rexx packages placed in front of everything, * it then will run the "oorexxshell" script which loads the versatile "oorexxshell", which itself loads all its packages In my case the following gets displayed: E:\DropBox\Dropbox\xfer\oorexxshell\net-oo-rexx.windows.x86_64-portable-release-20240827>run oorexxshell loadPackage OK for C:\Users\Administrator\.config\oorexxshell\custom1.rex loadPackage OK for extension/stringChunk.cls loadPackage OK for utilities/indentedStream.cls loadPackage OK for extension/std/extensions-std.cls loadPackage OK for procedural/dispatcher.cls loadPackage OK for oodialog.cls loadPackage OK for winsystm.cls loadPackage OK for csvStream.cls loadLibrary OK for hostemu loadPackage OK for json.cls loadPackage OK for mime.cls loadPackage OK for rxftp.cls loadLibrary OK for rxmath loadPackage OK for rxregexp.cls loadPackage OK for regex/regex.cls loadPackage OK for smtp.cls loadPackage OK for socket.cls loadPackage OK for streamsocket.cls loadPackage OK for pipeline/pipe.cls loadPackage OK for rgf_util2/rgf_util2.rex loadPackage OK for BSF.CLS loadPackage OK for jdor.cls loadPackage OK for oorexxshell_clauser.cls REXX-ooRexx_5.1.0(MT)_64-bit 6.05 21 Jul 2024 Input queue name: S0000000000001848Q000001B1CB35D210 E:\DropBox\Dropbox\xfer\oorexxshell\work ooRexx[CMD]> The prompt "ooRexx[CMD]" indicates that it is ooRexx that will process your entries and that its default address environment is "CMD", the Windows cmd.exe command line interpreter. You could change that default address to e.g. JDOR which is available via BSF4ooRexx (BSF.CLS was loaded successfully if you look up the loaded packages above) by entering: ooRexx[CMD]> address jdor Duration: 0 E:\DropBox\Dropbox\xfer\oorexxshell\work ooRexx[JDOR]> say address() JDOR Duration: 0 E:\DropBox\Dropbox\xfer\oorexxshell\work ooRexx[JDOR]> So by default oorexxshell will hand over every entry for ooRexx to execute. (As long as you run oorexxshell the changed environment will stay set to what the "run" script defined.) Now, your entry: ooRexx[CMD]> nrc -exec which_rexx.rex is taken as a Rexx statement that deducts "exec" from "nrc" and appends "WHICH_REXX.REX" to the result, but nrc is not a Rexx variable such that it evaluates to "NRC" - a string - causing the error: Nonnumeric value ("NRC") used in arithmetic operation. Error code= 41.1 If your current shell is ooRexx then you would have to enquote the command to have ooRexx pass it to CMD, so this is what you should enter in this case: ooRexx[CMD]> "nrc -exec which_rexx.rex" Or, you could change the command interpreter from ooRexx to CMD by entering "cmd" ooRexx[CMD]> cmd E:\DropBox\Dropbox\xfer\oorexxshell\work cmd> And then you can enter the command without quotes: cmd> nrc -exec which_rexx.rex yielding the output: java -cp "E:\DropBox\Dropbox\xfer\oorexxshell\net-oo-rexx.windows.x86_64-portable-release-20240827\packages\bsf4oorexx\lib\*;.;C:\Users\Administrator\BSF4ooRexx\lib\*;E:\DropBox\Dropbox\xfer\oorexxshell\net-oo-rexx.windows.x86_64-portable-release-20240827\packages\..\netrexx\lib\NetRexxF.jar;E:\DropBox\Dropbox\xfer\oorexxshell\net-oo-rexx.windows.x86_64-portable-release-20240827\packages\bsf4oorexx\lib\*;.;C:\Users\Administrator\BSF4ooRexx\lib\*;E:\DropBox\Dropbox\xfer\oorexxshell\net-oo-rexx.windows.x86_64-portable-release-20240827\packages\..\netrexx\lib\NetRexxF.jar;C:\Program Files\BSF4ooRexx850\lib\*;.;C:\Users\Administrator\BSF4ooRexx\lib\* ;;." -Dnrx.compiler=ecj org.netrexx.process.NetRexxC -exec which_rexx.rex NetRexx portable processor 4.06-GA build 152-20240304-0612 Copyright (c) RexxLA, 2011,2024. All rights reserved. Parts Copyright (c) IBM Corporation, 1995,2008. Program which_rexx.rex ===== Exec: which_rexx ===== parse version: NetRexx 4.06 03 Mar 2024 parse source : Java method which_rexx.rex directory() : E:\DropBox\Dropbox\xfer\oorexxshell\work Processing of 'which_rexx.rex' complete Duration: 0.703000 E:\DropBox\Dropbox\xfer\oorexxshell\work cmd> It gives you the duration of the command nevertheless (in this case NetRexx gets loaded, the script in "which_rexx.rex" gets compiled to Java and then the Java class gets executed). To switch back to the ooRexx shell you would enter: cmd> oorexx E:\DropBox\Dropbox\xfer\oorexxshell\work ooRexx[CMD]> The ooRexx shell allows you to get at help by entering a question mark: ooRexx[CMD]> ? Queries: ?: display help. ?bt: display the backtrace of the last error (same as ?tb). ?d[ocumentation]: invoke ooRexx documentation. ?i[nterpreters]: interpreters that can be selected. ?s[ettings]: display ooRexxShell's settings. ?sf: display the stack frames of the last error. ?tb: display the traceback of the last error (same as ?bt). ?v[ariables]: display the defined variables. Commands: /* alone: Used in a demo to start a multiline comment. Ended by */ alone. < filename: read the file and put each line in the queue. color off|on: deactivate|activate the colors. color codes off|on: deactivate|activate the display of the color codes. debug off|on: deactivate|activate the full trace of the internals of ooRexxShell. demo off|on|fast: deactivate|activate the demonstration mode. exit: exit ooRexxShell. goto <label>: used in a demo script to skip lines, until <label>: (note colon) is reached. indent+ | indent-: used by the command < to show the level of inclusion. infos off|on|next: deactivate|activate the display of informations after each execution. prompt off|on [a[ddress]] [d[irectoy]] [i[nterpret]]: deactivate|activate the display of the prompt components. readline off: use the raw parse pull for the input. readline on: delegate to the system readline (history, tab completion). reload: exit the current session and reload all the packages/libraries. security off: deactivate the security manager. No transformation of commands. security on : activate the security manager. Transformation of commands. sleep [n] [no prompt]: used in demo mode to pause during n seconds (default 2 sec). test regression: activate the regression testing mode. trace off|on [d[ispatch]] [f[ilter]] [r[eadline]] [s[ecurity][.verbose]]: deactivate|activate the trace. trap off|on [l[ostdigits]] [nom[ethod]] [nos[tring]] [nov[alue]] [s[yntax]]: deactivate|activate the conditions traps. Input queue name: S0000000000001848Q000001B1CB35D210 E:\DropBox\Dropbox\xfer\oorexxshell\work ooRexx[CMD]> If you want to learn the different shells (command interpreters) that ooRexxShell can offer on your system, you just enter "?i" which on my Windows 10 system yields: ooRexx[CMD]> ?i Interpreters: cmd: to activate the cmd interpreter. command: to activate the cmd interpreter. hostemu: to activate the HostEmu interpreter. oorexx: to activate the ooRexx interpreter. pwsh: to activate the pwsh interpreter. system: to activate the cmd interpreter. E:\DropBox\Dropbox\xfer\oorexxshell\work ooRexx[CMD]> ooRexxShell can do so much more, hence it pays to invest a couple of minutes and check out the very nice ASCINEMA tutorials by Jean Louis at: https://jlfaucher.github.io/executor.master/demos/index.html The first three tutorials are about ooRexxShell, just look through them, they are really informative and very interesting, here the direct links: * https://jlfaucher.github.io/executor.master/demos/index.html#interpreters * https://jlfaucher.github.io/executor.master/demos/index.html#queries * https://jlfaucher.github.io/executor.master/demos/index.html#helpers (The tutorials about "executor" are about a special version of ooRexx that Jean Louis has created and enhanced with many different interesting features to experiment with, including full Unicode support.) HTH ---rony |
Hi Jeff, On 17.09.2024 20:58, Jeff Hennick wrote: > > Self answer: > > The problem apparently is Windows "*Extract All*." > Where does this come from? The Windows Explorer? The PowerShell? > I retried "unzipping" using 7-Zip and it worked without problems. (And faster!) > Thank you for this important information! > > So at this point I have the *ooRexxCMD]>* prompt, and am happy. > +1 Cheers ---rony |
From: Chip D. <ch...@ar...> - 2024-09-18 14:27:44
|
Yes, we need a non-judgemental term for such anomalies. Perhaps, "Surprise" or "Anomaly". Or some other friendly snowclone for Dijkstra's "harmful". -Chip- On 9/18/2024 9:03 AM, René Jansen wrote: > I support this point. Not from a semantic or categorical point of > view (the fact that an "issue" can be categorized as "invalid" is > befoisted upon us by issue tracking systems ("bugs" was earlier > judged to be too judgemental)) but from the practical position that > everything in the ooRexx source realm which is captured in version > management repositories should be correct. > > The particular problem with not working test cases is that it > muddles the definition of what the interpreter should do. This also > holds for test cases failing on a subset of the supported platforms. > > I agree that the tone is important. We should all be very careful in > our interactions with others - we are all members of a very small > group that use and like the Rexx programming language in all its > variants. So the signalling of errors in tests should be > acknowledged and the tests should be fixed - even if we invent a > friendly synonym of "invalid" - I think it is the intent that counts. > > best regards, > > René. > > > > >> On 18 Sep 2024, at 10:46, Josep Maria Blasco >> <jos...@gm...> wrote: >> >> Hi P.O., >> >> Well, not everybody seems to appreciate the "invalid" treatment, >> see https://sourceforge.net/p/oorexx/bugs/1976/?limit=25#2ef9 as a >> recent example. >> >> To state the obvious, when somebody spends her time detecting and >> documenting a bug, she's working for free for the project, she's >> giving to the community. >> >> For example, somebody who detects a malfunction in the test suite >> has to: a) know that the test suite exists; b) have the test suite >> installed; c) have run the test suite (which takes some time), and >> d) document the said malfunction. >> >> All of this requires a non-inconsiderable skill set. "Invalid" >> ---says Google, following Oxford--- means "not legally recognized >> because it contravenes a regulation or law" (as a noun, it means "a >> person made weak or disabled by illness or injury"). >> >> To summarize, we have a certain user, let's call her A. A has a >> considerable skillset. A has donated her free time and resources to >> the community to report what she considers to be a bug. This bug >> happens to refer to the test suite. Then A is told that her >> contribution is not legally recognized "because it contravenes a >> regulation or law". >> >> To me, this looks like a fantastic recipe to alienate A from the >> community. Specially when, as far as I know, there is no >> established protocol to report bugs in the test suite. >> >> Words are not meaningless identifiers. They are important, because >> they happen to have meanings. Meanings are dangerous: they can >> please and hurt, they can bind and unbind. When used wrongly, they >> can alienate very valuable people. People we need, because we are >> not precisely a huge community. >> >> My impression is that new, different names should be chosen, with >> some urgency. Names that do not have these ugly connotations: >> "Invalid", for example, is a toxic word. And the work that somebody >> has done for the community should always be acknowledged and >> appreciated. When I work on a project, the results R of my work may >> be wrong, but the fact F that I have worked can never be wrong. >> "Invalid" might apply to R, but never to F. One has to be careful. >> >> Josep Maria >> >> Missatge de ooRexx <oo...@jo...> del dia dt., 17 de set. 2024 >> a les 23:03: >> >> Hi Joseph Maria, >> >> If the reason for the behavior emanates from a change to the >> code it is a bug and should be reported in the bug tracker, as >> you did. >> >> Bugs in the test cases are not considered bugs and will be >> closed as “invalid” by the developers, only bugs in the >> interpreter are considered bugs. Hence “Feature”. One can >> report them to this list if the developers did not already spot >> them. >> >> Hälsningar/Regards/Grüsse, >> ooRexx >> oo...@jo... >> >> _______________________________________________ >> Oorexx-devel mailing list >> Oor...@li... >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > > > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel |
From: René J. <rvj...@xs...> - 2024-09-18 13:49:09
|
Hi P.O., the problem with this is that when an error occurs during testing it is not immediately clear whether this indicates a bug in the interpreter or the test case. So the onus should be on the person servicing the bug to categorize it as an interpreter, test case or platform bug - one could imaging that on a specific platform an otherwise correct implementation triggers an error in a system service - when a workaround is needed or possible then would be the next decision. So this practice needs change. best regards, René. > On 18 Sep 2024, at 15:41, P.O. Jonsson <oo...@jo...> wrote: > > Hi again Josep Maria, > > I did not create the current practice, in fact I was just as upset as you and others the first time my bug report was closed as „invalid“ :-( > > Having learned a bit more about the release procedure I realized that there was reason for this stricter definition of „Bugs“; when preparing for the release one want to list all improvements and bugs fixed in the Interpreter/language, hence any bugs in a test case are not really relevant at that point and only create additional work. > > Rather than trying to tweak the wordings I would be in favor of creating a new category of „bugs“ in the bug tracker that could involve anything that is not a bug in the Interpreter itself. When I look at Sourcforge there is a category „Test Cases“ under Tickets that is sparingly used. Would it not be possible to agree to file/move all bugreuports for test cases to that category? > > Hälsningar/Regards/Grüsse, > P.O. Jonsson > oo...@jo... > > > > >> Am 18.09.2024 um 10:46 schrieb Josep Maria Blasco <jos...@gm...>: >> >> Hi P.O., >> >> Well, not everybody seems to appreciate the "invalid" treatment, see https://sourceforge.net/p/oorexx/bugs/1976/?limit=25#2ef9 as a recent example. >> >> To state the obvious, when somebody spends her time detecting and documenting a bug, she's working for free for the project, she's giving to the community. >> >> For example, somebody who detects a malfunction in the test suite has to: a) know that the test suite exists; b) have the test suite installed; c) have run the test suite (which takes some time), and d) document the said malfunction. >> >> All of this requires a non-inconsiderable skill set. "Invalid" ---says Google, following Oxford--- means "not legally recognized because it contravenes a regulation or law" (as a noun, it means "a person made weak or disabled by illness or injury"). >> >> To summarize, we have a certain user, let's call her A. A has a considerable skillset. A has donated her free time and resources to the community to report what she considers to be a bug. This bug happens to refer to the test suite. Then A is told that her contribution is not legally recognized "because it contravenes a regulation or law". >> >> To me, this looks like a fantastic recipe to alienate A from the community. Specially when, as far as I know, there is no established protocol to report bugs in the test suite. >> >> Words are not meaningless identifiers. They are important, because they happen to have meanings. Meanings are dangerous: they can please and hurt, they can bind and unbind. When used wrongly, they can alienate very valuable people. People we need, because we are not precisely a huge community. >> >> My impression is that new, different names should be chosen, with some urgency. Names that do not have these ugly connotations: "Invalid", for example, is a toxic word. And the work that somebody has done for the community should always be acknowledged and appreciated. When I work on a project, the results R of my work may be wrong, but the fact F that I have worked can never be wrong. "Invalid" might apply to R, but never to F. One has to be careful. >> >> Josep Maria >> >> Missatge de ooRexx <oo...@jo... <mailto:oo...@jo...>> del dia dt., 17 de set. 2024 a les 23:03: >>> Hi Joseph Maria, >>> >>> If the reason for the behavior emanates from a change to the code it is a bug and should be reported in the bug tracker, as you did. >>> >>> Bugs in the test cases are not considered bugs and will be closed as “invalid” by the developers, only bugs in the interpreter are considered bugs. Hence “Feature”. One can report them to this list if the developers did not already spot them. >>> >>> Hälsningar/Regards/Grüsse, >>> ooRexx >>> oo...@jo... <mailto:oo...@jo...>_______________________________________________ >> Oorexx-devel mailing list >> Oor...@li... >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel |
From: P.O. J. <oo...@jo...> - 2024-09-18 13:41:55
|
Hi again Josep Maria, I did not create the current practice, in fact I was just as upset as you and others the first time my bug report was closed as „invalid“ :-( Having learned a bit more about the release procedure I realized that there was reason for this stricter definition of „Bugs“; when preparing for the release one want to list all improvements and bugs fixed in the Interpreter/language, hence any bugs in a test case are not really relevant at that point and only create additional work. Rather than trying to tweak the wordings I would be in favor of creating a new category of „bugs“ in the bug tracker that could involve anything that is not a bug in the Interpreter itself. When I look at Sourcforge there is a category „Test Cases“ under Tickets that is sparingly used. Would it not be possible to agree to file/move all bugreuports for test cases to that category? Hälsningar/Regards/Grüsse, P.O. Jonsson oo...@jo... > Am 18.09.2024 um 10:46 schrieb Josep Maria Blasco <jos...@gm...>: > > Hi P.O., > > Well, not everybody seems to appreciate the "invalid" treatment, see https://sourceforge.net/p/oorexx/bugs/1976/?limit=25#2ef9 as a recent example. > > To state the obvious, when somebody spends her time detecting and documenting a bug, she's working for free for the project, she's giving to the community. > > For example, somebody who detects a malfunction in the test suite has to: a) know that the test suite exists; b) have the test suite installed; c) have run the test suite (which takes some time), and d) document the said malfunction. > > All of this requires a non-inconsiderable skill set. "Invalid" ---says Google, following Oxford--- means "not legally recognized because it contravenes a regulation or law" (as a noun, it means "a person made weak or disabled by illness or injury"). > > To summarize, we have a certain user, let's call her A. A has a considerable skillset. A has donated her free time and resources to the community to report what she considers to be a bug. This bug happens to refer to the test suite. Then A is told that her contribution is not legally recognized "because it contravenes a regulation or law". > > To me, this looks like a fantastic recipe to alienate A from the community. Specially when, as far as I know, there is no established protocol to report bugs in the test suite. > > Words are not meaningless identifiers. They are important, because they happen to have meanings. Meanings are dangerous: they can please and hurt, they can bind and unbind. When used wrongly, they can alienate very valuable people. People we need, because we are not precisely a huge community. > > My impression is that new, different names should be chosen, with some urgency. Names that do not have these ugly connotations: "Invalid", for example, is a toxic word. And the work that somebody has done for the community should always be acknowledged and appreciated. When I work on a project, the results R of my work may be wrong, but the fact F that I have worked can never be wrong. "Invalid" might apply to R, but never to F. One has to be careful. > > Josep Maria > > Missatge de ooRexx <oo...@jo... <mailto:oo...@jo...>> del dia dt., 17 de set. 2024 a les 23:03: >> Hi Joseph Maria, >> >> If the reason for the behavior emanates from a change to the code it is a bug and should be reported in the bug tracker, as you did. >> >> Bugs in the test cases are not considered bugs and will be closed as “invalid” by the developers, only bugs in the interpreter are considered bugs. Hence “Feature”. One can report them to this list if the developers did not already spot them. >> >> Hälsningar/Regards/Grüsse, >> ooRexx >> oo...@jo... <mailto:oo...@jo...>_______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel |
From: René J. <rvj...@xs...> - 2024-09-18 13:04:16
|
I support this point. Not from a semantic or categorical point of view (the fact that an "issue" can be categorized as "invalid" is befoisted upon us by issue tracking systems ("bugs" was earlier judged to be too judgemental)) but from the practical position that everything in the ooRexx source realm which is captured in version management repositories should be correct. The particular problem with not working test cases is that it muddles the definition of what the interpreter should do. This also holds for test cases failing on a subset of the supported platforms. I agree that the tone is important. We should all be very careful in our interactions with others - we are all members of a very small group that use and like the Rexx programming language in all its variants. So the signalling of errors in tests should be acknowledged and the tests should be fixed - even if we invent a friendly synonym of "invalid" - I think it is the intent that counts. best regards, René. > On 18 Sep 2024, at 10:46, Josep Maria Blasco <jos...@gm...> wrote: > > Hi P.O., > > Well, not everybody seems to appreciate the "invalid" treatment, see https://sourceforge.net/p/oorexx/bugs/1976/?limit=25#2ef9 as a recent example. > > To state the obvious, when somebody spends her time detecting and documenting a bug, she's working for free for the project, she's giving to the community. > > For example, somebody who detects a malfunction in the test suite has to: a) know that the test suite exists; b) have the test suite installed; c) have run the test suite (which takes some time), and d) document the said malfunction. > > All of this requires a non-inconsiderable skill set. "Invalid" ---says Google, following Oxford--- means "not legally recognized because it contravenes a regulation or law" (as a noun, it means "a person made weak or disabled by illness or injury"). > > To summarize, we have a certain user, let's call her A. A has a considerable skillset. A has donated her free time and resources to the community to report what she considers to be a bug. This bug happens to refer to the test suite. Then A is told that her contribution is not legally recognized "because it contravenes a regulation or law". > > To me, this looks like a fantastic recipe to alienate A from the community. Specially when, as far as I know, there is no established protocol to report bugs in the test suite. > > Words are not meaningless identifiers. They are important, because they happen to have meanings. Meanings are dangerous: they can please and hurt, they can bind and unbind. When used wrongly, they can alienate very valuable people. People we need, because we are not precisely a huge community. > > My impression is that new, different names should be chosen, with some urgency. Names that do not have these ugly connotations: "Invalid", for example, is a toxic word. And the work that somebody has done for the community should always be acknowledged and appreciated. When I work on a project, the results R of my work may be wrong, but the fact F that I have worked can never be wrong. "Invalid" might apply to R, but never to F. One has to be careful. > > Josep Maria > > Missatge de ooRexx <oo...@jo... <mailto:oo...@jo...>> del dia dt., 17 de set. 2024 a les 23:03: >> Hi Joseph Maria, >> >> If the reason for the behavior emanates from a change to the code it is a bug and should be reported in the bug tracker, as you did. >> >> Bugs in the test cases are not considered bugs and will be closed as “invalid” by the developers, only bugs in the interpreter are considered bugs. Hence “Feature”. One can report them to this list if the developers did not already spot them. >> >> Hälsningar/Regards/Grüsse, >> ooRexx >> oo...@jo... <mailto:oo...@jo...>_______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel |
From: Josep M. B. <jos...@gm...> - 2024-09-18 08:46:46
|
Hi P.O., Well, not everybody seems to appreciate the "invalid" treatment, see https://sourceforge.net/p/oorexx/bugs/1976/?limit=25#2ef9 as a recent example. To state the obvious, when somebody spends her time detecting and documenting a bug, she's working for free for the project, she's giving to the community. For example, somebody who detects a malfunction in the test suite has to: a) know that the test suite exists; b) have the test suite installed; c) have run the test suite (which takes some time), and d) document the said malfunction. All of this requires a non-inconsiderable skill set. "Invalid" ---says Google, following Oxford--- means "not legally recognized because it contravenes a regulation or law" (as a noun, it means "a person made weak or disabled by illness or injury"). To summarize, we have a certain user, let's call her A. A has a considerable skillset. A has donated her free time and resources to the community to report what she considers to be a bug. This bug happens to refer to the test suite. Then A is told that her contribution is not legally recognized "because it contravenes a regulation or law". To me, this looks like a fantastic recipe to alienate A from the community. Specially when, as far as I know, there is no established protocol to report bugs in the test suite. Words are not meaningless identifiers. They are important, because they happen to have meanings. Meanings are dangerous: they can please and hurt, they can bind and unbind. When used wrongly, they can alienate very valuable people. People we need, because we are not precisely a huge community. My impression is that new, different names should be chosen, with some urgency. Names that do not have these ugly connotations: "Invalid", for example, is a toxic word. And the work that somebody has done for the community should always be acknowledged and appreciated. When I work on a project, the results R of my work may be wrong, but the fact F that I have worked can never be wrong. "Invalid" might apply to R, but never to F. One has to be careful. Josep Maria Missatge de ooRexx <oo...@jo...> del dia dt., 17 de set. 2024 a les 23:03: > Hi Joseph Maria, > > If the reason for the behavior emanates from a change to the code it is a > bug and should be reported in the bug tracker, as you did. > > Bugs in the test cases are not considered bugs and will be closed as > “invalid” by the developers, only bugs in the interpreter are considered > bugs. Hence “Feature”. One can report them to this list if the developers > did not already spot them. > > Hälsningar/Regards/Grüsse, > ooRexx > oo...@jo... > |
From: ooRexx <oo...@jo...> - 2024-09-17 21:02:13
|
Hi Joseph Maria, If the reason for the behavior emanates from a change to the code it is a bug and should be reported in the bug tracker, as you did. Bugs in the test cases are not considered bugs and will be closed as “invalid” by the developers, only bugs in the interpreter are considered bugs. Hence “Feature”. One can report them to this list if the developers did not already spot them. Hälsningar/Regards/Grüsse, ooRexx oo...@jo... > Am 17.09.2024 um 22:24 schrieb Josep Maria Blasco <jos...@gm...>: > > This was reported on 2024-09-08 here: https://sourceforge.net/p/oorexx/bugs/1945/#cb5f > > The latest fixes are too aggressive regarding what's considered to be a label "inside an IF" (I don't think that labels inside block instructions should be banned, but that's another question). They detect labels that they shouldn't be detecting. In particular, the one you are referring to is at line 499 of NUMERIC.testGroup. The previous line is an IF instruction, and the interpreter erroneously detects the next label ("for:") as if it was part of the IF instruction. > > Josep Maria > > Missatge de ooRexx <oo...@jo... <mailto:oo...@jo...>> del dia dt., 17 de set. 2024 a les 22:10: >> This error is present in most if not all platform tests: >> >> Interpreter: REXX-ooRexx_5.1.0(MT)_64-bit 6.05 8 Sep 2024 >> OS Name: LINUX >> SysVersion: Linux 5.14.0-503.el9.x86_64 >> >> Tests ran: 23945 >> Assertions: 355393 >> Failures: 0 >> Errors: 1 >> >> [Framework exception] 20240908 19:11:40.367276 >> Type: Trap Severity: Fatal >> File: .../ooRexx/base/keyword/NUMERIC.testGroup >> Line: 2105 >> Initial call of test container failed >> Condition: SYNTAX >> Labels are not allowed within an IF block; found "FOR". >> File: .../ooRexx/base/keyword/NUMERIC.testGroup >> Line: 499 >> 499 *-* for: Return form() >> 2105 *-* call (file) self~testTypes >> 2053 *-* container = self~getContainer(fileName) >> 81 *-* containers = finder~seek(testResult) >> 79 *-* retCode = 'worker.rex'(arguments) >> >> File search: 00:00:01.299699 >> Suite construction: 00:00:01.266240 >> Test execution: 00:07:20.532384 >> Total time: 00:07:23.098937 >> >> Build step 'Execute shell' marked build as failure >> Finished: FAILURE >> >> It might be the result of this commit >> >> >> Revision: 12905 >> Changes >> >> fix code, update rexref, add LABEL test group for [bugs:#1945] No labels should be allowed within DO/LOOP, IF, SELECT (detail) >> by erich_st >> fix SIGNAL test group (detail) >> by erich_st >> >> >> Can anyone that made a commit recently please have a look? >> >> Hälsningar/Regards/Grüsse, >> ooRexx >> oo...@jo... <mailto:oo...@jo...> >> >> >> >> _______________________________________________ >> Oorexx-devel mailing list >> Oor...@li... <mailto:Oor...@li...> >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel |
From: Josep M. B. <jos...@gm...> - 2024-09-17 20:24:53
|
This was reported on 2024-09-08 here: https://sourceforge.net/p/oorexx/bugs/1945/#cb5f The latest fixes are too aggressive regarding what's considered to be a label "inside an IF" (I don't think that labels inside block instructions should be banned, but that's another question). They detect labels that they shouldn't be detecting. In particular, the one you are referring to is at line 499 of NUMERIC.testGroup. The previous line is an IF instruction, and the interpreter erroneously detects the next label ("for:") as if it was part of the IF instruction. Josep Maria Missatge de ooRexx <oo...@jo...> del dia dt., 17 de set. 2024 a les 22:10: > This error is present in most if not all platform tests: > > Interpreter: REXX-ooRexx_5.1.0(MT)_64-bit 6.05 8 Sep 2024 > OS Name: LINUX > SysVersion: Linux 5.14.0-503.el9.x86_64 > > Tests ran: 23945 > Assertions: 355393 > Failures: 0 > Errors: 1 > > [Framework exception] 20240908 19:11:40.367276 > Type: Trap Severity: Fatal > File: .../ooRexx/base/keyword/NUMERIC.testGroup > Line: 2105 > Initial call of test container failed > Condition: SYNTAX > Labels are not allowed within an IF block; found "FOR". > File: .../ooRexx/base/keyword/NUMERIC.testGroup > Line: 499 > 499 *-* for: Return form() > 2105 *-* call (file) self~testTypes > 2053 *-* container = self~getContainer(fileName) > 81 *-* containers = finder~seek(testResult) > 79 *-* retCode = 'worker.rex'(arguments) > > File search: 00:00:01.299699 > Suite construction: 00:00:01.266240 > Test execution: 00:07:20.532384 > Total time: 00:07:23.098937 > > Build step 'Execute shell' marked build as failure > Finished: FAILURE > > It might be the result of this commit > > > Revision: 12905 > Changes > > fix code, update rexref, add LABEL test group for [bugs:#1945] No > labels should be allowed within DO/LOOP, IF, SELECT (detail) > by erich_st > fix SIGNAL test group (detail) > by erich_st > > > Can anyone that made a commit recently please have a look? > > Hälsningar/Regards/Grüsse, > ooRexx > oo...@jo... > > > > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > |
From: ooRexx <oo...@jo...> - 2024-09-17 20:10:13
|
This error is present in most if not all platform tests: Interpreter: REXX-ooRexx_5.1.0(MT)_64-bit 6.05 8 Sep 2024 OS Name: LINUX SysVersion: Linux 5.14.0-503.el9.x86_64 Tests ran: 23945 Assertions: 355393 Failures: 0 Errors: 1 [Framework exception] 20240908 19:11:40.367276 Type: Trap Severity: Fatal File: .../ooRexx/base/keyword/NUMERIC.testGroup Line: 2105 Initial call of test container failed Condition: SYNTAX Labels are not allowed within an IF block; found "FOR". File: .../ooRexx/base/keyword/NUMERIC.testGroup Line: 499 499 *-* for: Return form() 2105 *-* call (file) self~testTypes 2053 *-* container = self~getContainer(fileName) 81 *-* containers = finder~seek(testResult) 79 *-* retCode = 'worker.rex'(arguments) File search: 00:00:01.299699 Suite construction: 00:00:01.266240 Test execution: 00:07:20.532384 Total time: 00:07:23.098937 Build step 'Execute shell' marked build as failure Finished: FAILURE It might be the result of this commit Revision: 12905 Changes fix code, update rexref, add LABEL test group for [bugs:#1945] No labels should be allowed within DO/LOOP, IF, SELECT (detail) by erich_st fix SIGNAL test group (detail) by erich_st Can anyone that made a commit recently please have a look? Hälsningar/Regards/Grüsse, ooRexx oo...@jo... |
From: ooRexx <oo...@jo...> - 2024-09-16 15:31:26
|
Hi René, To late for a look, as I explained in the reply to Rony. I have saved a zipped copy of the docs built from the sandbox test and from the current beta, you can download and compare them from this dropbox folder https://www.dropbox.com/sh/egbap7tmx16znht/AAAdeDVXyguemm7Nat3vXOfVa?dl=0 JenkinsShare dropbox.com In the subfolder DocumentationTest. I will be AFK mostly for the coming 2 months but will monitor m mail and keep an eye on Jenkins from remote. Hälsningar/Regards/Grüsse, ooRexx oo...@jo... > Am 16.09.2024 um 13:02 schrieb René Jansen <rvj...@xs...>: > > Hi P.O., > > your work is greatly appreciated even if we are not at home or swamped with other emails - or just work that creeps into our private lives. Will have a look. > > best regards, > > René. > >> On 15 Sep 2024, at 18:11, P.O. Jonsson <oo...@jo...> wrote: >> >> From the non-response to this request I take it that there is no interest in a release procedure and even less a future release? If there is no interest there is no point in me trying to come up with a better release procedure than the last time :-( >> >> I will remove the staged folder tomorrow at the latest? >> >> Hälsningar/Regards/Grüsse, >> P.O. Jonsson >> oo...@jo... >> >> >> >> >>> Am 13.09.2024 um 16:05 schrieb ooRexx <oo...@jo...>: >>> >>> Dear All, >>> >>> In preparation for the next release I have made a “dry run” of the documentation build for a fictive 5.1.0, building from an alternate svn path in the sandbox mimicking a release. >>> >>> On sourceforge you can find a staged folder (i.e. hidden folder unless you are logged in) with the documentation as built with this setup. >>> >>> Can you please have a look and confirm that everything looks alright, with all revisions and dates etc as we would expect them to be for a release? Is there anything missing for a release (in the doc folder)? >>> >>> The documentation needs to be in place before we build any installers so I want to have confirmation before I go on and test a dry run of building the installers for the next release. Once that works the release will be less demanding, on me at least :-) >>> >>> I will restore everything to normal build within a few days, >>> >>> Hälsningar/Regards/Grüsse, >>> ooRexx >>> oo...@jo... >>> >>> >>> >>> _______________________________________________ >>> Oorexx-devel mailing list >>> Oor...@li... >>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> >> _______________________________________________ >> Oorexx-devel mailing list >> Oor...@li... >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel |
From: ooRexx <oo...@jo...> - 2024-09-16 15:24:12
|
> Am 16.09.2024 um 12:39 schrieb Rony G. Flatscher <Ron...@wu...>: > > Hi P.O., > > On 15.09.2024 18:11, P.O. Jonsson wrote: >> From the non-response to this request I take it that there is no interest in a release procedure and even less a future release? If there is no interest there is no point in me trying to come up with a better release procedure than the last time :-( > > well, I can understand your frustration in that no one communicates, let alone gives any feedback. > > OTOH you may be a little bit too impatient :) given that people may be on vacation (like myself) or being consumed by other non-ooRexx tasks to an extent that hinders them to download and check out the results of your hard work, which I think is *great*, seriously! > Well, I had set up a staged folder on sourceforge for the test, and I had to delete it today since it would otherwise become visible to the public after 3 days, hence the frustration, no-one had looked at it before it had to be deleted :-(. > It is nice to now see the production date and revision of the pdf files and also when the last change (together with the revision) the individual pdf books took place, so thank you very much for these improvements, kudos! > I am not responsible for those amendments, I think that is Gil’s work (and brilliant it is), all I have done is to make sure that the documentation build job on Jenkins can be switched to be rebuilt completely and automatically at the time of a release, that MUST be ready before we start to build the artifacts. But I need to know if the layout is ok for a release or if I need to do some further modifications. For most documents it will look like Edition Date.Of.The.Release (last revised on 2024-09-08 with r12905) But for oodialog et al this is not the case. Also for some smaller docs like oosqlite.pdf the layout is different. Maybe not a big deal. For all books we need to revise the list of contributors in due time before a release as well. > Looking for your work to be merged to trunk! It is already in trunk > > Best regards > > ---rony > > > > > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel |
From: René J. <rvj...@xs...> - 2024-09-16 11:02:30
|
Hi P.O., your work is greatly appreciated even if we are not at home or swamped with other emails - or just work that creeps into our private lives. Will have a look. best regards, René. > On 15 Sep 2024, at 18:11, P.O. Jonsson <oo...@jo...> wrote: > > From the non-response to this request I take it that there is no interest in a release procedure and even less a future release? If there is no interest there is no point in me trying to come up with a better release procedure than the last time :-( > > I will remove the staged folder tomorrow at the latest? > > Hälsningar/Regards/Grüsse, > P.O. Jonsson > oo...@jo... > > > > >> Am 13.09.2024 um 16:05 schrieb ooRexx <oo...@jo...>: >> >> Dear All, >> >> In preparation for the next release I have made a “dry run” of the documentation build for a fictive 5.1.0, building from an alternate svn path in the sandbox mimicking a release. >> >> On sourceforge you can find a staged folder (i.e. hidden folder unless you are logged in) with the documentation as built with this setup. >> >> Can you please have a look and confirm that everything looks alright, with all revisions and dates etc as we would expect them to be for a release? Is there anything missing for a release (in the doc folder)? >> >> The documentation needs to be in place before we build any installers so I want to have confirmation before I go on and test a dry run of building the installers for the next release. Once that works the release will be less demanding, on me at least :-) >> >> I will restore everything to normal build within a few days, >> >> Hälsningar/Regards/Grüsse, >> ooRexx >> oo...@jo... >> >> >> >> _______________________________________________ >> Oorexx-devel mailing list >> Oor...@li... >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel |
From: Rony G. F. <Ron...@wu...> - 2024-09-16 10:39:35
|
Hi P.O., On 15.09.2024 18:11, P.O. Jonsson wrote: > From the non-response to this request I take it that there is no interest in a release procedure > and even less a future release? If there is no interest there is no point in me trying to come up > with a better release procedure than the last time :-( well, I can understand your frustration in that no one communicates, let alone gives any feedback. OTOH you may be a little bit too impatient :) given that people may be on vacation (like myself) or being consumed by other non-ooRexx tasks to an extent that hinders them to download and check out the results of your hard work, which I think is *great*, seriously! It is nice to now see the production date and revision of the pdf files and also when the last change (together with the revision) the individual pdf books took place, so thank you very much for these improvements, kudos! Looking for your work to be merged to trunk! Best regards ---rony |
From: P.O. J. <oo...@jo...> - 2024-09-15 16:12:05
|
From the non-response to this request I take it that there is no interest in a release procedure and even less a future release? If there is no interest there is no point in me trying to come up with a better release procedure than the last time :-( I will remove the staged folder tomorrow at the latest? Hälsningar/Regards/Grüsse, P.O. Jonsson oo...@jo... > Am 13.09.2024 um 16:05 schrieb ooRexx <oo...@jo...>: > > Dear All, > > In preparation for the next release I have made a “dry run” of the documentation build for a fictive 5.1.0, building from an alternate svn path in the sandbox mimicking a release. > > On sourceforge you can find a staged folder (i.e. hidden folder unless you are logged in) with the documentation as built with this setup. > > Can you please have a look and confirm that everything looks alright, with all revisions and dates etc as we would expect them to be for a release? Is there anything missing for a release (in the doc folder)? > > The documentation needs to be in place before we build any installers so I want to have confirmation before I go on and test a dry run of building the installers for the next release. Once that works the release will be less demanding, on me at least :-) > > I will restore everything to normal build within a few days, > > Hälsningar/Regards/Grüsse, > ooRexx > oo...@jo... > > > > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel |
From: ooRexx <oo...@jo...> - 2024-09-13 14:06:27
|
Dear All, In preparation for the next release I have made a “dry run” of the documentation build for a fictive 5.1.0, building from an alternate svn path in the sandbox mimicking a release. On sourceforge you can find a staged folder (i.e. hidden folder unless you are logged in) with the documentation as built with this setup. Can you please have a look and confirm that everything looks alright, with all revisions and dates etc as we would expect them to be for a release? Is there anything missing for a release (in the doc folder)? The documentation needs to be in place before we build any installers so I want to have confirmation before I go on and test a dry run of building the installers for the next release. Once that works the release will be less demanding, on me at least :-) I will restore everything to normal build within a few days, Hälsningar/Regards/Grüsse, ooRexx oo...@jo... |
From: Mike C. <mf...@sp...> - 2024-09-12 12:02:54
|
Another option (probably too radical a change) would be to switch to the NetRexx rule: a symbol that has been used as a variable cannot be a keyword. The advantage of this is that keywords added to the language in the future will and can not break existing programs. Mike |
From: Josep M. B. <jos...@gm...> - 2024-09-12 06:16:54
|
I forgot to add: another possibility which is also easy to remember and explain is the following: Definition: nesting level: the number of opened unpaired "(" and "[" when examining thee current token. Rule: A simple symbol will be recognized as an expression terminator if and only if it is at nesting level zero and it is found after a blank or abuttal concatenation operator. This option would give maximal freedom to the programmer. My only worry is that it, in some cases, it might make error detection more complicated. Josep Maria Missatge de Josep Maria Blasco <jos...@gm...> del dia dc., 11 de set. 2024 a les 18:07: > The latest fixes have added a new chapter to rexxref, chapter 16 "Reserved > keywords", which details when a simple symbol will be recognized as an > expression terminator. I think this is a very welcome addition to the > reference manual. > > Allow me to center the discussion around an example: the DO instruction. > > TRL2 says > > The sub-keywords WHILE and UNTIL are reserved within a DO instruction, in > that they cannot be used as symbols in any of the expressions. Similarly, > TO, BY, and FOR cannot be used in *expri*, *exprt*, *exprb*, or *exprf*. > FOREVER is also reserved, but only if it immediately follows the keyword DO. > > > Regina follows TRL2. The version of Object Rexx distributed with OS/2, > "OBJREXX 6.00 18 May 1999", also has the same paragraph. > > ooRexx is much more flexible. It takes the "no reserved words" philosophy > of Rexx (which it inherited from PL/I) to a new level, because it allows to > use a symbol that would usually be considered to be a reserved word as a > normal variable if it is found between parenthesis (or brackets, but this > was not documented until the very recent addition of chapter 16). So, for > example, after to = 3, > > Do i = 1 To to; Say i; End > > > produces a syntax error, while > > Do i = 1 To (to); Say i; End > > > works perfectly. > > One day, I realized that > > Do i = 1 To >to ; Say i; End > > > was working. I reported it as a bug: the documentation said that reserved > symbols had to be between parenthesis to be usable as normal variables. > Rick pointed that a construction like > > Do i = 1 To a~to ; Say i; End > > > produced an error, and that both cases should work in the same way. > > Lately, there have been some fixes that modify the language so that these > constructions are both accepted. This is documented in the new chapter 16: > > While typically these reserved keywords act as expression terminators, > using them within terms like message terms or Variable Reference terms, or > with parentheses around or within the expression, can prevent these > keywords from terminating the expression. > > > In the discussion of a new bug, I discovered that namespace-qualified > symbols are also accepted, even if they are reserved subkeywords. So, for > example > > namespace:to > > > would not be recognized as a reserved subkeyword. This is still not > documented. > > I understand and appreciate the general intention of these modifications: > they are an attempt to improve the language by making it as independent of > reserved keywords as possible. > > But at the same time, I am afraid that this goes against the idea of > keeping the language small and simple. > > Allow me to elaborate a little more. If the namespace feature is > documented, the mentioned paragraph should tell the user that a reserved > subkeyword can be used as a normal symbol when 1) it is between > parentheses; 2) when it is between brackets (I would strongly suggest > making this possibility explicit); 3) when it is used as a Variable > Reference term; 4) when it is the message name of a message term; and now > 5) when it is a namespace-qualified symbol. > > To me, it seems that this is getting complicated, very complicated, and > quite difficult to remember. With a suitable preparsing pass, a parser > could also accept subkeywords-as-variables as the right operands of most > binary operators (I checked it), but what would we gain from it? > > Very little in terms of making our own life easier. And we would be > getting a language that would be more and more complicated. > > I would suggest reverting things to something which can be effortlessly > explained and understood: a reserved subkeyword will not be recognized as > an expression terminator *if and only if it is found between parenthesis > or brackets*. And nothing more. No more special cases. > > When things become too complicated, I feel forced to re-read the manual > continuously. It's a nuisance, not something which makes my programming > life easier. > > I would prefer a syntax which is simple and easy to remember. > > Josep Maria > > > > |
From: Josep M. B. <jos...@gm...> - 2024-09-11 16:08:06
|
The latest fixes have added a new chapter to rexxref, chapter 16 "Reserved keywords", which details when a simple symbol will be recognized as an expression terminator. I think this is a very welcome addition to the reference manual. Allow me to center the discussion around an example: the DO instruction. TRL2 says The sub-keywords WHILE and UNTIL are reserved within a DO instruction, in that they cannot be used as symbols in any of the expressions. Similarly, TO, BY, and FOR cannot be used in *expri*, *exprt*, *exprb*, or *exprf*. FOREVER is also reserved, but only if it immediately follows the keyword DO. Regina follows TRL2. The version of Object Rexx distributed with OS/2, "OBJREXX 6.00 18 May 1999", also has the same paragraph. ooRexx is much more flexible. It takes the "no reserved words" philosophy of Rexx (which it inherited from PL/I) to a new level, because it allows to use a symbol that would usually be considered to be a reserved word as a normal variable if it is found between parenthesis (or brackets, but this was not documented until the very recent addition of chapter 16). So, for example, after to = 3, Do i = 1 To to; Say i; End produces a syntax error, while Do i = 1 To (to); Say i; End works perfectly. One day, I realized that Do i = 1 To >to ; Say i; End was working. I reported it as a bug: the documentation said that reserved symbols had to be between parenthesis to be usable as normal variables. Rick pointed that a construction like Do i = 1 To a~to ; Say i; End produced an error, and that both cases should work in the same way. Lately, there have been some fixes that modify the language so that these constructions are both accepted. This is documented in the new chapter 16: While typically these reserved keywords act as expression terminators, using them within terms like message terms or Variable Reference terms, or with parentheses around or within the expression, can prevent these keywords from terminating the expression. In the discussion of a new bug, I discovered that namespace-qualified symbols are also accepted, even if they are reserved subkeywords. So, for example namespace:to would not be recognized as a reserved subkeyword. This is still not documented. I understand and appreciate the general intention of these modifications: they are an attempt to improve the language by making it as independent of reserved keywords as possible. But at the same time, I am afraid that this goes against the idea of keeping the language small and simple. Allow me to elaborate a little more. If the namespace feature is documented, the mentioned paragraph should tell the user that a reserved subkeyword can be used as a normal symbol when 1) it is between parentheses; 2) when it is between brackets (I would strongly suggest making this possibility explicit); 3) when it is used as a Variable Reference term; 4) when it is the message name of a message term; and now 5) when it is a namespace-qualified symbol. To me, it seems that this is getting complicated, very complicated, and quite difficult to remember. With a suitable preparsing pass, a parser could also accept subkeywords-as-variables as the right operands of most binary operators (I checked it), but what would we gain from it? Very little in terms of making our own life easier. And we would be getting a language that would be more and more complicated. I would suggest reverting things to something which can be effortlessly explained and understood: a reserved subkeyword will not be recognized as an expression terminator *if and only if it is found between parenthesis or brackets*. And nothing more. No more special cases. When things become too complicated, I feel forced to re-read the manual continuously. It's a nuisance, not something which makes my programming life easier. I would prefer a syntax which is simple and easy to remember. Josep Maria |
From: Michael L. <ml...@lu...> - 2024-09-09 13:28:52
|
Greetings ooRexx'ers, I saw a reply directly from Rony first, and replied to it.... Now discover he also answered this list: Rony G. Flatscher wrote: > On 07.09.2024 17:22, Michael Lueck wrote: >> >> The run-time environment of methods created with self~SetMethod() seem funky. > > Sorry, need to run, however, have you consulted rexxref.pdf's "new" method on the Method class, namely the optional "context" argument? Would that help? I appear to have caused confusion by referring back to the year 2008, and at the time the client was running on IBM ORexx 2.1.1 when we were developing the Persistence class wrapper for the ancient IBM DB2 Rexx driver. I no longer have access to that software stack.... sadly long decommissioned. I will work up a test program on more current ooRexx on Linux.... $ rexx -v Open Object Rexx Version 5.0.0 r12583 Build date: Dec 23 2022 Addressing mode: 64 I am intrigued to see if the "context" argument was in the "new" method of the class already in v2.1.1, that would have solved it back then.... ;-) I am thankful, -- Michael Lueck Lueck Data Systems http://www.lueckdatasystems.com/ |
From: Rony G. F. <Ron...@wu...> - 2024-09-09 13:26:34
|
On 09.09.2024 11:43, Josep Maria Blasco wrote: > Missatge de Rick McGuire <obj...@gm...> del dia dc., 4 de set. 2024 a les 18:14: > > > On Wed, Sep 4, 2024 at 12:07 PM Erich Steinböck <eri...@gm...> wrote: > > Ok, thanks. > > As, except for tracing, there seems to be little value in labels that cannot be branched > to, should we completely disallow them already in the translation phase, like it is done > for labels within INTERPRET? > > One of the open bug reports claims we should allow `label: THEN` within an IF (it's the > ANSI argument) and I wonder whether we really want a fix with so lottle vealue. > > > I think I'd be in favor of not allowing them at those locations. I agree there is very little > value in having them there, and the control structure of how instructions are linked together > probably would not accommodate that well. > > > (Resending from my Gmail address) > > My impression is that several different questions are being conflated here. Let me elaborate. > > It would be nice if others would give their opinions, too. The changes to the language are important. > > I will work modulo null clauses (as they are completely ignored, I will do so myself). Labels can > precede other labels and different clauses, including the implicit exit instruction assumed at the > end of every code body > > e.g., you can place a label at the end of a program (or prolog), of a routine or of a method > body, > > > but excluding directives, i.e., you cannot place a label immediately before a directive, because > of the way the parser works: LABEL: ::DIRECTIVE would be parsed as {LABEL ::} {:DIRECTIVE}, and > then we would have a directive start marker, "::", followed by a single colon, ":", which is > obviously invalid. > > A label before a directive, anyway, would not make much sense: a directive is non-executable, > while a label is in principle always traceable, and may additionally also be SIGNALable, CALLable, > etc. > > Even if all clauses can, in principle, from a Classic Rexx perspective, be labelled, not all > labels make the same sense. > > * *Group 1)* Some labels are indisputable. They are attached to first-level instructions (i.e., > instructions which are not inside a block instruction), and can therefore be the targets of > CALL, SIGNAL, etc. (unless they are duplicates). > * *Group 4)* In the other extreme, labels before WHEN, THEN, ELSE, OTHERWISE, or the END of a > SELECT block do not seem to make much sense. There is no possible semantics for a SIGNAL or a > CALL to one of these labels which appears to be meaningful (unless we ignore a THEN clause and > branch instead to the attached instruction, for example, but this is to evade the question). > These clauses, in some sense, can be thought of as non-executable, pure syntax sugar (not that > they have to be in the current interpreter, but think of an optimizing compiler). Since labels > identifying them cannot be used in any significant way, there are strong arguments in favour > of forbidding them altogether. > * *Group 3)* Labels before LEAVE, ITERATE and END for DO/LOOP blocks are only slightly less > problematic. The difference with the above is that LEAVE, ITERATE and END are actually > executable instructions or clauses (and END, if we allow it to mean "jump to the start of the > loop"). A branch to one of these would produce an immediate error, but they should be able to > be traced. This makes a strong point in favour of forbidding static SIGNAL and CALLs to these > labels at translation time, but allowing them to be used for tracing. > * *Group 2)* Other labels inside block instructions are similarly problematic. Being able to > SIGNAL one of these labels made sense in the times of TRL2 (and for sure it opens several > interesting avenues for programming), but it is not allowed by ANSI. If one wants to assign a > sane semantics to such a branch, one has to stipulate that the program should "jump out" of > the block instruction before encountering a conflicting instruction (like LEAVE, ITERATE or > END). Implementing such a semantics makes writing compilers much more difficult and/or > inefficient. > > ANSI defines labels inside block instructions as /trace-only/ (6.4.2), and disallows SIGNALing or > CALLing them (errors 16.2 and 16.3). > > Currently, Erich is writing a set of patches that completely _disallow /all labels/_ inside block > instructions, and (in the more recent patch) also labels attached to instructions which should not > be jumped to, like EXPOSE. You can follow the development of these patches here: > https://sourceforge.net/p/oorexx/bugs/1945/ > > Some users complained that this change would make the claimed compatibility with classic Rexx > extremely problematic. > > I tend to agree. > > One thing is to _disallow /branches/_ into labels inside block instructions (or EXPOSE, etc), > effectively making these labels trace-only, to use the ANSI nomenclature, and a completely > different one is to _disallow /the labels themselves/_. > > Disallowing the label themselves *breaks TRACE L semantics, and poses a big compatibility > problem*. To me, it appears as a not very good idea. > > On the other hand, disallowing labels in places where they do not make any sense altogether (i.e., > group 4 labels) seems a sensible approach. The TRACE effect can be achieved by attaching a label > to the subordinate instruction, in the case of WHEN, THEN, ELSE, OTHERWISE, or just after the > instruction, in the case of SELECT. > > Labels inside block instructions or non-branchable instructions (like EXPOSE or USE LOCAL) should > be allowed, but they should be made trace-only. > > To summarize, my take is the following: > > * Group 1: Allow labels, SIGNAL and CALL. > * Groups 2 and 3: Allow labels, but make them trace only. Static SIGNAL and CALL instructions > should be rejected at translation time. > * Group 4: Labels should not be allowed (and thus SIGNAL or CALL become impossible). > > What's your opinion? Well, I have been following these items, issues and fixes, and have been fascinated by your and Erich's hard and close work! Kudos to both! Ad labels in selects and the like: I learned that "trace l" adds utility to it (would have never thought about that). With regards to compatibility: if it is to be expected that code exists that takes advantage of these ANSI definitions then it would be desirable that ooRexx would be able to execute such code (thereby making that feature available to ooRexx as well, now that we know :) ). Just my 2 cents. ---rony |
From: Josep M. B. <jos...@gm...> - 2024-09-09 09:43:41
|
Missatge de Rick McGuire <obj...@gm...> del dia dc., 4 de set. 2024 a les 18:14: > > On Wed, Sep 4, 2024 at 12:07 PM Erich Steinböck < > eri...@gm...> wrote: > >> Ok, thanks. >> >> As, except for tracing, there seems to be little value in labels that >> cannot be branched to, should we completely disallow them already in the >> translation phase, like it is done for labels within INTERPRET? >> >> One of the open bug reports claims we should allow `label: THEN` within >> an IF (it's the ANSI argument) and I wonder whether we really want a fix >> with so lottle vealue. >> > > I think I'd be in favor of not allowing them at those locations. I agree > there is very little value in having them there, and the control structure > of how instructions are linked together probably would not accommodate that > well. > (Resending from my Gmail address) My impression is that several different questions are being conflated here. Let me elaborate. It would be nice if others would give their opinions, too. The changes to the language are important. I will work modulo null clauses (as they are completely ignored, I will do so myself). Labels can precede other labels and different clauses, including the implicit exit instruction assumed at the end of every code body e.g., you can place a label at the end of a program (or prolog), of a routine or of a method body, but excluding directives, i.e., you cannot place a label immediately before a directive, because of the way the parser works: LABEL: ::DIRECTIVE would be parsed as {LABEL ::} {:DIRECTIVE}, and then we would have a directive start marker, "::", followed by a single colon, ":", which is obviously invalid. A label before a directive, anyway, would not make much sense: a directive is non-executable, while a label is in principle always traceable, and may additionally also be SIGNALable, CALLable, etc. Even if all clauses can, in principle, from a Classic Rexx perspective, be labelled, not all labels make the same sense. - *Group 1)* Some labels are indisputable. They are attached to first-level instructions (i.e., instructions which are not inside a block instruction), and can therefore be the targets of CALL, SIGNAL, etc. (unless they are duplicates). - *Group 4)* In the other extreme, labels before WHEN, THEN, ELSE, OTHERWISE, or the END of a SELECT block do not seem to make much sense. There is no possible semantics for a SIGNAL or a CALL to one of these labels which appears to be meaningful (unless we ignore a THEN clause and branch instead to the attached instruction, for example, but this is to evade the question). These clauses, in some sense, can be thought of as non-executable, pure syntax sugar (not that they have to be in the current interpreter, but think of an optimizing compiler). Since labels identifying them cannot be used in any significant way, there are strong arguments in favour of forbidding them altogether. - *Group 3)* Labels before LEAVE, ITERATE and END for DO/LOOP blocks are only slightly less problematic. The difference with the above is that LEAVE, ITERATE and END are actually executable instructions or clauses (and END, if we allow it to mean "jump to the start of the loop"). A branch to one of these would produce an immediate error, but they should be able to be traced. This makes a strong point in favour of forbidding static SIGNAL and CALLs to these labels at translation time, but allowing them to be used for tracing. - *Group 2)* Other labels inside block instructions are similarly problematic. Being able to SIGNAL one of these labels made sense in the times of TRL2 (and for sure it opens several interesting avenues for programming), but it is not allowed by ANSI. If one wants to assign a sane semantics to such a branch, one has to stipulate that the program should "jump out" of the block instruction before encountering a conflicting instruction (like LEAVE, ITERATE or END). Implementing such a semantics makes writing compilers much more difficult and/or inefficient. ANSI defines labels inside block instructions as *trace-only* (6.4.2), and disallows SIGNALing or CALLing them (errors 16.2 and 16.3). Currently, Erich is writing a set of patches that completely *disallow all labels* inside block instructions, and (in the more recent patch) also labels attached to instructions which should not be jumped to, like EXPOSE. You can follow the development of these patches here: https://sourceforge.net/p/oorexx/bugs/1945/ Some users complained that this change would make the claimed compatibility with classic Rexx extremely problematic. I tend to agree. One thing is to *disallow branches* into labels inside block instructions (or EXPOSE, etc), effectively making these labels trace-only, to use the ANSI nomenclature, and a completely different one is to *disallow the labels themselves*. Disallowing the label themselves *breaks TRACE L semantics, and poses a big compatibility problem*. To me, it appears as a not very good idea. On the other hand, disallowing labels in places where they do not make any sense altogether (i.e., group 4 labels) seems a sensible approach. The TRACE effect can be achieved by attaching a label to the subordinate instruction, in the case of WHEN, THEN, ELSE, OTHERWISE, or just after the instruction, in the case of SELECT. Labels inside block instructions or non-branchable instructions (like EXPOSE or USE LOCAL) should be allowed, but they should be made trace-only. To summarize, my take is the following: - Group 1: Allow labels, SIGNAL and CALL. - Groups 2 and 3: Allow labels, but make them trace only. Static SIGNAL and CALL instructions should be rejected at translation time. - Group 4: Labels should not be allowed (and thus SIGNAL or CALL become impossible). What's your opinion? Josep Maria |
From: Rony G. F. <Ron...@wu...> - 2024-09-07 15:25:48
|
On 07.09.2024 17:22, Michael Lueck wrote: > Greetings Rony, > > Rony G. Flatscher wrote: >> What would be a "dynamic method" for you and what would you expect of it and why? > > > > Starting with your last question first.... > > > A Persistence framework builds run-time code dynamically to match up with physical database table > schema. We make use of calls to self~SetMethod() to build out the needed class object code at > run-time > matching up with the table schema. > > >> What do you assess to be an "odd environment" (and why would it be odd for you?) "which >> dynamically created methods execute their code in" ? >> >> Can you explain? >> >> What would be a "dynamic method" for you and what would you expect of it and why? > > > Calling from the main class code into these dymaically created methods lands execution in some > sort of a jailed environment. Code there does not have access to objects visible within the real > class > object, nor access to loaded Rexx DLL's. > > However, we found if we call back to another static method within the class (meant only to be > called by these dynamically crated methods) then the correct environment visibility is restored. > > So we ended up doing just the minimal code in those methods defined with self~SetMethod() and then > from there call to one of the special methods intended only to be called from a self~SetMethod() > created section of code. > > The run-time environment of methods created with self~SetMethod() seem funky. Sorry, need to run, however, have you consulted rexxref.pdf's "new" method on the Method class, namely the optional "context" argument? Would that help? ---rony |
From: Michael L. <ml...@lu...> - 2024-09-07 15:23:02
|
Greetings Rony, Rony G. Flatscher wrote: > What would be a "dynamic method" for you and what would you expect of it and why? Starting with your last question first.... A Persistence framework builds run-time code dynamically to match up with physical database table schema. We make use of calls to self~SetMethod() to build out the needed class object code at run-time matching up with the table schema. > What do you assess to be an "odd environment" (and why would it be odd for you?) "which dynamically created methods execute their code in" ? > > Can you explain? > > What would be a "dynamic method" for you and what would you expect of it and why? Calling from the main class code into these dymaically created methods lands execution in some sort of a jailed environment. Code there does not have access to objects visible within the real class object, nor access to loaded Rexx DLL's. However, we found if we call back to another static method within the class (meant only to be called by these dynamically crated methods) then the correct environment visibility is restored. So we ended up doing just the minimal code in those methods defined with self~SetMethod() and then from there call to one of the special methods intended only to be called from a self~SetMethod() created section of code. The run-time environment of methods created with self~SetMethod() seem funky. I am thankful, -- Michael Lueck Lueck Data Systems http://www.lueckdatasystems.com/ |