Re: [fpc-pascal] AnsiStrupper Error
On 26 May 2014, at 01:59, Daniel Gaspary wrote: The code bellow is throwing an exception and I don't know why. It used to work. program Project1; uses sysutils; var s : AnsiString; begin s := 'a'; AnsiStrupper(PAnsiChar(s)); end. It works fine with FPC 2.6.4 (Linux x86-64 bits). No, it corrupts your string constant. I'm using FPC trunk (Revision 27818): An unhandled exception occurred at $00428E4D: EAccessViolation: Access violation $00428E4D And that corruption is now caught: http://wiki.freepascal.org/User_Changes_Trunk#Literal_storage_memory_has_been_made_read-only Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi compatible anonymous functions
On 05/23/2014 05:46 PM, Craig Peterson wrote: On 5/23/2014 2:09 AM, Michael Schnell wrote: rather simple: - declaring the event method as something like closure resulting it having it do an auto-free on exit. more advanced (needing the RTL to provide pool of threads to fire on demand): - parallel loop and future support like in Prism (In fact I don't see anonymous functions - see thread topic - here.) I'm not sure exactly what you're asking/proposing. Yes, there are alternative syntaxes for closures that might be more Pascalish, but I want something that's compatible with Delphi because we need to keep using it on Windows for the foreseeable future. Hmmm parallel loop and future in fact _is_ compatible with Delphi: here Delphi Prism. (It's not the fault of Lazarus, that Delphi is not compatible with itself :-( .) The discussion has somehow moved from, anonymous functions do OpenMP support. I understand that anonymous functions is some kind of syntax candy for stuff that - with some additional typing - could be done without, OpenMP support is about allowing parallel work - especially useful on the now ubiquitous multi-processor boxes - by means of the rtl. parallel loop and future is about syntax candy for parallel execution - e.g. via OpenMP. So my question was about the real target of the discussion. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EpikTimer v1.0.1 released
On 05/24/2014 01:55 PM, Graeme Geldenhuys wrote: I've spoken to Tom and he agreed. We moved the EpikTimer repository to Github. The Lazarus-CCR version will be deleted by Tom in due time. While I am happy about your move to do an official release of EpikTimer. I'd like to add that IMHO it would be appropriate to have the file epiktimer.pas that is independent of Lazarus and makes sense to be use in not Lazarus based projects in the fpc RTL svn. I did not check the latest release, yet, but I suppose there are some more files (that allow for visible placing of a TEpikTimer Instance on a form). Same should come as a Lazarus package. Thanks for your work, -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi compatible anonymous functions
Am 26.05.2014 09:52 schrieb Michael Schnell mschn...@lumino.de: On 05/23/2014 05:46 PM, Craig Peterson wrote: On 5/23/2014 2:09 AM, Michael Schnell wrote: rather simple: - declaring the event method as something like closure resulting it having it do an auto-free on exit. more advanced (needing the RTL to provide pool of threads to fire on demand): - parallel loop and future support like in Prism (In fact I don't see anonymous functions - see thread topic - here.) I'm not sure exactly what you're asking/proposing. Yes, there are alternative syntaxes for closures that might be more Pascalish, but I want something that's compatible with Delphi because we need to keep using it on Windows for the foreseeable future. Hmmm parallel loop and future in fact _is_ compatible with Delphi: here Delphi Prism. (It's not the fault of Lazarus, that Delphi is not compatible with itself :-( .) That's because Delphi Prism is not Delphi. It's a product they licensed and added the name Delphi Prism on. Oxygene (what Prism is based on) was never intended to stay Delphi compatible. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi compatible anonymous functions
On 05/26/2014 11:35 AM, Sven Barth wrote: That's because Delphi Prism is not Delphi. It's a product they licensed and added the name Delphi Prism on. Oxygene (what Prism is based on) was never intended to stay Delphi compatible. Of course I do know this, But They decided to call It Delphi, while the original name by RemObj was just Oxygen. Moreover the mobile stuff they include with Delhi XE seems to be nearly as poorly compatible with the mainstream Delphi as Prism is. Hence Lazarus' quest for overall Delphi compatibility is not a possible aim. (even disregarding maybe nearly solvable issues like codepage based strings.) -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EpikTimer v1.0.1 released
On 26/05/2014 11:14, Michael Schnell wrote: While I am happy about your move to do an official release of EpikTimer. I'd like to add that IMHO it would be appropriate to have the file epiktimer.pas that is independent of Lazarus and makes sense to be use in not Lazarus based projects in the fpc RTL svn. I don't understand exactly what you are trying to say. Is this: - a request to Graeme - a promise that you are going to provide a patch to the FPC RTL - a remark - something else Thanks, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EpikTimer v1.0.1 released
On 05/26/2014 11:55 AM, Reinier Olislagers wrote: I don't understand exactly what you are trying to say. Is this: - a request to Graeme - a promise that you are going to provide a patch to the FPC RTL - a remark - something else Sorry for being unclear. I meant this as a general request to the powers of the fpc (rtl) project with svn write access to allow Greame, Tom (or maybe myself) to include the TEpikTimer class in the next release of the official RTL. (And maybe help with doing so) In the Lazarus Forum I am trying to discuss some improvements in EpikTimer, I would like to introduce before that move. (I already did and tested this with the pre-release file that had been provided on Lararus CCR). Thanks for listening, -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EpikTimer v1.0.1 released
On 26/05/2014 12:12, Michael Schnell wrote: On 05/26/2014 11:55 AM, Reinier Olislagers wrote: I meant this as a general request to the powers of the fpc (rtl) project with svn write access to allow Greame, Tom (or maybe myself) to include the TEpikTimer class in the next release of the official RTL. Well, the normal procedure for doing this is to submit a patch if you want something to be added to FPC. If you need help with that, you could put up your modified code on a public repository. An example is somebody who modified Lazarus to use/create other widgetsets: https://github.com/x2nie/LiteZarus ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EpikTimer v1.0.1 released
On 05/26/2014 12:42 PM, Reinier Olislagers wrote: Well, the normal procedure for doing this is to submit a patch if you want something to be added to FPC. Thanks for your hints. As I locally do use svn, I suppose I will be able to do a patch for a not yet existing file :) I can't do a patch that will have the file integrated in the make process, though. Anyway before doing this I'd like to do some more improvements and tests. (including trying to use ) A big ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EpikTimer v1.0.1 released
On 05/26/2014 12:42 PM, Reinier Olislagers wrote: Well, the normal procedure for doing this is to submit a patch if you want something to be added to FPC. Thanks for your hints. As I locally do use svn, I suppose I will be able to do a patch for a not yet existing file :) I can't do a patch that will have the file integrated in the make process, though. Anyway before doing this I'd like to do some more improvements and tests (including trying to use vDSO). A big problem with EpikTimer is that is _should_ be decently useful with all archs and OSes. This might be a nightmare to test. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi compatible anonymous functions
In our previous episode, Michael Schnell said: using it on Windows for the foreseeable future. Hmmm parallel loop and future in fact _is_ compatible with Delphi: here Delphi Prism. (It's not the fault of Lazarus, that Delphi is not compatible with itself :-( .) It is not a part of Delphi we are compatible with. And before you ask, neither we are compatible with 3rd rail or radphp. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] How to get the borders and background color of the Message Box
Hi, Looking for guidance on formatting of the attached application Output snippet. I'm having trouble on getting the borders and background color of the Message Box to display correctly. Any help will be appreciated. Nitin http://free-pascal-general.1045716.n5.nabble.com/file/n5719375/Application_Snippets.jpg -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/How-to-get-the-borders-and-background-color-of-the-Message-Box-tp5719375.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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EpikTimer v1.0.1 released
On Mon, May 26, 2014 13:12, Michael Schnell wrote: . . A big problem with EpikTimer is that is _should_ be decently useful with all archs and OSes. This might be a nightmare to test. You don't need to do that - the new addition may be enabled selectively for the CPU+OS combinations for which it has been already tested successfully (and this approach is preferred over enabling it for everything after testing just a small subset of all targets supported by FPC). Additional targets would then get enabled later by the individual target maintainers as appropriate. Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] AnsiStrupper Error
On Mon, May 26, 2014 at 3:04 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: And that corruption is now caught: http://wiki.freepascal.org/User_Changes_Trunk#Literal_storage_memory_has_been_made_read-only Thank You, Jonas. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to get the borders and background color of the Message Box
On Mon, May 26, 2014 14:04, nitinjain wrote: Hi, Looking for guidance on formatting of the attached application Output snippet. I'm having trouble on getting the borders and background color of the Message Box to display correctly. Any help will be appreciated. Nitin http://free-pascal-general.1045716.n5.nabble.com/file/n5719375/Application_Snippets.jpg You have already received a lot of help for this topic, haven't you? Which of the previously discussed approaches (unit Video, unit Crt, Free Vision with its unit msgbox, ...) do you try to use now? Drawing of the window border was exactly discussed here in the last message in the previous thread; the general window background could be basically covered by the same approach as drawing the window border by writing out width-2 instances of ' ' between the vertical lines at the beginning and end. Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EpikTimer v1.0.1 released
Am 26.05.2014 12:12 schrieb Michael Schnell mschn...@lumino.de: On 05/26/2014 11:55 AM, Reinier Olislagers wrote: I don't understand exactly what you are trying to say. Is this: - a request to Graeme - a promise that you are going to provide a patch to the FPC RTL - a remark - something else Sorry for being unclear. I meant this as a general request to the powers of the fpc (rtl) project with svn write access to allow Greame, Tom (or maybe myself) to include the TEpikTimer class in the next release of the official RTL. (And maybe help with doing so) I don't see a need for this in the FCL yet. At least not until the dust that you are whirling up has settled down as FPC has a quite slow release cycle. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi compatible anonymous functions
On 05/26/2014 02:03 PM, Marco van de Voort wrote: neither we are compatible with 3rd rail or radphp. I never heard somebody call one of these Delphi. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EpikTimer v1.0.1 released
On 05/26/2014 02:06 PM, Tomas Hajny wrote: You don't need to do that - the new addition may be enabled selectively for the CPU+OS combinations for which it has been already tested successfully (and this approach is preferred over enabling it for everything after testing just a small subset of all targets supported by FPC). Additional targets would then get enabled later by the individual target maintainers as appropriate. In fact I would like to use EpikTimer in my upcoming ActiveNoGUI Lazarus WidgetType. ActiveNoGUI is especially useful with small Gadgets that typically don't have X32 or X64 archs. That is why I am after multi-arch support. And that is why I feel that it makes sense to use EpikTimer in ActiveNoGUI instead of directly including the timer related code. With EpicTimer the ActiveNoGUI implementation itself would be automatically arch and OS independent. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EpikTimer v1.0.1 released
On 05/26/2014 02:23 PM, Sven Barth wrote: I don't see a need for this in the FCL yet. At least not until the dust that you are whirling up has settled down as FPC has a quite slow release cycle. I absolutely agree. Nonetheless I feel that (a decently multi-arch enabled version) of TEpikTimer does make sense in the FCL as a courtesy class (in fact TList is a courtesy class as well, as it does not support syntax candy but just is provided directly for the user to use). Especially as the multi-arch support of EpikTimer is really critical and it would be very helpful to know that this issue is managed by the fpc team. Hence including it in the svn seems nice to me, especially regarding that I'd like to use it in a Lazarus enhancement. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi compatible anonymous functions
On May 26, 2014, at 7:47 AM, Michael Schnell mschn...@lumino.de wrote: neither we are compatible with 3rd rail or radphp. I never heard somebody call one of these Delphi. RadPHP was originally marketed under the name Delphi for PHP. -- Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] fpc stderr broken?
Hi all,
When I compile a program with a duplicate $R
directive fpc (2.6.4) gives an error. Unlike other error messages this
error is written to stderr (under Linux and OS X).
Running fpc in a shell seems to always work. The output/stdout and
stderr are both written nicely together.
But when the stderr is redirected (e.g. fpc test.pas 2 errors.txt)
then errors.txt is empty and the stderr error message is lost. And
depending on the quantity of output/stdout some output bytes in front
of the error are missing too.
The same happens when running fpc via TProcess (with or without
poStdErrToOutput).
Is it a bug in fpc or in ppcx64 or in fpcres?
Here is an example:
debugressourcestderrbug.pas:
program debugressourcestderrbug;
{$mode objfpc}{$H+}
uses
Classes, SysUtils;
{$R debugressourcestderrbug.lfm}
{$R debugressourcestderrbug.lfm}
begin
writeln;
end.
debugressourcestderrbug.lfm:
object Form1: TForm1
Left = 337
end
--
Running in terminal:
fpc debugressourcestderrbug.pas
...snip...
Compiling debugressourcestderrbug.pas
Compiling resource debugressourcestderrbug.or
Error: Duplicate resource: Type = 10, Name = TFORM1, Lang ID =
debugressourcestderrbug.pas(23,1) Error: Error while compiling resources
...snap...
--
Running in terminal with stderr redirect:
fpc debugressourcestderrbug.pas 2 error.txt
...snip...
Compiling debugressourcestderrbug.pas
Compiling resource debugressourcestderrbug.or
debugressourcestderrbug.pas(23,1) Error: Error while compiling resources
...snap...
error.txt is empty.
Mattias
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi compatible anonymous functions
On 05/26/2014 03:20 PM, Craig Peterson wrote: RadPHP was originally marketed under the name Delphi for PHP. very funny stuff :-) . -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to get the borders and background color of the Message Box
Thanks Tomas Hajny-2, Actually I tried with video unit, but on freepascal.org site (http://www.freepascal.org/docs-html/rtl/video ) I was read that “The video unit should not be used together with the crt unit”. And I am using CRT unit as well. I posted same issue on previous blog also, but not getting any answers after that, so now I posted newly with snippets. If you have any another options instead of video unit then it will definitely helpful to us. Regards, Nitin -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/How-to-get-the-borders-and-background-color-of-the-Message-Box-tp5719375p5719386.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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi compatible anonymous functions
On May 26, 2014, at 2:52 AM, Michael Schnell mschn...@lumino.de wrote: I understand that anonymous functions is some kind of syntax candy for stuff that - with some additional typing - could be done without, OpenMP support is about allowing parallel work - especially useful on the now ubiquitous multi-processor boxes - by means of the rtl. parallel loop and future is about syntax candy for parallel execution - e.g. via OpenMP. So my question was about the real target of the discussion. I am interested in anonymous functions specifically. See my second post in the thread for why. OpenMP support would be a nice feature, but even if it were Delphi/VCL compatible, it only gets me half of my goal, and I only included the threading support first because it was shorter to describe. Replacing our usage of fibers/coroutines is a *much* more pressing issue. In any case, neither Free Pascal nor Delphi support OpenMP right now, but Delphi does support futures and parallel loops using the OmniThreadLibrary, which requires anonymous methods. Getting anonymous methods into Free Pascal is a much more manageable short term goal than waiting for OpenMP support to be specified, implemented, and debugged. -- Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi compatible anonymous functions
On 05/26/2014 03:32 PM, Craig Peterson wrote: In any case, neither Free Pascal nor Delphi support OpenMP right now, but Delphi does support futures and parallel loops using the OmniThreadLibrary, ... Nice ! I did not know that. I understand that you mean this without the Prism compatible syntax candy for t futures and parallel loops ?!?!? which requires anonymous methods. Getting anonymous methods into Free Pascal is a much more manageable short term goal than waiting for OpenMP support to be specified, implemented, and debugged. seems like a viable way to go. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi compatible anonymous functions
On 5/26/2014 8:43 AM, Michael Schnell wrote: Nice ! I did not know that. I understand that you mean this without the Prism compatible syntax candy for t futures and parallel loops ?!?!? Yes. The syntax isn't as nice, but it works: Parallel.ForEach(1, testSize).Execute( procedure (const elem: integer) begin if IsPrime(elem)then outQueue.Add(elem); end); http://otl.17slon.com/tutorials.htm -- Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi compatible anonymous functions
I might be wrong, but reading through OmniThreadLibrary - the usage of anonymous functions is optional. The regular language structures could be used: global functions/object methods. Why having anonymous support is critical for the usage of the library? thanks, Dmitry On Mon, May 26, 2014 at 9:49 AM, Craig Peterson cr...@scootersoftware.comwrote: On 5/26/2014 8:43 AM, Michael Schnell wrote: Nice ! I did not know that. I understand that you mean this without the Prism compatible syntax candy for t futures and parallel loops ?!?!? Yes. The syntax isn't as nice, but it works: Parallel.ForEach(1, testSize).Execute( procedure (const elem: integer) begin if IsPrime(elem)then outQueue.Add(elem); end); http://otl.17slon.com/tutorials.htm -- Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi compatible anonymous functions
Sorry, you've actually somehow answered my questions earlier... I'm rereading the thread now. On Mon, May 26, 2014 at 9:53 AM, Dmitry Boyarintsev skalogryz.li...@gmail.com wrote: I might be wrong, but reading through OmniThreadLibrary - the usage of anonymous functions is optional. The regular language structures could be used: global functions/object methods. Why having anonymous support is critical for the usage of the library? thanks, Dmitry On Mon, May 26, 2014 at 9:49 AM, Craig Peterson cr...@scootersoftware.com wrote: On 5/26/2014 8:43 AM, Michael Schnell wrote: Nice ! I did not know that. I understand that you mean this without the Prism compatible syntax candy for t futures and parallel loops ?!?!? Yes. The syntax isn't as nice, but it works: Parallel.ForEach(1, testSize).Execute( procedure (const elem: integer) begin if IsPrime(elem)then outQueue.Add(elem); end); http://otl.17slon.com/tutorials.htm -- Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to get the borders and background color of the Message Box
On Mon, May 26, 2014 15:29, nitinjain wrote: Hi Nitin, Actually I tried with video unit, but on freepascal.org site (http://www.freepascal.org/docs-html/rtl/video ) I was read that “The video unit should not be used together with the crt unit”. And I am using CRT unit as well. I posted same issue on previous blog also, but not getting any answers after that, so now I posted newly with snippets. If you have any another options instead of video unit then it will definitely helpful to us. Assuming that previous blog = previous thread, I'm not aware of any messages appearing in this mailing list related to this discussion (appearing in various threads) which would not be answered by me and/or others. You seem to be accessing our mailing list via Nabble rather than by e-mail - I don't use Nabble myself, so I cannot judge whether there's been some post from you not getting to the list (and thus missing responses from people subscribed to the list). Let me summarize - if I look at the mailing list archive for May (http://lists.freepascal.org/pipermail/fpc-pascal/2014-May/thread.html), I see the following threads: - 'Identifier not found MEMW' (ended by Marco's question to which you have not responded) - 'How to get GO32 Unit file' (responded by me) - 'How To Rewrite/Replace Below MEM And MEMW' (ended by my response with a follow-up question to you) - 'Segmentation Error using VideoBuf' (started from another e-mail address, finished by my suggestion to post a compilable crashing code) - 'Drawing window out line' (again started from the other e-mail address, responded by me with information how to achieve the wanted result by using just unit Crt in one post, but also providing more detailed information about in/compatibility between units Video and Crt in another post - see http://lists.freepascal.org/pipermail/fpc-pascal/2014-May/041991.html; that thread also included suggestion from Mark Morgan Loyd for using FreeVision as another alternative). Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpc stderr broken?
On Mon, 26 May 2014, Mattias Gaertner wrote: Hi all, When I compile a program with a duplicate $R directive fpc (2.6.4) gives an error. Unlike other error messages this error is written to stderr (under Linux and OS X). Running fpc in a shell seems to always work. The output/stdout and stderr are both written nicely together. But when the stderr is redirected (e.g. fpc test.pas 2 errors.txt) then errors.txt is empty and the stderr error message is lost. And depending on the quantity of output/stdout some output bytes in front of the error are missing too. The same happens when running fpc via TProcess (with or without poStdErrToOutput). Is it a bug in fpc or in ppcx64 or in fpcres? fpcres, I think, because the compiler does not use stderr, to my knowledge... Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpc stderr broken?
On Mon, 26 May 2014 16:46:01 +0200 (CEST) Michael Van Canneyt mich...@freepascal.org wrote: On Mon, 26 May 2014, Mattias Gaertner wrote: Hi all, When I compile a program with a duplicate $R directive fpc (2.6.4) gives an error. Unlike other error messages this error is written to stderr (under Linux and OS X). Running fpc in a shell seems to always work. The output/stdout and stderr are both written nicely together. But when the stderr is redirected (e.g. fpc test.pas 2 errors.txt) then errors.txt is empty and the stderr error message is lost. And depending on the quantity of output/stdout some output bytes in front of the error are missing too. The same happens when running fpc via TProcess (with or without poStdErrToOutput). Is it a bug in fpc or in ppcx64 or in fpcres? fpcres, I think, because the compiler does not use stderr, to my knowledge... Confirmed. Calling fpcres gives the problem. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi compatible anonymous functions
On Fri, May 16, 2014 at 11:45 AM, Craig Peterson cr...@scootersoftware.comwrote: 2) Our application has multiple independent top-level windows, like a web browser. There is no MainForm. Each window can show modal dialogs that only disable that specific window. [snip] Ugh, but with anonymous functions replacing ShowMyDialog vs ShowMyDialogDone, you're in much worse positions. It's likely that you would have to the duplicate code. I'd assume that after modal dialog code is somehow matches to some other code in the system. Model-View-Controller pattern comes into play. The dialog itself is just a way to get a confirmation from a user to do an actions. It's likely that the same action could take place without a confirmation from a user. So, with anonymous functions, you'd need to duplicate the same action code across the system. (Anonymous functions are just for here-and-now usage). No reason to enumerate the cons of code duplication. No directly related to usage of anonymous functions... ...and please note, I'm not trying to criticize your work, but give an excuses for my point of view... Using a threading for GUI control is generally bad idea. Most of standard GUI APIs (OSX, Windows, *nixes) have a note in 90% of their functions - do not use in multiple threads. Introducing threads to handle GUI is potentially dangerous (due to all threading syncing issues) and an overhead. Most of solutions doesn't really need threads, as well as usage of threads increases resources consumption. ...back to anonymous: So making a choice of changing the code to use Fibers, rather than using ShowDialog / DoneDialog was not so good after all. Right now you're in position to change the code code from Fibers to something more portable... And yet again using ShowDialog / DoneDialog is one of the options. Another point to use anonymous functions is storing of State that could be later use in processing the resulting code. The compiler is doing for you it's good and bad. Good - you don't need to write any extra code, Bad - pretty much anything could go into the state, even the things you don't need to be there (or do need to be there, but not there at all). So, I do think that storing the state explicitly is a better option, even though extra lines of code would be required. thanks, Dmitry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi compatible anonymous functions
On Fri, May 16, 2014 at 11:45 AM, Craig Peterson cr...@scootersoftware.comwrote: 1) I want to use the OmniThreadLibrary. Setting up objects and thread descendents is fine in moderation, but it's too much of a hassle when you just want a quick parallel for loop. Anonymous functions are bad for unit testing. Why? Because they do exist only at the place of the call and depends on the state of at the time the call. And thus they cannot be tested separately without the caller. I'd assume the parallel execution is definitely needed since the actions you're separating are time consuming. They're time consuming, because they might be complex. Having an ability to test a complex code separately (outside the execution environment/application) is a big benefit. Yet again - the re-usage of the code. What if you switch from OmniThreadLibrary to OpenMP (or whatever other threading library) that doesn't provide support for anonymous functions. What if you'd need to write a separate application, that doesn't have the requirement to use threads. Using the regular code (in procedures or methods) reduces the number of changes you'd need to do. I've mentioned it before OmniThreadLibrary doesn't require you to use anonymous functions. thanks, Dmitry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi compatible anonymous functions
On 5/26/2014 10:02 AM, Dmitry Boyarintsev wrote: Ugh, but with anonymous functions replacing ShowMyDialog vs ShowMyDialogDone, you're in much worse positions. It's likely that you would have to the duplicate code. I'd assume that after modal dialog code is somehow matches to some other code in the system. Model-View-Controller pattern comes into play. The dialog itself is just a way to get a confirmation from a user to do an actions. It's likely that the same action could take place without a confirmation from a user. So, with anonymous functions, you'd need to duplicate the same action code across the system. (Anonymous functions are just for here-and-now usage). No reason to enumerate the cons of code duplication. Dmitry, no offense, but you're making a lot of assumptions about our code with no basis to do so, and I'm honestly not interested in getting into a philosophical debate about the correct way to develop software. There are cases where anonymous methods will work well and cases where we'll have to split it up. It's a tool that I'd like to have available, not something I'm going to cram where it doesn't belong. Using a threading for GUI control is generally bad idea. Most of standard GUI APIs (OSX, Windows, *nixes) have a note in 90% of their functions - do not use in multiple threads. Introducing threads to handle GUI is potentially dangerous (due to all threading syncing issues) and an overhead. Most of solutions doesn't really need threads, as well as usage of threads increases resources consumption. Fibers are cooperative threads, not pre-emptive ones. They're the way GUI APIs worked in the past (Windows 3.1, MacOS Classic) and GUI APIs generally still support them just fine. Recent releases of OS X have started having trouble with it, but older ones worked just fine. There are no synchronization issues because there isn't more than one running at the same time. So making a choice of changing the code to use Fibers, rather than using ShowDialog / DoneDialog was not so good after all. Right now you're in position to change the code code from Fibers to something more portable... And yet again using ShowDialog / DoneDialog is one of the options. Cocoa already has what I'm asking for built in to Objective C language and the Cocoa/sheets API. Many of the functions that show dialogs, that previously would have had ShowDialog/DoneDialog behavior, accept Objective C blocks now, which are very similar to how anonymous methods would work in this context. In any case, we've already done the ShowDialog/DoneDialog thing and it was unpleasant to work with and resulted code that was much harder to understand. Anonymous functions are bad for unit testing. Why? Because they do exist only at the place of the call and depends on the state of at the time the call. And thus they cannot be tested separately without the caller. *GUIs* are bad for unit testing. *Threading* is bad for unit testing. Anonymous functions are an implementation detail and are no better or worse for testing than ShowDialog/DoneDialog or OpenMP would be. In the cases where we'd use it for things like parallel loops, I'd test the outer function as a whole, and the inner functions that it calls. I don't need to unit test the anonymous function separately just because it has function in it's name. You might as well be arguing that I should break out every for loop and if statement into its own function that I can test it separately. Having an ability to test a complex code separately (outside the execution environment/application) is a big benefit. Again, you're assuming things about the testability and structure of our code that have nothing to do with the discussion at hand. What if you switch from OmniThreadLibrary to OpenMP (or whatever other threading library) that doesn't provide support for anonymous functions. What if you'd need to write a separate application, that doesn't have the requirement to use threads. Using the regular code (in procedures or methods) reduces the number of changes you'd need to do. Switching from OmniThreadLibrary to some eventual OpenMP implementation would involve removing the anonymous function syntax and turning it into a regular begin..end block for a parallel for loop. That wouldn't involve any visible changes to the objects themselves because that's all encapsulated in the outer function call. The chances of our code being reused in something that doesn't use threads is non-existent, and irrelevant either way. I've mentioned it before OmniThreadLibrary doesn't require you to use anonymous functions. Even if that's true, it would significantly reduce the expressiveness of the resulting code, and I don't know how true it is because the author has specifically said that he doesn't support FPC because of how intrinsic anonymous functions are to the design. -- Craig Peterson Scooter Software
Re: [fpc-pascal] Delphi compatible anonymous functions
On Mon, May 26, 2014 at 12:17 PM, Craig Peterson cr...@scootersoftware.comwrote: Dmitry, no offense, but you're making a lot of assumptions about our code with no basis to do so, and I'm honestly not interested in getting into a philosophical debate about the correct way to develop software. There are cases where anonymous methods will work well and cases where we'll have to split it up. It's a tool that I'd like to have available, not something I'm going to cram where it doesn't belong. That's very valid point. I do not know how your code, I don't know who is based and organized. So I have to go from my experience on how the problems (with UI) are solved. I also have a vast experience of (language/libraries) tools being misused and underused. (My fear here is that anonymous functions will be misused dramatically once being available. And I'm fine with that for C-syntax languages, but I'd hate to handle in future for Pascal) My general point is - in many cases (pascal) language is underused. And many problems could be solved without a new language constructions. Use the reasonable minimum as much as possible. So sticking to an existing syntax minimum improves portability of the code (portability not just across platforms and/or compilers, but for integration with different 3d-party libraries). You've done your considerations and you've done your choice, so let's wait until anonymous functions are available in FPC. thanks, Dmitry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EpikTimer v1.0.1 released
On 26.05.2014 15:07, Michael Schnell wrote: On 05/26/2014 02:23 PM, Sven Barth wrote: I don't see a need for this in the FCL yet. At least not until the dust that you are whirling up has settled down as FPC has a quite slow release cycle. I absolutely agree. Nonetheless I feel that (a decently multi-arch enabled version) of TEpikTimer does make sense in the FCL as a courtesy class (in fact TList is a courtesy class as well, as it does not support syntax candy but just is provided directly for the user to use). TList and TEpikTimer are two completely different things. The former is already required out of Delphi compatibility while TEpikTimer is not. Additionally container structures can be considered essential for basically every software while a timing component is not... Especially as the multi-arch support of EpikTimer is really critical and it would be very helpful to know that this issue is managed by the fpc team. And you don't think we FPC developers have enough to do with the remaining RTL and FCL on all those platforms we support? Hence including it in the svn seems nice to me, especially regarding that I'd like to use it in a Lazarus enhancement. Then let it be put in Lazarus in components/epiktimer ... Lazarus releases more often than FPC does. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Java crash when fpc library CallVoidMethod in a thread.
Hello. What is the best way to unthread a procedure ? I have try with a fptimer outside the thread but the thing that disturb me is that you need a tcomponent as owner to create it. And in the library i do not use any tcomponent... How to create a fptimer without owner ? I have try with fptimer.create(Nil) but without luck... Thanks PS: if you have a better idea how to unthread, im verry interessed - Many thanks ;-) -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Java-crash-when-fpc-library-CallVoidMethod-in-a-thread-tp5719098p5719400.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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Java crash when fpc library CallVoidMethod in a thread.
On Mon, 26 May 2014, fredvs wrote: Hello. What is the best way to unthread a procedure ? I have try with a fptimer outside the thread but the thing that disturb me is that you need a tcomponent as owner to create it. And in the library i do not use any tcomponent... How to create a fptimer without owner ? I have try with fptimer.create(Nil) but without luck... A fptimer.create(nil) should always work. fptimer does not need a non-nil owner. But if you don't have components, you probably also don't have a main application loop. So I think it likely that then you probably also do not call checksynchronize() at regular intervals, meaning that fptimer will not work, as this is required to get the ticks. So, the Nil owner is (with 99.99% certainty) not the problem. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Java crash when fpc library CallVoidMethod in a thread.
Yep, Michael, thanks... Ok then for Nil owner... Hum, checksynchronize(), i do not realy understand how to use in the thread/loop... In the loop i do not use synchronize, because the procedure that is called is a java/method and synchronize is for procedure of object outside the thread... (Or i miss something ). Ps : this is the very last obstacle for total intégration into java (thread are working perfect, only calling java/method iniside the thread is problematic...) Ps2 : maybe i have to forget to use thread inside a library (but if it is possible then: whow...) - Many thanks ;-) -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Java-crash-when-fpc-library-CallVoidMethod-in-a-thread-tp5719098p5719402.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/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TZipper and special file names like atenção.txt (#26213)
2014-05-24 5:02 GMT-03:00 Reinier Olislagers reinierolislag...@gmail.com: On 24/05/2014 08:33, Michael Van Canneyt wrote: On Fri, 23 May 2014, Craig Peterson wrote: The Info-zip project maintains an annotated Appnote that lists a bunch of the extra fields that various vendors use here: http://www.info-zip.org/doc/ Strange then that the info-zip so often creates garbled filenames on Linux ! Probably the used zipper doesn't use the extra fields. Of course it doesn't use them. It has no unicode support. Since it is optional, we can probably add a WideString property to the zipitem and add an overloaded call; Then we don't need to recreate everything, Recreate everything? Don't get what you mean here. just add the extra fields. (Yes, IIRC, the zip64 fix added support for extra fields already so it shouldn't be a big change) Agreed when writing. When reading, I'd suggest following the suggested behaviour in the spec: 1. Try to read UTF8 filename from the EFS; if not present fall back to 2. Try to read extra fields filename as implemented by info-zip/abbrevia etc, if not present fall back to 3. current behaviour (reading filename as is) Perfect! :) -- Silvio Clécio My public projects - github.com/silvioprog ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [ANN] Brook 3.0.0 release!
[...] Added an issue: https://github.com/silvioprog/brookframework/issues/99 Thank a lot friends! -- Silvio Clécio My public projects - github.com/silvioprog ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Java crash when fpc library CallVoidMethod in a thread.
On 26.05.2014 21:47, fredvs wrote: Yep, Michael, thanks... Ok then for Nil owner... Hum, checksynchronize(), i do not realy understand how to use in the thread/loop... In the loop i do not use synchronize, because the procedure that is called is a java/method and synchronize is for procedure of object outside the thread... (Or i miss something ). CheckSynchronize is used to process calls to TThread.Synchronize and TThread.Queue. It *must* be called in the context of the main thread (the thread that loaded the library). TFPTimer uses Synchronize internally, because it uses a thread to keep track of the timing and notifies the main thread using Synchronize. Maybe one could add a non-synchronize mode, then oneself would need to make sure that eventual accesses inside the event handler are synchronized (CritialSections, etc.) correctly. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
