डिजिटल मानविकी |

persNamer 1.2: एक VIAF नंबर, नौ प्रामाणिक नाम-सूचियाँ

Mon, 07 Sep 2026 00:00:00 +0000

शुरू में एक छोटी-सी सुविधा भर था: VIAF नंबर दीजिए, TEI की एक <person> प्रविष्टि पाइए, साथ में पाठ में लगाने के लिए <persName> टैग। बस इतना ही — और जो प्रविष्टि बनती थी वह भी दुबली-पतली: एक नाम, दो तिथियाँ, एक पहचानकर्ता। आज जारी हुआ संस्करण 1.2 अब भी वही एक काम करता है, पर इस बार जो प्रविष्टि निकलती है वह सँभालकर रखने लायक है।

व्यक्ति-प्रविष्टि में अब क्या-क्या है

पहले नाम की बात। VIAF के क्लस्टर में हर सहयोगी पुस्तकालय अपना-अपना नाम-रूप लेकर आता है, और पुराना persNamer जो लेबल पहले हाथ लगे वही उठा लेता था। उससे वोल्तेयर (Voltaire) के बारे में पूछिए तो जवाब मिलता « فولتير، » — यानी नाम का अरबी रूप, और वह भी पीछे लटके अल्पविराम सहित — ऊपर से एक खाली xml:id मुफ़्त में। अब औज़ार पूरे क्लस्टर में नाम-रूपों की गिनती करके वही रखता है जिस पर स्रोत रिकॉर्ड एकमत हों; बाक़ी रूप <persName type="variant"> बनकर पीछे-पीछे आते हैं, जो सबसे प्रचलित हो वह सबसे आगे। तिथियाँ मानकीकृत होकर (1572-08-00 से 1572-08) दो बार दर्ज होती हैं — एक बार पाठ के रूप में, एक बार @when विशेषता में — और तिथियाँ समझने वाली कोई भी प्रोसेसिंग असल में इसी दूसरी को पढ़ती है। लिंग और विवरण भी आते हैं, जहाँ VIAF उन्हें देता है।

और अब वह हिस्सा जिसका मुझे सबसे ज़्यादा इंतज़ार था। VIAF जिस-जिस पहचानकर्ता को इस व्यक्ति से जोड़ता है — चाहे schema:sameAs के ज़रिए, चाहे अपने स्रोत-आईडी के ज़रिए — वह सब अब अलग-अलग <idno> में दर्ज हो जाता है: BnF, GND, लाइब्रेरी ऑफ़ कांग्रेस, SUDOC, Wikidata, ISNI, BNE, LIBRIS, NDL। एक नंबर अंदर गया, नौ कैटलॉग बाहर आए। किसी व्यक्ति-सूची (personography) के लिए नामों की कोरी फ़ेहरिस्त और प्रामाणिक डेटा के जाल की एक गाँठ में जो फ़र्क़ है, वह यही है।

<person xml:id="pers-teligny-c">
 <persName>Charles de Téligny</persName>
 <birth when="1535">1535</birth>
 <death when="1572-08-24">1572-08-24</death>
 <sex value="M">M</sex>
 <idno type="VIAF">314802260</idno>
 <idno type="BNF">16133360</idno>
 <idno type="Wikidata">Q1868249</idno>
 <idno type="ISNI">0000000071126808</idno>
</person>

टुकड़ों से व्यक्ति-सूची तक

एक आदमी के लिए टर्मिनल पर XML छाप लेना ठीक है; पर एक संपादित ग्रंथ में तो सैकड़ों लोग होते हैं। इसलिए persNamer अब एक साथ कई VIAF नंबर लेता है, दो अनुरोधों के बीच VIAF को साँस लेने की मोहलत देता है, जो कुछ लाया है उसे कैश में रख लेता है ताकि दोबारा न माँगना पड़े, और --merge मिलते ही नई प्रविष्टियाँ सीधे मौजूदा TEI फ़ाइल के <listPerson> में बिठा देता है। जो लोग फ़ाइल में पहले से हैं, वे अपने VIAF नंबर से पहचान लिए जाते हैं और उनका xml:id ज्यों का त्यों रहता है; नए आईडी फ़ाइल से मिलाए जाते हैं और कहीं टकराव हो तो पीछे प्रत्यय (-2, -3) लग जाता है; अंत में पूरी फ़ाइल के इंडेंट फिर से सँवार दिए जाते हैं — हाँ, उससे पहले एक .bak प्रति अलग रख ली जाती है।

