بلوج شناوي

لية نيو ڤيم في عصر الاجينتس؟

Thu, 16 Jul 2026 00:00:00 GMT

Introduction

انا بكتب كود بقالي 4 سنين تقريباً. في الفترة دي, انا بدأت زي اي طالب CS بـVSCode. عايز اكتب كود, هكتبه كأني بكتب اي Text تاني. عايز اعمل Run للكود بتاعي, كنت بدوس Shortcut و VSCode يشغلهولي. مكنتش فاهم اصلاً الكود بيشتغل ازاي. كنت عارف انه It just runs.

How Neovim and I met

بعدها بفترة, بدأت اتفرج على يوتيوبر اسمه ThePrimeagen. ساعتها كان Software Engineer في Netflix, وكنت كل لما ابص عالـStreams بتاعته على Twitch او YouTube, عيني مكنتش بتعرف تواكب اصلاً هو بيعمل اية. بعيداً عن ان سرعته فالكتابة عالية جداً, وانه بيستعمل Keyboard غير العادية (dvorak), بس دا مكنش السبب الرئيسي اللي كان مخليه سريع. السبب الرئيسي كان الـText Editor بتاعه, Neovim.

What is Neovim

لو معندكش فكرة, Neovim هو Fork من Text Editor تاني اسمه Vim. Vim قديم جداً, اتعمل سنة 1991. وهو ذات نفسه كان تحسين لـText Editor اقدم منه اسمه Vi.

كان في زي حرب بين Vim و Emacs فترة, بس المعارك دي خلصت خلاص, لكنها لسة موجودة فالـProgramming Culture. لو جيت تعمل جوجل لـVim مثلاً, هيقولك Did you mean emacs, والعكس بيحصل برضو.

Neovim شغال على الـTerminal. بمعنى ان يعتبر مفيش GUI, اللي هي Window بتظهرلك الـUI. بيرسم الـUI بتاعه على الـTerminal.

لعده اسباب, Neovim سريع جداً. بيفتح في اقل من 100ms على حسب الـCPU بتاعك, حتى لو حاطت عشرات الـPlugins.

Neovim عبارة عن Modal Text Editor. يعني بتدخل في كذا Mode عشان تعمل حاجات. مينفعش مثلاً تعمل Hold لـShift وتنزل, ويقوم عاملك Selection. محتاج تدخل الـVisual Selection Mode. لو عايز تكتب, لازم تدخل الـInsert Mode. لو عايز تتحرك, لازم تدخل الـNormal Mode وهكذا. عشان كدا, الـLearning Curve ممكن يكون عالي شويتين.

الهدف من الـArticle دي مش انك تعرف تستعمل Neovim. في مقولة بتقول “You don’t know what you don’t know”. تحسها بديهية شوية, لكنها حقيقة. عمرك ماكنت هتجرب Neovim لو محدش قالك عليه, عشان انت متعرفش انها حاجة موجودة اصلاً.

زي مثلاً واحد عمره ما جرب حاجة غير المفكات العادية, مش هيفكر يسأل عن المفكات الكهربائية اصلاً. هو شايف ان المهمة بتتعمل, خلاص. نفس الكلام مع Neovim. لو انت شغال بـVSCode وخلاص, مش هتعرف ان في أسلوب تاني للكتابة خالص, وهتفضل فاكر ان الـVSCode هو الحقيقة المطلقة.

وعشان انا شايف ان A Picture is Worth a Thousand Words, قررت اني اظهر حاجات انت ممكن تعملها بـNeovim, صعب تتعلم بـEditors تانية.

Practical Examples

هنا مثلاً حاجة Practical. غالباً كنت محتاج حاجة زي دي قبل كدا.

او لو مثلاً, عايز اغير If statements لـSwitch Statment بسرعة بالـRegex Substitution:

ممكن تضيف Plugins جديدة. مثلاً لو عايز تعمل Exchange للـFunction Arguments, ممكن تستعمل Plugin mini.ai

في Plugin برضو اسمها flash.nvim. بتخليك تعمل Remote Operations, مثلاً تروح تعمل Delete لحاجة في مكان تاني وترجع تـPasteها مكان ما كنت واقف:

Any Agent Could Do This…

كل الحركات دي جامدة اوي وبتخليك سريع وكل حاجة. لو جيت تكتب Prompt واحدة الحاجات دي هتتعمل كلها عادي. طبعاً, بالوقت اللي انت بتستعمله عشان تكتب الـPrompt غالباً هيبقى اطول من الوقت اللي محتاجه عشان تعمل الحاجة دي اصلأ, ولكنها هتتعمل, ومش هضطر تتعلم Text Editor تاني من الاول.

الـBenefits بتاعت Neovim عمرها ماكانت في السرعة. دا عامل كبير, بس ليا انا شخصياً دا مكنش اكبر Benefit ليا.

الـBenefit الأكبر هو الـEcosystem. اول لما تستعمل الـVim Motions, مش هتعرف متستعملهاش في حاجة تانية. هتلاقيها في كل حاجة: الـBrowser (Vimium), الـFile Manager (ranger/lf/yazi), الـShell (set -o vi في zsh/bash), tmux, git, وحتى الـIDEs التانية (VS Code Vim extension, JetBrains IDEAVim). كلهم فيهم support للـVim Motions. بتكون حركة واحدة موحدة على كل حاجة بتستخدمها في الكمپيوتر.

الـBenefit الأخر هو انك تتعود على الـCLI. يعتبر هتعيش جواه, هتحس ان اي حاجة تانية بطيئة, Bloated. هتبقى عادي عندك تعمل حاجات combine بين أدوات CLI مختلفة بـpipes, تدير sessions بـtmux, تعمل search و replace بـgrep و sed, تتعامل مع git بسرعة, تشتغل على servers بعيدة بـ ssh و nebula من غير ما تفتح حاجة تانية. الـCLI بيديك control كامل على كل حاجة.

حاجة تانية هي الـCommunity. مع اي حاجة بتعملها بتلاقي Support كبير جداً. انا مثلاً كنت عامل xdg-nvfilechooser, ورغم ان الـProject مش Complete, الا اني لقيت دعم كبير لأن الناس عجبها الفكرة.

هتلاقي في Overlap كبير في الـCommunity بتاعت Neovim, و الـCommunities الأخرى بتاعت الـProgrammers اللي بيقولوا عليهم “cracked.” غالباً هتلاقي اللي بيستعمل Neovim شخص عنده خبرة كبيرة في المجال بتاعه. دي حاجة لاحظتها, والناس دي ممكن تتعلم منها فعلاً.

مثلاً, عمري ماكنت هكون كويس في Rust من غير الـYouTube Channel بتاعت Jon Gjengset, والكتب بتاعته. عايزك تخمن الـEditor بتاعه اية.

في برضو sphaerophoria. بيستعمل Zig و Rust على طول, ومش بفهم 99 فالمية من الكود اللي بيكتبه لأنه على Level اخر بصراحة. خمن الـEditor بتاعه برضو.

هتلاقي برضو Overlap بين الـCommunity بتاعت Neovim و Nix. لو متعرفش, Nix هو Package Manager لـLinux. من الـResources اللي فادتني هي الـYouTube Channel بتاعت Tweag. خمن الـEditor اللي بيستعملوه.

مش معنى ان الناس دي كلها بتستعمل Neovim ان انت اول لما تستعمله وتتقنه هتبقى فظيع بقا ومفيش منك اتنين لأ. الفكرة ان الناس اللي بتحب تستعمل Neovim ليها Mindset معينة, والناس اصحاب الـMindset دي بحب اتعلم منها. بيكون عندهم شغف, حُب للي بيعملوه.

Conclusion

لو عايز تتعلم اكتر عن Neovim, منصحكش تبدأ بالـEditor. ابدأ بأي Extension بتعمل Implementation للـVim Motions في الـEditor اللي انت بتستعمله already. لما تتعود, ممكن تغوص بقا في الـText Editor نفسه.

ادخل الحلبة

Sun, 12 Jul 2026 00:00:00 GMT

لية بنستعمل Python؟ JavaScript؟ Java؟ Dart؟ اي طالب CS في سنة اولى ممكن يقولك ان اللغات دي بطيئة بالنسبة للغات تانية زي C. لو احنا عايزين الـSoftware بتاعنا يبقى اسرع مايمكن, لية بنستعمل اللغات دي لما ممكن نكون بنستعمل C++ مثلاً في كل حاجة؟

الأجابة بسيطة: Ease of use. اللغات دي سهلة جداً فالاستعمال, الـSyntax بتاعها بسيط, بتقرأ زي الـEnglish, غالباً بتبقى Portable, ومن اهم الصفات انها Garbage Collected.

Garbage Collected يعني الـCoder مش بيفكر فالـMemory. بينساها من دماغه (Ironically). لو كتبت برنامج بيستعمل 100 كيلوبايت, انا مش محتاج اعمل للـ100 كيلوبايت دي free, لأني عارف ان الـRuntime بتاعت اللغة بتاعتي هتنقذني و هتحرر الـMemory اللي طلبتها دي في وقت ما.

