Hi,

The Lazarus IDE has the option "Run Without Debbuging (Shift+Ctrl+F9)"?

Delphi(7) has this option, see: http://imagebin.org/150467

Thx,

2011/4/27 silvioprog :

Delphi(7) has this option, see: http://imagebin.org/150467

+1 from me

I would like such an option. I permanently find myself switching on and off the debugger in the options dialog. This is very cumbersome. A separate "run" command in the menu and in the toolbar would be extremely nice, just like for example eclipse has it also.

for example:
the green arrow: run
a green arow with a small red bug on it: run with debugger.

What's the problem with running in the debugger?

DoDi

2011/5/1 Hans-Peter Diettrich :

What's the problem with running in the debugger?

When running without debugger it will run the program in an xterm and I can see my debugging output on stdout in realtime. When running with the debugger then I have found no easy way to do the same.

Debugger=none is normally my default setting all the time, only when my writeln() technique does not help anymore or when I am trying to understand what exactly is going on in other people's code then I use the debugger.

Bernd

SVN has a console output window (linux only) that displays the output of your app (only works if the below is NOT set)

in 0.9.30 you can set a terminal name for the in/output of your app (if running in debugger). options dialog => debugger: look at the property grid.

If you open a terminal outside lazarus, and run "tty" it will show it's terminal name (eg: /dev/pts/1) enter this in lazarus, and all in output go via this terminal.
BUT unfortunately, the number of the terminal may change if you close/open it, and it is uncomfortable to keep changing it in the options....

2011/5/1 Martin :

SVN has a console output window (linux only) that displays the output of your app

I just tried it. It almost works but it still has some flaws:

* there is no option to clear it, with every new run it will scroll to the top but append the new text at the bottom
* there is no scrollbar
* it should use a fixed width font (some applications might output formatted text)

Additionally running the application within its own xterm makes it possible to shut down the application and all the processes it created by simply closing the xterm (should the gui of my app crash or hang or otherwise fail), I have had some need for this already a few times.

Bernd

2011/5/1 Bernd :

* and there should be an option to make it open automatically when the program is run and this option should be enabled by default, just to make it consistent with the xterm also appearing automatically when the app is run without debugger.

2011/5/1 Bernd :

* and there should be an option to make it open automatically when the program is run...

or better yet: whenever some output appears on stdout (or stderr), otherwise not.

You need to open a terminal with the settings of your choice and Lazarus just tells GDB to redirect the output of the debugged process to that window. Lazarus has basically no way of knowing what your preffered shell looks like (as there are many, many different terminal applications on Linux).

