[fpc-pascal] Cmdline parser

Hi all Could anybody suggest some existing command line parser for FPC having following requirements: 1. Crossplatform with stable semantics - Linux/Windows. 2. Short and long values support. 3. Support for "generic parsing". I mean being able to parse from string any unknown set of args as

Re: [fpc-pascal] Barriers semantics

> On 14/08/2023 18:19, denisgolovan via fpc-pascal wrote: > >> Now we have "volatile" intrinsic for assignments in place, I'd like to ask >> for another clarification. > > Just to make sure given your questions below: using volatile in the > context of m

[fpc-pascal] Barriers semantics

Hi all Now we have "volatile" intrinsic for assignments in place, I'd like to ask for another clarification. Documentation states we have following barriers - ReadBarrier, WriteBarrier, ReadDependencyBarrier, ReadWriteBarrier. I'd like to get an idea how those related to more common / standard

Re: [fpc-pascal] Volatile store usage

> On 11/08/2023 18:05, denisgolovan via fpc-pascal wrote: > >> Are "volatile" stores supported? > > They weren't, but I've added support for it now. Aha. Thanks. -- Regards, Denis Golovan ___ fpc-pascal maillist - fpc

[fpc-pascal] Volatile store usage

Hi all I'd like to get some clarification about "volatile" intrinsic. https://wiki.freepascal.org/FPC_New_Features_Trunk#Support_for_.22volatile.22_intrinsic says just following: Support for "volatile" intrinsic Overview: A volatile intrinsic has been added to indicate to the code

Re: [fpc-pascal] Cache-line alignment for records

> It is possible > (https://gitlab.com/freepascal.org/fpc/source/-/blob/main/tests/test/talignrec1.pp), > but it is subject to the same limitations when declaring variables of > those types. > > Jonas Aha. Nice! Does it work recursively? I mean - does it work when aligned record is itself a

Re: [fpc-pascal] Cache-line alignment for records

> However, the maximum alignment you can specify this way is limited per > target (hardcoded in the compiler). In 3.2.x, it's 16 bytes for most > desktop targets. On 3.3.x, it's 64 bytes for most desktop targets. > > Jonas But it's still not possible to attach alignment to type itself instead

Re: [fpc-pascal] Feature announcement: implicit generic function specializations

> If you want to pass a pointer to ^T in a generic function is there anyway > safe to do this currently? Pascal doesn’t allow ^ types in function arguments > (why?) and generics don’t seems to support pointers either (why?). > > generic TValues = array[0..0] of T; > generic PValues =

Re: [fpc-pascal] Feature announcement: implicit generic function specializations

That seriously improves generic code readability. Definitely worth trying to upgrade. Thanks a lot! 20:15, 20 апреля 2022 г., "Sven Barth via fpc-pascal" :Dear FPC community,The FPC developers are pleased to announce the implementation of a new feature: implicit generic function specializations.

Re: [fpc-pascal] Compiler internals. Changing dynamic arrays format

> On 2022-04-13 00:34, denisgolovan via fpc-pascal wrote: > Your comment about conditional defines goes in the right direction - > basically: > > 1) Separate your changes into parts affecting the compiler behaviour > (e.g. the changes impacting the compiled structures an

[fpc-pascal] Compiler internals. Changing dynamic arrays format

Hi all I've been maintaining a set of private patches for some quite old FPC revision for some years. The idea behind those patches to ease interoperation between FPC and LuaJIT FFI by pointer tagging for dynamic arrays. For that to happen I was forced to modify "tdynarray" record (increase its

Re: [fpc-pascal] Inactive account on GitLab

> I starred the projects of those bugs (FPC/FPC/Source and > FPC/Lazarus/Lazarus) but my todo list is still empty. > Not a biggie now that I know how to find my bugs, though I'd prefer to > find them with the proper filter (the first one with author_username) > and not with a full text search.

Re: [fpc-pascal] Inactive account on GitLab

> FPC's git and issue trackers are hosted on Gitlab itself, we have no > authority to do > user management. Ok. I managed to sign up and login. Does it mean my old issues cannot be linked to my GitLab account? -- Regards, Denis Golovan ___ fpc-pascal

[fpc-pascal] Inactive account on GitLab

Hi all Could anybody look at GitLab MageSlayer account? I can neither login nor change my password. Maybe my mail has not been transferred? -- Regards, Denis Golovan ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org

Re: [fpc-pascal] Management operators memleaks

> I have not looked at your test case yet, but it *might* be related to > issue #37164 ( https://bugs.freepascal.org/view.php?id=37164 ). Thanks for the point, Sven. Is there something I can do to prioritize the issue? -- Regards, Denis Golovan ___

Re: [fpc-pascal] Management operators memleaks

Could anybody reply? Am I doing something wrong? Are management operators supported or not? -- Regards, Denis Golovan ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Management operators memleaks

Hi all I created a test case for rather unusual behaviour of management operators in fpc 3.3.1. In some specific cases they produce memory leaks. I suspect it's some compiler issue. Could somebody take a look at https://bugs.freepascal.org/view.php?id=38990 ? P.S. Sorry for attaching quite

Re: [fpc-pascal] Option type

> Well as already discovered type like strings can not go into a "record case" > > But... The above record is anyway of constant size. I.e. the memory for > the field is always included, even if it is not used. > > Since the "false" block is empty, you can do > > type > generic TOption =

Re: [fpc-pascal] Option type

> You simply can't use managed types in a variant clause and as T could be > a managed type the compiler does not allow it. Well. I thought it should be precisely the case for variant clause to properly handle. Compiler knows IsSome field is used to determine if some contains initialized

Re: [fpc-pascal] Option type

> You need to use a constraint like: > > type > generic TOption = record > case IsSome:boolean of > true: ( some: T ); > false: (); > end; > > Not sure why though. > > Regards, > Ryan Joseph That would limit supported types to class instances. I'll like to avoid that. Ideally TOption type

[fpc-pascal] Option type

Hi all I am trying to implement Option type in FPC. type generic TOption = record case IsSome:boolean of true: ( some: T ); false: (); end; However fpc just emits errors: Error: Type parameters may require initialization/finalization - cannot be used in variant records Could

Re: [fpc-pascal] Extended type under Win64

> In theory yes, but it's not recommended, because Microsoft does not recommend > it (not to mention that it isn't even remotely tested as much as the normal > Win64 target). > > Regards, > Sven Got it. Thanks for the clarification. -- Regards, Denis Golovan

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

