Re: [fpc-devel] TRegistry fixes

[Michael Van Canneyt]

On Tue, 12 Feb 2019, Pierre Muller wrote:


 Hi Bart,

Le 11/02/2019 à 15:29, Bart a écrit :

Hi,



 I am one of the rare regular users of Windows OS in the core team,
but I must also confess that I am neither knowledgeable in TRegistry fields,
nor in all what concerns UniCode matters, which is still the main point
of those modifications...

 If nobody else steps up, I will try to look into it,
but I hope someone else from core team will be able to check and commit
those changes...


As far as I know, Marco is working mainly on Windows these days.

But I am familiar with the TRegistry implementation.
If Marco has no time, I can look at it myself during the weekend.
I will need to boot a Windows VM and update FPC on that. I just need to
remember on which one I have an FPC checked out :)

Michael.___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] TRegistry fixes

[Pierre Muller]

  Hi Bart,

Le 11/02/2019 à 15:29, Bart a écrit :
> Hi,
> 
> The new (W-API based) TRegistry in trunk and 3.2 fixes has some
> problems on Windows, amongst which at least one regression.
> 
> https://bugs.freepascal.org/view.php?id=35060
> The use of Utf8Decode on strings that are not guaranteed to be CP_UTF8 is 
> wrong.
> As a result Keys with unicode characters in their name cannot be read
> anymore (nor written to).
> (This is a regression)
> 
> https://bugs.freepascal.org/view.php?id=34876
> The implementation of ReadStringList/WriteStringList treats a sequence
> of Unicode chars (WideChar) as if they were AnsiChar (a.o.).
> 
> https://bugs.freepascal.org/view.php?id=35022
> TRegIniFile writes data to the wrong Key.
> 
> All these issues have patches and sample programs attached.
> 
> The patch for https://bugs.freepascal.org/view.php?id=35022 also
> resolves https://bugs.freepascal.org/view.php?id=35023 and
> https://bugs.freepascal.org/view.php?id=33980
> 
> Attached to https://bugs.freepascal.org/view.php?id=35022  is also a
> test, intended to be added to tests/test/packages/fcl-registry.
> (Currently the only test there is a trivial one.)
> 
> I can try to write tests for the other issues as well, but verifying
> in code that WriteStringList yields the correct result may be a little
> tricky, because it would depend on ReadStringList.
> The patch for that issue will write a StringList and read that back
> again and regedit does not complain that data is wrong.
> 
> It would be very nice if some devel who actually uses Windows (and has
> at least rudimentary knowledge of the use of TRegistry) can have a
> look at it and give some feedback.
> Especially since these bugs will be in the upcoming 3.2.0 if they are
> not fixed (and merged).
> 


  I am one of the rare regular users of Windows OS in the core team,
but I must also confess that I am neither knowledgeable in TRegistry fields,
nor in all what concerns UniCode matters, which is still the main point
of those modifications...

  If nobody else steps up, I will try to look into it,
but I hope someone else from core team will be able to check and commit
those changes...


Pierre
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] [Suggestion] Disable "inline" on -O1 and -O-.

[J. Gareth Moreton]

 I would like to make a suggestion that when compiling on a debug build,
which is usually -O1 and below, that procedures marked as "inline" are not
inlined and instead treated as regular subroutines.  The reason why I
suggest this is that "inline" makes it very difficult to debug the actual
procedure, since you can't step into it or put breakpoints on lines inside
said routine.  More often than not, I find myself commenting out the
"inline" directive when I need to debug it, which is a little silly and is
asking to accidentally leave it commented out.

 I realise that the -O flags are for optimisation and "inline" is more of a
feature, but considering -O2 and -O3 are usually only selected when
compiling a release build, it's a little more convenient than having a
separate flag or option buried in a configuration dialog or the command
line.

 Gareth aka. Kit
 ___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Fppkg

[Joost van der Sluis]

Op 05-02-19 om 21:55 schreef Ben Grasset:
On Mon, Feb 4, 2019 at 9:53 AM Martok > wrote:


the first-ever fppkg.exe invocation on a machine


Do people actually use fppkg for anything? More specifically what is the 
point of integrating it with Lazarus, which already has the OPM?


Good question.

And I have two answers for you:

First: Fppkg has been integrated with Lazarus for over 10 years. It is 
part of FPC from since the nineties. It has never been used really, 
though. It had potential at the start, but it was too hard to get it 
working properly all the time. It was difficult to get it to compile 
Lazarus properly, due to all the strange exceptions in it's 
build-system. Mattias decided not to wait but to build Lazbuild. Making 
fppkg obsolete in some part. The same happened with OPM. Fppkg never 
gained popularity, and nowadays all Lazarus packages are distributed 
through OPM. So it's questionable what the reason of existing of Fppkg 
is at this moment.


Second: Lazbuild and OPM do only a part of what Fppkg/Fpmake are capable 
of. Remember that the FPC-universe does not only consists of Lazarus. 
For Fppkg/Fpmake, Lazarus is just one of the projects. And it is 
possible to compile (bootstrap) Lazarus using Fppkg, so it replaces 
'Make'. Lazbuild can not do this. (In principle it is possible to 
install Lazarus using 'fppkg install lazarus')
I often see discussions about a certain unit, if it should be part of 
Freepascal or Lazarus. Adding it to Fppkg is the solution. We can also 
use Fppkg to solve problems with bugs in Freepascal's packages between 
two fpc releases.
And about the online packages-part of Fppkg, in contradiction to OPM 
Fppkg has different repositories for different version of FPC. And it 
actually checks for packages if they compile before they can be 
submitted. Also when a package changes, all packages that depend on the 
changed package are recompiled (on several targets) to check if the 
compilation breaks. If this is the case, an update will be refused. 
(Well an administrator can override this, but let's keep it simple)
On moving compiler targets (fpc-trunk) the packages are checked for 
regularly.


So I still think it's worthwhile to work on Fppkg. And I'm really 
pleased with all the bug-reports regarding the invalid 
Fppkg-configurations. I hope that solving these issues now will lead to 
more correct fppkg-installations. That way it will be really possible to 
distribute updates of FPC-packages between FPC-releases.


Ok, I've tried to give a short answer, but it is still a lot of text. 
But I hope this will explain a bit of my motivation to work on the system.


Regards,

Joost.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] commits for merging to 3.2 ?

[Sven Barth via fpc-devel]

Am Mo., 11. Feb. 2019, 15:13 hat Marco van de Voort <
c...@pascalprogramming.org> geschrieben:

> Op 2/11/2019 om 2:38 PM schreef Sven Barth via fpc-devel:
>
>
> If Sven says to merge them, I will.
>>
>
> If the testsuite isn't saying otherwise you have a green light for that
> (I'd first need to check today's Changed results :/ ).
>
>
> The only regression is the new test added. I suspect because it has the
> lazarus cthreads clause
>
> {$IFDEF UseCThreads} cthreads, {$ENDIF}
>
> in the uses list, but probably the text runner doesn't enable that define?
>
>
>
Ah, dang it. In the other test I had changed that to Unix but in that one I
forgot it  I'll correct that shortly.

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] TRegistry fixes

[Bart]

Hi,

The new (W-API based) TRegistry in trunk and 3.2 fixes has some
problems on Windows, amongst which at least one regression.

https://bugs.freepascal.org/view.php?id=35060
The use of Utf8Decode on strings that are not guaranteed to be CP_UTF8 is wrong.
As a result Keys with unicode characters in their name cannot be read
anymore (nor written to).
(This is a regression)

https://bugs.freepascal.org/view.php?id=34876
The implementation of ReadStringList/WriteStringList treats a sequence
of Unicode chars (WideChar) as if they were AnsiChar (a.o.).

https://bugs.freepascal.org/view.php?id=35022
TRegIniFile writes data to the wrong Key.

All these issues have patches and sample programs attached.

The patch for https://bugs.freepascal.org/view.php?id=35022 also
resolves https://bugs.freepascal.org/view.php?id=35023 and
https://bugs.freepascal.org/view.php?id=33980

Attached to https://bugs.freepascal.org/view.php?id=35022  is also a
test, intended to be added to tests/test/packages/fcl-registry.
(Currently the only test there is a trivial one.)

I can try to write tests for the other issues as well, but verifying
in code that WriteStringList yields the correct result may be a little
tricky, because it would depend on ReadStringList.
The patch for that issue will write a StringList and read that back
again and regedit does not complain that data is wrong.

It would be very nice if some devel who actually uses Windows (and has
at least rudimentary knowledge of the use of TRegistry) can have a
look at it and give some feedback.
Especially since these bugs will be in the upcoming 3.2.0 if they are
not fixed (and merged).

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] commits for merging to 3.2 ?

[Sven Barth via fpc-devel]

Am Mo., 11. Feb. 2019, 10:07 hat Marco van de Voort <
c...@pascalprogramming.org> geschrieben:

>
> Op 2/10/2019 om 9:47 PM schreef Martin:
> > I am not sure  if there is a place for the indent to merge (or absent
> > thereof) can be checked?
> >
> > Once merged, the svn log, but before?  Will the target on mantis
> > always indicate the decision made?
> >
> > Can the following 2 be merged?
> > https://bugs.freepascal.org/view.php?id=35027
> > https://bugs.freepascal.org/view.php?id=35028
> >
> If Sven says to merge them, I will.
>

If the testsuite isn't saying otherwise you have a green light for that
(I'd first need to check today's Changed results :/ ).

Regards,
Sven

>
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] commits for merging to 3.2 ?

[Marco van de Voort]

Op 2/10/2019 om 9:47 PM schreef Martin:
I am not sure  if there is a place for the indent to merge (or absent 
thereof) can be checked?


Once merged, the svn log, but before?  Will the target on mantis 
always indicate the decision made?


Can the following 2 be merged?
https://bugs.freepascal.org/view.php?id=35027
https://bugs.freepascal.org/view.php?id=35028


If Sven says to merge them, I will.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel