[fpc-devel] FastRTTI for FPC
Hi, in response to the topic "Attn Sven: New flags related to management operators" 2018-06-29 11:53 GMT+02:00 Maciej Izak : > 2018-06-28 22:10 GMT+02:00 Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org>: >> >> Sorry that it took me so long, but I wanted to reread your proposed >> FastRTTI changes before deciding and I only found the time this evening. >> >> I'm currently indeed leaning towards option 2. >> > > This is good info. > > >> If you want to prepare this you can of course do it in a way that allows >> to easily add in your other FastRTTI changes at a later date (though those >> are still a bit up for debate (lessthe principal idea, more the concrete >> implementation)). >> > > This is good info too. So we can keep all gathered information about > "managed things" in compiler without producing final FastRTTI (only > mentioned table of initialization operators - which is special). > > I agree that implementation in details may change and is for debate. > > In early July I will prepare code base for both : FPC trunk and NewPascal, > and I will continue development of FastRTTI: > I just want to say that I am not able to do this patch for FPC (or any other patch) - there is no technical reason but rather sense of injustice in many aspects (finally FastRTTI is important part of my ban). IMO The best solution from topic "Attn Sven: New flags related to management operators" ATM is option 3 : 3. moving "Flags: TRecordInfoInitFlags;" into private section of record in TypInfo module, it can be removed in the future (if needed) without breaking backward compatibility for users code. FPC will stay with improper / slower solution for the problem (until someone will decide to solve this in proper way). I need to inform that I am not allowed (this is not my decision) to use fpc-devel / fpc-pascal anymore to inform about progress/announcements of my work for my branches of FPC (or anything related to NewPascal) so if someone is interested in news about more optimal management operators should rather track http://newpascal.org or https://plus.google.com/+MaciejIzak . -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Attn. Generics.Collections and rev. 39345 and speed slowdown
2018-06-30 11:03 GMT+02:00 Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org>: > mORMot is a third party project that can be used with FPC while Delphi is > essentially a template and base line for compatibility, so there is a > difference between the two. Though if you have a formal name for the hash > that Delphi uses we can change that as well :P > TDelphi*HashFactory is not required for compatibility with Delphi (as many other things in rtl-generic). Correct name for this hash is "BobJenkins" (Delphi has special slightly modified version of HashLittle which in Delphi is called BobJenkins - don't ask :P). I will fix all hash names where "Delphi" word exist. -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Attn. Generics.Collections and rev. 39345 and speed slowdown
2018-06-30 8:55 GMT+02:00 Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org>: > No, the bad taste is too have a class that appears to be named > specifically to fit a specific third party project inside a general purpose > library. > Ok, I agree here, but why Michael Van Canneyt decide to annihilating only TmORMotHashFactory and TDelphi*HashFactory still exist? This is highly not consequent! > (though I agree that the change of the default hash could have been > discussed first) > seems that compilation for minor example (easy fixable in other way) has bigger priority than major performance of whole library :P -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Attn. Generics.Collections and rev. 39345 and speed slowdown
2018-06-30 8:33 GMT+02:00 Michael Van Canneyt : > As noted in the bugreport, your own examples did not compile with your > supplied code. > Next time, please test that too. > The most important was to finish new collections, deep refactoring and proper tests suite than testing all examples. Library was totally refactored and something like that may happens. > It is definitely better to have a slower default that works always than a > faster one that does not let all code compile. > No. You are wrong. The more important is test suite than minor example somewhere (which can be easily fixed). For sure faster library with proper test suite is more important than a little outdated example (!sic). > But not problem, please advise on the changes needed to a) fix the > mentioned example so it actually compiles. > b) Speed up the default hash. > > I (or someone else) will be happy to change it. Ok, but in the future you should ask for such important changes. -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Attn. Generics.Collections and rev. 39345 and speed slowdown
Hi, renaming for TMormotHashFactory to TGenericsHashFactory is somehow acceptable (but IMO bad taste) but change for default hashing algorithm in such important library is really really really bad idea. This was not consulted, change like that or proposition should be reported here : https://github.com/maciej-izak/generics.collections/issues OR IN ANY OTHER WAY, not in comment in other bug report where can be easily omitted (!). The problem with thashmapextendedequalitycomparer example was really minor and should be fixed in other way not by changing *default hashing algorithm* for whole library (!). Widely used TDictionary is also affected by this change. Results BEFORE Michael Van Canneyt changes: THashSet add200 items. Time elapsed : 1844 THashSet lookup 200 items. Time elapsed : 812 TSortedHashSet add 200 items. Time elapsed : 18640 TSortedHashSet lookup 200 items. Time elapsed : 641 THashSet add 1000 items. Time elapsed : 1328 THashSet lookup1000 items. Time elapsed : 640 TSortedHashSet add 1000 items. Time elapsed : 4235 TSortedHashSet lookup 1000 items. Time elapsed : 765 Results AFTER Michael Van Canneyt changes: THashSet add200 items. Time elapsed : 2250 THashSet lookup 200 items. Time elapsed : 906 TSortedHashSet add 200 items. Time elapsed : 18828 TSortedHashSet lookup 200 items. Time elapsed : 688 THashSet add 1000 items. Time elapsed : 2219 THashSet lookup1000 items. Time elapsed : 1140 TSortedHashSet add 1000 items. Time elapsed : 5250 TSortedHashSet lookup 1000 items. Time elapsed : 1234 -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generics.Collections June update
2018-06-28 22:13 GMT+02:00 Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org>: > - why is it that you adjusted DaThoX' copyright range, but not yours at > the top? > on the top is date of creation :) (it seems like standard, but maybe I am wrong). -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Attn Sven: New flags related to management operators
2018-06-28 22:10 GMT+02:00 Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org>: > > Sorry that it took me so long, but I wanted to reread your proposed > FastRTTI changes before deciding and I only found the time this evening. > > I'm currently indeed leaning towards option 2. > This is good info. > If you want to prepare this you can of course do it in a way that allows > to easily add in your other FastRTTI changes at a later date (though those > are still a bit up for debate (lessthe principal idea, more the concrete > implementation)). > This is good info too. So we can keep all gathered information about "managed things" in compiler without producing final FastRTTI (only mentioned table of initialization operators - which is special). I agree that implementation in details may change and is for debate. In early July I will prepare code base for both : FPC trunk and NewPascal, and I will continue development of FastRTTI: - integration with NewPascal for current layout of FastRTTI, which can be changed/adjusted at any time. also some new directions (also partially related to FastRTTI): - inline management operators - inline initialization for managed fields, local managed variables (probably this can provide a lot of additional performance on user request). This shows that NewPascal as "bleeding edge technology" (anyway tested with all available tests) is a good idea. :) I will for sure adjust FastRTTI, when I will get any feedback from you (or any other core developer). It is very good that will be possible to keep single code base in this matter. -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Attn Sven: New flags related to management operators
2018-06-22 21:08 GMT+02:00 Maciej Izak : > I see 4 options: > > 1. integration of FastRTTI > 2. limited integration, only part of "FastRTTI" branch (only table with > initialization operators and related compiler and RTL part) > 3. moving "Flags: TRecordInfoInitFlags;" into private section of record in > TypInfo module, it can be removed in the future (if needed) without > breaking backward compatibility for users code > 4. all will stay as-is (the worst scenario) > > The option 2 seems optimal (no redundant/useless actions/calls in > constructors). > Ping? Would be good to know what you decide. -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Generics.Collections June update
Hi, I have decide to keep compatibility for Generics.Collections with FPC 3.0.4 and trunk as long as possible (library is important for many users). First update and related bug report: https://bugs.freepascal.org/view.php?id=33921 The patch includes latest changes from original library : * basic information why Generics.Collections library in FPC trunk is not up to date * unified code base between FPC trunk, library and NewPascal. Previously trunk was priority, so there was some minor differences between FPC trunk version, github repo and NewPascal version. Now the order is : library on github > NewPascal > FPC trunk * reworked patch and reworked test from Michalis Kamburelis for xxHash32 pure pascal version (problem highly visible for MacOS version and for non Intel CPUs), fix issue 9 in "github issues" * link to proper bugtracker for bugs related to this library : https://github.com/maciej-izak/generics.collections/issues * update for inactive freesparta.com links (newpascal.org is used instead of freesparta.com) * some new proper credits in few places -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Attn Sven: New flags related to management operators
2018-06-21 22:09 GMT+02:00 Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org>: > > We don't really know when your FastRTTI changes are going to be integrated > or if they are going to be integrated at all; the performance of classes > that don't have fields that use an Initialize operator needed to be > restored sooner rather than later. This is especially important as on Core > we've recently started talking about branching of 3.2 and even though I've > implemented my Flags based solution before that discussion was started it's > definitely an important point. > Also your FastRTTI approach and the Flags can coexist without problems > (and even complement each other) from what I've read in the thread where > you introduced your idea. That said I seriously doubt that the flags are > less efficient than FastRTTI for 8 and 16 bit platforms (where we had said > that FastRTTI isn't used by default) or even the 32 or 64 bit ones, because > with the flags no initialization aside from FillChar() is executed at all > for classes that contain managed types, but no types with an initialize > operator (while with the FastRTTI disabled the record initialization would > still be executed). > Sven you are wrong, flags for this case are less efficient for 8 and 16 bit platforms and not only for this platforms. This is also true even for other platforms even when FastRTTI is off. This is because RecordRTTI(Instance,Temp,@int_initialize); is never called even for disabled FastRTTI. Instead of this in the place of current RecordRTTI call is used https://github.com/maciej-izak/freepascal/blob/fastrtti/rtl/inc/objpas.inc#L392-L396 here is used simple table of all initialize operators to call. This table is always generated as special part of INIT RTTI (independent from other FastRTTI stuff) for maximal performance of this critical RTL part. The pointer to table of all initialize operators is in the place of current new field "Flags: TRecordInfoInitFlags;". No need for redundant call to RecordRTTI which dose many redundant things like initialization for already initialized managed fields and many potential calls to next RecordRTTI... Coexistence of both has no sense - information stored in Flags will be useless, this info is for sure not complement :( . I can propose to adjust all needed things in FastRTTI patch before 3.2 branching, I think this will be good for all (FPC will be much faster in many areas than Delphi!) . I have just few minor things to finish (one day of work?). The patch was tested for all platforms: 8bit, 16bit, 32, 64 also for big endian without single regression. Additionally patch was tested with all available very strict mORMot tests, so I think FastRTTI is really stable. -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Smart pointers/nullable types - compromise solution
Hi,
I think that the most acceptable solution for all in core team and for
advanced users (here I mean Stefan Glienke ;) ) for smart pointers and
nullable types is usage of default property without indexer.
For example :
type
TFoo = record
{ ... }
property Some: Integer read GetSome write SetSome; default;
end;
this solution seems better compromise than default field (which I
personally prefer). This will allows new proper handling of exceptions for
nullable types, IIRC this was mentioned by Stefan Glienke as the
main disadvantage of default fields, also probably all Jonas Maebe doubts
are not actual with "default property without indexers" (for example "var"
parameter problem for overloaded procedures).
usage of smart pointers and nullable types will introduce more extensive
usage of managed types (finally every nullable type and smart pointer is in
managed types category because "default property without indexers" almost
always means usage of management operators) which may means really
slowdown, but this can be solved (generally already is solved in my
FastRTTI branch) - in this context is worth to look into my other topic :
"[fpc-devel] Attn Sven: New flags related to management operators" (
http://lists.freepascal.org/pipermail/fpc-devel/2018-June/039109.html )
also might be worth to introduce modeswitch to allows "default field" which
should be disabled by default for all modes. In practice default field is
also very usable in many scenarios, for example as replacement for type
helpers or as some kind of aspects and many more.
the main questions are :
* FastRTTI should be introduced into NewPascal only or should be refactored
and used also in FPC trunk?
* What with TRecordInfoInitFlags? (very important for above, with FastRTTI
TRecordInfoInitFlags has not much sense)
* What with smart pointers/nullable types/ARC objects further work? Here
the same question : NewPascal only or FPC trunk too?
--
Best regards,
Maciej Izak
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Attn Sven: New flags related to management operators
Hi Sven, I saw the new commits related to Management Operators (I mean new flags riifNonTrivialChild and riifParentHasNonTrivialChild) and I wonder what next. When I was developing management operators (and FastRTTI related to speed up things) I had in mind extensive expansion for management types in many directions (nullable types, smart pointers and so one, FastRTTI is also related to all managed types not only to management operators) and optimizations to speed up things (in the final, generated code can be faster even few times than current code, here I mean code with standard managed types without any management operators). The FastRTTI covers the needs of the optimization for constructors but also moves things much forward (it depends on use case: from my tests is never slower but always faster, for some cases even few times). For example the new flags (riifNonTrivialChild and riifParentHasNonTrivialChild) works good only when none of record with "Initialize operator" is used as field, also worth to note that new solution will be much slower in the future than FastRTTI when users will decide to use more types backed by management operators (and the topic will back again...). Current flags are temporary solution or final thing? I have few things to say A. we have ready to use better/faster solution than riifNonTrivialChild riifParentHasNonTrivialChild B. current solution probably means also waste of memory for TRecordInfoInitFlags when in the future someone decide to introduce other optimizations related to RTTI and managed types (similar to FastRTTI) C. also is possible to use less invasive version of FastRTTI (for example can be used part related to Initialize operator only (this part is already exposed outside FastRTTI structures and is generated always even when fast RTTI is off) and the way for full FastRTTI will be opened without wast of space for new flags... D. Do we really want to use temporary solution? I think no - we should looks forward. E. FastRTTI is just beginning and can be expanded to more optimizations F. if for some reasons you want to keep current solution (anyway IMO very unwelcome for future things) may be worth to rename TRecordInfoInitFlags because can be also used for other purposes not related to initialization only. For example all flags defined for FastRTTI can be moved into this flag... Anyway TRecordInfoInitFlags will be still less efficient than FastRTTI for 8 and 16 bit platforms... -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Announcement: NewPascal is back :)
Hello, first of all I like to thanks for kind e-mails and messages with positive energy, this was really important for me in my current situation. After more than one year of lack of updates for NewPascal, NewPascal is back to life in new version v1.0.55 and I have hope to continue progress. This version contains fresh, ready to use mORMot and trunk of Lazarus and modified version of FPC trunk in really lightweight form without needs of installation: http://newpascal.org/ https://github.com/newpascal/newpascal/releases/tag/np-v1.0.55 NewPascal is a must: I have ban for FPC core mailing list (no more "Daily test suite diffs" for me) and I don't have access to trunk without any rational reason. I am not able to provide any updates, bug fixes nor new features into FPC trunk. What is good in current situation : * Smart pointers / nullable types works, the merge went well and I will continue my work, any tests and opinions are welcome :) the related library is : https://github.com/maciej-izak/PascalSmartPointers What is bad is related to unfinished work for FPC (unexpected end of access): * Florian wants cleaning up of Generics.Collections/rtl-generics. Many part of code inside library should be moved into other packages * I have few bug fixes for generics (and not only for generics) in advanced progress :( * Managemenet operators are not so cool without default field, there is also work-in-progress * better CI for simple testing has also good progress... * new more modern website for FPC (with NewPascal as part of official FPC). * FastRTTI with general speed up for any operations on managed types. Feature well tested for many platforms... * Almost all elements were related... Life Goes On :) I will try to put all puzzles together. -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] NewPascal plans, Generics.Collections and FPC trunk
2018-05-02 18:41 GMT+02:00 Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org>: > Please note that the pnameless.pas file by Blaise does not yet have a GPL > compatible license header and thus you're essentially violating his > copyright with that (it's one of the points I'm waiting to be corrected for > the final merge). > this is not true, GPL is viral licence and pnameless is affected by other GPL modules used in pnameless. Anyway Blaise already agreed with my acquisition some time ago so I see no violation here ( the topic "Closures / anonymous methods" 25.10.2016 ). I had also contact from "Scooter Software" (with Zoë Peterson) and all is fine here too (eventually if I will get some bounties for closures, then Blaise should receive proper part of bounty). I have copy of publicly available code on GPL licence, this code was not stolen. Blaise will be mentioned as main author of this module I have always full respect for original authors of any code and no one will be omitted (AFAIK this is not required by GPL but is natural for me). Anyway the code will be refactored, because part of the same code will be used for further "yield" functionality. -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] NewPascal plans, Generics.Collections and FPC trunk
Hello, I was kicked away today from core team (probably by Michael Van Canneyt). Insulting and destructive approach by Michael Van Canneyt (with silent acceptance from other persons in core team) is unacceptable (the good example can be found in topic "[fpc-devel] What's the status of Maciej's Smart Pointer enhancements?" from 29 April 2018). IMO this is not the way how good open source project should work. I leave it to everyone for individual evaluation, here is short summary: http://lists.freepascal.org/pipermail/fpc-devel/2018-May/038886.html I will continue my all work as much as possible with NewPascal (which will be synced with FPC trunk few times in the year - or more often if needed), I mean here all stuff, including updates for Generics.Collections library, bug fixes for compiler and generics, smart pointers/ARC/nullable types, oxygene mode, closures and extended RTTI. I've suspended the NewPascal foundation (it was not officially registered yet) and the idea of the NewPascal for the good of whole community (finally one project is better than divided community). I was trying to put all my energy into official FPC but it seems impossible. Every person has a dignity, and the unacceptable line of insulting in many fields was crossed many times. Note about Generics.Collections: the library is important for many programmers, so everyone who is using Generics.Collections should use : https://github.com/maciej-izak/generics.collections the FPC trunk version will be not updated anymore so if someone is using this library should definitely not use official FPC trunk version. Any bug report about Generics.Collections should be filled in my github repo (in current situation usage of official bug tracker in this matter has no sense). The next place with actual Generics.Collections will be http://NewPascal.org distribution (which will be updated soon) - the distro was not intensively update because I was too much naive in my faith for FPC progress. NewPascal was intended as part of official FPC which in current situation is impossible. -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] What's the status of Maciej's Smart Pointer enhancements?
2018-04-30 21:30 GMT+02:00 Michael Van Canneyt <mich...@freepascal.org>: > I can imagine that checking such a field will be more fast than actually >>> calling a routine. This is just a thought, if you had already considered >>> such a thing, I would like to hear why you discarded it, for my >>> education. >>> >> >> >> this is exactly what is done in FastRTTI >> > > Yes, I imagined this answer. Allow me to ask further questions: > > You are adding - please correct me if I am wrong - a complete new table > to the binary, for every class. What does this table contain if no > management operators are used ? Dear Sir, all was explained in core mailing list (about FastRTTI) and in fpc-devel (about management operators), even if some detail was not clear enough you had many occasions to ask. If you was able to imagine previous answer I think that you can imagine my next answer so let me not answering on your request because you already know the answer (the answer already exist in your imagination). First you told that my solution is : - simply not convincing - FastRTTI is tricky - I should find a solution just a little harder - you are talking that: things are rammed through our throat which we didn't ask for - you are asking for a solution that satisfies everyone (finally every other person can contribute) After something like this, without basic knowledge about my work, now you are asking for details ? In addition : - in core and in public lists you are writing many strange things all the time, like for example that I am drunk, etc (about other topics but this is general manner of your personal culture) - I had ban from you on G+ in "FreePascal Foundation" group (some time ago, only because I was author of NewPascal) - you are thinking that all my work for FPC is bad (or most of work, without basic knowledge about details) I have one clear answer for you (especially that you are the "core member") : I have no time for you anymore because I have more important things to do than blabbing with you. Best wishes and good luck! -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] What's the status of Maciej's Smart Pointer enhancements?
2018-04-30 20:56 GMT+02:00 Michael Van Canneyt <mich...@freepascal.org>: > There is no agression. There is critique. > > Maybe the others were satisfied with your solution I am not. So I brought > it > again to everyone's attention. There is difference between rudeness and critique. You are just rude, for someone from core team I have greater demands. > I can imagine that checking such a field will be more fast than actually > calling a routine. This is just a thought, if you had already considered > such a thing, I would like to hear why you discarded it, for my education. this is exactly what is done in FastRTTI -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] What's the status of Maciej's Smart Pointer enhancements?
2018-04-30 14:59 GMT+02:00 Michael Van Canneyt <mich...@freepascal.org>: > > Maybe because your solution is simply not convincing and I wish to try and > find a solution just a little harder ? > > Allow me to exaggerate the point a little: > > A bunch of changes are introduced, things are rammed through our throat > which we didn't ask for and then we're told "this is the price for > progress'. Management operators feature was one of the point from Sven's TODO list and was consulted with Sven, Florian and Jonas. If Sven, Florian or Jonas likes to remove this idea I have no objections it was not my idea I am just a modest contractor. The FastRTTI was created on your request (not directly) because you asked about speed comparison between FPC 1.0 and 3.0/trunk in core mailing list. Florian asked for patch and FastRTTI is the answer for Florian request, checked also by Sven. I don't understand your aggression and the whole message. You was informed all the time like others in core team. Maybe other people can contribute to a solution that satisfies everyone. > Maybe yes, probably I am too stupid :) -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] What's the status of Maciej's Smart Pointer enhancements?
2018-04-30 15:05 GMT+02:00 Mattias Gaertner <nc-gaert...@netcologne.de>: > Does that mean fpc 3.0.x had an unneeded overhead for classes without > managed types and 3.1 fixes this? > No, small unneeded overhead exist in both. The situation is different when managed types are used. FPC has similar solution for RTTI like Delphi. FastRTTI (not merged yet into trunk) is something new (optimized layout of RTTI). In the short all managed fields are initialized in one call instead of recursion (one call to FPC_INITIALIZE instead of many calls). It saves many of initialization/finalization time. -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] What's the status of Maciej's Smart Pointer enhancements?
2018-04-30 13:53 GMT+02:00 Michael Van Canneyt <mich...@freepascal.org>: > > You mean that a constructor call for a program that does not uses > pointers/management operators also gets slower ? > > Can we solve this _without_ additional tricks ? > > Because the fact that a feature you do not use slows down your code is not > really acceptable in my opinion. > It was discussed some time ago on core so I have no idea why you are asking for this again. The "slower" is too strong word. RTL must to call internal int_initialize in TObject.InitInstance and this is required for management operators. The similar operation was always executed for destructors in TObject.CleanupInstance: "int_finalize" even without new feature "management operator" for all managed types. With FastRTTI additional call to int_initialize is omitted when possible. Furthermore with FastRTTI all code is executed faster (much faster than in 3.0.x) because all info about managed fields (for classes, objects and records) is aggregated in single array for faster initialization/finalization. By managed fields I mean all managed types (strings, interfaces, etc.) So: no we can't solve this without FastRTTI (or without significant part of FastRTTI) and this is not additional trick but new feature. This is the same for any string and interface (or any other managed type) inside classes. Your code is already "slows down" even when you don't use managed types for fields (even in 3.0.x or in any previous version). Nothing new here so probably you should change your opinion. This is the price of managed types. FastRTTI is significant step forward for more performant and extensive usage of managed types (also for smart pointers). -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] What's the status of Maciej's Smart Pointer enhancements?
2018-04-30 13:15 GMT+02:00 Anthony Walter <sys...@gmail.com>: > Okay great. Thanks for the information. I'll experiment with the smart > pointers and their potential performance impact. In the interim I've > created a solution using the approach of records containing private > reference counted interfaces. Here is an example of my JSContext record: > Internal interface is also proper solution, all depends on use-case. Anyway in my previous post I mean that every execution of constructor in trunk (even without smart pointers/management operators in any place) is slower than in 3.0.* (in most of cases the difference is very subtle, just additional call to "int_initialize" in TObject.InitInstance (rtl\inc\objpas.inc file) - with FastRTTI this problem is solved). -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] What's the status of Maciej's Smart Pointer enhancements?
2018-04-29 21:26 GMT+02:00 Anthony Walter <sys...@gmail.com>: > I wanted to know from the people who make decision about what to merge, > what's the status of rolling his enhancements at following location into > FPC trunk? > The key part of smart pointers (management operators) is already in trunk (as Sven said). Btw. you forgot about AddRef operator ;) The problem is more complicated than just "merge" for "default field". *** part 1 *** The first problem is slowdown for constructors for classes (which already is part of trunk, trunk is a little slower than 3.0.x for constructors). The main reason of " slowdown" is new feature "management operators". The solution (and improvement) is FastRTTI which is designed for management operators and all managed types: https://github.com/maciej-izak/freepascal/tree/fastrtti with these patch FPC is faster for all classes/records/objects with managed types. This patch is not only designed as patch for constructors but the gain is more general, for all managed types the result is really good - the execution of code is even few times faster when you use a lot of managed types. Compiler compilation with FastRTTI is always faster around 1%-3% (where usage of managed types is rather rare). The hardest part for me of implementation of FastRTTI was testing (I don't use AVR nor i8086 nor m68k) , but this is ready: https://travis-ci.org/maciej-izak/fpc-ci-tests/builds/320484 786?utm_source=email_medium=notification this part was really depressing :P. The last thing what I must finish is renaming "holes" to "unmanaged_spaces" x) (personally I prefer the "holes" but I must agree with Sven that the "holes" term is not perfect). *** part 2 *** The default field. The topic is complicated on many fields, but generally we have 2 issues, raised by Jonas : - existence of @@ and @@@ operators: https://github.com/maciej-izak/PascalSmartPointers/blob/mast er/tests/tdefaultfield6.pp https://github.com/maciej-izak/PascalSmartPointers/blob/mast er/tests/tdefaultfield14.pp https://github.com/maciej-izak/PascalSmartPointers/blob/mast er/tests/tdefaultfield21.pp https://github.com/maciej-izak/PascalSmartPointers/blob/mast er/tests/tdefaultfield22.pp - handling procedures/methods parameters (especially for var/out which is not listed below) https://github.com/maciej-izak/PascalSmartPointers/blob/mast er/tests/tdefaultfield25.pp https://github.com/maciej-izak/PascalSmartPointers/blob/mast er/tests/tdefaultfield26.pp as solution was proposed new type kind, but IMO new kind just for default field is redundant. What with further usage of "default field" for classes and objects (maybe now it looks like nonsense but should be usefully with ARC combination with classes)? Again new types? I don't wan't to lock this path (default field for classes and objects). possible alternative is "strict" modifier https://github.com/maciej-izak/PascalSmartPointers/blob/mast er/tests/tdefaultfield30.pp "strict default" may be the solution, the record with "strict default" may have more strict policy in compiler to make all of us happy. If someone needs to use "default field" as more advanced precise helpers - just use "default". If strict policy is more important (like for Jonas, some part of me agree with him) then use "strict default". Technically all for smart pointers is ready. -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Wrong docs: not initialized global variables
2018-03-24 20:49 GMT+01:00 Ondrej Pokorny <laza...@kluug.net>: > Does it mean I can assume a local string variable is always (=whenever the > routine is called) initialized to ''? I.e. that TestB always returns 'a'? > > function TestB: string; > var B: string; > begin > B := B + 'a'; > Result := B; > end; > > Until now I though that the above code is unsafe and I always initialized > all local variables (also managed) before use. I assumed the initialization > to empty string does not need to happen at every routine call. > Please note that string/dynamic array as Result is exception (it works like *var* parameter). IMO this is the ugliest Pascal behavior ever: === example begin === function test1: string; begin Result := Result + 'a'; end; function test2: TArray; begin SetLength(Result, Length(Result) + 1); end; begin writeln(test1); // print a writeln(test1); // print aa writeln(test1); // print aaa writeln(test1); // print writeln(Length(test2)); // print 1 writeln(Length(test2)); // print 2 writeln(Length(test2)); // print 3 writeln(Length(test2)); // print 4 end. === example end === -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Static class methods can or cannot be virtual?
2018-01-22 18:48 GMT+01:00 Mattias Gaertner <nc-gaert...@netcologne.de>: > On Mon, 22 Jan 2018 18:45:57 +0100 > Maciej Izak <hnb.c...@gmail.com> wrote: > > Correct. There was some topic about "static class methods" and "class > > property" some time ago on fpc-devel or in fpc-pascal. For example static > > class methods can be used as callback procedure for external > APIs/Libraries. > > Can you explain what external APIs/Libraries have to do with class > properties? > "Class property" was not mentioned in the part about "external APIs/Libraries". -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Static class methods can or cannot be virtual?
2018-01-22 18:25 GMT+01:00 Denis Kozlov <dez...@gmail.com>: > I presume then there is no way for having a class property who's returned > value can be dynamically changed in child classes? In other words, class > property getters/setters can only be implemented by the class that declared > the property. > Correct. There was some topic about "static class methods" and "class property" some time ago on fpc-devel or in fpc-pascal. For example static class methods can be used as callback procedure for external APIs/Libraries. -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Static class methods can or cannot be virtual?
2018-01-22 18:00 GMT+01:00 Denis Kozlov <dez...@gmail.com>: > Can static class methods be virtual? > This was bug, fixed in trunk (see my rev. 35724) -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Allow record helper inheritance in Delphi mode
2017-09-01 18:30 GMT+02:00 Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org>: > I'd prefer to keep that syntax for aspects or as alternative attribute > syntax instead of wasting it for helpers that are defined to work based on > the type > +1 :))) so we have nice topic to talk. I have hope that you remember our last long conversation about default field? Since that time I've done work around aspects and smart pointers / nullable types too (and syntax with "with" is also related and can aspects can coexist with my proposition for helpers - anyway we will discuss this later in other topic). All syntax/conceptual problems mentioned last time by Jonas for default field are solved. But I don't want to start yet another discussion around new patch, especially that FastRTTI is in last phase ;) (I hope so). -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Allow record helper inheritance in Delphi mode
2017-09-01 14:30 GMT+02:00 Michael Van Canneyt <mich...@freepascal.org>: > >> No, directives won't be abused for something like that. >> > > I am glad I am not the only one who thins so :) I like experiments as you know. Thanks for critical words as always :P. But this time I must agree too. :) Only one experimental option left in my mind for this: s: string with TH1, TH2; but for now probably hardcasting is the best what we can. -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Allow record helper inheritance in Delphi mode
2017-09-01 11:41 GMT+02:00 Stefan Glienke <sglie...@dsharp.org>:
> Again you will cause unnecessary headaches because now your helper has the
> dependency of the builtin and the third party one.
> How would third party one and third party two implement them? They both
> probably would extend the builtin one. Which one can you use in your code
> then?
> Yes, the one that comes last in the uses. What if you want to use
> functions from both? Out of luck again.
>
> Inheritance regardless what form is never is the best option here. I think
> "ancestor list" is just a misnomer in the documentation as it cannot be a
> list but only one in case of class helper.
The control of modules order in uses section can turn programmers life into
real hell for type helpers. I think that new directive
$EXPLICITHELPERS should help :
type
TH1 = record helper for string
procedure foo;
procedure foo1;
end;
TH2 = record helper for string
procedure foo;
procedure foo2;
end;
TH3 = record helper for string
procedure foo;
procedure foo3;
end;
var
s: string;
begin
s.foo; // call TH3.foo
{$EXPLICITHELPERS TH1 for string} // scope for helpers limited only to TH1
s.foo; // call TH1.foo
s.foo3; // error
{$EXPLICITHELPERS TH2, TH1 for string}
s.foo; // call TH2.foo
s.foo1; // call TH1.foo1
{$EXPLICITHELPERS default for string}
s.foo; // call TH3.foo
{$EXPLICITHELPERS TH1, default for string}
s.foo; // TH1.foo
s.foo1;
s.foo2;
s.foo3;
end.
--
Best regards,
Maciej Izak
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Allow record helper inheritance in Delphi mode
2017-08-29 22:09 GMT+02:00 Ondrej Pokorny <laza...@kluug.net>: > I, on the contrary, read: > > On 29.08.2017 18:54, Sven Barth via fpc-devel wrote: > > (btw: a type helper for a primitive type can inherit from a record > helper of the same type, internally they're all the same) > but in this example you have different kind of inheritance (type helper from record helper). "internally" is the key word ;) > Btw. record helpers support inheritance in all modes but Delphi. It > doesn't make sense to disallow it for record helpers but allow it for type > helpers... Too overcomplicated without any plus value :/ > what if Delphi will decide to introduce some new exotic syntax/extension/feature for "record helper"? With "type helper" and modeswitch typehelpers usage of inheritance still will be possible in Delphi mode and is safer :). You have also right, so inheritance in Delphi mode for record helpers should be "undefined" but you don't like this, so I have no idea how you want to convince Sven to "record helpers" inheritance in Delphi mode :P. Good luck ;) -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Allow record helper inheritance in Delphi mode
2017-08-29 17:51 GMT+02:00 Ondrej Pokorny <laza...@kluug.net>: > On 29.08.2017 17:47, Anthony Walter wrote: > > Out of curiosity, is there any strategy that is or can be employed to > ensure new language features and mode switches automatically work with > codetools and by extension the Lazarus IDE? > > Or is duplication of effort the only way to get codetools properly parsing > new language features? > > > "duplication of effort" is the correct answer :) > for codetools synchronized with compiler we should have: * new frontend for compiler (dual licensing GPL/LGPL with static linking exception would be cool for 3rd tools) * or smart plugins system for compiler * or some other hardcore solution :) -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Allow record helper inheritance in Delphi mode
2017-08-29 20:24 GMT+02:00 Ondrej Pokorny <laza...@kluug.net>: > No - please not yet another undefined behavior :) > > It's perfectly defined: disabled without typehelpers, enabled with > typehelpers. > but in the case of strictly defined rules we must to do as Sven said: "Namely that it enabled the "type helper" syntax including the inheritance. But the record helpers are left as is..." it is contrary to your previous message: + It means that record helper inheritance will be enabled with typehelpers > as well because if I am not mistaken currently the compiler cannot > distinguish between a type helper and record helper acting on a record. > (IMO it is even a plus.) > in "Svens scenario" inheritance for "record helper" should be blocked in Delphi mode and compiler is obligated to knows differences between "type helper" and "record helper". By "undefined behavior" I mean allowing inheritance for "record helper" in Delphi mode *for now* because is not harmful (especially with switch typehelpers). "for now" means years or even forever. If you wish to have strictly defined rules for "record helpers" inheritance in Delphi mode it simple means no inheritance for such case as is in Delphi :) -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Allow record helper inheritance in Delphi mode
2017-08-29 18:54 GMT+02:00 Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org>: > Maybe it would indeed make more sense to adjust the meaning of the > typehelpers modeswitch in mode Delphi... Namely that it enabled the "type > helper" syntax including the inheritance. But the record helpers are left > as is... (btw: a type helper for a primitive type can inherit from a record > helper of the same type, internally they're all the same) > > This way we won't need a new modeswitch... > +1 for single modeswitch. In my case both would be used all the time. IMO inheritance for record helpers in Delphi mode has no really meaning and may stay as undefined behavior (finally we have many non Delphi behaviors available in Delphi mode), even more - it is nice addition :). -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Allow record helper inheritance in Delphi mode
2017-08-29 10:37 GMT+02:00 Ondrej Pokorny <laza...@kluug.net>: > Hmm yes. Reading https://www.freepascal.org/doc > s-html/3.0.2/prog/progsu105.html you can define other non-delphi > extensions for the Delphi mode (like NESTEDCOMMENTS). > > Maybe it would be more clear to name the modeswitch TYPEHELPERINHERITANCE > and don't bind it to delphi mode? IMO the switch should be related strictly to unified type helpers usage. I prefer to have also "type helper for" also in Dlephi mode instead of "record helper for" for simple types. Different syntax for the same thing is very annoying especially when someone need to work in many modes. -,- -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch #31249 and objects
2017-01-31 19:35 GMT+01:00 Sven Barth <pascaldra...@googlemail.com>: > A little sidenote: the "day unique" part of an internal error is > supposed to be two digits and to start from 1, so your internal error > should have been 2017011801 instead of 201701180 (I've corrected that > already). > Ok. Another sidenote to remember. :) > I still can't recommend the way it's done in mORMot. This will break > each time the binary format of the RTTI changes. Take my adjustment of > TProcedureParam.Flags (now .ParamFlags) for example which I changed from > Byte to TParamFlags which not much later changed its size from Byte to > Word due to newly added elements. You might not catch such a change > especially if it should be used in a seldomly used code branch. > ...and that is why we have NewPascal also as "buffer". When someone is using NewPascal instead of pure FPC trunk, can be sure that he has right version of FPC trunk for mORMot. My every day starts from checking what is new in ncgrtti and typinfo :) so don't worry. Anyway I am just human, so maybe more detailed test suite for RTTI binary consistency is good idea. Whatever we discuss here I can't make such decision. IMO only main author of mORMot (Arnaud Bouchez) has rights for such important changes. > My suggestion would be an RTTI abstraction that makes use of inline > methods/properties as part of objects/records to access the Delphi and > FPC RTTI. > And we have that abstraction too (!)... The most painfully part is collecting the data in optimal way (also part of data lands into cache) and we need to keep single code base as possible with many versions of Delphi which is not trivial task. > For example another change that will come up in the near future will be > a link from the TTypeData to the unit its contained in which will again > lead to a shift in fields. > We have a lot of "breaking changes" behind us. We will take the challenge. ;) -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch #31249 and objects
2017-01-31 14:56 GMT+01:00 Sven Barth <pascaldra...@googlemail.com>: > Anyway, I'll try to get it applied tonight. Thanks :) -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch #31249 and objects
2017-01-31 14:56 GMT+01:00 Sven Barth <pascaldra...@googlemail.com>:
> I "ignored" it, cause up to now it was merely a performance improvement.
> If you had added your info from 31305 to 31249 instead of creating a new
> report then I might have reacted faster.
>
Very sad info. 31305 costed me additional time. 31305 is separate problem
so has separate ticket. I didn't knew about 31305 until today.
> Anyway, I'll try to get it applied tonight.
>
> PS: If you adjust mORMot then I highly suggest you not to use custom
> records/objects, but the typinfo ones as much as possible as they deal with
> alignment issues correctly (especially the new types of the interface
> RTTI). Or at least use the typinfo types to retrieve pointers to the
> correct parts of the RTTI and store those instead of using inc()s to
> navigate the RTTI.
>
Not that simple, almost impossible to use only TypInfo. mORMot has support
for very large range of compilers: FPC >= 2.6.4 and Delphi >= 5... Custom
records/objects are often the only way to keep sensible code base... mORMot
has own aligntoptr implementation (which is different for each compiler and
platform if needed). aligntoptr is used together with inc()s. TypInfo is
generally incompatible in many ways between Delphi and FPC so we have a lot
of $IFDEFs for low level RTL / RTTI and own structures.
Thanks to mORMot and NewPascal initiative ("fork" is wrong word - NewPascal
exist like more stable predictable trunk with few additional
features/previews) we can keep real single code base between Delphi and FPC.
--
Best regards,
Maciej Izak
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Patch #31249 and objects
Hi, Somehow my patch #31249 was ignored. Could someone from core team look at : http://bugs.freepascal.org/view.php?id=31249 http://bugs.freepascal.org/view.php?id=31305 patch and reported bug is very important. I can't update mORMot for newest FPC RTTI without changing all objects to records (which is possible in this case but still we have serious bug)... -,-. Thanks. -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Management operators : Copy and Clone confusion...
2017-01-19 10:44 GMT+01:00 Michael Van Canneyt <mich...@freepascal.org>: > > At the risk of writing nonsense: > Seems ok to me :) > > I would think that a method name should give a clue as to what it actually > does. > In that sense AddRef/Clone seems better to me ? > (unless Copy does something else besides increasing the ref count ?) > > AddRef is clear to anyone, I think. > > If I see "Clone", I immediatly think of an object whose properties are a > copy of > the original, but which otherwise has nothing to do with the original. current "Clone" works like expected: (1) https://github.com/maciej-izak/PascalSmartPointers/blob/1ecf773128b523a328a11f30a9b766858ac57c99/sources/SmartObj.pas#L63-L77 (2) https://github.com/maciej-izak/PascalSmartPointers/blob/1ecf773128b523a328a11f30a9b766858ac57c99/sources/SmartPtr.pas#L62-L76 "Copy" in (1) and (2) looks somehow strange for me. But for example for Nullable type, convention proposed by Florian is not bad: (3) https://github.com/maciej-izak/PascalSmartPointers/blob/1ecf773128b523a328a11f30a9b766858ac57c99/sources/Nullable.pas#L115-L143 "Clone" seems like right move for all examples. But together with "Copy" IMO is crappy. AddRef in (3) is not correct at all but for (1) and (2) is perfect. Maybe I thinking too much by RTL and Copy/Clone is not that bad? Anyway is hard for me to ignore RTL... Copy operator with single parameter seems for me really strange. When I starting any of new code for management operators my first declaration looks like: class operator Copy(constref Src: T; var Dest: T); // >.< meh... TLTR: Clone might stay as-is but what with "class operator Copy(var Rec: TNullable);"? AddRef for example (3) might be bad idea. Current pair Copy/Clone operators is used in different context for different ideas. At the end RTL naming convention (AddRef/Copy) might be not bad... -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Management operators : Copy and Clone confusion...
Hi,
in patch/feature proposed in http://bugs.freepascal.org/view.php?id=30687
we have Copy/Clone operators naming convention proposed by Florian (my
initial idea was AddRef/Copy).
I'd like to say that Copy/Clone naming convention is terrible in practical
usage. :( As the main author I have many troubles and I have always
confusion >.< I always must to check which is for adding reference and
which one is for copying...
For example Paul Ishenin said in previous discussion ("ANN: Management
operators - final patch") : I know Florian insisted on Copy and Clone names
but still for my taste it would be the best to have conformity between
compiler and RTL.
In current FPC implementation of management operators "Copy" operator is
*always* used for increasing reference count and "Clone" operator is used
to create copy... In this area I have objections for my own patch.
Maybe someone have other ideas? Maybe we could back to AddRef/Copy which is
RTL compatible and is more "real life" friendly?
--
Best regards,
Maciej Izak
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Public interface for Record Init Table
Hi, new patch for RTTI is ready (initially discussed in "RTTI module and "IsManaged" critical problem"), anyway I think is needed some review... http://bugs.freepascal.org/view.php?id=31123 The TRecInitData IMO is better naming than TRecInitTableData because is more opened for management operators (or for some other data) in the future. Also field name RecInitInfo looks better than RecInitTable. RecInitInfo is nice complement part for RecInitData property. -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] GetTypeKind for Generics
2016-12-15 17:13 GMT+01:00 Sven Barth <pascaldra...@googlemail.com>: > There is already a bug report for this and a few other functions (don't > know the bug ID right now however). http://bugs.freepascal.org/view.php?id=28357 -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI module and "IsManaged" critical problem
2016-12-14 20:06 GMT+01:00 Sven Barth <pascaldra...@googlemail.com>: > I found the "problem": write_rtti_ref() will always write an indirect > reference (which is by design), so I adjusted the code that it will > really write a direct one. Bye, bye, one level of indirection ;) > ^_^ but... I found another problem. We have small typo for RTTIRecordRttiInfoToInitInfo. Please merge ASAP http://bugs.freepascal.org/view.php?id=31118 otherwise InitializeArray FinalizeArray will stay totally broken >.< -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI module and "IsManaged" critical problem
2016-12-14 11:17 GMT+01:00 Sven Barth <pascaldra...@googlemail.com>: > It should be a Pointer of course, not a PPointer... I will correct that > later on (I shouldn't commit code that late -.- ). > > So I will wait again ^^ > PPU version is only increased if the structure of the PPU file is changed. > That RTTI change has nothing to do with the PPU. > Yes, that is true, but I want to be sure :) , at the end we have change in critical place. This change is big step forward in right direction. -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI module and "IsManaged" critical problem
2016-12-14 0:16 GMT+01:00 Sven Barth <pascaldra...@googlemail.com>: > At least the patch as is (with PPointer) didn't trigger anything on > Win64... > > Will it stay as PPointer (PPRecInitTable)? I am wondering why we have bug (or expected behavior?) for this. > Committed with a few adjustments. Now I only need to update User Changes > Trunk, but I'll do that tomorrow *yawns* > Thanks... Now I need to merge "few adjustments" into NewPascal -,-' Shall we increase CurrentPPUVersion or we will wait some time (we have many changes pending so probably inc for CurrentPPUVersion has not much sense yet)? -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI module and "IsManaged" critical problem
2016-12-13 14:31 GMT+01:00 Sven Barth <pascaldra...@googlemail.com>: > No idea. But I have a couple of platforms to test this on myself :) > (x86_64-win64, i386-win32, powerpc-darwin, i386-linux, x86_64-linux, > arm-linux, m68k-linux > It is easy to reproduce with PRecInitTable. You can play with "*PART 2* patch" with PRecInitTable/PPRecInitTable pointers and InitializeArray/FinalizeArray for records. > Okay, will do that either tonight (don't know yet whether I'll have the > time however) or hopefully tomorrow evening. > ^^ I will wait. Not bad info :) -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI module and "IsManaged" critical problem
2016-12-13 11:09 GMT+01:00 Sven Barth <pascaldra...@googlemail.com>: > Comment regarding your previous mail: right, I forgot that due to > InitializeArray() and FinalizeArray() being publicly available version of > the internal helpers we either need to keep INIT and FULL RTTI in sync or a > way to differentiate them... That's why you added the Terminator field I > guess? > Exactly. > Okay, I think we can indeed go with this aside from one small remark: the > double indirection for Pointers is only needed if data resides in different > units as those might be in different dynamic packages. Since the INIT and > FULL RTTI of a record are always in the same unit a single indirection is > sufficient (thus PRecInitTable instead of PPRecInitTable). > IIRC something is (was?) wrong (AV) for Mac i386 and Win64 when is used PRecInitTable instead of (indirect) PPRecInitTable... It is strange because for example for Win32 and Aarch64 PRecInitTable works fine... Have you an idea? > Other than that I think we've found a good compromise for our wishes and > hopes for this :) > Phew! So... Please merge PART 2 of MO :P after this step I can start work on RTTI.pas and on extended info for records (with small "baby steps" ofc). -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI module and "IsManaged" critical problem
2016-12-12 23:14 GMT+01:00 Maciej Izak <hnb.c...@gmail.com>:
> With second iteration we could add your modifications, I have no other
> objections.
New day new ideas :)
With my patch we don't really need ManagedFieldCount, ManagedFields,
ManagedFieldTable in TTypeData (each of Managed* can still be added later).
It means also much better memory usage and it solves RTL problems (which
was mentioned in my previous message). All what we need is:
=== code begin ===
type
TInitManagedField = record
TypeRefRef: TypeInfoPtr;
FldOffset: SizeInt;
end;
PPRecInitTable = ^PRecInitTable;
PRecInitTable = TRecInitTable;
TRecInitTable = packed record
Size: Longint;
Terminator: Pointer;
ManagedFieldCount: Longint;
{ ManagedFields: array[0..ManagedFieldCount - 1] of TInitManagedField
; }
end;
TRecordField = record
Visibility: TVisibility;
TypeRef: TypeInfoPtr;
FldOffset: SizeInt;
Name: PShortString; { can be NULL if no ext RTTI }
end;
TManagedField = TRecordField deprecated;
TTypeData = record
// ...
tkRecord: (
RecSize: Integer;
RecInitTable: PPRecInitTable;
case Boolean of
True: (ManagedFldCount: Integer deprecated 'Use
RecInitTable^^.ManagedFieldCount
or TotalFieldCount depending on your use case')
False: (TotalFieldCount: Integer)
{ Fields: array[1..TotalFieldCount] of TRecordField }
{ Names: array[1..TotalFieldCount] of {packed} ShortString }
);
end;
=== code end ===
I have hope that this is final solution :)
--
Best regards,
Maciej Izak
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI module and "IsManaged" critical problem
2016-12-12 20:41 GMT+01:00 Sven Barth <pascaldra...@googlemail.com>: > So, my own idea for this. First insight looks good (kudos for union with "deprecated field" ^^) and we don't have redundant info, but sorry it can't work in presented form. With your changes INIT RTTI is incompatible with RTTI, which is critical defect for RTL. FPC_(INITIALIZE|FINALIZE|COPY|ADDREF) (rtl/inc/rtti.inc) is used in many contexts - both for internal usage (where generally is used INIT RTTI) and for external usage (with regular RTTI). Since we have InitializeArray/FinalizeArray/CopyArray is possible to execute FPC_(INITIALIZE|FINALIZE|COPY) with RTTI for records (instead of INIT RTTI for records) which means AV. To solve this issue you need obligatory to add RecInitTable: PPointer; (and Terminator for INIT RTTI). To move forward presented patch is obligatory: https://github.com/maciej-izak/freepascal/commit/ea23ca80630fae488990dcd4bc62ddc94b18d304 *PART 2* http://bugs.freepascal.org/view.php?id=30687#c96093 This is first step. With second iteration we could add your modifications, I have no other objections. See above patch - it is already prepared for differences between INIT RTTI (TRecordInfoInit) and FULL RTTI (TRecordInfoFull) Finally we can merge both ideas. User has access to: * Classical array of compact "managed field" by RecInitTable * All fields * All managed fields (in your solution it has sense) -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI module and "IsManaged" critical problem
2016-12-12 15:53 GMT+01:00 Maciej Izak <hnb.c...@gmail.com>: > Field: TManagedField; // :\ a little redundant info (we have this info > also in TotalFields, but we need to deal with $RTTI EXPLICIT) To save memory I think we can use FieldIndex: Integer (instead of Field: TManagedField). FieldIndex is index to TotalFields item... -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI module and "IsManaged" critical problem
2016-12-12 13:32 GMT+01:00 Maciej Izak <hnb.c...@gmail.com>:
> Status of #31102 is unclear. I need clear response about ManagedFldCount
> to decide how to do it - as part of FPC or NewPascal or some mixed way to
> keep compatibility as much as possible (in NewPascal for sure I will
> correct ManagedFldCount, current value of ManagedFldCount and form of
> ManagedFields is unacceptable).
My more complex proposition from point 2. Full backward compatible... Fair
enough, ready for Management Operators + fix for Initialize/FinalizeArray:
=== code begin ===
type
PPRecInitTable = ^PRecInitTable;
PRecInitTable = TRecInitTable;
TRecInitTable = packed record
Size: Longint;
Terminator: Pointer;
ManagedFieldCount: Longint;
{ ManagedFields: array[0..ManagedFieldCount - 1] of TManagedField; }
end;
TRecordTypeField = packed record
Field: TManagedField; // :\ a little redundant info (we have this info
also in TotalFields, but we need to deal with $RTTI EXPLICIT)
Flags: Byte; // visibility
Name: ShortString;
end;
TTypeData =
...
{ tkRecord }
property ManagedFldCount: Integer read GetManagedFldCount;
deprecated 'Use TotalFieldCount'; // return TotalFieldCount
...
tkRecord: (
RecSize: Integer;
RecInitTable: PPRecInitTable; // here is accessible
ManagedFieldCount and ManagedFields
TotalFieldCount: Integer;
{TotalFields: array[0..TotalFieldCount - 1] of TManagedField;
RecFldCnt: Integer; // for $RTTI EXPLICIT ... FIELDS
RecFields: array[0..RecFldCnt - 1] of TRecordTypeField});
=== code end ===
So merge for PART 2 of Management Operators might be not bad idea:
https://github.com/maciej-izak/freepascal/commit/ea23ca80630fae488990dcd4bc62ddc94b18d304
Now I feel that all of my ideas to solve this are expressed.
--
Best regards,
Maciej Izak
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC internal linker issues with Win64 .a startic-link libraries by GCC newer than 4.8.1
2016-12-12 14:27 GMT+01:00 Sven Barth <pascaldra...@googlemail.com>:
> I'm still thinking about a solution that will satisfy both of our points
> as good as possible - yes, I already have an idea. Maybe I'll share it this
> evening when I'm home again.
>
Do you mean :
=== code begin ===
TRecordTypeField = packed record // without "Field: TManagedField"
Flags: Byte; // visibility
Name: ShortString;
end;
...
{ tkRecord }
property ManagedFldCount: Integer read GetManagedFldCount;
deprecated 'Use TotalFieldCount'; // return TotalFieldCount
...
tkRecord: (
RecSize: Integer;
ManagedFieldCount: Integer;
TotalFieldCount: Integer;
{TotalFields: array[0..TotalFieldCount - 1] of TManagedField;
ManagedFields: array[0..ManagedFieldCount - 1] of TManagedField; //
or indirect pointer to init table ?
RecFields: array[0..TotalFieldCount - 1] of TRecordTypeField});
=== code end ===
Full backward compatible... Fair enough and a little Delphi incompatible
(it is already incompatible so no big difference and no redundant info for
TRecordTypeField)
> Then don't pick such controversial topics :P
>
You never know what is controversial :P. Core team is unpredictable. ;)
--
Best regards,
Maciej Izak
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI module and "IsManaged" critical problem
2016-12-12 13:07 GMT+01:00 silvioprog <silviop...@gmail.com>: > Could you do that please? :-) Status of #31102 is unclear. I need clear response about ManagedFldCount to decide how to do it - as part of FPC or NewPascal or some mixed way to keep compatibility as much as possible (in NewPascal for sure I will correct ManagedFldCount, current value of ManagedFldCount and form of ManagedFields is unacceptable). -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC internal linker issues with Win64 .a startic-link libraries by GCC newer than 4.8.1
2016-12-09 13:49 GMT+01:00 Sven Barth <pascaldra...@googlemail.com>: > Improvements for cppclass are definitely welcome :) Rather not mine :P I have packed cppclass into record. For "wrapped cppclass" I have "default" field (aka proxy record) for direct access combined with "managament operators" to handle "new" & "destroy" operators. I have always many troubles with my patches/reports (many times reopened - #25610, #25607, long pending time - #27206, not merged - #30687). I don't have real response about ManagedFldCount (#31102) nor vManagedTable topic. I always need to use many arguments to force my changes (even simple and basic changes). It costs me many time, energy and nerves. I see no sense in contributing improvements for cppclass. Especially that Jonas is in opposition to default field/proxy records. I have patch for this but... It has no sense. #30687 is not merged yet, so what is the sense for contributing "yet another big patch" when I am not sure about future of #30687 which is base for many new patches? I will continue my work in less problematic topics like minor/major bug fixes for FPC. Improved cppclass will be merged to NewPascal because I can't see any chance in FPC trunk for my modifications. Good deal for all :). -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI module and "IsManaged" critical problem
2016-12-11 13:18 GMT+01:00 Maciej Izak <hnb.c...@gmail.com>: > http://bugs.freepascal.org/view.php?id=31102 I can provide proper patch for #31102 and for #31108 (for fields part). TotalFieldCount seems redundant (finally we have in conception RecFldCnt), we could point deprecated ManagedFldCount property to RecFldCnt. New ManagedFieldCount might be compromise solution. Anyway I have feeling that keeping both : ManagedFldCount and ManagedFieldCount is very bad idea (especially with new layout for ManagedFields which must contains managed fields only). -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI module and "IsManaged" critical problem
2016-12-10 0:54 GMT+01:00 Sven Barth <pascaldra...@googlemail.com>:
> We rename ManagedFldCount to TotalFieldCount, add a field
> ManagedFieldCount and a property ManagedFldCount that returns
> TotalFieldCount for backwards compatibility (and maybe marked as
> deprecated).
>
I've created new bug report to express my strong stand about this problem:
http://bugs.freepascal.org/view.php?id=31102
(copied from bug report)
FPC has long standing critical issue. ManagedFldCount field in TypInfo
(TTypeData) contains "count" for all fields (but should contains "count"
for managed fields only - as name suggest). It is not feature but highly
visible bug.
* The bug has critical meaning for development of RTTI.pas because is
impossible to implement in rational way IsManaged function (ManagedFldCount
is used for that)
* The bug has many performance issues especially for
InitializeArray/FinalizeArray.
* The bug means more Delphi incompatibility RTTI.
* For scripting languages it means many troubles (for Delphi porting code)
* TManagedField entry for each (I mean here unmanaged fields) field has
zero value for programmer, it has no sense.
any partial fix with pseudo backward compatibility has no sens and will
bring much more noise and confusion and more complicated RTTI code without
real gain.
the proper layout for part related to records (in current state) in
TTypeData is:
tkRecord: ( // could be extended for info about attributes, methods
and operators (maybe also properties)
RecSize: Integer;
ManagedFldCount: Integer;
{ManagedFields: array[0..ManagedFldCnt - 1] of TManagedField;
RecFldCnt: Integer;
RecFields: array[1..RecFldCnt] of TRecordTypeField});
where
TRecordTypeField = packed record
Field: TManagedField;
Flags: Byte; // visibility
Name: ShortString;
end;
When we have additional "Name" and "Flag" for managed and unamanaged fields
it has sense, because when we have more info than pure TManagedField for
each field, it could be used for ORM or for scripts. Probably is good idea
to correlate RecFields together with:
{$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}
The patch provided in #29767 is wrong when we thinking about extended RTTI
(init table should stay simple as possible), same for MO PART 2 (
http://bugs.freepascal.org/view.php?id=30687#c96093 )
It must be changed same as was needed change for indirect type info
(PPTypeInfo) for greater good.
--
Best regards,
Maciej Izak
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI module and "IsManaged" critical problem
10.12.2016 00:54 "Sven Barth": We rename ManagedFldCount to TotalFieldCount, add a field ManagedFieldCount and a property ManagedFldCount that returns TotalFieldCount for backwards compatibility (and maybe marked as deprecated). Looks almost like point 4. We need also to adjust ManagedFields. ManagedFieldCount is not enough. User still is unable to figure which fields are managed without many additional conditions -,- . Delphi layout: ManagedFields: array[0..ManagedFldCnt - 1] of TManagedField; NumOps: Byte; RecOps: array[1..NumOps] of Pointer; RecFldCnt: Integer; RecFields: array[1..RecFldCnt] of TRecordTypeField; RecAttrData: TAttrData; RecMethCnt: Word; RecMeths: array[1..RecMethCnt] of TRecordTypeMethod In this context TotalFieldCount looks like yet another incompatibility. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI module and "IsManaged" critical problem
5. Super slowly checking for each field in ManagedFields, and eventually new checking for each record in ManagedFields... I am so sad that I need to post this point :\ -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] RTTI module and "IsManaged" critical problem
Hi, thanks Sven, finally we have initial RTTI.pas version on trunk. Let me start with first serious issue and eventually patch: function IsManaged(TypeInfo: PTypeInfo): boolean; IsManaged can't work with records because we need know managed fields count (in Delphi when ManagedFldCount is bigger than 0 it means that record has managed fields and problem is solved). Two possible (and IMO correct) solutions: 1. I think it's time to new position in "User Changes" wiki page. We can fix that by new behavior (a more Delphi compatible, more logical, more proper and a little incompatible with old code, but the risk is minimal): ManagedFldCount should be fixed/corrected as mentioned in http://bugs.freepascal.org/view.php?id=29767 (so it should count *real* managed field as the name "ManagedFldCount" suggests. Otherwise we can't implement this function. Btw. old behavior for ManagedFldCount will be not usefully anymore with RTTI module/improved TypInfo for counting all fields. 2. http://bugs.freepascal.org/view.php?id=30687#c96093 PART 2 of reworked patch for Management Operators should be accepted. With this path we have access to Init RTTI table. Anyway solution 1 is strongly recommended. Other "solutions" (IMO totally wrong): 3. New compiler intrinsic routine: function IsManagedType(T: Type): Boolean; which is no real alternative because IsManaged from RTTI.pas is more run-time dedicated and is impossible to replace IsManaged by IsManagedType for all scenarios. Generally new intrinsic IsManagedType is not wrong but in our context is useless... 4. New additional RTTI generated for records, for example new field for TTypeData: ThisIsRealAndNotFakeManagedFldCount: Integer; with additional list declared after ManagedFields: array[1..ManagedFldCount] of TManagedField: ThisIsRealAndNotFakeManagedFields: array[1..ThisIsRealAndNotFakeManagedFldCount] of TRealAndNotFakeManagedField Or some flag in TTypeData for records: YesIamManagedRecordAndIHaveRealManagedFieldsAndYesPleaseIgnoreManagedFldCountWhichIsLying: boolean; -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC black list details
2016-12-08 13:04 GMT+01:00 Jonas Maebe <jonas.ma...@elis.ugent.be>: > > The problem is that the bug report is about resolving calls specific to > Objective-Pascal, which is only supported (and hence tested) on > Darwin-based platforms by FPC (Mac OS X/OS X/macOS, iOS). So your testing > probably did not cover this. If Alf confirms it works fine with trunk, I'll > check your patch. You were right... I was so close :\. Now I need to find some mac for better testing experience. Thanks for improved version. -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Improved RTTI compromise
2016-12-09 21:53 GMT+01:00 Sven Barth <pascaldra...@googlemail.com>: > Also when you have extended the unit and provide your changes: please > use baby steps, not one big patch to rule them all ;) > Thanks for tips for tests. I will start new topic - we need to discuss one critical aspect... -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC internal linker issues with Win64 .a startic-link libraries by GCC newer than 4.8.1
2016-09-18 2:31 GMT+02:00 Benjamin Rosseaux <benja...@rosseaux.de>:
> i've noticed a weakness of the FPC internal linker at static-linking .a
> libraries on the Win64 target, which're generated by GCC newer than 4.8.1,
> due to the new refptr.* and .refptr.* symbols-can-be-multiple-defined
> stuff (inside one single .a library file), which was introduced in newer
> GCC versions.
>
I don't have the real patch for this yet but I have my inner tool to rename
all duplicated symbols for statically linking FPC with C++ code (I have
improved cppclass type). My tool uses objconv :
http://www.agner.org/optimize/#objconv . Rename for symbols is simple with
few commands for objconv ("-dfhs" to list symbols and "-nr" to rename).
Anyway your temporary patch might be better for statically linking with
SDL2...
--
Best regards,
Maciej Izak
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC black list details
2016-12-08 14:34 GMT+01:00 Sven Barth <pascaldra...@googlemail.com>: > Small formal note: you should check the coding style of your patch again. > There are superfluous spaces among some expressions. ;) (also we tend to > use assigned() instead of a check for nil with (in)equality) True, thanks for note. Even spaces around "=" are wrong, and useless "objdef: tobjectdef;" local variable. The patch is much older than MO (almost 2 years old, was created before my more serious compiler work), I forgot to rework this part. :\ Should I rework this patch again? -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC black list details
2016-12-08 12:15 GMT+01:00 Jonas Maebe <jonas.ma...@elis.ugent.be>: > Does this version of the patch fix the issue from > http://bugs.freepascal.org/view.php?id=31081 ? Or is your change > (probably) unrelated to that? > I think it is unrelated but we need to wait for report from Alf. If it is caused by calc_distance I will try to improve the patch (btw. the patch is almost from beginning with NewPascal and it works perfect without any regressions for tests. Also calc_distance works with all tested platforms and for all cross compilers, so I have hope that #31081 is unrelated). -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Improved RTTI compromise
2016-12-07 9:45 GMT+01:00 Arnaud Bouchez <webcontac...@synopse.info>: > Don't forget that there is some working code of interface "Invoke" and > "fake" in mORMot.pas: > - working with FPC_HAS_EXTENDEDINTERFACERTTI or manual-registered RTTI, > - x86 and x64 support on Windows and Linux ABI > - ARM 32-bit and 64-bit (preliminary) support > - well tested under Windows, good coverage under Linux, preliminary > testing under *BSD. > > "Invoke" is indeed only half the way. > Creating "fake" interfaces are also needed for any modern > > It is not using TValue, but currently JSON serialization, working with > by-representation transfer (e.g. objects are transmitted by field values, > not class instance). > It was design to be extended to support a TValue-like input and output. > > It currently lacks some less common targets (CPU & ABI). > But could be used as a starting point. > Good idea with "mORMotish starting point" (especially that licence is compatible with FPC RTL and we have proven code behind), we can wait for Sven (RTTI.pas module on official trunk). Next we can start on NewPascal new branch "fpc-rtti-invoke". Created directly from FPC trunk mirror ( https://github.com/newpascal/freepascal/tree/freepascal ). It could be merged to NewPascal release directly for tests purposes and for more users and for early access. Finally it could be merged as series of patches to official trunk. -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Improved RTTI compromise
2016-12-07 8:49 GMT+01:00 Michael Van Canneyt <mich...@freepascal.org>: > > I am not sure this is possible. The structures exposed in the typinfo > interfacee mimic the info the compiler generates in the binary. > > If the compiler generates different info than Delphi, you cannot retrieve > it in a delphi-compatible way. > > Trying to generate the exact same information as Delphi is IMHO not the > right path. > > What is needed is an API that gives you the info contained in the internal > structures. I think it is possible but solution proposed by Sven is good enough :). As was mentioned in my previous message to Sven: 100% agree I don't have problem with a little Delphi incompatible RTTI, the bigger picture is more important than small details, but quote from Jonas Maebe ([fpc-devel] Attributes thread): "some people wanted it to be Delphi compatible, other people did not mind if it was not. Both categories of people were in the core team." Delphi incompatible info was mentioned as serious problem for merging RTTI branch into trunk. > No-one is ignoring RTII. I have contacted Joost on multiple occasions to > merge his work into trunk. I get a lot of questions about it. But I cannot > do the work myself. If I could, I would. I am waiting for the attributes > since a long time. Glad to hear that. RTTI together with closures is "must to have" feature. Extended RTTI + closures is the last missing element for many users to escape from Delphi. -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Improved RTTI compromise
2016-12-06 23:39 GMT+01:00 Sven Barth <pascaldra...@googlemail.com>: > Most Delphi code probably uses the RTTI unit anyway for this. And when > playing with the RTTI one needs to keep track of FPC vs. Delphi anyway > cause we'll never be 100% compatible (e.g. the Interface RTTI branch > does not keep in mind parameters that might be split across multiple > locations (like two registers), so that needs to be extended compared to > Delphi). > 100% agree I don't have problem with a little Delphi incompatible RTTI, the bigger picture is more important than small details, but quote from Jonas Maebe ([fpc-devel] Attributes thread): "some people wanted it to be Delphi compatible, other people did not mind if it was not. Both categories of people were in the core team." > However I think that we'll add the Delphi compatible TAttrEntry, but > with an additonal AttrCreate field before the AttrCtor field. The former > will then contain a pointer to the generated "fast invoke" function > while AttrCtor, ArgLen and ArgData will be Delphi compatible. > mostly redundant info, but probably best what we can get. > Okay then, maybe I'll manage that this week (no promise though ;) ). > I personally think that removing TRttiContext for now is the better > choice, so people will know not to use it while they might expect valid > values in the other case... > I am waiting :P. Sure, feel free to remove TRttiContext. IMO almost empty TRttiContext has not many sense yet. > I don't know whether an early implementation of Invoke() would be a good > idea already as it would need a heavy rewrite once parameter location > support is available in the RTTI... what you mean by "heavy rewrite once parameter location"? Invoke is extremely usefully even without detailed RTTI info about parameters, for example for scripting purposes. I don't mean only pascal functions, script is able to call external system API. Very handy. -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Improved RTTI compromise
2016-12-06 17:46 GMT+01:00 Michael Van Canneyt <mich...@freepascal.org>: > The Delphi TypInfo unit also exposes the attributes. My message was unclear - I mean that we can hide incompatible part of TypInfo. Type TAttributeData is located in TypInfo (sooner or later that part of TypInfo will be corrected - but IIRC for that "Invoke" function is needed). RTTI.pas is rather fine (need to check). or second option: compiler hinting directive "experimental" for TypInfo.TAttributeData. Good temporary deal for all (I think)... anyway any option is much better perspective than ignoring RTTI.pas for long long long time... -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Management operators and new VMT entry
Hi, I know that MO is not merged (and might be never merged) but I have an idea. In current implementation additional loop was added to TObject.InitInstance (for vInitTable). It could be speed up by new vManagedTable (for TObject.InitInstance). vManagedTable should have the same structure like vInitTable but should contains info only about records with management operators (+ classic objects with records with management operators). In practice it means significant improvement of performance for allocation of new objects. What you think about idea of vManagedTable? -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Improved RTTI compromise
Hi, I was thinking about extended RTTI, and important RTTI.pas module (good start point with attributes is waiting 3 years). Seems that the only real reason why we don't have yet RTTI.pas in trunk is incompatibility of generated type info (as Jonas said: TAttributeData vs TAttrData, no TAttrEntry). Current situation seems like big lock for many developers and development. I see 3 solutions: 1. TAttributeData with additional compiler hinting directive "experimental" 2. Moving TAttributeData into implementation section (and related functions accessible through alias *.inc for RTTI.pas). Only usage of attributes through RTTI.pas would be allowed. 3. Not merged. Point 1&2 is fair enough (especially 1). We can change RTTI layout in the future (when Invoke will be implemented). I think that speed of development of RTTI.pas will increase (btw. management operators are perfect for TValue). For point 3 I am forced to add RTTI branch into NewPascal project which is dangerous for both projects and for me personally. Today I need to read ridiculous messages (for example from Blaise in "Closures / anonymous methods" topic) about "no respect" for my person ^^ because I have Open Source supporting project (as Blaise said: I am schismatic which create unnecessary forks, splitting the community and resources). For me NP is start point for many patches merged back into FPC, libraries and motivation for improvements and for discussions with core team about improvements. *Sooner or later someone will send agent 47 to eliminate me ;) so please rethink decision about RTTI branch*. Maybe RTTI branch has some hidden flaw? -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Closures / anonymous methods
2016-12-05 17:46 GMT+01:00 <bla...@blaise.ru>: > > Because much communication occurred off-list. :) in that case all is ok. Good luck. I have hope to see new release soon. I will try to create few tests. > if you do not have enough patience for FPC core team >> > > What I do not have is respect for schismatics who create unnecessary > forks, splitting the community and resources. Indeed! That would be terrible. I think that is good that we don't have any Lord Vader nor Emperor :) -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Closures / anonymous methods
2016-12-05 15:12 GMT+01:00 <bla...@blaise.ru>: > On 05.12.2016 16:44, Sven Barth wrote: > > You mean that from around a year ago? >> > > No. Your latest letter to me is dated 26.11.2016. I see big problem with communication. Seems like I am special mediator. Without my notification the topic was almost dead for 1 year. Now we have similar situation again probably for another year or two. I need that feature to start many other related features in my compiler work. For example I like to start experiments with "yield" and other stuff (compiler code behind closures is usefully). >From my experience with management operators: * The patch can't be simple as one big patch, the working feature is just a start (in current form, closures are not in that stage yet - see problems with already implemented "blocks" by Jonas). State of closures IMO is far far away from "ready to merge". * When big patch is ready you need to rework whole patch for small commits * Each owner/author of feature, should be able to create full-test suite, generally only author knew how it works in all details, and how to create proper test suite to cover low level scenarios, so community could not help much with test suite (sure - bug reports and related tests are fine but I mean test suite prepared by core team for each new feature). * The style of compiler code *must* be exactly same in all parts (after many hours with compiler I think it is perfect). Did I miss something important? I might be wrong. Let me know if you do not have enough patience for FPC core team ;). I will do it :P... -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Closures / anonymous methods
2016-11-25 19:10 GMT+01:00 Sven Barth <pascaldra...@googlemail.com>: > Just to be sure: we're talking about the week from 28th to 2nd. If so, yes > I'll try to make sure that I'm available. Maybe I'll even hang around on > IRC :) Any new info? Link to repository? Should I continue? -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Wiki Article about FPC's testsuite
2016-11-29 10:51 GMT+01:00 Jonas Maebe <jonas.ma...@elis.ugent.be>: > > Do you need more information besides what is already explained in > > tests/readme.txt? > > I've added a reference/link to the readme for an explanation of the > other options. Link to "readme" in wiki article is fair enough. Thanks. -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Closures / anonymous methods
2016-11-24 19:38 GMT+01:00 Sven Barth <pascaldra...@googlemail.com>: > mea culpa So what next? Blaise is still interested in? Am I alone on battle field? Is Scooter Software around? I am confused. -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Attributes
2016-11-22 21:03 GMT+01:00 Jonas Maebe <jonas.ma...@elis.ugent.be>: > a) it breaks the syntax for procedure attributes that has existed since > the beginning in FPC in case such an attribute comes right after a > procedure declaration (like procedure test; [public, alias: 'abc'];). At > the very least the attributes need an extra modeswitch to activate them in > order not to potentially break existing code by default. > modeswitch prefixedattributes is implemented (and seems it works) and can be used by default in Delphi mode only, so I think this is not the problem. > b) the generated type info is Delphi-incompatible (TAttributeData vs > TAttrData, no TAttrEntry). Some people wanted it to be Delphi-compatible, > other people considered this is an implementation detail and that we do not > have to follow Delphi here. > Don't get my next words as attack but... I don't understand double standards. TypInfo is already incompatible, first example: http://lists.freepascal.org/pipermail/fpc-devel/2016-March/036742.html http://bugs.freepascal.org/view.php?id=29767 I still have objections about ManagedFldCount which is in many cases buggy/problematic for existing Delphi code base and has improper naming (btw. info about all record fields in that form is useless). On the other hand I need to read "We can't accept that because is Delphi-incompatible". TypInfo module is less important than RTTI module. In most of cases for newer code TypInfo is rarely used. At the end we can mark TAttributeData as experimental feature. Generics.Collections is also incompatible on details but i prefer to have somehow incompatible important feature than don't have that feature. -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Attributes
2016-11-22 14:27 GMT+01:00 Sven Barth <pascaldra...@googlemail.com>: > There is still Joost's branch that's waiting to be merged, but even then > this would only contain class attributes. I have checked Joost implementation and generally seems ok (logically most important part for me about "when" and "how" is called constructor for attributes is alright). Branch is waiting almost 3 years (sic!). Joost branch should be part of NewPascal much much sooner than official FPC trunk, anyway I have question: Eventually rework for this branch has any sense? I am asking because I need to prepare some work on this branch for NewPascal purposes. I prefer "less" work but if I can somehow help to "speed-up" FPC-trunk integration then I prefer to rework this branch in similar way like for management operators. -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ANN: Management operators - final patch
2016-11-21 2:16 GMT+01:00 Maciej Izak <hnb.c...@gmail.com>: > I have new dedicated branch located here: > > https://github.com/maciej-izak/freepascal/tree/fpc-management-operators > note: management operators are also available in version for NewPascal : https://github.com/maciej-izak/freepascal/tree/management-operators <https://github.com/maciej-izak/freepascal/tree/fpc-management-operators> If someone is interested in tests, "ready to use" compiler with management operators and latest Lazarus is available at: http://newpascal.org -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ANN: Management operators - final patch
2016-11-21 2:54 GMT+01:00 Paul Ishenin <paul.ishe...@gmail.com>: > Use fpc_Copy for Clone and fpc_Addref for Copy is misleading. First of all I don't like to have Florian in opposition to this feature ;) it is a teamwork. Anyway I agree that this is misleading... But as was suggested by Florian (as far as I understand): On the language level Clone and Copy is totally new feature. Users don't have direct access to FPC_COPY nor FPC_ADDREF. FPC_COPY and FPC_ADDREF naming is outdated and probably renaming to FPC_CLONE and FPC_COPY is good idea, but old convention is still in usage for backward compatibility with old code (for "alias"/"public name" feature). I can't do much in this matter. -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Raw ARC objects preview
2016-11-09 22:36 GMT+01:00 silvioprog <silviop...@gmail.com>: > Dude, all your effort is enjoyed here, the C++/C# community is already > crowded, so you'd be just another one there hehe :-D Thanks. After few sessions with GTA IV and many kills I have good news: https://plus.google.com/u/0/115782878581272923715/posts/ZdCcSzikRVS -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] NewPascal cooperation
NewPascal future should be bright. My decision was too hasty. Few persons of whole community (especially in Delphi) is not whole community. When you do what you can best, totally for free then the critic (or ban) hurts more than critic for commercial projects. Maybe is time to cut off G+ Delphi community cuz I have enough work with FPC core team ;) (discussion with core team is very constructive while discussions what can I post and why not on G+ Delphi community is pointless). I can't leave and drop support for many projects: fpcdelux by Don Alfredo (rather fpcdelux has support for NP), mORMot by A. Bouchez, "Pascal UE" engine by Benjamin Rosseaux, Castle Game Engine by Michalis Kamburelis and my current job. This has gone too far... What you would expect from NewPascal project? What is most important target for you? How we can cooperate in better way with FPC core team? I will try to run G+ NewPascal community soon. It might be good to have more persons in NewPascal and own G+ community site. I don't mean "schism" in FPC community. NewPascal should be early access system, easy start for cross-platforms development, modern looking project hosted on GitHub to attract more developers, management of SDK (for example for Android) better CI system both for NewPascal and regular FPC trunk, patches for mORMot and Delphi compatibility, and place where I can put new language features (discussed ofc with FPC core team -,- meh). I will try to have more patience for patches and FPC core team (is that possible? ;P). -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Raw ARC objects preview
2016-11-08 17:56 GMT+01:00 silvioprog <silviop...@gmail.com>: > NewPascal is now on my wishlist. :-) > Thanks. But sadly that was my last job for Pascal community. One person from FPC core team suggested me to switch to C++/C# instead of discussing with them. Time to start new adventure! I am banned Delphi user (thanks to Lars Fosdal) and problematic community member for FPC core team. More info about my reasoning: https://plus.google.com/u/0/115782878581272923715/posts/gmeysvbJiZS Btw. You can test early (but working very well without regressions) implementation of nullable types and smart pointers (examples and sources attached): https://github.com/maciej-izak/PascalSmartPointers Compilable and runable with latest and last NewPascal release. -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Raw ARC objects preview
I became outlaw (permanent ban) on Delphi G+ for this :D . Seems my work is serious danger for Delphi (single programmer can kill their business? I have no idea). ARC objects preview for newpascal.org (will be probably used for Delphi NEXTGEN mode in NewPascal). Fully compilable and backward compatible. Some work is still required (additional Delphi compatible interface, compiler magic and and few changes in RTL): https://github.com/maciej-izak/PascalSmartPointers/blob/master/examples/SmartObj01.pas https://github.com/maciej-izak/PascalSmartPointers/blob/master/sources/SmartObj.pas -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Closures / anonymous methods
2016-10-29 13:29 GMT+02:00 Florian Klämpfl <flor...@freepascal.org>: > While I agree that we are merging invasive changes slowly, this is a > little bit unfair as > Generics.Collections required a lot of bugs to be fixed before it could be > merged: > http://bugs.freepascal.org/view.php?id=27206 > Last serious bug was fixed around rev. 29537 (January 2015). Ok just ~1,5 year. My bad ;). Sven had a lot of doubts about manual interfaces :P... Anyway I am very happy that we finally have rtl-generics! -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Closures / anonymous methods
2016-10-26 0:03 GMT+02:00 <bla...@blaise.ru>: > Now you have me confused. > I thought you wanted to "take over" acceptance of this into FPC and doing > further improvements. > What is this NewPascal? How official is it? Are the changes ported to FPC? > (Googling through the lists.freepascal.org did not help.) > NewPascal is official compiler for mORMot. NewPascal means tuned compiler more Delphi compatible with additional support for mORMot framework, cross compiling and early access for new features. More info about changes and differences with comparison to official FPC: http://newpascal.org/compass.html . All is reported on FPC bugtracker. I can't do much in that matter. ... I also want acceptance of all important patches into FPC (that is why I will work on your patch). We really need NewPascal fork, to get important patches/modifications in reasonable time, for example merge for finished Generics.Collections took 2 years... Many users likes more modern Pascal (for example oxygene mode is also one of NewPascal targets), FPC core team likes more old fashioned Pascal... I do not believe that core team would accept oxygene mode/patch. Anyway... *NewPascal is and will be as close FPC trunk/bugtracker as possible*. -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Closures / anonymous methods
2016-10-25 20:38 GMT+02:00 <bla...@blaise.ru>: > > 3) I have not abandoned this project (and I am as frustrated with the pace > as you may be; although, the previous disruption was not my fault -- I had > allocated last December to finally have this merged, but got no response > from maintainers within a month). > ... I understand ... :\ > TL;DR: while there may be nothing preventing you from just grabbing the > feature-ready files and "taking over" from the legal standpoint (and I do > not care to check), there are other implications to consider. > > The other reason I mentioned Scooter Software is that they may be > interested in funding your further work. (The list does not reflect this, > but I CC'ed my original message to them to keep them in the loop.) > that is very interesting for me. Thanks? btw. your work (with my modifications and with regression tests) will become part of NewPascal release (for sure!) and I hope it makes you less frustrated :) -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Closures / anonymous methods
2016-10-25 16:09 GMT+02:00 <bla...@blaise.ru>: > In theory, that is fine by me (the author). > Good to hear that > However, if I were to formally pass the bucket to you, I would like to > settle with Scooter Software on my work done thus far. > What Scooter Software has to GPL licensed code? -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Closures / anonymous methods
2016-10-25 15:45 GMT+02:00 Michael Van Canneyt <mich...@freepascal.org>: > One remark only: you should keep it independent of (or orthogonal to) the > work you did on management operators. One should not depend on the other... Yes I know and I agree :P One branch for Generics.Collections, one for Management Operators, one for Smart Pointers, one for patches and new one for Closures. I hope that Github has enough space for all branches... -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Closures / anonymous methods
Hi, I'd like to take over work on closures/anonymous methods: http://newpascal.org/compass.html (point #5). Patch/hg repository from original author has gone away but I have made copy. My working repository is here: https://github.com/maciej-izak/freepascal/commits/closures I sent here original patch. I will rework this functionality according to all suggestions from Jonas and Sven (reference to all informations avaible in NewPascal "compass" listed above). any objections? -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Black List of examples that FPC won't compile, 2, 5 years later...
2016-09-19 12:30 GMT+02:00 Maciej Izak <hnb.c...@gmail.com>: > Patch is attached here and in #25607. I forgot to remove "objdef: tobjectdef;" local variable from calc_distance function in the patch. -,- -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Black List of examples that FPC won't compile, 2, 5 years later...
Hi,
reminder:
Essence: http://bugs.freepascal.org/file_download.php?file_id=19514=bug
Examples: http://bugs.freepascal.org/file_download.
php?file_id=19513=bug
Bugtracker: http://bugs.freepascal.org/view.php?id=25607
Prev. discussion:
http://lists.freepascal.org/fpc-devel/2014-January/033232.html
During my work on Generics.Collections, SmartPointers and NewPascal.org
initiative, I have decided to split my work on many parts to be as close as
possibly to original FPC trunk by sending patches and improvements (all is
listed here http://newpascal.org/compass.html ).
One of most important parts is fix for bug #25607. FPC has problem with
calculating "distance" for methods with default parameter. Patch is
attached here and in #25607.
We have small difference with Delphi implementation for example:
===code begin===
type
TA = class
constructor Create(A: Integer = 0); overload; virtual;
end;
TB = class(TA)
constructor Create(A: Integer); overload; override;
end;
TClassB = class of TB;
constructor TA.Create(A: Integer = 0);
begin
WriteLn('TA.Create');
end;
constructor TB.Create(A: Integer);
begin
WriteLn('TB.Create');
end;
var
B: TB;
ClassB: TClassB;
begin
B := TB.Create;
B.Create;
ClassB := TB;
ClassB.Create;
==code end===
Output for Delphi:
TA.Create
TB.Create
TB.Create
Output for FPC with my patch:
TB.Create
TB.Create
TB.Create
Seems like Delphi implementation is buggy (override should work for
"Create" in presented context too).
--
Best regards,
Maciej Izak
compiler_patch_distance_for_black_list_19.09.2016.patch
Description: Binary data
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Default" discussion for SmartPointers etc
2016-07-26 21:59 GMT+02:00 Sven Barth <pascaldra...@googlemail.com>: > First of let me tell you that in essence and in general I'm in support > of your "default" idea > Not only you Sven ;) I found interesting comment by Allen Bauer, seems like "default" idea is right direction. Completely independent source. I didn't know before about this comment. Comment created in May 2015 strictly related to nullable types. My work starts in 2014 and "default" in my case was created for smart pointers and ARC objects :) Additional note: IMO 'default' for fields is more powerful and together with default for non-indexed properties is awesome combo. === begin quotation === Current working theory of Nullable. Nullable = record ... property Value: T read FValue; default; ... end; Using the default directive to "hoist" the operators of "T". Currently the default directive only works for array properties by "hoisting" the '[]' operator. Marking a non-array property with default will make the containing type behave as that type. This, coupled with some intrinsic compiler knowledge of the Nullable type will make Nullable work without any addition of keywords or other standard functions or procedures. Using the "default" directive on a non-array property will work for any type, except for having the null-propagation semantics. When considering language features, I try and not only make it work for the intended purpose, but also broaden reach of any supporting feature. In the above scenario, even user-defined operators on "T" will be properly hoisted and used. === end quotation === source (one of last comments) : https://plus.google.com/u/0/+HoracioJoseCavalcantiFilho/posts/2vzP8sdF4f7 -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generics collections
2016-07-30 18:40 GMT+02:00 Sven Barth <pascaldra...@googlemail.com>: > please check the changes I've made (they're mentioned both in the commit > as well as the issue). > > merged into github repo > Maybe you should add an "experimental" modifier to these types so that one > knows that they're unstable. > I've made that long time ago (for most of unstable interfaces). -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generics collections
Impossible! :O *Finally*! Thanks Sven! Totally unexpected event. ;) I'd like to use Generics.Collections in stable release ASAP but... IMO best version for release is 3.2 (even 3.0.4 is probably to early). I need to review latest changes in trunk for generics to correct library (package?) code, because few elements in library are temporary (to workaround bugs) see https://github.com/dathox/generics.collections/blob/master/GenericsCompatibilityMatrix.pdf especially we need to fix: #26030 and #28911 #28911 will be fixed (probably) after packages release. I have questions how to contribute in future: - shall I create ticket on bugtracker for set of my commits on github (or for each commit separately?)? - Is right to break interface for experimental structures (generally most of experimental structures were introduced only for bug workarounds) - maybe is good idea to add me write-rights for svn only for rtl-generics subdirectory for easily maintenance? 2016-07-29 20:01 GMT+02:00 Dimitrios Chr. Ioannidis <d.ioanni...@nephelae.eu >: > Hi, > > is there a chance to merge the generics collections 34229 commit from > trunk to 3.0 fixes ( a.k.a. 3.0.2 soon to be ) also ? > > regards, > > -- > Dimitrios Chr. Ioannidis > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel > -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Default" discussion for SmartPointers etc
2016-07-28 17:03 GMT+02:00 Stefan Glienke <sglie...@dsharp.org>: > I agree with Michael here. While in Spring4D our nullables have the > implicit > operator in both directions in retrospective I think it's not a good idea > and > the nullable -> x conversion should be explicit (with the possibility to > raise an explicit exception - not an AV) and for sure not be faked by the > deref > operator because a nullable is not a reference type in my book even if it > can be > null (err nil?) That btw leads to another question - is the "null" state > equal > to nil - or is it something different. So a nullable is kind of both > things, it > can be nil/null but if not it contains the value but does not point to it > thus > cannot/should not be deferenced. C# for example requires a hard cast or > the call > to .Value to get the underlying value from a nullable with the possibility > to > throw a InvalidOperationException if it has no value. > Remember that we working not in .NET environment, Pascal has assembler, pointers and other cool stuff, and I think that we need different approach adjusted to highly optimized needs. Explicit conversion still exist. Default field is blazing fast solution and it covers many needs (not nilable types only). I don't want 1:1 copy from C# -,- > > FWIW if you make it a new language construct I actually would prefer > "nullable > of " which is consistent with "array of " or "set of ". > aside from the syntax I see nilable types as new type kind called: proxy. Same family as smart pointers and ARC objects, that means new unified TTypeData entry: tkProxy: (ProxyType: TProxyType; ProxyOwnerType: TypeInfoPtr; // maybe ProxyContainerType is better name? It points to type information of record DefaultFieldOffset: PtrUInt; DefaultFieldType: TypeInfoPtr); where TProxyType = ( ptCustom, // proxy object defined by user, declared as var x: TMySmartPtr; ptNilable, // declared as var x: nilable/nullable Integer ptStrong, // declared as var x: strong TObject; ptWeak, // declared as var x: weak TObject; ptUnretained); // declared as var x: unretained TObject; -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Default" discussion for SmartPointers etc
2016-07-28 17:58 GMT+02:00 Michael Van Canneyt <mich...@freepascal.org>: > Then you will not have this problem; GetValue will always return a > 'Default' value. IMO bad design. You can't use value of not assigned nilable types as same as you can't use not assigned pointers >.<. There is no magic in ^ . Just look at declaration: Instance: ^T default; you can create alternative nilable struct with: FInstance: T default; FHasValue: Boolean; with that you don't need any ^ operator -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Default" discussion for SmartPointers etc
2016-07-28 17:49 GMT+02:00 Maciej Izak <hnb.c...@gmail.com>:
> === code begin ===
>
> var
> n: TNilable;
> begin
> {
>
>... let say that n is assigned somewhere, assume that n.HasValue = true
>
> }
> x.foo1 := 10;
> x.foo2 := 'abc';
> end.
>
> === code end ===
>
small typo. n instead of x ;)
--
Best regards,
Maciej Izak
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Default" discussion for SmartPointers etc
2016-07-28 16:37 GMT+02:00 Michael Van Canneyt <mich...@freepascal.org>:
>
> Are there additional benefits I have missed ?
>
>
Using nilable (I think nilable is better than nullable) records is terrible
without default field:
=== code begin ===
var
n: TNilable;
x: TRec;
begin
{
... let say that n is assigned somewhere, assume that n.HasValue = true
}
// to change any field in nilable n you need to...
x := n.Value;
x.foo1 := 10;
x.foo2 := 'abc';
n := x;
end.
=== code end ===
instead of:
=== code begin ===
var
n: TNilable;
begin
{
... let say that n is assigned somewhere, assume that n.HasValue = true
}
x.foo1 := 10;
x.foo2 := 'abc';
end.
=== code end ===
> I can live with the 'ascetic' version :-)
>
> Since the following:
>
> Procedure SomeTest(Var X : Integer);
>
> begin
> X:=1; end;
>
> Var
> A : TNullable;
>
> begin
> SomeTest(A^);
> end.
>
> Will lead to a crash on a null value, I don't think this is a very good
> idea to add.
> We should protect users from crashes, not expose them to it :-)
>
that will change nothing, just look below. Just harder to usage pure
non-pascalish clone of C# struct (finally C# has pointers as
nonstandard/unsafe type so feature with direct dereference is disabled by
design).
=== code begin ===
procedure SomeTest(x : Integer);
begin
end;
Var
A : TNullable;
begin
SomeTest(A.Value); // AV error here!
end.
=== code end
A^ is shortcut for A.Value but has advantage = direct dereference to
Instance.
--
Best regards,
Maciej Izak
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Default" discussion for SmartPointers etc
2016-07-28 14:59 GMT+02:00 Michael Van Canneyt <mich...@freepascal.org>: > Because with the exception of the ^ operator, I see no need for any special > constructions to achieve a "nullable type", except maybe some implicit > constructor/destructor ? > procedure with var parameter is special case, we need somehow to perform backward compatibility and strong typing is the must. In the fact TNullable is proxy type to field of ^Integer type. ^ operator exist to make life easier in comparison to C# implementation. "default field" is not necessary for nullable types but is extremely useful addition, more options and optimization for end user. We can exclude completely possibility of usage ^ operator for nullable types (^ for nullable type is just my invention). In that case calling functions like test1 will be impossible. Just pure copy of Nullable types from C# -,- . So you are right - ascetic version of nullable type need only management operators (aka implicit constructor/destructor). Presented nullable type is not "pure" copy of C# implementation, presented above implementation has Pascal spirit and optimizations impossible to achieve in other languages. btw. you can add class operator Equal(A: TNullable; B: T): Boolean; to run this: if b = 0 then b:=1 else b:=23; -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Default" discussion for SmartPointers etc
2016-07-28 13:02 GMT+02:00 Stefan Glienke <sglie...@dsharp.org>: > One thing that I did not see mentioned here is the fact that introducing > "operator hoisting" by introducing that default feature will not solve > nullables > at all. > In most of cases we can solve that by class operators but I think that for few cases compiler magic is needed. We can use additional compiler support ony for that form of nullable types: var x: nullable Integer; // which is de facto TNullable on steroids ;) -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
