[fpc-pascal] Delphi TService
Does somebody have a compatible TService somewhere for dual compilation Delphi/Lazarus purposes? There is daemonapp, but that seems to be incompatible, but maybe it can be wrapped? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi TService
On Wed, 20 May 2020, Marco van de Voort wrote: Does somebody have a compatible TService somewhere for dual compilation Delphi/Lazarus purposes? There is daemonapp, but that seems to be incompatible, but maybe it can be wrapped? It can be easily wrapped. The only difference is that the registration is separate from the actual service implementation. The usual events are there just as in TService. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Custom attributes
Hi! FPC compiler has a define when custom attributes are present? Something like FPC_HAS_CONSTREF, to say when constref is available... -- The best regards, Fabio Luis Girardi PascalSCADA Project http://sourceforge.net/projects/pascalscada http://www.pascalscada.com ___ 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
Seems like the first message did not make it to the list. Maybe because of the attachments... Retry: Op 19-05-2020 om 16:42 schreef Martin Frb: On 19/05/2020 15:55, Joost van der Sluis wrote: It is not documented, and, to be honest, only name, value and type are being used now. It is just a rough idea, we have to figure things out. Ah, I see. About DebuggerIntf: 1) DebuggerIntf was meant to be the API between IDE and the debugger-backend. The backend is TFpDebugDebugger. FpDebug is not the backend, its used by the backend. But it currently provides for the backend, and that means it uses those classes I was very disappointed when i (re?)-discovered that fpDebug has a dependency on DebuggerIntf. 2) DebuggerIntf was never "designed". It was ripped out of GDBMIDebugger, with the hope to be cleaned up and refactored. That hope is still there That also raises the question what you base your DAB classes on. Some code that you will need, does live in TFpDebugDebugger - Detecting the instantiated class, instead of the declared class. - Checking breakpoint conditions (Though part of this should move into FpDebug) - Handling Exceptions / stepping to except,finally (not sure if that is likely to move) It is even more complex then I could remember. Thanks for the update, very useful. I think it is difficult to discuss a new design/solution at a distance. I've tried to catch the problems in some pictures. Picture1: http://amira.cnoc.nl/fpc/FPDebugDesign1.svg Picture1 show what I want to achieve. I want to use the formatting of variables and such in another environment as Lazarus. And ind the long term I want to make it possible for Lazarus to use other debuggers. Also for other languages. (Using DAB or others) Picture2: http://amira.cnoc.nl/fpc/FPDebugDesign2.svg Picture2 shows the current situation at a high abstraction level. The logic for displaying variables is all over the place, as you explained. Please correct me, if I'm wrong somewhere. Picture3: http://amira.cnoc.nl/fpc/FPDebugDesign3.svg Picture3 shows a possible solution. We add a new class, in the picture called 'formatter' to handle the display of variables. As an input it will need some 'handler' which implements an interface with functions to retrieve debug-information and access memory. It's output can be in something like the TDbgVariable format I showed before. (Needs adaptation, though). In the picture I let the IDE make a direct connection to this new 'formatter'. But maybe it is better to do this in DebuggerIntf. I also thought about a migration-path: we can just add this new route, without using it. And then enable it bit-by-bit. We could alse add a 'default' implementation in DebuggerIntf. So all debug-handlers may use it, or add overrides to do it in a different way. What do you think? 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 20/05/2020 17:50, Joost van der Sluis wrote: I was very disappointed when i (re?)-discovered that fpDebug has a dependency on DebuggerIntf. It is a bit of a catch22: - On the one hand, FpDebug is/should be stand alone. - On the other hand, it would be a pity to have to copy all the used types. There is basic stuff like TDbgPtr. If needs must, that could be redeclared, with IFDEF But there is also result classes for PascalBuilder (and probably somewhere stackframes). Removing this may add a lot of overhead. FpDebug also uses LazUtils package. And that wont be easy to resolve, unless by "copy and paste" :( Picture1: http://amira.cnoc.nl/fpc/FPDebugDesign1.svg Picture1 show what I want to achieve. I want to use the formatting of variables and such in another environment as Lazarus. And ind the long term I want to make it possible for Lazarus to use other debuggers. Also for other languages. (Using DAB or others) Should the arrows be the other way round? console === "has a / uses " ===> var/type-formatter Picture2: http://amira.cnoc.nl/fpc/FPDebugDesign2.svg Picture2 shows the current situation at a high abstraction level. The logic for displaying variables is all over the place, as you explained. Please correct me, if I'm wrong somewhere. "There are several implementations of DebuggerIntf, each for a specifig debugger" There is only one "DebuggerIntf" (aka API). The Interface is "designed" to provide base-classes for both: the IDE and each backend. So GDBMIDebugger is a "debugger backend". As such it inherits the provided base classes of the DebuggerIntf. The Backends then use an actual debugger (gdb, lldb, fpDebug) Formatting does not really happen in the Frontend (IDE) or DebuggerIntf. It happens either in the "Backend": reformat from what gdb gave us. Or in the debugger: FpDebug/PascalBuilder. Picture3: http://amira.cnoc.nl/fpc/FPDebugDesign3.svg Picture3 shows a possible solution. We add a new class, in the picture called 'formatter' to handle the display of variables. As an input it will need some 'handler' which implements an interface with functions to retrieve debug-information and access memory. It's output can be in something like the TDbgVariable format I showed before. (Needs adaptation, though). I think some arrows go the wrong way round? In the picture I let the IDE make a direct connection to this new 'formatter'. But maybe it is better to do this in DebuggerIntf. I also thought about a migration-path: we can just add this new route, without using it. And then enable it bit-by-bit. We could alse add a 'default' implementation in DebuggerIntf. So all debug-handlers may use it, or add overrides to do it in a different way. DAB and Console => those should be handled like debugger backends. Except they do not need IDE compatibility. But they do the same task. And add FpDebugServer. *** FORMATTER CLASS First of all "Formatter" (PascalBuilder) is already somewhat exchangeable. It is currently up to the "backend" what to call to get text. "Backend" calls Parser (currently PascalParser) to get FpDebug internal value. "Backend" hands result to Formatter (PascalBuilder) The Formatter still needs to read memory. This needs to be the case, as the amount of memory to be read can depend on the format (i.e. a pointer in the data may display the address, or read the data at the address). Some formatting should be responsibility of the IDE (or debugger frontend) 1) I.e Changing decimal to hex => no need for the backend 2) On the other hand, the IDE does not know, how to display a "structure" (record, class, object, or even none Pascal). That is work the backend needs to do. (That is as a single text, not be expanding a [+] subitems view) 3) The backend also needs to deliver different data for hex dump. Most of that exists, in the current classes in TDebuggerIntf. (with some issues though) - If you look at using FpDebug directly, then you use TFpValue. (returned by PascalParser, or any Parser you want to add) All you need is to encapsulate PascalBuilder into a class. And stick the value and the builder into yet another object, holding both of them. TPascalBuilder would then be a formatter class. It would also deliver the structures for fields, elements, children. TPascalBuilder can be configured, for verbosity. (optino to skip all the typenames, it currently includes) With TPascalBuilder it can also be passed to whatever code builds stackframes. So formatting for those can be affected. (because the class carries the config) - For the IDE it is more work. There needs to be an abstraction that works with all backends. And the abstraction must be serializable (for DebugHistory window) / or partly serializable. For the IDE it is important that the "formatter" delivers fields, elements, children in the classes provided by TDebuggerInf. Otherwise the backends, must copy all the data into the expe
Re: [fpc-pascal] fpDebug extension for Visual Studio Code
On 20/05/2020 19:54, Martin Frb wrote: If you look at using FpDebug directly, then you use TFpValue. (returned by PascalParser, or any Parser you want to add) All you need is to encapsulate PascalBuilder into a class. And stick the value and the builder into yet another object, holding both of them. TPascalBuilder would then be a formatter class. It would also deliver the structures for fields, elements, children. TPascalBuilder can be configured, for verbosity. (optino to skip all the typenames, it currently includes) With TPascalBuilder it can also be passed to whatever code builds stackframes. So formatting for those can be affected. (because the class carries the config) And then there is/was the idea with: getting data on request. Creating a list of objects for all the fields of a class, needs to be optional. Well it is, by means of flags passed to Pascalbuilder. What is missing, is the ability to later upgrade. There are 2 considerations. 1) re-reading target mem. There already is a cache for target mem. If TFpValue and TPascalBuilder are hold by a "watch value class", this can control the cache, and keep the memory. This memory is only the class. Vaules by ref, like strings are not included. 2) adding list of fields, to watch that was text only This will also rebuild the text. That can be suppressed, if needed ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Custom attributes
On 20/05/2020 15:55, Fabio Luis Girardi via fpc-pascal wrote: > FPC compiler has a define when custom attributes are present? > > Something like FPC_HAS_CONSTREF, to say when constref is available... In general, such defines are only added if they are required for bootstrapping. For the same reason they are also removed again after a while, so you really should not use them. The only supported way to check for the presence of certain features is by performing a version check (FPC_FULLVERSION > ). Jonas ___ 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
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. I provide them, in the hope they will help choosing a path for the backend. The IDE should receive a "TWatchWhateverValue" from any of the backend, that provides: 1) async interface (that is actually for the benefit of the backends) Currently the IDE would call a method (example callstack) - IDE calls "count" => not yet known = 0 - the backend starts retriving the value, and once the value is avail, it triggers an "changed" event - IDE calls count again. - IDE starts accessing the items in the list. They may be available, but if not the return "evaluating" (or whatever dummy value), and the backend will get them and trigger "change" again. Alternative, there could be a CountState, that would return if the count is already avail. The trigger to get the count, would still be to call "count". However, the backend must be able to retrieve any requested data from fpdebug, and that should be in a format that is ready for the IDE. (TDebuggerIntf classes) Evaluating huge data, may need to be "interruptible" => either called in small blocks (like the callstack at current), or by run in a thread, and check for an "abort state". For single watches this is currently not needed. 2) the IDE must be able to retrieve values in different formats, with minimum work of the backend (but allowing for async) - An ordinal value must either be known as ordinal (none text form), then the IDE can do dec/hex/bin... or it can be retrieved from the TWatchWhateverValue in any of those formats (and does not need complete re-eval) - Hex representation: this can do a re-eval if needed - A structure may have different text formats (more or less verbose...) - objects for fields/members (array element) can be retrieved. array element, probably re-use one instance, changing the value. One would not want to create thousands of instances Because any op can be async, the current way of just calling the getter, and getting a dummy "evaluating" value/object works well. The IDE does not need to differ if the value is final or not. If it is not final a "changed" event is triggered, and the IDE starts again (same as if the debugger entered pause) 3) The TWatchWhateverValue must be able to store (and serialize) its data. Or a part of it. It must be able to "work on the stored data only". Watches are added to debug history. If viewed from history, no further eval is possible. The debugged app has changed its state... Currently this stores the display-text. Limiting changed to display format. It would be up to the IDE how match the watch stores, and the watch would then only be able to return the stored subset of data. It also must be able to serialize, as the history can be saved/loaded to/from xml. - The async part may make things tricky IF a watch asks for the list of fields, it gets TDbgFields or similar. But a field may be an object with fields of its own. So if this TDbgField is asked for its field, that must somehow be async to. Yet the baseclass may not necessary need that implementation.. So PascalBuilder would need to create Fields, but the exact subclass could be given by the backend. Disclaimer: I have not fully thought that through And many thinks should probably only be added, when they will be needed. As I said, just to help keeping the design flexible enough. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
