BaCon Bits

For discussions about programming, programming questions/advice, and projects that don't really have anything to do with Puppy.
Message
Author
User avatar
GatorDog
Posts: 138
Joined: Tue 12 Sep 2006, 16:43

#101 Post by GatorDog »

Once there`s a good copy of libhug.so ...
You already have a copy. Just copy or rename hug.so to libhug.so
post a few Bacon app examples showing the init code for it.
You've already been using it. When you use

Code: Select all

INCLUDE /usr/share/BaCon/hug_imports.bac"
hug_imports takes care of linking to hug.so/libhug.so

If hug_imports.bac hasn't been edited, it has a path set to /usr/lib/hug.so. (the default setup AFAIK)
If you prefer to use the name libhug.so, edit the top line in hug_imports.bac to /usr/lib/libhug.so (and make sure the file is there).

However, this does not conform to the model "as of today"; and that would make a bacon gui program
less compatible/portable amongst puppians. Which of course is counter productive. I know I would get
frustrated if I had to sort out and rename shared library files to get a program to run.

I think there's a kinda' chicken/egg thing goin' on here. :roll:

GatorDog

Saw a good 'make you think' movie on netflix recently, The Encounter

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#102 Post by sunburnt »

I`ll have to look up the Encounter and see what it`s about.

# Perhaps have both hug.so and libhug.so in /usr/lib in Puppy`s ISO?
Previously written apps would still work with hug.so, but new apps could
be written for libhug.so for a future when it`s a normal library.
Seems like a good direction even though Bacon is the only thing to use hug.


# Qs: Buttons highlight on mouse hover, any way to tell which one? REGISTER?
............ Or what to use instead of a button for a slide out sub menu hover spot.

You may have answered this... How to use any type of icons on buttons, etc.?

User avatar
GatorDog
Posts: 138
Joined: Tue 12 Sep 2006, 16:43

#103 Post by GatorDog »

# Qs: Buttons highlight on mouse hover, any way to tell which one? REGISTER?
............ Or what to use instead of a button for a slide out sub menu hover spot.
AMPG
You may have answered this... How to use any type of icons on buttons, etc.?
AMPG

Next question? :twisted:

The button mouse hover is certainly generating an event; but using it is another mater.
Something you can do with your existing code. Your top button opens and closes (expand/contract) it's window.
You can change the button text at your pleasure. So when it's closed, button text is "Open Squash List".
And when it's open, "Close Squash List". Personally I don't like gui's flip-flopping around just because the
mouse pointer happens to pass over something. And tooltips should be used sparingly. Too often they
obfuscate more than they illuminate.

In vovchik's pLogo, he imports his own icon and uses it in the title bar. There may be a similar
technique for buttons. Seek and ye shall find.

Rod

big_bass
Posts: 1740
Joined: Mon 13 Aug 2007, 12:21

#104 Post by big_bass »

Hey Rod @GatorDog

your recent summary of events was very clear

I think it will be useful to document
the steps better and confirm the results on different computers
I have a different glibc so I dont know if my recompiled binary
will work on newer puppy versions or not

but by having to recompile everything the steps are confirmed
I included all the edited files for clarity as only a reference
I would like that people use your original example pFontSelect-104-sa
with this new shared lib info
*pFontSelect-104-sa is now 79kb a saving of 108kb smaller this way
so worth all the research and testing that was involved

All edits below applied to these sources already
the binary was recompiled on txz_pup (same glibc as puppy 4.12)
notes documented by Joe Arose 9-29-2011

this is a note that was placed with the sources

===================
1.) EDIT SOURCE CODE
===================
pFontSelect-104-sa is 187kb "as is" in example one of the first post on the first page

http://www.murga-linux.com/puppy/viewtopic.php?t=69647

edit pFontSelect-104-sa.bac original source code

from (notice I just commented this statement out to be clearer)
'INCLUDE "/usr/share/BaCon/hug.bac", ATTACH, BUTTON, CALLBACK, CANVAS, CIRCLE, DISPLAY, ENTRY, FONT, FRAME, GET, GRAB$, HSEPARATOR, HUGOPTIONS, INIT, LIST, MARK, PROPERTY, QUIT, RADIO, SET, SPIN, SQUARE, STOCK, SYNC, TEXT, TIMEOUT, WINDOW

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

*notice here that the ,ATTACH ,BUTTON ... and so forth are NOT added to the end of hug_imports.bac

=================================================================================


===================
2.) EDIT hug_imports.bac
===================

from
' Imports when HUG is used as shared object
CONST HUG_lib$ = "./hug.so"

to
' Imports when HUG is used as shared object
CONST HUG_lib$ = "/usr/lib/libhug.so"

=================================================================================



===================
3.) make the shared lib libhug.so
===================
open hug.bac and save it as libhug.bac

bacon -f libhug

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

compile pFontSelect-104-sa.bac ( I used my hacked geany)
or simply bacon pFontSelect-104-sa.bac
pFontSelect-104-sa is now 79kb a saving of 108kb smaller this way


===================
4.) place libhug.so in /usr/lib
===================


a special note that libhug.so is not a compile time dependency
it is however a run time dependency
which means it is not needed in the iso at compile time

this is good if you want to keep up to date with hug.bac
and keep it updated


Peter the BaCon developer decides
what names to use (since he writes the source code and docs)
I prefer libhug.so
for the following of the Bacon Documentation is better understood
and for those that are used to thinking about shared libs (on linux)
having the *.so and the prefix lib are very familiar

I am just glad that smaller binaries result
using shared libs whatever the name is

a rose by any other name is still a rose :D

Joe
Attachments
pFontselect-1.0.4-shared.tar.gz
(94.39 KiB) Downloaded 359 times

big_bass
Posts: 1740
Joined: Mon 13 Aug 2007, 12:21

#105 Post by big_bass »

GatorDog
If hug_imports.bac hasn't been edited, it has a path set to /usr/lib/hug.so
thats not correct the official file is here (maybe you have an already edited file )
http://www.basic-converter.org/hug_imports.bac.html

"as is" without editing hug_imports.bac

' Imports when HUG is used as shared object
CONST HUG_lib$ = "./hug.so"



what does the trick though is telling the compiled app
where to look for the the libhug.so or hug.so
this is why we do edit
CONST HUG_lib$ = "/usr/lib/libhug.so"

since this is a run time library
that needs to be hard coded into the program

*I just dont want anyone else to trip up
and spend a lot of time just trying to get started correctly
figuring out what is needed to compile a shared lib

P.S a big thanks for all your examples ,comments and code

I will be going over all the Bacon *.bac files
and reporting things as they come I will
open a new thread for a more basic getting started with the official examples
as the focus ...and continue using and testing all your great apps here

Joe

User avatar
GatorDog
Posts: 138
Joined: Tue 12 Sep 2006, 16:43

#106 Post by GatorDog »

If hug_imports.bac hasn't been edited, it has a path set to /usr/lib/hug.so

thats not correct the official file is here (maybe you have an already edited file )
http://www.basic-converter.org/hug_imports.bac.html
I stand corrected :oops:
-----------------
Just had a power outage :evil:
So I booted a fresh pup 528 into memory (pfix=ram).
- /usr/lib/hug.so is there.
- /usr/share/BaCon/ dir is there with two lang definition files. (For nicoedit and vim I think)

I ran a couple of bacon programs that were compiled with hug_imports.bac pointing to /usr/lib/hug.so
One file ran fine. The other failed. It expected a feature available in a later hug verson. (see below)

This points to a need for version tracking for hug. Bacon has a reserved variable $VERSION, but
this is for bacon itself and does not apply to hug.

The only way I know to find the hug version number is to open hug.bac. Peter maintains a commented
section there that includes the hug version number.

I've been backing up older files by naming them (for example) hug.59.so, hug.60.so, etc.

Simply having /usr/lib/hug.so (or libhug.so) gives no clue to what your working with.
In earlier post in this thread, I made tar files for the latest (beta) versions of hug as they became available.

Another point I'll mention; the hug_imports.bac version is loosely tied to the hug.bac/hug.so version.
To wit-
- hug_imports.bac is the mechanism to load HUG features from the shared library, hug.so
- When Peter adds a new HUG feature, hug_imports.bac is updated to include loading those new features.
- If a program is compiled with the new hug_imports.bac, it expects all the features are available in /usr/lib/hug.so
- If hug.bac is only updated for a bug fix, then hug_imports.bac version doesn't change, as there is no new features added.
. (Probably an oversimplification but works for this discussion)
- This is why the second program I tried didn't run. The program was compiled with a newer hug_imports, which was looking for
. /usr/lib/hug.so, which it found. However, that hug.so is outdated (pup 528), so the program failed because it couldn't
. import a feature from hug.so

So version control is another issue to consider when offering bacon programs for Puppy.
I really don't want to be limited to the "offical" hug version in Puppy. The current beta versions of Bacon, hug and hug_imports
have several bug fixes and some new features.

I don't follow gtkDialog closely, but it seems that it too is under development. Therefore new scripts require the latest gtkDialog version.
So, wonder how that is being addressed?

In conclusion, to shoot for success, this is what I've done with the programs that I've recently posted.
1.) I include the source code. Anyone that has bacon set up can compile it on their machine.
. They can use hug_imports.bac for the smallest possible program. And I comment in the
. source what versions of bacon, hug etc. were used.
2.) I include a "standalone" version of the binary/executable program. This is compiled using INCLUDE ".../hug.bac".
. It makes for a significantly larger program, but, it should only have common linux dependencies, (gtk etc.) and
. should run independent of any bacon related settings or programs.

Your Mi!eage May Vary,
GatorDog

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#107 Post by sunburnt »

Hey guys, an item I looked into that GatorDog spoke of.

I ran "dd" on hug.so to see if I could find it`s version.
I found "1.0 build 24 beta r3" about half way down the output in rxvt.

