BaCon Bits
GatorDog; Thanks for the code staring, I appreciate it greatly.
If there`s something of your`s in particular you want looked at, say so...
# Cross-Linux compatability...
So a Bacon file with: INCLUDE "hug_imports.bac" needs the hug.so library file.
# But if the target Linux distro. has a hug.so compiled and installed on it,
...... then the the smaller Bacon binary file will work on it?
If there`s something of your`s in particular you want looked at, say so...
# Cross-Linux compatability...
So a Bacon file with: INCLUDE "hug_imports.bac" needs the hug.so library file.
# But if the target Linux distro. has a hug.so compiled and installed on it,
...... then the the smaller Bacon binary file will work on it?
sunburnt
This got me to thinking. The hug_imports.bac file has a (CONST) variable
that sets the path to hug.so. I don't know if Puppy(s) are consistant about the
location of Bacon files or not. So maybe that would leave the location of
Bacon support files on other systems something that would need to be
considered.
Food for thought. If in doubt, compile a standalone version.
--------------
Joe,
I updated the first post with the latest source and standalone for pFontselect.
I'm not seeing that last set of errors/ gtk-warnings that you posted.
I probably used Bacon 1.0.23 originally on pFontselect, but I've been using
BaconGUI 1.0.24 beta hug.bac .62 beta. A few posts back there should be
a tar package with those versions if you'd like to try them.
rod
That's how I understand it.# But if the target Linux distro. has a hug.so compiled and installed on it,
...... then the the smaller Bacon binary file will work on it?
This got me to thinking. The hug_imports.bac file has a (CONST) variable
that sets the path to hug.so. I don't know if Puppy(s) are consistant about the
location of Bacon files or not. So maybe that would leave the location of
Bacon support files on other systems something that would need to be
considered.
Food for thought. If in doubt, compile a standalone version.
--------------
Joe,
I updated the first post with the latest source and standalone for pFontselect.
I'm not seeing that last set of errors/ gtk-warnings that you posted.
I probably used Bacon 1.0.23 originally on pFontselect, but I've been using
BaconGUI 1.0.24 beta hug.bac .62 beta. A few posts back there should be
a tar package with those versions if you'd like to try them.
rod
# Wouldn`t it be much better if hug.so were in /lib or /usr/lib ? ( in the Lib. path )
This seems all too obvious, but maybe there`s a method to the madness...
# GatorDog; ( I`ll continue calling you that as there`s been complaints in the past
when using real names, as most folks only know our forum handles. )
# I`m going to need "spots" of help with this, PMs might be better than
messing up your BaCon thread here... Unless it may be helpful to others?
# Error at "empty line"...
Line 2: lstGRPS_
Cause: 'lstGRPS_' undeclared here (not in a function)
### Got the error, so I added the DECLARE line and same error!
I think you can see what I`m doing here, files to read to fill the widgets.
# Also, is there a way to read a file in one command ( not looping )?
The editBox is filled in one command, so read it`s file in one command also?
V.B. would do this and I used it almost exclusively to reduce H.D. wear.
This seems all too obvious, but maybe there`s a method to the madness...
# GatorDog; ( I`ll continue calling you that as there`s been complaints in the past
when using real names, as most folks only know our forum handles. )
# I`m going to need "spots" of help with this, PMs might be better than
messing up your BaCon thread here... Unless it may be helpful to others?
# Error at "empty line"...
Line 2: lstGRPS_
Cause: 'lstGRPS_' undeclared here (not in a function)
Code: Select all
DECLARE lstGRPS_, lstPKGS_, edINFO_, cboMIR_ AS int
LOCAL dat[8]
DATA "/main.list", lstGRPS_, "/pkgs.list", lstPKGS_, "/pkg.info", edINFO_, "/mirrors.list", cboMIR_
FOR i = 0 TO 7 STEP 2
READ dat[i]
READ dat[i+1]
PRINT CONCAT$(TMP$,dat[i])
PRINT CONCAT$(TMP$,dat[i+1])
NEXT
I think you can see what I`m doing here, files to read to fill the widgets.
# Also, is there a way to read a file in one command ( not looping )?
The editBox is filled in one command, so read it`s file in one command also?
V.B. would do this and I used it almost exclusively to reduce H.D. wear.
Hey rod @GatorDog
great news !
now tested on an older glibc re-compiled and gtk compatible
on another gtk version
there is a gtk fix you need to add I looked over your code with the error report
so I replaced the medium with light and bingo !
now it is more portable for gtk
as you can see no errors with gtk the terminal is clean
one small suggestion to your great app
could you default to the quick brown fox to be in the display by default
a big thanks
Joe
I added the sources and edits compiled for puppy 4.12 compatible
I bumped the minor version number to avoid confusion
this is fun
Joe
great news !
now tested on an older glibc re-compiled and gtk compatible
on another gtk version
there is a gtk fix you need to add I looked over your code with the error report
Code: Select all
(<unknown>:27668): Gtk-WARNING **: Failed to set text from markup due to error parsing markup: 'medium' is not a valid value for the 'weight' attribute on <span> tag, line 1; valid values are for example 'light', 'ultrabold' or a number
Code: Select all
tmp$ = "<span weight=\"light\" size=\"33000\" color=\"#000000\">p</span>"
tmp$ = CONCAT$(tmp$, "<span weight=\"light\" size=\"33000\" color=\"#202020\">F</span>")
tmp$ = CONCAT$(tmp$, "<span weight=\"light\" size=\"33000\" color=\"#303040\">o</span>")
tmp$ = CONCAT$(tmp$, "<span weight=\"light\" size=\"33000\" color=\"#373760\">n</span>")
tmp$ = CONCAT$(tmp$, "<span weight=\"light\" size=\"33000\" color=\"#474780\">t</span>")
tmp$ = CONCAT$(tmp$, "<span weight=\"light\" size=\"33000\" color=\"#505090\">S</span>")
tmp$ = CONCAT$(tmp$, "<span weight=\"light\" size=\"33000\" color=\"#555595\">e</span>")
tmp$ = CONCAT$(tmp$, "<span weight=\"light\" size=\"33000\" color=\"#5757A5\">l</span>")
tmp$ = CONCAT$(tmp$, "<span weight=\"light\" size=\"33000\" color=\"#5757B5\">e</span>")
tmp$ = CONCAT$(tmp$, "<span weight=\"light\" size=\"33000\" color=\"#6060C0\">c</span>")
tmp$ = CONCAT$(tmp$, "<span weight=\"light\" size=\"33000\" color=\"#7070E5\">t</span>")
as you can see no errors with gtk the terminal is clean
one small suggestion to your great app
could you default to the quick brown fox to be in the display by default
a big thanks
Joe
I added the sources and edits compiled for puppy 4.12 compatible
I bumped the minor version number to avoid confusion
this is fun
Joe
- Attachments
-
- gtk-fix-1.0.4.png
- (88.91 KiB) Downloaded 794 times
Last edited by big_bass on Thu 29 Sep 2011, 06:07, edited 2 times in total.
I started using Bacon when I switched to PUP 525. There were some issuessunburnt wrote:# Wouldn`t it be much better if hug.so were in /lib or /usr/lib ? ( in the Lib. path )
with the Bacon files in the 525 devx. By trial, error and some help I upgraded Bacon
packages. It's possible that I, myself may have moved my hug.so to the /usr/share/BaCon
directory. I just looked, and there is an old hug.so in /usr/lib. I probably left it alone while
trying to get things to work; then never went back and replaced the old version in /usr/lib.
I'll probably do that, now that I have a little more knowledge. I'll need to edit my hug_imports.bac
to point there. It would still be nice to know if the default location for hug_imports.bac is the same
on Puppy & non-Puppy systems. Are you running Bacon on ubuntu?
I'm good either way# GatorDog; ( I`ll continue calling you that as there`s been complaints in the past
when using real names, as most folks only know our forum handles. )
Good point. Maybe some things might fit better in vovchik's original thread?# I`m going to need "spots" of help with this, PMs might be better than
messing up your BaCon thread here... Unless it may be helpful to others?
In a nutshell - DATA stores "values" not variables. (The widget names are variables.)# Error at "empty line"...
Line 2: lstGRPS_
Cause: 'lstGRPS_' undeclared here (not in a function)### Got the error, so I added the DECLARE line and same error!Code: Select all
DECLARE lstGRPS_, lstPKGS_, edINFO_, cboMIR_ AS int LOCAL dat[8] DATA "/main.list", lstGRPS_, "/pkgs.list", lstPKGS_, "/pkg.info", edINFO_, "/mirrors.list", cboMIR_ FOR i = 0 TO 7 STEP 2 READ dat[i] READ dat[i+1] PRINT CONCAT$(TMP$,dat[i]) PRINT CONCAT$(TMP$,dat[i+1]) NEXT
I think you can see what I`m doing here, files to read to fill the widgets.
So, DATA "some string data" is cool.READ <x[$]>
Type: statement
Reads a value from a DATA block into variable <x>.
Also DATA 123
BUT, DATA program_variable_name , Not so much
(voice of experience here)
Another problem with your code- the LOCAL dat[8] I believe defaults to a numeric variable.
You're trying to make READ and CONCAT$ use it as a string variable. Numbers can
easily be converted to string with STR$(... . However that doesn't help here.
I think this will get you what you're after-
Code: Select all
' ------------------
SUB WIDGET_STUFFER(int Widget_handle_, STRING Basename$)
' ------------------
LOCAL Dirname$, File$, Txt$ TYPE STRING
Dirname$ = "/tmp/"
File$ = CONCAT$(Dirname$, Basename$)
OPEN File$ FOR READING AS Infile
WHILE NOT(ENDFILE(Infile))
READLN Txt$ FROM Infile
IF Txt$ = "" THEN Txt$ = CONCAT$(" ", NL$)
TEXT(Widget_handle_, Txt$)
WEND
CLOSE FILE Infile
END SUB
' ==============================================
WIDGET_STUFFER(lstGRPS_, "main.list")
WIDGET_STUFFER(lstPKGS_, "pkgs.list")
WIDGET_STUFFER( cboMIR_, "main.list")
WIDGET_STUFFER( edINFO_, "mirrors.list")
Not that I'm aware of.# Also, is there a way to read a file in one command ( not looping )?
rod er... I mean Gatordog
OK Joe,
"light" it is. And 2nd request is even easier.
Just enter the text you'd like to see as default and click "Apply".
The next time you run pFontselect, it should be there, along
with your previous setup. ie. Font name, Style, Size
How 'bout that
rod
(will update first post with latest 1.0.4 pFontselect)
"light" it is. And 2nd request is even easier.
Just enter the text you'd like to see as default and click "Apply".
The next time you run pFontselect, it should be there, along
with your previous setup. ie. Font name, Style, Size
How 'bout that
rod
(will update first post with latest 1.0.4 pFontselect)
Thanks; I`ll redirect somethings(?) to vovchik...
### I think hug.so just being found by the Lib. path is best.
### Perhaps compile hug.so on all the "common" C compilers and versions.
....... Then an installer package to copy the needed one could be written?
# The Linux I`m working to modify with all this is Tiny Core.
It doesn`t use a union, and uses Squash files for app. packages.
But a Debian download GUI is useful to most distros. and certainly Puppy.
I realized years ago that Puppy is one of the few distros. that uses gtkDialog.
So portability with gtkDialog GUIs is never going to be a reality.
BaCon with HUG making exec. files solves this "universal GUI" problem.
I`m beginning to remember how tedious and limited Basic is ( Quick Basic ).
Bash puts it to shame, too bad there isn`t a real free Bash to C Converter.
But for GUIs, use BaCon to support HUG, and use Bash for everything else.
### I think hug.so just being found by the Lib. path is best.
### Perhaps compile hug.so on all the "common" C compilers and versions.
....... Then an installer package to copy the needed one could be written?
# The Linux I`m working to modify with all this is Tiny Core.
It doesn`t use a union, and uses Squash files for app. packages.
But a Debian download GUI is useful to most distros. and certainly Puppy.
I realized years ago that Puppy is one of the few distros. that uses gtkDialog.
So portability with gtkDialog GUIs is never going to be a reality.
BaCon with HUG making exec. files solves this "universal GUI" problem.
I`m beginning to remember how tedious and limited Basic is ( Quick Basic ).
Bash puts it to shame, too bad there isn`t a real free Bash to C Converter.
But for GUIs, use BaCon to support HUG, and use Bash for everything else.
I think its important we have only a how to link a shared lib nothing else as the focus
step by step using the first example as a reference
even though the first code example was designed to link a shared lib it doesnt
(the app code is great we are only focusing on linking a shared lib during the compile)
and since everyone starts out using a first example it would be good
to use the excellent code and app in the first example thanks to GatorDog
as the practical walk though to linking a shared lib
it is a tricky thing to do so much better if you have some code to
to follow along and test with so that this feature can be used more often
step by step using the first example as a reference
even though the first code example was designed to link a shared lib it doesnt
(the app code is great we are only focusing on linking a shared lib during the compile)
and since everyone starts out using a first example it would be good
to use the excellent code and app in the first example thanks to GatorDog
as the practical walk though to linking a shared lib
it is a tricky thing to do so much better if you have some code to
to follow along and test with so that this feature can be used more often
Last edited by big_bass on Thu 29 Sep 2011, 06:09, edited 1 time in total.
- L18L
- Posts: 3479
- Joined: Sat 19 Jun 2010, 18:56
- Location: www.eussenheim.de/
quick brown fox
is existing anywhere, internationalized...big_bass wrote:...
one small suggestion to your great app
could you default to the quick brown fox to be in the display by default
...
Cheers
- Attachments
-
- quickbrownfox.png
- (19.43 KiB) Downloaded 875 times
Big_bass,
Great information! And I will attempt to add a little to it.
Good to know about ldconfig and ldd.
Another way to generate the hug.so/libhug.so
1. Open hug.bac in BaconGUI, Save as: libhug.bac (This takes care of copy/rename).
2. TOOLS/CONVERT/ Check "Create shared object" /CONVERT
3. As suggested above, copy library to a system path, for a standard use /usr/lib.
4. Update linker cache with the linux ldconfig command.
So along with your command line to compile with a link, there are at least
four ways to control compiling a program.
Using this as a small Bacon/hug test program:
If you uncomment one "INCLUDE" statement at a time and compile, you can check the size of the resulting binary file.
- For the second method, I made a copy of hug_imports.bac
without the CONST HUG_lib$ = "./libhug.so" statement; since libhug is linked in with
the command: bacon -l hug btest.bac I was surprised to see that it generated a slightly
larger file than compiling without linking. Note- compiling with "bacon -l ..." (linking) was only used with the 2nd example.
The 3rd & 4th examples do not use libhug.so, but instead use hug.bac directly. This is what
I refere to as creating a standalone program. ie. doesn't depend on a libhug.so file being on the target system.
- The third statement, by not selecting specific functions, essentially includes everything
including the ketchen sink; and results in the largest binary.
- The fourth statement generates a significanly smaller binary than the previous (3rd)method.
What's the deal (411/lowdown/story) on the other files reported by "ldd"?
linux-gate.so.1
libm.so.6
libdl.so.2
libhug.so
libc.so.6
/lib/ld-linux.so.2
Are these files that all linux systems need to function? (and therefore sure to be present?)
Or is this one of those maybe but it just depends... kind-of-sort-of things?
still learning,
rod
and what's up with Osama plastering his puss all over everybody's youtube videos?
Great information! And I will attempt to add a little to it.
Good to know about ldconfig and ldd.
Another way to generate the hug.so/libhug.so
1. Open hug.bac in BaconGUI, Save as: libhug.bac (This takes care of copy/rename).
2. TOOLS/CONVERT/ Check "Create shared object" /CONVERT
3. As suggested above, copy library to a system path, for a standard use /usr/lib.
4. Update linker cache with the linux ldconfig command.
So along with your command line to compile with a link, there are at least
four ways to control compiling a program.
Using this as a small Bacon/hug test program:
Code: Select all
' btest.bac
INCLUDE "/usr/share/BaCon/hug_imports.bac"
' Generates a 51K bytes binary
' ----------------------------------------
'INCLUDE "/usr/share/BaCon/hug_imports_wo_hugso.bac"
' bacon -l hug btest.bac
' Generates a 59k bytes binary
' ----------------------------------------
'INCLUDE "/usr/share/BaCon/hug.bac"
' Generates a 177K bytes binary
' ----------------------------------------
'INCLUDE "/usr/share/BaCon/hug.bac", INIT, WINDOW, ATTACH, BUTTON, CALLBACK, DISPLAY, QUIT
' Generates a 136K bytes binary.
' ----------------------------------------
INIT
Mainwin_ = WINDOW("Bacon Testing", 200, 100)
Ok_btn_ = BUTTON("OK", 100, 30)
ATTACH(Mainwin_, Ok_btn_, 50, 40)
CALLBACK(Ok_btn_, QUIT)
DISPLAY
- For the second method, I made a copy of hug_imports.bac
without the CONST HUG_lib$ = "./libhug.so" statement; since libhug is linked in with
the command: bacon -l hug btest.bac I was surprised to see that it generated a slightly
larger file than compiling without linking. Note- compiling with "bacon -l ..." (linking) was only used with the 2nd example.
The 3rd & 4th examples do not use libhug.so, but instead use hug.bac directly. This is what
I refere to as creating a standalone program. ie. doesn't depend on a libhug.so file being on the target system.
- The third statement, by not selecting specific functions, essentially includes everything
including the ketchen sink; and results in the largest binary.
- The fourth statement generates a significanly smaller binary than the previous (3rd)method.
What's the deal (411/lowdown/story) on the other files reported by "ldd"?
linux-gate.so.1
libm.so.6
libdl.so.2
libhug.so
libc.so.6
/lib/ld-linux.so.2
Are these files that all linux systems need to function? (and therefore sure to be present?)
Or is this one of those maybe but it just depends... kind-of-sort-of things?
still learning,
rod
and what's up with Osama plastering his puss all over everybody's youtube videos?
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
In the BaCon PET in the 'common' repo:sunburnt wrote:# Wouldn`t it be much better if hug.so were in /lib or /usr/lib ? ( in the Lib. path )
This seems all too obvious, but maybe there`s a method to the madness...
http://distro.ibiblio.org/quirky/pet_pa ... 0.23-1.pet
http://distro.ibiblio.org/quirky/pet_pa ... 0.23-1.pet
Does have /usr/lib/hug.so (in the first PET). Most recent puppies are using that PET (Wary, Racy, Slacko), so hug.so is in a "standard" location.
However, it is NOT in the shared library search path. For a start, the shared libraries must be named lib*.so*, otherwise 'ldconfig' (the utility that updates the library search path) ignores it.
Secondly, a BaCon app does not use the shared library load mechanism. It is hard-coded at compile-time to look for hug.so at a particular place.
So, if we all standardize on /usr/lib/hug.so, that would be good.
[url]https://bkhome.org/news/[/url]
Hi Barry,
Tnx for hug.so info.
Can you shed any light on:
Tnx for hug.so info.
Can you shed any light on:
rodWhat's the deal (411/lowdown/story) on the other files reported by "ldd" (ref: Bacon binary)?
linux-gate.so.1
libm.so.6
libdl.so.2
libc.so.6
/lib/ld-linux.so.2
Are these files that all linux systems need to function? (and therefore sure to be present?)
Or is this one of those maybe but it just depends... kind-of-sort-of things?
GatorDog; This are the base files most all Linux apps. use.
# These 2 are the main Linux "load and function" items as I understand it.
/lib/ld-linux.so.2
linux-gate.so.1
# libc and libm are C related. At least libc is I think...
libc.so.6
libm.so.6
# libdl It appears is used by the larger apps.
libdl.so.2
I`ve written a few scripts to get missing libs and to follow links to the real file.
I`m also in the process of a statistical analysis of lib usage to decide which libs
are used commonly enough to be shared, and uncommon ones to compile in.
The survey sample is about 3500 packages, so it`ll find most libs to be shared.
# These 2 are the main Linux "load and function" items as I understand it.
/lib/ld-linux.so.2
linux-gate.so.1
# libc and libm are C related. At least libc is I think...
libc.so.6
libm.so.6
# libdl It appears is used by the larger apps.
libdl.so.2
I`ve written a few scripts to get missing libs and to follow links to the real file.
I`m also in the process of a statistical analysis of lib usage to decide which libs
are used commonly enough to be shared, and uncommon ones to compile in.
The survey sample is about 3500 packages, so it`ll find most libs to be shared.
Last edited by sunburnt on Sun 25 Sep 2011, 06:54, edited 2 times in total.
everything below the line is copy and paste from the official documentation
all here in blue are just my comments
I hope that Peter the BaCon developer would shed some light on why hug.so isnt
itself a linkable library following the guidelines noted in the documentation
using a lib prefix like the libdemo example (which is the one I followed)
I am still convinced this is the correct way to link a library
but I am unsure now if hug.so itself was meant to be a linkable library
in the same manner
*I havent edited my prior post it can be referenced with the documentation below but I may later to reflect the how to with libdemo instead of libhug.so
using some example code so that we do have a workable practical example for linking a library to follow
here it is with the examples given in the documentation showing the code output
Converting 'libdemo.bac'... done.
Compiling 'libdemo.bac'... done.
Program 'libdemo.so' ready.
Converting 'program.bac'... done.
Compiling 'program.bac'... done.
Program 'program' ready.
shows that the documentation is correct
let's prove if the program runs
25
the output is 25
everything works
Joe
-------------------------------------------------------------------------
http://www.basic-converter.org/documentation.html
Creating and linking to libraries created with BaCon
With Bacon, it is possible to create libraries. In the world of Unix these are known as shared objects. The following steps should be sufficient to create and link to BaCon libraries.
Step 1: create a library
The below program only contains a function, which accepts one argument and returns a value.
FUNCTION bla (NUMBER n)
LOCAL i
i = 5 * n
RETURN i
END FUNCTION
In this example the program will be saved as 'libdemo.bac'. Note that the name must begin with the prefix 'lib'. This is a Unix convention. The linker will search for library names starting with these three letters.
Step 2: compile the library
The program must be compiled using the '-f' flag: bacon -f libdemo.bac
This will create a file called 'libdemo.so'.
Step 3: copy library to a system path
To use the library, it must be located in a place which is known to the linker. There are more ways to achieve this. For sake of simplicity, in this example the library will be copied to a system location. It is common usage to copy additional libraries to '/usr/local/lib': sudo cp libdemo.so /usr/local/lib
Step 4: update linker cache
The linker now must become aware that there is a new library. Update the linker cache with the following command: sudo ldconfig
Step 5: demonstration program
The following program uses the function from the new library:
PROTO bla
x = 5
result = bla(x)
PRINT result
This program first declares the function 'bla' as prototype, so the BaCon parser will not choke on this external function. Then the external function is invoked and the result is printed on the screen.
Step 6: compile and link
Now the program must be compiled with reference to the library created before. This can be done as follows: ./bacon -l demo program.bac
With the Unix command 'ldd' it will be visible that the resulting binary indeed has a dependency with the new library!
all here in blue are just my comments
I hope that Peter the BaCon developer would shed some light on why hug.so isnt
itself a linkable library following the guidelines noted in the documentation
using a lib prefix like the libdemo example (which is the one I followed)
I am still convinced this is the correct way to link a library
but I am unsure now if hug.so itself was meant to be a linkable library
in the same manner
*I havent edited my prior post it can be referenced with the documentation below but I may later to reflect the how to with libdemo instead of libhug.so
using some example code so that we do have a workable practical example for linking a library to follow
here it is with the examples given in the documentation showing the code output
Code: Select all
bacon -f libdemo.bac
Compiling 'libdemo.bac'... done.
Program 'libdemo.so' ready.
Code: Select all
bacon -l demo program.bac
Compiling 'program.bac'... done.
Program 'program' ready.
Code: Select all
ldd /root/bacon-examples/program
linux-gate.so.1 => (0xffffe000)
libm.so.6 => /lib/libm.so.6 (0xb7fbc000)
libdl.so.2 => /lib/libdl.so.2 (0xb7fb8000)
libdemo.so => /usr/lib/libdemo.so (0xb7fac000)
libc.so.6 => /lib/libc.so.6 (0xb7eb1000)
/lib/ld-linux.so.2 (0xb7fdf000)
shows that the documentation is correct
let's prove if the program runs
Code: Select all
./program
the output is 25
everything works
Joe
-------------------------------------------------------------------------
http://www.basic-converter.org/documentation.html
Creating and linking to libraries created with BaCon
With Bacon, it is possible to create libraries. In the world of Unix these are known as shared objects. The following steps should be sufficient to create and link to BaCon libraries.
Step 1: create a library
The below program only contains a function, which accepts one argument and returns a value.
FUNCTION bla (NUMBER n)
LOCAL i
i = 5 * n
RETURN i
END FUNCTION
In this example the program will be saved as 'libdemo.bac'. Note that the name must begin with the prefix 'lib'. This is a Unix convention. The linker will search for library names starting with these three letters.
Step 2: compile the library
The program must be compiled using the '-f' flag: bacon -f libdemo.bac
This will create a file called 'libdemo.so'.
Step 3: copy library to a system path
To use the library, it must be located in a place which is known to the linker. There are more ways to achieve this. For sake of simplicity, in this example the library will be copied to a system location. It is common usage to copy additional libraries to '/usr/local/lib': sudo cp libdemo.so /usr/local/lib
Step 4: update linker cache
The linker now must become aware that there is a new library. Update the linker cache with the following command: sudo ldconfig
Step 5: demonstration program
The following program uses the function from the new library:
PROTO bla
x = 5
result = bla(x)
PRINT result
This program first declares the function 'bla' as prototype, so the BaCon parser will not choke on this external function. Then the external function is invoked and the result is printed on the screen.
Step 6: compile and link
Now the program must be compiled with reference to the library created before. This can be done as follows: ./bacon -l demo program.bac
With the Unix command 'ldd' it will be visible that the resulting binary indeed has a dependency with the new library!
Last edited by big_bass on Tue 27 Sep 2011, 14:20, edited 1 time in total.
big_bass; Yeah, maybe hug.so can be made into libhug.so and universalized.
Of course it would take some work to Bacon itself to fix how it loads Hug.
# Apparently the canvas can be printed on, but will do multiple lines?
In Visual Basic I made a nice font dialog that printed the font types directly on the Form ( window ).
That way you could see them all at once without repeatedly clicking on them.
# I also need to check out the color dialog to see what it`s like.
Of course it would take some work to Bacon itself to fix how it loads Hug.
# Apparently the canvas can be printed on, but will do multiple lines?
In Visual Basic I made a nice font dialog that printed the font types directly on the Form ( window ).
That way you could see them all at once without repeatedly clicking on them.
# I also need to check out the color dialog to see what it`s like.
Creating and linking to libraries created with BaCon
here it is with the examples given in the documentation
I added showing the code output
using these two test files
call this libdemo.bac
call this program.bac
let's make the lib using the -f option
Converting 'libdemo.bac'... done.
Compiling 'libdemo.bac'... done.
Program 'libdemo.so' ready.
let's link the lib to the program using the -l option
notice that here you don't use the lib prefix in the command line
but this is the correct way to link libdemo.so to the program
Converting 'program.bac'... done.
Compiling 'program.bac'... done.
Program 'program' ready.
let's check if the library is seen by the ldd command
shows that the documentation is correct the libdemo.so is linked and understood by ldd
as being a real shared library *because it has a lib prefix
let's prove if the program runs
25
the output is 25
everything works as described (there needs to be some "re-thinking" about how this
really works ) in order to benefit from this advantage of having shared libs
Joe
here it is with the examples given in the documentation
I added showing the code output
using these two test files
call this libdemo.bac
Code: Select all
FUNCTION bla (NUMBER n)
LOCAL i
i = 5 * n
RETURN i
END FUNCTION
call this program.bac
Code: Select all
PROTO bla
x = 5
result = bla(x)
PRINT result
let's make the lib using the -f option
Code: Select all
bacon -f libdemo.bac
Compiling 'libdemo.bac'... done.
Program 'libdemo.so' ready.
let's link the lib to the program using the -l option
notice that here you don't use the lib prefix in the command line
but this is the correct way to link libdemo.so to the program
Code: Select all
bacon -l demo program.bac
Compiling 'program.bac'... done.
Program 'program' ready.
let's check if the library is seen by the ldd command
Code: Select all
ldd /root/bacon-examples/program
linux-gate.so.1 => (0xffffe000)
libm.so.6 => /lib/libm.so.6 (0xb7fbc000)
libdl.so.2 => /lib/libdl.so.2 (0xb7fb8000)
libdemo.so => /usr/lib/libdemo.so (0xb7fac000)
libc.so.6 => /lib/libc.so.6 (0xb7eb1000)
/lib/ld-linux.so.2 (0xb7fdf000)
shows that the documentation is correct the libdemo.so is linked and understood by ldd
as being a real shared library *because it has a lib prefix
let's prove if the program runs
Code: Select all
./program
the output is 25
everything works as described (there needs to be some "re-thinking" about how this
really works ) in order to benefit from this advantage of having shared libs
Joe
I must be missing something with libraries as to why they`re important.
They are shared code of any type, but isn`t a std. exec. also?
What do libraries do that an exec. can`t? "Must be in the sharing..."
Are they usable in some way that an exec. isn`t?
A copy of an exec. is put in ram each time it`s run, making for many copies.
But libraries there`s only one copy of in ram? ( This would make it useful. )
If this is so, are the libraries only kept in ram while in use by some app.?
They are shared code of any type, but isn`t a std. exec. also?
What do libraries do that an exec. can`t? "Must be in the sharing..."
Are they usable in some way that an exec. isn`t?
A copy of an exec. is put in ram each time it`s run, making for many copies.
But libraries there`s only one copy of in ram? ( This would make it useful. )
If this is so, are the libraries only kept in ram while in use by some app.?
Hi Joe,
Using libdemo.bac and program.bac,
First I put everything in a single program and just called "bla" as normal function. I'll call this the "complete" program.
The binary for this file is 34k (33,982)
Next I IMPORTed the libdemo.so into program.bac
This gave a file size of 34K (34096), just a few bytes larger than the
"complete" program. Note here that no path is specified to libdemo.so,
which is in /usr/lib. (For ref. "ldd" does not show a link to libdemo)
Then I compiled per above example using bacon -l demo program.bac.
The size is 38k (37,997).
(By the way, BaconGUI also has the option of compiling using linking.)
Next I tried this:Compiled binary for this is 34k.
Then I "linked" it with a hug.so file and compiled. That gave a binary of 38K.
(It would appear that linking increases the binary size by 4k.)
Then I compiled using INCLUDE "/usr/share/BaCon/hug.bac" . This binary is 177k.
Next I compiled using INCLUDE "/usr/share/BaCon/hug_imports.bac". This
binary is 51K.
If I understand it, linking is a soft link. ie. the lib file needs to exist some
where in the path. While using INCLUDE hard codes the path.
Going by binary size alone, linking has a definite advantage.
But, what about memory usage. Does the whole linked file get loaded into
memory when the program is run; or do modules get loaded as called.
Someone know about this?
Because when hug.bac is INCLUDEd in a program, you have the option
of only loading the modules specifically needed, thereby reducing memory
usage.
Regardless, it would seem to be more appropriate to have libhug.so than
hug.so. Then hug_imports.bac could point to libhug. The uptic being that
either soft or hard linking could be accommodated.
EDIT: See next post about why linking doesn't seem to work for hug.
Well, don't know if that classifies as "re-thinking", or even thinkin', but there you have it.
rod
Using libdemo.bac and program.bac,
First I put everything in a single program and just called "bla" as normal function. I'll call this the "complete" program.
Code: Select all
FUNCTION bla (NUMBER n)
LOCAL i
i = 5 * n
RETURN i
END FUNCTION
x = 5
result = bla(x)
PRINT result
Next I IMPORTed the libdemo.so into program.bac
Code: Select all
IMPORT "bla" FROM "libdemo.so" TYPE long
x = 5
result = bla(x)
PRINT result
"complete" program. Note here that no path is specified to libdemo.so,
which is in /usr/lib. (For ref. "ldd" does not show a link to libdemo)
Then I compiled per above example using bacon -l demo program.bac.
The size is 38k (37,997).
(By the way, BaconGUI also has the option of compiling using linking.)
Next I tried this:
Code: Select all
PRINT "do nothing"
Then I "linked" it with a hug.so file and compiled. That gave a binary of 38K.
(It would appear that linking increases the binary size by 4k.)
Then I compiled using INCLUDE "/usr/share/BaCon/hug.bac" . This binary is 177k.
Next I compiled using INCLUDE "/usr/share/BaCon/hug_imports.bac". This
binary is 51K.
If I understand it, linking is a soft link. ie. the lib file needs to exist some
where in the path. While using INCLUDE hard codes the path.
Going by binary size alone, linking has a definite advantage.
But, what about memory usage. Does the whole linked file get loaded into
memory when the program is run; or do modules get loaded as called.
Someone know about this?
Because when hug.bac is INCLUDEd in a program, you have the option
of only loading the modules specifically needed, thereby reducing memory
usage.
Regardless, it would seem to be more appropriate to have libhug.so than
hug.so. Then hug_imports.bac could point to libhug. The uptic being that
either soft or hard linking could be accommodated.
EDIT: See next post about why linking doesn't seem to work for hug.
Well, don't know if that classifies as "re-thinking", or even thinkin', but there you have it.
rod
Last edited by GatorDog on Wed 28 Sep 2011, 00:09, edited 1 time in total.
I decided I'd better try out linking libhug in an actual program.
Turns out a program using hug features won't convert if hug (libhug) definitions
aren't available before conversion. The conversion process executes before the program is compiled,
so linking hug is after the fact. Unless there's a way to PROTO wildcard the
whole libhug.so.
So the memory savings of linking still stand, just apparently doesn't apply to hug.
Big_Bass, a few post back, when you compiled pFontselect and linked to
libhug.so (bacon -l hug pfontselect.bac), did you first remove the
INCLUDE "/usr/share/BaCon/hug.bac" line from program? If not, I think that
may be why you succeded with linking hug
rod
Turns out a program using hug features won't convert if hug (libhug) definitions
aren't available before conversion. The conversion process executes before the program is compiled,
so linking hug is after the fact. Unless there's a way to PROTO wildcard the
whole libhug.so.
So the memory savings of linking still stand, just apparently doesn't apply to hug.
Big_Bass, a few post back, when you compiled pFontselect and linked to
libhug.so (bacon -l hug pfontselect.bac), did you first remove the
INCLUDE "/usr/share/BaCon/hug.bac" line from program? If not, I think that
may be why you succeded with linking hug
rod
instead of reviewing some standard linux package differences
between compiling static and compiling shared
the focus here is what does all this mean when we use BaCon
"most" of the binaries we compile in BaCon have no dependencies
they are stand alone apps without statically compiled libs
some apps have a dependency of hug.so as being the only
"special" shared dependency
but we can link to a shared library in the next example using curl
the linux app curl http://curl.haxx.se/download.html (not the bacon curl.bac)
-----------------------------------------------------------
using the official demo from the main bacon website
Symbol not found in library /usr/lib/libcurl.so.3: undefined symbol: curl_easy_pause
this means that you dont have curl the "real program" installed
for me I compiled and made this package curl-7.21.4-i486-1.txz
the error reads no shared lib--> libcurl.so.3
for this reason the BaCon program curldemo3 can not read the library and get the needed info
now install the curl-7.21.4-i486-1.txz package and try again
Downloaded 'documentation.pdf' using CURL version: libcurl/7.21.4 OpenSSL/0.9.8e zlib/1.2.3
this shows that BaCon compiled apps can and do utilize the shared libraries
in the same way that when you install other linux programs
Joe
between compiling static and compiling shared
the focus here is what does all this mean when we use BaCon
"most" of the binaries we compile in BaCon have no dependencies
they are stand alone apps without statically compiled libs
some apps have a dependency of hug.so as being the only
"special" shared dependency
but we can link to a shared library in the next example using curl
the linux app curl http://curl.haxx.se/download.html (not the bacon curl.bac)
-----------------------------------------------------------
using the official demo from the main bacon website
Code: Select all
./curldemo3
Symbol not found in library /usr/lib/libcurl.so.3: undefined symbol: curl_easy_pause
this means that you dont have curl the "real program" installed
for me I compiled and made this package curl-7.21.4-i486-1.txz
the error reads no shared lib--> libcurl.so.3
for this reason the BaCon program curldemo3 can not read the library and get the needed info
now install the curl-7.21.4-i486-1.txz package and try again
Code: Select all
./curldemo3
this shows that BaCon compiled apps can and do utilize the shared libraries
in the same way that when you install other linux programs
Joe
Last edited by big_bass on Thu 29 Sep 2011, 14:27, edited 1 time in total.