մատեան անկապութեան

c

2021-04-18-2492083 – 2021-04-18

այսօր դաշնեզերքի օգնութեամբ բացայայտեցի cppcast պոդքաստը։ լսեցի վերջին էպիզոդը՝ այն մասնաւորապէս ̶բ̶ո̶ր̶լ̶ա̶ն̶դ̶ի̶ էմբարկադերօյի c++ builder֊ի մասին էր։

հետաքրքիր ա որ
- այլեւս չեն զարգացնում իրենց c++ կազմարկիչը, անցել են clang֊ի։
սա շատ կարեւոր թեմա ա ինձ համար, նշանակում ա c++֊ն այնքան արագ տեմպերով ա զարգանում, որ նոյնիսկ այդ, բաւական լուրջ, բաւական, թւում ա թէ, փող ունեցող ընկերութիւնը, չի հասցնում իր կազմարկիչը զարգացնել։

սա կարող էր ոգեւորիչ լինել․ ահա՛, ազատ ծրագրակազմը յաղթում ա, ոչ մի առանձին ընկերութիւն չի կարող հասնել, զի համայնքը զօրաւոր ա, եւ մարդկութիւնը իր ամբողջ ռեսուրսներով կարողանում ա աւելին անել, քան առանձին ընկերութիւնը։

ու մասամբ երեւի այդպէս ա։

մտահոգիչ մասն այն ա, որ լեզուն այնքան ա բարդացել, որ չի լինում առանձին ընկերութեան համար այն իրականացնելն այլեւս իրատեսական չի։ մօտաւորապէս նման պատմութիւն ա դիտարկիչների հետ՝ html֊ն ա այնքան բարդացել, որ առանձին ընկերութիւն այն իրականացնել չի կարող։

եւ մեր բախտից ա (դէ իրականում նախկինում տարուած պայքարից) որ գուգլն ու էփլը այսօր ազատ ծրագրակազմ են ֆինանսաւորում, ու կայ chromium֊ը, եւ llvm֊ն ա ազատ։

բայց եթէ մթնոլորթը փոխուի, մի պահ ա գալու, երբ chromium֊ի շարժիչը գուգլը կարող ա եւ փակել։ իսկ եղած ազատը համայնքը չի կարողանայ զարգացնել այնպէս որ արագ զարգացող ստանդարտներին հասնի։ այդ պատճառով էլ եմ ես ոգեւորւում աւելի պարզ համակարգերից, ինչպիսին են gemini֊ն, եւ oberon֊ը։

c լեզուն էլ ա բաւական պարզ (առանց ընդլայնումների) որ մի հոգի նստի եւ մի քանի ամսում իրականացնի կազմարկիչ։

շարունակեմ այն մասին, ինչ եմ յիշում զրոյցից։
- հին կոմպիլեատորը դեռ տարածւում ա builder֊ի հետ, բայց առանձնապէս չի օգտագործւում, եւ հաւանաբար այն դիստրիբուտիւից հանելու են։ այսօր builder֊ի թիմը մասնաւորապէս զբաղուած ա նրանով, որ ինտեգրում ա builder֊ին սպեցիֆիկ c++ լեզուի ընդլայնումները clang֊ի մէջ, իսկ clang֊ի ներքին ինտերֆէյսները փոխւում են, ու հետեւաբար դա շարունակական պրոցես ա։
ի՞նչ ընդլայնումներ են դրանք։

դէ դա ես գիտէի, ու կարելի ա պատկերացնել՝

c++ builder֊ը օգտագործում ա բորլանդի object pascal֊ով գրուած vcl (եւ արդէն fmx) գրադարանները։ իսկ գրադարանները նախատեսուած են gui ծրագրեր գրելու համար։ այդ պատճառով object pascal֊ն ունի properties՝ յատկութիւններ, որ կլասի դաշտեր են։ բայց երբ դու վերագրում ես յատկութեանը, իրականում տակից կանչւում ա setter մեթոդ, իսկ երբ կարդում ես դրանից, իրականում տակից կանչւում ա getter (fread) մեթոդ։ դրանք պէտք ա սահմանես, եթէ հատկութիւն ես աւելացնում։ յատկութիւններ նաեւ ունի բորլանդի c++ լեզուի դիալեկտը։