Code: Select all

dd if=hug.so [of=hug.dd]
Providing the "of=" to make an output file just makes another copy of hug.
It seems to throw rxvt for a loop, I had to shut it down after doing this.

I can`t get sed to do anything with the output as it`s a binary file.
dd can convert, but I don`t know what it`s capabilities are.
If the output could be convert to text then sed might work.
It`s just one big long string with no LF or CR so grep isn`t much good.

seaside
Posts: 934
Joined: Thu 12 Apr 2007, 00:19

#108 Post by seaside »

sunburnt wrote:Hey guys, an item I looked into that GatorDog spoke of.

I ran "dd" on hug.so to see if I could find it`s version.
I found "1.0 build 24 beta r3" about half way down the output in rxvt.

Code: Select all

dd if=hug.so [of=hug.dd]
Providing the "of=" to make an output file just makes another copy of hug.
It seems to throw rxvt for a loop, I had to shut it down after doing this.

I can`t get sed to do anything with the output as it`s a binary file.
dd can convert, but I don`t know what it`s capabilities are.
If the output could be convert to text then sed might work.
It`s just one big long string with no LF or CR so grep isn`t much good.
Hey sunburnt,

How about the command "strings".

Regards,
s

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#109 Post by sunburnt »

SeaSide; That did it !!! I`m always amazed at the number of exec. there are.
Unix has been around sooo long that there`s a file for almost everything.

This gets the "build version" from /usr/lib/hug.so

Code: Select all

strings /usr/lib/hug.so |grep ' build '

User avatar
GatorDog
Posts: 138
Joined: Tue 12 Sep 2006, 16:43

#110 Post by GatorDog »

seaside,
Wow!
strings
Who knew?

Thank you for taking time to share that. That's (another) one I hadn't run into before.

sunburnt,
The "build" that is reported is the version of "Bacon" that was used to generate the hug.so file.
So the search goes on.
-------------------

hug_imports.bac looks for hug.so
Q. If a new version of hug.so includes the version number (hug.62.so), can a pet package not only
put it in /usr/lib/ but also take care of linking hug.so/libhug.so to the new hug.62.so?

GatorDog

big_bass
Posts: 1740
Joined: Mon 13 Aug 2007, 12:21

#111 Post by big_bass »

Hey guys

great ideas

probably the fastest most secure way of knowing for sure its the right one is just

Code: Select all

md5sum /usr/lib/libhug.so

Code: Select all

md5sum /usr/lib/hug.so
then place that in the source code

in the header maybe the third line down of hug_imports.bac
then quickly use sed or the head command to get the value
or place it in an array if its always in the same place

how about this for keeping up to date with Bacon
to avoid old files in the first place this is what I use
*if you want to use hug.so instead just edit the code
the default is libhug.so (this way I dont clobber your hug.so )



used on the new *.so

Code: Select all

md5sum libhug.so >md5sum_libhug.txt 
MD=$(<md5sum_libhug.txt)
sed -i "2a \'$MD " hug_imports.bac
to keep your thread cleaner to read I'll point to the full source code
http://www.murga-linux.com/puppy/viewto ... 36&start=3

Joe

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#112 Post by sunburnt »

Looks like with all this version problem, compiling with hug.bac is the way to go.
Develop with hug_imports.bac for a fast compile, and use hug.bac for the final app.
Seems to only add about 100 KB or so to the size. For GUIs that`s okay.
And any cli or code only app. ( no GUI ), I would write in Bash anyway.


