Re: [fpc-devel] Function for translation "normalized" Unicode strings into strings with composed characters?

The canonic decomposition (NFD) can be performed with UnicodeData.NormalizeNFD function in FPC, but I don't think there is an implementation of canonical composition (NFC) in FPC. It would be great to have one! On Windows, you can perform both NFD and NFC via NormalizeString API function.

[fpc-devel] Peculiar string comparison behaviour ("0-0" and "-00" are same)

Hello, I have encountered a peculiar behaviour in FPC string comparison functions (UnicodeSameStr, UnicodeTextStr, UnicodeCompareStr, and Wide* variants). Basically, on some systems "0-0" and "-00" strings are considered to be same. FPC string comparison functions use the WideStringManager,

Re: [fpc-devel] Moving to gitlab.

Regarding the old bug tracker. Can you please keep it online, perhaps making it accessible in read-only mode? There are many references to issues in the old bug tracker across many code bases and discussions, at it would be a real shame to loose that link so abruptly. If keeping the old

[fpc-devel] Get system ANSI code page

Hi, I was looking for a cross-platform method for retrieving system ANSI code page. I have identified two methods, using direct API calls (1) and indirect using the WideStringManager (2). FPC's SetPascalWideStringManager() routine provided a good reference. Any ideas about which is best?

Re: [fpc-devel] Porting from Delphi to FPC - challenge #2.

PChar is a typed pointer, so you need to point it to the memory location of TmpBugStr using the "@" operator, like so: const    TempString : PChar = @TmpBugStr; On 01/10/2018 13:18, Ozz Nixon wrote: Type Line:Array[0..127] of Char; Var TmpBugStr:Line; {later in the code} Const   

Re: [fpc-devel] Fix CamelCase in unit and method names

Please do... It has caused enough eye (OCD) stress over the years ;) Denis On 22/03/2018 11:32, Ondrej Pokorny wrote: Hello, will a patch be applied that fixes CamelCase in unit and method names and other identifiers? Example: dateutils -> DateUtils sysutils -> SysUtils typinfo ->

Re: [fpc-devel] End of support for Win XP?

On 06/02/2018 07:54, Michael Van Canneyt wrote: I would have preferred that you always use the new function when available, but since you'd then be doing what Microsoft is already doing, so I won't make a point out of it. I will apply and test the patch, thank you. That was my original plan,

Re: [fpc-devel] End of support for Win XP?

not be affected, except for an improved forward compatibility when the deprecated SHGetFolderPath is finally removed from Windows API, in which case a newer API function will be used automatically. Denis On 01/02/2018 13:31, Sven Barth via fpc-devel wrote: Am 01.02.2018 14:08 schrieb "

Re: [fpc-devel] End of support for Win XP?

It still feels *very early* to drop support for Windows XP. I haven't used it properly in years, but I can't say the same about the target user audience. I still test some builds against Windows XP. It would be a shame to drop support for Windows XP over SHGetKnownFolderPath(), when

Re: [fpc-devel] Static class methods can or cannot be virtual?

On 22/01/2018 17:09, Maciej Izak wrote: This was bug, fixed in trunk (see my rev. 35724) Thank you for pointing that out. I presume then there is no way for having a class property who's returned value can be dynamically changed in child classes? In other words, class property

[fpc-devel] Static class methods can or cannot be virtual?

Hello, Can static class methods be virtual? According to the FPC documentation, static class methods cannot be virtual, as stated here: https://www.freepascal.org/docs-html/ref/refsu30.html But in practice, FPC compiles and executes virtual and overridden static class methods just fine.

Re: [fpc-devel] Last call for 3.0.4 merges

Can you merge r35878 as well please? It is a small fix for TAssert.AssertEquals with strings. Thanks, Denis On 17/06/2017 20:31, Marco van de Voort wrote: While I have not done much the last month, I did keep up with most of the merging so most requests have been honoured, and I plan to

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

