ISSIE (Interactive Schematic Simulator พร้อมตัวแก้ไขแบบรวม) เป็นแอปพลิเคชันสำหรับการออกแบบและจำลองวงจรดิจิตอล มีการกำหนดเป้าหมายไปที่นักเรียนและมือสมัครเล่นที่ต้องการเข้าใจแนวคิดอิเล็กทรอนิกส์ดิจิตอลในวิธีที่เรียบง่ายและสนุกสนาน Issie ได้รับการออกแบบให้เป็นมิตรกับผู้เริ่มต้นและแนะนำผู้ใช้ไปสู่เป้าหมายผ่านข้อความแสดงข้อผิดพลาดที่ชัดเจนและเบาะแสภาพ Issie ได้รับการพัฒนาและใช้อย่างแข็งขันในการสอนที่ Imperial College London
สำหรับข้อมูลทางเทคนิคเพิ่มเติมเกี่ยวกับโครงการอ่านต่อ เอกสารนี้ส่วนหนึ่งมาจากเอกสาร Visual2 ที่ยอดเยี่ยมเนื่องจากมีความคล้ายคลึงกันในสแต็กเทคโนโลยีที่ใช้
สำหรับเว็บไซต์ ISSIE ไปที่นี่
แอปพลิเคชันส่วนใหญ่เขียนใน F#ซึ่งจะถูกส่งไปยัง JavaScript ผ่านคอมไพเลอร์นิทาน จากนั้นอิเล็กตรอนจะถูกใช้เพื่อแปลงเว็บแอปที่พัฒนาแล้วเป็นแอปพลิเคชันข้ามแพลตฟอร์ม อิเล็กตรอนให้การเข้าถึง API ระดับแพลตฟอร์ม (เช่นการเข้าถึงระบบไฟล์) ซึ่งจะไม่สามารถใช้ได้กับเว็บแอปเบราว์เซอร์วานิลลา
WebPack 5 เป็นโมดูล Bundler ที่รับผิดชอบการต่อการต่อ JavaScript และกระบวนการสร้างอัตโนมัติ: การสร้างอิเล็กตรอน-Webpack นั้นเป็นไปโดยอัตโนมัติโดยใช้สคริปต์ที่มีอยู่แล้วภายใต้ไดเรกทอรีสคริปต์
ความสามารถในการวาดภาพมีให้ (ตอนนี้) โดยไลบรารีบรรณาธิการแผนผังที่กำหนดเองที่ใช้ใน F# และพิเศษสำหรับส่วนประกอบดิจิตอล
ทางเลือกของ F# เป็นภาษาการเขียนโปรแกรมหลักสำหรับแอพได้รับการกำหนดโดยปัจจัยบางประการ:
หากคุณเพียงต้องการเรียกใช้แอพไปที่หน้ารีลีสและดาวน์โหลดและเรียกใช้ไบนารี prebuilt ล่าสุดสำหรับแพลตฟอร์มของคุณ (Windows หรือ MacOS) ISSIE จะต้องใช้พื้นที่ดิสก์ทั้งหมดประมาณ 200 เมตร
Issie.exe ระดับบนสุดในไฟล์คลายซิป ISSIE ติดตั้งและรันโดยไม่ต้องเปลี่ยนระบบ - รหัสทั้งหมดอยู่ในไดเรกทอรีที่คุณดาวน์โหลด คุณสามารถลบสิ่งนี้และแทนที่ด้วย ISSIE เวอร์ชันภายหลัง แผ่นออกแบบแต่ละแผ่นจะถูกเก็บไว้ในไฟล์ที่มีชื่อคล้ายกันภายใต้ไดเรกทอรีโครงการ backup ไดเรกทอรีย่อยมีจำนวนสแน็ปช็อตสำรองจำนวนมากสำหรับการกู้คืนการออกแบบ สิ่งเหล่านี้ไม่จำเป็นสำหรับการดำเนินการของ ISSIE เพื่อให้คุณสามารถลบได้ - หรือแม้แต่ไดเรกทอรี backup ทั้งหมดหากคุณต้องการ
ISSIE Binaries จะไม่เรียกใช้ (ในบางกรณี) จากตำแหน่งไฟล์เครือข่าย (พบในเครื่องคลัสเตอร์จำนวนมาก) หากคุณมีปัญหานี้จะนำทางไปยังไดเรกทอรีระดับบนสุดที่มีไบนารี ISSIE ในหน้าต่างคำสั่งและพิมพ์ issie.exe --no-sandbox ดู #125 สำหรับรายละเอียด
เมื่อคุณเปิด ISSIE และพร้อมที่จะไปอย่าลังเลที่จะเปิดหนึ่งในโครงการสาธิตจากหน้าต่างเริ่มต้น สิ่งเหล่านี้อยู่ที่นั่นเพื่อแสดงให้คุณเห็นว่าโครงการ ISSIE ที่สมบูรณ์มีลักษณะอย่างไรและช่วยให้คุณสนุกกับมันโดยไม่ต้องออกแบบและสร้างมันขึ้นมาตั้งแต่เริ่มต้น ทุกครั้งที่คุณเปิดโครงการสาธิตอีกครั้งมันจะถูกรีเซ็ตเป็นสถานะเริ่มต้น
หากคุณต้องการเริ่มต้นในฐานะนักพัฒนาให้ทำตามขั้นตอนเหล่านี้
ดาวน์โหลดและติดตั้ง (หากคุณมีเครื่องมือเหล่านี้ติดตั้งอยู่แล้วเพียงตรวจสอบข้อ จำกัด ของเวอร์ชัน)
npm ดังนั้นจึงไม่จำเป็นต้องติดตั้งแยกต่างหากดาวน์โหลดและคลายซิป issie repo หรือโคลนในพื้นที่หรือส้อมบน GitHub แล้วโคลนในพื้นที่
ตรวจสอบว่าคุณมี. NET 8.X SDK, Node V20.x: หากคุณต้องการทำมากกว่าทำไบนารีเช่นกัน: VS 2022 (หรือรหัสล่าสุด vs + Ionide หรือ Rider) ติดตั้ง
node -v แสดงเวอร์ชันโหนด dotnet --version แสดงเวอร์ชัน DOTNETนำทางจากไดเรกทอรีรากสาขา repo master (ซึ่งมี readme นี้) ในล่ามบรรทัดคำสั่งหรือเริ่มต้นหนึ่งจากเมนูบริบทของไดเรกทอรี
เรียกใช้ build.cmd ภายใต้ windows หรือ build.sh ภายใต้ linux หรือ macOS ( chmod 755 build.sh จะให้สิทธิ์การดำเนินการสคริปต์) สิ่งนี้จะดาวน์โหลดและติดตั้งการพึ่งพาทั้งหมดจากนั้นเรียกใช้แอปพลิเคชันในโหมด Dev ด้วย HMR
File -> reload pagenpm run dev อีกครั้ง เรียกใช้ npm run debug สำหรับโหมดการดีบัก (จะช้ากว่า DEV มาก)npm run distpacket.json ดังนั้นจึงจำเป็นต้องสร้างไฟล์ล็อค paket-lock.json ใหม่ให้ใช้ npm installbuild killzombies จะยุติกระบวนการ Orphan Node และ Dotnet ซึ่งบางครั้งเกิดขึ้นโดยใช้ห่วงโซ่การสร้างนี้หลังจากการยุติที่ผิดปกติ (อาจไม่จำเป็นอีกต่อไป?)npm run dist ในหน้าต่างคำสั่งเพื่อสร้างไบนารีภายใต้ไดเรกทอรี .dist สำหรับ MacOS คุณจะต้องติดตั้ง Python 3 เพื่อรวบรวมไบนารีดั้งเดิม - คุณจะได้รับการแนะนำอัตโนมัติในการทำเช่นนี้ แต่จะต้องเรียกใช้ npm run dist อีกครั้งNB - ควบคู่ไปกับการรวบรวมข้างต้นรหัส ISSIE จะรวบรวมโดยไม่มีข้อผิดพลาด (แต่ไม่ทำงาน) ภายใต้ Dotnet ตัวอย่างเช่นการสร้างจาก Visual Studio การรวบรวมควรเหมือนกัน แต่เมื่อไม่แน่ใจว่าทำไมมีข้อผิดพลาดมี ประโยชน์มาก ในการสร้างรหัสปัจจุบันภายใต้. NET ด้วย VS หรือ VSC และง่ายต่อการค้นหาข้อความแสดงข้อผิดพลาด ในทำนองเดียวกัน VS หรือ VSC สามารถใช้ด้วยความมั่นใจในการเปลี่ยนรหัสทดสอบด้วยการรวบรวม การสร้างภายใต้ VS หรือ VSC ไม่สามารถทำงานได้เนื่องจากรหัสขึ้นอยู่กับอิเล็กตรอนและโหนด API ในการทำงาน
package-lock.json มีแพ็คเกจที่แน่นอนและดาวน์โหลดจาก repo โดยปกติคุณไม่จำเป็นต้องเปลี่ยนสิ่งนี้ บิลด์มาตรฐานด้านบนจะเรียกใช้ npm ci ซึ่งตรวจสอบและตรวจสอบแพ็คเกจ แต่ไม่เปลี่ยนไฟล์ล็อคpackage.json1 ) ใช้ npm install เพื่อสร้างไฟล์ล็อคใหม่ซึ่งสามารถส่งไปยัง repo ได้npm upgrade name หรือ npm [-D] install name แทนการแก้ไข package.json JSONnpm ls name เพื่อค้นหาแพ็คเกจที่ต้องการใช้ (โดยปกติแล้วการอัพเกรดหรือแทนที่พวกเขาจะลบปัญหา) บิลด์ที่สะอาดจะทำงานได้ดีอย่างเท่าเทียมกันใน MacOS แต่สิ่งต่าง ๆ มีแนวโน้มที่จะผิดพลาดมากขึ้นหากคุณเคยติดตั้งแพ็คเกจที่ขัดแย้งกันมาก่อน:
dotnet เวอร์ชันดั้งเดิม - สามารถลบได้หากจำเป็นที่นี่:
curl -O https://raw.githubusercontent.com/dotnet/sdk/main/scripts/obtain/uninstall/dotnet-uninstall-pkgs.sh
chmod u+x dotnet-uninstall-pkgs.sh
sudo ./dotnet-uninstall-pkgs.sh การอนุญาตรูทในไฟล์ dev เพื่อให้ dev ทำงานได้อย่างราบรื่นคุณต้องติดตั้งไฟล์การกำหนดค่าทุกไฟล์ภายใต้ชื่อผู้ใช้ของคุณเองดังนั้นคุณจึงสามารถเข้าถึง R/W สิ่งนี้จะแตกหักหากคุณเคยพบว่าตัวเองใช้ซอฟต์แวร์ sudo เพื่อรูทติดตั้งหรือถ้าคุณเคยทำสิ่งนี้ในอดีต ในกรณีนี้คุณสามารถได้รับปัญหารอบชั่วคราวโดยใช้ sudo เพื่อเรียกใช้การพัฒนา (หรือแอพที่สร้างขึ้น) ด้วยสิทธิ์ของผู้ดูแลระบบ นี่เป็นสิ่งที่ผิดที่ต้องทำ คุณควรใช้แทน
chown -R `whoami` dir สำหรับแต่ละไดเรกทอรีที่อาจมีไฟล์ที่มีสิทธิ์ไม่ดี โดยทั่วไป . dev ของคุณ และ /usr/localการถอนการติดตั้งและติดตั้ง Dotnet ล่าสุดจะมีประโยชน์หากมีการติดตั้ง Dotnet ผิด
สำหรับผู้ใช้ Apple Silicon Mac คุณควรใช้. NET เวอร์ชัน ARM64 เพื่อให้ได้ผลลัพธ์ที่ดีที่สุด คุณสามารถรับได้จากเว็บไซต์ Microsoft อย่างเป็นทางการโดยใช้ตัวติดตั้ง
แม้ว่าห่วงโซ่ dev นั้นซับซ้อน แต่ตอนนี้มันราบรื่นและเหมือนกันมากสำหรับทุกแพลตฟอร์ม แต่ละขั้นตอนเหล่านี้สามารถทำได้ตามต้องการ:
Dotnet SDK และ Node Dotnet SDK ให้ F#dotnet tool restore ช่วยให้คุณได้รับเครื่องมือ Dev: Fable Compiler, Fake Build Automation, paket Dotnet Package Manager (การจัดการแพ็คเกจโหนดผ่าน npm ซึ่งมาพร้อมกับโหนด)dotnet paket install ติดตั้งแพ็คเกจด้าน dotnet ทั้งหมดที่จำเป็นnpm ci ดาวน์โหลดและตรวจสอบเวอร์ชันที่ถูกต้องของแพ็คเกจ NPM ทั้งหมด npm install จะทำซ้ำเวอร์ชันหากสิ่งเหล่านี้มีการเปลี่ยนแปลงและสร้างไฟล์ล็อคที่อัปเดตnpm run dev , npm run dist , npm run debug : สคริปต์ที่กำหนดไว้ใน package.json ซึ่งควบคุมการพัฒนา (พร้อม HMR) หรือการรวบรวมการผลิตด้วยนิทานและการบรรจุโดยใช้ WebPack 5build.cmd และ build.sh scripts แพ็คเกจขั้นตอนข้างต้นเพิ่มการทำความสะอาดไดเรกทอรีที่ไม่จำเป็นบางอย่าง - คุณสามารถเรียกใช้งานเป็นรายบุคคลได้หากคุณมีปัญหาdotnet-tools.jsonpaket.dependencies ที่ระดับบนสุด และ paket.references ในไดเรกทอรีของไฟล์ .fsproj ที่เกี่ยวข้อง ปัจจุบันแพ็คเกจ Dotnet ไม่ได้ถูกตรึงไว้ในเวอร์ชันดังนั้นจึงใช้เวอร์ชันล่าสุดที่ใช้งานร่วมกันได้เสมอ นี่อาจผิด แต่ดูเหมือนว่าจะทำงานได้ดี.d สิ่งนี้ใช้งานได้ดี แต่จำเป็นต้องมีการปรับด้วยตนเองสำหรับสิ่งที่ซับซ้อน ดูอินเทอร์เฟซอิเล็กตรอน API ใน ISSIE ซึ่งสร้างขึ้นในลักษณะนี้จากไฟล์อิเล็กตรอน API .d ที่เผยแพร่ - ในกรณีนั้นการปรับด้วยตนเองค่อนข้างไม่เป็นที่พอใจเนื่องจากอิเล็กตรอน API นั้นซับซ้อนมาก Electron Bundles Chromium (View) และ Node.js (เครื่องยนต์) ดังนั้นในทุกโครงการ Node.js ไฟล์ package.json จะระบุการพึ่งพาโมดูล (โหนด)
นอกจากนี้ส่วน "scripts" :
"scripts": {
"clean-dev-mac": "sudo killall -9 node && sudo killall -9 dotnet && sudo killall -9 issie",
"clean-dev-win": "taskkill /f /im node.exe && taskkill /f /im dotnet.exe && taskkill /f /im issie.exe",
"compile": "dotnet fable src/Main -s && dotnet fable src/Renderer -s --define PRODUCTION",
"debug": "dotnet fable watch src/Main -s --run npm run debugrenderer",
"debugrenderer": "dotnet fable watch src/Renderer -s --define ASSERTS --run npm run start",
"dev": "dotnet fable watch src/Main -s --run npm run devrenderer",
"devrenderer": "dotnet fable watch src/Renderer -s --run npm run start",
"start": "cross-env NODE_ENV=development node scripts/start.js",
"build": "cross-env NODE_ENV=production node scripts/build.js",
"pack": "npm run compile && npm run build && electron-builder --dir",
"dist": "npm run compile && npm run build && electron-builder",
"buildonly": "electron-builder",
"compile-sass": "cd src/renderer/scss && node-sass main.scss main.css",
"testcompiler": "cd src/Renderer/VerilogComponent/test && dotnet fable --noCache && node testParser.fs.js"
}
กำหนดคำสั่งทางลัดในโครงการเป็นชุดของ <key> : <value บรรทัดดังนั้นเมื่อเราใช้ npm run <stript_key> มันเทียบเท่ากับการเรียก <script_value> ตัวอย่างเช่นในรูทของโครงการการทำงานในเทอร์มินัล npm run dev นั้นเทียบเท่ากับบรรทัดคำสั่ง:
dotnet fable watch src/Main -s --run npm run devrenderer
สิ่งนี้เรียกใช้ Fable 4 เพื่อ transpile กระบวนการหลักจากนั้น ( --run เป็นตัวเลือกของนิทานที่จะเรียกใช้คำสั่งอื่น) เรียกใช้ script devrenderer เพื่อ transpile ไปยัง JavaScript และดูไฟล์ F# ในกระบวนการเรนเดอร์ หลังจากการเรนเดอร์ transpilation เสร็จสิ้นการเริ่มต้นสคริปต์ js จะเรียกใช้ สิ่งนี้เรียกใช้ webpack เพื่อแพ็คและ lauch รหัส JavaScript ภายใต้อิเล็กตรอนและยังเฝ้าดูการเปลี่ยนแปลงในรหัส JavaScript และ HOT โหลด เหล่านี้ในแอปพลิเคชันที่กำลังทำงานอยู่
ด้วยเหตุนี้เมื่อใดก็ตามที่บันทึกไฟล์โครงการ F# Renderer ที่แก้ไขได้ตลอดเวลา (เกือบ) ทันที:
ระบบบิลด์ขึ้นอยู่กับไฟล์ Fake build.fsx ปลอมเป็น DSL ที่เขียนใน F# ซึ่งมีความเชี่ยวชาญในการสร้างงานสร้างอัตโนมัติ build.fsx มีเป้าหมายที่แสดงถึงงานสร้างและโดยปกติแล้วสิ่งเหล่านี้จะทำงานผ่าน build.cmd หรือ build.sh แทนที่จะใช้ dotnet fake โดยตรง:
build <target> ==> dotnet fake build -t <target> ซอร์สโค้ดประกอบด้วยสองส่วนที่แตกต่างกัน transpiled แยกไปยัง JavaScript เพื่อสร้างแอปพลิเคชันอิเล็กตรอนที่สมบูรณ์
อิเล็กตรอนจึงอนุญาตให้เขียนรหัสสำหรับเบราว์เซอร์ (HTML + CSS + JavaScript) ทำงานเป็นแอพเดสก์ท็อปที่มีความสามารถเพิ่มเติมของการเข้าถึงระบบไฟล์เดสก์ท็อปผ่านการสื่อสารระหว่างสองกระบวนการ
กระบวนการทั้งสองรัน JavaScript ภายใต้โหนด
แหล่ง src/Main/Main.fs กำหนดค่าอิเล็กตรอนเริ่มต้นและเป็นหม้อต้ม มันถูก transpiled ไปยังไดเรกทอรีรูทโปรเจ็กต์เพื่อให้สามารถรับได้โดยอัตโนมัติโดยอิเล็กตรอน
รหัสแอพที่เหลือ (ใน)
รหัสที่เปลี่ยนแหล่งที่มาโครงการ F# เป็น renderer.js คือคอมไพเลอร์นิทานตามด้วยโหนด Webpack Bundler ที่รวมไฟล์ JavaScript หลายไฟล์ลงใน renderer.js เดียว
กระบวนการคอมไพล์ถูกควบคุมโดยไฟล์ .fsproj (กำหนดแหล่ง F# source) และ webpack.additions.main.js , webpack.additions.renderer.js ซึ่งกำหนดวิธีการที่ WebPack รวมเอาเอาต์พุต F# สำหรับทั้งกระบวนการอิเล็กตรอนหลักและอิเล็กตรอน นี่คือหม้อต้มที่คุณไม่จำเป็นต้องเปลี่ยน โดยปกติไฟล์โครงการ F# จะต้องแก้ไขทั้งหมด
มีสคริปต์ในรูทของที่เก็บ, build_docs.sh ซึ่งจะสร้างเอกสารสำหรับโครงการโดยใช้ FSDOCs โครงการจะต้องคอมไพล์พร้อมก่อนที่จะสร้างเอกสาร
ไฟล์ Markdown ภายใต้ /docs จะถูกเปลี่ยนเป็นหน้าคงที่ในเว็บไซต์เอกสาร ความคิดเห็น XML ใด ๆ ในรหัสจะกลายเป็นความคิดเห็นของเอกสารสำหรับทุกฟังก์ชั่นใน codebase
หากต้องการเพิ่มการอัปเดตให้ไปที่โฟลเดอร์ /docs/updates และสร้างไฟล์ MarkDown ใหม่ด้วยส่วนหัวต่อไปนี้:
---
layout : post
title : [title here]
date : [ ISO 8601 UTC datetime, etc 2021-07-04 15:52:01 +0100]
category : Updates
index : [index that decides the order of the update. later updates have greater indexes]
---
# your markdown content below ดูเอกสารอื่น ๆ ในโฟลเดอร์ /docs/updates สำหรับตัวอย่าง
ความคิดเห็น XML ทั้งหมด (เริ่มต้นด้วย /// ) ภายใต้การประกาศโมดูลและฟังก์ชั่นใด ๆ จะถูกเปลี่ยนเป็นเอกสารภายใต้ส่วนอ้างอิง API ของเว็บไซต์เอกสาร
โปรดติดตามกฎ XML เมื่อสร้างความคิดเห็นจากเอกสารในรหัสเช่นไม่มีการใช้งานวงเล็บสามเหลี่ยม <และ> นอกเหนือจากแท็ก กรุณาอย่าใช้คำพูดสองเท่าเช่นกัน!
build_docs.sh ยังเรียก dotnet fsdocs watch เพื่อเริ่มต้นเซิร์ฟเวอร์ท้องถิ่นที่โฮสต์เอกสารที่ http: // localhost: 8901/ เอกสารที่สร้างขึ้นสำหรับรหัสอยู่ภายใต้ส่วน "การอ้างอิง API"
หากคุณสร้างเอกสารและต้องการเข้าถึงเซิร์ฟเวอร์อีกครั้งคุณสามารถเรียกใช้ dotnet fsdocs watch ในเทอร์มินัล
หมายเหตุด้านข้าง: สคริปต์แทนที่จะใช้
dotnet fsdocs buildปกติเนื่องจากมีข้อผิดพลาดที่ไม่มีเอกสารซึ่งคอมไพเลอร์สร้างรหัส XML ที่ไม่ถูกต้องสำหรับฟังก์ชั่นที่มีเร็กคอร์ดที่ไม่ระบุชื่อกำหนดแอตทริบิวต์ด้วย "<>" ในชื่อของพวกเขา สิ่งนี้ทำให้คนรุ่นล้มเหลว การใช้<exclude/>ไม่ได้แก้ไขปัญหาดังนั้นวิธีแก้ปัญหาคือการเรียกสคริปต์ที่ใช้ Regex เพื่อลบแอตทริบิวต์ที่ไม่ถูกต้องเหล่านี้ออกจากเอกสาร XML ก่อนที่จะสร้างเอกสาร
ดูปัญหาที่คล้ายกันเกี่ยวกับ GitHub ที่มีข้อผิดพลาดที่คล้ายกันที่นี่
src| โฟลเดอร์ย่อยหรือไฟล์ | คำอธิบาย |
|---|---|
Main/main.fs | รหัสสำหรับกระบวนการอิเล็กตรอนหลักที่ตั้งค่าทุกอย่างขึ้น - ปกติจะไม่เปลี่ยนแปลง |
Renderer/Common/* | จัดเตรียมประเภทและยูทิลิตี้ทั่วไปบางประเภทรวมถึงอินเทอร์เฟซกับไลบรารี API และไลบรารีที่กำหนดเอง |
Renderer/Interface/* | มีฟังก์ชั่นอินเทอร์เฟซระดับต่ำและการจัดการไฟล์ระดับต่ำทั้งหมด |
Renderer/DrawBlock/* | มีรหัสโปรแกรมแก้ไขแผนผังที่ใช้ SVG ทั้งหมดใน F# |
Renderer/Simulator/* | มีตรรกะในการวิเคราะห์และจำลองแผนผังแผ่นงาน |
Renderer/UI/* | มีตรรกะ UI |
./renderer.fs | ไฟล์ระดับบนสุดที่ขับรหัสเรนเดอร์: มีรหัสเมนู Elmish MVU และรหัสเมนูอิเล็กตรอน |
Testsการทดสอบในปัจจุบันมีอายุมากและจะไม่ทำงาน พวกเขาจะขึ้นอยู่กับไลบรารีการทดสอบ F# คาดหวังและโดยหลักการแล้วรหัส Widthinferrer และ Simulator (ซึ่งทำงานภายใต้ Dotnet) สามารถทดสอบได้ที่นี่
Staticมีไฟล์คงที่ที่ใช้ในแอปพลิเคชัน
Docs เอกสารมีข้อมูลแหล่งที่มาที่ควบคุมเว็บไซต์เอกสารโครงการ https://tomcl.github.io/issie/
ISSIE อนุญาตให้ผู้ใช้สร้างโครงการและไฟล์ภายในโครงการเหล่านั้น โครงการ ISSIE เป็นเพียงโฟลเดอร์ชื่อ <project-name> ที่มีไฟล์ว่างชื่อ <project_name>.dprj (DPRJ ย่อมาจากโครงการไดอะแกรม) โฟลเดอร์ Project ใด ๆ ไฟล์การออกแบบที่ไม่ใช่ศูนย์แต่ละไฟล์ชื่อ <component_name>.dgm (DGM ย่อมาจากไดอะแกรม) ไฟล์การออกแบบแต่ละไฟล์แสดงถึงแผ่นออกแบบหนึ่งแผ่นของการออกแบบฮาร์ดแวร์แบบลำดับชั้นแผ่นสามารถมีเป็นส่วนประกอบแผ่นอื่น ๆ
เมื่อเปิดโครงการ ISSIE จะเริ่มค้นหาที่เก็บข้อมูลที่กำหนดสำหรับไฟล์ .dgm แยกวิเคราะห์และโหลดเนื้อหาของพวกเขาและอนุญาตให้ผู้ใช้เปิดใน ISSIE หรือใช้เป็นส่วนประกอบในการออกแบบอื่น ๆ
ในการติดตั้งสภาพแวดล้อมการสร้างใหม่ (โดยไม่ต้องเปลี่ยนรหัสโครงการ) เรียกใช้ใหม่ build.cmd (Windows) หรือ build.sh (Linux และ MacOS)
npm run dist จะสร้างไบนารีที่ถูกต้องสำหรับระบบของคุณภายใต้ /dist