Sestdienas rītā, kad ārā temperatūra kādi mīnus 15, uzvilku ziemas jaku un krosenes, iekāpu mašīnā un aizbraucu uz veikalu. Šortos. Pēc tam bija stipri jāsakož zobi, lai nesmietos par cilvēku izbolītajām acīm. Bet man nesalst.
Tas atgādināja bērnību, kad 90. gados dobokā un basām kājām trenējāmies nekurinātās vai slikti apkurinātās sporta zālēs un pusstunda pagāja, līdz atkal varēja just kāju pirkstus. Uz beigām treneris kļuva apsēsts ar “Детка” ideju un vairākas reizes treniņi notika tajos pašos dobokos basām kājām sniegotā mežā. Beidzās ar to, ka es aizgāju trenēties uz citu klubu.
Mazliet pārfrāzējot: programmētājam bija ātrdarbības problēma un viņš nespēja atrast risinājumu. “Zinu,” viņš teica, “es lietošu vairākus pavedienus.” Tagad programmētājam bija divas problēmas.
Ik pa brīdim uzrodas kāda diskusija par Python GIL likvidēšu. Tā ir “ļaunuma sakne”, kuras dēļ Python vairākpavedienu programmas nespēj izmantot vairākus procesorus, jo vienlaicīgi tiek izpildīta tikai viena instrukcija un darbojas viens pavediens. Oficiālā atbilde šādos gadījumos ir lietot Jython vai neatkarīgus procesus pavedienu vietā.
Arī jaunākajā Python 3k versijā GIL joprojām ir, bet ar dažiem uzlabojumiem. Ja piever acis uz tehnisko realizāciju, šajā prezentācijā ir pāris interesanti fakti:
Šobrīd, “optimizējot” ar vairākiem pavedieniem un paralēlu izpildi, tiek sasniegts negatīvs rezultāts – prezentācijas piemērā uzdevums tiek veikts 1.8 reizes lēnāk.
Nākošajās Python versijās vairākpavedienu programmas strādās gandrīz tikpat ātri kā viena pavediena programmas.
Tāpēc, ja vien programmas šaurā vieta nav I/O (bieži ir), tad par vairākiem pavedieniem Python programmās ir jāaizmirst.
Meklējot precīzos vārdus citātam par Perl izrādījās, ka kopš 2009. gada Erik Naggum vairs nav. Pirms vairākiem gadiem es izklaides pēc lasīju comp.lang.lisp diskusijas ar viņa piedalīšanos apmēram to pašu īpašību dēļ kā tagad skatos dakteri Hausu. Viņš bija Lisp programmētājs, kas ienīda Perl, XML, C++, cilvēku stulbumu, mācīšanās vēlmes trūkumu, prata argumentēt savus uzskatus un nekad nepalika vārdu parādā.
Tas viss ir jautri, kamēr nav vērsts pret tevi.
Kaut kur pusceļā starp RDBMS un NoSQL atrodas FcukSQL pasaule.
No vienas puses FcukSQL grib izmantot SQL, nevis manuāli rakstītu meklēšanas/grupēšanas/summēšanas kodu, grib vairākus(!) indeksus, ACID transakcijas un RDBMS administrēšanas rīkus. Un pilnībā pietiek ar viena datu bāzes servera jaudu. No otras puses – grib “lidojumā” maināmas datu struktūras, glabāt nestrukturētus datus (schema-less) un taisīt indeksus šiem nestrukturētajiem datiem.
Tad rodas risinājumi, kas “izvaro” RDBMS un glabā serializētus datus vai tabulas ar key-value pārīšiem. Bet kaut ko tādu nākas redzēt pirmo reizi:
Kāds ir uzrakstījis diezgan labu rakstu par malloc() kļūdu apstrādi dažādās atvērtā koda programmās un bibliotēkās. Visus variantus atgremot nav vērts, tomēr vispopulārākā stratēģija ir kļūdas ziņojums un priekšlaicīgā procesa pārtrauce (abort), kas ir saprātīgs kompromiss starp mēģinājumu apstrādāt kļūdu un nekā nedarīšanu.
Arī komentāri lasīšanas vērti. Ir interesanta versija (ļoti ticami, bet precīzi pārbaudījis neesmu): malloc() uz Linux pēc noklusēšanas vienmēr atgriezīs ne-NULL adresi. Atmiņa tiks izdalīta tikai brīdī, kad mēģinās rakstīt šajā adresē un programmu nokaus OOM killer.
Pēc šī teksta vēlme apstrādāt malloc() kļūdas vēl vairāk tuvojas nullei.
Š ādu saiti uzgāju, lasot coding horror rakstu par atmiņas vadību . Vairums jauno un moderno programmēšanas valodu ir atbrīvojušās no “drausmīgās” manuālas atmiņas vadības ar new/delete, malloc/free. Bet problēma drīzāk ir acquire/release šablons, kas joprojām ir sastopams daudzās programmās. Es runāju par kaut ko šādu, kur resource ir fails, pieslēgums pie datubāzes, pavediens:
Aizmirstā release problēma joprojām ir aktuāla. Tāpēc man liekas, ka lielākais (automātisko) drazu savācēju trūkums ir tāds, ka tie veic tikai atmiņas resursu vadību. 60-ajos gados tas tiešām bija aktuāli, bet mūsdienās pat “Hello world” lasa vairākus konfigurācijas failus, slēdzas pie datubāzes, Web serveriem un šiem resursiem ir tendence izbeigties ātrāk nekā atmiņai. Problēma tiek slēpta, veicot drazas savākšanu biežāk, vairāk un pat paralēli programmas izpildei. Kaut kādi uzlabojumi šajā jomā ir sastopami C# un Ruby ar paredzamu resursu vadību koda bloka ietvaros, bet man arvien vairāk sāk likties, ka atsauču skaitīšana un RAII ir pareizāks risinājums. Tik daudz darba tiek veikts, lai tuvinātos paredzamai resursu atbrīvošanai – varbūt tā bija jādara no paša sākuma?
Pussy reklāmas Rīgas ielās un televīzijā pašas uzprasījās. Es reģistrēšu preāu zīmi “Cock” – tā būs mana vīzija par proteīniem bagātu enerģijas batoniņu.
Manas smadzenes ir izvarotas un rokas nogurušas: Apache FOP (Formatting Objects Processor) jau esošajiem izvadformātiem pievienoju Horrible Spreadsheet Format, pazīstamu arī kā Excel. Tagad no datiem XML formātā ar standarta XSL(-FO) transformācijām var iegūt XLS atskaites failu.
Smadzenes tāpēc, ka arvien labāk saprotu, ka briesmīgais nosaukums ir tiešām pelnīts – var palasīt kā tiek rēķināts kolonas platums un pārējos ierobežojumus. Rokas dēļ javiskajiem table.getCommonBorderPaddingBackground() .getBorderStyle(CommonBorderPaddingBackground.BEFORE) .
