Re: [fpc-pascal] FpDebug hands-on: AnsiStrings
On 21/05/2020 20:19, Joost van der Sluis wrote: Might be, you could see this as a saveguard. But my goal is to cut-out the middle part of the string. That's formatting Well, we should have the safeguard. And make it configurable. ... See below Part 2 is formatting related In most cases the user does not need a 10kb string, the user may want offset 1500 len 500. Ideally then the debugger only reads that part. That part may move to the formatter. But also may need an extension to target reading the correct subset of the data. Indeed Now for your goal. That does not conflict with the safeguard. When "getting the middle of a string" is added, then the safeguard still applies. (Well maybe). If the user says get me SomeString[1000..1999] (1000 chars) => technically the safeguard should apply (no problem if user configurable. This may sound nonesense, when the user gives hardcode dimensions. But what if SomeString[1000..1000+i] Btw, It may be a good idea to teach pascal parser that syntax. (also for arrays) Anyway: A formatter can temp increase the safeguard. So there is no problem with keeping it on this level. To get substrings, one needs to be able to read the length, without actually starting to retrieve the text. (would be a waste, to retrieve text that will not be needed). So maybe implement GetMemberCount to return the amount of "char"s (bytes / words for widestring) And then one new method is needed to get the substring. Need to check which other dwarf types could benefit. (For arrays members are retrieved individually, but maybe target mem could be read and cached (like for structures) If needed I would rather add the 2 new functions. Though it seems the data is actually returned as part of the longstring? No, it is not, because the result is assigned to an AnsiString, and therefor the compiler could decide to change it's codepage. In this function or somewhere further down the line. Then the result type should be changed to rawbytestring or whatever is safe? At least so that the formatter can get it correct. Other calling code may assign it to whatever that code wants What you are saying is that the TFpValue doesn't do the formatting. But it retrieves the data. And indeed it's very suitable for that. Should be that way. But then, we should be consistent. And do not let any other classes (The formatter I was talking about, but also the PrettyPrinter and such) retrieve data. Such a class could always create a TFpValue for their own use Have to look at it case by case. Ideally yes. It may have to be judged for performance: Array members are gotten by re-using the same TFpValue. Otherwise retrieving a large array would be expensive... If the formatter would all the sudden need to create extra object for each array value Anyway case by case. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FpDebug hands-on: AnsiStrings
Op 21-05-2020 om 18:25 schreef Martin Frb: On 21/05/2020 17:29, Joost van der Sluis wrote: But that the design is problematic can be seen in a comment in the file: // TODO: X Dynamic max limit This is not really about formatting. A corrupt debug target, could return a string length of 2^31, not something that the debugger should attempt to read. (newer gdb have similar options, if the data is to large they return nothing / for strings we can do better and get the start) That can happen when reading locals before the stackframe is set up. Might be, you could see this as a saveguard. But my goal is to cut-out the middle part of the string. That's formatting Part 2 is formatting related In most cases the user does not need a 10kb string, the user may want offset 1500 len 500. Ideally then the debugger only reads that part. That part may move to the formatter. But also may need an extension to target reading the correct subset of the data. Indeed If needed I would rather add the 2 new functions. Though it seems the data is actually returned as part of the longstring? No, it is not, because the result is assigned to an AnsiString, and therefor the compiler could decide to change it's codepage. In this function or somewhere further down the line. If you need individual calls to retrieve that info, it could be done by something like GetMember. GetMember has to much overhead. as it returns a big object. But something like GetDataProperty(AnPropId: Integer): Pointer; would be generic enough to return any additional data. (yes ID is integer. quicker to much than doing string compare) What you are saying is that the TFpValue doesn't do the formatting. But it retrieves the data. And indeed it's very suitable for that. But then, we should be consistent. And do not let any other classes (The formatter I was talking about, but also the PrettyPrinter and such) retrieve data. Such a class could always create a TFpValue for their own use Regards, Joost. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FpDebug hands-on: AnsiStrings
On 21/05/2020 17:29, Joost van der Sluis wrote: I've added codepage-support for ansistrings, compiled with -gw3. This is done in the TFpValueDwarfV3FreePascalString class, which does the heavy work regarding the formatting of strings. Although there is also some code in TFpDebugDebugger.EvaluateExpression and probably other places that change the formatting of string-values. So I've made my change in TFpValueDwarfV3FreePascalString, but I don't know if this is the right place. After all, it is about formatting, and this class is related to the Dwarf-debug info. On the other hand. I do understand why this logic in implemented here. This is *the* place where all the relevant information is present. But that the design is problematic can be seen in a comment in the file: // TODO: X Dynamic max limit This is not really about formatting. A corrupt debug target, could return a string length of 2^31, not something that the debugger should attempt to read. (newer gdb have similar options, if the data is to large they return nothing / for strings we can do better and get the start) That can happen when reading locals before the stackframe is set up. Part 2 is formatting related In most cases the user does not need a 10kb string, the user may want offset 1500 len 500. Ideally then the debugger only reads that part. That part may move to the formatter. But also may need an extension to target reading the correct subset of the data. Currently config for FpDebug does not exist. It needs to be integrated with the config for LazDebuggerFp (i.e. use TDebuggerProperties so it can be streamed). Yet separated from config that is only for LazDebuggerFp. That is why the value is hardcoded. I want to avoid having to copy all the values in from LazDebuggers config to FpDebug config (which happens now for the 2 configs avail) max memory limits can be passed via TFpDbgMemReader = class(TDbgMemReader) TDbgMemReader could have a property that can be read by the dwarf classes. This seems an easy task, but it is not. TFpValueDwarfV3FreePascalString is not bound to the GUI or does not have formatting-settings. But it is the place where the formatting takes place! But adding a formatting-setting (like a max-length for strings) at this location would be really strange. Well the current code (your commit) does not do formatting. It adds the info to the string. The formatter, getting the longstring, can read the codepage from it. The formatter can also read the string byte by byte. SetCodePage(RResult, Codepage, False); Does not change the raw data in the string (only the meaning it has). As long as it does not accidentally get converted while being passed around. I see two solutions: Besides the AsString property we could add a GetAsString procedure with some parameters on how to format the string. Maybe the easiest at this moment, and this morning I though it was a good idea. (Note that I want to add more stuff, like function to retrieve the code-page, and the raw-data) If needed I would rather add the 2 new functions. Though it seems the data is actually returned as part of the longstring? If you need individual calls to retrieve that info, it could be done by something like GetMember. GetMember has to much overhead. as it returns a big object. But something like GetDataProperty(AnPropId: Integer): Pointer; would be generic enough to return any additional data. (yes ID is integer. quicker to much than doing string compare) Or you add dedicated properties to TFpValueDwarfV3FreePascalString and use type casting. *** For starters, I would go with that, and later redesign I am not sure about adding to many methods to for up the hierarchy, and needing meaningless defaults for them. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FpDebug hands-on: AnsiStrings
Excuses for the empty mail... Op 21-05-2020 om 17:29 schreef Joost van der Sluis: This seems an easy task, but it is not. TFpValueDwarfV3FreePascalString is not bound to the GUI or does not have formatting-settings. But it is the place where the formatting takes place! But adding a formatting-setting (like a max-length for strings) at this location would be really strange. I know that it was probably me who who designed it this way. But maybe I learned a few new things in all those years... Regards, Joost. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FpDebug hands-on: AnsiStrings
Op 21-05-2020 om 17:29 schreef Joost van der Sluis: Op 20-05-2020 om 20:48 schreef Martin Frb: Ok, here are some of my ideas/hopes/dreams/wishes for the IDE They are all "ideas only", with on knowledge of when/if they may be done. Ok, clear. Thanks again for the info. I think we can conclude that most parts are there. It only needs some polishing. Except for the threading and smoothness of the debugging-experience in Lazarus. There we have some work to do... Now, a hands-on example. We can discuss the theory later on again. I've added codepage-support for ansistrings, compiled with -gw3. This is done in the TFpValueDwarfV3FreePascalString class, which does the heavy work regarding the formatting of strings. Although there is also some code in TFpDebugDebugger.EvaluateExpression and probably other places that change the formatting of string-values. So I've made my change in TFpValueDwarfV3FreePascalString, but I don't know if this is the right place. After all, it is about formatting, and this class is related to the Dwarf-debug info. On the other hand. I do understand why this logic in implemented here. This is *the* place where all the relevant information is present. But that the design is problematic can be seen in a comment in the file: // TODO: X Dynamic max limit This seems an easy task, but it is not. TFpValueDwarfV3FreePascalString is not bound to the GUI or does not have formatting-settings. But it is the place where the formatting takes place! But adding a formatting-setting (like a max-length for strings) at this location would be really strange. I see two solutions: Besides the AsString property we could add a GetAsString procedure with some parameters on how to format the string. Maybe the easiest at this moment, and this morning I though it was a good idea. (Note that I want to add more stuff, like function to retrieve the code-page, and the raw-data) But then again, maybe the other solution, to split this formatting-logic into another class might be better... I'll try if I can split the logic. If doable, that might be better. (Still a lot of theory, though) Regards, Joost. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] FpDebug hands-on: AnsiStrings
Op 20-05-2020 om 20:48 schreef Martin Frb: Ok, here are some of my ideas/hopes/dreams/wishes for the IDE They are all "ideas only", with on knowledge of when/if they may be done. Ok, clear. Thanks again for the info. I think we can conclude that most parts are there. It only needs some polishing. Except for the threading and smoothness of the debugging-experience in Lazarus. There we have some work to do... Now, a hands-on example. We can discuss the theory later on again. I've added codepage-support for ansistrings, compiled with -gw3. This is done in the TFpValueDwarfV3FreePascalString class, which does the heavy work regarding the formatting of strings. Although there is also some code in TFpDebugDebugger.EvaluateExpression and probably other places that change the formatting of string-values. So I've made my change in TFpValueDwarfV3FreePascalString, but I don't know if this is the right place. After all, it is about formatting, and this class is related to the Dwarf-debug info. On the other hand. I do understand why this logic in implemented here. This is *the* place where all the relevant information is present. But that the design is problematic can be seen in a comment in the file: // TODO: X Dynamic max limit This seems an easy task, but it is not. TFpValueDwarfV3FreePascalString is not bound to the GUI or does not have formatting-settings. But it is the place where the formatting takes place! But adding a formatting-setting (like a max-length for strings) at this location would be really strange. I see two solutions: Besides the AsString property we could add a GetAsString procedure with some parameters on how to format the string. Maybe the easiest at this moment, and this morning I though it was a good idea. (Note that I want to add more stuff, like function to retrieve the code-page, and the raw-data) But then again, maybe the other solution, to split this formatting-logic into another class might be better... I'll try if I can split the logic. If doable, that might be better. (Still a lot of theory, though) Regards, Joost. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpDebug extension for Visual Studio Code
> On May 19, 2020, at 4:43 AM, Joost van der Sluis wrote: > > Hi all, > > As I wrote before I'm working on a fpDebug-extension for Visual Studio Code, > based on the DAB (Debug Adapter Protocol). Excellent, I applaud your efforts. I'm busy now but I'll be sure to test this later. I'm using LLDB in VSCode as my primary debugger for Pascal now so I'm eager to see what improvements you may have made. As for the language server I've taken a break from it for a week but I've implemented ~90% of the protocol already and once I get it cleaned up it will be usable also. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
