BaCon, HUG & Thanks for the fishes

[GatorDog]

BaCon is an acronym for BAsic CONverter. The BaCon BASIC converter
is a tool to convert programs written in BASIC syntax to C. The
resulting C program should be compilable with GCC or CC.
...
The Highlevel Universal GUI abstraction layer (HUG) is a simple set of
functions to allow BaCon to set up graphical user interfaces in a fast and
efficient manner.

HUG's impact on Bacon programs is file size and protability. Which is
somewhat inversely proportional and vice versa.

Probably the way to create the smallest Bacon program is to include the
shebang at the top of the program. "#!/dir/to/bacon -b". Just like a bash
script, the interpretation and execution will take place. The program size
is simply the size of the (text) script. The trade off being that the
Bacon interpretor and gcc are required on the system the script is run on;
and there is a brief delay before program execution.

There are several ways to incorporate HUG into a Bacon program. I'll use
a GUI example that creates one small window. What will change is how HUG
is accessed.

First is the shotgun approach. It's easy and if your agenda is to create
the largest possible executable (binary) program, then this is what you're
looking for. The compiled binary is 181k.

Code: Select all

INCLUDE "/usr/share/BaCon/hug.bac"

INIT
Mainwin_ = WINDOW( "HUG TEST", 200, 200 )
DISPLAY

Second. This is a modification of the first example. There are 57 HUG
"commands". The above example loads all 57. Our sample program only uses
three of the commands. So here we're instructing the program to only
include the code for those three. (INIT, WINDOW, DISPLAY). The compiled
binary is 135k. This 45k smaller. Also this program can run on systems without
Bacon installed. It should be noted that the big plus to this method is that the
executable binary will run regardless of future changes to Bacon, Hug and
hug_imports.bac.

Code: Select all

INCLUDE "/usr/share/BaCon/hug.bac", INIT, WINDOW, DISPLAY

INIT
Mainwin_ = WINDOW( "HUG TEST", 200, 200 )
DISPLAY

A third way is to include hug_imports.bac. This requires the hug.so library, but
hug.so is included in the current Puppy releases. It is also about 100k smaller
than the first two options. It's binary is 52k.

Code: Select all

INCLUDE "/usr/share/BaCon/hug_imports.bac"

INIT
Mainwin_ = WINDOW( "HUG TEST", 200, 200 )
DISPLAY

"hug_imports.bac" takes care of some house keeping by "importing" the hug
commands from the compiled hug.so file. The fact that they are compiled is
what leads to the smaller binary file size. However, it is still loading all
57 of the HUG commands.

The first three methods are the common approaches. Here is another option that I
haven't seen mentioned yet. It produces a binary that is 34k, that's 147k smaller
than the shotgun approach.

Code: Select all

CONST HUG_lib$ = "/usr/lib/hug.63.so"
IMPORT "DISPLAY" FROM HUG_lib$ TYPE void
IMPORT "INIT" FROM HUG_lib$ TYPE void
IMPORT "WINDOW(char*,int,int)" FROM HUG_lib$ TYPE long

INIT
Mainwin_ = WINDOW( "HUG TEST", 200, 200 )
DISPLAY

The IMPORT statements are taken directly from hug_imports.bac. I don't know yet
what the economy of scale will be, but it looks to be promising.

If you want your app to be more portable amongst linux's, use one of the first
two methods. I you're writting an app for Puppians, one of the last two methods will
produce the smallest executable.

qed <><
rod

[big_bass]

Hey Rod *GatorDog

The first three methods are the common approaches. Here is another option that I
haven't seen mentioned yet. It produces a binary that is 34k, that's 147k smaller
than the shotgun approach.

this really caught my attention
and some gears started moving in my mind uh -oh

we could write a pre parser "only for small apps when speed and size is critical"
that reads through the code and pulls out the IMPORTS from hug_imports.bac
and generates the the IMPORTS in the header of your app automatically prior to compiling

it would be easy to do since there are just a few in the list and they are all capital letters
it would also shed light on the what really is happening when the program is run

having a script pre parse the code could then be applied to already working code examples
pulling only the needed IMPORTS
sort of an auto program compressing tool

not losing the focus that this concept should be applied
to very small code examples when speed and size are a must

it then could be expanded to pre parse all programs
after much testing though

Joe

[sunburnt]

big_bass; This is what I`ve said in so many different ways.
The compiler really should do all of this and more as to declares, etc...

# Additional idea for big_bass`s preparser:

