A couple of apps for BaCON development

[doyle]

Hi,

I made a sqlite database builder and reader for making a database of IMPORT and CONST statements from the *.bac include files. The reader has a entry where you can paste the IMPORT/CONST name and read out the full IMPORT/CONST information. You also can paste it into your application.

Thanks for all of the code snippets. I borrowed heavily from them for code, ideas, etc.

To make a database:

Create a folder and add all of your files that you want to read the IMPORT/CONST information from. (*MUST* use *.bac ext) Drop the mkdb executable file in there and run it. It will create a database of all of the IMPORTs and CONSTs in the files. The database is named 'import.sdb'

To read out a IMPORT or CONST:

Place the rddb executable in the same folder as the 'import.sdb' file and run it. You will see an entry to paste the query into and another for the full IMPORT or CONST statement. If you want to search for an IMPORT, just paste into the top entry and hit 'Find'. Then you may press the copy to clipboard button and the full line is put into the clipboard for you to paste into your code. If you want to search for a CONST, tick the checkbox and it will search for a CONST instead of an IMPORT. Then copy into the clipboard as above.

Any comments, bug reports, etc. appreciated.

Enjoy and have fun!

Get the code here: www.bcxgurus.com/bcxusers/doyle/Puppy_Linux/db.tar.gz

Doyle

[Pjot]

Hi Doyle,

This is a very cool program! Nice to see how SQlite and GTK/Glade can be combined.

Nevertheless I do have a comment, as 'rddb.bac' segfaulted on my 64-bit Linux distributions, both Slackware and Ubuntu ('mkdb.bac' works fine).

To get your program running, I had to remove two IMPORT functions from your code in 'rddb.bac':


IMPORT "gtk_main" FROM lib_Gtk$ TYPE void
IMPORT "gtk_set_locale" FROM lib_Gtk$ TYPE char*
IMPORT "gtk_init(int*,void*)" FROM lib_Gtk$ TYPE void
IMPORT "gtk_main_quit" FROM lib_Gtk$ TYPE void
IMPORT "gtk_widget_show_all(long)" FROM lib_Gtk$ TYPE void
IMPORT "gtk_exit(int)" FROM lib_Gtk$ TYPE void
REM IMPORT "g_signal_connect_data(long,char*,long,long,long,int)" FROM lib_Gobject$ TYPE void
REM IMPORT "g_object_unref(long)" FROM lib_Gobject$ TYPE void
IMPORT "glade_xml_new_from_buffer(char*, long, char*, char*)" FROM lib_Glade$ TYPE long
IMPORT "glade_xml_get_widget(long, char*)" FROM lib_Glade$ TYPE long
IMPORT "glade_xml_signal_autoconnect(long)" FROM lib_Glade$ TYPE void
IMPORT "glade_xml_signal_connect(long,char*,long)" FROM lib_Glade$ TYPE void
IMPORT "gtk_entry_get_text(long)" FROM lib_Gtk$ TYPE char*
IMPORT "gtk_entry_set_text(long,char*)" FROM lib_Gtk$ TYPE void
IMPORT "gtk_toggle_button_get_active(long)" FROM lib_Gtk$ TYPE int


This is an issue which has been discussed in the past, in the previous forum, relating to importing Glade and functions from gObject at the same time. Also Armando Rivera, who ported BCX to Linux, has put some effort into sorting out this problem. However until today I was unable to identify the reason.

So if the 'signal_connect' is commented, of course there are no callback functions to the program. In that case, you must define the name of the callback function in the Glade file itself. Then also the 'rddb.bac' file must be compiled with the '-export-dynamic' option to allow Glade calling back.

Thanks and regards
Peter

[doyle]

Sept 20, 2010 13:07:39 GMT 1 Pjot said:

Hi Doyle,


So if the 'signal_connect' is commented, of course there are no callback functions to the program. In that case, you must define the name of the callback function in the Glade file itself.

Sorry about the problems. Exactly how do you define the name of the callback function in Glade? I missed that one or am not understanding what you mean here.