[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

[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

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

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=log) > which is the same date as the last commit on Graeme's mirror > (https://github.com/graemeg/freepascal/commit/a1fd692f4f98e4889eb9ef333075a6c0f8dd0891). > I

[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

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] 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

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] 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

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

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 :

[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

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] 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

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

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

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

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

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 -

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

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

[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

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 i

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-pascal wrote: Looks better. The next thing to nuke is the tgenericparamdef. The

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

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)

[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

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 -

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 -

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.

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

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] 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.

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

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

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

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 -

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

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

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

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

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 >

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;

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

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

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 ___

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" = >

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

[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 :

[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

Re: [fpc-pascal] Compiler debug build

Thanks.That's exactly what I need.22.07.2017, 20:20, "Maciej Izak" <hnb.c...@gmail.com>: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

[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

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" <mich...@freepascal.org>: > On Mon, 10 Jul 2017, denisgolovan wrote: > >>  That's exactly what I mean - so

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." <s...@ciberpiula.net>: > El 10/07/2017 a las 11:17, denisgolovan escribió: > It is not a matter of publi

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

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

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

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

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] 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

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

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" <jonas.ma...@elis.ugent.be>: > denisgolovan wrote: > >>  18.11.2016, 13

Re: [fpc-pascal] Other linkers support

Ok. See http://bugs.freepascal.org/view.php?id=30956 then. 18.11.2016, 13:00, "Jonas Maebe" <jonas.ma...@elis.ugent.be>: > denisgolovan wrote on Fri, 18 Nov 2016: > >>  Last time I tried, ld scripts generated by fpc caused some errors on >>  gold linker. &

[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,

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.

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 

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

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

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

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

[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

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

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

[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

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

[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

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

  1   2   >