[fpc-pascal] Re: SIGTERM and thread
In the handler i just set a variable. I have solved my problem in setting my own handler later in the application, after having started the threads. It seems there is another handler which is setting when i use threads and that starts a shutdown of the application when receiving SIGTERM. Thank you for your replies. -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/SIGTERM-and-thread-tp5710294p5710300.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: RE : JSON and UTF8
On 7/11/2012 01:36, Reinier Olislagers wrote: On 11-7-2012 4:19, waldo kitty wrote: On 7/10/2012 07:00, Luiz Americo Pereira Camara wrote: With the old behavior, in an system with a system code page<> UTF8, if i try to show the parsed value of "\u4E01" in e.g. a LCL app will get garbage. I would expect to work correctly in any enviroment this means that some environments will end up with "garbage" for those UTF-8 characters that cannot be translated back to the local codepage... And your point is? that there will be data loss when converting from UTF-8 to codepages with less characters than UTF-8 has... that is what i stated and i thought it was an answer to the poster's question/problem of conversion... This change moves the conversion problem from with the JSON library to your responsibility. Please note that these same characters in a JSON string would have ended up as garbage already in the old situation. and they'll still end up as garbage anyway... especially if they do not exist in the current codepage and there's no multiple characters format to represent them... In the new situation, you have some more control over it. If you don't like the new behaviour, you can always set the conversion flag in the constructor to false instead of its default true... and move back to the earlier "conversion in a black box" method. However, if you don't have a need to convert to system codepage, as you say, you could lose information because the conversion is lossy. That has been fixed (and correctly so, IMO). For instance, I can now get a UTF8 JSON string, and write it out to a UTF8 File, process it with the FPC UTF8 functions, show it in a Lazarus TEdit or grid, etc. maybe we're talking the same basic point to each other? ;) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] SIGTERM and thread
jmbottu wrote: Hello, I wrote a handler to intercept the SIGTERM signal and execute some processing before terminating the program. It works fine. But when i add the cthreads unit in the uses clause, the application seems to do a shutdown after the end of the handler function, and the processing before terminating the program can no longer run. What's in the handler? I usually just use it to set a variable, since the CPU context at the time of the signal is unclear (i.e. might not be safe to perform a GUI op, don't know which thread was running at the time, might already be inside a non-reentrant function, and so on). -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] SIGTERM and thread
Did you try a simpler handler ? Maybe just set a variable and exit. Just a kind of test case... 2012/7/11 jmbottu : > Hello, > I wrote a handler to intercept the SIGTERM signal and execute some > processing before terminating the program. > It works fine. > > But when i add the cthreads unit in the uses clause, the application seems > to do a shutdown after the end of the handler function, and the processing > before terminating the program can no longer run. > > Thanks in advance for your help. > Jean-Marc > > -- > View this message in context: > http://free-pascal-general.1045716.n5.nabble.com/SIGTERM-and-thread-tp5710294.html > Sent from the Free Pascal - General mailing list archive at Nabble.com. > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] SIGTERM and thread
Hello, I wrote a handler to intercept the SIGTERM signal and execute some processing before terminating the program. It works fine. But when i add the cthreads unit in the uses clause, the application seems to do a shutdown after the end of the handler function, and the processing before terminating the program can no longer run. Thanks in advance for your help. Jean-Marc -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/SIGTERM-and-thread-tp5710294.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] JSON and UTF8
Em 10/7/2012 23:19, waldo kitty escreveu: On 7/10/2012 07:00, Luiz Americo Pereira Camara wrote: With the old behavior, in an system with a system code page <> UTF8, if i try to show the parsed value of "\u4E01" in e.g. a LCL app will get garbage. I would expect to work correctly in any enviroment this means that some environments will end up with "garbage" for those UTF-8 characters that cannot be translated back to the local codepage... i've been running headlong into this with another project and needing to convert from UTF-8 back to at least CP437... there are more than 255 characters in UTF-8 and there's no way i know of to translate them all back to 255 characters... even with trying to use multiples like ae for æ ( alt-145 in CP437 i think realizing that this editor can do whatever it wants to :/ )... the doublet and the character i typed the ones i was thinking of for this example, though... In the previous behavior (conversion UTF16 -> system code page) you will get a meaningless "character" anyway, i.e., those unicode characters are not correctly translated to the system code page correctly since is impossible. BTW: the original issue is already fixed. Thanks Michael Luiz ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
