[fpc-devel] heap.inc evo when

Florian Klämpfl florian at freepascal.org
Fri Apr 18 15:53:42 CEST 2025



> Am 18.04.2025 um 15:44 schrieb Michael Van Canneyt via fpc-devel <fpc-devel at lists.freepascal.org>:
> 
> 
> 
> On Fri, 18 Apr 2025, Florian Klämpfl via fpc-devel wrote:
> 
>> 
>> 
>>> Am 18.04.2025 um 15:10 schrieb Michael Van Canneyt via fpc-devel <fpc-devel at lists.freepascal.org>:
>>> 
>>> 
>>> 
>>> On Fri, 18 Apr 2025, Michael Van Canneyt via fpc-devel wrote:
>>> 
>>>> 
>>>> 
>>>> On Fri, 18 Apr 2025, Florian Klämpfl via fpc-devel wrote:
>>>> 
>>>>>> Am 18.04.2025 um 14:07 schrieb Michael Van Canneyt via fpc-devel <fpc-devel at lists.freepascal.org>:
>>>>>> On Fri, 18 Apr 2025, Florian Klämpfl via fpc-devel wrote:
>>>>>>>> Am 16.04.2025 um 12:00 schrieb Michael Van Canneyt via fpc-devel <fpc-devel at lists.freepascal.org>:
>>>>>>>> On Wed, 16 Apr 2025, Florian Klämpfl via fpc-devel wrote:
>>>>>>>>> On 15.04.25 22:52, runewalsh via fpc-devel wrote:
>>>>>>>>>> What’s the position on MR !694? Person with the yellow avatar mentioned in https://gitlab.com/freepascal.org/fpc/source/-/ commit/922457e5b58d76a13ff706f9220d9d6350631930#note_2390656703 there was some discussion somewhere, and that’s all.
>>>>>>>>> Our main issue is that nobody really feels capable of reviewing it :( The initial contributors of the heap manager are basically gone and nobody else is really that deep into this code to do a review.
>>>>>>>> Since Runewalsh is deep in it, clearly we're not off worse if we change it :-)
>>>>>>>> So, in order to progress: we'll throw it in the wild to be field-tested.
>>>>>>>> So I propose the following: I will add the new heap manager in a new file.
>>>>>>> Please do it in a way which preserves line history: copy heap.inc to oldheap.inc, add and commit it. Then accept the merge request. Add ifdefs. So heap.inc keeps line history making debugging in the future easier.
>>>>>> I intended to do it more or less so, yes.
>>>>> The way you did it, line history is broken :(
>>>> 
>>>> Huh ? This makes no sense to me.
>>>> 
>>>> What's the point of having "git mv" if it does not preserve history?
>>> 
>>> I checked, I can do "git log" on both files, and I get the full history (for
>>> oldheap.inc you need to add --follow to get it)
>>> 
>>> Is this not what you wanted ?
>> 
>> When I do git blame I get:
>> 
>> c8bf474d6d0 (Michaël Van Canneyt 2025-04-18 14:44:24 +0200    1) {
>> c8bf474d6d0 (Michaël Van Canneyt 2025-04-18 14:44:24 +0200    2)     This file is part of the Free Pascal run time library.
>> c8bf474d6d0 (Michaël Van Canneyt 2025-04-18 14:44:24 +0200    3)     Copyright (c) 1999-2000 by the Free Pascal development team.
>> c8bf474d6d0 (Michaël Van Canneyt 2025-04-18 14:44:24 +0200    4)
>> c8bf474d6d0 (Michaël Van Canneyt 2025-04-18 14:44:24 +0200    5)     functions for heap management in the data segment
>> c8bf474d6d0 (Michaël Van Canneyt 2025-04-18 14:44:24 +0200    6)
>> c8bf474d6d0 (Michaël Van Canneyt 2025-04-18 14:44:24 +0200    7)     See the file COPYING.FPC, included in this distribution,
>> c8bf474d6d0 (Michaël Van Canneyt 2025-04-18 14:44:24 +0200    8)     for details about the copyright.
>> c8bf474d6d0 (Michaël Van Canneyt 2025-04-18 14:44:24 +0200    9)
>> c8bf474d6d0 (Michaël Van Canneyt 2025-04-18 14:44:24 +0200   10)     This program is distributed in the hope that it will be useful,
>> c8bf474d6d0 (Michaël Van Canneyt 2025-04-18 14:44:24 +0200   11)     but WITHOUT ANY WARRANTY; without even the implied warranty of
>> c8bf474d6d0 (Michaël Van Canneyt 2025-04-18 14:44:24 +0200   12)     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>> c8bf474d6d0 (Michaël Van Canneyt 2025-04-18 14:44:24 +0200   13)
>> c8bf474d6d0 (Michaël Van Canneyt 2025-04-18 14:44:24 +0200   14)  **********************************************************************}
>> c8bf474d6d0 (Michaël Van Canneyt 2025-04-18 14:44:24 +0200   15)
>> c8bf474d6d0 (Michaël Van Canneyt 2025-04-18 14:44:24 +0200   16) {****************************************************************************}
>> c8bf474d6d0 (Michaël Van Canneyt 2025-04-18 14:44:24 +0200   17) { Do not use standard memory manager }
>> c8bf474d6d0 (Michaël Van Canneyt 2025-04-18 14:44:24 +0200   18) { $define HAS_MEMORYMANAGER}
>> c8bf474d6d0 (Michaël Van Canneyt 2025-04-18 14:44:24 +0200   19)
>> c8bf474d6d0 (Michaël Van Canneyt 2025-04-18 14:44:24 +0200   20) { Memory manager }
>> c8bf474d6d0 (Michaël Van Canneyt 2025-04-18 14:44:24 +0200   21) {$if not defined(FPC_NO_DEFAULT_MEMORYMANAGER)}
>> c8bf474d6d0 (Michaël Van Canneyt 2025-04-18 14:44:24 +0200   22) const
>> c8bf474d6d0 (Michaël Van Canneyt 2025-04-18 14:44:24 +0200   23)   MemoryManager: TMemoryManager = (
>> c8bf474d6d0 (Michaël Van Canneyt 2025-04-18 14:44:24 +0200   24)     NeedLock: false;  // Obsolete
>> c8bf474d6d0 (Michaël Van Canneyt 2025-04-18 14:44:24 +0200   25)     GetMem: {$ifndef FPC_NO_DEFAULT_HEAP}@SysGetMem{$else}nil{$endif};
>> c8bf474d6d0 (Michaël Van Canneyt 2025-04-18 14:44:24 +0200   26)     FreeMem: {$ifndef FPC_NO_DEFAULT_HEAP}@SysFreeMem{$e
>> 
>> ? Does it work for you?
> 
> No, I get the same.
> 
> But I only checked the workings of git log.
> 
> But now I understand correctly what you meant by "line history" : the "git blame"
> output. I implicitly assumed you meant 'linear history' :-(

Yes :) It often helps to understand code. But I think I can fix it without rewriting git history. Though that one of oldheap.inc will be gone but it doesn’t matter for oldheap.inc imo.

> 
> My apologies, if I had correctly understood, I would have done exactly as you said :/
> 
> Michael._______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org <mailto:fpc-devel at lists.freepascal.org>
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20250418/46d0c28b/attachment-0001.htm>


More information about the fpc-devel mailing list