Inside - MISCELLANEOUS
Contents
Section 1
SHELL
INFORMATION
CoCo-3 Level Two has a new shell, derived from the original that was used before for both L-I and L-II systems. The changes made were done mostly because of windows and our 8K blocks.
To the user, there are four main new features:
* The ability to redirect multiple paths to the same file, using the <>, <>>, <>>>, >>> options. * The usage of a path number as a device reference: that is, you can redirect a command's standard input, output or error to the current in/out/err paths. To do this, you use the pseudo device names "/0, 11, or 12".
The main use that you'll see of this is inside shell scriptfiles. An example should be in your Startup file, where you'll find "setime </1" instead of "setime </term" like you're used to seeing. Since path 1 (standard output) is still the device that you're viewing, the effect is the same, but now the same Setime script will also work with say, an external terminal. This feature gives you more flexiblility and less hard-coding of device names.
* The "i-/devicename" option. This is known as the immortal option. What it does is open all three standard paths to the device named, and sets a flag in the shell's data area.
The flag indicates that the shell should not end operations on an End-of-File. This is needed because CC3GO would have no idea where to restart a shell, unlike the older SysGo which could pretty well assume (TERM.
This also provides a quick and dirty tsmon-like way to use an external terminal without it dying on you. Just use something like "shell i=/T2 &" to keep a shell on /T2. You could also have done "shell <>>>/t2", but that one could die on an EOF.
A related new feature is that if a new shell starts up but gets back an error printing "Shell", then it does die. This might happen if you start a shell and the open-window call fails. The reason is to keep from having phantom shells laying about with no paths open... they'd be impossible to kill.
* The ability to send special shell characters as parameters. Before, if you tried an: echo hello! , the shell would send "hello' (without the quotes) to echo, but then take the and try to pipe to the next command, which wasn't there of course.
Now, you can type: echo "hello!" , and what echo gets and prints out is: "hello!", but including the quote marks, unfortunately.
A SMALL PROBEM
As seen in the flowchart, if the shell can't find a program in memory, it tries reading it's header from the current execution directory. If that fails, it tries to use a file from the data directory as a shell script for a new shell.
The older shells would first F$Link a module into it's own map to get the header information needed for a FSFork of the new process. Unfortunately, with our 8K blocks, it's possible that this link might fail because the new program was too large to fit in the blocks left in a shell's map (normally 5 under ver 2.00.01).
The new L-II shell uses two new OS9 system calls to get around this: FSNMLink and FSNMLoad, both of which do NOT link a module into the caller's map, but instead just return some information from the module's header (like Data Size).
To keep the module link count straight, the shell also does an FSUnLoad, which uses a module's NAMEto callunlink.
This is fine. A minor problem can occur, though, if the name of the module that shell wants to unload differs from the module's real name. This can happen if, for example, you had the Ident command on your disk under the filename "Id". What would happen is that when you typed "id", the shell would end up FSNMLoading Ident from your commands directory and executing it. This is normal. But then shell would try to Unload "id", as that's the name it saved from the command line.
The net effect is that Ident would stay linked in the module directory until you manually unlinked it.
Another way this could occur is if you used a partial or full pathname. Examples: "/d1/cmds/bob" or "../bob". In neither case will the FSUnload call work since those "names" do not match any in memory.
As I said, this is minor, and the shell can be rewritten someday to also read in the real name after it reads the header from disk. I suspect a later version will have this. The point is that you should be aware of this and so not be surprised.
KILLNG WINDOW PROCESSES
While we're on the shell, I want to bring up another "gotcha" that makes perfect OS9 sense, but that still took a while to figure out.
Let's say that you began with a shell on TERM. Then you started one on W2 with "shell i=/wl&" and you went over to that one. Now you start another one with "shell i=/w7&" and then moved back to the original TERM window.
There let's say that you kill the shell on W7. You do a Procs and that shell continues to show up with an error 228.
The "gotcha" is that the shell on W1 was the parent of the dead W7 shell, and until you go to W1 and hit a key, the dead shell can't get thru to W1 to report it's death.
A similar thing can bite you worse. If you had started a process on W7 using the same method and it dies while you're doing something important (like editing a file) on the parent's window (W1), then you'll be confused by the death message popping up in the middle of your session.
Now this quirk has been around OS9 forever, but unless you used a lot of terminals, it didn't matter too much. With many windows now, it becomes more important and aggravating.
The partial solution that I use is to always start all my shells on other windows from my first window. That way, I at least know where their deaths will show up (-005 etc). This would go for any program I wanted to run in the bacground mostly unseen (using "&").
Typing "w" <enter> on the parent shell's window after killing a child is another good idea, as that causes that shell to Wait for the death report without messing up your screen.
MISC
Just wanted to add a couple of things about the shell that don't seem to be well-documented.
Many people falsely assume that "OS9" recognizes that a module is, say, a Basic09 packed I-Code procedure and so "OS9" calls up RUNB to execute it. The truth is that this is all done by the Shell. Trying to fork an I-Code module from a machine language program would fail unless you yourself specified the module as a parameter to RUNB and forked RUNB.
The other small point is that using parenthesis starts a sub-shell. For example, the command" ((( echo hi; sleep 500)))" would cause 3 sub-shells to be formed, each calling the next. Try this sometime with a Procs command running on another window so you can see all the shells formed.
SHELL Flowchart SHELL
l Data Area: Clear vars redirected Pithis Set signal intercept pages Store parm size pathmanne ptr - <--y (parm size=0?) parm size l Gosub. DOCMD parm ptr l (end of parms?) y------- >END mem for mod L------ > this char Print "She" ( ' count - - - --അ > signal storage l Print OS 9 P flag l IŞReadiline T l (end of file?) y-------- >END X l <-- - - - - - - - - - - - Setpr ID # l (-X flag?) l 19 byte buff l<-- Print err msg l input buffer
(-T flag?) Echo in to 2 l l GOSub DOCMD l lK--n ( error?) y------ >
sk DOCMD SUB k
Exec W, *, CHD, CHX, EX, KILL, X, P, T, SETPR, ; Find () 's Exec & ! < > >> Start Process Undo redirection Wait if required
RTS
k START PROCESS k
l
Link to name er - - - - - - - - - Unlink l
l Open xifile err-------- جر - l Read hor l l Close file 1.
a lar l l . K--y (M/L code ?) Cnd = " Shell l Else find lang (Runb, PascalS) < name" l Cmd=lang parm-name l 1. -- ཨམ- - -- - ཁམ། -- >< AA ака ова ам- l
Link to cmd/language
Load if necessary
Set mem size
FSfork
FSsleep 1.
FSunload cmd name
RTS
- Miscellaneous: Section 2
This section is not really needed any more, as L-II will be out by the time this gets published. However, for those those who are getting started with L-II by way of the Tandy game disk "Rogue" cat #26-3297,
USING Rogue TO MAKE A SYSTEM DISK:
1- under L-I, format a disk . 2- os9gen that disk using the OS 9boot file on Rogue *. 3- copy over CMDS dir with grfcdrv and shell ** . 4- drop back to RSDOS and copy over the L-II kernal with: 5 REM Rogue in drive 0, new disk in drive 1. 10 CLEAR 10000 20 E'OR SE = - TO 18 30 DSKIS 0,34 SE AS, BS 40 DSKOS 1, 34 SE AS, BS 50 NEXT SE
- LR Tech owners may include their driver and desc after copying the new "shell" file and "grfdrv" to it, OR after changing the desc name from "HO" to something else so that the bootup gets shell/grfdrv from the floppy. Then CHX/HO/CMDS.
You should also change the HO desc byte at SOE from SFF to $07 and reverify that module. That's the extended device address.
- You may include other utilities merged into the Rogue shell file (do an ident on it first!), to be included at startup. The total length of your shell file should be under $1E00 long.
You MUST have Grfdrv and Shell in your CMDS dir. They must also have the "e" attribute set on the files.
Since L-II will map in the entire block of cmds loaded in a file, you should try to keep things on an n°8K+(8K-512) boundary.
Your L-I mfree, mdir, and procs will NOT work.
PRINTER will work if you change the baud rate to 1/2 before.
One other thing: do NOT unlink Shell in memory. Crash-o!
MAKING WINDOWS:
Examples are also in Rogue's MAKE40, MAKE80, MAKEGW shell files.
However, because Rogue does not include the W, and W1-W7 device descriptors, you cannot make more than one window or screen of windows with it. Solution: make a set of window descriptors using the source code elsewhere in this text.
Don't worry too much about the default size and palettes, you can send the escape codes to override them anyway. Example:
iniz w1 (if you have iniz cmd) display lb 20 2 O 0 30 c. 9 0 1 >/wl shell i=/w 1 & (now hit the CLEAR key: you should flip to that screen)
Read the Sept 86 RAINBOW article on windows, plus try out the later examples they give if you have 512K.
Be aware that your CLEAR and G) keys are no longer the same as the CTRL and ALT keys
- Miscellaneous: Section 3
BUGS - SOFTWARE
Level Two for the CoCo-3 has gone through many revisions, and most of the bugs have been ironed out over the months. What are left in version 2.00.01 are relatively minor. Not all are listed here. Check the electronic forums for recent updates.
MODULE: Clock PROBLEM: Bad error code return. SPECIFICS: Somebody left the '#' sign off of a LDB #ESerror. SOLUTION: Patch and reverify. Offset Old New O191 D6 C6
MODULE: OMan PROBLEM: Sorts queues wrong. SPECIFICS: Change first made in L-I 2.0 to insert processes in I/O queues according to priority. Used wrong register. SOLUTION: Patch and reverify. Offset Old New 09/A6 10 12 O9A7 A3 E1
MODULE: GrfDrv PROBLEM: Non-efficient use of screen memory. SPECIFICS: Opening a 40 column screen should use the last 2K of an 8K screen block if it's free for use. However, apparently a bad Def was used in MW's source code and GrfDrv cannot match an internal code as a 40 column screen. SOLUTION: Patch and reverify. Offset Old New 033A 84 86
MODULE: OMan PROBLEM: Cannot have more than one VIRQ device at a time. SPECIFICS: While Clock gets the size of the VIRQ table from the Init module (as it should), IOMan has a different size hard-coded in. Clock inserts the first entry at the front of the VIRQ table, but the next call starts searching at the end of the table...which turns out to usually be the header of the first module in your bootfile. Symptoms: if your disk drive is still going (waiting for motor time-out), you cannot Iniza ModPak device. Or, if you. Iniza ModPak device, your drives will never shut off. SOLUTION: Easiest patch is to the INIT Module, to change the number of IRQ/VIRQ devices down from 15 to say, 12. Offset Old New OOOC OF OC
MODULE: CC3IO PROBLEM: SS...Montrgetstat call bad. SPECIFICS: Although the manual doesn't mention it, CC3IO also supports getting the current monitor type set by montype. The value (0,1,2) is returned in the X register. The code in CC3IO should have been a STDRSX instead of STB RSX though. SOLUTION: Patch and reverify. Offset Old New O7D2 E7 ED
BUGS - HARDWARE
The GIME chip itself, on many machines, has problems with map changes causing "snow" on the screen, horizontal scrolling difficulties, and a few other items.
The most basic problem is one of bus-timing, and a fix is expected soon from Tandy. This is all I can say right now.
The Speech/Sound Cartridge, because it uses the clock signals generated from the 6809E, is driven too fast at the 2MHz speed of L-II to operate correctly. This is also true of several third-party interfaces and ramdisk paks.
Information on hacking the SSC can be had on the electronic forums. Users of other gear should contact their suppliers for updates or patches to their hardware.
Many of us with the original Tandy floppy disk controllers have found that they simply cannot handle the 2Mhz speed. There are two things you can do about this.
You can try replacing the Floppy Disk Controller chip or data separator chips, and hope you bought a faster part than before. Or you can opt for one of the third-party controllers.
Both Disto and J&M controllers seem to work fine so far. The newer, the better, seems to be the rule of thumb.
As far as hard disk set-ups go, the ones at this time that I know will work at 2MHz is the LR Tech from Owlware, FHL's QT CoCo, and perhaps the J&M.
BUGS - MANUAL
At the last moment before this went to press, several people with Level Two called to ask about some mistakes in the manual. I won't point out the ones like misspellings, just the ones that might confuse you.
SUBJECT: Creating GFX Windows SECTION: BASICO9 Reference PAGE: 9-37 Here they tell you how to create a graphics window, but show the "merge sys/stdfonts >/wl" AFTER the wcreate. Nope. All you get is dots on the screen. You must merge stdfonts BEFORE opening any gfx windows, unless you care to do a FONT command to that window after merging. They had it correctly on the page before (9–35) about merging so that you can type later.
SUBJECT: FSFORK, FSLINK, FSLOAD, ISCREATE, ISMAKDDR, ISOPEN SECTION: OS9 Tech Reference PAGE: 8-16, 8-23, 8-26, 8-49, 8-56, 8-58 On all of these, after the call X should be pointing to the SOD (carriage return) at the end of the string.
SUBJECT. F$FORK SECTION: OS9 Tech Reference PAGE: 8-15 The Y register contains the parameter areasize in BYTES, not in pages.
SUBJECT: FSTIME SECTION: OS9 Tech Reference PAGE: 8-40 To be exact, on exit X points to the time packet returned to the area at (X) that you had originally passed for the call.
SUBJECT: ISDELETE SECTION: OS9 Tech Reference PAGE: 8-50 On return, X should be pointing to the beginning of "MEMO".
SUBJECT:FSALARM SECTION: OS9 Tech Reference PAGE: 8-66 F$Alarm is a user call, too. And they left out how to use it. Here's the info: This call has several variations, which have to do with setting time variables that the Clock module will try to match once a second. You may clear the alarm setting, read it, or set it for one of two exclusive actions. D = 0000: clear the setting X = ptr to 5-byte time packet (YY.MM.DDHHMM) D = 0001 : cause the CC3IO "beep" for 16 seconds after the time packet sent matches system time. X = ptr to spot for time packet return D - OOO2 X < current alarm setting packet returned D < current procid and signal pending X = ptr to 5-byte time packet (YY.MM.DDHHMM) A = procid to signal on time match B = signal to send on time match
SUBJECT. FsdATLOG SECTION: OS9 Tech Reference PAGE: 8-78 Actually, not a bad example, but only if you're running on a machine with 4K blocks. On the CoCo-3, Ouput X = $4329. The actual code just multiplies B*$2000 and adds it to X.
SUBJECT: SS.RDY SECTION: OS9 Tech Reference PAGE: 8-113 On devices that support it, the B register will return the number of characters that are ready to be read. Both CC3IO and ACIAPAK support this feature.
SUBJECT:ss.MOUSE SECTION: OS9 Tech Reference PAGE: 8-125 on Somebody forgot the two reserved bytes between Pt.ToTm and Pt.TTTo. As printed, offsets after ToTm are wrong. So insert a "rmb 2- reserved" after Pt.ToTm. Also ignore the system use note at the end after Pt.Siz.
SUBJECT: SS.DSCRN SECTION: OS9 Tech Reference PAGE: 8-143
Also, if you specify screen number zero (Y=0000), then you will return to the normal VDG (32x16) screen. This should be done before a SS.F.Scrn if you wish to return to a text screen. SUBJECT: INSIDE OS9 LEVEL II BOOK SECTION: A1 PAGES : Many This is such a great book that the minor errors can be explained by the authors desire to get the information out to you quickly. You should send them lots of money and good wishes. By the way, this portion of the book is being written very close to April 1st. PS The word 'them' in the second sentence should be changed to FHL. PPS Remember it's real close to April 1st.
FONT CONVERSION
This is an RSDOS program from Chris Babcock that converts Graphicom-II font files to the format required by OS9. After conversion, you must copy the file over to an OS9 disk.
You must also specify the group/buffer numbers that you will later use to access the font using the FONT commands. We've been personally using group D0, and buffers 1-8 or so.
10 CLEAR 500, &H 7B00:POKE&H95C9, & H17:POKE&HFF 22, PEEK (&HFF22) OR&H10: CLS: PRINT"Graphi com II Font to OS-9 Font Copyright 1987 by Chris babcock - Program for Coco 3" 20DATA141, 83, 134, 27 141, 59, 134, 43, 141, 55, 182, 14, 0, 141, 50, 182, 14, 1, 141, 45, 134, 5, 141 , 4, 204 0, 8, 141, 46, 141, 44, 204, 4, 0, 141, 39, 79, l 6, 142, 1, 0, 141, 22, 49, 63, 38, 250, 142, 124, 0, 16, 142, 3, 0, 236, 129, 141, 17, 49, 62 38 30 DATA 248, 126, 164, 45, 141, 28, 38, 3, 126, 206, 217, 126, 207, 181, 141, 18, 38, 3, 126, 206, 215, 126, 207, 179, l A1, 8, 38, 3, 126, 201 86, 126, 202, 4, 52, 2, 182, 193, 66, 129, 48, 53, 130 40 FOR I=&HEO 4 TO &HEO 4+103 : READ DT:POKE I, DT : NEXT 50 PRINT"What is the filename of the font (Maximum 8 Chairs. Ext is "+CHRS (34) + "SET"+CHRS (34) +") " : PRINT"Use if : FILENAME if other drive." 60 LINE;INPUT': '"; " ; FŞ : PRINT Ga 235 " . SET" +CHRŞ (13) : F. Ş=LEFTŞ (FŞ, 10) + " . SET" 70 PRINT"New filename for the font (Maximum 8 Chairs. Ext is "+CHR$ (3 4) + " OS 9 " +-CHR$ (3 4) + ") " : PRINT "Do NOT enter a drive # now . " 80 LINEINPUT": "; GS: PRINT(393, " . OS 9": GS=LEFTS (GS, 8) ; GS =GS+STRINGS (8- LEN (GS), 32) + "OS9"
90 INPUT"Drive number for OS-9 file"; D
100 LOADMİ E"Ş 110 CLS: PRINT"Group number for the OS-9 Font (Give in hexadecimal 00FF)" : LINEINPUT": "; GRS
120 GR=VAL (" & H " +GRŞ) : IF GR<0 OR GR>255 THEN 110
130 PRINT "Buffer/Font number (Hex also ) " : ILIINEINPUT" : " ; BEF $
140 BF =VAL ("S.H"+BFS) : IF BF<0 OR BF>255 THEN PRINTG 96, ""; : GOTO 130
150 POKE& HEB, D: POKE& H95A. D
160 POKE&HE00, GR: POKES HE01, BF
170 x=&H94C: FOR I=l TO ll:POKE X, ASC (MIDS (GS I, 1) ) : X=X+1 : NEXT I: POKE&H957, 1: POKE&H 958, O
180 PRINT"Saving. . ."
19O EXECS HEO 4 200 CILS : PRINT "Use XCOPY or TRISCOPY to move the file over to an OS-9 Level II disk . MERGE the file and type DISPLAY 1B 3A GROUP BUFFER <cr>"
2O0 END
TIPS, GOTCHAS, and LAST MINUTE STUFF
Using L-1 VDG Programs
Many of you may want to run programs such as TSEDIT or Steve Bjork's bouncing ball demo within a L-II screen. Fortunately, Microware provided for this. However, your disk only comes with one VDG-type descriptor, TERM-VDG.
For programs that don't have "/TERM" hard-coded in them, you can set up a window device as a VDG screen using the following method (where wX= any window number):
deiniz wX
xmode /wx type=1 pag=16
shell i=/wX &
This will give you another screen that you can flip to, where you can run TSEDIT or other older programs.
OS9BOOtS
Under L-1, many of us only loaded drivers and other modules as needed, to save memory. Level Two acts a bit differently, and your methods must change.
You should put ANY and ALL drivers and descriptors that you plan to use, IN your OS9Bootfile. If you don't, then each time you load a separate driver, you will take up 8K of your 64K system map... doesn't take more than a couple to really limit the number of tasks or open files that you can have.
When using OS9Gen or Cobbler to make a new boot disk, be sure that you have a CMDS directory with a Shell file and the GrfDrv module. The execution attributes should also be set on these two files. Otherwise, you'll get the dreaded "OS9BOOT FAILED".
Merged Module Files
If you ident your /DO/CMDS/shell, you'll see that more than one command is included in that file. The reason is that it pays to get as close to an 8K block boundary as possible, so that you use less memory. If you separately loaded each of those commands, each would take an 8K block. Even with 512K, you'd lose memory very quickly.
OS9 will try to fit a block of modules into the upper part of a 64K task map... but remember that the FEXX page and our I/O is from FE00-FFFF in all maps. So the ideal size of a merged file is:
(8K * N)-512 bytes, where N ranges from 1-7)
Actually, N should be kept around 1, if possible. So a Shell file for instance, should ideally be just under $1E00 long. That's (8K * 1)-512 = $2000-$200 = $1E00.
RUNB is 12K, so it takes up 2 blocks, but you still have room for about 5K of things like syscall, inkey, gfx2, etc.
To create a new shell file, for example, you might do:
merge shell dir free mdir procs ... etc >newshell
rename shell shell.old; rename newshell shell
attr shell e pe
A "dir e" can tell you the size of merged files or you can print out an Ident of all your commands and use that as a reference to calculate from.
F$Load from system state
Requires an extra parameter if done from a driver or other module that will be in the system map. The U register must point to the process descriptor of the process who's map you want the new module loaded into. Example for loading module file into the system space:
leax modnam,pc point to name of module to load
ldu D.SysPrc get system proc des c pointer
OS9 F$L Load load file "modnam" into system map
F$Link from system state:
Will put the module into the map of the current process (D.Proc). It also gets the name (X points to it) from the D.Proc map. So to link a module into system space, you must "trick" OS9:
ldd D.ProC get current process
pshs d save it
ldd D.SysPro get system proc desc
std D.Proc make it current proc temporarily
... (set up link parms)
OS9 FŞLink link module (s) into system map
puls d retrieve true user process
std D.Proc and reset as current process
Forking RUNB modules:
Pete Lyall and I just figured this one out, and even though it's fully explainable, it's still a gotcha...
Let's say that you have a Basic09 I-code (packed) module named "Bob", and it requires 10K of data area. Typing "bob" from the shell command line causes shell to check Bob's header. There it finds that Bob needs 10K and also needs RUNB. So the shell effectively does a "runb bob #10k". Fine.
But! If you have the need to fork"RUNB BOB" from within a m/1 program and don't know what data size Bob (or any I-code module) needs, you'll probably try just using a FSFork RUNB with Bob as a parameter - which will fail because RUNB's header only has a default data size required of 4K (possibly 8K for CoCo-3). And 4K isn't enough for Runb to use Bob.
(note: just doing a "runb bob" from the shell cmd line would fail, too)
Moral is that you should either check an I-code's header yourself, or you could instead do a "FSFork Shell bob" and let shell handle everything.
Using L-1 Debug on Level Two:
There is no debug included on the L-II disk set. It will be on the Developer's Pak disk. In the meantime, if you can't use Modpatch for what you need to do, you can partially patch your current debug to at least let you modify modules in memory.
Debug will link to a module, but does so just to get the module address. It immediately unlinks the same module to keep the system link count correct. Under L-II, this means that the module is mapped into debug's space, then mapped out right after that
As debug is now, you CAN use it on any modules that were in your bootfile, but that's because those cannot be unlinked. To debug other loaded modules, you have to change debug while under Level ONE:
Offset Old New O6CC 10 12 this changes FŞUnlinks to NOPs O6CD 3F 12 O6CE O2 12 06D0 10 12 " " 06D1 3F 12 06D2 O2 12
Then save it and reverify, of course. The only gotcha now is that since modules are not unlinked at all, then if you try debugging all sorts of modules at one time, you could get an error #207 from the debug map getting filled up. No problem, just Quit and enter Debug again.
Login II Patch
This patch will allow you to use your level I LOGIN" command (which currently crashes on a level II system) on a level II system. It corrects the code so that it uses the F$suser call instead of trying to manipulate the system's direct page, which is inaccessible under level II for writing (in USER mode). This patch is a joint effort of Kent Meyers and Pete Lyall.
display c t * LOGIN2.DBG - A patch script by Pete Lyall * * This is a shell procedure to use DEBUG to patch the LOGIN * command for use on a Level II OS9 system. Note: If you HAVE * NOT already patched your DEBUG command for use on a level II * system then either do THAT first or run this script on a * LEVEL, I system where DEBUG will work. * * -t tmode .1 -pause load login debug l login . ... +52 zE 49 20عد =32 li login . ... +57 =30 li login . . +5a a-31 l login ・ ・+69 a=49 20ܣܒ zas 32 Il 3 og in . ... + 6e s30 l login +71 s3. li login . . .234 as 1.f =02 st:10 35=ܒ sc =12 l login ・+49b க66 s5 æ73 q save login.ii login display c
The patch is completed.
Now simply UNLINK LOGIN until it is out of memory
The updated LOGIN command has been saved as "login. ii' in the current directory.
To use it, simply copy it to a LEVEL II disk's CMDS directory and rename it to "login". Also ensure that all the attributes are set properly for execution. Enjoy!
