[Oorexx-devel] Fwd: SVN browser on sourceforge - broken?

[Sahananda Sahananda]

-- Forwarded message -
From: Sahananda Sahananda 
Date: Sat, 6 Jan 2024 at 21:40
Subject: Re: [Oorexx-devel] SVN browser on sourceforge - broken?
To: oorexx 


Ah YES - Brilliant it is back.

Thanks P.O.

On Sat, 6 Jan 2024 at 21:28, oorexx  wrote:

> Dear Jon,
>
> It might have been me; I was just uploading something using FTP and that
> might have blocked you, please try again, it worked for me just now.
>
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se
>
>
>
>
> Am 06.01.2024 um 22:07 schrieb Sahananda Sahananda :
>
> Hi All,
>
> when I try to browse the SVN through the sourceforge SVN web interface
> <https://sourceforge.net/p/oorexx/code-0/> I see this message:
>
> Browsing this repo on the web is unavailable currently. To fix, please try
>> a Repository Refresh <https://sourceforge.net/p/oorexx/code-0/refresh>.
>> Committing and pulling code should still work.
>
>
> I can confirm that I can still update my working copy.
> I don't know if this message pertains only to my sourceforge login or is
> general.  I tried clicking on the repository refresh link, but it didn't
> seem to fix things.
>
> I'm not sure how or whether to proceed.
>
> Jon
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] SVN browser on sourceforge - broken?

[Sahananda Sahananda]

Hi All,

when I try to browse the SVN through the sourceforge SVN web interface
 I see this message:

Browsing this repo on the web is unavailable currently. To fix, please try
> a Repository Refresh .
> Committing and pulling code should still work.


I can confirm that I can still update my working copy.
I don't know if this message pertains only to my sourceforge login or is
general.  I tried clicking on the repository refresh link, but it didn't
seem to fix things.

I'm not sure how or whether to proceed.

Jon
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] Discuss bug 1647 - ooDialog crashes interpreter

[Sahananda Sahananda]

 Hi Developers,

there is an open bug https://sourceforge.net/p/oorexx/bugs/1647/ which was
first reported nearly 5 years ago, in which use of some ooDialog public
routines (ooDialog Ref 30.1.1) in some circumstances crash the interpreter.

I don't think that anyone has done any work on this, and it may be that
because of it's special nature (Windows Gui programming) no one is going to.

Please can I just initiate some discussion / ask some questions.

*Firstly, the milestone for the bug ticket is 'ooDialog 4.2.0' - would this
bug get more attention if the milestone was '5.1.0' - it does crash the
5.1.0 interpreter.  Can I just change it?*

I found myself able to recreate this problem reliably, and I might be
wrong, but I have a hunch that the problem is in the use of the c++
function GetTextExtentPoint32, and I have another hunch that this problem
only occurs with the 64bit interpreter (but not always).

Calls to GetTextExtentPoint32 exist in several of the Public Routines
(TimedMessage, InputBox, MultiInputBox, ListChoice, CheckList,
SIngleSelection, Progress Dialog).
They also exist in one of the ooDialog Main classes PropertySheet and it's
long deprecated predecessor CategoryDialog
Also they exist in the DynamicDialog mixin class used by all ooDialog
programmers who do not use a resource builder.  Luckily the calls there are
in less used methods (createRadioButtonGroup,
createCheckBoxGroup,CreateEditInput, createEditInputGroup,
createEditInputStem, createComboBoxInput, createCheckboxStem &
createRadioButtonStem) all of which simultaneously create a dialog control
(or group of controls) and their static label(s).

All of these channel through 19 calls to GetTextExtentPoint32 in one of
[oodBaseDialog.cpp, oodControl.cpp, oodDeviceGraphics.cpp or oodialog.cpp]

Now, I don't know enough about C++ or Windows GUI coding to understand the
error, but I see the warning about runtime errors on this page
https://learn.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-gettextextentpoint32w

*So, I wonder: Even if we don't know how to fix this problem, could we not
handle it such that it throws a rexx error rather than crashing the
interpreter?*

For myself, I have hit this problem in the InputBox and listchoice routines
and have worked around it by writing my own safe routines.  These require
the size of the dialog to be specified at coding time rather than runtime,
but as they are often used with static text labels this is not a big
disadvantage.  I could tidy these routines up and make them available in
the sandbox as a workaround, but I don't want to do this if the bug is
going to get attention, as no doubt my workarounds would then appear in
users code and require support for decades.

This leads me to ask the question:  *Is anyone likely to fix this problem
or handle the errors in the (near) future?  *I'm not trying to pressure
anyone, but a bit of crystal ball gazing might save us from me creating a
future mess.

thanks for listening

Jon
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Committing change

[Sahananda Sahananda]

Hi Terry,

It looks like you are not a committer.  I believe that Erich as the project
manager could convey that right on you.  In the old days that would follow
a poll of all the committers.
Otherwise you would need to create and submit a patch.  If you use Tortoise
SVN you can create a patch from the context menu.  If you use SVN directly,
someone will tell you what to do.
You submit patches through the patches tracker on sourceforge.

If I was polled on making you a committer I would vote +1

Jon

On Fri, 22 Sept 2023 at 18:08, taf  wrote:

> I've got the change for the ooRexx.org site that Jon provided. I've
> tried to commit the change, but I don't have the appropriate access.
> Should I send the change to someone else?
>
> --
> taf
>
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] oorexx.org lists 4.2.0 as current release for downloads

[Sahananda Sahananda]

Hi All,

I notice that https://www.oorexx.org/download.html shows 4.2.0 as our
latest release.

I believe the website is source controlled through the SVN and I find the
page source in the SVN at  / websites / main / trunk / docroot /
download.html

I have four questions.
1) Should bug tracker items be raised for problems with the website?  I
don't see any previous ones.
2) Is it a simple matter of updating the SVN or does the website also need
to be published somehow.
3) All the current links to downloads on that page refer to http, but when
I go to sourceforge the pages are https.  Does that matter?  Which should
be coded there?
4) Should this go on a list of tasks for a release?

Notwithstanding the above questions I think the html that is needed to be
added is
~~~

  
 Release
5.0.0
  
  
 Install/Source Files
 
https://sourceforge.net/projects/oorexx/files/oorexx/5.0.0/";>ooRexx install
files
 
  
  
 Documentation
 
https://sourceforge.net/projects/oorexx/files/oorexx-docs/5.0.0/";>ooRexx
docs
 
  
~~~

and it should go immediately above the comment

~~~

~~~

If no one else feels this is their task, I could take it on.

Jon
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] ooRexx access to Google Sheets

[Sahananda Sahananda]

Looking at https://developers.google.com/sheets/api/guides/concepts

It appears Google sheets has a restful api.  You can usually access a
restful api using curl or rexx/curl and the Json class.  Have a poke around
the documentation and if you give it a try and need help, ask back here.

Jon

On Thu, 7 Sep 2023, 03:31 Sanford Geiger,  wrote:

>
> Is there a way to directly access Google Sheets using
> ooRexx? If so, how?
>Thank you,
>   Sandy Geiger
>
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Latest Builds

[Sahananda Sahananda]

Hi GIl,

I should have said, using Chrome Browser with Windows Defender.  Windows
defender updated to 1.391.1635.0 today at approx the time of the download.
If you are using WD it might be worth forcing an update

hth Jon

On Fri, 16 Jun 2023 at 15:42, Sahananda Sahananda 
wrote:

> Hi Gil,
>
> Just successfully upgraded 12583 => 12693  on Windows 11.  Usually the
> first time I click "run anyway" it silently terminates the process without
> running.  This time it installed first time.
>
> Jon
>
> On Fri, 16 Jun 2023 at 15:20, Gilbert Barmwater 
> wrote:
>
>> Has anyone had any success in downloading the latest Windows 64-bit
>> build?  I tried to update twice this morning and got messages that the
>> file couldn't be downloaded because it had a virus.  Now I normally have
>> to jump through hoops anyway because Windows tells me that the file
>> isn't normally downloaded and then yes, I really want to keep it anyway
>> but now it says after all that that the file has a virus.  I'm sure it's
>> a false positive but I can't install the latest build because of it.
>> Anybody else seeing this?  BTW, this is Windows 10 with the Edge browser.
>>
>> Gil
>>
>>
>>
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Latest Builds

[Sahananda Sahananda]

Hi Gil,

Just successfully upgraded 12583 => 12693  on Windows 11.  Usually the
first time I click "run anyway" it silently terminates the process without
running.  This time it installed first time.

Jon

On Fri, 16 Jun 2023 at 15:20, Gilbert Barmwater  wrote:

> Has anyone had any success in downloading the latest Windows 64-bit
> build?  I tried to update twice this morning and got messages that the
> file couldn't be downloaded because it had a virus.  Now I normally have
> to jump through hoops anyway because Windows tells me that the file
> isn't normally downloaded and then yes, I really want to keep it anyway
> but now it says after all that that the file has a virus.  I'm sure it's
> a false positive but I can't install the latest build because of it.
> Anybody else seeing this?  BTW, this is Windows 10 with the Edge browser.
>
> Gil
>
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Musings with tracing multithreaded ooRexx programs, mt91.rex: on two Rexx interpreter instances (RII)

[Sahananda Sahananda]

I like these suggestions.

Jon

On Fri, 17 Feb 2023 at 09:14, René Jansen  wrote:

> One idea here is to no change the options of TRACE at all (they are very
> portable over variants). For implementations that have threads, why don’t
> we add a
>
> TRACE THREADS
>
> before the trace statement. We can have an TRACE THREADS OFF option to
> switch back to the regular trace.
>
> also, a
>
> TRACE THREAD x
>
> would just trace a named thread. Assuming we name them, which would be
> better than following the OS.
>
> In this vein, I would very much like a
>
> TRACE TIME
>
> which timestamps trace messages (for performance work), combinable with
> threads.
>
> This would have the advantage of keeping TRACE the same on implementations
> and add the extra line length when asked for it.
> It can also be done in OPTIONS - where the general line should be that
> unknown options are just ignored.
>
> best regards,
>
> René.
>
> On 16 Feb 2023, at 22:42, Rony  wrote:
>
>
> Am 15.02.2023 um 18:57 schrieb Mike Cowlishaw :
>
>
> As for the 'spaced out' case (excerpt below) ... this really would not
> work for me.   I often have 5-9 windows open when I'm programming and these
> are 80 characters wide so I can minimise overlaps.  With the suggested
> layout this would only work for programs less than ~40 characters wide!
> Here's how the excerpt looks for me (and this example has very short lines
> -- most of my programs use 72 or more characters per line for better
> commentary):
>
> ---> mt91.rex_nr_1_via_JSR223
> R1   T1   A13 *-* t=.Test~new
> R1   T1   A2V1  1* 21 *-* say "arrived in:" .context~name
> arrived in: INIT
> R1   T1   A2V1  1* 22 *-* counter=0
> R1   T1   A1  >>>   "a TEST"
> R1   T1   A14 *-* t~m1
> R1   T1   A3V1  1* 27 *-* counter+=1  -- increase
> counter
> R1   T1   A3V1  1* 28 *-* say "arrived in:" .context~name
> "before reply"
>
> Almost any line of any length will wrap.  That's why the trace headers in
> Rexx are kept as short as feasible.
>
> Yes trace has been well thought out and well designed.
>
> It seems that you are under the impression that this extra trace
> information should get added to trace by default? If so, that is not the
> case. In effect as designed and
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Musings with tracing multithreaded ooRexx programs, mt91.rex: on two Rexx interpreter instances (RII)

[Sahananda Sahananda]

Hi,

I think Gil talks sense.  Most of the time, most or all of the users do not
need or want this feature, but when they do, it would be important and
should provide all the information they might require.

I may be covering old ground here, but as a user I don't do multithreading
on a whim.  When I first learnt about it, I got excited about the prospect
of improving performance, but then, and probably still now, on Windows all
the ooRexx threads run on the same core, so if there are any performance
advantages, it seems to me that they would be negligible.  Apart from a
very few exceptions I pretty much only indulge in multi-threading when
forced to by the GUI package.

Gil's suggestion provokes two responses in me which I offer in the spirit
of helpfulness.

1) If one accepts that this could be an external package, then is it really
such a leap to sanction having it contained within the interpreter and
subject to our regression testing etc., but requiring something from the
user to turn it on.  Many applications and services honour the concept of a
verbose mode.  It doesn't have to be called verbose tracing, it could be
called advanced multithread tracing mode or some such.

2) If on the other hand, it does become a separate package in the
incubator, and special hooks have to be built into the interpreter for it,
then should we not perhaps be more ambitious and aim for the hooks that
would be needed to provide a future toy like the IBM Object Rexx
Workbench.  There must have historically been hooks provided for that, and
perhaps they are still there.  I mention the workbench, because that is the
sort of thing that I'm led to believe young programmers value.  Having
grown up with merely Xedit and a flowchart template as my IDE I did not
miss The Workbench too much personally, but in my opinion, providing a
workbench with breakpoint and variable modification capabilities as well as
auto-complete and context sensitive help would be a good strategic move for
rexx (I am aware of the intelliJ offering, but would advocate taking it
further).  In case this paragraph might read like I'm demanding the
development team pull this rabbit out of a hat here and now, that is not
what I'm expecting.  I just want us to adopt a strategic direction.  I have
no idea how, if or when we would get there.

just my two-pennies/cents worth

On Wed, 15 Feb 2023 at 22:45, Gilbert Barmwater  wrote:

> Not being a user who writes multi-threaded ooRexx programs, I have
> remained silent until now.  However, it seems to me that there are enough
> objections to the proposal that would add this to TRACE that we should
> consider alternatives. I appreciate the need for the information and the
> work done both by Jean-Louis and Rony but perhaps this is better provided
> as a stand alone package in the Incubator similar to ooSQLite.  Then those
> that need the information that this package supplies could retrieve the
> package and add the appropriate ::requires directive(s) to their program.
> I understand this will require some redesign and may still need additions
> to the interpreter to expose the needed data to an external package but I
> think we should consider going this route as I do not see a compromise that
> will satisfy everyone.  Just my 2 opinion for what its worth.  Gil
> On 2/15/2023 1:59 PM, Rick McGuire wrote:
>
> I’m in complete agreement with Mike on this. There are better ways to make
> this sort of information available than trying to force fit it   In to
> trace.
>
> Rick
>
> On Wed, Feb 15, 2023 at 12:58 PM Mike Cowlishaw 
> wrote:
>
>> Thanks for the multiple examples!
>>
>> As for the 'spaced out' case (excerpt below) ... this really would not
>> work for me.   I often have 5-9 windows open when I'm programming and these
>> are 80 characters wide so I can minimise overlaps.  With the suggested
>> layout this would only work for programs less than ~40 characters wide!
>> Here's how the excerpt looks for me (and this example has very short lines
>> -- most of my programs use 72 or more characters per line for better
>> commentary):
>>
>> ---> mt91.rex_nr_1_via_JSR223
>> R1   T1   A13 *-* t=.Test~new
>> R1   T1   A2V1  1* 21 *-* say "arrived in:" .context~name
>> arrived in: INIT
>> R1   T1   A2V1  1* 22 *-* counter=0
>> R1   T1   A1  >>>   "a TEST"
>> R1   T1   A14 *-* t~m1
>> R1   T1   A3V1  1* 27 *-* counter+=1  -- increase
>> counter
>> R1   T1   A3V1  1* 28 *-* say "arrived in:" .context~name
>> "before reply"
>>
>> Almost any line of any length will wrap.  That's why the trace headers in
>> Rexx are kept as short as feasible.  Adding an unexplained 27 characters on
>> the front of each line makes little sense, especially as the information is
>> the same on most lines, and as I mentioned before is not user-friendly
>> (here I mean 'user' as being a writer of Rexx programs, not someone who
>> runs a 

Re: [Oorexx-devel] A draft for documenting MT tracing (Re: Planning to add multithreaded (concurrent) tracing (Re: RFC for feature request "794 Concurrency request"

[Sahananda Sahananda]

I don't know if it is helpful for me to say this, but just in case.

When creating ooDialog scripts (I think of myself principally as a USER of
ooRexx and ooDialog though I also have my users who don't code) I have
sometimes had a great need for this kind of trace.

Things can hang, and it often isn't clear where they are or the journey
they have taken to get there, as you are handling (perhaps simultaneously)
messages from Windows GUI.

In the past I have had to resort (with Mark Miesfeld or Rick's help) to the
C++ tools to get a chance of understanding what is going on - and for a
mere user like me - that is far more difficult.

I can understand how users could go through life, and never be in a
position where they need to look at multiple threads, and I'm glad for
them, but should they prevent these tools being available when they are
needed.

hope that helps

Jon

On Sun, 12 Feb 2023 at 14:41, Rony G. Flatscher 
wrote:

> On 11.02.2023 20:11, Mike Cowlishaw wrote:
>
> Similar comments:  this extra information seems to be aimed at
> 'developers', not users.   A user seeing the proposed output would have no
> idea what it means or what it's about.  It's astonishing, in every sense.
>
> Not sure what you mean when writing "developers" or "users" in this
> context.
>
> Just to be clear about the meanings in this e-mail context: "developer"
> means the "developer of an ooRexx program" and "user" means "user of an
> ooRexx program (probably not a programmer)".
>
> This is about the TRACE instruction that gets usually used for debugging
> when developing programs, users of programs usually do not get to see TRACE
> output (with the single exception that a command causing a failure will be
> traced by default).
>
>
> To me this seems absolutely contrary to the Rexx principles.   If
> developers need this kind of information, cannot this be achieved by other,
> less visible and less ugly, means?
>
> There may be a misunderstanding here.
>
> Multithreaded tracing is meant to help the *developers* of an ooRexx
> program to trace ooRexx programs that execute in different threads for
> debugging purposes (there is no need for this in classic Rexx). The next
> context is that the execution environment are method routines, i.e. method
> routines usually defined in classes and being executed on behalf of an
> ooRexx object (as classic Rexx has no classes/methods there is no reason to
> trace them).
>
> The ooRexx reference, rexxref.pdf, documents concurrency in ooRexx in
> chapter "12. Concurrency" such that one can expect that there are ooRexx
> programmers who will apply/exploit it.
>
> ---
>
> The ooRexx TRACE is modeled after the classic Rexx trace and currently
> does unfortunately not have the ability to gain insight of what happens
> when ooRexx programs execute in a mulithreaded fashion.
>
> Take a look at this ooRexx program taking advantage of ooRexx' concurrency:
>
> c1 = .c~new
> call syssleep 0.5
> c1~m2 -- wake-up m1
> say "done"
>
> ::class C
> ::method init
> expose s
> s = 0
> reply
>
> self~m1
>
> ::method m1
> expose s
> s = 1
> guard off
> say "before guard" -- here, no lock
> guard on when s <> 1 -- but here, is locked while waiting...
> say "after guard"
>
> ::method m2
> expose s
> s = 2
>
> -- ::options trace a
>
>
> If you run this program it will hang (run into a deadlock), here the
> output thanks to some say-statements for debugging:
>
> G:\test\orx\trace>jlf_dl1.rex
> before guard
>
> The program just hangs, one must CTL-C to break the running program.
>
> So where is the problem? The current TRACE does not help to shed any light
> on the (concurrent) ooRexx context.
>
> This is where the MT tracing enhancement comes into play, following the
> "Rexx principles" to make the programmers better understand what happens
> and how the Rexx program gets executed. After all, this is the motivation
> that you came up with TRACE, right?
>
> So in the post-classic Rexx, ooRexx, allowing for exploiting OO,
> concurrency, messaging etc., TRACE needs to be enhanced accordingly to help
> and ease the ooRexx program developer with his work when hitting problems
> because of the complex environment concurrently executing ooRexx programs
> have to relate to. It is about making debugging in this application area
> easier than is currently possible.
>
> To illustrate, firstly here a TRACE A in "classic Rexx style" as currently
> implemented in ooRexx 5.0 (by uncommenting the options directive at the end
> of the above program which will set TRACE A for the entire package, i.e.
> for all routines in that program):
>
> G:\test\orx\trace>jlf_dl1.rex
>  1 *-* c1 = .c~new
>>I> Method "INIT" with scope "C" in package 
> "G:\test\orx\trace\jlf_dl1.rex".
>  8 *-* expose s
>  9 *-* s = 0
> 10 *-* reply
>  2 *-* call syssleep 0.5
>>I> Method "INIT" with scope "C" in package 
> "G:\test\orx\trace\jlf_dl1.rex".
> 12 *-* self~m1
> 

Re: [Oorexx-devel] Jenkins Heads-up

[Sahananda Sahananda]

Thanks P.O.

Jon

On Mon, 6 Feb 2023 at 21:57, ooRexx  wrote:

> I failed to notice that the machine used for building the documentation
> was offline for some time. I have reconnected it and it will start to
> rebuild any changed documentation within an hour or so.
>
> This line seems to take ages to get past, seems to be a huge file. What is
> it?
>
> AoorexxdocSVN/tools/RailRoadDiagrams/rr-1.67-java8.zip
>
>
>
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se
>
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Request for fast help on finally resolving 5.0.0 related open partial tracker items ...

[Sahananda Sahananda]

Hi Gil, Rony,

Love the build tools. +1+1+1

After removing some non-utf triple elipses (...) that should have been (. .
.) my changes now compile.

As well as the thousands of fo:region-after etc. warnings that have been
the subject of a couple of threads on this list I also see:

   - WARNING: Font "Symbol,normal,700" not found. Substituting with
   "Symbol,normal,400".
   - WARNING: Font "ZapfDingbats,normal,700" not found. Substituting with
   "ZapfDingbats,normal,400".
   - WARNING: Font "Liberation Sans,normal,400" not found. Substituting
   with "any,normal,400".
   - WARNING: span="inherit" on fo:block, but no explicit value found on
   the parent FO.
   - WARNING: Destination: Unresolved ID reference "book-oorexx-oodialog"
   found.
   - WARNING: Destination: Unresolved ID reference "notices.title" found.
   - WARNING: Destination: Unresolved ID reference "cplv10.title" found.

I can't find an fo:block or any of the unresolved ID references in the
source file I have edited
book-oorexx-oodialog is in book_info.xml
notices.title is in Notices.xml
cplv10.title is in CPLv1.0.xml

Should these be a cause for concern do you think?

Jon




On Mon, 6 Feb 2023 at 16:29, Sahananda Sahananda 
wrote:

> Hi Rony, Gil,
>
> I have the repository checked out and updated it just before working on
> the docs.
>
> Thanks for the build at home instructions.  I will try to give it a go
> over the next couple of evenings.
>
> Jon
>
> On Mon, 6 Feb 2023 at 14:02, Gilbert Barmwater 
> wrote:
>
>> On 2/6/2023 6:50 AM, Rony G. Flatscher wrote:
>>
>> Hi Jon,
>> On 05.02.2023 22:34, Sahananda Sahananda wrote:
>>
>> I have updated and committed the xml file.  I think that now an automatic
>> rebuild of the documentation will be triggered.  Is that right?
>>
>> Not sure. An automatic build gets triggered if code changes took place
>> IIRC. Maybe in that context the documentation may be recreated and updated
>> on the web site, just do not know.
>>
>> If there are build errors how will I get to see them?
>>
>> If you created the documentation yourself in the subdirectory "log_files"
>> (see below).
>>
>> Creating the documentation for yourself is actually not really difficult,
>> here an attempt of a "how-to":
>>
>> Probably the easiest (sic!) would be to check out the entire ooRexx
>> project via svn. Here the directions copied over:
>>
>>  Forwarded Message 
>> Subject: Getting oorexx docs, test, code from SourceForge to help the
>> oorexx project ... (Re: [rexxla-members] The external program search order,
>> source-relative paths, Call and Requires
>> Date: Fri, 20 Jan 2023 12:37:35 +0100
>> From: Rony Flatscher
>> To: rexxla-memb...@groups.io
>> ... cut ...
>>
>> ... a coarse path:
>>
>>- get svn for your operating system, if not already present (e.g.
>>Tortoise for Windows, on Unix the respective svn package)
>>- run:
>>- svn checkout https://svn.code.sf.net/p/oorexx/code-0/ oorexx-proj
>>- The above will create a directory "oorexx-proj" which  contains
>>everything of the ooRexx project with the following important directories:
>>   - latest documentation: oorexx-proj/docs/trunk
>>   - latest test framework: oorexx-proj/test/trunk
>>   - latest code: oorexx-proj/main/trunk
>>
>> Ad docs/trunk: go into the "tools" directory and study "readme.txt". The
>> build tools are either in bldoc_win (cmd scripts) or bldoc_orx (Rexx
>> scripts).
>>
>> Basically all documentation is in DocBook XML and the xsl files are used
>> to transform it to pdf and html.
>>
>> The XML text sources are in oorexx-proj/docs/trunk in subdirectories
>> named after the book, e.g. "rexxref/en-US" (reference) or "rexxapi/en-US"
>> (the API documentation). The cover page and first pages are the same for
>> all books and defined in "oorexx/en-US".
>>
>> The tools/bldoc* directories contain scripts that allow one to create the
>> books one by one. "setup" will try to download the needed tools from the
>> internet, "docprep" allows one to denote the book to create and e.g.
>> "doc2pdf" tries to create a pdf rendering and places it, if successful into
>> "pdf_files".
>>
>> ... cut ...
>>
>> After checking out the ooRexx project as described above this would be a
>> fast-lane approach to create the documentation immediately:
>>
>>- change into

Re: [Oorexx-devel] Request for fast help on finally resolving 5.0.0 related open partial tracker items ...

[Sahananda Sahananda]

Hi Rony, Gil,

I have the repository checked out and updated it just before working on the
docs.

Thanks for the build at home instructions.  I will try to give it a go over
the next couple of evenings.

Jon

On Mon, 6 Feb 2023 at 14:02, Gilbert Barmwater  wrote:

> On 2/6/2023 6:50 AM, Rony G. Flatscher wrote:
>
> Hi Jon,
> On 05.02.2023 22:34, Sahananda Sahananda wrote:
>
> I have updated and committed the xml file.  I think that now an automatic
> rebuild of the documentation will be triggered.  Is that right?
>
> Not sure. An automatic build gets triggered if code changes took place
> IIRC. Maybe in that context the documentation may be recreated and updated
> on the web site, just do not know.
>
> If there are build errors how will I get to see them?
>
> If you created the documentation yourself in the subdirectory "log_files"
> (see below).
>
> Creating the documentation for yourself is actually not really difficult,
> here an attempt of a "how-to":
>
> Probably the easiest (sic!) would be to check out the entire ooRexx
> project via svn. Here the directions copied over:
>
>  Forwarded Message 
> Subject: Getting oorexx docs, test, code from SourceForge to help the
> oorexx project ... (Re: [rexxla-members] The external program search order,
> source-relative paths, Call and Requires
> Date: Fri, 20 Jan 2023 12:37:35 +0100
> From: Rony Flatscher
> To: rexxla-memb...@groups.io
> ... cut ...
>
> ... a coarse path:
>
>- get svn for your operating system, if not already present (e.g.
>Tortoise for Windows, on Unix the respective svn package)
>- run:
>- svn checkout https://svn.code.sf.net/p/oorexx/code-0/ oorexx-proj
>- The above will create a directory "oorexx-proj" which  contains
>everything of the ooRexx project with the following important directories:
>   - latest documentation: oorexx-proj/docs/trunk
>   - latest test framework: oorexx-proj/test/trunk
>   - latest code: oorexx-proj/main/trunk
>
> Ad docs/trunk: go into the "tools" directory and study "readme.txt". The
> build tools are either in bldoc_win (cmd scripts) or bldoc_orx (Rexx
> scripts).
>
> Basically all documentation is in DocBook XML and the xsl files are used
> to transform it to pdf and html.
>
> The XML text sources are in oorexx-proj/docs/trunk in subdirectories named
> after the book, e.g. "rexxref/en-US" (reference) or "rexxapi/en-US" (the
> API documentation). The cover page and first pages are the same for all
> books and defined in "oorexx/en-US".
>
> The tools/bldoc* directories contain scripts that allow one to create the
> books one by one. "setup" will try to download the needed tools from the
> internet, "docprep" allows one to denote the book to create and e.g.
> "doc2pdf" tries to create a pdf rendering and places it, if successful into
> "pdf_files".
>
> ... cut ...
>
> After checking out the ooRexx project as described above this would be a
> fast-lane approach to create the documentation immediately:
>
>- change into "oorexx-proj/docs/trunk/tools/bldoc_win" (I prefer
>"bldoc_orx", but there is a little bug currently there)
>
> Indeed there is but I have located the issue and have designed a fix which
> I am in the midst of developing and testing.
>
>
>- you may want to skim over "read1st.txt"
>   - run "setup.rex" (will download all software needed to create the
>docs)
>- then each time you want to create a book (bldoc_win will use
>environment variables if not mistaken, so the following steps might have to
>be repeated for each new session):
>- run "docpath.cmd %cd%\..\..\orexx-proj\docs\trunk"  (or define an
>   absolute path): this is the location where book directories are rooted
>   - run "docprep.cmd oodialog" (this defines the book-directory
>   looked up in docpath)
>   - run "doc2pdf.cmd": this will run in sequence
>   - "doc2fo.cmd": creates the fo-file "oodialog.fo" in the "fo_files"
>  directory placing any log output ("oodialog.log") into "log_files"
>  - "fo2pdf.cmd": creates the pdf-file "oodialog.pdf" in the
>  "pdf_files" directory from the fo-file "fo_files\oodialog.fo"
>
> So when everything went fine you would have the pdf file in the
> "pdf_files" subdirectory. If not, then there was probably an error creating
> the fo-file "oodailog.fo" which would be described in
> "log_files\oodialo

[Oorexx-devel] Access to the builds

[Sahananda Sahananda]

Hi all,

at some point my access to Jenkins which I set up in around 2015 has fallen
off.

I have recreated my account - username: sahananda

However, logging in I see 'sahananda is missing the Overall/Read permission'

I would like to be able to see the builds - particularly the documentation

thanks

Jon
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Request for fast help on finally resolving 5.0.0 related open partial tracker items ...

[Sahananda Sahananda]

Hi Rony et al,

I have updated and committed the xml file.  I think that now an automatic
rebuild of the documentation will be triggered.  Is that right?
If there are build errors how will I get to see them?

thanks,

Jon

On Sun, 5 Feb 2023 at 18:40, Rony G. Flatscher 
wrote:

> Hi Jon,
>
> On 05.02.2023 16:51, Sahananda Sahananda wrote:
> > I think I could provide the documentation here for the comboBox.
> >
> > It is really just a question of sensibly copying the paragraphs that
> Mark provided for the
> > listview control methods (15.50, 15.89 & 15.103), but it might be a few
> weeks before I got to it.
> >
> > However, just having a quick check leads me to see other undocumented
> areas of ooDialog 4.2.4.
> >
> > These appear to be the tbButton (toolbar button) class and the change
> summary.
> >
> > I have raised tickets for these documentation deficiencies, but I'm not
> committing to them at this
> > point.
>
> Super, thank you very much indeed!
>
> Best regards
>
> ---rony
>
>
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Request for fast help on finally resolving 5.0.0 related open partial tracker items ...

[Sahananda Sahananda]

HI Rony,

I think I could provide the documentation here for the comboBox.

It is really just a question of sensibly copying the paragraphs that Mark
provided for the listview control methods (15.50, 15.89 & 15.103), but it
might be a few weeks before I got to it.

However, just having a quick check leads me to see other undocumented areas
of ooDialog 4.2.4.

These appear to be the tbButton (toolbar button) class and the change
summary.

I have raised tickets for these documentation deficiencies, but I'm not
committing to them at this point.

Jon

1.5, 4.7.22.1, 18, 23

On Sun, 5 Feb 2023 at 13:58, Rony G. Flatscher 
wrote:

> Hi Jon,
>
> On 02.02.2023 22:21, Sahananda Sahananda wrote:
> > Regarding:  136: # 581 Add item data capability to combo box
> >
> >  (entered by Mark Miesfeld on 2014-01-30 -> 2014-01-30)
> ***TODO: [doc+test]
> >
> > I have always been flakey at providing test cases, but I see what Mark
> has done here.  It echoes
> > what he did with the ooDialog list class.
> > He has added two methods (setItemData and getItemData) which allow you
> to associate an object with
> > each item in the list of a comboBox control.
> > Here is a small test script demonstrating it by associating a 'valueBox'
> (a made up demonstration
> > object) with each item and saying it's value when the item is selected.
> > Maybe it will help someone less flakey to provide a test case and add
> the methods to the
> > documentation.
>
> Thank you for coming back to these ooDialog related open items!
>
> Would it be possible for you to add to the documentation? The reason I am
> asking is that not many
> have an expertise in ooDialog and you have become a real master of it,
> seriously!
>
> If you would attempt to do so we could give you a recipe how to get to the
> documentation (they are
> xml text files and once can copy the existing structure/tags which is
> actually not bad) and how to
> produce the PDF book such that you can check it out yourself before
> creating and supplying a patch!
> Please let us know.
>
> Best regards
>
> ---rony
>
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] e-Mail notifications from patches tracker ?

[Sahananda Sahananda]

Hi Rony,

I think it is bad interface design.  The button to the left of the envelope
has a tooltip follow.  I would click that whilst signed-in.

Jon

On Fri, 3 Feb 2023 at 14:30, Rony G. Flatscher 
wrote:

> On 03.02.2023 15:23, Sahananda Sahananda wrote:
>
> OK.  Rick's email makes sense.  Looks like you need to follow the tracker
> rather than subscribe to the mailing list.
>
> Yes, thank you and thanks to Rick!
>
> The strange thing though is that hovering over the envelope yielded:
>
> as if I was subscribed. Unsubscribing and subscribing again was possible,
> so hoping that this is now working.
>
> ---rony
>
>
>
> On Fri, 3 Feb 2023 at 14:20, Sahananda Sahananda 
> wrote:
>
>> Hi Rony,
>>
>> are you one of the 5 subscribers to the oorexx-patches mailing
>> <https://sourceforge.net/p/oorexx/mailman/oorexx-patches/> list?
>>
>> I see a message on the summary screen saying "This mailing list appears
>> to be either not archived yet, or has had no e-mails sent to it. If it is a
>> new list, please wait 2-4 hours after the first message is sent for the
>> archive to show up." so I wonder if it is the linkage to the patches
>> tracker that does not work.
>>
>> I notice that I received a notification via the feature-requests list
>> yesterday.  Looking at the admin for the tracker under options there is a
>> field 'email ticket notifications to:' which is empty for both lists.
>>
>> It could be that there is a sourceforge problem currently and none of the
>> forwarding is working, or it could be that another admin has changed
>> something, or it could be that this field despite it's name does not
>> control the forwarding of tracker items to the mailing lists.
>>
>> I just tested the rfe ticket and it forwarded to the list ok, even though
>> that field is empty, so not sure now where to go with this one.
>>
>> ideas?
>>
>> Jon
>>
>>
>>
>>
>>
>>
>>
>> On Fri, 3 Feb 2023 at 13:44, Rony G. Flatscher 
>> wrote:
>>
>>> Just noticed that I have not received any e-mail notification messages
>>> when a patch tracker item
>>> gets created (unlike with the bug- or rfre-tracker).
>>>
>>> Does anyone know where one can activate/define this feature and define
>>> the e-mail address to send
>>> notifications to? (Could not find anything looking at the bug tracker
>>> definitions.)
>>>
>>> ---rony
>>>
>>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] e-Mail notifications from patches tracker ?

[Sahananda Sahananda]

OK.  Rick's email makes sense.  Looks like you need to follow the tracker
rather than subscribe to the mailing list.

On Fri, 3 Feb 2023 at 14:20, Sahananda Sahananda 
wrote:

> Hi Rony,
>
> are you one of the 5 subscribers to the oorexx-patches mailing
> <https://sourceforge.net/p/oorexx/mailman/oorexx-patches/> list?
>
> I see a message on the summary screen saying "This mailing list appears
> to be either not archived yet, or has had no e-mails sent to it. If it is a
> new list, please wait 2-4 hours after the first message is sent for the
> archive to show up." so I wonder if it is the linkage to the patches
> tracker that does not work.
>
> I notice that I received a notification via the feature-requests list
> yesterday.  Looking at the admin for the tracker under options there is a
> field 'email ticket notifications to:' which is empty for both lists.
>
> It could be that there is a sourceforge problem currently and none of the
> forwarding is working, or it could be that another admin has changed
> something, or it could be that this field despite it's name does not
> control the forwarding of tracker items to the mailing lists.
>
> I just tested the rfe ticket and it forwarded to the list ok, even though
> that field is empty, so not sure now where to go with this one.
>
> ideas?
>
> Jon
>
>
>
>
>
>
>
> On Fri, 3 Feb 2023 at 13:44, Rony G. Flatscher 
> wrote:
>
>> Just noticed that I have not received any e-mail notification messages
>> when a patch tracker item
>> gets created (unlike with the bug- or rfre-tracker).
>>
>> Does anyone know where one can activate/define this feature and define
>> the e-mail address to send
>> notifications to? (Could not find anything looking at the bug tracker
>> definitions.)
>>
>> ---rony
>>
>>
>>
>>
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] e-Mail notifications from patches tracker ?

[Sahananda Sahananda]

Hi Rony,

are you one of the 5 subscribers to the oorexx-patches mailing
 list?

I see a message on the summary screen saying "This mailing list appears to
be either not archived yet, or has had no e-mails sent to it. If it is a
new list, please wait 2-4 hours after the first message is sent for the
archive to show up." so I wonder if it is the linkage to the patches
tracker that does not work.

I notice that I received a notification via the feature-requests list
yesterday.  Looking at the admin for the tracker under options there is a
field 'email ticket notifications to:' which is empty for both lists.

It could be that there is a sourceforge problem currently and none of the
forwarding is working, or it could be that another admin has changed
something, or it could be that this field despite it's name does not
control the forwarding of tracker items to the mailing lists.

I just tested the rfe ticket and it forwarded to the list ok, even though
that field is empty, so not sure now where to go with this one.

ideas?

Jon







On Fri, 3 Feb 2023 at 13:44, Rony G. Flatscher 
wrote:

> Just noticed that I have not received any e-mail notification messages
> when a patch tracker item
> gets created (unlike with the bug- or rfre-tracker).
>
> Does anyone know where one can activate/define this feature and define the
> e-mail address to send
> notifications to? (Could not find anything looking at the bug tracker
> definitions.)
>
> ---rony
>
>
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Request for fast help on finally resolving 5.0.0 related open partial tracker items ...

[Sahananda Sahananda]

Re:  152: # 550 Add the ReBar dialog control to ooDialog

 (entered by Mark Miesfeld on 2013-08-30 -> 2013-09-21)
***TODO: [doc+test]


This is tricky.  The Documentation for the rebar control is in an
incomplete state and there is a bug in the code as it stands.
I don't think a ticket was ever raised, but there is a discussion on the
ooRexx Open Discussion list dated 2015-01-15 revealing the problem where
rebar controls prevented dialogs resizing.


This left us with a dilemma, ooDialog v4.2.4 was vastly superior to it's
predecessors, but was not really ready for the world.  As I recall, after a
discussion on this list we released it anyway.
It might be worth removing the documentation for the rebar control, in the
intervening 8 years I've never heard of anyone but Nickski attempting to
use it.

Just my opinion FWIW

Jon

On Thu, 2 Feb 2023 at 16:23, Rony G. Flatscher 
wrote:

> CHANGES.txt for 5.0.0 has a couple of bug-fix and rfe-items that are not
> completed in all aspects in full according to the tracker information.
>
>1. It seems that some information is incomplete: please, can the
>authors correct/complete any wrong/incomplete tracker information as soon
>as possible? (E.g. missing 'code' seems to be wrong.)
>
>2. Open test or documentation: could the authors add/complete the
>missing items as soon as possible?
>
>3. Which of the following TODO items cannot be completed? If so, we
>need to adjust the tracker information accordingly!
>E.g. there are TODO items in the RFE section for/by Mark Miesfield who
>has - very unfortunate! - long passed away. What shall we do with them?
>
>4. Are there TODO doc or TODO test items that you think could be done
>by RexxLA members or by lurkers of this list? If so, can you please denote
>exactly which (bug/rfe number, whether test and/or doc is regarded to be
>doable)?
>
> Please give feedback ASAP, the community lives from communication. We need
> to resolve these open TODO items ASAP!
>
> Here the filtered list from ooRexx 5.0.0 "doc/CHANGES.txt":
>
> Fixes in Open Object Rexx 5.0.0
>
> The following is a list of fixes, enhancements, and other relevant changes
> to ooRexx since the 4.2.0 release.  The numbers for each item can be used to
> look up the item in the appropriate tracker in the ooRexx project on
> SourceForge, i.e. the Bugs tracker, the Feature Requests tracker, etc.
>
>
>   Bugs
>   
>   https://sourceforge.net/p/oorexx/bugs/
>
>5: # 1842 linein performance issue
>  (entered by Erich on 2022-09-11 -> 25 minutes ago) ***TODO: 
> [code]
>
>6: # 1841 charin and record I/O linein/arrayin performance
>  (entered by Erich on 2022-09-11 -> 2022-09-11) ***TODO: [code]
>
>7: # 1840 lineout for very long lines is broken
>  (entered by Erich on 2022-09-07 -> 2022-09-18) ***TODO: [tests]
>
>8: # 1838 Crash while attempting to resolve a routine in a library package.
>  (entered by Rick McGuire on 2022-08-11 -> 2022-08-11) ***TODO: 
> [tests]
>
>9: # 1837 circular requires: some public classes are not visible
>  (entered by jfaucher on 2022-08-09 -> 25 minutes ago) ***TODO: 
> [doc+test]
>
>   15: # 1827 13 Sample files missing shebang
>  (entered by Per Olov Jonsson on 2022-07-05 -> 2022-07-22) 
> ***TODO: [code+test]
>
>   16: # 1825 CALL with literal name should bypass internal labels
>  (entered by Matthé van der Lee on 2021-10-02 -> 2022-06-25) 
> ***TODO: [tests]
>
>   40: # 1786 RexxPullFromQueue() returning invalid data for a null queue entry
>  (entered by Daniel Erdos on 2021-11-05 -> 2021-11-27) ***TODO: 
> [tests]
>
>   45: # 1774 Building and Testing on Windows 8
>  (entered by Per Olov Jonsson on 2021-07-13 -> 2021-12-30) 
> ***TODO: [tests]
>
>   50: # 1768 ncurses.cls doesn't build on some platforms
>  (entered by Erich on 2021-05-23 -> 2021-06-02) ***TODO: [tests]
>
>   53: # 1763 StreamSocket issues
>  (entered by Ruurd Idenburg on 2021-05-11 -> 2022-06-27) ***TODO: 
> [code+doc+test]
>
>   54: # 1762 pushing very large data hangs RexxQueue
>  (entered by Erich on 2021-05-04 -> 2021-07-07) ***TODO: 
> [code+test]
>
>   65: # 1742 Stream RECLENGTH 1 issues
>  (entered by Erich on 2021-02-05 -> 2021-02-05) ***TODO: [tests]
>
>   68: # 1734 Hang with multiple threads
>  (entered by Erich on 2020-12-19 -> 2022-06-19) ***TODO: [tests]
>
>  107: # 1656 Lineout fails (at 2nd call) when path case not matched
>  (entered by AvdP on 2019-10-09 -> 2021-01-31) ***TODO: 
> [code+test]
>
>  126: # 1625 NewRoutine() and LoadPackageFromData() raise error 13.1 on 
> tokenized Rexx code
>  (entered by Rony G. Flatscher on 2019-04-06 -> 2019-07-16) 
> ***TODO: [doc+test]
>
>  127: # 1624 .Routine~newFile(rexxc-program) raises error 13.1
>  (entered by Rony G. 

Re: [Oorexx-devel] Request for fast help on finally resolving 5.0.0 related open partial tracker items ...

[Sahananda Sahananda]

Regarding:  136: # 581 Add item data capability to combo box

 (entered by Mark Miesfeld on 2014-01-30 -> 2014-01-30)
***TODO: [doc+test]

I have always been flakey at providing test cases, but I see what Mark has
done here.  It echoes what he did with the ooDialog list class.
He has added two methods (setItemData and getItemData) which allow you to
associate an object with each item in the list of a comboBox control.
Here is a small test script demonstrating it by associating a 'valueBox' (a
made up demonstration object) with each item and saying it's value when the
item is selected.
Maybe it will help someone less flakey to provide a test case and add the
methods to the documentation.

dlg = .comboitemdatadlg~new
dlg~execute
exit

::requires "ooDialog.cls"

::CLASS comboitemdatadlg subclass userdialog
::method init
  self~init:super /*(a.)*/  /* we call the Super Class (userdialog)
 */
  width=300 ; height=200/* Set the Width and height of dialog
 */
  success=self~createCenter(width,height,'Combo Item Data Dialog')

  if \success then do
self~initCode=1
return
  end

::method defineDialog


 
self~createComboBox(100,10,10,self~SizeX-20,self~sizeY-40,'options','combinations')

 self~createPushButton(IDCANCEL,self~sizeX-120,self~sizeY-20,50,15,,'Cancel')

::method initDialog
  cb = self~newComboBox(100)
  if \cb~isNil
  then do
 idx = cb~add('First')
 cb~setItemData(idx,.valueBox~new('One'))
 idx = cb~add('Second')
 cb~setItemData(idx,.valueBox~new('Two'))
 idx = cb~add('Third')
 cb~setItemData(idx,.valueBox~new('Three'))
  end /* DO */

  self~connectComboBoxEvent(100, "SELCHANGE", "onSelChange")

::method onSelChange   unguarded
use arg info, hwnd, id, notifyCode, CB
  idx = CB~selectedIndex
  say idx': ['cb~selected'] ['cb~getItemData(idx)']'
RETURN 0



::CLASS valueBox   private
::method init
  expose value
  use arg value
::method string
  expose value
  RETURN  'a valueBox containing "'value'"'

On Thu, 2 Feb 2023 at 16:23, Rony G. Flatscher 
wrote:

> CHANGES.txt for 5.0.0 has a couple of bug-fix and rfe-items that are not
> completed in all aspects in full according to the tracker information.
>
>1. It seems that some information is incomplete: please, can the
>authors correct/complete any wrong/incomplete tracker information as soon
>as possible? (E.g. missing 'code' seems to be wrong.)
>
>2. Open test or documentation: could the authors add/complete the
>missing items as soon as possible?
>
>3. Which of the following TODO items cannot be completed? If so, we
>need to adjust the tracker information accordingly!
>E.g. there are TODO items in the RFE section for/by Mark Miesfield who
>has - very unfortunate! - long passed away. What shall we do with them?
>
>4. Are there TODO doc or TODO test items that you think could be done
>by RexxLA members or by lurkers of this list? If so, can you please denote
>exactly which (bug/rfe number, whether test and/or doc is regarded to be
>doable)?
>
> Please give feedback ASAP, the community lives from communication. We need
> to resolve these open TODO items ASAP!
>
> Here the filtered list from ooRexx 5.0.0 "doc/CHANGES.txt":
>
> Fixes in Open Object Rexx 5.0.0
>
> The following is a list of fixes, enhancements, and other relevant changes
> to ooRexx since the 4.2.0 release.  The numbers for each item can be used to
> look up the item in the appropriate tracker in the ooRexx project on
> SourceForge, i.e. the Bugs tracker, the Feature Requests tracker, etc.
>
>
>   Bugs
>   
>   https://sourceforge.net/p/oorexx/bugs/
>
>5: # 1842 linein performance issue
>  (entered by Erich on 2022-09-11 -> 25 minutes ago) ***TODO: 
> [code]
>
>6: # 1841 charin and record I/O linein/arrayin performance
>  (entered by Erich on 2022-09-11 -> 2022-09-11) ***TODO: [code]
>
>7: # 1840 lineout for very long lines is broken
>  (entered by Erich on 2022-09-07 -> 2022-09-18) ***TODO: [tests]
>
>8: # 1838 Crash while attempting to resolve a routine in a library package.
>  (entered by Rick McGuire on 2022-08-11 -> 2022-08-11) ***TODO: 
> [tests]
>
>9: # 1837 circular requires: some public classes are not visible
>  (entered by jfaucher on 2022-08-09 -> 25 minutes ago) ***TODO: 
> [doc+test]
>
>   15: # 1827 13 Sample files missing shebang
>  (entered by Per Olov Jonsson on 2022-07-05 -> 2022-07-22) 
> ***TODO: [code+test]
>
>   16: # 1825 CALL with literal name should bypass internal labels
>  (entered by Matthé van der Lee on 2021-10-02 -> 2022-06-25) 
> ***TODO: [tests]
>
>   40: # 1786 RexxPullFromQueue() returning invalid data for a null queue entry
>  (entered by Daniel Erdos on 2021-11-05 -> 2021-11-27) ***TODO: 
> [tests]
>
>   45: # 1774 Building

Re: [Oorexx-devel] Replacement for json.cls ...

[Sahananda Sahananda]

Thank you Rony.  👏

I have had to use terrible kludges to get over the otherwise remarkably
usable JSON class's habit of turning JSON booleans into ooRexx booleans.
This will be a great boon.

+1 to adding this to the language proper.

Jon

On Thu, 2 Feb 2023 at 12:37, Rony G. Flatscher 
wrote:

> "json.cls" as distributed with ooRexx 5.0.0 has one (actually two)
> limitation which can be regarded to be a bug:
>
>- It cannot handle JSON booleans properly: when reading a JSON file
>with boolean values and creating a JSON file from ooRexx the boolean values
>will not show up, rather their ooRexx numeric representations of "0" and
>"1".
>
> In the past I came up with a solution for this problem which was not
> "liked" and was 30% slower than json.cls (sounds dramatic, but in today's
> world with such power horses in the hands of end-users may be negligeable,
> but still, one being made aware of this made it less attractive).
>
> As the above limitation is really a problem if one wants to use ooRexx
> json.cls and exchange proper JSON with other systems, e.g. via curl, I came
> up with a version (starting out with the current json.cls) that does the
> following in addition:
>
>- It adds support for JSON true and false: just send .json~true or
>.json~false. The resulting JsonBoolean objects behave like ooRexx .true and
>.false (both strings with the numeric values "0" and "1") and can be used
>interchangeably
>
>- when reading a JSON file, JSON booleans will be represented with the
>   appropriate .json~true or .json~false values
>
>   - when writing a JSON file, any JSON boolean value will be properly
>   encoded with "false" and "true"
>
>   - It adds generic support for MapCollection and OrderedCollection
>instead of restricting support to Directory and Array,
>
>- It uses StringTable instead of Directory for reading in JSON data,
>
>- Although JSON is a string encoding, which could be read by humans,
>there are two observable properties that do not make it human-friendly:
>
>- by default the encoding is "minimized" such that no ignorable
>   whitespace (usually used for making JSON better legible e.g. cf.
>   Wikipedia's JSON [1] sample) is contained,
>
>   - there is no sorted order of name/value pairs (per specification
>   no order is implied, yet for humans having a sorted order in the JSON
>   encoded data makes it possible to quickly check whether certain 
> name/values
>   pairs exist or not without affecting any JSON importer)
>
> the replacement version will create by default minimized JSON encodings,
> however it will sort name/value pairs by name to ease reading by humans
>
>
>- as this is Rexx/ooRexx it is made possible to create a "legible", a
>"human-oriented" JSON encoding in two ways: when creating a JSON instance
>or when sending the toJson message one can supply .true which causes the
>produced JSON encoding to be formatted with ignorable whitespace such that
>it will be easy to see the structure and spot name/value pairs therein;
>yet, the produced JSON is still JSON and can be processed without problems,
>
>- two new convenience class methods for reading from and writing to
>files are defined: fromJsonFile(fileName) and toJsonFile(fileName,
>ooRexxObject [, legible=.true])
>
> Here the JSON sample given at [1]:
>
> {  "firstName": "John",  "lastName": "Smith",  "isAlive": true,  "age": 27,  
> "address": {"streetAddress": "21 2nd Street","city": "New York",
> "state": "NY","postalCode": "10021-3100"  },  "phoneNumbers": [{  
> "type": "home",  "number": "212 555-1234"},{  "type": 
> "office",  "number": "646 555-4567"}  ],  "children": [  
> "Catherine",  "Thomas",  "Trevor"  ],  "spouse": null}
>
> Here the minimized rendering with the replacement version of json.cls:
>
> {"address":{"city":"New 
> York","postalCode":"10021-3100","state":"NY","streetAddress":"21 2nd 
> Street"},"age":27,"children":["Catherine","Thomas","Trevor"],"firstName":"John","isAlive":true,"lastName":"Smith","phoneNumbers":[{"number":"212
>  555-1234","type":"home"},{"number":"646 
> 555-4567","type":"office"}],"spouse":null}
>
> Here the legible rendering with the replacement version of json.cls:
>
> {
>"address": {
>   "city": "New York",
>   "postalCode": "10021-3100",
>   "state": "NY",
>   "streetAddress": "21 2nd Street"
>},
>"age": 27,
>"children": [
>   "Catherine",
>   "Thomas",
>   "Trevor"
>],
>"firstName": "John",
>"isAlive": true,
>"lastName": "Smith",
>"phoneNumbers": [
>   {
>  "number": "212 555-1234",
>  "type": "home"
>   },
>   {
>  "number": "646 555-4567",
>  "type": "office"
>   }
>],
>"spouse": null
> }
>
> ---
>
> Here an ooRexx program that creates a structure which will get encoded 

Re: [Oorexx-devel] I think I've seen the future...

[Sahananda Sahananda]

Rick,

Fascinating!

I'm really impressed and grateful for the time that you put into trying to
solve this question.

Did ChatGPT provide the comments and variable names as well?

Do you think it 'created' that code or merely 'found it' already solved by
human brains?

Jon

On Mon, 23 Jan 2023 at 14:21, Rony G. Flatscher 
wrote:

>
> On 23.01.2023 14:17, Mike Cowlishaw wrote:
> >
> >> "but still humans need to be able to
> >> understand and assess/control them otherwise humanity becomes
> >> helpless and dependent over time"
> > So it just happens earlier in life ...?  :-))
> Indeed! 😂
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] Enquiry through rexxla website contact form re mutex semaphores

[Sahananda Sahananda]

Hi All,

Can anyone help David (email address below)

thanks,

Jon


Name David Looney
Email Address dals...@cox.net
Subject Mutex semaphores
Details I have experimented with the new mutexsemaphore class and I don't
see a way for it to coordinate activities between independently running
processes. The "sysxxxmutexsem utilities are great at this and while they
are still available in Rexx 5, you have taken the documentation of them out
of the Rexx Reference. Please put them back.
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] How about samples for Restful API with cUrl

[Sahananda Sahananda]

Having pressed send, I thought about this some more.  Ideally we should
have a set of samples demonstrating the use of cUrl with ooRexx and I
wonder if it wouldn't be really nice if they demonstrated using a restful
interface with the JSON class.

I have code for a GET and a POST using JSON class with Mark's rexx/cUrl,
but it was really a novice scrabbling around in the dark.  If anyone could
produce samples demonstrating POST & GET, along with PUT, PATCH & DELETE it
would be a great resource.

Jon

On Mon, 2 Jan 2023 at 18:08, Sahananda Sahananda 
wrote:

> I think that the usage section should briefly explain what cUrl is or what
> cUrl does.
> I remember the first time I met it as a Rexx programmer it was confusing.
>
> Could be as simple as.
>
> N.B.: This program uses "curl" to retrieve data and documents from the 
> internet on all platforms. You can find more information
>   on the Internet or <https://curl.se> <https://curl.se/> and 
> <https://en.wikipedia.org/wiki/CURL> <https://en.wikipedia.org/wiki/CURL>.
>
>
> hth Jon
>
>
> On Mon, 2 Jan 2023 at 17:28, Rony G. Flatscher 
> wrote:
>
>> The usage section now adds at the end:
>>
>> N.B.: This program uses "curl" on all platforms. You can find more 
>> information
>>   on the Internet or <https://curl.se> <https://curl.se> and 
>> <https://en.wikipedia.org/wiki/CURL> <https://en.wikipedia.org/wiki/CURL>.
>>
>>
>> ---rony
>> On 02.01.2023 18:19, Rony G. Flatscher wrote:
>>
>> Dave, could you look at the enclosed sample and give some feedback
>> whether it serves its purpose (demonstrate the new ADDRESS...WITH in an
>> understandable manner)?
>>
>> ---rony
>>
>>
>> On 02.01.2023 14:53, Dave Jones wrote:
>>
>> Not knowing very much about the new ADDRESS...WITH... feature, I would
>> think that it would be a very useful example.
>> DJ
>>
>> On Mon, Jan 2, 2023 at 7:08 AM Rony G. Flatscher 
>> wrote:
>>
>>> One of the many new great features of ooRexx 5.0.0 is the ADDRESS...WITH
>>> variant.
>>>
>>> In order to demonstrate how to use it, here an idea: have a sample that
>>> uses curl command (available
>>> on all modern operating systems) to fetch the latest ooRexx
>>> documentation files from SourceForge and
>>> download them into a subdirectory named docs.V, where "V" would be the
>>> ooRexx version. Supplying the
>>> optional ooRexx version (e.g. "4.2.0", "5.0.0", "5.1.0beta", etc.) would
>>> download all the
>>> documentation files from the given SourceForge oorexx-docs directory.
>>>
>>> What do you think, would that be a helpful sample to add to ooRexx?
>>>
>>> ---rony
>>>
>>
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Idea for a new sample demonstrating ADDRESS ... WITH ...

[Sahananda Sahananda]

I think that the usage section should briefly explain what cUrl is or what
cUrl does.
I remember the first time I met it as a Rexx programmer it was confusing.

Could be as simple as.

N.B.: This program uses "curl" to retrieve data and documents from the
internet on all platforms. You can find more information
  on the Internet or   and

.


hth Jon


On Mon, 2 Jan 2023 at 17:28, Rony G. Flatscher 
wrote:

> The usage section now adds at the end:
>
> N.B.: This program uses "curl" on all platforms. You can find more information
>   on the Internet or   and 
>  .
>
>
> ---rony
> On 02.01.2023 18:19, Rony G. Flatscher wrote:
>
> Dave, could you look at the enclosed sample and give some feedback whether
> it serves its purpose (demonstrate the new ADDRESS...WITH in an
> understandable manner)?
>
> ---rony
>
>
> On 02.01.2023 14:53, Dave Jones wrote:
>
> Not knowing very much about the new ADDRESS...WITH... feature, I would
> think that it would be a very useful example.
> DJ
>
> On Mon, Jan 2, 2023 at 7:08 AM Rony G. Flatscher 
> wrote:
>
>> One of the many new great features of ooRexx 5.0.0 is the ADDRESS...WITH
>> variant.
>>
>> In order to demonstrate how to use it, here an idea: have a sample that
>> uses curl command (available
>> on all modern operating systems) to fetch the latest ooRexx documentation
>> files from SourceForge and
>> download them into a subdirectory named docs.V, where "V" would be the
>> ooRexx version. Supplying the
>> optional ooRexx version (e.g. "4.2.0", "5.0.0", "5.1.0beta", etc.) would
>> download all the
>> documentation files from the given SourceForge oorexx-docs directory.
>>
>> What do you think, would that be a helpful sample to add to ooRexx?
>>
>> ---rony
>>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Kudos

[Sahananda Sahananda]

Jose Maria Blasco who made the comment followed it up and allows me to pass
it to the development team:

  A real pleasure. This new 5.0.0 release is *glorious* :) I just installed
it on Ubuntu 22.04.01LTS, where it drives our web, www.epbcn.com (~40.000
pages, we're an SMB dedicated to mental health and education), without a
single problem.

I've written the CGI wrapper for our web, and we get pages happily served
at < 60 ms/page, all of them constructed following an elegant hierarchy of
classes. Awesome.

And the new ::RESOURCE directive will come very handy to make the process
still more elegant.

So, thanks to you, to all the development team, and of course to RexxLA.
I've been programming in Rexx practically all my life (since 1981 iirc,
under VM/SP rel 3, we had an IBM 4341 I think), switched effortlessly (and
with great advantage) to the oo- version, and I continue to benefit from
the pleasure to use a language that has kept small size and designed for
humans.

  Jose Maria


On Sun, 1 Jan 2023 at 16:46, Rony G. Flatscher 
wrote:

> On 01.01.2023 15:05, Sahananda Sahananda wrote:
>
> A note was attached to a recent donation to rexxLa
>
> 'Thanks for the 5.0.0 release. Keep up the good work! :)'
>
> I thought I should pass it on.
>
> that is kind of you, thank you very much for passing it on!
>
> Also many thanks to everyone who was involved in this release, kudos, you
> made the release a reality which has been making many ooRexx supporters
> very happy! :)
>
> ---rony
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] Kudos

[Sahananda Sahananda]

A note was attached to a recent donation to rexxLa

'Thanks for the 5.0.0 release. Keep up the good work! :)'

I thought I should pass it on.

Jon
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] Sourceforge release glitch

