DEMO: GLL, Faster Development Cycle?

[(X)]

I WANT TO BUILD A FASTER GLL DEVELOPMENT CYCLE USING A GLL!

In a nutshell:

I want a faster way to develop GLLs!  It feels like it takes almost a minute to compile and enable a GLL manually.  I would like to bring that down to 1 second using GLL automation.

The typical "manual" GLL Development Cycle using shortcuts:

    Compile     ({Ctrl+S, Ctrl+E, Enter} saves and compiles the New GLL)
    Enable       ({Ctrl+M, End, Alt+R, Alt+A, Select file} Open Ext mgr, Select Old, Remove Old, Select New GLL)
    Run           (Enter Shortcut Key Combo or Select the Extra Menu Item)

This sequence takes me about 40 seconds and that's using shortcuts to open menu sections etc.
I would like to automate much of this and bring the Dev Cycle Time down to ~1 sec.

Here is what I have come up with so far:

'#################################################################################
'
' DISCLAIMER:   THIS CODE IS OFFERED AS IS FOR EDUCATIONAL PURPOSES.
'               YOU ARE FREE TO USE, COPY AND DISTRIBUTE.
'               THE USE OF THIS CODE IS AT YOUR OWN RISK.
'               I ACCEPT NO LIABILITY NOR MAKE ANY CLAIM OF
'               CORRECTNESS OR SUITABILITY IN PART OR IN WHOLE.
'
'#################################################################################
'
' FILENAME      GFA_APP_G__GLL_Auto_Dev.G32
'
' DESCRIPTION   Can we reduce the development cycle time of "GLL"s by using a GLL
'               to automate as many operations as possible?
'
' AUTHOR        (X)
' EMAIL         [e-mail]
' WEBSITE       https://gfabasic32.blogspot.com/
' FORUM         https://gb32.proboards.com/
' STARTED       2023-08-16
' UPDATED       <ISO date>
'
'
Sub Gfa_APP_G()  // Auto compile and Add a GLL!
 ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
 ' Why this routine?  When you want to CREATE, COMPILE and ADD a GLL to the IDE,
 ' this requires the coder to manually perform many key strokes before being able
 ' to test.  Can't we automate this using a GLL?  Well, that's what this code is
 ' going to try to find out!
 '
 ' What are the steps to implementing a new version of a GLL?
 '
 ' DESIGN A "GLL INFORMATION INPUT FORM" TO PROMPT THE CODER FOR GLL INFO...
 '         SPECIFY:
 '             DISCLAIMER_TYPE             // FREE FOR ALL, LIMITED OR COPYRIGHT
 '             SHORTCUT_KEY_COMBINATION
 '             EXTRA_MENU_ITEM_NAME        // OPTIONAL
 '             FILENAME
 '             DESCRIPTION
 '             AUTHOR
 '             DATE
 '
 ' BEG: PRIMARY AUTO SEQUENCE
 '         INSERT_HEADER
 '         INSERT_SHORTCUT_SUBROUTINE
 '         INSERT_EXTRA_MENU_ITEM          // Optionial
 '         SAVE_FILE       // Preferably: GFA_<Shortcut Key Combo>__<Description>.G32
 '                         // A bunch of GLL funcs, procs and subs can all be stuffed
 '                         // inside one GLL but that makes it difficult to "opt out"
 '                         // of one utility or another.  I am choosing to develop
 '                         // GLLs separately for convenience, not necessity.
 '                         // Once a GLL has reached maturity, perhaps it can be
 '                         // merged into a more comprehensive GLL file.
 ' END: PRIMARY AUTO SEQUENCE
 '
 ' BEG: CODING PHASE
 '         CREATE_CODE     // Preferably: By increment, to catch errors early
 ' END: CODING PHASE
 '
 ' BEG: SECONDARY AUTO SEQUENCE
 '         COMPILE         // Compilation creates the .GLL file
 '         COPYFILE        // Copy compiled GLL over to: "GFABASIC32\bin\"
 '         ADD/UPDATE      // As a GLL: GFA IDE Extension!
 '                         // Is there a way to do this with "Gfa_<combo>" commands?
 '                         // Is there a way to do this using the Window Registry commands?
 '         EXECUTE         // Press the shortcut or select the Extra menu item.
 ' END: SECONDARY AUTO SEQUENCE
 '
 '         EVALUATE        // If not "up to snuff", back to the drawing board!)
 '         NOTES           // Keep a log!  Record problem, possible fix and solution.
 '