I had some problems trying to use Glade for the events even using the '-export-dynamic' option. I don't remember the exact details now but I'm sure I'll run into it again. So I used 'g_signal_connect_data' and it seemed to work fine.

Thanks for the explanation. I'll try to change it back to using Glade functions only and see what happens.

Thanks again,
Doyle

[doyle]

Sept 20, 2010 23:19:47 GMT 1 doyle said:

I'll try to change it back to using Glade functions only and see what happens.

Well I finally got it to compile without errors but...

No matter what I do, I now get the following:

ERROR: signal for SEGMENTATION FAULT received - memory invalid or array out of bounds? Try to compile the program with TRAP LOCAL to find the cause.
Exit code: 11

I AM using TRAP LOCAL so I don't know what else to do. I do know it is getting the segfault when opening the sqlite database file.

I can comment out the following line (along with the following close database line):



mydb = DB_OPEN(datafile$)



Now I don't segfault. Any ideas? What possible problem could using glade have to do with using the sqlite include file? Maybe using the "-export-dynamic" flag is messing up sqlite?

Thanks,
Doyle

[Pjot]

Hi Doyle,

Sorry for all the trouble you are going through! In fact, the change is a very small one. Looking at your DATA lines, I can see a signal definition for each widget already. For example:


line 83:
DATA "<signal name=\"destroy\" handler=\"on_window1_destroy\"/>"

line 97:
DATA  "<signal name=\"activate\" handler=\"on_entry1_activate\"/>"

...etc...


So there is no need to use 'g_signal_connect' anyway, as you already have defined the callback functions for each widget correctly.

However, Glade must be instructed to actually connect the signals and the functions it finds in the Glade definition. For this you need to use the command 'glade_xml_signal_autoconnect'.

Therefore, right after the 'glade_xml_new_from_buffer' you can add this autoconnect and it all works out-of-the-box.

Regarding the TRAP LOCAL, it was put it just before the INCLUDE statement. But the INCLUDE itself ends with TRAP SYSTEM, so if the INCLUDE file is parsed BaCon comes back to the program with a different TRAP definition. Therefore it is better to put the TRAP LOCAL behind the INCLUDE statement.

For your convenience the complete 'rddb' program with the changes as it works for me, on several platforms:

rddb.bac

I have converted/compiled it as follows: ./bacon -o -export-dynamic rddb

Regards
Peter

[doyle]

Sept 21, 2010 8:41:12 GMT 1 Pjot said:

Hi Doyle,

Sorry for all the trouble you are going through! In fact, the change is a very small one. Looking at your DATA lines, I can see a signal definition for each widget already. For example:


line 83:
DATA "<signal name=\"destroy\" handler=\"on_window1_destroy\"/>"

line 97:
DATA  "<signal name=\"activate\" handler=\"on_entry1_activate\"/>"

...etc...


So there is no need to use 'g_signal_connect' anyway, as you already have defined the callback functions for each widget correctly.

However, Glade must be instructed to actually connect the signals and the functions it finds in the Glade definition. For this you need to use the command 'glade_xml_signal_autoconnect'.

Therefore, right after the 'glade_xml_new_from_buffer' you can add this autoconnect and it all works out-of-the-box.

Thanks, I have the program like this now. Unfortunately now it doesn't work here at all.

Regarding the TRAP LOCAL, it was put it just before the INCLUDE statement. But the INCLUDE itself ends with TRAP SYSTEM, so if the INCLUDE file is parsed BaCon comes back to the program with a different TRAP definition. Therefore it is better to put the TRAP LOCAL behind the INCLUDE statement.

Thanks for this explanation.

For your convenience the complete 'rddb' program with the changes as it works for me, on several platforms:

rddb.bac

I have converted/compiled it as follows: ./bacon -o -export-dynamic rddb

Thanks, unfortunately nothing I do seems to allow rddb (my version or yours above) to access the database now. It immediately closes the program and nothing is shown with the TRAP statements. So, does Sqlite have a problem with "-export-dynamic" ?

