[fpc-pascal] Commercial support for Lazarus/FPC

[denisgolovan]

Hi all

I am considering to subscribe to commercial support in FPC/Lazarus, but I don't 
have a clear picture what actually support is :)
I am looking at http://www.lazarussupport.com/lazarus/Support and it is 
somewhat too abstract.

I thought maybe it is easier to see what I am interested in and to give a 
concrete example.
So if you don't mind, I'll try to describe a couple of alternatives.

Personally, I am interested in maintenance in FPC/Lazarus existing 
functionality.
But for objective reasons sometimes I am stuck with some bug in FPC/Lazarus.

So I have several choices there.

First one and the easiest - to report it and try to wait until the next stable 
version release.
And yes, unfortunately it is too much time between releases currently.
Furthermore if the reported bug is fixed, it is fixed only in trunk and no 
backporting occurs.
Again no hard feelings, I fully understand that it is a open-source project and 
you do the best you can.

Second one - try to follow FPC/Lazarus development in trunk every time 
something is fixed.
That's the way I am currently following. Unfortunately, the trunks (FPC and 
Lazarus) can be unstable and when something is fixed, the other existing 
functionality stops working.
Again - that's the fact of life and I can't demand anything here.

Third alternative, which I wanted to discuss in more details, is bug-fix 
backporting to the last stable version.
Yes, it is time-consuming and it is quite costly, but it guarantees the quality.
Again, I could do it myself, keeping the patches I am interested in in a 
separate private repository, but :
 1. I think a lot of people can be potentially interested in such
 repository, so the costs can be divided between the "stakeholders" and
 qualitative commercial support can be provided.
 2. Some patches are too complex for me to maintain by myself.

Please give your suggestion for dealing with my/similar problems.

Again maybe Professional type of support can include backports service?

 -- 
Regards,
Denis
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re:[fpc-pascal] Commercial support for Lazarus/FPC

[denisgolovan]

> > Same for Lazarus, although the numbering is different.
> > There is always a svn branch "fixes", while the svn "trunk" is the
> > development version. The fixes receives only bug fixes.
> > The release was 0.9.30. The development version was 0.9.31. Then came
> > several minor releases 0.9.30.2,3,4,5 with fixes.
> > Next version is 1.0 (fixes branch), development has version 1.1 (trunk).
> > 
> > Mattias

I know about those branches.
But still, I'd like to know more about commercial support.
Could you present some information about services behind it?

Not everything is backported and unfortunately fpc trunk sometimes not too 
stable.
Especially when using templates/generics and interfaces.

Moreover, I'd like to understand the terms of support for components which are 
part of FPC and Lazarus.

 -- 
Regards,
Denis
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Complex circular references

[denisgolovan]

Hi all

Now and again, I am trying to debug complex circular references.
By complex circular references I mean those which are produced by cyclic graphs 
of units, not simple one unit uses another and that uses the first one.

Unfortunately, currently fpc just shows that some circular references exist 
between units.
I wonder, is it possible to receive some more detailed information on those 
graphs?

 -- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re:[fpc-pascal] Complex circular references

[denisgolovan]

> PasDoc can produce 'dot' files of unit dependencies. (No idea if it will
> handle circular refs though). GraphViz can then be used to produce
> images based on the 'dot' files. I gave up with it because it did not
> parse the implementaion sections, but you won't be needing that for unit
> dependences. (I was hoping for a full class heirachy diagram).
> 
> http://pasdoc.sipsolutions.net/
> 
> Regards,
> Peter

Hm.
Dot files should the ideal solution.
Thanks a lot for the hint.

 -- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Registers in loops

[denisgolovan]

Hi all

Recently I discovered that fpc refuses to use registers in my loops even with 
optimization turned on (-O1,-O3 used).
I tested using both Linux x86 and Windows x64 version.

The results are basically the same.
The compiler just uses stack variables.

I've also included naive asm version of the same loop just to see the 
comparison.
All tests were done using EpikTimer.

==
Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz
Sandy Bridge-DT XE
Microsoft Windows XP Professional x64 Edition Build 3790
Free Pascal Compiler version 2.7.1 [2012/08/25] for x86_64
Result:
  
asm 0.0256358138703286 sec
for downto 0.193564002384441 sec
for to 0.177300077002942 sec
repeat 0.158137833298043 sec
while 0.156996773175159 sec

Intel(R) Core(TM)2 CPU 6600  @ 2.40GHz
Linux x86
Free Pascal Compiler version 2.7.1 [2012/11/17] for i386
Result:

asm 0.049642 sec
for downto 0.322694 sec
for to 0.312163 sec
repeat 0.298781 sec
while 0.298575 sec
==

You can easily see that asm version is about 10 times faster.
Is this something that can be fixed?

P.S. A full test source + assembler listings are attached.

 -- 
Regards,
Denis Golovan

loop-test.tar.gz
Description: GNU Zip compressed data
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re:[fpc-pascal] Registers in loops

[denisgolovan]

> Indeed, adding inline assembler to a routine disables many
> optimizations.
> 
> Jonas

Hm. 
Yeap. Looks like I completely missed the point :)
Thanks for the explanation.

 -- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Bitpacked dynamic array support

[denisgolovan]

Hi guys

It looks like currently FPC does not support dynamic bitpacked arrays.
I wonder how much work it will take to make support for it?

For some things, it's a really useful functionality.

 -- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re:[fpc-pascal] Bitpacked dynamic array support

[denisgolovan]

Hi Flávio

> You can use sets or TBits. Unless you mean packed arrays of byte or
> word, etc. In this case you just declare "myvar: packed array of
> byte".
> 
> -Flávio

I meant bitpacked arrays of boolean. That's when boolean occupies only one bit 
in memory.
Yes, I can use TBits, but unfortunately for operation that I care about it's 
not an option.

I attached the benchmark with numbers a sequential reading in a loop.
All in all TBits performance is really low. Currently it's about 150 times 
lower than QWord reading (near optimal on my machine)

Read from memory Array 100 elements
Read Byte0.004380 sek   Speed,MB/sec =   217.73
Read Word0.002950 sek   Speed,MB/sec =   646.56
Read DWord   0.004550 sek   Speed,MB/sec =   838.40
Read QWord   0.003943 sek   Speed,MB/sec =  1934.92
Read bitpacked   0.002745 sek   Speed,MB/sec =43.43
Read TBits   0.009329 sek   Speed,MB/sec =12.78 (!!!)

Test program attached.

 -- 
Regards,
Denis Golovan

testbits.tar.gz
Description: GNU Zip compressed data
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] FPC build fails

[denisgolovan]

Hi all

I experience some strange issue, which I happen to find accidentally.
When I try to build fpc using "make -B all" (executing in fpc sources root), it 
crashes with following error.

$ make -B all
/bin/mkdir -p x86_64/units/x86_64-linux
/usr/local/lib64/fpc/source/compiler/ppc3 -Ur -Xs -O2 -n -Fux86_64 -Fusystems 
-Fu/usr/local/lib64/fpc/source/rtl/units/x86_64-linux -Fix86_64 -FE. 
-FUx86_64/units/x86_64-linux -Cg -dRELEASE -dx86_64 -dGDB -dBROWSERLOG -Fux86 
-Sew -Owdevirtcalls,optvmts -Fw/usr/local/lib64/fpc/source/compiler/pp1.wpo 
-OWdevirtcalls,optvmts -FW/usr/local/lib64/fpc/source/compiler/pp2.wpo -dx86_64 
-dGDB -dBROWSERLOG -Fux86 -Sew -FE. utils/msg2inc.pp
/usr/bin/ld: warning: ./link.res contains output sections; did you forget -T?
/usr/local/lib64/fpc/source/rtl/units/x86_64-linux/system.o: In function 
`SYSTEM$_$TINTERFACEDOBJECT_$__$$__RELEASE$$LONGINT':
system.pp:(.text+0x10a3f): undefined reference to 
`SYSUTILS$_$TMULTIREADEXCLUSIVEWRITESYNCHRONIZER_$__$$_DESTROY'
msg2inc.pp(823,1) Error: Error while linking
msg2inc.pp(823,1) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted

It looks like there is some problem with makefiles as "make all" (without -B) 
works perfect.
Can it be reported as a bug?

P.S. Tested under Linux x64 using svn rev.23629

 -- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] LuaJIT 2 crashes under FPC+Win64. SEH issue?

[denisgolovan]

Hi all

Currently I am trying to make work attached code under Win64.
It uses LuaJIT 2 as drop-in replacement to Lua.

The code works fine under Linux32, Linux64, Win32, but not under Win64.
Under Win64 it crashes with unhandled exception like following:

An unhandled exception occurred at $77D67D9D:
EControlC: Control-C hit
  $77D67D9D

The same dll works fine under gcc/msvc complied project (luajit.exe interpreter 
which comes in box).

The idea of the attached code is following:
- try to calculate _invalid_ Lua code
- return Lua error (not exception).

The problem seems to have something to do with exception handling under Win64 
as LuaJIT 2 using native exceptions in its dll.
But it does not mean that C exceptions should be catched by FPC.  I understand 
that's not possible.
lua_pcall should handle those internally (like under Linux64).