Have "canned" code inserted at the start of all Bacon programs look for the
proper hug version, if not found or an older one`s found then download and
install the latest hug if it can, otherwise do a popup error message and quit.
# This could be an exec. too, installed with hug and bacon. Support library?

[GatorDog]

...we could write a pre parser...

Yes, we're on the same wavelength here.
Actually, one of the main functions of BaconXref is to parse a bacon program for
the HUG functions. It then generates the correct line for hug.bac,
ex. INCLUDE "/usr/share/BaCon/hug.bac", BUTTON, STOCK, RADIO, CHECK, COMBO, INIT, WINDOW
Then you can cut-n-paste the line into the bacon progarm.
So, there is a HUG parser already written. And there's a variable that contains all of
the HUG keywords used in the scanned program. I'd like to make this part of baconXref
but may make a prototype of just this functionality.

rod[/list]

[big_bass]

Hey this can be done

if using your code snippet above to keep things simple
the code I added is also simple to show the concept only with a working example

Code: Select all

INCLUDE "/usr/share/BaCon/hug.bac"

INIT
Mainwin_ = WINDOW( "HUG TEST", 200, 200 )
DISPLAY

I called your snippet test-shared.bac and placed it here
/usr/share/BaCon/test-shared.bac


sorry that the forum posting of code makes my code look poorly formatted
but it looked good in geany before I posted so select all the code and paste it in geany please

now run this pre-parser script

http://www.puppy2.org/slaxer/preparser.html

the output is /usr/share/BaCon/preparser.txt
notice the formatting its produces the smaller binary this way
as it using the last compile option you posted


CONST HUG_lib$ = "/usr/lib/libhug.so"
'a644b477ebae6202f294194667cef1a5 libhug.so
IMPORT "INIT" FROM HUG_lib$ TYPE void
IMPORT "DISPLAY" FROM HUG_lib$ TYPE void


I just downloaded your baconXref that looks great! I will have to
see what you did there

updated to use html of original code to have color and formatting
Joe

[GatorDog]

HI Big_Bass,

I have a functional Bacon GUI version of an IMPORT parser.
Got a couple of things to clean up yet.

With this method pFontselect is 10k smaller than using hug_imports.bac.

I'll post code when I've got it ready for testing.

rod

[big_bass]

Hey rod @GatorDog

I just compiled and ran baconXref your beta baconxref_1r4
excellent !

sadly I hadnt tried it before because I misunderstood something

I've been using bacongui 1.0.24beta and hug.bac v.61 for development.

and thought they were linked somehow and gtk sourcecode wont compile with my gtk version
so that leaves me out of the fun there

but the great news is baconxref_1r4 runs on my box

a side thought :
--------------------------------
I still think that having a "bash pre parser version" will be useful
to just do that one thing (maybe I'll figure out how to add a button or recycle a button
in geany *without having to recompile it* and call the pre-parser as a script that way it would work too) while editing code
I already added to geany BaCon and HUG highlighting and the ability to compile bacon code from the GUI
pre-parsing would be a great tool


Joe

[GatorDog]

Just to put a handle on this optional way of using hug, I'll call it the Hug Direct Import Method (DIM).

I resurected my HKP program, Hug Keyword Parser, to implement the direct import method.
It's ready for testing. Itself using the DIM method.

Three options for usage.
1.) Double click to run GUI.
. Select a Bacon (file.bac.) from the filedialog.
. Generated IMPORT statements are listed in the EDIT window, ready for cut-n-paste.

2.) Start from terminal command line "./hkp".
. Select a Bacon (file.bac.) from the filedialog.
. Click "Apply",
. Generated IMPORT statements are listed in the terminal window.

3.) Call as an executable. hkp filename.bac [libhug]
. Generated IMPORT statements are returned on STDOUT
. Optional "libhug": use /usr/lib/libhug.so instead of /usr/lib/hug.so (default)
. No GUI appears.

Output can also be redirected to a text file: hkp filename.bac > save_import.txt

rod

Edit: What it all means -
Use the generated list of direct IMPORT statements to replace IMPORT "/usr/share/BaCon/hug_imports.bac"
_________________________________________________________________________________________

Edit: Attached HKP 2.1

[GatorDog]

I added this info to the first post, relative to using IMPORT "/usr/share/BaCon/hug.bac", INIT, WINDOW, DISPLAY, etc...

It should be noted that the big plus to this method is that the executable binary will run regardless of future
changes to Bacon, Hug, hug.bac and hug_imports.bac.

GatorDog