On 07/06/2017 15:18, Juha Manninen wrote: The compiler trusts that data in an enum variable is legal, within the range. It should trust the same way when doing DFA. It is logical and consistent. I understand your reasons now and agree that DFA should cover only logical (according to the

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

--- On 05/06/2017 22:11, Juha Manninen wrote: On Mon, Jun 5, 2017 at 9:37 PM, Denis Kozlov <dez...@gmail.com> wrote: I just wanted to highlight that these cases as legal and I presume not uncommon, particularly if values are deserialized and typecasted. No they are no

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

I just wanted to highlight that these cases as legal and I presume not uncommon, particularly if values are deserialized and typecasted. It seems that there is no way for compiler to know if the result has indeed being initialized by reason of enumeration of valid values, because one has

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

or Lazarus 1.6.4 + FPC 3.0.2 and Lazarus 1.4.4 + FPC 2.6.4. Denis On 05/06/2017 17:51, Jonas Maebe wrote: On 05/06/17 18:46, Denis Kozlov wrote: Result is undefined if caller passes an out of range value. That would be an error at the time this out-of-range value would be converted to T

Re: [fpc-devel] Data flow analysis (dfa) and "case ... of"

Result is undefined if caller passes an out of range value. An example: TControlBorderSpacing.GetSpace(TAnchorKind(-1)); Result is indeed not initialized, so silencing this message may be harmful. Denis On 05/06/2017 15:22, Juha Manninen wrote: Wiki tells about problems the dfa encounters:

Re: [fpc-devel] Math expressions in wiki

On 18/04/2017 22:32, Werner Pamler wrote: v52.0.2 (Win10-64bit, Firefix is 32-bit). Any extensions needed? Works fine here with Firefox v52.0.2 on Windows 7. No extensions needed, it just needs javascript. Try clearing your cache. Denis ___

Re: [fpc-devel] Math expressions in wiki

On 15/04/2017 20:43, Vincent Snijders wrote: What math rendering extension do you recommend? I recommend *SimpleMathJax* extension for its simplicity. It uses an external resource (mathjax.org) and doesn't require a local rendering engine.

Re: [fpc-devel] Math expressions in wiki

On 15/04/2017 20:06, Werner Pamler wrote: Thanks. Application of #2 is a bit complicated, but the results are very nice - see http://wiki.lazarus.freepascal.org/NumLib_Documentation#Gamma_function. Which resolution would you recommend? Your current resolution appears good on a desktop. On a

Re: [fpc-devel] Math expressions in wiki

On 14/04/2017 11:25, Werner Pamler wrote: Does anybody know how to write mathematical expressions in the wiki? I would like to write an article on fpc's NumLib, but I would only want to begin this activity when I know how to enter complex mathematical formulas like integrals etc such that they

Re: [fpc-devel] NowUTC in FPC

On 01/08/2016 07:59, Michael Van Canneyt wrote: But that would create duplicated code of LocalTimeToUniversal, UnixToDateTime, IncMilliSecond functions in SysUtils and DateUtils. So what ? It is essentially A+B*C or some variant of that. I try to avoid code duplication, which unnecessarily

Re: [fpc-devel] NowUTC in FPC

On 30/07/2016 17:45, Michael Van Canneyt wrote: I don't see why you cannot perform simple additions in sysutils. But that would create duplicated code of LocalTimeToUniversal, UnixToDateTime, IncMilliSecond functions in SysUtils and DateUtils. As far as I can see, these perform almost the

Re: [fpc-devel] NowUTC in FPC

On 30/07/2016 11:10, Michael Van Canneyt wrote: I had a look at it. Please modify the patch first, see comments in bugreport. The reason why I put UniversalTime (a.k.a. NowUTC) function in DateUtils is because of the dependency on LocalTimeToUniversal, UnixToDateTime, IncMilliSecond

Re: [fpc-devel] NowUTC in FPC

Can somebody take a look and apply the patch please? Thanks On 21/07/2016 09:37, Denis Kozlov wrote: I've uploaded a patch to mantis: http://bugs.freepascal.org/view.php?id=30394 Denis ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] NowUTC in FPC

On 21/07/2016 10:04, Ondrej Pokorny wrote: Why does your client ignore mailing list threads? (Or why does my Thunderbird email client ignore threads on messages sent from you?) It's replying through Gmail web interface seems to screw it up. Can't use it for mailing lists then. Bummer. P.S.

Re: [fpc-devel] NowUTC in FPC

On 21 July 2016 at 10:04, Ondrej Pokorny wrote: > > Why does your client ignore mailing list threads? (Or why does my > Thunderbird email client ignore threads on messages sent from you?) > I use latest Thunderbird too and Gmail web interface sometimes, but haven't seen this

Re: [fpc-devel] NowUTC in FPC

I've uploaded a patch to mantis: http://bugs.freepascal.org/view.php?id=30394 Denis ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] NowUTC in FPC

On 20 July 2016 at 15:52, Denis Kozlov <dez...@gmail.com> wrote: > > So, below is a tidy cross-platform implementation of NowUTC: > Oops, forgot the milliseconds, here it is: function NowUTC: TDateTime; {$ifdef WINDOWS} var SystemTime: TSystemTime; begin Windows.GetSystem

Re: [fpc-devel] NowUTC in FPC

On 20 July 2016 at 10:08, Denis Kozlov <dez...@gmail.com> wrote: > Is it possible to move NowUTC from LazUTF8SysUtils.NowUTC to FPC, e.g. > DateUtils? > > LocalTimeToUniversal(Now) is inefficient and suffers from a race > condition, but can still be used as a fallback impleme

Re: [fpc-devel] NowUTC in FPC

On 20 July 2016 at 15:33, Henry Vermaak <henry.verm...@gmail.com> wrote: > On Wed, Jul 20, 2016 at 03:26:56PM +0100, Denis Kozlov wrote: > > Don't mind another poorly chosen name "EpochToLocal", which in reality is > > more like "UnixToDateTime". >

Re: [fpc-devel] NowUTC in FPC

On 20 July 2016 at 14:47, Marco van de Voort <mar...@stack.nl> wrote: > In our previous episode, Denis Kozlov said: > > I'm not sure why you say there is no guarantee, because in example of > > Windows implementation GetSystemTime API is explicitly expressed in UTC > &g

Re: [fpc-devel] NowUTC in FPC

On 20 July 2016 at 13:31, Marco van de Voort <mar...@stack.nl> wrote: > In our previous episode, Denis Kozlov said: > > Is it possible to move NowUTC from LazUTF8SysUtils.NowUTC to FPC, e.g. > > DateUtils? > > > > LocalTimeToUniversal(Now) is inefficient an

[fpc-devel] NowUTC in FPC

Hello, Is it possible to move NowUTC from LazUTF8SysUtils.NowUTC to FPC, e.g. DateUtils? LocalTimeToUniversal(Now) is inefficient and suffers from a race condition, but can still be used as a fallback implementation. Denis ___ fpc-devel maillist -

Re: [fpc-devel] FPC V3.0.0 LocalTimeToUniversal() error

On 28/06/2016 04:55, Russ Davies wrote: Hi, My local time zone is GMT +2, and have noticed that with V3.0.0, that the LocalTimeToUniversal() function is adding the offset instead of subtracting it: FPC 3.0.0 produces incorrect results. FPC 3.0.1 r34023 and FPC 3.1.1 r34024 produce correct

Re: [fpc-devel] Mdelpih vs Mdelphi?

On 3 June 2016 at 14:32, Marco van de Voort wrote: > > Looks like a typo in the docs: > > http://www.freepascal.org/docs-html/prog/progse74.html#x290-305000D.3 > > Fixed in svn. > *-Mdelpi* ? A very persistent typo ;) ___ fpc-devel

[fpc-devel] Mdelpih vs Mdelphi?

Looks like a typo in the docs: http://www.freepascal.org/docs-html/prog/progse74.html#x290-305000D.3 On the command line, this mode is selected by the *-Mdelpih* switch. P.S. It has propagated to at least 44 other pages on the internet ;) Denis ___

Re: [fpc-devel] SysUtils.GetEnvironmentVariable(String) still uses GetEnvironmentVariableA

On 23 May 2016 at 15:23, Jonas Maebe wrote: > > Michael Van Canneyt wrote on Mon, 23 May 2016: > > The typecase will not help you, since the result is an ansistring. >> The result will still be crippled. >> > > It would help when DefaultSystemCodePage is changed to

Re: [fpc-devel] SysUtils.GetEnvironmentVariable(String) still uses GetEnvironmentVariableA

P.S. A minor typo, GetEnvironmentVariableA should read GetEnvironmentStringsA. On 23 May 2016 at 13:31, Denis Kozlov <dez...@gmail.com> wrote: > Hi, > > In FPC 3.0.0 and TRUNK for Windows: > > SysUtils.GetEnvironmentVariable(String) uses Ge

[fpc-devel] SysUtils.GetEnvironmentVariable(String) still uses GetEnvironmentVariableA

Hi, In FPC 3.0.0 and TRUNK for Windows: > SysUtils.GetEnvironmentVariable(String) uses GetEnvironmentVariableA > SysUtils.GetEnvironmentVariable(UnicodeString) uses GetEnvironmentStringsW GetEnvironmentVariableA produces a result crippled by ANSI/OEM. Can it be replaced with a simple typecast of

[fpc-devel] PDB debug format made public

/This might be of interest or used for future reference./ Microsoft has made an effort to open up and document it's proprietary PDB debugging file format, a.k.a program database (.pdb) file, primarily used by Visual Studio Debugger and WinDbg. Apparently, the aim is to open it for use in

Re: [fpc-devel] Questions on TStringList.Find change (Mantis 28744)

On 22/03/2016 17:56, Michael Van Canneyt wrote: or better something concise like ltAuto,ltUser,ltNone. It may make more sense to call it ListSortType (as opposed to ListType): TListSortType = (lstNone, lstAuto, lstManual); Something like this could work (prototype code):

Re: [fpc-devel] Questions on TStringList.Find change (Mantis 28744)

On 22 March 2016 at 14:43, Michael Van Canneyt wrote: > > On 3/22/16 2:01 AM, Michael Van Canneyt wrote: >> >>> >>> There are now several options: >>> 1. I change the code to raise an exception instead (as was my original >>> plan) >>> 2. I change the code to resort to a linear search if sorted

Re: [fpc-devel] Questions on TStringList.Find change (Mantis 28744)

Find method must find an item in the list. Whether the list is sorted or not, whether the binary search optimization can be applied or not - are implementation details. Find method should either: 1) Raise exception if list is not sorted, 2) Use IndexOf method if the list is not sorted

