Menu
▾
▴
bashdb-devel
|
From: R. B. <ro...@pa...> - 2006-07-28 02:50:09
|
The problem with making an eclipse plugin for bashdb is that seems to want to debug via some sort of out of process mechanism (and usually via a socket). Right now bashdb doesn't have support for remote debugging or debugging via a socket. As for readarray, sure, I think reading in a file into an array quickly is a generally useful thing. Python has a fancier module called linecache. Volunteers for sheparding this through? |
|
From: Masatake Y. <je...@gy...> - 2006-08-02 11:25:57
|
> As for readarray, sure, I think reading in a file into an array > quickly is a generally useful thing. Python has a fancier module > called linecache. Volunteers for sheparding this through? Of couser if my mail doesn't goto the spam trash:) Any good way to solve this situation? |
|
From: Masatake Y. <je...@gy...> - 2006-08-02 13:54:09
|
> As for readarray, sure, I think reading in a file into an array
> quickly is a generally useful thing. Python has a fancier module
> called linecache. Volunteers for sheparding this through?
Before, contacting to Chet Ramey, I'd like to have some discussions.
1. How do you think rename readarray to readfile?
I think the shell script writer may be confused read -a and readarray.
readfile is more specific name.
2. I think it is better to make readarray options are similar to read.
char *readarray_doc[] = {
"Copy the lines from the input file into an array variable.",
"Use the `-n' option to specify a count of the number of lines to copy.",
"If -n is missing all lines are copied.",
"Use the `-O' option to specify an index orgin to start the array.",
"If -O is missing the origin will be 0.",
"Use -t to chop trailing newlines (\\n) from lines.",
"To read from stdin use '-' as the filename.",
In stead of specifying filename, how do you think fd like
"read -u fd"? You can slow away `-'.
3. Do you think callback is needed?
readarray is fast enough, so I think callback arguments is
overkilling. I tried more than 10000 lines configure. However,
it takes no time to read.
Masatake
|
|
From: Masatake Y. <je...@gy...> - 2006-08-02 14:00:18
|
Could you review this patch and install it if you appreciate it?
2006-08-02 Masatake YAMATO <je...@gy...>
* dbg-io.inc: Put BASH_EXECUTION_STRING
to ${source_array}[0], not [1].
--- dbg-io.inc 20 3月 2006 10:51:36 +0900 1.8
+++ dbg-io.inc 02 8月 2006 22:57:27 +0900
@@ -204,7 +204,7 @@
if [[ -z $filename ]] || [[ $filename == $_Dbg_bogus_file ]] ; then
filevar='ABOGUSA'
source_array="_Dbg_source_${filevar}"
- local cmd="${source_array}[1]=\"$BASH_EXECUTION_STRING\""
+ local cmd="${source_array}[0]=\"$BASH_EXECUTION_STRING\""
eval $cmd
else
|
|
From: Masatake Y. <je...@gy...> - 2006-08-21 12:05:11
|
> 1. How do you think rename readarray to readfile?
>
> I think the shell script writer may be confused read -a and readarray.
> readfile is more specific name.
I did not rename it yet. I'm still looking for a good name.
>
> char *readarray_doc[] = {
> "Copy the lines from the input file into an array variable.",
> "Use the `-n' option to specify a count of the number of lines to copy.",
> "If -n is missing all lines are copied.",
> "Use the `-O' option to specify an index orgin to start the array.",
> "If -O is missing the origin will be 0.",
> "Use -t to chop trailing newlines (\\n) from lines.",
> "To read from stdin use '-' as the filename.",
> In stead of specifying filename, how do you think fd like
> "read -u fd"? You can slow away `-'.
>
I did. The documentation is not updated but now readarray takes -u option for specify
file descriptor. The file name is not acceptable. Use redirection instead.
I'm changing the coding style(variable name conversion and
indentation) to make it similar to that of bash.
I'll use more bash functions in readarray.c.
Then I'll convert readarray.c to readarray.patch:-P
|
|
From: Masatake Y. <je...@gy...> - 2006-08-02 14:02:37
|
Could review this patch and install it if you appreciate it?
2006-08-02 Masatake YAMATO <je...@gy...>
* emacs/bashdb.el: Replace `pydb' with 'bashdb'.
--- bashdb.el 28 7月 2006 08:31:58 +0900 1.16
+++ bashdb.el 02 8月 2006 22:24:43 +0900
@@ -37,10 +37,10 @@
;; The debugger outputs program-location lines that look like this:
;; (/etc/init.d/network:14):
-(defconst gud-pydb-marker-regexp
+(defconst gud-bashdb-marker-regexp
"^(\\([-a-zA-Z0-9_/.]*\\):\\([0-9]+\\)):[ \t]?\\(.*\n\\)")
-(defconst gud-pydb-marker-regexp-file-group 1)
-(defconst gud-pydb-marker-regexp-line-group 2)
+(defconst gud-bashdb-marker-regexp-file-group 1)
+(defconst gud-bashdb-marker-regexp-line-group 2)
;; Convert a command line as would be typed normally to run a script
;; into one that invokes an Emacs-enabled debugging session.
@@ -91,18 +91,18 @@
(let ((output ""))
;; Process all the complete markers in this chunk.
- (while (string-match gud-pydb-marker-regexp gud-marker-acc)
+ (while (string-match gud-bashdb-marker-regexp gud-marker-acc)
(setq
;; Extract the frame position from the marker.
gud-last-frame
(cons (substring gud-marker-acc
- (match-beginning gud-pydb-marker-regexp-file-group)
- (match-end gud-pydb-marker-regexp-file-group))
+ (match-beginning gud-bashdb-marker-regexp-file-group)
+ (match-end gud-bashdb-marker-regexp-file-group))
(string-to-int
(substring gud-marker-acc
- (match-beginning gud-pydb-marker-regexp-line-group)
- (match-end gud-pydb-marker-regexp-line-group))))
+ (match-beginning gud-bashdb-marker-regexp-line-group)
+ (match-end gud-bashdb-marker-regexp-line-group))))
;; Append any text before the marker to the output we're going
;; to return - we don't include the marker in this text.
|
|
From: R. B. <ro...@pa...> - 2006-08-02 16:57:02
|
All the changes you propose look good and make sense. Go for it! Only
thing I ask is to update the bashdb sources so that they aren't left
broken :-) (It would be a pity if the thing, bashdb, this was
initially written for and probably the only use of it were broken by
improving it.)
As for a callback, I think that was to allow for the progress bars you
had added. A callback seems generally useful and doesn't seem to
signficantly slow down the program so why remove it?
Masatake YAMATO writes:
> > As for readarray, sure, I think reading in a file into an array
> > quickly is a generally useful thing. Python has a fancier module
> > called linecache. Volunteers for sheparding this through?
>
> Before, contacting to Chet Ramey, I'd like to have some discussions.
>
> 1. How do you think rename readarray to readfile?
>
> I think the shell script writer may be confused read -a and readarray.
> readfile is more specific name.
>
> 2. I think it is better to make readarray options are similar to read.
>
> char *readarray_doc[] = {
> "Copy the lines from the input file into an array variable.",
> "Use the `-n' option to specify a count of the number of lines to copy.",
> "If -n is missing all lines are copied.",
> "Use the `-O' option to specify an index orgin to start the array.",
> "If -O is missing the origin will be 0.",
> "Use -t to chop trailing newlines (\\n) from lines.",
> "To read from stdin use '-' as the filename.",
> In stead of specifying filename, how do you think fd like
> "read -u fd"? You can slow away `-'.
>
> 3. Do you think callback is needed?
>
> readarray is fast enough, so I think callback arguments is
> overkilling. I tried more than 10000 lines configure. However,
> it takes no time to read.
>
> Masatake
>
|
|
From: Masatake Y. <je...@gy...> - 2006-08-03 11:53:49
|
> As for a callback, I think that was to allow for the progress bars you > had added. A callback seems generally useful and doesn't seem to > signficantly slow down the program so why remove it? Weak reason: I introduced callback for "read" because it is really slow. However, "readarray" is fast enough. Callback may be useful but it is not necessary. Strong reason: When I send readarray.c.patch to the bash maintainer, I have to explain what readarray is. To make the explanation I'll write simple, I'd like to make readarray simple and small as possible as I can. Without bashdb background, the maintainer may not understand why callback is needed; and I may not explain well the background to him. Masatake |
|
From: R. B. <ro...@pa...> - 2006-08-03 12:36:45
|
Masatake YAMATO writes: > > As for a callback, I think that was to allow for the progress bars you > > had added. A callback seems generally useful and doesn't seem to > > signficantly slow down the program so why remove it? > > Weak reason: > I introduced callback for "read" because it is really slow. > However, "readarray" is fast enough. Callback may be useful > but it is not necessary. This is like Bill Gates saying you will never need a computer that uses more than 640K of memory. Okay, so readarray is isn't currently needed for script files in the situation that came up because they are only tens of thousands of lines long. Nobody reads in files that are millions of lines long because, well, it would just take forever without readarray. But should readarray or something like that become popular, perhaps people will use it for reading files other than script files which are orders of magnitudes larger. > > Strong reason: > When I send readarray.c.patch to the bash maintainer, I have > to explain what readarray is. To make the explanation I'll write > simple, I'd like to make readarray simple and small as possible > as I can. Without bashdb background, the maintainer may not > understand why callback is needed; and I may not explain well > the background to him. I don't think it is all that hard to understand or explain. (I do see this that I forgot to document this option. Don't think the background all all that deep either. But that said, you're doing the work; so do it any way you are comfortable. |
×
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