And for me most of your points worked:
I simply started my systems default terminal application which is configured the way I like it (it's an urxvt with scrollbar on the right, black background, grey foreground color, fixed width font). Then I printed the tty number and entered that in the options dialog.

When I run my application it did output to that shell window, the output was appended at the bottom and the scrollbar scrolled down as it should (even when I restarted my applicaton).

What could be done by the Lazarus devs though is to use the "starting application" that's entered in the projects option, let that execute the "tty" command and then Lazarus uses that to start GDB. This way the user could use his/her default shell (or maybe a global "terminal" command line option would be better)

Regards,
Sven

....

There is a patch on the tracker somewhere, that would allow this.....

Yet the way it is currently done, is not good enough. The patch includes commands that need to be run by the terminal, and those should not be hardcoded.

If someone wants to rewrite the patch, so that the debugger options can contain an executable (script or otherwhise), and this script returns only the tty name, then i think it could be accepted.

for this the debuggerproperties needs 2 values.
either keep the current tty property, and add a tty-script or *preferred* add a 2nd property tty-is-exe (true/false)

Note that if the debugger executes the scripts, and reads the output, then it can be allowed to strip a newline, but that's it. any other extra output must be detected, and lead to the script being ignored. (or an error generated).
No attempts to smart-guess, which part of the output is the tty. it is either a single line output, and the whole line is the tty, or it is wrong.

Since the script mus return (the debugger should await it's termination), the terminal would have to launch as background process.

Patch, Ideas, Discussion welcome.

-----------
I think ultimately the build in is the best solution. But yes it still needs a lot of work....

2011/5/1 Sven Barth :

Yes, I have tried this also, it woks better than the terminl output window from the debugging windows menu, but it is cumbersome to find the terminal name each time.

In my previous post I was only referring to the other solution:

view -> debug windows -> terminal output

This could serve as a replacement for the most purposes (just catching and displaying my writelns) if the few problems were removed (scrolling behavior, fixed font, clear the window when doing a new run, open automatically when there appears output). (I know, I should not complain, instead I should just start making a patch, this should not be so difficult)

Bernd

Oh, didn't know about that one.

Regards,
Sven

I added that, not as option, but as always clear on run.

* there is no scrollbar

there now is... (vertical, autoshow)

* it should use a fixed width font (some applications might output formatted text)

hm, yes. But I don't want to hardcode a font..., maybe use editor-font.

The long (very long) time idea is to have several tabs.
- one showing raw data ( similar to now, but unprintable chars being displayed as sequence (maybe with highlight)
- one that is a true terminal emulation, and supports different modes. So escape sequence will be handled, do change position, color, ... ; this view would obviously be monospaced, and optional be a grid of 80x25 or configurable other common dos-screen resulotions...

But, unless patches come in => someday...

This is also in my to-do list.
Sometimes I have lots of breakpoints and just wanna run to application to check whether some modification worked...

-Fl?vio

open the breakpoint dlg, disable all breakpoints

Thanks. I knew this, however.
I happen to have some already disabled breakpoints too that I want to keep that way later. I guess you already tried debugging the AutoAlign code? ;-)
I had a quick look at implementing "skip breakpoints" for RunTo, Step, StepInto etc, as I could swear gdb supported this, but couldn't find it. It's been some time since I last worked in the debugger code and with gdb inner workings...
BTW, very good that somebody/you are working in the debugger :-) It definetely still "needs some love". Anything big currently on your plate?

Best regards,
Fl?vio

Nope, but I did debug lot's of other code.
Including the debugger, while it was itself debugging. Effectively having 3 instances of lazarus running

But I see your problem is recurisve code...

just noticed. breakpoint conditions are broken at the moment...

you know $fp?

once conditions are fixed. you should be able to put in (c-style constant) $fp=0x0262F404

and it will only stop, if back to the give stack frame.

the number obviously is the current value of $fp

Haven't tested it, since conditions are broken at the moment...

Martin wrote

just noticed. breakpoint conditions are broken at the moment...

Do you mean they ever worked before?

Best regards,
Paul Ishenin

Paul Ishenin wrote

03.05.2011 17:05, Martin wrote: > just noticed. breakpoint conditions are broken at the moment... Do you mean they ever worked before?

yes, so long as if you put in a gdb-ish expression

that is the IDE does not (or not correctly) translate. There is some code to attempt some translatiopn. Not sure how much good or damage it does....

but my example $fp=0xAB12345 would have worked

fixed in r 30539

Paul Ishenin wrote

03.05.2011 17:05, Martin wrote: > just noticed. breakpoint conditions are broken at the moment... Do you mean they ever worked before?

What does not yet work, are breakpoint groups, and enbling/disabling breakpoints, depending on other breakpoints being hit......

On the todo list

Sorry for my long time in off.

So, " Run Without Debbuging" will be implemented in Lazarus?

Thanks.

silvioprog wrote

Sorry for my long time in off. So, " Run Without Debbuging" will be implemented in Lazarus?

If someone sends a patch...

Otherwise I would currently say it's on the far end of the list of things that are to be done

I was in the in middle of reply saying that I've just written a patch :-) The biggest issue is I just implemented the command directly in main.pas using a TProcess, don't whther it's the right approach. Second biggest issue is nor git-gui nor smartgit want to let me create a patch from the revision :-/ Guess I'll have to go the cmdline way :-$

-Fl?vio

2011/5/5 Fl?vio Etrusco :

http://bugs.freepascal.org/view.php?id=19296

-Fl?vio

probably best to look at the current debugger=none implementation (TProcessDebugger, yes it is no debugger, yet the name)

Afterall, the IDE needs to know when the process starts, and stops. so it can update run and stop buttons.
It also need the capabilities, of such a run session, so it does not offer pause, or single stepping

Oops, of course. I was going to look into that and got distracted :-$ It was late night ;-)