[Sahananda Sahananda]

Hi,

The page https://sourceforge.net/projects/oorexx/files/ on my laptop has a
button on the top inviting me to download ooRexx 5.0.0 as the current
version.
Looking at this same page on my phone, the same button offers ooRexx 4.1.0
as the latest version.

Jon
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Ad oorexx-announcement list

[Sahananda Sahananda]

I have tried.  No Bounce, but I don't see it on the list nor do I get a
request for moderation.  Sourceforge may be running slow.

Jon

On Fri, 23 Dec 2022 at 23:22, Rony  wrote:

> Just received a rejection from the oorexx-announcement list. Can someone
> else try to send the announcement to that list please?
>
> —-rony
>
> Rony G. Flatscher (mobil/e)
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Proposed text ...

[Sahananda Sahananda]

Just a reminder, we have the ooRexx Announcements list on Sourceforge with
26 members

Jon

On Fri, 23 Dec 2022 at 13:37, WalterPachl via Oorexx-devel <
oorexx-devel@lists.sourceforge.net> wrote:

> Two suggestions:
>
>  OLD-> statements, boiler plate text, base64 encoded binary data ...) and
> much
>  NEW-> statements, boiler plate text, base64 encoded binary data ...) and
> many
>
>
>  OLD-> samples directory which demonstrates some of its capabilities. The
>  NEW-> samples directory which contains programs that demonstrate some of
> its capabilities. The
>
> And thanks to the incredible effort of y'all
> + Season's Greetings
> Walter
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] Making a request for a future release

[Sahananda Sahananda]

Looking at the docs, I think that the *NEW* & *CHANGED* markers are hard to
distinguish from the text and I would like to request that we look into
either using some symbolic markers or text in a different style for these
markers.

However, I don't want this request to hold up this release.

Is there a way to put in a feature request ticket and not have it
considered yet, or should I perhaps sit on my hands till 5.0.0 is out of
the door?

thanks

Jon
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Preparing the release

[Sahananda Sahananda]

Regarding the 11 minute wait I reported.

Soon after this incident it became clear that a massive Windows Update was
brewing, which occupied my laptop for the rest of the evening.

This morning I reverted to ooRexx-5.0.0-12359 then back to
ooRexx-5.0.0-12558 and in both cases the install started immediately and
proceeded relatively briskly.

I often notice that things don't work properly when a Windows Update is
brewing.

Jon

On Fri, 23 Dec 2022 at 08:01, Rony G. Flatscher 
wrote:

> On 22.12.2022 21:54, ooRexx wrote:
> > H Jon,
> >
> > There should be at maximum 5 versions of every platform, which makes it
> 10 for Windows (32/64
> > bit). We do build and test Windows 7,8.1,10 and recently also 11 but we
> only upload Windows 10,
> > which should work on all Windows platforms supported.
> >
> > The problems with Windows blocking the installation (and Apple blocking
> the installation on macOS)
> > is something that should be given high priority once ooRexx 5 is
> officially released IMO. On the
> > ToDo list.
>
> +1
>
> ---rony
>
>
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Preparing the release

