from:"Mattias Gaertner"

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

2024-03-19 Thread 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

2024-03-19 Thread 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

2024-03-18 Thread 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

2023-12-20 Thread 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

2023-10-18 Thread 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

2023-10-17 Thread 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

2023-10-17 Thread 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

2023-10-17 Thread 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

2023-10-17 Thread 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

2023-10-10 Thread 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

2023-10-02 Thread 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

2023-08-30 Thread 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

2023-08-30 Thread 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

2023-08-30 Thread 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

2023-08-18 Thread 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

2023-08-18 Thread 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

2023-08-18 Thread 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

2023-08-17 Thread 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

2023-08-17 Thread 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

2023-07-28 Thread 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;

2023-05-21 Thread 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....

2023-03-01 Thread 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....

2023-03-01 Thread 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

2023-02-02 Thread 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

2023-02-02 Thread 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

2023-01-13 Thread 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

2023-01-13 Thread 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?

2023-01-12 Thread 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

2023-01-07 Thread 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

2023-01-07 Thread 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

2023-01-07 Thread 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

2022-11-29 Thread 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

2022-11-29 Thread 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

2022-09-21 Thread 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

2022-05-07 Thread 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

2022-05-06 Thread 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

2022-03-23 Thread 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

2022-03-23 Thread 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

2022-03-23 Thread 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

2022-01-14 Thread 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

2022-01-12 Thread 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

2021-12-27 Thread 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

2020-12-16 Thread 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

2020-09-26 Thread 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

2020-07-13 Thread 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.

2020-07-03 Thread 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!

2020-03-30 Thread 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?

2020-02-23 Thread 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*()

2019-12-27 Thread 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*()

2019-12-26 Thread 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*()

2019-12-26 Thread 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

2019-11-10 Thread 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 ?

2019-09-03 Thread 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 ?

2019-09-03 Thread 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?

2019-07-22 Thread 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

2019-07-01 Thread 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

2019-05-13 Thread 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

2019-03-30 Thread 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

2019-03-30 Thread 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

2019-02-26 Thread 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

2019-02-16 Thread 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

2019-02-16 Thread 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

2019-02-04 Thread 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

2019-02-03 Thread 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)

2019-01-27 Thread 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)

2019-01-27 Thread 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)

2019-01-07 Thread 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)

2019-01-07 Thread 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

2019-01-02 Thread 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

2018-11-05 Thread 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

Re: [fpc-devel] Why/how does the compiler have a non-trivial number ofmemory leaks after over two decades of development?

2018-07-30 Thread Mattias Gaertner

On Mon, 30 Jul 2018 14:36:10 +0200 (CEST)
Michael Van Canneyt  wrote:

>[...]
> Many people will probably be surprised, but the use of try/finally 
> is not required for an application:
> 
> Gradually, some parts of the compiler were switched to classes, but even
> then, without exceptions: As long as you do not use the sysutils unit,
> (which was the case for many years for the compiler) exceptions will 
> not be raised, and so there is simply no need for try/finally blocks.

Many people will probably surprised, that try/finally/except works
without sysutils and try/except does not need "Exception". It
works with any TObject.

 
> Probably it would be better to remove the dependency on sysutils, to keep
> the compiler free of try/finally blocks.

Sysutils has nothing to do with creating exception frames.

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

Re: [fpc-devel] Managed Types, Undefined Bhaviour

2018-06-29 Thread Mattias Gaertner

On Fri, 29 Jun 2018 19:15:00 +0200
Martok  wrote:

> Am 29.06.2018 um 16:37 schrieb Thorsten Engler:
> > The specific functions that implement an interface get baked into the class 
> > at the moment when the interface is defined as part of the class. This 
> > results in important differences in behaviour, depending if methods (in the 
> > class) are defined as virtual or not, and if a derived class redeclares an 
> > interface already declared on an ancestor or not.  
> Okay, then why does the calling convention change matters so much?

The compiler searches interface methods in the class via the method
signature, which includes the calling convention.
Same as Delphi.

And same as Delphi, FPC does not give a hint if there is an overload
with a different calling convention. I wish there would be.

> [...] COM interface methods can't logically not be virtual,