Re: [fpc-devel] InstantFPC in FPC distribution?

Filed a bug report: http://bugs.freepascal.org/view.php?id=29750 On 28/02/2016 08:37, Michael Van Canneyt wrote: On Sat, 27 Feb 2016, Denis Kozlov wrote: Why is InstantFPC not included in FPC distribution? An oversight. Please file a bugreport. Michael

[fpc-devel] InstantFPC in FPC distribution?

Why is InstantFPC not included in FPC distribution? For example: * fpc-3.0.0.i386-win32.exe - no InstantFPC. * lazarus-1.6.0-fpc-3.0.0-win32.exe - contains InstantFPC. Denis ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] Add {$I %DATETIME%}

On 27/02/2016 12:08, Jonas Maebe wrote: If something is platform-specific, it generally does not belong as a language extension. It's the same as existing %DATE% and %TIME%, plus few mathematical operations, no extra dependencies. // Existing function used for %DATE% in globals.pas:

Re: [fpc-devel] Add {$I %DATETIME%}

What if we define %TIMESTAMP% or %UNIXTIMESTAMP%, instead of %DATETIME%? * %UNIXTIMESTAMP% - as a well defined Unix timestamp (i.e. number of seconds since Unix Epoch). * %TIMESTAMP% - as an Int64 version of TTimeStamp (i.e. number of MSecs since 1/1/0001). These could be inserted as

