Re: [fpc-devel] Object upgrades (new)
schrieb am Di., 18. Juni 2019, 03:27: > >> *this is an example of a traditional record and a traditional object as > i > >> think of them... > > [snip] > > > > These would still work as is in FPC. > > > right but are they objects, classes or advanced records? > Your example showed a couple of records and an object. The later is often also called TP-style object for better distinction to Delphi-style objects also known as "classes" (due to their use of the "class" keyword instead of the "object" keyword). Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pending approval...
Le 18/06/2019 à 04:21, J. Gareth Moreton a écrit : > Hi everyone, > > So I sent my last update/fix/patch for the XML core dump feature 3 weeks > ago, but my main liaison, Pierre, seems to have vanished for the time > being. Hopefully he's okay, but it means the feature is currently in > limbo and I could greatly benefit from its use in developing future > ideas, and I'm sure other developers will find use in it too. > https://bugs.freepascal.org/view.php?id=35017 Hi all, as you might remember, there are only afew volonteers behind this project, which all have also 'a real life' which makes them not available at all times for 'Free Pascal' project. Besides, there are numerous other problems that I am also trying to tackle and resolve. Otherwise, thank you very much for your concern, but I am OK, just not as available as I would like... Coming back to the XML dump feature that you developed, I do think that it is now in a better state, and it will probably be integrated into main trunk after I find time to re-run the different checks that I used for the mutual feedback. I cannot give you any fixed date for this, as it will depend greatly on the time I can find for Free Pascal, and on those other tasks. > On another note, I've made some fixes to compiler issues when it comes > to x86 assembly language, specifically the SSE and AVX instructions that > deal with single rather than packed data, because a number of > instructions would throw false warnings or errors due to incorrect > operand sizes, even though they are actually correct. Details can be > found here: https://bugs.freepascal.org/view.php?id=35700 (this one has > a couple of linked issues too). My knowledge about those i386/x86_64 extensions is too vague, so you will need to find another core developer to handle this bug report. Keep on the good work, and try to be patient with other members that have less time to dedicate to Free Pascal! Pierre ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Pending approval...
Hi everyone, So I sent my last update/fix/patch for the XML core dump feature 3 weeks ago, but my main liaison, Pierre, seems to have vanished for the time being. Hopefully he's okay, but it means the feature is currently in limbo and I could greatly benefit from its use in developing future ideas, and I'm sure other developers will find use in it too. https://bugs.freepascal.org/view.php?id=35017 On another note, I've made some fixes to compiler issues when it comes to x86 assembly language, specifically the SSE and AVX instructions that deal with single rather than packed data, because a number of instructions would throw false warnings or errors due to incorrect operand sizes, even though they are actually correct. Details can be found here: https://bugs.freepascal.org/view.php?id=35700 (this one has a couple of linked issues too). Would any of the administrators or moderators be able to have a look and confirm if these are okay/correct or not? Gareth aka. Kit --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades (new)
On 6/17/19 4:56 PM, Sven Barth via fpc-devel wrote: Am 17.06.2019 um 19:56 schrieb wkitt...@windstream.net: And yes, both are again different from classes. yeah, i'll have to see if i can figure out what classes are and if they are one of the old-school objects or records... yeah, i'm getting old and rarely dabble in pascal code any more but i still read the mailing lists :) I suggest you to take a look at this: https://wiki.freepascal.org/Object_Oriented_Programming_with_Free_Pascal_and_Lazarus#Free_Pascal_Language_Extensions thanks... i'll try to get by there soon-ish... *this is an example of a traditional record and a traditional object as i think of them... [snip] These would still work as is in FPC. right but are they objects, classes or advanced records? -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Copy/move operator
> On Jun 17, 2019, at 1:00 PM, Sven Barth via fpc-devel > wrote: > > If we do this at all we should use a separate operator as those two are > rather different operations and the compiler would already have figured out > which of the two operations is needed and thus the code inside the operator > doesn't need to do that anymore. > > That said this would require extending the RTL assignment helper. > > And the problems that Jonas mentioned are less problems inside the compiler, > but problems inside the user code when they write their Move operator > incorrectly. From great power comes great responsibility after all and I'm > not sure whether we should provide the users with that much power. I see. Looking at this on Sunday I see in assignment nodes fpc_copy_proc would need to be modified or a new fpc_move_proc introduced which (for now at least) would only affect records which had a move operator. In theory the concept could be extended to dynamic arrays and other reference counted types but that’s another story. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Copy/move operator
> On Jun 17, 2019, at 5:16 PM, Ben Grasset wrote: > > I can't actually check the assembly at the moment, but I'm pretty sure if > your example was written like the following, it would not call `Copy` for the > `TList.Create(10)` assignment: > The copy operator is always called on all assignments. Try actually running that and you’ll see. :) Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Copy/move operator
On Sun, Jun 16, 2019 at 9:30 AM Ryan Joseph wrote:
> Here’s a little example of the problem. What I propose is that we either
> add a 3rd boolean parameter to the Copy operator or add a new Move operator
> which is preferred over the Copy operator if it exists (this is much more
> work obviously but maybe has some benefit).
>
I can't actually check the assembly at the moment, but I'm pretty sure if
your example was written like the following, it would not call `Copy` for
the `TList.Create(10)` assignment:
{$mode objfpc}
{$modeswitch advancedrecords}
program test;
type
generic TList = record
data: array of T;
// static class function instead of actual constructor
class function Create(num: integer): TList; static; inline;
class operator Copy(constref src: TList; var dest: TList);
end;
class function TList.Create(num: integer): TList;
begin
SetLength(result.data, num);
end;
class operator TList.Copy(constref src: TList; var dest: TList);
begin
// no reason not to use `move` here, I wouldn't say
move(src.data, dest.data, sizeof(T) * Length(src.data));
end;
var
a, b: specialize TList;
i: integer;
begin
// TList.Create allocates a new array but we don’t really need to copy
// on assignment because the source is a temporary object that doesn’t
// actually exist at any static address.
a := specialize TList.Create(10);
for i := 0 to 9 do a.data[i] := i;
b := a;
for i := 0 to 9 do writeln(b.data[i]);
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades (new)
Am 17.06.2019 um 19:56 schrieb wkitt...@windstream.net: And yes, both are again different from classes. yeah, i'll have to see if i can figure out what classes are and if they are one of the old-school objects or records... yeah, i'm getting old and rarely dabble in pascal code any more but i still read the mailing lists :) I suggest you to take a look at this: https://wiki.freepascal.org/Object_Oriented_Programming_with_Free_Pascal_and_Lazarus#Free_Pascal_Language_Extensions *this is an example of a traditional record and a traditional object as i think of them... [snip] These would still work as is in FPC. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades (new)
On 6/17/19 12:49 PM, Sven Barth via fpc-devel wrote:
schrieb am Mo., 17. Juni 2019, 14:15:
On 6/17/19 1:54 AM, Sven Barth via fpc-devel wrote:
> schrieb am Mo., 17. Juni 2019, 02:07:
>
> what always confused me these days is that records and objects were
one thing
> back in the (TP6) day but today they are something quite different...
i had to
> be very careful when i wrote my satellite TLE management tool because
of these
> differences...
>
>
> Ehm... TP style objects were already quite different to records back in
TP days.
yes... what i'm saying is that today's are different and that's what
confuses me...
You are talking about classes, aren't you?
maybe... that's part of the confusion... i'm self taught from TP2... never took
any classes for anything computer at all... started with B.A.S.I.C. and a friend
showed me asm and pascal... i dropped basic like a hot potato and went all out
with asm and pascal... had a nice library of routines in asm but as each new TP
came out, fewer and fewer of my homegrown asm routines were needed... eventually
i was doing asm blocks in my pascal sources instead of compiling .obj files and
linking them in...
in the day that i speak of, records were simple static blocks that contained
data in a certain defined order... today's records have methods, too, which
are
more like objects back then... i forget the difference between yesterday's
objects and today's...
But back in the days the objects were already different from records.
right... i wrote my own objects when they were introduced and later extensively
used message base objects from Mark May when writing BBS message base tools...
some objects had (traditional) records* within them...
mksm106.zip 215k
MK Source for Msg Access v1.06 - Mark May's
Pascal OOP source code to access Squish,
Jam, Hudson, *.Msg, and Ezycom message
bases. Great for developing BBS utilities.
(FW)
ftp://sestar.synchro.net/main/PROG/mksm106.zip
i started, some time back, to convert the code to FPC but RL and other shite got
in the way...
And yes, both are again different from classes.
yeah, i'll have to see if i can figure out what classes are and if they are one
of the old-school objects or records... yeah, i'm getting old and rarely dabble
in pascal code any more but i still read the mailing lists :)
*this is an example of a traditional record and a traditional object as i think
of them...
Type JamHdrType = Record
Signature: Array[1..4] of Char;
Created: LongInt;
ModCounter: LongInt;
ActiveMsgs: LongInt;
PwdCRC: LongInt;
BaseMsgNum: LongInt;
Extra: Array[1..1000] of Char;
End;
Const JamSubBufSize = 4000;
Type JamSubBuffer = Array[1..JamSubBufSize] of Char;
Type HdrType = Record
JamHdr: JamMsgHdrType;
SubBuf: JamSubBuffer;
End;
Type JamMsgObj = Object (AbsMsgObj)
JM: ^JamMsgType;
MsgHdr: ^HdrType;
JamIdx: ^JamIdxArrayType;
TxtBuf: ^JamTxtBufType;
Error: Longint;
Constructor Init; {Initialize}
Destructor Done; Virtual; {Done}
Procedure SetMsgPath(St: String); Virtual; {Set netmail path}
Function GetHighMsgNum: LongInt; Virtual; {Get highest netmail msg number in
area}
Function LockMsgBase: Boolean; Virtual; {Lock the message base}
Function UnLockMsgBase: Boolean; Virtual; {Unlock the message base}
Function WriteMailIdx(FN: String; MsgPos: Word): Word; Virtual; {Write
Netmail or EchoMail.jam}
Procedure SetDest(Var Addr: AddrType); Virtual; {Set Zone/Net/Node/Point for
Dest}
Procedure SetOrig(Var Addr: AddrType); Virtual; {Set Zone/Net/Node/Point for
Orig}
Procedure SetFrom(Name: String); Virtual; {Set message from}
Procedure SetTo(Name: String); Virtual; {Set message to}
Procedure SetSubj(Str: String); Virtual; {Set message subject}
Procedure SetCost(SCost: Word); Virtual; {Set message cost}
Procedure SetRefer(SRefer: LongInt); Virtual; {Set message reference}
Procedure SetSeeAlso(SAlso: LongInt); Virtual; {Set message see also}
Function GetNextSeeAlso: LongInt; Virtual;
Procedure SetNextSeeAlso(SAlso: LongInt); Virtual;
Procedure SetDate(SDate: String); Virtual; {Set message date}
Procedure SetTime(STime: String); Virtual; {Set message time}
Procedure SetLocal(LS: Boolean); Virtual; {Set local status}
Procedure SetRcvd(RS: Boolean); Virtual; {Set received status}
Procedure SetPriv(PS: Boolean); Virtual; {Set priveledge vs public status}
Procedure SetCrash(SS: Boolean); Virtual; {Set crash netmail status}
Procedure SetKillSent(SS: Boolean); Virtual; {Set kill/sent netmail status}
Procedure SetSent(SS: Boolean); Virtual; {Set sent netmail status}
Procedure SetFAttach(SS: Boolean); Virtual; {Set file attach status}
Procedure SetReqRct(SS: Boolean); Virtual; {Set request receipt status}
Procedure SetReqAud(SS: Boolean); Virtual; {Set request audit status}
Procedure
Re: [fpc-devel] Copy/move operator
Ryan Joseph schrieb am So., 16. Juni 2019, 15:29: > I just came across an efficiency issue when using management operators > that I’d like to fix before the next release and we have backwards > compatibility problems. > > Basically the problem is that the Copy operator doesn’t know if the source > value is actually mapped to memory or just a temporary value so we’re > forced to always copy memory (just to be safe) even when a simple move > would be good enough. C++ has a similar idea of rvalues and lvalues and a > copy and move constructor which addresses this. > > Here’s a little example of the problem. What I propose is that we either > add a 3rd boolean parameter to the Copy operator or add a new Move operator > which is preferred over the Copy operator if it exists (this is much more > work obviously but maybe has some benefit). > If we do this at all we should use a separate operator as those two are rather different operations and the compiler would already have figured out which of the two operations is needed and thus the code inside the operator doesn't need to do that anymore. That said this would require extending the RTL assignment helper. And the problems that Jonas mentioned are less problems inside the compiler, but problems inside the user code when they write their Move operator incorrectly. From great power comes great responsibility after all and I'm not sure whether we should provide the users with that much power. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades (new)
schrieb am Mo., 17. Juni 2019, 14:15: > On 6/17/19 1:54 AM, Sven Barth via fpc-devel wrote: > > schrieb am Mo., 17. > > Juni 2019, 02:07: > > > > what always confused me these days is that records and objects were > one thing > > back in the (TP6) day but today they are something quite > different... i had to > > be very careful when i wrote my satellite TLE management tool > because of these > > differences... > > > > > > Ehm... TP style objects were already quite different to records back in > TP days. > > > yes... what i'm saying is that today's are different and that's what > confuses me... > You are talking about classes, aren't you? > > After all the former supported inheritance and (virtual) methods while > the later > > supported variant parts. > > > in the day that i speak of, records were simple static blocks that > contained > data in a certain defined order... today's records have methods, too, > which are > more like objects back then... i forget the difference between yesterday's > objects and today's... > But back in the days the objects were already different from records. And yes, both are again different from classes. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Copy/move operator
> On Jun 17, 2019, at 2:19 AM, Jonas Maebe wrote: > > And which also causes hard-to-find memory corruption bugs. How so? I looked into this yesterday and it’s pretty easy to tell if a node is temporary memory or not, but if there’s a chance it isn’t then calling the copy operator is still safe. > >> Here’s a little example of the problem. What I propose is that we >> either add a 3rd boolean parameter to the Copy operator or add a new >> Move operator which is preferred over the Copy operator if it exists >> (this is much more work obviously but maybe has some benefit). > > The compiler knows that source is a temporary value that will be gone > afterwards, so it could perform this optimisation itself in this case. It > won't be possible to always do this and there are undoubtedly cases where a > dedicated Move operator would result in more optimal code, but > maintainability and safety are also important. If the compiler knows the source is temporary then why can’t the copy operator be told of this? This is specifically for the new management operators (which are always called) so the compiler can’t make any optimizations here anywhere. Seems like an obvious win to me to gain some performance and avoid unnecessary copies. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades (new)
On 6/17/19 1:54 AM, Sven Barth via fpc-devel wrote: schrieb am Mo., 17. Juni 2019, 02:07: what always confused me these days is that records and objects were one thing back in the (TP6) day but today they are something quite different... i had to be very careful when i wrote my satellite TLE management tool because of these differences... Ehm... TP style objects were already quite different to records back in TP days. yes... what i'm saying is that today's are different and that's what confuses me... After all the former supported inheritance and (virtual) methods while the later supported variant parts. in the day that i speak of, records were simple static blocks that contained data in a certain defined order... today's records have methods, too, which are more like objects back then... i forget the difference between yesterday's objects and today's... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Copy/move operator
On 2019-06-16 15:29, Ryan Joseph wrote: Basically the problem is that the Copy operator doesn’t know if the source value is actually mapped to memory or just a temporary value so we’re forced to always copy memory (just to be safe) even when a simple move would be good enough. C++ has a similar idea of rvalues and lvalues and a copy and move constructor which addresses this. And which also causes hard-to-find memory corruption bugs. Here’s a little example of the problem. What I propose is that we either add a 3rd boolean parameter to the Copy operator or add a new Move operator which is preferred over the Copy operator if it exists (this is much more work obviously but maybe has some benefit). The compiler knows that source is a temporary value that will be gone afterwards, so it could perform this optimisation itself in this case. It won't be possible to always do this and there are undoubtedly cases where a dedicated Move operator would result in more optimal code, but maintainability and safety are also important. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