الوضع مكنش كدا على طول, معظم الـCoders زمان كانوا بيستعملوا Manual Memory Management, بيقولوا للكمبيوتر: انا هعمل Object. الـObject دي كلها على بعضها 100 كيلوبايت. الكمبيوتر مهمته الوحيدة انه يرجعلك الـMemory دي عشان تحط عليها الـData اللي انت محتاجها. مش مهمته انه يحرر الـMemory دي في وقت اخر. دي مهمتك انت.

هفترض في الـArticle دي انك عندك فكرة عن الـHeap, الـStack, و اية malloc و free.

Stack Based Allocations

وانت بتتعلم برمجة لأول مرة في حياتك بتعرف ان في طريقتين انك تعمل ميموري. على الـStack او على الـHeap. غالباً اتعلمت ان الـStack اسرع عشان الميموري بتبقى ورا بعض, والـHeap ابطىء عشان الميموري بتبقى مبعثرة. وانك بتستعمل الـHeap لما متكونش عارف الـObject اللي انت عايزها هتبقى قد اية, فانت بتستعمل Dynamic Memory. الكلام دا مش دقيق اوي, انت ممكن بسهولة تستعمل الـStack عشان تعمل Dynamic Memory, بطريقة هنشوفها بعدين.

تخيل الكود اللي تحت دا:

def three():
    e = 3
    f = 3
    g = 3


def two():
    b = 2
    c = 2


def one():
    a = 1
    two()

def main():
    one()

if __name__ == "__main__":
    main()

لو جينا نبص على الـBytecode بتاع Python دا على Godbolt, وركزنا على three هنلاقي دا:

Disassembly of <code object three at 0x5676616f8980, file "example.py", line 1>:
  1           RESUME                   0

  2           LOAD_SMALL_INT           3
              STORE_FAST               0 (e)

  3           LOAD_SMALL_INT           3
              STORE_FAST               1 (f)

  4           LOAD_SMALL_INT           3
              STORE_FAST               2 (g)
              LOAD_CONST               1 (None)
              RETURN_VALUE

لاحظ ان في 3 Store (Allocate) بس مفيش اي Deallocate. عشان الـStack Frame كله بيتشال مرة واحدة, فا دا يعتبر الـDeallocate بتاعك.

الـVariables اللي احنا بنعملها بتتشال كلها مرة واحدة, عشان الـStack Frame كله بيتشال.

سؤال بقا, احنا لية منستعملش الـStack لكل حاجة؟ الـStack تعتبر حاجة Efficient جداً. بتعمل Allocation واحدة لكل Object, و Deallocation لكل الـObjects لما الـLifetime بتاعت الـStack Frame تخلص.

الفكرة كلها مش اننا عايزين Dynamic Memory. احنا لو عايزين Dynamic Memory, دي حاجة ممكنة على الـStack بـAPI اسمه alloca موجود في الـStdlib بتاعت C. الفكرة ان احنا عايزين الـMemory بتاعتنا تطلع براالـStack Frame. مش عايزين الـMemory اللي احنا بنعمله تروح بعد مالـFunction Call تخلص.

Heap Based Allocations

على الجانب الأخر عندنا الـHeap. الطريقة العادية انك تعمل Allocation على الـHeap هي انك تستعمل الـC API اللي اسمه malloc و free.

الـAPI بتاعهم مش صعب يتفهم, والهدف من الـArticle دي مش انك تتعلم malloc و free, لكن انك تتعلم Advanced Techniques للـMemory Allocation.

الفكرة بتاعت malloc و free بسيطة. عايز ميموري؟ اطلب بـmalloc. معنتش عايزها؟ حررها بـfree. لو انتظمت على الشكل دا, البرنامج بتاعك مستحيل يبقى فيه Memory Leak.

الـParadigm دا حلو. لكل malloc, لازم يبقى في free تصاحبها. لكن، في الواقع، الموضوع مش سهل بالبساطة دي دايماً.

Manual Memory Management: Problems

اصدقائنا بتوع الـCybersecurity عارفين ان جزء كبير من مجالهم موجود عشان يلاقي كود بيستعمل malloc و free بطريقة غلط. زي انك تعمل free مرتين (Double Free), وهو ممكن يخليك تكتب على Memory اتحجزت لحاجة تانية خالص من غير ما تاخد بالك. او انك تـmalloc لـBuffer صغير عن حجم الـData اللي هتحطها فيه, فتكتب برا حدود الـBuffer وتبوظ Memory جنبه. فانت لازم تاخد بالك كويس وانت بتستعمل الـAPI دا.

رغم كدا، كل لسه محتاج يدور على مساحة مناسبة، ويحدث الـMetadata الداخلية بتاعته، ويتعامل مع مشاكل زي الـFragmentation. يعني حتى لو مفيش Syscall، فهو مش Operation ببلاش.

ان الـOperation ممكن تكون Expensive شوية مش الحاجة الوحيدة السيئة في الـParadigm دا. لو انت عندك Graph كله Objects, انك تعرف انهي Node تعمله free الأول ممكن يبقى صعب, بالذات لو الـGraph Cyclic.

حتى لو استعملت الـAPI صح 100%، لسه فيه تكلفة بتدفعها. الـ ممكن يضطر يطلب Memory جديدة من الـOS، ودا بيكون مكلف لأنه غالباً بيتضمن System Call. لكن معظم الـAllocators الحديثة مبتعملش Syscall لكل malloc. بدل كدا، بتطلب Chunk كبيرة من الـMemory مرة واحدة، وبعدها تقسمها بنفسها على الـAllocations الصغيرة اللي برنامجك بيطلبها.

300,000 Rats

تخيل انك بتعمل لعبة. لعبة زي مثلاً A Plague Tale: Requiem. بيكون موجود اكتر من 300,000 فار عالـScreen. بعيداً عن صعوبة الـRendering اصلاً على الـGPU, الـCPU محتاج يـTrack الـObject نفسها عشان الـLogic بتاع الفار نفسه. هو بالتأكيد ان مش كل فار Object لوحده, بيحصل Merging لكن نفترض ان في اللعبة الخيالية بتاعتنا دي ان احنا مضطرين نخلي كل فار Object لوحده.

هنعمل Creation للـObjects دي ازاي؟ احنا لو عملنا 300,000 Allocation مرة واحدة حرفياً مش هنخلص. تخيل انك عندك Ability فاللعبة برضو انك تقتل كل الـEnemies على الـScreen. لما تقتل الـEnemies بيختفوا. هل هنعمل 300,000 free؟

الحل الانسب عندنا, ان مادام الـEnemies دي بيتعملها Spawn مرة واحدة, وبيختفوا مرة واحدة برضو, ان احنا نعمل Allocation واحدة بس للـEnemies كلهم, واننا نعمل Deallocation مرة واحدة برضو. لأن الـEnemies دول حياتهم كلهم يعتبر مرتبطين ببعض. الـLifetime بتاعتهم مرتبطة ببعض.

Lifetimes

غالباً الناس اللي بتتعلم Rust جالهم PTSD Flashbacks لما شافوا الـSubtitle دا. مش هنتكلم كتير عن الـLifetimes لأنهم معقدين, لكن هنتكلم بمنظور عام.

بطريقة بسيطة خالص: الـLifetime بتاعت Object هي المدة اللي الـObject تعتبر Valid فيها, وتقدر تستخدمها.

هنا مثلاً, انا مقدرش استعمل a_1 و a_2 بعد ما الـScope (نهاية الـBrackets) بتاعتهم تخلص.

{
    let a_1 = 1;
    let a_2 = 2;
}

زي كدا:

{
    let a_1 = 1;
    let a_2 = 2;
}

// Invalid.
console.log(a_1);

بعيداً عن تعقيدات JavaScript اللي ليها علاقة بالـScope, الـConcept دا موجود في تقريباً كل لغة برمجة موجودة حالياً.

لو عايزين نعمل Lifetime تانية, هنبدا Scope تاني. عشان نقدر نـTrack الـLifetimes بتاعتنا, احنا هنسميهم. هنسميهم a و b مثلاً.

// lifetime a start
{
    let a_1 = 1;
    let a_2 = 2;
}
// lifetime a end

// lifetime b start
{
    let b_1 = 1;
    let b_2 = 2;
}
// lifetime b end

ملاحظ اية؟ كل رقمين جوا كل Scope مرتبطين ببعض. الـLifetime بتاعتهم مرتبطة ببعض. أول لما الرقمين يبقوا Out of Scope، احنا ممكن نشيلهم كلهم مرة واحدة، عشان كدا كدا مفيش رقم هيعيش بعد التاني. لو رقم من الرقمين انتهت الـLifetime بتاعته، يبقى الرقم التاني ضروري إن الـLifetime بتاعته تنتهي برضو, لأنهم اتعملوا في نفس الـScope.