[fpc-devel] TSimpleIPC is broken as a component in FPC 3.0.0

TSimpleIPC.Loaded overrides TComponent.Loaded, but never calls the inherited method to exclude csLoading from ComponentState. This breaks TSimpleIPC as a component, i.e. it never gets activated when used in Lazarus IDE. It may also need to check for csDesigning and never activate itself at

Re: [fpc-devel] Add {$I %DATETIME%}

On 23 February 2016 at 15:24, <wkitt...@windstream.net> wrote: > is there something wrong with what is already available?? Yes, as highlighted in my original post. On 15 January 2016 at 21:23, Denis Kozlov wrote: > Benefits of this directive: > 1) Access to build date/time in n

Re: [fpc-devel] Add {$I %DATETIME%}

On 23 February 2016 at 11:57, Michael Van Canneyt wrote: > 1. The TDateTime format is not a basic format of the language. >It is an agreement on how to encode date/time information in a double. > If I understand this point correctly, you are concerned about "FloatToStr(Now)" statement, where

Re: [fpc-devel] Add {$I %DATETIME%}

Can someone apply the patch for adding %DATETIME%, if there are no objections? Denis On 15 January 2016 at 21:23, Denis Kozlov wrote: > I'm proposing addition of {$I %DATETIME%} directive. A trivial patch is > attached. > > The following will be possible: > const >

Re: [fpc-devel] Inconsistent use of Timeout in SimpleIPC

On 22/01/2016 22:33, Denis Kozlov wrote: so the next patch will be use this common "simpleipc.inc" on all Windows platforms (AllWindowsOSes). Patch attached here: http://bugs.freepascal.org/view.php?id=29496 Summary of changes: 1) Moved "src/win/simpleipc.inc" to "sr

Re: [fpc-devel] Inconsistent use of Timeout in SimpleIPC

On 16/01/2016 21:43, Denis Kozlov wrote: In regards to merging "wince" and "win" implementations of SimpleIPC. The only real difference is the use of Wide vs Ansi types and functions of WinAPI. Currently, "win32" and "win64" platforms use A versions,

Re: [fpc-devel] Inconsistent use of Timeout in SimpleIPC