# A thought... Each compile the same hug.bac file is compiled.
Why not compile it once into hug.so and then include it in the app.?

I assume Peter would have already done this if he could have.
But what`s the problem with adding already compiled code?
As I understand it, the include code gets pasted in at the line of the include.
And the include is the first line in the file, do a "join" files?

I`m sure there`s start points in ram for the calls to hug, etc., etc., etc.
But wouldn`t these be the same for all apps.?

A new compiler would be needed I suppose... Just thinking...

User avatar
GatorDog
Posts: 138
Joined: Tue 12 Sep 2006, 16:43

#113 Post by GatorDog »

Why not compile it once into hug.so and then include it in the app.?
...
And the include is the first line in the file, do a "join" files?
Why not compile it once into hug.so and then include it in the app.?
The INCLUDE file is a text file. Similar to a dot file ( . filename ) in bash.
You're right, the text gets pasted in at that position.

From BaconGUI (and probably from the command line too), there is an option to
save the intermediate c-code. There is also a Bacon command "USEC" that allows
using c-code in a Bacon program. So in theory, the c-code could be generated
and use in a bacon program. But I'll bet that'd be a can of worms. :roll:

g

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#114 Post by sunburnt »

A can of worms it certainly sounds like, but a promising approach.
Someone like Peter would have little problem with the concept.