persnamer --merge edition.xml 314802260 36925746

एक बदलाव ज़रूर ध्यान में रखिए: कुलनाम से पहले आने वाला कण (particle) अब डिफ़ॉल्ट रूप से आईडी में नहीं रहता, इसलिए Charles de Téligny पहले के pers-deteligny-c की जगह अब pers-teligny-c हो गया है। आपकी परियोजना पुराने रूप की आदी हो चुकी हो तो --keep-particle उसे वापस ले आता है; और नामों के भरोसे रहना ही न हो तो --id-format viaf से pers-viaf-314802260 मिल जाता है।

साफ़-सफ़ाई

स्क्रिप्ट अब बाक़ायदा एक पैकेज बन गई है, अपनी persnamer कमांड के साथ: uv tool install या pipx से एक लाइन में इंस्टॉल कीजिए, या बिना इंस्टॉल किए बस एक बार आज़माना हो तो uvx से चला लीजिए। छब्बीस टेस्ट VIAF की रिकॉर्ड की हुई प्रतिक्रियाओं पर चलते हैं, इसलिए टेस्ट-सूट को नेटवर्क की कोई ज़रूरत नहीं; CI उन्हीं को Python 3.9 से 3.13 तक दोहराता है, और आउटपुट TEI P5 के मुताबिक़ जाँचा जाता है। लाइसेंस पहले की तरह Apache 2.0 ही है।

जो यह अब भी नहीं बता सकता, वह है कि कोई कहाँ पैदा हुआ और रोज़ी-रोटी के लिए क्या करता था: VIAF के क्लस्टर RDF में न जगहें हैं, न पेशे। पर जिन BnF और GND रिकॉर्डों से यह जुड़ा है, उनमें दोनों हैं — और उनके नंबर अब आपके हाथ में हैं।

कोड और दस्तावेज़ पर।

tei-mcp v0.3: स्रोत को दोबारा लिखे बिना TEI एनकोडिंग

Tue, 05 May 2026 00:00:00 +0000

जब मैंने , तो मक़सद था एआई असिस्टेंटों को TEI मार्कअप गढ़ने से रोकना। स्कीमा-आधार ने समस्या का एक हिस्सा सुलझा दिया: P5 विनिर्देश तक सीधी, उपकरण-आधारित पहुँच मिल जाने पर मॉडल को अब यह अनुमान नहीं लगाना पड़ता कि किसी एलिमेंट का मतलब क्या है या वह कौन-से एट्रिब्यूट स्वीकार करता है। आउटपुट वैध निकलता है।

लेकिन TEI एनकोडिंग में मतिभ्रम के दो चेहरे हैं, और स्कीमा उनमें से सिर्फ़ एक को पकड़ती है। विनिर्देश पर परखने से इतना पता चलता है कि मार्कअप सही बना है। उस पाठ के बारे में यह कुछ नहीं कहती, जिसे वह मार्कअप लपेटे हुए है। और यहीं – पाठ में ही – ज़्यादा घातक मतिभ्रम बसते हैं। v0.3 की प्रमुख सुविधा, स्पैन-लॉक्ड कंपोज़िशन, ख़ास तौर पर इन्हीं को रोकने के लिए बनाई गई है।

सामग्री तालिका

वह मतिभ्रम जिसे स्कीमा नहीं पकड़ सकती

किसी मॉडल से सोलहवीं सदी का एक फ़्रांसीसी पत्र एनकोड करने को कहिए, और अक्सर आपको एक ऐसा TEI दस्तावेज़ मिलेगा जो देखने में बेदाग़ लगेगा। हेडर भरा हुआ है, <persName> टैग सही जगह पर हैं, <dateline> ठीक बना है। उसे validate_document से गुज़ारिए, और वह पास हो जाता है।

फिर उसके मूल पाठ का स्रोत से मिलान कीजिए।

mesme बनकर même हो गया है। एक अल्पविराम अपनी जगह से खिसक गया है। luy चुपचाप आधुनिक होकर lui बन गया है। पांडुलिपि में जो वाक्यांश पढ़ने में कठिन था, उसे “सुधारकर” कुछ ज़्यादा साफ़-सुथरा बना दिया गया है। इनमें से कोई बदलाव माँगा नहीं गया था। कोई चिह्नित नहीं है। दस्तावेज़ स्कीमा के हिसाब से वैध है, और चुपचाप ग़लत।