I think you are confusing things here. They can be virtual or not
virtual in COM and CORBA.

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

Re: [fpc-devel] Managed Types, Undefined Bhaviour

2018-06-29 Thread Mattias Gaertner

On Fri, 29 Jun 2018 19:11:14 +0200 (CEST)
Michael Van Canneyt  wrote:

> On Sat, 30 Jun 2018, Thorsten Engler wrote:
> 
> >> -Original Message-
> >> From: fpc-devel  On Behalf Of
> >> Michael Van Canneyt
> >> Sent: Saturday, 30 June 2018 01:07
> >> To: FPC developers' list 
> >> Subject: Re: [fpc-devel] Managed Types, Undefined Bhaviour
> >> 
> >> what does this demo actually demonstrate other than that the compiler
> >> functions ?  
> >
> > That there is a difference between "functions correctly" and "performs 
> > well"?  
> 
> Please explain. Exactly how does it demonstrate this ?

Functions correctly: _AddRef is called for each interface reference and
_AddRef and _Release are balanced.

Performs well: need only 3 _AddRef instead of 6

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

Re: [fpc-devel] Managed Types, Undefined Bhaviour

2018-06-29 Thread Mattias Gaertner

On Fri, 29 Jun 2018 16:18:04 +0200 (CEST)
Michael Van Canneyt  wrote:

> On Fri, 29 Jun 2018, Michael Van Canneyt wrote:
> 
> >
> >
> > On Fri, 29 Jun 2018, Martok wrote:
> >  
> >> Am 29.06.2018 um 14:41 schrieb Michael Van Canneyt:  
> >>> As far as I can see, you get 2 chain and 1 done call. Which is what I'd   
> > expect.  
> >>> The overrides of the _* calls are useless, since they are not virtual in
> >>> TInterfacedObject and hence never called. So that's OK too.  
> >> Interface functions are always virtual and implemented by the actually
> >> instantiated class.  
> 
> > The "override" keyword is neither allowed nor needed, this  
> >> code does what it looks like.
> >>
> >> The expected output would be 3 Addrefs and 3 Releases.  
> >
> > I don't get that.  
> 
> Pressed send too quickly.
> 
> home:~> ./tirc   
> Chain: 7FA5948CF040
> Chain: 7FA5948CF040
> Done: 7FA5948CF040

"stdcall" is wrong for Linux. It must be
{$IFNDEF WINDOWS}cdecl{$ELSE}stdcall{$ENDIF};

Then you get under Linux:
Addref: 7F0B935BF040 Refcount: 1 at 0041331A
Addref: 7F0B935BF040 Refcount: 2 at 004121F2
Release: 7F0B935BF040 Refcount: 2 at 00412196
Chain: 7F0B935BF040
Addref: 7F0B935BF040 Refcount: 2 at 0041331A
Addref: 7F0B935BF040 Refcount: 3 at 004121F2
Release: 7F0B935BF040 Refcount: 3 at 00412196
Chain: 7F0B935BF040
Addref: 7F0B935BF040 Refcount: 3 at 0041331A
Addref: 7F0B935BF040 Refcount: 4 at 004121F2
Release: 7F0B935BF040 Refcount: 4 at 00412196
Done: 7F0B935BF040
fin
Release: 7F0B935BF040 Refcount: 3 at 00412196
Release: 7F0B935BF040 Refcount: 2 at 00412196
Release: 7F0B935BF040 Refcount: 1 at 00412196

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

Re: [fpc-devel] {$mode tp} compatibility issue

2018-06-05 Thread Mattias Gaertner

On Tue, 5 Jun 2018 14:09:16 +0200
Klaus Hartnegg  wrote:

> Hi,
> 
> I just stepped into a trap when compiling Turbo Pascal source with 
> FreePascal, and wonder how FreePascal could prevent this.
> 
> The source effectively contains something like
> 
> type
>mytype = (a,b,c);
> 
> var
>t : mytype;
>f : text;
> 
> begin
>assign (f,'filename');
>reset (f);
>readln (f,byte(t));
> 
> Except that in the real thing the type declaration was in another unit,
> but that should not matter, right?

It does matter. See here:
https://www.freepascal.org/docs-html/prog/progsu59.html#x66-650001.2.59

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

