From: René J. <rvj...@xs...> - 2022-06-03 08:27:33
|
> On 3 Jun 2022, at 04:53, hp...@we... wrote: > > ((Reply to a mail I missed)) >>> So once more without the ZIP -- René, IMO you got it in your >>> personal mail, holler if not. >>> >> I have it. > > Good. So you may take a closer look to the files VilMA uses or the > description of a "session". Probably this gives a bit more insight > than the bare REXX code only. > > I skip all "documentation" related issues, I know it's not easy to > find a description level that fits for a non-uniform target group. > >> I would suggest to use ’nrws’ (the Netrexx Workspace) for experiments with pipes. > > 'Netrexx Workspace' is neither mentioned in the NetRexx QuickStart > Guide nor in NetRexx Language Reference, there is a chapter about > it in NetRexx Programming Guide and one in NetRexx Pipelines Guide > and Reference. In that case I assume the Pipelines Guide will show > supplementary information only and all fundamentals about /nrws/ > are in the Programming Guide where I start. The Pipelines Guide shows some examples of how nrws is an apt environment for pipeline experimentation. The main nrws documentation is in the Programming Guide. I will make sure to refer to it from the Quickstart Guide and the Reference, but nrws was a late addition - it existed for 20 years already, and I came across it while starting to write a simple repl for NetRexx. It can do some nifty stuff of which I am using about 5%. On Windows an extra added value is that it logs your session in the nrws.history file; we have that standard on *nix from the shell. With the default (without a nrws.properties file in the home directory (the user home directory) I do not see the timings that I want to see, and it will not preload the pipeline classes - but this has changed in NetRexx 4.04.) > BTW, since decades on > VM/CMS now with ooRexx, I use a very simplest "type REXX on the > command line" tool, consisting of just three lines: > >> /* interactive REXX */ >> trace '?R' >> address '' > > Until I know how to run this with NetRexx I'll use 'nrws' -- which > shows something daunting at first try: > >> nrws> say hello initial 1 >> 2 +++ say hello; >> +++ ^^^^^ >> +++ Error: Result of this expression cannot be just a type; it must have a va >> lue > In NetRexx, there is no literal value of an undeclared string. If you look at the first VM manuals, those were all over them, and they disappeared from the examples and a ’signal on novalue’ was introduced. Following that trend they were removed from NetRexx. > This contradicts REXX principles of primary importance, at least > from my point of view. Fortunately we'll replace only the > pipelines, not the REXX dialect. > > BTW, the nrws description uses every now and then the term "home > directory", once even "top level home directory". May I assume > this is the same as I set at some point during installation > procedure in the NETREXX_HOME system variable (and the top level > home directory to be the same)? No, this is your home directory, I think in windows referred to as %HOME%. > > Now I slooowly start to grasp, what you sent recently had been > screen shots of a nrws session: > >> ➜ test git:(master) ✗ cat varset.nrx >> vars ='' >> address pipe with output stem vars >> "< vars.ini | nlocate 1 /*/ | cons" >> do i=1 to vars[0] >> say vars[i] >> end > No, these were just cats from a macOS terminal. To show source as the content of a file. > ...and so on. Did you read along "the Book" about varset at > http://vm.marist.edu/~pipeline/pipeline.pdf ? > I know it's dated, but -- hobbyist I am -- I'm removed from > Pipelines evolution ever since the Runtime Library Distribution > was updated for the last time. > Not yet, but I will today. Seems like a handy addition. > The comment for the pipe in line 94 of VilMA.rx is a silent hint, > that the nlocate stage is only necessary because OS/2 Pipelines > does not offer the COMMENTS option of varset. > >> So that does more or less what you want already - the source redirect <, the nlocate works. If you want we can make a varset stage, I think we don’t have that at the moment but it cannot be too hard. > > No, we should go all-in, if NetRexx Pipelines does not have a > varset stage yet it is a good test (for me to learn and for > NetRexx to point out) how to add those 'on the fly', analogous to > CMS Pipelines (filetype REXX). varset is almost something like > > signal on error > do forever > 'READTO record' /* don't mind delay */ > parse var record sc +1 vn (sc) sv > if pos(sc, "* ") > 0, /* see the COMMENT option */ > then iterate > upper vn /* optional, see also varload */ > dummy = value(vn, sv, ...) /* for variable pool of caller */ > end > error:; exit rc * (rc <> 12) /* or whatever rc is OK */ > > Well, I hope NetRexx Pipelines allows home-made stages like this. > Maybe this "take in INI file" pipe could then look something like: > Yes, certainly. The source of all the stages is in NetRexx. Did you check out the source from Github or SourceForge (I keep it in two places because it limits the exposure from outages). We keep all the stages in src/org/netrexx/njpipes/stages. Most are put together by Jeff Hennick so I hope he’ll join this conversation sometime. > NetRexx Pipe "<" fn "|varload symbolic" > > (see the differences in the defaults of varset and varload.) > > Best, > M. best regards, René. |