अभिलेखीय वर्कफ़्लो में – जहाँ एनकोड किया गया पाठ वह स्थायी अभिलेख बन जाता है जिस पर आगे के पाठक, खोज-अनुक्रमणिकाएँ और उद्धरण टिके होते हैं – यही वह विफलता है जो सबसे ज़्यादा मायने रखती है। एक बिगड़ा हुआ टैग खीज पैदा करता है। एक आधुनिक की गई वर्तनी, जिस पर पाँच साल तक किसी की नज़र न पड़े, पाठ का भ्रष्ट हो जाना है।

स्पैन-लॉक्ड कंपोज़िशन

नया रिलीज़ (v0.3) मतिभ्रम रोकने की एक ऐसी व्यवस्था लेकर आया है, जिसका निशाना ठीक यही विफलता है। डिज़ाइन का लक्ष्य: मूल पाठ के मतिभ्रम को केवल असंभाव्य नहीं, बल्कि बनावट से ही असंभव बना देना।

विचार सीधा-सा है: मॉडल मूल पाठ कभी टाइप नहीं करता।

इसके बजाय वर्कफ़्लो यों चलता है:

मॉडल get_source("letter_001") बुलाता है और उसे स्रोत का सादा पाठ एक अपरिवर्तनीय स्ट्रिंग के रूप में मिलता है।
जो भी टैग वह लगाना चाहता है, उसके लिए वह tag_span("letter_001", start, end, element_path, attrs) बुलाता है – यानी स्रोत की एक वर्ण-सीमा पर एक TEI एलिमेंट दर्ज करता है।
काम पूरा होने पर वह compose("letter_001") बुलाता है। सर्वर दर्ज किए गए टैगों को मूल सादे पाठ में पिरोता है, अंतिम TEI तैयार करता है, और फिर बाइट-दर-बाइट जाँचता है कि तैयार दस्तावेज़ का सपाट पाठ स्रोत के बराबर है या नहीं।

बाइट मिल गए, तो दस्तावेज़ लौट आता है। नहीं मिले – अगर मॉडल के टैगों से किसी तरह ऐसा मूल पाठ निकलता है जो स्रोत से एक भी वर्ण में भिन्न हो – तो compose() भ्रष्ट दस्तावेज़ लौटाने के बजाय त्रुटि उठा देता है।

इस वर्कफ़्लो में कोई ऐसा रास्ता नहीं जिससे मॉडल एक ऐसा TEI दस्तावेज़ बना सके जिसका मूल पाठ स्रोत से भिन्न हो। यह अपरिवर्तनीय शर्त यांत्रिक है, व्यवहार पर टिकी नहीं। आपको यह भरोसा नहीं करना कि मॉडल मतिभ्रम नहीं करेगा; आपको बस दो बाइट-स्ट्रिंगों के बीच एक == जाँच पर भरोसा करना है।

यह क्या है, और क्या नहीं

स्पैन-लॉक्ड कंपोज़िशन स्कीमा-आधार की पूरक है, उसका विकल्प नहीं। स्कीमा-आधार के उपकरण (validate_document, lookup_element, valid_children और मूल सोलह में से बाक़ी) मॉडल को वैध TEI बनाने में मदद करते हैं। स्पैन-लॉक्ड कंपोज़िशन इसकी गारंटी देती है कि उस TEI के भीतर का मूल पाठ स्रोत के प्रति वफ़ादार है। काम में लाने लायक़ एनकोडिंग वर्कफ़्लो को दोनों कसौटियों पर खरा उतरना होता है, और अब दोनों एक ही सर्वर से सधती हैं।

यह हर मर्ज़ की दवा भी नहीं है। compose() अभी यह नहीं जाँचता कि दर्ज किए गए टैग किसी लोड किए गए ODD अनुकूलन के अनुसार स्वीकार्य हैं या नहीं – यह अगला क़दम है। दर्ज किए गए टैग प्रोसेस की मेमोरी में रहते हैं और रीस्टार्ट के बाद नहीं बचते। और स्रोत फ़ाइलें वहाँ से पढ़ने योग्य होनी चाहिए जहाँ सर्वर चल रहा है। ये सब सुलझाए जा सकते हैं; इनमें से कोई भी मूल अपरिवर्तनीय शर्त को कमज़ोर नहीं करता।