[fpc-devel] Lazarus Release 1.8.4

2018-05-22 Thread Mattias Gaertner

The Lazarus team is glad to announce the release of Lazarus 1.8.4. This
is a bugfix release.

The release was built with FPC 3.0.4.

Here is the list of changes for Lazarus and Free Pascal:
http://wiki.lazarus.freepascal.org/Lazarus_1.8.0_release_notes
http://wiki.lazarus.freepascal.org/User_Changes_3.0.4

Here is the list of fixes for Lazarus 1.8.x:
http://wiki.freepascal.org/Lazarus_1.8_fixes_branch

The release is available for download on SourceForge:
http://sourceforge.net/projects/lazarus/files/

Choose your CPU, OS, distro and then the "Lazarus 1.8.4" directory.

Checksums for the SourceForge files:
http://www.lazarus-ide.org/index.php?page=checksums#1_8_4

Minimum requirements:

Windows:
2k, XP, Vista, 7, 8, 8.1 and 10, 32 or 64bit.
optional qt 4.5 or 5.6 for qt apps

FreeBSD/Linux:
gtk 2.8 for gtk2, qt4.5 for qt, qt5.6 for qt5, 32 or 64bit.

Mac OS X:
10.5 to 10.12; Carbon (32bit), Cocoa (64bit, not stable), qt and qt5
(32 or 64bit).

The svn tag is
http://svn.freepascal.org/svn/lazarus/tags/lazarus_1_8_4

For people who are blocked by SF, the Lazarus releases from SourceForge
are mirrored at: ftp://ftp.freepascal.org/pub/lazarus/releases/
and later at (after some time for synchronization)
http://mirrors.iwi.me/lazarus/


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

Re: [fpc-devel] Debugging Loop Unroll Optimization

2018-05-18 Thread Mattias Gaertner

On Sat, 19 May 2018 01:16:00 +1000
"Thorsten Engler"  wrote:

>[...]
> The for-loop variable is undefined after the loop if the loop ran to 
> completion. It retains its last value if the loop exited in a controlled way 
> (goto, break, exit, ?) before running to completion.

You forgot the case where the loop was not entered:

for i:=2 to 1 do ;

i is now undefined.

Same for 

for i in emptyset do ;


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

Re: [fpc-devel] Debugging Loop Unroll Optimization

2018-05-18 Thread Mattias Gaertner

On Fri, 18 May 2018 13:28:30 +0200 (CEST)
mar...@stack.nl (Marco van de Voort) wrote:

>[...]
> > > "After the for statement terminates (provided this was not forced by a 
> > > Break or an Exit procedure), the value of counter is undefined."
>[...]
> Well, well, clearly. One could interpret it that it says that the for
> statement terminates naturally if not forced by break or exit.  It doesn't
> say what happens with break or exit.

If the value of counter is undefined no matter what, then you would
not bother writing the exception in the brackets, wouldn't you?

> The fact that this exception is not documented with an example makes it very
> ambiguous IMHO.

I found a dozen places in the VCL using this. 
For Result:=...do if ... then exit;

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

Re: [fpc-devel] Debugging Loop Unroll Optimization

2018-05-17 Thread Mattias Gaertner

On Thu, 17 May 2018 18:34:04 +0200
Florian Klämpfl  wrote:

>[...]

Apparently this mail thread confuses some users:
report https://bugs.freepascal.org/view.php?id=33753:


> ISO7185: "After a for-statement is executed, other than being left by a 
> goto-statement, the
> control-variable shall be undefined"
> 
> http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Declarations_and_Statements_(Delphi)#For_Statements:
> "After the for statement terminates (provided this was not forced by a Break 
> or an Exit procedure),
> the value of counter is undefined."
> 
> So this shall not be unrolled, but is still error prone, if Result is not set 
> after the regular end of the for loop.

To avoid misunderstandings:
The above clearly says, that using break/goto/exit is safe:

  for Result:=low to high do
if Something(Result) then exit;

  for Result:=low to high do 
if Something(Result) then break;
  Something(Result);

OTOH this is not safe:

> > function tfun: integer;
> > begin
> >   for Result:=1 to 10 do
> > s:=s+1;
> > end;  


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

[fpc-devel] note 6058 marked as inline is not inlined

2018-05-04 Thread Mattias Gaertner

Hi all,

I welcome the possibility to see what inline function is not inlined,
but why is it enabled by default?

componenttreeview.pas(304,5) Note: (6058) Call to subroutine "function 
GetDebugLogger:TLazLogger;" marked as inline is not inlined

Can it be disabled by default and enabled with -vm6058- when needed?

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

Re: [fpc-devel] Broken frac function in FPC3.1.1 / Windows x86_64

2018-04-28 Thread Mattias Gaertner

On Sat, 28 Apr 2018 10:55:10 +0200
Sven Barth via fpc-devel  wrote:

>[...]
> The question is whether we should really return 0 for numbers that would 
> cause an integer overflow as from the user's perspective of this 
> function integers aren't involved at all (after all one passes in a 
> floating point value and receives one).
> Maybe it would be better if we'd provide an optimized Int() function and 
> Frac() then simply stays "d - Int(d)".

Since a float only stores the highest bits of a number, the fraction
of a high number is not stored aka treated as 0.

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

Re: [fpc-devel] Broken frac function in FPC3.1.1 / Windows x86_64

2018-04-27 Thread Mattias Gaertner

On Sat, 28 Apr 2018 02:48:14 +1000
"Thorsten Engler"  wrote:

> For what it’s worth, Delphi simply decided to give up on doing it correctly 
> and silently fail if the double is too large to fit in an Int64.
>[...]
> WriteLn(Frac(1e15+0.5));
> 
> WriteLn(Frac(1e16+0.5));
> 
> When executed in 32bit code, returns:

That means it has the Extended 80bit type, so it can handle the
1e16+0.5.
http://docwiki.embarcadero.com/Libraries/Tokyo/en/System.Extended

 
> 5.00E-0001
> 
> 5.00E-0001
> 
>  
> 
> And when executed in 64bit code, returns:

That means it has only the 64bit double type, so the +0.5 is lost.


> 5.00E-0001
> 
> 0.00E+

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

Re: [fpc-devel] * GMX Spamverdacht * Re: Broken frac function in FPC3.1.1 / Windows x86_64

2018-04-27 Thread Mattias Gaertner

On Sat, 28 Apr 2018 00:09:12 +1000
"Thorsten Engler"  wrote:

> Highest integer that fits in a Int64:
> 9223372036854775808
> 1e20:
> 1
> 
> Your Int is overflowing.
> 
> You can’t implement Frac by going through an Integer, that will never work.

It could work if you check for small and big values before doing so.


Mattias

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

Re: [fpc-devel] What to call this?

2018-03-25 Thread Mattias Gaertner

On Sun, 25 Mar 2018 19:59:55 +
Ozz Nixon  wrote:

> Going through the system unit, and I noticed this syntax (not verbatim!)
> 
> Procedure Cmd_Line:PChar;
> property CmdLine read Cmd_Line;
> 
> * Debating about support this, but, no idea what this would be called, a
> property outside of a class, to a global proc.

Do you mean "global properties":
https://freepascal.org/docs-html/ref/refse27.html

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

Re: [fpc-devel] Multiple variable initialization

2018-03-24 Thread Mattias Gaertner

On Sat, 24 Mar 2018 15:41:15 +0100 (CET)
Michael Van Canneyt  wrote:

> On Sat, 24 Mar 2018, Ondrej Pokorny wrote:
> 
> > Is there a reason why multiple variable initialization is forbidden?
> >
> > program Test;
> > var
> >   A: Integer = 0;    // allowed
> >   B, C: Integer = 0; // not allowed  
> 
> I think this is confusing to read. 
> Are B and C both initialized, or only B ?

The "integer" is applied to both. It would be inconsistent to apply the
=0 only to C.

 
> Javascript also does not allow this, I think, and for once with good reason.

Since when is JS a role model for Pascal?

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

[fpc-devel] Lazarus Release 1.8.2

2018-03-02 Thread Mattias Gaertner

The Lazarus team is glad to announce the release of Lazarus 1.8.2. This
is a bugfix release.

The release was built with FPC 3.0.4.

