Język i kompilator

W języku Junexis opisujesz zadania, dane, połączenia i miejsca wykonania. Kompilator odczytuje ten opis, sprawdza obsługiwane reguły języka i tworzy model systemu. Dla wybranych środowisk może następnie wygenerować kod oraz pliki potrzebne do dalszego budowania.

Sprawdzenie, generowanie i uruchomienie to różne etapy

Poprawny opis nie jest jeszcze działającym systemem. Powstanie kodu Go, C++ lub TypeScript nie oznacza, że został on zbudowany narzędziami danego środowiska, uruchomiony albo sprawdzony na docelowym urządzeniu.

Co jest wejściem

Podstawową jednostką pracy jest projekt z manifestem junexis.project.toml i plikami źródłowymi .jnx. Źródła określają typy danych, zachowanie zadań oraz ich połączenia. Manifest wskazuje między innymi plik wejściowy i wybrane środowiska wykonania.

W przykładzie magazynu opis obejmuje pomiar temperatury, zadanie dostarczające dane, regułę alarmową i odbiorcę wyniku. Kompilator sprawdza zapisane konstrukcje i relacje. Nie ustala sam, jaka temperatura jest bezpieczna dla przechowywanego towaru — tę regułę określa autor systemu.

Junexis nie wymaga podziału Producer–Controller–Presenter. To pomocny model przykładu, a kompilator pracuje z rzeczywistymi zadaniami i połączeniami opisanymi w projekcie.

Co robią kolejne kroki

Krok	Pytanie, na które odpowiada	Granica wyniku
doctor	czy projekt i środowisko spełniają sprawdzane wymagania?	nie zastępuje zbudowania i uruchomienia systemu
parse i check	czy zapis jest zrozumiały i zgodny z obsługiwanymi regułami języka?	nie dowodzi poprawności reguł biznesowych ani działania w sieci
analyze	jakie zadania, relacje i topologia wynikają z opisu?	analiza modelu nie jest obserwacją działającego systemu
build	jakie pliki można wygenerować dla wybranych środowisk?	kod i manifesty nie są jeszcze potwierdzeniem natywnego budowania
artifact-gate	czy generowane artefakty spełniają sprawdzane kontrakty i przechodzą budowanie dostępnymi narzędziami?	nie zastępuje testu całego systemu w jego środowisku
pakowanie i uruchomienie	jak przygotować wynik do dostarczenia i rozpocząć wykonanie?	to dalsze operacje CLI i środowiska wykonawczego

Nie każda praca wymaga ręcznego wywoływania wszystkich kroków. Rozdzielenie ich wyników pozwala jednak ustalić, na którym etapie wystąpił problem.

Rola w platformie

flowchart LR
    SRC["Projekt .jnx"] --> PARSE["Parser i semantyka"]
    PARSE --> MODEL["Model i topologia"]
    MODEL --> CPP["C++ / urządzenie"]
    MODEL --> GO["Go / serwer"]
    MODEL --> TS["TypeScript / interfejs"]
    MODEL --> SNAP["Zapis analizy"]
    SNAP --> TOOLS["Studio i Mentor"]

Co działa

• praca z projektem opisanym manifestem junexis.project.toml,
• parser, AST, model pośredni, semantyka i analiza topologii,
• komendy init, doctor, parse, check, analyze i build,
• generowanie C++, Go i TypeScript w sprawdzonym zakresie,
• manifesty artefaktów, snapshoty analizy oraz mapy debugowania,
• pakowanie systemu, kontrola przed wdrożeniem i lokalne scenariusze wdrożeniowe,
• LSP udostępniający diagnostykę i tokeny semantyczne.

Szybkie sprawdzenie

junexis --version
junexis --help
junexis check .\moj-system

Polecenia budowania samego projektu C# należą do dokumentacji dla twórców kompilatora, a nie do instrukcji użytkownika Junexis.

Polecenie check wymaga istniejącego projektu w podanym katalogu. Przewodnik Szybka kontrola środowiska opisuje mały przykład po przygotowaniu CLI. Publiczne paczki instalacyjne nie są jeszcze udostępnione; sama publikacja dokumentacji nie oznacza dostępności instalatora.

Główne wyniki

Wynik	Konsument
kod i konfiguracja środowiska docelowego	zestaw narzędzi C++, Go albo TypeScript
junexis.artifacts.json	CLI, pakowanie i Studio
zapis analizy	Mentor i narzędzia architektoniczne
mapy źródeł i manifest debugowania	Studio oraz Narrative
stan ostatniego poprawnego budowania	uruchamianie, debugowanie i dalsze operacje CLI

Granice

Generatory nie obsługują jeszcze identycznego zakresu języka. Istnieją wykonywalne i wielotargetowe scenariusze, ale nie tworzą jeszcze pełnej macierzy zgodności dla każdego programu, urządzenia i transportu.

Przykłady w specyfikacji mogą opisywać kierunek rozwoju. O dostępności konkretnej funkcji decydują jej implementacja i sprawdzenie dla wybranego środowiska. Ekspercki zakres kontroli nie usuwa ograniczeń generatora.

Wygenerowane pliki w out/ mogą zostać odtworzone podczas kolejnego budowania. Trwałe zmiany wprowadzaj w źródłach, manifeście lub odpowiednim katalogu user/, zamiast poprawiać ręcznie wynik generatora.

Zobacz także podstawy języka i CLI.