On Tue, 26 Feb 2019, Marco van de Voort wrote:
Op 2/25/2019 om 9:27 PM schreef Michael Van Canneyt:
I'm currently involved in some TRegistry bugs and regressions.
Personally I don't use TRegistry in any of my programs.
Also I mostly use Lazarus, so most most of the issues don't affect me.
Gareth, I like very much what you do about compiler optimizations.
From my point of view, execution speed is the most valuable, but of course 17%
of compilation speed increase is worth it!
If you want to have a big test case, and potentially find regressions, you may
try the TestSQL3 project
On 25.02.2019 20:03, Bart wrote:
On Lazarus, this no problem, since by default all strings are UTF8
encoded, so all conversions are lossless.
In a plain fpc program though on Windows, default encoding is the
current codepage (cp1252 in my case) and information will get lost
when you process the
On Tue, 26 Feb 2019, Yuriy Sydorov wrote:
On 25.02.2019 20:03, Bart wrote:
On Lazarus, this no problem, since by default all strings are UTF8
encoded, so all conversions are lossless.
In a plain fpc program though on Windows, default encoding is the
current codepage (cp1252 in my case) and
Op 2/26/2019 om 11:04 AM schreef Michael Van Canneyt:
If I understood the OP correct, he wants to change the use of "string"
arguments in the public API to unicodestring.
That changes a lot.
Contrary to popular belief, the conversion will not automatically be
correct, and will produce
Speaking of the optimiser overhaul, what are timings like for others?
Gareth aka. Kit
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Op 2/25/2019 om 9:27 PM schreef Michael Van Canneyt:
I'm currently involved in some TRegistry bugs and regressions.
Personally I don't use TRegistry in any of my programs.
Also I mostly use Lazarus, so most most of the issues don't affect me.
However I would like to share som observations
On Tue, 26 Feb 2019, Marco van de Voort wrote:
Op 2019-02-26 om 19:27 schreef Mattias Gaertner via fpc-devel:
Perhaps it would be better to change TXmlRegistry to Unicodetring?
I think that would be best, yes.
That was what I meant with 'switch the internals to unicodestring'
Michael.
On Tue, Feb 26, 2019 at 2:12 PM Michael Van Canneyt
wrote:
> But inner workings can be made to use Unicode, because the underlying APIs
> are using unicode: The *W registry calls on windows, XML DOM on other systems.
Well, my argument is that since we interface explicitely with a
UnicodeString
On Tue, 26 Feb 2019 19:14:41 +0100
Bart wrote:
> On Tue, Feb 26, 2019 at 2:12 PM Michael Van Canneyt
> wrote:
>
> > But inner workings can be made to use Unicode, because the
> > underlying APIs are using unicode: The *W registry calls on
> > windows, XML DOM on other systems.
>
> Well, my
On Tue, Feb 26, 2019 at 11:04 AM Michael Van Canneyt
wrote:
> If I understood the OP correct, he wants to change the use of "string"
> arguments in the public API to unicodestring.
>
> That changes a lot.
And that's why I asked here first.
> (See e.g.
Op 2019-02-26 om 19:27 schreef Mattias Gaertner via fpc-devel:
Perhaps it would be better to change TXmlRegistry to Unicodetring?
I think that would be best, yes.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Thanks George,
I've finished and debugged my optimizer overhaul, although performance
varies. It is predominantly faster than the existing peephole optimizer,
but not always as fast as I'd like (no more than a few seconds). I figure
I might have introduced one or two bottlenecks during my
13 matches
Mail list logo