It looks like some issue in FPC prevents LuaJIT catch its own exception under 
Win64.

P.S. Tested under FPC svn rev. 23910
P.P.S. You can use 
https://github.com/malkia/ufo/blob/master/bin/Windows/x64/luajit.dll LuaJIT 
build under Win64. Just rename it to lua5.1.dll to comply with lua.pas.

-- 
Regards,
Denis Golovanprogram project1;

{$mode objfpc}{$H+}
{$apptype console}

uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  {$IFDEF WINDOWS}
  Windows,
  {$ENDIF}
  sysutils,
  Classes
  { you can add units after this },
  
  lua,
  lauxlib
  ;

var L : Plua_State;
  LibName, script, r:string;
  errCode:Integer;
begin
  L := lua_open;
  LibName:='main';

  Script:='do return 1 + nil end';
  luaL_loadbuffer(L, PChar(Script), Length(Script), PChar(LibName));

  errCode:=lua_pcall(L, 0, LUA_MULTRET, 0); // << crashes here under Win64
  r := string(lua_tostring(l, -1));
  WriteLn(r);

  lua_close(l);
end.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: LuaJIT 2 crashes under FPC+Win64. SEH issue?

[denisgolovan]

Thanks a ton.
Building FPC with -dTEST_WIN64_SEH makes the trick!

02.03.2013, 14:47, "Reinier Olislagers" :
> On 2-3-2013 11:42, denisgolovan wrote:

> Yep, it seems like issue is exception handling (similar to issue
> http://bugs.freepascal.org/view.php?id=21581
> etc)
> Try compiling FPC with -dTEST_WIN64_SEH and try again...
>
> To the devs: any news about Win64 SEH code progress?
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Stack traces under Win64

[denisgolovan]

Hi all

I am trying to get stack traces for Win64 for exception, but BackTraceStrFunc 
still returns only hex representation.
My stack dumper is called via ExceptProc global variable.
Basically the procedure dumping exception stack follows below.

procedure TLogger.DumpExceptionBackTrace;
var
  FrameNumber,
  FrameCount   : longint;
  Frames   : PPointer;
begin
  if RaiseList=nil then
exit;
  Log(BackTraceStrFunc(RaiseList^.Addr));
  FrameCount:=RaiseList^.Framecount;
  Frames:=RaiseList^.Frames;
  for FrameNumber := 0 to FrameCount-1 do
Log(BackTraceStrFunc(Frames[FrameNumber]));
end;

Some info:
Actually I am doing cross-compilation from Linux x64 if it matters.
Linux version of the same application works fine.
I added both -gh and -gl parameters for compiler.

Am I doing something wrong?
Should I force the compiler to save debug info in some specific format on Win64?
Please comment.

 -- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] fpc does not invoke correct compiler

[denisgolovan]

Hi all

I experience inconsistency using fpc wrapper. 
See below.

When I invoke fpc using command line "fpc -Px86_64 ..." it correctly executes 
cross-compiler (ppcrossx64) under Linux 32 bit.
But if I try to push -Px86_64 into a separate file (opts.cfg) and run with "fpc 
@opts.cfg" it just executes native ppc386.

It looks like a bug to me.

 -- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re:[fpc-pascal] fpc does not invoke correct compiler

[denisgolovan]

Ok, I see.
Thanks for the explanation.

 Regards, Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

[fpc-pascal] Compiled resource file search path

[denisgolovan]

Hi

Could anybody give a hint on which fpc option to use to force compiler search 
.res files in some directory?
I've added -vt switch and it shows that the only file name being searched is in 
the same directory of referring unit.

It looks like search paths for res files are not implemented at all.
Am I correct? If yes, could it be fixed?  

 -- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Compiled resource file search path

[denisgolovan]

> You can use full/relative path for resources: {$R /path/to/resource/file} or
> {$R ../relative/resource/file}

Yes. I can.
The problem is that my .res files are not always in the same directory.
My build scripts use separate dirs for every arch-os-debug combination.

Now the question to the compiler developers - will you accept my patch if I 
make .res to be searched in unit output directory (-FU)? 

 -- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Compiled resource file search path

[denisgolovan]

Hi

Fortunately I don't use Windows when doing development for Windows :)
Cross-compiling under Linux is way better.

BR,
Denis
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] fpc build breaks since 26398

[denisgolovan]

Hi

Looks like since 26398 rev. fpc cannot be built.
It fails with following when running "make all". 

classes.pp(56) Warning: Implicit uses of Variants unit
Fatal: Can't find unit variants used by Classes
Fatal: Compilation aborted

Any hints to resolve?

P.S. I am under Linux, svn rev. 26427

 -- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fpc build breaks since 26398

[denisgolovan]

> 
> fpc trunk 26427 compiles here under Linux 64bit with fpc 2.6.2.
> 
> Mattias

Hi Mattias

Even though it currently works, I believe at least Makefile.fpc in rtl/linux 
directory is not updated.
It still assumes varutils.pp, variants.pp in old places.
You can try to look at my roughly made patch attached.

Please fix.

 -- 
Regards,
Denis Golovandiff --git a/rtl/linux/Makefile.fpc b/rtl/linux/Makefile.fpc
index 23ca2b6..8586d78 100644
--- a/rtl/linux/Makefile.fpc
+++ b/rtl/linux/Makefile.fpc
@@ -16,7 +16,7 @@ units=$(SYSTEMUNIT) fpintres $(SYSINIT_UNITS) \
   charset cpall buildcollations character unixcp getopts \
   errors  ipc serial terminfo dl dynlibs \
   types sysconst fpwidestring \
-  cthreads classes fgl strutils rtlconsts dos  cwstring fpcylix clocale
+  cthreads classes variants fgl strutils rtlconsts dos  cwstring fpcylix clocale
 implicitunits=exeinfo \
   cp1250 cp1251 cp1252 cp1253 cp1254 cp1255 cp1256 cp1257 cp1258 \
   cp437 cp646 cp850 cp856 cp866 cp874 cp932 cp936 cp949 cp950 cp8859_1 cp8859_5 \
@@ -40,8 +40,8 @@ fpcdir=../..
 target=linux
 
 [compiler]
-includedir=$(INC) $(PROCINC) $(UNIXINC) $(ARCH)
-sourcedir=$(INC) $(PROCINC) $(UNIXINC) $(ARCH) $(COMMON)
+includedir=$(INC) $(PROCINC) $(UNIXINC) $(ARCH) $(VARINC)
+sourcedir=$(INC) $(PROCINC) $(UNIXINC) $(VARINC) $(ARCH) $(COMMON)
 targetdir=.
 
 [shared]
@@ -58,6 +58,8 @@ INC=$(RTL)/inc
 COMMON=$(RTL)/common
 PROCINC=$(RTL)/$(ARCH)
 UNIXINC=$(RTL)/unix
+VARINC=../../packages/rtl-objpas/src/inc
+RTLOBJPAS=../../packages/rtl-objpas/src/unix
 
 UNITPREFIX=rtl
 
