BaCon Bits

[sunburnt]

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?

[GatorDog]

sunburnt

# 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?

That's how I understand 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

[sunburnt]

# 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)

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

### 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.

[big_bass]

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

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

so I replaced the medium with light and bingo !

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>")

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

[GatorDog]

# Wouldn`t it be much better if hug.so were in /lib or /usr/lib ? ( in the Lib. path )

I started using Bacon when I switched to PUP 525. There were some issues
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?

# 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 good either way

# 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?

Good point. Maybe some things might fit better in vovchik's original thread?

# 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

### 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.

In a nutshell - DATA stores "values" not variables. (The widget names are variables.)

READ <x[$]>

Type: statement

Reads a value from a DATA block into variable <x>.

So, DATA "some string data" is cool.
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")

Haven't tried it, but at least it looks pretty, don't you think?

# Also, is there a way to read a file in one command ( not looping )?

Not that I'm aware of.

rod er... I mean Gatordog

[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)

[sunburnt]

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.

[big_bass]

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

[L18L]

...
one small suggestion to your great app
could you default to the quick brown fox to be in the display by default
...

is existing anywhere, internationalized...
Cheers

[GatorDog]

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:

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

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?

[BarryK]

# 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...

In the BaCon PET in the 'common' repo:
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.

[GatorDog]

Hi Barry,
Tnx for hug.so info.

Can you shed any light on:

What'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?

rod

[sunburnt]

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.

[big_bass]

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

Code: Select all

bacon -f libdemo.bac 

Converting 'libdemo.bac'... done.
Compiling 'libdemo.bac'... done.
Program 'libdemo.so' ready.

Code: Select all

 bacon -l demo program.bac 

Converting 'program.bac'... done.
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

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!

[sunburnt]

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.

[big_bass]

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

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 

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

Code: Select all

 bacon -l demo program.bac 

Converting 'program.bac'... done.
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

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

[sunburnt]

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.?

[GatorDog]

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.

Code: Select all

FUNCTION bla (NUMBER n)
LOCAL i
i = 5 * n
RETURN i
END FUNCTION 

x = 5
result = bla(x)
PRINT result

The binary for this file is 34k (33,982)

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

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:

Code: Select all

PRINT "do nothing"

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

[GatorDog]

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

[big_bass]

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

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 

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