[TxMt] Re: GDB integration in TextMate

[Mathieu Godart]

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 at 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 at lists.macromates.com
> http://lists.macromates.com/listinfo/textmate

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macromates.com/textmate/attachments/20090325/257406bc/attachment.html>