The time now is Thu 26 Apr 2018, 07:49
All times are UTC - 4 |
Page 6 of 12 [168 Posts] |
Goto page: Previous 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 Next |
Author |
Message |
sunburnt

Joined: 08 Jun 2005 Posts: 5087 Location: Arizona, U.S.A.
|
Posted: Tue 20 Sep 2011, 00:34 Post subject:
|
|
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?
|
Back to top
|
|
 |
GatorDog

Joined: 12 Sep 2006 Posts: 136
|
Posted: Tue 20 Sep 2011, 01:36 Post subject:
|
|
sunburnt
Quote: | # 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
|
Back to top
|
|
 |
sunburnt

Joined: 08 Jun 2005 Posts: 5087 Location: Arizona, U.S.A.
|
Posted: Tue 20 Sep 2011, 05:59 Post subject:
|
|
# 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: | 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.
|
Back to top
|
|
 |
big_bass
Joined: 13 Aug 2007 Posts: 1742
|
Posted: Tue 20 Sep 2011, 09:41 Post subject:
|
|
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: |
(<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: |
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
Description |
|
Filesize |
88.91 KB |
Viewed |
780 Time(s) |

|
Last edited by big_bass on Thu 29 Sep 2011, 02:07; edited 2 times in total
|
Back to top
|
|
 |
GatorDog

Joined: 12 Sep 2006 Posts: 136
|
Posted: Tue 20 Sep 2011, 13:16 Post subject:
|
|
sunburnt wrote: | # 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?
Quote: | # 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
Quote: | # 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?
Quote: | # Error at "empty line"...
Line 2: lstGRPS_
Cause: 'lstGRPS_' undeclared here (not in a function)
Code: | 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.) Quote: | 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: | ' ------------------
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?
Quote: | # 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
|
Back to top
|
|
 |
GatorDog

Joined: 12 Sep 2006 Posts: 136
|
Posted: Tue 20 Sep 2011, 13:21 Post subject:
|
|
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)
|
Back to top
|
|
 |
sunburnt

Joined: 08 Jun 2005 Posts: 5087 Location: Arizona, U.S.A.
|
Posted: Tue 20 Sep 2011, 17:53 Post subject:
|
|
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.
|
Back to top
|
|
 |
big_bass
Joined: 13 Aug 2007 Posts: 1742
|
Posted: Wed 21 Sep 2011, 01:09 Post subject:
|
|
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
Last edited by big_bass on Thu 29 Sep 2011, 02:09; edited 1 time in total
|
Back to top
|
|
 |
L18L
Joined: 19 Jun 2010 Posts: 3431 Location: www.eussenheim.de/
|
Posted: Wed 21 Sep 2011, 14:24 Post subject:
quick brown fox |
|
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
... |
is existing anywhere, internationalized...
Cheers
Description |
|
Filesize |
19.43 KB |
Viewed |
860 Time(s) |

|
|
Back to top
|
|
 |
GatorDog

Joined: 12 Sep 2006 Posts: 136
|
Posted: Thu 22 Sep 2011, 00:00 Post subject:
|
|
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: | ' 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?
|
Back to top
|
|
 |
BarryK
Puppy Master

Joined: 09 May 2005 Posts: 8529 Location: Perth, Western Australia
|
Posted: Thu 22 Sep 2011, 06:12 Post subject:
|
|
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... |
In the BaCon PET in the 'common' repo:
http://distro.ibiblio.org/quirky/pet_packages-common/bacon-1.0.23-1.pet
http://distro.ibiblio.org/quirky/pet_packages-common/bacon_DEV-1.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.
_________________ http://bkhome.org/news/
|
Back to top
|
|
 |
GatorDog

Joined: 12 Sep 2006 Posts: 136
|
Posted: Thu 22 Sep 2011, 12:08 Post subject:
|
|
Hi Barry,
Tnx for hug.so info.
Can you shed any light on: Quote: | 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
|
Back to top
|
|
 |
sunburnt

Joined: 08 Jun 2005 Posts: 5087 Location: Arizona, U.S.A.
|
Posted: Thu 22 Sep 2011, 13:02 Post subject:
|
|
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.
Last edited by sunburnt on Sun 25 Sep 2011, 02:54; edited 2 times in total
|
Back to top
|
|
 |
big_bass
Joined: 13 Aug 2007 Posts: 1742
|
Posted: Thu 22 Sep 2011, 22:14 Post subject:
|
|
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: | bacon -f libdemo.bac |
Converting 'libdemo.bac'... done.
Compiling 'libdemo.bac'... done.
Program 'libdemo.so' ready.
Code: | bacon -l demo program.bac |
Converting 'program.bac'... done.
Compiling 'program.bac'... done.
Program 'program' ready.
Code: | ldd /root/bacon-examples/program |
Quote: | 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
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!
Last edited by big_bass on Tue 27 Sep 2011, 10:20; edited 1 time in total
|
Back to top
|
|
 |
sunburnt

Joined: 08 Jun 2005 Posts: 5087 Location: Arizona, U.S.A.
|
Posted: Sat 24 Sep 2011, 19:58 Post subject:
|
|
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.
|
Back to top
|
|
 |
|
Page 6 of 12 [168 Posts] |
Goto page: Previous 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 Next |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|