[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