SATAI: S tunou chyb.

JARDABEREZA: 60000000 řádek v Čobolu za víkend snadno vygeneruješ v APL

ABAP: 60 000 000 řádek Cobolu? To je přece práce na jeden víkend ne? :-D https://www.zdnet.com/article/if-cobol-is-so-problematic-why-does-the-us-government-still-use-it/

ABAP: HOLAKAC: Tak u nás v ČR, pokud mě paměť nemate, také shodou okolností prý to "jádro" výpočtu důchodů, nebo nějakých takových sociálních výplatků, je archaický COBOL script, na který se prý nesmí šahat.
Teda říkalo se to před spoustou let, ale vsadím se, že to pořád platí, protože kdyby tohle někdo předělával, tak je to stopro v Ústavu pro vysmáté.

JANFROG: novejsi gdb neni problem, to sem-tam prekladam (at uz kvuli chybam nebo archaicnosti). ale co si pamatuju, tu kompresi zarizoval linker, nas linker to neumel a upgradovat neco v nasem dockeru je vzdycky voser (ted sem napr upgradoval fuse na fuse3) tak sem to hodil za hlavu.. jeste se na to podivam, mozna by to ocenili i ostatni kolegove, takze by se na to cas nasel

nas debug build je -O0 -g, navic v gdb samotnym to info je - spis to vypada ze to ty frontendy neumej vytahnout

KLEINZACH: A co mas za GDB? Pokud mas nejake fakt stare, zkus novejsi. Neni zas takova raketova veda to prelozit (s tim muzu pomoci, delam to casto :-). Pripadne mit vlastni GDB vne dockeru a uvnitr si pustit jen gdbserver
(a v zasade jinak nez takhle nedebuguji).

KLEINZACH: I v tech debug buildech se obcas neco ztrati, teda pokud nebuildujes debug buildy s `-O0`
(to delam kdyz uz to je i na me moc :-). I kdyz prekladas s `-O2 -ggdb` tak to proste obcas GCC neda (treba kdyz nahrazuje nejake sekvence vystupem ze superoptimizeru, tam si nedokazu predstavit ze by to vubec mohlo fungovat :-)

A bocni projekty...chapu no. Musis bocni projekt pretavit na hlavni, ale snadny to neni, chce to osvicene vedeni a takovych neni moc, no.

JANFROG: ajo, na tema komprese symbolu uz jsem myslim googlil a pak jsem shorel na tom, ze bych musel upgradovat gcc (nebo linker? uz nevim) v dockeru (pouzivame celkem archaicky tooly). 2. a 3. se podivam, diky

jj pretty print frontendu se nesnasi s lokalne nastavenym pretty printem, na to uz si davam pozor (resp. rychle se dozvim, ze sem na to zapomnel)

(mluvim o debug buildu, u release bych si na chybici info nestezoval)


JANFROG: jo clovece, dalsi bocni projekty muzu pribirat az deti vyrostou :) T-1x let a odpocitavam ;)

-any GDB

prosimvas, pouzivate nejakej rozumnej front end (staci textovej) ke gdb? nebo sem jedinej kdo s tim kramem zapasi? :)

pokazdy kdyz neco delam v gdb tak me to vlastne sere. asi nejvic:
- pomalost (pracuju s binarkama > 3 giga). jeden blbej preklep, aby gdb hledalo v tabulce symbolu a je pomalu rychlejsi to killnout a zacit znovu nez cekat
- pretty printing je dost casto buggy/nestabilni (jasne, neni primo gdb vina, ale manualne prochazet mapy listu se shared pointrama na stringy... kuuurva!)
- neprehlednost.. furt musim nekde neco psat a zjistovat, misto abych videl rovnou: registry, stack, locals, thready

co mi na textovym gdb chybi:
- pohodlnost pri 'bloumani' kodem. dost casto nevim co vlastne hledam a tak jenom trasuju, koukam, nahlizim do datovych struktur co by mohlo bejt relevantni atp. v tomdle me gdb strasne sere, protoze i s tim pretty printem je dost otrava to hledat. ve vizualku je todle mnohem jednodussi, pac clovek proste napul spi a dela klik-klik-klik....-klikklik a vzbudi se az tehdy, kdyz je neco zajimavyho. uz nejsem mladej thread abych jel porad na 100% :)

co jsem vyzkousel:
- v minimu pouzivam tui a cgdb.. ale uprimne to je jak sedet na zidli bez sedaku
- ruzny graficky frontendy typu eclipse, vscode, seer - vsechny maj tu nevyhodu ze jsou ve finale napojeny na ten gdb/mi interface, kterej je imho vetsi pulka problemu (nevim co presne je na tom spatne, rozchazej se interfacy? nebo s tim ty frontendy blbe zachazej?). prochazeni slozitejsich dat bud vubec nefunguje, nebo se na nej nesnesitelne ceka, neuplny data atp
- par textovych frontentu (neco psanyho v pythonu? zkusim dohledat co to bylo).. problem byla opet stabilita
- lldb - to zkousim ted, reaguje mnohem svizneji nez gdb a to jejich textovy gui je na pul cesty toho co bych chtel

asi sem se na jako gamedev na widlich zhejckal - jak je to celkove takovej kompost mezi operacnimi systemy, tak ten jejich debugger je jak perla na.. tom kompostu :)

ono to je asi prast jak uhod.
obcas delas framework, nebot je to do prace a si tlaceni casem
a obcas to udelas cele sam, nebot je to pro kamarada nebo pro sebe a chces se neco noveho naucit a trosku si pohrat, pohrat si s kodem a pohrat se s vlastni hlavou..
je to asi jako ze vsim, muze to byt raj, muze to byt peklo. s framworkem a nebo bez nej...

AXTHEB: Ne, male frameworky typu FastAPI preferuju pro jednu cast aplikaci a velke typu Rails zase pro jine aplikace. Problem je ze jsem nikdy nedelal Sinatru a s Django nemam moc dobre zkusenost... jsem nechtel zbytecne generalizovat frameworky ve kterych jsem moc nedelal