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 MSN: mathieu_godart@hotmail.com

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