EndSub




[Roger Cabo]

Interesting stuff!

+ Perhaps its possible to include some compiling directives into the code.
+ If a gll would be able to run at the same time a loop what you type, it can control/add/make comments on some stuff at the same time.

Some thoughts only..

[(X)]

For a second there, I imaginged a droid-like programming assistant hovering over the screen...

[webu]

Aug 17, 2023 17:55:11 GMT 1 Roger Cabo said:

Interesting stuff!

+ Perhaps its possible to include some compiling directives into the code.
+ If a gll would be able to run at the same time a loop what you type, it can control/add/make comments on some stuff at the same time.

Some thoughts only..

A Precompliler, like GFA for Atari. Delete some spezial marked lines before compiling. This would be a good thing.

[(X)]

Aug 17, 2023 21:41:03 GMT 1 webu said:

A Precompliler, like GFA for Atari. Delete some spezial marked lines before compiling. This would be a good thing.

This seems intriguing.

Do you have an example of how a "compiler directive" might be useful?

Why and when would you "delete special lines"?

[webu]

st-news.com/issues/st-news-volume-9-issue-3/previews/ergopro

Look at this. in 1998 we finished a project named Ergo!pro for GFA Atari. It works with 3.5 and 3.6tt. It had a precompiler for infos over all used procedures, functions and vars inside all subs and proc and how they were local or global.

But the powerful feature was the posibilty to delete lines before compiling. With that, it was possible, difficult versions of compilied programs with one code to have.

It was controlled by the last chars of a line. Maybe you want to have code, only executed in the interpreter. You start the precompiler with the parameter 'awa'  (from 'away')

' del=weg

' now 'del' and 'weg' will delete lines

Print "this is normal code"

Print "this is debug code" // -del

Print "this is debug code" // -weg

Print "this is normal code"

Print "this is normal code"

Print "this is debug code" // --del

Print "this is debug code"

Print "this is debug code"

MakeSomething

MakeItSo

Print "this is debug code"

Print "this is debug code" // ++del

Print "this is normal code"

All lines with '-del' and all lines between '--del' and '++del' will erased before compiling.

In the 90s, memory and speed were still relevant. Our PRGs had between 5 and 10 kb. Bigger programms hadt 50 kb and biggest had 200 - 300 kb. A HD for Atari have had 30 mb (Megfile 30) and i remeber, that i had 5 partitions with 6 mb.

[(X)]

Ok, you seem to be refering to ways to get the code to run faster by telling the compiler to leave out lines and/or debugging code.

I am trying to speed up the GLL development cycle: {edit, compile, enable, test}... {edit, compile, enable, test}...
To compile and enable a GLL seems to take a dozen steps which I would like to reduce to one shortcut run by a GLL.

[(X)]

While perusing the GFA Help Document, I keep running into helpful hints by chance.

I was thinking of a way to 'enable' the new GLL and this just about sums up the problems I am facing.

Testing a GLL
During the development of an editor extension, you have two options to load the newly compiled GLL. First, you must make sure it is entered in the Extension Manager list. Since this operation loads the GLL as well, you can test immediately. All other times you could repeat this process but remove the GLL first.

Unfortunately, replacing a GLL using the Extension Manager requires quite some actions to perform the task. Another way to load a GLL to test it is by restarting the IDE after compiling a GLL. This takes two shortcuts: Alt-F4 to quit GFA-BASIC 32 and a Windows shortcut key to start the GFA-BASIC 32 IDE.

{Created by Sjouke Hamstra; Last updated: 12/05/14 by James Gaite}