Here is the list of changes for Lazarus and Free Pascal:
http://wiki.lazarus.freepascal.org/Lazarus_1.8.0_release_notes
http://wiki.lazarus.freepascal.org/User_Changes_3.0.4

Here is the list of fixes for Lazarus 1.8.x:
http://wiki.freepascal.org/Lazarus_1.8_fixes_branch

The release is available for download on SourceForge:
http://sourceforge.net/projects/lazarus/files/

Choose your CPU, OS, distro and then the "Lazarus 1.8.2" directory.

Checksums for the SourceForge files:
http://www.lazarus-ide.org/index.php?page=checksums#1_8_2

Minimum requirements:

Windows:
2k, XP, Vista, 7, 8, 8.1 and 10, 32 or 64bit.
optional qt 4.5 or 5.6 for qt apps

FreeBSD/Linux:
gtk 2.8 for gtk2, qt4.5 for qt, qt5.6 for qt5, 32 or 64bit.

Mac OS X:
10.5 to 10.12; Carbon (32bit), Cocoa (64bit, not stable), qt and qt5
(32 or 64bit).

The svn tag is
http://svn.freepascal.org/svn/lazarus/tags/lazarus_1_8_2

For people who are blocked by SF, the Lazarus releases from SourceForge
are mirrored at: ftp://ftp.freepascal.org/pub/lazarus/releases/
and later at (after some time for synchronization)
http://mirrors.iwi.me/lazarus/


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

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

2018-01-22 Thread Mattias Gaertner

On Mon, 22 Jan 2018 18:45:57 +0100
Maciej Izak  wrote:

> 2018-01-22 18:25 GMT+01:00 Denis Kozlov :
> 
> > I presume then there is no way for having a class property who's returned
> > value can be dynamically changed in child classes? In other words, class
> > property getters/setters can only be implemented by the class that declared
> > the property.
> >  
> 
> Correct. There was some topic about "static class methods" and "class
> property" some time ago on fpc-devel or in fpc-pascal. For example static
> class methods can be used as callback procedure for external APIs/Libraries.

Can you explain what external APIs/Libraries have to do with class
properties?

Mattias

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

Re: [fpc-devel] Revision 38008 : log entry

2018-01-19 Thread Mattias Gaertner

On Fri, 19 Jan 2018 17:02:12 +0100
Bart  wrote:

> Hi,
> 
> The log entry for revision 38008 reads:
> 
> "fcl-passrc: renamed bsMethodCallChecks to bsOverflowChecks"
> 
> This should be:
> 
> "fcl-passrc: renamed bsMethodCallChecks to bsObjectChecks"
> 
> Can someone fix the log message?

Fixed.


> (I currently have nothing better to do than nitpicking over this ...)

Want to help?

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

[fpc-devel] Internal error 2018011401

2018-01-15 Thread Mattias Gaertner

Hi,

Using fpc trunk. What means error
Error: Internal error 2018011401
?


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

Re: [fpc-devel] First pas2js public release

2017-12-22 Thread Mattias Gaertner

On Fri, 22 Dec 2017 14:21:20 +
Alfred  wrote:

> Thanks for a very nice tool !
> 
> Small problem: AFAIK, the rtl.js is missing from SVN ?!
> https://svn.freepascal.org/svn/projects/pas2js/trunk/src/rtl/

The rtl.js is currently in the compiler svn:

https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/utils/pas2js/dist/

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

Re: [fpc-devel] First pas2js public release

2017-12-20 Thread Mattias Gaertner

On Tue, 19 Dec 2017 09:40:48 +
Lukasz Sokol  wrote:

>[...]
> pas2js treated program would run in a browser, client side only ?
> And does not care what the server is, because it does not run on server ?

Yes, in fact it does not need a server. A browser only needs some
HTML and the pas2js generated js, which could be on your local disk.
See here:
http://wiki.freepascal.org/pas2js#for_the_browser