վարողը հարցրեց, արդե՞օք ընկերութիւնը փորձել ա լեզուի ընդլայնումներն աւելացնել c++ ստանդարտի մէջ։ ինչ֊որ գործ այդ առումով արուել ա, ու հիւրը մի քանի c++ կոմիտէի թղթերի յղուեց։ բայց վերջին թուղթը որին յղուել էր փաստարկներ էր անում ինչու յատկութիւններ լեզուի մէջ բերելը վատ միտք ա՝ զի կարող են ոչ տեղին օգտագործուել (misuse), երբ պէտք չի (իբր դա c++֊ի համար ամենակարեւոր խնդիրն ա՝ իբր c++֊ում արդէն չկան հնարաւորութիւններ որ կարող ա սխալ կամ ոչ տեղին օգտագործուեն), եւ այլ փաստարկն այն էր, որ թափանցիկ չի, մարդիկ կարող ա չիմանան, որ դաշտ չի այն, ինչը դաշտ ա երեւում։ սա շատ լաւ փաստարկ ա, բայց կրկին՝ c++֊ն արդէն ունի բազմաթիւ հնարաւորութիւններ որ սինտակտիկ շաքար են։ բայց ես ինքս նոյն կարծիքի են՝ ինձ դուր չեն գալիս յատկութիւններ, եթէ դրանք սովորական դաշտի տեսք ունեն, ու սինտաքսից պարզ չի, որ հատկութիւն են, եւ ոչ թէ սովորական դաշտ։

այլ ընդլայնումը վերաբերում էր, իհարկէ, event֊ներին՝ օրինակ, կտոցը կոճակին event ա, որ կապուած ա յատուկ ֆունկցիայի հետ։ այդ համար borland֊ը նախագծել էր closure կոչուող լեզուի յատկութիւն։ տես նաեւ սա։

ի դէպ քիւթը այլ ձեւերով ա լուծում նոյն խնդիրները, իրենք ունեն սիգնալ եւ սլոտ հասկացութիւններ, բայց ձեռք չեն տալիս c++ կազմարկիչը, փոխարէնը գրել են մի գործիք՝ moc, որը իրենց, քիւթին սպեցիֆիկ սիփլասփլասը թարգմանում ա ստանդարտ սիփլասփլասի։

abi֊ի հետ են շատ գործ անում, եւ pascal֊ական տիպերի հետ համատեղելի լինելու։ գիտենք, որ դելֆիի պասկալն ունի cow strings, իմացայ որ ունի նաեւ ինչ֊որ տարադրամի տիպ, ու այդ տիպերին, բնական ա, իրենց c++֊ն էլ պէտք ա սատարի։

դելֆիի պասկալի ֆունկցիայի քոլերն ունեն register կոչուող calling convention, այդ համար էլ ա գործ արւում։ abi֊ն ջանում են մի ստաբիլ վարկածի մէջ չփոխել, ու եթէ abi֊ի փոփոխութիւններ են նախատեսւում, ապա դրանք արւում են մէյջըր ռելիզների ժամանակ։ այդ փոփոխութիւնները ոչ միայն կարող են վերաբերուել հէնց ֆունկցիաներ կանչելու ձեւին, այլեւ նրան ինչպէս են տուեալները պահւում յիշողութեան մէջ։
- նշեց որ c++ builder֊ն այլեւս չունի android֊ի համար յաւելուածներ գրելու հնարաւորութիւն, բայց դեռ ունի ios֊ի համար գրելու հնարաւորութիւն։ անդրոիդի «բեքենդը» (որովհետեւ լոկ բեքենդ չէր, ահագին ենթակառուցքուածքներ էին) հանել են այն պատճառով, որ պահանջարկ չկար։ կրկին, անդրոիդ դեւելոփմենթ էլ ա այնքան բարդ, որ պարզւում ա, ձեռնատու չի մի քանի (գուցէ մի հոգի էին պահում որ գործն անի) հոգու փող տալ, զի այդ փողը չեն հանի։
ու գուցէ ios դեւելոփմենթն աւելի պարզ բան ա՝ կպնում ես objective c գրադարաններին, պէտք չի jni անել, պէտք չի լիքը այլ բան։ կամ գուցէ իսկապէս այօս դեւելոփմենթի պահանջարկ ունեն։