Like Basic itself, a next layer of code is needed to streamline the methods.
Like so many languages and other tools I see, too much code to do the job.
You look at what`s needed to describe what`s wanted and it`s not much at all.
Hug is pretty straight forward, and it`s syntax is way better than gtkDialog.

User avatar
GatorDog
Posts: 138
Joined: Tue 12 Sep 2006, 16:43

Bacon port of "resizepfile"

#115 Post by GatorDog »

"resizepfile.sh" is a Puppy script to resize the Puppy save file.
This program is a port of the resizepfile script to a Bacon program.
In particular it makes use of Bacon's Associative array.
An associative array is an array of which the index is determined by a string, instead of a number. Associative arrays use
round brackets '(…)' instead of the square brackets '[…]' used by normal arrays.

An associative array can use any kind of string for the index, and it can have an unlimited amount of elements.

Code: Select all

fullname$("bob") = "Robert Fuller"
fullname$("jane") = "Janet Jenkins"
name$ = "bob"
PRINT fullname$(name$)
Output: Robert Fuller
EDIT: Corrected missing "$" on variable name.

The resizepfile shell script uses an external file (/etc/rc.d/PUPSTATE) to retrieve variables and their values.
The variables are in shell syntax. ie. variable = 'text'. This syntax is decoded and assigned
values in Bacon using an associative array.

This is the contents of (my) /etc/rc.d/PUPSTATE:

Code: Select all

