الخلاصة

  • عرض LAP6 المخطوطة الطويلة كلفافة متحركة؛ يضيف المستخدم سطراً أو يحذفه عند الموضع الحالي، ثم يرى التغيير مدمجاً في النص فوراً.
  • كان حفظ المخطوطة يحدّث مُدخلاً مسمى على LINCtape، أما التحويل والتحميل والتشغيل والتحقق من التجربة فبقيت عمليات لاحقة ومستقلة.
  • كتبت Wilkes نظام LAP6، لكن السجل الموثق ينسب أيضاً تقنية التحرير المعتمدة على معالجة الشريط إلى Mishell J. Stucki وSevero M. Ornstein، وسياق LINC إلى Wesley Clark وفريقه، وجزءاً من المتطلبات والاختبار إلى المستخدمين وزملاء Washington University.

يظهر سطر من الشفرة على شاشة LINC. تنتقل المشغلة إليه، تحذفه، ثم تكتب بديلاً. تتقارب السطور التالية وتتغير أرقامها، وتصبح المراجعة مرئية في سياقها. على آلة لا تملك سوى 2,048 كلمة من 12 بت، لم تكن هذه زينة لواجهة الاستخدام؛ بل كانت مركز بيئة تطوير كاملة.

في بحثها الصادر عام 1970، “Conversational Access to a 2048-Word Machine”، وصفت Mary Allen Wilkes نظام LAP6 بوصفه بيئة مباشرة لتحرير النصوص والحفظ الآلي وصيانة الملفات وإعداد البرامج وتجميعها. وكان الإنجاز في وصل هذه الأنشطة من دون الادعاء بأنها تمثل الواقعة نفسها أو تقدم الدرجة نفسها من الإثبات.

كانت المخطوطة كيان عمل مرئياً

يمكن أن تكون مخطوطة LAP6 أي مجموعة مفيدة من محارف لوحة المفاتيح. كانت الشفرة المصدرية الاستخدام المعتاد، لكن النظام لم يفرض تنسيقاً خاصاً بها. احتوت اللفافة القياسية 45 كتلة شريط، أي 23,040 محرفاً، بينما لم يحتج النظام إلى معالجة أكثر من جزء صغير منها في الذاكرة في اللحظة الواحدة.

كانت المخطوطة تتحرك إلى الأمام مع الكتابة. يتحكم مقبض مقاومة متغيرة في عدد السطور الظاهرة. وكانت أرقام السطور علامات نسبية للموقع، يعاد ترتيبها بعد كل تغيير. يسمح رقم السطر بالانتقال لمسافة كبيرة، ثم تنقل مفاتيح قريبة اللفافة إطاراً أو سطراً في الاتجاهين. ولم يحتج التحرير إلى لغة أوامر منفصلة: يُضاف السطر أو يُحذف عند النقطة الحالية، وتدمج الشاشة أثر التغيير.

يشرح بحث Wilkes المستقل عن التحرير بالتمرير الآلية الداخلية. ظل النص سلسلة متصلة في عناوين ثابتة على الشريط. واستوعبت مساحة عمل من 512 محرفاً عند نقطة القطع الإضافات والحذف، ثم أعيد وصل المادة بالنص عند تحريك اللفافة. عالجت الخوارزمية النص نفسه بدلاً من تجميع قائمة خفية من التعديلات تنتظر التسوية لاحقاً.

إذن كان العرض المرئي يثبت حقيقة محددة: تغيّرت المخطوطة الحالية. لكنه لم يثبت أن نسخة مسماة أخرى على الشريط تغيّرت، ولا أن النص الجديد قابل للتجميع، ولا أن البرنامج الناتج سيعمل كما هو مقصود.

أنشأ الحفظ حالة جديدة وحداً جديداً للفشل

أدار فهرس من كتلتين ملفات LAP6. كان المُدخل إما مخطوطة أو برنامجاً ثنائياً؛ وهما نوعان مختلفان قد يحملان الاسم نفسه من دون أن يكونا الشيء نفسه. نقل أمر الحفظ المخطوطة الحالية، أو نطاقاً محدداً منها، إلى مُدخل. ونسخت أوامر أخرى المخطوطات أو الملفات الثنائية أو جميع المدخلات غير المكررة بين شريطين.

