Menu
▾
▴
bashdb-devel
|
From: R. B. <ro...@pa...> - 2002-12-30 21:45:57
|
Hi there, Ho there, Okay. Thanks for the information and looking into bashdb. If you have questions, comments, or problems with bashdb let us know. > Hey there, > Just wanted to let you know that I am starting to look into bashdb. I > have selected your project as a possible partner for the introspector > bash interface. > I would like to be able to dump exisiting bash scripts into rdf/xml > using the redland lib similar to what we are doing with the gcc. > > also I need to debug some configure/libtool scripts, so I hope that > this will be a usefull tool. > > Later, > mike > > ===== > James Michael DuPont > http://introspector.sourceforge.net/ > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > > > > --__--__-- > > _______________________________________________ > Bashdb-devel mailing list > Bas...@li... > https://lists.sourceforge.net/lists/listinfo/bashdb-devel > > > End of Bashdb-devel Digest |
|
From: James M. D. <mdu...@ya...> - 2002-12-30 23:14:54
|
--- "R. Bernstein" <ro...@pa...> wrote:
> Hi there, Ho there,
>
> Okay. Thanks for the information and looking into bashdb. If you have
> questions, comments, or problems with bashdb let us know.
>
I am running this on libtool
/usr/local/bin/../lib/bashdb/bashdb-list.inc: line 200: local:
+2D0M2D0D6Slibtool: value too great for base (error token is
"2D0M2D0D6Slibtool")
/usr/local/bin/../lib/bashdb/bashdb-list.inc: line 200: local:
+2D0M2D0D6Slibtool: value too great for base (error token is
"2D0M2D0D6Slibtool")
# the line is
local -i max_line=`_bashdb_get_assoc_scalar_entry "_maxline_"
$filevar`
# echo "debug: -- max_line: $max_line --"
bash -x ../libtool --mode=link i586-mingw32msvc-gcc
-DGLIB_STATIC_COMPILATION -mms-bitfields -Wall -D_REENTRANT
-I/usr/local/win32/include -I/usr/local/win32/include/glib-2.0/
-mms-bitfields -L/usr/local/win32/lib -o test-gdk-pixbuf.exe
test-gdk-pixbuf.o libgdk_pixbuf-2.0.la -L/usr/local/win32/lib/ -lgdi32
-lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -liconv
It has something to do with the size of the identfiers,
i will gdb it.
mike
=====
James Michael DuPont
http://introspector.sourceforge.net/
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
|
|
From: R. B. <ro...@pa...> - 2002-12-31 04:20:52
|
A guess is the problem is that you have a plus (or some other
character that isn't usually part of a BASH identifier) in the filename.
+2D0M2D0D6Slibtool
^here
Some background. For the debugger, it is very useful to have a hash
table data structure. Hash tables are not part of bash (yet). The way
these are implemented is to convert what in Perl would be $file{key}
into a single identifier "file_key" making use of BASH's hashed symbol
table.
But in order to do this "key" can't have any non-identifer symbols,
like "+", "/", "." and so on. So these must either be stripped or
replaced. We in fact, replace them to make it easier to recontruct the
original name. Right now I don't list all the weird symbols that might
appear in a filename. In particular, I don't have "+" listed.
Doing a reverse translation of +2D0M2D0D6Slibtool the original
filename with a path probably contained something like
"+2.0-2-0.6/libtool", possibly with other stuff in front. If this is
the case, then a simple fix is to make sure we tranlate the "+" in
_bashdb_file2var. That is, change this line 22 of bashdb-file.inc:
local varname=`builtin echo $filename | tr '* .?/"[]-' 'ABDQSqLRM'`
into this:
local varname=`builtin echo $filename | tr '+* .?/"[]-' 'PABDQSqLRM'`
Actually, I've already made the change in CVS.
If that works, let me know. If not, it would be helpful to understand
not just what the error message you encountered given below, but some
short example giving *input* that you typed to get that output.
Better, is a short test case that causes the debugger to fail.
Thanks.
James Michael DuPont writes:
>
> --- "R. Bernstein" <ro...@pa...> wrote:
> > Hi there, Ho there,
> >
> > Okay. Thanks for the information and looking into bashdb. If you have
> > questions, comments, or problems with bashdb let us know.
> >
> I am running this on libtool
>
> /usr/local/bin/../lib/bashdb/bashdb-list.inc: line 200: local:
> +2D0M2D0D6Slibtool: value too great for base (error token is
> "2D0M2D0D6Slibtool")
> /usr/local/bin/../lib/bashdb/bashdb-list.inc: line 200: local:
> +2D0M2D0D6Slibtool: value too great for base (error token is
> "2D0M2D0D6Slibtool")
>
> # the line is
> local -i max_line=`_bashdb_get_assoc_scalar_entry "_maxline_"
> $filevar`
> # echo "debug: -- max_line: $max_line --"
>
> bash -x ../libtool --mode=link i586-mingw32msvc-gcc
> -DGLIB_STATIC_COMPILATION -mms-bitfields -Wall -D_REENTRANT
> -I/usr/local/win32/include -I/usr/local/win32/include/glib-2.0/
> -mms-bitfields -L/usr/local/win32/lib -o test-gdk-pixbuf.exe
> test-gdk-pixbuf.o libgdk_pixbuf-2.0.la -L/usr/local/win32/lib/ -lgdi32
> -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -liconv
>
> It has something to do with the size of the identfiers,
> i will gdb it.
>
> mike
>
> =====
> James Michael DuPont
> http://introspector.sourceforge.net/
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
|
|
From: James M. D. <mdu...@ya...> - 2002-12-31 09:07:11
|
Thank you very much for the detailed explaination.
Yes, I should have included the file with me,
or even a -x copy of it.
On that note, do you have a way to -save-temps like gcc does, like +x
so that you can capture the fully post-preprocessed files?
I am cvs updating and will tell you how I fare.
it is funny, but i had a feeling that those long indentifiers were
created out of some hashing scheme, I encountered similar longs ids
using hashes in shell before, just concatinating the symbols into
one...
Happy new year!
mike
--- "R. Bernstein" <ro...@pa...> wrote:
> A guess is the problem is that you have a plus (or some other
> character that isn't usually part of a BASH identifier) in the
> filename.
>
> +2D0M2D0D6Slibtool
> ^here
>
> Some background. For the debugger, it is very useful to have a hash
> table data structure. Hash tables are not part of bash (yet). The way
> these are implemented is to convert what in Perl would be $file{key}
> into a single identifier "file_key" making use of BASH's hashed
> symbol
> table.
>
> But in order to do this "key" can't have any non-identifer symbols,
> like "+", "/", "." and so on. So these must either be stripped or
> replaced. We in fact, replace them to make it easier to recontruct
> the
> original name. Right now I don't list all the weird symbols that
> might
> appear in a filename. In particular, I don't have "+" listed.
>
> Doing a reverse translation of +2D0M2D0D6Slibtool the original
> filename with a path probably contained something like
> "+2.0-2-0.6/libtool", possibly with other stuff in front. If this is
> the case, then a simple fix is to make sure we tranlate the "+" in
> _bashdb_file2var. That is, change this line 22 of bashdb-file.inc:
>
> local varname=`builtin echo $filename | tr '* .?/"[]-' 'ABDQSqLRM'`
>
> into this:
>
> local varname=`builtin echo $filename | tr '+* .?/"[]-'
> 'PABDQSqLRM'`
>
> Actually, I've already made the change in CVS.
>
> If that works, let me know. If not, it would be helpful to understand
> not just what the error message you encountered given below, but some
> short example giving *input* that you typed to get that output.
> Better, is a short test case that causes the debugger to fail.
>
> Thanks.
>
>
> James Michael DuPont writes:
> >
> > --- "R. Bernstein" <ro...@pa...> wrote:
> > > Hi there, Ho there,
> > >
> > > Okay. Thanks for the information and looking into bashdb. If you
> have
> > > questions, comments, or problems with bashdb let us know.
> > >
> > I am running this on libtool
> >
> > /usr/local/bin/../lib/bashdb/bashdb-list.inc: line 200: local:
> > +2D0M2D0D6Slibtool: value too great for base (error token is
> > "2D0M2D0D6Slibtool")
> > /usr/local/bin/../lib/bashdb/bashdb-list.inc: line 200: local:
> > +2D0M2D0D6Slibtool: value too great for base (error token is
> > "2D0M2D0D6Slibtool")
> >
> > # the line is
> > local -i max_line=`_bashdb_get_assoc_scalar_entry "_maxline_"
> > $filevar`
> > # echo "debug: -- max_line: $max_line --"
> >
> > bash -x ../libtool --mode=link i586-mingw32msvc-gcc
> > -DGLIB_STATIC_COMPILATION -mms-bitfields -Wall -D_REENTRANT
> > -I/usr/local/win32/include -I/usr/local/win32/include/glib-2.0/
> > -mms-bitfields -L/usr/local/win32/lib -o test-gdk-pixbuf.exe
> > test-gdk-pixbuf.o libgdk_pixbuf-2.0.la -L/usr/local/win32/lib/
> -lgdi32
> > -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -liconv
> >
> > It has something to do with the size of the identfiers,
> > i will gdb it.
> >
> > mike
> >
> > =====
> > James Michael DuPont
> > http://introspector.sourceforge.net/
> >
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> > http://mailplus.yahoo.com
=====
James Michael DuPont
http://introspector.sourceforge.net/
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
|
|
From: R. B. <ro...@pa...> - 2002-12-31 16:12:26
|
James Michael DuPont writes: > On that note, do you have a way to -save-temps like gcc does, like +x > so that you can capture the fully post-preprocessed files? This debugger is a little bit different in design from earlier BASH or Korn shell debuggers such the one described in the O'Reilly books. While the others wrote a new script with debugger routines prepended, this one doesn't. Or more bluntly: there is no preprocessed source. Here's why. When one changes the source code you need to have a mapping from the things you've changed into the the original text. That is you are keeping a mapping of a set of lies around so you can keep the story you tell the users straight. The more you change the more lying going on. This lie mapping is overhead and adds complexity. As in normal life, the fewer lies I have to tell the easier things are. (In truth, though there are things that the debugger does lie about. For example the call stack omits the debugger routines from the top of the stack when reporting the contents .) |
|
From: James M. D. <mdu...@ya...> - 2002-12-31 16:46:24
|
ok, let me put this in another way : Is there a way to pull out all of the knowledge that you have about a give bash routine into a file? or at least an interator function that visits each node uniquly? I would like to have a routine that visits all the internal COMMAND and WORD objects, so that I can use that as input into the introspector. The thing is that, I need to see : 1. what file a node (COMMAND,WORD) comes from. 2. what type it is (unary expr, function call, function decl) 3. what line number/column it came from I use the redland rdf lib for storing this information, and to be able to gather all of that out of a ./configure file would be very usefull. Also, we need to figure out the sources before they are interpolated and afterwards. Happy new year, mike --- "R. Bernstein" <ro...@pa...> wrote: > James Michael DuPont writes: > > On that note, do you have a way to -save-temps like gcc does, like > +x > > so that you can capture the fully post-preprocessed files? > > This debugger is a little bit different in design from earlier BASH > or > Korn shell debuggers such the one described in the O'Reilly books. > While the others wrote a new script with debugger routines prepended, > > this one doesn't. > > Or more bluntly: there is no preprocessed source. > > Here's why. When one changes the source code you need to have a > mapping from the things you've changed into the the original > text. That is you are keeping a mapping of a set of lies around so > you > can keep the story you tell the users straight. The more you change > the more lying going on. This lie mapping is overhead and adds > complexity. As in normal life, the fewer lies I have to tell the > easier things are. > > (In truth, though there are things that the debugger does lie about. > For > example the call stack omits the debugger routines from the top of > the stack when reporting the contents .) > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Bashdb-devel mailing list > Bas...@li... > https://lists.sourceforge.net/lists/listinfo/bashdb-devel ===== James Michael DuPont http://introspector.sourceforge.net/ __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
|
From: R. B. <ro...@pa...> - 2002-12-31 17:12:03
|
James Michael DuPont writes: > ok, let me put this in another way : > Is there a way to pull out all of the knowledge that you have about a > give bash routine into a file? or at least an interator function that > visits each node uniquly? Not that I know of. I don't see a need for this for debugger operations. If you have a need for this perhaps you could write something. > > I would like to have a routine that visits all the internal COMMAND and > WORD objects, so that I can use that as input into the introspector. > > The thing is that, I need to see : > 1. what file a node (COMMAND,WORD) comes from. > 2. what type it is (unary expr, function call, function decl) > 3. what line number/column it came from The bash "declare" statement can probably give some of this information. "declare -F" lists all functions. "declare -a" lists all arrays. A variable name can be given too. See the bash documentation on declare. (Note: make sure you look at the doc that comes with the debugger since in fact declare has been extended to give line and source file information for functions; it does this because the debugger needs that info.) Names that pertain to the debugger start _bashdb. But alas there are stll a few debugger variables however that don't start _bashdb; they all do start with an underscore though. > > I use the redland rdf lib for storing this information, and to be able > to gather all of that out of a ./configure file would be very usefull. > > Also, we need to figure out the sources before they are interpolated > and afterwards. In bashdb, the command "info files" lists all the file the debugger knows about - has seen so far. You can look at the code to find the array that stores that. _bashdb_file2var as mentioned before does the name mangling. From that, if you need a reverse mapping you can probably create it. |
|
From: James M. D. <mdu...@ya...> - 2002-12-31 17:44:22
|
Dude! the cvs updates made a big difference! now l and w are working! you rock! --- "R. Bernstein" <ro...@pa...> wrote: > James Michael DuPont writes: > > ok, let me put this in another way : > > Is there a way to pull out all of the knowledge that you have > about a > > give bash routine into a file? or at least an interator function > that > > visits each node uniquly? > > Not that I know of. I don't see a need for this for debugger > operations. If you have a need for this perhaps you could write > something. Yes, I will. The whole problem is that a debugger is really needed, and sometimes we need to sift through a bash script with an editor looking for things. Or want to extract data out of a given bash script, then you need an intermediate form for the scripts. For me it is very important to be able to extract the data out of the build scripts, so Make uses bash all the time, and in order to be able to extract the data out of a makefile, we also have to be able to extract the data out of bash. > > > > > I would like to have a routine that visits all the internal > COMMAND and > > WORD objects, so that I can use that as input into the > introspector. > > > > The thing is that, I need to see : > > 1. what file a node (COMMAND,WORD) comes from. > > 2. what type it is (unary expr, function call, function decl) > > 3. what line number/column it came from > > The bash "declare" statement can probably give some of this > information. "declare -F" lists all functions. "declare -a" lists all > arrays. that is really cool!! I never used this before! >A variable name can be given too. See the bash documentation > on declare. (Note: make sure you look at the doc that comes with the > debugger since in fact declare has been extended to give line and > source file information for functions; it does this because the > debugger needs that info.) Ok, I will read the docs :) > > Names that pertain to the debugger start _bashdb. But alas there are > stll a few debugger variables however that don't start _bashdb; they > all do start with an underscore though. > > > > > I use the redland rdf lib for storing this information, and to be > able > > to gather all of that out of a ./configure file would be very > usefull. > > > > Also, we need to figure out the sources before they are > interpolated > > and afterwards. > > In bashdb, the command "info files" lists all the file the debugger > knows about - has seen so far. You can look at the code to find the > array that stores that. _bashdb_file2var as mentioned before does the > name mangling. From that, if you need a reverse mapping you can > probably create it. cool! that is really good. Now i can figure out this silly automake libtool stuff! so, happy new years again, I gotta get ready to party! mike ===== James Michael DuPont http://introspector.sourceforge.net/ __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X