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

JINX: S fast-api nemam zkušenost, ježto jsem k ruby přičuchnul v rámci správy Redmine.

VITEX: Muzes to nejak rozvest? Kdybych ted sel delat webovku tak podle use-case/velikosti nebo jinym pozadavkum se budu primarne rozhodovat mezi Rails/FastAPI ty doby kdy se byznys logika prasila primo do view uz jsou doufam pryc :-)

VITEX: ano. Ale to musíš za at na zelene louce. Já delal asi 5 let jsem se staral o jeden project v obstaroznem phpku. Pak jsem to vzdal a presel jsem na jiní. S toho mám tu zkušenost s starým php. Jo nový je lepší. Já si pak zvolil jinej jazyk..

JINX: vscode se měl vždy ptal na změny z copilota

MARASAN: Ano ve starém PHP můžeš dělat takové prasárny, ale zaděláváš si na problémy. Takže moderní PHP se spíše podobá javě kde není tolik svobody míchat jabka s hruškama a pak se divit že dostaneš ovocný jam.

Jakoze v PHp se misto struktur delala netypovana pole, kde byly vsechny fieldy predem vyhrazeny jednotlivym atributum?
zlatej Perl

JARDABEREZA: tak zrovna timhle me irituje Copilot. Cursor se chova uplne jinak navic vzdy musim akceptovat/rejectnout zmeny kdezto copilot s vscode to do kodu dava sam a sere tak uzivatele