TEI से आगे यह क्यों मायने रखता है

यह पैटर्न सामान्यीकृत होता है। जब भी किसी मॉडल से किसी पाठ पर टिप्पणी करने, उसे रूपांतरित करने या लपेटने को कहा जाए – और जब भी मूल पाठ की अखंडता मॉडल की “सुधारने” की क्षमता से ज़्यादा मायने रखे – तो इसी आकार का समाधान लागू होता है। मॉडल से पाठ दोबारा टाइप करने को मत कहिए। उससे पाठ पर निर्देश बनवाइए, और एक नियतात्मक कंपोज़र को समानता की अपरिवर्तनीय शर्त के तहत उन्हें लागू करने दीजिए।

ख़ास तौर पर डिजिटल संस्करणों के लिए इससे यह बदल जाता है कि आप ज़िम्मेदारी के साथ किसी मॉडल से क्या करवा सकते हैं। एनकोडिंग अचानक ऐसा काम बन जाती है जिसे आप हर आउटपुट का स्रोत से हाथ से मिलान किए बिना सौंप सकते हैं। मशीन उबाऊ रास्ता चलती है; संपादक मार्कअप की समीक्षा करता है, वर्तनी की नहीं।

अपडेट कैसे पाएँ

अगर tei-mcp पहले से इंस्टॉल है:

uvx tei-mcp@latest

या नए सिरे से:

pip install tei-mcp

स्पैन-लॉक्ड कंपोज़िशन इस्तेमाल करने के लिए सर्वर को स्रोत की सादा-पाठ फ़ाइलों की किसी डायरेक्टरी की ओर मोड़िए:

export TEI_MCP_SPAN_SOURCE_ROOT=/path/to/sources
uvx tei-mcp

हर फ़ाइल का मूल नाम उसका दस्तावेज़ ID बन जाता है (letter_001.txt → letter_001)।

स्रोत कोड, पूरा दस्तावेज़ीकरण और अपरिवर्तनीय शर्त के डिज़ाइन-नोट:

एक अलग ढंग का डिजिटल संस्करण

Tue, 24 Mar 2026 00:00:00 +0000

ज़्यादातर प्राथमिक स्रोत कभी प्रकाशित नहीं होते। इसका इलाज जिस मॉडल से करने की हम कोशिश करते हैं – अनुदान पर टिके डिजिटल संस्करण – वह इतना महँगा, इतना केंद्रीकृत और इतना नाज़ुक है कि बड़े पैमाने पर चल ही नहीं सकता। मैंने अभी-अभी प्रकाशित की है, जिसमें बताया है कि मैं कावरियाना के पत्रों का आलोचनात्मक संस्करण अलग ढंग से क्यों बना रहा हूँ: डिजिटल रूप में प्राथमिक स्रोत, जो अपने-आप, धीरे-धीरे बढ़ते हैं – न्यूनतम इन्फ़्रास्ट्रक्चर के साथ, स्वचालित रखरखाव के साथ, सहयोग के लिए खुले, और इतने सस्ते कि अनुदान की ज़रूरत ही न पड़े। यह दरअसल एक ऐसी डिजिटल मानविकी के पक्ष में दलील है, जो संस्थागत सहारे के होने-न-होने की परवाह किए बिना चलती रहे।

tei-mcp: एआई एजेंटों के लिए TEI P5

Sun, 15 Mar 2026 00:00:00 +0000

अगर आपने कभी किसी एआई कोडिंग असिस्टेंट से TEI XML लिखवाया है, तो ग़ौर किया होगा कि वह गड़बड़ कर बैठता है। एलिमेंट वहाँ आ जाते हैं जहाँ उन्हें नहीं होना चाहिए। एट्रिब्यूट गढ़ लिए जाते हैं। नेस्टिंग के नियम अनदेखे रह जाते हैं। मॉडल को मोटा-मोटी अंदाज़ा है कि TEI कैसी दिखती है, पर विनिर्देश का कोई भरोसेमंद ज्ञान नहीं।

tei-mcp इसका हल है: यह एआई एजेंटों को TEI P5 दिशानिर्देशों तक सीधी, उपकरण-आधारित पहुँच देता है।

सामग्री तालिका

MCP क्या है?

