Re: [fpc-pascal] Where and Why is there a memory leak?
On 06.09.2017 18:03, Graeme Geldenhuys wrote: Quite likely. It did all sound awfully familiar. :-) Is there even a thinkable solution ? To me the offering of two incompatible kinds of interfaces (not regarding the external libraries but the language construct) seems rather odd, especially as the language construct is decently usable without attaching to an external library. In fact to me it's already off to create a language construct based on the dedicated makeup of some external library at all. It would be better to have an independent and usable language construct that just offers means to optionally attach to certain types of libraries. OTOH, another related construct already discusses multiple times (and seemingly offered by Embarcadero) is ref counted "normal" objects. But those are known to introduce certain pitfalls, as well. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Using Serial in a TCP/RS232 gateway, how to set buffer sizes?
On 06.09.2017 20:35, Bo Berglund wrote: The problem is that when the Windows app is done sending the data system is still missing many kilobytes So no ACK is returned, it is still in receive mode. On serial lines bits and bytes always can get lost or be distorted, independent from OS, hardware, ... Any data transfer software needs to use appropriate means (i.e. appropriately small packets. counting packet number. ACK block containing the packet number it answers to, timeout, retransmit, ...) to handle this. Moreover, with USB serial adapters I rather often found that the loose the connection to the OS and can't be re-established without a power cycle. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Using Serial in a TCP/RS232 gateway, how to set buffer sizes?
On 06.09.2017 20:35, Bo Berglund wrote: ... (i.e. appropriately small packets. counting packet number. ACK block containing the packet number it answers to, timeout, retransmit, ...) Not to forget: save detection of block start and block end (and hence introducing a decent transparentizing scheme, and using a block check (e.g. CRC). -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Inclocked/declocked
On 11/09/17 19:45, Sven Barth via fpc-pascal wrote: I've rechecked and the thing is as follows:- the IncLocked call happens each time you assign a dynamic array toanother dynamic array variable or a by-value parameter (this alsoincludes being part of a record, but not a class instance or TP-styleobject)- the DecLocked call happens each time the array is cleared (as long asthe reference count is > 0 this only means a decrement of the count)which happens if you assign Nil, assign a different array (thedestination array is "cleared") or if the array variable goes out of scope The two routines are also used in context of Ansi- and UnicodeStringvariables as well as reference counted interfaces (aka COM-styleinterfaces). In contrast to what I wrote earlier the compiler does however not ensurea unique array if you only change an element, so given the followingexample: In the general case, will these force a membar or a cache flush? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Inclocked/declocked
> On Sep 12, 2017, at 12:56 PM, Sven Barth via fpc-pascal > wrote: > > The Inc-/DecLocked routines perform a locked increment/decrement, so they're > blocking the memory bus for all cores (simply spoken), thus leading to a > higher CPU utilization. On e.g. i386 there is an optimisation to only do that > locking if IsMultiThread is True (some other platforms might benefit from > that optimization as well :/ ). > Additionally they are the leave routines of the dynamic array management > code, so the time would be really used up there if not for the locking. That’s probably it then even though I wasn’t growing the arrays by single elements (ReAllocMem didn’t give me problems). De facto Solution is to be safe and not use dynamic arrays in low-level high performance code. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Comparison operator for generics
> On Sep 12, 2017, at 12:59 PM, Sven Barth via fpc-pascal > wrote: > > You could try to use the TEqualityComparer<> (or so) types from the > rtl-generics package (don't know in which unit exactly they are ^^') as those > can work with records without operator overloads. > Do any examples of how to use the class exist? I searched around and couldn’t find a single snippet even though it appears to exist in Delphi. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Comparison operator for generics
2017-09-12 11:07 GMT+02:00 Ryan Joseph : > > Do any examples of how to use the class exist? I searched around and > couldn’t find a single snippet even though it appears to exist in Delphi. Please check example at : packages\rtl-generics\examples\tcomparer\tcomparerproject.lpr -- Best regards, Maciej Izak ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Comparison operator for generics
2017-09-12 7:59 GMT+02:00 Sven Barth via fpc-pascal < fpc-pascal@lists.freepascal.org>: > You could try to use the TEqualityComparer<> (or so) types from the > rtl-generics package (don't know in which unit exactly they are ^^') as > those can work with records without operator overloads. > Generics.Defaults :P -- Best regards, Maciej Izak ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Comparison operator for generics
> On Sep 12, 2017, at 4:46 PM, Maciej Izak wrote: > > Please check example at : > packages\rtl-generics\examples\tcomparer\tcomparerproject.lpr Thanks. What is the & here? TCompare.&String(Left.Name, Right.Name); I don’t think I’ve ever seen that before. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Comparison operator for generics
On Tue, 12 Sep 2017, Ryan Joseph wrote: On Sep 12, 2017, at 4:46 PM, Maciej Izak wrote: Please check example at : packages\rtl-generics\examples\tcomparer\tcomparerproject.lpr Thanks. What is the & here? TCompare.&String(Left.Name, Right.Name); I don’t think I’ve ever seen that before. It means you use a language keyword as an identifier. An ugly habit, but unfortunately inherited from Delphi. Originally intended to be able to create imports of other languages (think SOAP, COM) it is now of course abused... Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