اختار LAP6 كتلًا حرة متجاورة قرب الفهرس. ولم يكن الاستبدال ملزماً بإعادة استخدام الموقع المادي القديم. إذا كان الاسم موجوداً، ظهرت العبارة REPLACE? وطُلب مفتاح قرار. حمت هذه الخطوة اسماً من الاستبدال غير المقصود، لكنها لم تكن شهادة بأن العملية ذرّية لا تتجزأ.

يوضح LAP6 Handbook هذا الحد بصراحة. بعد تحديث الفهرس، لا يعود إيقاف العملية قادراً على إلغاء الحفظ. والأهم أن LAP6 يكتب الفهرس قبل مُدخل الملف المقابل. وقد يترك عطل في الشريط بين الخطوتين فهرساً يصف مُدخلاً غير موجود. ولم تكن للفهرس نسخة احتياطية.

أثبت الحفظ الناجح شيئاً أقوى من تعديل الشاشة: لقد تصرف LAP6 في مُدخل مسمى. ومع ذلك، بقيت الموثوقية رهينة اتساق الشريط والفهرس والبيانات الفعلية. ووجود إجراءات الاسترداد في الدليل دليل على أن هذا الاتساق كان قابلاً للفشل.

لم يكن التجميع والتشغيل مرادفين للحفظ

بالنسبة إلى برامج المصدر، حوّل CONVERT المخطوطة الحالية إلى صيغة ثنائية. استطاع LAP6 عرض أخطاء تعريف الرموز مع أرقام سطور المخطوطة، ونطاق مواقع الذاكرة المطلوب، وجدول إسناد الرموز. وإذا ظهرت أخطاء، عاد المستخدم إلى المخطوطة وصححها ثم أعاد التحويل.

كان LOAD عملية أخرى. فهو ينقل البرنامج الثنائي الحالي أو المحفوظ إلى الذاكرة ويبدأه وفق الآلية الموثقة. وكان إبقاء شريط LAP6 مركباً يسهل العودة إلى المخطوطة وجدول الرموز والتصحيح وإعادة التجميع. اختصر ذلك الحاجة إلى ترقيع الثنائي، لكنه لم يحول تعديل المصدر إلى نتيجة تشغيل.

بقي تسلسل الأدلة واضحاً: تثبت الشاشة حالة المصدر؛ ويسجل الحفظ مُدخلاً مسمى؛ وينتج التحويل ملفاً ثنائياً وتشخيصات؛ ويضع التحميل ملفاً ثنائياً بعينه في الذاكرة؛ ويراقب الاختبار سلوكه. وبعد ذلك كله، لا بد من بروتوكول مستقل لإثبات أن الجهاز المتصل والتجربة قد أنتجا نتيجة صالحة.

حدود الإسهام مهمة أيضاً

وفق التاريخ الشفهي المحفوظ في Computer History Museum، كتبت Wilkes معظم LAP6 خلال عام 1965 على جهاز LINC موضوع في غرفة المعيشة بمنزل والديها في Baltimore. وقالت إنها بنت النظام إلى حد بعيد من البداية، مع إعادة استخدام بعض الإجراءات السابقة حين أفادتها، ثم أرسلت نسخة LAP5 إلى St. Louis للاستخدام عدة أشهر قبل الإصدار العام.

هذه شهادة قوية على التأليف، لكنها لا تمحو الفريق المحيط. قاد Wesley Clark مشروع LINC وشارك Wilkes في تأليف “Programming the LINC”. وينسب الدليل صراحة إلى Mishell J. Stucki وSevero M. Ornstein تقنية معالجة الشريط المستخدمة في مرفق التحرير. كما اختبر زملاء Washington University النسخ السابقة للإصدار، وأسهمت زيارات مختبرات LINC في صياغة المتطلبات. ووفر MIT Lincoln Laboratory البيئة الأسبق التي نشأ فيها LINC ومحاكيه.

تخلط بعض الروايات الثانوية الأسماء كما تخلط الأدوار. تحدد المصادر الأولية التي راجعناها Mishell J. Stucki وSevero M. Ornstein، ولا تثبت إسهامات مستقلة في LAP6 لشخصين باسم “Philip Mishell” أو “Ted Severo”. تحافظ الكتابة التاريخية المسؤولة على هذا الالتباس بدلاً من اختلاق هوية أو نقل فضل من شخص إلى آخر.

المصادر