Note that with Node.js you can run pas2js programs on the server too.

 
> For 'server' side you then write 'as usual' e.g. cgi or other way available
> (server-native binary)
> 
> (Nothing stops really the server-side-native binary (e.g. written in Pascal)
>  from sending a pas2js transpiled program to the browser as a part of a 'html 
> page'/script,
>  but the line of separation is pretty clear here : this is like doing 
> Graeme's favorite GUI to non-gui portion separation ';) 
>  but still YOU are doing the separation manually - you need to write BOTH 
> portions separately)
> 
> For communication between the browser end and the server end, there are ways 
> covered 
> (AJAX ?) not much different than the usual (js in browser <-> 
> java/php/perl/python/server side js in server) LAMP stack does.

Yes, see the demoxhr.lpr example in:
https://svn.freepascal.org/svn/projects/pas2js/trunk/demo/rtl/


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

Re: [fpc-devel] First pas2js public release

2017-12-18 Thread Mattias Gaertner

On Mon, 18 Dec 2017 20:16:03 +0100
Benito van der Zander  wrote:

>[...]
> But recently I have started to change everything to pointers.
> 
> For example when you have an array and want a subrange without the first 
> element of the array, you can either copy almost everything in a new 
> array, or just use a pointer to the second element.
> 
> Or in my XQuery interpreter I used interfaces to get ref counting, but 
> at many places the ref counting was too slow, so I replaced it with 
> pointers to interfaces.

js has different runtimes. Some things are slow some things are simple
and fast. If you need speed you have to use different tricks than on
an assembly target.

Your pointers work for some cases, but not for all. They are fast on
some browsers, on others not so much.
I agree with Michael, that this has low priority.

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

Re: [fpc-devel] First pas2js public release

2017-12-18 Thread Mattias Gaertner

On Mon, 18 Dec 2017 14:55:53 +0100
Benito van der Zander  wrote:

>[...]
> > That would be quite a slow down.  
> 
> Is it?
> 
> I saw no speed difference between
> 
> var x = 1;
> for (var i=0;i<10;i++) x++;
> 
> and
> 
> var x = [1];
> for (var i=0;i<10;i++) x[0]++;
> 
> in Firefox.

Of course not. First of all 10 is ridiculously small and second
the above example is probably optimized by the engine.
For example under V8 with 1 iterations you get 1.1s and 1.9s.

Test with some more real world code.

> Perhaps more memory usage

Pretty sure more memory usage.

 
> > Isn't speed the main idea of using pointers?  
> 
> It would be to port all existing pascal code

Like what?
What pointer code do you want to port?


> > Also what if var and @var are in different units?  
> 
> Either it needs full program static analysis, or pointers are only 
> allowed to something that was used with a pointer in its unit

Isn't that a contradiction to "port all existing"?


> > You may want to take a look at asm.js, which has a working
> > model for emulating pointers in JavaScript. It would be possible to add
> > a pas2js target for that. But then again there is webassembly
> > as well and it seems to have better support.  
> 
> That model looks like quite a slow down

The js engines have some optimizations for that model.

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

Re: [fpc-devel] Compiler for current function name

2017-12-18 Thread Mattias Gaertner

On Mon, 18 Dec 2017 10:57:59 +0100
Ondrej Pokorny  wrote:

> On 18.12.2017 10:54, Marco van de Voort wrote:
> > {$i %CURRENTROUTINE%}  
> 
> Thank you!
> Ondrej

Lazarus completion box shows that too.

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

Re: [fpc-devel] First pas2js public release

2017-12-17 Thread Mattias Gaertner

On Sun, 17 Dec 2017 21:43:45 +0100
Benito van der Zander  wrote:

> Hi,
> 
> >
> > Naturally, any memory pointer operation is not possible in Javascript. 
> > Code that relies on this will not work.  
> 
> 
> it would be great, if pointers were added.

There are pointers already. For example references to class and
arrays. 
It seems you want to emulate pointer of integer.

> One trick would be to wrap every variable that is accessed by a pointer 
> in an array (or object).

That would be quite a slow down.
Isn't speed the main idea of using pointers?

Also what if var and @var are in different units?
And what about pointer of pointer?

You may want to take a look at asm.js, which has a working
model for emulating pointers in JavaScript. It would be possible to add
a pas2js target for that. But then again there is webassembly
as well and it seems to have better support.

Mattias

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

Re: [fpc-devel] First pas2js public release

2017-12-16 Thread Mattias Gaertner

On Sat, 16 Dec 2017 17:36:14 +0100 (CET)
Michael Van Canneyt  wrote:

>[...]
> * Debugging:
> 
> Obviously, the browser debugger can be used to debug the Javascript.
> But there is more: the compiler can emit a source map, and this means that
> if the browser finds the source file, it will display the original source
> file instead of the javascript. You can debug Object pascal in the browser.

Hint: Passing -Jminclude to pas2js will include the Pascal sources in
the map, so you don't need to worry about paths.

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

[fpc-devel] Lazarus Release 1.8

2017-12-07 Thread Mattias Gaertner


The Lazarus team is glad to announce the release of Lazarus 1.8.The release was built with FPC 3.0.4.The previous release Lazarus 1.6.4 was built with FPC 3.0.2.Here is the list of changes for Lazarus and Free Pascal:http://wiki.lazarus.freepascal.org/Lazarus_1.8.0_release_noteshttp://wiki.lazarus.freepascal.org/User_Changes_3.0.4Here is the list of fixes for Lazarus 1.8.x:http://wiki.freepascal.org/Lazarus_1.8_fixes_branchThe release is available for download on SourceForge:http://sourceforge.net/projects/lazarus/files/Choose your CPU, OS, distro and then the "Lazarus 1.8.0" directory.Checksums for the SourceForge files:http://www.lazarus-ide.org/index.php?page=checksums#1_8_0Minimum requirements:Windows:2k, XP, Vista, 7, 8, 8.1 and 10, 32 or 64bit.optional qt 4.5 or 5.6 for qt appsFreeBSD/Linux:gtk 2.8 for gtk2, qt4.5 for qt, qt5.6 for qt5, 32 or 64bit.Mac OS X:10.5 to 10.12; Carbon (32bit), Cocoa (64bit, not stable), qt and qt5 (32 or 64bit).The svn tag ishttp://svn.freepascal.org/svn/lazarus/tags/lazarus_1_8_0For people who are blocked by SF, the Lazarus releases from SourceForge are mirrored at:ftp://ftp.freepascal.org/pub/lazarus/releases/and later at (after some time for synchronization)http://mirrors.iwi.me/lazarus/Mattias
 
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Multiple type sections - Far forward type declarations [feasible feature request?]

2017-10-31 Thread Mattias Gaertner

On Tue, 31 Oct 2017 09:46:52 +0100 (CET)
Michael Van Canneyt  wrote:

>[...]
> With your extended "forward type resolution" this would no longer be possible.
> Theoretically it probably can, but multiple passes would be needed. 
> This would aversely affect the compiler speed.

True for such an extended forward.
FPC allows only a simple forward. For example this is not allowed:

type
  TAnimal = class;
  TBird = class(TAnimal) end;
  TAnimal = class end;

The check at the end of a type section is done for usability, so that
missing declarations are spotted early and you cannot write spaghetti
code. There is no technical reason to check later, e.g. at the end of
the unit interface.

> Maybe some form of section folding (Type A ... Type B ->  Type A, B) can be 
> done.
> 
> But maybe h2pas can be improved. multiple "type' sections following each
> other should not happen.

+1

Another solution is the h2paswizard in Lazarus, which uses h2pas and
various codetools. One of them sorts the declarations.

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

Re: [fpc-devel] [Lazarus] Free Pascal 3.0.4-rc1 released!

2017-09-13 Thread Mattias Gaertner

On Sun, 3 Sep 2017 13:59:22 +0200 (CEST)
mar...@stack.nl (Marco van de Voort) wrote:

> In our previous episode, Mattias Gaertner said:
> > Are there already plans for the final 3.0.4 release?  
> 
> I branched on saturday and did the version updates. Then I usually wait a
> few days for people to check things (Tomas usually checks things) and
> for last minute merges.  So I hope to generate source packages on
> tuesday/wednesday and then building can start.

Any news?


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

Re: [fpc-devel] [Lazarus] Free Pascal 3.0.4-rc1 released!

2017-09-03 Thread Mattias Gaertner

Hi,

Are there already plans for the final 3.0.4 release?

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

1 2 3 4 5 6 7 >

1 - 100 of 611 matches

Mail list logo