Dear Hans,

Thank you for your hint. It's a good direction to look at. I started looking at your code I discovered the shell command mkfifo. It will be of a great help.

I'm using mkfifo to create a pipe cmd file (let's say /tmp/tm_gdb_in) from which GDB gets the commands to execute (-x option). And I use a open("/tmp/tm_gdb_in", "r+") { |toGdb| toGdb.puts("bt") }. But as GDB quits when it reaches the end of the command file , GDB quits when the IO is closed. So, to avoid that it seems that I have the use a little trick to cheat GDB. I have to create a Ruby thread opening the fifo /tmp/tm_gdb_in and an other fifo (let's say /tmp/tm_gdb_multiple_in) and running in loop to just get from /tmp/tm_gdb_multiple_in to put it in /tmp/tm_gdb_in. In this case, the file /tmp/tm_gdb_in is never closed, but the file /tmp/tm_gdb_multiple_in can be closed without finishing GDB.

Have you had to do such an inelegant thing?

About the parsing of GDB output, I agree it will not be easy, but I'll try to handle that. It will force me to use regular expression extensively. ;-)

I will try to set this up progressively and explain my method, it might help someone one day.

Best regards,
Mathieu

___________________________________________

Mathieu Godart

Skype: mathieu_godart

ASIC Integration Manager
Coolsand Technologies
___________________________________________



Le 25 mars 09 à 17:39, Hans-Jörg Bibiko a écrit :


On 25.03.2009, at 17:06, Mathieu Godart wrote:

I'm still thinking on how to implement this debugger wrapper.

To do so, I would need to create a thread in which GDB would be
running. Ok, this is easy, but the tricky part is that I need to keep
track of this thread (of its STD IOs, in fact) and I need this thread
not to be killed when the TM command execution is done. And when a new
command needs to be sent to GDB, I would need to send it to the STDIN
of the thread and read back its STDOUT.

Does someone have a hint for that? Or a bundle doing that where I
could have a look?

Hmm, I do not know whether my hint could help because I have no  
exhausted experiences of using gdb.

I wrote the bundle "R Console (Rdaemon)" http://svn.textmate.org/trunk/Bundles/R%20Console%20(Rdaemon).tmbundle
 which allows to run a Terminal process (here R) inside of a TM doc.  
This is done by spawning that process to an hidden terminal (pseudo-
terminal). This works because R has a (relatively) fixed prompt '> '.

[in short words how it works]
If the R process was started it prompts '> ' to signalise please enter  
a task. In the TM doc I can type 'sqrt(2)' and press ↩. ↩ is bound  
to a script which sends the task 'sqrt(2)' to a named pipe which is  
linked to the input of the R process. Then this script waits for the  
output of the R process until R returns '> '. After having the prompt  
this script takes the delta of R's output file and inserts it as  
snippet into the current TM doc.

gdb also has a prompt '(gdb) '. OK. But the tricky part with gdb would  
be to get rid of, amongst others, prompted questions like:

The program being debugged has been started already.
Start it from the beginning? (y or n)

Here I do not know a way how to detect from a script that gdb is  
expecting something from the user. Maybe a solution would be to use  
the tm_interactive_input.dylib stuff. In R I got rid of it by  
overwriting e.g. the readline function (i.e. by using DIALOG).

I tested that approach also with 'irb' and basically it works.

But I guess this could become a very stony way.


--Hans

_______________________________________________
textmate mailing list
textmate@lists.macromates.com
http://lists.macromates.com/listinfo/textmate