(MCP) एक खुला मानक है, जो एआई ऐप्लिकेशनों को बाहरी डेटा-स्रोतों और उपकरणों से जोड़ने देता है। इसे एआई का USB पोर्ट समझिए: एक ही प्रोटोकॉल, जिससे कोई भी संगत क्लाइंट – Claude, Cursor, Windsurf और अन्य – विशेष सेवाओं में प्लग हो सकता है।

एक MCP सर्वर ऐसे उपकरण उपलब्ध कराता है, जिन्हें एआई बातचीत के दौरान बुला सकता है। रटे हुए प्रशिक्षण-डेटा के भरोसे रहने के बजाय मॉडल किसी जीवंत, प्रामाणिक स्रोत से पूछ सकता है।

tei-mcp क्या करता है

tei-mcp TEI P5 के ODD विनिर्देश को पार्स करता है और 16 उपकरण उपलब्ध कराता है, जो किसी संपादक या एनकोडर के सबसे आम सवालों का जवाब देते हैं:

यह एलिमेंट क्या है? किसी भी एलिमेंट, क्लास, मैक्रो या मॉड्यूल को नाम से खोजिए – बड़े-छोटे अक्षर का भेद किए बिना, और टाइपिंग की ग़लती पर सुझाव के साथ।
यह कौन-से एट्रिब्यूट लेता है? पूरी क्लास-श्रेणी में एट्रिब्यूट का निर्धारण – पहले स्थानीय, फिर क्रम से विरासत में मिले।
इसके भीतर क्या आ सकता है? कंटेंट मॉडल को संरचित वृक्ष के रूप में खोलिए, या वैध संतानों की सपाट सूची पाइए।
क्या यह एलिमेंट यहाँ आ सकता है? अभिभावक-संतान नेस्टिंग की जाँच कीजिए, या पूरी एलिमेंट-श्रेणी में पहुँच का पता लगाइए।
क्या मेरा दस्तावेज़ वैध है? किसी TEI XML फ़ाइल को विनिर्देश पर परखिए: कंटेंट मॉडल, एट्रिब्यूट के मान, बंद मान-सूचियाँ, संदर्भों की अखंडता और अप्रचलन की चेतावनियाँ।
और मेरी परियोजना की स्कीमा? ODD अनुकूलन फ़ाइल लोड कीजिए, ताकि ऊपर का सब कुछ आपकी परियोजना के TEI उपसमुच्चय तक सीमित रहे।

यह क्यों मायने रखता है

TEI एनकोडिंग में दिशानिर्देशों को बार-बार देखना पड़ता है। अनुभवी एनकोडर सबसे आम पैटर्न आत्मसात कर लेते हैं, लेकिन कम परिचित एलिमेंटों या जटिल कंटेंट मॉडलों के लिए उन्हें भी विनिर्देश खोलना पड़ता है। एआई असिस्टेंटों के पास ऐसा कोई आत्मसात ज्ञान नहीं होता, इसलिए उनकी समस्या और गंभीर है: वे देखने में ठीक-ठाक पर ग़लत मार्कअप गढ़ लेते हैं।

tei-mcp के साथ एआई को अनुमान लगाने की ज़रूरत नहीं। पहला कोण-कोष्ठक लिखने से पहले वह विनिर्देश में जवाब देख सकता है। नतीजा: ऐसा मार्कअप जो TEI P5 के – या आपकी परियोजना के ODD अनुकूलन के – अनुरूप हो।

शुरुआत कैसे करें

PyPI से इंस्टॉल कीजिए:

pip install tei-mcp

फिर इसे अपने MCP क्लाइंट की कॉन्फ़िगरेशन में जोड़िए:

{
 "mcpServers": {
 "tei": {
 "command": "uvx",
 "args": ["tei-mcp"]
 }
 }
}

सर्वर पहली बार चलने पर TEI विनिर्देश डाउनलोड करता है और किसी भी MCP-संगत क्लाइंट के साथ काम करता है।

स्रोत कोड और पूरा दस्तावेज़ीकरण:

ITA2 टेलीग्राफ़ एम्युलेटर से बाइनरी की पढ़ाई

Thu, 13 Feb 2025 00:00:00 +0000

अमूर्त को मूर्त बनाना