الـStack بتعمل كدا بالظبط, زي ماشوفنا فوق. كل Variable جوا الـStack Frame الـLifetime بتاعتها مربوطة بـLifetime الـFrame نفسه.

اللي احنا عايزينه دلوقت: احنا عايزين طريقة تخلينا نقدر نربط الـLifetimes بتاعت الـObjects بتاعتنا ببعض زي الـStack, نتجنب الصعوبات بتاعت malloc و free, ونعرف نحدد نهاية الـLifetime نفسها براحتنا.

The Arena Allocator

الحل للمشكلة بتاعتنا دي هي الـArena Allocation. الفكرة كلها انك بتبدأ بأنك تعمل malloc واحد لـBuffer كبير, وبعد كدا تستعمل الـRegion دا في انك تضيف الـObjects بتاعتك. الـObjects ممكن تكون من اي نوع, واحجامهم ممكن تكون مختلفة. ولما تخلص من الـArena, تعمل Reset للـMemory دي بس.

في Techniques كتير انك تعمل Arenas, هنعمل Implementation لأشهر نوع, اسمه Bump Allocator. هنستعمل C.

The Arena Struct

دي اول حاجة هنعملها. كل اللي احنا محتاجينه جوا الـStruct بتاعنا هو Buffer عشان نحط فيه الـData, ومحتاجين نعرف الـSize بتاع الـBuffer دا.

#include <stddef.h>

typedef struct Arena {
    unsigned char* buffer;
    size_t buffer_size;
} Arena;

int main(int argc, char* argv[]) {
    return 0;
}

عشان نعمل الـArena محتاجين نعمل Function. الـFunction هنسميها Arena_malloc وهترجع Pointer للـStruct اللي احنا عاملينه.

Arena* Arena_malloc(size_t buffer_size) {
    // One malloc to create the struct.
    Arena* arena = malloc(sizeof(Arena));
    arena->buffer_size = buffer_size;

    // Another malloc to create the buffer.
    arena->buffer = malloc(buffer_size);
    return arena;
}

دلوقت, لو عايزين نعمل Arena جديدة, دا كل اللي احنا هنعمله:

int main(int argc, char* argv[]) {
    Arena* a = Arena_malloc(1024);
}

دا هيعمل Buffer حجمه 1024 Byte.

الـBuffer حالياً شكله كدا:

Arena Allocation

دلوقت, نستعمل الـArena بتاعتنا ازاي؟

هنعمل Function تانية هنسميها Arena_allocate. كل اللي الـFunction دي هتعمله انها تاخد Size parameter, وبالـSize دا هتحط الـMemory اللي احنا محتاجينها على الـBuffer اللي احنا عاملينه.

لو جينا مثلاً نعمل Allocate لـStruct اسمه Player, وحجم الـStruct دا 120 بايت, الـBuffer هيبقى شكله عامل كدا:

دلوقت, احنا محتاجين حاجة تخلينا نعرف الـBuffer بتاعنا مليان قد اية. هنضيف buffer_offset جوا الـArena struct.

typedef struct Arena {
    ...
    size_t buffer_offset;
} Arena;

CPU Alignment

دلوقت, حاجة زيادة محتاجين نتعلمها. هي الـCPU Alignment.

الـCPUs بتحب تقرأ من الميموري بطريقة معينة. لو انت عندك int (غالباً 4 بايت), يبقى الـAddress بتاع اول بايت محتاج يكون Address يقبل القسمة على الـ4.

فاحنا لو عندنا الـMemory بتاعتنا بالمنظر دا, بادئة من الصفر لحد 1024 (دول Addresses), ومستعملين لحد Address 493, يبقى الـAddress الجديد اللي المفروض نحط عنده الـint بتاعنا هو 496, عشان دا اقرب رقم يقبل القسمة على الـ4.

نعمل اية في الـ3 Addresses اللي بعد 493؟ محتاجين نمليهم. هنمليهم بحاجة اسمها Padding.

طيب, نحسب الـAlignment بتاعت الـData Types بتاعتنا ازاي؟ هتقولي مادام الـAddress بتاع الـData Type محتاج يقبل القسمة على الحجم بتاع الـData Type, فاحنا ممكن نستعمله بـsizeof.

الموضوع مش بالسهولة دي للأسف. تخيل انك عندك حاجة زي كدا:

struct Player {
    char x;
    int y;
};

وان الـMemory بتاعتنا هتبقى كدا:

0    x
1    padding
2    padding
3    padding
4    y
5    y
7    y
8    y

الـsizeof بتاع الـStruct هيدينا 8. لكن الحقيقة ان احنا محتاجين الـAddress يكون يبدأ على Address يقبل القسمة على الـ4.

الـRule of Thumb بتاعت الـAlignment هي ان الـAlignment تساوي اكبر Data Type جوا الـStruct, في الحالة دي اكبر Data Type هي الـint, فالـAlignment هتساوي 4, يعني الـStruct دا محتاج يبدأ على Address يقبل القسمة على 4.

نرجع تاني للـAllocation. عشان نعمل Allocate جوا الـBuffer بتاعنا, محتاجين نعرف حجم الـStruct اللي هنعمله Allocation, والـAlignment بتاعته عشان نعرف نحطه في انهي Address جوا الـBuffer بتاعنا.

void* Arena_allocate(Arena* a, size_t struct_size, size_t struct_alignment) {
    ...
}

محتاجين نعمل Visualization احسن شوية للـBuffer بتاعنا. الـBuffer بتاعنا مش موجود فالـMemory لوحده.

لو الـMemory بتاعتنا مثلاً 4096 بايت, والـBuffer عبارة عن 1024 بايت, ممكن يكون بالمنظر دا:

يبقى, عشان نعمل Allocate المفروض نعمل اية؟ المفروض نبدأ من اول الـAddress بتاع الـBuffer نفسه, ونضيف عليه الـOffset, اللي هو الـBuffer مستخدم قد اية, و كمان نضيف عليه Padding, عشان الـStruct يكون Aligned.

اول حاجة هنعملها, اننا نحسب من اول الـOffset, احنا محتاجين نضيف قد اية عشان نبقى Aligned. لو احنا الـOffset عندنا 5 مثلاً, والـAlignment بـ4, يبقى احنا هنحسب 5 % 4 = 1. يعني الـOffset الحالي قدام 1 بايت بعد الـAlignment الصح. يبقى, عشان نوصل الـAlignment اللي بعده, محتاجين نطرح الـAlignment من النتيجة اللي حسبناها دي. يبقى 4 - 1 = 3. يعني احنا محتاجين نضيف 3 بايت للـOffset الحالي عشان نلاقي الـAddress الصح.

لكن اية اللي هيحصل لو انت عند Alignment صح اصلاً؟ لو الـOffset بـ8, والـAlignment بـ4. هتيجي تحسب 8 % 4 = 4, وهتطرح النتيجة دي من الـAlignment, هيديك 4, لكن دا مش صح. عشان كدا فالأخر محتاجين نعمل mod للنتيجة بتاعتنا تاني. يبقى 4 % 4 = 0. ودي النتيجة الصح بتاعتنا.

الكود هيبقى كدا:

void* Arena_allocate(Arena* a, size_t struct_size, size_t struct_alignment) {
    size_t padding =
        (struct_alignment - (a->buffer_offset % struct_alignment)) %
        struct_alignment;

}

دا هيدينا الـPadding عشان نخلي الـAddress aligned.

Arena Allocation: Continued

عايزين نتأكد ان الـStruct بتاعنا هيكفي جوا الـArena بتاعتنا. هنحسب لو الـOffset بتاعنا + الـPadding + الحجم بتاع الـStruct نفسه اقل من حجم الـArena نفسها.

هنكتب السطر دا:

if (a->buffer_offset + padding + struct_size > a->buffer_size) {
    return NULL;
}

عشان نحسب الـAddress, هنعمل Pointer Arithmetic. هنضيف الـPadding للـAddress بتاع الـPointer بتاع الـBuffer. وكمان هنضيف عليه الـOffset الحالي, اللي بيحسب احنا مستعملين قد اية من الـBuffer.

void* placement_address = a->buffer + a->buffer_offset + padding;

بعد كدا, هنضيف للـOffset بتاعنا الـPadding اللي احنا عملناه, زائد الحجم بتاع الـStruct اللي هنضيفه.

a->buffer_offset += padding + struct_size;

فالأخر, هنـReturn الـAddress بتاعنا.

return placement_address;

ودي الـImplementation كاملة للـAllocation:

void* Arena_allocate(Arena* a, size_t struct_size, size_t struct_alignment) {
    size_t padding =
        (struct_alignment - (a->buffer_offset % struct_alignment)) %
        struct_alignment;

    if (a->buffer_offset + padding + struct_size > a->buffer_size) {
        return NULL;
    }

    void* placement_address = a->buffer + a->buffer_offset + padding;

    a->buffer_offset += padding + struct_size;

    return placement_address;
}

