SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Wed, 18 Nov 1998 05:36:23 PDT
From:	dallasii@kincyb.com
Reply-To:	scoug-programming@scoug.com
To:	scoug-programming@scoug.com
Subject:	SCOUG-Programming: More2queue2stuff

PS>
PS> Date: Tue, 17 Nov 1998 06:09:23 PDT
PS> Reply-To: scoug-programming@scoug.com
PS> From: Peter Skye
PS> To: scoug-programming@scoug.com
PS> Subject: SCOUG-Programming: Queues\1b[1;33m2etc.\1b[0m
PS>
PS> dallasii@kincyb.com wrote:
PS> >
PS> > On further reflection (a muffin at a local doughnut shop),
PS> > maybe it would be better to replace the
PS> > stem variable with a queue altogether - download it in the
PS> > procedures to a stem variable for messy operations on individual
PS> > elements, then requeue them -
PS> > do you really need to have random access to the elements
PS> > most of the time? Maybe do away with my 'Global stack' idea,
PS> > and have the subroutines operate on some dedicated queues whose
PS> > names are passed to them.
PS>
PS> Interesting idea. I'm reading several small (200 lines or so) text
PS> files into the stem variables and then looping through them repeatedly.
PS> Some of the text files are "master" HTML files which contain tags where
PS> I insert links into a database (I generate one HTML page for every item
PS> in the database). One of the files is a "parameter" file that specifies
PS> things like fonts to be used in the HTML (there's a default section plus
PS> individual sections for every item category in the database). I don't
PS> need random access; I only have to read the files sequentially, albeit
PS> repeatedly.
PS>
PS> Where do you get these ideas? What was in that muffin?

Lots of bran. :-)

PS>
PS> > Actually I've been learning a lot from all this.
PS>
PS> I haven't used REXX queues; guess I'll have to take a look at them. The

I'm just starting to ReXX in OS/2 to any significance.
As I recall on the Big Iron at Rockwell, they were too cheap to update
all their OS stuff to REXX smart while I was there,
and to run any editor under REXX control I had to queue up the commands
and run the line editor. Things were somewhat different
in that OS, but not too far off.

PS> Warp 4 online help for REXX covers QUEUE, QUEUED and RXQUEUE, and from
PS> those three pages I deduce that I'd have to PUSH a line back into the
PS> queue every time I PULLed it out, and use some kind of a marker to

You're probably thinking QUEUE, not PUSH to put them at the bottom
after PULLing off the top, and you can roll through the thing,
but yeah...

PS> indicate when I was at the start/end of my data (sort of a circular
PS> buffer without random access or ability to start at the beginning).

That sounds OK to me.

PS>
PS> Eat another muffin and figure out how I can do this. :)

Here's some ideas:

when you put a line on the queue, put the element # on with it.
Maybe something like this:

QUEUE ::

PARSE PULL item_num '::' line_of_text
or
PARSE VALUE LINEIN(QUEUE:) WITH item_num '::' line_of_text

or maybe even: ( yeah, this looks like it works )

PARSE PULL item_num '::' line_of_text.item_num
or
PARSE VALUE LINEIN(QUEUE:) WITH item_num '::' item_num.item_num

I don't know right now if this last pair will work, but if it will, you
just have to put it in a DO loop to download the queue to a stem variable:

/* if you need all items at once, instead of one at a time */

CALL RXQUEUE 'SET', TextQueue
number_of_items=QUEUED()

DO number_of_items
PARSE PULL item_num '::' line_of_text.item_num
/* I just 'REXXTRIed it, and this looks like a go! */
/*
OR
PARSE PULL item_num '::' line_of_text /* if the above doesn't
LOT.item_num = line_of_text work */
*/

QUEUE item_num'::'line_of_text /* if only one at a time */

END

Do i = 1 to number_of_items
/* reload the queue with this loop if doing 'all at once action' */
QUEUE i'::'line_of_text.i
END

Now that I think about it, maybe the '.' will throw things off in the parse,
(no, apparently it doesn't)
but the general idea will still work one way or the other, just different
details.

The possible advantage of putting the line number is that you might
be able to search until you find a desired item, and just leave the
queue in a 'random' rolodexed position, instead of always
having to make sure you get it reset with item #1 on top and
the last at the bottom, before going on to something else.

And maybe when processing the queue, push the total item count on the
top of it and pull it off when you start processing it again.
Maybe put some special marker along with this count.
This might be redundant, since I think you could use the
QUEUED() function to get the total count when needed.

While developing, it might be a good idea, when creating the
queues, to generate a file with CALL RXQUEUE 'Delete',
for all opened queues, so if things crash you can clean up
the mess and avoid 'queue' memory leaks.
I'm not totally sure what resources these things use in OS/2,
and really how fast they are, but I don't know how to get
rid of them if you don't record the names when they are
created, except to shut down (I think!).

PS>
PS> - Peter Skye
PS>
SL>
SL> Date: Tue, 17 Nov 1998 09:11:46 PDT
SL> Reply-To: scoug-programming@scoug.com
SL> From: Steven Levine
SL> To: scoug-programming@scoug.com
SL> Subject: SCOUG-Programming: Queues\1b[1;33m2etc.\1b[0m
SL>
SL> In , on 11/17/98
SL> at 04:02 AM, dallasii@kincyb.com said:
SL>
SL> >with everything that they are going to hold before the pipe is started -
SL> >launching the pipe first, and reading the queue as data shows up is a
SL> >future project, and will definitly need some changes to the queue->pipe
SL>
SL> Both START and DETACH should work the same as long as the DETACH'ed
SL> session does not try to access STDIN/STDOUT. Can't say yet why you are
SL> seeing a difference.
SL>
SL> > works, but detach versions put the pipe into background, (as desired)
SL> > start versions hang in foregroud till completion, and then resume
SL> > execution. (not really desired)
SL>
SL> Are you using START /C? If so, drop the /C. If not, it's something else.

I just tried it without the '/C', and almost the same thing happened, it
didn't really go to background, just ran the pipeline, then the
outermost script just hung for good.

SL>
SL> >launching pipes into backgound execution from original .CMD interpreter
SL> >is getting pretty convoluted.
SL>
SL> I've seen some pretty big REXX applications, but unfortunately, with REXX
SL> larger means more global crosstalk and that makes maintenance and
SL> enhancements difficult.
SL>
SL> >one other major mismatch that I've encountered so far is accessing the
SL> >OS/2 FIND command - it seems to be an almost perfect syntax clash. So
SL> >far my kludge to use it renders it almost unrecognizable.
SL>
SL> Not to mention that the FIND finds files not text lines.

If there is an internal FIND for ksh, I think it is disabled on this port,
but there definitly is some confusion in getting the FIND.EXE to
run.

SL>
SL> Steven
SL>
SL> --
SL> -----------------------------------------------------------
SL> Steven Levine MR2/ICE #10183
SL> -----------------------------------------------------------
SL>
SL>

Regards,
Dallas E. Legan II
(562) 862 - 4854 ext. '*'

L
E
G
A
N
@
A
C
M
.
O
R
G

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================

Return to [ 18 | November | 1998 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.