Re: [fpc-pascal] Question about System.Move()
Op 2021-01-11 om 15:26 schreef Benito van der Zander via fpc-pascal: Hi, perhaps a safe, generic function for this copying could be added to the RTL. Like: Procedure ManagedMove(const source: T;var dest: T;count: SizeInt); a) For non-managed types it would be the same as Move(source, dest, count*sizeof(T)) Then you want to simply use ismanagedtype and move(). Moving the move() to a separate generic procedure will only lead to many instantiations of what is basically a move() procedure. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fcl-web: Trequest.RemoteAddr is empty (sometimes)
On Tue, 12 Jan 2021, Luca Olivetti via fpc-pascal wrote: El 12/1/21 a les 10:24, Michael Van Canneyt via fpc-pascal ha escrit: Am I right thinking that, even if several copies of the above method are running, each will get it's own local variables, so the LocCommandQueue variable (as well as the other locals) won't be clobbered by another copy? Or should I declare them as threadvar? If FCommandQueue is the only thing that is set during SyncNewConnection based on TRequest, then yes. yes to "each will get its [*] own local" or yes to "should I declare them as threadvar"? Yes to "each will get its own local copy". I don't think threadvars are needed here. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fcl-web: Trequest.RemoteAddr is empty (sometimes)
El 12/1/21 a les 10:24, Michael Van Canneyt via fpc-pascal ha escrit: Am I right thinking that, even if several copies of the above method are running, each will get it's own local variables, so the LocCommandQueue variable (as well as the other locals) won't be clobbered by another copy? Or should I declare them as threadvar? If FCommandQueue is the only thing that is set during SyncNewConnection based on TRequest, then yes. yes to "each will get its [*] own local" or yes to "should I declare them as threadvar"? For safety, I would Nil the FCommandQueue after assigning it to locCommandQueue. No need, it's only used as a return value from the synchronized method. [*] sorry for the "it's" in the original sentence Bye -- Luca ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fcl-web: Trequest.RemoteAddr is empty (sometimes)
El 08/01/2021 a las 10:16, Luca Olivetti via fpc-pascal escribió: El 7/1/21 a les 16:59, Luca Olivetti via fpc-pascal ha escrit: El 7/1/21 a les 16:15, Luca Olivetti via fpc-pascal ha escrit: Hello, I need to tailor the content based on the remote ip address. I use the property RemoteAddr of a TRequest, but sometimes it is empty. I see that it is a header, what I didn't see (yet, I'll trace through the code later) is if it is sent from the remote host or is it filled based on the ip address of the connection. If the former, is there a more reliable way to obtain the connected ip address? If the latter is it a bug? I now see that it set in TFPHTTPConnection.ReadRequestHeaders: Result.RemoteAddress := SocketAddrToString(FSocket.RemoteAddress) In turn SocketAddrToString returns an empty string if the address is ipv6, but in my case it shouldn't be (the clients, firefox under windows 10 uses the ipv4 address of the server and most of the time I get the correct remote address, even from the same client). Besides, it seems that the server only listens on ipv4. I'm puzzled, I really can't see where this empty RemoteAddress could come from. Bye In windows 10 when you connect to localhost, it may connect with IPV6 and route to ipv4 with weird results. Try to connect using IP 127.0.0.1 http://127.0.0.1 You may also add in C:\Windows\System32\drivers\etc\hosts a line like localhost4 127.0.0.1 and then http://localhost4 You may also disable IPV6 service if you don't use it. I have, because it is seldom used, it looks like every device/system still works only with IPV4 -- Saludos Santiago A. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fcl-web: Trequest.RemoteAddr is empty (sometimes)
On Tue, 12 Jan 2021, Luca Olivetti via fpc-pascal wrote: El 8/1/21 a les 11:14, Luca Olivetti via fpc-pascal ha escrit: El 8/1/21 a les 11:06, Michael Van Canneyt via fpc-pascal ha escrit: Are you using https ? No, plain text http. An even weirder fact is that I seem to get the wrong ip address (i.e. the address of a different client). I think I found the possible cause: I have an own thread that spawns a TEmbeddedHttpServer (actually a derived class to manage server-sent-events, https://lists.lazarus-ide.org/pipermail/lazarus/2020-June/238072.html) with threaded:=true. My thread has a method to manage the requests and it does this FRequest:=ARequest; Synchronize(@SyncNewConnection); if FCommandQueue<>nil then . I think that, since the method is called from a different thread for each request, if two requests come at the same time, the FRequest and/or the FCommandQueue (which is set in the synchronized method) could get mixed up. If there is only 1 FRequest instance/location in your thread, then this is definitely so... I now did 2 things: 1) protected that part of the code with a critical section 2) use TThread.Synchronize(nil,..) (since it's not my thread but another one FCrit.Acquire; FRequest:=ARequest; TThread.Synchronize(nil,@SyncNewConnection); LocCommandQueue:=FCommandQueue; FCrit.Release; if LocCommandQueue<>nil then... WDYT? From the info you gave me, I think this could work, yes. Care should be taken that the critical lock does not cause a deadlock, I don't know what happens in SyncNewConnection. Am I right thinking that, even if several copies of the above method are running, each will get it's own local variables, so the LocCommandQueue variable (as well as the other locals) won't be clobbered by another copy? Or should I declare them as threadvar? If FCommandQueue is the only thing that is set during SyncNewConnection based on TRequest, then yes. For safety, I would Nil the FCommandQueue after assigning it to locCommandQueue. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fcl-web: Trequest.RemoteAddr is empty (sometimes)
El 8/1/21 a les 11:14, Luca Olivetti via fpc-pascal ha escrit: El 8/1/21 a les 11:06, Michael Van Canneyt via fpc-pascal ha escrit: Are you using https ? No, plain text http. An even weirder fact is that I seem to get the wrong ip address (i.e. the address of a different client). I think I found the possible cause: I have an own thread that spawns a TEmbeddedHttpServer (actually a derived class to manage server-sent-events, https://lists.lazarus-ide.org/pipermail/lazarus/2020-June/238072.html) with threaded:=true. My thread has a method to manage the requests and it does this FRequest:=ARequest; Synchronize(@SyncNewConnection); if FCommandQueue<>nil then . I think that, since the method is called from a different thread for each request, if two requests come at the same time, the FRequest and/or the FCommandQueue (which is set in the synchronized method) could get mixed up. I now did 2 things: 1) protected that part of the code with a critical section 2) use TThread.Synchronize(nil,..) (since it's not my thread but another one FCrit.Acquire; FRequest:=ARequest; TThread.Synchronize(nil,@SyncNewConnection); LocCommandQueue:=FCommandQueue; FCrit.Release; if LocCommandQueue<>nil then... WDYT? Am I right thinking that, even if several copies of the above method are running, each will get it's own local variables, so the LocCommandQueue variable (as well as the other locals) won't be clobbered by another copy? Or should I declare them as threadvar? Bye -- Luca ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] SQLDB: Set port in TSQLConnector
On Mon, 11 Jan 2021, Virgo Pärna via fpc-pascal wrote: On Fri, 08 Jan 2021 14:25:09 -0300, Luis - SoftSAT Sistemas via fpc-pascal wrote: I'm trying to connect to a Firebird database with TSQLConnector, but I can't seem to find a way to set the port number. Looking at TIBConnection, there is a port property, but none in TSQLConnector. You can use HostName := ServerName/Port; Port is normally handled using the Params property, so Params.Values['port']:='1234' should do. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] SQLDB: Set port in TSQLConnector
On Fri, 08 Jan 2021 14:25:09 -0300, Luis - SoftSAT Sistemas via fpc-pascal wrote: > I'm trying to connect to a Firebird database with TSQLConnector, but I can't > seem to find a way to set the port number. > > Looking at TIBConnection, there is a port property, but none in TSQLConnector. You can use HostName := ServerName/Port; -- Virgo Pärna virgo.pa...@mail.ee ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PTCGraph Causing 217
I've made a sample program that demonstrates the problem https://gist.github.com/Zaaphod/936901eb5f31df5044d2bd36a7cf6c91 When I was testing it, I found out that the problem shows up also with PTCCRT.Keypressed, Procedure to re-produce bug in Putimage 1.Run program in Windows 2.Do something that activates Windows User Account Control like open an administrator command prompt 3.Program crashes with exitcode 217 EAccessViolation: Access violation on line 108 which is doing Putimage, even if you answer NO to user account control Procedure to re-produce bug in Keypressed 1.UnComment //Until ptccrt.Keypressed; Comment out //Until ptccrt.Keypressed; 2.Run Program in Windows 3.Do something that activates Windows User Account Control like open an administrator command prompt 4.Program crashes with exitcode 217 EAccessViolation: Access violation on line 114 which is doing Keypresed (sometimes the error is on putimage) Other things that cause it: Unplug monitor and plug it back in Change Display settings Putting computer to sleep Unknown reasons. system just idle James From: fpc-pascal On Behalf Of Nikolay Nikolov via fpc-pascal Sent: Thursday, January 7, 2021 2:17 AM To: fpc-pascal@lists.freepascal.org Cc: Nikolay Nikolov Subject: Re: [fpc-pascal] PTCGraph Causing 217 On 1/6/21 5:44 PM, James Richters via fpc-pascal wrote: I've been having issues with PTCGraph causing a runtime Error 217 : EAccessViolation: Access violation at seemingly random times in my program. The error is always on a line with either GetImage() or PutImage() but not the same one. The program can run for hours with no problems doing GetImage and PutImage every second or so, and then it just stops with this error. I know that if something disrupts the screen. like if I install a program and the Windows user control thing asks for a password, that ALWAYS causes this to happen, or if I unplug my monitor and plug it back in.. I find that this happens.. but lately it seems to happen for no reason. I don't know enough about it to track it down, but is there some way I Can find out what causes this and prevent the error?It would be nice if I could detect the condition that causes this issue, and if I find that the issues is present, just stop trying to do Getimage() or PutImage() until the condition is resolved. Can you provide an example program and exact steps to reproduce this bug? Nikolay ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