بس كدا. دي كل الـImplementation بتاعت الـAllocator بتاعنا.

Reset & Free

نعمل اية لو عايزين نعيد استعمال الـArena بتاعتنا في حاجة تانية؟ هنكتب Function تانية هنسميها Arena_reset. طبعاً هتفتكر ان الـImplementation دي هتبقى معقدة, بس لأ. دي كل الـImplementation:

void Arena_reset(Arena* a) {
    a->buffer_offset = 0;
}

فكر كدا. لو احنا رجعنا الـOffset بتاعنا في صفر, اية اللي هيحصل؟ لما نيجي نعمل Allocate تاني, هنكتب فوق الـData اللي احنا كنا عاملينها قبل كدا. ممكن تفكر بيها ان احنا اعتبرنا الـData القديمة بتاعتنا Garbage Values, وان احنا بنكتب فوقها وخلاص.

بس, لسة لحد دلوقت معملناش Free للـMemory بتاعت الـBuffer. عايزين Function تعمل كدا.

void Arena_free(Arena* a) {
    // Free the buffer owned by the arena first
    free(a->buffer);
    // Free the arena struct itself
    free(a);
    // `a` is now dangling.
}

Arena Usage

دلوقت, الجزء الممتع. نستعمل الـArena بتاعتنا ازاي؟ تخيل ان احنا بنعمل لعبة. عند كل Frame فاللعبة, محتاجين نعمل Allocate لشوية Ammo مثلاً, او رصاص.

اول حاجة هنعملها هنعمل struct هنسميه Bullet.

typedef struct Bullet {
    float x, y;
} Bullet;

لو حبينا نعمل Allocate, هنعمل حاجة زي كدا:

int main(int argc, char* argv[]) {
    Arena* a = Arena_malloc(1024);

    Bullet* b = (Bullet*)Arena_allocate(a, sizeof(Bullet), _Alignof(Bullet));

    b->x = 10.0;

    return 0;
}

الحاجة الغريبة فالكود دا هي _Alignof. دي بتجيبلنا الـAlignemnt بتاعت اي Type.

بنبدأ الأول بأننا نعمل الـArena بتاعتنا, الـAllocate بترجعلنا Address جوا الـBuffer عبارة عن void*. كل اللي احنا عايزينه ان احنا نعمل Cast للـAddress دا لـPointer للـType بتاعنا. دا مالأخر بيقول “انا معنتش عايز اعامل الـAddress دا كـRaw Bytes. الـAddress دا مخصص لأن يتحط عليه Bytes بتاعت struct Bullet.”

بعد كدا, بنكتب جوا الـAddress دا الـData اللي احنا عايزينها. فالحالة دي خلينا الـx بـ10.0.

كتابة الكود دا مزعجة شوية, فاحنا ممكن نعمل macro يخليلنا الكتابة اسهل.

#define ARENA_ALLOCATE(arena, Type)                                            \
    ((Type*)Arena_allocate((arena), sizeof(Type), _Alignof(Type)))

int main(int argc, char* argv[]) {
    Arena* a = Arena_malloc(1024);

    Bullet* b = ARENA_ALLOCATE(a, Bullet);

    b->x = 10.0;

    return 0;
}

هنعمل دلوقت الـGame Loop بتاعتنا.

int main(void) {
    Arena* a = Arena_malloc(MAX_BULLETS * sizeof(Bullet) + 64);

    // so gcc doesn't optimize this out.
    volatile float sink = 0;

    for (int frame = 0; frame < FRAME_COUNT; frame++) {
        int bullet_count = (frame % MAX_BULLETS) + 1;

        Bullet* bullets = (Bullet*)Arena_allocate(
            a, sizeof(Bullet) * bullet_count, _Alignof(Bullet));

        for (int i = 0; i < bullet_count; i++) {
            bullets[i].x = i * 10.0f;
            bullets[i].y = frame * 5.0f;
        }

        sink += bullets[bullet_count - 1].x;

        Arena_reset(a);
    }

    printf("done, sink = %f\n", sink);
    Arena_free(a);
    return 0;
}

بنعمل Arena واحدة بس قبل مالـLoop تبدأ. عند كل Frame, بنعمل Allocate لـBullets مخصصة بالـFrame دا, بنستخدم الـBullets, وبعد كدا بنعمل Reset للـArena في نهاية الـLoop.

بعد كدا, بنعيد استخدام نفس الـArena عند الـFrame اللي بعد كدا.

الـBenchmark: Arena vs malloc

دلوقت, عايزين نقارن بين الـAllocator بتاعنا, وبين malloc. دا نفس الـVersion بالظبط, بس بـmalloc.

#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>

typedef struct Bullet {
    float x, y;
} Bullet;

#define FRAME_COUNT 2000000
#define MAX_BULLETS 50

int main(void) {
    // same thing
    volatile float sink = 0;

    for (int frame = 0; frame < FRAME_COUNT; frame++) {
        int bullet_count = (frame % MAX_BULLETS) + 1;

        Bullet* bullets = (Bullet*)malloc(sizeof(Bullet) * bullet_count);

        for (int i = 0; i < bullet_count; i++) {
            bullets[i].x = i * 10.0f;
            bullets[i].y = frame * 5.0f;
        }

        sink += bullets[bullet_count - 1].x;

        free(bullets);
    }

    printf("done, sink = %f\n", sink);
    return 0;
}

هنستعملhyperfine عشان نقارن الاتنين.

دي الـCompile Commands اللي هنستعملها:

gcc -O2 -std=c11 -o arena_bin arena.c

gcc -O2 -std=c11 -o malloc_bin malloc.c

والـRun Command:

hyperfine --warmup 3 ./malloc_bin ./arena_bin

دي الـResults بتاعتنا:

Benchmark 1: ./malloc_bin
  Time (mean ± σ):      19.0 ms ±   1.9 ms    [User: 18.6 ms, System: 0.5 ms]
  Range (min … max):    17.9 ms …  36.8 ms    141 runs


Benchmark 2: ./arena_bin
  Time (mean ± σ):      10.0 ms ±   0.3 ms    [User: 9.7 ms, System: 0.5 ms]
  Range (min … max):     9.5 ms …  12.0 ms    244 runs

Summary
  ./arena_bin ran
    1.90 ± 0.20 times faster than ./malloc_bin

Credits

الـArticle دي مكنتش هتبقى ممكنة من غير الـTalk العظيم دا لـRyan Fleury.

الـImplementation دي بـC++ كانت مفيدة جداً برضو.

الاعداد التخيلية حقيقية

Mon, 23 Mar 2026 00:00:00 GMT

الـMath كعلم موجودة من بداية التاريخ. من اول مالبشرية بدأت تعمل حضارة, الارقام شيء موجود ولكن مكنش كل الارقام اللي احنا عارفينها دلوقت موجودة. الاول بدأنا بالاعداد الصحيحة: $1, 2, 3, 4, 5, . . .$

الاعداد دي كانت كفاية لحد مابدأنا نواجه مشاكل في حساب النسب. في الفترة دي الاعداد الكسرية, الـFractions, اتوجدوا عشان يحلوا بعض المشاكل اللي واجهناها.

بعدها اكتشفنا ان مش كل الاعداد ممكن نكتبها ككسر, زي مثلاً $\sqrt{2}$ .الفترة دي كانت صعبة شوية, لأن كان في ثقافات بتعتبر الارقام الصحيحة مقدسة وان كل حاجة في الكون ممكن نكتبها كأعداد صحيحة و كسور.

تطور الارقام

في قصة قديمة بتحكي ان في الاغريق, كان في جماعة بيتبعوا مدرسة فلسفية ودينية اسمها الـ”فيتاغورية”. اكتشفوا حاجة صدمتهم: طول قطر اي مربع طول ضلعه 1 يساوي $\sqrt{2}$ . مينفعش يتكتب ككسر, عدد غير نسبي. اللي اكتشف دا كان اسمه “هيبياسي” والقصة بتقول ان اتباع الفيثاغورية قتلوة لما قالهم كدا (غالباً يعني غرقوه).

وده النمط اللي هنشوفه على طول في الحكاية دي: كل ما نكتشف نوع جديد من الأرقام, الناس قاومت في الأول.

بعد ذلك, الاختراع الجديد للاعداد بتاعتنا كانت الاعداد السالبة وصفر. الاعداد دي واجهت مقاومة برضو, لأنك لو جيت تفكر فيها بجد: يعني اية 5- من حاجة؟

الناس كانت بتحاول على قد ماتقدر انها متكتبش سالب في اي حاجة. فانت لو عندك مثلاً $a + b - c = 0$ كنت بتكتبها كـ $a + b = c$ .

انا عندي 5 تفاحات, مفيش حاجة في الكون سالب حاجة من حاجة.

المهم, دا السيستم الجديد للأعداد بتاعتنا. الاعداد الموجبة والسالبة والغير نسبية وصفر.