Does "no debugger" behave this way? Actually I don't think Delphi behaved like that, i guess it simply launched the application (maybe it deserves a new name if we go this route ;-)

Best regards,
Fl?vio

Fl?vio Etrusco wrote

http://bugs.freepascal.org/view.php?id=19296 -Fl?vio

Thanks to all.

I am following this issue. ;)

We're not creating delphi !
I don't think we need a 2nd way of running processes. The ide still needs the info.

Marc

all you need is to look at how debugger class is currently changed ( + reset debuggeR).

then do that on the fly. And of course restore it too.

However, before switching, check the state, that it isn't running.

Possible preserve the debug-instance, but not a 100% requirement

Of course. It only that I often wanted this in lazarus when I needed several instances to run concurrently.

-Fl?vio

Fl?vio Etrusco wrote

Second biggest issue is nor git-gui nor smartgit want to let me create a patch from the revision :-/ Guess I'll have to go the cmdline way :-$

Makes no sense, but the follow should work:

----8<-------------8<-------------8<-------------8<-------------8<----

Creating and emailing a patch
=============================
If simply want to fix something small and email a patch to a mailing list on NNTP server, you can do the following:

$ cd lazarus
$ git branch myfeature
$ (edit files)
$ git add (files)
$ git commit -m 'Explain what I changed'
$ git format-patch origin/upstream

----8<-------------8<-------------8<-------------8<-------------8<----

More tips can be found on my wiki:

http://opensoft.homeip.net:8080/wiki/wiki.cgi?p=git-tips http://opensoft.homeip.net:8080/wiki/wiki.cgi?p=git-howto

...and for some fun with git and repository statistics...

http://opensoft.homeip.net:8080/wiki/wiki.cgi?p=git-and-repository-statistics

Regards,
- Graeme -

Then the IDE can no longer keep track, if the process runs, and further attempts to compile will fail (exe locked / at least on windows).

Though I can see your requirement. I would think, that such an "independent" launcher, would be best done as an installable package. It can then be discussed, if such a package could be included in the lazarus distribution, or was to be kept as separate download.

Btw, there is another scenario:
One might want to launch an app without debugger (maybe because some library loaded at launch does not work in gdb), and then attach to the running app (assuming attach is implemented).

http://bugs.freepascal.org/view.php?id=19296

Fl?vio Etrusco wrote

Of course. It only that I often wanted this in lazarus when I needed several instances to run concurrently.

Since the discussion about the patch was started on the list, I decided to continue it here, rather than to move it to mantis.

I understand your requirement, but as indicated I (and apparently others) are not comfortable with the solution in your patch.

IMHO the following additions are acceptable (though I am open to arguments):

1) An build in "Run without debugger", that uses the current "no debugger class" (TProcessDebugger) to launch the app.
- This launches a single instance and keeps track of it (same as setting debugger to none) [1]
- It disables single step and other buttons ....

2) A solution similar to yours, I think is reasonable too. But I would suggest it to be committed as an installable package, for those who need it.
- I do think such a package could be committed to the Lazarus svn and be distributed with Lazarus by default. But of course it can also go to CCR...

Launching the app into background (and then just forget about it), can have unexpected side-effects, that may confuse other users.
- Such as, if the app still runs, at least on windows compilation will fail, because the exe is locked
- Not even the stop button would work (couldn't because if many are launched, which one to stop)
Though of course it was possible to add comfort functions and keep track of them

In that aspect your patch has a problem, even if done as package. It attempts to compile the app first (if changed).
So if one instance is launched, then any change is made, launching another instance is impossible, as compilation fails due to the locked exe (may work on none windows)

3)
Actually a 3rd solution would be possible, where the IDE would have a debug-window listing all launched instances. Then one could attach/detach the debugger to any of them.
That would be pretty cool, but is far more than a what your patch attempts to do. (And it is my opinion only, I do not know if the other developers would think of such a solution as proper) It would have to be very carefully be considered how such a function should work (and maybe even than it was better an external package). And also I can see quite a few problems that would have to be solved to do this....

--------------
In any case, do you indent to make further change, like implementing it as external package (considering the issue with compiling before exec, and locked exe)?
Or do you have any other idea, you wish to discuss, ad of which you hope it may help to solve this?

Best Regards
Martin

[1] should that not currently behave as described, then it may have to be fixed