[Sahananda Sahananda]

OK.  When I started the download this event occurred which I find in my
Windows Application log.
It appears to be reporting a hang in Explorer, but I launched the installer
from the chrome download bar:
=
Log Name:  Application
Source:Application Hang
Date:  22/12/2022 18:14:58
Event ID:  1002
Task Category: (101)
Level: Error
Keywords:  Classic
User:  N/A
Computer:  DESKTOP-TKEH56A
Description:
The program explorer.exe version 10.0.19041.2193 stopped interacting with
Windows and was closed. To see if more information about the problem is
available, check the problem history in the Security and Maintenance
control panel.
 Process ID: 1aa4
 Start Time: 01d915dcda18f330
 Termination Time: 0
 Application Path: C:\Windows\explorer.exe
 Report Id: 058f3648-5d60-4023-a2da-19d4bf5a310f
 Faulting package full name:
 Faulting package-relative application ID:
 Hang type: Cross-process

Event Xml:
http://schemas.microsoft.com/win/2004/08/events/event";>
  

1002
0
2
101
0
0x80

129349


Application
DESKTOP-TKEH56A

  
  
explorer.exe
10.0.19041.2193
1aa4
01d915dcda18f330
0
C:\Windows\explorer.exe
058f3648-5d60-4023-a2da-19d4bf5a310f




Cross-process

430072006F00730073002D00700072006F006300650073007300
  


On Thu, 22 Dec 2022 at 18:39, Sahananda Sahananda 
wrote:

