https://outcast.am/w/748yNuYn2ZbeaQ5Ps7RRMP
ցոյց եմ տալիս իմ նոր ծրագիրը՝ պիտակներ օգտագործելով ֆայլային համակարգի ընդլայնուած յատկութիւնները։
իհարկէ գրուած ա #օբերոն լեզուով։
#էկրանահան #ֆայլային_համակարգ #ֆայլ #նիշք #ընդլայնուած_յատկութիւններ #պիտակ #պիտակներ #էտիկէտկա #էտիկէտ #ներկայացում #զեկոյց
գուցէ գիտէք, որ borland֊ը որ ստեղծել էր delphi֊ն, փորձեց object pascal֊ում եղած ֆիչըրները բերել c++։ ու բորլանդի c++֊ը տարբերւում ա սովորական c++֊ից նրանով, որ ունի այսպէս կոչուած closure֊ներ, կամ անոնիմ մեթոդներ։
իրականում, եթէ գալիս ես օբերոնից՝ ոչ մի տարօրինակ բան չկայ, շատ նորմալ ֆունկցիոնալ ա։
ահա օրինակ՝
type
TNotifyEvent = procedure(Sender: TObject) of object;
TButton = class
private
FOnClick: TNotifyEvent;
public
procedure Click;
property OnClick: TNotifyEvent read FOnClick write FOnClick;
end;
procedure TButton.Click;
begin
if Assigned(FOnClick) then
FOnClick(Self);
end;
procedure MyButtonClick(Sender: TObject);
begin
WriteLn('Button clicked!');
end;
procedure SomeEntryPoint;
var
Button: TButton;
begin
Button := TButton.Create;
Button.OnClick := @MyButtonClick;
Button.Click; // Outputs: Button clicked!
Button.Free;
end;
TNotifyEvent֊ը ֆունկցիայի, պրոցեդուրայի տիպ ա։ յետոյ այդ տիպի պրոցեդուրա ա կարելի ստեղծել։
Sender: Tobject ֊ը մեզ պէտք ա, որ իմանանք ով ա այդ event֊ը ուղարկել։ ինչի՞ ա ինքը TObject տիպի՝ որովհետեւ դա կլասսերի ծառի արմատն ա՝ ամէնը դրանից են ժառանգած, այսինքն՝ ամէնը կարելի ա դրան վերագրել։
օրինակ, կարելի ա էսպէս իմանալ թէ ով ա՝
if Sender is TButton then // Check if the sender is a button
begin
if TButton(Sender).Name = 'Button1' then
ShowMessage('Button 1 was clicked!')
else if TButton(Sender).Name = 'Button2' then
ShowMessage('Button 2 was clicked!');
end
else
begin
ShowMessage('Something else triggered this event!');
end;
տեսէք լրիւ օբերոնի runtime check անող IS ֊ն ա։
Button(Sender).Name ֊ը թոյլ ա տալիս կարդալ էդ կոնկրէտ կոճակի անունը։ օրինակ, կարող ես կոճակի անունը դնել Button1, իսկ կարող ես օրինակ՝ processButton։
Button֊ը իրականում ցուցիչ ա յիշողութեան մի տեղի, որ դատարկ ա։
TButton.Create֊ը լցնում ա էդ տեղը, ստեղծում ա յիշողութեան մէջ դաշտերը, կլասը, ու վերադարձնում ա էդ պատրաստուած յիշողութեանը ցուցիչ։
Button.OnClick֊ին կարողանում ենք վերագրել MyButtonClick ֆունկցիայի հասցէն։
այդ OnClick֊ը pascal֊ի property ա, որը կայ իմ իմանալով միայն այլ անդրեաս հայլսբերգի լեզուի՝ c#֊ի մէջ։
դրանից յետոյ Button.Click֊ը դա ա կանչելու։
շատ օբերոնական ա, չէ՞։ (:
ո՞նց ա դա արւում borland֊ի c++ դիալեկտով՝
#include <vcl.h>
#pragma hdrstop
class TButton
{
private:
typedef void __fastcall (__closure *TNotifyEvent)(TObject *Sender);
TNotifyEvent FOnClick;
public:
void __fastcall Click()
{
if (FOnClick)
FOnClick(this);
}
void __fastcall setOnClick(TNotifyEvent value)
{
FOnClick = value;
}
TNotifyEvent __fastcall getOnClick()
{
return FOnClick;
}
__property TNotifyEvent OnClick = {read=getOnClick, write=setOnClick};
};
void __fastcall MyButtonClick(TObject *Sender)
{
ShowMessage("Button clicked!");
}
int main()
{
TButton *Button = new TButton;
Button->OnClick = MyButtonClick;
Button->Click(); // Outputs: Button clicked!
delete Button;
return 0;
}
նախ, ահագին ոչ ընթերնելի ա, ինձ թւում ա։
յետոյ, դէ մասնաւորապէս որովհետեւ fastcall֊ը նշանակում ա որ պասկալի ֆունկցիա ա կանչելու, զի ամբողջ գրադարանը (vcl֊ը կամ fmx֊ը) պասկալով ա գրուած։
closure֊ը borland֊ի լուծումն ա որ մեթոդ փոյնթերն իմանայ this֊ի մասին։ ոնց pascal֊ում ա հնարաւոր։
property֊ով են փորձում դէ property իրականացնել։
հետաքրքիր ա, որ qt֊ն էլ ստանդարտ c++ չի՝ իրենք փաստացի նոր լեզու են ստեղծել, ու իրենց մօտ կայ moc (meta object compiler) որը յետոյ բերում ա qt֊ի կոդը ստանդարտ c++֊ի։ ու իրենք ունեն ինչ֊որ slot֊եր ու signal֊ներ որ էլի էմուլացնում են նոյն բանը՝ property֊ներ ու event֊ներ։
gtk֊ում ստանդարտ c ա, ու դա աւելի ա դուրս գալիս։
ի դէպ՝
https://norayr.am/weblog/2021/04/18/2492083/ — այն մասին ա որ embarcadero֊ն այլեւս չի կարողանում իր c++ քոմփայլերը շարունակել, զի c++ ստանդարտն էնքան արագ ա շարժւում, որ չեն ձգում։ ու հիմա փաստացի մէյնթէյն են անում llvm֊ի փաթչեր։ llvm֊ի արտօնագիրն էլ թոյլ ա տալիս որ դա անեն։ աւաղ։ (:
https://norayr.am/weblog/2021/04/19/2530704/
#ծրագրաւորում #ծրագրաւորման_լեզուներ #տէք #պասկալ #օբերոն #pascal #oberon
երեք աղջիկ նստած անքուն թել են մանում մի իրիկուն թէ լինէի ես թագուհի ասում է մէկը սրտալի կը սարքէի vπn անվտանգ կը լինէր ատեն
թէ լինէի ես թագուհի նրա քոյրն է ասում բարի կը գործէի քոմփայեր ադա լեզուի անունը կը դնէի ցիկադա որի
թէ լինէի ես թագուհի երրորդ քոյրն է յուզուած ասում կը կենդանացնէի օհ֊ն օբերոն անունը կը լինէր՝ օվերտոն։
#ադա #ցիկադա #օբերոն #անքուն
երբ պասկալով ա կոդ գեներացնում, աբօն՝ արհեստական բանականութիւնը, յաճախ շփոթւում ա այնտեղ, ուր օրինակ տիպ ա գրում, բայց չի ջոկում որ էդ տիպ նկարագրող unit֊ը իմպորտ չի արել։ ինչի՞ չի ջոկում, որովհետեւ դէ կոդի մէջ տեսել ա՝ աշխատում ա, չի մտածել որ մի մոդուլի մէջ ա ու որ էդ մոդուլը պէտք ա ներմուծել։
իսկ օբերոնով երբ գրում ա, պիտի յստակ իմանայ ինչը որտեղ ա որ ճիշտ գրի։ ու էդ դէպքում նման սխալ անել չի կարող։
#աբ #պասկալ #օբերոն
ինձ մէյլ եկաւ օփենէյայից, որ բոլոր օգտատէրերն այլեւս կարող են շփուել իմ oberon programmer֊ի հետ։
#օբերոն
ապահով լեզուն էն ա երբ segfault֊ը անհնար ա։ բայց մեր վիշապի իմպլեմենտացիան կաղ էր որովհետեւ segfault լինում էր երբ dereference of NIL pointer էիր անում։
հիմա ուղղեցի, հիմա ռանթայմը սպանում ա ծրագիրը։
եթէ կարող էք թեստաւորել՝ խնդրում եմ արէք։ ես ստուգել եմ x86_64 ու aarch64 լինուքսների վրայ։
պէտք ա անել
git clone -b catching_segfault https://github.com/vishaps/voc
cd voc
make full
sudo make install
ու յետոյ ինչպէս էկրանահանում։ եթէ ամէնը լաւ լինի, վաղը մերջ կանեմ մասթերի մէջ։
#էկրանահան #վիշապ #օբերոն
ես պարբերաբար փորձել եմ գրել makefile որը
ու մէկ ա կան խնդիրներ ու ամէնը վատ ա։
դրա լուծումն էլ կայ՝ vipack֊ը։
ոչ makefile֊ները ոչ git֊ը չեն կարողանում նորմալ կառավարել կախուածութիւնները։ ու էդ օկ ա որովհետեւ էդ իրենց գործը չի։
ինձ էսօր պէտք ա makefile միայն երկու անգամ՝ որ հաւաքեմ voc֊ը ու որ voc֊ով հաւաքեմ vipack֊ը։
դրանից յետոյ makefile֊ներ այլեւս պէտք չեն։ git ենթամոդուլներ կամ ենթածառեր պէտք չեն ու միայն խանգարում են։
vipack ու միայն vipack֊ը այլեւս բաւական ա պրոյեկտներ շինելու համար։
vipack֊ը էն գործիքն ա որ պէտք ա, ու պէտք ա իրականում ոչ միայն ինձ ու ոչ միայն օբերոնի աշխարհում։
vipack֊ով կարելի ա եւ գուցէ պէտք ա շինել ամէն ինչ։
ես պարզապէս հասկանում եմ ինչքան հրաշալի գործիք ենք ստեղծել։ ու սկսուել ա ամէնը որպէս @shekspir55@xn–69a.xn–99axc.xn–y9a3aq ֊ի թէզ։
ու տէնց։
#vipack #voc #օբերոն
ուրեմն, էսօր տէնց օր էր։
նախ գնացի էդ գործարան։ էնտեղ այլ քսան տարի հնացած հաստոց կար, որ լինուքսով ա աշխատում՝ debian woody֊ով, դրա մասին կարծես գրել էլ եմ։
գնացի, տեսնեմ ինչի համար են կանչել՝ այլ հաստոց ա, մեեեեեեեեեեեծ, սովորական բնակարանում տեղ չէր անի, ու վրան ամէն կողմից գրուած ա՝ «pozor»։ ես գիտեմ որ դա չեխերէն «ուշադրութիւն» ա։
ու էնտեղ արտասահմանից եկած մարդ կար, որ էդ հաստոցները սպասարկո՞ւմ էր, չեմ իմանում ինչ էր անում։ ու մի ձեռք չունէր։ չեմ կարող չմտածել՝ հաստոցներից մէկն ա կտրել։
ասում եմ՝ «չեխերէ՞ն» ա, ասում ա՝ «հա, ես եմ չեխիայում ապամոնտաժել»։ ուրեմն, դիսկ են գտել հաստոցի մէջ ինչ֊որ պահարանում՝ ֆլոպի դիսկ։ ասում են՝ սրա մէջ երեւի ծրագիր կայ։ գնացի տուն, միացրի ֆլոպի ընթերցիչին՝ դրա մէջ ոչ բարձրաճաշակ նկարներ էին՝ նրբերշիկից սարքած արնանդամը դրանցից ամենազուսպն էր երեւի։ ա չէ, մէկ էլ կար ինչ֊որ նկարչի գրաֆիկա՝ ստորագրութեամբ։ էդ մարդը համ տէնց նկարներ էր հաւաքել, բայց եւ մի գեղանկարչութեան նմուշ։ ուրիշ բան չկար։ գրեցի էդ մարդկանց, ասացի որ սէնց վիճակ ա։ ասին՝ ուղարկի ֆայլերը։ ասում եմ՝ օգտակար բան չկայ։ ասում են՝ ուղարկիր համոզուենք։ դէ ուղարկեցի։
ու դէ ճանապարհը ահաւոր՝ լայն փողոցներ, աւտօյի տակ ընկած շներ, ահաւոր քշող մեքենաներ, փիլիսոփայի ասած՝ գաղջ մթնոլորտային ճնշում։
դրանից յետոյ մեր արուարձանի թափթփուած վիճակը եւ օդում լողող, սառը քամով քշուող ցելոֆանները սիրտ էին ջերմացնում։
յետոյ գնացի քաղաք ֆռֆռալու, գտայ ինձ հայկում, ինչ֊որ ոչ մի տեղ չէր հրապուրում, ընկերներս չեկան, նստեցի էն հետեւի մութ տեղում, գործ էի անում, նոյնիսկ հետաքրքիր գործ՝ ես տարուած եմ նրանով որ ամէնի պատմութիւնը լինի, ու օրինակ հանել եմ ulm oberon֊ի ամէն թողարկման փոփոխութիւնը որպէս առանձին git commit։
ու ունեմ shark oberon֊ի սորսը որ վերջերս հեղինակի git֊ում եմ գտել, նաեւ եսիմերբ ներբեռնած չեմ յիշում որտեղից, ու դրա հետնորդ olr֊ի բոլոր֊բոլոր վարկածները գտայ ներբեռնեցի։ archive.org֊ում նայում էի ինչ թողարկումներ են եղել, յղման անունով, նիշքը չեն պահել, ու չնայած յղումը փոխուել ա, նիշքերի անունները գիտէի, բոլորը նոր յղումով ներբեռնեցի՝ ենթադրեցի որ տեղափոխել ա նիշքերը, ու իսկապէս՝ բոլորը տեղափոխել ա, հները չի ջնջել։
իսկ ես ուզում եմ git պատմութիւն ստանալ shark oberon֊ից սկսած՝ բոլոր փոփոխութիւնները, զի արդէն գիտեմ ինչպէս օբերոնի ֆայլերը պահել git֊ում որ git diff֊ն աշխատի։
իսկ էնտեղ բարդ ա։ ինչ֊որ ֆայլի մէջ օրինակ լիքը բան պակասում ա, իսկ մի բան այլ ձեւ ա։ գուցէ կը մտածես՝ էն միւսի մէ՞ջ են աւելացրել, իսկ էդ տողերը չունեցողը հի՞նն ա, բայց ամէնն այդքան միանշանակ չէ բնաւ ու գուցէ մարդիկ ջնջել են կոդը, զի լաւն ա, բայց պէտք չի։ ու ուզում էի հասկանալ olr֊ն որի՞ց ա ժառանգել, սրանի՞ց թէ՞ նրանից։
ու ջոկեցի, օրինակ էսպէս՝
տող 315,
fixlist:=SYSTEM.LSH(cw, -13) MOD 8000H*4);
անյայտ սորսի մէջ էդ տողը քոմենթած ա, ու դրա վերեւից այլ ձեւ ա գրուած։ իրանք դէ վարկածների պատմութեան ծրագրակազմ չունէին։ ես ունեմ բայց մէկ ա սիրում եմ էդպիսի բաներ անել, մեկնաբանութեան մէջ թողնում, որ երեւայ առաջ ոնց էր, կամ գուցէ ապագայում ոնց էլի փոխել դա հաշուի առնելով։ իսկ ամենահին հրապարակուած olr֊ի ելատեքստի մէջ լիքը բան փոխել են, բայց այ էդ տողն ու մեկնաբանածը՝ կան։
հետեւաբար պարզ ա որն էր որից յետոյ։ ու ով ա ումից սորս ստացել։
ինչեւէ, մարդ չեկաւ ինձ տեսնելու, յանկարծ ընկերոջս քոյրն եկաւ, նստեց դիմացս, գործ արեց, միայն ասացինք իրար բարեւ, ու յետոյ հաւաքուեց՝ ասաց՝ մինչ, ու գնաց։ էնտեղ էլ փչում էր, ու ես սկզբից հուդին կոչկեցի, յետոյ կնգուղը (վերջերս թարգմանութիւն էի գտել, ո՞րտեղ էր, որ այլ էր, գլխաեսիմինչ էր… ա՛, յիշեցի, քիքոձէի թարգմանութեան մէ՛ջ էր, փորձում էի յիշել ու չյիշեցի) քաշեցի, մի պահ դէմքս չէր երեւում, էդ քոյրն էլ երեւի մտածում էր ոճի համար եմ անում։
յետոյ հասայ տուն, մրսած եւ այլն, ու կոմպենսացրի այսօրուայ դժբախտ մանկութիւնս երկու բաժակ արտակարգ իրլանդական թէյով եւ չրով։
իսկ դո՞ւք ինչ յաջողութիւնների էք հասել։ աշխատանքում եւ անձնական կեանքում։
#հետազօտութիւն #հնէաբանութիւն #պատմութիւն #գաղջ #առօրեայ #օբերոն #էկրանահան #հայկ #թէյ
երէկ ֆփերսընն ասաց որ յաւելուած գրելն իրան շատ ա տանում, ու մասնաւորապէս որովհետեւ մի մարդ կարող ա կիրառելի ու օգտակար յաւելուած գրել։
ես էլ մեկնաբանեցի, որ դա մարդու սանդղակին համապատասխան (human scale) (ֆփերսըն, այ այսպէս կարող եմ այլաբանութիւն օգտագործել) ծրագրակազմ ա։ երբեմն դրան ասում են lowtech։ դէ քաղաքներ կան մարդու սանդղակին, չափսին համապատասխան, փողոցներ՝ ուր փողոցը նեղ ա, ու աւելի կոմֆորտ ա։ ու պատահական չի որ փարփեցու փողոցը դարձաւ փաբերի ու սրճարանների փողոց՝ նեղ ա։ սարեանն էլ ա նեղ։ ու սարեանը կոր ա՝ հետեւաբար չես տեսնում անվերջութիւն, ու դա աւելի կոմֆորտ ա։ նոյն ձեւ հրապարակը եթէ շատ ա մեծ՝ տագնապում ես։
ու ասացի որ դրա համար եմ oberon֊ը սիրում՝ մի հոգի՝ գուցէ ես, կարող եմ մի ամսում քոմփայլեր գրել։
նա էլ ասաց թէ հա, նոյնը լիսպի հետ՝ երեւի ամէն լիսպիստ մի լիսպ գրել ա իր կեանքում։ (:
ես էլ յիշեցի որ gemini֊ն էլ ա մարդու սանդղակին համապատասխան՝ նախագծուած ա որ ամէն մարդ կարողանայ իմպլեմենտացնել հաղորդակարգը մէկ֊երկու օրում, ու օրինակ սպասարկիչ կամ դիտարկիչ գրի։
ահա, օրինակ, solderpunk֊ի՝ gemini ստեղծողի go իրականացում, հարիւր տողից քիչ կոդով՝
https://tildegit.org/solderpunk/gemini-demo-3
յ․ գ․ ապակենտրոնացումն ինչ լաւ բան ա՝ էսօր jabber.am֊ը չի աշխատում, բայց ես չոլ.հայ֊ի ժողովրդին տեսնում եմ ու կարող եմ չաթուել։
#յաւելուած #քաղաք #փողոց #հրապարակ #սանդղակ #մարդ #օբերոն #ջեմինի #լիսպ #ապակենտրոնացում
ուրեմն, voc֊ը պորտ եմ արել nvcc֊ի։
հետաքրքիր ա, սովորական aarch64֊ի gcc֊ով voc֊ը սարքում ա 11կբ չափսի, սովորական գրադարաններին դինամիկ կպած բինար։
nvcc֊ով սարքած բինարն ունի նոյն կախուածութիւնները ըստ ldd֊ի, բայց զբաղեցնում ա 623կբ արդէն։
inky@nv:~/test$ file test
test: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=cb4b973aac98318b8bdb993b3483c0ef1f44bf6c, with debug_info, not stripped
inky@nv:~/test$ file test_
test_: ELF 64-bit LSB shared object, ARM aarch64, version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=0395d6ca9fdc7104b4bb632c28d4b4ada98c9fd9, with debug_info, not stripped
inky@nv:~/test$ ldd ./test
linux-vdso.so.1 (0x0000007f823ca000)
libvoc-O2.so => /opt/voc/lib/libvoc-O2.so (0x0000007f821b9000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007f82060000)
librt.so.1 => /lib/aarch64-linux-gnu/librt.so.1 (0x0000007f82049000)
libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000007f8201d000)
libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000007f82008000)
/lib/ld-linux-aarch64.so.1 (0x0000007f8239e000)
inky@nv:~/test$ ldd ./test_
linux-vdso.so.1 (0x0000007fa0bda000)
libvoc-O2.so => /opt/voc/lib/libvoc-O2.so (0x0000007fa0956000)
librt.so.1 => /lib/aarch64-linux-gnu/librt.so.1 (0x0000007fa093f000)
libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000007fa0913000)
libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000007fa08fe000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007fa07a5000)
/lib/ld-linux-aarch64.so.1 (0x0000007fa0bae000)
inky@nv:~/test$ ls -lh
total 648K
-rwxrwxr-x 1 inky inky 11K Փտր 16 14:52 test
-rwxrwxr-x 1 inky inky 623K Փտր 16 14:51 test_
-rw-rw-r-- 1 inky inky 370 Փտր 16 14:52 test.c
-rw-rw-r-- 1 inky inky 371 Փտր 16 14:51 test.c_
-rw-rw-r-- 1 inky inky 76 Փտր 16 14:50 test.Mod
գեներացուած սի կոդի տարբերութիւնն այս տողն ա՝
inky@nv:~/test$ diff test.c test.c_
1c1
< /* voc 2.1.0 [2023/02/15] for gcc LP64 on ubuntu xtpam */
---
> /* voc 2.1.0 [2023/02/15] for nvcc LP64 on ubuntu xtpam */
inky@nv:~/test$
#օբերոն
սպեկտրումը ցոյց տուեց helix խմբագրիչը՝ շաատ հետաքրքիրն ա, կը սովորեմ։
ուզում ա դրան անցնի, ու սալիկային ինտերֆէյսի՝ զի աւելի յարմար ա քան vscode֊ը։
ես մտածեցի՝ էն գործառոյթն ինչ արդէն անում ա պատուհանների կառավարիչը, հիմա էլ մոնոլիտ ծրագրերն իրենք են իրականացնում, փոխարէնը մենք օգտուենք արդէն եղած եւ իրականացուած ձեւերից։
այսպէս մոնոլիտ ծրագրերով ինքներս ենք հեռանում իւնիքս գաղափարախօսութիւնից, նոյնիսկ այնտեղ ուր պէտք չի։
ես էլ ցոյց տուի acme խմբագրիչը, բայց արդէն ռոբ փայկը, դրա հեղինակը, հեռացաւ իւնիքս փիլիսոփայութիւնից իրանով՝ acme֊ն ոգեշնչուած էր oberon֊ի սալիկային ինտերֆէյսից։ ու այդ ինտերֆէյսը արդէն իսկ ծրագրաւորման եւ աշխատանքի եւ ամէնի միջավայր ա։ իսկ քանի որ acme֊ն աշխատում էր plan9֊ում՝ ուր արդէն կար պատուհանային կառավարիչ՝ ինքն իրականացրել ա պատուհաններ հէնց խմբագրիչի մէջ։
#միջավայր #տեք #իւնիք #օբերոն #միջերէս #նախագծում
դեռ 19֊րդ դարում օգտագործւում էր մորզէ կոդը՝ տեղեկատւութիւն տեղափոխելու համար։ մորզէն տպւում էր ոչ թէ a4 թղթերի վրայ, այլ թղթէ ժապաւէնի։ եւ խնդիր կար տողերն առանձնացնելու։ այդ համար օգտագործւում էր BT յաջորդականութիւնը։ նշանակում էր՝ breat text։ այսպէս էլ գրում էին տեքստի մէջ՝ BT՝ բնաւ ոչ անտեսանելի։
յետոյ, երբ եկաւ տելետայպների եւ թուանշային գրամեքենաների ժամանակը, այդ տեսակ նիշերը թաքցուեցին, դարձան անտեսանելի։
այսպիմի նիշերից մէկն ա cr֊ն, որը նշանակում ա՝ carriage return՝ կրողի վերադարձ։ եթէ տեսել էք տպագրական մեքենայ, գուցէ նկատել էք որ մեքենայի մի մասը կրում ա թուղթը։
տպելիս կրող մասը շարժւում ա աջից ձախ (քանի որ մենք գրում ենք ձախից աջ) որ ամէն նոր նիշը տպուած լինի թղթի նոր տեղում։
եւ երբ տողն աւարտուած ա լինում, պէտք ա վերադարձնել թուղթը ելքային դիրք։
թուանշային տպագրական մեքենաներում այդ համար մտածել են հատուկ անտեսանելի նշան, անունը՝ cr, որ երբ մեքենան հանդիպի այն, կրողը կը վերադարձնի թուղթը ելքային դիրք։ այդ անտեսանելի նիշի համարը ascii աղիւսակում տասականով 13 ա, իսկ տասնվեցականով՝ 0d։
windows֊ում տողադարձը նշւում ա երկու անտեսանելի նիշով, cr ու lf։ վերջինը նշանակում ա՝ line feed։ եթէ cr֊ը վերադարձնում ա թուղթը աջ, կամ հետեւաբար կուրսորը՝ ձախ, ապա lf֊ն բարձրացնում ա տողը, կամ կարգիչներում՝ իջեցնում կուրսորը։
այս անտեսանելի նիշի համարն ա, տասականով՝ 10, տասնվեցականով՝ 0a։
իսկ իւնիքս համակարգերում ձեւաւորուեց այլ աւանդոյթ՝ ամէն տողի վերջում երկու բայթ չզբաղեցնելու համար պարզապէս օգտագործուել ա lf֊ն՝ որպէս տողադարձի նշան, տողի վերջի նշան։
գոյութիւն ունի եւ երրորդ աւանդոյթ՝ գրել միայն cr եւ հասկանալ նոյնը՝ տողադարձ։
այդպէս էր ընդունուած անել commodore, spectrum դասական ութ բիթանի համակարգիչներում, ու գուցէ այդ պատճառոջ էլ այդպէս էր ընդունուած apple ][֊ում, իսկ հետագայում՝ macintosh համակարգում։ խօսքը հին, այսօր «դասական» կոչուած macos֊ի մասին ա։ cr֊ն նաեւ օգտագործւում էր այսպէս կոչուած «լիսպ մեքենաներում», եւ՝ «օբերոն» օպերացիոն համակարգում։
նոյնիսկ վերջին թարմացման ժամանակ, project oberon 2013֊ում, վիրտը կրկին օգտագործել ա 0d֊ն որպէս տողի աւարտի նշան։
ահա, այս նիշքի սկզբում գրուած ա՝
TAB = 9X; CR = 0DX;
TextTag = 0F1X;
replace* = 0; insert* = 1; delete* = 2; unmark* = 3; (*op-codes*)
եւ գրել ա յատուկ Tools.convert() ֆունկցիան, որպէսզի 0d տողադարձով նիշքերը փոխակերպի հրապարակման համար։
մինչ այդ, lilith համակարգիչներում, ըստ երեւոյթին օգտագործւում էր lfcr յաջորդականութիւնը՝ 0d յետոյ 0a։ յամենայն դէպս օրիգինալ կոմպիլեատորի ելատեքստում այդպէս ա։
այսպիսի փախած կոդաւորում էր միայն առաջին arm համակարգիչներից մէկում՝ acorn bbc֊ում, որ աշխատում էր risc os֊ով։ այսօր risc os֊ը կարելի ա օգտագործել raspberry pi֊երի վրայ, զի arm ա։
իմ խնդիրն էր՝ ես ուզում էի խմբագրել, աշխատել օբերոն համակարգի ելատեքստերի վրայ եւ կարողանալ օգտագործել որեւէ control revision կոդի համար։
օբերոն նիշքերն ունեն երկու հիմնական խնդիր՝
git֊ն ընկալում ա ֆայլը որպէս բինարcr ա։ի՞նչ եմ ուզում՝ ուզում եմ կարողանալ կոնսոլում անել git diff ու համեմատել վարկածները։ որ github֊ի, gitlab֊ի, gitea֊ի վեբ ինտերֆէյսները կը կարողանան ցոյց տալ ռեւիզիաների տարբերութիւնները՝ յոյս չէի փայփայում։ կոնսոլում աշխատի՝ լաւ ա։
git֊ն ունի երկու մեզ հետաքրքիր հնարաւորութիւն՝ text ու diff։
text֊ն այն մասին ա, ինչպէ՞ս պահել, ներմուծել նիշքը git֊ի տուեալների բազա (այն որ .git պանակի մէջ ա)։
diff֊ն այն մասին՝ ինչպէս համեմատել տողեր։
ես սկզբից դա չէի հասկացել, ու փորձում էի աւելացնել .gitattributes նիշքի մէջ՝
*.Mod text
*.Mod eol=cr
text eol=cr
առաջին տողով ուզում էի ասել, որ ֆայլը բինար չէ։ պարզուեց՝ անիմաստ, զի յետոյ հասկացայ, որ դա ընդամէնը կապ ունի նրա հետ, ինչպէս տեքստը լցնել տուեալների բազայի մէջ՝ կոնուերտե՞լ տողադարձը lf թէ՞ չէ։ ըստ որում, պարզւում ա, cr տարբերակը git֊ը չի հասկանում։ կարելի ա ասել՝ crlf, բայց մեր դէպքը ելատեքստում նախատեսուած չի։
նաեւ փորձեցի արդեօք կաշխատի diff֊ը։ .gitattributes֊ում այսպիսի տող փորձեցի՝
*.Mod diff eol=cr
ու չօգնեց, զի կրկին՝ cr կարգաւորումը նախատեսուած չի, handle չի լինում, ելատեքստում չկայ։
ահա այսպէս էր տարբերութիւնը ցոյց տալիս՝
ամբողջ ֆայլի պարունակութիւնը մի վարկածից ու մի տողով, ու յետոյ ամբողջ միւս ֆայլի պարունակութիւնը, մի տողով։
արդէն յուսահատուել էի։ git֊ը կարգաւորում չունի։ մտածեցի՝ կարո՞ղ ա mercurial֊ն ունենայ։
արագ գտայ, որ mercurial֊ն ունի eol extension բայց, աւաղ՝
Older versions of Mac OS used CR (\r), but Mac OS X is Unix and uses LF. This extension does not support the old CR format.
չկպաւ։ :/
մտածեցի՝ բայց հին մակօսի կոդերի հետ մի ձեւ աշխատում են չէ՞։ ու սկսեցի փնտրել։ եւ գտայ այս շղթան։
այնտեղ առաջարկւում էր ստեղծել զտիչ՝ convert-cr անունով, ու սահմանել այն։ նաեւ առանձին մեկնաբանութիւնը վերաբերում ա diff֊ի համար կարգաւորմանը։
փորձում եմ, ինչպէս խորհուրդ ա տրւում, աւելացնել .git/config նիշքում՝
[filter "convert-cr"]
clean = tr '\r' '\n'
smudge = tr '\n' '\r'
բայց ապա յետոյ git֊ը չի աշխատում, ասում ա՝ կոնֆիգում սխալ կայ։
fatal: bad config line 13 in file .git/config
մտածում եմ, ո՞նց անել։
յետոյ ջոկեցի՝ աւելացրի հրամանային տողից այսպէս՝
git config filter.convert-cr.clean "tr '\r' '\n'"
git config filter.convert-cr.smudge "tr '\n' '\r'"
իսկ այս տողը շղթայում այսպէս էլ տուեցին՝
git config diff.cr.textconv "tr '\r' '\n' <"
դրանից ջոկեցի ինչպէս անել։
ահա, փաստօրէն .git/config֊ում աւելացրել եմ՝
[diff "cr"]
textconv = tr '\\r' '\\n' <
[filter "convert-cr"]
clean = tr '\\r' '\\n'
smudge = tr '\\n' '\\r'
հետեւեալ հրամաններով՝
git config diff.cr.textconv "tr '\r' '\n' <"
git config filter.convert-cr.clean "tr '\r' '\n'"
git config filter.convert-cr.smudge "tr '\n' '\r'"
.gitattributes֊ում գրեցի՝
*.Mod filter=convert-cr
*.Text filter=convert-cr
փորձեցի կրկին քոմիթ անել, ու համեմատել քոմիթը՝ չկպաւ։
ապա յիշեցի, այս անգամ աւելացրի .gitattributes֊ում՝ *.Mod diff eol=cr ու այն այսպիսի տեսք ունեցաւ՝
*.Mod filter=convert-cr
*.Text filter=convert-cr
*.Mod diff eol=cr
ու հա՛, աշխատե՛ց։
հիմա կարող եմ օբերոն ֆայլերի հետ գործ անել։
#օբերոն #էկրանահան #գիտ #ծրագրաւորում #պատմութիւն #հետազօտութիւն #տեք #կարգաւորում #ձեռնարկ #կարգիչ
>Loading the binary is done with dlopen(), and therefore the application needs to be compiled and linked as a shared library or a position independent executable.
երեսուն տարի անց սկսեցին ծրագիրը շինել որպէս բեռնուող մոդուլ, օբերոնի պէս։
#սէյլֆիշ #օբերոն #տեք
freepascal կոմպիլեատորում աւելացրին երկու նոր հնարաւորութիւն՝ function references ու anonymous functions՝
https://forum.lazarus.freepascal.org/index.php?topic=59468.0
նայեցի, ոնց հասկանում եմ, նման բան կայ օբերոնում, միշտ կար, եւ օբերոնի էական յատկանիշ ա։ այսպէս ա կարելի օօծ ֊ի ոճով գրել՝ դաշտի տիպը սահմանել որպէս անանուն, կամ նախապէս ձեւակերպուած ֆունկցիա։
պասկալ կոմպիլեատորները (չեմ ասում պասկալը, զի պասկալն ունի իսօ ստանդարտ, որը շուկայում եղած կոմպիլեատորները չեն իրականացնում) տրամադրում էին c++֊ի վիրտուալ ֆունկցիաների ձեւով՝ տիպին կպած ֆունկցիաների, կամ մեթոդների, օօծ անելու հնարաւորութիւն։
վիրտն այդ ձեւն ա համարում ոչ էական, ոչ հիմնային։ նա, սակայն, ստորագրել ա օբերոն֊2 թղթի տակ, ուր իր աշակերտը նման ձեւի օօծ աւելացրել ա։ ես, ի դէպ, բարեյաջողղ օօծ եմ օգտագործում առանց մեթոդների։
եւ ահա, այդ հիմնային, էական ձեւն են էսօր աւելացնում fpc֊ում, զի համարում են, որ այն ինչ֊որ դէպքերում օգտակար կը լինի։ եւ աւելացրին ամենաբարդ, ամենաանհասկանալի ձեւով։
չիմանաս ինչ ա (եթէ իմանում եմ) , կը մտածես շատ քուլ, շատ բարդ բան ա։ ուղեղդ կաշխատեցնես երկար, որ հասկանաս ոնց ա աշխատում եւ երբ օգտագործել։ երբ հասկանաս, կը մտածես որ շատ խելացի ես, երեւի, որ էդքան ջանք դրեցիր ու հասկացար։ բայց էլի կը մոռանաս շուտով։
ես կը մոռանամ՝ էդքան բարդ ա։
իսկ օբերոնում սա հիմնային ա, շատ հասկանալի, ու շատ պարզ ա կիրառւում։ իսկ այլ լիքը բան չկայ, զի լեզուի ստեղծոէները էական չեն համարել։
#պասկալ #օբերոն
դիեգօն օբերոնի չաթում պատմեց այս դէպքի մասին՝ քսան տարի չէին նկատում որ փակագիծը սխալ տեղ են դրել, ու իմաստը փոխուել ա։
նա նշեց որ սա հնարաւոր ա հէնց սի֊ում։ ու մեր ծրագրաւազմի զգալի մասը սի֊ով ա գռուած։ աւելի ժամանակակից լեզուով, ու իհարկէ օբերոնով նման սխալ հնարաւոր չի։
#օբերոն #սի #վրիպակ #տեք #ծրագրաւորում #էկրանահան
ո՛նց չասեմ՝ իսկ վիրտն այդ խնդիրը լուծել էր դեռ ութսունականների վերջի օբերոնում։
#օբերոն #տեք #ծրագրաւորում #իւնիքս #լոտուս #էկրանահան
վիրտի cpu֊ի ու կարգչի հիման վրայ նախագծեր՝
https://riskfive.com/Web_resources.htm
#օբերոն #երկաթ #նախագծում
այստեղ #օբերոն պիտակով թողնեմ, որ յետոյ հեշտ գտնեմ՝
https://conf.tube/videos/watch/8479099c-2247-4904-a5df-1f540c1af7fb
տեղափոխում են op13֊ի օբերոն համակարգը risc-v֊ի վրայ։
բռունցքն ինձ ցոյց էր տալիս իր արդուինօները, ու ասում էր, որ սիրում ա դրանք՝ պարզ են, օհ չունեն։ գրում ես՝ կատարում են։
ու շատ ոգեւորեց, իրականում։
նաեւ, աւելացնեմ, օհ֊ի «օվերհեդ» չունեն, որն ունի լինուքսը, կամ թէկուզ զէֆիրը։
նաեւ, ռասփբերին անհամեմատ աւելի շատ հոսանք ա վառում։ ես ժամանակին համեմատում էի, adafruit֊ը արեւային պանելներ էր ծախում, որ կարողանում էին սնել arduino, կամ ասենք, avr atmel֊ով տպասալ, բայց raspberry pi֊ի համար դա շատ շատ շատ քիչ ա։
երբ raspberry֊ն դուրս եկաւ, ես ուրախացայ՝ զի մանկուց ունեմ վախ առանց կարգիչ մնալու, ու դա էժան համակարգիչ ունենալու ձեւ ա, միւս կողմից տխրեցի՝ զի մարդիկ, որ նախկինում պէտք ա աւելի ցածր մակարդակի գործ անէին arduino֊ով, կանեն պայմանական փայթընով կամ ջս֊ով նոյն նախատիպերը՝ raspberry֊ի վրայ։
(նաեւ, էսօր ասում էի ուսանողներին, երբ ասեմբլեր կոդ էինք գրում, ախր շատ հեշտ բան ա ասեմբլերը, մանաւանդ risc պրոցեսորի ասեմբլերը։ էնպէս չի որ սիրում եմ, չեմ կարծում որ պէտք ա դրանով ամէնը գրել՝ ու առհասարակ, իրանով ամէն ինչ ա կարելի անել, իսկ ես սահմանափակումներ եմ սիրում։ բայց պարզ ա, իրականում, շատ աւելի պարզ ա, երբ 35 ինստրուկցիա սովորելով կարող ես գրել ամէն ինչ, քան c++ սովորելով կարող ես գրել ամէն ինչ։)
հա, պարզ ա, ասում ա։ ու էներգախնայող։
ու ապա կրկին գալիս եմ օբերոն օհ֊ի յանճարին, երբ քանի որ այն «սինգլ թրեդ» օհ ա, դու չունես օվերհեդ։ ո՞ր կոդն ա պէտք կատարուի, կատարւում ա լրիւ քամելով ռեսուրսները երկաթի։ բայց օհ ունես, ունես աբստրակցիաներ, ունես տիպերի ստուգում, ունես դինամիկ մոդուլների բեռնում, շատ բան ունես։ եւ չի ծախսում յիշողութիւն։ դէ պարզ ա։ չունի շատ ֆունկցիոնալ, ակնյայտօրէն լինուքսի պէս ճկուն չի, բայց պարզ ա, փոքր, էներգախնայող։
#անկապ #արդուինօ #ռասփբերի #փայ #երկաթ #տեք #պարզութիւն #մինիմալիզմ #օբերոն
եօթուբիս ալիքը ջնջել եմ, սա անգլերէն ձայնագրեցի տուբնիքսի համար։
իմ հայերէն վիդեօ ալիքը դաշնեզերքում ինքս եմ սելֆ հոստ անելու, էնտեղ էլ նման բաներ կանեմ։
երբ սեթափ անեմ փիըրթիւբը իհարկէ։
https://toobnix.org/w/8p8GVqLpsJAVpZUpHssjZL
#օբերոն #տեղակայում
#օբերոն #օհ #տեք
https://www.youtube.com/watch?v=OJGnpmnXR5w
#օբերոն #օպերացիոն_համակարգեր
ինչքան լաւ միտք ա ինձ թւում օբերոնի մի պահին մի բան աշխատեցնելը՝
ես օրինակ հիմա քանի հատ պդֆ ունեմ բացած։
էդ պդֆ֊ների ընթերցիչները միշտ լուփի մէջ, ու միշտ շատ քիչ, բայց ռեսուրս են պահանջում։
դասական օբերոն համակարգում դրանց պրոցեսորի ժամանակ երբէք չէր յատկացուի։ էդպէս բացաց կը մնային, մինչեւ չկպնէի էդ թղթերին։
նոյնը վեբ էջերի հետ։ ճռռում են, զի ջս֊ը պիտի շարունակի աշխատել։ գոնէ ստոպ անէին ջս֊ները։ իրականում ես եմ ստոպ անում ֆֆ֊ի ընդլայնումով, չօգտագործուող էջերը։ անում եմ էն, ինչ համակարգը չի անում։ իրականում ունեմ STOP սիգնալ, բայց ոչ մի միջավայր՝ գնօմը, կդէն, չեն որոշում ուղարկել STOP ծրագրերին, որովհետեւ որպէս կանոն համարւում ա որ դա պէտք չի։
բայց ես կուզէի ոնց ունեմ պատուհանների ցանկ, կարողանայի այդ ցանկում նշել որ ծրագրերն են ազատ կանգնեցուելուց։ մնացածը, եթէ մի քանի րոպէ դրանց հետ չես զբաղուել, օհ֊ը կանգնեցնէր։
#օբերոն #գնօմ #օպերացիոն_համակարգեր #օհ
դեւինը գրել էր որ օփենսթեփում սքրոլբառերը ձախից են։
յետոյ գտաւ այս թուղթը ուր բացատրում են, ինչի են սքրոլբարները հիմնականում աջից տեղակայում։
յետոյ ցոյց տուեց ակմէ֊ի ինտերֆէյս ուր դրանք ձախից են։
ես էլ ցոյց տուի, որ օբերոն օհ֊ում էլ են ձախից, ու դէ ակմէն ոգեշնչուած ա դասական օբերոնի ինտերֆէյսից։
#նախագծում #օբերոն #դիզայն #ինտերֆէյս #միջերես
յէ՛յ։
irc_bot֊իս կախուածութիւնները ջոկում ա։ (:
#փաթեթների_կառավարում #փաթեթային_կառավարիչ #վիպակ #օբերոն #էկրանահան #կախուածութիւն #ծառ #վիշապ #ծրագրաւորում #էհ
չդիմանամ, կիսուեմ ձեզ հետ։
էդուարդ ուլրիխն ուղարկել ա ինձ իր օբերոն համակարգից էկրանահաններ, աւելացրել ա իւնիկոդի սատարում՝
#օբերոն #օպերացիոն_համակարգեր #լեզու #տառատեսակ #հայերէն #էկրանահան
օօծ֊ի գինն ու առաւելութիւնները (costs and benefits of oop) լոյս ա տեսել որպէս առանձին թուղթ, ու այս գրքի 12֊րդ գլուխն ա, 215 էջում։
թուղթը բարդ ա ճարել, գիրքը ես առել եմ։ ռուսալեզու լսարանն արտօնեալ էր՝ վոլոգդայի համալսարանը, ուր սուերդլովն ա աշխատում, թարգմանում եւ հրապարակում էր շատ օբերոնին վերաբերող թղթեր, եւ կայ նաեւ այս յօդուածի ռուսերէն թարգմանութիւնը։
#օբերոն #օօծ #ծրագրաւորման_լեզուներ #ծրագրաւորում #թուղթ #գիրք
մէկին փորձում էի բերել sdf֊ի համայնք, ու դրա համար պէտք ա ընդամէնը մի բան, բացել տերմինալ եւ գրել՝ ssh new@sdf.org։
բայց քանի որ ուինդոուսում ա էս մարդը, ու ssh անելու փորձ չունի (որը կրկին մեր կրթութեան մասին ա, ո՞նց ա որ քանի տարուայ ուսանողին երբեք պէտք չի եղել ոչ մի տեղ ssh֊ուել) միասին առցանց տառապեցինք։
ասի՝ քաշիր putty։ քաշեց ինչ֊որ այլ ուինի համար ssh կլիենտ։ bitvise՞ ոնց որ։ ես դէ էկրահաններով բնաւ չհասկացայ ոնց դրա հետ աշխատել։ լիքը կոճակներ, լիքը դաշտեր եւ տաբեր։ յետոյ քաշեց իսկական փութին։
դրանով կպաւ։
ու սա շատ պարզ ա նկարագրւում՝ ինտերակտիւ հաղորդակցութիւն մեքենայի հետ, ընդդէմ աւտոմատիզացիայի։
կամ ժեստերո՞վ ենք խօսում (կոճակ ենք ընտրում սեղմելու համար) թէ՞ յստակ գրում ենք ինչ ենք ուզում։
էստեղ օբերոնի մշակոյթն էլ աւելի յարմար ա՝ ձեռնարկն ու հրամանը առանձին չեն՝ ձեռնարկը բացում ես՝ հրամանների ձեւերը մէջը կան, ու մեկնաբանուած են՝ պարզապէս քեզ պէտք եղած հրամանի վրայ կտացնում ես։ ու եթէ արգումենտ ա պէտք տալ, կարող ես արգումենտը «սելեքթ» անել այլ պատուհանի մէջ։ ճիշտ ա, մի քանի արգումենտ տալ չես կարող, պիտի գրես։
օրինակ, իմ irc_bot֊ը հիմա պահանջում ա լիքը արգումենտներ՝
vocbot -h irc.libera.chat -p 6667 -o inky -u mobot -n mobot_ -r '#test' -w 'SECRET'
բայց էսպէս իհարկէ ծրագրերն աւտոմատացւում են՝ կարող ես կանչել սկրիպտի միջից՝ արա սա ու սա։ այն քեզ ամէն անգամ չի հարցնում՝ իսկ էս ի՞նչ անեմ։ իսկ սա՞։ դու ամէնը ասում ես։
օրինակ, վերցու էս հոսքից երրորդ դաշտը, դարձրու բոլոռ տառերը փոքրատառ, վերագրի փոփոխականի՝
VAR=`cat /dev/something | awk -F ":" {'print $3'} | tr A-Z a-z`
իսկ օբերոնում առհասարակ «սկրիպտ» հասկացութիւն պէտք չի՝ նոյն հրամանը (մոդուլի ֆունկցիան) կարող ես կանչել եւ «կոնսոլից»՝ ամէն տեղից, մի տեղ գրած լինի, կտացնես վրան, եւ նոյն ֆունկցիան կարող ես կանչել քո ծրագրից։
#իւնիքս #աւտոմատացում #կոնսոլ #տեքստ #օբերոն #սկրիպտ #ինտերֆէյս #մշակոյթ
ես՝ oberon֊ը հաւէսն ա հէնց նրանով որ single threaded օպերացիոն համակարգ ա։
էլի ես՝ maemo֊ն հաւէսն ա նրանով որ իսկական բազմախնդիր համակարգ ա, տեսնում ես միաժամանակ՝ էս պատուհանում ֆիլմ ա ցոյց տալիս, էն պատուհանում չաթն ա թարմանում, եւ այլն։
#անկապ #տեք #օպերացիոն_համակարգեր #օբերոն #մաեմօ
https://www.youtube.com/watch?v=8K84aG72Dw8
#օբերոն
հաւէս յօդուած ա սա շատ՝ https://www.joelonsoftware.com/2001/12/11/back-to-basics/
իսկ օբերոնում վիրտը որոշել ա հրաժարուել պասկալական տողերից, ու կիրառել զրօյով աւարտուող տողեր։
սակայն, էդ տողերով կարիք չկայ միշտ վազել չափն իմանալու համար։ առանձին դաշտ էլ պէտք չի օգտագործել ու յիշողութեան մէջ մի տեղ պահել չափսը՝ քոմփայլերը գիտի տողի երկարութիւնը։
ու քոմփայլ թայմ թեստ կարող ա անել։ դիցուք վերցնենք էս ելատեքստը՝
MODULE tst;
IMPORT Out;
VAR i: SHORTINT;
str: ARRAY 1024 OF CHAR;
BEGIN
FOR i := 0 TO LEN(str) DO
Out.Int(i, 0); Out.Ln
END;
END tst.
այն քոմփայլ չի լինի՝
[2020-09-02 16:00:20] $ voc -m tst.Mod
tst.Mod Compiling tst.
9: FOR i := 0 TO LEN(str) DO
^
pos 102 err 113 incompatible assignment
Module compilation failed.
[2020-09-02 16:00:21] $
voc֊ը որ դէպի C ա թարգմանում սորսը, շատ լաւ ա պատկերելու համար։ եթէ մենք ունենք՝
str: ARRAY 16 OF CHAR;
ապա ելքային C կոդը կը լինի՝
static CHAR tst_str[16];
միայն դա։
իսկ
FOR i := 0 TO LEN(str) DO
կը թարգմանուի որպէս՝
tst_i = 0;
while (tst_i <= 16) {
Երբ մենք գրում ենք տողի հետ աշխատող ֆունկցիա, մենք կարող ենք չիմանալ փոխանցուող տողի երկարութիւնը՝
MODULE tst2;
PROCEDURE addStrs(VAR a, b: ARRAY OF CHAR);
BEGIN
(* do smth useful here *)
END addStrs;
PROCEDURE test*;
VAR
s0: ARRAY 32 OF CHAR;
s1: ARRAY 64 OF CHAR;
BEGIN
addStrs(s0, s1);
END test;
END tst2.
եւ ապա սի կոդը կը լինի՝
static void tst2_addStrs (CHAR *a, ADDRESS a__len, CHAR *b, ADDRESS b__len)
{
/* here we think we can do smth useful */
}
void tst2_test (void)
{
CHAR s0[32];
CHAR s1[64];
tst2_addStrs((void*)s0, 32, (void*)s1, 64);
}
այսինքն՝ ֆունկցիան ստանում ա նաեւ տողի երկարութիւնը։ ու եթէ անել LEN(a) անմիջապէս՝ առանց ոչ մի հաշուարկ՝ ստանում ես տողի երկարութիւնը։
ապա ինչպէ՞ս են աշխատում դինամիկ տողերը։
MODULE tst3;
PROCEDURE addStrs(VAR a, b: ARRAY OF CHAR);
BEGIN
(* do smth useful here *)
END addStrs;
PROCEDURE test*(i: INTEGER);
VAR
s: ARRAY 32 OF CHAR;
ps: POINTER TO ARRAY OF CHAR;
BEGIN
NEW(ps, i);
addStrs(s, ps^);
END test;
END tst3.
ունենք մի հատ ստատիկ տող՝ s ու մի հատ դինամիկ տողի ցուցիչ՝ ps։
ps֊ի չափսը կը ստանանք որպէս ֆունկցիայի արգումենտ՝ էս պահին մեզ անյայտ ա։
առաջին ֆունկցիան մնում ա անփոփոխ, երկրորդը թարգմանւում ա սէնց՝
static void tst3_addStrs (CHAR *a, ADDRESS a__len, CHAR *b, ADDRESS b__len)
{
/* do smth useful here */
}
void tst3_test (INT16 i)
{
CHAR s[32];
struct {
ADDRESS len[1];
CHAR data[1];
} *ps = NIL;
ps = __NEWARR(NIL, 1, 1, 1, 1, ((ADDRESS)(i)));
tst3_addStrs((void*)s, 32, (void*)ps->data, ps->len[0]);
}
_NEWARR֊ն արդէն մի քիչ բարդ ֆունկցիա ա, որը ռանթայմի մաս ա։
բայց ընդհանուր առմամբ պարզ ա ինչ ա անում՝ հիփ֊ի մէջ ալոքէյթ ա անելու տող, եւ մեր ստացած ցուցիչն արդէն struct֊ի ա, որն ունի data դաշտ եւ len դաշտ։
սա ռանթայմ տեղեկատւութիւն ա, ու այս դէպքում արդէն մեզ պէտք ա պահել առանձին դաշտ տողի երկարութեան համար։
ու տէնց։
#օբերոն #ծրագրաւորում #տող #տողեր #պասկալ #սի #վիշապ #իրականացում #կազմարկում #կոմպիլյատոր #կոմպիլեատոր #կազմարկիչ
@{antranigv; antranigv@spyurk.am}֊ը գրել ա dtrace֊ով voc֊ով կազմարկած ծրագիրը հմմմ… թրէյսելու մասին՝ https://antranigv.am/weblog/posts/dtrace-voc-experiment/
#օբերոն #վօկ #վիշապ #յօդուած
ասք էնկապսուլեացիայի մասին՝ https://github.com/vishaps/vipack/commit/e6823cb373c80222acc5d8adcf56f72ec7449a01 #օբերոն #վիպակ #վիշապ
առհասարակ, aarch64 հրամանների բազմութիւնը (ISA) կապ չունի 32 բիթանի արմ պրոցեսորների հետ։
սակայն փայնբուքի միջի սիփիուն կարողանում ա երկու ռեժիմում էլ աշխատել։
#օբերոն #էկրանահան #փայնբուք
ես ասում եմ, որ օբերոնով գրուած ծրագիրը (եթէ SYSTEM օգտագործուած չի) ունի միայն երեք պայթելու ձեւ։
երէկ rust֊ի մասին էի նիւթեր կարդում։ մի ձեւ ասին ծրագիր սպանելու, որ սի֊ում աշխատում ա, ռաստ֊ում չի աշխատի։ դա սթեքի մէջ օբյեկտ ստեղծելն ա, ու յետոյ դրա փոյնթերը վերադարձնելն ա որպէս ֆունկցիայի արդիւնք։ բնական ա, որ սթեքը կը մաքրուի, ու այն ցոյց ա տալու ոչ էն բանի վրայ, ինչի վրայ նախատեսուած ա։
ու ապա մտածեցի՝ իսկ օբերոնում ո՞նց կը լինի։ սկսեցի գրել, ու մտքովս անցաւ՝ բայց չէ՞ որ օբերոնում հէնց NEW անեմ՝ հիփ֊ում ա օբյեկտ ստեղծուելու։ ու ապա էլ էդ խնդիրը չի լինի։ յետոյ մտքովս անցաւ, որ ախր՝ կարող եմ չէ՞ սթեքին ցոյց տուող փոյնթեր սարքել այսպէս՝
MODULE test;
IMPORT Out;
TYPE
arr = ARRAY 16 OF CHAR;
string = POINTER TO arr;
PROCEDURE str(): string;
VAR
a: arr;
s: string;
BEGIN
a := "aaa";
s^ := a;
RETURN s;
END str;
PROCEDURE main;
VAR st: string;
BEGIN
st := str();
Out.String(st^); Out.Ln;
END main;
BEGIN
main;
END test.
ահա այս ծրագիրը պայթելու ա։ բնականաբար։ բայց մտածում եմ, լրիւ կարելի ա դա քոմփայլ թայմ բռնել ու մարդուն գոնէ զգուշացնել, եթէ ոչ՝ սխալով դուրս թռնել կազմարկելու ընթացքում։
#ծրագրաւորում #օբերոն #rust #տեքնոլոգիա #դիզայն #նախագծում #լեզու
սկրիպտ եմ գրում, ու մտածում եմ, ինչ յարմար կը լինէր շելլից էդ սկրիպտի տարբեր ֆունկցիաներ կանչել, պարամետրերով։
ու ջոկում եմ, որ էդ արդէն օբերոնում արուած ա։ մարդը մտածել ա։
իսկ բաշում էլի ձեւ կայ, բայց պէտք ա source myscript && myfunc smth, փոխարէնը կոկիկ myscript.myfunc smth֊ի։
#օբերոն
վիդեօներ օբերոնական կոնֆերանսներից՝ https://www.video.ethz.ch/search-results.html?query=oberon&x=13&y=11
մի երկու տարի առաջ մկգաւ֊ն ինձ գրել ա որ վօկ ա օգտագործում։ (: #օբերոն
էսօր քամուն ասում եմ, ջաբերում նորութիւններ ունենք, սէնց ու սէնց բաներ ենք աւելացրել, էլ տելեգրամին չի զիջում, աւելի լաւն էլ ա, ասում ա՝ ինձ էդ ամէնը պէտք չի։
ու ես ուզում եմ ասել, որ ինձ թուում ա, որ երբ մարդուն պէտք չի՝ էդ իր զարգացման մասին ա։
ու երբ վիշապի դէյւի հետ խօսում էինք, էլ ինչ անենք վօկ֊ում, ու ես առաջարկեցի ջեներիկներ իրականացնել, նա ասաւ՝ խնդրում եմ հաւատայ իմ փորձին, դրանցից աւելի շատ խնդիր ա, քան օգուտ։
ու վիրտն էլ ա տէնց, ու վիրտն էլ ա ահաւոր զարգացած։
երէկ էլ սոնայի հետ էի խօսում, ասում էի՝ ո՞նց ա էն շէնքը, ո՞նց են սարքել, ասում ա՝ դէ աւելորդութիւններ կան։ զգում ես պատասխանից՝ աւելորդութիւններն ա նշում։
#օբերոն #նախագծում #ճարտարապետութիւն #վիրտ #վիշապ #ճաշակ #զարգացում #մարդիկ #զրոյց #դիզայն #աւելորդութիւն #աւելորդութիւններ
օբերոնի փաթեթնեկի կառավարիչ։
#օբերոն #տտ #ծրագրաւորում
@{ Րուփեն ; shekspir55@spyurk.am} 12.05.2019, 12:54:32
Sneak peek
The fastest package manager ever yet created :D @{inky, from the tape; tanakian@spyurk.am} զգա մի հատ։Դ
#ծրագրաւորում #տտ #հարցազրոյց #օբերոն
@{ քամի ; o_o@spyurk.am} 30.04.2019, 10:09:18
վիրտի հարցազրոյցից ա։ առաջին մասում հետաքրքիր ա, թէ ոնց ա խօսում մարդու մասին, որն իր վրայ ազդել ա ու որպէս դրական յատկանիշ նշում պարզ մտածելը։ ու դա էլ, իր տրամաբանութիւնն ա։ երրորդ մասում խօսում են քըմփայլերներից, լեզուներից եւ այլն։ ջաւային չեն տշում, ուրախ եմ, իսկ սիին ու սիպպ֊ին տաշըմ ա։ ինչեւէ, հետաքրքիր ա,
ու նա, որ ասում ա՝ համալսարանները չեն ստեղծում նորը, այլ հին զիբիլի՝ սիի, սիպպի վրայ են հիմնւում, սրա հիմնական պատճառն այն ա, որ համալսարանները, ոչ միայն հայաստանում՝ ամէնուր, հիմնւում են շուկայի վրայ։ իսկ շուկայի վրայ հիմնուելով դու չես ստեղծում նոր բան, դու զուտ եղած ռեսուրսներով խոշոր ընկերութիւն կարող ես ունենալ, որոնց արտադրանքը միեւնոյն ա մեծ ազդեցութիւն չի ունենալու ու շեշտը դնելու ա սպառման վրայ։ միւս կողմից էլ ուղեղս չի ձգում, թէ այսուհետ ոնց ա հնարաւոր շտկել, գուցէ ճիշտը զուգահեռ նոր բան անելն ա։ ու նա, որ ասում ա, պէտք չի զրոյից սկսել, հիմքը կայ, աշխատանքը գնահատել ա պէտք։ մտածում եմ, որ իրօք, նա թողել ա օբերոն օհ֊ը, որն իրօք նոր ա, նոր միտք, բայց իմացողները նոյնիսկ չաշխատելով դրա վրայ նպաստում են հետընթացին։ ու նոյնիսկ ես, որ քննադատում եմ շուկան, ես չեմ սկսում օբերոն նայել՝ զուտ նայել, որովհետեւ հասկանում եմ, որ եթէ նայեմ օրինակ գոուն, ես յետագայում աւելի մեծ շանս եմ ունենալու աշխատելու, քան օբերոնով/մոդուլայով։ ու սա նաեւ մտքի շուկայի վրայ հիմնուելու մասին ա։ իսկ վերջին մասը, գժուելու լաւն ա, ու հա, էն ինչը հիմա կատարւում ա՝ գիտութիւն չի, ինժեներիա չի։
կողքինն ասում ա, եթէ գոնէ ստիպուած էք անել բաներ, որոնք չէք հասկանում, գոնէ մի խօսէք բաներ, որոնք չէք հասկանում։
#ծրագրաւորում #օբերոն #համալսարան #շուկա #գիտութիւն
#պասկալ #մոդուլա #օբերոն #տտ #տեքնոլոգիա #գրականութիւն #մարդիկ
@{ քամի ; o_o@spyurk.am} 30.04.2019, 11:23:40
Reviving a computer system of 25 years ago - Wirth, 2014
ինձ վիրտի մէջ ամէնաշատն իր խնդիր֊կողմնորոշուած լինելն ա դուր գալիս։ ու պարզ մտածելը։
ասումա, ծրագիր գրելը բարդ ա՝ ինչքան էլ առեւտրականները հակառակը քարոզեն։ ճիշտ ծրագիր գրելն՝ առաւել եւս։
ասում ա, ծրագիրը կոդ չի համակարգչի համար, գրականութիւն ա մարդկանց համար։
#ծրագրաւորում #վիրտ
#չաթ
@{ մարիամ ; wordsthatidefend@spyurk.am} 25.02.2019, 22:58:09
ասում ա՝ — հայութիւնը զգալի ներդրում ա ունեցել ոչ միայն երկրորդ համաշխարհային պատերազմում, այլեւ օբերոնի այառսի չաթում:
#օբերոն #զրոյց
վիրտը թարմացրեց ORB.Mod մոդուլը՝ http://susepaste.org/view/raw/49183431
#օբերոն
ասում ա՝ — հայութիւնը զգալի ներդրում ա ունեցել ոչ միայն երկրորդ համաշխարհային պատերազմում, այլեւ օբերոնի այառսի չաթում:
#օբերոն #զրոյց
վաու, օբերոն համակարգերի մասին գիրք՝
https://en.wikibooks.org/wiki/Oberon
#օբերոն
իմ կեանքի ամենակարեւոր նպատակը՝ պահել օբերոնը կենդանի։ #օբերոն
Ես գուցէ ասել եմ, որ սեթը, այսօր իմ հասկանալով, վաւերագրական նկարի պէս ա, փողոցային լուսանկարի պէս ա, այն այն մասին ա թէ ովքեր են հաւաքուել այդ օրը այդ վայրում՝ ես այդ ժամանակաշրջանում ինչ երաժշտութիւն եմ լսել, ինչպէս եմ ինձ զգում, ով են մարդիկ ով գալիս են, ու ոնց են արձագանքում իմ դրած գործերին, մենք ծանօթանում ենք, ու փորձում ենք ընդհանուր հայտարարի գալ, նոր մարդիկ են աւելանում ընթացքում, տեղի աշխատողները կարող ա գնան գան, հազար ու մի բան ա կատարւում, լիքը անկանխատեսելի բաներ են պատահում, ու սեթն էլ այդ ամէնից ձեւաւորւում ա։
Սեթերիցս մէկը տեխնիկական պատճառներով չի ձայնագրուել։ Ու մի աղջիկ ասաց՝ «տանը մի հատ էլ նուագի նոյնը, ձայնագրի ու հրապարակի»։ Ես փորձեցի իրան բացատրել, որ տանը ձայնագրած սեթը, թէեւ հնարաւորինս մօտ փորձեմ անել նրան, ինչ եղել ա ակումբում՝ նոյն սեթը չի լինի։ Կը լինի այլ սեթ։ Փորձեմ բացատրել։
Անցնենք ծրագրաւորմանը։ Գոյութիւն ունի structural equivalence ու name equivalence։ Ասենք թէ ունենք տիպ human՝ այն ունի դաշտեր՝ name, weight, height, age։ ու ունենք տիպ alien, ով նոյնպէս ունի դաշտեր՝ name, weight, height, age։
TYPE
human = RECORD
name : ARRAY 64 OF CHAR;
weight, height, age: INTEGER
END;
alien = RECORD
name : ARRAY 64 OF CHAR;
weight, height, age: INTEGER
END;Ապա մենք կարող ենք ունենալ փոփոխական Valod՝ human տիպի, ու փոփոխական FordPrefect՝ alien տիպի։
VAR
Valod: human;
FordPrefect: alien;Եթէ ծրագրաւորման լեզուն չի պարտադրում name equivalence, մենք կարող ենք վերագրել FordPrefect֊ը Valod֊ին՝
Valod := FordPrefect;Սա լրիւ վալիդ կոդ ա Modula-3֊ում, բայց ոչ՝ Oberon֊ում։
Եթէ կազմարկումն անցաւ, ապա թւում ա թէ, ծրագիրը պէտք ա որ չպայթի, գոնէ վերագրման ժամանակ։
Բայց արդե՞օք մենք այլ տեսակի սխալ չենք անում, ու ի՞նչ հետեւանքների ա բերելու այդ սխալը, ո՞նց ա պահելու իրան ծրագիրը, դա արդէն աւելի դժուար ա կանխատեսել։
Վերադառնանք սեթին։ Տանը նուագած ու ձայնագրած սեթը որը ձտգում ա կրկնել մի այլ, իսկական լայւ նուագած սեթ նման ա փողոցային լուսանկար բեմադրելու փորձի, իսկ այդ ժամանակ նոյնիսկ եթէ դու կարողանաս ամէնն անել նոյն կերպ (ինչը ակնյայտ չի որ հնարաւոր ա կամ հեշտ ա), դա միեւնոյն ա կը լինի փողոցային լուսնկարի պէս մի բանի բեմադրութեան փորձ, ոչ թէ փողոցային լուսանկար։
Ու եթէ տանը՝ ստուդիայում անել սեթ՝ ապա անել կարգչով, սիրուն, մտածուած, բոլոր մանրուքները հաշուի առած սեթ յստակ յաջորդականութեամբ։ Բեմադրուած լուսանկարի պէս։ Բայց ես բեմադրուած լուսանկարներ սովորաբար չեմ անում, այդ պատճառով ա գուցէ, որ դեռ չեմ վառւում ցանկութեամբ հանգիստ նախապէս մոնտաժած սեթ պատրաստելու։ Ինձ դուր ա գալիս փողոցի անկանխատեսելիութիւնը, ինձ դուր ա գալիս փողոցի ոչ կատարեալ լինելը, կադրի ոչ կատարեալ լինելը՝ բազմազան պատճառներով՝ եսիմով մտաւ կադրի մէջ, կոմպոզիցիան փչացրեց, լոյսը խաղաց, անցաւ կամ գնաց, ժապաւէնի վրայ անկապ կէտ եղաւ, մութ էր, լուսազգայունութիւնը չհերիքեց, ու երկար պահաժամի պատճառով լղոզուեց շարժումը։ Այդ ամէնը ահաւոր սիրուն ա, թէկուզ եւ «սխալ» կոմպոզիցիա արած կամ այլ «թերութիւններով» ու կեանքն ա անկատար, ու ինձ դուր ա գալիս որ լուսանկարներս ու սեթերս կատարեալ չեն։
ու տէնց։
ուզում եմ օբերոնի մասին էլի բաներ կարդալ, բայց աշխարհում ինչ կայ գրած արդէն կարդացել եմ։
ուզում եմ մշակոյթ լինի դրա շուրջ, մարդիկ, որ նոր բաներ գրեն, բայց չկայ էդ։ #օբերոն #մշակոյթ
այս տղան վիրտուալ դիսպլէյներ (ուորքսփէյսներ) ա իրականացրել վերջին օբերոնի համար։
https://groups.google.com/forum/#!topic/comp.lang.oberon/39qdj1EIf_k #օբերոն
Օբերոնին նուիրուած հանդիպմանը «իմփաքթ հաբ»֊ում։ Էդուարդ Ուլրիխը ցոյց է տալիս իր V4 համակարգի «ֆորքը»։
#օբերոն #իմփաքթ_հաբ #երեւան
ինչ եմ շատ վայելում #օբերոն IRC ալիքի քննարկումներում այն է, որ ակնյայտ երեւում է որ լեզու իմանալը չի նշանակում ծրագրաւորել իմանալ։
@{Antranig Vartanian ; antranigv@spyurk.am} 17.05.2017, 22:29:36
solving https://www.reddit.com/r/dailyprogrammer/comments/68oda5/20170501_challenge_313_easy_subset_sum/
#DailyProgrammer #Oberon #Oberon-2 #voc ##
Էդուարդ Ուլրիխն առաջարկում է Օբերոն Դեյ անել երեւանում, փոքր փակ հանդիպում օբերոնիստների հետ։ Ասացի որ Արմենին կը կանչեմ Բադալեան, ու գուցէ մի երկու հետաքրքրուած երիտասարդ, առանձնապէս մարդ չի լինի։ Այնպէս որ սթեյ թիւնդ։ #օբերոն #երեւան
պատմում է Կապանում հարսանիքից՝
— նա էլ է դեւելոփեր աղջիկ, քոյրս է, առաջին անգամ եմ ծանօթացել իր հետ, խմել էինք, դուրս էինք եկել ու ես նրան խմած օբերոնի մասին էի պատմում։ ու մենք բաց թողեցինք տարոսիկների արարողութիւնը։ իսկ ընթացքում ինձ հա զանգում էին, չէի վերցնում, յետոյ ասացին՝ ո՞ւր էիր, տարոսիկ քեզ չմնաց։
#օբերոն #զրոյց
https://groups.google.com/d/msg/comp.lang.oberon/zWJaF1rOa1o/6b-6y04pDgAJ #օբերոն
#օբերոն #էկրանահան #զրոյց
#շաթլ #օդանաւ #ռենդեր #օբերոն #տպասալ
օբերոնի եւ մոդուլայի թրենդերի մասին՝ http://norayr.arnet.am/weblog/թրենդային
#օբերոն #մոդուլա-2 #մոդուլա #ծրագրաւորում #ծրագրաւորման_լեզուներ
Փաստօրէն, Օբերոնը երբեք չէր վայելում համայնքի բաւականաչափ ուշադրութիւն, նոյնիսկ համեմատած Մոդուլա֊2֊ի հետ։
Նոյնիսկ բաւական տուեալ չկայ, որպէսզի պարզ լինի, թէ որ երկրներում էր այն աւելի տարածուած։ Զարմանալի է, որ Մոդուլա֊2 ֊ով աւելի շատ հետաքրքրւել են Իսպանիայում, քան Գերմանիայում։
Ինչն է նաեւ զարմանալի, Օբերոնով երբեք այնքան հետաքրքրուած չէին, ինչպէս այսօր։
Նոյնիսկ ոչ այն ժամանակ, երբ Oberon S3֊ը կամ V4֊ը ակտիւ զարգանում էին, ի տարբերութիւն այսօրուայ PO֊ին։
Հաւանաբար, դա կարելի է բացատրել նրանով, որ վերջերս մարդիկ աւելի են հետաքրքրուած ծրագրաւորման լեզուներով, քան երբեւէ առաջ, եւ Վիրտի նոր գիրքը հրապարակուել է ճիշտ այն ժամանակին, երբ ծրագրաւորման լեզուները վայելում են բարենպաստ պայմաններ։
փաստօրէն, հայերէն վիքի֊ում այսպիսի յօդուած կայ՝ https://hy.wikipedia.org/wiki/Oberon_(ծրագրավորման_լեզու)
#օբերոն
շատ հետաքրքիր թուղթ եմ կարդում, այն մասին ինչպէս Ա2 համակարգի միջուկը փոխել են, որ այն աշխատի կոոպերատիւ մալտիթասկինգով։ սակայն դեռ լաւ չեմ հասկանում, թէ արդեօք Ա2֊ի միջուկը հիմա այդ նոր միջուն է ու արդեօք այն հիմա դարձել է «լոք ֆրի» համակարգ թէ ոչ։
#Ա2 #օբերոն #զուգահեռութիւն #ակտիւ_օբերոն #ծրագրաւորում #օպերացիոն_համակարգեր #ծրագրաւորում #թուղթ
այն, որ մոդուլը մնում է յիշողութեան մէջ ու պահում է իր վիճակը, իսկ կարող է մանիպուլացուել կողքի շելլից, հրամաններով։ սա շատ սիրուն նախագիծ է։
https://www.youtube.com/watch?v=byC98PHZR2Y
#օբերոն #նկարչութիւն #ծրագրաւորում #դեմո #էկրանահան #դիզայն #նախագծում
ահագին հաւանում եմ Փիթեր Մաթիասի Օբերոն/Լինուքս Ռիւայւալ նախագիծը։
այսօր աւելացրի իրա քոմփայլերին մի փաթչ, որը նախկինում աւելացրել եմ վիշապի մէջ։
Եթէ ունենք CASE, որը չի աւարտւում ELSE֊ով իսկ եղած վարկածներից ոչ մէկը չէ, ապա տեղի է ունենալու այսպէս կոչուած թռափ։ Սա ինձ ահագին գլխացաւանք է պատճառել նախկինում, երբ ես տարբեր կոդի հետ գործ ունենալիս փորձում էի հասկանալ, ինչու է այն մեռնում։
Ու քանի վիշապը փաթչ եմ արել, նոյն փաթչը որոշեցի այդ նախագծին էլ տալ։
Սա Վիշապի զգուշացման տեսքն է՝
Իսկ այսպէս է մեռնում ծրագիրը Օբերոն համակարգում՝
Ահա եւ ուղղումը՝
եւ այդպէս։ ։Ճ
գրառում նոր նախազգուշացման մասին։
#օբերոն #վօկ #ծրագրաւորում
վօկի պէս նախագծեր հայաստանում ցուցադրելը ոնց որ երբ արուեստի դպրոցի ուսանողը բերում է տուն իր կտաւը, ցոյց է տալիս։ իսկ տնեցիները նայում են այդ նկարին, նայում, ու ոչ այնքան հասկանում են ինչով է իրենց զաւակը զբաղուած եւ ինչու։ ասենք հարեւան Գուգոն, ով վերնիսաժում է վաճառում, հասկանալի գործ է անում։ իսկ սա ի՞նչ է, որ բերել է ցոյց է տալիս։
երբ այսօր հարցրին բարքեմփի պոտենցիալ շուեյցարական հիւրի մասին ու ես կարճ բացատրեցի ինչի մասին է նա, Հարութն ասաց՝ «աութ օֆ թիզ փլանեթ»։
եւ իսկապէս։
այսօր էլ մէկն ուղարկել էր քոմփիւթեր սայնս ֆիքշն վեց գործերի մասին գրառումը։ այսինքն, ֆանտաստիկա է այս ամէնը։ ինչպէս այլմոլորակայինները եւ ուրուականները։ ու վիշապները։
#օբերոն #վօկ #նախագիծ #տուն #արուեստ #հայաստան #մոլորակից_դուրս #ֆանտաստիկա #բարքեմփ #վիշապ #իսկապէս
ուրեմն, ասենք մի տարի առաջ, մի աղջկայ դեբիան եմ տեղադրել։ ինչո՞ւ։ մթոմ լաւութիւն էի արել՝ չի փչանայ, ասել եմ, վիրուսներ չես ունենայ, հանգիստ կապրես։
վերջերս կապուել է։ ասում է՝ վայֆայը չի աշխատում։ նախ, կարեւորն այն է, որ ինձ է կապուել։ ինչո՞ւ ինձ։ եթէ վինդովս լինէր, նա շատ տարբերակներ կունենար ու գուցէ նախընտրեր ինձ չդիմել։ բայց լինուքս «սափորթ» անողները, այո, այնուամենայնիւ, դեռ անհամեմատ աւելի քիչ են։
ինչեւէ, մենք հանդիպում ենք սրճարանում, եւ իր նոութը վայֆային կպնում է։ «ուրեմն աշխատում է» — ուրախանում եմ ես։ «չգիտեմ ինչ է, քեզնից է վախեցել» — պատասխանում է նա։ յետոյ գնում է տուն։ եւ իր նոութը իր տան վայֆային չի կպնում։ այդ ժամանակ նա համարձակւում է զանգել պրովայդերին, ով տեղադրել է եւ կարգաւորել վայֆայը եւ բողոքել։ իսկ պրովայդերը լուծում է խնդիրը՝ իր մեղքն էր։
ո՞րն է երկրորդ կարեւոր մասը այս պատմութեան։ այն, որ այդ աղջիկը, ով բնաւ էլ կոնֆորմիստ աղջիկ չէ ընդհանուր առմամբ, ու նախանձելի համարձակութիւն ունի շատ այլ իրավիճակներում, փաստացի ենթադրել էր, որ «մարգինալ լինուքսն է» պատճառը կապ չունենալու, ոչ թէ «մեյնսթրիմ» պրովայդերը։ նա չի ենթադրել, որ այն, ինչ մարգինալ է, այն ինչ տարածուած չէ, այն ինչ կոնֆորմիստական չէ՝ կարող է անխափան աշխատել։ ինքը՝ մարգինալ, ոչ կոնֆորմիստ լինելով։
ես կարծում եմ, որ դա շատ պարզ է։ ու որ մենք շատ քիչ հաւանականութեամբ կարող ենք ունենալ իրական նոն կոնֆորմիստ եւ իրական մարգինալ։ նրանց՝ ով փոխում է աշխարհը։ մերոնք՝ փոփոխութիւն անել ունակ չեն։ եւ դա, ես կարծում եմ, կապ ունի նաեւ մեր քանակի եւ բազմազանութեան հետ։
ինչպէ՞ս են մարգինալները փոխում աշխարհը։ փոխում են՝ ունենալով մեծ շուկայ։ փոխում են՝ քանի որ իրենց համայնքներն այնքան մեծ են, որ իրենց քիչ քանակի համախոհները այնուամենայնիւ այնքան շատ են, որ տարբերւողները կարողանում են չմնալ տեղում, զարգանալ, եւ համայնքները փոփոխութեան են տանում։
այսպէս, Սթոլմանը կարող էր իր գրած ազատ ծա֊ի աջակցութիւն մատուցելով ապրել՝ ժամը 200 դոլար վաստակելով։ քանի որ միացեալ նահանգների շուկան այնքան մեծ է, որ գտնւում էին մարդիկ, ով կօգտագործեր իր ծրագրերը, եւ դրանց մէջ գտնւում էին նաեւ նրանք, ով կը վճարէին աջակցութեան համար։
այսպէս, Լինուսը, չնայած իհարկէ բնաւ հարուստ չէ, ինչպէս Գեյթսը կամ Ջոբսը, Լինուսը կարողացել է իրեն թոյլ տալ միլիոն դոլարով տուն ձեռք բերել։ Եւ երկու հարիւր հոգանոց ռեդհեթը կարողացել է լինել շահութաբեր եւ տարածուել։ իհարկէ, նահանգների ճնշող մեծամասնութիւնը դեռ օգտագործում է մայքրոսոֆթի կամ էփլի արտադրանքը սեղաններին, սակայն իրավիճակը կամաց, բայց կայուն փոխւում է։ ու արդեն զարմանալի չէ, որ տեսականօրէն ազատ անդրոիդը, լինուքս միջուկով, դէ ֆակտո ստանդարտ է։
այնտեղ, ուր շատ մարդ կայ, գտնւում է շատ մարդ, ով կարող է, օրինակ, լաւ դիտորդ լինել ընտրութիւնների ժամանակ, կամ աջակցում է ոչ այնքան շահութաբեր մտքին՝ ասենք օգնել անօթեւան կենդանիներին։ այնտեղ փոքր համայնքները դառնում են ազդեցիկ, եւ փոխում են հասարակութիւնը, իսկ յետոյ փոխում են օրէնքները։
հայաստանի շուկան այնքան փոքր է, որ կարելի է ասել՝ այն չկայ։ նաեւ ակնյայտ է, որ շուեյցարական (իսկ շուեյցարիան նեյտրալ է եւ նոյնիսկ եւրամիութեան անդամ չէ) տեքնոլոգիաները չէին կարող մրցել ամերիկեան տեքնոլոգիաների հետ, անկախ նրանից, թէ ինչքանով լաւն էին։ օբերոնը, մոդուլան այդպէս էլ մնացին համալսարանների նեղ պատերի մէջ, ուր եւ շնչահեղձ են լինում։ պասկալը ժամանակաւոր տարածում ունեցաւ՝ երբ բորլանդ ընկերութիւնը գրանցուեց ամն֊ում, եւ ամն֊ում տարածուելու պատճառով այն յետոյ հասաւ մեզ։
եթէ օբերոնը լինէր գերմանական՝ տարածուեր գերմանիայում, դրան աւելի լուրջ էին վերաբերուելու։
կամ այլ օրինակ՝ ո՞վ էր լինելու Գոդարը, եթէ նա ապրեր եւ ստեղծագործեր (եթէ իրեն թոյլ տային) Հայաստանում։ Ո՞վ էր իրեն ճանաչելու։ Հայերը չէին ճանաչի ճիշտ այնպէս, ինչպէս ծանօթ չեն Փելեշեանին։ Աշխարհը չէր ճանաչի այնպէս, ինչպէս ծանօթ չէ Փելեշեանին։ Ի՞նչ կը լինէր, եթէ Փելեշեանը ստեղծագոծած լինէր Ֆրանսիայում։ Կասէին՝ որ նա փոխել է աշխարհը։ Որ կայ կինո մինչեւ Փելեշեան, եւ Փելեշեանից յետոյ։
այնտեղ է, իրենց մօտ է երբ փայթնը յաղթում ջաւան։ այո, աւելի հիփսթերական քան գիտական փայթնը յաղթում է կորպորատիւ ջաւան։ քանի որ այնքան լիբերալ հասարակութեան մէջ միայն կարող են լինել այնքան հզօր մարգինալներ։ այսպէս է որ փոքրամասնութեան իրաւունքները պաշտպանուած են լինում այնտեղ, ուր ժողովրդավարութիւն է։
Հայաստանում շատ բարդ է զարգանալ։ այսինքն՝ կարելի է լինել կենսակայուն «բակի բուդկա», որը թոյլ է տալիս տիրոջը սպասարկել հին «բմվ» եւ վճարել դստեր տնտեսագիտականի համար, բայց ոչ աւել։ նա ալեքսանեան երբեք չի դառնալու, ինչքան գրագէտ մարկետինգ չանի, ինչքան լաւ չկազմակերպի իր խանութի աշխատանքը՝ ապրանքների դասաւորութիւնը, գները, դիզայնը։
այսինքն՝ չի ստացուի լինելով տարբեր գրաւել շուկան։ չի ստացուի լինել տեղական գուգլ, կամ էփլ, որը դուրս է եկել աւտոտնակից։
նոյնը՝ ինդիւիդների մակարդակում է։
յիշո՞ւմ էք, երբ հայրը, իր երեխային ասում է՝ «տեսնո՞ւմ ես պեծյան փորում է։ այ դու էլ դասերից փախնես՝ փորելու ես»։ այո, ճիշտ է ասում, ընդհանուր առմամբ, հայաստանի համար։ բայց ճիշտ չէ ասում նահանգների համար, ուր գեյթսը թողնում է ուսումը, եւ հիմնում է մայքրոսոֆթ։ ուր ջոբսը թողնում է ուսումը եւ ստեղծում է էփլ։ ուր էյնշթեյնը գալիս է, անում իր դոկտորականը, նրանից յետոյ, երբ մերժւում է շուեյցարիայում։
կամ՝ ինչո՞ւ է այս աղջիկը հագնում կրունկներ, չնայած չի սիրում դրանք։ քանի որ, ասում է, չեն հաւանում ինձ։ բայց չէ՞ որ — հակաճառում էի ես — երբ դու վերջապէս հանդիպես նրան, ով հաւանելու էր հենց քեզ, նա դա չի անի, քանի որ դու չես լինի ինչպիսին կաս։ այո — համաձայնում էր նա։
սակայն ես հիմա հասկանում եմ, որ նա աւելի ճիշտ է։ նա, ով այդ աղջկան կհաւանէր այնպիսին, ինչպիսին նա կայ, կամ արդեն զբաղուած է, կամ գնացել է արտասահման՝ այնտեղ, ուր շատ են նրանք, ով իրեն դուր են գալիս։ ու նրանք, ով իրեն կընդունեն։ իսկ այն աղջիկը, որ սիրում է կարճ մազեր, ու «տղայական» տեսք, նա ոչ միայն քիչ հաւանական է, որ կհանդիպի իրեն այդպէս հաւանողին, այլեւ նա ինքը, ամենայն հաւանականութեամբ կհաւանի աւելի «աւանդական» տղայի, քան նա աղջիկ է։
եւ բնաւ պատահական չէ, որ մեզ մօտ ընդդիմադիր երեխաները՝ ընդդիմադիր ընտանիքներից են։ իսկ ոչ ընդդիմադիր երեխաները՝ ոչ ընդդիմադիր ընտանիքներից։ բնաւ պատահական չէ, որ դատախազի որդին է դառնում դատախազ, ոչ թէ ընդդիմադիր։
մեզ մօտ չափազանց քիչ են, փաստացի չեն լինում շրջակայ միջավայրին դէմ գնացող մարդիկ՝ հասարակութեանը, կամ ընտանիքին, եղբայրութեանը։ մեզ մօտ չեն լինում, քանի որ մենք քիչ ենք, ու դէմ գնալով, իրենք ընդամէնը գնալու են ինքնամեկուսացման։ իսկ մեկուսացող մարդիկ վաղ թէ ուշ լրացնելու են «նեուդաչնիկների» շարքերը։ սա ամն չէ, ուր նեուդաչնիկները գտնում են իրենց պէս ընկերներ, հզօրանում են, եւ տակն ու վրայ են անում համակարգը։ կամ գոնէ կարողանում են զարգանալ լինելով այնպիսին ինչպիսին կան, առանց կոտրուելու։
ու գուցէ զարմանալի չէ բնաւ, որ հայերի էպոսի հերոսը՝ Մհերը, ի վերջոյ գնում է ինքնամեկուսացման։ նա յաղթող չէ։
մարգինալները չեն կարող փոխել հայաստանը, քանի որ չեն հաւաքում կրիտիկական զանգուած։ (այնպէս, ինչպէս գազոնը ունի մինիմալ չափ ապրելու համար, եւ երկիրը ունի այնպիսի սահմաններ, որ պաշտպանելը իրատեսական լինի։) եւ ինչքան քիչ մարդ կայ այստեղ, այնքան քիչ է այն հաւաքելու հաւանականութիւնը։ (զակոն օբրատնիխ կուադրատով)։
այդ պատճառով էլ ունենք երեք հոգի հայերէն գրող դիասպորայում։ որոնց թիւը չի աճի։ այդպէս էլ կը փտեն, մինչեւ չյոգնեն իրարից։
ու պատահական չէ, որ մեզ մօտ նոնկոնֆորմիզմ գոյութիւն չունի։ իհարկէ կան, մեն֊մենակ այստեղ եւ այնտեղ, իրենց փոքր, նեղ համայնքիկներում՝ ախպերութիւններում փտող մարդիկ։ փտող՝ քանի որ օդի շարժ չկայ։ սակայն իրենք չեն փոխի ոչ մի բան։ ոչ իրենց արուեստն է տարածուելու, ընդունուելու լայն զանգուածներում, ոչ իրենց տեքնոլոգիաները, ոչ իրենց գաղափարները։ (ո՞ւր է ժամանակակից արուեստը հայաստանում։ մնացել է նփակի պատերի արանքում։ եւ դեռ կոմունիստների ժամանակ ստեղծուած թանգարանում։ չի տարածուել։ որտե՞ղ է ժամանակակից արուեստը նիւ֊յորքում։ պէ՞տք է պատասխանել։) աւելի ճիշտ՝ դրանք կընդունուեն այն ժամանակ, երբ կը գան դրսից։ եւ զարմանալի չէ, որ այդ մարգինալներին կհամարեն դրսամոլ, արեւմտամոլ։ ասենք որտեղի՞ց պէտք է գայ թարմութիւնը՝ այնտեղից, ուր յաղթել են մարգինալները։ որտե՞ղ են իրենք յաղթում՝ արեւմուտքում։
որտե՞ղ չեն յաղթում մարգինալները՝ չինաստանում։ ի՞նչ է անում չինաստանը՝ կրկնօրինակում է արեւմուտքը, իրականացնում է արեւմտեան նախագծերը։ ինչո՞ւ սոնի ուոլքմենը չդարձաւ այֆոն։ որովհետեւ կարգին ընկերութիւն էր սոնին, ոչ թէ արտակարգ եւ ըմբոստ՝ էփլի պէս։
տասնեօթ եւ տասնութ տարեկան դեռահասներն աւելի են տարբերւում իրարից, քան երեսուներեք եւ երեսունչորս տարեկան մարդիկ։ նոյնիսկ հարիւր հազար բնակչութիւն կորցնել կամ ձեռք բերելը աւելի մեծ ազդեցութիւն է ունենում հայաստանի վրայ, քան միացեալ նահանգների՝ մէկ միլիոնը։ «միլիոնոմ բոլշե, միլիոնոմ մենշե» — ասում էր Շարլ Բոննէն՝ «ինչպէս գողանալ միլիոն» ֆիլմում։ մեզ համար ամէն մի գնացող մարդն է կարեւոր։ ամէն մէկը նշանակութիւն ունի։
Այդ պատճառով են այնքան նկատելի այն քչերը, որ ինչ֊որ բան փորձում են փոխել։ Ու այնքան ատելութեան արժանանում։ Փոփոխութիւն անողներն, տարբերուողները այնքան շատ պիտի լինէին, որ այս մարդիկ չէին էլ երեւալու իրենց մէջ, լինելով ալիքների մաս, ոչ թէ առանձին իմպուլսներ։
այո, շատ անյոյս եմ գրել, թւում է։ բայց դա իրականութիւնն է, ֆիզիկայի օրէնքների պէս։ ես չեմ կարծում որ պէտք է հաւատալ փոխելու համար։ ես կարծում եմ, որ պէտք է իրատես լինել փոխելու համար։
եւ իրատես լինելով ես գիտեմ, որ ամէն գնացողը ազդում է, եւ ամէն մնացողն ազդում է։ մնացողին բարդ է ամենուր․ եւ ուսման ժամանակ, եւ աշխատանքի վայրում, եւ նախաձեռնելուց՝ նա վաստակելու է թուք ու մուր, կամ արհամարհանք, կամ ատելութիւն, կամ պրեզրենիե։ նա գնահատուած չի լինելու, նա իրեն շատ վատ է զգալու։
ու միայն եթէ բոլորը չէ, եթէ շատերը մնան, ինչպէս շատերը գնացին ապրելու էրեծ իսրայէլ, շատ տարբեր շատերը՝ եւ նիհար գունատ աշկենազիներն եւ սեւ էֆիոպցիներն, եւ շատերը որոշեցին սովորել մեռած լեզու, եւ շատերը լինեն դուխով՝ նախաձեռնող, անող, կպնող իրենց գործին՝ առանց խանգարող «հաւատքի», բայց եւ անկախ «հասարակական» փոփոխական կարծիքից, պարզապէս, որովհետեւ իրենք անձամբ այդպէս են կարծում, այն ժամանակ է փոխուելու հասարակութիւնը, ընտրութիւնները, բնականոն ձեւով է գալու հանդուրժողականութիւնը՝ քանի որ ահա տեսէք, բոլորը տարբեր են, ամէն ձեւի մարդ կայ, եւ պարզւում է, իրենք չեն քանդում պետութիւնը, այլ ստեղծում են ազգ։
ինչ֊որ «մալչիշեսկի» բան եմ տեսնում իմ ու վօկի մասին։
ի դէպ երբեմն անտանելի բարդ է լինում, ու ոնց որ իրօք վիշապի հետ պայքարէս։
սա ոնց որ ասպետական «քուեսթ» լինի, ինչ֊որ վեհ թուացող նպատակի համար, ասենք գրաալի, կամ արդարութեան։
օրինակ, կարծում եմ, որ օբերոնը չգնահատուած է։
ինչ֊որ «մալչիշեսկի» բան եմ տեսնում իմ ու վիշապի յարաբերութեան մէջ։
նախ երբեմն անտանելի բարդ է լինում, ու ոնց որ իրօք վիշապի հետ պայքարէս։
բայց կարեւորն այն է, որ սա ոնց որ ասպետական «քուեսթ» լինի, ինչ֊որ վեհ թուացող նպատակի համար, ասենք գրաալի, արդարութեան։ (օրինակ, կարծում եմ, որ օբերոնը չգնահատուած է։)
#վօկ #քուեսթ #վիշապ #էկրանահան #օբերոն
փաստօրէն տրէքը թարգմանուած է հայերէն։
#հայերէն #փաստօրէն #թրէք #թարգմանութիւն #օբերոն #ակտիւ֊օբերոն #ա2
#մէջբերում #քաղուածք #ելատեքստ #մաթեմատիկա #մաթեմ #մաթ #ջոն֊ֆոն֊նեյման #էկրանահան #օբերոն #պատահական֊թուեր #այո
ինչ է իւենթը ու ինչով են այն ուտում։ աւելի ճիշտ ինչպէս պատրաստել քոլբեք ֆունկցիա։
https://github.com/norayr/events_in_oberon/
#օբերոն #քոլբեք #ծրագրաւորում #թեստ
սի պլիւս պլիւսը ստանդարտ, մեծ ծիծիկներով, լայն շրթունքներով ծիտ է, էն որ համարւում է տղամարդու իդեալ, ու եթէ դու իրա պէս աղջիկ չունես, դու լուզեր ես, ու դու չես ձգել։ նա նաեւ ունի հարուստ ծնողներ, ժառանգութիւն, կապեր։
իսկ ես, եթէ եւ մի քանի գայթակղութիւն ունեցել եմ դրա մէջ խորանալու, ծանօթացել եմ, բայց մէկ է․
սիրում եմ եւ շարունակում եմ խորանալ իմ նիհար ու կոկիկ, զանգուածների կողմից չգնահատուած, ոչ շատ բարձրահասակ, բայց երբեք կրունկներով (հենակներով) եւ երբեք վուլգար, միշտ ճաշակով հագնուող, հմայիչ ու հարազատ օբերոնի մէջ։
#ծրագրաւորում #օբերոն #աղջիկ #յարաբերութիւն #սէր
մի քիչ լաւացրի ու աւելացրի ԿարդայԻնդ֊ը։ ահա։ ։Ճ
https://github.com/norayr/rrro
#օբերոն #աւբերոն #կոմպիլյատոր #հաւէս
#oberon #programming #operating-systems #oberon-v5 #screencast
@{
Փրչրթան✱ Թանաքեան ; norayr@spyurk.am} 11.09.2014, 22:31:53
Oberon V5 կոմպիլյացիա։
#օբերոն #աւբերոն #կոմպիլյացիա #էկրանահան
Oberon V5 կոմպիլյացիա։
#օբերոն #աւբերոն #կոմպիլյացիա #էկրանահան
http://www.youtube.com/watch?v=ZiKWZySzKrM
#վիշապ #օբերոն #աւբերոն #ինֆերնո #պլան9 #օպերացիոն֊համակարգեր #ծրագրաւորում #barcampevn14
#shanghai #game #screenshot #oberon #aos #gadgets #desktop #էկրանահան #Շանհայ #խաղ #օբերոն
սա իմ կոմպիլյատորի աշխատանքի թրեյսն է, որ պարզ բան է անում՝ վերագրում կոմպիլիացիա անում։
ստացուած է օգտագործելով gdb, callgraph, graphviz ծրագրերը։
ու տենց
I have published Vishap Oberon compiler
#vishap #voc #oberon #oberon-2 #compiler #ofront #pascal #modula-2 #fork #github #compilers #վիշապ #օբերոն #կոմպիլյատոր #պասկալ #մոդուլա֊2 #ծրագրավորում
ԵՏՀ-ի Բ հարկում ապակու հետեւը տեղադրված են ԵՏՀ-ի արտադրված Լիլիթ եւ Սերես կարգիչները։
Լիլիթի ԾԱ-ն գրված էր ԵՏՀ-ում ստեղծված Մոդուլա-2 լեզվով, Սերեսը աշխատում էր Օբերոնով գրված Օբերոն ՕՀ-ի տակ։
Այժմ Օբերոնը իր զարգացումը ունի, օգտագործվում է մի շարք հետաքրքիր պրոեկտներում, ու բնականաբար ԵՏՀ-ում։ Սույն տեքստը այդ մասին չէ։
Այն մասին է, որ մի անգամ, երբ ես մտա Բ հարկ, որ իջնեմ Ա, ուր աշխատում էի, տեսնեմ ապակու մոտ ինչ որ երիտասարդ է կանգնած, կարգիչները զննում է։
Ես մտածեցի, մերոնցական է, հավանում է։
Մոտեցա, որ ծանոթանամ։ Ասացի, – վերջն են։
– Դրա՞նք – ասաց նա։
– Հիանում եմ, – ասում եմ։ – Գեղեցիկ ՕՀ, արտակարգ լեզուներ։
– Ո՞ւմ է դա պետք – ասաց նա – երբ մենք ունենք դոթնեթ։
վարագույր
ու տենց
Let’s write a minimal module with one exported function in Oberon:
MODULE m;
PROCEDURE add*(a, b : INTEGER): INTEGER;
BEGIN
RETURN a + b;
END add;
END m.
We even can compile it now with oo2c
$ oo2c m.Mod
and get directories obj and sym.
We may now compile obj/m.c
and get an object m.o
gcc -Iobj -I/local/oo2c/lib/oo2c/src -I/local/oo2c/lib/oo2c/obj -c obj/m.c
Now we need a pascal wrapper to bind it.
Let’s call it mbind.pas
unit mbind;
{$link m.o}
(*oo2c objs to link*)
{$link RT0.o}
{$link Object.o}
{$link Exception.o}
{$link HashCode.o}
{$linklib c}
interface
uses CTypes;
function m__add(a, b : ctypes.cint16) : ctypes.cint16; cdecl; external;
(*
/local/oo2c/lib/oo2c/obj/C.oh
typedef OOC_INT16 C__shortint;
*)
implementation
end.
We need to tell compiler explicitly which object files to link.
m.o is the object file we get by compiling obj/m.c
Other files are the minimal oo2c rtl which needs to be linked.
We also need to link to libc, because oo2c works by compiling via C.
Function name is m__add because oo2c translates m.add to C as m__add
Note, that implementation section is empty, and fpc does not issue an error because the function marked as external.
Eventually, let’s write a main module to call the Oberon function.
program m0;
uses mbind;
var i : integer;
begin
i := m__add(20, 3);
writeln (i);
end.
Neither fpc nor oo2c do not need a make file.
FreePascal compiler, as well as Oberon can itself resolve module dependencies.
For example, I do not need to write a makefile where I compile first mbind.pas and get mbind.o and link it during the next step.
However, in this case I’d like to write a make file.
IPATH = -Iobj -I/local/oo2c/lib/oo2c/src -I/local/oo2c/lib/oo2c/obj
LPATH = /local/oo2c/lib/oo2c/obj
GCC = /usr/bin/gcc
OO2C = /local/oo2c/bin/oo2c
FPC = /local/fpc/bin/fpc
all:
$(OO2C) m.Mod
$(GCC) $(IPATH) -c obj/m.c
$(FPC) -Fo$(LPATH) -Fo. m0.pas
clean:
rm *.o
rm *.ppu
I usually use custom fpc I compiled from subversion, and I prefer to keep my software in /local
LPATH is the path where oo2c main rtl objects are located, so fpc can find and link RT0.o, Exceptions.o, Object.o and HashCode.o.
So, first oo2c compiles the m module to c.
Then gcc compiles it to object file.
Then fpc compiles the main module.
And now enjoy:
$ ./m0
23
und so weiter
այսպես, աշխատացրել եմ i2c tiny usb օբերոնով, ooc օգտագործելով։
ու տենց
մի ամերիկացի պրոֆեսոր կա, հա մեյլ լիստերում բողոքում էր, ասենք, այ, դուք այստեղ խոսում եք ինչ լավն է կամ վատն է այս կամ այն նախագծման միջավայրը, կամ քոմփայլերը, իսկ ինձ համար նրանք չեն կարող լինել լավը կամ վատը, որովհետեւ այն երկաթի համար, ինչի հետ ես գործ եմ անում, այն պարզապես գոյություն չունի։
Ասացի դե ես չանեմ, էլ ո՞վ կանի։
Պորտ արեցի Ջոզեֆ Թեմփլի Oberon-2 քոմփայլերը իրա ուզած blackfin-ի համար։
Նա էլ որոշեց ինձ բլաքֆին քարտ ուղարկել, հետագա տեստավորման համար։ Ու, փաստորեն, ուղարկեց, հունվարի երեքին։ սույն թվի ։Ճ
Քարտը այդպես էլ կորել էր։ Բայց հույսը դեռ չէր մարել։
Ահա, նոր հասավ ինձ, այսօր ստացա, մայիսի վեցին մտավ Հայաստան, տասին հասավ ինձ։
ու տենց
I want to avoid implementation inheritance in CP programs.
What are the language features I have to rule out ?
Is it just the super call which I have to avoid or something else ?
Give priority to composition over inheritance.
Inherit, if you must, only from ABSTRACT classes. No EXTENSIBLE types or methods.
Methods should be ABSTRACT, EMPTY or FINAL.
No supercalls, use ordinary exported procedures instead (this is always possible).
Avoid exported fields, use functions instead (better evolvability).
Stick to sequential data structures and algorithms whenever possible (scalability),
exploit carrier-rider to the full — hide data access behind abstract riders.
Your specific data processing algorithms should interface to abstract riders rather than carriers.
Give priority to text-as-interface over forms.
Avoid anything fancy or smart or optimized — that’s Devil tempting you.
Once again: f*** optimizations!
from the blackbox component pascal mailing list
und so weiter
«Մոդուլային համակարգերի գաղտնիքները» հոդվածի հեղինակն է Սերգեյ Գուբանովը։
«Մոդուլ» եւ «մոդուլյար լեզու» թերմերի բացատրությունների զանազանությունը ծնում է ավներջ վեճեր։ Ինչեր ասես, որ մոդուլ չեն անվանել, ինչ լեզու ասես, որ մոդուլյար չեն համարել։ Ոմանք մոդուլ անվանում են կլասսները, ոմանք ել համեմատում են մոդուլները օբյեկտների հետ։ Առհասարակ այնպիսի տպավորություն է ստեղծվում, որ այժմ մոդուլյար եւ կոմպոնենտային լինելը նորաձեւ ոճ է։ Տարբերակների զանազանության պատճառը բացատրությունների ձեւի մեջ է՝ ներքին ձեւի։ Ներքին է այն իմաստով, որ սահմանումը տրվում է որոշ ներքին հատկությունների հիման վրա (մոդուլը պարունակում է տվյալներ, կոդ, տիպեր, ապահովում է ինկապսուլյացիան, ունի ինտերֆեյս, եւ այլն)։ Մոդուլների ներքին էական հատկությունները առանձնացնելու բազմաթիվ եղանակներ կան, իսկ դա նշանակում է, որ գոյություն ունեն նաեւ մոդուլների սահմանման բազմաթիվ եղանակներ։ Ապագայում ներքին հատկությունների քանակը գուցե եւ ավելանա, հայտնվեն սահմանումների նոր ձեւեր․ այսինքն՝ վիճելու առիթ ավելի շատ կլինի ու դա կտանի փակուղու։ Ելքը ներքին սահմանման փոխարինումն է արտաքինով։
Արտաքին է այն իմաստով, որ սկզբից պետք է նկարագրել ինչ է «մոդուլյար համակարգը», իսկ «մոդուլի» հասկացությունը կհայտնվի ինքնաբերաբար, ավտոմատ կերպով, քանի որ մոդուլը մոդուլյար համակարգի բաղադրիչն է։ Մոդուլյար համակարգը առաջնային է, մոդուլը՝ երկրորդային։ Մոդուլն ինքը իրանով չէ, այլ համակարգի մոդուլ է։ Մոդուլյար լեզու հարկավոր է անվանել այն լեզուն, որը մոդուլյար համակարգեր նախագծելու համար հարմարեցված, օպտիմիզացված է։ Այսպիսով՝ մոդուլյար ծրագրավորման լեզուների իմաստը մոդուլյար համակարգերի նախագծումն է։
Ստորեւ բացահայտենք մոդուլյար համակարգերի իմաստը:
Մոդուլյար ծրագրավորման համակարգերը եկել են միաձույլ ծրագրերը փոխարինելու համար։ Մոդուլյար համակարգեր կիրառելու իմաստը (ի տարբերություն միակուռ ծրագրերի) դինամիկ ընդարձակվելու ունակությունն է։ Մոդուլյար համակարգը կարելի է դինամիկ ընդլայնել մի քանի ձեւով։ Օրինակ՝ դրա մեջ նոր մոդուլներ ավելացնելով կամ փոխարինելով դրա միջի հին մոդուլները նորերով , որոնք ունեն ավելի լայն հնարավորություններ կամ որեւէ այլ լավացումներ։ Ընդարձակվող մոդուլյար համակարգը երբեք ավարտված չէ, այն զարգացում է ապրում։ Որոշ մոդուլներ փոխարինվում են, որոշները դինամիկ ավելացվում։ Այսպիսի համակարգի կյանքը կարող է լինել ավելի երկար, քան նրա միջի կոմպոնենտների կյանքը (տես․ մարդը եւ բջիջները, թարգմանչի նկատողություն)։ Համակարգի օգտագործողը ինքն է որոշում ինչպես այն ընդարձակել։ Կատարյալ դեպքում գոյություն ունի համակարգի կոմպոնենտների շուկա, որտեղ տարբեր արտադրողներ առաջարկում են մոդուլների իրենց իրագործումները, որոնք եւ ձեռք է բերում համակարգի օգտագործողը։ Կոմպոնենտների շուկայի բացակայությունը կարող է խոչընդոտել միաձույլ համակարգերից մոդուլյար համակարգեր անցնելուն։ Սակայն, պահանջարկը ծնում է առաջարկ։
Դիտարկենք մոդուլյար, դինամիկ ընդլայնվող համակարգի կառուցվածքը։ Մոդուլների միջեւ փոխազդեցությունը իրագործվում է մոդուլի՝ այլ մոդուլներ ներմուծելու (import) ունակության շնորհիվ։ Այսպիսով՝ ներմուծող մոդուլը հանդիսանում է ներմուծվող մոդուլների կլիենտ։ Մոդուլների ներմուծման գրաֆը միշտ ացիկլիկ է։ Գրաֆի ացիկլիկ լինելը կապված է այն հանգամանքի հետ, որ մոդուլները հանդիսանում են բեռնման, կատարման եւ բեռնաթափման միավորներ, իսկ ցիկլիկ կախվածության դեպքում բեռնման եւ կատարման միավոր կլիներ ամբողջ ցիկլը․ այսինքն՝ այն ամբողջությամբ կլիներ մոդուլ (համակարգի կոմպոնենտ)։ Մոդուլյար համակարգը ենթադրում է կատարման միջավայր, որի հիմնական խնդիրներից է մոդուլների դինամիկ բեռնումը, ուշ կապը (late linking), կատարումը եւ բեռնաթափումը։ Այլ խնդիրը ամբողջականության կոնտրոլն է․ տիպերի դինամիկ բերումը, զանգվածների (array) ինդեքսների դինամիկ ստուգումը եւ այլն։ Դինամիկ բեռնաթափման հնարավորությունը անհրաժեշտ է հին մոդուլները նորերով փոխարինելու համար։ Ի դեպ մոդուլը չի կարելի բեռնաթափել մինչեւ բեռնաթափված չեն բոլոր նրա կլիենտները։ Դա ակներեւ է թվում, սակայն այդ մասին հաճախ մոռանում են։ Մոդուլների բեռնումը եւ բեռնաթափումը կարելի է համեմատել աղյուսներից աշտարակ հավաքելու հետ․ աշտարակը կարելի է քանդել միմիայն վերեւից, այլ դեպքում այն կփլվի։ Ակներեւ է նաեւ այն, որ մոդուլը կարելի է բեռնաթափել միմիայն հստակ (explicit) հրամանով, այլ ոչ թե ավտոմատ կերպ (օրինակ՝հիմնվելով կլիենտների բացակայության փաստի վրա․ այժմ կլիենտներ չկան, իսկ որոշ ժամանակ անց կլինեն, եւ մոդուլի վիճակը պիտի պահպանվի)։ Նոր մոդուլի ավելացումը կամ հին մոդուլի փոփոխությունը չպետք է բերի ամբողջական համակարգը ավիրելուն։ Քանի որ մոդուլները կարող են մատակարարվել տարբեր արտադրողների կողմից, ապա կատարման միջավայրը պիտի ստուգի մոդուլների համատեղելիությունը եւ խոչընդոտի անհամատեղելի մոդուլների բեռնմանը։ Համատեղելիությունը ստուգվում է մոդուլի ինտերֆեյսի անալիզի միջոցով։ Մոդուլը պարունակում է իր մեջ զանազան ծրագրային էություններ` կոնստանտներ, տիպեր, փոփոխականներ, ֆունկցիաներ։ Մոդուլի որոշ էություններ հասանելի են դառնում կլիենտների համար, այսինքն` արտահանվում են (export), իսկ մնացածները թաքցվում, այլ խոսքերով՝ ինկապսուլյացիա անում։ Ի դեպ այդպիսի ինկապսուլյացիայի ձեւը ամենահզորն է, քանի որ այն խախտելու միակ միջոցը մոդուլի բինար կոդի հետազոտությունը եւ դրա ոչ անվտանգ փոփոխությունն է։ Մոդուլի արտահանվող էությունների ամբողջությունը սահմանում է մոդուլի ինտերֆեյսը։ Դրա միջոցով էլ իրականացվում է կլիենտների հետ փոխազդեցությունը։ Եթե երկու մոդուլ (նույնիսկ տարբեր արտադրողների մոդուլներ) ունեն նույն ինտերֆեյսը, ապա դրանք երկուստեք փոխարինելի են։ Եթե երկու մոդուլներից մեկը ունի առաջինի համեմատ ընդլայնված ինտերֆեյս (այսինքն՝ նրա ինտերֆեյսը ճշգրիտ կրկնում է առաջին մոդուլի ինտերֆեյսը եւ դրան գումարած արտահանում է հավելյալ էություններ), ապա երկրորդ մոդուլը փոխադարձորեն փոխարինելի է առաջինի հետ։
Ինչպե՞ս է կատարման միջավայրը որոշում մոդուլների համատեղելի լինելը։ Ամենապարզ ձեւն է՝ դրոշմել ամեն մոդուլը իր տարբերակի համարով (լինի դա հստակ նշված տարբերակ, թե վերջին կոմպիլյացիայի ժամանակը)։ Հին մոդուլյար համակարգերը օգտագործում էին ժամանակային նշումների մեխանիզմը (timestamps)։ Բայց տարբերակի հստակ (explicit) նշելը գերադասելի է, որովհետեւ ավելի ուշ timestamp-ը հայտնում է միայն այն, որ տվյալ մոդուլը ավելի ուշ է հավաքվել (compiled), բայց չի ակնարկում որ մոդուլի ինտերֆեյսը լուրջ փոփոխությունների է ենթարկվել։ Սակայն մոդուլը որոշակի համարով դրոշմելու լուծումը նույնպես թերի է։ Ենթադրենք, նոր մոդուլը հնից տարբերվում է միայն նրանով, որ նրա մեջ փոխված է ինտերֆեյսի բավականին փոքր մասը։ Օրինակ՝ փոխվել է մի արտահանվող կոնստանտի արժեքը, իսկ մնացած ամենը մնացել է անփոփոխ։ Ապա այդ մոդուլը պետք է դրոշմվի որպես նոր տարբերակ։ Սակայն գոյություն ունեն այնպիսի կլիենտ մոդուլներ, որոնք օգտագործում են միայն ինտերֆեյսի անփոփոխ մնացած մասը։ Նոր դրոշմի պատճառով այդ մոդուլի բոլոր կլիենտ մոդուլները կճանաչվեն անվավեր, այսինքն՝ կատարման միջավայրը կհրաժարվի բեռնել (աշխատեցնել) դրանք փոփոխված մոդուլի հետ համատեղ։ Մոդուլների համատեղելիության ստուգման մեխանիզմը երբեմն անհիմն անգութ է, եւ կատարման միջավայրը կարող է անվավեր համարել բազմաթիվ մոդուլներ։ Բարեբախտաբար, գոյություն ունեն մոդուլների համատեղելիությունը հաստատելու այլ, ավելի գրագետ ձեւեր։ Հավաստիանալու գաղտնիքը նրանում է, որ մոդուլի յուրաքանչյուր արտահանվող (exported) էությանը (յուրաքանչյուր կոնստանտի, փոփոխականի, տիպի, ֆունկցիաի) կցվում է ուրույն նշան, մատնահետք (fingerprint), ավելի պարզ՝ checksum, որը հաշվարկված է այդ էության որոշակի կառուցվածքային ինվարիանտ հատկությունները ի նկատի ունենալով։ Այսպիսի «մանտնահետք» դրոշմեր ստանալը հեշտ խնդիր չէ, առավել եւս ընդարձակվող համակարգերի դեպքում։ Ավելի քան տաս տարի առաջ ETH-ում մատնահետք դրոշմեր հաշվելու թեմայով դոկտորական թեզ է պաշտպանվել (Regis Crelier «Separate Compilation and Module Extension», գիտական ղեկավարներն էին Նիկլաուս Վիրտն (Wirth) ու Հանսպետեր Մոսենբոքը (Mossenbock), Oberon-2 լեզվի համահեղինակները)։ Կատարման միջավայրում մոդուլների համատեղելիության կոնտրոլի բացակայությունը կարող է բերել անկանխատեսելի հետեւանքների։ Այսպես, օրինակ, MS Windows համակարգի կատարման միջավայրը (ըստ էության պարզապես բեռնիչը), որի մեջ dll ֆայլերը հանդիսանում են մոդուլներ, չի ստուգում այդ մոդուլների համատեղելիությունը։ Որպես հետեւանք գոյություն ունի տխրահռչակ dll hell հասկացությունը։
Մոդուլյար համակարգեր ստեղծելը սկզբունքայնորեն հնարավոր է ցանկացած ծրագրավորման լեզվի օգնությամբ։ Օրինակ՝ win32 dll մոդուլյար համակարգը կարող է իրագործվել զանազան լեզուներով։ Սակայն դժվար թե լինի գոնե մեկ լեզու, որը այդ իսկ նպատակին հարմարեցված է նախագծման պահին։ Համեմատենք մեկ dll մոդուլի ստեղծման թեթեւությունը (որը որպես կանոն շատ հեշտ է, քանի որ բոլոր հոգսերը տանում է նախագծման միջավայրը) մի քանի, կամ տասնյակ/հարյուրավոր դինամիկ բեռնվող եւ բեռնաթափվող dll մոդուլներ պարունակող համակարգի ստեղծման բարդության հետ։ LoadLibrary եւ GetProcAddress կանչերի վիթխարի քանակը հարմարավետ չես անվանի եւ դրանք կիրառող տեքնոլոգիան, կամ լեզուն, ոչ մի կերպ չես անվանի մոդուլյար համակարգեր ստեղծելու համար հարմարեցված լեզու։ Ընդ որում ստատիկ կապումը (static linking) ելք համարել չի լինի, որովհետեւ բեռնաթափել եւ փոխարինել ստատիկ կապված մոդուլը անհնար է։ Ինչպես ասված էր, բնական է մոդուլյար ծրագրավորման լեզուները սահմանել որպես մոդուլյար համակարգեր ստեղծելու համար հարմարավետ, հատուկ նախագծված, նախատեսված լեզուներ, դա է իրենց իմաստը։ Բայց ինչպես մենք քիչ առաջ համոզվեցինք, մոդուլյար համակարգերը, առհասարակ, կարելի է կերտել նաեւ այդ համար հատուկ չնախատեսված լեզուների օգնությամբ։ Հարցը միմիայն աշխատանքի ծախսն է։ Կարող է պարադոքսալ թվալ, բայց լինում է եւ հակառակը․ կան ծրագրավորման լեզուներ, որոնք, կարծես, հարմարավետ են ոչ միայն միաձույլ, այլ նաեւ մոդուլյար համակարգեր ստեղծելու համար։ Ես ի նկատի ունեմ Delphi-ն։ Թվում է, որ այնպիսի սինտակտիկ միավորները, ինչպիսին են՝ unit, interface, implementation, uses, մոդուլյար համակարգեր ստեղծելու համար շատ օգտակար են․ մոդուլներ կհանդիսանային յունիթները, ավելի ճիշտ դրանց կոմպիլյացիայի արդյունքը՝ dcu ֆայլերը (delphi compiled unit)։ Բայց, ցավոք, dcu ֆայլերը մոդուլներ չեն, դրանք «կիսաֆաբրիկատներ» են։ Չնայած նրան, որ մոդուլների բոլոր արտաքին սինտակտիկ հատկանիշները առկա են, նրանց անհնար է մոդուլյար համարել․ ներկա ժամանակ աշխարհում գոյություն չունի մոդուլյար համակարգ, որի ստեղծման համար այն հատուկ հարմարեցվի։ Տեսականորեն, եթե երբեւէ ստեղծվի հատուկ կատարման միջավայր, որն ունակ կլինի դինամիկ բեռնել եւ բեռնաթափել dcu ֆայլերը, ապա այնժամ հնարավոր կլինի Delphi-ն անվանել մոդուլյար, այսինքն՝ հատուկ հարմարեցված մոդուլյար ծրագրավորման համար։ Այս տրամաբանությունը կարող է թվալ անսպասելի, բայց այն հետեւում է այս գրառման սկզբում սահմանված մոդուլյար համակարգերի իմաստից։ Մոդուլյարության հատուկ սինտակտիկ հատկանիշները անշուշտ անհրաժեշտ են, սակայն դրանք բավական չեն, այսինքն ոչ մի պարադոքս իրականում չի դիտվում։
Չնայած նրան, որ լեզվի միջի հատուկ շարահյուսական (սինտակտիկ) հատկանիշները բավական չեն լեզուն մոդուլյար անվանելու համար, դրանք միեւնույն է անհրաժեշտ են։ Անհրաժեշտ են նրա համար, որ լեզուն հարմարեցված լինի մոդուլյար համակարգեր գրելու համար։ Մոդուլյար ծրագրավորման լեզվի շարահյուսության մեջ պիտի արտահայտված լինեն ամենաքիչը երեք հասկացություն՝ ինքը մոդուլը, մոդուլների ներմուծմանվ(import) միջոցները եւ ծրագրային էությունների արտահանման (export) միջոցները։ Մոդուլյար համակարգի ամբողջականության վերահսկումը հնարավորինս վաղ իրականացնելու համար անհրաժեշտ է անջատ (separate), այլ ոչ թե անկախ (independent) կոմպիլյացիա։ Ակնհայտ է, որ մոդուլը պիտի լինի կոմպիլյացիայի միավոր։ Այլ դեպքում ինչու՞մ է կայանում հարմարավետությունը։ Մոդուլի ներքին էությունները իրար ամուր կապված են։ Եթե կոմպիլիացիայի միավոր լինի մոդուլից փոքր մեծություն, ապա անջատ կոմպիլիացիան հաշվի առնելով՝ անհրաժեշտ կլինի հնարել որոշակի թաքցրած ինտերֆեյսներ այդ էությունների փոխազդեցությունների համար։ Ակներեւ է, որ դա ավելորդ բարդացում է, գուցե նույնիսկ՝ անվտանգության ճեղք (vulnerability), եւ դրա օգուտը պարզ չէ։
Ընդհանուր առմամբ, մոդուլյար համակարգերի ծրագրավորումը չի պահանջում օբյեկտային կողմնորոշված ծրագրավորման (ՕԿԾ) մոտեցում, իրավացի է եւ հակառակը։ Սակայն, այդ երկու մոտեցումների համաժամյա կիրառությունը բերել է նոր ծրագրավորման պարադիգմայի ստեղծմանը։ Բանն այն է, որ ՕԿԾ-ն, իր ամենատարածված բացատրությամբ, հիմնված է ժառանգողականության (inheritance) հասկացության վրա։ ՕԿԾ-ն եւ մոդուլարությունը միատեղ կիրառելու ընթացքում ծնվում է միջմոդուլյար ժառանգողականությունը, սակայն այն հանդիսանում է տարբեր արտադրողների մոդուլների փոխարինելիության խոչընդոտ։ Եթե տիպի մասը սահմանված է մեկ մոդուլի մեջ, իսկ մյուս մասը՝ այլ, ապա հիմնական տիպի նկարագրությունը պարունակող մոդուլը այլ արտադրողից նույնանման մոդուլով փոխարինելը բավականին մեծ խնդիր է․ իրականացման հնարավոր մանր տարբերությունների պատճառով։ 1995 թվին, պրոֆեսոր Կլեմենս Շիպերսկին (Clemens Szyperski) ֆորմալիզացրել է Կոմպոնենտային Կողմնորոշված Ծրագրավորման (ԿԿԾ) հիմունքները սահմանափակելով եւ ՕԿԾ-ն եւ մոդուլյար մոտեցումը դրանց չհակասող համատեղ գոյության համար («Component-Oriented Programming A Refined Variation on Object-Oriented Programming», The Oberon Tribune, Vol 1, No 2, December 1995)։ ԿԿԾ-ի իմաստը ընդարձակելի համակարգերի կառուցումն է՝ մոդուլների եւ ՕԿԾ-ի օգնությամբ։ Այսպիսով, ԿԿԾ-ն, Շիպերսկու կարծիքով, գտնվում է «<ՕԿԾ-ից դուրս» (Beyond Object Oriented Programming - թարգմանչի նկատողություն) (այսպես է կոչվում նրա արդեն երկու անգամ հրատարակված բեսթսելերը)։ ԿԿԾ-ի հիմքը հանդիսանում են․ պոլիմորֆիզմը, ուշ կապումը (late linking), իսկական ինկապսուլյացիան, կատարման միջավայրի կողմից իրականացվող անվտանգութան ամբողջական վերահսկումը։ Կատարման միջավայրը նաեւ պարտավոր է աղբ հավաքել։ Աղբ հավաքելը շքեղություն չէ բնավ, այլ անհրաժեշտություն․ այն կոմպոնենտային համակարգի ամբողջականության երաշխիքներից մեկն է (հիշենք, որ համակարգի կոմպոնենտները՝ մոդուլները, ստեղծվում են, առհասարակ, տարբեր արտադրողների կողմից)։ Այժմ, ուշադրություն դարձրեք այն հանգամանքին, որ «ժառանգողականության» հասկացությունը (այսինքն տիպի ընդլայնումը), որը այնքան տարածված է ժամանակակից ՕԿԾ լեզուներում, առհասարակ չի ընդգրկված ԿԿԾ-ի հիմքերի մեջ։ Դրա բացատրությունը տրիվիալ է։ Եթե տիպերի ընդլայնումը կիրառվում է մոդուլների մեջ, ապա դա սովորական ՕԿԾ է՝ այնտեղ ուրույն կանոններ են։ Իսկ եթե օգտագործվում է տիպերի միջմոդուլյար ընդլայնումը, ապա այն մոդուլները, որոնց միջեւ տիպերը կապված են ժառանգողականողականության հարաբերություններով, կապված են լինում ավելի պինդ, ավելի կարծր կերպ։ Բարդ է փոխարինել բազային տիպ պարունակող մոդուլը այլ արտադրողի մոդուլով, առանց անվավեր անելու կլիենտ մոդուլները, որտեղ այդ տիպը ընդլայնված է։ ԿԿԾ-ն խորհուրդ է տալիս կիրառել միջմոդուլյար ժառանգողականություն միմիայն աբստրակտ տիպերից՝ դա նպատակահարմար փոխզիջում է ՕԿԾ-ի եւ մոդուլյար համակարգերի միջեւ։ Սակայն ծրագրավորողը, իհարկե, իրավացի է ինքը որոշել, արդյո՞ք արժե կոնկրետ համակարգում օգտագործել տիպերի միջմոդուլյար ժառանգողականությունը առանց սահմանափակումների (դրանով իսկ կարծր կապելով մոդուլները իրար), թե այնուամենայնիվ, նախընտրել փոխարինելի, ընդարձակվող մոդուլներ՝ տարբեր արտադրողներից։ ԿԿԾ-ի սահմաններում, «կոմպոնենտ» բառը դառնում է թերմ։ Կոմպոնենտային համակարգը դա մոդուլյար համակարգի այն մասնավոր դեպքն է, որի մեջ կիրառվում է ՕԿԾ։ Քանի որ այժմ ՕԿԾ-ն օգտագործվում է ամենուր, ապա «մոդուլյար համակարգ» կամ «կոմպոնենտային համակարգ» հասկացությունների տարբերությունը գրեթե բացակայում է։ Մյուս կողմից, կոմպոնենտ բառը այժմ չափազանց ծանրաբեռնված է տարբեր իմաստներով, այդ իսկ պատճառով կարելի է գտնել կոմպոնենտոների այլ բացատրություններ։ Քանի որ այժմ դա «նորաձեւ» է, յուրաքանչյուրը այն բացատրում է իր ձեւով։ Օրինակ՝ Delphi-ում կան ուրույն, այսպես կոչված, «կոմպոնենտներ», որոնք բնավ ոչ մի առնչություն չունեն մոդուլյար համակարգերի հետ։ Այս գրառումը ավարտելով դիտարկենք ինչպիսի կոմպոնենտային համակարգեր կան այսօր։ Microsoft ընկերությունը իրականացրել է կոմպոնենտ համակարգի իր մտապատկերը՝ .Net պլատֆորման եւ այդ պլատֆորմայի համար կանոնիկ՝ C# ծրագրավորման լեզուն։ Անկեղծ ասած, .Net համակարգը առհասարակ չի հանդիսանում դինամիկ ընլայնվող մոդուլյար համակարգ, քանի որ նրա մեջ պարզապես բացակայում է մոդուլներ բեռնաթափելու հնարավորությունը։ .Net համակարգերը ավելի շատ նման են մոնոտոն աճող միաձույլ ծրագրերի, մասնակի, հաջորդաբար կոմպիլյացիայով ու բեռնմամբ ըստ անհրաժեշտության։ Իրականում, այս ամենը ավելի բարդ է, որովհետեւ .Net-ում տարբերություն կա կոմպիլիացիայի միավորի (dll կամ exe մոդուլ) եւ բեռնման միավորի միջեւ (assembly)։ Assembly-ն մի քանի մոդուլի տրամաբանական միացումն է մեկ ենթահամակարգում։ Assembly-ների, dll-ների եւ exe մոդուլների մեջ չխառնվելու և առանց ընդհանրությունը կորցնելու պարզության համար ենթադրենք, որ assembly-ն բաղկացած է մեկ մոդուլից, եւ դրանց մեջ ոչ մի տարբերություն չկա։ Մեկ assembly-ի մեջ մի քանի մոդուլի դեպքը սկզբունքորեն ոչ մի բան չի փոխում (բացի բարդացում ավելացնելուց), այդ պատճառով կխոսենք միայն մոդուլների մասին։ Այսպիսով՝ .Net կատարման միջավայրը մոդուլների համատեղելիության վերահսկման համար չի օգտվում վերը նշված մատնահետքերի (fingerprint) մեխանիզմով։ Դրա փոխարեն կիրառվում է մոդուլի տարբերակի համարը հստակ նշելու տեխնիկան։ Դա, իհարկե, ավելի լավ է, քան ոչինչը (ինչպես win32 dll դեպքում), բայց ստեղծում է իր խնդիրները։ Օրինակ՝ եթե .Net մոդուլը արտահանում է կոնստանտ, որը, միգուցե, ոչ ոք չի օգտագործում, ապա, այդ մոդուլի ինտերֆեյսը, այսինքն՝ կոնստանտի արժեքը փոխելով, պետք է փոխել նաեւ մոդուլի տարբերակի համարը՝ այսպիսով անվավեր հանելով բոլոր կլիենտ մոդուլները, նույնիսկ նրանք, որոնք այդ կոնստանտը չեն օգտագործել։ Սա արդեն «dll hell»-ի ճիշտ հակապատկերն է։ Եթե սովորական win32 dll բեռնիչը բոլոր մոդուլները համարում էր համատեղելի, ապա .Net-ի դեպքում բեռնիչը անհամատեղելի է համարում չափազանց շատ մոդուլներ․ ինտերֆեյսում նույնիսկ չնչին փոփոխություն կատարելիս անհրաժեշտ է փոխել ամբողջ մոդուլի տարբերակի համարը։ C# լեզվի մեջ, որը, թվում է թե իր տրամաբանությամբ պիտի հարմարեցված լիներ մոդուլյար համակարգերի ծրագրավորման համար, բացակայում է մոդուլի հասկացությունը շարահյուսական մակարդակի վրա․ ուրեմն, մոդուլի ներմուծման հասկացությունը նույնպես բացակայում է։ C# լեզվով գրված մոդուլի տեքստը կարդալիս անհնար է իմանալ․ ա) ինչպիսի մոդուլներ է այն ներմուծում։ բ) որ մոդուլի մեջ է սահմանված տեքստում օգտագործված այս կամ այն իդենտիֆիկատորը։ Կիրառվող namespace մեխանիզմը կապված չէ մոդուլների անունների հետ։ C#-ը «հին նմուշի» լեզու է, որը հարմար է միաձույլ ծրագրեր ծրագրավորելու համար, ու հարմարեցված չէ մոդուլյար համակարգեր ստեղծելու համար։ Գուցե արդար չէ այդքան խիստ լինել C#-ի հետ, քանի որ .Net-ը ավելի նման է քայլ առ քայլ աճող միակուռ համակարգի, քան դինամիկ ընդարձակվող մոդուլյար համակարգի։ Մեծ պրոեկտներ հարմարավետ ծրագրավորելու համար առաջարկվում է օգտվել ոչ թե լեզվի հնարավորություններից, այլ նախագծման միջավայրի գործիքներից։ Գոյություն ունեն կոմպոնենտային համակարգեր, ու կոմպոնենտային ծրագրավորման լեզուներ, որոնք գրեթե զուրկ են թերություններից։ Դա կարող է զարմանք առաջացնել, սակայն առաջին մոդուլյար համակարգերը հայտնվել են դեռ անցյալ դարի 70-ականների ավարտին։ Օրինակ՝ դա Lilith համակարգչի համար ստեղծված օպերացիոն համակարգն է, որը գրված է պրոֆեսոր Նիկլաուս Վիրտի (Niklaus Wirth) Modula-2 լեզվով։ Այնուհետեւ, նա ու Յուրգ Գութկնեխտը (Jurg Gutknecht) ստեղծել են Oberon օպերացիոն համակարգը նույն անվանմամբ՝ Oberon լեզվի օգնությամբ, որը արդեն կարելի է համարել կոմպոնենտային, չնայած այդ համակարգը ստեղծելու աշխատանքը սկսվել է դեռ 1985 թվին՝ կոմպոնենտային ծրագրավորման հիմունքները հռչակելուց 10 տարի առաջ։ Մեր օրերում, օրինակ, Windows-ի համար գոյություն ունի անվճար (եւ ազատ արտոնագրով - թարգմանչի նկատողություն) տարածվող, 1994թ ստեղծված շվեյցարական AG Oberon Microsystems, Inc արտադրության BlackBox Component Builder կոմպոնենտային միջավայրը։ Նիկլաուս Վիրտը տնօրենների խորհրդի կազմի մեջ է, իսկ հիմնադիրներից մեկը ԿԿԾ «գաղափարային հայր», պրոֆեսոր Կլեմենս Շիպերսկին է։ Ճիշտ է այժմ նա աշխատում է որպես software architect Microsoft Research-ում։ Ամենասկզբից BlackBox համակարգը անվանվում էր Oberon/F եւ նախագծվում էր Oberon-2 լեզվով MacOS եւ Windows համակարգերի համար։ Այնուհետեւ Oberon-2 լեզուն փոփոխված էր ԿԿԾ նորաձեւ գաղափարի համաձայն։ Նոր լեզուն ստացավ Կոմպոնենտ Պասկալ (Component Pascal) անունը (1997)․ դա Oberon-2-ի արդյունաբերական տարբերակն է։ 2004 թվին BlackBox-ը հայտարարվել է անվճար, (իսկ ծրագրի կոդը՝ ազատ - թարգմանչի նկատողություն)։ Կամավորները ստեղծում են BlackBox-ի տարբերակ Linux (GNU/Linux - թարգմանչի նկատողություն) համակարգի համար (արդեն կա ալֆա տարբերակը)։ Իսկ Oberon Microsystems-ը ներկա ժամանակ աշխատում է համակարգի նոր տարբերակի վրա։ BlackBox-ով ստեղծված է Ամազոն գետի վրա գտնվող աշխարհի ամենամեծ հիդրոէլեկտրոկայանի հսկման համակարգը։ Դրա համար ստեղծվել էր BlackBox-ի հատուկ տարբերակ 64 բիտանի Unix-ի համար։ Borland ընկերության պատվերով Oberon Microsystems ընկերությունը գրել է Java-ի JIT կոմպիլյատոր։ Բացի դրանից, Oberon Microsystems-ում Կոմպոնենտ Պասկալով գրված է Portos իրական ժամանակի օպերացիոն համակարգը (չշփոթել PortOs-ի հետ, որը լրիվ այլ համակարգ է)։ Այնուհետեւ Portos-ը վերանվանվեց JBed, իսկ Oberon Microsystems-ից առանձնացվեց Esmertec ընկերությունը։ JBed-ը ավելի շատ հայտնի է որպես իրական ժամանակի օպերացիոն համակարգ embedded սարքերի համար, որը գրված է java-ով։ Ի նկատի ունենալով Java-ի լայն տարածումը եւ Component Pascal-ի թույլ ճանաչվածությունը՝ պետք է խոստովանել, որ դա հաջող մարկետինգային քայլ է։ Ռուսաստանում վերջերս հայտնվել է ընկերություն, որը հայտարարել է որպես հիմնական արտադրամիջոց BlackBox Component Builder համակարգը օգտագործոլու մասին։ Գոյություն ունի «Ինֆորմատիկա 21» միջազգային պրոեկտ, որի նպատակներից մեկն է BlackBox համակարգի առաջխաղացումը դպրոցներ, բարոյապես հնացած Turbo Pascal-ի փոխարեն։ Եթե փորձել պատասխանել այն հարցին, թե որն է ավելի լավը՝ BlackBox-ը թե Java-ն, ապա պետք է հաշվի առնել, որ բարդությունը թերություն է, իսկ .Net-ն եւ Java-ն անհամեմատ ավելի բարդ են։ Իսկ բացի BlackBox-ից գոյույթուն ունեն մի շարք հետազոտական մոդուլյար համակարգեր։ Ուզում եմ շեշտել Aos BlueBottle օպերացիոն համակարգը (այժմ A2, թարգմանչի նկատողություն) որը անմիջապես «երկաթի» վրա ապրող ակտիվ օբյեկտների հիման վրա ստեղծված առաջին եւ միակ համակարգն է։ Այն ամբողջությամբ գրված է Active Oberon լեզվով։ Համակարգի կատարման միջավայրը իրականացված է անմիջապես «երկաթի» վրա։ Սակայն, դա արդեն այլ պատմություն է։ բնորինակը
ու տենց
Շատ բարդ էր այս գիրքը գտնել։
Ու վերջապես գտա, օգտագործածը։
Իրան խորհուրդ էր տվել Creenshaw-ն իրա քոմփայլերների գրքում։
POINTER TO սինտաքսը հայտնվեց Մոդուլայում։
Նախկին գրքի տերը հաստատ փորձում էր թարգմանել ծրագրի տեքստը Պասկալից Մոդուլա, կամ Օբերոն։
Մոդուլայում և Օբերոնում արդեն չկա function բառը, կան միայն PROCEDURE ներ։ ։Ճ
ու տենց
Սա երրորդ մասն ա։
Ասենք սա ինձ թաչ ա անում՝
<blockquote style="border: 2px solid rgb(127, 195, 59); padding: 10pt; margin-left: 30pt; background-color: #a6df6d;">
<p>
try not to do things you don’t understand<br /> and if you are forced to do things you don’t understand, then at least, do not speak about things you don’t understand
</p>
und so weiter
Ստանդարնտները լավ բան են։ Ինչ որ ստանդարտ պետք ա լինում։ Նույնիսկ ասենք շփման մեջ, միմյանց հասկանալու համար։ Կամ թերմերի մեջ, կրկին՝ հասկանալու համար։
Սակայն, երբ ստեղծում եք նորը ստանդարտին հետևելը, կամ համապատասխանելը հաճախ բերում է վատ որոշումներին, ու վատ դիզայնին։
Ասենք, երբ Ստրաուստրուպը C++ նախագծելուց փորձում էր պահպանել C-ի հետ համատեղելիությունը, դա բերեց ինչպես տգեղ լուծումների, այնպես էլ լեզվի չաղացմանը։
Ուինդոուս/Սոլարիս-ներում – պահպանել նախկին տարբերակների հետ համատեղելիությունը որոշումը բերեց գրադարանների չաղացմանը։
Ի տարբերություն, Վիրտը, նախագծելով Մոդուլան որոշեց չպահպանել պասկալի հետ համատեղելիությունը։ Փոխարենը, նա գրեց քոնվերթեր, պասկալից մոդուլա տրանսլացիա անելու համար։ Նույնպես նա վարվում էր և հետագայում, Մոդուլայից Օբերոն քոնվերթեր գրելով, քանի որ հասկանում էր՝ համատեղելիությունը պահպանելը կբերի տգեղ դիզայնի։
Բաց ԾԱ-ի աշխարհում համատեղելիություն պահպանելը իմաստ չունի։
Փոխվեց գրադարանը՝ փոխվում է ծրագիրը որը այն օգտագործում է։ Եթե ծրագրի հեղինակը հետաքրքրված չէ, դա անում է մեյնթեյները կամ յուրաքանչյուր մեկը ում այդ ծրագիրը պետք է։ Այսպիսով, բաց ԾԱ-ն չունենալով համատեղելիության շերտ՝ ավելի նիհար է։
Ինչպես ես արդեն գրել եմ, կարգինը՝ արտակարգ լինել չի կարող։
Այս պատճառով Պլան9-ը և Ինֆերնոն, որոնց դիզայնի մեջ, ի դեպ, անկերես է Օբերոնի ազդեցությունը, չեին կարող հետևել սովորական Յունիքս/Պոսիքս ստանդարտների։
Ու պարզ է որ նրանք լայն չեն կիրառվում այն պատճառով, որ ծրագրերի մեծ մասը գրված է տեքնոլոգիաներով, որոնք անհամատեղելի են Ինֆերնոի հետ։ Օրինակ, C-ով կոդ այնտեղ ափլիքեյշն լեվել չի օգտագործվում, դրա համար կա Լիմբո։
Սակայն, նոր դիզայն կարող է իրեն թույլ տալ կորմորացիա որը նախագծում է ու տարածում նոր համակարգ։
Ես Անդրոիդ-ի մասին եմ։
Գուգլը լինուքս միջուկի հիման վրա ստեղծել է «նոր» համակարգ, ձեռք է բերել նոր ջավա վիրտուալ մեքենա։
Դրայվերների խնդիր մոբայլ սարքերի համար չկա՝ միևնույն է լիքը նոր դրայվեր գրվել է։
Լինուքսից օգտագործվել է սքեդուլերը, թիսիփի սթեքը, և այլն։ Սի-ով ափլիքեյշն կոդ գրելն նախատեսված չեր։
Այսինքն, կարելի էր անել համակարգ, որտեղ կան դիզայնի նոր ընտրություններ, ինչպես ընդհանուր հասցեական տարածությունը։ Բայց էդպիսի բան արված չէ։ Ընդ որում Լինուքս միջուկի քաստոմիզացիայի վրա այնքան ռեսուրս է ծախսվել, որ այդ ուժերը անհրաժեշտ էր ծախսել Ինֆերնոն փրոդաքշն և մոբայլ սարքեր բերելով։
Որովհետև նոր է, արագագործ, ու գեղեցիկ։
ու տենց
Գիտեք որ արհամարհանքով եմ վերաբերվում ջավա/դոթնեթ/մոնո/քորփորեյթ/էնթերփրայս և այլ իմպերիալիստական չաղ և քաղքենիքաղցած գործիքներին։
Տեխնոլոգիապես։
Ընդհանրապես փորթաբլ լեզու ունենալու գաղափարը լավն է։
Այսինքն մի լեզու որով ոնց էլ գրես, ամեն ինչի վրա քմփայլ կլինի։
Ու ոչ թե նենց ոնց որ ասենք սի-ն որ ասենք եթե ԳՆՈՒ սի քմփայլեր ամեն տեղ կա, ուրեմն ֆսյո։
Չեմ ֆսյո չի բնավ, քանզի ասենք դուք շիֆտ-միֆտ անու՞մ եք։ Վաաաայ, բա էնդիաննեսսը մոռացա՞ք։
Բա տիպերը ձեր մոտ ի՞նչ չափսերի են։
Էթեսեթտրա։
Ու էդ տեսանկյունից իհարկե վատ չի որ ինչ որ տենց բան փորձել են մտածել։
Բայց սպասե՛ք։ Բանն այն է որ լիքը այլ լեզուներ ստեղծվել են հենց փորթաբիլիթին մտքին ունենալով։
Քանզի Լիսպը նա լյուբիծելյա ա, ապա հեռու չգնալու համար հիշեմ Ադան, որտեղ տիպերը առհասարակ ռանջերով են նկարագրվում, ասենք
type Range_Type is range -5 .. 10;
type Angle is delta Pi/2.0**31 range -Pi .. Pi;
Կարող եմ նաև նշել Լիմբո-ն, որը Ինֆերնո համակարգի հիմնական ծրագրավորման լեզուն է։
Ու եթե Լիմբոն համեմատաբար նոր է (իննսունականներ)
ապա Ադան վաղուց կար ու ջեներալփուրփոս է։
Սակայն մարկետինգը ասում է որ սիրուն չէ անել Սան Ադա Մաշին։ Ավելի լավ է մի նոր բան մտածել։
Ջավան ռադիկալ ա, սակայն բնավ ազատ չէ։ Այսինքն, գրել միմիայն օբջեքթ օրիենթեդ պետք չէ։
Լիքը խնդիր կա երբ օբյեկտները լրիվ ավելորդ են։
Մի ծրագրավորող ասում էր որ երբ ջավայով ա գրում, հա պատերի ա իրան խփում։ Քայլ ձախ, քայլ աջ՝ պատ։
Ու դրանք ոչ թե ասենք թայփ տեստեր են որոնք օբյեքտ լեզվին շատ անհրաժետ են, այլ ասենք վիրտուալ մեքենան։
Սինտաքս։
Կրկին մարկետինգ։ Սի-ի սինտակսի թերությունները մնացել են։
x=x+1 – ներեցեք, ո՞նց եք բացատրելու մարդուն էդ ո՞նց ա x-ը «հավասար»։ Չէ՞ հավասար չէ բնավ։ Վերագրվու՞մ ա։
Ապա վերագրման նշան կիրառեք, որը ընգծում ա անհավասարակշռությունը։
Այդ նշանը Ալգոլի ժամանակներից կա՝ :=
Չի դզում՝ նորը մտածեք։
Ու ասեմ որ Յունիքսի ստեղծողները իրանք ով նախագծել են Լիմբոն, արդեն այնտեղ կիրառում են հենց այդ նշանը։
Լիմբոն և Օբերոնը ինսփայր են արել Գոու, որին խորհուրդ եմ անում ուշադրություն դարձնել։ Չնայած, իրա մեջ դեռ ռեալիզացիա արած չեն շատ հնարավարություններ, որոնք կան պարզ Օբերոնում, բայց դա հիմա էական չէ։
Էդ նաև ազատում ա == որպես էքվալիթիի նշան օգտագործելուց։
Առհասարակ, ==, <> սխալի բուն են։ Նիշերից մեկը չտպվեց՝ հետո լիքը մարդ տառապում ա խնդիրը գտնելով։
Ու մի ասեք, փորձառու ծրագրավորողը տենց սխալ չի անի։ Ինչի՞ փորձառուն տենց հիմար բաներով պիտի տարբերվի անփորձից։ Փորձառուն մի քիչ այլ գաղափար ա։ Տենց հիմար փորձ պետք չէ բնավ։
Ռեալիզացիա։
Դիտարկենք ՋՎՄ/ՋԴԿ և գցջ։
ՋՎՄ-ի շերտը շատ ծանր է և չաղ։
Մասշտաբիրուեմոսծը բացակայում է։
ՄԵ-ն միկրո էդիշն ա, այլ ոչ թե ստանդարտ մեքենայի քոր, որը էքստենսիբլ ա լինում, ու դառնում ստանդարտ փլագիններ ավելացնելով։
Էքսթենսիբլիությունը – սիրուն լուծում ա։ Տարբեր էդիշններ՝ տգեղ և հիշեցնում է հենակներ, որոնք, անկասկած շատ են կիրառվել ռեալիզացիայի ժամանակ։
Վիրտուալ մեքենան ուտում է հիշողություն և մինչև վերջերս բաց չեր։
Ու որպես կանոն ջավա կոդը անհամեմատ դանդաղ ա կատարվում։
Իմ խորհին համոզմունքն է որ մենք ժամանակից թանկ բան չունենք։
Այսպիսով ծրագրի վրա թող նախագծողները ավելի երկար աշխատեն, բայց մենք քիչ ժամանակ սպասենք ամեն անգամ։ Սակայն, իրականությունն այն է որ դա հակասում է մարկետինգի և բիզնեսի շահերին։
Ինչքան արագ գրվի սոֆտը, այդքան արագ շուկա կհանվի, այդքան քիչ փող կծախսվի նախագծման ընթացքում։
Ջավայի տորմոզնուտոսծի շատ հավես իլլյուստրացիա կա։
Ռուսները Տոմմի անունով ռոբոտ ունեին։ Ինքը մասնակցում էր ԴԱՐՊԱ-ի կազմակերպած րեյսինգի մրցույթին։ Եվ սպանվեց իրան ապստենու գլուխը պատով տվեց։ Երևի ԳՑ-ն էր միացել։ Այդ դեպքից հետո ծրագրավորողների մի մաս սկսեց համաձայնվել ջավիստների հետ այն մասին որ «ջավա նե տարմազիտ»։
Իմ իմացած յուզերների մեծ մասը զզվում ա ջավա ափլիքեյշններից․ «նրանք ծանր են, դանդաղ և այլն» պատճառաբանություններով։
Այդ իսկ պատճառով հիմա ջավան հարկադրվել է հեռանալ քորփորեյթ լուծումների ասպարեզ։ Դեսքթոփ ափլիքեյշններ անտեսելի քիչ են։
գցջ-ն՝ քմփայլ է լինում նեյթիվ կոդ, լինկ էր լինում սի և այլ գրադարաններին, նույնիսկ աղբ թափելը իրականացվախ է Հանս Բոեհմի Սի/ՍիՓլասՓլասՔոլեկտորով ։ Ահագին գործ իրան լավացնելու մաջ արել է ՐեդՀատը, որը ասենք, ժամանակին պատչեր արել որ Թոմքատ իրանով քմփայլի։
Այս իրականացումը վատը չէ, նույնիսկ լավն է, սակայն իրանով լիքը բան անել չի լինի։ ՋԴԿ-ի օփենսոուրսացումը կարող է խոչընդոտել այս լուծման հետագա զարգացմանը։
Արտաքին տեսք։
Ջավայի Սվինգ ուիդջետներից տգեղ բան չկա։ Մոտիֆը նույնիսկ սիրուն ա դրա հետ համեմատ։ Այսպիսի բաներից հետ տալս գալիս ա։ Լուրջ։ Սիրտս խարնում ա։
Ընդ որում ուինդոուսում էդ ուիդջետներով հաճախ հասարակ մաուսի սքրոլ չի աշխատում։ Լինուքսում ի դեպ՝ աշխատում ա։
Եթե ԱյԲիԷմի ՍՎՏ թուլքիթը չլիներ (էկլիպսի ուիդջետները դրանով են արած) ի՞նչ էիք անելու այ դեվելոպերներ։
Իդեոլոգիապես։
Իմ կարծիքով,
Ջավան ինքը իրա դիզայնով օփեն սորսին խփում էր՝ տիպա մեզ պետք չեն իսխոդնիկներ պորտ անելու համար, այլ պլատֆորմային, քանզի ամեն պլատֆորմայի վրա մի վիրտուալ շերտ կա։
Ու ջահնդամը որ լիքը հիշուղություն ա ուտում այդ շերտը, և հիմնականում դանդաղ են աշխատում ծրագրերը։
Սաղ հեչ։ Փաստորեն հիմա ստացվում ա որ նույնիսկ նենց տգեղ լուծումը «լավն» ա դարնում երբ այֆոնը կապվում ա օբջեքթիվ-սի-կակաո վիճակներին փորթաբիլիությունը խոչընդոտելու նպատակով։ Ի դեպ, էփլին լավ կհարվածի ՔյուՏի պորտը։ Թե սիպլասնել են բան անելու։ Ո՞ր պատճառաբանությամբ։
Հա, ու ասենք ծանոթ եմ տեսնում Սոնի Էրիկսոնով, ասում եմ՝ լավ ա չի բողոքի որ բան չի կարողանում տեղակայել, քանզի իրա մոտ, ջավա կա՝ աշխատում ա լիքը բան։
Չնայած ՄԵ-ի ռեալիզացիան նենց աղքատիկ էր վախտին, ասենք թափանցիկ սպրայտեր չկային։ Չգիտեմ հիմա ավելացրել են թե ոչ։
Իսկ նապասլեդըկ խորհուրդ եմ տալիս նայել սա ու համոզվել թե ով է ջավամանը իրականում ։
_ու տենց _
I guess nobody would be interested, just ignore this message.
Of course, not much sense without multitouch support(that was irony), but here it is, as a proof:
(drum roll)
Oberon V4 (Kepler version, Linz, Austria) running on top of maemo on my Nokia N810 🙂
WHERE IS THE MIDDLE CLICK OF THE MOUSE ??????
I will try to not forget, and write in details about this, and my other Nokia N series hacks.
_und so weiter _
[այստեղից][1]
_ու տենց _
[1]: http://groups.google.am/group/comp.lang.oberon/browse_thread/thread/ffe11b45037375e0/e8b65d37114d4931?hl=hy&ie=UTF-8&oe=utf-8&q=andreas+borchert+c+interfaces#e8b65d37114d4931Я уже писал о том, какие девушки мне не нравятся
Время собирать камни делать статистический анализ spss sux, R rulez, какие – нравятся.
Итак, я подметил связь.
Те, кто нравится, обязательно, непременно, и неуклонно имеют тенденцию уезжать заграницу. Или там и находятся.
Причем, чем больше нравятся, тем скорее уезжают.
Одна девушка, которая мне безумно понравилась, уехала спустя день после знакомства.
Только успел написать – а ответ – “Я уже в Москве”.
Сейчас встречается с парнем, который ей читает по ночам между делом Бродского. Ну девочка, я ведь лучше собаки(ц) … я бы тоже почитал, а придачу и Севака в оригинале … он ведь не сможет… (флейм Севак вс Бродский будет баниться грубо, но аккуратно)
Или, катаясь на велосипеде, клеет девочек. Нет, нет – я не осуждаю. Я анализирую.
У нас есть много общего. Я тоже люблю кататься на велосипеде, и тоже (надо же!) интересуюсь девушками.
Вот она – общность интересов, ценностей и духовная близость.
Эх, *\*, **** (за звездочками имя, повторяется два раза), я не хочу твоего замороженного винограда шоколада…
Одна убежала от чрезмерно пристального внимания родителей. Другая смоталась в холодные края со своим новоприобретенным парнем. (Ехать за кем-либо тоже больше не стану).
Третья – учиться, но отпустили лишь к злой бабушке, которой нужно показать резюме парня, прежде чем та разрешит с ним встретиться (срсли! резюме!). Еще одна – как и все, с отмазкой об учебе – уехала кататься на велике 🙂 Ага – опять – велик 🙂 А *** не расстается со своей Канон камерой и у нее крепкие отношения уже много лет. Я ведь тоже не расстаюсь со своей Канон камерой, даже если вывожу собаку в три часа ночи!
И когда встретишь ту, кто тебе на самом деле нравится – значит – либо парень уже есть, либо – она вот-вот уедет. За *** даже приударять не собирался, просто симпатизировал – и что вы думаете – уехала! Кто-нить здесь остается? Вроде да – не пустой город – и?
При встрече с понравившейся девушкой еле сдерживаюсь, чтобы не спросить: – “а ты, ты-то куда собираешься? уже завтра? или может,(со слабой надеждой в голосе) может, все-таки через неделю?”
Так, что им вра галови а. Точнее, гналови. 🙂
Ну понятно, это не рациональное обьяснение.
Идеи.
Поэтому приступим к формализаии, и для начала опишем в удобной нотации
TYPE GirlILike = OBJECT (human)
SheLikes : SET := {bike, camera, herboyfriend, scifi};
SheLeaves : BOOLEAN; (* set as TRUE during initialization of an object *)
CurlyHair : POINTER TO ARRAY OF Hair;
InARelationship: BOOLEAN; (* almost always set to TRUE, which perfectly fits Murthy’s theory *)
Это лишь подмножество интерфейсной (видимой) части.
И они обусловлены безумным количеством не видимых, скрытых, инкапсулированных черт (private)
Однако – имеющий глаза да увидит. Вот оно – нашел. Не простой обьект, а активный. (Do the fish girl really need remote control?)
То есть обязательно наличие секции activity
BEGIN {ACTIVE}
…
END
Этим и обусловлены интерфейсные – SheLeaves, TakesRisks, и т. д.
Ну и другие методы в наличии, типа
PROCEDURE WannaLisPoetry (Author : SET) : BOOLEAN;
BEGIN
IF Author IN {Brodski, Pasternak, Akhmatova, Cvetaeva} THEN
RETURN TRUE
ELSIF Author IN {Sevak, Charents, Mandelshtam} THEN
Think (10); //in seconds
RETURN TRUE
ELSE
RETURN FALSE
END;
END WannaLisPoetry;
Свойство InterestedInARelationship – константно – FALSE
Не меняется ни при каких обстоятельствах.
Оно и понятно, они, эти рилейшншипс, либо уже есть, а если их нет, то и так жизнь хороша и интересна.
Отвлекусь на секунду от темы. Меня много спрашивают, почему следуя крысакану нельзя задавать личные вопросы. Отвечаю: описанная в крысакане функция DoYouHaveABoyFriend реализована так:
PROCEDURE DoYouHaveABoyFriend() : BOOLEAN;
BEGIN
RETURN TRUE
END DoYouHaveABoyFriend;
а иногда так:
BEGIN
IF InARelationship THEN
RETURN TRUE
ELSE
RETURN TRUE
END;
END DoYouHaveABoyFriend;
что обычно оптимизируется компилятором к первому варианту. 🙂
Вернемся к нашим овечкам тараканам.
Еще одна константа, always set to TRUE – Independent.
Еще одно property – “Самостоятельность” может временами меняться, но стремится к TRUE, потому, что – смотри выше.
Отсюда:
PROCEDURE DontDoIt(smth: VARIANT);
BEGIN
DoIt(smth);
Out.Message(“fuck off”) (* this may vary depending on cultural features *)
END DontDoIt;
Еще одно очень важное свойство – Creativity․
Пишет – может стихи (если хорошие – то наповал), фотографирует, рисует, что-нить вообще делает по жизни, а если ничего не делает – то креативность и творческий подход все равно заметны и льются через край.
Это свойство и обьясняет почему те, кто мне нравятся – уже in a nice relationship. Потому, что according to Abraham Maslow’s hierarchy of needs – творчество, самоактуализация, как ступень развития человека возможна только после удовлетворения более “низкоуровневых потребностей” – проще говоря творчество проявляется так как она уже в хороших, счастливых отношениях. 🙂
И меня “цепляет” даже намек на креативность – Увлеченность – Keenness.
Таким образом, секция ACTIVITY заполняется
BEGIN {ACTIVE} //equal to WHILE (Alive) DO
activity := SearchForSmthInteresting();
WHILE (stillinteresting) DO
DoIt(activity)
END;
END
Значит, есть в этих девушках что-то общее, и даже вырисовывается – что!
Им не сидится на месте. Они активные, и не бояться рисковать. Они независимые, самостоятельные, и Ինքնուրույն – от слова ուրույն։
Они креативны, увлекаются, не страдают от недостатка внимания. Им обычно есть чем интересным заняться.
Они живые.
И у них очень интересный взгляд, замечательные глаза – независимо от их цвета
Это и делает девушку привлекательной для меня. Интуитивно.
Следовательно, я не мазохист, и я не избегаю отношений! Однако почти наверняка обречен на дистант рилейшншипс.
Every relationship sux – distant relationship suck distantly.
Чтож, так тому и быть.
_ու տենց _
взято у old_dilettante{.lj-user}
—
Вот такой текст запостил Давид Толпин в список рассылки Brain Users Group{.snap_shots}:
мне пришли откровения про лопаты и языки программирования.
Haskell и Схема – это сферические лопаты в вакууме. Они внутренне совершенны и
стройны, но ими довольно трудно копать. Разве что вакуум.
Common Lisp – это лопата, с кривоватой ручкой и слегка ржавым ножом, но
пригодная для копания. Испытываешь легкую досаду от неуклюжестей, но работаешь.
C++ – это такой предмет, на рукояти с одной стороны – лопата, с другой – грабли.
Можно делать все, что угодно, но либо отрезаешь себе что-нибудь лопатой, или
протыкаешь граблями.
Python – это пластмассовая лопата. Очень красивая и удобная, но копать ей можно
что-то мягкое и легкое; иначе не выдерживает и ломается.
Java – это лопата с прорезями, или грабли с широкими зубьями. При помощи нее
можно как плохо копать, так и плохо грести.
Perl – это не лопата. Это мотыга. Можно очень хорошо копать, если очень хорошо
умеешь, иначе ничего не выходит.
C – это лопата без ручки. Либо трахаешься по локоть в грязи, либо приделываешь к
ней ручку, после чего получается просто самодельный лисп.
—
Добавлю от себя, когда меня спрашивают про Оберон, я часто говорю: Это как латинский алфавит, когда из букв нужно составлять слова, против китайских иероглифов (c++), где на каждое слово предусмотрен отдельный знак.
Active Object System for Unix preview versions available for download
upd: link above currently doesn’t work, new builds are here
Recently I have managed to port oo2c Oberon compiler to a number of nmos6502 based platforms including
Atari 8 bit
Apple ][
Commodore
Pet
Oric Atmos
NES
oo2c is two pass Oberon-2 language compiler. First pass generates abstract syntax tree and second pass generates target machine code. Currently oo2c generates very optimized ansi-c code.
That code is very similar to assembler, with many goto statements etc.
oo2c developers prefer to use C as a portable assembler and for that reason it is possible not only to write in Oberon-2 language for most of the platforms but also to easily port it to any platform if there is C compiler available for it.
Initially Stewart Greenhill who sometimes deal with embedded systems and avr micro controllers have been written minilib and changed oo2c code so it could generate code for 8 bit cpus. I have changed minilib so it could be compiled with cc65 c compiler which generates code for many 8 bit 6502 based platforms. That is why now one can write object oriented code for nmos 6502 platforms 🙂
Compiler port is available for download at http://sourceforge.net/projects/nmos6502-oo2c