վախեցայ որ դելֆիից էլ են հանել անդրոիդի մասը, ստուգեցի, ու կայքում կարծես թէ գրուած ա որ ունեն անդրոիդ դեռ։ չգիտեմ։
- որոշ չափով խօսուեց delphi֊ի մասին, զի builder֊ի delphi֊ի հետ սերտ կապեր ունի։ օրինակ, կարող ա ընդլայնել պասկալով գրած կլաս։ դէ բնական ա, զի կարող ա ուզես մի կոնտրոլի հիման վրայ մի այլ կոնտրոլ սարքել։ պատմեց, որ delphi֊ն կարողանում ա գեներացնել հեադեր նիշքեր որ իրենց c++ կազմարկիչը կը ճանաչի։ որ շատ հանգիստ լինկ են լինում pascal եւ c++ ծրագրերը։ ու որ աւելի բարդ ա պասկալից կպնել սիփլասական գրադարաններին, քան հակառակը, զի սիփլասփլասը կոնստրուկտներ ունի, որ պասկալը չունի։ իսկ այն կոնստրուկտները որ իրենց պասկալից պէտք էին՝ իրենք արդէն աւելացրել են իրենց սիփլասփլաս կազմարկչի մէջ, ու հետեւաբար պասկալ կոդ շատ հեշտ ա օգտագործել։
- նշեց մի քանի նախագիծ, բայց առանց անունների, որ գրուել են սիփլասփլաս բիլդերով։ ու ես հասկացայ որն են իրենց մեծ պատուիրատուները, օրինակ կան ծրագրեր որ սպասարկում են էլեկտրակայաններ, ու քանի որ կոդն ի սկզբանէ գրուած ա եղել բորլանդի բիլդերով, այսօր էլ էմբարկադերօն պէտք ա, որ սպասարկի պրոդուկտ, որը կառնեն այդ էլեկտրակայանի ծրագրակազմ նախագծողները։
- ես կարծում եմ որ իրենց գնային քաղաքականութիւնը խանգարում ա իրենց զարգանալ։ եւ այդ պատճառով էլ վարողը հարցրեց, արդեօք կան օփեն սորս դեւերի համար անվճար վերսիաներ։ պատասխանը՝ այո, բայց մի վերսիա հետ ընկած ա, աշխատում ենք թարմացնել։
- ովքե՞ր են օգտագործում բիլդեր — հիմնականում ուինդոուս դեւելոփերներ։
ինձ թւում ա, դա բորլանդի, եւ յետոյ էմբարկադերօյի ամենամեծ խնդիրներից ա, որ չեն կարողացել հասցէագրել (այսպէս կարելի՞ ա ասել), չեն կարողացել այնպէս անել որ ոչ ուինդոուս ծրագրաւորողները հետաքրքրուեն նախագծով։ իհարկէ, շատ բարդ ա մրցել լինուքսի աշխարհում, ուր մարդիկ սովոր են ազատ լուծումների, ու սիփլափփլաս մարդիկ սովոր են քիւթին, եւ շատերն իրենց վճարում են։ բայց կարելի էր մրցել, կարելի էր լուրջ փորձեր անել շուկայ մտնելու։ ու բնաւ անիրատեսական չէր մակօսի շուկայ մտնել, կարծում եմ շատ շատերը կը նախընտրէին բիլդեր էքսկոդին, բայց բիլդերի (ինչպէս եւ դելֆիի) այդիին, նախագծման միջավայրը աշխատում ա միայն ուինդոուսում։ ինձ թւում ա դա ամենակարեւոր խնդիրներից ա որ իրենք չլուծեցին, զի մակօս դեւը չի ուզի ուինդոուսում գրել մակօս ծրագրեր։

ընդհանուր առմամբ զարմացած եմ, ինչքան անտեղեակ էր վարողը, որ սիփլասփլաս աշխարհից ա, բիլդերից։ ու դա այն մասին ա, ինչքան ա բիլդերը, որ բաւական լաւ նախագիծ ա, ու ոգեշնչուած ա դելֆիից, չգնահատուած, ինչպէս եւ ինքը դելֆին։

#ծրագրաւորում #ծրագրաւորման_լեզուներ #պասկալ #սիփլասփլաս #սի #բիլդեր #բորլանդ #էմբարկադերօ #նախագծում #ծրագրակազմ #հարցազրոյց #պոդքաստ #տտ #տեք #գործիք #գործիքներ

բնօրինակ ծմակուտում(եւ մեկնաբանութիւննե՞ր)
C ծրագրաւորում ծրագրաւորման_լեզուներ պասկալ սիփլասփլաս սի բիլդեր բորլանդ էմբարկադերօ նախագծում ծրագրակազմ հարցազրոյց պոդքաստ տտ տեք գործիք գործիքներ
2020-09-02-4499476 – 2020-09-02

this is a very good blog post՝ back to basics about strings in C and Pascal. i suggest you to read it, and now i’ll tell you something else:

in Oberon, Wirth decided to give up on Pascal strings, and use zero terminated strings.

however, there is no need to run by the whole array to find out the length of the string. we don’t even need to have a separate field that holds the length՝ compiler knows the length of the static string.

thus it can do compile time tests. for example we have the following Oberon source՝
```
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.
```
lets try to compile it՝
```
[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 compiles Oberon source to C, which is very good to illustrate what happens. if we have՝
```
str: ARRAY 16 OF CHAR;
```
then the output C code will be՝
```
static CHAR tst_str[16];
```
nothing more։ no field for the length.

still, this՝
```
FOR i := 0 TO LEN(str) DO
```
will translate to՝
```
tst_i = 0;
while (tst_i <= 16) {
```
as i said we know the length at compile time. doesn’t matter if you generate C or assembly, you already know the number, you can put the number to the output assembly code as well.

when we write a function which receives strings, we should not knowt the length of the received string, we just use ARRAY OF CHAR as an argument՝
```
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.
```
therefore C code will be՝
```
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);
}
```
as we see՝ the function also gets the length of strings. and if we do LEN(a) we get the length without any calculations.

now let’s see how dynamic strings work՝
```
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.
```
now we hase a static string՝ s and we allocate a dynamic string with its pointer ps. lets assume we don’t know the size of ps^ string (^ means dereference) and we will receive the length of the allocated string as a function argument. it is not known at compile time.

first function remains unchanged, second function gets translated like this՝
```
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]);
}
```
the _NEWARR is a bit more complicated function, which is a part of the runtime. but we can understand what it does՝ it allocates a space in the heap, and the pointer ps we get now points to the struct, which has a data field and len field.

this is a runtime information, and in this case we have to keep a separate field for the length of the string.

that’s it.

#oberon #c #pascal #wirth #programming #programming-languages #programming_languages #design #implementation #vishap #voc #compiler #compilation #strings #string #heap #stack #storage #storage-management #storage_management #length

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)
oberon c pascal wirth programming programming-languages programming_languages design implementation vishap voc compiler compilation strings string heap stack storage storage-management storage_management length
2020-02-24-4117478 – 2020-02-24

Modula and Modula-2 went nowhere not because they’re particularly high level languages (they’re not much higher than C!) but because they didn’t have a quasi-free operating system spreading like a virus to bolster their popularity. At the time Unix was almost unique in being a semi-capable operating system written in a portable language that wasn’t wrapped up in billions of proprietary licensing arrangements (because AT&T didn’t notice there was a potential market for it until after the cat had escaped the bag).

source

#modula #modula-2 #modula2 #c #programming-languages #programming_languages #unix

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)
modula modula-2 modula2 c programming-languages programming_languages unix
2018-11-11-3345807 – 2018-11-11

First things first: printf is expecting a valid (i.e. non-NULL) pointer for its %s argument so passing it a NULL is officially undefined. It may print “(null)” or it may delete all files on your hard drive–either is correct behavior as far as ANSI is concerned (at least, that’s what Harbison and Steele tells me.)

https://stackoverflow.com/questions/11589342/what-is-the-behavior-of-printing-null-with-printfs-s-specifier/11589443#11589443

#programming #c #null

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)
11589443 programming c
2017-09-28-2759306 – 2017-09-28

C, Rust, Pascal and Go are the best in terms of energy consumption!

https://jaxenter.com/energy-efficient-programming-languages-137264.html

#golang #c #rust #pascal #energy #programming-languages #programming_languages #programming

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)
golang c rust pascal energy programming-languages programming_languages programming
2016-08-29-2177590 – 2016-08-29

today we were discussing different spacecraft accidents caused by/related to software, discussed Arian-5 case, and I remembered a Soviet case, where there was a problem with decimal separator and Fortran compiler. Decimal separator in USSR was comma, but in Fortran code it should be the dot.

Also, Fortran compiler did not consider using comma instead of the dot as an error, but as different code. And my friend said - the same is possible to do in C++ - and sent me the illustration.
```
#include <iostream>
using namespace std;
int main()
{
cout << "Hello World" << endl;
if (1,2!=1.2)
{
cout << (1,2) << endl;
}
return 0;
}
```
if you run it, you’ll get
```
Hello World
2
```
(:

#safety #programming #mistakes #safe #c++ #code #example #programming-languages #programming_languages #arian #fortran #source

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)
include safety programming mistakes safe c code example programming-languages programming_languages arian fortran source
2016-05-26-2042055 – 2016-05-26

C++ is a horrible language. It’s made more horrible by the fact that a lot of substandard programmers use it, to the point where it’s much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C.

Linus Torvalds, here.

#linus #linus_torvalds #git #programming_languages #programming-languages #c++ #c #programming

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)
linus linus_torvalds git programming_languages programming-languages c c programming
2015-12-14-1781229 – 2015-12-14

how C evolved http://pastebin.com/UAQaWuWG

so it wasn’t designed from scratch indeed. it had to pass evolutionary process. and that’s not always about best design.

https://vimeo.com/132192250

#C #programming #programming_languages

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)
C programming programming_languages
2015-02-27-1314839 – 2015-02-27

Now, modular programming is possible in C, but only if the programmer sticks to some fairly rigid rules:
- Exactly one header file per module. The header should contain the function prototypes and typedef declarations to be exported, and nothing else (except comments).
- The comments in a header file should be all that an external caller needs to know about the module. There should never be any need for writers to know anything about the module except what is contained in the header file.
- Every module must import its own header file, as a consistency check.
- Each module should contain #include lines for anything being imported from another module, together with comments showing what is being imported. The comments should be kept up-to-date. There should be no reliance on hidden imports which occur as a consequence of the nested #include lines which typically occur when a header file needs to import a type definition or a constant from elsewhere.
- Function prototypes should not be used except in header files. (This rule is needed because C has no mechanism for checking that a function is implemented in the same module as its prototype; so that the use of a prototype can mask a “missing function” error.)
- Every global variable in a module, and every function other than the functions exported via the header file, should be declared static.
- The compiler warning “function call without prototype” should be enabled, and any warning should be treated as an error.
- For each prototype given in a header file, the programmer should check that a non-private (i.e. non-static, in the usual C terminology) function with precisely the same name has its implementation in the same module. (Unfortunately, the nature of the C language makes an automatic check impossible.)
- Any use of grep should be viewed with suspicion. If a prototype is not in the obvious place, that’s probably an error.
- Ideally, programmers working in a team should not have access to one another’s source files. They should share only object modules and header files.
http://www.modulaware.com/mdlt35.htm

#programming #modularity #modular-programming #modules #C #modula #modula2 #oberon #consistency #safety

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)
include include programming modularity modular-programming modules C modula modula2 oberon consistency safety
2014-02-12-610398 – 2014-02-12
- Why void main is wrong.
- Why gets() is bad.
- Why implicit main is bad.
- How to <a href="http://sourceforge.net/apps/mediawiki/cpwiki/index.php?title=Delay"delay a program.
- Why Turbo C is bad.
- How to <a href="http://sourceforge.net/apps/mediawiki/cpwiki/index.php?title=Indentation"indent properly.
- How to keep a Windows console from closing.
- What an Integrated Development Environment is.
- What Endianness is.
- Need an introduction to Graphics?
- Why fflush(stdin) is bad.
- Why buffer overruns are bad.
- Information about Boost (specific libraries also have their own articles).
- A pointer on pointers.
- A short guide on what undefined behavior is.
- Don’t use feof in a loop.
- All about profiling with gprof.
- Using POSIX timers
- How to shuffle an array
- Intro to Serialization
- How to clear the input buffer (or how to fix common input problems)
http://sourceforge.net/apps/mediawiki/cpwiki/index.php?title=Main_Page

#gcc #c #programming #development #gprof #posix #serialization #endianness #boost #indentation

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)
gcc c programming development gprof posix serialization endianness boost indentation
2013-10-27-416211 – 2013-10-27

I’ve mentioned before in comp.lang.modula2, Oberon hasn’t a specific set of object-oriented techniques burnt into the language. Instead of this, Oberon provides you with all necessary features (namely type extension, type tests, procedure types and hidden record components) to adapt any interesting OO-technique. Surprisingly enough, the Oberon techniques in practise are much more powerful than common OO-models and OO-languages. As an example: C++ provides so many unnecessary features and so much more complex than Oberon but doesn’t provide type tests up to now.

https://groups.google.com/forum/#!topic/comp.lang.oberon/8Bmb20Ds8Cg

#Oberon #oop #c #c++ #1993 #type-extention #type-tests #procedure-types #libc #usenet

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)
Oberon oop c c 1993 type-extention type-tests procedure-types libc usenet
2013-10-27-416205 – 2013-10-27

https://groups.google.com/forum/#!topic/comp.lang.oberon/8Bmb20Ds8Cg

#programming #usenet #1993 #oberon #c #libc #ulms-oberon-compiler #programming-languages #hello-world #write #printf #setlocale

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)
include include include define define programming usenet 1993 oberon c libc ulms-oberon-compiler programming-languages hello-world write printf setlocale
2013-10-26-415148 – 2013-10-26

Ngaro is a minimalistic virtual machine emulating a dual stack computer with a simple instruction set and a few basic I/O devices.

http://retroforth.org/docs/The_Ngaro_Virtual_Machine.html

#ngaro #vm #virtual-machine #emulation

At present, there are full implementations in #Assembly (#x86), #C, #F#, #Go, #Common-Lisp, #PHP, #Python, and #Ruby, and minimal implementations in #C#, #Forth, #Lua, #JavaScript, #Java, #Perl, and #Scheme

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)
ngaro vm virtual-machine emulation Assembly x86 C F Go Common-Lisp PHP Python Ruby C Forth Lua JavaScript Java Perl Scheme
2013-09-18-364788 – 2013-09-18

Over the past few days I have taken an interest in writing my own linker scripts, start code and a CRT0 (C Runtime) http://www.theresistornetwork.com/2013/09/arm-bare-metal-programming.html

#arm #programming #c #runtime #crt0 #linking

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)
arm programming c runtime crt0 linking
2013-02-19-119036 – 2013-02-19

On the X axis you see the number of threads that the program creates. On the Y axis you see the arithmetic mean of the run time over 10 runs. The green line is Haskell, the red line is C. Haskell is almost 10 times faster. Control.Concurrent kicked pthreads’ ass, leaving it no chances.

http://10098.arnet.am/?p=147 #haskell #threads #c #comparison #programming #pthread #benchmark #programming-languages

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)
haskell threads c comparison programming pthread benchmark programming-languages
2012-12-27-65557 – 2012-12-27

The #libc is certainly not a good guide:
- Buffer overruns are not ruled out by design: gets, sscanf etc.
- Interface inconsistencies: gets vs fgets, fgets vs fscanf (note the position of the file stream parameter)
- Bad interfaces like that of getchar() whose return code can be a character or an error code
- Particularly bad buffering system which – ignores the block structure of underlying file systems, and – does not support bidirectional buffering
- No provisions exist such that independent libraries can cooperate with each other in – signal handling, – setting up alarms, and – tracking childs.
(Please note that I do not want to bash Ritchie, Kernighan etc. The libc is #history and should be taken as such… It is time to abandon #C and the libc and it does not help to place other systems on top of this historic relic.) #programming-languages https://comp.lang.oberon.narkive.com/Vb26nQgd/some-ideas-on-eth-oberon-linux-c-relationship 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

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)
libc history C programming-languages e8b65d37114d4931
2012-12-21-61826 – 2012-12-21

A small #hack for embedding #GDB #breakpoints in #C s#ource #code. https://github.com/kmcallister/embedded-breakpoints

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)
hack GDB breakpoints C ource code
2012-12-04-49983 – 2012-12-04

#Bjarne-Stroustrup, Designer of the #C++ #Programming Language, to Join #Embarcadero for #Live Conversation During #CodeRage 7 http://edn.embarcadero.com/article/42756

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)
Bjarne-Stroustrup C Programming Embarcadero Live CodeRage
2012-11-06-23959 – 2012-11-06

Մեկ օրինակ հինգ լեզուներով՝ http://hy-it.org/1822/one-in-five/ #ծրագրավորում #go #c #c++ #java #lisp

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)
ծրագրավորում go c c java lisp