> OK.  12558 doesn't have the recent changes to the Docs, but it does seem
> to run my programs alright -  Yay.
>
> I notice on sourceforge  files download page:
>
> 1)  You can nominate a default download for operating systems such as
> Windows, Mac or Linux.  I'm not sure if that is any use to us even on
> Windows, because people still have to make a choice of 32 or 64 bit.
>
> 2) Logged in as me, at the bottom of the download page sourceforge has a
> nudge reading "You should add a README file
> <https://sourceforge.net/p/forge/documentation/Files-Readme/>, to provide
> release notes. It will be shown right here."   We should probably add such
> a file to help people select the correct download.
>
> When another version is available I will download it and see if I still
> get the 11 minute delay and I will try to see what processes (if any) are
> active during that time.
>
> Jon
>
> Jon
>
> On Thu, 22 Dec 2022 at 18:26, Sahananda Sahananda 
> wrote:
>
>> Hi.
>>
>> I downloaded ooRexx-5.0.0-12558.windows.x86_32 from the release candidate
>> folder.  It was a bit hard choosing which file to download as there were
>> multiple x86_32 files with different release levels, and none with the
>> highest release level.
>>
>> Running the installer, I got the usual windows stopped you from running
>> something risky, and navigating past that, the installer immediately hung.
>> I can see that there is a window titled 'Window Dialog (Not Responding)'
>> active, but It is minimised or not shown.
>>
>> Spoke too soon - after approx 11 minutes in this state the installer
>> appeared.
>> After that delay the installer ran very quickly.
>> I have a strong feeling/hunch/intuition that there has been something
>> wrong with the windows installer w.r.t. the ooDialog Guide documentation
>> that appears to be fixed now - well done.
>>
>> Hope that is helpful.  I will test and report.
>>
>> Jon
>>
>>
>> On Thu, 22 Dec 2022 at 12:20, Rony G. Flatscher 
>> wrote:
>>
>>> Dear Jon,
>>>
>>> On 22.12.2022 12:56, Sahananda Sahananda wrote:
>>> > Sorry to have been absent during the effort that has gone on over the
>>> last week or so.  I have
>>> > been unwell (really nasty cold).  I'm better now and have a bit of
>>> time if there are any tasks
>>> > that fit my limited skillset.
>>>
>>> thank you very much for your offer!
>>>
>>> It would be helpful at this stage, if you could express your opinion,
>>> especially when questions get
>>> asked! :)
>>>
>>> But also, if you could download, install and run those installation
>>> versions from
>>> <
>>> https://sourceforge.net/projects/oorexx/files/oorexx/5.0.0_Release_Candidate/>
>>> that match your
>>> operating system. If you encounter something that looks strange or any
>>> experiences, impressions and
>>> communicate them would be great!
>>>
>>> Also (not yet had time to look into it), if portable versions of the
>>> release candidates can be
>>> created and uploaded (the suggested sub-directory 

Re: [Oorexx-devel] Preparing the release

[Sahananda Sahananda]

OK.  12558 doesn't have the recent changes to the Docs, but it does seem to
run my programs alright -  Yay.

I notice on sourceforge  files download page:

1)  You can nominate a default download for operating systems such as
Windows, Mac or Linux.  I'm not sure if that is any use to us even on
Windows, because people still have to make a choice of 32 or 64 bit.

2) Logged in as me, at the bottom of the download page sourceforge has a
nudge reading "You should add a README file
<https://sourceforge.net/p/forge/documentation/Files-Readme/>, to provide
release notes. It will be shown right here."   We should probably add such
a file to help people select the correct download.

When another version is available I will download it and see if I still get
the 11 minute delay and I will try to see what processes (if any) are
active during that time.

Jon

Jon

On Thu, 22 Dec 2022 at 18:26, Sahananda Sahananda 
wrote:

> Hi.
>
> I downloaded ooRexx-5.0.0-12558.windows.x86_32 from the release candidate
> folder.  It was a bit hard choosing which file to download as there were
> multiple x86_32 files with different release levels, and none with the
> highest release level.
>
> Running the installer, I got the usual windows stopped you from running
> something risky, and navigating past that, the installer immediately hung.
> I can see that there is a window titled 'Window Dialog (Not Responding)'
> active, but It is minimised or not shown.
>
> Spoke too soon - after approx 11 minutes in this state the installer
> appeared.
> After that delay the installer ran very quickly.
> I have a strong feeling/hunch/intuition that there has been something
> wrong with the windows installer w.r.t. the ooDialog Guide documentation
> that appears to be fixed now - well done.
>
> Hope that is helpful.  I will test and report.
>
> Jon
>
>
> On Thu, 22 Dec 2022 at 12:20, Rony G. Flatscher 
> wrote:
>
>> Dear Jon,
>>
>> On 22.12.2022 12:56, Sahananda Sahananda wrote:
>> > Sorry to have been absent during the effort that has gone on over the
>> last week or so.  I have
>> > been unwell (really nasty cold).  I'm better now and have a bit of time
>> if there are any tasks
>> > that fit my limited skillset.
>>
>> thank you very much for your offer!
>>
>> It would be helpful at this stage, if you could express your opinion,
>> especially when questions get
>> asked! :)
>>
>> But also, if you could download, install and run those installation
>> versions from
>> <
>> https://sourceforge.net/projects/oorexx/files/oorexx/5.0.0_Release_Candidate/>
>> that match your
>> operating system. If you encounter something that looks strange or any
>> experiences, impressions and
>> communicate them would be great!
>>
>> Also (not yet had time to look into it), if portable versions of the
>> release candidates can be
>> created and uploaded (the suggested sub-directory would be "portable") it
>> would be great, if you
>> could test them on your platform. (The portable versions are
>> zip-archives, one containing the
>> binaries only, one containing in addition the documentation and samples,
>> per operating system. They
>> are meant to be portable on an e.g. USB stick such that one can run
>> ooRexx off the stick; also it
>> would allow for unzipping them on a harddisk and run ooRexx from there.
>> There is a readme.txt going
>> with them explaining how to set up the environment with the supplied
>> scripts for the portable
>> version to function from any location.)
>>
>> Best regards
>>
>> ---rony
>>
>>
>>
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Preparing the release

[Sahananda Sahananda]

Hi.

I downloaded ooRexx-5.0.0-12558.windows.x86_32 from the release candidate
folder.  It was a bit hard choosing which file to download as there were
multiple x86_32 files with different release levels, and none with the
highest release level.

Running the installer, I got the usual windows stopped you from running
something risky, and navigating past that, the installer immediately hung.
I can see that there is a window titled 'Window Dialog (Not Responding)'
active, but It is minimised or not shown.

Spoke too soon - after approx 11 minutes in this state the installer
appeared.
After that delay the installer ran very quickly.
I have a strong feeling/hunch/intuition that there has been something wrong
with the windows installer w.r.t. the ooDialog Guide documentation that
appears to be fixed now - well done.

Hope that is helpful.  I will test and report.

Jon


On Thu, 22 Dec 2022 at 12:20, Rony G. Flatscher 
wrote:

> Dear Jon,
>
> On 22.12.2022 12:56, Sahananda Sahananda wrote:
> > Sorry to have been absent during the effort that has gone on over the
> last week or so.  I have
> > been unwell (really nasty cold).  I'm better now and have a bit of time
> if there are any tasks
> > that fit my limited skillset.
>
> thank you very much for your offer!
>
> It would be helpful at this stage, if you could express your opinion,
> especially when questions get
> asked! :)
>
> But also, if you could download, install and run those installation
> versions from
> <
> https://sourceforge.net/projects/oorexx/files/oorexx/5.0.0_Release_Candidate/>
> that match your
> operating system. If you encounter something that looks strange or any
> experiences, impressions and
> communicate them would be great!
>
> Also (not yet had time to look into it), if portable versions of the
> release candidates can be
> created and uploaded (the suggested sub-directory would be "portable") it
> would be great, if you
> could test them on your platform. (The portable versions are zip-archives,
> one containing the
> binaries only, one containing in addition the documentation and samples,
> per operating system. They
> are meant to be portable on an e.g. USB stick such that one can run ooRexx
> off the stick; also it
> would allow for unzipping them on a harddisk and run ooRexx from there.
> There is a readme.txt going
> with them explaining how to set up the environment with the supplied
> scripts for the portable
> version to function from any location.)
>
> Best regards
>
> ---rony
>
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad copyright string

[Sahananda Sahananda]

It reads better WITH the comma imho, but then, who reads it?

Jon

On Thu, 22 Dec 2022 at 16:53, Rony G. Flatscher 
wrote:

> While creating a little script that does bulk updates to the copyright
> statements in all files I noticed that there are two styles in use, one
> with a comma immediately following the year portion, one without that
> comma, e.g.:
>
> ooconsole/en-US/ooconsole.xml:10:# Copyright (c) 2014-2014 Rexx Language 
> Association. All rights reserved.
>   ootest/en-US/testoorexx.xml:10:# Copyright (c) 2005-2014*,* Rexx 
> Language Association. All rights reserved.
>
> Which form should the updated copyright string take, with the comma or
> without the comma after the year portion?
>
> ---rony
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] Preparing the release

[Sahananda Sahananda]

Hi All,

Sorry to have been absent during the effort that has gone on over the last
week or so.  I have been unwell (really nasty cold).  I'm better now and
have a bit of time if there are any tasks that fit my limited skillset.

Jon
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Ad "Sir Santa's Bag for 2022" ...

[Sahananda Sahananda]

+1

Jon

On Sat, 10 Dec 2022 at 22:34, René Jansen  wrote:

> Me too. Let’s do it!
>
> René.
>
>
> On 10 Dec 2022, at 18:21, P.O. Jonsson  wrote:
>
> I am in favor of making an official release of ooRexx 5; It is building
> without error on all platforms on Jenkins and with the exception of a few
> glitches due to testing in a VM all tests pass on all platforms. In
> particular Windows 10 and macOS Monterey pass all tests.
>
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se
>
>
>
>
> Am 08.12.2022 um 14:41 schrieb Rony G. Flatscher  >:
>
> The post  on the
> Linux on Z mailing list points the programmers to a set of updated
> programs. It is interesting among other things to note that it includes
> ooRexx! :)
>
> It is ooRexx 4.2 though, which was released on  2014-02-24, almost nine
> and three quarters of a year ago.
>
> The current ooRexx 5.0*beta* has many bugs of ooRexx 4.2 fixed, it has
> many more and very useful features, and it is noticeably faster! So - we
> all know that here - ooRexx 5.0*beta* would be definitely a huge
> improvement to anyone who has been using and deploying ooRexx 4.x!
>
> Why not create a release "ooRexx 5.0" from the current trunk and remove
> "beta" from it? Continue with enhancing and fixing ooRexx 5.0 and have at
> least once a year a new version to be dubbed a "release" when it passes the
> ooRexx test suite without any show-stopper errors (preferably right before
> the yearly International Rexx Symposium).
>
> Or maybe even a "rolling release": whenever changes occur, but the test
> suite passes without any show-stopper errors, place it in a release folder
> on SourceForge rather than in a beta folder. This way anyone - including
> companies - have the ability to download and use the latest version being
> sure that the test-suite ran without any show-stopper errors. It would also
> allow for an "up-to-date" feeling and having the world see that it gets
> continually enhanced!
>
> If ooRexx 5.0 just had lost the word "beta" in it I am quite sure that the
> poster of "Sir Santa's Bag for 2022" would have included ooRexx 5.0 instead
> of the almost ten year old 4.2 version. Linux on Z user would then had been
> able to take advantage of all those great enhancements and improvements in
> ooRexx 5.0.
>
> All it would take is a consensus among the developers and decide which
> version (the trunk version?) should be picked for a formal release to
> signal the world that it is good enough to be used in production.
>
> ---rony
>
>
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Error in array class with two dimensional arrays ?

[Sahananda Sahananda]

I'm sure Rony would answer this when it's daytime in Austria, but It might
help speed things up if I say that my mail client (gmail) does not render
the oblique strokes that you ask about, but does render the text between
them as italics.

hth

On Fri, 10 Jun 2022 at 23:23, Jeremy Nicoll 
wrote:

> On Sat, 4 Jun 2022, at 14:25, Rony G. Flatscher wrote:
> > Given the following Rexx program:
> >
> > a=.array~new
> > /a[1,1]="a"//* first usage, makes array a two dimensional array
> */
>
> What does enclosing a statement in "/" characters mean?
>
> --
> Jeremy Nicoll - my opinions are my own.
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] Do we have instructions for setting up SVN (preferably with Tortoise)

[Sahananda Sahananda]

Hi guys,

It's a few years since I had SVN set u on my laptop.  Do we have a guide
somewhere?

thanks,

Jon
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Signal on syntax

[Sahananda Sahananda]

Hi Walter

I'm not sure I see what your problem is.  This is a good way of validating
dates and I have used it often in production.  Nowadays I use the datetime
class rather than the date BIF, but I found some code that used the TIME
BIF, that shows the principle.

HTH Jon

::routine good_time public
use strict arg time, form = 'n'

signal on syntax name bad_time
   t = time('n',time,form)
signal off syntax

RETURN .true

bad_time:
signal off syntax
RETURN .false


On Mon, 24 Jan 2022 at 21:27, WalterPachl via Oorexx-devel <
oorexx-devel@lists.sourceforge.net> wrote:

> Surprise of the day/nite;
> > -- Ursprüngliche Nachricht --
> > Von: WalterPachl 
> > An: TSO REXX Discussion List , Irwin Poché <
> ipo...@ix.netcom.com>
> > Datum: 24.01.2022 22:22
> > Betreff: Re: [TSO-REXX] Validating Dates
> >
> >
> > Try this and tell us what TSO says
> > I am astonished that Regina reacts nicely and ooRexx does not
> >
> > signal on syntax
> > userDate = "14/01/22"
> > ok = date("B",userDate,"U")
> > back: Say 'we are back'
> > Exit
> > syntax:
> > Say 'C' condition('C')
> > Say 'D' condition('D')
> > Say 'E' condition('E')
> > Say 'I' condition('I')
> > Say 'S' condition('S')
> > Signal back
> >
> > H:\>regina vd
> > C SYNTAX
> > D Error 40.19: DATE argument 2, "14/01/22", is not in the format
> described by argument 3, "U"
> > E 40.19
> > I SIGNAL
> > S OFF
> > we are back
> >
> > H:\>rexx vd
> > C SYNTAX
> > D
> > 9 *-* Say 'E' condition('E')
> > Error 40 running H:\vd.rex line 9: Incorrect call to routine.
> > Error 40.904: CONDITION argument 1 must be one of ACDIORS; found "E".
> >
> >
> > > Irwin Poché  hat am 24.01.2022 21:47
> geschrieben:
> > >
> > >
> > > I have never used the CALL ON / SIGNAL ON handlers and I’m wondering
> if they can be used to assist validating user inputed dates.
> > >
> > > The statement that would trigger the trap would be something like…
> > >
> > > userDate = “14/01/22”
> > > ok = date(“B”,userDate,”U”)
> > >
> > > …where userDate ought to be a MM/DD/YY date. If it’s not, then the
> exec is terminated with “Incorrect call to routine”
> > >
> > > The DATE function feels like the perfect way to validate dates if the
> exec can be prevented from being terminated.
> > >
> > > I’ve used all the permutations of CALL ON / SIGNAL ON I can think of.
> None are working so this looks like a dead end.
> > >
> > > If this is a dead end is there any simple way to validate a date ?
> > >
> > > -Irwin
> > >
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Question ad changes to ProgramMetaData.{c|h}pp

