On Mon, Mar 25, 2019 at 10:37 AM Bart wrote:
> I'll have a go at it.
First draft at
http://wiki.lazarus.freepascal.org/FPC_New_Features_Trunk#Registry_unit
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On Mon, Mar 25, 2019 at 7:48 AM Sven Barth via fpc-devel
wrote:
>> Should the changes be documented at
>> http://wiki.lazarus.freepascal.org/FPC_New_Features_Trunk#Units ?
>
>
> Would be good, yes. Are you going to do it?
I'll have a go at it.
--
Bart
Bart schrieb am So., 24. März 2019, 23:49:
> On Sat, Mar 23, 2019 at 2:27 PM Bart wrote:
>
> > > I will look at it tomorrow. It has been a busy week.
>
> Thanks for applying.
> Thanks to all of you for your advice and patience.
>
> Should the changes be documented at
>
On Sat, Mar 23, 2019 at 2:27 PM Bart wrote:
> > I will look at it tomorrow. It has been a busy week.
Thanks for applying.
Thanks to all of you for your advice and patience.
Should the changes be documented at
http://wiki.lazarus.freepascal.org/FPC_New_Features_Trunk#Units ?
Bart
--
Bart
On Sat, Mar 23, 2019 at 12:02 AM Michael Van Canneyt
wrote:
> > Bump?
>
> I will look at it tomorrow. It has been a busy week.
Thank you, it got a bit silent here...
I'll await comments in the bugtracker then.
--
Bart
___
fpc-devel maillist -
On Fri, 22 Mar 2019, Bart wrote:
On Sun, Mar 17, 2019 at 1:16 PM Bart wrote:
I attached registry.unicode.part5.diff for review to
https://bugs.freepascal.org/view.php?id=35213 .
...
I would appreciate a review and feedback.
...
I propose to continu the discussion in the bugtracker
On Sun, Mar 17, 2019 at 1:16 PM Bart wrote:
> I attached registry.unicode.part5.diff for review to
> https://bugs.freepascal.org/view.php?id=35213 .
...
> I would appreciate a review and feedback.
...
> I propose to continu the discussion in the bugtracker then, unless
> there are fundamental
On Mon, Mar 18, 2019 at 8:08 AM Silvestre wrote:
Thanks for the info, now please back on topic.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
In the following link you can download official and legal windows virtual
machines for any test.
https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/
El dom., 17 mar. 2019 a las 20:03, Giuliano Colla (<
giuliano.co...@fastwebnet.it>) escribió:
> Il 14/03/2019 18:32, Bart ha scritto:
Il 14/03/2019 18:32, Bart ha scritto:
That is not really the issue.
My machine is Win10 on i5 with 8GB memory.
I run Mint in aVirtualBox VM (a bit sluggish, but do-able).
I don't have a Windows installable medium with license that I can
install into a VM.
And I'm not gonna buy it, nor am I gonna
On Sat, Mar 16, 2019 at 4:36 PM Michael Van Canneyt
wrote:
> > I can declare the type there as well, but for the compiler these will
> > be 2 different types.
>
> In Delphi yes, but normally not in FPC. If the base type is the same, 2
> array definitions will be assignment-compatible.
Thanks
On Sat, 16 Mar 2019, Bart wrote:
On Wed, Mar 13, 2019 at 6:51 PM Michael Van Canneyt
wrote:
What you could do is
TUniCodestringArray = Array of UniCodeString;
Function GetKeyNames : TUniCodestringArray;
Function GetValueNames : TUniCodestringArray;
The TStringList versions can call
On Wed, Mar 13, 2019 at 6:51 PM Michael Van Canneyt
wrote:
> What you could do is
>
> TUniCodestringArray = Array of UniCodeString;
>
> Function GetKeyNames : TUniCodestringArray;
> Function GetValueNames : TUniCodestringArray;
>
> The TStringList versions can call these and do the conversion.
On Fri, Mar 15, 2019 at 10:29 AM Michael Van Canneyt
wrote:
> No worries. We know you're working on it. When you finalize your patch,
> we'll test the other TRegistry related bugs as well when we apply it.
OK, fine!
--
Bart
___
fpc-devel maillist -
On Fri, 15 Mar 2019, Bart wrote:
On Mon, Feb 25, 2019 at 7:03 PM Bart wrote:
I'm currently involved in some TRegistry bugs and regressions.
As this turns out to be a massive patch, I would really appreciate if
for the time being no other patches were applied to the registry
(there are
On Mon, Feb 25, 2019 at 7:03 PM Bart wrote:
> I'm currently involved in some TRegistry bugs and regressions.
As this turns out to be a massive patch, I would really appreciate if
for the time being no other patches were applied to the registry
(there are several in the bugtracker), since they
On Fri, Mar 15, 2019 at 7:40 AM Sven Barth via fpc-devel
wrote:
> > Since this function did not exist in 3.0.4 I think this is acceptable?
> > Especially since the previous implementation was bugged as well.
> > (Released software should not be made with fpc trunk anyway IMO)
> Trunk is free to
Am 15.03.2019 um 00:04 schrieb Bart:
On Wed, Mar 13, 2019 at 6:43 PM Bart wrote:
That was the easy part.
Since all values written are now UnicodeString, WriteStringList in
XMLREG implementation now writes a sequence of UnicodeChar
representations to the registry. Previously it wrote
On Wed, Mar 13, 2019 at 6:43 PM Bart wrote:
> That was the easy part.
Since all values written are now UnicodeString, WriteStringList in
XMLREG implementation now writes a sequence of UnicodeChar
representations to the registry. Previously it wrote AnsiChar's.
Give a stringlist with values
On 14.3.2019 19.32, Bart wrote:
On Thu, Mar 14, 2019 at 8:22 AM Cyrax wrote:
If your computer have enough RAM and have support for hardware
virtualization (motherboard, its firmware and CPU) then I would
recommend that you set up a VM for testing. I would recommend to you to
use VirtualBox.
On Thu, Mar 14, 2019 at 7:50 PM Sven Barth via fpc-devel
wrote:
> Support for 64-bit values in the registry was only added a few weeks ago, so
> I'd say that was an oversight.
> If you implement it, then please as a separate patch, maybe also with a
> separate bug report.
OK
Bart schrieb am Do., 14. März 2019, 19:34:
> On Wed, Mar 13, 2019 at 6:43 PM Bart wrote:
>
> > That was the easy part.
>
> TXMLRegistry does not seem to support Int64.
> Any reason for that?
>
> If it's an oversight (support for that was only recently added for
> Windows) should I try and
On Wed, Mar 13, 2019 at 6:43 PM Bart wrote:
> That was the easy part.
TXMLRegistry does not seem to support Int64.
Any reason for that?
If it's an oversight (support for that was only recently added for
Windows) should I try and implement it as well in the unicode patch or
implement it later?
On Thu, Mar 14, 2019 at 8:22 AM Cyrax wrote:
> If your computer have enough RAM and have support for hardware
> virtualization (motherboard, its firmware and CPU) then I would
> recommend that you set up a VM for testing. I would recommend to you to
> use VirtualBox.
That is not really the
On 13.3.2019 16.56, Bart wrote:
On Wed, Mar 13, 2019 at 2:24 PM Michael Van Canneyt
wrote:
Done and done.
Thanks.
I will report back here if I have something I think is worth applying.
In the mean time ignore patches added to that bugreport.
I'll attach intermediate diff's there, just
On Wed, 13 Mar 2019, Bart wrote:
On Mon, Mar 11, 2019 at 4:03 PM Michael Van Canneyt
wrote:
From my perspective: the public API is all that matters.
There I would opt for overloads that accept unicodestring.
Done that.
That was the easy part.
Now:
procedure GetKeyNames(Strings:
On Mon, Mar 11, 2019 at 4:03 PM Michael Van Canneyt
wrote:
> From my perspective: the public API is all that matters.
> There I would opt for overloads that accept unicodestring.
Done that.
That was the easy part.
Now:
procedure GetKeyNames(Strings: TStrings);
procedure GetValueNames(Strings:
On Wed, Mar 13, 2019 at 2:24 PM Michael Van Canneyt
wrote:
> Done and done.
Thanks.
I will report back here if I have something I think is worth applying.
In the mean time ignore patches added to that bugreport.
I'll attach intermediate diff's there, just because it eases my work flow.
(And
On Wed, 13 Mar 2019, Bart wrote:
On Wed, Mar 13, 2019 at 1:58 PM Bart wrote:
Could you (or some other devel) change thus summary of
https://bugs.freepascal.org/view.php?id=35213 from "TRegistry should
not enforce UTF8 encoding on returned string variables." to something
like "Unicode aware
On Wed, Mar 13, 2019 at 1:58 PM Bart wrote:
> Could you (or some other devel) change thus summary of
> https://bugs.freepascal.org/view.php?id=35213 from "TRegistry should
> not enforce UTF8 encoding on returned string variables." to something
> like "Unicode aware TRegistry"?
>
> It'll be more
On Mon, Mar 11, 2019 at 8:17 PM Michael Van Canneyt
wrote:
> > I can work on that.
>
> Great, thank you.
Could you (or some other devel) change thus summary of
https://bugs.freepascal.org/view.php?id=35213 from "TRegistry should
not enforce UTF8 encoding on returned string variables." to
On Mon, Mar 11, 2019 at 8:17 PM Michael Van Canneyt
wrote:
> To keep things simple: A unit reginifile ?
In the future perhaps. Let's first do the Unicode stuff.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On Mon, 11 Mar 2019, Bart wrote:
On Mon, Mar 11, 2019 at 4:03 PM Michael Van Canneyt
wrote:
Probably because no-one in his right mind uses TRegIniFile ?
Mind you, the reason I looked into it was that on the forum somone
actually reported it not working as expected.
So clearly there are
On Mon, 11 Mar 2019, Bart wrote:
On Mon, Mar 11, 2019 at 4:03 PM Michael Van Canneyt
wrote:
Sorry to hear this.
That was certainly not my intention, on the contrary: I am glad to see that
someone takes the time to look at some of these bugs in earnest.
Thanks.
From my perspective: the
On Mon, Mar 11, 2019 at 4:03 PM Michael Van Canneyt
wrote:
> Probably because no-one in his right mind uses TRegIniFile ?
Mind you, the reason I looked into it was that on the forum somone
actually reported it not working as expected.
So clearly there are (left-minded?) people out there using
On Mon, Mar 11, 2019 at 4:03 PM Michael Van Canneyt
wrote:
> Sorry to hear this.
> That was certainly not my intention, on the contrary: I am glad to see that
> someone takes the time to look at some of these bugs in earnest.
Thanks.
> From my perspective: the public API is all that matters.
>
On Mon, 11 Mar 2019, Bart wrote:
On Mon, Mar 11, 2019 at 12:37 AM Michael Van Canneyt
wrote:
What's the problem ?
The problem is that you make me feel that evreything I do or think of is wrong.
Sorry to hear this.
That was certainly not my intention, on the contrary: I am glad to see
On Mon, Mar 11, 2019 at 12:37 AM Michael Van Canneyt
wrote:
> What's the problem ?
The problem is that you make me feel that evreything I do or think of is wrong.
Most likely this would not be the case if we were in the same room and
talked about it.
Another practical problem is that we (as in
On Sun, 10 Mar 2019, Bart wrote:
On Sun, Mar 10, 2019 at 5:56 PM Michael Van Canneyt
wrote:
I don't ever use the registry, so in that sense you are right it is indeed
not sexy enough to worry about it :-)
Neither do I use it...
Long time ago I wrote a patch for some other part of the
If I may add my two pence...
I'm all for speed and efficiency in library code, but conformance is more
important - if a correct input (even if somewhat extreme) results in a bad
output, then it's something that should be fixed. If you try to feed the
unit malformed input and it predictably
On Sun, Mar 10, 2019 at 5:56 PM Michael Van Canneyt
wrote:
> I don't ever use the registry, so in that sense you are right it is indeed
> not sexy enough to worry about it :-)
Neither do I use it...
Long time ago I wrote a patch for some other part of the RTL.
The old behaviour was plain wrong
On Sun, Mar 10, 2019 at 5:56 PM Michael Van Canneyt
wrote:
> It does not resolve a regression.
Yes, it does and I showed it here.
> The current behaviour is a bugfix for a reported bug.
And it did that the wrong way.
Calling Utf8Decode on a string without checking it is indeed Utf8
encoded is
On Sun, 10 Mar 2019, Bart wrote:
No.
Please, a single patch with full solution for unicode & ansistring.
You misundersdtand me here, I think.
The patch I mentioned does not concern the Unicode issue at hand.
The patch file however has a chunk of unaltered code in it, and in
_that_ code
> No.
>
> Please, a single patch with full solution for unicode & ansistring.
You misundersdtand me here, I think.
The patch I mentioned does not concern the Unicode issue at hand.
The patch file however has a chunk of unaltered code in it, and in
_that_ code there is one Utf8Encode.
If the
On Sun, 10 Mar 2019, Bart wrote:
On Sat, Mar 2, 2019 at 3:48 PM Joost van der Sluis wrote:
The utf8encode should go, just like the utf8decode's that we fixed already.
Regards,
Joost.
I posted a patch in https://bugs.freepascal.org/view.php?id=35213.
Again: please first aplply the patch
On Sat, Mar 2, 2019 at 3:48 PM Joost van der Sluis wrote:
> The utf8encode should go, just like the utf8decode's that we fixed already.
>
> Regards,
>
> Joost.
I posted a patch in https://bugs.freepascal.org/view.php?id=35213.
Again: please first aplply the patch from
On Thu, Mar 7, 2019 at 6:30 PM Yuriy Sydorov wrote:
> Of course if "u8" is utf8string, then then first char will be encoded as a
> 2-byte pair. But if you change "u8" to be
> just "string" or "ansistring", then the first byte would contain "ä" if the
> current ansi code page supports it (eg
On 07.03.2019 18:38, Bart wrote:
On Wed, Mar 6, 2019 at 10:09 PM Yuriy Sydorov wrote:
If you declare a function result as utf8string instead of string (ansistring)
then automatic conversion will be
performed when you assign the result of the function to a variable of type
string
On Wed, Mar 6, 2019 at 10:09 PM Yuriy Sydorov wrote:
> If you declare a function result as utf8string instead of string (ansistring)
> then automatic conversion will be
> performed when you assign the result of the function to a variable of type
> string (ansistring). You will gen a classic
>
On 06.03.2019 22:21, Bart wrote:
Using UTF8String in TRegistry instead of String forces users to
consider the fact that returned strings are Utf8Encoded now always,
even if they (probably most of them) do not need that because what
they retrieve from and put in the registry fits into their
On Wed, Mar 6, 2019 at 8:39 PM Michael Van Canneyt
wrote:
> Not sure I follow you ?
>
> If somewhere there is a warning about conversion of unicodestring to
> ansistring (often abused as single-byte string) then this must be looked at
> and somehow
> fixed.
>
> This can mean changing the
On Wed, 6 Mar 2019, Bart wrote:
On Wed, Mar 6, 2019 at 6:28 PM Michael Van Canneyt
wrote:
Ideally, they should all be fixed. They are all potential sources of error.
You can't have it both ways: use CP_ACP string and expect them to be
able to handle Unicode outside of their codepage,
On Wed, Mar 6, 2019 at 6:28 PM Michael Van Canneyt
wrote:
> Ideally, they should all be fixed. They are all potential sources of error.
You can't have it both ways: use CP_ACP string and expect them to be
able to handle Unicode outside of their codepage, unless your codepage
is UTF8.
--
Bart
On Wed, 6 Mar 2019, Bart wrote:
On Wed, Mar 6, 2019 at 4:10 PM Michael Van Canneyt
wrote:
So, what do you propose for maximum backwards compatibility ?
By this I mean, for people that basically use plain strings and ASCII, they
should not get warnings about
'conversion from widestring to
On Wed, Mar 6, 2019 at 4:10 PM Michael Van Canneyt
wrote:
> So, what do you propose for maximum backwards compatibility ?
>
> By this I mean, for people that basically use plain strings and ASCII, they
> should not get warnings about
> 'conversion from widestring to ansistring' and vice versa.
On Wed, 6 Mar 2019, Bart wrote:
On Wed, Mar 6, 2019 at 2:16 PM Michael Van Canneyt
wrote:
Please add overloading using UTF8String.
Backwards compatibility is not an idle word.
To be honest, that last sentence does not make sense to me.
Before trunk TRegistry used (on Windows) the A-API
On Wed, Mar 6, 2019 at 2:16 PM Michael Van Canneyt
wrote:
> Please add overloading using UTF8String.
> Backwards compatibility is not an idle word.
To be honest, that last sentence does not make sense to me.
Before trunk TRegistry used (on Windows) the A-API and string
parameters are just
On Wed, 6 Mar 2019, Bart wrote:
On Wed, Mar 6, 2019 at 12:59 PM Marco van de Voort
wrote:
1+2. Reverse manual enforced encoding, and honour the codepage in the
default string type.
(2 sort of implies 1 as well...)
If unicode MUST be supported on windows without lazarus hack, convert
On Wed, Mar 6, 2019 at 12:59 PM Marco van de Voort
wrote:
> 1+2. Reverse manual enforced encoding, and honour the codepage in the
> default string type.
(2 sort of implies 1 as well...)
> If unicode MUST be supported on windows without lazarus hack, convert
> the interface to unicodestring.
Op 3/6/2019 om 12:48 PM schreef Bart:
So, where to go now from here?
1. Leave all method signatures unchanged (use plain string variables)
and cut out all the Utf8Encode(). Then wait for the time that
string=unicodestring?
2. Cut out Utf8Encode(), overload all methods with ansistring
On Mon, Mar 4, 2019 at 12:16 PM Marco van de Voort
wrote:
> There is no need to further change interfaces to provide yet another
> option which does yet another option which is useful for only a limited
> time.
So, where to go now from here?
1. Leave all method signatures unchanged (use plain
Op 3/3/2019 om 11:17 AM schreef Yuriy Sydorov:
On 02.03.2019 18:53, Bart wrote:
On Sat, Mar 2, 2019 at 3:48 PM Joost van der Sluis
wrote:
The utf8encode should go, just like the utf8decode's that we fixed
already.
Shall I post a patch in the bugtracker?
If so: instead of
SomeAnsiString
On 03.03.2019 17:45, Bart wrote:
On Sun, Mar 3, 2019 at 11:17 AM Yuriy Sydorov wrote:
This is good if you assign the result of ReadString() to a regular ansistring
var. But if you assign it to a
utf8string,unicodestring,widestring var - it will not return correct result for
chars that are
On Sun, Mar 3, 2019 at 11:17 AM Yuriy Sydorov wrote:
> This is good if you assign the result of ReadString() to a regular ansistring
> var. But if you assign it to a
> utf8string,unicodestring,widestring var - it will not return correct result
> for chars that are missing in the current
>
On 02.03.2019 18:53, Bart wrote:
On Sat, Mar 2, 2019 at 3:48 PM Joost van der Sluis wrote:
The utf8encode should go, just like the utf8decode's that we fixed already.
Shall I post a patch in the bugtracker?
If so: instead of
SomeAnsiString := UTf8Encode(SomeUnicodeString) do I make it an
On Sat, Mar 2, 2019 at 5:53 PM Bart wrote:
> As a side note: I now have several patches for the registry in the
> bugtracker, and it gets increasingly difficult to make new patches for
> each issue if the "previous" (as in: the ones I made earlier) don't
> get applied.
Applying the patch for
On Sat, Mar 2, 2019 at 3:48 PM Joost van der Sluis wrote:
> The utf8encode should go, just like the utf8decode's that we fixed already.
Shall I post a patch in the bugtracker?
If so: instead of
SomeAnsiString := UTf8Encode(SomeUnicodeString) do I make it an
implicit conversion (SomeAnsiString
Op 01-03-19 om 22:19 schreef Bart:
On Tue, Feb 26, 2019 at 10:49 AM Marco van de Voort
wrote:
If I look into e.g. registry.pp, the only use of utf8encode there is
like this:
var s : string;
u:unicodestring;
s:=utf8encode(u);
which, IF lazarus is used in the default utf8 mode is
On Tue, Feb 26, 2019 at 10:49 AM Marco van de Voort
wrote:
> If I look into e.g. registry.pp, the only use of utf8encode there is
> like this:
>
> var s : string;
>
> u:unicodestring;
>
> s:=utf8encode(u);
>
> which, IF lazarus is used in the default utf8 mode is equivalent to
>
>
>
Am 26.02.2019 um 19:12 schrieb Bart:
> This leaves my initial "itch": input strings are CP_ACP (so can be
> anything), output strings are CP_UTF8 always.
Unless your DefaultSystemCodePage is CP_UTF8 (in which case UTF8Encode is not
needed), the next action on the string will convert away from UTF8
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.
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
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 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, 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 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
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
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, 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.
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 Mon, 25 Feb 2019, Bart wrote:
Hi,
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 and thoughts.
Hi,
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 and thoughts.
TRegistry on Windows now (3.2+) uses
82 matches
Mail list logo