Since FPC trunk no longer supports Win9x platforms, is it safe to use W variants across all windows platforms for SimpleIPC? Denis On 05/01/2016 07:57, Denis Kozlov wrote: Proposed next steps: 1) If everyone is happy - commit changes (should I create a bug report in mantis?). 2) I

[fpc-devel] Add {$I %DATETIME%}

Hello, I'm proposing addition of {$I %DATETIME%} directive. A trivial patch is attached. The following will be possible: const T = {$I %DATETIME%}; begin WriteLn(DateTimeToStr(T)); end. Benefits of this directive: 1) Access to build date/time in native TDateTime format. Existing {$I

Re: [fpc-devel] Fixing line info units (stabs, dwarf)

Uploaded updated patch files to mantis. Also attached here for the reference. On 9 January 2016 at 15:52, Denis Kozlov <dez...@gmail.com> wrote: > On 9 January 2016 at 15:34, Denis Kozlov wrote: > >> I uploaded patches for line info units: >> http://bugs.freepascal.org/

Re: [fpc-devel] Fixing line info units (stabs, dwarf)

I uploaded patches for line info units: http://bugs.freepascal.org/view.php?id=28283#c88738 http://bugs.freepascal.org/view.php?id=28288#c88737 Reuse of line info data is now optional and controlled via global AllowReuseOfLineInfoData variable. Default value is TRUE. Denis

Re: [fpc-devel] Fixing line info units (stabs, dwarf)

Patches are ready for both DWARF and STABS. There is now a global variable "AllowReuseLineInfoData" in each unit. Should it default to TRUE or FALSE? Description of the variable, as in code comments: // Allows more efficient operation by reusing previously loaded debug data // when the target

Re: [fpc-devel] Fixing line info units (stabs, dwarf)

On 4 January 2016 at 11:52, Michael Van Canneyt wrote: > Maybe it is possible to make it configurable ? > Yes, should be doable. I'll look into it. Denis ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] Inconsistent use of Timeout in SimpleIPC

On 5 January 2016 at 12:39, Michael Van Canneyt wrote: > I was in fact waiting for this part, rather than applying the patch as it > is. > But if you prefer we can do it in steps ? > I prefer to do this in steps, easier to control changes. Bug report with same patch files:

Re: [fpc-devel] Inconsistent use of Timeout in SimpleIPC

are identical except for wide types/winapi, but won't be able to test on Windows CE. 3) Investigate if implementations on other platforms can benefit from message queue and overflow handling. Denis On 10 December 2015 at 21:02, Denis Kozlov <dez...@gmail.com> wrote: > I have rewri

[fpc-devel] Fixing line info units (stabs, dwarf)

Hello, I want to fix couple of issues with line info units, STABS (lineinfo.pp) and DWARF (lnfodwrf.pp): 1) Back trace is permanently disabled once a module without line info is encountered. This has already been fixed in STABS (r31026, r31025), similar changes can be applied to DWARF.

Re: [fpc-devel] Inconsistent use of Timeout in SimpleIPC

I have rewritten SimpleIPC implementation for Windows. Summary of changes: 1. Using SetTimer + GetMessage method for handling PeekMessage. 2. Store all received incoming messages in a message queue (per IPC server instance). 3. Implemented message queue (PeekMessage receives messages, ReadMessage

Re: [fpc-devel] Inconsistent use of Timeout in SimpleIPC

On 6 December 2015 at 08:29, Ondrej Pokorny wrote: > If you don't persist in using SimpleIPC, there is also AdvancedIPC that uses > the same approach (temporary files) across all targets and so it behaves > consistently. I think SimpleIPC and AdvancedIPC complement each other.

Re: [fpc-devel] Inconsistent use of Timeout in SimpleIPC

I got the Plan B working (SetTimer+GetMessage) for SimpleIPC. However, it is not possible at all to get TSimpleIPCServer.PeekMessage to NOT read the message, i.e. to respect DoReadMessage=False parameter. Every message queue accessing function in Windows (e.g. PeekMessage, GetMessage)

Re: [fpc-devel] Inconsistent use of Timeout in SimpleIPC

There is another problem with SimpleIPC on Windows. This same problem was experienced in @Juha's post "SimpleIPC and TWinMsgServerComm.PeekMessage": http://lists.freepascal.org/pipermail/fpc-devel/2013-October/032871.html TWinMsgServerComm.PeekMessage never waits for a Timeout because of this

[fpc-devel] Inconsistent use of Timeout in SimpleIPC

ropose the following consistent use of Timeout parameter: * >0 -- number of milliseconds to wait. * 0 -- return immediately. * -1 -- wait infinitely. * <-1 -- wait infinitely (force to -1). I can produce a patch and a test project, if there are no objections. Regards,