यह ITA2 एम्युलेटर पढ़ाने का एक व्यावहारिक औज़ार है। एनकोडिंग जैसी अमूर्त अवधारणा को आँखों के सामने और हाथ में ले आकर यह विद्यार्थियों को कंप्यूटिंग और दूरसंचार की एक बुनियादी बात से परिचित कराता है: बाइनरी निरूपण – यानी पाठ किस तरह एक और शून्य के पैटर्न में बदल जाता है। आम तौर पर हम इसे किताबी ढंग से पढ़ाते हैं, लेकिन जब टेप पर सचमुच छेद उभरते दिखते हैं, तो विद्यार्थी समझ पाते हैं कि कोई भौतिक व्यवस्था डिजिटल सूचना को कैसे धारण कर सकती है।

ITA2 (Baudot-Murray) Telegraph Type Emulator

Type a word in the input below to see its representation on the ITA2 tape.

Type word:

ऐतिहासिक पृष्ठभूमि: टेलीग्राफ़ से कंप्यूटिंग तक

ITA2 (International Telegraph Alphabet No. 2) कोड, जिसे बोदो-मरे कोड भी कहते हैं, 1920 के दशक में एमिल बोदो के 1870 के दशक वाले मूल टेलीग्राफ़ कोड को सुधारकर बनाया गया था। इन शुरुआती दूरसंचार प्रणालियों का बाद के कंप्यूटिंग विकास पर सीधा असर पड़ा:

5-बिट एनकोडिंग योजना कैरेक्टर एनकोडिंग का एक आरंभिक उदाहरण थी
वर्ण-समुच्चय की सीमा (5 बिट से केवल 32 संयोजन संभव) ने LETTERS/FIGURES शिफ़्ट की चतुर युक्ति को जन्म दिया
यह प्रणाली टेलीटाइप मशीनों में बीसवीं सदी के काफ़ी अंदर तक इस्तेमाल होती रही

खेल-खेल में स्टेट मशीन

LETTERS/FIGURES शिफ़्ट की युक्ति स्टेट मशीन की अवधारणा को सहज ढंग से सामने ले आती है। विद्यार्थी प्रयोग करते-करते ख़ुद खोज लेते हैं कि एक ही पैटर्न मौजूदा मोड के हिसाब से अलग-अलग वर्ण दर्शा सकता है। अवस्था-आधारित एनकोडिंग का यह हाथों-हाथ अनुभव उन्हें कंप्यूटिंग की और जटिल अवधारणाओं के लिए तैयार करता है। मिसाल के तौर पर, बिट-पैटर्न 00011 का अर्थ है:

LETTERS मोड में अक्षर ‘A’
FIGURES मोड में अंक ‘1’ अवस्था के अनुसार बदलने वाली यह दोहरी व्याख्या कंप्यूटर के डेटा-संचालन की बुनियाद में है।

कक्षा की गतिविधियाँ

ITA2 एम्युलेटर को पढ़ाई में शामिल करने के कुछ तरीक़े:

कोड तोड़ने की चुनौती: विद्यार्थियों से ITA2 पैटर्न में लिखे संदेश डिकोड करवाइए
किफ़ायती एनकोडिंग: चर्चा कीजिए कि बैंडविड्थ बचाने के लिए शिफ़्ट की युक्ति क्यों ज़रूरी थी
एनकोडिंग का विकास: ITA2 के 5-बिट कोड की तुलना ASCII (7-बिट) और Unicode से कीजिए
फ़िज़िकल कंप्यूटिंग: इस ऐतिहासिक प्रणाली को Arduino जैसे आधुनिक माइक्रोकंट्रोलरों से जोड़िए

सुगमता के लाभ

ऐतिहासिक दिलचस्पी से आगे, यह तरीक़ा अलग-अलग ढंग से सीखने वाले विद्यार्थियों के काम आता है:

देखकर सीखने वाले पैटर्न देखते हैं
हाथ से करके सीखने वाले एनकोडिंग की प्रक्रिया से सीधे जुड़ते हैं
सैद्धांतिक रुचि वाले सूचना सिद्धांत के गणितीय पहलू खंगाल सकते हैं

कार्यान्वयन का ब्योरा

एम्युलेटर JavaScript में लिखा गया है और किसी भी वेब-आधारित शिक्षण मंच में आसानी से जोड़ा जा सकता है। कोड मॉड्यूलर है और अलग-अलग शैक्षिक संदर्भों के अनुसार ढाला जा सकता है। स्रोत कोड यहाँ मिलेगा, और एम्युलेटर को आप ख़ुद भी आज़मा सकते हैं: