Discussion:
Calling Ghostscript from BASIC
(too old to reply)
Rob Hemmings (News)
2020-06-08 14:22:18 UTC
Permalink
It is ages since I've been programming so apologies if this is a silly
question.

Is there a way to call GhostScript from inside a BASIC program and return
control to the BASIC program afterwards? I've just tried invoking
GhostScript from a program using an OSCLI command but although
GhostScript then runs correctly it does not hand back control to the
BASIC program which just ends. I think I understand why it is happening
but is there any way to get around it?
--
-------------------------------------------------------------
Rob Hemmings Southport

***@dsl.pipex.com
Harriet Bazley
2020-06-08 14:39:04 UTC
Permalink
On 8 Jun 2020 as I do recall,
Post by Rob Hemmings (News)
It is ages since I've been programming so apologies if this is a silly
question.
Is there a way to call GhostScript from inside a BASIC program and return
control to the BASIC program afterwards? I've just tried invoking
GhostScript from a program using an OSCLI command but although
GhostScript then runs correctly it does not hand back control to the
BASIC program which just ends. I think I understand why it is happening
but is there any way to get around it?
Wimp_StartTask will launch a program from within BASIC, and will return
the task handle in R0 if successful.

SYS"Wimp_StartTask",cmd$ TO handle%


In Infozip, in order to avoid freezing the desktop I launched the
'child' task in a taskwindow, recorded the task handle as child%, then
listened in on Wimp_Poll for the Wimp message &400C3 (TaskCloseDown)
being broadcast in order to detect when the child had finished. This is
a fairly crude approach which only allows for one child task to be
running at a time.
--
Harriet Bazley == Loyaulte me lie ==

The attacker must vanquish; the defender need only survive.
Rob Hemmings (News)
2020-06-08 14:44:43 UTC
Permalink
Post by Harriet Bazley
On 8 Jun 2020 as I do recall,
Post by Rob Hemmings (News)
It is ages since I've been programming so apologies if this is a silly
question.
Is there a way to call GhostScript from inside a BASIC program and return
control to the BASIC program afterwards? I've just tried invoking
GhostScript from a program using an OSCLI command but although
GhostScript then runs correctly it does not hand back control to the
BASIC program which just ends. I think I understand why it is happening
but is there any way to get around it?
Wimp_StartTask will launch a program from within BASIC, and will return
the task handle in R0 if successful.
SYS"Wimp_StartTask",cmd$ TO handle%
In Infozip, in order to avoid freezing the desktop I launched the
'child' task in a taskwindow, recorded the task handle as child%, then
listened in on Wimp_Poll for the Wimp message &400C3 (TaskCloseDown)
being broadcast in order to detect when the child had finished. This is
a fairly crude approach which only allows for one child task to be
running at a time.
Thanks Harriet, that is very helpful.
--
-------------------------------------------------------------
Rob Hemmings Southport

