ասք վիշապին մակում բնակեցնելու մասին

ուրեմն, ուզում եմ մի քիչ գրել իմ մակօս֊ական փորձից։

որպէս դեւ, ով առաջին անգամ է այս օհ֊ի հետ աշխատում։ իմ հին ծանօթ աւստրալիացին իր մակի վրայ հաշիւ է բացել, որ կպնեմ, վոկ֊ը պորտ անեմ մակի։

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

clang hints

Միւս կողմից, այդ իր վարքագիծը նոյնիսկ յոգնացնում է։ Ասենք, այս դէպքում, լրիւ անիմաստ է զգուշացնել, ինձ թւում է՝

clang warning

ասում է՝ «place parentheses around the ‘&&’ expression to silence this warning»։ ինչո՞ւ։ կոմպիլյատորը գիտի, չէ՞, ցանկացած սի֊ի կոմպիլյատորը այդքան պարզ բան գիտի, չէ՞ որն է օպերատորների precedence֊ը։ ուրեմն ո՞ւմ համար է։ գրողի, կամ կարդացողի։ որ գրողը տեսնի իր գրածը, ու իմանայ, որն է precedence֊ը, այնպէս չստացւի, որ կասկած լինի, որ նա չգիտի։

բայց սա արդեն ո՞ւմ համար է։ ակնյայտ անգրագէտի՞։ չգիտեմ, լա՞ւ է դա, թէ չէ։ այն էլ լռելեայն, առանց զգուշացումներն յատուկ միացնելու։

Ասենք այս կոդի մէջ կայ սխալ՝

int main()
{

   int a, b;
   
   a = 23; b = 42;

   if (a = b)
      {
        b = a;
      }

}

սիլանգը ասում է՝

clang_warnings

ասում է… նու ճիշտ բան է ասում, հա՞։ բայց կարող է ես ուզում եմ սենց բան անել, ինձ պէտք է հենց այսպէս, ինչի՞ պիտի հայհոյի։ նկատի ունեմ, նա ինձ նախապէս դնում է յիմարի տեղ։ ենթադրում է, որ ես չգիտեմ ինչ եմ անում։

չգիտեմ, լաւ է դա թէ վատ։

ջիսիսի֊ում իմ ցանկութեամբ կմիացնէի ասենք, -pedantic, ու կնայէի ինչ է ասում։

հիմա համակարգից։

փաստօրէն, ստատիկ բինար նիշք ստանալ չեմ կարող։ մակօս֊ում չի լինի։ իրենք (էփլը, ֆաշիստները, սրիկաները) չեն տալիս համակարգի գրադարանների ստատիկ տարբերակները՝ .a նիշքերը, ասենք։ Որ դրանց միջի .o նիշքերը լինի ստատիկ միացնել իմ ծրագրին։

երկրորդ շատ հետաքրքիր բանը։ այստեղ ELF չկայ, այստեղ Mach-O բինարնիկներ են։

ու այդ պատճառով էլ .so չկայ, կայ .dynlib.

ldd֊ի փոխարէն էլ otool է

$ otool -L voc
voc:
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
$ 

ու վերջապէս այն, ինչը լրիւ անսպասելի էր։

ուրեմն, ես երբ voc֊ը թեստաւորում եմ, անում եմ այսպէս․ ստացա՞յ նոր վարկածը, իրենով իրեն շինում կոմպիլացնում եմ, ու նայում եմ md5 գումարը նոյնը մնա՞ց թէ չէ։

ինձ պէտք է որ նոյնը մնայ, եթէ չէ, ուրեմն ինչ֊որ բան սխալ է, ինքն իրեն վերարտադրել չի կարողանում։ ու սխալը երկար չի թաքնւում, արդեն երկրորդ անգամ, յաջորդ սերնդի վարկածը կամ ինքն իրեն, կամ այլ մոդուլներ կոմպիլյացիա անել չի կարողանում։

այս անգամ, նա ինքն իրեն ստաբիլ ստանում է, լրիւ գրադարանները ստաբիլ կարողանում է շինել, իսկ արի ու տես, որ իր իսկ md5 գումարը հա փոխւում է։

ամէն անգամ կոմպիլյացիայից յետոյ փոխւում է։

ես մտածում էի՝ խնդիր ունեմ։ ես եմ մի բան սխալ արել։

յետոյ մտածեցի, ո՞վ գիտի ի՞նչ է այդ ոչ էլֆ օ֊մախ բայնարին։ մի հատ ․օ֊ները ստուգեմ։

բոլոր գեներացւող ․օ֊ները նոյն էմդիհինգն ունէին։ Դա ինձ հանգստացրեց։ Բայց ամէն անգամ լինքինգից յետոյ ստացւած նիշքի էմդիհինգ գումարը փոխւում էր։ Յետոյ պարզեցի, որ այդ մակի ֆորմատի ձեւն է, ամէն անգամ լինքերը մախ բինարիի մէջ uuid է սարքում խփում։ այն պէտք է իրեն համապատասխանեցնելու համար արտաքին dwarf debugging տւեալները յստակ այս կամ այն նիշքի հետ։

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

ու տենց

ասք վիշապին մակում բնակեցնելու մասին՝ http://norayr.arnet.am/weblog/2014/03/20/ասք-վիշապին-մակում-բնակեցնելու-մասին/

#voc #oberon #clang #vishap #վիշապ #հետազօտութիւն #ասք #ծրագրաւորում #ուտենց

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)

Изначально просто брать и заменять свой парсер на clang никто не собирался - разработчики не хотят регрессий, даже ради точного анализа. Где-то в 2010 был составлен долгосрочный план, и один инженер - Erik Verbuggen - начал работу. И вот автокомплит/подсветка уже заработала, и тут столкнулись с проблемами производительности - в файлах самого QtCreator репарсинг генерация дополнения занимает до 0,6 сек, подсветка - до 1 сек.

Потом Erik Verbuggen уехал на полгода в отпуск, а теперь его бросили затыкать недостаток сил в нативном парсере. Экспериментальная поддержка сделана на 50% - ещё нет лексера и индексера на clang, для этого используется нативный парсер. #qt #digia #clang #compilers #qt-creator #parsers http://www.linux.org.ru/news/opensource/8447338?cid=8447726

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)