[fpc-pascal] Commercial support for Lazarus/FPC
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
> > 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
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
> 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
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
> 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
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
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
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?
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?
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
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
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
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
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
> 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
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
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
> > 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
> 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
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?
> 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
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
> 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)
> 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
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
> 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
> 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
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.
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.
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.
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 ?
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"
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'
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
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
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
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?
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?
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
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
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?
> 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?
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
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
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
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
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
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
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
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
> 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
> 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
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
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
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
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
> 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
> 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
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
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
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
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
> 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?
> 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?
> 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?
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
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
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
> 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
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
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
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
> 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
>> - 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
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-pascalwrote: 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
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
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
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
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
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
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
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
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
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???
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???
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
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
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
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?
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?
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
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
> 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
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
> 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
> 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
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
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
> 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