պարզւում ա, հնարաւոր չի էփլի ափսթոր լցնել որեւէ բան, որը շինած ա gcc֊ով, կամ դրա վրայ հիմնուած կազմարկիչով։
այդ պատճառով, օրինակ, չի կարելի ադայով գրուած յաւելուած վերբեռնել՝ ադա կազմարկիչն այս պահին հիմնուած ա ջիսիսիի վրայ։
էփլը տարօրինակ պահանջներ ունի, զի ջիսիսի֊ով կարելի ա շինել նաեւ սեփականատիրական ծրագրակազմ։
ու ես հասկանում եմ որ էփլը վաղուց պատկերացնում էր ինչ տեսակի սահմանափակումներ են ուզում ունենալ, այդ պատճառով էլ ֆինանսաւորում էր llvm նախագիծը՝ որը կը լինի ֆորմալ ազատ, բայց իրենց պահանջներին կը բաւարարի։
նախ, պէտք չի էփլի բարութեան մասին պատրանքներ ունենալ՝ llvm֊ը բնաւ էլ էփլի նուէրը չէր համայնքին, այլ ստեղծուած իրավիճակում, երբ ազատ ծրագրակազմի շարժումն արդէն ուժեղ էր ու նախագծողները սովոր են ազատ գործիքների, եւ gcc֊ին բաւական զարգացած էր ու վաղուց ունէր բազմաթիւ ֆրոնտէնդներ, էփլին պէտք էր կարողանալ առաջարկել նախագծողներին ընդունելի այլընտրանք։
երկրորդը՝ շնորհակալութիւն fsf֊ին ու rms֊ին՝ մենք արդէն ունէինք ազատ գործիքներ, եւ էփլը մրցունակ լինելու համար ստիպուած էր իրենց կազմարկիչների նախագիծը ազատ դարձնել՝ այլապէս ունենալու էինք ոչ ազատ llvm, որով գուցէ նոյնիսկ արգելուած լինէր, կամ հնարաւոր չլինէր ոչ էփլի հարթակների համար ծրագրեր կազմարկել։
երրորդը՝ ես չեմ կարող գրել այօսի համար շատ լաւ ու շատ տարբեր ազատ գործիքներով՝ զի ֆաշիստ են։
չեմ կարող նաեւ իմ քոմփայլերով։ ու չեմ կարող նաեւ վերբեռնել ազատ ծրագիր՝ պիտի փակեմ, որ ըստ իմ արտօնագրի նոյնպէս չլինի տարածել իմ ծրագիրը՝ որ համատեղելի լինի գուգլի կամ էփլի կանոնների հետ։
եւս մի պատճառ էփլը չսիրելու, ու bsd արտօնագրերը չսիրելու։
բաւական տհաճ էր նաեւ պատմութիւնը, երբ vlc նուագարկիչը չէր կարելի աւելացնել գուգլի «փլէյ սթոր»՝ զի ըստ gpl արտօնագրի չի լինի մարդուց խլել ստացած ծրագիրը տարածելու ազատութիւնը։ իսկ գուգլը ուզում էր չթողնել ներբեռնուած յաւելուածը նոյնիսկ պահել մօտդ, կամ այլ սարքի մէջ տեղակայել։ վճարե՛լ ես ծրագրի համար, ոնց որ քո՛նն ա, բայց մէկ ա պիտի կախուած լինես գուգլից։
նոյնիսկ ազա՛տ ա ծրագիրը՝ vlc֊ն ա, որ հազար տարի գիտենք՝ բայց պարզւում ա այն պէտք ա դարձնել անազատ՝ խանութում ձրի ներբեռնելու հնարաւորութեամբ տեղաւորելու համար։
ու նուագարկիչի թիմը ստիպուած եղաւ կապուել նախագծին աջակցած բոլոր֊բոլոր կոդի քոմիթերների հետ եւ համոզել ռելայսնսել կոդը bsd արտօնագրով։
եւ ո՞նց են դրանից յետոյ ասում, որ bsd֊ն աւելի ազատ արտօնագիր ա՝ դրա օգնութեամբ մարդկանց զրկեցին ձեռք բերուած եւ ազատ ծրագիրը տարածելու իրաւունքից, ազատութիւնից, պարտադրելով խոշոր ընկերութիւնից կախուածութիւն, ու փաստացի մենք ունենք իրավիճակ, երբ bsd արտօնագիրը սատարում ա մենաշնորհներին։
#ադա #ծրագրաւորում #կազմարկում #կազմարկիչ #արտօնագիր #մենաշնորհ #էկրանահան #էփլ #ֆաշիստներ #գուգլ #ազատութիւն
այստեղ լինուսն ասում ա որ սերուերային հարթակի ճարտարապետութիւնը պէտք ա լինի ծրագրաւորողի հարթակի ճարտարապետութեանը մօտ։
յիշեցի այս յօդուածը՝ zx spectrum ֊ի համար ծրագրաւորման մասին. նշում ա, որ օգտագործում էին նոյն ճարտարապետութեան իրական պրոցեսորներ՝ սերուերի վրայ։
Սպեկտրում ծրագրաւորելու բոլոր գործիքներն աշխատում էին CP/M֊ի տակ՝ դա ստանդարտ օպերացիոն համակարգ էր միկրոհամակարգիչների համար մինչեւ MS-DOS֊ի տարածումը։ CP/M֊ը նախագծուած էր 8080 եւ Z80 պրոեսորների համար, եւ երկու Z80֊ներով տպասալ ապրում էր VAX֊ի մէջ՝ օպերացիոն համակարգ աշխատեցնելու եւ օգտատէրերին սպասարկելու համար։ Եթէ երկու հոգի արդէն օգտագործում էին տպասալը, ապա ձեզ մնում էր Z80֊ի ծրագրային էմուլեատոր VAX֊ի պրոսեսորի վրայ — ինչը լրիւ քամում էր իր հզօրութիւնը, դանդաղեցնելով աշխատանքը բոլորի համար։
#պրոցեսոր #ճարտարապետութիւն #նախագծում #կազմարկում #ծրագրաւորում #վաքս #սպեկտրում #օպերեցիոն_համակարգեր #լինուս #պատմութիւն #ռետրո #ռետրոհամակարգչութիւն
հաւէս յօդուած ա սա շատ՝ 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 դաշտ։
սա ռանթայմ տեղեկատւութիւն ա, ու այս դէպքում արդէն մեզ պէտք ա պահել առանձին դաշտ տողի երկարութեան համար։
ու տէնց։
#օբերոն #ծրագրաւորում #տող #տողեր #պասկալ #սի #վիշապ #իրականացում #կազմարկում #կոմպիլյատոր #կոմպիլեատոր #կազմարկիչ
երէկ տառապել եմ դեբիանի փաքաջինգի հետ։ եւ ջենքինս բիլդերի։
ուզում էի photolightmeter֊ը աւելացնել maemo-leste֊ի ռեպօներ։ ահաւոր երկար տեւեց։
ամենաբարդ խնդիրն էր, որի վրայ լռուել էի՝ բիլդ լինում էր ինձ մօտ, բիլդ լինում էր իրենց վմ֊ի մէջ, բայց չէր լինում նման վմ֊ի մէջ ջենքինսում։ որն արդէն երեք պլատֆորմի համար շինում ա՝ amd64, armhf, arm64։ ծրագիրս գրուած ա պասկալով, օգտագործում էի lazbuild այն կազմարկելու համար։
ուրեմն, սէնց փախած սխալ էր տալիս՝
Fatal: (10022) Can’t find unit FastHTMLParser used by Clipbrd
ուրեմն էս lazbuild֊ը չգիտեմ ինչի չէր հաւանում եղած քոմփայլ արած .o ու .ppu նիշքերը որ գալիս են իր հետ՝ LCL գրադարանի մաս են, կամ նրանք, որ ստանդարտ ֆրիպասկալի մաս են, ու ուզում էր կրկին կազմարկել ելատեքստից։
իսկ դէ փաթեր չէր գտնում։
տեղակայեցի fpc-source-3.0.4 ու դրա մէջ գտայ այդ fasthtmlparser.pas֊ը։ արդէն շինում էի ոչ թէ lazbuild֊ով այլ հէնց fpc֊ն կանչելով ու երկար երկար փաթեր տալով ամէն մի գրադարանի։
տուեցի՝ սա՝ -Fu/usr/share/fpcsrc/3.0.4/packages/chm/src/ — ոնց որ պէտք ա հէնց առանց բացատ աւելացնել -Fu արգումենտին
էլի չի գտնում։ վերջը դրա վերեւի դիրեկտորիայում գտայ ինչ֊որ fpmake.pp
root@devuan:/usr/lib/x86_64-linux-gnu/fpc/3.0.4# ls /usr/share/fpcsrc/3.0.4/packages/chm/
Makefile.fpc fpmake.pp src
root@devuan:/usr/lib/x86_64-linux-gnu/fpc/3.0.4#
ու յիշեցի որ ինչ֊որ fpmake կայ, որը փաքաջներ ա սարքում, ու այդ ուղին տուեցի նաեւ քոմփայլերին։ եւ այո, ստացուեց։ կազմարկուեց։
ապա միակ խնդիրը որ մնացել էր՝ ռեսուրս կոմպայլերը՝ fpres֊ը չէր գտնում։ որովհետեւ ես fpc֊ն կանչել եմ լրիւ ուղղով՝ /usr/bin/fpc, իսկ այ որտեղ ա fpres֊ը չէր գտնում։ չգիտեմ, գուցէ makefile֊իս մէջ պէտք ա ինչ֊որ աւելի յստակ PATH֊ը export անէի, բայց fpc֊ն յատուկ արգումենտ ունէր իր ուզած բինարնիկները գտնելու համար՝ -FD, այսպիսով աւելացրի՝ -FD/usr/bin ու յէյյյ, եղաւ քոմփայլը։
էդ ամենակարեւորն էր։
յետոյ պարզուեց որ armhf մեքենայի վրայ մէկ ա կազմարկումը չի անցնում։ ու չգիտես ինչի էնտեղ fpc֊ն աւելի շատ բան ա ուզում կազմարկի ու չի գտնում։ երեւի դեբիանի armhf սբորկան մի քիչ այլ ձեւ էր, չնայած նոյն վերսիաներն էին ծրագրերի, ու նա ուզում էր աւելի շատ լիբ ինքը շինել, քան արդէն ստացել էր։ ու օկ, էդ արդէն բարդ չէր՝ պոչը բռնել էի։ ինչը ասում էր որ չի գտնում, գտնում էի lcl֊ի կամ fpc֊ի ելատեքստերի մէջ՝ տալիս էի իրան։ armhf բիլդն էլ եղաւ։
էդ պահերին մտածել էի որ arm64 բիլդը իզուր տապալուում ա ու պէտք ա ինչ֊որ ձեւ նշել որ չշինի դրա համար, զի fpc-3.0.2֊ը չունի դեռ arm64֊ի սափորտ։ fpc-3.2֊ն ունի, բայց էդ debian beowulf֊ի մէջ այն չկայ։ ու մտածել էի՝ դէ մինչեւ դեբիանը չթարմանայ ու մաեմոն չօգտագործի նոր դեբիան՝ դէ չի լինի։
բայց ինչ֊որ ձեւ սխալ էի սահմանափակում որ պլատֆորմների համար շինի, ու վերջը թողեցի՝ any, ու չեմ հասկանում ոնց՝ arm64֊ի համար էլ բիլդը լրիւ նորմալ անցնում ա։
հա, էս բիլդերի հետ մի խնդիր էլ կար։ fpc֊ի համար գրադարանների ուղիներում կայ x86_64-linux ու կայ arm-linux որը armhf֊ի վրայ ա։ ու ես makefile֊ի մէջ ջոկում էի որն ա ճարտարապետութիւնը՝
ARCH = $(shell arch)
arch քոմանդլայն հրամանը կանչելով։ ու արդէն այդ ստացած $ARCH֊ը տեղադրում էի fpc֊ի ուղիների մէջ։ վերջում ստացած ուղին սէնց սարսափելի տեսք ունէր՝
PARAMS = -MObjFPC -Scgi -Cg -O1 -g -Xg -XX -l -vewnhibq -FD/usr/bin -Fi/usr/lib/lazarus/2.0.0/lcl/nonwin32 -Fu/usr/lib/lazarus/2.0.0/lcl/nonwin32 -Fi/usr/lib/lazarus/2.0.0/lcl/forms -Fu/usr/lib/lazarus/2.0.0/lcl/forms -Fi/usr/lib/lazarus/2.0.0/lcl/interfaces/gtk2 -Fu/usr/lib/lazarus/2.0.0/lcl/interfaces/gtk2 -Fi/usr/lib/lazarus/2.0.0/lcl/widgetset -Fu/usr/lib/lazarus/2.0.0/lcl/widgetset -Fi/usr/lib/lazarus/2.0.0/lcl -Fu/usr/lib/lazarus/2.0.0/lcl -Fi/usr/lib/lazarus/2.0.0 -Fu/usr/lib/lazarus/2.0.0 -Fi/usr/lib/lazarus/2.0.0/lcl/include -Fu/usr/lib/lazarus/2.0.0/lcl/include -Fi/usr/share/fpcsrc/3.0.4/packages/chm -Fu/usr/share/fpcsrc/3.0.4/packages/chm -Fi/usr/share/fpcsrc/3.0.4/packages/chm/src -Fu/usr/share/fpcsrc/3.0.4/packages/chm/src -Filib/$(ARCH)-linux -Fu/usr/lib/lazarus/2.0.0/lcl/units/$(ARCH)-linux/gtk2 -Fu/usr/lib/lazarus/2.0.0/lcl/units/$(ARCH)-linux -Fu/usr/lib/lazarus/2.0.0/components/lazutils/lib/$(ARCH)-linux -Fu/usr/lib/lazarus/2.0.0/packager/units/$(ARCH)-linux -Fu. -Fulib/x86_64-linux/ -FE. -o./project1 -dLCL -dLCLgtk
սա արդէն armhf֊ի աւելացումներով։ x86_64֊ի վրայ դեբիանի կազմարկիչն աւելի քիչ բան էր ուզում գտնել։
հա, ու arch հրամանը որ ինթելի վրայ տալիս էր՝ x86_64, armhf համակարգում վերադարձնում էր՝ armv71։
ապա ստիպուած եղայ կեղտոտ հաք անել՝
ARCH = $(shell arch)
ifeq ($(ARCH),armv7l)
ARCH = arm
endif
օկ, սէնց կազմարկուեց։ ու օհ անակնկալ, նաեւ կազմարկուեց arm64 համակարգում։ գտաւ որ կարծես aarch64 ա ճարտարապետութիւնը ու fpc֊ի ուղիներում էլ ամէնը գտաւ ու կազմարկեց։
էսպէս։
բայց կարեւոր ասածս այլ ա։ սէնց բաներ չեն պահանջում լինել յանճար։ ու լիքը բան չի պահանջում։ ես սրա վրայ նստած էի մօտ 12 ժամ։ ու ամէն անգամ, ամէն պահի վարկած ունէի՝ թէ էլ ո՞նց փորձել։ օրինակ նախորդ գրառման խնդրի հետ՝ թեմայի մէջ չէի ու վարկած չունէի։ իսկ սա՝ ամէն անգամ մի նոր բան էի փորձում։ ու մենք ունենք գործ տարբեր մարդկանց սարքած տարբեր ծրագրակազմերի հետ, տուեալ դէպքում՝ fpc, lazarus, jenkins, debian, ու պէտք ա մօտաւորապէս պատկերացնելով որն ա սխալ գնում բզբզալ մինչեւ ստացուի։ սա հէնց էն not science, trying ձեւն ա։ ու պարզապէս պէտք ա փորձել ու փորձելը երկար ա։ ու խելքը կապ չունի շատ։ համբերատարութիւն ա պէտք։
#տեքնոլոգիաներ #մաեմո #մաեմօ #համբերատարութիւն #փորձ #դեբիան #լինուքս #կազմարկում #ծրագրակազմ
աշխարհը գժուել ա՝ ամն֊ում թրամփ ա, ռդ֊ում պուտին, իսկ մատրիքսը հտտպ֊ով ա աշխատում։
#աստուատ #էկրանահան #ծրագրաւորում #տեքնոլոգիա #մատրիքս #խի #փաստօրէն #կազմարկում
էսօր ահաւոր ուզեցի այբուք ջի չորսիս վրայ ջենթու նստեցնել։
մեքենան շատ դանդաղ ա, կարծես երբ վերջին անգամ թարմացնում էի, հա անջատւում էր տաքանալուց։ ու որոշեցի դեբեան գցել, պրծնել։ բայց դէ դեբեանին էլ չեմ դիմանում, ու արդիւնքում առհասարակ չէի օգտագործում։
նէնց չի որ սովորաբար օգտագործում եմ, բայց այնուամենայնիւ։
հիմա եմ օգտագործում՝ ջենթու տեղակայելիս։ ֆանթու աւաղ չկայ փաւերփիսի֊ի համար։
սէնց, ես չգիտեմ, արդեօք հարդի հետ մի բան էն չի, վերջին անգամ երբ քանդել ենք, տէնց վատ չէր։ քանդել էինք՝ վինչ փոխելու համար՝ մեծ վինչ էի ուզում դնել։ ու մինչեւ հետ հաւաքեցինք, հոգիներս դուրս եկաւ։ շատ բարդ էր։
ու դէ հիմա չեմ քանդի։ բայց երբ տեղակայում էի ջենթու՝ կազմարկում էի ինչ֊որ բան երկու թրեդով՝ անջատուեց։
մտածեցի՝ ի՞նչ անեմ, որ դանդաղ լինի, բայց շատ չտաքանայ։
ու ահա։
նախ make.conf՝
այստեղ MAKEOPTS֊ի մէջ ոչ միայն -j1 ա, այլեւ --load-average=0.5 — պէտք ա էն թօփի աւերիջը էդքանից չբարձրանայ։ չգիտէի նաեւ EMERGE_DEFAULT_OPTS ու PORTAGE_NICENESS֊ի մասին։ վերջինը
փաստօրէն 10֊ով բարձրացնում ա առաջնահերթութեան թիւը՝ այսինքն առաջնահերթութիւնը պակասեցնում։
բայց առաջինն ինչ արեցի, տեղակայեցի cpulimit, այն մի քիչ կեղտոտ ծրագիր ա, /proc֊ով ման ա գալիս, ու պրոցեսների միջեւ բարեկամական կապեր փնտրում։
ամէն դէպքում, աշխատեցրել եմ՝
cpulimit -e cc1plus -l 4&
cpulimit -e cc1 -l 4&
cpulimit -e perl -l 4&
ու այն տեսէք, իր մէսիջն ա, որ բռնում ա պրոցեսներ, յետոյ կորցնում, յետոյ նոր պրոցեսներ բռնում։
եւ վերջապէս, մի բան էլ արի՝ էմերջը աշխատեցրի ionice֊ով։
ionice -c3 emerge gentoo-sources linux-firmware yaboot
զի դէ ամենաառաջինը սիրում եմ իմանալ, որ համակարգը բեռնւում ա, յետոյ արդէն մնացածը։
այստեղ -c3֊ը նշանակում ա idle դաս, երբ պրոցեսը կը ստանայ գրել կարդալու հնարաւորութիւն միայն եթէ ոչ ոք չի գրում կամ կարդում։ #ջենթու #լինուքս #կազմարկում #էկրանահան #գործիքակազմ