Re: [Lazarus] Playing with debuggers
Op 14-09-2021 om 02:18 schreef Martin Frb via lazarus: On 14/09/2021 01:00, Joost van der Sluis via lazarus wrote: I'm playing with several debuging-concepts. And I want to share this one with you. I've created a new Lazarus-debugger LazDabDebugger that can work with FpdServer. It depends on a package (LazDebugExtensionIntf) that adds another way of showing debugging variables inside Lazarus. Great, the frontend was overdue for a remake. I have not yet looked at the code. But ideally this should just replace/extend the existing watches. Of course that also would need the debugger intf to be updated. (That does need an overhaul, and yes it could mean all existing debuggers will need a bit of work to follow / ideas welcome) What I did now, is add new dialogs, and created an debug-interface separate from the existing one. But with the idea that it could replace/be merged with the existing one. What we could also do is make the debug-windows (watches, locals, evaluation pluggable, so that a debugger can choose which one to use.) Ideally the entire debugger frontend could move into a package of its own too (all the current windows). Exactly, that is why I created a new debug-intf package instead of adapting the existing one. I can write tons of texts about the background and possibilities. But for now I'm just curious at your input. Currently the debugger intf allows to fetch watches as plain text, or as structure. But this has to be passed in as flag at the request time. Any watch object should instead have methods to fetch "sub watches" so structures can unfold. What I have now is that each object has a 'reference', and there is a separate call to get the sub-watches that belong to the reference. That way the data (in the object) and the logic (function to retrieve sub-watches) are separated. I don't have a solution for requesting the result as text(string) only. But that's not a bad idea. I see you pass the variable to the debugger, that is ok. But that may well get abstracted into the Watch, so the watch has its own ref to the debugger, and makes the needed calls. I don't follow exactly. But if there's a need for an extra abstraction layer before sending the variable to the debugger directly, this could be added. Not sure about passing callbacks directly. Thinking of the current notification system (data monitors). What does your new watch window do, if the user modifies a variable? This triggers re-eval of all watches (so they need to unfold again). Currently the debugger backend can trigger the re-eval, and through the data-monitors tell everyone about the updates. Have to look at it in more detail I have something similar as the data-monitors. Main difference is that the events are based on what the gui needs, instead of what the debugger does. So: there is an event to tell the 'gui' that it is inpossible to show any data. (for example: the application has stopped or there is no debugger at all) There is an event for the case that debug-data has become available or unavailable. (Application paused or continued) And I should add an event for the case that the debug-info should be re-evaluated. (context switch, or variable-change). And I can think of another event that can be send when the debug-data could have been changed, due to unforeseen effect, for example when a propperty with a getter has been evaluated. The advantage of 'events' that are more geared towards the gui, is that it is easier to add catchy things. For example: to avoid flickering, when the gui receives an event that debug-data is not available anymore, it starts a timer of 200 mseconds, and only after that timer the data is removed from the screen. This way, when stepping through the code, there is no flickering in the small periods of time that the application runs. It also made it easy to highlight variables that changed. But atm they are only suitable for displaying variables. Stuff like the call-stack are not touched. Regards, Joost. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Unable to show method
Hello, I have an issue creating a new component, but it can be reproduce easily using a default component: - drop a TPopupMenu - on Object Inspector, go to Events tab - double-click in `Items.OnClick` to implement - you will get the message: "Unable to show method. Please fix the error shown in the message window which is normally below the source editor." There is no message in Message Windows. Lazarus 2.0.12 r64642 FPC 3.2.0 i386-win32-win32/win64 Lazarus 2.0.13 r64940M FPC 3.2.0 i386-win32-win32/win64 Should I open a ticket? best regards, Marcos Douglas -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Playing with debuggers
On Tue, 14 Sep 2021, Joost van der Sluis via lazarus wrote: Hi all, I'm playing with several debuging-concepts. And I want to share this one with you. I've created a new Lazarus-debugger LazDabDebugger that can work with FpdServer. It depends on a package (LazDebugExtensionIntf) that adds another way of showing debugging variables inside Lazarus. I can write tons of texts about the background and possibilities. But for now I'm just curious at your input. Look at the screencast or install the debugger, and share your opinion(s). Impressive job... Looking at the screencast, I think changing the current interface with the one presented in the screencast would be a definite improvement; regardless of the backend used... Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Playing with debuggers
I started about "sub watches" before reading your "every watch has a reference" On 14/09/2021 11:00, Joost van der Sluis via lazarus wrote: Op 14-09-2021 om 02:18 schreef Martin Frb via lazarus: But ideally this should just replace/extend the existing watches. Of course that also would need the debugger intf to be updated. (That does need an overhaul, and yes it could mean all existing debuggers will need a bit of work to follow / ideas welcome) What I did now, is add new dialogs, and created an debug-interface separate from the existing one. But with the idea that it could replace/be merged with the existing one. What we could also do is make the debug-windows (watches, locals, evaluation pluggable, so that a debugger can choose which one to use.) Actually all it would need is for the watch to have a new method, and to have a flag if it can be expanded. (a debugger that can not do that, will not set the flag). However, it is a bit more 1) All watches should be part of the "watches" list. (or alternative means must be found). This is so the debugger can update them, if the user changes memory (set a new value to a variable). This is also helpful for the history window, and for "idle eval" (if the watches window is closed but the debugger is idle, then eval starts anyway). The problem of not being in the "watches" exists for "debug inspector". It does not always update correctly. Adding to the "watches" would however mean that each watch needs some sort of owner, so the watch-window does not display watches added by others. So that ends up more rework (and maybe there is a better way) Of course instead of adding new watch to the "watches", those watches can be hold as a sublist by each watch. Note that watches for structures already have a list, with a description of each member field. (if the watch request had the correct flag set). But those list should probably be reworked... 2) Currently formatting (hex vs dec) is done in the debugger. That is also nonsense. As much as can be should be moved to the frontend. 3) Btw, if arrays can be expanded, precautions are needed. I don't think we want to expand 10 child values. If we go for the flag and sub-watches, then "debug history" needs to be aware of it. Ideally the entire debugger frontend could move into a package of its own too (all the current windows). Exactly, that is why I created a new debug-intf package instead of adapting the existing one. Well we may need to create an interface for the debugger frontend, and then add the frontend package. Though DebugManager already has parts of that. On the other hand its not strictly mandatory yet. As I see it your new watches can simply replace the old one. (as soon as watches provide that flag, so old watches can be displayed too) Currently the debugger intf allows to fetch watches as plain text, or as structure. But this has to be passed in as flag at the request time. Any watch object should instead have methods to fetch "sub watches" so structures can unfold. What I have now is that each object has a 'reference', and there is a separate call to get the sub-watches that belong to the reference. That way the data (in the object) and the logic (function to retrieve sub-watches) are separated. Ok, I have to look at that. Another important factor on the design of every debugger-object (eg watches) is "notify on free" or TRefCountedObject. Any debugger backend holds on to the "watch object" while it evaluates the data needed. However the frontend may remove (and free/dereference) that watch during that time. The backend must know that. (and potentially even call the callback, if the object no longer exists / the editor hint code requires this ) I don't have a solution for requesting the result as text(string) only. But that's not a bad idea. Currently we have (as param to eval) TDBGEvaluateFlag = (defNoTypeInfo, // No Typeinfo object will be returned defSimpleTypeInfo, // Returns: Kind (skSimple, skClass, ..); TypeName (but does make no attempt to avoid an alias) defFullTypeInfo, // Get all typeinfo, resolve all anchestors defClassAutoCast, // Find real class of instance, and use, instead of declared class of variable defAllowFunctionCall ); TDBGEvaluateFlags = set of TDBGEvaluateFlag; Currently TWatchValue = class(TFreeNotifyingObject) property TypeInfo: TDBGType; and TDBGType = class(TObject) property Fields: TDBGFields; which is a list of TDBGField So if (full)typeinfo is request, you have a list of fields, and you can then get the sub-watches. But that is not a good way That means you then have lots of dup data => each subwatch, has some data also in a field. ** The other downside is, that the gdb debugger needs more time to fill the fields. So not every debugger should provide them by default. ** The upside is,
Re: [Lazarus] Playing with debuggers
Op 14-09-2021 om 14:26 schreef Michael Van Canneyt via lazarus: On Tue, 14 Sep 2021, Joost van der Sluis via lazarus wrote: Hi all, I'm playing with several debuging-concepts. And I want to share this one with you. I've created a new Lazarus-debugger LazDabDebugger that can work with FpdServer. It depends on a package (LazDebugExtensionIntf) that adds another way of showing debugging variables inside Lazarus. I can write tons of texts about the background and possibilities. But for now I'm just curious at your input. Look at the screencast or install the debugger, and share your opinion(s). Impressive job... Looking at the screencast, I think changing the current interface with the one presented in the screencast would be a definite improvement; regardless of the backend used... Yes, but that needs work on the backends. And I think we can better improve and fine-tune the interface first. At this moment this is easily done. Once there are multiple backends, that becomes more work. Regards, Joost. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Playing with debuggers
On 14/09/2021 15:32, Joost van der Sluis via lazarus wrote: Looking at the screencast, I think changing the current interface with the one presented in the screencast would be a definite improvement; regardless of the backend used... Yes, but that needs work on the backends. And I think we can better improve and fine-tune the interface first. At this moment this is easily done. Once there are multiple backends, that becomes more work. If it is a flag, then each backend can choose to support it. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Playing with debuggers
On Tue, 14 Sep 2021, Joost van der Sluis via lazarus wrote: Op 14-09-2021 om 14:26 schreef Michael Van Canneyt via lazarus: On Tue, 14 Sep 2021, Joost van der Sluis via lazarus wrote: Hi all, I'm playing with several debuging-concepts. And I want to share this one with you. I've created a new Lazarus-debugger LazDabDebugger that can work with FpdServer. It depends on a package (LazDebugExtensionIntf) that adds another way of showing debugging variables inside Lazarus. I can write tons of texts about the background and possibilities. But for now I'm just curious at your input. Look at the screencast or install the debugger, and share your opinion(s). Impressive job... Looking at the screencast, I think changing the current interface with the one presented in the screencast would be a definite improvement; regardless of the backend used... Yes, but that needs work on the backends. And I think we can better improve and fine-tune the interface first. At this moment this is easily done. Once there are multiple backends, that becomes more work. I think you indeed better fine-tune first. It could be that the fine-tuning necessitates changes in the API, so better to do this with 1 backend. Once the API is stable, expand to other backends. Michael. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Playing with debuggers
Op 14-09-2021 om 14:27 schreef Martin Frb via lazarus: I started about "sub watches" before reading your "every watch has a reference" On 14/09/2021 11:00, Joost van der Sluis via lazarus wrote: Op 14-09-2021 om 02:18 schreef Martin Frb via lazarus: 1) All watches should be part of the "watches" list. (or alternative means must be found). This is so the debugger can update them, if the user changes memory (set a new value to a variable). This is also helpful for the history window, and for "idle eval" (if the watches window is closed but the debugger is idle, then eval starts anyway). Yes, as you look carefully at the screencast, you'll see that the history-option is removed. ;) And idle... I didn't really thought about that. My idea was that the gui is the most 'responsible' place to determine when to request data. And in this case this is the dialog itself. The dialogs in the screencast fetch their data only when they have to be showed, just to make it fast. Catching data in advance when the debugger is idle slightly contradict with that approach. Although, the 'gui'/dialogs can always decide to do so. But in that case a 'global cache' of retrieved variables might be useful, yes. 2) Currently formatting (hex vs dec) is done in the debugger. That is also nonsense. As much as can be should be moved to the frontend. Yes, I agree. (But for the fpdserver-backend I use the DAB-protocol which has all kind of issues with this) 3) Btw, if arrays can be expanded, precautions are needed. I don't think we want to expand 10 child values. The fpdserver has a solution for that, I only did not implement it on the Lazarus-side. But it basically adds paging, together with the load-on-demand features of the treeview, this should be no problem. If we go for the flag and sub-watches, then "debug history" needs to be aware of it. Yup, that one needs work. Ideally the entire debugger frontend could move into a package of its own too (all the current windows). Exactly, that is why I created a new debug-intf package instead of adapting the existing one. Well we may need to create an interface for the debugger frontend, and then add the frontend package. Though DebugManager already has parts of that. On the other hand its not strictly mandatory yet. As I see it your new watches can simply replace the old one. (as soon as watches provide that flag, so old watches can be displayed too) I'll see if I can implement that flag. Currently the debugger intf allows to fetch watches as plain text, or as structure. But this has to be passed in as flag at the request time. Any watch object should instead have methods to fetch "sub watches" so structures can unfold. What I have now is that each object has a 'reference', and there is a separate call to get the sub-watches that belong to the reference. That way the data (in the object) and the logic (function to retrieve sub-watches) are separated. Ok, I have to look at that. Another important factor on the design of every debugger-object (eg watches) is "notify on free" or TRefCountedObject. Any debugger backend holds on to the "watch object" while it evaluates the data needed. However the frontend may remove (and free/dereference) that watch during that time. The backend must know that. (and potentially even call the callback, if the object no longer exists / the editor hint code requires this ) That's easy. The gui requests a variable using a reference. Once it retrieves the callback with the data that response contains the reference. If the gui does not need that reference anymore, just throw away the data. The request to the backend only contains the reference. The response is a newly created object, that the receiving party gets ownership to. And, as long as there is no global-cache, a variable has only one 'owner'. All the gui-related stuff goes into the main thread. I don't have a solution for requesting the result as text(string) only. But that's not a bad idea. Currently we have (as param to eval) TDBGEvaluateFlag = (defNoTypeInfo, // No Typeinfo object will be returned defSimpleTypeInfo, // Returns: Kind (skSimple, skClass, ..); TypeName (but does make no attempt to avoid an alias) defFullTypeInfo, // Get all typeinfo, resolve all anchestors defClassAutoCast, // Find real class of instance, and use, instead of declared class of variable defAllowFunctionCall ); TDBGEvaluateFlags = set of TDBGEvaluateFlag; Currently TWatchValue = class(TFreeNotifyingObject) property TypeInfo: TDBGType; and TDBGType = class(TObject) property Fields: TDBGFields; which is a list of TDBGField So if (full)typeinfo is request, you have a list of fields, and you can then get the sub-watches. But that is not a good way That means you then have lots of dup data => each subwatch, has some data also in a field. **
Re: [Lazarus] Unable to show method
Am 14.09.21 um 12:56 schrieb Marcos Douglas B. Santos via lazarus: Hello, I have an issue creating a new component, but it can be reproduce easily using a default component: - drop a TPopupMenu - on Object Inspector, go to Events tab - double-click in `Items.OnClick` to implement - you will get the message: "Unable to show method. Please fix the error shown in the message window which is normally below the source editor." There is no message in Message Windows. Lazarus 2.0.12 r64642 FPC 3.2.0 i386-win32-win32/win64 Lazarus 2.0.13 r64940M FPC 3.2.0 i386-win32-win32/win64 Should I open a ticket? best regards, Marcos Douglas Tested on Lazarus 2.3.0 rmain-2_3-337-gfc99cfa6ee FPC 3.2.2 x86_64-linux-gtk2 You need to have at least one item WITH(!) a name. Without an item with name i get your error. John -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Unable to show method
Am 14.09.21 um 12:56 schrieb Marcos Douglas B. Santos via lazarus: Hello, I have an issue creating a new component, but it can be reproduce easily using a default component: - drop a TPopupMenu - on Object Inspector, go to Events tab - double-click in `Items.OnClick` to implement - you will get the message: "Unable to show method. Please fix the error shown in the message window which is normally below the source editor." There is no message in Message Windows. Lazarus 2.0.12 r64642 FPC 3.2.0 i386-win32-win32/win64 Lazarus 2.0.13 r64940M FPC 3.2.0 i386-win32-win32/win64 Should I open a ticket? best regards, Marcos Douglas Tested on Lazarus 2.3.0 rmain-2_3-337-gfc99cfa6ee FPC 3.2.2 x86_64-linux-gtk2 You need to have at least one item WITH(!) a name. Without an item with name i get your error. John -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Playing with debuggers
On 14/09/2021 16:11, Joost van der Sluis via lazarus wrote: 1) All watches should be part of the "watches" list. (or alternative means must be found). This is so the debugger can update them, if the user changes memory (set a new value to a variable). This is also helpful for the history window, and for "idle eval" (if the watches window is closed but the debugger is idle, then eval starts anyway). Yes, as you look carefully at the screencast, you'll see that the history-option is removed. ;) I am using the history a lot. So that needs to be fixed And idle... I didn't really thought about that. My idea was that the gui is the most 'responsible' place to determine when to request data. And in this case this is the dialog itself. The dialogs in the screencast fetch their data only when they have to be showed, just to make it fast. Well, with fpdebug eval is fast. But still, if you stop (maybe unexpected on an exception), it is good if the debugger already did the work. And it is needed anyway for the history. Catching data in advance when the debugger is idle slightly contradict with that approach. Although, the 'gui'/dialogs can always decide to do so. But in that case a 'global cache' of retrieved variables might be useful, yes. In fact, IIRC, it is not the debugger that acts on IDLE. the debugger just triggers an event. It is the history, that then starts evaluating. On the other hand its not strictly mandatory yet. As I see it your new watches can simply replace the old one. (as soon as watches provide that flag, so old watches can be displayed too) I'll see if I can implement that flag. See also what to do about TDbgFields. I think they are crucial here. See below. That's easy. The gui requests a variable using a reference. Once it retrieves the callback with the data that response contains the reference. If the gui does not need that reference anymore, just throw away the data. The request to the backend only contains the reference. The response is a newly created object, that the receiving party gets ownership to. And, as long as there is no global-cache, a variable has only one 'owner'. All the gui-related stuff goes into the main thread. Well yes, thats because you no longer use the global TWatches list. (Though subwatches would be the same) Current eval works by creating a TWatch on the IDE side, and pass that object to the debugger. And that is important, because "eval" carries more than just the watch expression "SomeVar". It may request a memory dump. Or allow function calls. Other current options (formatting hex/dec) may get dropped. But still Also the debugger backend should keep access. So it can invalidate a watch, when it continues running. That way, invalidate can happen in a single place, and not be spread to each dialog that has its own set of watches. (dialogs can still defer updating the display) On top of that validity for typeinfo/fields can be dsNotAvail. In which case there just is a default text value for the watch. Let's not over complicate things (immediately). But let's see which functionality we need, and then come up with a design for that. Yep. But even if we implement only one backend to start with, we need to keep the other in mind, to come up with an universal enough design. Also the design should allow different frontends. IHMO, new TWatches must be created for each opened value in the tree (for arrays some sort of fly-weight object may be done). Then the question is, if those watches should be (directly) added to the global "TWatches" list. (debug inspector may need such a feature anyway, so the global list may anyway end up with values not displayed on top-level watch window). The other question is how to return what currently is in TDbgFields. So there is the least amount of data duplication. I see you pass the variable to the debugger, that is ok. But that may well get abstracted into the Watch, so the watch has its own ref to the debugger, and makes the needed calls. I don't follow exactly. But if there's a need for an extra abstraction layer before sending the variable to the debugger directly, this could be added. See above, if the subwatches are already in place of the current fields, then they have a ds...validity. And if accessed they will further evaluate. Ok, let's dive something more into this particular case. I used flags for variables, for example to indicate that they are 'loading'. But at this moment I do not have an error-flag. When the 'gui' requests a variable from the backend, it can receive an error. In that cast it just fills in the error-message as the value of the variable and it's done. Not sure I follow. But that is why I advocate to create a TWatch on the gui site, and pass that TWatch to the debugger to be filled in. That way you have the full "validity" property. Main difference is that the events are based on what the gui nee
[Lazarus] git diff enhancement
In order for git to show pascal function headers. Add the following to your config [diff "fpc"] xfuncname = "^(((class[ \\t]+)?(procedure|function)|constructor|destructor|[ \\t].*[ \\t]*=[ \\t]*(class|interface|object|record)|initialization|finalization)[ \\t]*.*)$" then create a file lazarus\.git\info\attributes and add the following *.pas diff=fpc *.pp diff=fpc *.lpr diff=fpc *.inc diff=fpc Diffs then look like (note the @@ line has the "function" header) components/lazdebuggers/lazdebuggerfp/fpdebugdebugger.pas | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/components/lazdebuggers/lazdebuggerfp/fpdebugdebugger.pas b/components/lazdebuggers/lazdebuggerfp/fpdebugdebugger.pas index ea4fbee06a..8fd79d673d 100644 --- a/components/lazdebuggers/lazdebuggerfp/fpdebugdebugger.pas +++ b/components/lazdebuggers/lazdebuggerfp/fpdebugdebugger.pas @@ -1745,7 +1745,8 @@ function TFPDBGDisassembler.PrepareEntries(AnAddr: TDbgPtr; ALinesBefore, ALines p: pointer; ADump, AStatement, - ASrcFileName: string; + ASrcFileName, + AFuncName: string; ASrcFileLine: integer; i,j, sz, bytesDisassembled, bufOffset: Integer; Sym: TFpSymbol; -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] git diff enhancement
Op 14-9-2021 om 17:17 schreef Martin Frb via lazarus: In order for git to show pascal function headers. Add the following to your config [diff "fpc"] xfuncname = "^(((class[ \\t]+)?(procedure|function)|constructor|destructor|[ \\t].*[ \\t]*=[ operator? -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] git diff enhancement
On 14/09/2021 17:49, Marco van de Voort via lazarus wrote: Op 14-9-2021 om 17:17 schreef Martin Frb via lazarus: In order for git to show pascal function headers. Add the following to your config [diff "fpc"] xfuncname = "^(((class[ \\t]+)?(procedure|function)|constructor|destructor|[ \\t].*[ \\t]*=[ operator? Yes, and you can also allow spaces at the begin of the line. I did not, to try and get the outer procedure always. Because otherwise it finds nested procs, even if you are in the main body. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Unable to show method
On Tue, Sep 14, 2021 at 11:29 AM John Landmesser via lazarus wrote: > > Am 14.09.21 um 12:56 schrieb Marcos Douglas B. Santos via lazarus: > > Hello, > > > > I have an issue creating a new component, but it can be reproduce > > easily using a default component: > > - drop a TPopupMenu > > - on Object Inspector, go to Events tab > > - double-click in `Items.OnClick` to implement > > - you will get the message: "Unable to show method. Please fix the > > error shown in the message window which is normally below the source > > editor." > > > > There is no message in Message Windows. > > > > Lazarus 2.0.12 r64642 FPC 3.2.0 i386-win32-win32/win64 > > Lazarus 2.0.13 r64940M FPC 3.2.0 i386-win32-win32/win64 > > > > Should I open a ticket? > > > > best regards, > > Marcos Douglas > > > > Tested on Lazarus 2.3.0 rmain-2_3-337-gfc99cfa6ee FPC 3.2.2 > x86_64-linux-gtk2 > > You need to have at least one item WITH(!) a name. > > Without an item with name i get your error. Hello John, But the IDE gives the name, automatically... I didn't understand what you meant. And it happens in TPopupMenu, a default component that came with Lazarus. Marcos Douglas -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] git diff enhancement
Op 14-9-2021 om 17:55 schreef Martin Frb via lazarus: On 14/09/2021 17:49, Marco van de Voort via lazarus wrote: Op 14-9-2021 om 17:17 schreef Martin Frb via lazarus: In order for git to show pascal function headers. Add the following to your config [diff "fpc"] xfuncname = "^(((class[ \\t]+)?(procedure|function)|constructor|destructor|[ \\t].*[ \\t]*=[ operator? Yes, and you can also allow spaces at the begin of the line. I did not, to try and get the outer procedure always. Because otherwise it finds nested procs, even if you are in the main body. I meant "class operator" is also a method like declaration -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Fpdebug merge request 6
On 05/09/2021 21:08, Martin Frb wrote: On 05/09/2021 20:57, Christo Crause wrote: 1) adding to the IDE options. Looks that then every user using fpdebug, will see options for host/port? While really convenient for avr users, rather confusing for others? I am starting to agree with this view. There are quite a few extra remote options that should eventually be implemented, so the IDE options will become more busy. My simplistic view is that a new remote Lazarus debugger will inherit just about all its core functionality from the existing FpDebugDebugger, with added remote config options. Ok, so on the topic of user config. Step 1 is to decide, if IDE-config for avr debugging should be part of the generic FpDebug config. At current, I see that as a remote debugger, and therefore would think it should be made a separate entry in the list of debuggers. That would mean to subclass TFpDebugDebugger and add a new TFpRemoteDebugDebuggerProperties or TFpAvrDebugDebuggerProperties. Of course, it may turn out in the future that the current config will get a bit of a mix. Lets say if support for Win on Arm would be added, and some options are arm/intel specific. Or if some options are Windows/Linux specific. (Like loading debug symbols for Windows dll, that can be downloaded at MS / not planned by the way). But I still think remote debugging is a step further. (To say, it could even be that we get an fpdebug remote / actually there also is Joost's DAB debugger) Since it seems you agree, I will base below points on this There are 2 ways here: 1) find a way to pass a custom config to whatever T[avr]DbgProcess. 2) Instantiate a process class, before starting the controller, and push that in. That also has the advantage that it allows to choose between several process classes, if more than one can handle the target. *** Option 1 Initially my thought was that once you have a TFpAvrDebugDebugger you could just instantiate the TDbgAvrProcess before starting the debugger, and pass the instance to the TDbgController. Then you could set any config values to it, that you would want. But the controller should keep control of calling either StartInstance or AttachToInstance => which currently call the constructor. StartInstance/AttachToInstance would become normal methods. And the constructor would be called before them. In that case you could - create the instance of your TDbgAvrProcess outside of the controller, - set host/port/... to the instance, - and pass it to the controller before calling Run. This also needs to ensure, that the OsDbgClasses are matching the instance Some sample of how they can be set: https://gitlab.com/martin_frb/lazarus/-/tree/f-fpdebug-override-OsDbgClass-selection That can be easily extended to pass the TDbgAvrProcess instance too. The controller then just calls StartInstance/AttachToInstance . *** Option 2 have a TDbgProcessConfig class and a TDbgAvrProcessConfig subclass. That can be instantiated. And host/port/... can be copied to it. It can be passed to the controller before calling Run, and it can then be passed to the constructor. Or to StartInstance/AttachToInstance as an optional argument. Of course that also modifies StartInstance/AttachToInstance. So it seems of little benefit to me. *** Option 2a If StartInstance/AttachToInstance become normal methods, and the constructor is called before, then the controller could do: MainProcess := OSDbgClasses.DbgProcessClass.create; MainProcess.Options := MainProcess.StartIntstance(); That would mean you would not need to pre-select the OSDbgClasses. (But still could) IMHO 1 or 2a. Your opinion? -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] git diff enhancement
On 14/09/2021 21:28, Marco van de Voort via lazarus wrote: Op 14-9-2021 om 17:55 schreef Martin Frb via lazarus: On 14/09/2021 17:49, Marco van de Voort via lazarus wrote: Op 14-9-2021 om 17:17 schreef Martin Frb via lazarus: In order for git to show pascal function headers. Add the following to your config [diff "fpc"] xfuncname = "^(((class[ \\t]+)?(procedure|function)|constructor|destructor|[ \\t].*[ \\t]*=[ operator? Yes, and you can also allow spaces at the begin of the line. I did not, to try and get the outer procedure always. Because otherwise it finds nested procs, even if you are in the main body. I meant "class operator" is also a method like declaration yes, When I wrote "Yes, and you can also allow spaces at the begin of the line." The "yes" applied to "operator may be included too". And then I went on and talked about something else. I do see, how this does not come across, if you don't have inside info from inside my head. -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