المعادلة

فضلنا كدا فترة. والرياضيين, زي ما اتعودنا, فضلوا بيحلوا معادلات أعقد وأعقد. لحد ما واحد منهم وصل لمعادلة محدتش قدر يحلها بأي أرقام موجودة, وفضل واقف قدامها مش عارف يعمل إيه. المعادلة دي كانت:

$f (x) = x 2 + 1$

دلوقت عندنا مشكلة. الـRoots او الجذور هي القيم اللي لما تحطها في المعادلة, المعادلة بتساوي صفر. في واحد زمان اثبت دا:

.Polynomials of degree $n$ have exactly $n$ roots

الاثبات دا مهم جداً لدرجة انه اتسمى النظرية الأساسية في الجبر The Fundamental Theorem of Algebra سموها كدا لأنها من أهم الحقائق اللي الجبر كله اتبنى عليها.

الاثبات دا بيقول ان المعادلة دي لازم يبقى في رقمين بيخلوا المعادلة دي تساوي صفر. لا نقاش.

بس لو بصيت على الـGraph مش هتلاقي أي نقطة بتساوي صفر. يعني الـRoots موجودين بس مش في الأرقام اللي احنا عارفينها. دي بالظبط المشكلة.

لو جينا نبص عالـFunction, مش هنلاقي اي نقطة فيها تساوي صفر.

شوف ازاي الـFunction دي مش بتلمس الـX axis خالص:

لو جينا نحل:

$x 2 + 1 = 0$

$x 2 = - 1$

$x = \pm\sqrt{-1}$

هنلاقي اعداد غريبة جداً.

الأعداد التخيلية

جزر سالب واحد؟ بل اسوء, سالب جزر سالب واحد؟ ماشي هو في حلين للمعادلة بس للأسف الحلين مش منطقيين. الارقام دي بدأت تظهر في الحلول الرياضية كتير جداً. في ناس اتعودت عليها, وناس افترضوا ان اول لما الارقام دي تطلعلهم ان مفيش حل للمعادلة اللي بيحلوها.

الارقام دي سميناها اعداد تخيلية. من اسوء الاسامي اللي على الكوكب, لأن لو قولت لحد ان دا عدد تخيلي هيفترض انه “مش موجود” او انه زي Glitch كدا انت بتستعمله وخلاص عشان تحل معادلاتك. في ناس اقترحت ان احنا نسميها “ارقام جانبية” او “عليا” لأسباب هتظهر قريب.

مادام الارقام دي عمالة تطلع في كل حتة, فيها اية لو ضيفناها للأرقام بتاعتنا؟ مش هتكون اول مرة نعدل السيستم بتاعنا. بس مينفعش نضيف اي حاجة كدا وخلاص. لو الارقام دي ينفع نستعملها فعلاً, يبقى الارقام دي لازم تخضع لقوانين الجبر اللي موجودة حالياً.

في الارقام العادية ممكن نقسم الجزر كدا

$\sqrt{2\times3} = \sqrt{2} \times \sqrt{3}$

هل ينفع للاعداد التخيلية؟

$\sqrt{-25} = \sqrt{25}\times \sqrt{-1} = 5\sqrt{-1}$

طب والجمع والطرح؟

$2 x + 3 x = 5 x$

و للتخيلية؟

$2\sqrt{-1} + 3\sqrt{-1} = 5\sqrt{-1}$

الظاهر ان الاعداد الغريبة بتاعتنا دي شغالة تمام مع كل العمليات الرياضية اللي جربناها. لكن هنكتبها ازاي؟

الناس اتفقوا على طريقة لكتابة الاعداد التخيلية. كل عدد تخيلي ممكن يتكتب كعدد حقيقي مضروب في $\sqrt{-1}$ . يبقى الرقم دا مميز جداً لدرجة ان احنا اديناله رمز: $i$ 1.

الـComplex Plane

دلوقت, احنا عايزين طريقة نضيف بيها الاعداد بتاعتنا للسيستم بحيث اننا نقدر نكتب Functions ونرسمها. هنضحى بالـY axis بتاعنا ونكتب الارقام التخيلية بتاعتنا عليه هكذا:

ده الـCoordinate System الجديد بتاعنا, الأرقام الحقيقية على المحور الأفقي والتخيلية على الرأسي:

لاحظ حاجة في السيستم بتاعنا دا.

كمثال عندك $1$ . اية اللي هيحصل لو ضربت الرقم دا في $i$ او في $\sqrt{-1}$ ؟

هيبقى $1 \times \sqrt{-1}$ يعني $\sqrt{-1}$ طب ولو ضربت $\sqrt{-1}$ في $\sqrt{-1}$ ؟ هيبقى $\sqrt{-1}^2$ يعني -1. طب لو عملت كدا تاني؟ هيبقى - $\sqrt{-1}$ لو ضربت تاني هيرجع يبقى 1.

\begin{aligned} 1 &\times \sqrt{-1} &&\;\;\;\;= \sqrt{-1} \\ \sqrt{-1} &\times \sqrt{-1} &&\:\;\;\;= -1 \\ -1 &\times \sqrt{-1} &&\;\;\;\;\;\;\;= -\sqrt{-1} \\ -\sqrt{-1} &\times \sqrt{-1} &&\,= 1 \end{aligned}

يعني

\begin{aligned} 1 &\times i &&= i \\ i &\times i &&\:\;\;\;= -1 \\ -1 &\times i &&\;\;\;= -i \\ -i &\times i &&\,= 1 \end{aligned}

او

\begin{aligned} i^1 =&\;\; i\\ i^2 =& -1\\ i^3 =& -i\\ i^4 =&\;\;1\\ i^5 =&\;\;i\\ \end{aligned}

$. . .$

والنمط دا بيتكرر للأبد.

شوف ازاي الضرب في $i$ بيلف الأرقام في دايرة كاملة:

الأعداد المركبة

دلوقت عندنا نوعين من الأرقام: حقيقية الرمز بتاع مجموعتها $\Reals$ وتخيلية الرمز بتاع مجموعتها $ℑ \Im$ . مجموعة الارقام التخيلية شكلها اجمد بكتير انا عارف. ولما بنجمعهم مع بعض بنعمل نوع تالت اسمه الأعداد المركبة $\mathbb{C}$ .

شوفنا طريقة نقدر نجمع بيها المجموعتين دول بحيث ان احنا نحط الأرقام الحقيقية على الـX axis والأرقام التخيلية على الـY axis. ولكن, ازاي ممكن نحط نقطة على الـGraph بتاعنا دا؟

الـNotation اللي كله بيستخدمه هي انك تجمع الرقمين. دا بيسهل الجبر للأرقام دي كتير.

مثلاً. لو احنا عايزين نقطة على $(2, 3)$ هنكتبها $2 + 3 i$ . المزج بين رقم حقيقي ورقم تخيلي كدا بيديك عدد مركب.

مثلاً, النقطة $2 + 3 i$ بتتحط على الـGraph كده:

العمليات على الأعداد المركبة

دلوقت بعد ما عرفنا الأعداد المركبة, خلينا نشوف ازاي بنتعامل معاها. مش هنتكلم عن الأرقام الحقيقية لوحدها, ولا التخيلية لوحدها. هنتكلم عن المركبة كاملة, يعني الاتنين مع بعض.

القاعدة الأساسية بسيطة: الحقيقي مع الحقيقي, والتخيلي مع التخيلي.

الجمع

$(2 + 3 i) + (1 + 2 i)$

$= (2 + 1) + (3 i + 2 i)$

$= 3 + 5 i$

بالظبط زي ما بتجمع أي حاجتين من نفس النوع. الأرقام الحقيقية مع بعض, والتخيلية مع بعض.

الطرح

$(5 + 4 i) - (3 + 2 i)$

$= (5 - 3) + (4 i - 2 i)$

$= 2 + 2 i$

نفس الفكرة بالظبط.

الضرب

الضرب بقى أكتر إثارة شوية. هنضرب زي ما بنضرب أي حدين جبريين بس لازم نفتكر إن $i 2 = - 1$ .

$(2 + 3 i) (1 + 2 i)$

$= 2 + 4 i + 3 i + 6 i 2$

$= 2 + 7 i + 6 (- 1)$

$= 2 + 7 i - 6$

$= - 4 + 7 i$

لاحظ إن $6 i 2$ اتحولت لـ $- 6$ يعني عدد حقيقي عادي. ده مش خطأ, ده بالظبط اللي المفروض يحصل. الأعداد التخيلية والحقيقية بتتداخل مع بعض في الضرب بطريقة منضبطة تماماً.

الفيل في الغرفة

احنا فهمنا دلوقت العمليات البسيطة على الـComplex Numbers. سؤال بقا: هي فين الـRoots اللي كنا بنتكلم عنها هنا؟ لو المعادلة بتاعتنا لازم تساوي صفر عند نقطتين, فين النقطتين دول؟