[Sahananda Sahananda]

Hi Erich,

Can you just be clear for my understanding please.
Are you saying that Rony should not change the METAVERSION from 42 to 43,
and should leave it at 42?

thanks,

Jon

On Mon, 24 Jan 2022 at 14:04, Erich Steinböck 
wrote:

> Rony,
> METAVERSION was already changed to 42 for 5.0
> no double patch please
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Reusing an instance of the .Stream class

[Sahananda Sahananda]

Hi Leslie,

Why would you want/need to do that?

Jon

On Fri, 29 Oct 2021 at 02:18, J Leslie Turriff  wrote:

> Supposing I want to write several different files, one after
> another.  I would use a
> sequence like
>
> | fileName1 = 'file1.txt'
> | fileStream = .Stream ~ new(fileName)
> | fileStream ~ open(write replace)
> | fileStream ~ arrayOut(someArray)
> | fileStream ~ close
>
> for the first file.  Now, do I have to create a new, different stream
> instance for
> fileName2, or can I reuse fileStream somehow?  There seems to be no way to
> associate
> fileStream with a different file, e.g. fileName2.
>
> Leslie
>
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Regarding API samples, thoughts and suggested changes

[Sahananda Sahananda]

It's not an area that I'm competent to comment on, beyond thanking you for
your rigorous look at this.

Jon

On Mon, 18 Oct 2021, 12:10 Rony G. Flatscher, 
wrote:

> Sleeping over the current structure of the API samples these are the
> things that are in place currently:
>
>1. samples/Makefile.am (???)
>2. samples/native.api/call.example/ ... for all systems,
>CMakeLists.txt, Makefile.linux, Makefile.windows, Makefile.am (???)
>3. samples/unix/api/callrexx/ ...  callrexx1.cpp, callrexx2.c,
>CMakeLists.txt, no Makefiles
>4. samples/unix/api/wpipe{1..3}/... rexxasp{1..3}.c,
>aspitest{1..3}.rex, CMakeLists.txt, no Makefiles
>5. samples/windows/ ... api/ ... misc/ ... ole/ ... oodialog/
>...rexutils/
>6. samples/windows/api/ ... callrxnt/ ... callrxwn/ ... rexxexit/
>7. samples/windows/api/wpipe{1..3}/ .. rexxapi{1..3}.c,
>apitest{1..3}.rex, CMakeLists.rex, nmake make files named rexxapi{1..3}.mak
>
> Suggested changes:
>
> 1. It seems that the "Makefile.am" files are left-overs and can be safely
> deleted?
>
> 2. create a new structure for the installed api samples, such that the
> installation on all systems would look like:
>
> samples/api
> samples/api/classic/ ... having all samples in their own directories that
> exemplify the SAA API interface, rexxapi.pdf, "Chapter 2. Classic Rexx
> Application Programming Interfaces"
> samples/api/c++/ ... having all samples in their own directories that
> exemplify the ooRexx native API interface, rexxapi.pdf, "Chapter 1. Rexx
> C++ Application Programming Interfaces"
>
> 3. rename "wpipe{1..3}" directory names to "rexxapi{1..3]" to match the
> names of the programs therein for all systems ("wpipe" is confusing)
>
> 4. Unix, rename "rexxsp{1..}.c" to "rexxapi{1..3}.c" and
> "aspitest{1..3].rex" to "apitest{1..3].rex"  to match the Windows names
> ("asp" does not make any sense in this context); sample change done with
> "wpipe1"
>
> 5. Add Makefiles where there are missing, such that interested programmers
> can try compiling and running the samples on their own (e.g. missing for
> the Unix wpipe samples
>
> 6. Add "readme.txt" files in each api directory to briefly describe its
> content
>
> In addition I propose to add the c++ samples of the 2015 RexxLA
> presentation of how to create external routines and external methods, cf.
> 
> , the talk with the
> code samples entitled "How to Develop a Native Library in C++ for ooRexx in
> a Nutshell".
>
> The easier it becomes for programmers to understand how the APIs work the
> better.
>
> Any comments?
>
> ---rony
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Creating USB stick versions

[Sahananda Sahananda]

I agree with all that Jeremy says.

Jon

On Sun, 10 Oct 2021 at 15:41, Jeremy Nicoll 
wrote:

> On Sat, 9 Oct 2021, at 14:01, Rony G. Flatscher wrote:
>
> > The stick versions should be zip archives that users can unzip
> > change into the bin-directory and run that version of ooRexx
> > off that directory without the need of an installation.
>
> I like that idea a lot.
>
> Perhaps it would also allow people easily to test whether a new
> build fixed a problem, without having to uninstall their main
> instance of ooREXX?
>
> Also, I periodically contemplate writing code that I know some
> of my non-technical friends could use.  But I know they'd never
> be willing to install ooREXX to do so.  They might be willing to
> grab a zip containing an instance of ooREXX and my program
> though.
>
> Right now I tend to end up thinking "it'll have to be written in
> something they already have", eg VBS.   But I code in VBS so
> rarely that it takes me lots longer to do & most often I never
> get started.
>
> --
> Jeremy Nicoll - my opinions are my own.
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Planned commits

[Sahananda Sahananda]

To be fair to Rony, he is not the only one keen to have a release and he
has suggested holding back some features for a subsequent release.

I won't rehash the reasons why we need a release - I think we are all
familiar with them.

So, can I suggest that we mark this enhancement (which I think is very
important, but not as important as ending the beta state of 5.0.0) for
5.0.1 And release 5.0.0 as soon as we can?

Jon



On Wed, 15 Sep 2021, 23:15 Rick McGuire,  wrote:

> Since you are the one pushing to get 5.0 released, why are you adding new
> features to the interpreter at this point? I'm OK with the MacOS changes,
> but I'm against adding any new features to 5.0.
>
> Rick
>
> On Tue, Sep 14, 2021 at 12:19 PM Rony G. Flatscher <
> rony.flatsc...@wu.ac.at> wrote:
>
>> As long as there is no architecture review board (ARB) in effect and
>> developers in "land under water" mode that hinders them to communicate, I
>> would like to apply the classic rule: "silence counts as approval" for the
>> following planned changes/patches:
>>
>>- concurrency trace: this is a tested, important feature as it is for
>>the first time that one becomes able to really trace concurrently 
>> executing
>>Rexx programs; this is especially helpful for students who learn
>>programming and must apply their acquired skills also in mastering
>>concurrently executing Rexx programs (e.g. when debugging GUI applications
>>from awt/swing and/or JavaFX); in this context also the documentation 
>> needs
>>to be supplemented which I would do (in the area of the existing RXTRACE
>>section in rexxref.pdf), RFE with patch:
>>
>>,
>>
>>- extract and commit the CMake definitions from Enrico's patch to
>>allow ooRexx on MacOS to be optionally built as a universal binary such
>>that ooRexx can run with the same binary on Intel and M1 computers.
>>
>> Will wait at least a week such that there is enough time for
>> consideration and communication.
>>
>> ---rony
>>
>> P.S.: Also, if time permits (unfortunately I am also in "land under
>> water" mode myself) I would like to add the ability to create
>> "stick"-versions of ooRexx, such that up-to-date versions can be created
>> each time ooRexx gets compiled.
>>
>>
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Problem in a multihreaded environment with the change from the guarded method default of expose-less methods to unguarded ...

[Sahananda Sahananda]

Rony,

Thanks for taking care of that.  Sorry I started this.

Jon

On Thu, 12 Aug 2021, 13:26 Rony G. Flatscher, 
wrote:

> Backed out and as a reslut rejecting RFE 720, cf.
> 
> .
>
> ---rony
> On 11.08.2021 13:21, Rony G. Flatscher wrote:
>
> On 10.08.2021 18:07, Rick McGuire wrote:
>
> No, this is way too complicated to add. It would be better to just back
> out the feature, which was only added under the assumption that there was
> no detectable effect in doing so. The guarded/nonguarded state clearly
> protects more than just the variable state of the object, it also
> synchronizes the order of invocations of any methods called from within the
> method.
>
> +1
>
> So would revert the changes applied as recorded in
> 
>  in reverse order
> from the svn root, like:
>
> svn merge -r 12141:12140 .
> svn ci -m "Backed out r12141."
>
> svn merge -r 12006:12005 .
> svn ci -m "Backed out r12006."
>
> Would that be the correct sequence?
>
> Anything to watch out, any suggestions otherwise?
>
> ---rony
>
>
> On Tue, Aug 10, 2021 at 11:30 AM Rony G. Flatscher <
> rony.flatsc...@wu.ac.at> wrote:
>
>> To keep the best of both worlds I propose to allow to activate this
>> particular feature (defaulting methods to unguarded if the first statement
>> neither starts with EXPOSE nor with USE LOCAL) with a new option
>> "unguarded" on the options directive, i.e.:
>>
>> ::options unguarded
>>
>> Enclosed please find the intended patch (tested) with request for
>> comment.
>>
>> Will update the documentation (rexxref) and the method directive test
>> unit accordingly.
>>
>> ---rony
>>
>> P.S.: With the patch applied the following program:
>>
>> say 'OPTIONS UNGUARDED set ...'
>>
>> do i=1 to 5
>>m=.Test1~method("M"i)
>>say "m"i"~isGuarded:" m~isGuarded
>> end
>>
>> ::options unguarded
>>
>> ::class Test1
>>
>> ::method m1
>>  say 'm1'
>>
>> ::method m2
>>   expose a
>>
>> ::method m3
>>   use local
>>
>> ::method m4 guarded
>>
>> ::method m5 unguarded
>>
>>
>> will yield the following (expected) output:
>>
>> OPTIONS UNGUARDED set ...
>> m1~isGuarded: 0
>> m2~isGuarded: 1
>> m3~isGuarded: 1
>> m4~isGuarded: 1
>> m5~isGuarded: 0
>>
>> Without the new "unguarded" subdirective of the options directive in
>> effect method m1 will be guarded by default (the original behavior).
>>
>>
>> On 07.08.2021 18:28, Rony G. Flatscher wrote:
>>
>> Sleeping and thinking more over it I would suggest to remove this feature
>> altogether! The major reasing being that the Rexx philosophy (and ooRexx by
>> extension) should make coding as easy as possible for programmers.
>>
>> The default for methods (and related) has always been "guarded" such that
>> one would not have to write "guarded" to the method directive. With that
>> default only in very rare cases (in multithreaded scenarios) would one have
>> to write "unguarded" to a method directive. And if doing so one must have
>> an understanding of multithreading and the ramifications if someone would
>> want a method to run unguarded.
>>
>> Compare this to the current situation with this new feature on: in order
>> to fix BSF.CLS  all of a sudden I had to add the keyword "guarded" to every
>> method to gain the default behaviour for ooRexx < 5.0 and thereby
>> re-enabling correct execution of GUI nutshell examples.
>>
>> Ad feature: originally it was thought to be helpful to programmers by
>> saving the programmers to write "unguarded" to a method directive for a
>> method that is known to be safe in unguarded mode thinking that methods
>> that have no direct access to the attribute pool (i.e. the method routine
>> would not start with "expose" or "use local") qualify for unguarded
>> execution not thinking about scenarios where this is not enough.
>>
>> To make it easy for the programmer (i.e. not having to know additional,
>> sometimes quite subtle, concepts that play a role in this context) I would
>> be in a strong favor to leave the default "guarded" in place. Then either
>> remove this new feature altogether or make it an explicit option a
>> programmer has to state ("::OPTIONS" with a new pair "guarded|unguarded").
>>
>> What opinions have others? Do you concur?
>>
>> ---rony
>>
>>
>> On 06.08.2021 15:09, Rony G. Flatscher wrote:
>>
>> Background: In order for ooRexx programmers getting acquainted with
>> BSF4ooRexx/Java quickly there are numerous nutshell examples in
>> "bsf4rexx/samples". Most of these nutshell examples stem from observations
>> of students over time who should get help by demonstrating them how to
>> achieve something of interest with these (mostly brief) nutshell examples.
>>
>> One interesting problem has been the interaction from ooRexx with GUI
>> objects which must be carried out on the GUI threads in Java (the "awt
>> thread" or 

Re: [Oorexx-devel] Problem in a multihreaded environment with the change from the guarded method default of expose-less methods to unguarded ...

[Sahananda Sahananda]

Hi Guys,

This is awkward, I think this change was made in response to my expressing
surprise that the guard made a difference to methods which have no
variables exposed - something that I still don't understand, but have no
need to understand.  However, if you think it should go, then I'm content
for it to go.

BTW, and just for correctness sake, I think the default guard state was
changed before, sometime in version 3.x I think.  I remember that I had to
change all my oodialog message handling methods to be explicitly unguarded.

Jon

On Sat, 7 Aug 2021, 18:36 Jean Louis Faucher,  wrote:

> +1
>
> If you run the example 12.4 of rexxref, you will see that it breaks the
> rule written just above.
>
>
> Regards
>
> On 7 Aug 2021, at 18:28, Rony G. Flatscher 
> wrote:
>
> Sleeping and thinking more over it I would suggest to remove this feature
> altogether! The major reasing being that the Rexx philosophy (and ooRexx by
> extension) should make coding as easy as possible for programmers.
>
> The default for methods (and related) has always been "guarded" such that
> one would not have to write "guarded" to the method directive. With that
> default only in very rare cases (in multithreaded scenarios) would one have
> to write "unguarded" to a method directive. And if doing so one must have
> an understanding of multithreading and the ramifications if someone would
> want a method to run unguarded.
>
> Compare this to the current situation with this new feature on: in order
> to fix BSF.CLS  all of a sudden I had to add the keyword "guarded" to every
> method to gain the default behaviour for ooRexx < 5.0 and thereby
> re-enabling correct execution of GUI nutshell examples.
>
> Ad feature: originally it was thought to be helpful to programmers by
> saving the programmers to write "unguarded" to a method directive for a
> method that is known to be safe in unguarded mode thinking that methods
> that have no direct access to the attribute pool (i.e. the method routine
> would not start with "expose" or "use local") qualify for unguarded
> execution not thinking about scenarios where this is not enough.
>
> To make it easy for the programmer (i.e. not having to know additional,
> sometimes quite subtle, concepts that play a role in this context) I would
> be in a strong favor to leave the default "guarded" in place. Then either
> remove this new feature altogether or make it an explicit option a
> programmer has to state ("::OPTIONS" with a new pair "guarded|unguarded").
>
> What opinions have others? Do you concur?
>
> ---rony
>
>
> On 06.08.2021 15:09, Rony G. Flatscher wrote:
>
> Background: In order for ooRexx programmers getting acquainted with
> BSF4ooRexx/Java quickly there are numerous nutshell examples in
> "bsf4rexx/samples". Most of these nutshell examples stem from observations
> of students over time who should get help by demonstrating them how to
> achieve something of interest with these (mostly brief) nutshell examples.
>
> One interesting problem has been the interaction from ooRexx with GUI
> objects which must be carried out on the GUI threads in Java (the "awt
> thread" or the "JavaFX Application thread"). Although they got the
> necessary information about the architecture and what to do in ordert to
> become able to send messages on GUI threads, they kept running into
> problems, losing a lot of time (even months because they could not get it
> working in more complex programs).
>
> To make a long story short, I came up with a message based solution, that
> was very easy to understand and to employ for them. None of the students
> ran into the GUI thread problems since then.
>
> The solution is an ooRexx class for awt (the Java "abstract windows
> toolkit") named .AwtGuiThread and for JavaFX (a powerful GUI system)
> .FxGuiThread, both subclassing a common superclass .AbstractGuiThread.
> These classes allow one to send the ooRexx message
> runLater[Latest](GUIreceiver, messageName, arguments) which get queued and
> dispatched on the GUI thread later.
>
> The nutshell examples
> "bsf4rexx/samples/3-090_update_awtSwing_GUI-from-non-GUI-thread.rxj" and
> "bsf4rexx/samples/JavaFX/javafx_update_GUI-from-non-GUI-thread.rxj"
> demonstrate how to employ this infrastructure. They have been working for
> years without a problem.
>
> While working on BSF4ooRexx I stumbled over an error (not having run those
> two examples for quite some time) which seems to indicate that ooRexx now
> creates an error when being used from different threads:
>
> F:\work\svn\bsf4oorexx\trunk\bsf4oorexx\samples>3-090_update_awtSwing_GUI-from-non-GUI-thread.rxj
> screenSize: [java.awt.Dimension[width=1920,height=1080]]
> winSize   : [java.awt.Dimension[width=800,height=200]]
> xPos=[560] yPos=[440]
> a REXXEVENTHANDLER::actionPerformed - starting Rexx thread
> The SOME_REXX_CLASS class::updateGuiFromRexxThread - just arrived, GUI 
> thread: 23808
> The SOME_REXX_CLASS class::updateGuiFromRexxThread - now running on threa

Re: [Oorexx-devel] need help on eliminating an error on a ::REQUIRES statement

[Sahananda Sahananda]

otherwise, you can replace the requires directive with a call in your code

parse source os .
if os = 'WindowsNT' then call 'Winsystm.cls'

hth Jon

On Sun, 4 Apr 2021 at 18:12, Enrico Sorichetti via Oorexx-devel <
oorexx-devel@lists.sourceforge.net> wrote:

> NO to both questions
>
> I had the same need and a one liner solved the problem
> As … one line of useful code
>
> The source code
>
> /* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> */
> #include 
> #include 
> #include 
> #include 
> #include 
>
> #include "oorexxapi.h"
>
> /* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> */
> RexxRoutine1( logical_t, rxLoader, CSTRING, L )
> {
>   return ( context->LoadLibrary( L ) );
> }
>
> /* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> */
> RexxRoutineEntry rxLoader_functions[] =
> {
>   REXX_TYPED_ROUTINE( rxLoader, rxLoader ),
>   REXX_LAST_ROUTINE()
> } ;
>
> RexxPackageEntry rxLoader_package_entry =
> {
>   STANDARD_PACKAGE_HEADER
>   REXX_INTERPRETER_5_0_0,
>   "rxLoader", "1.0.0",
>   NULL, NULL,
>   rxLoader_functions,
>   NULL
> } ;
>
> OOREXX_GET_PACKAGE( rxLoader ) ;
>
>
>
> How to use it
> ...
> ...
> ...
>
> lib = "somelibrary"
> if  \ rxloader( lib  ) then do
> say "'"this"' error loading library '"lib"'"
> exit ( -1 )
> end
> ...
> ...
> ...
>
> /*  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - -
> */
> ::requires "rxloader" library
>
>
>
>
> On 4 Apr 2021, at 18:56, Bill Turner, WB4ALM  wrote:
>
> Is there a way to
> (1) conditionally control the execution of the ::REQUIRES statement or
> (2) Trap that specific error so that t can be ignored?
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Statusreport new testGroups

[Sahananda Sahananda]

David Ashley sent me the source for his build machine if it is of any help
or interest.

Jon

On Wed, 24 Mar 2021 at 21:52, P.O. Jonsson  wrote:

> Since the Jenkins Master machine is in my corner I could give it a try, I
> use Virtualbox and have built on various Linux, would Virtualbox be an
> acceptable solution? If so I would gladly work with Enrico on this, (after
> I reworked the samples test cases that is).
>
> I have tried to use Dockers for the same purpose but could not make it
> work from remote. For Dockers someone else will need to do the work.
>
> I also noted that in one document „Buildmachine“ (BuildooRexx internal
> name) in the documentation that we are currently not building there are
> such plans already in 2007, in fact the system is quite similar to what we
> have.
>
>
> And you may be surprised to hear that this setup works quite well almost
> 15 year later :-)
>
>
> Hälsningar/Regards/Grüsse,
> P.O. Jonsson
> oor...@jonases.se
>
>
>
> Am 24.03.2021 um 22:32 schrieb Enrico Sorichetti via Oorexx-devel <
> oorexx-devel@lists.sourceforge.net>:
>
>
> Unfortunately there is quite a bit of work to do to support
> The systems in the BSD family
>
> I know because
> A a bit more than two years ago I made all the modifications to support
> FreeBSD, OpenBSD, netBSD, dragonfly
> And run the testSuite with only a couple of minor glitches
>
> I talked  about it i but nobody seemed interested
>
> I will have to look at the time machine backups,
> To find the repositories with the modifications
>
> And publish them again on GitHub
>
> enrico
>
> An excerpt from an old email I exchanged with Rony and PO
>
> FreeBSD
>
> [vagrant@freebsd ooRexx.testSuite]$rexx testOORexx.rex -s -X native_API
> -x FUNCTION.testGroup
>
> ooTest Framework - Automated Test of the ooRexx Interpreter
>
> Interpreter:REXX-ooRexx_5.0.0(MT)_64-bit 6.05 11 Feb 2019
> OS Name:FREEBSD
> SysVersion: FreeBSD FreeBSD 12.0-STABLE r341991 GENERIC.12.0-STABLE
>
> Tests ran:  22579
> Assertions: 376974
> Failures:   0
> Errors: 0
>
> File search:00:00:01.555107
> Suite construction: 00:00:01.275722
> Test execution: 00:03:45.116683
> Total time: 00:03:48.470149
>
>
> OpenBSD
>
> [vagrant@openbsd ooRexx.testSuite]$rexx testOORexx.rex -s -X native_API
> -x FUNCTION.testGroup
>
> ooTest Framework - Automated Test of the ooRexx Interpreter
>
> Interpreter:REXX-ooRexx_5.0.0(MT)_64-bit 6.05 11 Feb 2019
> OS Name:OPENBSD
> SysVersion: OpenBSD GENERIC.MP#364.6.4
>
> Tests ran:  22579
> Assertions: 377044
> Failures:   0
> Errors: 0
>
> File search:00:00:02.112482
> Suite construction: 00:00:01.635886
> Test execution: 00:04:40.743375
> Total time: 00:04:45.000832
>
>
> On 24 Mar 2021, at 21:58, Erich Steinböck 
> wrote:
>
> OpenBSD
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Adaptations for the macOS Installer

[Sahananda Sahananda]

>
>
>> Q7: Is the contact mail sahana...@users.sf.net for macOS still correct?
>> Probably not. It would be better if a contact email were a
>> project-specific one (perhaps one of the mailing lists) rather than a
>> specific individual.
>
>
> I hadn't realised this was the case, and I can't remember receiving any
email from this.
It is tricky specifying one of the lists as they require subscription - I'm
not sure what to do.  I'm not in a position to really help the development
effort at the moment, but I can certainly forward a trickle of emails to
the developers or users list if that helps.

Jon






On Sun, 7 Feb 2021 at 22:58, Rick McGuire  wrote:

>
>
> On Sun, Feb 7, 2021 at 5:34 PM P.O. Jonsson  wrote:
>
>> Following Ricks advice I am looking how and where to put the additional
>> files for the macOS installer in the SVN tree.
>>
>> In oorexxSVN/platform/unix/macosx there are 3 files related to the (now
>> broken) packagemaker for macOS.
>>
>> Q1: Can I put macOS specific files there?
>>
> Yes, either there, or create a platform/macosx directory. I can make
> strong arguments either way, but keeping an existing directory probably
> makes the most sense. There are no other places where we've created
> subdirectories specifically for macosx. It probably makes sense to consider
> it a sub-type of a unix OS.
>
> For Windows, all files related to the installer are put in
> platform/windows/install. It might be a good idea to use
> platform/unix/macos/install
>
> Q2: Shall I delete those files that are no longer used? or create a
>> subdirectory /obsolete?
>>
>> svn maintains information for all file deletions, so there's no need to
> keep old files around. If needed, they can be recovered at any time.
> Keeping them in the tree just adds noise to the process. Go ahead and
> delete them.
>
>
>> I also have a question about the ooRexx icon files. I have used a high
>> resolution (512X512 px) png version of the ooRexx logo to create the icon
>> file (icns file) for the macOS installer. It is similar to the png files
>> used here  (256X256 px png file) and
>> here  (png file 200X200 px) with the two "O"s
>> close to each-other. Since I am not sure where I have "my" file from I am
>> not sure if I can upload it or use it for icon file for the macOS.
>> Q3: What is the opinion on this?
>>
>> If you don't really know the pedigree of the icon you are using, then
> please don't use it. It should be easy to create a higher res version from
> existing resources.
>
>
>> I have looked in the SVN tree and in oorexxSVN/platform/unix there is a
>> low resolution file oorexx.png (48X48 px) used for Unix/Linux RPM and DEB
>> builds. This png is also referred to in CMakelists.txt in the (obsolete)
>> Cpack section #Apple macOS.
>>
>> Q4: Should this section be emptied? Or can someone clean it up? Who?
>>
> Yes, remove anything that no longer applies. As I stated earlier, svn
> never forgets so those sections can be recovered if they are needed.
>
>
>>
>> Q5: Should I include the "Package description" from this section of
>> CMakelists.txt in the Readme files for the installer?
>>
> It would be a good idea, if it makes sense. I just checked, and the
> Windows installer does not include this. Not sure if it is part of the
> other unix installer packages or not.
>
>
>>
>> Q6: Shall I include the Copyright Notice in the readme files?
>>
>> Yes. A copyright really should be in any plain text files.
>
>
>> Q7: Is the contact mail sahana...@users.sf.net for macOS still correct?
>>
>> Probably not. It would be better if a contact email were a
> project-specific one (perhaps one of the mailing lists) rather than a
> specific individual.
>
>
>> Any other things that need consideration?
>>
>>
> Does the installer you build also pick up things like release number, etc.
> from CMake? You might want to take a look at platform/windows/install/
> cpack.nsi.template.in to see the types of information the Windows
> installer pulls in from CMake. Any variable in that file that starts with
> '@" is information that is pulled in from cmake.txt file.
>
> Rick
>
>
>
>> Hälsningar/Regards/Grüsse,
>> P.O. Jonsson
>> oor...@jonases.se
>>
>>
>>
>> ___
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel