Re: [fpc-devel] Failing Lazarus Codetools Pas2JS-related tests - again

[Mattias Gaertner via fpc-devel]

On 19.03.24 14:58, Maxim Ganetsky via fpc-devel wrote:

[...]
#7 944.7 fpmake.pp(228,5) Error: Identifier not found "T"


Ah, you are using fpc 3.3.1 to compile it.

Fixed.

But I get strange linker errors compiling webidl2pas:

(9015) Linking bin/x86_64-linux/webidl2pas
/usr/bin/ld.bfd: 
/path/compiler/utils/pas2js/units/x86_64-linux/webidl2pas.o:(.fpc.n_links+0x50): 
undefined reference to `DEBUGSTART_$CUSTAPP'
/usr/bin/ld.bfd: 
/path/compiler/utils/pas2js/units/x86_64-linux/webidl2pas.o:(.fpc.n_links+0x58): 
undefined reference to `DEBUGEND_$CUSTAPP'


It compiles with the ppu files of fpc 3.3.1 and 3.2.2 tough, but not 
with the sources ...


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

Re: [fpc-devel] Failing Lazarus Codetools Pas2JS-related tests - again

[Mattias Gaertner via fpc-devel]

On 18.03.24 20:29, Michael Van Canneyt via fpc-devel wrote:

[...]

#7 1429.0 -Fu$CfgDir/../lib/fpc/3.3.1/pas2js/*/*/namespaced
||
#7 1429.0 -Fi$CfgDir/../lib/fpc/3.3.1/pas2js/*/*/src


This seems wrong to me, but Mattias will need to look at this.


I changed the fpmake.pp. Please test.

Mattias

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

Re: [fpc-devel] Failing Lazarus Codetools Pas2JS-related tests - again

[Mattias Gaertner via fpc-devel]

On 18.03.24 18:43, Maxim Ganetsky via fpc-devel wrote:

[...]
After recent update of FPC 3.3.1 (and Pas2JS) in Lazarus CI several 
Codetools tests related to Pas2JS started failing again:


TTestPas2js.TestPas2js_ReadSettings: pas2js system unit not found
TTestPas2js.TestPas2js_FindDeclaration: pas2js system unit not found
TTestPas2js.TestPas2js_FindDeclaration_AWait: pas2js system unit not found

They worked fine with FPC 3.3.1 from the end of December.

Contents of Pas2JS configuration files follow:

[...]
#7 1429.0 #else
||
#7 1429.0 -Fu$CfgDir/../lib/fpc/3.3.1/pas2js/*/*/src


This should be enough
-Fu$CfgDir/../lib/fpc/3.3.1/pas2js/packages/*/src


[...]

Can you compile a simple Helloworld?

begin
  writeln('Hi');
end.

?

If this works, you might try removing the 
components/codetools/tests/codetools.config, so codetools rebuild the cache.



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

Re: [fpc-devel] Failing Lazarus Codetools Pas2JS-related tests

[Mattias Gaertner via fpc-devel]

On 20.12.23 10:18, Michael Van Canneyt via fpc-devel wrote:


[...]
Is this an FPC regression or the tests should be adapted somehow? Can 
this be related to introduction of subtargets to Pas2JS?


It could be, although I suspect it is more likely that the sources moved to
a subdir src in each of the package directories, to support namespaced
files.


Yes.


I was not aware that there were tests for pas2js in the lazarus 
codebase, so yes, probably some tests or the underlying code in the IDE need to be 
adapted.



utils/createconfig.pas needs to be adapted...

Mattias


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

Re: [fpc-devel] fnmatch (linux), where is the external

[Mattias Gaertner via fpc-devel]

On 18.10.23 02:03, robert rozee via fpc-devel wrote:

[...]
i prefer to work with a non-moving target, that is the sourceforge releases. 
this way, others can duplicate exactly my environment, and see what i see. i 
also believe that the vast majority of users get their FPC and Lazarus from 
sourceforge, hence it is important that any patches can be applied to such 
installs.


Patches don't work with debs.

git can reproduce any release, e.g.

cd your/lazarusgit
git checkout lazarus_3_0_RC2



given that i have installed from the three .deb packages, how do i perform a rebuild of 
the Lazarus packages? do i add the line "make distclean bigide" to the end of 
Fred vS's script?


cd your/lazarusgit
make distclean bigide

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

Re: [fpc-devel] fnmatch (linux), where is the external

[Mattias Gaertner via fpc-devel]

On 17.10.23 22:22, robert rozee via fpc-devel wrote:

Sent: Wednesday, October 18, 2023 at 3:05 AM
From: "Mattias Gaertner via fpc-devel" 

#!/bin/sh
COMPILER=fpc
make clean
make all FPC=$COMPILER OPT="-Fl/usr/local/lib"
make FPC=$COMPILER install INSTALL_PREFIX=/usr/


No, it updates fpc and all its packages. It does not touch any Lazarus
package. They must be rebuilt too. Since all packages needs rebuilding,
it makes no sense to use the lazarus deb. Just use the git version or
fpcupdelux.


interesting. the above script has been widely circulating on the lazarus/FPC 
forums, and to date none of the 'experts' there, including Marco, have suggest 
it is deficient. this silence disappoints me.


The script is ok to update fpc. And if you use lazarus from git then 
lazarus and lazbuild automatically rebuild the lazarus packages.

The script is not fine in combination with the lazarus deb.



[...] simply downloading the pre-compiled git version of anything is pointless


Where is this coming from?
I'm not aware of a pre-compiled git version of lazarus.

Clone the lazarus git and build it with "make distclean bigide".

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

Re: [fpc-devel] fnmatch (linux), where is the external

[Mattias Gaertner via fpc-devel]

On 17.10.23 15:34, robert rozee via fpc-devel wrote:

Sent: Wednesday, October 18, 2023 at 2:17 AM
From: "Mattias Gaertner via fpc-devel" 
To: fpc-devel@lists.freepascal.org

Let's see if I got this right:
You installed the debs and then installed a new compiler, effectively
replacing deb files.

The problem is that the debs install a version (Makefile.compiled files)
that is blind for changes to the compiler.

If you need a custom compiler, you need to compile lazarus yourself too,
either clone it yourself with git or use fpcupdelux.



i start out with a clean Linux install, then install the three .deb packages.

next i place in /usr/share/fpcsrc/3.2.2/ the following script and run it as 
root:

#!/bin/sh
COMPILER=fpc
make clean
make all FPC=$COMPILER OPT="-Fl/usr/local/lib"
make FPC=$COMPILER install INSTALL_PREFIX=/usr/

this script, according to Fred vS, rebuilds: FPC, the FPC RTL, and the Lazarus 
LCL.


No, it updates fpc and all its packages. It does not touch any Lazarus 
package. They must be rebuilt too. Since all packages needs rebuilding, 
it makes no sense to use the lazarus deb. Just use the git version or 
fpcupdelux.


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

Re: [fpc-devel] fnmatch (linux), where is the external

[Mattias Gaertner via fpc-devel]

On 17.10.23 14:37, robert rozee via fpc-devel wrote:

Sent: Wednesday, October 18, 2023 at 1:13 AM
From: "Mattias Gaertner via fpc-devel" 

What packages are listed in the project inspector?


you mean for my test application when it is opened in the Lazarus IDE?

Files
 project1.lpr
 unit1.pas
Required Packages
 LCL

i would strongly recommend you simply creating a x86 64-bit Linux VM and 
duplicating the process i outlined at the start.


Let's see if I got this right:
You installed the debs and then installed a new compiler, effectively 
replacing deb files.


The problem is that the debs install a version (Makefile.compiled files) 
that is blind for changes to the compiler.


If you need a custom compiler, you need to compile lazarus yourself too, 
either clone it yourself with git or use fpcupdelux.


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

Re: [fpc-devel] fnmatch (linux), where is the external

[Mattias Gaertner via fpc-devel]

On 17.10.23 13:17, robert rozee via fpc-devel wrote:

[...] i next rebuilt the compiler, RTL, etc using Fred vS's shell script:
#!/bin/sh
COMPILER=fpc
make clean
make all FPC=$COMPILER OPT="-Fl/usr/local/lib"
make FPC=$COMPILER install INSTALL_PREFIX=/usr/


NOW, the test application FAILS TO BUILD, with lazbuild reporting:

user@test:~/Pascal/Clock$ lazbuild ./project1.lpr
Hint: (lazarus) [RunTool] "/usr/bin/fpc" "-iWTOTP"
Hint: (lazarus) [RunTool] "/usr/bin/fpc" "-va" "compilertest.pas"
Hint: (lazarus) [RunTool] "/usr/bin/fpc" "-iWTOTP" "-Px86_64" "-Tlinux"
Hint: (lazarus) [RunTool] "/usr/bin/fpc" "-va" "compilertest.pas" "-Px86_64" 
"-Tlinux"
TProject.DoLoadStateFile Statefile not found: 
/home/user/Pascal/Clock/lib/x86_64-linux/project1.compiled


lazbuild should have noticed the changed file date of the compiler and 
recompile all used packages.


What packages are listed in the project inspector?

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

Re: [fpc-devel] specialization with type alias, bug or feature

[Mattias Gaertner via fpc-devel]

On 18.08.23 00:09, Mattias Gaertner via fpc-devel wrote:

[...]


Another point where it could wrong, is a generic method.
For example:

type
  TBird = class
    procedure Fly; // fpc does not yet allow this
  end;
var
  a: TBird;
  b: TBird;
begin
  a:=b;
  a.Fly; // this might call the wrong specialization or even call 
a non existing method

end;

So with class vars, generic methods and sub types the assignment must be 
forbidden.
Maybe pas2js could allow it for simple arrays, pointers, records and 
classes.


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

Re: [fpc-devel] A call to help test pure functions

[Mattias Gaertner via fpc-devel]

On 29.09.23 21:28, J. Gareth Moreton via fpc-devel wrote:

[...]  As the examples imply, to mark as a function as pure, simply
use the new "pure" directive.


When is it available? Is there a modeswitch?

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

Re: [fpc-devel] fpc compiler wrong encoding in console output on Windows

[Mattias Gaertner via fpc-devel]

On 30.08.23 15:57, Tomas Hajny via fpc-devel wrote:

[...]

I get the same in cmd.exe and via TProcess.


I.e. you open cmd.exe e.g. via the Windows key+R (rather than by 
shelling from Lazarus)?


Of course.



[...]

ACP is 1252
ConsoleCP 437


Just to be sure - you get this when running the test from Lazarus as a 
"compiler" (as suggested in my note above)?


No, when running the program in the the console. No Lazarus involved.


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

[fpc-devel] passing unicode seach paths on windows

[Mattias Gaertner via fpc-devel]

Hi,

How to pass unicode search paths to fpc?

For example when passing a -Fu as UTF8 via a config file "@my.cfg", fpc 
says:

Path: "C:\pascal\...gibberish..." not found

Is there some flag I'm missing or does fpc not support unicode search 
paths on windows?


Tested with 3.2.2 and 3.3.1.

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

Re: [fpc-devel] fpc compiler wrong encoding in console output on Windows

[Mattias Gaertner via fpc-devel]

On 30.08.23 12:04, Tomas Hajny via fpc-devel wrote:

On 2023-08-28 15:53, Ondrej Pokorny via fpc-devel wrote:
[...]
Your output is different from mine (using a freshly compiled trunk 
compiler):

Free Pascal Compiler version 3.3.1 [2023/08/29] for i386
Copyright (c) 1993-2023 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling t2.pas
t2.pas(4,2) Note: User defined: ä


Then you don't have default windows setup. Maybe you installed the cp 65001?



[...]
However, I run the compiler from regular command line, not from Lazarus. 


I get the same in cmd.exe and via TProcess.


[...] What do you get when running the following test program (you can 
simulate the same conditions e.g. by naming the resulting binary fpc.exe 
and configuring Lazarus to use this "compiler"):


uses
  Windows;
begin
  WriteLn (GetACP);
  WriteLn (GetConsoleCP);


ACP is 1252
ConsoleCP 437


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

Re: [fpc-devel] Recent changes break distclean for utils

[Mattias Gaertner via fpc-devel]

On 18.08.23 15:39, Mattias Gaertner via fpc-devel wrote:



On 18.08.23 15:29, Michael Van Canneyt via fpc-devel wrote:

[]
Where do you do this "make all" ?


top level


1. The error is that it cannot find the system unit. To my knowledge, 
that cannot be caused by stray leftover units.


2. At the top level, You must call "make all " with a release compiler.
    I do not see you specifying this option.


Because that is already the default compiler.

$ fpc -v
Free Pascal Compiler version 3.2.2 [2021/07/09] for x86_64


It seems I accidentally compiled with sudo. It would be nice if the 
clean up would stop if it can't delete a file.


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

Re: [fpc-devel] Recent changes break distclean for utils

[Mattias Gaertner via fpc-devel]

On 18.08.23 15:29, Michael Van Canneyt via fpc-devel wrote:

[]
Where do you do this "make all" ?


top level


1. The error is that it cannot find the system unit. To my knowledge, 
that cannot be caused by stray leftover units.


2. At the top level, You must call "make all " with a release compiler.
    I do not see you specifying this option.


Because that is already the default compiler.

$ fpc -v
Free Pascal Compiler version 3.2.2 [2021/07/09] for x86_64

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

Re: [fpc-devel] Recent changes break distclean for utils

[Mattias Gaertner via fpc-devel]

On 18.08.23 09:36, Michael Van Canneyt via fpc-devel wrote:

[...]


After doing "make disctlean" I still have many ppu files left:

./compiler/x86_64/units/x86_64-linux/cutils.ppu
...
./compiler/x86_64/lazbuild/nobj.ppu
...
./rtl/units/x86_64-linux/cp8859_1.ppu
...
./utils/pas2js/lib/x86_64-linux/pas2jsjsresources.ppu

That's why I get on "make all OPT='-gw2'":

make[5]: Entering directory '/home/mattias/pascal/fpc/3.3.1/compiler'
/usr/bin/ppcx64 -Ur -Xs -O2 -n -Fux86_64 -Fusystems 
-Fu/home/mattias/pascal/fpc/3.3.1/rtl/units/x86_64-linux -Fix86_64 
-FEx86_64/bin/x86_64-linux -FUx86_64/units/x86_64-linux -Cg 
-Fl/usr/lib/gcc/x86_64-linux-gnu/11 -dRELEASE -gw2 -dx86_64 -dGDB -Fux86 
-Fix86 -o/home/mattias/pascal/fpc/3.3.1/compiler/ppc1 pp.pas

PPU Loading /home/mattias/pascal/fpc/3.3.1/rtl/units/x86_64-linux/system.ppu
PPU Invalid Version 208
Fatal: Can't find unit system used by pp


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

Re: [fpc-devel] specialization with type alias, bug or feature

[Mattias Gaertner via fpc-devel]

On 17.08.23 20:08, Michael Van Canneyt wrote:

[...]
Both FPC and Delphi create different classes for TDoubleBird and 
TMyDoubleBird.


In Delphi they are not assign compatible, in FPC they are. For example:
var
 a: TDoubleBird;
 b: TMyDoubleBird;
begin
 b:=TMyDoubleBird.Create;
 a:=b; // forbidden in Delphi
 writeln(a is TDoubleBird); // writes false

Bytewise the assignment is ok, but logic wise "a" is no longer a 
TDoubleBird.


Is this a bug or a feature?


Depends on how you look at it. Double and TMyDouble are assignment 
compatible.
There is no reason why the same should not hold true for TDoubleBird and 
TMyDoubleBird ?


I guess that is true for specialized arrays, records (non advanced), 
proc types and pointers, unless I forgot something (maybe helpers?).
But classes and interfaces have "is", "as", "class of", and "class 
vars", where the difference matter.





[...]
Of course, the method addresses are different. Other than that and the
different RTTI (which has 100% the same structure)


The different RTTI has 100% the same structure?
For clarification for others to follow the discussion here is an example:

type
  TBird = class(TPersistent)
  private
FWing: T;
  published
property Wing: T read FWing;
  end;

This is allowed in Delphi, but FPC refuses generic templates in published.
The TBird.Wing has a different PPropInfo than 
TBird.Wing. That is probably only relevant in some rare cases.




I am inclined to go for feature, but maybe there are arguments to tip the
balance in the direction of bug.


One point where it could wrong, is when you port Delphi code to FPC.
For example this is fine in Delphi:

type
  TBird = class
class var Cnt: integer;
  end;
  TDoubleBird = TBird;

procedure Fly(b: TDoubleBird);
begin
  inc(b.Cnt); // under Delphi this must be TBird.Cnt
// not so under FPC
  ...
  if TDoubleBird.Cnt=1 then ...
end;


Mattias

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

[fpc-devel] specialization with type alias, bug or feature

[Mattias Gaertner via fpc-devel]

Hi,

FPC and Delphi handle type alias differently and I wonder if this was 
deliberate.


type
  TMyDouble = type double;

  TBird = class
a: T;
  end;
  TDoubleBird = TBird;
  TMyDoubleBird = TBird;

Both FPC and Delphi create different classes for TDoubleBird and 
TMyDoubleBird.


In Delphi they are not assign compatible, in FPC they are. For example:
var
  a: TDoubleBird;
  b: TMyDoubleBird;
begin
  b:=TMyDoubleBird.Create;
  a:=b; // forbidden in Delphi
  writeln(a is TDoubleBird); // writes false

Bytewise the assignment is ok, but logic wise "a" is no longer a 
TDoubleBird.


Is this a bug or a feature?

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

Re: [fpc-devel] Unicode RTL

[Mattias Gaertner via fpc-devel]

On 24.07.23 21:49, Michael Van Canneyt via fpc-devel wrote:

[...]
Subtarget support is explained in more detail here:
https://wiki.freepascal.org/FPC_Subtarget_Support



* compile the various Lazarus widgetsets into different directories
* ... any other things you may think of ...

all with a single installation of FPC.


The -t switch alters the $fpctarget, and therefore searches the fpc 
units in another directory. So a non-fpc project must add the -Fu for 
the fpc units itself.


Can you elaborate, how -t gives non-fpc projects new possibilities?

Mattias


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

Re: [fpc-devel] type PPGdkScreen = PGdkScreen;

[Mattias Gaertner via fpc-devel]

On Sat, 20 May 2023 14:09:00 +0300
Juha Manninen via fpc-devel  wrote:

> In gtkstatusiconh.inc there is a type definition
>   PPGdkScreen = PGdkScreen;
> It is most likely a bug. I guess it should be
>   PPGdkScreen = ^PGdkScreen;

Yes, fixed.

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

Re: [fpc-devel] Curious about the effect of all the new optimizations....

[Mattias Gaertner via fpc-devel]

On Wed, 1 Mar 2023 15:02:25 +0100 (CET)
Michael Van Canneyt via fpc-devel 
wrote:

> On Wed, 1 Mar 2023, Mattias Gaertner via fpc-devel wrote:
> 
> > On Wed, 1 Mar 2023 14:10:28 +0100
> > Sven Barth via fpc-devel  wrote:
> >  
> >> [...]  
> >> > I can't remember the proverb that Florian used, but it
> >> > essentially boils down to very small changes, individually not
> >> > amounting to much, but which accumulate into a noticable
> >> > difference when in large numbers.   
> >> 
> >> It's a German proverb: "Mühsam ernährt sich das Eichhörnchen"  
> >
> > Maybe more like "Kleinvieh macht auch Mist" ?  
> 
> These proverbs come from the "German Farmer & gardeners
> association"'s yearly gift calendar ?

Although the German Farmers' Association has a saying in German
politics, the proverbs are much older.

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

Re: [fpc-devel] Curious about the effect of all the new optimizations....

[Mattias Gaertner via fpc-devel]

On Wed, 1 Mar 2023 14:10:28 +0100
Sven Barth via fpc-devel  wrote:

>[...]
> > I can't remember the proverb that Florian used, but it essentially
> > boils down to very small changes, individually not amounting to
> > much, but which accumulate into a noticable difference when in
> > large numbers. 
> 
> It's a German proverb: "Mühsam ernährt sich das Eichhörnchen"

Maybe more like "Kleinvieh macht auch Mist" ?

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

Re: [fpc-devel] Question on constref

[Mattias Gaertner via fpc-devel]

On Thu, 2 Feb 2023 12:19:46 +0100
Marco van de Voort via fpc-devel  wrote:

> On 2-2-2023 12:00, Ondrej Pokorny via fpc-devel wrote:
> >
> >
> > The only disadvantage is that you get a FreeAndNil copy for every
> > type you pass into the parameter (?)  
> 
> Are they actually made global ?

yes

> Will two freeandnil in different units use the same?

yes (except for packages).

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

Re: [fpc-devel] Question on constref

[Mattias Gaertner via fpc-devel]

On Thu, 2 Feb 2023 12:00:31 +0100
Ondrej Pokorny via fpc-devel  wrote:

>[...]
> Delphi cannot do it. FPC rocks!

+1

> The only disadvantage is that you get a FreeAndNil copy for every
> type you pass into the parameter (?)
> 
> Do we want to change it in SysUtils? :)

I got a feeling this solves a problem no one had.


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

Re: [fpc-devel] Unicode RTL for FPC

[Mattias Gaertner via fpc-devel]

On Fri, 13 Jan 2023 11:25:56 +0100
Tomas Hajny via fpc-devel  wrote:

>[...]
> > My /etc/fpc.cfg contains:
> > 
> > # searchpath for units and other system dependent things
> > -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget
> > -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/*
> > -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/rtl  
> 
> What does your /etc/fpc-unicodertl.cfg contain? The correct paths
> should be there...

Michael wrote it should contain:


-dUNICODERTL
-Municodestrings


Adding unitpaths without removing/disabling the wrong ones seems wrong
to me.

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

Re: [fpc-devel] Unicode RTL for FPC

[Mattias Gaertner via fpc-devel]

On Sun, 8 Jan 2023 08:46:37 +0100 (CET)
Michael Van Canneyt via fpc-devel 
wrote:

>[...]
> Should have been
> 
> make install SUB_TARGET=unicodertl PP=path/to/the/new/compiler

This does not install the new compiler, so I used the compiler/ppcx64
exe directly to compile a program.

I see in the -va output:
[0.008] Hint: Start of reading config file /etc/fpc-unicodertl.cfg
[0.008] Handling option "-dUNICODERTL"
[0.008] Interpreting option "-dUNICODERTL"
[0.008] Macro defined: UNICODERTL
[0.008] Handling option "-Municodestrings"
[0.008] Interpreting option "-Municodestrings"
[0.008] Macro defined: FPC_UNICODESTRINGS
[0.008] Macro defined: UNICODE
[0.008] Hint: End of reading config file /etc/fpc-unicodertl.cfg

But then it uses the wrong unit paths:
[0.012] Using unit path: /usr/lib/fpc/3.3.1/units/x86_64-linux/httpd22/

It should be:

[0.012] Using unit path:
/usr/lib/fpc/3.3.1/units/x86_64-linux-unicodertl/rtl/

My /etc/fpc.cfg contains:

# searchpath for units and other system dependent things
-Fu/usr/lib/fpc/$fpcversion/units/$fpctarget
-Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/*
-Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/rtl

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

Re: [fpc-devel] Why: "Can't take the address of constant expressions" here?

[Mattias Gaertner via fpc-devel]

On Wed, 11 Jan 2023 23:58:34 +0100
Bart via fpc-devel  wrote:

> Given the following program (an excerpt form a test program for a
> bugreport about the fpwidestring unit):
> 
> ===
> program test;
> {$codepage utf8}
> {$mode objfpc}
> {$h+}
> 
> uses
>   FpWideString;
> 
> var
>   WSource: WideString = 'source';
>   USource: UnicodeString = 'source';
>   WDest: WideString = '' ;
>   UDest: UnicodeString = '';
>   ASource: AnsiString = 'source';
>   ADest: AnsiString = '';
>   P: array[0..99] of AnsiChar;
> 
> begin
>   with WideStringManager do
>   begin
> writeln(1);
> Wide2AnsiMoveProc(pwidechar(WSource),RawByteString(ADest),
> CP_UTF8, Length(WSource));
> writeln(2);
> Ansi2WideMoveProc(PChar(ASource), CP_UTF8, UDest,
> Length(ASource));   //<< test.lpr(24,53) Error: Can't take the address
> of constant expressions (caret behind UDest)
> end.

First of all, adding a 'end;" for the "with" compiles under Linux.
That's because widestring=unicodestring on Linux.

On Windows widestring is not a unicodestring and thus it can't be
passed to a var parameter. 

https://wiki.freepascal.org/Widestrings

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

Re: [fpc-devel] Unicode RTL for FPC

[Mattias Gaertner via fpc-devel]

On Fri, 6 Jan 2023 18:05:43 +0100 (CET)
Michael Van Canneyt via fpc-devel 
wrote:

>[...]
> - to create a Unicode RTL, in the rtl directory do a
> 
> make clean all SUB_TARGET=unicodertl PP=path/to/the/new/compiler
> 
> - if that worked, you can try then a
> 
> make install SUB_TARGET=unicodertl

It installed under
/usr/lib/fpc/3.2.2/units/x86_64-linux-unicodertl

Instead of
/usr/lib/fpc/3.3.1/units/x86_64-linux-unicodertl

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

Re: [fpc-devel] Unicode RTL for FPC

[Mattias Gaertner via fpc-devel]

On Fri, 6 Jan 2023 18:05:43 +0100 (CET)
Michael Van Canneyt via fpc-devel 
wrote:

>[...]
> - to create a Unicode RTL, in the rtl directory do a
> 
> make clean all SUB_TARGET=unicodertl PP=path/to/the/new/compiler

The "make clean" deletes the new compiler.

Storing the compiler/ppcx64 somewhere else and using that gives:

*** The only supported starting compiler version is 3.2.2. You are
trying to build with 3.3.1.

Trying to build using fpc 3.2.2 gives:
Error: Illegal parameter: -tunicodertl

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

Re: [fpc-devel] Unicode RTL for FPC

[Mattias Gaertner via fpc-devel]

On Fri, 6 Jan 2023 18:05:43 +0100 (CET)
Michael Van Canneyt via fpc-devel 
wrote:

>[...]
> For those that wish to help in testing:
> 
> - Update your git clone

I used a fresh clone.

> - switch to branch unicodertl.

I used git checkout unicodertl
 
> - in the toplevel FPC directory, do a
> 
> make all

I get:

Compiling .../packages/fcl-process/src/process.pp
Compiling .../packages/fcl-process/src/pipes.pp
process.inc(94,23) Error: Incompatible type for arg no. 1: Got "PChar",
expected "PWideChar"


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

Re: [fpc-devel] Sorting tests

[Mattias Gaertner via fpc-devel]

On Tue, 29 Nov 2022 23:57:14 +
"J. Gareth Moreton via fpc-devel" 
wrote:

> Familarity mostly.  More people are familiar with quicksort than 
> introsort.  Are there any explicit code examples where quicksort 
> succeeds and introsort fails?  I'm told even Lazarus crashes (or used
> to crash), so I'll be interested to see what code causes (or caused)
> it.

+1

 
>[...]

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

Re: [fpc-devel] Sorting tests

[Mattias Gaertner via fpc-devel]

On Tue, 29 Nov 2022 15:54:03 +0100
Benito van der Zander via fpc-devel 
wrote:

> Hi,
> and the FPC implementation is actually documented to not be stable in 
>[...]
> and one can see that it is indeed not stable, if you sort
> ['a','b','A'] case-insensitively, it becomes ['A', 'a','b']

If the current QuickSort is not stable, is there an another argument
for keeping it as default?


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

[fpc-devel] wasi fd_prestat_get unimplemented

[Mattias Gaertner via fpc-devel]

Hi,

Since last week wasi system unit calls fd_prestat_get, which is not yet
implemented:

pas2js git, unit packages/wasi/wasienv.pas :

function TPas2JSWASIEnvironment.fd_prestat_get(fd, bufPtr: NativeInt
  ): NativeInt;
begin
  console.log('Unimplemented: TPas2JSWASIEnvironment.fd_prestat_get');
  Result:=WASI_EBADF;
end;

Was some file not committed?

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

Re: [fpc-devel] TShiftState

[Mattias Gaertner via fpc-devel]

On Sat, 7 May 2022 10:21:26 +0200 (CEST)
Michael Van Canneyt via fpc-devel 
wrote:

> On Sat, 7 May 2022, Mattias Gaertner via fpc-devel wrote:
> 
> > Hi,
> >
> > Delphi has some extra TShiftState enums: ssTouch, ssPen,
> > ssHorizontal
> >
> > https://docwiki.embarcadero.com/Libraries/Sydney/en/System.Classes.TShiftState
> >
> > I propose for fpc to add these three and add an alias
> >
> > constant
> >  ssCommand = ssMeta;
> >
> > What do you think?  
> 
> Compiler got scared by your idea:
> 
> > fpc a.pp  
> a.pp(1,9) Fatal: Syntax error, "BEGIN" expected but "identifier
> CONSTANT" found Fatal: Compilation aborted
> Error: /usr/local/bin/ppcx64 returned an error exitcode

lol. I should not work at that time.

 
> After some calming down the compiler I committed & pushed your idea.

Thanks!

Mattias

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

[fpc-devel] TShiftState

[Mattias Gaertner via fpc-devel]

Hi,

Delphi has some extra TShiftState enums: ssTouch, ssPen, ssHorizontal

https://docwiki.embarcadero.com/Libraries/Sydney/en/System.Classes.TShiftState

I propose for fpc to add these three and add an alias

constant
  ssCommand = ssMeta;

What do you think?


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

Re: [fpc-devel] case is

[Mattias Gaertner via fpc-devel]

On Wed, 23 Mar 2022 22:20:38 +0700
Hairy Pixels via fpc-devel  wrote:

>[...]
> > Did you use multiple "is" or did you check for sorted and use one
> > loop? 
> 
> No it’s just like a the case of string syntax which checks for
> equality with ClassType so the order does matter. Maybe it’s not
> exactly like what Java has then.

Forget Java. The point is, that its "case" can be more than mere
syntactic sugar. It could give a nice speed up and the compiler warns
about unreachable statements.

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

Re: [fpc-devel] case is

[Mattias Gaertner via fpc-devel]

On Wed, 23 Mar 2022 22:00:05 +0700
Hairy Pixels via fpc-devel  wrote:

> Lol I just implemented this and made a merge request but I haven’t
> heard back from anyone yet so it’s just sitting there….
> 
> I basically just copied the structure used for “case of string” in
> that it makes if a big if-else statement.

Did you use multiple "is" or did you check for sorted and use one loop?

 
> https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/147

"Rebase failed"

Mattias


> 
> > On Mar 23, 2022, at 7:44 PM, Mattias Gaertner via fpc-devel
> >  wrote:
> > 
> > Basically for Pascal it is a case block using the "is" operator.
> > Pseudo code:
> > 
> > procedure Fly(o: TObject);
> > begin
> > case o is
> > TButton: TButton(o).foo;
> > TControl: TControl(o).bar;
> > TComponent: TComponent(o).meh;
> > nil: Msg;
> > else Run;
> > end;
> > end;  
> 
> Regards,
>   Ryan Joseph
> 

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

[fpc-devel] case is

[Mattias Gaertner via fpc-devel]

Hi,

I just stumbled over the new Java feature "Pattern Matching for switch".
https://openjdk.java.net/jeps/420
IMO it is a misnomer, but it has some interesting ideas.

Basically for Pascal it is a case block using the "is" operator.
Pseudo code:

procedure Fly(o: TObject);
begin
  case o is
TButton: TButton(o).foo;
TControl: TControl(o).bar;
TComponent: TComponent(o).meh;
nil: Msg;
  else Run;
  end;
end;

The gain versus "if o is then..." is that the compiler warns if the
case statements are not sorted and can optimize the checks.

For example the above code could be converted to:

procedure Fly(o: TObject);
var
  tmp: TClass;
begin
  if o<>nil then
  begin
tmp:=o.ClassType;
repeat
  if tmp=TButton then
  begin
TButton(o).foo;
break;
  end else if tmp=TControl then
  begin
TControl(o).bar;
break;
  end else if tmp=TComponent then
  begin
TComponent(o).meh;
break;
  end;
  tmp:=tmp.ClassParent;
  if tmp=nil then
  begin
Run;
break;
  end;
until false;
  end else
Msg;
end;

What do you think?


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

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

[Mattias Gaertner via fpc-devel]

On Fri, 14 Jan 2022 07:32:59 +0100
Sven Barth via fpc-devel  wrote:

>[...]
> Just FYI what Delphi writes in their documentation ( 
> https://docwiki.embarcadero.com/RADStudio/Sydney/en/Simple_Types_(Delphi)#Real_Types
>  
> ):
> 
> On i386 Windows Extended is 80-bit, on x86_64 Linux, i386 macOS and
> i386 iOS simulator it's 128-bit and on all other platforms (which
> includes x86_64 Windows) it's 64-bit.
> 
> So Delphi went the same way as we did.

The 128-bit is only 80bit precision, right?

With ppcx64 on Linux I get sizeof(extended)=10.

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

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

[Mattias Gaertner via fpc-devel]

On Wed, 12 Jan 2022 23:20:34 +0100
Sven Barth via fpc-devel  wrote:

>[..]
> When compiling from a target supporting Extended to one only
> supporting Double there isn't a loss of precision when calculating
> values at compile time. The other way around however, there *is* and
> that is the more crucial problem.

I'm curious, do other cross compilers like gcc
have similar problems? How do they solve it?

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

[fpc-devel] fpc make fail target embedded wasm32

[Mattias Gaertner via fpc-devel]

Hi,


make all OS_TARGET=embedded CPU_TARGET=wasm32 BINUTILSPREFIX= OPT="-O-"
PP=fpc

External command
"/home/mattias/pascal/fpc/3.3.1/compiler/ppcrosswasm32
-Tembedded -FUrtl-extra/units/wasm32-embedded/
-Fu/home/mattias/pascal/fpc/3.3.1/rtl/units/wasm32-embedded/
-Furtl-extra/src/inc -Firtl-extra/src/inc -Firtl-extra/src/embedded
-Tembedded -Pwasm32 -Ur -Xs -O2 -n -Fl/usr/lib/gcc/x86_64-linux-gnu/9
-O- -dwasm32 -dRELEASE -Sc -viq rtl-extra/BuildUnit_rtl_extra.pp"
failed with exit code 256. Console output: 
Target OS: Embedded
Compiling rtl-extra/BuildUnit_rtl_extra.pp 
Compiling ./rtl-extra/src/inc/ucomplex.pp 
ucomplex.pp(26,10) Fatal: Can't find unit math used by UComplex 
Fatal: Compilation aborted


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

Re: [fpc-devel] Explicitly named return values and implicit aliases Result

[Mattias Gaertner via fpc-devel]

On Wed, 16 Dec 2020 10:24:39 +0100 (CET)
Michael Van Canneyt via fpc-devel 
wrote:

>[...]
> Function MyResult : String;
> 
> begin
>Result:='';
>MyResult:='';
> end;
> 
> You can still use the function name for the result, so "Result" is in
> fact an alias for the function name, which is the actual name for the
> result value.

That is not entirely correct.

Function MyResult : String;
begin
   Result:=Result; // the current result
   MyResult:=MyResult; // recursive call
end;

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

Re: [fpc-devel] TThread.RemoveQueuedEvents

[Mattias Gaertner via fpc-devel]

On Sat, 26 Sep 2020 14:05:21 +0200
Martin Frb via fpc-devel  wrote:

> On 26/09/2020 13:58, Pascal Riekenberg wrote:
> > Hi Martin,
> >
> > there is a free Community Edition.
> >  
> Ok, but maybe someone who already has it installed, can copy and
> paste the test that I posted? (should barely take half a minute or
> less)

Delphi checks Code and Data.

Mattias

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

Re: [fpc-devel] Fwd: Re: An optimization suggestion for FPC

[Mattias Gaertner via fpc-devel]

On Mon, 13 Jul 2020 21:17:39 +0100
"J. Gareth Moreton"  wrote:

> I'm still having problems.  It's not letting me rebuild Lazarus for
> one thing:
> 
> jcfidemain.pas(41,3) Fatal: Cannot find LazIDEIntf used by
> JcfIdeMain, incompatible 
> ppu=c:\lazarus\components\ideintf\units\x86_64-win64\win32\lazideintf.ppu, 
> package IDEIntf
> 
> I even manually deleted the ppu file in question

Did you try deleting all ppu files using 'make distclean'?

> before opening
> Lazarus to use the internal build wizard.  I know I'm probably
> missing something obvious, but I'm not sure what.  I'm wondering if I
> should just completely delete lazarus and build from a fresh install,
> and hope I don't lose the ability to edit my projects!
> 
> Granted, having multiple versions of Lazarus installed on my system 
> probably doesn't help (I tend to keep a stable release version
> installed for non-compiler work).

Make sure Lazarus uses the right lpk files.
For example Package / Install Package. Click on each package to see the
path.

And finally as Sven already suggested:
Compile with -vut and check for checksum changed and where fpc
searches and what it finds.

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

Re: [fpc-devel] FPC 3.2.0 CHM docs updated.

[Mattias Gaertner via fpc-devel]

On Sat, 27 Jun 2020 22:45:06 +0200
Marco van de Voort  wrote:

>[...]
> If you cache CHM docs for release purposes (lazarus, fpcdeluxe etc), 
> please redownload.  The original archive has been renamed to 
> doc-chmorig.zip in case somebody needs it.

On sourceforge still contains the old doc-chm.zip from 2020-06-16.
There is no doc-chmorig.zip.

The ftp.hu.freepascal.org/pub/fpc/dist/3.2.0/docs/ contains the two files.
I will take it.

Thanks for creating them! That saves me quite some time.

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

Re: [fpc-devel] FPC 3.2.0RC1 released!

[Mattias Gaertner via fpc-devel]

On Sun, 29 Mar 2020 20:18:19 +0200
Marco van de Voort  wrote:

>[...]
> You can help improve the upcoming 3.2.0 release by downloading and
> testing this release. If you want you can report what you have done
> here: http://wiki.freepascal.org/Testers_3.2.0 or in the maillist.

It seems libpas2jslib.so needs some adjustments under debian:

From lintian:

Errors:
unstripped-binary-or-object usr/lib/libpas2jslib.so
library-not-linked-against-libc usr/lib/libpas2jslib.so
shlib-with-executable-bit usr/lib/libpas2jslib.so 0755
package-must-activate-ldconfig-trigger usr/lib/libpas2jslib.so

Warnings:

shlib-without-versioned-soname usr/lib/libpas2jslib.so libpas2jslib.so

privacy-breach-generic
usr/share/doc/fpc-3.2.0/libxml2/examples/test1.xml [http://www.garmin.com;>] (http://www.garmin.com) 

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

Re: [fpc-devel] Public modifier: brackets or not?

[Mattias Gaertner via fpc-devel]

On Sun, 23 Feb 2020 16:35:28 +0100
Bart via fpc-devel  wrote:

> Hi,
> 
> I'm a little confused.
> 
> From:
> https://www.freepascal.org/docs-html/ref/refsu81.html
> 
> This page gives 2 examples.
> 
> Function Second : Real; [Public];
> begin
>   Second := 1;
> end;
> 
> and
> 
> Function Second : Real; Public name ’second’;
> begin
>   Second := 1;
> end;
> 
> In the first, Public is in brackets, in the second it is not.
> 
> However, this will compile also:
> 
> Function Second : Real; [Public name ’second’];
> begin
>   Second := 1;
> end;
> 
> So, what is the correct syntax?

The [] is the old syntax.
It bites attributes, so better not use it.

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

Re: [fpc-devel] TEncoding.Default and default encoding for TStrings.LoadFrom*()

[Mattias Gaertner via fpc-devel]

On Fri, 27 Dec 2019 12:01:24 +0100
Ondrej Pokorny  wrote:

>[...]
> > If I understand your reasoning correct, that should solve the
> > problems you
> > report ?  
> 
> Yes, that perfectly solves the issues Lazarus developers and users
> face. I am OK with this solution as well. Thanks!

Thank you both \O/

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

Re: [fpc-devel] TEncoding.Default and default encoding for TStrings.LoadFrom*()

[Mattias Gaertner via fpc-devel]

On Thu, 26 Dec 2019 16:55:04 +0100
Ondrej Pokorny  wrote:

> On 26.12.2019 16:41, Mattias Gaertner via fpc-devel wrote:
> > On Thu, 26 Dec 2019 16:15:03 +0100
> > Ondrej Pokorny  wrote:
> >  
> >> Hello,
> >>
> >> a lot of people have a problem with the TStrings.LoadFrom*()
> >> changes when TEncoding support was added.
> >>
> >> Currently, the no-encoding overloads of TStrings.LoadFrom*() and
> >> TStrings.SaveTo*() use the TEncoding.Default, which is WIN-ANSI and
> >> not DefaultSystemCodePage.  
> > It seems FPC 3.3.1 does use DefaultSystemCodePage:
> >
> > class function TEncoding.GetANSI: TEncoding;
> > begin
> >
> >  if not Assigned(FStandardEncodings[seAnsi]) then
> >  begin
> >// DefaultSystemCodePage can be set to non-ANSI
> >if Assigned(widestringmanager.GetStandardCodePageProc) then
> >  FStandardEncodings[seAnsi] :=
> > TMBCSEncoding.Create(widestringmanager.GetStandardCodePageProc(scpAnsi))
> > else FStandardEncodings[seAnsi] :=
> > TMBCSEncoding.Create(DefaultSystemCodePage); ...
> > end;  
> 
> Check the code more carefully. It uses DefaultSystemCodePage only
> when no widestringmanager is present - which is basically never the
> case (at least on win32, Linux, Mac OS).
> 
> It uses widestringmanager.GetStandardCodePageProc(scpAnsi) that is 
> WIN-ANSI on win32 (typically 1250, 1251, 1252 - depending on your OS 
> language version).

Yes, I just saw it. Bummer.

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

Re: [fpc-devel] TEncoding.Default and default encoding for TStrings.LoadFrom*()

[Mattias Gaertner via fpc-devel]

On Thu, 26 Dec 2019 16:15:03 +0100
Ondrej Pokorny  wrote:

> Hello,
> 
> a lot of people have a problem with the TStrings.LoadFrom*() changes 
> when TEncoding support was added.
> 
> Currently, the no-encoding overloads of TStrings.LoadFrom*() and 
> TStrings.SaveTo*() use the TEncoding.Default, which is WIN-ANSI and
> not DefaultSystemCodePage.

It seems FPC 3.3.1 does use DefaultSystemCodePage:

class function TEncoding.GetANSI: TEncoding;
begin
  
if not Assigned(FStandardEncodings[seAnsi]) then
begin
  // DefaultSystemCodePage can be set to non-ANSI
  if Assigned(widestringmanager.GetStandardCodePageProc) then
FStandardEncodings[seAnsi] := 
TMBCSEncoding.Create(widestringmanager.GetStandardCodePageProc(scpAnsi))
  else
FStandardEncodings[seAnsi] := 
TMBCSEncoding.Create(DefaultSystemCodePage);
   ...
end;

Maybe you are querying TEncoding.Default before changing
DefaultSystemCodePage?


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

Re: [fpc-devel] inline... and philosophy

[Mattias Gaertner via fpc-devel]

On Sun, 10 Nov 2019 02:23:03 +
"J. Gareth Moreton"  wrote:

> Does the smart linker strip out LCL components that are not used, or 
> must everything that's registered in a package or unit be included? 

If you mean with "registered" the RegsiterClass or RegisterComponents
functions:
If it is registered the compiler must include it.
Usually the LCL components are only registered by designtime code.


> Granted, since forms are being read from a resource file, I doubt it
> can really be tied into the compiler that closely.


Mattias


> 
> Gareth aka. Kit
> 
> On 09/11/2019 15:50, Sven Barth via fpc-devel wrote:
> > J. Gareth Moreton  > > schrieb am Sa., 9. Nov. 2019,
> > 16:20:
> >
> >
> > On 09/11/2019 15:14, Michael Van Canneyt wrote:  
> > >
> > >
> > > On Sat, 9 Nov 2019, J. Gareth Moreton wrote:
> > >  
> > >> Competitions aside, there are times where space is a
> > >> premium,  
> > whether  
> > >> it be from distributing an application on a DVD, bandwidth
> > >> or data limits (even some first world countries are still on
> > >> dial-up in places, or are otherwise monopolised by a single,
> > >> bad-quality provider), the smaller capacity of solid-state
> > >> hard drives (especially on some laptops) and can otherwise
> > >> be a money saver sometimes.  
> > >
> > > I tend to think more size gains can be obtained from more  
> > aggressive  
> > > smartlinking.
> > > The smartlinking is sometimes disabled by the way code is
> > > written.
> > >
> > > To give an example, pas2js has a switch to convert published
> > > to  
> > public  
> > > sections. As a result, the published sections are suddenly  
> > reduced to  
> > > what is actually used in code. This produces significant size
> > > gains.
> > >
> > > Michael.
> > > ___
> > > fpc-devel maillist  - fpc-devel@lists.freepascal.org  
> >   
> > > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> > >  
> > That's true.  That's mentioned in the "size matters" article. I
> > didn't
> > know about 'published' until then.  Presumably, if that switch
> > doesn't
> > exist (like with most of the LCL), I gather the only way to
> > strip out those unused published sections is some very intelligent
> > whole-program
> > optimisation, and even then it may not work if a string (to
> > access a property name) is not deterministic.
> >
> >
> > For the LCL it's simply not possible, because it relies heavily on
> > the RTTI. And in the future that will only increase with extended
> > RTTI.
> >
> > Regards,
> > Sven
> >
> >
> > ___
> > fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel  

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

Re: [fpc-devel] objfpc generics how to generate self type reference ?

[Mattias Gaertner via fpc-devel]

On Tue, 3 Sep 2019 12:38:49 +0200
Mattias Gaertner via fpc-devel  wrote:

> On Tue, 3 Sep 2019 12:15:50 +0200
> Marco van de Voort  wrote:
> 
> > I'm trying to let an iterator implement the enumerator pattern and 
> > return itself, but for that I need to use the type of the generic:
> > 
> >   generic THashmapIterator=class
> >   public
> >        type PValue=^TValue;
> > 
> >      // make type alias
> > 
> >    TIteratorType = generic THashmapIterator > TValue, T, TTable>;  
> 
> Inside the generic the templates are normal types:
> 
>   TIteratorType = specialize THashmapIterator TTable>;

Btw, mode objfpc allows shortcut THashmapIterator without <> as
shortcut for "specialize THashmapIterator";

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

Re: [fpc-devel] objfpc generics how to generate self type reference ?

[Mattias Gaertner via fpc-devel]

On Tue, 3 Sep 2019 12:15:50 +0200
Marco van de Voort  wrote:

> I'm trying to let an iterator implement the enumerator pattern and 
> return itself, but for that I need to use the type of the generic:
> 
>   generic THashmapIterator=class
>   public
>        type PValue=^TValue;
> 
>      // make type alias
> 
>    TIteratorType = generic THashmapIterator TValue, T, TTable>;

Inside the generic the templates are normal types:

  TIteratorType = specialize THashmapIterator;


> 
>    var
>     Fh,Fp:SizeUInt;
>     FData:TTable;
>     function Next:boolean;inline;
>     function MoveNext:boolean;inline;
>     function Prev:boolean;inline;
>     function GetData:T;inline;
>     function GetKey:TKey;inline;
>     function GetValue:TValue;inline;
>     function GetMutable:PValue;inline;
>     procedure SetValue(value:TValue);inline;
>     function getenumerator : TIteratorType ;
>     property Data:T read GetData;
>     property Key:TKey read GetKey;
>     property Value:TValue read GetValue write SetValue;
>     property MutableValue:PValue read GetMutable;
>     property Current : T read GetData;
>     end;
> 

No repetition of templates in mode objfpc:

 function THashmapIterator.getenumerator : TIteratorType ;
 
>       begin
> 
>      result:=self;
> 
>   end;
> 
> but the I can't find a TIteratorType definition that is accepted. Can 
> some of the objfpc generics buffs reveal the secret how to do this?
> 
> Do I need to nest the iterators first, like in Delphi, and if so will 
> ($modeswitch advancedrecords} allow this?


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

Re: [fpc-devel] pas2js: Generics for TJSArray?

[Mattias Gaertner via fpc-devel]

This is the fpc list. It would be better to post on the pas2js mailing list.

On 21.07.19 22:45, Michael Van Canneyt wrote:

[...]
As far as I know, array helpers should work ?

Yes.



What is missing on the arrays ? I think Copy, insert, Concat should 
all work.

Yes.


[...]


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

Re: [fpc-devel] [] property overloads

[Mattias Gaertner via fpc-devel]

On Mon, 1 Jul 2019 11:38:31 -0400
Ryan Joseph  wrote:

> > On Jul 1, 2019, at 7:56 AM, Ondrej Pokorny 
> > wrote:
> > 
> > type
> >   TValue = record A: Integer end;
> >   TMyClass = class
> > function GetValue(index: integer): TValue;
> > function GetValue(index: string): TValue;
> > property Index[aindex: integer]: TValue read GetValue; default;
> >   end;  
> 
> And btw what was decided about the syntax? I think it was determined
> it was valid in Delphi but is it going to be allowed in ObjFPC mode?

Write one thing, mean another? Come on, even Embarcadero can't call
that bug a feature.

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

Re: [fpc-devel] modeswitch multihelpers

[Mattias Gaertner via fpc-devel]

On Mon, 13 May 2019 11:33:36 +0200 (CEST)
Stefan Glienke  wrote:

> I want to argue that the way this is implemented is asking for easily
> introducing defects into existing code by extending/modifying helpers
> causing methods to creep into scope.

How can a disabled-by-default modeswitch "defects into existing code"?


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

Re: [fpc-devel] Aligned dynamic arrays

[Mattias Gaertner via fpc-devel]

On Sat, 30 Mar 2019 12:57:48 -0400
Ryan Joseph  wrote:

> > On Mar 30, 2019, at 12:53 PM, Mattias Gaertner via fpc-devel
> >  wrote:
> > 
> > I guess you mean auto dereferencing.
> > {$ModeSwitch AutoDeref}  
> 
> Yeah I just found this by looking around in the compiler. Mind.
> Blown. No idea that existed!

And some people still ask for more modeswitches...

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

Re: [fpc-devel] Aligned dynamic arrays

[Mattias Gaertner via fpc-devel]

On Sat, 30 Mar 2019 10:03:12 -0400
Ryan Joseph  wrote:

> > On Mar 30, 2019, at 9:55 AM, Jonas Maebe 
> > wrote: 
> >> You are not required to dereference pointers to write to them.
> >> var
> >>   P: PPoint;
> >> begin
> >>   P := AlignedArray[0];
> >>   P.X := 3; // can be okay
> >>   AlignedArray[0].Y := 4;  // can be okay as well  
> > 
> > That only works in {$mode delphi}  
> 
> Oh that’s why! How does this work in Delphi mode without pointers and
> why wasn’t it added to ObjFPC mode? 

I guess you mean auto dereferencing.
{$ModeSwitch AutoDeref}

> That would have saved me some
> headache in the past if I knew this.

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

Re: [fpc-devel] TRegistry and Unicode

[Mattias Gaertner via fpc-devel]

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 argument is that since we interface explicitely with a
> UnicodeString API, then why not expose that to the programmer?

Note: TRegistry uses only on Windows a UTF-16 API.
On non Windows systems it uses TXmlRegistry, which uses AnsiString and
internally uses TXMLDocument, which uses UnicodeString.

Perhaps it would be better to change TXmlRegistry to Unicodetring?

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

Re: [fpc-devel] "Blank slate" next version of FPC

[Mattias Gaertner via fpc-devel]

On Sat, 16 Feb 2019 13:37:44 -0800
Ralf Quint  wrote:

>[...]
> Adding newfangled gadgets and gizmos might be all fine and dandy, but 
> don't force it down the throat of everyone as a must. I am not going
> to throw away 40 years of libraries and snippets away and start from 
> scratch, just so some folks can claim to run with the in-crowd. I got 
> work to do...

+1

But FPC has accumulated so many features over the years that it
became hard for a newbie to learn the whole language, some old language
features are hardly needed anymore and many of the new languages
features are hidden behind some modeswitches.

For example I would like to disable TP objects and writeable
const and enable advanced records. Are there some command line params
to do that?


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

Re: [fpc-devel] "Blank slate" next version of FPC

[Mattias Gaertner via fpc-devel]

On Sat, 16 Feb 2019 09:43:32 +0100
Florian Klämpfl  wrote:

>[...]but we try as much as possible to break old code.

Then you are not doing a good job. ;)

Mattias

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

Re: [fpc-devel] New sorting routines

[Mattias Gaertner via fpc-devel]

On Mon, 4 Feb 2019 14:26:55 +0200
Nikolay Nikolov  wrote:

> On 2/3/19 11:22 PM, C Western wrote:
> > I suspect the new sorting routines need some work - lazarus
> > compiled with the latest trunk hangs on start up, and it looks like
> > an infinite loop in sorting. Stack trace below.  
> 
> Even though the sort routine did slightly change, I believe this
> exposes a bug in lazarus. The CompareBinary routine in
> syneditmarkuphighall.pp returns -1 when the strings are equal, while
> it should return 0 in this case. This is like having two elements in
> the array, for which (a The Compare function, passed to the sort algorithms must satisfy the
> mathematical properties of comparisons, otherwise the result is
> undefined (whether it should results in a hang (like in this case),
> or in a bad sort (like in the previous variation of the algorithm) is
> a separate discussion).
> 
> The attached patch fixes this.

Thanks. Applied.

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

Re: [fpc-devel] Internal symbols

[Mattias Gaertner via fpc-devel]

On Sun, 03 Feb 2019 04:08:46 +
"J. Gareth Moreton"  wrote:

>[...]
>   Lazarus doesn't even display the error (see bug #34996)

Fixed.

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

Re: [fpc-devel] Looking for clarification on what I think are obviously missing "const" prefixes for parameters in the methods of TRect (the typshrdh.inc one)

[Mattias Gaertner via fpc-devel]

On Sun, 27 Jan 2019 13:11:53 +
Walter Prins  wrote:

>[...]
> Just thinking out loud (probably a bad idea) but:
> 
> Would it perhaps be possible to treat this as a type of optimization
> however?  Which is to say, if the called routine makes no changes to
> the passed record, then it should not matter whether compiler
> implicitly const passes the parameter or copies it?  (If the routine
> *does* change the passed record then it does the normal thing.)  Of
> course I have no idea whether the dataflow analysis I imagine needed
> to support this is whatsoever plausible to be done without
> unacceptable compromises  (And even then, I'd guess it's not
> something there'd be sufficient appetite for even if in theory it
> might be possible...?)

It is possible. 
Note that changing the signature needs a wrapper when creating a proc
value:
Proc:=@TheOptimizedProc;

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

Re: [fpc-devel] Looking for clarification on what I think are obviously missing "const" prefixes for parameters in the methods of TRect (the typshrdh.inc one)

[Mattias Gaertner via fpc-devel]

On Sat, 26 Jan 2019 20:52:44 -0500
John Doe  wrote:

>[...]
> Regardless, units like graphmath.pp
> 

I added some const and inline.

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

Re: [fpc-devel] Failure to recompile TAChart after FPC r40785 (committed by Jonas)

[Mattias Gaertner via fpc-devel]

On Mon, 7 Jan 2019 19:24:53 +0100
Jonas Maebe  wrote:

> On 07/01/19 17:32, Mattias Gaertner via fpc-devel wrote:
> > True, reason is that *non* static means there is a Self.
> > But since there is no "object of objecttype" and no "record of
> > recordtype", there is no type for Self in class methods of
> > objects/record.  
> 
> Object class methods do have a self parameter. If an object has a
> vmt, the object class methods get this vmt pointer passed as self
> parameter. Otherwise they get nil as self parameter. Kylix does not
> support calling object class methods through tobjecttype.classmethod
> either, which is indeed kind of strange.

Thanks. I learned something new.

But what is this Self?

  TBird = object
class procedure DoIt; virtual;
  end;

class procedure TBird.DoIt;
var
  o: TBird;
begin
  o:=Self; 
  // Error: Incompatible types: got "Class Of TBird" expected "TBird" 
end;

But "Class Of TBird" does not exist in FPC, does it?

 
> It is not possible to declare a non-static class method (in FPC, at 
> least; Kylix does not support "advanced records", so I cannot test
> there).

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

Re: [fpc-devel] Failure to recompile TAChart after FPC r40785 (committed by Jonas)

[Mattias Gaertner via fpc-devel]

On Mon, 7 Jan 2019 17:13:21 +0100
Sven Barth via fpc-devel  wrote:

>[...]
> Did you try to add "static" to the TDiaPosition.Equals class
> function? For an object type only instance and static class methods
> make sense so non static class methods should probably best be
> forbidden.

True, reason is that *non* static means there is a Self.
But since there is no "object of objecttype" and no "record of
recordtype", there is no type for Self in class methods of
objects/record.

Mattias


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

Re: [fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements

[Mattias Gaertner via fpc-devel]

On Wed, 2 Jan 2019 12:05:17 +0100 (CET)
Michael Van Canneyt  wrote:

> On Wed, 2 Jan 2019, Sven Barth via fpc-devel wrote:
> 
> > Am Mi., 2. Jan. 2019, 11:08 hat Bart 
> > geschrieben: 
> >> On Wed, Jan 2, 2019 at 9:44 AM Martok 
> >> wrote: 
> >>> - If a case statement on an ordinal does not contain labels for
> >>> all  
> >> values of  
> >>> the ordinal, and no else statement is given, raise a new warning  
> >> (W6059). This  
> >>> is actually defined as an error in ISO7185 and a
> >>> dynamic-violation in  
> >> IEC10206.
> >>
> >> So now I will have to add a useless else statement for every case
> >> statement that uses e.g. integers, or rewrite them to
> >> if..then..else or if value in [...]?
> >> And how will I mage this when my code runs on different
> >> architecture where the full range of the ordinal may differ?
> >>
> >> Please no (to this part of the proposal).
> >>  
> >
> > Warnings can always be disabled by {$warn NR off} or - I believe - a
> > command line switch.
> > One could also decide to have it be a default off warning for the
> > non ISO modes (FPC, Delphi, MacPas) like some of the string
> > conversion warnings.  
> 
> I would strongly advise to have it off by default for all but the ISO
> modes.
> 
> You have perfectly valid code today (see the example of indexed
> properties) which would start generating exceptions, and you should
> not be forced to add a {$ } directive or an "else" clause to a case
> statement for this.

I do hope you meant warnings, not exceptions.

 
> I agree this warning is very useful for enumerated types, but really
> not for integers. There are too many cases where it would be a false
> positive.

I have a lot of code with enums, where these warnings will force me to
do a lot of changes.

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

Re: [fpc-devel] How do I go about volunteering as a "release builder", so that we can get rid of the objectively untrue, misleadingly worded "There is no native compiler available for x86_64 Win64. Yo

[Mattias Gaertner via fpc-devel]

On Sun, 4 Nov 2018 22:43:19 -0500
Ben Grasset  wrote:

>[...]
> It's worth noting I guess that Lazbuild *does *invoke the FPC
> instances all at the same time, and by default uses the number of
> CPUs as the limit. It seems theoretically possible that if you had
> let's say 8 copies of specifically *32-bit* FPC running at the same
> time building Lazarus packages that they could hit a cap that
> wouldn't be hit with 64 bit binaries.

Have you tried passing --max-process-count=1 to lazbuild?

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