@@ -288,7 +290,7 @@ sysutils$(PPUEXT) : $(UNIXINC)/sysutils.pp $(wildcard $(OBJPASDIR)/sysutils/*.in
 $(COMPILER) -Fi$(OBJPASDIR)/sysutils $(UNIXINC)/sysutils.pp
 
 classes$(PPUEXT) : $(UNIXINC)/classes.pp $(wildcard $(OBJPASDIR)/classes/*.inc) \
-   sysutils$(PPUEXT) typinfo$(PPUEXT) rtlconsts$(PPUEXT) fgl$(PPUEXT)
+   variants$(PPUEXT) sysutils$(PPUEXT) typinfo$(PPUEXT) rtlconsts$(PPUEXT) fgl$(PPUEXT)
 $(COMPILER) -Fi$(OBJPASDIR)/classes $(UNIXINC)/classes.pp
 
 typinfo$(PPUEXT): $(OBJPASDIR)/typinfo.pp objpas$(PPUEXT) sysutils$(PPUEXT) rtlconsts$(PPUEXT)
@@ -304,12 +306,12 @@ math$(PPUEXT): $(OBJPASDIR)/math.pp objpas$(PPUEXT) sysutils$(PPUEXT)
 gettext$(PPUEXT): $(OBJPASDIR)/gettext.pp objpas$(PPUEXT) sysutils$(PPUEXT)
 $(COMPILER) $(OBJPASDIR)/gettext.pp
 
-varutils$(PPUEXT) : $(OBJPASDIR)/cvarutil.inc $(OBJPASDIR)/varutils.inc \
-$(OBJPASDIR)/varutilh.inc $(UNIXINC)/varutils.pp sysutils$(PPUEXT)
-$(COMPILER) -I$(OBJPASDIR) $(UNIXINC)/varutils.pp
+varutils$(PPUEXT) : $(VARINC)/cvarutil.inc $(VARINC)/varutils.inc \
+$(VARINC)/varutilh.inc $(UNIXINC)/varutils.pp sysutils$(PPUEXT)
+$(COMPILER) -I$(OBJPASDIR) -I$(VARINC) $(RTLOBJPAS)/varutils.pp
 
-variants$(PPUEXT) : $(INC)/variants.pp sysutils$(PPUEXT) sysconst$(PPUEXT) varutils$(PPUEXT) typinfo$(PPUEXT) rtlconsts$(PPUEXT)
-$(COMPILER) -Fi$(INC) $(INC)/variants.pp
+variants$(PPUEXT) : $(VARINC)/variants.pp sysutils$(PPUEXT) sysconst$(PPUEXT) varutils$(PPUEXT) typinfo$(PPUEXT) rtlconsts$(PPUEXT)
+$(COMPILER) -Fi$(INC) $(VARINC)/variants.pp
 
 fmtbcd$(PPUEXT) : $(OBJPASDIR)/fmtbcd.pp objpas$(PPUEXT) sysutils$(PPUEXT) variants$(PPUEXT) classes$(PPUEXT) system$(PPUEXT)
 $(COMPILER) $(OBJPASDIR)/fmtbcd.pp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fpc build breaks since 26398

[denisgolovan]

> This patch is totally, totally wrong. variants and varutils are no longer
> part of the RTL, and this patch tries to reinstate them.
> 
> It should simply work as is. Yes, there are some old dependencies left in
> the old makefile.fpc, but that doesn't matter.
> 
> Something else in your setup is wrong, and I suggest you look for it.

Yes. I found a problem.
It works now.
It's just "old" dependencies seem weird.

 -- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Find/open files in search paths

[denisgolovan]

Hi all

Does anybody know if Lazarus IDE has something similar to View units (Ctrl+F12) 
tool, but searching in all search paths defined in project settings?
It would allow to open modules much quicker than using standard Open file 
dialog.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Find/open files in search paths - Exuberant CTags?

[denisgolovan]

> On Mon, Jul 21, 2014 at 01:15:03AM -0300, Flávio Etrusco wrote:
 
> Is there any thought to someone extending Exuberant CTags
> to handle innovations in Pascal since Knuth? This CTags
> program has a Pascal mode that handles old-style Turbo
> Pascal source with procedural code reasonably well, but
> falls flat with object oriented code once dot notation is
> used. The advantage of Exuberant CTags is that then
> arbitrary programmer text editors like Vim can browse
> source code in the language almost as seamlessly as a
> dedicated IDE environment like Lazarus.
 
In case you are interested.
I did something similar back in 2009 as a small OSS project called JediTag.
http://jeditag.sourceforge.net/

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Heap manager tuning

[denisgolovan]

Hi all

I am trying to debug an issue that seems to be related to FPC heap manager.
Test machine - Linux x64.

It looks like really large memory "overhead" compared to cmem manager.
Test load profile - 50 heavy objects with around 25 large (1Mb - 10Mb) dynamic 
arrays each.
Those arrays are created in threads.

That allocation takes 10Gb+ under FPC heap manager. Further allocation becomes 
hardly possible (I have 16Gb on-board).
Meanwhile, cmem allocates around 3Gb. So I can operate >3 times more object 
set. 

I am pretty sure I don't have any memory leaks (heaptr is enabled all the time).

Any suggestions?
I am willing to sacrifice some allocation performance to decrease total memory 
consumption if it is necessary. 

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Heap manager tuning

[denisgolovan]

> On 09/08/14 23:01, denisgolovan wrote:
> 
> Try avoiding growing memory blocks small amounts at a time via
> reallocmem or setlength, and instead grow them in bigger chuncks. This
> will both increase the performance of your program and reduce the
> internal memory fragmentation.
> 
> Jonas

I don't have that allocation pattern here. Just a lot of large arrays 
allocating/deallocating (including local arrays for temporary results).
Any Java-like knobs to play with? :)

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Linux x64 linking error (FPC_ABSMASK_SINGLE)

[denisgolovan]

> How can I fix it? Should I pass -fPIC argument (and how to do this)?

AFAIK, PIC code generation is turn on by default.
Are you sure you don't have an opposite problem?
Sometimes when you have asm code written with hard-coded offsets you can get a 
module which can't be PIC-compiled.

See fpc -h params for _disabling_ PIC code generation.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] fgl.TFPGMap / operator not overloaded for object types

[denisgolovan]

Hi all

I am wondering if somebody created a bug request for the problem described in
http://lists.freepascal.org/fpc-pascal/2011-January/028020.html ?

If not I'd like report it :)
I am asking because I stumbled across the same issue under fpc 3.1.1 (rev.30041)

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fgl.TFPGMap / operator not overloaded for object types

[denisgolovan]

> Alternatively you can use THashMap from Generics.Collections -> this 
> implementation don't need any operators overloading, will work with most of 
> FreePascal types and it is much, much faster :)

Yes. I saw your library.
Looks promising, but I am a bit concerned about amount of bugs related to this 
one.
You pushed fpc generics straight to the edge :)

BTW, could you upload it to GitHub to be able to pull new changes easier?
It looks like it will be a long way to official FPC package.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fgl.TFPGMap / operator not overloaded for object types

[denisgolovan]

> https://github.com/dathox/generics.collections
 
  Thanks. Git makes life easier.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Lazarus smartlinking

[denisgolovan]

Hi all

I am trying to get smartlinking working, but it seems a bit harder than I 
expected. I am interested in both Linux and Windows arches.
I was able to build fpc using "RELEASE=1 CREATESMART=1 LINKSMART=1" make flags.
So far so good.

However, when I tried building Lazarus with the same make flags, it just fails 
early with:
(3104) Compiling fcllaz.pas
Fatal: (10022) Can't find unit process used by RegisterFC

I found out it's related to RELEASE=1 flag. Looks like recent Lazarus cannot be 
build with RELEASE=1 at all (-n is passed and fpc can no longer find its own 
units).

I removing RELEASE=1 and leaving CREATESMART=1 LINKSMART=1, but it looks like 
makefiles pass -g -gl flags to compiler and Linux compiler does not like dwarf 
debug info together with smartlinking. 

Can somebody give a hint on a proper build sequence for Lazarus?

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] [PATCH] Addition of OnNotify event on "TFPGObjectList" and "TFPGList" triggered on the insert, delete and extract methods.

[denisgolovan]

Hi That always keeps me wondering - why neither FPC, no any other mainstream static-type language implements specialization based not only on types, but on compile-time constants as well? I mean something like   TGenericList = class    ...  end; procedure TGenericList.Delete(index:integer);begin  if (nnNotifyDelete in options) and Assigned(FOnDelete) then FOnDelete(...);  end;end; // usagetype  TMyList = specialize TGenericList; ... that "if (nnNotifyDelete in options) " condition will optimized out by compiler if options lack corresponding enum constant.Of course, FOnDelete property should be omitted as well in ideal case. That might require something like "static if" in D. I've done that trick for ages using m4 preprocessor and it works really good, why it's still not supported natively by compilers themselves? 20.02.2016, 02:05, "Sven Barth" :There's no need for a sample. This degradation is the whole reason why the non-generic classes TFPObjectList and TFPList exist compared to TObjectList and TList which do have notifications.Regards, Sven,___fpc-pascal maillist - fpc-pascal@lists.freepascal.orghttp://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal  -- Regards,Denis Golovan ___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] [PATCH] Addition of OnNotify event on "TFPGObjectList" and "TFPGList" triggered on the insert, delete and extract methods.

[denisgolovan]

20.02.2016, 02:05, "Sven Barth" :
> There's no need for a sample. This degradation is the whole reason why the 
> non-generic classes TFPObjectList and TFPList exist compared to TObjectList 
> and TList which do have notifications.
>
> Regards,
> Sven

/ My previous mail appeared to be in html format. Sorry for that.

Hi

That always keeps me wondering - why neither FPC, no any other mainstream 
static-type language implements specialization based not only on types, but on 
compile-time constants as well?

I mean something like

  TGenericList = class
    ...
  end;

procedure TGenericList.Delete(index:integer);
begin
  if (nnNotifyDelete in options) and Assigned(FOnDelete) then
    FOnDelete(...);
  end;
end;

// usage
type
  TMyList = specialize TGenericList;

... that "if (nnNotifyDelete in options) " condition will optimized out by 
compiler if options lack corresponding enum constant.
Of course, FOnDelete property should be omitted as well in ideal case. That 
might require something like "static if" in D.

I've done that trick for ages using m4 preprocessor and it works really good, 
why it's still not supported natively by compilers themselves?

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] [PATCH] Addition of OnNotify event on "TFPGObjectList" and "TFPGList" triggered on the insert, delete and extract methods.

[denisgolovan]

21.02.2016, 02:59, "Sven Barth" :
> Then you don't consider C++ as mainstream, do you?
>
> Regards,
> Sven

Hm. Looks like C++ actually does that and that's great.
Unfortunately I stopped using C++ for large projects about 12 years ago, so my 
C++ template knowledge must be too old :)  

> I had thought about this some time ago and then found a reason why I wouldn't 
> do it... Now if I'd only remember that reason -.-
Yes, it's interesting to see why. It's wildly useful and gives a lot of power.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Smart Link definition ?

[denisgolovan]

Sorry, for the question, but is it really working for FPC+Lazarus?
I mean FPC with smart-linking from trunk.

Last time I tried, I could not complete full FPC and Lazarus rebuild.

BR,
Denis

10.10.2016, 18:03, "Jonas Maebe" :
> On 10/10/16 16:25, fredvs wrote:
>>  Does somebody know if smart-link (-XX) is done by the compiler (fpc) or by
>>  the linker (ld) ?
>
> It's done by the linker, but it is based on how the compiler
> structures/annotates the code and data when you compile with -CX.
>
> Jonas
> ___
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] New Feature: "Management Operators"

[denisgolovan]

  08.11.2016, 11:48, "Maciej Izak" : anyway probably I have no motivation anymore to continuing my work. That's unfortunate for the community, IMHO.Personally, I appreciate your idea of management operators. -- Regards,Denis Golovan 
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] New Feature: 'Management Operators'

[denisgolovan]

Yes. Mostly.

More general advantage is that this feature might finally bring FreePascal back 
into league of languages having nice support for value types (as opposed to OOP 
atrocities). 
To put it in other words, functional style might become both feasible and 
sufficiently fast in FreePascal.

IMHO, that is one of the most valuable additions to the language in years.

BR,
Denis


09.11.2016, 08:29, "Lars" :
> On Tue, November 8, 2016 1:47 am, Maciej Izak wrote:
>>  2016-11-07 22:24 GMT+01:00 African Wild Dog :
>>
>>>  I saw on the bug tracker a patch submission by Maciej Izak about the
>>>  feature "Management Operators".
>>>
>>>  This feature is related to Automatic Reference Counting?
>>
>>  Yes. We have a working ARC objects
>
> Can someone briefly explain what this means for code?
>
> Is this related to garbage collected heap allocated objects and similar,
> without using a garbage collector but using reference counting?
>
> Sorry if I am way off base, I just have no idea what it is...
> ___
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Other linkers support

[denisgolovan]

Hi all

Could anybody provide some information on support for LLD and/or gold linker?
Linker phase becomes a bottleneck for me. 

Last time I tried, ld scripts generated by fpc caused some errors on gold 
linker.
Are there any plans for support anything else besides standard ld?

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Other linkers support

[denisgolovan]

Ok.
See http://bugs.freepascal.org/view.php?id=30956 then.


18.11.2016, 13:00, "Jonas Maebe" :
> denisgolovan wrote on Fri, 18 Nov 2016:
>
>>  Last time I tried, ld scripts generated by fpc caused some errors on
>>  gold linker.
>>  Are there any plans for support anything else besides standard ld?
>
> Gold and lld are supposed to be compatible with GNU ld (bar ancient
> stuff that is no longer relevant current platforms). If you get
> errors, please report bugs against these other linkers.
>
> If you are under Linux, make sure to first check with FPC trunk
> though, because the "did you forget -T" warnings from ld have been
> fixed there, and these warnings indicated that FPC was relying on
> undefined behaviour of the linker.
>
> Jonas
> ___
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Other linkers support

[denisgolovan]

I've received an answer to my reported bug
https://sourceware.org/bugzilla/show_bug.cgi?id=20870

Could anyone from FPC team comment anything there?


19.11.2016, 14:53, "Jonas Maebe" :
> denisgolovan wrote:
>
>>  18.11.2016, 13:00, "Jonas Maebe" :
>>>  denisgolovan wrote on Fri, 18 Nov 2016:
>>>
>>>>   Last time I tried, ld scripts generated by fpc caused some errors on
>>>>   gold linker.
>>>>   Are there any plans for support anything else besides standard ld?
>>>  Gold and lld are supposed to be compatible with GNU ld (bar ancient
>>>  stuff that is no longer relevant current platforms). If you get
>>>  errors, please report bugs against these other linkers.
>>
>>  Ok.
>>  See http://bugs.freepascal.org/view.php?id=30956 then.
>
> With "report a bug against these other linkers" I meant "report a bug to
> the project that develops those linkers". The reason is that they are
> supposed to be drop-in replacements for GNU/BFD ld, so any
> incompatibility is a bug/missing feature in their implementation.
>
> Jonas
> ___
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] List of integers? Any class available in RTL or FCL to help?

[denisgolovan]

 05.12.2016, 13:35, "Sven Barth" :I really don't get why some people think of generics as complex -.- Exactly for the cited reason. See below. > Using plain old arrays, requires reinventing the wheel because you end up> writing duplicate functions for each array type (array of string) instead> of a general purpose algorithm for many types.. It's not possible to get uniform interfaces that would play nice with algorithms.Try writing a _single_ function for sorting static arrays, dynamic arrays,open arrays, generic containers(T*List * all value types).The standard recipe is re-implement everything from scratch over and over again.Even now, when we have generic functions - I am forced to specialize them by hand! Even C# got it right...Another issue is that some special functions are considered "special" - you cannot overload them (SetLength, Copy, ...).Yet another thing is that arrays are nice value-pretending types (refcouting), but most generics are classes!We desperately need http://bugs.freepascal.org/view.php?id=30687 to get record based generics value types back to the language. Basically it's all about combinatorics when combining functions.Either compiler does it for you, or you are forced to do it manually instead. To sum up, generics in current implementation add too little while exploding combinatorial variety of algorithms. -- Regards,Denis Golovan ___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] List of integers? Any class available in RTL or FCL to help?

[denisgolovan]

05.12.2016, 16:38, "Sven Barth" :Again: I don't see why anyone thinks of generics as complex. Your mail did not answer that in any way. Hm. I tried :)I can put it another way.No language element exists on its own.And generics are complex because they lead to more accidental complexity for reasons given earlier. I guess the analogy with bureaucratic papers is valid here.Too much hassle (new strange and verbose syntax, combination/overload rules are non-obvious) with so low added value.It comes that using any sufficiently advanced text preprocessor (like m4) gives much more power _without_ added complexity of generics. For OOP-only, it may be a step forward, but for functional language it's quite a controversy. -- Regards,Denis Golovan ___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Management Operators

[denisgolovan]

Thanks a lot.I guess http://bugs.freepascal.org/view.php?id=30687 should be closed now :) -- Regards,Denis Golovan 
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Coroutines and VirtualAlloc

[denisgolovan]

20.04.2017, 11:43, "Ryan Joseph" :
>>  On Apr 20, 2017, at 3:01 PM, Bernd Mueller  wrote:
>>
>>  it would be really nice to have coroutines for the embedded targets like 
>> AVR and ARM.
>
> What are people using this for btw? Personally I wanted them to solve some 
> problems in game programming where I lots of nested loops that need to be 
> synched with a main loop and can’t block.

It is especially favorable for game development.
All processes/objects which live across several rendering frames and have any 
state are greatly simplified by coroutines.
e.g. living entities, animations, any game triggers, any finite state machines, 
etc. 
Proper implemented coroutines support thousands of instances. 
With proper (read "mostly functional"/non-shared data) approach coroutines 
might also be calculated within real threads in parallel.

Another example is network-related code (both client and server code).
Break your huge finite state machines into pipeline stages via coroutines and 
it gets pretty modular, extensive and simple to reason about.

To say to generally, had we had coroutines in first place, no OOP crap would be 
necessary :)
At least in game development.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] machine readable grammar of object pascal?

[denisgolovan]

> On 2017-05-03 00:53, Marc Santhoff wrote:
>>  Does such grammar exist?

Well, it depends on what you are trying to solve.
If you want to parse Pascal using FPC - that's one way. 
If you want to get some king of AST using any available [command-line] tools - 
that's another one.

Talking about latter - I would take LPEG (Lua+PEG) and create a parser myself. 
It comes quite simple and intuitive (contrary to LL,LR,LALR,...).
Most of Object Pascal is done right (minus sets/open arrays), so it can be 
parsed statically pretty easily.
See http://lua-users.org/wiki/LpegRecipes for inspiration.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] GLM library alternative?

[denisgolovan]

28.05.2017, 09:55, "Benjamin Rosseaux" : I've put some units of my still work-in-progress UE4-style SupraEngine on my root server, after I've read this mailing list thread =>  http://rootserver.rosseaux.net/stuff/supraengineunits/   Looks nice. Thanks for sharing.How about publishing it on Github with small readme to ease contributions? -- Regards,Denis Golovan 
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[denisgolovan]

Just my 50 cents.

Even though I avoid using debugger at all cost, 
I am willing to donate some money should someone start a crowd-funding effort 
to get "modern" debugging support in Lazarus.
That would definitely improve Lazarus/FPC public image.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[denisgolovan]

That's exactly what I mean - some (or major) part of public considers it a 
stopper for some reason :)

Sorry for hijacking the thread.


10.07.2017, 12:43, "Santiago A." :
> El 10/07/2017 a las 11:17, denisgolovan escribió:
> It is not a matter of public image, it's a matter of usability, a "must
> have", a stopper.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Food for thought - language string improvement

[denisgolovan]

Please do.

And to that hero who is willing to take the effort - please post a call for 
donation in a separate thread :)

10.07.2017, 13:06, "Michael Van Canneyt" :
> On Mon, 10 Jul 2017, denisgolovan wrote:
>
>>  That's exactly what I mean - some (or major) part of public considers it a 
>> stopper for some reason :)
>>
>>  Sorry for hijacking the thread.
>
> I can add it to the list of sponsored projects on the foundation page.
>
> Michael.
> ___
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Compiler debug build

[denisgolovan]

Hi all

Currently I am debugging a nasty shared memory bug.
More specifically it's related to memory allocator, though not directly.

More to the point - lack of backtraces is really tough - Lazarus debugger just 
shows one level. 
Upon some investigation I managed to get much more meaningful backtraces. 
However the only way to enable them which I found is manually editing root 
Makefile.fpc and removing all RELEASE directives (giving executing make DEBUG=1 
does not help) and compiler rebuild to avoid -O2 optimizations.

So the question is why it's so difficult to build fpc compiler/rtl in debug 
mode?
Is it possible to fix? Or maybe I miss some official way?

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Compiler debug build

[denisgolovan]

Thanks.That's exactly what I need.22.07.2017, 20:20, "Maciej Izak" :2017-07-22 19:05 GMT+02:00 denisgolovan <denisgolo...@yandex.ru>:So the question is why it's so difficult to build fpc compiler/rtl in debug mode?
Is it possible to fix? Or maybe I miss some official way?You don't need to edit Makefile.fpc. When I need debug info for rtl and packages I use this:make clean all LINKSMART=1  CREATESMART=1  DEBUG=1 OPTIMIZE=0  OPT="-gl -gw -godwarfsets -O-1" -- Best regards,Maciej Izak

,___fpc-pascal maillist  -  fpc-pascal@lists.freepascal.orghttp://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal-- Regards,Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] PAPI module for FreePascal

[denisgolovan]

Hi all

Does anybody know any module/binding for PAPI?
I mean some library for reading hardware performance counters under Linux.
Something similar to https://github.com/david-grs/geiger
It's quite simple to write it myself, but worth asking before re-inventing the 
wheel :)

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Again heaptrc dump interpretation

[denisgolovan]

Hi all

I am getting following dump after my application exits.

Heap dump by heaptrc unit
342662 memory blocks allocated : 7318105636/7319146560
342662 memory blocks freed : 7318105636/7319146560
0 unfreed memory blocks : 0
True heap size : 7276691456
True free heap : 1773152
Should be : 7276691456

Could somebody explain what "Should be" (7Gb here) is?
Is it some memory leak which is not tracked by heaptrc?

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Again heaptrc dump interpretation

[denisgolovan]

> IIUC, if these two do not match, you might have a memory leak... keep up also
> with your memory blocks allocated and freed...

Well. I feel something is wrong.
But how can it be? I mean all allocated blocks were freed.
I'd like to know for sure what that "Should be" means.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Operator overload resolution with arrays

[denisgolovan]

> Take the following simple declaration:
> 
> type
> TTriangleIndex = array[0..2] of Integer;
> TFacetList = specialize TFPGList;
> 
> operator = (A, B: TTriangleIndex): boolean;
> 
> This will not work:
> fgl.pp(948,50) Error: Operator is not overloaded: "TTriangleIndex" =
> "TTriangleIndex"

Hi, I believe https://bugs.freepascal.org/view.php?id=27690 is all about it.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Copy dynamic array

[denisgolovan]

A side note:

I am still wondering why there is no something like "Clone" function to make an 
independent copy of string/array/... ? It's used quite often in practice (as we 
don't have copy-on-write working in all circumstances).

BR,
Denis
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Copy dynamic array

[denisgolovan]

Well.

"Copy" works for arrays only.
Neither strings nor records work.
Tested in pretty old svn rev. 37656

//=
program project1;

{$mode objfpc}{$H+}

type
  TRec = record
s1:string;
i1:integer;
  end;

var S1,S2:string;
A1,A2:array of integer;
R1,R2:TRec;
begin
  A1:=[1,2,3];
  A2:=Copy(A1);
  A2[0]:=10;
  writeln(A1[0]);
  writeln(A2[0]);

  S1:='123';
  S2:=Copy(S1);

  R1.s1:='123';
  R1.i1:=1;
  R2:=Copy(R1);
end.
//===

BR,
Denis
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Copy dynamic array

[denisgolovan]

Yes. 
That's exactly why I gave that example.
Your method with Move will trigger segfault eventually, so the compiler support 
is required to handle it properly.

BR,
Denis
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Copy dynamic array

[denisgolovan]

Doing the same conceptual thing using different syntax does not seem right as 
generics, macros and other nice stuff become clumsy and too verbose.

See

//
program project1;
{$mode objfpc}

type
   TRec= record
  A:array of integer;
  S:string;
   end;

var R1,R2:TRec;
begin
   SetLength(R1.A, 3);
   R1.A[0]:=1;
   R1.A[1]:=2;
   R1.A[2]:=3;
   R1.S:='123';

   R2:=R1; // shallow copying <> full clone
   R2.A[0]:=10;
   R2.S[1]:='S';

   // does not work as expected (no copy-on-write/cloning)
   writeln(R1.A[0]); // prints 10
   writeln(R2.A[0]); // prints 10

   // works fine
   writeln(R1.S[1]); // prints 1
   writeln(R2.S[1]); // prints S
end.
//

BR,
Denis
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Copy dynamic array

[denisgolovan]

> What would the expected behavior be for pointers inside records? What if
> the record is actually a linked list? Or includes classes and objects?
> Do we run the constructor or no? If the record has file handles do we
> attempt to recreate their state? (perhaps running assign again, and
> crossing our fingers the file hasn't been deleted - which at least on
> Linux is definitely possible)

Well.
The answer is simple - value types (scalars, strings, records, variants, arrays 
of mentioned) are good functional citizens.
Cloning is well defined for them as compound value is also value. 

Should someone wants for add complexity (read OOP/pointers/classes and other 
crap) - use http://wiki.freepascal.org/management_operators#Copy at your own 
risk.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

[denisgolovan]

> By all means, please reconsider this, and leave me the choice to define the
> operators. If I want "+" for concatting, it is trivial to define it myself.
> I don't need the language to force that and eseentially destroy operator
> overloading for mathematical operations on dynamic arrays.

Same here.

The semantics for vector operations on arrays was thoroughly explored in vector 
languages (APL, A+, J, K, etc).
Doing per-element dyadic function application is the basis for it. Having 
proper operators overloads is crucial.

@Sven
Please reconsider "+" operator for arrays if your changes really forbid to 
overload operators for arrays now.

Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

[denisgolovan]

It's technically possible.

But for vector operations to be valid/consistent both of them should work the 
same way. That is perform arithmetic per-element addition. 

BTW, you first overload is not implemented properly. You need to clone "left"  
first and return it as a result.

BR,
Denis
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

[denisgolovan]

Yes, I strongly support removing that functionality in favor of user operator 
overloads or vector-compatible way.

Moreover, SSE/AVX vector extensions also should work per-element.
I mean those vectors as in https://bugs.freepascal.org/view.php?id=27870

BR,
Denis
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

[denisgolovan]

Yes, if you want destructive updates you need a special syntax for that.

I believe existing syntax is not suitable for destructive update, hence the 
error I mentioned.

BR,
Denis
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

[denisgolovan]

Having worked with APL for almost 6 years and continuing with Q/KDB, I would 
say APL syntax is much more readable than Perl 6. 

Though being able to modify language like that is really impressive.

BR,
Denis 
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

[denisgolovan]

> Horses for courses. I think the impressive thing about APL is that the
> necessary operations were worked out (and used for Blackboard
> demonstrations) /before/ it was converted into a computer language, and
> by and large weren't added to. However the functional nature of the
> language was vastly overrused, and students who thought they were being
> smart would on occasion find themselves with mainframe runtimes of
> /months/ because they'd created an enormous array instead of using a
> simple control structure.

Yes, sure. 
But things slowly change in compiler/interpreter world.
Now we have loop/streams fusion techniques and other devectorization tricks, so 
I think smart APL interpreter would be of real help here.
 
> Nod here to Vector Pascal as well. And as a bit of history, the first
> computer implementation of Iverson's notation was done at Stanford under
> the watchful eye of Niklaus Wirth.

Hm, I didn't know that. Thanks for sharing.
Looks like computer scientist community was really small those days.

Vector Pascal is much closer to our current discussion though :)

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Proper preprocessor?

[denisgolovan]

> C was designed from the ground up with preprocessing. Pascal, and most newly
> designed languages, do not have preprocessing built-in. For good reason.

Well. I can't agree.
C macros are bolted on :). It's too alien for main part of language. No respect 
to captured variables, no operator priorities, parsing is hard, etc.
On the other hand, recent language Rust has macros nicely integrated in 
language itself and they plan to extend them in 2.0 version.
D language also has mixins. Let alone Lisp-dynamics derivatives.
Those macros help a lot in intensive meta programming (read writing 
interpreters/compilers/introspection heavy applications) and reduce total line 
count considerably.

Generics are rather limited in that respect. 
At least some construction should exist to instantiate those generics.
e.g. to create several public structs, interfaces, free functions (possibly 
instancing generics) in one go.

My personal way of doing stuff like that is "m4 -> pas/inc" conversion and 
triggering them in makefiles. 
Robust incremental pre-processing is quite affordable for make + m4 combination 
as well.
Again Rust macros being something in between C defines and m4 in terms of power 
are really pragmatic at times.

> Some cans are better left unopened. Or pandora's box is better left
> closed... (if you prefer mythological references ;) )

Again, different design philosophies lead to different design decisions.
Better less amount of code + more automatic consistence leading to more cryptic 
code (have a look at APL/J/... implementation) OR lots of boilerplate + less 
consistence, but much more readable for non-experts? 
What about refactoring price in both scenarios? Open source projects have a 
variety of opinions on that.

But I generally support FreePascal team in avoiding features they personally 
don't extensively use :)

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Proper preprocessor?

[denisgolovan]

> Do you have examples here?

There are several use-cases I often see.

1. The task is to allow declaration of some container structure (vector, tree, 
etc.)
The mechanism to create it must have enough flexibility to define/parametrize 
at compile-time in one go:
- keys are integers in 0..N-1 only or any type supporting equality testing. 
  That user decision should influence container code and its manual code 
optimizations, e.g. special cases like indexing, appending/removing/etc.
- are keys always sorted? => influences insertion, search, etc.
- values are primitive types (not having destruction phase - just dealloc) or 
it should call Finalize/Free/"Assign nil" on destroying.
- if values are records - all accessors should return pointers instead to be 
able to modify fields without "read, modify, write" ceremonies.
- does structure generate events on insertion/deleting/etc? => influences event 
property declarations + actual code to trigger those
- what kind of interface user prefers for the container - class, record, 
interface with reference counting or any combination of those?
- all its generic functions like map, filter, destructive map, etc. should be 
overloaded functions existing both as structure methods and free form (globals 
with additional argument). Their argument should accept all kinds of callbacks 
- simple functions, methods ("of object" type), nested ("is nested") and 
possibly future "reference" (closure FPC does not support yet).
- grow strategy - user-defined, with given coefficient, etc.

... currently all above is generated using m4 producing entire FPC module. 
That's old times philosophy - structures amount is small, functions to work 
with them are numerous and coherently named. Something similar to C++ STL, but 
without exponential build times and more tailored to users' needs.

2. Meta declarations for global entities with names/ids/descriptions/etc. 
The mechanism to create it must have enough flexibility to define/parametrize 
at compile-time in one go:
- create Pascal native declarations as enums
- create Pascal functions to convert to/from strings/integers/etc
- create overloaded serialization functions for XML, streams, etc.
- create foreign code declaration (C, Lua, etc.)
- native Pascal foreign code marshalling (e.g. Pascal <-> Lua via Lua stack)

3. Dynamic libraries exports.
The mechanism to create it must have enough flexibility to define/parametrize 
at compile-time in one go:
- compile in Pascal "generics" / m4 templates to support other processes / 
languages
- exported functions should accessible via specific foreign import (e.g. it 
should generate corresponding header files for use in C/C++)

4. Published functions/classes/ into interpreted languages
- just declare which classes and their methods should be accessible e.g. from 
Lua and code should generated for make it happen.
- FFI import/export - declare functions / types / names - get boilerplate to 
make it happen.


That's more or less it. 
At least those I quickly gathered from real project.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Proper preprocessor?

[denisgolovan]

See below the function to convert dynamic value into string value inside 
interpreter project I am working at, something similar to *ToStr family in FPC.

It's generated by the macro which expands to corresponding branches for each 
value type. "$" prefixes are for passing macro arguments. "ident!" is "calling" 
other macros, but it's quite obvious I guess.

Last syntax expression is "application" of this macro resulting in actual 
function creating and immediate compilation by Rust compiler. 

macro_rules! to_string {
($($scalar:tt),*) => {
pub fn to_string(ast: &AST, interpreter: &Interpreter) -> AST {
match base_tp(ast.tp()) {
$(
$scalar => {
let aco=aco!($scalar, ast, Some(interpreter.alloc()));
let s=ato_str!(aco, aget!(aco, ast), interpreter);
new_string(&s, interpreter.alloc())
},
)*
$(
to_vec!($scalar) => {
let aco=aco!($scalar, ast, Some(interpreter.alloc()));
let v=ast.array::();
v.iter().map(|x| {
let s=ato_str!(aco, *x, interpreter);
new_string(&s, interpreter.alloc())
}).enlist(v.len(), interpreter.alloc())
}
)*
$(
to_deq!($scalar) => {
let aco=aco!($scalar, ast, Some(interpreter.alloc()));
let v=ast.vecdeq().head::();
v.iter().map(|x| {
let s=ato_str!(aco, *x, interpreter);
new_string(&s, interpreter.alloc())
}).enlist(v.len(), interpreter.alloc())
}
)*
x if is_nested(x) => atomic(ast, to_string, "to_string", 
interpreter),
VEC_CHAR => (*ast).clone(),

_ => except!(eval_err!("cast: nyi.")),
}
}
}
}
to_string!(
SC_BOOL,
SC_BYTE,
SC_SHORT,
SC_INT,
SC_MONTH,
SC_DATE,
SC_MINUTE,
SC_SECOND,
SC_TIME,
SC_LONG,
SC_TIMESTAMP,
SC_DATETIME,
SC_TIMESPAN,
SC_SINGLE,
SC_DOUBLE,
SC_ENUM,
SC_SYMBOL,
SC_GUID
);

All in all my rough estimate for macro efficiency ratio is something like 12x 
currently. That's about 12 times less code to type and support. YMMV, of course.

See 
https://danielkeep.github.io/tlborm/book/mbe-min-captures-and-expansion-redux.html
 for boring details on Rust macros.

BR,
Denis
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Constants in generics

[denisgolovan]

Does this trick also work for declaring arrays using "val"?

BR,
Denis
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Constants in generics

[denisgolovan]

Hi

Sorry for breaking in, but I'd like to know if this functionality supports 
specializing generic functions with const parameters?

BR,
Denis
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Constants in generics

[denisgolovan]

> Here’s my test which seems to be working.
> 
> program gc_procs;
> 
> generic procedure DoThis(msg:string = U);
> begin
> writeln(msg, ' ',sizeof(T), ' ', U);
> end;
> 
> begin
> specialize DoThis('hello world’); // prints "hello world 4 foo"
> specialize DoThis; // prints “foo 4 foo"
> end.

Thanks.
That's definitely a nice feature.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Implicit generic specializations

[denisgolovan]

Hi Ryan

That's definitely a nice feature.
Could you clarify and/or discuss with compiler devs the rules for function 
overloads?
Currently FPC seems a bit messy even without inferencing like that.


BR,
Denis
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Implicit generic specializations

[denisgolovan]

Hi Sven

> Where is it messy? O.o

See https://bugs.freepascal.org/view.php?id=28824
 
> Also the idea should be that a non-generic routine takes precedence.

Seems reasonable.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Candidate for crowd-funding

[denisgolovan]

Hi all

I decided to start a separate thread for asking about potential candidate for 
crowd-funding.

My personal wish-list is:
- support for array calculations / automatic loop parallelization via SSE, AVX, 
etc.
  Both static and dynamic arrays should supported. 
  Once implemented vector operations on arrays (ala APL) might be done using 
operator overloads.
- Custom/separate allocators for dynamic arrays (to avoid manually patching 
compiler). 
- Coroutines. Portable library or in-compiler support.
- Interprocedural optimizations (something akin to LTO)
- inline assembler function support
- proper macro language perhaps

Could someone comment if those goal are attractive to somebody else?
I mean both donators and potential "implementors".

BTW, is it possible to state the specific project when donating?

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Candidate for crowd-funding

[denisgolovan]

> I will leave the technical comments to the compiler developers.
> 
>> BTW, is it possible to state the specific project when donating?
> 
> Yes, if I recall correctly you can give a message when the paypal donate
> page appears. (just as you can state that you want to be in the hall of
> fame)

Ok. Thanks.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Candidate for crowd-funding

[denisgolovan]

>> - Custom/separate allocators for dynamic arrays (to avoid manually patching 
>> compiler).
> 
> Why do you need that?

Besides ordinary arrays I allocate/use arrays backed by mmaped files. 
Existing functions taking arrays as arguments mostly remain working 
transparently.
That's a huge win in code size and allow zero-copy scenarios.

Besides that, I am able provide special alignment for arrays. 
That also would be necessary to vector/SSE/AVX work.

>> - inline assembler function support
> 
> The main problem here is to model what registers an instruction uses and 
> modifies so that the register allocator of the surrounding function can take 
> that into account accordingly... Maybe as a first step we could allow in 
> lining for funcrions that have a register clause with the touched registers...
> But yes, in the long term this would definitely be nice.

Agree. Register clause will ease a lot of pain.
 
>> - proper macro language perhaps
> 
> No. We already rejected such an idea some months ago.

Ok. Looks like m4 will be my friend forever :)

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Constants in generics

[denisgolovan]

Hi, allCould someone confirm this functionality is merged into trunk? I mean constants in generics.29.11.2018, 05:24, "Ryan Joseph" : On Nov 29, 2018, at 5:15 AM, Sven Barth via fpc-pascal  wrote: Looks better. The next thing to nuke is the tgenericparamdef. The parameters stored in tdef.genericparas are the parameter symbols, so there should be no need for defs. If necessary some of the code in pgenutil (and related functions) will need to be changed from handling a list of defs to a list of syms.I added that extra type so that it would be compatible with genericdeflist. I don’t see how that can be removed. The const sym is pulled out in generate_specialization_phase2 and renamed (which I forget why already).So the tgenericparamdef is just a vessel to hold the constsym until generate_specialization_phase2? Either way removing it means breaking genericdeflist right?if typeparam.nodetype <> typen then  begin{ the typesym from paramdef will be added to the list in generate_specialization_phase2 }paramdef := tgenericparamdef.create(typeparam.resultdef,typeparam,constprettyname);genericdeflist.Add(paramdef);  endelse  beginconstprettyname := '';genericdeflist.Add(typeparam.resultdef);  end;from generate_specialization_phase2:for i:=0 to genericdef.genericparas.Count-1 do  beginsrsym:=tsym(genericdef.genericparas[i]);if not (sp_generic_para in srsym.symoptions) then  internalerror(2013092602);// note: ryan{ set the generic param name of the constsym of tgenericparamdef }typedef := tstoreddef(context.genericdeflist[i]);if typedef.typ = genericconstdef then  tgenericparamdef(typedef).typesym.realname := srsym.realname;generictypelist.add(srsym.realname,typedef.typesym);  end;Regards,Ryan Joseph___fpc-pascal maillist  -  fpc-pascal@lists.freepascal.orghttp://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pas…-- Regards,Denis Golovan___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Constants in generics

[denisgolovan]

Well, I'll wait then.That's definitely nice to have feature.02.01.2019, 16:33, "Sven Barth via fpc-pascal" :Am Mi., 2. Jan. 2019, 11:20 hat denisgolovan <denisgolo...@yandex.ru> geschrieben:Hi, allCould someone confirm this functionality is merged into trunk? I mean constants in generics.I can confirm that it is not integrated in trunk. Regards, Sven ___fpc-pascal maillist  -  fpc-pascal@lists.freepascal.orghttp://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pas…-- Regards,Denis Golovan___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Interface bug or some new feature

[denisgolovan]

Hi all

I've been using 3.1.1 compiler for a long time and now I am trying to upgrade 
to 3.3.1 from trunk.
However, I am stuck with some new behavior when using classes + interfaces.
I've managed to reproduce it in a small example which follows. 

Specifically 3.1.1 compiler compiles it and correctly prints "Double". 
3.3.1 compiler refuses to compile it at all.
Please comment if it's a bug or a new breaking feature.

//==
program project1;

{$mode objfpc}{$H+}

uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  Classes
  { you can add units after this };

type
  IIntf1 = interface
procedure P(i:Integer);
  end;

  TClass1 = class(TInterfacedObject, IIntf1)
procedure P(i:Integer);
  end;

  IIntf2 = interface(IIntf1)
procedure P(f:Double);
  end;

  TClass2 = class(TClass1, IIntf2) // Error: No matching implementation for 
interface method "P(LongInt);" found
procedure P(f:Double);
  end;

procedure TClass1.P(i:Integer);
begin
  WriteLn('Integer');
end;

procedure TClass2.P(f:Double);
begin
  WriteLn('Double');
end;

var v2:TClass2;
begin
  v2:=TClass2.Create;
  v2.P(0.0);
  v2.Free;
end.
//===


-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Interface bug or some new feature

[denisgolovan]

06.01.2019, 14:57, "Jonas Maebe" :
> http://wiki.freepascal.org/User_Changes_Trunk#Methods_implementing_interface_methods_and_overloads
>
> Jonas

Thanks, Jonas.
That was precisely the cause for my trouble.

-- 
Regards,
Denis Golovan

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

Re: [fpc-pascal] Interface bug or some new feature

[denisgolovan]

  06.01.2019, 15:00, "Sven Barth via fpc-pascal" : The default visibility for classes without $M+ is private. Thus TClass1.P is private. An interface implementation does not have access to private methods of a parent class. So you need to declare P as protected for this to work. Though to be fair in the specific example you gave I think that it should work as both are within the same unit. We'll need to check that...  Yes. That was another real issue in my project.However I managed to get it.Thanks for quick help. -- Regards,Denis Golovan ___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] inlining functions

[denisgolovan]

07.01.2019, 00:45, "Jonas Maebe" :
> Not besides breaking your dependency cycles.

Sorry, but for necro-posting, but shouldn't WPO is supposed to help to inline 
functions as well?

-- 
Regards,
Denis Golovan

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

Re: [fpc-pascal] inlining functions

[denisgolovan]

12.01.2019, 14:53, "Jonas Maebe" :
> Not at this time (unless you use the LLVM backend). 

Could you give some hints on how to enable WPO/LTO under LLVM backend?
http://wiki.freepascal.org/LLVM does not seem to mention anything on that.

> However, what you actually can do, is manually recompile all units of your 
> program
> multiple times. While this won't help with inline functions called
> before they are parsed in those same units, it will allow inlining of
> function bodies in other units that were not available during the first
> compilation due to dependency cycles.

Eh.
It does not look too practical, right?
Unless there is some magical receipt for that :)

-- 
Regards,
Denis Golovan

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

Re: [fpc-pascal] inlining functions

[denisgolovan]

12.01.2019, 15:32, "Jonas Maebe" :
> It's not yet integrated in the compiler, so you have to do it manually
> right now:
> a) compile everything with -al (including the RTL etc; add OPT="-a" to
> the make command)
> b) go in all the unit directories, and assemble the files to bitcode
> using something like this:
>
> for file in *.ll; do
>    clang -emit-llvm -O -c $file
> done
>
> c) compile your program with -a -s and do the same as in step b) for
> your program
> d) edit the generated link.res file, and replace all references to unit
> files ending in ".o" with the same files ending in ".bc"
>
> If you used a custom clang rather than the one installed by default on
> your system, you will also have to specify the path to the libLTO that
> the linker should use. You have to do this on the ld command line in
> ppas.sh. You can find the correct parameter by compiling a test
> C-program with "clang -flto -### test.c", as this will print the ld
> invocation to use. E.g. on macOS, it will be something like
>
> -lto_library
> /Volumes/imac/devel/clang+llvm-7.0.0-x86_64-apple-darwin/lib/libLTO.dylib"
>
> On Linux, it's something like
>
> -plugin
> /home/jmaebe/local/clang+llvm-7.0.0-x86_64-linux-gnu-ubuntu-16.04/bin/../lib/LLVMgold.so
> -plugin-opt=O2
>
> (or a different optimization level)

Thanks, but I expected something like rebuilding compiler and adding some 
option to Lazarus project :)
So far it looks like it's not far away from manually recompilation of each and 
every module.

-- 
Regards,
Denis Golovan

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

Re: [fpc-pascal] inlining functions

[denisgolovan]

  12.01.2019, 16:03, "Sven Barth via fpc-pascal" :With WPO you need to compile at least twice as well as the first pass only collects information and acts on it in the second pass. Is it possible to make Lazarus do that automatically?According to Jonas it's a bit too unpractical. -- Regards,Denis Golovan 
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] inlining functions

[denisgolovan]

  12.01.2019, 19:44, "Benito van der Zander" :Hi,  something that appears  to help is to put units in the interface uses rather than the implementation uses.When the unit mentioned in the interface uses, uses the first unit in its implementation uses, it can inline the functions from the first unit. Although I would have expected it to do the opposite. Unfortunately that does not help if the second unit needs to use types from the first unit in its interface   Best,Benito Yes, I got it.The problem is that circular dependencies are too often happen in practice.The discussion is about how to make compiler inline function automatically even when circular dependencies exist. -- Regards,Denis Golovan ___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Undocumented optimizations???

[denisgolovan]

Hi all

I've just tried checking fpc optimizations and found that some implemented 
optimization are not documented in fpc -io output.
e.g. http://wiki.freepascal.org/Optimization mentions AUTOINLINE, but fpc 
states only (Linux x64, svn rev. 40743):

 $ fpc -io
REGVAR
STACKFRAME
PEEPHOLE
LOOPUNROLL
TAILREC
CSE
DFA
USERBP
ORDERFIELDS
FASTMATH
REMOVEEMPTYPROCS
CONSTPROP
USELOADMODIFYSTORE

However doing something like fpc -Ooautoinline project1.lpr works fine.
Same thing with STRENGTH, SCHEDULE and some others.
Also compiling with SCHEDULE causes immediate AV in compiler.

Is it intentional to avoid usage of unstable code or just a miss in 
documentation?

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Undocumented optimizations???

[denisgolovan]

Anybody home? :)

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] TOpenGLControl segfaults on re-parenting

[denisgolovan]

Hi all

I experience various random segfaults when trying to change Parent for 
TOpenGLControl.
Unfortunately it happens rather randomly. 
Sometimes it happens deep in GTK code, sometimes when GL context destroys.

I am under Linux + GTK-2.24.32 + Mesa 19.0.1 (amdgpu driver).

Does anybody experience the same?

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] TOpenGLControl segfaults on re-parenting

[denisgolovan]

Some more information on the matter.

While investigating the issue I noticed that gtk_gl_area_destroy is called 
twice for single OpenGL widget when changing Parent property.
That does not look nice as it accesses freed memory second time it calls 
gdk_gl_context_unref (context : PGdkGLContextPrivate).

gtk2proc.DestroyWidget->gtk_widget_destroy calls gtk_gl_area_destroy twice via 
internal gtk/glib functions.

First time gtk_gl_area_destroy is called from g_object_run_dispose with 
following stack:

#0 GDK_GL_CONTEXT_UNREF(0x29451c0) at 
../../../../../usr/local/share/lazarus/components/opengl/glgtkglxcontext.pas:456
#1 GTK_GL_AREA_DESTROY(0x278bb10) at 
../../../../../usr/local/share/lazarus/components/opengl/glgtkglxcontext.pas:283
#2 g_closure_invoke(0x26f86b0, 0x26f86b0, 0x0, 0x0, 1, 0x7fffc4a0, 
0x7fffc4a0, 0x7fffc410, 0x7fffc410) at 
/var/tmp/paludis/dev-libs-glib-2.52.3/work/glib-2.52.3/gobject/gclosure.c:804
#3 signal_emit_unlocked_R(0x26f80a0, 0x26f80a0, 0, 0, 0x278bb10, 0x278bb10, 
0x0, 0x0, 0x7fffc4a0, 0x7fffc4a0) at 
/var/tmp/paludis/dev-libs-glib-2.52.3/work/glib-2.52.3/gobject/gsignal.c:3751
#4 g_signal_emit_valist(, , , 
0x7fffc650, 0x7fffc650) at 
/var/tmp/paludis/dev-libs-glib-2.52.3/work/glib-2.52.3/gobject/gsignal.c:3391
#5 g_signal_emit(, , ) at 
/var/tmp/paludis/dev-libs-glib-2.52.3/work/glib-2.52.3/gobject/gsignal.c:3447
#6 ?? at :0
#7 g_object_run_dispose(0x278bb10) at 
/var/tmp/paludis/dev-libs-glib-2.52.3/work/glib-2.52.3/gobject/gobject.c:1084
#8 DESTROYWIDGET(0x278bb10) at gtk2/gtk2proc.inc:4252
#9 DESTROYCONNECTEDWIDGET(0x26a1100, 0x278bb10, false) at 
gtk2/gtk2widgetset.inc:4814
#10 DESTROYLCLCOMPONENT(0x26a1100, 0x2932a60) at gtk2/gtk2widgetset.inc:4724
#11 DESTROYHANDLE(0x2234978, 0x2932a60) at gtk2/gtk2wscontrols.pp:611
#12 DESTROYHANDLE(0x278be00, 0x2932a60) at 
../../../../../usr/local/share/lazarus/components/opengl/openglcontext.pas:766
#13 DESTROYWND(0x2932a60) at include/wincontrol.inc:7869
#14 DESTROYHANDLE(0x2932a60) at include/wincontrol.inc:5321
#15 REMOVECONTROL(0x2907120, 0x2932a60) at include/wincontrol.inc:6374
#16 SETPARENT(0x2932a60, 0x2f8e840) at include/control.inc:4347

Second time - from g_object_unref with stack:

#0 GDK_GL_CONTEXT_UNREF(0x29451c0) at 
../../../../../usr/local/share/lazarus/components/opengl/glgtkglxcontext.pas:449
#1 GTK_GL_AREA_DESTROY(0x278bb10) at 
../../../../../usr/local/share/lazarus/components/opengl/glgtkglxcontext.pas:283
#2 g_closure_invoke(0x26f86b0, 0x26f86b0, 0x0, 0x0, 1, 0x7fffc480, 
0x7fffc480, 0x7fffc3f0, 0x7fffc3f0) at 
/var/tmp/paludis/dev-libs-glib-2.52.3/work/glib-2.52.3/gobject/gclosure.c:804
#3 signal_emit_unlocked_R(0x26f80a0, 0x26f80a0, 0, 0, 0x278bb10, 0x278bb10, 
0x0, 0x0, 0x7fffc480, 0x7fffc480) at 
/var/tmp/paludis/dev-libs-glib-2.52.3/work/glib-2.52.3/gobject/gsignal.c:3751
#4 g_signal_emit_valist(, , , 
0x7fffc630, 0x7fffc630) at 
/var/tmp/paludis/dev-libs-glib-2.52.3/work/glib-2.52.3/gobject/gsignal.c:3391
#5 g_signal_emit(, , ) at 
/var/tmp/paludis/dev-libs-glib-2.52.3/work/glib-2.52.3/gobject/gsignal.c:3447
#6 ?? at :0
#7 g_object_unref(0x278bb10) at 
/var/tmp/paludis/dev-libs-glib-2.52.3/work/glib-2.52.3/gobject/gobject.c:3148
#8 DESTROYWIDGET(0x278bb10) at gtk2/gtk2proc.inc:4252
#9 DESTROYCONNECTEDWIDGET(0x26a1100, 0x278bb10, false) at 
gtk2/gtk2widgetset.inc:4814
#10 DESTROYLCLCOMPONENT(0x26a1100, 0x2932a60) at gtk2/gtk2widgetset.inc:4724
#11 DESTROYHANDLE(0x2234978, 0x2932a60) at gtk2/gtk2wscontrols.pp:611
#12 DESTROYHANDLE(0x278be00, 0x2932a60) at 
../../../../../usr/local/share/lazarus/components/opengl/openglcontext.pas:766
#13 DESTROYWND(0x2932a60) at include/wincontrol.inc:7869
#14 DESTROYHANDLE(0x2932a60) at include/wincontrol.inc:5321
#15 REMOVECONTROL(0x2907120, 0x2932a60) at include/wincontrol.inc:6374
#16 SETPARENT(0x2932a60, 0x2f8e840) at include/control.inc:4347

I guess I need some help from Lazarus GTK/GLib experts.
Calling glXDestroyContext in TOpenGLControl twice is obviously an undefined 
behavior and should be fixed.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] TOpenGLControl segfaults on re-parenting

[denisgolovan]

Bug report and patch with fix filed to 
https://bugs.freepascal.org/view.php?id=35335
Please review.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] wiki.freepascal.org is down?

[denisgolovan]

Hi

I get empty pages when browsing http://wiki.freepascal.org/
Is it some bug or I am doing something wrong?

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] wiki.freepascal.org is down?

[denisgolovan]

Ok, thanks.

-- 
Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Compiler regression

[denisgolovan]

Hi all

Could somebody look at https://bugs.freepascal.org/view.php?id=35877 ?
Latest fpc trunk is completely broken while using generics.collections.

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Compiler regression

[denisgolovan]

> Several people have already looked at it, but it's a complex issue that
> is not yet understood.
> 
> Jonas

Ok, thanks.
Hope all those people didn't find anything secret forcing them to remain silent 
with regards to bug comments :)

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Git mirror

[denisgolovan]

Hi all

Looks like Graeme's FPC git mirror stopped syncing with svn.
I've sent a private mail, but no response.
Could somebody help?

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Git mirror

[denisgolovan]

> It appears that the last commit on svn was on the 27th 
> (https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/utils/?sortby=date&view=log)
>  which is the same date as the last commit on Graeme's mirror 
> (https://github.com/graemeg/freepascal/commit/a1fd692f4f98e4889eb9ef333075a6c0f8dd0891).
>  I thus don't think there is a sync problem.

No, it's just Graeme fixed syncing today :)

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Git mirror

[denisgolovan]

> I fixed it at 08:00 this morning. It's all in sync again. There was a
> new contributor to SVN that wasn't in my name list. It happens ever now
> and again.

Thanks.

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] IDLE_PRIO with FPC-compiled processes

[denisgolovan via fpc-pascal]

Hi all

Have anybody experienced exceptions "Failed to create new thread" when 
FPC-compiled process priority changed with schedtool -D [pid]?

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Extended type under Win64

[denisgolovan via fpc-pascal]

Hi all

I'm trying to get an idea if Extended float is/can actually be 80bit?
I have FPC built under Linux x64 and it works fine (co-processor command are 
actually used).

But I haven't found any reliable information about Win64 support.
Brief FPC source grepping showed FPC_HAS_TYPE_EXTENDED define, but I haven't 
managed to find where it is defined.

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Extended type under Win64

[denisgolovan via fpc-pascal]

> The Extended type is not available for x86_64-win64. You either need to use 
> Double or the software floating point support in unit sfpux80 (though that is 
> only available in 3.2 and newer).

So, Linux x64 having hardware Extended support is just an exception?
Or maybe it's possible to build a custom x86_64-win64 compiler with that define 
enabled?

> Please note that you'll have the same problem on any non-x86 platform as that 
> type only exists there (and m68k).
Yes. I am perfectly ok with Intel only.

-- Regards,
Denis Golovan
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal