Re: [fpc-pascal] Copying a Pchar to an array of bytes
El 19/5/20 a les 19:05, Giuliano Colla ha escrit: Move(Hello,buffer,len); <--- Garbage in buffer - doesn't work Move(Hello^,buffer,len) Bye -- Luca ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Copying a Pchar to an array of bytes
Thank you both guys. Il 19/05/2020 19:28, Alexander Grotewohl ha scritto: do move(Hello^, ... -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to implement a simple tcp/ip connection?
On Tue, 19 May 2020, Giuliano Colla wrote: Il 19/05/2020 18:57, Michael Van Canneyt ha scritto: They are not missing. How do you think fpsock and lnet implement non-blocking ? It's simply called O_NONBLOCK. I'm using fpc 3.0.4. With just Sockets in the uses clause both SOCK_NONBLOCK and O_NONBLOCK give an Identifier not found error. I've seen that SO_REUSEPORT was commented out, so I just defined it in my code. You'll need the unix/baseunix unit for O_NONBLOCK. I believe on windows there is a similar define, but I'm not sure where. It must exist, because the non-blocking works cross-platform. Michaem.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to implement a simple tcp/ip connection?
Giuliano Colla a écrit : Il 19/05/2020 18:57, Michael Van Canneyt ha scritto: They are not missing. How do you think fpsock and lnet implement non-blocking ? It's simply called O_NONBLOCK. I'm using fpc 3.0.4. With just Sockets in the uses clause both SOCK_NONBLOCK and O_NONBLOCK give an Identifier not found error. I've seen that SO_REUSEPORT was commented out, so I just defined it in my code. With lnet I use: fsock.SetState (ssBlocking, false); fsock.SetState (ssReuseAddress, true); -- Norbert Saint Georges http://tetrasys.fi ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to implement a simple tcp/ip connection?
Il 19/05/2020 18:57, Michael Van Canneyt ha scritto: They are not missing. How do you think fpsock and lnet implement non-blocking ? It's simply called O_NONBLOCK. I'm using fpc 3.0.4. With just Sockets in the uses clause both SOCK_NONBLOCK and O_NONBLOCK give an Identifier not found error. I've seen that SO_REUSEPORT was commented out, so I just defined it in my code. -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Copying a Pchar to an array of bytes
I believe pchar has special treatment where pchar[i] is the same as pchar^[i] do move(Hello^, ... -- Alexander Grotewohl https://dcclost.com From: fpc-pascal on behalf of Giuliano Colla Sent: Tuesday, May 19, 2020 1:05:54 PM To: FPC-Pascal users discussions Subject: [fpc-pascal] Copying a Pchar to an array of bytes I'm not too familiar with Pchar, and apparently I'm missing something. I have a Pchar string which I must copy into an array of bytes. Could someone explain me while a move doesn't work while an assignment byte by byte does? Here's a snippet of the code: buffer: array [0..1023] of byte; Hello: PChar = 'Hello from server'; len := strlen(Hello); Move(Hello,buffer,len); <--- Garbage in buffer - doesn't work for I := 0 to Pred(len) do begin buffer[I] := Byte(Hello[I]); < Works just fine. end; I fail to understand why. What I'm missing? Giuliano -- Do not do to others as you would have them do to you.They might have different tastes. ___ 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
Re: [fpc-pascal] How to implement a simple tcp/ip connection?
It was added for Linux 3.9 in 2013.. maybe the code predates that? -- Alexander Grotewohl https://dcclost.com From: fpc-pascal on behalf of Michael Van Canneyt Sent: Tuesday, May 19, 2020 12:57:37 PM To: FPC-Pascal users discussions Cc: bo.bergl...@gmail.com Subject: Re: [fpc-pascal] How to implement a simple tcp/ip connection? On Tue, 19 May 2020, Giuliano Colla wrote: > I'm struggling with a similar problem. It would appear that the easiest > way would be just take advantage of the Sockets unit. You only must > define some more constants, such as SO_REUSEPORT and SOCK_NONBLOCK which > are missing in fpc. They are not missing. How do you think fpsock and lnet implement non-blocking ? It's simply called O_NONBLOCK. For some reason, SO_REUSEPORT was commented for linux, I uncommented it. Michael. ___ 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] Copying a Pchar to an array of bytes
I'm not too familiar with Pchar, and apparently I'm missing something. I have a Pchar string which I must copy into an array of bytes. Could someone explain me while a move doesn't work while an assignment byte by byte does? Here's a snippet of the code: buffer: array [0..1023] of byte; Hello: PChar = 'Hello from server'; len := strlen(Hello); Move(Hello,buffer,len); <--- Garbage in buffer - doesn't work for I := 0 to Pred(len) do begin buffer[I] := Byte(Hello[I]); < Works just fine. end; I fail to understand why. What I'm missing? Giuliano -- Do not do to others as you would have them do to you.They might have different tastes. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to implement a simple tcp/ip connection?
On Tue, 19 May 2020, Giuliano Colla wrote: I'm struggling with a similar problem. It would appear that the easiest way would be just take advantage of the Sockets unit. You only must define some more constants, such as SO_REUSEPORT and SOCK_NONBLOCK which are missing in fpc. They are not missing. How do you think fpsock and lnet implement non-blocking ? It's simply called O_NONBLOCK. For some reason, SO_REUSEPORT was commented for linux, I uncommented it. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to implement a simple tcp/ip connection?
I'm struggling with a similar problem. It would appear that the easiest way would be just take advantage of the Sockets unit. You only must define some more constants, such as SO_REUSEPORT and SOCK_NONBLOCK which are missing in fpc. I just made some preliminary tests, and it looks like it's not so difficult to implement something quite compatible with Delphi philosophy. The SOCK_NONBLOCK flag is one of the keys. Now I'm planning to look in more detail the old Delphi implementation, in order to see how they were tacking advantage of Libc. If you're interested I'll let you know my results. Giuliano Il 16/05/2020 20:13, Bo Berglund via fpc-pascal ha scritto: I am myself struggling with this problem right now converting an old Windows service application that is configured from a Delphi programmed client operating over TCP/IP sockets. And it uses TClientSocket and TServerSocket I am going to try LNet hoping it will not bee too different from the Delphi native components... (Note: Delphi 7/Delphi 2007) -- Do not do to others as you would have them do to you.They might have different tastes. ___ 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 19/05/2020 15:55, Joost van der Sluis wrote: On 5/19/20 12:59 PM, Martin Frb wrote: Where is that documented? Assuming this is part of the API? E.g. what goes into Flags/AdditionalInfo? You misunderstood me. The class above is my own design. The variable-definition of DAB is even simpler. (As you already found out) 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. In that case, the decision to be made is, if the classes from the DebuggerIntf package can be used (potentially after being updated). There already is TFields, and that can be used (and can be generalized) for that kind of thing. 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 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) Btw, for Children (I guess Fields of a struct?) we have TDbgFields. So maybe that can be replaced? But it affects all debuggers They don't have to be fields. It can be anything. To the user it is presented as something they can collapse/expand. If you want to give a hint to the GUI how to represent the data, you can set a flag. Of course. Arrays should also be collapse/expand able, so you can inspect each element (important of array of struct). But arrays may contain thousands of elements. So only a subset would be gotten at a time. When designing collapse/expand, it is important to consider, that in the IDE data needs to be retrieved in async calls (i.e. IDE requests, debugger triggers event if data is ready) - This is (not only) because gdb debuggers are slow - This is also because the IDE needs to keep running when many values are queried, and the IDE needs to be able to send "step/run" while eval still runs => debugger should abort eval, if user wants to continue Otherwise stepping becomes very sluggish, if you have a bigger list of watches. At least that's how it is implemented in DAB. I thought it would be a good idea to add a second 'group of children', the AdditionalInfo. For example for the character-set of a string. Things like that. There are different kind of children (and the question is, if they can be mixed) - named structure members - indexed/numbered (array) members (low / high / request any (sub)range) - internal properties (e.g. charset). - Flags (set of enum) Internal properties do not need a name. They could have an ID, which is an enum. FpDebug can only provide internal properties about which it knows. So the full list of possible ID must always be known. It would be a list (unique by ID). Not sure if we need a list of base classes? It be enough to have one (internal property) "base class", and search that recursively. Or allow it to be called with an index. There also is the question, should (all/some/none) of the internal properties be created by default? The structure could have a field "set of (id-list)" which indicates the available internal props. To be created on request. And when creating a watch, one could pass in a set of ID, that should be pre-created. There also may need to be control over caching the memory that was read. If that will still be needed for evaluating further info. (a cache exists, and is used for objects) Though that creates issues: - Calling in correct thread - any data retrieval from the debugger needs to be async. I.e. on callback. The IDE demands the data, and it will be available in/after a callback. However, maybe that can be done in a subclass/wrapper in the TFpDebugDebugger class. That is were the async is currently handled. Maybe. I don't really have a solution yet. Maybe the reference-id is not that bad. (In FPDServer the id is an auto-incremented field. In a map I store the related info, like the thread-id, callstack-index and such. When this info is not available anymore, the item is removed from the map. Seems to work ok) It depends a lot where the cut between FpDebug and FpDebugDebugger goes. FpDebug would not be async. But the design should allow for the caller to easily add that. Also one more note: - It should not affect above design to much - I have not yet looked into how to archive this, but threading may get added to fpdebug at some time (not soon). That needs to reflect that only one
Re: [fpc-pascal] fpDebug extension for Visual Studio Code
On 5/19/20 12:59 PM, Martin Frb wrote: On 19/05/2020 10:42, Joost van der Sluis wrote: It is basically this class: (see https://gitlab.freepascal.org/Joost/fpdserver/blob/master/fpdbgvariables.pas) TDbgVariable = class private FName: string; FValue: string; FType: string; FVisibleInScope: Boolean; FFlags: TStringArray; FAdditionalInfo: TDbgVariableList; FInheritedChildren: TDbgVariableList; FChildren: TDbgVariableList; published property Name: string read FName write FName; property Value: string read FValue write FValue; property : string read FType write FType; property VisibleInScope: Boolean read FVisibleInScope write FVisibleInScope; property Flags: TStringArray read FFlags write FFlags; property AdditionalInfo: TDbgVariableList read FAdditionalInfo; property InheritedChildren: TDbgVariableList read FInheritedChildren; property Children: TDbgVariableList read FChildren; end; Where is that documented? Assuming this is part of the API? E.g. what goes into Flags/AdditionalInfo? You misunderstood me. The class above is my own design. The variable-definition of DAB is even simpler. (As you already found out) 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. Btw, for Children (I guess Fields of a struct?) we have TDbgFields. So maybe that can be replaced? But it affects all debuggers They don't have to be fields. It can be anything. To the user it is presented as something they can collapse/expand. If you want to give a hint to the GUI how to represent the data, you can set a flag. At least that's how it is implemented in DAB. I thought it would be a good idea to add a second 'group of children', the AdditionalInfo. For example for the character-set of a string. Things like that. Things like Children should have a Getter, so they can be produced on demand. Yep. But I see this structure more as a an interface. A definition about how the data should be structured. In DAB they resolve this by setting some reference-id. So instead of the children, you get an ID. And if you want to have the children, just send a request with the given Id, and you will receive the children. Not a real solution for our case, I would think. Though that creates issues: - Calling in correct thread - any data retrieval from the debugger needs to be async. I.e. on callback. The IDE demands the data, and it will be available in/after a callback. However, maybe that can be done in a subclass/wrapper in the TFpDebugDebugger class. That is were the async is currently handled. Maybe. I don't really have a solution yet. Maybe the reference-id is not that bad. (In FPDServer the id is an auto-incremented field. In a map I store the related info, like the thread-id, callstack-index and such. When this info is not available anymore, the item is removed from the map. Seems to work ok) 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 19/05/2020 12:59, Martin Frb wrote: Where is that documented? Assuming this is part of the API? The closest I could find: https://microsoft.github.io/debug-adapter-protocol/specification#Types_Variable I would much prefer if "Flags: TStringArray" could be a "set of (...)" And then somehow be mapped. FpDebug could take a "class of TDbgVariable". And then create whatever subclass you need. So your subclass could map that into strings. ___ 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 19/05/2020 10:42, Joost van der Sluis wrote: Yes, you write about it earlier. Now it's time to discuss things. Looking at the DAB-protocol I came to some new insights. Microsoft managed to create a simple interface which makes it possible for all kinds of debuggers to work with the same GUI. Just by adding an abstraction layer. Only thing is that I missed a few functions and do not need others. So I've added my own abstraction layer. Now it is in the FPDServer project, but I think it should be made part of fpDebug itself. It is basically this class: (see https://gitlab.freepascal.org/Joost/fpdserver/blob/master/fpdbgvariables.pas) TDbgVariable = class private FName: string; FValue: string; FType: string; FVisibleInScope: Boolean; FFlags: TStringArray; FAdditionalInfo: TDbgVariableList; FInheritedChildren: TDbgVariableList; FChildren: TDbgVariableList; published property Name: string read FName write FName; property Value: string read FValue write FValue; property : string read FType write FType; property VisibleInScope: Boolean read FVisibleInScope write FVisibleInScope; property Flags: TStringArray read FFlags write FFlags; property AdditionalInfo: TDbgVariableList read FAdditionalInfo; property InheritedChildren: TDbgVariableList read FInheritedChildren; property Children: TDbgVariableList read FChildren; end; I think that we can give a frontend (Lazarus, Console, DAB) all the information it needs with this structure. The advantage is that it is layered, so a GUI can collapse information. We could expand the TDbgVariableBuilder to create these structures. For strings for example, we could add the length, string-type, binary-representation and character-set of the string in AdditionalInfo. In VS Code this info will end-up as a child of the variable, which a user could expand if needed. A lot of the existing functionality can be used. Where is that documented? Assuming this is part of the API? E.g. what goes into Flags/AdditionalInfo? Btw, for Children (I guess Fields of a struct?) we have TDbgFields. So maybe that can be replaced? But it affects all debuggers Things like Children should have a Getter, so they can be produced on demand. Though that creates issues: - Calling in correct thread - any data retrieval from the debugger needs to be async. I.e. on callback. The IDE demands the data, and it will be available in/after a callback. However, maybe that can be done in a subclass/wrapper in the TFpDebugDebugger class. That is were the async is currently handled. ___ 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 5/19/20 12:22 AM, Martin Frb wrote: On 18/05/2020 23:43, Joost van der Sluis wrote: All the basics should work, if someone could test it a bit that would be nice. Threading-support is still very lacking, and how variables are presented is not really nice. I'll be working on that. While this can be changed in PascalBuilder, there are some considerations. Some of those may want to become configurable. So not sure yet. More likely the formatting may want to depend an arguments passed to the functions. In the Lazarus IDE currently representation of the values is entirely to the backend. And that is plain wrong. The IDE will have to have some influence on that. I haven't yet given it much consideration. Just putting it out there for thought Yes, you write about it earlier. Now it's time to discuss things. Looking at the DAB-protocol I came to some new insights. Microsoft managed to create a simple interface which makes it possible for all kinds of debuggers to work with the same GUI. Just by adding an abstraction layer. Only thing is that I missed a few functions and do not need others. So I've added my own abstraction layer. Now it is in the FPDServer project, but I think it should be made part of fpDebug itself. It is basically this class: (see https://gitlab.freepascal.org/Joost/fpdserver/blob/master/fpdbgvariables.pas) TDbgVariable = class private FName: string; FValue: string; FType: string; FVisibleInScope: Boolean; FFlags: TStringArray; FAdditionalInfo: TDbgVariableList; FInheritedChildren: TDbgVariableList; FChildren: TDbgVariableList; published property Name: string read FName write FName; property Value: string read FValue write FValue; property : string read FType write FType; property VisibleInScope: Boolean read FVisibleInScope write FVisibleInScope; property Flags: TStringArray read FFlags write FFlags; property AdditionalInfo: TDbgVariableList read FAdditionalInfo; property InheritedChildren: TDbgVariableList read FInheritedChildren; property Children: TDbgVariableList read FChildren; end; I think that we can give a frontend (Lazarus, Console, DAB) all the information it needs with this structure. The advantage is that it is layered, so a GUI can collapse information. We could expand the TDbgVariableBuilder to create these structures. For strings for example, we could add the length, string-type, binary-representation and character-set of the string in AdditionalInfo. In VS Code this info will end-up as a child of the variable, which a user could expand if needed. A lot of the existing functionality can be used. Regards, Joost. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
