‟overcq”

Programowanie

Uzupełnianie projektu OUX

Projekt OUX zaprezentowany niegdyś w postaci implementacji prototypowej ‟tracon” nie zawierał jeszcze implementacji całej definicji, która była opisywana podczas jej wymyślania pod nazwą opRWTng. Z tej teorii OUX nie zawierał implementacji ‹zdarzeń› obiektów, ponieważ nie wiadomo było, jak je obsługiwać w obecnym języku i kompilatorze C kompilującym programy do standardowego systemu ‘unix’ (pseudo‐POSIX). Obecnie definicja nazw używanych w projekcie uległa formalnej zmianie (przez formalne odrzucenie nie wyliczanych nazw opRWTng dla nazw wybranych ponownie do urzeczywistnionej definicji) oraz projekt implementacji (mimo jeszcze niezaimplementowania fizycznego w prototypie, co nastąpi w czasie dostępnym względem innych priorytetów) został uzupełniony do pełnej definicji opisanej teoretycznie pod nazwą opRWTng. Nazwy z bieżącego akapitu zostały w ich użytym znaczeniu porzucone już dawno lub znikoma ilość być może niedawno, a jeśli występują tak samo brzmiące wyrazy w obecnej całościowej definicji OUX, to nie mają one związku formalnego z projektem opRWTng. W szczególności “zdarzenie obiektu” nie ma bytu w OUX, mimo że jest obecne pojęcie konkretne: ‹zdarzenie›, które odnosi się do obiektu przepływu danych ‹menedżera› — i nie ma innych ‹zdarzeń›. Definicja opRWTng przestała być projektem, a stała się historią, i nie utrzymuje już samoistnie żadnej nazwy, a utrzymuje je definicja OUX, mimo że niekoniecznie przejęła ona już w swoim projekcie wszystkie rozwiązania szczegółowe określone w opRWTng spośród tych, które są właściwe dla niej. Projekt OUX posiada jeszcze własną nazwę OUX, która oczywiście pochodzi z DQUXGdzie zamiast symbolu “D” wcześniej był używany symbol litery ‛O’. Zmieniony z oczywistych względów podobieństwa do cyfry ‛0’ i niepotrzebnego związku graficznego z używanym ‛Q’. czyli z symboli bloków wykonywalnych języka programowania ‘natywnego’ OUX (zwanego też Coux) zaimplementowanego na gruncie C (‹zadanie›, ‹obiekt›, znacznik stanu sygnalizującego kolekcję, ‹raport›), więc jest ściśle związana z projektem przez źródło skrótu, a ma też odrębny związek z obecnymi słowami cząstkowymi fonetycznie lub przez skrót skrótów, ale ta nazwa nie jest już nazwą wewnętrzną projektu, lecz staje się nazwą własną grupy projektów programowanych w definicji OUX lub nazwą handlową, czyli innymi słowy – nazwa ta w oparciu o projekt OUX przechodzi do przestrzeni zarządzanej produktów gospodarczych z woli wykonawczej jej użycia przez osoby odpowiedzialne odpowiednio za promowanie i prowadzenie sprzedaży produktu, określanie polityki dystrybucji.

Projekt OUX został sformalizowany w jego rodzajach implementacyjno‐funkcjonalnych: • system OUX, • podsystem oux oraz • aplikacja OUX. wszystkie one mają grunt tego samego języka, a z punktu widzenia programisty różnią się tylko obecnością złącza sprzętowego bezpośredniego lub pośredniego, które realizuje te same funkcje udostępnianego do użycia ·przepływu wykonania· sprzętu, a nie żadne typy danych i inne konstrukcje granic obrazowych; jakoże i tak w trwałości kreacji Coux programista używa z uwzględnieniem stanu przepełnienia (najlepiej zawijanego) zmiennej — typu “N”, który nie ma górnej granicy rozmiaru. Aplikacja OUX w zasadzie jest tylko miniaturowym podsystemem OUX, ponieważ i tak zawiera moduły podsystemowe, które są częścią jej samodzielnego przepływu wykonania w realizacji niezależnej interpretacji użytkowej (czyli jest programem ‘exokernelowym’ kompilowalnym pod dowolnym rodzajem ‘kernela’ bez konieczności odrębności dyskowej ‹modułów› pomiędzy programami; jak zostanie w przyszłości zgodnie z definicją dawno utworzoną zaimplementowana instalacja ‹modułów› w pamięci dyskowej i operacyjnej). Uzupełnienia do całości teoretycznej OUXPonadto pozostała jeszcze implementacja użycia obiektów przez symbole w programie, z zarządzaniem ich „wyrzucania”, automatycznego zwalniania pamięci.:

Język programowania Coux będzie potrzebował własnego kompilatora, który nie będzie zawierał wbudowanych optymalizacji maszynowych, które zaprzeczałyby definicji języka (przez zbędne poszukiwania wzorców optymalizacji naruszające odrębność bytów w tekście źródłowym), a które są obecne w ‟gcc” i podobnie – innych kompilatorach kompilujących C/C++ bez atomowego przepływu wykonania. Ten kompilator być może zostanie utworzony jako implementacja przy podstawowym kompilatorze składni formatów danych, składni niedodefiniowanej o definicjach lewostronnych funkcyjnych; wstępny projekt sprzed lat. Oraz będą powstawać wzorce optymalne konstrukcji wykonawczych do realizacji określonych funkcji w systemie (w ‹menedżerach› i ‹sterownikach›, które przecież są używane otwarcie, jawnie w programach, ściśle integrowane funkcjonalnie w programie).