***@dsl.pipex.com
Steve Fryatt
2020-06-08 15:19:57 UTC
Permalink
Post by Harriet Bazley
Wimp_StartTask will launch a program from within BASIC, and will return
the task handle in R0 if successful.
SYS"Wimp_StartTask",cmd$ TO handle%
Yes, this is pretty much how it works.
Post by Harriet Bazley
In Infozip, in order to avoid freezing the desktop I launched the
'child' task in a taskwindow, recorded the task handle as child%, then
listened in on Wimp_Poll for the Wimp message &400C3 (TaskCloseDown)
being broadcast in order to detect when the child had finished. This is
a fairly crude approach which only allows for one child task to be
running at a time.
This isn't a great idea, however, as it fails with at least one of the
popular TaskWindow providers (and ISTR that InfoZip has this problem,
although I'm not 100% certain). There's no guarantee when calling
Wimp_StartTask with *TaskWindow that the returned handle will be for the
task that you're interested in.

The better way is to check the handle returned from Wimp_StartTask to
make sure that it isn't zero, which tells you that something has
happened. Then listen out for Message_TaskInitialise, and check the names
of new tasks to see if they match the one that you're expecting to start
up. When you find it, you know the task handle from the sender field of
the message block.

The problem with taking the handle from Wimp_StartTask is that if the
registered TaskWindow provider is Zap, and Zap isn't running,
Wimp_StartTask returns the handle of another task, whose purpose seems to
be to get Zap up and running. This task starts the task that you're
after, and then exits immediately.

If you're listening for Message_TaskCloseDown, so that you can clean up
after the process, and match on the task handle from Wimp_StartTask, you
do the clean up just as your task is getting going. PrintPDF deletes the
intermediate PostScript file from the queue, and until I changed to the
more long-winded approach, it deleted the file just as GhostScript was
starting to read it if Zap wasn't loaded at the time.
--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/
Martin Wuerthner
2020-06-08 18:22:17 UTC
Permalink
Post by Steve Fryatt
Post by Harriet Bazley
Wimp_StartTask will launch a program from within BASIC, and will return
the task handle in R0 if successful.
SYS"Wimp_StartTask",cmd$ TO handle%
Yes, this is pretty much how it works.
Post by Harriet Bazley
In Infozip, in order to avoid freezing the desktop I launched the
'child' task in a taskwindow, recorded the task handle as child%, then
listened in on Wimp_Poll for the Wimp message &400C3 (TaskCloseDown)
being broadcast in order to detect when the child had finished. This is
a fairly crude approach which only allows for one child task to be
running at a time.
This isn't a great idea, however, as it fails with at least one of the
popular TaskWindow providers (and ISTR that InfoZip has this problem,
although I'm not 100% certain). There's no guarantee when calling
Wimp_StartTask with *TaskWindow that the returned handle will be for the
task that you're interested in.
The better way is to check the handle returned from Wimp_StartTask to make
sure that it isn't zero, which tells you that something has happened. Then
listen out for Message_TaskInitialise, and check the names of new tasks to
see if they match the one that you're expecting to start up. When you find
it, you know the task handle from the sender field of the message block.
That might be better, but there is still more guesswork involved and less
control than using the TaskWindow protocol, which was specifically designed
to allow tasks to control their TaskWindow children. Using this protocol
also makes you independent of any registered TaskWindow provider since your
application itself becomes the TaskWindow provider.

The key point is to launch the child by passing
TaskWindow <command> -wimpslot <slot> -name <name> -quit
-task <my_task_handle> -txt <arbitrary_id>
(obviously, all in one line) to Wimp_StartTask.

Then, you listen for the messages that TaskWindows sends to the given handle
(i.e., to your application since you passed your own task handle), most
notably TaskWindow_Ego, which tells your application the handle of your
child. If you run several children, you can distinguish them because the Ego
message quotes the arbitrary id you passed. TaskWindow_Morio tells you that
your child has died. While the child runs, you can suspend it, resume it and
kill it by sending messages TaskWindow_Suspend/Resume/Morite to your child
handle. By listening to TaskWindow_Output you can receive the output of your
child, e.g., any error messages from Ghostscript.

That is how GView (http://www.mw-software.com/software/gview/gview.html)
calls Ghostscript.
--
Martin Wuerthner MW Software http://www.mw-software.com/

------- RISC OS Software for Design, Printing and Publishing --------
Harriet Bazley
2020-06-08 20:15:33 UTC
Permalink
On 8 Jun 2020 as I do recall,
Martin Wuerthner wrote:

[snip]
Post by Martin Wuerthner
The key point is to launch the child by passing
TaskWindow <command> -wimpslot <slot> -name <name> -quit
-task <my_task_handle> -txt <arbitrary_id>
(obviously, all in one line) to Wimp_StartTask.
Then, you listen for the messages that TaskWindows sends to the given handle
(i.e., to your application since you passed your own task handle), most
notably TaskWindow_Ego, which tells your application the handle of your
child.
Ah, that looks *much* more elegant than hacking around by doing literal
string comparisons (which sounds like a recipe for obscure bugs in the
future)... except that from the StronHelp manuals it sounds rather as
if you need to duplicate all functionality of the Taskwindow handler
yourself, e.g. when the child task produces output, you need to display
the data. :-(

The zip utilities, for instance, not only display progress messages but
sometimes prompt for input, and implementing an entire scrolling
input/output display is the sort of reinvention of the wheel that using
a taskwindow to handle command-line utilities was supposed to avoid.
--
Harriet Bazley == Loyaulte me lie ==

Old Programmers never die. They just terminate and stay resident
druck
2020-06-09 09:58:55 UTC
Permalink
Post by Harriet Bazley
On 8 Jun 2020 as I do recall,
Post by Martin Wuerthner
Then, you listen for the messages that TaskWindows sends to the given handle
(i.e., to your application since you passed your own task handle), most
notably TaskWindow_Ego, which tells your application the handle of your
child.
Ah, that looks *much* more elegant than hacking around by doing literal
string comparisons (which sounds like a recipe for obscure bugs in the
future)... except that from the StronHelp manuals it sounds rather as
if you need to duplicate all functionality of the Taskwindow handler
yourself, e.g. when the child task produces output, you need to display
the data. :-(
You don't have to display the TaskWindow's task's output in a scrolling
window. If you are calling a program to process a file (as in this case
with Ghostscript) the only output you are interested in is error
messages, and you can capture this output and display in an error box.

---druck
Harriet Bazley
2020-06-09 14:09:43 UTC
Permalink
On 9 Jun 2020 as I do recall,
Post by druck
Post by Harriet Bazley
On 8 Jun 2020 as I do recall,
Post by Martin Wuerthner
Then, you listen for the messages that TaskWindows sends to the
given handle (i.e., to your application since you passed your own
task handle), most notably TaskWindow_Ego, which tells your
application the handle of your child.
Ah, that looks *much* more elegant than hacking around by doing literal
string comparisons (which sounds like a recipe for obscure bugs in the
future)... except that from the StronHelp manuals it sounds rather as
if you need to duplicate all functionality of the Taskwindow handler
yourself, e.g. when the child task produces output, you need to display
the data. :-(
You don't have to display the TaskWindow's task's output in a scrolling
window. If you are calling a program to process a file (as in this case
with Ghostscript) the only output you are interested in is error
messages, and you can capture this output and display in an error box.
Yes, but from Infozip's point of view I'm launching a program which can
potentially prompt the user for input (and will hang mysteriously if it
fails to get it). Unfortunately detecting the identity of the child
with TaskWindow_Ego doesn't sound as if it will work, if I can only do
that by taking over the entire taskwindow handling myself.
--
Harriet Bazley == Loyaulte me lie ==

It is better to be deceived by a friend, than to suspect him.
Ronald
2020-06-13 01:01:42 UTC
Permalink
Post by Harriet Bazley
On 9 Jun 2020 as I do recall,
Post by druck
Post by Harriet Bazley
On 8 Jun 2020 as I do recall,
Post by Martin Wuerthner
Then, you listen for the messages that TaskWindows sends to the
given handle (i.e., to your application since you passed your own
task handle), most notably TaskWindow_Ego, which tells your
application the handle of your child.
Ah, that looks *much* more elegant than hacking around by doing literal
string comparisons (which sounds like a recipe for obscure bugs in the
future)... except that from the StronHelp manuals it sounds rather as
if you need to duplicate all functionality of the Taskwindow handler
yourself, e.g. when the child task produces output, you need to display
the data. :-(
You don't have to display the TaskWindow's task's output in a scrolling
window. If you are calling a program to process a file (as in this case
with Ghostscript) the only output you are interested in is error
messages, and you can capture this output and display in an error box.
Yes, but from Infozip's point of view I'm launching a program which can
potentially prompt the user for input (and will hang mysteriously if it
fails to get it). Unfortunately detecting the identity of the child
with TaskWindow_Ego doesn't sound as if it will work, if I can only do
that by taking over the entire taskwindow handling myself.
I'd like to be able to use return codes from a unixlib program
but when called from an Obey file.
It looks like the only way to do this would be to have either a BASIC
or C wrapper/shell to do the running.
The only advantage would be that it could set a system variable that
an Obey file could read for any programs return code, avoiding setting
the system variable in every individual (ported) program.
Don't know how well this would work or if it would help Harriets case.

Ronald
druck
2020-06-13 11:03:55 UTC
Permalink
Post by Ronald
I'd like to be able to use return codes from a unixlib program
but when called from an Obey file.
It looks like the only way to do this would be to have either a BASIC
or C wrapper/shell to do the running.
The only advantage would be that it could set a system variable that
an Obey file could read for any programs return code, avoiding setting
the system variable in every individual (ported) program.
RISC OS already does this, Sys$ReturnCode should be set to the result
from the program, but note that not all programs return a non zero code
in the case of an error.

---druck
Ronald
2020-06-13 13:29:38 UTC
Permalink
Post by druck
Post by Ronald
I'd like to be able to use return codes from a unixlib program
but when called from an Obey file.
It looks like the only way to do this would be to have either a BASIC
or C wrapper/shell to do the running.
The only advantage would be that it could set a system variable that
an Obey file could read for any programs return code, avoiding setting
the system variable in every individual (ported) program.
RISC OS already does this, Sys$ReturnCode should be set to the result
from the program, but note that not all programs return a non zero code
in the case of an error.
---druck
So it does, looking forward to using it.
Important failures can be acted upon loudly now.

Ronald
Rob Hemmings (News)
2020-06-08 22:37:21 UTC
Permalink
[Snip]
Post by Martin Wuerthner
That might be better, but there is still more guesswork involved and
less control than using the TaskWindow protocol, which was specifically
designed to allow tasks to control their TaskWindow children. Using
this protocol also makes you independent of any registered TaskWindow
provider since your application itself becomes the TaskWindow provider.
The key point is to launch the child by passing
TaskWindow <command> -wimpslot <slot> -name <name> -quit
-task <my_task_handle> -txt <arbitrary_id>
(obviously, all in one line) to Wimp_StartTask.
Then, you listen for the messages that TaskWindows sends to the given
handle (i.e., to your application since you passed your own task
handle), most notably TaskWindow_Ego, which tells your application the
handle of your child. If you run several children, you can distinguish
them because the Ego message quotes the arbitrary id you passed.
TaskWindow_Morio tells you that your child has died. While the child
runs, you can suspend it, resume it and kill it by sending messages
TaskWindow_Suspend/Resume/Morite to your child handle. By listening to
TaskWindow_Output you can receive the output of your child, e.g., any
error messages from Ghostscript.
That is how GView (http://www.mw-software.com/software/gview/gview.html)
calls Ghostscript.
Thanks very much indeed to both Steve and Martin for the very thorough
and helpful explanations. Really useful although I'm going to have to do
some more reading of my Programmer's Reference Manuals!
--
-------------------------------------------------------------
Rob Hemmings Southport

***@dsl.pipex.com
Ronald
2020-06-14 04:38:33 UTC
Permalink
Post by Rob Hemmings (News)
It is ages since I've been programming so apologies if this is a silly
question.
Is there a way to call GhostScript from inside a BASIC program and return
control to the BASIC program afterwards? I've just tried invoking
GhostScript from a program using an OSCLI command but although
GhostScript then runs correctly it does not hand back control to the
BASIC program which just ends. I think I understand why it is happening
but is there any way to get around it?
Without going into the heavy Taskwindow stuff, one way is to filer_run
an obey file containing whatever, could even be a Taskwindow command
running yet another obey file with desired actions for within the
taskwindow.

The main consideration is that the BASIC file will continue to
the end unless you put have a wait routine straight after.

I guess checking for a file or system variable to be set with
some sort of wimp poll so it's not grinding away in a loop.
I've been experimenting with pause%=INKEY 2000
any key press will stop the wait, useable to a degree.

Ronald
Steve Fryatt
2020-06-14 06:40:36 UTC
Permalink
On 14 Jun, Ronald wrote in message
I guess checking for a file or system variable to be set with some sort of
wimp poll so it's not grinding away in a loop. I've been experimenting
with pause%=INKEY 2000 any key press will stop the wait, useable to a
degree.
If you don't want to do the Message_TW_* stuff, then Message_TaskInitialise
and Message_TaskCloseDown, as I originally posted. That way, there's no
polling and no ugly time delay stuff: you just get messages sent in when
there's something new to test against.
--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/
Rob Hemmings (News)
2020-06-14 07:48:41 UTC
Permalink
Post by Steve Fryatt
On 14 Jun, Ronald wrote in message
I guess checking for a file or system variable to be set with some sort of
wimp poll so it's not grinding away in a loop. I've been experimenting
with pause%=INKEY 2000 any key press will stop the wait, useable to a
degree.
If you don't want to do the Message_TW_* stuff, then Message_TaskInitialise
and Message_TaskCloseDown, as I originally posted. That way, there's no
polling and no ugly time delay stuff: you just get messages sent in when
there's something new to test against.
The TaskWindow and messaging approach was fairly easy to set up once
Martin had explained it and does work very well.

I just wish I could resolve the issue I have with GhostScript as easily!
--
-------------------------------------------------------------
Rob Hemmings Southport

***@dsl.pipex.com
Ronald
2020-06-14 08:27:36 UTC
Permalink
Post by Steve Fryatt
On 14 Jun, Ronald wrote in message
I guess checking for a file or system variable to be set with some sort of
wimp poll so it's not grinding away in a loop. I've been experimenting
with pause%=INKEY 2000 any key press will stop the wait, useable to a
degree.
If you don't want to do the Message_TW_* stuff, then Message_TaskInitialise
and Message_TaskCloseDown, as I originally posted. That way, there's no
polling and no ugly time delay stuff: you just get messages sent in when
there's something new to test against.
So where is the waiting done, with Message_TaskCloseDown sitting there
with the task handle (+4) you've asked for?
Initially looks easy enough, the StrongHelp doesn't explain where
you would get the information for Message_TaskInitialise +20 +24 +28

Not saying it wouldn't be worth the effort, it does sound like
a job that a pre-existing library could do so you can just
run what you want without delving into wimp offsets.
The Zap complication hopefully will get fixed by Zap people.

Ronald
Steve Fryatt
2020-06-14 09:01:22 UTC
Permalink
On 14 Jun, Ronald wrote in message
Post by Ronald
Post by Steve Fryatt
If you don't want to do the Message_TW_* stuff, then
Message_TaskInitialise and Message_TaskCloseDown, as I originally
posted. That way, there's no polling and no ugly time delay stuff: you
just get messages sent in when there's something new to test against.
So where is the waiting done,
Nowhere.

My suggestion is that your task does nothing, thereby allowing the
processing task to do as much work as possible, until the processing task
ends. The Wimp will then send it a message to let it know.
Post by Ronald
with Message_TaskCloseDown sitting there with the task handle (+4) you've
asked for? Initially looks easy enough, the StrongHelp doesn't explain
where you would get the information for Message_TaskInitialise +20 +24
+28
You start your task:

TaskName$ = "MyTaskName"
TaskHandle% = 0
command$ = "TaskWindow MyTask 256k -name """ + TaskName$ + """ -quit"
SYS "XWimp_StartTask", command$ TO handle%
IF handle% = 0 THEN PRINT "Failed to start"

and then return control to Wimp_Poll(Idle)

Your Message_TaskInitialise handler:

PROCmessage_task_initialise(message%)
LOCAL name$

SYS "XOS_GenerateError", message% + 28 TO name$
IF name$ = TaskName$ THEN TaskHandle% = message%!4
ENDPROC

Your Message_TaskCloseDown handler:

PROCmessage_task_close_down(message%)
IF TaskHandle% <> 0 AND message%!4 = TaskHandle% THEN
TaskHandle% = 0
PROCdo_something_useful_when_task_exits
ENDIF
ENDPROC
Post by Ronald
Not saying it wouldn't be worth the effort,
The code is above; less than 20 lines. Untested, as I work mainly in C these
days, but it's a translation into BASIC from what PrintPDF does.
Post by Ronald
it does sound like a job that a pre-existing library could do so you can
just run what you want without delving into wimp offsets.
Whilst a pre-existing library is a Very Good Idea, the code above is all
that you need (plus the usual to register interest in the two messages with
Wimp_Initialise, and the usual to identify the incoming messages and call
the handler procedures).
Post by Ronald
The Zap complication hopefully will get fixed by Zap people.
Who be they, then? :-)
--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/
Harriet Bazley
2020-06-14 14:41:49 UTC
Permalink
On 14 Jun 2020 as I do recall,
Steve Fryatt wrote:


[snip]
Post by Steve Fryatt
Whilst a pre-existing library is a Very Good Idea, the code above is all
that you need (plus the usual to register interest in the two messages with
Wimp_Initialise,
Note that you *will* need to do this, otherwise your task will mysteriously
fail to receive the messages at all... ask me how I know ;-p
--
Harriet Bazley == Loyaulte me lie ==

Confession is good for the soul, but bad for the career.
Ronald
2020-06-15 02:51:36 UTC
Permalink
Post by Harriet Bazley
On 14 Jun 2020 as I do recall,
[snip]
Post by Steve Fryatt
Whilst a pre-existing library is a Very Good Idea, the code above is all
that you need (plus the usual to register interest in the two messages with
Wimp_Initialise,
Note that you *will* need to do this, otherwise your task will mysteriously
fail to receive the messages at all... ask me how I know ;-p
Two places I can think of that you might run binaries from BASIC would
be AppBasic and Confix is predisposed for BASIC scripts.
Actually AppBasic seemed to call a binary OK.
The FilerHRun module is not mentioned much these days but it may
have had this type of usage in mind.
It can run a binary directly from BASIC, but once again you have to
perform a wait. Haven't checked to see if SYS$RETURNCODE is possible.

I'm putting PDF's on my chromebook, quite a fast startup,
not a bad pdf viewer, can do it in bed! (Winter here)
I think the PRM's need a separate index built so you can get to
where you want quicker. For one thing the pdf page numbers differ.

Ronald
druck
2020-06-15 07:56:01 UTC
Permalink
Post by Ronald
The FilerHRun module is not mentioned much these days but it may
have had this type of usage in mind.
It can run a binary directly from BASIC, but once again you have to
perform a wait. Haven't checked to see if SYS$RETURNCODE is possible.
It wont be. Sys$Return code is only valid if you explicitly run a
program via OSCLI. Any sort of FilerRun, TaskObey or other Wimp
mechanism will usually return to you straight away, and queue the
program to be run when they get the next Wimp Poll. Only they will be
able to read Sys$Return code when the program exits and you can't rely
on this variable once Wimp Poll is called, as something else may have
exited.

---druck
Ronald
2020-06-15 08:30:39 UTC
Permalink
Post by druck
Post by Ronald
The FilerHRun module is not mentioned much these days but it may
have had this type of usage in mind.
It can run a binary directly from BASIC, but once again you have to
perform a wait. Haven't checked to see if SYS$RETURNCODE is possible.
It wont be. Sys$Return code is only valid if you explicitly run a
program via OSCLI. Any sort of FilerRun, TaskObey or other Wimp
mechanism will usually return to you straight away, and queue the
program to be run when they get the next Wimp Poll. Only they will be
able to read Sys$Return code when the program exits and you can't rely
on this variable once Wimp Poll is called, as something else may have
exited.
---druck
OK, getting back to being better running the binary in an Obey
for that kind of simplicity then.
My Fetchmail program is in an obey file called by a Taskwindow.
It is well suited for Sys$ReturnCode it can range from O to 16 or so.
0 for mail received, 1 for no mail to retrieve, and higher numbers
reflect various authorisation or network faults.
Thanks
Ronald

Harriet Bazley
2020-06-14 14:44:38 UTC
Permalink
On 14 Jun 2020 as I do recall,
Ronald wrote:

[snip]
Post by Ronald
The Zap complication hopefully will get fixed by Zap people.
I imagine that the Zap attitude is 'the task may *expect* to receive the
handle of a child taskwindow from the registered taskwindow handler, but
this is not actually specified by the relevant WIMP protocols, and provided
the taskwindow is eventually created the handler can implement the actual
creation however it likes'.

Short version: 'tasks should not rely on undocumented behaviour' :-P
--
Harriet Bazley == Loyaulte me lie ==

A man's best friend is his dogma.
Loading...