بص على الـEquation بتاعتنا:

$f (x) = x 2 + 1$

في كام Variable في الـEquation بتاعتنا دي؟ عندنا واحد $x$ اللي هو الـInput بتاعنا, وعندنا $f (x)$ اللي هو الـOutput بتاعنا. لو $x$ يساوي 2 مثلاً, يبقى $f (x)$ هيساوي $22 + 1$ يعني $5$ .

احنا لو دخلنا الـImaginary Numbers بتاعتنا, يبقى احنا كدا عندنا Variable زيادة. يبقى عدد الـVariables اللي عندنا بقا 3. اتنين منهم Input وواحد بس Output.

الـFunction بتاعتنا دلوقت هيبقى اسمها Complex Function, لأنها بتاخد عدد Complex مش Real.

عشان نفهم الفكرة, هناخد Function ابسط شوية كمثال:

f (x + i y) = x + 5

لاحظ ان الجزء الـImaginary بتاعنا دلوقت هو الـ $y$ مش الـ $x$ .

كدا احنا لو عايزين نرسم الـFunction دي هنرسمها ازاي؟ الأول هنعمل Plug-in لشوية ارقام.

\begin{aligned} f(\textcolor{#4488ff}{0} + \textcolor{#ff4444}{0i}) &= \textcolor{#4488ff}{0} + 5 = \textcolor{#44cc88}{5} \\ f(\textcolor{#4488ff}{1} + \textcolor{#ff4444}{1i}) &= \textcolor{#4488ff}{1} + 5 = \textcolor{#44cc88}{6} \\ f(\textcolor{#4488ff}{2} + \textcolor{#ff4444}{2i}) &= \textcolor{#4488ff}{2} + 5 = \textcolor{#44cc88}{7} \\ f(\textcolor{#4488ff}{3} + \textcolor{#ff4444}{3i}) &= \textcolor{#4488ff}{3} + 5 = \textcolor{#44cc88}{8} \end{aligned}

فانت زي مانت شايف, احنا عندنا 3 ارقام بتتغير, 3 Variables. لو عايزين نرسم الـFunction بتاعتنا دي, هنحتاج نرسمها كرسمة 3D, وشكلها هيبقى كدا:

xxyy

لاحظ ان الـOutput بتاعنا في الـFunction دي يعتمد بس على الجزء الحقيقي اللي هو الـ $x$ , مهما غيرت في $y$ الـOutput مش هيتغير, لأن طبيعة الـOutput بتاع الـFunction دي انها تعتمد على الجزء الحقيقي فقط, رغم انها بتاخد الجزء التخيلي كـInput.

نرجع للـFunction الأصلية بتاعتنا, اللي اتفقنا انها هتبقى $f (x + i y) = (x + i y) 2 + 1$ .

هنيجي نعمل Plug-in بنفس الشكل اللي عملناه فالـFunction القديمة, بس المرادي بأرقام Random شوية.

\begin{alignedat}{2} f(\textcolor{#4488ff}{2} + \textcolor{#ff4444}{1i}) &= (\textcolor{#4488ff}{2} + \textcolor{#ff4444}{1i})^2 + 1 &&= (\textcolor{#44cc88}{4} + \textcolor{#ffcc00}{4i}) \\ f(\textcolor{#4488ff}{1} + \textcolor{#ff4444}{3i}) &= (\textcolor{#4488ff}{1} + \textcolor{#ff4444}{3i})^2 + 1 &&= (\textcolor{#44cc88}{-7} + \textcolor{#ffcc00}{6i}) \\ f(\textcolor{#4488ff}{3} + \textcolor{#ff4444}{2i}) &= (\textcolor{#4488ff}{3} + \textcolor{#ff4444}{2i})^2 + 1 &&= (\textcolor{#44cc88}{6} + \textcolor{#ffcc00}{12i}) \\ f(\textcolor{#4488ff}{5} + \textcolor{#ff4444}{4i}) &= (\textcolor{#4488ff}{5} + \textcolor{#ff4444}{4i})^2 + 1 &&= (\textcolor{#44cc88}{10} + \textcolor{#ffcc00}{40i}) \end{alignedat}

دلوقت احنا عندنا مشكلة. الـOutput بتاعنا عبارة عن رقمين, والـInput عبارة عن رقمين برضو. يبقى دول يعتبروا كدا 4 Variables. يعني محتاجين 4 ابعاد عشان نرسم الـEquation دي. بما أننا عايشين في عالم ثلاثي الابعاد, فاحنا مش هنعرف نرسم الـOutput بتاعنا دا في رسمه واحدة.

الحل عندنا اننا “نمذج” الـOutput بتاعنا دا جوا رقم واحد بيمثل المسافة من الـOrigin.

يعني بدل مالـEquation بالـOutput بتاعها تبقى كدا:

\begin{alignedat}{2} f(\textcolor{#4488ff}{1} + \textcolor{#ff4444}{3i}) &= (\textcolor{#4488ff}{1} + \textcolor{#ff4444}{3i})^2 + 1 &&= (\textcolor{#44cc88}{-7} + \textcolor{#ffcc00}{6i}) \\ \end{alignedat}

هتبقى كدا:

\begin{aligned} f(\textcolor{#4488ff}{1} + \textcolor{#ff4444}{3i}) &= (\textcolor{#4488ff}{1} + \textcolor{#ff4444}{3i})^2 + 1 \\ &= \sqrt{\textcolor{#44cc88}{-7}^2 + \textcolor{#ffcc00}{6}^2} \\ &= \textcolor{#44cc88}{\sqrt{85}} \end{aligned}

وبكدا, الـOutput بتاعنا فيه رقم واحد بس, ويبقى عندنا 3 Variables نقدر نرسمهم.

تعديل بسيط بس, احنا عندنا Standard ان بدل مالـFunction تتكتب كدا:

$f (x + i y) = (x + i y) 2 + 1$

هنعرف $z = x + i y$ ونكتبها كدا:

$f (z) = z 2 + 1$

وبما ان الـOutput بتاع الـFunction هو الطول, هنحط الـSymbol بتاع الـMagnitude:

∣ f (z) ∣ = ∣ z 2 + 1 ∣

دا التحويل الكامل للـFunction بتاعتنا.

لاحظ دلوقتي ان الـImaginary axis بتاعنا هو الـ $y$ مش الـ $x$ زي فالمعادلة الأصلية.

لاحظ برضو ان الـEquation بتاعتنا كلها بتساوي صفر لما الجزء الحقيقي بتاعنا اللي هو $x$ يساوي صفر, والـImaginary اللي هو $y$ يساوي $i$ او $- i$ , يعني عند النقطة $0 + i$ و $0 - i$

xxyy● Roots

ساعات هتلاقي اسمه $j$ بالذات في النطاقات الهندسية, لأن $i$ محفوظة للـCurrent. ↩

ڤيكتور فيلدس

Fri, 13 Mar 2026 00:00:00 GMT

من اكتر الحاجات الجميلة في الـMathematics عامتاً والـVector Calculus خاصتاً هي الـVector Fields. الـVector Fields بتمثل حاجات كتيرة. الجاذبية, مجال كهرومغناطيسي, Neural Network.

العب شوية بالـTool اللي تحت جرب ارقام وشوف هيطلعلك اية. في Presets ممكن تختارها لو عايز الهام.

fieldstreamRunpresetsrotationsinksaddlesourcespiral outsine wavesgravitytwo vortices

أويلر

Fri, 06 Mar 2026 00:00:00 GMT

تخيل انك معاك جنية, وقولتلك هاتلي الجنية دا وهديلك بعد سنة $100\%$ من القيمة اللي انت حطيتها. يعني بعد سنة هتاخد جنية كمان.

ييبقى انت كدا بعد سنة هيبقى معاك $1 + 1$ جنية. دلوقت, لو انا قولتلك مش هديلك الـ $100\%$ على طول, هحسبلك $50 %$ بعد 6 شهور, و $50 %$ كمان بعد 6 شهور. كدا هيبقى معاك كام بعد سنة؟

بعد 6 شهور هيبقى معاك

$1 \times 1.5 = 1.5$

والـ6 شهور اللي بعدهم هيبقى

$1.5 \times 1.5 = 2.25$

طيب, لو قولتلك 3 شهور؟ يعني هتاخد $25 %$ كل 3 شهور لحد ماتكمل سنة, هيبقى كام؟

بعد 3 شهور هيبقى $1 \times 1.25$

بعد 6 شهور هيبقى $1\times 1.25 \times 1.25$

بعد 9 شهور هيبقى $1 \times 1.25 \times 1.25 \times 1.25$

بعد 12 شهر هيبقى $1\times 1.25 \times 1.25 \times 1.25 \times 1.25$

هنلاقي نمط. فالأخر العدد هيساوي $1.25 4$

نقدر نخلي $1.25$ عبارة عن $1 + 1.25$ يعني $(1 + \frac{1}{4})^4$ , وهيساوي $2.44140625$ . لاحظ ان المبلغ بتاعنا بيكبر كل لما نحسب الفايدة بتاعتنا في اوقات اكتر.

افرض قولتلك احنا عايزين نعمل نفس الحاجة دي كل شهر, او كل اسبوع, او كل يوم, لحد مانوصل لكل ثانية وفيمتوثانية, عشان نجيب اكبر سعر ممكن؟

النمط بتاعنا هيبقى $(1 + \frac{1}{n})^n$

لو فضلنا نعمل كدا للأبد وحطينا رقم كبير جداً, $(1 + \frac{1}{100000})^{100000}$ مثلاً. هنلاحظ ان العدد بتاعنا بيقرب لعدد معين. $2.71828$ .

يتضح ان العدد دا مهم جداً لدرجة ان احنا اديناله رمز معين: $e$ .

من الحاجات المثيرة للأهتمام في العدد دا انه ملوش نهاية. كأثبات لذلك, احب اقدملك عدد اويلر اللانهائي.

$e$

طرمبة الـMemory بتسرب

Sun, 10 Aug 2025 00:00:00 GMT

عشان معظم اللغات اللي بنستعملها فيها نوع من الـGarbage Collection, قليل اوي اللي بتلاقيه بيفكر فالـMemory بطريقة عملية. فيها اية يعني لو عملت new Foo()؟

عندك حق. لو بتستعمل لغة زي Java او Go, غالباً مش هتفكر فالموضوع كتير. بس, لو بتستعمل ++ C, الموضوع يختلف. اي Heap Allocation بتعملها بnew لازم تعملها Free بdelete. الموضوع بسيط, صح؟ لما اخلص حاجة, همسحها!

بالرغم من ان الموضوع بسيط سطحياً, البني ادمين بطبيعتهم خطائين. وبسبب دا, مايكروسوفت بتقول ان %70 من الـSecurity Bugs في منتجاتها بسبب Bugs ليها علاقة بالـMemory. اغلبية الـBugs دي بسبب Use After Free, يعني انك تستعمل vector معموله Allocation بـnew مثلاً بعد ماتعمله delete.

دا فحد ذاته بيثبت ان فكرة الnew و delete مش احسن حاجة, لأن حتى لما بتفتكر تعمل delete, ممكن تنسى وتستعمل الحاجة اللي انت عملتلها delete تاني بالغلط!

اللغات اللي فيها Garbage Collection مفيهاش مشاكل من النوع دا, بس انت بتدفع تمن تاني: الـGarbage Collection ذات نفسها.

ايوة غالباً مش هيبقى عندك Memory Bugs, بس الـGarbage Collection نفسها مش مجانية. الـRuntime بتاعت اللغة بتاخد وقت انها تشوف الحاجات اللي مش مستخدمة وتعملها Free!

ديسكورد حل المشكلة بتاعت الـGarbage Collection في الـServices بتاعتهم اللي بتستعمل Go بأنهم يعدلوا الـSettings بتاعت الـGarbage Collector نفسه, بس مثبتوش على قرارهم وقرروا يستعملوا لغة تانية لأن الحل مكنش احسن حاجة.

كدا احنا عندنا مشكلة. عايزين لغة سريعة كفاية بأنها تأدي احتياجاتنا, وفنفس الوقت يبقى صعب اننا نعمل Vulnerabilities بالغلط بسبب طريقتنا في استعمال الـMemory.

RAII - Resource acquisition Is Initialization

راي - Resource Acquisition Is Initialization. ممكن اسوء اسم فالعالم, بس بيشرح نفسه.

عشان نفهم اية هي راي, ونستعملها ازاي, محتاجين نتكلم بطريقة تجريدية شوية.

لو فكرنا فاللي احنا بنعمله في معظم اللغات الـObject Oriented, احنا بنعمل Variables و نعمل شوية حاجات على الـVariables دي. Functions, Methods مهما كان. بس الفكرة ان احنا منقدرش نستعمل حاجة الا لما نديلها اسم. الـvector اللي احنا بنعمله ممكن يبقى اسمه v مثلاً. هستعمل حاجة ازاي لو هي ملهاش وجود فالبرنامج نفسه؟

راي يعتبر مبني على الفكرة دي. اي “اسم” فالبرنامج هو المسؤول عن انه يحرر الـMemory اللي بيستعملها.

std::vector<int>* x = new std::vector<int>();

فالكود دا, x هو الاسم, وهو مسؤول انه يحرر الـMemory بتاعت الـvector.

طب ودا؟

int y = 42;

هنا في فرق. الفرق هنا ان x مسؤول انه يحرر حاجة محطوطة في الـHeap. اي حاجة Dynamically allocated بـnew لازم تبقى في مكان الـMemory بتاعته تقدر تفضل بعد الـScope بتاعها.

فا هنا مثلاً:

#include <vector>

void foo() {
    std::vector<int>* x = new std::vector<int>();
}

الـMemory بتاعت الـVector مش هتتحرر بعد مالـFunction Call تخلص, لأنك بتستعمل new.

بس هنا:

void foo() {
    int y = 42;
}

24 دا موجود على الـStack. مش Dynamically Allocated, مستعملناش new, فالـMemory بتاعته هتتحرر لما الـFunction Call تخلص.

راي بتستعمل الفكرة دي للحاجات الـHeap Allocated.

اول لما اسم الـScope بتاعه يخلص, يعني مثلاً الـFunction Call اللي هو فيها تخلص, هو من مسؤوليته انه يحرر الـMemory بتاعت الـResource اللي هو ماسكه.

تمام زي الفل, نستعمل راي ازاي في++ C؟ الـStandard Library بتتيحلنا الامكانية دي في <memory>. الـType الاساسي اللي ممكن تستعمله هو unique_ptr. اسمه ممكن يكون مريب شوية زي RAII, بس هو فعلاً شارح هو بيعمل اية. هو Pointer ايوة, بس Unique…مميز. في حيث انه هو الشخص الوحيد المسؤول انه يحرر الـResource بتاعه.

كمثال:

#include <iostream>
#include <vector>
#include <memory>

int main() {
    std::unique_ptr<std::vector<int>> vec = std::make_unique<std::vector<int>>(5);
    // الميموري بتخلص هنا.
    return 0;
}

ملاحظ ان مفيش ولا كلمة new فالكود؟ ولكن فعلاً الـvectorدا Dynamically Allocated.

عايز دليل؟ بص عالـAssembly.

main:
        push    rbp
        mov     rbp, rsp
        push    rbx
        sub     rsp, 24
        mov     DWORD PTR [rbp-20], 5
        lea     rax, [rbp-32]
        lea     rdx, [rbp-20]
        mov     rsi, rdx
        mov     rdi, rax
        call    std::__detail::_MakeUniq<std::vector<int, std::allocator<int>>>::__single_object std::make_unique<std::vector<int, std::allocator<int>>, int>(int&&) 
        mov     ebx, 0
        lea     rax, [rbp-32]
        mov     rdi, rax
        call    std::unique_ptr<std::vector<int, std::allocator<int>>, std::default_delete<std::vector<int, std::allocator<int>>>>::~unique_ptr() [complete object destructor] 
        mov     eax, ebx
        mov     rbx, QWORD PTR [rbp-8]
        leave
        ret
.LC0:
        .string "cannot create std::vector larger than max_size()"

هتلاحظ ان السطر التاني بيستعمل حاجة اسمها std::default_delete. لو بصينا على الـDocumentation هنلاقيها بتقول دا:

The non-specialized default_delete uses delete to deallocate memory for a single object

معنى ان الـType دا بيستعمل delete ان الـResource دا Dynamically Allocated!

هنا كنا بنستعمل راي في اننا نستعمل Dynamic Memory على الـHeap. بس, راي ممكن تستعملها بطريقة عامة اكتر. ملف مثلاً استعملته وعايز تقفله لما متكونش محتاجة.

الناهية

الهدف من البوست دا انه يظهر فكرة RAII اكتر, بس في حاجات كتير متكلمتش عنها. افرض انا عايز كذا حد يملك Resource واحد و محتاج الـResource دا استعمله في اماكن كتير؟

في الحالة دي هتستعمل shared_ptr. الـType دا بيستعمل Technique اسمه Reference Counting. الـTechnique دا بطيء نسبياً, فاخد بالك!

Fun Fact: كل Object انت بتعملها في Python هتلاقيها By default بتستعمل Reference Counting عشان تحدد الـMemory بتاعت الـObject دي تتحرر امتى!

هيللو وورلد!

Sat, 09 Aug 2025 00:00:00 GMT

إن كانت المطرقة هي كل ما بيدك, فسترى كل الأشياء مسامير

دا غالباً هيبقى اول بوست فالبلوج دي.

معظم الناس لو طلبت منهم يعملوا موقع بسيط, هيقربوا ببطء لReact1 , Angular, Vue, او الخمسوميت فريم وورك اللي موجودين حالياً.

بصراحة, اول لما جيت افكر اعمل البلوج دي اتجهت للحاجة اللي انا اعرفها, React. بس, بعدها بدأت افكر شوية وافتكرت اني كنت قريت عن استرو وانه يعتبر مخصص للStatic Sites, حاجات مش محتاجة Interactivity كتير.

قبل مابدأ, انا كنت محتاج حاجات معينة:

محتاج ان الموقع يكون سريع. انا حرفياً مش بعمل حاجة مذهلة لأنه يكون بطيء, هو كل اللي بتشوفه HTML و CSS مش اكتر.
محتاج ان كتابة البوستس تكون سهلة. لو كتابة البوستس صعبة, مش هيبقى عندي شغف اني اكتب.
محتاج اني اعملة بسرعة. مش عايز ابدأ من الصفر, ولكن عايز انجز يعني!

انا مش هشرح استرو نفسه, لو عايز تتعلم اكتر عنه الdocumentation هتشرح احسن مني بكتير. بس, انا هشرح ازاي استرو حل المشاكل اللي اتكلمت عليها فوق.

سريع

لو بتعمل Static Site, فانت غالباً مش محتاج JavaScript. او بمعنى اصح, الـClient مش محتاج JavaScript.

استرو سريع عشان هو By default مش بيبعت اي JavaScript للClient. ولكن, استرو بيشتغل كCompiler. بتكتب كل كل ما تريد في ملفات .astro, وفالاخر دا بيتحول لملف HTML صغير يتبعت للـClient.

كمثال, بص عالكود دا, دا الكود اللي بيجيب كل البوستس في صفحة tags/. هي فاضية دلوقت, بس هتتملي (اتمنى).

---
import BaseLayout from "$lib/layouts/base_layout.astro";
import { getCollection } from "astro:content";

const pages = await getCollection("posts");

const tagMap = new Map();

for (const page of pages) {
    for (const tag of page.data.tags) {
        if (!tagMap.has(tag)) {
            tagMap.set(tag, []);
        }
        tagMap.get(tag).push(page);
    }
}

const uniqueTags = [...tagMap.keys()];
---

<BaseLayout>
    <h1>تاجژ</h1>
    {
        uniqueTags.map((tag) => (
            <div>
                <h2 id={tag}>
                    <span>#{tag}</span>
                </h2>
                <ul>
                    {tagMap.get(tag).map((post) => (
                        <li>
                            <a
                                href={`/${post.data.pubDate.toISOString().substring(0, 10)}/${post.id}`}
                            >
                                <span>
                                    {post.data.pubDate
                                        .toISOString()
                                        .substring(0, 10)}
                                </span>
                                <span>-</span>
                                <span>{post.data.title}</span>
                            </a>
                        </li>
                    ))}
                </ul>
            </div>
        ))
    }
</BaseLayout>

اية دا؟ انت بتضحك عليا؟! دي JavaScript اهي! واية دا كمان؟ 2 for loop جوا بعض!

دي $O(n \times t)$ !2 ازاي ممكن يكون سريع؟

عندك حق… دا مش اكتر حاجة Efficient…لو دا بيتعمل At runtime. الفكرة ان استرو بيشوف الكود دا, وبيحول كل حاجة لStatic HTML. مالاخر, بيعمل Compile للJavaScript اللي بتكتبه, وبيحوله لHTML & CSS. بالطريقة دي, استرو بيحفظ الـDX بأنه يسيبك تكتب لغة للScripting, وفنفس الوقت مبيعاقبش الـClient بأنه يبعتله حاجات هو مش محتاجها!

دا بيواجه الفكرة بتاعت الـFrontend Frameworks المشهورة, صفحة واحدة HTML وJavaScript تغير الـHTML بطريقة Dynamic (دي ال Single-Page Applications)

مش مصدقني؟ ادخل عالـNetwork Tab في الـChrome Devtools. مفيش ولا JavaScript Resource.

كتابة بوستس سهلة

من اكتر اللغات السهلة اللي ممكن تتعملها في ساعة حرفياً هي Markdown. وهي برضو من اكتر اللغات اللي الناس متعرفهاش, مش عارف لية. تحس ان البني ادمين كلهم قرروا يكتبوا الـReadMe بتاعتهم بالـAI.

غالباً, الكونتنت بتاعتك هتكتبها بMarkdown في استرو, والـMarkdown دا هيتحول لHTML فالاخر عشان الـBrowser بتاعك يقدر يقراه.

لية مكتبش بHTML على طول؟ انت ممكن تعمل كدا عادي, بس انت يعتبر بتعاقب نفسك. لو خيروك, هتحب تكتب دا:

<!doctype html>
<html lang="en">
    <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1" />
        <title></title>
    </head>
    <body>
        <h1>Hello, World!</h1>
    </body>
</html>

ولا دا؟

# Hello, World!

DX سريعة

انا شخص مبحبش اعمل UI. بالنسبالي اكتر جزء مضجر في كتابة اي Software. فابستعمل ادوات بتسهللي الموضوع لو جاتلي الفرصة, اولهم غالباً هي Tailwind.

تاني حاجة ممكن استعملها هي اي Component Library بتستعمل Tailwind. لو كنت بستعمل React او Next, كنت غالباً هختار ShadCn , بس انا كان عندي نظره لشكل الـBlog هيبقى عامل ازاي, وللأسف ملقتش حاجة بنفس الشكل اللي انا عايزه ومبتستعملش JavaScript, فاضطريت اكتب الـComponents بتاعتي بايدي (رعب).

الموضوع مكنش صعب اوي, عشان استرو برضو بيتيحلك انك تعمل الـComponents بتاعتك. اي ملف astro. يعتبر Component من وجهه نظر استرو.

دا مثلاً:

---
const { post } = Astro.props;
---

<div class="w-full">
    <div
        class="flex flex-wrap gap-x-3 divide-dotted text-xl text-wrap opacity-70"
    >
        <span class="text-wrap">
            {post.data.pubDate.toISOString().substring(0, 10)}
        </span>
        {
            post.data.tags.map((t) => (
                <>
                    <span> • </span>

                    <a href={`/tags#${t}`}>
                        <span>#{t}</span>
                    </a>
                </>
            ))
        }
    </div>
    <h1 class="mb-0">
        <a
            href={`/${post.data.pubDate.toISOString().substring(0, 10)}/${post.id}`}
        >
            {post.data.title}
        </a>
    </h1>
    <span class="italic">{post.data.subtitle}</span>
</div>

دا الكود اللي بيظهر الـTitle - Subtitle - Date - Tags بتاعت كل بوست. الـComponent بياخد Prop من النوع Post و بيRender دا على حسب كل بوست.

ممكن تستعمله كدا:

---
import { getCollection } from "astro:content";
import PostHeader from "./post-header.astro";
const allPosts = await getCollection("posts");
---

<div class="flex h-full w-full flex-col gap-y-12">
    {
        allPosts
            .sort((a, b) => b.data.pubDate.getTime() - a.data.pubDate.getTime())
            .map((post) => (
                <div class="flex flex-col">{<PostHeader post={post} />}</div>
            ))
    }
</div>

بتستعمله زي اي Component استعملته في حياتك (غالباً).

الناهية

استرو مش الـStatic Site Generator الوحيد, في Jekyll, 11ty, Hugo و غيرهم. طبعاً انا مستعملتهمش كلهم, ووارد جداً احب SSG غير استرو, ولكن صعب اتخيل DX اسهل من استرو.

اتمنى اني اكون شجعتك انك تستعمل استرو في مشروع ما, ولو استعملته بسبب البوست دا ابعتلي لينك!

رياكت Library مش Framework…عارف…عارف. ↩
حلو شكل الـO صح؟ دي Plugins استرو بيدعمها: remark-math و rehype-katex. استرو برضو بيدعم Syntax Highlighting في الكود ب Shiki و Prism. ↩

بلوج شناوي

لية نيو ڤيم في عصر الاجينتس؟

Introduction

How Neovim and I met

What is Neovim

Practical Examples

Any Agent Could Do This…

Conclusion

ادخل الحلبة

Stack Based Allocations

Heap Based Allocations

Manual Memory Management: Problems

300,000 Rats

Lifetimes

The Arena Allocator

The Arena Struct

Arena Allocation

CPU Alignment

Arena Allocation: Continued

Reset & Free

Arena Usage

الـBenchmark: Arena vs malloc

Credits

الاعداد التخيلية حقيقية

تطور الارقام

المعادلة

الأعداد التخيلية

الـComplex Plane

الأعداد المركبة

العمليات على الأعداد المركبة

الجمع

الطرح

الضرب

الفيل في الغرفة

Footnotes

ڤيكتور فيلدس

أويلر

ee

طرمبة الـMemory بتسرب

RAII - Resource acquisition Is Initialization

الناهية

هيللو وورلد!

سريع

كتابة بوستس سهلة

DX سريعة

الناهية

Footnotes

$e$