My full command line is: bacon -o -export-dynamic -d /tmp $(FilePath$)$(FileName)

I'm either going to have to write this without glade, revert back to the way it was using g_signal_connect_data or figure out why glade and sqlite don't seem to work very well together!

Any suggestions as to which way to go? Or what might be wrong?

Thanks
Doyle

[Pjot]

Weird! No problems here, neither with SQlite. I would not expect this compiler flag to have effect on SQlite, but then again, one does never know.

So it would be interesting to see where the program bails out.

Can you add the line TRACE ON to your program, just after the TRAP LOCAL for example, and recompile? Now execute the resulting binary and start running it by pressing the space bar. Each subsequent space bar press will print each step of your program on screen. This way you can see how far it gets. Please let me know where it stops.

Also I am interested in your Glade version and GTK version, can you let me know?

Thanks,
Peter

[doyle]

Sept 22, 2010 8:31:59 GMT 1 Pjot said:

Weird! No problems here, neither with SQlite. I would not expect this compiler flag to have effect on SQlite, but then again, one does never know.

So it would be interesting to see where the program bails out.

Can you add the line TRACE ON to your program, just after the TRAP LOCAL for example, and recompile? Now execute the resulting binary and start running it by pressing the space bar. Each subsequent space bar press will print each step of your program on screen. This way you can see how far it gets. Please let me know where it stops.

Interesting. I didn't know about TRACE ON. Guess I missed that one. But I could have told you where it bombed.

rddb.bac 290: mydb = DB_OPEN(datafile__b2c__string_var)
>Exit code: 0 Signal: 11

I attached the full TRACE as a text file.

Also I am interested in your Glade version and GTK version, can you let me know?

GTK version 2.20.0
Glade 3.6.7
Puppy Linux 5.0.1

Thanks,
Doyle


UPDATE:

I've been adding print statements trying to find the problem. I modified the sqlite3.bac include file like this:

FUNCTION DB_OPEN(STRING name)

LOCAL db, result
PRINT DB_STATUS$(db)
result = sqlite3_open(name, ADDRESS(db))

IF result THEN RETURN result

RETURN db

END FUNCTION


I now see this:



rddb.bac 289: ' Open the database
rddb.bac 290: mydb = DB_OPEN(datafile__b2c__string_var)
out of memory



[Pjot]

Hi Doyle,

Well, I have an old Puppy Linux 4.2.1 installation and your program starts, but when performing a database lookup it crashes there too. With 'valgrind' we can see where where the problem is:

# mksh ./bacon.ksh -o -g -o -export-dynamic -p rddb
Starting conversion... done.
Starting compilation... done.
Program 'rddb' ready.
# ./rddb
Segmentation fault
# valgrind ./rddb
==31636== Memcheck, a memory error detector
==31636== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==31636== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==31636== Command: ./rddb
==31636==
==31636== Invalid read of size 4
==31636== at 0x80547E1: ?? ?
==31636== Address 0x54fc6e8 is 0 bytes after a block of size 48 alloc'd
==31636== at 0x401C7E8: malloc (vg_replace_malloc.c:195)
==31636== by 0x45796FD: ?? ? (in /usr/lib/libsqlite3.so.0.8.6)
==31636== by 0x459E7E7: ?? ? (in /usr/lib/libsqlite3.so.0.8.6)
==31636==
==31636== Conditional jump or move depends on uninitialised value(s)
==31636== at 0x80547E1: ?? ?
==31636==
==31636==
==31636== Process terminating with default action of signal 8 (SIGFPE)
==31636== Integer divide by zero at address 0x6395C774
==31636== at 0x80547E9: ?? ?
==31636==
==31636== HEAP SUMMARY:
==31636== in use at exit: 1,565,732 bytes in 12,290 blocks
==31636== total heap usage: 40,382 allocs, 28,092 frees, 7,632,536 bytes allocated
==31636==
==31636== LEAK SUMMARY:
==31636== definitely lost: 1,792 bytes in 7 blocks
==31636== indirectly lost: 3,936 bytes in 194 blocks
==31636== possibly lost: 1,125,428 bytes in 6,808 blocks
==31636== still reachable: 434,576 bytes in 5,281 blocks
==31636== suppressed: 0 bytes in 0 blocks
==31636== Rerun with --leak-check=full to see details of leaked memory
==31636==
==31636== For counts of detected and suppressed errors, rerun with: -v
==31636== Use --track-origins=yes to see where uninitialised values come from
==31636== ERROR SUMMARY: 19 errors from 2 contexts (suppressed: 107 from 21)
Floating point exception