PUPMODE=12
PDEV1='sr1'
DEV1FS='iso9660'
PUPSFS='sda1,vfat,/l5281108.173/lupu_528.sfs'
PUPSAVE='sda1,vfat,/lupusave-528_IM-.3fs'
PMEDIA='cd'
#ATADRIVES is all internal ide/pata/sata drives, excluding optical, excluding usb...
ATADRIVES='sda '
#ATAOPTICALDRIVES is list of non-usb optical drives...
ATAOPTICALDRIVES='sr0 sr1 '
#these directories are unionfs/aufs layers in /initrd...
SAVE_LAYER='/pup_rw'
PUP_LAYER='/pup_ro2'
#The partition that has the lupusave file is mounted here...
PUP_HOME='/mnt/dev_save'
#(in /initrd) ...note, /mnt/home is a link to it.
#this file has extra kernel drivers and firmware...
ZDRV=''
#complete set of modules in the initrd (moved to main f.s.)...
ZDRVINIT='no'
#Partition no. override on boot drive to which session is (or will be) saved...
PSAVEMARK=''
The variable name (ex. PUPMODE) will be used for the associative arrays index (ex. Pupstate$("PUPMODE")
I used a SUB-routine to translate the shell variables. Here is commented code.

Code: Select all

' ------------------
SUB READ_PUPSTATE_VARIABLES
' ------------------
	' Declare the associative array
	DECLARE Pupstate$ ASSOC STRING

	' Open the file for reading
	OPEN Pupstate_file$ FOR READING AS Filehandle_

	' Check for end of file
	WHILE NOT(ENDFILE(Filehandle_)) DO

		' read in line by line
		READLN Pass$ FROM Filehandle_

		' CHOP$ - remove leading/trailing space, tab, CR, etc.
		Pass$ = CHOP$(Pass$)

		' If line begins with "#" it's a comment.
		IF LEFT$(Pass$, 1) = "#" THEN
			'Dump bash comment lines
			CONTINUE
		END IF

		' If line contains "=", there's a variable assignment going on.
		IF INSTR(Pass$, "=") THEN

			' Break line up using "=" as seperator
			' Arg$[1] will be variable name. Arg$[2] is the value.
			SPLIT Pass$ BY "=" TO Arg$ SIZE na

			' Replace the single quotes with null
			Pass$ = CHOP$(REPLACE$(Arg$[2], Single_quote$, ""))

			' Set up variable = value
			Pupstate$(Arg$[1]) = Pass$
		END IF
	WEND
	' Close file
	CLOSE FILE Filehandle_
END SUB
This is a simple use of associative arrays. There are some extended examples in the Bacon reference pages.
The rest of the program implements the actions of the shell script along with the addition of a GUI.

GatorDog
Attachments
resizepfile.png
(36.56 KiB) Downloaded 1147 times
Bacon-resizepfile-src.tar.gz
Bacon source code for resizepfile.bac
(3.64 KiB) Downloaded 509 times
Last edited by GatorDog on Mon 31 Oct 2011, 18:59, edited 1 time in total.

big_bass
Posts: 1740
Joined: Mon 13 Aug 2007, 12:21

#116 Post by big_bass »

Hey GatorDog

thanks for posting that http://www.murga-linux.com/puppy/viewto ... &start=114 (I had already ported the old xmessage resizepfile.sh
to Xdialog and added larger save options) so going over your BaCon version
will be easier for me to understand and follow this new associative array in action
thanks this will be fun to learn in Bacon :D

*I know this is a BaCon thread but only to ease into understanding what is happening
the equivalent bash4 example is given below using your example converted to bash4

GatorDog
# associative array Bacon example
fullname("bob") = "Robert Fuller"
fullname("jane") = "Janet Jenkins"
name = "bob"
echo $fullname($name)


big_bass

Code: Select all

# bash4 associative array equivalence to the Bacon example above

declare -A fullname
#       -A option declares associative array.

fullname[bob]="Robert Fuller"
fullname[jane]="Janet Jenkins"


echo "bob's fullname is ${fullname[bob]}."
echo "jane's fullname is ${fullname[jane]}."

echo "${!fullname[*]}"   # The array indices used
Joe

User avatar
GatorDog
Posts: 138
Joined: Tue 12 Sep 2006, 16:43

#117 Post by GatorDog »

Hi Joe,

To further the comparison a little, LOOKUP is used to get the array indices in Bacon.
(LOOKUP works similar to the SPLIT command)
LOOKUP <assoc> TO <array> SIZE <variable>

Code: Select all

LOOKUP Pupstate$ TO Index_name$ SIZE Count
and to access -

Code: Select all

FOR x = 0 TO Count - 1
    PRINT Index_name$[x]
NEXT 
GatorDog


User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#119 Post by sunburnt »

Hi guys; Thought I`d ask before just doing this in Bash.

My years of Quick Basic are slowly coming back to me as I use BaCon.
I recalled that Basic works with arrays not lists, Bash is powerful with both.
Basic`s problem with arrays is getting data into them... It`s one line at a time.
Bash will read and write files and arrays all in one statement.
I`m going to suggest this for the next BaCon, and also passing arrays to/from Bash.

# The Q:
An easy way to get the number of lines in a file to declare the array index?
All I can think of to do is:

Code: Select all

	OPEN File$ FOR INPUT AS file
	i = -1
	WHILE NOT(ENDFILE(file)) DO
		INCR i
		READLN txt$ FROM file
	WEND
	CLOSE file

	GLOBAL Array$[i] TYPE STRING

	OPEN File$ FOR INPUT AS file
	i = 0
	WHILE NOT(ENDFILE(file)) DO
		READLN txt$ FROM file
		IF ENDFILE(file) THEN BREAK
		Array$[i] = txt$
		INCR i
	WEND
	CLOSE file
Not a very efficient or elegant way to do anything at all.!

seaside
Posts: 934
Joined: Thu 12 Apr 2007, 00:19

#120 Post by seaside »

sunburnt,

Perhaps something like this-

Code: Select all

i$=EXEC$("wc -l filename")
Whether that's faster or not remains to be seen.... :)

regards,
s

Post Reply