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, bu
ittle 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
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
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
://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
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
e 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
2018-06-28 22:13 GMT+02:00 Sven Barth via fpc-devel <
fpc-devel@lists.freepascal.org>:
> Am 28.06.2018 um 08:52 schrieb Maciej Izak:
>
>> * some new proper credits in few places
>>
> Two questions regarding this:
> - who is DaThoX and in how far are they related to
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: TRecordInfoIn
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 mailli
2018-06-21 22:50 GMT+02:00 Maciej Izak :
> Coexistence of both has no sense - information stored in Flags will be
> useless, this info is for sure not complement :( .
>
I see 4 options:
1. integration of FastRTTI
2. limited integration, only part of "FastRTTI" bran
.IMPLEMENTATIONS$_$TPXI_PROXY_TGLOBALVARIABLESAGGREGATE_$__$$_GETOPERATOR_LOGIN$$PUTF8CHA
--
Best regards,
Maciej Izak
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 operato
nitFlags? (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-deve
oInitFlags 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
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. Ma
sed 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
very 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.collectio
cause 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
is 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
ked 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
__
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 regard
es 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 Iz
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 -
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
;
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(
2018-01-22 18:48 GMT+01:00 Mattias Gaertner :
> On Mon, 22 Jan 2018 18:45:57 +0100
> Maciej Izak 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 s
perty.
>
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
___
2018-01-22 18:00 GMT+01:00 Denis Kozlov :
> 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.o
ay 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 ;)
. :) 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.free
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
).
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
PL/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
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
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
__
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
he 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
___
2017-01-31 14:56 GMT+01:00 Sven Barth :
> 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
ctable 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
cords (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
s 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&
ons 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
pened 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@
2016-12-15 17:13 GMT+01:00 Sven Barth :
> 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-dev
other 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-
t; 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-de
ion 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
RT 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
nd 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
2016-12-12 23:14 GMT+01:00 Maciej Izak :
> 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
PC_(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
2016-12-12 15:53 GMT+01:00 Maciej Izak :
> 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 in
2016-12-12 13:32 GMT+01:00 Maciej Izak :
> 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 ManagedFldCo
pics :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
ect
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
e 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
2016-12-11 13:18 GMT+01:00 Maciej Izak :
> 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
)
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
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.
M
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
s:
array[1..ManagedFldCount] of TManagedField:
ThisIsRealAndNotFakeManagedFields:
array[1..ThisIsRealAndNotFakeManagedFldCount] of TRealAndNotFakeManagedField
Or some flag in TTypeData for records:
YesIamManagedRecordAndIHaveRealManagedFieldsAndYesPleaseIgnoreManagedFldCountWhichIsL
er 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
2016-12-09 21:53 GMT+01:00 Sven Barth :
> 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,
Ma
//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
_
es 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?
2016-12-08 12:15 GMT+01:00 Jonas Maebe :
> Does this version of the patch fix the issue
Ouch I read "cause" instead of "fix". Only Alf knows that. :)
--
Best regards,
Maciej Izak
___
fpc-devel maillist - fpc-devel@li
c_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,
etails:
E01 source:
https://gist.github.com/maciej-izak/f312ff683406e2b16003ee67ee1a95d1#file-e01-pas
{E01 Delphi | FPC with calc_distance }
TA.Create | TB.Create
TB.Create | TB.Create
TB.Create | TB.Create
E02 source:
https://gist.github.com/maciej-izak/f312ff683406e2b16003ee67ee1a95d1#file-
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
o
t 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 ele
eter 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
__
now also support generic functions we can also add the missing
> functions of TValue ;) (patches welcome once we've indeed merged it)
>
Sure, very welcome. TValue is good for beginning (would be cool to use
TValue with MO). RTTI.pas might
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
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
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 maill
spect 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
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
2016-11-25 19:10 GMT+01:00 Sven Barth :
> 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?
le 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 definitely welcome :)
>
Nice to see improvements in this area. IMO would be nice to have additional
info about %fail, %cpu, %opt ... Did I miss something important?
--
Best regards,
Maciej Izak
___
fpc-devel maillist - fpc-devel@lists.freepascal.
2016-11-24 19:38 GMT+01:00 Sven Barth :
> 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-de
ode 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
_
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
2016-11-21 2:16 GMT+01:00 Maciej Izak :
> 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/tre
tibility 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
Hi,
Patch for management operators is totally reworked. All suggestions from
Florian, Jonas and Sven have been implemented. This is the third attempt.
My base is trunk r34916. Each commit works well with "make clean all". I
have new dedicated branch located here:
https://github.com/m
81272923715/posts/ZdCcSzikRVS
--
Best regards,
Maciej Izak
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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
inters (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.or
2016-11-08 17:02 GMT+01:00 silvioprog :
> I need to test this new features soon... Can I use nextPascal on Linux?
> (I'm using latest Xubuntu version)
sure! try this:
https://github.com/LongDirtyAnimAlf/Reiniero-fpcup/releases/tag/0.99
Great tool made by Alf :)
--
Best regards,
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
st 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 mail
y 40th birthday FPC
team decide to merging Management Operatos into trunk -,- . If Oxygene
patch is next, which relay on MO... 80th birthday?
--
Best regards,
Maciej Izak
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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
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
-
Best regards,
Maciej Izak
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
rators, 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/m
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
2016-09-19 12:30 GMT+02:00 Maciej Izak :
> 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
1 - 100 of 301 matches
Mail list logo