Here an invalid memory read is performed by the SQlite library itself. Obviously, this is out of scope of BaCon.

Therefore, could you also try to compile your program with the same options as mentioned above, and then run it with valgrind (you can get it from http://www.valgrind.org)? The dump will show in which part of the C-code the crash takes place.

If you were using the BETA version of BaCon please refer to the official stable 1.0.17.

Thanks,
Peter

[doyle]

Sept 23, 2010 12:11:36 GMT 1 Pjot said:

Hi Doyle,

Well, I have an old Puppy Linux 4.2.1 installation and your program starts, but when performing a database lookup it crashes there too. With 'valgrind' we can see where where the problem is:

# mksh ./bacon.ksh -o -g -o -export-dynamic -p rddb
Starting conversion... done.
Starting compilation... done.
Program 'rddb' ready.
# ./rddb
Segmentation fault
# valgrind ./rddb
==31636== Memcheck, a memory error detector
==31636== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==31636== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==31636== Command: ./rddb
==31636==
==31636== Invalid read of size 4
==31636== at 0x80547E1: ?? ?
==31636== Address 0x54fc6e8 is 0 bytes after a block of size 48 alloc'd
==31636== at 0x401C7E8: malloc (vg_replace_malloc.c:195)
==31636== by 0x45796FD: ?? ? (in /usr/lib/libsqlite3.so.0.8.6)
==31636== by 0x459E7E7: ?? ? (in /usr/lib/libsqlite3.so.0.8.6)
==31636==
==31636== Conditional jump or move depends on uninitialised value(s)
==31636== at 0x80547E1: ?? ?
==31636==
==31636==
==31636== Process terminating with default action of signal 8 (SIGFPE)
==31636== Integer divide by zero at address 0x6395C774
==31636== at 0x80547E9: ?? ?
==31636==
==31636== HEAP SUMMARY:
==31636== in use at exit: 1,565,732 bytes in 12,290 blocks
==31636== total heap usage: 40,382 allocs, 28,092 frees, 7,632,536 bytes allocated
==31636==
==31636== LEAK SUMMARY:
==31636== definitely lost: 1,792 bytes in 7 blocks
==31636== indirectly lost: 3,936 bytes in 194 blocks
==31636== possibly lost: 1,125,428 bytes in 6,808 blocks
==31636== still reachable: 434,576 bytes in 5,281 blocks
==31636== suppressed: 0 bytes in 0 blocks
==31636== Rerun with --leak-check=full to see details of leaked memory
==31636==
==31636== For counts of detected and suppressed errors, rerun with: -v
==31636== Use --track-origins=yes to see where uninitialised values come from
==31636== ERROR SUMMARY: 19 errors from 2 contexts (suppressed: 107 from 21)
Floating point exception

Here an invalid memory read is performed by the SQlite library itself. Obviously, this is out of scope of BaCon.

Ok, maybe I need a newer version of sqlite3. I wonder why it don't crash with the first program using g_signal_connect_data? Methinks something's afoot with glade and sqlite! ;D

Therefore, could you also try to compile your program with the same options as mentioned above, and then run it with valgrind (you can get it from http://www.valgrind.org)? The dump will show in which part of the C-code the crash takes place.

If you were using the BETA version of BaCon please refer to the official stable 1.0.17.

Nope still using 17.

Thanks Peter, I'll get valgrind, seems like it would be very useful. I appreciate your help!

Doyle